16 votos

Mod_security bloquea solicitudes por el encabezado http-host

En los últimos días me di cuenta de que algunos servidores están siendo bombardeados con solicitudes desconocidas.

La mayoría de ellas son como las siguientes:

60.246.*.* - - [03/Ene/2015:20:59:16 +0200] "GET /announce.php?info_hash=%80%85%8e%9bu%cfJ.%85%82%e9%25%bf%8e%9e%d7%bf%c5%b0%12&peer_id=-UT3420-v%8bN%aa%60%60%fd%5d%d1%b0Ux&port=15411&uploaded=48588531&downloaded=0&left=0&corrupt=0&key=9E124668&numwant=200&compact=1&no_peer_id=1 HTTP/1.1" 200 -

Después de un poco de registro y búsqueda, descubrí que algunos proveedores de servicios de Internet chinos (probablemente CERNET según los resultados de whatsmydns.net) y turcos (probablemente TTNET) responden a consultas de DNS como a.tracker.thepiratebay.org con varias IPs que no tienen nada que ver con piratebay o torrents. En otras palabras, parece que están realizando algún tipo de Envenenamiento de Caché DNS por alguna razón extraña.

Entonces, cientos (si no miles) de clientes de BitTorrent en esos países realizan montones de 'anuncios' a mis servidores web, lo que resulta prácticamente en un ataque de denegación de servicio llenando todas las conexiones de Apache.

En este momento he bloqueado a China y Turquía por completo y funciona, pero me gustaría encontrar una mejor manera de bloquear esas solicitudes.

Estaba pensando en bloquear esas solicitudes con mod_security basado en el encabezado Host HTTP.

Todas esas solicitudes incluyen un encabezado Host HTTP como a.tracker.thepiratebay.org (o muchos otros subdominios del dominio thepiratebay.org).

Aquí tienes un volcado de los encabezados de la solicitud a través de la variable $_SERVER de PHP.

DOCUMENT_ROOT: /usr/local/apache/htdocs
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT_ENCODING: gzip
HTTP_CONNECTION: Close
HTTP_HOST: a.tracker.thepiratebay.org
HTTP_USER_AGENT: uTorrent/342(109415286)(35702)
PATH: /bin:/usr/bin
QUERY_STRING: info_hash=%80%85%8e%9bu%cfJ.%85%82%e9%25%bf%8e%9e%d7%bf%c5%b0%12&peer_id=-UT3420-v%8bN%aa%60%60%fd%5d%d1%b0Ux&port=15411&uploaded=48588531&downloaded=0&left=0&corrupt=0&key=9E124668&numwant=200&compact=1&no_peer_id=1
REDIRECT_STATUS: 200
REMOTE_ADDR: 60.246.*.*
REMOTE_PORT: 3445
REQUEST_METHOD: GET
REQUEST_URI: /announce.php?info_hash=%80%85%8e%9bu%cfJ.%85%82%e9%25%bf%8e%9e%d7%bf%c5%b0%12&peer_id=-UT3420-v%8bN%aa%60%60%fd%5d%d1%b0Ux&port=15411&uploaded=48588531&downloaded=0&left=0&corrupt=0&key=9E124668&numwant=200&compact=1&no_peer_id=1
SCRIPT_FILENAME: /usr/local/apache/htdocs/announce.php
SCRIPT_NAME: /announce.php
SERVER_ADDR: *.*.*.*
SERVER_ADMIN: *@*.*
SERVER_NAME: a.tracker.thepiratebay.org
SERVER_PORT: 80
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE: 
SERVER_SOFTWARE: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 mod_perl/2.0.8 Perl/v5.10.1
UNIQUE_ID: VKg8BJBMIPQAD01XYzgAAAAD
PHP_SELF: /announce.php
REQUEST_TIME_FLOAT: 1420311556.43
REQUEST_TIME: 1420311556
argv: Array
argc: 1

Entonces mi pregunta es, ¿cómo puedo bloquear las solicitudes entrantes a Apache basadas en el dominio de la solicitud (encabezado Host HTTP)? Ten en cuenta que las solicitudes están en varias URL no solo en /announce.php, por lo que bloquear por URL no es útil.

¿También es viable este enfoque o causará demasiada carga y debería seguir rechazando esas solicitudes antes de que lleguen a Apache?

Actualización:

Resulta que este problema ha afectado a muchas personas en muchos países de todo el mundo.
Ha habido numerosos informes y publicaciones en blogs al respecto y diversas soluciones para bloquear este tráfico.

He recopilado algunos de los informes para ayudar a cualquiera que venga aquí buscando una solución para bloquear esto.

Trafico chino misterioso desviado: ¿Cómo puedo averiguar qué servidor DNS usó una solicitud HTTP?
Registro de BitTorrent extraño en mi servidor
http://blog.devops.co.il/post/108740168304/torrent-ddos-attack
https://www.webhostingtalk.com/showthread.php?t=1443734
http://torrentfreak.com/zombie-pirate-bay-tracker-fuels-chinese-ddos-attacks-150124/
https://isc.sans.edu/forums/diary/Are+You+Piratebay+thepiratebayorg+Resolving+to+Various+Hosts/19175/
http://furbo.org/2015/01/22/fear-china/
http://www.jwz.org/blog/2015/01/chinese-bittorrent-the-gift-that-keeps-on-giving/

1 votos

Estoy viendo un problema similar a este, he bloqueado las solicitudes pero me preguntaba cómo habías descubierto qué proveedores de servicios de Internet estaban devolviendo las direcciones IP incorrectas. Estoy interesado en averiguar de dónde provienen las solicitudes, así que parece ser un buen punto de partida.

0 votos

Según whatsmydns.net y otros verificadores globales de propagación de DNS, CERNET y CPIP en China y TTNET en Turquía responden a consultas en varios subdominios de thepiratebay.org a varias IPs cuando ese dominio no resuelve en ningún otro ISP alrededor del planeta.

2 votos

Estoy experimentando exactamente lo mismo y comenzó más o menos en el mismo momento que tú lo notaste. Facebook, Bittorrent, sitios de pornografía. pero lo más notable es este constante anuncio del Pirate Bay. serverfault.com/questions/658433/… Estoy utilizando nginx y he devuelto un código de error 444 si el host no coincide.

7voto

user262546 Puntos 76

Mismo problema aquí. Estoy usando mod_security para bloquear el user-agent

SecRule REQUEST_HEADERS:User-Agent "Bittorrent" "id:10000002,rev:1,severity:2,log,msg:'Bittorrent Hit Detected'"

Cambiaría el log a nolog después de verificar que está funcionando para evitar llenar su archivo de registro

SecRule REQUEST_HEADERS:User-Agent "Bittorrent" "id:10000002,rev:1,severity:2,nolog,msg:'Bittorrent Hit Detected'"

1 votos

Mientras no era exactamente lo que necesitaba, tu respuesta me llevó en la dirección correcta, así que elegí la tuya como la correcta. Terminé bloqueando todas las solicitudes de torrent al hacer coincidir la cadena '?info_hash=' en el REQUEST_URI. User-Agent no era el mejor enfoque porque los clientes utilizan muchos clientes de bittorrent diferentes con diferentes UAs. La regla final de mod_security con la que terminé es: SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

0 votos

Intenta dig a.tracker.thepiratebay.org desde cualquier servidor DNS en esta lista public-dns.tk/nameserver/cn.html y en cada solicitud hay una respuesta diferente. Lo mismo para tracker.thepiratebay.org que también apareció en nuestros encabezados Host:. Hay una publicación al respecto en viewdns.info/research/… con algunos sitios adicionales. Intentar revertir algunas de las direcciones devueltas usando viewdns.info/reverseip muestra que es bastante aleatorio.

5voto

Dan Armstrong Puntos 51

Estamos experimentando exactamente el mismo problema con uno de los sitios de nuestros clientes. Añadí lo siguiente cerca de la parte superior de su:

# Bloquear el agente Bittorrent 2015-01-05 antes de redirigir a https

    RewriteEngine on
    # RewriteCond %{HTTP_USER_AGENT} =Bittorrent
    RewriteRule ^/announce$ - [F]
    RewriteRule ^/announce\.php$ - [F]

El RewriteCond comentado se puede descomentar para bloquear solo un agente de usuario específico. Pero no tienen contenido en announce o announce.php, así que simplemente lo bloqueamos todo.

0 votos

Gracias, pero necesitaba una solución usando mod_security y no mod_rewrite.

0 votos

Ver engineering.bittorrent.com/2015/01/29/… para una mejor manera (G/410 en lugar de F/403, y un ErrorDocument explícito)

5voto

Evgeny Puntos 381

He escrito una publicación en el blog sobre cómo decirle correctamente a los clientes de BitTorrent que se vayan y nunca vuelvan, similar a lo que hizo Dan, pero utilizando nginx.

servidor {
    ubicación /anuncio {
        access_log off;
        error_log off;
        default_type text/plain;
        return 410 "d14:failure reason13:not a tracker8:retry in5:nevere";
    }
}

Los trackers de torrents (generalmente) tienen una URL estándar que comienza con /anunciar o /scrape, así que no descartaría filtrar por URL tan rápidamente. Funciona.

La publicación completa está en - http://dvps.me/ddos-attack-by-torrent

1 votos

Interesante lectura. ¡Gracias por compartir :) Pero creo que el ataque fue inducido mediante Envenenamiento de caché DNS ya que CERNET en China responde a los dominios de TPB con IPs aleatorias y no chinas. Hasta donde yo sé, PEX es para compartir pares, no rastreadores. ¿Puedes explicar más sobre eso o proporcionar alguna documentación?

0 votos

Hay una extensión para compartir trackers descrita aquí bittorrent.org/beps/bep_0028.html. Pero tienes razón en que el encabezado 'Host:' para todas estas solicitudes es a.tracker.thepiratebay.org o tracker.thepiratebay.org que podría ser o no ser el objetivo real de estos clientes. También pueden ser clientes falsos que se disfrazan como bittorrents chinos :)

1 votos

Los desarrolladores de bittorrent sugieren 410 en lugar de 404: engineering.bittorrent.com/2015/01/29/…

5voto

Franci Puntos 51

En este momento estoy teniendo el mismo problema, con los rastreadores de torrent apuntando a mi servidor. He estado experimentando con iptables durante los últimos días e inspeccionando encabezados y patrones de las solicitudes, lo que me ha llevado a un par de reglas de iptables que filtran prácticamente todo el tráfico reciente aparentemente malicioso de Asia (China, Malasia, Japón y Hong Kong).

A continuación se muestran las reglas. Espero que le sean útiles a alguien.

iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "Bittorrent" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "spider" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "announce" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "deviantart" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "Bittorrent" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "baidu" --to 1000 -j REJECT
iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "Baiduspider" --to 1000 -j REJECT

0 votos

¡Genial! ¡No pensé en eso! ¡Gracias! :D ¿Escogiste REJECT en lugar de DROP por alguna razón en particular? (es decir: ¿los clientes pueden detenerse después de recibir un REJECT?)

1 votos

Sí, RECHAZAR debería indicar al cliente que deje de solicitar ese recurso, aunque no parece estar funcionando en este caso. Aún lo filtra, así que lo dejaré como RECHAZAR esperando que algunos clientes lo entiendan. De todas formas, iptables debería funcionar mucho mejor que mod_security en esta tarea, así que espero que funcione bien para ti.

0 votos

¡Sí debería funcionar! Estaba bloqueando todos los prefijos chinos. Probaré este enfoque que es mejor :) Creo que los clientes de bittorrent no dejarán de intentarlo incluso con REJECT. Lo verían como 'conexión rechazada' y volverían a intentarlo después de un tiempo. Creo que DROP es un enfoque mejor (y utiliza menos recursos, simplemente descarta los paquetes en el momento en que se emparejan sin ningún procesamiento adicional)

0voto

user3601800 Puntos 1

Tomé los rangos de IP chinos de: http://www.wizcrafts.net/chinese-blocklist.html y los bloquee en mi firewall de CSF, aquí están los rangos por si deseas copiarlos y pegarlos en tu lista de IP denegadas de CSF:

#bloqueos de China comienzo
1.80.0.0/13
1.92.0.0/14
1.192.0.0/13
1.202.0.0/15
1.204.0.0/14
14.144.0.0/12
14.208.0.0/12
23.80.54.0/24
23.104.141.0/24
23.105.14.0/24
27.8.0.0/13
27.16.0.0/12
27.36.0.0/14
27.40.0.0/13
27.50.128.0/17
27.54.192.0/18
27.106.128.0/18
27.115.0.0/17
27.148.0.0/14
27.152.0.0/13
27.184.0.0/13
36.32.0.0/14
36.248.0.0/14
42.96.128.0/17
42.120.0.0/15
58.16.0.0/15
58.20.0.0/16
58.21.0.0/16
58.22.0.0/15
58.34.0.0/16
58.37.0.0/16
58.38.0.0/16
58.40.0.0/16
58.42.0.0/16
58.44.0.0/14
58.48.0.0/13
58.56.0.0/15
58.58.0.0/16
58.59.0.0/17
58.60.0.0/14
58.68.128.0/17
58.82.0.0/15
58.100.0.0/15
58.208.0.0/12
58.242.0.0/15
58.246.0.0/15
58.248.0.0/13
59.32.0.0/12
59.51.0.0/16
59.52.0.0/14
59.56.0.0/13
59.72.0.0/16
59.108.0.0/15
59.172.0.0/14
60.0.0.0/13
60.11.0.0/16
60.12.0.0/16
60.24.0.0/13
60.160.0.0/11
60.194.0.0/15
60.208.0.0/13
60.216.0.0/15
60.220.0.0/14
61.4.64.0/20
61.4.80.0/22
61.4.176.0/20
61.48.0.0/13
61.128.0.0/10
61.135.0.0/16
61.136.0.0/18
61.139.0.0/16
61.145.73.208/28
61.147.0.0/16
61.150.0.0/16
61.152.0.0/16
61.154.0.0/16
61.160.0.0/16
61.162.0.0/15
61.164.0.0/16
61.175.0.0/16
61.177.0.0/16
61.179.0.0/16
61.183.0.0/16
61.184.0.0/16
61.185.219.232/29
61.187.0.0/16
61.188.0.0/16
61.232.0.0/14
61.236.0.0/15
61.240.0.0/14
101.64.0.0/13
101.72.0.0/14
101.76.0.0/15
101.80.0.0/12
103.253.4.0/22
106.112.0.0/13
110.6.0.0/15
110.51.0.0/16
110.52.0.0/15
110.80.0.0/13
110.88.0.0/14
110.96.0.0/11
110.173.0.0/19
110.173.32.0/20
110.173.64.0/18
110.192.0.0/11
110.240.0.0/12
111.0.0.0/10
111.72.0.0/13
111.121.0.0/16
111.128.0.0/11
111.160.0.0/13
111.172.0.0/14
111.176.0.0/13
111.228.0.0/14
112.0.0.0/10
112.64.0.0/14
112.80.0.0/12
112.100.0.0/14
112.111.0.0/16
112.122.0.0/15
112.224.0.0/11
113.0.0.0/13
113.8.0.0/15
113.12.0.0/14
113.16.0.0/15
113.18.0.0/16
113.62.0.0/15
113.64.0.0/10
113.128.0.0/15
113.136.0.0/13
113.194.0.0/15
113.204.0.0/14
114.28.0.0/16
114.80.0.0/12
114.96.0.0/13
114.104.0.0/14
114.112.0.0/14
112.109.128.0/17
114.216.0.0/13
114.224.0.0/11
115.24.0.0/15
115.28.0.0/15
115.32.0.0/14
115.48.0.0/12
115.84.0.0/18
115.100.0.0/15
115.148.0.0/14
115.152.0.0/15
115.168.0.0/14
115.212.0.0/16
115.230.0.0/16
115.236.96.0/23
115.236.136.0/22
115.239.228.0/22
116.1.0.0/16
116.2.0.0/15
116.4.0.0/14
116.8.0.0/14
116.16.0.0/12
116.52.0.0/14
116.76.0.0/15
116.90.80.0/20
116.112.0.0/14
116.128.0.0/10
116.204.0.0/15
116.208.0.0/14
116.224.0.0/12
116.254.128.0/18
117.8.0.0/13
117.21.0.0/16
117.22.0.0/15
117.24.0.0/13
117.32.0.0/13
117.40.0.0/14
117.44.0.0/15
117.60.0.0/14
117.79.224.0/20
117.80.0.0/12
117.136.0.0/13
118.26.0.0/16
118.72.0.0/13
118.112.0.0/13
118.120.0.0/14
118.132.0.0/14
118.144.0.0/14
118.180.0.0/14
118.186.0.0/15
118.192.0.0/15
118.248.0.0/13
119.0.0.0/13
119.8.0.0/16
119.10.0.0/17
119.18.192.0/20
119.36.0.0/16
119.57.0.0/16
119.60.0.0/16
119.88.0.0/14
119.96.0.0/13
119.112.0.0/13
119.120.0.0/13
119.128.0.0/12
119.144.0.0/14
119.164.0.0/14
119.176.0.0/12
119.233.0.0/16
120.0.0.0/12
120.24.0.0/14
120.32.0.0/13
120.40.0.0/14
120.68.0.0/14
120.80.0.0/13
120.192.0.0/10
121.0.16.0/20
121.8.0.0/13
121.16.0.0/12
121.32.0.0/14
121.60.0.0/14
121.76.0.0/15
121.196.0.0/14
121.204.0.0/14
121.224.0.0/12
122.10.128.0/17
122.51.128.0/17
122.64.0.0/11
122.119.0.0/16
122.136.0.0/13
122.156.0.0/14
122.188.0.0/14
122.192.0.0/14
122.198.0.0/16
122.200.64.0/18
122.224.0.0/12
123.4.0.0/14
123.8.0.0/13
123.52.0.0/14
123.64.0.0/11
123.97.128.0/17
123.100.0.0/19
123.112.0.0/12
123.128.0.0/13
123.138.0.0/15
123.150.0.0/15
123.152.0.0/13
123.164.0.0/14
123.180.0.0/14
123.184.0.0/14
123.196.0.0/15
123.232.0.0/14
123.249.0.0/16
124.42.64.0/18
124.64.0.0/15
124.67.0.0/16
124.73.0.0/16
124.114.0.0/15
124.126.0.0/15
124.128.0.0/13
124.160.0.0/15
124.162.0.0/16
124.163.0.0/16
124.192.0.0/15
124.200.0.0/13
124.226.0.0/15
124.228.0.0/14
124.236.0.0/14
124.240.0.0/17
124.240.128.0/18
124.248.0.0/17
125.36.0.0/14
125.40.0.0/13
125.64.0.0/12
125.79.0.0/16
125.80.0.0/13
125.88.0.0/13
125.104.0.0/13
125.112.0.0/12
125.210.0.0/15
140.224.0.0/16
140.237.0.0/16
140.246.0.0/16
140.249.0.0/16
142.4.117.0/30
159.226.0.0/16
171.34.0.0/15
171.36.0.0/14
171.40.0.0/13
175.0.0.0/12
175.16.0.0/13
175.24.0.0/14
175.30.0.0/15
175.42.0.0/15
175.44.0.0/16
175.46.0.0/15
175.48.0.0/12
175.64.0.0/11
175.102.0.0/16
175.106.128.0/17
175.146.0.0/15
175.148.0.0/14
175.152.0.0/14
175.160.0.0/12
175.178.0.0/16
175.184.128.0/18
175.185.0.0/16
175.186.0.0/15
175.188.0.0/14
180.76.0.0/16
180.96.0.0/11
180.136.0.0/13
180.152.0.0/13
180.208.0.0/15
182.18.0.0/17
182.32.0.0/12
182.88.0.0/14
182.112.0.0/12
182.128.0.0/12
183.0.0.0/10
183.64.0.0/13
183.129.0.0/16
183.148.0.0/16
183.160.0.0/12
183.184.0.0/13
183.192.0.0/11
192.34.109.224/28
192.74.224.0/19
198.2.203.64/28
198.2.212.160/28
202.43.144.0/22
202.46.32.0/19
202.66.0.0/16
202.75.208.0/20
202.96.0.0/12
202.111.160.0/19
202.112.0.0/14
202.117.0.0/16
202.165.176.0/20
202.196.80.0/20
203.69.0.0/16
203.86.0.0/18
203.86.64.0/19
203.93.0.0/16
203.169.160.0/19
203.171.224.0/20
210.5.0.0/19
210.14.128.0/19
210.21.0.0/16
210.32.0.0/14
210.51.0.0/16
210.52.0.0/15
210.77.0.0/16
210.192.96.0/19
211.76.96.0/20
211.78.208.0/20
211.86.144.0/20
211.90.0.0/15
211.92.0.0/14
211.96.0.0/13
211.136.0.0/13
211.144.12.0/22
211.144.96.0/19
211.144.160.0/20
211.147.0.0/16
211.152.14.0/24
211.154.64.0/19
211.154.128.0/19
211.155.24.0/22
211.157.32.0/19
211.160.0.0/13
211.233.70.0/24
218.0.0.0/11
218.56.0.0/13
218.64.0.0/11
218.84.0.0/14
218.88.0.0/13
218.96.0.0/14
218.102.0.0/16
218.104.0.0/14
218.108.0.0/15
218.194.80.0/20
218.200.0.0/13
218.240.0.0/13
219.128.0.0/11
219.154.0.0/15
219.223.192.0/18
219.232.0.0/16
219.234.80.0/20
219.235.0.0/16
220.112.0.0/16
220.154.0.0/15
220.160.

0 votos

O simplemente puedes agregar CC_DENY = "CN" en /etc/csf/csf.conf y automáticamente encontrará los prefijos chinos basados en la base de datos GeoIP de Maxmind.

0 votos

Gracias, pero no estoy seguro de qué manera consume menos recursos del servidor como el uso de la CPU, el CC_DENY o el bloqueo directo de IP. Yo diría que el bloqueo directo de IP es mejor.

0 votos

No veo ninguna diferencia. Una vez que las reglas de iptables estén cargadas (de una forma u otra, las reglas son esencialmente las mismas), la carga en el sistema será la misma. La única diferencia es que tu lista es estática (así que tendrás que mantenerla actualizada manualmente) mientras que la lista de la base de datos GeoIP se actualizará automáticamente de vez en cuando para reflejar cualquier prefijo nuevo u obsoleto por código de país. De cualquier manera, cuando bloqueas muchos prefijos con iptables, tendrás una carga extra en el sistema. La carga proviene de iptables mismos, no de la forma en que encuentras qué prefijos bloquear.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X