Sécuriser un VPS

... vis à vis des connexions malveillantes

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Hello,

J'utilise actuellement un VPS pour un site web, et je constate un nombre très important de tentatives de connexion ssh. J'ai bien sûr installé tous les utilitaires de défense "classiques" (fail2ban …).

Comme je ne dispose pas (encore :p ) de formation de sécurité informatique, je ne sais pas trop quoi penser de ces tentatives : C'est normal ? (j'aurais tendance à dire oui) Faut-il s'en inquiéter ?

En tout cas, 99% des IPs sont classé "malveillantes" sur des sites comme abuseipdb.com. Je me demandais donc :

  • si ça pouvait être intéressant de bannir définitivement ces IPs de mon serveur (blacklist), et ce au risque de bannir des utilisateurs innocents ? (je ne sais pas si ce genre d'IP est recyclé pour des utilisateurs lambdas)
  • s'il existait des services (un peu comme abuseipdb.com ) de récupérer (à l'aide d'une API) une blacklist des IPs récentes, histoire de les bannirs automatiquement (je vais pas m'amuser à en rentrer 10 par jour). Ou même de simplement checker si une IPs est malveillante.
  • si ça vaut le coup d'implémenter un système home-made, avec un compteur d'échecs de connexion (ce système serait directement alimenté depuis les logs de sshd), et qui bannis l'IP au bout d'un certain nombre d'échecs.

Une dernière question (on rentre sans-doute la parano là :D ) : est-ce que ça vaut le coup de mettre en place un système beaucoup strict de connexion sur le serveur ? En gros, supprimer les accès SSH par défaut pour tout le monde, et ne l'activer qu'après une série de mots de passes entrés sur le site internet par exemple ?
D'accord c'est une solution méga-tordue, mais je me dis qu'il y a forcément des gens qui ont réfléchi à de tels solution non ?

Voili-voilou, j'espère que vous pourrez éclairer ma lanterne pour m'éviter de tomber dans la parano :p

Édité par QuanticPotato

+0 -0

Cette réponse a aidé l'auteur du sujet

Pour SSH, la solution est de n'autoriser que l'authentification par clé, interdire l connexion en tant que root et bouger le serveur SSH sur un port pas standard. Avec ça normalement tu ne devrais plus avoir aucune tentative de connexion provenant d'un bot. J'ai fait ça, je vois plus rien.

Comme d'habitude le wiki d'Arch est très complet: désactiver l'auth par clef et interdire de se connecter en root. Il n'existe aucune raison valide pour se connecter via SSH en root quand on a accès à sudo, donc autant l'interdire.

N'oublie pas de mettre tes clés sur le serveur comme dit dans le premier lien avant d'interdire la connexion par mot de passe, ça serait ballot et ça a failli m'arriver.

Édité par anonyme

+2 -0
Auteur du sujet

J'utilisais déjà des clés ssh, mais il est vrai qu'il était toujours possible de se connecter par mot de passe (je pensais que c'était plus une sorte de "raccourci", pour se connecter plus vite).

Sinon (c'est sans doute une question de principe évidente) quand on créer un système de déploiement, tout doit être fait avec un utilisateur fait pour ça (non root) ?
Parce que là j'avoue qu'il tourne en root ..

+0 -0
Auteur du sujet

J'ai un script envoy qui se connecte en root (avec une clé publique) sur mon serveur, et qui lance tous les scripts de déploiement du site web (en gros il installe/compile des données précédemment envoyées avec git).

Le truc c'est qu'il se connecte en root, et qu'il fout tout dans un sous dossier de /root …

+0 -0
Auteur du sujet

Si bien sûr, je suis justement en train de lui faire utiliser un utilisateur dédié.

Le problème initial c'était qu'envoy galère avec les shell (notamment lors d'un password prompt), et donc comme c'était plutôt des tests à la base je faisais tourner en root.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte