DoS via CnCNet Tunnel

[gatekeep]

I host the 108.58.56.150 tunnel server, "CSE -- New York Tunnel (www.circlesoftus.org)". Over the past 2 weeks or so (I just isolated and killed the problem a few days ago), I've been getting a psuedo-distributed denial of service against our network via the tunnel server.

 

From what I can tell we had a huge range of IP's from an ISP in Africa (Egypt to be specific); that was opening hundreds of thousands of persistent UDP connections to port 50000 that would remain open (we actually looked at the raw connection statistics and at one point we had 791,000+ open connection states, normally we have less then 10,000 open connections simultaneously). This effectively choked our edge router from being able to pass traffic. I'm sure this isn't actually a bug with the tunnel server itself, but I wanted to put it out there that this was occurring (because I'm sure our tunnel going up and down was ruining fun for people). What we did to mitigate the problem was to blackhole the entire 156.192.0.0/11 subnet (sorry anyone in that subnet).

 

I don't know if anyone else in the community whom hosts tunnels has run into this issue or not. But I wanted to make those of you whom do, are aware that this kind of activity appears to be going on. My group and I are dedicated to continuing to support and host a tunnel for CnCNet though! Command and Conquer forever!

 

Thanks.

[hifi]

Hello and thanks for your continued support!

 

I'm aware the tunnels might be abused for non-game traffic or UDP flood and it's very hard to fight against it. If you happen to be a developer and know a bit about networking and UDP, you could take a look at the actual tunnel source and figure out if there are some holes that could be patched up. It wouldn't be surprising if my code is not air tight as it hasn't really been audited by anyone else.

 

As for what your investigation concluded, wouldn't this issue exist with any public ip? Unless the tunnel is actually passing the packets somewhere it's just getting hit with stuff it will drop on the spot and would act like the packet was dropped as no NACK is sent with UDP if the target port isn't listening. Are you sure those open connections weren't TCP as the tunnel listens on TCP for the HTTP session control commands?

 

And for the tunnel itself, there are a few conditions that should be met for the tunnel to pass any UDP traffic through:

 

[*]session is requested over HTTP with the number of end points that will be connecting

[*]incoming UDP packet has a valid source (own) ID header

[*]incoming UDP packet has a valid target ID header

[*]target ID has sent a packet so it's locked to an ip address where the data can be sent to

[*]both IDs need to be in the same session

 

Only if all above is met a packet is let through. At least in theory.

 

The source is at https://github.com/hifi/cncnet-tunnel if you're interested. It would also be a great idea to rewrite the tunnel in some other language for server side use to gain better performance under heavy load.

[gatekeep]

As for what your investigation concluded, wouldn't this issue exist with any public ip? Unless the tunnel is actually passing the packets somewhere it's just getting hit with stuff it will drop on the spot and would act like the packet was dropped as no NACK is sent with UDP if the target port isn't listening. Are you sure those open connections weren't TCP as the tunnel listens on TCP for the HTTP session control commands?

 

To be quite honest, we didn't check if it was TCP or UDP; and based on what your saying (and without looking at our log history) I almost immediately assume it was likely TCP, as these connections were remaining open. Yes; this could be an issue with any public IP, however, based on what was uncovered it seemed to be someone most definitely abusing some part of the tunnel software.

 

The source is at https://github.com/hifi/cncnet-tunnel if you're interested. It would also be a great idea to rewrite the tunnel in some other language for server side use to gain better performance under heavy load.

 

I wasn't aware the tunnel was open source, now that I know it is; I will take a look at it.

[SiRaLeX]

persistent UDP connections to port 50000 that would remain open

Newsflash, UDP is connectionless, brah.