Das Tor zu einem neuen Universum

29. Juni 2022
Das Tor zu einem neuen Universum

Bei Wordfence sorgen wir dafür, dass über 4 Millionen WordPress-Websites sicher sind und bleiben. Ich komme aus dem Netzwerkbetrieb und bin dann in die Softwareentwicklung gewechselt, weil ich in meiner Rolle im Betrieb eine Menge Code schreiben musste. Das führte mich zur Gründung von Start-ups und schließlich zur Gründung des Cybersicherheitsunternehmens Wordfence. Aber ich habe mir die Ops-Perspektive bewahrt, und wenn ich über die Sicherung eines Netzwerks nachdenke, denke ich meist an Ports.

Du kannst finden eine ziemlich erschöpfende Liste von TCP- und UDP-Ports auf Wikipedia, aber für diese Diskussion wollen wir uns auf ein paar der beliebtesten Ports konzentrieren:

  • 20 und 21 - FTP
  • 22 - SSH
  • 23 - (Nur ein Scherz. Du solltest besser nicht mit Telnet arbeiten)
  • 25 - E-Mail über SMTP
  • 53 - DNS
  • 80 - Unverschlüsseltes Web
  • 110 - POP3 (für ältere E-Mail-Clients)
  • 443 - Web verschlüsselt über TLS
  • 445 - Active Directory oder SMB-Freigabe
  • 993 - IMAP (für E-Mail-Clients)
  • 3306 - MySQL
  • 6378 - Redis
  • 11211 - Memcached

Wenn du dir diese Liste ansiehst, wird dir etwas Interessantes auffallen. Für die meisten dieser Ports stehen dir nur sehr wenige Dienste zur Verfügung. Einige von ihnen sind spezifisch für eine einzelne Anwendung, wie Redis. Andere, wie SMTP, bieten eine begrenzte Anzahl von Anwendungen, entweder proprietär oder Open-Source. In beiden Fällen kannst du die Konfiguration der Anwendung ändern, aber es ist selten, eine eigene Anwendung für einen dieser Ports zu schreiben. Außer Port 443.

Im Fall von Port 443 und Port 80 gibt es nur eine begrenzte Anzahl von Webservern, die auf diesen Ports lauschen, aber die Nutzer schreiben eine riesige Auswahl an maßgeschneiderten Anwendungen auf Port 443 und haben eine riesige Auswahl an Anwendungen, die sie auf diesem Port hosten können. Das reicht von WordPress über Drupal bis hin zu Joomla und vielem mehr. Es gibt riesige Listen von Content Management Systeme.

Du hast nicht nur eine große Auswahl an Standard-Webanwendungen, die du auf Port 443 oder (wenn du dumm bist) auf Port 80 ausführen kannst, sondern du hast auch eine Sprachen, in denen sie programmiert sein könnenoder in denen du deine eigene Webanwendung programmieren kannst. Denk daran, dass der Webserver in diesem Fall ähnlich wie ein SSH- oder IMAP-Server auf dem Port lauscht und Verbindungen verarbeitet. Der Unterschied besteht jedoch darin, dass er die Ausführung an diese Sprachen, ihre verschiedenen Entwicklungsframeworks und schließlich an die Anwendung weitergibt, die ein Entwickler zur Bearbeitung der eingehenden Anfrage geschrieben hat.

Bei SSH, SMTP, FTP, IMAP, MySQL, Redis und den meisten anderen Diensten ist der Prozess, der auf dem Port lauscht, der Prozess, der die Anfrage bearbeitet. Bei Web-Ports leitet der Prozess, der auf dem Port lauscht, die eingehende Verbindung an eine andere Anwendung weiter, die in der Regel in einer anderen Sprache geschrieben ist und auf der Anwendungsschicht läuft, die Teil des extrem großen und vielfältigen Ökosystems von Webanwendungen ist.

Dieses Konzept an sich - dass die Anwendungen, die auf den Web-Ports lauschen, extrem vielfältig sind und entweder selbst entwickelt oder aus einem großen und vielfältigen Ökosystem ausgewählt wurden - stellt einzigartige Sicherheitsherausforderungen dar. Im Fall von Redis könntest du dir Gedanken darüber machen, wie du eine sichere Version von Redis einsetzen und sicherstellen kannst, dass sie nicht falsch konfiguriert ist. Bei einem Webserver hast du vielleicht 50 Anwendungsinstanzen in zwei Sprachen von fünf verschiedenen Anbietern, die alle auf demselben Port laufen und die alle korrekt konfiguriert sein müssen, deren Patch-Levels gewartet werden müssen und die mit sicheren Programmierpraktiken geschrieben werden müssen.

Als ob das nicht schon schwierig genug wäre, sind die Webports auch noch größtenteils öffentlich. Sieht man einmal von den internen Websites ab, besteht der Wert der meisten Websites darin, dass sie den Nutzern im Internet Dienste zur Verfügung stellen, indem sie öffentlich zugänglich sind. Wenn du dir die Liste der Ports ansiehst, die ich oben aufgeführt habe, oder in dem Wikipedia-Artikel den ich verlinkt habe, sind viele dieser Ports nur in internen Netzwerken geöffnet oder der Zugang zu ihnen wird kontrolliert, wenn sie extern sind. Web-Ports für öffentliche Websites müssen von Natur aus öffentlich zugänglich sein, damit sie nützlich sind. Es gibt bestimmte öffentliche Dienste wie SMTP oder DNS, aber wie ich bereits erwähnt habe, ist in diesen Fällen der Server, der den Port abhört, der Server, der die Anfrage bearbeitet.

Eine weitere Herausforderung bei der Absicherung von Websites besteht darin, dass ein Angreifer bei der Kompromittierung einer Website oft mehr Geld und Daten erbeuten kann als bei der Kompromittierung eines Unternehmensnetzwerks. Dies zeigt sich zum Beispiel bei E-Commerce-Websites, auf denen ein kleines Unternehmen eine große Anzahl von webbasierten E-Commerce-Transaktionen unter 100 US-Dollar abwickelt. Wenn der Angreifer das Unternehmensnetzwerk über durchgesickerte AWS-Anmeldeinformationen kompromittiert, kann er sich Zugang zum Bankkonto und zum geistigen Eigentum des Unternehmens verschaffen, die Daten des Unternehmens mit Ransomware verschlüsseln oder vielleicht sogar persönliche Daten der Kunden erlangen. Wenn sie jedoch die E-Commerce-Website kompromittieren, können sie sich Zugang zu Kreditkartennummern verschaffen, die weitaus handelbarer sind und bei denen die Summe der verfügbaren Guthaben aller Karten größer ist als das gesamte Vermögen des Kleinunternehmens, einschließlich des Betrags des Lösegelds, den das Unternehmen möglicherweise zahlen kann.

Nicht zu vergessen sind Datenpannen wie die von Equifax im Jahr 2017, bei der 163 Millionen amerikanische, britische und kanadische Bürger betroffen waren. Diese Daten waren für die Angreifer extrem wertvoll. Aber solche Ziele sind selten, und das Internet bietet ein reichhaltiges Umfeld für Angriffe. Das ist der dritte Punkt, den ich in diesem Beitrag ansprechen möchte. Während ein Unternehmen vielleicht eine Handvoll Dienste auf anderen Ports betreibt, haben viele Unternehmen - insbesondere Hosting-Anbieter - eine große Anzahl von Webanwendungen im Einsatz. Und es ist viel wahrscheinlicher, dass eine Person oder ein Unternehmen einen Dienst auf einem Web-Port laufen lässt als auf einem anderen Port. Viele von uns haben eine Website, aber wie viele von uns betreiben ihr eigenes DNS, SMTP, Redis oder einen anderen Dienst, der auf einem anderen Port als 80 oder 443 läuft? Die meisten von uns, die Websites betreiben, lassen auch MySQL auf Port 3306 laufen, aber dieser Port sollte nicht öffentlich zugänglich sein, wenn er richtig konfiguriert ist.

Dass die Sicherheit von Port 443 anders ist, ist uns bei Wordfence im Laufe der Jahre klar geworden, als wir eine riesige Anzahl von Malware-Varianten, Web-Schwachstellen und eine breite Palette von Taktiken, Techniken und Verfahren (TTP), die Angreifer gegen Webanwendungen einsetzen, verfolgt und katalogisiert haben. Die meisten von ihnen haben keine Beziehung zu dem Webserver, der auf Port 443 lauscht, und fast alle haben eine enge Beziehung zu der Webanwendung, an die der Webserver die Kontrolle abgibt, sobald die Kommunikation hergestellt ist.

Ich hoffe, dass ich mit diesem Beitrag dazu beitragen kann, Port 443 und den anderen unsicheren Port (80), den wir alle hoffentlich nicht benutzen, anders zu betrachten. Port 443 ist nicht nur ein weiterer Dienst. Er ist vielmehr das Tor zu einem ganz neuen Universum von Programmiersprachen, Entwicklungsframeworks und Webanwendungen.

In den meisten Fällen ist das Tor zu diesem neuen Universum öffentlich zugänglich.

Sobald ein Angreifer dieses Tor passiert hat, ist es sinnvoll, die auf dem Server gehosteten Webanwendungen als einen eigenen Dienst zu betrachten, der mit einem Patch-Level versehen und korrekt konfiguriert werden muss und der entfernt werden sollte, wenn er nicht benutzt wird, um die Angriffsfläche zu verringern.

Wenn du ein Webentwickler bist, denkst du vielleicht schon so und vernachlässigst Dienste an anderen Ports als Port 80 oder 443. Wenn du ein Betriebsingenieur oder ein Analyst bist, der in einem SOC arbeitet, das ein Unternehmensnetzwerk schützt, denkst du vielleicht, dass Port 443 nur ein weiterer Port ist, den du sichern musst.

Betrachte Port 443 als Tor zu einem neuen Universum, das keine Zugangskontrolle hat, da HTTPS einen einfachen, standardisierten Zugang bietet und auf der anderen Seite eine Vielzahl von verschiedenen Diensten läuft, die einem Angreifer ein Ziel und eine Umgebung mit vielen Ressourcen bieten.

-

Fußnote: Wir werden dieses Jahr auf der Black Hat in Las Vegas am Stand 2514 zwischen dem Haupteingang und der Innovation City ausstellen. Unser gesamtes Team von über 30 Leuten wird dort sein. Wie immer werden wir tolle Werbegeschenke haben. Komm vorbei und sag hallo! Unser Team wird auch an der DEF CON teilnehmen, die direkt nach der Black Hat stattfindet.

Geschrieben von Mark Maunder - Gründer und CEO von Wordfence.

Quelle


Dieser Artikel ist im Original von www.wordfence.com und wurde übersetzt
https://www.wordfence.com/blog/2022/06/securing-port-443/

Abonniere den RSS-Feed von unseren WP News und verpasse keine Meldung: https://die-mainagentur.de/feed/?post_type=wp-news

Alternativ kannst du unseren WP-Newsletter abonnieren

Mit dem Eintrag in den WP-Newsletter bekommst du per Mail über neue Artikel zugesendet. Du kannst den Newsletter jederzeit abbestellen.
Mehr dazu in der Datenschutzerklärung