@marcosm We're all set. Thank You !

@skogs Sometimes, it takes a village. :)

@stanwij1
https://chatgpt.com/

what is suricata rule 2013075

Suricata rule 2013075 is a rule designed to detect network traffic associated with the C&C (Command and Control) communication of malware. Specifically, this rule is meant to detect possible communications from a malware sample to a command and control server using HTTP as the communication protocol.

The rule is part of Suricata’s signature-based detection for potential malicious activity. In this case, it focuses on identifying unusual or suspicious HTTP traffic patterns, often tied to botnets or other forms of malware that rely on HTTP-based C&C communications.

what is suricata rule "ET MALWARE Large DNS Query possible covert channel"

The Suricata rule "ET MALWARE Large DNS Query possible covert channel" is a rule designed to detect potential malware activity that uses DNS queries as a covert communication channel.

Explanation:
ET MALWARE: This indicates that the rule is part of the "Emerging Threats" (ET) signature set, which focuses on detecting malware-related traffic or behavior.
Large DNS Query: This suggests that the DNS query in question is unusually large. DNS queries typically contain small amounts of data (like domain names), but in some cases, malware might use DNS queries with larger payloads, which can be a sign of malicious activity.
Possible Covert Channel: A covert channel refers to a method used by malware to bypass security mechanisms by hiding data inside legitimate traffic. DNS, being a commonly used protocol for legitimate purposes, can sometimes be exploited by attackers to transmit data or control commands stealthily.
Why It’s Important:
Malware can use DNS queries to communicate with a command-and-control (C&C) server, exfiltrate data, or receive instructions. By embedding large or unusual data in DNS queries, attackers can avoid detection by blending in with normal DNS traffic. This rule is designed to catch those suspicious large DNS queries, which could indicate that such covert communication is taking place.

How It Works:
The rule triggers when a DNS query exceeds a certain size threshold, as large queries are unusual and could signal that the DNS protocol is being used for non-standard, potentially malicious purposes.
It is part of a broader effort to detect "DNS tunneling," a technique where attackers use DNS to bypass network filters or firewalls.
In summary, the "ET MALWARE Large DNS Query possible covert channel" rule is meant to flag large DNS queries, which could be indicative of malware trying to communicate or exfiltrate data in a covert manner using DNS.

@Alessiottero said in Uknown VLAN Traffic with Suricata IPS Inline Mode:

I guess SID mgmt is better for applying global filters or exclusions, like for silencing stream rules that are not useful except for troubleshooting, and suppression lists for excluding/including specific hosts or subnets in the inspections, correct?

That is correct. The two serve different functions. SID MGMT is for rules management on a global scale (or actually per configured interface). Suppress Lists allow the suppression of individual SIDs for chosen IP addresses or networks. You can also suppress a given SID for all hosts, but that feature is also easily done by simply listing that SID in a "disable SID list" in the SID MGMT tab. But you can't filter SID MGMT selections by IP address or subnet like you can do with Suppress Lists.

@AAS said in Block VPN connection with Snort:

These programs are installed on the computer and I want to block their connection.

The KIS solution : negotiate with the owner of that computer to de install them ?

If snort 'looks' (analyses) a VPN IP packet header, it can't detect if the originating program was a VPN app, as this app could use any IP addresses as a destination, any port as a destination, and the data payload is "TLS encrypted" so it will be recognized as "noise".
True, if the app was using the default UDP, and port 1194, then that could mean that the traffic is VPN traffic. It still is just a possibility, not a fact.
The VPN app could even use port 443, protocol TCP as a destination, so the traffic is now identical ordinary "https" web traffic. Good luck blocking that.

It's solved. It was caused by my son.

@btspce said in Switch from ETPro to ETOpen rules:

I'm going the other way from ETPro to ETOpen in this case

Yeah, sorry about that 😊. It says that right in the title and I still missed it.

@bmeeks copy that. Thank you sir

@bmeeks

For now I will leave it on WAN and over time setup a virtual sever to test and play with configuring Snort on LAN

Thank you for all the help and taking the time to explain this to me.

Jon

@tchadrack

Thermal Sensors
Zone 1: 29.9 °C
Zone 0: 27.9 °C

Name ..**
User admin@192.168..** (Local Database)
System pfSense
Netgate Device ID: ******************
BIOS Vendor: American Megatrends Inc.
Version: F2
Release Date: Mon Oct 7 2013
Version 2.7.2-RELEASE (amd64)
built on Fri Dec 8 17:55:00 -03 2023
FreeBSD 14.0-CURRENT

The system is on the latest version.
Version information updated at Sat Feb 1 9:35:25 -03 2025
CPU Type Intel(R) Pentium(R) CPU G3220 @ 3.00GHz
2 CPUs: 1 package(s) x 2 core(s)
AES-NI CPU Crypto: No
QAT Crypto: No
Hardware crypto Inactive
Kernel PTI Enabled
MDS Mitigation Inactive
Uptime 1 Day 03 Hours 20 Minutes 04 Seconds
Current date/time
Sat Feb 1 9:44:46 -03 2025
DNS server(s)
8.8.8.8
8.8.4.4
Last config change Sat Feb 1 9:05:02 -03 2025
State table size
0% (222/1000000) Show states
MBUF Usage
5% (18856/371768)
Temperature
27.9°C
Load average
0.47, 0.48, 0.42
CPU usage
4%
Memory usage
53% of 5980 MiB
SWAP usage
17% of 3851 MiB

DISKS:
Mount Used Size Usage
/ 28G 447G
7% of 447G (ufs)

SERVICES:
arpwatch Arpwatch Daemon
bandwidthd BandwidthD bandwidth monitoring daemon
captiveportal Captive Portal: **********
darkstat Darkstat bandwidth monitoring daemon
dpinger Gateway Monitoring Daemon
kea-dhcp4 Kea DHCP Server
ntopng ntopng Network Traffic Monitor
ntpd NTP clock sync
openvpn OpenVPN server: *************
pfb_dnsbl pfBlockerNG DNSBL service
pfb_filter pfBlockerNG firewall filter service
radiusd FreeRADIUS Server
sshd Secure Shell Daemon
suricata Suricata IDS/IPS Daemon
syslogd System Logger Daemon
unbound DNS Resolver
vnstatd Status Traffic Totals data collection daemon

S.M.A.R.T. Status
Drive Ident S.M.A.R.T. Status
ada0 WD-************ PASSED

@Soloam said in Suricata Inline add supress with dynamic IP:

@bmeeks said in Suricata Inline add supress with dynamic IP:

No. Aliases are not supported by Suricata in Suppress Lists. This is a limitation in the binary. Those lists are not "dynamic". They are loaded and parsed only once at startup.

Tks for the replay and all your work on this!

Is there a way to do this? Can I do it for exemple with "Modify SID List"? Can they have external alias?

No, you can't use firewall aliases in the Suricata rules. The binary that performs the actual work is completely unaware of things pfSense. It simply reads the addresses directly from the suricata.yaml file for the interface and runs using those. What you interact with in the GUI is just PHP code that creates the text-based suricata.yaml conf file for the Suricata instance. Then, when the binary Suricata service is started, it reads that conf file just once and uses the values stored there.

@stanwij1 said in Have a question on SIB Management Drop SID List:

@bmeeks thanks for your response, yes using Suricata. Issue is, using legacy mode, I went into individual interface rules, and clicked the Action and changed to Drop, but it isn't dropping, still showing in alerts, is that because need to check the box to Block on Drop?

Yes, you must check the box on the INTERFACE SETTINGS tab to enable "Block on DROP Only". That is a config logic flag the code checks in other places so it knows what options to offer the user in the GUI.

@bmeeks said in Recommended Snort rules to change from "Alert" to "Block"?:

@Enso_ said in Recommended Snort rules to change from "Alert" to "Block"?:

Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time.

I recommend leaving that setting alone, too. You generally don't want blocks hanging around forever. Not only do they consume resources, but if the block was due to a false positive you would like it to automatically clear in a reasonable time without requiring admin action.

If Snort blocked the traffic the first time, it will block it a subsequent time later on (if the blocked host is automatically periodically cleared).

One issue with Legacy Blocking Mode is that it is a big hammer. It blocks ALL traffic to a blocked IP for ALL internal hosts.

Inline IPS Mode, if you can use it (your NICs must support netmap natively), drops individual packets instead of blocking everything to/from the IP. That's much more granular. But with Inline IPS Mode, you must explicitly change rules you want to block traffic from ALERT to DROP using the features on the SID MGMT tab.

I'm leaving the setting to remove the blocked host after 1h.

As for inline mode; that is something I want to circle back to in the future. However, currently there are no resources that could configure inline mode in a timely fashion. Plus, I'm quite sure I'd have to upgrade the NICs to support netmap.

@bmeeks Thanks for the clarification. We have now added a "Disable SID List" conf file on all interfaces with the categories we want disabled which should solve it.

@pftdm007 said in Important Info: Inline IPS Mode with Suricata and VLANs:

@bmeeks

Just found out about this thread and am curious to ask...

If I understand correctly, neither Snort or Suricata are capable of differentiating traffic through VLAN's from their parent interface and therefore cant do inline filtering at the VLAN level...

I didnt know this, and created a Snort instance for each VLAN I have on my lan (parent interface) using different rulesets (some VLANs are more restrictive than others, etc etc...)

Unless I am wrong (and I need to do more testng) is that I noticed what you described (i.e. if something is blocked on a VLAN, it is blocked on all VLANs of the same parent interface). However, the advantage of having snort run on VLAN's instead of the parent interface is that in the reports tab, I can tell on which VLAN the block occured. I find it more straightforward to troubleshoot something that way.

IS there any drawback other than consuming more resources ? I didnt notice any instabilities at the firewall level so far.....

It should be fine to continue with your current configuration. As you observed, under the covers Snort is actually running on the physical parent interface and polices traffic at that level (meaning all VLANs on the same parent are treated as a single network). This is due to the how the netmap kernel device in FreeBSD is wired into the network stack. It does not see the VLAN tags. It's the netmap device that makes IPS mode possible, and since it can't see VLAN tags, then IPS mode can't use them to separate and treat the defined VLANs differently.

Snort will log a message to the pfSense system log as it starts. If it fails, generally the reason for the failure is also logged. The only exception to that is if a shared library is the wrong version or not present. That would only happen if you installed or updated some other package that shared a library with the Snort binary. That is very unlikely -- but not impossible.

The most common reason for Snort failing to start would be an error with a rule. It is not unheard of for the Snort VRT to release a rules update package with a syntax error in it. Snort will abort startup when it detects a syntax error. Rule syntax errors will be logged to the pfSense system log.

So, <TLDR;> check the pfSense system log immediately after trying to start Snort and see what is logged there. That will clue you in to the problem.

@bmeeks Thanks !

@bmeeks signed up. Thanks for the info.

@bmeeks said in packet log being generated?:

You will need to examine the existing PHP code files and learn by example

Thought so. @michmoor, you need the other book.

b702f6a8-9a39-444c-a837-b4f8cbe40540-9780470527580.jpg

Click the image.

edit : or this one.