SYN Flood

 

SYN-Flood – это одна из разновидностей DDOS атак вызывающая переполнение сетевого стека операционной системы, вследствие чего ОС не сможет больше принимать подключения и ваш веб-сервер будет в подвешенном состоянии.

 

Содержание

  • 1 Установка соединения или что такое TCP?
  • 2 Ddos уязвимость или как нам воспользоваться столь сложной схемой?
  • 3 Как вычислить SYN-Flood?
  • 4 Как защитить себя от DDOS?
  • 4 Рекомендации по защите NTP сервера

 

Установка соединения или что такое TCP?

 

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

TCP Session

 

Теперь поподробнее

 

Процесс начала сеанса TCP (также называемый «рукопожатие» (handshake)), состоит из трёх шагов.

 

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

б. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK. Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED. Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться. Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

в. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED. Процесс называется «трёхэтапным согласованием» (three way handshake), так как несмотря на то что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента.

 

Ddos уязвимость или как нам воспользоваться столь сложной схемой?

 

Злоумышленник генерирует большое количество Syn-запросов с рандомных source ip и направляет их на веб-сервер жертвы. Веб-сервер жертвы принимает запрос и направляет ему ответ SYN-ACK в сторону несуществующего адреса и вот тут самое главное! Веб-сервер Жертвы (в зависимости от настройки сетевого стека ОС) ожидает N-ое кол-во секунд подтверждения от несуществующего IP тем самым оставляя это соединение в открытом состоянии, подождав это время он повторно отправляет запрос и ждет. Так происходит несколько раз после чего соединение закрывается. А теперь умножьте это число на несколько тысяч запросов в секунду? Конечно Веб-сервер не справится и сервис будет не доступен.

 

Как вычислить SYN-Flood?

 

Идентифицировать такую атаку просто: достаточно попробовать подключиться к одному из сервисов. К примеру по telnet на 80 порт.

 

Ресурс доступен

telnet google.com 80

Trying 173.194.44.72…

Connected to google.com.

Escape character is ‘^]’.

asd

HTTP/1.0 400 Bad Request

Content-Type: text/html; charset=UTF-8

Content-Length: 1555

Date: Tue, 11 Oct 2016 15:46:38 GMT

 

 

 

Ресурс недоступен

telnet google.com

Trying 173.194.44.72…

Closed by Host

 

 

Как защитить себя от DDOS?

 

Здесь приведены некоторые примеры по настройки ваших веб-серверов работающих под управлением UNIX.

Как описано выше при такой атаке злоумышленник пытается открыть как можно больше TCP соединений. Значит узким местом нашей системы в первую волну удара будет кол-во этих соединений.

Для того чтобы увеличить их стоит выполнить простую команду

 

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

 

Где 1024 это кол-во одновременно открытых соединений которые одновременно может создавать ваш сервер. Этот параметр лучше установить не ниже 1000 но и в зависимости от железа его можно увеличивать (но не надо делать их максимально возможным, так как есть атаки типа SLOW DDOS, но об этом в других статьях)

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

 

# sysctl -w net.ipv4.tcp_synack_retries=1

 

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

 

# sysctl -w net.ipv4.tcp_syncookies=1

Механизм tcp syncookies очень интересен. Давайте разберем его подробнее. Для создания TCP-соединения клиент отправляет серверу TCP-пакет с флагом SYN и своим номером последовательности. В ответ сервер отправляет пакет с флагами SYN+ACK. номером последовательности клиента и своим собственным номером последовательности. По этим номерам собирается весь TCP-поток. Спецификация TCP определяет что начальные значение этих номеров последовательности определяются самими клиентом и сервером. SYN cookies — это как раз такой номер последовательности, который аккуратно собирается сервером по следующим правилам:

пусть t будет медленно увеличивающаяся метка времени (обычно результат функции time() логически сдвинутая на 6 позиций в право, что даёт новые значение каждые 64 секунды)

пусть m будет максимальным размером сегмента (MSS), которое сервер будет хранить в номере последовательности SYN
пусть s будет результатом криптографической хэш функции длиной 24 бита над адресами и портами сервера и клиента и значения t

Тогда SYN cookie вычисляется как: старшие 5 бит: t mod 32 средние 3 бита: кодированное m (всего будет 8 типов всех возможных MSS) младшие 24 бита: s

Когда клиент отправляет на сервер завершающий рукопожатие пакет с флагом ACK, то он отправляет первоначальный номер последовательности сервера увеличенный на единицу. Для проверки корректности SYN cookie, сервер отнимает от неё единицу и выполняет следующие проверки: проверяет значение t, чтобы проверить, что сессия не просрочилась; восстанавливает s для проверки действительности SYN cookie раскодировать значение m для дальнейшего построения элементов очереди

С этого момента соединение работает как обычно.

Но и у него есть свои недостатки:

Использование SYN cookie не нарушает работу ТСP и других протоколов. Однако в данной технике есть два ограничение возможность использовать только 8 различных значений для MSS; серверу придётся игнорировать все TCP соединения (увеличенный размер окна, метки времени и др.), т.к. они отправляются в первоначальном SYN-запросе.

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

Однако проблема возрастает когда теряется финальный ACK-пакет от клиента, а протокол прикладного уровня требует, чтобы сервер был инициатором дальнейшего взаимодействия (например, протоколы SMTP и SSH). В этом случае клиент предполагает, что соединение установлено успешно и ждёт от сервера пригласительный баннер или повторную пересылку SYN+ACK пакета. Однако сервер не будет отправлять такой пакет, т.к. забракует сессию. В конечном итоге клиент тоже сбросить сессию, но для этого может потребоваться много времени.