Archive for the 'Spam' Category

Blacklist de destinataire dans Postfix

Déjà pourquoi faire ça ? Nous avons eu un phishing assez méchant qui demande les identifiants / mots de passes au niveau de l’Université. Le truc est bien ficelé, très bien écrit et avec des domaines plausibles. Bon, le phishing est donc passé, que faire ? A part blacklister en sortie rien. On peut agir à deux niveaux : IP en blacklistant le MX du domaine de info.al au niveau du pare-feu. L’avantage est que c’est simple à faire et qu’en une seule manipulation on touche tout le réseau (du moins ce qui est dans le périmètre du pare-feu). L’inconvenient c’est qu’une requêtes MX sur le domaine sort un serveur hotmail donc il faut oublier cette méthode. Nous allons donc travailler au niveau applicatif SMTP en blacklistant le destinataire.

On génère une map de hash /etc/postfix/block_recipient :

notice@info.al  REJECT  mail bloque

Dans le main.cf :

smtpd_recipient_restrictions =
      check_recipient_access hash:/etc/postfix/block_recipient,
      ...

On recrée la map :
# postmap /etc/postfix/block_recipient

On relance Postfix :
# /etc/init.d/postfix reload

Intégration de Pyzor, Razor2 et DCC sous Spamassassin / Amavisd-new

Ce billet fait un point sur l’intégration des bases données distribuées d’empreinte de messages dans un environnement Spamassassin invoqué par Amavisd-new sous Debian. Ces systèmes sont uniquement basés sur les occurrences. C’est a dire qu’on va compter le nombre de fois que les serveurs centraux “voient” passer un message. Les empreintes interviennent dans le processus de normalisation des messages pour être présentés aux serveurs. On réalise plusieurs empreintes pour un message correspondants aux partie “intéressantes” du message (fuzzy checksums). Ces empreintes sont ensuite soumises sous forme de rapport aux serveurs. La différence entre DCC et Pyzor/Razor2 est dans le mécanisme de collecte : DCC collecte tout (ham et spam) tandis que Razor2 et Pyzor ne collectent que des spams. La partie qui nous intéresse est le client. Quand il voit passer un message, il interroge les serveurs pour avoir les statistiques relatives à ce message.

On va commencer par installer ce que l’on peut via les packages :
# apt-cache search razor

pyzor - spam-catcher using a collaborative filtering network
razor - spam-catcher using a collaborative filtering network

# apt-cache search dcc-client
Rien, il faudra se palucher DCC depuis les sources … La raison est que la version packagée par Debian est vulnérable à une faille non corrigée.

1. Razor2 et Pyzor

# apt-get install razor pyzor
On initialise un environnement par défaut Razor (création du .razor dans la home du root) :
# razor-admin -d -create
Ensuite en enregistre sa machine sur le réseau Razor :
# razor-admin -register
On y ajoute le fichier de configuration par défaut de l’agent :
# cp /etc/razor/razor-agent.conf /root/.razor/
On balance ça dans la home de l’utilisateur amavis :
# cp -r /root/.razor /var/lib/amavis
On effectue ensuite deux ou trois modifications dans /var/lib/amavis/.razor/razor-agent.conf :
- passer debug à 0 ;
- ajouter la ligne : “razorhome = /var/lib/amavis/.razor” pour que Razor2 trouve sa home.
On fixe le possesseur du répertoire fraichement ajouté :
# chown -R amavis:amavis /var/lib/amavis/.razor
Dans les préférences Spamassassin de l’utilisateur amavis (/var/lib/amavis/.spamassassin/user_prefs), on lui spécifie l’emplacement du fichier de configuration de Razor2 :

razor_config /var/lib/amavis/.razor/razor-agent.conf

Pour Pyzor, c’est plus simple, on définit le serveur auquel rattacher l’agent local :
# pyzor discover

downloading servers from http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x

Puis recopie de la configuration dans la home de amavis :
# cp -r /root/.pyzor /var/lib/amavis/
chown -R amavis:amavis /var/lib/amavis/.pyzor

On test Pyzor :
# su amavis -c 'pyzor ping'
Côté Spamassassin, on vérifie que dans /etc/mail/spamassassin/v310.pre on a bien les plugins activés :

loadplugin Mail::SpamAssassin::Plugin::Razor2
loadplugin Mail::SpamAssassin::Plugin::Pyzor

2. DCC

On va donc le compiler :
# cd /usr/local/src/
# wget http://www.rhyolite.com/dcc/source/dcc.tar.Z

--2010-02-24 11:06:08--  http://www.rhyolite.com/dcc/source/dcc.tar.Z
Resolving www.rhyolite.com... 192.188.61.3, 2001:4978:230::3
Connecting to www.rhyolite.com|192.188.61.3|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1630683 (1.6M) [application/x-compress]
Saving to: `dcc.tar.Z'
 
100%[======================================>] 1,630,683   84.2K/s   in 21s     
 
2010-02-24 11:06:29 (75.4 KB/s) - `dcc.tar.Z' saved [1630683/1630683]

# tar xzf dcc.tar.Z
# cd dcc-1.3.120

On va compiler DCC avec trois options : l’uid qui vaut amavis, on désactive le serveur et la partie dccm (interface Sendmail).
./configure --with-uid=amavis --disable-server --disable-dccm
# make
# make install

Dans /etc/mail/spamassassin/v310.pre, décommenter :

#loadplugin Mail::SpamAssassin::Plugin::DCC

Dans /etc/mail/spamassassin/local.cf, ajouter :

# dcc
use_dcc 1
dcc_path /usr/local/bin/dccproc
 
#pyzor
use_pyzor 1
pyzor_path /usr/bin/pyzor
 
#razor
use_razor2 1

Effectivement dans le cadre d’une utilisation avec Amavis, ça sert pas a grand chose (les réglages de ce fichier sont écrasés par Amavis). Par contre si on décidait de dédier la machine à Spamassassin et d’interfacer la version optimisée (Spamd) directement avec Postfix, le local.cf serait utilisé.

On redémarre Amavis et on test :
# /etc/init.d/amavis restart
# wget http://svn.apache.org/repos/asf/spamassassin/branches/b2_4_0/sample-spam.txt
# su amavis -c 'spamassassin -D test-report.txt 2>&1
# egrep -i '(pyzor|razor|dcc)' test-report.txt

[11769] dbg: plugin: loading Mail::SpamAssassin::Plugin::DCC from @INC
[11769] dbg: dcc: network tests on, registering DCC
[11769] dbg: plugin: loading Mail::SpamAssassin::Plugin::Pyzor from @INC
[11769] dbg: pyzor: network tests on, attempting Pyzor
[11769] dbg: plugin: loading Mail::SpamAssassin::Plugin::Razor2 from @INC
[11769] dbg: razor2: razor2 is available, version 2.84
[11769] dbg: config: fixed relative path: /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_dcc.cf
[11769] dbg: config: using "/var/lib/spamassassin/3.002005/updates_spamassassin_org/25_dcc.cf" for included file
[11769] dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_dcc.cf
[11769] dbg: config: fixed relative path: /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_pyzor.cf
[11769] dbg: config: using "/var/lib/spamassassin/3.002005/updates_spamassassin_org/25_pyzor.cf" for included file
[11769] dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_pyzor.cf
[11769] dbg: config: fixed relative path: /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_razor2.cf
[11769] dbg: config: using "/var/lib/spamassassin/3.002005/updates_spamassassin_org/25_razor2.cf" for included file
[11769] dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_razor2.cf
[11769] dbg: razor2: part=0 engine=4 contested=0 confidence=0
[11769] dbg: razor2: results: spam? 0
[11769] dbg: razor2: results: engine 8, highest cf score: 0
[11769] dbg: razor2: results: engine 4, highest cf score: 0
[11769] dbg: pyzor: pyzor is available: /usr/bin/pyzor
[11769] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin11769frgBiutmp
[11769] dbg: pyzor: [11771] finished: exit=0x0100
[11769] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 0
[11769] dbg: dcc: dccifd is not available: no r/w dccifd socket found
[11769] dbg: dcc: dccproc is available: /usr/local/bin/dccproc
[11769] dbg: dcc: opening pipe: /usr/local/bin/dccproc -H -x 0 -a 212.17.35.15 < /tmp/.spamassassin11769frgBiutmp
[11769] dbg: dcc: got response: X-DCC-CollegeOfNewCaledonia-Metrics: sara 1189; Body=1 Fuz1=1 Fuz2=38

Postfix et Kerberos howto

Après moult jours de tripatouillage, je suis parvenu à faire fonctionner l’authentification Kerberos avec Postfix. En effet, on trouve dans les howtos un nombre impressionnant de façon d’y arriver (avec comme toujours certaines configurations dont on peut se demander comment elles fonctionnent). Installons d’abord les paquets :

$ apt-get install postfix
$ apt-get install libsasl2-modules-gssapi-mit

Le daemon saslauthd est inutile. Passons maintenant à l’enregistrement du service SMTP dans le KDC en créeant un ticket pour le service (smtp/fqdn).

$ kadmin.local
kadmin: addprinc -randkey smtp/mailtest.mondomaine
kadmin: ktadd -k /etc/smtp.keytab smtp/mailtest.mondomaine

Il faut ensuite recopier le /etc/smtp.keytab depuis le KDC vers le serveur de mail (mailtest). Sur mailtest ce fichier doit être installé dans le chroot de Postfix car par défaut le processus smtpd acceptant les connexions authentifiées pour l’envoi de messages est chrooté dans /var/spool/postfix. Tant que l’on est à parler du chroot, il faut aussi recopier le répertoire temporaire /var/tmp dans /var/spool/postfix/var car il est utilisé par le processus krb5.login. Il nous faut aussi le /etc/krb5.conf dans /var/spool/postfix/etc. Dernière note sur le chroot, on peut aller voir dans le script de démarrage (/etc/init.d/postfix) les fichiers copiés automatiquement dans le chroot au démarrage du service.

Une fois le chroot configuré, passons au master.cf pour activer un smtpd en SSL sur le port 465 :

smtps inet n - - - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

Occupons nous aussi du main.cf :

import_environment = KRB5_KTNAME=/etc/smtp.keytab
 
[...]
 
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
 
smtpd_recipient_restrictions = permit_sasl_authenticated,
                                permit_mynetworks,
                                reject_unauth_destination

Le import_environment est super important car il permet de positionner l’emplacement d fichier keytab utilisé par le service smtp kerberisé. On redémarre un coup Postfix et on test les méthodes d’authentification présentées aux clients avec la classqiue commande “ehlo” :

$ openssl s_client -connect mailtest.univ-orleans.fr:465

Nous renvoie la sortie suivante :

220 mailtest.mondomaine ESMTP Postfix (Debian/GNU)
ehlo mailtest.mondomaine
250-mailtest.mondomaine
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN
250-AUTH=GSSAPI DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

La GSSAPI est bien notre mécanisme d’authentification par défaut. Testons maintenant avec un Thunderbird. Pour le configurer, allez dans les propriétés du compte puis “serveur sortant smtp”. Ajoutez en un avec comme nom de serveur mailtest.mondomaine, port 465, selectionnez “Utiliser un nom d’utilisateur et un mot de passe” et enfin choisissez “Utiliser un connexion sécurisée SSL”. Vous devriez maintenant pouvoir envoyer tous vos messages authentifié via Kerberos. Sus au spam interne !

Le debugging est assez complexe, surtout avec le chroot de Postfix. Pour vous aider, vous pouvez utiliser à mort strace en l’attachant au processus “master” de Postfix en suivant tout les types de fork (option -fF) et en sélectionnant certains appels systèmes (-e).

Spamd

Spamd est un programme antispam fourni dans le système de base OpenBSD. Il réglemente le trafic vers le MTA (Mail Transfer Agent) en interagissant avec PF (Packet Filter).
Continue reading ‘Spamd’