16

ไม่กี่วันที่ผ่านมาฉันสังเกตเห็นว่ามีบางเซิร์ฟเวอร์ที่ถูกร้องขอโดยไม่ทราบสาเหตุ

ส่วนใหญ่เป็นดังต่อไปนี้:

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 -

หลังจากการบันทึกและค้นหาเล็กน้อยฉันพบว่า ISP ของจีนบางตัว (อาจ CERNET ตามผลลัพธ์ของ whatsmydns.net) และ ISP ของตุรกีบางตัว (อาจเป็น TTNET) ตอบสนองต่อการค้นหา DNS เช่นa.tracker.thepiratebay.orgกับ IP ต่างๆที่ไม่มีส่วนเกี่ยวข้องกับ piratebay หรือ torrents กล่าวอีกนัยหนึ่งพวกเขาดูเหมือนจะทำ DNS Cache Poisoning บางชนิดด้วยเหตุผลที่แปลกประหลาด

ดังนั้นลูกค้า bittorrent หลายร้อยคน (ถ้าไม่นับพันคน) ในประเทศเหล่านั้นทำ 'ประกาศ' จำนวนมากให้กับเว็บเซิร์ฟเวอร์ของฉัน

ในขณะนี้ฉันบล็อกจีนและตุรกีโดยสิ้นเชิงและทำงานได้ แต่ฉันต้องการค้นหาวิธีที่ดีกว่าในการบล็อกคำขอเหล่านั้น

ฉันคิดว่าจะบล็อกคำขอเหล่านั้นด้วย mod_security ตามส่วนหัวของโฮสต์ HTTP

คำขอทั้งหมดนั้นรวมถึงส่วนหัวโฮสต์ HTTP เช่นa.tracker.thepiratebay.org(หรือโดเมนย่อยอื่น ๆ ของโดเมน thepiratebay.org)

นี่คือการถ่ายโอนข้อมูลของส่วนหัวคำขอผ่าน$_SERVERตัวแปรของ 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

ดังนั้นคำถามของฉันคือฉันจะบล็อกการร้องขอขาเข้าไปยัง Apache ตามโดเมนคำขอ (ส่วนหัวโฮสต์ HTTP) ได้อย่างไร โปรดทราบว่าคำขออยู่ใน URL ที่หลากหลายไม่ใช่แค่ /announce.php ดังนั้นการบล็อกโดย URL จะไม่มีประโยชน์

วิธีการนี้ยังใช้งานได้หรือจะทำให้เกิดภาระมากเกินไปและฉันควรทิ้งการร้องขอเหล่านั้นก่อนที่พวกเขาจะไปถึง Apache?

ปรับปรุง:

ปรากฎว่าปัญหานี้ส่งผลกระทบต่อคนจำนวนมากในหลายประเทศทั่วโลก
มีรายงานจำนวนมากและโพสต์บล็อกเกี่ยวกับมันและวิธีแก้ปัญหาต่าง ๆ เพื่อบล็อกปริมาณการใช้งานนี้

ฉันได้รวบรวมรายงานบางส่วนเพื่อช่วยให้ทุกคนที่มาที่นี่ค้นหาวิธีแก้ปัญหาเพื่อบล็อกสิ่งนี้

การรับส่งข้อมูลภาษาจีนที่ผิดทิศทางลึกลับ: ฉันจะทราบได้อย่างไรว่าเซิร์ฟเวอร์ DNS ใดที่ใช้คำขอ HTTP
แปลก Bittorrent เข้าสู่ระบบเซิร์ฟเวอร์ของฉัน
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- ให้ /

— Cha0s
แหล่งที่มา

1

ฉันเห็นปัญหาที่คล้ายกันนี้ฉันได้บล็อกคำขอ แต่ฉันสงสัยว่าคุณจะทราบได้อย่างไรว่า ISP ใดที่ส่งคืนที่อยู่ IP ที่ไม่ถูกต้อง ฉันสนใจที่จะทราบว่าคำขอมาจากไหนดังนั้นจึงเป็นจุดเริ่มต้นที่ดี

— pogo

จาก whatsmydns.net และตัวตรวจสอบการแพร่กระจาย glbal dns อื่น ๆ CERNET และ CPIP ที่ประเทศจีนและ TTNET ที่ตุรกีตอบสนองต่อการสอบถามเกี่ยวกับโดเมนย่อยต่างๆของ thepiratebay.org กับ IP ต่างๆเมื่อโดเมนนั้นไม่สามารถแก้ไขได้บน ISP อื่น ๆ ทั่วโลก

— Cha0s

2

ฉันได้รับสิ่งเดียวกันและเริ่มในเวลาเดียวกันกับที่คุณสังเกตเห็น facebook, bittorrent, เว็บไซต์ลามก แต่ที่สำคัญที่สุดคืออ่าวโจรสลัดคงที่นี้ประกาศ serverfault.com/questions/658433/… ฉันใช้ nginx และฉันคืนค่า 444 หากโฮสต์ไม่ตรงกัน

— เฟลิกซ์

คำขอที่จะประกาศลดน้อยลงไปเล็กน้อย อาจเป็นเพราะการกำหนดค่า DNS ผิดพลาดชั่วคราว คุณยังเห็นการจราจรอยู่หรือไม่

— เฟลิกซ์

2

พูดตามตรงฉันลงเอยบล็อกจีนที่ระดับไฟร์วอลล์เพราะแม้กระทั่งกับ mod_security พวกเขาจะเติมการเชื่อมต่อทั้งหมดของ Apache ดังนั้นฉันจึงไม่ได้สังเกตว่าคำขอลดลงหรือไม่

— Cha0s

7

ปัญหาเดียวกันที่นี่ ฉันใช้ mod_security เพื่อบล็อก user-agent

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

ฉันจะเปลี่ยนบันทึกเป็น nolog หลังจากที่คุณตรวจสอบว่ามันใช้งานได้เพื่อหลีกเลี่ยงการเติมไฟล์บันทึกของคุณ

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

— user262546
แหล่งที่มา

1

ในขณะที่ไม่ตรงกับสิ่งที่ฉันต้องการคำตอบของคุณพาฉันไปในทิศทางที่ถูกต้องดังนั้นฉันเลือกคุณเป็นคนที่ถูกต้อง ฉันสิ้นสุดการบล็อกคำขอฝนตกหนักทั้งหมดโดยจับคู่สตริง '? info_hash =' ใน REQUEST_URI User-Agent ไม่ใช่วิธีการที่ดีที่สุดเพราะลูกค้าใช้ลูกค้า BitTorrent ที่แตกต่างกันจำนวนมากด้วย UAs ที่แตกต่างกัน กฎ mod_security สุดท้ายที่ฉันได้รับคือ:SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"

— Cha0s

ลองdig a.tracker.thepiratebay.orgจากเซิร์ฟเวอร์ DNS ใด ๆ ในรายการนี้public-dns.tk/nameserver/cn.htmlและในแต่ละคำขอจะมีคำตอบที่แตกต่างกัน แบบเดียวกับtracker.thepiratebay.orgที่ปรากฏในโฮสต์ของเรา: ส่วนหัว มีการโพสต์เกี่ยวกับเรื่องนี้ในviewdns.info/research/ ......กับไซต์เพิ่มเติมบางอย่าง การพยายามย้อนกลับที่อยู่ที่ส่งคืนบางส่วนโดยใช้viewdns.info/reverseipแสดงให้เห็นว่ามันสุ่มค่อนข้างมาก

— Evgeny

5

เรากำลังประสบปัญหาเดียวกันกับหนึ่งในเว็บไซต์ของลูกค้าของเรา ฉันเพิ่มต่อไปนี้ใกล้ด้านบนของพวกเขา:

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

RewriteCond ที่ถูกคอมเม้นต์สามารถไม่ใส่เครื่องหมายข้อคิดเห็นเพื่อบล็อกเอเจนต์ผู้ใช้เฉพาะเท่านั้น แต่พวกเขาไม่มีเนื้อหาที่ประกาศหรือประกาศดังนั้นเราจึงปิดกั้นทั้งหมด

— แดนอาร์มสตรอง
แหล่งที่มา

ขอบคุณ แต่ฉันต้องการโซลูชันที่ใช้ mod_security ไม่ใช่ mod_rewrite

— Cha0s

ดูengineering.bittorrent.com/2015/01/29/…เพื่อวิธีที่ดีกว่า (G / 410 แทน F / 403 และ ErrorDocument อย่างชัดเจน)

— ysth

5

ฉันมีปัญหาเดียวกันในขณะนี้โดยให้ตัวติดตาม torrent ชี้ไปที่เซิร์ฟเวอร์ของฉัน ฉันได้ทดลองกับ iptables ในช่วงสองสามวันที่ผ่านมาและตรวจสอบส่วนหัวและรูปแบบของคำขอและ จำกัด ให้เป็นกฎ iptables สองสามตัวที่กรองการรับส่งข้อมูลที่เป็นอันตรายจากเอเชีย (จีนมาเลเซียญี่ปุ่นและญี่ปุ่น) ฮ่องกง).

ด้านล่างเป็นกฎ หวังว่าจะช่วยใครซักคน

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
แหล่งที่มา

ดี! ฉันไม่คิดอย่างนั้น! ขอบคุณ! : D คุณเลือกที่จะREJECTใช้DROPเหตุผลบางอย่างแทนหรือไม่? (เช่น: ลูกค้าอาจหยุดหลังจากได้รับ a REJECT)

— Cha0s

1

ใช่การปฏิเสธควรบอกให้ลูกค้าหยุดขอทรัพยากรนั้นแม้ว่าจะดูเหมือนจะไม่ได้ช่วยอะไรก็ตามในกรณีนี้ มันยังคงกรองมันออกดังนั้นฉันจะปล่อยให้มันเป็น REJECT หวังว่าลูกค้าบางรายจะบอกใบ้ อย่างไรก็ตาม iptables ควรทำงานได้ดีกว่า mod_security ในงานนี้ดังนั้นฉันหวังว่ามันจะทำงานได้ดีสำหรับคุณ

— Franci

มันควรจะเป็น! ฉันกำลังปิดกั้นคำนำหน้าภาษาจีนทั้งหมด ฉันจะลองใช้วิธีนี้ดีกว่า :) ฉันคิดว่าลูกค้า BitTorrent จะไม่หยุดลองใหม่แม้กับ REJECT พวกเขาจะเห็นว่าเป็น 'การเชื่อมต่อถูกปฏิเสธ' และลองอีกครั้งในภายหลัง ฉันเชื่อว่า DROP เป็นวิธีที่ดีกว่า (และใช้ทรัพยากรน้อยลง - เพียงแค่แพ็คเก็ตลดลงทันทีที่พวกเขาได้รับการจับคู่โดยไม่ต้องดำเนินการใด ๆ เพิ่มเติม)

— Cha0s

1

ความแตกต่างนั้นค่อนข้างเล็กน้อยในทุกกรณี แต่อย่างมากและความหวังของฉันคือการยับยั้งการจราจรในที่สุด หากไม่หมุนลงฉันจะเปลี่ยนเป็น DROP ฉันสงสัยมากว่าทำไมหรืออย่างไรสิ่งนี้เกิดขึ้นในสถานที่แรกแม้ว่า มีการพูดคุยเกี่ยวกับ Great Firewall of China ที่เปลี่ยนเส้นทางไปเป็น IP แบบสุ่ม แต่ฉันค่อนข้างแน่ใจว่านี่ไม่ใช่กรณีที่นี่

— Franci

1

+1 หนึ่งที่ดี เรากำลังดำเนินการ--string "GET /announce"เพื่อครอบคลุมคำขอที่แท้จริง

— Linus Kleen

5

ฉันเขียนบทความในบล็อกเกี่ยวกับวิธีบอกกับลูกค้า BitTorrent อย่างถูกต้องให้หายไปและไม่กลับมาเหมือนกับที่แดนทำ

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 (ปกติ) มี URL มาตรฐานที่เริ่มต้นด้วย/announceหรือ/scrapeดังนั้นฉันจะไม่ยกเลิกการกรองโดย URL อย่างรวดเร็ว มันได้ผล.

โพสต์แบบเต็มคือที่ - http://dvps.me/ddos-attack-by-torrent

— Evgeny
แหล่งที่มา

1

อ่านน่าสนใจ ขอบคุณที่แบ่งปัน :) แต่ฉันเชื่อว่าการโจมตีเกิดขึ้นDNS Cache Poisoningเนื่องจาก CERNET ในประเทศจีนตอบสนองต่อโดเมน TPB ด้วย IP แบบสุ่มและไม่ใช่ภาษาจีน AFAIK PEX ใช้สำหรับการแชร์เพียร์ไม่ใช่ผู้ติดตาม คุณสามารถอธิบายเพิ่มเติมเกี่ยวกับเรื่องนั้นหรือเตรียมเอกสารบางอย่างได้หรือไม่?

— Cha0s

มีเป็นส่วนขยายสำหรับการติดตามร่วมกันอธิบายไว้ที่นี่bittorrent.org/beps/bep_0028.html แต่คุณถูกต้องในส่วนหัวของ 'Host:' สำหรับคำขอทั้งหมดนี้a.tracker.thepiratebay.orgหรือtracker.thepiratebay.orgอาจเป็นเป้าหมายที่แท้จริงของลูกค้าเหล่านี้ นอกจากนี้ยังสามารถเป็นลูกค้าปลอมได้เพียงกำบังตัวเองในฐานะคนเสเพลในภาษาจีน :)

— Evgeny

1

คน bittorrent แนะนำ 410 แทน 404: engineering.bittorrent.com/2015/01/29/…

— ysth

0

ฉันใช้ช่วง IP ของจีนจาก: http://www.wizcrafts.net/chinese-blocklist.html และบล็อกพวกเขาในไฟร์วอลล์ csf ของฉันนี่คือช่วงในกรณีที่คุณต้องการคัดลอกและวางลงในรายการ ip ของ 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

— user3601800
แหล่งที่มา

หรือคุณสามารถเพิ่มCC_DENY = "CN"บน/etc/csf/csf.confโดยอัตโนมัติและจะพบว่าคำนำหน้าจีนขึ้นอยู่กับฐานข้อมูล GeoIP Maxmind ของ

— Cha0s

ขอบคุณ แต่ฉันไม่แน่ใจว่าวิธีใดที่ใช้ทรัพยากรเซิร์ฟเวอร์น้อยลงเช่นการใช้งาน CPU, CC_DENY หรือการบล็อก IP โดยตรง ฉันจะบอกว่าการปิดกั้น IP โดยตรงนั้นดีกว่า

— user3601800

ฉันไม่เห็นความแตกต่าง เมื่อกฎ iptables ถูกโหลด (ไม่ทางใดก็ทางหนึ่ง - กฎนั้นเหมือนกันโดยพื้นฐาน) โหลดบนระบบจะเหมือนกัน ความแตกต่างเพียงอย่างเดียวคือรายการของคุณเป็นแบบคงที่ (ดังนั้นคุณจะต้องปรับปรุงให้ทันสมัยด้วยตนเอง) ในขณะที่รายการจากฐานข้อมูล GeoIP จะได้รับการปรับปรุงเป็นครั้งคราวโดยอัตโนมัติเพื่อแสดงถึงคำนำหน้าใหม่หรือล้าสมัยต่อรหัสประเทศ ไม่ว่าจะด้วยวิธีใดเมื่อคุณบล็อกส่วนนำหน้าจำนวนมากด้วย iptables คุณจะมีภาระเพิ่มเติมในระบบ โหลดมาจาก iptables เองไม่ใช่จากวิธีที่คุณพบว่าคำนำหน้าใดที่จะบล็อก

— Cha0s

ฉันต้องบอกว่าการปิดกั้นรหัสประเทศ CN ใน csf ไม่ได้ผลสำหรับฉันในวันนี้ฉันได้พบ IP ใหม่จากประเทศจีนที่ถูกบล็อกโดย mod_security

— user3601800

คำร้องขอบล็อกการปรับเปลี่ยน mod_security โดยส่วนหัว http-host

ปรับปรุง: