@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