Protokolering af IP-adresser i serverlogfiler: tilladt eller ikke?

Ifølge dataskyddsbekendtgørelser på mange hjemmesider bliver IP-adresser i serverlogfiler lagret i fuld længde, og det sker ofte med den begrundelse, at det er nødvendigt for sikkerhedsformål uden nogen grund. Om den grundløse protokolering er tilladt afhænger af, om den teknisk er nødvendig eller hvis der er mildere midler til rådighed.

Indledning

Afgrænsning: Artiklen omfatter kun offentligt tilgængelige servere fra almindelige ejere, dvs.IKKE fra ISPs, politi osv. Det drejer sig her især ikke om de tilfælde, der er dækket af § 172 TKG. En retlig grundlag efter Art. 6 DSGVO, f.eks. en samtykke, bliver antaget som ikke givet (ellers ville spørgsmålet hurtigt være besvaret).

Fordi det hele tiden fører til misforståelser: Forståelsen af begrebet "anledning" er grundlæggende! Det forklares i bidraget. Vorratsdatenspeicherung hedder sådan, fordi den sker uden anledning, altså hele tiden!

IP-adresser er netværksadresser. De er en del af Metadatene, der overføres hver gang en hjemmeside bliver tilkaldt. Disse metadatater bliver også kaldt trafikdata eller forbindelsesdata. Betydningen af disse to begreber synes at være forskellig i det tekniske og juridiske kontekst. Derfor bruger jeg betegnelsen Metadatene.

IP-adresser er ifølge højesteretspraksis fra EU-domstolen og Tysklands føderale højesteret personlige oplysninger. Det gælder også for dynamiske IP-adresser, og det har været tilfældet siden 2016 (EU-domstolen) og 2017 (Tysklands føderale højesteret). Den europæiske dataskyddsforskrift er i kraft siden slutningen af maj 2018.

IP-adresser kan muligvis tillade det at angreb kan identificeres og dermed i visse tilfælde kan serveres sikkerhed øges. Desuden kan ved kendskab til en IP-adresse eventuelt føre til straffeforsøg. Alt dette synes mig plausibelt, selv om det ikke gælder for hverken et hvilket som helst angrebsscenarie. Mine samtalerum, hvor mange eksperter fra IT-sikkerhed og rett har deltaget, bekræfter dette.

IP-adresser er således nyttige til at forbedre sikkerheden på en server og til at identificere gerningerne. Nytten er dog ikke et afgørende retfærdiggørelsesgrund.

Spørgsmålet lyder:

Skal fulde IP-adresser uden grund registreres af servere, der drives af andre end selv, eller findes der mildere midler?

Spørgsmålet i denne artikel.

Denne artikel fokuserer så på serverejer. Internetserviceleverandører (ISP) som Deutsche Telekom eller Vodafone skal her ikke medregnes på grund af kompleksitet.

---

Opdatering: Den europæiske domstol havde endda erklæret, at opbevaringen af persondata uden grund for retslig lovpligtighed var ulovlig, hvis den kunne bruges til at afdække alvorlige forbrydelser. Se EuGH-dom fra 05.04.2022 (Sag nr.: C-140/20).

Selvlovepræggede lovgivning, som præventivt skal bekæmpe alvorlige kriminalitetsformer og forebygge alvorlige trusler mod den offentlige sikkerhed ved at foreskrive en allgemein og uden forbehold tilgængelig opbevaring af trafik- og positioneringsdata, er ulovlig.

Min formulering af EG-domstolens afgørelse af 05.04.2022, RN. 101.

Den Europæiske Domstol fastholder videre, at det kun er tilladt til forebygge trussel mod den offentlige sikkerhed og bekæmpe alvorlig kriminalitet, hvis man "for en begrænset periode på absolut nødvendigt niveau gør en allgemeine und unterschiedslose Vorratsspeicherung der IP adresses, som er tilknyttet en forbindelse" (punkt 101 i dommen). Den Europæiske Domstol bekræfter således, efter min opfattelse, det, hvad jeg allerede tidligere har udtalt. Fordi private ejere af (web)servere har meget lidt eller intet med den offentlige sikkerhed at gøre og slet ikke noget med bekæmpelsen af alvorlig kriminalitet.

---

Nu videre i teksten uden direkte henvisning til ovennævnte EU-dom, der først blev afgivet efter at jeg havde skrevet min tekst.

Det handler i min artikel om følgende tre betingelser, der pludselig gælder:

• FRI FORÅR (!!!!)
• Protokolering ( = fastholdende opbevaring, f.eks. i filer )
• FULDSTENDIGE IP-ADRESSER

Formålet er at forebygge farer. Efterforskning har intet med jer og mig at gøre og heller ikke med jeres server, bortset fra I er politi, statsadvokat o.sv.

Tak i forvejen for at læse dette indlæg! Indtag disse betingelser, før I fortsætter med at læse og tror, I kan svare på spørgsmålet i dette indlæg!

Det handler ikke om:

• Protokolering med tilknytning til en begivenhed og/eller
• Kun kortvarigt i hovedmindeholdte data og/eller
• Brug af andre data end fulde IP-adresser og/eller
• Efterfølgende af myndigheder, politi og statsadvokater.

Har du forstået det? Så læs venligst videre og meld dig til mig, hvis du vil være den første, der kan nævne et konkret eksempel på en uden anledning foretaget protokolering af IP-adresser, hvor man kan se en lovgivende grundlag.

Anledningsløs betyder, at IP-adresser altid protokolles. Anledningssammenhængende ville betyde, at med IP-adressenprotokolering først starter ved indtrængen af et begivenhed, som en påstået hackerangreb eller til fejlsøgning ved netværksproblemer eller ved en loginforsøg med et adgangskode, starter. Begivenheden gælder først fra den tidspunkt, hvor den er fastlagt eller antaget. En rækkevidende antagelse af begivenhed er ulovlig. For sådan ville altid protokolles blive, for at senere 99 % af dataene skulle kasseres (som derefter anledningsløse og dermed, som påstået, ulovligt, protokollet blev), blot for at bruge 1 % af dataene til den første senere fastlagte begivenhed. En begivenhed kan også betragtes som givet, hvis en automatisme med en høj nok sandsynlighed ser en begivenhed som foreliggende. Den høje sandsynlighed kan dog ikke være tilfældet for hver enkelt (dvs anledningsløse) adgang (bortset fra, hvis hver enkelt adgang til et server sker fra en hacker). I denne artikel handler det ikke om at diskutere sandsynlighedsværdier. En permanent protokolering af alle følger i hvert fald på en sandsynlighed af null procent, at en begivenhed foreligger, og er ikke tilladende, påstås jeg.

En årsag er et antaget begivenhed. En altid foregående protokolering er tydeligt uden årsag.

Erklæring.

En begivenhed bliver på en anden plads også kaldt Følge af begivenheder. Se her til det IT-Sikkerhedsgrundbog fra BSI (German federal security agency). Der finder man, hvis jeg har set det rigtigt, ingen conkrete henvisning til, at fulde IP-adresser uden begivenhed (dvs uden anledning) skal protokoleres. Selv om denne henvisning ville være i BSI (German federal security agency) Grundbogen, manglede der et conkrete eksempel til at redegøre for en berettiget interesse som retsgrundlag efter artikel 6 DSGVO.

Jeg vurderer først til at besvare spørgsmålet om IP-adresser skal protokoleres uden grund, formålet med IP-adressen i forbindelse med straffeforfølgning, og dernæst til sikring af systemer.

Efterforskning

En server har ikke til opgave at følge efter straffelovens bestemmelser. Heller ikke en serverejer har til opgave at følge efter straffelovens bestemmelser. Spørg en jurist, hvis du ser det anderledes.

Således udelukkes formålet med straffeforfølgelse som redegørelse for opbevaring af IP-adresser uden grund.

Efterfølgning af forbrydelser tilkommer hverken serverejer eller serveren selv, så denne grund skal ikke bruges som begrundelse for at opbevare netadresser uden omgang med en anledning.

Tyve ser ud til at være det, selv om det måske kan være en god idé i visse situationer at have en hjælper tilbage.

Et aktuel eksempel på en nyttig, men alligevel forbudt databehandling var udarbejdelsen af en kontaktliste i et restaurant til at følge op på Corona-sagen. Den hovedstadspoliti søger nemlig en vidne til en dødsfald af en gæst i restauranten. Derfor tog politiet data fra Luca-app'en, som den restaurant-ejer havde registreret efter pligt. Politiet kontaktede derefter de restaurantrådgivere, der var på stedet under den pågældende tid. Det var sikkert nyttig. Men det var forbudt. Fordi dataene blev indsamlet kun til sundhedsformål. Statsadvokaten undersøgte derefter politiet og undskyldte sig over for de retsvidtgående vidner.

Et andet eksempel: Såkaldte Kryptofonere blev eller blev brugt af kriminelle til at holde sig hemmeligt i samtalerne. Politiet lykkedes med at dechiffreere kommunikationen over disse hænder. Den måde, hvorpå beviserne blev indsamlet, blev sat spørgsmål (jeg tror det var fordi der ikke var en domstolsbeslutning). Men på grund af den faktum, at det drejede sig om et tilfælde, faldt fundet af beskederne i de dechiffrede hænder som bevis. Det kunne være været muligt, at denne nyttige findelse ville være blevet ulovlig og derfor ikke kunne have været brugt som bevis. KG Berlin havde klassificeret fundet som et tilfælde i henhold til § 100e Abs. 6 Nr. 1 StPO.

Trusselforsvar

Sikkerheden ved behandling er påkrævet i Art. 32 DSGVO. Ifølge dette skal IT-systemer således driftes, at risikoen for sikkerhedshændelser reduceres til en rimelig grad. Faren fra sikkerhedshændelser skal dog ikke kun være en retlig krav, men også det egentlige interesse af ansvarlige.

Eksempler på sikkerhedsbegivenheder

En ren illustrativ liste med eksempler på det, der falder mig ind som en sikkerhedsbegivenhed og ikke blot bliver kaldt hackerangreb:

• Denial of Service Attacke (DoS)
• Distributed Denial of Service Attacke (DDoS)
• Malware, Ransomware, Viren
• Tilgængelighed af adgangskoder
• Omvandling af et system til en zombie-computer

Nogle af de nævnte angreb finder sted via mekanismer som Session Hijacking, Phishing, Spam-mails eller udnyttelse af exploits/sikkerhedsbrister (eksempel: Log4J).

Listenningen er sikkert ikke fuldstændig. Hvis et vigtigt scenario mangler, beder jeg om at få en besked (såsom via kommentarfeltet nedenfor).

IP adresses

Hvert internetforbindelse baserer sig på en netværksadresse, der også kaldes IP-adresse. Hver bruger har en IP-adresse (som tildeles via et apparat, som f.eks. en router). Ofte får privatpersoner en dynamisk IP-adresse fra sin leverandør. Denne ændrer sig i uregelmæssige tidsrum, eller måske også i regelmæssige tidsrum. Ved kabel-bundne internetforbindelser synes den IP-adresseskiftning at være sjældnere end f.eks. ved forbindelser over telefonlinjer. Ved et strømudbrud finder sikkert også en (uigennemtænkt) skiftning af en IP-adresse sted, som jeg selv har opdaget. Over en reset af Fritz!Box-forbindelsen, hvis denne anvendes, kan ofte også en ny IP-adresse fås.

Nogle leverandører tilbyder også statiske IP-adresser. Disse bruges normalt mere af erhvervsbrugere end af privatpersoner. Statiske IP-adresser ændrer sig ikke over tid.

Fordelingen af IPv4-adresser er begrænset, og der kan under visse omstændigheder tildeles samme IP-adresse flere forskellige anslutninger, altså personer. Denne tildelelse bliver teknisk gennemført ved hjælp af forskellige porte. En betegnelse for dette er KARRIEREGRAD NAPT (CGN) (CGN), der i overensstemmelse med oversættelsen betyder noget i retning af "netværksopslusning" via internettilgangsdienstleverandøren.

EU-domstolen afgjorde den 19.10.2016 (C-582/14), at IP-adresser skal betragges som persondata, hvis en opsporing af forbindelses ejeren i det pågældende EU-land er juridisk mulig. I Tyskland er dette muligt, f.eks. til strafferetten. Det er nok den objektive mulighed for at få denne information om forbindelsen under visse omstændigheder også blot ved inddragelse af flere instanser (telefonfirmaet, efterretningstjenesten, politiet…). EU-domstolen gælder også for dynamiske IP-adresser. Den tyske Højesteret bekræftede dette afgørelse den 16.05.2017 (VI ZR 135/13).

Med nogle konkrette eksempler vil jeg nu undersøge, om en uden foranledning foretaget opbeholding af IP-adresser kan være berettiget.

Denial of Service Attacken

Ved denne type angreb bliver en server bombet med bølge af skadelige masseanmodninger, så den kollapser og kan ikke længere udføre sin normale arbejde.

Det er let at afgøre, om der fra samme IP-adresse flere adgangssteder inden for en tidsenhed har fundet sted. Dertil holdes hver IP-adresse i hukommelsen på serveren, altså ikke protokollet og teknisk set ikke gemt væk. Sker en efterfølgende adgang fra samme IP-adresse, bliver en teller øget med 1. Når tæller for en IP-adresse f.eks. inden for én minut er nået op på 200, kan man udgå fra en skadelig adgang.

En årsag kan være en begrundelse for at registrere en fuldstændig IP-adresse. Det synes ikke at være tilladt at protokollere uden grund.

Min nuværende videniveau.

Er der sandsynlighed for en skadelig angreb stor nok, er grund til at registrere IP-adressen givet. Kun fra dette tidspunkt skal IP-adressen, hvis overhovedet, virkelig først registreres. Så kan denne ene IP-adresse spærres for fremtidige adgang.

Distributed Denial of Service Attacken

Bei dieser Art af angreb, også med DDoS forkortet, bliver Massesanmodninger fra mange computere udført mod en server til ofre. I det foregående angriffs scenario blev disse massesanmodninger kun udført fra én computer eller i det bedste fald fra få angreb computersystemer.

Angrebsskikkeligheder tegner sig især ved, at angriberens computer forskellige IP-adresser har. Spærrer den truffende server kun enkelte IP-adresser, bliver han måske ikke hurtigt nok færdig med at spærrer. For der er jo mange angriberes systemer og ikke blot ét, som det skal være nødvendigt at slå ud.

En måde at genkende udbredte angribere på, er det bredere tolkning af angreibernes IP-adresser. Herfra fjernes f.eks. det sidste byte af en IPv4-adresse (IP-adresse med 4 bytes). Eksempel:

• Denial of Service
  • Angrer-IP: 10.20.30.40.
  • Angreb afbryde: Blokering af IP-adressen 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
  • Angreb udslette: Blokering af IP-blokke på 10.20.30.x eller endda adgang fra en geografisk region, som f.eks. et land

For at kunne afgøre, om angribere med forskellige netværksadresser er forbundne, kan yderligere Metadate udvundes. En IP-adresse har især følgende træk, der f.eks. kan fastlægges automatisk ved hjælp af databaser.

• Jord. Eksempel: Tyskland.
• Leverandør. Eksempel: Vodafone.
• Værtadresse. For nogle IP-adresser direkte tilgængelige tilføjelser. Eksempler: 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
• ASN (Autonom System Number): Selvstyrende Systemnummer. Et selvstyrende system er en slags Postkontor. Fra hovedpostkontoret sendes et datapakke til det lokale postkontor, som så fordele det lokalt. En leverandør holder flere postkontorer, altså ASNs.
• Netværk. Flere efterfølgende IP-adresser. Eksempel: 10.20.30.0 til 10.20.30.255, altså 10.20.30.x eller 10.20.30.0/24.
• Reputation. Bliver ofte ført i form af en værdi (Score) eller som en negativ liste (Black List).

Desuden til IP-adressen findes der mindst ved adgang til websteder andre metadatas. Disse er blandt andet:

• Brugeragent: Browsertype, Browser-version, Operativsystemstype, Operativsystemversion. Eksempel: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
• Browserindstillede Sprog af brugeren. Eksempel: de,en-US;q=0.7,en;q=0.3
• Cache-konfiguration. Eksempel: no-cache (Cache deaktiveret)
• Referer: Side, hvor opkaldet fandt sted (f.eks. ved klik på en link. Eksempel: https://dr-dsgvo.de/
• Opkaldte URL: Side med URL-parametre, der blev opkaldt. Eksempel: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
• Indholdsbegreber: Oprinderes ofte fra URL-parametre (GET) eller anmodningen (POST). Eksempel: Brugernavn=SELECT * from users
• Tidspunkt for adgang: Ligger altid til gavn, også ved andre netværksanmodninger. Til sidst ved, hvornår modtageren af en besked har fået den.
• Status af at være i sengen: Får modtageren svar på sine spørgsmål eller bruger han en uigangelig (da falsk) afsenderadresse?

Disse data kan, mindst i kombination, betragtes som personrelaterede og dermed personrelaterede data (se Art. 4 Nr. 1 DSGVO). Hvis man lagrede disse data uslukret og uklippet, ville man ikke have meget at gøre med det. Det foreslås at disse data, hvis de er nyttige til at forebygge farer, skal lukkes. Dette lukning kan opnås ved et matematisk procedur.

Persondaternes kryptering

En kryptering af data sker på en sådan måde, at en dataværdi kombinere med et frit valgt, passende Schlüsselværd. Resultatet er en målomdækningsværdi. Med et kryptografisk hash-funktion kunne også værdier genereres, der ikke nødvendigvis skal være unikke. Flere forskellige indgangsværdier kunne således godt afbildet på samme målomdækningsværdi. Sandsynligheden for dette kan ved valg af passende procedurer og parametre meget let holdes meget lav eller faktisk udelukkes (såkaldt injektive afbildning eller perfekt procedure uden kollisioner).

Et mål værdi er et anonymt dato, så længe nøgle værdien er kendt. Her et eksempel:

1. Bruger X tilgår med IP-adressen A1 en hjemmeside. Adressen A1 bliver omformet med nøgle S1 til målmålet H1.
2. H1 kan ikke føres tilbage til A1, fordi fremgangsmåden er asymmetrisk.
3. Nu søger bruger X igen med adresse A1 på hjemmesiden, og der opstår via S1 igen målet værdi H1. H1 var dog allerede blevet gemt i databasen. Man finder denne værdi H1 således for en tidligere tilgangsperiode. Dermed er det kendt, at bruger X nu og tidligere har åbnet hjemmesiden. Dermed kan H1 i A1 føres tilbage.

Med zeitligt begrenset gyldig nøgle kan en midlertidig pseudonymisering med følgende anonymisering foregå. Herfor er enkæde-funktioner egnet. En enkæde-funktion tillader kryptering, men ikke dekryptering. Ligger et klart værdi forinden først blev krypteret, kan det klare værdi efter kryptering sammenlignes med det tidligere krypterede værdi. Så kan fastslås, at det klare værdi allerede før var til stede. Den krypterede værdi kan dog ikke uden den igen forekomme klare værdi ført tilbage til det klare værdi.

For meget korte indtastningsværdier skal der sikres med tilsvarende tiltag, at en effektiv dekryptering ikke er mulig. Især må inte bruges Rainbow-tabeller. Det bedste er, at proceduren er så udformet, at sådanne tabeller overhovedet ikke kan anvendes.

Hvis nøglen S1 kun er gyldig i 24 timer og derefter bliver glemt, kan alle målverdier, der er genereret med denne nøgle, ikke længere dekrypteres. Dermed vil efter 24 timer anonyme data være til rådighed og ikke længere pseudonymiserede data. Det ville også betyde en beskyttelse mod Rainbow-tabeller, mindst efter udløbet af nøglen.

Farenhedssikring ved hjælp af metadata eller pseudonymisering

Spørgsmålet var jo, om man kun kan afværge DDoS-angreb ved at protokolere IP-adresser uden grund. Jeg påstår, at det ikke er nødvendigt at kende IP-adresserne for at afværge DDoS-angreb.

I et ikke optimalt tilfælde af dataskydd ville IP-adresser i form af et pseudonymt dato med en krypteringsprocedure registreres, der muligvis ikke repræsenterer en ét-vejsfunktion. En DDoS-angreb ville sandsynligvis være karakteriseret ved at angreifer hurtigt efter hinanden udfører angreb. Et tidsspecifik nøgle giver således en mulighed for pseudonymisering, der uden grund kunne anvendes. Dette procedur ville ikke være dårligere end brugen af fulde IP-adresser i realtid. Kun ved retrospektiv analyse ville det være dårligt. En retrospektiv analyse er ofte værdifuld til at analysere angrebsbølger.

Farer kan afværtes hvis der er en god indsats, når reducerede IP-adresser eller metadata til IP-adresser gemmes. Hvilke metadata dette kunne være nyttefuldt med har jeg beskrevet ovenover.

Under DoS- eller DDoS-angreb kan angriberne let fælde deres afsenderadresse (IP-adresse). Fordi de ikke har brug for at modtage en svar på deres skadelige anmodning. Angreberen kunne så skiftende IP-adresser anvende. Hvis man lagrede fulde IP-adresser, ville man her altså have vundet intet, i det mindste ikke i Echtzeit.

Få få tilgange: Angriberne, der kun én gang eller få gange tilgår et ofre-system, kan enten ikke anerkendes eller blot være tilfældige. Et login med erobrede brugeroplysninger kan på tilfældig vis blive føjet en IP-protokol. Det at udnytte en sikkerhedsfejl, som ved Log4J, over kun én tilgang kan ikke forhindres eller ad hoc anerkendes ved hjælp af et IP-protokol. Så dumt det også er, men opbevaring af IP-adressen uden tilfælde, for at overføre en mulig gerningsmand, er ikke tilladt. Dashcams i biler, der hele tiden og uden nogen grund optager billeder, er lige så meget ikke tilladt. Desværre, men det er sådan også, selv om det på den måde kan være svært at overføre en eller anden skyldig. Hvis en angriber indsætter en skadelig kode i et formuleringfelt for at erobre data, kan dette muligvis opdages ved at vurdere de indtastede data. Eksempelvis kan SQL-injektioner opdages på denne måde. Desuden kan skadelig kode blive gjort uvirksom, hvis der på serveren findes en tilsvarende programmering. Det er nemmere sagt end gjort, som man kunne se ved den meget udbredte hjælpebibliotek Log4J, der effektive angreb uden større indsats tillod. Alligevel hjælper en protokollet fuldstændig IP-adresse ikke bedre til at anerkende angrebet end det ville være muligt på anden vis (jeg påstår).

Brugere, der angriber bruger relativ stabile IP-adresser, hjælper metadata fra IP-adressen med at identificere angreb i realtid. Desuden er det meget lettere at gennemføre en automatisk eller manuel efterretningsanalyse ved hjælp af metadata, hvis kun hele IP-adressen blev gemt og metadataene skulle opdateres først til en angrebsanalyse. Det første gang er altid det første gang. Dette betyder: Ved første angreb, der analyseres senere, skal ofret arbejdsværdigt finde metadata for de protokolerede fulde IP-adresser. Bortset fra, hvis metadataerne blev direkte protokollet uden hele IP-adresse. En fuldstændig protokolering af IP-adresser uden metadata har således også tekniske ulemper.

En angreb, der altid kalder på samme målside (URL), kan let identificeres. Hvis en målside bliver opkaldt meget ofte, mere end hvad der ville være normalt, kunne det føre til en anledning for at protokolere IP-adressen. En uden anledning foretaget protokolering ville her ikke være nødvendig for at afværge farer.

DDoS-angreb, der kan tilknyttes et bestemt land, finder normalt ikke sted i Tyskland. I Tyskland har vi ret gode muligheder for at følge loven. På den anden side kunne Zombie-computere bruges til en angreb fra hjemlandet. Danske websteder kunne i hvert fald godt genkende og blokere tilgange fra udlandet, der kan betragtes som angreb. Det ville gå helt uden at kende fulde IP-adresser (se oven: ASN, land, provider). For zombie-angrebene ville en analyse af de tilgange være hjælpsomme (mål-URLs, parametre, frekvens, User-Agent…).

Bestemte angreb kunne ikke blokeres ved hjælp af fuldstændig IP-protokolering eller andre midler. Over disse slags angreb behøves der ikke videre tale, når det gælder spørgsmålet om anføringsløs protokolering af fuldstændige netværksadresser. Eksempler på sådanne angreb er:

• Skadelig kode: En tilknyttet bruger får en skadelig link sendt til ham/hende. Enten bliver der for e-mail-sending brugt en zombie-computer, eller en proxy eller en infiltreret hjemmeside. Hvis hackeren er særligt dum, bruger han sin egen forbindelse til at sende e-mailet. Hvad enten: I mail-hovedet er ofte IP-adressen af afsenderen indlejret og skal ikke være separat protokollet. Uafhængig heraf kunne også modtagelsen af en e-mail kunne ses som anledning til at undersøge nærmere. Ved gehackede hjemmesider, hvor en skadelig kode er placeret, bringer IP-protokoleringen i øjeblikket af link-klikken ikke noget.
• IP-falskning: Angriber bruger tilfældigt genererede afsender-IP-adresser og metadatablad. Svar modtager angriberne ikke, de går kun ud på at skade ofrene ved bølgeagtige anmodninger. Tidligere (og også i dag?) var det muligt for angriberne at få svar til andre adresser (Backscatter-Attacke).
• Erhvervede adgangskoder: At vide adgangskoder gør en hacker til at ligne en legitim bruger. Kun ved udstående aktivitet eller dybere undersøgelser eller faktiske oplysninger fra ejeren af adgangskoden kan sådanne indsloginger opdaget blive. Ligger et indslag fra udlandet eller fra et andet apparat end det, der normalt var tilfældet, kan en sikkerhedsprøve (CAPTCHA, spørgsmål om fødselsdato osv.) indsættes. Men selv her hjælper kendskabet til fulde IP-adresse ikke videre, i det mindste ikke videre end metadatene, der desuden tillader en bredere analyse.

I en ret løs oversigt har jeg samlet nogle typer af angreb. Typerne overlapper måske (DoS er mulig fra landet eller udlandet osv.). Tabellen skal kun give et overblik og er sikkert ikke fuldstændig.

Slagtype	Anerkendelse
Tilgang til overflodighed	Jævne IP-adresse i hukommelse sammenligne.
Denial of Service	Jævne IP-adresse i hukommelse sammenligne.
Distributed Denial of Service	Kortere IP-adresser eller metadatablokke udværde.
Indførsel af skadelig kode (SQL-injektion o.l.)	Indholdstegn mod slagord og tegn til indhold.
Inlogning af hacker (erhvervet adgang)	Søg efter en konkrete IP-adresse i databasen, hvis de anmeldte brugers IP-adresser er gemt, eller direkte protokolering (årsag = login)
Angreb fra udlandet	Vurder metadata, særligt land, ASN, subnet.
Angreb fra hjemlandet	Vurder metadata, særligt ASN, subnet.
IP-falskning	Hvis muligt, prøv at tjekke afsenderadressen mod den adresse, der anses for gyldig, hvilket f.eks. kan være muligt i lokale netværk. Ggf. hjælper _Unicast RPF (er ikke mit specialfelt)

Efter at en angreb af denne art er blevet anset som erkendt eller sandsynlig, kan (må) en anledningsspecifik protokolering af IP-adresser finde sted, hvis disse er nødvendige for at forebygge farerne.

Hvis en IP-adresse bliver blokeret fordi den anses være en angreber, følger der følgende farer:

1. Adresse er i virkeligheden ikke en angriber, men blev fejlagtigt mistænkt (det ser ud til at være muligt især ved automatiske blokeringer).
2. Adresse var falsk og tilhørte enten en anden (velfungerende) forbindelse eller ingen (så ville effekten af at blokkeere være ligegyldig).
3. Adresse tilhørte en angriber, men er nu blevet tildelt en anden (gavnlig) forbindelse. Dette kan ske igen og igen ved brug af dynamiske IP-adresser, men også når man har adgang via Tor-netværket.
4. Adresse er tilknyttet flere forbindelser via Carrier Grade NAT. Alle forbindelser bortset fra én er således potentielt venlige og bliver uønsket blokeret.
5. Denne adresse repræsenterer en proxy. Når proxy-adressen er blokeret, kan ingen forbindelse oprettes via proxyen.

Som at ses, er blokering af en IP-adresse ikke nødvendigvis løsningen på alle problemer, men kan i nogle tilfælde endnu forværre dem.

Yderligere anledninger, der ikke er angreb, kan være:

• Testformål, såsom fejlfinding, forbedringer eller nye udviklinger
• Tilmeldingsforsøg med brugernavn og/eller adgangskode
• Indførsel af mærkeligt anstændende data i et formulær (her er ikke nødvendigvis skadelig kode menes)

Jeg går her ikke nærmere ind på disse begivenheder, da det her drejer sig om spørgsmålet om uanledig protokolering!

Konklusion

Det ugrundige registrering af IP-adresser til at forebygge farlige situationer synes ikke nødvendigt teknisk set. Jeg ser ingen grund til det modsatte. I stedet for fuldstændig registrering af IP-adresser kan følgende data registreres:

• IP-adresseområder (også kaldet undernetværk)
• IP-adresseblokke
• Fiktivt navn, som kun kan føres tilbage i begrænset tid og er målverdi, der efter kort tid bliver anonym
• Metadata til IP-adresser:
  • Jord
  • Leverandør
  • ASN (Autonom System Number)
  • Vært-navne
  • Reputation
• Forbindelsesmetainformationer
  • Opkaldt mål (URL osv.)
  • Absendermetadaten som f.eks. User-Agent eller cache-konfiguration
  • Tidspunkt for adgang
  • Tilgængelighed af modparten

Hvis derimod er grund til det, kan fuldstændig protokolering af IP-adressen være berettiget. Eksempler på sådanne grunde kunne være:

• Overordentligt ofte kald til en kilde
• Abnormt brug af produkter
• Ualmelige opkald (såsom usædvanlige URL-parametre eller ikke eksisterende adresser)
• Suspiske metadata (eksempel: adgang fra land X eller subnet Y)
• Flere uklare svar
• Fejltilgang (Eksempel: at protokolere egne tilgange for at finde netværksfejl)

Det kan være forskelle i vurderingen af trusselscenarier på små og store netværk samt små og store hjemmesider. At dette indebærer en relevant forskel for spørgsmålet i denne artikel, kan jeg ikke se lige nu og glæder mig over enhver tilbagekaldelse.

Tilfældigvis er det ikke en grund til at indsætte en indlægning i webserver-logfil med IP-adresse, når man sender en mening på et portal for meninger. I stedet vil man gemme meningen, muligvis sammen med senders IP-adresse, i en Database.

Fra begyndelsen havde jeg skrevet, at det kun drejer sig om egne servere, ikke om Internetserviceleverandører (ISPs). Om ISPs nødvendigvis og uden grund skal protokolere hele IP-adressen for at afværge nogle farer, tvivler jeg til videre på, selv om det kan være sandsynligt hos ISPs, at disse tvivligheder er ubegrundede. Det samme kan sikkert også gælde Content Delivery Networks (CDNs). Så længe CDNs uden grund protokolcerer hele IP-adresser, skal det kommunikeres af CDN-leverandøren. Jeg ved fra Akamai, at denne udengrundige protokolering foregår. Derfor er brugen af tjenesten Cookiebot forbudt, der bruger Akamais servere.

Den ugrundede protokolering af fuldstændige IP-adresser af servere til at forebygge farer er teknisk ikke nødvendig.

Mit vidste indtil der er bevis for det modsatte.

Hvis du er uenig, ser jeg to muligheder:

1. De kan nævne et konkret, forståeligt eksempel. I dette tilfælde undersøger jeg gerne eksemplet og ændrer min mening, hvis jeres eksempel overbeviser mig.
2. De kan ikke nævne et konkret eksempel. I dette tilfælde skal De ændre Deres mening, om De vil eller ej, fordi meningen ville være ubegrundet og uden hold.

Vær så venlig at skrive til mig, hvem du kender et konkret eksempel, der kunne være relevant for en serverejer. Jeg minder igen om, at det drejer sig om anlasslose protokolering, ikke om protokolering til en erkendt årsag! Det drejer sig heller ikke om en vurdering af nytten, men om en vurdering af nødværdigheden. Som et stikord kan her nævnes det mildeste middel. Og der er mange andre midler, som er lige så egnet til at anerkende eller afvise farer, eller endda bedre egnet til dette formål.

Det er ikke nødvendigheden der afgørende faktor, men behovet og tilgængeligheden af mildere midler.

Denne princip gælder vel i mange områder af dataskyddet.

En kort oversigt til nytteværdi:

Skandale	Brugbart?	Tilgængeligt/ Tilladt?
Undlad at udfylde skattemelding	Yes, til alle, der ikke har lyst dertil	Nej, siger loven
Bankrøveri	Yes, for dem, der penge har brug for	Nej, siger loven
Enkeltkamera-video (med permanent lagring)	Yes, senere at kunne bevise en skadeværende for en ulykke	Nej, i hvert fald ikke permanent (så vidt jeg ved)
Ud fra ingen anledning at protokolere fulde IP-adresser	Yes, sikkert for mange	Nej, påstår jeg i denne artikel

Det drejer sig ikke om at følge op på straffelovens bestemmelser, da dette ikke er en sag for en serverejer og slet ikke en sag for en server (undtagen hvis serveren tilhører en auktoriseret myndighed).

Min dialog med eksperter og min spørgsmål til flere ekspergrupper i et socialt netværk gav mig i det mindste at ingen kunne nævne et eneste eksempel, der ville modsætte min holdning. BSI (German federal security agency) kunne heller ikke give mig et konkret eksempel. I stedet modtog jeg en svar med lidt spændende informationer. Der var blandt andet nævnt, at IP-adresser er persondata og at lovgivningsgrundlag fra DS-GVO skal tages i betragtning. Alt dette var mig bekendt. Desuden blev henviselse til BSI (German federal security agency) Kompendiet gjort, hvor også ikke et eneste konkret eksempel kunne findes (jeg håber ikke noget er overlesen).

Hvis du altid opbevarer den fulde IP-adresse af brugere i dit offentlige netværk i dine serverlogge: Hør op med det straks eller nævn et specifikt eksempel på, hvordan dette er nødvendigt til at forebygge farer eller for en anden lovlig årsag

Dette krav retter sig mod almindelige serverejer, ikke mod IPS, politi eller lignende.

Nyligt havde jeg opdaget, at en kunde's FTP-server skrev et serverprotokoll med fulde IP-adresser væk. Derved stod der spørgsmål, hvilken fordel denne information overhovedet kunne have for kunden. Fordelten skulle i praksis være næsten på nul. Kunden kunne ikke på sin virtuelle server f.eks. hindre DoS-angreb, selv om han kendte IP-adressen af angriberen. Det gælder også ofte til managed servers. Bare til side, selv om det ikke ændrer noget ved den egentlige spørgsmål.

Tilfældigvis protokoleres af NDR som ansvarlig for Tagesschau-Webstedet i henhold til persondatapolitikken den fulde IP-adresse fra alle besøgende. Hvorfor det sker, bliver ikke forklaret. Sikkert vil også dataskyddsombudet for NDR ikke vide og/eller ikke fortælle dette.

I en egen artikel beskæftiger jeg mig med den maksimale tilladte lagringsdauer af webseiten-logfiler.