Этот текст задуман как дополнение к,
несомненно, ценной статье TCP
№2, в которой автор излагал теоретические
основы SYN-flood атаки, а потом фантазировал о
том, как выглядит на практике эта атака и
защита от нее. Ни в коей мере не покушаясь на
авторитетность и величие господина автора
:), хочу поделиться знаниями, полученными
при практической реализации этого типа
атаки.
Проблемы, не зависящие от атакующего
Некоторые провайдеры (и чем дальше, тем
больше таких появляется) фильтруют трафик
своих клиентов на предмет подделки адреса
отправителя. Есть большая вероятность, что
возможность спуфинга ограничивается
подсетью класса 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 Mб/сек и таймауту около минуты
очередь полуоткрытых соединений будет
занимать примерно 1 Гб памяти, что для
крупных серверов не смертельно. Побочный
эффект: атакуемый сервер отвечает трафиком,
в 3 раза большим, чем трафик атакующего (говорят,
что происходит DDoS с умножением в 4 раза), что
может привести к истощению пропускной
способности канала. Однако, при
невозможности истощить ширину канала,
защита от атаки будет абсолютной, ни одно
клиентское соединение не будет отвергнуто.
в) Очистка наиболее старых полуоткрытых
соединений. При переполнении буфера из него
удаляется самое старое полуоткрытое
соединение. Побочный эффект: если при атаке
буфер заполняется за время t, то клиент не
сможет подключиться во время атаки, если
время подтверждения соединения больше t -
его запрос тоже будет выброшен. Например,
для нагрузки канала атакующего 4 Мбит/сек и
длины буфера 512 (рекомендуемое значение для
Win2K) время t - около 50 msec, что гарантированно
отбросит все попытки подключения к серверу
с диалапа и многие - с выделенных линий.
Увеличивая размер буфера, защиту можно
свести к предыдущему варианту.
г) SYN COOKIE. После истощения буфера
информация, которая не помещается в буфер,
отсылается клиенту, который якобы запросил
ее. Если клиент - настоящий, то он возвращает
информацию обратно, если поддельный - она
теряется, причем механизм реализован в
рамках RFC по TCP, т.е. его поддерживают и
клиенты, не знакомые с этой технологией.
Операционная система c SYN COOKIE, независимо от
размера буфера полуоткрытых соединений,
совершенно неуязвима для SYN-flood атак.
Побочный эффект: запрет "больших окон".
Резюме: SYN-flood атака морально устарела, и
сегодня может использоваться в лучшем
случае в качестве обычной flood-атаки на
превышение пропускной способности канала.
