11.11.2012

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

Существует несколько типов DDoS-атак с применением флуда, основные из них перечислены ниже:

SYN-ACK-флуд
HTTP-флуд
ICMP-флуд
UDP-флуд

SYN-ACK-флуд

SYN-ACK-флуд – один из типов сетевых атак , который основан на отправке огромного количества SYN-запросов в единицу времени. Результатом станет выведение из строя сервиса, работа которого была основана на TCP протоколе. Сначала клиент оправляет на сервер пакет, содержащий SYN-флаг, наличие которого говорит о желании клиент установить соединение. Сервер, в свою очередь, посылает пакет-ответ. В нем кроме SYN-флага имеется и ACK-флаг, который обращает внимание клиента на то, что запрос принят и ожидается подтверждение установления соединения со стороны клиента. Тот отвечает пакетом с ACK-флагом о успешном соединения. Все запросы на «коннект» от клиентов сервер хранит в очереди определенного размера. Запросы хранятся в очереди до возвращения от клиента ACK-флага. SYN-атака основана на отправке серверу пакетов с несуществующего источника, количеством превышающим размер очереди. Сервер, попросту не сможет ответить на пакет по вымышленному адресу. Очередь не будет уменьшаться и сервис перестанет функционировать.

HTTP-flood

HTTP-flood - применяется в случае работы сервиса с базой данных . Атака нацелена либо на web-сервер , либо на скрипт работающий с базой. Отправляется огромное количество запросов GET на 80 порт, дабы web-сервер не смог уделять должное внимание запросам другого типа. Log-файлы увеличиваются, а работа с базой данных становиться невозможной.

ICMP-флуд

ICMP-флуд – простой способ уменьшения пропускной способности и увеличения нагрузок на стек по средствам отправки однотипных запросов ICMP PING. Опасен в случае малого уделения внимания сетевым экранам, так как сервер, отвечающий на бесконечные запросы ECHO, обречен. Так что в случае одинакового количества входящего и исходящего трафика просто пропишите правила в iptables .

UDP-флуд

UDP-флуд – очередной способ захламления пропускной полосы , основанный на работе с протоколом, который не требует синхронизации перед отправкой данных. Атака сводится к обычной посылке пакета на UDP порт сервера. После получения пакета, сервер начинает его усиленно обрабатывать. Затем клиент отправляет Udp-пакеты некорректного содержания один за одним. В результате порты перестанут функционировать и система даст сбой.

В принципе, на определение типа DDoS-атаки зачастую не обязательно тратить много времени. Достаточно знать несколько признаков. Если значительно увеличился размер logфайлов – Вы имеете дело с HTTP-флудом . Если ограничен доступ к сервису в результате превышения количества допустимых соединений – это SYN-ACK-флуд . В случае, если исходящий и входящий трафик приблизительно равны – Вы имеете дело с ICMP-флудом . Главное, не забывать о поддержании безопасности своего сервера от ДДоС и уделять ей должное внимание. Самое лучшее – позаботиться о

syn-flood атака - практика

Alexander Antipov

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

Проблемы, не зависящие от атакующего.

Программная реализация.

Для реализации подходит как unix, так и windows-платформы. Программа должна запускаться с правами root и администратора соответственно. Под unix много готовых реализаций, например, synk4.c (искать поисковиками). Специализированные для координированых DDoS-атак реализации найти сложнее, но при минимальных навыках программирования можно доработать существующие или создать свои.

Кроме стандартных сырых сокетов, D0minat0r из Nerf нашел очень красивый способ реализации SYN flood под linux, на других юниксоподобных не тестировалось, на win не работает. Linux позволяет root"у биндить сокет к любому адресу, в т.ч. не принадлежащему локальному хосту. После этого можно вызывать connect() для этого сокета, и локальный хост пошлет SYN-пакет от адреса, к которому прибинжен сокет. Если сокет был в неблокирующем режиме, то сразу после connect() можно вызывать close(), и повторять операцию.

Реализации под windows встречаются реже, из-за расхожего мифа о невозможности генерации сырых пакетов в этой OS. На самом деле, win98 поддерживает сырые сокеты уровня до заголовка IP, а win2k и XP - и заголовок тоже (опция IP_HDRINCL), т.е. реализация атаки под win2k и XP отличается от юниксовской лишь несколькими строчками. Готовая реализация от меня, проверенная на win2k, лежала одно время на www.nerf.ru, но после смены хостинга, моего ухода из этой группы и форматцевта потерялась. Если у кого-то сохранилась - свяжитесь, плиз, выложу.

Механизмы защиты OS от SYN-flood.

a) Стандартный таумаут. Полуоткрытые соединения по прошествии некоторого времени выбрасываются из буфера. При истощении буфера запросы клиентов на подключение будут проходить с вероятностью C1/C2, где C1 - количество SYN-пакетов от клиента, C2 - количество SYN-пакетов от всех остальных (включая атакующего). Даже при нагрузке на канал атакующего в 6 пакетов в секунду C1/C2 - примерно 1/100, т.е. служба выведена из строя на 99%.

б) Безлимитный буфер полуоткрытых соединений. При нагрузке на канал атакующего 100 Mb/сек и таймауту около минуты очередь полуоткрытых соединений будет занимать примерно 1 Gb памяти, что для крупных серверов не смертельно. Побочный эффект: атакуемый сервер отвечает трафиком, в 3 раза большим, чем трафик атакующего (говорят, что происходит DDoS с умножением в 4 раза), что может привести к истощению пропускной способности канала. Однако, при невозможности истощить ширину канала, защита от атаки будет абсолютной, ни одно клиентское соединение не будет отвергнуто.

в) Очистка наиболее старых полуоткрытых соединений. При переполнении буфера из него удаляется самое старое полуоткрытое соединение. Побочный эффект: если при атаке буфер заполняется за время t, то клиент не сможет подключиться во время атаки, если время подтверждения соединения больше t - его запрос тоже будет выброшен. Например, для нагрузки канала атакующего 4 Мбит/сек и длины буфера 512 (рекомендуемое значение для Win2K) время t - около 50 msec, что гарантированно отбросит все попытки подключения к серверу с диалапа и многие - с выделенных линий. Увеличивая размер буфера, защиту можно свести к предыдущему варианту.

г) SYN COOKIE. После истощения буфера информация, которая не помещается в буфер, отсылается клиенту, который якобы запросил ее. Если клиент - настоящий, то он возвращает информацию обратно, если поддельный - она теряется, причем механизм реализован в рамках RFC по TCP, т.е. его поддерживают и клиенты, не знакомые с этой технологией. Операционная система c SYN COOKIE, независимо от размера буфера полуоткрытых соединений, совершенно неуязвима для SYN-flood атак. Побочный эффект: запрет "больших окон".

Резюме: SYN-flood атака морально устарела, и сегодня может использоваться в лучшем случае в качестве обычной flood-атаки на превышение пропускной способности канала.

DoS/DDoS-атаки направлены на нарушение базовой услуги доступности. Основная цель DoS/DDoS-атак вывести атакуемый объект из рабочего состояния и сделать его ресурсы недоступными для легальных пользователей. Атаку, направленную на отказ в обслуживании, можно провести двумя способами: используя уязвимости в программном обеспечении атакуемой системы и при помощи отсылки большого количества определенно составленных сетевых пакетов (flood).

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

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

Для многих DoS/DDoS атак результаты обработки сервером пакетов, отправленных злоумышленником, последнего не интересуют. Это значит, что атакующий может отправлять поток ложных заявок с ложных IP адресов (это понятие называется spoofing), что препятствует его обнаружению и эффективному противодействию такого рода атакам.

Для проведения успешной DoS-атаки необходима довольно высокая пропускная способность канала. Поэтому атака на отказ в обслуживании в большинстве случаев проводится сразу с нескольких машин. Атака, в проведении которой участвует большое количество машин, получила название DDoS. Стоит отметить, что для распределенной атаки могут использоваться инфицированные специальным ПО машины не принадлежащие атакующему. Такие зараженные машины называются "зомби". Одним из способов получения "зомби" является массовое внедрение "трояна" на компьютеры мирных пользователей. Получив определенную извне команду такой "троян" превращает "мирный" компьютер с доступом в Internet в источник ложных запросов, направленных на перегрузку ресурсов сервера.

Наиболее распространенными DoS атаками являются:

· TCP SYN Flood или просто TCP SYN

· Ping of Death

Рассмотрим подробнее TCP SYN (tcp syn flood) атаку, которая направлена на прикладные сервисы, использующие протокол транспортного уровня TCP. Этот протокол получил широкое распространение в информационных системах за счет того, что он гарантирует 100% доставку всех передаваемых данных. Взаимодействующие узлы сети, использующие в качестве транспорта этот протокол, устанавливают между собой TCP соединения, в рамках которых ведется контроль над тем, что получатель получит все посланные отправителем пакеты. Это достигается за счет того, что получатель извещает отправителя о том, какие пакеты он получил. Если до получателя дошли не все предназначенные ему пакеты, то отправитель повторно их отправит. Как видно достоинством этого протокола является возможность установления соединения. Для хранения информации о текущем состоянии соединения в частности используется поле битовых флагов в пакетах, используемых протоколом. Под это поле отведено 8 бит, однако 2 из них являются зарезервированными и в настоящее время используются только 6 флагов: URG (флаг срочности), ACK (флаг подтверждения), PSH (флаг push функции), RST (флаг сброса), SYN (флаг синхронизации) и FIN (флаг окончания). К сожалению, установленный стандартом механизм установления соединения не является совершенным, и рассматриваемая атака, как раз использует его недостатки.

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

процедура изображена на рис. 1.1

Рис. 1.1

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

Отсутствие обратной связи с атакующим делает обнаружение и отражение TCP-SYN атаки довольно сложной задачей.

Постановка задач по защите от угроз

В настоящее время в открытой литературе не известны эффективные методы обнаружения TCP SYN атак. В современных ОС присутствуют механизмы защиты атакуемого сервера, например SYN cookies. Операционная система автоматически включает защиту, когда обнаруживает превышение значений некоторых параметров. Например, ОС Windows 2000 следит за значениями трех параметров: TcpMaxHalfOpen, TcpMaxHalfOpenRetried, TcpMaxPortsExhausted . Пороговые значения для этих параметров имеют значения по умолчанию и могут меняться администратором. Если исходные значения не подходят для конкретного сервера, то перед администратором стоит непростая задача эффективно настроить защиту. Кроме того, этот метод требует внесения соответствующих изменений в реализацию стека TCP/IP, которые некоторые специалисты в области сетевых технологий считают "серьезным нарушением" протокола TCP.

Другим недостатком средств обнаружения TCP атаки интегрированных в ОС является то, что при перегрузке (имеется в виду нехватка ресурсов процессора и памяти) или зависании самой системы средства противодействия так же становятся неработоспособными.

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

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

DoS (аббр. Denial of Service «отказ в обслуживании») - хакерская атака на вычислительную систему с целью довести её до отказа, то есть создание таких условий, при которых добросовестные пользователи системы не могут получить доступ к предоставляемым системным ресурсам (серверам), либо этот доступ затруднён.

Существует два типа DoS-атака /DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них.

Обнаружение DoS-атак

SYN-флуд

Наличие SYN- флуда устанавливается легко - через подсчет числа «полуоткрытых» TCP- соединений. В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3).

Защита от DoS-атак

Блокирует фрагменты - пакетов. Так как, в силу функционального назначения протокола, ICMP-пакеты должны быть очень небольшими и нормально укладываться в MTU , наличие их фрагментов обычно свидетельствует об ошибке или попытке атаки. iptables -A INPUT -p icmp -f -j DROP

Запретить Спуфинг от вашего имени. iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-level info --log-prefix "DROP SYN,ACK: " iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

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

SYN-флуд

Один из распространенных способов не только забить канал связи, но и ввести сетевой стек операционной системы в такое состояние, когда он уже не сможет принимать новые запросы на подключение. Основан на попытке инициализации большого числа одновременных TCP-соединений через посылку SYN-пакета с несуществующим обратным адресом. После нескольких попыток отослать ответный ACK-пакет на недоступный адрес большинство операционок ставят неустановленное соединение в очередь. И только после n-ой попытки закрывают соединение. Так как поток ACK-пакетов очень велик, вскоре очередь оказывается заполненной, и ядро дает отказ на попытки открыть новое соединение. Наиболее умные DoS-боты еще и анализируют систему перед началом атаки, чтобы слать запросы только на открытые жизненно важные порты. Идентифицировать такую атаку просто: достаточно попробовать подключиться к одному из сервисов. Оборонительные мероприятия обычно включают в себя:

Увеличение очереди «полуоткрытых» TCP-соединений:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

Уменьшение времени удержания «полуоткрытых» соединений:

# sysctl -w net.ipv4.tcp_synack_retries=1

Включение механизма TCP syncookies:

# sysctl -w net.ipv4.tcp_syncookies=1

UDP-флуд

Метод захламления полосы пропускания. Основан на бесконечной посылке UDP-пакетов на порты различных UDP-сервисов. Легко устраняется за счет отрезания таких сервисов от внешнего мира и установки лимита на количество соединений в единицу времени.

#Ставим ограничение на 5 соединений на 80 порт. iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j REJECT # Разрешаем только одно одновременное соединение с одного айпи на smtp iptables -A FORWARD -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP #Ставим ограничение на 200 соединений на 1720 порт. iptables -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 200 -j REJECT # udp 5060 $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 5060: " $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j REJECT # tcp 1720 $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 1720: " $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j REJECT

ICMP- флуд

Очень примитивный метод забивания полосы пропускания и создания нагрузок на сетевой стек через монотонную посылку запросов ICMP протокол диагностики перегрузки сети ECHO (пинг). Легко обнаруживается с помощью анализа потоков трафика в обе стороны: во время атаки типа ICMP-флуд они практически идентичны. Почти безболезненный способ абсолютной защиты основан на отключении ответов на запросы ICMP ECHO:

Sysctl net.ipv4.icmp_echo_ignore_all=1

Или с помощью брандмауэра:

Iptables -A INPUT -p icmp -j DROP --icmp-type 8

HTTP-флуд

Количество процессов ps aux | grep apache | wc -l

Количество конектов на 80 порту netstat -na | grep ":80\ " | wc -l

Просмотреть список IP- адресов, с которых идут запросы на подключение: netstat -na | grep ":80\ " | sort | uniq -c | sort -nr

sysctl

Защита от спуфинга net.ipv4.conf.default.rp_filter = 1

Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная машина, она сразу ответит. Дефолтовое значение - 2 часа. net.ipv4.tcp_keepalive_time = 60

Повторить пробу через десять секунд net.ipv4.tcp_keepalive_intvl = 10

Количество проверок перед закрытием соединения net.ipv4.tcp_keepalive_probes = 5

Debian: борьба с DDoS

По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом. Необходимо внести изменения в настройки ядра, чтобы укрепить стек TCP/IP. Пример такой конфигурации:

Net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.core.rmem_max = 996777216 net.core.wmem_max = 996777216 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_mem= 786432 1048576 996777216 net.ipv4.tcp_wmem = 4096 87380 4194304 net.ipv4.tcp_max_orphans = 2255360 net.core.netdev_max_backlog = 10000 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 494967295 kernel.shmall = 268435456 net.core.somaxconn= 16096

Аккуратно меняем конфигурацию ядра и перезагружаем сервер…

FreeBSD: борьба с DDoS

Уменьшаем время ожидания ответного пакета на запрос SYN-ACK (защита от SYN-флуда):

# sysctl net.inet.tcp.msl=7500

Превращаем сервер в черную дыру. Так ядро не будет слать ответные пакеты при попытке подключиться к незанятым портам (снижает нагрузку на машину во время DDoS"а на случайные порты):

# sysctl net.inet.tcp.blackhole=2 # sysctl net.inet.udp.blackhole=1

Ограничиваем число ответов на ICMP-сообщения 50-ю в секунду (защита от ICMP-флуда):

# sysctl net.inet.icmp.icmplim=50

Увеличиваем максимальное количество подключений к серверу (защита от всех видов DDoS):

# sysctl kern.ipc.somaxconn=32768

Включаем DEVICE_POLLING - самостоятельный опрос сетевого драйвера ядром на высоких нагрузках (существенно снижает нагрузку на систему во время DDoS"а):

Пересобираем ядро с опцией «options DEVICE_POLLING»; Активируем механизм поллинга: «sysctl kern.polling.enable=1»; Добавляем запись «kern.polling.enable=1» в /etc/sysctl.conf.

Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:

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

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

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

На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика (NetFlow в помощь), которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.

SYN flood attack is a form of denial-of-service attack in which an attacker sends a large number of SYN requests to a target system’s services that use TCP protocol. This consumes the server resources to make the system unresponsive to even legitimate traffic. This attack can occur on any services that use TCP protocol but mainly on web service. In this tutorial, we will go through the basics of SYN flood attacks and the mitigation steps in detail.

The SYN Flood attack exploits an implementation characteristic of the Transmission Control Protocol (TCP), which is called 3-way handshake. Following are the steps that occur in a normal 3-way handshake:

1. The client requests a connection by sending a SYN (synchronize) message to the server.
2. The server acknowledges this request by sending SYN-ACK back to the client.
3. The client responds with an ACK, and the connection is established.

A SYN flood attack works by not responding to the server with the expected ACK code. By these half-open connections, the target machines TCP backlog will get filled up and hence all new connections may get ignored. This will cause the legitimate users to also get ignored.

This attack can take place in two ways:

1. Direct Attack

In this kind of attack, attackers rapidly send SYN segments without spoofing their IP source address. When detected, this type of attack is very easy to defend, because we can add a simple firewall rule to block packets with the attacker"s source IP address which will the attack.

2. Using Ip address Spoofing

This is a more complex form of attack than the direct attack. In this method, the malicious machine will send SYN request floods to the target machine from spoofed IP addresses, causing the server to send the SYN-ACK to a falsified IP address - which will not send an ACK because it "knows" that it never sent a SYN.

Detecting SYN flood Attack

The generic symptom of SYN Flood attack to a web site visitor is that a site takes a long time to load, or loads some elements of a page but not others. If you suspect a SYN Flood attack on a web server, you can use to check the web server connection requests that are in “SYN_RECEIVED” state.

netstat -tuna | grep:80 | grep SYN_RECV

If it shows numerous connections with this state, the server could be under SYN Flood attack. If the attack is direct with large number of SYN_RECV packets from a single IP address, you can stop this attack by adding that IP address in the firewall. If you have APF or firewall installed on your server, you can accomplish this by executing the following command:

apf –d IPADDRESS
csf –d IPADDRESS

Defending SYN Flood Attack

Using SYN cookies

This is the most effective method of defending from SYN Flood attack. The use of SYN cookies allow a server to avoid dropping connections when the SYN queue fills up. Instead, the server behaves as if the SYN queue has been enlarged. The server sends back the appropriate SYN+ACK response to the client but discards the SYN queue entry. If the server then receives a subsequent ACK response from the client, it is able to reconstruct the SYN queue entry using information encoded in the TCP sequence number.

SYN cookies can be enabled by adding the following to /etc/sysctl.conf

net.ipv4.tcp_syncookies = 1

After modifying the sysctl configuration file, you need to execute the following command to load sysctl settings from the file /etc/sysctl.conf

Increasing the SYN backlog queue

An optional defending technique is to increase the SYS backlog queue size. The default size is 1024. This can be done by adding the following to /etc/sysctl.conf

net.ipv4.tcp_max_syn_backlog = 2048

Reducing SYN_ACK retries

Tweaking the kernel parameter tcp_synack_retries causes the kernel to close the SYN_RECV state connections earlier. Default value is 5.

net.ipv4.tcp_synack_retries = 3

Setting SYN_RECV timeout

Lowering the timeout value for SYN_RECV will help in reducing the SYN flood attack. The default value is 60 and we can reduce it to 40 or 45. This can be done by adding the following line to sysctl.conf.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45

Preventing IP spoofing

The following sysctl parameter will help to protect against IP spoofing which is used for SYN flood attacks.

net.ipv4.conf.all.rp_filter = 1

Many hosting companies provide protection against SYN attack by deploying firewalls that employ SYN flood defense such as Netscreen or Appsafe.