You can't. Snort sits between the physical NIC and the kernel network stack before the firewall engine. So, when you run Snort (or Suricata for that matter) on the WAN, it only sees local traffic after NAT has been applied for outbound traffic, and before NAT is undone for inbound traffic. Here are two diagrams that show how the IDS/IPS packages are plumbed into the network. This is an operating system thing and not anything the packages can alter.

ids-ips-network-flow-legacy-mode.png

ids-ips-network-flow-ips-mode.png

This is why I have been recommending for the last few years that users put the IDS/IPS on internal interfaces. You should do the same. There is no point in having it on the WAN. IDS/IPS is not for protecting the firewall. It's for protecting the hosts behind the firewall. If you need IDS/IPS for your firewall itself, then you really need a new firewall 😀.

Running it on the LAN would eliminate your issue of NAT hiding local IP addresses. When running on the LAN, all traffic going to or coming from local hosts would have to pass through the IDS/IPS.

And one last note. Without MITM breaking of encryption, IDS/IPS on the firewall is severely limited in what it can accomplish these days because nearly 100% of network traffic is encrypted. The IDS/IPS can't peer into any of the payloads for SSL traffic. That means zero payload inspection of HTTPS, DoT, DoH, SMTPS, IMAPS, and POP3S for starters. That's nearly all of the web traffic, potentially all of the DNS traffic (if you use DoT), and pretty much all email traffic bypassing inspection. Intrusion Detection is rapidly becoming something best done on the local destination host itself and not on intermediate network devices.

@bmeeks

Your post here https://forum.netgate.com/post/1034999 and

https://forum.netgate.com/topic/171140/appid-metadata-unknown

This was very helpful too I think you forgot about this one you list the paths to the text files

@bmeeks
Ah, that is right. I might have gotten confused with that field. It does work omitting the content section.
I appreciate your help!

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