HTTP2에서의 flowbits 한계

Snort, Suricata는 TCP 재조합과 HTTP 파서를 제공하기 떄문에, TCP Segmentation이나 우회하는 공격을 탐지할 수 있다. 그러나 파서의 식별 처리 범위를 넘어서는 데이터 길이로 구성된 패킷 간의 탐지 또는 별도의 트랜잭션 메시지와 처럼 개별적인 패킷 간의 탐지를 위해서는 flowbits를 사용하여 chain을 구성해야 한다. 

그럼에도 불구하고 flowbits는 multiplexing을 기본적으로 지원하는 HTTP2에서는 견고한 탐지를 위해 사용하기는 어렵다.

 

HTTP2 Flow 예시

 

flowbits는 동일한 5-Tuple을 기준으로 flow를 식별하기 때문에 HTTP2 내부의 multiplexing이 존재하더라도 동일한 존재로 보일뿐이다. 사용자는 stream 2의 Header와 Data를 조건으로 하여 chain으로 묶고 싶으나 stream 3의 Header와 stream 2의 Data가 chain으로 묶일 수 있는 문제가 발생한다.

더욱이 HTTP2는 multiplexing 뿐만 아니라 Wildcard/SAN 인증서에 제공된 범위에 따라 connection-reuse를 사용하여 기존의 TLS 세션을 연속적으로 사용하는 것이 가능하기 때문에 동일한 flow에서 더 많고 유사한 패턴을 가지는 트랜잭션이 발생할 확률도 높아진다.

물론 HTTP1.x도 위와 같은 문제가 완전히 발생하지 않는다고 할 수는 없다. 하지만 HTTP1.x에서 지원하는 pipelining는 대부분의 서버에서 적용하는 case가 드물다. 또한 동일한 flow에서 여러 트랜잭션이 존재하더라도 (ex. GET -> POST)이는 트랜잭션의 종료를 식별하여 어느 정도 오탐을 완화시키거나 방지할 수 있어 flowbits의 사용이 크게 제한되지 않는다.

오픈소스 진영에서도 HTTP2 옵션을 본격적으로 지원하지 얼마 안되었기 때문에 stream 단위의 대응은 지원하지 않는다. 하지만 이미 안정권에 들어선 HTTP2는 이미 많은 사업자가 채택하여 사용하고 있으며, HTTP3 또한 멀지 않았기 때문에 stream 단위로 대응할 수 있는 개선이 필요하다고 생각한다.

 

관련 이슈

https://redmine.openinfosecfoundation.org/issues/4321