중국발 Mass SQL 인젝션 공격이 다시 한 번 주춤하고 있습니다. 실제로 최근 들어 공격 횟수가 급격히 줄어 들고 있네요. 아마 인터넷 상에 퍼져있는 다양한 정보들의 도움으로 웹 서버와 웹 소스의 보안이 강화되었고, 이로 인해 쿠키 변조를 통한 Mass SQL 인젝션 공격도 약발이 다 되었나 봅니다.

음… 하지만 공격 횟수가 단순히 줄어 들었을 뿐이지 일련의 사태들이 완벽하게 종식된 것은 아니기 때문에 서버 관리자 분들의 꾸준한 관심과 관리에는 변함이 없어야 할 것입니다.

최근 '웹나이트'를 비롯한 웹 방화벽에 대한 관심도가 크게 향상되었음은 물론이며 윈도우즈 웹 서버에 기본적으로 웹나이트를 비롯한 웹 방화벽이 설치될 정도로 보안 의식이 강화되었다고 합니다.

사실 웹나이트 외에도 하드웨어 웹 방화벽 장비나 기타 웹 방화벽 상품들이 시중에 많이 나와 있습니다만(따지고 보면 그렇게 많은 것도 아닙니다만…) 아무래도 비용적인 부담 때문에 많은 분들이 웹나이트를 선택해서 사용하고 계신 것으로 알고 있습니다.

서론이 길었네요. 예전 글에서도 누누히 말씀 드렸지만 웹나이트는 설치보다 관리가 몇 배는 더 중요합니다. 본 글에서는 웹나이트 설치 후, 반드시 해야 할 일 중 딱 두 가지만 다시 한 번 보기 좋게 정리해 보았습니다. 도움이 되셨으면 좋겠네요~

* 본 글은 '웹나이트 2.1 버전'과 '윈도우즈 2003 스탠다드 SP2 + IIS 6' 를 기반으로 작성되었습니다.


1. 웹나이트 로그를 반드시 정기적으로 확인하세요.

서버 관리자의 주된 업무 중 하나인 로그 확인 및 분석! 웹나이트 역시 정기적인 또는 주기적인 로그 확인이 무엇보다 중요합니다. 웹나이트 2.X 버전부터는 별도의 로그 애널라이저(analysis.exe)가 동봉 되어 있기 때문에 단순히 텍스트 파일을 열어 확인하는 것보다는 한결 수월해졌습니다.

로그 확인의 기본은 해당 로그의 형식 파악입니다. 그럼, 웹나이트에서 남기는 로그의 형식을 알아야 겠죠? 웹나이트의 로그 형식은 다음과 같습니다.

시간 ; 웹사이트 식별자 ; 이벤트 ; 클라이언트 IP주소 ; 사용자 명 ; 이벤트와 관련된 자세한 사항

이해를 돕기 위해 실제 웹나이트 로그를 통해 구분을 나눠보겠습니다.

03:21:39 ; W3SVC1 ; OnPreprocHeaders ; ***.***.***.*** ; ; GET ; /test/test.asp ; id=37'%20and%20user%2Bchar(124)=0%20and%20"=' ; BLOCKED: possible SQL injection in querystring ; HTTP/1.1 ;  ASPSESSIONIDAQDBDDAD=EDIAJJBAFOHJCEKKEMBNCEJD

1. 시간 : 03:21:39

2. 웹사이트 식별자 : W3SVC1

3. 이벤트 : OnPreprocHeaders

4. 클라이언트 IP주소 : ***.***.***.***

5. 사용자 명 : 내용 없음

6. 이벤트와 관련된 자세한 사항 : GET ; /test/test.asp ; id=37'%20and%20user%2Bchar(124)=0%20and%20"=' ; BLOCKED: possible SQL injection in querystring

로그 마지막에 'HTTP/1.1….' 부분은 크게 염두할 사항이 아니므로 과감히 잘라냈습니다. 위의 예제 로그를 분석해 보면 GET 방식으로 전달 받은 변수값에 SQL 인젝션 코드가 삽입되어 있어 웹나이트에 의해 클라이언트의 접근이 차단된 것임을 알 수 있습니다. 아마 URL을 직접 변조하여 SQL 인젝션을 시도했던 모양입니다…-_-;;

만일 로그 분석을 통해 공격 시도가 확인되었다면 서버 관리자는 공격자의 IP주소를 발췌하여 한국인터넷진흥원(NIDA) WHOIS 페이지(http://whois.nida.or.kr)에서 IP주소의 관리사와 관리자 그리고 제원을 확인해야 합니다.

조회된 정보를 살펴보면 하단에 네트워크 어뷰즈(Network Abuse) 담당자의 연락처와 이메일 주소를 확인하실 수 있을 겁니다. 보통 이 네트워크 어뷰즈 담당자의 이메일 주소로 귀사에서 관리하고 있는 네트워크 자원에서 SQL 인젝션 공격(또는 해킹 공격)이 접수되었다는 내용의 메일을 발송해 줍니다.

메일 내용에는 공격자의 IP주소와 해당 서버의 IP주소, 공격이 확인된 시간과 자세한 로그(웹나이트 로그에서 필요한 부분만 발췌하면 되겠죠?) 등을 반드시 동봉해 주어야 합니다.

만일 공격자의 IP주소를 국내 기관에서 관리하고 있다면 보통 처리 결과에 대한 회신이 1~2주 이내로 도착할 것입니다. 해외 기관에서 관리하고 있을 경우에는 처리 결과에 대한 구체적인 회신은 없을지라도 약 70% 이상 내부적으로 조치가 완료되니 너무 염려하지 마시구요.(참고로 해당 ISP 업체가 막장인 경우에는… 답이 없습니다.)

* 참고로 해외 기관에서 관리하고 있는 IP주소일 경우 한국인터넷진흥원 WHOIS 페이지에서 바로 조회 결과가 출력되지 않습니다. 해당 IP주소에 대한 정보 대신 조회해 볼 수 있는 해외 기관의 웹사이트 주소가 출력되는데. 해당 웹사이트로 이동하셔서 다시 한 번 IP주소에 대한 정보를 조회해 보시기 바랍니다.

이제 가장 중요한 것은 재접근 자체를 원천봉쇄 하는 것입니다. 서버 앞 단에 방화벽 장비 등이 이미 설치되어 있다면 정말 베스트겠죠?(방화벽 장비가 설치되어 있지 않다면 윈도우즈 방화벽, IPSEC, IIS 설정 등으로 차단할 수 있습니다만, 역시 방화벽 장비가 쵝오…!)

만일 로그 분석을 통해 확인된 공격자의 IP주소가 123.123.123.123 이라며 단순히 123.123.123.123 IP주소만 차단할 것이 아니라 C클래스, 즉 123.123.123.0 부터 123.123.123.255 까지 대역 자체를 차단하는 것이 좋습니다.

그 이유는 공격자의 IP주소가 해커의 손아귀에 들어간 흔히 말하는 좀비 서버의 IP주소라면 같은 세그먼트에 연결되어 있는 다른 서버 역시 좀비 서버가 되었을 가능성이 높기 때문입니다. 보통 같은 세그먼트에 연결된 서버끼리는 포트뿐만 아니라 IP 자체를 오픈해 놓는 경우가 많습니다. 포트스캐닝 프로그램만 한 번 돌려보면 손쉽게 다음 타겟을 찾을 수 있지요.


2. 새로운 해킹 동향에 대해 관심을 가져주세요.

어떤 분께서 이런 말씀을 하시더라구요. '보안은 곧 관심이다.' 라고요. 저는 이 말에 100배 공감합니다. 새로운 해킹 수법은 이미 그 피해 사례가 확대되기 전에 설이 풀리기 마련입니다. 물론 그 설에는 다양한 정보들이 내포되어 있습니다.

새로운 해킹 수법에 의한 피해 사례는 보통 국내 보다는 해외에서 먼저 발견되는 경우가 많습니다. 보통 일본과 미국 쪽에서 먼저 리포팅 되곤 하는데 영어의 압박이 있긴 합니다만 해석이 불가능 할 정도로 어려운 글들은 아닙니다. 사실 우리가 보안과 관련해서 사용하는 용어들도 영어가 많기 때문에 그나마 위안으로 삼으시면…-_-;;

그리고 이런 정보들이 국내 IT 보안 전문 업체나 해커들에 의해 해석되고, 분석되서 손쉽게 재가공된 정보가 검색될 때도 국내 피해 사례는 그렇게 크지 않습니다.(거의 없다고 봐도 무방할 정도로…) 늦지 않았다는 얘기지요. 이번 쿠키 변조를 통한 Mass SQL 인젝션도 그랬고, 그 이전에 Mass SQL 인젝션도 그랬습니다.

관심을 갖는다면 충분히 사전에 예방할 수 있습니다. 음… 제가 시간 날 때마다 방문하는 웹사이트 몇 군데를 소개해 드릴까 합니다.

- http://www.secureworks.com/research/threats/
- http://www.nchovy.kr/
- http://swbae.egloos.com/
- http://www.krcert.or.kr/index.jsp
- http://www.us-cert.gov

2009/08/27 11:09 2009/08/27 11:09

Trackback Address :: https://youngsam.net/trackback/844