В настоящее время я привык использовать такие инструменты, как fail2ban, чтобы убрать нежелательный трафик с моих серверов, запретив адреса IPv4: слишком много плохих записей в журнале на IP, запретить IP.
Однако, когда мир завершит переход на IPv6, запрет отдельных адресов, вероятно, больше не будет работать, поскольку «нормальный» ботнет-компьютер или злоумышленник обладает довольно большим количеством IPv6-адресов?
Если я хочу заблокировать пользователей IPv6, как лучше всего это сделать? Использовать определенную маску IP или что-то еще?
Как насчет выполнения «эвристики апскейлинга», когда вы получаете несколько отдельных обращений внутри IPv6, а затем блокируете весь блок?
Для меня важнее минимизировать угрозу. Если некоторые плохие подлинные пользователи принадлежат к одному блоку с заблокированными IP-адресами, то проблема между этими людьми и их провайдером - очистить этот сетевой блок.
Любой ответ на ваш вопрос потребует некоторого количества предположений. Развертываний IPv6 все еще недостаточно, поэтому мы просто еще не знаем, как именно будет выглядеть сценарий угрозы.
Большое количество адресов IPv6 приведет к множественным изменениям в сценарии угроз, который вам придется учитывать.
Во-первых, с IPv4 злоумышленник вполне может просканировать номер порта по умолчанию для какой-либо уязвимой службы по всем 3700 миллионам маршрутизируемых IPv4-адресов. Такие нецелевые атаки невозможны с IPv6. Те атаки, которые вы все еще наблюдаете, должны быть более целенаправленными. Будет ли это означать, что нам придется многое изменить в нашем подходе к атакам, еще неизвестно.
Основная цель запрета IP-адресов на основе сообщений журнала - уменьшить шум в журналах и до некоторой степени снизить нагрузку на систему. Это не должно служить защитой от эксплойтов. Злоумышленник, который знает слабость, будет внутри до того, как сработает бан, поэтому для защиты от этого вы должны исправить уязвимости - как и всегда.
Для уменьшения шума в журналах может быть достаточно запрета отдельных адресов IPv6. Но это не дано. Не исключено, что злоумышленник может использовать новый IP-адрес из доступного им диапазона для каждого соединения. Если злоумышленники будут вести себя подобным образом, запрет отдельных IPv6-адресов не только будет неэффективным, но и вы можете даже непреднамеренно вызвать DoS-атаку на себя, используя всю свою память для правил брандмауэра.
Вы не можете знать длину префикса, доступного каждому атакующему. Блокировка слишком короткого префикса вызовет DoS-атаку, в том числе и законных пользователей. Блокировка слишком длинного префикса будет неэффективной. В частности, попытки подбора пароля могут использовать большое количество клиентских IPv6-адресов.
Чтобы эффективно противостоять злоумышленникам, переключающим IPv6-адрес при каждом запросе, и для снижения использования памяти, вы должны блокировать диапазоны, а из-за того, что заранее не знаете длину префикса, вы должны динамически регулировать длину префикса.
Уже сейчас можно придумать эвристику. Насколько хорошо они будут работать, мы пока не знаем.
Одна эвристика будет для каждой длины префикса, чтобы определить порог количества IP-адресов, необходимых для блокировки префикса этой длины. И блокировку следует применять только на определенной длине, если более длинного префикса недостаточно. Другими словами, вам нужно достаточное количество индивидуально заблокированных IP-адресов в каждой из двух половин, чтобы фактически инициировать блокировку.
Например, можно решить, что для блокировки / 48 необходимо 100 заблокированных IP-адресов в каждом из двух / 49, составляющих / 48. Чем длиннее префикс, тем меньшее количество IP-адресов, необходимых для его блокировки, должно быть, но в любом случае они должны быть распределены по обеим половинам.
Запрет на / 128 не масштабируется, если для атаки используется подсеть размером / 64. В итоге вы получите 2 ^ 64 записей в таблице, что может вызвать отказ в обслуживании.
Конечные пользователи всегда будут получать / 56 за политику назначения глобального адреса. Компании всегда будут получать / 48 на глобальный адрес.
Видеть: https://tools.ietf.org/html/rfc6177 / 128 никогда не следует назначать серверу / пользователю, минимальное назначение другому объекту (клиенту сервера / vps) должно быть / 64. Минимальное назначение сайту должно быть / 56. Выдача / 128s принципиально нарушена и должна считаться ошибкой конфигурации.
Поэтому я рекомендую временный запрет на / 64, учитывая, что типичный конечный пользователь будет иметь доступ только к 2 ^ 8 / 64s, это не должно вводить слишком много записей в таблице запрета.
Вам следует придерживаться запрета на отдельные адреса.
Не определено, сколько адресов будет отдано конечным пользователям. Некоторые интернет-провайдеры могут давать целую подсеть, а другие - только один адрес.