isnic/proberАвтоматизированный, воспроизводимый фреймворк для тестирования безопасности сети, использующий Ansible и BATS для проверки DNS, доступности хостов, открытых портов и конфигурации TLS из нескольких точек обзора.
Этот проект использует Ansible для генерации тестовых файлов BATS, проверяющих допущения безопасности о сетевой инфраструктуре. Тесты запускаются с probe-машин ("узлов-зондов"), на которые развернут Prober.
Этот инструмент предназначен для воспроизводимого автоматизированного тестирования собственных сетей. Он поддерживает несколько узлов-зондов, выполняющих тесты, каждый со своим представлением тестируемой сети — например, из внешней зоны, из внутренней зоны и из DMZ.
Использование Prober для сканирования сетей, на которые у вас нет разрешения, может быть незаконным.
На Ansible master, используемом для развертывания тестов на узлах-зондах:
ansible (очевидно!)python*-netaddr (на GNU/Linux) / py*-netaddr (на FreeBSD)На самих узлах-зондах:
bashsshnmapdig/kdigtestsslНа системе, где вы просматриваете результаты (файлы *.tap), возможно, стоит установить tappy. Результаты хранятся на каждом узле-зонде в локальных git-репозиториях (по умолчанию в /var/run/prober/results/, см. ниже параметры конфигурации), с коммитами, помеченными датой завершения каждого сканирования, для ведения истории и удобного сравнения.
Ansible используется для генерации тестов на узлах-зондах. Узлом-зондом может быть любой хост FreeBSD или GNU/Linux, если на него можно установить зависимости Prober. Он не обязательно должен быть выделен только для тестирования, но это рекомендуется — сканирование сети разумного размера займет часы, потребует много процессора и создаст значительный трафик.
Имеет смысл развернуть Prober на нескольких разных машинах, чтобы проверить, как ваша сеть выглядит с разных точек обзора (например: внутренняя сеть, DMZ, Интернет).
В тестовом каталоге на узлах-зондах создается скрипт run-tests.sh для упрощения запуска тестов. Тесты запускаются таким образом, чтобы одновременно выполнялось <simultaneous_tests_count> тестов — эта переменная является основным способом контроля того, сколько ресурсов использует сканирование и сколько пропускной способности ему требуется.
Затем результаты тестов сохраняются в локальном git-репозитории, с коммитами, помеченными датой завершения запуска (которая может отличаться от даты начала для некоторых длительных сканирований).
При работе с инфраструктурой, состоящей более чем из нескольких хостов, может иметь смысл использовать такой инструмент, как Mitogen, чтобы значительно ускорить генерацию тестов.
Подготовьте сервер Debian или FreeBSD для использования в качестве узла-зонда (назовем его prober.example.com), убедитесь, что у вас есть SSH-доступ к нему и возможность выполнять sudo.
Скопируйте пример инвентаризации как inventories/test/.
В этой инвентаризации test:
group_vars/all.yml и установите zone_nameserver, zone_domains, address_blocks по своему усмотрению; предположим, вы добавили example.com как единственный домен для сканированияhosts, настроив ваш узел-зонд prober.example.com в разделе [prober-nodes]; скажем, вы установили tested_zone в test.Скопируйте пример конфигурации зоны как data/<tested_zone>.yml (в нашем случае: data/test.yml) и отредактируйте его; как минимум, ключ tested_zone_settings.name должен содержать tested_zone (то есть test).
Экспортируйте вашу DNS-зону и сохраните как data/<dns_zone>.zone (в нашем случае: example.com).
Запустите плейбук:
ansible-playbook prober.yml -i inventories/test/ -vvv
Это сгенерирует тесты на узле-зонде и настроит задачу cron для их запуска каждую ночь в 01:00.
Теперь вы можете выполнить ssh на узел-зонд и просмотреть сгенерированные тесты в /opt/prober/. Когда вы будете удовлетворены, вы можете запустить их, выполнив: /opt/prober/run_tests.sh. Результаты будут сохранены в /var/run/prober/results.
Переменные конфигурации (определены в probers.yml):
tests_directory (по умолчанию: /opt/prober):
директория на узлах-зондах, куда генерируются тестовые файлы (файлы *.bats).
results_repo_directory (по умолчанию: /var/run/prober/results)
директория репозитория для результатов тестов (файлов *.tap); там инициализируется git-репозиторий и создается поддиректория tap/ для самих результатов; результаты коммитятся в git-репозиторий, коммиты помечаются датой в формате гггг-мм-дд (например, коммит с результатами теста, завершившегося 19 марта 2020 года, помечен как 2020-03-19).
simultaneous_tests_count (по умолчанию: 20):
сколько тестов выполняется одновременно.
prober_dev (по умолчанию: не определено):
пропускать некоторые задачи, не имеющие смысла на dev-машине (например, настройку cron или zabbix).
Зоны определяются в файлах ./data/<zone_name>.yml, где корневым ключом является строка "tested_zone_settings", которая затем содержит ключи:
name: имя зоны, соответствующее имени файла (без расширения); например: "internal", "external", "dmz"default (опционально): настройки по умолчанию для всех хостов в этой зоне^"), соответствующие нескольким FQDNКлюч default, каждый ключ-регулярное выражение и каждый доменный ключ, в свою очередь, могут содержать следующие ключи:
resolve: должен ли хост разрешаться в соответствующий IP-адрес (bool true/false или строка "skip")ping: должен ли хост отвечать на ping (bool true/false или строка "skip")ports: список TCP и UDP портов, которые могут быть открыты (подключи "tcp" и "udp", каждый содержит массив целых чисел, определяющих разрешенные для открытия порты, или строку "skip"), и порты с поддержкой TLS для более глубокой проверки (подключ tls, содержащий словарь с номерами портов в качестве ключей и типом TLS-сервиса или словом "skip" в качестве значения)ports: "skip" является сокращением для:
ports:
tcp: "skip"
udp: "skip"
tls: "skip"
testssl.sh для опции -t/--starttls, "https" для HTTPS-теста (включая заголовки) или "tls" для общего TLS-теста.tcp".skip: следует ли полностью пропустить хост (логическое значение)Пример конфигурации можно посмотреть здесь.
Глобальные значения по умолчанию определены в probers.yml. Затем для каждого проверяемого хоста они объединяются (с помощью combine) с соответствующими настройками зоны по умолчанию, затем с ключами-регулярными выражениями, соответствующими данному hostname, и наконец с конкретными настройками хоста.
Это означает, что настройки конкретных хостов в данной зоне имеют приоритет над настройками из ключей, соответствующих регулярным выражениям, которые, в свою очередь, имеют приоритет над настройками зоны по умолчанию, которые, в свою очередь, имеют приоритет над глобальными настройками по умолчанию.