2014-02-12
393
С локальными D.o.S.-атаками разобрались. Теперь перейдём к атакам удалённым, основная задача всё та же – вывести машину из строя на какой-то период времени, когда доступ к машине есть только удалённый. Воздействовать остаётся только на те демоны/сервисы, которые «вывешены» для доступа. Такого вида атаки можно условно разделить на два типа – атака посредством большого количества запросов и атака, реализующая дыру в программном обеспечении.
Для реализации первой атаки не требуется практически никаких особенных знаний, только большая пропускная способность линии, по которой происходит доступ к данной сети. Суть наиболее распространённой в этом виде атак заключается в применении принципов реализации TCP/IP- протокола. Здесь для реализации атаки интересна начальная стадия установки соединения между двумя машинами.
Для лучшего понимания рассмотрим всё это на конкретном примере - обращение к почтовому сервису клиента (client) на сервер (victim). Естественно, что, для того чтобы можно было воспользоваться услугами какого-либо сервиса/демона, необходимо, чтобы была готовность обслуживать – то есть необходимо, чтобы программа прослушивала какой-либо порт на наличие «желающих подключиться». Когда таковые находятся, происходит следующее:
Клиент создаёт определённые TCP-пакеты, из которых заголовок первого всегда должен быть с установленным битом SYN и без бита ACK. В последующих пакетах всё ровно наоборот. Итак, далее сервер отвечает (если отвечает) на первый пакет клиента пакетом с установленным битом ACK – ответом на получение пакета и своим SYN-запросом синхронизации. При получении этого пакета от сервера, содержащего подтверждение и запрос, клиент передает собственное подтверждающее сообщение. Только теперь соединение считается открытым; до последнего момента это было полуоткрытое соединение.
В описываемой атаке используется именно эта первая стадия. На машине атакующего создаётся большое количество пакетов с установленным SYN-битом и посылается на сервер. В результате почтовый демон/сервис будет какое-то время занят только обработкой поступающих пакетов. Далее результат в основном зависит от настроек сервера и других вещей. В том случае если пакеты посылались от «лица» одной существующей в сети машины, то почтовик разберётся достаточно быстро, так как «подставленная» машина уже на третьем этапе вышеописанной цепочки заявит, что она «знать не знает» ни о каких таких запросах, и соединение настороне сервера будет обнулено. В том же случае если сообщения будут посылаться от «лица» несуществующей в сети машины, то серверу придётся ждать какое-то время никогда не придущего ответа на свой запрос. Таким образом, ресурсы будут заняты более длинное время.
Наибольшей «популярностью» пользуются программы, которые сами генерируют адреса «подставных» машин и посылают запросы как бы от них. Результат – выведение атакуемой машины на более длительный промежуток времени. В это время с victim возможны два варианта: в том случае если администратор поставил ограничения на количество возможных запусков программы, то ничего смертельного для системы не случится, случится только то, что так называемые законные пользователи не смогут воспользоваться услугами почтового сервера (вплоть до того момента, пока не будут обработаны все запросы, посылаемые с client на victim). В том случае если администратор по доброте душевной или по каким другим причинам такого ограничения не поставил, то всё будет прозаичнее – так как ресурсы машины какое-то время останутся «захваченными», то сводного места для действий у системы будет оставаться всё меньше. В конечном итоге может произойти полное исчерпание ресурсов системы, которое приведёт к тому, что запросы будут обрабатываться всё медленнее и медленнее. Все операции могут быть приостановлены, пока не будут обработаны все поступившие запросы. Такая ситуация, кстати, не будет вечной. В конечном итоге машина может уже игнорировать поступающие TCP-пакеты. Одним из неплохих методов отслеживания состояния системы может служить её пингование. Только для получения относительно точного результата необходимо производить это либо с другой машины, чтобы загруженность канала машины атакующего не сказывалась на результате, либо следить за тем, чтобы загруженность канала не сильно влияла на время получения ответа от системы. Далее может существовать два пути – либо надеемся на создание непредусмотренной ситуации и, соответственно, на крах системы, либо ждём пока система обработает всё, что ей выдали.
Второй тип удалённых D.o.S.-атак реализуется благодаря ошибкам в программном обеспечении. Уровень реализации можно поделить на два: уровень конкретной программы и уровень операционной системы.
На уровне конкретной программы обычно эксплуатируются ошибки при программировании. Наиболее популярными из них на данный момент являются ошибки переполнения буфера (buffer overflow). Механизм действия достаточно прост, для большей наглядности рассмотрим его на конкретном примере. Пусть существует некоторая программа, которая прослушивает, скажем, порт 2101, и в задачи которой входит ожидание какой-то строки, которая при получении отсылается, скажем, на root@localhost (суперпользователю на локальной машине). Программа вроде полезная, но проблема у ней следующая: под буфер, в который помещается получаемая строка, отведено всего 32 768 бит. Скажем, какой-то программист, просматривая эту программу, обнаружил эту ошибку. Дальнейшая логика действий проста – ей посылается 32 768 плюс ещё сколько-то бит. В программе такой поворот событий не предусмотрен, а потому она аварийно завершается. При этом происходит то самое переполнение буфера, и появляется возможность немного поиграться с машиной, на которой запущена эта «дырявая» программа. Обычно желаемым действием является вызов командного интерпретатора. Привилегии, с которыми этот интерпретатор будет запущен, напрямую зависят от того, с какими привилегиями «бегала» наша испытуемая. Вот, собственно, и вся история. Впрочем, это всё так легко только на словах, так как зачастую необходимо возиться с регистрами процессора. Так как сейчас мы рассматриваем только удалённую атаку на отказ в обслуживании, то достаточно будет сказать, что, для того чтобы просто «свалить» программу, достаточно ей просто послать, скажем, 32 770 бит. А вот это уже можно сделать, не особо копаясь в процессоре, немножко модифицировав программку char_echo, и связав её с “nc” (net cat):
Листинг программы Char_echo.II.c:
#include <stdio.h>
main ()
{
int i; /*Объявляем переменную…*/
for (i=0; i<=33000; i++) /*Запускаем
цикл на 33000 "заходов"*/
printf ("X"); /*И печатаем символ 'X'*/
}
Листинг go.sh:
#!/bin/sh
./echo_char | nc victim 2101
Всё, что называется весьма прозаично, не требует особых мудрствований в программировании. Потом можно проверить работоспособность сервера, просто подключившись напрямую к порту. Если соединения не будет, то это значит, что демон/сервис на какое-то время оказался в небытии.
Это что касаемо атак на уровне программ; на уровне операционной системы всё немножко интереснее. Задача заключается в том, чтобы либо ядро, либо какой-нибудь серьёзный модуль ядра не смог обработать ситуацию и привёл либо к “kernel panic” (панике ядра – *nix системы), либо к “The blue screen of death” (синему экрану смерти – соответственно Windows-системы). Итог – автоматическая перезагрузка, полное зависание системы, приостановка работы, недоступность сети – что называется, на выбор. В общем и целом опять таки законные пользователи не могут воспользоваться услугами сервера какое-то время. Зачастую такие атаки реализуются на ошибке в обработке протокола в общем и пакетов в частности. Самый банальный и немалоизвестный пример – это здравствующая и поныне программа WinNuke. Программ, подобных этой, немало, да и существуют они не только для излюбленной народом ОС Windows. В список уязвимых попадают и такие операционные системы как Linux и OpenBSD.
Итак, относительно вывода системы из строя удалённо – всё. Теперь стоит рассказать ещё немного про приём, который может оказаться полезным в сочетании с чем-нибудь другим. Речь идёт об описанной ранее процедуре засорения дискового пространства системы. Конечной целью может являться невозможность системы протоколировать действия, которые с ней производятся. Можно также ориентироваться не на систему, а на человека – посылая большое количество фальшивых запросов, получим долгую обработку или даже игнорирование происходящих событий, имеющих малое отношение к действительности. Оба варианта требуют большой пропускной способности канала атакующего. Путей для реализации «плана максимум» относительно немало: любой сервис, к которому можно получить доступ, является потенциальной мишенью. Например, это может быть достаточно широко распространённый на многих машинах веб-сервер, ведь каждое обращение протоколируется, и потому можно, например, через анонимный прокси-сервер посылать уйму запросов. Лучше всего это делать через разные прокси-серверы, для того чтобы было сложнее вычислить. В том случае если приблизительно известно дисковое пространство, отведённое под систему (например, при наличии локального доступа свободное пространство узнаётся очень легко), то узнаётся, какой веб-сервер работает на атакуемой системе, приблизительно высчитывается пространство, которое тратится после каждой записи, и вперёд… Также можно использовать любые средства протоколирования (например, такие вещи как tcpspy, icmplog,…). Однако же, для этого необходим мощный канал связи.
Теперь: как с этим бороться. Относительно первой описанной атаки, SYN flood, однозначных методов борьбы нет, особенно если «подставляется» не одна машина, а целая серия. Полное закрытие доступа может отрезать законных пользователей от машины (иногда, кстати, может преследоваться именно эта цель, ведь каждый потенциальный покупатель, который не смог обратиться в нужное время к интернет-магазину может уйти к конкуренту, и тем самым атакуемый магазин будет терять прибыль), но и смотреть, как некто пытается вывести машину из строя, – не самое лучшее занятие. В общем, это каждый должен решать для себя. Единственное, что можно сказать точно, так это то, что лучше ограничивать программы в ресурсах, пусть и очень большой цифрой, но всё же ограничивать. Выяснение IP-адреса в большинстве случаев будет невозможно, и достать злоумышленника будет очень сложно. Разработки в защите от подобного рода атак ведутся, но распространения практически не имеют.
Борьба с атаками второго рода сводится к регулярному обновлению программного обеспечения, дабы были исправлены обнаруженные ошибки в системе и/или программе.
И относительно последнего трюка – здесь совет всё тот же, что и в защите от локальных D.o.S.-атак, и небольшое «сетевое» дополнение – не надо вешать на свою машину слишком много следящих средств, и неплохо бы позаботиться о том, чтобы их журналы располагались в независимых от системы местах.
Итак, с атаками на отказ в обслуживании в общем и целом разобрались, теперь разберёмся с атаками на получение прав суперпользователя на атакуемой машине.
