Protocolización de direcciones IP en registros del servidor: permitida o no

Según los aviso de protección de datos en muchas páginas web, las direcciones IP se almacenan en archivos de registro del servidor durante un período más largo, a menudo supuestamente por razones de seguridad y sin ninguna causa. Si la protocolización innecesaria es permitida, depende de si es técnicamente necesaria o si hay medios menos severos.

Introducción

Diferenciación: El artículo solo considera servidores públicamente accesibles de proveedores comunes, es decir,NO de ISPs, autoridades de persecución penal, etc. No se trata aquí de los casos cubiertos por § 172 TKG, ni tampoco de una base legal según Art. 6 DSGVO, como podría ser una autorización, que se considera no dada (de lo contrario la pregunta estaría rápidamente respondida).

Para evitar malentendidos: La comprensión del concepto "motivo" es fundamental! Se explica en el artículo. La almacenación de datos previos se llama así porque ocurre sin motivo, es decir, siempre!

Las direcciones IP son direcciones de red. Son parte de los metadatos, que se transmiten siempre al llamar a una página web. Estos metadatos también se conocen como datos de tráfico o datos de conexión. Parece que el significado de estos dos términos es diferente en el contexto técnico y jurídico. Por lo tanto, utilizaré el término de metadatos.

Las direcciones IP son, según la jurisprudencia más alta de los Tribunales Europeo y Alemán datos personales. Esto también se aplica a las direcciones IP dinámicas, y es así desde el año 2016 (Tribunal Europeo) y 2017 (Tribunal Alemán). La RGPD rige desde finales de mayo de 2018.

Las direcciones IP permiten posiblemente identificar ataques y por lo tanto aumentar la seguridad de los servidores en caso necesario. Además, mediante el conocimiento de una dirección IP puede tener lugar una investigación penal. Todo esto parece plausible a mí, aunque no para cada escenario de ataque. Mis interlocutores, numerosos expertos en seguridad informática y derecho, lo confirman.

Las direcciones IP son útiles para aumentar la seguridad de un servidor y para identificar a los delincuentes. La utilidad no es, sin embargo, un motivo justificativo decisivo.

¿Cuál es la pregunta?:

¿Deben las direcciones IP completas ser registradas por los proveedores de servidores propios sin motivo, o hay medios más suaves?

Pregunta de este artículo.

Este artículo se centra en los propietarios de servidores. Los proveedores de servicios de Internet (ISP) como la Deutsche Telekom o Vodafone no deben ser considerados aquí por razones de complejidad.

---

Actualización: El TJUE había incluso declarado ilegal la almacenación de datos sin causa, si se utilizaba para esclarecer delitos graves. Ver Sentencia del TJUE del 05.04.2022 (Asunto C-140/20).

Las mismas normas jurídicas que prevén la recopilación preventiva de datos de tráfico y ubicación para combatir la gravedad del crimen y prevenir graves amenazas a la seguridad pública, son ilegales.

Mi formulación del fallo del Tribunal de Justicia de la Unión Europea del 05.04.2022, RN. 101.

El TJUE establece además que solo está permitida la "almacenación de reservas de direcciones IP generales y no discriminadas por un período de tiempo limitado a lo absolutamente necesario para prevenir la amenaza a la seguridad pública y combatir la delincuencia grave" (punto 101 de la sentencia). El TJUE confirma, según mi comprensión, lo que ya había expresado anteriormente. Pues los proveedores privados de servidores (de Internet) tienen poco o nada que ver con la seguridad pública y mucho menos con la lucha contra la delincuencia grave.

---

Continuando con el texto sin relación directa con la sentencia del TJUE mencionada anteriormente, que se emitió después de mi texto.

Me refiero a las siguientes tres condiciones que de repente se cumplen:

• NO SE PIERDA (!!!!)
• REGISTRO DE PROTOCOLO (persistencia de almacenamiento, por ejemplo en archivos)
• DIRECCIONES IP COMPLETAS

El propósito es la prevención de peligros. La persecución penal no os importa a ti y a mí ni a vuestro servidor, a menos que seáis policía, fiscalía o lo que sea.

Por favor interioricen estas condiciones antes de seguir leyendo y creer que pueden responder a la pregunta de este artículo!

No se trata de:

• Registación con motivo y/o
• Datos que se mantienen de manera fugaz en la memoria principal y/o
• El uso de otros datos que no sean las direcciones IP completas y/o
• Investigación por parte de las autoridades, la policía y el ministerio fiscal.

¿Lo han asimilado? Luego, por favor, continúen leyendo y háganme saber si usted es el primero en mencionar un ejemplo concreto de la protocolización de direcciones IP sin motivo que reconozca una base legal.

Inmotivado significa que las direcciones IP se registran siempre. Relacionado con la ocasión significaría que la registro de direcciones IP comienza solo cuando ocurre un evento, como una supuesta invasión por hackers o para buscar errores en problemas de red o al intentar acceder con una contraseña. El motivo se considera válido a partir del momento en que se establece o se asume. Es inadmisible suponer retroactivamente un motivo. Porque entonces siempre habría que registrar, para luego descartar el 99% de los datos (que serían registrados anlasslos y por lo tanto, como se afirma, ilegalmente), solo para utilizar el 1% de los datos para el motivo establecido más tarde. Un motivo también puede considerarse válido cuando un automatismo con una probabilidad lo suficientemente alta considere que hay un motivo presente. Sin embargo, esta alta probabilidad no puede estar presente en cada acceso (a menos que todo acceso a un servidor sea de un hacker). En este artículo no se trata de discutir valores de probabilidad. Una registro permanente, por lo tanto, está basado en una probabilidad del 0% de que haya un motivo y es inadmisible, sostengo yo.

Un motivo es un evento supuesto. Una protocolización siempre realizada es obviamente sin motivo.

Declaración.

Un motivo se le llama también Evento en otro lugar. Consulte el IT-Grundschutz-Kompendium del BSI (German federal security agency). Allí, si lo he visto correctamente, no hay una indicación concreta de que las direcciones IP completas deben ser registradas sin evento (es decir, sin motivo). Incluso si esta indicación estuviera en el Compendio del BSI (German federal security agency), faltaba un ejemplo concreto para justificar un interés legítimo como base legal según Art. 6 DSGVO.

Considero al responder a la pregunta de si se deben registrar por motivos protocolarios las direcciones IP, primero el propósito de la dirección IP para la persecución penal, luego el destinado a la protección de sistemas.

Investigación penal

Un servidor no tiene la tarea de realizar persecución penal. Tampoco un proveedor de servicios de un servidor tiene la tarea de realizar persecución penal. Pregunte a un abogado si ve esto diferente.

Por lo tanto, el propósito de la persecución penal como justificación para la almacenamiento sin causa de direcciones IP queda descartado.

La persecución penal no compete al propietario de un servidor ni al propio servidor. Por lo tanto, se descarta esta razón como justificación para la protocolización sin causa de direcciones de red.

Lamentablemente parece ser así, a veces puede ser tan razonable ser un ayudante de sheriff.

Un ejemplo actual de una procesamiento de datos útil, pero aún así prohibido fue la evaluación de un registro de contactos en un restaurante para el seguimiento de la COVID-19. La policía de Mainz buscaba a un testigo para un fallecimiento de un cliente del restaurante. Para ello, la policía tomó datos de la aplicación Luca, que el propietario del restaurante había recopilado con estricto cumplimiento legal. Luego, la policía contactó a los visitantes del restaurante que estuvieron en ese momento allí. Eso fue seguro útil. Pero estaba prohibido. Porque los datos se habían recopilado solo para el propósito de protección de la salud. La fiscalía investigó luego contra la policía y se disculpó con los testigos ilegalmente contactados.

Un ejemplo más: Los llamados teléfonos cibernéticos fueron o eran utilizados por delincuentes para comunicarse de manera secreta. La policía logró descifrar la comunicación a través de estos teléfonos. Este tipo de investigación de pruebas fue puesta en cuestión (creo que porque no había orden judicial). Sin embargo, se decidió (solo?) que debido al hecho de que se tratara de un hallazgo casual, el hallazgo de las noticias en los teléfonos descifrados sería considerado como prueba. De lo contrario, podría haber sido que este útil hallazgo fuera ilegal y por lo tanto no habría podido servir como prueba. El Tribunal Superior de Berlín había clasificado el hallazgo como un hallazgo casual en el sentido del § 100e Abs. 6 Nº 1 StPO.

Prevención de peligros

La seguridad de la tratamiento está en Art. 32 DSGVO exigida. Según esto, los sistemas informáticos deben funcionar de tal manera que el riesgo de incidentes de seguridad se reduzca en una medida adecuada. La prevención de peligros no es solo una exigencia legal, sino que debería ser un interés propio de los responsables.

Ejemplos de incidentes de seguridad

Una lista puramente ilustrativa con ejemplos de lo que a mí me viene en mente como incidente de seguridad y no solo se le llama ataque informático de manera generalizada:

• Denial of Service Attacke (DoS)
• Distributed Denial of Service Attacke (DDoS)
• Malware, Ransomware, Viren
• Robos de datos de acceso
• Reconfiguración de un sistema en un Computador-Zombie

Algunos de los ataques mencionados se producen a través de mecanismos como el robo de sesión, el phishing, las spam-mails o la explotación de exploits/fallas de seguridad (por ejemplo: Log4J).

La enumeración no es completa con seguridad. Si un escenario importante falta, le ruego que me avise (por ejemplo, a través del campo de comentarios debajo).

IP adresses

Cada acceso a Internet se basa en una dirección de red que también se conoce como dirección IP. Cada usuario tiene una dirección IP (que se asigna a través de un dispositivo, como por ejemplo un router). A menudo las personas particulares reciben una dirección IP dinámica de su proveedor. Esta cambia en intervalos irregulares, a veces también en intervalos regulares. En los accesos cableados parece que el cambio de dirección IP es menos frecuente que por ejemplo en accesos a través de líneas telefónicas. En caso de un apagón eléctrico probablemente se producirá también un (inintencionado) cambio de una dirección IP, como pude comprobar yo mismo. A través de la reinicialización de la conexión Fritz!Box, siempre que esta se utilice, se puede obtener a menudo también una nueva dirección IP.

Algunos proveedores ofrecen además direcciones IP estáticas. Estas se utilizan normalmente más por clientes comerciales que por particulares. Las direcciones IP estáticas no cambian con el tiempo.

Debido al espacio de direcciones IP4 limitado, en ocasiones se asigna la misma dirección IP a varios usuarios diferentes, es decir, personas, mediante técnicas que utilizan puertos distintos. Un término para describir esto es NAT de Grado de Transporte (CGN), lo cual significa aproximadamente "encapsulación de red por parte del proveedor de servicios de acceso a Internet".

El TJUE decidió el 19.10.2016 (C-582/14), que las direcciones IP deben considerarse como datos personales si es legalmente posible determinar al titular del contrato en el país de la UE. En Alemania es posible, por ejemplo, para la persecución penal. Basta con la posibilidad objetiva de obtener esta información sobre el contrato, incluso mediante la intervención de varias instancias (proveedores de telecomunicaciones, servicios secretos, policía…). El TJUE también se aplica a las direcciones IP dinámicas. El BGH confirmó este fallo el 16.05.2017 (VI ZR 135/13).

A través de algunos ejemplos concretos, quiero comprobar si puede justificarse el almacenamiento sin causa de direcciones IP.

Denial of Service Attacken

Al realizar este tipo de ataque, un servidor es bombardeado con solicitudes maliciosas en masa hasta que se derrumbe y ya no pueda realizar su trabajo normal.

Es es fácil determinar si desde la misma dirección IP se han realizado numerosos accesos dentro de una unidad de tiempo. Para ello, cada dirección IP se mantiene en el caché del servidor, por lo que no se registra ni se almacena técnicamente. Si se produce un acceso secuencial desde la misma dirección IP, se incrementa un contador en uno. Por ejemplo, si el contador para una dirección IP alcanza un valor de 200 dentro de un minuto, puede suponerse que se ha producido un acceso malicioso.

Un motivo puede ser una justificación para la protocolización de una dirección IP completa. No parece permitido el registro de actas sin motivo.

Mi situación actual de conocimiento.

Si la probabilidad de un ataque maligno es lo suficientemente grande, entonces un motivo para registrar las direcciones IP está dado. Solo a partir de este momento debe registrarse la dirección IP, si se registra en absoluto. De esta manera, esta una sola dirección IP puede ser bloqueada para futuros accesos.

Distributed Denial of Service Attacken

Al realizar este tipo de ataque, también abreviado como DDoS, se realizan solicitudes masivas desde numerosos ordenadores hacia un servidor víctima. En el escenario anterior de ataque, estas solicitudes masivas fueron realizadas solo desde un ordenador o, en su caso máximo, desde unos pocos ordenadores de ataque.

Los ataques de vertido se caracterizan especialmente por el hecho de que los ordenadores atacantes tienen diferentes direcciones IP. Si el servidor atacado solo bloquea una sola dirección IP, no estará listo a tiempo con el bloqueo. Porque hay muchos sistemas de ataque y no uno solo que debe ser apagado.

Una forma de reconocer atacantes distribuidos es interpretar más ampliamente las direcciones del atacante. Para ello, por ejemplo, se elimina el último byte de una dirección IPv4 (=dirección IP con 4 bytes). Ejemplo:

• Denial of Service
  • Dirección IP del atacante: 10.20.30.40.
  • Desactivar el ataque: Bloquear la IP 10.20.30.40
• Distributed Denial of Service
  • Angreifer-IPs: 10.20.30.40, 10.20.30.45, 10.20.30.53, 10.20.30.88
  • Bloquear el ataque: Bloquear áreas de direcciones IP 10.20.30.x o incluso accesos desde una región geográfica, como un país

Para determinar si los atacantes tienen diferentes direcciones de red, se pueden analizar más Metadatos. Una dirección IP tiene especialmente las siguientes características que, por ejemplo, se pueden establecer automáticamente a través de bases de datos.

• Tierra. Ejemplo: Alemania.
• Proveedor. Ejemplo: Vodafone.
• Dirección del host. Para algunas direcciones IP información adicional directamente disponible. Ejemplos: xdsl-87-79-57-01.nc.de, ip-178-11-19-33.hsi05.unitymediagroup.de, p549e3719.dip0.t-ipconnect.de, x4dfc0e22.dyn.telefonica.de, 91-145-240-240.subs.proxad.net
• Asociación de Servicios Numéricos: Número de Sistema Autónomo. Un sistema autónomo es una especie de oficina de correos. Desde la oficina central se envía un paquete de datos a la oficina local, que lo distribuye en el lugar. Un proveedor tiene varios oficinas de correos, por lo tanto ASNs.
• Subredes. Varias direcciones IP consecutivas. Ejemplo: 10.20.30.0 hasta 10.20.30.255, es decir, 10.20.30.x o 10.20.30.0/24.
• Reputación. Suele llevarse a cabo en forma de un valor (Puntuación ) o como lista negativa (Lista Negra ).

Además de la dirección IP, existen otros metadatos al menos cuando se accede a sitios web. Estos son entre otras cosas:

• Usuario-Agente: Tipo de navegador, Versión del navegador, Tipo de sistema operativo, Versión del sistema operativo. Ejemplo: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
• El idioma del usuario configurado en el navegador. Ejemplo: de,en-US;q=0.7,en;q=0.3
• Configuración del caché. Ejemplo: sin caché (Caché desactivado)
• Referente: Página desde la que se realizó el llamado (por ejemplo, al hacer clic en un enlace. Ejemplo: https://dr-dsgvo.de/
• URL llamada: Página junto con los parámetros URL que se llamó. Ejemplo: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
• Datos de contenido: Suele provenir de parámetros URL (GET) o la solicitud (POST). Ejemplo: Username=SELECT * from users
• Punto de acceso: Siempre está presente, incluso en todas las otras solicitudes de red. Finalmente, el destinatario de un mensaje sabe cuándo lo recibió.
• Estado de equipaje: ¿Recibe el remitente respuestas a sus consultas o utiliza una dirección de remitente inalcanzable (ya que es falsa)?

Estas datos pueden, al menos en combinación, ser considerados como datos personales y por lo tanto como datos de carácter personal (vgl. Artículo 4 Número 1 DSGVO). Si se guardaran sin cifrar ni cortarlos, no habría ganado mucho. Se sugiere cifrar estos datos, si parecen útiles para la prevención de peligros, cifrarlos. Este cifrado puede lograrse mediante un procedimiento matemático.

Cifrado de datos personales

El cifrado de datos se realiza de tal manera que un valor de datos se combina con un valor de clave elegido libremente y adecuado. El resultado es un valor objetivo. Con un procedimiento de hash criptográfico también podrían generarse valores que no necesitan ser únicos. Varias entradas diferentes podrían estar representadas por el mismo valor objetivo. La probabilidad de esto puede mantenerse muy baja o en realidad descartada (llamado mapa inyectivo o procedimiento perfecto sin colisiones) mediante la elección de métodos y parámetros adecuados.

Un valor objetivo es una fecha anónima mientras el valor de la clave está conocido. Aquí hay un ejemplo:

1. El usuario X accede a una página web con la dirección IP A1. La dirección A1 se convierte en el valor objetivo H1 utilizando la clave S1.
2. No se puede retrotraer H1 a A1 porque el procedimiento es asimétrico.
3. Ahora que el usuario X vuelve a acceder con su dirección A1 a la página web, se crea nuevamente el valor objetivo H1 a través de S1. H1 ya estaba almacenado en la base de datos. Se encuentra este valor H1 para un momento de acceso anterior. Por lo tanto, es conocido que el usuario X ahora y en un momento anterior accedió a la página web. Por lo tanto, se puede retrotraer H1 a A1.

Con llave válida temporalmente se puede realizar una pseudonimización temporal seguida de una anonymización. Para ello son adecuadas las funciones de un solo sentido. Una función de un solo sentido permite cifrar, pero no descifrar. Si existe un valor claro que previamente fue cifrado, se puede comparar el valor claro después de la cifratura con el valor cifrado anterior. De esta manera se puede determinar si el valor claro ya existía antes. El valor cifrado, sin embargo, no puede ser devuelto al valor claro sin el valor claro actual.

Para valores de entrada muy cortos se deben tomar medidas adecuadas para asegurar que una descomposición eficiente no sea posible. En particular, no deben usarse tablas de colores. Lo mejor es diseñar el procedimiento de tal manera que tales tablas no sean aplicables en absoluto.

Si el llave S1 solo dura 24 horas y luego se olvida, todos los valores de destino generados con esta llave no podrán ser desencriptados más. Por lo tanto, después de 24 horas habría datos anonimizados y no ya pseudonimizados. Esto también significaría un protección contra tablas de colores, al menos después del vencimiento de la llave.

Prevención de peligros mediante metadatos o pseudonimización

La cuestión era si se pueden repeler ataques DDoS sólo si se registran protocolariamente las direcciones IP. Yo sostengo que para repeler ataques DDoS no es necesario conocer las direcciones IP.

En el caso no óptimo desde el punto de vista del derecho a la protección de datos, las direcciones IP se registrarían en forma de fecha pseudónima con un procedimiento de cifrado que podría no ser una función de solo ida. Un ataque DDoS se caracteriza por que los atacantes llevan a cabo rápidamente ataques consecutivos. Una clave dependiente del tiempo proporciona así una posibilidad de pseudonimización, que podría utilizarse sin motivo alguno. Este procedimiento no sería peor en tiempo real que el uso de direcciones IP completas. Sólo cuando se analiza retrospectivamente es peor. Una consideración retrospectiva es a menudo útil para analizar las olas de ataques.

Los peligros pueden ser más efectivamente repelidos si se almacenan direcciones IP o metadatos a direcciones IP reducidas. Los cuales podrían ser útiles, los he descrito arriba.

En ataques DoS o DDoS, los atacantes pueden falsificar sin problemas su dirección de origen (dirección IP). Pues no necesitan recibir una respuesta a su mala petición. El atacante podría entonces utilizar direcciones IP cambiantes. Si se guardaran las direcciones IP completas, en este caso no habría ganado nada, al menos no en tiempo real.

Pocos accesos: Los atacantes que solo acceden una vez o pocas veces a un sistema de víctima pueden no ser detectados en absoluto o detectados de manera relacionada con el incidente. Un inicio de sesión (Ingreso) con datos de usuario obtenidos puede verse equipado con un protocolo IP relacionado con el incidente. El aprovechamiento de una vulnerabilidad, como Log4J, a través de solo un acceso no puede ser evitado o detectado ad hoc mediante un protocolo IP. Así que aunque sea tonto, pero la almacenación de la dirección IP sin motivo alguno para poder identificar al presunto culpable no es admisible. Las cámaras de velocidad en autos, que filman permanentemente y sin ningún motivo, son igualmente inadmisibles. ¡Qué lástima, pero así es, aunque por eso el o los culpables no puedan ser identificados. Si un atacante introduce código malicioso en un campo de formulario para obtener datos, esto puede ser detectado al evaluar los datos ingresados. Por ejemplo, se pueden detectar inyecciones SQL. Además, el código malicioso puede hacerse ineficaz si hay una programación adecuada en el servidor. Eso es más fácil de decir que de hacer, como se vio en la biblioteca auxiliar Log4J muy extendida, que permitía ataques efectivos sin mucho esfuerzo. Sin embargo, tampoco ayuda una dirección IP completa y protocolizada a reconocer el ataque mejor que lo haría de otra manera (creo yo).

Los atacantes utilizan direcciones IP temporalmente estables, ayudando los metadatos de la dirección IP en tiempo real a reconocer ataques. Además, mediante los metadatos es mucho más fácil una evaluación automática o manual retroactiva que si solo se guardaba la dirección IP completa y se necesitaban los metadatos para analizar un ataque. La primera vez es siempre la primera vez. Esto significa: En una primera agresión, que se analiza posteriormente, el objetivo debe trabajar arduamente en determinar los metadatos de las direcciones IP completas registradas. A menos que los metadatos se hayan registrado directamente, lo mejor sería sin la dirección IP completa. Una protección completa de direcciones IP sin metadatos tiene evidentemente también inconvenientes técnicos.

Una ataque que siempre llama a la misma página de destino (URL) puede ser fácilmente reconocido. Si una página de destino es llamada con mucha frecuencia más de lo que sería normal, podría haber un motivo para protocolizar la IP. Una protocolización sin motivo sería aquí para la prevención de peligros no necesaria.

Ataques DDoS, que se pueden asignar a un país específico, no suelen tener lugar en Alemania. En Alemania tenemos buenas posibilidades de investigación legal. Por otro lado, computadoras zombis podrían utilizarse para un ataque desde el interior. Las páginas web alemanas, por lo menos, pueden reconocer y bloquear accesos desde el extranjero, que se consideran ataques. Esto podría hacerse sin conocer las direcciones IP completas (ver arriba: ASN, país, proveedor). Para ataques zombis, en cambio, una análisis de los llamados sería útil (direcciones URL objetivo, parámetros, frecuencia, agente del usuario…).

Determinados ataques no podrían ser bloqueados de manera efectiva ni mediante la completa protocolización de direcciones IP, ni con otros medios. Por lo tanto, sobre este tipo de ataque no se debe hablar más cuando se trata de la cuestión de la protocolización inmotivada de direcciones de red completas. Ejemplos de tales ataques son:

• Código malicioso: A un usuario registrado se le envía un enlace dañino. Ya sea que se utilice un reloj zombie para el envío de correos electrónicos, una proxy o una página web infiltrada, o si el hacker es especialmente tonto y utiliza su propio acceso para enviar el correo electrónico. De cualquier manera: En el encabezado del correo electrónico a menudo está registrada la dirección IP del remitente y no necesita ser registrada por separado. Independientemente de eso, también podría considerarse el recibimiento de un correo electrónico como una excusa. Algunas páginas web hackeadas en las que se coloca un código malicioso, la protocolización de IP al momento de hacer clic en el enlace no aporta nada.
• IP-Spoofing: Los atacantes utilizan direcciones IP de origen generadas al azar y metadatos. A los atacantes no les llega la respuesta, solo buscan dañar al objetivo con solicitudes maliciosas. Antes (también hoy en día?) era posible que a los atacantes se les recibieran respuestas para otras direcciones (Backscatter-Attacke).
• Datos de acceso obtenidos: El conocimiento de los datos de acceso hace que un hacker parezca un usuario legítimo. A lo sumo, a través de actividades anormales o investigaciones más profundas o incluso indicaciones del titular real de los datos de acceso pueden descubrirse estos accesos. Si se produce una conexión desde el extranjero o desde otro dispositivo que no es normal, puede realizarse una verificación de seguridad (CAPTCHA, pregunta por la fecha de nacimiento, etc.) relacionada con el motivo. Pero incluso aquí, la conocimiento de la dirección IP completa no ayuda más allá de los metadatos, y menos aún permite una análisis más amplio.

En una visión general bastante vaga, he reunido algunas clases de ataques. Las clases pueden superponerse (un DoS es posible tanto desde dentro como desde fuera del país, etc.). La tabla solo pretende dar una idea general y no es completa.

Tipo de ataque	Reconocimiento
Acceso excesivamente frecuente	Comparar la dirección IP concreta en memoria.
Denial of Service	Comparar la dirección IP concreta en memoria.
Distributed Denial of Service	Evaluar direcciones IP abreviadas o metadatos.
Inserción de código malicioso (inyección SQL, etc.)	Verificar datos de contenido contra palabras clave y símbolos de código.
Ingreso por hackers (acceso obtenido)	Buscar dirección IP concreta en la base de datos cuando las direcciones IP de los usuarios registrados se almacenan, o protocolización directa (motivo = inicio de sesión)
Ataque desde el extranjero	Evaluar metadatos, especialmente país, ASN, subred.
Ataque desde el interior	Evaluar metadatos, especialmente ASN, subred.
IP-Spoofing	Si es posible, verificar la dirección de envío contra el addressrau considerado válido, lo que puede ser posible en redes locales. En caso de que así sea, Unicast RPF (no es mi especialidad)

Después de que se haya reconocido o considerado probable una agresión, puede (debe) realizarse un protocolo relacionado con las direcciones IP siempre y cuando sea necesario para la prevención de peligros.

Si se bloquea una dirección IP porque se la considera como dirección de atacante, existen las siguientes peligros:

1. La dirección es en realidad un atacante no, sino que fue injustamente acusada (esto parece sobre todo posible cuando se trata de bloqueos automáticos).
2. La dirección era falsa y pertenecía a un otro (benigno) conexión o a ninguna (entonces el efecto de una suspensión sería igual a cero).
3. La dirección pertenecía a un atacante, pero ahora ha sido asignada a otro (benigno) acceso. Esto puede ocurrir siempre que se utilicen direcciones IP dinámicas, pero también cuando se accede a través de la red Tor.
4. La dirección es asignada a varios enlaces mediante Carrier Grade NAT. Todos los enlaces, excepto uno, son potencialmente benignos y se bloquean involuntariamente.
5. La dirección representa un proxy. Si se bloquea la dirección de la proxy, ninguna conexión puede establecer una conexión a través de la proxy.

La restricción de una dirección IP no resuelve necesariamente todos los problemas, sino que puede agravarlos en algunos casos.

Otros motivos que no son ataques pueden ser:

• Pruebas, como búsqueda de errores, optimizaciones o nuevas desarrollos
• Intentos de registro con nombre de usuario y/o contraseña
• Inserción de datos extraños en un formulario (aquí no se refiere necesariamente a código malicioso)

No voy a entrar en detalles sobre estos eventos, ya que aquí se trata de la cuestión de la protocolización sin motivo!

Conclusión

El protocolizar de direcciones IP sin motivo para la prevención de peligros parece técnicamente innecesario. No veo indicio alguno en contrario. En lugar de direcciones IP completas, pueden ser registradas las siguientes datos:

• Direcciones de IP (también subredes)
• Bloques de direcciones IP
• Nombre ficticio, como objetivos temporales limitados que se vuelven anónimos después de un corto período
• Información metadatos sobre las direcciones IP:
  • Tierra
  • Provedor
  • Asociación de Servicios Numéricos
  • Nombres de host
  • Reputation
• Información metadatos de la conexión
  • Objetivo llamado (URL, etc.)
  • Metadatos del remitente como User-Agent o configuración de caché
  • Punto de acceso
  • Accesibilidad de la contraparte

Si por el contrario existe un motivo, puede justificarse la completa protocolización de la dirección IP. Ejemplos de tales motivos podrían ser:

• Llamada excesivamente frecuente por una fuente
• Comportamiento anormal del usuario
• Llamadas anormales (como parámetros de URL inusuales o direcciones inexistentes)
• Metadatos sospechosos (Ejemplo: Accesos desde el país X o del subred Y)
• Multiples de respuesta incorrectas
• Búsqueda de errores (Ejemplo: registrar propios accesos para encontrar errores en la red)

Puede haber diferencias en la evaluación de los escenarios de amenaza en redes pequeñas y grandes respectivamente, así como en páginas web pequeñas y grandes. No puedo reconocer actualmente que esto dé lugar a una diferencia relevante para la cuestión planteada en este artículo, por lo que me alegra cualquier retroalimentación.

Por cierto, enviar una opinión en un portal de opiniones no es motivo para registrar un acceso en el archivo de registro del servidor web con la dirección IP. Por el contrario, se guardará la opinión, posiblemente junto con la dirección IP del remitente, en una base de datos.

Al principio había escrito que se trataba solo de servidores propios, no del proveedor de acceso a Internet (ISPs). Si bien dudo que los ISPs deban registrar la dirección IP completa sin motivo y sin previo aviso para defenderse de algunas peligrosidades, hasta ahora me atrevo a cuestionarlo, aunque es posible que los ISPs ya sean los que tienen razón. Lo mismo puede decirse sobre Redes de entrega de contenido (CDNs). Si bien las CDNs registran direcciones IP completas sin motivo, esto debe ser comunicado por el proveedor del CDN. Me ha sido conocido a Akamai que esta práctica se lleva a cabo. Por lo tanto, se le ha prohibido el uso del servicio Cookiebot, que utiliza servidores de Akamai.

La protocolización de direcciones IP completas por parte de los propietarios de servidores para la prevención de peligros no es técnicamente necesaria.

Mi conocimiento hasta la prueba en contrario.

Si no están de acuerdo, veo dos posibilidades:

1. Pueden nombrar un ejemplo concreto y comprensible. En este caso, reviso el ejemplo con gusto y cambio de opinión si su ejemplo lo justifica.
2. No pueden nombrar un ejemplo concreto. En este caso deberían cambiar de opinión, queráis o no, porque la opinión sería infundada y sin fundamento.

Por favor, escribanme a quién conocen un ejemplo concreto que podría ser relevante para el propietario de un servidor. Recuerdo nuevamente que se trata de la anotación sin causa, no de la anotación por un motivo reconocido! No se trata tampoco de una consideración sobre la utilidad, sino de una consideración sobre la necesidad. Como palabra clave, aquí se menciona el medio más suave. Y hay numerosos otros medios que son igualmente adecuados como direcciones IP, o incluso mejores para reconocer peligros o defenderse.

No es la utilidad lo que importa, sino la necesidad y la disponibilidad de medios más suaves.

Este principio es probablemente aplicable en muchos ámbitos del protección de datos.

Un breve resumen de su utilidad:

Accidente	Útil?	Necesario/Permitido?
Omitir la declaración de impuestos	Sí, para todos los que no tengan ganas de ello	No, dice la ley
Robo de un banco	Sí, para el que necesita dinero	No, dice la ley
Cámara de dash con video (con almacenamiento permanente)	Sí, más tarde poder demostrarle a un culpable de un accidente que él es el culpable	No, al menos no de manera permanente (que yo sepa)
Registrar direcciones IP sin motivo	Sí, seguramente para muchos	No, sostengo en este artículo

Tampoco se trata de persecución penal, ya que ésta no es competencia de un propietario de servidor y mucho menos de un servidor (a excepción de que el servidor pertenezca a una entidad autorizada para la persecución penal).

Mis conversaciones con expertos y mis preguntas a varias grupos de expertos en una red social me dieron por lo menos que nadie pudo mencionar un solo ejemplo que refutara mi postura. Incluso el BSI (German federal security agency) no pudo mencionar un ejemplo concreto. En su lugar, recibí una respuesta con información poco interesante. Se mencionó allí que las direcciones IP son datos personales y que se deben tener en cuenta las bases legales de la DS-GVO. Todo esto ya lo sabía. Además, se hizo referencia al compendio del BSI (German federal security agency), pero tampoco allí encontré un solo ejemplo concreto (espero no haber pasado por alto nada).

Si guardan siempre la dirección IP completa de los usuarios de su red pública en sus registros del servidor: Detengan esto inmediatamente o proporcionen un ejemplo concreto para la prevención de peligros o algún otro motivo legítimo por el que les permita hacerlo

Esta solicitud se dirige a los operadores de servidores comunes, no a las IPS, autoridades de persecución penal, etc.

Recientemente había observado que en el servidor FTP de un cliente se estaba escribiendo un protocolo de servidor con direcciones IP completas. De ello surge la pregunta, qué beneficio puede tener esta información para el cliente. El beneficio prácticamente debe ser cero. El cliente no puede, por ejemplo, mitigar ataques DoS en su servidor virtual si conoce las direcciones IP del atacante. Lo mismo es frecuentemente cierto para servidores administrados. Esto solo de pasada, aunque nada cambia a la pregunta real.

Por cierto, el NDR como responsable de la página web de la Tagesschau registra según las indicaciones de protección de datos la dirección IP completa de todos los visitantes. No se explica por qué sucede esto. Seguro que tampoco lo sabrá ni lo dirá el delegado de protección de datos del NDR.

En un artículo propio me dedico a la duración máxima permitida de los archivos de registro de sitios web.