Portspoof: Eine Technik, die gültige Dienste auf allen 65.535 TCP-Ports emuliert

 (github.com/drk1wi)
1 Punkte von GN⁺ 2024-12-26 | 1 Kommentare | Auf WhatsApp teilen
  • Portspoof lässt alle 65.535 TCP-Ports so erscheinen, als wären sie offen, und emuliert Service-Signaturen. Dadurch wird die Reconnaissance-Phase eines Angreifers von einem schnellen Scan in eine lange und teure Aufgabe verwandelt.
  • Es gibt bei jedem Verbindungsversuch SYN+ACK zurück und lässt jeden Port mithilfe von mehr als 9.000 Regex-basierten dynamischen Service-Signaturen wie einen anderen legitimen Dienst antworten.
  • Beim Start werden pro Port gemischte Übertragungsmodi wie sofortiger Banner, verzögerte Antwort oder dauerhaft keine Antwort zugewiesen; Jitter bei der Haltezeit von Verbindungen erschwert timingbasierte Filterung.
  • Ein vollständiger Versionsscan nmap -sV -p- dauert mit der Standard-Tarpit-Konfiguration mehr als 10 Stunden und kann Hunderte MB an Fake-Daten erzeugen; dabei werden Zeit und Threads der Scanner des Angreifers verbraucht.
  • Die Implementierung nutzt eine Single-Thread-epoll-Event-Loop, läuft im User Space ohne Root-Rechte und bindet pro laufender Instanz nur einen TCP-Port.

Welches Problem Portspoof lösen will

  • Ziel von Portspoof ist es, die Reconnaissance von Angreifern langsam, teuer und unzuverlässig zu machen.
  • Statt dass ein typischer 5-Sekunden-Nmap-Scan die echten Dienste eines Systems abbildet, erscheinen vor Portspoof alle 65.535 Ports als offen.
  • Jeder Port sieht wie ein anderer legitimer Dienst aus, und das Design soll verhindern, dass sich schnell erkennen lässt, welcher Port tatsächlich einen echten Dienst bereitstellt.

Kernfunktionen

  • Antwort, als wären alle 65.535 TCP-Ports offen

    • Statt einen Port als CLOSED oder FILTERED zu melden, wird auf jeden Verbindungsversuch SYN+ACK zurückgegeben.

  • Service-Emulation

    • Verwendet mehr als 9.000 Regex-basierte dynamische Service-Signaturen.
    • Jeder Port antwortet auf Scanner-Probes mit einer anderen überzeugenden Service-Identität.

  • Gemischte Übertragungsmodi

    • Jeder Port erhält beim Start ein anderes Verhaltensprofil.
    • Sofortige Banner-Ausgabe, verzögerte Antworten und dauerhaftes Schweigen werden gemischt.
    • Haltezeiten sind über einen breiten Bereich verteilt, sodass eine Versionserkennung über den gesamten Portbereich mit nmap -sV -p- praktische Grenzen überschreitet.

  • Offensive Verteidigung

    • Kann als „Exploitation Framework Frontend“ genutzt werden, das auf Schwachstellen in den Scanning-Tools des Angreifers selbst abzielt.

  • Leichtgewichtiges Ausführungsmodell

    • Läuft im User Space.
    • Benötigt keine Root-Rechte.
    • Bindet pro laufender Instanz nur einen TCP-Port.
    • CPU- und Speicherverbrauch sind gering.

Wie Scanner und Versionserkennung verwirrt werden

  • Bei einfachen Portscans erscheinen selbst kleine Bereiche wie Port 1 bis 20 vollständig als open.
    • In Beispielausgaben werden Dienstnamen wie tcpmux, compressnet, echo, daytime und ftp-data gemischt angezeigt.
  • Bei Scans zur Versionserkennung werden gültige dynamische Signaturen auf Service-Probes zurückgegeben.
    • In einem Beispiel für Port 1 bis 100 erscheinen verschiedene Dienste und Versionsstrings wie irc, http, pop3, ssh, ftp, smtp, telnet und tor-control.
  • Dadurch wird es für Angreifer schwierig zu beurteilen, welche Portnummern das System tatsächlich nutzt.
  • Ein vollständiger Versionsscan nmap -sV -p- dauert mit der Standard-Tarpit-Konfiguration mehr als 10 Stunden und erzeugt Hunderte MB an Fake-Daten.
  • Der Scanner verbraucht Zeit und Threads für Verbindungen, die zu keinen echten Ergebnissen führen.

Designansatz: Single-Thread-epoll-Tarpit

  • Echte Dienste wie SSH, SMTP, FTP und HTTP senden Banner, halten Verbindungen offen und warten auf Client-Eingaben.
  • Eine überzeugende Emulation muss demselben Ablauf aus accept, send, hold folgen.
  • Ein Modell mit einem Thread pro Client verbraucht Speicher und CPU; durch die Kosten von Context Switching kann zuerst der Verteidiger seine Ressourcen erschöpfen.
  • Portspoof nutzt eine Single-Thread-epoll-Event-Loop.
    • Jeder Port erhält beim Start einen Übertragungsmodus.
    • Manche Ports senden sofort einen Banner, manche antworten erst nach Client-Daten, andere bleiben stumm.
    • Haltezeiten sind über mehrere Größenordnungen verteilt, von Dutzenden Millisekunden bis zu mehreren Minuten.
    • Jede Verbindung enthält Jitter, sodass wiederholte Erkennung desselben Ports nicht dasselbe Timing liefert.
  • Dieser Ansatz erschwert Angriffe, bei denen Garbage-Daten an alle Ports gesendet und Antwortzeiten gemessen werden.
    • Bei einer einfachen Tarpit kann der Unterschied entstehen, dass sie Verbindungen einige Sekunden festhält, während echte Dienste bei falschem Protokoll schnell schließen.
    • Mit gemischten Modi und breiter Timing-Verteilung schließen auch Tausende Fake-Ports in einem Bereich, der echten Diensten ähnelt.
    • Es gibt keinen sauberen Schwellwert mehr, der sich zum Filtern verwenden ließe.

Kostenasymmetrie

  • Die Kosten für den Verteidiger liegen bei etwa 1–2 KB Kernel-Speicher pro inaktiver Verbindung.
  • Die epoll-Loop ist Single-Threaded und hat daher keinen Context-Switching-Overhead.
  • Auch durchschnittliche Hardware kann mehr als 10.000 gleichzeitige Verbindungen verkraften.
  • Die Kosten des Angreifers verschieben sich auf Zeit und Aufwand.
    • Allein durch Portscans erscheinen alle Ports offen, sodass kaum verwertbare Informationen entstehen.
    • Um echte Dienste zu finden, sind Versionserkennung über alle 65.535 Ports und Protokoll-Level-Erkennung bei plausiblen Zielen nötig.
    • Ein 5-Sekunden-Scan wird zu mehr als 10 Stunden aktiver Arbeit, während die Ergebnisse weiterhin im Heuhaufen verborgen bleiben.

Änderungen in v2.0

  • v2.0 löst sich vom bisherigen Ansatz, nach dem Senden eines Banners die Verbindung zu schließen.
  • Der bisherige Ansatz war anfällig für die in einem Vicarius/Hored1971-Blogbeitrag beschriebene Umgehung über Verbindungsabbrüche.
  • Die neue Tarpit-Engine hält alle Verbindungen mit gemischtem Timing offen.
  • Dieser Ansatz soll Filterung nach Verbindungsabbrüchen, Timing-Fingerprinting, Banner-Analyse und statistische Mustererkennung verhindern.

Installation und Grundeinstellungen

  • Für den Build werden ein C++-Compiler und CMake 3.10+ benötigt.
  • Der Build aus dem Quellcode erfolgt wie folgt:
mkdir build && cd build
cmake -DCMAKE_INSTALL_SYSCONFDIR=/etc ..
make
sudo make install
  • Portspoof läuft im User Space, aber zum Abfangen von Traffic, der an andere Ports gerichtet ist, sind System-Firewall-Regeln erforderlich.
  • Der Standardport ist 4444; echte Service-Ports werden zuerst ausgenommen, danach wird der übrige TCP-Traffic zu Portspoof umgeleitet.
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j RETURN
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 4444
  • eth0 muss durch das tatsächliche Netzwerkinterface ersetzt werden.
  • Für jeden Port, auf dem ein echter Dienst läuft, muss eine RETURN-Regel hinzugefügt werden.
  • Für dauerhafte Anwendung können iptables-Regeln gespeichert oder iptables-config aus dem Verzeichnis system_files verwendet werden.
  • Für Startskripte können die Beispiele unter system_files/init.d/ verwendet werden.

Ausführungsmodi

  • Der empfohlene Modus ist der Service-Emulation-Modus.
    • Er erzeugt Fake-Service-Signaturen und liefert sie an Portscanner aus.
portspoof -c /etc/portspoof.conf -s /etc/portspoof_signatures -D
  • Benutzerdefiniertes Tarpit-Timing wird mit -t und -T angegeben.
    • Das Beispiel hält jede Verbindung 10 bis 60 Sekunden offen.
portspoof -s /etc/portspoof_signatures -t 10 -T 60 -D
  • Open Port Mode gibt ohne Service-Banner bei allen Verbindungsversuchen nur den Status OPEN zurück.
    • Die Verbindung wird dennoch als Tarpit behandelt.
portspoof -D
  • Fuzzing Mode kann genutzt werden, um zufällige oder wortlistenbasierte Payloads an Scanning-Tools zu senden.
portspoof -1 -v
portspoof -f payloads.txt -v

Härtung auf iptables-Basis

  • Schon die einfache REDIRECT-Regel funktioniert, aber aggressive Scanner können Portspoof durch viele Verbindungen unter Druck setzen.
  • Härtungsregeln ergänzen Rate Limiting und automatisches Blockieren.
    • Echte Service-Ports werden von der Umleitung ausgenommen.
    • Im Beispiel wird SSH-Port 22 ausgenommen.
    • Globale Blockierregeln gelten auch für echte Dienste.
  • Beispielregeln enthalten folgende Elemente:
    • Loopback erlauben
    • als PORTSCAN markierte IPs 60 Sekunden lang droppen
    • neue SYNs pro Quell-IP auf 10 pro Sekunde begrenzen, bei Burst über 30 droppen
    • wenn eine einzelne IP mehr als 100 Verbindungen zum Portspoof-Port 4444 offen hält, markieren und anschließend droppen
    • established/related Traffic und neue SYNs erlauben, danach den Rest droppen
  • Bei Deployments mit hohem Traffic kann die Listengröße von xt_recent erhöht werden.
echo "options xt_recent ip_list_tot=10000" > /etc/modprobe.d/xt_recent.conf
  • Auch Kernel-Connection-Tracking und Backlog-Einstellungen können angepasst werden.
sysctl -w net.netfilter.nf_conntrack_max=131072
sysctl -w net.core.somaxconn=4096

Portspoof Pro

  • Portspoof Pro erweitert Deception von einem einzelnen Host auf die Ebene eines gesamten Netzwerks.
  • Ein einzelner Sensor emuliert ein komplettes /16-Netzwerk.
    • Er stellt Tausende IPs bereit.
    • Jede IP hat auf allen Ports eigene Dienste.
    • Zustandsbehaftete mehrstufige Dialoge werden beibehalten.
  • Es bietet netzwerkweite Deception-Funktionen.
    • Dark-IP-Räume und ungenutzte Subnetze werden in ein aktives Deception Grid verwandelt.
    • Jeder emulierte Host zeigt je nach Quell-IP eigene Dienste mit unterschiedlicher Persönlichkeit.
    • Eine aktive Tarpit erschöpft den Socket-Pool des Angreifers und drosselt Automatisierungstools.
  • Es unterstützt Scan-Erkennung und Tool-Fingerprinting.
    • Erkennt SYN-, FIN-, NULL-, XMAS- und ACK-Scan-Techniken.
    • Führt Fingerprinting von Nmap, Masscan, ZMap und Custom-Scannern durch.
    • Streamt strukturierte JSON-Telemetrie mit MITRE-ATT&CK-Mapping an ein SIEM.
  • Es berücksichtigt Deployments in Betriebsumgebungen.
    • Läuft in einer Sandbox-Umgebung neben Production-Traffic.
    • Routing-Policies senden Deception-Traffic an den Sensor.
    • Es wird darauf hingewiesen, dass es keinen Inline-Tap und kein Risiko für echte Workloads gibt.
  • Unterstützt NIS2, DORA, ISO 27001, NIST CSF und CIS Controls.

Lizenz und Issue-Meldung

  • Portspoof steht unter der GNU GPLv2.
  • Für kommerzielle und legitime Anwendungen wird empfohlen, den Autor wegen geeigneter Lizenzvereinbarungen zu kontaktieren.
  • Bugs und Feature Requests können über den GitHub Issue Tracker oder per E-Mail gemeldet werden.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-26
Meinungen auf Hacker News

  • Es gibt 65.536 Ports, und Port 0 ist auf manchen Betriebssystemen ebenfalls ein Port, auf dem man einen aus dem Internet erreichbaren Dienst bereitstellen kann.
    Und falls ein MariaDB-Entwickler das liest: Die Standardeinstellung, eine Datenbank auf Port 0 lauschen zu lassen, um Internetzugriff zu verhindern, verhindert auf ziemlich vielen Systemen tatsächlich nicht, dass die DB aus dem Internet erreichbar ist.

    • MariaDB prüft ausdrücklich, ob der Port nicht 0 ist, bevor es auf einem TCP-Socket lauscht: https://github.com/MariaDB/server/blob/ae998c22b2ce4f1023a6c...
      if (mysqld_port) bedeutet, dass mysqld_port ungleich 0 ist, und dieses Verhalten scheint es mindestens seit MariaDB 5.5 zu geben.
    • Auch unter Linux kann man Port 0 verwenden, wenn man möchte. Direkt binden kann man ihn nicht, aber per Firewall kann man Port 0 auf einen anderen Port umleiten.

  • Computersicherheit scheint sich letztlich zwangsläufig weiter in Richtung aktiver Verteidigung dieser Art zu entwickeln.
    Wenn man sieht, wie komplex und vielschichtig das Immunsystem ist, werden Computer oder Netzwerke wohl irgendwann ähnlich aussehen.

    • Das wirkt immer noch eher wie passive Sicherheit, die auf Obfuskation setzt. Aktive Verteidigung wäre eher so etwas, wie bekannten Eindringlingen eine zip bomb zurückzuschicken, um deren Prozess zu beenden.
    • Auch die IT reift langsam heran. Wir beschäftigen uns erst seit ein paar Jahrzehnten ernsthaft mit Sicherheit, und den Großteil davon habe ich selbst miterlebt.
      Irgendwann wird IT ein hinreichend ausgereiftes Fachgebiet sein, aber heute ist es noch nicht so weit.
    • Die Analogie gefällt mir nicht besonders, weil das Immunsystem, etwa bei Allergien oder Krebs, häufig Fehlfunktionen hat und dem Wirt schadet.
      Wenn man diesen Aspekt einbezieht, sieht man allerdings sogar eine eher beunruhigende Parallele.
    • KI dürfte hochwertige, tiefgehende Honeypots ermöglichen. Das ist ein Anwendungsfall, der gut zu den heutigen Fähigkeiten von LLMs passt; es muss nur plausibel wirken.
    • Ich glaube nicht, dass die Haut so tut, als wäre sie ein Mund.

  • Um E-Mail-Harvesting-Spambots aufzuhalten, habe ich einmal eine Webseite gebaut, die unendlich viele zufällige E-Mail-Adressen erzeugt: http://web.archive.org/web/20020610054821/http://www.sourtim...

  • Wenn man so etwas laufen lässt, könnte es passieren, dass jemand meine Maschine scannt und mir Dutzende Bug-Bounty-Anfragen schickt, weil dort angeblich „eine bekannte verwundbare Version von X“ läuft.

  • Mitte der 90er gab es ein Honeypot-Produkt namens CyberCop Sting, das Ballista von Secure Networks vorausging.
    CyberCop Sting konnte TCP/UDP-Dienste verschiedener Implementierungen simulieren und, wenn ich mich richtig erinnere, auch das Verhalten des TCP/IP-Stacks so konfigurieren, dass es wie unterschiedliche Betriebssysteme aussah. Für vor fast 30 Jahren war das ziemlich innovativ.
    [1] https://theswissbay.ch/pdf/Gentoomen%20Library/Security/0321...
    [2] https://news.ycombinator.com/item?id=26440139

    • Interessant. Ich wollte gerade fragen, ob es ähnliche Projekte gab.
      Natürlich ist es etwas, das wohl irgendjemand gemacht haben dürfte; trotzdem finde ich es ein wenig überraschend, dass es mir vorher nie in den Sinn gekommen ist, und noch überraschender, dass ich von dieser Idee zum ersten Mal höre.

  • Ich vermute, dass das am Ende dazu führt, dass Hacker oder Bots den Server genauer untersuchen oder zumindest mehr Traffic darauf landet.
    Ich glaube nicht, dass die meisten Script Kiddies in ihren Tools potenzielle Honeypots oder solche Vorrichtungen herausfiltern.

    • Wenn drei zufällige Dienste so aussehen, als würde sie niemand mehr benutzen, wird ziemlich schnell klar, dass der Server portspoof laufen lässt.
      Aber nachdem man weiß, dass der Host lebt, ist die Frage, welchen Port man anfasst. Wenn man annimmt, dass die Kosten fürs Scannen oder Angreifen jedes Ports auf jedem Server ähnlich sind, ist es selbst dann, wenn man gespoofte Ports erkennen kann, besser, eine andere Maschine mit höherer Erfolgswahrscheinlichkeit zu suchen. Man könnte portspoof lokal auf 127.0.0.35 laufen lassen, um Antwortdaten oder Timing-Unterschiede zu vergleichen, aber der Suchraum wird plötzlich etwa 5000-mal größer als die wenigen Ports, die normalerweise offen sind, und Ports auf anderen Servern könnten erfolgversprechender wirken.
    • Auf gängigen Ports plausible Banner zurückzugeben, dürfte eher dazu führen, dass man stärker statt weniger auffällt.
      Die meisten Tools berücksichtigen nicht den Fall, dass alle Ports offen sind und dadurch False Positives entstehen. Bei Penetrationstests ist das eine häufige Situation und kann Zeit verschwenden, aber ich möchte Angreifern keinen Grund geben, sich meine Infrastruktur genauer anzusehen. Ich bevorzuge eher Port Knocking, also fast das genaue Gegenteil dieses Ansatzes.
    • Ich bin kein Netzwerksicherheitsexperte, aber der Traffic, der nötig wäre, um herauszufinden, was echt ist, dürfte dabei wahrscheinlich andere Erkennungsmechanismen auslösen.
    • Wenn man sich um großflächige Internet-Scans sorgt, sehe ich Nachteile. Wenn man sich aber um einen bestimmten Angreifer sorgt, der nur die IP-Bereiche einer Organisation scannt, könnte es ziemlich störend wirken.
    • Wenn man kurz darüber nachdenkt, scheint das Threat Model, bei dem dieses Tool hilft, begrenzt zu sein.
      Gegen breit angelegte Angriffe müsste es auf zig Millionen Hosts verteilt sein, um eine gewisse Wirkung zu haben; erst dann würde es für Angreifer unpraktisch, nur Honeypots zu finden und mit ihnen zu interagieren. Bei einem gezielten Angriff auf ein bestimmtes Ziel kann es zwar etwas verzögern, weil der Angreifer versucht, Honeypot-Ports auszunutzen, aber wenn man einen verwundbaren Dienst betreibt, wird man am Ende trotzdem kompromittiert. Und wenn man Anbieter ist, muss man unter Umständen sehr lästige Sicherheitsfragebögen beantworten, wenn das Sicherheitsteam eines potenziellen Kunden scannt.

  • Ich mache auf meiner Website etwas Ähnliches. https://bini.wales gibt für alle Endpunkte 200 zurück und protokolliert alle Versuche, wodurch es zu einem ganz brauchbaren Honeypot gegen automatisierte Angriffe wird.
    Meistens fängt es Massen-Scans nach verwundbaren WordPress-Plugins oder zurückgelassenen Backdoors ab. Ähnlich imitiert https://varun.ch/login eine WordPress-Seite mit einem kleinen Twist.

    • Egal, was man zurückgibt: WordPress-Scans kommen trotzdem rein.

  • Gut. Ich bin froh, dass das Wort „Honeypot“ kein einziges Mal vorkam.
    Ich habe früher einmal einen „echten“ Honeypot geerbt und mir angesehen: Es waren etwa 30 Ports offen, und ich sagte tatsächlich laut: „Was ist das denn für ein Mist?“

    • Ich glaube, genau das soll ein Honeypot doch tun.
      Man lässt Ports offen, damit Script-Kiddies glauben, sie hätten etwas erreicht, und sich freuen, obwohl es in Wirklichkeit nichts ist. Ein abgeschlossener Honeypot wirkt an dem Punkt nicht besonders honeypot-artig.
    • Einer von uns beiden könnte den Begriff Honeypot falsch verstehen, vielleicht bin es auch ich. Trotzdem sieht es so aus, als ließe sich das durchaus verwenden, um ein Honeypot-System in einem Netzwerk aufzubauen.
      Honeypots dienen dazu, Angreifer anzulocken und zu erkennen; üblicherweise werden ihr Verhalten und ihre Muster protokolliert, analysiert oder blockiert. Bei diesem Tool wären mehr Logging-Funktionen als nur iptables schön, und für sich genommen ist es kein Honeypot, aber die Idee ist nicht weit davon entfernt. Dass die GitHub-Seite behauptet, damit werde die „OS-Sicherheit erhöht“, überzeugt mich allerdings überhaupt nicht. Es bietet vielleicht etwas Verschleierung gegen automatisierte Service-Scanner, aber wenn ein MySQL-Server auf 3306 lauscht und ein Angreifer sich mit 3306 verbindet, spricht er immer noch mit MySQL. Ob die restlichen 65534 Ports Müllantworten liefern, ist egal.

  • Dort steht, dass es „pro laufender Instanz nur an einen TCP-Port bindet“; ich frage mich, wie das funktioniert.
    Muss man 65535 Instanzen starten, um alle Ports abzudecken?

  • Könnte das potenziell ein DoS-Verstärker sein?
    Wenn man passend gefälschte Pakete sendet, kann man dann viele Pakete an die scheinbare Quelladresse zurückschicken lassen?

    • Bei einem TCP-Dienst werden keine großen Pakete gesendet, bevor der „Client“ mit dem richtigen ACK-Paket den Drei-Wege-Handshake abgeschlossen hat.
      Bei UDP könnte das wirklich absurd werden.
    • Amplification-Angriffe sind hauptsächlich bei UDP ein Problem, weil UDP nicht prüft, ob ein Rückweg tatsächlich möglich ist; TCP dagegen schon.