일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Eclipse
- 자바
- html
- 코드이그나이터
- JavaScript
- SQL
- Oracle
- java
- codeigniter
- 오라클
- jquery
- 주식 청약
- 주식
- 주식 청약 일정
- 공모주 청약 일정
- css
- 리눅스
- linux
- IPO
- MYSQL
- php
- 7월 공모주 청약 일정
- 공모주 청약
- 6월 공모주 청약 일정
- Stock ipo
- 자바스크립트
- 제이쿼리
- Stock
- 맥
- 공모주
- Today
- Total
개발자의 끄적끄적
[was] apache 보안 설정 본문
[was] apache 보안 설정
:: Apache 설치 후 보안설정 ::
- No1. httpd.conf - 보안관련사항 설정
Apache 웹서버는 httpd.conf 파일에서 웹서버 구동과 관련된 다양한 설정을할수있다. 웹서버 포트 지정, 사용자 및 그룹 지정 등을 비롯해서 보안과 관련한 설정들도 여기서 제어할 수 있다. httpd.conf 수정 후에는 설정파일의 문법오류를 점검한 다음 변경된 내용을 반영하기 위해 웹 데몬을 재가동하여야한다.
[root@to root]# /usr/local/apache/bin/./httpd -t
Syntax OK
[root@to root]# /usr/local/apache/bin/./apachectl restart
/usr/local/apache/bin/./apachectl restart: httpd restarted
가. 디렉토리 리스팅, 심블릭 링크, SSI 기능, CGI 실행
■ 디렉토리 리스팅
웹 브라우저에서 사용자가 URL을 입력했을 경우, Apache 웹서버는 3가지 방법 응답한다. 정상적으로 웹 내용을 보여주든지, 디렉토리 리스트를 보여주든지, 에러 메시지를 보여준다.
원격의 공격자가 시스템에 대한 많은 정보를 획득할수록 보안 허점을 발견하기가 용이해 진다. 디렉토리 리스트를 보여주는 것 또한 불필요한 정보를 공격자에게 제공하여 공격에 이용될 수 있다. 백업 데이터, CGI 소스코드들, 필요에 의해 만들어놓은 심블릭 링크 등 서버 관리자가 실수로 지우지 않은 파일들이 공격자의 손에 들어갈 수 있다. DocumentRoot 디렉토리 내의 모든 파일들이 리스팅되는 것을 방지하기 위해서 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 실행은 Script-xsAlias 지시자에 의해서 실행가능한 디렉토리를 제한할 수 있다. Script-xsAlias 지시자 문법은 다음과 같다.
Syntax : Script-xAlias URL-pathfil - path | directory-path
예를들어 cgi-bin이라는 디렉토리에서만 실행가능하도록 할 경우 다음과 같이 지정할 수 있다.
Script-xAlias /cgi-bin/ "/usr/local/apache/cgi-bin/ "
Options 지시자에서 사용할 수 있는 옵션값은 다음 표와 같다.
ALL : MultiViews를 제외한 모든 옵션을 줌 (default 설정값임)
None : 옵션을 주지 않음
ExecCGI : CGI 프로그램 실행을 가능하게 함
FollowSymLinks : 심볼릭 링크로의 이동을 가능하게함
Includes : Server Side Includes를 가능하게함
IncludesNOEXEC: Server Side Includes는 가능하지만 CGI 스크립트나 프로그램들은 실행할 수 없도록 함.
Indexes : 해당 디렉토리안에 DirectoryIndex에 명기된 파일(index.html등)이 없을 경우 디렉토리와 파일목록을 보여줌
Multiviews : 유사한 파일이름을 찾아 주는 기능을 실행함(예를들어 index라고만 입력하더라도 index.*를 찾아 보여줌)
DocumentRoot 디렉토리에서 다음과 같이 설정되어 있다고 하자.
<Directory "/usr/local/apache/htdocs/list">
Options Indexes FollowSymLinks
</Directory>
이 경우 다음 그림과 같이 DirectoryIndex에 정의된 초기 파일(index.html)이 존재하지 않을 경우 디렉토리내의 파일목록을 리스트업 해준다.
- 그림 1.
또한, FollowSymLinks로 인해 /etc/passwd 에 심블릭 링크된 파일(ln -s /etc/passwd link.txt)을 열었을 경우 DocumentRoot 디렉토리 상위의 passwd파일의 열람이 가능함을 알 수 있다.
- 그림 2.
이러한 문제점을 제거하기 위해서는 Indexes 옵션과 FollowSymLinks 옵션을 제거하고, IncludesNoExec 옵션을 사용하도록 한다.
<Directory /usr/local/apache/list>
Options IncludesNoExec
</Directory>
이 경우 다음과 같이 초기 파일(index.html)이 존재하지 않을 경우 디렉토리 리스트를 보여주는 것이 아니라 오류 창을 띄워주는 것을 확인할 수 있다. (403에러)
-그림 3.
- ServerSignature Off : 웹브라우저 Not found시에 웹서버의 정보가 누출됨을 막을 수 있다.
- 그림 4.
나. PUT과 POST의 제한
원격 사용자는 DocumentRoot 디렉토리 구조에 파일을 업로드 하거나 수정하는 행위가 제한되어야 한다. 물론 DocumentRoot의 파일/ 디렉토리 퍼미션을 사용해서도 웹을 통한 파일 업로드 및 수정을 막을 수는 있다. 하지만, 적절한 제한이 이루어지지 않을 경우 홈페이지가 변조되거나 웹 사이트가 침해당할 수 있으므로 <Limit>태그를 이용하여 각 디렉토리별로 HTTP Method의 사용여부를 통제할 수 있다. 파일 업로드 및 파일의 수정을 위해서 사용되는 HTTP Method는 PUT과 POST이다.
사용시 주석문 해재하고 적절히 수정한다.
#<Directory /home/*/public_html>
# AllowOverride FileInfo AuthConfig Limit
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
# <Limit GET POST OPTIONS PROPFIND>
# Order allow,deny
# Allow from all
# </Limit>
# <LimitExcept GET POST OPTIONS PROPFIND>
# Order deny,allow
# Deny from all
# </LimitExcept>
#</Directory>
다. 헤더 정보 숨김
클라이언트가 Apache웹서버에 접속했을때 웹서버에서는 응답 메시지의 헤더에 웹서버 버전,설치된 응용프로그램 등과 같은 정보를 전달한다.
- ServerTokens Full(default)
[root@to root]# telnet to.esom.net 80
Trying 218.238.43.8...
Connected to to.esom.net (218.238.43.8).
Escape character is '^]'.
GET / HTTP/ 1.1
HTTP/1.1 400 Bad Request
Date: Wed, 25 Dec 2002 09:29:31 GMT
Server: Apache/1.3.27 (Unix) PHP/4.2.1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
..........
</HTML>
Connection closed by foreign host. : 아파치,php의 정보가 출력됨을 알 수 있다.
- ServerTokens Prod 설정후
HTTP/1.1 400 Bad Request
Date: Wed, 25 Dec 2002 09:24:17 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
.........
</HTML>
Connection closed by foreign host. : 서버정보가 표시되지 않음을 알 수 있다.
ServerTokens 지시자에서 설정할 수 있는 각 키워드에 의해 나타나는 정보와 형식.
Syntax : ServerTokens Minimal|ProductOnly|OS|Full
ServerTokens 옵션은 아파치 1.3 이후 버젼에서 사용할수 있으며, ProductOnly 키워드는 1.3.12 이후 버젼에 추가되었다.
일반적으로 ServerToken은 httpd.conf에서 명시되어있지않는경우가 많은데 이럴 경우에는 기본값인 ServerTokens Full이 적용되어 운영체제 정보, 웹서버 정보, 버전정보, 설치된 모듈정보등이 모두 서버의 응답 헤더에 포함되어 클라이언트에게 전송된다. 최소한의 정보를 주기 위해서 ServerTokens Prod를 설정하는 것이 바람직하다.
ServerTokens Prod[uctOnly] : Apache만 보여줌
Min[imal] : Apache 버젼만 보여줌
OS : 아파치 버젼과 운영체제를 보여줌
Full (또는 지시하지 않았을때) : 모두보여줌
- No2. 사용자 인증 및 접근통제
가. 사용자 인증의 종류
■ 기본 사용자 인증
HTTP는 stateless 프로토콜이므로 기본적인 사용자인증에 의해 보호되는 자원에 접근하기 위해서는 매번 사용자 이름과 패스워드와 같은 인증서를 서버에 보내야만 한다. 하지만 초기 인증을 거친 후 다른 페이지에 접근하기 위해서 매번 사용자 이름과 패스워드를 서버에 전송하는 것은 일반적으로 클라이언트 소프트웨어나 웹 브라우져에 의해서 자동으로 이루어진다. 만약 사용자 이름이 웹서버의 리스트에 있고, 패스워드가 일치하면 보호된 자원에 접근을 허락받게 된다.
기본적인 인증에서는 패스워드가 암호화되어서 저장되지만 클라이언트에서 서버로전송되는 도중에는 암호화되지 않아 제3자에 의해서 도청될 수 있다. 보호된 자원에 접속하는 매 순간마다 ID와 패스워드가 전송되므로 telnet, ftp 등 인증을 하는 다른 서비스보다 쉽게 도청이 가능하다. 뿐만 아니라 서버에서 클라이언트로 전송되는 어떠한 데이터에 대해서도 암호화가 제공되지 않으므로 내용도 가로채기가 용이하다. 따라서 기밀성이 중요시되는 웹서버에서는 이러한 인증은 권장할 수 없다.
■ 다이제스트 사용자 인증
두 번째 인증 방법으로는 다이제스트 인증이 있는데 기본적인 인증과의 차이점은 네트워크 등 전송로 상에서 패스워드가 평문으로 전송되지 않는다는 점이다. 패스워드는 MD5 암호화 해쉬를 시킨 후 전송한다. 다이제스트 인증은 패스워드를 암호화해서 전송하고는 있지만 데이터는 평문으로 전송되므로 문제점을 가지고 있고, 또한 모든 웹브라우져가 다이제스트 인증을 지원하지는 않는다는 문제점이 있다.
■ DB 인증 모듈
DB 인증 모듈은 사용자 이름과 패스워드를 보다 신속하게 확인할 수 있도록 한다. 서버에 다수의 사용자 이름과 패스워드가 저장되어 있을 경우 사용자가 데이터에 접근하기 위한 인증과정에 많은 시간이 소모될 수 있다. 일반 파일 시스템이 아닌 DB를 이용할 경우 사용자 이름과 패스워드 확인 시간을 대단히 단축할 수 있다.
나. 기본 사용자 인증 설정
기본 사용자 인증과 다이제스트 사용자 인증의 설정 방법은 대단히 유사한데 다음과 같은 절차를 거쳐서 설정할 수 있다.
- 패스워드 파일 생성
- 패스워드 파일을 사용할 수 있도록 Apache 환경 설정
일반적으로 많이 사용되고 있는 기본 사용자 인증 설정 절차에 대해서 살펴보기로 한다.
① 패스워드 파일 생성
/usr/local/apache/bin/htpasswd 명령을 이용하여 패스워드 파일을 생성한다.
Usage : htpasswd [- cmdps ] passwordfile username
패스워드 파일을 최초로 생성할 경우에는 -c 옵션을 사용하여 새로운 패스워드 파일을 만든다.
[root@to bin]# ./htpasswd -c /usr/local/apache/htdocs/list/passfile simon
New password:
Re-type new password:
Adding password for user simon
이후 새로운 사용자를 추가하고자 할 경우에는 -c 옵션을 빼고 사용하면 된다. 실수로 -c 옵션을 줄 경우 기존에 등록된 사용자들이 지워지므로 주의하여야 한다.
② 패스워드 파일을 사용가능하도록 환경설정
패스워드 파일의 생성이 끝났으면 Apache 웹서버에게 이파일을 사용할 수 있도록 설정하여 주어야 한다.
먼저 각 디렉토리별로 사용자 인증을 하기위해서 httpd.conf 파일내의 AllowOverride 지시자의 옵션을 AuthConfig 또는 All로 바꾼다. (사용자인증만을 위해서는 AuthConfig 사용을 권고)
<Directory /usr/local/apache/htdocs/list>
AllowOverride AuthConfig
</Directory>
사용자 인증이 필요한 디렉토리에 다음의 지시자들이 포함된 .htaccess 파일을 생성한다.
AuthType : 인증형태 (Basic 또는 Digest)
AuthName : 인증영역(웹브라우저의 인증창에 표시됨)
AuthUserFile : 사용자 패스워드 파일의 위치
AuthGroupFile : 그룹 파일의 위치(옵션)
Require : 접근을 허용할 사용자 또는 그룹의 정의
등록자만이 접속할수 있도록 .htaccess파일을 생성한다.
[root@to bin]# cat /usr/local/apache/htdocs/list/.htaccess
AuthType Basic
AuthName "Welcome, Please Login"
AuthUserFile /usr/local/apache/htdocs/list/passfile
<Limit GET POST>
require valid-user
</Limit>
- 그림 5.
입력한 정보가 일치하지 않으면 오류페이지가 출력된다.
Authorization Required
This server could not verify that you are authorized to access the d0cument requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
다. 접근통제
클라이언트가 사용하는 호스트의 IP 주소나 도메인에 의해서 웹서버의 데이터에 대한 접근을 통제할 수 있다. 기본적인 서버 설정은 DocumentRoot의 내용에 대해 누구나 접속을 허락하도록 설정되어 있다. Apache의 Allow 와 Deny 지시자는 사용자 시스템의 호스트 이름과 호스트 주소를 근간으로 접속을 허락 또는 차단할 수 있도록 지정할 수 있다. 또한, Allow와 Deny 지시자를 동시에 사용할 경우 그 순서를 정하는 Order 지시자를 사용하여 보다 정교한 정책설정을 할 수 있다.
Order Deny,Allow : Deny 지시자가 Allow 지시자 보다 먼저 검사된다. 접근은 기본적으로 허용된다. 즉,Deny 지 시자나 Allow 지시자에 일치하지 않는 클라이언트의 접속은 허용한다.
Order Allow,Deny : Allow 지시자가 Deny 지시자 보다 먼저 검사된다. 접근은 기본적으로 차단된다. 즉, Deny 지 시자나 Allow 지시자에 일치하지 않는 클라이언트의 접속은 차단한다.
Order Mutual-failure : Allow 리스트에 있고 Deny 리스트에 없는 호스트만 접근을허용한다. 순서는 Allow,Deny 때와 같다.
[root@to bin]# cat /usr/local/apache/htdocs/list/.htaccess
AuthType Basic
AuthName "Welcome, Please Login"
AuthUserFile /usr/local/apache/htdocs/list/passfile
order deny,allow
deny from all
allow from 218.238.43
<Limit GET POST>
require valid-user
</Limit>
218.238.43.1~255 이외의 아이피소유자는 접속할 수 없다.
라. 권한부여(Authorization)
권한부여는 특정한 자원에 접근할 사용자 퍼미션이 유효한지를 확인하는 과정이다. 어떤 퍼미션에 의해 허락되고 거부될지는 자원과 그 자원과 관련된 규칙들에 따라서 대단히 다양하다. 각 파일과 디렉토리 구조는 다른 접근통제나 사용자 인증 방법을 가질 수 있다. 접근통제와 사용자 인증 방법을 사용하여 각 자원에 대한 다양한 권한을 부여할 수 있다. 가령 인터넷에서 접속시에는 사용자 이름과 패스워드를 확인하고 인트라넷에서 접속시에는 요구하지 않도록 설정할 수도 있다. 이는 Satisfy " 지시자를 통해서 구현할 수 있다. 즉, Satisfy " 지시자는 사용자 인증(Requ ire에 의한)과 클라이언트 호스트 주소에 따른 접근통제(Allow에 의한)를 동시에 사용하여 정책설정을 할 때쓰인다.
Syntax : Satisfy any|all
다음은 인트라넷 밖에서의 모든 접속시 패스워드를 요구하고 인트라넷 내부의 사용자들은 패스워드 없이 접속을 허용하도록 설정한 예이다.
[root@to bin]# cat /usr/local/apache/htdocs/list/.htaccess
AuthType Basic
AuthName "Welcome, Please Login"
AuthUserFile /usr/local/apache/htdocs/list/passfile
order deny,allow
deny from all
allow from 211.209.107 <- 저의집 ip대역.
require simon
Satisfy Any
마. SSL/TLS 인증
앞서 살펴본 사용자 인증기법들은 모두 웹 컨텐츠를 암호화하지는 않는다는 단점이 있었다. 최근 인터넷 뱅킹등과 같이 전송로상에 전송되는 웹 컨텐츠 역시 보호되어져야 하는 경우가 많다.
SSL/TLS는 사용자인증과 웹서버 데이터와 컨텐츠를 암호화하는 훌륭한 수단이다. SSL을 지원하기 위해서 Apach e는 Mod_SSL 모듈을 가지고 있고, 이 모듈은 SSLv2,v3 그리고 새로운 TLS을 사용하는 강력한 암호화를 제공한다. 현재 이 모듈은 강력한 128bit 암화화와 RSA와 Diffie-Hellman 암호화를 제공한다. 하지만, 최근 Apache Op enSSL 버퍼오버플로우 취약점을 이용한 Apache/mod-ssl웜(또는 Slapper 웜으로도 불림)으로 인해 많은 Ap ache 웹서버들이 공격당하고 있으므로 OpenSSL 버전 0.9.6e을 사용하여야 한다.
다음은 SSL 프로토콜이 제공하는 주요 기능이다.
- 사설 접속과 데이터 암호화
- 서버에 통신하는 단말 인증
- 신뢰된 접속
최초 핸드쉐이크 후에 SSL은 비밀키를 생성하고 이 대칭키 암호화가 데이터 암호화를 위해 사용된다. 공개키(비대칭키)는 단말의 신원 인증과 대칭키 교환에 사용된다. 메시지 무결성은 MAC(Message Auth entication Code)에 의해 제공되고 신뢰된 접속을 가능하게 한다.
- No3. 운영관리
가. 로그관리
Apache 로그파일들은 기본적으로 /usr/local/apache/logs 디렉토리에 저장된다.
기본 설치시에는 access_log와 error_log 2개의 로그파일이 생성된다.
(1) access_log
access_log는 서버에서 처리된 모든 요청들의 기록을 가지고 있다. access_log의 위치와 로그 포맷은 "Cu stomLog" 지시자에 의해 정의된다.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /usr/local/apache/logs/access_log common
사용자 접속을 기록할 로그 포멧을 정의한 부분이다. 위와 같이 4가지 형식의 로그 포멧이 기본적으로 설정되어 있다.
common : 가장 일반적인 로그 기록
referer : 현재 아파치 서버에 접속하기 전에 머물렀던 URL으 기록한다.
agent : 접속자의 웹 브라우저(OS 포함) 종류를 기록한다.
combined : 위의 3가지 로그 포멧을 모두 조합한 것이다.
접속자에 대한 많은 정보를 기록하길 원한다면 combined으로 설정하면 된다.
8개의 필드로 구성
- 클라이언트 IP 주소
- 유일한 개인 ID(클라이언트의 ident 값)
- 사용자 이름(사용자 인증을 거친 경우 사용자 이름)
- 날짜
- Method (GET, PUT, POST 등)
- URI(Uniform Resource Identifier)
- HTTP 상태
- 전송된 바이트 수
다음은 access_log의 예이다.
218.54.113.162 - - [25/Dec/2002:20:30:51 +0900] "GET /~simon/bbs/zboard.php?id=september HTTP/1.1" 200 12495
211.209.107.153 - - [25/Dec/2002:20:40:41 +0900] "GET /list HTTP/1.1" 401 409
211.209.107.153 - simon [25/Dec/2002:20:40:46 +0900] "GET /list HTTP/1.1" 401 409
211.209.107.153 - simon [25/Dec/2002:20:40:49 +0900] "GET /list HTTP/1.1" 401 409
웹서버 로그는 운영체제 로그와 더불어서 주기적으로 검사하여야 한다. 검사시에 다음 사항들을 점검하도록 한다.
- 유효하지 않은 로그인 시도
- 제한된 필드에 대한 접속 시도
- 존재하지 않는 파일에 대한 접속 시도
- 허락되지 않은 PUT(업로드) 시도
- 단기간 동안의 동일한 IP 주소로 부터의 대량 접속 시도(서비스거부)
- 웹서버의 예기치 못한 종료와 시작
아이템 의미
Host : 클라이언트의 호스트이름이나 IP Address
Ident : IdentityCheck 가 enable 되어 있고, 클라이언트가 ident 에 응답을 보내면 identity 정보를 남기게 되며, 보통은 “-“로 대체된다.
Authuser : 인증이 있을 경우 여기에 사용자 이름이 기록되게 되며, 그렇지 않을 경우 “-“ 로 대체된다.
Date : 접속한 시간과 날짜를 나타내며, 포맷은 다음과 같다 :
날짜포맷 = [day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
Request : 클라이언트가 요청한 자료
Status : 요청한 것에 대한 서버의 처리사항으로 상태 코드라 한다.
Bytes : 헤더를 제외한 전송된 Byte 양
(2) error_log
Apache 웹서버의 진단정보 및 요청 처리과정에서 발생되는 각종 에러에 대한 기록을 남기는 error_log는 ErrorLog 지시자에 의해서 위치와 이름이 정해진다. 비정상적인 웹서버의 종료 등과 같은 문제가 발생되었을 경우 가장 먼저 error_log의분석이 필요하다.
설정을 변경하여 웹서버를 테스트할 때에는 다음 명령으로 error_log의 내용을 실시간으로 모니터링할 수 있다.
[root@to logs]# tail -f /usr/local/apache/logs/error_log
[Wed Dec 25 21:24:56 2002] [notice] Apache/1.3.27 (Unix) PHP/4.2.1 configured -- resuming normal operations
[Wed Dec 25 21:24:56 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
error_log는 아래와 같이 4개의 필드로 구성되어 있다.
- 메시지의 날짜와 시간
- 보고된 에러의 심각성 수준
- 에러를 발생시킨 클라이언트의 IP 주소
- 에러 메시지 내용(대단히 다양함)
기본 설정상태의 httpd.conf에서는 error_log와 관련하여 다음과 같이 되어 있다.
ErrorLog /usr/local/apache/logs/error_log
LogLevel warn
LogLevel 지시자는 에러로그에 어느정도 이상의 심각성이 있을 경우 로그를 남길 것인지를 지정할 수 있는데, 일반적인 유닉스 시스템의 syslog와 마찬가지로 디버그(debug), 정보(info), 주의(notice), 경고(warn), 에러(error), 비판(crit), 경계(alert), 비상(emerg) 중 하나를 선택할 수 있다. debug는 심각성이 가장 낮은 수준의 로깅이며 emerg는 심각성이 가장 높은 수준의 로깅을 의미한다. LogLevel을 debug로 지정할 경우 대단히 사소한 내용도 기록되므로 로그의 량이 대단히 방대해 질 수 있으므로 적정한 수준에서 기록하도록 하여야 한다.
나. 보안 패치
앞서 살펴본 웹 서버 관리자에 의한 환경 설정상의 문제점으로 인한 공격 가능성과 더불어 웹서버 자체 또는 웹서버에서 사용하는 애플리케이션 프로그램의 버그로인한 공격도 심각하다. 특히, 요즘 극성을 부리고있는 인터넷 웜의 경우 각 서버에 공통적인 취약점을 찾아서 공격하므로 웹서버에 대한 보안 패치는 수시로 이루어져야만 한다.
최근 Chunked encoding 취약점, Open SSL 취약점 등 서비스 거부공격 뿐만 아니라 임의의 명령어 실행까지 가능한 다수의 취약점이 발견되었다.
버전별로 발견된 취약점은 ApacheWeek (http://www.apacheweek.com/security/)에서 확인할 수 있다.
웹서버의 보안 취약점은 Nessus,Whisker 등과 같은 공개 취약점 점검 도구나 상용취약점 분석 도구를 이용하여 점검하고 조치할 필요가 있다.
Apache 웹서버 관련 취약점에 대한 패치는 아래에서 받아 설치할 수 있다.
Official Patches for publically released versions of Apache : http://www.apache.org/dist/httpd/patches/
다. 설정파일 및 데이터 백업
초기 서버 설정 파일들과 이후의 기본적인 설정파일들은 일반에 공개되거나 다른 변화가 일어나기 전에 백업해서 보관되어져야 한다. 또한 시스템 설정이 변경될 때마다 이력관리가 필요하고 다수의 수정이 있을 경우에는 반드시 백업을 하도록 한다. 설정파일 뿐 아니라 웹 데이터에 대한 백업도 정기적으로 이루어져야 한다. 웹서버의 중요도나 내용의 변화주기에 따라 달라질 수 있겠지만 가능하면 매일 백업을 받는 것이 안전하다. 또한 모든 백업 데이터는 정상적으로 동작될 수 있는지 검증되어져야만하고, 백업 데이터 또한 서비스 중인 웹서버와 동등한 수준의 기밀성을 보장하여야만 한다.
이는 관리자의 실수에 의한 잘못된 설정이나 해킹으로 인해 웹서버가 정상적으로 동작하지 않을 경우 신속하게 복구하는데 많은 도움을 줄 수 있다.
- No.4 보안관련 퍼미션 설정
가. 서버관리자용 명령어 퍼미선 설정
일반적으로 서버를 처음설치하고 나면 아래에서 설명드리는 대부분의 명령어들은 일반사용자들도 사용할 수 있게 퍼미션되어있는 경우가 많다. 따라서 서버(OS)를 설치한 후에는 보안을 위하여 아래와 같은 명령어들의 퍼미션을 일반사용자들이 사용할 수 없도록 다음과 같이 조정해 주시는 것이 좋다.
chmod 100 /usr/bin/top /usr/bin/w /usr/bin/uptime /usr/sbin/useradd /usr/sbin/userdel /usr/bin/last /bin/ping /usr/bin/find
나. 일반적인 보안파일 퍼미션
chmod 700 /etc/exports /etc/fstab /usr/bin/chage /usr/bin/wall /usr/bin/chfn /usr/bin/write /usr/sbin/usernetctl /bin/mount /bin/umount /sbin/netreport /usr/bin/screen /usr/local/apache /usr/bin/sftp /usr/bin/scp /usr/bin/whereis /usr/bin/which /usr/bin/who /etc/cron* -R
chmod 755 /usr/bin/man
chmod 750 /bin/ps /bin/netstat /bin/dmesg /bin/df /usr/bin/who /usr/bin/finger /usr/bin/last /usr/bin/top /usr/bin/w
chmod 600 /usr/local/apache/conf/httpd.conf
chmod 711 /
chmod 700 /boot /mnt /root
chmod 711 /bin /dev /etc /home /initrd /lib
chmod 711 /misc /opt /sbin /usr /var
chmod 711 /var/log/
SetUID 권한파일 검색후 실행파일로 작성.
- find / -type f -perm -4000 -exec ls -l {} \; > file.sh
- chmod a-s filename or chmod o-x file.sh
file.sh 열어 형식에 맞게 수정후 su, sendmail등 SetUID권한이 꼭 필요한 데몬들을 제외하고 SetUID해제시킨다.
출처: https://yeichan.tistory.com/39 [예슬원준]
'개발 > was & server' 카테고리의 다른 글
[apache] 아파치 VIRTUALHOST 설정 [펌] (0) | 2020.03.27 |
---|---|
[apache] CentOS7 SSL 인증서 설치하기 (0) | 2020.03.24 |
[was] jboss 설치방법 [펌] (0) | 2020.03.19 |
[JBOSS AS 7 팁] eclipse 사용시 jsp 등 자원 변경 즉시 적용 팁 ( auto deploy ) [펌] (0) | 2020.03.11 |
[iis] ssl 인증서(*.pfx) 갱신 [펌] (0) | 2020.03.09 |