isnic/proberMarco de pruebas automatizado y reproducible de seguridad de redes usando Ansible y BATS para verificar DNS, disponibilidad de hosts, puertos abiertos y configuración TLS desde múltiples puntos de vista.
Este proyecto utiliza Ansible para generar archivos de prueba BATS que verifican supuestos de seguridad sobre la infraestructura de red. Las pruebas se ejecutan desde máquinas de prueba ("nodos prober") en las que se despliega Prober.
Esta herramienta está diseñada para pruebas automatizadas y reproducibles de redes propias. Admite múltiples nodos prober ejecutando pruebas, cada uno con una vista diferente de la red sondada — por ejemplo, una vista desde la zona externa, desde una zona interna, y una vista desde dentro de la DMZ.
Usar Prober para sondear redes para las que no estás autorizado podría ser ilegal.
En el maestro de Ansible utilizado para desplegar pruebas a los nodos prober:
ansible (¡obvio!)python*-netaddr (en GNU/Linux) / py*-netaddr (en FreeBSD)En los propios nodos prober:
bashsshnmapdig/kdigEn un sistema donde revises los resultados (archivos *.tap), quizás quieras instalar tappy. Los resultados se mantienen en cada nodo prober, en repositorios git locales (por defecto, en /var/run/prober/results/, ver más abajo las opciones de configuración), con commits etiquetados con la fecha de finalización de cada ejecución de escaneo, para registro histórico y fácil comparación.
Se utiliza Ansible para generar pruebas en los nodos prober. Un nodo prober puede ser cualquier host FreeBSD o GNU/Linux, siempre que sea posible instalar las dependencias de Prober. No necesita estar dedicado a pruebas, pero se recomienda — un escaneo de una red de tamaño razonable tomará horas, usará mucha CPU y generará bastante tráfico.
Tiene sentido desplegar Prober en varias máquinas diferentes para comprobar cómo se ve tu red desde distintos puntos de observación (por ejemplo: red interna, DMZ, Internet).
En el directorio de pruebas en los nodos prober se crea un script run-tests.sh para facilitar la ejecución de las pruebas. Las pruebas se ejecutan de manera que se asegure que <simultaneous_tests_count> pruebas se estén ejecutando simultáneamente en todo momento — esta variable es la forma principal de controlar cuántos recursos usa un escaneo y cuánto ancho de banda necesita.
Los resultados de las pruebas se guardan luego en un repositorio git local, con commits etiquetados con la fecha en que finalizó una ejecución determinada (que puede ser diferente de la fecha de inicio para algunas ejecuciones largas de escaneo).
Si se trata de una infraestructura más grande que solo unos pocos hosts, puede tener sentido usar una herramienta como Mitogen para acelerar drásticamente la generación de pruebas.
Prepara un servidor Debian o FreeBSD para usarlo como nodo prober (llamémoslo prober.example.com), asegúrate de tener acceso SSH a él y poder hacer sudo en él.
Copia el inventario de ejemplo como inventories/test/.
En ese inventario test:
group_vars/all.yml y establece zone_nameserver, zone_domains, address_blocks a tu gusto; supongamos que agregas example.com como el único dominio a sondear.hosts, configurando tu nodo prober prober.example.com en la sección [prober-nodes]; digamos que estableces tested_zone como test.Copia la configuración de zona de ejemplo como data/<tested_zone>.yml (por lo tanto, en nuestro caso: data/test.yml) y edítala; como mínimo, la clave tested_zone_settings.name debe contener el tested_zone (es decir, test).
Exporta tu zona DNS y guárdala como data/<dns_zone>.zone (en nuestro caso: example.com).
Ejecuta el playbook:
ansible-playbook prober.yml -i inventories/test/ -vvv
Esto generará las pruebas en el nodo prober y configurará un cronjob para ejecutarlas cada noche a la 01:00 AM
Ahora puedes hacer ssh al nodo prober e inspeccionar las pruebas generadas en /opt/prober/. Una vez que estés satisfecho, puedes ejecutarlas con: /opt/prober/run_tests.sh. Los resultados se guardarán en /var/run/prober/results.
Variables de configuración (definidas en probers.yml):
tests_directory (por defecto: /opt/prober):
directorio en los nodos prober donde se generan los archivos de prueba (archivos *.bats).
results_repo_directory (por defecto: /var/run/prober/results):
directorio del repositorio para los resultados de las pruebas (archivos *.tap); allí se inicializa un repositorio git y se crea un subdirectorio tap/ para los resultados reales;
los resultados se confirman en el repositorio git, los commits se etiquetan con una fecha
en formato yyyy-mm-dd (el commit con los resultados de una prueba que finalizó el 19 de marzo de 2020
se etiqueta como 2020-03-19, por ejemplo).
simultaneous_tests_count (por defecto: 20):
cuántas pruebas se ejecutan simultáneamente.
prober_dev (por defecto: sin definir):
omite ciertas tareas que no tienen sentido en una máquina de desarrollo
(como configurar cron o zabbix).
Las zonas se definen en archivos ./data/<nombre_de_zona>.yml con la clave principal siendo la cadena "tested_zone_settings", que a su vez contiene las claves:
name: el nombre de la zona, que coincide con el nombre del archivo (sin extensión); por ejemplo: "internal", "external", "dmz"default (opcional): la configuración predeterminada para todos los hosts en esta zona^") que coinciden con múltiples FQDNLa clave default, cada clave de expresión regular y cada clave de dominio a su vez pueden contener estas claves:
resolve: si el host debe resolver a la dirección IP relevante (booleano true/false, o la cadena "skip")ping: si el host debe responder a ping (booleano true/false, o la cadena "skip")ports: lista de puertos TCP y UDP permitidos para estar abiertos (subclaves "tcp" y "udp", cada una contiene un array de enteros que definen los puertos permitidos, o la cadena "skip"), y puertos con TLS habilitado para hacer una inspección más profunda (la subclave tls, que contiene un dict con números de puerto como claves y el tipo de servicio TLS o la palabra "skip" como valor)ports: "skip" es una abreviatura de:
ports:
tcp: "skip"
udp: "skip"
tls: "skip"
testssl.sh soporta para la opción -t/--starttls, "https" para prueba HTTPS (incluyendo cabeceras), o "tls" para prueba TLS genérica."tcp".skip: si el host debe omitirse por completo (booleano)Puedes ver la configuración de ejemplo aquí.
Los valores predeterminados globales se definen en probers.yml. Para cada host sondado, estos se combinen con los valores predeterminados de la zona relevante, luego con las claves de expresión regular que coinciden con un nombre de host dado, y finalmente con la configuración específica del host.
Esto significa que la configuración de hosts específicos en una zona determinada tiene prioridad sobre la configuración de las claves de expresión regular, que a su vez tienen prioridad sobre los valores predeterminados de la zona, que a su vez tienen prioridad sobre los valores predeterminados globales.
La clave ports se trata de manera especial: si ciertos puertos están listados en algún lugar de la cadena de herencia de configuración, es imposible eliminarlos más abajo en la cadena, solo se pueden agregar números de puerto adicionales, o usar "skip" para omitir las pruebas de todos los puertos de un protocolo dado por completo.
Los archivos de zona se seleccionan según la variable tested_zone establecida para cada nodo prober.
Algunas pruebas tienen sentido en el contexto de direcciones IP individuales, independientemente de cuántos dominios/nombres de host resuelvan a ellas; por ejemplo, verificar si ciertos puertos están abiertos. Por ejemplo, supongamos que a.example.com y b.example.com apuntan a la misma dirección IP. Con la configuración del ejemplo anterior, eso significa que los puertos 8080/tcp y 8443/tcp deben estar abiertos, y que se espera HTTPS en el puerto 8443/tcp.
Algunas pruebas tienen sentido en el contexto de combinaciones particulares de dominio/nombre de host y dirección IP; por ejemplo, si el certificado TLS presentado para un nombre de dominio particular en una dirección IP particular es válido.
Estos dos tipos de pruebas se implementan generando dos listas separadas de objetivos:
<dirección-ip> <nombrehost1> (<nombrehost2> <nombrehost3> ... <nombrehostN>)<dirección-ip> <nombrehost>Algunos archivos de prueba se generan solo para objetivos de la primera lista (por ejemplo, pruebas de puertos abiertos), y otros solo para objetivos de la segunda lista (por ejemplo, relacionadas con TLS).
Algunas pruebas no tienen sentido si ciertos puertos no están abiertos. Las pruebas relacionadas con TLS se generan para un host determinado solo si algún puerto TCP relevante está configurado como open en la zona dada.
Por defecto, si alguno de los puertos conocidos habilitados para TLS está configurado como abierto en la clave ports.tcp, se generarán pruebas TLS para ellos. La lista de puertos conocidos habilitados para TLS está definida en la variable default_host_settings.
En general, la diferencia entre Prober y muchas otras herramientas o servicios similares suele resumirse en alguna combinación de:
Shodan rastrea Internet para encontrar sistemas expuestos. Prober rastrea tu propia infraestructura para verificar tus supuestos sobre ella, desde tantos puntos de observación como necesites. Se centra en la reproducibilidad de los resultados mediante pruebas bien definidas y ejecuciones regulares programadas, e intenta entregar un resultado booleano "pasa/falla" para cada uno de los supuestos probados (con los datos completos del escaneo disponibles para inspección).
BitSight verifica su idea de supuestos razonables sobre tu infraestructura, sin darte control ni información sobre cuándo exactamente se realizará un escaneo, ni proporcionar los datos de escaneo sin procesar. Prober verifica tus supuestos sobre tu infraestructura, lo hace en tu cronograma y proporciona todos los datos de escaneo sin procesar para su inspección.
Natlas parece estar más cerca de Shodan (rastrear para encontrar hosts expuestos, mostrar resultados en respuesta a consultas), pero con la capacidad de auto-alojarse (y por lo tanto también de ejecutar el Agente Natlas en diferentes ubicaciones dentro y fuera de tu infraestructura, como los nodos Prober). Prober ejecuta escaneos regulares de tu infraestructura para verificar tus propios supuestos sobre ella, tal como se expresan en la configuración.
Logotipo basado en Lupa por verry obito, ID; CC-By y Red por Creative Stall, PK; CC-By, vía the Noun Project.