Le serveur OpenSSH se configure via le fichier
/etc/ssh/sshd_config. Même si la configuration par défaut
sour Ubuntu serveur est plutôt bonne, quelques ajustements peuvent améliorer
la sécurité du service.
Le serveur ssh écoute par défaut sur le port
22/tcp. Laisser ce port ouvert à n'importe qui
peut sembler anodin, puisqu'il qu'une authentification est requise. Mais c'est
en fait un risque qui n'a rien de négligeable.
Tout d'abord, le risque est d'être victime d'attaque de force brute. Dans ce cas, le serveur est assailli de tentatives de connexion ssh avec des identifiants/mot de passe tirés de dictionnaire de mots ou générés aléatoirement. En choisissant des mots de passe décents, il y a peu de risque. C'est tout de même ennuyeux puisque cela consomme des ressources que l'on voudrait allouer ailleurs (CPU, remplissage des logs). Mais le risque principal est plutôt de se retrouver sous le coup d'un exploit zéro-day : une faille inconnue du public (et des développeurs d'OpenSSH) qui serait exploitée par des attaquants. Si l'on considère le fait que les attaquants se constituent des bases de données service/version à l'avance grâce à des scans massifs, l'apparition d'un tel 0-day peut potentiellement compromettre le serveur instantanément.
Plusieurs possibilités existent afind de mettre le port 22 à l'abri. Comme d'habitude, ces techniques ont leur avantages et leurs inconvénients, certaines sont meilleures que d'autres et il faudra choisir la plus adaptée en fonction de la situation et de l'appréciation du risque. Il est tout à fait possible de combiner ces solutions entre-elles : changer le port d'écoute, le protéger par un port knocker qui filtrera les paquets reçus pour n'accepter que quelques blocks d'IP spécifiques, etc...
Il faut cependant noter que plus de sécurité n'est pas forcément une meilleure sécurité, et que mettre en place une usine complexe juste pourt défendre l'accès à un port peut conduire à des erreurs ou une incompréhension du système final qui vont au contraire desservir la sécurité. Il faut garder à l'esprit que le seul garant de la sécurité est OpenSSH lui même que et la qualité de sa configuration et le suivi de ses éventuels problèmes de sécurité seront toujours cruciaux.
Il faut donc considérer ces mesures uniquement pour ce qu'elles sont : éliminer l'accès au port pour éliminer les 99.99% des accès frauduleux (brute force, fingerprinting, script kiddies, ...). Le danger réside évidemment dans les 0.01% restants et là, seul OpenSSH lui-même (et sa configuration) feront la différence.
Un des moyens les plus simples consiste à filtrer l'accès au port pour ne laisser passer que des IP ayant le « droit » d'utiliser le service.
Avantages : très simple à mettre œuvre par la configuration de règles IPtables (Section 2.4.3, « Filtrage de base ») :
# # ###################################### # TCP entrant # Il faudra ouvrir des ports au fil de l'eau # lors de la mise en place de # services TCP (ssh, apache, ...). # ###################################### # -A TCP_IN -j TCP_INLIMITS -A TCP_IN -j STATEFUL -A TCP_IN -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m limit --limit 10/min -j LOG --log-prefix "TCP_IN:" --log-level 6 -A TCP_IN -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j DROP # Ajouter les rêgles ici lors de l'installation de services TCP si ces services # doivent être ouverts # -A TCP_IN -s adresse_ip_autorisée -p tcp -m tcp --dport 22 -j ACCEPT ❶ #
| ❶ | Régle autorisant l'accès au port 22/tcp (ssh) pour l'adresse adresse_ip_autorisée |
Inconvénients : il n'est pas toujours possible (client en DHCP, ...) ou suffisant (client NATé) de restreindre l'accès au port ssh par IP. Par ailleurs, une adresse IP peut être « spoofée » par un attaquant qui aurait réussi à déterminer la relation de confiance serveur/adresse_ip_autorisée.
Il est possible de changer le port d'écoute
(22/tcp) vers l'un de n'importe que autre des
65535 ports possibles (sshd refuse d'utiliser le port 0, pourtant valide).
Avantages : très simple à mettre œuvre (il suffit de changer le paramètre
Port dans le fichier de configuration).
Inconvénients : cette mesure suffit contre les attaques automatisées basiques,
mais est largement insuffisante contre les scans. Rien n'interdit à un
attaquant de scanner les autres ports de la machine et de retrouver le serveur
sshd grâce au banner fingerprinting.
nmap est tout à fait capable de reconnaître ssh sur un port
différent du port standard.
Il est donc souhaitable d'utiliser d'autres techniques de protection du port si possible.
Les portknockers permettent de n'ouvrir un port donné que lorsqu'une séquence
particulière de paquets vient d'être reçue. Par exemple, un portknocker peut
être configuré pour ouvrir le port 22 lorsqu'il a auparavant reçu un paquets
TCP syn sur le port 33333 suivi d'un paquet UDP sur le port 1234.
Il faudra donc connaître la séquence de paquets à envoyer, le
« sésame » afin que l'accès au port soit permis (typiquement grâce à
une règle iptables ressemblant à
iptables -I INPUT -p tcp -s ip_ayant_correctement_carilloné
--dport 22 -j ACCEPT. Des outils comme
knockd, voire même quelques règles
iptables
sont capables de fournir ce service.
Cette idée peut sembler astucieuse à première vue, mais souffre d'un problème plutôt ennuyeux : le portknocking « de base » est vulnérable aux attaques par rejeu : une personne mal intentionnée peut, si elle se trouve au milieu de la conversation, capturer de trafic et le rejouer afin d'ouvrir le port ssh. Des techniques plus pointues ont donc été mises en avant afin de contrer le rejeu : séquence de ports construite à partir d'un cryptogramme contenant l'IP source et le port à débloquer (http://www.portknocking.org/view/details), SPA, (Single Packet Authorization), ... Ces implémentations, beaucoup plus intéressantes, souffrent quand à elles d'un autre défault : leur mise en place nécessite de déployer un dæmon supplémentaire sur le système. Et mettre en place un dæmon en plus c'est s'exposer à de nouveaux problèmes introduits par ce dernier, c'est un service de plus à maintenir, à monitorer, à upgrader, pour lequel il faudra suivre les évolutions et les informations liés à la sécurité...
Chacun décidera en fonction de ses besoins si le jeu en vaut la chandelle. Mais il faut donc bien prendre le port knocking comme ce qu'il est : une méthode simple, mais pas infaillible, de masquer la présence d'un serveur ssh. Point.
oper@ubuntu:~$ sudo apt-get install knockd
Password:
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Reading state information... Fait
Les NOUVEAUX paquets suivants seront installés :
knockd
0 mis à jour, 1 nouvellement installés, 0 à enlever et 4 non mis à jour.
Il est nécessaire de prendre 25,1ko dans les archives.
Après dépaquetage, 172ko d'espace disque supplémentaires seront utilisés.
Réception de : 1 http://fr.archive.ubuntu.com feisty/universe knockd 0.5-2ubuntu1 [25,1kB]
25,1ko réceptionnés en 5s (4218o/s)
Sélection du paquet knockd précédemment désélectionné.
(Lecture de la base de données... 14236 fichiers et répertoires déjà installés.)
Dépaquetage de knockd (à partir de .../knockd_0.5-2ubuntu1_i386.deb) ...
Paramétrage de knockd (0.5-2ubuntu1) ...
Not starting knockd. To enable it edit /etc/default/knockd
oper@ubuntu:~$
Afin de limiter les effets d'une attaque par force brute, il est préférable de
n'autoriser que l'authentification par clef publique.
Pour cela, il faut configurer
PasswordAuthentication à la valeur
no dans le fichier de configuration.
Il est conseillé d'avoir mis en place l'authentification par clef publique
(voir Section 3.4, « Authentification par clef publique ») avant de n'autoriser
que celle-ci...
Il est aussi conseillé de mettre
PermitRootLogin
à without-password. Cela n'apporte rien si
PasswordAuthentication est à la valeur
recommandée, s'avère utile dans le cas contraire en forcant les connexions
« as root » a s'authentifier sans mot de passe.
Si le proxying de connexions ssh et le transfert de sessions X-Window n'est pas
requis (ce qui est généralement le cas dans la mesure ou les serveurs n'ont
pas de librairies X installées), il est recommandé de passer les valeurs
AllowTcpForwarding et
X11Forwarding à
no
Enfin, même si IPv6 a été désactivé sur la machine, il est conseillé de mettre
AddressFamily à inet,
ce qui force le dæmon sshd à n'utiliser qu'IPv4. L'interêt est
double : c'est un sécurité en cas d'erreur de désactivation d'IPv6
(voir Section 2.3.2.2, « Désactiver IPv6 »), mais cela permet aussi de ne pas remplir les logs avec
des messages du kernel tentant de charger le module ipv6
alors qu'il est blacklisté.
Les autres paramètres pas défaut sous Ubuntu serveur 7.04 sont corrects. Une fois ces paramètres appliqués, il faut redémarrer le serveur pour qu'ils soient pris en compte.