Hast du öfter Probleme mit deinem WiFi und fragst dich, ob da nicht möglicherweise der Nachbar versucht, dein WLAN zu hacken? Natürlich kannst du den Datenverkehr in der Luft 24/7 loggen und auswerten, aber Spaß wirst du am Ende keinen dabei haben. Spaß hast du auch nicht dem dem Tool nzyme, aber es nimmt dir die Suche nach Angriffen im WLAN ab und das ist ja auch nicht schlecht.
Entgegen der Beschreibung auf der Entwicklerseite stelle ich dir die Installation unter Debian vor, ich hatte darüber hinaus noch einen alten Fritz!WLAN-USB-Dongle herumliegen, der im 2,4- und 5 GHz-Band dann nach unerwünschten Signalen snifft. Natürlich kannst du dir auch entsprechende Hardware von Alfa oder Panda besorgen (siehe ebenfalls Entwicklerseite).
Aber zunächst installieren wir uns die entsprechenden Pakete, die für die eigentliche Installation benötigt werden:
$ sudo apt update && sudo apt install -y libpcap0.8 openjdk-11-jre-headless postgresql-13 wireless-tools
Dann lädst du dir nzyme in der aktuellen Version (hier 1.2.2) herunter und installierst es:
$ wget https://assets.nzyme.org/releases/nzyme-1.2.2.deb
$ sudo dpkg -i nzyme-1.2.2.deb
Selecting previously unselected package nzyme.
(Reading database ... 73229 files and directories currently installed.)
Preparing to unpack nzyme-1.2.2.deb ...
Unpacking nzyme (1.2.2) ...
Setting up nzyme (1.2.2) .
Dann musst du dir leider noch einiges konfigurieren, out of the box läuft das leider noch nicht.
Dazu bringst du als erstes in Erfahrung, wie dein WLAN-Netzwerkadapter unter Debian benannt ist, dazu benötigst du root-Rechte:
# iwconfig
lo no wireless extensions.
enp3s0 no wireless extensions.
wlxe2af905efb6c IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry short long limit:2 RTS thr:off Fragment thr:off
Power Management:off
Okay, der Name lautet wlxe2af905efb6c. Solltest du hier keinen WLAN-Netzwerkadapter sehen, dann ist dieser entweder nicht angesteckt oder es fehlen dir die passenden Treiber. Diese Installation ist nicht Bestandteil dieses Blogbeitrages, das ist je nach Hardware schlicht zu unterschiedlich.
Anschließend konfigurierst du dir die Datenbank, in der am Ende alle Daten geloggt werden, wähle ein eigenes Passwort und notiere dir das sowie den Namen der Datenbank und des Benutzers (hier nzyme), du brauchst es noch.
$ sudo -u postgres psql
postgres=# create database nzyme;
CREATE DATABASE
postgres=# create user nzyme with encrypted password 'DEIN_DB_PASSWORT';
CREATE ROLE
postgres=# grant all privileges on database nzyme to nzyme;
GRANT
postgres=# \q
Die psql-Shell kannst du mit STRG-d beenden.
Jetzt generierst du dir noch fix ein Passwort (ersetze dafür den LOGINPASSWORT durch dein persönliches Passwort) für den späteren Login und kopierst dir den Hash-Wert (hier 23d5f1a340ef7f9987b9027470086d4de1c62d145b8061f7a7ca6b53a8f04546) in die Zwischenablage.
$ echo -n LOGINPASSWORT | sha256sum
23d5f1a340ef7f9987b9027470086d4de1c62d145b8061f7a7ca6b53a8f04546 -
Als nächstes kopierst du dir die Vorlage für die Konfigurationsdatei in den entsprechenden etc-Ordner und öffnest diese im Editor.
$ sudo cp /etc/nzyme/nzyme.conf.example /etc/nzyme/nzyme.conf
$ nano /etc/nzyme/nzyme.conf
Folgende Zeilen solltest du jetzt anpassen:
...
admin_password_hash:23d5f1a340ef7f9987b9027470086d4de1c62d145b8061f7a7ca6b53a8f04546
...
database_path: "postgresql://localhost:5432/nzyme?user=nzyme&password=DEIN_DB_PASSWORT"
...
path: /usr/bin/python3.9
...
802_11_monitors: [
{
# The 802.11/WiFi adapter name. (from `ifconfig` or `ip link`)
device: wlxe2af905efb6c
# WiFi interface and 802.11 channels to use. Nzyme will cycle your network adapters through these channels.
# Consider local legal requirements and regulations.
# See also: https://en.wikipedia.org/wiki/List_of_WLAN_channels
channels: [1,2,3,4,5,6,7,8,9,10,11,12,13,14,36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136]
...
Es steht dir frei, in der Sektion alerting und 802_11_traps entsprechende Angaben für den Mail-Server zu machen, damit du später auch per Mail über „Störer“ alarmiert wirst.
Das ist es bereits zur Grundkonfiguration, anschließend aktivierst du nzyme als Systemdienst und startest diesen:
$ sudo systemctl enable nzyme
Created symlink /etc/systemd/system/multi-user.target.wants/nzyme.service → /lib/systemd/system/nzyme.service.
$ sudo systemctl start nzyme
$ sudo systemctl status nzyme
● nzyme.service - Nzyme
Loaded: loaded (/lib/systemd/system/nzyme.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-12-27 20:05:48 CET; 18h ago
Docs: https://github.com/lennartkoopmann/nzyme
Main PID: 3219300 (nzyme)
Tasks: 77 (limit: 8846)
Memory: 784.1M
CPU: 2h 26min 59.583s
CGroup: /system.slice/nzyme.service
├─3219300 /bin/sh /usr/share/nzyme/bin/nzyme
└─3219301 /usr/bin/java -Xmx1g -jar -Dlog4j.configurationFile=file:///etc/nzyme/log4j2-debian.xml /usr/share/nzyme/nzym>
Nach ca. 30 Sekunden Wartezeit, die der Dienst zum Starten benötigt, kannst du dich an der Weboberfläche unter http://127.0.0.1:22900 anmelden. Der Benutzername lautet admin, das Passwort hast du dir ja notiert (im Beispiel oben LOGINPASSWORT (nicht den HASH-Wert selbst).
Wenn du von einem anderen Computer in deinem LAN auf nzyme zugreifen möchtest, dann ändere die Einstellungen der interfaces in der Konfigurationsdatei unter /etc/nzyme/nzyme.conf. Ersetze die 127.0.0.1 durch die entsprechende IP deiner nzyme-Installation, die du mit ip a herausfinden kannst und starte den Dienst neu.
# Web interface and REST API configuration.
interfaces: {
# Make sure to set this to an IP address you can reach from your workstation.
rest_listen_uri: "http://127.0.0.1:22900/"
# This is usually the same as the `rest_listen_uri`. Take a look at the configuration documentation to learn about
# other use-cases. It will be interesting if you run behind a load balancer or NAT. (basically, it is the address
# that your web browser will use to try to connect to nzyme and it has to be reachable for it.)
http_external_uri: "http://127.0.0.1:22900/"
# Use TLS? (HTTPS) See https://go.nzyme.org/docs-https
use_tls: false
}
Jetzt siehst du sicherlich etliche Alarmmeldungen wie z.B. UNKNOWN_SSID.
Das ist zum jetzigen Zeitpunkt noch kein Grund zur Sorge. Deine Fleißaufgabe lautet jetzt, alle BSSID mitsamt MAC-Adresse und Fingerprint, die du überwachen willst, erst einmal zu notieren und in die Konfigurationsdatei unter /etc/nzyme/nzyme.conf einzupflegen. Die kannst du leicht ermitteln, in dem du auf Details klickst, gefolgt von einem der beiden blauen Links (die Kringel) neben der ssid oder der bssid.
Im folgenden Bild kannst du alle für die weitere Konfiguration nötigen Angaben wie ssid, bssid und Fingerprint entnehmen:
Editiere also die Konfigurationsdatei erneut und ändere den Abschnitt 802_11_networks.
802_11_networks: [
{
ssid: Funkloch
channels: [1,2,3,4,5,6,7,8,9,10,11,12,13,14,36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136]
security: [WPA2-PSK-CCMP]
beacon_rate: 40
bssids: [
{
address: "de:39:6f:36:1c:b7",
fingerprints: [ 64e3d11addd5516dcb324d8cd31bf40f9143a6fb37d2dbcccc50a3225d88da5e ]
}
]
}
]
Starte anschließend den Dienst neu:
$ sudo systemctl stop nzyme
$ sudo systemctl start nzyme
Solltest du mehrere Accesspoints zu einem WLAN (hier Funkloch) haben, dann musst du unter bssid auch mehrere Felder address und fingerprints anlegen, das Array lässt sich leicht erweitern. Genauso kannst du auch bei mehreren zu überwachenden WLAN’s vorgehen. Die Konfiguration ist auch hier ganz gut beschrieben. Solltest du hierzu mehr Infos brauchen, schreibe es in die Kommentare, dann erweitere ich die Beispiele.
Die Alarme wechseln, sofern sie nicht mehr einen aktiven Zustand haben, nach 10 Minuten automatisch in einen passiven Modus – sie stehen aber weiterhin im Logfile.
Jetzt liegt es an dir, verschiede Alarme korrekt zu deuten, hier ein paar Beispiele:
Hallo ich hätte Interesse Nzyme unter Docker in einem Container laufen zu lassen.
Haben Sie dieses ev schon lauffähig.
Ich habe Nzyme in einem Container lauffähig schaffe es nicht meine Panda Wöan USB Sticks im Container sichtbar zu bekommen.
Danke für Ihre Rückmeldung
Mit freundlichen Grüßen A. Krause
Zugegebenermaßen ist nzyme eines der wenigen Tools (neben ntopng und fail2ban), die ich nicht unter Docker laufen habe. Bei nzyme würde es aber durchaus Sinn machen, da der WLAN-USB-Stick ohnehin nur exklusiv durch die Anwendung nzyme genutzt wird. Da wäre es durchaus ein denkbares Szenario, bei dem die Docker-Instanz exklusiv Zugriff auf die diese spezielle Hardware bekommt.
Leider kann ich da spontan auch keine Lösung präsentieren, so ein WLAN-USB-Stick ist schließlich kein einfacher USB-Stick mit einem beschreibbaren Dateisystem.
Ich kann nicht versprechen, mich in nächster Zeit damit mal näher zu beschäftigen. Wenn eine Lösung gefunden wird, würde ich mich über eine Info zum Lösungsweg freuen.
Schöner Artikel! Wie viele WLAN-Adapter hast Du bei Dir am Start? Auf der Nzyme-Website erwähnen die mehrfach, dass die mehrere Sticks an einen Raspi hängen. Ich verstehe nur den Grund nicht.
Danke.
In der Tat nutze ich nur einen einzelnen. Dies hat den Nachteil, das dieser zeitgleich im 2,4- und 5GHz-Band scannen muss. Ein einzelner Adapter kann jedoch grundsätzlich nur auf einer Frequenz in einem Frequenzband gleichzeitig sein. Also schaltet der Adapter in sehr kurzen Abständen einen Kanal (Frequenz) nach dem anderen durch und lauscht dort auf Aktivitäten (Frequenzband und Kanäle lassen sich in der Konfiguration ja auch pro Gerät gezielt einstellen). In einer wirklich sicherheitskritischen Umgebung macht das Aufteilen des Scans auf unterschiedlichen Frequenzen auf mehrere Adapter wirklich Sinn. Viele Augen/Ohren sehen/hören halt mehr als eines 😉
Ich nutze die nzyme-Umgebung jedoch auch gerne in Verbindung mit HAK5 Wifi Tetra/Pineapple/Mark VII, um zu visualisieren und zu erkennen, wie sich WLAN-Angriffe auf diese Art optisch auf dem Frequenzband darstellen und so selbst Angriffe besser erkennen zu können.
Danke für die Antwort. Also derselbe Grund, aus dem die Entwickler einen Pi 4 benutzen: Als Demo auf Conventions und für wirklich sicherheitskritische Infrastrukturen. Wobei man sich bei letzteren fragen sollte, ob WLAN die einzige Option ist. Aber manchmal geht es eben nicht anders. Bei mobilen Geräte auf dem Werksgelände zum Beispiel.
Soll das Ding doch zeitaufwendiger scannen. Im privaten und ländlichen Bereich ist mir das ziemlich egal. Bei meinen Dutzenden von Smart Home-Geräten wäre bei einem Deauth sowieso die Hölle los, das bekäme auch ein einzelner Stick mit. Wenn ein geklonter Hotspot auftaucht, ist es das gleiche Spiel und eher zeitunkritisch.
Ich würde sowieso zusätzlich meinen alten DWL-G132 verwenden, mit dem ich mit dem Powerbook 2004 „wargedrivet“ bin. 100 m durch Berlin fahren: Möööp, Bing, Bing, Bing, Bing, Bing, Möööp, Bing, Bing, Bing, Bing – das waren noch Zeiten, als fast niemand sein WLAN absicherte. 😀
Ein Probelauf auf meinem PiHole (Raspi 2b) war sehr ernüchternd. Da in Java geschrieben, ist nzyme ein Ressourcenfresser. Wenn man beim normalen Surfen bereits merkt, dass die DNS-Ausflösung nur noch schleppen vonstattengeht und dann einen Blick auf die Auslastung wirft, ist Nzyme schnell wieder deinstalliert.
Bei den aktuellen Preisen für Raspis sehe ich nicht ein, mir einen 3er oder 4er nur für Nyzme zu kaufen, ich werde mir in China eine TV-Box ordern und da Linux draufpacken (S905X3, 4 GB, 64 GB = 30 Euro). Die sollte es für den Zweck tun. Dazu noch ein 2.4/5 GHz Stick mit monitor-fähigen Chipset, sowie den alten Stick und ich sollte für 45 Euro ein weiteres Gadget mit fraglichem Gegenwert in meinem IT-Sammelsurium haben. Aber es ist halt cool und man hat wieder ein Stück mehr self monitoring betrieben, das man sich auf dem x-ten Screen anschauen kann. Passt schon.
Ich schweife abermals ab, sorry: Man hätte im Falle eines geklonten Hotspots eh schlechte Karten. Ganz real betrachtet kann man sich fragen, was man dann tun sollte. Da zum Beispiel bei mir fast alle smarten Gerätschaften fest verbaut sind, bliebe mir nur den Strom im Haus abzuschalten und zu warten, bis der Angreifer aufgibt.
Gut, ein Angriff auf ein Smarthome ergibt Sinn, wenn man WLAN-Kameras deaktivieren will, oder Schwachstellen in den verwendeten Geräten kennt, über die man Zugriff auf andere Geräte im Netz erlangen könnte. Eine Übernahme eines Google-Accounts – und damit letztlich auf den Rattenschwanz des digitalen Lebens des Opfers – ist auch denkbar. Deswegen sind meine Netze auch physikalisch getrennt und ich verwende spezielle Accounts für Cloud-Anbindungen. Man weiß ja eh nie genau, was man sich da ins Haus holt.
Nzyme gäbe im privaten Bereich also nur Sinn, wenn man es in seine smarte Alarmanlage integriert und bei Auffälligkeiten etwa die Außenbeleuchtung zur Abschreckung aktiviert. Einbrecher komme aber eher selten zu nachtschlafender Zeit. Doof. Also bleibt es bei einer Benachrichtigung an den Nutzer.
Aber klar: In Zeiten von Homeoffice (und massiven Lücken beim schnellen mobilen Internet) ist nicht der private Nutzer das Ziel, sondern die Firma. Man sollte also solche Angriffe nicht weniger ernst nehmen als andere Angriffsvektoren. Ottonormaluser wird aber heillos überfordert mit Nzyme-Meldungen sein.
Am Ende ist es also wie immer: Man schafft sich so ein (Sicherheits-) Gadget an, versenkt eine große Menge an Zeit, Geld und Strom darin, um primär seiner Neugier nachzugeben und vielleicht(!) in dunklen Nächten etwas besser schlafen zu können. 🙂 Männer und ihre sinnfreien Spielzeuge.
Ich bestelle gleich mal die Brocken bei Ali.
Ob es Detection-Systeme auch für 433/868 MHz gibt? Wenn Nzyme das noch könnte …
Zitat: „…Soll das Ding doch zeitaufwendiger scannen…“
Das Problem ist nicht, das es länger dauert. Das Risiko besteht eher darin, das Sicherheitsvorkommnisse schlichtweg nicht protokolliert werden, da der Stick zu dem Zeitpunkt einfach auf einer anderen Frequenz/Kanal war. Ich muss ja nicht 10min Deauth-Frames senden, so dass es auch wirklich jeder mitbekommt, sondern kann ja auch gezielt ein Endgerät angreifen. Dann bleibt ein solcher Angriff unter Umständen unter dem Radar.
Für die Überwachung von 433/868 gibt es durchaus passende Hardware, schau dir mal den LimeSDR an. Allerdings ist das dann weniger Klicki-Bunti 😉
Ja, das ist klar. Deswegen schrieb ich ja: bei einem Deauth wäre bei mir die Hölle im WLAN los. Da würden eine Menge Geräte verschwinden und ich würde darüber informiert werden. Ich betreibe keine WLAN-Cams, nur PoE-Cams – eben aus diesem Grunde.
Vergiss auch nicht, dass ich nur aus der Sicht eines Smarthome-Besitzers schreibe.
350 Dollar für den LimeSDR? Ja, nee, ist klar. 🙂 Das ist im Privatbereich für Otto Normaluser nicht darstellbar.
Zur Not überwacht man eben per Script seine Bridge und bekommt so zumindest einen blockierenden Flood mit. Das kostet nichts.
Obendrein ist dieser LimeSDR komplett oversized und die Zielgruppe sehe ich persönlich eher im professionellen Security-Bereich oder bei Amateurfunkern mit viel Zeit. 🙂
Ich hasse Mausschubsen bei solchen Anwendungen. Ein Smarthome muss auch einen hohen WAF haben. Würde Nzyme noch MQTT-Meldungen absetzen, wäre das eine feine Sache. Kann es aber nicht. So müssen eben E-Mails reichen.