Barnyard2 quits, then Snort quits

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.