snort rules for nikto web scanning -3

snort rules for nikto web scanning -3

참고게시물

https://girrr.tistory.com/132

IDS - 스노트(Snort) : 기본

https://latte-is-horse.tistory.com/22

PCRE (Perl Compatible Regular Expressions)

지난 글 

burp suite로 nikto 동작 살펴보기 -1

https://man-25-1.tistory.com/264

burp suite로 nikto 동작 살펴보기 -2

 

지난 게시물에서 nikto 사용법과 burp suite를 통해 nikto 의 request 패킷들을 살펴보았습니다.

 

이번 게시물에서는 nikto의 웹 스캐닝을 snort로 탐지하려고 할때 어떤식으로 rule을 작성해야할지 고민해보는? 글입니다.

 

 

Wireshark로 스캐닝 패킷 캡쳐

먼저 wireshark를 이용해서 스캐닝 과정에서 생기는 패킷들을 캡쳐해봅시다.

 

TCP stream을 관찰하면 좀 더 직관적으로 볼 수 있습니다.

여러 패킷들 중 몇가지를 확인해보겠습니다.

 

 

 

 

여기까지 보면 패킷의 Request URI 에 위험성을 가지고 있는 확장자나 키워드가 보입니다.

 

예를 들면  .asp, .tar, .perf, .exe 같은 확장자나 .. config, boot.ini  ,database, /etc/passwd 등 정상적인 접근이라면

이런식의 request 는 존재하지 않겠죠?

 

이 외에도 아래와 같이 union all select 구문을 시도한다거나 (sql injection)

 

script 를 삽입해서 xss를 시도하는 구문도 있습니다.

 

Nikto scanning을 원천 차단하는 Snort rule 

패킷들을 관찰한 결과 모든 패킷의 user agent에 "nikto" 문자열이 들어간 것을 볼 수 있습니다. 따라서 단순히 nikto 를 활용한 스캐닝을 허용하고 싶지 않다면 다음과 같은 룰을 작성할 수 있습니다.

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Nikto Web App Scan in Progress"; flow:to_server,established; content:"(Nikto"; fast_pattern:only; http_header; pcre:"/^User-Agent\x3a[^\r\n]*?\(Nikto/Hmi"; threshold: type both, count 5, seconds 60, track by_src; reference:url,www.cirt.net/code/nikto.shtml; reference:url,doc.emergingthreats.net/2002677; classtype:web-application-attack; sid:2002677; rev:14;)

 

이 외에 구체적으로 탐지하고 싶은 범위를 지정해서 snort rule을 작성해서 스캐닝의 허용 범위를 줄이는 것은 학습에 많은 도움이 됩니다.

 

먼저 snort rule에 쓰이는 pcre 정규식과 옵션들은 아래와 같습니다.

 

 

 

XSS 공격을 차단하는 Snort rule 

 

위와 같이 스캐닝 테스트케이스중에는 XSS 공격을 수행하는 케이스도 있습니다. 위와 같은 경우 Request URI 로 전달되는 <script> 가 탐지 키워드가 될 것입니다.

 

따라서 http_uri 에서 "<script>" 문자열을 탐색하는 룰을 작성합니다.

룰을 위와 같이 작성하고 웹 스캐닝을 수행해보겠습니다.

 

 

성공적으로 잘 탐지되는 것을 확인할 수 있습니다.

 

마찬가지로 sql injection이나 admin, root, passwd , cmd와 같은 위험한 키워드들, 또는 확장자들에 적용해서 룰을 작성하면 구체적으로 탐지하고싶은 패킷을 지정할 수 있습니다.

 

 

 

디렉토리 스캐닝을 차단하는 rule

위의 캡쳐된 패킷들의 전체적인 모습을 보면 request 패킷에서 특정 URI를 요청하고, 서버에서는 response 패킷으로

404 not found를 보내고 있습니다.

 

따라서 웹 서버 입장에서 생각해봅시다. 매우 빠른 속도로 80번 포트를 통해 임의의 포트로 404 not found를 보내고 있는 상황이라면? 잠재적으로 위험성을 내포한 접근일 수 있습니다. 해당 상황을 탐지하는 룰을 작성해보겠습니다.

 

*이 룰은 실제 서비스에 적용하기에는 굉장히 많은 과탐이나 오탐이 발생할 수 있습니다.

 

이 외에도 패킷들을 살펴보면서 자신이 필터링하고싶은 패킷들에 대한 룰을 작성해보면 많은 공부가 됩니다 !