언제나 공사중! ::

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을 막는 방법 #3

일 2006/05/29 14:33

이 글을 쓰기 전에 제목을 고민 좀 했다. 왜 고민했는가 하면 바로 제목을 "SQL Injection을 막는 방법 #2-1"로 할까 아니면 "SQL Injection을 막는 방법 #3"으로 할까.. 하는 고민...

왜 이런 고민을 했는가 하면 "SQL Injection을 막는 방법 #2"에서 맨 마지막에 언급한 Server나 Workstation을 죽일때의 부작용을 전혀 언급하지 않았기 때문이다. 과연 부작용이 얼마나 심한가... 거짓말 조금도 안보테고 아주 심각한 부작용이 있다. 이 부작용에 따라서는 몇몇 시스템은 아예 동작을 안할 수 있다. 그리고 동작은 하나 기능이 동작안하는 경우도 있다.

구체적으로 쉽게 볼 수 있는 예를 들어주겠다.

Workstation을 정지시키면...
- 도메인 로그온이 불가능해진다
- 도메인 로그온이 가능하더라도 정책 업데이트가 진행되지 않는다
- 모든 네트워크 드라이브 연결이 불가능해진다
- Distributed Link Tracking Client 가 동작하지 않는다

- Distributed Transaction Coordinator 일부분 오동작한다
- 기타 등등 네트워크 접근 부분이 꼬인다

Server를 정지시키면...
- 도메인 콘트롤러의 기능이 정상 동작하지 않는다
- DFS를 사용할 수 없다
- 정책 업데이트가 진행되지 않는다
- SMTP(Simple Mail Transfer Protocol) 가 동작은 하나 MMC에서 관리도구에 나오지 않는다
- EMWAC이 설치된 경우 관리도구가 정상 동작하지 않는다
- RPC기반의 모든 부분이 오동작 할 수 있다. (이 부분은 조금 심각하다. 특히 이벤트 뷰어에 일부 몇가지 이상하게 찍히곤 한다)
- Symantec Norton Antivirus나 TrendMicro의 ServerProtect의 스케줄 검사가 동작하지 않는다
- 기타 외국의 도메인 상태에서 동작하는 대부분의 프로그램이 동작하지 않는다
- 기타 등등 네트워크 관련된 부분이 꼬인다
- 비싼 프로그램들의 대부분이 꼬이기 시작한다

이 정도면 끔찍하지 않은가? 순수하게 윈도우에 MS-SQL만 올라간 상태가 아니라 만약 지금 당장 문제가 없다하더라도 다른 부분도 일부 사용하는 것이라면, 반드시 오류는 발생한다. 문제는 오류가 발생해도 이를 모니터링하거나 알아차리기가 어려운 상태에서 동작시키는 것이다.

즉, Server/Workstation을 죽이면 윈도우라는 OS가 동작하기 위한 최소한의 OS상태가 되버린다고 생각해도 무방하다. Windows 2003 R2에 Server/Workstation를 죽이고 사용하면 괜찮기는 하지만, Windows 2000에 Server/Workstation을 죽이고 사용하면 OS가 이상하게 변하기 시작한다.

그러면 이 방법을 쓰지 말아야 하는가? 하면 그건 "그때그때 달라요"를 외칠 수 밖에 없다. 경험이 있는 사람이나 이러한 문제 발생을 처리할 수 있고 또 사전 예방이 가능하다. 혹시 그냥 해봤다면 모니터링을 한 보름정도 해보고 계속할지 안할지를 결정해라.

자.. 그럼 네트워크 속성에서 "Microsoft 네트워크용 파일 및 프린터 공유"를 제거하는 방법의 경우에는 어떨까? 이 옵션을 모두 꺼버리면 NetBIOS를 사용하지 않는다는 사실만 알고 있으면 된다. 문제가 발생해도 비교적 쉽게 처리가 가능하니까 직접 해보는게 낫겠다. 하지만, 이 방법만으로는 외부의 연결을 확실하게 막을 수 없기에 문제가 된다는 사실을 잊지 말도록!

PS: 최근에 이런 글이 많은 이유는... 개인적으로 머리가 아프기 때문임.

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

트랙백 0 Comment 3

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

木蓮 2006/05/29 21:33
아고..
여전히 넘 어려운 포스트네요..~~
이 목련이,도체 무슨소린지..하나두 모르겠거든요..~~ㅎㅎㅎ
우리 데굴데굴님..전공이..아고아고...
무슨소린지못알아듣지만..이웃으로 함게인것...

머물다감니다...행복한시간가지세요..~~~
- 데굴대굴 2006/05/30 09:07
  "일"이라는 카테고리에 있는건 제가 일하면서 남기는 그런 기록들이기에.... 완벽하게 "전문화된 잡담 문서"입니다.
  
  평범한 분들이 이거 읽고 이해한다는 생각은 전혀~ 안합니다. 저와 비슷한 업종에 있거나 비슷한 업종에 올려는 학생들을 위해서 만들어두는 것이니까요.. ^^
  
  목련님이 머리 저 때문에 머리아 아푸시다니...ㅠ.ㅠ 죄송할 따름입니다....ㅠ.ㅠ
木蓮 2006/05/30 22:04
아고...아닌데...련이..전혀,머리안아픈데..ㅎㅎ
모르면모르는데로..살아가는저인걸요..~~ㅋㅋ

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에서