GhostShield – Eigentlich wollten wir nur ein paar Hacker ärgern. Jetzt wird etwas Größeres daraus.
*dieser Text wurde mit KI umgeschrieben
Wie aus einer ungenutzten VM, einer verrückten Idee und ziemlich viel Kaffee eine eigene Web Application Firewall entsteht.
Es gibt diese Momente, in denen man sich denkt: „Ach komm, das probiere ich mal eben aus.“
Meistens endet das mit einem kleinen Experiment, ein paar interessanten Erkenntnissen und vielleicht einem neuen Eintrag auf der To-do-Liste.
Bei uns ist daraus GhostShield geworden.
Aber fangen wir von vorne an.
Alles begann mit einem Fake-CMS
Die ursprüngliche Idee war eigentlich ziemlich überschaubar.
Wir hatten noch eine ungenutzte virtuelle Maschine. Und die Frage: Was wäre, wenn wir darauf ein Content-Management-System vortäuschen, das gar nicht existiert?
Ein paar typische WordPress-Pfade hier, ein vermeintliches Admin-Panel dort. Genug, um automatisierte Scanner und neugierige Angreifer anzulocken.
Nur dass hinter diesen Pfaden kein echtes WordPress steckt.
Stattdessen sollte unser kleines Experiment beobachten, welche Angriffsmuster auftauchen, welche Schwachstellen ausgenutzt werden sollen und welche IP-Adressen besonders hartnäckig sind.
GhostCMS war geboren.
Ein Honeypot. Ein bisschen Threat Intelligence. Ein spannendes Nebenprojekt.
Zumindest war das der Plan.
Und dann kam die verhängnisvolle Frage …
„Wenn wir Angriffe ohnehin erkennen können, warum schützen wir damit nicht gleich unsere echten Websites?“
Tja.
Aus einem kleinen Beobachtungssystem wurde plötzlich die Idee für einen vollständigen Reverse Proxy mit integrierter Web Application Firewall.
Und aus GhostCMS wurde GhostShield.
Das Ziel: Eine Sicherheitsplattform, die sich vor Websites schalten lässt, verdächtige Anfragen untersucht und bei Bedarf automatisch eingreift.
Nicht als weiteres WordPress-Plugin.
Nicht als zusätzliche Belastung innerhalb der Kundenanwendung.
Sondern als eigenständige Schutzschicht, bevor eine Anfrage überhaupt beim eigentlichen Webserver ankommt.
Erst beobachten. Dann warnen. Und irgendwann ist Schluss.
GhostShield kombiniert inzwischen mehrere Sicherheitsmechanismen.
Im Mittelpunkt stehen Nginx, ModSecurity und das OWASP Core Rule Set. Damit lassen sich beispielsweise typische SQL-Injection-Versuche, Cross-Site-Scripting-Muster und andere verdächtige HTTP-Anfragen erkennen.
Aber Erkennung allein war uns irgendwann nicht mehr genug.
Also haben wir eine abgestufte Sperrlogik entwickelt.
Auffällige Clients können zunächst auf HTTP-Ebene gesperrt werden. Bei weiteren bestätigten Angriffsmustern kann GhostShield die Sperre bis auf die Netzwerkebene eskalieren.
Und ja, das haben wir tatsächlich ausprobiert.
Bei einem kontrollierten Test von einem externen Server antwortete GhostShield zunächst mit HTTP 403.
Dann, nach weiteren erkannten Angriffen, war plötzlich Schluss.
Keine Fehlerseite mehr. Keine HTTP-Antwort.
Nur noch ein Timeout.
Der Grund? Die Quell-IP war automatisch in einer zeitlich begrenzten nftables-Sperre gelandet.
Zugegeben: Es gibt langweiligere Momente bei der Softwareentwicklung. 😏
Aber eine WAF allein reicht uns nicht
Während der Entwicklung wurde schnell klar, dass Website-Sicherheit nicht nur daraus besteht, verdächtige Requests abzuwehren.
Was passiert beispielsweise, wenn ein Backend plötzlich nicht mehr erreichbar ist?
Was, wenn auf einem WordPress-System eine veraltete Erweiterung installiert ist?
Oder wenn ein Administrator wissen möchte, warum eine bestimmte IP gesperrt wurde?
Also wuchs GhostShield weiter.
Inzwischen arbeiten wir unter anderem an beziehungsweise mit:
- Zentraler Website-Verwaltung: Mehrere Websites und Backend-Server über eine gemeinsame Oberfläche verwalten.
- Automatischem Zertifikatsmanagement: HTTPS-Zertifikate ausstellen und erneuern.
- WAF-Monitoring: Angriffe, Requests, Sperren und Auffälligkeiten pro Website auswerten.
- Traffic-Analytics: Bandbreite, HTTP-Statuscodes und zeitliche Entwicklungen sichtbar machen.
- Backend-Überwachung: Ausfälle erkennen und automatisch individuell gestaltete Störungsseiten ausliefern.
- CVE- und Software-Inventar: Installierte CMS-Versionen, Plugins und relevante Serverpakete mit bekannten Sicherheitsmeldungen vergleichen.
- Abgestuftem Blocking: Temporäre HTTP-Sperren und optional eine weitergehende Netzwerksperre.
Und das alles möglichst modular, damit sich die einzelnen Funktionen unabhängig weiterentwickeln lassen.
Natürlich ist noch nicht alles fertig. Manche Funktionen werden bereits praktisch getestet, andere brauchen noch Feinschliff.
Aber genau das macht die Entwicklung gerade so spannend.
Warum entwickeln wir das selbst?
Eine berechtigte Frage.
Schließlich gibt es bereits etablierte Web Application Firewalls und kommerzielle Sicherheitsdienste.
Die Antwort ist eigentlich einfach:
Wir wollen verstehen und kontrollieren können, was mit dem Traffic unserer Hosting-Infrastruktur passiert.
Welche Regel hat eine Anfrage blockiert? Warum wurde eine IP als gefährlich eingestuft? Wie lange bleibt eine Sperre bestehen? Welche Websites sind betroffen?
Und vor allem: Wie können wir Schutzmechanismen so integrieren, dass sie zu unserer Infrastruktur und zu den Bedürfnissen unserer Kunden passen?
GhostShield soll kein undurchsichtiges System werden, bei dem am Ende nur ein rotes oder grünes Lämpchen leuchtet.
Wir wollen nachvollziehbare Entscheidungen, übersichtliche Auswertungen und die Möglichkeit, gezielt einzugreifen.
Denn auch eine WAF kann sich irren.
Und ein legitimer Besucher sollte nicht auf einer Sperrliste landen, nur weil irgendeine Sicherheitsregel einen schlechten Tag hat.
Was bedeutet das für bit-line.com und unsere Kunden?
Langfristig möchten wir GhostShield als zusätzlichen Sicherheitsbaustein für unsere Hosting-Angebote einsetzen.
Dabei bleibt die Entscheidung, ob eine Website diesen zusätzlichen Schutz nutzen soll, bewusst flexibel.
Websites können weiterhin regulär auf unseren Webservern betrieben werden. GhostShield soll dort zum Einsatz kommen, wo eine vorgeschaltete Sicherheits- und Überwachungsschicht gewünscht ist.
Für Kunden könnte das künftig bedeuten: zusätzliche Angriffserkennung, nachvollziehbare Sicherheitsberichte, zentrale Überwachung und Schutzmechanismen, die unabhängig vom eingesetzten CMS funktionieren.
Denn nicht jede Website läuft auf WordPress. Und nicht jede Anwendung braucht dieselben Regeln.
Und jetzt?
Jetzt wird weiterentwickelt, getestet, gelegentlich geflucht und anschließend wieder getestet.
GhostShield befindet sich noch in aktiver Entwicklung. Es ist kein fertig zertifiziertes Sicherheitsprodukt, und wir werden auch nicht behaupten, dass irgendeine WAF sämtliche Angriffe verhindern könnte.
Aber die ersten praktischen Ergebnisse sind vielversprechend.
In den kommenden Beiträgen möchten wir euch mit hinter die Kulissen nehmen.
Wir zeigen, wie GhostShield aufgebaut ist, welche Herausforderungen uns begegnet sind und warum selbst eine scheinbar einfache Funktion wie „IP blockieren“ technisch überraschend interessant werden kann.
Und vielleicht verraten wir dabei auch, wie aus einer einzigen ungenutzten VM plötzlich ein ganzes Sicherheitsprojekt geworden ist.
Eines können wir schon sagen:
GhostShield ist längst mehr als ein kleines Experiment.
Und wir haben damit noch einiges vor.
Da kommt etwas Größeres.
GhostShield – Ein Sicherheitsprojekt von bit-line.com
Entwickelt mit Neugier, einer gesunden Portion Misstrauen gegenüber unbekanntem Traffic und vermutlich deutlich mehr Kaffee als ursprünglich geplant.
