No, il campo del numero di porta in un'intestazione TCP è tecnicamente limitato a 2 byte. (dandoti 2^16=65536 di porte possibili)

Se modifichi il protocollo riservando più bit per porte superiori, stai violando le specifiche per segmenti TCP e non sarebbe compreso da un cliente. In altre parole, non si sta parlando più di TCP e il termine "porta" come in "Porta di origine / destinazione TCP" non si applica. 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 utilizza solo ICMP. In definitiva, puoi anche implementare il tuo protocollo personalizzato per il livello di trasporto utilizzando socket raw che possono avere la propria nozione di porte con un intervallo maggiore di 0-65535.

No, è quel numero perché il campo TCP per questo è lungo solo 16 bit (65536, ma a partire da 0) , quindi è fondamentalmente impossibile comunicare una porta superiore a 65535

Questo post ha una bella recensione sul perché questo è così in IPv4, come è lo stesso in IPv6 e come riutilizzare le porte in uso regolare.

If you rebuilt the TCP/IP stack locally on the machine, would the overall concept not work due to how the RFC 793 - Transmission Control Protocol Standard works as mentioned below in some of the answers? Making it impossible to access a service running on a port higher then 65535.

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 che ...? Sicuro. E potrebbe essere molto simile al TCP? Al punto di essere retrocompatibile? Sì ad entrambe le domande.

There has been so much talk about hardware and devices having backdoors created that only government have access too for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

Se avessi sviluppato un dispositivo del genere, farebbe affidamento su un protocollo abbastanza comune da essere irrilevante. Un pacchetto di protocollo sconosciuto / illegale, dopo il quale si verifica un traffico extra, sarebbe piuttosto sospetto.

Nascondi in (quasi) in bella vista

Cosa potrebbe fare un dispositivo del genere, 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, ad un host casuale, forse addirittura inesistente oltre , il target, mascherato da (diciamo) a Richiesta HTTPS o tentativo di accesso SSH.

Se vedi un pacchetto che non conosci, potresti diventare sospetto. Ma anche se hai visto nei log qualcosa come

SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance

non ti preoccupare, specialmente se hai no utente "manutenzione". Forse supponete 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 un dispositivo simile, renderlo vulnerabile e non risolverlo, al solo scopo di giustificare tali connessioni su dispositivi completamente diversi . Qual è la prima cosa che faresti nel vedere questi tentativi? O nulla ("innocuo bruteforce. Idiot"), google e scrollata di spalle ("Oh, qualcuno pensa di avere un CheapRouter 2000. Idiot", possibilmente scrivere una regola del firewall per bloccare l'IP - eccetto che i pacchetti arrivano ancora sulla scheda di rete ).

E ciò che accade in realtà è che il firmware malvagio nel router, nella scheda di rete, nella scheda madre o in quello che hai, riconosce il pacchetto e restituisce una risposta . Potrebbe farlo forging i pacchetti di risposta sovrascrivendo quelli "reali".

L'unico sintomo di qualcosa di molto brutto potrebbe essere se confrontassi, ad 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 si annusa su un cavo, a sinistra oa destra del dispositivo compromesso, si noterà immediatamente qualcosa di sbagliato.

L'altra cosa sospetta sarebbe che il mittente usi apparentemente l'estensione TCP Fast Open . Nota che puoi inviare dati extra in SYN anche senza TCP / FO, sarà semplicemente ignorato dai dispositivi che sono entrambi non-FO e non compromessi.

Come già detto, i numeri di porta sono rappresentati con un numero intero a 16 bit senza segno e non possono essere superiori a 65535.

Ma esiste la possibilità di utilizzare diversi protocolli (non TCP o UDP). Nell'intestazione IP c'è un campo di 8 bit chiamato «numero di protocollo», che indica quale protocollo di trasporto viene utilizzato all'interno di questo pacchetto.

Puoi consultare la tabella dei protocolli di trasporto qui: link

Alcuni protocolli di questo elenco sono ampiamente utilizzati dall'utente (ad esempio, TCP o UDP), altri più raramente (DCCP o UDPLite). Alcuni numeri di protocollo non sono ancora stati utilizzati e alcuni sono deprecati (ARGUS, EMCON).

Quindi, backdoor può utilizzare numeri di protocollo non utilizzati per inviare dati al proprio server. Naturalmente, questa tecnica è difficile da implementare (richiede l'accesso a raw socket o l'implementazione di backdoor come modulo del kernel del sistema operativo).

Questo sarebbe possibile, ma non sarebbe possibile utilizzare protocolli come UDP e TCP poiché la loro porta massima è 65535.

Dovresti implementare il tuo protocollo sulla parte superiore del protocollo IP.

Questo potrebbe essere possibile usando socket grezzi.

There has been so much talk about hardware and devices having backdoors created that only government have access too for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

Non penso che questo potrebbe aiutare a rendere la connessione più furtiva dal momento che saresti ancora in grado di vedere i pacchetti in corso attraverso la rete.

Ci ho pensato per un paio di giorni, e penso che la risposta potrebbe essere sì, ma in un modo strano .

Quindi, come hanno sottolineato molte delle altre risposte, TCP dice che i numeri di porta sono 16 bit. Quel 16 1s e 0s. Questo ha un limite di 65535 porte ripetibili. Per il resto dell'esempio avrei usato 4 bit perché sono pigro.

Quindi con 4 bit posso rappresentare 15 porte.

La tua backdoor teatrale dovrebbe fare affidamento su come gestiva pacchetti TCP malformati. Quindi (ricorda 4 bit invece di 16). Consente di inviare traffico sulla porta 17.

L'intestazione sarebbe malformata come 10001. Il tuo stack TCP potrebbe affermare che se ottieni un'intestazione malformata, vai su un percorso logico diverso, collegando i dati alla porta dei quattro bit "più a destra". In questo caso la porta 1 o 0001. Il vero trucco è che TCP utilizza solo il conteggio dei bit. Non è come xml dove c'è una [porta] 10001 [/ porta]. Quindi avresti bisogno di un modo per rilevare l'overflow dell'intestazione della tua porta. SYN è proprio accanto alla porta, quindi è possibile farlo, un SYN di "1073741823" indica che la porta di destinazione è più grande di uno.

Questo diverso percorso logico potrebbe rimanere attivo per tutto il tempo in cui la connessione è attiva sulla porta 1.

In questo modo si poteva avere una backdoor TCP da qualche parte che accettava pacchetti malformati e faceva qualcosa di speciale con loro. Il vero problema è che nient'altro che il tuo stack TCP speciale potrebbe capirli. Router, switch intelligenti, anche in teoria alcune schede NIC rilasciano il pacchetto, perché è malformato. Non ci sarebbe quasi alcun modo di dire se un pacchetto sarebbe arrivato alla sua destinazione con quell'intestazione malformata.

Ma, se hai collegato due dispositivi con lo stack TCP strabiliante a uno switch o un hub "stupido". In teoria, potresti farlo funzionare, tuttavia questo non sarebbe nelle specifiche TCP.

Fonte: link

Questo documento veramente esauriente indica chiaramente come i bit vengono assegnati su Internet tramite TCP. Mostra le porte di origine e di destinazione una accanto all'altra.

Quindi hai creato una porta sorgente a 32 bit? NOPE non appena tocca Internet byte 3 e amp; 4 (l'ordine inferiore) della tua porta sorgente verrà trattato alla destinazione.

La porta di destinazione cancella il numero di sequenza e tutto verrà spostato più in basso.

Da quando il numero di sequenza è stato distrutto, la destinazione non si aspetta il numero di sequenza, e lo lascerà cadere come se fosse un pacchetto contraffatto.

Anche se è passato oltre questo punto, il numero di riconoscimento sarà distrutto dal numero di sequenza e dal momento che quel numero non è più valido, per quanto riguarda Internet, non sarà mai riconosciuto.

Tutti lo hanno spiegato in termini di pacchetto TCP / IP: il campo della porta ha una lunghezza di soli 16 bit.

Ma per quanto riguarda il codice sorgente del kernel Linux e come gestisce la porta? Ovunque nel kernel di Linux, per la porta TCP / IP è sempre lanciato come "corto" o 16 bit. E quando è compilato in assembly x86, la versione a 16 bit delle istruzioni viene utilizzata per gestire i dati a 16 bit.

E se ti stai interrogando su IPv6, allora è lo stesso os IPv4 - tutto su TCP e UDP.

link

Ma ovviamente è possibile impostare una comunicazione strana come l'utilizzo del server TWO per la comunicazione, ognuna con porte individuali a 16 bit e quindi quando le combini hai una porta virtuale a 32 bit. Ma in tutto il mondo solo tu saprai come parlare con i due server - ad esempio, dividendo i dati a metà e dividendolo tra i due server, per essere ricostruito di nuovo dal lato client.

Sembrava davvero più lungo di 16 bit è quasi impossibile.

Sì, dal momento che hai specificato che puoi modificare il sistema operativo, ma con l'avvertimento principale che solo i dispositivi modificati potrebbero vedere come se si trovasse a un numero di porta non standard.

La maggior parte delle implementazioni correnti memorizzano il numero di porta in un campo a 16 bit, quindi tutte le possibili combinazioni di bit sono mappate su numeri interi da 0 a 65.535. Queste implementazioni semplicemente non sono in grado di riconoscere nessun altro numero di porta perché nessuna combinazione di bit si assocerebbe ad essa.

Tuttavia, se si desidera veramente che un determinato client riconosca il traffico come se si trovasse su un numero di porta diverso, è possibile riscrivere il modo in cui quel client interpreta i pacchetti al livello inferiore. Invece di utilizzare solo il numero di porta a 16 bit, è possibile scrivere il sistema operativo per riconoscere le modifiche ad esso basate sui dati contenuti nelle sezioni Opzioni o Messaggio del pacchetto. Il sistema potrebbe quindi operare come se ci fosse una gamma più ampia di possibili numeri di porta.

Questo trucco funzionerebbe solo su dispositivi che hanno riscritto i loro algoritmi di interpretazione dei pacchetti. I dispositivi esterni potevano ancora inoltrare questi pacchetti senza essere compromessi, ma avrebbero visto i pacchetti come su un numero di porta standard.