Je fait suite à mon précédent article sur l’intégration d’un certificat signé par la PKI Micorsoft au sein du serveur Apache.

On va ici effectuer une demande pour le webmail de Zimbra.

le scénario est le suivant :

  • ActiveDirectory 2008 R2 incluant la PKI
  • Un client Windows 2008 R2 intégré au domaine
  • Zimbra v8.0.7 sous CentOS 6.4 avec le paquet zimbra-proxy installé

Tout comme la demande pour Apache, il faut que le paquet OpenSSL soit installé.

On commence par créer la clef privé du serveur :

zimbra# openssl genrsa 2048 > /etc/pki/tls/private/zimbra.domain.tld.key

Puis on génère la requête :

zimbra# openssl req -new -key /etc/pki/tls/private/zimbra.domain.tld.key > /etc/pki/tls/private/zimbra.domain.tld.req
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Country Name (2 letter code) [XX]:FR
 State or Province Name (full name) []:IDF
 Locality Name (eg, city) [Default City]:Paris
 Organization Name (eg, company) [Default Company Ltd]:Les Titans
 Organizational Unit Name (eg, section) []:
 Common Name (eg, your name or your server's hostname) []:zimbra.domain.tld
 Email Address []:admin@domain.tld
Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

Une fois le fichier de requête transféré au serveur Windows, on va demander à la CA de créer un certificat :

windows# certreq -submit -attrib "CertificateTemplate:WebServer" zimbra.domain.tld.req

Zimbra-MPKI-01

a la différence de apache, il est obligatoire de concaténer le root CA avec le certificat du service. Il faut donc récupérer le certificat public de notre ADSC :

windows# certutil -ca.cert c:\users\administrator\Desktop\ca_root.crt

Zimbra-MPKI-02

une fois les deux certificats sur le serveur Zimbra, concaténez les deux via la commande suivante :

cat /etc/pki/tls/certs/zimbra.lab.rezo.local.crt /etc/pki/tls/certs/ca_root.crt > /etc/pki/tls/certs/complete_zimbra.lab.rezo.local.crt

Enfin aller dans l’interface web d’administration de Zimbra et copier-coller le contenu du certificat dans l’onglet configuration -> domaine -> domain.tld > Certificats (colone de gauche) et dans la colonne de droite la clef privé du serveur que nous avons créé auparavant et cliquer sur sauvegarder.

Zimbra-MPKI-03

Comme l’indique le popup, il faut effectuer une commande sur le serveur lui même afin de déployer ce nouveau certificat. Pour cela

mkdir /opt/zimbra/conf/domaincerts <- petit bug de Zimbra qui ne créer pas le repertoire si celui-ci n'existe pas
 chown zimbra:zimbra /opt/zimbra/conf/domaincerts
 /opt/zimbra/libexec/zmdomaincertmgr deploycrts
 su - zimbra
 zmnginxctl restart

enfin connectez-vous sur l’interface web depuis le client :

Zimbra-MPKI-04

et voila un beau webmail reconnu par votre navigateur

Monitoring Web

Dans Zabbix il est possible d’effectuer des checks de services web. Mais une problématique se pose quand ceux-ci se situe derrière un proxy. En effet, dans les versions antérieurs à la 2.2 il n’est pas possible de configurer dans l’interface web le serveur proxy.

Il faut donc passer par le système d’exploitation pour effectuer l’opération. La documentation de Zabbix est clair sur le comment, mais après moult essais, je n’ai pas réussi à le faire fonctionner correctement. Je livre donc ici une méthodologie qui m’est fonctionnel.

Configuration du système

Pour faire les choses propres, on va créer un fichier de configuration qui exportera les variables systèmes et qui sera lu au lancement du serveur.

On créer donc le fichier de configuration suivant : /etc/sysconfig/zabbix (Red Hat like) en y mettant le contenu suivant :

export http_proxy=http://PROXY_USER:PROXY_USER_PASSWORD@PROXY_IP:PROXY_PORT
export https_proxy=$http_proxy
export ftp_proxy=$http_proxy
#Upper Case
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$http_proxy
export FTP_PROXY=$http_proxy
# Exclusions Proxy
export no_proxy="127.0.0.1,HOST_TO_Exclude,DOMAIN_TO_Exclude"
export NO_PROXY=$no_proxy

puis on modifie le script de lancement du serveur afin d’y ajouter notre fichier de configuration. Celui-ci sera lu au lancement par l’utilisateur système zabbix (ici zabbixsrv), ce qui permettra aux checks de pouvoir sortir via le proxy.

Modifiez le fichier /etc/init.d/zabbix-server afin d’y ajouter ces deux lignes :

...
# Source function library.
 . /etc/rc.d/init.d/functions
# Source sysconfig
 . /etc/sysconfig/zabbix
exec=zabbix_server
 prog=${exec##*/}
 ...

Puis redémarrer le serveur Zabbix :

/etc/init.d/zabbix-server restart

Si vous avez bien suivi, le fichier est lu au démarrage de Zabbix, cela veux dire que si vous voulez ajouter des exclusions, il faut redémarrer le serveur Zabbix.

Vivement mon passage en 2.2 🙂

Merci a l’utilisateur BDiE8VNy qui a donné la solution sur le forum Zabbix

Un des problèmes que l’on rencontre souvent lors de l’installation de Zimbra sur un hôte, c’est qu’il ne faut pas installer le MTA de l’OS. En effet Zimbra en livre un par défaut (postfix). Du coup les mails systèmes ne sont pas transmis car ils n’utilisent aucun client. Pour que cela fonctionne, il suffi simplement de configurer le système d’exploitation pour qu’il utilise le postfix de Zimbra :

Dans un premier temps, on ajoute le postfix de Zimbra danes les alternatives pour le service « mta »

/usr/sbin/alternatives --install /usr/sbin/sendmail mta /opt/zimbra/postfix/sbin/sendmail 25 \
--slave /usr/bin/mailq mta-mailq /opt/zimbra/postfix/sbin/mailq \
--slave /usr/bin/newaliases mta-newaliases /opt/zimbra/postfix/sbin/newaliases \
--slave /usr/share/man/man1/mailq.1.gz mta-mailqman /opt/zimbra/postfix/man/man1/mailq.1 \
--slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /opt/zimbra/postfix/man/man1/newaliases.1 \
--slave /usr/share/man/man8/sendmail.8.gz mta-sendmailman /opt/zimbra/postfix/man/man1/sendmail.1 \
--slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /opt/zimbra/postfix/share/man/man5/aliases.5 \
--initscript zimbra

Puis on configure le système pour qu’il l’utilise en choisissant notre option (ici la 2) :

/usr/sbin/alternatives --config mta
There are 2 programs which provide 'mta'.
Selection Command
-----------------------------------------------
*+ 1 /usr/sbin/sendmail.postfix
2 /opt/zimbra/postfix/sbin/sendmail

Et si l’on souhaite vérifier :

update-alternatives --display mta
mta - status is manual.
link currently points to /opt/zimbra/postfix/sbin/sendmail
/usr/sbin/sendmail.postfix - priority 30
slave mta-pam: /etc/pam.d/smtp.postfix
slave mta-mailq: /usr/bin/mailq.postfix
slave mta-newaliases: /usr/bin/newaliases.postfix
slave mta-rmail: /usr/bin/rmail.postfix
slave mta-sendmail: /usr/lib/sendmail.postfix
slave mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz
slave mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz
slave mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz
slave mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz
/opt/zimbra/postfix/sbin/sendmail - priority 25
slave mta-pam: (null)
slave mta-mailq: /opt/zimbra/postfix/sbin/mailq
slave mta-newaliases: /opt/zimbra/postfix/sbin/newaliases
slave mta-rmail: (null)
slave mta-sendmail: (null)
slave mta-mailqman: /opt/zimbra/postfix/man/man1/mailq.1
slave mta-newaliasesman: /opt/zimbra/postfix/man/man1/newaliases.1
slave mta-aliasesman: /opt/zimbra/postfix/share/man/man5/aliases.5
slave mta-sendmailman: /opt/zimbra/postfix/man/man1/sendmail.1
Current `best' version is /usr/sbin/sendmail.postfix.

Introduction

Vous avez sans doute eu le souci lors de l’utilisation d’un reverse proxy pour desservir des machines web type Apache. Dans les logs des backend, l’adresse IP retourné est celle du reverse proxy; logique puisque c’est lui qui effectue les requêtes. Cela peut être gênant si vous voulez lever des statistiques sur vos visiteurs.

Pour que le backend traite les trames les frontend ajoute dans les headers l’occurrence X-Forwarded-For. Voici comment cela se présente :

X-Forwarded-For: client, proxy1, proxy2

En premier lieu on l’adresse ip d’origine (celle du client) puis le ou les proxy par lesquels la demande est passée.

Nginx

Pour configurer cela sous NGINX, il faut d’abord vérifier que votre version de NGINX a été compilé avec. Pour cela :

nginx -V

piuis vérifier que l’occurrence suivante apparait bien dans la ligne des compilations :

--with-http_realip_module

si cela est présent vous n’avez simplement qu’a rajouter dans votre virtualhost ces deux lignes :

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Coté backend il faut maintenant prendre en compte ces headers pour cela sur

CentOS

On installe le module mod_extract_forwarded disponible dans les repository EPEL puis :

yum install mod_extract_forwarded

Une fois le module installé, il faut le configurer pour accepter les headers de la part de certains proxy (un peu de sécurité que diable !).

Pour cela éditer le fichier /etc/httpd/conf.d/mod_extract_forwarded.conf et ajouter la ligne suivante :

MEFaccept reverse_proxy_IP
MEFaccept reverse_proxy_IP2

Puis on redémarre apache

service httpd restart

On vérifie que le module est bien chargé :

apachectl -M | grep frowarded

et normalement dans vos logs ça roulera.

Debian

Même topo que pour CentOS, a la différence que c’est le module rpaf que l’on installe :

apt-get install libapache2-mod-rpaf

Puis on modifie le fichier /etc/apache2/mods-enabled/rpaf.conf pour ajouter l’IP du reverse proxy

Pourquoi ?

Effectivement, pourquoi installer un proxy IMAP/POP plutot que de laisser le serveur de messagerie faire son travail. Plusieurs points (ceci peut être purement subjectif) :

  • Assurer une zone d’étanchéité entre les utilisateurs provenant de l’externe et le serveur de messagerie IMAP situé en interne
  • Faire de la répartition de charge sur X backend
  • Assurer une migration sur différent service
  • etc.

Mon besoin personnel est la création d’une zone DMZ dans mon infrastructure, je ne voulais donc pas que les utilisateurs parviennent directement sur mon serveur de messagerie. Mais je me sert aussi de cette solution pour assurer des migrations de messagerie.

Je suis parti sur une installation sur Centos, mais le principe reste le même sur Debian-like.

Installation sur Centos-6

Tout d’abord on créer un fichier de configuration de yum, ainsi nous pourrons installer le proxy plus simplement que par la compilation. Le repository le plus a jour que j’ai trouvé est celui d’OpenSuse, les paquets datant du 30 Septembre 2012.

vim /etc/yum.repos.d/perdition.repo
[perdition]
 name=perdition repo
 baseurl=http://download.opensuse.org/repositories/home:/horms:/perdition/CentOS_CentOS-6/
 gpgcheck=0
 enabled=1

Puis on installe l’application :

yum install perdition

si vous souhaitez utiliser le backend LDAP (ou autre) il suffit d’installer la librairie correspondante. Dans mon cas je vais faire des interrogations LDAP afin de dire a Perdition sur quel backend aller se connecter.

yum install libperditiondb_ldap0.x86_64

Fichiers de configuration de Perdition

Explications des fichiers de configuration se trouve dans /etc/perdition/

Makefile  Makefile.popmap  perdition.conf  popmap  popmap.re

Le fichier popmap est un fichier a plat qui pourrai s’apparenter au aliases de Postfix avec une syntaxe de type user:destination

Il en va de même pour le fichier popmap.re qui lui prend en charge les expressions régulières.

Le fichier Makefile est un lien symbolique vers Makefile.popmap

Le fichier Makefile.popmap sert a générer le fichier db a partir du fichier popmap pour cela il suffit de faire la commande make all. Celle-ci va générer le fichier popmap.gdbm.db qui sera a intégrer dans la configuration de perdition. Pour plus d’informations je vous recommande le site de perdition ici

Enfin le fichier perdition.conf pour toute la configuration du logiciel. C’est ce que je vais détailler ci dessous. Cette configuration fonctionne en mode LDAP et n’utilisera pas le fichier map.

Configuration de perdition

Tout d’abord on va activer/desactiver les services qui ne nous interesse pas. Pour mon compte, je ne vais juste activer que l’IMAPS. Pour cela, il faut éditer le fichier /etc/sysconfig/perdition et modifier les occurrence pour correspondre a notre besoin :

RUN_PERDITION=yes
 POP3=no
 POP3_FLAGS=
 POP3S=no
 POP3S_FLAGS=
 IMAP4=no
 IMAP4_FLAGS=
 IMAP4S=yes
 IMAP4S_FLAGS=
 MANAGESIEVE=no
 MANAGESIEVE_FLAGS=

ET maintenant on va éditer le fichier perdition.conf afin de correspondre a notre besoin.

On commence par une copie de sauvegarde

cp /etc/perdition/perdition.conf  /etc/perdition/perdition.conf.bak

puis on édite le fichier. Voici la configuration que j’ai mis en place pour mon système

 no_bind_banner
 bind_address 192.x.x.x
 imap_capability IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR COMPRESS=DEFLATE
 no_lookup
 server_resp_line
 ssl_cert_file /path/to/certificate.cert
 ssl_cert_verify_depth 9
 ssl_key_file /path/to/certificate.key
 ssl_no_cert_verify
 ssl_no_cn_verify
 M /usr/lib64/libperditiondb_ldap.so.0
 m "3:ldap://zimbra-ldap.domain.tld/?zimbraMailDeliveryAddress,zimbraMailHost?sub?(&(objectClass=zimbraAccount)(zimbraMailDeliveryAddress=%25s))?!BINDNAME=uid=zmpostfix%2ccn=appaccts%2ccn=zimbra,X-BINDPW=mypassword"

Explications des options :

no_bind_banner : On résoud l’adresse stipulé dans l’option « bind_address »
bind_address : adresse d’écoute du service
imap_capability : Capacité IMAP présenté aux clients se connectant à Perdition
no_lookup : On ne fait pas de lookup sur le serveur
server_resp_line : plutôt que de générer un message de bienvenue lors de la connexion, on affiche le message du backend
ssl_cert_file : chemin vers le certificat
ssl_cert_verify_depth : Profondeur de vérification du certificat
ssl_key_file : chemin vers la clef du certificat
ssl_no_cert_verify : On ne vérifie pas la cryptographie inclus dans le certificat du backend
ssl_no_cn_verify : On ne vérifie pas le nom inclus dans le CN du certificat du backend
M : libairie utilisé pour rechercher le backend
m : recherche LDAP utilisé avec les options ci-dessous :

  • 3 : version de protocole a utiliser
  • ldap://zimbra-ldap.domain.tld : adresse du serveur LDAP
  • zimbraMailDeliveryAddress,zimbraMailHost : attribut de retour
  • sub : scope de la recherche LDAP
  • (&(objectClass=zimbraAccount)(zimbraMailDeliveryAddress=%25s)) : la recherche envoyé au serveur LDAP
  • !BINDNAME=uid=zmpostfix%2ccn=appaccts%2ccn=zimbra,X-BINDPW=mypassword : pour le LDAP de Zimbra il faut se binder

Une fois le fichier enregistré, on place le service au démarrage du système puis on le démarre :

chkconfig perdition on
service perdition start

Test

Faisons un test avec l’utilitaire fournit par Openssl

openssl s_client -connect 127.0.0.1:993
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=PLAIN SASL-IR COMPRESS=DEFLATE] perdition ready on imap.domain.tld 0002eec5
A login login@domain.tld password
A OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN completed

Et voila un proxy IMAP/POP qui ronronne !