2017년 3월 6일 월요일

간만에 Snort 분석(DNS Request - 3rd)

하루 동안 DNS 조회가 시도된 도메인의 검사 범위를 1,300여 개에서 448개로 좁혔다. 이제 448개의 추세선만 분석하면 된다. 물론 쉽지는 않겠지만 1,300개 보다야 양반이지 뭐.


당연히 한동안은 현황 파악을 위한 노가다가 필수다. 조회를 시도하는 도메인의 개수, 유형 등의 정보를 일, 주 단위 등으로 쌓고, 단위별 추세 변화의 차이나 정상과 비정상(으로 보이는) 도메인에 대한 구분 작업을 해야 한다는 얘기.

정상임이 확실한 도메인을 걸러낼수록 현황 파악은 점점 더 쉬워진다. 그리고 나면? 특정 상태의 개수를 세는 것만으로도 의미를 찾게될 확률이 높아진다. 예를 들면 시간대별 중복되지 않는 도메인 개수같은 것.


select distinct time, domain2
from D:\domain.csv
where domain2 not in (
        'google-analytics.com'; 'google.co.kr'; 'google.com';
'googleadservices.com'; 'googleapis.com'; 'googlesyndication.com';
'googletagservices.com'; 'googleusercontent.com'
)

구글 관련 도메인만 걸러낸 시간대별 도메인 개수를 구해봤다. 01시경 조회가 시도된 도메인은 11개. LogParser는 중복을 제거해주는 distinct 함수의 단일 집계만 지원하기 때문에 시간대별 개수를 직접 구하려면 해당 결과를 별도의 CSV로 저장 후, 다시 작업을 해야 한다. 다음은 그 결과.



이런 건 어떨까? 01시경 발생한 도메인 내역에서 00시경 발생한 도메인 내역을 뺐다. 01시경 새롭게 발생한 도메인 내역만을 조회했다는 얘기. 일 또는 주 단위 차이를 구해보면 재밌을 듯.


① select domain2
② from D:\domain.csv
③ where time = '1:02'
    and domain2 not in (
          select domain2
          from D:\domain2.csv
          where time = '0:02'
)

이런 작업을 사고 전에 시도하면 이상징후 분석, 사고 후 시도하면 포렌식. 이상징후 분석 별거 없다. 전체 현황에서 하나씩 정상을 걸러내면 된다. 노가다가 많고, 그럼에도 세상은 뜻밖에 아름다워서 비정상이 별로 없다는 게 함정. 그래서 이상징후 분석은 일한 티가 잘 안 나고, 그래서 시도 자체가 어렵다.

그나저나 DNS 조회를 시도하는 프로세스까지 파악되면 그림 좀 나올 것 같은데? Windows Event Log를 뒤져볼까 싶다.

댓글 없음:

댓글 쓰기

크리에이티브 커먼즈 라이선스