Повесть о Linux и DoS-атаках
введение
В наши дни атаки компьютерных сетей типа "отказ в обслуживании" (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. Ее единственным назначением есть сужение полосы пропускания жертвы.
Сценарий таков: посылается эхо-запрос с адресом источника, подмененным на адрес жертвы. Следовательно, эхо-ответ уже приходит к компьютеру-жертве. Если, к тому же, эхо запрос является широковещательным для сети, на него могут отреагировать все компьютеры указанной сети и поток, направленный на жертву, уже становится весьма ощутимым.
Приведу пример из документа 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 либо 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'
Другой тип сканирования использует в пакетах установленный флаг RST:
# tcpdump 'ip[13] & 0xff = 4'
При обнаружении направленных и всесторонних зондирований стоит, не дожидаясь проведения атаки, обращаться к вышестоящему провайдеру с целью выработки общего плана действий при начале настоящей атаки.
работа с вышестоящим провайдером
Что же делать, если вы подвергаетесь или уже подверглись атаке? Как реагировать?
Допустим, атаку вы уже пропустили. Безусловно, злонамеренный, ненужный трафик вам придется оплатить и с этим ничего не поделать. Однако, если вы однажды уже подверглись такой атаке, попытки будут продолжаться. Значит, вам следует каким-то образом договорится с вашим вышестоящим провайдером, и во время следующей или следующих атак пытаться отследить реальный источник пакетов. Помните, что любой, кто подключается к всемирной сети, подписывает договор, в котором указано, что он не имеет права производить умышленно действия, которые могут причинить вред другим пользователям сети Internet.
Всеми силами следует стараться пресекать попытки такого использования Internet. Хорошими помощниками в таком деле является файрволл, прокси-сервер и система трансляции адресов (NAT). При продуманной конфигурации сети с использованием указанных технологий после начала атаки можно переводить сеть на работу с резервным каналом, а основной отключать. Это поможет уменьшить материально-экономический ущерб.
/* Хорошим подспорьем в оперативной борьбе с DoS-атаками являются добросердечные, еще лучше — неформальные взаимоотношения с технической поддержкой вышестоящего провайдера. Заметив первые признаки надвигающейся атаки, вы можете позвонить саппорту и — минуя стадию бумагомарательства или утомительного ожидания — просто попросить заблокировать нежелательный трафик по каким-то критериям (лучше, если критерии озвучите вы сами). По прошествии некоторого времени можно позвонить опять и откатить все до прежнего состояния.
Да, и вот еще: если вы не являетесь провайдером услуг Internet, а просто рядовой абонент, подключающий к Internet, допустим, свой офис, можете вовсе отказаться от потенциально опасных видов трафика, например, от ICMP Echo. Проверено, жить без него можно: традиционный ping может быть заменен на TCP ping (например hping), юниксовый traceroute (и некоторые реализации под win32) также могут обходиться без ICMP Echo. — прим. Alice D. Saemon */
Во всех случаях, необходимо официально сообщать об атаках своему провайдеру. Все дальнейшее является плодом индивидуальной работы, не в последнюю очередь с администраторами. Следует отметить, что частные провайдеры обычно более дружелюбные и готовы помочь, хотя у государственных возможностей намного больше. В последнем случае чаще всего приходится либо работать персонально с необходимыми людьми, либо заниматься бумажкописанием в особо крупных размерах.
заключение
Все приведенные в статье примеры датчиков и скриптов, являются очень простыми и призваны лишь ознакомить читателя с идеями их создания. Для применения в реальных условиях они не предназначены.
Напоследок, хоть и банально, но: не поддавайтесь на провокации и вымогательства!
Помните: пойдя на поводу однажды вы не получаете абсолютно никаких гарантий, наоборот, лишь увеличиваете вероятность скорейшего повторения атаки.
В наши дни атаки компьютерных сетей типа "отказ в обслуживании" (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. Ее единственным назначением есть сужение полосы пропускания жертвы.
Сценарий таков: посылается эхо-запрос с адресом источника, подмененным на адрес жертвы. Следовательно, эхо-ответ уже приходит к компьютеру-жертве. Если, к тому же, эхо запрос является широковещательным для сети, на него могут отреагировать все компьютеры указанной сети и поток, направленный на жертву, уже становится весьма ощутимым.
Приведу пример из документа 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 либо 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'
Другой тип сканирования использует в пакетах установленный флаг RST:
# tcpdump 'ip[13] & 0xff = 4'
При обнаружении направленных и всесторонних зондирований стоит, не дожидаясь проведения атаки, обращаться к вышестоящему провайдеру с целью выработки общего плана действий при начале настоящей атаки.
работа с вышестоящим провайдером
Что же делать, если вы подвергаетесь или уже подверглись атаке? Как реагировать?
Допустим, атаку вы уже пропустили. Безусловно, злонамеренный, ненужный трафик вам придется оплатить и с этим ничего не поделать. Однако, если вы однажды уже подверглись такой атаке, попытки будут продолжаться. Значит, вам следует каким-то образом договорится с вашим вышестоящим провайдером, и во время следующей или следующих атак пытаться отследить реальный источник пакетов. Помните, что любой, кто подключается к всемирной сети, подписывает договор, в котором указано, что он не имеет права производить умышленно действия, которые могут причинить вред другим пользователям сети Internet.
Всеми силами следует стараться пресекать попытки такого использования Internet. Хорошими помощниками в таком деле является файрволл, прокси-сервер и система трансляции адресов (NAT). При продуманной конфигурации сети с использованием указанных технологий после начала атаки можно переводить сеть на работу с резервным каналом, а основной отключать. Это поможет уменьшить материально-экономический ущерб.
/* Хорошим подспорьем в оперативной борьбе с DoS-атаками являются добросердечные, еще лучше — неформальные взаимоотношения с технической поддержкой вышестоящего провайдера. Заметив первые признаки надвигающейся атаки, вы можете позвонить саппорту и — минуя стадию бумагомарательства или утомительного ожидания — просто попросить заблокировать нежелательный трафик по каким-то критериям (лучше, если критерии озвучите вы сами). По прошествии некоторого времени можно позвонить опять и откатить все до прежнего состояния.
Да, и вот еще: если вы не являетесь провайдером услуг Internet, а просто рядовой абонент, подключающий к Internet, допустим, свой офис, можете вовсе отказаться от потенциально опасных видов трафика, например, от ICMP Echo. Проверено, жить без него можно: традиционный ping может быть заменен на TCP ping (например hping), юниксовый traceroute (и некоторые реализации под win32) также могут обходиться без ICMP Echo. — прим. Alice D. Saemon */
Во всех случаях, необходимо официально сообщать об атаках своему провайдеру. Все дальнейшее является плодом индивидуальной работы, не в последнюю очередь с администраторами. Следует отметить, что частные провайдеры обычно более дружелюбные и готовы помочь, хотя у государственных возможностей намного больше. В последнем случае чаще всего приходится либо работать персонально с необходимыми людьми, либо заниматься бумажкописанием в особо крупных размерах.
заключение
Все приведенные в статье примеры датчиков и скриптов, являются очень простыми и призваны лишь ознакомить читателя с идеями их создания. Для применения в реальных условиях они не предназначены.
Напоследок, хоть и банально, но: не поддавайтесь на провокации и вымогательства!
Помните: пойдя на поводу однажды вы не получаете абсолютно никаких гарантий, наоборот, лишь увеличиваете вероятность скорейшего повторения атаки.
Ivan N. Pesin
Сетевые решения. Статья была опубликована в номере 04 за 2003 год в рубрике sysadmin
