Меня это интересует в контексте защиты веб-приложения от ботов, но я предполагаю, что это применимо ко всем видам атак, которые могут быть выполнены ботами через IPv6.
В веб-приложении у вас есть страницы, которые нужно защитить от ботов.
Это может быть страница входа: вы хотите избежать миллионов запросов, пытающихся использовать комбинации имени пользователя и пароля.
Это может быть страница регистрации. Вы же не хотите, чтобы на вашем сайте создавались тысячи учетных записей ботов.
Или, может быть, вы не хотите, чтобы все содержимое вашей базы данных загружалось сразу. Вы думаете, что анонимный пользователь может делать 100 или 200 запросов в день к вашей базе данных, чтобы получить некоторую информацию, но вас не устраивает, что боты загружают весь контент, который вы предлагаете, выполняя 1000 запросов в минуту.
Или просто для статистических целей. Вы регистрируете активность посетителей на своем сайте и не хотите, чтобы боты полностью искажали ваши данные, например, искусственно нажимая ссылку тысячи раз, чтобы статья, на которую она ссылается, стала «самой популярной статьей» на вашем новостном сайте. .
Я часто обрабатывал это, используя дросселирование / ограничение скорости на основе IP-адресов, используя возможности ограничения скорости Nginx:
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/m;
server {
location /sensitiveUrl {
limit_req zone=mylimit;
proxy_pass http://my_upstream;
}
}
Но с IPv6 я не уверен, насколько это эффективно. Я имею в виду, что с IPv4 он относительно эффективен, потому что злоумышленникам дорого создавать и использовать тысячи IP-адресов, но кажется, что с IPv6 любой может создать миллионы IP-адресов. Как с этим справиться? Следует ли применять ограничения в сетях IPv6 вместо адресов? Насколько эффективно это было бы на практике, если бы я сделал это?
Гибкость IPv6 с адресацией велика, но она действительно усложняет подобные вещи. Алгоритм, который я бы порекомендовал:
/128). Это может быть один пользователь в сети с несколькими пользователями, и вы хотите избежать блокировки невинных пользователей (что происходит с IPv4 постоянно из-за NAT, давайте не будем повторять это)x блоки внутри того же /64, предположим, что весь /64 испорчен и заблокировал все это. Теперь вы можете удалить индивидуальный /128 записи из вашего черного списка, потому что теперь они включены в /64. Это предотвращает переполнение памяти / хранилища вашей системы черного списка./64. Размер по умолчанию - /48, но /56 и даже /60 (что слишком мало для IPv6, но некоторые интернет-провайдеры никогда не узнают). Я бы увеличил масштаб на 4 бита: если несколько /64с того же /60 заблокированы, увеличьте масштаб, чтобы заблокировать весь /60. То же самое с несколькими /60 в /56 и т.п./64 чем "случайно" получить целую /48 заблокирован. ИМХО, блоки большего размера заслуживают более длительного времени в черном списке./48 с самого начала, поэтому алгоритм масштабирования не запускается быстро. Поэтому для быстрого масштабирования может потребоваться одновременное выполнение нескольких условий.Примером такого механизма масштабирования может быть:
+---------------+----------------------------------------+-----------+
| | Block when containing >= of these: | Blacklist |
| Prefix length | /128 | /64 | /60 | /56 | /52 | time |
+---------------+--------+-------+-------+-------+-------+-----------+
| /128 | N/A | N/A | N/A | N/A | N/A | 5 min |
| /64 | 5 | N/A | N/A | N/A | N/A | 15 min |
| /60 | 15 | 2 | N/A | N/A | N/A | 30 min |
| /56 | 50 | 4 | 2 | N/A | N/A | 60 min |
| /52 | 75 | 8 | 4 | 2 | N/A | 120 min |
| /48 | 100 | 16 | 8 | 4 | 2 | 240 min |
+---------------+--------+-------+-------+-------+-------+-----------+