Получен пакет без syn android

Разбор атак на части: SYN-flood

Spoofed SYN — атака, при которой заголовки пакетов подделывается таким образом, что место реального отправителя занимает произвольный либо несуществующий IP-адрес.

Дисклеймеры

Дисклеймер №1

Все, описанное в этом и последующих топиках – по сути не является know-how. Все методики – открытые, и в то или иное время (некоторые – от 2003 года) были опубликованы в открытых источниках. Я взял на себя труд только свести их в одно и описать «глобальную стратегию» защиты, ориентированную на системных администраторов, обслуживающих небольшие проекты, расположенные на выделенных серверах (описанную стратегию можно применить и в shared-проектах, но реализация будет настолько запредельно ужасной, что писать об этом нет никакого желания)

Дисклеймер №2

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

Дисклеймер №3

В топике не рассматриваются провайдеры защиты от DDoS-атак – сервис-инженеры этих организаций смогут описать их методы работы лучше и подробнее. Стоило бы, наверное, сделать обзор самих провайдеров как таковых — с точки зрения клиента (в разное время проекты, в которых я принимал участие, были клиентами Dragonara, Blacklotus, Gigenet, Vistnet (в настоящий момент), Prolexic (в настоящий момент) и ряда продавцов услуг вышеперечисленных компаний), но это выбивается из рамок топика, попробуем поговорить об этом позже. Опять же, стоит заметить что все провайдеры защиты, с которыми работают или работали проекты автора, справляются с проблемой SYN-атак, показывая хорошую эффективность.

Немного механики и википедии

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

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

В контексте статьи интересно рассмотреть механизм установки TCP-соединения – трехстороннее рукопожатие. В первом приближении на уровне «клиент-сервер» выглядит это вот так: клиент отправляет серверу SYN-пакет, на который отвечает SYN+ACK.Клиент отправляет в ответ ACK на SYN сервера и соединение переходит в состояние установленного.

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

Один в поле

Используй то, что под рукою, и не ищи себе другое – что можно сделать, находясь один на один с атакой? Честно говоря, не многое, но бывает, что хватает и этого. Далее описано, что делать с FreeBSD, так как в наших проектах в 90% случаев используется именно эта система. Впрочем, от ОС к ОС разница будет невелика – принципы одинаковы.

Первое – необходимо получить доступ к серверу (да, в этом тоже может быть сложность, особенно если атака масштабная и/или продолжительная – сервер просто выбрал все буферы или имеет 100% загрузку CPU). Обычно для этого достаточно закрыть атакуемый сервис фаерволом или просто его – сервис – погасить (впрочем, при обнаружении атаки это нужно сделать в любом случае, хотя бы для того, что бы иметь возможность делать на сервере что-то еще).

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

Третье – на интерфейсе, где расположен атакуемый IP-адрес должен остаться только он один. Каждый алиас будет снижать производительность системы. Выражается это в разных числах для разных систем, но числа эти – серьезные, каждый алиас может стоить дополнительных 2-3 тысяч пакетов в секунду.

Четвертое – если вы используете какой-либо фаерволл для входящего трафика по атакуемому адресу – все правила, кроме блокирования, должны быть отключены – к примеру, при spoofed SYN-атаке вероятность того, что вам поможет SYN-proxy от PF стремится к нулю, а CPU это займет очень серьезно.

Пятое – настраиваем систему. Чудес тут не будет, для них нужен рояль в кустах в виде подготовленных драйверов и специально купленных сетевых карт, а единственные две общие рекомендации, которые серьезно отражаются на возможности приема SYN-атаки давно всем известны:
— Размазать обработку прерываний по процессорам сервера;
— Включить syn-cookies и отключить syn-cache.

Остальной тюнинг системы поможет выжать дополнительные 5-10 тысяч пакетов, что в условиях атаки вряд ли окажется определяющим. На случай, если он кому-нибудь пригодится – вот максимально общий конфиг (без включения опций, требующих пересборки ядра или специализированных драйверов):

Система уровня десктопного компьютера, сконфигурированная в соответсвии с данными рекомендациями:

Система уровня IBM System x3630 M3, сконфигурированная в соответсвии с данными рекомендациями:

Детальные конфигурации ОС и машин, и, собственно, как мы пришли именно к ним — я попробую рассказать в следующем топике.

Одно дело делаем

Что делать помимо тюнинга системы В принципе, есть чем заняться.

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

Если хостер попался понимающий (что действительно большая редкость) – то работаем по следующему алгоритму — параллелим и блокируем, блокируем и параллелим:
Если у нас есть несколько сетевых карточек (если нет – просим поставить) – включаем их в режим LACP (для этого придется включить аналогичные опции на свитче хостера) – это даст фактически полуторный прирост производительности (отдельные тонкости процесса мы рассмотрим позже — объять необъятное в рамках топика никак не получается) Выходим вот к такой производительности:

Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой.
На эти действия способен фактически любая хостниг-компания. Но если вам посчастливилось работать с серьезной компанией — попросите заблокировать трафик из региона, где не проживает большая часть аудитории вашего проекта (например, Китай) – обычно это означает анонс блекхола для вашей сети для магистральных провайдеров определенного региона. Как правило, SYN-атака совершается из Азии, ввиду дешевизны и массовости, и, следовательно, такой анонс может серьезно помочь в борьбе с атакой либо вообще исключить ее возможность.

Помимо вышеописанных мер можно посоветовать использовать GeoDNS-like сервис – при некоторых условиях (атака ведется по домену, к примеру) это сработает аналогично анонсированию блекхола для определенных сетей.

Напоследок

Надеюсь, статья поможет вам справиться с проблемой SYN-флуда, не превысив годовой бюджет какой-нибудь африканской страны. Конечно, здесь даны только самые общие рекомендации, но поверьте – в 90% случаев их вполне достаточно. И главное — don’t panic!

UPD. Продолжение находится в стадии написания, и скоро будет выложено тут. Оставайтесь с нами!

Источник

Укрепление стека TCP/IP для защиты от SYN атак

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

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

В то время как невозможно полностью предотвратить 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 атака -это один из типов DDoS атак. Мы можем говорить, что хост жертвы подвергся SYN атаке, в случае, когда злоумышленник пытается создать огромное количество подключений в состоянии SYN RECEIVED до тех пор, пока не переполнится очередь соединений. Состояние SYN RECEIVED создается, когда хост жертвы получает запрос на подключение (пакет с набором флага SYN) и распределяет для этого некоторые ресурсы памяти. При SYN атаке создается такое количество полуоткрытых подключений, что система переполняется и больше не может обрабатывать поступающие запросы.

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

Мы должны знать, что процесс создания полного подключения занимает некоторое время. Первоначально, после получения запроса на подключение (пакет с набором флага SYN), хост жертвы помещает это полуоткрытое соединений в очередь и посылает первый ответ (пакет с флагами SYN и ACK). Если жертва не получает ответ от удаленного хоста, то она повторно передает SYN+ACK пакеты, до тех пор, пока не наступит тайм-аут, а затем удаляет это полуоткрытое соединение из очереди. В некоторых операционных системах этот процесс, для каждого отдельного SYN запроса, может занимать приблизительно 3 минуты! В этом документе Вы узнаете, как можно изменить эту закономерность. Другой, не менее важной информацией, которой Вы должны владеть является то, что операционная система может обрабатывать только определенное количество полуоткрытых подключений в очереди. Это количество управляется размером очереди соединений. Например, заданный по умолчанию размер очереди в RedHat 7.3 — 256, а в Windows 2000 Professional — 100. Когда размер очереди достигнет этого размера, система больше не будет принимать поступающие запросы.

Обнаружение 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 до момента установления соединения между клиентом и сервером. Операционная система распределяет часть системной памяти для каждого поступающего соединения. Мы знаем, что каждый tcp порт может обрабатывать только определенное количество поступающих запросов. Очередь соединений управляет количеством полуоткрытых подключений, способных одновременно обрабатываться операционной системой. Когда количество поступающих соединений достигнет максимального уровня, все последующие запросы будут отклонены операционной системой.

Как упомянуто выше, обнаружение большого количества соединений в состоянии 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 равно 1, количество повторных передач уменьшено, а маршрутизация содержимого кеша отсрочена до создания соединения. Рекомендуемое значение SynAttackProtect — 2, при котором дополнительно задерживается признак соединения с Windows Socket до установления связи сервера с клиентом. В ходе нападения, лучшая производительность в обработке соединений достигается с помощью отключения нескольких параметров (эти параметры обычно используются системой в течение процесса создания новых соединений). Параметр TCPINITIALRTT, определяющий время первой перепередачи, больше не будет использоваться.

Как мы можем увидеть, включение параметра SynAttackProtect не изменяет режим работы стека TCP/IP до и при SYN атаке. Но даже при включенном параметре SynAttackProtect, операционная система может обрабатывать легальные поступающие соединения.

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

Чтобы изменить значения этих параметров, сначала мы должны добавить их к тому же самому ключу системного реестра, как и в случае с SynAttackProtect.

Элемент системного реестра TcpMaxHalfOpen определяет максимальное количество состояний SYN RECEIVED, которые могут быть одновременно обработаны, прежде чем сработает SYN защита. Рекомендуемое значение этого параметра — 100 для Windows 2000 Server и 500 для Windows 2000 Advanced Server.

TcpMaxHalfOpenRetried определяет максимальное количество полуоткрытых подключений, для которых операционная система выполнила по крайней мере одну повторную передачу, прежде, чем сработает SYN защита. Рекомендуемое значение — 80 для Windows 2000 Server, и 400 для Advanced Server.

Элемент системного реестра TcpMaxPortsExhausted определяет число отклоненных SYN запросов, после которого сработает защита от SYN атак. Рекомендованное значение — 5.

Операционная система: Linux RedHat

В RedHat, как и в других Linux системах, осуществлен механизм SYN cookies, который включается следующим способом:

* ECHO 1 >/proc/sys/net/ipv4/tcp_syncookies

Обратите внимание, что для того чтобы сделать это изменение постоянным, мы должны создать загрузочный файл, который будет присваивать значение этой переменной. Мы должны проделать ту же самую операцию и для других UNIX переменных, описанных в этой статье, потому что значения этих переменных после перезагрузки системы вернуться к прежним значениям.

Защита SYN cookies особенно полезна, в случае, когда система подверглась SYN атаке, а исходные IP адреса пакетов — фиктивные (SYN спуфинг). Этот механизм позволяет структурировать пакеты с набором флагов SYN и ACK, которые имеют специально обработанный «начальный номер последовательности» (ISN), называемый cookie. Значение cookie это не псевдослучайное число, сгенерированное системой, а результат действия хеш-функции. Это значение генерируется хеш-функцией в зависимости от следующей информации: IP-адрес источника, порт источника, IP адрес получателя, порт получателя плюс некоторые секретные значения. В ходе SYN атаки, когда заполняется очередь соединений, система вместо отклонения запроса, генерирует ответ, посылая клиенту пакет с cookie. Когда сервер получает пакет с набором флажка ACK (последняя стадия процесса установления соединения с клиентом), тогда он проверяет значение cookie. Если это значение правильно, то сервер создает подключение, даже в случае если нет никакого соответствующего элемента в очереди соединений. В этом случае мы знаем, что это легальное соединение, и что исходный IP адрес не фиктивный. Важно обратить внимание на то, что механизм работы SYN cookie, вообще не использует очередь соединений, так что теперь мы не должны изменять её размер. Более подробную информацию об использовании SYN cookies можно найти здесь.

Также необходимо обратить внимание на то, что механизм SYN cookies работает только когда опция CONFIG_SYNCOOKIES установлена в ходе компиляции ядра системы.

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

Увеличение размера очереди соединений

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

Увеличение размера очереди задач требует, чтобы система резервировала дополнительные ресурсы памяти для входящих соединений. Если в системе отсутствует достаточное количество свободной памяти для этой операции, то пострадает производительность системы. Также мы должны удостовериться, что сетевые приложения (Apache, IIS и т.д.) смогут принимать большее количество подключений.

Операционная система: Windows 2000

Кроме описанных выше переменных TcpMaxHalfOpen и TcpMaxHalfOpenRetried, в Windows 2000 количество полуоткрытых подключений может быть установлено через динамическую очередь соединений. Конфигурирование этой очереди выполняется через драйвер AFD.SYS. Этот драйвер используется для поддержки Windows Socket приложений (FTP, Telnet и т.д.). Для увеличения количества полуоткрытых соединений, AFD.SYS поддерживает четыре элемента системного реестра. Все эти значения расположены в следующем ключе системного реестра:

Значение системного реестра EnableDynamicBacklog — глобальный переключатель, включающий или выключающий динамическую очередь соединений. Значение 1 — включает динамическую очередь.

MinimumDynamicBacklog — управляет минимальным количеством свободных соединений, разрешенных на каждом отдельном TCP порте. Если количество свободных соединений снижается ниже этого значения, то дополнительные свободные соединения будут созданы автоматически. Рекомендованное значение 20.

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

Последний параметр DynamicBacklogGrowthDelta управляет количеством свободных соединений, создаваемых в случае необходимости. Рекомендуемое значение: 10.

Ниже расположена таблица, показывающая рекомендуемые значения для драйвера AFD.SYS:

Источник