16

W ciągu ostatnich kilku dni zauważyłem, że niektóre serwery są hamowane nieznanymi żądaniami.

Większość z nich wygląda następująco:

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 -

Po pewnym zalogowaniu i wyszukiwaniu dowiedziałem się, że jakiś chiński dostawca usług internetowych (prawdopodobnie CERNET według wyników whatsmydns.net) i turecki dostawca usług internetowych (prawdopodobnie TTNET) odpowiada na zapytania dns, takie jak a.tracker.thepiratebay.orgróżne adresy IP, które nie mają nic wspólnego z piratebay lub torrenty. Innymi słowy, wydają się robić jakieś zatrucie pamięci podręcznej DNS z jakiegoś dziwnego powodu.

Tak więc setki (jeśli nie tysiące) bittorrentowych klientów w tych krajach przekazuje mnóstwo „zapowiedzi” moim serwerom internetowym, które powodują atak DDoS wypełniający wszystkie połączenia Apache.

W tej chwili całkowicie zablokowałem Chiny i Turcję i spełnia to zadanie, ale chciałbym znaleźć lepszy sposób na zablokowanie tych wniosków.

Myślałem o zablokowaniu tych żądań za pomocą mod_security na podstawie nagłówka hosta HTTP.

Wszystkie te żądania obejmują nagłówek hosta HTTP, taki jak a.tracker.thepiratebay.org(lub wiele innych subdomen domeny thepiratebay.org).

Oto zrzut nagłówków żądań poprzez $_SERVERzmienną 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

Więc moje pytanie brzmi: jak mogę blokować przychodzące żądania do Apache na podstawie domeny żądania (nagłówek hosta HTTP)? Pamiętaj, że żądania dotyczą różnych adresów URL, a nie tylko /announce.php, więc blokowanie według adresów URL nie jest przydatne.

Czy to podejście jest wykonalne, czy też spowoduje zbyt duże obciążenie i powinienem porzucić te żądania, zanim dotrą one do Apache?

Aktualizacja:

Okazuje się, że problem ten dotknął wiele osób w wielu krajach na całym świecie.
Pojawiło się wiele raportów i postów na blogu oraz różne rozwiązania blokujące ten ruch.

Zebrałem niektóre raporty, aby pomóc każdemu, kto tu przyjdzie, szukając rozwiązania tego problemu.

Tajemniczy źle skierowany ruch chiński: Jak mogę dowiedzieć się, jakiego serwera DNS użyło żądanie HTTP?
Dziwne Bittorrent Zaloguj się na moim serwerze
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- dający/

apache-2.2 http mod-security bittorrent Cha0s
źródło

1

Widzę podobny problem, zablokowałem żądania, ale zastanawiałem się, w jaki sposób dowiedziałeś się, którzy dostawcy usług internetowych zwracają nieprawidłowe adresy IP? Chciałbym dowiedzieć się, skąd pochodzą wnioski, więc wydaje się to dobrym punktem wyjścia

pogo

Według whatsmydns.net i innych kontrolerów propagacji glbal dns, CERNET i CPIP w Chinach oraz TTNET w Turcji odpowiadają na zapytania dotyczące różnych subdomen thepiratebay.org na różne adresy IP, gdy domena ta nie jest rozpoznawana na żadnym innym dostawcy usług internetowych na całej planecie.

Cha0s,

2

Dostaję dokładnie to samo i zaczęło się mniej więcej w tym samym momencie, kiedy to zauważyłeś. strony na Facebooku, Bittorrent, porno. ale przede wszystkim ogłaszają tę stałą piracką zatokę. serverfault.com/questions/658433/ ... Używam nginx i zwróciłem 444 jeśli host nie pasuje.

felix

wnioski o ogłoszenie zostały znacznie zmniejszone. może była to tymczasowa błędna konfiguracja DNS. czy nadal widzisz ruch?

felix

2

Szczerze mówiąc, ostatecznie zablokowałem Chiny na poziomie zapory ogniowej, ponieważ nawet przy mod_security wypełniłyby wszystkie połączenia Apache. Więc nie zauważyłem, czy prośby zostały zmniejszone.

Cha0s,

7

Ten sam problem tutaj. Korzystam z mod_security, aby zablokować klienta użytkownika

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

Zmieniłem dziennik na nolog po sprawdzeniu, czy działa, aby uniknąć zapełniania pliku dziennika

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

użytkownik262546
źródło

1

Chociaż nie do końca to, czego potrzebowałem, twoja odpowiedź poprowadziła mnie we właściwym kierunku, więc wybrałem twój jako właściwy. Skończyło się na blokowaniu wszystkich żądań torrentowych przez dopasowanie ciągu „? Info_hash =” w REQUEST_URI. User-Agent nie był najlepszym rozwiązaniem, ponieważ klienci używają wielu różnych klientów bittorrent z różnymi UA. Ostateczna zasada mod_security, na której się skończyłem, to:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

Cha0s

Spróbuj dig a.tracker.thepiratebay.orgz dowolnego serwera DNS na tej liście public-dns.tk/nameserver/cn.html, a na każde żądanie jest inna odpowiedź. To samo, w przypadku tracker.thepiratebay.orgktórego pojawił się również nasz Host: nagłówki. Jest post na ten temat na viewdns.info/research/… z kilkoma dodatkowymi stronami. Próba odwrócenia niektórych zwróconych adresów za pomocą viewdns.info/reverseip pokazuje, że jest to dość losowe.

Evgeny

5

Mamy dokładnie ten sam problem z jedną z witryn naszego klienta. Dodałem następujące u góry ich:

# 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>

Skomentowane RewriteCond można odkomentować, aby zablokować tylko określonego klienta użytkownika. Ale nie mają żadnych treści na announce lub announce.php, więc właśnie to wszystko zablokowaliśmy.

Dan Armstrong
źródło

Dzięki, ale potrzebowałem rozwiązania wykorzystującego mod_security, a nie mod_rewrite.

Cha0s,

zobacz: engineering.bittorrent.com/2015/01/29 /... (G / 410 zamiast F / 403 i wyraźny dokument

błędu

5

W tej chwili mam ten sam problem - śledzenie torrentów wskazuje mój serwer. Przez ostatnie kilka dni eksperymentowałem z iptables, sprawdziłem nagłówki i wzorce żądań i zawęziłem go do kilku reguł iptables, które filtrują prawie cały pozornie złośliwy ruch z Azji (Chiny, Malezja, Japonia i Hongkong).

Poniżej znajdują się zasady. Mam nadzieję, że to komuś pomoże.

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
źródło

Ładny! Nie myślałem o tym! Dzięki! : D Czy zdecydowałeś się na to REJECTz DROPjakiegoś konkretnego powodu? (tzn. klienci mogą przestać otrzymywać wiadomość REJECT?)

Cha0s

1

Tak, REJECT powinien powiedzieć klientowi, aby przestał żądać tego zasobu, chociaż wydaje się, że w tym przypadku nie pomaga. Nadal go odfiltrowuje, więc zostawiam go jako REJECT, mając nadzieję, że niektórzy klienci skorzystają z podpowiedzi. W każdym razie, iptables powinno działać o wiele lepiej niż mod_security w tym zadaniu, więc mam nadzieję, że zadziała dobrze dla ciebie.

Franci

Tak, powinno! Blokowałem wszystkie chińskie prefiksy. Wypróbuję to podejście, które jest lepsze :) Myślę, że klienci bittorrent nie przestaną próbować nawet z REJECT. Widzą to jako „odmowę połączenia” i po chwili ponawiają próbę. Wierzę, że DROP jest lepszym podejściem (i zużywa mniej zasobów - po prostu upuszcza pakiety, gdy tylko zostaną dopasowane bez dalszego przetwarzania)

Cha0s

1

Różnica jest właściwie znikoma we wszystkich przypadkach poza ekstremalnymi, a moją nadzieją było w końcu powstrzymanie ruchu. Jeśli nie zadzwoni, zmienię go na DROP. Jestem jednak bardzo ciekawy, dlaczego i jak to się stało. Trwają dyskusje na temat przekierowywania Great Firewall of China na losowe adresy IP, ale jestem pewien, że tak nie jest.

Franci

1

+1 Niezły. Zamierzamy --string "GET /announce"jednak pokryć faktyczną prośbę.

Linus Kleen

5

Napisałem post na blogu o tym, jak prawidłowo powiedzieć klientom BitTorrenta, aby odeszli i nigdy nie wracali, podobnie jak zrobił to Dan, ale używając 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";
    }
}

Urządzenia śledzące torrent (zwykle) mają standardowy adres URL rozpoczynający się od /announcelub /scrape, więc nie odrzuciłbym tak szybko filtrowania według adresu URL. To działa.

Pełny post znajduje się na stronie - http://dvps.me/ddos-attack-by-torrent

Evgeny
źródło

1

Ciekawa lektura. Dziękujemy za udostępnienie :) Ale uważam, że atak został wywołany, DNS Cache Poisoningponieważ CERNET w Chinach odpowiada na domeny TPB losowymi i nie chińskimi adresami IP. AFAIK PEX służy do udostępniania elementów równorzędnych, a nie elementów śledzących. Czy możesz opracować więcej na ten temat lub dostarczyć dokumentację?

Cha0s,

Istnieje rozszerzenie do udostępniania trackerów opisanych tutaj bittorrent.org/beps/bep_0028.html . Ale masz rację, ponieważ nagłówek „Host:” dla wszystkich tych żądań jest a.tracker.thepiratebay.orglub tracker.thepiratebay.orgmoże być lub nie być faktycznym celem tych klientów. Mogą to być również fałszywi klienci, którzy po prostu maskują się jak chińskie bittorenty :)

Evgeny

1

bittorrent ludzie sugerują 410 zamiast 404: engineering.bittorrent.com/2015/01/29/…

ysth

0

wziąłem chińskie zakresy adresów IP z: http://www.wizcrafts.net/chinese-blocklist.html i zablokowałem je w mojej zaporze csf, oto zakresy na wypadek, gdybyś chciał skopiować i wkleić na listę odmówionych adresów csf :

#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

użytkownik3601800
źródło

Albo można po prostu dodać CC_DENY = "CN"na /etc/csf/csf.confktóry automatycznie znaleźć chińskich prefiksy opartych na bazie GeoIP MaxMind użytkownika.

Cha0s

dzięki, ale nie jestem pewien, który sposób zużywa mniej zasobów serwera, takich jak użycie procesora, CC_DENY lub bezpośrednie blokowanie adresów IP. Powiedziałbym, że bezpośrednie blokowanie adresów IP jest lepsze.

user3601800,

Nie widzę żadnej różnicy. Po załadowaniu reguł iptables (w ten czy inny sposób - reguły są zasadniczo takie same), obciążenie systemu będzie takie samo. Jedyną różnicą jest to, że twoja lista jest statyczna (więc musisz ręcznie ją aktualizować), podczas gdy lista z bazy danych GeoIP będzie od czasu do czasu aktualizowana automatycznie, aby odzwierciedlić wszelkie nowe lub nieaktualne prefiksy według kodu kraju. Tak czy inaczej, gdy zablokujesz wiele prefiksów za pomocą iptables, będziesz miał dodatkowe obciążenie systemu. Obciążenie pochodzi od samych iptables, a nie od sposobu wyszukiwania prefiksów do zablokowania.

Cha0s,

muszę powiedzieć, że blokowanie kodu kraju CN w csf nie działało dla mnie, dzisiaj znalazłem nowe adresy IP z Chin zablokowane przez mod_security

user3601800

żądania bloków mod_security według nagłówka http-hosta

Aktualizacja:

Odpowiedzi: