Barnyard2 quits, then Snort quits

dave_c

Hi,

I installed Snort 2.8.4.1_5 pkg v.1.7 on pfSense 1.2.2 yesterday. This morning, I found that Snort was not running, and I found the following in the system log:

barnyard2[40047]: Leaving due to signal f.

Once barnyard2 finishes exiting, Snort exits:

snort[40038]: *** Caught Term-Signal

I'm running most Snort rules, including Emerging Threats. My system is Pentium 4 with 1 GB RAM. I've been running pfSense for months with no problem.

I'm logging barnyard2 output to mySQL on a different box. I use BASE to view barnyard2's output, and it appears that nothing unusual was happening in terms of malicious activity at the time when barnyard2 quit. pfSense's graphs show no unusual system or traffic loads at that time.

I know that barnyard is prone to losing connection with MySQL, but for some reason (can't remember if I saw this documented somewhere) I thought that this was not an issue with barnyard2. Either way, my experience with barnyard has been that it doesn't quit when it looses its MySQL connection. And shouldn't Snort continue to run even if barnyard2 quits?

Has anyone else seen similar problems, and is there a fix?

Thanks,
Dave

dave_c

At 6:00 PM barnyard2 and Snort quit again. The first time this happened was at 6:00 AM, so I checked into the automatic Snort rules update, which is scheduled to run every six hours. Looks like there are a couple of problems, one of which was my fault, having to do with barnyard2's connection to the MySQL server. It's probable that this caused the error that occurred at 6:00 PM, but not the previous one at 6:00 AM. My best guess at this point is that the first failure might have been due to the memory limit setting in the update script. I'm using the ac-bnfa memory/performance setting, and when I restart Snort, it runs at 100% cpu until the rules are loaded, and it uses more memory than allowed by the update script. I tried to adjust the performance setting, but there's no option for high memory and slow processor. So, in general, I either completely overload the CPU or I underutilize memory. Seems pfSense/Snort requires a better processor than the one that I'm currently using. Let's see what happens the next time the rules are updated.

ColdFusion

It seems to always hit 100% when the rules load, I don't think that this is necessarily a problem. It also seems Snort doesn't restart after the auto rules update until you manually restart it by hitting Save again. I have 1 pf box that auto updates after 4 days and it seems to quit until I restart it. Another box set to auto update after 7 days and then it also seems to quit after this time. Of course my findings are pure observation and speculative.
Previously, when we had to manually update the rules at whatever time we chose Snort stayed running fine. I've had snort running over 2-3 weeks straight without updating the rules and it would be fine.

dave_c

Hi,

Thanks for your reply. Yeah, the auto update script fails to re-launch Snort. Also, the enabling/disabling of individual rules is not saved when Snort is updated manually. Fortunately, I have disabled only one individual rule.

Other than these relatively minor problems, the Snort package works great. Thanks to the developers.

–Dave

jamesdean

@dave_c:

Hi,

Thanks for your reply. Yeah, the auto update script fails to re-launch Snort. Also, the enabling/disabling of individual rules is not saved when Snort is updated manually. Fortunately, I have disabled only one individual rule.

Other than these relatively minor problems, the Snort package works great. Thanks to the developers.

–Dave

Im realy busy at work right now. I'll fix these errors soon.

I'm almost done with the New GUI just a few more days fellas/gals and Snort-dev will be up with the New gui.

Thank you Dav keeping me updated with this issue.

James

Jare

Hi,

The auto update script failing to restart Snort was an easy fix. I have just posted the details in the other thread: http://forum.pfsense.org/index.php/topic,19834.msg105683.html#msg105683.

dave_c

Cool! Thanks Jare and James. BTW, I just manually updated Snort, and it did restart successfully this time. Not sure what changed…

James, how much work would it be for me to get this package working with the latest version of Snort?

jamesdean

@dave_c:

Cool! Thanks Jare and James. BTW, I just manually updated Snort, and it did restart successfully this time. Not sure what changed…

James, how much work would it be for me to get this package working with the latest version of Snort?

You could compile the newest version of snort.

Note, you would lose threshold option, and blocking of ips.

James

dave_c

Hmmm… Wouldn't want to lose either. Are you diverting the packets to Snort in some special way that can't be done with a non-package version of Snort?

And, two more questions if you have time...

Have you hand-picked rules for inclusion in pfSense, or does the full complement of rules for that version of Snort download?

Also (this is probably a dumb question), is it possible to run pfSense as a filtering bridge with Snort in IPS mode? Or are is this not possible because the OS is FreeBSD?

Thanks.

jamesdean

@dave_c:

Hmmm… Wouldn't want to lose either. Are you diverting the packets to Snort in some special way that can't be done with a non-package version of Snort?

And, one more question if you have time...

I'm running the latest version of Snort in IDS mode on one computer, and pfSense/Snort in IPS mode on another. There are rules on the IDS box that don't exist on the IPS box. Is this because you've hand-picked rules for inclusion in pfSense, or because the sets of rules that are available for each version of Snort are different?

Thanks.

Yes, I have custom C++ code for the IPS part of snort.

I have to hand pick the rules.
Because some of the rules will break snort.

James

dave_c

@jamesdean:

Yes, I have custom C++ code for the IPS part of snort.

I have to hand pick the rules.
Because some of the rules will break snort.

James

Okay, thanks.

Not sure if this is the right forum for the questions that follow, but here goes….

Here's what this all boils down to: I'm putting together a proposal for a small, remote data center for a client who deals with extremely sensitive data, and I'm evaluating IPS solutions. Sourcefire would be my first choice, but it's outside of my client's budget. So I'm checking into less expensive and free solutions.

I'm sold on pfSense as a firewall, and Snort is a state-of-the art IDS. But for me to choose pfSense's implementation of Snort as the IPS solution for my client, I would need to have a fairly high level of comfort. I do realize that I'm not dealing with a sales department, my intent is not to be critical in any way, and again, I don't assume that you have time to answer. But if you could help me gain some comfort, it would be most appreciated.

Here are my questions:

I see that the Snort package works. But does it work well enough for me to entrust it with the task of protecting my client's data? The fact that it was necessary for you to turn off certain rules has diminished my level of confidence somewhat, because the rules weren't chosen for IPS tuning reasons; rather, some had to be turned off just to get Snort to work.

I wonder if you could provide, with little or no effort, a list of the rules that you have turned off, and/or give me a sense of the kinds of functionality that are missing with your subset of rules relative to the full set. Could you describe briefly why certain rules break pfSense's implementation of Snort?

Another factor here is that I don't have the expertise at this point to tune Snort rules myself. Should this necessarily deter me from deploying Snort in a production environment and learning as I go?

Has anyone here done comparisons between pfSense/Snort IPS and other solutions like Untangle, SonicWall UTM and CheckPoint?

Thanks again.

jamesdean

@dave_c:

@jamesdean:

Yes, I have custom C++ code for the IPS part of snort.

I have to hand pick the rules.
Because some of the rules will break snort.

James

Okay, thanks.

Not sure if this is the right forum for the questions that follow, but here goes….

Here's what this all boils down to: I'm putting together a proposal for a small, remote data center for a client who deals with extremely sensitive data, and I'm evaluating IPS solutions. Sourcefire would be my first choice, but it's outside of my client's budget. So I'm checking into less expensive and free solutions.

I'm sold on pfSense as a firewall, and Snort is a state-of-the art IDS. But for me to choose pfSense's implementation of Snort as the IPS solution for my client, I would need to have a fairly high level of comfort. I do realize that I'm not dealing with a sales department, my intent is not to be critical in any way, and again, I don't assume that you have time to answer. But if you could help me gain some comfort, it would be most appreciated.

Here are my questions:

I see that the Snort package works. But does it work well enough for me to entrust it with the task of protecting my client's data? The fact that it was necessary for you to turn off certain rules has diminished my level of confidence somewhat, because the rules weren't chosen for IPS tuning reasons; rather, some had to be turned off just to get Snort to work.

I wonder if you could provide, with little or no effort, a list of the rules that you have turned off, and/or give me a sense of the kinds of functionality that are missing with your subset of rules relative to the full set. Could you describe briefly why certain rules break pfSense's implementation of Snort?

Another factor here is that I don't have the expertise at this point to tune Snort rules myself. Should this necessarily deter me from deploying Snort in a production environment and learning as I go?

Has anyone here done comparisons between pfSense/Snort IPS and other solutions like Untangle, SonicWall UTM and CheckPoint?

Thanks again.

You misunderstand.

The only rules I remove are the snort_inline rules from Emerging threats. Im working on snort_inline for the pfsense package
but you will not see that until pfSense 2.0.

The rules you see enabled or disabled in the snort package are done by the rule maintainers (emergingthreats.net, snort.org).
You can safely enable or disable rules that you see in the snort package.

James

dave_c

@jamesdean:

The only rules I remove are the snort_inline rules from Emerging threats. Im working on snort_inline for the pfsense package
but you will not see that until pfSense 2.0.

The rules you see enabled or disabled in the snort package are done by the rule maintainers (emergingthreats.net, snort.org).
You can safely enable or disable rules that you see in the snort package.

Thank you so much for clearing that up.

I see now where my anxiety and misunderstanding came from… There are no preproc rules on my pfSense box. Are they supported?

jamesdean

@dave_c:

@jamesdean:

The only rules I remove are the snort_inline rules from Emerging threats. Im working on snort_inline for the pfsense package
but you will not see that until pfSense 2.0.

The rules you see enabled or disabled in the snort package are done by the rule maintainers (emergingthreats.net, snort.org).
You can safely enable or disable rules that you see in the snort package.

Thank you so much for clearing that up.

I see now where my anxiety and misunderstanding came from… There are no preproc rules on my pfSense box. Are they supported?

Yes, they are supported and are there. Moreover, so rules are there and supported also.

James

dave_c

I'm probably exposing my ignorance here… My Snort 2.8.5 IDS box reported an http_inspect alert that was not reported by pfSense/Snort IPS. Also, the only file or folder on my pfSense box whose name contains "preproc" is /usr/local/src/snort_dynamicsrc/preprocids.h.

dave_c

I thought that I should pause and put things in perspective (at least for myself) by mentioning this:

I've been running Snort IDS on my network for a few months, so I've become fairly well acquainted with the kinds of malicious traffic that have been getting to my servers (fortunately, without doing harm). I had been averaging about 500 alerts per day. But after adding Snort IPS to pfSense a few days ago, a grand total of 8 alerts have triggered on the IDS sensor. Six of them were also registered by the pfSense sensor, but not blocked. (I'll trust the expertise of the Snort guys and James on those.) Thanks, Snort guys and James for such a great product.

But even though they have presented no danger to me, because I'm not running IIS, I am still a bit concerned about the two http_inspect double decoding alerts that didn't get caught by pfSense/Snort. I'm concerned, because if I needed to turn them on, I wouldn't know how, and it makes me wonder what other preprocessor rules are not active.

The http_inspect preprocessor is configured in snort.conf, but the preprocessor rules path is commented out, and can't be un-commented (snort.conf gets overwritten when snort reloads). So, I guess the preproc rules must be stored in some location that's unknown to me, making it impossible for me to turn them on or off.

James, I'm sure your plate is full. But I would be grateful if you would provide some advice on this when you get a chance.