Non, le champ du numéro de port dans un en-tête TCP est techniquement limité à 2 octets. (vous donnant 2^16=65536 ports possibles)
Si vous modifiez le protocole en réservant plus de bits pour des ports plus élevés, vous enfreignez la spécification des segments TCP et ne serez pas compris par un client. En d'autres termes, vous ne parlez plus TCP et le terme "port" comme dans "port source/destination TCP" ne s'appliquerait pas. La même limitation existe pour les ports UDP.
Cela dit, une porte dérobée pourrait plutôt communiquer via un protocole différent de TCP ou UDP pour masquer sa communication. Par exemple, icmpsh est un shell inversé qui utilise uniquement ICMP. En fin de compte, vous pouvez également implémenter votre propre protocole de couche de transport personnalisé à l'aide de sockets bruts qui peuvent avoir leur propre notion de ports avec une plage supérieure à 0-65535.
Non, c'est ce nombre car le champ TCP pour cela ne fait que 16 bits (65536, mais à partir de 0), il est donc fondamentalement impossible de communiquer un port supérieur à 65535
Ce message contient une très belle description de la raison pour laquelle il en est ainsi dans IPv4, comment c'est la même chose dans IPv6 et comment vous pouvez réutiliser les ports en utilisation régulière.
Si vous reconstruisiez la pile TCP / IP localement sur la machine, le concept global ne fonctionnerait-il pas en raison du fonctionnement de la norme RFC 793 - Transmission Control Protocol Standard, comme mentionné ci-dessous dans certaines des réponses?Rendant impossible l'accès à un service exécuté sur un port supérieur alors65535.
Il n'y a aucun service TCP/UDP sur les ports supérieurs à 65535. S'il prend en charge les numéros de port supérieurs à 2-1, alors ce n'est plus TCP (ou UDP) .
Pouvez-vous avoir autre chose ce...? Bien sûr. Et pourrait-il être très similaire à TCP ? Au point d'être rétrocompatible ? Oui aux deux questions.
Il y a eu tellement de discussions sur le matériel et les appareils ayant créé des portes dérobées que seul le gouvernement a également accès pour la surveillance, et j'étais juste curieux de savoir si c'était peut-être l'une des façons dont ils le faisaient et éviter la détection et être trouvé ?
Si j'avais développé un tel appareil, il s'appuierait sur un protocole suffisamment commun pour être banal. Un paquet de protocole inconnu/illégal, après quoi un trafic supplémentaire s'ensuit, serait assez suspect.
Cachez-vous à la vue (presque) de tous
Ce qu'un tel appareil pourrait faire pourrait être, par exemple, d'inspecter certains octets de la charge utile. Il s'agirait généralement de valeurs non corrélées ; Je pourrais alors envoyer des paquets à la cible, ou s'il s'agit d'un routeur, sans même une adresse IP propre, à un hôte aléatoire, voire inexistant au-delà la cible, se faisant passer pour (par exemple) une requête HTTPS ou une tentative de connexion SSH.
Si vous voyez un paquet que vous ne connaissez pas, vous pourriez avoir des soupçons. Mais même si vous avez vu dans les journaux quelque chose comme
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
vous ne vous inquiétez pas, surtout si vous aviez non "maintenance" de l'utilisateur. Vous supposeriez peut-être que quelqu'un, quelque part, a découvert une attaque contre un appareil avec un utilisateur par défaut de "maintenance" (diable, si j'étais un gouvernement, je pourrais commercialiser un tel appareil, le rendre vulnérable et non le réparer, dans le seul but de justifier de telles connexions sur des appareils totalement différents . Quelle est la première chose que vous feriez en voyant de telles tentatives ? Soit rien ("force brute inoffensive. Idiot"), google et hausser les épaules ("Oh, quelqu'un pense que j'ai un CheapRouter 2000. Idiot", éventuellement écrire une règle de pare-feu pour bloquer l'IP - sauf que les paquets arrivent toujours au carte réseau ).
Et ce qui se passe réellement, c'est que le firmware maléfique du routeur, de la carte réseau, de la carte mère ou autre, reconnaît le paquet et renvoie une réponse . Il pourrait le faire en falsifiant les paquets de réponse en écrasant les "vrais" paquets.
Le seul symptôme d'un événement très grave serait de comparer, par exemple, le trafic entrant et sortant d'un routeur malveillant :
Hôte avec serveur 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!
Hôte sans serveur 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 vous reniflez un câble, que ce soit à gauche ou à droite de l'appareil compromis, vous ne remarquerez rien d'anormal immédiatement.
L'autre chose suspecte serait alors que l'expéditeur utilise apparemment l'extension TCP Fast Open. Notez que vous pouvez envoyer des données supplémentaires dans le SYN même sans TCP/FO, elles seront simplement ignorées par les appareils qui sont les deux non FO et sans compromis.