DDoS в разрезе

Размахнин Сергей Александрович

Хакер, номер #094, стр. 094-082-3

1. Клиент посылает серверу пакет с SYN-флагом и установленным начальным номером (SEQ) клиенткой последовательности пакетов(SEQ=ISN_C), который говорит о том, что мы хотим установить соединение: Client ----- (SEQ=ISN_C, CTRL=SYN). -----> Server;

2. Сервер отвечает клиенту SYN/ACK пакетом (ваш пакет с SYN= ISN_C получен, готов установить соединение, мой начальный номер последовательности пакетов (SYN) равен ISN_S):

Server ----- (SEQ=ISN_S, ACKN= ISN_C+1, CTRL=SYN, ACK)---> Client

3. Клиент на это отвечает серверу пакетом ACK, и соединение считается установленным:

Client -----(SEQ=ISN_С+1, ACKN= ISN_S+1, CTRL=ACK)-----> Server

Убрав из схемы трехуровневого рукопожатия шаг номер 3, можно реализовать атаку TCP SYN Flood. Тогда на втором шаге сервер посылает клиенту SYN/ACK-пакет, переводит сессию в состояние SYN_RECEIVED и заносит пакет в очередь. Добавление пакета в очередь означает, что если в течение установленного интервала времени сервер не получит подтверждения, что данный пакет дошел до адресата (шаг №3 и есть это подтверждение), то данный пакет будет считаться потерянным и потому будет послан снова. Если подтверждение в виде SYN/ACK-пакета будет получено, то пакет будет удален из очереди.

Представим, что произошла попытка установки еще одного соединения, и новый пакет из шага №2 добавляется в очередь. А потом еще одна попытка и еще один пакет. Очередь имеет свои известные пределы, поэтому рано или поздно должно произойти ее переполнение. После чего сервер перестает реагировать на всякие попытки установления соединения. Строго говоря, в различных системах работа с очередью реализована по-разному. После истечения некоторого времени система удаляет пакеты из очереди. Однако ничего не мешает атакующему послать новую серию запросов, чтобы вновь заполнить буфер атакуемой системы, тем самым и далее поддерживая ее в нерабочем состоянии. Реализация атаки SYN-flooding основывается на том, что жертве могут посылаться как пакеты от имени IP-адреса, которого реально не существует (IP-spoofing), так и пакеты с реального IP-адреса атакующего.

Обнаружить данную атаку довольно просто, ее характеризуют:

1) большое количество соединений в состоянии SYN_RECEIVED;

2) игнорирование попыток соединиться с данным портом.

Затопление SYN-пакетами - самый известный способ «загрузить» информационный канал. В результате этой атаки жертва перестает реагировать на попытки установления соединения, то есть попросту отбрасывает все приходящие пакеты. Этот вид DOS-атаки очень распространен — практически все известные порталы в свое время страдали от подобных атак.

Механизмы защиты от атаки SYN-flood:

a) выбор оптимального таймаута, по истечении которого полуоткрытые соединения выбрасываются из буфера;

в) очистка наиболее старых полуоткрытых соединений:

г) SYN COOKIE. Это самый действенный способ защиты от SYN Flood-атак, поговорим о нем более подробно. В этом способе трехэтапное соединение TCP сводится к двум этапам: при получении SYN-пакета сервер отвечает пакетом SYN/ACK и не заносит никакую информацию в очередь (забывает о клиенте). Идея этого способа защиты заключается в следующем. Значение ISN_S формируется сервером в пакете SYN/ACK. Так вот, если зашифровать в значении ISN_S ip адрес клиента, то в случае корректной работы клиент возвратит Ack-пакет со значением ACKN= ISN_S+1, а сервер расшифрует его, извлечет из него начальный IP-адрес, сравнит его с IP-заголовком IP-пакета, и если адреса совпадают, то установит соединение. Если адреса из расшифрованного значения ACKN= ISN_S+1 и значения IP-заголовка совпадать не будут, значит, происходит syn flood-нападение. Существуют два механизма реализации SYN COOKIE. Один разработан Стивом Гибсоном, другой — Дэном Бэрнстейном (Dan Bernstein) и Эриком Шенком (Eric Schenk). Концепция Syn cookie соответствует стандарту RFC-793, она требует доработки только серверной части и не касается клиентской.