Einleitung

Täglich kann man von Unternehmen lesen, die Opfer von Cyberangriffen geworden sind. Wie es zu diesen Angriffen kam und welche Schwachstellen ausgenutzt wurden, um in die internen Systeme der Unternehmen einzudringen, bleibt in der Berichterstattung meist unklar. Ein wichtiges Einfallstor – gerade wenn es um kompromittierte Server und Webseiten geht – sind technische Schwachstellen in der verwendeten Software.

Deshalb stellt sich die Frage: Wie schwierig wäre es, einen “Gesundheitscheck” über den gesamten .de-Domainraum durchzuführen. Ganz im Sinne eines regelmäßigen Arztbesuches, einfach mal die klassischen Probleme abfragen, ohne bei jedem Thema zu tief in die Materie einzusteigen. Die Antwort: Es ist schockierend einfach.

Vorgehensweise

Als Erstes musste ich mir einen Überblick über alle .de-Domains verschaffen. Da aber die DENIC, die die .de-Domains verwaltet, ihr sog. Zone-File, in dem alle .de-Domains dokumentiert sind, nicht ohne weiteres herausgibt, musste ich nach anderen Lösungen suchen. Glücklicherweise beobachten wir als Lutra Security seit unserer Gründung den globalen Domainraum. Das bedeutet, dass ich einfach auf unseren Datensatz zugreifen kann, ohne manuell scannen zu müssen. Daraus ergeben sich ca. 27 Millionen .de-Domains inklusive Subdomains (im Folgenden werden Domains und Subdomains mit dem Begriff Domains zusammengefasst).

Die reine Auflistung der Domains lässt aber zunächst keine Aussage über den Sicherheitsstatus zu. Diese Domains aktiv zu scannen war mir zu plump, deshalb wollte ich einen Ansatz finden, bei dem ich als potentieller Angreifer passiv an die Informationen herankomme. Ich brauchte also einen Plan, um möglichst passiv an die gewünschten Daten zu kommen. Im Klartext heißt das, dass die Betreiber der Systeme hinter den Domains keine verdächtigen Anfragen von meinen Systemen erhalten sollten. Das bedeutet, aktive Portscans, Vulnerability Scans und dergleichen scheiden aus.

Zudem helfen mir die reinen Domainnamen nur bedingt weiter, da die Sicherheitslücken der darunter liegenden Systeme auf IP-Ebene betrachtet werden müssen. Deshalb folgte hier der einzige “aktive Scan” meinerseits: Das Auflösen der 27 Millionen Domains auf ihre zugeordneten IP-Adressen. Heraus kamen etwas mehr als 6,2 Millionen IP-Adressen. Nun galt es noch, möglichst viele Metainformationen zu erhalten, um auf deren Basis eine erste Einschätzung vornehmen zu können.

Zum Glück gibt es Dritte, die diese Aufgabe übernehmen und täglich das gesamte Internet scannen und sich damit bei den Betreibern der betroffenen Systeme unbeliebt machen. Einziges Problem dabei: Die Geschäftsmodelle der Dritten sehen nicht vor, dass man die gesammelten Informationen von 27 Millionen Domains bzw. 6,2 Millionen IP-Adressen auf einen Schlag einsehen kann. Nach einigen Recherchen, der Zusammenführung mehrerer öffentlich zugänglicher Quellen mit qualitativ hochwertigen Informationen und dem Aufbau einer eigenen Infrastruktur zur Verarbeitung dieser Daten hieß es abwarten. Zu meiner eigenen Überraschung dauerte es nur 4 Tage, bis ich alle Informationen hatte, die ich brauchte.

Die Auswertung und Bewertung der Daten wird nun die nächste Zeit in Anspruch nehmen. Ich werde die Ergebnisse meines “Healthchecks” auf mehrere Artikel aufteilen müssen, da sich sonst die Ergebnisse in einem Artikel gegenseitig die Show stehlen würden.

Hinweis: Anders als bei Artikeln dieser Art üblich, empfehle ich technisch versierten Lesern, sich hauptsächlich auf die bunten Bilder zu konzentrieren. Technisch weniger versierten Lesern empfehle ich, zusätzlich den Artikel Was sind Ports und Services zu lesen, um ein oberflächliches Grundverständnis für das Thema zu bekommen.

Top 10 häufigste Ports

Beginnen möchte ich mit den Ergebnissen zum Thema offene TCP-Ports (UDP-Ports werden in diesem Artikel nicht betrachtet). Auch wenn mich die Ergebnisse im Großen und Ganzen nicht wirklich überrascht haben, gab es doch einige Dinge, die ich so nicht erwartet hatte. Deshalb hier der Klassiker, eine Top 10 nach Häufigkeit, die eigentlich auch sehr erwartbar und relativ harmlos erscheint.

Die Top 3

In den Top 3 sehen wir alte Bekannte wie die für Webseiten zuständigen HTTPS bzw. HTTP-Ports 443 (HTTPS) und 80 (HTTP), gefolgt von dem viel genutzten alternativen Web-Port 8089. Auch wenn es wahrscheinlich an meinen Erfahrungen mit dem Thema IT-Sicherheit liegt, war ich doch sehr überrascht (wenn auch positiv überrascht), dass das verschlüsselte HTTPS-Protokoll endlich das unverschlüsselte HTTP-Protokoll in seiner Masse überholt zu haben scheint. Aus Sicht der IT-Sicherheit könnten diese Ports kaum langweiliger sein, aber wenn man bedenkt, dass unser Internet in seiner Masse hauptsächlich aus Webseiten und HTML-Inhalten besteht, ist das Ergebnis auch nicht verwunderlich.

Platz 4-6

Die Plätze Vier bis Sechs sind zwar vorhersehbar, können aber sicherlich in langen und ausufernden Diskussionen unter Branchenkollegen enden.

Beginnen wir mit dem vierten Platz: Port 22 (SSH), der dazu dient, sich mit einem Server zu verbinden, um dort Befehle auszuführen. Wie bei vielen Themen, wenn es um IT-Sicherheit geht, ist die Tatsache, dass ein SSH-Port offen im Internet erreichbar ist, nicht unbedingt ein Problem. Jedoch sollte man sich auch immer die Fragen stellen: “Wie ist das Ganze konfiguriert? Hat man sich hier ausreichend Gedanken gemacht?” Denn ein schlecht konfigurierter SSH-Dienst kann zum Albtraum eines jeden Administrators werden, wenn er sich mit ungebetenen Gästen auf seinem Server herumschlagen muss.

Platz Fünf belegt Port 25 (SMTP) und ist ein Kandidat, der auch immer wieder die Gemüter unter Kollegen zum Kochen bringt. Das SMTP-Protokoll (Simple Mail Transfer Protocol), das zum Senden und Empfangen von E-Mails genutzt wird, ist per Design unsicher. Themen wie Authentifizierung oder Autorisierung spielten bei der Veröffentlichung des Protokolls 1982 (siehe RFC 821) keine große Rolle. Auch spätere Iterationen waren nicht wirklich zukunftssicher konzipiert, obwohl zumindest der Versuch gemacht wurde. Schlecht konfigurierte SMTP-Server werden z.B. immer wieder gerne von Scammern und Spammern ausgenutzt, weil man damit ggf. Mails verschicken kann, ohne sich authentifizieren zu müssen.

Auf dem sechsten Platz findet sich Port 21 (FTP), das wahrscheinlich einzige Problemkind unter diesen Plätzen. Auch hier haben wir es mit einem Protokoll zu tun, das in den 80er Jahren veröffentlicht wurde und bis heute munter verwendet wird. Auch wenn die Möglichkeit, Dateien mit wenig Aufwand von und zu einem Server zu verschieben, sehr praktisch ist, gibt es genügend Alternativen, um nicht mehr auf das FTP-Protokoll angewiesen zu sein (und sei es nur das sicherere SFTP-Protokoll). Wenn ich mir die Infrastruktur der deutschen Domains anschaue, muss ich wohl auch viele Hosting-Provider in die Verantwortung nehmen. Wenn ich für meine 1€-Domain im Monat den Server mit tausenden anderen Kunden teile, dann ist es als Anbieter nicht attraktiv, meinen Kunden diesen wirklich sehr einfachen Weg sich mit dem Server zu verbinden zu nehmen.

Platz 7-9

Der siebte Platz wird von Port 465 (SMTPS) belegt. SMTPS (Simple Mail Transfer Protocol Secure) macht nicht viel anderes als SMTP (unser Platz fünf), jedoch wird die Kommunikation über eine verschlüsselte TLS-Schicht durchgeführt (ähnlich wie bei HTTP und HTTPS).

Der achte Platz gehört Port 993 (IMAP), der wie Port 25 und Port 465 für die E-Mail Kommunikation relevant ist. Wie bei allen Dingen in der IT-Sicherheit stellt ein gut konfigurierter IMAP-Dienst kaum ein Sicherheitsproblem dar und ist wahrscheinlich eher am unteren Ende der Liste problematischer Ports zu finden.

Platz neun belegt 587 (SMTP), ein weiterer Port für E-Mail-Dienste.Auch hier könnte man sich sicherlich in quälend langen Diskussionen verlieren, ob nun Port 587 mit STARTTLS oder Port 465 mit implizitem TLS verwendet werden soll, aber das passiert schon seit vielen Jahren und wenn meine Erfahrung eines zeigt: Am Ende macht jeder was er will.

Platz 10

Das Schlusslicht der Top 10 bildet wiederum ein HTTPS-Port, nämlich Port 8443. Dieser wird gerne als Alternative für Webserver verwendet und nur allzu oft findet man hier Admin-Portale, Proxy-Server oder ähnliches. Port 8443 ist zwar ein sog. “inoffizieller” Port, wird aber sehr oft als Alternative zu Port 443 verwendet.

Die wirklich interessanten Ports

Wie bei so vielen Dingen im Leben findet man die spannendsten Dinge selten in einer Top 10 Liste. So ist es auch hier. Wenn ich mich in die Rolle eines Angreifers versetze, besteht ein großer Teil meiner Arbeit darin, die kleinen Details zu erkennen und die wirklich interessanten Angriffspunkte aus der Masse herauszufiltern.

So war es auch bei diesem Forschungsprojekt. Denn aus über 5000 verschiedenen gefundenen offenen Ports galt es, die besonders interessanten herauszufiltern. Auf diese möchte ich daher im Folgenden “kurz” eingehen. Dabei ist zu beachten, dass die Reihenfolge der Häufigkeit und nicht der Problematik o. ä. entspricht.

Hinweis: Es gilt zu beachten, dass insbesondere bei gefunden Servern im vierstelligen Bereich davon ausgegangen werden kann, dass eine nicht vernachlässigbare Anzahl davon sog. Honeypots (siehe Wikipedia Honeypots) sind. Wenn man bedenkt, dass selbst die Telekom über 6.000 Honeypots betreibt, werden die Ergebnisse hier auch durch diese beeinflusst sein.

5060 Session Initiation Protocol (SIP)

SIP wird hauptsächlich im Rahmen der IP-Telefonie verwendet, um eine Verbindung zwischen den Teilnehmenden herzustellen. Das “Tolle” daran ist, dass SIP standardmäßig unverschlüsselt kommuniziert und wie bei so vielem in der IT-Landschaft die Sicherheit meist nicht an erster Stelle steht.

Hier zeigen sich sehr viele Probleme: Bei über 85.000 Servern, auf denen ein offener SIP-Port gefunden wurde, wundert es mich momentan eher, dass nicht mehr Angriffe gegen diese gefahren werden. Klassische Angriffe sind u.a:

• Registration Hijacking: Die Identität eines SIP-Benutzers wird übernommen, um damit unerlaubt Anrufe zu tätigen, entgegenzunehmen oder weiterzuleiten.
• Eavesdropping: Ohne geeignete Verschlüsselung kann die Kommunikation über SIP abgehört werden.
• SIP Spoofing: Es werden manipulierte Pakete an den Server gesendet, um an laufenden Gesprächen teilzunehmen.
• Toll Fraud: Schwachstellen in SIP-Servern werden ausgenutzt, um Anrufe auf Kosten des Betreibers zu tätigen.
• SIP Invite Flooding: Sog. SIP INVITE Nachrichten werden an den Server gesendet, um ihn davon abzuhalten, legitime Anrufversuche anzunehmen.

Mit sehr viel Optimismus hoffen wir also, dass die Betreiber, dass die Betreiber dieser Services, obwohl diese auf Port 5060 anstatt auf dem TLS Port 5061 laufen, folgende Maßnahmen getroffen haben:

• Starke Authentifizierung
• Verschlüsselung (z.B. über TLS)
• Geeignete Firewall und IP-basierte Regeln
• Einsatz eines IDS (Intrusion Detection System) oder IPS (Intrusion Prevention System)
• Regelmäßige Updates und Patches der Systeme
• Ein geeignetes Rate-Limit, um DoS oder Brute-Force-Angriffe zu verhindern.
• Ein SIP Application Layer Gateway
• Ein geeignetes Monitoring- und Logging-System und regelmäßige Auswertung.

Dies mag auf den ersten Blick nach einer Menge Arbeit klingen, aber es muss gesagt werden, dass dies wahrscheinlich die Baseline ist, an der sich alle Systeme im Jahr 2024 orientieren sollten.

3306 MySQL

Bei über 60.000 gefundenen Servern mit offenem MySQL-Port kann ich die Hände der Angreifer schon förmlich zusammenschlagen hören. Denn was gibt es schöneres, als sich direkt mit einem Datenbankserver verbinden zu können, der vielleicht auch noch öffentlich bekannte Schwachstellen aufweist? Denn eines habe ich gelernt: Wenn die Datenbank einmal funktioniert, birgt jedes Update, jeder Patch, jede Änderung, das Risiko, dass sie danach nicht mehr so funktioniert. Und dieses Risiko will eigentlich niemand eingehen, wenn es darum geht, dass die Dinge einfach funktionieren. Ich muss auch ehrlich sagen, dass ich mich hier auch schwer tue, nicht wieder die immer wieder (un)beliebten “JETZT RIESIGE PREISKNALLER! EIGENE DE-DOMAIN INKLUSIVE WEBSERVER FÜR NUR 1€” Hoster in die Verantwortung zu nehmen. Denn zumindest meine Erfahrung hat in der Vergangenheit gezeigt, dass diese den Port für die MySQL-Datenbank standardmäßig offen halten, da ihre Kunden in der Regel keine technisch sehr versierten Menschen sind und man ihnen nicht zumuten kann, per VPN oder SSH-Tunnel auf den Datenbankserver zuzugreifen.

Das oft gehörte Argument “Die Betreiber werden doch für alle ihre Kunden eine sichere Baseline geschaffen haben, die sinnvoll skaliert” möchte ich hier übrigens nicht zählen lassen. Am Ende ist es die simple Kalkulation, dass Supportanfragen von unzufriedenen Kunden teurer sind als vereinzelte Sicherheitsvorfälle bei denselben. Und im letzteren Fall kann man die Schuld natürlich immer auf den Kunden schieben. Komfort ist bekanntlich der Feind von Sicherheit (ein Perlenvorhang ist entspannter als eine Tür mit Schloss) und ein komfortabler Kunde “verbraucht” weniger Support-Ressourcen. Dies ist wahrscheinlich auch der Grund dafür, dass die meisten technisch versierten Nutzer diese Produkte nicht verwenden und lieber die Kontrolle über ihre Systeme behalten, auch wenn dies zunächst einen höheren Einrichtungs- und Wartungsaufwand bedeutet.

500 Internet Security Association and Key Management Protocol (ISAKMP/IKE)

Mit knapp 31.000 Servern, bietet der Service, der normalerweise auf Port 500 läuft, ein gefundenes Fressen für Angreifer. Denn hier läuft in der Regel ein Service mit dem sog. Internet Key Exchange (IKE) Protokoll. Dies ist eine wesentliche Komponente vieler Enterprise VPNs (Virtual Private Networks) und ermöglicht den Aufbau einer sicheren Verbindung zwischen zwei Geräten (z. B. Client und Server) und ist damit oft ein Tor in ein internes Netzwerk eines Unternehmens.

Es ist bspw. keine zwei Jahre her, dass eine Schwachstelle in Form einer RCE (Remote-Code-Execution) im Windows Internet Key Exchange gefunden wurde (siehe CVE-2022-34721). Diese Schwachstelle in der Windows IKE Implementierung ermöglicht es einem Angreifer, beliebigen Code auf dem Server auszuführen und damit die Kontrolle über diesen erlangen und potenziell auch über das gesamte Netzwerk zu erlangen. Diese Sicherheitslücke verdeutlicht das hohe Risiko, das mit offenen und ungeschützten IKE-Diensten einhergeht.

VPNs sind nicht mehr wegzudenken und IKE spielt dabei eine kritischen Rolle. Daher ist es essentiell, dass Unternehmen ihre IKE-Implementierungen sorgfältig absichern oder sich möglicherweise mit alternativen Optionen auseinandersetzen.

5432 PostgreSQL

Mit “nur” knapp 13.000 Servern sind offene PostgreSQL Server zwar nicht so in der Masse vertreten wie es bspw. bei MySQL war. Jedoch muss man auch hier sagen, dass ein über das Internet erreichbarer Datenbankserver einfach ein Problem darstellt. Es ist sehr schwer ersichtlich, woher diese Menge überhaupt kommt, da meiner Erfahrung nach PostgeSQL nicht die erste Wahl bei günstigen Webspace-Hostern ist, da MySQL weiter verbreitet ist. Aber ich würde es auch nicht wagen zu sagen, dass es sich hier um reine Bastelaktionen handelt, deshalb ist es wohl am besten, darauf zu vertrauen, dass die Betreiber dieser Server früher oder später selbst herausfinden, dass Sie hier ein Problem haben.

3389 Remote Desktop Protocol (RDP)

RDP, ein alter Bekannter. Wir leben in einer Zeit, in der Home Office für viele glücklicherweise zum Arbeitsalltag gehört. Vor langer, langer Zeit war das Arbeiten von zu Hause aus noch ferne Zukunftsmusik. Gute VPN-Verbindungen zum Firmennetzwerk und sinnvoll konfigurierte Netzwerke sind es auch heute noch. Dennoch gab es schon immer den einen oder anderen Verantwortlichen, der seine Arbeit auch außerhalb des Büros erledigen “musste” und dafür eine Lösung benötigte. Und wenn es schnell gehen muss, braucht man keine gute Lösung, sondern irgendeine Lösung. Und diese Lösung heißt RDP - im Internet. Einfach mit den gewohnten Zugangsdaten über eine grafische Oberfläche am Arbeitsplatzrechner einloggen und wie gewohnt arbeiten. Das klingt bequem und einfach und ist es auch. Aber genau hier liegt auch das Problem.

RDP ist so “einfach”, dass es vergleichbar damit ist, wenn man seinen Rechner (oder in diesem Fall seinen Server) verschlossen auf die Straße stellt und Passanten nur Zugriff auf Maus, Monitor und Tastatur haben und man sich denkt “Das wird schon passen, meine Zugangsdaten kennt ja keiner”. Aufmerksame Leser merken wahrscheinlich, dass das ein Problem sein könnte. Und genau dieses Problem haben über 11.000 Server im .de-Domainraum.

135 Remote Procedure Call (RPC)

RPC ist eine Netzwerktechnik, die es Anwendungen erlaubt, bestimmte Befehle auf anderen Systemen so auszuführen, als wären sie lokal auf diesem System, und die im Gegensatz zu z.B. SSH normalerweise keine starken Sicherheitsmechanismen hat. Mehr braucht es wahrscheinlich nicht, um schon zu merken, warum solch ein Service nicht öffentlich im Internet erreichbar sein sollte.

Neben immer wieder veröffentlichten Schwachstellen im RPC-Protokoll, die es einem Angreifer erlauben, Befehle auf dem System und auch auf verbundenen Systemen auszuführen, ist RPC zusätzlich häufig anfällig für z.B. DoS-Angriffe, die das System überlasten und möglicherweise andere, davon abhängige Systeme damit unbrauchbar machen. Mit knapp 6.000 gefundenen Servern, die diesen Dienst im Internet anbieten, nähen wir uns den 0.1% der Gesamtmenge an gefundenen Servern, aber die absolute Zahl an sich ist immer noch erschreckend hoch.

445 Server Message Block (SMB)

SMB, ein gern gesehener Service bei internen Penetrationstests, Red-Teams oder Angriffssimulationen, ist ein Service der für die Freigabe von Dateien oder auch Druckern verwendet wird.

Als Angreifer ist dieser immer sehr interessant, da insbesondere freigegebene Dateien oft Informationen enthalten, die sich als sehr wertvoll herausstellen können. Und da es viele Tools (Programme) und gut dokumentierte SMB-Schwachstellen gibt, sollte so ein Service auch immer in den eigenen vier Wänden bzw. im internen Netzwerk nur vertrauenswürdigen Personen zur Verfügung gestellt werden. Damit haben wir eine Kombination aus diesem Service, Tools, die nur für den Angriff auf diesen Service entwickelt wurden und die freie Erreichbarkeit aus dem Internet.

Die Tatsache, dass hier über 5.000 Server zu finden sind, die den SMB-Dienst aus dem Internet erreichbar betreiben, halte ich für ein großes Problem.

5985 Windows Remote Management (WinRM)

WinRM ist ein Protokoll von Microsoft, das es Benutzern ermöglicht, Windows-Systeme aus der Ferne zu verwalten. Die Hauptaufgabe dieses Protokolls (ähnlich wie RDP) besteht also darin, Systeme fernsteuern zu können.

In einem internen Netzwerk, in dem diese Systeme auf einem Server ohne angeschlossene Peripherie laufen, ist dies eine gute Möglichkeit für Administratoren, sich um die vielen verschiedenen Systeme zu kümmern, ohne jedes Mal von Server zu Server laufen zu müssen. WinRM wird deshalb auch eher für administrative Aufgaben genutzt, da es bspw. keine graphische Oberfläche wie bei RDP für den Benutzer vorsieht.

Und trotzdem ließen sich im Internet knapp 3.400 Server im deutschen .de-Domainraum finden, die nur darauf warten, dass sich jemand auf den Service verbindet und das darunterliegende System “administriert”. Natürlich müsste ein Angreifer, wie bei fast allen Services, eine Schwachstelle im Service, eine Fehlkonfiguration oder schwache Passwörter ausnutzen. Doch ähnlich wie bei SMB gibt es auch für WinRM zahlreiche Tools und gut dokumentierte Angriffsmöglichkeiten, die einem Angreifer das Leben leichter machen.

88 Kerberos

Kerberos, der dreiköpfige Hund aus der griechischen Mythologie und Wächter der Unterwelt, wird als beeindruckendes mythologisches Wesen beschrieben. Der Microsoft-Dienst Kerberos, der für die sichere Authentifizierung innerhalb von Netzwerken zuständig ist, ist allerdings oft eher ein verspielter kleiner Welpe, wenn man weiß, wie man mit ihm reden muss.

Das liegt jedoch nicht daran, dass dieser Dienst so simpel ist, sondern oft eher daran, dass er so komplex ist, dass selbst Administratoren mit jahrelanger Erfahrung immer noch Fehler in der Konfiguration passieren können, die bestenfalls bei einem internen Penetrationstest auffallen.

Da Kerberos für die Authentifizierung von Benutzern in einem Netzwerk verantwortlich ist, sollte dieser Dienst nur von Benutzern verwendet werden, die Zugang zu diesem Netzwerk besitzen sollen. Daher wird Kerberos normalerweise nur in internen Netzwerken zur Authentifizierung von Mitarbeitern verwendet.

Im deutschen .de-Domainraum wurden dennoch über 2.600 Server gefunden, die ihren Kerberos Service im Internet zur Verfügung stellen.

23 Telnet

Telnet stammt aus einer Zeit, in der es weder Apple noch Microsoft gab. Im Jahr 1974 wurde das Protokoll zum ersten Mal verwendet, um einen anderen Computer über ein Netzwerk fernzusteuern. Und da Telnet ein Kind der wilden 70er Jahre ist, waren Sicherheitsfunktionen eher zweitrangig. Es ging in erster Linie darum, ein Werkzeug zu haben, das die Arbeit erleichtert, und das war für die damalige Zeit angemessen und wichtig. Im Laufe der Zeit wurde Telnet dann von anderen Diensten wie z.B. SSH abgelöst, die zumindest einige Sicherheitsfunktionen schon bei der Entwicklung berücksichtigten.

Und doch lassen sich im deutschen .de-Domainraum noch über 1.200 Server finden, auf denen man dieses historische Protokoll bewundern kann. Sprüche zum Thema “Das Internet ist Neuland” möchte ich mir an dieser Stelle sparen, ich denke, das kann sich jeder selbst denken.

Top 10 Port-Kombinationen

Um zu verstehen, wofür Server verwendet werden, ist es oft ausreichend zu sehen, welche Ports auf diesen Servern offen sind. Aus diesem Grund habe ich nach einzigartigen Portkombinationen gesucht (wobei auch ein einzelner offener Port eine Port-Kombination ist).

Hier die Auflistung der Top 10 Kombinationen mit möglichem Einsatzzweck bzw. Services:

• 8089: Webserver mit Services für Analytics und Monitoring
• 80/443: Webserver mit klassischer Webseite, wahrscheinlich bei Drittanbieter
• 443: Webserver mit Webseite, möglicherweise für internen Gebrauch
• 22/80/443: Webserver mit klassischer Webseite, die selbst verwaltet wird
• 5060: VoIP Telefonie, wie hier im Artikel besprochen
• 80: Veralteter Webserver, möglicherweise für internen Gebrauch
• 80/443/2082/2083/2086/2087/8080/8443/8880: Server eines Hosting Anbieters
• 5080/8089: VoIP mit Webanwendung
• 22: Server, der hauptsächlich für Rechenleistung genutzt wird
• 21/22/80/443: Server eines Hosting Anbieters, der für Webanwendungen gedacht ist

Server nach Anzahl der offenen Ports

Und schließlich die Frage, wie viele Ports ein Server im .de-Domainraum offen hat. Hier war ich tatsächlich positiv überrascht, dass wohl die meisten Server nur wenige Ports offen haben, was darauf hindeutet, dass diese Server tatsächlich auch nur für einen bestimmten Zweck konfiguriert sind und nicht unzählige öffentlich erreichbare Services auf diesen laufen.

Fazit

Würde ich sagen, dass wir unsere Ports im deutschen .de-Domainraum im Griff haben und uns niemand “in die Karten schauen” kann? Klares Jein.

Auf der einen Seite gibt es kleine Highlights, wie z.B. dass der HTTPS-Port 443 den HTTP-Port 80 in der Masse abgelöst hat. Auch die Tatsache, dass offenbar die meisten Server im deutschen .de-Domainraum für einen bestimmten Zweck genutzt werden und nicht mit unzähligen Diensten im Internet erreichbar sind, finde ich sehr positiv.

Betrachte ich die Ergebnisse jedoch von der anderen Seite, ergibt sich für mich ein anderes Bild. Um es auf den Punkt zu bringen, möchte ich das Ganze aus der Sicht eines Angreifers zusammenfassen:

• Ich habe passiv Informationen aus öffentlichen Quellen gesammelt, ohne dass die Betroffenen eine Chance hatten, davon zu erfahren.
• Ich habe Informationen über mehrere 10.000 Server, die mit sehr hoher Wahrscheinlichkeit durch einen trivialen Angriff übernommen werden können, weil sie Dienste im Internet anbieten, die dort nicht hingehören (mehr dazu folgt im Artikel über die gefundenen Sicherheitslücken).
• Mit diesen Informationen kann ich zufällige Ziele auswählen, um sie anzugreifen, da ich bereits weiß, dass sie mit hoher Wahrscheinlichkeit technisch angreifbar sind.

Denn was ich hier getan habe, ist im Grunde das, was Angreifer wie Ransomware-Gruppen und sog. Advanced Persistent Threats jeden Tag tun. Der Spruch “Bevor es uns erwischt, erwischt es die Großen zuerst” stimmt einfach nicht. Wenn ich mein Netz auswerfe und immer weiter aussortiere, bis ich irgendwann eine große Zahl potenzieller Opfer habe, ist es mir egal, wer das ist, wenn ich weiß, dass ich mit minimalem Aufwand maximalen Ertrag erziele.

An dieser Stelle möchte ich mich bei allen bedanken, die es bis hierher geschafft haben. Die nächsten geplanten Artikel werden sich damit beschäftigen, wie der deutsche .de-Domainraum aufgebaut ist (welche Software/Services zum Einsatz kommen) und welche Schwachstellen gefunden werden konnten.