Question on STUN traffic no ndefault ports

[michmoor]

I understand the purpose of STUN especially when it comes to certain types of real time traffic such as MSFT Teams calls for example.
Usually associated with these types of flows is some non-standard port used other than 3478.
I got some IDS alerts for STUN traffic being detected but on ports 53 and 123. Why would any application or web service need to use stun for DNS or NTP? Whats the use case for any application on this?

login-to-view

[bmeeks]

You would need to examine the actual text of the triggering rule to see what exactly the rule is looking for to trigger.

My guess is the traffic is not really STUN. It just happened to randomly match some pattern the rule was looking for. Not all the rule authors are geniuses . Very easy to get tunnel vision as a rule author and forget other random data patterns that could trigger your detection logic unnecessarily.

[michmoor]

@bmeeks
In this case this rule is wrong all around.

alert udp $HOME_NET any -> $EXTERNAL_NET :1024 (msg:"ET INFO Session Traversal Utilities for NAT (STUN Binding Request On Non-Standard Low Port)"; content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4; 

As you can see from my screen shots the Dports are 123 or 53 and the rule for some reason wants to match port 1024.
To me, that alone makes it a false positive. I cant speak on the bytes depth as i dont have a pcap but this rule is wrong.

[bmeeks]

@michmoor said in Question on STUN traffic no ndefault ports:

@bmeeks
In this case this rule is wrong all around.

alert udp $HOME_NET any -> $EXTERNAL_NET :1024 (msg:"ET INFO Session Traversal Utilities for NAT (STUN Binding Request On Non-Standard Low Port)"; content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4; 

As you can see from my screen shots the Dports are 123 or 53 and the rule for some reason wants to match port 1024.
To me, that alone makes it a false positive. I cant speak on the bytes depth as i dont have a pcap but this rule is wrong.

Not exactly correct. That syntax (:1024) means "any port number with 1024 or less". So, 123 and 53 are both less than 1024. If the range had been specified as (1024:), that would mean any port with number 1024 or greater. And a port range specified as (1024:2048) would mean any port greater than or equal to 1024 but less than or equal to 2048.

[michmoor]

@bmeeks Ahhhhhhh thanks for clearing that up. Makes sense. Thank you sir.

[bmeeks]

So that rule is looking for particular content in the payload AND a destination port of 1024 or less (typically meaning a privileged low port). In your case, the destination port range matched and then so did some pattern in the packet's payload. But still likely not truly STUN traffic.

[michmoor]

@bmeeks I wish I knew what specific application caused the alert but by the time I checked there was no firewall state so couldn’t dig in.
So from what I gather the rule looks for a stun server based on looking for privileged ports and a stun payload but I can rule out any malicious actor as this is a very recent Windows 10 build. Nothing installed but default apps

[bmeeks]

@bmeeks said in Question on STUN traffic no ndefault ports:

content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4;

The rule is simply looking for a particular pattern of bytes within a given range of bytes in the packet's payload (in this rule, it's looking for the Magic Cookie byte sequence 2112 a442):

content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4;

Here is a description of the STUN protocol down at the byte level: https://subspace.com/resources/stun-101-subspace.

It is entirely possible for some given DNS or NTP payload to randomly match on that sequence of bytes. The problem with these types of rules is they are never absolute. That's why the rule is in the ET INFO category -- it can't be 100% certain with no doubt that the traffic is correctly identified every time.

So, TLDR, the rule is really sort of meaningless in my opinion. It cannot absolutely say some given traffic is STUN, and there is lots of legitimate traffic that uses port numbers less than 1024. And any packet payload might just randomly happen to contain a triggering byte sequence from time to time, most especially when the packet payload is encrypted.

[JonathanLee]

Sorry I am late to this party. I had issues with STUN and the IPS blocking traffic. It was for my son’s Nintendo switch and Xbox for the chat feature. Once I suppressed the alarms the chat live voice feature worked perfectly. I also think that FaceTime requires you to suppress the STUN alarms. Long story short STUN is finally working on my system as of today.