В первой части обзора CentOS 7 было рассказано о поддержке контейнеров Linux в Cent OS 7. Во второй части мы поговорили об управлении идентификацией. В третья части обзора мы коснулись сетевой файловой системы NFS и ее окружению. В этой статье поговорим о смягчении DDoS атак TCP SYN Flood. В конце поста ссылка на бесплатное тестирование CentOS 7 в облачной VPS от Infobox.
DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.
Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.
Основная проблема масштабируемости TCP для ядра Linux связана с тем, как много новых соединений могут быть созданы за секунду. Это относится к блокировке на сокет в состоянии «listen» (прослушивания). «Estabilished» (Установленные) соединения масштабируются очень хорошо. Блокировка состояния «listen» встречается не только с SYN–пакетами, но и другими пакетами для первоначального подключения «SYN-ACK» и «ACK» (пакеты тройного рукопожатия в TCP). В сценарии атаки флудом нам необходим механизм фильтрации фейковых попыток подключения до того, как сокет войдет в состояние «listen» и блокирует новые входящие соединения.
Используя систему отслеживания соединений в Netfilter (conntrack), мы можем начать фильтрацию ложных SYN-ACK и ACK пакетов до того, как они вызовут блокирующее состояние «listen». Это было возможно уже долгое время, но не было включено по умолчанию.
Вам помогут следующие две команды:
Правило для iptables будет отлавливать пакеты, которые система отслеживания соединений классифицировала как «INVALID» и не являющихся частью известных состояний соединения.
Настройка sysctl сделает систему отслеживания соединений более строгой в категоризации и поможет уклониться в том числе от атак ACK–flood.
В результате мы в 20 раз уменьшим влияние атак, основанных на SYN–ACK и ACK.
Conntrack в Netfilter имеет плохую репутацию за низкую скорость работы, но так было в первое время после появления технологии. Сейчас она предлагает превосходную масштабируемость и работает очень быстро. Conntrack работает без локов, используя RCU (обновление через копирование) для существующих соединений.
По сути это предотвратит проблемы от всех флудящих пакетов TCP, кроме SYN.
В conntrack есть проблема масштабируемости (похожая на блокировку «listen»), возникающую, когда речь идет о создании (или удалении) соединений, которую вызывает SYN флуд.
Даже после настройки contrack SYN пакеты будут отправлены сокету вызывая блокировку «listen». Методика смягчения этой атаки — отправить SYN–куки и предотвратить создание любого статуса, пока SYN–ACK не будет виден.
К сожалению SYN–куки, отправляются под той же блокировкой «listen», поэтому такое смягчение не решит проблему масштабируемости. Чуть позже мы обсудим, как обойти это ограничение.
На Netfilter Workshop 2013 была предложена идея «сетевых контрмер». Это дало рождение модулю iptables «SYNPROXY» и соответствующим изменениям в ядре Netfilter. Теперь эта функциональность доступна в CentOS 7.
Модуль SYNPROXY предназначен для решения двух проблем с масштабируемостью. Во-первых работает с SYN–куками параллельно. Во-вторых, он не создает conntrack до получения пакета SYN–ACK, что позволяет conntrack не блокировать новые соединения.
SYNPROXY может быть использован на локальном хосте или может защищать другие хосты за файрволом. Как только первоначальное соединение установлено, conntrack возьмет на себя все необходимые трансляции (повторно использовав части кода NAT).
Тестирование на соединениях к localhost показали 10-и кратный рост производительности по смягчению SYN–атак.
Настройка SYNPROXY может быть достаточно сложной без руководства. В этой статье рассмотрены необходимые шаги, однако вы можете использоват0 и скрипт для упрощения настройки.
Этот пример может быть использован для защиты веб-сервера на 80 порту.
Убедитесь, что соединения, которые мы защищаем, не создают conntrack для SYN пакетов.
Включим более строгий conntrack. Это необходимо чтобы иметь INVALID статус для плохих ACK пакетов.
Теперь нам необходимо обрабатывать эти пакеты и передавать их напрямую в модуль SYNPROXY. Чтобы это сделать, используйте правило обработки UNTRACKED SYN и INVALID пакетов, которые содержат ACK от тройного рукопожатия (и других, но они просто будут проходить через это правило):
Поймайте пакеты с состоянием INVALID, которые попали в SYNPROXY и уничтожьте их. Это предотвратит флуд SYN–ACK.
Не забудьте включить временные метки TCP. SYN–куки используют это поле TCP.
Если у вас нагруженный сайт, рекомендуется настроить conntrack для увеличения лимита в 64 тысячи подключений. Так же увелитьте размер хеша conntrack. Это очень важно для производительности.
Необходимо устанавливать значение лимитов, актуальное для вашего сайта и посчитать использование памяти для него. Например, 2 000 000 записей за раз по 288 байт = максимум 576 Мб потенциального использования памяти. Для хеша, каждая голова хеш-таблицы занимает только 8 байт на миллион записей = 8 Мб фиксированной выделенной памяти (помните размер вашего кеша L3 у CPU, когда выбираете значение кеша). Узнать, какой процессор используется на хосте можно командой:
Включение SYNPROXY может не пройти незаметно. Установка соединений будет проходить медленнее в связи с дополнительной настройкой соединения, необходимого конечному хосту. Когда конечный хост локальный, все происходит очень быстро и практически не добавляет задержек.
Параметры модуля SYNPROXY должны соответствовать опциям TCP и должны поддерживаться конечным хостом, для которого TCP соединение проксируется. Обнаружение и настройка производится вручную на основе правил (полезный инструмент «nfsynproxy» – часть релиза iptables 1.4.21). К сожалению это означает, что модуль не может быть просто развернуть на DHCP файрволы.
В будущем есть планы по авто-обнаружению опций TCP конечных хостов. Голосуйте за фичу в баг-трекере Red Hat.
Использованные в подготовке статьи источники:
Mitigate TCP SYN Flood Attacks
Oфициальный блог RedHat
База знаний RedHat
Официальный блог CentOS
Специально для наших читателей мы обеспечили возможность попробовать CentOS 7 на облачной VPS от Infobox в Амстердаме. Регистрируйте пробную версию на 15 дней по этой ссылке. Если вам нужно больше ресурсов для тестирования, чем в пробной версии — напишите на trukhinyuri@infoboxcloud.com
DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.
Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.
Почему SYN-flood — боль для ядра
Основная проблема масштабируемости TCP для ядра Linux связана с тем, как много новых соединений могут быть созданы за секунду. Это относится к блокировке на сокет в состоянии «listen» (прослушивания). «Estabilished» (Установленные) соединения масштабируются очень хорошо. Блокировка состояния «listen» встречается не только с SYN–пакетами, но и другими пакетами для первоначального подключения «SYN-ACK» и «ACK» (пакеты тройного рукопожатия в TCP). В сценарии атаки флудом нам необходим механизм фильтрации фейковых попыток подключения до того, как сокет войдет в состояние «listen» и блокирует новые входящие соединения.
Основы фильтрации conntrack
Используя систему отслеживания соединений в Netfilter (conntrack), мы можем начать фильтрацию ложных SYN-ACK и ACK пакетов до того, как они вызовут блокирующее состояние «listen». Это было возможно уже долгое время, но не было включено по умолчанию.
Вам помогут следующие две команды:
iptables -A INPUT -m state --state INVALID -j DROP
/sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0
Правило для iptables будет отлавливать пакеты, которые система отслеживания соединений классифицировала как «INVALID» и не являющихся частью известных состояний соединения.
Настройка sysctl сделает систему отслеживания соединений более строгой в категоризации и поможет уклониться в том числе от атак ACK–flood.
Что с производительностью?
В результате мы в 20 раз уменьшим влияние атак, основанных на SYN–ACK и ACK.
Conntrack в Netfilter имеет плохую репутацию за низкую скорость работы, но так было в первое время после появления технологии. Сейчас она предлагает превосходную масштабируемость и работает очень быстро. Conntrack работает без локов, используя RCU (обновление через копирование) для существующих соединений.
По сути это предотвратит проблемы от всех флудящих пакетов TCP, кроме SYN.
Почему это не работает с SYN-flood?
В conntrack есть проблема масштабируемости (похожая на блокировку «listen»), возникающую, когда речь идет о создании (или удалении) соединений, которую вызывает SYN флуд.
Даже после настройки contrack SYN пакеты будут отправлены сокету вызывая блокировку «listen». Методика смягчения этой атаки — отправить SYN–куки и предотвратить создание любого статуса, пока SYN–ACK не будет виден.
К сожалению SYN–куки, отправляются под той же блокировкой «listen», поэтому такое смягчение не решит проблему масштабируемости. Чуть позже мы обсудим, как обойти это ограничение.
Что нового в CentOS 7
На Netfilter Workshop 2013 была предложена идея «сетевых контрмер». Это дало рождение модулю iptables «SYNPROXY» и соответствующим изменениям в ядре Netfilter. Теперь эта функциональность доступна в CentOS 7.
Модуль SYNPROXY предназначен для решения двух проблем с масштабируемостью. Во-первых работает с SYN–куками параллельно. Во-вторых, он не создает conntrack до получения пакета SYN–ACK, что позволяет conntrack не блокировать новые соединения.
SYNPROXY может быть использован на локальном хосте или может защищать другие хосты за файрволом. Как только первоначальное соединение установлено, conntrack возьмет на себя все необходимые трансляции (повторно использовав части кода NAT).
Тестирование на соединениях к localhost показали 10-и кратный рост производительности по смягчению SYN–атак.
Настройка SYNPROXY
Настройка SYNPROXY может быть достаточно сложной без руководства. В этой статье рассмотрены необходимые шаги, однако вы можете использоват0 и скрипт для упрощения настройки.
Этот пример может быть использован для защиты веб-сервера на 80 порту.
Шаг 1
Убедитесь, что соединения, которые мы защищаем, не создают conntrack для SYN пакетов.
iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn --dport $PORT -j CT --notrack
Шаг 2
Включим более строгий conntrack. Это необходимо чтобы иметь INVALID статус для плохих ACK пакетов.
/sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0
Шаг 3
Теперь нам необходимо обрабатывать эти пакеты и передавать их напрямую в модуль SYNPROXY. Чтобы это сделать, используйте правило обработки UNTRACKED SYN и INVALID пакетов, которые содержат ACK от тройного рукопожатия (и других, но они просто будут проходить через это правило):
iptables -A INPUT -i $DEV -p tcp -m tcp --dport $PORT -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
Шаг 4
Поймайте пакеты с состоянием INVALID, которые попали в SYNPROXY и уничтожьте их. Это предотвратит флуд SYN–ACK.
iptables -A INPUT -m state --state INVALID -j DROP
Шаг 5
Не забудьте включить временные метки TCP. SYN–куки используют это поле TCP.
/sbin/sysctl -w net/ipv4/tcp_timestamps=1
Шаг 6
Если у вас нагруженный сайт, рекомендуется настроить conntrack для увеличения лимита в 64 тысячи подключений. Так же увелитьте размер хеша conntrack. Это очень важно для производительности.
echo 1000000 > /sys/module/nf_conntrack/parameters/hashsize
/sbin/sysctl -w net/netfilter/nf_conntrack_max=2000000
Необходимо устанавливать значение лимитов, актуальное для вашего сайта и посчитать использование памяти для него. Например, 2 000 000 записей за раз по 288 байт = максимум 576 Мб потенциального использования памяти. Для хеша, каждая голова хеш-таблицы занимает только 8 байт на миллион записей = 8 Мб фиксированной выделенной памяти (помните размер вашего кеша L3 у CPU, когда выбираете значение кеша). Узнать, какой процессор используется на хосте можно командой:
cat /proc/cpuinfo
Соображения по использованию SYNPROXY
Включение SYNPROXY может не пройти незаметно. Установка соединений будет проходить медленнее в связи с дополнительной настройкой соединения, необходимого конечному хосту. Когда конечный хост локальный, все происходит очень быстро и практически не добавляет задержек.
Параметры модуля SYNPROXY должны соответствовать опциям TCP и должны поддерживаться конечным хостом, для которого TCP соединение проксируется. Обнаружение и настройка производится вручную на основе правил (полезный инструмент «nfsynproxy» – часть релиза iptables 1.4.21). К сожалению это означает, что модуль не может быть просто развернуть на DHCP файрволы.
В будущем есть планы по авто-обнаружению опций TCP конечных хостов. Голосуйте за фичу в баг-трекере Red Hat.
Использованные в подготовке статьи источники:
Mitigate TCP SYN Flood Attacks
Oфициальный блог RedHat
База знаний RedHat
Официальный блог CentOS
Попробуйте CentOS 7 в облаке
Специально для наших читателей мы обеспечили возможность попробовать CentOS 7 на облачной VPS от Infobox в Амстердаме. Регистрируйте пробную версию на 15 дней по этой ссылке. Если вам нужно больше ресурсов для тестирования, чем в пробной версии — напишите на trukhinyuri@infoboxcloud.com
