vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

#130 Повесть о Linux и DoS-атаках

Дата публикации: 23.03.2003
Количество просмотров: 6726

Повесть о Linux и DoS-атаках.

Данную статью написал Ivan N. Pesin.
Специально для сайта Nag.ru. ;-)

Введение.

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

Атаки типа "Отказ в обслуживании" основанные на протоколе ICMP.

Большое количество DoS-атак основывается на протоколе ICMP. Его служебные функции используются в некорректных целях. Рассмотрим несколько атак, которые могут использоваться с целью нанесения финансового вреда конкурентам. Такие атаки, из-за необходимости большого трафика, называются "грубыми". Классическим примером является Smurf. Ее единственным назначением есть сужение полосы пропускания жертвы.

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

Атака Smurf

Приведу пример из документа Cisco http://www.cisco.com/warp/public/707/5.html:

"...представьте себе сеть из 100 узлов и нарушителя с соединением 768Кбит. Он посылает поток эхо-запросов с измененным адресом источника и указанной скоростью по упомянутой сети из 100 узлов. ...В результате ответный поток от сети к жертве составит 76,8Мбит..."

Впечатляет, не правда ли?

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

К счастью для нас, проведение таких атак требует значительных умений, ресурсов и большого желания. Для начала нужно внедрить большое количество "агентов", которые обычно распространяются вместе с "троянами". Нужно собрать достаточно разведывательной информации о жертве и возможных посредниках. Это этапы достаточно длительные. Лишь после этого можно начинать распределенную атаку на отказ в обслуживании.

Защита от использования Вашей сети со злым умыслом

Рассмотрев распределенные атаки, становится ясным, что кроме защиты от угрозы извне, следует уделять внимание и защите изнутри. Ведь компьютеры внутренней сети могут быть заражены и использованы для dDoS-атаки в качестве агентов. Кроме того, что вы будете пособником атаки, на ваши каналы возрастет исходящая нагрузка. Посмотрим, что можно сделать для защиты Сети и ваших внешних каналов от вашей сети.

Первое, что приходит в голову, так это то, что при атаке подменяются адреса источника. Следовательно, если из вашей сети будут идти пакеты с не вашими адресами, то сеть инфицирована, а такие пакеты выпускать нельзя.

Второй важный момент - это протокол ICMP. В обычной работе его часть от остального трафика составляет 3-5%, а то и меньше. При проведении атак, очевидно, его доля будет значительно выше. Мысль - ограничить скорость исходящих ICMP пакетов до приемлемой для нормальной работы и неприемлемой для атак.

Атака c использованием 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 либо 0x00.

Команда активации датчика:

# 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). При продуманной конфигурации сети с использованием указанных технологий после начала атаки можно переводить сеть на работу с резервным каналом, а основной отключать. Это поможет уменьшить материально-экономический ущерб.

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

Заключение.

Все приведенные в статье примеры датчиков и скриптов, являются очень простыми и призваны лишь ознакомить читателя с идеями их создания. Для применения в реальных условиях они не предназначены.

Напоследок, хоть и банально, но:
не поддавайтесь на провокации и вымогательства!
Помните: пойдя на поводу однажды вы не получаете абсолютно никаких гарантий, наоборот, лишь увеличиваете вероятность скорейшего повторения атаки.

Анонс

Программа прежняя, только уменьшилась на один пункт:

  • Заметка о грозозащите - как программа подготовки к летнему сезону;
  • Рассказ о использовании односторонней спутниковой тарелки в Екатеринбурге.

     

  • Постараюсь завершить следующую часть теории надежности домашних сетей;
  • Материал по изготовлению антенн 2,4ГГц;
  • Новости, ссылки, комментарии - эта часть идет непрерывно, по мере накопления материала;
  • Ваши материалы - надеюсь, что их всегда будет немного больше, чем удается опубликовать. ;-)
От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/reviews/15704/povest-o-linux-i-dos-atakah.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться