КЛАССИФИКАЦИЯ DoS-АТАК

основы основ

Спецвыпуск Xakep, номер #021, стр. 021-012-2

Самый типичный (и самый тупой) пример bandwidth consumption - это банальный ping. Почему тупой? Да потому что пакеты ping-запросов и ping-ответов незначительно отличаются по размеру, и канал у атакующего и атакуемого забивается в равной степени - 3.14zDoS может произойти обоим :). Фишка катит, если у атакующего канал шире, чем у атакуемого, но это туфта, так как атакуемыми чаще всего оказываются сервера (с широченными каналами), а не левые диалапные юзеры. Поэтому "не тупыми" bandwidth consumption-атаками считаются такие, при которых атакуемый комп вынужден отсылать значительно больше информации, чем атакующий. Простой пример - самый обычный HTTP-запрос на страничку. Клиент (хацкер) шлет серваку малюсенький запрос, типа "GET /index.html", а сервер ему шлет эту самую index.html, размер которой может оказаться в сотни раз больше, чем размер запроса. Дальше вступает в силу элементарная математика: хацкер висит, допустим, на мегабайтном канале, а сервак - на десятимегабайтном; разница - пропускная способность канала сервера больше в десять раз; следовательно, если ответ будет по размеру превосходить запрос, скажем, в пятнадцать раз, у хакера будет хороший шанс за3.14zDoS`ить вражеский сервак. Все очень просто :). Но тут есть еще одна заковырка: а как же index.html, которая отправляется хацкеру от сервера с каждым новым запросом? Она же тоже забивает атакующему канал... Да уж, еще как забивает - от такого трафика хакерюга со своим хиленьким каналом уйдет в даун, когда сервер еще и почесаться не успеет :). Решение, как всегда, по-хацкерски простое: подменять source IP (айпишник отправителя) в пакетах запросов на какой-нибудь другой, чтоб проклятые index.html уходили на этот самый другой адрес, не забивая канал хакера. При этом желательно, чтоб source IP в каждом запросе был разный, а то нехилая нагрузка пойдет на машину с этим адресом, и может спохватиться админ сети, которой она принадлежит, - лишний шум, лишняя возня - ничего хорошего. А так на разные IP`шки приходит какая-то хтмлка - ну, подумаешь, ошибка маршрутизации...

Если ты хорошенько пошевелишь мозгами, то сам догадаешься, как можно кого-нибудь задосить еще одним способом: находится огромная сеть (с кучей машин) на широченном канале, и ей шлются запросы, source IP в которых заменен на IP жертвы. Вся эта байда начинает слать на несчастный IP`шник ответы, думая, что запросы пришли именно от него, забивая по самые уши канал атакуемому и устраивая бедняге мега3.14zDoS :). Такая фишка называется усилением (или умножением) DoS-атаки.

Недостаток ресурсов (resource starvation)

Атаки, направленные на захват критических системных ресурсов: процессорное время, место на харде, память и т.д. Resource starvation часто очень похож на bandwidth consumption: взломщик опять-таки отсылает кучу запросов на сервер, после чего тому наступает полный 3.14zDoS :). Но на этот раз пакеты не забивают канал хоста-жертвы, а занимают, скажем, все его процессорное время. Ведь на обработку каждого пакета сервак затрачивает некоторое процессорное усилие. Остается только выбрать такие пакеты, на которые процессорного времени тратится достаточно много, и вперед - бомбить ими тачку! Канал-то может оказаться достаточно широким - с ним все будет ок, а вот проц просто захлебнется, обрабатывая всю эту бомбежку. Результат - все остальные процессы висят, пользователи не могут получить доступа к сервисам. Еще один популярный пример - это когда хард забивается логами. Еcли админ - ламо, он может криво отконфигурировать систему логирования на своем серваке, не поставив ей лимит. Тогда достаточно выбрать такие пакеты, которые жрут в логах больше места, и начать отсылать их на сервер пачками. Через какое-то время файлы логов разрастутся до немереных размеров, сожрут все место на харде, и машина опять окажется в "затруднительном положении". Правда, это покатит только на самых ламерских серваках - грамотные люди держат логи на отдельном от системного харде. Также resource starvation актуален, если у хакерюги уже есть какой-то (ограниченный) доступ к ресурсам машины (например, у него есть непривилегированный аккаунт) - тут поле для действий значительно шире в том смысле, что взломщик не ограничен одними только пакетами, которые он может отсылать на удаленный сервер. Тут немаловажную роль играет, насколько грамотно построена система квотирования. Например, если на хостинге есть доступ к cgi, можно написать скрипт, который нехило жрет памяти или, опять же, ресурсов проца (ну, скажем, циклически создает какие-нибудь огромные массивы/хэшы в памяти или вычисляет какие-нибудь громоздкие математические формулы), и обратиться к нему несколько сот/тысяч/десятков тысяч раз. Если система квотирования настроена глючно, то такой скрипт очень скоро отожрет всю память (или забьет проц), а если все пучком, то процесс скрипта, достигнув поставленного ему лимита в жоре памяти, не получит доступа к мозгам до тех пор, пока не выгрузит оттуда старые данные.