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

A quick Google search with this term: "writing snort rules examples" yields a ton of results. Here are a few of them--

https://www.sapphire.net/security/snort-rules-examples/
https://cyvatar.ai/write-configure-snort-rules/
https://www.crowdstrike.com/cybersecurity-101/threat-intelligence/snort-rules/

@John-Willard The pinned posts in this category are a good start.

@Danil-0 said in Suricata logs:

Is it possible to disable repeatedly logs from suricata to main log?

For example, i have only one line on suricata log.
Suri_block.png Hi,

If attacker repeated attempt, i have more line on main firewall log
Sys_log.png

Also i have disable Log to System Log.

Thanks for help.

Suricata does not put those entries in the System Log that you marked. Those are from the pf firewall engine itself. It's logging traffic hitting the built-in rule that exists for the snort2c pf table that is used to implement Suricata blocking (and Snort, if that package is installed). Suricata does not, and cannot, log to the firewall log tab. It can only log to the system tab.

Suricata "blocks" by adding IP addresses to a pre-existing pf firewall engine table. pfSense creates a built-in rule automatically each time it builds the firewall rules that blocks IP addresses added to the snort2c table.

You should not see these logged entries if you enable the option to "do not log default rules" in the Settings tab of the System Logs tab of pfSense.