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 DDoSThis 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 toit.The server in turn will then send back a message with an own random idtothe 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 thiswithit's own client/server-id. If the server agrees, then it will send the previously requestedinformationto 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 thefactthat 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
