MX secundari a cPanel
Aquest és un apunt recordatori que pot tenir utilitat a tot aquell que usi cPanel/WHM com a sistema d’allotjament a Internet.
cPanel/WHM és un dels sistemes d’allotjament més estesos que hi ha. Es bassa en una sèrie de scripts (amb llicència privativa) que corren sobre una gran quantitat de sistemes (tant lliures com no).
cPanel no està preparat per suportar redundàncies o alta disponibilitat més enllà de poder configurar diversos servidors DNS per a les mateixes zones. Així i tot se’n pot millorar el seu comportament, per exemple, a l’apartat del correu electrònic.
Les distribucions de cPanel que corren sobre GNU/Linux usen exim com a MTA (servidor de correu) però ho fa de forma independent a cada servidor. A pesar de no estar publicat, però, cPanel està preparat per configurar-se com a servidor secundari de correu i així fer de backup d’altres servidors, siguin cPanel o no.
Fer que cPanel accepti el correu d’un domini concret és tant senzill com posar aquest nom de domini dins el fitxer /etc/secondarymx (un domini per línia). Ni tant sols és necessari reiniciar l’exim. Si el que volem és fer de servidor secundari de tots els dominis d’un altre servidor cPanel (cosa habitual), bastarà copiar el contingut del fitxer /etc/localdomains del primer a /etc/secondarymx del segon… i vice-versa si volem que ambdós facin de backup un de l’altre. Això es pot automatizar amb cron i un simple scp, per exemple.
Una vegada configurat, només és necessari posar la informació dels registres MX a les zones DNS dels dominis afectats. Sobre bind, per exemple…
domini.com. 14400 IN MX 10 mx1.domini.com.
domini.com. 14400 IN MX 20 mx2.domini.com.
La creació d’aquests registres es pot automatitzar en el moment de la creació del compte d’allotjament si editam les plantilles de DNS que té el cPanel. Per exemple…
%domain%. IN MX 10 %domain%.
%domain%. IN MX 20 mx2.domini.com.
%domain%. IN MX 30 mx-fake.domini.com.
(explic la darrera línia més endavant)
Una vegada configurat, els servidors de correu que ens vulguin entregar un missatge ho intentaran amb el servidor de major prioritat (10 en aquest cas) i en cas de no estar disponible per qualsevol motiu ho intentaran amb el següent (20, aquí). Quan el servidor principal torna estar disponible, el secundari (o secundaris) li entregarà els missatges que hagi anat recollint.
Com que el servidor secundari no té cap informació sobre quins usuaris de correu té cada domini només farà unes comprovacions bàsiques per evitar l’spam, com és la consulta de RBL si les tenim configurades, deixant la feina restant al servidor principal quan torni estar disponible.
Convé, també, afegir el servidor secundari a l’ACL de l’exim “** Whitelist: Backup Mail Hosts (bypass all smtp ratelimits)” perquè no quedi bloquejat en entregar una quantitat important de missatges de cop.
Si ho configurau així veureu tot d’una que el servidor secundari comença a rebre missatges quasi instantàniament a pesar de que el principal està disponible. Això és perquè molts spammers no envien els missatges al servidor de major prioritat fent la suposició de que els secundaris estan més descuidats i desprotegits.
Aquí podeu aplicar un mecanisme nou, que no aconsell explícitament però que funciona en certa mesura. Es tracta de configurar un tercer registre MX al DNS amb menor prioritat i que apunti a una direcció IP que controleu però que no respongui a les peticions SMTP (port 25/TCP). Així, en condicions normals, els servidors de correu ben configurats, els que ens entreguen missatges legítims, ho faran al primer servidor i al segon si el primer no està disponible… mentre que alguns spammers que ho intenten amb el de menor prioritat xocaran amb un tallafocs que no respondrà a cap de les seves peticions (DROP), fent-los perdre el temps esperant timeouts i desviant tot aquest tràfic molest dels servidors de correu reals.
No és que aquest mecanisme sigui plenament efectiu però ajuda. Per exemple, sobre un servidor sense gaire càrrega de feina i dominis, ha desviat més de 5000 peticions en 24h.
Esper que l’apunt vos sigui útil. S’agraeix qualsevol comentari.
novembre 21st, 2008 at 12:09
El Nolisting té una efectivitat (crec jo) bastant limitada. Molts de spammers els proven tots als MX.
Prefereixo el greylisting tot i els seus inconvenients. Encara que hi ha spammers que reintenten les connexions després del periode de greylisting, actualment encara són pocs i fa que l’efectivitat sigui bastant alta.
Si combines greylisting amb nolisting, millor que el fake-mx faci un REJECT a les peticions al port 25 perque si no estaras putejant bastant als servidors de correu “legítims”.
I sobre els servidors MX de backup, si no hi configures i sincronitzes les llistes d’usuaris acabaras amb una coa plena de missatges de rebot de spammers i altres alimanyes que proven usuaris del teu domini aleatoriament (et pot arribar a generar problemes bastant grossos al MX de backup).
novembre 21st, 2008 at 12:39
A jo també m’agrada més el graylisting, però no és fàcil implementar-lo al cPanel.
Els rebots eren una de les coses que me preocupaven però, amb les verificacions que fa el servidor de backup en rebre el missatge original (RBL, SPF, verificació del remitent…) la majoria queden descartats.
He vigilat la cua de l’exim i es manté estable i no gaire gran. Ja veurem com evoluciona.
Gràcies pels comentaris. :-)
novembre 21st, 2008 at 13:15
No, si la cua de l’exim la veuràs més o manco bé fins que a un spammer hdp se li ocorri enviar-te 10.000 missatges a usuaris inexistents des d’una ip no llistada a cap RBL i posant el meu domini com a remetent (que no publica registres SPF; perque el SPF està romput per disseny).
Aleshores veuràs la gràcia que li fa al teu exim i la que me fa a mi quan comenci a rebre rebots provinents del teu servidor.
I si en lloc de amb mí, topes amb una tercera víctima que cregui amb les RBL és més que probable que la teva ip acabi llistada a alguna d’aquestes blacklists.
novembre 21st, 2008 at 13:22
Per això hi ha els ratelimits. :-P
Kiko, està clar que no és una solució perfecta ni molt manco… però de moment soluciona el tema de no tenir MX de backup. Deixa passar alguns d’aquests missatges… però n’atura molts més.
novembre 21st, 2008 at 20:20
[...] en cPanel Noviembre 21st, 2008 by Suki_ Xisco Lladó me pasa un interesante texto donde explica como configurar un MX secundario en un cPanel / WHM. Gracias. Tags: Correo, Exim, [...]