Zum Inhalt

Discovery

Discovery scannt das Kundennetz über den Collector, erkennt Geräte anhand mehrerer Quellen (nmap, ARP, SNMP, mDNS, SSDP, LLDP, CDP, Routing) und schlägt Profile vor. Wer die gefundenen Geräte nicht von Hand anlegen will, lässt das Automatische Setup daraus Hosts mit Checks machen.

Seiten-Struktur

Fünf Tabs: Übersicht · Automatisch einrichten · Geräte · Scan-Historie · Einstellungen. Der „Geräte"-Tab trägt eine Zahl: alle bisher gefundenen Geräte — genau das, was der Reiter unter „Alle" auflistet. Der Header zeigt die Anzahl verbundener Collectors und einen Doku-Link; bei mehr als einem Tenant erscheint ein Tenant-Multiselect.

Auf einer frischen Installation zeigt die Seite statt „kein Collector eingerichtet" an, dass der Aktive Collector (in dieser Meldung noch unter seinem alten Namen „Check-Executor") gerade automatisch eingerichtet wird — üblicherweise 1–3 Minuten nach dem Einrichtungs-Assistenten. Scheitert das, steht der Fehler dort samt Link zur Admin-Seite.

Übersicht

KPIs

KPI Bedeutung
Netze erkannt Anzahl bekannter Subnets, plus „davon N aktiv beobachtet"
Geräte gesamt alle bisher gefundenen Geräte
Abdeckung behandelt ÷ gefunden, in % — darunter „alles behandelt" oder „N unbehandelt"
Neu in 7 Tagen neue Geräte der letzten Woche

Aktionen

  • „Geräte suchen (Scan)" (primär) — öffnet den Scan-Dialog. Deaktiviert, solange kein Collector online ist oder bereits ein Scan läuft.
  • Im Bereich Netze, direkt bei der Liste:
    • „Netze automatisch finden" — kein Geräte-Scan: Der Collector schaut nach, welche Netze er kennt (eigene Schnittstellen, Routing-Tabelle, ARP, SNMP am Gateway, an Layer-3-Switches und an bereits überwachten SNMP-Geräten). Am Ende steht das Ergebnis direkt am Knopf („Fertig — N neue Netze gefunden", „keine neuen Netze" oder der Fehlergrund). Braucht einen Online-Collector.
    • „Subnetz hinzufügen" — für Netze, die der Collector nicht selbst sieht (Collector, CIDR, optionales Label). Ein eingetragenes Netz erscheint sofort in der Liste; ein laufender Collector ist dafür nicht nötig, nur ein angelegter.

Die Netz-Suche läuft nicht von allein

„Netze automatisch finden" startet von selbst nur einmal, wenn sich ein Collector zum ersten Mal meldet (auch der Aktive Collector nach der Installation). Danach nur auf Klick oder vor einem geplanten Scan, wenn im Zeitplan „Subnetze vorher aktualisieren" angehakt ist. Bis v1.9.436 lief die Suche zusätzlich täglich von allein — ab v1.9.437 nicht mehr; bestehende Collectors lösen nach dem Update keine neue Suche aus.

Für den SNMP-Teil der Netz-Suche braucht es keine eigens gepflegte Community: Vesana probiert die am Collector gelernten Communities (erfolgreichste zuerst), dann die Zugangsdaten-Sets des Tenants (SNMP v2c), zuletzt public.

Unter den Netzen listet die Übersicht „Neue Geräte" der letzten 7 Tage mit denselben Aktionen wie im Geräte-Tab; „Behandelte zeigen" blendet auch schon hinzugefügte oder ignorierte ein.

Netze (Subnet-Liste)

Jede Zeile zeigt: Status-Icon, CIDR (mono), optionales Label, ggf. eine „ausgeschlossen"-Pille, Quell-Badges, einen Abdeckungsbalken (überwacht/gesamt, farbgestuft) und einen Blitz-Button „Dieses Subnet scannen". Ein Klick auf die Zeile öffnet den Subnetz-Drawer.

Filter: Collector-Dropdown, „Ausgeschlossene ein-/ausblenden", Suche über CIDR/Label.

Subnetz-Drawer

Zwei Reiter:

  • Details — Label vergeben, Quellen mit Konfidenz, Verlauf der Scans in diesem Netz, „Dieses Subnet jetzt scannen", „Subnet ausschließen" (mit optionalem Grund; bereits überwachte Hosts bleiben überwacht, nur weitere Discovery unterbleibt) und „Subnetz aus der Liste löschen". Löschen entfernt das Netz samt Quellen und Label aus der Erkennungs-Liste — Geräte und Hosts bleiben unberührt. Sieht der Collector das Netz weiterhin, taucht es bei der nächsten Netz-Suche wieder auf; dauerhaft fernhalten geht nur über „Ausschließen".
  • Geräte — alle in diesem Netz gefundenen Geräte mit Status (Überwacht / Neu / Ignoriert) und „Host öffnen" bei überwachten.

Quellen-Tags pro Subnet

Tag Herkunft Konfidenz
Interface lokale Netzwerkkarte der Collector-VM Sehr zuverlässig
Route Routing-Tabelle der Collector-VM Sehr zuverlässig
Manuell vom Operator eingetragen Sehr zuverlässig
SNMP-Route Routing-Tabelle per SNMP vom Gateway Zuverlässig
SNMP-ARP ARP-Tabelle (ipNetToMediaTable) per SNMP Zuverlässig
LLDP vom Switch gemeldete Nachbarschaft Zuverlässig
CDP Cisco Discovery Protocol Zuverlässig
mDNS passiver Bonjour-Mitschnitt Vermutung
SSDP passiver UPnP-Mitschnitt Vermutung
Traceroute abgeleitet aus Traceroute-Hops Vermutung
Gescannt im letzten aktiven Scan direkt gesehen Sehr zuverlässig
Ping-Sweep reine ICMP-Antwort Zuverlässig
Implizit (Host) ein Host referenziert das Subnet, wurde aber nie direkt beobachtet Implizit
Implizit (Scan) Nebenprodukt eines Scans in einem angrenzenden Netz Implizit

Farbcode: Implizit-Tags grau, passive Quellen (mDNS/SSDP/Traceroute) amber, alle anderen in der Akzentfarbe.

Findet er nicht alle Netze?

Häufige Gründe:

  • Der Gateway antwortet auf keine der bekannten Communities → passende Community in den SNMP-Einstellungen oder als Zugangsdaten-Set hinterlegen, dann „Netze automatisch finden" erneut klicken
  • 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 starten

„Geräte suchen (Scan)" öffnet das Scan-Modal:

  1. Collector-Picker (Multi-Select, nach Tenant gruppiert). Wählst du mehr als einen Collector, erscheint eine amber-Warnung mit Type-to-Confirm (exakt „N COLLECTORS" eintippen).
  2. Schätz-Grid: Anzahl Subnets (plus „N ausgeschlossen"), Anzahl Sub-Jobs (/24-Chunks — rot, wenn über 256 pro Collector), IPs gesamt (~), geschätzte Dauer (parallel).
  3. „Erweiterte Optionen (Scan-Profil ändern)" — drei Profil-Karten, siehe unten. Default ist Normal.

Hardcap 256 Sub-Jobs pro Collector

Ein /16-Netz sind 256 /24-Chunks — mehr Sub-Jobs pro Collector lehnt der Server ab. Große Netze vorher in kleinere Scans aufteilen.

Scan-Profile

Parameter Stealth Normal Aggressiv
Rate-Limit (pps) 50 200 1000
Parallele /24-Subnets 1 (sequenziell) 4 16
Service-Ports 22, 80, 443, 3389 (SSH, HTTP, HTTPS, RDP) 22, 80, 443, 3306, 3389, 5432, 6379, 8080 (+ MySQL, PgSQL, Redis, AppServer) 24 Ports, u. a. FTP, Telnet, SMTP, DNS, SNMP, LDAP, SMB, JetDirect
Bandbreiten-Spitze ~30 kbit/s ~120 kbit/s ~600 kbit/s
Last niedrig mittel hoch
IDS-Sichtbarkeit niedrig mittel hoch
Type-To-Confirm nein nein exakt „AGGRESSIV" (Danger-Button)

Was über alle Profile identisch ist: Die Host-Discovery-Phase (ICMP-Echo + TCP-Probe) läuft für alle drei Profile gleich — die Unterschiede liegen in Rate, Parallelität und der anschließenden Service-Port-Liste. Ist eine SNMP-Community bekannt, wird jeder gefundene Host in jedem Profil gleich präzise per sysOID/sysDescr klassifiziert — Stealth spart also nur bei den TCP-Ports, nicht bei der Geräteerkennung selbst. Hersteller-Banner und Geräte-Zertifikate werden auf allen geprüften Ports ausgewertet.

Reine SNMP-only-/DNS-only-Geräte ohne offenen TCP-Port und mit geblocktem ICMP werden von keinem Profil gefunden — die müssen manuell als Host angelegt werden.

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 Audits.

Geräte-Lifecycle

Jedes gefundene Gerät hat einen von vier Zuständen: neu, bekannt, hinzugefügt, ignoriert. Der „Geräte"-Tab bündelt sie in vier Segmenten:

Segment Enthält
Unbehandelt neu + bekannt
Ignoriert ignoriert
Hinzugefügt hinzugefügt
Alle alles, inklusive ignorierter Geräte

Die Liste aktualisiert sich alle 15 Sekunden von selbst. Die Suche versteht IP, Hostname, Gerätetyp („synology", „mikrotik") und Tenant. Lange Listen werden bei 500 Einträgen gekappt — dann Suche eingrenzen.

Pro Zeile: „Hinzufügen" öffnet das Host-Formular vorausgefüllt (IP, Hostname, passender Modus, vorgeschlagenes Profil — siehe Hosts anlegen), „Ignorieren" blendet das Gerät ins Segment Ignoriert aus, „Nicht mehr ignorieren" holt es zurück — beides ohne Neuladen.

Ist ein Gerät bereits als Host angelegt, erscheint statt der Aktionen ein „Host öffnen"-Button plus eine grüne „Hinzugefügt"-Pille — verhindert versehentliche Duplikate. Kümmert sich gerade das Automatische Setup um ein Gerät, steht „im automatischen Setup" an der Zeile.

Bulk: Checkboxen + „Ausgewählte hinzufügen (N)", „Ignorieren". Select-All wählt nur die sichtbaren/gefilterten Zeilen; in der „Alle"-Ansicht greifen Sammel-Aktionen nur auf unbehandelte Geräte. Die Sammel-Übernahme prüft die Lizenz-Hostgrenze für die ganze Auswahl und nennt bei Überschreitung die freien Plätze — es wird dann kein Host angelegt.

Gerätename

Ein gefundenes Gerät trägt seinen Namen, nicht nur eine IP — auch ohne Zugangsdaten. Vesana wertet mehrere Namensquellen aus und nimmt die verlässlichste, in dieser Rangfolge:

  1. Reverse-DNS
  2. SNMP (sysName)
  3. LLDP (vom Nachbar-Switch gemeldet)
  4. RDP-Zertifikat (Windows)
  5. SMB
  6. mDNS
  7. NetBIOS (nur im selben Subnetz)
  8. TLS-Zertifikat
  9. Web-Weiterleitung

Eine schlechtere Quelle überschreibt nie eine bessere: Antwortet der DNS-Server bei einem späteren Scan nicht, bleibt der sauber aufgelöste Name stehen. Platzhalter wie „localhost", „WORKGROUP" oder Werksnamen landen nie als Gerätename. Die Herkunft steht im Tooltip („Name aus DNS", „Name aus dem RDP-Zertifikat", …).

Liegen die Namen auf einem DNS-Server im Kundennetz (z. B. dem Domain Controller), den die Collector-VM nicht als Resolver nutzt: Einstellungen → „DNS-Server für die Namensauflösung" pro Collector — IP-Adressen durch Komma getrennt, gilt ab dem nächsten Scan. Leer heißt: der Collector löst über seine eigene Systemkonfiguration auf.

Identität

Ob und was ein gefundenes Gerät „ist", zeigt die Identitäts-Ampel — read-time berechnet, keine gespeicherte Wahrheit, die veralten kann.

Die Ampel ist bewusst zweistufig: bestätigt und wahrscheinlich zeigen grün, ein bloßer Hinweis zeigt amber. Es gibt kein rotes Identitäts-Licht — eine unsichere Vermutung wird nie als Fehler dargestellt.

Das Badge zeigt einen farbigen Punkt, ein konkretes Label („Windows", „Proxmox VE", „MikroTik RouterOS", „MikroTik Switch", …) und im Tooltip die Beweislage (stärkste Evidenz zuerst, z. B. „Port 3389 (RDP) offen"). Ein einzelner offener Standard-Port wie 443 zählt dabei nie als starkes Hersteller-Signal, und eine sicher erkannte Identität (z. B. Debian) gewinnt gegen mehrdeutige Regel-Treffer. Ohne jede Evidenz steht dort „Unbekanntes Gerät (antwortet auf Ping)".

Die VM-Erkennung läuft orthogonal dazu: Erkennt Vesana, dass ein Gerät auf einem Hypervisor läuft, hängt das Badge einen Suffix an — z. B. „· VM auf Proxmox" (ebenso für QEMU-KVM, VMware, Hyper-V, VirtualBox, Xen).

Hat der Profil-Classifier eine konkrete Vermutung, ersetzt eine eigene Profil-Vorschlags-Pille (mit eigener Konfidenz inklusive Konflikt-Status) das Identitäts-Badge. Nach dem Import eines Community-Profils bleiben weitere Geräte desselben Typs eindeutig — die lokale Kopie konkurriert nicht mit dem Hub-Eintrag.

Ghost-Filter

Discovery filtert bekannte Netzwerk-Artefakte automatisch heraus — läuft komplett collector-seitig, ohne Nutzer-Kontrolle. Gedroppt werden ausschließlich beweisbare Artefakte: eine Proxy-ARP-MAC-Adresse, die auf mehr als drei IPs antwortet, oder pauschale RST-Antwort-Sweeps. Ein Gerät, das lediglich hinter einer Firewall nur auf Ping antwortet, bleibt sichtbar — der Filter ist bewusst konservativ und verwirft nie zu viel.

Automatische Scans

Im Tab Einstellungen, pro Collector: „Automatische Scans" mit dem Toggle „Zeitgesteuerte Scans aktiv". Alle Zeiten werden in Lokalzeit eingegeben (intern als UTC gespeichert).

Drei Modi:

Modus Konfiguration
Intervall alle N Stunden (Presets: 1/2/4/6/8/12/24 h, 2/3 Tage, 1 Woche)
Täglich feste Uhrzeit (Stunde + Minute, 5-Minuten-Raster)
Wöchentlich Wochentage (Mehrfachauswahl, mind. einer) + Uhrzeit

Eine Klartext-Zusammenfassung zeigt z. B. „Scannt täglich um 02:00 Uhr…" sowie „Zuletzt gelaufen"/„Nächster Scan". Dazu ein Scan-Profil-Dropdown (Stealth/Normal/Aggressiv) — der automatische Scan läuft über alle nicht ausgeschlossenen Subnets des Collectors und nutzt dieselben SNMP-Communities wie die Netz-Suche (gelernte Communities, Zugangsdaten-Sets, public).

„Subnetze vorher aktualisieren" (Häkchen, Standard aus; ab v1.9.437): Vor jedem geplanten Scan sucht der Collector zuerst nach neuen Netzen und scannt dann über die frische Liste. Ohne Häkchen wird nur gescannt, was schon bekannt ist.

Ist der Collector zum geplanten Zeitpunkt offline, legt Vesana keinen Scan-Auftrag an, der nie ausgeführt würde — der Scan startet, sobald der Collector zurück ist.

Alerts für neue Geräte

Ebenfalls in Einstellungen: Alert-Regeln „neues Gerät". Eine Regel feuert eine Benachrichtigung einmal pro echt-neuem Gerät zum Scan-Zeitpunkt — nicht bei jedem erneuten Sehen desselben Geräts.

Pro Regel:

  • Name
  • Collector (optional — leer = alle)
  • Subnet/CIDR (optional — leer = alle)
  • Benachrichtigungs-Kanäle (Multiselect)
  • Toggle aktiv/inaktiv, Löschen

Regeln gelten tenant-weit. Ausgewertet werden nur neue Geräte aus finalen Scan-Ergebnissen — Zwischenstände aus der ersten Scan-Phase lösen noch keinen Alert aus. Ergebnis und Fehler beim Speichern erscheinen direkt in der Karte.

Multi-Source-Discovery

Der Collector kombiniert mehrere Quellen, statt sich auf eine zu verlassen:

  • Aktiver nmap-Scan — erst Ping-/ARP-Sweep, dann Port-/SNMP-/TLS-/HTTP-/SSH-Fingerprinting
  • Interface und Route — lokale Netzwerkkonfiguration der Collector-VM
  • SNMP-Route (Gateway-Routing-Tabelle) und SNMP-ARP (ARP-Tabelle per SNMP)
  • LLDP — vom Switch gemeldete Nachbarschaft
  • Ping-Sweep — reines ICMP
  • Passiv mDNS/Bonjour, passiv LLDP und CDP (Linux-only), passiv SSDP/UPnP

Die passiven Listener sind Opt-in — sie hören nur mit, senden selbst nichts.

Scan-Historie

Die Historie ist seitenweise (25 pro Seite) mit Status-Filter Alle · Läuft & wartet · Fertig · Fehlgeschlagen. Jede Zeile zeigt Tenant, Collector, exakte Startzeit, Dauer, geprüfte Ports, verwendete SNMP-Community, Wiederholungen und bei Fehlschlag den Fehlertext; Teil-Scans eines „Alles scannen"-Laufs sind als solche markiert. Löschen fragt direkt in der Zeile nach („Scan + Ergebnisse löschen?").

Läuft ein Scan noch, zeigt die Zeile z. B. blau „N Geräte gefunden – Details werden ermittelt…" oder „Suche Geräte…".

Wartet ein Scan, erscheint der Grund in amber:

  • Collector-Update ausstehend — „Wartet auf Collector-Update ({vX → vY}) – startet danach automatisch." Ein gestagter Scan wird zurückgehalten, solange der Collector älter ist als die für den Scan vorgesehene Version — das verhindert, dass ein Auto-Update den laufenden nmap-Prozess killt.
  • Collector offline — „Collector offline – Scan wartet auf Abholung."

SNMP-Einstellungen

Drei Orte, die zusammenspielen:

  • Pro Collector (Einstellungen → „SNMP-Communities"): Community hinzufügen (Default „public"), verschlüsselt gespeichert (als *** angezeigt), mit Erfolgs-/Fehlerzähler — Communities werden in Reihenfolge ihrer Erfolgsrate probiert. Damit ein neuer Eintrag für die Netz-Suche wirkt, danach „Netze automatisch finden" klicken.
  • Pro Tenant (Zugangsdaten-Sets, Art „SNMP v2c"): werden bei automatischen Scans und der Netz-Suche nach den Collector-Communities probiert. SNMPv3-Sets nutzt das Automatische Setup; die Discovery-Klassifikation selbst spricht v1/v2c.
  • Plattform-weit (nur Super-Admin, Einstellungen → „Plattform-Defaults", eingeklappt): „Default-Community für neue Collectors" plus Toggles „ICMP-Pingsweep aktiv" / „ARP-Cache lesen" / „mDNS / SSDP-Listener (passiv)".

Excludes & manuelle Subnets

  • Ausgeschlossene Subnetze legst du aus dem Subnetz-Drawer heraus an; die Liste steht in den Einstellungen. Ein /16-Exclude blockt auch alle darunterliegenden /24-Subnets (CIDR-Vererbung).
  • Manuelle Subnets trägst du über „Subnetz hinzufügen" ein — sie tragen das Quell-Tag „Manuell" und lassen sich in den Einstellungen wieder entfernen.

Reset statt automatischem Purge

Kein automatisches Zeit-Purge

Discovery-Ergebnisse und Scan-Historie werden nicht automatisch nach Alter gelöscht. Aufräumen ist immer eine bewusste Aktion:

  • ein einzelner Scan lässt sich in der Scan-Historie löschen, oder
  • Discovery zurücksetzen (Einstellungen, pro Collector): „Zurücksetzen…" und dann „Endgültig zurücksetzen" — ein Klick zur Bestätigung, kein Bestätigungssatz. Wischt Scan-Ergebnisse (neu, bekannt, ignoriert), die Scan-Historie und „Alles scannen"-Läufe dieses Collectors. Bleibt erhalten: Hosts (auch aus Discovery erstellte), SNMP-Communities, Excludes, manuelle Subnetze und die beobachteten Subnet-Quellen. Das Ergebnis („Reset abgeschlossen — N Scans gelöscht") erscheint direkt in der Karte.

Voraussetzungen

  • Mindestens ein Collector im Kundennetz — oder der Aktive Collector auf dem Vesana-Server, der für jeden Tenant zählt, aber nur die Netze sieht, die der Server selbst erreicht. Siehe Collector.
  • nmap auf dem Collector — wird vom Installer automatisch mitinstalliert
  • SNMP-Community für die Zielgeräte, falls SNMP-Klassifikation gewünscht ist

Discovery für Agent-fähige Hosts

Discovery erkennt das Vorhandensein eines Linux/Windows-Servers (ICMP, SSH-Banner, RDP, SMB, ggf. SNMP), kann aber keinen Agent installieren. Zwei Wege:

  • Von Hand: Host anlegen (direkt aus der Geräteliste über „Hinzufügen") → Agent-Token erzeugen → Token auf der Maschine ausrollen.
  • Über das Automatische Setup: Für erkannte Windows-/Linux-Rechner entsteht die Aufgabe „Agent installieren" mit fertigem Installations-Befehl; sobald sich der Agent meldet, legt Vesana die Checks an.

Tipps

  • Subnetz-Größe: /24 scannt schnell, ein /16 solltest du splitten oder mit dem Aggressiv-Profil fahren
  • SNMP-Community früh hinterlegen — sonst bleiben Geräte als „Unbekanntes Gerät" stehen, obwohl SNMP verfügbar wäre
  • Automatische Scans statt manuellem Wiederholen — siehe oben
  • Fehlt ein VLAN? Erst „Netze automatisch finden", dann „Subnetz hinzufügen"

Anschluss