Project

General

Profile

Actions

Bug #992

closed

Different alerts reported when reading from pcap file with runmode=single and runmode=autofp

Added by Ken Steele about 9 years ago. Updated over 3 years ago.

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

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

test-one-file (657 Bytes) test-one-file Ken Steele, 10/07/2013 12:22 PM
compare-results (171 Bytes) compare-results Script to compare *.sorted in two directories (eg ./compare single-results autofp-results) Ken Steele, 10/17/2013 10:27 AM
autofp-6732-10298.sorted (269 KB) autofp-6732-10298.sorted Sorted alerts without time-stamps from reading LLS-6732-10298.pcap with runmode=autofp Ken Steele, 10/17/2013 10:27 AM
LLS-208.209.46.47.pcap (520 KB) LLS-208.209.46.47.pcap Subset of DDOS pcap for two specific IP addresses. This Fails Ken Steele, 10/17/2013 10:27 AM
LLS-6732.pcap (120 KB) LLS-6732.pcap Further subset with only one flow to port 6732. This PASSES Ken Steele, 10/17/2013 10:27 AM
LLS-6732-10298.pcap (126 KB) LLS-6732-10298.pcap subset with two flows for ports 6732 and 10298. This FAILS Ken Steele, 10/17/2013 10:27 AM
LLS-10298.pcap (5.54 KB) LLS-10298.pcap Subset with only one flow for port 10298. This PASSES Ken Steele, 10/17/2013 10:27 AM
LLS-not-10298.pcap (514 KB) LLS-not-10298.pcap Remove the flow to port 10298. This one PASSES Ken Steele, 10/17/2013 10:27 AM
single-6732-10298.sorted (271 KB) single-6732-10298.sorted Sorted alerts without time-stamps from reading LLS-6732-10298.pcap with runmode=single Ken Steele, 10/17/2013 10:27 AM
suricata.yaml (43.3 KB) suricata.yaml Conf file that disables detect keywords: tag, threshold, detect_filter and app-layer-event Ken Steele, 10/17/2013 10:27 AM
LLS_DDOS_2.0.2-inside.pcap.xz (17 MB) LLS_DDOS_2.0.2-inside.pcap.xz Original pcap file from Lincoln Labs DDOS published traces Ken Steele, 10/17/2013 10:27 AM

Updated by Ken Steele about 9 years ago

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).

Actions #2

Updated by Ken Steele about 9 years ago

Needs PR: https://github.com/inliniac/suricata/pull/594 to disable Detect keywords.

Actions #3

Updated by Anoop Saldanha about 9 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.

Actions #4

Updated by Anoop Saldanha about 9 years ago

  • Assignee set to Anoop Saldanha
  • Target version set to 2.0beta2
Actions #5

Updated by Ken Steele about 9 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.

Actions #6

Updated by Anoop Saldanha about 9 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?

Actions #7

Updated by Victor Julien almost 9 years ago

  • Target version changed from 2.0beta2 to TBD
Actions #8

Updated by Andreas Herz about 6 years ago

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

Updated by Andreas Herz over 3 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

Actions

Also available in: Atom PDF