@bmeeks thanks for your great help!!!

@talaverde said in ET Open Ruleset not downloading: pfBlockerNG is a possiblity A package such as pfBlockerNG is a very useful tool, but it can be misused or misapplied sometimes leading to frustration. It works essentially as a long list of IP addresses to be blocked. Those lists can be configured from many sources. Not all of the sources are "current", and even those that are can frequently contain errors in the form of a legitimate web site IP address or netblock being lumped into a "bad actor" list. So when you have a security tool such as an IDS/IPS layered with another security tool such as pfBlockerNG, you have to immediately consider any "failing to connect" issues on your network as being caused by one of those packages. So in your case, if I saw failing ET-Open downloads, my first instinct would be to check my pfBlockerNG blocks to see if the address had gotten inadvertently blocked. The rules vendors use various CDNs (content distribution networks) to host their rules file for worldwide download. Sometimes a pfBlockerNG list might get overly aggressive and block one of those CDNs (or a segment of a CDN) because a bad actor IP lives in the same netblock. This has happened to folks in the past with AWS addresses. In the same vein, if I had connectivity issues on a client with a web site or other service, I would check both the IDS/IPS alerts to see if the address showed up there as well as the pfBlockerNG alerts to see if something there tagged it. I would do that before I considered anything else on the client itself. Neither of these tools (Snort/Suricata nor pfBlockerNG) is a "click it on and forget it" type of package. They require constant baby sitting by a knowledgeable admin. So in the future, when you have any kind of connectivity issues outside of something obvious like a hardware failure, look first at your IDS/IPS and pfBlockerNG tools as the source of the connectivity issue. Only after eliminating both packages as the cause of the "block" should you look at potential client issues such as software bugs or something.

@pftdm007 said in Snort intermittently seems to crash, trying to find why: @bmeeks Thanks for letting me know that! I did not happen to browse the forums about this specific issue/topic... I think these services should not be available in Watchdog's available services to monitor if this is that critical? Anyways, +1 for implementing a real monitoring feature for such critical processes I think.. Snort and Suricata are unique in how they operate. They are quite different from services such as the ntpd daemon or something like sshd, for example. The two main differences are Snort and Suricata spawn separate executables for each configured interface, and both services restart themselves following a rules update. If you have LAN and WAN instances of Snort or Suricata configured, that means two separate snort or suricata processes are running: one per interface. Service Watchdog simply does the equivalent of a ps -ax | grep snort to see if a monitored process is running. So if it finds any snort process with that query, it is happy. But Snort might be running on the LAN yet have crashed on the WAN. Service Watchdog would never know that. The other thing that trips up Service Watchdog is that it does not understand that Snort and Suricata restart themselves following a rules update. So if Service Watchdog happens to test for the existence of a Snort or Suricata process during that rules update restart, it will find no running instance and immediately try to start one up. That will likely collide with the restarting Snort or Suricata is doing itself following the rules update and can result in a crash.

@bmeeks reading learning, thanks again!!!

@sandeep335577 said in Snort - not working with HTTPs urls/IPs: I am using snort with my pfsense. I have added two IPs(By doing ping command for two different sites) in my IP lists file section and then marked the file as a blacklist file inside wan/lan. When i try to open non-https urls it gets blocked but the url with https doesnt get block. My first suspicion is that the two URLs are actually resolving to different IP addresses (but that would definitely be weird if they are supposedly the same site). Snort does not care about the protocol at all when using an IP blacklist. It only goes by the IP address.

You can use the IP Reputation feature to accomplish this. First, upload an IP list containing the IP addresses of hosts you wish to exempt from Snort rules. You do this on the IP LISTS tab of the Snort GUI. Next, go to the LAN INTERFACE SETTINGS tab in Snort and edit the LAN interface. Choose the IP REP tab. There you will enable whitelisting by adding/selecting the IP list you uploaded earlier. Details on Snort whitelisting and blacklisting can be found in the Snort docs here.

Perfect. That's what I needed to know. Now I have a new project to work on. Thanks! I'm already running my pfSense firewalls on HyperV. I don't have any unused physical ports, unless I un-team some. However, I'm sure I could simply add another internal network to my pfSense VM and connect the Kali Linux VM that way. I'll figure out something. Again, thanks.

Hey is saying that since there is detection listed for it ciscos VDB, that there is prob a rule... My guess would be openappid could be used to detect it.

You cannot populate aliases with either the Snort or Suricata packages. They are just not designed for that purpose. Also, Suricata does not have a DPI equivalent of Snort's OpenAppID feature. If I understand what you are wanting to do, I know of nothing that can do that. Sounds like you want to dynamically route traffic depending on the packet type (after a Layer 7 deep packet inspection to identify the underlying app protocol).

A high core count CPU like you have will definitely need more memory allocated for the TCP Stream Memory Cap. With 8 cores I would start with 256 MB and test upwards from there. The parameter is found on the FLOW/STREAM tab. View the suricata.log file for the interface on the LOGS VIEW tab to see if you are hitting a Stream Memory Cap limit.

The pull request to update the Suricata package to 4.1.3 has been posted for the pfSense developer team to review and merge into pfSense-2.5 DEVELOPMENT. Here is the link: https://github.com/pfsense/FreeBSD-ports/pull/631.

Thought i would post for my own reference and anyone else with this problem.... Rebooting the firewall results in Suricata listening on all interfaces with 1 instance (startup). So, the problem fixed itself.

Yes, Snort and Suricata are IDS/IPS packages that can be used in pfSense. Google would be a great place to compare features and differences. (Lots of reading available on the subject) If you are trying out either for the first time, BMeeks posted a reply to a question for another user trying out Snort that may be of some use for you. (another good read): https://forum.netgate.com/topic/141743/best-rules-to-best-protection-in-wan-and-lan-interface/2

Hmm... that sounds like something you might want to ask the upstream Suricata team. I'm not sure of its significance. The Suricata bug reporting/issues site is here: https://redmine.openinfosecfoundation.org/projects/suricata. When giving them your configuration, tell them you are using inline IPS mode with netmap on FreeBSD. If you are on pfSense 2.4.x, then the FreeBSD version is 11.2; if you are using pfSense-2.5-DEVEL, then the FreeBSD version is 12.0.

@bmeeks thanks a lot!

Thank you both for your input. Yes this will be a huge learning curve for me. I will keep on analyzing.

I'll probably just run anti-malware then and front everything in the DMZ with a WAF. I already have it behind NGINX and cloudflare. Thanks for the help!

@bmeeks said in Still seeing suricata stop an interface due to .pid error: @val said in Still seeing suricata stop an interface due to .pid error: @bmeeks PM you the log file....it's way to big to post here. Thanks bmeeks. I looked through you log file. What version of the Snort Rules Snapshot file are you using? You should be using only rules packages for Snort 2.9.x if you are running Snort rules with Suricata. Your file name should be snortrules-snapshot-29120.tar.gz. Do not use the Snort3 rules (that means do not use any Snort rules file with 3 in the name). You should not be seeing those "unknown reference" error messages. The only time I've noticed those is when the user has downloaded the rules meant for use only with the new Snort3 beta package from the Snort team. Hi bmeeks I have since moved away from suricata backon Snort for now, my internet connection it's through an PPPoE connection so from my understanding suricata doesn't play well with PPPoE. I have tried few difference thing all result the same suricata still kill it self and wouldn't start again til I delete the pid file. Thanks for all the help.

If you can't figure out how !any got there, i'd be tempted to remove snort after unticking Keep Snort Settings After Deinstal then do a re install. I'd follow these steps to configure snort as written by @bmeeks who maintains the snort package. https://forum.netgate.com/topic/55095/quick-snort-setup-instructions-for-new-users/147