Was eine KMU-Firewall 2026 tatsächlich sieht – und was nicht

Laut Google Transparency Report sind inzwischen über 95 % der geladenen Seiten in Chrome HTTPS – Tendenz: steigt nicht mehr, weil es nicht viel mehr zu verschlüsseln gibt. Der Zscaler ThreatLabz Report 2024 zählt rund 87 % aller beobachteten Angriffe im verschlüsselten Kanal. Das heisst in der Praxis: Die brave Firewall, die den Router vom Provider ergänzt und pauschal alles auf Port 443 durchlässt, sieht bei den relevanten Bedrohungen heute ungefähr so viel wie ein Nachtwächter ohne Taschenlampe.

Das hier ist bewusst ein technischer Praxisbeitrag für IT-Verantwortliche und Admins, die Security nicht nur einkaufen, sondern im Alltag betreiben.

Wir bauen für unsere KMU-Kunden Firewalls auf Basis von OPNsense. Nicht weil wir keine FortiGates verkaufen könnten, sondern weil die Fragen, die dabei auftauchen, interessant sind: Was sieht so ein Gerät heute wirklich? Wo lohnt sich Deep Inspection, wo wird es Theater? Und was bedeutet Full-Mesh-VPN jenseits des Marketing-Schlagworts?

HTTPS ist das Problem, nicht die Lösung

Vor zehn Jahren konnte eine klassische Firewall den ausgehenden Traffic mitlesen, URLs filtern, Mail-Anhänge auf Viren scannen, und per DPI Anwendungen erkennen. Heute funktioniert davon wenig, weil TLS (der Nachfolger von SSL) fast alles davon unsichtbar macht.

Was eine Firewall ohne TLS-Inspection bei einem HTTPS-Request sieht:

• Ziel-IP und Port
• den Server Name Indicator (SNI) im TLS-Handshake – also www.beispiel.ch, aber nicht die vollständige URL
• Paketgrössen und Timing

Was sie nicht sieht:

• den Pfad der URL (/admin, /download/malware.exe)
• HTTP-Header, Cookies, Formulardaten
• den Inhalt der Antwort – also auch keine Malware im Download

Das bedeutet: Ein Webfilter auf SNI-Basis kann zwar facebook.com blockieren, aber nicht zwischen firma-im-sharepoint.com/hr-policy.pdf und firma-im-sharepoint.com/cryptolocker.exe unterscheiden. Und ein AV-Scan auf der Firewall läuft ins Leere, weil das verdächtige Binary im TLS-Tunnel steckt.

Wo TLS-Inspection (SSL-Bump) eingreift

Die Lösung heisst „Man-in-the-middle mit Ansage": Die Firewall hält beim HTTPS-Aufbau die Verbindung an, baut selbst eine TLS-Sitzung zum Ziel auf, und präsentiert dem Client ein im Moment generiertes Zertifikat, ausgestellt von einer lokalen CA, der die Endgeräte der Firma vertrauen. Auf OPNsense erledigt das Squid im SSL-Bump-Modus. Danach kann:

• der Webfilter die vollständige URL prüfen
• ICAP den entpackten Content an ClamAV zur AV-Signatur-Prüfung schicken
• der Admin Logs schreiben, die tatsächlich etwas aussagen

Das klingt schön, hat aber Kosten, die selten ehrlich benannt werden:

1. Die CA muss auf jedes Endgerät. Laptop, Tablet, das private Handy im Office-WLAN, der CNC-Server aus 2014. Wir rollen das automatisiert über unsere selbst entwickelte Geräteverwaltung auf Basis von Open-Source-Technologien aus. Bring-Your-Own-Device bleibt ein Dauerproblem, das man organisatorisch, nicht technisch löst.
2. Certificate Pinning bricht. Banking-Apps, manche Messenger, ein paar Java-Clients und Update-Mechanismen vertrauen ausschliesslich ihrer eigenen CA-Liste. Die muss man per Domain bypassen – sonst funktioniert z. B. die Windows-Update-Infrastruktur nicht mehr. Eine gepflegte Bypass-Liste ist ein Teil der Arbeit, die nach dem Projekt weiterläuft.
3. Privacy und Legalität. TLS-Inspection auf Arbeitsgeräten ist in der Schweiz möglich, braucht aber eine vorgängige Information der Mitarbeitenden und einen dokumentierten Zweck. Die Policy gehört ins Mitarbeiterhandbuch, nicht ins Wiki.
4. Nie ganz harmlos. Jede zusätzliche Komponente im TLS-Pfad ist eine weitere Stelle, an der etwas brechen kann. Auf OPNsense haben wir mit der Kombination Squid + c-icap + ClamAV auf der 26er-Branch Ausfälle gesehen; wir halten ICAP/AV-Scan deshalb aktuell aus dem Squid-Datenpfad heraus und erreichen das Scan-Verhalten anders. Kein Drama, aber eben auch nicht „einfach einschalten".

DNS-Filter: das unterschätzte billige Werkzeug

Bevor irgendein TLS-Handshake stattfindet, macht der Browser eine DNS-Abfrage. Das ist – anders als HTTP – im klassischen Setup unverschlüsselt und damit ein praktischer Angriffspunkt zum Schutz.

Ein lokaler Resolver (bei uns Unbound auf der Firewall) mit einer Blocklist macht in der Regel schon 80 % der Arbeit, für die andere Hersteller teure „Web Security"-Module verkaufen:

• Bekannte Malware-C2-Server, Phishing-Domains, Krypto-Miner-Pools fallen raus, bevor die Verbindung aufgebaut wird.
• NSFW-Kategorien lassen sich per Blocklist deutlich ruhiger blocken als über einen reaktiven Webfilter.
• Ad- und Tracker-Domains blocken nebenbei ein Drittel des Browser-Traffics, was sich angenehm auf die Bandbreite auswirkt.

Damit DNS-Filterung nicht trivial umgangen werden kann, muss die Firewall DoH (DNS-over-HTTPS, Port 443) und DoT (DNS-over-TLS, Port 853) zu bekannten Anbietern blocken und Port 53 nach extern umleiten auf den eigenen Resolver. Bei uns steht das im Baseline-Regelwerk – Port 853 komplett gesperrt, bekannte DoH-IPs auf 443 geblockt, 53/udp nach aussen auf den Firewall-Resolver genattet. Das verhindert, dass ein Browser unbemerkt an der Firewall vorbei den Chrome-eigenen DoH-Resolver benutzt.

DNS-Filter ersetzen keine TLS-Inspection – aber wer mit einem DNS-Filter und einem Standard-SNI-Webfilter startet, hat bei deutlich weniger Betriebsaufwand den Grossteil des realistischen Angriffsvolumens abgedeckt. Die volle Deep-Inspection ist das letzte 15–20 %, das die meiste Arbeit macht.

WireGuard-Mesh: warum wir OpenVPN nicht mehr deployen

Die zweite Dauerbaustelle ist der Remote-Zugriff. Mitarbeitende im Homeoffice, Baustellen-Laptops, Handwerker mit einem Tablet vor Ort. Klassisch war das OpenVPN gegen einen Konzentrator in der HQ-Firewall. Funktioniert, aber: jedes Paket von Filiale A zu Filiale B läuft über die HQ – selbst wenn A und B nur 20 Kilometer voneinander entfernt sind. Das ist ein Flaschenhals aus den Neunzigern.

WireGuard macht zwei Dinge besser:

Erstens ist der Code klein genug, dass er lesbar ist. Jason Donenfelds Paper auf der NDSS 2017 – „WireGuard: Next Generation Kernel Network Tunnel" – zeigt eine Codebasis in der Grössenordnung von ~4'000 Zeilen gegen OpenVPN/IPsec mit sechsstelligem Umfang. Kleineres Angriffsfenster, weniger Konfigurationsoptionen, weniger falsch konfigurierbar. Seit Kernel 5.6 ist WireGuard Teil des Linux-Mainline; auf OPNsense seit 24.1 im Core, kein Plugin mehr nötig.

Zweitens ist WireGuard symmetrisch: Jeder Peer kennt die öffentlichen Schlüssel aller anderen Peers und spricht direkt mit ihnen. Das heisst, man kann ohne Hub-Architektur ein Full Mesh aufziehen: Firewall Filiale A hat Firewall Filiale B und alle Remote-Worker als Peer, B hat A und die Worker, jeder Remote-Worker kann – sofern erlaubt – direkt auf A und B zugreifen. Traffic von A nach B läuft nicht über HQ.

Aus Nutzersicht heisst das: Alle Geräte, Server und Standorte sehen sich, als wären sie im gleichen LAN. Wer den Drucker in der Filiale drucken will, druckt. Wer auf das ERP im HQ zugreifen will, greift direkt zu. SMB-Shares verhalten sich wie im Büro. Die Latenz ist die jeweilige Standleitung, nicht Standleitung × 2 über die Hub-Firewall.

Austritts-IP an/aus: split vs. full tunnel

Eine Frage, die fast jeder Kunde irgendwann stellt: Soll der ganze Internet-Traffic vom Laptop auch durch die Firma-Firewall laufen? WireGuard regelt das über ein einziges Konfig-Feld pro Client: AllowedIPs.

• AllowedIPs = 10.91.0.0/24, 10.0.2.0/24 → Split Tunnel. Nur Firma-Netze gehen durch den Tunnel, der Rest geht übers Heim-Internet. Schnell, schont die Firewall-Bandbreite, Mitarbeitende können privat Netflix schauen, ohne die Firma-Leitung zu belasten.
• AllowedIPs = 0.0.0.0/0 → Full Tunnel. Der gesamte Traffic, inkl. Web, DNS, Updates, geht über die Firma-Firewall. Der Mitarbeiter ist bei aktivem VPN im Firmennetz – inklusive Webfilter, DNS-Block, TLS-Inspection. Die Austritts-IP im Internet ist die der Firma.

Wir exponieren diesen Schalter als bewusste Entscheidung. Für Baustellen-Laptops oder Admin-Geräte: Full Tunnel, damit der gleiche Schutz greift wie im Büro. Für Wissensarbeiter im Homeoffice: meistens Split Tunnel plus zusätzlicher lokaler Schutz (EDR), damit die Firma-Uplink nicht die 4K-Videokonferenz des Kindes rauten muss. Beides ist dieselbe Technik, nur ein anderes AllowedIPs-Feld.

Was davon braucht ein KMU mit 20 Mitarbeitenden wirklich?

Die ehrliche Antwort auf die Frage „reicht uns nicht der UPC-Router?" hängt an drei Dingen:

1. Wie viel eigenes Fachwissen liegt in welcher Infrastruktur? Eine Treuhand mit 12 Leuten, die hauptsächlich in Microsoft 365 arbeitet, hat vor allem ein Endgeräte- und Identitätsproblem (Conditional Access, MFA, EDR). Die Firewall darf solide sein, muss aber nicht spektakulär sein. Eine Anwaltskanzlei, die klassische Akten lokal verwaltet, profitiert deutlich stärker von DNS-Filter + TLS-Inspection, weil das LAN selbst noch Wert hat und ein Crypto-Trojaner reales Papier kostet.

2. Wie viele Standorte, wie viele Remote-Worker? Sobald man mehr als einen Standort hat oder regelmässig Externe einbinden muss, ist WireGuard-Mesh kein Luxus mehr, sondern spart real Arbeit. Routing-Troubleshooting in einer Hub-and-Spoke-Topologie kostet im Jahr mehr als ein neuer Router im dritten Standort.

3. Wer betreibt das Ding nach 18 Monaten? Die meiste Firewall-Debatte endet nicht beim Feature-Set, sondern bei der Frage, wer die Bypass-Liste pflegt, die CA erneuert, die Updates einspielt und die Alerts liest. Ein FortiGate, das nicht gewartet wird, ist auch nur ein Router mit mehr Lampen.

Zu uns

Wir betreiben diese OPNsense-Baseline (MIT-Firewall) intern und bei Schweizer KMU-Kunden. Der ganze Stack – Baseline-Konfiguration, TLS-Inspection mit lokaler MITM-CA-Auslieferung über unsere selbst entwickelte Geräteverwaltung auf Basis von Open-Source-Technologien, WireGuard-Mesh mit Full/Split-Tunnel pro User, DNS-Filter, AV-Scan, syslog-over-TLS an unser Monitoring – läuft im Betrieb als Managed Service. Preise und Scope sind auf der Netzwerksicherheits-Seite aufgelistet. Wenn jemand selbst baut: OPNsense ist offen, das meiste was wir tun, steht in der DSG-Diskussion um KI und Datenabfluss als Nachbar-Thema – Datenhoheit ist am Ende dieselbe Baustelle, nur an zwei Stellen.

---

Wenn Sie für Ihre Infrastruktur wissen möchten, wo zwischen „solide genug" und „volle Deep Inspection" der sinnvolle Punkt liegt: 30 Minuten reichen für eine ehrliche Einschätzung. Kontaktieren Sie uns.