'웹서버'에 해당되는 글 41건

  1. 2008.12.30 [웹서버로그] 웹 로그분석의 절대강자는?
  2. 2008.12.30 [WebKnight] 웹나이트 룰 적용 이후 결과와 주저리~ (2)
  3. 2008.12.30 최신 버전으로 구축하는 웹 파이어월, modsecurity
2008.12.30 14:14

[웹서버로그] 웹 로그분석의 절대강자는?

다운로드 :

웹 로그분석은 말그대로 아파치나 IIS 웹 서버들이 남겨놓은 웹 서버 접속 정보를 바탕으로 이를 분석하고 통계를 내어 보기좋게 출력하는 것을 말한다. 오픈소스 OS인 리눅스와 역시 오픈소스 웹서버인 아파치를 많이 사용하는 인터넷 환경에서 웹 로그분석의 중요성은 두말할 필요가 없다 하겠다. 1998년까지만 하더라도 제대로 된 리눅스용 웹 로그분석기가 없어서 기업 시장에 제대로 접근하기가 힘들었지만 요즘에는 적지 않은 웹 로그분석기들이 나와있어 오히려 어떤 걸 선택해야할지 고민해야하는 시점에 이르렀으니 참 격세지감이 아닐 수 없다.

레드햇 리눅스 9에 기본으로 깔려있는 분석기는 웹얼라이저(Webalizer)인데 간단한 기능을 가지고 있어 간편하게 사용할 수 있다. 이보다 훨씬 많은 분석과 통계를 제공하는 소프트웨어로는 AW스테이츠(AWStats)가 있고, 이 중간쯤에서 비주얼한 보고서를 출력하는 것으로는 아날로그(Analog)가 있는데 이 소프트웨어는 비주얼한 보고서를 출력하는 리포트매직(Report Magic)이라는 소프트웨어와 연동해서 움직인다.

여기서는 대표적인 웹로그 분석 오픈소스 소프트웨어인 웹얼라이저와 AW스테이츠, 아날로그+리포트매직을 살펴보도록 하겠다.

1.웹얼라이저 (GPL)

웹얼라이저는 기본으로 설치되어 있거나, 또는 CD만 집어넣어 다시 설치할 수 있는 경우가 많아서 설치한 후에 설정파일만 손보면 비교적 쉽게 사용할 수 있어서 아주 편리하다.

웹얼라이저가 제공하는 기능에는 어떤 것들이 있는지 살펴보자.




(홈페이지: http://www.mrunix.net/webalizer/)

메시지가 한글로 번역된 버전: http://www.oops.org ftp://mirror.oops.org/pub/Linux


공식 사이트에서 소프트웨어를 내려받아도 되고 김정균님이 메시지를 한글로 번역한 소프트웨어를 내려받아 설치할 수도 있다.



(웹얼라이저가 분석하고 통계를 낸 웹 화면1)



(웹얼라이저가 분석하고 통계를 낸 웹 화면2)


웹얼라이저는 C로 작성되어 있어 실행이 아주 빠른 반면 기능이 비교적 적다. 제공하는 기능은 다음과 같다.

월별 통계 (총 히트수, 파일수, 페이지수, 방문자수, 데이터 전송량 및 평균/최대값)
응답코드
일별 통계(그래프 및 표)
시간별 통계(그래프 및 표)
히트 URL 순위
접속 시작/종료에 사용된 주요 페이지
페이지 참조 통계
접속시 사용한 웹브라우저 및 OS (아주 간단히)


위와 같이 비교적 기본 기능을 제공하는데, 아울러 제공하는 그래프는 그리 세련되지는 않다.


2.AW스테이츠 (GPL)




(공식 페이지: http://awstats.sourceforge.net/)


AW스테이츠는 Perl 스크립트로 만든 로그분석기로 비교적 많은 기능을 제공한다. 언뜻 보기에는 웹 서버가 남겨놓은 로그를 하나도 남김없이 분석하고 통계를 낸다는 느낌마저 들 정도다. 일목요연한 출력에 비교적 깔끔한 그래프와 표를 보여주지만 그래프를 보면 항목과 떨어져있어 한눈에 이해되지 않는다는 단점이 있다.



(데모 페이지: http://awstats.sourceforge.net/cgi-bin/awstats.pl)


AW스테이츠는 데모 페이지를 따로 마련해두었는데 위 페이지를 접속하면 소프트웨어를 내려받아 사용하기 전에 마음껏 기능을 음미해볼 수 있어 아주 편리하다.

제공하는 분석 및 통계 내용을 잠깐 살펴보면 다음과 같다.

간단한 전체 요약 및 월별 통계 (순 사용자, 방문횟수, 페이지수, 히트수, 전송용량)
상기 항목에 대한 일별(4 항목)/요일별 통계(3 항목=페이지, 히트, 용량)
시간별 통계 (3 항목)
접속 국가 (3 항목)
접속 호스트 (3 항목 + 최종 접속 일시)
로봇/스파이더 방문자 (히트수, 데이터용량, 최종 방문 일시)
접속해서 끊기까지의 시간
파일 타입(php, html, asp 등에 대한 히트수, 전송용량 등)
많이 본 페이지 URL, 접속 및 끊기 시 사용된 페이지
운영체제 (히트수 및 비중)
브라우저
경유 사이트(다이렉트/북마크, 뉴스그룹 링크, 인터넷 서치 엔진 경유, 서치 엔진 이외 다른 사이트 경유)
검색에 사용된 단어 및 구절
HTTP 응답 코드





웹얼라이저에 비해 아주 자세한 통계를 보여주고 있음을 알 수 있다. 특히 로봇/스파이더 방문자를 순 방문자와 구별하여 통계를 내어주는 것은 AW스테이츠의 장점이라 할 수 있다. 또한 경유 사이트에 대한 자세한 분석은 실제 기업 마케팅에서 활용할 수 있는 부분이 있다.

아울러 AW스테이츠는 웹서버 뿐만 아니라 FTP, 메일 서버까지 분석해준다.



(메일 서버 분석 통계)


3.아날로그 + 리포트매직

아날로그는 개인이 소유하고 있는 공개 소프트웨어로 GPL과는 달리 배포 및 수정에 제한을 두고 있다. 또한 아날로그와 연결하여 사용하는 리포트 매직은 개인 소유를 기본으로 'Artistic License'를 가지고 있다. 따라서 이 두 소프트웨어는 GPL과는 거리가 있지만 기업이나 개인이 사용하는 데는 별 문제가 없어 보인다.



(아날로그 공식 페이지: http://www.analog.cx/)



(리포트매직 공식 페이지: http://www.reportmagic.org/)


리포트매직 사이트는 아날로그와 리포트매직을 함께 사용해서 데모를 시연하고 있다.



(데모 사이트: http://www.reportmagic.org/sample/index.html)



(운영체제 통계)


리포트매직이 제공하는 정보의 양은 웹얼라이즈와 AW스테이츠 중간 정도다. 구체적으로는 다음과 같다.

통계 요약 및 주간/일별/시간별 보고서
접속 도메인/단체
실패한 참조 및 경유 사이트
검색에 사용된 단어
브라우저/운영체제
응답코드
파일크기, 파일 타입, 디렉토리 보고
실패한 요청
접속 페이지 및 파일


전체적으로 깔끔하고 고급스러운 3D 그래프와 파이는 매력적이지만 항목별로 자세하지 않은 정보라든지 언급되지 않은 항목도 있어 아쉬움을 남긴다.


4.웹로그 분석기의 강자는?


무릇 소프트웨어는 사용 용도와 사용자의 의도에 맞으면 그것이 최고다. 기능이 많든 적든 그림이 멋지든 안 멋지든에 상관없이 말이다. 그런 점에서 본다면 지금까지 살펴본 웹얼라이저와 AW스테이츠, 아날로그는 나름대로 일장일단을 가지고 있다.



(주요 웹로그 소프트웨어의 기능을 정밀하게 비교 분석해놓은 AW스테이츠 메인 페이지)


상기 사이트는 주요 웹로그 소프트웨어들(지금까지 살펴본 세 가지 소프트웨어 + 히트박스)의 기능을 정밀하게 비교 분석하고 있다. 자신에게 알맞는 소프트웨어를 결정하기 전에 필요한 기능을 미리 확인해보면 도움이 될 것이다.

이중에서 굳이 강자를 뽑아야한다면 AW스테이츠의 손을 들어주고 싶다. 아주 자세하고 꼼꼼한 정보는 웹 사이트 운영자에게 단순한 정보제공뿐만이 아니라 웹 사이트를 활성화할 수 있는 방안을 생각하는 데 기초자료를 제공해준다. 그리고 웹 서버 뿐만 아니라 메일 서버, FTP 서버에 대한 통계는 또 나름대로 쓰일 일이 있을지도 모른다.

정밀한 접속 분석/통계를 필요로 하는 본격 웹 사이트에는 AW스테이츠를, 간단한 정보를 간편히 보고 싶은 사이트에는 웹얼라이즈를, 멋진 그래프와 고급스러운 디자인이 우선이라면 아날로그를 권하고 싶다.

지금까지 살펴본 소프트웨어들은 대다수 소스를 함께 제공한다. 따라서 저작권에 따라 다소 다르겠지만 자유 소프트웨어인 경우 소스를 고쳐 자신의 웹 사이트에 적용하거나 아니면 이를 필요로하는 고객들에게 공급해줄 수도 있겠다.

자유 소프트웨어와 함께 즐거운 삶이 되기를!



AWStats 를 설치 후, 일반적으로는 당연히 국가별로 접속기록 확인이 가능할것이라고 예상한다.
그러나, GeoIP가 없으면 국가별로 접속기록 확인이 불가능하다.
그리고 이것은 Default 옵션이 아니다.
먼저 GeoIP를 설치하자.
[root@fimg1 ~]# yum install GeoIP
그리고나서, GeoIP를 제공하는 MaxMind에서, GeoIP의 Binary Database 파일을 다운받는다.
[root@fimg1 ~]# cd /usr/local/lib
[root@fimg1 lib]# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
[root@fimg1 lib]# gzip -d GeoIP.dat.gz
[root@fimg1 lib]# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
[root@fimg1 lib]# gzip -d GeoLiteCity.dat.gz
AWStats에서, 해당 바이너리 데이터베이스를 통하여 접속기록 IP주소들에 대한 국가와 지역을 확인할 수 있도록 설정해주어야 한다.
[root@fimg1 lib]# vim /etc/awstats/awstats.www.sealtale.com.conf
1305번째 라인의 주석을 해제하고, 경로를 수정하자.
#LoadPlugin="geoip GEOIP_STANDARD /pathto/GeoIP.dat"                       에서
LoadPlugin="geoip GEOIP_STANDARD /usr/local/lib/GeoIP.dat"               이렇게, 경로를 지정하여준다.
동일하게, 1344번째 라인에서, 주석을 해제하고, 해당 바이너리 데이터베이스의 경로와, 파일명도 지정하여 주자.
#LoadPlugin="geoip_city_maxmind GEOIP_STANDARD /pathto/GeoIPCity.dat"              에서
LoadPlugin="geoip_city_maxmind GEOIP_STANDARD /usr/local/lib/GeoLiteCity.dat"    처럼 수정하여 준다.
이것으로 설정이 모두 끝났고,
해당 config를 업데이트 하여 준다.
/usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=www.sealtale.com -update
이제, 기존과 달리 AWStats에서, 국가와 지역에 대한 접속 기록을 얻을 수 있다.


Trackback 1 Comment 0
2008.12.30 10:18

[WebKnight] 웹나이트 룰 적용 이후 결과와 주저리~

금번 쿠키의 취약점을 악용한 Mass SQL 인젝션과 관련하여 예전에 제가 별도로 운영하고 있는 일종의 허니넷에 웹나이트 룰을 수정하고, 결과를 지켜보는 중이라는 글을 올린 적이 있었습니다.(바로 이글입니다요~) 최근 개인적인 사정으로 그 결과를 정리하지 못하고 있었는데 Zasfe님께서 그 결과가 궁금하다고 하셔서 시간을 내어 일부만 정리하여 포스팅합니다.

'웹나이트 룰 수정 이후 효과가 있는가?'라고 여쭤보신다면 일단 '있습니다.'라고 답변을 드릴 수 있을 것 같습니다.

단, 블로그에 포스팅하지 않은 많은 부분이 추가되고, 수정되었습니다.(귀차니즘 때문에… 헐퀴~) 이미 적용되어 있었던 것도 있었습니다만, 제가 별도로 공개하거나 포스팅한 적은 없었기 때문에 같이 정리합니다.

많은 분들이 알고 계시다시피 단순히 웹나이트만 설치한다고 해서 외부 웹 해킹으로부터 운영 중인 웹사이트가 완벽하게 안전한 것은 아닙니다. '커스터마이징'이 매우 중요합니다.

거두절미하고! 금번 Mass SQL 인젝션과 관련하여 별도로 어루만져(?) 주셔야 할 웹나이트 룰들을 정리합니다.

아, 일전에 '그냥 웹나이트 룰을 제공해 줄 수 없냐?'라는 의견이 제 메일로 수신된 적이 있었습니다. 죄송하게도 제 개인적으로 테스트하고 있는 룰이라면 얼마든지 제공해 드릴 의사가 있습니다만, 어쩌다 보니 회사에서 운영 중인 서비스에 채택되어 외부에 공개되었을 경우, 보안 상 문제가 발생할 여지가 있습니다. 그리고 그밖에 내부적인 여러가지 요인으로 인해 룰 자체를 직접적으로 제공해 드리기 어려울 것 같습니다. 이 자리를 빌어 양해 부탁 드립니다.

참고로 본 포스트는 현재 가장 많이 사용되고 있는 웹나이트 2.1 버전을 기준으로 작성되었습니다. 아울러 웹나이트 로그에서 문제가 될 수 있는 부분은 보안상 애스터리스크(Asterisk) 기호로 변환 조치하였습니다.

 

1. Headers 섹션

'Deny Cookie SQL Injection' 항목은 기본적으로 필히 체크해 주셔야 합니다. 그리고 'Deny Cookie Encoding Exploits' 항목은 쿠키값에 인코딩된 익스플로잇(공격 코드)이 동봉되어 있을 경우, 접속을 차단해 버리는 옵션인데 국내에서는 문제가 발생할 수 있습니다. 특히 네이버나 다음에서 검색 후, 결과 페이지의 링크를 통해 웹사이트에 접속할 경우, 네이버나 다음에서 넘어오는 쿠키값을 웹나이트에서 익스플로잇으로 오인하여 클라이언트의 접속을 차단시킵니다. 자세한 것은 아래 웹나이트 로그를 참고해 주세요. 제 생각에는 쿠키값이 인코딩만 되어 있으면 접속을 차단시키는 것이 아닌가 싶을 정도로 처리 결과가 그리 좋지 못합니다.

2008-10-29 ; 09:03:21 ; W3SVC*** ; OnPreprocHeaders ; ***.***.***.*** ;  ; GET ; /***/***/***/***/***.gif ; HTTP/1.1 ; Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) ; COUNT%5FCHECK=CKCOUNT=YES; ASPSESSIONIDQSATSSTS=ONEIMHLDBLFKNHAPBGAACLBI; Log_CK=http%3A//search.naver.com/search.naver%3Fwhere%3Dnexearch%26query%3D%25BC%25D2%25B9%25E6%25C0%25DA%25C0%25E7%26sm%3Dtab_she ; BLOCKED: Encoding exploit in cookie (embedded encoding)

다음으로 'Deny Header SQL Injection' 항목을 체크해 주시기 바랍니다. 그리고 앞으로 꾸준히 룰을 관리해 주셔야 할 항목 중 첫번째 녀석인 'Use Denied Header Sequences'입니다. 우선 본 항목에 체크만 해 주시고 자세한 설명은 아래에서 계속 진행하겠습니다.

 

2. Querystring 섹션

'Use Querystring Raw Scan' 항목은 역시 필히 체크해 주셔야 하는 항목 중 하나입다. 몇가지 테스트를 통해 확인해 본 결과, 이 항목이 체크되어 있을 경우, 인코딩된 URL을 통해 전달되는 쿼리문을 일정 부분 다시 디코딩하여 확인합니다. 'Deny Querystring SQL Injection' 항목은 뭐… 굳이 말씀 드리지 않아도 체크하셨으리라 믿습니다. 다음으로 앞으로 꾸준히 룰을 관리해 주셔야 할 항목 중 두번째 녀석인 'Use Denied Querystring Sequences' 입니다. 역시 자세한 설명은 아래에서 계속 하겠습니다. 우선 체크만 해 두시길…

 

3. Global Filter Capabilities 섹션

'Deny Postdata SQL Injection' 항목은 역시 필히 체크해 주시고, 앞으로 꾸준히 룰을 관리해 주셔야 할 항목 중 세번째 녀석인 'Use Denied Post Sequences' 항목도 함께 체크해 주시기 바랍니다. 자세한 설명은… 이제 말씀 드리지 않아도 아시죠?

 

4. SQL Injection 섹션

일종의 SQL 인젝션 키워드 DB라고 할 수 있습니다. 위에서 체크한 항목 중 'Deny 뭐시기 SQL Injection' 등과 같은 항목들은 바로 이 'SQL Injection Keywords'에 등록된 값을 기준으로 하여 입력 받은 또는 전달 받은 값이 SQL 인젝션인지 아닌지를 구분하게 됩니다. 그만큼 중요한 부분이라 할 수 있습니다. 그리고 앞으로 꾸준히 룰을 관리해 주셔야 할 항목 중 네번째 녀석이죠.

 

5. 꾸준한 룰 관리가 생명입니다!

웹나이트는 패턴 매치 방식으로 부정한 접속과 공격 코드를 차단하는 어플리케이션입니다. 따라서 패턴. 즉, 룰 관리가 굉장히 중요합니다. 예를 들어 새로운 중국발 SQL 인젝션 코드가 나왔습니다. 그런데 웹나이트에 그 코드와 관련된 패턴이 전혀 등록되어 있지 않다면 웹나이트가 설치되어 있더라도 그 공격을 전혀 감지할 수 없습니다. 결과적으로 운영 중인 웹사이트에 침해사고가 발생하겠죠.

위에서 앞으로 꾸준히 룰을 관리해 주셔야 할 항목 네 가지를 말씀 드린 바 있습니다. 다시 한 번 정리해 보자면 다음과 같습니다.

- Headers 섹션의 'Use Denied Header Sequences'
- Querystring 섹션의 'Use Denied Querystring Sequences'
- Global Filter Capabilities 섹션의 'Use Denied Post Sequences'
- SQL Injection 섹션의 'SQL Injection Keywords'

차후 새로운 공격 코드의 패턴이 확인되었을 경우, 위의 네 가지 항목에 일제히 추가해 주셔야 합니다. 금번 Mass SQL 인젝션과 관련하여 확인된 패턴은 다음과 같습니다.

- declare (declare 뒤에 공백까지 포함하여 등록합니다.)
- declare @
- dec%lare
- .cn
- set @
- s%et @
- cast(
- ca%st(
- varchar(
- var%char(
- exec (exec 뒤에 공백까지 포함하여 등록합니다.)
- e%xec (e%xec 뒤에 공백까지 포함하여 등록합니다.)
- sysobjects
- 7379736F626A65637473
- syscolumns
- 737973636F6C756D6E73
- sysdatabases
- 737973646174616261736573

힘드시겠습니다만, 이 패턴들을 위에서 말씀 드렸던 네 가지 항목에 추가해 주시기 바랍니다. 아, 물론 가능하시다면 webknight.xml 파일을 직접 수정하셔도 무방합니다.

그리고 웹나이트 룰이 수정되셨다면 매번 말씀 드리고 있는 부분이지만, 반드시 최소 5일 간은 웹나이트 로그를 정기적으로 확인하셔서 정상적인 접속이 웹나이트 룰에 의해 차단되고 있지 않은지 확인하셔야 합니다.

이상입니다. 추가적으로 궁금하신 사항이나 질문이 있으시다면 댓글로 부탁 드립니다.

끝으로 한 가지 덧 붙이자면 웹나이트를 비롯한 웹 방화벽은 절대 웹 해킹을 100% 전면 방어할 수 없습니다. 어디까지나 차선책일 뿐입니다. 근본적인 해결 방법은 웹 취약점을 야기시키는 웹소스를 확인하여 보완하는 것임을 다시 한 번 강조하여 말씀 드립니다.

좋은 주말 되시길 바라며…


출처 : http://nice19.net/blog/index.php/archives/434


Trackback 0 Comment 2
  1. 푸른늑대 2009.01.07 14:05 address edit & del reply

    좋은 정보 감사합니다. 그리고 질문이 좀 있는데요^^
    웹나이트 적용 후 홈페이지의 메뉴들이 작동을 안하는데요.(스크립트로 되어 있습니다.)
    global filter capabilites에서 <script를 빼야 하는지요? 이건 아닌거 같구 해서요.
    혹시 방법을 아시는지요?
    읽어주셔서 감사합니다.

  2. Favicon of https://blog.pages.kr 날으는물고기 2009.01.13 14:24 신고 address edit & del reply

    먼저 웹나이트에서 남기는 로그를 확인해 보셔야 겠지요.
    해당 로그에 보시면 정상적인 것인데 차단된 경우가 있는지 확인해 보시고
    정상적인 접근이 차단된 경우를 찾으셔서 해당 차단된 룰을 수정해 주시면 됩니다. ^^

2008.12.30 09:54

최신 버전으로 구축하는 웹 파이어월, modsecurity

여러 차례 소개된 바 있는 아파치용 웹 파이어월인 modsecurity의 새로운 버전이 발표됐다. 아파치 2와 함께 많은 기능의 변화를 보이고 있는 웹 파이어월 모듈 modsecurity2를 설치하고 활용하는 방법에 대해 살펴보자.

홍석범 | 오늘과 내일 차장

여러 차례 소개된 바 있는 아파치용 웹 파이어월인 modsecurity의 새로운 버전이 발표됐다. 아파치 2와 함께 많은 기능의 변화를 보이고 있는 웹 파이어월 모듈 modsecurity2를 설치하고 활용하는 방법에 대해 살펴보자.
최신 버전의 아파치는 http://httpd.apache.org/에서 다운로드할 수 있으며, 여기서는 httpd-2.2.4.tar.gz를 다운로드한다. 만약 DSO 방식으로 사용하는 rpm을 이용하고자 한다면, 별도로 다운로드하지 않고 yum 등으로 설치해도 된다.
아파치 2와 호환되는 최신 버전의 modsecurity는 http://www.modsecurity.org/에서 다운로드할 수 있으며, modsecurity-apache_2.1.1.tar.gz를 다운로드하면 된다. 참고로 modsecurity는 1.x 대와 최근의 2.x가 있는데, 각각은 많은 차이점이 있다. 앞으로는 2.x를 중심으로 지원이 이뤄질 것이기 때문에 이 버전에 대해 살펴보도록 하겠다.
구체적으로 설치방법을 알아보기에 앞서 1.x와 2.x의 차이점에 대해 중요한 부분만 간략하게 살펴보면 (표 1)과 같다. 1.x와 2.x의 차이점에 대해 궁금하거나 1.x 사용중 2.x로 업그레이드하고자 할 때는 다음의 문서를 참고하기 바란다.

http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf



rpm 버전의 아파치(DSO)에 탑재하는 경우
이미 배포판에 설치된 DSO 방식의 rpm 버전 아파치에 modsecurity를 탑재하는 방법에 대해 살펴보도록 하자. 


# rpm -q httpd
httpd-2.0.52-28.ent.centos4


먼저 httpd가 설치된 것을 확인한 후, 관련 디렉토리로 이동해 다음과 같이 실행하면 된다. modsecurity2.x에서는 더 이상 apxs로 설치하는 것을 지원하지 않으며, 자체적으로 지원되는 Makefile을 이용해야 한다.
이후 Makefile 을 열어 20번째 줄에 있는 top_dir을 다음과 같이 변경한다.


변경 전 : top_dir      = /apps/apache22
변경 후 : top_dir      = /etc/httpd


이제 컴파일해 설치하도록 한다.

# make; make install


문제없이 설치되면 다음과 같은 메시지가 보일 것이다.


make[1]: Entering directory `/usr/local/src/modsecurity-apache_2.1.1/apache2'
/bin/sh /usr/lib/apr/build/libtool --silent --mode=install cp mod_security2.la /usr/lib/httpd/modules/
make[1]: Leaving directory `/usr/local/src/modsecurity-apache_2.1.1/apache2'


정상적으로 설치되면 /usr/lib/httpd/modules/mod_security2.so 파일이 생성된다. 이후 /etc/httpd/conf/httpd.conf 파일을 열어 다음 내용을 추가한다.


LoadFile /usr/lib/libxml2.so
LoadModule security2_module   modules/mod_security2.so


이제 httpd를 재가동하도록 한다.


# /etc/rc.d/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]


DSO 방식으로 httpd를 소스 컴파일 설치해 탑재하는 경우

아파치를 설치할 경우 DSO 방식으로 소스 컴파일해 설치한 경우의 modsecurity 탑재 방법에 대해 살펴보자. 이는 httpd 설치 시 다음과 같이 --enable-so 옵션을 주고 설정한 경우를 말한다. 그리고 여기에서 --enable-unique-id는 각 요청마다 유일한 식별자를 갖는 환경변수를 위해 설정하는 것으로 자세한 내용은 http://httpd.apache.org/docs/2.2/mod/mod_unique_id.html를 참고하기 바란다.


# cd src/httpd-2.2.4
# ./configure --enable-so --enable-unique-id
# make; make install


이렇게 설치하면 기본적으로 /usr/local/apache2/ 디렉토리에 아파치가 설치될 것이다. 이후 다음과 같이 압축을 해제한 modsecurity 소스 디렉토리로 이동하도록 한다.
 
# cd modsecurity-apache_2.1.1/apache2/


이후 Makefile 을 열어 20번째 줄에 있는 top_dir을 다음과 같이 변경하도록 한다.


변경 전 : top_dir      = /apps/apache22
변경 후 : top_dir      = /usr/local/apache2


이제 컴파일해 설치한다.


# make; make install


정상적으로 설치되면 /usr/local/apache2/modules/mod_security2.so 파일이 생성된다. 이후 httpd.conf 파일을 열어 다음 내용을 추가한다.


LoadFile /usr/lib/libxml2.so
LoadModule security2_module   modules/mod_security2.so


이제 httpd를 재가동하면 된다.


# /usr/local/apache2/bin/apachectl restart


소스 컴파일해 정적으로 설치하고자 할 경우
앞에서 살펴본 DSO 방식이 아닌 아파치 소스를 가져와 정적으로(static) 소스 컴파일해 설치하는 방법도 있다. 그러나 modsecurity 2.x에서는 이 방법을 더 이상 지원하지 않으며 오직 DSO 방식만 지원하므로 참고하기 바란다. 만약 정적으로 소스 컴파일해 사용하고자 할 경우에는 modsecurity 1.x 버전을 사용하기 바란다.
설치가 된 후 정상적으로 작동하는지 여부는 httpd.conf에 다음과 같은 설정을 해 본 후 간단히 확인해 보면 된다.


SecServerSignature "Microsoft-IIS/5.0"


이후 httpd를 재가동하고 다음과 같이 헤더값을 확인해 보기 바란다.


# curl --head  http://127.0.0.1/

HTTP/1.1 200 OK
Date: Fri, 20 Apr 2007 05:33:01 GMT
Server: Microsoft-IIS/5.0
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "11a088-2c-4c23b600"
Accept-Ranges: bytes
Content-Length: 44
Content-Type: text/html


만약, 정상적이라면 Server 부분에 앞에서 설정한 Microsoft-IIS/5.0이 보일 것이고, 제대로 적용되지 않았다면 다음과 같이 Apache가 보일 것이다.


Server: Apache/2.2.4 (Unix)


성공적으로 적용됐다면, 원하는 규칙을 설정하면 된다. 만약 아무런 규칙을 적용하지 않으면 설정 자체가 의미가 없으므로 modsecurity에서는 Core rule이라는 이름으로 별도의 규칙을 제공하는데, modsecurity-apache_2.1.1/rules 디렉토리에 관련 파일들이 있다. Core rule은 알려진 취약성(known vulnerabilities)에 대한 차단뿐만 아니라 알려지지 않은 취약성(unknown vulnerabilities)에 대한 차단 기능도 제공한다.
규칙 관련 파일은 별도의 디렉토리에 저장하는 것이 좋은데, 다음과 같이 디렉토리 내에 별도의 디렉토리를 생성하도록 한다. 


# mkdir /usr/local/apache2/conf/modsecurity
# mv *.conf /usr/local/apache2/conf/modsecurity/


그리고, httpd.conf에서 설정 파일을 로드하도록 포함(include)한다.


Include conf/modsecurity/*.conf


이후 httpd를 재가동하면 된다. 정상적으로 작동하는지 여부는 nikto와 같은 웹 스캐너를 이용해 스캔한 후 /usr/local/apache2/logs 디렉토리에 생성되는 로그파일을 살펴보면 된다. 모든 보안 솔루션이 그렇듯이 모든 규칙을 그대로 적용하면 정상적인 접속도 차단될 수 있으므로 오탐(false positive)이 없는지 확인한 후 커스터마이징 과정을 거쳐야 한다.
 
modsecurity 애플리케이션
다음으로는 modsecurity와 관련된 유용한 애플리케이션을 살펴보도록 하자.
먼저 modsecurity에서 제공하는 modsecurity-console이 있다. 이 프로그램은 modsecurity에 대한 로그 관리 등을 웹을 통해 수행할 수 있는 프로그램으로, 3개의 센서에 대해서는 제한없이 사용할 수 있다.
이 프로그램은 https://bsn.breach.com/ 에 접속 후 회원 가입하여 다운로드가 가능하다. 다음과 같이 압축해제 후 실행하면 된다.


# tar zxvfp modsecurity-console_1_0_2_unix.tar.gz
# cd modsecurity-console
# ./modsecurity-console


이 프로그램은 JDK가 설치돼 있어야 하므로, JDK가 없을 경우 다음과 같은 메시지가 나오면서 실행이 중지된다.


No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.4.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file /root/.install4j


이 때는 http://java.sun.com/에서 JDK 1.5 이상 버전을 다운로드한 후 설치해야 한다. 다음과 같이 실행하면 설치가 시작된다.


# ./jdk-1_5_0_09-linux-i586.bin


이후 jdk1.5.0_09 디렉토리가 생성되면서 관련 파일들이 설치되는데, 다음과 같이 실행해 INSTALL4J_JAVA_HOME 변수를 지정해 주도록 한다.


# export INSTALL4J_JAVA_HOME=/usr/local/src/modsecurity-console/jdk1.5.0_09


이제 modsecurity-console을 실행하면 잠시 후 8886/tcp에서 포트를 리슨하고 이 포트로 접속하면 된다. 초기 기본 ID와 암호인 admin/admin으로 로그인하면 (화면 1)과 같은 화면을 볼 수 있다.



modsecurity-cosole에 대해서는 http://modsecurity.org/projects/console/index.html을 참고하기 바란다. 이외에도 modsecurity와 관련된 주요 프로젝트는 다음과 같다.

- REMO : http://remo.netnea.com/
modsecurity에 대한 규칙 설정을 웹 기반으로 편집할 수 있는 프로그램이다.

- WeBekci : http://www.owasp.org/index.php/Category:OWASP_WeBekci_Project
modsecurity에 대한 규칙 설정 등의 관리를 웹 기반으로 수행할 수 있는 프로그램으로, php+mysql 기반의 프로그램이다.

또한 modsecurity에 대한 유료 기술지원을 제공하는 Breach(http://www.breach.com/)에서는 modsecurity를 기반으로 한 리눅스 기반의 ModSecurity Pro와 WebDefend라는 웹 파이어월 어플라이언트 제품도 별도로 판매하고 있다.



Trackback 0 Comment 0