¿Es seguro comprometer la configuración del cliente OpenVPN con Git?

6

Me gustaría comprometer mi configuración de cliente OpenVPN para el control de versiones, en un repositorio que esté alojado de forma remota y accesible públicamente.

Esto revelaría el nombre de host y el puerto del servidor, así como las rutas de archivo a los archivos .crt y .key.

¿Debería preocuparme por revelar el nombre de host / puerto del servidor, o se consideraría seguridad a través de la oscuridad?

Más en general, ¿qué tan seguro / inseguro sería?

Una configuración de ejemplo confusa se vería así:

client
dev tun
proto udp4

remote my.example.net 1194
remote-cert-tls server
tls-auth /home/ivan/path/to/ta.key 1
cipher AES-256-CBC

ca /home/ivan/path/to/ca.crt
cert /home/ivan/path/to/myuser.crt
key /home/ivan/path/to/myuser.key

nobind
user nobody
group nogroup
persist-key
persist-tun
comp-lzo yes
auth-nocache

Actualización : Gracias por los comentarios. Los puntos sobre el contraste de "seguridad a través de la oscuridad" con la elección de no exponer más de lo necesario acerca de su sistema seguro fueron bien hechos.

Me di cuenta de que el contexto en el que estoy haciendo esto ofrece una manera fácil de excluir parte de la configuración del control de versiones mientras se confirma el resto. El repositorio de Git es para la configuración de mi sistema NixOS, por lo que puedo colocar las partes sensibles de mi configuración vpn en un archivo separado, que voy a gitignore, e interpolar su contenido en el archivo de configuración final que compone nix.

Entonces mi configuración.nix tendrá algo como:

services.openvpn = {
  servers.fooServer = {
    config = ''
      # The insensitive stuff inline, committed to Git
      client
      dev tun
      # etc...

      # The sensitive stuff slurped from a gitignore'd file
      ${builtins.readFile ./foo-server.private.conf}
    ''
  }
}
    
pregunta ivan 15.05.2018 - 13:56
fuente

3 respuestas

1

Me temo que no podemos concluir qué tan seguro / inseguro es porque no sabemos qué otros controles de seguridad ha implementado. En términos generales, la seguridad a través de la oscuridad como el único mecanismo de defensa es una mala práctica y debe evitarse en todo momento; sin embargo, además de otros controles de seguridad fundamentales, puede ser conveniente no publicar información innecesariamente.

Suponiendo que ha aplicado las prácticas de seguridad básicas (es decir, no hay contraseñas predeterminadas, no hay servicios abiertos no utilizados, middleware actualizado, etc.), diría que es seguro publicar su configuración ya que no hay nada que se esté debilitando. tu nivel de seguridad Tenga en cuenta que hacer pública esta configuración puede llevar a los usuarios con intenciones maliciosas a su servidor con mayor facilidad, por lo que el riesgo en que incurra al publicar su configuración depende de la forma en que su servidor esté configurado y mantenido actualmente de forma segura. Depende de usted si acepta o no ese riesgo ...

    
respondido por el Stef Heylen 15.05.2018 - 17:11
fuente
4

Evitar "seguridad a través de la oscuridad" no significa revelar información sobre su sistema solo porque es algo que una persona determinada puede descubrir de todos modos.

Además, supongo que te refieres al control de versiones alojado de forma remota, no solo el control de versiones en tu máquina de desarrollo?

Si el servidor de control de versiones remoto es de acceso público o más accesible para aquellos que necesitan conocer esta información, poner el archivo en el control de versiones no lo hace más seguro, así que supongo que si cree que sí, eso está cayendo víctima de la "seguridad a través de la oscuridad".

    
respondido por el user693473 15.05.2018 - 16:10
fuente
1

Si el fragmento de código anterior es todo lo que se publica (es decir, no se incluye ningún archivo clave), entonces la única información que está protegiendo es la ubicación del servicio OpenVPN y cómo conectarse a él, información que probablemente se pueda obtener de Un atacante mediante el escaneo y la observación. Esta información por sí sola no le otorga ningún acceso a un atacante (a menos que algo esté terriblemente mal configurado o sea vulnerable).

Dicho esto, revela cierta información sobre su entorno, que, dependiendo de su modelo de amenaza específico, puede ser indeseable.

    
respondido por el multithr3at3d 15.05.2018 - 16:28
fuente

Lea otras preguntas en las etiquetas