Snort 2.9.4.6 pkg v2.6.1
-
An updated Snort package is now available. Release notes are below.
Bill
Snort Package v2.6.1 New Features
This update adds support for the Emerging Threats Pro ruleset to the Snort package. The ETPro ruleset is mutually exclusive to the Emerging Threats Open (ETOpen) ruleset. Because the ETPro ruleset contains all of the ETOpen rules in addition to a number of others, it is not necessary to run both rulesets simultaneously. When the ETPro ruleset is selected, the ETOpen ruleset is automatically disabled. ETPro rules require a paid subscription through the Emerging Threats service. You must enter your ETPro subscription code as part of the configuration.
Tool Tip pop-ups now appear for form field textboxes in the Snort GUI where Aliases are used as the value. The Tool Tip pop up displays the resolved string value of the Alias when you hover your mouse over the textbox.
Automatically enabled Flowbit Rules can now be selected on the RULES tab the same as any other rules category. You can manually disable auto-flowbit rules if you have good reason for doing so, but the recommended method for dealing with unwanted alerts from auto-flowbit rules is to add a Suppress List entry instead. Disabling an auto-flowbit rule can result in unintended consequences including a reduction in overall protection. You need to fully understand the role of auto-flowbit rules in Snort and their impact on the security posture before choosing to disable one! A link is now provided on the RULES tab page when "Auto-Flowbit Rules" is the selected category for adding a Suppress List entry.
–----------------------------------------------------------------------
IMPORTANT -- Snort Package Functionality Change
------------------------------------------------------------------------Snort package update 2.6.0 introduced limited support for using Fully-Qualified-Domain-Name (FQDN) Aliases in some configuration parameters. This required a pair of package-specific custom functions for resolving FQDN Aliases because the built-in pfSense function does not support resolving FQDN Aliases. The Core Team package review rejected adding these two custom functions in the Snort package; therefore they have been backed out, and support for FQDN Aliases has currently been removed from the Snort package. This functionality may return in a later update when a suitable method exists natively in pfSense to allow packages to resolve FQDN Aliases. You can still use Host, Network and Port Aliases in Snort configurations. The only limitation is that any Host Aliases must be defined with specific IP addresses and must not be FQDN hosts.
Snort Package Bug Fixes
Port Aliases containing port ranges (such as 137:139, etc.) in their value were not being expanded into the full list of individual ports prior to being written to certain preprocessor configuration lines in the snort.conf file.
The Download buttons on the ALERTS and BLOCKED tabs now function properly to download the alert logs and blocked IP address lists. The downloaded file is a gzipped UNIX tar archive (*.tar.gz).
-
Thanks Bill!
Did the core team give any reason for wanting to break FQDN support?
-
Thanks Bill!
Did the core team give any reason for wanting to break FQDN support?
They were worried about extra work for the filterdns process and some other internals of pfSense. I think some improvements may come along later that will let FQDN support back into Snort and other packages. Of course the FQDN support that was there in 2.6.0 was very limited and definitely nowhere near realtime. The Aliases were only evaluated and updated on a Snort restart when the snort.conf file was rebuilt. So that is another reason for not including the support since it really does not work like FQDNs do in other parts of pfSense (meaning the Alias values do not get updated on the 5-minute interval).
Bill
-
I vaguely remember something about fixing the update log file formatting. Was this change made in this version or the planned 2.7 package version with new binary? My log file still looks rather horrible (see picture).
-
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.
-
Hello Bill,
I changed the Blocking to both SRC/DST but I noticed that this one alert was blocked in pfSense but Security Onion picked it up.
See the jpg attached.
-
@BBcan17:
Hello Bill,
I changed the Blocking to both SRC/DST but I noticed that this one alert was blocked in pfSense but Security Onion picked it up.
See the jpg attached.
Is this routine or more random? What I mean by that is does it seem to leak all the packets that should have been blocked, or is it more like randomly it does this? I'm asking to see if this might be tied in any way to the random clearing of the block table. I doubt it is, but just checking all possibilities.
It certainly does appear from your captures that the packet is supposedly "blocked", but it leaks by anyway to the LAN. I do notice a 5 hour time discrepancy in the Snort log entry versus the Security Onion entry. The times match on the minute and second, but the hour is off. I'm assuming this maybe is a time zone issue with one of the devices.
This is obviously not supposed to happen, so I would like to get to the bottom of it. Unfortunately this is likely to require some pfSense uber-geek magic to figure out. The packet filter and all the network stack stuff in pfSense is not my area of expertise. Perhaps we can get one of the Core Team developers to take a look. I will ping them with a link to this thread to see if one will weigh in.
Bill
-
Hi Bill,
Activity has been fairly low today, but I would say that most alerts are passing thru unblocked. The things that I dont see in Security Onion are the DROP/DShield/ET RBN's alerts in snort but that activity could also be drooped by the router.
I am in EST and Security Onion is configured in UTC time so that is your time difference.
I have three NICs installed on this router. I have two WAN addresses but only one GW. I have been trying to get Multiwan to work without success.
http://forum.pfsense.org/index.php/topic,64682.msg374930.html#msg374930I have the second WAN Disabled for several weeks and I also had disabled the Snort Interface for this 2nd Wan port. However, today i noticed activity in this disabled Wan2 port Snort interface. It didnt match the snort alerts from Wan1.
So this afternoon, I deleted the WAN2 interface and also deleted the snort interface and Rebooted pfSense.
This didnt fix the issue but I thought I would share that with you just in case,
-
Bill,
The router is set for Automatic Outbound Nat but there were 4 entries from the Manual Outbound NAT that I was working with a few weeks ago. I have since cleared the Manual rules and restarted pfSense.
-
@BBcan17:
Bill,
The router is set for Automatic Outbound Nat but there were 4 entries from the Manual Outbound NAT that I was working with a few weeks ago. I have since cleared the Manual rules and restarted pfSense.
I sent a request via e-mail to the pfSense Core Team asking for one of them to take a look at this thread and see if they had any thoughts about what might be going on. It's weird that the blocks are getting set in the packet filter table, but yet some traffic still seems to get through.
Bill
-
@BBcan17:
Hi Bill,
…The things that I dont see in Security Onion are the DROP/DShield/ET RBN's alerts in snort but that activity could also be drooped by the router.
Can you elaborate a bit more on this statement. Are you saying you have some of the ET RBN and ET CIARMY rules enabled on the WAN side of pfSense in Snort, and those are all getting blocked but traffic matching other rules is not being reliably blocked?
Bill
-
Yes It was blocking DROP/Dshield/ET RBNs/CINS but i didnt see any CIARMY.
There were also blocked port scan sweeps and ET SCAN Sipvicious.
I didnt see any of that in Security Onion. I dont think I have ever seen one of those alerts.
https://code.google.com/p/security-onion/wiki/ManagingAlerts (They do have them as part of the rulesets.)
-
Hi Bill,
I removed all of my suppression lists to try to get something to come in and get an alert and I got an alert and a block but Security Onion still picked the blocked packets up even after my changes. Could there be some other setup/config issue that I could check?
The blocked ip is in the snort2c table.
I also found this interesting. I set a block on sig 1:2013504 (ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management)
I requested apt-get updates on the Security Onion Box and part of the updates came thru before pfSense/Snort kicked in and blocked the remaining.
See attached Jpg.
-
Without reading the previous replies to this thread (just glanced at the above couple of posts tbh), you are seeing the intended behaviour of snort. Snort in pfsense is not running drop rules, but alert rules. The reason you might see traffic behind the snort box is that (as I said in the past) snort doesn't actually block any packets. I'll reuse a previous analogy I used:
Snort in pfsense (an IDS):guy sitting in a room, watching the CCTV feeds. He picks up the radio and radios to a security person "hey, guy in the red jacket, pick him up". The downside is that while the guy is watching the guy in the red jacket, the one in the blue jacket gets through. They later decide that no jacket guys are allowed, which prevends this from happening again (until pfsense decides to flush the block table,out of nowhere, of course).
Snort running drop rules (or any IPS): You wall off part of the corridor, and set up a metal detector, a security guard padding you down, full body search and all that. Everyone has to go through this to be let through.Summary: Snort will allow some packets through until the whole analyze/alert/ban cycle completes.
If I missed something, or I'm not making any sense, please do ignore me. It's too early in the morning and I haven't had the mandatory cafeine boost yet. Or the sleep.
-
Not if the one in the blue jacket gets blocked as well due to the "ET no jacket in the building" rule ;)
-
Not if the one in the blue jacket gets blocked as well due to the "ET no jacket in the building" rule ;)
What if the person observing them has a monitor in front of him, on which he watches the guy in the red jacket, while at the same time, the person in the blue jacket shows up on the monitor behind him? ;-)
What I was getting at is that some packets "leak through", I've seen it more than enough times by now. Sometimes, depending on the processing the snort box has to do, less packets get through before the eventual ban.
-
Snort strips him naked and scan his clothes without him noticing that… while stripping him naked, Snort discovers his jacket...and blocks him. ;)
-
So, to be perfectly clear, are you arguing that snort (as running in pfsense) should block packets (act as an IPS), or are you saying that snort should allow some packets through, while scanning them (act as an IDS)?
Because from what I've seen in multiple production environments, snort (as running in pfsense) acts as an IDS. Packets leak through, as I've said. -
What logs can I look at to see if Snorts performance ie-dropping packets or CPU/Memory issues?
From the main pfsense:Dashboard I never see any performance issues that would cause any concerns.
I have Snort blocking on the WAN SRC/DST and killing states. I also have Security Onion running immediately after pfSense performing Full Packet Capture and I am seeing every blocked alert from pfSenses Snort in my Security Onion Alert System. Both Running the same rulesets (Snort and ET)
-
Dropping packets in snort terms means blocking the packet. The reason that we say that they are being dropped it's that the rules actually start with drop instead of alert.
I'm guessing that you actually get alerts behind pfsense, because by the time that snort is finished with analysing the packet and sets up the ban, the packet is not actually stopped from going through the network. Imagine the packet getting copied on the fly, a copy is sent down the network, and the other copy is sent for analysis (overly simplified, gets the point across though). I'm willing to bet money that if you trigger a rule a second time, with some time between the triggers (let's say a couple of minutes just to be sure) you will not get the alert/lights/fireworks on the box behind pfsense for the second time.
A single host network (pfsense running snort, protecting 1 server/pc behind it) doesn't actually make a lot of sense. Sure you get alerts, but by the time the alerts are generated, the packets have already reached their destination. A multi-host network (pfsense running snort, protecting a dozen servers/pcs) makes a lot more sense.
Let's take this scenario (which is actually what I described in the past, about detecting network scans on multiple hosts): pfsense 192.168.1.1, host a 192.168.1.2, host b 192.168.1.3 and so on and so forth, until host xyz 192.168.1.100
An attacker sets up a network scan for an open port 22, pressumably because he forgot that this is 2013 and password based ssh logins are forbidden by international law and treaties (SET UP KEY BASED LOGINS NOW!). The scan (actually the program generating the scan) starts sending packets asking for a connection to port 22 (let's say simple syn packets for argument's sake). There are a total of 100 packets that should reach our network of 192.168.1.1-192.168.1.100. The packets start arriving at the pfsense host and start going through it (assuming that there is a port forward for port 22, just play along and stop arguing :p ). At this point, let's say that hosts 192.168.1.2-192.168.1.5 saw the packets and actually answered. Snort already picked up that this is a network scan for an open port, since it has a rule that says: "if x packets destined for y hosts arrive in z seconds, assume that a network scan is in progress and raise an alert". The process of banning a host has started, since the alert was raised. Packets are still flowing up to this point through the pfsense box, and hosts behind it are still answering those connection requests. By now hosts 192.168.1.1 up to 192.168.1.50 have actually answered those connections. The banning process is complete, and the firewall states are killed. This interrupts the flow of those suspicious packets through the network. It might sound futile, but you have actually protected the other 50 hosts just by using the 50 hosts that answered as a "decoy". The second time round, this time the attacker decides to scan for open port 25, the ban is already in place (assuming that you have snort fine tuned to the point of being called a psychiatrically unstable person and have the max ban time set at 28 days, hint hint). No packets are allowed through the firewall, and the entire network is protected. The bonus thing is, since snort actually raised an alert the second time round (imagine it as if snort is running in front of pf, it's extremely close to how it actually works in reality) since the packets get analyzed before being dropped (blocked) by pf, the "last time this host was bad" gets updated, and the remaining days to unban gets reset.That was a long post, but I tried my best to explain why you see packets flowing through the snort/pfsense box. If something is not along those lines ie. the alert is already raised, the banned hosts table is not automatically cleared, and the ban in other words should be effective but it's not, something is wrong with the pfsense rule blocking(dropping) those packets. By the time snort stands up and shouts "IT'S HIM, I'VE SEEN HIM!", the suspect is already identified and flagged as "most wanted". The second time round, no packets should be allowed through, and this actually has nothing to do with snort, it's all pf from there on.
Troubleshooting:
Start your packet capture behind pfsense. Manage to trigger an alert using an outside host (a host not part of your home network). Make sure that the alert is raised, and the host is added to the blocked tab (MAKE A NOTE OF THE TIME SHOWN HERE). Go into Diagnostics>tables>snort2c (off the top of my head, could be wrong) and verify the host is there. This completes snort's part. If the host is there, snort is working as expected. If the host is not there, snort is not adding it to the blocked table. The packet capture should show packets arriving behind pfsense, since this is the first time round.
Leave the packet capture running, and trigger the alert after a couple of minutes (to account for table refresh, updates to rules, cosmic events, etc etc) This time you should see an alert generated by snort, The blocked tab should by updated by the new time (since technically this is a new alert). The packet capture should NOT show any packets arriving behind pfsense. If it shows packets arriving behind it, then there is something wrong with the rule that pfsense uses to block hosts (using the snort2c table).Short summary for the impatient: First time round, you will see packets flowing through (a typical IDS). Second time round no packets should flow through.
Edit: fixing typos
-
Look…
Qoute from Snort.org
Snort is an open source network intrusion prevention system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.
Notice the REALTIME traffic analysis part....
In sniffer mode, the program will read network packets and display them on the console. In packet logger mode, the program will log packets to the disk. In intrusion detection mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified....
Notice that part where its says it will perform a specific action based on what has been identified.
Packet comes in at WAN -> gets analyzed -> put up against a predefined ruleset -> block or pass.
This happens in realtime!
So youre wrong.
