Предисловие
Благодарности
Введение
Поле битвы

ПРОЕКТ HONEYNET
СИСТЕМА HONEYPOT
СЕТЬ HONEYNET
Назначение Honeynet
Система Honeypot в сети Honeynet
РЕЗЮМЕ

Как работает Honeynet
КОНТРОЛЬ ДАННЫХ
ЗАПИСЬ ДАННЫХ
Уровень контроля доступа
Сетевой уровень
Системный уровень
Автономный уровень
СОЦИОТЕХНИКА
Риск
РЕЗЮМЕ

Создание сети Honeynet
ОБЩАЯ АРХИТЕКТУРА
КОНТРОЛЬ ДАННЫХ
ЗАПИСЬ ДАННЫХ
ПОДДЕРЖАНИЕ HONEYNET И РЕАГИРОВАНИЕ НА АТАКИ
РЕЗЮМЕ

АНАЛИЗ
Анализ данных
РЕГИСТРАЦИОННЫЕ ЖУРНАЛЫ БРАНДМАУЭРА
АНАЛИЗ IDS
СИСТЕМНЫЕ ЖУРНАЛЫ
РЕЗЮМЕ

Анализ взломанной системы
НАПАДЕНИЕ
АНАЛИЗ
Взлом
ПОЛУЧЕНИЕ ДОСТУПА
ВОЗВРАЩЕНИЕ
РЕЗУЛЬТАТЫ АНАЛИЗА
РЕЗЮМЕ

Продвинутый анализ данных
ПАССИВНАЯ ДАКТИЛОСКОПИЯ
Сигнатуры
Пример ICMP
СИСТЕМНОЕ ВСКРЫТИЕ
РЕЗЮМЕ

Практика системного вскрытия
ОБРАЗЫ
ИНСТРУМЕНТЫ THE CORONER'S TOOLKIT
ВРЕМЯ MAC
УДАЛЕННЫЕ СТРУКТУРЫ INODE
ВОССТАНОВЛЕНИЕ ДАННЫХ
РЕЗЮМЕ

УГРОЗА
ТАКТИКА
ИНСТРУМЕНТЫ
Мотивы
МЕНЯЮЩИЕСЯ ТЕНДЕНЦИИ
РЕЗЮМЕ

Червяки на войне
УСТАНОВКА
ПЕРВЫЙ ЧЕРВЯК
ВТОРОЙ ЧЕРВЯК
НА СЛЕДУЮЩИЙ ДЕНЬ
РЕЗЮМЕ

Своими собственными словами
Взлом

Наша ссылка ;)



котельное оборудование москва
Эротический массаж


АНАЛИЗ

При изучении нападения начинайте с самого начала. Где взломщик приступил к своим действиям? Как только мы определимся с началом, все нападение можно будет проследить шаг за шагом, анализируя его параметры. Помните, не надо ограничивать себя целью определения одних лишь действий взломщика. Нам нужно знать, что он делал до и после нападения, в частности технические приемы, тактику и мотивы нападения.

Обычно взломщики начинают со сбора информации: прежде чем нанести удар, им нужно определить существующие слабые места. Если ваша система была вскрыта, то, как правило, хакер не впервые имеет дело с такой системой. Большинство нападений начинается со сбора информации перед началом атаки. Таким образом, именно со стадии сбора взломщиком информации мы и начнем.

Если обратиться к предупреждению, то видно, что нападение совершено на порт 53, а это означает - система подверглась атаке через DNS. Так что мы начнем просматривать заархивированные предупреждения Snort, чтобы найти предположительные информационные запросы, предшествующие DNS. И действительно, в архивах предупреждений Snort мы находим, что той же системой, из которой исходила угроза, было произведено зондирование с целью определения версии DNS.

Apr 25 02:08:07 ids snort[5875]: IDS278/named-probe-version: 63.226.81.13:4499 -> 172.16.1.107:53
Apr 25 02:08:07 ids snort[5875]: IDS278/named-probe-version: 63.226.81.13:4630 -> 172.16.1.107:53

Обратите внимание на номер ссылки на предупреждении: IDS278. При помощи этого номера можно получить более подробную информацию на Web-сайте http://www.snort.org. Этот сайт, поддерживаемый Максом Виж-ном, является великолепным источником информации, и мы часто пользуемся им при анализе данных. Вот что мы узнали об этом предупреждении.

Такое предупреждение указывает на пробник, цель которого заключается в определении версии BIND, установленной на удаленном хосте. Этот запрос, как правило, считается зондом, высылаемым перед нападением, направленным на намеренную перегрузку устройства. В1998 году было обнаружено буферное переполнение, которое оказывает влияние на некоторые версии BIND, домены сервера, в настоящее время поддерживаемые Internet Software Consortium. Эти ранние версии программного обеспечения BIND не смогут указать границы полученных данных при обработке ответного запроса. В память будут переписаны некоторые куски программы, и на подвергшемся нападению хосте можно будет выполнять произвольные команды.

Итак, мы убедились, что этот зонд, скорее всего, означает попытку найти системы, уязвимые для взлома на основе DNS. Обратите внимание на то, что были прозондированы только две honeypot: 172.16.1.101 и 172.16.1.107. Именно они были зарегистрированы как DNS для определенного имени домена. Скорее всего, наш взломщик запрашивал поисковую систему WHOIS и определял серверы DNS для случайных доменных имен. После того как они были вычислены, он просто зондировал эти системы в поисках уязвимой версии сервиса DNS. Кроме того, обратите внимание на дату проверки, 25 апреля, за день до начала атаки. Взломщик, скорее всего, проверил в этот день множество систем и сохранил IP-адреса всех обнаруженных уязвимых ресурсов. После этого он просмотрел результаты, определил слабые системы, в том числе нашу, а затем совершил нападение.

Теперь мы представим общую картину происходящего. Сначала взломщик прозондировал нас 25 апреля, чтобы выяснить, насколько уязвимы наши DNS перед определенного вида нападением. Как следует из объяснения Макса Вижна, взломщик определяет это путем запроса DNS-серве-ра о его версии. На следующий день мы, видимо, были атакованы в хорошо известном слабом месте защиты DNS. Но как была произведена атака и как она сработала? Более того, что и зачем делал взломщик после того, как он получил доступ? Давайте это выясним.
Copyright (ЦЕ) Addison-Wesley