Tengo ataques continuos contra mi servidor exim. Estoy intentando retrasar los intentos con la siguiente acl.
deny condition = ${if and {\
{>{$rcpt_count}{10}}\
{<{$recipients_count}{${eval:$rcpt_count/2}}} }}
delay = 5s
message = Rejected for too many bad recipients
logwrite = REJECT [$sender_host_address]: bad recipient count high [${eval:$rcpt_count-$recipients_count}]
.endif
Eso se retrasa una vez después de los primeros 10 intentos.
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [11]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [12]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
En cambio, quiero que retrase cada intento posterior. ¿Cómo puedo lograr eso?
Respuesta1
Me encontré con el mismo problema/pregunta e investigué y probé un poco.
Lo primero que necesita saber es que SMTP originalmente se basaba estrictamente en comandos-respuesta, lo que significa que el cliente puede enviar exactamente un comando al servidor y tiene que esperar la respuesta antes de poder enviar el siguiente. Debido a que ese ir y venir implica un poco de espera cada vez y, por lo tanto, crea latencia,RFC 2920Más tarde se introdujo "Canalización SMTP". Esto permite a un cliente enviar múltiples comandos en un lote al servidor, que los procesa y devuelve las respuestas. En exim, la disponibilidad de "Canalización SMTP" se puede controlar mediante la pipelining_advertise_hostsopción, que de forma predeterminada lo permite para todos. Supongo que este también es el caso de tu configuración.
Lo que creo que sucedió en su caso es que al cliente (también conocido como spammer) conectado a su servidor exim se le dijo que admite "canalización SMTP", por lo que envió un lote de 100 RCPT TO:comandos. Su servidor los recibió y comenzó a procesarlos, ejecutando la acl_smtp_rcptacl para cada destinatario. Los primeros 10 comandos arrojaron una 550 Unrouteable addressrespuesta cada uno, 550siendo unCódigo de error RFC5321significado Requested action not takenseguido de una razón legible por humanos. Ese motivo se puede establecer en exim con la messagedirectiva y también se imprime en el registro después de los dos puntos. Probablemente el cliente simplemente los ignoró; después de todo, está buscando destinatarios válidos.
Al procesar el undécimo comando/destinatario, la condición de su denyregla se evaluó como verdadera y exim se retrasa (duerme) durante 5 segundos; este es el único retraso que ves. Después de eso envía la 550 Rejected for too many bad recipientsrespuesta al cliente. Debido al motivo incluido (bien conocido), el cliente detecta que cruzó la línea y ya no hay posibilidad de encontrar un destinatario válido; Todos los comandos siguientes también serán rechazados. Como ya no hay nada que valga la pena esperar/ganar, finaliza la conexión sin esperar el resto de las respuestas (y probablemente recurre inmediatamente a su próxima víctima). Si bien su servidor nota esto (porque se usa TCP), continúa procesando el lote de comandos. Pero debido a que la conexión SMTP con el cliente ya ha finalizado, no tiene sentido retrasarla más; el único que retrasaría es él mismo. Por lo tanto, se ignora el retraso y su servidor ejecuta los comandos hasta que finaliza todo el lote.
Si el cliente no finaliza la conexión, esto funcionaría como esperaba: el retraso de 5 segundos se aplicaría para cada destinatario después del día 10.
Suponiendo que lo anterior sea correcto, la mejor solución que se me ocurre es eliminar el motivo/mensaje predeterminado. Si el servidor simplemente continúa respondiendo con algo como 550 Unrouteable address, el cliente no tiene forma de saber que cruzó la línea y no puede abandonar. Dependiendo de cómo funcione el cliente, puede ser suficiente cambiarlo/reformularlo a algo diferente del valor predeterminado para que no se maneje de manera especial.
Alternativamente, puede desactivar la "canalización SMTP" en su servidor utilizando la opción mencionada anteriormente. El cliente probablemente aún abortará después de ver la undécima respuesta con el motivo revelador, y su servidor todavía solo se retrasa una vez, pero al menos no incluye a los otros 89 destinatarios fallidos en su registro. La desventaja obvia es que "ralentiza" a cada cliente, pero esto puede mejorarse un poco al habilitar la "canalización SMTP" solo para clientes seleccionados "buenos".
Y solo como nota al margen: el retraso no tiene por qué ser un valor estático, también puede ser una expresión. Esto permite implementar retrasos progresivos, donde cada destinatario no válido adicional lo hará más largo. el excelenteFiltrado de spam para intercambiadores de correoHowTo tiene un ejemplo de esto.