Früher galt eine Einbruchserkennung als zu kompliziert und zu teuer für Heimnetze. Heute lässt sich ein solches Alarmsystem mit einem RasPi und freier Software schnell und kostengünstig aufsetzen.

Ein System zur Erkennung von Einbrüchen (Intrusion Detection System, IDS) funktioniert wie ein Rauchmelder: Es bemerkt die Gefahr, gibt eine Warnung aus, verhindert aber keineswegs die Katastrophe. Während Rauchmelder in den eigenen vier Wänden bereits Pflicht sind, finden sich IP-Alarmanlagen in den wenigsten Heimnetzen.

Das IDS wirft einen tiefen Blick in die durchlaufenden IP-Pakete. Erscheinen die analysierten Inhalte verdächtig, schlägt das System Alarm. Ob ein Paket einen möglichen Angriff enthält, weiß das IDS aus einer mit bekannten Angriffsmustern gefüllten Datenbank. Damit ähnelt es einem Virenscanner: Es untersucht Daten und vergleicht sie mit bekannten Mustern.

In Rechenzentren gilt ein IDS heute als Standard: Eine flotte Appliance empfängt über eine Multi-Gigabit-Netzwerkkarte die Datenströme aller Server und berichtet ihre Entdeckungen dem Network Operations Team. Was nach einer kostspieligen Lösung klingt, lässt sich technisch genauso gut auf Heimnetze übertragen. Als Hardware fungiert dann kein lärmender Server, sondern ein Raspberry Pi oder ein vergleichbarer Minicomputer. Das kleine IDS holt sich von der Fritzbox eine Kopie der übertragenen Pakete und beginnt mit seiner Detektivarbeit.

Eine Warnung vorweg: Bei dem im Folgenden vorgestellten Aufbau handelt es sich eher um einen Lifehack als um ein unterstütztes Szenario. Die Fritzbox muss durch die zusätzliche Aufgabe etwas mehr Leistung aufbringen und erreicht dann je nach Modell möglicherweise nicht mehr die volle Bandbreite.

Ausstattung

Das IDS benötigt für seine Untersuchungen Rechenleistung. Daher sollten Sie mindestens einen Raspberry Pi 3B+ einsetzen, besser noch einen Vertreter der vierten RasPi-Generation. Wer es mit einem anderen Mini-PC versuchen möchte, benötigt mindestens 1 GByte Arbeitsspeicher und eine Zwei-Kern-CPU. Als Betriebssystem genügt ein aktuelles Pi OS oder Debian ohne grafische Oberfläche.

Nach der Installation des Pi OS benötigt der Raspberry keine lokale Konsole mehr. Die Konfiguration nehmen Sie über SSH vor, und mehrere Webseiten kümmern sich um die spätere Auswertung. Für die Auswahl der Software gilt: Sparsam mit Leistung und Flash umgehen. Eine 500 MByte große Log-Datei des IDS macht das System träge und beinahe untauglich. Für große Installationen mag Elasticsearch das richtige Backend sein, für das Heim-IDS tut es eine schlanke SQLite-Datenbank.

Suricata

Als Herzstück des RasPi-IDS dient Suricata [1], eine quelloffene Software zur Einbruchserkennung. Der Suricata-Prozess lauscht an einem Netzadapter und vergleicht die durchlaufenden IP-Pakete mit seiner Signaturdatenbank. Passt das untersuchte Paket zu einer Signatur, reagiert Suricata mit der hinterlegten Aktion, die zum Beispiel einen Alarm auslöst. Die Analyse hängt also von der Qualität der Signaturen ab.

Zuerst muss die Software ihren Weg auf den RasPi finden (Listing 1, erste Zeile). Im Repository findet sich eine aktuelle Version, die für das Heim-IDS ausreicht. Als Besonderheit konzentriert sich Suricata nicht auf den physischen Netzadapter eth0, sondern auf den virtuellen Adapter ids0 (Zeile 2). Der Update-Befehl (Zeile 4) holt sich die kostenfreien Signaturen, was je nach Geschwindigkeit der Internet-Anbindung einige Minuten dauert. Beispielsweise vergehen beim Laden und Testen von 43 000 Regeln auf einem Raspberry Pi 3B+ etwa drei Minuten.

# apt install suricata
# sed -i -e 's/interface: eth0/interface: ids0/' /etc/suricata/suricata.yaml
# ln -s /var/lib/suricata/rules/suricata.rules /etc/suricata/rules/
# suricata-update
# systemctl stop suricata
[... siehe Listing 2 ...]
# suricata -c /etc/suricata/suricata.yaml -i ids0 -v
# systemctl start suricata

Danach stoppen Sie Suricata erst einmal (Zeile 5). Der erste “heiße” Start das IDS muss noch warten, bis die Anweisungen aus Listing 2 die Schnittstelle ids0 zum Leben erweckt haben – dazu später mehr. Ist das erledigt, starten Sie Suricata manuell neu (Zeile 7 und 8). Es greift die Pakete vom Interface ids0 ab und prüft sie gegen die aktivierten Signaturen. Schlägt eine der Regeln zu, gibt es einen Eintrag in der Datei eve.json – dazu später mehr. Falls Fehlermeldungen den Systemstart begleiten, lohnt sich der Einsatz der Verbose-Option -v.

Sie sollten etwas Geduld mitbringen, denn auf einem RasPi 3B+ dauert es bis zu zwei Minuten, bis Suricata die Signaturen geladen hat und einsatzbereit ist. Das Protokoll der Anwendung findet sich als Datei unter /var/log/suricata/.

Workflow

Die meisten Heim-Router verfügen nicht über einen Mirror-Port, der Paketkopien erstellt und über einen anderen LAN-Anschluss an einen Analyseserver sendet. Daher muss das RasPi-IDS die Daten von der Fritzbox einfordern (Abbildung 1). Dazu genügen Wget und etwas Bash-Gefummel. Die gesammelten Pakete soll Wget aber nicht zwischenspeichern (das würde die SD-Karte relativ schnell töten), sondern dem IDS-Prozess zuspielen.

Abbildung 1: Der RasPi sitzt im Heimnetzwerk und holt sich die Kopien aller IP-Pakete von der Fritzbox.

Die Magie einer Pipe hilft hier ausnahmsweise nicht: Suricata bricht seine Arbeit ab, sobald kein Datenstrom durch die Pipe fließt, sprich, wenn die Fritzbox im Leerlauf döst. Die Lösung besteht in einem Dummy-Netzadapter, der sich wie ein zweites Loopback-Interface verhält. Konkret holt sich Wget PCAP-Dateien von der Fritzbox und sendet die darin enthaltenen IP-Pakete an das Dummy-Interface. An dieser Dummy-NIC lauscht Suricata und erhält damit alle Pakete in Kopie, die durch die eigene Internet-Leitung fließen. In den Paketen stöbert Suricata nach verdächtigen Inhalten. Der Umweg über das Dummy-Interface bietet den Vorteil, dass sich ohne Umbau weitere Analysewerkzeuge andocken können, etwa Tcpdump.

Suricata sichert seine Ergebnisse im JSON-Format als Textdatei. Die grafische Aufarbeitung übernimmt Evebox: Das Tool zerlegt die JSON-Zeilen, extrahiert die wesentlichen Inhalte und stellt alles schick als Webseite dar.

Fritzbox und Fritzdump

Das angekündigte Bash-Gefummel mit Fritzbox und PCAP haben bereits andere als Skript formuliert und als fritzdump.sh auf Github platziert [2]. Das Zielsystem ist dabei kein IDS, sondern das Monitoring-Paket Ntop-NG, aber der Umbau gestaltet sich überraschend einfach.

Doch zuerst wenden Sie sich dem Dummy-Interface zu. Da Pi OS den NetworkManager mitbringt, klappt die Einrichtung mit einem Einzeiler (Listing 2, erste Zeile). Der Dummy-Netzadapter dient als Bindeglied zwischen Fritzdump und Suricata. Die beiden systemctl-Zeilen am Schluss des Listings stellen sicher, dass der NetworkManager läuft und sich um das neue Interface ids0 kümmert.

# nmcli con add type dummy ifname ids0 ipv4.method disabled ipv6.method disabled
# systemctl enable NetworkManager
# systemctl start NetworkManager

Zurück zur Fritzbox: Die muss die versteckte Funktion Paketmitschnitt unterstützen. Das lässt sich schnell prüfen, denn eine passende Fritzbox bietet dazu die Webseite http://fritz.box/html/capture.html an (Abbildung 2). Schlecht sieht es dagegen aus, falls nur ein 404-Fehler zurückkommt.

Abbildung 2: Bietet die Fritzbox einen Paketmitschnitt an, kann das IDS die Pakete abgreifen und analysieren.

Die große Auswahl der Schnittstellen wirft die Frage auf, welche davon wohl die richtige ist? Grundsätzlich untersucht ein IDS die Pakete auf der LAN-Seite, da auf der WAN-Seite Angriffe relativ normal sind. Die Wahl fällt demnach auf die Schnittstelle lan oder wifi0.

Ungünstigerweise hat die Schnittstelle intern noch einen weiteren Namen, den Fritzdump in exakter Schreibweise benötigt. Wenn Sie nicht den HTML-Quellcode durchstöbern möchten, klicken Sie auf der Webseite bei der entsprechenden Schnittstelle auf Start und untersuchen anschließend den Download-Link. Dieser enthält in der URL den Parameter ifaceorminor, gefolgt vom exakten Namen der ausgewählten Schnittstelle.

Zuletzt kommt das Skript an die Reihe. Es liegt bei Github [2] und erfordert nur wenige Anpassungen an seine neue Rolle als Paketzulieferer. Listing 3 zeigt die Installation und das Anpassen des Skripts an das RasPi-IDS. Tragen Sie im Skript fritzdump.sh für die Variable IFACE den Interface-Namen aus dem vorherigen Abschnitt ein.

# apt install tcpreplay
# wget https://raw.githubusercontent.com/ntop/ntopng/dev/tools/fritzdump.sh
# sed -i -e 's/ntopng.*/nice tcpreplay --mbps 1000 -i ids0 -/' fritzdump.sh
# install --mode=755 fritzdump.sh /usr/bin/
# fritzdump.sh dslf-config Fritzbox-Passwort
# systemctl restart suricata
# tcpdump -nnli ids0

Das Sed-Kommando aus Zeile 3 entfernt kurzerhand Ntop-NG und ersetzt es durch Tcpreplay, ein Werkzeug, das Pakete aus PCAP-Dateien wieder ins Netz einspielt. Dabei gehen die Pakete über das Dummy-Interface hinaus und erreichen so Suricata. Da Tcpreplay viel CPU-Power verbrät, bremst Nice diesen Hunger etwas und lässt das Gesamtsystem weniger träge erscheinen.

Sobald die Vorbereitungen abgeschlossen sind, dürfen Sie fritzdump.sh und Suricata starten (Zeile 5 und 6). Das Skript erwartet den Benutzernamen und das Kennwort der Fritzbox als Kommandozeilenargument. Melden Sie sich an Ihrer Fritzbox ausschließlich per Passwort an, verwenden Sie für das Skript den Benutzer dslf-config oder fritz3103.

Das Skript beginnt sogleich damit, Pakete zur Dummy-NIC zu schaufeln. Ob das funktioniert, kann Tcpdump bestätigen, das die Pakete in der Konsole abbildet (Zeile 7). Damit Fritzdump nach einem Reboot seine Arbeit wieder aufnimmt, benötigt es einen Eintrag in der Datei /etc/rc.local vor der finalen Anweisung exit.

Regelwerk

In der Voreinstellung nutzt das IDS alle verfügbaren Signaturen, also auch solche von in Heimnetzen unüblichen Protokollen. Die Untersuchung der IP-Pakete durchläuft also unnötig viele Kontrollen und macht das IDS träge. Schlimmer noch: Manche Signaturen bemängeln sogar unerwartete Werte im TCP-Header und blähen damit die Log-Datei eve.json auf. Pro Tag wächst diese Datei dann um etwa 500 MByte an – das ist für das RasPi-IDS viel zu groß.

Als Faustregel gilt: Aktivieren Sie nur die wichtigsten Regeln, sonst platzt eve.json aus allen Nähten, und Evebox reagiert nicht mehr. Doch was zählt zu den wichtigsten Regeln? Das müssen Sie schlicht ausprobieren, denn in jedem Heimnetz sind andere Anwendungen unterwegs. Falls eine bestimmte Alarmierung von Suricata ständig im Log hängen bleibt und der Inhalt unpassend oder nur informativ ist, setzen Sie diese Regel oder Regelgruppe auf die Ausnahmeliste. Das Beispiel aus Listing 4 deaktiviert drei Regelgruppen mit rein informativen Inhalten und aktualisiert danach die neue reduzierte Signaturliste.

# cat <<EOF > /etc/suricata/disable.conf
group:stream-events.rules
group:decoder-events.rules
group:emerging-info.rules
EOF
# suricata-update

Evebox

Bei welchen Paketen hat Suricata Alarm geschlagen? Möchten Sie sich nicht durch lange JSON-Zeilen arbeiten, dann holen Sie sich die webbasierte Ansicht von Evebox ins Haus und stöbern wie in Abbildung 3 durch die Meldungen. Für die Installation stellt das Team hinter Evebox ein eigenes Repository zur Verfügung, das spätere Aktualisierungen ermöglicht. Das Einrichten von Repo und GPG-Schlüssel fällt fast aufwendiger aus als die eigentliche Installation, wie Listing 5 zeigt.

Abbildung 3: Evebox bereitet die Alarmliste von Suricata grafisch auf.

# apt install gnupg apt-transport-https
# wget -qO - https://evebox.org/files/GPG-KEY-evebox | apt-key add -
# cat <<EOF > /etc/apt/sources.list.d/evebox.list
deb http://evebox.org/files/debian stable main
EOF
# apt update
# apt install evebox

Eine minimale Konfiguration für die Evebox findet sich in Listing 6, dessen Inhalt Sie in der Datei /etc/evebox/evebox.yaml ablegen. Die Werte sind schonend gewählt und passen für einen Raspberry Pi. Nach dem Speichern darf Evebox per systemctl restart evebox seine Dienste anbieten. Anschließend steht die Webseite http://ip_vom_pi:5636 bereit und informiert zukünftig über Alarme. Genau genommen sehen Sie nicht die originalen Alarme von Suricata, sondern die von Evebox aufgearbeitete Liste.

http:
  tls:
    enabled: false
  host: 0.0.0.0
  port: 5636
database:
  type: sqlite
  retention:
    days: 7
    size: "500 MB"
input:
  enabled: true
  paths:
    - "/var/log/suricata/eve.json*"

IDS testen

Damit wäre alles startklar, aber Sie sollten sicherheitshalber testen, ob das Home-IDS auch funktioniert. Ähnlich wie bei EICAR für Virenscanner gibt es eine präparierte Webseite, die einem aktiven IDS auffallen soll.

Für diesen Test muss ein Client aus dem Heimnetz auf die Website http://testmynids.org/uid/index.html zugreifen. Dabei spielt es keine Rolle, ob das per Webbrowser oder Curl passiert, so lange Sie die Webseite über die Fritzbox aufrufen. Wichtig ist dabei, dass Suricata den Pseudo-Angriff erkennt und Evebox ihn als GPL ATTACK_RESPONSE id check returned root anzeigt (Abbildung 4).

Abbildung 4: Suricata erkennt die Test-Webseite, und Evebox meldet den Pseudo-Alarm.

Im Gegensatz zu EICAR bei einem Virenscanner zeigt der Webbrowser den Inhalt der Webseite an. Das liegt daran, dass Suricata lediglich als IDS arbeitet und nicht als Intrusion Prevention System (IPS). Der Unterschied liegt darin, dass ein IDS lediglich alarmiert, während ein IPS den Angriff verhindert.

Abspecken

Standardmäßig speichert Suricata zahlreiche Informationen und Statistiken, was die Log-Dateien schnell anschwellen lässt. Evebox muss die Alerts mühsam heraussuchen, was viele Zugriffe auf das Flash-Speichermedium bewirkt. Eine RAM-Disk hilft zwar ein wenig, aber es ist zweifellos sinnvoller, die unnötigen Werte gar nicht erst zu speichern.

Dazu müssen Sie in die Konfigurationsdatei suricata.yaml eingreifen. Das YAML-Format arbeitet mit Einrückungen und liest sich wie eine Gliederung von Themen und Stichpunkten. Alles, was in der Log-Datei eve.json landen soll, listet Suricata unter outputs im Unterabschnitt eve-log. Für den Betrieb auf einem Raspberry Pi empfiehlt es sich, alle dort in types aufgeführten Ausgabeformate auszukommentieren oder auf false zu setzen, mit Ausnahme von alert, anomaly und drop (Abbildung 5).

Abbildung 5: Per Konfigurationsdatei arbeitet Suricata sparsam und entlastet damit den RasPi.

Der nächste Rotstift setzt bei den Signaturen an. Im vorherigen Abschnitt mussten bereits drei Regelgruppen das Feld räumen. Wenn Evebox weitere Alarme vermeldet, die lästig, unnötig oder falsch sind, kommt ein entsprechender Eintrag in die Datei disable.conf mit anschließendem Update der Signaturdatenbank zum Einsatz.

Verhält sich der RasPi nach der Aufräumaktion immer noch träge, lohnt es sich, die SQLite-Datenbank von Evebox unter /var/lib/evebox/ zu leeren oder in /var/log/suricata/ eine frische eve.json zu erstellen. In beiden Fällen müssen Sie den jeweiligen Dienst einmal per Systemctl neu starten.

Aufpasser

Zu guter Letzt überprüfen Sie, unter welcher Last die Fritzbox mit aktiviertem IDS läuft. Ältere Modelle zeigen sich durch das permanente Herunterladen der PCAP-Datei überfordert und reagieren mit geringerer Durchsatzrate. Beispielsweise erreicht eine Fritzbox 6591 an einem 100-MBit/s-Kabelanschluss von Vodafone noch etwa 75 Mbit/s im Download, während das Heim-IDS läuft. Die Upload-Rate bleibt davon unberührt. Hier gilt es abzuwägen, ob die Sicherheit oder die Performance im Vordergrund steht.

Das IDS wirkt nur, wenn die Prozesse von Fritzdump und Suricata laufen. Falls nicht, ist das Einbruchserkennungsnetz löchrig und gefährliche IP-Pakete bleiben unentdeckt. Ein kleines Überwachungswerkzeug wie M/Monit [4] kontrolliert die kritischen Prozesse und startet sie bei Bedarf neu (Listing 7).

# apt install monit
# cat <<EOF >> /etc/monit/monitrc
set httpd port 2812 and
  use address 0.0.0.0
  allow admin:monit
EOF
# systemctl restart monit

Eine passende Konfigurationsdatei für alle relevanten Dienste des Heim-IDS finden Sie im Download-Bereich zu diesem Artikel [5]. Diese Datei namens monit_ids.conf gehört ins Verzeichnis /etc/monit/conf.d/. M/Monit nutzt sie beim Neustart automatisch. Über die Webseite Abbildung 6).

Abbildung 6: Der Monit Service Manager überwacht die IDS-Prozesse und startet sie bei Bedarf neu.

Alarme auswerten

Evebox signalisiert die Bedeutung einer Meldung mithilfe eines Farbschemas: Hinweise erscheinen im Light Theme in Türkis, Angriffe in Orange und kritische Zustände in Rot (Abbildung 3). Im Dark Theme gehen die Farben nahezu unter, sodass wichtige Meldungen nicht mehr ausreichend hervorstechen. Indem Sie auf die Meldung klicken, wechseln Sie zur Detailansicht mit sämtlichen Informationen, die Suricata notiert hat. Mit dem Severity-Wert gibt Suricata an, wie bedrohlich es den Alert einstuft. Evebox verwendet den Zahlenwert, um die Meldung einzufärben.

Im nächsten Schritt machen Sie sich auf die Suche nach dem Client, der den Alarm ausgelöst hat. Die Felder Source und Destination zeigen die verantwortlichen IP-Adressen samt Port-Nummer an, jedoch ohne Auflösung in Host-Name oder Anwendung. Erscheint der Titel des Alerts schwammig oder unklar, hilft die Signatur-ID weiter, mit der sich die Regel in den Signaturdateien wiederfinden. Benötigen Sie mehr Details einer Signatur, gibt Grep Auskunft:

$ grep ID /etc/suricata/rules/*

Das Ergebnis ist die Syntax der Signatur, so wie Suricata sie einliest und verarbeitet. Editoren mit passendem Syntax-Highlighting, wie etwa Visual Studio Code, machen den Inhalt etwas lesbarer.

Beispielsweise hat die Meldung ALERT: ET CINS Active Threat Intelligence Poor Reputation IP group 48 ein eingehendes HTTP-Paket im LAN gesichtet. Im lokalen Netz wird offenbar ein Webserver öffentlich angeboten, der von allen IP-Adressen im Internet zu erreichen ist. Weder Suricata noch Evebox empfehlen in diesem Fall eine konkrete Aktion, aber beide Tools machen den Admin immerhin auf den Missstand aufmerksam. Im einfachsten Fall liegt eine vergessene Port-Weiterleitung vor. Die Meldung deutet jedoch darauf hin, dass der eigene Webserver unter Beschuss steht. Als geeignete Maßnahme kommen hier ein GeoIP-Blocker oder ein DDoS-Tool wie Fail2ban [6] infrage.

Grundlose Alarme?

Nicht jeder Angriff muss gefährlich sein. Die orangefarbene Meldung ALERT: ET DNS Query to a *.pw domain — Likely Hostile warnt vor dem Zugriff auf eine Webseite mit der Top-Level-Domain http://pw. Eine kurze Recherche zeigt, dass hier jemand seinen Passwortmanager Buttercup über die Webseite http://buttercup.pw aktualisiert hat (Abbildung 7). Eine unmittelbare Gefahr geht davon nicht aus.

Abbildung 7: Eine DNS-Anfrage nach der TLD http://pw ist Suricata einen Alarm wert. Hier aktualisiert lediglich ein Client seinen Passwortmanager, der seine Webseite in dieser Domain hostet.

Kein Rechner läuft, aber das IDS meldet dennoch etwas? Hand aufs Herz: Wie viele Smartphones, Laptops und Smart-Home-Geräte nutzen Ihre Fritzbox? Jedes Endgerät im Netz hat eine IP-Adresse, und jede Suricata-Meldung enthält deren Quell- und Zieladresse. Ein Blick in die Teilnehmerliste der Fritzbox offenbart, welches Endgerät zu dieser Adresse gehört. Zugegeben: Wenn Suricata zum hundertsten Mal dieselbe Kommunikation anmeckert, sollten Sie diese Signatur aus dem Verkehr ziehen. Der richtige Ort dafür ist die bereits bekannte Datei disable.conf.

Sicherheit

Ein IDS bringt zwar ein Stückchen mehr Sicherheit, die vorgestellte Installation markiert allerdings nur den Einstieg in die seriöse Einbruchserkennung. Der robuste Einsatz im Unternehmen würde noch einige Ergänzungen erfordern. Die Webseiten von Evebox und M/Monit benötigen einen HTTPS-Zugang mit warnungsfreiem Zertifikat. Zudem sollte eine Authentifizierung nicht fehlen, damit nicht jeder in den Logs herumstöbern kann.

Fritzdump erwartet zwar das Kennwort der Fritzbox, doch das sollte auf keinen Fall in der Prozessliste zu sehen sein. Sicherheitsrelevante Informationen bewahren Sie besser in Variablen oder Dateien mit restriktiven Rechten auf. Darüber hinaus läuft Suricata als Root, was bedenklich ist. Das ändern Sie in der Konfigurationsdatei im Abschnitt run-as: und spannen ein dedizierten IDS-Benutzer dafür ein.

Ein Raspberry Pi mit Linux gilt nicht als völlig ungeschützt, trotzdem sollten Sie eine lokale Firewall aktivieren. Hier bietet das Pi OS die üblichen Verdächtigen Iptables, Nftables und Firewalld an. Der Zugriff lässt sich damit auf die benötigten Anwendungen (SSH und HTTPS) einschränken und auf das lokale Netz eingrenzen. Zuletzt erweist sich die Integration in ein bestehendes Alerting-System als nützlich. Wenn die kritische Meldung im Dateisystem des RasPi untergeht, hilft das wenig: Sie muss zeitnah auf dem Smartphone des zuständigen Admins erscheinen.

Fazit

Kein IDS vermag alle Sicherheitsprobleme zu lösen. Genauso wie Zwei-Faktor-Authentifizierung, Virenscanner und Verschlüsselung leistet es jedoch seinen Beitrag dazu, das Netzwerk abzusichern. Angesichts eines überschaubaren Budgets können ein Raspberry Pi und die freie Software Suricata in Verbindung mit einer Fritzbox die Einbruchserkennung übernehmen.

Die Fritzbox liefert die durchlaufenden Pakete im gängigen PCAP-Format, Suricata wirft einen kritischen Blick hinein. Warnungen, Alarme und Statistiken gibt es per Weboberfläche. Es dürfte Sie überraschen, wie auffällig sich Ihre Clients und verborgenen Always-on-Geräte verhalten. (csi/jlu)