@tbaror:

Thanks all for the answers , but Snorby would be a good solution if he had some alerting rules facility

The Snorby package in Security Onion has alerting functionality.

good stuff, thanks a lot!

now i'll go find a way to get a pfblocker report in the mail too!

@iraiam:

@fragged:

The HTTP preprocessor does fire a lot of false positives. You can either add the single rules to your suppress list or enable this setting:

Disable Alerts from this engine configuration. Default is Not Checked.

You can find it under the settings for your Interface -> <interface name="">Preprocessors -> HTTP Inspect / Server Configuration (click the E to edit)</interface>

Thanks, I'll give that setting a try, I don't have time to deal with single rules at the moment, maybe at a later date. Take Centurylink.com; it generated 19 blocks from one session. I went through the logs and checked a quite few of the blocks manually and found no actual threats.

it makes sense to me to block offenders, providing it detects actual offenders without all the false positives.

The HTTP_INSPECT preprocessor is unfortunately very good at generating false positives.  Some of them are likely the fault of code in the preprocessor itself, but many are due to various web servers not adhering strictly to the standards.  No matter which is the real problem, it's a fact of like for IDS/IPS admins that false positives will occur.  Snort on pfSense uses the binary file produced by the Snort VRT, so any bugs in that code show up in pfSense.

There is a thread that lists many of the known false-positives, and some users have shared their Suppress Lists.  You might want to try some of their shared settings.  Here is the link:  https://forum.pfsense.org/index.php/topic,56267.0.html

The third script now errors and says "Illegal variable name."

You are going to have to give us some information to work with. Like the access.log I think when it is not working. Does restarting the service fix it? What do you have to do to get it working again?

@Clear-Pixel:

Why is it often times many IP's are missing the reverse DNS info?

Is it a DNS server with a poorly compiled DNS list?

It would seem the IP would be out of compliance if no Name was attached?

There are a fairly significant number of the "spammer" and other blacklisted IPs that do not resolve via DNS lookups.  Not really surprising when you realize these guys don't want to be found… ;)

Bill

@berrick:

From my limited use of both these packages it seems they do the same thing, is this correct?

Which is better sarg or lightsquid?

regards

Depends on your wishes.
LightSquid easier, Sarg has more features.

By default the firewall won't touch HTTPS with squid in transparent mode. Make sure your firewall rules allow access on the LAN interface from your LAN subnet to anywhere on port 443. So long as the rules pass it and squid doesn't touch it, it will go right out.

Just figured out that the 2.12.0.6 version of DG that Marcello compiled does not have PCRE support… or at least that is my guess on the problem. It does not execute and of the regular expression functionality - such as URL regular expression modifications.

Would anyone with a dev environment (Marcello?) be willing to compile the 2.12.0.6 or 2.12.0.7 version with PCRE? Or, for that matter, e2guardian (I'd be willing to mod the UI to get it working)? Thanks in advance!

I am not sure if SquidGuard is the same as pfBlocker for the max table entries, but I would assume so.

Did you edit the System:Advanced:Firewall/NAT  "Firewall Maximum Table Entries"

@KOM:

1. pkg_info:

bsdinstaller-2.0.2013.0911 BSD Installer mega-package
gettext-0.18.3

Going to need the rest of the information still ;)

@mudmanc4:

I have changed the whitelist for that interface to the one created earlier,  restart snort, and made various protocol requests - no blocking that I can see at this point.

Big info from you on this, much appreciated bmeeks !

Thank you.  Glad it's working for you now.  One item on my TODO list is to update the Snort package documentation and then include links to it from various spots in the package.

Bill

I have a fix!

sarg can examine more than one log file, so regardless of order of execution of the rotate and log generation, just ensure all the logs, rotated or not, are used thus:

Steve


@BBcan17:

@bmeeks:

So I think we are stuck staying with a version that is at least 30 days old, or else require everyone to buy the paid subscription.  That would not be popular :'(

Thanks Bill,

If its not too much trouble, maybe you could post both updates and users could choose which version would work for them? This would allow us to debug the most recent Snort version while having the option to go down one version just in case?

Well, that is a good idea.  There was, at one time, an active snort-dev package maintained by the old maintainer.  It was really bleeding edge, though.  I had considered resurrecting that old snort-dev tree, but not for "free" versus "paid" subscriptions, but instead to try and keep the most recent Snort binary out there.  I've just been busy lately with the current package and doing some work on a Suricata package, and just have not gotten around to it.

Bill

by using the country blocker, you'll also find it kills your ability to generate a return ticket and shipping label at Amazon.  (why is Amazon's return label eneration routing through Asia??) There is another thread here on using pfBlocker to generate the lists to be used by Snort and the rules set. I've found this option makes every problem like this (that I was having) go away without having a lot of custom pass rules.

https://forum.pfsense.org/index.php/topic,64674.0.html

Rick

@kevin067:

It seems to me whatever pfblocker is doing internally to create it's alias tables, snort should do the same. As far as I can tell pfblocker (using "Alias_Only" mode) has been blocking well.

Here's a link to the code inside pfblocker that creates those tables…

http://www.pfsense.org/packages/config/pf-blocker/pfblocker.inc

So the idea is to let snort use snort2c tables for the immediate blocking. Then append the ip's it finds into an alias for long term blocking (one that survives filter_reload, and reboots). using a normal incoming wan/outgoing lan rule.

I like where the <snort2c>table is currently located up high in the pf rule chain such that it is hit very early in the packet's traversal of the firewall.  This gives Snort a chance to block early and protect users from "quick pass" rules farther down that would bypass Snort.

It occurred to me last night there may a fix for the clearing problem triggered by the filter reloads.  I need to talk it over with the Core Team, but maybe the filter reload process could persist the <snort2c>block table out to a temp file during the reload process, and then read the file back in as part of the filter reload.  It is trivial to do this with the pfctl utility (dumping a table to a file and loading a table from a file).

Bill</snort2c></snort2c>

iperf is what we normally use. On endpoints beyond the firewall on each side.