웹 서버 Apache 서버보안
가. 웹 서버 프로세스를 위한 계정
Apache와 관련된 사용자 계정은 크게 두 가지가 있다.
● Apache 서버가 설치 및 구동을 위한 계정 - 운영체제에 로그인하여 Apache를 설치하고, 웹서버를 시작/종료 시키는 계정
※ 웹 서비스를 위한 포트로 1024번 미만 포트번호(80 번 포함)를 사용하기 위해서는 이 계정이 root이어야 한다.
● 웹 서버 프로세스를 위한 계정 - 웹 서버 데몬이 시작된 후 일반사용자의 웹 접속을 처리하기 하기 위하여 생성되는 프로세스가 사용하는 계정
“웹서버 프로세스 계정”의 경우 반드시 로그인할 수 없는 계정 즉, 쉘(shell)이 없는 계정으로 설정하여야 한다. 일반적으로는 사용자 ID와 그룹으로 쉘이 없는“nobody”계정을 사용한다. 아래 그림처럼 /etc/passwd파일과 /etc/shadow파일의 nobody 계정에 대하여 맨 마지막에 /bin/sh, /bin/csh등 shell을 명시하는 부분이 제외되어 있음을 확인 할 수 있다.
nobody:x:99:99:Nobody:/:
nobody:*:11900:0:99999:7::: |
또한, 이러한 계정(쉘이 없는계정, 아래 예에서는“nobody”)이 실제 웹 서비스에 적용되려면 아파치 설정파일(httpd.conf)에서“User”,“ Group”지시자(directive)가 아래와 같이 설정되어야 한다.
나. 웹 서버 DocumentRoot의 설정
웹 서버 DocumentRoot는 모든 웹 컨텐트가 저장될 디렉토리 구조이며 이 디렉토리에 위치된 컨텐츠는 웹을 통하여 공개된다. 따라서 가능하면 이 디렉토리는 시스템의 루트 파일시스템 등과는 별도의 파일시스템을 사용해야 한다.
Apache 기본 설치시에는 htdocs 디렉토리를 DocumentRoot로 사용하고 있는데 이를 바꾸도록 한다. htdocs 디렉토리에는 공개될 필요가 없거나 공격에 악용될 수 있는 시스템 관련 정보가 담긴 파일이 기본적으로 설치 될 수 있다.
“/usr/local/www”를 DocumentRoot로 지정하고자 할 경우 httpd.conf 파일에서 다음과 같이 할 수 있다.
#DocumentRoot“ /usr/local/apache/htdocs”
DocumentRoot“ /usr/local/www” |
웹 서버 데몬은 chroot에 설치하는 것을 권고한다. 만약 웹서버 데몬이 공격당했다고 하더라도 공격자는 chroot 디렉토리로 정해놓은 디렉토리 이외로는 접근할 수 없어 피해를 최소화할 수 있다.
다. 불필요한 CGI 스크립트 제거
Apache 배포판에는 불필요한 CGI 스크립트들이 포함되어 있어 공격에 이용될 수 있다. Apache
설치시 기본적으로 cgi-bin 디렉토리에 설치되는 모든 CGI 스크립트들은 제거하는 것이 안전
하다.
라. Apache 환경파일(httpd.conf)의 설정
● 디렉토리 리스팅 방지
- 웹 브라우저에서 사용자가 URL을 입력했을 경우, 웹 컨텐츠가 없을 경우 기본적으로 디렉토리 리스트를 보여주는 것을 방지해야 한다.
- DocumentRoot 디렉토리 내의 모든 파일들이 리스팅되는 것을 방지하기 위해서는 환경설정화일(httpd.conf)“ Options”지시자에서“Indexes”옵션을 제거한다.
● 심블릭 링크의 사용 방지
- 웹 서버에서 심블릭 링크를 이용해서 기존의 웹 문서 이외의 파일시스템에 접근하는 것이 가능하나 심각한 보안 문제를 야기시킬 수 있다. 가령 시스템 자체의 root 디렉토리(/)를 링크 걸게 되면 웹서버 구동 사용자 권한(nobody)으로 모든 파일시스템의 파일에 접근할 수 있게 된다.(예를 들면 /etc/passwd을 공개하게 될 수도 있다.)
- 이를 방지하기 위해서는“Options”지시자에서 심블릭 링크를 가능하게 하는 옵션인 “FollowSymLinks”를 제거함으로써 이를 막을 수 있다.
● SSI(Server Side Includes) 사용 제한
- SSI는 HTML 페이지 안에 위치하고 있으며, 동적인 웹 페이지를 제공할 수 있도록 한다. 하지만 SSI가 포함된 파일은“exec cmd”를 사용해서 어떤 CGI 스크립트나 프로그램들을 Apache가 구동하는 사용자와 그룹 권한으로 실행시킬 수 있다.
- 이 SSI 페이지가 스크립트나 프로그램을 실행시킬 수 없도록 하기 위해서는“Options”지시자에“IncludesNoExec”옵션을 추가함으로써 차단할 수 있다.
● CGI 실행디렉토리 제한
- 사용자들이 CGI 스크립트들을 어느 디렉토리에서나 실행할 수 있도록 할 경우 악의적인 사용자가 CGI 프로그램을 업로드한 후 이를 실행하여 임의의 명령을 실행시킬 수 있다.
- 따라서, CGI 프로그램의 실행은 관리자가 지정한 특정 디렉토리에서만 가능하도록 제한할 필요가 있다. CGI 실행은“ScriptsAlias”지시자에 의해서 실행가능한 디렉토리를 제한할 수 있다.“ ScriptsAlias”지시자 문법은 다음과 같다.
| 정의방법: ScriptAlias URL-path file-path | directory-path |
예를들어 cgi-bin이라는 디렉토리에서만 CGI프로그램을 실행가능하도록 할 경우 다음과 같이 지정할 수 있다.
| ScriptAlias /cgi-bin/“ /usr/local/apache/cgi-bin/” |
앞서 언급한 디렉토리 리스팅, 심블릭 링크, SSI 등에 대한 제어는“Options”지시자에 의해 제어가 가능하다.
| 정의방법: Options [+|-]option [[+|-]option] ... |
“Options”지시자에서 사용할 수 있는 옵션값은 다음 표와 같다.
| 옵션값 |
설명 |
| All |
MultiViews를 제외한 모든 옵션을 줌(default 설정값임) |
| None |
옵션을 주지 않음 |
| ExecCGI |
CGI 프로그램 실행을 가능하게 함 |
| FollowSymLinks |
심볼릭 링크로의 이동을 가능하게 함 |
| Includes |
Server Side Includes를 가능하게 함 |
IncludesNOEXEC
|
Server-side includes는 가능하지만 CGI 스크립트나 프로그램들은 실행할 수
없도록 함. |
| Indexes |
해당 디렉토리 안에 DirectoryIndex에 명기된 파일(index.html 등)이 없을 경우 디렉토리와 파일 목록을 보여줌 |
| MultiViews |
유사한 파일이름을 찾아 주는 기능을 실행함(예를들어 index라고만 입력하더라도 index.*를 찾아 보여줌) |
| SymLinksIfOwnerMatch |
The server will only follow symbolic links for which the target file or directory is owned by the same user id as the link. |
● httpd.conf 설정 예시
- DocumentRoot 디렉토리가 다음과 같이 설정되어 있다고 하자.
Options Indexes FollowSymLinks
|
- 이 경우 다음 그림과 같이 DirectoryIndex에 정의된 초기 파일(index.html) 이 존재하지 않을 경우 디렉토리내의 파일목록을 리스트업 해 준다.
또한, FollowSymLinks로 인해 루트 디렉토리(/)에 심블릭 링크된 system.html 파일(ln -s / system.html)을 열었을 경우 DocumentRoot 디렉토리 상위의 passwd 파일까지 열람이 가능함을 알 수 있다.
이 경우 초기 파일(index.html)이 존재하지 않을 경우 디렉토리 리스트를 보여 주는 것이 아니라 오류 창을 띄워주는 것을 확인할 수 있다.
● 웹 서버 응답 메시지 헤더 정보 숨기기
- 웹서버 해더 정보란 다음과 같이 클라이언트가 Apache 웹서버에 접속했을 때 웹서버에서는 응답 메시지의 헤더를 말한다.
[root@hcjung conf]# telnet xxx.xxx.xxx.xxx 80
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is‘ ^]’.
GET / HTTP/1.1
HTTP/1.1 400 Bad Request
Date: Tue, 15 Oct 2002 11:25:10 GMT
Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1 |
- 이 정보는 공격자에 의해 Apache 웹서버 버전별 또는 구동되고 있는 응용프로그램에 잘 알려진 취약점을 공격하는데 유용하게 악용될 수 있으며, 인터넷 웜과 같은 자동화된 공격에서도 이러한 banner 정보가 사용되어지기도 한다. 따라서 공격자에게 웹서버의 버전과 같은 banner 정보를 숨기는 것이 안전하다.
- Apache 웹서버에서는“ServerTokens”지시자를 수정함으로써 헤더에 의해 전송되는 정보를 바꿀 수 있다.
| 정의방법: ServerTokens Minimal|ProductOnly|OS|Full |
- ServerTokens 지시자를 이용하여 설정할 수 있는 각 키워드와 표시되는 헤더 정보는 다음
과 같다.
| 키워드 |
제공하는 정보 |
예 |
| Prod[uctOnly] |
웹서버 종류 |
Server: Apache |
| Min[imal] |
Prod 키워드 제공 정보 + 웹서버 버전 |
Server: Apache/1.3.0 |
| OS |
Min 키워드 제공 정보 + 운영체제 |
Server: Apache/1.3.0 (Unix) |
| Full |
OS 키워드 제공 정보 +
설치된 모듈(응용프로그램) 정보 |
Server: Apache/1.3.0 (Unix)
PHP/3.0 MyMod/1.2 |
- 공격자를 속이기 위해서 서버의 헤더 정보를 앞에서 명기한 내용과는 전혀 다른 내용으로 조작하여 클라이언트에 보낼 수도 있는데 이를 위해서는 Apache 소스코드를 수정한후 재컴파일하여야 한다.
마. 사용자 인증
(1). 사용자 인증의 종류
① 기본 사용자 인증(Basic Authentication)
● 기본 사용자 인증은 Apache에서 제공되는 htpasswd를 이용하여 사용자 계정을 생성하고 인증하는 방법이다.
● 패스워드가 암호화되어서 저장되지만 클라이언트에서 서버로 전송되는 도중에는 암호화되지 않아 전송 중 노출될 수 있다.
② 다이제스트 사용자 인증(Digest Authentication)
● 기본 사용자 인증과 마찬가지로 Apache에서 제공되는 htpasswd를 이용하여 사용자 계정을 생성하고 인증하는 방법이다.
● 기본 사용자 인증과의 차이점은 패스워드를 MD5 암호화 해쉬하여 전송하므로 전송중에도 비교적 안전하지만 인증에 사용되는 패스워드만 암호화되고 데이터는 평문으로 전송됨을 주지할 필요가 있다.
③ 어플리케이션에서의 인증(데이터베이스 등 로그인 정보유지)
● 어플리케이션에서의 인증은 Apache에서 제공되는 htpasswd 명령을 이용하지 않고 사용자 이름과 패스워드를 데이터베이스에 저장하고 이를 이용하여 인증하는 방법이다.
● 데이터베이스에 저장된 사용자 계정에 대한 정보는 기업의 보안정책에 따라 다르지만 일반 적으로, 암호화나 단방향 함수(해쉬)등을 적용하여 저장 하는 것이 안전하다. (내부자에 의한 정보유출 방지)
바. 기본 사용자 인증
● 기본 사용자 인증은 크게 다음과 같은 두가지 절차로 설정할 수 있다.
(1) 패스워드 파일 생성
- 아파치 설치시 제공되는 htpasswd 명령을 이용하여 패스워드 파일을 생성한다. htpasswd 파일의 사용법은 다음과 같다.
| 사용법: htpasswd [-cmdps] passwordfile username |
- 패스워드 파일을 최초로 생성할 경우에는 -c 옵션을 사용하여 새로운 패스워드 파일을 만든다.
[root@hcjung bin]# ./htpasswd -c /usr/local/apache/passwords hcjung
New password:
Re-type new password:
Adding password for user hcjung |
- 이후, 새로운 사용자를 추가하고자 할 경우에는 -c 옵션을 빼고 사용하면 된다. 실수로 -c 옵션을 줄 경우 기존에 등록된 사용자들이 지워지므로 주의하여야 한다.
| [root@hcjung bin]# ./htpasswd /usr/local/apache/passwords webmaster |
- 생성된 패스워드 파일은 가능한 안전한 장소에 보관하고 웹서버 자체가 읽을 수 있는 최소한의 권한만을 주어야만 한다. 만일 웹서버가 nobody 사용자와 nobody 그룹으로 구동된다면 다음과 같이 소유권과 접근권한을 줄 수 있다.
[root@hcjung bin]# chown root.nobody /usr/local/apache/passwords
[root@hcjung bin]# chmod 640 /usr/local/apache/passwords |
(2) 패스워드 파일을 사용가능하도록 환경설정
- 패스워드 파일의 생성이 끝났으면 Apache 웹서버에게 이 파일을 사용할 수 있도록 설정하여 주어야 한다.
- 먼저 각 디렉토리별로 사용자 인증을 하기 위해서 httpd.conf 파일 내의 AllowOverride 지시자의 옵션을 None에서 AuthConfig 또는 All로 바꾼다.(사용자 인증만을 위해서는 AuthConfig 사용을 권고)
그리고, 사용자 인증이 필요한 디렉토리에 다음의 지시자들이 포함된 .htaccess 파일을 생성 한다.
| 옵션값 |
설명 |
| AuthType |
인증 형태(Basic 또는 Digest) |
| AuthName |
인증 영역(웹 브라우저의 인증창에 표시됨) |
| AuthUserFile |
사용자 패스워드 파일의 위치 |
| FollowSymLinks |
심볼릭 링크로의 이동을 가능하게 함 |
| AuthGroupFile |
그룹 파일의 위치(옵션) |
Require
|
접근을 허용할 사용자 또는 그룹 정의
ex)
Require user userid [userid] ...
Require group group-name [group-name] ...
Require valid-user |
앞서 패스워드 파일에 등록된 hcjung와 webmaste만이 웹서버에 접속 할 수 있도록 하기 위해서는 다음과 같이 설정할 수 있다.
[root@hcjung /root]# cd /usr/local/www
[root@hcjung www]# vi .htaccess
AuthType Basic
AuthName“ Welcome HyunCheol’s Home”
AuthUserFile /usr/local/apache/passwords
Require user hcjung webmaste |
- 위에서 접근을 허용할 사용자를 hcjung와 webmaster로 한정을 했는데 패스워드 파일에 등록된 모든 사용자들이 접근할 수 있도록 하기 위해서는 사용자를 지정하는 대신“Require valid-user”라고 하면 된다.
- 정상적으로 사용자 인증 설정이 완료되었을 경우 웹 브라우져에서 웹서버 접속시 다음과 같은 사용자 이름과 암호를 묻는 인증창이 뜨게 된다.
- 사용자 이름과 암호가 정확하게 입력된 경우는 웹 페이지 접속이 가능하지만 정확하지 않을 경우 다음과 같은 경고창이 뜨고 접속을 허가하지 않는다.
사. SSL 인증서 또는 웹 암호화 솔루션의 적용
● 웹을 통하여 회원신상, 금융거래, 카드번호 등 데이터의 기밀성이 요구되는 데이터가 전송된다면 SSL을 적용하거나 기타 웹 암호화 제품의 적용을 고려하여야 한다.
● Apache에서는 mod-ssl을 이용하여 SSL 암호화를 적용할 수 있다.
● SSL의 적용은 기본적으로 OpenSSL을 이용한 Apache용 SSL모듈(apache/mod-ssl)을 이용하여 생성한 자체 SSL 인증서를 이용할 수도 있고, 유료로 제공되는 SSL인증서를 이용할 수 도 있다.
● 자체 SSL인증서와 유료 인증서 방식의 차이점은 접속하는 사용자 관점에서 해당 사이트가 정말로 그 사용자가 믿고(알고)있는 웹 사이트인지 여부에 대하여 제3자(인증기관)이 보증해 주느냐 안해주느냐의 차이다. 데이터에 이용되는 암호화 수준은 알고리즘과 키길이와 관련되므로 별개의 문제이다.
아. 보안 패치
● Apache설치후 버전별로 발견된 취약점은 ApacheWeek (http://www.apacheweek.com/security/) 에서 확인할 수 있다.
● 가능한 주기적으로 보안 패치정보를 확인후 조치하여야 한다. Apache 웹서버 관련 취약점에 대한 패치는 http://www.apache.org/dist/httpd/patches/ 에서 다운받을 수 있다.
자. 설정파일 및 데이터 백업
● 초기 서버 설정 파일들과 이후의 기본적인 설정파일들은 일반에 공개되거나 다른 변화가 일어나기 전에 백업해서 보관되어져야 한다. 또한 시스템 설정이 변경될 때마다 이력관리가 필요하고 다수의 수정이 있을 경우에는 반드시 백업을 하도록 한다.
● 주요 백업 데이터는 다음과 같은 것이 있다.
- 아파치 각종 환경설정 파일
- 아파치 설치과정에 사용된 Install 파일(경우에 따라 Rebuild에 많은 시간을 단축할 수
있음)
- 사용자 프로그램 소스(PHP, JSP, CGI등)
- 웹서비스와 관계된 데이터 베이스 등
차. 로그 설정 및 분석
● 아파치는 두 개의 로그 파일을 사용하는데, 에러 로그와 액세스 로그이다. 에러 로그는 아파치 서버의 에러 정보를 기록하고, 액세스 로그는 아파치 서버가 처리하는 모든 요청에 대한 정보를 기록한다.
● 로그 파일의 위치는 httpd.conf 파일에서 지정한다.
#
# ErrorLog : The location of th error log file
# if you do not specify an ErrorLog directive within a
# container, error messages relating to that virtual host will be
# Logged herer. if you *do*define an error logfile for a
#container, that host's errors will be logged therer and not here.
#
ErrorLog/var/log/httpd/error_log
#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a
# container, they will be logged here. Contrariwise, if you *do*
#define per-access logfiles, transactions will be
# logged therein and *not*in this file.
Custom Log/var/log/httpd/access_log common |
(1) 에러 로그
● 에러 로그 파일의 포맷은 비교적 자유로운 형식인데, 대부분의 경우 다음과 같은 정보가 포 함된다.
| [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration:/ export/home/live/ap/htdocs/test |
① 메시지의 날짜와 시간
② 에러의 위험도
③ 에러를 발생시킨 클라이언트의 IP주소
④ 에러 메시지의 내용 (클라이언트가 요청한 문서를 파일 시스템 경로로 표현)
● 에러 로그 파일에 기록될 에러의 위험도 수준은 다음과 같이 httpd.conf파일에서 LogLevel 지시자를 이용하여 지정할 수 있다.
#
# LogLevel:control the number of messages logged to the error_log
# Possible values include: debug, info, notice, warn, error, crit.
# alert, emerg.
#
LogLevel error |
(2) 엑세스 로그
● 액세스 로그는 서버가 처리하는 모든 요청에 대한 정보를 기록한다. 액세스 로그의 위치와 로그 포맷은 CustomLog 지시자를 통해 지정된다. LogFormat 지시자를 이용해서 다양한 로그 포맷을 만들어 놓고, 간단하게 선택하여 사용할 수 있다.
● 액세스 로그로 사용되는 공통적인 로그 포맷은 Common Log Format(CLF)과 Combined Log Format(CLF)이다.
가) Common Log Format(CLF): 많은 다른 웹 서버에서도 동일하게 생성되는 포맷이고, 많은 로그 분석 프로그램이 읽을 수 있는 포맷이다. httpd.conf 파일에서 다음과 같이 설정할 수 있다.
LogFormat "%h %1 %u %t \" %\" %>s %b" common
CustomLog logs/access_log common |
● LogFormat 지시자는 하나의 포맷 스트링을 정의하고 common이라는 닉네임을 붙인다.
CustomLog 지시자는 로그가 저장될 파일의 위치와 이름, 그리고 저장될 로그의 포맷을 정 의한다.
● 이 포맷에 의해 생성된 로그는 다음과 같다.
| 172.16.5.100 - jun [ 08/Apr/2003:16:03:43 + 0900] "GET / php HTTP/1.1"301 |
① 클라이언트의 IP 주소(%h) HostnameLookups이 On으로 설정되어 있으면 IP주소 대신 호 스트네임을 찾아서 저장한다(이 설정으로 서버가 크게 느려질 수 있기 때문에 가능하면 사용 하지 않도록 한다).
② 클라이언트의 identity(%l) 클라이언트 컴퓨터의 identd에 의해 결정된 클라이언트 identity. IdentityCheck가 On으로 설정되어 있지 않으면 이 정보를 찾지 않는다(이 설정으로 서버가 느려질 수 있고, identity 정보도 신뢰하기 어렵기 때문에 가능하면 사용하지 않도 록 한다).
③ HTTP 인증을 받은 사용자의 ID(%u) 인증을 받지 못한 경우에(상태 코드가 401인 경우) 이값은 부정확하다. 또한 요청받은 문서가 인증을 요구하지 않는 경우에는 -로 표시된다.
④ 서버가 요청 처리를 끝낸 시간(%t) [일/월/년:시:분:초 지역]
⑤ 클라이언트의 요청 내용(\ %r\ ) 사용한 메소드, 요청한 자원, 사용한 프로토콜
⑥ 상태코드(%>s) 서버가 클라이언트에게 보낸 상태 코드. 2XX(성공), 3XX (redirection), 4XX(클라이언트에 의한 에러), 5XX(서버에 의한 에러). 상세한 상태 코드는 부록을 참고한다.
⑦ 클라이언트에게 전송된 컨텐츠의 크기 response header 부분은 포함되지 않는다. 클라이언트에게 전송된 컨텐츠가 없으면 이 값은 -로 표시된다.
나) 다음은 Combined Log Format :
● httpd.conf 파일에서 다음과 같이 설정할 수 있다.
LogFormat "%h %l %u %t \"%r\" %>s %b \"% {Referer}i\" \"%{User-agnet}i\"" combined
CustomLog log/acces_log combined |
● 이 포맷은 두 개의 필드를 제외하면 Common Log Format과 동일하다. 추가된 필드는 퍼센트 지시자 %{header}i를 사용하고 있는데, header는 HTTP request header 중 일부가 될 수 있다. 이 포맷에 의해 생성된 로그는 다음과 같다.
172.16.5.100 - jun [ 08/Apr/2003:16:03:43 + 0900] "GET / php HTTP/1.1"301
313 "-" "Mozilla/4.0 (compatible: MSIE 6.0: Windows NT 5,0)" | ① 클라이언트가 요청한 자원이 include되었거나 링크된 페이지(\ %{Referer}I\) 위 예제에 서는 그러한 페이지가 없음
② 클라이언트 브라우저에 대한 정보(\ %{User-agent}I\)
다) 로그 설정시 유의사항
● 아파치는 대부분의 경우 root권한으로 로깅을 수행하는데, 시스템사용자는 아파치의 로그 파일을 다른 중요 시스템 파일에 대한 링크로 대체하여, root 권한으로 다른 중요 시스템 파일의 내용을 변경할 수 있다.
● 따라서, 일반사용자는 로그가 저장되는 디렉토리에 대해 쓰기 권한이 없도록 설정해야 한다.
● 또한 로그 파일에 클라이언트가 제공하는 데이터가 들어갈 경우 악의적인 클라이언트가 제어 문자 등을 로그 파일에 삽입하여 웹 서버를 침해할 수 있다. 특히 클라이언트가 웹 서비스를 통해서 아파치의 로그 파일을 볼 수 없도록 해야 한다.
출처 -한국정보보호진흥원 사이버안전메뉴얼 중
|
|
