richieste di blocco mod_security tramite intestazione http-host


16

Negli ultimi giorni ho notato che alcuni server venivano martellati con richieste sconosciute.

La maggior parte di questi sono i seguenti:

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 -

Dopo un po 'di registrazione e ricerca ho scoperto che alcuni ISP cinesi (probabilmente CERNET secondo i risultati di whatsmydns.net) e alcuni ISP turchi (probabilmente TTNET) rispondono a domande DNS come a.tracker.thepiratebay.orgcon vari IP che non hanno nulla a che fare con piratebay o torrent. In altre parole, sembrano fare una sorta di avvelenamento da cache DNS per qualche bizzarro motivo.

Quindi centinaia (se non migliaia) di clienti bittorrent in quei paesi fanno tonnellate di "annunci" ai miei server web, il che si traduce in un attacco DDoS che riempie tutte le connessioni di Apache.

Al momento ho bloccato del tutto la Cina e la Turchia e fa il suo lavoro, ma vorrei trovare un modo migliore per bloccare quelle richieste.

Stavo pensando di bloccare quelle richieste con mod_security basato sull'intestazione dell'host HTTP.

Tutte queste richieste includono un'intestazione host HTTP come a.tracker.thepiratebay.org(o molti altri sottodomini del dominio thepiratebay.org).

Ecco un dump delle intestazioni della richiesta tramite la $_SERVERvariabile 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

Quindi la mia domanda è: come posso bloccare le richieste in arrivo ad Apache in base al dominio della richiesta (intestazione host HTTP)? Tieni presente che le richieste si trovano su vari URL non solo /announce.php, quindi il blocco tramite URL non è utile.

Inoltre, questo approccio è praticabile o causerà un carico eccessivo e dovrei continuare a eliminare quelle richieste prima ancora che raggiungano Apache?

Aggiornare:

Si scopre che questo problema ha colpito molte persone in molti paesi del mondo.
Ci sono stati numerosi report e blogposts a riguardo e varie soluzioni per bloccare questo traffico.

Ho raccolto alcuni dei rapporti per aiutare chiunque venga qui a cercare una soluzione per bloccarlo.

Misterioso traffico cinese indirizzato in modo errato: come posso sapere quale server DNS è stato utilizzato da una richiesta HTTP?
Strano Bittorrent Accedi al mio server
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+Varieus+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/


1
Sto riscontrando un problema simile a questo, ho bloccato le richieste ma mi chiedevo come avessi capito quali ISP stavano restituendo gli indirizzi IP errati? Sono interessato a scoprire da dove provengono le richieste in modo che sembri un buon punto di partenza
pogo

Secondo whatsmydns.net e altri controllori di propagazione del dns glbal, CERNET e CPIP in Cina e TTNET in Turchia rispondono alle domande su vari sottodomini di thepiratebay.org a vari IP quando quel dominio non si risolve su nessun altro ISP in tutto il pianeta.
Cha0s

2
Sto ottenendo la stessa identica cosa ed è iniziata nello stesso momento in cui l'hai notato. facebook, bittorrent, siti porno. ma in particolare questa costante baia dei pirati annuncia. serverfault.com/questions/658433/… Sto usando nginx e ho restituito 444 se l'host non corrisponde.
Felix,

le richieste di annuncio sono diminuite di un bel po '. forse è stata una configurazione errata del DNS temporaneo. vedi ancora traffico?
Felix,

2
Ad essere sincero, alla fine ho bloccato la Cina a livello di firewall perché anche con mod_security avrebbero riempito tutte le connessioni di Apache. Quindi non ho notato se le richieste sono state ridotte.
Cha0s

Risposte:


7

Lo stesso problema qui. Sto usando mod_security per bloccare lo user-agent

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

Vorrei cambiare il registro in nolog dopo aver verificato che funzioni per evitare di riempire il file di registro

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

1
Sebbene non sia esattamente ciò di cui avevo bisogno, la tua risposta mi ha guidato nella giusta direzione, quindi ho scelto la tua come quella corretta. Ho finito per bloccare tutte le richieste torrent abbinando la stringa '? Info_hash =' su REQUEST_URI. User-Agent non era l'approccio migliore perché i client utilizzano molti client bittorrent diversi con UA ​​diversi. L'ultima regola SecRule REQUEST_URI "\?info_hash\=" "id:10000002,rev:1,severity:2,nolog,msg:'Torrent Announce Hit Detected'"
mod_security

Provare dig a.tracker.thepiratebay.orgda qualsiasi server DNS in questo elenco public-dns.tk/nameserver/cn.html e su ogni richiesta c'è una risposta diversa. Lo stesso per tracker.thepiratebay.orgcui è apparso anche nel nostro Host: header. C'è un post a riguardo su viewdns.info/research/… con alcuni siti aggiuntivi. Cercare di invertire alcuni degli indirizzi restituiti usando viewdns.info/reverseip mostra che è praticamente casuale.
Evgeny,

5

Stiamo riscontrando esattamente lo stesso problema con uno dei siti dei nostri clienti. Ho aggiunto quanto segue nella parte superiore del loro:

# 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 commentato può essere decommentato per bloccare solo un agente utente specifico. Ma non hanno alcun contenuto su Annuncio o Annuncio.php, quindi abbiamo appena bloccato tutto.


Grazie, ma avevo bisogno di una soluzione usando mod_security e non mod_rewrite.
Cha0s

vedere engineering.bittorrent.com/2015/01/29/… per un modo migliore (G / 410 anziché F / 403 e un documento di errore esplicito)
ysth

5

Al momento sto riscontrando lo stesso problema, poiché i tracker torrent puntano sul mio server. Ho sperimentato iptables negli ultimi due giorni e ho ispezionato intestazioni e modelli delle richieste e ridotto a un paio di regole iptables che filtra praticamente tutto il recente traffico apparentemente dannoso proveniente dall'Asia (Cina, Malesia, Giappone e Hong Kong).

Di seguito sono riportate le regole. Spero che aiuti qualcuno.

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

Bello! Non ci avevo pensato! Grazie! : D Hai scelto di REJECTinvece di DROPper qualche motivo particolare? (vale a dire: i clienti possono smettere dopo aver ricevuto un REJECT?)
Cha0s

1
Sì, REJECT dovrebbe dire al client di smettere di richiedere quella risorsa anche se in questo caso non sembra essere d'aiuto. Lo filtra ancora, quindi lo lascerò come REJECT sperando che alcuni clienti diano un suggerimento. In ogni caso, iptables dovrebbe funzionare molto meglio di mod_security in questo compito, quindi spero che funzioni bene per te.
Franci,

Sì dovrebbe! Stavo bloccando tutti i prefissi cinesi. Proverò questo approccio che è meglio :) Penso che i client bittorrent non smetteranno di riprovare anche con REJECT. Lo vedrebbero come "connessione rifiutata" e riprovare dopo un po '. Credo che DROP sia un approccio migliore (e utilizza meno risorse - semplicemente rilascia i pacchetti nel momento in cui vengono abbinati senza ulteriore elaborazione)
Cha0s

1
La differenza è piuttosto trascurabile in realtà in tutti i casi, tranne che in casi estremi, e la mia speranza è stata quella di dissuadere il traffico. Se non compone il numero, lo cambierò in DROP. Sono molto curioso di sapere perché o come sia potuto accadere, in primo luogo. Ci sono alcune discussioni sul Great Firewall della Cina che reindirizza a IP casuali, ma sono abbastanza sicuro che non sia così.
Franci,

1
+1 Bello. Stiamo andando con --string "GET /announce", però, per coprire la richiesta effettiva .
Linus Kleen,

5

Ho scritto un post sul blog su come dire correttamente ai clienti BitTorrent di andarsene e non tornare mai più, simile a quello che ha fatto Dan, ma usando 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";
    }
}

I tracker dei torrent (di solito) hanno un URL standard che inizia con /announceo /scrape, quindi non chiuderei il filtro per URL così rapidamente. Funziona.

Il post completo è all'indirizzo - http://dvps.me/ddos-attack-by-torrent


1
Lettura interessante. Grazie per la condivisione :) Ma credo che l'attacco sia stato indotto da DNS Cache Poisoningquando CERNET in Cina risponde ai domini TPB con IP casuali e non cinesi. AFAIK PEX è per la condivisione di colleghi, non di tracker. Puoi approfondire ulteriormente o fornire un po 'di documentazione?
Cha0s

Esiste un'estensione per la condivisione dei tracker descritta qui bittorrent.org/beps/bep_0028.html . Ma hai ragione nel dire che l' intestazione 'Host:' per tutte queste richieste è a.tracker.thepiratebay.orgo tracker.thepiratebay.orgche potrebbe essere o meno il vero target di questi client. Può anche essere un falso cliente che si maschera da credente cinese :)
Evgeny,

1
la gente bittorrent suggerisce 410 invece di 404: engineering.bittorrent.com/2015/01/29/…
ysth

0

ho preso gli intervalli IP cinesi da: http://www.wizcrafts.net/chinese-blocklist.html e li ho bloccati nel mio firewall CSF, ecco gli intervalli nel caso in cui si desidera copiare e incollare nell'elenco IP negato di 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

Oppure si può semplicemente aggiungere CC_DENY = "CN"su /etc/csf/csf.confe troverà automaticamente i prefissi cinese basata sul database di GeoIP MaxMind.
Cha0s

grazie, ma non sono sicuro in che modo consuma meno risorse del server come l'utilizzo della CPU, il CC_DENY o il blocco diretto dell'IP. Direi che il blocco diretto dell'IP è migliore.
user3601800,

Non vedo alcuna differenza. Una volta caricate le regole di iptables (in un modo o nell'altro - le regole sono essenzialmente le stesse) il carico sul sistema sarà lo stesso. L'unica differenza è che il tuo elenco è statico (quindi dovrai tenerlo aggiornato manualmente) mentre l'elenco dal database GeoIP verrà aggiornato di volta in volta automaticamente per riflettere eventuali prefissi nuovi o obsoleti per codice paese. In ogni caso, quando blocchi molti prefissi con iptables, avrai un carico extra sul sistema. Il carico proviene dagli stessi iptables, non dal modo in cui trovi i prefissi da bloccare.
Cha0s

devo dire che il blocco del codice paese CN nel CSF non ha funzionato per me, oggi ho trovato nuovi IP dalla Cina bloccati da
mod_security
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.