SYN floods are a very well-understood attack and SYN cookies provide a
good defense against them.
One nice thing about TCP connections is that the handshake is done at
the level of the OS, not the application -- so it can take advantage of
other resources while the game server continues to chug along
independently, and there's more opportunity for tweaking.
-John
On 1/28/2011 7:28 AM, Saul Rennison wrote:
Please, read what I initially said.
"TCP would solve the issue for queries"
What's the issue with moving the query system from UDP 27015 to TCP 27016?
:/ However, TCP is also prone to DDoS via SYN floods:
"SYN flood<http://en.wikipedia.org/wiki/SYN_flood> sends a flood of TCP/SYN
packets, often with a forged sender address. Each of these packets is
handled like a connection request, causing the server to spawn a half-open
connection<http://en.wikipedia.org/wiki/Half-open_connection>, by sending
back a TCP/SYN-ACK packet, and waiting for a packet in response from the
sender address. However, because the sender address is forged, the response
never comes. These half-open connections saturate the number of available
connections the server is able to make, keeping it from responding to
legitimate requests until after the attack ends."
(see: http://en.wikipedia.org/wiki/SYN_flood)
Basically, ANY transport-layer protocol can be DDoS'd and brought down with
enough bandwidth-- it's the nature of the internet.
Thanks,
- Saul.
On 28 January 2011 15:12, Frederic Fortier<[email protected]> wrote:
Yes, a gameserver on TCP is really a bad idea because the handshake
creates a very high overhead. I'm pretty sure you can test it out by
yourself by adding -tcp to your client's startup line, and see if you enjoy
playing with a choke of about 60. Which is why UDP is used instead: while
it's easier to spoof the IP and DDOS without risking to be IP blocked, it's
still better than not being to play the game at all.
Le 2011-01-28 09:20, Emil Larsson a écrit :
Since it requires a handshake, TCP is impossible to spoof (unlike UDP). It
would make it a bit easier to block IP's since a handshake will fail if a
spoofed IP is used. Of course, most DOS bugs in SRCDS are from bugs and
lack
of packet caching/priority.
However it also have higher overhead, which is why you rarely see
gameservers using it as a protocol.
On Fri, Jan 28, 2011 at 3:05 PM, Saul Rennison<[email protected]
wrote:
I thought that TCP would solve the issue for queries and stuff like
that but in practice TCP is just as prone to DDoS as UDP -.-
On Friday, 28 January 2011, Marco Padovan<[email protected]>
wrote:
TCP for example...
Il 28/01/2011 13:45, frostschutz ha scritto:
On Thu, Jan 27, 2011 at 06:53:08PM -0500, clad iron wrote:
Would there be a way for the engine to identify
exactly where it's coming from and drop the connection ?
It's UDP, there are no connections and you can't stop others
from sending packets to you. So the best you can do is drop
without spending any unnecessary CPU time.
The protocol unfortunately is DDoS by design - if a game has
a ton of players and in one second 100 people around the
world refresh their server list at the same time, your server
has 100 queries to reply to 100 different IPs... per second.
So all you can do is make those queries faster.
Usually games just don't have enough players for this to be
a problem, but Valve is a monster in that regard.
The protocol could be designed differently to make it easier
to drop / delay unwanted packets, but protocol redesign is
not something you do on a regular basis for gameservers. ;)
Regards
frostschutz
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
--
Thanks,
- Saul.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
