Auf einem System, auf dem Sie die Ergebnisse (*.tap-Dateien) überprüfen, möchten Sie vielleicht tappy installieren. Die Ergebnisse werden auf jedem Prober-Knoten in lokalen Git-Repositories gespeichert (standardmäßig in /var/run/prober/results/, siehe unten für Konfigurationsoptionen), mit Commits, die mit dem Datum jedes abgeschlossenen Scan-Durchlaufs getaggt sind, für historische Aufzeichnung und einfachen Vergleich.

Betrieb

Ansible wird verwendet, um Tests auf Prober-Knoten zu generieren. Ein Prober-Knoten kann jeder FreeBSD- oder GNU/Linux-Host sein, solange es möglich ist, Probers Abhängigkeiten zu installieren. Er muss nicht dediziert für Tests sein, wird aber empfohlen — ein Scan eines vernünftig großen Netzwerks wird Stunden dauern, viel CPU verbrauchen und eine beträchtliche Menge an Datenverkehr erzeugen.

Es ist sinnvoll, Prober auf mehreren verschiedenen Maschinen bereitzustellen, um zu überprüfen, wie Ihr Netzwerk von verschiedenen Blickwinkeln aussieht (z.B. internes Netzwerk, DMZ, Internet).

Im Testverzeichnis auf den Prober-Knoten wird ein Skript run-tests.sh erstellt, um die Ausführung der Tests zu erleichtern. Die Tests werden so ausgeführt, dass zu jeder Zeit <simultaneous_tests_count> Tests gleichzeitig laufen — diese Variable ist die Hauptmethode, um zu steuern, wie viele Ressourcen ein Scan verwendet und wie viel Bandbreite er benötigt.

Testergebnisse werden dann in einem lokalen Git-Repository gespeichert, wobei Commits mit dem Datum getaggt sind, an dem ein bestimmter Durchlauf beendet wurde (welches sich vom Startdatum für einige lange Scan-Durchläufe unterscheiden kann).

Wenn Sie mit einer Infrastruktur umgehen, die größer als nur ein paar Hosts ist, kann es sinnvoll sein, ein Tool wie Mitogen zu verwenden, um die Testgenerierung drastisch zu beschleunigen.

Schnellstart

1. Bereiten Sie einen Debian- oder FreeBSD-Server zur Nutzung als Prober-Knoten vor (nennen wir ihn prober.example.com), stellen Sie sicher, dass Sie SSH-Zugriff darauf haben und sudo ausführen können.

2. Kopieren Sie das Beispiel-Inventar als inventories/test/.

3. In diesem test-Inventar:

   1. Bearbeiten Sie group_vars/all.yml und setzen Sie zone_nameserver, zone_domains, address_blocks nach Ihren Wünschen; nehmen wir an, Sie fügen example.com als einzige zu testende Domain hinzu.
   2. Bearbeiten Sie die Datei hosts und konfigurieren Sie Ihren Prober-Knoten prober.example.com im Abschnitt [prober-nodes]; sagen wir, Sie setzen tested_zone auf test.

4. Kopieren Sie die Beispiel-Zonenkonfiguration als data/<tested_zone>.yml (also in unserem Fall: data/test.yml) und bearbeiten Sie sie; mindestens muss der Schlüssel tested_zone_settings.name den Wert von tested_zone enthalten (also test).

5. Exportieren Sie Ihre DNS-Zone und speichern Sie sie als data/<dns_zone>.zone (in unserem Fall: example.com).

6. Führen Sie das Playbook aus:

   root@kitploit:~

   ansible-playbook prober.yml -i inventories/test/ -vvv
   

   Dadurch werden die Tests auf dem Prober-Knoten generiert und ein Cronjob eingerichtet, der sie jede Nacht um 01:00 Uhr ausführt.

Sie können sich jetzt per ssh in den Prober-Knoten einloggen und die generierten Tests in /opt/prober/ inspizieren. Sobald Sie zufrieden sind, können Sie sie durch Ausführen von /opt/prober/run_tests.sh starten. Die Ergebnisse werden in /var/run/prober/results gespeichert.

Konfiguration

Konfigurationsvariablen (definiert in probers.yml):

• tests_directory (Standard: /opt/prober):
  Verzeichnis auf den Prober-Knoten, in dem die Testdateien (*.bats-Dateien) generiert werden.

• results_repo_directory (Standard: /var/run/prober/results): Verzeichnis des Repositories für Testergebnisse (*.tap-Dateien); dort wird ein git-Repository initialisiert und ein Unterverzeichnis tap/ für die eigentlichen Ergebnisse erstellt; Ergebnisse werden in das git-Repository committed, Commits werden mit einem Datum im Format yyyy-mm-dd getaggt (der Commit mit Ergebnissen eines Tests, der am 19. März 2020 beendet wurde, ist beispielsweise als 2020-03-19 getaggt).

• simultaneous_tests_count (Standard: 20):
  Wie viele Tests gleichzeitig ausgeführt werden.

• prober_dev (Standard: nicht definiert):
  Überspringen bestimmter Aufgaben, die auf einem Entwicklungsrechner keinen Sinn ergeben (wie das Einrichten von cron oder zabbix).

Zonen

Zonen werden in Dateien ./data/<zone_name>.yml definiert, wobei der oberste Schlüssel die Zeichenkette "tested_zone_settings" ist, die dann folgende Schlüssel enthält:

• name: der Name der Zone, passend zum Dateinamen (ohne Erweiterung); z.B. "internal", "external", "dmz"
• default (optional): die Standardeinstellungen für alle Hosts in dieser Zone
• Regex-Schlüssel (müssen mit einem "^" Zeichen beginnen), die mehrere FQDNs abgleichen
• ein Schlüssel pro FQDN, der eine explizite Konfiguration benötigt

Der default-Schlüssel, jeder Regex-Schlüssel und jeder Domain-Schlüssel können wiederum diese Schlüssel enthalten:

• resolve: soll der Host zur relevanten IP-Adresse aufgelöst werden (bool true/false oder der String "skip")
• ping: soll der Host auf Ping antworten (bool true/false oder der String "skip")
• ports: Liste der TCP- und UDP-Ports, die offen sein dürfen (Unter-Schlüssel "tcp" und "udp", jeweils ein Array von Integern, die offene Ports definieren, oder der String "skip"), und TLS-fähige Ports für eine tiefere Inspektion (der tls-Unter-Schlüssel, der ein Dict mit Portnummern als Schlüsseln und dem Typ des TLS-Dienstes oder dem Wort "skip" als Wert enthält)
  ports: "skip" ist eine Abkürzung für:
  root@kitploit:~

  ports:
    tcp: "skip"
    udp: "skip"
    tls: "skip"
  

  TLS-Diensttypen sind alles, was testssl.sh für die Option -t/--starttls unterstützt, "https" für HTTPS-Test (einschließlich Header) oder "tls" für generischen TLS-Test.
  HINWEIS: TLS-Tests werden nicht ausgeführt, es sei denn, der Port ist auch im Schlüssel "tcp" als offen markiert.
• skip: ob der Host vollständig übersprungen werden soll (boolesch)

Eine Beispielkonfiguration finden Sie hier.

Globale Standardeinstellungen sind in probers.yml definiert. Für jeden getesteten Host werden diese dann mit den entsprechenden Zonenstandards kombiniert, dann mit Regex-Schlüsseln, die einen bestimmten Hostnamen abgleichen, und schließlich mit den spezifischen Host-Einstellungen.

Das bedeutet, dass spezifische Host-Einstellungen in einer bestimmten Zone Vorrang vor Einstellungen aus Regex-gematchten Schlüsseln haben, die wiederum Vorrang vor Zonenstandards haben, die wiederum Vorrang vor globalen Standardeinstellungen haben.

Der ports-Schlüssel wird etwas speziell behandelt: Wenn bestimmte Ports irgendwo in der Konfigurationsvererbungskette aufgeführt sind, ist es unmöglich, sie weiter unten in der Kette zu entfernen, sondern nur zusätzliche Portnummern hinzuzufügen oder Tests für alle Ports eines bestimmten Protokolls insgesamt zu "skip"en.

Zonendateien werden basierend auf der für jeden Prober-Knoten gesetzten Variable tested_zone ausgewählt.

Pro-IP-Tests vs. Pro-Hostname-Tests

Einige Tests sind im Kontext einzelner IP-Adressen sinnvoll, unabhängig davon, wie viele Domains/Hostnamen auf sie verweisen; zum Beispiel die Überprüfung, ob bestimmte Ports offen sind. Nehmen wir an, a.example.com und b.example.com zeigen auf dieselbe IP-Adresse. Mit der Konfiguration aus dem obigen Beispiel bedeutet das, dass sowohl die Ports 8080/tcp als auch 8443/tcp offen sein sollten und dass HTTPS auf Port 8443/tcp erwartet wird.

Einige Tests sind im Kontext bestimmter Domain-/Hostname- und IP-Adress-Kombinationen sinnvoll; zum Beispiel, ob das für einen bestimmten Domainnamen auf einer bestimmten IP-Adresse präsentierte TLS-Zertifikat gültig ist.

Diese beiden Testarten werden implementiert, indem zwei separate Listen von Zielen generiert werden:

• Pro-IP-Liste, bei der jedes Element die Form hat:
  <IP-Adresse> <Hostname1> (<Hostname2> <Hostname3> ... <HostnameN>)
  IP-Adressen sollten in dieser Liste nicht wiederholt werden;
• Pro-Hostname-Liste, bei der jedes Element die Form hat:
  <IP-Adresse> <Hostname>
  IP-Adressen können in dieser Liste wiederholt vorkommen.

Einige Testdateien werden dann nur für Ziele aus der ersten Liste generiert (z.B. Tests auf offene Ports), und einige nur für Ziele aus der zweiten Liste (z.B. TLS-bezogene Tests).

Ports und Tests

Einige Tests sind nicht sinnvoll, wenn bestimmte Ports nicht offen sind. TLS-bezogene Tests werden für einen bestimmten Host nur generiert, wenn in der gegebenen Zone relevante TCP-Ports als open konfiguriert sind.

Standardmäßig werden TLS-Tests für sie generiert, wenn einer der bekannten TLS-fähigen Ports im Schlüssel ports.tcp als offen konfiguriert ist. Die Liste der bekannten TLS-fähigen Ports ist in der Variable default_host_settings definiert.

FAQ

Im Allgemeinen läuft der Unterschied zwischen Prober und vielen anderen ähnlichen Tools oder Diensten auf eine Kombination von Folgendem hinaus:

• Eigenständig gehostet, wobei Prober-Knoten an jedem Ort innerhalb oder außerhalb Ihrer Infrastruktur bereitgestellt werden können;
• Fokus auf regelmäßige, reproduzierbare Scans, die gut definierte, konfigurierbare Annahmen überprüfen;
• Sie haben die Kontrolle über den Zeitplan der Testläufe und Zugriff auf die Rohdaten der Scans.

Wie unterscheidet sich dies von Shodan?

Shodan durchsucht das Internet, um exponierte Systeme zu finden. Prober durchsucht Ihre eigene Infrastruktur, um Ihre Annahmen darüber zu überprüfen, und zwar von so vielen Blickwinkeln wie nötig. Es konzentriert sich auf die Reproduzierbarkeit der Ergebnisse durch klar definierte Tests und regelmäßige, geplante Läufe und versucht, für jede der getesteten Annahmen ein boolesches „bestanden/nicht bestanden“-Ergebnis zu liefern (mit den vollständigen Scan-Ergebnisdaten zur Einsicht).

Wie unterscheidet sich dies von BitSight?

BitSight überprüft deren Vorstellung von angemessenen Annahmen über Ihre Infrastruktur, ohne Ihnen die Kontrolle oder Informationen darüber zu geben, wann genau ein Scan stattfindet, noch die Rohdaten der Scans bereitzustellen. Prober überprüft Ihre Annahmen über Ihre Infrastruktur, führt dies nach Ihrem Zeitplan durch und stellt vollständige Rohdaten der Scans zur Einsicht bereit.

Wie unterscheidet sich dies von Natlas?

Natlas scheint Shodan näher zu sein (Durchsuchen, um exponierte Hosts zu finden, Anzeige von Ergebnissen als Antwort auf Abfragen), aber mit der Möglichkeit, es selbst zu hosten (und somit den Natlas-Agenten auch an verschiedenen Orten innerhalb und außerhalb Ihrer Infrastruktur auszuführen, ähnlich wie Prober-Knoten). Prober führt regelmäßige Scans Ihrer Infrastruktur durch, um Ihre eigenen Annahmen darüber zu überprüfen, wie sie in der Konfiguration festgelegt sind.

Große Fragen

• Wechsel zu einem leistungsfähigeren Testsystem?
  • BATS hat ärgerliche Einschränkungen, zum Beispiel: Es gibt keine Möglichkeit für bedingte Tests („Wenn Test A fehlschlägt, überspringe Test B“ usw.)
  • Testsystem ganz weglassen?
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• IPv6-Vollblock-Scans sind innerhalb eines Jahrtausends unmöglich abzuschließen
  • einen Weg bereitstellen, die Heuristik der Auswahl der zu scannenden IPs zu konfigurieren (zufällig, von unten beginnen mit einem konfigurierten „Schritt“ usw.)?

Danksagungen

Logo basierend auf Vergrößerungsglas von verry obito, ID; CC-By und Netzwerk von Creative Stall, PK; CC-By, über the Noun Project.