<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 [email protected] https://mail.gna.org/listinfo/freeciv-dev
