¿Verificando la integridad del software del servidor?

Qué gran pregunta. Creo que esta es una de las cosas que divide a la industria de los juegos: ¿centraliza sus servidores para mantener el control sobre ellos, pero luego sufre la falta de flexibilidad para las necesidades de los jugadores y se le acusa de gobernar con puño de hierro? para la población de jugadores y correr el riesgo de servidores maliciosos o contaminados.

Se me ocurren tres pensamientos, ninguno es ideal, pero podría ser útil.

1. Anuncie las configuraciones a los clientes, esto no retrasará el compromiso importante del servidor, pero aumentará el esfuerzo requerido de la parte maliciosa.

2. Ir por el camino de la confianza y la reputación, y tener servidores de velocidad de juego, ya sea que crean que son honestos o no. Esto también tiene problemas, y el representante también se puede jugar, pero es otra opción.

3. Proporcione el software del servidor como un módulo que puede consultar (a la punkbuster y las propias comprobaciones de la válvula) y deshabilitar en inconsistencias. Una vez más, se ha demostrado una y otra vez que este tipo de cosas se romperán en algún momento, ya que alguien analiza el código para comprender qué respuesta enviar, y molestará a los propietarios de los servidores, pero también aumentará el esfuerzo requerido de parte maliciosa.

Parece altamente improbable que pueda confiar en las respuestas que obtiene directamente del servidor en el que no confía. Parece que necesitas un tercero para responder por ello. P.ej. encuentre una manera de hacer que un proveedor de servicios en la nube certifique que el operador ha cargado una imagen ISO determinada en algún hardware estándar y, posteriormente, solo se ha comunicado con él a través de un determinado puerto que está vinculado a una interfaz de configuración bien restringida. Me he preguntado antes si alguno de los proveedores de la nube hace eso ...

En principio, hay soluciones técnicas. Puede asegurarse de que todos sus servidores contengan un TPM y usar la certificación remota para que el servidor certifique a cada cliente que está ejecutando el software legítimo del servidor.

Sin embargo, en la práctica, existen importantes desafíos de ingeniería, que pueden hacer que este enfoque no sea tan realista o más costoso de lo que vale en su entorno. Por ejemplo, los clientes ahora necesitan tener una forma de obtener la lista maestra de qué versiones de software están autorizadas; los servidores deben programarse para usar el hardware TPM (que es un poco una operación especializada); es necesario diseñar esquemas para garantizar que la integridad del software del servidor no pueda verse comprometida después de la certificación; y otros retos. Todo esto suena como una molestia de ingeniería y administración de grandes proporciones.

Desafortunadamente, las capacidades de certificación remota de los TPM no se usan mucho en la actualidad, por lo que no puede aprovechar los esfuerzos y la experiencia de otros. Entonces, si quisieras adoptar este enfoque, estarías en la vanguardia. Suena como el tipo de cosa que haría que un administrador de programas ejecutara gritos.

Por lo tanto, es probable que no recomiende este enfoque a un pequeño proveedor de software independiente, aunque en principio sospecho que se podría hacer para proporcionar una seguridad razonablemente decente contra el tipo de amenaza que menciona (si tuviera recursos ilimitados) .