OPNsense Firewall für deine Magento / Mage-OS Shop-Infrastruktur

1. Warum überhaupt eine Netzwerk-Firewall?

Um zu verstehen, warum deine Magento-Infrastruktur eine Netzwerk-Firewall wie OPNsense braucht, lohnt sich zuerst ein Blick auf das, was den ganzen Tag an deinem Shop anklopft: den Internet-Traffic.

Der besteht längst nicht nur aus echten Kunden. Dazwischen tummeln sich Suchmaschinen-Bots, Security-Scanner, Brute-Force-Versuche, bekannte bösartige IPs, Spam-Bots und jede Menge Hintergrundrauschen. Und das ist kein Randphänomen: Laut dem Imperva Bad Bot Report 2025 war 2024 bereits über die Hälfte des weltweiten Web-Traffics automatisiert (51 %) — erstmals mehr als menschlicher Traffic. Gut ein Drittel (37 %) entfällt auf ausgesprochen bösartige Bots, und Deutschland zählt zu den am stärksten betroffenen Ländern weltweit.

Ob ein Bot dabei gut oder schlecht ist, lässt sich nicht pauschal sagen — das hängt von deinem Shop ab: Der Googlebot ist willkommen, der Preis-Scraper der Konkurrenz eher nicht. Bei IP-Adressen ist die Lage klarer. Welche Adressen bösartig sind, ist im Netz größtenteils bekannt und dokumentiert — und genau dieser bekannte, bösartige Teil ist für einen erheblichen Anteil an Last und Ressourcenverbrauch verantwortlich, lange bevor ein echter Besucher bedient wird.

2. Warum filtert das nicht einfach der Hoster?

Könnte er — technisch sogar ziemlich leicht. Er tut es aber bewusst nicht: Eine inhaltliche Filterung deines Traffics wäre ein Eingriff, der datenschutzrechtlich heikel ist und nicht in seine Rolle gehört. Was für den einen Shop ein Angreifer ist, kann für den anderen ein legitimer Besucher sein.

Deshalb beschränkt sich der Hoster auf das, was nur er kann: das Abfangen volumetrischer DDoS-Angriffe — der Brachialgewalt, die deine Leitung oder den Switch-Port komplett zustopft. Genau dort, wo deine eigene Firewall, egal welche, längst nichts mehr ausrichten könnte, weil schon die Bandbreite dicht ist. Alles Feinere bleibt deine Aufgabe.

3. Gute und böse IPs — gar nicht so kompliziert

Bevor OPNsense filtern kann, musst du festlegen, was eine gute und was eine böse IP ist. Das klingt aufwändiger, als es ist, denn diese Arbeit haben andere längst gemacht. Es gibt etablierte Reputationslisten — Spamhaus, AbuseIPDB, IPsum und etliche mehr. Das gemeinnützige Spamhaus-Projekt etwa lässt seine Einträge nicht nur automatisch erzeugen, sondern von einem festen Team aus Researchern und Forensik-Spezialisten prüfen — und wird von ISPs, E-Mail-Providern, Behörden und Konzernen weltweit eingesetzt. Solche Listen überschneiden sich teilweise, ergeben in Summe aber ein verlässliches Bild.

Die meisten arbeiten mit einem Vertrauensmaß: AbuseIPDB etwa mit einem Score von 0 bis 100 (0 = unauffällig, 100 = von vielen Nutzern als bösartig gemeldet), IPsum mit einem Level, das zählt, auf wie vielen seiner über 30 ausgewerteten Blacklists eine Adresse gleichzeitig auftaucht — je höher, desto eindeutiger der Fall. So entscheidest du selbst, ab welcher Schwelle geblockt wird. Die Dimension dahinter ist beträchtlich: Allein AbuseIPDB verarbeitet über eine Million Missbrauchsmeldungen pro Tag.

In OPNsense hinterlegst du solche Listen als URL-Table-Alias — die Firewall zieht sie automatisch und hält sie aktuell. Die meisten Listen sind kostenlos; AbuseIPDB ist ab 10.000 Einträgen kostenpflichtig und liefert seine Daten nicht in einer direkt importierbaren Form. Genau dafür gibt es unseren PARC-Security-Container: Er holt die AbuseIPDB-Daten, bereitet sie auf und stellt sie OPNsense importierfertig bereit.

Das Ergebnis: Ein Großteil des bekannten bösartigen Traffics wird schon hier aussortiert — auf Netzwerkebene, lange bevor er in den nachfolgenden Schichten Rechenzeit kostet oder Schaden anrichtet.

4. Klare Grenzen — nach außen, nach innen und dazwischen

Die zweite große Aufgabe von OPNsense ist die Trennung von öffentlichem und internem Netz. OPNsense ist die einzige Komponente, die der öffentliche Traffic überhaupt direkt erreicht — keine deiner virtuellen Maschinen, kein Cache, keine App, keine Datenbank, hängt ungeschützt am offenen Internet.

Dabei gilt Default-Deny: Standardmäßig sind alle Ports zum öffentlichen Netz dicht, offen sind nur die Pflicht-Ports 80 und 443 für den Web-Traffic. Das heißt nicht, dass SSH, SFTP & Co. nicht funktionieren — sie sind nur nicht aus dem offenen Internet erreichbar, sondern ausschließlich über VPN oder für definierte, vertrauenswürdige IPs. Damit fällt die häufigste Brute-Force-Angriffsfläche schlicht weg.

Diese Grenze wirkt in beide Richtungen. Denn wozu müssten die internen VMs überhaupt von sich aus ins offene Internet? Außer um Updates zu ziehen: praktisch nie. Deshalb ist auch der ausgehende Traffic gefiltert — eine VM darf nur zu den Adressen und auf den Ports nach außen, die sie wirklich braucht, alles andere ist dicht. Sollte sich doch einmal eine Backdoor einschleichen, kann sie so weder Befehle von einem Steuerungsserver empfangen noch gestohlene Daten abfließen lassen — sie sitzt in einer Sackgasse.

Und die Abschottung endet nicht an der VM-Grenze, sie reicht bis in jede einzelne Maschine hinein. Jede VM ist für sich gehärtet: eine Minimal-Installation mit nur dem einen Dienst, den sie bereitstellt, eine Firewall direkt auf der VM selbst, die ausschließlich die tatsächlich benötigten Ports öffnet (plus den Update-Kanal), und fail2ban, das auch den internen Traffic überwacht. Alles andere ist schon auf der Maschine dicht — nicht erst auf der Netzwerk-Firewall. Überwindet ein Angreifer eine Schicht, steht er sofort vor der nächsten.

Das Prinzip „ein Dienst pro VM" zahlt sich dabei weit über die Sicherheit hinaus aus. Wo nur eine einzige Anwendung läuft, gibt es kaum noch Paketkonflikte, gegenseitige Abhängigkeiten oder Seiteneffekte: Updates lassen sich gezielt einspielen und im Zweifel ebenso gezielt wieder zurückrollen, ohne dass ein halbes Dutzend anderer Dienste mitbetroffen ist. Die Komplexität einer einzelnen Maschine sinkt drastisch — und damit auch die Wahrscheinlichkeit, dass ein Update etwas Unerwartetes umwirft. Dieselbe Trennung ist außerdem die Grundlage dafür, dass sich jeder Dienst unabhängig skalieren, verschieben, sichern oder hochverfügbar auslegen lässt.

Diese gestaffelte, mehrfach abgesicherte Bauweise ist kein PARC-Sonderweg, sondern anerkannte Sicherheitslehre — sie folgt dem Defense-in-Depth-Prinzip, das auch das BSI in seinem IT-Grundschutz beschreibt. Wir gehen dabei bewusst über das hinaus, was eine einzelne zentrale Firewall leisten kann:

Zusammenfassung der Sicherheitsvorkehrungen zum Schutz deiner Magento-Infrastruktur

• Volumetrischer DDoS-Schutz auf Hoster-Ebene
• IP-Reputationsfilterung aus laufend aktualisierten Blacklists
• Default-Deny nach außen — nur 80/443 offen
• Egress-Kontrolle — kein unkontrollierter Verkehr nach außen
• Strikte Netztrennung — keine VM direkt am offenen Netz
• Interne Segmentierung — Dienste nur auf ihren Ports erreichbar
• Host-Firewall auf jeder VM — Abschottung bis in die Maschine
• fail2ban — auch für den internen Traffic
• Minimal-Installation — ein Dienst pro VM, kleine Angriffsfläche
• Admin-Zugänge nur per VPN — kein offener SSH-Port im Netz
• TLS-Terminierung erst an der WAF — inhaltliche Prüfung vor der App
• Hochverfügbarkeit — Ausfallsicherheit auf jeder Ebene

Genau das ist der Unterschied zwischen „eine Firewall davorgestellt" und einer durchdacht abgesicherten Infrastruktur.

5. Warum genau OPNsense?

Ausgereifte Open-Source-Firewalls gibt es mehrere: im FreeBSD-Lager OPNsense und pfSense (eng verwandt — OPNsense ist 2015 als Fork von pfSense entstanden, das wiederum aus m0n0wall hervorging), im Linux-Lager IPFire. Ausschlaggebend für uns waren die folgenden Punkte:

• Unabhängige Governance. Entwickelt vom niederländischen Hersteller Deciso, der Open-Source-Core ist vollständig nutzbar, die Roadmap transparent, der Release-Rhythmus planbar — zwei große Versionen pro Jahr, dazwischen regelmäßige Patches.
• API-first. Vollständige offizielle REST-API, die gesamte Konfiguration als versionierbares XML. Aufbau, Updates und Wiederherstellung laufen automatisiert und reproduzierbar statt per Klick-Marathon — Infrastruktur als Code.
• Native Blacklist-Integration. Reputationslisten per URL-Table, automatisch abgeglichen — die Grundlage für das IP-Filtering von oben.
• WireGuard im Kernel. Plus OpenVPN und IPsec — für abgesicherte Zugänge: Administration, Standortkopplung (Site-to-Site), Anbindung externer Dienste und mehr.
• GeoIP-Filterung. Traffic auf Länderebene gezielt sperren oder zulassen.
• Hochverfügbarkeit. Zwei (oder mehr) Geräte lassen sich per CARP zu einem Failover-Cluster mit gemeinsamer virtueller IP koppeln. Fällt das primäre aus, übernimmt das zweite in Sekunden — und weil die Verbindungstabelle laufend repliziert wird, bleiben bestehende Verbindungen dabei erhalten.
• Reporting im Core. Traffic-Statistiken und NetFlow ohne Zusatzwerkzeuge.
• 2FA & rollenbasierte Zugriffe. Sauberer Betrieb, wenn mehrere Hände ans System sollen.
• Modernes Web-Interface. Aufgeräumt und übersichtlich.

6. Richtig dimensioniert — schlank statt übermotorisiert

Eine Netzwerk-Firewall muss nicht groß sein, um schnell zu sein — sie muss richtig zugeschnitten sein. Der entscheidende Punkt: Auf OPNsense liegen bei uns nur die leichtgewichtigen Aufgaben — Pakete weiterleiten, bekannte IPs und Ports blocken, VPN terminieren. Das sind Operationen auf Netzwerkebene, die kaum Rechenleistung kosten. Die wirklich rechenintensive Arbeit — TLS entschlüsseln und den Inhalt jeder Anfrage prüfen — passiert bewusst erst auf der nachgelagerten WAF, nicht hier. Dadurch bleibt OPNsense schlank.

Bei reinem Paketfiltern ist nicht die Anzahl der CPU-Kerne der Engpass, sondern die Single-Core-Leistung und die Netzwerkkarte. Der Speicherbedarf ist gering: Jede aktive Verbindung belegt in der State-Tabelle rund 1 KB — selbst 500.000 gleichzeitige Verbindungen sind also nur etwa 500 MB RAM. Eine zweistellige Zahl an Gigabyte RAM und eine moderne CPU mit wenigen, aber schnellen Kernen decken damit schon sehr große Lasten ab.

Weil der Bedarf so überschaubar ist, ist OPNsense flexibel im Betrieb. Es läuft auf dedizierter Hardware ebenso wie als virtuelle Maschine — etwa auf einem Proxmox-Host neben anderen Diensten oder in der Cloud mit geteilten Ressourcen. Dedizierte CPU-Kerne sind kein Muss; sinnvoll sind sie vor allem dann, wenn unter Last konstante Latenz garantiert sein soll — dann pinnt man die Firewall auf feste Kerne, damit ein lauter Nachbar auf demselben Host sie nicht ausbremst. Beim Massenspeicher zählt nicht die Geschwindigkeit, sondern nur, dass er vorhanden ist: OPNsense belegt lediglich wenige Gigabyte, und Firewalling ist kein I/O-lastiger Vorgang — eine normale SSD genügt völlig, NVMe bringt keinen messbaren Vorteil. Einzig die Logs werden laufend geschrieben; das ist auf robustem Server-Storage unkritisch, und wer maximal schonen will, legt das Log-Verzeichnis per Klick in den Arbeitsspeicher (RAM-Disk). Ein Verschleißthema ist das real nur bei kleinen Embedded-Appliances mit Flash-Speicher, nicht bei einer VM auf ordentlichem Server-Storage.

Konkret nennt OPNsense als Mindestanforderung eine 1-GHz-Dual-Core-CPU und 3 GB RAM, empfohlen werden eine 1,5-GHz-Mehrkern-CPU mit 8 GB RAM und einer SSD. Diese empfohlene Ausstattung deckt laut Hersteller bereits 350–750 Mbit/s und über hundert Nutzer beziehungsweise Netze ab — und das mit vollem Funktionsumfang. In der Praxis geben wir unserer OPNsense-VM typischerweise 2 Kerne und 8 GB RAM; selbst mit 4 GB liefe sie für die reine Edge-Aufgabe (Filtern, Blocken, VPN) problemlos. Mehr braucht es schlicht nicht, solange die rechenintensive Inhaltsprüfung auf der WAF liegt.

Betrieben wird das Ganze in der Regel virtualisiert mit geteilten Ressourcen — das ist günstig, flexibel und für diese Last völlig ausreichend. Reicht ein Server irgendwann nicht mehr, nimmt man einfach weitere dedizierte Server hinzu und skaliert horizontal. In der Realität wächst man mit einem gut dimensionierten Setup allerdings nur sehr selten über die Ressourcen eines einzigen dedizierten Servers hinaus.

Was das praktisch bedeutet, lässt sich an der Anbindung festmachen. Eine schlank gebaute Magento-Seite ist erstaunlich leicht: Eine reale, mit Hyvä optimierte Produktseite überträgt komplett — HTML, CSS, JavaScript und alle Bilder — nur rund 250 bis 300 KB. Das ist etwa ein Zehntel dessen, was eine durchschnittliche Webseite wiegt, und genau die Art von Schlankheit, die Ladezeiten und Suchmaschinen-Ranking zugutekommt. Rechnet man konservativ mit 300 KB pro Aufruf, ergibt sich als theoretische Obergrenze der Leitung:

• 1 Gbit/s-Anbindung. ≈ 125 MB/s — rechnerisch über 400 Seitenauslieferungen pro Sekunde, also Spielraum für mehr als eine Million Seitenaufrufe pro Stunde.
• 10 Gbit/s-Anbindung. ≈ 1.250 MB/s — das Zehnfache, mehrere tausend Seiten pro Sekunde, für sehr große Shops oder extreme Lastspitzen.

In der Praxis ist damit fast immer die Anbindung der begrenzende Faktor, nicht die Firewall selbst — sie hat für ihre Aufgabe reichlich Reserven.

Die genannten Werte sind Richtwerte zur Größenordnung. Die tatsächliche Seitengröße hängt stark vom jeweiligen Shop ab — Theme, Bildmenge, Anzahl der Produkte pro Seite — und kann im Einzelfall deutlich höher oder niedriger liegen. Sie ersetzen keine konkrete Lastmessung, geben aber ein realistisches Gefühl für die Dimensionen.

Was an Web-Traffic auf Port 80 und 443 durchkommt, ist damit von bekannten Angreifern bereinigt — aber noch nicht inhaltlich geprüft. Das kann OPNsense an dieser Stelle auch gar nicht: Um in den Inhalt verschlüsselter Verbindungen zu schauen, müsste der Traffic hier erst terminiert, also entschlüsselt werden. Genau das tut die Firewall bewusst nicht. Die TLS-Terminierung und damit die inhaltliche Prüfung auf Anwendungsebene übernimmt erst die nachgelagerte SafeLine WAF.

Kontakt aufnehmen