No, il campo del numero di porta in un'intestazione TCP è tecnicamente limitato a 2 byte. (dandoti 2^16=65536 possibili porte)
Se modifichi il protocollo riservando più bit per porte più alte, stai violando le specifiche per i segmenti TCP e non saresti compreso da un client. In altre parole, non stai più parlando TCP e il termine "porta" come in "porta di origine/destinazione TCP" non si applicherebbe. La stessa limitazione esiste per le porte UDP.
Detto questo, una backdoor potrebbe invece comunicare su un protocollo diverso da TCP o UDP per oscurare la sua comunicazione. Ad esempio, icmpsh è una shell inversa che usa solo ICMP. Infine, puoi anche implementare il tuo protocollo a livello di trasporto personalizzato utilizzando socket grezzi che possono avere una propria nozione di porte con un intervallo maggiore di 0-65535.
No, è quel numero perché il campo TCP per quello è lungo solo 16 bit (65536, ma inizia da 0), quindi è fondamentalmente impossibile comunicare una porta più alta di 65535
Questo post contiene un resoconto davvero interessante sul perché è così in IPv4, su come è lo stesso in IPv6 e su come puoi riutilizzare le porte in uso regolare.
Se ricostruissi lo stack TCP/IP localmente sulla macchina, il concetto generale non funzionerebbe a causa di come funziona lo standard RFC 793 - Transmission Control Protocol come indicato di seguito in alcune delle risposte? Rendere impossibile l'accesso a un servizio in esecuzione su una porta più alta allora65535.
Non ci sono servizi TCP/UDP su porte superiori a 65535. Se supporta numeri di porta superiori a 2-1, allora non è più TCP (o UDP) .
Puoi avere qualcos'altro Quello...? Sicuro. E potrebbe essere molto simile al TCP? Al punto da essere retrocompatibile? Sì a entrambe le domande.
Si è parlato così tanto di hardware e dispositivi con backdoor create a cui solo il governo ha accesso per il monitoraggio, ed ero solo curioso di sapere se questo fosse forse uno dei modi in cui lo stavano facendo ed evitando il rilevamento e l'essere trovati.
Se avessi sviluppato un tale dispositivo, si baserebbe su un protocollo abbastanza comune da essere insignificante. Un pacchetto di protocollo sconosciuto/illegale, dopo il quale si verifica del traffico extra, sarebbe piuttosto sospetto.
Nasconditi (quasi) in bella vista
Ciò che un tale dispositivo potrebbe fare potrebbe essere, ad esempio, ispezionare alcuni byte nel payload. Di solito sarebbero valori non correlati; Potrei quindi inviare pacchetti alla destinazione, o se si tratta di un router, senza nemmeno un indirizzo IP proprio, a un host casuale, forse anche inesistente oltre l'obiettivo, mascherandosi come (diciamo) una richiesta HTTPS o un tentativo di accesso SSH.
Se vedi un pacchetto che non conosci, potresti insospettirti. Ma anche se hai visto nei log qualcosa di simile
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
non ti preoccuperesti, soprattutto se avessi no utente "manutenzione". Si potrebbe forse presumere che qualcuno, da qualche parte, abbia scoperto un attacco contro un dispositivo con un utente predefinito di "manutenzione" (diamine, se fossi un governo, potrei commercializzare tale dispositivo, renderlo vulnerabile e non ripararlo, al solo scopo di giustificare tali connessioni su dispositivi totalmente diversi . Qual è la prima cosa che faresti vedendo tali tentativi? O niente ("forza bruta innocua. Idiota"), google e scrolla le spalle ("Oh, qualcuno pensa che io abbia un CheapRouter 2000. Idiota", possibilmente scrivi una regola del firewall per bloccare l'IP - tranne che i pacchetti arrivano ancora al scheda di rete ).
E ciò che realmente accade è che il firmware malvagio nel router, nella scheda di rete, nella scheda madre o altro, riconosce il pacchetto e invia una risposta . Potrebbe farlo falsificando i pacchetti di risposta sovrascrivendo quelli "reali".
L'unico sintomo di qualcosa di molto brutto che sta accadendo sarebbe se confrontassi, per esempio, il traffico in entrata e in uscita da un router malvagio:
Host con server SSH:
--> 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 senza server SSH:
--> 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
Se annusassi un cavo, a sinistra oa destra del dispositivo compromesso, non noterai immediatamente nulla che non va.
L'altra cosa sospetta sarebbe quindi che il mittente utilizzi apparentemente l'estensione TCP Fast Open. Tieni presente che puoi inviare dati extra nel SYN anche senza TCP/FO, verranno semplicemente ignorati dai dispositivi che sono entrambi non FO e non compromesso.