DDraceNetwork - developer

traceroute -m40 hand.bb0.nl

00:06

(needs ipv6)

heinrich5991

interesting, didn't know the article that you posted @Learath2 http://ithare.com/udp-for-games-security-encryption-and-ddos-protection/

If the entire point of the article is to "encrypt" udp traffic, it won't make a difference. (edited)

00:13

Encrypting initial handshake packet as example, will make it way harder to seperate legitimate from malicious traffic.

Yes. At the filtering level encrypting will make it that much harder to tell a legitimate packet apart. But with all things there would still need to be a handshake. As long as there is a handshake that can be emulated at an upstream level it will make the game more easy to protect. CF for instance emulates a handshake for TLS for customers that don't want CF to see their traffic.

00:21

But encrypting UDP packets at the game level may become messy. Since often encryption changes based on previous bytes sent and also a video game does not care to resend a stale game world state so the encryption could fail.

Kigen

Yes. At the filtering level encrypting will make it that much harder to tell a legitimate packet apart. But with all things there would still need to be a handshake. As long as there is a handshake that can be emulated at an upstream level it will make the game more easy to protect. CF for instance emulates a handshake for TLS for customers that don't want CF to see their traffic.

The game is pretty damn easy to protect to begin with.

00:23

Everything you need is there, an initial UDP handshake challenge is sufficient.

00:23

(We've already made a filter, took about 2 minutes of looking at traffic in wireshark)

Yes. I was just pointing out problems with encrypting. But also that it probably won't affect filtering that much.

It could affect filtering, depending on how well the encryption is handled.

00:25

If there's still an easily recognizable handshake packet, no problem.

00:25

But again, "encrypting" packets will not solve ddos attacks.

00:25

It will stop users from messing with the game on network-level, but it won't really affect ddos attacks at all.

Encryption of this type does require a handshake process unless they have a pre-shared key. And yeah, encrypting has no effect on DDoS protection. Encrypting should be for the purposes of privacy or tamper protection to sensitive communications.

I agree, what I am trying to say is that if you introduced game-specific ddos filtering, and the initial handshake packet is being messed with by the encryption, filtering will just become way harder.

00:27

(Talking about the initial challenge packet (10\00\00\01\TKEN)) (edited)

00:28

Regardless, as you already said, encrypting will not "protect" you from ddos attacks.

I haven't had a chance to look at packet captures of this game's communication yet. But I am familiar with the concepts from building such filtering for the Source engine.

Well, with source engine, you'd still have to cache A2S_INFO packets

00:29

with this server application, you do not have to

There are a lot more attack vectors.

Not if your filtering works properly.

00:29

I'm not talking about just caching info packets, I'm trying to point out that this is not necessary with this game/mod (edited)

00:29

therefore it is even easier to craft a filter than for e.g. SRCDS, which is already fairly trivial (edited)

A2S_CHALLENGE, the connect 'k' packet. etc

A2S_CHALLENGE is handled pretty easily

The servers I worked on protecting got hit with everything under the sun.

Our SRCDS filter is ~100 lines of C, and I am fairly confident that it'd work flawlessly

I basically just fully emulated every unauthenticated communication.

00:31

And built in a ban and rate limit system.

00:32

Due to a dude that kept using so many VPNs to connect and attack the server that way.

Kigen

I basically just fully emulated every unauthenticated communication.

Do not allow any packets except for A2S_INFO, which you'll respond to from a cache instead. Listen for SRCDS challenge header, reply with a crafted packet, and validate that. Now, you start accepting other packets from that source ip & source port. Otherwise, drop. Bam, there you go. Only thing limiting you now is capacity.

I built that quite a few years ago.

00:33

And the capacity problem is something I'm trying to address now. But the issue is waiting for ARIN to give me a IPv4 /22.

Also, for the love of god, do not go with Cogent.

lol

I've seen someone mention Cogent in here, horrible choice.

My main issues have been with HE.net lately. They keep screwing up their BGP.

Kigen

My main issues have been with HE.net lately. They keep screwing up their BGP.

Should talk to Cogent Customer Support

00:35

"Sorry sir, BGP is not something we offer"

00:35

Cheap? Sure. Quality? If you stay within Cogent yes. If Cogent starts handing off packets to GTT / whatever other isp, you will start seeing packet loss. a lot.

Well, I've already been approved for an ASN, on a wait list for IPv4, and getting some IPv6 for giggles).

IPv4 should be handed out in a few days, if you're with ARIN (edited)

Yes, Oct 1.

if you're lucky, that is.

If I'm lucky. So far they've been able to fully fulfill their quarterly wait lists.

Kigen

Yes, Oct 1.

If you're lucky. Last time we've received an allocation was 10 days after allocations were given out

So I am quite hopeful.

and that was for a single /24

They do say it takes them a week after Oct 1 to fully distribute IPs.