[ Administration des systèmes et réseaux | sécurité informatique ]
Après la faille OpenSSL chez Debian, la faille OpenSSH chez RedHat.
Un message sur la liste d’annonce CentOS relate une intrusion sur les serveurs RedHat. Cette intrusion a conduit au remplacement du paquet OpenSSH. Aucun détail sur la manière dont les pirates ont pénétrés les serveurs RedHat ni sur les “features” de leur openSSH modifié. Le communiqué sur le site de RedHat est extrêmement laconique.
Le RHN c’est cher mais c’est sécurisé : c’est en HTTPS.
Un message est passé sur la liste debian-security il y a peu de temps pour demander comment réagir d’un point de vue aussi bien administratif que technique aux scans / bruteforces / attaques par dictionnaires sur OpenSSH. Une floppée de réponses lui ont donné les méthodes de base :
- Changer le port par défaut
- Utiliser un système de port knocking
- Utiliser authentification par clés
- Utiliser des systèmes assimilés aux HIPS [1] (type fail2ban)
Ce dernier point me gêne un peu. L’aspect “réactif” des HIPS est à double tranchant. Si les éléments sur lesquels se basent ces outils sont falsifiés alors on s’expose à des problèmes type DoS. Les outils type fail2ban utilisent les logs du système. Ces logs sont le plus souvent gérés par syslog. Or syslog n’intègre aucun mécanisme de sécurité. Tout les logs envoyés au démon syslogd sont traités pour peu que celui ci écoute sur le réseau. Après si on connait les patterns recherchés, on peut très bien déclencher une action en forgeant un paquet conforme au pattern attendu. Sur un pare-feu normalement syslogd est utilisé uniquement en local.
La on arrive à une situation un peu paradoxale. Pour que l’utilisation de fail2ban soit securisée, il faut installer fail2ban sur la machine et traiter les logs locaux à la machines. Si on superpose avec une architecture de détection d’intrusions [2] ça revient à placer la sonde et le manager ainsi que la base d’alerte sur la machine à protéger. D’un point de vue architecturale cela me gène un peu. La faiblesse du système de collecte empêche la distribution de l’architecture.
Une alternative peut être de se baser sur les statistiques de connexions vers le port SSH. Je l’ai fait avec PF sous OpenBSD dans ce billet.
Notes :
[1] Les HIPS (Host Intrusion Prevention System) sont des logiciels dont le but est de relever des tentatives d’intrusions et de déclancher une action en fonction de l’alerte levée.
[2] Un système classique de détection d’intrusions est composé de trois éléments :
- Une sonde qui collecte les évènements
- Un moteur de stockage qui stock les alertes
- Un manager qui traite les alertes
Un petit post sur un truc un peu rétro mais au combien pratique : autofs.
J’ai constaté un truc qui revient souvent sur le net : l’utilisation des caractères jocker pour les montages de répertoires utilisateurs.
Je pense que c’est le mal.
En fait je faisais ça avant et c’est vrai que c’est assez pratique mais lorsqu’une machine demande un montage d’un fichier issu d’un répertoire utilisateur qui n’existe plus c’est le drame.
Ne riez pas, il y a vraiment des gens qui utilisent un compte utilisateur “env_default” pour y spécifier leurs paramètres par défaut (bashrc, profile etc.). En plus pour bien faire, ce compte n’est pas verrouillé et le mot de passe associé est “env_default” (et la quand on sort tout frais moulu d’une formation de sécurité informatique on tombe de haut !). Ainsi lorsque toto ouvre sa session le répertoire env_default est aussi monté car les fichiers du compte toto incluent ceux de env_default. Et ça produit plein de trucs dégueulasses dans les logs …
Aussi j’ai avantageusement remplacé les autofs avec caractère jocker par mon LDAP. En effet, on peut stocker les maps automount dans un LDAP. Ainsi j’ai de jolis logs et il faut juste penser à créer la map de l’utilisateur au moment de la création du compte. Comment faire ? Simple :
Coté client :
[root@machine_de_toto ~]# apt-get install autofs-ldap
[root@machine_de_toto ~]# vi /etc/nsswitch.conf
... automount: files ldap ...
Hop, votre client est maintenant conscient qu’il doit aller chercher ses maps sur un serveur LDAP.
Pour les puristes, on peut aussi spécifier le rdn de l’endroit ou se trouvent les maps mais je ne suis pas un puriste (grouik, grouik) !
Coté serveur LDAP :
On commence par créer l’arborescence pour autofs-ldap, ensuite il suffit d’ajouter les répertoires à auto-monter au moment de la création du compte.
1. Le /etc/auto.master :
Créons le ldif suivant :
ou=auto.master,ou=linux,o=autofs,dc=example,dc=domain,dc=org ou: auto.master objectClass: top objectClass: automountMap
Je crée VOLONTAIREMENT une arborescence pour Linux car MacOS utilise un format différent pour stocker ses auto-montages dans un LDAP. Après investigations il se trouve que MacOS emploi le format autofs5 intégré dans leur Active Directo oups ! Open Directory. On ne peut pas rétrograder en autofs4. On ne peut pas non plus integrer la partie autofs de Open Directory dans les schémas LDAP car des objets ont le même nom (mais pas la même définition). Bref pour ceux qui en doutaient encore MacOS X à part faciliter mon transit ça fait pas grand chose.
On crée l’entrée pour la racine des répertoires utilisateurs :
cn=/home/users,ou=auto.master,ou=linux,o=autofs,dc=example,dc=domain,dc=org objectClass: automount cn: /home/users automountInformation: ldap:ou=auto.home,ou=linux,o=autofs,dc=example,dc=domain,dc=org
Rien de bien nouveau sous le soleil sauf peut être pour la partie automountInformation. Cette partie peut inclure le nom du serveur LDAP ou aller chercher les montages. A mon avis c’est une connerie : si jamais vous ajoutez en dur un serveur LDAP, il faudra modifier votre enregistrement si vous ajoutez des replicas de secours. Il vaut mieux laisser autofs-ldap utiliser le ldap.conf du client.
Enfin l’OU qui va contenir nos montages utilisateurs :
dn: ou=auto.home,ou=linux,o=autofs,dc=example,dc=domain,dc=org ou: auto.home objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit
2. Utilisateur final :
On a plus qu’a créer l’entrée dans l’OU auto.home.
cn=toto,ou=auto.home,ou=linux,o=autofs,dc=example,dc=domain,dc=org objectClass: automount automountInformation: -rw,hard,intr,nosuid filer:/home/users/toto cn: toto
And … Voila !!
Mon dieu que j’aimerais avoir un kerberos pour pouvoir passer en NFSv4 …
Heureux les administrateurs qui ne mettent jamais à jour leur système. Sans sombrer dans le syndrome “cutting edge” à outrance j’essaie de maintenir les machines que j’administre ainsi que ma machine personnelle à jour niveau sécurité. Cependant il y a des fois où ce type de discipline est difficile à assumer. J’ai donc passé le présent serveur en FreeBSD 7.0 et j’ai pleuré. Revue de détail :
Phase 1 : Mise à jour du système de base
J’ai suivi la méthode d’un upgrade binaire décrite [ici]. Pour le système de base ça a très bien marché. En revanche ça a tout pété les ports.
Phase 2 : Recompilation des ports
A l’issu de l’upgrade du système de base j’obtiens :
[garnett@silky ~]$ uname -a
FreeBSD silky.garnett.fr 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Wed Jun 18 07:33:20 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
Je me dis c’est OK, passons à la réinstallation des ports :
[garnett@silky ~]$ sudo portupgrade -afP
Et la c’est le drame : plus rien ne marche. J’ai des erreurs de librairies non trouvées par divers applications (Apache22, vim, php etc.). Gênant d’autant plus que je venais de réinstaller mes ports avec les nouvelles librairies du système de base … En lisant le fichier de sortie du portupgrade, je me rends compte qu’il a recompilé un bon paquet des ports (le -P veut dire que lorsqu’un package est disponible pour un port, on utilise l’utilise plutôt que de tout compiler).
Bon, OK, ne faisons donc pas les choses à moitié et plutôt que d’avoir un truc un peu bâtard (ports et packages) recompilons tout :
[garnett@silky ~]$ sudo portupgrade -af
…
Ça mouline, ça mouline 
…
Confiant je tente un vim sur un fichier quelconque.
Paf encore une librairie introuvable … Merde !
Hop lancement de msn : chouette Arno est rentré de vacances. Après les politesses d’usage je lui demande si il a une idée et là il me dit qu’après chaque upgrade majeur de version il vaut mieux supprimer les ports et les réinstaller (méthode d’autant plus propre que certains logiciels disponibles sous forme de ports sont intégrés à cette occasion au système de base, par exemple ftp-proxy).
Sans autre forme de procès :
[garnett@silky ~]$ sudo pkg_delete -a
[garnett@silky ~]$ sudo portinstall databases/mysql51-server
[garnett@silky ~]$ sudo portinstall www/apache22
…
Et la effectivement tout a fonctionné à merveille.
Une fois de plus : merci Arno !!
Moralité pour les upgardes mineurs ca passe en live. Par contre pour le prochain majeur je mettrais la machine offline et je stopperais les services pour réaliser ces manipulations.