Project

General

Profile

Actions

Bug #185

closed

Duplicate alerts when processing the following pcap for sid 498

Added by Will Metcalf almost 14 years ago. Updated almost 14 years ago.

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

Description

Seems we fire twice when processing the attached pcap when we should only fire once. Probably related to bug #183 as we log on packet that is correct and one that is not. sid 498 is part of the VRT rules that I think is actually GPL'd but better safe than sorry, so I will not include it here ;-).

src/suricata -r suricata200.pcap -s current-all.rules -l ./ -c suricata.yaml

09/21/09-13:48:50.723346 [**] [1:498:7] ATTACK-RESPONSES id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 3] {6} 82.165.50.118:80 -> 192.168.2.3:50072
09/21/09-13:48:50.869254 [**] [1:498:7] ATTACK-RESPONSES id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 3] {6} 82.165.50.118:80 -> 192.168.2.3:50072

+================
TIME: 09/21/09-13:48:50.723346
PCAP PKT NUM: 2
ALERT CNT: 1
ALERT MSG [00]: ATTACK-RESPONSES id check returned root
ALERT GID [00]: 1
ALERT SID [00]: 498
ALERT REV [00]: 7
ALERT CLASS [00]: Potentially Bad Traffic
ALERT PRIO [00]: 3
SRC IP: 82.165.50.118
DST IP: 192.168.2.3
PROTO: 6
SRC PORT: 80
DST PORT: 50072
TCP SEQ: 3949352143
TCP ACK: 3318028795
FLOW: to_server: FALSE, to_client TRUE
PACKET LEN: 62
PACKET:
0000 00 24 E8 29 FA 4F 00 04 76 D3 D8 6A 08 00 45 00 .$.).O.. v..j..E.
0010 00 30 00 00 40 00 32 06 01 02 52 A5 32 76 C0 A8 .0...2. ..R.2v..
0020 02 03 00 50 C3 98 EB 66 54 CF C5 C5 19 FB 70 12 ...P...f T.....p.
0030 16 D0 41 92 00 00 02 04 05 B4 01 03 03 07 ..A..... ......
+================
TIME: 09/21/09-13:48:50.869254
PCAP PKT NUM: 6
ALERT CNT: 1
ALERT MSG [00]: ATTACK-RESPONSES id check returned root
ALERT GID [00]: 1
ALERT SID [00]: 498
ALERT REV [00]: 7
ALERT CLASS [00]: Potentially Bad Traffic
ALERT PRIO [00]: 3
SRC IP: 82.165.50.118
DST IP: 192.168.2.3
PROTO: 6
SRC PORT: 80
DST PORT: 50072
TCP SEQ: 3949352144
TCP ACK: 3318028900
FLOW: to_server: FALSE, to_client TRUE
PACKET LEN: 363
PACKET:
0000 00 24 E8 29 FA 4F 00 04 76 D3 D8 6A 08 00 45 00 .$.).O.. v..j..E.
0010 01 5D FE 17 40 00 32 06 01 BD 52 A5 32 76 C0 A8 .]..
.2. ..R.2v..
0020 02 03 00 50 C3 98 EB 66 54 D0 C5 C5 1A 64 50 18 ...P...f T....dP.
0030 00 2E CE C9 00 00 48 54 54 50 2F 31 2E 31 20 32 ......HT TP/1.1 2
0040 30 30 20 4F 4B 0D 0A 44 61 74 65 3A 20 4D 6F 6E 00 OK..D ate: Mon
0050 2C 20 32 31 20 53 65 70 20 32 30 30 39 20 31 33 , 21 Sep 2009 13
0060 3A 34 38 3A 35 30 20 47 4D 54 0D 0A 53 65 72 76 :48:50 G MT..Serv
0070 65 72 3A 20 41 70 61 63 68 65 0D 0A 4C 61 73 74 er: Apac he..Last
0080 2D 4D 6F 64 69 66 69 65 64 3A 20 4D 6F 6E 2C 20 -Modifie d: Mon,
0090 31 35 20 4A 61 6E 20 32 30 30 37 20 32 33 3A 31 15 Jan 2 007 23:1
00A0 31 3A 35 35 20 47 4D 54 0D 0A 45 54 61 67 3A 20 1:55 GMT ..ETag:
00B0 22 39 62 33 30 36 30 37 2D 32 37 2D 34 35 61 63 "9b30607 -27-45ac
00C0 30 61 33 62 22 0D 0A 41 63 63 65 70 74 2D 52 61 0a3b"..A ccept-Ra
00D0 6E 67 65 73 3A 20 62 79 74 65 73 0D 0A 43 6F 6E nges: by tes..Con
00E0 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20 33 39 0D tent-Len gth: 39.
00F0 0A 4B 65 65 70 2D 41 6C 69 76 65 3A 20 74 69 6D .Keep-Al ive: tim
0100 65 6F 75 74 3D 32 2C 20 6D 61 78 3D 32 30 30 0D eout=2, max=200.
0110 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 .Connect ion: Kee
0120 70 2D 41 6C 69 76 65 0D 0A 43 6F 6E 74 65 6E 74 p-Alive. .Content
0130 2D 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C -Type: t ext/html
0140 0D 0A 0D 0A 75 69 64 3D 30 28 72 6F 6F 74 29 20 ....uid= 0(root)
0150 67 69 64 3D 30 28 72 6F 6F 74 29 20 67 72 6F 75 gid=0(ro ot) grou
0160 70 73 3D 30 28 72 6F 6F 74 29 0A ps=0(roo t).


Files

suricata200.pcap (1.15 KB) suricata200.pcap pcap for sid 498 www.testmyids.com Will Metcalf, 06/21/2010 08:18 PM
Actions #1

Updated by Will Metcalf almost 14 years ago

"Probably related to bug #183" should be #184 instead..

Actions #2

Updated by Victor Julien almost 14 years ago

  • Assignee changed from OISF Dev to Victor Julien

This seems to be caused by scanning the packet and the reassembled stream at separate moments thus matching twice. Working on it...

Actions #3

Updated by Victor Julien almost 14 years ago

  • Status changed from New to Closed
  • Target version changed from 0.9.3 to 1.0.0
  • % Done changed from 0 to 100

This has been fixed in the current master.

Actions

Also available in: Atom PDF