Snort 2.9.4.6 pkg v2.6.1
-
It looks fine to me. :(
how do you imagine a better way to see a text file?
-
Looks like it has duplicate lines and
other formatting issuesodd line order. Or possibly the Snort update process is acting up on my system. -
Looks like it has duplicate lines and
other formatting issuesodd line order. Or possibly the Snort update process is acting up on my system.I think the update process is somehow borked on your setup. I have never seen that in my testing environment nor on my production system. Can you look in /etc/crontab and see if more than one Snort rule update job is in there? There should be just a single line calling snort_check_for_rule_updates.php. From the looks of that log file, it does appear multiple processes are trying to write to it at the same time or something.
Another thing to check is that you don't have multiple duplicate Snort processes running on the same interface. That was a problem some back that was supposed to be fixed in the 2.6.0 update. Execute this command and see if you see any duplicate lines in the output. If you do, shutdown Snort, then kill any remaining Snort processes and restart. You can also reboot the firewall if desired.
ps -ax | grep snortBill
-
I nuked my Snort setup and I'm currently setting up things again. The first rules update log looks much better. Before I didn't even get the update finished line.
Starting rules update... Time: 2013-11-07 18:15:50 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Checking Snort VRT md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2946.tar.gz'... Done downloading rules file. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Emerging Threats Open md5. There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading Emerging Threats Open rules file. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Extracting and installing Snort VRT rules... Using Snort VRT precompiled SO rules for FreeBSD-8-1 ... Installation of Snort VRT rules completed. Copying new config and map files... Warning: No interfaces configured for Snort were found... The Rules update has finished. Time: 2013-11-07 18:16:51 -
I nuked my Snort setup and I'm currently setting up things again. The first rules update log looks much better. Before I didn't even get the update finished line.
Starting rules update... Time: 2013-11-07 18:15:50 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Checking Snort VRT md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2946.tar.gz'... Done downloading rules file. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Emerging Threats Open md5. There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading Emerging Threats Open rules file. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Extracting and installing Snort VRT rules... Using Snort VRT precompiled SO rules for FreeBSD-8-1 ... Installation of Snort VRT rules completed. Copying new config and map files... Warning: No interfaces configured for Snort were found... The Rules update has finished. Time: 2013-11-07 18:16:51Yep…that log file looks normal. I don't know what could have been going on with your previous install. Let me know if things mess up again.
Bill
-
I have seen this before on a previous install a few releases ago (multiple update attempts in sequence).
An uninstall then fresh install fixed it.
-
And my Snort seems to be all crazy again. Only one Snort process running at the moment and Cron looks good also with just one copy of snort_check_for_rule_updates.php
Starting rules update... Time: 2013-11-08 12:20:01 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Starting rules update... Time: 2013-11-08 12:20:01 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Starting rules update... Time: 2013-11-08 12:20:01 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Emerging Threats Open md5. Emerging Threats Open rules are up to date. The Rules update has finished. Time: 2013-11-08 12:20:03 Checking Emerging Threats Open md5. Emerging Threats Open rules are up to date. The Rules update has finished. Time: 2013-11-08 12:20:03 Checking Emerging Threats Open md5. Emerging Threats Open rules are up to date. The Rules update has finished. Time: 2013-11-08 12:20:03Edit:
I'm also seeing other things going off three times instead of once, what in the system could be causing this? I'm on pfSense:
Version 2.1-RELEASE (amd64)
built on Wed Sep 11 18:17:37 EDT 2013
FreeBSD 8.3-RELEASE-p11Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblocktor does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeretRBNmalvertisers does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerMalwaredomainlistcom does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerCIArmy does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockwebexploit does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerblockspyware does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockhijacked does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblocktor does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeretRBNmalvertisers does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerMalwaredomainlistcom does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerCIArmy does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockwebexploit does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerblockspyware does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockhijacked does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblocktor does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeretRBNmalvertisers does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerMalwaredomainlistcom does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerCIArmy does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockwebexploit does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerblockspyware does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockhijacked does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Sleeping for 11 seconds. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Starting up. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Sleeping for 24 seconds. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Starting up. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Sleeping for 39 seconds. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Starting up. -
Hi Bill. Would it be a good option to increase the snort widget number of rows to 10 or 20 and make it update in a fixed interval of 10 secs independently of the entire dashboard GUI?
To refresh the dashboard, I need to refresh the entire GUI and change the default autoscale back to follow on a number of interfaces.
-
Hi Bill. Would it be a good option to increase the snort widget number of rows to 10 or 20 and make it update in a fixed interval of 10 secs independently of the entire dashboard GUI?
To refresh the dashboard, I need to refresh the entire GUI and change the default autoscale back to follow on a number of interfaces.
I don't know about the refresh stuff. The Dashboard Widget for Snort was written by someone else. I can study it a bit and see if I can understand better how it works. I've only made a couple of really small tweaks to it. Perhaps a configuration link could be added like some of the other widgets have (the Services widget is one that comes to mind). That would let a user set their own configuration preferences. Not promising anything until I can get into and understand that code better, though.
Bill
-
And my Snort seems to be all crazy again. Only one Snort process running at the moment and Cron looks good also with just one copy of snort_check_for_rule_updates.php
Starting rules update... Time: 2013-11-08 12:20:01 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Starting rules update... Time: 2013-11-08 12:20:01 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Starting rules update... Time: 2013-11-08 12:20:01 Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'... Checking Emerging Threats Open md5. Emerging Threats Open rules are up to date. The Rules update has finished. Time: 2013-11-08 12:20:03 Checking Emerging Threats Open md5. Emerging Threats Open rules are up to date. The Rules update has finished. Time: 2013-11-08 12:20:03 Checking Emerging Threats Open md5. Emerging Threats Open rules are up to date. The Rules update has finished. Time: 2013-11-08 12:20:03Edit:
I'm also seeing other things going off three times instead of once, what in the system could be causing this? I'm on pfSense:
Version 2.1-RELEASE (amd64)
built on Wed Sep 11 18:17:37 EDT 2013
FreeBSD 8.3-RELEASE-p11Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblocktor does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeretRBNmalvertisers does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerMalwaredomainlistcom does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerCIArmy does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockwebexploit does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerblockspyware does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockhijacked does not need updated. Nov 8 12:30:39 php: rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblocktor does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeretRBNmalvertisers does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerMalwaredomainlistcom does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerCIArmy does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockwebexploit does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerblockspyware does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockhijacked does not need updated. Nov 8 12:30:24 php: rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblocktor does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeretRBNmalvertisers does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerMalwaredomainlistcom does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerCIArmy does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockwebexploit does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockerblockspyware does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: pfBlockeriblockhijacked does not need updated. Nov 8 12:30:11 php: rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Sleeping for 11 seconds. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Starting up. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Sleeping for 24 seconds. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Starting up. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Sleeping for 39 seconds. Nov 8 12:30:00 php: rc.update_urltables: /etc/rc.update_urltables: Starting up.Fragged:
I really don't know what is going on with your setup. Something is definitely weird. Did you remove just Snort? I'm wondering if something is off in either your config.xml file or even with the base pfSense install itself. The fact other packages are showing duplicate or triplicate log entries points to something other than just the Snort package.
Bill
-
I have done a complete reinstall + recovery of my settings.xml and so far so good, though there haven't been any Snort or ET rules updates yet. There must have been something wrong with my base pfSense setup, which I've had from 2.0.3 -> 2.1 snapshots -> 2.1 release.
-
I am running Snort 2.9.4.6 pkg v. 2.6.1 and have set the WAN Interface to Block Offenders and Kill State. Its set to block the SRC.
I am also using an IPS program called "Security Onion" which also uses Snort and it has captured the same packets that were supposed to be Blocked at pfSense level.
Is this normal? or am I missing some configurations?
-
@BBcan17:
I am running Snort 2.9.4.6 pkg v. 2.6.1 and have set the WAN Interface to Block Offenders and Kill State. Its set to block the SRC.
I am also using an IPS program called "Security Onion" which also uses Snort and it has captured the same packets that were supposed to be Blocked at pfSense level.
Is this normal? or am I missing some configurations?
Make sure of two things.
First, both Snort on pfSense and the Security Onion appliance, ensure the exact same rules are being used. Also verify and scrub the hits you see on Security Onion against the auto-whitelist in Snort. Could be you are seeing packets captured on Onion that matched the whitelist in Snort (and thus were not blocked) on ingress.
Second, my recommendation is to operate Snort blocking in the BOTH mode (that is, block source and destination IP addresses).
Bill
-
Hello Bill,
Please see the screenshots below. You can see the alert and the block in pfsense. There is no entry in the Whitelist WAN or LAN for this Wan IP or Sig ID. The Alert is also
in Security Onion with the same Sig ID. This alert is a false positive but it should still have blocked it.I have also attached the full packet capture from Security Onion. I changed the ext to .TXT (Hope it attaches properly)
If I block both the SRC and DST wont that kill the ability for the alerted LAN address to access the Net?
If you need any further details please let me know.
[Wireshark 11-20-13.txt](/public/imported_attachments/1/Wireshark 11-20-13.txt)
-
Screen shot didnt attach. Please see attached jpg file.
-
@BBcan17:
Hello Bill,
If I block both the SRC and DST wont that kill the ability for the alerted LAN address to access the Net?
If you need any further details please let me know.
No, the auto-whitelist will keep it from actually blocking the LAN addresses. This is because locally attached networks like the LAN are automatically added to the whitelist. By choosing BOTH for the block parameter, this catches an offending IP no matter which way the traffic is flowing. However, this setting is only for blocking. The alerting in the logs is not dependent on that setting.
Bill
-
@BBcan17:
Screen shot didnt attach. Please see attached jpg file.
Looking at the attached images (the JPG was cut off a bit in my browser window), it appears the traffic was alerted and blocked by Snort. Or least an entry was put in the pf table (snort2c). That's all Snort can do. After that it is up to the packet filter engine in FreeBSD to do the rest. Where exactly is the Security Onion appliance in the network traffic path as compared to Snort on the pfSense firewall? Could it be they are both seeing the traffic in parallel? I'm asking how exactly the Onion appliance is wired into the network such that it is seeing WAN traffic.
Bill
-
Thanks Bill,
I will try to block/kill the SRC/DST and see if that fixes the issue.
The Lan side of pfSense goes to a Switch which span/mirrors the traffic to Security Onions sensor port.
On another note - Would it be possible to Add a comment line to the Suppression process when we select "Add this alert to the suppress list" or "Add this alert to the suppress list .. DST/SRC" This way you can record the reasoning behind some of the Suppressions?
Thanks
-
@BBcan17:
I will try to block/kill the SRC/DST and see if that fixes the issue.
The Lan side of pfSense goes to a Switch which span/mirrors the traffic to Security Onions sensor port.
I don't think this will necessarily fix the issue, but it's worth a try. Can I assume from your reply about the sensor location that one of those IP addresses is in your LAN and you are not using NAT?
@BBcan17:
On another note - Would it be possible to Add a comment line to the Suppression process when we select "Add this alert to the suppress list" or "Add this alert to the suppress list .. DST/SRC" This way you can record the reasoning behind some of the Suppressions?
That might be possible. I will file it away for some future feature adds. The next big release is already packaged (version 3.0.0) and it's too late to add more features. That version, when released, will add support in the GUI for multiple target engine configurations for five of the preprocessors (frag3, stream5, http_inspect, ftp_server and ftp_client).
Bill
-
Great stuff. I dont know what i would do without pfsense and snort.
I also notice that when I am viewing the alert list and select the "+" or "x' buttons for suppression that the refresh of the screen brings me to another snort interface alert list.
Yes the alert was for an IP on the same network (10.1.xx.xxx) as the pfsense LAN port.
