J'interdit accidentellement la connexion SSH à un serveur distant… Et ensuite?

61

Répétons-le, nous commettons tous des erreurs et je viens d’en commettre une.

Une brève histoire: je travaillais sur un VPS (Debian) que je louais, quand j'ai remarqué un comportement étrange. À l'aide de la netstatcommande, j'ai constaté une connexion non autorisée via SSH. Je ne savais pas quoi faire, alors j'ai décidé de fermer sa connexion en utilisant iptables:

iptables -A INPUT -p tcp --dport ssh -s IP -j DROP

Mais je suis fatigué et j'ai écrit

iptables -A INPUT -p tcp --dport ssh -j DROP

et je me suis mis à la porte (et tous les autres) ...

Comment puis-je réparer ça?

— TomoGuy
source

double possible Est - il possible d'accéder SSH un serveur avec un sous - réseau mal configuré?

— Kasperd

1

non, car il bloque tous les paquets ssh sur la machine. sur un sous-réseau mal configuré, il vous suffirait de tcpdump pour cette adresse mac, d'obtenir le sous-réseau sur lequel il est connecté, puis de configurer un nic virtuel sur le même sous-réseau et de lui parler.

— jfalcon alias Don Fanning le

50

Eh bien, vous avez certainement supprimé l'accès au moins à la personne non autorisée.

— un CVn

2

Pour la prochaine fois, peut-être que l'interrupteur d' un homme mort serait utile.

— Wayne Conrad

2

Qui est ton hôte? Un grand nombre d'hôtes VM offrent une console série qui vous permet d'utiliser SSH dans les cas où vous ne pouvez pas vous connecter depuis un emplacement distant.

— Jon

60

Il y a plusieurs alternatives:

Vérifiez s’ils disposent d’un accès IPMI / "KVM" / console au serveur, ce qui vous permet de le contrôler comme si vous disposiez d’un clavier physique.
S'ils ne le proposent pas, voyez si vous pouvez démarrer la VM sur un CD de Linux de récupération (certains fournisseurs le proposent), puis corrigez les règles de pare-feu de cette façon, puis démarrez-le normalement.
Si vous n'avez pas d'accès à la console, avant de démarrer la récupération ou de connecter le volume à une autre machine virtuelle (comme dans le cas Amazon, crédit de la réponse de user3550767), vous pouvez essayer la réponse d'Ankh2054 de redémarrer si vous n'avez pas enregistré les règles ( probablement le cas depuis que vous vous êtes mis à la porte avant d'avoir eu la chance de sauver). Utilisez le panneau de configuration ou demandez à quelqu'un de le redémarrer avec une réinitialisation non automatique (redémarrage ou arrêt brutal) au cas où le script init enregistre automatiquement les règles lors du redémarrage normal (crédit @jfalcon, @joshudson).

En pesez les inconvénients (par exemple, des données en cours d'écriture lors du redémarrage peuvent être perdues et une vérification du système de fichiers peut être requise au démarrage, donc une durée de démarrage plus longue, bien que ce délai puisse être inférieur au démarrage depuis la récupération).

— g491
source

1

en fonction du serveur vps, il peut ne pas y avoir d'accès distant. les systèmes tels que vmware, kvm, xen, etc. ont des consoles mais ne sont pas configurés pour la consommation publique. ferme qui autorise cette forme de contrôle public est openstack.

— jfalcon alias Don Fanning le

4

Cela dit, si c'est dans l'espace amazon / google, il peut capturer le lecteur et le monter à partir d'une autre machine virtuelle pour effectuer le correctif.

— jfalcon alias Don Fanning le

47

Si vous n'avez pas encore enregistré la règle IPtables, vous pouvez redémarrer le serveur sous VPS (si disponible) et la règle devrait disparaître.

— Ankh2054
source

sauf si le script init enregistre les iptables lors de l’arrêt.

— jfalcon alias Don Fanning le

3

@ jfalcon: C'est pourquoi vous pouvez leur demander de débrancher la prise virtuelle.

— joshudson

22

@ jfalcon C'est aussi pour cette raison que c'est une mauvaise idée de sauvegarder automatiquement à la fermeture ... faites une sauvegarde en toute conscience par l'administrateur système, et non par quelque chose que le système exécute à l'aveuglette.

— un CVn

@ joshudson: Vous devez dire au singe de redémarrage exactement ce qu'il faut faire et le mettre hors tension. Pas simplement initier un arrêt.

— jfalcon alias Don Fanning, le

@ MichaelKjörling: Cette philosophie est également fausse. Il s’agit d’un VPS tellement probable que ses applications sont mises en sandbox et qu’il n’a aucun contrôle sur les personnes qui appuient sur l’interrupteur. Et vous n'avez aucune idée de la façon dont l'hébergement VPS a configuré ses versions. Il n'y a rien de mal à économiser à l'arrêt. Son erreur était son erreur. La démarche intelligente en premier lieu aurait été de mettre SSH sur un port non standard ou d’utiliser fail2ban au lieu de réagir avec une réaction paniquée.

— jfalcon alias Don Fanning le

30

C’est à cela que servent les lignes d’assistance humaines. Appelez le fournisseur de services et demandez à l'un de leurs opérateurs de supprimer la règle pour vous.

— RobertG
source

3

Un moyen général de réparer une instance endommagée consiste à la fermer et à attacher le volume racine à une instance en cours de travail. Vous pouvez ensuite monter le volume à cet endroit et afficher les journaux ou modifier les fichiers de configuration. Vous pouvez alors détacher le volume et le démarrer à sa guise.

— utilisateur3550767
source

2

Vrai pour les VPS AWS; pas généralement vrai.

— MadHatter

@MadHatter Les détails exacts peuvent varier, mais si un fournisseur VPS n'offre aucune méthode pour démarrer avec une image de travail connue à partir de laquelle vous pouvez monter et réparer votre système de fichiers racine, je m'attendrais à ce qu'ils cessent leurs activités une fois que les clients appris à propos de cette limitation.

— Kasperd

En général, ils le font en proposant un accès à la console, ce qui vous permet de démarrer en mode mono-utilisateur ou à partir d'un support de secours (généralement sous la forme d'un fichier ISO). Je soutiens que cela est en réalité beaucoup plus normal que la façon bizarre de traiter le problème d'AWS, dans laquelle un second VPS est (temporairement) une exigence.

— MadHatter

@MadHatter Laquelle de ces deux approches semble étrange dépend peut-être de ce que vous connaissez le mieux. Et l’une ou l’autre approche fait le travail. Je ne peux pas vraiment commenter, car je n'ai besoin que d'un tel accès sur un seul fournisseur VPS.

— Kasperd

@kasperd: Non, ce que vous utilisez dépend de quel fournisseur de VPS prend en charge; ce n'est pas une question de choix. Si vous utilisez AWS, vous montez le volume sur un autre serveur virtuel principal; Si vous utilisez un fournisseur VPS plus normal, vous démarrez un utilisateur unique ou à partir d'un support de secours. Je ne fais pas cette remarque pour être une bite (enfin, pas tout à fait) mais parce qu'il est important de comprendre qu'il faut savoir quelles sont les méthodes prises en charge par le fournisseur, puis les utiliser. Essayer d'utiliser la méthode AWS avec, disons, Hetzner ne fonctionnera tout simplement pas , car un serveur Hetzner vs ne peut pas voir l'autre FS (afaik).

— MadHatter

3

Réponse officielle: accédez au panneau de gestion VPS, obtenez un accès local (KVM virtuel) ou appelez-les.

Explication des étapes / règles pour éviter de tomber à nouveau:

Certaines modifications apportées aux règles de l'IP, du routage et du pare-feu peuvent se détériorer et bloquer votre accès.
et cela s'applique aussi à la configuration des périphériques réseau dédiés, pas seulement aux VPS

Donc , à moins que vous êtes sûr à 100% que vous pouvez récupérer .. Je recommande de faire toujours un moyen de réinitialiser config réseau à son état précédent .. comme, ouvert la session de fond avec soit screen, nohupou tmuxmême cronpeut travailler pour cela, et ajouter iptables -Fou autre moyen souhaité pour réinitialiser quoi que ce soit à l'état précédent.

— Kagali-san
source