Quali criteri dovrebbero essere utilizzati per rivedere / stabilire manualmente l'accesso non riuscito?

Question

Quali criteri dovrebbero essere utilizzati per rivedere / stabilire manualmente l'accesso non riuscito?

#1 da (2 voti)
#2 da (2 voti)

7

Ho un'applicazione Web esposta a Internet e sono interessata a creare avvisi o dare priorità alla revisione manuale degli accessi non riusciti all'applicazione Web.

Quali soglie o formule dovrebbero essere utilizzate per determinare quando un login fallito dovrebbe essere rivisto in maggiore dettaglio? (Supponiamo che un avviso possa essere attivato su base per utente o su base per-IP.)

Alcune formule che ho provato, ma che hanno riscontrato problemi con l'applicazione coerente includono:

accessi riusciti / non riusciti per IP
Accesso riuscito / non riuscito per utente
L'utente ha mai effettuato l'accesso con successo a questo IP in precedenza? (se no, sii più prudente)

Ho eseguito un audit Proof of Concept contro le applicazioni Web esistenti e ho notato che c'erano alcuni casi di utilizzo legittimi per l'app che distorcono l'applicazione diretta dei rapporti sopra riportati:

L'utente si trova dietro un NAT o proxy condiviso (ufficio remoto).
L'utente si trova su un dispositivo domestico (o mobile) e l'IP di origine cambia sempre.
La macchina è condivisa tra molti utenti e ha un IP costante ma molti utenti

Alcune cose che sto cercando di impedire (elenco incompleto) includono:

Forza brutale nomi utente o password. (il periodo di blocco è di 24 ore)
Esecuzione dell'applicazione bloccando intenzionalmente gli utenti
Qualsiasi attacco precedente da una BotNet o TOR
Attacchi interni / attività sospette da utenti interni.

La soluzione ideale dovrebbe prendere in considerazione lo scenario seguente, ma qualsiasi approccio generale, white paper accademico o ricerca sarebbe utile.

Scenario facoltativo :: Un utente malintenzionato sta utilizzando account puppet puppet per aggiungere accessi riusciti all'account non riuscito, facendolo apparire come NAT sopra.

audit web-application ids

posta random65537 29.12.2013 - 18:03

fonte

2 risposte

Leggi altre domande sui tag audit web-application ids

Privacy del telefono per le piccole imprese WebRTC P2P SSL - Dove vengono generate le chiavi?

score 2 · Answer 1

Al valore nominale, questo è facile, ma come chiunque può dire leggendo la tua domanda (o per quelli di noi che hanno implementato qualcosa in questo senso) questo diventa rapidamente un barattolo di vermi.

Analizziamo alcune potenziali metriche ...

Tentativi falliti per username - la metrica standard con cui un account viene bloccato, tenerlo basso e la maggior parte degli attacchi verrà bloccato.

nomi utente non validi per IP per x ore : la visualizzazione di 100 tentativi di accesso per nomi utente univoci non validi in un'ora dallo stesso IP è un buon indicatore di attività dannose.

utenti bloccati per violazione dell'IP nelle ultime x ore - Se un IP ha causato il blocco di numero di utenti nelle ultime x ore, è sospetto. Vorresti confrontare questo con il numero di utenti unici riusciti connessi da quell'IP. Se ci sono stati un buon login e 40 utenti bloccati, sta succedendo qualcosa di interessante e vale la pena proibire l'IP fino a quando un'indagine può confermare.

avg & il numero massimo di accessi utente validi per IP su x ore / giorni - fornisce una buona base per l'utilizzo standard delle reti NAT.

La chiave è costruire linee di base e segnalare eventuali anomalie per la revisione manuale o l'azione automatica. Tale azione automatica potrebbe bloccare un utente, vietare o limitare la velocità di un IP, contrassegnare un IP o un utente come sospetto e richiedere tutti gli accessi da tale fonte per passare ulteriori passaggi di prevenzione bot, ad esempio CAPTCHA e / o verifica email.

Alcuni siti richiedono questi passaggi di verifica aggiuntivi da qualsiasi utente che acceda da un nuovo dispositivo, anche questo ridurrà notevolmente il potenziale per un attacco basato sull'utente.

Per quanto riguarda lo scenario opzionale, diciamo che stanno usando i conti burattini per soddisfare le linee di base per apparire come un ambiente NAT. Diciamo che hanno 100 accts che accedono con successo. Se stanno cercando di entrare in un account specifico, quell'account verrà bloccato dopo 3-4 tentativi. Supponendo che si disponga di una password decente, l'attacco è impedito. Diciamo che stanno cercando di entrare in uno dei 10 account, sarebbero 10 account bloccati in un'ora da un ambiente NAT essere normali? Dubbio ... Segnala l'IP per attività sospette che richiedono agli utenti di verificare la loro umanità dopo un tentativo fallito di password.

Garantire che gli utenti vengano bloccati in un tempo ragionevolmente rapido preverrà la maggior parte degli attacchi di forza bruta. L'aggiunta di metriche basate su IP per utenti bloccati, utenti non validi e altre metriche correlate rispetto alle linee di base e legata alla prevenzione bot standard e ai metodi di verifica dell'utente ridurranno ulteriormente il rischio e assicureranno auditor, amministratori di sistema e utenti.

score 2 · Answer 2

Difficile per una risposta diretta poiché non ho alcuna indicazione sul numero di utenti che hai, o che intendi avere, che accedono al tuo server. Se questo colpisce migliaia, ti sparerai ai piedi con così tanti falsi positivi, che alla fine ignorerai tutti gli avvisi.

Quindi aggiungerò i miei due centesimi a questo stile da avvocato del diavolo:

Forza brutale nomi utente o password. (il periodo di blocco è di 24 ore)

Attivo se qualcuno bruta forza un nome utente legittimo, attiverà un avviso che blocca un utente legittimo. Moltiplicalo per N e ora hai N quantità di utenti irked.

Esecuzione dell'applicazione bloccando intenzionalmente gli utenti

Anche questo è "non intenzionale" vedi sopra "

Qualsiasi attacco precedente da una BotNet o TOR

Anche questo è "non intenzionale" vedi sopra "

Attacchi interni / attività sospette da utenti interni.

Se devi preoccuparti degli utenti interni, hai più grandi problemi.

Ecco cosa farei e ho fatto: perché la maggior parte della mia base utente che ha bisogno di " accedere " a qualcosa, di solito proviene da luoghi definiti (un ISP, un'azienda, ecc. Tendo a consentire a quelli in (tramite firewall) e bloccare il resto. Questa è una pratica generale, tuttavia, non è per tutti, il mio metodo sarebbe il seguente:

1) Captcha o Cloudflare - il ragionamento per questo è semplice; la maggior parte degli "attacchi" al giorno d'oggi sono principalmente automatizzati. Captcha e Cloudflare ridurranno al minimo questi tipi di attacchi.

2) Strong firewalling / ACL - se dici di essere in Nord America, hai VERAMENTE bisogno del tuo server visibile alle reti APNIC, RIPE, LACNIC, AFRINIC? (Google quelli se non capisci cosa sono)

3) Registrazione e monitoraggio SIEM - ancora una volta, cosa dura da menzionare anche perché non conosco la dimensione della rete, i registri, ecc. , quindi ignorare TUTTI I CONOSCENTI, quindi avvisare per gli sconosciuti prima di bloccare.

Le reti sono diverse, quindi probabilmente otterrai una risposta migliore con una descrizione migliore. Ad esempio, ho un'app Web, a cui si accede dalla quantità N di utenti. Ho / non ho un budget, ecc.