Protokollföring av IP-adresser i serverloggar: tillåtet eller inte?

Enligt dataskyddsinformation på många webbplatser sparas IP-adresser i serverloggfiler under lång tid, och det sker ofta med hänsyn till säkerhetsaspekter utan någon anledning. Om den oanlediga protokoleringen är tillåten beror det på om den tekniskt är nödvändig eller om det finns mildare åtgärder.

Inledning

Skiljelinje: Artikeln behandlar endast offentligt tillgängliga servrar från vanliga operatörer, alltsåINTE från ISP:er, brottsbekämpande myndigheter etc. Det handlar här särskilt inte om de fall som täcks av § 172 TKG. En rättslig grund enligt Artikel 6 DSGVO, till exempel en samtycke, antas inte finnas (annars skulle frågan snabbt besvarats).

För att undvika missförstånd: Begreppet "anledning" är grundläggande! Det förklaras i bidraget. Vorratsdataskydd kallas så, eftersom det sker utan anledning, alltså alltid!

IP-adresser är nätverksadresser. De är en del av metainformation, som överförs vid varje anrop av en webbsida. Dessa metainformation kallas ibland också för trafikdata eller anslutningsdata. Betydelsen av dessa två begrepp verkar vara olika i teknisk och juridisk kontext. Därför använder jag begreppet metainformation.

IP-adresser är enligt högsta domstolens rättspraxis från EU-domstolen och Bundesgerichtshof personuppgifter. Det gäller även för dynamiska IP-adresser, och det har varit så sedan 2016 (EU-domstolen) respektive 2017 (Bundesgerichtshof). GDPR gäller sedan slutet av maj 2018.

IP-adresser kan möjligen tillåta angrepp att identifieras och därmed eventuellt öka säkerheten för servrar. Dessutom kan genom kännedom av en IP-adress kanske en utredning äga rum. Allt detta tycks mig trovärdigt, även om det inte gäller varje möjligt angreppsscenario. Min samtalspartner, många experter inom IT-säkerhet och rätt, bekräftar detta.

IP-adresser är således nyttiga för att öka säkerheten på en server och för att spåra gärningsmän. Den Nytta är dock inte ett avgörande rättfärdigande skäl.

Frågan lyder:

Måste fullständiga IP-adresser rapporteras av serverägare utan anledning, eller finns det mildare medel?

Fråga i detta inlägg.

Denna artikel fokuserar på serverägare. Internetleverantörer (ISP) som Deutsche Telekom eller Vodafone ska här inte beaktas på grund av komplexitet.

---

Uppdatering: EU-domstolen hade till och med funnit att laglig visselkus av uppgifter för att utreda allvarliga brott var ogiltig, om de kunde användas för detta ändamål. Se EU-domstolens dom den 05.04.2022 (Målnr: C-140/20).

Självförsvarsregler som föreskriver en allmän och oavhängig lagring av trafik- och positionsdatorer för att bekämpa allvarlig brottslighet och förhindra allvarliga hot mot den allmänna säkerheten är olagliga.

Min formulering av EU-domstolens dom den 5 april 2022, nr 101.

EU-domstolen konstaterar vidare att det endast är tillåtet för att förebygga hot mot allmänheten och bekämpa allvarlig brottslighet att "för en begränsad tid på absolut nödvändigt sätt genomföra en allmän och odiskriminerande lagring av IP-adresser, som tilldelats källan till en anslutning" (punkt 101 i domen). EU-domstolen bekräftar således, enligt min förståelse, vad jag tidigare redogjort för. För det är nämligen privatserverdrift och inte alls något som har med allmänheten att göra eller med bekämpandet av allvarlig brottslighet.

---

Nu vidare i texten, utan direkt anknytning till det tidigare EU-domstolsavgörande som fattades efter att jag skrivit innehållet här.

Det handlar i min artikel om följande tre villkor som plötsligt gäller:

• ANLEDNINGEN TILL DETTA (!!!!)
• Dokumentationshantering ( = persistent lagring, exempelvis i filer )
• Hela IP-adresser

Syftet är att förhindra faror. Åklagarmyndighetens utredning gäller dig och mig inte, och heller inte din server, om du inte är polisen, åklagaren o.s.v.

Börja förstå dessa villkor innan du fortsätter läsa och tror att du kan svara på frågan i detta inlägg!

Det handlar inte om:

• Protokollföring med anknytning till ett ärende och/eller
• Endast tillfälligt i huvudminnet innehållande data och/eller
• Användning av andra data än fullständiga IP-adresser och/eller
• Efterforskning av myndigheter, polisen och åklagaren.

Har ni förstått detta? Då läs sedan vidare och kontakta mig när ni vill vara den förste som kan ge ett konkret exempel på en anledningslös protokolering av IP-adresser, som erkänner en rättslig grund.

Anledningslöst betyder att IP-adresser alltid protokolleras. Anledningsrelaterat skulle betyda att med IP-adressprotokollieringen startar först vid inträde av ett händelse, som en antagen hackattack eller vid felspaning vid nätverksproblem eller vid inloggningssökande med lösenord, börjar. Anledningen gäller först från den tidpunkt då den upptäckts eller antagits. En återvändande antagande av en anledning är otillåten. För att sedan skulle alltid protokolleras, för att senare kasta bort 99 % av data (som sedan skulle vara anledningslöst och således, som hävdats, olagligt protokolierade), bara för att använda 1 % av data för den senare upptäckta anledningen. En anledning kan också betraktas som givna när en automatik med en tillräckligt hög sannolikhet ser en anledning som föreliggande. Denna höga sannolikhet kan dock inte för varje enskild (således anledningslöst) åtkomst finnas (utom, om varje åtkomst till en server sker från en hackare). I detta inlägg handlar det inte om att diskutera sannolikhetsvärden. En permanent protokolliering av alla fall baseras på en sannolikhet av noll procent att en anledning föreligger, och är inte tillåten, hävdar jag.

En anledning är ett antaget händelseförlopp. En alltid skriftligen dokumenterad protokollering är uppenbarligen utan anledning.

Bekännelse.

En anledning kallas också på annan plats för Händelse. Se till detta IT-Grundschutz-Kompendium av BSI (German federal security agency). Där hittar man, om jag har sett rätt, ingen specifik indikation på att fullständiga IP-adresser utan anledning (d.v.s. utan Händelse) måste protokolleras. Även om detta skulle stå i BSI (German federal security agency) Kompendiet saknade det ett konkret exempel för att motivera ett berättigat intresse som rättslig grund enligt Artikel 6 DSGVO.

Jag betraktar till att besvara frågan om IP-adresser måste protokolleras utan anledning först syftet med IP-adressen vid brottsutredningar, sedan syftet med att skydda system.

Efterforskning

En server har inte uppgiften att bedriva utredning. Även en serverdriftare har inte uppgiften att bedriva utredning. Fråga en jurist om ni ser på det annorlunda.

Därmed faller syftet med brottsutredningen som ursäkta för lagring av IP-adresser utan anledning.

Efterforskning tillhör inte serverägaren eller servern, så denna grund kan inte användas som ursäkta för att logga inkommande nätverksadresser utan anledning.

Tyvärr verkar det vara så att man ibland kan tänkas vara en till hjälp för en sheriff.

Ett aktuellt exempel på en nyttig, men ändå förbjuden datahantering var utvärderingen av en kontaktuppgiftssamling i ett restaurang till coronaföljande. Polisen i Mainz sökte nämligen en vittne till en dödsfall av en gäst på restaurangen. Därför tog polisen data från Luca-appen, som restaurangägaren lagt in plichtgemäß. Polisen kontaktade sedan de restaurangbesökare som var i restaurangen vid den tidpunkten. Detta var säkert nyttigt. Men det var förbjudet. För att datainsamlingen endast skedde till syfte av hälsoskydd. Åklagaren utredde därefter mot polisen och ursäktade sig inför de rättvidigt kontaktade vittnena.

Ett annat exempel: Så kallade Kryptomobiler användes eller har använts av brottslingar för att kunna kommunicera i hemlighet. Polisen lyckades krypta kommunikationen via dessa handys. Denna typ av bevisupptagande ifrågasattes (jag tror det var på grund av att ingen domstolsbeslut fanns). Dock ansågs fundet av meddelanden i de kryptade handynas som bevis, eftersom det rörde sig om en slumpmässig hittning. Det hade annars kunnat vara så att detta användbara fynd varit olagligt och därmed inte skulle ha kunnat fungera som bevis. Kammaråklagaren i Berlin hade fundet klassificerat som slumpmässig hittning enligt § 100e Abs. 6 Nr. 1 StPO.

Brandbekämpning

Säkerheten vid behandling är föreskriven i Artikel 32 DSGVO. Enligt detta ska IT-systemen drivas på ett sätt så att risken för säkerhetsincidenter i rimligaste mån minskas. Förebyggandet av faror är dock inte bara en rättslig krav, utan bör vara det egentliga intresset hos ansvariga.

Exempel på säkerhetsincidenter

En rent illustrativ lista med exempel på vad som faller mig in under säkerhetsincident och inte bara allmänt kallas för hackattack:

• Denial of Service Attacke (DoS)
• Distributed Denial of Service Attacke (DDoS)
• Malware, Ransomware, Viren
• Inloggningssidor
• Omprogrammering av ett system till en zombie-dator

Vissa av de nämnda attacker sker genom mekanismer som sessionhäckning, phishing, spam e-post eller utnyttjande av exploits/säkerhetshål (exempel: Log4J).

Förteckningen är säkert inte komplett. Om ett viktigt scenario saknas, ber jag om meddelande (t.ex. via kommentarfältet nedan).

IP adresses

Varje internetuppkoppling bygger på en nätverkadress som också kallas IP-adress. Varje användare har en IP-adress (som tilldelas via ett enhet, såsom en router). Många gånger får privatpersoner en dynamisk IP-adress från sin leverantör. Den ändras i oregelbundna intervaller, ibland kanske också i regelbundna intervaller. Vid kabeluppkopplade internetuppkopplingar verkar den IP-adressväxlingen sällan förekomma än till exempel vid uppkopplingar via telefonledningar. När det gäller strömavbrott torde också en (oavsiktlig) växling av IP-adress ske, som jag själv kunnat konstatera. Via återställning av Fritz!Box-anslutningen kan ofta även en ny IP-adress erhållas.

Vissa leverantörer erbjuder också statiske IP-adresser. Dessa används vanligtvis mer av företagskunder än privatpersoner. Statiska IP-adresser ändrar sig inte över tid.

På grund av begränsningen i IPv4-adressernas adressutrymme kan en och samma IP-adress tilldelas flera olika anslutningar, alltså personer, under vissa omständigheter. Denna tilldelning sker tekniskt genom olika portar. En term för detta är KärntunnlatsNAT (CGN), som ungefär betyder "nätverksuppskärmning via internetleverantören".

EU-domstolen beslutade den 19 oktober 2016 (C-582/14), att IP-adresser ska betraktas som personuppgifter om det är lagligt möjligt att identifiera anslutningen i EU:s medlemsländer. I Tyskland är detta möjligt, till exempel vid brottsbekämpning. Det räcker med den objektiva möjligheten att få denna information om anslutningen under vissa omständigheter även genom att kontakta flera instanser (telekommunikationsleverantörer, säkerhetstjänster, polisen…). EU-domstolen gäller också för dynamiska IP-adresser. Den högsta domstolen i Tyskland bekräftade detta beslut den 16 maj 2017 (VI ZR 135/13).

Med hjälp av några konkreta exempel vill jag nu undersöka om en orsakslös lagring av IP-adresser kan försvaras.

Denial of Service Attacken

Vid denna typ av anfall attackerar en server med skadliga massanrop så att den kollapsar och inte längre kan utföra sin normala funktion.

Det är lätt att upptäcka om det har skett många anslutningar från samma IP-adress inom en tidsenhet. För detta hålls varje IP-adress i servers minnescache, dvs inte protokolletterad och tekniskt sett inte sparad. Om ett följdinträde sker från samma IP-adress ökar en räknare med ett. När räknaren för en IP-adress når till exempel 200 inom en minut kan man dra slutsatsen att det har skett ett skadligt intrång.

En anledning kan vara en ursäkt för att protokollera en fullständig IP-adress. Protokolseringen verkar inte tillåten vara.

Mitt nuvarande kunskapsläge.

Om sannolikheten för en skadlig attack är tillräckligt stor, är anledning till att protokolleras IP-adresser givet. Endast från och med detta ögonblick måste den IP-adressen, om alls, faktiskt protokoleras. Så kan denna ena IP-adressen för framtida inloggningar spärras.

Distributed Denial of Service Attacken

Vid denna typ av attack, även med DDoS förkortat, utförs massanfrågningar från många datorer mot en server som är offer för angreppet. I det tidigare angräpningsscenariot utfördes dessa massanfrågningar bara från en dator eller högst från några attackerande datorer.

Angripare attacker kännetecknas särskilt av att angriparföretagen försvarar olika IP-adresser. Stänger den anfallna servern bara en enda IP-adress, kommer han inte att hinna med att stänga tillräckligt snabbt. För det finns ju många attackerande system och inte bara ett som ska stängas av.

En möjlighet att identifiera spridda angripare är att vidare tolka angreppsinstruktionerna. Härav låter man till exempel bort det sista byte av en IPv4-adress (IP-adress med 4 bytes). Exempel:

• Denial of Service
  • Angränsande-IP-adress: 10.20.30.40.
  • Attack avstängd: Blockera 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
  • Angrepp blockera: Spärra IP-områdena 10.20.30.x eller till och med från åtkomster från en geografisk region, som ett land

För att upptäcka om angripare med olika nätadresser är kopplade till varandra kan ytterligare Metadata analyseras. En IP-adress har särskilt följande egenskaper, som exempelvis kan automatiskt fastställas via databaser.

• Mark. Exempel: Tyskland.
• Försäljare. Exempel: Vodafone.
• Hostadress. För vissa IP-adresser direkt tillgängliga ytterligare uppgifter. Exempel: 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 Systemnummer. Ett autonomt system är en sorts Postkontor. Från huvudpostkontoret skickas ett datapaket till det lokala postkontoret, som sedan fördelar det på plats. En leverantör har flera postkontor, alltså ASNs.
• Nätverksslutet. Flera efter varandra kommande IP-adresser. Exempel: 10.20.30.0 till 10.20.30.255, alltså 10.20.30.x eller 10.20.30.0/24.
• Fama. Förekommer ofta i form av ett värde (Score) eller som en negativ lista (Black List).

Utöver IP-adressen finns ytterligare metainformation vid tillgång till webbplatser, bland annat:

• Användaragent: Webbblädersort, Webbbläderversion, Operativsystemstyp, Operativsystemversion. Exempel: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
• Användarens Språk som är inställd i webbläsaren. Exempel: de,en-US;q=0.7,en;q=0.3
• Cachekonfiguration. Exempel: no-cache (cachen inaktiverad)
• Referent: Sida som anropet skedde via (t.ex. genom att klicka på en länk. Exempel: https://dr-dsgvo.de/
• Uppkallad URL: Sida med URL-parametrar som påkallades. Exempel: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
• Innehållsdata: Uppstår ofta ur URL-parametrar (GET) eller begäran (POST). Exempel: Användarnamn=SELECT * from users
• Tidpunkt för åtkomst: Ligger alltid tillgängligt, även vid alla andra nätverksanrop. Till slut vet mottagaren av en meddelande när han eller hon fick det.
• Status på sängen: Får sändaren svar på sina frågor eller använder han en oåtkomlig (därför falsk) sändaradress?

Dessa data kan, åtminstone i kombination, betraktas som personuppgifter och därmed personuppgifter (se Artikel 4 punkt 1 DSGVO). Om man sparade dessa data oåtkomliga och obearbetade hade man inte vunnit mycket. Det förefaller lämpligt att kryptera dessa data, om de verkar vara till nytta för hotbehandling. Krypteringen kan uppnås genom ett matematiskt förfarande.

Kryptering av personuppgifter

Ett kryptografiskt hash-verktyg kan användas för att generera värden som inte behöver vara unika. Flera olika indatavärden kan alltså avbildas på samma målvärde. Sannolikheten för detta kan hållas mycket lågt genom val av lämpliga metoder och parametrar (s.k. injektiva avbildningar eller perfekta verktyg utan kollisioner).

Ett målvärde är ett anonymt datum så länge den krypterande nyckeln är känd. Här ett exempel:

1. Användaren X använder sig av IP-adressen A1 för att komma åt en webbplats. Adressen A1 omvandlas med hjälp av nyckeln S1 till målmvärdet H1.
2. H1 kan inte återföras till A1 eftersom processen är asymmetrisk.
3. Nu åker användare X igen till webbplatsen med sin adress A1, skapas målvärdet H1 via S1 på nytt. Värdet H1 hade redan sparats i databasen. Man hittar denna värde H1 för en tidigare åtkomsttidpunkt. Därmed är det känt att användare X nu och tidigare har besökt webbplatsen. Därmed kan H1 återföras till A1.

Med zeitlich begrenzt giltiga nycklar kan en tidsbegränsad pseudonymisering med efterföljande anonymisering ske. Här är enveckade funktioner lämpliga. En enveckad funktion tillåter kryptering, men inte dekryptering. Om ett klart värde redan tidigare har kryptiserats kan det kryptiserade värdet jämföras med det tidigare kryptiserade värdet efter krypteringen. Så kan man fastställa att det krypterade värdet redan tidigare fanns. Det kryptiserade värdet kan dock inte återgå till det klara värdet utan den senaste krypterade värdet.

För riktigt korta inmatningsvärden måste med lämpliga åtgärder säkerställas att en effektiv avkryptering inte är möjlig. Särskilt får inga Rainbow-tabeller användas. Det bästa är att förfarandet är utformat så att sådana tabeller överhuvudtagit inte kan tillämpas.

Om nyckeln S1 bara gäller i 24 timmar och sedan glöms bort kan alla mål som genererats med denna nyckel inte längre avkrypteras. Därmed ligger anonymiserade data framför oss efter 24 timmar, och inte längre pseudonymiserade data. Detta skulle också ge ett skydd mot Rainbow-tabeller, åtminstone efter att nyckeln har gått ut.

Förhindrande av faror genom metadata eller pseudonymisering

Frågan var ju om man bara kan avvärja DDoS-attackerna genom att protokolliera IP-adresser utan anledning. Jag påstår att för att avvärja DDoS-attackerna är känslan av IP-adresserna inte nödvändig.

Om det inte är optimalt enligt dataskyddslagen skulle IP-adresser i form av ett pseudonymiserat datum protokolleras med ett Krypteringsförfaranden som kanske inte utgör en enkelriktad funktion. En DDoS-attack kännetecknas sannolikt av att angriparna snabbt efter varandra utför attacker. Ett tidshängande nyckel ger således möjlighet till pseudonymisering, som utan anledning kan användas. Detta förfarande skulle inte vara sämre än att använda fullständiga IP-adresser i realtid. Men vid retrospektiv betraktelse skulle det vara sämre. En retrospektiv betraktelse är ofta värdefull för att analysera attacker.

Faror kan effektivare avvärjas om krypterade IP-adresser eller metadata till IP-adresser sparas. Vilka metadata detta kan vara nödvändigt med har jag beskrivit ovan.

Vid DoS- eller DDoS-attacken kan angriparen lätt fälska sin sändaradress (IP-adress). För att de inte behöver få någon respons på deras skadliga begäran. Angriparen skulle alltså Skiftande IP-adresser kunna använda sig av. Om man sparade fullständiga IP-adresser hade man här ingenting vunnit, åtminstone inte i realtid.

Få anrop: Angripare som bara en gång eller ett fåtal gånger tillgriper ett offer-system kan antingen inte upptäckas alls eller endast i samband med ett specifikt fall. Ett inloggning (Inloggning) med stulna användardata kan i samband med ett specifikt fall förses med ett IP-protokoll. Att utnyttja en säkerhetslucka, som vid Log4J, genom bara ett anrop kan inte förhindras eller upptäckas ad hoc med hjälp av ett IP-protokoll. Så dumt det än är, men lagringen av IP-adressen utan samband till en möjlig gärningsman är inte tillåten. Dashcams i bilar, som filmar permanent och utan anledning, är lika oacceptabelt. Tyvärr, men så är det också om detta innebär att den ene eller den andre skyldige tyvärr inte kan upptäckas. Om en angripare skriver in ett skadeprogram i ett formulär fält för att stjäla data kan detta kanske upptäckas genom utvärdering av de inmatade datorna. Till exempel kan SQL-injektioner upptäckas på detta sätt. Dessutom kan skadeprogrammen göra sig obrukbara om servern har en motsvarande programmering. Det är lättare sagt än gjort, som man såg vid den bredt spridda hjälphelten Log4J, som tillät effektiva hackangrepp utan större ansträngning. Men även en fullständig protokoliserad IP-adress hjälper inte att upptäcka angreppet bättre än det skulle vara möjligt annars (som jag påstår).

Angräffarna använder tillfälligt stabila IP-adresser, hjälper metadata från IP-adresserna i realtid att upptäcka attacker. Dessutom är det med hjälp av metadata mycket lättare att göra en återvändande automatisk eller manuell utvärdering än om bara den fullständiga IP-adressen sparades och metadata för en attackanalys skulle hämtas. Första gången är alltid första gången. Det innebär: Vid första angreppet, som analyseras efteråt, måste offret svärtigt hitta metadata för de protokoliserade fullständiga IP-adresserna. Utom om metadata direkt protokoliserades, bäst utan fullständig IP-adress. En fullständig protokolering av IP-adresser utan metadata har alltså tydliga tekniska nackdelar.

En attack som alltid ringer till samma URL kan lätt upptäckas. Om en sida anropas mycket oftare än vad som är normalt, kunde det härleda till ett anledning för att protokolleringen av IP-adresser ska ske. En protokolering utan anledning skulle då inte vara nödvändig för hotbehandling.

DDoS-attackerna som kan hänföras till ett visst land förekommer vanligtvis inte från Tyskland. I Tyskland har vi bra möjligheter att följa rättsliga procedurer. Å andra sidan kunde Zombie-datorer användas för en attack från inlandsenheten. Tyska webbplatser skulle i alla fall kunna identifiera och blockera anrop från utlandet som kan betraktas som attacker. Detta skulle gå utan att veta fullständiga IP-adresser (se ovan: ASN, land, leverantör). För zombie-attackerna skulle en analys av anropen hjälpa till ytterligare (mål-URLs, parametrar, frekvens, User-Agent…).

Vissa attacker kunde inte hindras med full IP-protokollering eller andra metoder. Därför behöver man inte prata om dessa slags attacker när det gäller frågan om anledningslös protokolliering av fullständiga nätadresser. Exempel på sådana attacker är:

• Skadlig kod: En inloggad användare får ett skadligt länk skickat till sig. Antingen använder en "zombie"-dator för att skickas e-post eller en proxy eller en infiltrerad webbplats. Om hackern är extra dum använder han sin egen anslutning för att skicka e-post. Hur som helst: I mejl-huvudet är ofta IP-adressen av sändaren inbyggd och måste inte ges separat protokollfört. Oavsett detta kunde även mottagandet av ett mejl ses som en anledning. När webbplatser hackats och skadlig kod placerats på dem, ger IP-protokolliering vid länk-klickningen ingenting i nuläget.
• IP-Spoofing: Angripare använder slumpmässigt genererade avsändar-IP-adresser och metainformation. Svaret får angriparen inte, de är bara intresserade av att skada offret genom onda anmodan. Förr (idag också?) var det möjligt för angripare att få svar för andra adresser (Backscatter-Attacke).
• Hämtade inloggningsuppgifter: Kännedomen av inloggningsuppgifter gör en hackare till att likna sig på en legitim användare. Högst genom uppenbara aktiviteter eller djupare undersökningar eller rentav tips från den egentlige ägaren av inloggningsuppgifter kan sådana intrång upptäckas. Ligger ett intrång från utlandet eller från en annan dator än det som tidigare var vanligt, kan anlednadsvis en säkerhetskontroll (CAPTCHA, fråga efter födelsedatum etc.) införas. Men även här hjälper känslan av den fullständiga IP-adressen inte vidare, i alla fall inte vidare än de metadatana som dessutom tillåter en bredare analys.

I en ganska löst översikt har jag samlat ihop några typer av attacker. Typerna kan överlappa (DoS är möjlig från in- eller utland etc.). Tabellen ska bara ge en överblick och är säkert inte komplett.

Typ av attack	Kännedom
Överdriven tillgång	Jämför konkret IP-adress i minnet.
Denial of Service	Jämför konkret IP-adress i minnet.
Distributed Denial of Service	Analysera kortade IP-adresser eller metainformation.
Inmatning av skadlig kod (SQL-injektion etc.)	Innehållsdata mot Nyckelord och tecken för skattning.
Inlogning genom hackare (överraskad åtkomst)	Sök efter en konkret IP-adress i databasen när anmälde användares IP-adresser lagras, eller direkt protokollering (orsak = inloggning)
Angrepp från utlandet	Utvinna metadata, särskilt land, ASN och undernät.
Invasion från inhemskt territorium	Utvinna metadata, särskilt ASN, undernät.
IP-Spoofing	Om möjligt, kontrollera avsändaradressen mot den som anses vara giltig adressruta, vilket till exempel kan fungera bra i lokala nätverk. Ggf. hjälper _Unicast RPF (inte mitt specialområde)

Efter att en attack har blivit upptäckt eller bedömts vara sannolik kan (får) en anpassad protokolering av IP-adresser ske, om det är nödvändigt för hotbekämpning.

Om en IP-adress blockeras på grund av att den betraktas som ett attackerande IP-adress, finns följande risker:

1. Den här adressen är faktiskt inte en angripare, utan har blivit felaktigt misstänkt (detta kan särskilt ske vid automatiska blockeringar).
2. Adressen var falsk och tillhörde antingen en annan (icke-skadlig) anslutning eller ingenting alls (då skulle effekten av ett blockering vara noll).
3. Den här adressen tillhörde en angripare, men har nu tilldelats en annan (gottartad) anslutning. Detta kan hända vid dynamiska IP-adresser och även när man använder Tor-nätverket för att komma in på webben.
4. Adressen är tilldelad Carrier Grade NAT flera anslutningar. Alla anslutningar utom en är således potentiellt godartade och blir oavsiktligt blockerade.
5. Den här adressen representerar en proxy. Om den proxyadressen är blockerad kan ingen anslutning mer upprätta en anslutning via den proxy.

Som att synas är blockering av en IP-adress inte nödvändigtvis lösningen på alla problem, utan kan i vissa fall till och med förvärra dem.

Ytterligare anledningar som inte är attacker kan vara:

• Teständamål, som till exempel felhantering, förbättringar eller nyutveckling
• Inlogningsförsök med användarnamn och/eller lösenord
• Inmatning av märkliga uppgifter i ett formulär (här är inte nödvändigtvis skadlig kod menade)

Jag går inte in på dessa tillfällen här, eftersom det handlar om frågan om ogrundade protokollföringar här!

Sammandrag

Protokollierandet av IP-adresser för att förebygga faror synes inte vara tekniskt nödvändigt. Jag ser inget skäl till motsatsen. I stället kan följande data protokolleras:

• IP-adressområden (dvs. undernätverk)
• IP-adressblock
• Fiktivt namn, som endast är tillfälligt återgående mål, som efter en kort tid blir anonyma
• Information om metainformation till IP-adresser:
  • Mark
  • Försörjare
  • ASN
  • Värdnamn
  • Fama
• Metainformationer till anslutningen
  • Uppmanat mål (URL osv.)
  • Upphovsmannsdata som användaragent eller cachekonfiguration
  • Tidpunkt för åtkomst
  • Tillgängligheten för motsvarande delen

Om det finns ett skäl kan fullständig protokollering av IP-adressen vara motiverad. Exempel på sådana skäl kunde vara:

• Överdriven frekvens av anrop från en källa
• Ovanligt användarbeteende
• Ovanliga anrop (t.ex. ovanliga URL-parametrar eller icke existerande adresser)
• Misstänkta metainformationer (exempel: anrop från landet X eller från undernätet Y)
• Flertalet felaktiga svar
• Felspaning (exempel: dokumentera egna åtkomster för att hitta nätverksfel)

Det kan ge skillnader i bedömningen av hotscenarierna för små och stora nätverk respektive små och stora webbplatser. Att detta skulle leda till en relevant skillnad för frågeställningen i denna artikel ser jag inte just nu, men jag är glad över varje återkoppling.

För övrigt är det inte skäl nog att lägga till en inlägg i webbserverns logfil med IP-adress för att skicka ut en åsikt på ett opinionsforum. Istället kommer man att spara åsikten, eventuellt tillsammans med sändarens IP-adress, i en Databas.

I första hand hade jag skrivit att det bara gällde egna servrar, inte Internettillgängsägare (ISPs). Om ISPs måste protokollerar fullständig IP-adress för att skydda mot vissa faror utan anledning, tvivlar jag på det till vidare ordning, även om det kan vara så att ISPs redan har skäl att tvivla. Samma sak gäller Content Delivery Networks (CDNs). Om CDNs protokollerar fullständiga IP-adresser utan anledning måste CDN-leverantören kommunicera detta. Jag vet från Akamai att de protokollerar fullständiga IP-adresser utan anledning. Därför har jag förbjudit användningen av tjänsten Cookiebot, som använder Akamai-servrar.

Den orsaksfria protokoleringen av fullständiga IP-adresser av serverägare för att förebygga faror är tekniskt inte nödvändig.

Min kunskapsnivå till dess beviset för motsatsen.

Om du har en annan åsikt, ser jag två möjligheter:

1. Ni kan ge ett konkret och begripligt exempel. I så fall undersöker jag exemplet gärna och ändrar min uppfattning om ert exempel styrker er argument.
2. Ni kan inte ge ett konkret exempel. I så fall bör ni ändra er uppfattning, om ni vill eller ej, eftersom uppfattningen skulle vara obefogad och ohållbar.

Vänligen skriv till mig vem du känner till ett konkret exempel som skulle kunna vara relevant för en serveradministratör. Jag påminner er åter om att det handlar om anlasslos protokolsskrivning, inte om protokolsskrivning vid upptäckt av anledning! Det handlar inte heller om nytta, utan om nödvändighet. Som ett nyckelord kan nämnas miljest mittel. Och det finns många andra medel som är lika lämpliga som IP-adresser, eller till och med bättre anpassade för att upptäcka eller avvärja faror.

Det som är avgörande inte är nyttan, utan behovet och tillgängligheten av mildare medel.

Denna princip gäller väl i många områden av dataskyddet.

En kort sammanfattning av nyttan:

Händelse	Nyttig?	Behövs/Är tillåtet?
Upphörd med att lämna in skattedeklaration	Yes, för alla som inte har lust till det	Yes, säger lagen
Bankrån	Yes, för den som behöver pengar	Yes, säger lagen
Körlekskamerafilm (med lagringsfunktion)	Yes, senare kunna bevisa att en olycksbekant var skyldig	Nej, i alla fall inte pågående (såvitt jag vet)
Omotiverad fullständig IP-adressprotokollering	Yes, säkert för många	Nej, hävdar jag i detta inlägg

Det handlar inte heller om att utreda brott, eftersom detta inte är något som en serverägare ska ta sig an och än mindre något som en server själv ska göra (utom om servern tillhör en auktoriserad myndighet för brottsutredning).

Min samtal med experter och min fråga till flera grupper av experter i ett socialt nätverk gav mig i alla fall inget exempel som kunde motbevisa min uppfattning. Även BSI (German federal security agency) kunde inte ge mig något konkret exempel. I stället fick jag en svar med lite spännande informationer. Där nämndes att IP-adresser är personuppgifter och att man måste följa rättsliga grunder från DS-GVO. Detta var allt redan känt för mig. Dessutom hänvisades till BSI (German federal security agency):s kompendium, men där fanns inte ett enda konkret exempel (jag hoppas att jag inte missat något).

Om ni alltid sparar den fullständiga IP-adressen från användare på era publikt tillgängliga nätverk i era serverloggar: Håll upp med det omedelbart eller ge ett specifikt exempel på hur detta skulle kunna skydda mot faror eller vara till någon annan giltig anledning

Denna begäran riktar sig till vanliga serverdriftare och inte till IPS, åklagarmyndigheter etc.

Nyligen hade jag upptäckt att på en kunds FTP-server skrevs ett serverprotokoll med fullständiga IP-adresser ut. Därifrån uppstod frågan, vilken nytta denna information överhuvudtaget kunde ha för kunden. Nyttan borde i praktiken gå nära mot noll. Kunden kunde till exempel inte på sitt virtuella server ingripa mot DoS-angrepp, även om han kände till IP-adresserna av angriparen. Samma gäller ofta för managed servers. Detta bara till sidan, även om det inte ändrar på den egentliga frågeställningen.

För övrigt protokollerar NDR som ansvarig för Tagesschau-webbplatsen enligt dataskyddsinformationen den fullständiga IP-adressen från alla besökare. Varför det händer förklaras inte. Säkert vet och/eller berättar inte heller NDR:s dataskyddsuppgivare om detta.

I en egen artikel ägnar jag mig åt den maximalt tillåtna lagringsduren av webbplats-loggfiler.