Qué significa una denuncia de abuso contra tu VPS

Qué es realmente una denuncia de abuso contra un VPS

Una denuncia de abuso contra un VPS es un informe sobre tráfico que salió de tu dirección IP, se envió al contacto de abuso publicado para ese bloque de IP y después tu proveedor de alojamiento te lo remitió con un plazo para responder. El contacto publicado pertenece a la empresa que tiene asignado ese espacio de direcciones, por lo que casi nunca eres tú la primera persona que lee un informe sobre tu servidor. Tu proveedor relaciona la IP y la marca de tiempo con tu cuenta y te lo reenvía.

El aviso no demuestra que hayas hecho nada de forma intencionada. Una dirección IP es el único identificador del que dispone quien presenta el informe. Una aplicación comprometida que envía spam a las 03:00 genera el mismo informe que una persona que envía spam a las 03:00. Por eso, la respuesta es lo importante. Te piden que indiques cuál fue el origen y qué cambios aplicaste.

Quién envía el informe y cómo llega a su host

Cada bloque de IP pública está registrado en un registro regional de Internet (RIR): RIPE NCC, ARIN, APNIC, LACNIC o AFRINIC. Cada registro publica un contacto de abuso. Los informes se envían a esa dirección. Puede consultar el mismo registro que consulta quien envía el informe:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

Los registros de RIPE contienen un objeto de rol abuse-c: con una línea abuse-mailbox:. Los registros de ARIN contienen OrgAbuseEmail:. La dirección que aparece publicada allí recibe la reclamación. Por eso un informe sobre su servidor llega a su host y no a su bandeja de entrada.

Normalmente, quien presenta el informe es una máquina. Cuatro tipos abarcan casi todos los casos:

• Escáneres automatizados y honeypots. Una máquina registra un intento de conexión desde su IP y presenta un informe con el fragmento del registro adjunto.
• Bucles de comentarios (FBL) gestionados por proveedores de buzones. Un destinatario hace clic en el botón de correo no deseado y una copia del mensaje vuelve en ARF (abuse reporting format), un formato de correo estructurado para que las máquinas puedan analizarlo.
• Agentes de derechos de autor. Supervisan enjambres de torrents o rastrean URL públicas. Después envían un aviso DMCA (digital millennium copyright act) que identifica un archivo, su IP y una marca de tiempo en UTC.
• Operadores de blocklists e ingenieros de redes. Envían un correo breve con las líneas problemáticas de sus propios registros.

Como la mayoría de los primeros informes se generan automáticamente, discutir en la respuesta no sirve de nada. Los hechos sí sirven: qué estaba en ejecución y cuándo dejó de estarlo.

Por qué llega el aviso con un plazo

Su host también es un inquilino. Su espacio de direcciones está detrás de operadores ascendentes y dentro de bases de datos de reputación administradas por terceros. Los informes que quedan sin respuesta aumentan la puntuación negativa de todo el bloque, no sólo la de su dirección. Por eso recibe un plazo: es una medida de presión que se transmite hacia abajo. Lea el plazo indicado en el aviso y trátelo como real.

Cuando un caso sin respuesta llega a alguna consecuencia, normalmente se aplica una ruta nula, es decir, se descarta el tráfico dirigido a esa IP en un operador ascendente, o se suspende la instancia. El desencadenante suele ser el silencio, no el incidente original. Las medidas que puede tomar un host concreto y el momento en que se aplican están definidos en su propia política y en el aviso. Esos dos documentos son los únicos que conviene citar. No actúe basándose en lo que un foro afirma que permite un proveedor.

Spam saliente: por qué mi VPS envía correo que no he enviado

El informe indica que su IP entregó correo a una trampa de spam o que los destinatarios marcaron sus mensajes como correo no deseado. Cuatro fuentes explican la mayoría de los casos: una aplicación web con un formulario de correo y sin límite de tasa, una credencial SMTP filtrada que otra persona está usando, un servidor de correo que retransmite para hosts que no debería y un acceso robado a una aplicación de boletines. Empiece por la cola, porque un remitente comprometido normalmente se puede identificar allí:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Una cola con miles de mensajes dirigidos a direcciones que no reconoce significa que el equipo está enviando correo. A continuación, averigüe quién se autenticó:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

Una cuenta con un recuento muy superior al de las demás es la credencial filtrada. Si /var/log/mail.log no existe, el sistema no tiene rsyslog instalado y las mismas líneas están en el journal: sudo journalctl -t postfix --since '2 days ago'.

Si nadie se autenticó, el remitente es un proceso local. Compruebe las reglas de retransmisión y las conexiones abiertas:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Un Postfix estándar de Debian o Ubuntu no retransmite correo para usuarios externos. Se convierte en un open relay cuando mynetworks se amplía manualmente a toda una subred de hosting, porque entonces se confía en todos los demás tenants de esa subred para enviar correo a través de su servidor. Cualquier conexión al puerto 25 cuyo propietario sea un proceso que no sea su servidor de correo indica que un script está enviando correo por su cuenta. Esto es lo que suele hacer una aplicación PHP comprometida.

Detenga el flujo antes de investigar y conserve las pruebas:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL vacía la cola y también destruye el registro de lo que se envió, así que haga primero la copia. Después, rote todas las credenciales que utilice la aplicación, actualice la aplicación y busque lo que dejó el intruso. Un incidente de spam y una intrusión suelen ser el mismo evento, así que siga los pasos de recuperación de un VPS comprometido en lugar de limitarse a vaciar la cola.

Escaneo de puertos y fuerza bruta: cómo es un contenedor comprometido

Este informe contiene líneas de los registros de otro operador. Tienen este aspecto:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

La causa casi siempre es un servicio que creía protegido por un firewall. Docker es el caso más frecuente. Publicar un puerto con -p 6379:6379 escribe reglas en las cadenas DOCKER-USER y nat. Estas se evalúan antes que las reglas de ufw, por lo que ufw deny 6379 no lo bloquea y la base de datos responde a todo Internet.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

Cualquier elemento de ss -ltnp enlazado a 0.0.0.0 o [::] está escuchando en la dirección pública. En su lugar, publique en la dirección de loopback, -p 127.0.0.1:6379:6379, cuando sólo el host necesite acceder al servicio. La decisión sobre si la base de datos debe ejecutarse en Docker o en el host es independiente. Ejecutar la base de datos en Docker o en el host explica las ventajas y desventajas.

Para comprobar si su propio equipo está realizando un escaneo ahora mismo:

sudo ss -tnp state syn-sent

Muchas conexiones semiabiertas hacia destinos distintos indican que hay un escaneo saliente en curso. Un registro del kernel que se llena con nf_conntrack: table full, dropping packet indica lo mismo desde otro punto de vista: algo está abriendo muchas más conexiones de las que este servidor debería abrir.

Recree un contenedor comprometido en lugar de intentar limpiarlo. No puede demostrar qué más se modificó dentro de él. Por tanto, recréelo a partir de una imagen de confianza, restaure sólo los datos en los que confíe y rote las claves que tenía el contenedor.

Avisos de copyright: qué archivo vieron realmente

Un aviso de la DMCA incluye una URL o un hash de información de un torrent, tu IP y una marca de tiempo en UTC. Casi todos se deben a una de estas dos causas: un directorio que el servidor web publica con archivos multimedia, o un cliente de torrent que sigue compartiendo después de terminar la descarga.

Compara la marca de tiempo con el registro de acceso. El formato de registro combinado de nginx coloca el estado en el campo 9 y la ruta solicitada en el campo 7:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

Antes de concluir que no se sirvió ningún archivo, comprueba el reloj. El aviso usa UTC y tus registros usan la zona horaria del servidor. Por tanto, un desfase de varias horas hace que busques en la ventana temporal equivocada y comuniques un resultado falso negativo:

timedatectl
sudo timedatectl set-timezone UTC

Después, corrige la causa. Elimina o restringe el archivo, desactiva el listado de directorios con autoindex off; en el bloque location de nginx y vincula el cliente de torrent a una interfaz que no sea la pública. Responde indicando el archivo, el cambio y la hora en que lo aplicaste. Si crees que la reclamación es incorrecta, es una cuestión legal entre tú y el remitente, y el aviso indica cómo impugnarla. Tu proveedor no es quien decide sobre la reclamación, por lo que un ticket que discuta el fondo del asunto no llegará a ninguna parte.

Listas de bloqueo: por qué dejó de funcionar el correo saliente

Este problema suele aparecer sin que reciba ningún correo. El correo saliente deja de aceptarse y el rebote incluye el motivo:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

Compruebe si una IP aparece en una lista invirtiendo sus cuatro octetos y consultando la zona de la lista:

dig +short 10.113.0.203.zen.spamhaus.org

Una respuesta vacía significa que la IP no aparece en esa lista. Una respuesta 127.0.0.x significa que sí aparece, y el último octeto indica qué sublista coincidió. Una respuesta del rango 127.255.255.x significa que la consulta fue rechazada en lugar de responderse, normalmente porque salió a través de un resolvedor público grande que el servicio gratuito no atiende. Repita la consulta desde el resolvedor del propio servidor para obtener un resultado real.

La eliminación de la lista se solicita en el sitio web del operador, no a través de su proveedor de alojamiento, y sólo se mantiene si corrige primero el origen del problema, porque el mecanismo que provocó la inclusión volverá a incluirlo con el siguiente mensaje. Hay otros dos factores que determinan si el correo volverá a funcionar. El registro PTR, es decir, el nombre DNS inverso de la IP, lo controla su proveedor de alojamiento. Pídale que configure uno que resuelva de nuevo a la misma dirección y use ese nombre como HELO. Además, una dirección IP reciclada de un cliente anterior puede conservar un historial que usted no creó. Conviene preguntar por ello antes de pasar una semana reescribiendo la configuración DNS. La configuración correcta de los registros SPF (sender policy framework) y DKIM (domainkeys identified mail), junto con la política DMARC que los vincula, se explica de principio a fin en la guía para ejecutar su propio servidor de correo con Mailcow.

Infraestructura de retransmisión, donde atender los correos de abuso forma parte del trabajo

Si ejecuta un nodo de salida de Tor, una VPN pública o un proxy para otras personas, las quejas sobre tráfico que usted no generó son un coste operativo normal. El objetivo es que el servicio parezca claramente una retransmisión y no un servidor comprometido. Configure el DNS inverso con un nombre descriptivo, sirva una página breve de aviso en el puerto 80 que explique el uso de la dirección, responda rápidamente a los correos de abuso con la misma explicación y use las opciones de política que ofrezca el software para descartar los puertos que generan más informes. Ejecútelo en su propia dirección IP y, preferiblemente, en su propia instancia, de modo que una ruta nula para esa dirección no deje fuera de servicio su aplicación web. Consulte a su proveedor antes de empezar, porque lo permitido varía según la empresa y, en ocasiones, según el bloque de IP. Esa es una cuestión para el proveedor, no para un hilo de un foro. Ejecutar un nodo de salida de Tor en una VPS explica en detalle la política de salida y la página de aviso.

Cómo responder para cerrar el ticket

• Publique un contacto que una persona pueda leer. RFC 2142 establece abuse@ y postmaster@ en su dominio como las direcciones que los remitentes de informes prueban primero. Aloje ese buzón en un lugar distinto del servidor que protege, porque una instancia suspendida no puede entregar el aviso que informa de su suspensión.
• Conserve los registros durante el tiempo suficiente para poder responder. No se puede responder a un informe sobre tráfico de hace doce días si el registro se rotó después de siete. Compruebe journalctl --disk-usage, establezca MaxRetentionSec=90d en /etc/systemd/journald.conf y ejecute sudo systemctl restart systemd-journald. Los registros web y de correo se rotan según su propio calendario en /etc/logrotate.d/.
• Mantenga el servidor en UTC para que una marca de tiempo de un informe coincida con una marca de tiempo de los registros sin tener que hacer conversiones.
• Separe lo que atrae reclamaciones de lo que no puede perder. Aloje el correo en una dirección, la aplicación web en otra y los servicios de retransmisión en su propia instancia. Cualquier acción aplicada a una IP afecta a todo lo que haya detrás de ella.
• Responda dentro del plazo aunque la investigación no haya terminado. Una respuesta provisional con una hora concreta es una respuesta completa para la primera ronda.

Una primera respuesta que cierra la mayoría de los tickets es breve y específica:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

Indique lo que sabe y lo que todavía no ha podido determinar. El silencio parece indicar que el servidor no recibe mantenimiento, y la vía de escalado existe para los servidores sin mantenimiento. Que alguna de estas tareas le corresponda depende del producto que haya contratado. Esa es la diferencia práctica entre el alojamiento VPS administrado y no administrado. En un plan no administrado, el arrendatario forma el equipo de seguridad.

Cómo se ve cuando todo funciona bien

Una reclamación por abuso es, ante todo, un problema de enrutamiento. Un informe sobre una dirección llega a la parte responsable de esa dirección y se reenvía a la persona que puede solucionarlo. Los aspectos que controla son su dirección de contacto, la retención de registros, la forma en que distribuye los servicios entre las IP y la rapidez con la que responde. Si los configura correctamente, la mayoría de las notificaciones terminan después de un solo intercambio. Estos mismos hábitos resuelven la cuestión más amplia de si el alojamiento VPS es seguro, porque un servidor que nadie supervisa acaba en los registros de otra persona.

FAQ

¿Una reclamación de abuso significa que mi VPS fue vulnerado?

No por sí sola, pero es lo primero que debe descartar. El informe sólo demuestra que salió tráfico de su IP. El spam saliente y el escaneo de puertos suelen proceder de una aplicación o un contenedor comprometido, mucho más a menudo que del titular de la cuenta. Por eso, compruebe primero la cola de correo con sudo postqueue -p y los sockets en escucha con sudo ss -ltnp. Los avisos por derechos de autor y listas de bloqueo son diferentes: normalmente indican algo que está ejecutando de forma intencionada.

¿Cuánto tiempo tengo para responder a un aviso de abuso?

El plazo aparece en el aviso que recibió y varía según el proveedor y la categoría. Los informes sobre derechos de autor y spam traps suelen tener los plazos más cortos. Trate el plazo indicado como real y envíe una respuesta breve de seguimiento antes de que venza, aunque todavía esté investigando la causa. Para la persona que gestiona el ticket, lo importante es que alguien se esté ocupando del caso y que el tráfico se haya detenido.

Mi IP está en una lista de bloqueo. ¿Puede mi proveedor eliminarla?

No. La eliminación de una lista la realiza el operador de esa lista en su propio sitio, y su proveedor no controla su base de datos. Su proveedor sí controla el registro PTR, es decir, el nombre DNS inverso de su IP. Por tanto, conviene solicitarlo por separado al mismo tiempo. Solucione el problema de envío antes de solicitar la eliminación de la lista, porque el spam trap que incluyó su IP volverá a incluirla en el siguiente mensaje.

¿Tengo que informar a mi proveedor de lo que ocurrió exactamente?

Debe informar de lo suficiente para cerrar el ticket: cuál fue el origen y cuándo se detuvo. No tiene que entregar un informe forense ni los datos de sus usuarios. Una respuesta imprecisa es peor que una respuesta breve, porque la persona que gestiona el caso no puede considerar resuelto un problema si no sabe qué cambió.

¿Puedo ignorar un informe automatizado de un escáner?

No. Los informes automatizados se contabilizan, y los informes repetidos sobre una IP elevan la puntuación de todo el bloque de direcciones de su proveedor. Eso es lo que convierte un caso menor en una escalada. Su respuesta puede ocupar un solo párrafo. Normalmente el sistema que genera el informe no la lee, pero sí la lee la persona que gestiona el ticket en su proveedor. Esa persona decide qué ocurrirá con su instancia.