Come posso bloccare bot che colpiscono costantemente gli stessi URL?

4

I bot vengono sbattuti duramente e non sono sicuro di come fermarli senza bloccare il mio traffico legittimo. Ho creato alcune regole di iptables che dicono, se le connessioni X in X secondi, bloccano, ma questo non mi fa molto bene quando il bot fa solo 2 o 3 richieste ogni 30 secondi.

Idealmente, vorrei identificare questi bot con gli URL e quante volte stanno raggiungendo quell'URL, sono sicuro di poterlo fare con del codice, ma mi stavo chiedendo se qualcuno là fuori abbia già una soluzione che non coinvolgere il codice e preferibilmente bloccare tramite iptables .

Tutte le idee, i pensieri, i suggerimenti sono molto apprezzati.

Ecco l'output del mio registro di accesso:

27.153.233.93 - - [02/Nov/2013:10:44:54 +0000] "GET /register/ HTTP/1.1" 200 8296
192.99.2.188 - - [02/Nov/2013:10:44:54 +0000] "GET /register/ HTTP/1.1" 200 8296
110.86.164.186 - - [02/Nov/2013:10:44:54 +0000] "GET /register/ HTTP/1.1" 200 8296
121.205.239.188 - - [02/Nov/2013:10:44:54 +0000] "POST /register/ HTTP/1.1" 44 339
27.153.233.93 - - [02/Nov/2013:10:44:54 +0000] "POST /register/ HTTP/1.1" 44 339
36.251.24.146 - - [02/Nov/2013:10:44:54 +0000] "GET /wp-login.php HTTP/1.1" 200 1655
110.86.164.186 - - [02/Nov/2013:10:44:55 +0000] "POST /register/ HTTP/1.1" 44 339
192.99.2.188 - - [02/Nov/2013:10:44:54 +0000] "POST /register/ HTTP/1.1" 302 20
110.85.107.18 - - [02/Nov/2013:10:44:56 +0000] "GET /register/ HTTP/1.1" 200 8296
110.86.187.169 - - [02/Nov/2013:10:44:56 +0000] "GET /register/ HTTP/1.1" 200 8296
125.117.214.174 - - [02/Nov/2013:10:44:55 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 1166
110.85.107.18 - - [02/Nov/2013:10:44:56 +0000] "POST /register/ HTTP/1.1" 44 339
110.86.187.169 - - [02/Nov/2013:10:44:56 +0000] "POST /register/ HTTP/1.1" 44 339
192.99.2.188 - - [02/Nov/2013:10:44:55 +0000] "GET / HTTP/1.1" 200 10718
110.89.13.58 - - [02/Nov/2013:10:44:57 +0000] "GET /register/ HTTP/1.1" 200 8296
36.251.24.146 - - [02/Nov/2013:10:44:57 +0000] "POST /wp-login.php HTTP/1.1" 302 20
110.89.13.58 - - [02/Nov/2013:10:44:57 +0000] "POST /register/ HTTP/1.1" 44 339
218.86.50.83 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
218.86.50.83 - - [02/Nov/2013:10:44:58 +0000] "POST /register/ HTTP/1.1" 44 339
117.26.195.51 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
120.43.20.103 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
121.205.196.193 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
117.26.195.51 - - [02/Nov/2013:10:44:58 +0000] "POST /register/ HTTP/1.1" 44 339
120.43.20.103 - - [02/Nov/2013:10:44:58 +0000] "POST /register/ HTTP/1.1" 44 339
120.37.207.234 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
27.153.210.2 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
121.205.196.193 - - [02/Nov/2013:10:44:59 +0000] "POST /register/ HTTP/1.1" 44 339
120.37.207.234 - - [02/Nov/2013:10:44:59 +0000] "POST /register/ HTTP/1.1" 44 339
120.37.206.69 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
120.37.206.69 - - [02/Nov/2013:10:44:59 +0000] "POST /register/ HTTP/1.1" 44 339
27.159.234.10 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
27.159.234.10 - - [02/Nov/2013:10:45:00 +0000] "POST /register/ HTTP/1.1" 44 339
    
posta Jeffrey L. Roberts 02.11.2013 - 11:51
fonte

5 risposte

7

Sembra che Fail2ban si adatti perfettamente al tuo scenario. È piuttosto configurabile, quindi dovresti essere in grado di configurare ciò di cui hai bisogno consultando la documentazione un po '.

    
risposta data 02.11.2013 - 13:43
fonte
4

Non hai molte informazioni in quel registro, quindi devi assumere qualcosa (o usare qualche strumento che lo faccia per te).

Ad esempio, supponi che la maggior parte dei tuoi clienti si trovi in USA / EMEA. Quindi forse tutti gli IP provenienti dalla Cina possono essere bloccati. Puoi ottenerli con WHOIS dai log o provare i servizi online:

  • IPDeny sembra non avere dati: link
  • NirSoft ha qualcosa, ma non troppo aggiornato ( link )
  • Il link ha anche il supporto di formato .htaccess

Manualmente (con il vantaggio di bloccare solo sottoreti realmente "colpevoli"):

$ whois 218.86.50.83 | grep "country\|inetnum" | sort | uniq
country:        CN
inetnum:        218.85.0.0 - 218.86.127.255
# iptables-deny 218.85.0.0/15

$ # Repeat for all "suspicious" IPs in your access.log

Per scoprire chi ti sta colpendo, puoi fare una statistica su access.log e i primi bit dell'IP in entrata, raggruppando per ora:

$ grep "GET /register/" /path/to/access.log| cut -f 1,4 -d " " | cut -f1-2 -d: | sed -e 's/\(.*\)\.[0-9]* .*:\(.*\)/ /g' | sort | uniq -c | sort -n

Se desideri raggruppare per reti più ampie,

$ grep "GET /register/" /path/to/access.log | cut -f 1,4 -d " " | cut -f1-2 -d: | sed -e 's/\(.*\)\.[0-9]*\.[0-9]* .*:\(.*\)/ /g' | sort | uniq -c | sort -n

Questo per il tuo campione ti dà

  1 10 110.85
  1 10 110.89
  1 10 117.26
  1 10 120.43
  1 10 121.205
  1 10 192.99
  1 10 218.86
  1 10 27.159
  2 10 110.86
  2 10 120.37
  2 10 27.153

e ora puoi cercare, ad esempio, ^ 27.153 nel file access.log (ancora in Cina, ancora coperto da ip2location).

    
risposta data 02.11.2013 - 13:46
fonte
3

Sarebbe molto meglio fermare questo tipo di attacchi sul perimetro piuttosto che sul server stesso. La maggior parte dei firewall del livello applicazione viene fornita con un elenco di reputazione IP. Non voglio raccomandare alcun prodotto specifico, ma CISCO, Juniper e la maggior parte degli altri fornitori che forniscono funzionalità firewall e IDP forniscono anche servizi di reputazione IP. Consulta il tuo team di rete e loro possono fornirti le impostazioni specifiche di cui hai bisogno.

Inoltre, puoi utilizzare Mod Security che è un firewall a livello di applicazione open source. Il vantaggio della sicurezza mod è che oltre alla vasta gamma di attacchi che può arrestare, ha anche la possibilità di registrare le richieste HTTP POST complete. Apache non lo fa per impostazione predefinita. Una volta ottenuto il pacchetto completo, è possibile analizzarlo per qualsiasi firma di attacco. Ad esempio, se il bot dovesse utilizzare un particolare parametro POST o una lunghezza di intestazione del pacchetto, ecc, è possibile sviluppare anche firme di attacco basate su quei parametri.

    
risposta data 02.11.2013 - 14:16
fonte
2

se quegli URL sono legittimi, fail2ban come terry menzionato sarebbe il modo più semplice per andare. un altro modo, ma molto più complicato in termini di configurazione e manutenzione, sarebbe quello di usare snort / suricata; ha anche soglie / limiti di velocità, e i blocchi basati su ip potrebbero essere cancellati dopo un certo periodo di tempo.

Il problema

si verifica quando hai solo 1 o 2 hit per bot su questi URL; l'unica possibilità di bloccare i tentativi malevoli senza interessare gli utenti normali mi viene in mente (ma potrebbe influire sugli utenti legittimi)

  • cambia / registra / su / registra-solo-umani / nella tua applicazione
  • blocca chiunque tenti di utilizzare / register /

btw, il tuo registro di accesso vede mancare alcuni valori, come il referer e l'user-agent. puoi vedere un modello, basato sull'agente utente, ad esempio, è sempre lo stesso? se è così, puoi anche provare a bloccare in base a uri / user-agent.

se tali URL non sono legittimi, blocca chiunque desideri accedervi.

    
risposta data 03.11.2013 - 09:18
fonte
1

Come già detto, puoi bloccare l'intero paese e puoi anche bloccare gli IP dai server: da Amazon Datacenter come esempio.

Sto utilizzando l'elenco di IP fornito da: link

Puoi usare un filtro fail2ban come questo:

[Definition]
failregex = ^ .* POST /register.*
            ^ .* PUT /register.*

e il file di configurazione corrispondente:

[register]
enabled  = true
port     = http,https
filter   = wp-login
action = iptables-multiport[name=wp-login, port="http,https", protocol=tcp]
logpath  = /var/log/.../*access.log
bantime = 36000
findtime = 172800
maxretry = 4
    
risposta data 29.07.2015 - 20:13
fonte

Leggi altre domande sui tag