Tracciamento dell'indirizzo IP per prevenire abusi senza registrare i metadati dell'utente

Question

Tracciamento dell'indirizzo IP per prevenire abusi senza registrare i metadati dell'utente

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

3

Sto cercando di bilanciare le buone pratiche di sicurezza contro la registrazione eccessiva dei metadati dell'utente / Informazioni di identificazione personale.

Sto costruendo un'app Web che consente la messaggistica sicura. In parte nella progettazione del mio sistema, sto cercando di minimizzare la perdita di metadati dell'utente.

Parte della progettazione del mio sistema include un modulo che tiene traccia degli indirizzi IP per prevenire abusi, come Denial-of-Service o cracking dell'account. Mantengo il registro degli indirizzi IP solo per il tempo necessario. Un approccio diretto sarebbe quello di registrare l'indirizzo IP e un timestamp in un file di log e cancellare le voci dopo un periodo di tempo. Per evitare qualsiasi distrazione, l'intento è quello di bandire gli indirizzi IP abusivi per un determinato periodo di tempo (ad esempio, offset lineare), non in modo permanente.

Il modello di minaccia è che i registri potrebbero essere utilizzati per determinare chi stava usando il sistema e quando. Voglio che gli utenti di questo sistema abbiano fiducia che anche se un server è compromesso, i registri non sono progettati in modo tale che una terza parte possa dedurre chi ha usato il sistema e quando, per parlare con chi.

Il mio primo pensiero è che l'archiviazione di informazioni in un modulo che può essere verificato in seguito, ma non memorizzato in testo in chiaro, è simile a come si memorizzano in modo sicuro le password di sistema utilizzando una funzione di derivazione della chiave (ad esempio, l'applicazione di un hash a una passphrase e un sale per un gran numero di iterazioni). Quindi, allo stesso modo in cui una password utente può essere verificata con il suo hash basato su KDF, un IP può essere verificato con il suo hash basato su KDF nel file di log per vedere se lo stesso indirizzo IP è stato registrato prima.

Quali sono i punti di forza e di debolezza di questo approccio? Esistono metodi superiori per la memorizzazione dei metadati / informazioni personali dell'utente non in testo semplice, in un formato che può essere verificato da un'app Web?

Aggiornato per chiarire lo scopo delle app Web e il modello delle minacce.

ip web-application hash denial-of-service pbkdf2

posta taltman 18.07.2014 - 21:07

fonte

3 risposte

Leggi altre domande sui tag ip web-application hash denial-of-service pbkdf2

Sulley - Logica dietro ai primitivi Si possono considerare più frodi / corruzione più transazioni dello stesso importo in breve tempo?

score 1 · Answer 1

Diciamo che è necessario visualizzare gli IP in un periodo di 30 minuti per decidere sull'abuso. Ecco uno schema per mantenere gli IP non più di un'ora.

Ogni 30 minuti, genera una stringa casuale solo memoria, RS.

Per qualsiasi periodo di tempo, mantieni la RS corrente e precedente: rs_c, rs_p.

Per ogni IP, calcola l'hmac corrente usando la stringa casuale corrente:

IP_c = HMAC(rs_c, IP)

Archivia l'IP in una tabella:

IP_c, last-update

Calcola il conteggio ip nell'ultima ora.

func get_ip_count(ip):
  IP_p = HMAC(rs_p, IP)
  IP_c = HMAC(rs_c, IP)
  count = [select count(*) from ipHistory where IP in (IP_p, IP_c) and last-update < [30-minutes-ago]]

Finché puoi proteggere la RS, non recupererai gli IP per più della tua finestra scorrevole.

Pulisci la tabella in base all'ultimo aggiornamento / età.

delete from ipHistory where last-update < [30-minutes-ago]

score 0 · Answer 2

(Questo potrebbe essere un errore, ho un vago ricordo di una domanda simile, ma non riesco a trovarlo ora, quindi la mia memoria o il mio search-fu è difettoso, o è stato cancellato.)

Salt funziona solo se è possibile legare il valore protetto a un valore pubblico (ad esempio, sale per l'hashing, una password viene memorizzata con l'ID utente corrispondente). L'unica corrispondenza ovvia a un indirizzo IP è il nome DNS che è almeno altrettanto sensibile e non sempre 1-a-1. Pepper (fisso ma segreto) è ancora utile contro un utente malintenzionato che riceve i dati del file di log ma non l'app che lo scrive. Ma c'è una limitazione intrinseca: puoi riconoscere un hash duplicato, ma non puoi tornare facilmente all'indirizzo IP se lo desideri per qualcosa come le regole del firewall, puoi solo fare controlli basati su hash nelle app scrivi te stesso.

Per una soluzione più flessibile, potresti criptare a chiave pubblica i valori con padding deterministico (che i paddings standard NON sono, proprio per impedire il riconoscimento dei duplicati) e fornire solo la chiave privata (e temporaneamente) per amministrare app che devono essere decodificate, magari eseguite su una macchina diversa (più sicura).

Ma qualsiasi schema che rilevi duplicati può essere rinforzato da un utente malintenzionato che riceve il file di registro e il pepe o la chiave pubblica (o l'app che lo contiene), poiché lo spazio dell'indirizzo IP (per v4 e 99,99 % della rete pubblica è ancora v4) è leggermente inferiore a 32 bit.

Che apre un altro approccio: separa i dati sensibili dal rischio di compromissione. Invece di scrivere il file di log sul server web, che deve essere pubblicamente accessibile e di solito è abbastanza complicato da avere rischi di vulnerabilità, inviarlo a un altro computer che è protetto da firewall per eseguire solo un programma di registrazione di sola scrittura dead-simple - forse 20 linee di codice che può essere controllato rigorosamente.

Modifica: chiarimenti per i commenti, 2015/02/24.

Salt di per sé non ha bisogno di essere pubblico (anche se a volte lo è), ma deve essere determinato dai dati pubblici e univoco per oggetto con almeno alta probabilità se non certezza. L'esempio canonico è l'hashing della password, in cui sia il sale solitamente saltato che l'hash salato della password sono memorizzati in un database a cui accede l'utente. L'intero punto di sale deve essere diverso per valori diversi. Un valore aggiunto all'hash che è segreto (nel tuo caso al server dell'app) ma lo stesso per tutti i valori hash è pepe . Ciò è utile, come ho detto, se un utente malintenzionato può ottenere dati contenenti gli hash pepati ma non il pepe stesso.

Ho confrontato la crittografia a chiave pubblica come "flessibile" nel modo in cui è possibile utilizzare i risultati. Ad esempio, un programma di filtro può prendere un determinato IPaddr, come una nuova connessione, e cancellarlo (con il pepe) per vedere se corrisponde a una voce registrata, ma non può prendere una voce registrata o più e (a buon mercato) determinare il IPaddr (s). La crittografia a chiave pubblica può essere invertita per mostrare l'IPaddr con solo un programma specifico o (possibilmente remoto) al sistema a cui si fornisce la chiave privata, e proteggere e limitare di conseguenza.

score 0 · Answer 3

A straightforward approach would be to log the IP address and a timestamp in a logfile, and delete entries after a period of time.

Semplice ma fenomenale inefficiente. In realtà dovresti mantenere i dati dei violatori solo nella memoria indicizzata indipendente dai tuoi dati di log (probabilmente dovresti tenere i file di registro ma questa è la discussione separata ).

Dal momento che presumo che tu non senta il dovere di diligenza nei confronti dei trasgressori come fai tu ad altre persone che usano il tuo sito, questo risolve sia il problema delle prestazioni che il problema della privacy.