DDoS - сокращение от английского Distributed Denial of Service, что означает "распределенная атака, отказ в обслуживании". Слово "распределенная" говорит о том, что атака производится не одним компьютером и, соответственно, не по одному каналу, а целой группой компьютеров-зомби, которые одновременно начинают атаку. Используется как грубая сила, так сказать, танком напролом, для завала сервера или роутера...
Приблизительная схема DDoS такова: хакер ломает кучу серверов по всему Инету, устанавливает туда DDoS-модули, а потом, когда возникает необходимость, приказывает всем своим зомбированным серверам валить жертву. Соответственно, чем больше у него таких зомби, тем страшнее атака. Существуют DoS-атаки, которые позволяют забить более мощный канал, чем у атакующего, а при DDoS общая пропускная способность всех зомбированных машин может в десятки раз превосходить пропускную способность атакуемого!
Хорош этот способ тем, что не требует от устроителя данного веселья широкого канала связи. В принципе он может даже не находиться в сети во время атаки, так как в данном случае используется чужой канал, чужой трафик и чужие компьютеры. Если при DDoS вылетит (вовремя выключат) половину компьютеров, атака все равно будет чувствительна для жертвы.
Работает это очень просто, и до сих пор загадка, почему данный вид атаки является малоиспользуемым. Как известно, любой канал - Интернета - не резиновый и имеет свои ограничения. Вот на этом все и основано, то есть, канал забивается мусором. Иногда бессмысленным, иногда конкретными запросами, иногда пакеты формируются так, чтобы ответ сервера был по размеру больше запроса. DDoS-модули могут быть также разными по написанию и использованию, например, бывают этакие навороченные троянские кони с системой прицеливания, а бывают просто бомбы с часовым механизмом. Даже баннер при желании можно использовать как DDoS-модуль. Для распространения можно использовать чаты, форумы или электронную почту. В принципе для DDoS можно использовать и прокси-сервер, но данный метод пока мало обкатан и не дает нужных результатов.
По видам можно разделить DDoS-модули на саморазмножающиеся (e-mail - вирусы) и размножающиеся вручную (ломаешь и ставишь). Для размножения вручную хорошо подходят компьютеры в интернет-кафе, и, если приготовиться к акции за пару месяцев, то можно осуществить хорошую атаку, а если есть друзья в других городах, готовые пройтись по местным интернет-кафе, то атака получится очень чувствительной. Как правило, серверные модули после установки слушают порт и ждут команд. Поэтому вероятность обнаружения у них выше, чем у молчаливых, которые хранят все данные о жертве в себе и ждут своего часа, никак не проявляя себя. Еще DDoS-модули делят по запросам на посылающих "мусор"(эти случайные данные, как правило, посылаются по UDP или ICMP); расширяющиеся, например, минимальный запрос на HTTP-сервер имеет длину пакета 7 байт, а ответ зависит от сервера (например, yahoo.com в ответ послал 21239 байт, что в 3000 раз больше; и загружающие сервер, что очень эффективно против поисковых машин и страниц, собранных с использованием Perl или PHP.
Итак, хакер нашел себе много компьютеров и хочет завалить любимый сервер. Как же найти слабое место? Для начала, как и перед любой битвой, надо изучить своего противника. Прежде всего узнать, какая стоит система на сервере, хотя бы примерно. Если это 95 или 98 Windows (маловероятно?!), то достаточно знать, что максимальное количество соединений на данной ОС - 255. Понадобится флудилка вроде PortFucker и примерно 3-4 машины. Запустив этот агрегат на порт 80, можно идти пить кофе, поскольку порты забьются достаточно быстро, и до тех пор, пока админ файрволом или роутером не отрежет запросы, сервер будет недоступен. Это больше всего похоже на анекдот про Ржевского, помните? Дали ему одну свечку в левую руку, вторую - в правую, дают третью, а он и не знает, куда ее деть... Вот так и сервер - вроде как занят, вроде работает, а никто это не видит. Пойдем дальше: если это NT4/2000/XP, то можно и старым способом, но надо значительно больше машин. При 64М RAM на сервере он нормально держит 7000 соединений, а значит надо 30 машин под 95/98, можно и 2-3 под NT, но сами зомби тоже порядком подвиснут. В данном случае достаточно просто загрузить сервер мусором и забить канал (UDP пакеты), что сильно затормозит сервер. Но как на NT, так и на любом сервере Linux есть такая хорошая вещь, как timeout, то есть ограничение по времени. Это очень скользкая часть, поскольку если ограничение маленькое (1-2 секунды), то клиенты на медленном канале будут с трудом получать необходимое. Но если Timeout около минуты, то это самое слабое место, причем нет разницы, где он установлен, на POP3-порту или FTP. Можно написать программу, которая будет коннектиться, посылать команду типа "help" и опять коннектиться, и опять "help", поскольку сервер не отличает "хорошего" клиента от зомби, и он будет вынужден висеть с каждым клиентом по минуте, а это достаточно для забивания всех возможных ресурсов. Если же жертва - поисковый сервер, то можно сконнектиться, сделать запрос по букве "а", вторым сконнектиться, сделать запрос по букве "б" и т.д. Все закончится тем, что сервер будет искать и мучить себя до потери пульса, а пульс сервер "пень-3/256Mb/канал на 64к" потеряет после двенадцатого запроса. Если же это определенно линух, да еще и на хорошей машине, то тут необходим только мусор, то есть, если машина хороша, то слабое место в ней - ее канал в И-нете. Следовательно, надо набирать как можно больше зомби и устраивать одноразовую массовую бомбардировку.
Допустим, что с жертвой мы разобрались. Теперь давайте посмотрим на хакерское "оборудование", то есть программы для зомбирования машин. Прежде всего, надо определиться, что лучше подходит. Если есть доступ к большому количеству интернет-кафе и подобным заведениям, то писать надо определенно под Windows. Если же есть огромное количество серверов с возможностью запуска Perl, то на нем и надо писать. А если имеется просто 2000000 показов баннеров, и при этом есть возможность показывать Flash-баннеры или html-баннеры (что значительно лучше), то ими и надо пользоваться. Затем, выбрав, на чем писать и тактику нападения, неплохо посчитать, сколько надо машин и что лучше делать - серверподобного зомби или же все-таки бомбу с часами. Определившись и прикинув план работы программы (например, ждем 12:00 пятницы тринадцатого, затем начинаем бомбежку), стоит приступить к написанию программы. При реальных взломах не рекомендуется пользоваться готовыми DDoS-модулями, они хороши в обучающих целях, но на практике их быстро найдут, и жертвоприношение не состоится.
НЕМНОГО ИСТОРИИ
Чтобы не быть голословным и показать, что это все действительно работает, давайте посмотрим реальное прошлое. 1. Yahoo
Наиболее шумный случай использования DDoS произошел в начале февраля 2000 года с сервером компании и отрубил его на три часа. Для компании такого размаха три часа - это по примерным подсчетам 1.2 млрд. долларов. По заявлениям прессы атака была произведена с университетских компьютеров, которые оказались зомбированными. Было задействовано более тысячи компьютеров-зомби. В то же время был атакован сервер интернет-магазина e-bay, а затем книжный магазин amazone.com. Атакующим оказался канадец, называющий себя MafiaBoy, пятнадцати лет отроду. Все атаки производились банальным флудом (UDP-пакетами с корявым содержанием), расчет велся на слабый канал, и стоит отметить, в расчетах он не ошибся, поскольку канал действительно не выдержал. Парень отделался 160 долларами штрафа и восьмью месяцами лишения свободы.
2. RLE-SLE
Целенаправленное использование баннеров одной компании против другой. Ребята из RLE заметили, что их дизайн был слизан SLE-шниками, после чего по словам владельцев SLE было зарегистрировано три сайта, и начались "показы" баннеров с частотой примерно 20-30 показов в секунду. Сайт плюхнулся, переделали алгоритм, подняли. Теперь уже на всех участников, а не только на тех трех зарегистрированных, пошли показы с частотой 100-150 запросов в секунду. В принципе ребята просто хотели помочь с накруткой баннеров. Но вот сервер SLE не выдержал потока, от чего и слег. Завершение этой истории подробно не описано, но дизайн ребятки сменили. В настоящий момент сайт находится в дауне. Способ решения проблемы нельзя назвать тактичным, но то, что он сработал и ожидаемый результат был получен - это очевидно. Учитывая размах RLE (вчера было показано 27922759), использование этой дырочки может повредить и более сильным сайтам, не каждый может выдержать такой резкий наплыв "посетителей".
ЧЕТЫРЕ ОСНОВНЫХ ТИПА DoS-АТАК
Насыщение полосы пропускания (bandwidth consumption)
Эти атаки основаны на том, что хакер под завязку заполняет всяческим мусором атакуемую им сеть. Необходимым условием для этого является наличие у взломщика широкого канала (во всяком случае, шире, чем у атакуемого хоста). Он отсылает на вражеский сервер тучи различных запросов и прочей информационной пурги насколько позволяет ширина его канала, забивая линию атакуемой машины. Соответственно, забитая линия не может пропустить к серверу еще какие-либо другие запросы. Вот вам и DoS!). Пользователи не могут получить доступ к серверу, а у самого сервера начинает съезжать крыша, и он даже может упасть в даун. Инфа с сервера становится временно недоступной для юзеров (пока админ не спохватится и не примет меры). Bandwidth consumption - отличный выбор, если нужно временно вывести из строя какой-нибудь web-сервер или базу данных. Он также отлично подходит для выбрасывания из сети всяких хамящих пользователей, ведь у них коннект часто очень хиленький. И совсем не обязательно самому висеть на широком канале - достаточно иметь удаленный доступ к машине, висящей на таком конце. Самый типичный (и самый тупой) пример bandwidth consumption - это банальный ping. Почему тупой? Да потому, что пакеты ping-запросов и ping-ответов незначительно отличаются по размеру, и канал у атакующего и атакуемого забивается в равной степени. Фишка катит, если у атакующего канал шире, чем у атакуемого, но это туфта, так как атакуемыми чаще всего оказываются сервера (с широченными каналами), а не левые диалапные юзеры. Поэтому "не тупыми" bandwidth consumption-атаками считаются такие, при которых атакуемый компьютер вынужден отсылать значительно больше информации, чем атакующий. Простой пример - самый обычный HTTP-запрос на страничку. Хакер шлет серверу малюсенький запрос, типа "GET /index.html", а сервер ему отсылает эту самую index.html, размер которой может оказаться в сотни раз больше, чем размер запроса. Дальше вступает в силу элементарная математика: хакер висит, допустим, на мегабайтном канале, а сервер - на десятимегабайтном; разница - пропускная способность канала сервера больше в десять раз; следовательно, если ответ будет по размеру превосходить запрос, скажем, в пятнадцать раз, у хакера будет хороший шанс вывести из строя вражеский сервер. Все очень просто!. Но тут есть еще одна заковырка: а как же index.html, которая отправляется хакеру от сервера с каждым новым запросом? Она же тоже забивает атакующему канал... Да уж, еще как забивает - от такого трафика хакер со своим хиленьким каналом уйдет в даун, когда сервер еще и почесаться не успеет. Решение, как всегда, по-хакерски простое: подменять source IP (айпишник отправителя) в пакетах запросов на какой-нибудь другой, чтобы проклятые index.html уходили на этот самый другой адрес, не забивая канал хакера. При этом желательно, чтобы source IP в каждом запросе был разный, а то нехилая нагрузка пойдет на машину с этим адресом. Может спохватиться админ сети, которой она принадлежит, - лишний шум, лишняя возня - ничего хорошего. А так на разные IP`шки приходит какая-то хтмлка - ну, подумаешь, ошибка маршрутизации...
Если хорошенько пошевелить мозгами, то вы сами догадаетесь, как можно кого-нибудь задосить еще одним способом: находится огромная сеть (со множеством машин) на широченном канале, и ей посылаются запросы, source IP в которых заменен на IP жертвы. Вся эта байда начинает слать на несчастный IP`шник ответы, думая, что запросы пришли именно от него, забивая по самые уши канал атакуемому и устраивая бедняге мега-DoS. Такая фишка называется усилением (или умножением) DoS-атаки.
Недостаток ресурсов (resource starvation)
Это атаки, направленные на захват критических системных ресурсов: процессорное время, место на харде, память и т.д. Resource starvation часто очень похож на bandwidth consumption: взломщик опять-таки отсылает множество запросов на сервер, после чего тому наступает полный крах). Но на этот раз пакеты не забивают канал хоста-жертвы, а занимают, скажем, все его процессорное время. Ведь на обработку каждого пакета сервер затрачивает некоторое процессорное время. Остается только выбрать такие пакеты, на которые тратится достаточно много процессорного времени, и вперед - бомбить ими сервер Канал-то может оказаться достаточно широким - с ним все будет ОК, а вот процессор просто захлебнется, обрабатывая всю эту бомбежку. Результат - все висит, пользователи не могут получить доступ к сервисам. Еще один популярный пример, когда хард забивается логами. Еcли админ "криво" отконфигурировал систему логирования на своем сервере и не поставил ей лимит, тогда достаточно выбрать такие пакеты, которые жрут в логах больше места, и начать отсылать их на сервер пачками. Через какое-то время файлы логов разрастутся до немеренных размеров, сожрут все место на харде, и машина опять окажется в "затруднительном положении". Правда, грамотные люди держат логи на отдельном от системного харде. Также resource starvation актуален, если у хакера уже есть какой-то (ограниченный) доступ к ресурсам машины (например, у него есть непривилегированный аккаунт) - тут поле для действий значительно шире. Взломщик не ограничен одними только пакетами, которые он может отсылать на удаленный сервер. Тут немаловажную роль играет, насколько грамотно построена система квотирования. Например, если на хостинге есть доступ к cgi, можно написать скрипт, который нехило жрет память или, опять же, ресурсы процессора (ну, скажем, циклически создает какие-нибудь огромные массивы/хэшы в памяти или вычисляет какие-нибудь громоздкие математические формулы), и обращается к нему несколько сот/тысяч/десятков тысяч раз. Если система квотирования настроена глючно, то такой скрипт очень скоро сожрет всю память (или забьет процессор), а если все пучком, то скрипт, достигнув отведенного ему лимита в жоре памяти, не получит доступа к мозгам до тех пор, пока не выгрузит оттуда старые данные.
Ошибки программирования (programming flaw)
Эти атаки направлены на слабые места, баги и недокументированные функции операционных систем, программного обеспечения, процессоров и программируемых микросхем. Зная дырки в чем-то из вышеперечисленного, можно создать и отправить по назначению определенный пакет, который вызовет какую-либо ошибку, переполнение буфера или стека. В результате этого возможны тяжкие последствия для всей системы. Она будет виснуть, глючить и биться в конвульсиях. Причем, если хорошо знать архитектуру процессора, на котором запущена система, то не составит труда вызвать какую-нибудь некорректную инструкцию или операцию в кремниевых мозгах. Все мы знаем, что не существует осей, софта и железа без багов. Недаром bug-traq на хакерских серверах пополняются с завидной регулярностью. Самый тривиальным пример: программер пишет клиент-серверное приложение, работающее по такому-то протоколу, в спецификации которого сказано, что такое-то поле такого-то пакета может содержать максимум 65500 бит данных. Программер сам писал клиентскую часть, и, как оказалось, на практике больше 255 бит в это поле пихать не приходится, поэтому он написал свою клиентскую часть так, что она шлет в этом поле максимум 255 бит, а больше - не умеет. В серверной части программы кодер написал, что такая-то переменная (в которую будет передаваться содержимое того самого поля из того самого пакета) имеет длину 255 бит (все равно больше приехать не может, так как клиентская часть не умеет отсылать больше 255). Поставили сервер, раздали юзерам клиентские программы - все пучком, все работает, все довольны. Но тут пришел хакер, разобрался во всем этом деле и устроил в этом маленьком раю большой DoS. Он модифицировал клиентскую часть (или написал свою) так, чтобы та слала 65500 бит данных в том самом поле именно того пакета. Все хорошо, протокол позволяет передавать данные такой длины, а вот сервер к такого рода отношениям не готов... Данные приходят, и все 65500 бит записываются в переменную, размер которой 255 бит, - нарушается организация памяти, программа глючит, сервер висит, клиенты не могут получить к нему доступ.
Маршрутизация и DNS
Тут и так все ясно - если иметь доступ к маршрутизатору, то можно изменить таблицы маршрутизации таким образом, чтобы желающие попасть на сервер с IP`шником таким-то попадали совсем на другой IP, либо на IP, который вообще не существует. То же самое DNS, но уже в отношении сайтов. Если получить доступ к кэшу DNS`ки, можно привязать искомое доменное имя совсем к другому IP`шнику, и тогда юзеры будут попадать на совсем другой сервер, а не туда, куда они хотели. Если же вставить вообще несуществующий IP, то это будет больше похоже на DoS. Особенностью этих атак является то, что сам атакуемый сервер (да он, в общем-то, и не атакуем) продолжает нормально работать, в то время, как его юзеры не могут на него попасть, думая, что он в дауне.
DoS-АТАКА - ВИРТУАЛЬНЫЙ АНАЛОГ ЯДЕРНОЙ ВОЙНЫ?!
DoS-атак существует несколько, а средства для их проведения вполне доступны. Все необходимые инструменты для них можно найти в Инете. Так что устроить такую атаку при большом желании может даже ушастый ламер, если найдет готовые тулзы (обезьяна с гранатой). Последствия, к которым приводят такие забавы, могут оказаться очень даже не детскими и пострашнее, чем последствия от вирусов. Именно поэтому DoS становится все более популярным и широко используемым в среде кибертеррористов и киберманьяков, а правительства некоторых развитых стран даже рассматривают вопросы ведения виртуальных войн. Так что будущее, которое лет 10-20 назад нам рисовали в своих рассказах писатели-киберпанки, уже не за горами.
Ключевые слова : сервер, можно, больше, канал, может, будет, доступ, очень, сервера, достаточно, просто, время, которые, машин, хакер, пакеты, могут, атаки, атака, программы
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.
В избранное
На главную
(0)
