Project

General

Profile

Actions

Bug #708

closed

Flow vars issue in pcap file mode

Added by Eric Leblond over 11 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

The following signatures should allow to detect non HTTP traffic on port 80:

alert http any any -> any any (msg: "Set flag_http"; \
flowbits: set, flag_http;\
noalert; \
sid:6; rev:1;)
#
alert tcp any any -> any 80 (msg: "Increment flag"; \
flowint: cnt, +, 1; \
flowbits: isnotset, flag_http; \
noalert; \
sid: 7; rev:1;)
#
alert tcp any any -> any 80 (msg: "Non HTTP on port 80"; \
flowint: cnt, >, 5; \
flowbits: isnotset, flag_http; \
flowbits: set, flag_http;\
sid: 8; rev:1;)

On some systems (FC14 dual core) this is not working correctly with alert firing for both attached files.
This should not alert:

suricata -S not-http-port-80.rules -r 80-http.pcap

This should alert once:

suricata -S not-http-port-80.rules -r 80-no-http.pcap

On the faulty systems, switching to runmode single by adding --runmode=single on command line fixes the issue.


Files

80-http.pcap (244 KB) 80-http.pcap Eric Leblond, 01/12/2013 05:14 AM
80-no-http.pcap (1.04 KB) 80-no-http.pcap Eric Leblond, 01/12/2013 05:14 AM
not-http-port-80.rules (405 Bytes) not-http-port-80.rules Eric Leblond, 01/12/2013 05:14 AM
Actions #1

Updated by Anoop Saldanha over 11 years ago

  • Assignee set to Anoop Saldanha
Actions #2

Updated by Anoop Saldanha over 11 years ago

would the above set of rules work? As in sig 7 will be run for every packet heading in the port 80 direction, which means all the syn retransmissions as well, which is why you are seeing alerts for 80-http.pcap as well. You can see a fair bit of FPs.

Unable to reproduce the single vs autofp thing you are noticing. See an alert. I have an update to the engine, which might be a fix, but single vs autofp in this case should virtually be the same thing. Let me check in some detail next.

On an unrelated note, we should probably support

alert !<protocol> ....

which should be more reliable.

Actions #3

Updated by Anoop Saldanha over 11 years ago

unable to reproduce single vs autofp thing.

Btw, a feature update patch related to the code corresponding to the bug(but not related to the bug itself).

https://github.com/inliniac/suricata/pull/253

Actions #4

Updated by Victor Julien over 10 years ago

  • Target version set to TBD
Actions #5

Updated by Andreas Herz over 7 years ago

I can reproduce it but in the first case I receive

6/9/2016 -- 23:57:31 - <Warning> - [ERRCODE: SC_ERR_INVALID_CHECKSUM(11)] - 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.

So when I start it with "-k none" the alert won't trigger. So still a bug or working as expected in that case?

Actions #6

Updated by Andreas Herz over 7 years ago

  • Assignee changed from Anoop Saldanha to OISF Dev
Actions #7

Updated by Victor Julien almost 6 years ago

Without -k none the stream engine rejects the packets and packets are inspected differently. In the normal case they are inspected after reassembly, so a bit later.

Actions #8

Updated by Andreas Herz almost 5 years ago

So with -k none the alert should trigger, right?

Actions #9

Updated by Philippe Antoine 9 months ago

  • Status changed from New to Closed

The official way to do this is alert tcp any any -> any 80 (msg:"non-HTTP traffic over HTTP standard port"; flow:to_server; app-layer-protocol:!http; sid:1;) as tested by S-V test detect-app-layer-protocol-01

Actions

Also available in: Atom PDF