@GemeenAapje: Hi guys I'm trying to configure snort to add some additional security to be web server. At the moment I'm running it and monitoring the alerts without blocking. My web server is within my home network and I'm running snort on pfSense router on the WAN interface only. Is this correct practice? One thing i see, for example, is when I'm using Deezer that I see my own external IP flag up as accessing iTunes, for example "ET POLICY iTunes User Agent" Before I enable blocking, I really want to be 2000% sure that my own IP is never going to be added to the banned list, blocking my web server from accessing the outside world. Any advice greatly welcome. Thanks Matt For home users I recommend running Snort on the LAN.  This lets you see actual LAN host IP addresses in the alerts.  If you run Snort on the WAN, then you can't see local LAN host IP addresses in any alerts.  Instead, all local host IP addresses will be the WAN IP of the firewall.  This is because Snort on the WAN sees inbound traffic from the web before the NAT rules are applied, so the destination IP for inbound Internet traffic is the external IP of the firewall.  When you run Snort on the LAN, it sees traffic after NAT has been removed, so the actual internal IP addresses of LAN hosts appear in the alerts. Snort has built-in safeguards that prevent the actual IP interface addresses on the firewall from being blocked.  If you get alerts from rules that you know are OK in your environment (such as that ET POLICY rule in your example), then you can disable those rules.  Be careful just enabling all the rule categories!  You will get a lot of noise.  For example, that ET POLICY rule set is mainly there for corporate network admins where corporate IT policies are in place that may forbid employees from accessing iTunes at work.  The admins would want an alert if an employee was attempting to access iTunes.  For a home user, this policy rule is likely not useful unless you really hate Apple and use only Google Play  :D. Bill

@pffan: Thanks for the response. I am testing from inside the LAN but I figured that because IIS bound traffic is exiting the LAN interface, it is subject to fw rules and thus snort inspection.  Also the preprocessor rules are generating alerts okay. The external net variable has been customized.  Not sure where the ipv6 address came from but the others are ips of my pfsense interfaces. I think the problem might be due to my custom pass list which I tried to make empty.  The local interface addresses are added automatically.  Can you confirm if traffic originating from an ip in the pass list is still checked?  Or is it just discarded immediately?  I think that might be the problem. One other thing I didn't mention is that haproxy is adding x-forward-for headers to http traffic and I was hoping to detect and block those addresses when offensive.  Is that possible or am I going about this the wrong way? A pass list entry prevents that IP address from being blocked, but it has no impact on the alert showing up on the ALERTS tab.  So the pass list has no bearing on what alerts you see.  It only determines whether or not the IP itself gets added to the "blocked IPs" snort2c table in the pf firewall. In your case, a failure to see alerts would be due to one or both of the following:  (1) the traffic in question is not actually traversing the firewall, or (2) the IP addressess in HOME_NET and EXTERNAL_NET are not correct in terms of the rule's logic, and thus the rule is not triggered. Bill

@bmeeks: You can turn if off, but if any of your enabled rules use keywords or rule options specific to the SIP preprocessor, then you will get errors when Snort starts up and it will not start successfully.  I would suggest simply disabling the rues generating the "noise" and leave the default preprocessor set enabled. Yes, that's what I meant: disable the individual rules, not the whole rule set. Thanks.

@bmeeks: @bimmerdriver: The system that is having the MD5 errors is running version 2.4.2. The system that is working properly is running the latest 2.4.3 snapshot. Is it possible a difference between the respective snort packages is the reason for the difference? There was an update to the Snort GUI a month or two back that updated the URL used for downloading the OpenAppID rules package.  Perhaps your older version is trying the older URL? The current Snort GUI package version is 3.2.9.6. Bill I updated the package and the problem is fixed. Thank you very much.

There are no LAN alerts in snort alert tab. I've just left it as it is, everything is working just fine.

@bmeeks: @drewsaur: THANK YOU! I completely missed that. That key point is hidden via the "i" icon. I think they should leave that information visible by default! Yeah, the default state of those "Information" icons is collapsed.  I think that was state was chosen in order to reduce clutter. Bill May I suggest that the text "Check the box beside an interface to immediately apply new auto-SID management changes and signal Suricata to live-load the new rules for the interface when clicking Save; otherwise only the new file assignments will be saved" be outside of the "info" icon? It seems essential to the UI and is non-obvious. The remainder of the text is certainly a candidate for the "i" icon :) Cheers!

@bmeeks: @gryest: Hi I noticed Snort turned itself off past few days after rules update. Rules update success but found Snort is stopped??? Not good at all. I was OK before even if rules update failed, it's never stopped by itself. I ran Snort package update 2 day ago but it still doing that. Is anybody have same issue? What might be wrong or changed? Thanks. PS. i have Snort logs setup on local system (SSD) and checked log size option are limited. Log exceed memory should not be an issue. Have you looked back through your firewall's system log to see what, if any, messages might have been logged by Snort as it restarted from the rules update?  The most likely possibility is a rule syntax error of some sort with one of your enabled rules (or even a newly added rule).  Those happen from time to time as the rules are modified by the authors/vendors. Bill Yes, I did. Rules update happened 00:07. Before that Snort shows some ping IP ("Misc Attacks") Log Alerts. After 00:07 nothing until I restarted snort in the morning. No any records in the system log. I will check logs if it's happen again. Thanks.

TL;DR:  "Why Not?"  :) A couple reasons, neither important: I am running snort for recreational reasons on a small appliance.  Getting it to work on a RAM disk kept me occupied for a few minutes. My "day job" is HPC systems at extreme scale.  In that environment most solutions are stateless root for reliability and performance reasons.  Those concerns probably bias how I approach recreational programming. I think you're correct about average SSD reliability being more than adequate for pfSense deployments. At large scale it's still something we worry about, and my pfSense box had enough RAM, so "why not".  As long as pfSense has the option, my OCD side says it should work regardless of which packages I select.  It did not, so I fixed it. Proper fix would probably be for the pfsense base to copy out all of /var/db rather than just /var/db/rrd.  The additional directories don't add much space.  Or stop providing the RAM disk option.  :)

@bmeeks: @Nixus: Hi everyone, Is it possible to get a list of the force-disabled rules from [Force-disable this rule and remove it from current rules set.] in the Alerts tab? No, that is currently not an available feature.  It would make a good future enhancement, though.  I will put it on my TODO list for a future update. Bill Thanks! That would be a really nice feature! :)

Thanks, I did try that, and just tried it again as well.  I removed snort, manually removed the cached package, reinstalled.  I then updated the rules, created a LAN interface, and started it.  No other settings were changed and it crashed

Removed and reinstalled snort, issue is resolved. Perhaps a simple restart would have done the trick as well.

@The: Hi @bmeeks Thank you so much again for the explanation, I actually added Suricata to watchdog service after noticing this issue, but as you mentioned it doesn't really know how Suricata service work so I was noticing the CPU usage is much higher everytime I manually restart Suricata from the interface tab, I removed it from watchdog now. Thanks. I will fix the GUI issue with showing the status correctly on the INTERFACES tab.  Probably will be sometime next week, though, before I can get it put together and posted. Bill

@Beerman: Will it also fix the Problem with the "Host Attribute Table"? See: https://forum.pfsense.org/index.php?topic=135137.0 Thx! :) I will have to re-test and see. Bill

@Wroxc: OK seems like /tmp was full. Resolved my issue by increasing the /tmp size to 300MB since i have plenty of ram Yep, Snort and RAM disks are not friends!  I don't recommend that configuration, but if you do, make sure you have at least 300 MB configured for /tmp and the same or more for /var if that is also a RAM disk.  Snort downloads and extracts rule updates into /tmp, and all the logs are on /var. Bill

i too am having same issue. i will also wait to see if it resoles for itself

@Bill: OK. Required a bit of extra shell action. After removing package, hunted down leftover bits in the filesystem. rm -rf /usr/local/etc/snort rm -rf /usr/local/lib/snort_dynamicrules rm /var/cache/pkg/*snort* Also grep'ed globally to find references to snort. In config.xml I found that it still had stuff about snort and there were two sqlite databases that contained references. I didn't bother with those, but I did open up config.xml and found all the basic setting properties in there. So removing doesn't really remove. That's not cool. But I left it there not wanting to break anything. I did notice that there was a space in front of my oinkcode though! :) When reinstalling the package, I made sure to remove that and when I did the update it went fine. You can remove Snort and have it clean up after itself.  The default is to "save settings" because most folks want to remove and reinstall or update the binary while keeping their existing configuration settings.  On the GLOBAL SETTINGS tab is a checkbox option to save settings when uninstalling the package.  The box is checked by default, but you can uncheck the box and when you remove Snort it will remove all traces of itself from the config.xml file.  That of course means any and all of your previous Snort configuration settings are gone. The directories you found are being left because of a bug in the uninstall code.  That should be fixed in the latetst package version.  The only exception would be if you manually modified any files in those directory trees. Bill

No, I don't believe the binary supports text wildcards.  You can use very large network blocks by specifying a large subnet mask when you suppress by IP, but that trick does not work for text.  The only supported options for suppression are "by IP" and "by GID:SID". Bill