주요정보통신기반시설 기술적 취약점 분석 평가 가이드

Unix 서버 취약점 분석 평가 _ 3. 서비스 관리(2)

jeff_kim 2024. 8. 1. 16:27

항목 중요도: 상

 

3.12. Sendmail 버전 점검

  • 점검 내용: 취약한 버전의 Sendmail 서비스 이용 여부 점검
    • Sendmail 서비스의 경우 최신 버전 이하 대부분의 버전에서 취약점이 보고되고 있기 때문에 O/S 관리자, 서비스 개발자가 패치 적용에 다른 서비스 영향 정도를 파악하고 주기적인 패치 적용 정책을 수립하여 적용함
  • 점검 목적: Sendmail 서비스 사용 목적 검토 및 취약점이 없는 버전의 사용 유무 점검으로 최적화된 Sendmail 서비스의 운영
  • 보안 위협: 취약점이 발견된 Sendmail 버전의 경우 버퍼 오버플로우 공격에 의한 시스템 권한 획득 및 주요 정보 요출 가능성이 있다
# Sendmail 서비스 실행 여부 점검
ps -ef | grep -i 'sendmail'

# Sendmail 버전 점검
nc localhost 25

# 조치 방법
Sendmail 서비스를 사용하지 않을 경우 -> 서비스 중지, 재부팅 후 다시 시작하지 않도록 시작스크립트 변경
Sendmail 서비스를 사용할 경우 -> 패치 관리 정책 수립 후 주기적인 패치 적용

 

 

3.13. 스팸 메일 릴레이 제한

  • 점검 내용: SMTP 서버의 릴레이 기능 제한 여부 점검
    • SMTP(Simple Mail Transfer Protocol): 인터넷상에서 이메일을 전송할 때 이용하게 되는 표준 통신 규약이다. SMTP에 의해 전자 메일을 발신하는 서버를 SMTP 서버 라고 한다
  • 점검 목적: 스팸 메일 서버로의 악용 방지 및 서버 과부하의 방지를 위함
  • 보안 위협: SMTP 서버의 릴레이 기능을 제한하지 않는 경우, 악의적인 사용목적을 가진 사용자들이 스팸메일 서버로 사용하거나 DoS 공격의 대상이 될 수 있음
# SMTP 서비스 사용 여부 및 릴레이 제한 옵션 확인
ps -ef | grep sendmail | grep -v "grep"
cat /etc/mail/sendmail.cf | grep "R$\" | grep -i "relaying denied"

# 조치 방법
1. vi /etc/mail/sendmail.cf

2. 아래와 같은 조치를 취한다
(전) #R$* $#error $@ 5.7.1 $: "550 Relaying denied"
(후) R$* $#error $@ 5.7.1 $: "550 Relaying denied"

3. 특정 IP, domain, Email Address 및 네트워크에 대한 sendmail 접근 제한 확인(없을 시 생성)
cat /etc/mail/access
ex)
localhost,localdomain	RELAY
localhost				RELAY
127.0.0.1				RELAY
spam.com				REJECT

4. 수정했거나 생성했을 경우 DB 파일 생성
makemap hash /etc/mail/access.db < /etc/mail/access

 

 

3.14. 일반 사용자의 Sendmail 실행 방지

  • 점검 내용: SMTP 서비스 사용 시 일반 사용자의 q 옵션 제한 여부 점검
  • 점검 목적: 일반 사용자의 q 옵션을 제한하여 Sendmail 설정 및 메일큐를 강제적으로 drop 시킬 수 없게 하여 비인가자에 의한 SMTP 서비스 오류 방지
  • 보안 위협: 일반 사용자가 q 옵션을 이용하여 메일큐, Sendmail 설정을 보거나 메일큐를 강제적으로 drop 시킬 수 있어 악의적으로 SMTP 서버의 오류를 발생시킬 수 있음
# SMTP 서비스 사용 여부 및 restricqrun 옵션 확인
ps -ef | grep -i 'sendmail' | grep -v 'grep'
grep -v '^ *#' /etc/mail/sendmail.cf | grep -i 'privacyoptions'

# 조치 방법
1. vi 편집기를 사용하여 sendmail.cf 설정파일 열기
2. O PrivacyOptions= 설정 부분에 restrictqrun 옵션 추가
(전) O PrivacyOptions=authwarnings, novrfy, noexpn
(후) O PrivacyOptions=authwarnings, novrfy, noexpn, restrictqrun

3. Sendmail 서비스 재시작

 

 

3.15. DNS 보안 버전 패치

  • 점검 내용: BIND 최신버전 사용 유무 및 주기적 보안 패치 여부 점검
    • BIND(Berkeley Internet Name Domain): BIND는 BSD 기반의 유닉스 시스템을 위해 설계된 DNS로 서버와 resolver 라이브러리로 구성되어 있음.
    • 네임서버는 클라이언트들이 이름 자원들이나 객체들에 접근하여, 네트워크 내의 다른 객체들과 함께 정보를 공유할 수 있게 해주는 네트워크 서비스로 사실상 컴퓨터 네트워크 내의 객체들을 위한 분산 데이터베이스 시스템이다
  • 점검 목적: 취약점이 발표되지 않은 BIND 버전의 사용을 목적으로 함
  • 보안 위협: 최신버전 이하의 버전에서는 서비스 거부 공격, 버퍼오버플로우 및 DNS 서버 원격 침입 등의 취약성이 존재함
# DNS 서버 사용 및 BIND 버전 확인
ps -ef | grep -i 'named'
named -v

# 조치 방법
DNS 서비스 사용 X -> 서비스 중지
DNS 서비스 사용 O -> 패치 관리 정책을 수립하여 주기적으로 패치 적용

 

 

3.16. DNS Zone Transfer 설정

  • 점검 내용: Secondary Name Server로만 Zone 정보 전송 제한 여부 점검
    • DNS Zone Transfer는 Primary Name Server와 Secondary Name Server 간에 Zone 정보를 일관성 있게 유지하기 위하여 사용하는 기능
  • 점검 목적: 허가되지 않은 사용자에게 Zone Transfer를 제한함으로써 호스트 정보, 시스템 정보 등 정보 유출의 방지를 목적으로 함
  • 보안 위협: 비인가자 Zone Transfer를 이용해 Zone 정보를 전송받아 호스트 정보, 시스템 정보, 네트워크 구성 형태등의 많은 정보를 파악할 수 있음
<DNS 서비스를 사용할 경우>
# DNS서비스 사용 시 /etc/named.conf 파일의 allow-transfer 및 xfrnets 확인
ps -ef | grep -i 'named' | grep -v 'grep'
cat /etc/named.conf | grep 'allow-transfer'
cat /etc/named.conf | grep 'xfrnets'

# BIND8 DNS 설정 수정 예
Options {
			allow-transfer (존 파일 전송을 허용하고자 하는 IP;);
};

# BINd4.9 DNS 설정 수정예
Options
			xfrnets 허용하고자 하는 IP
            

<DNS 서비스를 사용하지 않는 경우>
# DNS 서비스 데몬 확인 (DNS 동작 SID 확인)
ps -ef | grep 'named'

# 조치 방법
kill -9 [PID]

 

3.17. 웹 서비스 디렉터리 리스팅 제거

  • 점검 내용: 디렉터리 검색 기능의 활성화 여부 점검
  • 점검 목적: 외부에서 디렉터리 내의 모든 파일에 대한 접근 및 열람을 제한함을 목적으로 한다
  • 보안 위협: 디렉터리 검색 기능이 활성화 되어 있을 경우, 사용자에게 디렉터리 내의 파일이 표시되어 웹 서버의 구조 및 백업파일, 소스파일, 중요한 공개되어서는 안되는 파일들이 노출될 수 있다
# Indexes 옵션 사용 여부 확인
cat /[apache home]/conf/httpd.conf | grep -i 'indexes'

# 조치 방법
1. vi /[apache home]/conf/httpd.conf

2. 설정된 모든 디렉터리의 Options 지시자에서 Indexes 옵션 제거
(수정 전)
<Directory />
 	Options Indexes FollowSymLinks
	AllowOverride None
 	Order allow, deny
 	Allow from all
</Directory>

(수정 후)
<Directory />
 	Options FollowSymLinks -> Indexes 삭제 또는 -Indexes
	AllowOverride None
 	Order allow, deny
 	Allow from all
</Directory>

 

3.18. 웹 서비스 웹 프로세스 권한 제한

  • 점검 내용: Apache 데몬이 root 권한으로 구동되는지 여부 점검
  • 점검 목적: Apache 데몬을 root 권한으로 구동하지 않고 별도의 권한으로 구동함으로 써 침해사고 발생 시 피해 범위 확산 방지를 목적으로 함
  • 보안 위협: 웹 서비스 데몬을 root 권한으로 실행 시 웹 서비스가 파일을 생성 수정하는 과정에서 웹 서비스에 해당하지 않는 파일도 root 권한에 의해 쓰기가 가능하며 공격자의 공격에 의해 root 권한이 노출 될 수 있음
# Apache 데몬 구동 권한 (User 및 Group) 확인
vi /[aoache_home]/conf/httpd.conf

# 조치 방법
1. 데몬 User & Group 변경 -> root 가 아닌 별도의 계정으로 변경
* 웹 서비스 실행 계정은 로그인이 불가능하도록 쉘 제한 필수!

User [root가 아닌 별도 계정]
Group [root가 아닌 별도 계정]

2. apache 서비스 재시작

 

3.19. 웹 서비스 상위 디렉터리 접근 금지

  • 점검 내용: ".."와 같은 문자 사용 등으로 상위 경로로 이동이 가능한지 여부 점검
  • 점검 목적: 상위 경로 이동 명령으로 비인가자의 특정 디렉터리에 대한 접근 및 열람을 제한하여 중요 파일 및 데이터 보호를 목적으로 함
  • 보안 위협: 상위 경로로 이동하는 것이 가능할 경우 접근하고자 하는 디렉터리의 하위 경로에 접속하여 상위경로로 이동함으로 써 악의적인 목적을 가진 사용자의 접근이 가능해진다
# AllowOverride 지시자 Authconfig 옵션 확인
cat /[apache_home]/conf/httpd.conf | grep -i 'allowoverride'


# 조치 방법
1. vi /[apache_home]/conf/httpd.conf

2. 설정된 모든 디렉터리의 AllowOverride 지시자에서 Authconfig 옵션 설정
(수정 전)
<Directory “/usr/local/apache2/htdocs”>
 	AllowOverride None
 	Allow from all
</Directoty>
 
 (수정 후)
 <Directory "/usr/local/apach2/htdocs">
 	AllowOverride Authconfig
    Allow from all
 </Directory>
 
 3. 사용자 인증을 설정할 디렉터리에 .htaccess 파일 생성 (아래 내용 삽입)
 AuthName "디렉터리 사용자 인증"
 AuthType Basic
 AuthUserFile /usr/local/apache/test/.auth
 Require valid-user
 
 4. 사용자 인증에 사용할 아이디 및 패스워드 생성
 htpasswd -c /usr/local/apache/test/.auth test
 Password 설정
 
 5. 변경된 설정 내용 저장을 위해 Apache 세몬 재시작
 
 **
 해당 설정이 적용된 디렉터리 내 파일들은 아이디/패스워드 인증절차 없이는 접속이 불가능하며,
 대회 서비스 인 경우 해당 디렉터리에 대한 외부자의 접근 필요성을 검토 후 적용해야함

 

 

3.20. 웹 서비스 불필요한 파일 제거

  • 점검 내용: Apache 설치 시 기본으로 생성되는 불필요한 파일의 삭제 여부 점검
    • 불필요한 파일: 샘플파일, 메뉴얼 파일, 임시 파일, 테스트 파일, 백업 파일
  • 점검 목적: Apache 설치 시 디폴트로 설치되는 불필요한 파일을 제거함을 목적으로 함
  • 보안 위협: htdocs 디렉터리 내에 메뉴얼 파일은 시스템 관련 정보를 노출하거나 해킹에 악용될 수 있다
# 불필요한 파일 및 디렉터리 조재 여부 확인
ls -al /usr/local/apache2/htdocs/manual
ls -al /usr/local/apache2/manual

# 조치 방법
1. ls 명령어로 확인된 메뉴얼 디렉터리 및 파일 제거
rm -rf /usr/local/apache2/htdocs/manual
rm -rf /usr/local/apache2/manual

2. 삭제 후 다시 확인 후, 추가적인 웹서비스 운영에 필요하지 않은 파일이나 디렉터리가 있을 시 제거

 

3.21. 웹서비스 링크 사용금지

  • 점검 내용: 심볼릭 링크, Alias 사용 제한 여부 점검
    • 심볼릭 링크: 윈도우 운영체제의 lnk, 바로가기 아이콘과 비슷하다
    • 링크 파일 생성 시 파일 내용은 존재하지 않으나 사용자가 파일을 요청하면 링크가 가리키고 있는 원본 데이터에서 데이터를 가져와 전달
    • 직접 원본을 가리키지 않고 원본 데이터를 가리키는 포인터를 참조함으로써 원본데이터가 삭제, 이동 수정 되면 사용이 불가함
  • 점검 목적: 무분별한 심볼릭 링크, aliases 사용제한으로 시스템 권한의 탈취 방지를 목적으로 한다
  • 보안 위협: 웹 루트 폴더(DocumentRoot)에 root 디렉터리를 링크하는 파일이 있으며, 디렉터리 인덱싱 기능이 차단되어 있어도 root 디렉터리 열람이 가능함
# Options 지시자에서 FollowSymLinks 옵션 제거
cat /[Apache_home]/conf/httpd.conf | grep -i 'options'

# 조치 방법
1. vi /[Apache_home]/conf/httpd.conf

2. 설정된 모든 디렉터리의 Options 지시자에서 FollowSymLinks 옵션 제거
(수정 전)
<Directory />
	Options Indexes FollowSymLinks
    AllowOverride None
    Order allow, deny
    Allow from all
</Directory>

(수정 후)
<Directory />
	Options Indexes -> FollowSymLinks 삭제 또는 -FollowSymLinks
    AllowOverride None
    Order allow, deny
    Allow from all
</Directory>

 

3.22. 웹 서비스 파일 업로드 및 다운로드 제한

  • 점검 내용: 파일 업로드 및 다운로드 사이즈 제한 여부 점검
    • 불필요한 업로드와 다운로드: 내부 정책에 맞지 않는 업로드와 다운로드를 말함, 예를 들어 5Mb 이상의 대용량 파일이나 확장자를 화이트 리스트 방식으로 제한함
  • 점검 목적: 기반 시설 특성상 원칙적으로 파일 업로드 및 다운로드를 금지하고 있지만 불가피하게 필요할 시, 용량 사이즈를 제한함으로 써 불필요한 업로드와 다운로드를 방지해 서버의 과부하 예방 및 자원을 효율적으로 관리하기 위함
  • 보안 위협: 악의적 목적을 가진 사용자가 반복 업로드 및 웹 쉘 공격 등으로 시스템 권한을 탈취하거나 대용량 반복 업로드로 서버 자원을 고갈시키는 공격의 위험이 있음
# LimitRequestBody 파일 사이즈 용량 제한 설정 여부 확인 -> 업로드 및 다운로드는 5Mb를 넘지 않도록 설정을 권고
cat /usr/local/apache2/conf/httpd.conf | grep -i 'limit'

# 조치 방법
1. vi /usr/local/apache2/conf/httpd.conf

2. 설정된 모든 디렉터리의 LimitRequestBody 지시자에서 파일 사이즈 용량 제한 설정
<Directory />
LimitRequestBody 5000000 (* “/” 는 모든 파일 사이즈를 5M로 제한하는 설정 - 단위:byte)
</Directory>

 

3.23. 웹서비스 영역의 분리

  • 점검 내용: 웹 서버의 루트 디렉터리 와 OS의 루트 디렉터리를 다르게 지정했는지 점검
  • 점검 목적: 웹 서비스 영역과 시스템 영역을 분리시켜서 웹 서비스의 침해가 시스템 영역으로 확장될 가능성을 최고화 하기 위함
  • 보안 위협: 웹 서버의 루트 디렉터리와 OS의 루트 디렉터리를 다르게 지정하기 않았을 경우, 비인가자가 웹 서비스를 통해 해킹을 성공할 경우 시스템 영역까지 접근이 가능해서 피해가 확장 될 수 있음
# DocumentRoot의 별도 디렉터리 지정 여부 확인
cat /[Apache_home]/conf/httpd.conf | grep -i 'documentroot'
DocumentRoot "/usr/local/apache/htdocs" or
DocumentRoot "/usr/local/apache2/htdocs" or
DocumentRoot "/var/www/html"

위의 3개의 경로가 아닌 별도의 디렉터리로 변경

# 조치 방법
1. vi /[Apache_home]/conf/httpd.conf

2. 확인 후 위의 3개의 경로중 하나가 아닌 별도의 디렉터리로 변경