No, el campo de número de puerto en un encabezado TCP está técnicamente limitado a 2 bytes. (dándote 2^16=65536 posibles puertos)
Si altera el protocolo reservando más bits para puertos más altos, está violando la especificación para segmentos TCP y un cliente no lo entenderá. En otras palabras, ya no está hablando TCP y el término "puerto" como en "puerto de origen/destino 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 un shell inverso que solo usa ICMP. En última instancia, también puede implementar su propio protocolo de capa de transporte personalizado mediante sockets sin procesar que pueden tener su propia noción de puertos con un rango mayor que 0-65535.
No, es ese número porque el campo TCP para eso tiene solo 16 bits (65536, pero comienza en 0), por lo que es fundamentalmente imposible comunicar un puerto superior a 65535
Esta publicación tiene un artículo muy bueno sobre por qué esto es así en IPv4, cómo es lo mismo en IPv6 y cómo puede reutilizar los puertos en el uso regular.
Si reconstruyera la pila TCP/IP localmente en la máquina, ¿no funcionaría el concepto general debido a cómo funciona RFC 793 - Estándar de protocolo de control de transmisión como se menciona a continuación en algunas de las respuestas? ¿Hacer imposible acceder a un servicio que se ejecuta en un puerto superior? entonces65535.
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 tomar algo más? que...? Por supuesto. ¿Y podría ser muy similar a TCP? ¿Hasta el punto de ser retrocompatible? Sí a ambas preguntas.
Se ha hablado tanto sobre el hardware y los dispositivos que tienen puertas traseras creadas que solo el gobierno tiene acceso también para el monitoreo, y tenía curiosidad si esta era posiblemente una de las formas en que lo estaban haciendo y evitando la detección y ser encontrado.
Si hubiera desarrollado un dispositivo de este tipo, se basaría en un protocolo lo suficientemente común como para pasar desapercibido. Un paquete de protocolo desconocido/ilegal, después del cual se produce algo de tráfico adicional, sería bastante sospechoso.
Esconderse (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. Por lo general, 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á el objetivo, haciéndose pasar por (digamos) una solicitud HTTPS o un intento de inicio de sesión SSH.
Si ve un paquete que no conoce, es posible que sospeche. Pero incluso si vio 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 no tuvieras no usuario "mantenimiento". Tal vez suponga 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 tal dispositivo, hacerlo vulnerable, y no arreglarlo, con el único propósito de justificar tales conexiones en dispositivos totalmente diferentes . ¿Qué es lo primero que harías al ver tales intentos? O nada ("Fuerza bruta inofensiva. Idiota"), Google y encogerse de hombros ("Oh, alguien piensa que tengo un CheapRouter 2000. Idiota", posiblemente escriba una regla de firewall para bloquear la IP, excepto que los paquetes todavía llegan al tarjeta de red ).
Y lo que realmente sucede es que el firmware maligno en el enrutador, la tarjeta de red, la placa base o lo que sea, reconoce el paquete y envía una respuesta . Podría hacerlo falsificando paquetes de respuesta sobrescribiendo los "reales".
El único síntoma de que sucede algo muy malo sería si compararas, por ejemplo, el tráfico entrante y saliente de un enrutador maligno:
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 husmeaste en un cable, ya sea a la izquierda o a la derecha del dispositivo comprometido, no notarías ningún problema 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án ignorados por dispositivos que son ambos no FO y no comprometido.