
- •Воронеж 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
2.2.1.1.4 Сканирование tcp-портов флагом fin
Лишь немногие серверы способны отследить попытку SYN-сканирования их портов. Так, некоторые брандмауэры и пакетные фильтры «ожидают» поддельные SYN-пакеты на закрытые порты защищенного ими сервера, и специальное программное обеспечение типа synlogger или courtney распознает попытку SYN-сканирования. Если сервер обрывает соединение после опроса нескольких портов, используется FIN-сканирование [63].
В этом методе используются FIN-пакеты, используемые в процедуре закрытия соединения. Пакет предусматривает установку в TCP-сообщении флага FIN. Процедура закрытия соединения следующая.
Рисунок 2.13 - Хост передает серверу данные
В исходном состоянии хост передает серверу данные (рисунок 2.13).
Рисунок 2.14 - Первый этап закрытия соединения
Первый этап (рисунок 2.14): по окончании передачи данных хост посылает серверу FIN-пакет с указанием собственного ISS, ACK и установленными флагами FIN и ACK [7].
Риснок 2.15 - Второй этап закрытия соединения
Второй этап (рисунок 2.15): сервер, приняв FIN-пакет, посылает хосту подтверждение о приеме.
Рисунок 2.16 - Третий этап закрытия соединения
Третий этап (рисунок 2.16): сервер посылает хосту FIN-пакет с указанием собственных данных.
Рисунок 2.17 - Четвертый этап закрытия соединения
Четвертый этап (рисунок 2.17): хост передает серверу подтверждение о приеме FIN-пакета. После этого соединение между сервером и хостом будет закрыто.
FIN-пакеты способны обойти средства защиты сети. Идея заключается в том, что на прибывший на закрытый порт FIN-пакет сервер должен ответить RST-пакетом (TCP-пакет с установленным в нем флагом RST). FIN-пакеты на открытые порты игнорируются сервером [41].
ОС Windows 95/98/NT имеют средства противодействия к такому сканированию, однако большинство ОС являются уязвимыми. Таким образом, совместно используя SYN и FIN-сканирование можно обойти средства защиты сервера и просканировать его порты.
2.2.1.1.5 Сканирование с использованием ip-фрагментации
Данный метод представляет собой комбинацию SYN и FIN-сканирования с небольшим усовершенствованием. Он основан на использовании функциональной особенности протокола IP, называемой фрагментацией.
Фрагментация – это процесс разделения большого пакета данных на несколько частей перед непосредственной передачей его в сеть для получения размера фрагмента, соответствующего стандарту используемой сети (т.н. параметр MTU – Maximum Transmission Unit, максимальный размер блока). Фрагментация пакета на стороне источника и его сборка на стороне приемника осуществляется автоматически. Каждая фрагментированная часть исходного пакета имеет одинаковый формат. Этот метод позволяет маршрутизировать фрагменты независимо друг от друга.
На рисунок 2.18 представлен пример исходного заголовка дейтаграммы протокола IP с приведением конкретных значений полей.
Общая длина фрагментируемой дейтаграммы составляет 472 байта (20 байт заголовок и 452 байта данных). Максимальное значение MTU примем равным 280 байт. На рисунок 2.19 приведены значения полей заголовков двух полученных в результате фрагментации дейтаграмм. Первый фрагмент возникает после фрагментации исходной дейтаграммы по границе 256 байт.
Поля «Идентификатор», «Флаги» и «Смещение фрагмента» предназначены для управления процессами фрагментации и сборки дейтаграммы.
«Идентификатор» используется для распознавания дейтаграмм, образованных процессом фрагментации. Все фрагменты исходной дейтаграммы должны иметь одинаковое значение этого поля [61].
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
|
|||
|
|
|||||||||||||||||||||||||||||||||
Номер версии=4 |
Длина заголовка=5 |
Тип сервиса |
Общая длина = 472 |
|
||||||||||||||||||||||||||||||
Идентификатор = 111 |
Флаги=0 |
Смещение фрагмента = 0 |
|
|||||||||||||||||||||||||||||||
Время жизни = 123 |
Протокол = 6 |
Контрольная сумма заголовка |
|
|||||||||||||||||||||||||||||||
Адрес отправителя |
|
|||||||||||||||||||||||||||||||||
Адрес получателя |
|
|||||||||||||||||||||||||||||||||
Данные |
|
Рисунок 2.18 - Формат IP-заголовка нефрагментированного пакета
Поле «Флаги» указывает на возможность фрагментации. Нулевое состояние первого бита разрешает выполнять фрагментацию, единичное – запрещает. Второй бит определяет последний пакет дейтаграммы.
Поле «Смещение фрагмента» используется для указания места данного фрагмента в дейтаграмме. Смещение измеряется группами по 8 байт (т.е. в данном случае смещение составляет 32 группы по 8 байт, или 256 байт). Первый фрагмент всегда имеет нулевое смещение.
Таким образом, TCP-пакет (SYN или FIN-пакет, имеющий размер порядка 24 байт) разбивается на стороне хоста на пару IP-фрагментов меньшего размера, и эта пара IP-фрагментов отправляется серверу. На стороне сервера IP-фрагменты «собираются» в один TCP-пакет и производится его обработка (те же действия, как и при SYN или FIN-сканировании).
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
|
|||||||||||||||||||||||||||||||
Номер версии=4 |
Длина заголовка=5 |
Тип сервиса |
Общая длина = 256 |
||||||||||||||||||||||||||||
Идентификатор = 111 |
Флаги=1 |
Смещение фрагмента = 0 |
|||||||||||||||||||||||||||||
Время жизни = 119 |
Протокол = 6 |
Контрольная сумма заголовка |
|||||||||||||||||||||||||||||
Адрес отправителя |
|||||||||||||||||||||||||||||||
Адрес получателя |
|||||||||||||||||||||||||||||||
Данные |
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
Номер версии=4 |
Длина заголовка=5 |
Тип сервиса |
Общая длина = 216 |
||||||||||||||||||||||||||||
Идентификатор = 111 |
Флаги=3 |
Смещение фрагмента = 32 |
|||||||||||||||||||||||||||||
Время жизни = 119 |
Протокол = 6 |
Контрольная сумма заголовка |
|||||||||||||||||||||||||||||
Адрес отправителя |
|||||||||||||||||||||||||||||||
Адрес получателя |
|||||||||||||||||||||||||||||||
Данные |
Рисунок 2.19 - Пример фрагментации дейтаграммы
В этом случае фрагментация позволяет уменьшить вероятность обнаружения сканирования фильтрами пакетов и другим подобным оборудованием. Однако, следует учитывать, что некоторые программы имеют обыкновение «зависать» при попытке обработки такого маленького IP-фрагмента [7].