Newsgroup: it.comp.os.linux.sys
Titolo: Prevenire il brute forcing

Salve, sono nuovo nel ng (nel senso che questo è il mio primo
messaggio).
Sto facendo una ricerca - per la tesi - sulla sicurezza delle web
application e dell'ambiente LAMP in generale: in particolare ora mi
sto chiedendo come prevenire un brute forcing alla pagina di login di
un sito.
A livello applicativo ho impostato un numero di tentativi oltre i
quali blocco temporaneamente l'IP address remoto. Ma se l'attaccante
usasse un proxy o fosse comunque dietro una rete che cambiasse l'IP ad
ogni richiesta?
Ho cercato in giro qualche soluzione attraverso i moduli di Apache e
ho provato mod_cband: in questo modo imposto il numero di richieste
accettate in un intervallo di tempo di un secondo; il problema è che
la validità della regola è a livello di VirtualHost.
Vorrei applicare quella funzione alla sola pagina di login. È
possibile? Esistono moduli che fanno quel lavoro?
Vi ringrazio in anticipo per l'attenzione.

 .....
Il sistema perfetto non esiste.
Un buon sistema (anche semplice) e' quello di aggiungere un delay di 
qualche secondo prima che il server risponda con un'autorizzazione 
fallita (401). Ovviamente se la password e' difficilmente indovinabile - 
come si spera che lo sia.
Un altro sistema (piu' rigido - applicabile in alcuni particolari casi) 
e' quello di bloccare l'account dopo N tentativi consecutivi di accesso 
falliti - e questo indipendentemente dall'ip di provenienza di chi 
prova......
Ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 credenziali impieghi - che so - cinque secondi a girare, sempre ?
Vale anche per l'altra risposta: IMHO non è una grande idea, e risolve poco.
I bruteforce che si stan vedendo da alcuni mesi a questa parte, sui
servizi più disparati (HTTP, POP, ecc)[1] nel caso di HTTP possono
giungere da centinaia di IP diversi contemporaneamente.
Un approccio tipo quello che citi è efficace se è lo stesso IP a tentare
plurime validazioni: se lavora in parallelo ti fraga comunque, ma ha un
limite al numero di sessioni parallele che può aprire.
Se sono più macchine separate a effettuare il bruteforce, il fatto di
introdurre un delay serve solo a peggiorare le cose: aumenti di
parecchio la permanenza in memoria degli script php verso cui viene
tentato l'abuso, e nulla di più facile di ritrovarsi DoSsati per
saturazione...
Il delay genericamente va bene liddove l'applicazione che la applica è
multithreaded, oppure con bassissimo footprint sulla memoria, ma non lo
applicherei a pagine php, tantomeno se di qualche complessità...
Tutto IMHO, ovviamente...
[1]opera di rumeni, pare, e alla base delle svariate attività di
phishing Bancaintesa/PosteItaliane, ecc
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 prova......
Mh! Sì, anche a questo avevo pensato, piuttosto in ritardo però. È che
la mia tesi è accompagnata da un tirocinio e ora non voglio rimettermi
a sviluppare il modulo per l'autenticazione. Comunque anche qui, come
per l'indirizzo IP, si sfocia in un DoS!
Il fatto è che il modulo mod_cband è interessante: se ho tempo magari
vedo se in futuro potrei dare una mano nello sviluppo; la limitazione
ai VirtualHost mi sembra una imposizione troppo restrittiva. Sarebbe
bello ridefinire la validità delle direttive a livello Directory o
File!
Grazie per i suggerimenti e le sagge considerazioni.

[CUT] captcha sulla pagina di login ?
Già. L'unica soluzione è quella che il bruteforcing sia fatto a manina
da un uomo (o una scimmia ammaestrata?) così il tempo di delay viene
naturale.

 BOH... captcha sulla pagina di login ?
Heh. Può essere una via.
Sia chiaro che non ho una soluzione "pronta", esprimo solamente
un'opinione...
Per quel che ho visto girare finora, banalmente aiuta già il fatto di
instaurare una sessione all'atto della presentazione della form e, in
fase di validazione credenziali, verificare che il client si presenti
con una sessione già esistente: se non lo fa, si ignora direttamente la
richiesta di autenticazione senza nemmeno guardare quali credenziali
sono state fornite.
Quantomeno, mitiga le metodologie che si son viste fin'ora, non è detto
che in futuro 'sti bruteforcer non si facciano più scaltri...


 per l'indirizzo IP, si sfocia in un DoS!
Esatto, anche con il lock dopo N tentativi falliti si rischia di
esporsi ai DoS, ma in alcuni casi (tipicamente i sistemi bancari)
questo è noto ed accettato. Comunque è un Dos "personale" ed è molto
meno dannoso di un DoS "sistematico" come quello a cui accennava skull
in cui rischi di cadere se cerchi di applicare logiche tipo "tarpit"
alle web application.
Tuttavia La policy "blocco account dopo N tentativi" può essere
mitigata con:
1) utilizzo di una parte pubblica delle credenziali (lo userid) scelta
anch'essa con criteri "strong" e magari sostituibile con procedura di
reset.
(la ratio è: se tentano di brutaforzarti, l'account è già in parte
compromesso perchè è stata svelata almeno una parte dello stesso,
meglio saperlo per tempo)
2) sblocco automatico dopo un tempo ragionevole (tipo dopo un'ora).
Tecnicamente realizzare la parte 1) può essere molto difficile se,
come spesso capita nelle web application, la userid viene utilizzata
anche come "chiave" per l'anagrafica utenti. Meglio essere previdenti
ed utilizzare una chiave naturale (ad es. codice fiscale) o comunque
una chiave sintetica non strettamente collegata con una delle
credenziali di accesso, in modo da poter preparare agevolmente una
procedura di reset.

 I bruteforce che si stan vedendo da alcuni mesi a questa parte, .....
forse non si intendeva dall'altra mia risposta che la protezione dipende 
anche molto dall'applicativo che si vuole tenere riservato.
Se l'account che vuoi proteggere e' (che so) una semplice limitazione ad 
un'area informativa riservata, allora metterei il delay + un captcha 
(come ha anche suggerito Cujo). Il captcha proteggerebbe dai brute 
forcing automatizzati, il delay dai brute forcing manuali.
Se invece mi si da' la possibilita' di entrare in un account su 
(esempio) un home-banking, allora (tra le altre misure di sicurezza) 
darei al massimo la possibilita' di sbagliare 3 o 4 volte le credenziali 
e poi bloccherei incondizionatamente l'accesso. Che questo crei un DoS 
e' cosa indiscussa - ma qui sarebbe e' il male minore...


 plausibile?
certo, contribuirai a migliorare il livello di sicurezza di quella
organizzazione/azienza/comunita'/o-che-altro ;)
PS ovviamente fa eccezione telecom, vedi rbl e gestione spam

 BOH... captcha sulla pagina di login ?
Mi sembra una buona idea.
Mi chiedevo, però, se un tool di brute force scritto ad hoc per una
determinata pagina di loign non sia in grado di bypassare anche un
captcha utilizzando qualcosa di simile a fuzzyocr.

 sono state fornite.
Beh, non vedo particolari problemi nel mettere in piedi un tool
session-capable...:-/

 session-capable...:-/
Tutt'altro: è banale.
Purtuttavia ora come ora se ne vedono pochi, ed è un check banale e a
costo zero.
Similmente, form con campi non visualizzati dal browser: l'utente non li
vede e non li riempirà, mentre i bot in circolazione non sono in grado
di distinguerli dai campi "normali", e permette di saltare direttamente
l'analisi di qualsiasi POST si presenti con quei campi popolati...
Se il campo password non si chiama password, il quale è invece un campo
nascosto in tal guisa, poi...
Sono cose stupide e banali, ma aiutano più di quanto sembri, contro i
bot attualmente in circolazione.


whiplash ha scritto:

piu` pragmaticamente mi chiedo se sia compatibile con la legge stanca
;)

 di distinguerli dai campi "normali", [CUT]
È anche vero che un probabile attaccante si studi prima un po' come
funzioni il sito e poi sferri l'attacco. Uno scriptino ad-hoc e il
brute forcing parte.
Quello che mi ha destato meraviglia è il fatto di non aver trovato
nessun buon tool (modulo Apache) per limitare il numero di richieste
al minuto per una determinata pagina o directory web: mod_cband è una
mezza soluzione.
Oppure si potrebbe fare in modo che i dati relativi agli accessi alle
pagine vengano salvati lato server dall'applicazione per agire secondo
una determinata politica.
Apparentemente la soluzione più semplice sembrano i captcha, ma come
si comportano i grandi portali che non usano captcha per autenticare
l'utente? Non sono a rischio di brute-forcing? Si tutelano bloccando
l'account? Sono queste le domande che mi sono sorte.

 mezza soluzione.
dospagecount di mod_dosevasive

 un sito.
captcha dopo 3 tentativi su uno userid
come fa gmail ad esempio
-- 
777 fanno 21, arriva la volante e non c'è nessuno

 l'account? Sono queste le domande che mi sono sorte.
Di solito bloccano l'utente, oppure sono effettivamente vulnerabili (sì,
parecchi).


 come fa gmail ad esempio
Io scemo ad azzeccare sempre la prima volta la password: potevo
provarci prima di chiedere una valida soluzione sul ng, ma vedo che i
messaggi sono stati numerosi e forse non è stato un messaggio di
troppo!

 provarci prima di chiedere [CUT]
Ho provato proprio ora a sbagliare password, ma dopo tre tentativi e
anche di più tutto uguale: chiede user e password e nessun tipo di
captcha. Mah! Chissà come funzionano i meccanismi interni di
diogoogle.

 diogoogle.
Stai usando un account con il quale ti sei già loggato? Forse hai
ancora settato un cookie di sessione e quindi il server "ti conosce"
ed evita di passare al captcha. Prova con uno username a caso. O forse
c'e' anche qualche giochino con un hidden field o un javascript
cattura-bot, ora non ho voglia di andarci a guardare, ma tu puoi
farlo... use the source, Luke, use the source... ;^D
bye e IBAL per la tesi.

 
ê 100 volte più probabile che t'arrivi un bruteforcing ignorante ed
automatizzato che un attacco ad-hoc contro il tuo sito pubblico (a meno che
tu non sia una banca, chiaramente).
-- 
Vide

 tu non sia una banca, chiaramente).
Appunto. Non stavo riflettendo sulla sicurezza degli accessi al mio
blog! :-)
Credo comunque che siano emerse nella discussione soluzioni
interessanti.

 ancora settato un cookie di sessione e quindi il server "ti conosce" [CUT]
Vero, un controllo troppo frettoloso il mio.
Vabè, crepi il lupo: intanto sta finendo il tirocinio, "ho una barca
da scrivere" e... poi un esame, poi mi sa che la devo chiedere, la
laurea!

possibile? Esistono moduli che fanno quel lavoro?
Secondo me se usi pass di 9 caratteri alfanumerici non
dovresti preoccuparti di brute force... mi sembra paranoico.
Al limite puoi fare digitare le letterine generate a random dalle GD
cosě impedisci le prove ad eventuali script "automatici".
                                                -- Yena --