Uknown VLAN Traffic with Suricata IPS Inline Mode
-
Good evening @bmeeks, thank you very much for the details, I was hoping for your intervention!!
I changed the option as indicated, saved the configuration (I verified that the change was correctly in place), and restarted the Suricata probe from the LAN interface in question, but I am still unfortunately seeing this type of alert:
I read the post on Suricata's forum, the configuration of VLANs should not have any particular misalignments...on my “core” switch, the only particular configuration is on the UniFi access points ports, which have the managment VLAN in access and tag all VLANs that are then propagated by the WiFi network SSIDs...but the chain should still be respected.
In order to go and check where any configuration of this type possibly resides, would you know if from logs I can somehow figure out what kind of package Suricata sees that it can't recognize?
Thank you again!
-
@Alessiottero said in Uknown VLAN Traffic with Suricata IPS Inline Mode:
Good evening @bmeeks, thank you very much for the details, I was hoping for your intervention!!
I changed the option as indicated, saved the configuration (I verified that the change was correctly in place), and restarted the Suricata probe from the LAN interface in question, but I am still unfortunately seeing this type of alert:
I read the post on Suricata's forum, the configuration of VLANs should not have any particular misalignments...on my “core” switch, the only particular configuration is on the UniFi access points ports, which have the managment VLAN in access and tag all VLANs that are then propagated by the WiFi network SSIDs...but the chain should still be respected.
In order to go and check where any configuration of this type possibly resides, would you know if from logs I can somehow figure out what kind of package Suricata sees that it can't recognize?
Thank you again!
That rule triggering is one of the built-in Suricata rules -- specifically
decoder-events.rules. I can't find any clear definition of why that rule would trigger. I see in the C source for Suricata where the flag is set, but again it's not clear to me why (at least in the time I had for a cursory examination). You might ask this question on the Suricata forum here: https://forum.suricata.io/. If you do that, just ask the generic question of what that rule SID (2200067) is looking for and why it would trigger. If you mention "pfSense" in your question, that may get the focus and folks will say to come back here. But your question is about that rule and what triggers it, and that is not related necessarily to pfSense.I would be interested in hearing what you find out. I also monitor that upstream Suricata forum.
-
-
@Alessiottero said in Uknown VLAN Traffic with Suricata IPS Inline Mode:
Ciao @bmeeks, thank you again, I have write right know on the Suricata forum!
If you are interested this is the topic.
Thank you very much again, we will update soon I hope!
I checked on your Suricata forum post. Excellent way to phrase your question. It leaves the focus on why that rule would trigger and does not muddy up the water by mentioning pfSense.
There are several key Suricata developers that frequent the forum. Hopefully one of them will answer soon. I am curious myself about the answer to your question.
-
Same problem here.
I'm not blaming the hardware as this started happening with the upgrade to the latest version of Suricata back in Jan. I've tried all sorts of configuration combinations with no luck.
So following any update in this thread.
-
@graphene said in Uknown VLAN Traffic with Suricata IPS Inline Mode:
Same problem here.
I'm not blaming the hardware as this started happening with the upgrade to the latest version of Suricata back in Jan. I've tried all sorts of configuration combinations with no luck.
So following any update in this thread.
This is the reply from the lead developer of the upstream Suricata team, Victor Julien: https://forum.suricata.io/t/decoder-events-rule-sid-2200067/5319.
-
Good evening @bmeeks @graphene, unfortunately I have not yet been able to clarify the causes leading to this error, but in my small home network I think I have reached the conclusion that the error comes from my UniFi access points.
Blocking via SID lists on devices connected to the wifi works correctly (for example I tried with some DNS resolutions with "bad" TLDs), but both before and after the logged drops a flood of warnings related to unknown traffic is reported.
I tried changing the AP configuration, enabled the VLAN override to connect APs with exclusively tagged ports and vice versa to set my management VLAN in access, but no change had any effect.
Unfortunately I don't have much knowledge of traffic analysis, but if you have any advice I am available for any test to better document and understand the error in question!
-
All of the built-in Suricata rules are informational in nature. They do not, and were never intended to, detect malicious traffic. They simply "inform" on things passing by. In the majority of cases admins really don't care to know and thus should disable many of the built-in informational rules.
All the rule in question here means is that a VLAN packet came by with a 8-bit "type" number embedded that Suricata (the binary piece) is not currently coded to recognize. Thus the alert -- "unknown VLAN traffic". It is a completely harmless informational message just letting you that the binary does not currently recognize some particular 8-bit type. Don't confuse VLAN Type with VLAN ID. They are not the same thing. In the Suricata binary I believe they call this VLAN Layer and it is currently programmed to only recognize the values 0 - 3. Here is some documentation on using the VLAN rule keywords: https://docs.suricata.io/en/latest/rules/vlan-keywords.html.
It does not mean something malicious is happening. A similar example would be a rule triggering on a malformed packet. That does not automatically mean "bad actor". It most commonly is simply an error in transmission caused by some electrical glitch on the wire.
One of the things to learn about IDS/IPS is that some rules are meant for either informational or debugging purposes and have nothing at all to do with detecting malicious traffic. If an informational rule is alerting (and/or causing a block on your network), and you don't want to constantly be alerted to that traffic, you can disable that SID. In your case, I would definitely disable that SID and be happy
. -
Ciao @bmeeks, thank you for details, this is exactly the point that I would understand: despite the VLAN traffic warnings, can I be sure that all the traffic on the physical interface will be analyzed and eventually blocked or logged by Suricata?
The blocks that I have mentioned are related to some Proofpoint ET rules that I add in my SID drop list, and apparently are working (for requests performed by different hosts on different VLANS) although the continous warnings.
-
@Alessiottero said in Uknown VLAN Traffic with Suricata IPS Inline Mode:
can I be sure that all the traffic on the physical interface will be analyzed and eventually blocked or logged by Suricata?
Yes, Suricata will see the traffic crossing a physical interface that Suricata is enabled on. Whether or not the traffic is alerted on and/or blocked is determined by what rules are enabled and how their actions are configured (rule action is critical when using Inline IPS Mode).
The alerts about unknown VLAN Type is simply Suricata saying "I am analyzing this packet stream and I found a VLAN Type I don't recognize". That is an informational message only. It does not mean malicious nor does it mean Suricata will cease analyzing that packet stream. It's just the program's way of saying "I am doing my job and I saw this while examining the flow".
-
@bmeeks Okk perfect, then I can sleep sound dreams by silencing the SID!
Now I am that I understand the meaning of the warning I am more relaxed, let's say that if you talk about "unknown traffic" relative to an IDS it becomes easy to get scared!!!
At this point I wanted to ask you, in my spare time I would like to figure out what is the cause of the warning, is it possible to mute the warning via SID mgmt list only for some VLAN/subnet/IP hosts without canceling it for the whole physical interface (of course in the Inline mode on LAN interface I'm promiscuous mode scenario)?
-
@Alessiottero said in Uknown VLAN Traffic with Suricata IPS Inline Mode:
At this point I wanted to ask you, in my spare time I would like to figure out what is the cause of the warning, is it possible to mute the warning via SID mgmt list only for some VLAN/subnet/IP hosts without canceling it for the whole physical interface (of course in the Inline mode on LAN interface I'm promiscuous mode scenario)?
If you wish to mute or disable a SID for a particular host or subnet, you do that using the Suppress List. Using that list you can suppress rules from triggering for certain IP addresses using the "track_by_src" or "track_by_dst" options. Those can be either single IP addresses or subnets. You can, using the suppress tools, suppress all alerts for a given IP or network, or suppress only a given SID (rule) for a specified IP or subnet.
You can't suppress SIDs for particular IP addresses or networks using the SID MGMT tool. That tool only works on the rules themselves, not which IP addresses or interfaces the rules apply to. The logic there can enable SIDs, disable SIDs, change SID actions, or modify SID content on a limited basis, but you can't control what VLAN or IP or subnet the rule might apply to.
Here are the official docs showing the syntax for thresholding (or using Suppress Lists in the pfSense Suricata GUI): https://docs.suricata.io/en/latest/configuration/global-thresholds.html#suppress.
-
Good evening @bmeeks, good to know, I had not yet discovered this suppression function, thank you!
I don't want to dirty the topic too much, which could be useful for those who, like me, will run into the warning in question, but can I just ask if SID mgmt (disable list) and suppression lists can co-exist?
Could you advise me of ‘best practices’ or use cases for which one method is preferred over the other?
I guess SID mgmt is better for applying global exclusions, like for silencing stream rules that are not useful except for troubleshooting, and suppression lists for excluding specific hosts or subnets in the inspections, correct?
-
@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.
