Dangers d'ouvrir un large éventail de ports? (mosh)
Pourquoi configurons-nous généralement des pare-feu pour filtrer tout le trafic que nous n'autorisons pas spécifiquement? S'agit-il simplement d'une couche de sécurité supplémentaire pour la défense en profondeur qui ne nous achète rien si nous n'exécutons pas de logiciels malveillants sur notre système?
Y a-t-il des dangers à dire, par exemple, ouvrir les ports 60000 à 61000 pour les connexions UDP entrantes, ce qui est beaucoup moins sûr que de simplement ouvrir quelques ports?
Je viens d'entendre parler de mosh qui s'annonce comme une meilleure façon de faire du ssh mobile (via wifi/téléphone portable). Mosh utilise UDP plutôt que TCP, donc si vous entrez brièvement dans un tunnel ou si votre adresse IP change (commutation de tours de téléphone portable), vous n'avez pas à attendre pour revenir du contrôle de la congestion ou établir une nouvelle session ssh. Fondamentalement, mosh utilise ssh pour démarrer à distance un serveur mosh en tant qu'utilisateur non privilégié, échange une clé AES-OCB à l'aide de ssh, puis envoie/reçoit des paquets chiffrés (avec des numéros de séquence) vers un port de la plage 60000-61000, que vous devez configurez votre pare-feu pour l'ouvrir.
Je suis quelque peu mal à l'aise d'ouvrir ~ 1000 ports pour les connexions entrantes (UDP), mais je ne vois pas de très bonne raison à cela. Si aucun logiciel n'écoute les données sur ce port, il est simplement ignoré, n'est-ce pas? (Lors de la modification: non - il demande en fait au serveur de renvoyer une réponse inaccessible de destination ICMP (ping)). Je suppose que si un logiciel malveillant s'exécutait sur mon serveur, il pourrait attendre d'écouter les instructions des adresses IP falsifiées sur l'un de ces ports ouverts. Cependant, les logiciels malveillants exécutés sur des systèmes connectés à Internet pourraient déjà établir des connexions/télécharger des informations à partir d'autres serveurs de logiciels malveillants (mais devraient connaître une adresse IP) et récupérer des instructions, ce qui ne rend pas la sécurité beaucoup moins sécurisée.
EDIT: Intéressant, je viens de voir ceci autre question qui m'a amené à lire DP_flood_attack . Je suppose que je devrais en outre désactiver mon système pour envoyer des réponses de destination ping inaccessibles pour les ports UDP nouvellement ouverts.
En plus de la réponse de Justin à propos de l'ouverture par inadvertance d'applications à accéder à distance, rappelez-vous que même si rien n'écoute spécifiquement une connexion, le système d'exploitation va TOUJOURS écouter - ne serait-ce que pour router/mapper vers le processus approprié ou refuser ou déposez silencieusement le paquet. Par conséquent, le système d'exploitation est toujours un vecteur d'attaque spécifique qui peut rester non protégé lorsqu'un pare-feu permet au trafic de circuler vers un port "inactif".
Cependant, toutes choses étant égales par ailleurs dans ce scénario, l'ouverture d'un port inactif ou de 1 000 ports inactifs fait peu de différence. Mais écoutez certainement les conseils de principe du moindre privilège.
Autant que je sache, Mosh n'a pas vraiment besoin de mille ports pour fonctionner; il n'en a besoin que d'un (par client). Vous pouvez donc ouvrir n'importe quel port et dire à Mosh de l'utiliser (à partir de le manuel ):
mosh -p 60000 my.server
Quelle est la raison de la sélection aléatoire du port? Je ne comprends pas cela.
[MISE À JOUR] il ne sélectionne pas de port aléatoire. Il recherche dans un ensemble de ports pour trouver le premier ouvert ( voir code ). Sinon, vous devrez choisir un port libre manuellement sur un système multi-utilisateur.
Cela signifie que vous n'avez besoin que de ports autant que vous avez d'utilisateurs (personnes qui pourraient utiliser mosh) sur votre serveur . S'il s'agit de votre propre boîtier, il vous suffit d'ouvrir le port 60000.
Le problème est que l'ouverture d'une large gamme de ports peut permettre à un attaquant d'exposer une autre application susceptible d'utiliser ces ports. Par exemple, mon application EMR utilisée pour stocker les dossiers des patients peut être configurée pour utiliser cette plage de ports, mais je ne veux pas qu'une personne d'Internet non fiable puisse exploiter cette ouverture. Cela revient à faire respecter le moins de connaissances possible. Dans ces scénarios, vous voudriez tirer parti d'un VPN qui aurait cette plage de ports ouverte. Cela règle le problème de l'authentification et donc de l'autorisation. Si vous parlez de votre pare-feu externe sur votre DMZ votre confiance uniquement au niveau du protocole/port et doit donc être encore plus stricte.
Il devrait être parfaitement possible de minimiser la plage de ports UDP de mosh dans
https://github.com/keithw/mosh/blob/master/src/network/network.h#L77
Si j'ai bien compris, c'est la plage à partir de laquelle le processus d'expéditeur choisira le port UDP. Il devrait donc être possible de compiler une édition mosh locale "à portée étroite" et d'avoir une politique UDP de pare-feu locale "à portée étroite" appropriée pour mosh.
Ce qui m'amène à la méta-question: dans quelle mesure une plage est-elle suffisamment large pour que mosh soit utile?
Si j'ai bien compris, un port par serveur mosh est nécessaire. Ainsi, dans le cas d'un serveur personnel et de l'utilisation habituelle de tmux (= un seul client), un pour travailler et un pour réparer les choses est nécessaire.
Mais je peux me tromper, je ne suis pas un codeur C et j'ai découvert mosh seulement hier.