Атаки типа syn flood. Флуд – наиболее простой и распространенный способ проведения DDoS атак

Неужели ты думаешь, что знаешь все о DoS? Тогда читай!

Denial-of-service (DoS), атаки отказа от обслуживания, стали опаснее и легче. DoS это разновидность
сетевых атак (от червей до SYN flooding), цель которых сделать сервер недоступным для пользователей. ‘Distributed Reflection’ это новый вид DoS атак с использованием SYN flood"а. Его особенность в том, что на атакуемый сервер не посылаются миллионы SYN пакетов, они посылаются на router"ы или сервера и ответ приходит целевому серверу. А
роутеров существует миллионы!

Чтобы понять как все это работает и почему это так важно
давайте кое-что вспомним... Подтверждение TCP соединения происходит посредствам обмена тремя пакетами между двумя
компьютерами, так называемое рукопожатие. Вот примерная схема:

SYN клиент (web браузер, ftp клиент, etc.) входит в связь с сервером, посылая ему SYN пакет.
SYN/ACK: Когда запрос о соединении(SYN пакет) получен на открытом порту сервера, тот подтверждает соединение посылая клиенту SYN/ACK пакет.
ACK: Когда клиент получает подтверждение сервера SYN/ACK пакет для ожидаемой связи, то отвечает ACK пакетом.

Что происходит?

Традиционные "SYN flooding DoS" атаки работают по двум принципам:

"one-on-one" одна машина отсылает достаточное количество SYN пакетов чтобы заблокировать доступ к серверу.
"many-on-one" множество программ зомби,
установленых на разных серверах, атакуют целевую машину SYN пакетами.

С использованием "reflection SYN flooding" посылаются пакеты,
но с исходным IP адресом, указывающим на целевую машину. TCP соединение с использованием этих трех пакетов требует, чтобы любая TCP служба, которая получает SYN пакет, ответила SYN/ACK пакетом. Сервер или router, которые получают эти поддельные SYN пакеты, посылают SYN/ACK ответы на машину, указанную SYN пакетами с исходным адресом
IP. Основной протокол Интернета и инфраструктура
сети используются сами против себя!

В деталях

Любая TCP связь с сервером общего назначения может использоваться, чтобы "отразить" SYN пакеты. Вот
короткий список наиболее популярных TCP портов:
22 (Secure Shell), 23 (Telnet), 53 (DNS) и 80 (HTTP/web). И фактически router"ы всего Интернета подтвердят TCP связь на
179 порту. Давайте оценим потенциал этой атаки:

Она использует фундаментальный Интернет протокол коммуникаций;
Машин, которые используют этот протокол, существует миллионы;
чрезвычайно просто организовать атаку ‘SYN packet
reflectors’.

Довольно легко может быть построен список,
в котором будут перечислены router’ы и
сервера, отвечающие на SYN пакеты. Имея
большой список SYN "отражателей", каждый
хакер может распределить поддельные SYN
пакеты равномерно через весь набор
роутеров/серверов в списке. Ни один из невинных "отражателей" не испытает
существенной сетевой нагрузки. Роутеры вообще не сохраняют отчеты про пакеты с запросами на
предварительное соединение, это делает
отслеживание нападения чрезвычайно трудным.

"Отражатели"(роутеры и сервера) отправят в три или четыре раза большее количество SYN/ACK пакетов, чем число SYN пакетов которые они
получат. TCP соединение, которое получает команду
SYN, ожидает ACK ответ от машины на которую послало
SYN/ACK пакет, поэтому компьютер посылается еще несколько SYN/ACK ответов через несколько минут. Эта особенность TCP протокола по существу умножает число злонамеренных SYN/ACK пакетов, посылаемых целевой машине на три или четыре. Это также означает, что flood SYN/ACK
пакеты продолжат атаковать целевой сервер в течение минуты или
двух даже после того, как нападавший отозвал нападение.

syn-flood атака - практика

Alexander Antipov

Некоторые провайдеры (и чем дальше, тем больше таких появляется) фильтруют трафик своих клиентов на предмет подделки адреса отправителя. Есть большая вероятность, что возможнось спуфинга ограничивается подсетью класса 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-атаки на превышение пропускной способности канала.

DoS (аббр. Denial of Service «отказ в обслуживании») - хакерская атака на вычислительную систему с целью довести её до отказа, то есть создание таких условий, при которых добросовестные пользователи системы не могут получить доступ к предоставляемым системным ресурсам (серверам), либо этот доступ затруднён.

Существует два типа DoS-атака /DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них.

Обнаружение DoS-атак

SYN-флуд

Наличие SYN- флуда устанавливается легко - через подсчет числа «полуоткрытых» TCP- соединений. В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3).

Защита от DoS-атак

Блокирует фрагменты - пакетов. Так как, в силу функционального назначения протокола, ICMP-пакеты должны быть очень небольшими и нормально укладываться в MTU , наличие их фрагментов обычно свидетельствует об ошибке или попытке атаки. iptables -A INPUT -p icmp -f -j DROP

Запретить Спуфинг от вашего имени. iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-level info --log-prefix "DROP SYN,ACK: " iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

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

SYN-флуд

Один из распространенных способов не только забить канал связи, но и ввести сетевой стек операционной системы в такое состояние, когда он уже не сможет принимать новые запросы на подключение. Основан на попытке инициализации большого числа одновременных TCP-соединений через посылку SYN-пакета с несуществующим обратным адресом. После нескольких попыток отослать ответный ACK-пакет на недоступный адрес большинство операционок ставят неустановленное соединение в очередь. И только после n-ой попытки закрывают соединение. Так как поток ACK-пакетов очень велик, вскоре очередь оказывается заполненной, и ядро дает отказ на попытки открыть новое соединение. Наиболее умные DoS-боты еще и анализируют систему перед началом атаки, чтобы слать запросы только на открытые жизненно важные порты. Идентифицировать такую атаку просто: достаточно попробовать подключиться к одному из сервисов. Оборонительные мероприятия обычно включают в себя:

Увеличение очереди «полуоткрытых» TCP-соединений:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

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

# sysctl -w net.ipv4.tcp_synack_retries=1

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

# sysctl -w net.ipv4.tcp_syncookies=1

UDP-флуд

Метод захламления полосы пропускания. Основан на бесконечной посылке UDP-пакетов на порты различных UDP-сервисов. Легко устраняется за счет отрезания таких сервисов от внешнего мира и установки лимита на количество соединений в единицу времени.

#Ставим ограничение на 5 соединений на 80 порт. iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j REJECT # Разрешаем только одно одновременное соединение с одного айпи на smtp iptables -A FORWARD -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP #Ставим ограничение на 200 соединений на 1720 порт. iptables -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 200 -j REJECT # udp 5060 $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 5060: " $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j REJECT # tcp 1720 $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 1720: " $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j REJECT

ICMP- флуд

Очень примитивный метод забивания полосы пропускания и создания нагрузок на сетевой стек через монотонную посылку запросов ICMP протокол диагностики перегрузки сети ECHO (пинг). Легко обнаруживается с помощью анализа потоков трафика в обе стороны: во время атаки типа ICMP-флуд они практически идентичны. Почти безболезненный способ абсолютной защиты основан на отключении ответов на запросы ICMP ECHO:

Sysctl net.ipv4.icmp_echo_ignore_all=1

Или с помощью брандмауэра:

Iptables -A INPUT -p icmp -j DROP --icmp-type 8

HTTP-флуд

Количество процессов ps aux | grep apache | wc -l

Количество конектов на 80 порту netstat -na | grep ":80\ " | wc -l

Просмотреть список IP- адресов, с которых идут запросы на подключение: netstat -na | grep ":80\ " | sort | uniq -c | sort -nr

sysctl

Защита от спуфинга net.ipv4.conf.default.rp_filter = 1

Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная машина, она сразу ответит. Дефолтовое значение - 2 часа. net.ipv4.tcp_keepalive_time = 60

Повторить пробу через десять секунд net.ipv4.tcp_keepalive_intvl = 10

Количество проверок перед закрытием соединения net.ipv4.tcp_keepalive_probes = 5

Debian: борьба с DDoS

По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом. Необходимо внести изменения в настройки ядра, чтобы укрепить стек TCP/IP. Пример такой конфигурации:

Net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.core.rmem_max = 996777216 net.core.wmem_max = 996777216 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_mem= 786432 1048576 996777216 net.ipv4.tcp_wmem = 4096 87380 4194304 net.ipv4.tcp_max_orphans = 2255360 net.core.netdev_max_backlog = 10000 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 494967295 kernel.shmall = 268435456 net.core.somaxconn= 16096

Аккуратно меняем конфигурацию ядра и перезагружаем сервер…

FreeBSD: борьба с DDoS

Уменьшаем время ожидания ответного пакета на запрос SYN-ACK (защита от SYN-флуда):

# sysctl net.inet.tcp.msl=7500

Превращаем сервер в черную дыру. Так ядро не будет слать ответные пакеты при попытке подключиться к незанятым портам (снижает нагрузку на машину во время DDoS"а на случайные порты):

# sysctl net.inet.tcp.blackhole=2 # sysctl net.inet.udp.blackhole=1

Ограничиваем число ответов на ICMP-сообщения 50-ю в секунду (защита от ICMP-флуда):

# sysctl net.inet.icmp.icmplim=50

Увеличиваем максимальное количество подключений к серверу (защита от всех видов DDoS):

# sysctl kern.ipc.somaxconn=32768

Включаем DEVICE_POLLING - самостоятельный опрос сетевого драйвера ядром на высоких нагрузках (существенно снижает нагрузку на систему во время DDoS"а):

Пересобираем ядро с опцией «options DEVICE_POLLING»; Активируем механизм поллинга: «sysctl kern.polling.enable=1»; Добавляем запись «kern.polling.enable=1» в /etc/sysctl.conf.

Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:

Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту (sshd спасет отца русской демократии). Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.

ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки - пропатчены, обновления установлены (простой, как сапог, совет, которому многие не следуют). Это оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.

Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.

На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика (NetFlow в помощь), которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.

Собственно, речь пойдет о защите от SYN flood атак:

Очень популярная DoS атака заключается в посылке большого числа SYN пакетов на ваш сервер. При этом установка TCP связи не доводится до конца. Очередь полуоткрытых запросов соединений быстро заполняется, что мешает установке нормальных соединений. Так как соединение не должно быть обязательно завершено, такая атака не требует больших ресурсов от атакующей машины, поэтому её легко реализовать и контролировать.

Определить SYN атаку просто - команда netstat выдает огромный список полуоткрытых подключений:

Netstat -n --tcp | grep SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1084 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1228 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:2652 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:3446 SYN_RECV

Netstat -n --tcp | grep SYN_RECV | wc -l 238

Для начала - проверяем параметр tcp_syncookies - он должен быть равен 1:

Cat /proc/sys/net/ipv4/tcp_syncookies 1

Так и оставляем. По умолчанию в новых дистрибутивах этот параметр всегда включен.

Если параметр tcp_syncookies установлен (доступен только когда ядро собрано с CONFIG_SYNCOOKIES), тогда ядро обрабатывает SYN пакеты TCP в обычном режиме до тех пор, пока очередь не заполнится. После заполнения очереди включается механизм SYN cookies.

SYN cookies вообще не использует очередь SYN. Вместо этого ядро отвечает на каждый SYN пакет, как обычно SYN|ACK, но туда будет включено специально сгенерированное число на основе IP адресов и портов источника и получателя, а также времени посылки пакета. Атакующий никогда не получит эти пакеты, а поэтому и не ответит на них. При нормальном соединении, будет послан третий пакет, содержащий число, а сервер проверит был ли это ответ на SYN cookie и, если да, то разрешит соединение даже в том случае, если в очереди SYN нет соответствующей записи.

Включение механизма SYN cookies является очень простым способом борьбы против атаки SYN флудом. При этом немного больше загружается процессор из-за необходимости создавать и сверять cookie. Так как альтернативным решением является отклонять все запросы на соединение, SYN cookies являются хорошим выбором.

Также нужно увеличить очередь полуоткрытых соединений - tcp_max_syn_backlog (в Debian Lenny по-умолчанию 1024 соединения):

Cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1024

Увеличиваем:

Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog

Кроме того, можем уменьшить время ожидания соединения tcp_synack_retries :

Целочисленное значение (1 байт) tcp_synack_retries определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP. Число попыток не должно превышать 255. Используемое по умолчанию значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения.

cat /proc/sys/net/ipv4/tcp_synack_retries 5

Уменьшаем до 1 (это примерно 9 секунд):

Echo "1" > /proc/sys/net/ipv4/tcp_synack_retries

tcp_fin_timeout

Целое число в файле tcp_fin_timeout определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Партнер может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд. В ядрах серии 2.2 обычно использовалось значение 180 секунд и вы можете сохранить это значение, но не следует забывать, что на загруженных WEB-серверах вы рискуете израсходовать много памяти на сохранение полуразорванных мертвых соединений. Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1, поскольку поглощают не более 1,5 Кбайт памяти, но они могут существовать дольше.

cat /proc/sys/net/ipv4/tcp_fin_timeout 60

Меняем на 30:

Echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout

tcp_keepalive_probes

Целочисленная переменная tcp_keepalive_probes задает число передач проб keepalive, после которого соединение считается разорванным. По умолчанию передается 9 проб.

cat /proc/sys/net/ipv4/tcp_keepalive_probes 9

Echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes

tcp_keepalive_intvl

Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.

cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75

Ставим 15:

Echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl

netdev_max_backlog

Здесь указывается максимальное количество пакетов в очередь на обработку если интерфейс получает пакеты быстрее, чем ядро может их обработать.

Cat /proc/sys/net/core/netdev_max_backlog 1000

Увеличиваем:

Echo "20000" > /proc/sys/net/core/netdev_max_backlog

somaxconn

Максимальное число открытых сокетов, ждущих соединения.

Cat 1024

Увеличиваем:

Echo "20000" > /proc/sys/net/core/somaxconn

Так как подобные изменения параметров ядра не сохранятся после перезагрузки - добавляем в /etc/rc.local :

Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog echo "1" > /proc/sys/net/ipv4/tcp_synack_retries echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl echo "20000" > /proc/sys/net/core/netdev_max_backlog echo "20000" > /proc/sys/net/core/somaxconn

Кроме того, можно добавить ограничение числа SYN пакетов в единицу времени в iptables:

Iptables -N syn_flood iptables -A INPUT -p tcp --syn -j syn_flood iptables -A syn_flood -m limit --limit 500/s --limit-burst 1500 -j RETURN iptables -A syn_flood -j DROP

Число новых SYN пакетов - максимум 500 в секунду, при превышении порога в 1500 - новые пакеты блокируются:

Более наглядно этот критерий можно представить себе как некоторую емкость с выпускным отверстием, через которое проходит определенное число пакетов за единицу времени (т.е. скорость «вытекания»). Скорость «вытекания» как раз и определяет величина --limit. Величина --limit-burst задает общий «объем емкости». А теперь представим себе правило --limit 3/minute --limit-burst 5, тогда после поступления 5 пакетов (за очень короткий промежуток времени), емкость «наполнится» и каждый последующий пакет будет вызывать «переполнение» емкости, т.е. «срабатывание» критерия. Через 20 секунд «уровень» в емкости будет понижен (в соответствии с величиной --limit), таким образом она готова будет принять еще один пакет, не вызывая «переполнения» емкости, т.е. срабатывания критерия.

DoS/DDoS-атаки направлены на нарушение базовой услуги доступности. Основная цель DoS/DDoS-атак вывести атакуемый объект из рабочего состояния и сделать его ресурсы недоступными для легальных пользователей. Атаку, направленную на отказ в обслуживании, можно провести двумя способами: используя уязвимости в программном обеспечении атакуемой системы и при помощи отсылки большого количества определенно составленных сетевых пакетов (flood).

Первый способ сложнее и требует более высокой квалификации атакующего. Второй способ основан на применении "грубой силы". Идея заключается в том, чтобы загрузить вычислительные ресурсы сервера обработкой огромного количества посланных злоумышленником пакетов. Такая загрузка сервера в лучшем случае может привести к тому, что сервер будет неспособен принять на обработку запросы от легальных пользователей, а в худшем случае может привести к зависанию и отключению сервера.

Здесь стоит отметить, что можно выделить два типа атак, направленных на загрузку ресурсов системы: в первом случае загружаются вычислительные ресурсы сервера, а в другом - пропускная способность канала связи. Разрабатываемая методика ориентирована на защиту от атак первого типа, поэтому дальше будем считать, что пропускной способности достаточно, чтобы сервер получил весь адресованный ему трафик.

Для многих DoS/DDoS атак результаты обработки сервером пакетов, отправленных злоумышленником, последнего не интересуют. Это значит, что атакующий может отправлять поток ложных заявок с ложных IP адресов (это понятие называется spoofing), что препятствует его обнаружению и эффективному противодействию такого рода атакам.

Для проведения успешной DoS-атаки необходима довольно высокая пропускная способность канала. Поэтому атака на отказ в обслуживании в большинстве случаев проводится сразу с нескольких машин. Атака, в проведении которой участвует большое количество машин, получила название DDoS. Стоит отметить, что для распределенной атаки могут использоваться инфицированные специальным ПО машины не принадлежащие атакующему. Такие зараженные машины называются "зомби". Одним из способов получения "зомби" является массовое внедрение "трояна" на компьютеры мирных пользователей. Получив определенную извне команду такой "троян" превращает "мирный" компьютер с доступом в Internet в источник ложных запросов, направленных на перегрузку ресурсов сервера.

Наиболее распространенными DoS атаками являются:

· TCP SYN Flood или просто TCP SYN

· Ping of Death

Рассмотрим подробнее TCP SYN (tcp syn flood) атаку, которая направлена на прикладные сервисы, использующие протокол транспортного уровня TCP. Этот протокол получил широкое распространение в информационных системах за счет того, что он гарантирует 100% доставку всех передаваемых данных. Взаимодействующие узлы сети, использующие в качестве транспорта этот протокол, устанавливают между собой TCP соединения, в рамках которых ведется контроль над тем, что получатель получит все посланные отправителем пакеты. Это достигается за счет того, что получатель извещает отправителя о том, какие пакеты он получил. Если до получателя дошли не все предназначенные ему пакеты, то отправитель повторно их отправит. Как видно достоинством этого протокола является возможность установления соединения. Для хранения информации о текущем состоянии соединения в частности используется поле битовых флагов в пакетах, используемых протоколом. Под это поле отведено 8 бит, однако 2 из них являются зарезервированными и в настоящее время используются только 6 флагов: URG (флаг срочности), ACK (флаг подтверждения), PSH (флаг push функции), RST (флаг сброса), SYN (флаг синхронизации) и FIN (флаг окончания). К сожалению, установленный стандартом механизм установления соединения не является совершенным, и рассматриваемая атака, как раз использует его недостатки.

Основная цель этой TCP SYN атаки - превысить ограничение на количество TCP соединений, которые находятся в состоянии установки. Рассмотрим процедуру установки TCP соединения. Сначала клиент, инициализирующий соединение отправляет серверу TCP-SYN запрос. Получив такой запрос, сервер выделяет память для параметров соединения в специально предназначенном для этого буфере. Затем отправляет клиенту TCP пакет с флагами SYN+ACK. Получив пакет SYN+ACK, клиент должен отправить серверу пакет с подтверждением, т.е. пакет с установленным флагом ACK. Когда сервер получит и обработает этот пакет, соединение является установленным. Описанная выше

процедура изображена на рис. 1.1

Рис. 1.1

TCP SYN атака производится следующим образом: злоумышленник генерирует большое количество пакетов с установленными SYN флагами протокола TCP. Получая пакеты, атакуемая машина выделяет память для хранения параметров соединения и отправляет ответ - пакет с флагами SYN + ACK и ожидает пакета с флагом ACK. Очевидно, что ожидаемый ответ она не получит, и память будет освобождена только после истечения установленного таймаута. Через некоторое время буфер, выделенный для хранения параметров TCP, соединений будет полностью занят, в результате чего, система не сможет устанавливать новые соединения. После этого каждый дополнительный запрос еще сильнее увеличивает нагрузку. Такие атаки не нуждаются в обратной связи с атакующим, и поэтому злоумышленник может генерировать пакет с произвольными IP адресами отправителя.

Отсутствие обратной связи с атакующим делает обнаружение и отражение TCP-SYN атаки довольно сложной задачей.

Постановка задач по защите от угроз

В настоящее время в открытой литературе не известны эффективные методы обнаружения TCP SYN атак. В современных ОС присутствуют механизмы защиты атакуемого сервера, например SYN cookies. Операционная система автоматически включает защиту, когда обнаруживает превышение значений некоторых параметров. Например, ОС Windows 2000 следит за значениями трех параметров: TcpMaxHalfOpen, TcpMaxHalfOpenRetried, TcpMaxPortsExhausted . Пороговые значения для этих параметров имеют значения по умолчанию и могут меняться администратором. Если исходные значения не подходят для конкретного сервера, то перед администратором стоит непростая задача эффективно настроить защиту. Кроме того, этот метод требует внесения соответствующих изменений в реализацию стека TCP/IP, которые некоторые специалисты в области сетевых технологий считают "серьезным нарушением" протокола TCP.

Другим недостатком средств обнаружения TCP атаки интегрированных в ОС является то, что при перегрузке (имеется в виду нехватка ресурсов процессора и памяти) или зависании самой системы средства противодействия так же становятся неработоспособными.

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

Для возможности использования предлагаемой методики на практике для защиты критичных ресурсов корпоративной сети необходимы так же средства, позволяющие определить фактические значения входных параметров модели для конкретного сервера и сети, к которой он подключен.