The problem is that each query program has a different design, so designing a library that would be useful for all would be nigh on impossible (especially considering all the little hacks you can do to speed up server queries). Some sample code on the other hand would be useful :)
As for running both protocols at the same time, doing this would be pretty difficult in the engine (as all traffic comes in through the same port). I would say the method used would have to be one or the other, not both at once.

Jan Kleinsorge wrote:
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
_______________________________________________
hlds_apps mailing list
[EMAIL PROTECTED]
http://list.valvesoftware.com/mailman/listinfo/hlds_apps

Reply via email to