AccessScope Bedienungsanleitung

Diese Anleitung zeigt, wie Sie mit dem Diagnosewerkzeug in den Zugriffsprotokollen Ihres Servers Angriffsversuche finden, jeweils mit den Protokollzeilen als Beleg. Zuerst wird die Diagnose in der Oberfläche beschrieben, die Verwendung per Befehl steht gesammelt in Kapitel 8.

1. Über AccessScope

AccessScope ist ein Diagnosewerkzeug, das die Protokolle liest, die Ihr Webserver und Ihr SSH-Server ohnehin schon schreiben, und darin nach Angriffsversuchen sucht. Zu jedem Fund zeigt es die Protokollzeilen, auf denen er beruht. Es eignet sich für alle, die einen eigenen Server betreiben und prüfen möchten, ob in den Protokollen verdächtige Zugriffe stehen.

Die Protokolle werden nur gelesen. AccessScope verändert oder löscht sie nicht, blockiert keine Verbindungen und erhöht keine Rechte. Die Diagnose selbst nutzt weder ein LLM noch das Netzwerk.

Beim Mac ist AccessScope im DMG von RoamSwitch enthalten, bei Linux in den deb-, rpm- und tarball-Paketen von RoamSwitch. Es ist ein eigenständiges Werkzeug neben RoamSwitch und steht unter der Apache License 2.0. Zum Starten wählen Sie am Mac das App-Symbol, unter Linux in der App-Liste den Eintrag „AccessScope“.

Gespeicherte Dateien

AccessScope speichert automatisch die Einstellungen, die Liste der gefundenen Protokolle, die Ausschlussregeln und die Aufzeichnung für den Vergleich mit dem letzten Lauf. Alles liegt unter ~/.config/accessscope/ und ist nur für Sie les- und schreibbar.

Updates

Der Mac verbindet sich nur dann mit lafine.net, wenn Sie in den Einstellungen unter „Updates“ auf „Nach Updates suchen“ klicken. Dabei werden keine Informationen über diesen Rechner oder die Protokolle gesendet, und heruntergeladene Dateien werden erst nach einer Signaturprüfung installiert. Unter Linux gibt es keine Update-Funktion in der App, dort aktualisieren Sie über die Paketverwaltung.

2. Die erste Diagnose

1. Wählen Sie die Protokolle aus. Am einfachsten geht das mit „Protokolle auf diesem Rechner suchen“. Dabei werden Protokolle von nginx, Apache, SSH und anderen automatisch gesucht und unter „Auf diesem Rechner gefundene Protokolle“ aufgelistet. Wenn Sie den Ort kennen, wählen Sie ihn mit „Dateien wählen“ oder „Ordner wählen“ aus oder ziehen die Dateien oder Ordner auf das Fenster.
2. Wählen Sie den „Zeitraum“. Voreingestellt ist „Letzte 7 Tage“, möglich sind auch „Letzte 24 Stunden“, „Letzte 30 Tage“ und „Alle“. Der Zeitraum wird von jetzt an zurückgerechnet. Für ältere Protokolle wählen Sie also „Alle“.
3. Klicken Sie auf „Diagnose starten“. Der Fortschritt wird mit „Protokolle werden gelesen“ und „Analyse läuft“ angezeigt, und am Ende öffnet sich das Ergebnis.

3. Lesbare Protokolle und wo gesucht wird

Die Art eines Protokolls wird automatisch am Inhalt erkannt. Auch mit gzip komprimierte, rotierte Protokolle lassen sich direkt lesen. Wenn Sie einen Ordner wählen, werden alle darin liegenden Dateien gelesen, die wie Protokolle aussehen.

„Protokolle auf diesem Rechner suchen“ prüft die Standardorte und die Protokollorte, auf die die Konfigurationsdateien des Webservers zeigen. Aufgelistet werden nur Protokolle, bei denen bestätigt ist, dass sie sich lesen lassen.

Docker-Container

Wenn Sie „Docker-Container auch prüfen“ ankreuzen, werden auch die Docker-Protokolle dieses Rechners einbezogen. Vor der Diagnose zeigt ein Bestätigungsfenster den auszuführenden Befehl und die betroffenen Container, und gelesen wird erst, wenn Sie auf „Zustimmen und diagnostizieren“ klicken. Es wird nur gelesen, Rechte werden nicht erhöht.

Protokolle mit einem LLM suchen (optional)

Wenn nichts gefunden wird, können Sie mit „Auch mit einem LLM suchen“ ein LLM nach den Orten suchen lassen. Übergeben werden nur Fakten zur Umgebung, etwa die Namen laufender Server und die Namen von Dateien in /var/log, aber nie der Inhalt der Dateien. Die Vorschläge werden erst auf Lesbarkeit geprüft und dann mit entferntem Häkchen angezeigt. Die Einstellungen finden Sie in Kapitel 7.

4. Ergebnisse lesen

Nach der Diagnose können Sie die Ergebnisse in vier Tabs ansehen.

Erkennungen verstehen

Eine Erkennung wird mit ihrem Namen angezeigt, zum Beispiel „SQL-Injection-Versuche“, und hat einen Schweregrad (Hoch, Mittel, Niedrig) sowie eine Konfidenz. Die Konfidenz zeigt, wie viel sich allein aus dem Protokoll sagen lässt.

• Bestätigt heißt, dass sich die Aussage allein aus dem Protokoll belegen lässt.
• Wahrscheinlich heißt, dass der Versuch mit hoher Wahrscheinlichkeit stattgefunden hat.
• Hypothese heißt, dass sich die Aussage allein mit dem Protokoll nicht prüfen lässt.

Wenn Sie die „Belegzeilen“ öffnen, sehen Sie die Protokollzeilen, auf denen die Erkennung beruht, unverändert. Sie sind normalerweise eingeklappt. Lesen Sie zuerst Namen und Begründung und öffnen Sie nur das, was Sie interessiert.

Das Gesamtrisiko (0 bis 100) ist ein Richtwert, gewichtet nach Schweregrad und Konfidenz. Es wächst nicht allein durch eine hohe Anzahl und wird nicht „Hoch“, solange es keine einzige Erkennung mit hohem Schweregrad gibt. Es ist keine Wahrscheinlichkeit, nehmen Sie es also als Orientierung.

5. Weniger Treffer anzeigen

Ausschlussregeln

Erkennungen, deren Auftreten Sie schon kennen, etwa von der IP Ihres Büros, von Verfügbarkeitsprüfungen oder von Ihren eigenen Schwachstellenscans, können Sie aus dem Bericht herausnehmen. Ausgeschlossene Erkennungen werden nicht verworfen, ihre Anzahl bleibt mit Begründung erhalten.

1. Klicken Sie im Tab „Erkennungen“ neben der IP einer Erkennung auf „Diese IP ausschließen…“.
2. Geben Sie eine Begründung ein und klicken Sie auf „Zu den Ausschlussregeln hinzufügen“. Die Begründung bleibt im Bericht erhalten.
3. Prüfen Sie den Inhalt im Bestätigungsdialog und bestätigen Sie ihn. Die Regel gilt ab der nächsten Diagnose.

Unter „Ausschlussregeln“ in den Einstellungen sehen Sie die aktuell gültigen Regeln. Die Anzeige dient nur zur Ansicht und lässt sich dort nicht bearbeiten. Regeln mit genaueren Bedingungen schreiben Sie in eine Datei im Einstellungsordner (suppress.toml), die Schreibweise steht in Kapitel 8. Erkennungen mit dem Schweregrad „Hoch“ werden auch durch einen Ausschluss nicht herausgenommen und bleiben im Bericht.

Vergleich mit dem letzten Lauf

Wenn Sie dieselbe Kombination von Protokollen mehrmals nacheinander diagnostizieren, wird mit der letzten Aufzeichnung verglichen, und neu aufgetretene Erkennungen erhalten die Markierung „Neu“. Mit dem Häkchen bei „Nur neue“ im Tab „Erkennungen“ zeigen Sie nur die neuen an. Beim ersten Lauf gilt alles als neu. In die Aufzeichnung gelangen nur der Fingerabdruck (Hash) der Erkennung, die Art, der Schweregrad, die Anzahl und die Zeit, aber keine Texte aus dem Protokoll.

6. Ergebnisse exportieren

Mit den Schaltflächen oberhalb der Ergebnisse können Sie die Ergebnisse mitnehmen.

Bei „Exportieren…“ stehen für die Sperrliste die Formate fail2ban-ip, nftables, ipset, nginx-deny, apache-require und csv zur Wahl. Die Liste der Erkennungen lässt sich als CSV, SARIF oder JSON exportieren.

Bei der Sperrliste können Sie unter „Aufzunehmen“ zwischen „Standard“, „strenger“ und „weiter“ wählen, und die Anzahl der exportierten IPs wird vor dem Speichern angezeigt. IPs offizieller Crawler und IPs, die unter eine Ausschlussregel fallen, werden nie aufgenommen.

7. Analyse mit einem LLM (optional)

Diese Funktion lässt ein LLM die Diagnoseergebnisse in Text zusammenfassen. Sie ist standardmäßig ausgeschaltet. Zum Nutzen kreuzen Sie in den Einstellungen unter „LLM-Anbindung“ die Option „Analyse mit einem LLM aktivieren“ an, wählen das „Zu verwendende LLM“ und klicken auf „Speichern“. Zur Wahl stehen claude, opencode, codex und agy, soweit der jeweilige Befehl auf dem Rechner installiert ist.

Was gesendet wird

• Rohe Protokolle werden nicht gesendet. Gesendet werden Statistiken und die Fakten der Erkennungen sowie je Erkennung bis zu 3 Protokollzeilen als Beleg (höchstens 300 Zeichen pro Zeile).
• Geheimnisse wie Schlüssel, Tokens und Passwörter sowie E-Mail-Adressen werden vor dem Senden unkenntlich gemacht.
• IPs werden in entschärfter Form übergeben, etwa als 203[.]0[.]113[.]9. Wenn Sie „Keine echten IPs senden (Pseudonyme verwenden)“ ankreuzen, werden sie durch Pseudonyme wie ip-001 ersetzt.

Mit „Genau anzeigen, was gesendet wird“ im Tab „Mit LLM analysieren“ sehen Sie den gesamten Text, der gesendet würde. Dabei wird nichts gesendet. Erst wenn Sie auf „Mit LLM analysieren“ klicken, wird gesendet.

• Den Inhalt von Protokollen kann ein Angreifer selbst schreiben. AccessScope meldet Zeichenfolgen, die wie Anweisungen an eine KI aussehen, als Erkennung und zeigt die Ausgabe des LLM als nicht vertrauenswürdiges Zitat an. Ein LLM kann Erkennungen auch schwerwiegender deuten, als sie sind. Prüfen Sie Schlussfolgerungen daher anhand der Protokollzeilen als Beleg.
• claude und opencode startet AccessScope mit gesperrten Werkzeugen (Befehle ausführen und Dateien lesen). Bei codex und agy lassen sich die Werkzeuge nicht sperren, deshalb müssen Sie das Häkchen bei der Bestätigung in den Einstellungen setzen. Die LLM-Analyse lässt sich auch als root verwenden, doch das LLM läuft dann mit Root-Rechten; ein unprivilegierter Benutzer wird empfohlen (in den Einstellungen erscheint ein Hinweis, solange die App als root läuft).

8. Verwendung per Befehl

In Umgebungen nur mit Befehlen, etwa der Server Edition, oder wenn Sie die Diagnose regelmäßig mit cron laufen lassen möchten, nutzen Sie den Befehl accessscope. Er verwendet dieselbe Engine wie die Oberfläche und findet daher dieselben Erkennungen.

accessscope discover
accessscope scan --auto --since 7d --report report.md
accessscope scan /var/log/nginx/access.log /var/log/auth.log

Täglich per cron ausführen

accessscope scan --auto --since 24h --since-last --new-only --fail-on medium

Zeigt nur Erkennungen, die im letzten Lauf nicht vorkamen, und endet nur dann mit dem Exitcode 3, wenn neue Erkennungen mindestens mittleren Schweregrad haben. Die Diagnose ohne --llm läuft auch als root.

So schreiben Sie suppress.toml

Ausschlussregeln schreiben Sie in ~/.config/accessscope/suppress.toml. Wenn es diese Datei gibt, wird sie automatisch gelesen.

[[rule]]
reason  = "office"
ip      = ["203.0.113.0/28"]
expires = 2027-03-31

[[rule]]
reason      = "uptime monitor"
ua_prefix   = ["Mozilla/5.0 (compatible; UptimeRobot"]
path_prefix = ["/healthz"]

• Eine Regel trifft auf Anfragen zu, die allen angegebenen Einträgen entsprechen. reason ist Pflicht und erscheint in jedem Bericht. Regeln, deren expires überschritten ist, werden nicht mehr angewendet.
• Erkennungen mit dem Schweregrad „Hoch“ werden nur ausgeschlossen, wenn die Regel allow_high = true enthält.
• User-Agent und Pfad sind Werte, die der Client selbst schreiben kann. Eine Regel, die nur darüber und ohne IP festgelegt ist, kann Erkennungen wie Angriffe, Authentifizierung oder Web-Shells nicht ausschließen.

9. Was nicht möglich ist

• Sichtbar sind nur die Fakten, die in den Protokollen stehen. Nicht erkennbar sind der Inhalt von Anfragen, der Inhalt von Antworten, der interne Zustand von Anwendungen und Zeiträume, die durch Rotation verschwunden sind. Keine Erkennung bedeutet nicht, dass alles sicher ist.
• Eine Erkennung bedeutet, dass es einen Versuch gab, und ist kein Beweis für einen Erfolg. Der User-Agent ist eine Selbstauskunft und lässt sich fälschen.
• Verknüpfungen über mehrere Protokolle hinweg beruhen allein darauf, dass die Adresse gleich ist. Hinter NAT oder einem Proxy erscheinen unbeteiligte Personen unter derselben Adresse. Interne Adressen (ein Reverse-Proxy oder ein Docker-Gateway) stehen für viele Clients zugleich und werden deshalb nicht in eine Verknüpfung aufgenommen. Eine Verknüpfung ohne Hinweis auf Erfolg erhält die Schwere „niedrig“.
• „Anmeldungen von einer ungewohnten Quelle“ heißt, dass die Quelle für dieses Protokoll ungewohnt ist, und nicht unbedingt, dass die Anmeldung unberechtigt war. „Abweichungen vom Üblichen“ zeigen nur eine Veränderung und sind nicht zwingend ein Angriff.
• Die Protokolle von AWS ALB und CloudFront wurden mit Zeilen getestet, die nach den Definitionen in der AWS-Dokumentation erstellt wurden, nicht mit echter AWS-Ausgabe.

10. Wenn etwas nicht klappt

Unter „Derzeit nicht lesbare Protokolle“ erscheint etwas

Das ist die Anzeige bei fehlenden Rechten. AccessScope liest nicht mit erhöhten Rechten. Gehen Sie auf eine der folgenden Arten vor.

• Bei Protokolldateien starten Sie AccessScope mit einem Benutzer, der die nötigen Rechte hat, oder wählen eine Kopie des Protokolls mit „Dateien wählen“ aus.
• Für journald unter Linux starten Sie AccessScope als root oder als Benutzer der Gruppen adm, systemd-journal oder wheel.
• Für das Unified Log von macOS starten Sie AccessScope als Benutzer der Gruppe admin.

Es erscheint „Auf diesem Rechner wurden keine diagnostizierbaren Protokolle gefunden“

Der Grund wird als Satz angezeigt, zum Beispiel „Es gibt keine Webserver-Protokolle (Apache, nginx usw.)“. Am Mac erscheint bei fehlenden SSH-Einträgen „Die Remote-Anmeldung (SSH) ist möglicherweise ausgeschaltet“. Mit den angezeigten Optionen „Dateien wählen“, „Mit einem LLM suchen“ und „Anderen Ort angeben“ können Sie den nächsten Schritt versuchen. Wo gesucht wurde, sehen Sie, wenn Sie das eingeklappte „Ausführliches Suchergebnis“ öffnen.

Es erscheint „Die Docker-Protokolle konnten nicht gelesen werden“

Entweder läuft Docker nicht, Docker wurde nicht gefunden, es fehlen Rechte oder Docker hat einen Fehler gemeldet. Fehlen Rechte, starten Sie AccessScope mit einem Benutzer, der Docker verwenden darf. AccessScope liest nicht mit erhöhten Rechten neu und verlangt oder empfiehlt auch nicht, der Gruppe docker beizutreten, denn die Rechte der Gruppe docker entsprechen denen von root auf dem Host.

Es erscheint „Nicht als Protokoll lesbar“

Das wird angezeigt, wenn sich aus der gewählten Datei keine einzige Zeile auswerten ließ. Die Datei wird nicht diagnostiziert und nirgendwohin gesendet. Prüfen Sie, ob es eine unterstützte Protokollart ist, und wählen Sie die Datei neu aus.

„Mit LLM analysieren“ lässt sich nicht anklicken

In der Nähe der Schaltfläche steht der Grund. Bei „Die LLM-Anbindung ist deaktiviert“ aktivieren Sie sie in den Einstellungen. Bei „Es ist kein LLM ausgewählt“ wählen Sie dort eines aus. Auch wenn Sie als root gestartet haben oder der Befehl des gewählten LLM nicht auf dem Rechner installiert ist, lässt sich die Funktion nicht nutzen.

Als Zugriffsquelle erscheinen nur IPs von Proxys

In Protokollen hinter einem Reverse-Proxy oder CDN kann als Zugriffsquelle die IP des Proxys stehen. In der Voreinstellung „Automatisch“ wird die Client-IP nur bei Zeilen aus X-Forwarded-For bestimmt, deren aufgezeichnete Quelle eine interne Adresse ist, etwa ein Reverse-Proxy oder ein Docker-Gateway. Zeilen, die direkt von außen kamen, behalten die aufgezeichnete Quelle. Da der Header gefälscht werden kann, gilt eine so bestimmte IP nie als geprüfter Crawler. Zum Abschalten wählen Sie in den Einstellungen unter „Analyse“ die Option „Nicht verwenden“. Es lassen sich auch die erste Adresse von rechts, die kein vertrauenswürdiger Proxy ist, oder die Adresse ganz links wählen; Clients können diesen Wert verändern, verwenden Sie diese Optionen also nur hinter einem selbst verwalteten, vertrauenswürdigen Zwischenglied. Die Einstellung gilt ab der nächsten Diagnose.