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.
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.
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.).
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.
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.
@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.
ther key piece of information that you omitted from your original pos
The dynamic IP are the external one, and when it changes, I manually update the suppress list. these works well for years, but after the last update, it took same time to snort stop blocking, even the IP are updated on the suppress list.
The next time the IP changes, I will restart snort after the edition of the suppress list.
Well, as I mentioned earlier, if you really are running Microsoft Terminal Services on a non-standard port (which is what the alert suggests), then why not disable that rule? Don't suppress it, just disable it. If you are not running Terminal Services on a non-standard port, then I would certainly be investigating why that rule is triggering. I assume you have external clients connecting back to something inside your LAN. Also, if this is Terminal Services and it's not running over a VPN, you really need to rethink that setup.
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: 49090SERVER-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.