- Se reportó un caso en el que un servidor personal cayó por solicitudes excesivas de bots de scraping con IA
- El análisis de logs confirmó intentos de acceso intensivos desde el rango de IP alojado en Singapur (47.79.*) de Alibaba(US) Technology
- Un User-Agent falsificado con formato
Mozilla/5.0 inutilizó los sistemas habituales de detección de bots
- Los sistemas automáticos de bloqueo de Fail2ban y Nginx se sobrecargaron, por lo que fue necesario bloquear manualmente todo el rango de IP
- Debido a estos ataques repetidos, el entorno de autoalojamiento se está debilitando y los operadores de servidores personales están siendo empujados hacia plataformas centralizadas
La causa de la caída del servidor y la respuesta inicial
- Hace unos días, un servidor pequeño que alojaba el sitio quedó temporalmente fuera de servicio por un ataque de bots de scraping
- Ya había habido ataques similares en el pasado, y se está considerando implementar herramientas de defensa más potentes como Anubis
- Los ataques repetidos han reducido la motivación creativa y el disfrute como hobby de los desarrolladores individuales
- Tras notar lentitud en el acceso al servidor, al revisar con el comando
top se vio que Gitea y Fail2ban estaban consumiendo casi toda la CPU
- Incluso después de cerrar el proceso de Gitea, la carga de Fail2ban no bajó, y los logs de acceso de Nginx estaban desbordados
Análisis de logs y patrón del ataque
- En los logs quedaron registradas numerosas solicitudes HTTP 502 dirigidas a la ruta
/commit/
- En los encabezados de la solicitud se usaban User-Agent disfrazados de navegador común, como
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
- La mayoría de las herramientas de inspección de User-Agent los reconocieron como tráfico normal, lo que permitió evadir la detección
- Las IP de ataque provinieron de múltiples direcciones, no de una sola fuente, pero en común usaban el rango
47.79.*
- Según una consulta en
ipinfo.io, ese rango pertenece a Alibaba(US) Technology Co., Ltd.
- También existen reportes de ataques desde el mismo rango de IP en foros como PhpBB
Medidas defensivas y limitaciones
- Fail2ban analizaba en tiempo real los logs de Nginx para aplicar reglas de bloqueo, pero hubo retrasos por la explosión del volumen de logs
- Se ejecutó un script para bloquear de inmediato las IP que intentaban acceder a
/commit/, pero había límites de velocidad
- Finalmente, mediante el comando
iptables, se bloqueó manualmente todo el rango 47.79.0.0/16
- Esta respuesta es solo una medida temporal, y es probable que los ataques continúen desde nuevos rangos de IP
- Se está evaluando adoptar servicios externos de protección como Cloudflare o sistemas de defensa avanzados como Anubis
- Sin embargo, existe reticencia a implementarlos porque no se desea pasar por servidores de EE. UU. con funciones de rastreo
Las dificultades de operar un servidor personal
- Se está considerando mover la instancia de Gitea a Codeberg
- Los operadores de servidores personales, debido a los ataques repetidos, tienden a abandonar el autoalojamiento y migrar a plataformas centralizadas
- Esta tendencia termina debilitando la descentralización y la autonomía de Internet
- Otros blogueros también han reportado daños por ataques similares, y el problema se está extendiendo a los pequeños operadores web en general
Otras anomalías de tráfico observadas
- Se detectaron encabezados Referer falsificados que apuntaban a dominios de grandes empresas como
bioware.com, mcdonalds.com y microsoft.com
- En realidad, esos sitios no habían proporcionado ningún enlace, y se observó un aumento de tráfico de propósito desconocido
- Aun si los ataques se repiten, se expresa la determinación de no abandonar el autoalojamiento
- Al final del texto, la frase “Get Hostin’ Or Die Tryin’” subraya la voluntad de seguir operando servidores autónomos
1 comentarios
Opiniones de Hacker News
Se siente que internet ya dejó de ser un espacio seguro para desarrolladores aficionados de software
He administrado mis propios servidores desde más o menos 2005, y desde el momento en que un servidor se pone en línea siempre recibe ataques
En especial, cuando le pones un nombre DNS o usas un certificado TLS, parece que los ataques empeoran porque queda expuesto en los registros de transparencia de certificados
Si publicas un sitio web, se te viene encima una avalancha de tráfico malicioso, y si haces enojar a cierta organización, parece que contratan a alguien para intentar un DDoS
Cada año toca lidiar con crawlers, botnets, ataques automatizados y gente enojada
He probado varios proveedores de hosting, pero el resultado ha sido parecido
Como no actualicé WordPress, en pocas horas quedó infectado con spam SEO, y cuando por error expuse Redis hacia afuera, le instalaron un RAT de botnet
Pero no creo que esas cosas signifiquen que internet sea “peligroso”
Más bien fueron experiencias que me enseñaron lo que tenía que aprender
Después de eso empecé a usar star-cert para no aparecer en los logs de certificados, añadí autenticación básica, mantuve respaldos y operé todo con más cuidado
Creo que lo realmente peligroso es que alguien sin conocimientos técnicos instale cualquier exe y le entregue toda su información a Facebook o TikTok
La mayoría son solicitudes que buscan vulnerabilidades de WordPress, y nunca he usado WordPress
La primera vez que vi los logs me impactó, pero ahora ya lo tomo como algo cotidiano
Ejemplo: https://www.masswerk.at/wp-admin
Fue la época en que empezaron a difundirse herramientas para escanear rangos de IP y encontrar vulnerabilidades de forma automática
Extraño la web de entre 1995 y 2008, cuando existían Web Rings, Technorati y los fansites
Referencia: wiki de Script Kiddie
Antes usé una zipbomb para bloquear bots y sí funcionó
Pero después de publicarlo en HN, llegó una nueva ola de bots y mi servidor de $6 ya no pudo aguantar
Era imposible servir 100 mil solicitudes al día con cargas de 1 a 10 MB
Después cambié la estrategia para apuntar solo a ciertos bots, creé un honeypot para recolectar IPs y responder con 403
Tras unos meses, el tráfico volvió a niveles normales
Pero no sé quién sería el cliente objetivo. La mayoría de quienes hacen self-hosting no tienen mucho dinero
Mi servidor cgit también lleva un año recibiendo accesos constantes de scrapers
Eso sí, son solo 2 o 3 solicitudes por minuto, así que es un bot bastante “educado”
Lo chistoso es que todo el código que publiqué puede clonarse directamente desde upstream, pero igual se ponen a rasparlo así
Viendo los logs, la automatización es realmente ineficiente
Si configuras directamente la función de rate-limiting de Nginx, se puede resolver más fácil que con Fail2ban
Blog de referencia: https://blog.nginx.org/blog/rate-limiting-nginx
Es difícil aplicarlo a servicios públicos como un blog, pero para self-hosting de uso personal recomiendo configurar autenticación mTLS en el reverse proxy
Las solicitudes sin certificado se bloquean de inmediato y solo mis dispositivos pueden entrar
Una vez configurado, casi no hay que volver a pensar en ello
Es fácil de configurar y funciona bien en Android e iOS
Ahora tengo todos mis servicios self-hosted accesibles solo dentro de una VPN de Wireguard, y en el firewall dejo abierto únicamente el puerto de Wireguard
Anubis está haciendo bien este juego del gato y el ratón contra los bots
Pero solo lugares como Cloudflare, que tienen datos de tráfico a gran escala, pueden hacer bien el bloqueo basado en reputación de IP
Los operadores pequeños no tienen más remedio que bloquear rangos completos de IP, y eso es ineficiente
Hace falta una solución como Crowdsec que comparta datos de reputación para bloquear IPs maliciosas y ofrezca un desafío simple sin JS
Si un enfoque así fuera posible, creo que a los desarrolladores aficionados les volvería a ser más fácil operar servicios
Mi instancia de Gitea también fue scrapeada recientemente desde IPs y ASN distribuidos
Si se trata de empresas de IA con mucho dinero, probablemente ni Anubis bastaría para detenerlas
Por eso estoy considerando el “envenenamiento” de scrapers: entregar datos basura en lugar del código
Ese tipo de servicios hace que el scraping sea todavía más difícil de frenar
Lo que se vuelve popular al final pasa por el ciclo de caer en manos del público y arruinarse
Por eso da la impresión de que la única solución es seguir mudándose a espacios nuevos
Desde que moví el DNS a Cloudflare, no dejan de llegar paquetes SYN extraños
Llegan solicitudes cada segundo al puerto 443 o 22, pero después del SYN-ACK ya no hay respuesta
La mayoría parece venir de proveedores de hosting VPS para servidores de juegos en lugares como Brasil
Así que capturo los paquetes SYN, los consulto por RDAP y bloqueo por completo las subredes de esas organizaciones
Solo mantengo a Google en la whitelist
Digital Ocean parece ser una de las principales fuentes de tráfico malicioso
La pila de red reintenta y así el tráfico amplificado termina llegando a la víctima
A menudo falsifican la IP de origen, así que recomiendo probar con
rp_filteren modo strictAsí como la compañía eléctrica no prohíbe usar focos rojos, no es deseable que el proveedor del servicio controle el tráfico
Me identifiqué con este post no porque internet sea seguro, sino porque deja constancia de esta realidad
Yo también estoy bloqueando Alibaba /16 y todo el rango de AWS
Uso un script que cada día descarga datos de RouteViews por cron y los aplica a iptables
Código de ejemplo:
Ojalá otras nubes también ofrecieran algo así