Administrar clúster de computadoras Linux detrás de firewalls


19

El producto de mi empresa es esencialmente una caja de Linux (Ubuntu) ubicada en la red de otra persona que ejecuta nuestro software. Hasta ahora teníamos menos de 25 cajas en la naturaleza y usamos TeamViewer para administrarlas.

Ahora estamos a punto de enviar 1000 de estas cajas y TeamViewer ya no es una opción. Mi trabajo es encontrar una forma de acceder a estos cuadros y actualizar el software en ellos . Esta solución debería poder atravesar firewalls y lo que tenga.

He considerado:

1. Solución local (por ejemplo, un servicio de Linux) que establece un túnel inverso SSH a un servidor en la nube y otro servicio en la nube que realiza un seguimiento de esos y le permite conectarse a ellos.

Obviamente, esto requiere mucha mano de obra y, francamente, se siente como reinventar la rueda, ya que muchas otras empresas ya deben haberse encontrado con este problema. Aun así, no estoy seguro de que haremos un gran trabajo.

2. Herramientas como títeres, chef o OpenVPN

Traté de leer lo más posible, pero parece que no puedo penetrar lo suficiente a través del discurso de marketing para comprender la elección obvia.

Nadie más, excepto nosotros, necesita conectarse a estas cajas. ¿Hay alguien con experiencia relevante que me pueda dar algunos consejos?


2
"No estamos a punto de la nave" => "Estamos ahora a punto de la nave"?
Bob

Respuestas:


23

Obtenga actualizaciones, no presione

A medida que escala, será inviable realizar actualizaciones automáticas para todos sus productos.

  • Tendrá que rastrear a cada cliente, que puede tener una configuración de firewall diferente.
  • Tendrá que crear conexiones entrantes a través del firewall del cliente, lo que requeriría el reenvío de puertos o algún otro mecanismo similar. Esto es un riesgo de seguridad para sus clientes.

En su lugar, haga que sus productos "actualicen" sus actualizaciones periódicamente, y luego puede agregar capacidad adicional en el lado del servidor a medida que crece.

¿Cómo?

Este problema ya se ha resuelto, como sugirió. Aquí hay varios enfoques en los que puedo pensar.

  • usando apt : use el sistema apt incorporado con un PPA personalizado y una lista de fuentes. ¿Cómo configuro un PPA?
    • Contras: a menos que use un servicio de alojamiento público como launchpad, configurar su propio sistema de empaque PPA + apto no es para los débiles de corazón.
  • usando ssh : genere una clave pública SSH para cada producto y luego agregue la clave de ese dispositivo a sus servidores de actualización. Luego, solo tiene su software rsync/ scplos archivos requeridos.
    • Con: tiene que rastrear (¡y hacer una copia de seguridad!) Todas las claves públicas para cada producto que envía.
    • Pro : más seguro que una descarga sin formato, ya que los únicos dispositivos que pueden acceder a las actualizaciones serían aquellos con la clave pública instalada.
  • descarga sin procesar + verificación de firma :

    • Publique un archivo de actualización firmado en alguna parte (Amazon S3, servidor FTP, etc.)
    • Su producto verifica periódicamente el cambio del archivo de actualización y luego descarga / verifica la firma.
    • Con : Dependiendo de cómo implemente esto, los archivos pueden ser accesibles públicamente (lo que puede hacer que su producto sea más fácil de realizar ingeniería inversa y piratear)
  • ansible : Ansible es una gran herramienta para administrar las configuraciones del sistema. Está en el ámbito de la marioneta / chef, pero no tiene agente (usa python) y está diseñado para ser idempotente. Si la implementación de su software requiere un script bash complicado, usaría una herramienta como esta para que sea menos complicado realizar sus actualizaciones.

Por supuesto, hay otras formas de hacer esto ... Pero me lleva a un punto importante.

¡Firma / valida tus actualizaciones!

No importa lo que haga, es imperativo que tenga un mecanismo para garantizar que su actualización no haya sido alterada. Un usuario malintencionado podría hacerse pasar por su servidor de actualizaciones en cualquiera de las configuraciones anteriores. Si no valida su actualización, su caja es mucho más fácil de hackear y entrar.

Una buena forma de hacerlo es firmar sus archivos de actualización. Tendrá que mantener un certificado (o pagarle a alguien para que lo haga), pero podrá instalar su huella digital en cada uno de sus dispositivos antes de enviarlos para que puedan rechazar las actualizaciones que han sido manipuladas.

Seguridad física

Por supuesto, si alguien tiene acceso físico a la implementación del cliente, fácilmente podría hacerse cargo del servidor. ¡Pero al menos no pueden atacar los otros despliegues! La seguridad física es probablemente la responsabilidad de su cliente.

Si quisiera por un momento, imagine lo que sucedería si usara una gran red OpenVPN para actualizaciones ... Luego podrían usar el servidor comprometido para atacar cada instancia en la VPN

Seguridad

Hagas lo que hagas, la seguridad debe incorporarse desde el principio. No cortes las esquinas aquí: si lo haces, te arrepentirás al final.

Asegurar completamente este sistema de actualización está fuera del alcance de esta publicación, y recomiendo contratar a un consultor si usted o alguien de su equipo no tiene conocimiento en esta área. Vale la pena cada centavo.


2
Secundaría el uso de Ansible: tiene una complejidad intermedia entre los scripts de shell y la gestión de configuración de estilo Puppet / Chef, y tiene la sofisticación para hacer cosas más complejas que simplemente actualizar el software (como se insinúa en la pregunta que dice " gestionar").
RichVel

Si sigue la ruta del uso de Ansible, puede escribirlo para que se ejecute en 'localhost', y no requerirá acceso SSH a ninguna de las máquinas que se administran. Configúralo para ser un cronjob, y eres dorado.
BobTuckerman

1
Por cierto: si desea ejecutar su propio servidor de paquetes, fpmy aptlyson dos excelentes herramientas que hacen que sea mucho más fácil construir y alojar sus propios paquetes. Acabo de pasar por este proceso recientemente, y fue bastante agradable.
BobTuckerman

10

¿Realmente necesitas acceder a ellos?

O simplemente actualizarlos? Debido a que puede hacer que se actualicen ellos mismos, de manera similar a cómo apt actualiza en sí mismo sin supervisión.

Si necesita iniciar sesión

¿Por qué no un demonio OpenSSH escuchando a través del reenvío de puertos? Cada cliente puede tener una clave separada para la seguridad y solo se conectaría cuando sea necesario.

Hasta sus clientes

También debe tener en cuenta lo que el cliente está dispuesto a aceptar. Es posible que no se sientan cómodos con ningún acceso remoto a su red, o solo se sientan cómodos con tecnologías / configuraciones específicas.


44
esta. con 1000 requisitos diferentes de clientes, al menos algunos no querrán una conexión abierta abierta permanente a sus oficinas. Lo ideal sería intentar que se actualicen ellos mismos si / as / cuando detectan que hay una nueva versión disponible (por ejemplo, desde un archivo en un bucket de AWS S3. Eso es lo que hacemos.)
Sirex

@Sirex: un inconveniente de usar un bucket S3 es que no hay una lista blanca de IP simple que el cliente pueda usar para bloquear ese servidor para que solo pueda alcanzar el bucket que contiene la actualización. Terminamos teniendo que configurar un servidor de actualización con una dirección IP pública estática para que los clientes pudieran usar filtros IP para controlar lo que ese servidor puede hablar. (AWS publica todos sus bloques de IP, por lo que teóricamente es posible configurar un filtro que permita el acceso solo a los recursos de AWS, pero que es demasiado amplio para este caso de uso)
Johnny

No tenemos las actualizaciones en S3, pero sí tenemos un archivo de texto que detalla cuál es la última versión, utilizada por la aplicación para proporcionar los mensajes de banner 'actualización disponible'. Los clientes pueden activar (en nuestro caso manualmente) la descarga de la última versión, en nuestro caso desde un servicio llamado fetchapp.
Sirex

9

Sugiero una herramienta de orquestación como Puppet o Salt .

Salt es una cola de mensajes y puede hacer una conexión saliente persistente desde su dispositivo a un servidor maestro. Puede usar esto para ejecutar comandos arbitrarios en los dispositivos ... como un apt-get.

La otra opción es Puppet, donde todavía tiene un servidor maestro y los clientes realizan conexiones salientes desde sus ubicaciones.

Utilizo ambas herramientas para un propósito similar en el que es posible que no tenga control administrativo del firewall.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.