[Snort-users] A few questions regarding Solaris

Mike Lococo mikelococo at ...11827...
Mon Aug 30 13:37:15 EDT 2010


> Mainly, has anyone gotten them to compile on a Solaris build?  I'm not
> successful at compiling them from scratch.  I pay the subscription fee
> and I feel that I'm taking advantage of the subscription by not using
> the SO_RULES.  Any help at all would be great! 

I can't address your question directly, since I don't run on Solaris.
As a warning, though, it's worth noting that even if you get them to
compile, you won't have access to all of the SO_RULES.  Many SO_RULES
are precompiled in order to obfuscate them.  The information-sharing
agreements that allow SourceFire to release sigs for vulnerabilities and
exploits before details become public often require the sigs to be
obfuscated so the source-compilable SO_RULES don't have everything.

> Also i'm running it on a heavily trafficed VLAN, lots of server and
> workstation traffic, to/from Internet, etc.  I know that some alerts are
> being missed.  I have tuned out a lot of the snort rulesets and use
> emerging markets and most of the malware rulesets.  I still find myself
> missing alerts, for example i'll try and hit one of the RBN sites and
> sometimes Snort will trigger and alert and sometimes it won't.  Is there
> anything I can do to make sure it captures everything without missing
> anything.  My box has 10GB of Ram and 500GB 10k harddrives.  So i'm not
> sure where the bottleneck is.  I run snort 8.6 and barnyard 1 because 2
> wouldn't compile correctly for me on Solaris; I run both of these in
> damon mode.

1) Check your CPU usage, is snort pegging one or more or your cores?  If
so, then you're likely dropping packets.
2) Turn on the performance monitor preprocessor and check the stats.  In
particular, check:
   a - The total-packets-dropped count, and how it changes while you
       watch it in relation to total-packets-received. This tells you
       how many packets snort has failed to process that libpcap knows
       about.  The packets could be dropping in the kernel buffer, or
       by snort due to lack of CPU.
   b - Largely ignore the drop-rate percentage.  It's averaged over
       the lifetime of your snort process.  If that lifetime is long,
       and you've *ever* experienced a large amount of loss, this ratio
       can be misleading and may not reflect your *current* drop rate.
   c - Mbits/sec.  Are these values pushing the
       max for your monitor port, or any link in the path between your
       packet-source and monitor port?  If so, you could be dropping
       packets before they ever hit your sensor.

Cheers,
Mike Lococo




More information about the Snort-users mailing list