태그 보관물: 로그분석

효율적인 이벤트 분석

효율적으로 이벤트를 분석하기 위해 다음과 같은 단계를 거치게 된다.

가장 먼저 수행하는 작업이 분석 정보를 선별하는 것이다. 네트워크 패킷이나 로그를 보기 좋게 가공하는 과정이다. 보기 좋게 가공한다는 것은 먼저 수집된 정보 중 정상 범주의 데이터를 제외 하는 과정이다. 이 부분이 이번 장에서 첫 번째로 배우게 될 짚더미 치우기다.

정상 범위의 데이터를 제외하고 나며 선별된 정보에서 가장 핵심적인 메시지를 찾아 낸다. 이 핵심 이벤트를 찾는 것이 여러분이 두번째로 배우게 될 공격 구분 이다. 그리고 핵심 메시지를 찾아 냈다면 시스템에 미치는 영향을 통해 이론이나 가설을 증명 하게 된다. 만약 적정한 정보를 찾지 못하거나 잘못된 데이터 가공이 이뤄졌다면 추가 증거 수집을 통해 분석 과정을 반복한다.

  • 무조건 많은 정보를 수집하는 것이 증거 수집은 아니다.
  • 분석되지 않은 데이터나 사용되지 않는 데이터는 의미가 없다.
  • 분석을 통해 즉각적인 행동과 정보 보호 전략을 수립한다.
  • 기본적인 데이터는 자동으로 처리하여 효율적으로 분석한다.
  • 보안 위협에 대응하는 보안팀의 대응 마인드도 중요하다.

웹로그분석(짚더미치우기)

짚더미를 치운다는 것은 분석되지 않거나 불필요한 정보를 치워서 좀더 효율적으로 이벤트를 분석하기 위한 작업 이다. 가능한 부분은 프로그램이나 오픈 소스를 이용해 자동으로 분류해서 분석 대상을 선별하는 것도 방법 중 하나다.

다음과 같은 가정을 해보자.

“일반적인 네트워크 트래픽엔 공격 패킷이나, 악성코드가 없다.”

하지만 이러한 착한 트래픽은 모래 더미처럼 수 없이 많다. 모래 더미에 숨어 있는 바늘 같은 공격 트래픽을 찾는 일은 결코 쉬운 일이 아니다.

모래더미처럼 쌓아 놓은 정보들 중에 불필요한 정보들을 치워 보자.

웹 로그를 이용해 짚더미를 치우는 방법은 같이 살펴보자. 로그 파서를 설치하고 실행 시키면 로그를 분석하기 위해서는 로그 타입을 “ IISW3CLOG” 형식으로 지정 한다.

<짚더미 1단계 – 메소드 점검>

먼저 분석할 웹 로그에서 응답 코드 현황에 대한 통계를 추출한다.

먼저 샘플 로그를 저장하고 해당 로그 위치를 경로로 지정해 다음과 같은 쿼리 문은 로그 파서 쿼리창에 입력하고 실행 버튼()을 클릭 하면 다음 그림처럼 응답코드 통계를 추출할 수 있다.

SELECT sc-status AS Status,
         COUNT(*) AS Total
FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’
GROUP BY Status
ORDER BY Total DESC
그림 응답 통계 추출

<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치운다>

일반적으로 웹 응답과정에서 자주 발생하는(흔히 정상 범주에 해당하는) 응답코드를 제외하고 나머지 코드를 살펴 보자. 정상 범주에 대한 기준은 다음과 같이 정의 하자.

응답코드설명
200 클라이언트 요청이 성공했습니다.
302 개체 이동
304 수정되지 않았습니다.
404 찾을 수 없습니다.

4개 응답코드를 제외하고 500(에러), 401(거부), 201(파일생성), 206(일부응답)와 같이 잘 발생하지 않는 응답코드 위주로 분석을 진행 하자. 동일하게 로그 파서 쿼리 창에 다음과 같이 입력하고 실행 한다.

SELSELECT sc-status AS Status, cs-method, cs-uri-stem, c-ip
FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’
WHERE (Status = 500) or (Status = 401) or (Status = 201) or (Status = 206)
그림 로그쿼리(정상범주제외)

총 25개의 결과물이 검색되었다. 25개 정도면 충분히 하나씩 전수 분석이 가능한 범위다. 응답코드를 정렬해서 하나씩 살펴보자.

먼저 201 응답 코드로 응답된 URL을 보면 /test.txt, /da.txt URL에 대해 3가지 메소드(PUT, COPY, MOVE)가 사용되었다.

Statuscs-methodcs-uri-stemc-ip
201PUT/test.txt192.168.20.20
201COPY/test.txt192.168.20.20
201PUT/da.txt192.168.20.37
201MOVE/da.txt192.168.20.37

<짚더미 치우기 3단계 – 공격자 상세 분석>

이제 공격자로 의심되는 IP에 대해 상세하게 분석해 보자.

다음 그림 처럼 쿼리문을 입력하고 결과를 확인해 보자.

SSELECT TO_TIMESTAMP(date,time) as Datetime, sc-status, cs-method, cs-uri-stem, c-ip
FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’
WHERE c-ip like ‘192.168.20.37’
ORDER BY Datetime

그림 로그쿼리(공격자분석)

웹 로그를 분석해 보면 192.168.20.37 IP에서 PUT메소드를 이용해 da.txt파일을 업로드 하였고, 성공적으로(201 응답코드) 웹 서버에 파일이 업로드 된것을 알 수 있다. 이후 공격자는 MOVE메소드를 이용해서 업로드한 da.txt 파일을 fuck.asp 파일로 변경하였다.

해당 파일은 IIS 환경에서 동작하는 웹 쉘 파일로 공격자는 웹쉘을 이용해 웹 서버를 장악했다.

정상 범주의 데이터를 제거한 것만으로 공격자의 공격 경로를 찾아 낸 것이다.

패킷 분석

앞서 로그를 이용해 침해 분석하는 방법을 살펴 보았다. 이번에는 네트워크 패킷을 분석해 보자. 마찬가지로 분석 범위를 선정하는 작업 만으로도 상당히 침해분석을 효율적으로 수행 할 수 있다.

<짚더미 1단계 – 메소드 점검>

Statistic > HTTP > Packet Counter > 필터 입력 없이 Create stat 클릭

그림 웹 패킷 통계 추출

통계 정보를 추출해 보면 사용된 메소드 정보와 웹 서버의 응답 코드 정보를 한눈에 요약해서 살펴 볼 수 있다. 요약된 정보를 통해 분석 대상 범위에서 제외할 정보를 정의한다. 효율적으로 분석 작업을 하기 위해서는 정상 범위의 데이터를 제외할 필요가 있다. 정상 범위를 정의하기 위해 수집한 정보의 현황을 먼저 살펴보는 과정이다.

<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치우기>

로그 분석할 때와 마찬가지로 정상 범주의 패킷을 제거하자. 정상 범위로 웹 요청 패킷 중 GET 요청 패킷을 제외해보자. 와이어샤크에 패킷 필터 구문을 적용하자.

Filter > BPF(Berkeley Packet Filter) 형식 필터 구문 입력

!(http.request.method == GET) && tcp
그림 정상범위 패킷필터

GET요청이 포함된 패킷을 제외한 TCP 패킷을 불러왔다. 이 과정을 통해서 원본 패킷에서 분석해야 하는 범위를 상당수 좁혔다. 분석 대상을 선택하기 따라 추가적인 범위 구분이 가능 하다.

Case #1 GET요청이 아닌 웹 통신 분석

!(http.request.method == GET) && tcp.dstport == 80

Case #2 실제 데이터 통신이 발생한 패킷만 분석

!(http.request.method == GET) && tcp.dstport == 80 && tcp[13] == 18

Case #3 특정 메소드 분석

http.request.method == NOTIFY

<짚더미 치우기 3단계 – 상세 분석>

앞서 로그상에 정상 범주를 제외하고 남은 로그에 대해 상세 분석 하듯이 정상 범주를 제외한 패킷 상세 분석을 진행한다. 특정 코드 (“204”)에 의한 패킷분석을 통해서 사고 발생 연관 공격 패킷 또는 피해 관련 증적 정보를 추적한다.

그림 패킷 상세분석

로그와 패킷 분석 작업은 시간과 리소스가 많이 필요한 과정이다. 효율적인 이벤트 분석을 하기 위해 불필요한 데이터를 정제하고 공격의 흔적을 찾이 위해 적정한 범위로 분석 대상을 선별하는 작업이 중요하다.

엔드포인트(Endpoint) 보안에 대한 이해

사이버 보안 침해사고가 발생하면 기업은 내부적으로 침해사고분석을 통해 공격자의 흔적을 찾아내고, 공격 당시 사건을 재구성하여 시스템에 발생한 피해를 파악 한다.

시스템에 침해가 발생하기 까지는 많은 일들이 발생 한다. 공격자가 시스템을 공격하고 장악하기 위해 정보 수집 과정을 거치게 된다. 이 과정에서 공격자는 대상 시스템의 서비스 종류, 시스템 현황, OS종류, IP대역, 포트정보, 취약점 정보 등 많은 정보를 수집하게 된다.

외부의 공격자가 정보 수집을 통해 충분히 공략할 대상 시스템의 약점을 파악했으면 취약점을 이용해 공격에 들어가게 된다. 보통 이 과정에서 많은 수의 공격이 탐지되고 차단이 된다. 공격자는 가능한 모든 방법을 동원해 탐지되지 않기 위해 우회 시도를 하고, 100번의 공격 중 1번의 공격이 성공하게 되면 공격 성공 단계에 이르게 된다. 바로 이 단계가 침해가 발생되는 시점 이다.

시스템 장악에 성공하면 공격자는 자신의 목적에 따라 시스템에 악성코드를 설치하거나 시스템의 정보를 유출하는 행위가 이뤄지고, 많은 경우 침해사고 발생에 대한 인지는 정보 유출 또는 시스템 변조가 발생되고 이뤄지게 된다. 공격자가 공격 대상의 약점을 악용해 개인정보유출과 랜섬웨어로 인한 피해로 이어지게 된다.

보안팀은 공격을 탐지하고 예방하기 위해 다양한 방법을 이용해 침입시도에 대해 모니터 한다. 주로 네트워크에서 발생되는 정보를 활용하게 된다. 가장 많이 사용되는 정보는 침입탐지시스템에서 제공하는 정보를 활용한다. 시스템에 가해지는 공격시도나 공격행위에 대해 네트워크 레벨에서 사전에 분석해 파악하고, 차단하면 시스템 침해를 예방할 수 있다.

시스템에 발생되는 변화를 모두 기록하는 운영체제의 시스템 로그는 보안 사고 대응 관점에서 중요한 정보다. 침해사고가 발생하면 시스템 로그 분석을 통해서 타임테이블을 정의하고 공격 경로와 시스템 피해를 파악할 수 있다. 공격자가 원격에서 시스템에 접근하게 되면 시스템에 접근을 시도한 계정과 원격 IP 또는 접근한 컴퓨터의 정보, 접근 시간 등 사고 조사에 중요한 IOC 정보를 수집할 수 있다.

네트워크에 노출된 윈도수 시스템에 로그인을 시도한 로그 샘플을 살펴보자. 해당 로그는 윈도우 보안 이벤트 로그다.

그림 – 윈도우 보안 이벤트 로그

로그를 살펴보면 해외 49개 IP (대부분 러시아)에서 짧은 시간동안 사전식 대입 공격을 통해 로그인을 시도했다. 공격자는 135개의 ‘Username’을 변경해서 네트워크를 통해 로그인을 시도했다. 실제 시스템이 외부에 노출되면 여러분이 예상하는 것보다 빨리 공격에 노출된다. 한가지 흥미로운 부분은 공격자가 로그인을 시도한 Username 이다. 해외 공격자가 로그인을 시도하지만 실제 한글 이름이나 성의 영문 이니셜을 사전 파일로 사용한 것으로 보인다. 공격 대상 국가에 맞춰 사전 파일을 커스터마이징해서 공격하는 모습이 흥미롭다.

공격자의 로그인 실패 로그는 윈도우 보안 이벤트로 남기 때문에 사고 분석이나 보안 모니터링 로그로 활용할 수 있다. 개별 로그의 상세 분석 정보를 통해 필요한 IOC를 추출하고 여러 시스템을 분석할 때 분석 키워드로 사용한다.

그림 – User Logouts Winlogbeat Security 샘플로그

운영체제의 시스템 로그는 사고 조사 뿐만 아니라 사고를 예방하는 관점에서도 중요하다. 공격자에 의해 백도어 프로그램이 설치되거나 시스템 명령이 실행되면 모든 정보를 시스템에 로그로 남길 수 있다. 특히 윈도우 운영체제의 시스템 로그에는 공격 과정에서 발생하는 다양한 정보가 로그에 기록된다.

시스템 로그는 중요성 만큼 기록하는 정보가 많다. 운영체제의 로그 설정에 따라 보관할 수 있는 기간도 다르기 때문에 분석가나 실시간 모니터링 관점에서는 로그를 XDR 플랫폼과 연동해서 사고 분석 과정에서 활용하거나 실시간 위협 탐지를 위해 활용한다.

사고가 발생할 경우 사고조사를 수행하는 분석가 입장에서는 피해 범위를 파악하기 위해 모든 시스템을 일일이 확이할 수 없기 때문에 시스템 로그를 수집해서 식별된 IOC와 연관된 시스템 로그를 분석해서 사고 피해 범위를 유추한다. 이후 파악된 시스템의 디지털 포렌식 작업이나 2차 상세 점검을 수행하는게 효율적으로 사고 분석을 수행할 수 있다.

실시간으로 수집되는 시스템 로그에는 시스템 운영과 관련된 다양한 정보가 수집된다. 보안팀에게는 실시간 보안 위협과 관련된 정보가 실시간으로 전달된다. 원격에서 공격을 시도할 경우 시스템에 접근하려는 시도가 로그를 통해 수집된다. 공격을 시도하는 원격 IP나 시스템에서 외부로 연결되는 백도어 IP를 수집해 모니터링 할 수 있다. 실시간 모니터를 위해서 보안팀은 오픈 소스 기반의 인텔리전스 (OSINT)를 활용 힐 수 있다.

실전사례: 웹 애플리케이션 로그 분석

로그 가공 작업은 분석되지 않거나 불필요한 정보를 치워서 좀더 효율적으로 이벤트를 분석하기 위한 작업 이다. 다음과 같은 가정을 해보자.

“일반적인 네트워크 트래픽엔 공격 패킷이나, 악성코드가 없다.”

하지만 이러한 트래픽은 짚더미처럼 수 없이 많다. 짚더미에 숨어 있는 바늘 같은 공격 트래픽을 찾는 일은 결코 쉬운 일이 아니다. 불필요한 정보들을 치워 보자.

웹 로그를 이용해 짚더미를 치우는 방법을 같이 살펴보자

로그 파서를 설치하고 실행 시키면 로그를 분석하기 위해서는 로그 타입을 “ IISW3CLOG” 형식으로 지정 한다.

<짚더미 1단계 – 메소드 점검>

먼저 분석할 웹 로그에서 응답 코드 현황에 대한 통계를 추출한다.

먼저 샘플 로그를 저장하고 해당 로그 위치를 경로로 지정해 다음과 같은 쿼리 문은 로그 파서 쿼리창에 입력하고 실행 버튼()을 클릭 하면 다음 그림처럼 응답코드 통계를 추출할 수 있다.

SELECT sc-status AS Status,
         COUNT(*) AS Total
FROM ‘C:\(로그파일 경로 지정)\ex*.log’
GROUP BY Status
ORDER BY Total DESC
그림 응답 통계 추출

<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치운다>

일반적으로 웹 응답과정에서 자주 발생하는(흔히 정상 범주에 해당하는) 응답코드를 제외하고 나머지 코드를 살펴 보자. 정상 범주에 대한 기준은 다음과 같이 정의 하자.

응답코드설명
200 클라이언트 요청이 성공했습니다.
302 개체 이동
304 수정되지 않았습니다.
404 찾을 수 없습니다.

4개 응답코드를 제외하고 500(에러), 401(거부), 201(파일생성), 206(일부응답)와 같이 잘 발생하지 않는 응답코드 위주로 분석을 진행 하자. 동일하게 로그 파서 쿼리 창에 다음과 같이 입력하고 실행 한다.

SELECT sc-status AS Status, cs-method, cs-uri-stem, c-ip
FROM ‘C:\(로그파일 경로 지정)\ex*.log’
WHERE (Status = 500) or (Status = 401) or (Status = 201) or (Status = 206)
그림 로그쿼리(정상범주제외)

총 25개의 결과물이 검색되었다. 25개 정도면 충분히 하나씩 전수 분석이 가능한 범위다. 응답코드를 정렬해서 하나씩 살펴보자.

먼저 201 응답 코드로 응답된 URL을 보면 /test.txt, /da.txt URL에 대해 3가지 메소드(PUT, COPY, MOVE)가 사용되었다.

Statuscs-methodcs-uri-stemc-ip
201PUT/test.txt192.168.20.20
201COPY/test.txt192.168.20.20
201PUT/da.txt192.168.20.37
201MOVE/da.txt192.168.20.37

<짚더미 치우기 3단계 – 공격자 상세 분석>

이제 공격자로 의심되는 IP에 대해 상세하게 분석해 보자.

다음 그림 처럼 쿼리문을 입력하고 결과를 확인해 보자.

SELECT TO_TIMESTAMP(date,time) as Datetime, sc-status, cs-method, cs-uri-stem, c-ip
FROM ‘C:\(로그파일 경로 지정)\ex*.log’
WHERE c-ip like ‘192.168.20.37’
ORDER BY Datetime
그림 로그쿼리(공격자분석)

웹 로그를 분석해 보면 192.168.20.37 IP에서 PUT메소드를 이용해 da.txt파일을 업로드 하였고, 성공적으로(201 응답코드) 웹 서버에 파일이 업로드 된것을 알 수 있다. 이후 공격자는 MOVE메소드를 이용해서 업로드한 da.txt 파일을 fuck.asp 파일로 변경하였다.

해당 파일은 IIS 환경에서 동작하는 웹 쉘 파일로 공격자는 웹쉘을 이용해 웹 서버를 장악했다.

정상 범주의 데이터를 제거한 것만으로 공격자의 공격 경로를 찾아 낸 것이다.

침해사고사례 사전식 대입 공격 로그인 성공 로그 검색

사전식 대입공격이라 함은 흔히 무작위 대입공격, 또는 패스워드 추측공격으로 침입탐지 시스템이나 패킷 분석 시 자주 나타나는 공격 유형 중 하나 이다.

자주 보이는 만큼 대비를 많이 하여 실제 위험도는 낮지만 방심하면 언제든지 공격을 당할 수 있다.

이번에 소개할 사례도 잠깐의 방심으로 침해가 발생한 사례다. 해당 침해사고는 시스템 침입이 발생되고 CERT팀으로 시스템 점검 의뢰가 접수 되었다.

확인된 증상으로는 시스템에서 아웃바운드로 비정상 트래픽이 발생하고, 시스템에 파일들이 생성되었다는 내용 이다.

시스템 분석을 위해 IDC로 이동하였고, 이동 후 시스템 관리자를 통해 시스템 운영현황과 구성을 파악하였다.

특정 Application 관련 서버로 사용하기 위해 시스템을 재설치 하였고 재설치 후 인터넷 연결 1시간 만에 이상 증상이 발생 되었음을 전달 받았다. 침해가 발생한 시스템이 설치된 네트워크에는 F/W등의 네트워크 보안 장비가 설치 되지 않았었다.

시스템 점검을 위해 침해사고가 발생된 것으로 의심되는 시스템 하드를 별도의 서버에 마운트하여 분석을 시작하였다.

시스템을 마운트 하고 가장 먼저 점검 시스템의 실행 명령 내역을 점검 하였다. 확인 결과 여러 사이트에서 파일을 다운로드 하였고, 파일을 다운로드 후 피해 시스템에서 실행 시킨 흔적이 확인 되었다.

실행된 명령 내역을 살펴 보니 특정 사이트의 URL을 통해 압축된 프로그램을 다운받아 압축을 풀고 파일에 포함된 스크립트 파일을 실행 시키는 행위가 반복적으로 나타났다.

스크립트를 실행 시키면서 IP 대역을 인자값으로 사용하는 것도 확인 할 수 있었다.

실행된 명령내역을 점검하며 다운로드 한 파일들은 별도로 다운로드 하여 시스템 점검과 툴분석을 병행 하였다.

시스템 침해 경로는 시스템로그를 통해 쉽게 찾을 수 있었다.

침해시스템에 구동중인 SSH 서비스를 대상으로 특정 IP에서 사전식 대입공격이 이뤄졌고, 단 4번만의 시도로 접속이 성공된 것이 확인 되었다.

다음은 실제 침해발생 시스템의 secure 로그다. 사전식 대입공격을 시도한지 4번만에 로그인 패스워드 획득에 성공한다. “Accepted password” 로그는 성공적으로 로그인이 이뤄지면 남는 로그다.

XXX XX XX:XX:18 [HOSTNAME] sshd[13015]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.xxx.xxx.68  user=root
XXX XX XX:XX:20 [HOSTNAME] sshd[13015]: Failed password for root from 123.xxx.xxx.68 port 47277 ssh2
XXX XX XX:XX:20 [HOSTNAME] sshd[13016]: Received disconnect from 123.xxx.xxx.68: 11: Bye Bye
<중략>
XXX XX XX:XX:30 [HOSTNAME] sshd[13021]: Accepted password for root from 123.xxx.xxx.68 port 48306 ssh2
XXX XX XX:XX:30 [HOSTNAME] sshd[13021]: pam_unix(sshd:session): session opened for user root by (uid=0)

총 15회 대입공격을 시도 하였다.

공격 성공은 4번째 시도에 이뤄졌고, 사전식 대입 공격툴은 준비한 사전파일의 모든 계정 패스워드를 시도하고 공격을 종료 하였다.

분석 과정에서 피해 시스템을 공격한 툴이 공격자에 의해 피해 시스템에도 다운로드 한 것을 분석과정에서 확인 하였다. 공격자는 동일한 방식으로 시스템을 공격하고 성공하면 동일한 프로그램을 다운로드 하고 또 다른 시스템을 공격하는 방식으로 공격을 진행하고 있는 것으로 추정 되었다.

해당 프로그램의 사전파일의 4번째 패스워드가 실제로 피해시스템에서 설치 시 설정된 패스워드와 동일한 것으로 확인 되었다. 침해사고가 발생된 시스템에 초기 패스워드가 쉬운 패스워드로 설정되었고, 이 상태에서 인터넷에 연결되어 “흔히” 발생하는 사전식 대입 공격에 의해 시스템 침해가 발생된 것이.

해당 시스템은 점검 후 재포맷을 하고, 패스워드에 대해서도 강화된 패스워드로 변경하여 설정 되었다. 실제 필드에서 침해사고로 시스템을 분석하다 보면 금번 사례와 같이 사소한 실수로 시스템이 공격자에 의해 장악되는 경우를 자주 보게 된다.

항상 공격은 어렵고 복잡한 경로를 통해 이뤄지는 것보다 허술하거나 관리가 소홀한 곳을 통해 이뤄진다.

임계치 기반 분석

위협 분석 방법론은 쉽게 얘기해서 어떻게 분석을 할지 정의 하는 것이다. 가장 대표적인 분석 방법론으로 블랙리스트 방식과 화이트리스트 방식이 있다. 먼저 블랙리스트 방식은 기존에 위험하다고 알려져 있는 키워드나 이벤트를 중심으로 수집된 정보를 분석하는 방법이다. 방대한 정보에서 정해진 정보만을 검색하기 때문에 상대적으로 분석 소요 시간이 짧다. 하지만 알려진 정보를 가지고 검색하기 때문에 언노운[1] 공격은 찾아내기 어렵다. 반대로 화이트 리스트 방식은 확인된 정상 범주의 정보를 제외한 모든 정보를 분석하는 방법이다. 블랙리스트 방식에 비해 분석할 양도 많고 분석 시간도 많이 소요 된다. 하지만 언노운 공격도 분석이 가능한 방법이다.

분석한 이벤트가 왜 공격인가에 대해서 정의하기 위해서는 먼저 왜 공격이 아닌지 알고 있어야 한다. 다시 말해 정상 통신이나 정상 행위가 무엇인지 알고 있어야 한다. 보안을 입문하는 사람들에게 기본을 강조하는 이유이기도 하다. 애플리케이션이나 네트워크 통신이 어떻게 이뤄지는지 알고 있다면 정상 통신과 비정상 통신을 구분할 수 있다.

예제를 통해 정상 통신과 비정상 통신을 구분하는 사례를 보자.

[1] 공격 방식이 알려지지 않아 보안 솔루션에서 탐지되지 않는 공격

  • 원격 접속

텔넷이나 SSH, 원격데스크탑 연결 등 사용자 대화 방식(user interaction) 기반 통신은 해킹에 자주 사용되는 통신 방식이다.

다음 표는 침입탐지시스템에서 추출한 침입탐지 이벤트에 대한 정보를 요약한 표다.

탐지항목탐지정보
이벤트 수집 기간3개월
탐지 시그니처 이름TCP_Invalid_SACK
출발지 IP10.0.0.1
출발지 포트랜덤
도착지 IP랜덤
도착지 포트랜덤
총합1441 건
표 IDS 이벤트 분석 정보 요약

TCP_Invalid_SACK 라는 침입탐지시스템 시그니처는 비정상 SYN 패킷과 ACK 패킷에 의해 발생된다. 일반적으로 TCP 통신은 프로토콜에 정해진 방법으로 필요한 통신 패킷을 주고 받는다. 하지만 통신에 사용되는 프로그램이나 네트워크 특성에 따라 정해진 프로토콜과 다른 방식으로 통신하는 현상이 발생한다. TCP_Invalid_SACK 시그니처는 이러한 현상을 기록한다.

이러한 이유로 공격자가 비표준 방식의 프로그램을 사용할 때도 통신 내역이 탐지된다. 물론 탐지된 정보에는 공격자의 통신만 기록되진 않는다. 탐지된 1441건의 이벤트에 공격자가 통신한 횟수는 소수일 것이다. 보안 분석가는 이벤트 분석을 통해 소수의 공격 탐지 건수를 찾아야 한다.

정상 통신과 비정상 통신을 구분하기 위해 먼저 전체 통신 내역을 하나의 큰 그림으로 정리할 필요가 있다. 각각의 날짜에 어떤 포트들이 사용됐고, 사용된 횟수를 누적한 정보를 표로 정리할 수 있다.

포트 통신 통계

표를 작성하는 과정은 유튜브 영상을 참고 할 수 있다.

이제 추출한 로그에서 어떤 공격이 발생했는지 같이 분석해 보자.

정상 통신과 비정상 통신의 차이가 무엇 일까?

그 차이를 구분하기 위해서는 여러분들은 정상 통신과 비정상 통신의 기준을 만들어야 한다. 정상과 비정상 통신의 차이를 접속횟수라는 기준으로 가정해 보자. 좀더 구체적으로 이전보다 갑자기 접속횟수가 4배 이상 증가된 경우 비정상 통신으로 가정해 보자.

앞서 표로 만들었던 통신 포트 통계를 다시 살펴보면 이상한 현상이 눈에 들어 올 것이다.

포트 통계 표에 22, 1501, 8002번 포트의 접속 횟수가 비정상적으로 증가 하거나 감소한 것으로 알 수 있다. 여기까지는 분석하는 사람의 가설에 의한 의심이고 정확한 분석을 위해서는 상세한 내역을 보고 판단하자.

각각의 통신 내역을 상세하게 살펴보자.

먼저 22번 포트의 통신 내역을 살펴보자. 의심스러운 통신 내용 중 어느 것을 먼저 볼지는 분석하는 사람들의 의도에 따라 적절히 판단하자.

이번 경우에는 사용자가 시스템에 명령(user interaction)을 주고 받을 수 있는 SSH통신이 위험도가 높기 때문에 SSH접근 내역에 대한 분석을 먼저 진행 했다.

엑셀로 추출한 로그를 분석할 때는 원본 정보가 변경되는 것을 막기 위해 파일을 복사해서 작업하거나 파일에 새로운 시트를 추가하고 복사한 정보를 가공하자.

분석할 정보가 22번 포트 통신에 대한 내용이기 때문에 나머지 통신에 대해서는 일단 제외 처리한다. 엑셀의 필터 메뉴를 이용해서 22번을 제외하고 모든 숨긴 후 탐지로그를 복사한다.

그림 SSH 탐지 로그 분석

도착지 포트(Target Port) 22번 포트에 대해서만 별도로 추출했기 때문에 이제 날짜별로 공격대상이 어떻게 이뤄지는지 살펴 보자.

날짜와 도착지 IP 컬럼만 선택해서 새로운 시트에 복사하고, 피벗 테이블을 작성한다.

그림 공격대상 분석

22번 포트로 통신한 도착지 IP에 대한 현황 정리가 완료 되었다. 하나의 출발지 IP에서 여러 도착지 IP에 접근을 했고, 접근을 시도했던 날짜도 19일에 집중되어 있다.

19일 날짜에 접속된 통신 내역을 다시 한번 상세하게 살펴본다.

19일에 발생된 침입탐지 로그만 선택해서 새로운 시트에 복사 한다. 복사한 로그를 다시 한번 피벗 테이블을 이용해서 시간대별 통신한 도착지 IP를 정리한다.

피벗 테이블을 만드는 방법은 다음 순서로 진행 한다.

  • 피벗 테이블을 생성하고 행 필드에 시간을 끌어서 이동
  • 열 필드에 Target IP를 끌어서 이동
  • 값 필드에 Target IP를 끌어서 이동
그림 시간대별 통신 분석 1
그림 시간대별 통신 분석 2

완성된 테이블을 살펴보자. 새벽 4시를 시작으로 서로 다른 시스템에 1~2회씩 통신이 약 30초에서 1분 간격으로 이뤄졌다.

이렇게 통신이 발생될 수 있는 유형은 대표적으로 다음 2가지 형태가 있다.

  • 예약된 작업에 의해 정기 점검
  • 스캐닝 프로그램에 의한 네트워크 포트 스캔 시도

예약된 작업의 경우는 매주 지정 요일이나 매달 지정날짜에 발생하기 때문에 해당되지 않는다. 스캐닝에 의한 접근 시도일 가능 성이 높다. 내부 시스템간에 스캐닝이 발생했다는 것은 출발지 IP가 공격자에 장악됐을 가능성이 매우 높다. 공격에 사용된 내부 시스템을 찾아낸 것이다.

공격자는 백도어가 설치된 내부 시스템(10.0.0.1)을 경유해 2차 공격을 수행했다.

사전에 수집했던 로그인 정보를 이용해 단순 스캔이 아닌 시스템 로그인에 성공했고, 접속한 시스템에 공격 스크립트를 실행했다.

공격자는 공격 스크립트를 통해 하드디스크에 ‘PRINCIPES’ 문자열로 채워서 디스크를 못쓰게 만드는 명령을 실행했다.

많은 탐지 로그 중에서 이전 대비 급격한 통신 횟수의 변화가 생긴 로그를 의심 행위로 간주했다. 짧은 시간(수초 간격)에 다수의 시스템에 접속한 시스템 로그를 추출했고, 상세 분석을 통해 공격자에 의한 시스템 피해를 확인했다.

특정 문구가 아닌 횟수 변화를 이용해 공격을 구분하는 방법이 임계치 기반의 분석 방법이다.

임계치 기반의 상관 분석을 위해서는 기본 프로파일 정보가 필요하다. 프로파일을 정의 하는 방법은 정상 상황을 정의하고 이에 벗어나는 상황을 분리한다.

앞서 살펴본 예제에서는 정상 상황의 통신은 꾸준하게 통신이 발생한다라는 프로파일을 정의 한 것이다. 이를 기준으로 꾸준하기 않은, 즉 “접속횟수가 이전보다 N배 이상 차이가 나는 것”을 의심스런 통신으로 정의 했다.

프로파일 정의에 사용될 수 있는 정보

  • 매시간 외부와 주고 받는 최대 트래픽 수치
  • 매일 외부와 주고 받는 최대 트래픽 수치
  • 비업무 시간 외부와 통신하는 내부 시스템 수

외부로 중요한 데이터가 유출되었다고 가정해 보자. 해당 데이터는 일반적으로 주고 받는 파일보다 매우 큰 파일이라고 했을 때, 아래 그래프와 같이 평상 시 트래픽을 벗어나 급증한 그래프는 해당 가설을 입증하는 데이터가 될 수 있다.

그림 임계치 기반 분석

통계학적인 관점에서 접근하는 방법으로 침입탐지시스템 로그를 이용해 다음과 같이 이상 통신에 대한 기준을 정의할 수 있다.

  • 공격자/피해자 분석

시스템에 이상이 발생하거나 악성코드가 설치된 시점을 기준으로 관련 이벤트를 검색하고 검색한 이벤트를 이용해 공격 대상을 추출한다. 특정 사건이 발생된 시간이 확인되면 이전에 발생한 이벤트를 분석한다. 침해사고가 발생되면 공격자에 대해 역추적하는 과정이다.

최초 공격을 위해 사전 공격 시점이 언제인지 분석을 하고, 이 후 취약점을 이용해 공격이 성공한 시점을 찾는다.

예제를 살펴보자. 침입탐지시스템 로그에서 공격을 시도한 IP와 공격자가 사용한 취약점을 분석하는 과정이다.

피해를 받은 대상 시스템을 구분하기 위해 침입탐지시스템 로그에서 공격 대상별로 이벤트 발생 시간을 목록화 한다. 단순 스캔 시도한 탐지 로그를 제외하고 대상 시스템을 목록화 한다.

다음 표처럼 대상 시스템 목록과 각각의 대상 시스템이 8월 한달 동안 공격 받았던 취약점 종류(탐지수), 공격자 IP 종류를 목록화 한다.

대상시스템탐지수공격자IP 종류최초 이벤트 발생 시간최종 이벤트 발생 시간
타켓시스템1999445502015-08-01 0:002015-08-30 15:00
타켓시스템2651924332015-08-01 0:002015-08-30 15:00
타켓시스템37512015-08-01 0:002015-08-30 14:00
타켓시스템47412015-08-01 0:002015-08-30 14:00
타켓시스템5987814952015-08-01 0:002015-08-30 15:00
타켓시스템812842682772015-08-01 0:002015-08-30 15:00
타켓시스템679122015-08-02 0:002015-08-29 0:00
타켓시스템910722015-08-03 13:002015-08-27 15:00
타켓시스템7112015-08-05 15:002015-08-05 15:00
타켓시스템12712015-08-06 0:002015-08-27 23:00
타켓시스템101642015-08-06 16:002015-08-29 19:00
타켓시스템11912015-08-07 19:002015-08-25 10:00
표 공격 대상 시스템 목록

반대로 공격을 시도했던 공격자 IP를 목록화 하고, 침해사고 원인을 역추적하는 방법도 있다.

 다음 표는 공격자 IP별로 탐지된 이벤트 종류와 피해 IP 건수를 정리한 결과다.

공격자 IP탐지수피해IP 종류최초 이벤트 발생 시간최종 이벤트 발생 시간
공격자1312010-08-02 00:00:002010-08-27 00:00:00
공격자2312010-08-02 00:00:002010-08-18 00:00:00
공격자31612010-08-02 12:00:002010-08-25 12:00:00
공격자4212010-08-03 12:00:002010-08-24 00:00:00
공격자52612010-08-04 00:00:002010-08-10 12:00:00
공격자61012010-08-04 12:00:002010-08-27 12:00:00
공격자7712010-08-05 00:00:002010-08-25 00:00:00
공격자8212010-08-09 00:00:002010-08-09 12:00:00
공격자9212010-08-16 17:00:002010-08-16 17:00:00
공격자10112010-08-17 11:00:002010-08-17 11:00:00
공격자11612010-08-18 12:00:002010-08-20 00:00:00
공격자12112010-08-29 00:00:002010-08-29 00:00:00
표 공격자 IP 목록