He notado un rápido aumento en las conexiones SMTP que llegan a mi servidor. Al investigarlo más a fondo, descubrí que hay una botnet atacando mi servidor SMTP. Intenté detenerlo agregando una regla en iptables:
-N BLOQUE SMTP -A BLOQUE SMTP -m límite --límite 1/m --limit-burst 3 -j LOG --aviso de nivel de registro --log-prefix "iptables SMTP-BLOQUE " -A SMTP-BLOQUE -m reciente --name SMTPBLOCK --set -j DROP -A ENTRADA -p tcp --dport 25 -m estado --state NUEVO -m reciente --name SMTPBLOCK --rcheck --segundos 360 -j SMTP-BLOCK - A ENTRADA -p tcp --dport 25 -m estado --estado NUEVO -m reciente --nombre SMTP --set -A ENTRADA -p tcp --dport 25 -m estado --estado NUEVO -m reciente --nombre SMTP --rcheck --segundos 60 --hitcount 3 -j SMTP-BLOCK -A ENTRADA -p tcp --dport 25 -m estado --estado NUEVO -j ACEPTAR
Eso evitaría que martillaran "demasiado rápido", sin embargo, el problema persiste, hay como 5 intentos por segundo, se está volviendo una locura, tuve que aumentar el número máximo de hijos de sendmail/dovecot. Hay demasiadas direcciones IP para filtrar manualmente y simplemente cambiar el SMTP a otro puerto no es práctico ya que tengo muchos otros clientes en ese servidor.
Estoy usando sendmail con dovecot, ¿alguna idea para filtrar esto de manera más eficiente?
Respuesta1
Mi inclinación sería asegurarme de tener hosts MX de respaldo que estén a bordo; luego bloquee el acceso a su puerto 25 desde todas las máquinas que no sean sus hosts MX de respaldo. El correo legítimo entrante se entregará al host MX de respaldo, que podrá entregárselo; pero el correo entrante que no esté destinado a su sistema y que provenga de un host en buen estado no irá a ninguna parte.
(El "host MX de respaldo" podría incluso ser otra máquina suya, o incluso una máquina VPS/en la nube que alquile por horas durante unos días).
No entre en una carrera armamentista con una botnet: puede agregar tráfico más rápido de lo que usted puede agregar ancho de banda y servidores.
Parece que tal vez tengas muchos clientes/dominios en una máquina, lo que genera más trabajo. Lo siento.
Podría considerar mudarse a una nueva dirección IP y/o cambiar el registro A del host atacado a 127.0.0.1 y encontrar un nuevo nombre para el servidor; existe una probabilidad razonable de que los spammers pasen a otra víctima y dejen su nueva dirección IP. nombre de host/dirección IP solo.