Los últimos días noté que algunos servidores estaban siendo abarrotados con solicitudes desconocidas.
La mayoría de ellos son como los siguientes:
60.246.*.* - - [03/Jan/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 ISP chinos (probablemente CERNET según los resultados de whatsmydns.net) y algunos ISP turcos (probablemente TTNET) responden a consultas de DNS, como a.tracker.thepiratebay.org
con varias IP que no tienen nada que ver con piratebay o torrentes. En otras palabras, parecen hacer algún tipo de envenenamiento de caché de DNS por alguna extraña razón.
Entonces, cientos (si no miles) de clientes bittorrent en esos países hacen toneladas de 'anuncios' a mis servidores web que resultan en un ataque DDoS que llena todas las conexiones de Apache.
En este momento bloqueé China y Turquía por completo y hace el trabajo, 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 HTTP Host.
Todas esas solicitudes incluyen un encabezado HTTP Host como a.tracker.thepiratebay.org
(o muchos otros subdominios del dominio thepiratebay.org).
Aquí hay un volcado de los encabezados de solicitud a través de la $_SERVER
variable 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 en función del dominio de solicitud (encabezado de host HTTP)? Tenga en cuenta que las solicitudes se encuentran en varias URL, no solo /announce.php, por lo que el bloqueo por URL no es útil.
¿También es viable ese enfoque o causará demasiada carga y debería seguir descartando esas solicitudes incluso antes de que lleguen a Apache?
Actualizar:
Resulta que este problema ha afectado a muchas personas en muchos países del mundo.
Ha habido numerosos informes y publicaciones de blog al respecto y varias soluciones para bloquear este tráfico.
He recopilado algunos de los informes para ayudar a cualquiera que venga a buscar una solución para bloquear esto.
Misterioso tráfico chino mal dirigido: ¿Cómo puedo saber qué servidor DNS utilizó una solicitud HTTP?
Registro extraño de Bittorrent 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-attack-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- dando /