The Snort package offers the OpenAppID feature which can be useful blocking social media sites. You will want to be sure your NIC hardware (the specific driver, actually) fully supports the FreeBSD netmap kernel device. Netmap is used for Inline IPS Operation in Snort, and if you use OpenAppID you definitely want the ability to selectively drop individual traffic flows rather than simply block an entire IP address with Legacy Mode Blocking. The official Netgate Snort package documentation can be found here: https://docs.netgate.com/pfsense/en/latest/packages/snort/setup.html. Setting up OpenAppID is at the bottom of the linked page.

@fartypants said in Snort keep blocking IPs on suppress list!: Just wanted to say thanks to BMeeks for suggestion re- run-away snorts above. Been smacking my head against a similar-but-different problem for days, and that's what it was. Whodathunkit? Si. Multiple, but duplicate, Snort (and Suricata) processes can happen from either of these things: Something causes the WAN IP to change rapidly or the WAN interface cycles down and back up repeatedly. This causes a built in pfSense script to fire that restarts all packages. Because Snort and Suricata both can take a while to start, rapid back-to-back execution of "restart all packages" can result in multiple instances of Snort or Suricata running on the same interface. Configuring the Service Watchdog package to monitor Snort or Suricata. Service Watchdog does not understand how the Snort and Suricata packages work, thus it cannot properly monitor them. It also does not understand that both packages will stop and restart themselves when doing rule updates. Service Watchdog simply sees the Snort or Suricata daemon stop, so it immediately restarts it. Service Watchdog does not know that Snort (or Suricata) are in the process of restarting themselves from a rules update, so when it issues its own "start" command you can wind up with two or more processes running on the same physical interface. Service Watchdog should never be configured to monitor either of the two IDS/IPS packages!

If I understand your post correctly, you have devices on your internal networks (LAN) that communicate with a database server located elsewhere on the Internet (accessible via your WAN). If this true, then you need to simply add the IP address of the remote DB server to a Pass List by creating a list on the PASS LIST tab, accepting the default checked options, adding the IP address of the remote DB to the list using the controls at the bottom of the EDIT LIST screen, then save the new list. Now go to the INTERFACE SETTINGS tab in Snort for your WAN (since your are running Snort on that interface) and select the newly created Pass List in the drop-down selector there. Save that change and restart Snort on the interface. You do NOT need to be changing the HOME_NET nor EXTERNAL_NET variable settings. Changing those is almost never required. And changing them from the defaults without a full understanding of what they are for and how they work will result in a setup that will NOT trigger rules properly. The fact you altered them in an attempt to solve the problem you describe indicates you may not understand what those parameters are actually for. They define the networks to be protected (HOME_NET) and the networks that are assumed hostile (EXTERNAL_NET). The default setup puts every address/network not defined in HOME_NET in EXTERNAL_NET. Literally, in the PHP code, $EXTERNAL_NET is defined as !$HOME_NET (the leading '!' character indicates a logical NOT operation).

@bmeeks Yah, was running version 6.0.4_1 but I'll dig some more into the NIC and iflib stuff and see if there is a known incompatibility or other issue that I might have missed. Just for posterity currently running the following firmware on the X710 NIC: sysctl dev.ixl.1.fw_version dev.ixl.1.fw_version: fw 8.1.63299 api 1.12 nvm 8.10 etid 800093ea oem 1.267.0

@steveits I love multi threading, I have been researching this with Java for some time now with the university, but it's not fully taught, so I get hints from the Professor and book recommendations, and a lot of trial and error. I have a couple binary search methods that split the lists between different threads and cores to help aid in searching. It's amazing to see it work. The concurrent threads does cause confusion, again Class CyclicBarrier helps with making the threads run exactly at the same time or use of volatile variables helps for multi objects that pass in variables in the method headers. Again that is Java not Python. Python has to have something also. Thanks for the reply.

As a side note, I just tried to add a dropped entry into the Suppress list and when clicking the + button, it's not adding the entry. It used to work but now it doesn't. Odd. [image: 1668018125737-gid-sid.png]

Unless you have open and forwarded ports on your firewall, it is going to drop all unsolicited inbound traffic anyway. So, really Suricata is not doing anything worthwhile running on the WAN (unless you do have open and forwarded inbound ports on the WAN). One big issue when it runs on the WAN is that it sees outbound traffic after NAT has been applied, and it sees inbound traffic before NAT is unwound. So, you can never see what internal host (on the LAN, for example) is participating in the conversation. But when you run Suricata on the LAN, then it sees the real native host IP address and the alert logs will show both the local internal host's IP address as well as that of the external participant in the traffic. So, much easier to see what internal hosts may have issues when you run Suricata on the LAN. This diagram illustrates what I mean. This is how traffic flows with Suricata running in Legacy Blocking Mode. Suricata gets a copy of every packet, examines that packet, and then determines if it should signal a block. But notice the firewall gets the original packet. So, if the firewall drops it anyway due to the default rule dropping unsolicited inbound traffic, there is no point in having Suricata issue a second block for the same traffic. [image: 1667867146015-ids-ips-network-flow-legacy-mode.png]

@mrpete said in Suricata Home/External Net - HOW do you make the External list???: @bmeeks THANKS! I do want it to be an exact negation. HAH. THANK YOU. Bad assumption on my part (I assumed "default" meant "default Home Net" in both places!) Simple suggestion: modify the External Net dropdown... something like: from: "default" to: "default: negate selected Home Net" Just to be clear, when you set it to "default" that does in fact result in EXTERNAL_NET being an exact one-for-one negation of each entry in HOME_NET. So if you customize HOME_NET to something else other than the default values, then EXTERNAL_NET will follow automatically so long as it remains set for "default". But I can do a better job of explaining that in the help note underneath the drop-down selector.

Pure speculation here, but there was a patch submitted to FreeBSD upstream that fixed an issue where the traffic counters would not register at all when a netmap device was in use. That caused the counters to always show zero traffic. A fix for that was submitted to FreeBSD upstream by, I believe, the OPNSense team. That fix then made its way into pfSense with a recent base OS update. Maybe the fix has a side-effect for emulation mode operation ?? Might be something you want to report upstream in FreeBSD. But it may be specific to your particular setup with Proxmox. Maybe other Proxmox users with a pfSense VM can chime in here.

@bmeeks We do a lot of work for [unnamed] clients who highly value the security of their information. My consultants are very attuned to those requirements, so I have little concern about their device healthcare. We have very few other visitors, so I didn't pay much attention to who was on the wifi until I discovered that the janitorial service phones were connecting. Now we have a separate guest wifi, direct to Internet on a separate circuit. pfsense seems much happier since I took Snort off the Wan and cutback severely on the rulesets being used on the LANs. My wife works for one of those companies that provides the hardware and controls the software. They're still running Win7! They offered to put their access software on her phone, but she would have to sign a document that basically gave them ownership of the phone. Hah! I, too, think the current Windows Defender does a pretty good job. We happen to have a long term subscription for Malwarebytes, so we stick with it, at least for now. The Linux boxes run ClamAV. None of those are exposed outside the firewall. Thank you, again, and SteveITS. You saved me a lot of wasted time and a significant addition to my collection of gray hairs! Rog

@bmeeks I think I found it! So I waited until it blocked it again. Then I searched the snort2c list and found the remote IP of the server. So I confirmed it was getting blocked. Then I searched the alerts, but I increased the list count to 5000 instead of 500 and turned off auto-refresh. Then I found this new alert: #SURICATA HTTP URI terminated by non-compliant character suppress gen_id 1, sig_id 2221029 So I suppressed that one, removed the IP in the snort2c table, and the camera came back up! So now, I just have to see if it holds! I will set the firewall back up to allow that IP and see if it makes a difference since I don't think changing it to the alias with all their IPs made a difference. Thanks for the patient help on this! Here is the site with the camera: Lovington Weather

hola, necesito saber porque al utilizar suricata en pfsense y configurar el modo ips y cargarle reglas en una interfaz al iniciar suricata en dicha interfaz me bloquea el acceso web y me sale ERROR 502 Bad Gategay

There is an option to send Suricata alerts to syslog (the pfSense system log). There is no direct remote syslog option within Suricata itself. The upstream package does not support that either best I recall. But you can configure pfSense to send its logs to a remote syslog server. However, syslog on pfSense will- by default- truncate all messages to a max of 480 bytes. That is usually not big enough to fully capture payload info. Most users that are serious about obtaining logging data from Suricata stand up an ELK or Graylog setup on a third host. Then configure Suricata to log to EVE JSON format and use a third-party process to export those logs off the pfSense box to a remote host. Something like the filebeat package on FreeBSD. Here are some examples: https://www.diaryfolio.com/2020/07/elastic-beats-on-pfsense-installation.html. https://docs.logz.io/shipping/security-sources/pfsense.html. https://psychogun.github.io/docs/linux/ELK-stack-on-Ubuntu-with-pfSense/. There are many other examples available if you search Google with "filebeat pfSense" or "elk pfSense", etc.

@johnpoz , @bmeeks Update: Yesteay I replaced Realtec NIC`s with Dual NIC with Intel 82576 Chip PCI-E card, unchecked " Hardware Checksum Offloading" and rebooted the system as required. Overnight Snort downloaded and successfully updated Registered rules. So, I think this issue is resolved. I want to thank you both for your help.

On pfSense, NEVER directly edit anything at the command-line. All configuration files are recreated from scratch each time Suricata is started or restarted within the GUI. pfSense packages store all of their configuration information inside a custom XML file and then write it out to any required *.conf or *.yaml files when starting. So any edits you make will be immediately overwritten. You can easily add your own custom rules by going to the RULES tab for the interface, selecting Custom Rules in the Category drop-down, and then typing your rule in the text box. Click Save when done. SIDs (signature IDs) must never be duplicated. Most folks start their custom rule SIDs up around 1 million to be sure they are out of scope of any commercial rules. So, start your SIDs with 1000xxx and you should be good.

@ezvink Send the logs to a syslog server.

@ezvink Before attacking, finish first the basic setup. I mean, this : [image: 1664533710292-280752bf-fc28-46a5-9ebc-57bf45fe5329-image.png] is not done any more. http over port 80 is something of the past, as all traffic passes very visible over the internet. That the opposite of 'security'. Google, for example, won't index http sites any more. Browsers start to show warnings when http is used. The solution has been found a decade ago : use https over port 443. So, add a new NAT rules, same settings as the "port 80 rule", but now you use port 443. And do not forget to tell apache2 that it should listen port 443 also. And consider disabling port 80 (http) functionality all together - and if you do, ditch the port 80 pfSense NAT rule. When done, you can start thinking about 'security'. One of the best starting points would be : leave the /var/www/html/ folder empty, just keep the index.html file and don't edit it. Do not install "PHP" (Java, whatever) as this would open up a whole new set of angle of attacks.

@bmeeks Thanks for your help, this is very helpful, appreciate it!

Thank you. Have a nice weekend