Ip bloqueada por spam – Taller Linux
Uno de los problemas más comunes actualmente en el uso del correo electrónico es la posibilidad de que los emails que mandamos no lleguen a los destinatarios o entren en su carpeta de correo no deseado o “spam”. Esto normalmente es debido a que nuestro sistema de correo tiene su ip bloqueada por spam en las numerosas listas negras DNS o DNSBL que hay por Internet.
De este problema normalmente nos enteramos porque algunos correos vienen devueltos con un mensaje que hace referencia a una lista negra y nuestra Ip.
En los hosting compartidos, cuando nosotros no tenemos control sobre el servidor de correo no queda otra que avisar a los administradores para que lo revisen, pero si el problema está en nuestro servidor será necesario que nosotros nos hagamos cargo o bien busquemos ayuda especializada para resolverlo.
En esta entrada vamos a explicar cuales son los pasos que se deben seguir para trazar y resolver las incidencia de este tipo, aunque como siempre nos ceñiremos a los casos más comunes.
1. ¿La Ip está listada o tiene baja reputación?
En la red existen gran cantidad de páginas dedicadas a mostrar cuando una ip está listada por alguna DNSBL o que son útiles para determinar si tiene baja reputación de envío. Por poner ejemplos podemos citar:
– Te permite revisar una ip contra un listado extenso de las más importantes DNSBL.
– Igual que la anterior pero tiene casi todas las listas que existen.
– Te ofrece una puntuación a la IP en base a los correos enviados en los últimos 30 días, es muy utilizada.
– Permite revisar las listas mas importantes y ademas ofrece ejemplos de correos ilegítimos enviados desde la ip a su red de SPAMTRAPS.
2. ¿Nuestro servidor está enviando SPAM?
Una vez que ya tenemos claro el punto anterior podemos pasar al siguiente, que es clave ya que como dice el proverbio “cuando el rio suena es que agua lleva” y si suena en nuestro caso probablemente es porque se ha estado enviando spam y del malo.
Para ello lo primero que debemos hacer es revisar la cola de salida de nuestro MTA (servicio de correo), ya que los spammers que abusan de los sistemas ajenos suelen enviar enormes cantidades de correos rwtgvnu find out here. En estos envíos masivos los destinatarios muchas veces no existen o directamente son rechazados por filtros antispam bien configurados, y por tanto seguirán en la cola de salida siendo retrasados, a veces incluso bloqueando el correo legitimo. Estos correos nos permitirán determinar de una forma rápida e inequívoca si el correo es ilegitimo e incluso identificar al emisor.
Al revisar la cola uno de los primeros indicadores que debemos ver es la cantidad de correo saliente. En un servidor saludable no muy grande no debería haber más que unos pocos correos a la espera de ser entregados, si vemos un numero elevado ya podemos empezar a sospechar. Debemos también mirar con lupa el origen de los mensajes y si es posible el asunto que tienen. Si vemos cuentas de origen que no existen en nuestro servidor, o asuntos inequívocamente falsos deberemos revisar su contenido y así ya tendremos el primer punto completado. En un futuro ofreceremos una entrada con los detalles para efectuar este proceso en los servidores de correo más utilizados.
Si en la cola no hay evidencias claras también podemos revisar el log de correo de nuestro servidor, que tiene un registro de todo lo que ocurre aunque no contiene detalles como el asunto o la posibilidad de ver el mensaje, por esto hemos mirado primero la cola. Allí podremos utilizar comandos como cat, grep, wc, sort, uniq, etc .. para tratar de sacar listados que nos muestren un comportamiento anómalo y así poder identificar al emisor.
En el peor de los casos es posible que los spammers utilicen un programa que incluya internamente su propio servicio de correo, con lo que no aparecerán los mensajes en nuestra cola de correo o en el log. Estos casos los detectaremos porque nuestra IP estará constantemente listada, e incluso en algunas paginas podremos ver los correos enviados a los SPAMTRAPS, pero no habrá nada en la cola y el log.
Para finalizar este punto, con la anterior revisión ya nos tendría que quedar claro si nuestro servidor está siendo utilizado ilícitamente o por el contrario el problema viene de envíos publicitarios demasiado agresivos. Si se debe a esto último podemos pasar directamente a la sección de limpieza de IP y de paso revisar nuestro articulo sobre buenas practicas enviando correo. En caso contrario podéis seguir leyendo porque os vamos a explicar como detectar la cuenta pirateada o script de envío y resolver el entuerto.
3. Detener el envío de SPAM
Siguiendo los puntos anteriores, una vez tenemos claro que se está abusando del servidor, lo principal es detener la salida de correo externa hasta que hayamos neutralizado la fuente de los problemas, borrando los mensajes ilícitos en cola que pudieran quedar.
Dependiendo de que servidor de correo se esté utilizando (Postfix, Qmail, Sendmail, etc..) hay varias maneras de hacer esto, pero una muy sencilla y efectiva, sea lo que sea tengamos instalado, es cortar la salida al puerto 25 en nuestro firewall. Esto es bueno por varios motivos, uno porque es igual para todos y muy sencillo, dos porque se siguen pudiendo recibir y entregar correos de forma local, y tres nos aseguramos que los correos legítimos que se quieran salir a fuera no se perderán o rebotarán, ya que se quedarán en la cola intentando salir hasta que expire el tiempo asignado para los reintentos, que pueden ser varios días.
En el caso que no tengamos una interfaz gráfica para ello siempre podemos llamar a iptables directamente con está linea:
/sbin/iptables -A OUTPUT -p tcp --dport 25 -j DROP
Para asegurarnos de que no hay conexión con el exterior, podemos hacer un telnet a un servidor de correo remoto. Primero buscamos cual es el servidor Mail eXchange de por ejemplo gmail con una consulta “dig”:
[root@server ~]# dig mx gmail.com +short 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 5 gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com.
Cogemos la entrada mx con mayor prioridad (número menor) y lanzamos el telnet al puerto 25:
[root@server ~]# telnet gmail-smtp-in.l.google.com. 25 Trying 173.194.66.26...
Si no pasa de ahí es que ha funcionado, ya tenemos el envío de correo saliente bloqueado temporalmente.
4. Determinar y neutralizar la fuente del abuso.
En este punto deberemos revisar los logs de correo, la cola de envío, buscar ficheros modificados recientemente, etc.. cualquier cosa que nos indique si el envío proviene de una cuenta smtp cuya seguridad ha sido comprometida o de un script malicioso de alguna web, o mucho peor, del propio sistema con permisos de administrador.
En la revisión de logs, como hemos comentado antes es importante utilizar herramientas que nos permitan contabilizar el numero de entradas por ip, por cuenta de origen, por id del usuario, etc.. para poder visualizar el comportamiento anómalo. En la cola de envío si se da la suerte que tenemos acceso al cuerpo de un mensaje ilícito podremos buscar pistas que nos lleven a algún host infectado alojado en nuestro servidor, o incluso si configuramos correctamente php nos puede mostrar el nombre del script utilizado.
Cuando ni en el log ni en la cola hay evidencias claras, nos tocará buscar ficheros infectados, siendo entonces útil la herramienta “find”, buscando por el tiempo de modificación y por tipos de fichero ejecutables, como .php .js .html, etc.. La sintaxis exacta para las webs alojadas en “/var/www” y con 10 días de antiguedad sería:
find /var/www/ -type f -mtime -10
Pasar un antivirus libre como clamav por todos los ficheros también ayuda. Si el problema viene de una cuenta de correo smtp deberéis cambiar la contraseña y avisar a su usuario para que limpie su equipo y utilice una contraseña mas robusta. Si por un fichero web habrá que determinar si ha sido subido por una vulnerabilidad en el código o mediante una cuenta ftp pirateada, para la cual habría que tomar las mismas medidas que con la cuenta smtp.
Las posibilidades son muy amplias para abarcarlas en un post, os dejamos a vosotros la tarea de detectar la forma de inyección del correo malicioso y neutralizarla, o si no siempre podéis buscar ayuda profesional.
5. Limpiar la cola de correo.
Una vez la amenaza este neutralizada tocará reparar los daños. Primero antes de permitir el envío de nuevo se deberá limpiar la cola de correo por si quedasen emails. Para esto cada servidor de correo dispone de unas herramientas especificas, permitiendo buscar por un nombre en las cabeceras de cada mensaje y eliminarlos de forma selectiva, para no afectar al correo legitimo.
6. Limpiar la Ip y reactivar el envío.
Por último, una vez la amenaza este neutralizada y el sistema limpio ya podremos reactivar la salida. En caso de que la IP haya sido catalogada como spammer tocará acceder a cada una de las DNSBL que la tengan y seguir los pasos necesarios para solicitar su exclusión. Normalmente este proceso es gratuito aunque hay algunas listas que piden un importe para agilizar el tramite, nosotros no recomendamos pagar ya que existen formas de permitir enviar sin verse afectado por el bloqueo, y ademas no vemos ético que intenten lucrarse de esta forma.
Por ejemplo es posible redirigir el trafico de correo saliente desde nuestro servidor hacia otro servidor relay, que pondrá su IP para que nosotros podamos entregar el correo, o también es posible añadir una IP extra a nuestro servidor e indicarle a nuestro servicio de correo que envíe con ella.
Para solicitar la exclusión de la IP en una lista DNSBL lo primero que hay que comprobar es si dicha IP tiene la resolución inversa configurada, si no normalmente nos será denegada la petición. Esto es que su reverso sea un nombre identificable y no el genérico facilitado por el proveedor o que no tenga. Para esto primero debemos acceder al panel del proveedor de la ip (normalmente el del servidor), y en su configuración encontraremos seguro esta opción. Lo ideal es utilizar un nombre con un subdominio que siempre debe estar ya apuntando a dicha ip.
Por ejemplo una ip que sea “123.123.123.123” y aloje los servicios del dominio “ejemplo.com” le podríamos llamar “servidor.ejemplo.com” y a su vez, esta entrada DNS tipo A debería apuntar a 123.123.123.123, completando el circulo.
Con esto damos por finalizada esta entrada, esperamos que os haya sido de utilidad, cualquier duda o consulta como siempre no dudéis en transmitírnoslo añadiendo un comentario, email o rellenando nuestro formulario de contacto.
Un saludo!
En ocasiones nos encontramos con que los servicios de nuestro servidor han dejado de responder o lo hacen mal. Un causa bastante común de esto es que el disco duro se ha quedado sin espacio, y esto hace que por ejemplo mysql deje de servir consultas, con lo que ya la tenemos liada.
En esta semana en Taller Linux vamos a explicaros las formas más comunes de detectar fallos de hardware y como tratarlos en un servidor linux al cual no tenemos acceso físico. Primero para clarificar mejor vamos a definirlos en dos categorías. A los problemas que hacen que un sistema no esté online, es decir no tenemos acceso a los servicios o SSH los llamaremos de tipo A. Y las incidencias donde el sistema aun está online y podemos acceder por SSH, pero por ejemplo de vez en cuando se reinicia, o se caen servicios, etc.. a estos los llamaremos de tipo B.
