[Oisf-users] Why blocks suri this traffic?

[Stefan Sabolowitsch]

Hi Eric,
Too bad, i thought it could make "fine tuning" with threshold.conf.
Remove the rule from the rule set here is the worst solution (is a global action here), but apparently the only possible.

regards
Stefan

Am 04.03.2014 um 09:16 schrieb Eric Leblond <eric at regit.org>:

> Hello,
> 
> On Tue, 2014-03-04 at 08:11 +0000, Stefan Sabolowitsch wrote:
>> Hi all,
>> have here latest git version an this start option:
>> suricata --user sguil --group sguil -c /etc/nsm/Serrig-intern/suricata.yaml -q 0 -q 1 -q 2 -q 3 -l /nsm/sensor_data/Serrig-intern --runmode workers
>> 
>> I wanted to prevent that suri blocks access to a Web page. Here the appropriate log entry in evejson -> alert.
>> 
>> "message": "{\"time\":\"03\\/04\\/2014-07:15:17.412182\",\"event_type\":\"alert\",\"src_ip\":\"192.168.100.254\",\"src_port\":80,\"dest_ip\":\"192.168.1.69\",\"dest_port\":51538,\"proto\":\"TCP\",\"alert\":{\"action\":\"wDrop\",\"gid\":1,\"signature_id\":2221021,\"rev\":1,\"signature\":\"SURICATA HTTP response header invalid\",\"category\":\"Generic Protocol Command Decode\",\"severity\":3}}",
>> 
>> Then made the following entries in threshold.conf and restart suri.
>> 
>> suppress gen_id 1, sig_id 2221021, track by_src, ip 192.168.100.254
>> 
>> Now although no alert more in evejson written, but the traffic is still blocked. I found this drop message in evejson.
>> 
>> {"time":"03\/04\/2014-07:45:39.159838","event_type":"drop","src_ip":"192.168.1.69","src_port":52842,"dest_ip":"192.168.100.254","dest_port":80,"proto":"TCP","drop":{"len":
>> 40,"tos":0,"ttl":63,"ipid":50755,"tcpseq":3077954821,"tcpack":2506757002,"tcpwin":65535,"syn":false,"ack":true,"psh":false,"rst":false,"urg":false,"fin":true,"tcpres":0,"t
>> cpurgp":0}}
>> 
>> Why still blocks suri the traffic, a Bug?
> 
> No, it is a feature:
> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Global-Thresholds#suppress
> 
> All actions but alert are still performed when using suppress. To avoid
> drop, you have to remove the rule from the ruleset or set it to pass.
> 
>> Is threshold.conf in the IPS-mode not effective?
> 
> NO, the behavior you've seen is conform to what is expected.
> 
> BR,
> -- 
> Eric Leblond <eric at regit.org>
> 
>