Project

General

Profile

Actions

Bug #455

closed

Suppression not working with "track by_src"

Added by Ian Bowers about 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

This was addressed in ticket #386, but still appears to be a problem in version 1.2.1

Thresholding for a particular SID with source IP address specified:
[0][root@linolea-ips1:/etc/nsm/linolea-ips1-eth1]# grep 108.59.1.205 /etc/nsm/linolea-ips1-eth1/threshold.conf
suppress gen_id 1, sig_id 2406000, track by_src, ip 108.59.1.205
suppress gen_id 1, sig_id 2406001, track by_src, ip 108.59.1.205

Threshold file is properly specified:
[0][root@linolea-ips1:/etc/nsm/linolea-ips1-eth1]# grep threshold-file /etc/nsm/*/suricata.yaml
  1. You can specify a threshold config file by setting "threshold-file"
    threshold-file: /etc/nsm/linolea-ips1-eth1/threshold.conf

9 items in file:
grep -v ^# /etc/nsm/linolea-ips1-eth1/threshold.conf | wc -l
9

And they all get parsed:
[0][root@linolea-ips1:/etc/nsm/linolea-ips1-eth1]# grep Threshold /var/log/nsm/*/suricata.log
23/4/2012 -- 07:02:26 - <Info> - Threshold config parsed: 9 rule(s) found

But the sigs still fire despite the suppression rules (last few are after suricata reload):
[0][root@linolea-ips1:/etc/nsm/linolea-ips1-eth1]# grep 108.59.1.205 /nsm/sensor_data/linolea-ips1-eth1/fast.log | tail -n 5
04/23/2012-06:53:04.622886 [**] [1:2406000:281] ET RBN Known Russian Business Network IP (1) [**] [Classification: (null)] [Priority: 3] {UDP} 108.59.1.205:53 -> 192.168.254.254:25436
04/23/2012-15:00:06.685215 [**] [1:2406000:281] ET RBN Known Russian Business Network IP (1) [**] [Classification: (null)] [Priority: 3] {UDP} 108.59.1.205:53 -> 192.168.254.254:24410
04/23/2012-17:01:30.156676 [**] [1:2406000:281] ET RBN Known Russian Business Network IP (1) [**] [Classification: (null)] [Priority: 3] {UDP} 108.59.1.205:53 -> 192.168.254.254:5213
04/23/2012-19:01:51.862718 [**] [1:2406000:281] ET RBN Known Russian Business Network IP (1) [**] [Classification: (null)] [Priority: 3] {UDP} 108.59.1.205:53 -> 192.168.254.254:21632
04/23/2012-21:03:23.455593 [**] [1:2406000:281] ET RBN Known Russian Business Network IP (1) [**] [Classification: (null)] [Priority: 3] {UDP} 108.59.1.205:53 -> 192.168.254.254:43299

So the file is referenced, the right number of lines is getting parsed by suricata, and signature, IP, and directionality all satisfy the suppression rule. The same lines fed to snort do suppress the alerts.

Suricata is above the version referenced in the last ticket:
[0][root@linolea-ips1:/etc/nsm/linolea-ips1-eth1]# suricata
23/4/2012 -- 21:16:41 - <Info> - This is Suricata version 1.2.1 RELEASE
23/4/2012 -- 21:16:41 - <Info> - CPUs/cores online: 4
-- SNIP --

I'm happy to attach any files or perform any tests to help.


Files

Actions #1

Updated by Peter Manev about 12 years ago

Hi Ian,

1.Can you please post all your "suppression" rules in the threshold(privately if you would like) ?

2.I think you are referring to [[https://redmine.openinfosecfoundation.org/issues/366]] ? , not
[[https://redmine.openinfosecfoundation.org/issues/386]] - the last is a Mac OS compilation issue.

3. Do you have any other sig_id 2406000 and sig_id 2406001 in the threshold.conf file?

Thanks

Actions #2

Updated by Ian Bowers about 12 years ago

You're correct, The case I'm referring to is 366. fat finger on my part.

File attached. Uncommented lines below:

suppress gen_id 1, sig_id 2404154, track by_src, ip 192.168.2.2
suppress gen_id 1, sig_id 2002026, track by_src, ip 192.168.2.2
suppress gen_id 1, sig_id 2013031, track by_src, ip 192.168.2.2
suppress gen_id 1, sig_id 2013031, track by_src, ip 192.168.2.3
suppress gen_id 1, sig_id 2013031, track by_src, ip 192.168.2.216
suppress gen_id 1, sig_id 2010645, track by_dst, ip 12.129.222.51
suppress gen_id 1, sig_id 2406000, track by_src, ip 108.59.1.205
suppress gen_id 1, sig_id 2406001, track by_src, ip 108.59.1.205

The 2 lines I have listed for sig_id 2406000 and sig_id 2406001 are the only ones for each.

Actions #3

Updated by Peter Manev about 12 years ago

so all of the suppression rules are not working?
or some are and some are not?

Actions #4

Updated by Ian Bowers about 12 years ago

To be specific, my logs (since the 4th or 5th of the month) show:

sig_id 2404152, sig_id 2002026, and sig_id 2010645 have not been seen at all since I added the rules. And they were only coming in for the IPs specified, so they're working properly.

sig_id 2013031 continues to come in, but not for the 3 devices I've define in the rule. So it is suppressing alerts and tracking source properly.

sig_id 2406001 has never been seen on this sensor, I copied the line over from another sensor, so I can't say anything to qualify it on this sensor.

sig_id 2406000 is the only line that has failed to suppress alerts as expected.

Actions #5

Updated by Peter Manev about 12 years ago

Hi,

Just to confirm - the only rule ("sig_id 2406000") is the one that is not suppressing in your case, the others work fine, correct?

I tried to reproduce your issue but it behaves as it should at least in my tests.

Could you please try
suppress gen_id 1, sig_id 2406000, track by_dst, ip 108.59.1.205

see if that has some effect?

Actions #6

Updated by Victor Julien about 12 years ago

  • Assignee set to Anoop Saldanha
  • Target version changed from 1.2.1 to 1.3beta2
  • Estimated time set to 5.00 h
Actions #7

Updated by Ian Bowers about 12 years ago

Correct, that's the only suppression rule that's misbehaving.

I've added the line as you suggested, I'll see how it behaves today. I'll also look back through my packet captures and see if it's doing something weird in context.

Actions #8

Updated by Ian Bowers about 12 years ago

I induced it by starting some bittorrent traffic... the signature tends to fire when a DNS request for tracker.publicbt.com is made, triggering on a DNS response from 108.59.1.205 . So I can trigger the issue pretty reliably. The signature itself is very simple, just a source-to-dest match, no content inspection that I can see. Attached is a packet capture of the transaction. Perhaps replaying the exact traffic that's evading suppression will shed some light.

Actions #9

Updated by Anoop Saldanha almost 12 years ago

The conf suppression won't work because the rule has an event filter set, in which case the rule filter is given precedence over the conf.

You can see that the suppression works by disabling the rule's threshold.

We are working on updating our event filter/suppression engine to allow conf override and be used simultaneously with rule filters.

Actions #10

Updated by Ian Bowers almost 12 years ago

Outstanding. Thank you very much for the explanation. That makes perfect sense.

I can play with modifysid.conf in pulledpork as a workaround until this update comes to bear.

Actions #11

Updated by Victor Julien almost 12 years ago

  • Target version changed from 1.3beta2 to 1.3rc1
Actions #12

Updated by Victor Julien almost 12 years ago

  • Status changed from New to Assigned
  • Priority changed from Normal to High

For 1.3rc1, please add an error condition so that the user knows this is not supported. For 1.4 we'll see how we can better support this case.

Actions #13

Updated by Anoop Saldanha almost 12 years ago

Info message added. Was torn on having it as a warning message. But Info seemed right. It's not a bug or error per-se. Just how it currently works.

Actions #15

Updated by Victor Julien almost 12 years ago

  • Target version changed from 1.3rc1 to 1.3
Actions #16

Updated by Victor Julien almost 12 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

Patch pushed, thanks Anoop.

Actions #17

Updated by Hang Cheung over 10 years ago

Dear All,

It seems I got a similar issue as well. Here is the suppression rule I made for my IPS:

suppress gen_id 1, sig_id 2100366
suppress gen_id 1, sig_id 2006445, track by_src, ip 192.168.200.10
suppress gen_id 1, sig_id 2011215, track by_src, ip 192.168.200.10

Neither of them work as expected under inline mode: it just suppressed the "alert", but not the "drop" action.

ips/emerging-icmp_info.rules:drop icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL ICMP_INFO PING *NIX"; itype:8; content:"|10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F|"; depth:32; classtype:misc-activity; sid:2100366; rev:8;)

ips/emerging-web_server.rules:drop http $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM"; flow:established,to_server; uricontent:"SELECT"; nocase; uricontent:"FROM"; nocase; pcre:"/SELECT.+FROM/Ui"; reference:url,en.wikipedia.org/wiki/SQL_injection; reference:url,doc.emergingthreats.net/2006445; classtype:web-application-attack; sid:2006445; rev:10;)

ips/emerging-web_specific_apps.rules:drop http $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB_SPECIFIC_APPS Campsite article_id Parameter SELECT FROM SQL Injection Attempt"; flow:established,to_server; content:"GET"; http_method; content:"/plugins/campsiteattachment/attachments.php?"; nocase; http_uri; content:"article_id="; nocase; http_uri; content:"SELECT"; nocase; http_uri; content:"FROM"; nocase; http_uri; pcre:"/SELECT.+FROM/Ui"; reference:url,secunia.com/advisories/39580/; reference:url,doc.emergingthreats.net/2011215; classtype:web-application-attack; sid:2011215; rev:5;)

while I run with this command:
suricata -c /etc/suricata/suricata-ips.yaml -q 0

Any idea?

Regards,
Hang

Actions #18

Updated by Victor Julien over 10 years ago

@Hang I think this actually works as expected. Suppression is about suppressing the output, while keeping the rule 'actions' (drop, setting flowbits, etc).

Actions

Also available in: Atom PDF