J’utilise un serveur de messagerie nommé Mdaemon. Ce type de serveur possède un client à installer sur le poste de l’utilisateur permettant d’être notifié lorsqu’un nouveau mail est reçu, de se connecter au webmail sans taper de mot de passe…

Bref, mon problème est que j’ai l’impression que quelqu’un l’a installé chez lui sur un poste infecté car la boite à laquelle il se connecte spam énormément et risque de nous blacklister.

En visualisant les logs de mon reverse proxy Vulture,  j’ai remarqué que les UserAgents utilisés par ce logiciel sont  "ComAgentWCIM" et “WCInterface”.

Avec Vulture, nous avons la possibilité d’utiliser le mod_security sur les applications de notre choix. Cela va me permettre d’ajouter une règle permettant de bloquer les UserAgents qui me concernent.

Règles utilisées :

Voici les règles que j’ai mis en place pour mon webmail :

SecRule REQUEST_HEADERS:User-Agent ".*ComAgent.*" "t:none,msg:’ComAgent Identifie’"
SecRule REQUEST_HEADERS:User-Agent ".*WCInterface.*" "t:none,msg:’WCInterface identifie’"

Explication :

SecRule : Déclare une règle de sécurité

REQUEST_HEADERS:User-Agent : Filtrer le User-agent du client web

".*ComAgent.*" : Le User-Agent contiendra ComAgent

“t:none” : Indique que toutes les translations ne effectuées avant cette règle ne seront pas appliquées. Une translation permet de remplacer une chaine par une autre par exemple.

“msg:” : Inscrit un message personnalisé dans les logs

Après avoir appliqué cette règle à l’application, il ne faut pas oublier de redémarrer l’interface de Vulture qui a été touchée.

Après avoir ajouté des interfaces à mes serveurs Vulture pour prendre en charge mes certificats SSL par domaine, j’ai du mettre à jour mes scripts de synchronisation et de supervision. Pour rappel, la première version ainsi qu’une doc explicative se trouve à cette adresse : http://www.croc-informatique.fr/2009/07/synchronisation-et-monitoring-de-deux-reverse-proxy-vulture/

J’en ai profité pour remanier un peu mon code pour qu’il soit plus exploitable par tous. J’espère que ça servira à quelqu’un.

Attention :

J’ai transformé le script permettant la supervision de la synchronisation du shell en perl. Donc, à présent, il faut mettre dans le fichier /etc/sudoers la ligne :

nagios   ALL = NOPASSWD: /usr/bin/perl /usr/lib/nagios/plugins/check_synchro_vulture.pl

Au lieu de :

nagios   ALL = NOPASSWD: /bin/sh /usr/local/nagios/libexec/check_synchro_vulture.sh

Modifier également la commande utilisé par Nagios.

La supervision des sites Web hébergés a également changée. La commande s’exécute de cette manière :

./check_vulture.pl -H 192.168.0.1

Il vous faudra modifier les constantes dans la plupart des scripts.

Vous pouvez télécharger la dernière version ici

Mot de passe de l’archive : http://www.croc-informatique.fr

Nous allons configurer openldap pour s’assurer que l’authentification et les informations ne circulent pas en claires. Pour cela, nous allons devoir générer un certificat serveur à l’aide d’openssl, indiquer au serveurs Ldap d’utiliser ces certificats et enfin lui demander d’écouter sur un nouveau port pour les connexions sécurisées.

Pré-requis :

• OpenLdap installé et configuré
• Openssl doit être installé

Génération du certificat serveur :

Créer l’arborescence qui contiendra les certificats que nous allons générer :

mkdir –p /etc/ssl /etc/ssl/openldap

cd /etc/ssl/openldap

Générer le certificat :

openssl req -x509 -new -config openssl-ldap.cnf -out ldap_cert.pem -keyout ldap_key.pem -days 730 –nodes

Vous devez répondre aux questions. Celles-ci permettent à l’utilisateurs de connaître la provenance du certificat.

Deux fichiers vont être générés : ldap_cert.pem et ldap_key.pem

Mettez leurs les droits 440 propriétaire root groupe ldap

Configuration d’OpenLdap

Editez le fichier /etc/openldap/slapd.conf et ajoutez :

TLSCertificateFile /etc/ssl/openldap/ldap_cert.pem
TLSCertificateKeyFile /etc/ssl/openldap/ldap_key.pem

Ces lignes permettent de spécifier l’emplacement du certificat et de sa clé au serveur OpenLdap.

Editez le fichier /etc/openldap/ldap.conf Pour qu’il ressemble à cela :

URI     ldaps://192.168.0.1:636
TLS_CACERTDIR /etc/ssl/openldap/

Le serveur ldap écoutera sur le port 636 au redémarrage du service ldap.

Vous pouvez tenter une connexion avec JXplorer :

Afin de faire du chroot, il est nécessaire de mettre à jour open-ssh en v5 ou v4.8 minimum.

Voici la procédure permettant de faire la mise à jour :

Installer les outils de développement si ce n’est pas déjà fait :

yum install gcc

yum install openssl-devel

yum install pam-devel

yum install rpm-build

Télécharger openssh 5.2p1

wget ftp://mirror.planetunix.net/pub/OpenBSD/OpenSSH/portable/openssh-5.2p1.tar.gz

Génération des fichiers RPM

Maintenant, nous allons créé le RPM à partir du fichier tar.gz :

tar xvfz openssh-5.2p1.tar.gz

cp ./openssh-5.2p1/contrib/redhat/openssh.spec /usr/src/redhat/SPECS/

cp  ./openssh-5.2p1.tar.gz /usr/src/redhat/SOURCES/

cd /usr/src/redhat/SPECS/

perl -i.bak -pe 's/^(%define no_(gnome|x11)_askpass)\s+0$/$1 1/' openssh.spec

rpmbuild -bb openssh.spec

Liste des fichiers rpm générés :

cd /usr/src/redhat/RPMS/`uname -i` ls -l       
total 988 

-rw-r--r-- 1 root root 272540 nov  2 15:55 openssh-5.2p1-1.i386.rpm          
-rw-r--r-- 1 root root 431980 nov  2 15:55 openssh-clients-5.2p1-1.i386.rpm         
-rw-r--r-- 1 root root  16712 nov  2 15:55 openssh-debuginfo-5.2p1-1.i386.rpm         
-rw-r--r-- 1 root root 269432 nov  2 15:55 openssh-server-5.2p1-1.i386.rpm

Mettre à jour open-ssh :

rpm -Uvh openssh*rpm

Preparing... ################################

1: openssh ####

2: openssh-clients ####

3: openssh-server ####

Redémarrer SSH

service sshd restart

Vérification :

# rpm -qa | grep openssh
openssh-5.2p1-1
openssh-server-5.2p1-1
openssh-debuginfo-5.2p1-1
openssh-clients-5.2p1-1