Protokowanie adresów IP w logach serwerowych: dozwolone czy nie?

Zgodnie z informacjami o ochronie danych osobowych na wielu stronach internetowych adresy IP są przechowywane w plikach logów serwerowych w pełnej długości, a to często rzekomo ze względów bezpieczeństwa i bez jakiegokolwiek powodu. Czy protokół niezwiązany z żadnym powodem jest dopuszczalny, zależy od tego, czy jest technicznie konieczny lub czy istnieją łatwiejsze sposoby.

Wprowadzenie

Ograniczenie: Artykuł dotyczy tylko publicznie dostępnych serwerów, zarządzanych przez zwykłych administratorów, a nie przez ISP, służby śledcze itp. Nie chodzi tu o przypadki objęte § 172 TKG. Założono, że nie ma podstaw prawnych na podstawie Art. 6 DSGVO, np. zgody, (w przeciwnym razie pytanie byłoby szybko rozwiązane).

Aby unikać nieporozumień: Zrozumienie pojęcia "przyczyna" jest fundamentalne! Jest on wyjaśniony w artykule. Magazynowanie danych przedawnionych nazywa się tak, ponieważ odbywa się bez przyczyny, czyli zawsze!

Adresy IP są adresami sieciowymi. Są częścią metadanych, które są przesyłane przy każdym wezwaniu strony internetowej. Te metadane są czasem nazywane również danymi ruchu lub danymi połączenia. Znaczenie tych dwóch terminów wydaje się być różne w kontekście technicznym i prawnym. Dlatego użyję terminu metadanych.

Adresy IP są zgodnie z orzeczeniem najwyższego trybu sądowego EuGH i BGH dane osobowe. Zastosowanie ma się również do adresów IP dynamicznych, a to już od roku 2016 (EuGH) i 2017 (BGH). Rozporządzenie o ochronie danych osobowych obowiązuje od końca maja 2018 r.

Adresy IP pozwalają być może na rozpoznanie ataków i tym samym zwiększenie bezpieczeństwa serwerów. Ponadto, poprzez wiedzę o adresem IP możliwa jest ściganie sprawcy. Wszystko to wydaje mi się logiczne, chociaż nie dla każdego scenariusza ataku. Mój rozmówca, liczni eksperci z dziedziny bezpieczeństwa IT i prawa, potwierdzają to.

Adresy IP są więc przydatne do zwiększenia bezpieczeństwa serwera i do ustalenia sprawcy. Niezbywalność jest jednak niezmiennym powodem uzasadnienia.

Czy jest pytanie:

Czy pełne adresy IP muszą być bez powodu rejestrowane przez operatorów własnych serwerów, czy istnieją łagodniejsze środki?
Pytanie tego wpisu.

Ten wpis skupia się na operatorach serwerów. Usługi Internetowe (ISP) takie jak Deutsche Telekom czy Vodafone nie powinny być tu uwzględniane z powodów skomplikowania.

Aktualizacja: Europejski Trybunał Sprawiedliwości uznał nawet za niezgodne z prawem przechowywanie danych bez podstawienia, jeśli mogłyby być wykorzystane do rozwiązania ciężkich przestępstw. Zobacz orzeczenie Trybunału Sprawiedliwości Unii Europejskiej z dnia 05.04.2022 (nr sprawy C-140/20).

Samowolne przepisy prawne, które w celu zapobiegania ciężkim zbrodniom i zapobieganiu ciężkim zagrożeniom dla bezpieczeństwa publicznego przewidują ogólną i niezróżnicowaną przechowywanie zasobów danych dotyczących ruchu i lokalizacji, są nielegalne.
Moje sformułowanie wyroku Trybunału Sprawiedliwości Unii Europejskiej z dnia 05.04.2022, nr Rzeczoznawców 101.

Sąd Najwyższy Unii Europejskiej stwierdza ponadto, że dopuszczalne jest tylko przechowywanie wpisów IP dla zapobieżenia zagrożeniu bezpieczeństwa publicznego i zwalczaniu poważnych przestępstw (pkt 101 wyroku). Sąd Najwyższy potwierdza tym samym, co wcześniej miałem już dość wcześnie napisane. Bo prywatni operatorzy serwerów internetowych mają z bezpieczeństwem publicznym i zwalczaniem poważnych przestępstw mało lub nic wspólnego.

Dalej w tekście, bez bezpośredniego odniesienia do powyższego wyroku Trybunału Sprawiedliwości Unii Europejskiej, który został wydany dopiero po moim tekście.

W moim wpisie chodzi o następujące trzy warunki, które nagle się spełniają:

NIE WYŁĄCZAJ ZASŁONIĘ
DOKUMENTOWANIE (= trwała przechowywanie, np. w plikach)
PEłne adresy IP

Cel jest ochrona przed niebezpieczeństwem. Śledztwo karnie nie ma z tym nic wspólnego i nie dotyczy również Waszego serwera, chyba że jesteście policją, prokuraturą itp.

Proszę wewnętrznie przyjąć te warunki przed dalszym czytaniem i uważaj, że możesz odpowiedzieć na pytanie tego wpisu!

Nie chodzi o nic:

Protokolarne zapisywanie związane z określonymi sprawami i/lub
Tylko przejściowo przechowywane w pamięci operacyjnej dane i/lub
Użycie innych danych niż pełne adresy IP i/lub
Ściganie przez władze, policję, prokuraturę.

Czy to wam się przydarzyło? Jeśli tak, proszę przeczytaj dalej i zrób mi ten zaszczyt, by być pierwszym, kto może podać konkretne przykłady protokołowania adresów IP bez powodu, które uznają za prawny.

Bezprzyczynowy oznacza, że adresy IP są zawsze protokolowane. Anlassbezogen oznaczałoby, że protokolowanie adresów IP rozpoczyna się dopiero przy wejściu pewnego zdarzenia, takiego jak podejrzany atak hakera lub poszukiwania błędów w przypadku problemów sieciowych lub próby logowania się za pomocą hasła. Zdarzenie uważa się za występujące od momentu jego ustalenia lub przyjęcia. Nie jest dopuszczalne podejmowanie decyzji o zdarzeniu z perspektywy wstecznej. Wtedy musiałoby być zawsze protokolowane, aby później 99% danych zostało wyświetlonych (co następnie uważano za anlasslos i tym samym, jak twierdzono, nielegalne), tylko po to, by móc użyć 1% danych dla zdarzenia ustalonego później. Zdarzenie może być również uznane za występujące, jeśli automatyzm uznałby go za istniejący z wystarczającej wysokości prawdopodobieństwa. Tak duże prawdopodobieństwo nie mogłoby jednak dotyczyć każdego przypadku (poza tym, że każdy dostęp do serwera byłby od hakera). W tym wpisie nie chodzi o dyskusję na temat wartości prawdopodobieństwa. Długotrwałe protokolowanie w każdym razie opierałoby się na prawdopodobieństwie zerowym, że zdarzenie występuje, i nie byłoby dopuszczalne, twierdzę.

Przyczyną jest przyjęte zdarzenie. Zawsze odbywająca się protokół jest oczywistym brakiem przyczyny.
Oświadczenie.

Powyższy powód jest również nazywany zdarzeniem w innych miejscach. Zobacz tutaj IT-Grundschutz-Kompendium BSI (German federal security agency). Tam, jeśli to prawda, nie ma konkretnego odniesienia do tego, że pełne adresy IP muszą być protokolowane bez zdarzenia (tj. bez powodu), nawet jeśli istnieje taki wskazówka w Kompendium BSI (German federal security agency). Nawet gdyby ta wskazówka była dostępna w Kompendium BSI (German federal security agency), brakowałoby konkretnego przykładu na uzasadnienie uprawnionego interesu jako podstawy prawnej zgodnie z Art. 6 DSGVO.

Rozważam cel adresów IP w sprawie ścigania prawa i następnie ich ochrony systemu.

Ściganie się z prawną odpowiedzialnością

Serwer nie ma na celu prowadzenia śledztwa. Nie ma również dla operatora serwera na celu prowadzenia śledztwa. Zadajcie prawnikowi, jeśli widzicie to inaczej.

Zatem cel ścigania przestępców nie jest uzasadnieniem dla bezprzyczynowej przechowywania adresów IP.

Ściganie przestępców nie dotyczy ani administratora serwera, ani samego serwera. Zatem ten powód wyklucza się jako uzasadnienie dla bezprzyczynowej rejestracji adresów sieciowych.
Niestety zdaje się być tak, że czasem może być sensownym pomysłem być pomocnym policjantem.

Przykładem aktualnie używanej, ale wciąż zabronionej przetwarzania danych jest ocena zebranych danych z kontaktnego formularza w restauracji pod kątem śledzenia koronawirusa. Policja z Mainz szukała świadka w sprawie śmierci gościa restauracji. Policja pobierała dane z aplikacji Luca, które zostały przez właściciela restauracji wpisane zgodnie z obowiązkiem. Następnie policja skontaktowała się z klientami restauracji, którzy byli w niej podczas sprawy. To było pewnie przydatne. Ale to było zabronione. Bo dane zostały zebrane jedynie dla celów ochrony zdrowia. Prokurator prowadził postępowanie przeciwko policji i wyrażał swoje przeprosiny wobec świadków, którzy nielegalnie zostali skontaktowani.

Przykład: Sogenannte Telefony kryptograficzne były lub są używane przez przestępców, aby się ukrywać. Policja udało się zdekodować komunikację na tych telefonach. Ten rodzaj zebrania dowodów został poddany wątpliwości (myślę, że dlatego, że nie było orzeczenia sądu). Jednakże, ze względu na fakt, że był to przypadkowy znaleziony, fundusz wiadomości w telefonach zdekodowanych został uznany za dowód. Inaczej mogło być tak, że ten przydatny znaleziony byłby nielegalnie i tym samym nie mógłby być użyty jako dowód. Sąd Apelacyjny w Berlinie sklasyfikował fundusz jako przypadkowy znaleziony zgodnie z § 100e ust. 6 pkt 1 Kodeksu Postępowania Karnego.

Ochrona przed niebezpieczeństwem

Bezpieczeństwo przetwarzania jest wymagane w Art. 32 DSGVO. Zgodnie z tym, systemy IT powinny być prowadzone tak, aby ryzyko incydentów bezpieczeństwa było w odpowiedniej mierze zmniejszone. Ochrona przed niebezpieczeństwami jest jednak nie tylko wymogiem prawnym, ale również powinnem własnego interesu osób odpowiedzialnych.

Przykłady incydentów bezpieczeństwa

Lista ilustracyjna z przykładami tego, co uważam za incydent bezpieczeństwa i nie tylko ogólnikowo nazywając go atakiem hakerskim:

Denial of Service Attacke (DoS)
Distributed Denial of Service Attacke (DDoS)
Malware, Ransomware, Viren
Dziedzictwo zalogowań do systemu
Przerobienie systemu na komputer zombie

Niektóre z wymienionych ataków odbywają się za pomocą mechanizmów takich jak przejęcie sesji, phishing, spamowanie lub wykorzystanie eksploitu/braków w bezpieczeństwie (np. Log4J).

Lista nie jest kompletna. Jeśli brakuje istotnego scenariusza, proszę o informację (np. przez pole komentarzy poniżej).

IP adresses

Każdy dostęp do Internetu opiera się na adresie sieciowej, która nazywana jest również adresem IP. Każdy użytkownik ma swój adres IP (przypisany przez urządzenie, takie jak router). Często osoby prywatne otrzymują adres IP dynamiczny od dostawcy. Ten zmienia się w niespodziewanych odstępach czasu, a nawet regularnie. W przypadku dostępu kablowego zmiana adresu IP jest mniej powszechna niż przy dostępie przez linie telefoniczne. Podczas awarii prądu prawdopodobnie nastąpi również (niespodziewany) przypadek zmiany adresu IP, tak jak to się stało z moim własnym doświadczeniem. Przez reset połączenia Fritz!Box można często uzyskać nowy adres IP.

Niektórzy dostawcy oferują również stacjonarne adresy IP. Te są zwykle używane przez klientów biznesowych i mniej przez osoby prywatne. Adresy IP stacjonarne nie zmieniają się w czasie.

W związku ze skromnym zakresem adresów IPv4, podczas gdy może dojść do przydziału tej samej IP-Adresy na kilka różnych połączeń (dla różnych osób), to ta procedura jest technicznie realizowana poprzez różne porty. Pojęcie tego rodzaju to NAT o jakości operatora (CGN), co można tłumaczyć jako "sieciowy klucz dostępu" za pośrednictwem dostawcy usług internetowych.

Sąd Najwyższy Unii Europejskiej orzekał w dniu 19.10.2016 (C-582/14), że adresy IP należy traktować jako dane osobowe, jeśli możliwa jest identyfikacja użytkownika połączenia na terenie jednego z krajów Unii Europejskiej. W Niemczech to możliwe np. w celach śledczych. Wystarczy, że istnieje obiektywnie możliwość uzyskania tej informacji o połączeniu, nawet przy pomocy kilku instytucji (operatorów telekomunikacyjnych, służb specjalnych, policji…). Sąd Najwyższy Unii Europejskiej orzekał również w odniesieniu do adresów IP dynamicznych. Sąd Najwyższy Republiki Federalnej Niemiec potwierdził to orzeczenie w dniu 16.05.2017 (VI ZR 135/13).

Przykładach konkretnych chcę teraz sprawdzić, czy magazynowanie adresów IP bez powodu może być uzasadnione.

Denial of Service Attacken

Podczas tego rodzaju ataku serwer jest bombardowany złośliwymi masowymi zapytaniami, co powoduje jego zawalenie się i niezdolność do normalnego działania.

Latwo jest ustalić, czy z tej samej adresu IP nastąpiły liczne dostępy w jednej sekundzie. Dla tego celu każda adresa IP przechowywana jest w pamięci głównej serwera, nie jest protokołowana i nie jest technicznie zapisywana. Jeśli następuje kolejny dostęp z tej samej adresu IP, to licznik jest o 1 zwiększany. Gdy np. w ciągu jednej minuty wartość licznika dla danej adresem IP wynosi 200, można przypuszczać, że nastąpił atak szkodliwy.

Powód może być uzasadnieniem dla protokołowania pełnej adresu IP. Nie wydaje się, że protokół jest dopuszczalny bez powodu.
Mój bieżący stan wiedzy.

Jeśli prawdopodobieństwo ataku szkodliwego jest wystarczająco duże, istnieje powód do protokołowania adresów IP. Dopiero wtedy, gdy nastąpi to, musi być zapisana rzeczywiście adresem IP, jeśli zostanie ono zapisany. Tak można zablokować tę jedną adres IP na przyszłe logowanie.

Distributed Denial of Service Attacken

Podczas takiego rodzaju ataku, również skróconego jako DDoS, masowe zapytania od wielu komputerów są kierowane na serwer ofiary. W poprzednim scenariuszu ataku te masowe zapytania były prowadzone tylko z jednego komputera lub maksymalnie z kilku komputerów atakujących.

Ataki odbywają się przede wszystkim tym, że komputery atakujące mają różne adresy IP. Jeśli serwer napadany blokuje tylko pojedyncze adresem IP, nie będzie w stanie zablokować go szybko. Bo istnieją wiele systemów ataku i nie tylko jeden, który trzeba wyłączyć.

Jedną z możliwości rozpoznania ataków odległych jest szersze interpretowanie adresów atakujących. W tym celu można np. pozostawić ostatni bajt IPv4 (adres IP o długości 4 bajtów). Przykład:

Denial of Service
- Adres IP atakującego: 10.20.30.40.
- Zakładanie ataku: Blokowanie adresu 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
- Zakładanie ataku: Zablokowanie obszarów IP 10.20.30.x lub nawet dostępu z określonej geograficznie regionu, np. kraju

Aby stwierdzić, czy atakujący posługują się różnymi adresami sieciowymi, można dalsze metadane przeanalizować. Adres IP posiada w szczególności następujące cechy, które np. automatycznie mogą być ustalone za pomocą baz danych.

Ziemia. Przykład: Niemcy.
Dostawca. Przykład: Vodafone.
Adres hosta. Dla niektórych adresów IP dostępne są dodatkowe informacje. Przykłady: 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
ASNR (Agencja ds. Nadzoru): Numer Systemu Autonomicznego. System autonomiczny jest rodzajem Poczty. Z głównego biura pocztowego pakiet danych jest wysyłany do lokalnego biura pocztowego, które go następnie rozdaje na miejscu. Dostawca utrzymuje kilka biur pocztowych, czyli ASN.
Podsieć. Wiele następujących po sobie adresów IP. Przykład: 10.20.30.0 do 10.20.30.255, czyli 10.20.30.x lub 10.20.30.0/24.
Reputacja. Często prowadzona w formie wartości (Punkty ) lub jako negatywna lista (Czarna Lista ).

Dodatkowo do adresu IP istnieją jeszcze inne dane metadanych, które pojawiają się przy dostępie do stron internetowych. Są m.in.:

User-Agent: Browsertyp, Browser-Version, Betriebssystemtyp, Betriebssystemversion. Beispiel: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
W przeglądarce ustawiona Język użytkownika. Przykład: de,en-US;q=0,7,en;q=0,3
Konfiguracja pamięci podręcznej. Przykład: no-cache (pamięć podręczna wyłączona)
Przypis: Strona, z której nastąpił wezwany (np. po kliknięciu w link. Przykład: https://dr-dsgvo.de/
Zwrócona URL: Strona wraz z parametrem URL, która została wywołana. Przykład: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
Dane zawartości: Często wynikają z parametru URL (GET) lub zapytania (POST). Przykład: Username=SELECT * from users
Czas dostępu: Zawsze is dostępny, również przy wszystkich innych zapytaniach o sieć. Po prostu odbiorcy wiadomości wiedzą kiedy ją otrzymali.
Stan położenia: Czy odbiorca odpowiada na jego zapytania lub używa nieosiągalnej (bo fałszywej) adresu nadawcy?

Te dane można, co najmniej w połączeniu z innymi danymi, uznać za dane osobowe i tym samym dane osobowe (por. Art. 4 pkt 1 Dz.U. z 2018 r. poz. 1000). Jeśli te dane byłyby przechowywane niezaszyfrowany i niewycięte, to nie byłoby to duży sukces. Może się okazać, że te dane, jeśli są przydatne do zapobiegania zagrożeniom, powinny być zaszyfrowane. Zaszyfrowanie może zostać osiągnięte za pomocą matematycznego procesu.

Szyfrowanie danych dotyczących osób fizycznych

Zabezpieczenie danych odbywa się w taki sposób, że wartość danych jest połączona z wybranym, odpowiednim kluczem. Wynikiem jest wartość docelowa. Z kryptograficzną procedurą haszującą można również generować wartości, które nie muszą być jedynie. Wielokrotnie różne dane wejściowe mogłyby być przypisane do tej samej wartości docelowej. Prawdopodobieństwo tego może być utrzymane na bardzo niskim poziomie lub w praktyce wykluczone (zwane mapowaniem iniekcyjnym, czyli idealną procedurą bez kolizji).

Celem jest fikcyjna data, tak długo jak wartość klucza jest znana. Przykładem może być następujące:

Użytkownik X dostępuje do strony internetowej przy pomocy adresu IP A1. Adres A1 jest przekształcany za pomocą klucza S1 w wartość docelową H1.
H1 nie może być odwinięte do A1, ponieważ procedura jest asymetryczna.
Teraz użytkownik X odwiedza ponownie stronę za pomocą adresu A1, powstaje znów wartość docelowa H1. Wartość H1 była już jednak zapisana w bazie danych. Znajduje się więc ten sam wynik dla wcześniejszego momentu wejścia na stronę. Zatem jest znany fakt, że użytkownik X odwiedził stronę zarówno teraz, jak i w przeszłości. Zatem H1 może być odwrócony do A1.

Za pomocą czasowo ograniczonego klucza można przeprowadzić czasową pseudonimizację z następną anonymizacją. Do tego celu są odpowiednie funkcje jednorazowego użycia. Funkcja jednorazowego użycia pozwala na szyfrowanie, ale nie odszyfrowywanie. Jeśli istnieje wartość jasnoscowa przedtem już zaszyfrowana, można porównać wartość jasnoscową po zaszyfrowaniu z wartością jasnoscową przedtem już zaszyfrowaną. W ten sposób można ustalić, że wartość jasnoscowa istniała przedtem. Zaszyfrowany wynik może być jednak nieodwracalny bez ponownego występowania wartości jasnoscowej.

Dla bardzo krótkich danych wejściowych należy podjąć odpowiednie działania, aby zapobiec efektywnej deszyfrowaniu. W szczególności nie wolno używać tabel Rainbow. Najlepiej jest tak zaprojektować procedurę, aby takie tabele były zupełnie niezastosowalne.

Jeśli klucz S1 jest ważny tylko przez 24 godziny i zostanie zapomniany, wszystkie wartości docelowe generowane tym kluczem nie będą już więcej rozkodowane. W związku z tym po 24 godzinach będziemy mieli dane anonimizowane a nie pseudonimyzowane. To również oznaczałoby ochronę przed Rainbow-Tablicami, przynajmniej po upływie klucza.

Ochrona przed niebezpieczeństwami przy użyciu metadanych lub pseudonimizacji

Pytanie było, czy można odparować ataki DDoS tylko wtedy, gdy adresy IP są protokolowane bez powodu. Uważam, że dla odparowania ataków DDoS nie jest wymagana znajomość adresów IP.

W przypadku nie najlepszych praktyk dotyczących ochrony danych osobowych adresy IP byłyby zapisywane w formie pseudonimicznego datuma za pomocą procedury szyfrowania, która może nie mieć funkcji jednorazowego szyfrowania. Atak DDoS charakteryzuje się tym, że atakujący wykonują szybkie po sobie ataki. Klucz zależny od czasu daje możliwość pseudonimizacji, która może być używana bez powodu. Ten procedurę nie można było w rzeczywistości uważać za gorszą niż korzystanie z pełnych adresów IP. Tylko przy retrospektywnym spojrzeniu byłoby to gorsze. Retrospektywny ogląd jest często użyteczny, aby analizować falę ataków.

Ponadto niebezpieczeństwa mogą być skutecznie odrabiane, jeśli zapisywane są skrócone adresy IP lub dane metadanych do adresów IP. Jakie dane te mogą być przydatne, opisałem powyżej.

Podczas ataków DoS lub DDoS atakujący może łatwo fałszować swoją adres IP (adres IP). Ponieważ nie muszą oczekiwać odpowiedzi na ich złośliwe żądanie. Atakujący mógłby więc zmieniać adresy IP. Jeśli przechowywano pełne adresy IP, niczego by się nie skorzystało, przynajmniej w czasie rzeczywistym.

Niewiele dostępów: Atakujący, którzy tylko raz lub kilkukrotnie uzyskali dostęp do systemu ofiary, mogą nie być w ogóle rozpoznani lub rozpoznani przypadkowo. Zalogowanie (Zaloguj się) przy użyciu zdobytych danych użytkownika może zostać związane z protokołem IP. Wykorzystanie luk w bezpieczeństwie, takiego jak Log4J, poprzez jeden dostęp nie może być zapobiegane lub rozpoznany ad hoc przez protokół IP. Takie głupią rzecz, ale przechowywanie adresu IP bez powodu, aby ułatwić potencjalnemu sprawcy ujęcie, jest niedopuszczalne. Kamery na dachu samochodów, które stale i bez powodu filmują, są również niedopuszczalne. Niestety, ale takie to, nawet jeśli w ten sposób niektórym winnym nie uda się ująć. Jeśli atakujący wpisze kod szkodliwy do pola formularza, aby zdobyć dane, może być rozpoznany przez ocenienie danych wejściowych. Na przykład takie mogą być rozpoznane SQL-injektiony. Ponadto kod szkodliwy może zostać bezskuteczny, jeśli na serwerze znajduje się odpowiednia programowanie. To jest łatwiejsze do powiedzenia niż zrobienia, jak można zobaczyć w szeroko rozpowszechnionej bibliotece pomocy Log4J, która umożliwiała skuteczne ataki hakera bez większego wysiłku. Jednakże protokolowana pełna IP-adres nie jest lepsza w rozpoznaniu ataku niż to, co inaczej możliwe (mówię).

Używający atakują czasowo stabilne adresy IP, pomagają dane metadanych adresów IP w czasie rzeczywistym w rozpoznaniu ataku. Ponadto za pomocą danych metadanych jest możliwa automatyczna lub ręczna ocena odwrotna znacznie łatwiejsza niż gdyby tylko pełne adresy IP były przechowywane i dane metadanych musiały być uzyskane w celu analizy ataku. Pierwszy raz jest zawsze pierwszym razem. Oznacza to: przy pierwszej atakacji, która jest później analizowana, ofiara musi trudno ustalić dane metadanych dla protokolowanych pełnych adresów IP. Poza tym, jeśli dane metadanych były bezpośrednio protokół, najlepiej bez pełnego adresu IP. Pełna protokół zapisywanie adresów IP bez danych metadanych ma oczywiste techniczne wady.

Atak, który zawsze odnosi się do tej samej strony docelowej (URL), może być łatwo rozpoznany. Jeśli strona docelowa jest często odwiedzana, więcej niż to normalnie byłoby, mogłoby to sugerować powód dla protokołu IP. Protokół bez powodu nie byłby konieczny w celu ochrony przed zagrożeniami.

Ataki DDoS, które można przypisać do określonego kraju, nie występują zwykle w Niemczech. W Niemczech mamy bardzo dobre możliwości śledzenia prawnych. Z drugiej strony komputery zombie mogłyby być używane do ataków z wewnątrz kraju. Niemieckie strony internetowe, której można przypisać ataki, mogą rozpoznać i zablokować próby dostępu z zagranicy. To wszystko może być zrobione bez znajomości pełnych adresów IP (patrz powyżej: ASN, kraj, dostawca). Aby przeprowadzić analizę ataków zombie, analiza wezwań byłaby przydatna (adresy URL docelowe, parametry, częstotliwość, User-Agent…).

Niektóre ataki nie mogą być skutecznie zablokowane nawet przy pełnej protokół IP rejestracji, ani za pomocą innych środków. O takich atakach nie trzeba więc mówić w kontekście pytania o bezprzyczynową rejestrację wszystkich adresów sieciowych. Przykładami takich ataków są:

Kod szkodliwy: Użytkownikowi zalogowanemu przesyłany jest szkodliwy link. Albo używany jest do wysyłania maili zombie-komputer, albo proxy lub strona internetowa poddana ataku. Jeśli hacker jest szczególnie głupi, korzysta ze swojego własnego połączenia do wysyłania maili. W każdym przypadku w nagłówku wiadomości e-mail często znajduje się adres IP nadawcy i nie musi być odseparowany protokołowano. Niezależnie od tego, może również odebranie wiadomości e-mail mogą być uznane za powód. Gdy strony internetowe są poddane atakowi i na nich umieszczany jest szkodliwy kod, protokołowanie adresu IP w momencie kliknięcia linku nie przynosi żadnych korzyści.
IP-Spoofing: Atakujący wykorzystują losowo generowane adresy IP nadawców i metadane. Odpowiedzi otrzymują atakujący nie, ich celem jest szkodzenie ofierze poprzez złośliwe żądania. Dawniej (i dzisiaj?) atakującym było możliwe otrzymanie odpowiedzi dla innych adresów (Backscatter-Attacke).
Udostępnione dane dostępu: Wiedza o danych dostępowych pozwala hackerowi wyglądać jak prawdziwy użytkownik. Zazwyczaj tylko dzięki podejrzanej aktywności lub bardziej szczegółowej analizie, a nawet informacji od właściciela danych dostępu można zidentyfikować takie próby wejścia. Jeśli próba logowania pochodzi z zagranicy lub z innego urządzenia niż to, na które jesteśmy przyzwoleni, może być wprowadzona bezpośrednia weryfikacja (CAPTCHA, pytanie o datę urodzenia itp.). Ale nawet tutaj nie pomaga wiedza o pełnej adresie IP, przynajmniej nie dalej niż metadane, które zezwalają na bardziej obszerną analizę.

W krótkiej, nieco luźnej prezentacji zebrane są kilka rodzajów ataków. Rodzaje te mogą się nakładać (DoS może być z kraju lub za granicą itd.). Tabela ma jedynie pokazać ogólny widok i jest prawdopodobnie niepełna.

Rodzaj ataku	Rozpoznawanie
Nadmiarne korzystanie z dostępu	Porównaj konkretną adres IP w pamięci.
Denial of Service	Porównaj konkretną adres IP w pamięci.
Distributed Denial of Service	Skrócone adresy IP lub dane metadanych ocenić.
Wprowadzenie szkodliwego kodu (iniekcja SQL itd.)	Dane zawartości przeciwko słowom kluczowym i znakom kontrolować.
Zalogowanie przez hakera (zdobyty dostęp)	Szukaj konkretnego adresu IP w bazie danych, gdy adresy IP zalogowanych użytkowników są przechowywane, lub bezpośrednia protokół (powód = Logowanie)
Napad z zagranicy	Dane metadanych oceniać, szczególnie kraj, ASN, podsieć.
Napad z kraju	Dane metadanych oceniać, szczególnie ASN, podsieć.
IP-Spoofing	Jeśli możliwe, sprawdź adres nadawcy w porównaniu z adresem routingu, który uważasz za prawidłowy, co np. w lokalnych sieciach jest dobrze możliwe. Gdykolwiek może pomóc Unicast RPF (nie jest moim specjalistycznym obszarem)

Znajomość ataków bez protokołowania pełnej adresu IP.

Po rozpoznaniu lub uznaniu za prawdopodobną atakę może (może) odbyć się protokół zależny od okoliczności, dotyczący adresów IP, jeśli jest to niezbędne do ochrony przed zagrożeniami.

Jeśli adresem IP zostanie zablokowana, ponieważ uznaje się ją za adres atakujący, istnieją następujące zagrożenia:

Adres jest naprawdę nieprzyjacielem, lecz została niesłusznie podejrzana (co wygląda szczególnie przy automatycznych blokadach jako możliwe).
Adres była fałszywa i należała do innego (niegroźnego) połączenia lub do niczego (wtedy efekt zablokowania byłby równy zero).
Adres należała do atakującego, została jednak już przypisana innemu (pozytywnemu) połączeniu. Może się to zdarzyć przy dynamicznych adresach IP, ale także przy dostępie przez sieć Tor.
Adres jest przypisana przez Carrier Grade NAT do kilku połączeń. Wszystkie łączności, oprócz jednej, są potencjalnie bezpieczne i niechcąco są zablokowane.
Adres ta reprezentuje proxy. Gdy adres proxy jest zablokowany, żaden połączenie nie może nawiązać połączenia przez proxy.

Zobaczcie, że blokowanie adresu IP nie jest zawsze rozwiązaniem wszystkich problemów, ale może nawet pogłębić je w niektórych przypadkach.

Inne okazje, które nie są atakami, mogą być:

Cel testowy, np. szukanie błędów, optymalizacja lub nowe rozwiązania
Pokusy rejestracji przy użyciu nazwy użytkownika i/lub hasła
Wprowadzenie do formularza niezwykle interesujących danych (tu niekoniecznie chodzi o szkodliwe oprogramowanie)

Nie będę tu szerzej odnosił się do tych okazji, ponieważ tutaj chodzi o kwestię protokołowania bez przyczyny!

Wnioski

Protokowanie adresów IP bez powodu do celów zapobiegania niebezpieczeństwom wydaje się technicznie niepotrzebne. Nie widzę dowodów na to, że tak jest. Zamiast pełnych adresów IP można protokować następujące dane:

Zakresy adresów IP (takie jak podsieci)
Zakresy adresów IP
Pseudonim, jak czasowo ograniczony cel, który po krótkim czasie staje się anonimowy
Informacje metadane dotyczące adresów IP:
- Ziemia
- Dostawca
- ASNR (Agencja ds. Nadzoru)
- Nazwy hostów
- Opinia publiczna
Informacje metadane dotyczące połączenia
- Cel wywołany (adres URL itp.)
- Dane metadanych nadawcy, takie jak User-Agent lub konfiguracja cache'owania
- Czas dostępu
- Dostępność odwrotnego odbiornika

Jeśli jednak istnieje powód, pełna protokolarzacja adresu IP może być uzasadniona. Przykładami takich powodów mogą być:

Nadmiernie częste wywołanie przez źródło
Niezwykłe zachowanie użytkowników
Nieprawidłowe wywołania (np. niezwykłe parametry adresu URL lub nieistniejące adresem)
Zawarte w niepewności metadane (przykład: dostępy z kraju X lub z podsieci Y)
Wielokrotna niewłaściwa odpowiedź
Szukanie błędów (przykład: protokołowanie własnych akcji, aby znaleźć błąd w sieci)

Możą istnieć różnice w ocenie scenariuszy zagrożeń w przypadku małych i dużych sieci oraz małych i dużych stron internetowych. Nie mogę jednak zauważyć, żeby to powodowało istotne różnice dla tematu tego wpisu.

Oto tłumaczenie: Przypomnijmy sobie, że wysyłanie opinii na portalu dyskusyjnym nie jest powodem do zapisania wpisu w pliku logi Webservera z adresem IP. Zamiast tego będziemy przechowywać opinię, ewentualnie z adresem IP nadawcy, w bazie danych.

W początku napisałem, że chodzi tylko o własne serwery, nie o dostawców usług internetowych (ISPs). Czy ISPs muszą zawsze i bez powodu protokolować pełną adres IP w celu obrony przed niektórymi zagrożeniami, to na razie odważyłem się zaprzeczyć. Choć przy ISP może być tak, że te obawy są nieuzasadnione. To samo można powiedzieć o sieciach dostarczania treści (CDNs). Jeśli CDNs protokolują bez powodu pełne adresy IP, to musi to zostać przez dostawcę CDNs poinformowane. Wiem od Akamai, że tak się dzieje. Dlatego zastosowanie usługi Cookiebot zostało zabronione, która korzysta z serwerów Akamai.

Bezprzyczynowa protokolarizacja pełnych adresów IP przez administratorów serwerów w celach bezpieczeństwa jest technicznie niepotrzebna.
Moja wiedza do czasu przeciwnego dowodu.

Jeśli są innej opinii, widzę dwie możliwości:

Możecie wymienić konkretne, zrozumiałe przykłady. W takim przypadku będę przetestował przykład i zmienię zdanie, jeśli Wasze przykłady to potwierdzą.
Nie mogą wskazać konkretnego przykładu. W takim przypadku powinnie zmienić swoją opinię, chcą lub nie, bo opinia byłaby bezpodstawna i niesłuszna.

Proszę napiszcie mi, ktoś zna konkretne przykłady, które dla administratora serwera mogą być istotne. Ponownie przypominam, że chodzi o bezpardonową protokolację, a nie o protokolację w przypadku rozpoznania okazji! Nie chodzi również o ocenę użyteczności, ale raczej o ocenę konieczności. Jako hasło można tu wymienić najmniejsze zło. I istnieje wiele innych środków, które są tak samo odpowiednie jak adresy IP, a nawet lepsze w rozpoznaniu lub odparowaniu zagrożeń.

Nie użyteczność jest decydująca, lecz potrzeba i dostępność łagodniejszych środków.
Ten zasadniczy punkt prawdopodobnie obowiązuje w wielu dziedzinach ochrony danych osobowych.

Krótki zarys dobroczynności:

Incident	Przydatne?	Dobrze/Nie dozwolone?
Zaniechanie złożenia deklaracji podatkowej	Tak, dla wszystkich, którzy nie mają ochoty do tego	Nie, mówi prawo
Przelew bankowy	Tak, dla tego, który potrzebuje pieniędzy	Nie, mówi prawo
Kamery do rejestracji wypadków (z zapisem na stałe)	Tak, później udowodnić winę kierowcy przeciwnemu w przypadku wypadku	Nie, przynajmniej nie na długo (przez co wiem)
Bezpardonowe rejestrowanie pełnych adresów IP	Tak, dla wielu pewnie	Nie, twierdzę w tym wpisie

Pożyteczność wobec konieczności

Nie chodzi o ściganie sprawiedliwości, ponieważ nie jest to sprawa administratora serwera i tym bardziej nie jest to sprawa samego serwera (chyba że serwer należy do osoby uprawnionej do prowadzenia postępowania).

Rozmowy z ekspertami i moje pytania w kilku grupach ekspertów na portalu społecznościowym nie dały mi żadnego przykładu, który mógłby obalić moją postawę. Także BSI (German federal security agency) nie mogło mi podać konkretnego przykładu. Zamiast tego otrzymałem odpowiedź z mało interesującymi informacjami. W tej odpowiedzi było wspomniane, że adresy IP są danymi osobowymi i że należy przestrzegać przepisów z DS-GVO. To wszystko mi już było znane. Ponadto został mi wskazany BSI (German federal security agency) Kompendium, ale nie znalazłem tam żadnego konkretnego przykładu (niech niczego nie przegapiłem).

Jeśli zawsze przechowujecie w swoich logach serwerowych pełną adres IP użytkowników z sieci dostępnej publicznie, zatrzymajcie się albo podajcie konkretny przykład, dlaczego to jest dla what dozwolone i nie naraża innych na zagrożenie
Ta prośba kierowana jest do zwykłych operatorów serwerów, a nie do IPS, organów ścigania itp.

Niedawno zauważyłem, że na serwerze FTP klienta jest wyświetlany protokół serwera z pełnymi adresami IP. Z tego wynika pytanie, jaki korzyść może mieć ta informacja dla klienta. Korzyść w praktyce powinna być bliska zeru. Klient nie może na przykład na swoim serwerze wirtualnym zminimalizować ataku DoS, jeśli wie adres IP atakującego. To samo dotyczy często serwerów zarządzanych.

Przypominam, że NDR jako odpowiedzialny za stronę Tagesschau-Webseite zgodnie z informacjami o ochronie danych osobowych protokoluje pełną adres IP od wszystkich użytkowników. Dlaczego tak się dzieje, nie jest wyjaśnione. Nie ma wątpliwości, że inspektor ochrony danych NDR nic o tym nie wie i/lub nie powie.

W swoim własnym wpisie poświęcam się maksymalnie dozwolonej długości przechowywania plików logów stron internetowych.