Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Datenquellen und Input-Agenten

Die eigentlichen Datenquellen, also die Portscan-Werkzeuge, sind zunächst unabhängig von den Input-Agenten zu konfigurieren. Beispielsweise könnte auf einer Linux-Maschine das Werkzeug »nmap« per Cronjob automatisiert einmal pro Tag wie folgt aufgerufen werden, um alle Ports eines Netzbereichs zu scannen, der einem herkömmlichen Class-B-Netz entspricht:

/usr/bin/nmap -v -v -oG - -p 1-65535 10.1.0.0/16 > /tmp/nmap-results.txt

Jeder Datenquelle ist ein Input-Agent zugeordnet; seine Hauptaufgabe ist das Erzeugen einer Liste aller IP-Adressen- und Port-Paare, die von der Datenquelle als offen erkannt wurden. Er liest die Ausgabe des Scan-Werkzeugs und parst sie. Der obige Nmap-Aufruf würde beispielsweise bei einem Webserver folgende Textausgabe liefern:

Host: 10.1.123.123 (www.example.com)  Ports: 80/open/tcp//http///, 443/open/tcp//https///      Ignored State: filtered

Das Ergebnis des Input-Agents – eine einfache Textdatei mit einer IP-Adresse, einem Port sowie der Protokollangabe und optional einem Zeitstempel pro Zeile – wird anschließend entweder zur Abholung durch den Delta-Reporter hinterlegt oder im Push-Verfahren, etwa per »scp« , auf eine andere Maschine übertragen. Dieser Zwischenschritt ist oft deshalb notwendig, weil die von Dr. Portscan in der Default-Konfiguration verwendete SQLite-Datenbank (ohne Zusatzsoftware wie cubeSQL) gar nicht über das Netz erreichbar ist und auch andere Datenbanken häufig per Firewall gegenüber Zugriffen aus dem Internet abgeschottet werden, sodass kein direktes Eintragen der Ergebnisse in die zentrale Datenbank möglich wäre.

Delta-Reporter, Output-Agenten und Reports

Zunächst überträgt der Delta-Reporter die von den Input-Agenten gelieferten Portscan-Ergebnisse in die zentrale Datenbank. Dabei überprüft er für jedes IP-Adress- und Port-Paar unter Berücksichtigung des Layer-4-Protokolls, ob zum entsprechenden Scanner bereits ein Eintrag vorliegt oder neu erzeugt werden muss. Bei Aktualisierung vorhandener Einträge wird der Veränderungstyp entsprechend gesetzt.

Nach Abschluss des Imports aller Portscan-Ergebnisse kann der Output-Agent den zentralen Datenbestand auswerten. Da primär Veränderungen gegenüber dem bisherigen Zustand interessant sind, suchen Output-Agenten in der Regel nur nach Datenbank-Einträgen mit passendem Veränderungstyp. Um zu verhindern, dass ein Output-Agent mehrfach dasselbe Ereignis bearbeitet, trägt dieser seinen Identifikator in eine entsprechende Spalte der Datenbanktabelle ein.

Anzahl und Art der verwendeten Output-Agenten sind beliebig an den eigenen Bedarf anpassbar. Dr. Portscan bietet einen vorgefertigten Output-Agenten, der dem Administrator einen Gesamtüberblick über alle Veränderungen seit dem letzten Bericht liefert. Die Auswertung durch die Output-Agenten lässt sich aber auch gezielt einschränken. So ist es denkbar nur Ereignisse bestimmter Subnetze zu betrachten, um gezielt dafür zuständige Server- oder Netzverantwortliche zu informieren, oder nur ausgewählte Ereignisse, zum Beispiel neu geöffnete Ports, um diese einem definierten Soll-Zustand gegenüberzustellen. Um generell Mehrfachmeldungen und Fehlalarme zu vermeiden, empfiehlt sich das folgende Vorgehen:

  • Ports werden erst als offen oder geschlossen gemeldet, wenn frei konfigurierbare, Scanner-spezifische Schwellenwerte überschritten werden. Diese Schwellenwerte tragen zu einer Stabilisierung des Portscans bei und vermeiden Falschmeldungen. Denn es kommt immer wieder vor, dass ein gescanntes System just zum Zeitpunkt des Scans temporär nicht erreichbar ist oder dass bei Scans aus dem Internet bei aggressiveren Timing-Werte der Portscan-Tools nicht immer alle offenen Ports zuverlässig erkannt werden.
  • Bei jeder Meldung wird geprüft, ob sie bereits durch andere Output-Agenten mit derselben Report-Zielgruppe beziehungsweise vom selben Output-Agenten aufgrund der Ergebnisse eines anderen Scanners berichtet wurden. In diesem Fall kann die erneute Meldung gänzlich unterdrückt oder explizit als Bestätigung eines bereits bekannten Sachverhalts gekennzeichnet werden.
  • Diskrepanzen zwischen den Ergebnissen verschiedener Scanner sind im Regelfall legitim und können etwa durch unterschiedlichen Scanzeitpunkt, Scanumfang oder Scannerstandort verursacht werden. Diese unterschiedlichen Sichten auf dasselbe System gilt es im Report geeignet aufzubereiten, zum Beipsiel indem pro Berichtspunkt die aktuell vorliegenden Ergebnisse der unterschiedlichen Scanner aufgeführt werden. In der Konfiguration wird jeder Scanner einer Gruppe zugeordnet, innerhalb derer alle Sensoren dieselbe Sicht haben sollten, um Inkonsistenzen erkennen zu können.

Durch Veränderungen der Scanner-Infrastruktur kann es von Zeit zu Zeit notwendig werden, den gespeicherten Datenbestand zu bereinigen. In Dr. Portscan enthaltene und optional zu verwendende Skripte löschen beispielsweise Einträge mit sehr alten Zeitstempeln, eines bestimmten Scanners, (wenn dieser außer Betrieb genommen wurde), alle Einträge in einem bestimmten Netzbereich oder alle Einträge zu einer IP-Adresse, (zum Beispiel wenn im eine Maschine durch eine andere mit derselben IP-Adresse ersetzt wird).

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022