<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40085 >

> [jdorje - Wed Feb 06 07:34:32 2008]:
> I believe such a feature exists in the warclient; would one of the
> warclient developers be willing to provide a patch for this?

Pepeto did implement a quick version of this
feature, I'll post a ported patch for S2_2
later today (gna svn seems to be overloaded
and I'm having a hard time updating :( ).

Now that I look at the implementation though,
it is not very well designed, just a very quick
work-around (dare I say hack). I'll post the
patch and you can decide if you want to accept
it as it stands, implement it more robustly and
efficiently, or just not bother to address the
issue (for the reasons explained below).

> [wsimpson - Wed Feb 06 16:09:50 2008]:
> Somebody had sent me private email bragging about his/her
> DoS against some
> game server, and telling me this was needed.  I didn't
> bother to reply.
> Anyway, per host blocking will adversely affect NATs and VPNs.

We allow a default value of 4 connections with the
same address, in our experience this has been
sufficient for all the players that happen to play
from the same host. In any case, it is a settable
option, hence under special circumstances it could
be increased to allow for more connections from the
same address.

>  The real
> DoS problem is TCB saturation -- that this won't fix.
> For security, the correct method is to exchange cookies
> between endpoints,
> and rate limit the exchange(s).  As we proved in Photuris,
> and multiple
> papers for *BSD....  The DoS limit is how fast you can
> refuse and close
> connections, not some arbitrary number of concurrent
> connections per game.

Yes, a maxconnectionsperhost option is no solution
for a DoS attack that simply saturates connection
requests at the transport level. Unfortunately I
don't see how a truly determined individual can be
prevented from doing this (short of the server
operator noticing it and blocking all of the sources
using iptables or similar).

> Therefore, I oppose such an option.  The only sensible
> number will be the
> same as the number of players.  It's such a small number
> already (30) that it won't make any difference.

Actually MAX_NUM_CONNECTIONS is arbitrarily defined to be
64 (twice the sum of MAX_NUM_PLAYERS and MAX_NUM_BARBARIANS).
Keep in mind that although the player limit is 32, there
can be observer (or even just detached) connections (i.e.
users) to the server as well.

> I've been working on a complete replacement for
> login (PR#39957, etc.)

I agree that a cleaner login protocol is needed intstead
of the existing system. Just some random issues I can
think of off the top of my mind are:
- Rejected clients should clearly be able to see the
  reason why they were rejected.
- Authentication lookups and reverse DNS should not
  block the server (very annoying for players).
- Reconnecting with the same address, username and
  password should allow the user to disconnect (i.e.
  cut) their previous connection that has become
  unresponsive. This actually occurs fairly frequently
  in games; we usually have to pause the game and
  vote to cut the lagged connection before the
  reconnected user can retake their player. Of course
  perhaps there might be other, preferable solutions
  (e.g. an irc-like GHOST command).

Incidentally, how do IRC servers handle such a DoS
situation? Surely they have already implemented a
practical solution to these and related problems -
maybe it would be a good idea to take a peek at
their sources for ideas about how freeciv connection
handling could be improved.

Freeciv-dev mailing list

Reply via email to