The updates for the binary and GUI have been merged and the new v7.0.6 package is available.

@SteveITS

Thank you for reply.
I was running Snort on WAN but I can't see any portscan detection alerts ?
We issued a few port scans over different outsides IPs but there were no alerts under Snort ?
Are we doing something wrong ?

I just purchase the Snort subscription rules, it’s not that much for private use. You get tons of good stuff with it. Is it ethical to use this rule set for other devices … no so I wouldn’t do it, just purchase a business subscription if you are attempting to do that.

Again there are rule sets for other security providers that I would love to add URLs for.

https://rules.emergingthreats.net/blockrules/3coresec.rules

https://forum.netgate.com/topic/177538/is-it-possible-to-use-a-cron-job-to-update-custom-snort-rules

So I get the appeal for wanting custom URLs but understand why it’s not included, if it was anyone could reuse subscriptions rules on other devices.

I wonder if there is a way to get the best of both custom url and rules and give Snort security for their subscription rules too for no free riders.

@MichaelRMO when you see the Ip address you want in the alert area click suppress for that IP it will no longer block that one in snort. Try to suppress that IP address. If it’s many look at the suppress list and manually add to it and or write a quick Java program to create a new list based on a text file you have. Hope that helps. I use appID with custom lists so I have a massive suppress list.

Thanks @bmeeks for the info.
This is... quite fundamental. Basically it would be like a new IDS system, will take some time to figure out :)

@Antibiotic VIPs though 😎

@focheur91300 said in Suricata IPS block out trafic WAN interface:

@bmeeks I haven't modified my configuration: IP Pass List
72610a9b-72c0-4001-9804-d8e8b745b7b1-image.png

With this configuration, as soon as an alert is sent, the SRC IP is added to the Blocks list.
87c46ccd-04f2-477b-a4e4-c7c120539209-image.png

At this point it is impossible to communicate with the outgoing ip.
0731e8ce-d2a3-4742-a83b-3e7c3e027cbd-image.png

Not sure I fully understand your problem. Legacy Blocking Mode does indeed completely block ALL traffic to any IP that triggered an alert and thus subsequent traffic of any type to that IP is blocked. That's because that IP is added to a pf firewall engine table called snort2c, and all IPs added to that table are blocked for all protocols and ports by a hidden built-in pfSense firewall rule.

In short, it appears to be working exactly as designed. If you want to selectively block individual packets and not ALL traffic to/from the IP, then you would need to switch to Inline IPS Mode (if your NIC natively supports the FreeBSD netmap device). Check the Sticky Posts at the top of this sub-forum for details and examples of Inline IPS Mode operation.

The yellow icon simply indicates the rule matched a SID MGMT condition such as SID or category name, for example. The dropsid.conf logic only modifies the action of a rule, it does not change the enabled or disabled state of the rule. So, default disabled rules remain disabled unless that is overridden in the enablesid.conf logic.

Try installing the Suricata package again. Be sure to let the installation fully complete. Remove the package by clicking the trashcan icon next to Suricata in the Package Manager. Be sure to let the uninstall process complete before clicking away from the page.

My suspicion is either you did not stay on the uninstall page long enough for the uninstall process to complete (if you click away, the process can fail to complete leaving remnants of Suricata behind). Another possibility is that you performed a config backup restore from a time when Suricata was installed. If you restore packages in that scenario, the config.xml portions of Suricata will get restored but the actual binary pieces will be missing.

If you want to permanently remove Suricata and all of its settings from the firewall configuration, go to the GLOBAL SETTINGS tab before uninstalling the package and uncheck the option to retain Suricata settings during uninstall.

@bmeeks
Not too old to learn something new ,thanks to you.

Many thanks
Jonna

I see you're dealing with the Rothenburg shellcode flood in your logs. That sounds frustrating! Have you tried analyzing the logs to see if you can identify patterns or signatures specific to this shellcode? It might help you create filters or rules to block or mitigate the flood. Also, ensuring your system is up-to-date with patches and using strong passwords can help prevent future attacks. You can find more detailed guides and discussions about shellcode and security on https://guidedhacking.com/threads/how-to-find-shellcode-in-malware-memory.20588/ . They have a supportive community that can offer insights and advice based on their experiences.

@coxhaus said in SNORT DNS inspection:

@bmeeks
I was thinking of maybe DNS.txt if it has machine language in it. Are there rules out there?
I don't know anything about writing rules. When I ran it in the past it was set up to download rules.
Maybe if the DNS is intercepted and changed on routing. QUAD9 is trying to do all the work.

Will Suricata do it more so than SNORT?

Suricata offers much more extensive logging through its EVE JSON system than does Snort. Also, you should consider that Snort on pfSense is the older 2.9.x binary version and not the newer 3.0 branch. There is currently nothing in the works to move Snort to the 3.0 branch, so whenever upstream Cisco/Talos pulls the plug on the Snort 2.9.x binary branch Snort will be dead. There have been no upstream additions or updates for the Snort 2.9.x branch for the last two years (and I don't expect any).

I'm not sure if you can find third-party rules to examine the DNS TXT records or not. Never have researched that. Google searches will be your friend when trying to locate something.

The RULES tab simply defaults to showing the first entry in the drop-down selector box. That has nothing to do with the rule set that is actually loaded. To see the loaded ruleset, choose "Active Rules" in the drop-down selector.

@bmeeks said in Snort / Suricata for inbound traffic only:

our firewall can't do a thing about traffic coming from your ISP link down to you. If you have a 1 Gig/sec WAN connection and the bad guy is sending 2 Gigs/sec of packet traffic to you, your WAN is effectively dead (saturated)

Well i will also state that even if the DDoS stream wasnt saturating your WAN, there is still firewall system resources being taken up by sessions that will never complete OR sessions that do complete but no further data. If your firewall resources are being maxed out that makes it difficult for other functions to operate correctly i.e. Routing
So a DoS doesnt have to be about filling a pipe.

@oscar-pulgarin said in Alerts that go up:

I am working with Suricata to map some alerts and vulnerabilities, the alerts are raised but only the name of the alert, IP and other parameters are visible.
But something important is missing and that is that I want to know what information raises those specific alerts, that is, a practical case, passwords and users in plain text, I want to know that information
Can?

You can enable packet capture in Suricata, but it will consume a lot of logging space so be prepared for that. You can quickly exhaust disk space on pfSense and crash the firewall. You will find the settings under the INTERFACE SETTINGS tab in the Logging section. You can also do this via EVE JSON logging configurable on the same tab.

But the vast majority of web traffic now is encrypted (HTTPS). Encrypted traffic cannot be analyzed nor logged by Suricata. Only plaintext HTTP traffic would be visible in a packet capture. But hardly anything is transported using plaintext HTTP these days.

@JonathanLee Good idea. Thank you will do it this way.