16

In den letzten Tagen bemerkte ich, dass einige Server mit unbekannten Anfragen überhäuft wurden.

Die meisten von ihnen sind wie folgt:

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 -

Nach ein wenig Protokollierung und Suche fand ich heraus, dass einige chinesische ISP (wahrscheinlich CERNET nach den Ergebnissen von whatsmydns.net) und einige türkische ISP (wahrscheinlich TTNET) auf DNS-Abfragen wie a.tracker.thepiratebay.orgmit verschiedenen IPs reagieren , die nichts mit PirateBay zu tun haben oder Torrents. Mit anderen Worten, sie scheinen aus irgendeinem bizarren Grund eine Art DNS-Cache-Vergiftung durchzuführen.

Hunderte (wenn nicht Tausende) von Bittorrent-Kunden in diesen Ländern senden meinen Webservern Unmengen von "Ankündigungen", die so gut wie zu einem DDoS-Angriff führen, der alle Apache-Verbindungen ausfüllt.

Im Moment habe ich China und die Türkei blockiert und es macht den Job, aber ich würde gerne einen besseren Weg finden, um diese Anfragen zu blockieren.

Ich dachte daran, diese Anforderungen mit mod_security basierend auf dem HTTP-Host-Header zu blockieren.

Alle diese Anforderungen enthalten einen HTTP-Host-Header wie a.tracker.thepiratebay.org(oder viele andere Unterdomänen der Domäne piratebay.org).

Hier ist ein Speicherauszug der Anforderungsheader über die PHP- $_SERVERVariable.

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

Meine Frage ist also, wie ich eingehende Anfragen an Apache basierend auf der Anfragedomäne (HTTP-Host-Header) blockieren kann. Beachten Sie, dass sich die Anfragen nicht nur auf /announce.php, sondern auf verschiedenen URLs befinden. Das Blockieren nach URL ist daher nicht sinnvoll.

Ist dieser Ansatz auch realisierbar oder wird er zu viel Last verursachen und ich sollte diese Anforderungen weiterhin löschen, bevor sie überhaupt Apache erreichen?

Aktualisieren:

Es stellt sich heraus, dass dieses Problem viele Menschen in vielen Ländern auf der ganzen Welt betroffen hat.
Es gab zahlreiche Berichte und Blogposts darüber und verschiedene Lösungen, um diesen Verkehr zu blockieren.

Ich habe einige der Berichte zusammengestellt, um allen, die hierher kommen, bei der Suche nach einer Lösung zu helfen, um dies zu blockieren.

Geheimnisvoller fehlgeleiteter chinesischer Verkehr: Wie kann ich herausfinden, welchen DNS-Server eine HTTP-Anfrage verwendet hat?
Merkwürdige Bittorrent-Anmeldung auf meinem Server
http://blog.devops.co.il/post/108740168304/torrent-ddos-attack
https://www.webhostingtalk.com/showthread.php?t=1443734
http: // torrentfreak. de / zombie-pirate-bay-tracker-treibt-chinesische-ddos-angriffe-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- geben /

apache-2.2 http mod-security bittorrent Cha0s
quelle

1

Ich sehe ein ähnliches Problem wie dieses. Ich habe die Anfragen blockiert, aber ich habe mich gefragt, wie Sie herausgefunden haben, welche ISPs die falschen IP-Adressen zurückgeben. Ich bin daran interessiert herauszufinden, woher die Anfragen kommen, so dass dies ein guter Ausgangspunkt zu sein scheint

pogo

Laut whatsmydns.net und anderen globalen DNS-Propagationsprüfern beantworten CERNET und CPIP in China und TTNET in der Türkei Anfragen zu verschiedenen Subdomains von thepiratebay.org zu verschiedenen IPs, wenn diese Domain auf keinem anderen ISP auf dem Planeten aufgelöst wird.

Cha0s

2

Ich bekomme genau das Gleiche und es begann ungefähr zu der gleichen Zeit, als du es bemerkt hast. Facebook, BitTorrent, Pornoseiten. vor allem aber kündigt sich diese ständige Piratenbucht an. serverfault.com/questions/658433/… Ich verwende Nginx und habe 444 zurückgegeben, wenn der Host nicht übereinstimmt.

Felix

die ankündigungsanfragen haben sich um einiges reduziert. Vielleicht war es eine vorübergehende DNS-Fehlkonfiguration. siehst du noch verkehr

Felix

2

Um ehrlich zu sein, habe ich China schließlich auf Firewall-Ebene blockiert, weil sie selbst mit mod_security alle Apache-Verbindungen füllen würden. Ich habe also nicht bemerkt, ob die Anfragen reduziert wurden.

Cha0s

7

Gleiches Thema hier. Ich benutze mod_security, um den User-Agent zu blockieren

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

Ich würde das Protokoll in nolog ändern, nachdem Sie überprüft haben, ob es funktioniert, um zu vermeiden, dass Ihre Protokolldatei voll ist

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

user262546
quelle

1

Ihre Antwort war zwar nicht genau das, was ich brauchte, aber sie hat mich in die richtige Richtung gelenkt, sodass ich Ihre als die richtige gewählt habe. Am Ende habe ich alle Torrent-Anfragen blockiert, indem ich die Zeichenfolge '? Info_hash =' in REQUEST_URI abgeglichen habe. User-Agent war nicht der beste Ansatz, da die Clients viele verschiedene Bittorrent-Clients mit unterschiedlichen UAs verwenden. Die letzte mod_security-Regel, mit der ich endete, ist:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

Cha0s

Versuchen Sie, dig a.tracker.thepiratebay.orgvon einem beliebigen DNS-Server in dieser Liste public-dns.tk/nameserver/cn.html eine andere Antwort zu erhalten. Dasselbe für tracker.thepiratebay.orgdas auch in unserem Host aufgetaucht ist: Header. Es gibt einen Beitrag dazu auf viewdns.info/research/… mit einigen zusätzlichen Seiten. Der Versuch, einige der zurückgegebenen Adressen mit viewdns.info/reverseip umzukehren, zeigt, dass dies ziemlich zufällig ist.

Evgeny

5

Wir haben genau dasselbe Problem mit einem Standort unseres Kunden. Ich fügte die folgenden in der Nähe der Spitze ihrer:

# Drop Bittorrent agent 2015-01-05 before redirect to https
<IfModule mod_rewrite.c>
    RewriteEngine on
    # RewriteCond %{HTTP_USER_AGENT} =Bittorrent
    RewriteRule ^/announce$ - [F]
    RewriteRule ^/announce\.php$ - [F]
</IfModule>

Die auskommentierte RewriteCond kann nicht kommentiert werden, um nur einen bestimmten Benutzeragenten zu blockieren. Aber sie haben keinen Inhalt bei announce oder announce.php, also haben wir einfach alles blockiert.

Dan Armstrong
quelle

Danke, aber ich brauchte eine Lösung mit mod_security und nicht mit mod_rewrite.

Cha0s

Siehe engineering.bittorrent.com/2015/01/29/… für einen besseren Weg (G / 410 anstelle von F / 403 und ein explizites Fehlerdokument)

Uhr

5

Im Moment habe ich das gleiche Problem: Torrent-Tracker zeigen auf meinen Server. Ich habe in den letzten Tagen mit iptables experimentiert und die Header und Muster der Anforderungen überprüft und auf ein paar iptables - Regeln eingegrenzt, die so gut wie den gesamten aktuellen scheinbar böswilligen Datenverkehr aus Asien (China, Malaysia, Japan und Japan) filtern Hongkong).

Unten sind die Regeln. Hoffe es hilft jemandem.

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

Franci
quelle

Nett! Daran habe ich nicht gedacht! Vielen Dank! : D Haben Sie sich REJECTaus DROPeinem bestimmten Grund für entschieden? (dh: Clients können nach Erhalt eines REJECT?

anhalten

1

Ja, REJECT sollte den Client auffordern, diese Ressource nicht mehr anzufordern, obwohl dies in diesem Fall keine Hilfe zu sein scheint. Es filtert es immer noch heraus, also lasse ich es als REJECT und hoffe, dass einige Kunden einen Hinweis nehmen. Auf jeden Fall sollte iptables bei dieser Aufgabe eine viel bessere Leistung erbringen als mod_security, also hoffe ich, dass es für Sie gut funktioniert.

Franci

Yeap sollte es! Ich habe alle chinesischen Präfixe blockiert. Ich werde diesen Ansatz ausprobieren, der besser ist :) Ich denke, dass die bittorrent-Clients auch mit REJECT nicht aufhören werden, es erneut zu versuchen. Sie würden es als "Verbindung abgelehnt" ansehen und es nach einer Weile erneut versuchen. Ich glaube, DROP ist ein besserer Ansatz (und verbraucht weniger Ressourcen - es

löscht

1

Der Unterschied ist eigentlich in allen außer extremen Fällen vernachlässigbar, und ich hoffte, den Verkehr irgendwann abschrecken zu können. Wenn es sich nicht auswählt, ändere ich es in DROP. Ich bin sehr gespannt, warum oder wie dies überhaupt geschehen ist. Es gibt einige Diskussionen darüber, dass die Great Firewall of China auf zufällige IPs umleitet, aber ich bin mir ziemlich sicher, dass dies hier nicht der Fall ist.

Franci

1

+1 Schöne. Wir werden uns jedoch darum --string "GET /announce"kümmern, die tatsächliche Anfrage abzudecken .

Linus Kleen

5

Ich schrieb einen Blog-Beitrag darüber, wie man BitTorrent-Clients anweist, wegzugehen und nie wieder zurückzukehren, ähnlich wie Dan, aber mit Nginx.

server {
    location /announc {
        access_log off;
        error_log off;
        default_type text/plain;
        return 410 "d14:failure reason13:not a tracker8:retry in5:nevere";
    }
}

Torrent-Tracker haben (normalerweise) eine Standard-URL, die mit /announceoder beginnt/scrape , daher würde ich das Filtern nach URL nicht so schnell verwerfen. Es klappt.

Der vollständige Beitrag ist unter - http://dvps.me/ddos-attack-by-torrent

Evgeny
quelle

1

Interessant zu lesen. Danke fürs Teilen :) Aber ich glaube, der Angriff wurde durch DNS Cache PoisoningCERNET in China ausgelöst, da es auf TPB-Domains mit zufälligen und nicht-chinesischen IPs reagiert. AFAIK PEX dient zum Teilen von Peers, nicht von Trackern. Können Sie das näher erläutern oder Unterlagen bereitstellen?

Cha0s

Es gibt eine Erweiterung zum Teilen von Trackern, die hier beschrieben wird: bittorrent.org/beps/bep_0028.html . Aber Sie sind richtig, dass die ‚Host:‘ Header für alle diese Anforderungen sind a.tracker.thepiratebay.orgoder tracker.thepiratebay.orgdie möglicherweise oder nicht das eigentliche Ziel dieser Kunden sein. Es können auch gefälschte Kunden sein, die sich nur als chinesische Bitterstoffe maskieren :)

Evgeny

1

Die Bittorrent-Leute schlagen 410 statt 404 vor: engineering.bittorrent.com/2015/01/29/…

ysth

0

Ich nahm die chinesischen IP-Bereiche von: http://www.wizcrafts.net/chinese-blocklist.html und blockierte sie in meiner CSF-Firewall. Hier sind die Bereiche, falls Sie sie kopieren und in Ihre Deny-IP-Liste von CSF einfügen möchten :

#china blocks start
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.0/11
220.181.0.0/16
220.191.0.0/16
220.192.0.0/12
220.228.70.0/24
220.242.0.0/15
220.248.0.0/14
220.250.0.0/19
220.252.0.0/16
221.0.0.0/12
221.122.0.0/15
221.176.0.0/13
221.192.0.0/14
221.200.0.0/14
221.204.0.0/15
221.206.0.0/16
221.207.0.0/16
221.208.0.0/12
221.212.0.0/15
221.214.0.0/15
221.216.0.0/13
221.224.0.0/13
221.228.0.0/14
221.232.0.0/13
222.32.0.0/11
222.64.0.0/12
222.80.0.0/12
222.132.0.0/14
222.136.0.0/13
222.168.0.0/13
222.172.222.0/24
222.176.0.0/13
222.184.0.0/13
222.200.0.0/16
222.208.0.0/13
222.219.0.0/16
222.220.0.0/15
222.240.0.0/13
223.4.0.0/14
223.64.0.0/11
223.144.0.0/12
223.240.0.0/13
#china blocks end

user3601800
quelle

Oder Sie können einfach hinzufügen , CC_DENY = "CN"auf , /etc/csf/csf.confund es wird die chinesischen Präfixe automatisch finden basierend auf Maxmind GeoIP - Datenbank.

Cha0s

danke, aber ich bin nicht sicher, auf welche Weise weniger Serverressourcen wie CPU-Auslastung, CC_DENY oder direkte IP-Blockierung verbraucht werden. Ich würde sagen, dass eine direkte IP-Blockierung besser ist.

user3601800

Ich sehe keinen Unterschied. Sobald die iptables-Regeln geladen sind (auf die eine oder andere Weise - die Regeln sind im Wesentlichen die gleichen), ist die Belastung des Systems die gleiche. Der einzige Unterschied besteht darin, dass Ihre Liste statisch ist (sodass Sie sie manuell auf dem neuesten Stand halten müssen), während die Liste aus der GeoIP-Datenbank von Zeit zu Zeit automatisch aktualisiert wird, um neue oder veraltete Präfixe pro Ländercode wiederzugeben. So oder so, wenn Sie viele Präfixe mit iptables blockieren, wird das System zusätzlich belastet. Die Last kommt von iptables selbst, nicht von der Art und Weise, wie Sie die zu blockierenden Präfixe finden.

Cha0s

Ich muss sagen, dass das Blockieren des Ländercodes CN im CSF bei mir nicht funktioniert hat. Heute habe ich neue IPs aus China gefunden, die von mod_security

user3601800

mod_security-Blockanforderungen nach http-Host-Header

Aktualisieren:

Antworten: