На главную

Библиотека Интернет Индустрии I2R.ru

Rambler's Top100

Малобюджетные сайты...

Продвижение веб-сайта...

Контент и авторское право...

Забобрить эту страницу! Забобрить! Блог Библиотека Сайтостроительства на toodoo
  Поиск:   
Рассылки для занятых...»
I2R » Хакеры и безопасность » Хакеры

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

buggzy
SecurityLab.ru

Другие разделы
Прочие опасности
Вирусы
Хакеры
Киберпреступность
Уязвимость ПО
Новое в разделе
Защита данных
I2R-Журналы
I2R Business
I2R Web Creation
I2R Computer
рассылки библиотеки +
И2Р Программы
Всё о Windows
Программирование
Софт
Мир Linux
Галерея Попова
Каталог I2R
Партнеры
Amicus Studio
NunDesign
Горящие путевки, идеи путешествийMegaTIS.Ru

2000-2008 г.   
Все авторские права соблюдены.
Rambler's Top100