Supposed, UA would provide libs (c, delphi, vb, perl etc) for this new
protocol the shock for all those 3rd party developers wouldn't be that big
if there'd be a change. They wouldn't be forced to learn the new
protocol-specifications which would obviously be a bit more complex than the
original protocol.
What about a solution like this ?
As far as know, there ain't another way for stopping the exploit. UDP is the
issue here as you already mentioned.
A way would be to completly block the rcon port and have 3rd party tool
perform the 'rcon-handshake'. If this gets supported by UA or Adminmod
(whatever), gameservers will slowly switch over to this, since no admin
really wants his server to be vulnerable.
When a certain quota has been reached (say, 50% of all HLDS now support the
new protocol), it would be possible to have this "hard-implement" it into
the HLDS. The switch-over would be rather gently this way. All 3rd party
developers would kindly be pushed to add support.
(Maybe HLDS could also provide both protocols, which both can be deactivated
if needed)
Jan
----- Original Message -----
From: "Alfred" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 24, 2003 9:07 PM
Subject: Re: [hlds_apps] preventing DDoS
> This would be the ideal solution to the problem (the rcon protocol under
> HL does this). The only problem is that it breaks every query program
> ever written.... Ahhh, the wonders of supporting legacy programs.
>
> Jan Kleinsorge wrote:
> > All this wouldn't be a problem if there'd some kind of validation of the
> > origin of the message. I think of some kind of handshake. An example:
> > The client performs an 'helloserver' and appends a random id-number to
it.
> > The server in turn will then send back a message with an own random id
to
> > the client ('helloclient')
> > The final step is, that the client has to respond with an id which is a
> > combination of both id's (XOR'ed .. whatever). The server compares this
with
> > it's own client/server-id.
> > If the server agrees, then it will send the previously requested
information
> > to the client.
> >
> > This way, there can't be any flood-attacks on a gameserver since the
> > clienthello-msg will only be a few bytes long. Problem is of course the
fact
> > that all this works through UDP. So there wouldn't be
> >
> >
> > Maybe this is a little contribution to this discussion.
> >
> >
> > Good luck
> >
> > Jan
> >
> > _______________________________________________
> > hlds_apps mailing list
> > [EMAIL PROTECTED]
> > http://list.valvesoftware.com/mailman/listinfo/hlds_apps
>
> _______________________________________________
> hlds_apps mailing list
> [EMAIL PROTECTED]
> http://list.valvesoftware.com/mailman/listinfo/hlds_apps
>
_______________________________________________
hlds_apps mailing list
[EMAIL PROTECTED]
http://list.valvesoftware.com/mailman/listinfo/hlds_apps
