Seguimiento de la dirección IP para evitar el abuso sin registrar los metadatos del usuario

Question

Seguimiento de la dirección IP para evitar el abuso sin registrar los metadatos del usuario

#1 de Jonathan (1 votos)
#2 de dave_thompson_085 (0 votos)
#3 de symcbean (0 votos)

3

Estoy tratando de equilibrar las buenas prácticas de seguridad con el registro excesivo de los metadatos del usuario / Información de identificación personal.

Estoy construyendo una aplicación web que permite la mensajería segura. En parte del diseño de mi sistema, estoy tratando de minimizar la pérdida de metadatos del usuario.

Parte del diseño de mi sistema incluye un módulo que rastrea las direcciones IP para evitar abusos, como la denegación de servicio o el descifrado de cuentas. Solo mantengo el registro de direcciones IP durante el tiempo que sea necesario. Un enfoque directo sería registrar la dirección IP y la marca de tiempo en un archivo de registro, y eliminar las entradas después de un período de tiempo. Para evitar cualquier distracción, la intención es prohibir las direcciones IP abusivas durante un tiempo determinado (es decir, un desplazamiento lineal), no de forma permanente.

El modelo de amenaza es que los registros podrían usarse para determinar quién estaba usando el sistema y cuándo. Quiero que los usuarios de este sistema tengan confianza en que, incluso si un servidor está comprometido, que los registros no están diseñados de tal manera que un tercero pueda inferir quién usó el sistema y cuándo, para hablar con quién.

Mi primer pensamiento fue que el almacenamiento de información en una forma que se puede verificar más tarde, pero no se almacena en texto simple, es similar a cómo se almacenan de forma segura las contraseñas del sistema mediante una función de derivación de claves (es decir, aplicar un hash a una frase de contraseña y un Sal para un gran número de iteraciones). Por lo tanto, de la misma manera que se puede verificar una contraseña de usuario contra su hash basado en KDF, se puede verificar una IP contra su hash basado en KDF en el archivo de registro para ver si se ha registrado la misma dirección IP anteriormente.

¿Cuáles son las fortalezas y debilidades de este enfoque? ¿Existen métodos superiores para almacenar metadatos / PII de usuarios que no estén en texto sin formato, en un formato que una aplicación web pueda verificar?

Actualizado para aclarar el propósito de la aplicación web y el modelo de amenaza.

web-application hash denial-of-service ip pbkdf2

pregunta taltman 18.07.2014 - 21:07

fuente

3 respuestas

Lea otras preguntas en las etiquetas web-application hash denial-of-service ip pbkdf2

¿Cómo puede LastPass imponer la autenticación de 2 factores? ¿Son suficientes los grupos de seguridad de AWS para autenticar la comunicación entre instancias? (HIPAA)

score 1 · Answer 1

Digamos que necesita ver las IP durante un período de 30 minutos para decidir sobre el abuso. Aquí hay un esquema para mantener las direcciones IP no más de una hora.

Cada 30 minutos, genere una cadena aleatoria de solo memoria, RS.

Para cualquier período de tiempo, mantenga el RS actual y anterior: rs_c, rs_p.

Para cada IP, calcule el hmac actual utilizando la cadena aleatoria actual:

IP_c = HMAC(rs_c, IP)

Almacena la IP en una tabla:

IP_c, last-update

Calcular el recuento de ip en la última hora.

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]]

Mientras pueda proteger la RS, no recuperará las IP más allá de su ventana deslizante.

Limpie la tabla según la última actualización / edad.

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

score 0 · Answer 2

(Esto puede ser una trampa; tengo un vago recuerdo de una pregunta similar, pero no puedo encontrarlo ahora, así que mi memoria o mi búsqueda-fu están defectuosas o se ha eliminado).

La sal solo funciona si puede vincular el valor protegido a un valor público (es decir, la sal para el hashing de una contraseña se almacena con el ID de usuario correspondiente). La única coincidencia obvia con una dirección IP es el nombre de DNS, que es al menos tan sensible y no siempre 1-a-1 de todos modos. Pepper (fijo pero secreto) sigue siendo útil contra un atacante que obtiene datos del archivo de registro pero no la aplicación que lo escribe. Pero hay una limitación inherente: puede reconocer un hash duplicado, pero no puede retroceder fácilmente la dirección IP si quiere algo como reglas de firewall, puede solo hacer verificaciones basadas en hash en las aplicaciones usted mismo escribe.

Para obtener una solución más flexible, puede hacer una clave pública cifrar los valores con un relleno determinístico (que NO son los rellenos estándar, precisamente para evitar el reconocimiento de duplicados) y proporcionar la clave privada solo (y temporalmente) a las aplicaciones de administración que necesitan descifrar, tal vez ejecutarse en una máquina diferente (más segura).

Pero cualquier esquema que detecte duplicados puede ser reforzado por un atacante que obtiene el archivo de registro y el pepper o publickey (o la aplicación que contiene cualquiera de los dos), desde el espacio de dirección IP (para v4 y 99.99). % de la red pública sigue siendo v4) es algo menor a 32 bits.

Lo que trae otro enfoque: separe los datos confidenciales del riesgo de compromiso. En lugar de escribir el archivo de registro en el servidor web, que debe ser de acceso público y por lo general es lo suficientemente complicado como para tener riesgos de vulnerabilidad, envíelo a otra máquina que tenga un servidor de seguridad para ejecutar solo un programa de registro de solo escritura de forma sencilla, tal vez 20 líneas de código que puede ser verificado rigurosamente.

Editar: aclaraciones para comentarios, 24/02/2015.

La sal en sí no necesita ser pública (aunque a veces lo es), pero tiene que estar determinada por datos públicos, y única por artículo con al menos Alta probabilidad si no certeza. El ejemplo canónico es el hashing de contraseñas, donde tanto el salt generalmente aleatorio como el hash salado de la contraseña se almacenan en una base de datos a la que se accede mediante ID de usuario. El punto entero de la sal es ser diferente para diferentes valores. Un valor agregado al hash que es secreto (en su caso para el servidor de aplicaciones) pero el mismo para todos los valores hash es pepper . Eso es útil, como dije, si un atacante puede obtener datos que contienen los hashes salpicados pero no la pimienta en sí.

Contrasté el cifrado de clave pública como "flexible" en la forma en que puedes usar los resultados. Por ejemplo, un programa de filtro podría tomar un IPaddr determinado, como una nueva conexión, y procesarlo (con la pimienta) para ver si coincide con una entrada registrada, pero no puede tomar una entrada registrada o varias y (de forma barata) determinar El IPaddr (s). El cifrado de la clave pública se puede revertir para mostrar el IPaddr mediante solo un programa específico o un sistema (posiblemente remoto) al que le asigne la clave privada, y proteja y restrinja en consecuencia.

score 0 · Answer 3

Un enfoque sencillo sería registrar la dirección IP y la marca de tiempo en un archivo de registro, y eliminar las entradas después de un período de tiempo.

Sencillo pero fenomenalmente insuficiente. En realidad, solo debe mantener los datos de los infractores en el almacenamiento indexado independientemente de sus datos de registro (probablemente también debería mantener los archivos de registro, pero eso es un debate separado ).

Como supongo que no se siente un deber tan fuerte de cuidar a los infractores como lo hace con otras personas que usan su sitio, esto resuelve tanto el problema de rendimiento como el problema de privacidad.