Cómo proteger el servidor MySQL para el caso de robo de hardware

No veo cómo restringir las veces que un cliente puede iniciar sesión tiene mucha relevancia para el problema que intenta resolver. También está cerrando la puerta para ejecutar el servicio a través de Internet si alguna vez se expande más allá de su LAN.

Agregar un servidor de descanso simple proporcionaría una manera fácil de aplicar reglas de acceso abstractas a la aplicación (de hecho, me cuesta entender por qué diseñaría una solución contra hardware específico en lugar de al menos modelar el acceso alrededor de un modelo basado en la nube). , incluso si terminas implementándolo en tu propio hardware).

Las personas que son demasiado valiosas (especialmente en las pequeñas empresas de software) sobre su propiedad intelectual son un tema recurrente aquí y en otros lugares en Internet; socavando a sus clientes legítimos pero ignorando las amenazas reales del robo de propiedad intelectual. Si la pregunta es realmente acerca de la seguridad de los datos que se intercambian después de este apretón de manos bizantino, entonces debería hablar con alguien que entiende esto mucho mejor en lugar de publicar una pregunta en Internet sobre algo relacionado tangencialmente con el problema real. / p>

  

El cliente primero proporciona la clave y se conecta a la cuenta raíz

OMG, no.

Realmente me cuesta entender por qué en cualquier aplicación consideraría usar root como una cuenta de servicio, y mucho menos una en la que esté tan preocupado por la seguridad. MySQL tiene la facilidad de transferir permisos de manera muy granular junto con un mecanismo de separación de privilegios.

Cualquier control que aplique a través de iptables, procedimientos almacenados o dentro de la lógica de la aplicación de un servidor REST en el host se omite fácilmente si alguien tiene el control físico del dispositivo. El cifrado de disco resuelve esto. Supongo que su mención de notas post-it y portátiles significa que espera dar la frase de cifrado del disco a mucha gente. Eso es fácil de resolver: no le des a nadie la contraseña. Podría ir y comprar un producto caro como CyberArk AIM para servir la frase de contraseña a pedido, pero ¿por qué? Es trivial colocar la frase de contraseña en otro lugar y escribir un script de shell de 10 líneas para recuperar la frase de contraseña a través de SSH / Https (o incluso otra instancia de MySQL a la que se accede a través de un túnel) validando el host cifrado usando un certificado de par de llaves / cliente y aplicando su hora / ubicación reglas en el host del servidor de frase de contraseña. Y el servidor de frase de contraseña debe residir en una ubicación física diferente para abordar su modelo de amenaza establecido.

Si esto suena similar al modelo de su servidor FTP, entonces preste atención a la diferencia: el servidor de frase de contraseña está en otra parte y el método de autenticación entre el servidor mysql y el servidor de frase de contraseña es seguro. Si alguien puede robar el servidor mysql y una computadora portátil, puede robar el servidor FTP.

Sugerencia para su problema:

• Asegúrese de que la zona horaria esté configurada correctamente y que ejecute ntpdate/ntpd en su máquina para mantener la hora sincronizada.
• Aplique reglas de iptables basadas en la hora y el día.

iptables -A INPUT -m time --timestart 07:00 --timestop 19:00 --weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT

• Para obtener información sobre el soporte de GeoIP con Linux netfilter, consulte: enlace

En otra nota, te sugiero que habilites Google Authenticator (teléfono / notificaciones push) o Yubikey integrado con PAM, para lograr un esquema de autenticación multifactor.

Al tener una unidad de disco duro de texto claro en su servidor, alguien detectará qué secuencias de comandos se ejecutarán durante el inicio, y la solución de detección de hashing de su impresora se evitará en ningún momento.

Si un servidor es robado físicamente, a menudo se apaga. Si tiene encriptación de alta definición completa, que necesita una clave para ingresar cuando se inicia; nadie podrá arrancar tus saques; eso elimina el riesgo de que alguien extrapole cualquier formulario de datos allí. Habilitar el cifrado completo del disco, sería mi primera recomendación.

Creo que el modelo de tratamiento de su arquitectura cliente / servidor es inherentemente defectuoso; alguien podría robar una computadora portátil (o tener una ejecución remota de código sin tener que tomar físicamente una computadora portátil), extraer la clave y tener acceso de raíz a su base de datos MySQL; y también cualquier información allí (nombres de usuario, contraseña / hashes, datos del cliente, etc.).

Recomiendo un inicio de sesión basado en SSL, donde cada usuario tiene su propio par de certificados (aumenta la auditoría y la responsabilidad), y si cree que hay algún juego sucio; Puedes revocar el certificado. Los inicios de sesión SSL se pueden encontrar en enlace

Espero que esto ayude,