Syn cookies что это
Stable IT
FastNetMon
Wednesday, 24 December 2014
Как работает механизм SYN Cookie в ядре Linux?
Уверен, многие в своей ежедневной практике используют механизм syn cookie, который позволяет решать проблемы с syn флудом.
Как известно, эта фича включается так:
Но когда именно они включаются? Как работают? Всегда ли это панацея? На эти вопросы я постараюсь ответить ниже.
Вся обработка входящего tcp соединения начинается в файле net/ipv4/tcp_input.c в функции tcp_conn_request. Там сразу после приема пакета осуществляется следующая проверка:
Обращаю внимание! Что syn cookie еще НЕ был отправлен! Даже если он был включен на какой-то из предыдущих проверок.
Как хорошее и надежное решение данной проблемы стоит использовать iptables/netfilter цель SYN PROXY, которая блокирует syn флуд раньше, чем они пойдет в обработку ядром (на этапе фильтрации через netfilter). Но тут стоит отметить, что данный функционал был добавлен в 3.12 ядре и присутствует только в RHEL/CentOS 7, в более младших версиях дистрибутивов такой возможности нету и вряд ли появится.
Но я бы хотел добавить, что syn cookie должны быть ВКЛЮЧЕНЫ в обязательном порядке. Вообще без них Linux упадет от самой слабой атаки syn флудом.
В чем же отличия 1 и 2го режимов syn cookie? В первом режиме они подключаются, когда переполняется очередь syn соединений на 1 порт, а во втором режиме они включаются безусловно даже очередь пуста. То есть для ВСЕХ соединений.
Укрепление стека TCP/IP для защиты от SYN атак
В то время как невозможно полностью предотвратить SYN атаки, настройка TCP/IP стека помогает уменьшить влияние этого вида атак, при этом все еще разрешая легальный клиентский трафик через сервер. Необходимо отметить, что некоторые SYN атаки не всегда пытаются «положить» серверы, вместо этого они пытаются потребить всю пропускную способность вашего Internet канала.
Что может сделать администратор, когда его серверы подвергаются классической (не использующей заполнения пропускной способности интернет-канала), SYN атаке? Одним из наиболее важных шагов является включение встроенных в операционную систему механизмов защиты, таких как SYN cookies или SynAttackProtect. Дополнительно, в некоторых случаях, необходима настройка параметров TCP/IP стека. Изменение заданных по умолчанию значений стековых переменных, является уже другим уровнем защиты и помогает нам лучше защитить наши хосты. В этой статье мы сконцентрируем наше внимание на:
Этот метод выполняется с помощью уменьшения времени первой повторной передачи пакета или уменьшения (вплоть до полного отключения) количества повторных передач пакета. Процесс повторной передачи пакета выполняется сервером, до получения от клиента ACK пакета. Пакет с флагом ACK завершает процесс установления соединения между сервером и клиентом.
Необходимо обратить внимание на то, что нападающий может посылать большее количество пакетов с флагом SYN, и тогда вышесказанные операции не смогут решить эту проблему. Однако их выполнение может увеличить вероятность создания полного подключения с легальными клиентами.
Также необходимо помнить, что модификация переменных, изменит режим работы стека TCP/IP. Так, после модификации, мы должны удостовериться, что сервер может должным образом связываться с другими хостами. Например, отключение повторных передач пакета в некоторых системах низкой пропускной способностью, может привести к отказу в работе при легальных запросах. В этой статье можно найти описание TCP/IP переменных для следующих операционных систем: Microsoft Windows 2000, RedHat Linux 7.3, Sun Solaris 8 и HP-UX 11.00.
Определения: SYN атака и SYN спуфинг.
Для увеличения эффективности SYN атаки, злоумышленник использует фиктивные IP адреса в SYN пакетах. В этом случае хост жертвы не может быстро закончить процесс инициализации, потому что исходный IP адрес может быть недостижим. Эта злонамеренная операция называется SYN спуфингом.
Обнаружение SYN атак
Обнаружить SYN атаку очень легко. Команда netstat показывает нам количество подключений находящихся в полуоткрытом состоянии. Полуоткрытое состояние описано как SYN_RECEIVED в Windows и как SYN_RECV в Unix системах.
Мы можем также подсчитать количество полуоткрытых подключений находящихся в очереди в настоящее время. В приведенном ниже примере, 769 подключений (для TELNET) находящихся в состоянии SYN RECEIVED сохраняются в очереди задач.
* netstat-n-p TCP | grep SYN_RECV | grep:23 | wc-l
Другой метод обнаружения SYN атак состоит в распечатке статистики TCP и просмотре параметров TCP, подсчитывающих количество отклоняемых запросов. Во время атаки значения этих параметров быстро возрастают.
В этом примере мы пронаблюдаем за значением параметра TcpHalfOpenDrop на системе Sun Solaris.
* netstat-s-P tcp | grep tcpHalfOpenDrop
Важно обратить внимание на то, что каждый tcp порт имеет свою собственную очередь соединений, но только одна переменная стека tcp/IP управляет размером этой очереди для всех портов.
Очередь соединений
Как упомянуто выше, обнаружение большого количества соединений в состоянии SYN RECEIVED скорее всего означает, что хост подвергся SYN атаке. Кроме того, исходные IP адреса, этих пакетов могут быть фиктивными. Для ограничения эффективности SYN атак мы должны включить некоторые встроенные защитные механизмы. Иногда мы также можем использовать методы типа увеличения размера очереди соединений и уменьшения времени хранения незавершенных соединений в распределяемой памяти (в очереди соединений).
Встроенные механизмы защиты
Операционная система: Windows 2000
Наиболее важным параметром в Windows 2000 и в Windows Server 2003 является параметр SynAttackProtect. Включение этого параметра позволяет операционной системе более эффективно обрабатывать поступающие соединения. Защита может быть установлена, путем добавления значения SynAttackProtect, типа DWORD, в следующий ключ системного реестра:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
В случае обнаружения SYN атаки, параметр SynAttackProtect изменяет режим работы стека TCP/IP, что позволяет операционной системе обрабатывать большее количество SYN запросов. Принцип работы заключается в отключении некоторые опций сокета, добавлении дополнительных задержек к показаниям соединения и изменении тайм-аута для запросов.
Как мы можем увидеть, включение параметра SynAttackProtect не изменяет режим работы стека TCP/IP до и при SYN атаке. Но даже при включенном параметре SynAttackProtect, операционная система может обрабатывать легальные поступающие соединения.
Операционная система автоматически включает защиту от SYN атак, когда обнаруживает превышение значений следующих трех параметров: TcpMaxHalfOpen, TcpMaxHalfOpenRetried и TcpMaxPortsExhausted.
Чтобы изменить значения этих параметров, сначала мы должны добавить их к тому же самому ключу системного реестра, как и в случае с SynAttackProtect.
Операционная система: Linux RedHat
В RedHat, как и в других Linux системах, осуществлен механизм SYN cookies, который включается следующим способом:
* ECHO 1 >/proc/sys/net/ipv4/tcp_syncookies
Обратите внимание, что для того чтобы сделать это изменение постоянным, мы должны создать загрузочный файл, который будет присваивать значение этой переменной. Мы должны проделать ту же самую операцию и для других UNIX переменных, описанных в этой статье, потому что значения этих переменных после перезагрузки системы вернуться к прежним значениям.
Также необходимо обратить внимание на то, что механизм SYN cookies работает только когда опция CONFIG_SYNCOOKIES установлена в ходе компиляции ядра системы.
В следующем разделе будут описаны другие полезные методы защиты от SYN атак. Я хотел бы подчеркнуть, что при более сложных видах SYN атак, эти методы могут помочь, но не решить проблему.
Увеличение размера очереди соединений
При SYN атаке, мы можем изменить размер очереди задач для поддержки большего количества полуоткрытых соединений так, чтобы не отклонять доступ к серверу легальным клиентам. В некоторых операционных системах, размер очереди задач очень маленький, поэтому производители рекомендуют увеличение этого значения, в случае если система подверглась SYN атаке.
Увеличение размера очереди задач требует, чтобы система резервировала дополнительные ресурсы памяти для входящих соединений. Если в системе отсутствует достаточное количество свободной памяти для этой операции, то пострадает производительность системы. Также мы должны удостовериться, что сетевые приложения (Apache, IIS и т.д.) смогут принимать большее количество подключений.
Операционная система: Windows 2000
Кроме описанных выше переменных TcpMaxHalfOpen и TcpMaxHalfOpenRetried, в Windows 2000 количество полуоткрытых подключений может быть установлено через динамическую очередь соединений. Конфигурирование этой очереди выполняется через драйвер AFD.SYS. Этот драйвер используется для поддержки Windows Socket приложений (FTP, Telnet и т.д.). Для увеличения количества полуоткрытых соединений, AFD.SYS поддерживает четыре элемента системного реестра. Все эти значения расположены в следующем ключе системного реестра:
Значение MaximumDynamicBacklog определяет сумму активных полуоткрытых соединений и максимального количества свободных соединений. Если это значение будет превышено, то система больше не будет создавать свободные соединения. Рекомендованное значение не должно превышать 20000.
Последний параметр DynamicBacklogGrowthDelta управляет количеством свободных соединений, создаваемых в случае необходимости. Рекомендуемое значение: 10.
Ниже расположена таблица, показывающая рекомендуемые значения для драйвера AFD.SYS:
SYN файлы cookie
Оглавление
Установление соединения с TCP
Расширение для включения файлов cookie SYN
Протокол управления передачей (TCP) не определяет начальное значение номера последовательности пакетов SYN / ACK. Таким образом, сервер может использовать его для кодирования информации, которую в противном случае пришлось бы хранить в таблице полуоткрытых TCP-соединений. Поскольку таблица полуоткрытых соединений не используется с активными файлами cookie SYN, эта таблица не может быть заблокирована, что означает ослабление атаки SYN flood.
Детально можно применить следующие правила:
Сервер отправляет свой пакет SYN / ACK со специально сгенерированным порядковым номером. Однако, согласно спецификации TCP, этот порядковый номер ограничен 32 битами и может быть сгенерирован следующим образом:
В деталях, после уменьшения размера пакета на сервере происходит следующее:
Поскольку настройка соединения проверяется на сервере, хеш-функция реализации может быть определена произвольно; однако он должен быть как можно более случайным, чтобы избежать угроз безопасности. Эта процедура выполняется прозрачно для клиента, поэтому соединения между удаленными станциями могут быть установлены независимо от того, используют ли они файлы cookie SYN.
Содержание начального порядкового номера
Хеш-функция не указана в соответствующем RFC 4987 и поэтому может быть выбрана произвольно.
Преимущества и недостатки использования файлов cookie SYN
Так или иначе любой провайдер сталкивается с проблемами DDOS атак на свои ресурсы либо, что менее приятно, со своих ресурсов. Когда в нашей компании Beget.com встала задача прозрачной фильтрации трафика на конечные сервера, мы написали свое решение Syncookied, которое изначально предполагалось только для защиты от syn, ack, data flood, но потом переросло в достаточно большую и обширную систему по защите от разного типа атак. Данным решением мы бы хотели поделиться со всем сообществом, так как на текущий момент аналогов ему мы не нашли (или мы о них не знаем). Есть платные решения, но стоят они очень дорого.
Вначале хотелось бы выразить свое мнение о лицах, которые организуют DDOS. Вместо того, чтобы конкурировать честным способом, они пытаются сделать плохо своим коллегам/конкурентам (не важно, кто жертва: сервер линейки, интернет магазин или отдельно взятая страна). Часто бывает, что за неимением конкурентов, но желанием монетизировать имеющиеся возможности «нехорошие» люди используют шантаж — заплатите 100$ и мы не будем DDOS`ить Ваш сайт. Но не лучше мы относимся и к фирмам, которые предлагают защиту от DDOS — фактически, это тот же шантаж, игра на страхе людей, но легальный. Вместо того, чтобы внести вклад в решение этой проблемы, на ней пытаются зарабатывать деньги. Надеюсь, что наши усилия не пропадут даром.
Немного теории TCP
DDOS атаки бывают разные, как и их классификации. Атаки могут забивать канал, нагружать приложение, могут быть направлены на стек TCP/IP. В данном случае я хотел бы более подробно рассказать об атаке типа SynFlood (и похожих ACK, DATA), когда на конечную машину приходит много пакетов на открытие соединения.
Соединение в TCP открывается так называемым «тройным рукопожатием», для установки соединения сервер пассивно ожидает входящего пакета (выполнив системные вызовы LISTEN и ACCEPT).
Номера последовательностей — это, фактически, номера пакетов (байт в байтовом потоке), которые будут приняты или посланы, они необходимы для дальнейшей сборки данных в правильном порядке (протокол IP не гарантирует доставку пакетов в правильной последовательности), а также для идентификации потерянных или испорченных пакетов. У каждой стороны есть две последовательности: одна для передачи, одна для приема.
Основное назначение установки соединения — согласовать передающие последовательности и параметры соединения, которые указываются дополнительными опциями TCP. По RFC начальная последовательность должна быть произвольным числом, плавно увеличиваемым во времени.
Установить соединения можно и за 4 пакета, отправив отдельные пакеты c флагами SYN и ACK. Так же есть технология TCP Fast Open, о которой стоит поговорить отдельно.
Более подробно об TCP/IP можно почитать в WIKI.
О простоте обработки пакетов говорит приведенная ниже схема работы сетевого стека ядра Linux:
В стандартной системе без применения дополнительных механизмов и тюнинга сетевого стека сервер начинает умирать уже при 100к-150к SYN-пакетов в секунду.
Технология Syncookie
В 1997 году в ядро был добавлен механизм защиты, позволяющий не сохранять данные в таблице тракинга соединений, а подписывать переданную последовательность в SYN+ASK пакете через куку, которая размещается на месте опций TCP.
Подписывание выполняется на основе алгоритма SHA1, где для валидации используется метки времени и секретный ключ, генерируемый каждый раз новый при старте системы. Кука записывается в значения seq, TCP опций в поля Timestamp (с 31 по 6 байт), ECN, SACK, WScale (4 байта из 6). Тут нужно пояснить: в Timestamp с 0 по 5 байт передается метка времени, которая также участвует в процессе валидации пакета (в среднем обновляется раз в 2 минуты), то есть если ответный пакет пришел через час — он будет не валидный. Также накладывается ограничение на количество возможных значений MSS, в последних ядрах используются следующие значения:
Более подробно все аспекты можно посмотреть в коде ядра в файле syncookies.c.
Данная технология позволила значительно увеличить способность системы обрабатывать SYN пакеты. В наших тестах, без особого тюнинга, система выдерживала 300к — 350к пакетов в секунду (данные приведены для сетевой карты 1G с 4 прерываниями). Но данное решение имеет недостатки в виде ограниченности выбора дополнительных параметров соединения — MSS ограничивается только 4 значениями, а также игнорировании части опций TCP.
Для включения в Linux Syncookie необходимо выполнить:
В значении 1 Syncookie включается только при переполнении таблицы тракинга соединений. Для значения по умолчанию 2048 (параметр net.ipv4.tcp_max_syn_backlog), скорей всего, Ваше приложение уже перестанет отвечать на запросы.
На OpenNet есть статья по настройке IPTables + SynProxy.
Не так давно в ядро были добавлены патчи от Eric Dumazet, значительно повышающие производительность сетевого стека. По заявленным тестам позволяющие обрабатывать до 6М пакетов в секунду. За проделанную работу по улучшению сетевой подсистемы ядра хочется сказать огромное спасибо.
Технология SynProxy
Такие компании как F5, Arbor, Juniper и большинство фирм по защите от DDOS реализовали технологию SynProxy. Фактически фаерволы представляются конечной машиной и отвечают SynCookie на каждый SYN пакет, при этом для увеличения производительности не всегда используется SHA1 (в наших тестах мы использовали XOR и добивались колоссальной производительности в расчете на одно ядро). Проблема в том, что кука генерируется с использованием невалидного с точки зрения защищаемого сервера секретного ключа и метки времени. Если ответный ACK пакет просто переслать на конечную машину, она разорвет соединения. Поэтому, после получения от клиента ACK пакета с валидной кукой (валидность проверяет фаервол), необходимо симулировать открытие соединения от имени конечной машины уже без использования syncookie. При этом номера последовательностей, сохраненные на клиенте и передаваемые сервером, будут разные. В задачи фаервола будет входить замена данных последовательностей в каждом пакете от клиента к серверу и от сервера к клиенту.
Этот метод дает некоторые неоспоримые преимущества:
Но есть и недостатки:
Зачем изобретать свой велосипед
Использование технологии SynProxy было логичным выходом, но, как оказалось, стоимость решения от вендоров, к которым мы обращались, для наших целей превышало 100 000$ и представляло больше стоимость ПО, а не железа.
Решили разобраться в проблеме более подробно и, по возможности, написать простое решение, идеально подходящее для наших задач.
Принцип работы
Мы сделали систему, которая фильтрует трафик на любой сервер в нашей сети, просто включается и настраивается (автоматически), не требует больших ресурсов и, что не менее важно, не сильно дорога в реализации.
Логичным продолжением технологии Syncookie является вынос ее за пределы сервера, для этого мы написали модуль к ядру и демон, который общается с системой фильтрации по внутренней сети, передает секретный ключ и синхронизирует метки времени, а также включает Syncookie на сервере в случае необходимости. То есть на защищаемый сервер устанавливается модуль для ядра, который создает файл /proc/tcp_secrets, и демон, который передает данные с этого файла на фаервол.
Роутер — в нашем случае граничный маршрутизатор MX480.
Фаервол — сервер, на котором запущена система фильтрации, соединен с главным коммутатором (Juniper EX4550) двумя линками по 10G.
Защищаемый сервер — защищаемый сервер, подключен линком 1G.
Физическая организация нашего стенда (атаки на канальную емкость фильтруются на роутере):
Роутер подключен в главный коммутатор линком 40G, с главного коммутатора на фаервол идет два линка по 10G (один для входящего на фаервол трафика, другой для исходящего с него) и защищаемый сервер подключен еще через несколько коммутаторов линком 1G.
В обычном состоянии роутер и защищаемый сервер общаются напрямую, в случае обнаружения атаки на роутере прописывается статическая привязка ip адреса сервера к mac адресу фаервола, после этого весь трафик, идущий на защищаемый сервер, идет на фаервол, который имеет гораздо большую полосу пропускания (10G вместо 1G). Фаервол при получении SYN пакета (через первый интерфейс) отправляет в сеть SYN-ACK пакет (через второй интерфейс) от имени защищаемого сервера (с его mac адреса и IP) с валидной с точки зрения защищаемого сервера syncookie (так как у него есть секретный ключ и метка времени от защищаемого сервера), в случае получения ACK пакета (с кукой), фаервол проверяет его валидность, затем или меняет в пакете mac адрес на mac адрес защищаемого сервера и отправляет пакет обратно в сеть, или удаляет его, если кука не валидна. Защищаемый сервер, получая ACK пакет, открывает соединения и исходящие пакеты отправляет напрямую на роутер.
На сервере, так же как и в технологии SynProxy, ведется отслеживание соединений, так как мы видим начало открытия соединения и можем считать его закрытым по timeout (в случае если его закрыл сервер).
Алгоритм отслеживания соединений следующий:
2 раза в минуту проходим по таблице отслеживания соединений и удаляем соединения в статусе Closing, для которых закончился Timeout.
Таблица возможных состояний соединения и последовательности передаваемых пакетов:
Также на фаерволе возможны любые правила фильтрации трафика — блокировка по IP, порту, протоколу и любым другим параметрам, которые задаются в pcap-filter в конфиге и могут применяться на лету. Например, для защищаемого сервера — запрещаем весь UDP трафик, разрешаем только TCP на порты 22, 80, 443 и для этих портов включаем SynProxy. Описание конфигурационного файла будет ниже в статье.
Во время защиты сервера от атак весь входящий трафик направляется на фаервол, и с него на сервер от имени роутера идут только валидные пакеты. Пакеты с защищаемого сервера идут напрямую на роутер в обход фаервола.
То есть, фактически, система включается только тогда, когда идет атака, и состоит из четырех основных частей:
Данная схема позволяет:
Настройка
На защищаемом сервере
1. Установите модуль ядра tcpsecrets для доступа к tcp syncookie key и timestamp
На фаерволе
1. Установите netmap и убедитесь, что он работает.
2. Запретите использование NIC offloading features на интерфейсе, который собираетесь использовать:
3. Настройте привязку прерываний к ядрам процессора. В данном примере мы привязываем 12 очередей к 12 первым процессорным ядрам:
4. Создайте конфигурационный файл hosts.yml в рабочий директории, например:
5. Запустите демон:
6. Настройте сеть таким образом, чтобы трафик на защищаемый сервер шел на фаервол.
7. В любой момент можно изменить конфигурацию путем изменения файла host.yml и отправки демону SIGHUP.
8. Наслаждайтесь превосходной защитой от DDOS атак =)
У syncookied есть много дополнительных опций, которые влияют на работу и производительность. Cписок всех опций:
Дополнительная фильтрация
Есть возможность указывать дополнительные фильтры в конфигурации хоста, фильры пишутся в pcap формате, политика по умолчанию пропускать трафик. Фильры применяются до 4 уровня модели ISO. Более подробно о формате фильтров можно прочесть в man pcap-filter.
InfluxDB
Тесты производительности
В ядре есть много реализаций алгоритма SHA1 — на С, на ассемблере с использованием разных инструкций. Написали небольшую программу для тестирования скорости, результаты представлены ниже:
По результатам к проекту было решено подключить код на асемблере, использующим инструкции avx. Но, ходят слухи, что intel хочет сделать аппаратную реализацию SHA.
TCP/IP checksum
Аналогичным образом тестировали TCP и IP контрольную сумму. Код представлен здесь. По результатам тестирования выбрали самый быстрый алгоритм:
Общее тестирование производительности
В отсутсвие трафика syncookied для уменьшения задержек постоянно опрашивает сетевую карту, что создает небольшую нагрузку:
Нагрузка, создаваемая фильтрацией трафика 12.755pps (теоретический предел при размере пакета 74 байта + 4 байта заголовок ethernet):
При фильтрации UDP или применении правил по портам/протоколам нагрузка будет неотличима от нагрузки в отсутствие трафика.
Фактически 10 ядер процессора Intel Xeon E5-2680v3 могут обрабатывать до 10 гигабит трафика. Один физический сервер способен обрабатывать более 40 гигабит трафика.