En anteriors entrades hem configurat el servidor de correu Postfix per tal que gestionés les adreces de correu mitjançant un directori LDAP. Això permet tenir un sistema d'usuaris centralitzat. Tanmateix aquest sistema no està correctament configurat per a quedar públic a Internet, doncs seria un objectiu directe de qui vol aprofitar per enviar correu brossa mitjançant el nostre servidor.

Així, el següent pas serà impedir que es pugui utilitzar el nostre servidor com a origen de correu fraudulent.

Xifrat a l'hora rebre el correu

El servidor POP3 Courier, ja disposa d'un sistema d'identificació per a evitar que altres puguin llegir el teu correu, encara que no és del tot segur i viatja de forma no-xifrada.

Una forma més segura de realitzar les connexions pop3 és fer-ho de forma xifrada.

courier-pop-ssl
110/tcp open pop3
S'instal·larà les claus i certificats
995/tcp open pop3s
El primer cop que hi accediu un informarà que el certificat no es pot validar, en aquest moment has de decidir si vols acceptar-lo (continuar) o no fer-ho. L'opció correcta seria acceptar-lo, doncs te'n fies de nosaltres, i el certificat ens l'hem creat nosaltres mateixos.

En principi la versió sense xifrar segueix funcionant, però recomanem a tothom usar mètodes xifrats per a que ningú que espiï la xarxa us pugui llegir els correus. També podríem desactivar-lo però de vegades no tothom té clients de correu que accepten comunicació xifrada.

Xifrat en el Postfix

El mètode de xifrat SSL a Postfix s'anomena TLS. Segurament ja l'heu instal·lat anterior, però si no, el paquet s'anomena "postfix-tls".

Quan instal·les el paquet, normalment et crea les claus i els certificats, i te'ls afegeix en la configuració. Si vols crear-lo tu mateix, pots fer-ho de la següent manera:

/usr/bin/openssl req -config /etc/ssl/openssl.cnf -new -x509 -nodes -out \
/etc/postfix/ssl/smtpd.pem -keyout /etc/postfix/ssl/smtpd-key.pem -days 999999

Un cop instal·lat el paquet i tenint les claus i el certificat, només cal modificar els fitxers de configuració:

smtpd_use_tls=yes
smtp_use_tls=yes
#smtpd_tls_auth_only=yes
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

smtpd_tls_loglevel=1
smtpd_tls_received_header=yes
smtpd_tls_session_cache_timeout=3600s
tls_random_source=dev:/dev/urandom

La primera línia indica que s'usa TLS. Si hi fiqueu "no" no podreu usar-lo i el client de correu us ho indicarà. La segona línia indica que el programa que envia els correus cap a fora, ha d'usar xifrat si el servidor on es connecta li ho demana. La tercera línia si la des-comenteu, obligareu a tothom a connectar-vos amb vosaltres amb SSL. No sé si és molt bo usar-ho, doncs el client que es connecta amb vosaltres no té activada l'opció de comunicacions xifrades no rebreu el seu correu.
Les dues línies següents indiquen el lloc on es troben els certificats i claus per xifrar la informació.

La resta de de paràmetres, serveixen per altres coses no tant importants que si us interessa trobareu en la documentació de postfix.

Un altre fitxer que també s'ha de modificar és el "master.cf", descomentant la línia del "smtpds" on hi ha els paràmetres del TLS:

smtps    inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes

No estem molt segurs de perquè serveix, tenint en compte que sense aquestes modificacions el xifrat funciona correctament, però en tots els documents que hem vist, hi és posat. Bé, mirant-nos-ho una mica, el mode "smtpd_tls_wrappermode" serveix per clients antics que busquen el servidor de correu xifrat en un port diferent del normal (el 465). Com podeu veure si mireu quins ports se us obre:
465/tcp open smtps

Ara ja tenim el servidor de correu a punt per treballar amb comunicacions xifrades, per a que ningú ens espiï el nostre correu-e.

Activar la identificació SASL LDAP

En l'apartat anterior, fem que la informació viatgi xifrada, però segueix sent possible que qualsevol persona pugui enviar correu massivament sense necessitat de cap tipus d'autenticació ni sense comprovar que el remitent pertany al nostre servidor.

Anem a marcar els paràmetres que ens activaran la identificació del servidor de correu. La identificació per part dels clients és voluntària, però el servidor pot utilitzar-la per realitzar certes restriccions i controlar qui envia correus.

Aquest són els quatre paràmetres interessants en la identificació SASL:

smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_application_name = smtpd

El primer és prou clar per no haver de parlar-ne més. El segon paràmetre permet la identificació de clients de correu antics que no segueixen algunes normes (outlook express, Microsoft Exchange, ...). El tercer paràmetre indica quina aplicació realitzarà la identificació, nosaltres deixem el valor per defecte.

Amb tot això encara no funciona la identificació, primer cal anar al directori sasl i crear o modificar el fitxer "smtpd.conf" per a indicar el mètode d'identificació sasl.

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Això indica al sistema que s'usarà el dimoni "saslauthd" per a identificar-se. Un cop fet això cal configurar el dimoni "saslauthd" per a que permeti la identificació mitjançant el correu electrònic de la mateixa manera que no feia abans només amb en nom de l'usuari. Si voleu provar si funciona una identificació podeu usar la següent instrucció:

$ testsaslauthd -u tester -p passwdtester
0: OK "Success."
$ testsaslauthd -u prova -p passwdprova
0: OK "Success."
$ testsaslauthd -u tester@guifi.net -p passwd tester
0: NO "authentication failed"
$ testsaslauthd -u prova@guifi.cat -p passwdprova
0: NO "authentication failed"

En aquest cas, tenim l'usuari tester creat anteriorment en el directori LDAP i que permetia identificar-se en el sistema. També podeu veure que usant el correu per a identificar-nos no funciona. Caldrà que el nom de l'usuari amb el correu també sigui possible.

El primer que cal fer és indicar en el fitxer per defecte de configuració del "saslauthd" que es troba en una debian situat a: "default/saslauthd" i que ja havíem modificat en l'exemple de la identificació del sistema. Ara hi afegirem que usi abans el directori LDAP en comptes de PAM. També li indicarem on és el fitxer de configuració del filtre LDAP:

START=yes
MECHANISMS="ldap pam"
CONFIG_FILE="/etc/saslauthd.conf"

El fitxer de configuració contindrà el següent:

ldap_version: 3
ldap_servers: ldap://ldap.guifi.net
ldap_search_base: ou=users,dc=guifi,dc=net
ldap_auth_method: custom
ldap_filter: (|(uid=%u)(&(mail=%u)(accountStatus=active)))

Aquí veieu que indiquem la localització del directori LDAP, i filtre la identificació tant amb el nom d'usuari, com amb el correu electrònic dels qui el tenen activat. Un cop fet això, heu de tornar a engegar el dimoni saslauthd.

El problema amb l'execució en gàbia del postfix

Però segurament encara no funciona. Això és degut a que el servidor postfix, per motius de seguretat, s'executa en un directori a part de la resta del sistema. Això vol dir que a l'hora de intentar enllaçar amb el dimoni saslauthd no hi pot arribar. Ho podeu consultar en el log "/var/log/mail.log" quan no us pogueu identificar us dirà que no pot connectar-s'hi.

Això és pot solucionar de dues formes: traient el procés de la gàbia (opció elimina mesures de seguretat), o canviant el directori on s'executa "saslauthd" per tal que el postfix hi pugui accedir.

Per solucionar això de forma que mantenim les mesures de seguretat és molt senzill. Només cal moure el directori on el dimoni "saslauthd" hi té el procés en execució i posar-lo en el directori on s'executa postfix. I posteriorment crear un enllaç simbòlic del lloc original al nou lloc.

Així tenint en compte que el directori d'execució de "saslauthd" és a "/var/run/saslauth" i el postfix s'executa en en un gàbia a "/var/spool/postfix". Primer mourem aquest directori:

$ mv /var/run/saslauth /var/spool/postfix

Després, en creem l'enllaç simbòlic en el lloc original.

$ ln -s /var/spool/postfix/var/run/saslauthd/ /var/run/saslauth

I tornem a engegar els dos processos. Ara el postfix ja pot accedir al procés doncs és en el seu arbre de directori.

Restriccions en l'enviament i rebuda de correu

El tema de la identificació no implica que serveixi per a res. Doncs ens podem seguir connectant sense identificar-nos-hi. Això és així perquè els altres servidors que ens envien el correu de les nostres adreces, no han d'identificar-se per res per enviar-nos el nostre correu. I no els posarem pals a les rodes a l'hora de rebre el correu.

Doncs bé, anem a veure com podem evitar algunes males pràctiques:

Evitar connexions maleducades

Hi ha clients que es connecten al servidor i no saluden:

HELO soc.el.servidor.del.domini.tal.com

A aquests, no els volem per maleducats. Hi els limitem l'enviament de correu amb aquesta opció:

smtpd_helo_required = yes 

Evitar verificació d'adreces

Hi ha pirates que es dediquen a fer consultes de les adreces de correu d'alguns dominis per a vendre-les a spammers. Per evitar aquesta verificació usarem el següent paràmetre:

disable_vrfy_command = yes

Restriccions del destinatari

Anem al moll de l'os. I per començar afegirem la configuració per analitzar-la després:

# Restriccions del destinatari
smtpd_recipient_restrictions =
        reject_non_fqdn_recipient
        permit_auth_destination
        reject_unknown_recipient_domain 
        permit_sasl_authenticated
        reject

El paràmetre indicat comprova el destinatari del correu. Així que la forma més adient de configurar el filtre depenent dels destinataris funciona així:

• reject_non_fqdn_recipient: Aquest paràmetre refusa qualsevol enviament a una adreça que no compleix la normativa d'adreces. Totes les adreces han de tenir l'arroba, l'usuari i el domini (p.e: usuari@domini.cat)
• permit_auth_destination: Aquest paràmetre permet qualsevol enviament als nostres dominis de correu, i als dominis dels quals en fem de servidor de suport per si aquest falla. Així qualsevol correu en que nosaltres en gestionem el compte el rebrem sense cap més restricció.
• reject_unknown_recipient_domain: Aquesta paràmetre realitza una comprovació del domini del destinatari. Si aquest domini no existeix, ja no permet enviar el correu.
• permit_sasl_authenticated: I per acabar, només es permet enviar correu a altres destinataris si ens hem identificat correctament.
• reject: Tota la resta els refusem.

Amb aquesta configuració aconseguim rebre tot el correu destinat als nostres comptes, i només permetem enviar correus als usuaris identificats correctament.

Hi hauria la possibilitat de permetre enviar correus des de les nostres xarxa amb l'opció "permit_mynetworks" però creiem que és una mala pràctica que s'enviïn correus que no s'hi pugui respondre, encara que sigui des de la nostra pròpia màquina.

Comprovar el propietari del remitent

Amb la configuració anterior, encara que és prou segura hi hauria la possibilitat que algú que s'hagués identificat, pogués enviar correus amb remitents que no li pertanyen, i fins i tot remitents amb dominis inexistents.

Podem evitar això comprovant qui és el propietari de cada correu, i com que obliguem a identificar-nos per als correus que surten, podem obligar a que l'usuari identificat sigui propietari de la direcció del remitent.

Això és realitzarà amb aquesta part de la configuració:

# Restriccions del remitent
smtpd_sender_restrictions =
        reject_sender_login_mismatch

# --
# Control de les adreces
smtpd_sender_login_maps = ldap:loginmap
loginmap_server_host = servidor.xarxa.xin
loginmap_server_port = 389
loginmap_bind = no
loginmap_search_base = ou=users,dc=poble,dc=dev
loginmap_query_filter = (&(mail=%s)(accountStatus=active)(objectClass=qmailUser))
loginmap_result_attribute = mail

El paràmetre "smtpd_sender_restrictions" controla el remitent. I el paràmetre "reject_sender_login_mismatch" comprova que qui s'ha identificat sigui propietari de l'adreça de correu, a partir de la taula "smtpd_sender_login_maps" que relaciona l'adreça de correu amb el login del propietari d'aquesta adreça.

Com que el login del propietari és la mateix adreça de correu, en la consulta LDAP retornem la pròpia adreça de correu. És així de senzill.

Conclusions

Ja veieu, que és una mica complex el tema dels servidors de correu. Però heu de tenir present tots aquests elements de seguretat, doncs hi ha infinitat d'atacants que intenten trobar un servidor accessible per a usar-lo per a enviar correu brossa i això pot fer que el teu servidor passi a llistes negres de correu no desitjat i et seria impossible poder enviar correu.

No us esteu de fer proves, fent-vos passar per altres persones i intentant enviar correus amb remitents no existents.