Suricata custom List
-
Bmeek,
I'm trying to create a custom list the will allow unimpeded connection to my VPN server. I came something like this:
pass udp 10.0.1.2 any -> <VPN IP>any (msg: "VPN Connection"; sid:xxxxx;)
Is my syntax correct? Dunno what to put in SID.
-
Your rule syntax is okay, but be sure that's what you really want. PASS rules are evaluated first, and any traffic matching a PASS rule bypasses all further analysis. It is not sent into the decision tree for any of the rule signatures. The rule as you have it written will cause all UDP traffic from IP 10.0.1.2 to IP address <VPN IP> to essentially bypass Suricata. If that's what you want, then good. But just making sure that is what you desire.
Research how SIDs work and the protocol around them. Number one requirement is a SID cannot be duplicated! Google can be your learning tool here. Search for something like "Suricata user SID range".
-
The pass list is an encrypted connection Would you suggest to bypass this as Suricata can't read it anyway?
-
@MagikMark said in Suricata custom List:
The pass list is an encrypted connection Would you suggest to bypass this as Suricata can't read it anyway?
Not sure what you mean by "pass list" in this context. A Pass List is a specific construct in the pfSense version of Suricata as it is a critical component of the Legacy Blocking Code.
If you instead mean to say "pass rule", then yes there is no reason to inspect any encrypted traffic as Suricata can see nothing but the IP headers, and in the case of some SSL/TLS stuff, the SNI header. But it cannot peer into the packet payload at all unless MITM is in place to break the encryption. But MITM is not something the current pfSense setup of Suricata can accomplish without a ton of manual customization by the admin.
-
Yes, "pass rule". Thank you
I will now familiarize my self with SID.
-
Bmeeks
Just need to be assured. Is it ok to use same SID for different Source/Destination IPs with the same rule? SID is associated exclusively with rule. It doesn't care on Sources and Destination, right?
Can you help me make a rule to bypass streaming. This is ok right? I stream a lot of youtube. I thought maybe it's a waste of rsouces to examine its packets
-
@MagikMark said in Suricata custom List:
Is it ok to use same SID for different Source/Destination IPs with the same rule?
SID is the acronymn for Signature ID. It uniquely identifies a rule in the rules engine array in memory. If you are familiar with relational databases, think of the SID as the same as a primary key in a relational database entry.
The SID identifies the specific rule and not elements of the rule. Elements would be source and destination IP addresses and ports or the specific data payload to be looking for as a trigger for the rule.
The generally accepted protocol for user rules (also known as custom rules) is to start those SIDs at 1000000 or greater to be sure you do not collide with the ranges used by the commercial rules providers such as Snort VRT, Emerging Threats/ProofPoint, etc.
@MagikMark said in Suricata custom List:
Can you help me make a rule to bypass streaming. This is ok right? I stream a lot of youtube.
No, this is not possible. You must new to networking
. Streaming services use CDNs (content distribution networks) that are scattered around the world. Each time you make a connection to a streaming service such as YouTube, it will almost always be with a different IP address. It will not be the same one. CDNs may frequently change what IP blocks they use at their various data centers. The best you can do here is research the ASNs assigned to the streamer host and use those large subnets in the rule.Since you mention YouTube, I assume you are setting up Suricata on a home network. To be perfectly honest with you, that is a waste of time. Nearly 100% of the traffic traversing your firewall is encrypted these days. DNS can be over DoT or DoH, email is exclusively done over TLS, and almost all web traffic is HTTPS. Your IDS/IPS can't inspect a single piece of the payload data in that traffic. All it can see is the source and destination IPs, port numbers, and for some web stuff the SNI.
So, not only is the IDS/IPS going to be severely hobbled in what it can actually inspect, it's going to generate a fair amount of false positives on you generating needless blocks. Even though I am the developer of both packages, I no longer run an IDS/IPS on my home firewall and have not for several years. I only occasionally fire up an instance of Snort or Suricata on a virtual machine for testing code as I modify the packages.
-
Thank you for your thoughts.
You are right, I have very little alert/blocks on ids/ips. Most of them if not all are false positive. But it's cool to have one. Besides, my aplliance is under utilized. I just would like to maximize what it could do
-
@MagikMark said in Suricata custom List:
Thank you for your thoughts.
You are right, I have very little alert/blocks on ids/ips. Most of them if not all are false positive. But it's cool to have one. Besides, my aplliance is under utilized. I just would like to maximize what it could do
For a learning experience, running the IDS/IPS can be fun. Just realize there will be needless blocks and it will need constant monitoring and baby sitting. Any time something suddenly stops working, then immediately suspect the IDS/IPS and investigate all the blocks and alerts.
A lot of IDS/IPS (and pfBlockerNG) users install all these blocking packages, configure massive IP block lists and enable tons of IDS/IPS rules, then within a week are posting here on the forum in a panic because "pfSense is blocking XYZ. Why?" They usually totally omit from their initial post they are running one or more "blocking" packages on their firewall. And they have, of course, not even checked to see if their issue just might be due to one of those blocking packages actually blocking something
. Those kinds of semi-opaque posts can be really frustrating for those attempting to offer assistance. -
Thank you for your patience and understanding Bill. Your efforts are greatly appreciated
