간만에 Snort 분석(DNS Request)

정말 오랫만에 Snort 로그. 목적지 포트가 53번인 UDP 트래픽을 모조리 탐지하는 다음과 같은 룰이 있다.

alert udp any any -> any 53 \
 (msg:"DNS Request_udp"; classtype:TEST; sid:3000005;)

특정 공격의 탐지보다는 내부에서 발생하는 DNS 조회 현황 파악 용도. (수상쩍은 DNS 조회가 있을지도 모르고) 특정일의 발생 현황을 살펴보자.

① select date_format(a.timestamp, '%H:%m'), c.data_payload, count(a.signature)
② from event a, signature b, data c
③ where b.sig_name = 'DNS Request_UDP'
      and date(a.timestamp) = '2016-02-18'
      and a.signature = b.sig_id
      and a.sid = c.sid and a.cid = c.cid
④ group by date_format(a.timestamp, '%H:%m'), c.data_payload

도메인 조회량이 시간 단위로 최대 천 개가 넘어간다. 무슨 도메인 조회가 이렇게 많지?

조회를 시도한 도메인 내역을 살펴보자. 다음은 16진수 'data_payload' 값을 디코딩한 결과. 그런데 읽을 수가 없네?

원인은 DNS 패킷의 구조에 있다. 여러 정보들로 이루어진 트리 구조 패킷을 아스키코드 체계의 문자로 디코딩되는 과정에서 제어문자 등이 깨진 것.

DNS Request 패킷 데이터 영역

조회 시도된 도메인 이름 영역

불필요한, 조회 시도된 도메인을 제외한 나머지 정보들을 삭제할 필요가 있다. 다음은 도메인 정보 좌우의 13, 5byte를 검사하는 VIM 정규표현식. 언제나 그렇지만 검사만 되면 삭제는 쉽다.

다음은 도메인 정보 좌우의 13, 5byte를 삭제한 16진수 데이터의 디코딩 결과. 그런데 뭔가 이상하다. 상하위 도메인 구분자인 '.'이 모두 제어문자로 인식되고 있다.

확인해보니 '0a~0f', '01~12' 까지의 16진수를 도메인 구분자로 사용중. 왜? -_-

모조리 '.'의 16진수인 '2e'로 바꿔주자. 검사만 되면 치환은 껌.

이제 조회 시도된 도메인 내역을 확인해볼 수 있다.

다음은 시간대별 발생 현황.

너무 많아서 상위 20개 도메인의 발생 현황만 그려봤다. 구글 소유인 'ssl.gstatic.com' 도메인 조회가 많네?

그나저나 내가 저 많은 도메인에 다 접속했을리는 없고, 구글 관련 도메인이 많은 걸로 봐서는 크롬이 범인이지 싶은데(..)

관련 글

• 간만에 Snort 분석(DNS Request - 2nd)