Un post algo más técnico para inaugurar el miércoles técnico (MT) que últimamente está esto muy filosófico (que tampoco está mal pero en la diversidad está la virtud).

Los cortafuegos Palo Alto (muy de moda últimamente, no entremos si mejores o peores, bla bla bla) permiten realizar pruebas sobre las reglas desde la línea de comando entrando por ssh. Esto permite probar sin necesidad de tener que generar tráfico real, lo cual viene muy bien para comprobar reglas, solventar incidencias, etc.

Sin embargo, es un poco coñazo por varias razones:

  • Tienes que escribir un chorizo directamente en la línea de comando cada vez
  • Si quieres repetir más adelante (por ejemplo, después de un commit) tienes que volver a escbirilo
  • Si quieres probar varias reglas, tienes que ir una a una

Lo ideal sería poder tener un fichero con las pruebas que quieres hacer, lanzarlo de golpe, ver los resultados, hacer cambios, añadir pruebas o lo que sea, y poder volver a lanzarlo. Y cuando se realicen cambios, poder comprobar como afectan a estas pruebas.

Para eso, os incluyo aquí este pequeño script en expect que permite tener en un fichero las pruebas a realizar, se conecta por ssh y automáticamente lanza las pruebas que haya definidas. Si tenéis clave ssh, mejor. Si no, podéis descomentar las líneas para introducir la contraseña.

Instrucciones sobre cómo usarlo las podéis ver en el propio script.

Espero que os sirva para algo a los que tengáis cortafuegos Palo Alto.

Happy testing!

Después de llevar ya más de 10 años en el mundo empresarial debo confesar que creo fervientemente que la magia existe. Y también los magos.

La magia se manifiesta en muchas ocasiones justo después de realizar alguna afirmación sobre una situación de seguridad. Creo que se entiende mejor con un ejemplo.

Alguien de seguridad dice que en cierto sistema hay una vulnerabilidad en el FTP que además es un servicio inseguro. Entonces aparece el mago con su «hechizo» y argumenta que «pero eso está a punto de migrarse». Con eso… se acaba todo. El hechizo ha tenido su efecto y consigue que nada se haga. Por supuesto, una año después todo sigue igual, el FTP, la vulnerabilidad y sigue «a punto de migrarse».

Así es la gestión de IT que tenemos. Mientras más gente haya presente más efectivo puede ser el hechizo. Como este de Wally, el «mago» de Dilbert.

1713.strip.zoom Pero bueno, este artículo no iba precisamente de esto, aunque está relacionado. Os quería hablar de un hechizo bastante común: el de los entornos.

En todas las organizaciones siempre hay diversos tipos de entornos: producción, pruebas, preproducción, desarrollo, integración, formación, etc.

El objetivo es disponer de entornos donde desarrollar, probar, romper, integrar, etc. las aplicaciones o nuevas funcionalidades que acabarán en el entorno de producción.

La idea en la mente del personal de IT es que el entorno de producción es estable y está expuesto a los usuarios (internos, de Internet, etc.) y que el resto de entornos están restringidos y son inaccesibles. Por lo tanto, si encuentras una vulnerabilidad o configuración no adecuada en un entorno que no es producción, normalmente no importa. El hechizo en este caso es «es que está en el entorno de [citar cualquier entorno que no es producción]«.

Lamentablemente, la realidad no siempre es como uno se la imagina. Y lo que te encuentras en muchos casos es la siguiente situación:

  • Varios entornos comparten redes y, en algunos casos, incluso sistemas.
  • Es posible acceder a muchos entornos de prueba, pre-producción, etc.
  • Los entornos de formación tienen usuarios/contraseñas predecibles.
  • En muchos entornos hay datos reales (a veces antiguos pero reales).
  • Las contraseñas, claves, scripts, etc. en el entorno de producción se replican en los otros entornos.

En definitiva, hay una tenue diferencia entre los entornos que, en muchos casos, desde el punto de vista de la seguridad equivale exclusivamente al nombre. Una intrusión en alguno de los entornos (aunque no sean producción) tendrá consecuencias similares. Es más, una vulnerabilidad en un entorno puede servir para afectar al entorno de producción.

A lo que quiero llegar con esto es que hay que evitar ser confundidos por la magia y analizar, realmente, hasta qué punto los entornos que no son producción se encuentran aislados y cuentan con medidas adecuadas de seguridad. Y que tan importante es aplicar dichas medidas a unos como a otros entornos. Tened mucho cuidado con ser hechizados.

¿Y vosotros? ¿Creéis en la magia? ¿Qué otros hechizos conocéis? ¿Cómo se gestionan los entornos en vuestra organización?