La registrazione di indirizzi IP nei log dei server: consentito o no?

Secondo le informazioni sulla protezione dei dati fornite da molte pagine web, gli indirizzi IP vengono registrati in file di log server per interi periodi di tempo e spesso senza alcun motivo apparente, affermando che ciò avviene per motivi di sicurezza. Se la registrazione senza un motivo è ammissibile dipende dal fatto se sia tecnologicamente necessario o se esistano metodi meno invasivi.

Introduzione

Differenziazione: Il contributo considera solo server accessibili al pubblico di gestori comuni, quindi NON quelli degli ISP, delle forze dell'ordine ecc. Non si tratta quindi dei casi disciplinati da § 172 TKG. Si assume che non sia presente una base giuridica in conformità con Art. 6 DSGVO, ad esempio un consenso, altrimenti la domanda sarebbe stata risolta velocemente.

Perché ciò che è sempre successo: la comprensione del concetto di "motivo" è fondamentale! Viene spiegato nel contributo. La conservazione dei dati in precedenza si chiama così perché avviene senza motivo, cioè sempre!

Le indirizzi IP sono indirizzi di rete. Sono parte dei metadati, che vengono trasferiti ogni volta che si richiama una pagina web. Questi metadati vengono occasionalmente chiamati anche dati di traffico o dati di connessione. La significato di questi due termini sembra essere diverso nel contesto tecnico e giuridico. Pertanto, utilizzo il termine dei metadati.

Le indirizzi IP sono, secondo la più alta giurisprudenza di Corte Europea e Corte Federale Tedesca dati personali. Ciò vale anche per le indirizzi IP dinamici, e ciò già dal 2016 (Corte Europea) e 2017 (Corte Federale Tedesca). La GDPR è in vigore dal fine maggio 2018.

Le indirizzi IP possono forse permettere di riconoscere gli attacchi e quindi aumentare la sicurezza dei server, se del caso. Inoltre, grazie alla conoscenza di un indirizzo IP, potrebbe avvenire una indagine penale. Tutto ciò mi sembra plausibile, anche se non per ogni scenario di attacco. I miei interlocutori, numerosi esperti in sicurezza informatica e diritto, confermano questo.

Le indirizzi IP sono quindi utili per aumentare la sicurezza di un server e per identificare i colpevoli. La utilità non è però un motivo giustificativo decisivo.

La domanda è:

Devono essere registrate le intere indirizzi IP senza motivo da parte dei fornitori di server propri, o ci sono metodi più miti?

Domanda di questo articolo.

Questo articolo si concentra quindi sui gestori di server. I fornitori di servizi internet (ISP) come la Deutsche Telekom o Vodafone non dovrebbero essere considerati per motivi di complessità.

---

Aggiornamento: Il Tribunale di giustizia dell'Unione europea aveva addirittura dichiarato illegale la conservazione dei dati senza motivo, se utilizzata per chiarire gravi reati. Vedi Sentenza del Tribunale di giustizia dell'Unione europea del 05.04.2022 (C-140/20).

Le stesse norme giuridiche che prevedono preventivamente la raccolta di dati di traffico e posizione per contrastare gravi forme di criminalità e prevenire gravi minacce alla sicurezza pubblica, sono illegali.

La mia formulazione della sentenza del Tribunale di giustizia dell'Unione europea del 05.04.2022, RN. 101.

Il giudice dell'Unione europea stabilisce inoltre che è consentito solo per prevenire la minaccia alla sicurezza pubblica e per combattere gravi crimini, "per un periodo di tempo assolutamente necessario, una raccolta indiscriminata delle indirizzi IP, attribuiti alla fonte di una connessione" (par. 101 della sentenza). Il giudice dell'Unione europea conferma quindi ciò che avevo già detto precedentemente. Infatti, i privati fornitori di server (web) hanno poco o nulla a che fare con la sicurezza pubblica e ancora meno con il combattimento dei gravi crimini.

---

Continuando con il testo senza alcun riferimento diretto al citato giudizio della Corte di Giustizia dell'Unione Europea, che è stato emesso dopo la stesura del mio testo.

Il mio contributo verte su tre condizioni che improvvisamente si verificano:

• LA SCELTA OBBLIGATORIA (!!!)
• REGISTRAZIONE (persistenza del file, ad esempio in file)
• INDIRIZZI IP COMPLETI

L'obiettivo è la prevenzione dei pericoli. La persecuzione penale non vi riguarda e neanche il vostro server, a meno che siate polizia, procuratore distrettuale ecc.

Per favore interiorizzate queste condizioni prima di proseguire e pensare di poter rispondere alla domanda di questo articolo!

Non si tratta di:

• Registrazione connessa all'occasione e/o
• Dati e/o che sono stati trattenuti solo temporaneamente nella memoria principale
• Utilizzo di altri dati al posto delle intere indirizzi IP e/o
• Indagine e persecuzione da parte delle autorità, della polizia, del pubblico ministero.

Avete assimilato questo? Allora proseguite la lettura e fatemi sapere se volete essere il primo a citare un esempio concreto di registrazione delle IP senza motivo che riconosce una base legale.

Annoiato significa che le indirizzi IP vengono sempre registrati. Annoiato in relazione significherebbe che la registrazione delle indagini IP avviene solo all'ingresso di un evento, come un presunto attacco hacker o per la ricerca di errori nei problemi di rete o per un tentativo di accesso con una password, si avvia. L'occasione è data solo dal momento in cui viene stabilita o ritenuta. Un'ipotesi retroattiva dell'occasione non è ammissibile. Infatti, allora dovrebbe essere sempre registrato per poi eliminare 99% dei dati (che sarebbero stati registrati senza un motivo e quindi, come affermato, illegalmente), solo per utilizzare il 1% dei dati per l'occasione successivamente stabilita. Un'occasione può anche essere considerata presente se un automatismo con una probabilità sufficientemente alta ritiene che l'occasione sia presente. Questa probabilità molto alta non può però essere presente per ogni accesso (ad eccezione di ogni accesso a un server da parte di un hacker). In questo contributo non si tratta di discutere valori di probabilità. Una registrazione continua, comunque, è basata su una probabilità del 0% che l'occasione sia presente e non è ammissibile, sostengo io.

Un motivo è un evento presunto. Una registrazione continua è ovviamente senza motivo.

Conferma.

Un motivo viene chiamato altrove anche evento. Si veda in questo senso il IT-Grundschutz-Kompendium del BSI (German federal security agency). Lì si trova, se l'ho visto giusto, nessun chiaro riferimento al fatto che le IP complete debbano essere registrate senza evento (cioè senza motivo). Anche se questo riferimento fosse presente nel Kompendium del BSI (German federal security agency), mancherebbe l'esempio concreto per giustificare un interesse legittimo come base di diritto ai sensi dell'art. 6 DSGVO.

Considero per rispondere alla domanda se le indirizzi IP debbano essere registrati senza motivo, in primo luogo lo scopo dell'indirizzo IP nella repressione della criminalità, poi quello per la sicurezza dei sistemi.

Indagine penale

Un server non ha l'obiettivo di condurre indagini penali. Anche il gestore di un server non ha l'obiettivo di condurre indagini penali. Chiedete a un giurista, se vedete le cose diversamente.

Quindi, il fine della persecuzione penale non giustifica più la conservazione di indirizzi IP senza motivo.

La persecuzione penale non spetta né al gestore di un server, né allo stesso server. Pertanto, questo motivo viene escluso come giustificazione per la registrazione senza motivi delle indirizzi di rete.

Purtroppo sembra essere così, forse sarebbe stato sensato essere un aiuto sceriffo a volte.

Un esempio attuale di una elaborazione dei dati utile, ma tuttavia vietata era l'analisi di un questionario di contatto in un ristorante per la tracciatura del COVID-19. La polizia di Magonza stava cercando un testimone per un decesso di un cliente del ristorante. Per questo scopo, la polizia ha prelevato dati dalla Luca App, che il gestore del ristorante aveva registrato in modo obbligatorio. La polizia ha quindi contattato i clienti del ristorante che erano presenti al momento della tragedia. Ciò era sicuramente utile. Ma era vietato. Infatti, i dati erano stati raccolti solo per scopo di protezione sanitaria. L'Autorità giudiziaria ha quindi iniziato un'indagine contro la polizia e si è scusata con i testimoni contattati illegalmente.

Un altro esempio: così chiamati telefoni criptati vengono o sono stati utilizzati dai criminali per comunicare in modo segreto. La polizia è riuscita a decrittare la comunicazione su questi telefoni. Questo tipo di raccolta di prove è stato messo in discussione (credo perché non c'era un mandato di cattura). Tuttavia, a causa del fatto che si trattava di un ritrovamento casuale, il ritrovamento dei messaggi nei telefoni decrittati è stato considerato come prova. Altrimenti sarebbe potuto essere che questo utile ritrovamento fosse illegale e quindi non avrebbe dovuto essere utilizzato come prova. Il KG di Berlino aveva classificato il ritrovamento come un ritrovamento casuale ai sensi dell'art. 100e, comma 6, n. 1 del codice di procedura penale.

Prevenzione dei pericoli

La sicurezza della trattativa è richiesta in Art. 32 DSGVO. Secondo ciò, i sistemi IT devono essere gestiti in modo che il rischio di eventi di sicurezza sia ridotto in misura adeguata. La prevenzione dei pericoli non è solo una richiesta legale, ma dovrebbe essere un interesse primario degli responsabili.

Esempi di incidenti di sicurezza

Una lista esemplare con esempi di ciò che mi viene in mente come incidente di sicurezza e non solo viene denominato genericamente con il termine "attacco hacker":

• Denial of Service Attacke (DoS)
• Distributed Denial of Service Attacke (DDoS)
• Malware, Ransomware, Viren
• Dati di accesso rubati
• Riqualificazione di un sistema in Zombie-Computer

Alcuni degli attacchi menzionati avvengono attraverso meccanismi come il hijacking di sessione, phishing, spam-mail o sfruttamento di exploit/vulnerabilità (ad esempio: Log4J).

La lista non è completa. Se manca un scenario importante, ti prego di farmelo sapere (tramite il campo dei commenti sotto).

IP adresses

Ogni accesso a Internet si basa su un indirizzo di rete, noto anche come indirizzo IP. Ogni utente ha un indirizzo IP (che viene assegnato tramite un dispositivo, ad esempio un router). Spesso le persone private ricevono un indirizzo IP dinamico dal loro fornitore. Questo cambia in intervalli irregolari, a volte anche regolari. Nelle connessioni a cavo sembra che il cambio di indirizzo IP sia meno frequente rispetto alle connessioni tramite linee telefoniche. In caso di black out si verificherà probabilmente un (imprevisto) cambio di indirizzo IP, come ho potuto constatare personalmente. Con la riavviatura della connessione Fritz!Box, se utilizzata, si può spesso ottenere anche un nuovo indirizzo IP.

Alcuni fornitori offrono inoltre indirizzi IP statici. Questi vengono solitamente utilizzati più dai clienti commerciali che dalle persone private. Gli indirizzi IP statici non cambiano nel corso del tempo.

A causa dello spazio di indirizzo limitato delle IPv4, può accadere che la stessa IP venga assegnata a più connessioni diverse, quindi persone, mediante tecnica di NAT di livello di carrier (CGN), ovvero una sorta di "chiave di accesso" al network attraverso il fornitore del servizio di accesso internet.

Il Tribunale di giustizia dell'Unione europea ha deciso il 19.10.2016 (C-582/14), che gli indirizzi IP debbano essere considerati dati personali se è possibile, nel paese UE in cui si trova l'indirizzo, determinare il proprietario dell'abbonamento con mezzi legali. In Germania ciò è possibile, ad esempio per la repressione della criminalità. Basta che sia possibile ottenere questa informazione sull'abbonamento, anche se richiedendo l'intervento di più persone (fornitori di telecomunicazioni, servizi segreti, polizia…). Il TUE si applica anche agli indirizzi IP dinamici. Il Tribunale federale tedesco ha confermato questa sentenza il 16.05.2017 (VI ZR 135/13).

Con alcuni esempi concreti vorrei ora verificare se una conservazione di indirizzi IP senza motivazione può essere giustificata.

Denial of Service Attacken

Con questo tipo di attacco un server viene bombardato con richieste maligne in massa al punto da crollare e non poter più svolgere il suo lavoro normale.

È facile stabilire se da un'indirizzo IP sono stati fatti numerosi accessi all'interno di una unità di tempo. Per questo viene tenuta traccia di ogni indirizzo IP nel cache del server, quindi non è protocollato e tecnicamente non è archiviato. Se si verifica un accesso successivo da stesso indirizzo IP, il contatore aumenta di uno. Se ad esempio il contatore per un indirizzo IP raggiunge i 200 all'interno di una minuta, si può supporre che ci sia stato un attacco malizioso.

Un motivo può essere una giustificazione per la registrazione di un'intera indirizzo IP. La registrazione sembra non essere consentita senza un motivo specifico.

Il mio attuale livello di conoscenza.

Se la probabilità di un attacco maligno è sufficientemente alta, un motivo per registrare gli indirizzi IP è dato. Solo a questo punto deve essere effettivamente registrata l'indirizzo IP, se lo si fa. In questo modo, questa unica IP può essere bloccata per future accessi.

Distributed Denial of Service Attacken

Con questo tipo di attacco, anche abbreviato con DDoS, vengono eseguite richieste in massa da numerosi computer su un server bersaglio. Nell'ultima scena di attacco queste richieste sono state eseguite solo da un computer o al massimo da pochi computer di attacco.

Attacchi di tipo verticale si caratterizzano in particolare per il fatto che i computer degli aggressori hanno diverse IP-Adressi. Se il server attaccato blocca solo singole IP-Adresse, non riuscirà a fermare l'attacco con sufficiente rapidità. Infatti ci sono moltissimi sistemi di attacco e non uno solo da disabilitare.

Una possibilità per riconoscere gli attaccanti distribuiti è l'interpretazione più ampia degli indirizzi dell'attaccante. Per far ciò, ad esempio, si lascia cadere l'ultimo byte di un indirizzo IPv4 (=indirizzo IP con 4 byte). Esempio:

• Denial of Service
  • Indirizzo IP dell'attaccante: 10.20.30.40.
  • Disabilitare l'attacco: Blocco dell'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
  • Bloccare l'attacco: Blocco delle aree di IP 10.20.30.x o addirittura degli accessi da una regione geografica, come ad esempio un paese

Per riconoscere se gli attaccanti hanno diverse indirizzi di rete, possono essere valutati ulteriori Metadati. Un indirizzo IP ha in particolare i seguenti caratteristici che ad esempio possono essere stabiliti automaticamente tramite database.

• Terra. Esempio: Germania.
• Fornitore. Esempio: Vodafone.
• Indirizzo host. Per alcune IPindirizzi disponibili informazioni aggiuntive direttamente. Esempi: 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
• Codice ASN: Numero di Sistema Autonomo. Un sistema autonomo è una sorta di ufficio postale. Dal grande ufficio postale viene inviato un pacchetto di dati all'ufficio postale locale, che lo distribuisce poi sul posto. Un fornitore tiene più uffici postali, quindi ASNs.
• Sottorete. Più di una successione di indirizzi IP adiacenti. Esempio: 10.20.30.0 fino a 10.20.30.255, quindi 10.20.30.x o 10.20.30.0/24.
• Riputazione. Viene spesso condotta sotto forma di un valore (Punteggio ) o come lista negativa (Lista Nera ).

Inoltre all'indirizzo IP esistono altre informazioni di metadati, almeno quando si accede a siti web, tra cui:

• Utente-Agente: Tipo di browser, Versione del browser, Tipo di sistema operativo, Versione del sistema operativo. Esempio: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
• Nella barra degli strumenti impostata lingua dell'utente. Esempio: de,en-US;q=0.7,en;q=0.3
• Configurazione del Cache. Esempio: no-cache (Cache disattivato)
• Riferitore: Pagina da cui è stato effettuato l'accesso (ad esempio cliccando su un link. Esempio: https://dr-dsgvo.de/
• URL richiamata: Pagina con tutti i parametri URL che è stata chiamata. Esempio: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
• Dati di contenuto: Sono spesso ottenute dai parametri URL (GET) o dalla richiesta (POST). Esempio: Username=SELECT * from users
• Punto di accesso: Si verifica sempre, anche per tutte le altre richieste di rete. Infatti il destinatario di un messaggio sa quando lo ha ricevuto.
• Stato di destinazione: Riceve il mittente risposte alle sue richieste o utilizza un indirizzo di posta elettronica inaccessibile (perché falsificata)?

Queste informazioni possono essere considerate come dati personali e quindi riferiti a persone (vgl. Art. 4 Nr. 1 DSGVO). Se si conservassero senza crittografia e senza tagli, non ci sarebbe molto da guadagnare. Si suggerisce di crittografare queste informazioni, se sembrano utili per la prevenzione dei pericoli, in modo che siano protette. Questa crittografia può essere raggiunta attraverso un procedimento matematico.

Critturazione dei dati personali

Il cifrare dei dati avviene in modo tale che un valore di dati viene combinato con un chiave scelta a piacere, adatto. Il risultato è un valore finale. Con un procedimento di hash crittografico potrebbero essere generati anche valori che non devono essere univoci. Più valori di input diversi potrebbero quindi essere mappati sullo stesso valore finale. La probabilità di ciò può essere mantenuta molto bassa o addirittura esclusa (chiamato immagine iniettiva o procedimento perfetto senza collisioni) attraverso la scelta di procedure e parametri adeguati.

Un valore di obiettivo è una data pseudonima, finché il valore della chiave è noto. Ecco un esempio:

1. L'utente X accede a un sito web con l'indirizzo IP A1. L'indirizzo A1 viene convertito nel valore di destinazione H1 utilizzando la chiave S1.
2. L'H1 non può essere riportato a A1 perché il procedimento è asimmetrico.
3. Il utente X richiama nuovamente la pagina web con l'indirizzo A1, e si crea nuovamente il valore di destinazione H1 attraverso S1. H1 era già stato salvato nella banca dati. Si trova quindi questo valore H1 per un momento precedente. Quindi è noto che l'utente X ha richiesto la pagina web in quel momento e in questo momento. Quindi si può ricondurre H1 a A1.

Con chiavi valide solo in un determinato periodo di tempo è possibile una pseudonymizzazione temporanea con successiva anonimizzazione. A tale scopo sono adatti le funzioni a senso unico. Una funzione a senso unico consente il cifrare, ma non il decifrare. Se esiste un valore chiaro che è stato precedentemente cifrato, dopo averlo cifrato nuovamente si può confrontarlo con il valore cifrato precedente. In questo modo si può stabilire se il valore chiaro era già presente in precedenza. Il valore cifrato però non può essere decifrato senza il nuovo valore chiaro.

Per valori di input estremamente brevi, devono essere adottate misure adeguate per garantire che una decrittazione efficiente non sia possibile. In particolare, non possono essere utilizzate Tabelle Rainbow. Il meglio è che il procedimento sia progettato in modo tale che tali tabelline non siano applicabili.

Se il chiave S1 è valida solo per 24 ore e viene poi dimenticata, non sarà più possibile decrittare tutti i valori di destinazione generati con questa chiave. Quindi dopo 24 ore ci saranno dati anonimizzati e non più pseudonimizzati. Ciò significherebbe anche un protezione contro le tabelle arcobaleno almeno dopo la scadenza della chiave.

Prevenzione dei pericoli attraverso i metadati o pseudonimizzazione

La domanda era se si possa difendere solo le attacchi DDoS, registrando gratuitamente gli indirizzi IP. Io sostengo che per difendere gli attacchi DDoS non è necessario conoscere gli indirizzi IP.

In caso di violazione dei diritti dell'utente non ottimale, le IP-Adressi sarebbero registrate in forma di data pseudonima con un procedimento di cifratura che potrebbe non avere una funzione a senso unico. Un attacco DDoS si caratterizza probabilmente per il fatto che gli aggressori lanciano velocemente una serie di attacchi uno dopo l'altro. Una chiave dipendente dal tempo offre quindi la possibilità di pseudonimizzare, senza motivo utilizzata. Questo procedimento non sarebbe peggiore della registrazione delle IP-Adressi complete in tempo reale. Solo nella visione retrospettiva sarebbe peggiore. Una visione retrospettiva è spesso utile per analizzare le onde di attacco.

Le minacce possono essere più efficacemente respinte se si registrano indirizzi IP ridotti o metadati a indirizzi IP. Quali metadati possano essere utili, ho descritto sopra.

Durante un attacco DoS o DDoS gli aggressori possono facilmente falsificare l'indirizzo di spedizione (indirizzo IP) dei loro messaggi maligni, poiché non hanno bisogno di ricevere una risposta. L'aggressore potrebbe quindi utilizzare indirizzi IP variabili. Se si fosse salvati gli indirizzi IP completi, in questo caso non sarebbe stato guadagnato nulla, almeno in tempo reale.

Pochi accessi: gli attaccanti che accedono a un sistema di vittima solo una volta o poche volte possono non essere riconosciuti affatto o in modo occasionale. Un login con dati utente rubati può essere annotato con un protocollo IP in base all'occasione. L'exploit di una vulnerabilità, come nel caso di Log4J, attraverso solo un accesso non può essere prevenuto o riconosciuto ad hoc mediante un protocollo IP. Quindi è stupido, ma la conservazione delle informazioni IP senza alcun motivo per identificare un possibile autore è inammissibile. Le dashcam negli auto, che filmano permanentemente e senza alcun motivo, sono altrettanto inammissibili. Purtroppo, ma così è, anche se ciò significa che il colpevole non può essere identificato. Se un attaccante inserisce codice dannoso in un campo di formazione per rubare dati, ciò potrebbe essere rilevato valutando i dati di input. Ad esempio, le SQL injection possono essere riconosciute. Inoltre, il codice dannoso può essere reso inefficace se sul server è presente una programmazione appropriata. È più facile da dire che fare, come si è visto nella vasta biblioteca di aiuto Log4J, che ha permesso attacchi hacker efficaci senza sforzo. Tuttavia, nemmeno un'intera IP annotata non aiuta a riconoscere l'attacco meglio di quanto sarebbe possibile altrimenti (sostengo).

Utilizzano gli aggressori indirizzi IP temporaneamente stabili, aiutano i metadati degli indirizzi IP in tempo reale a riconoscere gli attacchi. Inoltre, grazie ai metadati è possibile una valutazione retrospettiva automatica o manuale molto più facile che se si fosse salvato solo l'indirizzo IP completo e i metadati dovessero essere recuperati per un'analisi di attacco. La prima volta è sempre la prima volta. Ciò significa: In una prima offensiva, analizzata successivamente, il bersaglio deve faticare a determinare i metadati per le registrazioni complete degli indirizzi IP protocollate. A meno che i metadati non siano stati registrati direttamente, il meglio possibile senza l'indirizzo IP completo. Una registrazione completa di indirizzi IP senza metadati ha quindi ovviamente anche svantaggi tecnici.

Un attacco che sempre richiama la stessa pagina di destinazione (URL) può essere facilmente riconosciuto. Se una pagina di destinazione viene chiamata molto più spesso del normale, potrebbe esserci un motivo per registrare le protocolli IP. In questo caso, una registrazione senza motivo sarebbe quindi non necessaria per la prevenzione dei pericoli.

Attacchi DDoS che possono essere attribuiti a un determinato paese non si verificano di solito in Germania. In Germania abbiamo ottime possibilità di perseguire legalmente. D'altra parte, computer zombie potrebbero essere utilizzati per un attacco dal territorio nazionale. Siti web tedeschi, comunque, potrebbero riconoscere e bloccare accessi dall'estero che sembrano attacchi, senza conoscere le IP complete (vedi sopra: ASN, paese, provider). Per gli attacchi zombie, invece, un'analisi delle chiamate sarebbe utile (URL di destinazione, parametri, frequenza, User-Agent…).

Certi attacchi non potrebbero essere bloccati neanche con la registrazione completa degli indirizzi IP o con altri mezzi. Non è quindi necessario discutere ulteriormente di questo tipo di attacchi quando si tratta della registrazione senza motivazione degli indirizzi di rete completi. Esempi di tali attacchi sono:

• Codice dannoso: A un utente registrato viene inviato un link dannoso. O si utilizza un reputer zombie per l'invio della mail o una proxy o un sito web infettato. Se il hacker è particolarmente stupido, utilizza il proprio collegamento per inviare la mail. In ogni caso: nel header della mail è spesso registrata l'indirizzo IP dell'inviatore e non deve essere registrato separatamente. Indipendentemente da ciò, anche la ricezione di un'e-mail potrebbe essere considerata come motivo. Nelle pagine web hackerate, su cui viene posizionato il codice dannoso, la registrazione dell'indirizzo IP al momento del clic sul link non porta a nulla.
• IP-Spoofing: gli attaccanti utilizzano indirizzi IP di origine generati casualmente e metadati. La risposta non la ricevono, ma si limitano a danneggiare la vittima con richieste maliziose. In passato (anche oggi?) agli attaccanti era possibile ottenere le risposte per altre indirizzi (Backscatter-Attacke).
• Dati di accesso recuperati: La conoscenza dei dati di accesso fa sembrare un hacker come un utente legittimo. Al massimo attraverso attività anomale o indagini più approfondite o addirittura indicazioni dall'effettivo proprietario dei dati di accesso possono essere scoperti tali accessi. Se l'accesso è da fuori paese o da un altro dispositivo diverso da quello che era normale, può essere inserita una verifica di sicurezza (CAPTCHA, domanda sulla data di nascita ecc.) in base all'occasione. Ma anche qui la conoscenza dell'indirizzo IP completo non aiuta ulteriormente, almeno non ulteriormente della metadati, che consentono un'analisi più ampia.

In un quadro piuttosto generico ho elencato alcune tipologie di attacchi. Le categorie si sovrappongono probabilmente (un DoS può essere effettuato sia dall'interno che dall'estero ecc.). La tabella deve solo fornire un'idea d'insieme e non è affatto completa.

Tipo di attacco	Riconoscimento
Accesso eccessivo	Confrontare l'indirizzo IP concreto nel disco.
Denial of Service	Confrontare l'indirizzo IP concreto nel disco.
Distributed Denial of Service	Valutare indirizzi IP ridotti o metadati.
Inserimento di codice dannoso (iniezione SQL ecc.)	Controllare i dati di contenuto contro le parole chiave e i segni di interpunzione.
Accesso di hacker (accesso rubato)	Cercare nell'archivio una specifica indirizzo IP quando gli indirizzi IP degli utenti registrati sono memorizzati, o registrazione diretta (motivo = accesso)
Attacco dall'estero	Valutare i metadati, in particolare paese, ASN, subnet.
Attacco dall'interno	Valutare le metadati, in particolare ASN, subnet.
IP-Spoofing	Se possibile, verificare l'indirizzo di posta contro il routing table considerato valido, ad esempio in rete locale è fattibile. Gg. può aiutare Unicast RPF (non è la mia specialità)

Dopo che un attacco è stato riconosciuto o considerato probabile, può (deve) avvenire una registrazione motivata delle IP se queste sono necessarie per la prevenzione dei danni.

Se viene bloccata un'indirizzo IP perché considerato come indirizzo di attacco, esistono i seguenti pericoli:

1. L'indirizzo è effettivamente un innocente e non un aggressore, ma è stato ingiustamente sospettato (ciò sembra particolarmente possibile in caso di blocco automatico).
2. L'indirizzo era falso e apparteneva o a un altro collegamento benigno o a nessuno (in tal caso l'effetto di una chiusura sarebbe stato zero).
3. L'indirizzo apparteneva a un attaccante, ma è stato ora assegnato ad un altro (beninteso) collegamento. Ciò può accadere sempre di nuovo con gli indirizzi IP dinamici, ma anche quando si accede attraverso il network Tor.
4. L'indirizzo è assegnato a più connessioni tramite Carrier Grade NAT. Tutte le connessioni ad eccezione di una sono quindi potenzialmente innocue e vengono involontariamente bloccate.
5. L'indirizzo rappresenta un proxy. Se l'indirizzo della proxy è bloccato, nessun collegamento può stabilire una connessione attraverso la proxy.

La sospensione di un'indirizzo IP non risolve necessariamente tutti i problemi, ma può addirittura aggravarli in alcuni casi.

Altri motivi che non sono attacchi possono essere:

• Scopi di test, ad esempio ricerca di errori, ottimizzazioni o nuove sviluppo
• Tentativi di registrazione con nome utente e/o password
• Inserimento di dati strani in un modulo (qui non si intende necessariamente codice malevolo)

Non entro in questi argomenti, poiché qui si tratta della questione della registrazione senza motivazione!

Conclusione

Il protocollo di indirizzi IP senza motivo per la prevenzione dei pericoli sembra non essere tecnologicamente necessario. Non vedo alcun indizio contrario. Invece di numeri completi di IP, possono essere protocollati i seguenti dati:

• Zone di indirizzo IP (anche subnet)
• Blocchi di indirizzi IP
• Nome fittizio, come obiettivi temporaneamente limitati e reversibili che diventano anonimi dopo breve tempo
• Informazioni metadati sulle indirizzi IP:
  • Terra
  • Fornitore
  • Codice ASN
  • Nomi di host
  • Riputazione
• Informazioni metadati sulla connessione
  • Obiettivo richiesto (indirizzo URL ecc.)
  • Metadati dell'invio come User-Agent o configurazione del cache
  • Punto di accesso
  • Accesso alla controparte

Se invece c'è un motivo valido, la registrazione completa dell'indirizzo IP può essere giustificata. Esempi di motivi validi potrebbero essere:

• Chiamata eccessivamente frequente da una fonte
• Comportamento anomalo dell'utente
• Chiamate anomale (ad esempio parametri di URL inusuali o indirizzi non esistenti)
• Dati di metadato sospetti (esempio: accessi da Paese X o dal subnet Y)
• Risposta non conforme a quanto previsto
• Ricerca di errori (esempio: registrare i propri accessi per trovare gli errori del network)

Ci possono essere differenze nella valutazione dei scenari di minaccia nei reti piccole e grandi e nelle pagine web piccole e grandi, ma non riesco a riconoscere un differenza rilevante per la domanda trattata in questo articolo. Sono felice di ricevere ogni commento.

Al di là del fatto che l'invio di un commento su un portale di opinioni non è un motivo per registrare un accesso al file di log del webserver con l'indirizzo IP, si tratta invece di memorizzare il commento, eventualmente insieme all'indirizzo IP dell'autore, in una banca dati.

All'inizio avevo scritto che si trattava solo di server propri, non di fornitori di accesso a Internet (ISPs). Se gli ISPs devono assolutamente e senza motivo registrare l'intera IP-Address per contrastare alcuni pericoli, fino a nuovo ordine mi permetterò di dubitare, anche se è più probabile che questi dubbi siano infondati per gli ISP. Lo stesso vale per reti di distribuzione del contenuto (CDNs). Se i CDNs registrano senza motivo intere IP-Address, ciò deve essere comunicato dal fornitore del CDN. Mi è noto da Akamai che si verifichi tale registrazione senza motivo. Per questo motivo è stato vietato l'uso del servizio Cookiebot, che utilizza i server di Akamai.

La registrazione delle intere indirizzi IP senza motivo da parte dei gestori di server per la prevenzione del pericolo non è tecnicamente necessaria.

La mia conoscenza fino a prova contraria.

Se non condividete questo punto di vista, vedo due possibilità:

1. Potete citare un esempio concreto e comprensibile. In questo caso, sarò felice di controllarlo e cambiare idea se il vostro esempio lo giustifica.
2. Non possono citare un esempio concreto. In questo caso dovrebbero cambiare opinione, se lo vogliono o no, perché l'opinione sarebbe infondata e ingiustificata.

Per favore scrivete a me di chi conosce un esempio specifico che potrebbe essere rilevante per il gestore di un server. Ricordo nuovamente che si tratta della questione della protokollierung senza motivi, non della protokollierung in relazione a un motivo riconosciuto! Non si tratta nemmeno di una valutazione dell'utilità, ma di una valutazione della necessità. Come parola chiave si può citare il mezzo più lieve. E ci sono molti altri mezzi che potrebbero essere altrettanto adatti o addirittura meglio adatti per riconoscere o contrastare i pericoli.

Non è la utilità a essere decisiva, ma la necessità e l'accessibilità di mezzi meno gravi.

Questo principio vale probabilmente in molti settori della protezione dei dati.

Un breve riassunto della sua utilità:

Accaduto	Utile?	Necessario/Consentito?
Omissione della dichiarazione dei redditi	Sì, per tutti quelli che non ne hanno voglia	No, dice la legge
Rapina in banca	Sì, per chi ha bisogno di soldi	No, dice la legge
Videoregistrazione con dashcam (con memorizzazione permanente)	Sì, poi dimostrare che un altro è stato colpevole in un incidente	No, comunque non a lungo (almeno così credo)
Raccolta di indirizzi IP senza motivo	Sì, sicuramente per molti	No, affermo nel presente articolo

Non si tratta di perseguire un'indagine penale, poiché ciò non è affar del gestore di un server e neppure dell'intero server (a meno che il server appartenga a una persona autorizzata per la persecuzione penale).

Le mie conversazioni con esperti e le mie domande a diverse gruppi di esperti in un network sociale mi hanno dato comunque ragione che nessuno potesse citare neanche un solo esempio per confutare la mia posizione. Anche il BSI (German federal security agency) non poteva dirmi alcun esempio concreto. Invece, ho ricevuto una risposta con poche informazioni interessanti. C'era circa menzionato che le indirizzi IP sono dati personali e che si dovrebbero tenere conto delle norme giuridiche della DS-GVO. Tutto questo era già noto a me. Inoltre, è stato fatto riferimento al Compendio del BSI (German federal security agency), in cui non c'era neanche un esempio concreto da trovare (spero di non aver dimenticato nulla).

Se conservate sempre l'indirizzo IP completo degli utenti del vostro rete pubblicamente accessibile nei vostri log dei server: Smettetela immediatamente o fornite un esempio specifico per la prevenzione di pericoli o un altro motivo legittimo per cui è consentito

Questa richiesta si rivolge a comuni gestori di server, non a ISP, autorità di polizia ecc.

Di recente ho scoperto che sul server FTP di un cliente viene scritto il protocollo del server con indirizzi IP completi. Da ciò si pone la domanda, quale utilità possa avere questa informazione per il cliente. L'utilità in pratica dovrebbe avvicinarsi a zero. Il cliente non potrà ad esempio limitare le attacchi DoS sul suo server virtuale anche se conosce gli indirizzi IP degli aggressori. Lo stesso vale spesso per i server gestiti. Ciò solo di sfuggita, anche se non cambia la questione in sé.

In effetti il NDR, come responsabile del sito web della Tagesschau, registra secondo le indicazioni sulla protezione dei dati la piena IP di tutti gli utenti. Perché ciò accade non viene spiegato. È sicuro che anche il responsabile per la protezione dei dati del NDR non lo sappia e/o non lo dica.

Nel mio articolo dedicato, mi occupo della durata massima di archiviazione dei log dei file web.