Cela faisait un moment que je devais tester cette distribution. Xavier en est un fidèle utilisateur. Une mise à jour qui se passe mal sur mon ancien système… et me voilà donc parti à télécharger la dernière version de LinuxMint afin de faire le grand saut.
Verdict après l’installation : Bluffant. Certes, une des nouvelles fonctionnalités est le support amélioré des systèmes à double écrans par Gnome, mais je crois bien que c’est la première fois que tout s’installe automatiquement

Verdict après une journée d’utilisation : Tout marche bien. Malgré le passage à Gnome, je retrouve mes principaux outils et je n’ai pas rencontré de soucis particuliers. L’outil d’installation des packages est vraiment simple à utiliser et l’outil de mise à jour est prometteur (je ne l’ai pas encore véritablement testé). Un petit bémol pour la version d’Eclipse qui est la 3.2 alors que la 3.4 est dispo depuis un moment déjà.

Bref, si vous avez envie d’essayer cette distribution, n’hésitez pas. Elle existe également en version KDE (RC actuellement).

Squid est le proxy le plus connu, mais étant donné les débits possibles aujourd’hui, l’utilisation d’un proxy est de moins en moins nécessaire. Par contre, en plus de la fonction principale de cache, Squid possède des fonctionnalités intéressantes comme l’ajout de filtrages complémentaires.

SquidGuard est un outil permettant de bloquer l’accès à certaines pages Web, en fonction de différents critères. Cet outil est notamment utilisé par l’éducation nationale pour assurer un contrôle d’accès à Internet dans les établissements scolaires.

L’université de Toulouse met à jour régulièrement des listes noires (blacklist) de sites devant être interdits de consultation par les élèves (donc a priori par mes enfants également). Une page est d’ailleurs consacrée à l’utilisation et la mise en place de SquidGuard.

Installation

Squid est en principe livré avec les différentes distribution de Linux. SquidGuard l’est également dans certaines (c’est le cas dans la version OpenSuse que j’utilise).

Configuration

Il faut avant tout indiquer à Squid d’utiliser SquidGuard pour effectuer un filtrage supplémentaire. Cela se fait en ajoutant la ligne suivante au fichier squid.conf :

url_rewrite_program /usr/sbin/squidGuard -c /etc/squidguard.conf

Un redémarrage de Squid devrait faire appraître des process SquidGuard lancés par Squid.

Mise en place de listes noires

Vous pouvez confectionner vous-même vos blacklistes mais le plus simple est bien entendu d’utiliser des listes déjà éprouvées et mises à jour comme celles de l’université de Toulouse. Elles sont accessibles depuis cette page : http://cri.univ-tlse1.fr/blacklists/. Le fichier blacklists.tar.gz contient toutes les listes et pour une première installation il est sans doute intéressant de l’utiliser.

Les listes doivent être mises en place dans le répertoire indiqué par la variable dbhome du fichier de configuration de SquidGuard (/etc/squidguard.conf dans mon cas).

Prise en compte des listes dans SquidGuard

Il faut alors indiquer à SquidGuard d’utiliser ces listes ou au moins quelques unes (la liste adult est de loin la plus fournie et la plus intéressante en terme de contrôle parental).

dest blacklist {

    domainlist blacklists/adult/domains

    urllist    blacklists/adult/urls

}

Compilation des listes

Afin que SquidGuard soit plus performant et plus rapide au démarrage de Squid, il est possible (voire fortement conseillé) de demander à SquidGuard d’utiliser une base de données pour effectuer son filtrage.

La compilation des listes déclarées dans la configuration se fait à l’aide la commande :

squidGuard -C all

Le reste de la configuration de est assez implicite (déclaration des réseaux et utilisateurs devant être filtrés). Les fonctions avancées peuvent être mises en place en suivant la document de SquiGuard : http://www.squidguard.org/Doc/

Pour activer le filtrage, il suffit alors de configurer l’utilisation du proxy sur les postes qu’on désire protéger. Une solution plus radicale est de configurer au niveau des règles  du firewall l’utilisation automatique du proxy.

Postfix vous permet de modifier la route empruntée par les mails envoyés à certains domaines. Il sufit pour cela d’insérer dans le fichier transport ce type de ligne :

<domaine> : [<serveur smtp de destination>]

Par exemple, pour un serveur connecté sur une ligne Free :

aol.com         :[smtp.free.fr]
.aol.com        :[smtp.free.fr]

La seconde ligne permet de gérer les cas où un sous-domaine d’aol.com serait utilisé au sein d’une adresse email.

N’oubliez pas de compiler le fichier transport à l’aide de la commande

postmap transport

et de vérifier que ce fichier transport est bien déclaré dans le fichier main.cf :

transport_maps = hash:/etc/postfix/transport

Edit : vous pouvez ajouter également :

aim.com         :[smtp.free.fr]

L’installation se fait relativement simplement. Voici les quelques points nécesaires :

Téléchargement de la dernière version sur http://roundcube.net/downloads

L’installation en elle-même ne pose pas particulièrement de problème car il suffit de déposer le contnu du tar.gz dans un répertoire vu par apache.

Création des cles ssl

C’est peut-être la partie la plus sensible… Vous pouvez vous aider d’un de mes posts précédents pour cela.

Création d’un vhost sur apache

Voici un exemple de vhost simple :

<IfDefine SSL>
<IfDefine !NOSSL>

<VirtualHost nom_du_serveur:443>

        #  General setup for the virtual host
        DocumentRoot "repertoire_contenant_roundcube"
        ServerName nom_du_serveur:443
        ServerAdmin email_admin_du_serveur
        ErrorLog /var/log/apache2/nom_du_serveur_error.log
        TransferLog /var/log/apache2/nom_du_serveur_access.log

        SSLEngine on
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

        SSLCertificateFile /etc/apache2/ssl.crt/nom_du_certificat_du_serveur
        SSLCertificateKeyFile /etc/apache2/ssl.key/nom_de_la_cle_privee_du_serveur

        SetEnvIf User-Agent ".*MSIE.*" \
                 nokeepalive ssl-unclean-shutdown \
                 downgrade-1.0 force-response-1.0

        CustomLog /var/log/apache2/nom_du_serveur_acess.log ssl_combined

        <Directory "repertoire_contenant_roundcube">
                Options Indexes FollowSymLinks
                AllowOverride None
                Order allow,deny
                Allow from all
        </Directory>

</VirtualHost>

</IfDefine>

Bien entendu il faut activer le ssl en le redémarrant avecl’option startssl qui n’a d’autre mission que de démarrer le process en spécifiant -DSSL sur la ligne de commande.

Configuration de RoundCube

Le fichier INSTALL livré avec RoundCube décrit les opération à faire au niveau de la base de données. Il s’agit en fait de créer une base, le programme de configuration se chargeant alors de créer toutes les tables necessaires.

Il suffit ensuite d’appeler avec un browser l’url http://nom_de_votre_serveur/installer/ afin de compléter les quelques renseignements nécessaires comme la façons d’accéder au smtp, au serveur imap et à la base de données.

Une fois la configuration terminée, il est consillé de supprimer le répertoire /installer pour éviter quelques surprises

L’installation ne présente pas de problèmes particuliers et les quelques opérations sont décrites dans la documentation livrée. Elle est accessible en tapant la commande :

perldoc postgrey

Le lien avec postfix se fait en ajoutant au paramètre smtpd_recipient_restrictions une option check_policy_service inet:127.0.0.1:10023 (à condition d’avoir utiliser tous les paramètres par défaut). Voici par exemple le paramètre complet :

smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,
        permit_sasl_authenticated,
        check_policy_service inet:127.0.0.1:10023,
        reject_unauth_destination

Une fois le process postgrey lancé (postgrey –inet=10023 -d) et postfix rechargé, les premières traces de contrôle doivent apparaître dans le log postfix.

Le Software Portal de Linux Mint

Vous avez envie de découvrir une nouvelle distribution Linux ? Xavier a l’air très tenté par le test de la Linux Mint. Je dois dire que sur le papier les différentes fonctionnalités sont intéressantes… Pour tout vous dire, je suis en train de la télécharger pendant que j’écris ce billet. Je vous donnerai mes impressions une fois installée

Dovecot permet la gestion des boites au format Maildir, la récupération du courrier en pop3 et impa, SSL ou non et peut assurer le service d’authentification pour Postfix afin d’autoriser nos utilisateurs à envoyer des mails en utilisant notre serveur.

Fichier dovecot.conf

Voici donc les différetns paramètres modifiés par rapport à la configuration d’origine :

disable_plaintext_auth = no

Nécessaire pour l’uthentification de base. Toutes nos connexions avec Dovecot seront faites via SSL/TLS donc pas de soucis de lecture des mots de passe sur la ligne.

ssl_disable = no

SSL sera donc activé

protocol imap {
ssl_cert_file = /var/keys/imap.mondomaine.fr_cert.pem
ssl_key_file = /var/keys/imap.mondomaine.fr_key.pem
ssl_key_password = <Password de la clé>
}
protocol pop3 {
ssl_cert_file = /var/keys/pop3.mondomaine.fr_cert.pem
ssl_key_file = /var/ssl/keys/pop3.mondomaine.fr_key.pem
ssl_key_password = <Password de la clé>
}

SSL sera alors activé pour imap et pop3. La création des clés et certificats peuvent être faits en suivant les explications ici.

mail_location = maildir:~/Maildir

Même emplacement que défini dans Postfix (c’est mieux   )

auth default {
  mechanisms = plain login
}

Permet d’autauriser les authentification en PlainText

passdb passwd-file {
  args = /etc/dovecot/dovecot.users
}
userdb passwd-file {
  args = /etc/dovecot/dovecot.users
}

Indique l’emplacement du fichier listant les utilisateurs

socket listen {
  client {
    path = /var/spool/postfix/private/auth
    mode = 0660
    user = postfix
    group = postfix
  }
}

Indique à dovecot qui a le droit d’utiliser son authentification (cf paramètre smtpd_sasl_path de la conf postfix).

Fichier dovecot.users

Il reste maintenant à lister nos utilisateurs dans le fichier dovecot.users. Une ligne type à cette forme :

<userlogin>:{<encodagepwd>}<passwd>:vmail:vmail::<chemin de la boite>::userdb_mail=maildir:~

Par exemple,

monlogin:{PLAIN}passwd:vmail:vmail::/home/vmail/monlogin::userdb_mail=maildir:~

L’enregistrement dans ce fichier des mots de passe en mode PLAIN n’est pas recommandé d’un point de vue sécurité. Différents encodage peuvent être utilisé. Il suffit d’utiliser l’outil dovecotpw qui génère la chaine encodée à insérer dans le fichier de configuration.

Voici dans un premier temps le paramétrage de Postfix. Le paramétrage de dovecot viendra dans un second temps…

Tout d’abord, spécifiquement pour la Suse, il faut demander à Yast de ne plus gérer lui-même Postfix.

Système / Editeur pour fichier /etc/sysconfig / Network / Mail / General / MAIL_CREATE_CONFIG = no

Voici ensuite les différents paramètres à renseigner dans le fichier /etc/postfix/main.cf

myhostname = <Nom du serveur>

par exemple : smtp.mondomaine.fr

mydomain = <domaine principal>

par exemple : mondomaine.fr

mydestination = $myhostname, localhost.$mydomain, localhost, <nomserveurinterne>

Dans mon cas, je veux pouvoir router certains mails via une adresse précise correspondant à un alias de smtp.mondomaine.fr. Par exemple, smtp.domaineinterne.com

virtual_mailbox_domains = <liste de domaines>

Par exemple, mondomaine.fr, seconddomaine.com, serveurmail.mondomaine.fr
Dans mon cas, je renseigne cette liste en utilisant virtual_mailbox_domains et non pas virtual_alias_domains car j’utilise la possibilité de gérer des utilisateurs virtuels (qui ne sont pas des utilisateurs déclarés sur mon serveur linux).

virtual_alias_maps = hash:/etc/postfix/virtual

Le fichier virtual contient la liste de mes redirections vers d’autres emails ou vers des utilisateurs système

virtual_mailbox_maps = hash:/etc/postfix/vmailbox

Le fichier vmailbox contient la liste de mes redirections vers mes utilisateurs virtuels

virtual_mailbox_base = /home/vmail

Définit le répertoire contenant les boites des utilisateurs virtuels

virtual_minimum_uid = 500
virtual_uid_maps = static:3000
virtual_gid_maps = static:3000

Les boites mails virtuelles doivent appartenir à un compte et un groupe ayant l’id 3000 (par exemple vmail)

smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous

Le smtp autorise l’accès sasl pour les utilisateurs non anonymes

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Cet accès sasl est géré par dovecot

smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_recipient, permit_sasl_authenticated, reject_unauth_destination

On utilise les utilisateurs du réseau interne et les utilisateurs authentifiés

mynetworks = 192.168.1.0/24

Définition du réseau local interne

home_mailbox = Maildir/

Les boites sont gérés en format Maildir (un répertoire par boite et non pas un fichier). Le / est important…

Exemple de fichier virtual

nom@mondomaine.fr      userlinux
autre@mondomaine.fr    autre@hotmail.f

Exemple de fichier vmailbox

user1@mondomaine.fr      user1/

Cela signifie que les mails reçus par user1@mondomaine.fr seront stocké dans la boit user1 au format Maildir (grâce à la présence du / ) dans le répertoire user1 (qui sera lui-même situé sous /home/vmail).

Important : Ces deux fichiers doivent être « recompilés » avec l’outil postmap après chaque modification afin de mettre à jour les .db respectifs.

Voilà, le postfix doit en principe être fonctionnel, et les règles d’anti-relaying en place si les domaines et noms de serveurs correctement renseignés. Il est important de bien tester cette partie sous peine de rapidement avoir un serveur qui croulera sous le trafic de spams :-/

Prochain épisode, le paramétrage de Dovecot permettant de relever le courrier mais également d’authentifier nos utilisateurs pour l’envoi des mails.

# Création du CA
openssl req -config /etc/ssl/openssl.cnf -new -x509 -keyout private/cakey.pem -out cacert.pem -days 3650

# Générer une cle privée et la demande de certificat
openssl req -config /etc/ssl/openssl.cnf -new -keyout keys/server_key.pem -out keys/server_req.pem

# Signer le certificat
openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -out certs/server_cert.pem -infiles keys/server_req.pem