To my understanding when a player queries the status of a KF2 server on the query port, the server sends a random string to the player. The player then has to send that random string back to the server. This effectively confirms that the player is real.
My request is to add an option to allow the logging of successful queries to the query port along with the players ip address. This will confirm the player is authentic and allow for the creation of a whitelist of ip addresses.
From the server admin point of view it becomes really simple. Read the logs and filter looking for successful entries. If a new successful authentication is found add it to the white list.
Speculation: I assume that there is already debug logging for testing so in theory for a developer it should be really easy to implement by changing the debug logging to normal logging.
Justification: The best current method of blocking these attacks is dropping all packets with a ttl greater than 129. This will only work for so long until one of the attackers figures out that a ttl of less than 129 works. This is just a matter of time. I am currently dropping 6GB of data or 230 000 000 packets every 24 hours with the current rules.
For those that don't know the problems associated with running a server: https://forums.tripwireinteractive....s-defense-with-the-help-of-firewalld.2337631/
My request is to add an option to allow the logging of successful queries to the query port along with the players ip address. This will confirm the player is authentic and allow for the creation of a whitelist of ip addresses.
From the server admin point of view it becomes really simple. Read the logs and filter looking for successful entries. If a new successful authentication is found add it to the white list.
Speculation: I assume that there is already debug logging for testing so in theory for a developer it should be really easy to implement by changing the debug logging to normal logging.
Justification: The best current method of blocking these attacks is dropping all packets with a ttl greater than 129. This will only work for so long until one of the attackers figures out that a ttl of less than 129 works. This is just a matter of time. I am currently dropping 6GB of data or 230 000 000 packets every 24 hours with the current rules.
For those that don't know the problems associated with running a server: https://forums.tripwireinteractive....s-defense-with-the-help-of-firewalld.2337631/
Last edited: