Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2016-02-09T10:56:00+01:00Les derniers messages parus sur le forum de Zeste de Savoir.Sécuriser un VPS, message #979892016-02-09T10:56:00+01:00QuanticPotato/@QuanticPotatohttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97989<p>Si bien sûr, je suis justement en train de lui faire utiliser un utilisateur dédié. </p>
<p>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.</p>Sécuriser un VPS, message #979842016-02-09T10:28:30+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97984<p>Pourquoi il a besoin de se connecter en root ? Il y a pas moyen de le faire faire ses tâches en simple utilisateur et d'élever ses privilèges uniquement quand il faut ? </p>Sécuriser un VPS, message #979822016-02-09T10:25:13+01:00QuanticPotato/@QuanticPotatohttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97982<p>J'ai un script <a href="https://laravel.com/docs/5.0/envoy">envoy</a> 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).</p>
<p>Le truc c'est qu'il se connecte en root, et qu'il fout tout dans un sous dossier de /root …</p>Sécuriser un VPS, message #979782016-02-09T10:19:20+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97978<p>Tu as quoi qui tourne en root ? J'ai pas bien compris ce qu'est ton système de déploiement.</p>Sécuriser un VPS, message #979772016-02-09T09:55:37+01:00QuanticPotato/@QuanticPotatohttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97977<p>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).</p>
<p>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) ?<br>
Parce que là j'avoue qu'il tourne en root ..</p>Sécuriser un VPS, message #977642016-02-07T10:00:46+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97764<p>Pour SSH, la solution est de n'autoriser que l'authentification par clé, interdire l connexion en tant que <code>root</code> 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.</p>
<p>Comme d'habitude le wiki d'Arch est très complet: <a href="https://wiki.archlinux.org/index.php/Secure_Shell#Force_public_key_authentication">désactiver l'auth par clef</a> et <a href="https://wiki.archlinux.org/index.php/Secure_Shell#Deny">interdire de se connecter en root</a>. Il n'existe <strong>aucune</strong> raison valide pour se connecter via SSH en root quand on a accès à <code>sudo</code>, donc autant l'interdire. </p>
<p>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. </p>Sécuriser un VPS, message #977622016-02-07T09:32:27+01:00QuanticPotato/@QuanticPotatohttps://zestedesavoir.com/forums/sujet/5325/securiser-un-vps/?page=1#p97762<p>Hello,</p>
<p>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 …). </p>
<p>Comme je ne dispose pas (encore <img alt=":p" src="/static/smileys/langue.png"> ) 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 ?</p>
<p>En tout cas, 99% des IPs sont classé "malveillantes" sur des sites comme <a href="http://abuseipdb.com"><a href="http://abuseipdb.com">abuseipdb.com</a></a>. Je me demandais donc :</p>
<ul>
<li>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)</li>
<li>s'il existait des services (un peu comme <a href="http://abuseipdb.com"><a href="http://abuseipdb.com">abuseipdb.com</a></a> ) 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 <em>checker</em> si une IPs est malveillante.</li>
<li>si ça vaut le coup d'implémenter un système <em>home-made</em>, 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.</li>
</ul>
<p>Une dernière question (on rentre sans-doute la parano là <img alt=":D" src="/static/smileys/heureux.png"> ) : est-ce que ça vaut le coup de mettre en place un système beaucoup <em>strict</em> 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 ?<br>
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 ?</p>
<p>Voili-voilou, j'espère que vous pourrez éclairer ma lanterne pour m'éviter de tomber dans la parano <img alt=":p" src="/static/smileys/langue.png"></p>