Уязвимость ядра Linux CVE-2016-5696, раскрытая на прошлой неделе, затрагивает множество устройств, и сетевой администратор может не иметь root-доступ ко всем из них (если они принадлежат клиенту или в случае Android, root-права принадлежат производителю). а не хозяин). Неразумно думать, что исправления появятся в ближайшее время для всех этих устройств, а без рута невозможно даже увеличить глобальный лимит скорости для смягчения побочного канала.
Однако атака полагается на возможность злоумышленника намеренно инициировать несколько пакетов ACK-запроса обратно себе, чтобы увидеть, приводит ли тот, что на поддельном соединении, к достижению предела. Если бы пограничный брандмауэр ограничил количество пакетов ACK-запроса, возвращаемых злоумышленнику, до меньшего числа, чем ограничение на атакуемое устройство, утечка информации была бы перекрыта.
Например, если для уязвимого устройства установлено глобальное ограничение скорости по умолчанию, равное 100, то реализация ограничения скорости для каждого узла в 20 на граничном маршрутизаторе не позволит внешнему злоумышленнику выполнить атаку вне пути, даже если устройство и брандмауэр синхронизируют не синхронизированы (лучшее, что может сделать злоумышленник, - это 20 в конце одной секунды, за которыми сразу следует 40 в следующую, что намного меньше 100, на отправку которых настроено атакуемое устройство). Локальные устройства по-прежнему могут обмениваться данными без ограничения скорости.
Как реализовать такое смягчение последствий с помощью iptables на брандмауэре Linux с ядром версии 4.x? Какие пакеты должны быть сопоставлены, какие модули будут отслеживать скорость на каждом узле и разрешать ограничение?
Можно ли обнаружить продолжающуюся атаку, подсчитав пакеты ACK (достаточно ли у межсетевого экрана информации, чтобы их различить?), А затем заблокировать злоумышленника? (Вероятно, этого нельзя было сделать с использованием только iptables, но с помощью генератора реактивных правил)
Обнаружение пакетов ACK запроса может быть предварительным условием, чтобы не блокировать пакеты ACK, приходящие от истинного однорангового узла.
Можно ли уменьшить опасность CVE-2016-5696, используя брандмауэр периметра?
Возможно нет. По крайней мере, я не ожидал, что какие-либо производители брандмауэров официально поддержат какую-либо форму защиты от этого. Слишком много сценариев, в которых ложные срабатывания приводят к блокировке легального трафика.
Лучшее, что вы могли бы сделать, это обновить конфигурацию на своих серверах или запустить одну команду при запуске, пока у вас не будет исправленного ядра. Уязвимость возникает из-за того, что Linux подтверждает RFC, которому никто другой не соответствует.
Чтобы предотвратить такое поведение, обновите все свои серверы. /etc/sysctl.conf с участием:
net.ipv4.tcp_challenge_ack_limit = 131070
Тогда беги sysctl -e -p на всех серверах, к которым вы применили этот параметр.
Если вы планируете в ближайшее время обновить ядро, вы можете просто запустить:
sysctl -w "net.ipv4.tcp_challenge_ack_limit=131070"
так что вам не нужно менять файлы конфигурации.
Почему 131070? Все, что больше 1000, было бы достаточно, если бы ядро было обновлено с рандомизацией. Патч к ядру устанавливает число 1000 и добавляет рандомизацию для смягчения сценария атаки. Без рандомизации вам нужно гораздо большее число. Я видел, как некоторые люди использовали 9 миллионов.
[Обновление] Подводя итоги: судя по вашим комментариям, брандмауэр периметра вряд ли вам поможет. Прокси уровня 4 по периметру будет. Я бы серьезно прочитал о haproxy.
Я не совсем уверен, насколько реально беспокоиться об этой уязвимости в управляемой сети по нескольким причинам, которые я могу придумать.
* Конечно, все еще возможно, что Боб пытается атаковать устройства DoS в локальной сети, однако этот трафик все равно не будет проходить через брандмауэр.
Ничего не стоит то, что Challenge ACK - это просто ACK с определенными порядковыми номерами, поэтому вам, вероятно, потребуется реализовать настраиваемое отслеживание / синтаксический анализ пакетов на вашем брандмауэре, чтобы выбрать их. Звучит симпатично.