Проверяйте сетевые допущения воспроизводимо

Этот проект использует Ansible для генерации тестовых файлов BATS, проверяющих допущения безопасности о сетевой инфраструктуре. Тесты запускаются с probe-машин ("узлов-зондов"), на которые развернут Prober.

Этот инструмент предназначен для воспроизводимого автоматизированного тестирования собственных сетей. Он поддерживает несколько узлов-зондов, выполняющих тесты, каждый со своим представлением тестируемой сети — например, из внешней зоны, из внутренней зоны и из DMZ.

Использование Prober для сканирования сетей, на которые у вас нет разрешения, может быть незаконным.

Требования

На Ansible master, используемом для развертывания тестов на узлах-зондах:

• ansible (очевидно!)
• python*-netaddr (на GNU/Linux) / py*-netaddr (на FreeBSD)

На самих узлах-зондах:

• bash
• ssh
• nmap
• dig/kdig
• testssl
• и любые другие зависимости, устанавливаемые ролью Ansible.

На системе, где вы просматриваете результаты (файлы *.tap), возможно, стоит установить tappy. Результаты хранятся на каждом узле-зонде в локальных git-репозиториях (по умолчанию в /var/run/prober/results/, см. ниже параметры конфигурации), с коммитами, помеченными датой завершения каждого сканирования, для ведения истории и удобного сравнения.

Работа

Ansible используется для генерации тестов на узлах-зондах. Узлом-зондом может быть любой хост FreeBSD или GNU/Linux, если на него можно установить зависимости Prober. Он не обязательно должен быть выделен только для тестирования, но это рекомендуется — сканирование сети разумного размера займет часы, потребует много процессора и создаст значительный трафик.

Имеет смысл развернуть Prober на нескольких разных машинах, чтобы проверить, как ваша сеть выглядит с разных точек обзора (например: внутренняя сеть, DMZ, Интернет).

В тестовом каталоге на узлах-зондах создается скрипт run-tests.sh для упрощения запуска тестов. Тесты запускаются таким образом, чтобы одновременно выполнялось <simultaneous_tests_count> тестов — эта переменная является основным способом контроля того, сколько ресурсов использует сканирование и сколько пропускной способности ему требуется.

Затем результаты тестов сохраняются в локальном git-репозитории, с коммитами, помеченными датой завершения запуска (которая может отличаться от даты начала для некоторых длительных сканирований).

При работе с инфраструктурой, состоящей более чем из нескольких хостов, может иметь смысл использовать такой инструмент, как Mitogen, чтобы значительно ускорить генерацию тестов.

Быстрый старт

1. Подготовьте сервер Debian или FreeBSD для использования в качестве узла-зонда (назовем его prober.example.com), убедитесь, что у вас есть SSH-доступ к нему и возможность выполнять sudo.

2. Скопируйте пример инвентаризации как inventories/test/.

3. В этой инвентаризации test:

   1. отредактируйте group_vars/all.yml и установите zone_nameserver, zone_domains, address_blocks по своему усмотрению; предположим, вы добавили example.com как единственный домен для сканирования
   2. отредактируйте файл hosts, настроив ваш узел-зонд prober.example.com в разделе [prober-nodes]; скажем, вы установили в .

Теперь вы можете выполнить 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 или ).

Зоны

Зоны определяются в файлах ./data/<zone_name>.yml, где корневым ключом является строка "tested_zone_settings", которая затем содержит ключи:

• name: имя зоны, соответствующее имени файла (без расширения); например: "internal", "external", "dmz"
• default (опционально): настройки по умолчанию для всех хостов в этой зоне
• ключи-регулярные выражения (обязательно начинающиеся с символа "^"), соответствующие нескольким FQDN
• ключ для каждого FQDN, требующего явной конфигурации

Ключ default, каждый ключ-регулярное выражение и каждый доменный ключ, в свою очередь, могут содержать следующие ключи:

• resolve: должен ли хост разрешаться в соответствующий IP-адрес (bool true/false или строка "skip")
• ping: должен ли хост отвечать на ping (bool true/false или строка "skip")
• ports: список TCP и UDP портов, которые могут быть открыты (подключи "tcp" и "udp", каждый содержит массив целых чисел, определяющих разрешенные для открытия порты, или строку "skip"), и порты с поддержкой TLS для более глубокой проверки (подключ tls, содержащий словарь с номерами портов в качестве ключей и типом TLS-сервиса или словом "skip" в качестве значения) является сокращением для: Типы TLS-сервисов — это любые, поддерживаемые для опции , для HTTPS-теста (включая заголовки) или "" для общего TLS-теста. : TLS-тесты выполняются, если порт также не отмечен как открытый в ключе "".

Пример конфигурации можно посмотреть здесь.

Глобальные значения по умолчанию определены в probers.yml. Затем для каждого проверяемого хоста они объединяются (с помощью combine) с соответствующими настройками зоны по умолчанию, затем с ключами-регулярными выражениями, соответствующими данному hostname, и наконец с конкретными настройками хоста.

Это означает, что настройки конкретных хостов в данной зоне имеют приоритет над настройками из ключей, соответствующих регулярным выражениям, которые, в свою очередь, имеют приоритет над настройками зоны по умолчанию, которые, в свою очередь, имеют приоритет над глобальными настройками по умолчанию.

Ключ ports обрабатывается немного особым образом: если определенные порты перечислены где-то в цепочке наследования конфигурации, их невозможно исключить ниже по цепочке, можно только добавить дополнительные номера портов или полностью пропустить тесты для всех портов данного протокола ("skip").

Файлы зон выбираются на основе переменной tested_zone, установленной для каждого узла-зонда.

Тесты по IP vs. тесты по hostname

Некоторые тесты имеют смысл в контексте отдельных IP-адресов, независимо от того, сколько доменов/hostnames на них разрешается; например, проверка, открыты ли определенные порты. Допустим, a.example.com и b.example.com указывают на один и тот же IP-адрес. В конфигурации из примера выше это означает, что порты 8080/tcp и 8443/tcp должны быть открыты, а на порту 8443/tcp ожидается HTTPS.

Некоторые тесты имеют смысл в контексте комбинаций конкретного домена/hostname и IP-адреса; например, если TLS-сертификат, предоставленный для определенного доменного имени на определенном IP-адресе, является действительным.

Эти два типа тестов реализуются путем генерации двух отдельных списков целей:

• список по IP, где каждый элемент имеет вид:
  <ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)
  IP-адреса не должны повторяться в этом списке;
• список по hostname, где каждый элемент имеет вид:
  <ip-address> <hostname>
  IP-адреса могут повторяться в этом списке.

Затем некоторые тестовые файлы генерируются только для целей из первого списка (например, тестирование открытых портов), а некоторые — только для целей из второго списка (например, связанные с TLS).

Порты и тесты

Некоторые тесты не имеют смысла, если определенные порты не открыты. Тесты, связанные с TLS, генерируются для данного хоста, только если в данной зоне какие-либо соответствующие TCP-порты настроены как open.

По умолчанию, если какой-либо из общеизвестных портов с поддержкой TLS настроен как открытый в ключе ports.tcp, для них будут сгенерированы TLS-тесты. Список общеизвестных портов с поддержкой TLS определен в переменной default_host_settings.

FAQ

В целом, отличие Prober от многих других подобных инструментов или сервисов обычно сводится к некоторой комбинации следующих факторов:

• самостоятельное размещение, при котором узлы Prober можно развернуть в любом месте внутри или за пределами вашей инфраструктуры;
• ориентация на регулярные, воспроизводимые сканирования, проверяющие четко определенные, настраиваемые допущения;
• предоставление вам контроля над расписанием запусков тестов и доступа к необработанным результатам сканирования.

Чем это отличается от Shodan?

Shodan сканирует Интернет в поисках открытых систем. Prober сканирует вашу собственную инфраструктуру, чтобы проверить ваши предположения о ней, из сколь угодно многих точек обзора. Он ориентирован на воспроизводимость результатов с помощью четко определенных тестов и регулярных запланированных запусков и пытается предоставить логический результат "пройдено/не пройдено" для каждого из проверяемых допущений (с возможностью просмотра полных данных сканирования).

Чем это отличается от BitSight?

BitSight проверяет свои представления о разумных допущениях относительно вашей инфраструктуры, не давая вам контроля или информации о том, когда именно будет проводиться сканирование, а также не предоставляя необработанные данные сканирования. Prober проверяет ваши допущения о вашей инфраструктуре, делает это по вашему расписанию и предоставляет полные необработанные данные для просмотра.

Чем это отличается от Natlas?

Natlas, похоже, ближе к Shodan (сканирование для поиска открытых хостов, отображение результатов в ответ на запросы), но с возможностью самостоятельного размещения (и, следовательно, запуска агента Natlas в разных местах внутри и за пределами вашей инфраструктуры, как узлы Prober). Prober выполняет регулярные сканирования вашей инфраструктуры для проверки ваших собственных допущений о ней, выраженных в конфигурации.

Большие вопросы

• перейти на более мощную систему тестирования?
  • BATS имеет раздражающие ограничения, например: нет возможности выполнять условное тестирование ("если тест A не пройден, пропустить тест B" и т.д.)
  • отказаться от системы тестирования вообще?
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• Полное сканирование IPv6-блоков невозможно выполнить за тысячелетие
  • предоставить способ настройки эвристики выбора IP для сканирования (случайно, начать снизу с настроенным "шагом" и т.д.)?

Благодарности

Логотип основан на Увеличительном стекле от verry obito, ID; CC-By и Сети от Creative Stall, PK; CC-By через the Noun Project.