기본적인 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에 기본적인 룰 추가
- 먼저 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에 추가해보도록 하자.
- /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옵션만을 이용한 패킷 덤프 추출
시나리오 망 구성도 위와 동일
- Netcat을 이용하여 데이터를 주고 받을 시 패킷 덤프 분석
위의 패킷 덤프 파일처럼 Netcat을 이용한 데이터 통신에서는 HTTP Portf를 이용하여 데이터를 주고받는 것을 볼 수 있다. Test라는 문자열에는 ASCII 값으로 변환한 54 65 73 74 가 전달 되는 것을 볼 수 있다.
- 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옵션을 통한 패킷 덤프 추출
- 이전의 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라는 문자가 있기만 하면 검출 하겠다는 옵션을 추가하도록 한다.
위처럼 Test, test, TEST , 123456Test의 데이터를 보냈다. 정상적으로 Snort에서 검출 하는지 보도록 하자.
3. Snort 패킷 검출 여부 확인
Snort에서 정상적으로 4개의 데이터에 대한 패킷을 검출하는 것을 볼 수 있다. Wireshark로 정상적인 패킷을 검출한 것인지 확인해보도록 하자.
4. Wireshark를 통한 패킷 덤프 분석
위 처럼 정상적으로 BackTrack에서 보냈던 모든 데이터를 잡는 것을 확인 할 수 있다.
서브시나리오 No.3
Content와 offset과 nocase를 이용한 데이터 검출
- 이전의 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이 된다.
이전과 동일하게 데이터를 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
(해당 링크로 이동 후 그림을 꼭 참조 할 것.. 정말 유용한 정보이다)
'Security > Snort' 카테고리의 다른 글
침입 탐지 시스템 IDS와 침입 방지 시스템 IPS (0) | 2015.02.04 |
---|---|
Snort 2.9.1 설치 방법 (0) | 2014.03.31 |
Snort를 이용한 Brute Force 공격 탐지 (0) | 2014.03.31 |
Snort를 이용한 Port Scanning & Reverse Shell 탐지 (0) | 2014.03.31 |
Snort를 이용한 DOS 형태의 공격 탐지 (0) | 2014.03.31 |
댓글