[Oisf-users] Making Suricata Alert Per Matching Packet

[Cooper F. Nelson]

Well, first of all IP-only rules usually have a threshold set as most
folks don't want them alerting constantly.

In your example I can think of a few cases why the observed behavior
might be happening.

One, you may have some offloading enabled on your NIC.  Best practice is
to disable it.  Check the documentation here for instructions:

> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/File_Extraction

Two, I know that the unified2 logging is a "best effort" and may not
always log all packets.

I was going to mention this earlier, but if I was interested in matching
on all packets I would just use bpf filters and full-packet capture.

-Coop

On 4/11/2016 2:44 PM, Shane Boissevain wrote:
> Coop,
> 
> Thank's for the speedy reply. I've confirmed that by playing with the flags
> option i can get suricata to trip on the desired 18 packets.
> 
> However, I suppose my question isn't so much as "how do i get this to trip
> on these packets" and more of why doesn't that signature trip on all of
> these packets?
> 
> For example, if i add a reputation alert (based off of those found at
> Emerging Threat's drop.rules file:
> 
> alert ip 10.0.0.100 any -> any any (msg:"TEST Rule 2";
>> classtype:misc-attack; sid:9000002; rev:1;)
> 
> 
> I would expect there to be 20 alerts tripped, as I send 20 packets that
> have the source ip of 10.0.0.100 (as verified below):
> 
> # tcpdump -nr test.pcap src net 10.0.0.100 | wc
>>      20 lines
> 
> 
> However, I only see 5 total alerts...verified by:
> 
> # u2spewfoo unified2.alert.1460410545  | grep '(Event)' | wc
>>       5 lines
> 
> 
> ~ Shane
> 


-- 
Cooper Nelson
Network Security Analyst
UCSD ITS Security Team
cnelson at ucsd.edu x41042

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160411/64881fdd/attachment-0002.sig>