@everfree said in Snort v3.2.9.9 - not blocking?: Suricata 4.1.4_5 Legacy Mode blocking not actually blocking offender IPs in some setups. I have the "Which IP to Block" setting on BOTH. I think it is not fixed fully. You posted in a Snort 3.2.9.9 thread, so I read your initial post quickly and missed the Suricata part in the message. Sorry about that. I automatically assumed you were posting about a Snort issue. I get a lot of messages from various users and sometimes get all the different posts confused. I will need to check on Suricata using a test VM. Just noticed this post this morning in another thread for a different user: https://forum.netgate.com/topic/145891/my-suricata-not-blocking-legacy-mode. Look in your suricata.log file for the interface and see if a similar message is shown for your system.

@NollipfSense said in Suricata Inline and Rules: @bmeeks said in Suricata Inline and Rules: A corporate network does not want employees to have access to iTunes, Hulu, Netflix, etc. They want that stopped, so they configure security that way. A home network most definitely generally wants those services available, so you can't just go copying someone's list of rules and suppress listings unless you fully understand what those rules are actually doing. I understand Bill; however, all rules under stream-events.rule had been disabled as well as the only iTunes rule under Emerging-policy.rule had been disabled. I believe the author was from England. What about these two rules: 1:2009582 ET SCAN NMAP -ss window 1024 and 1:2027863 ET INFO Observed DNS Query to .biz TLD...I am getting lots alert so they were dropped. My opinion, and the advice I give home network users, is to enable the Snort rules download and then enable the IPS Policy - Connectivity setting. That's really all you need. Enable no other rules. That provides plenty of protection from most of the threats out there, especially if you keep your Windows machines updated with the latest security patches (in other words, leave Windows Update enabled and have your machines on a UPS so they just are on all the time and update late at night). If an admin has a good bit of IDS/IPS experience and also quite a bit of networking theory knowledge, then he can experiment with maybe the IPS Policy - Balanced setting and perhaps enable some additional Emerging Threats rules. But be prepared to have Google on speed-dial so you can quickly research potential false positives. All those events rules provided with a default Suricata installation are designed to simply detect deviations from RFC behaviors. They are triggering on protocol anomalies, and nearly 100% of the time those anomalies are completely harmless. So never set those rules to DROP, and if the alerts bother you, then disable those rules entirely. But don't obsess with them triggering, as they tend to false positive like crazy. Those ET DNS query rules are also only marginally useful at best. As you see, they will trigger quite often on even normal web traffic. Some of them will even false positive fairly often. For home users these kinds of rules are more of a bother than an addition to security. I don't run them on my system. If you keep your PC software updated, that's 95% or more of the network security battle won right there! Some IDS/IPS users want to start out with a whole bunch of enabled rules because they think it will make their setup "secure", but they quickly get frustrated because so many things (apps) get broken - and sometimes in very strange ways. Take my advice, keep it simple for many months as you get your feet wet administering an IDS/IPS. I have what I believe is a very secure setup for my home network using Snort. I may one day get zapped with a zero-day -- who knows, but I am pretty confident that my setup is secure. And my iTunes works, my Netflix works, my Facebook and YouTube videos work, and all the web sites I visit open up and display properly. I honestly do not know the last time Snort crashed or gave me any issue on my firewall, and I've been running it for many years. I get maybe one alert per month on average on my LAN from Snort. I do get several an hour on my WAN, but that's simply because I run a handful of ET rules there solely to generate alerts on purpose so I have data to use when I'm working on Snort package development tasks.

@Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE): Thank you, I'll bury my head in logs like an ostrich in the ground,... [image: 1566154485077-7566b68f-a11d-4f84-9fca-df8455d0a495-image.png] I would recommend first temporarily turning off the option for sending alerts to syslog. Do that for all interfaces and then restart Snort on all interfaces. That will make for a quieter log where other messages will more easily stand out. Once you track down the problem with the troublesome interface, you can re-enable the syslog alert output.

@ffuentes said in Adding custom rule: I added the following to the cutom.rules: alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP AUTH LOGON brute force attempt"; content:"AUTH LOGIN"; nocase; classtype:suspicious-login; sid:1000001; rev:2;) alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any (msg:"SMTP AUTH bruteforce attack"; content:"535 Incorrect authentication data."; nocase; classtype:attempted-user; threshold:type threshold, track by_src, count 2, seconds 60; sid:1000500; rev:6;) I am trying to alleviate the rash of auth failures spammers/bots are causing to our mail server. Once I added to teh cutom.rules the system validates it and reloads. Than I just sit and wait but I see nothing been blocked.... I look at my mail server logs and I still see: 535 Incorrect authentication data. Am I doing this wrong? TIA! If you are not seeing alerts for your custom rule, then that means it is written incorrectly. By that I don't mean a syntax error, but instead the conditions you specify in order to trigger the rule are not being detected. Here are some suggestions: Make sure that on the VARIABLES tab you have actually assigned a correct alias or IP address to the $SMTP_SERVERS variable. The best way to do this is create a firewall alias containing the correct IP address or addresses and then make sure that alias is defined for the SMTP_SERVERS variable on the VARIABLES tab for the Snort interface. You may also need to grab some packet captures to be sure you have the exact strings contained within your rules. Finally, the advice of @NollipfSense only applies to you if you are running Suricata and using Inline IPS Mode, or only if you are running the Snort 4.0 package on pfSense-2.5 DEVEL and using the new Inline IPS Mode there. If you are using the Snort package on pfSense-2.4.4, then you do not change rule actions because there is no Inline IPS mode available.

@phantonuser said in Snort rules being updated but not being loaded.: In fact see the topic and investigate. I install this cr.. for around 6 years I know what I am doing and the first and obvious thing to do when someone sees this kind of behaviour is discredit. Like let's see you misconfigure again. You do realize, I hope, that pfSense and all of its packages are open-source software and welcome user code contributions. If you see behavior you do not like or that you want changed, then simply submit a Pull Request to Github here for pfSense and here for Snort. That's what I did when I wanted some additional features added to the Snort package many years ago. Modify the code and then submit it to the core maintainers for consideration. I assure you it will be considered.

@bmeeks said in why is snort alerts not responding for the respective portscan as expected ???: The short version is that in my humble opinion the portscan stuff is way overrated. And to boot, the detection for it is very prone to false positives with the way today's network connectivity works with regards to all the various applications out there. So my suggestion is to stop wasting time playing with the portscan detection. Ok pls what other ruless apart for portsacn can u suggest me for clear understanding and testing purposes bcuz i'm actually working on small project to actually show how pfSense+Snort function to detect and prevent intrusions attacks.......thnks

@Simbad said in Snort-4.0_5 Package Update Release Notes (for pfSense-2.5 DEVEL): Bmeeks, will you add buttn DROP ALL in all category? Well, I could but I am a bit hesitant because that will clutter up the config.xml file on the firewall with large Base64 encoded strings. I had rather users make use of the SID MGMT features to accomplish what you are wanting. It is much, much more efficient in terms of configuration storage space. Using the example from your posted screen grab, assume you want all the rules in the snort_app-detect category to be DROP. Here is all you need to do: Enable SID MGMT (if not already enabled) Click the icon to ADD a new SID MGMT list. In the Title box name it dropsid.conf (or really any name you want to use, but I just like to keep it simple and name the file for what it is doing). Now, down in the edit box for content, type the following on a single line and then save the change to close the edit dialog modal. snort_app-detect At the bottom of the page, in the Drop SID List selector for the interface where you want the new rule action to apply, select the list you just created (dropsid.conf if you followed my example). Click the checkbox on the far left for Rebuild. Click Save. This will force an immediate calculation of the new rules with updated actions and then sends the running Snort process on that interface a signal to reload its rules. In the future, if you want to add more categories to the DROP action modification list, simply return to the SID MGMT tab and add the additional category names on the line. Separate the names witih commas (or you can put each category on a line by itself, either way). You can also modify the action for specific SIDS or even ranges of SIDS using this same file. Open up and view the dropsid-sample.conf file for examples of the various options.

@bmeeks said in Pfsense Migrate Snort to Suricata: Do you have any other packages running on pfSense (like maybe pfBlocker or Squid)? If so, check that one of them is not at fault. I DO have pfblocker and turned it off. Perhaps there is residual things that stay alive after turning it off? I have gone over all the logs and find nothing. Might also be something related to IPv6. I have all IPv6 turned off everywhere I can find it in Pfsense. I'm starting to drift out of the original header, but I just ran across where Snort is blocking 1.1.1.1 and 1.0.0.1. I whitelisted it, but for some reason was not honoring it. I accidentally deleted the Passlist info pointing to White_list. It would NOT let me. It kept saying I can't use a FQDN as a name. Of course I was not, so it appears this constantly annoying gui in corrupting data. I did a restore and white_list is back.

How exactly did you create the interface and when did you try to start it? Sounds like some initial configuration settings did not get set.

@Simbad said in Snort update: Any update for 2.4.4 ? :) Not sure at this time. I will need to talk it over in some detail with the pfSense team. There are some depenency issues that would have to be worked out in order to compile the new Snort binary package for pfSense-2.4.4. Update: the pfSense team and I discussed this via email and have decided the snort-2.9.14.1 binary will be pushed to pfSense-2.4.4_3 RELEASE. Look for an updated Snort GUI package later today for pfSense-2.4.4_3 that includes support for the latest 2.9.14.1 snort binary from upstream.

@bmeeks One more thing I want to share: I found the way to cross compiling rather than emulation. I saw 6x faster speed up in build time. See my notes here.

@bmeeks said in I am confusion...IDS inline on single WAN running an OpenVPN server which is LAN: Go Googe "FreeBSD netmap device" and that should begin to answer your questions. You can also research in detail how OpenVPN creates its hooks into the FreeBSD networking kernel stack. pfSense is your "origination" and "endpoint" for VPN connections to/from your LAN. Traffic flowing in and out of the physical LAN interface is unencrypted, so the IDS can inspect it. @NollipfSense said in I am confusion...IDS inline on single WAN running an OpenVPN server which is LAN: https://www.unix.com/man-page/freebsd/4/netmap/ thank you guys so much for pointing me towards the right direction, netmap is what I needed to dig a bit into to really understand this. I did not understand what it was doing in the system and you guys sent me through a very very interesting rabbit hole. let me add a couple of links in this thread (which is already popping in my google bubble for the search "freebsd netmap device openvpn"), this is the original paper from the guy who wrote netmap, Luigi Rizzo, an Italian IT professor, it goes into details about how it works and how it does it's pipes and answered a lot of my questions. netmap: a novel framework for fast packet I/O At a very high level, when a program requests to put an interface in netmap mode, the NIC is partially dis-connected (see Figure 3) from the host protocol stack.The program gains the ability to exchange packets withthe NIC and (separately) with the host stack, through circular queues of buffers (netmap rings) implemented in shared memory. figure 3 [image: figure%2B1.png] so specifically about suricata it does support netmap devices. So out of the box in inline mode, if your network device has netmap capabilities packets are gonna get from the NIC to suricata via the netmap magic (TX and RX rings, operating in shared memory). Am I getting this right? Specifically about OpenVPN another chapter should be opened because it comes with it's own way to implement things, it should be noted here that OpenVPN does stuff in user-mode and has its own hooks to get the encrypted packets coming in from the stack, authenticate/decrypt/(de)compress and then give em back to the stack, I haven't dug deep into it (yet), so thank you for clearing the air for me and allowing me to go further, much appreciated. If we were to consider the other main VPN implementation, IPsec/IKE then IPsec is already happening in kernel and only IKE is happening in user mode, so it's got different piping to encrypt/decrypt the packets while talking with the stack/netmap, so the two probably will end up having the packets follow very different routes in a netmap system. I'm also a linux guy and the tools to observe your own system are slightly different so doing this on BSD is extremely difficult for me, I've got an added learning curve, but exactly the learning experience I want because I'm really liking pfsense. plus, my VPS pfsese box deployed in the wild is working like a charm, the IDS rules are easier to tackle than I expected, given my setup I only really block scans and known bad hosts since all my potentially vulnerable services are accessible only via VPN, so that's probably why, monitoring an actual active webserver is probably a very different task.

@seantree said in My suppress list and Sid mgmt are not working: Hi Bmeeks, You are right! There is a duplicated process. I have killed that Zombie and everything is good so far. Thank you very much! Glad you got it sorted out. That duplicate process thing happens occasionally to some folks. Both me and the package maintainer before me have tried to stop it from happening, but neither of us have had 100% success. It has to do with the mechanism inside the pfSense plumbing that sends a "restart all packages" command every time certain things occur on interfaces. When these triggers occur multiple times in quick succession, multiple copies of Snort can get started.

@shred yup, I've been there, I also got confuse about that. but that rule is to block other interface to access management port. some of the link or pictures of this guide did not retrieve when netgate upgrade their forum. [image: 1565052185679-02268e4d-4c47-4b6c-b5ed-0cdbe7ee2a20-image.png]