Accès à distance à une machine Linux derrière un pare-feu

Je vais déployer une machine Linux comme une sorte de terminal public à distance. Je voudrais pouvoir y accéder à distance via SSH pour la maintenance, mais je ne veux pas garder un port ouvert sur le pare-feu distant pour les rares occasions où j'ai besoin d'accéder à cette machine. J'ai pensé à un script simple pour créer un tunnel SSH inversé vers une machine à l'extérieur, mais je préfère ne pas obliger un utilisateur à faire quoi que ce soit lorsque j'ai besoin d'y accéder. Des idées?

Mise à jour: j'ai décidé d'aller avec mon plan d'origine d'un script pour créer un tunnel ssh inverse. Alors que d'autres solutions suggérées, telles que le détournement de port, correspondraient davantage à ce que je veux vraiment faire, dans ce cas, je n'ai pas d'autre accès pour configurer le routeur que de guider un utilisateur dans une configuration. frémir

Cela a moins à voir avec le fait qu'un port soit ouvert et plus avec le fait de ne pas vouloir guider un utilisateur dans le processus d'ouverture d'un port. Je n'ai malheureusement aucun accès à ce routeur.

Si changer de routeur est complètement hors de question, vous devrez peut-être envisager une solution P2P ou VPN comme Hamachi . Si vous configurez le système pour établir automatiquement la connexion VPN au démarrage, vous devriez pouvoir vous connecter à tout moment. Hamachi fait toute la négociation du pare-feu pour vous. Le seul inconvénient est que vous devez vous fier aux serveurs Hamachi qui sont opérationnels et fonctionnels lorsque vous devez vous connecter.

Si vous avez un serveur qui est toujours opérationnel, vous pouvez configurer l' autossh afin que le système distant garde toujours un tunnel ouvert et connecté à votre serveur. Le seul inconvénient est que le système distant est compromis, l'attaquant obtiendra les clés qui ont été utilisées pour établir la session ssh. Il serait très important de garder votre système qui accepte la connexion ssh vraiment verrouillé.

Ci-dessous est ma réponse d'origine, j'avais supposé que la mise à jour du routeur était une option.

Une solution que vous voudrez peut-être étudier si votre pare-feu le prend en charge est le détournement de port . Avec certains pare-feu, il devrait être possible d'envoyer un ensemble spécial de paquets que le pare-feu remarque puis ouvre temporairement le trou à travers le pare-feu.

Il existe de nombreuses implémentations, certaines mieux que d'autres. Certains utilisent une cryptographie forte pour rendre presque impossible pour une personne sans les bonnes clés d'envoyer le bon coup.

Je ne serais pas si inquiet de laisser le port 22 accessible à Internet, mais je prendrais certaines mesures pour le sécuriser.

Tout d'abord, désactivez l'authentification interactive du clavier et passez aux touches ssh.

Deuxièmement, installez quelque chose comme fail2ban sur votre serveur distant sur des adresses IP blackball qui sondent de manière répétée votre machine. Étant donné que vous avez configuré les clés ssh, il ne devrait pas y avoir d'échec d'authentification pour les utilisateurs autorisés.

Sinon, si vous le pouvez, suivez les conseils de WerkkreWs et configurez le pare-feu devant la machine pour mettre fin à une connexion vpn, puis autorisez uniquement le démon ssh sur le serveur distant à accepter les connexions provenant de ce vpn.

Alternativement, si votre pare-feu ne peut pas mettre fin à la connexion VPN, vous pouvez probablement transférer les paquets GRE ou IPSEC vers votre machine Linux et y mettre fin.

On dirait que vous cherchez knockd

Vous pouvez l'installer sur le serveur linux lui-même, avec iptables pour que ce soit un peu comme un pare-feu de 2ème niveau. Même avec le port 22 ouvert sur le pare-feu frontal, il ne serait pas ouvert sur le serveur, donc les analyses de port ne verraient aucun port ouvert. Ensuite, lorsque vous envoyez le "coup secret", tout à coup, vous avez un chemin ouvert vers le port 22.

Cela a-t-il du sens?

Pour résumer toutes les réponses:

utilisez ssh, mais rendez-le plus obscur et plus sûr.

Pour la sécurité:

• Assurez-vous que la connexion root n'est pas autorisée (PermitRootLogin no).
• Limitez les utilisateurs, qui peuvent se connecter par l'option de configuration AllowUsers ou AllowGroups.
• Assurez-vous qu'il utilise uniquement le protocole ssh à 2 versions (protocole 2).
• Il est conseillé d'utiliser uniquement des clés d'authentification, mais le mot de passe est plus pratique, lorsqu'il peut être nécessaire de se connecter au serveur à partir de vacances où vous n'avez pas accès aux clés d'authentification.

Pour l'obscurité:

• Modifiez le port ssh en un port élevé aléatoire dont vous vous souviendrez, comme 20486. Cela éliminerait la plupart des bruteforcers automatiques, mais cela ne le cacherait pas de toutes les analyses de port sur le serveur.
• Masquer la possibilité de se connecter au port. Une façon est le détournement de port mentionné dans d'autres réponses, mais vous avez besoin d'un logiciel spécial, qui ne peut pas être accessible partout. Une autre option simple consiste à utiliser un pare-feu iptables avec un module récent pour créer une règle, ce qui permettrait de se connecter uniquement au deuxième ou au troisième essai. Vous savez donc que vous devez essayer plusieurs fois de vous connecter avec succès, mais une simple analyse de tous les ports ne révélera pas le port ssh. Les règles seraient similaires à celles-ci:

iptables -A INPUT -m tcp -p tcp --dport 20486 -m state --state NEW -m recent --set
iptables -A INPUT -m tcp -p tcp --dport 20486 -m state --state NEW  -m recent --rcheck --seconds 60 --hitcount 2 -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 20486 -j DROP

Planifiez le script de votre tunnel ssh inverse ou ouvrez le port du pare-feu.

Si vous craignez que SSH soit ouvert au monde, vous pouvez planifier une tâche lors de votre période de maintenance avec des scripts iptables et ne disposer que du port disponible.

Examinez le portage pour ouvrir votre tunnel SSH.

En outre, exécutez denyhosts pour verrouiller les utilisateurs après trop de mauvaises demandes.

Les deux packages sont disponibles dans les référentiels Ubuntu, Fedora et RHEL standard.

Allez-y et ouvrez un port, faites-en un en dehors de la plage normale. J'en ferais un port aléatoire au-dessus de 1024. De cette façon, les pirates seraient même peu susceptibles de le chercher.

Aucune raison de ne pas percer le trou dans le pare-feu si vous avez besoin d'accéder à la machine à distance, mais rarement.

Cependant, si vous préférez toujours ne pas (ou ne pouvez pas) ouvrir le port, un simple script shell pourrait surveiller certaines ressources disponibles sur Internet que vous contrôlez et écoutez la commande pour lancer le tunnel inverse. Les comptes de messagerie, les canaux IRC et les pages Web viennent immédiatement à l'esprit comme déclencheurs.

Bien sûr, c'est beaucoup plus fragile et moins sûr que d'ouvrir simplement le port. Mais je suis sûr que vous avez vos raisons.