언제나 공사중! ::

WebKnight.. 보안관련 웹 서버용 ISAPI 필터 #5

일/프로그램 2006/10/07 09:57

웹서버의 동작 사항과 사용자의 작업을 보는데 웹로그를 풀로 남기는 방법을 쓰는게 가장 좋기는 하지만 어지간한 인간이라면 하루에 몇 메가가 넘는 텍스트 파일을 보고 있을 시간은 없을꺼다.

웹로그를 한참 보다보면 대부분의 경우가 4xx, 5xx를 보는 것이고 특히 5xx를 주의깊게 봐야하는데.... 별 쓸대없이 2xx, 3xx, 4xx를 계속 보다보면...

눈과 머리가 정말로 아주 많이 아프다

따라서... 실제 문제가 되는 부분만 봤으면 좋겠는데, IIS의 기본 능력으로는 이걸 필터링하는 방법이 없다. 방법이 아예 없는 것은 아니다. 웹로그를 SQL에 집어넣고 이를 select해보면 되기는 한다. 근데, 해보니까 10M의 텍스트 파일을 SQL에 넣었더니 30M쯤으로 뿔더라... 따라서 실질적으로 사용할 수 있는 부분은 아니다. 아니면 리소스 킷이나 Microsoft사의 다운로드 사이트에서 Log Parser를 받아서 쿼리를 날리면 결과를 찾아 볼 수 있다. 하지만 이것조차 힘들고 귀찮다면 WebKnight를 이용할 수 있다. WebKnight의 로그 설정은 다음과 부분을 신경써서 보도록한다.

* 클라이언트의 오류 남기기 : 4xx 오류 계열이며 Log HTTP Client Errors 를 체크한다.
- Log HTTP Client Errors는 보통의 경우라면 필요가 없으나 웹사이트가 얼마나 링크가 잘 되어 있고 정상적으로 로깅이 되는지 확인하고 싶을 때 사용하면 된다. 자주 쓸 일도 없고, 한 일주일 정도만 남겨서 본다면 그걸로 족하다고 생각된다.

* 서버의 오류 남기기 : 5xx 오류 계열이며 Log HTTP Server Errors 를 체크한다.
- 이 부분은 항상 켜두기 바란다. 이것은 SQL Injection과 같은 공격의 패턴을 찾아내기 좋다. 대부분의 해킹은 서버의 오류를 고의로 발생시키는 것인데, 이 오류만 뽑아서 볼 수 있는 아주 쉽고 확인하기 편한 방법이다. 그리고 이것을 꼭 켜두어야 하는 이유는 바로 정상적인 요청이 튕겨져 나갔을 때 어느 필터에 의해 거절되었는지 확인할 수 있는 거의 유일한 길이기 때문이다.

* 모든 로그 남기기 : Log Allowed Requests, Log HTTP VIA 를 체크한다.
- 맨 마지막에 있는 모든 로그 남기는 부분은 주의하기 바란다. 정상적인 로그도 남기며, 이걸 사람이 읽는다는 것은 거의 미친짓에 가깝다. 더구나 IIS의 로그보다 더 많이 남기기도 하기 때문에 서버가 디스크 부족으로 죽을 수 있다.

참고 자료
- UrlScan : http://www.microsoft.com/technet/security/tools/urlscan.mspx
- WebKnight : http://www.aqtronix.com/?PageID=99

ISAPI, SQL Injection, WebKnight, 보안, 웹서버해킹, 웹해킹

트랙백 0 댓글 0

Trackback : http://www.daegul.com/trackback/31

SQL Injection을 막는 방법 #4

일 2006/08/14 09:10

대부분 SQL Injection이 가능한 이유는 웹서버에서 인자값 체크를 안하기 때문이지만, SQL서버에서 시스템을 건드릴 수 있는 다양한 방법을 제공하기 때문이다. 지금 MS-SQL이 설치되어 있다면 Master DB의 Stored Procedure를 봐라.

당신이 알고 있는 SP는 몇 개나 있는가?
당신이 사용하는 SP는 몇 개나 있는가?

갑자기 SP를 보라고 하는 이유는 이 중에서 SQL Injection에 사용되는 SP가 있기 때문이다. 바로 다음과 같은 부분이다.

xp_cmdshell
xp_regread
xp_regwrite
xp_dirtree

추가 내용 더 보기..

위에 적은 Stored Procedure/Extended Stored Procedure의 용도를 알고 있는가? 얼마나 위험한지 하나의 예를 들어주겠다. 예시로 하나 들을 것은 가장 강력하고 자주 쓰이는 xp_cmdshell이다. 심심하면 분석기에서 MS-SQL에 붙고 다음 쿼리를 날려보자.

xp_cmdshell 'net user Administrator P@ssw0rd'
xp_cmdshell 'format d: /q'

이런 쿼리를 날리면 별도의 말이 안나온다. 이제 심심하니까 서버에 터미널로 로그인을 해보자. 참고로 위의 쿼리 그대로 했다면 비밀번호는 P@ssw0rd다. 이 정도는 비극의 시초다. 만약 당신이 스크립트나 배치파일을 사용할 줄 안다면 xp_cmdshell이 얼마나 무서운 명령어인지 깨달아야 한다. 두번째 라인도 실행했다면, 이제 탐색기를 열어보자

혹시 D드라이브가 깔끔해지지 않았는가? 이제 날아간 D: 드라이브의 자료를 보며 당신은 소중한 경험을 배웠기에 즐거워해야한다. 설마 이 작업을 실 서버에서 한 사람은 없겠지? 당신은 읽으면서 해봤다고? 당신의 운명이다. 받아들여라.

자.. 이제 농담은 그만하고 SP의 용도 모르겠거나 안쓰면 다 실행 권한을 제거해버려라. SA건 뭐건간에 이런걸 돌릴 수 있다는 것이 시스템을 뺏기는 지름길이다.

PS: 작성 할려고 말만하다가 정말 오랫만에 올리는군요. 이런 글 올리는게 몇달 만인지.....

SQL Injection, Stored Procedure, WebKnight, 보안, 웹서버해킹, 웹해킹

트랙백 0 Comment 2

Trackback : http://www.daegul.com/trackback/293

木蓮 2006/08/14 22:45
아고!.. 머리넘아포요!!므슨뜻인지 하나도 모르겠어요.ㅎㅎㅎㅎ열심히 배워볼게요.
티춰님^^* 시원한 시간이 되세요.~~~
- 데굴대굴 2006/08/15 10:30
  거 이런거 안배워도 되요. 일반인이라면 이런거 배워봤자 쓸데가 없어요. -_-; 저와 비슷한 직종에 있는 극히 일부의 사람들이나 필요한거죠.

SQL Injection을 막는 방법 #1

일 2006/05/22 10:56

SQL Injection은 웹의 취약점으로 생긴다고 알고 있다. 이 SQL Injection은 그렇다. 분명한 취약점이다. 이 취약점이 문제가 되는 것은 정보가 빼돌려졌기에 대단히 위험도가 높은 것이다. 그런데 SQL Injection을 막기위해 WebKnight같은 웹 방화벽만으로 안전할까? 내 생각에는 안전하다고 생각하지 않는다. 하지만 현장에서 느끼는 문제는 이런 것이 아니다. 현장에서는...

- 페이지가 바뀌었는데 원상복구를 해도 자꾸 바뀐다.
- 사용자들이 올리는 글 때문에 짜증이 만땅된다.

이게 사실 가장 큰 스트레스의 이유다. DB 정보야 빠져나가면 그만이다. 누가 대대적으로 해킹해서 팔았다고 광고하지 않는 이상 스트레스를 받을 이유가 없다. (사실 이런 해커가 나오면 사이버 수사대에 신고해버리면 끝이다) 해킹 당한건 사실이고 이미 당한걸 어쩌겠냐? 잘 얼버무리든 다시 만들든 공지를 올리든 이번 한껀만 크게 잘 처리하면 되는거다. (물론 이미 당했다면 그 책임은 져야하는 것이 당연하다. -_-;)

그러면 현장에서 느끼는 이 짜증을 어떻게 막아야 할까?

옛날부터 내려오는 보안 수칙에 이런게 있다.

최소한의 프로그램만 설치한다.
데이터베이스는 사설망으로 바꾼다.

대부분의 업체들이 위 수칙은 잘 지키고 있다. 적어도 알고 있는 범위 내에서는 말이다. 근데 막상 사용해보면 DB를 사설망으로 바꿔봤자 소용이 없다. 위에 나온 수칙 중에 있는 DB를 사설망으로 바꾼다는 내용의 실제 중요한 핵심은 바로 DB와 웹서버의 연결고리를 끊는 것이다. 일단 정상적인 서비스를 위해서 MS-SQL과 IIS의 연결은 끊을 수 없다. 하지만, 다른 부분은 과연 신경쓰고 있을까? 예를 들면 다음과 같은 부분이다.

관리자적 공유 폴더(c$, d$, e$...)는?
컴퓨터 IP만 치면 알 수 있는 공유폴더는?
내부에 활성화 시켜둔 FTP서버로 접근은?
telnet, ssh 같은 원격 접속은?
오류 발생시 이를 내부에서는 검출하고 외부에서는 보지 못하게 할 수 있는가?

혹시 이런 부분이 문제가 된다고 생각해 본적은 없는가? 실제 SQL Injection뿐만이 아니라 해킹에서는 이런 부분을 이용한다.

자자~~ 오늘도 졸립다. 다음에 계속 쓰도록 하자~.

Security, SQL Injection, WebKnight, 보안, 웹서버해킹, 웹해킹

트랙백 1 Comment 2

Trackback : http://www.daegul.com/trackback/280

Subject SQL Injection을 막는 방법 #1
Tracked from 공부하세요. 2006/05/26 11:38
SQL Injection은 웹의 취약점으로 생긴다고 알고 있다. 이 SQL Injection은 그렇다. 분명한 취약점이다. 이 취약점이 문제가 되는 것은 정보가 빼

elca 2006/05/23 11:15
^^
다음글이 기대됩니다..
- 데굴대굴 2006/05/23 20:49
  될 수 있으면 이런 기술 문서 계열(이벤트 뷰어 제외)은 일주일에 하나씩은 올려볼려고 노력하고 있습니다.
  
  하루에 30분. 오래 걸려도 1시간이면 족하니까요. 다음 문서는 수요일 오후로 잡혀 있습니다. :)

WebKnight.. 보안관련 웹 서버용 ISAPI 필터 #4

일/프로그램 2006/05/15 11:08

이제까지 앞에 이야기 한 것을 잘 해서 봤다면 WebKnight가 정상적으로 동작할 것이고 로그를 꽤 많이 쌓고 있을 것이다. 로그를 잘 보자. 작게는 몇십 kb에서 많게는 몇십메가까지 쌓일것이다. (보통 하루에 몇메가 정도 쌓인다) 마음에 걸리지 않는가? 저 수많은 공격들이 하루에 들어오고 있었다니 말이다.

그러면 들어온 데이터를 기준으로 얼마나 더 필터링을 해야하는가를 확인해보자.

일단 SQL Injection을 부분이 많이 부족하다.

SQL Injection과 URL Denied Sequences에 다음 항목을 추가해보자.

xp_
cmdshell
dirtree
%20and
char(124)
char(94)
%2Buser%2B

;=
=;
%20%20

위의 것은 SQL Injection을 가능하게하는 프로그램을 통해서 돌릴 때 남는 로그를 기반으로 찾아낸거다. 설정해보고 역시 며칠동안 자자.... 로그의 쌓이는 양이 늘었다. 여기서 재미를 더 붙이면 더 많이 막을 수 있다. 이번에는 조금 더 생각해서 다음 항목을 활성화 시켜두자.

Deny Cookie SQL Injection : 활성화
Deny Cookie Encoding Exploits : 활성화
Deny Header SQL Injection : 활성화
Deny Header Encoding Exploits : 활성화
Deny Postdate SQL Injection : 활성화

자... 이제 조금씩 설정이 끝나간다. 하지만 방심은 금물. 아직도 갈길이 멀다. 로그를 한번 봐주고 문제가 생길 때까지 또 자자.... 이번에는 꽤 많이 설정을 변경했기에 로그 보기를 조금 자주하길 바란다.

참고 자료
- UrlScan : http://www.microsoft.com/technet/security/tools/urlscan.mspx
- WebKnight : http://www.aqtronix.com/?PageID=99

ISAPI, SQL Injection, WebKnight, 보안, 웹서버해킹, 웹해킹

트랙백 1 댓글 0

Trackback : http://www.daegul.com/trackback/279

Subject WebKnight.. 보안관련 웹 서버용 ISAPI 필터 #4
Tracked from 공부하세요. 2006/05/26 11:36
이제까지 앞에 이야기 한 것을 잘 해서 봤다면 WebKnight가 정상적으로 동작할 것이고 로그를 꽤 많이 쌓고 있을 것이다. 로그를 잘 보자. 작게는 몇십 kb에서

WebKnight.. 보안관련 웹 서버용 ISAPI 필터 #3

일/프로그램 2006/05/11 11:05

WebKnight의 로그를 분석하는 방법이다. WebKnight의 로그는 기본 적으로 설치폴더\Log에 남으며, 파일명은 yy.mm.dd.log 로 남는다. 만약 IIS 6라서 Per Process Logging을 활성화 하였다면 설치폴더\Log\w3wp_process_pid에 남는다

각 로그는 다음과 같은 형식으로 이루어져 있다. 꼭 알아두어야 나중에 고생 안한다.

발생시간; 발생서비스; 발생 부분; 클라이언트IP; ; 전송방식 ; 입력된부분; 처리 ; 사유 ; 상태

예를 들면 다음과 같다.

19:49:40 ; W3SVC4 ; OnPreprocHeaders ; 333.333.333.333 ; ; GET ; /_vti_bin/owssvr.dll ; BLOCKED: '/_vti_bin' not allowed in URL ; UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 ; HTTP/1.1 ; ASPSESSIONIDAQTTDBAD=FEJLIGOBPEOEBCCCACIOFHHN

;로 나줘져서 보기가 좀 그래서 그렇지 정리해서 보면 정말 쉽다. 위 문장을 잘 보면 왜 막았는지 기록이 남는다. 바로 /vti_bin 을 호출했기 때문에 BLOCKED된 것이다. 그러면 다음 예를 보자.

03:03:20 ; W3SVC4 ; OnPreprocHeaders ; 333.333.333.333 ; ; GET ; /notice/view.asp ; pid=284%20%20and%20exists%20(select%20*%20from%20sysobjects)%20-- ; BLOCKED: possible SQL injection in querystring ; HTTP/1.1 ; ASPSESSIONIDAQTTDBAD=IGNHIGOBELCAHABDIMNDPAOJ

거의 맨 끝에 BLOCKED: possible SQL injection in querystring 이라고 되어 있다. 아.. 저것이 바로 SQL Injection공격의 하나다. 이제 config.exe를 실행해서 로그와 맞는 SQL Injection이 어느 것인지를 확인해보도록 한다. 해당 내용을 보면 와 닫는 것이 바로 select, from, sysobjects의 3가지 부분이다. 이제 감을 잡았다면 처리를 한 것이다.

만약 위에 남은 로그가 정상적이였다면 해당 부분에 가서 지워주자. 로그를 보는 방법은 끝났다.... 일단은 행복하다. 이제 로그가 남도록 기다리며 잠이나 자자.

나머지 내용은 다음 이 시간에... 캬캬캬~~~

참고 자료
- UrlScan : http://www.microsoft.com/technet/security/tools/urlscan.mspx
- WebKnight : http://www.aqtronix.com/?PageID=99

ISAPI, SQL Injection, WebKnight, 보안, 웹서버해킹, 웹해킹

트랙백 1 댓글 0

Trackback : http://www.daegul.com/trackback/278

Subject WebKnight.. 보안관련 웹 서버용 ISAPI 필터 #3
Tracked from 공부하세요. 2006/05/26 11:35
WebKnight의 로그를 분석하는 방법이다. WebKnight의 로그는 기본 적으로 설치폴더\Log에 남으며, 파일명은 yy.mm.dd.log 로 남는다. 만약 IIS 6라서