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

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

2008년 11월 01일 토요일, 오후 1시 40분

금번 쿠키의 취약점을 악용한 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

 이분 글만 잘 탐독하면 저같은 초보도 조금이나마 이해할 수 있다는....ㅋㅋ