[Snort-users] Output question during FIN scan
mkettler at ...4108...
Sun May 12 14:44:02 EDT 2002
1) I'll repeat, please don't post in HTML to this list, it munges the
digest for digest mode subscribers, not to mention looks like complete
sensless garbage to the numerous plain-text mail readers on this list.
2) The stats mean that the kernel dropped 1847 packets without being able
to give them to snort. Of the 1305 packets that the kernel was able to give
snort, snort processed all of them.
The total number of packets seen by the snort computer is 1847+1305.
Basically you missed more packets than you managed to process. Lighten your
snort config up. Use non-text mode logging for starters. ie: tcpdump
Note that if you're doing fin scans across a local 100mbit ethernet segment
this is not likely to be a realistic load for snort (unless you have an OC3
you are monitoring). Compared to, say a typical cable-modem, T1, or common
DSL line, which are typically under 2mbit/sec the 100mbit ethernet is 50
times the load. Try to present snort with a load which isn't substantially
greater than your real world setup and then tune.
If you really need to monitor a truly high-speed network, please RTFM on
high performance setups:
(I've de-htmled tommy's message as best I can, and turned the html angle
braces in the stray urn schemas tag to parens)
The summary from implementing a FIN scan to my own private network outputs
part the following:
Snort analyzed 1305 out of 1305 packets, The kernel dropped 1847(141.533%)
packets (?xml:namespace prefix = o ns =
Breakdown by protocol: Action Stats:
TCP: 1299 (99.540%) ALERTS: 612
UDP: 0 (0.000%) LOGGED: 611
ICMP: 2 (0.153%) PASSED: 0
ARP: 4 (0.307%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
My question is how is it possible to drop 1847 when the program analysed 1305?
Forgive me if it is an easy answer but I am a newbbie.
More information about the Snort-users