Databases, Systems & Networks

Portier SSH

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 ports repérera le port que vous avez choisi, et des logiciels de scan sont capables 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’authentification 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

(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.

Source: absolacom.com