Fahrlässig ab Werk: Wenn die Installation des Herstellers das Netz gefährdet

Wer eine neue Fachanwendung einführt, verlässt sich meist darauf, dass der Hersteller sie sicher installiert. Schließlich kennt er sein Produkt am besten. In der Praxis erleben wir immer wieder das Gegenteil: frisch eingerichtete Systeme mit Schwachstellen, die seit Jahren in jedem Lehrbuch stehen. Das betrifft keine exotischen Nischenprodukte, sondern Software, die in vielen Betrieben und Verwaltungen täglich läuft.

Die Ausgangslage

Ein Kunde hat eine Branchenanwendung neu eingeführt, wie sie in vielen Organisationen läuft: ein Webportal für die Mitarbeitenden, eine Verwaltungssoftware an einigen Arbeitsplätzen und mehrere Geräte im Gebäude, die Daten an einen zentralen Server liefern. Die Installation hat der Hersteller selbst übernommen. Kurz darauf sollte das Webportal auch per VPN und von unterwegs erreichbar sein.

Bei der Vorbereitung fiel auf, dass die Anwendung in ihrem Auslieferungszustand nicht für einen sicheren Betrieb vorgesehen war. Die Befunde stammen aus einer einfachen Prüfung von Konfiguration, Logdateien, Netzwerk und Installationspaket – ohne Spezialwerkzeuge und ohne Angriffsversuche.

Was wir gefunden haben

Warum das kein Kavaliersdelikt ist

Jeder dieser Punkte ist für sich ein Mangel. Gefährlich wird es durch das Zusammenspiel:

• Kennwörter werden wiederverwendet. Viele Mitarbeitende nutzen im Webportal dasselbe Kennwort wie für ihre Windows-Anmeldung. Läuft das Portal über HTTP, reicht ein kompromittierter Rechner im selben Netz, um Domänenkennwörter mitzuschneiden – im ungünstigsten Fall die der Leitungsebene oder von Administratoren.
• Fest eingebaute Zugangsdaten sind Generalschlüssel. Sie lassen sich mit Bordmitteln aus der Installationsdatei auslesen. Sind sie überall gleich, öffnet ein einziger Fund die Datenbanken aller Kunden, die ihren Datenbankserver nicht abschotten.
• Die Datenbank umgeht die Anwendung. Wer direkt auf die Datenbank zugreift, braucht keine Benutzerrechte in der Anwendung und kann Daten lesen oder verändern.
• Geräte werden zum Einstiegspunkt. Telnet-Zugänge auf Geräten mit unbekanntem Firmwarestand sind ein bekannter Weg ins Netz – und solche Geräte werden kaum überwacht.

Wer einmal im Netz ist, etwa über eine Phishing-Mail, findet so gleich mehrere offene Türen. Und keiner dieser Fehler erfordert Spezialwissen, um ihn zu vermeiden: Verschlüsselte Verbindungen sind seit Jahren Standard, fest eingebaute Kennwörter stehen in allen einschlägigen Schwachstellenkatalogen.

Unser Lösungsweg: ein Name, überall verschlüsselt

Die Mängel der Software selbst kann nur der Hersteller beheben. Was wir als Betreuer lösen können, ist der sichere Zugang. Das Ziel war:

• Ein einziger Name für alle Nutzer – im Haus, per VPN und von unterwegs.
• Durchgehend TLS, ohne Ausnahme für interne Zugriffe.
• Keine Eingriffe in die Anwendung, denn deren Konfiguration wird vom Hersteller-Werkzeug bei Updates neu erzeugt.
• Nur das freigeben, was wirklich gebraucht wird.

1. Reverse Proxy statt Portweiterleitung

Das Webportal wird nicht per Portweiterleitung ins Internet gehängt, sondern über den Reverse Proxy der Firewall (Web Application Firewall) veröffentlicht. Die Firewall nimmt die HTTPS-Verbindung mit einem offiziellen Zertifikat an, prüft die Anfragen und reicht sie intern an den Anwendungsserver weiter. Die Anwendung selbst bleibt unverändert.

Eine TLS-Konfiguration direkt auf dem Anwendungsserver haben wir bewusst verworfen: Sie wäre beim nächsten Update des Herstellers überschrieben worden, und das Zertifikat müsste an zwei Stellen gepflegt werden.

2. Dieselbe Regel auch nach innen – und DNS darauf ausrichten

Der entscheidende Schritt war, die Reverse-Proxy-Regel zusätzlich auf der internen Schnittstelle der Firewall einzurichten. Dazu kommt Split-DNS:

Im internen DNS wird dafür eine eigene Zone nur für diesen einen Namen angelegt, die auf die interne Adresse der Firewall zeigt. So bleibt der Rest der Domain unberührt.

Das Ergebnis: Alle Nutzer verwenden denselben Link, jede Verbindung ist verschlüsselt und läuft durch dieselben Schutzfilter. Es gibt keinen Sonderweg mehr für das interne Netz, kein Hairpin-NAT und keine zweite Zertifikatsverwaltung. Auch Links in automatischen E-Mails der Anwendung funktionieren dann überall, sobald dort der neue Name statt der internen IP-Adresse eingetragen ist.

3. Schutzfilter mit Augenmaß

Auf beide Regeln wirkt dieselbe Schutzrichtlinie: Filter gegen typische Web-Angriffe in einer zurückhaltenden Stufe, Sperre von Adressen mit schlechter Reputation, HSTS und Schutz gegen MIME-Sniffing. Funktionen, die Webanwendungen gern stören – etwa das Umschreiben von Formularen oder URLs –, bleiben aus. Für den externen Zugriff kommt eine Länderbeschränkung hinzu.

4. Gezielt sperren, was nicht nach außen gehört

Die Anwendung stellt neben dem Portal auch eine Schnittstelle für die Geräte im Gebäude bereit. Die wird ausschließlich intern gebraucht. In beiden Proxy-Regeln ist dieser Pfad deshalb für alle Netze gesperrt. Die Geräte sprechen weiterhin direkt mit dem Server, nicht über die Firewall.

5. Den Direktzugriff abschalten – mit Ansage

Solange der Server direkt erreichbar bleibt, fließen weiterhin Kennwörter im Klartext. Deshalb wird auf dem Server selbst per Host-Firewall eingegrenzt:

• Webport nur noch von der Firewall und den Geräten im Gebäude.
• Datenbankport nur noch von den Arbeitsplätzen, auf denen die Verwaltungssoftware tatsächlich läuft.

Damit niemand überrascht wird, gehen wir dabei in Stufen vor: Zuerst werten wir die Zugriffsprotokolle des Servers aus und sehen so, welche Rechner noch alte Lesezeichen nutzen. Dann wird der neue Link per Gruppenrichtlinie verteilt und ein Stichtag angekündigt. Erst danach wird die Sperre aktiv.

Der Rechtsrahmen zieht an

Mit dem Cyber Resilience Act (Verordnung (EU) 2024/2847) setzt die EU genau hier an. Die Verordnung wird stufenweise wirksam:

Was heute noch als Mangel hingenommen wird, ist damit bald ein Verstoß gegen geltendes Produktrecht. Es lohnt sich, das schon bei der Beschaffung einzufordern.

Fragen für die nächste Herstellerinstallation

Einordnung

Die Verantwortung für sichere Produkte liegt beim Hersteller. Betreiber und IT-Dienstleister können vieles abfangen: mit einem Reverse Proxy, sauber geplantem DNS, Host-Firewalls und klaren Abnahmekriterien. Ein Ersatz für sicher entwickelte und sicher ausgelieferte Software ist das nicht. Wer Sicherheitsanforderungen schon in die Beschaffung schreibt und die Installation abnimmt statt sie nur entgegenzunehmen, muss später seltener reparieren, was ab Werk hätte stimmen müssen.

Unbequem bleibt die Konsequenz: Mängel wie diese gehören sachlich und schriftlich an den Hersteller. Reagiert er nicht und sind erkennbar viele Kunden betroffen, ist das BSI der richtige Ansprechpartner. Eine eigene Veröffentlichung technischer Details hilft niemandem und gefährdet andere Betreiber.

Quellen & weiterführende Links

• MITRE

  CWE-798: Use of Hard-coded Credentials
• MITRE

  CWE-319: Cleartext Transmission of Sensitive Information
• Rödl & Partner

  EU Cyber Resilience Act – Cybersecurity wird zur Produkt-Compliance