Реєстрування IP-адрес в серверних журналах: дозволено чи ні?

За повідомленнями про захист даних на багатьох вебсторінках IP-адреси зберігаються у серверних журналах повністю протягом тривалого періоду, часто з твердженням про необхідність безпеки без жодного приводу. Чи дозволена безпідставна реєстрація залежить від того, чи вона технічною необхідністю є або чи існують більш м'які засоби.

Вступ

Оголошення: Цей матеріал розглядає лише публічно доступні сервери звичайних операторів, тобтоНІ від ISP, правоохоронних органів тощо. Тут не йдеться про випадки, які охоплені § 172 TKG. Не вважається наявною правову підставу згідно з Art. 6 DSGVO, наприклад згоду користувача (інакше питання було б швидко вирішене).

Виночас, щоб уникнути помилок: розуміння поняття "підстава" є фундаментальним! Він пояснюється у статті. Власність даних попереднього зберігання називається такою, бо вона відбувається без підстав, тобто завжди!

Адреси IP є мережевими адресами. Вони є частиною Метаданих, які при кожному зверненні вебсторінки завжди передають. Ці метадані іноді називаються також даними про рух або даними про підключення. Значення цих двох термінів здається різним у технічному та юридичному контексті. Тому я використовую термін метаданих.

Адреси IP згідно вищій судової правової інтерпретації ЄСПЛ та Бундесгерихт є дані особистого характеру. Це стосується також динамічних адрес IP, і саме з 2016 року (ЄСПЛ) та 2017 року (Бундесгерихт). Діє GDPR з кінця травня 2018 року.

Адреси IP дозволяють можливо визначити Напади та відповідно підвищити Безпеку серверів. Крім того, шляхом отримання інформації про адресу IP може відбутися Слідкування злочинів. Всі ці речі здаються мені правдоподібними, хоча не для кожного можливого сценарію нападу. Мої співрозмовники, численні експерти з інформаційної безпеки та права, підтверджують це.

Адреси IP, отже, корисні для підвищення безпеки сервера та для розслідування злочинів. Нуттєвість ж не є вагомим підставою виправдання.

Питання таке:

Мусить повні IP-адреси без особливої причини реєструвати власниками власних серверів, чи є більш м'які засоби?
Питання цього статті.

Цей матеріал стосується власників серверів. Інтернет-провайдери (ISP) такі як Deutsche Telekom або Vodafone повинні бути виключені з цієї групи через їхню складність.

Оновлення: Європейський суд навіть визнав незаконною зберігання даних без підстав, якщо вони можуть бути використані для розслідування тяжких злочинів. Дивіться Європейський суд від 05.04.2022 (Az.: C-140/20).

Самі законодавчі акти, які передбачають попередню боротьбу з тяжкою злочинністю та запобігання серйозній загрозі громадській безпеці шляхом загальної та нечуйкої зберігання даних про рух і місцезнаходження, є незаконними.
Мій варіант формулювання рішення ЄСПЛ від 05.04.2022 року, РН. 101.

Європейський суд встановлює також, що дозволено лише для попередження загрози громадській безпеці та боротьби з важкою злочинністю «для обмеженого періоду часу здійснити всіагалкову і нечизбливу зберігання IP-адрес, призначених джерелом підключення (п. 101 рішення). Європейський суд підтверджує, згідно зі мною розумінням, те, що я вже раніше висловив раніше. Приватні оператори серверів мають мало або нічого спільного з громадською безпекою та ще менше із боротьбою проти важкої злочинності.

Ну далі в тексті, без прямого відношення до вищезгаданого рішення ЄСПЛ, яке було прийнято вже після створення цього тексту.

У моїй статті йде мова про такі три умови, які несподівано збіглися:

АНОНС ЗАБОРЕННЯ (!!!)
ПРОТОКОЛІВАННЯ (= тривала зберігання, наприклад у файлах)
ВСІ ВИБРАНІ АДРЕСИ ІП

Навколовідповідь: Мета – попередження небезпеки. Вивчення злочинів не має до мене та до вас ніякого стосунку, а також ні до вашого сервера, якщо ви поліція, прокуратура тощо.

Будьте ласка, прочитайте ці умови перед тим як продовжити читання і спробувати відповісти на питання цього статті!

Це не стосується:

Звітність, пов'язана з обставинами та/або
Надзвичайно тимчасово збережені дані та/або
Користування іншими даними ніж повними адресами IP та/або
Вищення покарання через органи влади, поліцію, прокуратуру.

Ви це усвідомили? Тоді продовжуйте читати далі та повідомте мене, коли ви станете першим, хто зможе назвати конкретний приклад безпідставної реєстрації IP-адрес, який вказує на наявність правової підстави.

Безпідставно означає, що адреси IP завжди реєструються. Anlassbezogen означає, що реєстрація адрес IP починається лише після виникнення події, наприклад, підозрюваного хакерського нападу або при пошукові помилок у мережевих проблемах чи спробі входу з паролем. Подія вважається встановленою лише тоді, коли вона була визначена або припущена. Неприйнятно буде вважати подію встановленою пізніше. Тоді завжди потрібно реєструвати дані, щоб потім викинути 99% даних (які будуть реєстровані без підґрунтя та таким чином, як стверджується, незаконно), лише щоб використовувати 1% даних для встановленої згодом події. Подія також може вважатися встановленою тоді, коли автоматизм з досить високою ймовірністю вважає її наявною. Але ця висока ймовірність не може бути обов'язковим для будь-якого доступу (окрім того, що кожен доступ до сервера здійснюється від хакера). У цьому статті мова не йде про обговорення ймовірності. Постійна реєстрація даних ґрунтується на ймовірності 0%, що подія існує, і є незаконною, згідно з моїми уявленнями.

Є підстава для чогось – це уявне подійство. Звичайна реєстрація явно відбувається без підстав.
Визначення.

Є підстава, яку ще називають Подія на іншому місці. Дивіться далі в IT-Грунтівий компендіум BSI (German federal security agency). Там знаходиться, якщо я бачу це правильно, ніякої конкретної вказівки щодо того, що повні адреси IP повинні реєструватися без події (тобто без підстави). навіть якщо ця вказівка була б у компендіумі BSI (German federal security agency), відсутнє конкретне приклад для виправдання законного інтересу як правової підстави відповідно до ст. 6 DSGVO.

Я вважаю щодо відповіді на питання, чи слід реєструвати IP-адреси без особливих підстав, спочатку про призначення IP-адрес для розслідування злочинів, потім про захист систем.

Виправча діяльність

Сервер не має завдання здійснювати слідство. Також оператор сервера не має завдання здійснювати слідство. Перейдіть до юриста, якщо ви бачите це інакше.

Оттак, метою слідства як виправдання для безпідставної зберігання адрес IP відмовляється.

Виправча діяльність не належить ні власнику сервера, ні самому серверу. Отже, цей ґрунтовий привод видаляється як виправдання для безпідставної реєстрації мережевих адрес.
Напевно, такий собі допоміжний поліцейський.

Є сучасним прикладом корисної, але тим самим забороненої обробки даних – аналіз зібраної інформації про відвідувачів ресторану для спостереження за коронавірусом. Основна поліція міста Майнца шукала свідка після смерті клієнта цього ресторану. Для цього поліція використовувала дані із програми "Лука", які було зібрано згідно обов'язкових вимог власником ресторану. Після чого поліція звернулася до відвідувачів, які були у ресторані в той час. Це було, безумовно, корисне. Але це було заборонене. Для того, щоб дані використовувалися лише для охорони здоров'я. Державна прокуратура розпочала розслідування проти поліції та вибачилася перед свідками, яким було зроблено незаконні звернення.

Інше приклад: так звані Крипто-Телефони були або були використовувані злочинцями для таємного спілкування. Поліції вдалося розшифрувати повідомлення через ці телефони. Цей спосіб збору доказів був підданий сумнівам (я вважаю, тому що немає рішення суду). Однак було визнано (лише?) на підставі того факту, що це була випадкова знахідка, знаходження повідомлень у розшифрованих телефонах як докази було прийнято. Інакше міг бути такий випадок, коли ця корисна знахідка була б незаконною і тому не мала би бути використана як доказ. Судова палата Берліна класифікувала цю знахідку як випадкову знахідку згідно зі статтею 100e § 6 п. 1 Кримінального процесуального кодексу Німеччини.

Захист від небезпек

Захист обробки даних вимагає згідно статті 32 ДЗПВ. За цим мають бути організовані ІТ-системи так, щоб ризик виникнення безпеки був зменшений у відповідній мірі. Захист від небезпек є не лише законодавчою вимогою, але й власним інтересом керівників.

Приклади випадків безпеки

Відповідь тексту: Різні приклади безпеки, які мені прийшли на думку, а не лише загальна назва "атак хакерів":

Denial of Service Attacke (DoS)
Distributed Denial of Service Attacke (DDoS)
Malware, Ransomware, Viren
Дані доступу
Перетворення системи в Зомбі-комп'ютер

Найомі деякі з згаданих атак здійснюються за допомогою механізмів, як-от захоплення сесії, фішингу, спаму або експлуатування експлоїтів/вulnerabilitей (приклад: Log4J).

Список не повністю викладений. Якщо важливе сценарій відсутній, просимо повідомити про це (у разі можливості через поле коментарів нижче).

IP adresses

Кожний інтернет-з'єднання ґрунтується на мережній адресі, яку також називають IP-адресою. Кожному користувачеві присвоюється IP-адреса (яка надається через пристрій, наприклад, маршрутизатор). Часто приватні особи отримують динамічну IP-адресу від свого провайдера. Вона змінюється в нерегулярних інтервалах, іноді навіть у регулярних інтервалах. При кабельному інтернет-з'єднанні здається, що зміна IP-адреси відбувається рідше, ніж при з'єднаннях через телефонні лінії. При відключенні електроенергії, ймовірно, також відбуватиметься (не запланований) перехід однієї IP-адреси до іншої, про що я особисто спостерігав. За допомогою перезапуску підключення Fritz!Box, якщо воно використовується, часто можна отримати нову IP-адресу.

Найомі провайдери пропонують також статичні IP-адреси. Вони здебільшого використовуються бізнес-клієнтами та менше приватними особами. Статичні IP-адреси не змінюються протягом часу.

Внаслідок обмеженого простору адресування IPv4-адреси може відбуватися розподіл однієї IP-адреси між кількома різними підключеннями, тобто особами. Цей розподіл здійснюється технічним шляхом за допомогою різних портів. Термін для цього є Кар'єр-Грейд NAT (CGN), що приблизно означає мережевий ключ розширення через інтернет-провайдера.

Європе́йський Суд у справах про права людини (ЄСПЛ) ухвалив рішення від 19 жовтня 2016 року (C-582/14), згідно з яким інтернет-адреси вважаються особистими даними, якщо можливий розголошення інформації щодо власника інтернет-з'єднання в певній країні ЄС. У Німеччині це можливо, наприклад, для проведення слідчих дій. Достатньо наявності об'єктивної можливості отримання цієї інформації щодо інтернет-з'єднання навіть після звернення до кількох організацій (провайдерів послуг зв'язку, спецслужб тощо). ЄСПЛ також стосується динамічних інтернет-адрес. Німецький Верховний суд підтвердив це рішення 16 травня 2017 року (VI ZR 135/13).

За допомогою деяких конкретних прикладів я тепер перевірю, чи може бути обґрунтованим зберігання IP-адрес без особливих підстав.

Denial of Service Attacken

При цьому виді атаки сервер піддається зловісним масовим запитам, що призводить до його краху та неспроможності виконувати свої звичайні функції.

Є можливість легко встановити, чи з однієї IP-адреси здійснено багато запитів протягом одної хвилини. Для цього зберігається кожна IP-адреса в оперативній пам'яті серверу, тобто не реєструється і не зберігається у технічному сенсі. Якщо після одного іншого запиту з однієї IP-адреси збільшується рахунок на одне, наприклад, протягом хвилини до 200, можна вважати, що здійснено брут-форсувальний доступ.

Є підстави для реєстрації повної адреси IP. Немає підстав для реєстрації.
Мої сучасні знання.

Якістю великою є ймовірність нападу, такий підстава для реєстрації IP-адреси вже дано. Тільки після цього часу повинна бути реєстрована IP-адреса, якщо вона буде реєстрована взагалі. Таким чином ця одна IP-адреса може бути заблокована для майбутніх доступів.

Distributed Denial of Service Attacken

При такій формі атаки, також відомій як DDoS, виконуються масові запити від багатьох комп'ютерів на жертву- сервер. У попередньому сценарії нападу ці масові запити здійснювалися лише з однієї машини або кількох атакуючих комп'ютерів.

Виражені атаки відрізняються тим, що атакуючі комп'ютери мають різні IP-адреси. Якщо захистити сервер лише окремими IP-адресами, він може не бути досить швидко підготовленим до захисту. Бо існує багато систем атак, і не тільки одна, яку потрібно вивести з ладу.

Одна з можливостей визнання розподілених атак — розширене тлумачення адрес атакуючого. Для цього, наприклад, видаляється останній байт IPv4-адреси (IP-адреса із 4 байтами). Приклад:

Denial of Service
- Атакуюча IP адреса: 10.20.30.40.
- Атаку вимкнути: блокування 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
- Вимкнення атаки: блокування області IP 10.20.30.x або навіть доступу з певної географічної території, наприклад країни

Аби визначити, чи атакувальники мають різні мережеві адреси, можна додатково Метадані вивчити. ІП-адреса має зокрема такі особливості, які наприклад можуть бути автоматично встановлені за допомогою баз даних.

Країна. Наприклад: Німеччина.
Провайдер. Наприклад: Водафон.
Адрес господаря. Для деяких IP-адрес прямий наявність додаткової інформації. Приклади: 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
АСН: Номер Автономної системи. Автономна система – це щось подібне до Поштового відділення. Від головного поштового відділення дані пакети надсилаються на місцеве поштове відділення, яке потім розподіляє їх на місці. Провайдер володіє кількома поштовими відділеннями, тобто ASNs.
Субнет. Several consecutive IP-addresses. Example: 10.20.30.0 up to 10.20.30.255, so 10.20.30.x or 10.20.30.0/24.
Репутація. Часто ведеться у формі вартості (Рейтинг ) або як негативна ліст (Чорний список ).

Крім адреси IP існують ще інші метадані, особливо при зверненні до вебсторінок. Серед них такі:

Користувач-агент: Тип браузера, Версія браузера, Тип операційної системи, Версія операційної системи. Приклад: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
У браузері встановлена Мова користувача. Приклад: de,en-US;q=0,7,en;q=0,3
Конфігурація кешу. Приклад: no-cache (кеш вимкнений)
Перенаправник: Сторінка, через яку здійснено звернення (наприклад, після кліку на посилання). Приклад: https://dr-dsgvo.de/
Викликана сторінка: Сторінка разом із параметрами URL, яка була викликана. Приклад: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
Інформація про вміст: Часто виникає з параметрів URL (GET) або запиту (POST). Приклад: Username=SELECT * from users
Загальний час доступу: завжди наявний навіть при всіх інших мережевих запитах. Урешті-урські повідомлення знають, коли вони отримані.
Застелений статус: Відправник отримує відповіді на свої запитання чи використовує він недоступну (бо фальшиву) адресу відправника?

Ці дані можуть бути розглянуті як особисто пов'язані та відповідно особисті дані (порівн.: Стаття 4, пункт 1 ДЗПВ). Якщо б зберігати ці дані відкритими та неокресленими, то було б мало виграш. Відповідно пропонує себе можливість цих даних, якщо вони здаються корисними для попередження небезпеки, зашифрувати. Це зашифрування може бути досягнуто шляхом математичної операції.

Кодування особистих даних

Використання шифрування даних відбувається таким чином, що значення даних поєднано з вільно обраним відповідним ключовим значенням. Результатом є цілевказівка. За допомогою криптографічного хеш-розширення також можна згенерувати значення, які не повинні бути унікальними. Багато різних вхідних даних можуть бути відображені на одному і тому ж цілевказівці. Вірогідність цього може бути дуже низькою або фактично виключена шляхом вибору відповідніх методів та параметрів (так звана ін'єктивна картинка чи ідеальний метод без зіткнень).

Цільове значення є псевдонімом дати, коли відомий ключовий значення. Наприклад:

Користувач Х звертається з адресою IP А1 на вебсайт. Адреса A1 перетворюється за допомогою ключа S1 у значення H1.
Г1 не можна повернути в А1, оскільки процес асиметричний.
Нині користувач Х знову відкриває вебсайт за адресою А1, відбувається створення цілевого значення H1 через S1. H1 вже був збережений у базі даних. Виявляється цей вікористаний раніше часовий період. Таким чином відомо, що користувач Х зараз і раніше відкривав сторінку вебсайту. Тому можна відновити H1 за адресою А1.

За допомогою часово обмежених ключів, які мають дію лише протягом певного часу, можна здійснити тимчасову псевдонімування із подальшою анонімізацією. Для цього підходять одноразові функції. Одноразова функція дозволяє шифрувати дані, але не розшифровувати їх. Якщо раніше був встановлений рівень відкритості даних, який вже був зашифровано, після повторного шифрування можна порівняти рівень відкритості даних із попереднім рівнем відкритості. Таким чином можна встановити, що рівень відкритості даних вже існував раніше. Але дані, які були знову зашифровані, не можуть бути відновлені до рівня відкритості без наявності знову відкритого рівня відкритості даних.

Для дуже коротких вхідних даних повинні бути прийняті відповідні заходи для забезпечення того, щоб ефективна дешифрування була неможлива. У першу чергу не можна використовувати Rainbow-таблички. Найкраще, якщо процес такий організований, що такі таблиці зовсім не застосовуються.

Якщо ключ S1 діє лише протягом 24 годин і потім забувається, усі дані, які були згенеровані цим ключем, більше не можуть бути розшифровані. Таким чином після 24 годин перед нами будуть анонімні дані, а не псевдонімовані дані. Це також буде захист проти Rainbow-табличок, принаймні після закінчення дії ключа.

Захист від небезпек за допомогою метаданих або анонімізації

Питання було саме в тому, чи можна відбивати DDoS-атаки лише тоді, коли реєструються безпідставні IP-адреси. Я стверджую, що для захисту від DDoS-атак необхідність знання IP-адрес не є обов'язковою.

У випадку неоптимального захисту даних IP-адреси реєструвалися у вигляді псевдонімного часу з застосуванням шифрування, яке, можливо, не має одноразової функції. Атака DDoS відрізняється тим, що атакувальники швидко чергуються в атаках. Часовий ключ надає можливість псевдонімування, яке без особливої причини може бути використане. Цей процес не буде гіршим за використання повних IP-адрес у реальному часі. Лише при огляді з минулого він буде гірший. Огляд із минулого часто є корисним для аналізу хвиль атак.

Помічені небезпеки можуть бути ефективно відбиті, якщо скорочені IP-адреси або метадані щодо IP-адрес зберігаються. Я вже описував які саме метадані можуть бути корисними.

При атаках типу DoS або DDoS нападник легко може змінювати свою адресу джерела (IP-адреса). Він не має необхідності отримувати відповідь на свій шкідливий запит. Нападник міг би використовувати переміщення IP-адрес. Якщо б зберігати повні IP-адреси, то нічого особливого було б досягнуто, принаймні в реальному часі.

Надзвичайно рідкі звернення: Атакувальники, які здійснюють лише один або кілька спроб доступу до системи жертви, можуть бути або зовсім не визнані, або визнані тільки у зв'язку з цим. Вхід (Увійти) із використаними обліковими даними може бути додатково забезпечений протоколом IP. Використання безпеки, наприклад Log4J, лише один раз не можна запобігти чи навіть швидко виявити за допомогою протоколу IP. Так само погано, але зберігати IP-адресу без жодного приводу для можливого злочинця не допустимо. Дашкамери у автомобілях, які постійно і без жодної причини знімають відео, теж не допустимо. Що ж до того, що таким чином можна не вловити одного злочинця, але так воно є. Якщо атакувальник вводить шкідливий код у поле форми для отримання даних, це може бути встановлено шляхом оцінки даних, введених користувачем. Наприклад, такі SQL-атаки можуть бути виявлені. Крім того, шкідливий код можна зробити непрацездійним шляхом створення відповідної програмування на сервері. Це важче сказати, ніж зробити, як було видно з дуже поширеної бібліотеки допоміжних функцій Log4J, яка дозволяла ефективні атаки хакерів без особливого зусилля. Але навіть повна IP-адреса також не допомагає визнати атаку краще, ніж це можливо було б інакше (я вважаю).

Використовують атакувачі часові відносно стабільні IP-адреси, допомагають метадані IP-адрес в реальному часі розпізнавати атаки. Крім того, за допомогою метаданих здійснюється автоматизована або ручна обробка набагато легше можливий, ніж коли тільки повна IP-адреса зберігається і метадани для аналізу атак отримуються пізніше. Перша спроба завжди перша спроба. Це означає: при першій атакі, яка пізніше аналізується, жертва повинна важко здобувати метадані для протоколованих повних IP-адрес. Крім того, якщо метадані були записані безпосередньо, найкраще без повної IP-адреси. Повна реєстрація IP-адрес без метаданих має очевидні технічні недоліки.

Атака, яка завжди звертається до однієї й тієї ж сторінки (URL), легко розпізнається. Якщо сторінка часто викликається більше, ніж це було б нормально, міг бути підставою для реєстрації IP-адреси. Безпідставна реєстрація була б не потрібна для попередження небезпек.

Атаками DDoS, які можна віднести до певної країни, як правило, не відбувається в Німеччині. У Німеччині у нас досить добрі можливості щодо дотримання законодавства. З іншого боку, зомбі-комп'ютери можуть бути використані для атаки з території країни. Німецькі вебсторінки, звичайно ж, зможуть добре розпізнати та блокувати доступи із-за кордону, які виглядатимуть як атаки. Для цього не потрібна повна інформація про IP-адреси (дивіться вище: ASN, країну, провайдера). Для зомбі-атак же додаткова аналіз запитів допоможе (цільові URL, параметри, частота, User-Agent…).

Вищі атаки можуть бути ефективно зупинені навіть без повної реєстрації IP-адрес, або іншими засобами. Про такі атаки не варто говорити далі щодо питання обов'язкової реєстрації всіх мережевих адрес. Прикладами таких нападів є:

Шкодний код: Зареєстрованому користувачеві надсилається шкідливий посилання. either використовується для відправки листа Zombie-комп'ютер або проксі або інфікована вебсторінка. Якщо хакер особливо глупий, він використовує свій власний інтернет-з'єднання для відправлення листа. Як би це не було: у заголовку листа часто міститься IP-адреса відправника і повинна бути записана окремо. незалежно від цього, навіть отримання листа може вважатися приводом. при завантажених вебсторінках, на яких розміщений шкідливий код, реєстрація IP-протоколу у момент кліку посилання нічого не дає.
IP-Spoofing: Атакувальники використовують випадково згенеровані адреси джерела та метадані. Відповіді отримують атакувальники не, їм лише потрібно завдати шкоди жертві шляхом зловісних запитів. Раніше (і сьогодні?) атакувальникам було можливим отримувати відповіді для інших адрес (Backscatter-Attacke).
Відібрані дані доступу: Знання даних доступу робить хакера схожим на справжнього користувача. Такий доступ можна відкрити лише шляхом помітної діяльності або глибшої перевірки, або навіть за вказівкою власника даних доступу. Якщо доступ здійснюється з-за кордону чи з іншого пристрою, ніж раніше було звичайно, то може бути здійснена додаткова перевірка безпеки (CAPTCHA, запит щодо дня народження тощо). Але навіть тоді знання повної IP-адреси не допоможе, принаймні не більше, ніж метадані, які дозволяють більш широкий аналіз.

У досить вільній оглядівці я зібрав кілька видів атак. Види можуть перекриватися (DoS можливо здійснювати як із країни, так і з-за кордону тощо). Таблиця повинна лише надавати загальний уявлення та не є повною.

Тип атаки	Визнання
Надмірно частіше звернення	Конкретна IP-адреса порівняти у пам'яті.
Denial of Service	Конкретна IP-адреса порівняти у пам'яті.
Distributed Denial of Service	Аналізувати скорочені IP-адреси або метадані.
Ввірення шкідливого коду (ін'єкція SQL тощо)	Інформація щодо змісту проти ключових слів та знаків пунктуації перевірити.
Вхід через хакерів (викрадений доступ)	Конкретна IP-адреса в базі даних шукати, коли зберігаються IP-адреси зареєстрованих користувачів або безпосередня реєстрація (Причина = вход)
Напад з-за кордону	Аналізувати метадані, особливо країну, ASN, підсітку.
Напад з території країни	Аналізувати метадані, зокрема ASN, підсітка.
IP-Spoofing	Якщо можливо, перевірити адресу відправника проти відомої вірної адреси мережевого інтерфейсу, що особливо добре працює в локальних мережах. Гляньте на Unicast RPF (це не моє спеціальне царство)

Визнання атак без підставної реєстрації повної адреси IP.

Після визнання або оцінки нападу як вірогідний може відбутися аналіз IP-адрес згідно з причиною, якщо це необхідно для попередження небезпеки.

Якщо адреса IP заблокована через те, що її вважають адресою атакуючого, існують такі ризики:

Адреса насправді не є атакувальником, а була помилково підозрювана (це здається особливо можливим при автоматизованих блокуваннях).
Адреса була фальшивою і належала або іншому (добробутовому) підключенню, або зовсім ні (тоді вплив блокування був би рівним нулю).
Адрес належав нападникові, але тепер йому присвоєно інша (доброзичлива) підключення. Це може відбуватися при динамічних IP-адресах знову і знову, але також при доступі через мережу Tor.
Адреса призначена за допомогою Carrier Grade NAT декільком іншим підключенням. Всі підключення окрім одного потенційно добре проводяться і несподівано блокуються.
Адреса представляє проксі. Коли адреса проксі заблокована, жодна з'єднана система більше не зможе встановити підключення через проксі.

Як бачити, блокування однієї IP-адреси не обов'язково є рішенням усіх проблем, але може навіть збільшувати їх у деяких випадках.

Інші причини, які не є нападами, можуть бути такі:

Тестирувальні цілі, наприклад пошук помилок, оптимізація або розробка нових функцій
Попытки реєстрації за допомогою імені користувача та/або пароля
Введення дивних даних у форму (не обов'язково мова про шкідливий код тут)

На ці події я тут не зупинюся, оскільки мова йде про питання безпідставної реєстрації!

Висновок

Непідставлене протоколування адрес IP для попередження небезпеки здається технічною несуттєвості. Я не бачу жодного підстави для того, щоб це було інакше. Замість повних адрес IP можна реєструвати такі дані:

Адресні області інтернету (також підмережі)
Адресні блоки IP
Псевдонім, як тимчасові цілеві значення, які після короткого часу стають анонімними
Метадані щодо адрес IP:
- Земля
- Поставщик
- АСН
- Ім'я хоста
- Reputation
Метадані щодо з'єднання
- Викликаний цілей (адреса URL тощо)
- Метадані відправника, такі як User-Agent або налаштування кешу
- Час доступу
- Доступність протилежної сторони

Якщо ж є підстава, то цілковита реєстрація адреси IP може бути виправданою. Прикладами таких підстав можуть бути:

Надмірно частіший виклик з боку джерела
Абнормальне поведіннє споживача
Абнормальні звернення (якщо не зовсім звичні параметри URL або відсутні адреси)
Непідозрілі метадані (приклад: доступ із країни Х або підсеті В)
Множинна невідповідність відповіді
Вивчення помилок (Наприклад, власні звернення до системи реєстрування для знаходження мережних помилок)

Є підстави вважати, що різниця в оцінці сценаріїв загрози у малих та великих мережах відповідно до маленьких та великих вебсторінок може мати місце. Але я не можу побачити жодної суттєвої відмінності щодо питання, яке розглядається у цьому матеріалі, і дуже вдячний за будь-які коментарі.

Зауважте, що відправлення повідомлення на форумі не є підставою для створення запису в файлі журналу вебсервера з адресою IP. Натомість ви збережете повідомлення разом із можливою адресою IP відправника у Довіднику.

Вперше я написав, що мова йде лише про власні сервери, а не про провайдерів інтернет-зв'язку (ISPs). Чи ISPs повинні обов'язково та без жодного приводу реєструвати повну IP-адресу для захисту від певних небезпек, я поки що сумнівався навіть тоді, коли вже було відомо, що такі сумніви можуть бути необґрунженими щодо ISP. Точно так же можна сказати про Content Delivery Networks (CDNs). Якщо CDNs реєструють без жодного приводу повні IP-адреси, це повинно бути повідомлено користувачем CDN. Відомо мені від Akamai, що ця реєстрація відбувається без жодного приводу. Тому було заборонено використання служби Cookiebot, яка використовує сервери Akamai.

Виправна реєстрація повних адрес IP серверами для попередження небезпек не потрібна технічними засобами.
Мій рівень знань до моменту підтвердження протилежного.

Якщо ви іншої думки, я бачу дві можливості:

Ви можете назвати конкретне, зрозуміле приклад. У цьому випадку я перевірю цей приклад і зміню свій погляд, якщо ваш приклад це підтвердить.
Ви не зможете назвати конкретний приклад. У цьому випадку ви повинні змінити своє ставлення, хоч би ви цього бажали чи ні, адже таке ставлення було б безпідставним і необґрунтованим.

Будь ласка, напишіть мені, хто знає конкретний приклад, який міг бути важливим для власника сервера. Я знову нагадую, що мова йде про анласову реєстрацію даних, а не реєстрацію даних до певного випадку! Також ні про якість, а про необхідність. Як стикворд можна згадати найменший вплив, який міг бути потрібним. І є багато інших засобів, які можуть бути досить добре підходящими для виявлення або захисту від небезпек, як і IP-адреси, або навіть краще підходящими.

Немає значення користі, а саме необхідність та наявність більш м'яких засобів.
Цей принцип, ймовірно, застосовується в багатьох галузях захисту даних.

Нижче короткий зміст щодо користливості:

Повідомлення	Користуваний?	Необов'язково/Дозволено?
Невідкриття декларації з податків	Так, для всіх, хто не хоче цього	Ні, каже закон
Банківський грабіж	Так, для того, хто потребує грошей	Ні, каже закон
Відеозапис з камери "Дешкам" (з можливістю зберігання)	Так, пізніше довести, що винуватцем аварії був такий-то	Ні, принаймні не постійно (як мені відомо)
Навмисне реєструвати повні IP-адреси	Так, безумовно для багатьох	Ні, стверджую я в цьому матеріалі

Користливість проти необхідності

Так само це не стосується розслідування злочинів, оскільки таке завдання не належить до обов'язків власника сервера та ще менше до обов'язків самого серверу (окрім того, що сервер належить організації, яка має повноваження для проведення слідства).

Мої розмов із фахівцями та запитання в декілька експертних груп соціальної мережі принесли мені хоча б одне приклад, яке міг би використати для спростування моїх поглядів ніхто. А також Бундесверсігурітс-інститут (BSI (German federal security agency)) не зміг мені назвати жодного конкретного прикладу. Замість цього я отримав відповідь з досить невибагливими інформаціями. У ній було згадано, що IP-адреси є особистими даними та слід дотримуватися правових підстав згідно із законодавством ЄС про захист даних (DS-GVO). Всі ці відомості мені вже були знайомі. Крім того, було посилання на компендіум BSI (German federal security agency), в якому теж не було жодного конкретного прикладу (хоча я сподіваюся, що нічого не пропустив).

Якщо ви зберієте повну IP-адресу користувачів свого публічного мережевого інтерфейсу завжди в своїх серверних журналах: зупиніть це миттєво або наведіть конкретний приклад щодо попередження небезпек чи іншого законного приводу, чому цьому дозволено має бути?
Ця вимога звернена до звичайних операторів серверів, а не до ІПС, правоохоронних органів тощо.

Навіть недавно я помітив, що на FTP-сервері клієнта відбувається запис серверного протоколу з повними IP-адресами. Від цього виникла питання, яким чином ця інформація може бути корисна для клієнта. У практиці користь цієї інформації майже наближається до нуля. Клієнт не зможе захистити свій віртуальний сервер від DoS-атак навіть якщо він знав IP-адреси атакуючого. Тож саме стосується часто керованих серверів.

Зауважте, що НДР як відповідальний за вебсайт Tagesschau, згідно з вказівками щодо захисту даних, реєструє повну IP-адресу всіх відвідувачів. Чому це відбувається, не пояснюється. Безумовно, спеціаліст із захистом даних НДР цього не знатиме та/або не розповість.

У своєму окремому матеріалі я присвячую увагу максимально допустимій тривалості зберігання файлів журналів вебсторінок.