Snort update coming soon – please read about an important change!

fragged

Multiple processes doesn't bring any use if it isn't combined with using pf_ring or other similarly capable packet capture interface. The currently used libcap doesn't have support for stuff like this. This would mean that you run the same ruleset with multiple Snort instanced for the same physical interface. Traffic is routed to each Snort interface by pf_ring.

Using multiple Snort interface with different rulesets sounds like a really stupid idea to me.

Then again, I don't actually know anything at all about networking and IDS efficiency.

Cino

If you want run multiple snort interfaces using different rule-sets (alerting/blocking), comment out line 114 to line 122 in /usr/local/www/snort/snort_interfaces_edit.php.

Use at your own risk

look for


	/* See if assigned interface is already in use */
	if (isset($_POST['interface'])) {
		foreach ($a_rule as $k => $v) {
			if (($v['interface'] == $_POST['interface']) && ($id <> $k)) {
				$input_errors[] = gettext("The '{$_POST['interface']}' interface is already assigned to another Snort instance.");
				break;
			}
		}
	}

change to


	/* See if assigned interface is already in use 
	if (isset($_POST['interface'])) {
		foreach ($a_rule as $k => $v) {
			if (($v['interface'] == $_POST['interface']) && ($id <> $k)) {
				$input_errors[] = gettext("The '{$_POST['interface']}' interface is already assigned to another Snort instance.");
				break;
			}
		}
	}
	*/

A Former User

bmeeks, can you add a way to filter out the:" [Classification: Attempted Information Leak] [Priority: 2]" (classification and priority) from the logs? Logging those to a syslog server is just adding extra unneeded info and makes managing the logs a bit of a headache.

bmeeks

@jflsakfja:

bmeeks, can you add a way to filter out the:" [Classification: Attempted Information Leak] [Priority: 2]" (classification and priority) from the logs? Logging those to a syslog server is just adding extra unneeded info and makes managing the logs a bit of a headache.

Not sure. I will have to see if Snort offers any native log output filtering. I don't recall off the top of my head. Suricata does. There are some log regex filters that can be used (but I don't have those enabled yet in the Suricata package for pfSense).

As I've said a few times, I am almost done with the initial blocking plugin for Suricata. I actually have it working as of last night on my VMs. Testing and refining the next few days, and then I will update the GUI code to accommodate the feature. As part of that update I can examine implementing the regex filtering.

Bill

A Former User

Would really appreciate it if something like that is implemented in suricata, since i'm also waiting for the blocking feature to be available to move off snort.

Thank you for all the time you've put so far into the IDS/IPS packages.

armouredking

@gscasny:

I had this exact issue (along with continuing "Duplicate Entry" issues), but to fix it, I removed the "Sensor Name" in the Barnyard2 portion of the web gui. This corrected barnyard2 logging in as root. I was able to repeat the issue and correct it by adding a name to the "Sensor Name" - broke, and then removing it.. fixed.

Yes, confirmed fix for me as well. Removing sensor names stops it from using root to try to access MySQL. Unfortunately, ever since the update I'm unable to get all the interfaces working with Snort; if I turn on more than one the signature clashes start occurring after a few minutes of otherwise stable operation. None of the old fixes is correcting it, and rebuilding the DB still only grants a few mins of operation before signature errors.

For whoever it was talking about Snorby dashboard issues, my fix to this was just a time check issue. I ran the pfSense using local time instead of UTC ( as was defined on the linux host for Snorby - pfSense was on AzT, with the DB server and the Snorby server on UTC ) which caused my dashboard to never update due to the differences in timezones for the database and the data coming in without a truncate tables command run on the db. Which would allow the dashboard to update once and then die.

Internet searches will provide a lot of posts with regards to Snorby's dashboard being a pain in the ass though, so barring something simple like a time mismatch it's a veritable field day of answers to try.

bmeeks

@armouredking:

@gscasny:

I had this exact issue (along with continuing "Duplicate Entry" issues), but to fix it, I removed the "Sensor Name" in the Barnyard2 portion of the web gui. This corrected barnyard2 logging in as root. I was able to repeat the issue and correct it by adding a name to the "Sensor Name" - broke, and then removing it.. fixed.

Yes, confirmed fix for me as well. Removing sensor names stops it from using root to try to access MySQL. Unfortunately, ever since the update I'm unable to get all the interfaces working with Snort; if I turn on more than one the signature clashes start occurring after a few minutes of otherwise stable operation. None of the old fixes is correcting it, and rebuilding the DB still only grants a few mins of operation before signature errors.

For whoever it was talking about Snorby dashboard issues, my fix to this was just a time check issue. I ran the pfSense using local time instead of UTC ( as was defined on the linux host for Snorby - pfSense was on AzT, with the DB server and the Snorby server on UTC ) which caused my dashboard to never update due to the differences in timezones for the database and the data coming in without a truncate tables command run on the db. Which would allow the dashboard to update once and then die.

Internet searches will provide a lot of posts with regards to Snorby's dashboard being a pain in the ass though, so barring something simple like a time mismatch it's a veritable field day of answers to try.

armouredking:

A new Pull Request is posted on Github containing a fix for both of these issues (well, a fix for the "root login thing" and a workaround for the duplicate key errors when running multiple Snort/Barnyard2 processes against a single DB). The Core Team has not yet approved and merged the fix, though. Hopefully they can get to it this week. In the meantime, if you know how to grab PHP files off of Github you can do that. Some other users have done that already. All of the fixes are within the PHP files. Here is a link: https://github.com/pfsense/pfsense-packages/pull/648

Bill

Fmstrat

How would one go about requesting a feature in the snort package?

Right now, the package provides IP info links for DNS Stuff and WHOIS. I'd love to see a link to Virus Total. Should be pretty straight forward, for instance:

https://www.virustotal.com/en/ip-address/23.62.236.97/information/

Virus Total provides a lot of history information on an IP, including reverse DNS history and seeding potential for infected files.

Thanks,
Ben

BBcan177

Hi Ben,

I already have request on Redmine to add this functionality for VirusTotal and other links.

https://forum.pfsense.org/index.php?topic=73406.msg400956#msg400956

https://redmine.pfsense.org/issues/3508#change-13575

You can manually edit that file for now.

Fmstrat

@BBcan177:

Hi Ben,

I already have request on Redmine to add this functionality for VirusTotal and other links.

https://forum.pfsense.org/index.php?topic=73406.msg400956#msg400956

https://redmine.pfsense.org/issues/3508#change-13575

You can manually edit that file for now.

Perfect. And now I also know where the issues log resides. Thanks.

Ben