correo electrónico - tareas #5517 - proyectos de la ... · trabajar en conjunto para configurar...
TRANSCRIPT
Correo electrónico - Tareas #5517
Explorar configuraciones para evitar bombas de mails
11/17/2016 12:03 PM - Andrés Pías
Status: En curso Start date: 11/17/2016
Priority: Urgente Due date:
Assignee: Daniel Viñar Ulriksen % Done: 50%
Category: Estimated time: 0.00 hour
Target version: Spent time: 0.50 hour
Description
Sería bueno explorar alguna configuración para aplicar en Zimbra para evitar que un usuario pueda mandar más de un determinado tope
de mails por vez para evitar que caigamos en spam.
Related issues:
Related to Correo electrónico - Soporte # 5800: Nuevamente problemas de envío... En curso 09/13/2017
Related to Correo electrónico - Tareas # 4087: Configurar en el servidor sant... En curso 02/19/2015
History
#1 - 09/21/2017 12:13 PM - Andrés Pías
- Priority changed from Normal to Urgente
Cada vez se hace mas necesario solucionar esto:
Monitorizar las colas de correo para limitar el volumen de mensajes por minuto/hora/dia....
Trabajar en conjunto para configurar Godel para que cuando se supere un determinado número de correos, se avise y se corte el servicio.
#2 - 09/21/2017 12:20 PM - Andrés Pías
- Related to Soporte #5800: Nuevamente problemas de envío de mails desde CUP a Hotmail added
#3 - 09/22/2017 04:55 PM - Andrés Pías
- Status changed from Nueva to En curso
La solución para detener las bombas de mails desde el propio Zimbra parece estar en activar y configurar Policyd
Lo pobramos directo en Godel?
#5 - 10/02/2017 11:30 AM - Andrés Pías
- Related to Tareas #4087: Configurar en el servidor santateresa la conexión de Zimbra a LDAP added
#6 - 10/02/2017 07:37 PM - Daniel Viñar Ulriksen
Se trata de un módulo externo, Cluebringer Policy Daemon, que el zimbra integra a su MTA Postfix.
Esta es la página oficial, la wiki de zimbra y otra página de esa wiki.
#7 - 10/02/2017 08:09 PM - Daniel Viñar Ulriksen
Probemos activar cbpolicyd en dirac. Está bien documentado acá.
10/10/2018 1/7
Con el usuario zimbra:
zimbra@dirac:~$ zmprov ms dirac.csic.edu.uy +zimbraServiceEnabled cbpolicyd
Como root:
cd /opt/zimbra/httpd/htdocs/
ln -s ../../cbpolicyd/share/webui .
Y reiniciamos el servicio. Como root:
service zimbra restart
Y ahí, conectándonos por un tunel:
ssh -L 7780:dirac:7780 [email protected]
Podemos ver la WebUI de la cbpolicyd: http://localhost:7780/webui/index.php, aunque a´un falta configurar la base, parece.
#8 - 10/02/2017 10:50 PM - Daniel Viñar Ulriksen
- % Done changed from 0 to 10
Un sysadmin que tuvo la misma problemática que propone un script que avisa del crecimiento de las colas,
Creo que podemos adaptar eso a la Ubuntu en la que están godel y dirac, mejorarlo, y usarlo.
#9 - 10/02/2017 11:04 PM - Daniel Viñar Ulriksen
Probemos activar cbpolicyd en dirac.
Faltaba configurar la base:
root@dirac:~# cat /opt/zimbra/cbpolicyd/share/webui/includes/config.php
<?php
# mysql:host=xx;dbname=yyy
#
# pgsql:host=xx;dbname=yyy
#
# sqlite:////full/unix/path/to/file.db?mode=0666
#
#$DB_DSN="sqlite:////tmp/cluebringer.sqlite";
# $DB_DSN="mysql:host=localhost;dbname=cluebringer";
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
10/10/2018 2/7
#$DB_PASS="";
$DB_TABLE_PREFIX="";
#
# THE BELOW SECTION IS UNSUPPORTED AND MEANT FOR THE ORIGINAL SPONSOR OF V2
#
#$DB_POSTFIX_DSN="mysql:host=localhost;dbname=postfix";
#$DB_POSTFIX_USER="root";
#$DB_POSTFIX_PASS="";
?>
Luego de esta configuración y de reinicio, todo parece fncionar bien y vemos cbpolicyd entre los servicios desde la consola de admin zimbra.
#10 - 10/09/2017 05:14 PM - Daniel Viñar Ulriksen
Para ordenar los procedimientos, creé esta wiki: [[Políticas_de_regulación_de_cantidad_de_mails]]
#11 - 10/09/2017 07:51 PM - Daniel Viñar Ulriksen
- Assignee changed from Andrés Pías to Daniel Viñar Ulriksen
#12 - 10/09/2017 11:04 PM - Daniel Viñar Ulriksen
Sigamos a justin Bachus, pero no ciegamente.
throtteling
Sugiere primero:
# immediately fail messages to over quota inboxes
zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE
Pero analizando ese parámetro no parece oportuno hacer esa configuración. Preferimos la configuración por omisión de zimbra: Zimbra Collaboration, by
default, saves email for 5 days if the quota of a mailbox is exceeded. Zimbra then sends the email to the recipient if (during this time) the mailbox has
space.
Esa misma página dice: This can be a huge a problem if you have thousands of mailboxes. No tenemos miles de casillas. Tenemos 811 en
[[servidores:Godel|Gödel]] y menos en [[servidores:Dirac|Dirac]].
Tampoco veo bien porqué hacer esta configuración:
# retrying bounced messages for 5 days is excessive
zmlocalconfig -e postfix_bounce_queue_lifetime=1d
podemos esperar 5 días que una entidad suba su servidor de correos caido...
Sí hacemos esta configuración que luego será necesaria:
root@dirac:~# su - zimbra
zimbra@dirac:~$ # I want to see the SASL username in the headers
zimbra@dirac:~$ zmlocalconfig -e postfix_smtpd_sasl_authenticated_header=yes
“reject_non_fqdn_sender” y “reject_unknown_sender_domain” ya los tenemos habilitados, así como las RBL recomendables (fuente: wiki zimbra).
#13 - 10/10/2017 11:51 AM - Daniel Viñar Ulriksen
10/10/2018 3/7
- % Done changed from 10 to 50
Con #5517#note-12, #5517#note-7 y #5517#note-9 (en ese orden) queda configurada cbpolicyd
Conectándonos con un tunel, llegamos a la interfaz de configuración: http://localhost:7780/webui/index.php
Esta interfaz es particular: permite manipular registros y, para cada registro, "miembros" o "limites" que son registros en una tabla enlazada.
Queda configurar los límites. En esta interfaz:
- completamos los miembros de los "groups" internal_ips e internal_domains
- dejamos enabled sólo las Policy Default y Default outbound,
- creamos una cuota Sender:user@domain, con un límite de 200 mails por hora.
Acá hay un ejemplo de configuración.
#14 - 10/10/2017 06:08 PM - Daniel Viñar Ulriksen
Ahora conviene hacer un script que manda muchos mails para probar que se activen las reglas de throttling.
Utilizamos de nuevo la solución de script que propone Justin Bachus. Este página también explica como mandar un mail con mailx
El utilitario email, que utiliza en Redhat, no existe en la Ubuntu. Bachus tambien identifica mailx y ssmtp.
ssmtp es incompatible con zimbra-mta que está instalado en el servidor. Hay varias iomplementaciones de mailx. La que hay que instalar es la del paquete
heirloom-mailx. Con esta podemos hacer un script que manda un mail:
#!/bin/sh
## Envio de correo desde script
EMAIL_SUBJECT="Prueba de envio"
FROM_EMAIL_ADDRESS="[email protected]"
FRIENDLY_NAME="Servicio de correo UdelaR"
AUTH_EMAIL_ADDRESS="[email protected]"
EMAIL_ACCOUNT_PASSWORD="********"
TO_EMAIL_ADDRESS="[email protected]"
mailx -v -s "$EMAIL_SUBJECT"\
-S smtp-use-starttls\
-S ssl-verify=ignore\
-S smtp-auth=login\
-S smtp=smtp://localhost:587\
-S from="$FROM_EMAIL_ADDRESS($FRIENDLY_NAME)"\
-S smtp-auth-user=$AUTH_EMAIL_ADDRESS\
-S smtp-auth-password=$EMAIL_ACCOUNT_PASSWORD\
-S ssl-verify=ignore \
$TO_EMAIL_ADDRESS
Y otro que manda muchos mails:
!/bin/sh
## enviarme 300 mails
for i in `seq 1 300`; do
10/10/2018 4/7
cat mail.txt | ./enviar_mail_local
done
#15 - 10/10/2017 07:06 PM - Daniel Viñar Ulriksen
Con el script me envío 300 mails en minutos, después del inicio manda más de 30 mails por minuto.... pero los recibo todos perfecto, ninguno va a la cola
hold :(
Algunas verificaciones:
# su - zimbra
zimbra@dirac:~$ zmprov gs dirac.csic.edu.uy | grep zimbraCBPolicyd
zimbraCBPolicydAccessControlEnabled: FALSE
zimbraCBPolicydAccountingEnabled: FALSE
zimbraCBPolicydAmavisEnabled: FALSE
zimbraCBPolicydBindPort: 10031
zimbraCBPolicydBypassMode: tempfail
zimbraCBPolicydBypassTimeout: 30
zimbraCBPolicydCheckHeloEnabled: FALSE
zimbraCBPolicydCheckSPFEnabled: FALSE
zimbraCBPolicydGreylistingBlacklistMsg: Greylisting in effect, sending server blacklisted
zimbraCBPolicydGreylistingDeferMsg: Greylisting in effect, please come back later
zimbraCBPolicydGreylistingEnabled: FALSE
zimbraCBPolicydGreylistingTrainingEnabled: FALSE
zimbraCBPolicydLogLevel: 3
zimbraCBPolicydMaxRequests: 1000
zimbraCBPolicydMaxServers: 25
zimbraCBPolicydMaxSpareServers: 12
zimbraCBPolicydMinServers: 4
zimbraCBPolicydMinSpareServers: 4
zimbraCBPolicydQuotasEnabled: TRUE
zimbraCBPolicydTimeoutBusy: 120
zimbraCBPolicydTimeoutIdle: 1020
Em particular, las cuotas están enabled.
Puedo reiniciar el servicio, para asegurarnos que tome la última configuración:
zimbra@dirac:~$ zmcbpolicydctl restart
Stopping policyd... done.
Starting policyd... done.
Si bien "acá": dice: Currently the only supported way of configuring policyd is through the CLI. The policyd gui that comes with the package is not
supported., miramos la base de atos con mysql y está bien configurada.
#16 - 10/10/2017 09:07 PM - Daniel Viñar Ulriksen
10/10/2018 5/7
En la interfaz http://localhost:7780/webui/index.php, OjO: todos los objetos que se crean tiene un parámetro "diabled" a "yes"- Hay que volver uno por uno
a los objetos y subobjetos (members, limits,...) para habilitarlos.
#17 - 10/11/2017 05:09 PM - Daniel Viñar Ulriksen
Algunas cosas que probé:
- primero procuré implementar 4 reglas de cuota:
- no más de 20 msg por min para cada remitente (Sender:user@domain)
- no más de 20 msg por min para cadausuario autenticado (SASLUsername)
- no más de 200 msg por hora, para las mismas condiciones.
Si pongo estas cuatro cuotas en la policy "default" (from any to any), zimbra se pone bastante lento. Se nota claramente en el script de envío.
Dejo por ahora sólo las reglas por minuto.
- Poniendo sólo una cuota de 20 mensajes por minutos por dirección remitente, funciona:
Cuando mando 300 mensajes con un script, 173 terminan en la cola de retenidos.
- La cuota SASLUsername también identifica los mensajes NO autenticados, en los log aparece: track=SASLUsername:, conviene ver cómo hacer
para que la Policy filtre los mensajes no autenticados.
- con la cuota de 20msg/min en la policy default, en el día puso en retención 5 mensajes de listas (todos@csic).
#18 - 10/11/2017 05:19 PM - Daniel Viñar Ulriksen
OjO: Las listas mandan los mensajes siempre con el mismo remitente, y terminan retenidas:
En /opt/zimbra/log/cbpolicyd.log:
[2017/10/11-10:54:09 - 8212] [CORE] INFO: module=Quotas, action=hold, host=164.73.68.14, helo=russell.csic.edu.uy,
[email protected], [email protected], reason=quota_match, policy=1, quota=5, limit=5,
track=Sender:[email protected], counter=MessageCount, quota=21.00/20 (105.0%)
Vemos el tracking llenarse:
[2017/10/11-10:53:42 - 20387] [CORE] INFO: module=Quotas, mode=update, host=164.73.68.14, helo=russell.csic.edu.uy,
[email protected], [email protected], reason=quota_update, policy=1, quota=5, limit=5,
track=Sender:[email protected], counter=MessageCount, quota=19.34/20 (96.7%)
Y luego de este todos siguen con "action=hold"
#19 - 10/18/2017 10:59 PM - Daniel Viñar Ulriksen
Bueno, aún tenía un problema de cuota "disabled"...
Las políticas exactas de retención y/o retraso de correos con cbpolicyd requiere diseño y análsis. Empecemos simple y vayamos analizando y
reconfigurando en función de lo que resulte.
En las pruebas que hicimos, nos dimos cuenta que 20 correos por minuto es demasiado fuerte: las listas de correos a las que están inscriptos más de 20
10/10/2018 6/7
correos del servidor mandan más que eso con el mismo remitente.
Los usuarios internos pueden mandar, autenticados, varias decenas de copias de un mismo mail. ¿Debe ser retenido por la política un correo con 20
destinatarios?
Para empezar: el problema que se planteó: alguien usurpó las credenciales de la cuenta y las usa para spamear a través de nuestro servidor. colas de
varios miles de correos diferidos.
Empecemos entonces por una regla: filtramos solamente los correos autenticados (cuota de tipo: SASLUsername) y debemos permitir cierta cantidad, por
cierta unidad de tiempo, que no sea restrictiva para los mensajes legítimos de los remitentes internos, pero que sí detecte los envíos de spam por una
cuenta usurpada.
Considerando que a partir de unas decenas de destinatarios se recomienda hacer una lista, consideremos envíos de hasta cien destinatarios o en copia.
Permitamos algunos correos por unidad de tiempo, por ejemplo 3. Empecemos por un límite de 300 correos.
¿En qué unidad de tiempo? Haciendo pruebas constatamos que un script puede mandar hasta un poco más de 30 mensajes por minuto. Contemos 20
por minuto por poder ser mensajes más grandes. Se necesitan 15 minutos para mandar esos mensajes. Seamos generosos: 30 minutos.
Primer regla: retener (hold) los mensajes que manda un mismo usuario autenticado más allá de 300 mensajes cada 30 minutos (1800 segundos)
OjO: la cuota se aplica a todos los mensajes, incluyendo los que no estén autenticados si la política (policy) utilizada los permite. Por ende, en la política
que utilizamos, debemos filtrar en un member, en el "source", los usuarios autenticados con: $*.
A esa política se aplica una cuota que filtra en un período de 1800 segundos, a la cual está asociada un limit de 300 mensajes.
10/10/2018 7/7