앞서 보안 위협 분석을 위해 어떠한 정보가 필요한지와 필요한 정보를 수집하는 방법을 살펴 봤다. 이번 장에서는 수집한 정보를 분석해 위협이 되는 이벤트와 그렇지 않은 이벤트를 구분하는 방법을 살펴 볼 것이다.
일반적으로 보안분석가가 보안 위협을 구분하는 과정은 다음과 같다. 보안 위협이나 피해 형태에 따라 필요한 방법론을 정의 하고, 방법론에 적합한 증거를 수집한다. 수집한 증거는 가공 과정을 거쳐 분석에 필요한 정보를 찾아낸다. 분석된 결과는 업무프로세스에 따라 보고 과정을 거쳐 최종적으로 의사 결정자에 의해 결론을 정의 한다.
분석에 사용될 방법론은 위협을 구분하고, 식별하기 위해 어떤 방법을 사용할지 정의 하는 것이다. 공격과 관련된 알려진 특징을 이용할 수도 있고, 수집된 정보를 가공해 통계적인 수치를 이용해 위협을 식별할 수도 있다.
필요한 분석 방법에 따라 수집되는 정보도 차이가 난다. 공격의 특징을 이용해 위협을 분석하기 위해서는 시그니처 기반의 탐지 정보가 필요하지만 통계정보를 이용하기 위해서는 수치화된 정보가 필요 하다.
필요한 정보가 수집이 완료되면 데이터를 가공해서 불필요하거나 분석 우선 순위가 낮은 데이터를 제외한다. 처음부터 끝까지 모든 정보를 분석하면 좋겠지만 제한된 시간과 자원을 가지고 분석하기 때문에 효율적으로 작업 해야 한다.
데이터가공까지 완료되면 위협을 식별하고 식별된 위협 결과에 따라 피해범위와 대응방안을 수립한다. 분석가에게 중요한 역량은 IT보안사고와 연관된 원인을 정확히 규명하고 사고로 인한 피해 범위를 정확히 파악하는 것이다. 분석가의 결론으로 기업이나 조직에 미치는 피해 범위를 정의한다.
분석된 내용은 보고서로 작성해서 대응방안과 함께 의사결정자에게 제공한다. 분석 결과는 의사 결정에 필요한 필수 정보로 사용된다.
정보보안 통합 솔루션 플랫폼을 이용해 애플리케이션 로그, 시스템 로그, 보안 솔루션 로그 등 다양한 이기종 장비에 대한 통합 분석이 가능하다. 보안 업무 수행 시 가장 많은 리소스를 소모하는 과정은 사고 발생 조사 과정에서 보안 이벤트 분석이다. 단편적으로 남아 있는 보안 로그를 사고 분석가나 관제팀에서 추적하면 연결고리를 찾아 분석하기 때문에 시간이 많이 소요된다. 대규모 사고 발생 시 사고분석에 오랜 시간이 걸리는 원인도 이러한 로그를 찾아 추적하고 분석하는데 시간이 많이 소요되기 때문이다.
SIEM 제품과 같은 통합 보안 솔루션은 다양한 보안로그와 시스템로그를 통합해 이상 탐지 및 사이버 보안 위협 탐지 기능을 제공한다. 대표적인 통합 플랫폼인 Elasticsearch Security 제품의 무료버전을 설치해 보자. 트라이얼 기능을 이용해 임시로 유료 기능도 활용해 볼 수 있다.
Elasticsearch Security 플랫폼은 XDR 플랫폼으로서 엔드포인트 컴포넌트인 EDR 에이전트와 중앙관리 서버(Fleet)를 포함해서 다음과 같이 구성된다. Elasticsearch 엔진과 Kibaba(키바나), 플릿(Fleet) 서버를 통해 XDR 플랫폼으로 실시간 보안 위협 탐지와 예방, 대응 기능을 제공한다.
윈도우, 리눅스 계열 운영체제에 따라 필요한 설치 파일을 다운받아 설치를 진행한다. 우분투 기반의 운영체제에서 데비안 패키지 파일을 이용해 설치하는 과정을 살펴 본다. 설치 후 30일 동안 트라이얼 라이센스를 적용하면 모든 기능을 활용하거나 테스트할 수 있다. 설치 가이드 설명을 참고해서 데비안 패키지 파일을 다운로드 받는다. 설치 환경에 따라 설치 패키지 파일명이 다르다. 맥운영 체제 기반의 가상 환경에서 설치를 하기 위해 amd64 버전이 아닌 arm64 버전의 설치 파일을 다운로드 받았다. 설치 시 플랫폼에 따라 필요한 설치 파일은 링크[1]에서 직접 확인 후 다운로드 가능하다.
설치 파일 다운로드가 완료되면 패키지 설치 명령을 통해 설치를 진행한다. 명령 실행 시 설치 파일명은 다운받은 파일명에 맞게 적용한다.
sudo dpkg -i elasticsearch-9.0.0-amd64.deb
설치가 완료되면 시스템 데몬은 다시 적용하고 재부팅 이후에도 Elasticsearch 서비스가 동작하도록 등록한다. 명령은 설치 CLI 화면에 내용을 복사해서 실행한다.
그림 Elasticsearch 설정
설치 과정에서 elastic 계정 패스워드를 별도로 메모한다. 키바나(Kibana) 설치 후 시스템 로그인 과정에 인증 정보가 필요하다.
그림 Elasticsearch 설치정보
설치가 완료되면 서비스를 시작하고 정상적으로 실행되었는지 확인한다.
그림 Elasticsearch 서비스 시작
서비스 상태가 실행상태를 확인하면 설치가 완료된다. Elasticsearch 설치가 완료되면 키바나(Kibana)를 설치한다. 키바나는 사용자가 Elasticsearch SIEM 기능을 운영하기 위해 필요한 웹 기반의 사용자 GUI 이다. Kibana GUI의 주요 기능은 다음과 같다.
데이터 시각화: 로그, 대시보드
보안 룰 설정 및 경보 설정
자산 정보 관리 및 RISK 관리
보안 경고 및 사고 조사
클라우드 보안 관리
그림 키바나 대시보드 예제
키바나 설치 파일은 링크[1]를 통해 다운로드 한다. 데비안 패키지 파일을 다운받기 위해 설치 파일 종류를 선택한다.
정상 구동이 이뤄지면 키바나 설정 파일을 수정한다. 키바나 서버에 원격으로 접근하기 위해서 설정을 변경하다.
# vi /etc/kibana/kibana.yml
설정 파일의 “server.host” 항목을 호스트 IP 또는 0.0.0.0 으로 설정하면 원격에서 접근이 가능하다. 키바나에 원격 접근을 허용하는 경우 권한 없는 사용자의 접근을 제안하기 위해 시스템에 대한 Iptable을 활용하거나 네트워크 기반의 접근 제어를 적용하는 작업이 선행되어야 한다. 기타 설정 항목들은 향후 필요한 경우 개별 수정 할 수 있다.
그림 키바나 원격접근 설정
Elasticsearch와 키바나의 설정이 변경되면 변경된 설정을 적용하기 위해 서비스를 재시작해야 한다.
키바나의 사용시 민감한 데이터를 보호하기 위한 암호화 키를 적용할 수 있다. Root 권한으로 키바나 암호화 키를 생성한다.
사이버 보안 침해사고가 발생하면 기업은 내부적으로 침해사고분석을 통해 공격자의 흔적을 찾아내고, 공격 당시 사건을 재구성하여 시스템에 발생한 피해를 파악 합니다.
시스템에 침해가 발생하기 까지는 많은 일들이 발생 합니다. 공격자가 시스템을 공격하고 장악하기 위해 정보 수집 과정을 거치게 됩니다. 이 과정에서 공격자는 대상 시스템의 서비스 종류, 시스템 현황, OS종류, IP대역, 포트정보, 취약점 정보 등 많은 정보를 수집하게 됩니다.
외부의 공격자가 정보 수집을 통해 충분히 공략할 대상 시스템의 약점을 파악했으면 취약점을 이용해 공격에 들어가게 됩니다. 보통 이 과정에서 많은 수의 공격이 탐지되고 차단이 됩니다. 공격자는 가능한 모든 방법을 동원해 탐지되지 않기 위해 우회 시도를 하고, 100번의 공격 중 1번의 공격이 성공하게 되면 공격 성공 단계에 이르게 됩니다. 바로 이 단계가 침해가 발생되는 시점 입니다.
시스템 장악에 성공하면 공격자는 자신의 목적에 따라 시스템에 악성코드를 설치하거나 시스템의 정보를 유출하는 행위가 이뤄지고, 많은 경우 침해사고 발생에 대한 인지는 정보 유출 또는 시스템 변조가 발생되고 이뤄지게 됩니다.
보안팀은 공격을 탐지하고 예방하기 위해 다양한 방법을 이용해 침입시도에 대해 모니터 합니다. 주로 네트워크에서 발생되는 정보를 활용하게 됩니다. 가장 많이 사용되는 정보는 침입탐지시스템에서 제공하는 정보 입니다. 시스템에 가해지는 공격시도나 공격행위에 대해 네트워크 레벨에서 사전에 분석해 파악하고, 차단하면 시스템 침해를 예방할 수 있습니다.
최근 보안 사고가 연속적으로 발생하고 이로 인한 개인정보유출과 랜섬웨어로 인한 피해가 발생 하였습니다. 공격자가 공격 대상의 약점을 악용해서 큰 피해로 이어지게 만들었던 사례입니다.
개인정보 유출 사례의 경우 공격자는 제로데이 공격이 아닌 이미 알려진 악성코드를 사용했던 것으로 확인되었고, 공격자가 취약한 시스템을 알려진 악성코드를 이용해 공격이 성공하였습니다.
보안 사고 사례: BPFDoor 유즈케이스
개인정보 유출 시 사용된 공격 프로그램은 BPFDoor라 불리는 리눅스 운영체제 기반의 백도어 프로그램 입니다. 해당 공격에 사용된 악성코드는 Elastic 보안 연구소에서 2022년 보안 블로그를 통해 동작 방식 및 예방 방법에 대해 공유 하였습니다.
BPFDoor 는 Linux용으로 특별히 제작된 백도어 입니다. 이 백도어의 목적은 공격 대상 환경에 반복적으로 재진입하기 위해 장기간 시스템에 숨겨진 백도어 역할을 수행 합니다. 특히 BPF를 비롯한 여러 기술을 활용하여 최대한 은밀하게 작동하도록 설계 되어 있습니다.
패시브 형태로 백도어가 동작하기 때문에 평상시 가동 시간이 높은 서버나 기기, IoT/SCADA, 또는 인터넷에 접속 가능한 클라우드 시스템에 설치되도록 설계되었습니다. 특히 서비스 특성 상 메인터넌스나 재부팅이 어려운 시스템에 지속적으로 상주하여 공격자의 백도어 역할을 수행 합니다. 공격 프로그램에서 사용하는 파일은 임시 폴더에 저장되므로 서버가 재부팅 되거나 종료될 경우 백도어가 손실됩니다.
이 악성코드가 시스템에서 발견될 경우, 초기 접근(1단계) 또는 사후 공격(2단계) 페이로드가 여전히 존재하고 환경의 다른 곳에서 활성화되어 있을 가능성이 높다고 가정해야 합니다. 이 백도어는 은밀하게 침투하여 탐지되지 않을 모든 기회를 포착합니다. 샘플 코드를 통해 확인된 BPFDoor의 동작 과정 입니다.
예외 샘플 분석
주목할 점은 1~4단계가 나타나지 않는 샘플이 하나 있다는 것입니다 . 이 샘플은 초기 이름을 하드코딩된 값으로 변경하지 않고, 배치된 위치에서 실행하며, 그 외에는 동일한 동작을 모델링합니다.
실행 시 바이너리는 자신을 /dev/shm/에 복사합니다. 임시 파일 시스템인 /dev/shm은 공유 메모리를 의미하며, 프로세스 간 효율적인 통신 수단으로 사용되는 임시 파일 저장 공간입니다.
프로세스 이름을 하드코딩된 프로세스 이름인 kdmtmpflush로 변경합니다.
-init 플래그로 자신을 초기화하고 자신을 fork합니다. Linux에서 fork는 호출 프로세스를 복제하여 새 프로세스를 생성하는 것을 의미합니다.
자신을 위한 새로운 프로세스 환경을 생성하고 기존 프로세스를 제거하며, 새 프로세스 이름을 설정(스푸핑)합니다. 마치 마스크를 쓴 것처럼 시스템에 나타나는 방식을 변경합니다. 프로세스는 여전히 kdmtmpflush이지만, ps를 실행하면 설정된 값을 볼 수 있습니다.
/var/run에 프로세스 ID(PID) 파일을 생성합니다. PID 파일은 연관된 프로그램의 프로세스 정보를 담고 있는 텍스트 파일로, 다중 시작을 방지하고, 상주 상태를 표시하며, 프로그램이 스스로를 중지하는 데 사용됩니다. 이 파일은 또 다른 임시 파일 저장 공간인 /var/run에 있습니다.
원시 네트워크 소켓을 생성합니다. Linux에서 소켓은 네트워크 통신의 엔드포인트로, 패킷의 모든 섹션을 세부적으로 지정할 수 있도록 하여 사용자가 인터넷(IP) 수준에서 자체 전송 계층 프로토콜을 구현할 수 있도록 합니다.
원시 소켓에 BPF 필터를 설정합니다. BPF를 사용하면 사용자 공간 프로그램이 모든 소켓에 필터를 연결하여 특정 유형의 데이터가 소켓을 통해 들어오도록 허용하거나 거부할 수 있습니다.
들어오는 패킷을 관찰합니다
BPF 필터와 일치하고 필요한 데이터를 포함하는 패킷이 관찰되면 처리를 위해 백도어로 전달됩니다.
현재 프로세스를 다시 포크합니다.
포크된 프로세스의 작업 디렉토리를 /로 변경합니다.
포크된 프로세스의 이름을 하드코딩된 값으로 변경(스푸핑)합니다.
“매직 패킷”에 전송된 비밀번호 또는 비밀번호의 존재 여부에 따라 백도어는 역방향 셸을 제공하거나 바인드 셸을 설정하거나 ping을 다시 보냅니다.
아래에서 Elastic의 Analyzer View를 활용하여 BPFDoor 프로세스 트리를 시각적으로 확인할 수 있습니다. 첫 번째 이미지는 백도어(즉, 리버스 셸, 바인드 셸 또는 핑백)가 실제로 사용되기 전의 트리를 보여주고, 두 번째 이미지는 리버스 셸이 연결되고 익스플로잇 후 활동을 수행한 후의 트리를 보여줍니다.
그림 BPFDoor 초기 호출 프로세스 트리의 Elastic Analyzer 뷰
그림 Reverse Shell연결 및 공격 성공 후 BPFDoor의 Elastic Analyzer 뷰
원격 스캔 방식: TCP, UDP, ICMP 혼합 방식으로 포트 연결 시도 (예: 68/UDP → 53/UDP)
포트리스닝 없는 역접속 방식: 백도어는 포트를 열지 않고 “매직 패킷” 수신 시명령 실행
은폐 기법: 프로세스 이름 위장, 표준 스트림 닫기, 루트 권한으로 메모리 상 실행
Elastic Security Team은 BPFDoor 맬웨어를 분석하는 데 도움이 되는 몇 가지 도구를 만들었습니다. BPFDoor 스캐너를 사용하면 BPFDoor 맬웨어에 감염된 호스트를 스캔할 수 있으며, BPFDoor 구성 추출기를 사용하면 맬웨어의 구성이나 하드코딩된 값을 추론하여 추가 분석, 추가 시그니처 개발 또는 클라이언트를 활용한 백도어 연결에 사용할 수 있는 추가 관찰 결과를 얻을 수 있습니다.
BPFDoor 백도어가 왜 그렇게 오랫동안 사용되면서 숨겨진 채로 남아 있었는지를 알기 위해 동작 방식을 설명 했습니다. Linux 운영체제의 이상 프로세스 대해 잘 모르거나 자세히 살펴보지 않았다면 쉽게 탐지되지 않을 것입니다. 탐지를 피하기 위해 은밀하게 동작하지만, 행위 기반 탐지 방식과 시그니처 기반 탐지 방식을 통해 충분히 탐지와 차단이 가능 합니다.
Elastic Endpoint 제품인 Elastic Defend에서 대응 과정을 살펴 보겠습니다.
악성코드 초기 실행 시 관찰된 동작에 주목 합니다. 특히 이상행위는 공유 메모리 위치인 /dev/shm 디렉터리에서 발견 되었습니다. 이 디렉터리는 Linux의 기본 임시 파일 시스템 위치로, RAM을 저장 공간으로 사용하며, 이 디렉터리에서 바이너리가 실행되거나 네트워크 연결을 생성하는 것은 실제로 매우 드뭅니다.
두 번째로 /var/run에 특정 PID 파일이 생성을 통해 악성코드 탐지 및 예방 입니다. Osquery 통합 기능을 통해 /var/run 디렉터리에 드랍된 PID 파일이 완전히 비어있는 것을 발견했습니다. 드랍 파일 자체가 악의적인 것은 아니지만, PID 파일 크기가 0이거나 10바이트 정도인 경우는 드물기 때문에 이러한 비정상적인 동작을 탐지하기 위한 추가 탐지 Rule을 만들었습니다.
침해사고 분석 시 시스템에 동작 중인 프로세스를 확인하는 과정이다. 침해사고에서 발견되는 공통점 중 하나가 악성코드다. 이 악성코드는 별도로 실행되기도 하지만 많은 수의 악성코드가 시스템에 구동중인 기존 프로세스를 감염시킨다. 시스템에서 구동중인 프로세스가 정상인지 비정상인지를 판단해야 한다. 점검 방법은 운영체제에서 제공하는 기본적인 프로세스에 대한 정보를 활용할 수도 있고, 백신프로그램을 이용해 검사를 해볼 수도 있다.
감염된 프로세스에서 사용중인 파일을 찾는 작업이 쉽지는 않다. 프로세스에서 사용하고 있는 파일들이 생각보가 많을 것이다. 프로세스에서 참조하는 많은 파일들이 정상 파일인지 확인해야 하고, 감염된 프로세스가 외부로 통신을 하고 있으면 통신목적을 확인해야 한다. 프로세스를 뜯어보기 위해 어떤 과정이 필요하고, 어떤 툴을 사용하는지 방법을 소개하고자 한다. 물론 책에서 소개한 방법이나 프로그램 외에도 많은 방법이 있다. 자신의 스타일에 맞는 방법이나 프로그램을 이용할 것을 추천 한다.
악성코드에 감염된 시스템에서 채증 또는 확보한 파일은 분석 전용 시스템으로 이동해 분석하자.
프로세스 정보 수집
침해사고 분석 시 프로세스 정보를 수집하기 전에 전반적인 시스템 정보를 다시 한번 확인한다. PSINFO 프로그램을 이용해 시스템 기본 정보를 확인한다.
기본 정보를 확인하는 목적은 단순한 정보에 침해의 중요한 실마리가 되는 정보들이 숨어 있기 때문이다. 예를 들어 업타임(Uptime) 정보는 시스템이 기동된지 얼마의 시간이 지났는지 정보를 제공 한다. 일부 악성코드의 경우 시스템에서 프로세스를 감염시키는 과정에서 얘상치못한 프로세스 또는 시스템 오류를 발생시키곤 한다. 이때 장비가 재부팅되기도 한다.
최초 악성코드 감염은 시스템이 기동되고 운영중인 상태에서 발생한다. 이 경우 다른 프로세스들과 기동 시간을 비교해보면 중간에 시작된 프로세스들이 생기는되 이러한 프로세스를 먼저 살펴볼 필요가 있다.
업타임 정보외에도 응용프로그램들의 버전 정보나 운영체제의 버전 정보도 확인할 필요가 있다. 기본에서 시작하면 복잡한 침해사고도 의외로 쉽게 풀린다.
리눅스에서는 ‘uptime’ 명령을 실행해서 윈도우에서와 동일한 정보를 수집 할 수 있다. 다음은 ‘uptime’ 명령을 실행한 예제이다.
이제 본격적으로 프로세스 리스트를 확인해 보자. PSLIST 툴을 이용해 점검 대상 시스템에 구동 중인 프로세스 리스트를 수집하자. PSLIST 툴은 각 프로세스의 PID, Elapsed Time(프로세스가 시작되어 현재까지 경과된 시간), CPU Time(CPU 사용 시간) 정보등을 확인할 수 있다. 다음은 툴을 실행시켰을 때 보여지는 각각의 항목에 대한 설명이니 참고하자.
항목
설명
Pri
우선순위
Thd
쓰레드수
Hnd
핸들수
VM
가상메모리
WS
워킹셋
Priv
Private 가상메모리
Priv Pk
Private 가상메모리 최대치
Faults
Page Faults
NonP
Non-Paged 풀
Page
Paged 풀
Cswtch
Context Switches
표 PSLIST 점검 항목
Elapsed Time은 해당 프로세스가 시작된 시점에 따라 차이가 발생된다. 일반적으로 주요 프로세스는 윈도우 시작 시 구동되기 때문에 윈도우 시작 시간과 거의 동일하다. 운영체제 업타임과 비교해서 시작 시 실행된 프로세스와 운영체제 구동 후 중간에 실행된 프로세스 정보 할 수 있다. 프로세스 PID의 경우도 시스템 시작 후 시간이 지날수록 실행되는 프로세스의 PID번호가 높아진다.
그림 PSLIST 실행
악성코드에 의해 생성된 프로세스 또는 감염된 프로세스 확인을 위해서는 프로세스에 대한 정보를 알고 있어야 한다. 하지만 프로세스는 구동 중인 환경에 따라 사용되는 종류도 다양하고, 특정 시스템에만 존재하는 프로세스도 있기 때문에 모든 프로세스에 대한 정보를 알고 있기는 힘든 것이 사실이다.
윈도우의 경우 다 음표와 같이 사이트를 통해 기본적인 프로세스에 대한 정보를 제공한다. 프로세스 점검 시 활용하면 도움이 될 것이다. 표는 윈도우를 기준으로 한 기본 프로세스에 대한 정보이다.
프로세스 이름
설명
Csrss.exe (작업관리자에서 종료 불가)
Win32.sys가 Win32 subsystem의 커널모드 부분인데 비해서 Csrss.exe는 사용자모드 부분이다. Csrss는 Client/Server Run-time SubSystem의 약자로 항상 돌고 있어야 하는 필수 subsystem 중 하나이다. 콘솔 창, 쓰레드 생성 및 제거 및 16비드 가상 도스 환경의 일부를 관리한다.
Explorer.exe (작업관리자에서 종료 가능)
작업관리줄, 바탕화면 등과 같은 사용자 셸로서 Windows의 작동에 있어 필수적인 요소가 아니며 시스템에서 아무런 부작용 없이 작업관리자에서 종료 및 재시작이 가능하다.
Internat.exe (작업관리자에서 종료 가능)
시스템 시작과 함께 구동되는 프로세스로 사용자가 지정한 여러가지 입력 로케일 (HKEY_USERS.DEFAULTKeyboard LayoutPreload키에서 뽑아낸다)을 구동한다. 시스템 트레이에 “EN” 아이콘을 띄움으로써 사용자가 입력로케일간에 변환을 손쉽게 할 수 있도록 한다. 작업관리자를 통해 이 프로세스를 종료하면 “EN” 아이콘도 disable되는 것처럼 보이지만 제어판을 통해 입력로케일간의 변환이 가능하다.
Lsass.exe(작업관리자에서 종료 불가)
로컬 보안 인증 서버로서 Winlogon 서비스가 사용자를 인증하는데 필요한 프로세스를 만들어 내고 이 프로세스는 Msgina.dll과 같은 인증 패키지를 이용함으로써 수행된다. 인증이 성공하면 Lsass는 해당 사용자의 Access Token을 생성하고 이를 이용해 초기 셸이 구동된다. 동 사용자가 초기화하는 다른 프로세스들은 이 Access Token의 지위/속성을 승계한다.
Mstask.exe (작업관리자에서 종료 불가)
사용자가 미리 지정한 시간에 작업을 실행시키는 Task Scheduler Service
Smss.exe (작업관리자에서 종료 불가)
사용자 세션을 시작시키는 세션 관리자 subsystem으로서 시스템 쓰레드에 의해 초기화되며 Winlogon 및 Win32 (Csrss.exe) 프로세스를 구동하고 시스템 변수를 설정하는 등의 다양한 활동을 담당한다. 이들 프로세스를 구동시킨 다음 Winlogon이나 Csrss가 종료할 때까지 대기하되, 종료가 정상적으로 이루어지는 경우엔 시스템이 종료하고 그렇지 않은 경우엔 시스템을 반응없음(Hang)상태로 만든다.
Spoolsrv.exe (작업관리자에서 종료 불가)
스풀된 프린트/팩스 작업을 책임지는 spooler service
Svchost.exe (작업관리자에서 종료 불가)
DLL로부터 구동되는 다른 프로세스들에 대한 호스트로서 작동하는 generic process이기 때문에 2개 이상이 생길 수도 있다. Svchost.exe를 이용하는 프로세스들의 명세를 확인하려면 윈2000 CD에 있는 Tlist.exe를 이용하면 되고 구문은 명령 프롬프트에서 tlist -s 이다.
Services.exe (작업관리자에서 종료 불가)
시스템 서비스들을 시작/종료/상호작용하는 역할을 담당하는 Service Control Manager
System (작업관리자에서 종료 불가)
대부분의 시스템 커널모드 쓰레드들이 System 프로세스로서 실행된다.
System Idle Process (작업관리자에서 종료 불가)
각각의 프로세서(CPU)에서 돌고 있는 단일 쓰레드로서 시스템이 다른 쓰레드들을 프로세싱하지 않을 때 프로세서 타임을 관리하는 역할을 수행한다. 작업관리자에서 이 프로세스가 프로세서 타임의 대부분을 차지해야 시스템이 빠른 속도를 낼 수 있다.
Taskmgr.exe(작업관리자에서 종료 가능)
작업관리자를 위한 프로세스
Winlogon.exe(작업관리자에서 종료 불가)
사용자 로그온 및 로그오프를 관리하는 프로세스로서 사용자가 Ctrl+Alt+Del를 눌러서 보안 대화상자를 띄울 때만 활성화된다.
Winmgmt.exe(작업관리자에서 종료 불가)
윈2000에서 클라이언트 관리의 핵심 구성요소로서 클라이언트 응용프로그램이 처음 연결될 경우 또는 관리 응용프로그램이 서비스를 요청할 때 초기화된다. 작업관리자에서 종료할 수 없는 프로세스들의 대부분은 Resource Kit 유틸인 Kill.exe를 이용하여 종료가 가능하지만 system failure나 기타 다른 부작용을 야기할 수 있다.
표 기본 프로세스 정보
한가지 분석 팁은 점검 대상과 동일한 버전의 깨끗한 상태의 운영체제를 설치해 프로세스 리스트를 점검 대상 시스템과 비교하는 방법이 있다. 설치하기가 어렵다면 기존의 설치된 시스템을 활용할 수도 있다.
프로세스 리스트를 좀더 유기적으로 분석하기 위해서는 앞서 PSLIST실행 결과를 의존관계에 따라 확인하는 방법이 있다. 방법은 PSLIST 실행 시 옵션 선택을 통해 가능하다. –t 옵션을 이용하면 단순 리스트업이 아닌 자식과 부모 프로세스로 구분해 트리형태로 표시한다. 악성코드가 어떤 프로세스를 만들었고, 악성코드에 의해 생성된 하위 프로세스를 확인 할 수 있다. 다음이 실제 확인해본 결과다.
그림 PSLIST 실행 옵션
필요에 따라 PSLIST에서 제공하는 옵션을 확인해 적절히 사용하면 프로세스 정보 분석에 도움이 된다. 윈도우의 경우에 프로세스 분석 시 GUI형태로 제공되는 툴도 있다. PSLIST를 통해 확인이 어려운 부분은 추가로 툴을 이용해 분석 시 활용한다.
윈도우에서 “pslist –t”를 이용해 확인한 결과와 동일한 결과를 리눅스에서 ‘pstree’ 명령을 통해 얻을 수 있다. PS명령의 옵션을 이용하여 확인도 가능 하다. (ps –ejH, ps axjf)
‘pstree’ 명령을 이용해 히든프로세스 정보까지 확인 가능하다. 명령 실행 시 h옵션을 이용해 확인한다. 다음은 히든프로세스를 확인한 결과 화면 이다. 동일한 시스템에서 명령을 실행 시켰지만 옵션에 따라 결과를 다르게 나타난다. 그림의 왼쪽은 pstree 명령을 실행 시킨 결과이고 오른쪽은 ‘-h’ 옵션을 사용한 결과다. 동일한 bash 프로세스도 보여지는 결과가 다른다.
그림 pstree 실행 비교
w명령은 현재 로그인한 정보와 함께 사용자별 실행 중인 프로세스 정보까지 확인이 가능 하다.
다음은 w명령이 표시하는 목록에 대한 설명 이다
항목
설명
User
로그인한 사용자 이름
TTY
teletype – TTY는 타자기 형태의 키보드와 부착형 프린터 등을 갖춘 장치를 의미, tty값이 0또는 양수인 경우 콘솔을 통해 로그을한 것을 의미, tty항목이 pts로 표기 또는 ttyp#일 경우 네트워크를 통한 로그온이다.
From
네트워크를 통한 연결일 경우 원격지 IP주소, 콘솔을 통한 로그인일 경우는 표기하지 않음
Login@
최종 로그인 시간 표기
Idle
마지막으로 행위 후 활동을 얼마나 멈추고 있는지 나타낸다. 예를 들어 “w”명령을 입력한 후 5초 동안 아무런 입력이나 출력을 하지 않았다면 해당 시간이 5초로 표기된다. 2:14pm 5.00s 0.00s 0.00s -bash
JCPU
TTY항목에 나열된 각각의 로그인(네트워크 또는 콘솔)에서 사용한 CPU사용 시간 합이다. 지나간 백그라운드 잡은 포함하지 않고, 현재 걸려있는 백그라운드 잡은 합산 시간에 포함된다.
해커에 의해 시스템을 공격 받게 되면 그 흔적이 남게 된다. 운영체제와 네트워크 트래픽에 남아 있는 공격자의 흔적이 무엇인지 살펴 보자. 공격 흔적을 찾기 위해서 특정 툴이나, 내장 명령, 스크립트 등을 이용해 시스템에서 정보를 추출 할 것이다. 정보 추출을 위해 필요한 옵션과 분석 시 도움되는 정보들을 살펴보자.
운영체제 메모리에 올라와 있는 정보나 네트워크 통신 정보들은 시간이 지나면 사라지는 정보다. 휘발성 정보가 무엇이고, 어떤 흔적이 남아 있는지 살펴보자.
세션 정보 수집
시스템에 남아 있는 정보 중 네트워크 통신 정보는 연결이 종료되면 사라진다. 키로깅 프로그램이나 백도어 프로그램은 피해 시스템에서 수집한 정보를 전송 하기 위해 외부와 통신을 해야 한다. 외부와 통신하기 위해 피해 시스템에 설치된 악의적인 프로그램은 프로세스를 생성한다. 백도어가 사용하는 프로세스를 확인하면 사용되는 파일과 통신 대상 정보를 알아 낼 수 있다.
정보를 수집할 때는 시스템의 내장 명령이 조작되었을 가능성이 있기 때문에 점검에 사용할 실행 프로그램을 따로 준비하는 게 좋다.
시스템간에 연결된 통신을 세션이라고 부른다. 이 세션 정보를 수집하기 위해 ‘netstat.exe’ 명령을 이용한다. 명령 옵션은 다음과 같다.
-a: 모든 연결 및 수신 대기 포트를 표시합니다. -o: 각 연결의 소유자 프로세스 ID를 표시합니다. -n 주소 및 포트 번호를 숫자 형식으로 표시합니다.
‘ao’ 옵션과 함께 명령을 실행 시키면 다음과 같은 결과 화면이 출력 된다. 현재 시스템에서 연결된 모든 세션 정보가 화면에 출력된다.
그림 세션별 PID
확인된 전체 세션 목록을 점검하여 비정상 세션이나 사용하지 않는 세션을 추출하고, 해당되는 PID(프로세스ID)를 통해 의심되는 프로세스를 점검한다. 이 경우 순간적으로 통신을 맺고 바로 세션을 끊는 경우 확인이 어려울 수 있다.
일부 악성코드는 히든프로세스로 시스템에서 대기 하고 있다 일정 주기나 특정 조건에 의해 세션을 연결하여 통신을 시도하고, 통신이 완료되면 세션을 종료한다.
일회성으로 연결을 맺고 금방 사라지는 세션을 점검하기 위해 실시간 모니터링 프로그램을 이용한다. 실시간 프로세스 모니터링은 TCPVIew , Seem(구Ekinx) 프로그램을 이용하여 확인 할 수 있다. 자동스크립트를 이용해 주기적으로 세션 정보를 저장해 일괄 확인하는 방법도 가능하다.
GUI 기반의 모티터링 프로그램을 실행시키면 다음 그림처럼 현재 시스템에 형성된 세션 정보를 출력한다. 세션 정보는 1초마다 자동 업데이트 된다. 업데이트 주기는 사용자가 메뉴에서 변경 할 수 있다.
그림 실시간 프로세스 모니터툴
실시간 모니터링 프로그램을 이용하면 외부로 연결을 시도하거나 내부로 연결을 시도하는 IP 정보를 확인하여 연관된 프로세스를 추출 할 수 있다. 윈도우처럼 리눅스도 동일하게 확인 가능하다. 필요에 따라 옵션항목을 조절해 사용 할 수 있다.
생성된 세션이 비정상이거나 시스템과 관련이 없을 경우 해당 프로세스에 대해 좀더 자세히 점검하고, 실제로 프로세스가 사용중인 파일에 대해 점검한다. 다음으로 세션을 유발 시킨 실행 파일을 확인하는 방법을 살펴보자.
세션별 실행파일
윈도우 실행파일 별로 PID번호와 현재 연결 상태, Local&Remote IP, Port정보를 점검 한다. 프로세스정보와 함께 분석한다. 악성 코드에 의한 연결 인지 정상 통신인지 확인한다. 점검은 윈도우 내장 명령이 아닌 별도의 무료 프로그램을 이용해 점검 할 수 있다.
tcpvcon을 다운받아 윈도우 명령 창에서 다음과 같이 실행 한다.
tcpvcon -n /accepteula
프로그램을 실행시키면 아래처럼 실행 파일별 PID정보와 연결 상태 및 상세 정보를 확인 할 수 있다.
세션 정보를 수집하는 방법을 살펴 봤다. 이번에는 여러분이 수집한 통신 연결 정보와 상세 실행 파일 정보를 활용하는 방법을 살펴 보자.
침해사고 분석에 어떻게 활용될 수 있는지 다음 사례를 같이 살펴 보자.
사례 분석
스팸 메일이 유포되었던 시스템을 분석했던 사례다.
침해가 발생한 시스템에서 특정 수신인을 대상으로 스팸 메일이 발송 되었다. 침해사고가 발생한 시스템이 중간 경유 시스템으로 이용되었는지 여부에 대한 분석을 진행 했다.
점검 대상 시스템은 윈도우 운영체제가 사용되고 있었다. 네트워크 방화벽에서 웹 서비스를 제외한 원격 접근은 불가능 하였다. 서비스 확인 시 웹 서비스 외 추가 서비스는 구동하지 않았다.
스팸 메일이 발송된 원인을 조사하기 위해 침입탐지시스템(Intrusion Detection System) 탐지 로그를 확인 하던 중 의심스런 통신 내역이 확인 되었다. 사용하지 않는 암호화 통신(SSL, Secure Sockets Layer)통신이 발생된 것이 확인 되었다. 상세 분석 시 점검 대상 시스템을 통해 해외 웹 메일 사이트에 접근 내역이 확인 됐다. HTTPS 통신을 통해 외부 웹 메일 서비스를 이용하였다.
프록시 설정이 의심되었고, 점검 결과 스팸 메일이 발송된 시스템을 거쳐 웹 메일 사이트에 접속하였고, 웹 서비스에서는 스팸 발송자를 해당 IP로 지목했던 것이다.
익명 웹 프록시 설정이 활성화 돼있을 경우 해당 시스템을 통해 타 사이트로 접근이 가능하게 되고, 이 경우 아래와 같은 구조로 중간(B Server)에서 중계 역할을 한다.
공격자 -> 중간 경유 서버(프록시서버) -> 웹 사이트
분석한 시스템은 중간 경우 서버에 해당 된다. 웹 사이트에는 공격자 IP가 아니라 중간 경유 서버 정보가 남는다. 참고로 익명 프록시 설정이 열리게 되면 해당 정보는 익명 프록시 서버 목록에 올라간다. 이 정보는 관리자가 의도하지 않은 피해를 유발할게 될 수 있다.
그림 익명 프록시 허용 서버 목록
스팸 발송 IP로 의심된 서버는 익명 프록시 허용으로 피해가 발생한 것이다. 자 그럼 프록시 서버로 이용된 사실을 어떻게 확인했는지 살펴 보자.
점검항목
분석 결과
세션 정보
다수의 웹 서비스 세션이 확인80번 출발지 포트 아웃바운드 연결불특정 다수 사용자가 경유를 통해 타 사이트로 접근
취약 경로 분석
익명 프록시 접근 허용
로그점검
제공하지 않는 서비스 로그 확인경유로 인한 외부 서비스 URL 제공 로그
표 점검 요약
세션 분석 결과 다수의 아웃바운드 통신이 확인 됐다. 다수의 FIN_WAIT_2 상태가 확인 됐다.
FIN_WAIT_2 상태는 통신을 종료하는 과정에서 FIN 패킷을 전송하고 상대방에서 ACK를 수신하지 못해 기다리고 있는 상태를 의미 한다. 다음 그림에서 FIN을 보내고 두 번째 단계로 ACK와 FIN요청을 받아야 되는데 ACK 응답이 오지 않아 기다리고 있는 상태가 FIN_WAIT_2다.
일반적으로 웹 서버는 클라이언트에서 FIN 요청을 보내면 ACK 응답을 보낸다.
하지만 이 경우 웹 서버가 마치 클라이언트처럼 웹 서버에 FIN 요청을 보내고 또 다른 웹 서버의 응답을 기다리고 있었다(FIN_WAIT_2). 통신을 주고 받는 주체가 반대로 보였다. 이 정보를 기반으로 프록시 설정을 의심했다.
간편하게 파일 분석이 가능한 프로그램을 살펴 보자. 올리디버거를 이용한 파일 분석 방법은 책 한권 분량이 나올 만큼 양이 방대하다. 이미 올리디버거를 이용해 정적으로 악성코드나 파일을 분석하는 좋은 책들이 많이 있기 때문에 관련 내용을 참고하기 바랍니다.
침해사고분석 과정에서 악성코드로 의심되는 파일이 확보되면 해당 파일의 기능 분석을 수행한다. 수집된 악성코드를 별도의 분석 시스템으로 옮겨와서 분석할 수 있지만 경우에 따라서는 부득이 분석 대상 시스템에서 악성코드 분석을 수행하기도 한다. 시스템에 영향을 최소화 하고 악성코드로 의심되는 파일을 분석하는데 많이 사용되는 분석도구가 PEiD이다.
PEiD 프로그램은 정적으로 파일을 분석하는데 사용되고 실행파일의 API, 문자열 정보, 실행압축정보 등을 확인하는데 사용한다. 대표적인 기능과 함께 실제 PE헤더 파일을 분석해보자.
그림 PEiD
악성코드 샘플을 분석하는 것도 의미가 있지만 샘플을 구하기 어려운 경우 윈도우 시스템에 “cmd.exe” 파일을 분석해보는 것으로도 기능 파악에 도움이 된다.
분석할 PE파일을 불러 온다.
그림 PEiD 주요기능
문자열 검색
파일 디버깅을 통해서 파일에 포함된 식별 가능한 문자열 검색을 수행할 수 있다.
일부 악성코드의 경우 하드코딩 형식으로 마스터 서버에 접속할 IP정보를 PE파일안에 넣어 두기도 한다. 이 경우 악성코드가 어떤 IP로 접속하는지 혹은 어떤 프로그램인지 확인할 수 있다.
API 확인
실행 파일에서 사용되는 API를 통해서 대략적인 프로그램이 수행하는 행위에 대해 추측이 가능하다. 정확한 분석을 위해서는 디버깅 프로그램을 이용해 분석이 필요하겠지만, API를 확인하는 것으로 침해사고 분석에 필요한 정보를 확보할 수 있다.
그림 PEiD주요기능-API점검
PEiD는 현재는 업데이트가 중단되었다. 대체 도구는 아래 사이트를 참고해 필요한 목적에 맞게 사용할 수 있다.
효율적으로 침해사고 분석 업무를 수행하기 위해서 필요한 분석 도구를 살펴보자. 분석도구란 분석에 필요한 정보를 해석하고, 분석가가 쉽게 필요한 정보를 볼 수 있도록 도와주는 도구다. 이러한 분석 도구는 크게 네트워크 패킷 분석 도구와 로그 분석, 파일 분석 도구로 나눌 수 있다.
가장 많이 사용되는 와이어샤크에 대해서 살펴 보자. 예전 이더리얼이라 불렸던 와이어샤크는 무료로 사용할 수 있는 대표적인 패킷분석 프로그램 이다. 네트워크 트래픽 통계와 스트림 정보, 파일 추출 등 분석에 필요한 다양한 기능을 제공한다. 공격자에게 백도어가 있다면 분석가에겐 분석 도구가 있다.
와이어샤크는 분석가들 사이에 워낙 많이 사용되는 툴이기 때문에 기본적인 사용법은 홈페이지[1]를 참고하자. 우리는 분석할 때 유용한 메뉴를 중심으로 분석도구로서 사용하는 방법을 같이 살펴 볼 것이다. 그리고 간편하게 사용할 수 있는 네트워크마이너도 살펴볼 예정이다.
포렌식 관점에서 와이어샤크의 가장 유용한 기능은 패킷에서 파일을 추출하는 것이다. 먼저 파일을 추출할 pcap 파일을 불러온다. 파일을 불러오면 Export objects 명령을 이용해 파일을 추출하자.
File > Export objects
그림 와이어샤크(파일추출)
통신 프로토콜을 선택하다. HTTP 통신을 선택하면 다음과 같이 웹 통신을 통해 주고 받은 파일 목록이 나타난다.
그림 추출파일목록
Save All 명령을 이용해 전체 파일을 저장할 수 있고, 필요한 파일만 Save As 메뉴를 이용해 저장한다.
그림 추출파일저장
악성코드로 의심되는 파일을 추출하면 파일 분석 도구를 이용해 정적분석을 수행하거나, 가상머신에서 파일을 실행시켜 동적분석을 수행하는데 사용한다. 혹은, 기업이나 조직의 중요한 내부 문서가 외부로 유출되는 경우 의심 파일을 추출해서 증거로 사용한다.
트래픽 정보 확인
이상 트래픽을 분석하는 관점에서 와이어샤크가 제공하는 유용한 기능 중 하나는 저장된 pcap파일의 트래픽 정보를 통계적인 관점으로 제공하는 것이다. 와이어샤크에서 제공하는 메뉴 중에서 Statistic 메뉴를 활용하면 다양한 통계 정보를 확보할 수 있다.
Statistics -> IO 그래프
IO그래프를 분석에 활용하기 위해서는 필터링 항목을 적극 이용해야 한다. IO 그래프를 실행시킨 화면만으로는 이상 트래픽을 분석하기 위한 단서 정보를 찾기 어렵다. 아래 그림은 IO그래프를 실행 시킨 모습니다. 아래 그래프를 통해서 우리가 확보할 수 있는 단서는 12시 13분쯤 트래픽이 한차례 증가 되었고, 이후 12:14분에 다시 한번 트래픽 증가가 있었다는 내용이다.
그림 IO 그래프
좀더 분석을 효율적으로 하기 위해 우리는 각각의 프로토콜 별로 색깔을 다르게 그래프로 표시해 보자. 각각 프로토콜 별로 필터링을 통해 실제 의심 현상과 관련된 프로토콜 연관성을 확인하는 작업을 수행한다. 이러한 과정을 통해 많은 정보를 분석할 때 좀더 효율적으로 시간을 아낄 수 있다.
그림 IO 그래프그림 IO 그래프 패킷 필터 적용
Protocol Hierarchy
앞서 IO 그래프를 통해 전체 트래픽 중에서 이상 현상이 발생된 트래픽을 확인하는 과정을 수행 했다면, 실제 세부 트래픽을 분석하는 작업이 필요한데, 이때 statistic 메뉴 중에 프로토콜 하이라키를 이용하면 저장된 pcap 파일의 구조를 살펴 볼 수 있다. 전체 트래픽 중 패킷 비율이나 프토토콜 비율 확인을 통해서 분석의 단서를 찾아 나간다.
Statistics -> Protocol Hierarchy
그림 Protocol Hierarchy
패킷분석
효율적인 패킷 분석에 빠질 수 없는 것 중 하나가 패킷 필터이다. 기본적으로 표준 pcap 형식의 파일은 BPF(Berkeley Packet Filter)를 지원한다. 와이어샤크를 통해 불러온 pcap파일은 BPF 구문을 이용해 효율적으로 패킷 분석이 가능하다.
패킷 필터 구문 사용 시 기본 지원 되는 연산자 종류는 3가지가 있다.
연산자 종류
문법
AND 연산자
AND (&&)필터 구문간 AND 조합 연산샘플 구문 tcp.port == 80 && ip.addr == 74.195.238.237
OR 연산자
OR (||)필터 구문간 OR 연산샘플 구문 tcp.port == 80 || ip.addr == 74.195.238.237
NOT 연산자
NOT (!)지정 필터 구문에 대한 NOT 연산샘플 구문 tcp.port == 80 && !(ip.addr == 74.195.238.237)
필터 관련 문법은 와이어샤크 프로그램에서 자동완성 형식으로 저장되기 때문에 복잡한 구문을 일일이 외우고 있을 필요 없다. 필요한 프로토콜을 지정하면 사용 가능한 문법이 자동 완성 된다.
그림 패킷필터구문
네트워크마이너(NetworkMiner)
네트워크 패킷 분석 도구 중에 네트워크마이너에 대해서 살펴보자. 앞서 패킷 분석 작업에 가장 많이 사용되는 와이어샤크를 살펴 보았다. 와이어샤크를 사용하기 위해서는 프로토콜에 대한 이해도 필요하고 정보를 찾기 위해 프로그램에서 제공하는 메뉴에 대해 공부가 필요하다. 하지만 이번에 살펴볼 네트워크마이너는 쉽고 강력하게 분석가에게 필요한 정보를 제공하는 툴 중에 하나다. 저장된 pcap 파일을 프로그램에 불러오면 자판기에서 먹고 싶은 음료수를 누르듯이 필요한 정보를 클릭하기만 하면 된다.
프로그램을 실행하고 분석할 pcap파일을 오픈하면 자동으로 각각의 메뉴에 맞게 패킷을 가공 한다.
그림 네트워크마이너
분석가는 각 탭을 하나씩 클릭해서 분석에 필요한 정보를 하나씩 살펴 보면 된다. 복잡하게 필터 문법을 사용하거나 메뉴을 하나씩 클릭할 필요 없이 쉽게 필요한 정보를 마우스 클릭으로 찾아서 사용하면 된다. 어려운 툴을 사용해야만 고급 분석을 할 수 있는 건 아니다. 상황과 조건에 맞게 적합한 툴을 사용하는 것이 분석 도구를 선택하는 중요한 기준이다.
네트워크 기반의 패킷 분석 프로그램을 살펴 보았고, 이제 파일 기반의 분석 프로그램을 살펴보자.
전문 침해 대응 업무를 수행하기 위해서 필요한 기술의 종류는 다양하다. 트래픽 분석에서부터 악성코드 분석까지 보안 업무의 분야가 다양한 만큼 필요한 기술의 종류도 여러 가지다.
전문 침해 대응 업무를 수행하기 위해서 필요한 대표적인 업무 스킬 항목을 살펴 보자. 각 업무 마다 기술 수준에 따라 초급, 중급, 고급으로 나눌 수 있다. 기술수준을 나눌 때 어떤 기준으로 나누는지 표를 통해 살펴 볼 것이다. 해당 수준 정의는 조직이나 기업의 상황에 따라 차이가 발생할 수 있다.
패킷 분석 레벨
Beginner
단일 패킷 분석 – 처음 패킷을 분석하는 분석가는 개별 패킷을 구분하고 패킷 내용을 이해 합니다. 단편화된 패킷의 헤더와 페이로드 구성을 이해할 수 있습니다.
헤더 정보 이해 – 패킷 헤더에 포함된 프로토콜 정보를 이해 할 수 있습니다. TTL 의미와 IP Flags, Fragment Offset이 의미하는 내용을 이해할 수 있어야 합니다.
응용프로그램 식별 – 패킷 데이터의 페이로드 정보를 통해 통신 애플리케이션(응용프로그램)이 무엇인지 식별할 수 있어야 합니다. 식별을 위해 HTTP/FTP/SSH 등 응용 프로그램 프로토콜 통신 형식에 대해서 이해가 필요 합니다.
IP/Port정보 식별 – 클라이언트와 서버의 통신 주소와 통신 포트를 식별할 수 있습니다.
Intermediate
단일 패킷 분석 – 패킷을 분석하는 분석가는 개별 패킷을 구분하고 패킷 내용을 이해 합니다. 단편화된 패킷의 헤더와 페이로드 구성을 이해할 수 있습니다.
헤더 정보 이해 – 패킷 헤더에 포함된 프로토콜 정보를 이해 할 수 있습니다. TTL 의미와 IP Flags, Fragment Offset이 의미하는 내용을 이해할 수 있어야 합니다.
응용프로그램 식별 – 패킷 데이터의 페이로드 정보를 통해 통신 애플리케이션(응용프로그램)이 무엇인지 식별할 수 있어야 합니다. 식별을 위해 HTTP/FTP/SSH 등 응용 프로그램 프로토콜 통신 형식에 대해서 이해가 필요 합니다.
IP/Port정보 식별 – 클라이언트와 서버의 통신 주소와 통신 포트를 식별할 수 있습니다.
페이로드 분석 – 통신 애플리케이션 형식에 대한 이해를 바탕으로 전달된 파라미터 정보를 구분할 수 있습니다. 정상 파라미터 유형에 대해서 이해하고 있습니다. HTTP 통신에 사용되는 표준 통신 메소드 종류. Ex. GET / POST / HEAD 등
공격 패킷 구분 – 공격 관련 통신 애플리케이션과 비정상 통신 애플리케이션 특징을 구분할 수 있어야 합니다. 페이로드 분석을 통해 정상 통신 패킷의 파라미터 정보와 공격을 시도하는 패킷을 구분할 수 있어야 합니다.
공격 경로 식별 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. HTTP URL 정보나 시스템 명령 실행 경로 등을 분석해서 공격이 발생한 대상과 위치를 식별할 수 있어야 합니다.
공격 영향 구분 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. 파악된 공격 유형과 패킷에 포함된 시스템 응답 정보를 분석해서 공격이 성공했는지 실패했는지 파악 할 수 있어야 합니다. 파악한 정보를 통해 시스템에 발생 가능한 영향을 분석 할 수 있어야 합니다.
Advanced
단일 패킷 분석/ 풀패킷 분석 – 패킷을 분석하는 분석가는 개별 패킷을 구분하고 패킷 내용을 이해 합니다. 단편화된 패킷의 헤더와 페이로드 구성을 이해할 수 있습니다. 전체 패킷을 조합해서 세션 기반의 통신 정보를 분석 할 수 있어야 합니다. 공격자가 시스템에 연결한 시간, 시스템과 주고 받은 전체 데이터 양, 다운받거나 업로드한 파일 정보를 분석할 수 있어야 합니다.
패킷 재조합, 패킷 필터 – 키워드 또는 통신 유형에 따라 패킷을 재 구성하거나 방대한 패킷에 분석에 필요한 패킷을 효율적으로 분석 할 수 있습니다.
헤더 정보 이해 – 패킷 헤더에 포함된 프로토콜 정보를 이해 할 수 있습니다. TTL 의미와 IP Flags, Fragment Offset이 의미하는 내용을 이해할 수 있어야 합니다.
응용프로그램 식별 – 패킷 데이터의 페이로드 정보를 통해 통신 애플리케이션(응용프로그램)이 무엇인지 식별할 수 있어야 합니다. 식별을 위해 HTTP/FTP/SSH 등 응용 프로그램 프로토콜 통신 형식에 대해서 이해가 필요 합니다.
IP/Port정보 식별 – 클라이언트와 서버의 통신 주소와 통신 포트를 식별할 수 있습니다.
페이로드 분석 – 통신 애플리케이션 형식에 대한 이해를 바탕으로 전달된 파라미터 정보를 구분할 수 있습니다. 정상 파라미터 유형에 대해서 이해하고 있습니다. HTTP 통신에 사용되는 표준 통신 메소드 종류. Ex. GET / POST / HEAD 등
공격 패킷 구분 – 공격 관련 통신 애플리케이션과 정상 통신 애플리케이션 특징을 구분할 수 있어야 합니다. 페이로드 분석을 통해 정상 통신 패킷의 파라미터 정보와 공격을 시도하는 패킷을 구분할 수 있어야 합니다.
공격 경로 식별 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. HTTP URL 정보나 시스템 명령 실행 경로 등을 분석해서 공격이 발생한 대상과 위치를 식별할 수 있어야 합니다.
공격 영향 구분 – 공격 패킷 페이로드에 포함된 정보를 분석해서 공격에 사용된 특징을 분석 할 수 있어야 합니다. 파악된 공격 유형과 패킷에 포함된 시스템 응답 정보를 분석해서 공격이 성공했는지 실패했는지 파악 할 수 있어야 합니다. 파악한 정보를 통해 시스템에 발생 가능한 영향을 분석 할 수 있어야 합니다.
이외에도 다양한 보안 관련 이벤트에 대해서 분석 가능한 역량이 구분 됩니다.
초급
중급
고급
패킷분석
단일 패킷 분석헤더 정보 이해응용프로그램 식별IP/Port정보 식별
단일 패킷 분석헤더 정보 이해응용프로그램 식별IP/Port정보 식별 페이로드 분석공격 패킷 구분공격 경로 식별공격 영향 구분
단일 패킷 분석/ 풀패킷 분석패킷 재조합, 패킷 필터헤더 정보 이해응용프로그램 식별IP/Port정보 식별 페이로드 분석공격 패킷 구분공격 경로 식별공격 영향 구분
로그분석
윈도우/유닉스 로그 타입 이해로그 저장 경로로그 내용 이해
윈도우/유닉스 로그 타입 이해로그 저장 경로로그 내용 이해비정상 로그 식별
윈도우/유닉스 로그 타입 이해로그 저장 경로로그 내용 이해비정상 로그 식별 트러블 슈팅원인 분석
네트워크침입탐지
IDS/IPS 이해오픈 소스(Snort)위험도 구분
IDS/IPS 이해침입탐지원리 이해오픈 소스(Snort)위험도 구분룰셋 이해기본 구성 및 설정
IDS/IPS 이해침입탐지원리 이해오픈 소스(Snort)위험도 구분룰셋 이해기본 구성 및 설정설정 최적화룰셋 제작네트워크 구성 및 설치
방화벽
방화벽 이해접근제어리스트(ACL)
방화벽 이해침입차단원리 이해접근제어리스트(ACL)ACL 작성
방화벽 이해침입차단원리 이해접근제어리스트(ACL)ACL 작성네트워크 구성 및 설치ACL 관련 고급 설정방화벽 운영 및 설정최적화
호스트기반침입탐지
HIDS 이해오픈 소스(OSSEC)
HIDS 이해침입탐지원리 이해오픈 소스(OSSEC)탐지 항목 이해룰셋 이해기본 구성 및 설정호스트 기반의 침입
HIDS 이해침입탐지원리 이해오픈 소스(OSSEC)탐지 항목 이해룰셋 이해기본 구성 및 설정호스트 기반의 침입HIDS 설치 및 구성 설계HIDS 탐지 및 수집 항목 정의
침입탐지시스템은 크게 2가지 형태의 탐지 방식을 갖고 있다. 시그니처 기반(misuse detection)과 행위기반이상(anomaly detection) 탐지 방식이다.
시그니처기반 이상탐지(misuse detection)
시그니처기반 이상탐지(misuse detection)은 침입탐지시스템 분석 엔진에서 패킷 정보를 수집하고 수집한 패킷에 대해 공격 시그니처 데이터베이스와 비교하여 공격 여부를 판단 한다. 이는 시그니처 데이터베이스에 존재하는 특정 패턴과 일치하는 경우 공격으로 판단하고 시그니처 데이터베이스에 있는 내용에 대해서만 공격 여부를 검증 한다. 다음이 흔히 웹 스캔을 시도했을 때 발생되는 URL요청의 일부로 이러한 URL요청을 데이터베이스에 저장하고 사용자의 요청에 해당 구문이 포함되는지를 확인해 공격성 여부를 판단하는 것이다.
장점 시그니처 기반 탐지라고 애기하는 Misuse detection은 특정 시그니처를 이용해 패킷에 포함된 데이터를 확인해 공격 여부를 판단 한다. 시그니처기반 이상탐지(misuse detection)에서 사용하는 시그니처는 공격과 관련된 특정한 행동, 변수, 인자값 등이 포합 된다. 시그니처 기반 탐지 방식은 다양한 이점이 있다. 그 중 한가지로 필드에 알려진 많은 수의 공격 행위가 시그니처로 작성 되었기 때문에 공격행위에 대해 다양하게 탐지가 가능하다. 공격 탐지 패턴을 이용해 쉽게 탐지할 공격 유형을 정의 하고 선택할 수 있다. 또한 시그니처 기반으로 탐지 시스템을 네트워크에 설치하면 별도의 학습과정 없이 바로 활성화 하여 탐지 및 방어를 할 수 있다. 마지막으로 탐지된 이벤트에 대해 쉽게 탐지 유형을 파악하여 적절한 행동을 취할 수 있다.
단점 다양한 이점만큼 다양한 문제점이 있다. 공격자의 공격행위에는 다수의 부가적인 행위가 포함 된다. 예를 들어 웹 공격을 시도하며사용하는 매개변수(특히 SQL Injection)가 사용자에 의해 변경될 경우 탐지 패턴이 없으면 탐지가 불가능해진다. 이처럼 시그니처를 이용해 공격 탐지 시 예측 가능한 변수를 포함하는데 한계가 있다. 또한 공격행위를 탐지 하기 위해서는 모든 행위에 대해 시그니처를 가지고 있어야 한다. 바꿔 말하면 시그니처가 존재하지 않는 공격 행위는 탐지가 불가능 하다는 의미가 된다. 이는 잦은 시그니처 업데이트가 필요함을 의미 하게된다. 공격자가 탐지를 우회할 목적으로 시그니처를 테스트 하고, 우회 가능한 공격 방식을 개발할 수도 있다.
행위기반 이상탐지(anomaly detection)
행위기반 이상탐지(anomaly detection)은 시스템 관리자가 특정한 사례 또는 환경에 대해 정상범위를 미리 정의 한다. 이는 트래픽이 될 수 있고, 웹 서버를 사용하는 사용자의 수가 될 수도 있다. 이 외에도 기준으로 사용 할 수 있는 항목으로 포트, IP, 프로토콜, 패킷 사이즈 등도 사용할 수 있다. 공격 또는 비정상을 구분하는 방법은 앞서 언급한 정상 범위, 즉 사전에 정의된 상황(프로파일)과 다른 상황이 발생되면 이를 비정상 상황으로 탐지 하는 방식 이다. 예로 평소에 웹서버에 접속하는 사용자가 오후 1시에 3만~4만명 사이라고 가정해 보자. 어느날 오후 1시에 웹서버에 접속하는 사용자 수가 1000명으로 줄어 들거나 10만명으로 갑자기 늘어날 경우 침입탐지시스템에서 이를 통보 하게 되는 것이다
그림 비정상상황탐지
행위 기반 이상탐지 방식의 장점과 단점을 살펴보자.
장점
행위기반 이상탐지(anomaly detection) 방식을 사용하기 위해서는 앞서 언급 한데로 먼저 정상 상황에 대한 정의(프로파일)가 필요 하다. 정상이라고 정의한 상황을 기준으로 변칙적인 상황이 발생될 경우 비정상 상황으로 판단 한다.
시스템에 사용자가 추가 또는 삭제 되는 경우 바로 행동 기반 방식에 의해 탐지가 가능 할 수 있다. 이는 일반적으로 사용자가 추가/삭제가 자주 발생하지 않는다는 가정하에서 사용자가 추가 또는 삭제되는 정상 행위에 대해 하나의 비정상 상황으로 가정하고 탐지할 수 있다는 의미다. 두번째로 각각 개별 환경에 따라 기준 또는 정상으로 정의한 상황이 틀리기 때문에 공격을 시도하는 입장에서는 탐지를 우회할 방법을 찾기가 매우 어렵다. 시그니처 기반의, 예를 들면 스노트룰의 경우 웹 상에 탐지 패턴이 공개되어 있기 때문에 언제든지 패턴을 획득하여 우회할 방법을 찾을 수 있지만 사용자 또는 시스템관리자가 정의한 개별 상황은 추측을 통해 우회 방법을 찾기가 매우 어렵다.
단점
대부분의 침입탐지시스템에서 행위기반 이상탐지(anomaly detection) 시스템은 몇 가지 문제를 갖게 된다. 먼저 비정상 상황에 대한 구분을 위해서는 반드시 적절한 기준이나 프로파일을 가지고 있어야 탐지가 가능하다는 점이다. 만약 기준 상황을 정의하는 기간 동안 공격이 발생되어 해당 기준 상황에 공격 행위가 포함될 경우 이 또한 정상 상황으로 판단될 수 있다. 이보다 큰 문제는 시스템의 복잡성과 임계치 설정이 매우 어렵다는 것이다. 만약 공격 행위나 상황이 정상 상황에 너무 가까워서 탐지가 되지 않을 수도 있고, 반대로 정상 사용자를 공격자로 탐지할 수도 있다.
이상탐지 기법을 기반으로 네트워크 또는 호스트의 보안 위협을 분석 한다. 침입분석대상의 사이버 보안 위협을 분석하는 방식을 살펴보자.
침입분석대상
앞서 침입탐지시스템에서 공격 행위를 변별하기 사용하는 2가지 방식을 살펴 보았다. 이번에는 이러한 탐지 방식을 적용하는 계층에 대해 살펴 보기로 하자.
공격 시도를 네트워크상에서 탐지 할 것인지 더 하위 레벨인 시스템에서 탐지 할 것인지에 대한 결정이다. 이 두가지 초점에 따라 탐지 매커니즘을 적용하는 대상에 차이가 발생 한다. 네크워크상에서 송/수신 되는 패킷의 데이터를 분석해 공격을 판단할 것인지, 시스템의 프로세스를 분석해 공격을 판단할 것인지 목적에 따라 차이가 발생 한다.
네트워크 감시(병목 감시)
일반 적으로 네트워크 환경을 구성할 때 웹 서버 및 서비스에 사용할 시스템을 IDC에 설치 하게 된다. 설치된 서버의 경우 동일 IP대역을 할당 받아 특정 범위의 서브넷 범위 안에서 네트워크 환경을 구성 한다. 병목 감시는 동일한 서브넷에 전달되는 모든 패킷에 대해 공격 여부를 탐지 하는 방식으로, 병목 처러 패킷이 집중되는 지점에서 서버로 전달되는 모든 패킷을 분석하고 공격 시도를 분별하는 방식이다.
이 때 사용되는 방법이 미러링 방식과 인라인 방식이 있는데 이는 네트워크 상에 침입탐지 시스템을 어떤 식으로 구성하는 냐를 일커는 용어이다. 스위치 장비나 기타 네트워크 장비에서 전체 트래픽을 침입탐지시스템으로 미러링하여 패킷을 검사 하거나 인라인 모드로 침입탐지시스템을 설치해 감시 하는 방식 이다. 이 구성에 대해 구체적인 형태는 뒤쪽 탐지 구성에서 다시한번 살펴 보기로 하자. 이처럼 네트워크상에서 네트워크 패킷을 감시하는 시스템을 Network Intrusion Detection System(NIDS)라 한다. 네트워크 기반의 침입탐지 시스템(NIDS)과 호스트 기반의 침입탐지 시스템(HIDS)의 가장 큰 차이가 바로 감시 대상의 차이인데, 앞서 설명한 미러링, 인라인 방식으로 네트워크 병목에서 공격 트래픽을 감시하는 것이 NIDS이다. HIDS와의 구분은 감시하는 트래픽이 단일 시스템인지 아니면 전체 네트워크 트래픽인지 차이이다. NIDS는 모든 네트워크 패킷을 검사하고, HIDS는 오로지 특정 호스트에 수신되는 트래픽만을 검사한다. 그럼 단일 호스트를 대상으로 트래픽을 감시하는 HIDS에 대해 살펴보자.
호스트 감시
앞서 NIDS와 HIDS의 차이에 대해 간단하게 언급 하였다. HIDS는 패킷 분석 외에도 침입시도를 탐지 하기 위해 다양한 방법으로 시스템을 감시 한다. 호스트 단위로 감시할 경우 다양한 시스템에서 발생되는 정보까지 활용할 수 있는 장정이 있다. 가장 많이 연동해 분석하는 정보를 다음과 같다.
감시항목
설명
Log Parsing
시스템에 저장되는 로그는 공격 시도를 확인 할 수 있는 좋은 소스 중 하나다. 많은 침입탐지시스템이 시스템 로그를 연동해 공격 행위가 탐지 되면 경고를 발생 시킨다. 일부 공격의 경우 시스템 로그에 공격 로그를 남기기 때문에 로그를 통해 공격을 감지 할 수 있다. 다음은 호스트 단위의 침입탐지시스템의 공격 탐지 로그다. sshd[3698]: fatal: Local: crc32 compensation attack: network attack detected
System Call Monitoring
호스트 기반의 침입탐지시스템은 운영체제의 커널모니터를 통해 잠재적으로 위험한 프로그램의 시스템 콜을 감시 할 수 있다. HIDS에서는 요청된 시스템 콜이 비정상으로 판단되면 경고를 발생 시키거나 호출된 시스템 콜을 막는 방식으로 침입시도를 찾아내고 차단한다.
Filesystem Watching
또 다른 기능은 중요한 파일의 사이즈를 감시하고 있다가 변환가 생기면 경고를 발생 시키는 방식이다. 중요한 시스템 파일이나 바이너리 파일의 크기가 변경될 경우 조작된 바이너리 파일로 교체된 것일 수 있기 때문에 경고를 발생 시키는 것이다. 파일 시스템 감시 방식를 이용해 웹 서버에서는 웹 경로의 파일 변조가 발생되는지 감시하여 웹 페이지가 위조 되거나 변조 되는 것을 탐지 한다.
탐지구성
네트워크 침입탐지 시스템은 네트워크 구성에 따라 미러링 방식과 인라인 방식으로 구성 한다. 먼저 미러링 구성은 원 암드(one armed) 방식이라고도 하는데 한쪽으로 팔을 뻗은 것처럼 복사된 패킷을 탐지 분석 한다. 스위치의 각 포트에 흐르는 트래픽을 특정 포트로 복사해 패킷을 미러 시켜 패킷을 검사 한다. 인라인 방식은 라우터와 스위치 사이(구성에 따라 위치는 바뀔 수 있다.)에 침입탐지시스템을 설치 한다. 인라인 방식은 침입차단장비 구성 시 많이 사용 된다. 인라인 구성 시 공격 패킷은 침입차단장비에서 차단 하거나 강제로 리셋 패킷을 전달하여 침입 시도한 공격자의 통신을 차단한다.
그림 미러링 방식과 인라인 방식 탐지
침입탐지 시스템 탐지우회 방법
공격 행위를 탐지 하기 위해 다양한 기법과 알고리즘이 사용되듯이 탐지를 피하기 위해서도 많은 기법이 끊임 없이 사용 된다. 해킹을 시도하는 공격자는 침입탐지시스템에서 탐지되는 것을 피하기 위해 다양한 방법으로 우회를 시도 한다. 많은 우회 기법이 있지만 예제로 우회기법과 관련해서 이중 디코딩을 통한 탐지 우회 방법과 패킷 프레그먼트 2가지 방법에 대해 살펴 보자
침입탐지시스템에서 탐지를 우회하기 위해 악성코드 제작자는 쉘 코드 작성 시 인코딩하여 작성 한다. 인코딩 한 코드의 경우 디코드 과정을 거쳐 패킷 분석이 필요하다. 소개할 사례는 인코딩된 소스 코드 중 악의적인 목적의 공격 코드에 자주 포함되는 NOP코드를 인코딩하여 우회 시도하는 방법에 대해 살펴보고 디코딩하는 방법을 살펴 보자.
NOP (no-operation) 코드 인코딩
90 NOP
90 NOP
Exploit 코드 제작자는 작성한 쉘 코드가 실행될 정확한 메모리 상의 위치를 추정하기 어렵다. 이는 각은 운영체제에서 사용하는 프로그램이나 설치된 패키지에 따라 정확한 주소값이 달라지기 때문이다. 오버 플로우 또는 언더플로우 등의 공격을 통해 시스템 처리 루틴의 주소 값을 조작하는 단계에 성공했다고 해도, 최종 목적지인 공격자가 작성한 프로그램 코드, 즉 쉘코드가 실행 되는 지점으로 돌아와야 한다. 그렇기 때문에 일정 부분 쉘 코드 앞에 여유 공간을 확보해 리턴 주소가 공격자가 작성한 쉘 코드를 지나치지 않도록 Exploit 코드를 제작한다.
이 때 쉘 코드 앞의 일정 부분을 NOP코드(0x90)로 채워 여유 공간을 확보 한다. 리턴값이 NOP코드를 만나면 아무것도 수행하지 않고 지나쳐 공격자가 작성한 쉘 코드에 이르게 되어 코드가 실행 된다. 많은 Exploit 코드에 NOP코드가 포함되는데 침입탐지시스템에서는 과도한 NOP코드 사용을 exploit코드로 탐지 한다. 탐지를 우회하기 위해 코드 제작자는 여러 가지 방법으로 NOP코드를 인코딩 하고, 침입탐지시스템에서는 이를 탐지 하기 위해 디코딩기법을 적용하거나 인코딩한 데이터를 탐지 패턴으로 사용하게 된다. 인코딩 기법으로 자주 사용되는 몇 가지 방식을 살펴보자.
엔티티 인코딩 방식 예제를 보자. 앞서 NOP코드는 16진수 값으로 0x9090, 10진수 37008 이다. 해당 값을 엔티티 인코딩 방식으로 다음과 같이 인코딩 할 수 있다.
“邐” or “邐”
프레그먼트(Fragment)
스노트 기반의 침입탐지 시스템의 특징이 패킷을 기반으로 특정 문자열이나 헤더값을 검사 하기 때문에 조각난 패킷(fragmented)의 경우 데이터에 포함된 공격 구문을 바로 찾기 어려울 수 있다. 이러한 이유로 스노트 엔진에서는 전처리기라는(preprocessor) 모듈을 통해 조각난 패킷을 재조합 하는 과정을 거치게 된다. 물론 성능의 한계로 무한 재조합은 현실적으로 불가능하다.
이러한 조각난 패킷은 탐지 시스템의 서비스 거부 공격에도 사용되기도 한다. 아주 작게 패킷을 조각내 공격 대상 시스템에 전송하여 패킷을 수신한 시스템에서 재조합에 많은 리소스가 사용되게 만들어 리소스를 고갈 시키는 방식이다. 그러면 대상 시스템은 패킷 조합에 리소스를 과도하게 사용하여 서비스 제공이 불가능한 상태가 된다.
서비스 거부 공격 외에 탐지 우회하기 위한 방법으로도 사용된다.
대부분 네트워크 기반 침입탐지 장비가 병목에 설치된다. 침입탐지시스템 엔진은 네트워크에서 캡쳐한 패킷의 공격성 여부를 판단하고 액션을 취한다. 하지만 침입탐지시스템이 탐지한 모든 패킷이 대상 호스트로 도달하지 않을 수도 있다. 각각의 단편화된 패킷은 각각 TTL설정에 의해서 도착지 IP까지 도착하지 못하고 네트워크에서 유실 될 수도 있다. 침입탐지 시스템을 우회하기 위해 공격 패킷을 조각 내고, 각각의 패킷의 TTL을 다르게 설정해 호스트까지 도착하는 패킷을 선택할 수 있다.
9개의 조각난 패킷을 침입탐지 시스템에서 재조합해 “cmdo.bexe”라는 구문을 탐지 했다고 가정 하자. 탐지한 “cmdo.bexe” 구문이 공격성이 없는 것으로 판단하고 패킷을 처리했으나, 호스트에서는 9개 중 2개를 뺀 7개의 패킷을 수신하였다. 수신된 패킷은 조합 결과 “cmd.exe” 구문이 포함되어 시스템 명령이 실행 되었다.
프레그먼트 패킷번호
공격구문
목적시스템 도달여부
1
C
수신
2
M
수신
3
D
수신
4
O
미수신
5
.
수신
6
B
미수신
7
E
수신
8
X
수신
9
E
수신
표 패킷 수신/미수신
공격자는 “cmd.exe”를 실행하기 위해 중간에 눈가림으로 사용할 ‘o’와 ‘b’가 포함된 패킷을 보내야 했다. 하지만 목적지 호스트에 모든 패킷이 도착했을 때는 ‘o’와 ‘b’가 포함되면 안됐다. 그래서 공격자는 TTL값을 다르게 설정해 필요 없는 패킷을 서버에 도착하기 전에 없앴다. 목적지 호스트에 도착하는 패킷의 TTL값보다 작은 값을 설정해 패킷을 중간에 사라지게 한것이다.
이를 타켓 베이스(Target-based) 공격 방식이라 얘기 한다.
시스템 전체 전송 단위(Maximum Transmission Unit)
통신 과정에 프레그먼트되지 않고 전송되는 패킷의 사이즈는 제한이 있다. 이는 패킷을 제각각 사이즈로 생성하여 생기는 통신 장애를 방지하기 위해 사전에 프레그먼트되지 않고 전송되는 퍄킷 사이즈를 정한 것이다.
물론 일부 개발과정에서 사이즈를 넘는 패킷을 만들어 사용하기도 한다. 동영상 데이터의 경우 패킷 사이즈를 초과하는 경우가 자주 발생하는데 이로 인해 일부 네트워크 장비나 통신 장비에서는 비정상 패킷으로 처리하여 통신이 끊기거나 지연되는 경우가 종종 발생 하곤 한다.
다음은 프로토콜 별 MTU 설정에 대한 자료다.
형식
시스템 전체 전송 단위 (바이트)
Internet IPv4 Path MTU
At least 576[1]
Internet IPv6 Path MTU
At least 1280[2]
Ethernet v2
1500[3]
Ethernet (802.3)
1492[3]
Ethernet Jumbo Frames
1500-9000
802.11
2272[4]
802.5
4464
FDDI
4500[3]
표 프로토콜 별 시스템 전체 전송 단위
코드를 인코딩하거나, 조각 내어 침입탐지시스템이나 기타 탐지에 대해 우회하는 시도에 대해 살펴 보았다. 물론 탐지를 우회하는 기법은 매우 다양하다. 언급한 2가지 방식은 이 중 일부이다. 침입탐지 시스템에서는 혹은 여러분은 공격자에 의한 공격이 정상 또는 어렵게 보이는 데이터로 가장하고 들어 올 수 있다는 것을 침입시도를 확인할 때 항상 유념해야 한다. 자, 이제 네트워크에서 이뤄지는 해킹 시도를 탐지하기 위해 네트워크 상의 어떤 위치에서 침입탐지 시스템이 운영되고 어떤 트래픽을 감시 하는지 살펴보자.
기업이나 정부 기관에서는 침해사고가 발생하면 사전에 정의된 업무 절차에 따라 사고대응 활동을 수행한다. 금융권 혹은 개인정보 유출과 연관된 사고의 경우에는 기업 내부뿐만 아니라 관리 기관과 함께 사고 조사를 수행하기도 한다. 침해사고 대응 활동을 통해 사고 원인을 파악하고 피해가 재발하지 않도록 재발방지 방안을 수립하는 것이 침해사고대응 활동의 목적인다. 침해사고 대응 하는 과정을 요약 하면 다음과 같다.
표 침해사고분석 과정 요약
사고의 유형은 다양하다. 랜섬웨어에 의해 시스템의 중요한 데이터가 암호화되는 피해를 입거나, 사전식 대입 공격을 통해서 시스템에 공격자가 침입할 수 있다. 사고 유형에 따라 침해사고를 어떻게 분석할지 분석가는 조사 방법을 정의 한다. 증거 수집 과정은 침해사고원인을 파악하기 위해 필요한 정보를 모으는 과정이다. 사전식 대입 공격에 의해서 사고가 의심되는 경우에는 침해사고원인 분석을 위해서 시스템의 로그인 로그가 필요하다. 만약 랜섬웨어에 의해 파일이 암호화 되었다면 시스템 명령 실행내역과 프로그램 설치 내역이 사고원인 분석을 위해 필요하다. 사고 원인을 정확히 파악하기 위해서는 공격자의 흔적이 기록된 정보를 활용한다. 증거 수집 과정에서는 다양한 보안 솔루션이 활용된다. 엔드포인트에서 수집된 로그에서 부터 클라우드 기반의 로그까지 다양한 로그를 활용한다. SOC팀에서 운영하는 보안 솔루션 장비가 분석가가 사고 조사 시 수집 대상으로 고려가 필요한 로그 정보다. 다음 그림은 SOC 보안 모니터링을 위한 솔루션 아키텍처 그림이다.
그림 – SOC 솔루션 아키텍처
수집된 로그를 가공하고 분석에 필요한 정보만 추출하는 과정을 거쳐 침해사고와 핵심이 되는 정보를 분석하게 된다. 최근에는 다양한 보안 솔루션을 이용해서 상관분석을 수행한다. 서로 다른 보안 장비간에 연관된 사고 관련 이벤트를 그래프나 히트맵으로 시각화해 분석 시간을 효율적으로 활용할 수 있게 도와 준다. 머신러닝(Machine Learning)을 활용해 방대한 로그를 분석해 사고와 관련된 이벤트를 사전에 탐지 할 수 있는 방법도 다양하게 시도된다. 보안 위협 탐지와 분석 과정에 인공지능 기술이 활용되면 업무 효율성을 높일 수 있을 것으로 기대 된다. 침해사고 원인이 확인되면 재발방지를 위해 필요한 조치를 정의 하고, 개인정보가 유출되거나 기업 고객 정보와 관련된 피해가 발생했다면 관련 규정에 따라 필요한 조치가 포함된 의사 결정이 이뤄진다. 일련의 침해사고분석 과정이 정상적으로 완료되면 침해사고 케이스를 종료한다.