- •Воронеж 2008
- •Воронеж 2008
- •Введение
- •1 Подбор пароля
- •1.1 Общие понятия парольной защиты
- •1.1.1 Парольная система
- •1.1.2 Методы подбора паролей
- •1.1.3 Методы количественной оценки стойкости паролей
- •1.2 Парольная защита операционных систем
- •1.2.1 Подбор паролей в ос Windows
- •1.2.1.1 База данных учетных записей пользователей
- •1.2.1.2 Хранение паролей пользователей
- •1.2.1.3 Использование пароля
- •1.2.1.4 Возможные атаки на базу данных sam
- •1.2.2 Подбор паролей в ос unix
- •1.3 Классификация и принцип работы программного обеспечения для подбора паролей
- •1.3.1 Подбор паролей в oc Windows
- •1.3.2 Подбор паролей в oc unix
- •1.3.3 Подбор паролей в архивах zip, rar и arj
- •1.3.4 Подбор паролей документов ms Office
- •1.3.5 Подбор паролей pdf документов
- •1.4 Противодействие подбору паролей
- •1.4.1 Требования к паролю
- •1.4.2 Правила назначения/изменения паролей
- •1.4.3 Требования к генерации паролей
- •1.4.4 Хранение пароля пользователем
- •1.4.5 Хранение паролей компьютерной системой
- •1.4.6 Противодействие попыткам подбора паролей
- •1.4.7 Защита Windows nt и Unix от подбора паролей
- •2.1.2 Протокол tcp
- •2.1.2.1 Функции протокола tcp
- •2.1.2.2 Базовая передача данных
- •2.1.2.3 Разделение каналов
- •2.1.2.4 Управление соединениями
- •2.1.2.5 Заголовок тср-сегмента
- •2.1.2.6 Состояния соединения
- •2.2 Основные методы, применяемые при сканировании портов
- •2.2.1 Методы сканирования tcp-портов
- •2.2.1.1 Методы открытого сканирования
- •2.2.1.1.1 Метод icmp-сканирования
- •2.2.1.1.2 Сканирование tcp-портов функцией connect()
- •2.2.1.1.3 Сканирование tcp-портов флагом syn
- •2.2.1.1.4 Сканирование tcp-портов флагом fin
- •2.2.1.1.5 Сканирование с использованием ip-фрагментации
- •2.2.1.1.6 Сканирование tcp-портов методом reverse-ident (обратной идентификации)
- •2.2.1.1.7 Сканирование Xmas
- •2.2.1.1.8 Null сканирование
- •2.2.1.2 Методы "невидимого" удаленного сканирования
- •2.2.1.2.1 Скрытая атака по ftp
- •2.2.1.2.2 Сканирование через proxy-сервер
- •2.2.1.2.3 Скрытное сканирование портов через системы с уязвимой генерацией ip id
- •2.2.1.2.3.1 Исторические предпосылки
- •2.2.1.2.3.2 Описание базового метода ip id сканирования
- •2.2.1.2.3.3 Исследование правил и обход брандмауэра при сканировании
- •2.2.1.2.3.4 Сканирование машин с приватными адресами
- •2.2.1.2.3.5 Использование ip id при сканирование udp сервисов за брандмауэром
- •2.2.2 Методы сканирования udp-портов
- •2.2.2.1 Сканирование udp-портов проверкой icmp-сообщения «Порт недостижим»
- •2.2.2.2 Сканирование udp-портов с использованием функций recvfrom() и write()
- •2.3.1 Сканирование портов в ос семейства Windows
- •2.3.2 Сканирование портов в ос семейства Unix
- •2.4 Защита от сканирования портов
- •3 Анализ сетевого трафика
- •3.1 Анализ сетевого трафика сети Internet
- •3.1.1 Ложные arp-ответы
- •3.1.2 Навязывание ложного маршрутизатора
- •3.1.3 Атака при конфигурировании хоста
- •3.1.4 Атака на протоколы маршрутизации
- •3.2 Протокол telnet
- •3.2.1 Протокол ftp
- •3.2.3 Программы анализаторы сетевого трафика (сниффиры)
- •3.2.4 Принцип работы сниффира
- •3.3 Методы противодействия сниффирам
- •3.3.1 Протокол ssl
- •3.3.2 Протокол skip
- •3.3.3 Устройство обеспечения безопасности локальной сети skipBridge
- •4 Внедрение ложного доверенного объекта
- •4.1 Особенности атаки «Внедрение ложного доверенного объекта»
- •4.2 Внедрение ложного объекта путем использования недостатков алгоритмов удаленного поиска
- •4.2.1.1 Протокол arp и алгоритм его работы
- •4.2.1.2 Техника выполнения arp-spoofing
- •4.2.1.3 Методы обнаружения
- •4.2.1.4 Методы противодействия
- •4.2.2.1 Принцип работы Domain Name System
- •4.2.2.2 Внедрение dns-сервера путем перехвата dns-запроса
- •4.2.2.3 «Шторм» ложных dns ответов на атакуемый хост
- •4.2.2.4 Перехват dns-запроса или создание направленного «шторма» ложных dns-ответов непосредственно на атакуемый dns-сервер
- •4.2.2.5 Обнаружение и защита от внедрения ложного dns-сервера
- •4.3.1.2 Внедрение ложного доверенного объекта путем навязывания ложного маршрута с помощью протокола icmp
- •4.3.1.3 Обнаружение и методы противодействия
- •5 Отказ в обслуживании
- •5.1 Модель DoS атаки
- •5.1.1 Отказ в обслуживании (DoS)
- •5.1.2 Распределенный отказ в обслуживании (dDoS)
- •5.2.1.1 Описание утилиты для реализации icmp – флуда и атаки Smurf
- •5.2.1.2 Реализация атаки icmp-flooding, на основе отправки icmp-пакетов
- •5.2.1.3 Реализация атаки Smurf
- •5.2.3 Низкоскоростные dos-атаки
- •5.2.3.1 Механизм таймаута tcp-стека
- •5.2.3.2 Моделирование и реализация атаки
- •5.2.3.2.1 Минимальная скорость DoS-атаки
- •5.2.3.3 Многопоточность и синхронизация потоков
- •5.2.3.5 Атаки в сети интернет
- •5.2.4 Syn атака
- •5.3 Анализ средств и методов сетевой защиты
- •5.3.1 Настройка tcp/ip стека
- •5.3.4 Межсетевые экраны (FireWall)
- •5.3.5 Системы обнаружения атак (ids)
- •5.3.6 Система Sink Holes
- •Заключение
- •Список информационных источников
- •394026 Воронеж, Московский просп., 14
3.1.2 Навязывание ложного маршрутизатора
Для перехвата трафика, направленного от некоторого узла А в другую сеть, злоумышленник может навязать хосту свой адрес в качестве адреса маршрутизатора, которому должны быть переданы отправляемые узлом А данные. В этом случае узел А будет направлять трафик на узел злоумышленника, который после анализа и, возможно, модификации данных, отправит их далее настоящему маршрутизатору.
Ложное сообщение ICMP Redirect
Как правило, навязывание ложного маршрутизатора выполняется с помощью фальсифицированных ICMP-сообщений Redirect, так как документ RFC-1122 требует, чтобы хосты обязательно обрабатывали такие сообщения. В подложном сообщении злоумышленник объявляет свой собственный адрес в качестве адреса маршрутизатора (рисунок 3.1).
Рисунок 3.1 - Навязывание ложного маршрутизатора с помощью ICMP Redirect
Напомним действия хоста А при получении сообщения Redirect. Хост А считает, что Redirect является реакцией на ранее отправленную датаграмму некому хосту В, причем заголовок и первые 64 бита этой датаграммы возвращаются внутри полученного сообщения. Из возвращенного заголовка хост А определяет, что он должен сделать перенаправление для датаграмм, направленных в В, и вносит в свою таблицу маршрутов частный маршрут к хосту В через маршрутизатор, указанный в сообщении Redirect. Следует обратить внимание, что все сообщения Redirect обрабатываются одинаково независимо от кода сообщения — таким образом, посылка Redirect с кодом 0 («перенаправление для сети получателя») не вызовет изменения маршрута в сеть, в которой находится получатель, а приведет к установке частного маршрута к хосту В, как и в случае сообщения с кодом 1.
Сообщение Redirect должно быть отправлено маршрутизатором, который в таблице маршрутов хоста А является следующим маршрутизатором на пути в В, при этом хост В не должен находиться в той же IP-сети, что и А, а новый объявленный маршрутизатор Х, наоборот, обязан находиться в одной IP-сети с хостом А.
Таким образом, для создания ложного сообщения Redirect с целью перехвата трафика между хостами А и В злоумышленник должен находиться в одной IP-сети с А и знать адрес маршрутизатора, через который А отправляет датаграммы в В. Если в сети имеется единственный шлюз, то он и является искомым маршрутизатором. Далее злоумышленник формирует IP-датаграмму, где в качестве адреса отправителя указан IP-адрес шлюза, а получателем является хост А. В датаграмму помещается сообщение Redirect, где в поле Адрес нового маршрутизатора значится IP-адрес злоумышленника, а дальше приводится заголовок произвольной датаграммы, якобы ранее направленной из А в В. Совершенно необязательно приводить там заголовок реальной датаграммы, потому что модуль IP не хранит информацию о ранее отправленных датаграммах. Получившееся сообщение отправляется адресату — хосту А, который считает, что оно прибыло от шлюза и меняет свою таблицу маршрутов. Новый маршрут к хосту В будет действителен в течение нескольких минут, поэтому, чтобы поддерживать его постоянно, злоумышленник должен посылать сфабрикованные сообщения периодически.
Отметим, что трафик из В в А будет по-прежнему направляться маршрутизатором непосредственно хосту А, минуя злоумышленника, потому что маршрутизатор и хост А находятся в одной сети, следовательно, маршрутизатор в принципе не может использовать никаких промежуточных узлов для достижения хоста А.
Несмотря на такой «половинчатый» перехват, злоумышленник может просматривать и модифицировать данные, направляемые из А в В, а если он находится в одном сегменте с хостом А или маршрутизатором, то и наблюдать за ответами узла В, направляемыми в А. Более того, злоумышленник может вообще не пересылать датаграммы в узел В, а отвечать на них сам, фабрикуя датаграммы от имени узла В.
Для устранения возможности описываемой атаки необходимо отключить на хосте обработку сообщений Redirect. Несмотря на то, что это действие противоречит требованиям к хостам, установленным в документе RFC-1122, оно выглядит совершенно разумным, особенно для хостов в сетях с единственным шлюзом, однако не все операционные системы могут поддерживать такое отключение.
Для пользователя атакуемого узла не составит особого труда раскрыть замысел злоумышленника: полученное сообщение Redirect отобразится в виде неожиданно появившейся строки в таблице маршрутов, направляющей данные для хоста В через узел Х2. Кроме того, программа traceroute скорее всего покажет дополнительный промежуточный узел на пути к В. К сожалению пользователи обычно не заглядывают в таблицу маршрутов и не запускают traceroute, если поведение сетевых программ не вызывает у них подозрений, поэтому злоумышленник имеет хорошие шансы остаться незамеченным.
2Узел Х может и не быть узлом злоумышленника. Затратив определенные усилия на программирование, тот может создать узел-фантом, присвоив ему свободный IP-адрес Х и свободный MAC-адрес. Фабрикуя ARP-ответы от имени узла Х, злоумышленник обеспечит доставку кадров, предназначенных этому узлу, в свой сегмент Ethernet, откуда он может их получить, настроив свою сетевую карты на вымышленный MAC-адрес Х, или извлечь с помощью прослушивания. Использование такой схемы не может скрыть наличия Redirect-атаки, но весьма затрудняет обнаружение злоумышленника.