I'm noticing that when I do reports or look at live connections, I see a lot of STUN traffic. And it's a LOT of traffic, which is puzzling in that I thought STUN was merely a tool to figure out how to get a direct connection when that would otherwise be frustrated by being behind NAT. So I would expect little actual STUN traffic.
But it appears that -- at least for certain considerations -- SFOS is smart enough to follow a STUN series of exchanges and the resulting successful connection and consider all of that and the follow-on traffic to be "STUN traffic". Does anyone have insight on this?
I'm running a dual-stack (IPv4/IPv6) network via an IPv6 6in4 tunnel, and I see IPv6 STUN traffic, too, which makes no sense. (Unless somehow not being "native" IPv6 causes problems that appear to STUN algorithms to be NAT-like.)
I've blocked STUN ports (TCP/UDP 3478 and TCP 5349) under IPv6, and it is in fact blocking traffic. I'm wondering if this is an oddity whereby STUN is focusing on IPv4 but Apple prioritizes IPv6. I also have a separate IPv4 firewall rule for STUN ports, to monitor things and traffic under this rule is low. Which is why I'm assuming that SFOS follows the connection resulting from STUN mechanisms and considers it STUN for some Application purposes. (Though I think there are other Application displays where the traffic is thrown under SSL or some other Application type.)
I have traffic shaping that should apply to various conferencing software (Teams, Zoom, etc), and I see some amount of traffic associated with them, but it also appears that some large amount of traffic is considered to be STUN and I assume it is not traffic-shaped or prioritized as conferencing.
Again, any insights or tips on STUN traffic?
Hello Wayne Folta,Thank you for reaching to the community, STUN is standard protocol for traversal of network address translator gateways in applications of real-time voice, video, messaging, and other interactive. The same protocol is also used in What's app application too. However if you wish to block the protocol, you can block with the help of application filter, as shown in the example below:Application filter has a higher precedence in respect to web filter. > Just ensure the IPS engine is running and patterns for the IPS and Application signatures should be up to date.
Thanks & Regards,_______________________________________________________________
Vivek Jagad | Technical Account Manager 3 | Cyber Security Evolved
Sophos Community | Product Documentation | Sophos Techvids | SMSIf a post solves your question please use the 'Verify Answer' button.
I've accepted the answer because it has a way to address STUN via IPS, which I hadn't thought of.
At the same time, I'd like to know more about what SFOS considers to be STUN traffic. As I said, STUN appears to be a set of tools for figuring out how to directly communicate, not a transportation mechanism. In which case, I shouldn't see GB of "STUN" data in reports. As I understand it, once an application has used STUN to figure out how to directly connect it will then use that connection and not "STUN".
So is SFOS watching STUN happen and then continuing to regard the ongoing connection as STUN traffic? And why would it classify IPv6 traffic as STUN when one of the key characteristics of IPv6 is that it does not require STUN?
The vast majority of SFOS installations probably can't completely prohibit STUN. Maybe limit the initial STUN servers to known servers, or maybe prohibit for some users, etc, but ultimately if you're running IPv4 and you have people who want to conference you need to allow some level of STUN.
Hey Wayne Folta,IPS uses snort engine and the current version of snort is 126.96.36.199Which does not support IPv6 as of now. And STUN uses UDP Port 3478 - based on the initial packets of "Allocate request/success" that is how it determines the traffic and blocks or allows based on the action selected in the application filter.