¿Preocupaciones de seguridad de los servidores Hudson y Jenkins visibles públicamente?

6

El inicio de un amigo ha implementado una serie de servicios críticos para el negocio en un servidor Hudson / Jenkins ejecutado en un contenedor Tomcat. Este no es un proyecto de código abierto, de hecho, muchos aspectos de este proyecto son confidenciales. Jenkins se utiliza principalmente como un medio para ejecutar lotes & obteniendo resultados de esos lotes.

Hasta cierto punto, el sistema se ha bloqueado, por ejemplo, se ha instalado un complemento que está destinado a bloquear los ataques de adivinación de contraseñas de fuerza bruta. El sistema Jenkins se ha configurado para que lo único que pueda ver antes de iniciar sesión sea una pantalla de inicio de sesión, por lo que estos usuarios pueden volver a configurar o ejecutar cualquier cosa en el servidor Jenkins.

La pregunta: ¿Este sistema representa una amenaza de seguridad importante para la empresa? ¿Hemos tomado todas las medidas de seguridad relevantes y razonables?

Por ejemplo, es posible que algún tipo de vulnerabilidad aún desconocida en la pila se convierta en la base de un exploit, pero ¿qué tan preocupados deberíamos estar ante un riesgo que, en el mejor de los casos, no es cuantificable, en el peor de los casos solo teórico?

    
pregunta Rory Alsop 17.01.2012 - 13:06
fuente

4 respuestas

7

Debes tomar medidas como:

  • Un firewall para asegurarse de que solo los puertos que se necesitan para ser accesibles sean
  • Lista blanca en lugar de lista negra (es decir, denegar el acceso a todos y simplemente dar acceso a lo que realmente necesite acceso)
  • ¿Debería ser accesible desde internet? (Es una VPN tal vez suficiente)
  • ...

Y siempre puede haber un exploit, el problema con los exploits es que nunca se sabe cuándo alguien encontrará un agujero en su sistema. Y no puede evaluar qué tan preocupado debería estar a menos que eche un vistazo al código fuente y al diseño del servicio. Cuando ve que tiene una validación deficiente o un mal diseño, sabe que debe estar alarmado, si está bien diseñado, bien codificado y existe una validación decente, puede estar menos preocupado. Pero siempre existe la posibilidad de que suceda.

Su pregunta es bastante amplia por un lado y muy localizada por el otro.

    
respondido por el Lucas Kauffman 17.01.2012 - 13:18
fuente
5

Si no es posible mover Hudson / Jenkins a otro servidor, entonces usaré un proxy inverso para deshabilitar el acceso remoto a cualquier cosa que no sea Hudson (también agregar SSL).

Siempre existe la posibilidad de que haya errores en Tomcat en Hudson, etc. Solo puedes minimizar el impacto que pueden causar.

    
respondido por el Hubert Kario 17.01.2012 - 13:32
fuente
4

Hay un riesgo. Ese riesgo no está cuantificado (no sabemos, o en este momento, qué tan riesgoso es). Contra ese riesgo, no hay beneficio en dejarlo público. Por lo tanto, realmente no vale la pena evaluar el riesgo porque cualquiera que sea ese riesgo, la proporción es contra nada.

Como sé por otra pregunta que estaba viendo en EC2, use una zona de seguridad privada que solo permita el acceso desde las direcciones IP de su empresa privada. Si lo mantiene interno en lugar de en EC2, sugiero hacer esfuerzos similares para eliminar cualquier tráfico que no sea de su red esperada.

    
respondido por el Jeff Ferland 17.01.2012 - 14:19
fuente
1

En cuanto a su configuración, me pregunto si realmente necesita acceso desde fuera de la empresa. En caso afirmativo, ¿puede utilizar VPN, HTTPS, certificados, ... Para asegurar la comunicación de su cliente al servidor Jenkins?

Uno de tus comentarios realmente me concierne:

  

... estos usuarios pueden volver a configurar o ejecutar cualquier cosa en el servidor Jenkins.

¿Es necesario que los usuarios puedan hacer algo en ese servidor Jenkins (solo conceda permiso / acceso a lo que realmente se necesita y no a lo que podría ser necesario en un futuro imprevisible)? ¿Se puede reducir la autoridad para Jenkins / Tomcat (se ejecuta Jenkins con autoridad de nivel de servicio / raíz)? ¿Puede limitar a los usuarios para que sean espectadores solo cuando se conectan desde fuera de la empresa? ¿Qué tal proteger la red de su empresa de cualquier posible amenaza del servidor Jenkins (firewalls)? En otras palabras, trate el servidor Jenkins como si no fuera parte de la red de su empresa.

    
respondido por el Peter Schuetze 17.01.2012 - 19:30
fuente

Lea otras preguntas en las etiquetas