@bmeeks said in Suricata INLINE mode ban IP after X attempt: @Cool_Corona said in Suricata INLINE mode ban IP after X attempt: @bmeeks said in Suricata INLINE mode ban IP after X attempt: @Cool_Corona said in Suricata INLINE mode ban IP after X attempt: @bmeeks Yeah. Could it be done in INLINE mode as well?? No, keeping count of how many times a given IP has triggered a given rule is not possible in the current code for either mode of operation (inline IPS or Legacy Blocking). It just happens that Legacy Blocking sort of accomplishes that by blocking an IP completely the first time it triggers any ALERT rule. Could that feature be ported to INLINE mode? Could what feature be "ported"? There is no such feature available with either mode, so there is nothing to "port" to Inline Mode. I was simply stating that because of how Legacy Mode blocking works (by stuffing the IP address from an alert into the snort2c pf table), that a single alert by an IP is sufficient to get that IP totally banned. If I make Inline IPS mode do that, then it is no longer Inline IPS mode because you could not selectively block only certain types of traffic from an IP. It would be all or nothing. That would be really nice.

There are several third-party tools available that do things like that (including fancy charts). Check out an ELK or Grafana setup. Here is a link to a recent thread posted by @kiokoman detailing his Grafana setup: https://forum.netgate.com/topic/156330/pfsense-firewall-and-suricata-log-to-grafana-with-logstash-worldmap-panel.

@bmeeks Thank you Bill! I've re-read that, this time comprehensively, along with a complete read of "Taming the Beasts", truly a beast of a thread! While a lot of the material appears to be out-of-date, I definitely absorbed a lot from them and gained even more appreciation for the efforts from folks like you. I'm still a bit stunned by the sign off by @jflsakfja Among the things I have learned, if I have these correct: It is great to know about using a config file for disabling rules! Notes on my TODO list: SID Management, "Enable Automatic SID State Management" Add disableSid.conf Reference disableSid.conf under Disable SID File. State order should be "Disable, Enable" event_filter seems like it could be a good step before going full-draconian disable on a rule. TODO: find out if these can go into a config file too. The use of comments in disable lists is very helpful. I may want to add some "golden rules" to ID and put a quick end to port scanners, but don't think these will be helpful until I am setting up an installation where I need to open ports and am ready to go full-monty and start blocking. Something like this I think: drop tcp $EXTERNAL_NET any -> any !$MY_OPEN_PORTS (msg:"Golden Rule TCP"; classtype:network-scan; sid:9900001; rev:1;) drop udp $EXTERNAL_NET any -> any !$MY_OPEN_PORTS (msg:"Golden Rule UDP"; classtype:network-scan; sid:9900002; rev:1;) However, I am starting to wonder whether I can possibly have the time required to keep snort properly configured, as I don't support networks for a living, I develop software. I anticipate that many will say "maybe not, but then you won't have the time to deal with intrusion/malware either", and I would have to agree with that. I have two use cases to consider: Home/office network (protection from internal actors) Pretty happy with all of the protection afforded by pfSense, VLAN-capable switches/APs, and pfBlockerNG-devel, but I recognize the limitations, especially with family laptops spending time connected to other networks. I love the idea of using Snort to identify and stop acquired malware. Cloud-based web servers (protection from external actors) Simply keeping the bad guys out and combatting DoS, I guess that's it? (in addition of course, to keeping all software up-to-date, best practices, and all) Certainly, I can cobble together a greatest hits collection of rules to disable, but that seems like such a leap of faith to me. Is that my best course of action? For both use cases? thanks! Bill

Just in case anyone else has this issue. With suricata 5, just about any "strangeness" with a certificate gets marked as "invalid certificate". One such case is a missing Subject DN, which is the case with Active Directory LDAP certificates (they use Subject Alternative Name instead). It appears that with suricata 6 this will trigger an app-layer-event:tls.certificate_invalid_subject flag (most TLS issues now have their own flag), but that there are no alerts associated with this so hopefully it will go away.

@Michael9876 said in Need help with snort block rules: Thanks for the detailed answer @bmeeks. So in my case as a beginner: What should I understand by "tune" rules, what are the possibilities? Some rules will likely need to be disabled. It is quite common for a number of the HTTP_INSPECT preprocessor rules to false-positive with today's web technology and the widespread use of HTTPS. This link contains a long thread with input from a number of experienced IDS/IPS admins. It is a great place to start learing about "tuning" your IDS/IPS -- https://forum.netgate.com/topic/50708/suricata-snort-master-sid-disablesid-conf

@bmeeks - Bill - I've been meaning to log on and say thanks for your reply. I read it a while back but I wasn't in a position (or condition) to reply. I sincerely appreciate you taking the time to reconsider my initial response. IMHO making an effort to put yourself in someone else's shoes shows strong character. Thank you. I also owe you an apology for overreacting. Life is just straight up fucking hard right now. Presumably for everyone. Personally, in addition to the daily drama of living in a world wide pandemic, I constantly feel like I'm teetering on the edge of being in over my head with my entire network environment. I upgraded too much shit too fast. For the record, I've since done several pfSense restores and the correct maxmind key now shows up but Suricata still won't reinstall properly. With each new restore, I'm learning a bit more and finding things I setup wrong (older snort rules, snort subscriber rules won't download, some other stuff I can't remember). Each time i find another problem, the subsequent restore gets closer to working. Ultimately I always end up having to completely uninstall and reinstall Suricata, force an update of the rules, and everything seems happy. Suricata is a bad-ass powerful tool. Thanks for all your hard work on it. I sleep better at night knowing it's working.

@septer012 said in Suricata Logs Mgmt Not Working?: @bmeeks I am not sure that is the case, for my problem, as all of my logs are .log, and none of them have what I would expect a log rotation filename extension to look like. suricata_igb119463: total 2565604 -rw-r--r-- 1 root wheel 780M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 942M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 783M Aug 23 00:41 tls.log suricata_ngeth036678: total 2016516 -rw-r--r-- 1 root wheel 387M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 943M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 638M Aug 23 00:41 tls.log I guess unless it doesnt create the empty file without at least one log message, than that would make alot of sense. What kind of hardware are you running Suricata on (Intel/AMD or ARM)? And what is the version of the Suricata package that you have installed?

@bmeeks thank you Bill! I'm ashamed that I didn't already read that before posting. I had developed the idea that suppression was "rule-atomic" if you will, but now I see the light! Working beautifully: #(http_inspect) BARE BYTE UNICODE ENCODING suppress gen_id 119, sig_id 4, track by_dst, ip 69.59.224.0/19

@bmeeks said in Snort and pfblockerNG-devel: Well, without some kind of error message indicating why Snort did not restart, I can't really help you. When you have a situation like that, if Snort will not restart from the GUI, then exit to a shell prompt and run this command: There was no error - it simply was not starting automatically as expected! Starting manually was without errors. My first guess, and this is purely a guess since there are no error messages to confirm my suspicion, is that the pfBlockerNG-devel package update swapped out some shared library that Snort uses. That could have caused a library version conflict. Reinstalling Snort would have brought back the correct library setup. But this is just a pure guess without any supporting evidence since I don't know what error message was being printed. This is something I thought too - thanks for confirming my thoughts! Have a fine Weekend, fireodo

Quick Update on this. After monitoring logs and Discord usage these alerts are %100 Discord. It happens on my own PC also but, I do not run discord for more than a few minutes at a time usually. Oddly enough the alerts do not appear when discord is actually in use but start to appear shortly after minimization (to systray in my wife's case). If it were google ads or something like that I would just suppress them however, it is the online-matrix ad-server company that the alerts are being cause by and AFAIK it is STILL being listed as a malicious ad/malware server. SO, I am keeping them get blocked - blocking the STUN server seems to have no obvious affect on Discord functionality. Thanks a bunch guys

This quote, is from back in 2012 from an author of the third, and most recent, book in the list. The final nail in the coffin for me! I'll just stick to the snort.org documents, thanks :) From: Joel Esler <jesler () sourcefire com> Date: Wed, 25 Jan 2012 12:18:56 -0500 Author, and the book was outdated when it was published, and people are still buying it and I still receive a check from it. But if I could, I'd pull the book from every shelf, because all it does is make my current job as community manager harder. It covered Snort version 2.6 and was written during Snort 2.5, if that tells you the age of the book. There were several chapters (including several mistakes in my own chapter) that are just plain wrong. I edited several chapters of the book, and the changes were so heavy that they deemed I essentially rewrote them, and they couldn't publish them as I wrote them because then the original author wouldn't get paid.

Sorry for the late reply, you were correct. I created a passlist entry and then removed the IP from the blocked table and, boom. No more issues reaching the host. Thank you again bmeeks, you are a wizard.

Thanks.

First, in order to detect the Eicar virus file you will need a Snort or Emerging Threats rule specifically designed for detecting the file, and you need that rule signature enabled. Secondly, and more importantly, if you are downloading the file from a web site and the web site is SSL encrypted (in other words, it is an HTTPS URL), then the virus payload will not be detected because it is encrypted with the end-to-end encryption of SSL between your browser and the web site. Neither Snort nor Suricata will, out-of-the-box, detect that file. And most especially they can't detect it when it comes over an encrypted connection such as SSL. If this is a surprise to you, then welcome to the wonderful world of encryption and VPNs since that technology has pretty much totally neutered deep packet inspection (DPI) technology. The only method to do DPI with encrypted traffic is to set up a MITM (man-in-the-middle) interception. And that comes with its own Pandora's Box of technological and ethical problems.

Hello OP, how did your filebeats setup go? I have run into this great log apocalypse and am searching for a solution. Really wish filebeats had made it into a package by now but I guess not.

@bmeeks said in News from Snort: @fireodo said in News from Snort: @bmeeks said in News from Snort: @fireodo said in News from Snort: That's where I would look first, by running a full memory hardware diagnostic if you have one. No issues (after running memtest86+) and all back to normal (I mean exit on signal 11 ) Thanks anyway for your time and all the best, fireodo

@Daniel1972 said in Strange behavior on "Update Your Rules Set" at Snort Service: Thanks bmeeks. Iam gonna upgrade and see what happends. This is my production firewall, so it's a critical task, probably I'll take my time to do it. Thanks again. Keeping your firewall updated is very important to overall network security. Older software versions can have unpatched vulnerabilities. I don't know what else is installed on your firewall, but the following things are common causes of rule download issues: Using a RAM disk, especially for /tmp. Snort needs 256 MB of free space in /tmp to safely download, extract and install updated rules. Many users configure a RAM disk and wind up shooting themselves in the foot because the disk size is too small and they run out of space during the rules update. This does not show up on the Dashboard, though, because at the end of an update Snort will cleanup after itself. So any space that was in use is returned. You can check the pfSense system log to see if there are any disk-space related errors. Running Squid or any of the Squid related packages. These frequently interfere with the Snort rules downloads. There have been reports of some IP lists used in pfBlockerNG causing problems, particularly if the list contains any AWS IP space. The Snort team hosts their rules files on Amazon Web Services IP space.

@costanzo said in running Suricata/Snort on a SG-1100 not a good idea ?: @informel I purchased a SG-1100 for my house and highly recommend it. I am running the following with no problem: pfBlockerNG devel (This is awesome - no more ads!) Snort (running only on the WAN) Acme (For let's encrypt) Avahi (so I can use AirPlay and AirPrint) OpenVPN 7 VLANs DNS Resolver (on by default) My ISP is through Comcast and I have a 100/20 connection. As far as performance, I have seen no loss of speed. For example, I run a xfinity speed test and I get the speed I am paying for. OpenVPN from my iPhone works with no disconnects. Sometimes I forget to turn it off only to find it still running. I did run in to some issues with the Snort service stopping during updates, but after following suggestion from bmeeks to use the "connectivity" IPS profile I haven't had this issue since. I think Snort is a very resource needy service. Again, for a small environment like a home, in my opinion, is an excellent choice. I work in IT and this is what I run at home. Hopefully this isn't so old that you don't see this, but I'm wondering what you mean when you say you are running Snort on WAN only? I'm reading that the 1100 can be under-powered for IDS but as it's my house I don't think I need really crazy rules in place, I just want to know if/when something happens. i can only really afford the SG1100 right now and it would be great to hear your thoughts on this (and how it's going, a year later)

@itNGO said in How to skip/bypass fully ignore subnet.: @bmeeks Thank you..... Perfect working now.... One other point I should have mentioned. PASS rules are one of the very first things looked at, so when traffic matches a PASS rule the Suricata inspection pipleline is very quickly exited. PASS rules are checked for matches before any other rule, so traffic matching a PASS rule quickly exits the inspection engine, and thus there is minimal performance impact. It's not zero impact, but it is minimal.

Yes, you have the current version of pfSense RELEASE. And FreeBSD-11.3 is not using the iflib subsystem. I'm not sure what could up with your setup. Thus far I've gotten no other reports like yours. Unfortunately I do not have anything to test on that has that NIC in it.