Mais quand on se trouve sur une machine qui n’a pas d’interface graphique, ou par SSH ?
Effectivement, on peut s’en sortir à grand coup de du, grep et find .

Par exemple, et vous conviendrez que c’est facile à mémoriser :

du -cks * | sort -rn | while read size fname; do for unit in k M G T P E Z Y; do if [ $size -lt 1024 ]; then echo -e  « ${size}${unit}\t${fname} »; break; fi; size=$((size/1024)); done; done.

Mais il n’est pas du tout pratique de se construire une représentation de l’arborescence pour agir efficacement et rapidement.

Confronté à un manque surprenant de place sur un NAS distant venant à peine d’être installé (500 Go / 1 mois), j’ai recherché un outil me permettant de trouver quel utilisateur squattait la place.

NCDU, pour NCurses Disk Usage, permet d’analyser le système de fichier, en tout cas l’arborescence dans laquelle vous vous trouvez ou celle que vous lui indiquez, et de naviguer dedans. Et de supprimer les fichiers/dossiers inutiles que vous rencontreriez.

Dans mon cas, supprimer le dossier de films de vacances² d’un utilisateur a permis de retrouver de quoi travailler confortablement pour les autres.

NCDU se trouve dans les dépôts officiels, et un simple sudo apt-get install ncdu vous permettra de profiter de ce formidable cli tool.

1. L’équivalent pour windows est WinDirStat
2. mouais…

En effet, rien n’empêche le propriétaire du point d’accès de surveiller tous les échanges sur cette borne, ou un pirate de sniffer les communications.

Il est possible d’utiliser votre serveur qui tourne à la maison, (voire même un serveur kimsufi, dédibox, ou autre), comme relai pour vos communication, à la fois pour la navigation web et pour les mails. L’important étant que vous ayez confiance dans la machine qui va vous servir d’intermédiaire et du réseau sur lequel elle est connectée.

L’avantage, c’est que c’est rapide et simple à mettre en place, même au dernier moment.

Précisions

Un tunnel ssh ne permet de passer que des protocoles basés sur TCP, au contraire d’un VPN qui permet de transporter tout type de trame IP et non IP en plus d’apporter un routage complet. Ce n’est donc pas un VPN au sens réel du terme, mais cela va vous permettre d’utiliser la sécurité du SSH sur la partie du réseau qui n’est pas fiable.

Creusons le tunnel

Votre ordinateur relai devra, bien évidemment, avoir un serveur SSH accessible depuis l’extérieur. L’idéal étant de pouvoir s’y connecter par clef plutôt que par mot de passe, ce qui vous permettra de fermer l’authentification par clef et de limiter les attaques. Mais les deux fonctionnent.

Je vous laisser lire la documentation pour mettre en place un serveur ssh si vous ne savez pas encore le faire.

Nous allons donc lancer une connexion vers notre serveur, et « binder » (lier) cette connexion à un port local afin que tout ce qui arrive sur le port local soit transféré sur la connexion SSH (et vice versa). Dans un terminal, qu’il faudra laisser ouvert tout le temps de la session, entrez ceci:

ssh -D 1234 utilisateur@serveur_relai

Un man ssh vous donnera plus de détails sur le fait que l’option -D fait que SSH se comporte comme un serveur SOCKS et vous rappellera que seul root peut utiliser les ports privilégiés. Nous utilisons arbitrairement le port 1234, mais vous pouvez utiliser n’importe quel port local supérieur à 1024 (lancé par un utilisateur non root) à condition qu’un service ne tourne pas déjà sur ce port.

Si votre serveur ssh ne tournait pas sur le port par défaut, vous pourrez alors utiliser cette commande en précisant le port de votre serveur:

ssh -D 1234:port_ssh utilisateur@serveur_relai

par exemple

ssh -D 1234:443 utilisateur@serveur_relai

ou

ssh -D 1234 -p 443 utilisateur@serveur_relai

Si vous fermez le terminal dans lequel vous avez ouvert le tunnel, la communication serait fermée et vos logiciels ne pourraient plus sortir. Il faudra donc ne pas le fermer tout le temps de la session.

Hey Ho, Hey Ho, on rentre … dans le tunnel

Maintenant que nous avons créé notre tunnel, il faut indiquer aux logiciels de l’utiliser.

Par exemple, pour firefox:

menu Édition > Préférences > Avancé > Réseau > Paramètres

Utilisez un proxy SOCKS qui est donc votre ordinateur (point de départ de la connexion SSH) sur le port indiqué (1234 dans ce cas) tel que ci dessous

Pour vous convaincre que vous passez par votre serveur et non par la connexion wifi en cours, allez visiter un site comme http://www.monip.org/ qui vous montrera votre adresse IP externe. Si votre serveur a une IP fixe, vous reconnaitrez facilement votre IP. Sinon, visitez le site, un coup sans proxy, un coup avec, et vous verrez que l’ip n’est pas la même.

Par exemple, pour thunderbird:

Les avantages de cette solution, pour envoyer du mail, sont:

• vous n’aurez pas à modifier le serveur SMTP d’envoi à chaque fois, même si des extentions existent pour compenser ce problème.
• pas d’interception de vos mails par un éventuel proxy ou sniffer sur le réseau
• l’adresse IP d’expédition est celle de votre serveur, pas celle de votre emplacement actuel (vie privée respectée)

Rendez vous à menu Édition > Préférences > Avancé > Réseau et espace disque > Paramètres et paramétrez tel que sur l’image suivante:

Lorsque vous enverrez un mail, il passera par le tunnel et sera donc réellement envoyé par votre serveur relai vers votre propre fournisseur d’accès, indépendamment du FAI depuis lequel vous êtes actuellement connecté.

Pour les autres logiciels:

Le principe du paramétrage est identique aux exemples ci dessus. Cherchez dans leur configuration comment utiliser un proxy socks.

Ça peut aussi ne pas fonctionner!

En effet, si un proxy est paramétré sur votre réseau (pas chez vous, là où vous êtes connecté) et qu’il ne laisse pas passer le ssh, vous êtes bloqué. Mais il existe parfois des solutions:

• Si le blocage du ssh est dû aux ports qui sont autorisés, il vous faudra mettre votre serveur ssh (chez vous) en écoute sur un de ceux ci. Il y a de fortes chances pour que le http et le https soient autorisés (sinon le proxy ne servirait à rien, autant débrancher le câble…).
• Si le blocage est dû à l’analyse des flux par le proxy et que le ssh est refusé, il faudra passer par un tunnel http dans lequel vous ferez passer un tunnel ssh (ou ce que vous voudrez). Vous pouvez utiliser l’excellent http-tunnel qui vous sortira de l’impasse.
• Si le proxy utilise un filtrage applicatif en plus du reste… c’est que l’admin est un acharné et que vous n’arriverez pas à sortir par cette voie.

Notez qu’il est possible de faire la même chose avec putty et Windows mais je vous laisser faire ça seuls, n’ayant plus de licence depuis longtemps, et encore moins l’envie de me salir les mains avec ça.

A lire aussi:

• http://proxytunnel.sourceforge.net/paper.php
• http://forum.ubuntu-fr.org/viewtopic.php?id=213500

Si vous possédez un serveur avec SSH opérationnel, vous ne serez pas long à avoir des messages tels que ceux ci dans le fichier /var/log/auth.log:

...
Mar 11 12:48:21 serv sshd[12956]: Failed password for invalid user root from 64.71.148.162 port 47270 ssh2
Mar 11 15:45:04 serv sshd[6954]: Did not receive identification string from 210.21.30.72
Mar 11 15:46:48 serv sshd[7041]: Did not receive identification string from 81.93.188.5
Mar 11 15:47:50 serv sshd[7106]: User root from 210.21.30.72 not allowed because none of user s groups are listed in AllowGroups
Mar 11 15:47:50 serv sshd[7106]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.21.30.72  user=root
Mar 11 15:47:52 serv sshd[7106]: Failed password for invalid user root from 210.21.30.72 port 54346 ssh2
Mar 11 15:49:33 serv sshd[7241]: User root from 81.93.188.5 not allowed because none of user s groups are listed in AllowGroups
Mar 11 15:49:33 serv sshd[7241]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=81.93.188.5  user=root
Mar 11 15:49:35 serv sshd[7241]: Failed password for invalid user root from 81.93.188.5 port 44663 ssh2
Mar 12 00:51:18 serv sshd[22229]: User root from host.ongamemarketing.com not allowed because none of user s groups are listed in AllowGroups
Mar 12 00:51:18 serv sshd[22229]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host.ongamemarketing.com  user=root
Mar 12 00:51:20 serv sshd[22229]: Failed password for invalid user root from 174.133.12.130 port 48089 ssh2
Mar 12 00:51:22 serv sshd[22236]: User root from host.ongamemarketing.com not allowed because none of user s groups are listed in AllowGroups
Mar 12 00:51:22 serv sshd[22236]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host.ongamemarketing.com  user=root
Mar 12 00:51:24 serv sshd[22236]: Failed password for invalid user root from 174.133.12.130 port 48521 ssh2
Mar 12 01:47:10 serv sshd[30827]: Did not receive identification string from 114.200.199.144
Mar 12 01:53:17 serv sshd[31227]: Invalid user staff from 114.200.199.144
Mar 12 01:53:17 serv sshd[31227]: pam_unix(sshd:auth): check pass; user unknown
Mar 12 01:53:17 serv sshd[31227]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=114.200.199.144
Mar 12 01:53:19 serv sshd[31227]: Failed password for invalid user staff from 114.200.199.144 port 35343 ssh2
Mar 12 01:53:27 serv sshd[31234]: Invalid user sales from 114.200.199.144
...

Vous avez besoin de pouvoir vous connecter en ssh depuis le réseau local, depuis l’extérieur, mais vous voulez limiter les risques. Il existe plusieurs solutions, qui peuvent être cumulées:

Sécuriser par la configuration de SSH

N’autoriser QUE certains utilisateurs à accéder au service

Si vous avez peu d’utilisateurs nécessitant un accès ssh, vous pouvez les déclarer ainsi en ajoutant cette ligne dans le fichier de configuration /etc/ssh/sshd_config (et en redémarrant le service après chaque modification)

AllowUsers titi toto

Après relance du service ssh, les utilisateurs titi et toto pourront se connecter en ssh, les autres utilisateurs se verront refuser leur mot de passe.

Vous pouvez aussi créer un groupe (par exemple: sshusers) et autoriser tous les utilisateurs de ce groupe à se connecter en ssh. Ceux n’appartenant pas à ce groupe se verront refuser leur mot de passe.

addgroup sshusers
adduser toto sshusers
adduser titi sshusers

Puis ajoutez la ligne suivante dans /etc/ssh/sshd_config:

AllowGroups sshusers

IN and OUT

Oui, mais voilà un nouveau problème:

1. Le serveur fait passerelle avec internet, et possède une carte sur le réseau interne, et une carte vers le réseau internet.
2. Tous mes utilisateurs internes doivent pouvoir accéder par ssh (ce qui est le cas avec la configuration par défaut), mais ne doivent pas pouvoir accéder depuis l’extérieur (parce qu’ils n’en ont pas besoin, ou parce que les mots de passe des utilisateurs sont trop simples)
3. Si je laisse la configuration ainsi, le serveur sera piraté très rapidement.

Il est possible d’ajouter une directive à la liste des autorisations, permettant de faire ceci:

AllowUsers *@192.168.0.*

Ainsi, tous les utilisateurs du réseau local (et possédant un compte sur le serveur) pourront accéder par ssh, mais ne pourront pas le faire s’ils ne proviennent pas du réseau local (par internet).
Si je veux pouvoir ensuite me connecter depuis l’internet pour faire de la télémaintenance, il me suffit d’ajouter mon compte et de transformer la ligne en ceci:

AllowUsers manu *@192.168.0.*

(1)

Il est possible aussi de cumuler les directives Users et Groups pour obtenir des possibilités supplémentaires. Exemple:

1. Seuls certains de mes utilisateurs locaux doivent pouvoir se connecter au serveur, depuis le net ou en local.
2. Je veux pouvoir m’y connecter de partout (local et internet)

La configuration est la suivante:

AllowGroups sshusers
AllowUsers manu

Ainsi, seuls les utilisateurs appartenant au groupe sshusers pourront se connecter au serveur, en plus de l’utilisateur manu qui pourra se connecter depuis n’importe où.

Si je possède un adresse IP fixe, et que je suis assez bête pour crée un compte manu avec le mot de passe manu, je peux tout de même limiter l’accès par mon adresse IP (80.80.80.80)

AllowUsers @80.80.80.80

Je suis désolé, ça va pas être possible…

Vous pouvez même ajouter des directives inverses, pour interdire les connexions:

DenyUsers invite
DenyGroups stagiaires

Autres configurations conseillées de ssh

Vous pouvez modifier d’autres éléments du fichier de configuration, qui permettront de sécuriser un peu plus votre serveur ssh:

• Changer le port d’écoute par défaut: vous pouvez changer ce port par autre chose que 22. Sachez cependant que la protection apportée par ce changement est TRÈS FAIBLE. Un scan de vos port repérera le port que vous avez choisi, et des logiciels de scans sont capable de déterminer le service qui tourne derrière ce port. Cela vous permettra seulement d’échapper à certains robots qui ne tentent des connexions que sur le port 22.
• N’autoriser une identification que par clef: il vous faudra générer des clefs d’identification (avec seahorse pour gnome ou ssk-keygen) pour tous vos utilisateurs et empêcher l’autentification par mot de passe dans la configuration de SSH. Cette protection est très efficace, par contre, il faut que les clefs soient sécurisées (pas sur une clef usb qui peut se perdre ou se faire voler, pas sur un partage accessible, pas échangées par courriel, …). L’autre inconvénient, c’est que vos clefs doivent voyager avec vous et être installées sur les ordinateurs que vous utilisez; d’où une incompatibilité avec le point précédent, si vous n’avez pas une politique stricte de stockage des clefs.
• Ne JAMAIS autoriser la connexion de l’utilisateur root: (PermitRootLogin no).  Il y a toujours un utilisateur root sur tous les Linux (même sur Ubuntu) et vous facilitez le travail d’un éventuel pirate, puisqu’il n’a qu’un mot de passe à trouver. Autrement, il doit d’abord trouver un login valide, puis son mot de passe, puis celui du root. Si vos mots de passe et vos logins sont adaptés, cela lui prendra des années avant d’y arriver par ce moyen.

Ajouter des logiciels de sécurisation

fail2ban

fail2ban est un logiciel qui va surveiller les tentatives de connexion échouées dans le fichier /var/log/auth.log , et bloquer, en modifiant les règles iptables à la volée, un nombre trop élevé de connexions échouées. Ce logiciel permet aussi, de la même manière, de protéger votre serveur apache, postfix, vsftpd, proftpd, wuftpd, sasl, dns, …
Une fois installé, il vous suffit d’éditer le fichier /etc/fail2ban/jail.conf pour configurer son comportement. Exemple pour ssh:

...
[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = <a class="linkification-ext" title="Linkification: http://10.0.0.0/24" href="http://10.0.0.0/24">10.0.0.0/24</a>
bantime  = 600
maxretry = 3
...
[SECTION_NAME]
enabled = true # vérifier que cette valeur est à True, sinon le logiciel n'est pas activé!
...
[ssh]
enabled = true
port	= ssh
filter	= sshd
logpath  = /var/log/auth.log
maxretry = 6

Dans cette configuration:

• Tout ce qui vient du réseau local (10.0.0.0/24) est ignoré. Donc je pourrais me tromper autant de fois que voulu, je ne me ferais pas bannir.
• En dehors de mon réseau local, par ssh, j’ai droit à 6 tentatives (par session) de connexions échouées. Ensuite, je me ferais bannir. Si je m’identifie, la fois suivante, j’ai encore droit à 6 tentative (ça repart à zéro avec l’identification réussie)
• Si je suis banni, toutes mes tentatives de connexions pendant les 600 prochaines secondes (10 minutes) seront refusées, sans possibilité d’identification.

La configuration de fail2ban vous offre plein d’autres possibilité, comme de recevoir des mails en cas de tentatives échouées, d’utilisateurs inconnus, etc. Consultez la documentation pour exploiter cet outils très pratique.

denyhosts

denyhosts permet de faire la même chose, un peu différemment. Il maintient une base d’IP bannies dans /etc/hosts.deny et les compare avec les tentatives de connexions.

Il a quelques avantages sur fail2ban, même si je le trouve plus lent (consommateur) à l’usage:

1. Il permet de bloquer les tentatives d’accès ssh sur l’utilisateur root dès la première tentative.
2. Il permet de paramétrer comme on le veut les champs from et subject des mails envoyés
3. Il permet d’envoyer les rapports vers le syslog, qui peut être distant (et ineffaçable)

Simple à configurer, le fichier /etc/denyhosts.conf est largement commenté

Sur le même sujet:

• http://www.fail2ban.org/wiki/index.php/FAQ_french
• http://doc.ubuntu-fr.org/denyhosts
• http://www.alsacreations.com/tuto/lire/622-Securite-firewall-iptables.html
• http://senseya.free.fr/index.php?tag/fail2ban

(1) Ne pensez pas que je suis assez bête pour utiliser un login simple tel que « manu » sur mes serveurs… C’est juste pour l’exemple.

S’il n’est pas installé par défaut sur votre distribution, installez le de manière classique.

Si vous utilisez rkhunter pour scanner votre machine, sans opération particulière vous aurez deux problèmes:

1. rkhunter n’utilisera pas par défaut unhide, et vous perdrez donc le bénéfice d’un seul scan.
2. rkhunter va détecter un warning sur unhide et unhide-linux26, ce qui vous enverra un mail à chaque détection.

La solution est simple: il suffit d’indiquer à rkhunter que unhide est fiable, en l’ajoutant à sa base de donnée. Ensuite, rkhunter utilisera unhide automatiquement.

ATTENTION: n’utilisez la commande suivante QUE SI VOUS ÊTES SÛR de votre système ! En effet, cette commande va réinitialiser la base de données des programmes considérés comme sûrs par rkhunter. Si vous avez un rootkit ou des programmes cachés, ils ne seront plus détectés!

Il est conseillé de lancer un rkhunter -c et de vérifier le rapport avant de lancer la commande suivante.

Maintenant que vous êtes prévenus, voici la commande magique (en root ou avec sudo):

rkhunter --propupd

C’est tout. La prochaine fois que rkhunter sera lancé, manuellement ou par la programmation, unhide sera détecté et utilisé.

Notez qu’il existe des outils graphiques pour réaliser ces opérations (par exemple seahorse sous Gnome), mais je n’en parlerais pas.

Sur l’ordinateur client (manu-desktop)

La première chose à faire, si vous n’avez pas de clef pour votre machine, est d’en générer une

manu@manu-desktop:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/manu/.ssh/id_rsa):
Created directory '/home/manu/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/manu/.ssh/id_rsa.
Your public key has been saved in /home/manu/.ssh/id_rsa.pub.
The key fingerprint is:
cd:9e:bb:0a:1e:22:29:fa:e3:dc:12:72:8a:15:13:58 manu@manu-desktop
manu@manu-desktop:~$ ls -l ~/.ssh
total 8,0K
3367418 -rw------- 1 manu manu 1,7K 2009-01-15 13:26 id_rsa
3367419 -rw-r--r-- 1 manu manu  399 2009-01-15 13:26 id_rsa.pub
manu@manu-desktop:~$

Ne mettez pas de passphrase et laisser les options par défaut pour la création de la clef. Il est aussi possible de spécifier les options via la ligne de commande:

ssh-keygen -qt rsa -b 1024 -C manu -f ~/.ssh/manu@manu-desktop.rsa -N ""

La commande précédente crée une clef rsa (-t) avec le commentaire (-C) manu d’une longueur de 1024 bits (-b) dans le fichier ~/.ssh/manu@manu-desktop.rsa (-f) avec une passphrase (-N) vide.

Sur le serveur (server)

Le compte utilisateur de connexion doit exister. Il n’est pas obligé que ce soit le même identifiant que sur le client. Par exemple, sur le serveur, mon compte est nommé zephir.

[root@server]:# adduser zephir
Ajout de l'utilisateur « zephir »...
Ajout du nouveau groupe « zephir » (1002)...
Ajout du nouvel utilisateur « zephir » (1002) avec le groupe « zephir »...
Création du répertoire personnel « /home/zephir »...
Copie des fichiers depuis « /etc/skel »...
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l'utilisateur zephir
Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée
Nom complet []:
N° de bureau []:
Téléphone professionnel []:
Téléphone personnel []:
Autre []:
Ces informations sont-elles correctes ? [o/N] o
[root@server]:#

Sur l’ordinateur client (manu-desktop), fin des opérations

Il ne reste plus au client qu’à envoyer sa clef d’identification au serveur simplement par la commande suivante:

ssh-copy-id -i ~/.ssh/id_rsa.pub zephir@server

Acceptez l’identification du serveur, le mot de passe est demandé (puisque vous n’avez pas encore envoyé la clef) et la clef est copiée dans le fichier /home/zephir/.ssh/authorized_keys.
Tentez la commande suivante (Ctrl+D pour sortir)

ssh zephir@server

Vous ne devriez plus avoir de demande de mot de passe.

Sur le serveur, fin des opérations

Il est possible de sécuriser le serveur afin de n’accepter que les authentifications avec clef et sans demande de mot de passe (pour ssh. L’accès en local demandera toujours un mot de passe).
Ainsi, les tentatives d’attaque par force brute sont vouées à l’échec. MAIS, soyez conscient que vous ne pourrez plus vous connecter depuis une autre machine que celle pour laquelle vous avez envoyé la clef, pas plus que vous ne pourrez envoyer d’autres clefs.
Paramétrez le fichier /etc/ssh/sshd_config tel que ci dessous:

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
 
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Relancez ensuite le serveur ssh pour prendre en compte les modifications.

Note sur la sécurité

L’accès au serveur est possible sans authentification par l’utilisateur manu depuis l’ordinateur client (manu-desktop). Si cet ordinateur est un portable et qu’il se fait voler, celui qui arrivera à se connecter avec l’identité de manu arrivera sans demande de mot de passe à se connecter au serveur !
Réfléchissez bien à l’utilisation de ce mode de fonctionnement avant de le mettre en place.
En cas de vol, il suffira de supprimer le fichier /home/zephir/.ssh/authorized_keys pour que la clef volée avec le portable ne soit plus opérationnelle.
Vous pouvez, de même, recréer et changer vos clefs d’identification lorsque vous le voulez en réutilisant les commandes données en début d’article.

Liens:

http://doc.ubuntu-fr.org/gnupg
http://doc.ubuntu-fr.org/ssh