No, el campo del número de puerto en un encabezado TCP está técnicamente limitado a 2 bytes. (dándole 2^16=65536 de puertos posibles)

Si modifica el protocolo reservando más bits para puertos más altos, está violando la especificación para segmentos TCP y no sería entendido por un cliente. En otras palabras, ya no se habla de TCP y el término "puerto" como en "puerto de origen / destino de TCP" no se aplicaría. La misma limitación existe para los puertos UDP.

Dicho esto, una puerta trasera podría comunicarse a través de un protocolo diferente a TCP o UDP para ocultar su comunicación. Por ejemplo, icmpsh es una shell inversa que solo usa ICMP. En última instancia, también puede implementar su propio protocolo de capa de transporte personalizado utilizando sockets sin procesar que pueden tener su propia noción de puertos con una mayor rango que 0-65535.

No, es ese número porque el campo TCP solo tiene 16 bits (65536, pero comienza en 0) , por lo que es fundamentalmente imposible comunicar un puerto superior a 65535

Esta publicación tiene una buena reseña de por qué esto es así. IPv4, cómo es lo mismo en IPv6 y cómo puede reutilizar los puertos en uso regular.

  

Si reconstruye la pila TCP / IP localmente en la máquina,   concepto general no funciona debido a cómo el RFC 793 - Control de transmisión   Protocolo estándar funciona como se menciona a continuación en algunas de las respuestas?   Haciendo imposible acceder a un servicio que se ejecuta en un puerto más alto que el   65535.

No hay servicios TCP / UDP en puertos superiores a 65535. Si admite números de puerto superiores a 2 ¹⁶ -1, entonces ya no es TCP (o UDP) .

¿Puedes tener algo más que ...? Por supuesto. ¿Y podría ser muy similar a TCP? ¿Hasta el punto de ser compatible hacia atrás? Sí a las dos preguntas.

  

Se ha hablado tanto sobre hardware y dispositivos que tienen   Puertas traseras creadas que solo el gobierno tiene acceso para monitoreo,   Y yo solo tenía curiosidad de si esta era posiblemente una de las formas en que eran   ¿Haciéndolo y evitando la detección y siendo encontrado?

Si hubiera desarrollado un dispositivo de este tipo, se basaría en un protocolo lo suficientemente común como para no tener nada especial. Un paquete de protocolo desconocido / ilegal, después del cual se produce un tráfico adicional, sería bastante sospechoso.

Ocultar en (casi) a simple vista

Lo que podría hacer un dispositivo de este tipo podría ser, por ejemplo, inspeccionar algunos bytes en la carga útil. Normalmente serían valores no correlacionados; Entonces podría enviar paquetes al destino, o si es un enrutador, sin siquiera una dirección IP propia, a algún host aleatorio, posiblemente incluso inexistente más allá del del destino, enmascarándose como (digamos) un Solicitud HTTPS o intento de inicio de sesión SSH.

Si ve un paquete que no conoce, puede sospechar. Pero incluso si has visto en los registros algo como

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

no te preocuparías, especialmente si tuvieras "mantenimiento" en no . Tal vez asumiría que alguien, en algún lugar, descubrió un ataque contra algún dispositivo con un usuario predeterminado de "mantenimiento" (diablos, si yo fuera un gobierno, podría comercializar dicho dispositivo, tenerlo vulnerable, y no lo arregles, con el único propósito de justificar tales conexiones en dispositivos totalmente diferentes . ¿Qué es lo primero que harías para ver tales intentos? O bien nada ("bruteforce. Idiot"), google y encoger de hombros ("Oh, alguien que piensa que tengo un CheapRouter 2000. Idiota", posiblemente escriba una regla de firewall para bloquear la IP, excepto que los paquetes aún llegan a la tarjeta de red ).

Y lo que realmente sucede es que el malvado firmware del enrutador, la tarjeta de red, la placa base o lo que sea, reconoce el paquete y envía una respuesta . Podría hacerlo falsificando los paquetes de respuesta que sobrescriben los "reales".

El único síntoma de que algo muy malo sucede es si comparas, por ejemplo, el tráfico entrante y saliente de un enrutador malvado:

Host con servidor 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 sin servidor 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

Si olfateaba un cable, ya sea a la izquierda o a la derecha del dispositivo comprometido, no notaría nada de inmediato.

La otra cosa sospechosa sería que el remitente aparentemente usa la extensión TCP Fast Open . Tenga en cuenta que puede enviar datos adicionales en SYN incluso sin TCP / FO, simplemente será ignorado por dispositivos que sean ambos no-FO y no comprometidos.

Como ya se dijo, los números de puerto se representan con un entero de 16 bits sin signo y no pueden estar por encima de 65535.

Pero existe la posibilidad de usar diferentes protocolos (no TCP o UDP). En el encabezado IP hay un campo de 8 bits llamado «número de protocolo», que indica qué protocolo de transporte se usa dentro de este paquete.

Puede consultar la tabla de protocolos de transporte aquí: enlace

Algunos protocolos de esta lista son usuarios extensos (por ejemplo, TCP o UDP), algunos más raramente (DCCP o UDPLite). Algunos números de protocolo aún no se utilizan, y algunos están en desuso (ARGUS, EMCON).

Por lo tanto, puerta trasera puede usar números de protocolo no utilizados para enviar datos a su servidor. Por supuesto, esta técnica es difícil de implementar (necesita acceso a Rawsocket o implementación de backdoor como módulo del kernel del SO).

Esto podría lograrse pero no podrías usar protocolos como UDP y TCP ya que su puerto máximo es 65535.

Necesitarías implementar tu propio protocolo sobre el protocolo IP.

Esto puede ser posible usando sockets en bruto.

  

Se ha hablado tanto sobre el hardware y los dispositivos que se han creado puertas traseras que solo el gobierno también tiene acceso para el monitoreo, y solo tenía curiosidad si esta era posiblemente una de las formas en que lo estaban haciendo y evitando la detección y el descubrimiento.

No creo que esto ayude a hacer que la conexión sea sigilosa, ya que aún podría ver los paquetes que pasan por la red.

Pensé en esto por un par de días, y creo que la respuesta podría ser sí, pero de una manera extraña .

Entonces, como muchas de las otras respuestas han señalado, TCP dice que los números de puertos son de 16 bits. Que 16 1s y 0s. Esto tiene un límite de 65535 puertos repetibles. Para el resto del ejemplo iban a usar 4 bits porque soy flojo.

Así que con 4 bits puedo representar 15 puertos.

Su puerta trasera teatral tendría que confiar en cómo manejó los paquetes TCP mal formados. Entonces (recuerda 4 bits en lugar de 16). Permite enviar algo de tráfico en el puerto 17.

El encabezado tendría un formato incorrecto como 10001. Su pila TCP podría indicar que si obtiene un encabezado con un formato incorrecto, luego siga una ruta lógica diferente, adjuntando datos al puerto de los cuatro bits "más a la derecha". En este caso, el puerto 1 o 0001. El verdadero truco es que TCP solo usa el conteo de bits. No es como xml donde hay un [puerto] 10001 [/ puerto]. Por lo tanto, necesitaría alguna forma de detectar el desbordamiento del encabezado de puerto. SYN está justo al lado del puerto, así que podrías hacerlo, un SYN de exactamente "1073741823" significa que tu puerto de destino es más grande en uno.

Esta ruta lógica diferente podría permanecer activa durante todo el tiempo que la conexión esté activa en el puerto 1.

De esta manera, podría tener una puerta trasera TCP en algún lugar que aceptara paquetes mal formados e hiciera algo especial con ellos. El problema real es que nada más que tu pila TCP especial podría entenderlos. Los enrutadores, los conmutadores inteligentes, incluso en teoría, algunas tarjetas NIC dejarían caer el paquete, porque está mal formado. Casi no habría manera de saber si un paquete llegaría a su destino con ese encabezado con formato incorrecto.

Pero, si conectó dos dispositivos con la pila TCP no fiable a un conmutador o concentrador "tonto". En teoría, podría hacer que esto funcione, sin embargo, esto no estaría en la especificación de TCP.

Fuente: enlace

Este documento realmente extenso indica claramente cómo se asignan los bits en Internet a través de TCP. Muestra los puertos de origen y destino uno al lado del otro.

¿Entonces creaste un puerto de origen de 32 bits? NOPE tan pronto como toque los bytes de Internet 3 y amp; 4 (el orden inferior) de su puerto de origen se tratará en el destino.

El puerto de destino borra el número de secuencia y todo será empujado más abajo en la línea.

Ahora que el número de secuencia ha sido destruido, el destino no esperará ese número de secuencia y lo eliminará como si fuera un paquete falso.

Incluso si ha superado este punto, el número de confirmación quedará destrozado por el número de secuencia y, dado que ese número ahora no es válido, en lo que respecta a Internet, nunca se reconocerá.

Todos lo explicaron en términos de paquetes TCP / IP: el campo del puerto tiene solo 16 bits de longitud.

¿Pero qué tal el código fuente del kernel de Linux y cómo maneja el puerto? En todas partes en el kernel de Linux, para el puerto TCP / IP siempre se convierte en "corto", o 16 bits. Y cuando se compila en el ensamblaje x86, la versión de 16 bits de las instrucciones se utiliza para manejar los datos de 16 bits.

Y si te estás preguntando acerca de IPv6, entonces es el mismo sistema operativo IPv4: todo sobre TCP y UDP.

enlace

Pero, por supuesto, puede configurar una comunicación extraña, como usar el servidor DOS para la comunicación: cada uno tiene puertos individuales de 16 bits y, por lo tanto, cuando los combina, tiene un puerto virtual de 32 bits. Pero solo el mundo entero sabrá cómo hablar con los dos servidores, por ejemplo, dividiendo los datos a la mitad y dividiéndolos entre los dos servidores, para ser reconstruidos nuevamente en el lado del cliente.

Realmente parecía que más de 16 bits es casi imposible.

Sí, ya que especificó que puede modificar el sistema operativo, pero con la advertencia principal de que solo los dispositivos modificados lo verían como un número de puerto no estándar.

La mayoría de las implementaciones actuales almacenan el número de puerto en un campo de 16 bits, por lo que todas las combinaciones posibles de bits se asignan a números enteros de 0 a 65,535. Estas implementaciones simplemente no pueden reconocer ningún otro número de puerto porque ninguna combinación de bits se asignaría a él.

Pero, si realmente quisiera que un cliente en particular reconociera el tráfico como si estuviera en un número de puerto diferente, podría volver a escribir cómo ese cliente interpreta los paquetes en el nivel inferior. En lugar de utilizar el número de puerto de 16 bits, puede escribir el sistema operativo para reconocer las modificaciones en función de los datos contenidos en las secciones de Opciones o Mensaje del paquete. El sistema podría entonces funcionar como si hubiera un rango más amplio de números de puerto posibles.

Este truco solo funcionaría en dispositivos que tienen sus algoritmos de interpretación de paquetes reescritos. Los dispositivos externos aún podrían reenviar estos paquetes sin verse comprometidos, pero verían los paquetes como si estuvieran en un número de puerto estándar.