----- Original Message -----
From: "Florian Zschocke"
Sent: Friday, January 24, 2003 4:31 AM
Subject: Re: [hlds_apps] preventing DDoS (was: hlds_apps digest, Vol 1
#138 - 3 msgs)


> Now you got me confused. I thought that after your explanations
> about the DDoS against UA we were back on topic about the DDoS
> risk having to do with HL servers which are completely unrelated.

Actually, no.  They are totally related.  The only difference between the
two is merely the ports really or a slightly different technique, which can
easily be scripted.

> > I think this is easily handled on Linux than win32.  In fact, you may
want
> > to look at this site:
> > http://www.netfilter.org/
>
> You don't even need to set up a netfilter firewall to protect a
> Linux machine against a SYN flood. The Linux kernel has
> syn-cookies support build in. All you need is a
> #  echo 1 > /proc/sys/net/ipv4/tcp_syncookies
>
> (Solaris has syn-cookies support, too, AFAIK.)

Windows 2000 and XP also have similar settings as well.  But, that basically
only deals with a low number of SYN connections and only adds wait-time to
the connections.  It still causes the OS to do something with the packets.
The netfilter will do the blocking before syncookies is needed.

In my recent experience, syn-cookies bought us like 1 hour on Monday
afternoon before the server was flooded off again.  Because, the attacker
will just throw more SYN connections at you until you reach the maximum
limit (which there is with syn-cookies).  Sure, you could raise the maximum
limit (not sure what the Linux setting is, but I've done it on my w2k
server).  But, that only causes more resources used and additional lag on
the server.

>
> > The SYN attacks typically come in blocks at a time.  See an example log
> > here:
> > http://grc.com/dos/drdos.htm
>
> I don't want to take sides or comment on that but I usually can't
> resist from giving people a link to http://grcsucks.com when I see
> a refernce to grc.com. :)

I wasn't supporting him or his products in any way.  But, his webpage has
the best examples and illustrations on the subject-matter and explains the
problem so that non-tech people could understand (to a degree).  You won't
find too many good illustrations in other SYN-flood topic sites.  If you
have any URLs that says otherwise, let me know.

> > I suppose Valve could build into HLDS something similar, but it's still
> > something better handled on the server side, IMO anyway.
>
> Huh? Now you're back to HLDS again. Valve could not build in
> something similar since HLDS uses UDP, not TCP. Apples, oranges.
> What we have here is a classic bandwidth flood. The best idea I've
> seen so far is the one with the small, simple handshake to
> establish if the client is really asking for an info packet.

This is true.  Although, not everything in HLDS is UDP though. I think the
added auth to the rcon connection has really helped.  But, I can see how a
DDoS attacker could easily flood the server with server query requests.
Those all request information from the server.  But, I'm not sure if there
is any anti-flooding built in for this feature.

> > Oh, and regarding flooding the router first, if this happens, it'll be
up to
> > your upstream provider to implement this anti-SYN type of filtering.
>
> No, it is up to your upstream provider to discard packets with an
> alien IP source address. That is the only way to effectively
> prevent the majority of DDoS attacks.

Yes, in a perfect world this would happen.  But, apparently, not even Time
Warner does this. O_o

HoundDawg

_______________________________________________
hlds_apps mailing list
[EMAIL PROTECTED]
http://list.valvesoftware.com/mailman/listinfo/hlds_apps

Reply via email to