Re: A few questions regarding Solaris

[Robert Riskin <freshbones () gmail com>]

@ Mike
Thanks for your information regarding the SO_RULES about the source
compiled, this means I will have to switch platforms completely.  I'm
thinking about CENTOS or Ubuntu, however it looks like Snort is not
compatible with the latest Ubuntu release? (Talking about SO_RULES) and
since they are in the midst of changing supported platforms I will most
likely rebuild my HP system. Does that make the most sense? I'm not going to
do anything with my current build until I form a plan of rebuilding a new
OS. More fun, which I really don't have time to do but I do want to take
advantage of the SO_RULES.

CPU usage is nil, watching it now under 1% . . . memory is at 3%.  I will
look into turning on the performance monitor preprocessor, can I run this in
daemon mode, if so how do I check the stats, can I log them to a file? Thank
you very much for your help, I really do appreciate it!


@ waldo kitty

CPU - 2x dual core 2.3MHz chips
Processor Cache: 4096KB

The NICs is HP branded without own CPU, it has 4 gig NIC ports on each card.
I'm only using one of these ports, as I originally planned to monitor more
than one VLAN.

I'm going to turn off the IRQs in the BIOS.

I don't have too many rules turned on and not even using the SO_RULES, but I
agree that it might be the shear amount of traffic going over the wire. I've
disabled the sftportscan preprocessor and am using mostly Emerging Threats
rulesets.

But since my CPUS and memory aren't anywhere near spiking could it be the
NIC? How do I check this? I greatly appreciate your feedback and help!!


On Mon, Aug 30, 2010 at 1:37 PM, Mike Lococo <mikelococo () gmail com> wrote:

> > 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
------------------------------------------------------------------------------
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