​

So ähnlich wie im Titel kamen mir oft Admins vor, die den Windows Remote Desktop Port von 3389 auf 8888 gelegt haben, mit der Begründung die Server abzusichern.

Der Fachbegriff dazu heißt “Security by Obscurity” und auch ich bekenne mich schuldig. Ich habe auch schon öfters den Schlüssel auf den Reifen gelegt, wenn ich jemandem mein Auto geborgt habe. 🛞🔑

Wenn aber jemand weiß, wo der Schlüssel, die Datei oder der Port ist, dann taugt das "Sicherheitskonzept" auch nicht mehr.

Ein paar Klassiker

WLAN verstecken: Wer den Namen seines WLANs (SSID) nicht anzeigt, ist nicht sicherer, sondern sogar unsicherer. Bei jeder Verbindung muss nämlich der Netzwerkname mitgeschickt werden und das verursacht mehr WLAN Traffic, was die Identifizierung Entschlüsselung für Angreifer dann vereinfacht.

Ping abdrehen: Wer Ping (ICMP) deaktiviert, der nimmt der IT ein wichtiges Werkzeug zur Fehlersuche. Die Prüfung, ob eine Netzwerkverbindung zwischen zwei Geräten möglich ist, ist dann nicht mehr so komfortabel möglich. Ja, es erschwert den Aufwand für Angreifer, aber es gibt genug andere Möglichkeiten auch. ARP-Table, DNS, Port-Probing, etc.

Webserver Banner entfernen: Nein, das ist nicht der LinkedIn Banner im Profil, sondern die Informationen über den Webserver selbst. Also zum Beispiel "Server: Apache/2.4.41". Man findet die Infos über Port-Scans, oder auch in den HTTP-Metadaten. Entfernt man sie, ist der Webserver deswegen nicht gleich sicherer. Über das Provozieren von Fehlern, kann man Rückschlüsse über die Version trotzdem rausfinden.

Verstecke Admin-Seiten: Wer kennt sie nicht, die kryptischen URLs, hinter denen sich interessante Funktionen verstecken, wie "firma.tld/admin238237". Mit Hilfe von Crawlern und Code-Analyse lassen sich die Verweise auf diese Seiten oft finden.

Bekannte Service-Kennwörter: Genauso wie die Admin-Seiten sind auch die "Service-Zugänge" bei verschiedenen Geräten im Internet einfach zu finden. Egal, ob es um PV-Anlagen, Waschmaschinen, Steuerungen, Drucker oder sogar IT-Netzwerkgeräte geht. Die Hersteller lernen einfach nicht dazu. Wenn du bei Google "Default Admin + [Produktname]" eingibst, findest du alles.

Proprietäre Protokolle: Das ist die nächste Evolutionsstufe. Übertragungsprotokolle, die nicht öffentlich dokumentiert sind. Meistens findet man das in Industrie-Steuerungen, was die Bindung an den Hersteller noch verstärkt. Weil die Protokolle oft nicht so komplex sind, werden sie sogar von anderen Firmen analysiert, um günstigere und passende Produkte anzubieten.

Die unsichtbare Gefahr

Nur weil etwas unentdeckbar ist, heißt das noch lange nicht, dass es unhackbar ist. Wenn du denkst, du bist schlauer als Leute, die den ganzen Tag damit beschäftigt sind, fremde Systeme zu verstehen und auszunutzen, dann wirst du dich bald wundern.

Security by Obscurity, also Sicherheit durch Unklarheit, ist eigentlich kein gutes Konzept. Irgendjemand wird kommen und neugierig genug sein, um dein Puzzle zu lösen. Und er wird dann auch noch so stolz darauf sein, dass er einen Blog-Artikel im Internet darüber veröffentlicht.

Wenn das verworrene System bekannt wird, gibt es auch keine Barrieren mehr. Heute werden Systeme vollautomatisch analysiert und es werden Millionen an möglichen Kombinationen pro Sekunde ausprobiert. Auch wenn es für Menschen nicht sofort erkennbar ist: Ein Programm findet es. Hacker sind neugierig und experimentierfreudig. Eigentlich sind sie dafür gemacht, Systeme zu verstehen (Reverse Engineering).

Die bessere Alternative

Security by Design. Ja, ich weiß. Ein sehr abgedroschener Begriff und es gibt dafür auch keine allgemein gültige Definition dafür, wie so etwas aussehen sollte. Ich kann dir aber ein paar Beispiele nennen, die besser sind als ein reines Versteckspiel:

• Starke Authentisierung wie MFA, Passkeys und kryptografische Schlüssel
• Solide Autorisierung durch ein Rechte & Rollen Konzept
• Fail-Safe Defaults, wie kein Betrieb ohne Änderung des Admin-Kennworts
• Least-Privilege, also Berechtigungen nicht überdimensionieren
• Nur die Dienste und Funktionen aktivieren, die auch genutzt werden

Und die Stärke durch Transparenz darf man auch nicht unterschätzen. Wenn du die nötigen Sicherheitsvorkehrungen getroffen hast, kannst du auch zeigen, wo die Kronjuwelen liegen. In den letzten 20 Jahren hat sich nämlich gezeigt, dass Open Source nicht unsicherer als Closed Source ist. Windows und macOS wären sonst unhackbar und Linux ein offenes Scheunentor.

Das Prinzip von Kerckhoff aus dem Jahr 1883 beschreibt Prinzipien für militärische Kryptografie-Standards. Die Hauptidee ist, dass die Sicherheit eines Systems nicht davon abhängen darf, wie sein Design oder Algorithmus gestaltet ist. Sie sollte nur vom Schlüssel abhängen. Selbst wenn ein Angreifer alles weiß, bis auf den Schlüssel, muss es trotzdem sicher sein. Aktuelle Standards wie AES, TLS, Signal und WireGuard basieren auf diesem Prinzip.

Microsoft macht auch immer mehr Open Source und hat echt viel dazugelernt. Visual Studio Code ist auch Open Source. Die Community hat das Programm innerhalb von nur ein paar Jahren zu einem echt tollen Software-Stück gemacht und zu einem der beliebtesten Code-Editoren weltweit. Bugs wurden super schnell gemeldet und behoben, die Stabilität massiv verbessert und unzählige Features hinzugefügt. PowerShell mittlerweile genauso.

Zero Trust ist auch so ein Prinzip. Es bedeutet, dass man Systemen nicht automatisch wegen ihres Standorts vertrauen sollte. Egal ob im Netzwerk oder im Internet – Systeme werden gleichbehandelt. Man setzt auf Authentifizierung und Überprüfung. Damit du auf die sensiblen Daten zugreifen kannst, musst du dich erst sicher authentifizieren. Dein System wird dann auch noch einer Integritätsprüfung unterzogen. Wer besteht, darf rein.

Das Beste aus beiden Welten

Erst, wenn deine Sicherheits-Architektur (Design) solide ist, solltest du überlegen, ob du auch noch zusätzliche Verschleierungen einsetzen willst. Erwarte aber kein höheres Sicherheitsniveau, denn das wirst du nicht bekommen. Was du aber erhöhst, sind die Aufwände für Angreifer, um an ihr Ziel zu kommen. Zwar nicht wesentlich, aber du gibst deiner Verteidigung auch gleichzeitig mehr Chancen, Angreifer zu entdecken. 😎

Wenn mal hier und mal da ein Port gescannt wird, fällt das nicht so auf. Wenn ein Host aber über mehrere Wochen zigmal gescannt wird, solltest du hellhörig werden. Das gilt natürlich nur für interne Systeme, nicht für Systeme, die im Internet hängen.

Das Problem dabei ist nur, dass wenn dein System bekannt wird, gibt es kein Halten mehr. Stell dir mal vor, du änderst den SSH-Port deiner Linux-Server von 22 auf 9999. Wenn das jemand anhand eines einzelnen Servers entdeckt, sind automatisch alle davon betroffen. Das kann man auf verschiedene Weise herausfinden, zum Beispiel, indem man es einfach ausprobiert, in deinem internen Wiki nachschaut oder am Fileserver ein Config-File findet.

Fazit

Wenn du deine Sicherheit nur auf Verschleierung stützt, hast du ein echtes Problem. Während deine Admins sich jeden Tag durch das magische Labyrinth quälen, fliegen die Hacker einfach drüber und holen sich mühelos den Trimagischen Pokal. 🧙

Wenn du dich traust, deine interne Architektur im Internet zu posten und jedem zu zeigen, wo die Firmen-Geheimnisse liegen, dann hast du verstanden, worum es geht.