[prev in list] [next in list] [prev in thread] [next in thread]
List: oisf-devel
Subject: [Oisf-devel] Suricata and HTTP reassembly
From: David.R.Wharton () regions ! com
Date: 2011-08-31 21:33:28
Message-ID: OFB6B3B51A.BC77178F-ON862578FD.00738461-862578FD.00766BEC () corp ! rgbk ! com
[Download RAW message or body]
This is a multipart message in MIME format.
This is a multipart message in MIME format.
--=_alternative 00766BEA862578FD_=
Content-Type: text/plain; charset="US-ASCII"
I am having issues with Suricata alerting when the data that needs to be
inspected spans multiple packets. I have been testing this with HTTP
traffic but it may apply to other application protocols as well if there
is a reassembly issue lower on the network stack.
Basically I have a rule that has a content match and a negated content
match. For example: content:"string1"; content:!"string2". If both
string1 and string2 are present, the rule should not alert because string2
is negated. This works as expected if string1 and string2 are in the same
packet. However, if the packet is split and string1 is in the first
packet and string2 in the second, the rule alerts because it does not
inspect the second packet for the negated content match even though it is
part of the same TCP/HTTP stream.
Are there HTTP reassembly issues or configurations that I don't know
about?
--------------------------
>From my .yaml config file:
# trying to compensate for a 1 off issue with PF_RING and/or VLAN tags but
not sure if it really helps
default-packet-size: 1522
defrag:
max-frags: 65535
prealloc: yes
timeout: 60
#flow settings:
flow:
memcap: 33554432
hash_size: 65536
prealloc: 10000
emergency_recovery: 30
prune_flows: 5
#stream engine settings:
stream:
memcap: 33554432 # 32mb
checksum_validation: yes # reject wrong csums
inline: no # no inline mode
reassembly:
memcap: 67108864 # 64mb for reassembly
depth: 1048576 # reassemble 1mb into a stream
toserver_chunk_size: 2560
toclient_chunk_size: 2560
# Configure libhtp.
libhtp:
default-config:
personality: IDS
request_body_limit: 3072
server-config:
- apache:
address: [192.168.1.0/24, 127.0.0.0/8, "::1"]
personality: Apache_2_2
request_body_limit: 4096
- iis7:
address:
- 192.168.0.0/24
- 192.168.10.0/24
- 172.16.0.0/12
personality: IIS_7_0
request_body_limit: 4096
--------------------------
>From alert-debug.log when this rules fires (when it shouldn't) b/c data is
spread among two packets:
PROTO: 6
SRC PORT: 9289
DST PORT: 8080
TCP SEQ: 760758486
TCP ACK: 3466528788
FLOW: to_server: TRUE, to_client: FALSE
FLOW Start TS: 08/30/2011-02:02:51.302354
FLOW IPONLY SET: TOSERVER: TRUE, TOCLIENT: TRUE
FLOW ACTION: DROP: FALSE, PASS FALSE
FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: FALSE
FLOW APP_LAYER: DETECTED: TRUE, PROTO 1
PACKET LEN: 608
PAYLOAD LEN: 554
--------------------------
This is a HTTP POST and the HTTP headers in the first packet have
"Content-Length: 63" and all the POST data is in the second packet.
I would provide the rule and pcap I'm replaying thru Suricata to test this
but it has sensitive data I can't share. Thanks for any help.
-David
--=_alternative 00766BEA862578FD_=
Content-Type: text/html; charset="US-ASCII"
<font size=2 face="sans-serif">I am having issues with Suricata alerting
when the data that needs to be inspected spans multiple packets. I
have been testing this with HTTP traffic but it may apply to other application
protocols as well if there is a reassembly issue lower on the network stack.</font>
<br>
<br><font size=2 face="sans-serif">Basically I have a rule that has a content
match and a negated content match. For example: content:"string1";
content:!"string2". If both string1 and string2 are present,
the rule should not alert because string2 is negated. This works
as expected if string1 and string2 are in the same packet. However,
if the packet is split and string1 is in the first packet and string2 in
the second, the rule alerts because it does not inspect the second packet
for the negated content match even though it is part of the same TCP/HTTP
stream.</font>
<br>
<br><font size=2 face="sans-serif">Are there HTTP reassembly issues or
configurations that I don't know about?</font>
<br>
<br><font size=2 face="sans-serif">--------------------------</font>
<br><font size=2 face="sans-serif">From my .yaml config file:</font>
<br>
<br><font size=2 face="sans-serif"># trying to compensate for a 1 off issue
with PF_RING and/or VLAN tags but not sure if it really helps</font>
<br><font size=2 face="sans-serif">default-packet-size: 1522</font>
<br>
<br><font size=2 face="sans-serif">defrag:</font>
<br><font size=2 face="sans-serif"> max-frags: 65535</font>
<br><font size=2 face="sans-serif"> prealloc: yes</font>
<br><font size=2 face="sans-serif"> timeout: 60</font>
<br>
<br><font size=2 face="sans-serif">#flow settings:</font>
<br><font size=2 face="sans-serif">flow:</font>
<br><font size=2 face="sans-serif"> memcap: 33554432</font>
<br><font size=2 face="sans-serif"> hash_size: 65536</font>
<br><font size=2 face="sans-serif"> prealloc: 10000</font>
<br><font size=2 face="sans-serif"> emergency_recovery: 30</font>
<br><font size=2 face="sans-serif"> prune_flows: 5</font>
<br>
<br><font size=2 face="sans-serif">#stream engine settings:</font>
<br><font size=2 face="sans-serif">stream:</font>
<br><font size=2 face="sans-serif"> memcap: 33554432
# 32mb</font>
<br><font size=2 face="sans-serif"> checksum_validation: yes
# reject wrong csums</font>
<br><font size=2 face="sans-serif"> inline: no
# no inline mode</font>
<br><font size=2 face="sans-serif"> reassembly:</font>
<br><font size=2 face="sans-serif"> memcap: 67108864
# 64mb for reassembly</font>
<br><font size=2 face="sans-serif"> depth: 1048576
# reassemble 1mb into a stream</font>
<br><font size=2 face="sans-serif"> toserver_chunk_size: 2560</font>
<br><font size=2 face="sans-serif"> toclient_chunk_size: 2560</font>
<br>
<br><font size=2 face="sans-serif"># Configure libhtp.</font>
<br><font size=2 face="sans-serif">libhtp:</font>
<br>
<br><font size=2 face="sans-serif"> default-config:</font>
<br><font size=2 face="sans-serif"> personality: IDS</font>
<br><font size=2 face="sans-serif"> request_body_limit:
3072</font>
<br>
<br><font size=2 face="sans-serif"> server-config:</font>
<br>
<br><font size=2 face="sans-serif"> - apache:</font>
<br><font size=2 face="sans-serif"> address:
[192.168.1.0/24, 127.0.0.0/8, "::1"]</font>
<br><font size=2 face="sans-serif"> personality:
Apache_2_2</font>
<br><font size=2 face="sans-serif"> request_body_limit:
4096</font>
<br>
<br><font size=2 face="sans-serif"> - iis7:</font>
<br><font size=2 face="sans-serif"> address:</font>
<br><font size=2 face="sans-serif"> -
192.168.0.0/24</font>
<br><font size=2 face="sans-serif"> -
192.168.10.0/24</font>
<br><font size=2 face="sans-serif"> -
172.16.0.0/12</font>
<br><font size=2 face="sans-serif"> personality:
IIS_7_0</font>
<br><font size=2 face="sans-serif"> request_body_limit:
4096</font>
<br>
<br><font size=2 face="sans-serif">--------------------------</font>
<br><font size=2 face="sans-serif">From alert-debug.log when this rules
fires (when it shouldn't) b/c data is spread among two packets:</font>
<br>
<br><font size=2 face="sans-serif">PROTO:
6</font>
<br><font size=2 face="sans-serif">SRC PORT:
9289</font>
<br><font size=2 face="sans-serif">DST PORT:
8080</font>
<br><font size=2 face="sans-serif">TCP SEQ:
760758486</font>
<br><font size=2 face="sans-serif">TCP ACK:
3466528788</font>
<br><font size=2 face="sans-serif">FLOW:
to_server: TRUE, to_client: FALSE</font>
<br><font size=2 face="sans-serif">FLOW Start TS: 08/30/2011-02:02:51.302354</font>
<br><font size=2 face="sans-serif">FLOW IPONLY SET: TOSERVER: TRUE,
TOCLIENT: TRUE</font>
<br><font size=2 face="sans-serif">FLOW ACTION: DROP:
FALSE, PASS FALSE</font>
<br><font size=2 face="sans-serif">FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD:
FALSE, APP_LAYER: FALSE</font>
<br><font size=2 face="sans-serif">FLOW APP_LAYER: DETECTED:
TRUE, PROTO 1</font>
<br><font size=2 face="sans-serif">PACKET LEN: 608</font>
<br>
<br><font size=2 face="sans-serif">PAYLOAD LEN: 554</font>
<br>
<br><font size=2 face="sans-serif">--------------------------</font>
<br>
<br><font size=2 face="sans-serif">This is a HTTP POST and the HTTP headers
in the first packet have "Content-Length: 63" and all the POST
data is in the second packet.</font>
<br>
<br><font size=2 face="sans-serif">I would provide the rule and pcap I'm
replaying thru Suricata to test this but it has sensitive data I can't
share. Thanks for any help.</font>
<br>
<br><font size=2 face="sans-serif">-David</font>
--=_alternative 00766BEA862578FD_=--
_______________________________________________
Oisf-devel mailing list
Oisf-devel@openinfosecfoundation.org
http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic