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

gscasny

I went ahead and grab the changes you made before the merge. Would it be possible to change the order of the database output? If I select the disable_signature_reference_table option (BTW you beat me too it, I started to test this option last night and was able to turn up 2 interfaces with no dup error), the 'root' error happens again when it tries to connect to mysql.

Right now the order is:
output database: log, mysql, sensor_name=pfsense_lan disable_signature_reference_table user=snort password=ABC123 dbname=snort host=somebox
After reading barnyard2's README.database doc, it seems to work in this order:
output database: log, mysql, user=snort password=ABC123 dbname=snort host=somebox sensor_name=pfsense_lan disable_signature_reference_table

Did you disable the reference table on both interfaces? Do you know what effect (if any) this has on the logging of snort alerts in mysql?

Thanks!

Greg

bmeeks

@Cino:

I went ahead and grab the changes you made before the merge. Would it be possible to change the order of the database output? If I select the disable_signature_reference_table option (BTW you beat me too it, I started to test this option last night and was able to turn up 2 interfaces with no dup error), the 'root' error happens again when it tries to connect to mysql.

Right now the order is:
output database: log, mysql, sensor_name=pfsense_lan disable_signature_reference_table user=snort password=ABC123 dbname=snort host=somebox
After reading barnyard2's README.database doc, it seems to work in this order:
output database: log, mysql, user=snort password=ABC123 dbname=snort host=somebox sensor_name=pfsense_lan disable_signature_reference_table

Sure. I will swap the order since the Pull Request is still open and I can update it. Thanks for testing and reporting back.

UPDATE: the fix to swap the order has been added to the open Pull Request.

Bill

bmeeks

@gscasny:

@Cino:
I went ahead and grab the changes you made before the merge. Would it be possible to change the order of the database output? If I select the disable_signature_reference_table option (BTW you beat me too it, I started to test this option last night and was able to turn up 2 interfaces with no dup error), the 'root' error happens again when it tries to connect to mysql.

Right now the order is:
output database: log, mysql, sensor_name=pfsense_lan disable_signature_reference_table user=snort password=ABC123 dbname=snort host=somebox
After reading barnyard2's README.database doc, it seems to work in this order:
output database: log, mysql, user=snort password=ABC123 dbname=snort host=somebox sensor_name=pfsense_lan disable_signature_reference_table
Did you disable the reference table on both interfaces? Do you know what effect (if any) this has on the logging of snort alerts in mysql?

Thanks!

Greg

Greg:

My understanding is this just prevents the insertion of the references information included with most signatures. It does not alter the insertion of the other parts of the alert data.

Bill

Cino

Thanks Bill!!! There shouldn't be any effect in how the alerts are sent to mySql. I only disabled it on my LAN interface, and left WAN alone so it would update the DB.

jasonlitka

Question. Is there a technical reason why you can't setup snort more than once on a single interface?

I was running some performance tests on my C2758 for cmb this morning and it occurred to me that since snort is single-threaded per interface, that it would be a lot more efficient on a multi-core box (C2758 has 8 cores) to offload rules that don't have anything to do with each other to a separate process. For example, run VRT Balanced on one process and the ET rulesets relating to rbn, botcc, and currentevents on another.

I've had a couple occasions where snort wouldn't shutdown correctly and I end up with two processes on a single interface which both grab traffic (based on CPU usage). Why not do it intentionally?

Thoughts?

bmeeks

@Jason:

Question. Is there a technical reason why you can't setup snort more than once on a single interface?

I was running some performance tests on my C2758 for cmb this morning and it occurred to me that since snort is single-threaded per interface, that it would be a lot more efficient on a multi-core box (C2758 has 8 cores) to offload rules that don't have anything to do with each other to a separate process. For example, run VRT Balanced on one process and the ET rulesets relating to rbn, botcc, and currentevents on another.

I've had a couple occasions where snort wouldn't shutdown correctly and I end up with two processes on a single interface which both grab traffic (based on CPU usage). Why not do it intentionally?

Thoughts?

Within the current GUI code that can't happen because it tests for an interface already being "Snort-configured" before letting you save a newly added interface. So from that narrow point of view the answer is "no, it's not technically possible". However, from a broader point of view, I suppose it could be done but it would take a lot of additional complexity within the GUI code to handle that situation. Some additional UUIDs would have to be assigned to each interface to identify each configured "thread" on an interface. This is because each Snort process needs it own separate configuration file and logging directories. Currently those are identified and named using the physical interface name and a UUID as part of the path name.

According to the Snort people (when comparing themselves to Suricata), the claim is no huge benefit to "threading" with Snort. I am not expert enough in all the subtleties to know, though.

I am quite close to having the Suricata blocking plugin ready, and Suricata is multi-threaded out of the gate. For the initial release, Suricata will use the same libpcap and pf table block mechanism as Snort does. This is because true inline IPS mode needs some critical changes in the ipfw code in pfSense.

Bill

jasonlitka

They claim there isn't a huge benefit to threading. They didn't say there wasn't a benefit to multiple processes. I believe that's the whole point behind PF_RING.

The difference here is that instead of distributing packets on a round-robin basis to identically-configured snort processes, I was proposing using multiple snort instances, each getting all the packets, with different rule-sets.

I agree that suricata should come first. If you plan to continue to maintain snort after suricata's "completion" though, I'd like to push this as a feature request.

bmeeks

@Jason:

They claim there isn't a huge benefit to threading. They didn't say there wasn't a benefit to multiple processes. I believe that's the whole point behind PF_RING.

The difference here is that instead of distributing packets on a round-robin basis to identically-configured snort processes, I was proposing using multiple snort instances, each getting all the packets, with different rule-sets.

I agree that suricata should come first. If you plan to continue to maintain snort after suricata's "completion" though, I'd like to push this as a feature request.

OK. After I get Suricata out with blocking, then I will see what it would take to implement this and then discuss with the Core Team devs. Sometimes they have alternative suggestions or desires.

Bill

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