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.

@dread said in [1:2240006:2] SURICATA DNS Z flag set:

So my question is, do you usually see this Z flag alert(s) and/or do you think it could be some malware installed on a device? (in my case, one android phone)

Anyone? Thanks!!

When you uncheck the Enable checkbox on the Suricata INTERFACES tab, that Suricata instance will never auto-start (even on a pfSense reboot). But if the Enable box is checked, the interface will auto-start upon a reboot of pfSense even if the interface had been manually stopped before the reboot.

One perverse thing with Suricata and the way it handles TCP sessions and flows is that the more CPU cores you throw at it, the more RAM it demands for the TCP Flow/Memcap parameter. Start simple with just 4 cores assigned to Suricata and 4 GB of RAM in the virtual machine.

And start with Legacy Blocking Mode instead of Inline IPS Mode. Legacy Blocking does not bring in the netmap kernel device and thus will likely bypass any issues existing there in Proxmox. And as I said earlier, you really can't successfully use VLANs with Inline IPS Mode (at least not without a lot of weirdness up to and including random crashes).

Suricata

@Antibiotic said in Snort rules order:

@bmeeks Hello again!
Now did dropsid for some rules and its working. But how to make drop action for whole category?Lets say category: emergening-ja3-rules want to drop action for all category.

The numbers are going not but orders and click whole category too long or make dropsid with a different numbers. Is it possible to make drop action for whole category? Suricata

Go read this Sticky Post at the top of this sub-forum: https://forum.netgate.com/topic/128480/how-automatic-sid-management-and-user-rule-overrides-work-in-snort-and-suricata.

@munson: I believe you posted this in the wrong sub-forum. This has nothing to do with the IDS/IPS packages.

Perhaps you should have posted this in the pfSense "Problems Installing or Upgrading pfSense Software" sub-forum here: https://forum.netgate.com/category/5/problems-installing-or-upgrading-pfsense-software?

The UUID I was referring to is for the top-level log directory for a given instance. On pfSense, the package uses the physical interface name along with a UUID to create directory paths unique for each configured Suricata instance. So, under /var/log/suricata/ you will see a different unique sub-directory for each configured Suricata interface. Within a given instance's log directory you will find additional sub-directories for various optional logging. One of those is captured/extracted files.

Suricata itself, when configured to capture files, will create its own unique sequence of sub-directories under the file capture logging sub-directory based on hash values. The following section of italics text is copied verbatim from the Suricata docs:

The file-store module uses its own log directory (default: filestore in the default logging directory) and logs files using the SHA256 of the contents as the filename. Each file is then placed in a directory named 00 to ff where the directory shares the first 2 characters of the filename. For example, if the SHA256 hex string of an extracted file starts with "f9bc6d..." the file will be placed in the directory filestore/f9.

Here is the link to the file extraction documentation for Suricata: https://docs.suricata.io/en/suricata-7.0.4/file-extraction/file-extraction.html.

@bmeeks Aha, thank you, I knew I was forgetting something. I'd setup the drop rules a while back and forgot there were disable sid rules I could use too :)