Защиты от атак TCP SYN Flooding - Интернет-протокол журнала - Том 9, номер 4

1. Уэсли М. Эдди, Федеральные сетевые системы Verizon В этой статье обсуждается конкретная атака типа...
2. Методы атаки
3. Прямая атака
4. Спуфинг-атаки
5. Распределенные атаки
6. Параметры атаки
7. Уроки выучены
8. Контрмеры
9. Конечные меры противодействия
10. Сетевые контрмеры
11. Защита на практике
12. Связанные атаки
13. Заключение
14. Подтверждения

Уэсли М. Эдди, Федеральные сетевые системы Verizon

В этой статье обсуждается конкретная атака типа «отказ в обслуживании» (DoS), известная как TCP SYN Flooding . Атака использует характеристику реализации протокола управления передачей (TCP) и может использоваться для того, чтобы сделать процессы сервера неспособными отвечать на запросы законного клиентского приложения о новых соединениях TCP. Любой сервис, который связывается с TCP-сокетом и прослушивает его, потенциально уязвим к атакам по переполнению TCP SYN. Поскольку это включает в себя популярные серверные приложения для служб электронной почты, Интернета и хранения файлов, понимание и знание способов защиты от этих атак является важной частью практического сетевого проектирования.

Атака была известна в течение десятилетия, и его вариации все еще видны. Хотя существуют эффективные методы борьбы с переполнением SYN, не было найдено ни одного стандартного средства для реализации TCP. Различные текущие решения могут быть найдены среди существующих операционных систем и оборудования, с различными последствиями как для приложений, так и для защищаемых сетей. В этой статье описывается атака и почему она работает, а затем дается обзор и оценка текущих тактик, которые используются как на конечных хостах, так и на сетевых устройствах для борьбы с атаками с использованием наводнения SYN.

Базовая уязвимость

Атака SYN-наводнения стала известной в 1996 году, когда журналы 2600 и Phrack опубликовали описание атаки вместе с исходным кодом для ее осуществления [1]. Эта информация была быстро использована при атаках на почтовые и интернет-серверы интернет-провайдера (ISP), что привело к сбоям, которые широко освещались в The Washington Post и The Wall Street Journal (среди других мест). CERT быстро выпустил рекомендации по технике атаки [2].

Основой атаки SYN-наводнения является проект трехстороннего рукопожатия, которое начинает TCP-соединение. В этом рукопожатии третий пакет проверяет способность инициатора принимать пакеты по IP-адресу, который он использовал в качестве источника в своем первоначальном запросе, или его возвращаемую достижимость. На рисунке 1 показана последовательность пакетов, которыми обмениваются в начале обычного TCP-соединения (см. RFC 793 для подробного описания этого процесса).

Рисунок 1: Обычное трехстороннее рукопожатие TCP

Блок управления передачей (TCB) является структурой данных транспортного протокола (фактически набором структур во многих операционных системах), которая содержит всю информацию о соединении. Объем памяти отдельного TCB зависит от того, какие параметры TCP и другие функции обеспечивает реализация для соединения. Обычно каждый TCB превышает по крайней мере 280 байтов, а в некоторых операционных системах в настоящее время занимает более 1300 байтов. Состояние TCP SYN-RECEIVED используется для указания того, что соединение открыто только наполовину, и что законность запроса все еще находится под вопросом. Важный аспект, который следует отметить, заключается в том, что TCB распределяется на основе приема пакета SYN - до того, как соединение будет полностью установлено, или пока не будет проверена достижимость возврата инициатора.

Эта ситуация приводит к явной потенциальной DoS-атаке, когда входящие SYN вызывают выделение такого количества TCB, что память ядра хоста исчерпывается. Чтобы избежать этого исчерпания памяти, операционные системы обычно связывают параметр «backlog» с прослушивающим сокетом, который устанавливает ограничение на количество TCB одновременно в состоянии SYN-RECEIVED. Хотя это действие защищает доступный ресурс памяти хоста от атаки, само отставание представляет собой другой (меньший) ресурс, уязвимый для атаки. Поскольку в резерве не осталось места, невозможно обслуживать новые запросы на подключение, пока некоторые TCB не будут собраны или иным образом удалены из состояния SYN-RECEIVED.

Устранение отставания является целью атаки по переполнению TCP SYN, которая пытается отправить достаточно сегментов SYN для заполнения всего журнала невыполненных работ. Атакующий использует исходные IP-адреса в SYN, которые вряд ли вызовут какой-либо ответ, который освободил бы TCB из состояния SYN-RECEIVED. Поскольку TCP пытается быть надежным, целевой хост удерживает свои TCB в режиме SYN-RECEIVED относительно долгое время, прежде чем отказаться от половины соединения и пожать их. В то же время сервису отказано в процессе приложения на приемнике для законных новых запросов инициализации соединения TCP. На рисунке 2 представлено упрощение последовательности событий, связанных с атакой TCP SYN flooding.

Методы атаки

Рисунок 2: Демонстрация атаки: достаточно незаконных УТС
SYN-RECEIVED, что законное соединение не может быть инициировано.

Сценарий, изображенный на рисунке 2, является упрощением того, как атаки SYN-наводнения осуществляются в реальном мире, и предназначен только для того, чтобы дать понимание основной идеи, лежащей в основе этих типов атак. На рисунке 3 представлены некоторые изменения, которые наблюдались в Интернете.

Рисунок 3: Некоторые варианты базовой атаки

Прямая атака

Если злоумышленники быстро отправляют сегменты SYN без подмены своего IP-адреса источника, мы называем это прямой атакой . Этот метод атаки очень прост в исполнении, потому что он не предполагает непосредственного внедрения или подмены пакетов ниже уровня пользователя операционной системы злоумышленника. Это может быть выполнено, например, путем использования многих вызовов TCP connect () . Однако, чтобы быть эффективными, злоумышленники должны препятствовать тому, чтобы их операционная система каким-либо образом отвечала на SYN-ACK, потому что любые сообщения ACK, RST или сообщения протокола ICMP ( Internet Control Message Protocol ) позволят слушателю переместить TCB из SYN-. ПОЛУЧЕНО . Этот сценарий может быть реализован с помощью правил брандмауэра, которые либо фильтруют исходящие пакеты к слушателю (разрешая только выход SYN), либо фильтруют входящие пакеты, так что любые SYN-ACK отбрасываются до достижения локального кода обработки TCP.

При обнаружении такого типа атаки очень легко защититься, поскольку все, что нужно, - это простое правило брандмауэра для блокировки пакетов с исходным IP-адресом злоумышленника. Это защитное поведение может быть автоматизировано, и такие функции доступны в готовых реактивных брандмауэрах.

Спуфинг-атаки

Другая форма атак SYN-наводнения использует подделку IP-адресов, которая может считаться более сложной, чем метод, используемый при прямой атаке, поскольку вместо простого манипулирования локальными правилами брандмауэра злоумышленник также должен иметь возможность формировать и внедрять необработанные IP-пакеты. с действительными заголовками IP и TCP. Сегодня существуют популярные библиотеки для помощи в формировании и внедрении необработанных пакетов, поэтому атаки, основанные на спуфинге, на самом деле довольно легки.

Для подмены атак основное внимание уделяется выбору адреса. Если атака будет успешной, машины по поддельным адресам источника не должны отвечать на SYN-ACK, которые им отправляются каким-либо образом. Очень простой злоумышленник может подделать только один адрес источника, который, как он знает, не будет отвечать на запросы SYN-ACK, либо потому, что в данный момент физически не существует машины по этому адресу, либо из-за какого-либо другого свойства адреса или конфигурации сети. Другой вариант - подделать много разных исходных адресов, предполагая, что некоторый процент поддельных адресов не будет соответствовать SYN-ACK. Эта опция достигается либо циклическим просмотром списка исходных адресов, которые, как известно, желательны для этой цели, либо генерированием адресов внутри подсети с аналогичными свойствами.

Если только один адрес источника постоянно подделывается, слушатель может легко обнаружить и отфильтровать этот адрес. В большинстве случаев больший список адресов источников используется для усложнения защиты. В этом случае лучшей защитой является блокировка поддельных пакетов как можно ближе к их источнику.

Предполагая, что злоумышленник находится в «тупиковом» месте в сети (например, а не в транзитной автономной системе (AS)), ограничительная входная фильтрация сети [7] по тупым интернет-провайдерам и выходная фильтрация в сети злоумышленника будут отключены. подделка атак - если эти механизмы можно развернуть в нужных местах. Поскольку эти средства защиты входящей / исходящей фильтрации могут мешать некоторому допустимому трафику, такому как режим работы с треугольной маршрутизацией Mobile IP, они могут рассматриваться как нежелательные и не используются повсеместно. IP Security (IPsec) также обеспечивает превосходную защиту от поддельных пакетов, но этот протокол обычно не требуется, поскольку его развертывание в настоящее время ограничено. Поскольку для слушателя обычно невозможно попросить интернет-провайдеров инициатора выполнить фильтрацию адресов или попросить инициатора использовать IPsec, защита от спуфинговых атак, использующих несколько адресов, требует более сложных решений, которые обсуждаются далее в этой статье.

Распределенные атаки

Реальное ограничение атак, основанных на спуфинге одного злоумышленника, состоит в том, что если пакеты каким-либо образом прослеживаются до их истинного источника, злоумышленник может быть легко отключен. Хотя процесс отслеживания обычно требует некоторого времени и координации между провайдерами, это не является невозможным. Распределенную версию атаки SYN-наводнения, в которой злоумышленник использует преимущества множества беспилотных машин по всему Интернету, остановить гораздо сложнее. В случае, показанном на рисунке 3, дроны используют прямые атаки, но чтобы еще больше повысить эффективность, каждый дрон может использовать атаку спуфинга и несколько поддельных адресов.

В настоящее время распределенные атаки возможны, поскольку существует несколько «ботнетов» или «армий дронов» из тысяч скомпрометированных машин, которые используются преступниками для DoS-атак. Поскольку беспилотные машины постоянно добавляются или удаляются из армий и могут изменять свои IP-адреса или соединения, блокировать эти атаки довольно сложно.

Параметры атаки

Независимо от метода атаки, наводнение SYN может быть настроено на использование меньшего количества пакетов, чем атака методом грубой силы, которая просто забивает целевую сеть, отправляя большой объем пакетов. Эта настройка выполняется с некоторым знанием операционной системы слушателя, такой как размер используемого невыполненного задания и то, как долго он удерживает TCB в SYN-RECEIVED до истечения времени ожидания и повторного их получения. Например, злоумышленник может минимально отправить быстрый полет некоторого количества SYN, точно равных отставанию, и периодически повторять этот процесс по мере того, как TCB освобождаются, чтобы постоянно держать слушателя недоступным.

Задержки по умолчанию 1024 настроены в некоторых последних операционных системах, но многие машины в Интернете настроены с задержками 128 или меньше. Общий порог для повторной передачи SYN-ACK равен 5, причем время ожидания между последовательными попытками удвоено, а начальное время ожидания составляет 3 секунды, что дает 189 секунд между временем, когда отправляется первый SYN-ACK, и временем, когда TCB может быть исправленным.

Предполагая, что резерв составляет 128, и злоумышленник генерирует 40-байтовые сегменты SYN (с 20-байтовым заголовком TCP плюс 20-байтовый заголовок IP), злоумышленник должен отправить только 5,12 килобайта (на уровне IP), чтобы заполнить отставание. Повторяемый каждые 189 секунд, этот процесс дает среднюю скорость передачи данных всего 27 байтов в секунду (легко достижимо даже по коммутируемым каналам). Эта скорость передачи данных резко контрастирует с DoS-атаками, которые основаны на отправке трафика со многими мегабитами в секунду. Даже если используется резерв 2048, необходимая скорость передачи данных составляет всего 433 байта в секунду, поэтому очевидно, что простота атаки масштабируется вместе с увеличением отставания - и требуются более сложные средства защиты.

Уроки выучены

Недостаток протокола в TCP, который делает затопление SYN эффективным, состоит в том, что при небольших затратах на отправку пакета инициатор вызывает относительно большие затраты для слушателя, заставляя слушателя резервировать состояние в TCB. Отличная технология для разработки протоколов, устойчивых к этому типу атак, состоит в том, чтобы заставить сторону слушателя работать без сохранения состояния [3], пока инициатор не сможет продемонстрировать свою легитимность. Этот принцип использовался в более поздних транспортных протоколах, таких как протокол управления потоком (SCTP) [4], который имеет четырехстороннее рукопожатие, причем состояние TCB слушателя создается только после того, как инициатор эхом отдает назад некоторые байты «cookie» отправлено слушателем. Это эхо в какой-то степени доказывает, что сторона инициатора находится по адресу, который, по-видимому, находится (то есть имеет обратную достижимость) и не пытается использовать стиль атаки SYN flood.

Вне транспортных протоколов и УТС протоколы безопасности также обычно используют эту технику защиты. Например, компонент IPsec Internet Key Exchange версии 2 (IKEv2) [5] не создает состояние для новой ассоциации безопасности, пока не сможет проверить, способны ли инициаторы отвечать на пакеты, отправленные по адресу, который, по их утверждению, используется. Существуют другие протоколы безопасности, в которых слушатель рассылает «головоломки» в ответ на попытки инициации и предоставляет услуги или состояние только при возврате решения головоломки [6]. Эта тактика не только проверяет адреса инициаторов, но также подразумевает вычислительную нагрузку, которая заставляет их дополнительно демонстрировать свою подлинную готовность продуктивно общаться.

Контрмеры

Во время первоначальной атаки Panix использовались произвольные поддельные адреса источников, но было отмечено, что все SYN-атаки TCP-атаки использовали один и тот же номер порта источника. Фильтр, который отклонял входящие пакеты с этого порта, был временно эффективен, но злоумышленнику было легко адаптироваться, и сегменты атаки начали использовать случайные порты. Panix удалось определить, с какого входного маршрутизатора исходила атака, и какие пакеты с нулевым маршрутом предназначались для его серверов, проходящих через этот маршрутизатор, но это решение, очевидно, было сложным, и, похоже, оно также было преодолено, когда злоумышленник начал посылать пакеты, которые были направлены через другого вышестоящего провайдера. Panix имел неоднозначный успех в привлечении своих провайдеров для помощи в отслеживании и блокировании атаки, и сетевое сообщество было побуждено к разработке других решений.

Были разработаны два широких класса решений атак SYN-наводнения, соответствующих тому, где реализованы средства защиты. Первый класс решений включает в себя ужесточение самой реализации TCP конечного хоста, включая изменение алгоритмов и структур данных, используемых для поиска и установления соединения, а также некоторых решений, которые отличаются от поведения конечного автомата TCP во время установления соединения, как описано в RFC. +793.

Второй класс включает в себя усиление сети, либо для уменьшения вероятности предварительных условий атаки (целая армия контролируемых хостов или распространение IP-пакетов с поддельными адресами источника), либо для вставки промежуточных ящиков, которые могут изолировать серверы в сетях позади них от незаконных сигналы SYN.

Конечные меры противодействия

Увеличение количества невыполненных заданий TCP : поскольку основной механизм атаки основан на переполнении невыполненных задним числом подключенных сокетов, очевидным решением для конечных узлов является простое увеличение числа невыполненных заданий, как это уже делается для очень популярных серверных приложений. По крайней мере, в некоторых популярных реализациях TCP это решение является плохим из-за использования обхода линейного списка в функциях, которые пытаются освободить состояние, связанное с попытками устаревшего соединения. Увеличение количества невыполненных работ обычно возможно путем изменения вызова приложения listen () и установки параметра ядра операционной системы с именем SOMAXCONN, который устанавливает верхнюю границу размера невыполненного задания, которое может запросить приложение. Этот шаг сам по себе не должен серьезно рассматриваться как средство защиты от атак SYN-наводнения - даже в операционных системах, которые могут эффективно поддерживать большие резервы - потому что злоумышленник, который может генерировать сегменты атаки, скорее всего, сможет масштабироваться до более крупных порядков чем отставание, поддерживаемое хостом.

Сокращение таймера SYN-RECEIVED : Другой простой механизм на основе конечного хоста заключается в том, чтобы установить более жесткое ограничение на количество времени между моментом, когда TCB входит в состояние SYN-RECEIVED, и когда он может быть получен для отказа в продвижении. Очевидным недостатком этого механизма является то, что в случаях агрессивных атак, которые приводят к некоторой потере перегрузки в пакетах SYN-ACK или ACK, завершающих рукопожатие, допустимые TCB соединения могут быть получены, поскольку хосты находятся в процессе повторной передачи этих сегментов. Кроме того, существует только линейная зависимость между уменьшением, которое администратор делает в таймере SYN-RECEIVED, и соответствующим увеличением скорости передачи пакетов, которое злоумышленник должен сделать, чтобы продолжить атаку на сервер. Другие альтернативные решения для конечных хостов значительно затрудняют атаку. По этим причинам уменьшение таймера SYN-RECEIVED не является рекомендуемой защитой от атак SYN-переполнения.

Рисунок 4: Установление соединения с помощью файлов cookie SYN

Кэши SYN : две защиты конечного хоста, называемые кэшами SYN и куки-файлами SYN (описанными позже), работают путем уменьшения количества состояний, первоначально выделенных для TCB, сгенерированного полученным SYN, и откладывания создания экземпляра полного состояния [8]. В хосте, который использует кэш SYN, хеш-таблица с ограниченным объемом пространства в каждом хэш-сегменте используется для хранения подмножества данных, которые обычно поступают в выделенный TCB. Если и когда квитанция, завершающая ACK, получена, эти данные могут быть перемещены в полный TCB; в противном случае самое старое ведро с определенным хеш-значением может быть получено при необходимости. В примере FreeBSD от Lemon [8] запись кэша SYN для половины соединения составляет 160 байтов против 736 байтов для полного TCB, и поддерживаются 15359 записей в кэше SYN.

Структура данных кэша SYN устойчива к злоумышленникам, пытающимся переполнить свои сегменты, поскольку она использует номер локального порта инициатора и некоторые секретные биты в значении хэша. Поскольку стеки являются более эффективной структурой данных для поиска, чем простой связанный список, стеки, использующие кэш SYN, могут иметь улучшенную скорость, даже если они не находятся под атакой. Согласно тестам Лемон, во время активной атаки хост, использующий кэш SYN, смог установить легитимные соединения с задержкой примерно на 15%.

Файлы cookie SYN : В отличие от подхода кэш-памяти SYN, техника файлов cookie SYN приводит к тому, что полученное сообщение SYN генерирует абсолютно нулевое состояние. Вместо этого самые основные данные, содержащие состояние соединения, сжимаются в биты порядкового номера, используемого в SYN-ACK. Поскольку для допустимого соединения будет получен сегмент ACK, который повторяет этот порядковый номер (фактически порядковый номер плюс один), базовые данные TCB могут быть восстановлены, а полный TCB может быть безопасно создан путем декомпрессии поля Acknowledgement. Эта декомпрессия может быть эффективной даже при интенсивной атаке, потому что на слушателя не загружается память, а только вычислительная нагрузка для кодирования данных в порядковые номера SYN-ACK. Недостатком является то, что не все данные TCB могут помещаться в поле 32-битного порядкового номера, поэтому некоторые параметры TCP, необходимые для высокой производительности, могут быть отключены. Другая проблема заключается в том, что SYN-ACK не передаются повторно (поскольку повторная передача требует состояния), что изменяет процедуры синхронизации TCP из RFC 793.

Недавняя работа Андре Опперманна использует опцию TCP Timestamp в сочетании с полем Sequence Number для кодирования дополнительной информации о состоянии и сохранения использования высокопроизводительных опций, таких как масштабирование окна TCP и опции выборочного подтверждения TCP (SACK), а также может быть используется для сохранения поддержки TCP-Message Digest 5 (MD5) с помощью файлов cookie SYN. Этот параметр является шагом вперед, поскольку он устраняет основной негативный эффект предыдущих реализаций файлов cookie SYN, которые отключали эти функции.

Рисунок 5: Процесс создания и проверки файлов cookie TCP SYN.

Точный формат файлов cookie TCP SYN не является проблемой взаимодействия, поскольку они интерпретируются только локально, а формат и процедуры генерации и проверки могут незначительно отличаться в разных реализациях. На рисунке 5 показан общий процесс генерации и проверки куки-файлов SYN, используемых несколькими реализациями.

Чтобы вычислить порядковый номер SYN-ACK (то есть cookie-файл TCP) при использовании cookie-файлов TCP, узел сначала объединяет некоторые локальные секретные биты, структуру данных, которая содержит IP-адреса и порты TCP, начальный порядковый номер SYN и некоторые индексные данные, идентифицирующие секретные биты. Дайджест MD5 вычисляется для всех этих байтов, и некоторые биты усекаются из значения хеш-функции, которое помещается в порядковый номер SYN-ACK. Поскольку порядковый номер составляет около четверти размера полного хеш-значения, это усечение необходимо, но обычно используются не менее 3-х байтов хэш-битов, что означает, что все еще должно быть около 2 ^ 24 усилий, необходимых для угадать действительный cookie, не зная локальных секретных битов. В дополнение к выводу хеш-функции некоторые из битов cookie указывают нижнюю границу максимального размера сегмента (MSS), содержащуюся в SYN, и биты индекса, определяющие локальный секрет, используемый внутри хеш-функции.

Чтобы проверить куки-файл SYN, сначала номер подтверждения во входящем сегменте ACK уменьшается на 1, чтобы получить сгенерированный куки-файл SYN. Действительное значение для набора усеченных битов хеша вычисляется на основе пары IP-адресов, номеров портов TCP, порядкового номера сегмента минус один и значения из секретного пула, соответствующего битам индекса в файле cookie. Если эти вычисленные биты хеша совпадают с битами в сегменте ACK, то TCB инициализируется и соединение продолжается. Закодированная граница MSS используется для установки MSS разумного размера, который не больше, чем было первоначально объявлено. Эта MSS обычно реализуется в виде трех битов, чьи кодовые точки соответствуют восьми «обычно рекламируемым» значениям MSS на основе типовых максимальных единиц передачи (MTU) канала и служебных данных заголовка.

Гибридные подходы : гибридный подход сочетает в себе два или более методов единой защиты, описанных ранее. Например, некоторые операционные системы конечного хоста реализуют как большие резервные файлы, так и файлы cookie SYN, но разрешают файлы cookie SYN, только когда объем занятого журнала ожидания превышает некоторый порог, что позволяет им нормально работать без недостатков файлов cookie SYN, но также позволяя им переключаться на поведение SYN-cookie и быть надежно защищенным при атаке.

Сетевые контрмеры

Фильтрация . Самая базовая защита на уровне сети - это применение методов фильтрации, описанных в RFC 2827 [7]. Используя входящую фильтрацию, провайдер отказывается от дальнейшей маршрутизации пакетов, поступающих с конечного сайта с IP-адресами источника, которые не принадлежат этому конечному сайту. Входная фильтрация была бы очень эффективной для предотвращения атак SYN-затопления, которые основаны на поддельных IP-пакетах. Однако в настоящее время это ненадежно, поскольку политики входной фильтрации не используются повсеместно. Входная фильтрация также совершенно неэффективна против атак SYN, которые используют распределенную армию управляемых хостов, каждый из которых атакует напрямую. Входная фильтрация также является механизмом, который конечный сайт, желающий защитить себя, чаще всего не контролирует, поскольку он не влияет на политику, применяемую интернет-провайдерами по всему миру.

Брандмауэры и прокси-серверы : Брандмауэр или прокси-машина внутри сети может буферизовать конечные хосты от атак SYN-наводнения двумя способами: либо путем подмены SYN-ACK инициаторам, либо путем подделки ACK слушателю [9].

На рисунке 6 показана базовая работа брандмауэра / прокси, который подменяет SYN-ACK для инициатора. Если инициатор является легитимным, брандмауэр / прокси-сервер видит ACK, а затем устанавливает соединение между собой и слушателем, подделывая адрес инициатора. Межсетевой экран / прокси-сервер разделяет сквозное соединение на два соединения с самим собой. Это разделение работает как защита от атак SYN, потому что слушатель никогда не видит SYN от атакующего. Пока брандмауэр / прокси-сервер реализует некоторый механизм защиты на основе TCP, такой как куки-файлы SYN или кэш-память SYN, он может защищать все серверы в сети, находящиеся за ним, от атак SYN-наводнения.

Рисунок 6: Обмен пакетами через брандмауэр / прокси-сервер SYN-ACK

На рисунке 7 показан обмен пакетами через брандмауэр / прокси-сервер, который подменяет ACK для слушателя в ответ на наблюдаемые SYN-ACK. Этот спуфинг не позволяет TCB слушателей оставаться в состоянии SYN-RECEIVED и, таким образом, сохраняет свободное место в заделе. Затем брандмауэр / прокси-сервер ожидает некоторое время, и если не наблюдается законный ACK от инициатора, то он может сигнализировать слушателю об освобождении TCB с использованием поддельного сегмента TCP RST. Для законных соединений поток пакетов может продолжаться без вмешательства со стороны брандмауэра / прокси. Это решение более желательно, чем режим работы на рисунке 5, где брандмауэр / прокси-сервер подделывает SYN-ACK, поскольку он не требует, чтобы брандмауэр / прокси-сервер активно участвовал в законных соединениях после их установления.

Рисунок 7: Обмен пакетами через ACK-спуфинг Firewall / Proxy.

Активный монитор. Активный монитор - это устройство, которое может наблюдать и вводить трафик слушателю, но не обязательно находится внутри самого маршрута маршрутизации, как это делает брандмауэр. Один тип активного монитора действует как брандмауэр / прокси-сервер, использующий ACK-спуфинг, показанный на рисунке 6, с добавленной возможностью немедленной подмены RST, если он видит SYN с адресов источника, которые, как он знает, используются злоумышленниками [9]. Активные мониторы полезны, поскольку они могут быть дешевле или проще в развертывании, чем решения на основе брандмауэра или фильтрации, и могут по-прежнему защищать целые сети слушателей, не требуя от каждой операционной системы слушателя реализации решения для конечного хоста.

Защита на практике

Как конечные хосты, так и сетевые решения для атаки SYN flooding имеют свои достоинства. Оба типа защиты часто используются, и они, как правило, не мешают при использовании в комбинации. Поскольку затопление SYN предназначается для конечных хостов, а не для того, чтобы пытаться исчерпать пропускную способность сети, кажется логичным, что все конечные хосты должны реализовывать защиту, и что сетевые методы представляют собой дополнительную вторую линию защиты, которую может использовать сайт.

Механизмы конечного хоста присутствуют в текущих версиях наиболее распространенных операционных систем. Некоторые реализуют кэши SYN, другие используют куки SYN после того, как порог использования невыполненного задания превышен, а третьи адаптируют таймер SYN-RECEIVED и количество попыток повторной передачи для SYN-ACK.

Поскольку известно, что некоторые методики неэффективны (увеличение задержек и уменьшение таймера SYN-RECEIVED), на эти методы определенно не следует полагаться. Основываясь на экспериментах и ​​анализе (и мнении автора), кэши SYN кажутся наилучшим доступным механизмом конечного хоста.

Этот выбор мотивирован фактами, что они способны противостоять сильным атакам, они свободны от негативных эффектов файлов cookie SYN, и им не требуется никакой эвристики для установки порогов, как во многих гибридных подходах.

Среди сетевых решений нет никаких веских аргументов в пользу спуфинга брандмауэра / прокси-сервера SYN-ACK. Поскольку эти спуфинговые прокси разделяют TCP-соединение, они могут отключить некоторые высокопроизводительные или другие параметры TCP, и, похоже, у этого подхода мало преимуществ по сравнению с ACK-спуфингом межсетевого экрана / прокси. Активные мониторы следует использовать, когда решение брандмауэра или прокси-сервера является административно невозможным или слишком дорогим в развертывании. Входная и выходная фильтрация часто выполняется сегодня (но не повсеместно) и является общепринятой практикой как часть хорошего соседа в Интернете. Поскольку фильтрация не справляется с распределенными сетями дронов, использующих прямые атаки, она должна быть дополнена другими механизмами, и конечный хост не должен полагаться на нее.

Связанные атаки

В дополнение к переполнению SYN возможны несколько других атак на TCP-соединения путем подмены IP-адреса источника и параметров соединения для выполняющихся TCP-соединений [10]. Если злоумышленник может угадать два IP-адреса, номера портов TCP и действительный порядковый номер в окне, то соединение может быть разорвано либо путем его сброса, либо путем введения поврежденных данных. В дополнение к поддельным TCP-сегментам, поддельные ICMP-дейтаграммы имеют возможность разорвать TCP-соединения жертвы.

Обе эти другие атаки и потоки SYN нацелены на приложение TCP жертвы и могут потенциально отказать в обслуживании жертве, используя скорость атаки, меньшую, чем при перегрузке пакетов методом перебора. Однако SYN-флуд и другие TCP-спуфинговые атаки имеют существенные различия. SYN flooding запрещает обслуживание новых соединений, не затрагивая выполняемые соединения, в то время как другие спуфинговые атаки нарушают работу входящих соединений, но не препятствуют запуску новых соединений. SYN-атаки могут быть защищены от изменения только начальной процедуры квитирования, в то время как другие спуфинговые атаки требуют дополнительных проверок для каждого сегмента в течение всего времени существования соединения. Общность между SYN-затоплением и другими атаками спуфинга TCP заключается в том, что они основаны на способности злоумышленника отправлять IP-пакеты с поддельными исходными адресами, и аналогичной защитой от этих атак будет удаление этой возможности посредством более универсального развертывания фильтрации адресов или IPsec. ,

Заключение

На момент написания этой статьи уязвимость, связанная с переполнением TCP SYN, была известна уже в течение десятилетия. В этой статье обсуждалось несколько решений, направленных на то, чтобы сделать эти атаки неэффективными, некоторые из которых легко доступны в коммерческих готовых продуктах или свободном программном обеспечении, но ни одно решение не было стандартизировано как часть функции TCP или промежуточного ящика на уровне IETF. Рабочая группа IETF по поддержке TCP и незначительным расширениям (TCPM) находится в процессе подготовки информационного документа, который объясняет положительные и отрицательные аспекты каждого из общих методов смягчения последствий [10], и читателям рекомендуется обратиться к этому документу для получения дополнительной информации. ,

По мнению автора, некоторый вариант метода кэширования SYN должен быть обязательной функцией для поиска в серверной операционной системе, и этот вариант может быть развернут в сочетании с другими сетевыми методами (фильтрация на основе адресов, спуфинговые брандмауэры с ACK-спуфингом). IPsec и т. Д.) В соответствующих ситуациях. Отрадно видеть, что разработчики протоколов извлекли урок из уязвимости, связанной с переполнением SYN в TCP, и сделали более современные протоколы по своей природе устойчивыми к таким атакам.

Подтверждения

Несколько отдельных участников рабочей группы IETF по TCPM предоставили биты данных, найденные в информационном документе группы о затоплении SYN [11], некоторые из которых по духу воспроизведены здесь.