Le blog de Dju - Mot-clé - sshUn peu de moto, un zeste de geek, et un brin d'autres trucs ;-)2024-03-22T17:50:26+01:00Djuurn:md5:5e61426dd704534f4aef077f5b82260bDotclearDechiffrement d'un volume LUKS à distance sous Debianurn:md5:d99229ca606b74c55f8ca6fe2546c7d52023-09-03T21:05:00+02:002023-09-05T09:38:03+02:00DjuServeurdebiandropbearluksssh <p><img src="https://blog.crifo.org/public/2023/.encrypt_t.jpg" alt="" style="float:left; margin: 0 1em 1em 0;" /></p>
<p>Quand on a un serveur sous debian, avec le disque chiffré grâce à LUKS, il faut avoir un écran/clavier pour taper le mot de passe au boot.<br />
Pas très pratique pour un serveur !</p>
<p>Mais une solution existe pour cela: le paquet dropbear-initramfs.</p>
<p>Il va faire en sorte que lorsque la machine démarre, dropbear (un serveur ssh très light) soit lancé, car intégré dans l'initramfs.<br />
Ce qui va nous permettre de s'y connecter en SSH (avec authentification par clé), rentrer le mot de passe pour déchiffrement, et qu'au final le système démarre <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /></p>
<p>Et comme je fais cela souvent, il m'arrive d'oublier une étape, en voici dont la liste :p</p>
<p>Pour ce faire, 5 étapes:</p>
<ol>
<li>installer dropbear</li>
<li>configurer l'authentification</li>
<li>configurer dropbear</li>
<li>configurer l'initramfs</li>
<li>désactiver dropbear pour que ssh se lancer normalement après</li>
</ol>
<p>1/ installation</p>
<p>on l'installe simplement en une commande :</p>
<pre>apt install dropbear dropbear-initramfs</pre>
<p>2/ Authentification</p>
<p>Afin de s'authentifer par clé, on créé le fichier <strong>/etc/dropbear/initramfs/authorized_keys</strong>, dans lequel on inscrit notre clé publique (généralement dans ~/.ssh/id_rsa.pub)</p>
<p>3/ Configuration de dropbear</p>
<p>On édite le fichier <strong>/etc/dropbear/initramfs/dropbear.conf</strong> et on décommente la ligne DROPBEAR_OPTIONS.<br />
Et on indique les options entre guillemets. au final, la ligne doit ressembler à ceci:</p>
<pre>
DROPBEAR_OPTIONS="-RFEsjk -c /bin/cryptroot-unlock"
</pre>
<p>ces options permettent pluisieurs choses, notemment de ne pas mettre dropbear en background, et qu'il affiche ce qui se passe à l'écran (dans stderr), de désactiver l'authentification par password, et le port forwarding.<br />
Enfin et surtout la derniere option permet de demander directemnet le mot de passe LUKS, sans qu'on aie accès à un shell busybox <img src="/themes/BlueSky/smilies/wink.gif" alt=";)" class="smiley" /></p>
<p>4/ Configuration de l'initramfs</p>
<p>Dropbear étant maintenant configuré, on passe à l'initramfs.<br />
On édite pour cela le fichier <strong>/etc/initramfs-tools/initramfs.conf</strong>, et on rajoute une ligne à la fin</p>
<pre>
IP=192.168.30.27::192.168.30.1:255.255.255.0::eth0:off
</pre>
<p>ici on indique que l'initramfs doit monter l'interface réseau eth0 avec l'ip 192.168.30.27; une gateway en 192.168.30.1 et un netmask à 255.255.255.0.<br />
Cette partie est tres importante, car sans elle la machine n'aura pas de réseau à ce stade du démarrage.</p>
<p>Enfin, on met à jour l'initramfs:</p>
<pre>
update-initramfs -u
</pre>
<p>5/ Désactivation de dropbear</p>
<p>Finalement, on désactive dropbear pour qu'il ne se lance pas au démarrage. il doit etre lancé uniquement pendant la phase de l'initramfs, et doit se désactiver après.<br />
Sans quoi, sshd ne pourra pas démarrer <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /></p>
<p>Si vous utilisez systemd:</p>
<pre>systemctl disable dropbear.service</pre>
<p>Si vous utilisez sysvinit:</p>
<pre>update-rc.d -f dropbear remove</pre>
<p>Et voila, c'est terminé. <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /></p>
<p>Désormais, lorsque la machine démarrera, vous pourrez toujours taper votre mot de passer au clavier si besoin, mais vous pourrez surtout vous y connecter en ssh, et une fois identifié, un prompt vous sera proposé pour taper votre mot de passe LUKS.</p>https://blog.crifo.org/post/2023/09/03/Dechiffrement-d-un-volume-LUKS-a-distance-sous-debian#comment-formhttps://blog.crifo.org/feed/atom/comments/99Login SSH long sur Ubuntu server 9.10urn:md5:43292295449d4cc81f79d89806d9b1642010-04-07T19:35:00+02:002010-04-09T19:26:41+02:00DjuUbuntuloginmotdsshubuntuupdate-motd<p><img src="https://blog.crifo.org/public/201004/.ubuntu-logo1_t.jpg" alt="ubuntu-logo1.jpg" style="float:left; margin: 0 1em 1em 0;" title="ubuntu-logo1.jpg, avr. 2010" />
Depuis la version 9.10, le login en ssh est particulièrement long, la ou d'habitude on était connecté le temps de claquer des doigts.<br />
Après investigation, le responsable est le paquet <strong>update-motd</strong>, inclus par défaut, qui a subi un changement à partir de la 9.10, augmentant ainsi le temps de connexion.<br />
Voici la solution permettant de contourner ce problème pour les plus impatients qui n'aiment pas attendre et se font des sueurs froides à chaque fois :p</p> <p><ins>Détails du fonctionnement</ins> :<br />
Le paquet update-motd est un ensemble de script permettant de générer le fichier <strong>/etc/motd</strong>, dont le contenu apparait lorsqu'on se logge en ssh sur un ubuntu server.<br />
Dans le dossier <strong>/etc/udate-motd.d</strong> on retrouve les scripts, dont le nom commence par un numéro à 2 chiffres permettant de définir un ordre d'execution.<br />
Chaque script écrit des infos dans la sortie standard, et le tout est concaténé dans le fichier /etc/motd, grâce à la commande <strong>run-parts</strong><br />
Pour des infos plus détaillées sur tout le processus, voir la page officielle (en anglais) ici:<br />
<a href="https://help.ubuntu.com/9.04/serverguide/C/update-motd.html">https://help.ubuntu.com/9.04/serverguide/C/update-motd.html</a></p>
<p>Jusqu'à la version 9.04 comprise, un cron exécutait la génération du fichier motd toutes les 10 minutes, donc pas de problème pour se connecter.<br />
Depuis la 9.10, le motd n'et plus généré toutes les 10 minutes, mais quand on se connecte en ssh.<br />
Du coup on poireaute 5/6 secondes, voire plus, avant d'avoir le shell... et moi j'aime pas ça :pf:</p>
<p>La première solution est, pour ceux qui n'ont pas besoin de ces infos au login, de supprimer complètement le paquet :</p>
<blockquote><p>aptitude purge update-motd</p></blockquote>
<p>La deuxième solution, que j'ai adoptée, est de faire un compromis: désinstaller update-motd, tout en gardant les scripts afin de générer un motd périodiquement.</p>
<blockquote><p>aptitude remove update-motd</p></blockquote>
<p>ici on enlève la paquet <strong>mais sans le purger</strong>. de fait on conserve les scripts dans /etc/update-motd.d/ <br />
Après quoi, il n'y a plus qu'à se faire un cron (en root) pour générer le motd.<br />
Par exemple, voici ce qu'il faut ajouter pour générer le motd toutes les 15 minutes (en tapant la commande <strong>crontab -e</strong>)</p>
<blockquote><p>*/15 * * * * run-parts /etc/update-motd.d/ > /etc/motd</p></blockquote>
<p>Résultat, le motd n'est plus généré quand on se connecte par ssh, on a le shell immédiatement <img src="/themes/BlueSky/smilies/wink.gif" alt=";)" class="smiley" /></p>
<p>Et plus généralement, on peut soit supprimer complètement le fichier motd, soit mettre dedans des infos statiques, qui s'afficheront alors à la connexion.<br /></p>
<p>Et pour les geeks amateurs de logo en ascii-art, on peut aussi utiliser <a href="http://www.system-linux.eu/index.php?post/2009/01/05/Joli-logo-au-demarrage-dun-shell">linuxlogo</a>, ou <a href="https://blog.crifo.org/post/2010/03/11/Ascii-art-avec-Figlet">Figlet</a></p>https://blog.crifo.org/post/2010/04/07/Login-SSH-long-sur-Ubuntu-server-9.10#comment-formhttps://blog.crifo.org/feed/atom/comments/45Protéger son acces SSHurn:md5:4896f9f6d515953299bfe1be0f7a9bc62010-03-10T22:30:00+01:002010-11-03T23:56:47+01:00DjuServeurfirewallhackprotectionsshsyn flood<p><img title="pirate.jpg, mar. 2010" style="float: left; margin: 0 1em 1em 0;" alt="" src="https://blog.crifo.org/public/201003/.pirate_t.jpg" /></p>
<p>Lorsqu'on a un serveur en ligne 24h/24, il est obligatoire d'avoir un accès SSH pour pouvoir s'y connecter à distance et intervenir dessus.<br />
De fait, il y aura toujours des petits malins pour s'amuser à aller scanner vos ports et essayer d'entrer sur votre machine.<br />
La plupart du temps, la technique n'est pas très évoluée et les tentatives sont faites en brute-force, c'est à dire en essayant successivement des logins et mots de passe différents jusqu'à trouver le bon.<br />
On se retrouve donc avec un fichier log de 3 km de long, ainsi qu'une certaine utilisation des ressources de la machine ainsi que de sa bande passante...<br />Bref, pas glop !</p> <p>En premier lieu, on change généralement le port. il est par défaut à 22, et donc facile à identifier. Beaucoup de softs tels que nmap le detecteront.<br />On peut le changer pour un autre à 5 chiffres, on sera deja un peu plus tranquille.<br />Pour ce faire, on peut éditer le fichier <strong>/etc/ssh/sshd_config</strong><br />Toujours dans ce même fichier, on peut indiquer les utilisateurs autorisés à se connecter, via la commande AllowUsers.<br />Exemple, on veut autoriser juste titi et toto :</p>
<pre>AllowUsers titi toto</pre>
<p>Encore mieux, on peut donner un user@ip.<br />On peut ainsi autoriser les acces root pour le reseau local, et un utilisateur pour le reste:</p>
<pre>AllowUsers titi toto@192.168.1.1 root@192.168.2.0/24</pre>
<p>Maintenant, il y a toutes sortes d'attaques utilisant des techniques différentes, je ne vous parlerai ici que de la brute-force.</p>
<p>Lors de ce type d'attaque, le hacker établit plusieurs connexions par secondes, chacune avec un couple login/pass différents.
Afin de s'en protéger et de bannir l'adresse ip de l'attaquant, on va rajouter ces 3 lignes dans notre firewall iptables :</p>
<pre>iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --set<br />iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j LOG --log-prefix="SSH BRUTEFORCE BANNED"<br />iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP</pre>
<p><ins>Explication :</ins><br />- La 1è ligne indique que lorsqu'une connexion arrive sur le port 22 (port ssh par défaut, à adapter suivant vos besoins), on va la marquer comme "à surveiller"<br />- La 2è va logger l'adresse IP et la date si il y a 3 nouvelles connexions venant de la meme adresse IP en 90 secondes<br />- Enfin la 3è va bannir cette adresse IP, et ne plus répondre à ces requêtes.</p>
<p>Ici ces 3 règles sont faites pour des connexions entrantes arrivant sur l'interface eth1, à adapter également <img src="/themes/BlueSky/smilies/wink.gif" alt=";)" class="smiley" /></p>
<p>L'avantage de ces règles est que toutes les tentatives de brute-force vont être loggées, et les ip bannies.<br />(on peut d'ailleurs dé-commenter la 2è ligne si on ne veut pas de log)<br />
Mais l'inconvénient est que si vous vous plantez de login ou mot de passe lors de la connexion, plus de 3 fois en 90 secondes, ou que vous vous connectez puis deconnectez 3 fois en 90 secondes, vous êtes mort ! :D <br />
Il vous faudra donc être trèèèèès prudent (surtout quand vous êtes à l'extérieur et que vous accédez en ssh à votre machine depuis votre iphone jailbreaké, on peut facilement se planter de touche, vécu inside... lol ) et adapter le nombre de connexions et le temps suivant vos besoins.<br />Dans l'exemple ci dessus, c'est assez drastique, suite à de très nombreuses tentatives. Dans un contexte courant, on pourrait mettre par exemple 5 connexions sur 5 minutes.</p>
<p>Pour faire mieux, on peut également configurer son firewall pour n'autoriser l'accès à SSH que depuis une adresse IP en particulier, comme ça plus de problème <img src="/themes/BlueSky/smilies/wink.gif" alt=";)" class="smiley" /></p>
<pre>iptables -A INPUT -i eth1 -p tcp --dport 22 -s 1.2.3.4 -j ACCEPT</pre>
<p>Par contre, il faut penser à autoriser autant d'adresses ip que vous avez de connexions extérieures; sinon vous serez coincé aussi.</p>
<p>Au passage, si vous avez installé <a href="https://blog.crifo.org/post/2010/01/12/Monitorer-son-serveur-avec-Munin">Munin</a> sur votre machine, <a href="http://muninexchange.projects.linpro.no/?search=&cid=0&os[4]=on&os[7]=on&os[3]=on&os[2]=on&os[5]=on&os[8]=on&os[1]=on&os[6]=on&pid=420">il y a un plugin</a> pour monitorer les accès. cela peut donner une bonne idées de la quantité de tentatives <img src="/themes/BlueSky/smilies/wink.gif" alt=";)" class="smiley" /></p>
<p>Enfin, pendant qu'on est dans les règles firewall, en voici également une pour se protéger du "syn-flood", technique consistant à initier massivement des connexions TCP, donc envoyer des paquets syn à un serveur sans y répondre, rendant ainsi à terme la machine distante non-communicante, voire figée si trop de ressources utilisées.<br />Testé et approuvé !</p>
<pre>echo 1 > /proc/sys/net/ipv4/tcp_syncookies<br />iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ! ALL SYN -j DROP</pre>
<p>La 1è ligne active la protection anti syn-flood au niveau du kernel, et la 2è indique à iptables de bloquer toutes les nouvelles connexions tcp ne commençant pas par un syn.</p>
<p>Longue vie à votre serveur <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /></p>https://blog.crifo.org/post/2010/03/10/Proteger-son-acces-SSH#comment-formhttps://blog.crifo.org/feed/atom/comments/33