flowbits chaning

트래픽에서 일반적인 패턴 기반은 손쉽게 문자열을 통해서 행위나 응용프로그램을 식별할 수 있다. 하지만, 암호화된 트래픽에서는 특정 문자열을 찾아내는 것이 불가능하다. 이때 패킷들의 특정 사이즈를 엮어 탐지의 방법으로 사용할 수 있다. 아래 룰들은 RDP over SSH를 탐지하는 룰 셋의 일부이다.

 

snort는 dsize 범위 지정 ( <> )이 inclusive이지만, suricata는 exclusive로 동작한다.

 

alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) set"; flow:established,to_server; dsize:96; prefilter; flowbits:isnotset,rostr; flowbits:set,rostr1; noalert; sid:10; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning1"; flow:established,to_server; flowbits:isset,rostr1; dsize:304; prefilter; flowbits:unset,rostr1; flowbits:set,rostr2; noalert; sid:9; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning1 flush"; flow:established,to_server; flowbits:isset,rostr1; dsize:>304; prefilter; flowbits:unset,rostr1; noalert; sid:8; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning1 flush"; flow:established,to_server; flowbits:isset,rostr1; dsize:0<>304; prefilter; flowbits:unset,rostr1; noalert; sid:7; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning2"; flow:established,to_server; flowbits:isset,rostr2; dsize:400; prefilter; flowbits:unset,rostr2; flowbits:set,rostr3; noalert; sid:6; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning2 flush"; flow:established,to_server; flowbits:isset,rostr2; dsize:>400; prefilter; flowbits:unset,rostr2; noalert; sid:5; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning2 flush"; flow:established,to_server; flowbits:isset,rostr2; dsize:0<>400; prefilter; flowbits:unset,rostr2; noalert; sid:4; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning3"; flow:established,to_server; flowbits:isset,rostr3; dsize:192; prefilter; stream_size:client,<,11500; flowbits:unset,rostr3; flowbits:set,rostr4; noalert; sid:3; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning3 flush"; flow:established,to_server; flowbits:isset,rostr3; dsize:>192; prefilter; flowbits:unset,rostr3; noalert; sid:2; )
alert tcp-pkt any any -> any 22 (msg:"RDP over SSH (Reverse) chaning3 flush"; flow:established,to_server; flowbits:isset,rostr3; dsize:0<>192; prefilter; flowbits:unset,rostr3; noalert; sid:1; )

10개의 시그니처에 대한 설명은 다음과 같다:

목적지 포트가 22인 패킷 중 TCP 페이로드가 96인 패킷을 탐지하고 flowbits:set,rostr1을 지정한다.

flowbits:isset,rostr1 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 304인 패킷을 탐지하고 flowbits:unset,rostr1를 해제하고 flowbits:set,rostr2를 지정한다.

flowbits:isset,rostr1 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 304보다 큰 패킷을 탐지하고 flowbits:unset,rostr1를 해제한다.

flowbits:isset,rostr1 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 0보다 크고 304보다 작은 패킷을 탐지하고 flowbits:unset,rostr1를 해제한다.

flowbits:isset,rostr2 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 400인 패킷을 탐지하고 flowbits:unset,rostr1를 해제하고 flowbits:set,rostr2를 지정한다.

flowbits:isset,rostr2 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 400보다 큰 패킷을 탐지하고 flowbits:unset,rostr1를 해제한다.

flowbits:isset,rostr2 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 0보다 크고 400보다 작은 패킷을 탐지하고 flowbits:unset,rostr1를 해제한다.

flowbits:isset,rostr3 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 192인 패킷을 탐지하고 flowbits:unset,rostr1를 해제하고 flowbits:set,rostr2를 지정한다.

flowbits:isset,rostr3 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 192보다 큰 패킷을 탐지하고 flowbits:unset,rostr1를 해제한다.

flowbits:isset,rostr3 상황에서 목적지 포트가 22번인 패킷 중 TCP 페이로드 사이즈가 0보다 크고 192보다 작은 패킷을 탐지하고 flowbits:unset,rostr1를 해제한다.

 

또한 10개의 시그니처는 sid가 10에서 1로 내림차순 적용된다. 이는 시그니처가 ordering으로 인하여 발생하는 문제를 처리하기 위함이다.

그림 1. sid 순서에 따른 탐지 차이

룰 셋의 sid가 그림1의 ASC처럼 오름차순으로 적용되었을 경우, 의도한 "dsize 기반 체인"이 아닌 오탐이 발생하거나 체인의 연속성이 깨지게 된다. 세그먼트 2가 chaning2에서 식별된 이후 chaning3은 세그먼트3에서 식별되거나 다른 사이즈로 chaning3 flush가 트리거되야 한다. 하지만 오름차순 상황에서는 세그먼트 2에서 chaning2가 식별되고 연속해서 chaning3 flush가 트리거 되어 의도한 체인이 아닌것으로 판정된다. 이는 동일한 우선순위를 부여받은 상황에서 chaning2의 sid가 chaning3 flush의 sid보다 우선적으로 (ex. chaning2/sid:2, chaning flush/sid:3) 식별되기 때문이다.
그림 1의 DESC에서는 처음에 제공된 룰셋과 같이 sid 적용을 반대로 적용한 상황을 보여준다. chaning2의 sid가 chaning3 flush보다 식별 순위가 낮기 때문에 식별하고자 했던 트래픽이라면 체인이 정상적으로 동작한다. 

그림 2. priority 키워드 사용에 따른 우선순위 조정

만약 sid를 임의로 조정할 수 없는 경우에는 priority 키워드를 사용하여 우선순의를 강제로 조정할 수 있다. priority 키워드는 snort, suricata 모두 지원하나 우선순위에 영향을 가하는 동작은 suricata에서만 가능하다.

그림2에서 changing2에 해당하는 시그니처에 priority:4를 적용시켜 changing3 flush 시그니처보다 우선순위를 강제로 낮게 할당하여 chaning이 동작할 수 있도록 한다. priority는 flush가 아닌 일반 시그니처에만 적용되어야 한다. 오름차순 상황에서는 flush 룰이 낮은 우선순위를 적용받으면 적용을 안 한 것과 동일하다. 그러나 별도의 지정이 필요하고 시그니처가 길어짐에 따라 sid를 내림차순 정렬하여 priority 없이 처리될 수 있도록 할 수 있다.

이외에도 chaning 구조는 추가적으로 고려해야 할 문제를 가지고 있다.
  
1. Signature ordering의 문제

 

가장 첫 번째 시그니처에는 무의미한 flowbits:isnotset이 존재한다. 이는 sid와 별개로 시그니처 ordering에 대한 문제를 해결하기 위해 사용되는 요소이다. sid는 부여된 값에 따라 동일한 우선순위에서 식별순서가 적용이 된다. 하지만 전체적인 ordering관점에서는단순히 sid 뿐만 아니라 여러 조건으로 인해 적용된다. 첫 번째 시그니처에서 flowbits:isnotset이 적용되지 않으면 첫 번째 시그니처는 chaning1과 chaning1 flush보다 우선적으로 탐지된다. flowbits는 "flowbits SET(set, unset)"이 "flowbits SET & flowbits READ (isset, isnotset)"보다 우선순위가 높기 때문에 priority는 sid를 제외한 동일 조건에서의 우선순위를 조정하는 것으로 flowbits에 대한 조정은 불가능하다. 첫 번째 시그니처의 flowbits:isset의 역할은 chaning1과 동일하게 flowbits SET & READ 상태로 만드는 역할을 한다.

그러나 첫 번째 시그니처와 두 번째 시그니처간의 방향성이 다른 경우에는 이 사항은 적용되지 않는다.

2. 확인된 룰의 flowbits:unset

chaning에서 확인된 시그니처는 잘못된 탐지를 초래하지 않도록 flowbits:unset을 통해서 바로 해제를 해주어야 한다.

그림 3. flowbits:unset의 필요