Remote D.o.S. attack

С локальными D.o.S.-атаками разобрались. Теперь перейдём к атакам удалённым, основная задача всё та же – вывести машину из строя на какой-то период времени, когда доступ к машине есть только удалённый. Воздействовать остаётся только на те демоны/сервисы, которые «вывешены» для доступа. Такого вида атаки можно условно разделить на два типа – атака посредством большого количества запросов и атака, реализующая дыру в программном обеспечении.

Для реализации первой атаки не требуется практически никаких особенных знаний, только большая пропускная способность линии, по которой происходит доступ к данной сети. Суть наиболее распространённой в этом виде атак заключается в применении принципов реализации TCP/IP-протокола. Здесь для реализации атаки интересна начальная стадия установки соединения между двумя машинами.

Для лучшего понимания рассмотрим всё это на конкретном примере – обращение к почтовому сервису клиента (client) на сервер (victim). Естественно, что, для того чтобы можно было воспользоваться услугами какого-либо сервиса/демона, необходимо, чтобы была готовность обслуживать – то есть необходимо, чтобы программа прослушивала какой-либо порт на наличие «желающих подключиться». Когда таковые находятся, происходит следующее:

Клиент создаёт определённые TCP-пакеты, из которых заголовок первого всегда должен быть с установленным битом SYN и без бита ACK. В последующих пакетах всё ровно наоборот. Итак, далее сервер отвечает (если отвечает) на первый пакет клиента пакетом с установленным битом ACK – ответом на получение пакета и своим SYN-запросом синхронизации. При получении этого пакета от сервера, содержащего подтверждение и запрос, клиент передает собственное подтверждающее сообщение. Только теперь соединение считается открытым; до последнего момента это было полуоткрытое соединение.

В описываемой атаке используется именно эта первая стадия. На машине атакующего создаётся большое количество пакетов с установленным SYN-битом и посылается на сервер. В результате почтовый демон/сервис будет какое-то время занят только обработкой поступающих пакетов. Далее результат в основном зависит от настроек сервера и других вещей. В том случае если пакеты посылались от «лица» одной существующей в сети машины, то почтовик разберётся достаточно быстро, так как «подставленная» машина уже на третьем этапе вышеописанной цепочки заявит, что она «знать не знает» ни о каких таких запросах, и соединение на стороне сервера будет обнулено. В том же случае если сообщения будут посылаться от «лица» несуществующей в сети машины, то серверу придётся ждать какое-то время никогда не придущего ответа на свой запрос. Таким образом, ресурсы будут заняты более длинное время.

Наибольшей «популярностью» пользуются программы, которые сами генерируют адреса «подставных» машин и посылают запросы как бы от них. Результат – выведение атакуемой машины на более длительный промежуток времени. В это время с victim возможны два варианта: в том случае если администратор поставил ограничения на количество возможных запусков программы, то ничего смертельного для системы не случится, случится только то, что так называемые законные пользователи не смогут воспользоваться услугами почтового сервера (вплоть до того момента, пока не будут обработаны все запросы, посылаемые с client на victim). В том случае если администратор по доброте душевной или по каким другим причинам такого ограничения не поставил, то всё будет прозаичнее – так как ресурсы машины какое-то время останутся «захваченными», то сводного места для действий у системы будет оставаться всё меньше. В конечном итоге может произойти полное исчерпание ресурсов системы, которое приведёт к тому, что запросы будут обрабатываться всё медленнее и медленнее. Все операции могут быть приостановлены, пока не будут обработаны все поступившие запросы. Такая ситуация, кстати, не будет вечной. В конечном итоге машина может уже игнорировать поступающие TCP-пакеты. Одним из неплохих методов отслеживания состояния системы может служить её пингование. Только для получения относительно точного результата необходимо производить это либо с другой машины, чтобы загруженность канала машины атакующего не сказывалась на результате, либо следить за тем, чтобы загруженность канала не сильно влияла на время получения ответа от системы. Далее может существовать два пути – либо надеемся на создание непредусмотренной ситуации и, соответственно, на крах системы, либо ждём пока система обработает всё, что ей выдали.