Bug #992
closedDifferent alerts reported when reading from pcap file with runmode=single and runmode=autofp
Description
When running suricata processing a pcap file, I see different alerts between runmode=autofp and runmode=single.
Some of the differences could be thresholds, but for sid:2221010, which have apps-layer-event, but no thresholds, I still see differences.
The attached script runs suricata on a specific pcap file with a specified runmode. To run the two cases, I do:
./test-one-file LL1999_Week1_Tue_inside.pcap single
./test-one-file LL1999_Week1_Tue_inside.pcap autofp
Comparing the results, there are different number of alerts for sid:2221010
grep 1:2221010:1 single-results/LL1999_Week1_Tue_inside.sorted | wc -l
4694
ken@lab-39:~/test-suricata$ grep 1:2221010:1 autofp-results/LL1999_Week1_Tue_inside.sorted | wc -l
4373
Test pcap file: http://www.ll.mit.edu/mission/communications/cyber/CSTcorpora/ideval/data/1999/training/week1/tuesday/inside.tcpdump.gz
git version: c1190545cfb1d06037847b94620591d2be6f3c07
$ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/suricata --build-info
This is Suricata version 2.0dev (rev c119054)
Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK
64-bits, Little-endian architecture
GCC version 4.6.3, C version 199901
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
compiled with -fstack-protector
compiled with _FORTIFY_SOURCE=2
L1 cache line size (CLS)=64
compiled with LibHTP v0.5.7, linked against LibHTP v0.5.7
Suricata Configuration:
AF_PACKET support: yes
PF_RING support: no
NFQueue support: no
IPFW support: no
DAG enabled: no
Napatech enabled: no
Unix socket enabled: no
libnss support: no
libnspr support: no
libjansson support: no
Prelude support: no
PCRE jit: no
libluajit: no
libgeoip: no
Non-bundled htp: no
Old barnyard2 support: no
CUDA enabled: no
Suricatasc install: yes
Unit tests enabled: no
Debug output enabled: no
Debug validation enabled: no
Profiling enabled: no
Profiling locks enabled: no
Generic build parameters:
Installation prefix (--prefix): /usr/local
Configuration directory (--sysconfdir): /usr/local/etc/suricata/
Log directory (--localstatedir) : /usr/local/var/log/suricata/
Host: x86_64-unknown-linux-gnu
GCC binary: gcc
GCC Protect enabled: no
GCC march native enabled: yes
GCC Profile enabled: no
CPU (12 cores 2 threads/core):
processor : 23
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
stepping : 2
microcode : 0xc
cpu MHz : 2793.017
Files
Updated by Ken Steele about 11 years ago
- File autofp-6732-10298.sorted autofp-6732-10298.sorted added
- File compare-results compare-results added
- File LLS_DDOS_2.0.2-inside.pcap.xz LLS_DDOS_2.0.2-inside.pcap.xz added
- File LLS-208.209.46.47.pcap LLS-208.209.46.47.pcap added
- File LLS-6732.pcap LLS-6732.pcap added
- File LLS-6732-10298.pcap LLS-6732-10298.pcap added
- File LLS-10298.pcap LLS-10298.pcap added
- File LLS-not-10298.pcap LLS-not-10298.pcap added
- File single-6732-10298.sorted single-6732-10298.sorted added
- File suricata.yaml suricata.yaml added
I have a smaller testcase that shows the different alerts generated when reading the same pcap file with runmode single and runmode autofp. Additional alerts are output in single runmode (see the difference between single-6732-10298.sorted and autofp-6732-10298.sorted).
To run the testcases, install suricata in /usr/local/bin (default location) and run:
./test-one-file LLS-6732-10298.pcap single
./test-one-file LLS-6732-10298.pcap autofp
This generates two directories: single-results and autofp-results, that contain LLS-6732-10298.fast and LLS-6732-10298.sorted (strip off time-stamps from .fast and sort).
The files LLS-6732-10298.pcap were created from Lincoln Labs 1999 DDOS file by selecting the two flows between IPs 208.209.46.37 and 172.16.115.87 with ports 6732 and ports 10298. The other LLS- files are similar, with different subsets of ports.
Most interesting, LLS-6732.pcap by itself generates the same alerts in single and autofp, as does LLS-10298.pcap, only putting both flows in the same pcap file causes the problem. Note, flow 10298 comes after flow 6732 in the pcap files. I have not tried reordering the pcap files.
File LLS-208.209.46.37.pcap contains all the flows between IPs 208.209.46.37 and 172.16.115.87 and LLS-not-10298.pcap is the same except removing flow with port 10298. The former gives different alerts, the latter the same alerts.
This testing requires the patch to disable Detect Keywors by adding testing.detect config in suricata.yaml (see attached file).
Updated by Ken Steele about 11 years ago
Needs PR: https://github.com/inliniac/suricata/pull/594 to disable Detect keywords.
Updated by Anoop Saldanha about 11 years ago
From the top of my head one of the reasons for the difference is alerts might be timing. When you process a pcap the global time used to track flows comes from the packet timestamps, i.e. for every packet we update the global time based on the packet timestamp. When you combine pcaps this can result in rubbish timestamp updates inside the engine, which in turn can result in flows getting culled sooner or at wrong intervals.
Updated by Anoop Saldanha about 11 years ago
- Assignee set to Anoop Saldanha
- Target version set to 2.0beta2
Updated by Ken Steele about 11 years ago
These files are generated by removing packets from the original file, not combining pcap files.
The reason for disabling the keywords was to remove the affects of threshold timing, but yes, there could be other timing factors.
Another option I have investigated is defining a pcap file replay "rate", for example 25,000 packets/second. If that also updated the global time, then it might be more consistent.
Updated by Anoop Saldanha about 11 years ago
Ken Steele wrote:
These files are generated by removing packets from the original file, not combining pcap files.
Doesn't matter how you obtained the files. End of the day pcap file mode can introduce this issue, and combining flows from various timestamp ranges can worsen this behaviour.
The reason for disabling the keywords was to remove the affects of threshold timing, but yes, there could be other timing factors.
Yes, there are, like the one I just explained.
Another option I have investigated is defining a pcap file replay "rate", for example 25,000 packets/second. If that also updated the global time, then it might be more consistent.
Live mode shouldn't see any of the flow timing issue I suggested, afai can see, although this doesn't mean this issue can't exist.
To exemplify the issue, you can modify your conf file to use some high timeout values and see if that changes the alert nos - autofp and single, alike.
default:
new: 4294967295
established: 4294967295
closed: 4294967295
emergency-new: 4294967295
emergency-established: 4294967295
emergency-closed: 4294967295
tcp:
new: 4294967295
established: 4294967295
closed: 4294967295
emergency-new: 4294967295
emergency-established: 4294967295
emergency-closed: 4294967295
udp:
new: 4294967295
established: 4294967295
emergency-new: 4294967295
emergency-established: 4294967295
icmp:
new: 4294967295
established: 4294967295
emergency-new: 4294967295
emergency-established: 4294967295
1. Run single mode multiple times. Do you get the same no of alerts for every run?
2. Run autofp mode multiple times. Do you get the same no of alerts for every run?
3. Do the nos from (1) match the nos from (2). Has the difference/margin between the 2 increased/decreased?
Updated by Victor Julien almost 11 years ago
- Target version changed from 2.0beta2 to TBD
Updated by Andreas Herz about 8 years ago
- Assignee changed from Anoop Saldanha to OISF Dev
Updated by Andreas Herz over 5 years ago
- Status changed from New to Closed
Hi, we're closing this issue since there have been no further responses.
If you think this bug is still relevant, try to test it again with the
most recent version of suricata and reopen the issue. If you want to
improve the bug report please take a look at
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Reporting_Bugs