enable
conf t
mirdate(config)#hostname mirdate (호스트명 mirdate로 설정하기)
mirdate(config)#no hostname (호스트명 취소하기)

DNS서버 명령어 찾지않기
mirdate(config)#no ip domain-lookup

로깅 싱크설정스위치에서 설정작업을 하다보면 명령어 입력도중 시스템 관련메시지가 자동으로 표시되므로 명령어를 제대로 입력하기 위해 싱크작업을 한다
mirdate(config)#line 0 16
mirdate(config-line)#logg sync

콘솔접속 유지하기
mirdate(config)#line console 0 
mirdate(config-line)# exec-timeout 0

패스워드 설정
mirdate(config)# enable secret cisco
해당명령어는 관리자 패스워드를 cisco 로 설정하겠다는 뜻이다

라인상황 확인하기
mirdate#show line

라인상황을 확인후 VTY 설정을 한다
mirdate(config)#line vty 0 15
mirdate(config-line)# password cisco
이러면 원격접속 라인 0~ 15까지 라인의 패스워드가 cisco 로 설정된다

vty 패스워드는 암호화 되지 않았기에 암호화를 한다
mirdate(config)#service password-encryption

.VLAN 1에 IP 할당하기
mirdate(config)#int vlan 1
mirdate(config)#ip address 10.10.10.10 255.255.255.0
mirdate(config)#no shutdown (포트 활성화)

설정 저장
mirdate(config)#do write memory

컨피그 확인 방법
mirdate#show running-config

배너달기
mirdate(config)#banner motd *Authonized access only!!*시작전후 *을쓴다

한글배너 입력하기
mirdate(config)# default-value exec-character-bits 8
mirdate(config)# banner motd *비인가자의 접속을 엄금합니다!!*
mirdate(config)#

인터페이스 설명달기
mirdate(config)# interface f 1/0/1
mirdate(config)# description mirdate1
mirdate(config)# interface f 1/0/2
mirdate(config)# description mirdate2

기본설정파일 셋팅
enable
config terminal
no ip domain-lookup
enable secret $gm@te2oo8

alias exec c config terminal
alias exec r show running-config
alias exec i show ip route
alias exec b show ip interface breif

line consol 0
logging synch
exec-timeout 0
lin vty 0 5pass $gm@te2oo8
exit
hostname

NTP 서버 주소
time.bora.net
time.nist.gov
time.windows.com
time.google.com

CISCO 장비 시간 확인 명령
mirdate#sh clock
.07:37:23.322 UTC Tue Jun 29 2010

CISCO 장비 시간대 설정 변경
mirdate#conf t
mirdate(config)#clock timezone KST 9
mirdate(config)#exit
mirdate#wr
mirdate#sh clock
.16:39:10.918 KST Tue Jun 29 2010

CISCO 장비 시간 설정
mirdate#clock set 22:25:00 29 jun 2010

CISCO 장비 NTP 설정
mirdate#conf t
mirdate(config)#ntp server [서버IP주소]
mirdate(config)#exit
mirdate#wr

 

빠른 스패닝트리 설정

mirdate#conf t

mirdate(config)#spanning-tree mode rapid-pvst
mirdate(config)#spanning-tree portfast edge default
mirdate(config)#spanning-tree extend system-id

mirdate(config)#exit
mirdate#wr

mirdate#show running-config 로 확인

Wireguard 설정의 검색 키워드는 'Wireguard site to site' 또는 'Wireguard road warrior'을 사용하면 됩니다.

 

라우터<->PC나 폰등 클라이언트 연결의 경우, 이러한 방식의 VPN에 대한 키워드는 road warrior입니다.
WAN아이피가 유동방식이라면, 클라이언트쪽 endpoint에 DDNS주소를 넣으면 됩니다.

아래는 참고 영상 입니다.

https://www.youtube.com/watch?v=ZNyCtMyGzLk 

 

Cisco_Catalyst_2960-L_Easy_Setup_Guide_20161101_KO.pdf

2.69MB

cisco-catalyst-2960-l-series-switches.pdf

0.42MB

"WS-C2960L-16TS-LL" 해당 모델은 콘솔 케이블로 2가지 이용이 가능 합니다.

 

 

전용 콘솔 케이블이 없는 경우 전면의 "미니 5핀 (일반 케이블도 가능)"을 이용하여 콘솔에 접속 할 수 있으며 시스코 USB 드라이버를 설치해주시면 콘솔로 접근할 수 있습니다.

 

윈도우10에서도 정상적으로 동작하는 드라이버 입니다.

설치가 정상적으로 완료되면 장치관리자에 아래 이미지와 같은 장치가 생성 됩니다.

 

 

이후 장치관리자의 포트에서 포트 확인후 일반 시리얼과 같은 방식으로 이용 하시면 됩니다.

Cisco USB Serial.exe

5.60MB

[오류증상]

*Mar  1 00:01:08.039: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/network-confg) failed
*Mar  1 00:01:08.039: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/cisconet.cfg) failed
*Mar  1 00:01:08.048: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/switch-confg) failed
*Mar  1 00:01:08.048: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (tftp://255.255.255.255/ciscortr.cfg) failed

 

 

[해결방법]

Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#no service config
Switch(config)#exit
Switch#wr
Building configuration...
[OK]
Switch#
*Mar  1 00:13:47.343: %SYS-5-CONFIG_I: Configured from console by console
Switch#

 

[출처]

https://community.cisco.com/t5/networking-documents/the-user-receives-the-sys-4-config-resolve-failure-error-message/ta-p/3111681

다시 배포하기 전에 스위치를 평면화하는 것은 항상 웹에서 조회하는 간단한 작업 중 하나이므로 나중에 시간을 절약하고 여기에 문서화해야 한다고 생각했습니다.

1 단계.

"모드" 버튼을 누른 상태에서 콘솔 케이블을 연결하고 스위치의 전원을 켭니다.

 

 

 

 

 

 

이렇게 하면 플래시 파일 시스템이 초기화되기 전에 부팅 프로세스가 중단되고 잠시 후("모드" 버튼을 계속 누르고 있음) 다음 프롬프트가 표시됩니다.

미디어 유형 1에 드라이버 버전 1 사용
기본 이더넷 MAC 주소: 4c:30:2d:81:ef:80
Xmodem 파일 시스템을 사용할 수 있습니다.
암호 복구 메커니즘이 활성화되었습니다.
초기화하기 전에 시스템이 중단되었습니다.
플래시 파일 시스템. 다음 명령은 초기화됩니다
플래시 파일 시스템 및 운영 로드 완료
시스템 소프트웨어:
flash_init
 신병
스위치:

2 단계.

flash_init 명령을 사용하여 플래시 파일 시스템을 초기화합니다 .

 

switch: flash_init
플래시 초기화 중...
mifs[2]: 파일 10개, 디렉토리 1개
mifs[2]: 총 바이트 수: 1806336
mifs[2]: 사용된 바이트 수: 612352
mifs[2]: 사용 가능한 바이트 수: 1193984
mifs[2]: mifs fsck는 1초가 걸렸습니다.
mifs[3]: 파일 0개, 디렉토리 1개
mifs[3]: 총 바이트 수: 3870720
mifs[3]: 사용된 바이트 수: 1024
mifs[3]: 사용 가능한 바이트 수: 3869696
mifs[3]: mifs fsck는 0초가 걸렸습니다.
mifs[4]: 파일 5개, 디렉토리 1개
mifs[4]: 총 바이트 수: 258048
mifs[4]: 사용된 바이트 수: 9216
mifs[4]: 사용 가능한 바이트 수: 248832
mifs[4]: mifs fsck는 0초가 걸렸습니다.
mifs[5]: 파일 5개, 디렉토리 1개
mifs[5]: 총 바이트 수: 258048
mifs[5]: 사용된 바이트 수: 9216
mifs[5]: 사용 가능한 바이트 수: 248832
mifs[5]: mifs fsck는 1초가 걸렸습니다.
 -- 더 --
mifs[6]: 566개 파일, 19개 디렉토리
mifs[6]: 총 바이트 수: 57931776
mifs[6]: 사용된 바이트: 28429312
mifs[6]: 사용 가능한 바이트 수: 29502464
mifs[6]: mifs fsck는 21초가 걸렸습니다.
...플래시 초기화를 완료했습니다.

3단계.

플래시 디렉토리에서 config.text, private-config.text 파일을 삭제합니다 .

switch: delete flash:config.text
"flash:config.text"(y/n)를 삭제하시겠습니까?y
"flash:config.text" 파일이 삭제되었습니다.
switch: delete flash:private-config.text
"flash:private-config.text"(y/n)를 삭제하시겠습니까?y
"flash:private-config.text" 파일이 삭제되었습니다.

4단계.

플래시 디렉토리에서 vlan.dat 파일을 삭제합니다 .

switch: delete flash:vlan.dat
"vlan.dat"(y/n)를 삭제하시겠습니까?y
"flash:vlan.dat" 파일이 삭제되었습니다.

5단계.

스위치를 재부팅하면 완료됩니다.

swtich: boot
"flash:c2960s-universalk9-mz.122-58.SE2.bin" 로드 중...
--- 시스템 구성 대화 상자 ---
비밀 경고 활성화
----------------------------------
장치 관리자에 액세스하려면 활성화 암호가 필요합니다.
초기 구성 대화 상자에 들어가면 암호 활성화를 묻는 메시지가 표시됩니다.
초기 구성 대화 상자에 들어가지 않도록 선택하거나 암호 활성화를 설정하지 않고 설정을 종료하는 경우
구성 모드에서 다음 CLI를 사용하여 암호 활성화를 설정하십시오.
암호 0 <일반 텍스트 암호> 활성화
----------------------------------
초기 구성 대화 상자로 들어가시겠습니까? [예 아니오]:
% '예' 또는 '아니오'로 답하십시오.

 

읽어 주셔서 감사합니다.

기존 사용하고 있던 MikroTik RB4011iGS+RM 후속 모델이 출시되서 냉큼 사버렸습니다.

기존 장비도 성능은 남아돌지만서도 궁금증을 못 이겨.. 이놈의 장비병이 또... 쿨럭;

 

기존 세팅내역이 많아서 바로 옮겨타기 힘드네요. 천천히 세팅해서 갈아타야겠습니다.

다음으로 2세대 방화벽은 보통 차세대(Next Generation) 방화벽이라 하며 통상 줄여서 NG방화벽이라고 호칭합니다. 1세대 방화벽과의 가장 큰 차이점은 단말이 사용하는 응용 프로그램(Application)을 인식해서 선별적으로 차단이 가능하다는 점입니다.

 

 

1세대 방화벽은 포트 넘버로만 트래픽을 구분할 수 있었기 때문에 TCP 80을 사용하는 모든 트래픽은 모두 차단하거나 허용할 수밖에 없었습니다. 예를 들면 인터넷 사용은 허용하면서 메신저나 P2P 다운로드 트래픽은 차단하고 싶거나, 인터넷 중에서도 유튜브, 인스타그램 등만 선별적으로 차단하는 보안 정책은 모두 같은 TCP 80 포트를 사용하기 때문에 불가능하였습니다.

 

 

우리가 사용하는 인터넷과 같은 통신은 참가하는 모든 단말이 동일한 규칙으로 신호를 주고받아야 하는데 이를 통신 규약을 프로토콜(Protocol)이라고 합니다. 그중에 가장 대표적인 것이 ISO(국제표준화기구)에서는 제정한 OSI 7 레이어 참조 모델이 입니다.

 

 

아래 <그림 1> OSI 프로토콜의 3번째 Network 계층이 IP 주소를 정의하는 곳이며, 4번째 Transport 계층이 TCP 혹은 UDP의 포트 넘버를 정의하는 단계입니다. 즉 1세대 방화벽은 4 계층까지만 모니터링이 가능한 장비이기 때문에 마지막 7번째 Application 계층인 응용 프로그램 단계는 모니터링이 불가능합니다. 

 

 

차세대 방화벽은 Application계층 데이터 모니터링이 가능하기 때문에 4 계층에서 같은 서비스 포트를 사용하는 프로그램이더라도 서로 구분이 가능합니다. 즉 포트 넘버가 아니고 카카오톡 같은 메신저, 토렌트 같은 P2P 파일공유 트래픽을 구분할 수 있습니다. 그뿐만 아니라 카카오톡 트래픽 중에서도 단순한 채팅 트래픽과 파일을 공유하는 트래픽을 구분할 수 있기 때문에 채팅만 허용하고 파일 전송만 선별적으로 차단하는 제어가 가능합니다.

 

 

 

그럼 차세대 방화벽은 어떻게 애플리케이션을 구분할 수 있을까요? 아래 <그림 2>와 같이 패킷이 들어오면 일단 보안정책으로 포트 넘버를 먼저 확인하게 됩니다. 그다음으로 패킷의 L7 레벨에 있는 데이터를 읽어서 방화벽이 가지고 있는 트래픽 패턴 정보와 동일한 패턴이 발견되는지 확인하여, 애플리케이션을 식별하고, 식별이 되지 않으면 다음으로 프로토콜 디코더라는 일종의 패킷 해석기를 이용하여 주고받는 내용의 특성을 분석하고 트래픽을 판별하는 방식을 이용합니다. 

 

 

이 단계에서도 판별이 되지 않으면 휴리스틱(Heuristic) 기법을 이용하여 정확하게 패턴이 일치하지 않더라도 통계적인 기법으로 유사도를 측정하여 80~90% 이상 패턴이 유사하면 특정 애플리케이션 트래픽으로 판별하는 방식으로 동작합니다.

 

 

 

 

그럼 현재 회사에서 많이 사용 중인 차세대 방화벽에서 어떤 애플리케이션을 탐지하고 허용/차단할 수 있는지 알아보도록 하겠습니다. 최근 10년간 가장 트래픽을 많이 발생시키고 있는 프로그램 중의 하나는 단연코 P2P 파일공유 프로그램들입니다. 

 

 

가장 대표적인 경우가 토렌트(torrent)류의 프로그램입니다. 웹하드와 같이 특정한 서버에 접속해서 파일을 다운로드하는 것이 아니라, 서버와 클라이언트가 구분되지 않고, 네트워크에 접속하는 각 개인이 보유 중인 파일을 접속된 다른 사용자들에게 파일을 전송하는 서버 역할을 하고, 내가 없는 파일은 다른 사용자에게서 받아 오는 클라이언트 역할을 동시에 수행하는 프로그램입니다.

 

 

이 프로그램의 특징은 일대일로 파일을 보내고 받는 것이 아니라, 내가 파일을 받을 때 하나의 파일을 여러 개로 쪼개서 여러 개의 단말에서 동시에 파일을 받을 수 있고, 반대로 파일을 보낼 때도 여러 개의 단말에 동시에 전송할 수 있는 점입니다. 

 

 

그래서 동일한 파일을 여러 단말이 많이 보유할수록 파일 전송속도가 빨라지는 특징이 있습니다. 문제는 대용량의 영상 파일을 주고받을 경우 많은 트래픽을 유발하기 때문에 집에서 사용하는 것은 문제가 없으나 회사 같은 조직 내에서 사용할 경우 네트워크 대역폭을 소모시켜서 업무에 지장을 줄 수 있다는 점입니다. 아래 <그림 3>는 방화벽에서 탐지할 수 있는 P2P 파일 공유 프로그램 목록입니다.

 

 

 

 

목록에 보면 다양한 파일공유 프로그램을 확인할 수 있고 분류 및 위험도, 기본통신방식 등이 나열되어 있습니다. 위험도는 벤더에서 임의로 지정한 등급으로 숫자가 높을수록 위험도가 높은 것으로 특정 등급을 묶어서 차단하거나 로그를 남기는 설정을 할 때 사용할 수 있습니다.  

 

 

파일공유 프로그램 이외에도 네이버 같은 포털 서비스, 다량의 트래픽을 유발하는 영상 스트리밍 서비스인 유튜브(YouTube), 채팅과 파일 전송 기능이 있는 카카오톡, 최근 인기가 높아진 인스타그램과 같은 SNS 서비스 등도 식별이 가능합니다.

 

 

아래 <그림 4>과 같이 네이버 트래픽에서도 블로그, 라인과 같은 메신저, 메일, 엔드라이브 같은 웹하드 서비스, 네이버 TV 같은 비디오 스트리밍 트래픽을 식별할 수 있기 때문에 세분화해서 트래픽을 제어할 수 있습니다.

 

 

 

 

아래 <그림 5>은 유튜브 트래픽 식별 목록입니다. 영상을 시청하는 것 이외에도 영상을 업로드하는 트래픽도 식별할 수 있는 것을 확인할 수 있습니다.

 

 

 

 

아래 <그림 6>은 국민 메신저인 카카오톡 트래픽 식별 목록입니다. 거의 전 국민이 사용하는 서비스이다 보니 보안을 위해 사용을 원천 차단한다면 원성이 대단할 것입니다. 이럴 경우 채팅 서비스는 허용하고 파일 전송 기능만 사내에서 사용을 차단한다면 보안을 강화하면서 임직원의 민원도 해결할 수 있을 것 같습니다.

 

 

 

 

마지막으로 아래 <그림 7>와 같이 사진 기반으로 운영되는 SNS인 인스타그램도 단순한 검색과 포스팅 트래픽을 구별할 수 있기 때문에 좀 더 유연한 보안 정책을 설정 가능합니다.

 

 

 

 

지금까지 차세대 방화벽의 애플리케이션 탐지 기능에 대해 살펴보았습니다. 대략 10년 전부터 차세대 방화벽이 도입되기 시작하면서, 최근에 도입되는 방화벽은 모두 차세대 방화벽을 표방하고 있습니다. 대부분의 벤더는 애플리케이션 탐지 기능을 기본 기능으로 제공하지 않고 별도의 서비스 라이선스를 구매해야 사용 가능하게 하고 있습니다. 

 

 

그 이유는 새로운 서비스가 계속 등장하고 있기 때문에 거기에 맞추어 식별 목록을 계속 업데이트해 줘야 하기 때문입니다. 보통 년 단위로 라이선스를 갱신해야 장비에서 업데이트된 식별 목록을 주기적으로 다운로드할 수 있습니다.

웹 방화벽(Web Application Firewall)은 통상 앞글자를 따서 와프(WAF)라고 부릅니다. 앞에서 설명한 차세대 방화벽도 Web 트래픽은 식별할 수 있기 때문에 웹 방화벽과 동일한 기능을 지원하지 않을까 생각할 수 있습니다. 그럼 여기서 차세대 방화벽과 웹 방화벽의 차이점을 먼저 알아보도록 하겠습니다.

 

차세대 방화벽은 모든 트래픽에 대해 L7 레벨을 모니터링하고 제어할 수 있는 장비이며 네트워크의 다양한 트래픽을 관리할 수 있는 장비라면, 웹 방화벽은 http, https트래픽만 집중해서 모니터링하여 웹서버 해킹을 방지하는 목적으로 http method(get, put)와 같은 세부적인 옵션 값에 따라 임계치를 설정하여 차단하는 장비로써 차세대 방화벽으로 차단이 불가능한 웹 기반 공격을 전문적으로 탐지 차단하는 보안장비입니다.

 

일반적으로 차세대 방화벽이 설치되어 있더라도 업무상 혹은 비즈니스 목적으로 운영되는 웹 기반 서버가 있다면 추가적으로 웹 방화벽을 설치하여 웹 서버의 보안을 강화하는 것이 일반적인 적용 방법입니다.

 

그럼 웹 방화벽이 등장한 배경을 알아보죠. 앞에서 설명한 1세대 혹은 2세대(차세대) 방화벽의 보급이 늘어나면서, 서비스하지 않는 모든 포트는 방화벽의 보안정책으로 차단되게 되었습니다. 보통 서버들은 사용자가 이용하지 않는 서비스라도 OS가 설치되면서 기본적으로 오픈되는 포트가 여러 개 있습니다.

 

예를 들면 윈도 OS를 설치하면 파일공유, 원격 접속 등의 위한 포트가 기본으로 오픈되면서 방화벽에서 차단되지 않으면, 인터넷으로 통해서도 접속이 가능한 경우가 종종 있습니다. 이렇게 기본적으로 오픈되는 포트를 통해 많은 공격이 이루어졌지만, 방화벽의 보급이 늘어나면서 서비스하는 포트 이외에는 인터넷으로 통해 접근이 불가능해지면서, 공격자의 공격 대상이 줄어들게 되었습니다.

 

그런데 대부분의 조직에서 웹 서버는 기본적으로 사용하기 때문에 방화벽에서 HTTP, HTTPS 서비스 포트는 열지 않을 수가 없습니다. 공격자의 입장에서는 HTTP, HTTPS 이외에는 열려 있는 포트가 없다 보니, 웹 서비스만 집중적으로 연구해서 공격 기술을 개발할 수밖에 없는 환경이 된 것입니다. 

 

이렇게 웹 기반 공격이 점점 발전되어 다양화되면서, 홈페이지 등이 변조되거나, 웹 서버를 해킹한 후에 이를 통해 사내의 DB서버에 접근해서 조직의 정보를 탈취하는 일이 빈번하게 발생되었습니다. 이런 웹 기반의 공격에 대응하기 위해 웹 공격 유행을 분석하여 3~4년 단위로 유행하는 공격 방식을 연구하여 가장 많이 사용하는 공격 유형 10가지(Top 10)를 발표하는 조직이 있습니다.

 

OWASP(Open Web Application Security Project)라는 일종의 커뮤니티로 다양한 개발자, 보안 관리자 등이 자발적으로 참여하여 조직한 비영리단체로 OWASP Top 10 이란 이름으로 주기적으로 보고서를 발표하고 있습니다. 최근 발표된 버전은 2017로서 아래 <그림 1>과 같이 A1부터 A10까지 가장 빈번하게 발생되는 웹 공격 10개를 나열하고 각 공격 별 취약점 확인 방법과 보안 대책을 설명하고 있습니다.

 

 

제일 빈번하게 발생되는 공격인 인젝션(Injection:주입)의 경우 말 그대로 클라이언트의 입력값을 조작하여 비 정상적인 명령어를 주입하고 해당 서버의 DB에 있는 다양한 정보를 탈취하거나 관리자 권한을 획득하는 공격 방법입니다. 쉬우면서도 공격 성공률이 높은 유형으로 2017년 3월에 발생한 "여기 어때"라는 숙박 정보 회사의 고객 DB정보를 통해 가입자 절반인 99만 명의 이름, 휴대전화 번호, 숙박 이용정보가 노출되는 사고도 이 공격으로 발생한 사고였습니다.

 

가장 유명한 공격 중 하나인 SQL Injection 공격 방식을 설명드리면, 아래 <그림 2>에 있는 1번과 같이 정상적인 SQL 명령어가 있다고 가정해 보겠습니다. 여기에 2번과 같이 ' OR 1=1 --'이라는 문구를 중간에 삽입하여 3번과 같이 SQL 명령어를 웹 서버로 전송하게 합니다. 1번 명령어는 ID가 INPUT1이고 패스워드가 INPUT2인 사용자의 모든 정보를 불러오게 하는 명령어인데 여기에 특정 문구를 삽입해서 3번과 같이 변조하여 서버로 전송하게 되면, 삽입한 문구 중 '--' 뒤에 있는 문구는 모두 주석 처리되고, OR 1=1은 언제나 True가 되기 때문에 결과적으로 서버에서는 유저 테이블에 있는 모든 정보를 불러오게 하는 명령어로 인식되기 때문에 서버가 보유한 모든 유저들의 정보가 공격자에게 출력되는 결과가 초래되게 됩니다.

 

 

그럼 이런 공격을 웹방화벽에서는 어떻게 차단할 수 있는지 알아보죠. 웹 방화벽은 웹 서버 앞에서 사전에 HTTP 패킷을 분석하여 정상적이라고 판단되는 트래픽만 웹 서버로 전달합니다. 아래 <그림 3>와 같이 트래픽이 들어오면 아래와 같은 여러 가지 단계의 분석을 통해 공격을 차단하게 됩니다.

 

1. 패킷의 L7 레벨을 확인하여 정상적인 HTTP구문 인지 먼저 확인한다.

2. URI(예:www.abc.com/user)를 식별하여 적용되어 있는 정책을 확인하고 어떤 공격 탐지 rule을 적용하여 검사할 것인지 판단한다.

3. 적용된 공격 탐지 룰에 따라 여러 가지 공격을 탐지한다. 이때 블랙리스트(black list)를 이용하여 사용할 수 없는 구문이나 패턴을 먼저 차단시킨다.

4. 화이트리스트(white list)를 이용하여 허용된 구문 또는 패턴을 통과시킨다.

5. 정상적인 시도라도 임계치 설정을 통해 짧은 시간 동안 여러 번의 시도가 있으면 차단시킨다. 6. 서버에서 응답하는 웹 페이지가 변조되어 있는지, 에러 코드를 반환을 통해 공격자에게 정보를 제공하는지 확인하여, 관리자에게 경보를 알리거나 반환 값을 숨긴다.

 

 

웹 방화벽의 경우도 일반 방화벽과 같이 시간이 지나면서 점점 발전을 거듭하였습니다. 초기 웹 방화벽은 사전에 관리자가 설정하는 화이트리스트, 블랙리스트에 의존하기 때문에 오탐(정상적인 트래픽인데 공격으로 판단하는 경우) , 미탐(공격 트래픽인데 탐지하지 못하는 경우)이 발생하는 경우가 매우 빈번하였습니다. 

 

이런 문제는 웹 방화벽이 URI(예: www.daum.net/news), 웹 트래픽 내용을 모니터링하여 학습하면서 정상적인 접속 내용은 화이트리스트를 자동으로 추가하거나, 기존에 학습된 내용과 현저히 다른 내용이 보이면 공격으로 판단하는 등, 사전에 등록된 패턴에 의존하지 않고, 유사도 등을 측정하여 공격을 차단하는 방식이 사용되었습니다.

 

최근에는 정치적이거나 민족주의적인 이유들, 예를 들면 815 광복절에 일본 해커가 독도 홍보사이트를 공격하여 홈페이지 내용의 위 변조를 시도하는 것 같이 과시형 공격이나, 웹 서버를 통해 고객 자료를 탈취하여 비트코인 등의 금품을 요구하는 행위 등 다양한 공격이 웹 서버를 대상으로 이루어지고 있습니다. 쇼핑몰, 서비스 예약, 웹 포탈, 홍보 사이트와 같이 조직의 비즈니스가 웹에서 대부분 이루어지는 조직에서 이제 웹 방화벽이 필수적인 보안 장비가 되었습니다.

비무장지대 - DMZ(Demilitarized Zone)란 단어 그대로, 아군과 적군 어느 쪽이든 무장을 하지 않는 지리적 군사 영역을 의미합니다.

 

네트워크에도 DMZ라는 것이 있는데 이것은 무엇이고 언제 사용하는지 알아보겠습니다.

 

컴퓨팅과 네트워크를 사용하는 기관들은 보안의 목적으로 폐쇄 형태의 내부 네트워크(LAN: Local Area Network)만 사용하여 각종 인트라넷이나 내부 시스템을 운영하는 방법도 있지만 이 경우엔 외부 네트워크로는 단절되어 웹 검색이나 이메일링, DNS 사용, FTP 등의 기본적인 인터넷 서비스를 사용할 수 없습니다.

 

외부 네트워크 연결을 위해 별도의 네트워크 케이블링을 하여, 물리적으로 내부/외부 다른 네트워크를 사용할 수 있지만 매우 불편한 상황은 어쩔 수 없습니다. 필자도 예전 SI 사업장에서 내부망/외부망 랜선을 각각 바꿔가며 프로젝트를 했던 경험이 있습니다.

 

문제는 비단 사람뿐만 아니라, 내부 IT 시스템들도 때로는 외부 네트워크를 사용해야 한다는 점입니다. 리눅스 운영체제, MySQL 등을 비롯한 각종 오픈 소스 설치 파일을 다운로드해서 설치하고, 패치 파일 버전을 확인하고 제때 업데이트해야 하는 과정이 있습니다. 업무상 기관의 이메일을 사용해야 하는데 이메일 서버는 내부에 있다 해도 SMTP는 외부에서 진입할 수 있도록 해야 하며, 기관에서 운영하는 웹 사이트는 외부에서 접속하지만 내부에 웹 서버가 존재합니다. 이러한 요구 사항을 DMZ로 해결할 수 있습니다.

 

"내부 네트워크에 존재하지만, 외부에서 접근할 수 있는 특수한 네트워크 영역을 DMZ라고 합니다."

 

DMZ의 활용 예제를 알아보겠습니다.

 

우리 회사의 IT 시스템은 외부에서 접속해야 할 웹 서버/이메일 서버/FTP 서버 시스템이 존재합니다.
이 시스템 영역을 A라고 가정해보겠습니다.

우리 회사의 IT 시스템은 내부에서만 사용하는 시스템 또한 존재합니다.
이 시스템 영역을 B라고 가정해보겠습니다.

외부에 열린 A에서, B로의 접속은 보안상 우려(해킹 등)가 있으므로 접속을 막습니다.
따라서, A를 통해 내부 시스템에 접속이나 침입이 불가능합니다.

B에서, A로의 접속은 보안상 우려가 없고, A가 가진 정보가 필요한 경우가 있으므로 접속을 허가합니다.
따라서, 내부 시스템은 외부 인터넷을 통해 얻은 정보를 내부 DB, 스토리지 등에 저장하고, 활용할 수 있습니다.

 

위 시나리오를 다이어그램으로 대략 표현하면 아래와 같습니다. 외부 연결이 필요한 시스템들을 DMZ에 배치합니다. 그렇다고 모든 연결이 DMZ로 가능한 것이 아니라, 알맞은 서비스만 연결이 되도록 방화벽 설정이 필요합니다. DMZ에서 내부로의 연결은 불가능하지만 반대로 내부에서 DMZ로의 연결은 가능합니다. 이는 또 다른 방화벽에서의 설정으로 구현 가능합니다.

 

DMZ를 구글링 해보면, 아래와 같이 단일 방화벽 구성도 가능합니다. (실제로 이렇게 사용을 더 많이 하고 있습니다)

이번 글에서는 가상화 기술이 발전하면서 거기에 맞추어 방화벽이 어떻게 발전했는지 알아보도록 하겠습니다. CPU의 코어(core) 수가 증가하면서, 하나의 CPU에서 동시에 여러 개의 OS를 구동할 수 있는 기술이 발전하였습니다. 이 기술을 통해 가상 서버의 사용이 활성화되면서, 이 기술을 서버가 아닌 네트워크 장비에도 활용하고 싶은 수요가 생기면서 NFV(Network Function Virtualization: 네트워크 기능 가상화)라는 용어가 등장하였습니다.

 

현재 대부분의 네트워크 장비, 예를 들면 라우터, 스위치, 방화벽 등은 서버 형태가 아닌 별도의 전용 장비로 공급되고 있습니다. 하지만 이런 장비들도 최초에는 일반적인 서버에 프로그램 방식으로 설치되는 사용되기 시작하였습니다. 지난 글에서 소개드린 1세대 방화벽의 시초인 체크포인트(checkpoint)의 경우에도 처음에는 H/W가 아니라 S/W로 출시되었습니다. 

 

즉, 방화벽을 설치하기 위해서 일반적인 서버를 구매하여 여기에 방화벽 소프트웨어를 설치하고, 서버 뒤에 네트워크 케이블을 연결하여 동작시켰습니다. 2000년 초중반까지도 이런 방식처럼 서버 형태로 공급되어,, 아주 높은 성능을 요구하지 않는 환경에서는 범용 서버의 CPU 성능으로도 웬만한 트래픽은 문제없이 처리할 수 있었습니다.

 

하지만 점점 처리해야 할 트래픽이 증가하면서 범용 서버의 성능으로는 한계에 다다르게 되었습니다. 이제 범용 서버가 아닌 전용 장비가 필요한 시기가 된 것이죠. 이때 등장한 것이 넷스크린(Netscreen)이라는 방화벽이었습니다. 이 회사의 방화벽은 기존 S/W방식으로 제품을 팔지 않고 전용 장비에 전용 OS를 설치하여, 그 당시에는 획기적인 성능인 2 Gbps의 처리 성능을 내는 장비까지 출시하였습니다. 

 

아래 <그림 1>과 같이 대략 13U(56cm)로 랙의 거의 절반을 차지하는 크기에 무게는 23kg이었습니다. 범용 CPU가 아니고 전용 ASIC칩(주문형 반도체: 특정한 기능을 가속해서 처리할 수 있도록 개발된 칩)을 직접 개발하여 적용하고 유닉스를 커널 컴파일(제작자의 의도에 따라 OS를 최적화시키는 작업)하여 전용 OS를 개발하여 적용하였기 때문에, 기존 범용 서버에서 나오는 성능의 대략 10배 이상의 성능을 달성할 수 있었습니다.

 

 

그럼 다음으로 서버 가상화 기술에 대해 알아보죠. 가상화 기술은 물리적으로 독립된 서버에 여러 개의 가상 서버를 동시에 운영할 수 있는 기술입니다. 아래 <그림 2>를 보면 왼쪽 서버처럼 제일 하단에 검은색의 CPU, 메모리, 저장장치, 랜카드로 이루어진 서버 하드웨어가 존재하고, 그 상단에 윈도 혹은 리눅스, 유닉스 등의 운영체제가 설치됩니다. 이렇게 운영체제가 설치되면, 사용자가 원하는 Web, DNS, Mail 등 의 응용프로그램이 설치되어 독립된 서버로 동작하게 됩니다.

 

그런데 <그림 2 >의 오른쪽 서버와 같이 동일한 하드웨어에 OS 대신에 VMware 같은 하이퍼바이저(Hypervisor)가 설치되면 CPU에 있는 각각의 코어(Core)를 독립된 하나의 가상 CPU로 인식하여, 하나의 가상 서버를 구성할 수 있도록 해줍니다. 또한 메모리, 하드디스크 등도 사용자가 설정하는 용량만큼 분할하여 각각의 가상 서버에 독립적으로 할당시켜 물리적으로 한 개의 메모리와 하드디스크가 가상 서버 개수만큼 존재하는 것처럼 동작하게 도와줍니다.

 

 

이렇게 생성된 가상 서버를 보통 VM(Virtual Machine) 혹은 가상 머신이라고 말합니다. 요즘 인텔 서버용 CPU당 코어 수는 모델에 따라 4개에서 28개까지 장착되어 있기 때문에 하나의 CPU가 있는 서버에 VM당 2개의 코어를 할당한다고 가정하면 최대 14개의 VM을 작동시킬 수 있습니다. 물리적으로 한대의 서버에 14개의 가상 서버를 운영할 수 있다면 가상화를 사용하지 않는 서버만 운영할 경우보다 서버 운영 자원의 절감이 가능합니다. 랙에 설치되어 차지하는 공간, 전원 소모량, 발열을 냉각하기 위한 항온항습기 전기 소모량 등 서버 유지비의 획기적인 절감이 가능하기 때문에 현재 많은 조직에서는 규모의 차이만 있을 뿐 많은 서버를 가상 서버로 운영하고 있습니다. 

 

물리적인 자원의 절감뿐만 아니라 서버를 운영하는 데 있어서도 시간과 인력을 절감할 수 있습니다. 신규로 OS를 설치할 경우 짧게는 20분에서 1시간 이상의 시간이 소요되었지만, 가상화 기술을 이용하게 되면 VM이 하나의 파일로 만들어 지기 때문에, 하이퍼바이저를 통해 동일한 OS에 동일한 소프트웨어가 설치된 VM을 배포하여 3~5분 내에 원하는 개수만큼 바로 사용할 수 있게 됩니다. 그리고 VM에 할당하는 CPU, 메모리를 하드웨어 자원에 여유가 있다면 VM에 할당하는 자원을 원하는 만큼 늘이거나 줄일 수도 있고, 저장 공간도 늘일 수 있기 때문에 서비스 접속자의 증가에 유연하게 대응이 가능합니다.

 

VM이 파일 형태로 존재하기 때문에 하드웨어의 공간적 제약도 없게 됩니다. 특정 서버에 있는 VM들의 사용량이 증가하여 해당 서버의 CPU 사용량이 높아지더라도 가상화 관리 프로그램이 자동으로 CPU 자원에 여유가 있는 서버로 VM을 중단 없이 이동시킬 뿐만 아니라 하드웨어의 장애가 발생되더라도 VM을 짧은 시간 내에 다른 서버에서 재가동시키기 때문에 서버 관리자의 업무량도 획기적으로 줄일 수 있게 되었습니다.

 

서버 가상화를 운영 중인 조직은 자기도 모르는 사이에 아주 기초적이기는 하지만 NFV 기술을 사용하고 있다고 볼 수 있습니다. 여러 대의 VM들이 하나의 서버에서 작동하게 되면 같은 서버 내의 VM 간의 통신뿐만 아니라 서버 외부의 다른 서버 와도 통신이 필요합니다. 아래 <그림 3>과 같이 하이퍼바이저 내에는 'vSwitch'라는 가상의 스위치가 존재합니다. 물리적인 스위치 대신에 가상의 스위치를 이용하기 때문에 사용 포트 수의 제한이나, 물리적인 케이블의 연결이 필요 없게 되었습니다.

 

아래 <그림 3>의 왼쪽 그림과 같이 총 4개의 VM이 있고 각각 vNIC이라는 가상의 네트워크 카드를 통해 vSwitch에 가상으로 연결되어 있고 이를 통해 오른쪽 3개의 서버 VM이 서로 통신이 가능하게 됩니다. 제일 왼쪽 VM은 방화벽 프로그램을 구동시켜 방화벽으로 동작 중입니다. 서버 VM에 연결된 가상 스위치가 방화벽 VM으로 연결되어 있고, 방화벽 VM은 다시 다른 가상 스위치를 통해 서버 외부로 연결되어 있습니다. 이렇게 가상으로 연결된 네트워크 구성을 실제 장비로 동일하게 구성하면 오른쪽 그림과 같습니다. 서버 3대가 하단 스위치에 연결되어 있고, 하단 스위치는 방화벽에 방화벽은 상단 스위치에 연결되어 있어 인터넷 등의 외부 네트워크로 통신이 가능하게 구성할 수 있습니다.

 

 

서버 3대, 스위치 2대, 방화벽 1대를 구성할 경우, 차지하는 공간, 소비되는 전력량, 발열로 인한 냉각 비용을 고려하면, 총 6대의 장비를 서버 1대로 구성할 수 있게 되면 여러 물리적인 자원의 획기적인 절감이 가능해집니다. 그뿐만 아니라, 이렇게 가상으로 구성된 전산 자원이 소프트웨어적인 파일 단위로 존재하기 때문에 쉽게 복제하여, 짧은 시간에 동일하게 구성할 수도 있습니다. 구성 변경을 할 경우에도 장비가 있는 데이터센터에 직접 가서 장비를 추가로 설치하거나 네트워크 케이블을 연결할 필요 없이 원격에서 관리 프로그램을 이용하여 손쉽게 장비를 추가, 삭제하거나 네트워크 연결 수정이 가능합니다.

 

보통 <그림 3>과 같이 VM에 일반적인 웹, DB 같은 서버 프로그램 대신에 방화벽, 라우터, 스위치 프로그램을 동작시켜 가상화된 네트워크 기능을 수행하는 것을 NFV(네트워크 기능 가상화)라고 정의합니다. 네트워크 장비 공급사인 시스코, 주니퍼 등의 종합 벤더뿐만 아니라 포티넷, 팔로알토 네트웍스, 파이어아이 등의 보안 전문 벤더까지 실제 장비와 동일한 기능을 수행하는 소프트웨어를 출시 중입니다. 아래 <그림 4>와 같이 일반적으로 기존에 출시되던 제품명 앞 혹은 뒤에 V 혹은 VM이라는 이름을 붙여서 소프트웨어로 제품을 판매하고 있습니다.

 

우선 방화벽의 기술발전 역사를 알아보도록 하겠습니다.

본격적인 방화벽이 나오기 전에는 통신을 전송하기 위한 통신장비인 라우터의 필터 기능에서부터 트래픽 제어 기능이 사용되었습니다. 우리가 데이터를 전송한다는 것은 최대 1500byte의 크기로 잘게 쪼개진 데이터 묶음으로 만들어진 패킷(packet)을 보내고 받는 것을 말합니다. 

 

 

이 패킷의 헤더에는 출발지, 목적지 IP주소와 서비스 포트가 기록되어 있습니다. 이 패킷 헤더 정보를 확인해서 라우터에 설정된 필터 정보를 참조하여 들어온 패킷을 허용하거나 차단하는 방식으로 동작합니다. 이런 필터가 증가하게 되면, 라우터의 부하가 증가하게 되어 패킷 전송이라는 본래 기능에 문제가 생기게 되고, 고정된 포트를 사용하지 않고 접속할 때마다 서비스 포트가 변경되는 RPC, FTP 같은 서비스의 경우에는 인식이 불가능한 문제점이 발생되면서 트래픽 제어를 위한 전용 장비의 필요성이 제기되었습니다.

 

 

 1994년 체크포인트(Checkpoint)라는 회사에서 이러한 문제점을 해결한 1세대 방화벽을 개발하였습니다. 개발된 방화벽의 가장 큰 특징은 스테이트풀 인스팩션(Stateful Inspection) 기능이 추가된 것입니다. 단순히 들어오는 패킷을 필터링하는 것이 아니라, 클라이언트와 서버 간 통신 상태를 모니터링하여 연결 테이블을 만들고 관리하면서 좀 더 세밀한 트래픽 제어가 가능해진 것입니다.

 

 

 

 

위의 <그림 1>을 보면 왼쪽의 단말장비에서 오른쪽의 웹 서버로 접속을 시도한다고 가정해 보도록 하겠습니다. 방화벽에는 인터넷에서 DMZ 구역으로 들어오는 패킷에 대해 출발지는 ANY, 목적지는 10.0.0.1, 서비스 포트는 TCP 80 포트에 대해 허용하는 보안 정책이 설정되어 있습니다.

 

 

접속 단말에서 서버로 웹 페이지를 요청하는 트래픽이 방화벽에 도착하면, 방화벽은 해당 요청에 대해 보안 정책을 확인하여 해당 패킷을 오른쪽 웹 서버로 전달합니다. 서버는 단말의 요청에 응답하기 위해 웹 페이지를 접속 단말을 목적지로 하는 패킷으로 생성하여 전송합니다. 이 응답 패킷이 방화벽에 전달되면 방화벽은 다시 보안정책을 참고하여 패킷을 허용할 건지 차단할 건지 결정할 것을 예상할 수 있습니다.

 

 

이 단계에서 스테이트풀 인스펙션의 장점이 발휘됩니다. <그림 1> 방화벽 정책은 외부에서 DMZ 구역으로 갈 수 있는 보안 정책이 있지만 반대 방향인 즉, DMZ 구역에서 외부로 나가게 허용하는 보안 정책은 없습니다. 방화벽은 기본적으로 보안 정책에 적용되지 않는 모든 패킷은 차단하게 되어있습니다. 즉, 서버에서 단말로 가는 응답 패킷은 차단될 것으로 예상할 수 있으나, 스테이트풀 인스팩션 기능이 동작하기 때문에 서버에서 보낸 페이지는 방화벽을 정상적으로 통과하게 됩니다.

 

 

즉 방화벽이 만들어서 관리하는 세션 테이블을 참조하여 들어오는 응답 패킷의 출발지, 목적지 IP 및 Port와 일치하는 세션 리스트가 있는지 확인되면, 해당 패킷은 응답 패킷으로 판단하여 보안 정책이 없더라도 해당 패킷을 클라이언트로 전달하는 것입니다. 방화벽은 데이터를 요청하는 트래픽이 들어오면 서버로 전달하면서 동시에 세션 테이블(Session Table)을 만들어서, 서버와 클라이언트 간의 통신 내역을 모니터링하고 제어하는 용도로 사용합니다.

 

 

아래 <그림 2>는 방화벽에서 출력한 세션 테이블입니다. In항목에 나와 있는 것과 같이 출발지 IP 10.10.10.235에서 출발지 포트 50588을 사용하여 st0.511 인터페이스로 들어와서 목적지 IP 172.70.1.13, 목적지 포트 TCP 7001로, 패킷 수 6개, 456 byte 크기의 패킷이 보안정책 "untrust-to-trust"에 적용되어 목적지로 전달되었습니다. 다음으로 Out에 표시된 것과 들어올 때와 출발지와 목적지 정보가 반대로 바뀌어서 서버에서는 데이터를 요청하는 단말로 응답 패킷을 4개, 427 byte 만큼 전송한 내역을 확인할 수 있습니다.

 

 

 

 

다시 말하면 방화벽은 요청 패킷이 들어오면 서버로 전달하면서 서버에서 다시 클라이언트로 응답할 패킷 정보를 예상하여 미리 세션 테이블을 만들어 둡니다. 실제 응답 패킷이 들어오면 먼저 만들어 둔 세션 테이블에서 정보가 일치하는 세션 정보가 있는지 확인되면, 보안 정책이 없더라도 패킷을 단말로 전달하는 것입니다. 이 기능을 이용하면, 관리자가 서버의 응답 패킷을 예상해서 보안정책을 미리 만들어 둘 필요 없이 방화벽이 자동으로 응답 패킷에 대한 보안정책을 생성했다가 연결이 종료되면 삭제하는 것처럼 작동합니다.

 

 

이런 작동 방식은 회사 내부에 있는 단말이 인터넷을 사용할 때도 동일하게 적용됩니다. 즉 Trust에서 Untrust 방향으로, 출발지는 단말 IP 대역이고 목적지는 ANY이며, 서비스 포트는 TCP 80으로 허용하는 보안 정책이 있으면, 사내의 단말이 인터넷의 웹 서버로 요청 패킷을 보낸 후, 외부에서 내부로 들어오는 응답 패킷은 별도의 보안 정책이 없더라도 인터넷에서 사내의 단말까지 전달되는데 아무 문제가 없습니다. 

 

 

인터넷에서 내부로 들어올 수 있는 통로가 필요할 때만 잠깐 생성되었다가 필요가 없으면 바로 삭제되는 것처럼 동작하기 때문입니다. 즉 라우터와 같이 별도의 통신 연결 정보를 관리하지 않는 장비의 경우 필터(Access List-ACL) 기능과 같이 외부에서 내부로 들어올 응답 패킷을 위한 보안 정책을 미리 만들어 둘 필요가 없기 때문에, 미리 만들어 둔 보안정책을 통해 발생 가능한 잠재적인 보안 위협을 감소시킬 수 있는 점이 1세대 방화벽의 가장 큰 장점이라고 할 수 있습니다.

 

 

그래서 방화벽의 경우 단순히 트래픽을 처리할 수 있는 성능도 중요하지만, 세션을 관리할 수 있는 능력도 중요합니다. 세션을 관리하는 능력을 판단하는 기준은 기본적으로 아래 두 가지 성능을 판단기준으로 사용합니다.

 

 

1. 초당 세션 생성률(CPS- Connection per seconds)

 1초 동안 신규로 세션을 생성할 수 있는 능력. 이 성능은 갑작스럽게 트래픽이 급증하는 경우 예를 들면, 특정한 이벤트(명절 차표 구매, 학기초 수강신청, 재난지원금 지급신청, 상품초 저가 세일)가 발생할 경우 짧은 시간 안에 급속하게 증가하는 접속 요구에 대응할 때 중요한 성능 지표입니다.

 

 

2. 최대 동시 세션 관리수(Maximum Concerent Session)

장비가 동시에 관리할 수 있는 연결 최대수. 이 성능은 방화벽을 통해 연결되는 최대 연결수를 얼마나 지원하는지를 판단하는 기준입니다. 최신 방화벽의 경우 가장 낮은 성능의 장비라도 만개 단위(대략 32,000~64,000개)의 세션을 동시에 관리할 수 있고 고성능 장비의 경우 억 개 단위까지 기능을 지원하고 있습니다. 이 성능은 얼마나 많은 서버와 일반 유저의 트래픽을 처리할 수 있는지 판단하는 기준으로 사용하고 있습니다.

 

 

지금까지 설명한 Stateful 방식의 장비에 대비하여 세션을 관리하지 않는 장비를 보통 Stateless장비라고 말합니다. 스위치, 라우터 같이 단순하게 패킷을 해당하는 목적지로 전달만 하는 장비를 말하는데 이런 장비의 경우 트래픽을 제어하기 위해 ACL을 사용하고 있습니다.  그럼 라우터 장비의 ACL은 어떤 경우에 이용할 수 있을까요?

 

 

방화벽이라는 장비는 앞에서 설명한 것과 같이 세션을 관리하는 장비이다 보니 동시에 관리 가능한 세션수를 초과하게 되면 더 이상 세션을 관리할 수 없기 때문에 신규 세션을 생성할 수 없게 됩니다. 즉 신규 트래픽을 처리할 수 없는 상황이 발생하는 것입니다.

 

 

최근의 DDoS 공격의 경우 이러한 방화벽의 취약점을 악용하여, 의도적으로 방화벽의 관리 가능한 세션수를 초과하게 하여, 서비스를 방해하는 공격이 빈번하게 발생되고 있습니다. 이런 경우에 공격을 수행하는 출발지 IP를 식별할 수 있다면 방화벽 앞단에 있는 라우터의 ACL 필터를 생성하여 방화벽 앞단에서 공격을 차단할 수 있으면 방화벽이 처리해야 하는 세션수를 줄여 주어 서비스의 중단을 막을 수 있습니다.

포트스캐닝(Port Scanning)이란?

 

 해커가 악의적인 공격을 수행하기 위해 취약점을 찾는 과정 중 수행하는 사전 작업이라고 할 수 있습니다.

 

피해자 시스템 혹은 네트워크를 선정한 뒤

 

해당 시스템이나 네트워크가 어떤 포트를 열고 서비스를 하고있는지 알아내기 위함 입니다.

 

가령, 해당 시스템이 23포트를 열고 Telnet서비스를 하고있는 것을 알아내었다면

 

해커는 Telnet서비스에 대한 취약점을 이용하여 적극적인 공격을 수행할 수 있겠습니다.

 

1.TCP Connect 스캔 (TCP Open 스캔)

 

 

구 분	설 명
스캔 방법	TCP/IP소켓 프로그래밍의 connect()함수를 사용하여 포트별로 직접 접속하여 스캔하는 방식
Open Port	정상적으로 연결 설정(3way handshaking)이 완료되며 연결 완료 후 RST+ACK를 전송하여 연결을 종료
Close Port	포트가 닫힌 상태이면 상대 시스템으로부터 RST+ACK를 수신
특 징	상대 시스템의 포트Open/Close 여부를 알아내는 가장 확실한 방법이며, 직접 연결을 맺기 때문에 시스템 로그가 남음

 

 

2.TCP SYN 스캔 (Half-Open 스캔)

 

 

구 분	설 명
스캔 방법	raw소켓에 접근해서 TCP 프로토콜 헤더의 제어비트(Control Bit)를 설정하여 스캔
Open Port	Target으로부터 SYN+ACK 응답이 올 경우 ACK가 아닌 RST를 보내어 연결을 강제 종료
Close Port	닫힌 경우 Target으로부터 RST+ACK를 수신
특 징	완전한 연결 설정(3way handshaking) 과정을 수행하지 않기 때문에 시스템 로그가 남지 않음

 

 

3. Stealth 스캔 (FIN / NULL / XMAS 스캔)

 

 

구 분	설 명
스캔 방법	TCP 제어비트(Control Bit)를 비정상적으로 설정해서 스캔
Open Port	Target시스템이 아무런 응답이 없음
Close Port	Target시스템으로부터 RST+ACK를 받게됨
특 징	시스템 로그를 남기지 않음

 

4.TCP ACK 스캔

 

 

 

구 분	설 명
스캔 방법	TCP 제어비트(Control)비트 중 ACK를 설정하여 스캔 포트의 오픈여부를 확인하는 용도가 아니라 방화벽의 필터링 정책을 테스트하기 위한 스캔
Filtered	Target으로부터 ICMP응답이 돌아오거나 아무런 응답이 없음
Not Filtered	필터링 되지 않을 경우 RST를 수신
특 징	방화벽이 상태기반(stateful) 방화벽인지 단순히 들어오는 SYN을 차단하는 정책을 가지고있는지 확인하는 용도 단순히 SYN만을 차단하는 정책일 경우 방화벽을 통과할 수 있음

 

5.UDP 스캔

 

 

 

구 분	설 명
스캔 방법	스캐닝하고자하는 포트번호를 목적지포트로 설정하여 UDP 전송
Open Port	아무런 응답이 없음
Close Port	ICMP Destination Port Unreachable 수신
특 징	-

 

 

6.Decoy 스캔

 

구 분	설 명
스캔 방법	실제 스캐너 주소 이외에 다양한 위조된 주소로 스캔하는 방식
Open Port	-
Close Port	-
특 징	다양한 IP로 스캔하기 때문에 피해자는 누가 스캔을하는지 알아채기 어려움

 

 

ARQ : Automatic Repeat Request의 약자로, 자동 반복 요청을 의미. 에러가 발생한 경우 재전송을 요구하는 방식 

Go-back-N ARQ와 Selective Repeat ARQ는 모두 전송층(Transport Layer)의 프로토콜이며 이 두가지를 혼합 및 개선하여 만든 프로토콜이 TCP(Transmission Control Protocol)이다.

이 글에서 사용된 '프레임'이라는 용어는 전송층에서 쓰이는 '패킷'과 같은 개념이며 데이터링크층에서 사용되는 전송단위인 프레임과는 다르다.

• 무잡음 채널에서의 프로토콜
• 잡음이 있는 채널에서의 프로토콜

네트워크관리사 2급 실기(라우터 시험) 정리

 

2021.10.06. by 영진직업전문학교 류원석 교수

 

문제1) ROUTER의 호스트 이름을 'ICQA'로 설정하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)# hostname ICQA

ICQA(config)#exit

ICQA#copy r s

Destination filename [start-config]?

 

문제2) 인터페이스 정보를 확인하고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#show interface

Router#copy r s

Destination filename [start-config]?

 

문제3) 접속한 사용자를 확인하고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#show user

Router#copy r s

Destination filename [start-config]?

 

문제4) 라우팅 테이블을 확인하고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#show ip route

Router#copy r s

Destination filename [start-config]?

 

문제5) 플래시를 확인하고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#show flash

Router#copy r s

Destination filename [start-config]?

 

문제6) Serial 2/0의 대역폭을 2048k로 설정하고, NVRAM에 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#int s2/0

Router(config-if)#ban 2048

Router(config-if)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제7) Serial 2/0의 clock rate를 72k로 설정하고, NVRAM에 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#int s2/0

Router(config-if)#clock rate 72000

Router(config-if)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제8) FastEthernet 0/0의 description을 설정하고 NVRAM에 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#int fa0/0

Router(config-if)#des ICQA

Router(config-if)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제9) FastEthernet 0/0의 IP Address를 192.168.2.1/30과 192.168.3.1/30 Secondary로 설정하고 저장하시오.

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#int fa0/0

Router(config-if)#ip add 192.168.2.1 255.255.255.252

Router(config-if)#ip add 192.168.3.1 255.255.255.252 secondary

Router(config-if)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제10) Default-Gateway를 설정하고 저장하시오. (IP: 192.168.0.10) (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#ip default-gateway 192.168.0.10

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제11) Router1 Telnet에 접근하는 Password를 ‘TELPass’로 설정하고, 상태를 저장하시오.

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#li v 0 4

Router(config-line)#password TELPass

Router(config-line)#login

Router(config-line)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제12) Telnet에 5분 50초 동안 신호가 없는 경우 해당 세션을 자동으로 종료하도록 라우터를 설정하시오.

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#li v 0 4

Router(config-line)#exec-t 05 50

Router(config-line)#login

Router(config-line)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제13) Router1 console의 패스워드를 ICQACon으로 설정하고, 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#li c 0

Router(config-line)#login

Router(config-line)#password ICQACon

Router(config-line)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제14) Router2의 Interface Serial 2/0을 활성화시키고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#int s2/0

Router(config-if)#no shutdown

Router(config-if)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제15) Hostname을 network2로 변경하고, Console 0의 Password를 route5로 변경하고 login하시오.

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#hostname network2

network2(config)#li c 0

network2(config-line)#password route5

network2(config-line)#login

network2(config-line)#exit

network2(config)#exit

network2#copy r s

Destination filename [start-config]?

 

문제16) domain-name을 ‘DOMAIN’으로 설정하고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#ip domain-name DOMAIN

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제17) Router1에서 Console 0번 Password를 설정하고 저장하시오. (Password : asin)

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#li c 0

Router(config-line)#login

Router(config-line)#password asin

Router(config-line)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제18) Router1에서 Virtual Terminal Password를 설정하고 저장하시오. (Password : asin)

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#li vty 0 4

Router(config-line)#login

Router(config-line)#password asin

Router(config-line)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제19) Router1에서 아래의 결과값과 동일하게 설정하고 저장하시오. (hostname : asin21, password : asinpass)

(완료된 설정은 startup-config에 저장하시오.)

hostname asin21 ! enable password asinpass ! Interface Ethernet 0 no ip address no ip direct-broadcast shut down !

정답)

Router>en

Router#conf t

Router(config)#hostname asin21

asin21(config)#enable password asinpass

asin21(config)#exit

asin21#copy r s

Destination filename [start-config]?

 

문제20) Router1에서 FastEthernet 1/0의 IP 및 서브넷을 설정하고 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#int fa1/0

Router(config-if)#ip add 210.108.245.1 255.255.255.192

Router(config-if)#no shutdown

Router(config-if)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

 

문제21) Router1에서 login할 때 나타나는 배너(Banner)를 설정하시오. (banner : Welcome to Asin Router)

(완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#banner motd #

Welcome to Asin Router

#

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제22) Router1의 AUX Port로 접속할 때 암호를 묻는 AUX 패스워드를 설정하고 NVRAM에 저장하시오.

(단, AUX 패스워드는 ‘AUXICQA’) (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#conf t

Router(config)#li aux 0

Router(config-line)#password AUXICQA

Router(config-line)#login

Router(config-line)#exit

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

문제23) Router1에 현재 실행 중인 CPU 상태를 NVRAM에 저장하시오. (완료된 설정은 startup-config에 저장하시오.)

정답)

Router>en

Router#show process

Router#copy r s

Destination filename [start-config]?

 

문제24) 아래와 같이 Router1의 접근 계정(icqa)을 설정하고, 현재 상태를 NVRAM에 저장하시오.

(단, 계정(icqa)의 패스워드는 network이고 대소문자를 구분한다.) (완료된 설정은 startup-config에 저장하시오.)

hostname Router ! username icqa password 0 network interface Ethernet 0 !

정답)

Router>en

Router>conf t

Router(config)#username icqa password network

Router(config)#exit

Router#copy r s

Destination filename [start-config]?

 

Ingress 필터링

라우터 외부에서 라우터 내부로 유입되는 패킷을 필터링하는 것이다.

패킷의 소스 IP 나 목적지 포트 등을 체크하여 허용하거나 거부하도록 필터링 하는 것을 뜻한다. 

공통적으로 필터링 하여야할 소스 IP는 인터넷 상에서 사용되지 않는 IP 대역

(대부분의 공격이 실제 존재하지 않는 위조된 IP 주소를 소스로 함)

 

Egress filtering 

라우터 내부에서 라우터 외부로 나가는 패킷의 소스ip를 체크하여 필터링

라우터를 통과하여 나가는 패킷의 소스 IP는 반드시 라우터와 같은 대역이여야 한다.

(라우터를 통해 나가는 패킷의 소스 ip 중 사용중인 ip 대역을 소스로 한 패킷은 허용하고 나머지는 거부 하도록 설정)

 

Blackhole filtering(Null routing 을 활용한 필터링)

특정한 ip 대역에 대해서 Null 이라는 가상의 쓰레기 인터페이스로 보내도록 함으로써 패킷의 통신이 되지 않도록 함

 

Unicast RPF

인터페이스를 통해 들어오는 패킷의 소스 ip 에 대해 라우팅 테이블을 확인하여 들어온 인터페이스로 다시 나가는지 확인

HTTP & HTTPS

HTTPS는 HTTP를 안전하게 만드는 방식이다

• HTTP
  • 인터넷 상에서 정보를 주고 받기위한 프로토콜(양식과 규칙의 체계)
  • 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜
  • 암호화되지 않은 방법으로 데이터를 전송한다. (악의적인 감청, 데이터 변조의 가능성)
• HTTPS
  • 보안이 강화된 HTTP
  • Hypertext Transfer Protocol Over Secure Socket Layer의 약자
  • 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
  • HTTPS는 HTTP의 하부에 SSL과 같은 보안계층을 제공함으로써 동작한다.

HTTPS는 TCP위에 놓인 보안계층(SSL)위의 HTTP이다

SSL 디지털 인증서

• 클라이언트와 서버간의 통신을 공인된 제3자(CA) 업체가 보증해주는 전자화된 문서

SSL 인증서의 장점 및 역할

• 통신 내용이 노출, 변경되는 것을 방지
• 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지 확인가능
• SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

SSL에서 사용하는 암호화의 종류

• 암호 : 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
• 키 : 암호의 동작을 변경하는 매개변수, 키에 따라서 암호화 결과가 달라지기 떄문에 키를 모르면 복호화가 불가능하다.

대칭키 암호화 방식

• 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
• 단점 : 단점은 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다.
• 대칭키를 전달하는 과정에서 키가 유출이 되면 암호의 내용을 복호화할 수 있기 때문에 위험하다
• 이를 보완하기 위해서 나온 방법이 공개키 암호화 방식이다.

공개키 암호화 방식

• 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
• A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화 하면 A키로 복호화 할 수 있는 방식
• 인코딩 키 (public key)는 공개되어 있으며 (그래서 공개키 암호방식이라는 이름이 붙었다.) 보통 디지털 인증서안에 포함되어 있다.
• 디코딩 키는 (secret key)는 호스트만이 개인 디코딩 키를 알고있다.
• 공개키와 비공개키의 분리는 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지의 디코딩은 비밀키 소유자에게만 부여한다.
• 이는 클라이언트가 서버로 안전하게 메시지를 발송하는 것을 쉽게 해준다.
• 단점 : 공개키 암호화 방식의 알고리즘은 계산이 느린 경향이 있다.

디지털 서명

디지털 서명의 동작방식

• 전자 서명을 통해서 누가 메시지를 썼는지 알려주고, 메시지가 위조되지 않았음을 증명할 수 있다. 전자서명은 SSL 인증서 에서 서비스를 보증하는 방법으로 활용된다.
• 공개키와 비공개키는 안전한 데이터 전달 이외에도, 데이터 제공자의 신원을 보장 하는데 사용할 수 있다.
• 비공개키의 소유자가 비공개 키를 이용해서 정보를 암호화 => 공개키와 함께 암호화된 정보를 전송 => 수신자는 공개키로 암호화된 정보를 복호화
• 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미한다.
• 즉 공개키가 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다. 이러한 것을 전자 서명이라고 부른다.

CA (Certificate Authority)

• 디지털 인증서를 제공하는 공인된 기업 (Certificate Authority 혹은 Root Certificate)
• 대표적인 CA 서비스 제공 기업과 시장점유율
  • Symantec (VeriSign, Thawte, Geotrust) with 42.9% market share
  • Comodo with 26%
  • GoDaddy with 14%
  • GlobalSign with 7.7%

SSL 인증서의 서비스 보증방법 및 동작방법

인증서 내용

• 인증서의 내용은 CA의 비공개 키를 이용해서 암호화 되어 웹브라우저에게 제공된다.
  • 서비스 정보 (인증서 발급자, CA의 디지털 서명,서비스 도메인)
  • 서버측 공개키

SSL 인증서의 서비스 보증방법

• 웹브라우저가 서버에 접속하면 서버는 제일 먼저 인증서를 제공한다.
• 브라우저는 인증서를 발급한 CA가 자신이 갖고있는 CA 리스트에 있는지 확인한다.
• 리스트에 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화 한다.
• 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미한다. 즉 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다.

SSL 동작방법

• 공개키 암호 방식은 알고리즘 계산방식이 느린 경향이 있다.
• 따라서 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키 암호화 방식을 혼합하여 사용한다.
• 안전한 의사소통 채널을 수립할 때는 공개키 암호를 사용하고, 이렇게 만들어진 안전한 채널을 통해서 임시의 무작위 대칭키를 생성 및 교환한다. 해당 대칭키는 나머지 데이터 암호화에 활용한다.
  • 실제 데이터 암호화 방식 : 대칭키
  • 상기 대칭키를 서로 공유하기 위한 암호화 방식 : 공개키

SSL 통신과정

• 컴퓨터와 컴퓨터가 네트워크를 통해서 통신을 할때 핸드쉐이크 -> 세션 -> 세션종료 의 과정을 거친다.
• 암호화된 HTTP 메시지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행한다.
• 핸드쉐이크의 목적은 아래와 같다.
  • 프로토콜 버전번호 교환
  • 양쪽이 알고 있는 pre master secret 키 생성 및 교환
  • 양쪽의 신원 인증
  • 채널을 암호화 하기 위한 임시 세션 키 생성
• SSL 통신과정을 간단하게 도식화 하면 아래와 같다.
• 생활코딩 SSL의 동작방법에 아주 쉽게 설명되어 있어서 함께 참고하면 좋다.

Snort 홈페이지의 기존 SNORT Users Manual 2.9.12 문서에서 Snort 규칙 관련 내용만 한글 번역함.

번역자 : KOROMOON

출처 : https://koromoon.blogspot.com/2020/10/snort-snort-rule-header-option.html

 

 

( 1 ) 기본 사항

 

Snort 는 유연하면서 강력한 그리고 간단한 규칙 기술 언어를 사용함.

대부분의 Snort 규칙은 한 줄로 작성됨.

1.8 버전 이상에서는 줄 끝 부분에 백슬래시(\)를 추가하여 규칙을 여러 줄로 확장할 수 있음.

그러나 규칙이 길지 않은 이상 가독성을 위해서 한 줄로 작성하는 걸 추천함.

 

< Snort 규칙 구성 요소 >

 

Snort 규칙은 두 개의 논리적 섹션으로 나뉘는데 각각 규칙 헤더와 규칙 옵션임.

규칙 헤더에는 행위(Action), 프로토콜, 출발지 주소, 출발지 포트, 방향성, 목적지 주소, 목적지 포트가 포함됨.

규칙 옵션에는 경고 메시지와 패킷의 어느 부분을 검사하여 규칙 행위을 수행해야 하는지 결정하는 정보가 들어 있음.

 

규칙을 구성하는 모든 요소는 표시된 규칙 행위를 실행할 때 참(True)이어야 함.

실행할 때 요소들은 논리적인 AND 문으로 형성하는 것으로 간주함.

동시에 다양한 Snort 규칙 라이브러리 파일들은 논리적인 OR 문으로 구성하는 것으로 간주함.

 

 

 

( 2 ) 규칙 헤더

 

 

2.1 규칙 행위

 

규칙 행위는 규칙 기준과 일치하는 패킷을 찾을 때 Snort 가 수행할 행위를 지시함.

alert, log, pass 이 3가지 기본 동작이 있음.

또한, 인라인 모드에서 Snort 를 실행할 경우 drop, reject, sdrop 와 같은 추가 옵션이 있음.

 

분류	설명
alert	선택한 alert 방법을 사용하여 경고를 생성한 다음 패킷을 기록함.
log	패킷 기록
pass	패킷 무시
drop	패킷 차단 및 기록
reject	패킷을 차단하고 기록한 다음 TCP 프로토콜이면 TCP Reset 플래그를 보내고 UDP 프로토콜이면 ICMP Port Unreachable 메시지를 보냄.
sdrop	패킷을 차단하지만 기록하지 않음.

 

 

2.2 프로토콜

 

현재 Snort 에서는 TCP, UDP, ICMP, IP 이렇게 4가지 프로토콜 분석 가능함. (규칙에 기재할 때 소문자로 기재할 것!)

앞으로 다른 프로토콜이 추가할 수 있을 것으로 전망됨. (ex. ARP, IGRP, GRE, OSPF, RIP, IPX)

 

 

2.3 IP 주소

 

IP 주소는 IP 와 CIDR 블록 형식으로 기재하며 any 키워드는 임의의 주소를 정의하는데 사용됨.

부정연산자 ! 를 사용할 경우 표시된 IP 주소 이외의 IP 주소만 적용됨.

쉼표로 구분된 IP 주소 목록을 대괄호 기호로 이용하여 표시함.

참고로 Snort 는 IP 주소 필드에 대한 호스트 이름 조회를 제공하는 매커니즘이 없음.

 

alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg:"external mountd access";)   alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> [192.168.1.0/24,10.1.1.0/24] 111 (content:"|00 01 86 a5|"; msg:"external mountd access";)

< 사용예 >

 

 

2.4 포트 번호

 

포트 번호는 포트, 범위연산자 :, 부정 연산자 ! 를 이용한 여러 가지 방법으로 지정함.

any 키워드는 모든 포트를 의미하는 와일드카드 값임.

 

 

2.5 방향 연산자

 

일방향 연산자 -> 와 양방향 연산자 <> 를 사용함.

참고로 규칙 일관성을 위해서 <- 기호는 사용하지 않음.

 

log udp any any -> 192.168.1.0/24 1:1024 log tcp any any -> 192.168.1.0/24 :6000 log tcp any :1024 -> 192.168.1.0/24 500: log tcp any any -> 192.168.1.0/24 !6000:6010 log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23

< 사용예 >

 

 

 

( 3 ) 규칙 옵션

 

규칙 옵션은 Snort 침입 탐지 엔진의 핵심이며 편의성과 유연성을 결합함.

모든 Snort 규칙 옵션은 세미콜론 문자(;)를 사용하여 서로 구분함.

규칙 옵션 키워드는 콜론 문자(:)를 사용하여 인수와 구분함.

 

규칙 옵션에는 아래 4 가지 주요 범주가 있음.

 

분류	설명
General	규칙에 대한 정보를 제공하지만 탐지 중에 영향을 주지 않음.
Payload	패킷 페이로드의 내부 데이터를 찾고 상호 관련됨.
Non-Payload	페이로드가 아닌 데이터를 찾음.
Post-Detection	규칙이 실행된 후에 발생하는 규칙 관련 트리거임.

 

 

 

( 4 ) General 규칙 옵션

 

 

4.1 msg

 

msg 키워드는 로깅 및 경고 엔진에 패킷 덤프 또는 경고와 함께 인쇄할 메시지를 알려줌.

 

msg:"<message text>";

< 형식 >

 

 

4.2 reference

 

reference 키워드를 사용하면 규칙에 대해서 외부 공격 식별 시스템에 대한 참조를 포함할 수 있음.

플러그인은 고유 URL 뿐만 아니라 여러 특정 시스템을 지원함.

 

reference:<id system>, <id>; [reference:<id system>, <id>;]

< 형식 >

 

alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio"; flags:AP; content:"|fff4 fffd 06|"; reference:arachnids,IDS411;)   alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-venglin-linux"; flags:AP; content:"|31c031db 31c9b046 cd80 31c031db|"; reference:arachnids,IDS287; reference:bugtraq,1387; reference:cve,CAN-2000-1574;)

< 사용예 >

 

System	URL Prefix
bugtraq	http://www.securityfocus.com/bid/
cve	http://cve.mitre.org/cgi-bin/cvename.cgi?name=
nessus	http://cgi.nessus.org/plugins/dump.php3?id=
arachnids	(currently down) http://www.whitehats.com/info/IDS
mcafee	http://vil.nai.com/vil/content/v_
osvdb	http://osvdb.org/show/osvdb/
msb	http://technet.microsoft.com/en-us/security/bulletin/
url	http://

< 지원 시스템 >

 

 

4.3 gid

 

gid 키워드(generator id)는 특정 규칙이 발생할 때 Snort 가 어떤 이벤트를 생성하는 지 식별하는데 사용됨.

현재 사용 중인 gid 에 대해서는 /etc/generators 파일을 참조 바람.

gid 키워드는 선택사항이며 규칙에 지정되지 않은 경우 기본값은 1 이며 규칙은 일반 규칙 하위시스템의 일부가 됨.

Snort 에 정의된 gid 와 잠재적인 충돌을 피하기 위해서 1,000,000 부터 사용하는 것이 좋음.

일반적인 규칙 작성할 경우, gid 키워드를 사용할 것!

이 옵션은 sid 키워드와 함께 사용해야 함.

etc/gen-msg.map 파일에 Preprocessor 및 Decoder gid 에 대한 자세한 정보가 들어 있음.

 

gid:<generator id>;

< 형식 >

 

alert tcp any any -> any 80 (content:"KOROMOON"; gid:1000001; sid:1; rev:1;)

< 사용예 >

 

 

4.4 sid

 

sid 키워드는 Snort 규칙을 고유하게 식별하는 데 사용됨.

이 정보는 출력 플러그인이 규칙을 쉽게 식별할 수 있게 함.

이 옵션은 rev 키워드와 함께 사용해야 함.

 

분류	설명
<100	향후 사용을 위해 예약됨
100~999,999	Snort 배포판에 포함된 규칙
>=1,000,000	사용자가 정의한 규칙

 

sid-msg.map 파일에는 Snort 규칙 ID 에 대한 경고 메시지 매핑이 들어 있음.

이 정보는 경고를 사후 처리하여 ID 를 경고 메시지에 매핑할 때 유용함.

 

sid:<snort rules id>;

< 형식 >

 

alert tcp any any -> an 80 (content:"KOROMOON"; sid:1000983; rev:1;)

< 사용예 >

 

 

4.5 rev

 

rev 키워드는 Snort 규칙의 수정 버전을 고유하게 식별하는 데 사용됨.

Snort 규칙 ID 와 함께 개정이 허용되며 서명 및 설명을 수정하여 업데이트 된 정보를 대체할 수 있음.

이 옵션은 sid 키워드와 함께 사용해야 함.

 

rev:<revision integer>;

< 형식 >

 

alert tcp any any -> any 80 (content:"KOROMOON"; sid:1000983; rev:1;)

< 사용예 >

 

 

4.6 classtype

 

classtype 키워드는 규칙에 대한 공격 범주화하는데 사용함.

Snort 는 기본적으로 제공하는 규칙에 대해서 공격 범주를 제공함.

 

classtype:<class name>;

< 형식 >

 

alert tcp any any -> any 25 (msg:"SMTP expn root"; flags:A+; content:"expn root"; nocase; classtype:attempted-recon;)

< 사용예 >

 

Snort 가 정의한 공격 범주 분류는 classification.config 파일에 있음.

이 파일은 다음과 같은 구문을 사용함.

config classification: <class name>,<class description>,<default priority>

 

이러한 공격 범주 분류는 아래 표에 나열되어 있음.

현재 4 가지 기본 우선 순위로 기재하였으며 1(높음) 은 가장 심각하고 4(매우 낮음) 는 가장 덜 심각함.

 

Classtype	설명	우선순위
attempted-admin	관리자 권한 획득 시도	high
attempted-user	사용자 권한 획득 시도	high
inappropriate-content	부적절한 컨텐츠 감지	high
policy-violation	잠재적인 개인 정보 침해	high
shellcode-detect	실행 코드 감지	high
successful-admin	관리자 권한 획득 성공	high
successful-user	사용자 권한 획득 성공	high
trojan-activity	네트워크 트로이목마 탐지	high
unsuccessful-user	사용자 권한 획득 실패	high
web-application-attack	웹 응용 프로그램 공격	high
attempted-dos	DoS 시도	medium
attempted-recon	정보 유출 시도	medium
bad-unknown	잠재적인 나쁜 트래픽	medium
default-login-attempt	기본 사용자 이름과 암호로 로그인 시도	medium
denial-of-service	DoS 탐지	medium
misc-attack	기타 공격	medium
non-standard-protocol	비표준 프로토콜 또는 이벤트 감지	medium
rpc-portmap-decode	RPC 쿼리 디코드	medium
successful-dos	DoS	medium
successful-recon-largescale	대규모 정보 유출	medium
successful-recon-limited	정보 유출	medium
suspicious-filename-detect	의심스러운 파일 이름 탐지	medium
suspicious-login	의심스러운 사용자 이름을 사용하여 로그인 시도 탐지	medium
system-call-detect	시스템 호출 탐지	medium
unusual-client-port-connection	클라이언트가 비정상적인 포트 사용	medium
web-application-activity	잠재적으로 취약한 웹 응용 프로그램에 대한 액세스	medium
icmp-event	일반적인 ICMP 이벤트	low
misc-activity	기타 활동	low
network-scan	네트워크 스캔 탐지	low
not-suspicious	의심스러운 트래픽 아님	low
protocol-command-decode	일반 프로토콜 명령어 디코드	low
string-detect	의심스러운 문자열 탐지	low
unknown	알 수 없는 트래픽	low
tcp-connection	TCP 연결 탐지	very low

 

classtype 옵션은 구성 분류 옵션(config classification option)을 이용한 snort.conf 에 정의된 분류만 사용할 수 있음.

Snort 는 classification.config 파일에서 제공하는 규칙에 따라 사용되는 기본 분류 집합을 제공함.

 

 

4.7 priority

 

priority 키워드는 규칙에 심각도 레벨을 지정함.

classtype 키워드는 구성 분류 옵션(config classification option)에 의해 정의된 기본적인 우선순위를 할당함.

각 경우의 예는 아래와 같음.

 

priority:<priority integer>;

< 형식 >

 

alert tcp any any -> any 80 (msg:"WEB-MISC phf attempt"; flags:A+; content:"/cgi-bin/phf"; priority:10;)   alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; dsize:>128; classtype:attempted-admin; priority:10 );

< 사용예 >

 

 

4.8 metadata

 

metadata 키워드를 사용하면 규칙 작성자가 규칙에 대한 추가 정보를 일반적으로 키-값 형식으로 포함시킬 수 잇음.

특정 메타데이터 키와 값은 Snort 에 의미가 있으며 아래 표에 나열되어 있음.

 

키	설명	값 형식
engine	공유 라이브러리 규칙 표시	"shared"
soid	공유 라이브러리 규칙 생성기 및 SID	gid|sid
service	목표 기반 서비스 식별자 (service 메타데이터 키는 호스트 속성 테이블이 제공될 때만 의미가 있음)	"http"

< Snort Metadata Keys >

 

표에 나열된 것 이외의 키는 Snort 에서 효과적으로 무시되며 키와 값을 사용하여 자유 형식이 될 수 있음.

여러 키는 쉼표로 구분되며 키와 값은 공백으로 구분됨.

 

metadata:key1 value1; metadata:key1 value1, key2 value2;

< 형식 >

 

아래 예제는 공유 라이브러리 규칙에서 스텁(stub) 규칙을 보여줌.

첫 번째 예제는 여러 metadata 키워드를 사용하고 두 번째 예제는 단일 metadata 키워드를 사용하며 키는 쉼표로 구분됨.

 

alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; metadata:engine shared; metadata:soid 3|12345;) alert tcp any any -> any 80 (msg:"Shared Library Rule Example"; metadata:engine shared, soid 3|12345;) alert tcp any any -> any 80 (msg:"HTTP Service Rule Example"; metadata:service http;)

< 사용예 >

 

 

4.9 General Rule Quick Reference

 

키워드	설명
msg	msg 키워드는 로깅 및 경고 엔진에 패킷 덤프 또는 경고와 함께 인쇄할 메시지를 알려줌.
reference	reference 키워드를 사용하면 규칙에 대해서 외부 공격 식별 시스템에 대한 참조를 포함할 수 있음.
gid	gid 키워드(generator id)는 특정 규칙이 발생할 때 Snort 가 어떤 이벤트를 생성하는 지 식별하는데 사용됨.
sid	sid 키워드는 Snort 규칙을 고유하게 식별하는 데 사용됨.
rev	rev 키워드는 Snort 규칙의 수정 버전을 고유하게 식별하는 데 사용됨.
classtype	classtype 키워드는 규칙에 대한 공격 범주화하는데 사용함.
priority	priority 키워드는 규칙에 심각도 레벨을 지정함.
metadata	metadata 키워드를 사용하면 규칙 작성자가 규칙에 대한 추가 정보를 일반적으로 키-값 형식으로 포함시킬 수 잇음.

< General 규칙 옵션 키워드 >

 

 

 

( 5 ) Payload 감지 규칙 옵션

 

 

5.1 content

 

content 키워드는 Snort 의 중요한 기능 중 하나임.

이를 통해 사용자는 패킷 페이로드의 특정 컨텐츠를 검색하고 해당 데이터를 기반으로 응답을 트리거하는 규칙을 설정할 수 있음.

content 옵션 패턴 매치가 수행될 때마다 Boyer-Moore 패턴 매치 함수가 호출되고 패킷 내용에 대해 테스트가 수행됨.

인수 데이터 문자열과 정확히 일치하는 데이터가 패킷 페이로드의 모든 위치에 포함되어 있으면 테스트가 성공하고 나머지 규칙 옵션 테스트가 수행됨.

이 테스트는 대소문자를 구분함.

 

content 키워드에 대한 옵션 데이터는 다소 복잡함. 혼합 텍스트 및 바이너리 데이터를 포함할 수 있음.

바이너리 데이터는 일반적으로 파이프(|) 문자로 묶여 있으며 바이트 코드로 표시됨.

바이트 코드는 16진수로 바이너리 데이터를 나타내고 복잡한 바이너리 데이터를 설명하기 위한 좋은 축약 방법임.

아래 예제는 Snort 규칙에서 혼합 텍스트와 바이너리 데이터의 사용을 보여줌.

 

하나의 규칙에 여러 content 규칙을 지정할 수 있음.

따라서 규칙을 잘못 판정하지 않도록 조정할 수 있음.

 

규칙 앞에 ! 문자열이 있을 경우 content 가 포함되지 않은 패킷에 대해 경고를 트리거됨.

이는 특정 패턴과 일치하지 않는 패킷에 대해 경고를 보내려는 규칙을 작성할 때 유용함.

 

참고로 다음 문자는 contnet 규칙 내에서 이스케이프 처리해야 함.

;\”

 

content:[!]"<content string>";

< 형식 >

 

alert tcp any any -> any 139 (content:"|5c 00|P|00|I|00|P|00|E|00 5c|";)   alert tcp any any -> any 80 (content:!"GET";)

< 사용예 >

 

! 수정자(modifier)는 해당 수정자가 포함된 전체 내용 검색 결과를 무효화함.

예를 들어 content:!"A"; within:50; 규칙일 경우 페이로드가 5바이트 뿐이며 해당 5 바이트에 “A” 가 없으면 결과는 일치로 리턴함.

유효한 일치를 위해 50 바이트가 있어야 하는 경우 isdataat 을 내용의 선행자(pre-cursor)로 사용해야 함.

 

content 키워드에는 여러 수정자(modifier) 키워드가 있음.

수정자(modifier) 키워드는 이전에 지정된 내용이 어떻게 작동하는지를 변경함.

수정자(modifier) 키워드는 다음과 같음.

 

수정자	섹션
nocase	5.5
rawbytes	5.6
depth	5.7
offset	5.8
distance	5.9
within	5.10
http_client_body	5.11
http_cookie	5.12
http_raw_cookie	5.13
http_header	5.14
http_raw_header	5.15
http_method	5.16
http_uri	5.17
http_raw_uri	5.18
http_stat_code	5.19
http_stat_msg	5.20
fast_pattern	5.22

< content 수정자(modifiers) >

 

 

5.2 protected_content

 

protected_content 키워드는 content 키워드의 많은 기능을 제공하지만 매우 다른 방식으로 수행되고 활용됨.

protected_content 키워드가 content 키워드에 비해 갖는 주요 이점은 보안 해시 다이제스트만 공개함으로써 지정된 컨텐츠를 숨길 수 있다는 것임.

content 키워드와 마찬가지로 주요 목적은 특정 바이트의 문자열을 일치시키는 것임.

들어오는 패킷의 일부를 해싱한 결과값과 지정된 해시값을 비교하여 검색을 수행하므로 계산 비용이 많이 듬.

 

현재는 protected_content 키워드로 MD5, SHA256, SHA512 해시 알고리즘을 사용할 수 있음

Snort 설정에서 기본값을 설정하지 않은 경우 해시를 사용하여 규칙에 해시 알고리즘을 지정해야 함.

또한, 원시 데이터의 길이를 나태내기 위해 length 수정자(modifier)를 이용해서 사용해야 함.

 

content 키워드와 마찬가지로 여러 protected_content 규칙을 하나의 규칙으로 사용할 수 있음.

또한, 여러 protected_content  규칙을 여러 protected_content 규칙과 혼합할 수 있음.

 

규칙 앞에 ! 가 있으면 대상 콘텐츠가 포함되지 않은 패킷에 대해 경고(alert)를 트리거함.

이는 특정 패턴과 일치하지 않는 패킷에 대해 경고(alert)하려는 규칙을 작성할 때 유용함.

 

Protected_content 키워드는 일부 content 수정자(modifiers)와 함께 사용할 수 있으나 지원되지 않는 것들은 아래와 같음:

nocase

fast_pattern

depth

within

 

protected_content:[!]"<content hash>", length:orig_len[, hash:md5|sha256|sha512];

< 형식 >

 

"HTTP" 문자열에 대한 다음 경고(alert) :   alert tcp any any <> any 80 (msg:"MD5 Alert"; protected_content:"293C9EA246FF9985DC6F62A650F78986"; hash:md5; offset:0; length:4;) alert tcp any any <> any 80 (msg:"SHA256 Alert"; protected_content:"56D6F32151AD8474F40D7B939C2161EE2BBF10023F4AF1DBB3E13260EBDC6342"; hash:sha256; offset:0; length:4;)

< 사용예 >

 

! 수정자(modifier)는 해당 수정자가 포함된 전체 내용 검색 결과를 무효화함.

예를 들어 content:!"A"; within:50; 규칙일 경우 페이로드가 5 바이트 뿐이며 해당 5 바이트에 “A” 가 없으면 결과는 일치로 리턴함.

유효한 일치를 위해 50 바이트가 있어야 하는 경우 isdataat 을 내용의 선행자(pre-cursor)로 사용해야 함.

 

 

5.3 hash

 

hash 키워드는 protected_content 규칙과 일치할 때 사용할 해싱 알고리즘을 지정하는 데 사용됨.

Snort 설정에 기본 알고리즘이 지정되지 않은 경우 protected_content 규칙에 반드시 사용할 알고리즘을 지정해야 함.

현재 MD5, SHA256, SHA512가 지원됨.

 

hash:[md5|sha256|sha512];

< 형식 >

 

5.4 length

 

length 키워드는 protected_content 규칙 요약(digest)에 지정된 컨텐츠의 원래 길이를 지정하는데 사용됨. 제공된 값은 0보다 크도 65536보다 작아야 함.

 

length:[<original_length>];

< 형식 >

 

 

5.5 nocase

 

nocase 키워드를 사용하면 규칙 작성기(rule writer)가 Snort에서 대소문자를 무시하고 특정 패턴을 찾도록 지정할 수 있음. nocase 는 규칙에서 이전 content 키워드를 수정함.

 

nocase;

< 형식 >

 

alert tcp any any -> any 21 (msg:"FTP ROOT"; content:"USER root"; nocase;)

< 사용예 >

 

 

5.6 rawbytes

 

rawbytes 키워드를 사용하면 규칙이 원시 패킷 데이터를 보고 전처리기(preprocessors)에 의해 수행된 디코딩을 무시함. 이는 content 키워드 옵션의 수정자(modifier) 역할을 함.

 

HTTP Inspect 는 원시 HTTP 요청 및 응답의 특정 부분과 일치하는 http_raw_cookie, http_raw_header, http_raw_uri 등과 같은 원시 데이터를 사용하기 위한 키워드 세트가 있음.

 

rawbytes 가 명시적으로 지정되지 않은 경우 대부분의 다른 전처리기는 기본적으로 컨텐츠 일치를 위해 디코딩/정규화된 데이터를 사용함. 따라서 패킷에서 임의의 원시 데이터를 검사하려면 rawbytes 를 지정해야 함.

 

rawbytes;

< 형식 >

 

이 예제는 컨텐츠 패턴 일치자(content patten matcher)에게 Telnet 디코더가 제공한 디코딩된 트래픽 대신 원시 트래픽을 보도록 지시함. alert tcp any any -> any 21 (msg:"Telnet NOP"; content:"|FF F1|"; rawbytes;)

< 사용예 >

 

 

5.7 depth

 

depth 키워드를 사용하면 규칙 작성자(rule writer)가 지정된 패턴을 검색해야 하는 거리를 지정할 수 있음.

예를 들어 "depth:5;" 는 페이로드의 처음 5 바이트 내에서만 지정된 패턴을 찾도록 지시함.

depth 키워드는 이전 content 키워드에 대한 수정자이므로 depth 키워드를 지정하기 전에 content 키워드가 있어야 함.

이 키워드는 검색되는 패턴 길이보다 크거나 같은 값을 허용하며 허용 범위는 1 ~ 65535 임.

동일한 규칙에서 byte extract 키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.

 

depth:[<number>|<var_name>];

< 형식 >

 

 

5.8 offset

 

offset 키워드를 사용하면 규칙 작성기(Rule Writer)가 패킷 내에서 패턴 검색을 시작할 위치를 지정할 수 있음.

예를 들어 "offset:5;" 는 페이로드의 처음 5 바이트 이후에 지정된 패턴을 찾도록 Snort 에 지시함.

offset 키워드는 이전 content 키워드에 대한 수정자이므로 offset 키워드를 지정하기 전에 content 키워드가 있어야 함.

해당 키워드의 값 허용 범위는 -65535 ~ 65535 임.

동일한 규칙에서 byte extract 키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.

 

offset:[<number>|<var_name>];

< 형식 >

 

다음 예제는 결합된 content, offset 및 depth 키워드를 사용하는 예제임.   alert tcp any any -> any 80 (content:"cgi-bin/phf"; offset:4; depth:20;)

< 사용예 >

 

 

5.9 distance

 

distance 키워드를 사용하면 규칙 작성자가 이전 패턴 일치의 끝을 기준으로 지정된 패턴 검색을 시작하기 전에 Snort 가 무시해야 하는 패킷의 거리를 지정할 수 있음.

이는 패킷의 시작이 아닌 마지막 패턴 일치의 끝과 관련이 있다는 점으로 offset 키워드와 정반대임.

해당 키워드의 값 허용 범위는 -65535 ~ 65535 임.

동일한 규칙에서 byte extract 키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.

 

distance:[<byte_count>|<var_name>];

< 형식 >

 

이 규칙은 /ABC.{1,}DEF/ 의 정규표현식과 매핑됨.   alert tcp any any -> any any (content:"ABC"; content:"DEF"; distance:1;)

< 사용예 >

 

 

5.10 within

 

within 키워드는 content 키워드를 사용하여 패턴 일치 사이에 최대 N 바이트가 되도록 하는 content 수정자임. (5.1 참조)

distance 키워드와 함께 규칙 옵션으로 사용하도록 설계됨.

해당 키워드는 검색되는 패턴 길이보다 크거나 같은 값을 허용하며 최대값은 63335 임.

동일한 규칙에서 byte extract 키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.

 

within:[<byte_count>|<var_name>];

< 형식 >

 

이 규칙은 ABC 일치한 후 10 바이트를 넘지 않도록 EFG 검색을 제한함.   alert tcp any any -> any any (content:"ABC"; content:"EFG"; within:10;)

< 사용예 >

 

 

5.11 http_client_body

 

http_client_body 키워드는 HTTP 클라이언트 요청의 본문으로 검색을 제한하는 content 수정자임.

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_client_body 키워드를 지정하기 전에 content 키워드가 있어야 함.

이 옵션으로 검사하는 데이터의 양은 HttpInspect 의 포스트 깊이 구성 옵션(post depth config option)에 따라 다름.

이 키워드를 사용한 패턴 일치는 포스트 깊이(post depth)가 -1 로 설정한 경우 작동하지 않음.

 

http_client_body;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 HTTP 클라이언트 요청의 본문으로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_client_body;)

< 사용예 >

 

노트 :

http_client_body 수정자는 동일한 content 에 대해 rawbytes 수정자와 함께 사용할 수 없음.

 

 

5.12 http_cookie

 

http_cookie 키워드는 HTTP 클라이언트 요청 또는 HTTP 서버 응답의 추출된 쿠키 헤더 필드(헤더 필드 이름 자체와 헤더 필드 행을 종료하는 CRLF 제외)로 검색을 제한하는 content 수정자임. (HttpInspect 구성에 따라)

쿠키 버퍼에는 헤더 필드 이름이나 선행 공백 및 헤더 필드 행을 종료하는 CRLF 가 포함되지 않음.

이는 HTTP 헤더 버퍼에 포함됨.

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_cookie 키워드를 지정하기 전에 content 키워드가 있어야 함.

이 키워드는 쿠키 사용 구성 옵션(enable cookie config option)에 따라 다름.

이 옵션이 구성된 경우에만 쿠키 헤더 필드가 추출됨.

쿠키 사용이 지정되지 않은 경우에도 쿠기는 HTTP 헤더로 끝남.

쿠키 사용이 지정되지 않은 경우 HTTP 쿠키 사용은 HTTP 헤더 사용과 동일함.

추출된 쿠키 헤더 필드는 HttpInspect 구성에 따라 NORMALIZED 일 수 있음.

 

http_cookie;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 HTTP 클라이언트 요청의 추출된 쿠키 헤더 필드로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_cookie;)

< 사용예 >

 

노트 :

http_cookie 수정자는 동일한 content 에 대해 rawbytes 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.13 http_raw_cookie

 

http_raw_cookie 키워드는 HTTP 클라이언트 또는 HTTP 서버 응답의 추출된 비정규화(UNNORMALIZED) 쿠키 헤더 필드로 검색을 제한하는 content 수정자임. (HttpInspect 구성에 따라)

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_raw_cookie 키워드를 지정하기 전에 content 키워드가 있어야 함.

이 키워드는 쿠키 사용 구성 옵션(enable cookie config option)에 따라 다름.

이 옵션이 구성된 경우에만 쿠키 헤더 필드가 추출됨.

 

http_raw_cookie;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 HTTP 클라이언트 요청의 추출된 비정규화(Unnormalized) 쿠키 헤더 필드로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_raw_cookie;)

< 사용예 >

 

노트 :

http_raw_cookie 수정자는 동일한 content 에 대해 rawbytes, http_cookie 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.14 http_header

 

http_header 키워드는 HTTP 클라이언트 요청 또는 HTTP 서버 응답의 추출된 헤더 필드로 검색을 제한하는 content 수정자임. (HttpInspect 구성에 따라)

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_header 키워드를 지정하기 전에 content 키워드가 있어야 함.

추출된 헤더 필드는 HttpInspect 구성에 따라 NORMALIZED 일 수 있음.

 

http_header;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 HTTP 클라이언트 요청 또는 HTTP 서버 응답의 추출된 헤더 필드로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_header;)

< 사용예 >

 

노트 :

http_header 수정자는 동일한 content 에 대해 rawbytes 수정자와 함께 사용할 수 없음.

 

 

5.15 http_raw_header

 

http_raw_header 키워드는 HTTP 클라이언트 또는 HTTP 서버 응답의 추출된 비정규화(UNNORMALIZED) 헤더 필드로 검색을 제한하는 content 수정자임. (HttpInspect 구성에 따라)

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_raw_header 키워드를 지정하기 전에 content 키워드가 있어야 함.

 

http_raw_header;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 HTTP 클라이언트 요청 또는 HTTP 서버 응답의 추출된 비정규화(Unnormalized) 헤더 필드로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_raw_header;)

< 사용예 >

 

노트 :

http_raw_header 수정자는 동일한 content 에 대해 rawbytes, http_header 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.16 http_method

 

http_method 키워드는 HTTP 클라이언트 요청에서 추출된 Method 로 검색을 제한하는 content 수정자임.

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_method 키워드를 지정하기 전에 content 키워드가 있어야 함.

 

http_method;

< 형식 >

 

이 규칙은 "GET" 패턴 검색을 HTTP 클라이언트 요청에서 추출된 메소드로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"GET"; http_method;)

< 사용예 >

 

노트 :

http_method 수정자는 동일한 content 에 대해 rawbytes 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.17 http_uri

 

http_uri 키워드는 정규화(NORMALIZED) 요청 URI 필드로 검색을 제한하는 content 수정자임.

content 규칙 옵션 다음에 http_uri 수정자를 사용하는 것은 uricontent 키워드를 사용하는 것과 같음. (5.23 참조)

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_uri 키워드를 지정하기 전에 content 키워드가 있어야 함.

 

http_uri;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 정규화(NORMALIZED) URI 로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_uri;)

< 사용예 >

 

노트 :

http_uri 수정자는 동일한 content 에 대해 rawbytes 수정자와 함께 사용할 수 없음.

 

 

5.18 http_raw_uri

 

http_raw_uri 키워드는 비정규화(UNNORMALIZED) 요청 URI 필드로 검색을 제한하는 content 수정자임.

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_raw_uri 키워드를 지정하기 전에 content 키워드가 있어야 함.

 

http_raw_uri;

< 형식 >

 

이 규칙은 "EFG" 패턴 검색을 비정규화(UNNORMALIZED) URI 로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_raw_uri;)

< 사용예 >

 

노트 :

http_raw_uri 수정자는 동일한 content 에 대해 rawbytes, http_uri 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.19 http_stat_code

 

http_stat_code 키워드는 HTTP 서버 응답에서 추출된 상태 코드 필드로 검색을 제한하는 content 수정자임.

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_stat_code 키워드를 지정하기 전에 content 키워드가 있어야 함.

상태 코드 필드는 확장 응답 검사가 HttpInspect 에 대해 구성된 경우에만 추출됨.

 

http_stat_code;

< 형식 >

 

이 규칙은 "200" 패턴에 대한 검색을 HTTP 서버 응답의 추출된 상태 코드 필드로 제한함. alert tcp any 80 -> any any (content:"ABC"; content:"200"; http_stat_code;)

< 사용예 >

 

노트 :

http_stat_code 수정자는 동일한 content 에 대해 rawbytes 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.20 http_stat_msg

 

http_stat_msg 키워드는 HTTP 서버 응답에서 추출된 상태 메시지 필드로 검색을 제한하는 content 수정자임.

이 키워드는 이전 content 키워드에 대한 수정자이므로 http_stat_msg 키워드를 지정하기 전에 content 키워드가 있어야 함.

상태 메시지 필드는 확장 응답 검사가 HttpInspect 에 대해 구성된 경우에만 추출됨.

 

http_stat_msg;

< 형식 >

 

이 규칙은 "Not Found" 패턴 검색을 HTTP 서버 응답의 추출된 상태 메시지 필드로 제한함. alert tcp any any -> any 80 (content:"ABC"; content:"Not Found"; http_stat_msg;)

< 사용예 >

 

노트 :

http_stat_msg 수정자는 동일한 content 에 대해 rawbytes 또는 fast_pattern 수정자와 함께 사용할 수 없음.

 

 

5.21 http_encode

 

http_encode 키워드는 HTTP 클라이언트 요청 또는 HTTP 서버 응답에 있는 인코딩 유형을 기반으로 경고를 활성화함.

HTTP 인코딩과 관련된 여러 키워드가 있음.

키워드 'uri', 'header' 및 'cookie' 는 특정 인코딩 유형을 검색하는 데 사용되는 HTTP 필드를 결정함.

키워드 'utf8', 'double encode', 'non ascii', 'uencode', 'iis encode', 'ascii' 및 'bare byte' 는 경고를 트리거하는 인코딩 유형을 결정함.

이러한 키워드는 OR 연산을 사용하여 결합할 수 있으며 제외도 허용됨.

규칙이 키워드 'header' 와 함께 작동하려면 구성 옵션 '헤더 정규화(normalize header)'를 설정해야 함.

키워드 'cookie' 는 '쿠키 사용(enable cookie)' 및 '쿠키 정규화(normalize cookies)' 옵션에 따라 다름.

이 규칙 옵션은 지정된 HTTP 필드가 정규화(NORMALIZED)가 아닌 경우 인코딩을 감지할 수 없음.

 

옵션	설명
uri	HTTP 클라이언트 요청 URI 필드에서 지정된 인코딩 유형을 확인함.
header	HTTP 요청 또는 HTTP 응답 헤더 필드에서 지정된 인코딩 유형을 확인함. (패킷의 흐름에 따라 다름)
cookie	HTTP 요청 또는 HTTP 응답 쿠키 헤더 필드에서 지정된 인코딩 유형을 확인함. (패킷의 흐름에 따라 다름)
utf8	지정된 버퍼에서 utf8 인코딩을 확인함.
double_encode	지정된 버퍼에서 이중 인코딩(double encoding)을 확인함.
non_ascii	지정된 버퍼에서 비 ASCII 인코딩(non-ASCII encoding)을 확인함.
uencode	지정된 버퍼에서 u 인코딩(u-encoding)을 확인함.
bare_byte	지정된 버퍼에서 bare 바이트 인코딩(bare byte encoding)을 확인함.
ascii	지정된 버퍼에서 ASCII 인코딩을 확인함.
iis_encode	지정된 버퍼에서 IIS 유니코드 인코딩을 확인함.

 

http_encode:<http buffer type>, [!]<encoding type> http_encode:[uri|header|cookie], [!][<utf8|double_encode|non_ascii|uencode|bare_byte|ascii|iis_encode>];

< 형식 >

 

alert tcp any any -> any any (msg:"UTF8/UEncode Encoding present"; http_encode:uri,utf8|uencode;) alert tcp any any -> any any (msg:"No UTF8"; http_encode:uri,!utf8;)

< 사용예 >

 

 

5.22 fast_pattern

 

fast_pattern 키워드는 빠른 패턴 일치자(matcher)와 함께 사용할 규칙 내의 컨텐츠를 설정하는 content 수정자임.

빠른 패턴 결정의 기본 동작은 가장 긴 HTTP 버퍼 컨텐츠를 사용하는 것임.

HTTP 버퍼가 없으면 빠른 패턴이 가장 긴 컨텐츠임.

이 동작이 주어지면 짧은 컨텐츠가 긴 컨텐츠보다 "고유한" 경우 유효함.

즉, 더 짧은 컨텐츠가 긴 컨텐츠보다 패킷에서 발견될 가능성이 적음.

 

빠른 패턴 일치자(matcher)는 선택을 위해 규칙의 컨텐츠를 사용하고 컨텐츠가 페이로드에서 발경되는 경우에만 해당 규칙을 평가하여 일치 가능성이 있는 규칙만 선택하는데 사용됨.

이는 오버헤드로 보일 수 있지만 평가해야 하는 규칙 수를 크게 줄여 성능을 향상시킬 수 있음.

빠른 패턴 일치자(matcher)에 사용되는 컨텐츠가 좋을수록 규칙이 불필요하게 평가될 가능성이 줄어듬.

 

이 키워드는 이전 content 키워드에 대한 수정자이므로 fast_pattern 을 지정하기 전에 규칙에 content 규칙 옵션이 있어야 함.

fast_pattern 옵션은 규칙당 한 번만 지정할 수 있음.

 

노트 :

fast_pattern 수정자는 다음 http 컨텐츠 수정자와 함께 사용할 수 없음. (http_cookie, http_raw_uri, http_raw_header, http_raw_cookie, http_method, http_stat_code, http_stat_msg)

fast_pattern 수정자는 해당 내용이 offset, depth, distance 및 within 내에서 수정되지 않은 경우에만 부정된(negated) 컨텐츠과 함께 사용할 수 있음.

빠른 패턴 일치자(matcher)는 항상 대소문자를 구분하지 않음.

 

fast_pattern 옵션은 단독으로 사용하거나 선택적으로 인수를 사용할 수 있음. 단독으로 사용하는 경우 단순히 지정된 컨텐츠를 규칙의 빠른 패턴 컨텐츠로 사용한다는 의미임. fast_pattern; 선택적 인수는 컨텐츠가 빠른 패턴 일치자(matcher)에만 사용되어야 하며 규칙 옵션으로 평가되지 않도록 지정하는 데만 사용할 수 있음. 예를 들어, 알려진 컨텐츠가 페이로드의 위치와 관계없이 페이로드에 있어야 하는 경우에 유용함. 규칙 옵션을 평가하는 데 필요한 시간을 절약하기 때문임. 1. 패턴이 대소문자를 구분하지 않는 방식으로 패턴 일치자(matcher)에 삽입되므로 수정된 컨텐츠는 대소문자를 구분하지 않아야 함. 2. 부정된(negated) 컨텐츠는 사용할 수 없음. 3. 컨텐츠에는 offset, depth, distance 또는 within 와 같은 위치 수정자가 있을 수 없음. fast_pattern:only; 선택적 인수 <offset>, <length> 를 사용하여 컨텐츠의 일부만 빠른 패턴 일치자(matcher)에 사용되도록 지정할 수 있음. 이는 패턴이 매우 길고 "고유성"을 충족시키기 위해 패턴의 일부만 필요한 경우에 유용하므로 빠른 패턴 일치자(matcher)에 전체 패턴을 저장하는 데 필요한 메모리가 줄어듬. fast_pattern:<offset>,<length>;

< 형식 >

 

노트 :

선택적 인수 <offset>, <length> 는 상호 배타적임.

 

이 규칙은 "IJKLMNO" 패턴이 이전 패턴 "ABCDEFGH" 보다 짧더라도 fast_pattern 일치자와 함께 사용되도록 함. alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern;) 이 규칙은 fast_pattern 일치자에 content:"IJKLMNO"; 를 사용하고 content가 fast_pattern 일치자만 사용되어야 하며 content 규칙 옵션으로 평가되지 않아야 함. alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; nocase; fast_pattern:only;) 이 규칙은 "JKLMN" 을 fast_pattern content 로 사용하지만 content 규칙 옵션을 “IJKLMNO” 로 평가함. alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern:1,5;)

< 사용예 >

 

 

5.23 uricontent

 

Snort 규칙 언어의 uricontent 키워드는 정규화(NORMALIZED) 요청 URI 필드를 검색함.

이는 content 키워드에 http_uri 수정자를 사용하는 것과 같음.

따라서 %2f 또는 Directory Traversal 기법과 같이 정규화된 항목을 포함하는 규칙을 작성하는 경우 이러한 규칙은 경고하지 않음.

그 이유는 찾고 있는 항목이 정규화된 URI 버퍼에서 찾기 때문임.

 

예를 들어, URI :

/scripts/..%c0%af../winnt/system32/cmd.exe?/c+ver

 

다음으로 정규화됨 :

/winnt/system32/cmd.exe?/c+ver

 

또 다른 예, URI :

bin/aaaaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f?

 

다음으로 정규화됨 :

/cgi-bin/phf?

 

uricontent 규칙을 작성할 때 URI 가 정규화될 문자열(context)에서 찾을려는 content 를 작성해야 함.

예를 들어 Snort 가 Directory Traversal 기법을 정규화하는 경우 Directory Traversal 기법을 포함하지 말 것!

content 옵션을 사용하여 정규화되지 않은 컨텐츠를 찾는 규칙을 작성할 수 있음. (5.1 섹션 참조)

uricontent 는 content 키워드에 사용할 수 있는 여러 수정자와 함께 사용할 수 있음.

여기에는 다음이 포함되며 이 옵션은 HTTP 검사 전처리기(HTTP Inspect preprocessor)와 함께 작동함.

 

수정자	섹션
nocase	5.5
depth	5.7
offset	5.8
distance	5.9
within	5.10
fast_pattern	5.22

< uricontent 수정자 >

 

uricontent:[!]"<content string>";

< 형식 >

 

노트 :

uricontent 는 rawbytes 수정자 또는 다른 HTTP 수정자로 수정할 수 없음.

비정규화(UNNORMALIZED) 요청 URI 필드를 검색하려면 content 옵션과 함께 http_raw_uri 수정자를 사용해야 함.

 

 

5.24 urilen

 

Snort 규칙 언어의 urilen 키워드는 일치시킬 URI 길이의 정확한 길이, 최소 길이, 최대 길이 또는 범위를 지정함.

기본적으로 원시 URI 버퍼가 사용됨.

선택적 <uribuf> 인수를 사용하면 원시 또는 정규화된 버퍼를 사용할 지 여부를 지정할 수 있음.

 

urilen:min<>max[,<uribuf>]; urilen:[<|>]<number>[,<uribuf>]; <uribuf> : "norm" | "raw"

< 형식 >

 

다음 예는 길이가 5 바이트인 URI 와 일치함.

urilen:5;

 

다음 예는 5 바이트보다 짧은 URI 와 일치함.

urilen:<5;

 

다음 예는 5 바이트보다 크고 10 바이트(포함)보다 작은 URI 와 일치함.

urilen:5<>10;

 

다음 예는 정규화된 URI 버퍼를 사용하여 500 바이트보다 큰 URI 를 일치시킴.

urilen:>500,norm;

 

다음 예는 원시 URI 버퍼를 사용하도록 명시적으로 나타내는 500 바이트보다 큰 URI 와 일치함.

urilen:>500,row;

 

이 옵션은 HTTP 감사 전처리기(HTTP Inspect preprocessor)와 함께 작동함.

 

 

5.25 isdataat

 

페이로드의 지정된 위치에 데이터가 있는지 확인하고 선택적으로 이전의 컨텐츠 끝과 관련된 데이터를 찾음.

 

isdataat:[!]<int>[, relative|rawbytes];

< 형식 >

 

이 규칙은 패킷에 PASS 문자열이 있는지 확인한 다음 문자열 PASS 가 끝난 후 50 바이트 이상이 있는지 확인함. 그런 다음 PASS 문자열 끝의 50 바이트 내에 개행 문자가 없는지 확인함. alert tcp any any -> any 111 (content:"PASS"; isdataat:50,relative; \ content:!"|0a|"; within:50;)

< 사용예 >

 

rawbytes 수정자가 isdataat 와 함께 지정되면 원시 패킷 데이터를 살펴보고 전처리기가 수행한 모든 디코딩을 무시함.

이 수정자는 이전 컨텐츠 일치가 원시 패킷 데이터에 있는 한 relative 수정자와 함께 작동함.

! 수정자는 isdataat 테스트의 결과를 무효화함.

페이로드 내에 특정 양의 데이터가 없으면 경고함.

예를 들어 수정자 컨텐츠가 있는 규칙은 다음과 같음.

"foo"; isdataat:!10,relative; 는 페이로드가 끝나기 전에 “foo” 뒤에 10 바이트가 없으면 경고함.

 

 

5.26 pcre

 

pcre 키워드를 사용하면 perl 호환 정규식을 사용하여 규칙을 작성할 수 있음.

무엇을 할 수 있는지에 대한 자세한 내용은 PCRE 웹사이트(http://www.pcre.org)를 확인하십시오.

 

pcre:[!]"(/<regex>/|m<delim><regex><delim>)[ismxAEGRUBPHMCOIDKYS]";

< 형식 >

 

post-re 수정자는 정규식에 대한 컴파일 시간 플래그를 설정함.

 

Perl 호환 수정자	설명
i	대소문자를 구분하지 않음.
s	점 메타 문자(.)에 줄바꿈 포함.
m	기본적으로 문자열은 하나의 큰 문자 줄로 처리됨. ^ 및 $ 는 문자열의 시작과 끝으로 일치함. m 이 설정되면 ^ 및 $ 는 버퍼의 모든 개행 바로 뒤 또는 바로 앞과 버퍼의 맨 처음과 맨 끝을 일치함.
x	패턴의 공백 데이터 문자는 이스케이프되거나 문자 클래스 내부의 경우를 제외하고 무시됨.
A	패턴은 버퍼의 시작 부분에서만 일치해야 함. (^ 와 동일)
E	제목 문자열의 끝에서만 일치하도록 $ 를 설정하십시오. E 가 없으면 $ 는 개행 문자인 경우 최종 문자 바로 앞과도 일치함. (다른 개행 앞이 아님)
G	한정자(quantifier)의 “탐욕”(greediness)을 반전하여 기본적으로 탐욕스럽지(greedy) 않지만 “?” 가 뒤따르면 탐욕스러워짐.
R	마지막 패턴 일치의 끝을 기준으로 일치함. (distance:0; 과 유사)
U	디코딩된 URI 버퍼를 일치시킴. (uricontent 및 http_uri 와 비슷) 이 수정자는 동일한 컨텐츠에 대해 정규화되지 않은 HTTP 요청 uri 버퍼 수정자(I)와 함께 사용할 수 없음.
I	정규화되지 않은 HTTP 요청 uri 버퍼와 일치함. (http_raw_uri 와 유사) 이 수정자는 동일한 컨텐츠에 대해 HTTP 요청 uri 버퍼 수정자(U)와 함께 사용할 수 없음.
P	정규화되지 않은 HTTP 요청 본문과 일치함. (http_client_body 와 유사) SIP 메시지의 경우 요청 또는 응답에 대해 SIP 본문을 일치시킴. (sip_body 와 유사)
H	정규화된 HTTP 요청 또는 HTTP 응답 헤더와 일치함. (http_header 와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화되지 않은 HTTP 요청 또는 HTTP 응답 헤더 수정자(D)와 함께 사용할 수 없음. SIP 메시지의 경우 요청 또는 응답에 대해 SIP 헤더를 일치시킴. (sip_header 와 유사)
D	정규화되지 않은 HTTP 요청 또는 HTTP 응답 헤더와 일치함. (http_raw_header 와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화된 HTTP 요청 또는 HTTP 응답 헤더 수정자(H)와 함께 사용할 수 없음.
M	정규화된 HTTP 요청 방법과 일치함. (http_method 와 유사)
C	정규화된 HTTP 요청 또는 HTTP 응답 쿠키와 일치함. (http_cookie 와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화되지 않은 HTTP 요청 또는 HTTP 응답 쿠키 수정자(K)와 함께 사용할 수 없음.
K	정규화되지 않은 HTTP 요청 또는 HTTP 응답 쿠키와 일치함. (http_raw_cookie 와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화된 HTTP 요청 또는 HTTP 응답 쿠키 수정자(C)와 함께 사용할 수 없음.
S	HTTP 응답 상태 코드와 일치함. (http_stat_code 와 유사)
Y	HTTP 응답 상태 메시지와 일치함. (http_stat_msg 와 유사)
B	디코딩된 버퍼를 사용하지 마십시오. (rawbytes 와 유사)
O	이 표현식에 대해 구성된 pcre 일치 제한 및 pcre 일치 제한 재귀를 재정의함. 지정된 pcre 패턴을 평가하는 동안 제한을 완전히 무시함.

< pcre 용 Perl 호환 수정자 >

 

노트 :

수정자 R(상대) 과 B(원시 바이트)는 U, I, P, H, D, M, C, K, S 및 Y 와 같은 HTTP 수정자와 함께 허용되지 않음.

 

이 예제는 HTTP URI foo.php?id=<some numbers> 에 대해 대소문자를 구분하지 않는 검색을 수행함. alert tcp any any -> any 80 (content:"/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";)

< 사용예 >

 

노트 :

pcre 를 사용하는 규칙에 하나 이상의 content 키워드가 있는 것이 좋음.

이를 통해 fast_pattern 일치자가 일치하지 않는 패킷을 필터링하여 회선을 통해 들어오는 각 패킷에 대해 pcre 평가가 수행되지 않도록 할 수 있음.

 

노트 :

Snort 가 PCRE 를 사용하여 여러 URI 를 처리하는 것이 예상대로 작동하지 않음.

uricontent 없이 사용되는 PCRE 는 첫 번째 URI 만 평가함.

pcre 를 사용하여 모든 URI 를 검사하려면 content 또는 uricontent 를 사용해야 함.

 

 

5.27 pkt_data

 

이 옵션은 감지에 사용되는 커서(cursor)를 원시 전송 페이로드로 설정함.

규칙에서 pkt_data 뒤에 오는 상대 또는 절대 컨텐츠 일치(HTTP 수정자 또는 원시 바이트 없음) 및 기타 페이로드 감지 규칙 옵션은 커서(탐지에 사용)가 다시 설정될 때까지 원시 TCP/UDP 페이로드 또는 정규화된 버퍼(telnet, 정규화된 smtp 경우)에 적용됨.

이 규칙 옵션은 규칙에서 여러 번 사용할 수 있음.

 

pkt_data;

< 형식 >

 

alert tcp any any -> any any(msg:"Absolute Match"; pkt_data; content:"BLAH"; offset:0; depth:10;) alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; content:"foo"; within:10;) alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; content:"foo";) alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; pcre:"/foo/i";)

< 사용예 >

 

 

5.28 file_data

 

이 옵션은 감지에 사용되는 커서를 다음 버퍼 중 하나로 설정함.

 

1. 탐지되는 트래픽이 HTTP 일 때 버퍼를 설정함 :

  a. HTTP 응답 본문 (chunking/압축/정규화 제외)

  b. HTTP dechunked 응답 본문

  c. HTTP 압축해제 응답 본문 (inspect_gzip 이 켜져 있는 경우)

  d. HTTP 정규화된 응답 본문 (normalized_javascript 가 설정된 경우)

  e. HTTP UTF 정규화된 응답 본문 (normalized_utf 가 설정된 경우)

  f. 모두 포함(All of the obove)

 

2. 감지되는 트래픽이 SMTP/POP/IMAP 인 경우 버퍼를 다음으로 설정함 :

  a. SMTP/POP/IMAP 데이터 본문 (디코딩이 해제된 이메일 헤더 및 MIME 포함)

  b. Base64 디코딩된 MIME 첨부 파일 (b64_decode_depth 가 -1 보다 큰 경우)

  c. 인코딩되지 않은 MIME 첨부 파일 (bitenc_decode_depth 가 -1 보다 큰 경우)

  d. 인용 인쇄 가능한(Quoted-Printable) 디코딩된 MIME 첨부 파일 (qp_decde_depth 가 -1 보다 큰 경우)

  e. Unix-to-Unix 디코딩된 첨부 파일 (uu_decode_depth 가 -1 보다 큰 경우)

 

3. 1 과 2 번 항목으로 설정하지 않으면 페이로드로 설정됨.

 

상대 또는 절대 컨텐츠 일치(HTTP 수정자 또는 rawbytes 없음) 및 규칙에서 file_data 를 따르는 페이로드 감지 규칙 옵션은 다른 규칙 옵션에 의해 명시적으로 재설정될 때까지 이 버퍼에 적용됨.

이 규칙 옵션은 규칙에서 여러 번 사용할 수 있음.

file_data 에 대한 mime 인수는 더 이상 사용되지 않음.

규칙 옵션 file_data 는 자체적으로 디코딩된 MIME 첨부를 가리킴.

 

 

file_data;

< 형식 >

 

alert tcp any any -> any any(msg:"Absolute Match"; file_data; content:"BLAH"; offset:0; depth:10;) alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo"; within:10;) alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo";) alert tcp any any -> any any(msg:"FILE DATA"; file_data; pcre:"/foo/i";) 다음 규칙은 file_data 버퍼 내에서 컨텐츠 "foo" 를 검색하고 전체 패킷 페이로드 내에서 컨텐츠 "bar" 를 검색함. 규칙 옵션 pkt_data 는 탐지에 사용되는 커서를 TCP 페이로드로 재설정함. alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo"; pkt_data; content:"bar";)

< 사용예 >

 

 

5.29 base64_decode

 

이 옵션은 base64 로 인코딩된 데이터를 디코딩하는 데 사용됨.

이 옵션은 HTTP 인증 헤더와 같은 HTTP 헤더의 경우 특히 유용함.

이 옵션은 디코딩하기 전에 데이터를 펼침.

 

base64_decode[:[bytes <bytes_to_decode>][, ][offset <offset>[, relative]]];

< 형식 >

 

옵션	설명
bytes	디코딩할 base64 인코딩 바이트 수임. 이 인수는 양수 및 0 이 아닌 값만 사용함. 이 옵션을 지정하지 않으면 헤더 라인의 끝에 도달하거나 패킷 페이로드의 끝에 도달할 때까지 base64 로 인코딩된 데이터를 찾음.
offset	relative 옵션이 지정될 때 doe_ptr 에 상대적인 오프셋을 결정하거나 base64 인코딩 데이터의 검사를 시작하기 위해 패킷 페이로드의 시작에 상대적인 오프셋을 결정함. 이 인수는 양수 및 0 이 아닌 값만 사용함.
relative	base64 로 인코딩된 데이터에 대한 검사가 doe_ptr 에 상대적임을 지정함.

base64_decode 에 대한 위의 인수는 선택사항임.

 

노트 :

이 옵션은 HTTP 와 유사한 폴딩(folding)이 있는 프로토콜로 확장할 수 있음.

폴딩(folding)이 없으면 다음 공백이나 탭없이 캐리지 리턴이나 줄바꿈 또는 둘 다가 표시되면 base64 로 인코딩된 데이터 검색이 종료됨.

이 옵션은 다른 페이로드 감지 규칙 옵션이 base64 디코딩된 버퍼에서 작동하도록 base64_data 와 함께 사용해야 함.

 

alert tcp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"Base64 Encoded Data"; base64_decode; base64_data; \ content:"foo bar"; within:20;) alert tcp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"Authorization NTLM"; content:"Authorization: NTLM"; base64_decode:relative; base64_data; content:"NTLMSSP"; ) alert tcp any any -> any any (msg:"Authorization NTLM"; \ content:"Authorization:"; http_header; \ base64_decode:bytes 12, offset 6, relative; base64_data; \ content:"NTLMSSP"; within:8;)

< 사용예 >

 

 

5.30 base64_data

 

이 옵션은 file_date 규칙 옵션과 유사하며 감지에 사용되는 커서가 있는 경우 base64 디코딩된 버퍼의 시작 부분으로 설정하는 데 사용됨.

이 옵션은 인수를 사용하지 않음.

base64_data 옵션보다 먼저 base64_decode 규칙 옵션을 지정해야 함.

 

base64_data;

< 형식 >

 

이 옵션은 base64 디코딩된 버퍼가 있는 경우 일치함.

 

노트 :

이 버퍼에서는 빠른 패턴 컨텐츠(fast pattern content) 일치가 허용되지 않음.

 

alert tcp any any -> any any (msg:"Authorization NTLM"; \ content:"Authorization:"; http_header; \ base64_decode:bytes 12, offset 6, relative; base64_data; \ content:"NTLMSSP"; within:8;)

< 사용예 >

 

 

5.31 byte_test

 

특정 값(연산자 사용)에 대해 바이트 필드를 테스트함.

바이너리 값을 테스트하거나 대표 바이트 문자열을 해당 바이너리로 변환하고 테스트할 수 있음.

 

byte_test:<bytes to convert>, [!]<operator>, <value>, <offset> \ [, relative][, <endian>][, string, <number type>][, dce] \ [, bitmask <bitmask_value>]; bytes = 1 - 10 operator = ’<’ | ’=’ | ’>’ | ’<=’ | ’>=’ | ’&’ | ’ˆ’ value = 0 - 4294967295 offset = -65535 to 65535 bitmask_value = 1 to 4 byte hexadecimal value

< 형식 >

 

Perl 호환 수정자	설명
bytes_to_convert	패킷에서 가져올 바이트 수임. dce 없이 사용할 경우 허용되는 값은 1-10 임. dce 와 함께 사용하는 경우 허용되는 값은 1,2 및 4 임.
operator	값을 테스트하기 위해 수행할 작업 : • < - 미만 • > - 보다 큼 • <= - 작거나 같음 • >= - 크거나 같음 • = - 같음 • & - 비트 AND • ˆ - 비트 OR
value	변환된 값을 테스트할 값임.
offset	처리를 시작할 페이로드의 바이트 수임.
relative	마지막 패턴 일치에 상대적인 오프셋을 사용함.
endian	읽고 있는 번호의 엔디안 유형 : • big - 데이터를 빅 엔디안으로 처리 (기본값). • little - 데이터를 리틀 엔디안으로 처리
string	데이터는 패킷에 문자열 형식으로 저장됨.
number type	읽을 번호 유형 : • hex - 변환된 문자열 데이터가 16 진수로 표시됨. • dec - 변환된 문자열 데이터가 10 진수로 표시됨. • oct - 변환된 문자열 데이터가 8 진수로 표시됨.
dce	dce 는 DCE/RPC 2 전처리기가 변환할 값의 바이트 순서를 결정하도록 함.
bitmask	변환된 바이트에 AND 연산자를 적용함. 결과는 마스크의 후행 0 수와 동일한 비트 수만큼 오른쪽 시프트됨.

모든 연산자에 ! 연산자가 사실이 아닌지 확인함.

만약 ! 연산자없이 지정된 경우 연산자는 = 로 설정됨.

 

노트 :

Snort 는 이러한 각 연산자에 대해 C 연산자를 사용함.

& 연산자를 사용하면 if (data & value) { do something();} 을 사용하는 것과 같음.

 

alert udp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"AMD procedure 7 plog overflow"; \ content:"|00 04 93 F3|"; \ content:"|00 00 00 07|"; distance:4; within:4; \ byte_test:4, >, 1000, 20, relative;) alert tcp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"AMD procedure 7 plog overflow"; \ content:"|00 04 93 F3|"; \ content:"|00 00 00 07|"; distance:4; within:4; \ byte_test:4, >, 1000, 20, relative;) alert udp any any -> any 1234 \ (byte_test:4, =, 1234, 0, string, dec; \ msg:"got 1234!";) alert udp any any -> any 1235 \ (byte_test:3, =, 123, 0, string, dec; \ msg:"got 123!";) alert udp any any -> any 1236 \ (byte_test:2, =, 12, 0, string, dec; \ msg:"got 12!";) alert udp any any -> any 1237 \ (byte_test:10, =, 1234567890, 0, string, dec; \ msg:"got 1234567890!";) alert udp any any -> any 1238 \ (byte_test:8, =, 0xdeadbeef, 0, string, hex; \ msg:"got DEADBEEF!";) alert tcp any any -> any any \ (byte_test:2, =, 568, 0, bitmask 0x3FF0; \ msg:"got 568 after applying bitmask 0x3FF0 on 2 bytes extracted";)

< 사용예 >

 

 

5.23 byte_jump

 

byte_jump 키워드를 사용하면 길이 인코딩된 프로토콜에 대한 규칙을 간단하게 작성할 수 있음.

데이터 일부의 길이를 읽은 다음 패킷에서 훨씬 앞으로 건너 뛰는 옵션을 사용하면 길이 인코딩된 프로토콜의 특정 부분을 건너 뛰고 특정 위치에서 탐지를 수행하는 규칙을 작성할 수 있음.

byte_jump 옵션은 일부 바이트 수를 읽고 숫자 표현으로 변환하고 해당 바이트를 앞으로 이동하고 나중에 감지할 수 있도록 포인터를 설정하여 이를 수행함.

이 포인터는 오프셋 감지 끝 포인터 또는 doe_ptr 로 알려져 있음.

 

byte_jump:<bytes_to_convert>, <offset> [, relative][, multiplier <mult_value>] \ [, <endian>][, string, <number_type>][, align][, from_beginning][, from_end] \ [, post_offset <adjustment value>][, dce][, bitmask <bitmask_value>]; bytes = 1 - 10 offset = -65535 to 65535 mult_value = 0 - 65535 post_offset = -65535 to 65535 bitmask_value = 1 to 4 bytes hexadecimal value

< 형식 >

 

옵션	설명
bytes_to_convert	패킷에서 가져올 바이트 수임. dce 없이 사용할 경우 허용되는 값은 1-10 임. dce 와 함께 사용하는 경우 허용되는 값은 1, 2 및 4 임. from_end 인수와 함께 사용하면 bytes_to_convert 는 0 이 될 수 있음. bytes_to_convert 가 0 이면 추출된 값은 0 임.
offset	처리를 시작할 페이로드의 바이트 수임.
relative	마지막 패턴 일치에 상대적인 오프셋을 사용함.
multiplier <value>	계산된 바이트 수에 <value> 을 곱하고 해당 바이트 수를 앞으로 건너뜀.
big	데이터를 빅 엔디안으로 처리함. (기본값)
little	데이터를 리틀 엔디안으로 처리함.
string	데이터는 패킷에 문자열 형식으로 저장됨.
hex	변환된 문자열 데이터는 16 진수로 표시됨.
dec	변환된 문자열 데이터는 10 진수로 표시됨.
oct	변환된 문자열 데이터는 8 진수로 표시됨.
align	변환된 바이트 수를 다음 32 비트 경계까지 반올림함.
from_beginning	패킷의 현재 위치에서가 아니라 패킷 페이로드의 시작 부분부터 앞으로 건너뜀.
from_end	점프는 페이로드의 끝에서 시작됨.
post_offset <value>	다른 점프 옵션이 적용된 후 <value> 바이트 수만큼 앞으로 또는 뒤(음수 값의 양수)로 건너뜀.
dce	DCE/RPC 2 전처리기(preprocessor)가 변환할 값의 바이트 순서를 결정하게 하십시오.
bitmask	bytes_to_convert 인수에 AND 연산자를 적용함. 결과는 마스크의 후행 0 수와 동일한 비트 수만큼 오른쪽 시프트됨.

 

alert udp any any -> any 32770:34000 (content:"|00 01 86 B8|"; \ content:"|00 00 00 01|"; distance:4; within:4; \ byte_jump:4, 12, relative, align; \ byte_test:4, >, 900, 20, relative; \ msg:"statd format string buffer overflow";) alert tcp any any -> any any (content:"Begin"; \ byte_jump:0, 0, from_end, post_offset -6; \ content:"end.."; distance:0; within:5; \ msg:"Content match from end of the payload";) alert tcp any any -> any any (content:"catalog"; \ byte_jump:2, 1, relative, post_offset 2, bitmask 0x03f0; \ byte_test:2, =, 968, 0, relative; \ msg:"Bitmask applied on the 2 bytes extracted for byte_jump";) alert tcp any any -> any any (content:"catalog"; \ byte_jump:1, 2, from_end, post_offset -5, bitmask 0x3c; \ byte_test:1, =, 106, 0, relative; \ msg:"Byte jump calculated from end of payload after bitmask applied";)

< 사용예 >

 

 

5.33 byte_extract

 

byte_extract 키워드는 길이 인코딩 프로토콜에 대한 규칙을 작성하는 데 유용한 또 다른 옵션임.

패킷 페이로드에서 몇 바이트를 읽어 변수에 저장됨.

이러한 변수는 하드 코딩된 값을 사용하는 대신 나중에 규칙에서 참조할 수 있음.

 

노트 :

규칙당 2개의 byte_extract 변수만 생성할 수 있음.

동일한 규칙에서 여러 번 재사용할 수 있음.

 

byte_extract:<bytes_to_extract>, <offset>, <name> [, relative] \ [, multiplier <multiplier value>][, <endian>][, string][, hex][, dec][, oct] \ [, align <align value>][, dce][, bitmask <bitmask>]; bytes_to_extract = 1 - 10 operator = ’<’ | ’=’ | ’>’ | ’<=’ | ’>=’ | ’&’ | ’ˆ’ value = 0 - 4294967295 offset = -65535 to 65535 bitmask_value = 1 to 4 byte hexadecimal value

< 형식 >

 

옵션	설명
bytes_to_convert	패킷에서 가져올 바이트 수임.
offset	처리를 시작할 페이로드의 바이트 수임.
name	변수의 이름임. 다른 규칙 옵션에서 변수를 참조하는 데 사용됨.
relative	마지막 패턴 일치에 상대적인 오프셋을 사용함.
multiplier <value>	패킷에서 읽은 바이트에 <value> 을 곱하고 그 숫자를 변수에 저장함.
big	데이터를 빅 엔디안으로 처리함. (기본값)
little	데이터를 리틀 엔디안으로 처리함.
dce	DCE/RPC 2 전처리기(preprocessor)가 변환할 값의 바이트 순서를 결정하십시오. 이 옵션이 작동하려면 DCE/RPC 2 전처리기가 활성화되어야 함.
string	데이터는 패킷에 문자열 형식으로 저장됨.
hex	변환된 문자열 데이터는 16 진수로 표시됨.
dec	변환된 문자열 데이터는 10 진수로 표시됨.
oct	변환된 문자열 데이터는 8 진수로 표시됨.
align <value>	변환된 바이트 수를 다음 <value> 바이트 경계까지 반올림함. <value> 은 2 또는 4 일 수 있음.
bitmask	인수를 추출하기 위해 바이트 값에 AND 연산자를 적용함. 결과는 마스크의 후행 0 수와 동일한 비트 수만큼 오른쪽 시프트함.

 

byte_extract 규칙 옵션은 자체적으로 아무것도 감지하지 않음.

다른 규칙 옵션에서 사용할 패킷 데이터를 추출하는 데 사용됨.

다음은 byte_extract 변수를 사용할 수 있는 위치 목록 :

규칙 옵션	변수를 취하는 인수
content/uricontent	offset, depth, distance, within
byte_test	offset, value
byte_jump	offset
isdataat	offset

< 바이트 추출 변수를 사용하는 기타 옵션 >

 

이 예에서는 두 개의 변수를 사용하여 다음을 수행함. • 오프셋 0의 바이트에서 문자열의 오프셋을 읽음. • 오프셋 1의 바이트에서 문자열의 깊이를 읽음. • 이 값을 사용하여 패턴 일치를 더 작은 영역으로 제한함. alert tcp any any -> any any (byte_extract:1, 0, str_offset; \ byte_extract:1, 1, str_depth; \ content:"bad stuff"; offset:str_offset; depth:str_depth; \ msg:"Bad Stuff detected within field";) alert tcp any any -> any any (content:"|04 63 34 35|"; offset:4; depth:4; \ byte_extract: 2, 0, var_match, relative, bitmask 0x03ff; \ byte_test: 2, =, var_match, 2, relative; \ msg:"Byte test value matches bitmask applied on bytes extracted";)

< 사용예 >

 

 

5.34 byte_math

 

추출된 값과 지정된 값 또는 기존 변수에 대해 수학적 연산을 수행하고 결과를 새 결과 변수에 저장함.

이러한 결과 변수는 하드 코딩된 값을 사용하는 대신 나중에 규칙에서 참조할 수 있음.

 

byte_math:bytes <bytes_to_extract>, offset <offset_value>, oper <operator>, rvalue <r_value>, result <result_variable> [, relative] [, endian <endian>] [, string <number type>][, dce] [, bitmask <bitmask_value>]; bytes_to_extract = 1 - 10 operator = ’+’ | ’-’ | ’*’ | ’/’ | ’<<’ | ’>>’ r_value = 0 - 4294967295 | byte extract variable offset_value = -65535 to 65535 bitmask_value = 1 to 4 byte hexadecimal value result_variable = Result Variable name

< 형식 >

 

옵션	설명
bytes_to_extract	패킷에서 가져올 바이트 수임. dce 없이 사용할 경우 허용되는 값은 1-10 임. dce 와 함께 사용하는 경우 허용되는 값은 1, 2 및 4 임. << 또는 >> 연산자와 함께 사용하는 경우 허용되는 값은 1-4 임.
oper	추출된 값에 대해 수행할 수학적 연산이 허용된 연산자 : +, -, *, /, <<, >>
rvalue	수학적 연산을 사용할 값임.
offset	처리를 시작할 페이로드의 바이트 수임.
relative	마지막 패턴 일치에 상대적인 오프셋을 사용함.
endian	읽고 있는 번호의 엔디안 유형 : • big - 데이터를 빅 엔디안으로 처리함. (기본값). • little - 데이터를 little endian으로 처리함.
string	데이터는 패킷에 문자열 형식으로 저장됨.
number type	읽을 번호 유형 : • hex - 변환된 문자열 데이터가 16 진수로 표시됨. • dec - 변환된 문자열 데이터가 10 진수로 표시됨. • oct - 변환된 문자열 데이터가 8 진수로 표시됨.
dce	DCE/RPC 2 전처리기(preprocessor)가 변환할 값의 바이트 순서를 결정하게 하십시오.
bitmask	추출된 바이트에 AND 연산자를 적용함. 결과는 마스크의 후행 0 수와 동일한 비트 수만큼 오른쪽 시프트됨.

 

규칙 옵션	결과 변수를 받는 인수
content	offset, depth, distance, within
byte_test	offset, value
byte_jump	offset
isdataat	offset

< 바이트 수학 결과 변수를 사용하는 기타 규칙 옵션 >

 

alert udp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"Perform Arithmetic Operation on the extracted bytes"; \ content:"|00 04 93 F3|"; \ content:"|00 00 00 07|"; distance:4; within:4; \ byte_math:bytes 4, offset 0, oper +, rvalue 248, result var, relative; \ byte_test:4, >, var, 2, relative;) alert tcp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"Bitwise shift operator"; \ content:"|00 00 00 07|"; distance:4; within:4; \ byte_extract: 1, 0, extracted_val, relative; \ byte_math: bytes 1, offset 2, oper >>, rvalue extracted_val, result var, relative; \ byte_test:2, =, var, 0, relative;) alert udp any any -> any 1234 \ (content: "Packets start"; \ byte_math: bytes 2, offset 0, oper -, rvalue 100, result var, relative, bitmask 0x7FF0; \ content: "Packets end"; distance: 2; within var; \ msg:"Content match with bitmask applied to the bytes extracted";) alert udp any any -> any 1235 \ (byte_extract: 4, 3, extracted_val, relative; \ byte_math: bytes 5, offset 0, oper +, rvalue extracted_val, result var, string hex; \ byte_test:5, =, var, 4, string, hex; \ msg:"String operator used with math rule option";)

< 사용예 >

 

 

5.35 ftpbounce

 

ftpbounce 키워드는 FTP bounce 공격을 감지함.

 

ftpbounce;

< 형식 >

 

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP PORT bounce attempt"; \ flow:to_server,established; content:"PORT"; nocase; ftpbounce; pcre:"/ˆPORT/smi";\ classtype:misc-attack; sid:3441; rev:1;)

< 사용예 >

 

 

5.36 asn1

 

ASN.1 탐지 플러그인은 패킷 또는 패킷의 일부를 디코딩하고 다양한 악성 인코딩을 찾음.

'asn1' 옵션에 여러 옵션을 사용할 수 있으며 암시적 논리의 부울 OR 임.

따라서 인수 중 하나라도 참으로 평가되면 전체 옵션이 참으로 평가됨.

ASN.1 옵션은 좀 더 동적인 유형 감지뿐만 아니라 프로그래밍 방식 감지 기능을 제공함.

옵션에 인수가 있는 경우 옵션과 인수는 공백이나 쉼표로 구분됨.

선호하는 사용법은 옵션과 인수 사이에 공백을 사용하는 것임.

 

asn1:[bitstring_overflow][, double_overflow][, oversize_length <value>][, absolute_offset <value>|relative_of

< 형식 >

 

옵션	설명
bitstring_overflow	원격으로 악용될 수 있는 것으로 알려진 유효하지 않은 비트 문자열 인코딩을 감지함.
double_overflow	표준 버퍼보다 큰 이중 ASCII 인코딩을 감지함. 이것은 Microsoft 에서 악용 가능한 기능으로 알려져 있지만 현재 어떤 서비스가 악용될 수 있는지는 알 수 없음.
oversize_length <value>	ASN.1 유형 길이를 제공된 인수와 비교함. 구문은 "oversize_length 500" 과 같음. 즉, ASN.1 유형이 500 보다 크면 이 키워드가 true 로 평가됨. 이 키워드에는 비교할 길이를 지정하는 하나의 인수가 있어야 함.
absolute_offset <value>	이것은 패킷 시작으로부터의 절대 오프셋임. 예를 들어 snmp 패킷을 디코딩하려면 "absolute_offset 0" 이라고 말하면 됨. absolute_offset 에는 오프셋 값이라는 하나의 인수가 있음. 오프셋은 양수 또는 음수일 수 있음.
relative_offset <value>	이것은 마지막 컨텐츠 일치, pcre 또는 byte_jump 의 상대적 오프셋임. relative_offset 에는 오프셋 번호라는 하나의 인수가 있음. 따라서 콘텐츠 "foo"바로 다음에 ASN.1 시퀀스 디코딩을 시작하려면 'content:"foo"; asn1:bitstring_overflow, relative_offset 0' 를 지정함. 오프셋 값은 양수 또는 음수일 수 있음.

 

alert udp any any -> any 161 (msg:"Oversize SNMP Length"; \ asn1:oversize_length 10000, absolute_offset 0;) alert tcp any any -> any 80 (msg:"ASN1 Relative Foo"; content:"foo"; \ asn1:bitstring_overflow, relative_offset 0;)

< 사용예 >

 

 

5.37 cvs

 

CVS 감지 플러그인은 Bugtraq-10384, CVE-2004-0396, "Malformed Entry Modified and Unchanged flag insertion" 를 감지하는 데 도움이 됨.

기본 CVS 서버 포트는 2401 및 514 이며 스트림 재조립을 위한 기본 포트에 포함됨.

 

노트 : 

이 플러그인은 암호화된 세션은 감지할 수 없음.

예를 들어 SSH 서비스와 일반적으로 포트 22번에 대해서 감지할 수 없음.

 

cvs:<option>;

< 형식 >

 

옵션	설명
invalid-entry	CVS 1.11.15 및 이전 버전에서 힙 오버플로우 및 잘못된 포인터 역참조를 유발하는 잘못된 항목 문자열을 찾음. (CVE-2004-0396 참조)

 

alert tcp any any -> any 2401 (msg:"CVS Invalid-entry"; \ flow:to_server,established; cvs:invalid-entry;)

< 사용예 >

 

 

5.38 dce_iface

생략

 

 

5.39 dce_opnum

생략

 

 

5.40 dce_stub_data

생략

 

 

5.41 sip_method

생략

 

 

5.42 sip_stat_code

생략

 

 

5.43 sip_header

생략

 

 

5.44 sip_body

생략

 

 

5.45 gtp_type

생략

 

 

5.46 gtp_info

생략

 

 

5.47 gtp_version

생략

 

 

5.48 ssl_version

생략

 

 

5.49 ssl_state

생략

 

 

5.50 Payload Detection Quick Reference

 

키워드	설명
content	content 키워드를 통해 사용자는 패킷 페이로드에서 특정 컨텐츠를 검색하고 해당 데이터를 기반으로 응답을 트리거하는 규칙을 설정할 수 있음.
rawbytes	rawbytes 키워드를 사용하면 규칙에서 전처리기가 수행한 디코딩을 무시하고 원시 패킷 데이터를 볼 수 있음.
depth	depth 키워드를 사용하면 규칙 작성기가 패킷 Snort 가 지정된 패턴을 검색해야 하는 거리를 지정할 수 있음.
offset	offset 키워드를 사용하면 규칙 작성기가 패킷 내에서 패턴 검색을 시작할 위치를 지정할 수 있음.
distance	distance 키워드를 사용하면 규칙 작성자가 이전 패턴 일치의 끝을 기준으로 지정된 패턴을 검색하기 전에 Snort 가 무시해야 하는 패킷의 거리를 지정할 수 있음.
within	within 키워드는 content 키워드를 사용하여 패턴 일치 사이에 최대 N 바이트가 있는지 확인하는 내용 수정자임.
uricontent	Snort 규칙 언어의 uricontent 키워드는 정규화된 요청 URI 필드를 검색함.
isdataat	isdataat 키워드는 페이로드의 지정된 위치에 데이터가 있는지 확인함.
pcre	pcre 키워드를 사용하면 perl 호환 정규식을 사용하여 규칙을 작성할 수 있음.
byte_test	byte_test 키워드는 특정 값(연산자 포함)에 대해 바이트 필드를 테스트함.
byte_jump	byte_jump 키워드를 사용하면 규칙이 데이터 일부의 길이를 읽은 다음 패킷에서 해당 길이를 건너 뛸 수 있음.
ftpbounce	ftpbounce 키워드는 FTP bounce 공격을 감지함.
asn1	asn1 탐지 플러그인은 패킷 또는 패킷의 일부를 디코딩하고 다양한 악성 인코딩을 찾음.
cvs	cvs 키워드는 유효하지 않은 항목 문자열을 감지함.
dce_iface	생략
dce_opnum	생략
dce_stub_data	생략
sip_method	생략
sip_stat_code	생략
sip_header	생략
sip_boy	생략
gtp_type	생략
gtp_info	생략
gtp_version	생략

< 페이로드 감지 규칙 옵션 키워드 >

 

 

 

( 6 ) Non-Payload 감지 규칙 옵션

 

 

6.1 fragoffset

 

fragoffset 키워드를 사용하면 IP 조각 오프셋 필드를 10 진수 값과 비교할 수 있음.

IP 세션의 모든 첫 번째 조각을 포착하려면 fragbits 키워드를 사용하고 fragoffset 0 과 함께 More fragments 옵션을 찾을 수 있음.

 

fragoffset:[!|<|>]<number>;

< 형식 >

 

alert ip any any -> any any \ (msg:"First Fragment"; fragbits:M; fragoffset:0;)

< 사용예 >

 

 

6.2 ttl

 

ttl 키워드는 IP 수명 값을 확인하는 데 사용됨.

이 옵션 키워드는 traceroute 시도 감지에 사용하기 위한 것임.

이 키워드는 0 에서 255 까지의 숫자를 사용함.

 

ttl:[<, >, =, <=, >=]<number>; ttl:[<number>]-[<number>];

< 형식 >

 

이 예에서는 3보다 작은 TTL 값을 확인함. ttl:<3; 이 예에서는 3과 5 사이의 수명 값을 확인함. ttl:3-5; 이 예에서는 0에서 5 사이의 TTL 값을 확인함. ttl:-5; 이 예에서는 5에서 255 사이의 수명 값을 확인함. ttl:5-; 다른 몇 가지 예는 다음과 같음. ttl:<=5; ttl:>=5; ttl:=5; 다음 예제는 ttl 키워드에서 허용되지 않음. ttl:=>5; ttl:=<5; ttl:5-3;

< 사용예 >

 

 

6.3 tos

 

tos 키워드는 특정 값에 대한 IP TOS 필드를 확인하는 데 사용됨.

 

tos:[!]<number>;

< 형식 >

 

이 예제는 4가 아닌 tos 값을 찾음. tos:!4;

< 사용예 >

 

 

6.4 id

 

id 키워드는 특정 값에 대한 IP ID 필드를 확인하는 데 사용됨.

일부 도구(Exploits, Scanner, 기타 프로그램)는 특히 다양한 목적으로 이 필드를 설정함.

예를 들어, 31337 값은 일부 해커에게 매우 인기가 있음.

 

id:<number>;

< 형식 >

 

이 예에서는 IP ID 31337 을 찾음. d:31337;

< 사용예 >

 

 

6.5 ipopts

 

ipopts 키워드는 특정 IP 옵션이 있는지 확인하는 데 사용됨.

다음 옵션을 확인할 수 있음.

rr - 경로 기록

eol - 목록 끝

nop - 작업 없음

ts - 타임 스탬프

sec - IP 보안

esec - IP 확장 보안

lsrr - 느슨한 소스 라우팅

lsrre - 느슨한 소스 라우팅 (MS99-038 및 CVE-1999-0909 의 경우)

ssrr - 엄격한 소스 라우팅

satid - 스트림 식별자

any - 모든 IP 옵션 설정

 

IP 옵션에 대해 가장 자주 관찰되는 것은 광범위하고 널리 퍼진 인터넷 어플리케이션에서 사용되지 않는 엄격하고 느슨한 소스 라우팅임.

 

ipopts:<rr|eol|nop|ts|sec|esec|lsrr|lsrre|ssrr|satid|any>;

< 형식 >

 

이 예에서는 느슨한 소스 라우팅의 IP 옵션을 찾음. ipopts:lsrr;

< 사용예 >

 

경고 :

규칙 당 하나의 ipopts 키워드만 지정할 수 있음.

 

 

6.6 fragbits

 

fragbits 키워드는 단편화 및 예약된 비트가 IP 헤더에 설정되어 있는지 확인하는 데 사용됨.

다음 비트를 확인할 수 있음.

M - 더 많은 조각

D - 조각화하지 마십시오.

R - 예약된 비트

 

다음 수정자를 설정하여 일치 기준을 변경할 수 있음.

+ - 지정된 비트 및 다른 비트에서 일치

* - 지정된 비트가 설정된 경우 일치

! - 지정된 비트가 설정되지 않은 경우 일치

 

fragbits:[+*!]<[MDR]>;

< 형식 >

 

이 예제는 More Fragments 비트와 Do not Fragment 비트가 설정되어 있는지 확인함. fragbits:MD+;

< 사용예 >

 

 

6.7 dsize

 

dsize 키워드는 패킷 페이로드 크기를 테스트하는 데 사용됨.

버퍼 오버플로우(buffer overflow)를 유발할 수 있는 비정상적인 크기의 패킷을 확인하는 데 사용할 수 있음.

 

dsize:min<>max; dsize:[<|>]<number>;

< 형식 >

 

이 예제는 300 에서 400 바이트(포함) 사이의 dsize를 찾음. dsize:300<>400;

< 사용예 >

 

경고 :

세분화는 HTTP 와 같은 TCP 기반 프로토콜에서 dsize 의 안정성을 떨어뜨림.

또한, 프로토콜 인식 플러시(PAF - Protocol Aware Flushing)가 이 패킷을 메시지의 시작으로 표시하지 않는 한 페이로드의 크기에 관계없이 스트림 재구축 된 패킷에서 dsize 가 실패함.

 

 

6.8 flags

 

flags 키워드는 특정 TCP 플래그 비트가 있는지 확인하는 데 사용됨.

다음 비트를 확인할 수 있음.

F - FIN (완료, TCP 플래그 바이트의 LSB)

S - SYN (시퀀스 번호 동기화)

R - RST (재설정)

P - PSH (푸시)

A - ACK (승인)

U - URG (긴급)

C - CWR (혼잡 창 감소, TCP 플래그 바이트의 MSB)

E - ECE (ECN-Echo, SYN이면 ECN 가능하며 그렇지 않으면 IP 헤더의 CE 플래그가 설정됨)

0 - TCP 플래그가 설정되지 않음

 

다음 수정자를 설정하여 일치 기준을 변경할 수 있음.

+ - 지정된 비트 및 다른 비트에서 일치

* - 지정된 비트가 설정된 경우 일치

! - 지정된 비트가 설정되지 않은 경우 일치

 

SYN 패킷이 CWR 및 ECE 세트와 함께 전송되는 ECN 같은 세션 시작 패킷에 대한 쓰기 규칙을 처리하기 위해 마스크 앞에 쉼표를 붙여 옵션 마스크를 지정할 수 있음.

예약된 비트의 값에 관계없이 syn 비트만 있는 패킷을 찾으려면 규칙은 S, CE 플래그 값을 확인할 수 있음.

 

flags:[!|*|+]<FSRPAUCE0>[,<FSRPAUCE>];

< 형식 >

 

이 예제는 CWR(예약 비트 1) 및 ECN(예약 비트 2) 을 무시하고 SYN 및 FIN 비트만 설정되었는지 확인함. alert tcp any any -> any any (flags:SF,CE;)

< 사용예 >

 

노트 :

RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP" 와 일치하도록 예약된 비트 '1' 및 '2' 가 각각 'C' 및 'E' 로 대체됨.

'1' 및 '2' 의 이전 값은 여전히 플래그 키워드에 유효하지만 현재는 더 이상 사용되지 않음.

 

 

6.9 flow

 

flow 키워드는 세션 추적과 함께 사용됨.

규칙을 트래픽 흐름의 특정 방향에만 적용 할 수 있음.

이렇게 하면 규칙이 클라이언트 또는 서버에만 적용됨.

이를 통해 웹 페이지를 보는 $HOME_NET 클라이언트와 관련된 패킷을 $HOME_NET 에서 실행되는 서버와 구별 할 수 있음.

설정된 키워드는 설정된 TCP 연결을 표시하기 위해 여러 위치에서 사용되는 flags:+A 를 대체함.

 

옵션	설명
to_client	A 에서 B 로 서버 응답을 트리거함.
to_server	A 에서 B 로 클라이언트 요청에 대해 트러거함.
from_client	A 에서 B 로 클라이언트 요청에 대해 트러거함.
from_server	A 에서 B 로 서버 응답을 트리거함.
established	설정된 TCP 연결에서만 트리거됨.
not_established	TCP 연결이 설정되지 않은 경우에만 트리거됨.
stateless	스트림 프로세서의 상태에 관계없이 트리거됨. (시스템 충돌을 유발하도록 설계된 패킷에 유용함)
no_stream	재구축된 스트림 패킷에서 트리거하지 마십시오. (dsize 및 stream5 에 유용)
only_stream	재구축된 스트림 패킷에서만 트리거됨.
no_frag	재구축된 조각 패킷에서 트리거하지 마십시오.
only_frag	재구축된 조각 패킷에서만 트리거됨.

< 옵션 >

 

flow:[(established|not_established|stateless)] [,(to_client|to_server|from_client|from_server)] [,(no_stream|only_stream)] [,(no_frag|only_frag)];

< 형식 >

 

alert tcp !$HOME_NET any -> $HOME_NET 21 (msg:"cd incoming detected"; \ flow:from_client; content:"CWD incoming"; nocase;) alert tcp !$HOME_NET 0 -> $HOME_NET 0 (msg:"Port 0 TCP traffic"; \ flow:stateless;)

< 사용예 >

 

 

6.10  flowbits

 

flowbits 키워드는 세션 전처리기의 대화 추적과 함께 사용됨.

규칙이 전송 프로토콜 세션 동안 상태를 추적할 수 있도록 함.

flowbits 옵션은 규칙이 일반적으로 어플리케이션 프로토콜의 상태를 추적할 수 있도록 허용하므로 TCP 세션에 가장 유용함.

flowbits 와 관련된 몇 가지 키워드가 있음.

대부분의 옵션에는 검사중인 특정 상태에 대한 사용자 정의 이름이 필요함.

일부 키워드는 그룹 이름을 사용함.

그룹 이름이 지정되지 않은 경우 flowbits 는 기본 그룹에 속함.

특정 flowbits 는 둘 이상의 그룹에 속할 수 있음.

flowbits 이름과 그룹 이름은 마침표, 대시 및 밑줄을 포함한 영숫자 문자열로 제한되어야 함.

 

flowbits:[set|setx|unset|toggle|isset|isnotset|noalert|reset][, <bits/bats>][, <GROUP_NAME>]; bits ::= bit[|bits] bats ::= bit[&bats]

< 일반적인 형식 >

 

alert tcp any 143 -> any any (msg:"IMAP login"; content:"OK LOGIN"; flowbits:set,logged_in; flowbits:noalert;) alert tcp any any -> any 143 (msg:"IMAP LIST"; content:"LIST"; flowbits:isset,logged_in;)

< 일반적인 사용예 >

 

옵션	설명
set	현재 흐름에 대해 지정된 상태를 설정하고 GROUP_NAME 이 지정되면 그룹에 할당함.
setx	현재 흐름에 대해 지정된 상태를 설정하고 그룹의 다른 상태를 지움.
unset	현재 흐름에 대해 지정된 상태를 설정 해제함.
toggle	지정된 모든 상태에 대해 상태가 설정되지 않은 경우 지정된 상태를 설정하고 상태가 설정된 경우 설정을 해제함.
isset	지정된 상태가 설정되었는지 확인함.
isnotset	지정된 상태가 설정되지 않았는지 확인함.
noalert	나머지 검색 옵션에 관계없이 규칙이 경고를 생성하지 않도록 함.
reset	지정된 흐름의 모든 상태를 재설정함.

 

set

 

이 키워드는 특정 흐름에 대해 그룹화할 비트를 설정함.

그룹이 지정되지 않은 경우 기본 그룹을 설정함.

이 키워드는 항상 true 를 반환함.

 

flowbits:set,bats[,group]

< 형식 >

 

첫 번째 규칙은 doc 그룹에서 bit1 을 설정하고 두 번째 규칫은 doc 그룹에서 bit2 및 bit3 을 설정함. 따라서 doc 그룹에는 bit1, bit2, bit3 이 설정되어 있음. flowbits:set,bit1,doc; flowbits:set,bit2&bit3,doc;

< 사용예 >

 

setx

 

이 키워드는 그룹화할 비트를 독점적으로 설정함.

이것은 그룹의 다른 비트를 지움.

그룹이 있어야 함.

이 키워드는 항상 true 를 반환함.

 

flowbits:setx,bats,group

< 형식 >

 

첫 번째 규칙은 doc 그룹에서 bit1 을 설정하고 두 번째 규칙은 doc 그룹에서 bit2 및 bit3 을 설정함. 따라서 bit1 은 규칙2 에 의해 지워지므로 doc 그룹에는 bit2 및 bit3 이 설정되어 있음. flowbits: setx, bit1, doc flowbits: setx, bit2&bit3, doc

< 사용예 >

 

unset

 

이 키워드는 특정 흐름에 대해 지정된 비트를 지우거나 그룹의 모든 비트를 지움. (그룹이 있어야 함)

이 키워드는 항상 true 를 반환함.

 

flowbits:unset,bats flowbits:unset,all,group

< 형식 >

 

bit1 을 지움. flowbits: unset, bit1 bit1 및 bit2 를 지움. flowbits: unset, bit1&bit2 doc 그룹의 모든 비트가 지워짐. flowbits: unset, all, doc

< 사용예 >

 

toggle

 

flowbit 가 설정되어 있으면 설정을 해제함.

설정되지 않은 경우 설정하십시오.

지정된 모든 비트를 토글(toggle)하거나 1그룹의 모든 비트를 토글함. (그룹이 있어야 함)

이 키워드는 항상 true 를 반환함.

 

flowbits:toggle,bats flowbits:toggle,all,group

< 형식 >

 

이 규칙 이전에 bit1 이 0 이고 bit2 가 1 이면 이 규칙 이후에 bit1 은 1 이고 bit2 은 0 임. flowbits: toggle, bit1&bit2 위에서 설명한대로 doc 그룹의 모든 비트를 토글함. flowbits:toggle,all,doc

< 사용예 >

 

isset

 

이 키워드는 설정되었는지 확인하기 위해 비트 또는 여러 비트를 확인함.

다음 구문에 따라 true 또는 false 를 반환함.

 

flowbits:isset, bits => 비트가 설정되었는지 확인 flowbits:isset, bats => 모든 비트가 설정되었는지 확인 flowbits:isset, any, group => 그룹의 비트가 설정되었는지 확인 flowbits:isset, all, group => 그룹의 모든 비트가 설정되었는지 확인

< 형식 >

 

flowbits:isnotset, bit1|bit2 => bit1 또는 bit2 가 설정되면 true 를 반환 flowbits:isnotset, bit1&bit2 => bit1 과 bit2 가 모두 설정된 경우 true 를 반환하고 그렇지 않으면 false 를 반환 flowbits:isnotset, any, doc => doc 그룹의 비트가 설정되면 true 를 반환 flowbits:isnotset, all, doc => doc 그룹의 모든 비트가 설정되면 true 를 반환

< 사용예 >

 

noalert

 

이 키워드는 항상 false 를 반환함.

이를 통해 사용자는 경고를 생성하지 않고 비트를 설정, 설정 해제 및 토글하는 규칙을 작성할 수 있음.

이는 정상적인 트래픽에 비트를 설정하고 원치 않은 경고를 크게 줄이는 flowbit 규칙을 작성하는 데 가장 유용함.

이 키워드에 지정된 비트가 없음.

 

flowbits:noalert;

< 형식 >

 

reset

 

이 키워드는 지정된 그룹이 없는 경우 지정된 흐름의 모든 상태를 재설정하고 그렇지 않으면 그룹의 모든 비트를 재설정함.

이것은 항상 true 를 반환함.

이 키워드에 지정된 비트가 없음.

 

flowbits:reset[,group]

< 형식 >

 

flowbits:reset => 흐름의 모든 비트 재설정 flowbits: reset, doc => doc 그룹의 모든 비트 재설정

< 사용예 >

 

 

6.11 seq

 

seq 키워드는 특정 TCP 시퀀스 번호를 확인하는 데 사용됨.

 

seq:<number>;

< 형식 >

 

이 예에서는 TCP 시퀀스 번호 0 을 찾음. seq:0;

< 사용예 >

 

 

6.12 ack

 

ack 키워드는 특정 TCP 승인 번호를 확인하는 데 사용됨.

 

ack:<number>;

< 형식 >

 

이 예에서는 TCP 승인 번호 0 을 찾음. ack:0;

< 사용예 >

 

 

6.13 window

 

window 키워드는 특정 TCP 창 크기를 확인하는 데 사용됨.

 

window:[!]<number>;

< 형식 >

 

이 예에서는 TCP 창 크기 55808 를 찾음. window:55808;

< 사용예 >

 

 

6.14 itype

 

itype 키워드는 특정 ICMP 유형 값을 확인하는 데 사용됨.

 

icode:min<>max; icode:[<|>]<number>;

< 형식 >

 

이 예에서는 30 보다 큰 ICMP 유형을 찾음. itype:>30;

< 사용예 >

 

 

6.15 icode

 

icode 키워드는 특정 ICMP 코드 값을 확인하는 데 사용됨.

 

itype:min<>max; itype:[<|>]<number>;

< 형식 >

 

첫 번째 형식의 <> 연산자는 지정된 범위(배타적) 내에서 ICMP 코드를 확인함.

즉, 최소값보다 크거나 최대값보다 작음.

최소값은 -1 이 될 수 있으므로 ICMP 코드 0 이 범위에 포함될 수 있음.

숫자 값은 0 에서 255 사이의 허용되는 ICMP 코드 값 및 기타 기준과 관련하여 검증됨.

 

icode:min<>max

-1 <= min <= 254

1 <= max <= 256

(max - min) > 1

 

icode:number

0 <= number <= 255

 

icode:<number

1 <= number <= 256

 

icode:>number

0 <= number <= 254

 

이 예에서는 30 보다 큰 ICMP 코드를 찾음. icode:>30;   이 예에서는 0 보다 크고 30 보다 작은 ICMP 코드를 찾음. icode:-1<>30;

< 사용예 >

 

 

6.16 icmp_id

 

icmp_id 키워드는 특정 ICMP ID 값을 확인하는 데 사용됨.

이것은 일부 비밀 채널 프로그램이 통신 할 때 정적 ICMP 필드를 사용하기 때문에 유용함.

이 특정 플러그인은 stacheldraht DDoS 에이전트를 감지하기 위해 개발됨.

 

icmp_id:<number>;

< 형식 >

 

이 예에서는 ICMP ID 0 을 찾음. icmp_id:0;

< 사용예 >

 

 

6.17 icmp_seq

 

icmp seq 키워드는 특정 ICMP 시퀀스 값을 확인하는 데 사용됨.

이것은 일부 비밀 채널 프로그램이 통신 할 때 정적 ICMP 필드를 사용하기 때문에 유용함.

이 특정 플러그인은 stacheldraht DDoS 에이전트를 감지하기 위해 개발됨.

 

icmp_seq:<number>;

< 형식 >

 

이 예에서는 ICMP 시퀀스 0 을 찾음. icmp_seq:0;

< 사용예 >

 

 

6.18 rpc

 

rpc 키워드는 SUNRPC CALL 요청에서 RPC 애플리케이션, 버전 및 프로시저 번호를 확인하는 데 사용됨.

와일드 카드는 ’*’ 를 사용하여 버전 및 프로시저 번호 모두에 유효함.

 

rpc:<application number>, [<version number>|*], [<procedure number>|*]>;

< 형식 >

 

다음 예제는 RPC 포트 맵 GETPORT 요청을 찾음. alert tcp any any -> any 111 (rpc:100000, *, 3;);

< 사용예 >

 

경고 :

빠른 패턴 일치 엔진으로 인해 RPC 키워드는 일반 컨텐츠 일치를 사용하여 RPC 값을 찾는 것보다 느림.

 

 

6.19 ip_proto

 

ip_proto 키워드는 IP 프로토콜 헤더에 대한 검사를 허용함.

이름으로 지정할 수 있는 프로토콜 목록은 /etc/protocols 를 참조하십시오.

 

ip_proto:[!|>|<] <name or number>;

< 형식 >

 

이 예에서는 IGMP 트래픽을 찾음.   alert ip any any -> any any (ip_proto:igmp;)

< 사용예 >

 

 

6.20 sameip

 

sameip 키워드를 사용하면 규칙에서 소스 IP 가 대상 IP 와 동일한 지 확인할 수 있음.

 

sameip;

< 형식 >

 

이 예에서는 소스 IP와 대상 IP가 동일한 트래픽을 찾음. alert ip any any -> any any (sameip;)

< 사용예 >

 

 

6.21 stream_reassemble

 

stream_reassemble 키워드를 사용하면 규칙이 일치하는 트래픽에서 TCP 스트림 재조립을 활성화 또는 비활성화할 수 있음.

 

노트 :

stream_reassemble 옵션은 스트림 전처리기(Stream preprocessor)가 활성화된 경우에만 사용할 수 있음.

 

stream_reassemble:<enable|disable>, <server|client|both>[, noalert][, fastpath]; • 선택적 noalert 매개 변수를 사용하면 규칙이 일치할 때 경고를 생성하지 않음. • 선택적 fastpath 매개 변수를 사용하면 Snort 가 나머지 연결을 무시함.

< 형식 >

 

예를 들어, HTTP 200 Ok 응답 메시지가 표시 될 때 클라이언트 트래픽에 대한 TCP 재조립을 비활성화하려면 다음을 사용함.   alert tcp any 80 -> any any (flow:to_client, established; content:"200 OK"; stream_reassemble:disable,client,noalert;)

< 사용예 >

 

 

6.22 stream_size

 

stream_size 키워드를 사용하면 규칙이 TCP 시퀀스 번호에 의해 결정된 대로 관찰된 바이트 수에 따라 트래픽을 일치시킬 수 있음.

 

노트 :

stream_size 옵션은 스트림 전처리기(Stream preprocessor)가 활성화된 경우에만 사용할 수 있음.

 

stream_size:<server|client|both|either>, <operator>, <number>; operator 가 다음 중 하나인 경우 : • < - 미만 • > - 보다 큼 • = - 같음 • != - 같지 않음 • <= - 작거나 같음 • >= - 크거나 같음

< 형식 >

 

예를 들어, 클라이언트 측에서 6 바이트 미만인 세션을 찾으려면 다음을 사용함. alert tcp any any -> any any (stream_size:client,<,6;)

< 사용예 >

 

 

6.23 Non-Payload Detection Quick Reference

 

키워드	설명
fragoffset	fragoffset 키워드를 사용하면 IP 조각 오프셋 필드를 10 진수값과 비교할 수 있음.
ttl	ttl 키워드는 IP 수명값을 확인하는 데 사용됨.
tos	tos 키워드는 특정 값에 대한 IP TOS 필드를 확인하는 데 사용됨.
id	id 키워드는 특정 값에 대한 IP ID 필드를 확인하는 데 사용됨.
ipopts	ipopts 키워드는 특정 IP 옵션이 있는지 확인하는 데 사용됨.
fragbits	fragbits 키워드는 단편화 및 예약 된 비트가 IP 헤더에 설정되어 있는지 확인하는 데 사용됨.
dsize	dsize 키워드는 패킷 페이로드 크기를 테스트하는 데 사용됨.
flags	flags 키워드는 특정 TCP 플래그 비트가 있는지 확인하는 데 사용됨.
flow	flow 키워드는 규칙이 트래픽 흐름의 특정 방향에만 적용되도록 허용함.
flowbits	flowbits 키워드를 사용하면 규칙이 전송 프로토콜 세션 동안 상태를 추적할 수 있음.
seq	seq 키워드는 특정 TCP 시퀀스 번호를 확인하는 데 사용됨.
ack	ack 키워드는 특정 TCP 승인 번호를 확인하는 데 사용됨.
window	window 키워드는 특정 TCP 창 크기를 확인하는 데 사용됨.
itype	itype 키워드는 특정 ICMP 유형 값을 확인하는 데 사용됨.
icode	icode 키워드는 특정 ICMP 코드 값을 확인하는 데 사용됨.
icmp_id	icmp_id 키워드는 특정 ICMP ID 값을 확인하는 데 사용됨.
icmp_seq	icmp_seq 키워드는 특정 ICMP 시퀀스 값을 확인하는 데 사용됨.
rpc	rpc 키워드는 SUNRPC CALL 요청에서 RPC 애플리케이션, 버전 및 프로시저 번호를 확인하는 데 사용됨.
ip_proto	ip_proto 키워드는 IP 프로토콜 헤더에 대한 검사를 허용함.
sameip	sameip 키워드를 사용하면 규칙에서 소스 IP 가 대상 IP 와 동일한 지 확인할 수 있음.

< 비 페이로드 감지 규칙 옵션 키워드 >

 

 

 

( 7 ) Post-Detection 규칙 옵션

 

 

7.1 logto

 

logto 키워드는이 규칙을 트리거하는 모든 패킷을 특수 출력 로그 파일에 기록하도록 Snort에 지시함.

이는 NMAP 활동, HTTP CGI 스캔 등과 같은 데이터를 결합하는 데 특히 유용함.

이 옵션은 Snort 가 바이너리 로깅 모드에 있을 때는 작동하지 않음.

 

logto:"filename";

< 형식 >

 

 

7.2 session

 

session 키워드는 TCP 세션에서 사용자 데이터를 추출하기 위해 작성됨.

사용자가 telnet, rlogin, ftp 또는 웹 세션에서 입력하는 내용을 보는 것이 매우 유용한 경우가 많음.

session 규칙 옵션에 대해 세 가지 사용 가능한 인수 키워드(printable, binary, all)가 있음.

printable 키워드는 사용자가 일반적으로 보거나 입력할 수 있는 데이터만 인쇄함.

binary 키워드는 바이너리 형식으로 데이터를 인쇄함.

all 키워드는 인쇄할 수 없는 문자를 16진수 문자으로 대체함.

 

session:[printable|binary|all];

< 형식 >

 

다음 예제는 텔넷 패킷에 인쇄 가능한 모든 문자열을 기록함. log tcp any any <> any 23 (session:printable;) 포트 12345 의 FTP 데이터 세션이 주어지면 페이로드 바이트를 바이너리 형식으로 기록함. log tcp any any <> any 12345 (metadata:service ftp-data; session:binary;)

< 사용예 >

 

경고 :

session 키워드를 사용하면 Snort 속도가 상당히 느려질 수 있으므로 부하가 많은 상황에서 사용해서는 안됨.

session 키워드는 사후 처리 바이너리(pcap) 로그 파일에 가장 적합함.

binary 키워드는 어플리케이션 계층 아래의 프로토콜 헤더를 기록하지 않으며 스트림 재조립은 재조립 된 패킷이 기록 될 때 중복 데이터를 발생시킴.

 

 

7.3 resp

 

resp 키워드는 문제가되는 세션을 종료하는 활성 응답을 활성화함.

resp 는 수동 또는 인라인 모드 모두에서 사용할 수 있음.

 

 

7.4 react

 

react 키워드를 사용하면 웹 페이지 또는 기타 컨텐츠를 클라이언트에 보낸 다음 연결을 닫는 것을 포함하는 활성 응답을 사용할 수 있음.

React는 수동 모드와 인라인 모드 모두에서 사용할 수 있음.

 

 

7.5 tag

 

tag 키워드를 사용하면 규칙에다가 규칙을 트리거 한 단일 패킷 이상을 기록 할 수 있음.

규칙이 트리거되면 소스 및 또는(and/or) 대상 호스트와 관련된 추가 트래픽에 태그가 지정됨.

태그가 지정된 트래픽이 기록되어 응답 코드 및 공격 후 트래픽을 분석 할 수 있음.

태그가 지정된 경고는 원래 경고와 동일한 출력 플러그인으로 전송되지만 이러한 특수 경고를 적절하게 처리하는 것은 출력 플러그인의 책임임.

 

tag:host, <count>, <metric>, <direction>; tag:session[, <count>, <metric>][, exclusive];

< 형식 >

 

type

• session - 규칙을 설정한 세션의 패킷 기록

• host - 태그를 활성화 한 호스트의 로그 패킷 ([방향] 수정자 사용)

 

count

• <integer> - 개수는 단위 수로 지정됨. 단위는 <metric> 필드에 지정됨.

 

metric

• packets - <count> 패킷 동안 host/session 에 태그를 지정

• seconds - <count> 초 동안 host/session 에 태그를 지정

• bytes - <count> 바이트 동안 host/session 에 태그를 지정

 

other

• src - 초기 이벤트를 생성한 패킷에서 소스 IP 주소를 포함하는 패킷에 태그를 지정함. 호스트 유형이 사용되는 경우에만 관련됨.

• dst - 초기 이벤트를 생성한 패킷에서 대상 IP 주소를 포함하는 패킷에 태그를 지정함. 호스트 유형이 사용되는 경우에만 관련됨.

• exclusive - 첫 번째 일치 세션에서만 패킷에 태그를 지정함. 세션 유형이 사용되는 경우에만 관련됨.

 

후속 경고나 이벤트 필터는 태그가 지정된 패킷이 기록되는 것을 방지하지 않음.

이후에 태그가 지정된 경고로 인해 제한이 재설정됨.

 

alert tcp any any <> 10.1.1.1 any \

(flowbits:isnotset,tagged; content:"foobar"; nocase; \

flowbits:set,tagged; tag:host,600,seconds,src;)

 

또한, 규칙에 packets 이외의 메트릭을 사용하는 태그 옵션이 있는 경우 seconds 또는 bytes 개수에 관계없이 태그가 지정된 패킷 수를 제한하는 데 tagged_packet_limit 가 사용됨.

기본 tagged_packet_limit 값은 256 이며 snort.conf 파일에서 구성 옵션을 사용하여 수정할 수 있음.

태그 옵션에 packets 메트릭을 추가하고 개수를 0 으로 설정하여 특정 규칙에 대해 이 패킷 제한을 비활성화 할 수 있음. (이는 snort.conf 의 tagged_packet_limit 옵션을 0 으로 설정하여 글로벌 규모로 수행할 수 있음)

이렇게하면 패킷이 seconds 또는 bytes 의 전체 양에 대해 태그가 지정되고 tagged_packet_limit에 의해 잘리지 않음. (tag_packet_limit 는 seconds 또는 bytes 카운트가 높은 태그 규칙에 대해 고대역폭 센서에서 DoS 상황을 피하기 위해 도입됨)

 

alert tcp 10.1.1.4 any -> 10.1.1.1 any \

(content:"TAGMYPACKETS"; tag:host,0,packets,600,seconds,src;)

 

이 예는 텔넷 세션의 처음 10 초 또는 태그가 지정된 패킷 제한(둘 중 먼저 오는 쪽)을 기록함. alert tcp any any -> any 23 (flags:S,CE; tag:session,10,seconds;) tag:host 에는 하나 이상의 개수와 메트릭이 필요하지만 메트릭없이 배타적인 tag:session 을 사용하여 이와 같은 전체 세션을 얻을 수 있음. pass tcp any any -> 192.168.1.1 80 (flags:S; tag:session,exclusive;)

< 사용예 >

 

 

7.6 replace

 

replace 키워드는 Snort 가 이전에 일치하는 컨텐츠에 주어진 문자열로 바꾸도록 하는 기능으로 인라인 모드에서 사용함.

새 문자열과 교체할 내용은 모두 길이가 같아야 함.

규칙 내에서 컨텐츠당 하나번 여러 개의 교체가 있을 수 있음.

 

replace:"<string>";

< 형식 >

 

 

7.7 detection_filter

 

탐지 필터는 규칙이 이벤트를 생성하기 전에 소스 또는 대상 호스트가 초과해야 하는 비율을 정의함.

 

detection_filter: \ track <by_src|by_dst>, \ count <c>, seconds <s>;

< 형식 >

 

 

옵션	설명
track by_src|by_dst	속도는 소스 IP 주소 또는 대상 IP 주소로 추적됨. 즉, 각 고유 소스 IP 주소 또는 각 고유 대상 IP 주소에 대해 개수가 유지됨.
count c	탐지 필터 제한을 초과하기 전에 허용되는 최대 규칙 일치 수(초)임. C 는 0 이 아니어야 함.
seconds s	실사가 발생하는 기간임. 값은 0 이 아니어야 함.

 

Snort는 다른 모든 규칙 옵션을 평가 한 후 탐지 단계의 마지막 단계로 탐지 필터를 평가함. (규칙 소스 내 필터의 위치에 관계없이)

규칙당 최대 하나의 탐지 필터가 허용됨.

 

이 규칙은 처음 30 회의 로그인 시도가 실패한 후 60 초 샘플링 기간 동안 10.1.2.100 부터 실패한 모든 로그인 시도에 대해 실행됨. drop tcp 10.1.2.100 any > 10.1.1.100 22 ( \ msg:"SSH Brute Force Attempt"; flow:established,to_server; \ content:"SSH"; nocase; offset:0; depth:4; \ detection_filter:track by_src, count 30, seconds 60; \ sid:1000001; rev:1;)

< 사용예 >

 

잠재적으로 많은 이벤트가 생성되므로 일반적으로 detection_filter 를 event_filter 와 함께 사용하여 기록된 이벤트 수를 줄임.

 

노트 :

위에서 언급했듯이 Snort 는 탐지 필터를 사후 탐지가 아닌 탐지의 마지막 단계로 평가함.

 

 

7.8 Post-Detection Quick Reference

 

키워드	설명
logto	logto 키워드는이 규칙을 트리거하는 모든 패킷을 특수 출력 로그 파일에 기록하도록 Snort 에 지시함.
session	session 키워드는 TCP 세션에서 사용자 데이터를 추출하기 위해 작성됨.
resp	resp 키워드는 경고가 트리거 될 때 세션을 닫는 데 사용됨.
react	이 키워드는 사용자가 연결을 닫고 알림을 전송하여 Snort 규칙과 일치하는 트래픽에 반응할 수 있는 기능을 구현함.
tag	tag 키워드를 사용하면 규칙이 규칙을 트리거 한 단일 패킷 이상을 기록할 수 있음.
replace	이전에 일치하는 컨텐츠를 동일한 길이의 주어진 문자열로 바뀜. 인라인 모드에서만 사용할 수 있음.
detection_filter	소스 또는 대상 IP 주소로 추적하고 규칙이 구성된 속도보다 더 많이 일치하면 실행됨.

< Post-Detection 규칙 옵션 키워드 >

 

 

 

( 8 ) Rule Thresholds

 

노트 :

Rule Thresholds 은 더 이상 사용되지 않으며 향후 릴리스에서 지원되지 않음.

규칙 내에서 detection_filters를 사용하거나 대신 독립형 구성으로 event_filters를 사용하십시오.

 

임계값은 규칙의 일부로 포함되거나 적용되는 생성자(generator) 및 SID 를 참조하는 독립 실행 형 임계값을 사용할 수 있음.

규칙에 임계값을 추가하는 것과 동일한 규칙에 적용된 독립형 임계값을 사용하는 것 사이에는 기능적 차이가 없음.

논리적 차이가 있음.

일부 규칙은 임계값으로만 이해할 수 있음.

이는 임계값을 규칙에 통합해야 함.

예를 들어 너무 많은 로그인 암호 시도를 감지하는 규칙은 5 회 이상의 시도가 필요할 수 있음.

이는 'limit' 유형의 임계값을 사용하여 수행할 수 있음.

임계값 기능이 이 규칙의 필수 부분이라는 것은 이치에 맞음.

 

threshold: \ type <limit|threshold|both>, \ track <by_src|by_dst>, \ count <c>, seconds <s>;

< 형식 >

 

이 규칙은 60 초마다 SID 의 첫 번째 이벤트를 기록함. alert tcp $external_net any -> $http_servers $http_ports \ (msg:"web-misc robots.txt access"; flow:to_server, established; \ uricontent:"/robots.txt"; nocase; reference:nessus,10302; \ classtype:web-application-activity; threshold:type limit, track \ by_src, count 1 , seconds 60; sid:1000852; rev:1;) 이 규칙은 60 초마다 SID 의 첫 번째 이벤트를 기록함. 따라서 60 초 동안 10 개 미만의 이벤트가 발생하면 아무것도 기록되지 않음. 이벤트가 기록되면 type=threshold 에 대한 새 기간이 시작됨. alert tcp $external_net any -> $http_servers $http_ports \ (msg:"web-misc robots.txt access"; flow:to_server, established; \ uricontent:"/robots.txt"; nocase; reference:nessus,10302; \ classtype:web-application-activity; threshold:type threshold, \ track by_dst, count 10 , seconds 60 ; sid:1000852; rev:1;) 이 규칙은 SID 에서 10 개 이상의 이벤트가 발생하는 경우 60 초마다 최대 하나의 이벤트를 기록함. alert tcp $external_net any -> $http_servers $http_ports \ (msg:"web-misc robots.txt access"; flow:to_server, established; \ uricontent:"/robots.txt"; nocase; reference:nessus,10302; \ classtype:web-application-activity; threshold:type both, track \ by_dst, count 10, seconds 60; sid:1000852; rev:1;)

< 사용예 >

 

옵션	설명
type limit|threshold|both	시간 간격 동안 첫 번째 m 이벤트에 대해 limit 경고를 입력한 다음 나머지 시간 간격 동안 이벤트를 무시함. 시간 간격 동안이 이벤트를 볼 때마다 threshold 경고를 입력함. m 개의 이벤트 발생을 확인한 후 시간 간격당 한 번씩 both 경고를 입력 한 다음 시간 간격 동안 추가 이벤트를 무시함.
track by_src|by_dst	속도는 소스 IP 주소 또는 대상 IP 주소로 추적됨. 즉, 각 고유 소스 IP 주소 또는 각 고유 대상 IP 주소에 대해 개수가 유지됨. 포트 또는 기타 항목은 추적되지 않음.
count c	event_filter 한계를 초과하게 만드는 s 초 단위의 규칙 일치 수임. c 는 0 이 아닌 값이어야 함.
seconds s	실사가 발생하는 기간임. s 는 0 이 아닌 값이어야 함.

< Post-Detection 규칙 옵션 키워드 >

 

 

 

( 9 ) 좋은 규칙 작성

 

효율성과 속도를 극대화하기 위해 Snort 규칙을 개발할 때 염두에 두어야 할 몇 가지 일반적인 개념이 있음.

 

 

9.1 컨텐츠 매칭

 

Snort 는 프로토콜(ip, tcp, udp, icmp), 포트(ip 와 icmp 는 약간 다른 로직 사용), content 가 있는 것과 없는 것 별로 규칙을 그룹화함.

content 가 포함 된 규칙의 경우 단일 컨텐츠를 기준으로 일치 가능성이 있는 규칙을 선택하기 위해 다중 패턴 매처(multi-pattern matche)가 사용됨.

이 "빠른" 패턴 일치기("fast" pattern matcher)를 통해 평가할 규칙을 선택하면 특히 HTTP 와 같은 대규모 규칙 그룹에 적용될 때 성능이 향상되는 것으로 나타남.

content 가 길고 고유할수록 해당 규칙과 모든 규칙 옵션이 불필요하게 평가 될 가능성이 줄어듬. - 일반적으로 "나쁜" 트래픽보다 "좋은" 트래픽이 더 많다고 말하는 것이 안전함(safe).

content 가 없는 규칙은 항상 평가되어(상주하는 프로토콜 및 포트 그룹과 관련하여) 잠재적으로 성능에 영향을 줌.

pcre 및 byte_test 와 같은 검색 옵션은 패킷의 페이로드 섹션에서 검색을 수행하지만 고속 패턴 일치 엔진(fast pattern matching engine)에서는 사용되지 않음.

가능하면 규칙에 하나 이상의 content(또는 uricontent) 규칙 옵션을 사용하십시오.

 

 

9.2 익스플로잇이 아닌 취약점 파악 (Catch the Vulnerability, Not the Exploit)

 

특정 익스플로잇 대신 취약점을 표적으로 삼는 규칙을 작성하십시오.

예를 들어, 쉘을 바인딩하는 쉘코드 대신 인수가 너무 큰 취약한 명령어를 찾으십시오.

취약점에 대한 규칙을 작성하면 공격자가 익스플로잇을 약간 변경할 때 규칙이 회피에 덜 취약함.

 

 

9.3 규칙에서 프로토콜의 이상한 점 파악

 

많은 서비스는 일반적으로 대문자로 명령어을 모냄.

FTP 가 좋은 예임.

FTP 에서 사용자 이름을 보내기 위해 클라이언트는 다음을 보냄.

 

user username_here

 

FTP root 로그인 시도를 찾는 간단한 규칙은 다음과 같음.

 

alert tcp any any -> any any 21 (content:"user root";)

 

사용자 이름 root 를 찾는 규칙을 작성하는 것은 사소한 것처럼 보일 수 있지만, 좋은 규칙은 사용자 명령을 수락할 때 프로토콜이 처리 할 수 있는 모든 이상한 일을 처리함.

 

예를 들어, 다음은 대부분의 FTP 서버에서 허용됨.

 

user root

user root

user root

user root

user<tab>root

 

FTP 서버가 처리 할 수 있는 모든 경우를 처리하려면 규칙에 단순한 문자열 일치보다 더 스마트 한 것이 필요함.

ftp 에서 루트 로그인을 찾는 좋은 규칙은 다음과 같음.

 

alert tcp any any -> any 21 (flow:to_server,established; \

content:"root"; pcre:"/user\s+root/i";)

 

이 규칙에서 유의해야 할 몇 가지 중요한 사항이 있음 :

• 규칙에는 설정된 세션에서 서버로 이동하는 트래픽인지 확인하는 flow 옵션이 있음.

• 규칙에는 공격에서 가장 길고 고유 한 문자열 인 root 를 찾는 content 옵션이 있음. 이 옵션은 페이로드에서 root 컨텐츠가 발견되는 경우에만 평가를 위해 빠른 패턴 일치자가 이 규칙을 선택할 수 있도록 추가됨.

• 규칙에는 pcre 옵션이 있으며 user 를 찾고 적어도 하나의 공백 문자(탭 포함)와 root 가 이어짐. (대소문자 무시)

 

 

9.4 규칙 최적화

 

검색 엔진의 컨텐츠 일치 부분에는 몇 가지 회피 사례를 처리하기 위한 재귀가 있음.

제대로 작성되지 않은 규칙으로 인해 Snort 가 검사를 복사하는(duplicationg) 데 시간을 낭비 할 수 있음.

이제 재귀가 작동하는 방식은 패턴이 일치하는 경우이고 해당 패턴 이후의 검색 옵션이 실패하면 이전에 발견된 위치에서 다시 패턴을 찾음.

패턴이 다시 발견되지 않거나 opt 기능이 모두 성공할 때까지 반복하십시오.

처음 읽을 때, 그것은 현명한 생각처럼 들리지 않을 수도 있지만 필요함.

예를 들어, 다음 규칙을 따르십시오 :

 

alert ip any any -> any any (content:"a"; content:"b"; within:1;)

 

이 규칙은 "a" 를 찾고 바로 뒤에 "b" 를 찾음.

재귀가 없으면 페이로드 "aab" 에 "a" 바로 뒤에 "b" 가 있음이 분명하더라도 "aab" 페이로드가 실패함.

왜냐하면 첫 번째 "a" 다음에 "b" 가 바로 뒤따르지 않기 때문임.

재귀는 탐지에 중요하지만 재귀 구현은 그리 똑똑하지 않음.

예를 들어 다음 규칙 옵션은 최적화되지 않음.

 

content:"|13|"; dsize:1;

 

이 규칙 스니펫(snippet)을 보면 규칙이 단일 바이트가 0x13 인 패킷을 찾는 것이 분명함.

그러나 재귀로 인해 1024 바이트의 0x13 패킷은 1023 너무 많은 패턴 일치 시도와 1023 너무 많은 dsize 검사를 유발할 수 있음.

왜?

컨텐츠 0x13 이 첫 번째 바이트에서 발견되면 dsize 옵션이 실패하고 재귀로 인해 컨텐츠 0x13 이 이전 0x13 이 발견된 위치부터 다시 발견되고 일단 발견되면 dsize 를 다시 확인함. 페이로드에서 0x13 이 다시 발견되지 않을 때까지 반복함.

 

불연속 검사(예 : dsize)가 규칙의 시작 부분으로 이동되도록 규칙 옵션을 재정렬하면 Snort 속도가 빨라짐.

최적화 된 규칙 스니핑(snipping)은 다음과 같음 :

 

dsize:1; content:"|13|";

 

1024 바이트 0x13 패킷은 dsize 검사가 첫 번째 옵션이고 dsize 가 재귀 없는 개별 검사이므로 즉시 실패함.

다음 규칙 옵션은 개별적이며 일반적으로 규칙의 시작 부분에 배치해야 함.

 

• dsize

• flags

• flow

• fragbits

• icmp id

• icmp seq

• icode

• id

• ipopts

• ip proto

• itype

• seq

• session

• tos

• ttl

• ack

• window

• resp

• sameip

 

 

9.5 숫자값 테스트

 

규칙 옵션 byte_test 및 byte_jump 는 길이 인코딩 데이터가 있는 프로토콜에 대한 쓰기 규칙을 지원하기 위해 작성됨.

RPC 는 데이터 전달에 간단한 길이 기반 인코딩을 사용하기 때문에 RPC 는 이 두 가지 규칙 옵션에 대한 요구 사항을 생성한 프로토콜임.

 

byte_test 및 byte jump 가 유용한 이유를 이해하기 위해 sadmind 서비스에 대한 공격 시도를 살펴봄.

이것은 익스플로잇의 페이로드임.

 

89 09 9c e2 00 00 00 00 00 00 00 02 00 01 87 88 ................

00 00 00 0a 00 00 00 01 00 00 00 01 00 00 00 20 ...............

40 28 3a 10 00 00 00 0a 4d 45 54 41 53 50 4c 4f @(:.....metasplo

49 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 it..............

00 00 00 00 00 00 00 00 40 28 3a 14 00 07 45 df ........@(:...e.

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 04 ................

7f 00 00 01 00 01 87 88 00 00 00 0a 00 00 00 04 ................

7f 00 00 01 00 01 87 88 00 00 00 0a 00 00 00 11 ................

00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 3b 4d 45 54 41 53 50 4c 4f .......;metasplo

49 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 it..............

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 06 73 79 73 74 65 6d 00 00 ........system..

00 00 00 15 2e 2e 2f 2e 2e 2f 2e 2e 2f 2e 2e 2f ....../../../../

2e 2e 2f 62 69 6e 2f 73 68 00 00 00 00 00 04 1e ../bin/sh.......

<snip>

 

이를 분리하고 각 필드를 설명하고 이 악용을 포착하기 위한 규칙을 작성하는 방법을 알아봄.

RPC 와 관련하여 몇 가지 주의 할 사항이 있음 :

• 숫자는 4 바이트를 사용하는 uint32s 로 작성됨. 숫자 26 은 0x0000001a로 표시됨.

• 문자열은 문자열, 문자열의 길이를 지정하는 uint32 로 작성되고 4 바이트 경계에서 끝나도록 문자열 길이를 채우는 null 바이트가 있음. 문자열 "bob" 은 0x00000003626f6200 으로 표시됨.

 

89 09 9c e2 - the request id, a random uint32, unique to each request

00 00 00 00 - rpc type (call = 0, response = 1)

00 00 00 02 - rpc version (2)

00 01 87 88 - rpc program (0x00018788 = 100232 = sadmind)

00 00 00 0a - rpc program version (0x0000000a = 10)

00 00 00 01 - rpc procedure (0x00000001 = 1)

00 00 00 01 - credential flavor (1 = auth\_unix)

00 00 00 20 - length of auth\_unix data (0x20 = 32

 

## the next 32 bytes are the auth\_unix data

40 28 3a 10 - unix timestamp (0x40283a10 = 1076378128 = feb 10 01:55:28 2004 gmt)

00 00 00 0a - length of the client machine name (0x0a = 10)

4d 45 54 41 53 50 4c 4f 49 54 00 00 - metasploit

00 00 00 00 - uid of requesting user (0)

00 00 00 00 - gid of requesting user (0)

00 00 00 00 - extra group ids (0)

00 00 00 00 - verifier flavor (0 = auth\_null, aka none)

00 00 00 00 - length of verifier (0, aka none)

 

나머지 패킷은 sadmind 의 프로시저 1 로 전달되는 요청임.

그러나 취약점은 sadmind 가 클라이언트에서 오는 uid 를 신뢰한다는 것임.

sadmind 는 클라이언트의 uid 가 0 인 요청을 root 로 실행함.

따라서 규칙을 작성하기 위해 요청을 충분히 디코딩했음.

먼저 패킷이 RPC 호출인지 확인해야 함.

 

content:"|00 00 00 00|"; offset:4; depth:4;

 

그런 다음 패킷이 sadmind 에 대한 호출인지 확인해야 함.

 

content:"|00 01 87 88|"; offset:12; depth:4;

 

그런 다음 패킷이 취약한 절차 1 에 대한 호출인지 확인해야 함.

 

content:"|00 00 00 01|"; offset:20; depth:4;

 

그런 다음 패킷에 인증 유닉스 자격 증명이 있는지 확인해야 함.

 

content:"|00 00 00 01|"; offset:24; depth:4;

 

호스트 이름은 신경 쓰지 않지만 건너 뛰고 호스트 이름 뒤의 숫자 값을 확인하려고 함.

이것은 byte_test 가 유용한 곳임.

호스트 이름의 길이에서 시작하는 데이터는 다음과 같음 :

 

00 00 00 0a 4d 45 54 41 53 50 4c 4f 49 54 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00

 

우리는 4 바이트를 읽고 이를 숫자로 바꾸고 그 만큼의 바이트를 앞으로 점프하여 RPC 가 문자열에 요구하는 패딩을 고려함.

그렇게 한다면 우리는 다음과 같은 위치에 있음 :

 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00

 

이는 우리가 확인하려는 값인 uid 의 정확한 위치임.

영어로 우리는 패킷 시작 부분에서 4 바이트, 36 바이트를 읽고 4 바이트를 정수로 바꾸고 4 바이트 경계에 맞춰 해당 바이트를 앞으로 점프하려고 함.

Snort 규칙에서 이를 수행하기 위해 다음을 사용함 :

 

byte_jump:4,36,align;

 

그런 다음 uid 0을 찾고 싶음.

 

content:"|00 00 00 00|"; within:4;

 

이제 규칙에 대한 모든 검색 기능을 갖추었으므로 모두 통합해봄.

 

content:"|00 00 00 00|"; offset:4; depth:4;

content:"|00 01 87 88|"; offset:12; depth:4;

content:"|00 00 00 01|"; offset:20; depth:4;

content:"|00 00 00 01|"; offset:24; depth:4;

byte_jump:4,36,align;

content:"|00 00 00 00|"; within:4;

 

세 번째와 네 번째 문자열 일치는 바로 옆에 있으므로 이러한 패턴을 결합해야 함.

우리는 다음과 같이 끝남.

 

content:"|00 00 00 00|"; offset:4; depth:4;

content:"|00 01 87 88|"; offset:12; depth:4;

content:"|00 00 00 01 00 00 00 01|"; offset:20; depth:8;

byte_jump:4,36,align;

content:"|00 00 00 00|"; within:4;

 

sadmind 서비스가 클라이언트의 호스트 이름을 읽을 때 버퍼 오버플로우에 취약한 경우 호스트 이름의 길이를 읽고 그만큼 앞으로 이동하는 대신 호스트 이름의 길이가 너무 크지 않은지 확인함.

이를 위해 36 바이트에서 시작하여 4 바이트를 패킷으로 읽어서 숫자로 변환한 다음 너무 크지 않은지 확인함. (200 바이트보다 크지 않은 경우)

Snort에서는 다음을 수행함 :

 

byte_test:4,>,200,36;

 

우리의 전체 규칙은 다음과 같음.

 

content:"|00 00 00 00|"; offset:4; depth:4;

content:"|00 01 87 88|"; offset:12; depth:4;

content:"|00 00 00 01 00 00 00 01|"; offset:20; depth:8;

byte_test:4,>,200,36;