 | ||
 |
 |
 |
 |
 |
 |
 |
 |
 |
Детектирование сетевых атак с неизвестной сигнатуройГуркин Ю.Н., Рыжков А.А., Семенов Ю.А., Шер А.С. (ИТЭФ), Овсянников А.П., Шабанов Б.М. (МСЦ РАН)Если сигнатура атаки известна, она может быть легко детектирована любой системой регистрации вторжений (IDS, например, программой SNORT). Но атаки, сигнатура которых известна, как правило, уже не опасны, так как уязвимости, которые ею используются уже устранены, если, разумеется, программы своевременно обновлены. Для детектирования атак с неизвестной сигнатурой можно использовать журнальные файлы и любые отклонения параметров работы сервера или сети от среднестатистической нормы. При анализе журнальных файлов следует принимать во внимание не только их содержимое, но и темп их роста. Список журнальных файлов зависит от используемой операционной системы и от перечня загруженных приложений. В этот список могут быть включены: bash_history (по числу аккоунтов), access, secure и т.д. В случае успешного вторжения хакер может фальсифицировать журнальные файлы или даже стереть их, по этой причине система оповещения должна работать оперативно. Анализируя журнальные файлы и текущие параметры работы сервера или субсети, следует учитывать, что распределение по некоторым параметрам может иметь большую или даже бесконечную дисперсию. В этом случае традиционные статистические методы могут оказаться неприменимы. Такая ситуация достаточно типична для самых разных видов атак. Учитывая это, надо признать крайне актуальным выработку способов распознавания атак по совокупности признаков. Нами на протяжении более пяти лет велись разработки систем безопасности, в частности скрытной системы дублирования журнальных файлов, исключающей возможность для хакера “заметания следов вторжения” путем искажения записей в журнальных файлов. Важность такой системы подтвердило вторжение на одну из наших машин путем подбора пароля (взлом системы SSH) в 2006 году, когда хакер частично успел стереть некоторые из журнальных файлов. Сейчас такая система разработана и даже, если хакер сотрет все журнальные файлы, последовательность его действий может быть восстановлена по копиям, хранящимся в недоступном для хакера месте. Эффективность мониторинга изменения объемов некоторых журнальных файлов для детектирования атак будут продемонстрированы на примере файлов access_log (httpd) и error_log. На рис. 1 показана временная зависимость изменения объема файлов access_log (вверху) и error_log (внизу) приложения apache. Горизонтальная ось диаграмм служит для обозначения времени в часах. Известно, что журнальные файлы, чтобы избежать беспредельного роста размеров, обычно подвергаются процедуре ротации, когда файл закрывается переименовывается и открывается пустой файл с тем же именем. Это несколько усложняет мониторинг. Понятно, что синхронный анализ роста объема журнальных файлов и их содержимого предоставляет несравненно более четкую картину атаки. На левых сторонах диаграмм приведена скорость роста файлов в байтах в минуту, на правых - абсолютные значения объемов файлов.   Рис. 1. Временная зависимость размеров файлов access_log и error_log Из диаграмм видно, что примерно в 19 часов произошел резкий скачок размеров рассматриваемых файлов. Это само по себе должно привлечь внимание. Рассмотрение содержимого файла access_log позволяет получить дополнительную информацию.  Рис. 2. Распределение имен источников по числу запросов в файле access_log Рис. 2 показывает, что максимум активности исходит из узла с именем rakhilim.ruscomnet.ru (1199500 запросов примерно за полтора часа). Это уже никак нельзя считать нормальным. Теперь рассмотрим содержимое файла error_log за тот же временной интервал. На рис. 3. представлено распределение числа ошибок по IP-адресам источников запросов.  Рис. 3. Распределение сообщений об ошибках по IP-адресам отправителя запроса На рисунке четко виден максимум, соответствующий IP-адресу 80.249.130.130. Утилита gethostbyaddr показывает, что этот адрес соответствует имени rakhilim.ruscomnet.ru. Все это крайне подозрительно, но еще не доказывает злого умысла. Но если рассмотреть причины ошибок вывод становится однозначным. Причиной ошибки в более чем 90% случаев является посылка HEAD-запросов, содержащих достаточно большое (варьируемое) число символов “/”. Проводился анализ сообщений “Don’t exist”. Очевидно, Эта атака рассчитана на блокиовку WEB-сервера (разновидность DoS-атаки). Вся последовательность операций в нашем случае выполнялась автоматически посредством скриптов, написанных на языке PERL. Время начала и конца атаки также фиксируются программно. Только отправка сообщений администратору сервис-провайдера, зоны, где работает атакер, пока не автоматизирована. Планируется создание базы данных атакеров. На рис. 4 показаны временные зависимости роста журнальных файлов secure (слева; файл демона sshd) и access_log (справа). В правой части рисунка видны два пика. Выбор отрезка времени, соответствующему первому пику, позволил вывести в текстовую часть рисунка строчку, соответствующую пользователю, проявившему эту активность. При копированиях с сайта частота обращений может достигать порядка десятков тысяч обращений за 15 минут. В левой части рисунка с машины www.ks-engo.com (221.251.188.125) проводится сканирование портов. Из текстовой части рисунка видно, что наш сайт запрещает доступ для данного IP адреса - это определяется политикой администратора сайта. В то же время, очевидно, что применение данной программы может легко запретить подобные атаки: например, после третьей попытки прощупать порты сервера можно автоматически внести данный IP адрес в запрещенные адреса (ASL). Таким образом, программа может спасти от атак сайт не очень квалифицированного администратора.  Рис. 4. Выводы
Ссылки | ||