oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: mailgateway

ACL Policy Daemon for Postfix

Reading time: 3 – 4 minutes

Fins ara l’únic policy daemon que usava per postfix és el policyd v1 que esta fet amb C i per temes de rendiment em donava grans funcionalitats, rapidesa i escalavilitat sobretot pel seu backend en MySQL. Però avui m’he vist obligat a instalar el ACL Policy Daemon que esta programat amb Twisted+Python i que a través de la seva capacitat de configurar les regles d’accés al Postfix vai ACLs m’he pogut montar una funcionlitat un pel rebuscada que em calia per un client.

El problema és que aquest client necessita:

  • Rebre correu pels seus dominis
  • Permetre relay previa autenticació dels seus roadwarriors

Doncs bé això planteja un problema degut a una funcionalitat contradictoria. Si configurem el Postfix perquè rebi correu local, podem protegir aquest correu contre UBE tan com volguem i més però si l’origen especificat en la transacció SMTP indica que el remitent és una compte de correu del mateix domini que el destí (sovint la mateixa compte de correu), aquest correu s’acceptarà com a legítim i no es demanarà autenticació perquè l’MTA on s’està enviant el correu és el destí del mateix. Gràcies a això el correu serà acceptat al MTA i només quedarà a expenses del anti-spam i regles UBE anturar-lo, el qual malgrat via SPF i d’altres similars intentarà aturar aquest correu això no sempre serà possible i menys si els intents d’injecció són de l’ordre de desenes de milers al dia. Ens trobavem que alunes desenes passaben els filtres igualment.

Així doncs, gràcies a aquest policy daemon he pogut programar un regla que diu algo així:

  • si IP d’enviant no és local
  • si origen del correu és un domini local
  • si destí del correu és un destí local
  • si l’usuari no s’ha autenticat
  • NO es pot enviar aquest correu!

Els clients que estan fora de l’empresa (roadwarriors) sempre que envien un correu ho fan via ASMTP així doncs, si volen enviar un correu a alguna compte del mateix domini que la seva ho faran de forma autenticada. Per altre banda, si un client de correu intern a l’emrpesa intenta enviar un correu ho farà amb una IP local de l’empresa i aquest filtre no el bloquejarà.

Com podeu veure el problema és una mica enrabassat. Per altre banda, si voleu fer un cop d’ull al fitxer de configuració policy.conf (un dels fitxers de configuració del aplicyd) que he creat és de l’estil d’aquest:

acl wl client_address NET_IP/MASK
action nice_users DUNNO
access wl nice_users

acl remitent sender @example.com
acl desti recipient @example.com
acl aut sasl_method (PLAIN|LOGIN)
action rej REJECT Auth required
access remitent desti !aut rej

Malgrat jo he usat el apolicyd per temes molt concrets s’ha de dir que el seu codi font és molt entenedor i simple de modificar, a més de suportar moltíssimes funcionalitats de serie que permeten ajustar les nostres regles de filtrat moltíssim. Realment m’ha sorprès de forma molt positiva no m’esperava que estigués tan ben pensat.

Postfix: Verifiquem recipients des del mailgateway

Reading time: 2 – 3 minutes

El maig de l’any passat vaig publicar un petit manual de com configurar un Postfix per fer de ‘mailgateway’ d’un altre servidor MTA. Doncs bé, avui hi he afegit una funcionalitat que inicialmen creia impossible. Es tracta de comprobar si el correu que estem rebent des de fora i que va dirigit a un usuari local existeix en el servidor destí on enviarem el correu. Fins ara tots els correus amb destí @dominilocal.tld els agafabem i ja era el MTA intern qui el refusava. El problema d’això és que genera un email de resposta del MTA intern cap al host de ‘relay’ (mailgateway) i aquest correu després s’intenta entregar al remitent orignal. Amb el conseqüènt problema de creixement de la cua de missatges sobretot si el remitent és un email problemàtic.

diagrama-xarxa.png

Doncs bé buscant per la documentació de Postfix he trobat que a través del fitxer /etc/postfix/main.cf podia usar la comanda smtpd_recipient_restrictions per afegir una nova restricció que fos verificar el recipient (reject_unverified_recipient). Però això no és el problema. Sinó que el problema esta en després d’això anar a verificar aquest recipient a l’altre host. Això es fa amb la comanda address_verify_local_transport on li indiquem quin és el host que realment té la base de dades d’usuaris.

smtpd_recipient_restrictions =
...
        reject_unverified_recipient
...
address_verify_local_transport=ip_interna_host_MTA

Obviament el MTA intern ha d’estar configurat de forma que no accepti correus per comptes que no existeixin. Per tant, no pot estar configurat amb un cul de sac, o com diuen en castellà amb una direcció de correu ‘recojetodo’. Així doncs, quan un MTA d’internet envii un correu al servidor de relay (mailgateway) aquest obrirà una connexió contra l’MTA intern i verificarà que existeix la compte de correu a través de la comanda RCPT TO, això ens permet no haver d’activar la temuda comanda VERIFY BY, per tal de saber si existeix o no una compte al servidor intern i per tant, refusar en cas de que sigui necessari aquest correu que es preten entregar.

mailgateway: postfix+amavisd+clamav+spamassassin+sasl

Reading time: 3 – 5 minutes

Algunes empreses disposen de servidors de correu amb infraestructures internes realment complexes i que seguint la màxima de la informàtica el millor que podem fer és: si alguna cosa va no la toquis. El problema és que sovint aquestes estructures tan complexes no disposen de filtres de correu mailiciós. O sigui, no són capaces de passar antivirus al correu, filtrar l’spam i controlar altres enviaments maliciosos de correu. A més intentar afegir un software dins el propi servidor que ens fassi aquestes funcions sobre l’Mail Transport Agent (MTA) que ja tenim corrent és un risc innecessari i poc rentable moltes vegades.

diagrama-xarxa.png

Una solució que s’usa sovint és afegir un servidor només per filtrar el correu que entre i surt de l’empresa i intentar eliminar amb aquest mail-gateway tots els correus no dessitjats. Bàsicament doncs el que fem és col·locar l’SMTP (Simple Mail Transport Protocol) del mail-gateway com a porta d’entrada del correu extern. Després modifiquem el servidor intern de correu perquè tots els correus que hagi d’enviar cap a fora ho fassi a través del mail-gateway. O sigui, posem com a servidor de relay fix del servidor intern la direcció del MTA del gateway.

Amb aquest escenari els usuaris no han de canviar res de res, ja que només estem intervenint el port 25/tcp, o sigui, l’SMTP. A més al servidor intern de correu podem crear una compte de gestió de correo mailiciós, per exemple mailgateway@exemple.com (sent exemple.com el nostre domini). En aquest compte li creem dues carpetes una que es digui spam i l’altre que es digui ham. El que farem és sincronitzar el correu d’aquestes comptes amb una carpeta del mail-gateway (si les comptes són IMAP és bona idea sincronitzar-les amb l’offlineimap). Quan tinguem aquests correus al mail-gateway li direm als filtres bayessians de l’antispam que aprenguin com és el correu maliciós que no és capaç de filtrar i com és el correu que ha filtrat i que era legítim.

Aquesta compte de correu (mailgateway@exemple.com) que hem creat al servidor intern, la podem configurar com a compte de correu secundaria a un administrador de la xarxa. Així aquest podrà gestionar el manteniment sense haver de tocar el mail-gateway. En cas de que hi hagi algún usuari de la xarxa que vulgui localitzar un correu que s’ha filtrat l’administrador ho podrà fer des d’aquesta compte.

A més pels usuaris que estan fora de l’empresa, delegacions o d’altres similars ens pot interessar autenticar l’SMTP per tal de que aquests usuaris puguin usar l’SMTP del mailgateway per enviar correu. Així doncs, aprofitarem el servei d’IMAP (Internet Message Access Protocol) del servidor intern per validar l’autenticació en l’SMTP. Sona una mica extrany però el mètode és ben senzill. Es tracta d’aprofitar la compte l’usuari i clau que tenen els usuaris en el servidor IMAP intern, llavors es configura el MUA perquè usi aquestes dades com a informació per autenticar l’SMTP i el servidor d’MTA quan rep una autenticació via SMTP el que fa és obrir una connexió IMAP contra el servidor intern i provar l’usuari i clau que el client l’hi ha enviat a l’SMTP si això és correcte l’MTA permet enviar correu al MUA amb l’origen i destí que vulgui.

La documentació d’aquest projecte la podeu trobar al wiki:

mail-gateway_amb_amavisd-new

Tenir-la al wiki em permet anar-a millorant i esta sempre localitzada.

Si teniu alguna cosa que no esta clara, petició o demanda del tipus que sigui sobre aquesta documentació podeu penjar els comentaris en aquest post.