Re: A few questions regarding Solaris

[Mike Lococo <mikelococo () gmail com>]

> 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

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users