[crossfire] new metaserver

Fri May 27 10:16:15 CDT 2005

MM this doesn't look like what i had in mind during irc chat. Here is my 
analysis of problem (no implementation done yet):

Problem:
 Metaserver currently down
Reason:
 DOS attack (polluted server list?)
Solution: Revise protocol

Things to care about:
 - DOS resistance and prevent list pollution
 - Redundancy to avoid downtime and easiness of redundant node creation
 - Reliability of data
 - redundant node should be able to be hosted on any web enabled isp (no 
active script)

Analysis of current metaserver behavior:

Currently, when a public server starts, it registers to the metaserver, using 
a simple protocol. It provides a server address, a description and a name. 
After, it updates the metaserver on a regular basis to inform it about 
current number of players. The metaserver keep track of servers for about one 
day. This protocol is subjet to several limitations:
- Somebody could register lots of fake servers (DOS) resulting in client 
having to download a huge list of servers.
- Somebody could register a server, faking another server, to gather 
passwords.
- If the server crash and re-register to metaserver, old entry is not deleted, 
resulting in pollution of list when a server is unstable.
- The informations from metaserver can not be trusted in any way.
- If metaserver crash, no client can see a list of servers
- udp/ip used for registering make it easy to do impersonate ips (attacker 
potentially untrackable)

The proposition i'll make to create a new handling for metaserver will address 
all those limitations.

Prevention of fake servers and list pollution, limitations on DOS:

The list of public servers is something quite static. Unless when used for 
testing purposes, if someone starts a public server this is for at least a 
few week. For this, i suggest the addition of server to the metaserver list 
be something needing manual metaserver admin intervention. The sourceforge 
bugtrack allows the creation of new named bugtrack lists. This is currently 
the case for RFE (request for enhancement). I suggest to create a new buglist 
named Server. This list will be used by server admins to request for the 
register of their server in the metaserver list. Metaserver admins would then 
check the validity of entry and process the registration. We could also 
perhaps configure this list to request user authentification by sourceforge.
The request must contain the servername, the server ip address or dns address 
(dynamic dns should be tolerated), the server admin email address, a server 
public description.

Redundancy:

The list of servers would be made available in a serverlist file, available on 
the metaserver root node. This list file will be downloaded on a regular 
basis by mirror nodes. The client could connect either to the root node, 
either to a mirror node to grab the list of public servers

Trust of metaserver datas.
Because of replication between nodes, there should be a way to ensure the list 
has not been tampered (preventing someone to fake a server). The client 
should have a list a public keys corresponding to the keys of metaserver root 
node admins. The server list must always  be signed by a root metaserver node 
admin, probably the one doing the manual update and client would check the 
signature of list before using it.

DOS resistance:
The client should be always shipped with an uptodate static list of 
metaservers and list of servers. If root metaserver node is down, meaning the 
list of metaservers can not be found, client use cached metaserver list to 
grab a mirror metaservers. If it can't connect to any metaserver, it uses the 
cached server list and diplay it to user.

Overall client process:
- get the metaserverlist from sf if possible and check signature. If anything 
fails, fallback to cached list. If cached list fail, fall back to static list
- connect to a random metaserver in lsit and process a GET for the url listed 
in the metaserver list. If this fail, or signature check fails, process to 
another metaserver.
- update cached metaserver list
- if all metaservers fails, process with cached server list and if it fails, 
process with the static server list.
- update cached server list
- for each server in list, eventually connect to it and grab it's current 
statistics (number of players, uptime, aso)

Replication process:
This is quite easy, each mirror node just has, on a regular basis, to download 
a specific file from root node and publish it. This could be done on any 
linux box with a wget <root node> followed by an ftp <isp url>, the box 
executing the mirroring script does not have to be the one serving the files. 
(ie i can run a script twice a day on my dsl connected linux box to publish 
the mirrored file to 

     http://users.skynet.be/tchize/server.list,

      i don not 
need my dsl linux box to be permanently connected (just twice a day).

Drawbacks:
metaserver does not keep anymore statical informations on server. Clients are 
supposed to gather such information themself (note this is a quite common 
behavior for first person shooter games)
process of adding a new public server is a bit slow (wait for admin approval 
and then replication)

Advantages:
DOS resistant
No single point of failure (isp's are quite difficult to DOS and even if all 
metaserver are under heavy load client can still rely on on cached datas)
Server list can be trusted.
Mirror can be put on most ISP (personal web spaces gracefully provided by 
provider)

Le Vendredi 27 Mai 2005 06:16, Brendan Lally a écrit :
>

     since the previous metaserver has shown itself to be unable to deal with an

     >

      attack, and since having a metaserver is a nice thing, I have over the last

     >

      few days been writing a distributed HTTP-based replacement. following a

     >

      design described on IRC by TechII and Tchize (among others).

     >

     >

     This system comprises of a series of metaservers and a metametaserver.

     >

     >

     The metaservers collect server information, and propagate it to the

     >

      metametaserver, and the metametaserver collates this and makes it available

     >

      to all the metaservers.

     >

     >

     The metametaserver is /only/ connected to by the metametaservers and can be

     >

      firewalled off from all but a small number of IP adresses. This will make

     >

      it hard to attack.

     >

     >

     The metaservers are vulnerable, but there are several (at least half a

     >

      dozen) and can be run on any webserver with php support (or even without,

     >

      I'll clarify below)

     >

     >

     As of now, the web-based scripts operate as they should, and most

     >

      show-stopper bugs appear to have been found.

     >

     >

     Metaservers can exist in two forms, what I call active and passive, active

     >

      webservers allow the game servers to add themselves, they require php.

     >

     >

     passive servers merely mirror the server list and metaserver list, any

     >

      webserver can support these.

     >

     >

     What is left is client and server support, plus maybe a few tweaks to

     >

      filelocking and bizzare character filtering.

     >

     >

     Before I start doing that though, I would like to be able to freeze the

     >

      server entry format. currently an entry looks like:

     >

     >

     cat2.dynu.ca 13327 1117165607 version 1023 1027 Crossfire Server

     >

      cat2 1.7.0CVS no description

     >

     >

     with two lines, the top line being the port, ip or hostname of the server,

     >

      (unix) time of the server entry and the protocol header.

     >

     >

     the second line contains information shown to the player, server name,

     >

      server version, and comment.

     >

     >

     The question is, are other fields needed, and if so what? (player maybe

     >

      could be one).

     >

     >

     the tracker item

     >

      http://sourceforge.net/tracker/index.php?func=detail&aid=1208250&group_id=1

     >

     3833&atid=313833 contains various files related to this.

     >

     >

     _______________________________________________

     >

     crossfire mailing list

     >

      crossfire at metalforge.org

     >

      http://mailman.metalforge.org/mailman/listinfo/crossfire

-- 
--
Tchize (David Delbecq)

     tchize at myrealbox.com

Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:

     http://wwwkeys.pgp.net/pgpnet/wwwkeys.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050527/1dd83250/attachment.pgp