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

Вспомним, что происходит при установлении TCP-соединения:

1. Мы посылаем удаленной системе пакет с SYN-флагом, который говорит о том, что мы хотим установить соединение:

Client —— SYN (856779) —— Host

2. Удаленная система отвечает нам SYN/ACK пакетом («ваш пакет с SYN(856779) получен, готова установить соединение, мой SYN = 758684758»):

Host —— SYN (758684758) и ACK (856780) —— Client

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

Client —— SYN (856780) и ACK (758684759) —— Host

А вот что будет, если убрать шаг №3?

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

А теперь представь, что происходить попытка установки еще одного соединения — и новый пакет из шага №2 добавляется в очередь… А потом одна попытка и еще один пакет… Это вселенная, если верить ученным, бесконечна, а очередь имеет свои известные пределы. Поэтому рано или поздно должно произойти ее переполнение. После чего, удаленная система перестает реагировать на всякие попытки установления соединения, а попросту — «уходит в глубокий даун».

Строго говоря, в различных системах работа с очередью реализована по разному. После истечение некоторого времени (зависит от реализации) система удаляет пакеты из очереди. Однако ничего не мешает нам послать новую порцию запросов, чтобы «забить освободившееся место», и тем самым и далее поддерживать удаленную систему в нерабочем состоянии.

Реализация атаки SYN-flooding основывается на том, что жертве посылаются пакеты от имени IP-адреса, которого реально не существует. Т.е. посылая SYN/ACK пакет, жертва отправляет его изначально несуществующему адресату, а значит и не может получить на него какой-либо ответ.

Предположим, наша жертва — сервер на NT4.0 Сервер будет пытаться повторить подтверждение 5 раз — через 3, 6, 12, 24 и 48 секунд. После этого еще 96 секунд система может ожидать ответ, и только после этого освободит ресурсы, выделенные для будущего соединения. Общее время занятости ресурсов — 189 секунд. Следовательно за 189 секунд мы должны успеть переполнить очередь на сервере — и тут одному уже не справиться, нужна сплоченная команда. Идеальный вариант, если это будут не люди, а программы запущенные на подставных серверах (Х писал об этом совсем недавно). История говорит, что в успешных атаках на крупные порталы принимало участие не менее 2000 машин. Но это там, где жертва на один сервер (к примеру hotmail.com — это 12 почтовых серверов) и имеется довольно неплохая защита. Защита основывается на том, что если в течение некого интервала времени не пришло подтверждение, то срабатывает защитный механизм и пакет насильственно удаляется из очереди, поэтому для «затопления» сервера у нападающего есть всего несколько секунд. При конфигурировании защиты перед администратором стоит задача определения того самого временного интервала, в течение которого нужно ждать ответа (при установке слишком малого интервала, есть опасность отбрасывать и «правильные» соединения). Конечно для твоего провайдера, где реальная цель — один сервер и никакой защиты — команда нужна поскромнее.

Детектирование данной атаки несложно — большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом.

Защитной мерой может быть софт вроде Real Secure от широко известной ISS (не очень хороша, но очень проста в реализации). Либо построение сетевых экранов — дорогое, но очень действенное средство. Беда в том, что даже самая дорогая защита не обеспечивает 100% защиты и потому, пока используется TCP будет и
SYN-flood…

Оставить мнение

Check Also

Алмазный фонд «Хакера». Важные материалы по взлому за последние несколько лет

В прошлом выпуске мы сделали подборку по реверсингу и анализу malware-кода, которая в перв…