Barnyard2 quits, then Snort quits
-
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. -
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
-
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
-
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.
-
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?
-
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
-
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.
-
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
-
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.
-
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
-
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?
-
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
-
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.
-
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.