Zum Inhalt

Discovery

Auto-Discovery scannt das Kundennetz, erkennt Geräte über SNMP-sysOID/sysDescr und schlägt Profile vor.

Wie funktioniert Discovery

Vesana durchsucht das Kundennetzwerk in zwei Stufen, ohne dass du irgendwas manuell konfigurieren musst:

1. Netze erkennen (passiv)

Der Collector schaut alle paar Stunden nach welche Netze er überhaupt sieht: lokale Interfaces, Routing-Tabelle, der ARP-Cache + LLDP/CDP des Default-Gateways. Daraus entsteht die Liste der bekannten Subnets. Klick auf „Jetzt aktualisieren" stößt diesen Pull sofort an.

2. Geräte finden (aktiv)

„Alles scannen" macht einen nmap-Sweep über die ausgewählten Subnets. Jedes Gerät bekommt einen Ping + eine Port-Probe. Findet der Collector SNMP, fragt er sysOID/sysDescr und kann den Gerätetyp exakt benennen. Dauer und Netzwerk-Last zeigt dir das Modal vor dem Scan-Start.

Quellen-Tags pro Subnet

Jedes erkannte Subnet zeigt woher die Information kommt:

Tag Bedeutung
Interface / Route aus der Collector-VM selbst (lokale Netzwerk-Karten + Routing-Tabelle)
SNMP-Route / LLDP vom Switch/Gateway gemeldet
Manuell hat der Operator selbst eingetragen
Implizit ein Gerät existiert da, das Subnet wurde aber noch nie direkt beobachtet (typisch über Routen die der Collector nicht sieht)

Findet er nicht alle Netze?

Häufige Gründe: - SNMP-Community fehlt für den Gateway → in den Discovery-Einstellungen hinterlegen - LLDP ist auf dem Switch deaktiviert → entweder am Switch aktivieren oder Netz manuell hinzufügen - Route geht nicht über die Collector-VM → manuell als Subnet eintragen, dann kannst du es trotzdem scannen

Scan-Profile — technischer Vergleich

Drei aktive-Scan-Profile mit unterschiedlicher Aggressivität, Rate-Limit und Port-Liste. Werte sind im Quellcode in shared/schemas/__init__.py::ACTIVE_SCAN_PROFILES definiert. nmap-Flags (-T4, -sV --version-intensity 2, -O) sind im Collector hardcoded — die Profile unterscheiden sich nur in den unten gelisteten Parametern.

Was über alle Profile identisch ist

  • Phase 1 — Host-Discovery: ICMP-Echo + TCP-SYN auf 22, 80, 443, 445, 3389, 8080 + TCP-ACK auf 80, 443. Ein Host wird entdeckt sobald einer dieser Ports antwortet oder ICMP durchgeht.
  • Phase 3 — SNMP-Walk: Auf jeden in Phase 1 entdeckten Host wird sysOID/sysDescr abgefragt, sofern eine SNMP-Community in den Discovery-Einstellungen hinterlegt ist. Stealth klassifiziert SNMP-Geräte genauso präzise wie Aggressiv.
  • Reine SNMP-only / DNS-only / JetDirect-only-Geräte (kein Phase-1-Port + ICMP geblockt) werden in keinem Profil entdeckt — sie müssen manuell als Host angelegt werden.

Vergleichstabelle

Parameter Stealth Normal Aggressiv
Rate-Limit (pps) 50 200 1000
Inter-Probe-Jitter (ms) 50–150 (random) 0–50 0
ICMP-Echo Retries 1 2 3
Parallele /24-Subnets 1 (sequenziell) 4 16
Service-Ports -p 22, 80, 443, 3389 (SSH, HTTP, HTTPS, RDP) 22, 80, 443, 3306, 3389, 5432, 6379, 8080 (+ MySQL, PgSQL, Redis, AppServer) 21, 22, 23, 25, 53, 80, 110, 143, 161, 389, 443, 445, 465, 587, 636, 873, 993, 995, 3306, 3389, 5432, 6379, 8080, 9100 (+ FTP, Telnet, SMTP, DNS, POP3, IMAP, SNMP, LDAP, SMB, LDAPS, rsync, IMAPS, POP3S, JetDirect)
Welche Ports erscheinen als „offen" nur die 4 Stealth-Ports — andere Services sind verborgen 8 Ports — DBs sichtbar, Mail/SMB/Druck nicht 24 Ports — voller Service-Inventar pro Host
OS-Fingerprint-Qualität niedrig — wenige offene Ports = nmap rät mehr mittel hoch — mehr offene Ports = präziseres Matching
Dauer pro /24 ~25 s ~6 s ~2 s
Dauer /16 (256× /24) ~1h 50min ~25 min ~7 min
Bandbreiten-Spitze ~30 kbit/s ~120 kbit/s ~600 kbit/s
IDS-Sweep-Detection unter Standard-Threshold (Snort SCAN_PORT_SCAN ≈ ≥5/s) triggert Snort/Suricata mit Low-Threshold-Profilen triggert nahezu garantiert SOC-Alerts + EDR-Lateral-Movement-Detection
Type-To-Confirm nein nein "AGGRESSIV" (manuelle Bestätigung)

Wofür welches Profil

  • Stealth — Produktion mit aktivem SOC, Banken, Krankenhäuser, regulierte Umgebungen.
  • Normal — Office-Netze ohne hartes IDS, Standard-Kunden-Setup.
  • Aggressiv — Greenfield-Inventar, Lab, Wartungsfenster mit IDS-Whitelist, schnelle /16-Audits, „findet alles auf einen Schlag".

Voraussetzungen

  • Mindestens ein Collector im Kundennetz (Discovery wird vom Collector ausgeführt, nicht vom Server). Siehe Collector.
  • nmap auf dem Collector — wird beim Installer automatisch mit installiert
  • SNMP-Community oder SNMPv3-Credentials für die Zielgeräte

Workflow

flowchart LR
    UI[Discovery-UI] -->|Scan starten| API
    API --> Q[(Queue: collector_config)]
    C[Collector] -->|holt Scans| API
    C --> NMAP[nmap -sT/-sP]
    NMAP --> SNMP[SNMP sysOID/sysDescr]
    SNMP --> R[Result: IP, MAC, Profile-Vorschlag]
    R --> API
    API --> UI
    UI -->|Bulk-Add| API
    API --> H[Hosts angelegt]

Scan starten

Discovery → Neuer Scan:

Feld Beispiel
Name Acme HQ Subnet
Collector acme-collector-01
CIDR 192.168.10.0/24
SNMP-Community public
Timeout pro IP 5 s

Der Collector pollt alle ~60 s seine Konfiguration. Sobald der Scan-Auftrag eingetragen ist, startet er. Fortschritt sichtbar in /discovery.

Ergebnisse

Pro gefundene IP:

Feld Bedeutung
IP gefundene Adresse
MAC + Vendor aus ARP / nmap-Vendor-DB
Hostname aus reverse DNS oder SNMP sysName
sysOID für Profile-Match
sysDescr Klartext-Beschreibung
Vorgeschlagenes Profil Best Match aus profiles.sysoid_patterns
Bestehender Host? wenn IP bereits zugewiesen

Auto-Matching

Profile haben Patterns:

sysoid_patterns:
  - "^.1.3.6.1.4.1.8072.3.2.10"     # Net-SNMP / Linux
sysdescr_patterns:
  - "^Linux"

Beim Scan-Result vergleicht das Backend die sysOID gegen alle Pattern, bei Match wird das Profil vorgeschlagen. Mehrere Matches → der spezifischere gewinnt (längeres OID-Pattern).

Als Host hinzufügen

Pro Result:

  1. Häkchen setzen
  2. Profil bestätigen oder umstellen
  3. Optionale Felder ergänzen (Tenant, Tags)
  4. Host anlegen

Bei Bulk-Selection: Mehrere als Hosts hinzufügen öffnet einen Sammel-Dialog mit gemeinsamem Tenant + Tags.

Bestehende Hosts erscheinen mit „bereits angelegt" und sind nicht selektierbar — verhindert Duplikate.

Discovery-Lebenszyklus

stateDiagram-v2
    [*] --> Pending: Scan angelegt
    Pending --> Running: Collector holt Auftrag
    Running --> Done: Scan fertig
    Running --> Failed: Fehler (Timeout, kein nmap)
    Done --> [*]: Results in /results

discovery_scans und discovery_results sind in Migration 035 definiert. Auto-Cleanup älter als 30 Tage löscht Results.

Tipps

  • Subnetz-Größe: /24 ist gut, /16 dauert auf nmap mehrere Stunden — splitten
  • SNMP-Timeout auf 3–5 s lassen, sonst hängt der Scan an unerreichbaren Geräten
  • Re-Scan: regelmäßig wiederholen, neue Geräte fallen sofort auf
  • Discovery via Cron: POST /api/v1/discovery/network-scan lässt sich scripten

Discovery für Agent-fähige Hosts

Discovery erkennt zwar das Vorhandensein eines Linux/Windows-Servers (ICMP, SSH-Banner, SNMP wenn aktiv), kann aber keinen Agent installieren. Workflow: Host anlegen → Agent-Token erzeugen → Token auf der Maschine ausrollen.

Anschluss