Текст книги "Спецвыпуск журнала «Хакер» 47, октябрь 2004 г."

Автор книги: Хакер Журнал

сообщить о нарушении

Текущая страница: 6 (всего у книги 21 страниц)

Поиск уязвимостей

Отдельно хотелось бы поговорить о поиске уязвимостей. Порой очень трудно определить, какой софт стоит на удаленной системе, особенно когда не имеешь к ней даже малейшего доступа. На помощь приходят различные сканеры, например, Retina, Shadow Security Scanner, XSpider. Сканирование ими даст исчерпывающую информацию об удаленной системе.

Заключение

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

Автор выражает благодарность NSD (nsd@nsd.ru) за скриншоты.

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

Всегда думай о своей безопасности! Никогда не мешает использовать соксы для подключения к удаленной системе. Если у тебя возникнут затруднения с выбором терминала для этих целей, я посоветую тебе PuTTY: он умеет работать через прокси– и сокс-сервера, а также имеет множество полезных функций, которые наверняка тебе пригодятся. Не нужно забывать чистить логи, ведь они – доказательство присутствия в системе. Не забудь почистить .bash_history, если ты зашел как обычный пользователь через стандартный ssh или telnet. Этот файлик обычно находится в домашней директории пользователя и, как ты уже заметил, является скрытым (перед именем файла стоит «.»). В хистори содержатся все команды, которые ты выполнял. И запомни: хистори записывается в файл только после того, как ты сделаешь лог-аут. Есть и другой вариант решения этой проблемы: после входа в систему выполнить команду «UNSET .HISTFILE».

Где же брать эксплоиты

Эксплоиты не растут на эксплоитном дереве и сами к тебе не прилетят (за исключением fake :)). Лучше сливать их с популярных ресурсов, таких, как http://www.securitylab.ru, http://packetstormsecurity.nl, http://security.nnov.ru.

ССЫЛКИ

www.securitylab.ru, www.security.nnov.ru, www.packetstormsecurity.nl – самые лучшие ресурсы по безопасности, самые свежие багтраки, секьюрити-репорты и обсуждения.

www.nsd.ru – тут ты тоже сможешь почерпнуть много интересного.

www.bugtraq.ru – хороший багтрак, часто обновляется.

www.google.ru – превосходный поисковик. Наш выбор.

www.xakep.ru – мегаресурс ;).

Не компилится?

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

Если изначально нет никакого доступа к хостингу, можно просто купить на нем аккаунт на месяц. А если денег совсем нет, можно попробовать закардить или побрутать :).

Теоретически в сети нет ни одного неуязвимого сервера. Весь вопрос заключается только в умении.

Будь предельно осторожен, проверь командой finger и w, нет ли в системе активных администраторов.

Скрипты, написанные на Perl, следует заливать в текстовом режиме и устанавливать на них chmod 755 или 777. Для того чтобы эксплоит выполнился, его тоже необходимо проchmod’ить как +x (chmod xploit +x).

Невидимость в *nix / Обзор stealth-механизмов бэкдоров

Адиль Хаштамов (adi1@ok.kz, http://unl0ck.blackhatz.info )

После взлома системы чрезвычайно сложно оставить там незаметный черный ход. Опытные администраторы очень быстро обнаруживают все известные и неизвестные бэкдоры. О том, как перехитрить админа и скрыть присутствие лазейки в системе, и пойдет речь в этой статье.

Давай подумаем, чем простейший бэкдор может выдать свое присутствие.

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

Во-вторых, если бэкдор запущен и работает, то он присутствует в системе как процесс. Соответственно, может быть обнаружен админом с помощью утилиты ps, вываливающей в консоль список процессов.

В-третьих, черный ход «висит» на каком-то порту и ждет входящего соединения для того, чтобы открыть командный шелл взломщику, из-за чего может быть обнаружен массой различных способов, самым простым из которых является анализ результата работы утилиты netstat.

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

Прячем процесс и файл

Алгоритмы сокрытия бэкдора от утилит ps и ls практически идентичны, поэтому я разберу только случай маскировки процесса. Надеюсь, что с маскировкой файла у тебя трудностей не возникнет.

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

Первый способ заключается в корректировке исходного кода утилиты, ответственной за вывод списка процессов. То есть мы должны будем найти сорцы ps, в них обнаружить функцию, которая выводит процессы на экран, и путем недолгих преобразований заставить забыть ее о нашем бэкдоре. Трудностей встретится целая куча: во-первых, придется рыться в чужих сорцах, а хуже, чем копаться в исходных кодах системных юниксовых утилит, ничего не придумаешь; во-вторых, реализация для каждой *nix-системы будет новая, ибо я сомневаюсь, что ps везде одинаковая.

Также можно воспользоваться другим приемом, состоящим в маскировке созданного бэкдором процесса. Это самый простой в реализации способ. Потребуется написать программу, полностью заменяющую ps, которая выплевала бы всегда один и тот же текст. После взлома запомним список «постоянно висящих» процессов, запишем его, например, в файл, который и будем выводить всякий раз при запуске утилиты. Применение данного способа не требует от хакера глубоких познаний в программировании, хватит и школьного курса. Ведь в программу всего то и надо, что понапихать функций printf(). Жаль только, что любой нормальный админ в здравом уме и трезвой памяти заподозрит неладное сразу же после второго запуска ps.

Ну и, наконец, самый интересный способ. Когда утилита ps пытается вывести все запущенные в данный момент в системе процессы, она обращается к ядру с некоторым системным запросом. Анализируя ответ ядра, она составляет список и выбрасывает его на экран. Способ маскировки бэкдора в данном случае будет заключаться в «обработке» этого самого системного ответа.

Грубо говоря, требуется перехватить системный вызов и подменить его на фальшивый, в котором будут отсутствовать всяческие данные о нашем бэкдоре. Осуществить это можно, написав Loadable Kernel Module (LKM), модуль, подгружаемый к ядру системы. Он подменит запись в таблице системных вызовов, в результате чего все запросы будут передаваться не стандартной функции, выдающей список процессов, а нашей хитрой процедурке. Похожий модуль был написан stan'ом из команды unl0ck team, но, к сожалению, он не захотел делиться с народом полноценной программой, поэтому написал некий PoC, который заставляет программу ps и ей подобные выводить сообщение о том, что в системе процессов нет как таковых. Немного подкорректировав код модуля (ты найдешь его на CD, прилагающемся к журналу) и добавив в него функцию поиска и сокрытия нужного нам процесса, можно добиться самой качественной маскировки своего бэкдора.

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

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

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

Прячем соединение

Каждому юниксоиду известно, что для просмотра списка открытых соединений в системе применяется утилита netstat. Если будет использован обычный бэкдор, который открывает шелл на заданном TCP-порту, первый же запуск этой программки выдаст взломщика с головой. Как же укрыться от netstat? Аналогично ситуации с ps, способов очень много.

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

Другой способ – написать LKM, который бы перехватывал системные вызовы утилиты netstat. Это вообще самый лучший подход к редактированию вывода любых системных утилит, будь то ps или netstat. Он немного сложен в реализации, но, если знать, куда копать – какие системные вызовы в каких случаях перехватывать, то справиться можно.

Допустим, нам удалось скрыть бэкдор из списка открытых соединений. А что, если администратор проверяет свою систему не локально, а, например, удаленно с помощью различных программ вроде nmap? Тогда при сканировании администратор заметит, что в системе открыт «левый» порт, а netstat его не показывает. Админ сразу же просечет фишку, и больше мы на его машину не попадем. Именно для таких случаев хакеры придумали еще кое-что для сокрытия своего присутствия в системе. При написании бэкдора следует использовать не SOCK_STREAM, а SOCK_RAW, то есть вместо TCP-сокетов юзать RAW-сокеты. Красивый способ: RAW-сокеты позволяют слушать весь входящий трафик, а это дает нам огромные возможности. Например, мы можем сделать так, чтобы после посылки определенного пакета бэкдор открывал шелл на определенном порту. Примеры подобных бэкдоров – на www.packetstormsecurity.nl.

Маскируем трафик

Грамотный администратор не всегда ограничивается стандартными средствами при поиске бэкдора в своей системе. Иногда он прибегает к поиску злоумышленника с помощью снифера или IDS, подобной Снорту. А от зоркого глаза (или чуткого носа? :)) «нюхача» не скроется ни один даже самый навороченный бэкдор.

Как же уберечься от надоедливого админа или его кошмарной IDS? Тут поможет только одно – полное шифрование трафика, которое уберет заметный plain text команд из логов снифера. Хакеры используют для этого самые разные криптоалгоритмы: и IDEA, и xTEA, и Blowfish, и Twofish.

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

Напоследок

В этой статье я описал лишь самые популярные подходы к маскировке. Время не стоит на месте, постоянно изобретаются все новые и новые способы сокрытия бэкдоров. Старайся не отставать от прогресса, ведь не просто так говорят: «Кто остановился, тот умер!»

Linux Kernel Module

#include

#include

#include

/* linux ps fake utility.

*

* if fake ps doesn't work, try below SYS_CALLS

*

* 1. SYS_rt_sigaction

* 2. SYS_rt_sigprocmask

* 3. SYS_clone

*

* the main hook function is fakepid(); this function try to

* hook SYS_call = SYS_waitpid, then programm print some inte

* resting message to the screen :)

*

* (c) by stan [unl0ck team] 2004

*/

extern void *sys_call_table[];

int (*origpid)(const char *path);

int fakepid(const char *path)

{

printk(«No proccess found!»);

return 0;

}

int init_module(void)

{

origpid = sys_call_table[SYS_waitpid];

sys_call_table[SYS_waitpid] = fakepid;

printk(«Module successfully loaded!»);

return(0);

}

void cleanup_module(void)

{

sys_call_table[SYS_waitpid] = origpid;

printk(«Module successfully unloaded!»);

}

Хитрости с демонами

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

Есть еще более простой способ – проход в систему посредством доверенных хостов. Многие сетевые демоны, такие, как sshd, rlogin, rshd, при соединении с кем-либо обращаются к файлам ~/.rhost, /.rhost (uid=0 auth), /etc/host.equiv, ~/.shosts, проверяя, нет ли там адреса соединяющегося с ними пользователя, и если есть, то документы у него не спросят. То есть, если нам вписать в вышеперечисленные файлы некий хост, то он будет пропущен на сервер без аутентификации. А если в этом файле будет пара «+ +», то на сервер сможет войти вообще любой хост без предварительной аутентификации. В этом случае может очень пригодиться crontab для того, чтобы поставить точное время, когда нужно создавать/удалять файл доверенных хостов – мы же не хотим, чтобы администратор нас засек. При этом следует помнить, что перед уходом с сервера нужно почистить логи. Но не полностью удалять, а аккуратно подрезать записи, оставленные системой только о собственных грязных делишках :).

Много бэкдоров, хороших и разных

Не всегда есть возможность и желание писать бэкдор самому. Я приготовил коротенький обзор полезных бэкдоров/руткитов, доступных в сети:

Bdoor.c – бэкдор, маскирующийся под HTTP-демон. Он не использует никаких stealth-технологий. Применять его можно только в расчете на невнимательность администратора (явление, надо признать, очень частое).

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

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

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

kbdv2.c – Linux loadable kernel module backdoor. Классический пример бэкдора, подгружаемого к ядру системы. Перехватывает системные вызовы (SYS_stat, SYS_getuid). Интересен бэкдор не столько своими функциями, сколько хорошо комментированным исходным кодом. Его изучение может быть очень полезно при написании собственной программы подобного рода.

Neth – детище Forb’а. Отличный бэкдор! Написанный с использованием «сырых» сокетов, он не открывает TCP-портов, за счет чего не палится ни netstat’ом, ни удаленным сканером.

Практически все перечисленные мной программки можно скачать с сайта www.packetstormsecurity.nl.

Бэкдор – черный ход в систему.

Массу полезной информации и программ ты можешь найти на www.packetstormsecurity.nl.

Умный админ может регулярно считать MD5-хэши от всех файлов в системе. Он без труда может заметить изменения в системных утилитах.

Утилита cron поможет обхитрить администратора.

От удаленного сканирования может спасти только использование RAW-сокетов.

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

Перехват системных вызовов – самый уважаемый в хакерских кругах способ сокрытия бэкдора от утилит операционной системы.

DoS/DDoS / Атака грубой силы

Ермолаев Евгений aka Saturn (saturn@linkin-park.ru)

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

Цель

Основная цель DoS/DDoS-атак – вывести объект из рабочего состояния. Конечно, в большинстве случаев глобальная атака приводит к большим финансовым потерям со стороны атакуемого. Например, если какой-либо коммерческий сайт упадет на несколько часов, то это нанесет вред бизнесу, а если на неделю, то владелец ресурса вполне может разориться. Или взять локальные сети. Дело в том, что одним из эффектов популярных атак на Denial of Service (DoS) является огромный трафик, направляемый на жертву. Если для крупной западной фирмы это мелочь, то для небольшой отечественной домашней сети средняя атака может грозить разорением. Кроме огромного вреда, наносимого жертве, такие нападения отличаются простотой и огромной эффективностью. Против них нет стопроцентной защиты. Именно названные выше факторы привлекают к DoS внимание специалистов по сетевой безопасности и… DoS'еров.

Принцип работы

Для того чтобы обнаружить, а уж тем более организовать DoS/DDoS-атаку, нужно разобраться в ее принципах. Эти атаки не направлены на получение доступа к ресурсам или к важной информации. Атака DoS делает ресурс недоступным для использования путем нарушения его нормальной работы. Атаку на отказ в обслуживании можно провести всего двумя способами: использовав уязвимости в программном обеспечении жертвы и при помощи отсылки большого количества определенно составленных сетевых пакетов (флуд). Первый способ состоит в том, чтобы, используя уязвимости типа переполнения буфера, отослать код, выполняющий DoS на сервере. Поскольку атака будет проводиться «изнутри», то через очень короткое время объект зависнет или будет отключен от интернета. Этот способ не требует больших вычислительных ресурсов нападающего, однако такая атака предполагает использование уязвимостей, что само по себе усложняет задачу. Поскольку никто не хочет излишне заморачиваться, в народе более популярен второй способ, которому мы и уделим основное внимание. Это пример применения простой грубой силы, которая практически не нуждается в приложении ума. Идея состоит в том, чтобы переслать как можно больше «кривых» запросов серверу (впрочем, не только «кривых»: от огромного количества нормальных пакетов, например GET-запросов для HTTP-сервера хосты падают с таким же успехом). Дело в том, что при получении сервером пакета данных происходит его обработка. Если приходит пакет, но сервер занят приемом или обработкой другого пакета, то вновь приходящий запрос ставится в очередь, занимая при этом часть ресурсов системы. При проведении DoS-атаки серверу отсылается большое количество пакетов определенного размера. При этом ответ сервера не ожидается (обычно адрес отправителя фальсифицируется – спуфинг). В результате, из-за того что сервер оказывается перегружен информацией, он либо отключается от интернета, либо зависает. В любом случае, нормальные пользователи некоторое время (иногда довольно продолжительное) не могут пользоваться услугами пострадавшего сервера. Просто и со вкусом :). Однако если сервер атакует одна «точка», он вполне может закрыться от нее фаерволом. Кроме того, для проведения качественной DoS-атаки необходима довольно высокая пропускная способность канала. Поэтому атака на отказ в обслуживании в большинстве случаев проводится сразу с нескольких машин. Атака, в проведении которой участвует много машин (обычно это затрояненные десктопы, их называют «зомби»), получила название DDoS (Distributed Denial of Service). Для сколь угодно мощного сервера всегда можно подобрать достаточное количество зомбиков (благо дырявых систем и ушастых юзверей по миру много развелось).

Есть несколько способов получения «зомби». Во-первых, это массовое внедрение трояна на компьютеры мирных пользователей. Самый популярный способ управления троянами – IRC, то есть организация ботнета. При посылке определенных команд троян активируется и мирный домашний компьютер (с широкополосным выходом в интернет) становится источником большого количества мусора, съедающего ресурсы атакуемого сервера.

Чтобы более детально разобраться в DoS-атаках, рассмотрим их наиболее известные разновидности. Выделяют пять наиболее популярных:

– TCP SYN Flood;

– TCP flood;

– Ping of Death;

– ICMP flood;

– UDP flood.

TCP SYN Flood и TCP flood

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

Ниже приведен пример установки заголовка IP пакета, который можно использовать в атаке типа «SYN Flood».

Листинг

packet.ip.version=4; // Версия

packet.ip.ihl=5; // Длина заголовка

packet.ip.tos=0; // Тип сервиса

packet.ip.tot_len=h_tons(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; // Адрес назначения

TCP flood – это вид атаки, при котором потенциальной жертве отправляется множество TCP-пакетов, что приводит к связыванию системных ресурсов.

Следующие виды DoS-атак основаны на совершенно другом принципе. При помощи таких атак можно переполнить сеть или отдельно взятую мишень абсолютно бесполезными ping-пакетами. Для реализации следующих видов атаки достаточно нескольких строк кода. Итак, это атаки, основанные на протоколе ICMP:

Ping of Death и ICMP flood

Большое количество DoS-атак основывается на протоколе ICMP. Некоторые его функции могут быть полезны для создания нападений такого рода.

ICMP flood – это далеко не новый вид атаки, который, тем не менее, не теряет популярности. Здесь используется ping. Ping изначально задумывался для проверки качества соединения с удаленным компьютером. Принцип работы следующий: программа отсылает некое сообщение, на которое удаленный компьютер автоматически отвечает. Вроде бы все нормально. Однако при атаке используются большие (64 кБ), сильно фрагментированные ICMP-пакеты. При получении таких пакетов удаленная машина зависает.

Ping of Death основывается на ICMP flood, однако усиливает атаку за счет того, что ping-запросы пересылаются по адресу широковещательной рассылки. Используемый в пакетах запроса адрес – это адрес атакуемого сервера. Получившие такие «посылки смерти» системы отвечают на них и забивают жертву. Это очень серьезный вид атаки, который, правда, требует длительной подготовки. Требуется много «зомби», необходимо собрать достаточное количество информации о жертве и посредниках.

UDP flood

Это наиболее опасный вид атаки. UDP-сервис одной машины генерирует последовательность символов для каждого получаемого системой пакета. Делается это в целях тестирования. Далее связывается с echo-сервисом другой машины, которая повторяет эти символы. В результате, передается большое количество UDP-пакетов с подделанным IP источника. Основная проблема для защиты состоит в том, что протокол UDP не устанавливает соединения и нет никаких индикаторов состояния, чтобы помочь межсетевой защите выявить нападение. Чтобы с большей долей вероятности избежать такой атаки, нужно удалить все ненужные UDP-сервисы, а остальным сервисам использовать механизм прокси-сервера.

Самые мощные DoS/DDoS-атаки

Теперь ты знаешь, что собой представляет атака на отказ в обслуживании. Пришло время составить небольшой хит-парад DoS/DDoS-атак.

1) Пожалуй, самой нашумевшей атакой из разряда DoS стала атака на корневые DNS-сервера, произошедшая в ноябре 2002 года. Тогда распределенной атаке подверглись все 13 DNS-серверов, семь из которых вышли из строя. Только высокий уровень избыточности в структуре интернета позволил избежать задержек при обращении к ресурсам.

2) Атака на сайт SCO, совершенная при помощи вируса MyDoom и всех его подцепивших. 22 августа 2003 года сайт компании SCO перестал отвечать на запросы пользователей. Атака продолжалась несколько дней и прекратилась только 25 августа. Поскольку вирус MyDoom имел очень широкое распространение, то атака получилась мощнейшей. Вторая редакция вируса MyDoom.B, созданная для атаки на сайт Microsoft, не имела такого «успеха» у пользователей.

3) Серверы Osirusoft крупнейшего хранилища IP-адресов, замеченных в спаме, были отключены после большого количества распределенных атак на отказ в обслуживании. Данная служба занималась ведением динамического списка IP-адресов, замеченных в спаме.

Атаки на отказ в обслуживании, несомненно, большое зло на просторах интернета. И если отдельно взятую пользовательскую машину можно защитить с помощью фаервола, то для серверов стопроцентной защиты нет и в скором времени не предвидится. Так что с DoS/DDoS-атаками сложилась довольно грустная (или веселая? :)) ситуация. Многие хостеры при обнаружении атаки просто выключают сервера. Это о чем-то говорит ;).

Главной особенностью DDoS-атак является то, что для них не существует сервера, который нельзя «завалить».