Nein, das Portnummernfeld in einem TCP-Header ist technisch auf 2 Bytes begrenzt. (gibt Ihnen 2^16=65536 mögliche Ports)
Wenn Sie das Protokoll ändern, indem Sie mehr Bits für höhere Ports reservieren, verletzen Sie die Spezifikation für TCP-Segmente und würden von einem Client nicht verstanden werden. Mit anderen Worten, Sie sprechen nicht mehr TCP und der Begriff "Port" wie in "TCP-Quell-/Zielport" würde nicht zutreffen. Dieselbe Einschränkung gilt für UDP-Ports.
Allerdings könnte eine Hintertür stattdessen über ein anderes Protokoll als TCP oder UDP kommunizieren, um ihre Kommunikation zu verschleiern. Beispiel:icmpsh ist eine Reverse-Shell, die nur ICMP verwendet. Letztendlich können Sie auch Ihr eigenes benutzerdefiniertes Transportschichtprotokoll implementieren, indem Sie Raw-Sockets verwenden, die eine eigene Vorstellung von Ports mit einem größeren Bereich als 0-65535 haben können.
Nein, es ist diese Zahl, weil das TCP-Feld dafür nur 16 Bit lang ist (65536, aber bei 0 beginnend), also ist es grundsätzlich unmöglich, einen höheren Port als 65535 zu kommunizieren
Dieser Beitrag enthält eine wirklich schöne Beschreibung, warum dies bei IPv4 so ist, warum es bei IPv6 genauso ist und wie Sie Ports bei regelmäßiger Verwendung wiederverwenden können.
Wenn Sie den TCP/IP-Stack lokal auf dem Computer neu erstellen würden, würde das Gesamtkonzept nicht funktionieren, da der RFC 793 - Transmission Control Protocol Standard wie unten in einigen Antworten erwähnt funktioniert? Es unmöglich machen, auf einen Dienst zuzugreifen, der auf einem höheren Port läuft dann65535.
Es gibt keine TCP/UDP-Dienste auf Ports höher als 65535. Wenn es Portnummern über 2-1 unterstützt, dann es nicht mehr TCP (oder UDP) ist .
Können Sie etwas anderes haben das...? Sicher. Und könnte es TCP sehr ähnlich sein? Bis zur Abwärtskompatibilität? Ja zu beiden Fragen.
Es wurde so viel darüber geredet, dass Hardware und Geräte mit Hintertüren erstellt wurden, auf die nur die Regierung Zugriff zur Überwachung hat, und ich war nur neugierig, ob dies möglicherweise eine der Möglichkeiten war, wie sie dies taten und eine Entdeckung und Entdeckung vermieden?
Wenn ich ein solches Gerät entwickelt hätte, würde es sich auf ein Protokoll verlassen, das allgemein genug ist, um unauffällig zu sein. Ein unbekanntes/illegales Protokollpaket, nach dem zusätzlicher Datenverkehr erfolgt, wäre ziemlich verdächtig.
Verstecken Sie sich (fast) vor aller Augen
Was ein solches Gerät tun könnte, könnte beispielsweise sein, einige Bytes in der Nutzlast zu inspizieren. Sie wären normalerweise nicht korrelierte Werte; Ich könnte dann Pakete an das Ziel senden, oder wenn es sich um einen Router handelt, sogar ohne eigene IP-Adresse, an einen zufälligen, möglicherweise sogar nicht existierenden Host jenseits das Ziel, getarnt als (sagen wir) eine HTTPS-Anfrage oder ein SSH-Anmeldeversuch.
Wenn Sie ein Paket sehen, das Sie nicht kennen, könnten Sie misstrauisch werden. Aber selbst wenn Sie in den Protokollen so etwas wie
gesehen habenSSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
Sie würden sich besonders keine Sorgen machen wenn Sie nein hätten Benutzerwartung". Sie würden vielleicht annehmen, dass jemand irgendwo einen Angriff auf ein Gerät mit einem Standardbenutzer von „Wartung“ entdeckt hat (verdammt, wenn ich eine Regierung wäre, könnte ich vermarkten ein solches Gerät, machen es angreifbar und reparieren es nicht, aus dem alleinigen Grund, solche Verbindungen auf völlig anderen Geräten zu rechtfertigen . Was würden Sie als Erstes tun, wenn Sie solche Versuche sehen? Entweder nichts ("harmless bruteforce. Idiot"), googlen und Achselzucken ("Oh, jemand denkt, ich habe einen CheapRouter 2000. Idiot"), evtl. eine Firewall-Regel schreiben, um die IP zu blockieren - außer dass die Pakete trotzdem ankommen Netzwerkkarte ).
Und was tatsächlich passiert, ist, dass die böse Firmware im Router, der Netzwerkkarte, dem Motherboard oder was auch immer, das Paket erkennt und sendet eine Antwort zurück . Es könnte dies tun, indem es Antwortpakete fälscht und die "echten" überschreibt.
Das einzige Symptom dafür, dass etwas sehr Schlimmes passiert, wäre, wenn Sie beispielsweise den ein- und ausgehenden Datenverkehr eines bösartigen Routers vergleichen würden:
Host mit SSH-Server:
--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH S+A <-- HOST
--> SSH ACK --> ROUTER --> SSH ACK --> HOST
...
--> LOGIN ----> ROUTER --> LOGIN ----> HOST
<-- FAIL2------ ROUTER <-- FAIL1 <---- HOST packets are different!
Host ohne SSH-Server:
--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH RST <-- HOST wait, WTF?
--> SSH ACK --> ROUTER HOST
...
--> LOGIN ----> ROUTER HOST
<-- FAIL2------ ROUTER HOST
Wenn Sie an einem Kabel schnüffeln, entweder links oder rechts vom kompromittierten Gerät, würden Sie sofort nichts Ungewöhnliches bemerken.
Das andere Verdächtige wäre dann, dass der Absender offenbar die TCP-Fast-Open-Erweiterung verwendet. Beachten Sie, dass Sie zusätzliche Daten im SYN auch ohne TCP/FO senden können, sie werden einfach von Geräten ignoriert, die beides sind Nicht-FO und nicht kompromittiert.