A SYN flood is a form of denial-of-service attack in which an attacker sends a progression of SYN requests to an objective’s framework trying to consume enough server assets to make the framework inert to authentic activity.

TCP three-way handshake

Typically, when a customer begins a TCP connection with a server, the customer and server trade a progression of messages which regularly runs this way:

1) The customer asks for a connection by sending a SYN (synchronize) message to the server.

2) The server recognizes this request by sending SYN-ACK back to the customer.

3) The customer reacts with an ACK, and the connection is built up.

This is known as the TCP three-way handshake, and is the establishment for each connection set up utilizing the TCP protocol.

Working of SYN flood attack

A SYN flood attack works by not reacting to the server with the normal ACK code. The pernicious customer can either basically not send the normal ACK, or by satirizing the source IP address in the SYN, bringing about the server to send the SYN-ACK to a distorted IP address – which won’t send an ACK on the grounds that it “knows” that it never sent a SYN.

The server will sit tight for the affirmation for quite a while, as straightforward system clog could likewise be the reason for the missing ACK. In any case, in an attack, the half-open connections made by the pernicious customer tie resources on the server and may in the long run surpass the resources accessible on the server. By then, the server can’t be access by any customers.

Security against SYN Flood Attacks

There are various surely understood countermeasures including:

1) Filtering

2) Increasing Backlog

3) TCP half-open: The term half-open alludes to TCP associations whose state is out of synchronization between the two potentially because of an accident on one side. A connection which is being set up is otherwise called a embryonic connection. The absence of synchronization could be because of malignant purpose. A TCP connection is alluded to as half-open when the host toward one side of that TCP association has slammed, or has generally evacuated the attachment without informing the flip side. In the event that the rest of the end is inert, the association may stay in the half-open state for unbounded time frames. These days, the term half-open association is regularly used to portray an embryonic connection, i.e. a TCP connection which is being set up.

The TCP convention has a three state framework for opening a connection. To begin with, the beginning endpoint (A) sends a SYN bundle to the destination (B). A is currently in an embryonic state (particularly, SYN_SENT), and anticipating a reaction. B now redesigns its portion data to demonstrate the approaching connection from A, and conveys a request to open a channel back (the SYN/ACK bundle). Now, B is additionally in an embryonic state (particularly, SYN_RCVD). Note that B was put into this state by another machine, outside of B’s control.

Under typical conditions (see foreswearing of-administration attack for conscious disappointment cases), A will get the SYN/ACK from B, overhaul its tables (which now have enough data for A to both send and get), and send a last ACK back to B. When B gets this last ACK, it additionally has adequate data for two-way correspondence, and the connection is completely open. Both endpoints are currently in an established state.

4) Firewalls and Proxies

5) Reducing SYN-RECEIVED Timer

6) SYN Cache

7) Recycling the Oldest Half-Open TCP

8) Hybrid Approaches

9) SYN cookies: SYN cookie is a strategy used to oppose SYN surge assaults. Daniel J. Bernstein, the procedure’s essential creator, characterizes SYN treats as “specific decisions of beginning TCP arrangement numbers by TCP servers”. The utilization of SYN treats permits a server to abstain from dropping associations when the SYN line tops off. Rather, the server carries on as though the SYN line had been amplified. The server sends back the suitable SYN+ACK reaction to the customer yet disposes of the SYN line section. In the event that the server then gets a resulting ACK reaction from the customer, the server can reproduce the SYN line section utilizing data encoded as a part of the TCP succession number.

If you need any further assistance please contact our support department.

Собственно, речь пойдет о защите от SYN flood атак:

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

Определить SYN атаку просто - команда netstat выдает огромный список полуоткрытых подключений:

Netstat -n --tcp | grep SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1084 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1228 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:2652 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:3446 SYN_RECV

Netstat -n --tcp | grep SYN_RECV | wc -l 238

Для начала - проверяем параметр tcp_syncookies - он должен быть равен 1:

Cat /proc/sys/net/ipv4/tcp_syncookies 1

Так и оставляем. По умолчанию в новых дистрибутивах этот параметр всегда включен.

Если параметр tcp_syncookies установлен (доступен только когда ядро собрано с CONFIG_SYNCOOKIES), тогда ядро обрабатывает SYN пакеты TCP в обычном режиме до тех пор, пока очередь не заполнится. После заполнения очереди включается механизм SYN cookies.

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

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

Также нужно увеличить очередь полуоткрытых соединений - tcp_max_syn_backlog (в Debian Lenny по-умолчанию 1024 соединения):

Cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1024

Увеличиваем:

Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog

Кроме того, можем уменьшить время ожидания соединения tcp_synack_retries :

Целочисленное значение (1 байт) tcp_synack_retries определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP. Число попыток не должно превышать 255. Используемое по умолчанию значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения.

Уменьшаем до 1 (это примерно 9 секунд):

Echo "1" > /proc/sys/net/ipv4/tcp_synack_retries

tcp_fin_timeout

Целое число в файле tcp_fin_timeout определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Партнер может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд. В ядрах серии 2.2 обычно использовалось значение 180 секунд и вы можете сохранить это значение, но не следует забывать, что на загруженных WEB-серверах вы рискуете израсходовать много памяти на сохранение полуразорванных мертвых соединений. Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1, поскольку поглощают не более 1,5 Кбайт памяти, но они могут существовать дольше.

Меняем на 30:

Echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout

tcp_keepalive_probes

Целочисленная переменная tcp_keepalive_probes задает число передач проб keepalive, после которого соединение считается разорванным. По умолчанию передается 9 проб.

Echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes

tcp_keepalive_intvl

Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.

Ставим 15:

Echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl

netdev_max_backlog

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

Cat /proc/sys/net/core/netdev_max_backlog 1000

Увеличиваем:

Echo "20000" > /proc/sys/net/core/netdev_max_backlog

somaxconn

Максимальное число открытых сокетов, ждущих соединения.

Cat 1024

Увеличиваем:

Echo "20000" > /proc/sys/net/core/somaxconn

Так как подобные изменения параметров ядра не сохранятся после перезагрузки - добавляем в /etc/rc.local :

Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog echo "1" > /proc/sys/net/ipv4/tcp_synack_retries echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl echo "20000" > /proc/sys/net/core/netdev_max_backlog echo "20000" > /proc/sys/net/core/somaxconn

Кроме того, можно добавить ограничение числа SYN пакетов в единицу времени в iptables:

Iptables -N syn_flood iptables -A INPUT -p tcp --syn -j syn_flood iptables -A syn_flood -m limit --limit 500/s --limit-burst 1500 -j RETURN iptables -A syn_flood -j DROP

Число новых SYN пакетов - максимум 500 в секунду, при превышении порога в 1500 - новые пакеты блокируются:

Более наглядно этот критерий можно представить себе как некоторую емкость с выпускным отверстием, через которое проходит определенное число пакетов за единицу времени (т.е. скорость «вытекания»). Скорость «вытекания» как раз и определяет величина --limit. Величина --limit-burst задает общий «объем емкости». А теперь представим себе правило --limit 3/minute --limit-burst 5, тогда после поступления 5 пакетов (за очень короткий промежуток времени), емкость «наполнится» и каждый последующий пакет будет вызывать «переполнение» емкости, т.е. «срабатывание» критерия. Через 20 секунд «уровень» в емкости будет понижен (в соответствии с величиной --limit), таким образом она готова будет принять еще один пакет, не вызывая «переполнения» емкости, т.е. срабатывания критерия.

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

Alexander Antipov

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

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

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

Кроме стандартных сырых сокетов, 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-атаки на превышение пропускной способности канала.

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-флудом . Главное, не забывать о поддержании безопасности своего сервера от ДДоС и уделять ей должное внимание. Самое лучшее – позаботиться о

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

Дисклеймеры

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

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

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

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

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

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

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

Один в поле

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

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

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

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

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

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

Net.isr.direct=1 kern.ipc.nmbclusters=400000 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=32768 net.inet.tcp.msl=5000 net.inet.tcp.blackhole=1 net.inet.ip.intr_queue_maxlen=3000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.log_redirect=1 net.inet.ip.redirect=0 net.inet.icmp.maskrepl=1 net.inet.tcp.syncookies_only=1 net.route.netisr_maxqlen=4096 kern.ipc.maxsockbuf=83886080 net.inet.ip.intr_queue_maxlen=10240
Система уровня десктопного компьютера, сконфигурированная в соответсвии с данными рекомендациями:

First# netstat -w1 -h -d input (Total) output packets errs idrops bytes packets errs bytes colls drops 260K 0 0 15M 230K 0 13M 0 0
Система уровня IBM System x3630 M3, сконфигурированная в соответсвии с данными рекомендациями:

Second# netstat -w1 -h -d input (Total) output packets errs idrops bytes packets errs bytes colls drops 477K 0 0 36M 457K 0 25M 0 0
Детальные конфигурации ОС и машин, и, собственно, как мы пришли именно к ним - я попробую рассказать в следующем топике.

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

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

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

Second# netstat -w1 -h -d input (Total) output packets errs idrops bytes packets errs bytes colls drops 1.2M 16K 0 65M 1.1M 0 59M 0 0
Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой.
На эти действия способен фактически любая хостниг-компания. Но если вам посчастливилось работать с серьезной компанией - попросите заблокировать трафик из региона, где не проживает большая часть аудитории вашего проекта (например, Китай) – обычно это означает анонс блекхола для вашей сети для магистральных провайдеров определенного региона. Как правило, SYN-атака совершается из Азии, ввиду дешевизны и массовости, и, следовательно, такой анонс может серьезно помочь в борьбе с атакой либо вообще исключить ее возможность.

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

Напоследок

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