Ein PHP-Dashboard, das rohe WAF-Logs in verwertbare Informationen verwandelt: Echtzeit-Risikobewertung, geografische Anreicherung und automatische IP-Sperrung über firewalld — ohne zusätzliche Infrastruktur.

Jede Webanwendung, die dem öffentlichen Internet ausgesetzt ist, erhält innerhalb weniger Minuten nach der Inbetriebnahme einen konstanten Strom automatisierter Anfragen: Schwachstellen-Scanner auf der Suche nach bekannten Exploits, Bots die Inhalte abgreifen, Brute-Force-Versuche gegen Login-Formulare und Aufklärungsanfragen, die die Struktur der Website kartieren. Die Standardantwort auf diese Realität ist der Einsatz einer Web Application FirewallEine WAF (Web Application Firewall) ist eine Sicherheitsschicht zwischen dem Internet und einer Webanwendung, die HTTP-Traffic prüft und bösartige Anfragen anhand konfigurierbarer Regeln blockiert. — einer WAF — die den Datenverkehr nach vordefinierten Regeln filtert. Aber eine WAF allein erzeugt Daten, kein Verständnis. Die Logs häufen sich an, der Speicher wächst, und in den meisten Fällen schaut niemand hinein, bis bereits etwas schiefgegangen ist.

Dies ist das Problem, das ich lösen wollte. SecureLog ist ein WAF-Dashboard, das ich entworfen und gebaut habe, um rohe HTTP-Log-Daten in operative Intelligence zu verwandeln: ein System, das nicht nur anzeigt, was auf der Web-Infrastruktur passiert, sondern es analysiert, bewertet und — wenn die Beweise es rechtfertigen — autonom handelt, indem es bösartige IP-Adressen auf Firewall-Ebene sperrt.

In diesem Artikel beschreibe ich die Architektur, die Überlegungen hinter den Designentscheidungen und wie jede Komponente zusammenwirkt, um ein geschlossenes Sicherheitsüberwachungssystem zu bilden.

Das Problem: Logs ohne Kontext

Ein typischer LAMP/LEMPLAMP steht für Linux, Apache, MySQL, PHP. LEMP ersetzt Apache durch Nginx. Beide sind Standard-Server-Stacks für das Hosting von Webanwendungen.-Webserver erzeugt Zugriffsprotokolle im Combined Log FormatEin Standardformat für Zugriffsprotokolle, das von Apache und Nginx verwendet wird. Jede Zeile enthält die Client-IP, den Zeitstempel, die HTTP-Methode, den URI, den Statuscode, die Antwortgröße, den Referrer und den User-Agent-String.: eine Zeile pro Anfrage mit Client-IP, Zeitstempel, HTTP-Methode, angefordertem URI, Statuscode, Referrer und User Agent. Bei einer mäßig frequentierten Website bedeutet das Zehntausende von Zeilen pro Tag.

Die Rohdaten sind vorhanden, aber daraus Bedeutung zu extrahieren ist eine völlig andere Herausforderung. Welche dieser 30.000 täglichen Anfragen sind legitime Besucher? Welche sind Suchmaschinen-Crawler? Welche suchen nach /wp-login.php auf einer Website, die kein WordPress verwendet? Welche versuchen eine SQL-InjectionEine Angriffstechnik, bei der bösartige SQL-Anweisungen in Eingabefelder oder URLs eingefügt werden, um Daten aus der Datenbank der Anwendung zu manipulieren oder zu extrahieren. über Query-Parameter? Und entscheidend — welche IP-Adressen tun dies hartnäckig genug, um eine Sperrung auf Firewall-Ebene zu rechtfertigen?

Diese Fragen manuell zu beantworten ist nicht tragbar. Ich brauchte eine automatisierte Pipeline, die Logs importieren, sie mit Bedrohungsanalyse und Geolokalisierungsdaten anreichern, die Ergebnisse über eine intuitive Oberfläche präsentieren und sowohl manuelle als auch automatisierte Reaktionsmöglichkeiten bieten konnte.

Architekturübersicht

SecureLog basiert auf einem PHP-Backend mit einem JavaScript-Frontend und ist dafür konzipiert, neben dem Webserver zu laufen, den es überwacht. Die Architektur folgt einer klaren Trennung der Zuständigkeiten über sechs Komponenten, die jeweils als eigenständige Datei mit einer spezifischen Aufgabe implementiert sind.

Das Frontend (index.php) ist eine Single-Page-Anwendung mit einer Sidebar-Navigationsstruktur, erstellt mit Vanilla-JavaScript und Chart.jsEine Open-Source-JavaScript-Bibliothek zur Erstellung responsiver, animierter Diagramme. SecureLog verwendet sie für Traffic-Trendlinien und Visualisierungen der HTTP-Statuscode-Verteilung.. Sie kommuniziert asynchron mit dem Backend über ein einheitliches API-Gateway (api.php), das alle AJAXAsynchronous JavaScript and XML — eine Technik für HTTP-Anfragen vom Browser ohne Neuladen der Seite, die Echtzeit-Datenaktualisierungen im Dashboard ermöglicht.-Anfragen an die entsprechende Handler-Funktion weiterleitet. Authentifizierung und Sitzungsverwaltung werden von einem dedizierten Sicherheitsmodul (auth.php und login.php) übernommen, das HTTPS, sichere Cookie-Parameter und CSRFCross-Site Request Forgery: ein Angriff, der den Browser des Benutzers dazu bringt, unerwünschte Anfragen zu stellen. SecureLog verhindert dies durch die Generierung und Validierung eines eindeutigen Tokens pro Sitzung.-Token-Validierung erzwingt.

Auf der Backend-Verarbeitungsseite läuft ein CLI-Log-Prozessor (LogProcessor.php) als geplante Aufgabe, liest die rohen Zugriffsprotokolle inkrementell und führt jede Zeile durch die Risikoanalyse-Engine (RiskAnalyzer.php). Schließlich überbrückt ein Firewall-Synchronisierungsskript (SynchronizeFirewall.sh) die Lücke zwischen den Entscheidungen der Anwendung und der firewalldDas Standard-Firewall-Management-Tool auf RHEL/CentOS/AlmaLinux-Systemen. Es unterstützt ipsets — benannte Sammlungen von IP-Adressen, die in Firewall-Regeln für effiziente Massensperrung verwendet werden können.-Konfiguration des Betriebssystems und wendet Sperren und Freigaben in Echtzeit an.

Die Risikoanalyse-Engine

Im Herzen von SecureLog steht die Klasse RiskAnalyzer — die Komponente, die eine rohe Log-Zeile in eine quantifizierte Bedrohungsbewertung verwandelt. Die Designphilosophie ist geradlinig: Jede Anfrage erhält einen numerischen Risiko-Score, der durch die Auswertung mehrerer unabhängiger Signale und die Summierung ihrer gewichteten Beiträge berechnet wird.

Die Analyse durchläuft sechs sequenzielle Prüfungen:

Erkennung aggressiver Scanner. Der User-Agent-String wird gegen eine konfigurierbare Bibliothek bekannter bösartiger Scanner-Signaturen abgeglichen — Tools wie Nikto, sqlmap, DirBuster und ähnliche Aufklärungswerkzeuge. Ein positiver Treffer trägt eine hohe Score-Komponente bei, da allein die Präsenz dieser Tools auf gezieltes Probing hinweist.

Erkennung von Angriffsmustern. Der vollständige Request-URI wird auf Signaturen gängiger Angriffsvektoren gescannt: SQL-Injection-Fragmente (UNION SELECT, OR 1=1), Path-TraversalEin Angriff, der Sequenzen wie ../../ in URLs verwendet, um das Web-Root-Verzeichnis zu verlassen und auf beliebige Dateien auf dem Server zuzugreifen, wie z.B. /etc/passwd.-Sequenzen, XSSCross-Site Scripting: ein Angriff, bei dem bösartiges JavaScript in Webseiten eingeschleust wird, die von anderen Benutzern angesehen werden, typischerweise über URL-Parameter oder Eingabefelder.-Payloads und Command-Injection-Versuche. Die Signaturbibliothek wird aus einer zentralen Konfigurationsdatei geladen und beim Start zu optimierten regulären AusdrückenPattern-Matching-Ausdrücke zur Identifizierung von Zeichenketten, die einer bestimmten Struktur entsprechen. RiskAnalyzer kompiliert alle Signaturen jeder Kategorie in eine einzige Regex für optimale Performance, wobei preg_quote() für sicheres Escaping verwendet wird. kompiliert.

Probing sensibler Dateien. Anfragen an Dateien, die niemals extern zugänglich sein sollten — Konfigurationsdateien, Backup-Archive, Versionskontroll-Verzeichnisse, Datenbank-Dumps — werden mit einem dedizierten Score markiert. Dies fängt die Aufklärungsphase ab, die typischerweise einem gezielten Angriff vorausgeht.

User-Agent-Anomalieanalyse. Fehlende oder verdächtig kurze User-Agent-Strings erhalten einen Score-Abzug. Legitime Browser senden immer einen umfangreichen User Agent; sein Fehlen ist ein starker Indikator für automatisierte Tools. Bekannte passive Bots — Suchmaschinen-Crawler, Überwachungsdienste — werden separat identifiziert und auf einer niedrigeren Stufe bewertet.

URI-Längenanalyse. Anfragen mit URIs über 200 Zeichen erhalten eine zusätzliche Score-Komponente. Abnorm lange URIs sind charakteristisch für Injection-Angriffe, bei denen die Payload im Query-String eingebettet ist.

HTTP-Statuscode-Auswertung. Wiederholte 404-Antworten von derselben IP deuten auf systematisches Probing nicht existierender Pfade hin — eine klassische Enumerationstechnik.

Die sechs Einzelwerte werden zu einem zusammengesetzten Risiko-Score summiert, der dann in fünf Schweregrade klassifiziert wird: CLEAN, LOW, MEDIUM, HIGH und CRITICAL. Die Schwellenwerte für jede Stufe sind in der zentralen Konfiguration definiert, was das System ohne Codeänderungen anpassbar macht.

Die Log-Verarbeitungs-Pipeline

Das Skript LogProcessor.php ist das operative Rückgrat des Systems. Es läuft als CLICommand Line Interface — das Skript ist für die Ausführung über das Server-Terminal oder einen Cron-Scheduler konzipiert, nicht über einen Webbrowser. Es verweigert explizit die HTTP-Ausführung aus Sicherheitsgründen.-Prozess, typischerweise ausgelöst durch CronEin zeitbasierter Aufgabenplaner unter Unix/Linux. Der Log-Prozessor von SecureLog wird typischerweise alle paar Minuten ausgeführt, um eine nahezu Echtzeit-Analyse ohne dauerhaften Ressourcenverbrauch zu gewährleisten. in regelmäßigen Intervallen, und führt drei aufeinanderfolgende Phasen durch.

Phase 1: Inkrementeller Log-Import. Der Prozessor liest die Zugriffsprotokolldateien für jede überwachte Website, beginnend ab der zuletzt bekannten Offset-Position. Dies ist eine kritische Designentscheidung — das System verarbeitet niemals bereits gesehene Daten erneut, was die Ausführungszeiten unabhängig von der Log-Dateigröße vorhersagbar hält. Jede Log-Zeile wird mit einem hybriden Ansatz geparst: Das Skript versucht zunächst einen Standard-Regex-Parser für das Combined Log Format und fällt auf einen tabulatorgetrennten Parser zurück, wenn das Format abweicht. Die geparsten Daten werden normalisiert: IP-Adressen, User Agents und Referrer werden über einen In-Memory-CacheEin assoziatives PHP-Array, das zuvor aufgelöste Datenbank-Lookups (Websites, IPs, User Agents, Referrer) für die Dauer des Batches speichert. Dies eliminiert redundante SELECT-Abfragen, wenn dieselbe IP oder derselbe User Agent Tausende Male in einer einzelnen Log-Datei auftaucht. mit Datenbank-Lookups in interne IDs aufgelöst, um redundante Abfragen zu minimieren. Jede Zeile wird dann durch den RiskAnalyzer geführt, und sowohl der Zugriffsrecord als auch seine Risikobewertung werden über Batch-OperationenStatt eines INSERT pro Log-Zeile akkumuliert der Prozessor Records und führt sie in konfigurierbaren Batches aus. Dies reduziert die Anzahl der Datenbank-Round-Trips drastisch und verbessert den Durchsatz bei großen Log-Dateien. effizient in die Datenbank eingefügt.

Phase 2: Geolokalisierungsauflösung. Nach Abschluss der Importphase identifiziert der Prozessor alle IP-Adressen ohne geografische Daten und löst sie über gleichzeitige API-Aufrufe an einen Geolokalisierungsdienst auf. Die Ergebnisse — Land, Stadt, ISP und Autonome-System-NummerEine ASN (Autonomous System Number) identifiziert den Netzbetreiber, der für einen Block von IP-Adressen verantwortlich ist. Die Kenntnis der ASN hilft dabei, Traffic von legitimen Hosting-Anbietern, Cloud-Diensten und bekannten bösartigen Netzwerken zu unterscheiden. — werden zusammen mit dem IP-Datensatz gespeichert. Diese Anreicherung ist essenziell für die geografischen Analysefähigkeiten des Dashboards und für die Identifizierung von Mustern wie konzentriertem Angriffstraffic aus bestimmten Regionen.

Phase 3: Automatisierte Ban-Verarbeitung. Die letzte Phase ist der Punkt, an dem Analyse zu Handlung wird. Die Klasse BanProcessor fragt die Risikoevent-Datenbank nach IP-Adressen ab, deren kumulative Bedrohungsaktivität konfigurierbare Schwellenwerte überschreitet. Die Schwellenwerte sind nach Schweregrad differenziert: Ein einzelnes CRITICAL-Ereignis kann ausreichen, um eine Sperre auszulösen, während LOW-Ereignisse eine höhere Anzahl innerhalb eines definierten Lookback-FenstersEin konfigurierbares Zeitfenster (Standard: 24 Stunden), in dem Risikoereignisse gezählt werden. Ereignisse, die älter als das Lookback-Fenster sind, werden von der Schwellenwertberechnung ausgeschlossen, um zu verhindern, dass veraltete Daten Sperren für IPs auslösen, deren Verhalten sich geändert hat. erfordern — typischerweise 24 Stunden. Wenn eine IP den Schwellenwert überschreitet, aktualisiert der Prozessor ihren Status auf BANNED und setzt das Firewall-Synchronisierungsflag auf PENDING, um zu signalisieren, dass die Änderung noch nicht auf Betriebssystemebene angewendet wurde.

Die gesamte Ausführung wird durch einen Lock-File-MechanismusEine gegenseitige Ausschlusstechnik: Das Skript erstellt beim Start eine temporäre Datei und entfernt sie nach Abschluss. Wenn die Lock-Datei bereits existiert, bricht das Skript ab und verhindert, dass zwei Instanzen gleichzeitig dieselben Daten verarbeiten. geschützt, der die Überlappung gleichzeitiger Instanzen verhindert — eine wesentliche Sicherheitsmaßnahme, wenn die Verarbeitung in häufigen Intervallen geplant ist.

Firewall-Synchronisierung

Die Brücke zwischen den Entscheidungen von SecureLog und der tatsächlichen Durchsetzung auf Netzwerkebene ist SynchronizeFirewall.sh — ein Bash-Skript, das den Datenbankzustand liest und Änderungen an der firewalld-Konfiguration des Servers über ipsetsBenannte Sammlungen von IP-Adressen, die von firewalld verwaltet werden. SecureLog pflegt zwei ipsets: bad_ips für IPv4-Adressen und bad_ipv6s für IPv6-Adressen. Die Zugehörigkeit zu diesen Sets löst Firewall-Regeln aus, die jeglichen Traffic von den gelisteten IPs blockieren. anwendet.

Die Synchronisierung läuft in vier Phasen ab, wobei IPv4 und IPv6 getrennt behandelt werden, um den unterschiedlichen ipset-Familien von firewalld gerecht zu werden. Für jede Protokollversion verarbeitet das Skript zwei Operationen: Hinzufügen (Anwenden neuer Sperren) und Entfernen (Aufheben von Sperren für IPs, deren Status sich in ALLOWED oder WHITELISTED geändert hat). In jedem Fall fragt das Skript ausschließlich Datensätze ab, bei denen firewall_status = 'PENDING', verarbeitet nur diese Änderungen und aktualisiert den Status nach erfolgreicher Ausführung auf APPLIED.

Dieses Design — die Trennung der Entscheidung (was gesperrt werden soll) von der Durchsetzung (wie es gesperrt wird) — bietet mehrere Vorteile. Die PHP-Anwendung benötigt niemals Root-Rechte; sie schreibt ausschließlich in die Datenbank. Das Bash-Skript, das erhöhte Berechtigungen zur Änderung von firewalld benötigt, operiert über eine minimale, klar definierte Schnittstelle: eine einzelne Datenbankspalte, die als Nachrichtenwarteschlange fungiert. Ein Sicherheitsmechanismus stellt sicher, dass eine vordefinierte „sichere IP“ — typischerweise die Adresse des Administrators — niemals zu einer Sperrliste hinzugefügt wird, unabhängig davon, was die Risikoanalyse ergibt.

Nach der Verarbeitung aller ausstehenden Änderungen löst das Skript ein firewall-cmd --reload nur dann aus, wenn mindestens eine Änderung vorgenommen wurde, und gibt einen zusammenfassenden Bericht aller durchgeführten Operationen aus.

Die Dashboard-Oberfläche

Das Frontend ist eine Single-Page-Anwendung, die um fünf funktionale Tabs herum strukturiert ist, zugänglich über eine dunkle Sidebar-Navigation. Der gesamte Datenfluss ist asynchron: Jede Ansicht befüllt sich durch API-Aufrufe an api.php, und die Oberfläche unterstützt Deep Linking und Browserverlauf-Navigation durch ein benutzerdefiniertes URL-Routing-SystemDas Dashboard verwendet die HTML5 History API (pushState/popState), um lesezeichenfähige URLs für jeden Tab und Filterstatus zu pflegen. Die Navigation zu /dashboard/?tab=logs&ip=1.2.3.4 stellt die exakte Ansicht wieder her..

Übersicht. Der Haupt-Tab präsentiert acht Key Performance Indicators in einem Karten-Raster: Gesamtanfragen, kritische Ereignisse der letzten sieben Tage, gesperrte IPs, eindeutige IPs, eindeutige Länder, nützlicher Traffic (sieben Tage und gesamt) und Gesamtbedrohungen. Unter den KPIs zeigen drei Visualisierungspanels den Traffic-Trend der vergangenen Woche als Liniendiagramm, die Verteilung der HTTP-Statuscodes als Donut-Diagramm und eine Rangliste der zehn meistbesuchten Seiten. Ein viertes Panel — die Risiko-Aufschlüsselungstabelle — zeigt die Anzahl der Ereignisse für jede Bedrohungskategorie (aggressive Scanner, Angriffsmuster, Probing sensibler Dateien) und bietet einen direkten Einblick in die Art der erkannten Bedrohungen.

Traffic & Logs. Eine paginierte, filterbare Tabelle, die einzelne Zugriffsprotokoll-Einträge mit den zugehörigen Risiko-Scores zeigt. Jede Zeile kann erweitert werden, um die vollständigen Details anzuzeigen, und IP-Adressen sind anklickbar: Die Auswahl einer IP filtert die gesamte Ansicht, um alle Anfragen von dieser Adresse anzuzeigen. Von diesem Tab aus können einzelne IPs mit einer einzigen Aktion gesperrt oder entsperrt werden, und Massenoperationen ermöglichen das Sperren oder Entsperren aller sichtbaren IPs auf der aktuellen Seite oder im gesamten gefilterten Ergebnis.

Ban-Verwaltung. Eine dedizierte Ansicht zur Überwachung und Verwaltung des vollständigen IP-Inventars. Jeder Eintrag zeigt die IP-Adresse, ihre geografische Herkunft, den durchschnittlichen Risiko-Score aus der Tabelle risk_analysis_events und den aktuellen Status (BANNED, ALLOWED oder WHITELISTED). Filter ermöglichen die Isolierung von IPs nach Status, Land oder Risikostufe. Von jedem Eintrag aus kann der Administrator direkt zur vollständigen Log-Historie für diese IP navigieren.

Blacklist. Eine manuelle Sperroberfläche zum proaktiven Hinzufügen von IP-Adressen zur Sperrliste — noch bevor die automatisierte Analyse sie erkennt. Nützlich für die Integration von Bedrohungsinformationen aus externen Quellen oder die sofortige Sperrung bekannter bösartiger Akteure.

Whitelist. Das Gegenteil: ein Schutzmechanismus, der sicherstellt, dass bestimmte IP-Adressen — Überwachungsdienste, Partnersysteme, die Adressen des Administrators — niemals der automatischen Sperrung unterliegen, unabhängig von ihren Traffic-Mustern.

Die gesamte Oberfläche unterstützt die Multi-Site-Filterung: Ein Dropdown-Selektor am oberen Rand der Seite ermöglicht den Wechsel zwischen aggregierten Daten für alle überwachten Websites und gefilterten Ansichten für einzelne Domains. Dies macht SecureLog für Umgebungen geeignet, die mehrere Web-Präsenzen auf derselben Infrastruktur betreiben.

Sicherheitsdesign

Ein Sicherheitsüberwachungstool, das selbst unsicher ist, wäre schlimmer als nutzlos — es wäre ein Risiko. Die Authentifizierungsschicht von SecureLog implementiert mehrere Verteidigungsmaßnahmen, die dieses Bewusstsein widerspiegeln.

Sitzungscookies werden mit den Flags secure, httponly und SameSite=Lax konfiguriert. Das httponlyEin Cookie-Attribut, das clientseitiges JavaScript daran hindert, den Cookie-Wert über document.cookie auszulesen. Dies ist eine kritische Verteidigung gegen Session-Hijacking durch XSS-Schwachstellen.-Attribut verhindert, dass JavaScript den Sitzungscookie liest und mindert so Session-Hijacking via XSS. Das SameSite-Attribut bietet einen grundlegenden Schutz gegen CSRF. Jeglicher Traffic wird über eine serverseitige Weiterleitung auf HTTPS erzwungen, und das Login-Formular validiert bei jeder Übermittlung einen CSRF-Token. Fehlgeschlagene Authentifizierungsversuche werden mit der Client-IP für Audit-Zwecke protokolliert, und eine bewusste Verzögerung wird nach fehlgeschlagenen Versuchen eingeführt, um Brute-Force-Angriffe zu verlangsamen.

Auf der API-Seite wird jede Anfrage vor jeder Datenoperation auf Authentifizierung geprüft. Das API-Gateway liefert strukturierte JSONJavaScript Object Notation — ein leichtgewichtiges Datenaustauschformat. Die gesamte Kommunikation zwischen dem Dashboard-Frontend und dem api.php-Backend verwendet JSON, sowohl für Request-Bodies (via POST) als auch für Antworten.-Antworten mit passenden HTTP-Statuscodes, und Datenbankfehler in Produktion werden serverseitig protokolliert, ohne interne Details an den Client preiszugeben.

Die CLI-Komponenten erzwingen einen strikten Ausführungskontext: LogProcessor.php verweigert die Ausführung bei HTTP-Zugriff, und RiskAnalyzer.php blockiert den direkten Dateizugriff über den Browser. Dies sind einfache, aber wesentliche Schutzmaßnahmen gegen versehentliche Offenlegung.

Das Datenmodell

Das Datenbankdesign von SecureLog folgt einer normalisierten Struktur, die auf einigen Kerntabellen basiert. Die Tabelle ip_addresses speichert eindeutige IPs mit ihren geografischen Metadaten. Die Tabelle ip_management verfolgt den Sicherheitsstatus jeder IP (BANNED, ALLOWED, WHITELISTED) zusammen mit dem firewall_status-Flag (PENDING oder APPLIED) — der entscheidenden Spalte, die den Synchronisierungskreislauf antreibt. Zugriffsprotokolle werden mit Fremdschlüsseln zu normalisierten Lookup-Tabellen für Websites, IP-Adressen, Referrer und User Agents gespeichert, wodurch die Haupt-Log-Tabelle kompakt und abfrageeffizient bleibt. Risikoanalyse-Ereignisse werden in einer separaten, mit dem Zugriffsprotokoll verknüpften Tabelle aufgezeichnet, die aggregierte Abfragen nach Schweregrad, Zeitraum und IP ermöglicht, ohne das gesamte Log zu scannen.

Die Trennung zwischen status (dem gewünschten Zustand) und firewall_status (dem angewendeten Zustand) ist der architektonische Schlüssel des gesamten Systems. Alle Schreiboperationen in der PHP-Anwendung — ob durch den automatisierten Ban-Prozessor, durch manuelle Aktionen über das Dashboard oder durch Whitelist-/Blacklist-Verwaltung ausgelöst — setzen firewall_status auf PENDING. Das Bash-Synchronisierungsskript konsumiert dann diese ausstehenden Datensätze und wendet sie auf firewalld an. Dieses Muster ist im Wesentlichen eine leichtgewichtige ereignisgesteuerte ArchitekturEin Entwurfsmuster, bei dem Zustandsänderungen als Ereignisse in einem gemeinsamen Speicher aufgezeichnet werden und nachgelagerte Consumer sie unabhängig verarbeiten. In SecureLog fungiert die Datenbankspalte als Ereigniswarteschlange, die PHP-Anwendung als Produzent und das Bash-Skript als Consumer., implementiert ohne den Overhead einer dedizierten Message Queue.

Warum ich dieses System gebaut habe

Bei meiner Arbeit in der Verwaltung von Web-Infrastruktur fand ich mich wiederholt in derselben Situation: Die WAF erledigte ihre Aufgabe beim Filtern des Traffics, die Logs häuften sich an, aber die Lücke zwischen Rohdaten und fundierter Entscheidungsfindung blieb groß. Kommerzielle SIEMSecurity Information and Event Management — Enterprise-Plattformen (wie Splunk, IBM QRadar oder Microsoft Sentinel), die Sicherheitsdaten aus mehreren Quellen aggregieren, Ereignisse korrelieren und Alerting bereitstellen. Effektiv, aber typischerweise teuer und komplex in der Bereitstellung.-Lösungen existieren, aber sie sind typischerweise für Enterprise-Umgebungen konzipiert und bringen Lizenzkosten mit sich, die für kleine und mittlere Deployments unverhältnismäßig sind. Open-Source-Alternativen wie der ELK-StackElasticsearch, Logstash und Kibana — eine Open-Source-Plattform zur Log-Aggregation und -Visualisierung. Leistungsstark und flexibel, erfordert jedoch eine dedizierte Infrastruktur (typischerweise 8+ GB RAM allein für Elasticsearch) und laufende Wartung. sind mächtig, erfordern aber erhebliche Infrastruktur und Betriebsexpertise für die Wartung.

Ich wollte etwas Zweckgebautes: ein Tool, das neben einem bestehenden Webserver betrieben werden kann, das keine zusätzliche Infrastruktur über eine MySQL-Datenbank hinaus benötigt und das den Kreislauf von der Log-Analyse bis zur Firewall-Durchsetzung ohne manuellen Eingriff schließen kann. SecureLog ist das Ergebnis — kein generischer Log-Aggregator, sondern ein spezialisiertes System, das für eine einzige, klar definierte Mission entwickelt wurde: die Bedrohungslandschaft der eigenen Webanwendungen verstehen und automatisch darauf reagieren.

Der Code ist so strukturiert, dass er von einem einzelnen Entwickler oder einem kleinen Team wartbar ist. Jede Datei enthält umfangreiche Inline-Dokumentation — nicht nur Kommentare, die erklären, was der Code tut, sondern warum bestimmte Entscheidungen getroffen wurden, einschließlich datierter Anmerkungen zu Bugfixes und Designkorrekturen. Dies spiegelt ein Prinzip wider, das ich in meiner gesamten Arbeit anwende: Code, der sechs Monate später von jemand anderem als seinem Autor nicht verstanden werden kann, ist eine technische Schuld, kein Vermögenswert.

Fazit

SecureLog zeigt, dass eine effektive Web-Sicherheitsüberwachung keinen komplexen, mehrschichtigen Enterprise-Stack erfordert. Eine gut konzipierte PHP-Anwendung, ein Bash-Skript mit den richtigen Berechtigungen, eine Datenbank als Koordinierungsschicht und eine klare Trennung zwischen Analyse, Entscheidung und Durchsetzung können ein System hervorbringen, das gleichzeitig transparent, reaktionsfähig und wartbar ist.

Die zentrale architektonische Erkenntnis ist der geschlossene Kreislauf: Logs gelangen in das System, werden analysiert und bewertet, die Bewertungen treiben automatisierte Entscheidungen, die Entscheidungen werden mit der Firewall synchronisiert, und die Ergebnisse sind in Echtzeit über das Dashboard sichtbar. In jeder Phase behält der Administrator die volle Kontrolle — automatisierte Sperren können überschrieben werden, Whitelists schützen vertrauenswürdige Adressen, und die vollständige Historie jeder Entscheidung ist auditierbar.

Wenn Sie Web-Infrastruktur verwalten und vor ähnlichen Herausforderungen stehen — oder wenn Sie an der Diskussion der technischen Details der Implementierung interessiert sind — zögern Sie nicht, mich zu kontaktieren.