Получился довольно ироничный заголовок. Дело в том, что если взять ElasticSearch и проанализировать подозрительную активность на больших объемах, то почти наверняка попытки взлома этого самого ElasticSearch будут в лидерах :)
В статьи мы оперируем обращениями к веб-серверу. Поэтому если на вашем сайте нет JS, который каждые 5 минут пингует сервер, то скорей всего ваша единожды открытая вкладка будет интерпретирована как одно обращение к сайту, не зависимо от того, сколько времени она была открыта.
Не думаю, что есть какие-то серьезные проблемы в применение это подхода к IPv6 адресам.
Если Вы считаете иначе, пожалуйста уточните, что именно Вас смущает?
То что по спецификации провайдеру рекомендуется выдавать клиентам подсеть /64, но какую именно он выдаёт подсеть /64 /90 или какую другую не факт что можно определить.
Хм. Я могу сильно заблуждаться, но разве правило блокировки входящего трафика из подсети должно точно соответствовать реальной подсети провайдера? Что плохого случиться, если мы заблокируем только часть подсети провайдера?
Я перечитал статью и понял вас.
Блокировать витуальные подсети (а Netrisk реальные сети не знает, а просто сегментирует по количеству байт) для IPv4 — ещё куда ни шло, но в IPv6 их будет уж очень много. И есть подозрение, что блокировка по IP для IPv6 будет большой нагрузкой на мощности.
Как Elasticsearch может помочь в поиске подозрительной активности на сайте