Bug #1190
closedhttp_header keyword not matching when SYN|ACK and ACK missing
Description
When using async-oneside and midstream, the http_header keyword does not function in some cases. Example rules:
alert http any any -> any any (msg:"Test 1 Sinkhole HTTP Response - Content only"; content:"X-Sinkhole|3a| "; sid:1;)
alert http any any -> any any (msg:"Test 2 Sinkhole HTTP Response - Content and http_header"; content:"X-Sinkhole|3a| "; http_header; sid:2;)
Test cases:
- Full TCP handshake + HTTP GET + HTTP response - both rules trigger
1 0.000000 192.168.0.33 -> 10.0.0.77 TCP 74 33382 > 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1250203509 TSecr=0 WS=128
2 0.022648 10.0.0.77 -> 192.168.0.33 TCP 74 80 > 33382 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1440 SACK_PERM=1 TSval=622145469 TSecr=1250203509 WS=256
3 0.022680 192.168.0.33 -> 10.0.0.77 TCP 66 33382 > 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1250203515 TSecr=622145469
4 0.022831 192.168.0.33 -> 10.0.0.77 HTTP 178 GET / HTTP/1.1
5 0.045884 10.0.0.77 -> 192.168.0.33 TCP 66 80 > 33382 [ACK] Seq=1 Ack=113 Win=14592 Len=0 TSval=622145474 TSecr=1250203515
6 0.047133 10.0.0.77 -> 192.168.0.33 HTTP 365 HTTP/1.1 302 Found
- SYN|ACK from server missing - both rules trigger
1 0.000000 192.168.0.33 -> 10.0.0.77 TCP 74 33382 > 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1250203509 TSecr=0 WS=128
2 0.022680 192.168.0.33 -> 10.0.0.77 TCP 66 33382 > 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1250203515 TSecr=622145469
3 0.022831 192.168.0.33 -> 10.0.0.77 HTTP 178 GET / HTTP/1.1
4 0.045884 10.0.0.77 -> 192.168.0.33 TCP 66 80 > 33382 [ACK] Seq=1 Ack=113 Win=57 Len=0 TSval=622145474 TSecr=1250203515
5 0.047133 10.0.0.77 -> 192.168.0.33 HTTP 365 HTTP/1.1 302 Found
- SYN|ACK from server and ACK from client missing - the content rule triggers, but the http_header rule does not trigger
1 0.000000 192.168.0.33 -> 10.0.0.77 TCP 74 33382 > 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1250203509 TSecr=0 WS=128
2 0.022831 192.168.0.33 -> 10.0.0.77 HTTP 178 GET / HTTP/1.1
3 0.045884 10.0.0.77 -> 192.168.0.33 TCP 66 80 > 33382 [ACK] Seq=1 Ack=113 Win=57 Len=0 TSval=622145474 TSecr=1250203515
4 0.047133 10.0.0.77 -> 192.168.0.33 HTTP 365 HTTP/1.1 302 Found
- Full handshake missing - both rules trigger
1 0.000000 192.168.0.33 -> 10.0.0.77 HTTP 178 GET / HTTP/1.1
2 0.023053 10.0.0.77 -> 192.168.0.33 TCP 66 80 > 33382 [ACK] Seq=1 Ack=113 Win=57 Len=0 TSval=622145474 TSecr=1250203515
3 0.024302 10.0.0.77 -> 192.168.0.33 HTTP 365 HTTP/1.1 302 Found
- SYN missing - neither rule triggers - this is perhaps a second bug
1 0.000000 10.0.0.77 -> 192.168.0.33 TCP 74 80 > 33382 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1440 SACK_PERM=1 TSval=622145469 TSecr=1250203509 WS=256
2 0.000032 192.168.0.33 -> 10.0.0.77 TCP 66 33382 > 80 [ACK] Seq=1 Ack=1 Win=229 Len=0 TSval=1250203515 TSecr=622145469
3 0.000183 192.168.0.33 -> 10.0.0.77 HTTP 178 GET / HTTP/1.1
4 0.023236 10.0.0.77 -> 192.168.0.33 TCP 66 80 > 33382 [ACK] Seq=1 Ack=113 Win=14592 Len=0 TSval=622145474 TSecr=1250203515
5 0.024485 10.0.0.77 -> 192.168.0.33 HTTP 365 HTTP/1.1 302 Found
With only the SYN missing, two stream event rules trigger:
05/07/2014-11:26:55.414347 [**] [1:2210029:2] SURICATA STREAM ESTABLISHED invalid ack [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.0.0.77:80 -> 192.168.0.33:33382
05/07/2014-11:26:55.414347 [**] [1:2210045:2] SURICATA STREAM Packet with invalid ack [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.0.0.77:80 -> 192.168.0.33:33382
Files
Updated by Victor Julien over 10 years ago
Did you try the git master? I did some fixes in there after the 2.0 release.
Updated by Matt Carothers about 10 years ago
Sorry Victor, I totally missed your reply. I tested again today from git, and the bug still exists.
Updated by Matt Carothers about 10 years ago
- File x-sinkhole-full-anon-missing-syn-ack-and-ack.pcap x-sinkhole-full-anon-missing-syn-ack-and-ack.pcap added
I could have sworn I attached a pcap to the original report. This pcap should trigger both rules, but it only triggers the first.
Updated by Victor Julien about 10 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 2.0.5
Updated by Victor Julien about 10 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Fixed through https://github.com/inliniac/suricata/pull/1192, thanks Matt!
Updated by Matt Carothers about 10 years ago
- File test-matrix.png test-matrix.png added
- File test-SYN_ACK.pcap test-SYN_ACK.pcap added
- File test-SYN_ACK-ACK.pcap test-SYN_ACK-ACK.pcap added
Thanks, Victor. The latest version from git now functions correctly for the case of the missing SYN|ACK and ACK. The missing SYN case still doesn't work, however. I went ahead and tested all 8 permutations. I've attached the test matrix and two pcap files that don't generate any hits with the two rules above.
Updated by Victor Julien about 10 years ago
Both those cases now also work in https://github.com/inliniac/suricata/pull/1194