Log-Dateien analysieren: Wer greift auf deinen Pi zu?

Log-Dateien analysieren: Wer greift auf deinen Pi zu? Diese Frage ist nicht nur für professionelle Administratoren relevant, sondern gerade im Heimnetz ein entscheidender Sicherheitsfaktor. Ein Raspberry Pi läuft oft 24/7, stellt Dienste bereit (SSH, Web-Apps, Docker-Container, Smart-Home-Software) und wird dadurch früher oder später Ziel automatisierter Scans und Login-Versuche. Ohne Log-Analyse bemerken Sie Angriffe, Fehlkonfigurationen oder ungewöhnliche Zugriffe häufig erst dann, wenn etwas nicht mehr funktioniert. Mit einer sauberen Auswertung von Systemprotokollen, SSH-Logs, Webserver-Logs und Firewall-Ereignissen erkennen Sie Muster: von harmlosen Portscans über Brute-Force-Versuche bis hin zu legitimen Zugriffen aus dem eigenen Netz. In diesem Artikel erfahren Sie praxisnah, welche Log-Dateien unter Raspberry Pi OS (Debian-basiert) besonders wichtig sind, wie Sie Zugriffe sicher zuordnen, welche Werkzeuge (journalctl, grep, awk, fail2ban) Ihnen helfen und wie Sie aus Zahlen und Mustern konkrete Schutzmaßnahmen ableiten. Ziel ist ein verständlicher, wartbarer Ablauf, mit dem Sie zuverlässig beantworten können, wer wann und wie auf Ihren Pi zugegriffen hat.

Warum Log-Analyse auf dem Raspberry Pi so wichtig ist

Logs sind die „Beweisspur“ eines Systems. Sie zeigen nicht nur erfolgreiche Anmeldungen, sondern auch Fehlversuche, Konfigurationsprobleme, Abstürze und ungewöhnliche Netzwerkaktivität. Besonders beim Raspberry Pi sind typische Szenarien:

• SSH ist aktiv: Häufiger Einstiegspunkt für Angreifer, wenn er aus dem Internet erreichbar ist.
• Webdienste laufen: Nginx/Apache, Home Assistant, Nextcloud, Admin-Oberflächen oder APIs.
• Container und Dienste: Docker-Stacks erzeugen eigene Logs, die bei Fehlern oder Zugriffen entscheidend sind.
• Heimnetz-Dynamik: Viele Geräte, wechselnde IPs, Gäste-WLAN, VPN-Zugriffe.

Wenn Sie Log-Analyse als Routine etablieren, erkennen Sie Probleme früher, sparen Zeit bei der Fehlersuche und können Sicherheitsmaßnahmen gezielt dort verstärken, wo sie wirklich nötig sind.

Grundlagen: Wo Raspberry Pi OS Logs speichert

Raspberry Pi OS basiert auf Debian, daher finden Sie klassische Log-Dateien unter /var/log und parallel die systemd-Journale. In modernen Debian- und Raspberry-Pi-OS-Versionen ist journalctl häufig die zentrale Stelle, weil viele Dienste ihre Ausgaben ins systemd-Journal schreiben. Dennoch bleiben textbasierte Log-Dateien wichtig.

• System- und Auth-Logs: /var/log/auth.log (Anmeldungen, sudo, SSH), teils auch /var/log/syslog
• Kernel-Meldungen: journalctl -k oder je nach Setup /var/log/kern.log
• Webserver: Nginx/Apache-Access- und Error-Logs (z. B. /var/log/nginx/)
• Firewall: Je nach Tool (ufw/nftables) in Journal oder separate Dateien
• Anwendungslogs: Docker-Container, Python-Apps, Home-Server-Dienste

Hilfreich als offizieller Einstieg: die systemd-Dokumentation zu Journal und journalctl sowie Debian-nahe Grundlagen. Eine kompakte Referenz ist die manpage zu journalctl sowie die systemd-Journal-Dokumentation: systemd-journald.

Erste Quick-Checks: In 5 Minuten einen Überblick bekommen

Bevor Sie tief einsteigen, machen Sie einen kurzen Sicherheits- und Aktivitätscheck. Diese Schritte sind bewusst einfach und liefern sofort verwertbare Hinweise.

• Letzte Logins: last zeigt erfolgreiche Logins und Reboots (Daten aus wtmp).
• Aktuelle Sessions: who und w zeigen, wer gerade angemeldet ist.
• SSH-Events im Journal: journalctl -u ssh --since "24 hours ago"
• Auth-Log filtern: grep "sshd" /var/log/auth.log | tail -n 100

Wenn Sie feststellen, dass regelmäßig viele fehlgeschlagene SSH-Logins auftauchen, ist das ein sehr typisches Zeichen für automatisierte Scans. Das ist nicht automatisch ein „Einbruch“, aber ein klarer Hinweis, dass Hardening (Schlüssel-Login, Fail2Ban, Firewall, VPN) Priorität haben sollte.

SSH-Zugriffe sauber auswerten: Erfolgreich vs. fehlgeschlagen

SSH ist der häufigste Remote-Zugang zum Pi. Deshalb lohnt sich eine gezielte Auswertung. In /var/log/auth.log (oder im Journal) finden Sie Einträge, die grob in drei Gruppen fallen:

• Erfolgreiche Anmeldungen: „Accepted password“ oder „Accepted publickey“
• Fehlversuche: „Failed password“, „Invalid user“
• Technische Hinweise: Verbindungsabbrüche, Schlüsselprobleme, „Connection closed“

Beispiel: Erfolgreiche SSH-Logins finden

In einer klassischen Logdatei erkennen Sie erfolgreiche Logins oft über „Accepted“. Ein typisches Muster ist: Benutzername, Authentifizierungstyp, Quell-IP. Sie können mit einfachen Filtern beginnen, zum Beispiel:

grep "Accepted" /var/log/auth.log

Für systemd-journalbasierte Systeme ist der Dienstfilter häufig noch bequemer:

journalctl -u ssh | grep "Accepted"

Beispiel: Brute-Force und „Invalid user“ erkennen

Automatisierte Angriffe versuchen oft Standardnamen wie „admin“, „pi“, „root“ oder zufällige Accounts. Das erscheint in Logs als „Invalid user“. Ein schneller Check:

grep "Invalid user" /var/log/auth.log | tail -n 50

Wenn Sie viele unterschiedliche Usernamen von vielen IPs sehen, ist das typisch für Internet-Scanning. Wenn Sie hingegen immer wieder dieselbe IP sehen, kann es auch ein falsch konfigurierter Client oder ein legitimer Nutzer mit Tippfehlern sein.

IP-Adressen zuordnen: Heimnetz, VPN, Provider und Standort

Eine IP-Adresse ist der wichtigste Ankerpunkt, um Zugriffe einzuordnen. Im Heimnetz sind private IP-Bereiche (z. B. 192.168.x.x, 10.x.x.x) normal. Externe Zugriffe kommen mit öffentlichen IPs. Wichtig: Eine IP allein beweist keine Identität, aber sie hilft bei der Klassifikation.

• Private IP: meist Heimnetz oder VPN-Subnetz, je nach Setup.
• Öffentliche IP: Internetzugriff; kann Provider, Mobilfunk oder ein Rechenzentrum sein.
• Rechenzentrums-IP: häufig Bots, Scanner oder VPS; kann aber auch Ihr eigener Cloud-Server sein.

Für eine grobe, manuelle Einschätzung können Whois- und IP-Informationen helfen. Nutzen Sie dafür seriöse Quellen und behandeln Sie Geolokalisierung als Näherung, nicht als Beweis. Als neutrale Referenz ist beispielsweise RIPE (für Europa) hilfreich: RIPE NCC.

Webserver-Logs: Wer greift auf deine Dienste zu?

Wenn auf Ihrem Pi ein Webserver läuft (Nginx/Apache), sind Access-Logs die zentrale Quelle für HTTP/HTTPS-Zugriffe. Dort sehen Sie Quell-IP, Zeit, angefragte Pfade, Statuscodes und User-Agent. Das ist ideal, um Angriffe auf Weboberflächen (Admin-Panels, Login-Seiten, APIs) zu erkennen.

• Nginx: oft /var/log/nginx/access.log und /var/log/nginx/error.log
• Apache: häufig /var/log/apache2/access.log und /var/log/apache2/error.log

Statuscodes verstehen: 200, 401, 403, 404, 500

• 200/302: erfolgreicher Zugriff oder Redirect (bei Logins häufig).
• 401: Authentifizierung nötig/fehlgeschlagen (z. B. Basic Auth).
• 403: Zugriff verboten (Firewall/ACL/Block).
• 404: Datei nicht gefunden; bei Angriffen oft viele 404 auf bekannte Pfade (z. B. /wp-admin).
• 5xx: Serverfehler; kann Fehlkonfiguration, Absturz oder Überlast anzeigen.

Wenn Ihr Pi gar kein WordPress betreibt, aber Sie sehen massenhaft Anfragen auf /wp-login.php, ist das ein klassisches Muster automatisierter Scans.

Journalctl richtig nutzen: Zeiträume, Dienste und Prioritäten

Mit journalctl können Sie Logs sehr präzise filtern. Das ist besonders hilfreich, wenn Sie wissen, welches Problem oder welcher Dienst betroffen ist. Drei Filter sind in der Praxis entscheidend: Zeitraum, Dienst, Priorität.

• Zeitraum: --since und --until (z. B. „today“, „yesterday“, „2026-02-01“).
• Dienst: -u ssh, -u nginx, -u docker usw.
• Priorität: -p warning, -p err für Fehlerfokus.

Die Details zur Syntax finden Sie zuverlässig in der journalctl manpage.

Häufige Muster: Was in Logs „verdächtig“ ist

Nicht jeder ungewöhnliche Eintrag ist ein Angriff. Dennoch gibt es wiederkehrende Muster, bei denen Sie genauer hinschauen sollten:

• Viele fehlgeschlagene SSH-Logins in kurzer Zeit: typisches Brute-Force-Muster.
• Viele verschiedene Usernamen von einer IP: Credential-Stuffing oder Rateversuche.
• Viele 404 auf typische Admin-Pfade: Webscanner versuchen bekannte Exploit-Pfade.
• Login-Erfolge zu ungewöhnlichen Zeiten: außerhalb Ihrer üblichen Nutzung.
• Neue Dienste/Ports: Logeinträge, die auf frisch gestartete Services hindeuten, die Sie nicht kennen.

Bewerten Sie Auffälligkeiten immer im Kontext: Läuft ein VPN? Haben Sie Gäste? Hat Ihr ISP eine neue IP vergeben? Gab es ein Update, das Dienste neu startet?

Aus Logs Kennzahlen machen: Wie Sie Angriffsintensität bewerten

Eine strukturierte Bewertung hilft, nicht in Einzelereignissen zu versinken. Zwei einfache Kennzahlen sind besonders nützlich: Fehlversuche pro Stunde und Unique IPs pro Tag. Damit sehen Sie, ob ein Problem „sporadisch“ ist oder dauerhaft eskaliert.

Fehlversuche pro Stunde berechnen (MathML)

Wenn Sie in einem Zeitraum F fehlgeschlagene Logins zählen und der Zeitraum t Stunden beträgt, ergibt sich:

$\mathrm{Rate}=\frac{F}{t}$

Beispiel: 240 Fehlversuche in 6 Stunden:

$240/6=40$

Eine Rate von 40 Fehlversuchen pro Stunde ist für offene SSH-Ports im Internet nicht ungewöhnlich, aber ein Hinweis, dass Schutzmechanismen (z. B. Schlüssel-Login und Fail2Ban) dringend sind.

Automatisches Blocken mit Fail2Ban: Auswertung trifft Gegenmaßnahme

Fail2Ban ist ein klassisches Werkzeug, das Logdateien analysiert und bei wiederholten Fehlversuchen automatisch IPs sperrt. Besonders für SSH und Web-Login-Formulare ist das sehr effektiv. Wichtig: Fail2Ban ersetzt keine saubere SSH-Härtung, aber es reduziert Lärm und Angriffsfläche erheblich.

• Vorteil: Sperrt wiederholte Fehlversuche zeitweise oder dauerhaft.
• Praxisnutzen: Aus Logs werden Aktionen; Sie müssen nicht manuell blocken.
• Grenze: Verteilte Angriffe über viele IPs bleiben möglich, aber deutlich erschwert.

Eine zuverlässige Referenz ist die Fail2Ban-Dokumentation: Fail2Ban Wiki.

Logrotate und Aufbewahrung: Damit Logs nützlich bleiben und nicht das System füllen

Logs sind nur hilfreich, wenn sie verfügbar sind. Gleichzeitig dürfen sie Ihren Speicher nicht füllen, insbesondere bei microSD-basierten Systemen. Dafür gibt es Logrotation und definierte Aufbewahrungsfristen. In Debian-Umgebungen ist dafür oft logrotate zuständig.

• Rotation: Logs werden regelmäßig umbenannt/komprimiert und neu begonnen.
• Retention: Nur die letzten X Rotationen werden behalten.
• Kompression: Spart Platz, bewahrt Historie.

Eine solide Referenz ist die logrotate-Dokumentation und die manpage: logrotate manpage.

Docker- und App-Logs: Wenn Dienste nicht in /var/log auftauchen

Viele Raspberry-Pi-Projekte laufen in Containern. Dann liegen Logs oft nicht in klassischen Dateien, sondern werden über den Docker-Logging-Mechanismus verwaltet. Zudem schreiben Anwendungen manchmal in eigene Verzeichnisse oder nur ins Journal.

• Docker Logs: Container schreiben standardmäßig in einen Logging-Driver; Auswertung erfolgt über Docker-Tools.
• Eigene Logpfade: Manche Stacks mappen Logs in Volumes (z. B. /opt/app/logs).
• systemd Services: Selbst erstellte Services loggen oft ins Journal.

Wenn Sie containerisierte Dienste betreiben, planen Sie früh eine Logstrategie: Wo sollen Logs liegen, wie werden sie rotiert, wie lange werden sie behalten und wie überwachen Sie Ausreißer (z. B. stark steigende Fehlerraten)?

Praktischer Workflow: So bauen Sie eine Routine zur Zugriffsanalyse

Eine gute Routine ist kurz, wiederholbar und liefert klare Ergebnisse. Ein bewährter Ablauf sieht so aus:

• Täglich (2–5 Minuten): SSH-Fehlversuche und erfolgreiche Logins der letzten 24 Stunden prüfen (auth.log/journal).
• Wöchentlich (10 Minuten): Webserver-Statuscodes prüfen (Top 404, Top IPs, ungewöhnliche User-Agents).
• Monatlich (20 Minuten): Retention/Rotation prüfen, Fail2Ban-Statistiken kontrollieren, Firewall-Regeln reviewen.
• Nach Änderungen: Nach Updates oder neuen Services gezielt Logs prüfen (Start/Fehler/Ports).

Wenn Sie den Pi von außen erreichbar machen, sollte diese Routine deutlich strenger sein. In diesem Fall sind zusätzlich VPN-Ansätze sinnvoll, um SSH und Admin-UIs gar nicht erst öffentlich zu exponieren.

Datenschutz und Log-Inhalte: Was Sie aufbewahren sollten und was nicht

Logs enthalten Metadaten, die in Summe sehr aussagekräftig sein können (IP-Adressen, Zeitpunkte, genutzte Endpunkte). Halten Sie die Aufbewahrung zweckgebunden und begrenzt:

• Minimieren: Nur so lange speichern, wie Sie es für Diagnose und Sicherheit benötigen.
• Schützen: Logs sind sensibel; Zugriffsrechte restriktiv setzen.
• Weitergabe vermeiden: Wenn Sie Logs in Foren posten, anonymisieren Sie IPs, Hostnamen und Tokens.

Weiterführende Informationsquellen (Outbound-Links)

• journalctl manpage (Filter, Zeiträume, Dienste)
• systemd-journald Dokumentation (Journal-Hintergrund)
• Fail2Ban Wiki (automatisches Blocken anhand von Logs)
• logrotate manpage (Rotation und Aufbewahrung)
• RIPE NCC (IP-/Whois-Kontext für Europa)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.