MISTERY

침입 탐지 시스템 IDS(Instrusion Detection System)

컴퓨터 또는 네트워크에서 발생하는 이벤트들을 모니터링하고, 침입 발생여부를 탐지(Detection)하고, 대응(Response)하는 자동화된 시스템이다.

IDS는 원본 트래피을 손실이나 변조 없이 복사해주는 장비인 TAP로 트래픽을 검사하는 구조이다. ,IDS는 트래픽 유통에는 전혀 관여하지 않는 Out of Path 방식이다.

IDS는 방화벽과 연동하여 공격을 차단하는 소극적인 방어가 가능하다.

IDSIPS의 핵심 기능은 사전에 정의된 룰과 트래픽의 비교를 통해서 보안 위협을 찾아내는 것이다.

 

 

 

 

 

 

IDS의 실행 단계

1) 데이터 수집

2) 데이터 가공 및 축약

3) 침입분석 및 탐지 단계

4) 보고 및 대응

 

 

 

 

탐지 방법에 의한 분류

 

분류

특징

장점

단점

지식기반/오용

침입탐지

(Misuse

Detection)

M.D

-특정 공격에 관한 분석결과를 바탕으로 패턴을 설정

-비정상 => 비정상 Case로 트래픽을 보냄

-Signature Pattern

-knowledage-Base

-Expert System

 

-오탐률이 낮음

-트로이목마,백도어 공격 탐지 가능

-패턴에 없는 새로운 공격에 대해서는 탐지 불가능 (기록에 없기 때문에)

-False Negative

(미탐: 탐지율이 낮다)

행위 기반/

비정상행위

침입 탐지

(Anomaly

Detection)

A.D

-급격한 변화가 발견되면 불법침입으로 탐지하는 방법

-정량적인 분석, 통계적 분석을 사용

-Beahavior , Profile 작성

(통계 임계치->공격 간주 수치)

-인공지능 : 학습 능력이 있다.

-알려지지 않은 새로운 공격 탐지 가능

-인공지능 알고리즘

-Flase Positive

(오탐률이 높음)

 

 

 

데어터 수집원에 의한 분류

 

 

네트워크 기반 IDS(Network-Based IDS)

-NIDS는 감지기를 이용하며, 이것은 소프트웨어가 설치된 컴퓨터나 혹은 전용 어플라이언스 장비 일 수있다. 무차별 모드에서 동작하는 네트워크 인터페이스(NIC)에 설치되어 있다.

-NIDS는 네트워크 트래피을 모니터링하며 자신으로 향하는 트래픽은 관찰할 수 없다. (->호스트 기반 IDS가 필요하다.)

 

 

호스트 기반 IDS(Host-Based IDS)

-NIDS는 네트워크 트래픽을 분석하고 모니터링 하는데 반해, HIDS의 목적은 컴퓨터 자체를 제한하는 것이다.

 

 

분류

특징

Network-IDS

(N-IDS)

-해당 네트워크의 모든 트래픽을 탐지한다 (하나만 설치)

-웜 억제 확률 높음

-네트워크를 새로 설치하면 네트워크 N-IDS도 새로 교체 해야한다.

-네트워크에서 발생하는 여러 유형의 침입을 탐지

-서버 성능 저하가 없음

 

Host-IDS

(H-IDS)

-트로이 목마 탐지율 높음

-논리폭탄 억제가능 : 소스코드를 접속한 호스트를 알 수 있다.

-백도어 탐지 및 억제 가능

-다양한 로그자료를 통해 정확한 침입방지 가능

 

 

 

 

탐지시점에 따른 분류

사후 분석 시스템 : IDS에서 수집된 데이터를 분석하여 침입 여부를 판정하는 시스템 침입이 발생하더라도 즉시 대응하지 못하는 한계가 있다.

실시간 탐지 시스템 : 실시간 정보수집과 동시에 감사 데이터 발생과 침입 탐지가 이루어진다.

 

 

IDS의 장/단점

 

장점

단점

-내부 사용자의 오/남용 탐지 및 방어 가능

-해킹사고 발생 시 어느 정도의 근원지 추적 가능

-대규모 네트워크에 사용 곤란

-관리 및 운영이 어렵다

-새로운 침입기법에 대한 즉각적인 대응이 곤란하다.

-보안사고에 대한 근본적인 해결책은 못된다.

 

 

 

침입 방지 시스템 (IPS)

IPS(Intrusion Prevention System) 다양한 방법의 보안기술을 이용하여 침입이 일어나기 전에 실시간으로 침입을 막고, 유해 트래픽을 차단하기 위한 능동형 보안 솔루션

IPS는 예방적이고 사전에 조치를 취하는 기술이며, 반면에 IDS는 탐지적이고 사후에 조치를 취하는 기술

IPS는 기존의 트래픽 유통에 직접 관여해야만 한다. 트래픽은 IPS를 거쳐야만 유통이 가능하며 이러한 방식을 ‘InLine’ 방식이라고 한다.

 

 

IPS의 종류

 

공격 패턴 인지 방식에 의한 분류

 

분류

상세내용

Signature

Based IPS

[지식 기반]

M.D

-각각의 공격에 대하여 정확한 Signature을 정의하고 해당 공격 패턴에 매칭이 되어야만 차단을 시행

-알려지지 않은 공격의 경우 정확한 Signature List가 업데이트되어 있지 않으면 차단이 불가능한 단점이 있으나 오탐 가능성은 적다.

 

Heuristics

Based IPS

[행위 기반]

A.D

-Anomaly Detection/Prevention 방식이라고도 한다.

-알려지지 않은 공격을 수집하여 정보를 이용하여 오탐을 줄이고 능동적으로 대처하는 방식

 

 

 

 

 

적용 범위

방화벽의 룰은 TCP/IP 2개 계층에 적용되는 데 반해, IDS/IPS 룰은 3개 계층에 적용된다. IDS/IPS IP 주소와 Port 번호는 물론 TCP/IP 응용계층의 데이터까지 검사가 가능하다. 이러한 방식을 패턴 매치 기법이라고 한다.

 

 

TCP/IP 4계층

동작 주체

패킷 구조

적용 범위

응용 계층

Web,Mail,Telnet

Data

적용

전송 제어 계층

TCP,UDP

TCP/UDP 헤더

적용

인터넷 계층

IP,ICMP,IGMP

IP 헤더

적용

네트워크 엑세스 계층

ARP,NIC

이더넷 헤더

비적용

 

 

 

Snort의 룰 구조

IDS/IPS는 사실상 기술 표준인 Snort의 룰 구조이다Snort룰은 크게 헤더옵션으로 나눌 수 있는데 , IDS/IPS는 문자열패턴을 검사할 수 있는 룰 옵션'구조를 이용하여 패킷의 데이터 영역까지 검사함으로써 방화벽과 차별화가 이루어진다.

 

-룰 헤더 : /수신 방향이 주어진 롤 헤더

-룰 옵션 : 공격방식을 검사하는 값, IDS/IPS는 문자열 패턴 검사로 룰옵션 구조를 이용해서 패킷 데이터를 검사한다.

 

 

 

IDSIPS의 비교

 

구분

IDS

IPS

목적

-침입 여부의 감지

-침입 이전의 방지

특징

-로그,Signature 기반의 패턴 매칭

-정책,규칙DB 기반의 비정상행위 탐지

장점

-실시간 탐지

-사후분석 대응기술

-실시간 즉각 대응

-세션 기반 탐지 가능

단점

-변형된 패턴에 대해 탐지의 어려움

-오탐 현생 발생 가능

-고가의 장비

 

 

 

 

범용적인 보안 솔루션

IDS/IPS는 네트워크 전체를 감시하는 가장 범용적인 솔루션이다. 그러므로 IDS/IPS는 동일 기반 기술을 사용하는 보안 솔루션의 운영기준인 Control Tower가 될 수 있다.

IDS/IPS는 패턴 매치 기법을 이용하는 룰 기반 보안 솔루션의 특성 때문에 보안관제 업무의 핵심으로 자리 잡고 있으며, 탐지와 방어라는 측면에서 상호본완의 업무 프로세스를 가져야 한다.

 










출처 : http://stop2y.blog.me/100210462612

>> 제법 괜찮은 내용들이 많다.











신고

Comment +0

 

 

금일 컴퓨터통신 연구실의 컴퓨터에 IDS를 설치하였다. 프로그램을 설치할 운영체제는 CentOS 5.7 이다. 그리고 설치할 프로그램은 Snort 2.9.1 버전이다. 운영체제를 설치할 때는 불필요한 패키지는 모두 제거하고 최소 모드로 설치를 하였다.

먼저 Snort를 설치하기에 앞서 VMware Tool 을 설치한다. 다음은 몇 가지 필요한 프로그램을 설치하여야 한다. 지금부터 소스코드를 컴파일 할 것이기 때문에 컴파일러가 필요하다.

yum -y install cc, gcc, gcc-c++

다음은 wget을 이용하여 아래 파일을 다운로드 받는다.

1. libnet
http://www.seronline.de/download/libnet-1.0.2a.tar.gz

2. libdnet
http://libdnet.googlecode.com/files/libdnet-1.12.tgz

3. libpcap
http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
libpcap 라이브러리는 의존성이 있다. 그래서 libpcap을 설치하기에 앞서 flex, byacc를 설치하여야 한다. 설치 방법은 다음과 같다.

yum -y install flex, byacc

4. snort
http://www.snort.org/dl/snort-current/snort-2.9.1.tar.gz
snort는 pcre와 zlib을 요구한다.

yum -y install pcre, zlib

5. nbtscan
http://www.unixwiz.net/tools/nbtscan-source-1.0.35.tgz

6. daq
http://www.snort.org/dl/snort-current/daq-0.6.1.tar.gz

yum -y install bison

7. jpgraph
http://hem.bredband.net/jpgraph/jpgraph-1.27.1.tar.gz

8. snortreport
http://www.symmetrixtech.com/ids/snortreport-1.3.1.tar.gz

9. barnyard2
http://www.securixlive.com/download/barnyard2/barnyard2-1.9.tar.gz

 

 

 

 

 

 

출처 : http://kimlab.kr/472

 

 

 

 

 

 

신고

Comment +0

기본적인 Snort 설정 구성표

• mkdir /etc/snort

• mkdir /var/log/snort

• cd /etc/snort

• tar zxvf /home/bubba/snortrules-snapshot-2910.tar.gz -C /etc/snort

• cp etc/* /etc/snort

• groupadd snort

• useradd -g snort snort

• chown snort:snort /var/log/snort

• touch /var/log/snort/alert

• chown snort:snort /var/log/snort/alert

• chmod 600 /var/log/snort/alert

• mkdir /usr/local/lib/snort_dynamicrules

• cp /etc/snort/so_rules/precompiled/Centos-5-4/i386/2.9.1.0/*.so /usr/local/

lib/snort_dynamicrules

• cat /etc/snort/so_rules/*.rules >> /etc/snort/rules/so-rules.rules

   

Local Rules에 기본적인 룰 추가

  1. 먼저 rules 디렉토리로 이동하여 local.rules 파일을 열도록 하자. 초기 모드에서는 아무것도 설정되어 있지 않다. 본인은 CentOS가 Snort가 되고 여기서 룰을 설정하기 위해서 이곳에 기본적인 ICMP 룰을 하나 만들어 보도록 하겠다.
  • alert icmp any any -> any any (msg:"ICMP Ping"; sid:1000001;) -> 이 것은 동작모드는 alert 즉, 경고창을 띄워주고 프로토콜인 ICMP 포트와 IP번호는 모두다 잡는 다는 이야기이다. 그리고 뒤에 msg를 이용하여 어떤 내용의 경고창을 띄울 것인지 정하고 sid를 이용해서 Snort에서 해당 룰을 찾을 수 있도록 해준다. 이 sid를 이용하여 sid-map에 추가해보도록 하자.
  1. /ect/snort/sid-msg.map을 보도록 하자. 이곳에서는 sid의 넘버와 각 sid에서 표현해줄 메시지 내용이 정해져 있다. 우리는 맨 밑으로 이동을 하여 이전의 과정에서 만들어준 룰을 추가해주도록 하자.
  • 1000001 || ICMP Ping -> 즉 sid넘버는 1000001 이고 뒤의 문자열은 alert파일에 저장 될때의 문자열을 의미한다.

   

위의 예는 Snort에서 CentOS를 대상으로 한 공식 문서에서 발취한 것이다. 기본적인 Snort 설정 파일들이 저장될 디렉토리와 Alert 설정이 저장될 디렉토리, 로그가 저장될 디렉토리를 지정하는 부분이다.

  

===========================================================================================

시나리오 No.1 : Rule을 이용한 HTTP 패킷 덤프 추출

   

Snort 망 구성도

   

   

Routing 형식 : Rip Version 2

  • Router는 10.10.10.0 대역대를 이용하여 통신을 한다.
  • IDS_CentOS와 WIN_XP는 192.168.10.0의 대역대를 사용하며 그 G/W는 192.168.10.1이 된다.
  • BackTrack은 192.168.20.0의 대역대를 사용하며 그 G/W는 192.168.20.1이 된다.   

1. 먼저 Snort에서 설정된 룰을 적용하여 패킷을 검출하려면 -c 옵션이 필요하다

  • 형식 : #snort -c /etc/snort/rules/local.rules

위의 형식을 이용하여 rules이 적용된 패킷만을 검출할 수 있다. 본인은 local.rules에 tcp에 대한 80번포트를 추가하여 HTTP 접속에 대한 패킷만을 뽑아내려 해보았다.

  • 형식 : alert tcp 192.168.10.0/24 any -> !192.168.10.0/24 80 (msg:"HTTP Packet"; sid:1000002;) 즉, 왼쪽의 형식은 프로토콜은 TCP를 이용 192.168.10.0 대역대에서 포트 상관없이 외부로 나가는 패킷에서 192.168.10.0의 대역대가 아닌 네트워크에 80번 포트로 접속하는 패킷을 검출한다는 룰이다.

       

   

2. BackTrack에서 웹 서버를 운용하며 WIN_XP에서 접속을 하여 패킷을 유발시키도록 해보자.

   

   

위의 디렉토리는 snort에서 로그가 저장되는 디렉토리인 /var/log/snort이다. 해당 패킷을 유발시키자 alert와 snort.log.[번호]를 가진 파일이 생성이 된다. 파일 포맷 형식은 alert는 ASCII 형식 snort.log.[번호]는 tcp data즉, pcap파일의 형식을 가지게 된다.

   

3. Wireshark를 통해서 패킷 덤프파일 확인해보자.

 

Wireshark를 통해서 패킷의 덤프파일을 확인해보자. 아마도 WIN_XP에서 BackTrack의 웹 서버에서 접속하였던 패킷을 볼 수 있을 것이다.

   

   

위의 그림에서도 확인할 수 있듯이 192.168.10.20 에서 외부의 어떤 대역대의 80번 포트로 접속하는 패킷을 볼 수 있다. 이처럼 룰을 얼마나 자세하고 정밀하게 짜냐에 따라 필터링의 정확도가 결정되게 된다.

 

===========================================================================================   

시나리오 No.2 Rule의 옵션을 통한 패킷 덤프 추출


서브 시나리오 No.1

Content옵션만을 이용한 패킷 덤프 추출

시나리오 망 구성도 위와 동일

  1. Netcat을 이용하여 데이터를 주고 받을 시 패킷 덤프 분석

   

위의 패킷 덤프 파일처럼 Netcat을 이용한 데이터 통신에서는 HTTP Portf를 이용하여 데이터를 주고받는 것을 볼 수 있다. Test라는 문자열에는 ASCII 값으로 변환한 54 65 73 74 가 전달 되는 것을 볼 수 있다.

  1. Rule의 Content옵션을 추가하여 Test라는 데이터의 패킷덤프 추출 옵션
  • Snort Rule 형식 : alert tcp 192.168.20.20 8080 -> 192.168.10.20 any (msg:"NC Contest Test"; content:"Test"; sid:1000004;)

    즉, tcp 프로토콜을 이용한 192.168.20.20의 8080 포트에서 192.168.10.20의 어떤 포트로 오는 패킷중 문자열 Test를 가진 패킷을 검출한다.

  • Snort 탐지 형식 : snort -c /etc/snort/rules/local.rules -A console

    A 옵션을 쓰게 되면 alert 파일로 저장하지 않고 바로 Snort 관리자에게 출력을 해주게 된다.

       

   

위처럼 Test 데이터를 전달 할 시 패킷을 정상적으로 검출 하는 것을 볼 수 있다. tcp packet형식으로 저장된 덤프 파일을 Wireshark로 열어 분석해보도록 하자.

   

2. Wireshark를 통한 Content:"Test" 패킷 덤프 분석

   

   

위의 덤프파일을 살펴보면 이전의 Test를 보낼 때와 동일한 형식의 패킷 파일을 덤프한 것을 볼 수 있다. BackTrack에서 보낸 Test라는 문자열 데이터가 정상적으로 전달 된 것을 볼 수 있으며 포트는 8080인 것을 확인할 수 있다.

   

시나리오의 문제점 : 이때, Test의 문자열만 패킷 덤프가 가능하였다. 대문자가 섞이거나 숫자패턴이 섞이면 패킷 덤프가 추출 되지 않았다. 즉 TEST, 1234Test 등의 문자열은 추출이 되지 않은 것이다. 이 문제점을 해결하기 위해 nocase 옵션을 사용하기로 하였다

   

서브시나리오 No.2

Content옵션과 nocase옵션을 통한 패킷 덤프 추출

  1. 이전의 Snort 룰 옵션에 nocase를 추가
  • Snort Rule 형식 : alert tcp 192.168.20.20 8080 -> 192.168.10.20 any (msg:"NC Contest Test"; content:"Test"; nocase; sid=1000004;)

    즉 이전의 형식과 동일하며 여기에 대소문자를 구분하지 않고 Test라는 문자가 있기만 하면 검출 하겠다는 옵션을 추가하도록 한다.

   

 

2. BackTrack에서 문자열을 바꿔가며 전송

 

   

위처럼 Test, test, TEST , 123456Test의 데이터를 보냈다. 정상적으로 Snort에서 검출 하는지 보도록 하자.

   

3. Snort 패킷 검출 여부 확인

   

Snort에서 정상적으로 4개의 데이터에 대한 패킷을 검출하는 것을 볼 수 있다. Wireshark로 정상적인 패킷을 검출한 것인지 확인해보도록 하자.

   

4. Wireshark를 통한 패킷 덤프 분석

위 처럼 정상적으로 BackTrack에서 보냈던 모든 데이터를 잡는 것을 확인 할 수 있다.

   

서브시나리오 No.3

Content와 offset과 nocase를 이용한 데이터 검출

  1. 이전의 Rule 옵션에 offset옵션 추가
  • Snort Rule 형식 : alert tcp 192.168.20.20 8080 -> 192.168.10.20 any (msg:"NC Content Test"; content:"Test"; offset:0; nocase; sid:1000004;)

    offset 옵션을 주는 이유는 좀더 명확한 데이터 검출을 위해서다. 해당 데이터가 담겨오는 Offset을 살펴보면 실제 36 Offset이 되는데 Snort는 특징 상 Application의 데이터부터 Offset을 부여하기 때문에 바로 0이 데이터가 시작되는 Offset이 된다.

   

 

2. 이전과 동일하게 BackTrack에서 데이터전송

 

   

이전과 동일하게 데이터를 3개 전달을 하였다.

3. 이전과 동일하게 Snort에서 데이터 검출 확인

위처럼 3개의 데이터가 정상적으로 검출 된 것을 확인 할 수 있다. Wireshark로 분석을 해보도록 하자.

   

4. Wireshark로 패킷 분석

 

   

위처럼 정상적으로 패킷을 검출하는 것을 확인 할 수 있다.

   

===========================================================================================

시나리오 명

Telnet 서버로의 접근시도에서의 패킷 검출

   

시나리오 망 구성도

   

   

서브 시나리오 No.1

내부에서의 Telnet 서버로의 접근 시도에서의 패킷 검출

   

시나리오 역할

  • WIN_XP : Telnet Server
  • WIN_XP_Att : Telnet Server Attacker

   

시나리오 개요

Telnet 으로 구성된 서버에 악의적 목적을 가진 사용자가 접근을 할 때 접근 성공과 접근 실패 하였을 때의 패킷을 검출하도록 해보자.

   

가. 성공의 경우

 

위와 같은 공통된 문자열을 볼 수 있었다. 이외에도 Microsoft라는 문자열을 잡을 수 있었지만 이 문자열은 처음 Telnet접속시에도 동일하게 뜨는 문자열 이기 때문에 제외하기로 하였다. 그래서 공통된 데이터 값을 찾다가 위와 같은 값을 찾을 수 있었다. 위와 같은 값은 OS에 차이 없이 공통으로 나오는 데이터 형식으로 실패했을때는 출력되지 않고 성공하였을 때만 출력되는 데이터 값이 였다.

   

  • Snort Rule 형식 : alert tcp 192.168.10.20 23 -> !192.168.10.10 any (msg:"Telnet YES Access"; content:"|fffa1801fff0|"l nocase; sid:1000006;)

    를 주게 되었다. 이 형식은 프로토콜은 tcp를 사용하며 Telnet Server인 192.168.10.20에서 23번 포트를 이용하여 주는 메시지 중에서 위와 같은 Hex값을 데이터로 보내는 것을 검출 하는 것이다

       

  • 결과 확인

   

  • Wireshark로 패킷 확인

       

   

위의 형식에서 데이터 부분을 보게 되면 ff fa 18 01 ff f0를 잡은 것을 볼 수 있다.

   

나. 실패의 경우

   

위와 같은 Login Failed 라는 문자열 데이터를 발견 할 수 있었다. 이 부분 같은 경우 OS의 상관없이 동일한 형식으로 전달되기 때문에 형식에서 Login Failed라고 룰을 설정 한 후 검출을 시도해보았다.

   

  • Snort Rule 형식 : alert tcp 192.168.10.20 23 -> !192.168.10.10 any (msg:"Telnet NO Access"; content:"Login Failed"; nocase; sid:1000005;) 라고 주었다. 즉 Content 옵션을 사용하여 Login Failed라는 데이터가 전달되면 검출 하도록 해보았다.

       

  • 결과 확인

       

위처럼 접근에 실패했을 경우 Telnet NO Access라는 alert 문을 출력해주며 해당 패킷을 검출 하는 것을 볼 수 있다.

   

  • Wireshark 패킷 덤프 분석

    위처럼 Login Failed라는 데이터 값과 함께 실패한 경우의 패킷을 검출 함을 볼 수 있었다.

       

       

서브 시나리오 No.2

외부에서의 Telnet 서버로의 접근 시도에서의 패킷 검출

   

시나리오 역할

  • 서버 : WIN_XP
  • 공격자 : BackTrack5 R3

   

시나리오 개요

Telnet 으로 구성된 서버에 악의적 목적을 가진 사용자가 접근을 할 때 접근 성공과 접근 실패 하였을 때의 패킷을 검출하도록 해보자.

 

가.성공의 경우

   

이전의 내부에서와 같이 성공하였을 때 이후에 나오는 Raw 데이터를 볼 수 있다. 이전과 동일하게 이 Raw 데이터를 가지고 성공하였을때의 패킷을 검출하도록 해보자

   

  • Snort Rule 형식 : alert tcp 192.168.10.20 23 -> !192.168.10.0/24 any (msg:"Telnet External YES Access"; content:"|fffa1801fff0|"; nocase; sid:1000008;)

    즉 이 형식은 tcp 프로토콜을 사용하며 192.168.10.20 에서 23번 포트를 이용하여 자신의 내부 네트워크가 아닌 외부 네트워크로 패킷을 보낼때 그 패킷의 값중 위의 Raw 데이터가 포함되면 검출하겠다는 뜻이다.

       

  • 결과 확인

    위처럼 정상적으로 alert를 출력하는 것을 볼 수 있다. 이어서 Wireshark로 Raw Data를 확인해보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

       

    위 처럼 본인이 입력했던 Raw DATA를 정상적으로 잡으며 Telnet 메시시를 검출하는 것을 볼 수 있다.

   

나. 실패의 경우

   

   

   

이전과 동일하게 TCP Stream에서 위처럼 Login Failed라는 문자열 데이터 값을 볼 수 있다. 이 값을 이용하면 패킷을 검출하도록 해보자.

  • Snort Rule 형식 : alert tcp 192.168.10.20 23 -> !192.168.10.0/24 any (msg:"Telnet Externel NO Access"; content:"Login Failed"; nocase; sid:1000007;)

    즉 위의 형식은 내부와 동일하지만 내부에서의 패킷이 아닌 외부로 나가는 패킷만 잡도록 하는 것이다.

  • 결과 확인

       

    위처럼 정상적으로 외부로 나갈때의 패킷을 검출 하는 것을 볼 수 있다. Wireshark를 이용하여 패킷을 분석해보도록 하자.

  • Wireshark로 패킷 덤프 분석

       

       

    위처럼 Wireshark에서 정상적으로 Login Failed라는 값을 검출 하는 것을 볼 수 있다.

       

서브 시나리오 No.3

내부에서의 Router Telnet 서버로의 접근 시도에서의 패킷 검출

   

시나리오 역할

  • 서버 : Router R1
  • 공격자 : WIN_XP_Att

   

시나리오 개요

Telnet 으로 구성된 Router에 악의적 목적을 가진 사용자가 접근을 할 때 접근 성공과 접근 실패 하였을 때의 패킷을 검출하도록 해보자.

 

가.성공의 경우

   

   

이처럼 성공의 경우 해당 Router의 호스트 네임을 출력 시키는 것을 볼 수 있다. 이때, Snort는 관리자가 설정하는 것이므로 어차피 호스트 네임을 알기 때문에 호스트 네임을 Rule형식으로 주었다.

   

  • Snort Rule 형식 : alert tcp 192.168.10.1 23 -> 192.168.10.0/24 any (msg:"Router Success"; content:"|0d0a52313e|"; nocase; sid:1000009;)

    즉 tcp 프로토콜을 사용하며 192.168.10.1 에서 23번 포트를 이용하여 자신의 내부 네트워크에 패킷을 보낼때 이 값에 0d0a523133=>..R1>의 데이터를 보내면 검출하겠다는 뜻이 된다. 즉 Router의 호스트네임으로 검출하는 것이다.

       

  • 결과 확인

       

       

    위처럼 해당 데이터를 포함한 alert가 정상적으로 출력되는 것을 볼 수 있다. 자세한 내용을 보기 위해서 로그파일을 이용해서 Wireshark로 분석해보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

       

       

    위의 네모로 표시된 부분에서 정상적으로 R1>을 포한한 패킷을 검출하여 내부의 어떤 사용자가 Router에 Telnet으로 접속에 성공했음을 알 수 있다.

       

나. 실패의 경우

   

   

실패의 경우 위처럼 Bad passwords를 띄워 줌을 볼 수 있다. 이때의 가정은 공격자가 브루트 포스 공격으로 여러번의 비밀번호를 입력한다는 경우이다. 실제 공격자가 1~2번 사이의 비밀번호를 알아내는 경우는 거의 없기 때문이다.

   

  • Snort Rule 형식 : alert tcp 192.168.10.1 23 -> 192.168.10.0/24 any (msg:"Router NO Sucess"; content:"Bad Password"; nocase; sid:1000010;)

    즉, 성공의 경우와 동일하지만 이번에는 패킷에 Bad Password라는 문자열이 포함되는 것으로 검출하겠다는 것이다. 즉, Router접속에 실패하였을 경우가 된다.

       

  • 결과 확인

       

       

    위처럼 정상적으로 해당 데이터가 포함된 패킷을 검출 함을 볼 수 있다. 좀더 자세한 정보를 보기 위해 Wireshark로 패킷을 분석해보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

       

       

    위 부분을 살펴보면 정상적으로 Bad Password가 포함된 패킷을 검출 함을 볼 수 있다. 즉 Bad passwords라는 문자열을 이용하여 Router의 Telnet서버 접속에 실패하였을 경우의 패킷을 검출하도록 한것이다.

 

 

 

 

 

출처 : http://god2zuzu.blog.me/70168951403
         (해당 링크로 이동 후 그림을 꼭 참조 할 것.. 정말 유용한 정보이다)

 

 

 

 

 

 

신고

Comment +1

시나리오

Snort를 이용한 SSH 접근 검출

시나리오 개요

Snort를 이용해서 관리자 외에 SSH Server에 접근하려는 패킷을 검출해보도록 하자.

시나리오 사용 툴

  • FreeSSHd
  • Putty
  • Snort

   

시나리오 망 구성도

IP 구성도

  • IDS_CentOS : 192.168.10.30
  • WIN_XP_SSH : 192.168.10.20
  • BackTrack : 192.168.20.20
  • Administrator : 172.168.10.10
  • SW1 : 172.168.10.1
  • SW2 : 192.168.20.1
  • SW3 : 192.168.10.1
  • Serial : 10.10.10.0 대역대 사용

   

시나리오 순서 설명

  1. WIN_XP_SSH를 SSH를 이용하여 관리하려는 관리자가 존재한다. 이 관리자는 IDS를 설치 한 후 자신외에 접근하려는 자가 있는지 지속적인 검출을 해보려 한다. 먼저 WIN_XP를 SSH Server로 구성을 해보자. 본인은 FreeSSHD를 사용하여 WIN_XP를 SSH Sever로 구성을 하였다.

       

  2. 관리자는 SSH 패킷을 유발 시킨 후 어떤 방식으로 Rule를 설정할지를 결정해야 한다. 정상적인 관리자에서의 접속으로 SSH 패킷을 유발 시킨 후 어떤 식으로 Rule을 구성해야 할지 결정해보자.

   

일반적으로 SSH는 암호화된 프로토콜 방식을 제공한다. 이때 평문으로 전송되는 패킷은 오로지 SSH Version을 결정하는 패킷이다. 위 처럼 TCP Stream으로 SSH 접속 시도를 보면 SSH-2.0의 버전으로 하자는 Server와 Client간의 패킷을 볼 수 있다. 그러면 우리는 이 부분에서 SSH Version에 상관없이 SSH 접근만을 검출하기 위해서 SSH라는 문자열을 이용하여 Rule을 정하면 될 것이다.

  1. Snort를 이용하여 Rule을 작성
  • 본인은 alert tcp 192.168.10.20(SSH_Sever) -> !172.168.10.10(관리자) any (msg:"SSH Detect"; content:"|535348|"; sid:10000011;)로 작성하였다. 즉 SSH Server가 관리자가 아닌 누군가에게 보내려는 패킷중에 SSH라는 문자열을 가진 패킷이 발생하면 검출하겠다는 것이다. 여기서 Version을 결정할때의 SSH는 항상 대문자로 전달되기 때문에 nocase 옵션을 제외 시켰다.

       

  1. 결과 확인

       

    위처럼 정상적으로 다른 누군가 (BackTrack)가 접속하는 것을 볼 수 있다. 본인이 설정한 msg인 SSH Detect가 뜨는 것을 볼 수 있는 것이다. Wireshark로 패킷을 분석해보도록 하자.

   

  1. Wireshark로 패킷 덤프 분석

       

       

    정상적으로 Server에서 Client에게 보내는 패킷 중 SSH Version을 결정하는 패킷을 검출 한 것을 볼 수 있다.

       

====================================================================================================

   

시나리오

Snort를 이용한 SSH & Telnet & FTP Brute Force 공격 탐지

   

시나리오 개요

Snort의 Rule을 이용하여 SSH & Telnet & FTP로의 Brute Force 공격을 탐지해보도록 하자.

   

시나리오 사용 툴

  • Snort
  • FreeSSHD, Telnet서버 , Filezila 서버
  • Hydra 7.2

   

시나리오 망 구성도

   

IP 구성도

  • IDS_CentOS : 192.168.10.30
  • WIN_XP_SSH : 192.168.10.20
  • BackTrack : 192.168.20.20
  • Administrator : 172.168.10.10
  • SW1 : 172.168.10.1
  • SW2 : 192.168.20.1
  • SW3 : 192.168.10.1
  • Serial : 10.10.10.0 대역대 사용

   

서브 시나리오 No.1

Snort를 이용한 SSH Brute Force 탐지

   

시나리오 순서 설명

  1. SSH 관리자는 WIN_XP에서 FreeSSHD를 이용하여 SSH Server를 설치하여서 운용하고 있다. 이때 공격자인 BackTrack은 BruteForce 공격을 수행하는데 관리자는 이처럼 BruteForce 공격을 탐지하기 위해 Snort에 Rule을 추가 한다.

       

  2. Snort Rule 형식

    관리자는 Snort Rule에 alert tcp 192.168.10.20 22 -> !172.168.10.10 any (msg:"SSH Brute Detect"; content:"|535348|"; threshold:type both, track by_src, count 10, seconds 20; sid:10000012;) 와 같이 추가를 하였다. 즉 SSH 서버에서 22번 포트를 이용하여 관리자 PC가 아닌 PC에 SSH라는 문자열이 20초당 10번 발생하면 경고를 띄운다는 뜻이 된다. 즉 단 시간내에 여러번의 결과를 대입하는 Brute Force 공격을 탐지하기 위함이다. 여기서 threshold의 type은 여러가지 있지만 both는 둘다 라는 뜻이고 track by_src는 소스에서 즉 보내는 쪽에서의, 패킷이라는 뜻이 된다. 그리고 count는 10번 seconds는 20초가 된다. 즉 20초 동안 10번의 카운트를 하겠다는 것이다.

   

  1. 결과 확인

       

       

    위처럼 alert가 출력 되는 것을 볼 수 있다. 2개 밖에 안뜨는 이유는 20초당 10번째 발생하는 패킷만을 잡기 때문이다. Wireshark로 분석해보도록 하자.

       

  2. Wireshark로 패킷 덤프 분석

       

       

       

    이처럼 SSH에 접속할 때 뜨는 SSH Version을 정하는 패킷을 볼 수 있다. 이 패킷들은 20초동안 10번째 발생한 패킷이기 때문에 각각 0초와 19초에 발생한 것을 볼 수 있다. 사실 정상적인 사용자가 비밀번호를 모른다 하더라도 20초내에 아이디와 비밀번호를 10번 입력하는 것은 불가능한 일이기 때문에 Brute Force 공격이라는 것을 알 수 있다.

   

서브 시나리오 No.2

Snort를 이용한 Telnet Brute Force 탐지

   

시나리오 순서 설명

  1. Telnet 관리자는 WIN_XP에 Telnet 서버를 설치 한 후 운용하러 한다. 이때 관리자는 동일한 망에 Snort를 설치 후 Telnet Brute Force 공격을 탐지하려 한다. Snort에 알맞은 Rule을 설정해보도록 하자.

       

  2. Snort Rule 형식

    관리자는 alert tcp 192.168.10.20 23 -> !172.168.10.10 any (msg:"Telnet Brute Detect"; content:"Microsoft"; nocase; threshold:type both, track by_src, count 10, seconds 20; sid:10000013;)로 설정하였다. 즉 서버에서 23번 포트로 관리자가 아닌 PC로 데이터를 보낼때 이때 Telnet 접속 시에 나타나는 문자열인 Microsoft가 20초에 10번동안 발생하게 되면 경고를 나타내도록 하였다.

       

  3. 결과 확인

       

       

    위처럼 20초당 Microsoft가 10번 발생하게 되면 경고를 울리게 하였다. 현재 공격자는 Hydra를 이용하여 지속적인 BruteForce공격을 수행하는 중이다. 그러면 정확한 분석을 위해 Wireshark로 분석해보도록 하자.

       

  4. Wireshark로 패킷 덤프 분석

       

       

    위처럼 처음 Telnet에 접속할때 뜨는 문자열을 볼 수 있다. Telnet은 3번이상 로그인에 실패하면 접근을 해제시키는데 Brute Force 공격은 이처럼 접근을 해제하고 다시 접근하는 과정을 반복하기 때문에 Brute Force 공격인지 알 수 있는 것이다.

   

서브 시나리오 No.3

Snort를 이용한 FTP Brute Force 탐지

   

시나리오 순서 설명

  1. FTP 관리자는 WIN_XP에 FTP Server를 설치 운용하러 한다. 이때 관리자는 FTP Brute Force 공격을 탐지하기 위해 Snort을 운용하는데 이에 알맞은 Rule을 추가해보도록 하자.

       

  2. Snort Rule 형식

    alert tcp 192.168.10.20 21 -> !172.168.10.10 any (msg:"FTP Brute Detect"; content:"530 Login or password incorrect"; threshold:type both, track by_src, count 10, seconds 20; sid:10000014;) 이처럼 설정하였다. 즉 Telnet Server에서 관리자 PC가 아닌 다른 PC에게 21번 포트로 FTP에서 로그인에 실패하였을 때 출력하는 530 Login or password incorrect 문자열을 20초동안 10번 보내면 결과를 출력하도록 했다.

       

  3. 결과 확인

       

       

    위처럼 결과를 확인할 수 있다. 즉 현 상태에서 공격자는 Hydra를 이용하여 지속적인 FTP Brute Force공격을 수행하는데 이때 로그인 실패 하였을때 뜨는 문자열을 검출하도록 Rule을 설정하여 20초동안 10번째 입력되는 패킷을 검출하도록 한 것이다. 정확한 분석을 위해 Wireshark로 패킷을 분석해보도록 하자.

       

  4. Wireshark로 패킷 덤프 분석

       

       

    이처럼 로그인에 실패하였을때 보내는 패킷이 20초동안 10개 넘게 발생하여 검출이 되는 것을 볼 수 있다. 위에 설명하였듯이 정상적인 사용자라면 20초 동안 10번의 아이디와 비밀번호 입력은 불가능하지만 Brute Force 공격은 빠른 대입을 수행하기 때문에 검출이 가능 한 것이다.

===================================================================================

   

시나리오 No.2

Snort를 이용한 Admin 페이지 접근 탐지

   

시나리오 개념

Snort를 이용하여 admin 페이지에 접근하려는 시도를 탐지해보자.

   

시나리오 사용 툴

  • BackTrack에서의 Apache
  • Snort

   

시나리오 망 구성도

  • IDS_CentOS : 192.168.10.30
  • BackTrack_Webserver : 192.168.10.20
  • WIN_XP_Att : 192.168.20.20

       

즉, 이번에는 BackTrack이 피해자의 WebServer가 되어서 WIN_XP의 공격자가 관리페이지로 접근하려는 것을 탐지 해보려한다.

   

시나리오 순서 설명

  1. WebServer 관리자는 자신 외에 관리페이지로 접근하려는 시도를 탐지하려 한다. 이에 알맞은 Snort Rule을 설정하도록 하자.

       

  2. Snort Rule 형식

    alert tcp !192.168.10.20 any -> 192.168.10.20 80 (msg:"HTTP Admin Attack"; content:"admin.html"; nocase; sid:10000015;) 관리자는 이처럼 설정을 하였다. 즉 관리자가 아닌 어떤 PC가 어느 포트로든 Web Server의 80번 포트로 요청하는 패킷중에 관리 페이지의 네임인 admin.html이 포함되어 있으면 검출 하겠다 라는 뜻이 된다. 공격자에 입장이 되어서 Web Server의 admin.html페이지로 접근을 시도해보자.

       

  3. 결과 확인

       

       

    위처럼 관리자가 아닌 PC에서 접근하려는 시도를 탐지 하는 것을 볼 수 있다. Wireshark로 패킷을 분석해보도록 하자.

       

  4. Wireshark로 패킷 덤프 분석

       

       

    위의 패킷을 보면 관리자(192.168.10.20)이 아닌 다른 PC(192.168.20.20)이 관리자만이 접근해야 할 admin.html페이지를 요청하는 것을 볼 수 있다. 이와 같은 패킷을 탐지함으로써 관리페이지로의 접근을 탐지할 수 있는 것이다.

 

 

 

 

 

 

 

 

 

 

출처 : http://god2zuzu.blog.me/70168951403
         (해당 사이트로 이동 후 그림을 꼭 참조 할 것)

 

 

 

 

 

 

신고

Comment +0

시나리오

Snort를 이용한 Nmap Port Scanning 탐지

   

시나리오 사용 툴

  • Snort
  • Nmap
  • Hping2

   

시나리오 망 구성도

   

시나리오 개념

BackTrack(공격자)에서 WIN_XP를 Port Scanning을 통해 활성화 되 있는 포트를 찾아 취약점을 공략하려 한다. 이때 관리자는 Snort의 탐지 룰을 추가하여 자신 이외에 다른 사용자가 XP에 포트 스캐닝을 하는 것을 탐지하려고 한다. 이에 따라 룰을 추가하여 보자.

   

시나리오 순서 설명

  1. Hping을 이용해서 각 플래그옵션을 이용한 공격으로 발생되는 패킷 확인

       

  • SYN 패킷

       

    위를 살펴보면 공격자(172.168.10.10)에서 지속적으로 1004번 포트로 SYN Packet을 전송하는 것을 볼 수 있다.

   

  • ACK 패킷

       

       

    위를 살펴보면 공격자(172.168.10.10)에서 지속적으로 1004번 포트로 ACK Packet을 전송하는 것을 볼 수 있다.

이처럼 Hping2 툴을 이용하여 FIN, SYN, RST, PUSH, ACK, URG Flag등은 각각 Flag의 이름을 달고 패킷이 전송 되는 것을 볼 수 있었다. 이러한 사실을 이용하여 Nmap Port Scanning을 탐지 해보도록 하자.

   

  1. Nmap Port Scanning(-sS , -sF , NULL, XMAS)를 탐지

    가. -sS 탐지 = 먼저 SYN 패킷을 이용하는 옵션인 -sS를 탐지해보도록 하자.

  • 공격자에서 -sS를 이용한 포트 스캐닝 수행

       

    위처럼 먼저 SYN Packet을 보낸 후 ACK 패킷을 받아 서버 자체가 운용되고 있는지 판단을 한 후 SYN 패키을 각 서비스포트마다 보내어 활성화 되어있는 포트를 찾아낸다. 우리는 이 SYN 패킷을 탐지하는 Snort Rule을 구성해보도록 하자.

       

  • Snort Rule 형식

    alert tcp !192.168.10.10 any -> 192.168.10.20 any (msg:Nmap -sS Detect"; flags:S; threshold:type both, track by_src, count 20, seconds 10; sid:10000030;) 본인은 이처럼 룰을 지정해주었다. 간략하게 설명한다면 먼저 flag값을 S즉 SYN 패킷이 유발될때 탐지를 한다는 뜻이고 관리자가 아닌 PC가 WIN_XP에게 유발 할때 탐지하도록 했다. 이때 시간은 10초당 20번의 패킷이 유발되는 것으로 조정하여 매우 짧은 시간에 여러번의 비정상적인 패킷이 유발됨을 봄으로써 포트 스캐닝 임을 알 수 있도록 하였다.

       

  • 결과 확인

       

       

    위처럼 정상적으로 -sS의 옵션을 이용한 포트 스캐닝을 탐지하는 것을 볼 수 있다. Wireshark로 보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

    위의 패킷을 살펴본다면 10번째 패킷을 잡은 것으로 해당 패킷을 보면 22번 포트 즉, SSH 서비스에 대한 활성화 여부를 알아보는 포트 스캐닝 패킷임을 알 수 있다.

       

    나. -sF 탐지 = FIN 패킷을 이용하는 옵션인 -sF를 탐지해보도록 하자.

  • 공격자에게서 -sF를 이용한 포트 스캐닝 수행

       

       

    위처럼 FIN 패킷을 이용하여 각 서비스의 활성화 여부를 스캐닝 하는 것을 확인 할 수 있다. 이것을 탐지하는 Rule을 적용해보도록 하자.

       

  • Snort Rule 형식

    alert tcp !192.168.10.10 any -> 192.168.10.20 any (msg:Nmap -sF Detect"; flags:F; threshold:type both, track by_src, count 20, seconds 10; sid:10000031;) 본인은 위처럼 룰을 정해주었다. -sS와 동일하되 flags 옵션만 F즉 FIN 패킷이 비정상적으로 과도하게 유발 될 때를 탐지하는 형식이다.

    정상적으로 탐지를 했는지 결과를 살펴보도록 하자.

       

  • 결과 확인

       

       

    위처럼 정상적으로 -sF옵션을 이용한 포트 스캐닝을 탐지하는 것을 확인 할 수 있다. Wireshark로 패킷을 보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

       

    패킷을 살펴본다면 이번에는 FIN 패킷을 이용하여 111번 포트 서비스의 활성화 여부를 스캐닝 하는 것을 볼 수 있다.

       

    다. NULL 탐지 = NULL 패킷을 이용하는 옵션인 -NULL을 탐지해보도록 하자.

    NULL 옵션은 말 그대로 아무런 flags 옵션을 주지 않고 포트를 스캐닝 하는 옵션이다. 먼저 공격을 수행해보도록 하자.

  • 공격자에서 NULL 옵션을 이용한 포트 스캐닝 수행

       

       

    위처럼 none즉 flags에 아무런 옵션이 지정되지 않은 패킷이 전달 되는 것을 볼 수 있다. 이것이 바로 NULL 옵션을 이용한 포트 스캐닝이다. 이 스캐닝을 탐지할 수 있는 Rule을 정해보도록 하자.

       

  • Snort Rule 형식

    alert tcp !192.168.10.10 any -> 192.168.10.20 any (msg:Nmap Null Detect"; flags:!AFPSUR; threshold:type both, track by_src, count 20, seconds 10; sid:10000032;) 본인은 이처럼 입력을 하였다. 이전과 동일 하되 !AFPSU 즉 , 부정연산자인 '!'를 사용하여 각 패킷의 옵션이 할당 되지 않았을 경우 탐지하도록 하였다. 결과를 확인해보도록 하자.

       

  • 결과 확인

       

       

    위의 그림을 살펴보면 Flags: 0x00 즉 아무런 옵션도 지정되 않았음을 볼 수 있다. 즉 정상적으로 NULL 옵션을 이용한 포트 스캐닝을 탐지 하는 것을 볼 수 있다.

       

    라. XMAS 탐지 = URG, PUSH, FIN 패킷을 이용하는 옵션인 XMAS을 탐지해보도록 하자.

       

  • 공격자에서 XMAS 옵션을 이용한 포트 스캐닝 수행

       

       

    이처럼 XMAS는 FIN, PSH, URG가 전달 되는 것을 볼 수 있다. 우리는 이 옵션을 이용한 XMAS 포트 스캐닝을 탐지 해보도록 하자.

       

  • Snort Rule 형식

    alert tcp !192.168.10.10 any -> 192.168.10.20 any (msg:Nmap XMAS Detect"; flags:UPF; threshold:type both, track by_src, count 20, seconds 10; sid:10000033;) 본인은 이처럼 입력을 하였다. 이전과 동일하되 Flag를 UPF로 지정하여 URG,PSH,FIN 옵션이 짧은 시간에 다량으로 유발될 때 탐지하도록 하였다. 결과를 확인 해보도록 하자.

       

  • 결과 확인

       

       

    위처럼 XMAS를 이용한 포트 스캐닝을 정상적으로 탐지 하는 것을 볼 수 있었다. Wireshark로 확인 해보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

       

    위처럼 Flags가 FIN, PSH, URG가 셋팅 되어서 올 경우를 정상적으로 탐지 한 것을 볼 수 있다.

       

   

======================================================================================

시나리오

Snort를 이용한 Reverse Shell 탐지

   

시나리오 사용 툴

  • Wireshark
  • netcat

   

시나리오 망 구성도

   

   

시나리오 개념

  • 공격자인 BackTrack인 Netcat을 어떤 방법으로든 XP에게 심어 놓은 후 특정 Port를 열고 XP가 세션 요청을 하길 기다리고 있다. 이 경우 XP의 Shell 권한을 따기 위해 공격자는 백도어 등을 이용 Netcat를 실행 시킨다. 관리자는 이 경우를 탐지하기 위한 Rule을 Snort에 추가해보도록 하자.

       

시나리오 순서 설명

  1. 공격자는 Netcat을 실행하여 특정 포트를 열고 대기를 하도록 한다.

       

       

  2. 공격자는 피해자에게 Netcat을 실행 시킬 수 있는 악성코드나 백도어 등을 심어 놓은 후 피해자가 세션을 요청하도록 한다. 이때 발생하는 패킷을 확인 한 후 Snort Rule을 지정해주도록 하자.

       

       

    위처럼 공격자가 어떤 경로를 이용해서든 피해자에게서 세션 요청을 하도록 하고 그 결과 값으로 자신의 CMD 창을 보내도록 하는 것을 볼 수 있다. 패킷을 확인해보도록 하자.

       

       

       

    위를 살펴보도록 하자. 먼저 내부에서 외부로 SYN을 보내는 것을 확인 할 수 있다. 사실 이 경우 매우 많은 경우 중에 하나이다. 인터넷 접속등 모든 Network 환경을 사용할 경우 일어날 수 있는 패킷이며 이 패킷을 Rule로 지정하면 안될 것이다. 그래서 본인은 문자열을 탐지하도록 해보았다. HTTP 프로토콜로 전성된 부분을 살펴보면 PSH, ACK의 Flags 옵션을 사용하며 내부에서 외부로 Microsoft windows XP 와 버전을 보내는 것을 볼 수 있다. 이 경우 내부에서 외부로 이러한 메시지를 보내는 경우는 거의 없다고 봐야 된다. 외부에서 Telnet의 서비스를 사용할때나 나올법한 메시지이고 관리자는 해당 XP에 Telnet 서비스를 수행한 적이 없기 때문에 나올 수가 없는 문자열이 되는 것이다. 이것을 이용하여 Rule을 지정해보도록 하자.

       

  • Snort Rule 형식

    alert tcp 192.168.10.0/24 any -> !192.168.10.0/24 any (msg:Reverse Shell Detect"; flag s:PA; content:"Microsoft"; nocase; sid:10000034;) 본인은 이처럼 입력을 하였다. 피해자인 XP와 같은 네트워크 대역대에서 같은 대역대가 아닌 어떠한 Host로든 PUSH, ACK를 셋팅한 flags 옵션과 Microsoft라는 문자열을 포함해서 보내는 패킷을 탐지하도록 한 것이다. 결과를 확인해보도록 하자.

       

  • 결과 확인

       

       

    위처럼 정상적으로 Reverse Shell 공격을 탐지 한 것을 볼 수 있다. Wireshark로 패킷을 분석해보도록 하자.

       

  • Wireshark로 패킷 덤프 분석

       

    위의 그림을 살펴본다면 피해자가 공격자인 172.168.10.10으로 Microsoft가 담긴 문자열과 PSH, ACK가 셋팅된 flags 옵션을 포함해서 패킷을 전송하는 것을 볼 수 있으며 이 것으로 우리는 Reverse Shell을 탐지 할 수 있다.

       

 

 

 

 

 

출처 : http://god2zuzu.blog.me/70168951403
         (해당 사이트로 가서 그림을 꼭 참조 할 것)

 

 

 

 

신고

Comment +0