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 : Bummer. But I understand now. Thanks!

Your post is not entirely clear. Perhaps it is a language translation issue ??? Are you saying that now your pfSense box is behind some kind of double-NAT? You must eventually have a public IP in order to route traffic (not an RFC 1918 address). However, if your pfSense box now communicates with some upstream host that in turn provides a NAT to some type of public routable IP, then your Snort rules update should still work. I assume other Internet traffic through the pfSense box works?? Or do you really mean to say you have isolated this pfSense box from the Internet? If that is the case, then there is no method for an offline update in the Snort package. It requires Internet access to update its rules.

@fst said in Snort will not start - PFSense 21.05 / FreeBSD 12.2: Thanks again. You're welcome. Sorry for not getting it working! Regards, fireodo

@paanvaannd said in Unable to modify (i.e., install, remove, or reinstall) packages via Web interface + Snort installed but not showing up in Web GUI: Thank you for taking the time to help and explain, @bmeeks! Per your and others' comments in that linked thread, I'm not hopeful that Snort/Suricata would have much hope of working on my SG-3100 even after 2.5.2 rolls around (I'd link directly to your comment but I can't figure out how to copy a permalink on this site...) so I may just upgrade to the SG-6100 since it's Intel-based. Yes, the SG-3100 is not the best choice right now for the IDS/IPS packages. It is due to the 32-bit ARM processor chip in that box. Because of the 32-bit ARM processor and the lack of Rust support for it, it is not possible to run any version of Suricata on that hardware newer than 4.x. That is two versions behind, and no longer supported by the Suricata team.

@sramsterdam showww, obrigado por compartilhar sua solução.

Thanks.

The next update to the Suricata 5.x package on pfSense will contain a new option for configuring Suricata to export performance stats over a Unix socket to Telegraf. It will support the input.suricata plugin. Suricata can produce EVE JSON logs, and that data can be either written to a conventional text file or it can be made available to a Unix socket. So if someone produces a log data parser for EVE JSON, then Suricata can easily be adapted to feed data over the Unix socket. I am not familiar with Telegraf since I've never used it. So I don't know what it is capable of in terms of digesting Suricata's EVE JSON logs. The new feature I mentioned came from a Redmine Feature Request submitted a while back. And that request was specifically for Suricata performance stats (things like packets processed, packets dropped due to load, etc.).

@Zulder Me pasa como a ti... Solo me pasa puerto 80 http y no todos... Lo pudiste solucionar?

This forum is for users of Snort on pfSense only. There is no support for Windows versions of Snort available here.

@heliop100 said in snort not keeping blocked hosts on reboot: @bmeeks said in snort not keeping blocked hosts on reboot: Why do you need to keep the offenders blocked as long as possible? Do yo I want to block torrents downloads, As the seeds keep changing, torrents slow down, but not stops. As the blocked hosts list grows, the download speed slow down. After the pfsense reboot the process need to begin from scratch again. Thanks I fail to see a connection between persistent blocks and the action you describe. Explain to me how you think that persistent blocks make a difference in your scenario. A block is a block, it does not matter if it just happened or if it happened three months ago. If you have blocking enabled and "kill states" enabled, the torrent from that specific seeder will stop. Will the client perhaps try and find another seeder, sure, but then that seeder will be blocked if the rule is there to trigger on the packets. No IDS I am aware of has persisent blocks. In fact, an IPS does not even have the capability of persisting a block for any period of time. An IPS performs real-time drops of packet data, but there is no persisted block. Persistent blocks that hold across a firewall reboot is not a design feature of the Snort package and no such feature is ever planned. There is no need for it.

@oldrik said in Setup and configure snort on pfsense to detect an intrusion detection attemps within a LAN: @kiokoman pls if i understand well, does it mean that snort can't actually alert and block an attack such as a portscan performed by a user on a LAN network to another user on the same LAN ???? if that is the case, how can snort be configure to alert and block a user on a LAN from another user on the same LAN who perform an attack such as a portscan ??? Thanks in advanced Snort runs on the firewall. The firewall is not in the traffic path if two machines on the same LAN talk to each other. Only the LAN switch is in that pathway. The only time the firewall can see traffic from a LAN client is when that client is communicating with an IP address that is NOT part of the LAN. That would be a different LAN subnet where the firewall is the route to the different subnet, or some host out on the Internet (which means the traffic is traversing the WAN interface). So since Snort would not see one LAN client port scanning another LAN client (in the same subnet), it can't do anything about it. If you wanted to monitor traffic between LAN hosts on the same network, then you will need a managed switch that provides a span port (or port mirroring). You would then configure mirroring on the switch and set up a separate installation of Snort on say a Linux host on the LAN and connect that host to the span port on the switch. Only then could Snort on the Linux host see traffic between other LAN hosts.

@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!

I was confused on how to do this so after I figured it out I thought I would share. Click Services, Snort Edit the non functional snort interface e Click %Interface% Rules Click the drop down for Category: and choose GPLv2_community.rules Wait for it to load and disable x Sid: 49090 SERVER-SAMBA at the bottom of the page Save & Apply Then back on the Snort Interfaces tab you should now be able to start x snort on the Interface

The biggest factor there is how much of that traffic will be over OpenVPN. If the majority of it is and you want to get anywhere near 2Gbps you're going to need the fastest CPU you can get hold of. Each OpenVPN process is single threaded so less cores at higher speeds wins here if you have only a few tunnels. Steve