Введение.
В наши дни атаки компьютерных сетей типа “отказ в обслуживании” (DoS, Denial of Service) являются одними из самых, а быть может, и самыми распространенными атаками. Частично виной тому простота их реализации и высокая эффективность. Целью таких атак, как следует из названия, является приведение сервера-жертвы в состояние, когда он не может отвечать на запросы клиентов. Побочным эффектом таких атак является большой трафик, направленный на жертву. Этот эффект, часто игнорируемый специалистами на Западе, приобретает несколько другой оттенок на просторах бывшего Союза. В данной статье мы рассмотрим некоторые, наиболее распространенные, атаки и методы их сдерживания. Важно понимать, что не существует методов, которые защитили бы вас от DoS-атак, можно лишь попытаться минимизировать причиненные убытки и оперативно отреагировать на атаку.
Взгляд на атаки “отказ в обслуживании” со стороны малых провайдеров и домашних сетей.
Взглянем на DoS-атаки с необычного ракурса. Для малых провайдеров и домашних сетей ощутим каждый десяток мегабайт трафика. В результате средняя по размерам атака “отказ в обслуживании” может в течение нескольких часов буквально разорить провайдера. Вот под таким углом мы и будем рассматривать методы борьбы с DoS-атаками.
В классическом понимании успехом атаки “отказ в обслуживании” является отказ оператора (сервера) в предоставлении сервиса. Но, беря во внимание специфику домашней сети и малого провайдера, я считаю, что в крайнем случае, приемлемо перестать временно (на период атаки) предоставлять сервис клиенту, чтобы не обанкротиться.
Атаки типа “SYN-flood”
Как известно, TCP использует трехэтапное квитирование для установления соединения. В основу данного типа атак заложена идея превышения ограничения на количество соединений, находящихся в состоянии установки. Результатом является состояние системы, в котором она не может устанавливать новые соединения. Кроме того, при такой атаке на каждый входящий пакет система-жертва высылает ответ, что ещё сильнее увеличивает злонамеренный трафик.
Поскольку такие атаки не предусматривают обратной связи с атакующим, нет необходимости использовать настоящий адрес источника. Вот листинг примера, как устанавливается заголовок IP пакета, используемого в атаке тпа “syn-flood”.
packet.ip.version=4; /* Версия */
packet.ip.ihl=5; /* Длина заголовка */
packet.ip.tos=0; /* Тип сервиса */
packet.ip.tot_len=htons(40); /* Общая длинна */
packet.ip.id=getpid(); /* Идентификатор */
packet.ip.frag_off=0; /* Смещение фрагмента */
packet.ip.ttl=255; /* Время жизни */
packet.ip.protocol=IPPROTO_TCP; /* Протокол */
packet.ip.check=0; /* Контрольная сумма */
packet.ip.saddr=saddress; /* Адрес источника */
packet.ip.daddr=daddress; /* Адрес назначения */
Что же можно сделать для сдерживания таких атак? Ответ состоит из нескольких частей. Во-первых, следует ограничить скорость поступающих пакетов с установленным флагом syn к вашим серверам. Для этого организовывается очередь с ограниченной скоростью, в которую поступают указанные пакеты. Ниже приводится пример соответствующего скрипта
#!/bin/sh
#
# Входящий интерфейс
DEV=eth2
#
# маркируем все входящие SYN-пакеты
# на интерфейсе $DEV значением 1
ipchains -A input -i $DEV -p tcp -y -j MARK --set-mark 1
#
# устанавливаем дисциплину обработки очереди входящих пакетов
tc qdisc add dev $DEV handle ffff: ingress
#
# Длина пакетов с установленным флагом SYN
# равна 40 байтам (320 бит)
# потому три SYN-пакета равны 960 битам (или скорости 1кбит)
# Теперь ограничим скорость до 3 пакетов в секунду
tc filter add dev $DEV parent ffff: protocol ip \
prio 50 handle 1 fw police rate 1kbit burst 40 \
mtu 9k drop flowid :1
#
#
Это обеспечит защиту вашего сервера от останова. Однако вы ничего не можете поделать с лишним трафиком. Указанный скрипт поможет вам обнаружить атаку: растущая очередь фильтра явно свидетельствует об этом. Можно написать еще один скрипт, который будет периодически запускаться, и анализировать размер очереди входящих syn-пакетов. Если он превышает допустимый размер, слишком быстро или постоянно растет – это признаки атаки. Вы ее обнаружили, а это очень важно.
DoS-атаки основанные на протоколе ICMP.
Большое количество DoS-атак основывается на протоколе ICMP. Его служебные функции могут использоваться в неблаговидных целях. Рассмотрим несколько атак, которые могут использоваться с целью нанесения финансового вреда конкурентам. Такие атаки, из-за необходимости большого объёма трафика, называются “грубыми”. Классическим примером является Smurf. Ее единственным назначением есть сужение полосы пропускания жертвы. Сценарий таков: посылается эхо-запрос с адресом источника, подмененным на адрес жертвы. Следовательно, эхо-ответ уже приходит к компьютеру-жертве. Если, к тому же, эхо-запрос является широковещательным для сети, на него могут отреагировать все компьютеры указанной сети и поток, направленный на жертву, уже становится огромным, приобретая лавинообразный характер.
Приведу пример из документа Cisco (http://www.cisco.com/warp/public/707/5.html):
“…представьте себе сеть из 100 узлов и нарушителя с соединением 768Кбит. Он посылает поток эхо-запросов с измененным адресом источника и указанной скоростью по упомянутой сети из 100 узлов… В результате ответный поток от сети к жертве составит 76,8Мбит…”
Впечатляет, не правда ли? А теперь несколько слов об организации и проведении модных нынче распределенных или dDoS-атак. Вернемся к атаке Smurf, где эхо-запросы посылались с одного компьютера злоумышленника и использовалась лишь одна сеть для “отражения” и “усиления” потока пакетов. Теперь представьте, что атака ведется с десятков, сотен или даже тысяч компьютеров и для “отражения” используется соответствующий порядок сетей. Smurf покажется вам детской забавой. К счастью для нас, проведение таких атак требует значительных умений, ресурсов и большого желания. Для начала нужно внедрить большое количество “агентов”, которые обычно распространяются вместе с “троянами”. Нужно собрать достаточно разведывательной информации о жертве и возможных посредниках. Это этапы достаточно длительные. Лишь после этого можно начинать распределенную атаку.
Защита от использования Вашей сети со злым умыслом
Рассмотрев распределенные атаки, становится ясным, что кроме защиты от угрозы извне, следует уделять внимание и защите изнутри. Ведь компьютеры внутренней сети могут быть заражены и использованы для dDoS-атаки в качестве агентов. Кроме того, что вы будете пособником атаки, на ваши каналы возрастет исходящая нагрузка. Посмотрим, что можно сделать для защиты Сети и ваших внешних каналов от вашей сети. Первое, что приходит в голову, так это то, что при атаке подменяются адреса источника. Следовательно, если из вашей сети будут идти пакеты не с вашими адресами, то сеть инфицирована, а такие пакеты выпускать нельзя. Второй важный момент – это протокол ICMP. В обычной работе его часть от остального трафика составляет 3-5%, а то и меньше. При проведении атак, очевидно, его доля будет значительно выше. Мысль – ограничить скорость исходящих ICMP пакетов до приемлемой для нормальной работы и неприемлемой для атак.
# Внешний интерфейс
EXT_IF=eth2
# Локальный интерфейс
INT_IF=eth0
# Наша локальная сеть
LAN="10.1.1.0/24"
#
# блокируем все входящие пакеты на локальном интерфейсе
# с адресом источника не из локальной сети
ipchains -A input -i $INT_IF -s $LAN -j ACCEPT
ipchains -A input -i $INT_IF -j DENY -l
#
#
# назначаем дисциплину обработки очереди
tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit \
avpkt 1000
tc class add dev eth0 parent 1:0 classid 1:10 cbq \
bandwidth 10Mbit rate 10Mbit allot 1514 prio 5 \
maxburst 20 avpkt 1000
#
# выделяем класс для ICMP пакетов
tc class add dev eth0 parent 1:10 classid 10:100 \
cbq bandwidth 10Mbit rate 100Kbit allot 1514 \
weight 5 prio 5 maxburst 20 avpkt 250 bounded
# заворачиваем все ICMP пакеты в выделенный класс
tc filter add dev eth0 parent 10:0 protocol ip \
prio 100 u32 match ip protocol 1 0xFF flowid 10:100
Обнаружение атак на отказ в обслуживании
Для обнаружения атак используются различные аппаратно-программные системы, устанавливаемые на специальных компьютерах в сети. Мы же рассмотрим мало-бюджетный вариант. Остановимся на утилите, которая может вам в этом помочь – это tcpdump. С ее помощью можно организовывать поиски сигнатур атак. Для этого указывается некое значимое поле в IP-датаграмме. Что бы это стало звучать понятнее, перейдем сразу к примерам. Как уже указывалось, для атак типа smurf используются широковещательные адреса. Следовательно, для обнаружения атаки такого типа датчик должен анализировать ip-адрес назначения. В ip-пакете он указывается в байтах 16-19. У всех широковещательных адресов последний байт равен либо 0xff, либо 0×00. Команда активации датчика:
# tcpdump 'ip[19]=0xff or ip[19]=0x00'
Другим, часто используемым, ходом в атаках является использование фрагментов. Признак наличия следующего фрагмента находится в третьем бите шестого байта заголовка IP. Датчик позволяющий отследить фрагменты выглядит так:
# tcpdump 'ip[6] & 0x20 = 32'
Обсудим возможность обнаружения пакетов характерных для атаки syn-flood. У таких пакетов выставлен флаг syn. Флаги tcp-пакета находятся в 13-м байте. Следовательно, нужный нам датчик, это:
# tcpdump 'tcp[13] & 0xff = 2‘
Очень полезный датчик на обнаружение активности Back Orifice:
# tcpdump 'udp and dst port 31337'
Огромную роль в атаках на компьютерные сети играет разведка. Наиболее часто применяемые типы разведок – это сканирование. Хотя поток пакетов при зондировании не такой интенсивный, как при атаках, обнаружение разведывательных сканирований не менее, а быть может и более важно, чем обнаружение атак. Поскольку любая продолжительная и направленная разведка предполагает возможную атаку. Потому рассмотрим датчики, которые помогут обнаружить некоторые распространенные типы сканирований.
Для обнаружения сканирования, с установленными флагами syn/fin подойдет датчик:
# tcpdump 'ip[13] & 0xff = 3'
Другой тип сканирования использует в пакетах установленный флаг reset
# tcpdump 'ip[13] & 0xff = 4'
При обнаружении целенаправленного зондирования стоит, не дожидаясь проведения атаки, обратиться к вышестоящему провайдеру с целью выработки общего плана действий при начале настоящей атаки.
Работа с вышестоящим провайдером
Что же делать, если вы подвергаетесь или уже подверглись атаке? Как реагировать?
Допустим, атаку вы уже пропустили. Безусловно, злонамеренный, ненужный трафик вам придется оплатить и с этим ничего не поделать. Однако, если вы однажды уже подверглись таким атакам, то они могут повториться снова. Значит, вам следует каким-то образом договорится с вашим вышестоящим провайдером, и во время следующей атаки пытаться отследить реальный источник пакетов. Помните, что любой, кто подключается ко всемирной сети, подписывает договор, в котором указано, что он не имеет права производить умышленно действия, которые могут причинить вред другим пользователям сети Internet.
Всеми силами следует стараться пресекать попытки такого использования Internet. Хорошими помощниками в таком деле является брандмауер, прокси-сервер и система трансляции адресов (NAT). При продуманной конфигурации сети с использованием указанных технологий после начала атаки можно переводить сеть на работу с резервным каналом, а основной отключать. Это поможет уменьшить материальный ущерб.
Во всех случаях, необходимо официально сообщать об атаках своему провайдеру. Все дальнейшее является плодом индивидуальной работы, не в последнюю очередь с администраторами. Следует отметить, что частные провайдеры обычно более дружелюбны и готовы помочь, хотя у государственных возможностей намного больше. В последнем случае, чаще всего приходится либо работать персонально с необходимыми людьми, либо заниматься бумагомаранием в особо крупных размерах.
Заключение
Все приведенные в статье примеры датчиков и скриптов, являются очень простыми и призваны лишь ознакомить читателя с идеями их создания. Для применения в реальных условиях они не предназначены.
В последнее время появился “сетевой шантаж”. Проводится атака на провайдера, после чего ему сообщается об этом и предлагается заплатить некую сумму денег за то, что бы атака не повторялась. Банально, но: не поддавайтесь на провокации и вымогательства! Помните: пойдя на поводу однажды вы не получаете абсолютно никаких гарантий, наоборот, лишь увеличиваете вероятность скорейшего повторения атаки.
Автор: Иван Песин