- •Воронеж 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
1.4.7 Защита Windows nt и Unix от подбора паролей
Одна из главных задач системного администратора Windows NT состоит в защите от несанкционированного доступа той информации, которая хранится в базе данных SAM. С этой целью ему, прежде всего, необходимо ограничить физический доступ к компьютерам сети и прежде всего — к контроллерам доменов. Дополнительно, при наличии соответствующих программно-аппаратных средств, следует установить пароли BIOS на включение компьютеров и на изменение настроек BIOS. Затем, используя настройки BIOS, рекомендуется отключить загрузку компьютеров с гибких и компакт-дисков. А для обеспечения контроля доступа к файлам и папкам операционной системы Windows NT системный раздел жесткою диска должен иметь формат NTFS.
Каталог \winnt_root\repair нужно средствами операционной системы закрыть для доступа всех пользователей, включая администраторов, и разрешать к ней доступ только во время работы утилиты RDISK, создающей в этом каталоге архивные копии системного реестра Windows NT. Системные администраторы также должны внимательно следить за тем, где и как хранятся дискеты аварийного восстановления (Emergency Repair Disks) и архивные копии на магнитных лентах, если на последних присутствует дубликат системного реестра Windows NT.
Если компьютер с операционной системой Windows NT входит в домен, то по умолчанию имена и хэшированные пароли последних 10-ти пользователей, регистрировавшихся на этом компьютере, сохраняются (кэшируются) в его локальном системном реестре (в разделе SECURITY\Policy\Secrets куста HKEY LOCAL_MACHINE). Чтобы отменить кэширование паролей на компьютерах домена, нужно с помощью утилиты REGEDT32 в раздел Micro-soft\WindowsNT\CurrentVersion\Winlogon раздела HKEY_LOCAL MACHINE добавить параметр CashedLogonsCount, установив его значение равным нулю, а тип — REG_SZ.
Для защиты базы данных SAM можно применить утилиту SYSKEY, входящую в состав пакета обновления Windows NT Service Pack 3. Эта утилита позволяет включить режим дополнительного шифрования информации о паролях, которая хранится в базе данных SAM. Уникальный 128-битовый ключ для дополнительного шифрования паролей (так называемый ключ шифрования паролей — Password Encryption Key, РЕК) автоматически сохраняется в системном реестре для дальнейшего использования [56].
Перед помещением в системный реестр ключ РЕК шифруется при помощи другого 128-битового ключа, который называется системным ключом (System Key), и может храниться либо в системном реестре, либо в файле с именем STARTUP.KEY в корневом каталоге на отдельной дискете. Можно не сохранять системный ключ на магнитном носителе, и тогда каждый раз при запуске операционной системы он будет вычисляться с помощью алгоритма MD5 на основе пароля, набираемого на клавиатуре в диалоговом окне утилиты SYSKEY. Последние два способа хранения системного ключа обеспечивают максимальную защиту паролей в базе данных SAM, однако приводят к невозможности автоматической перезагрузки операционной системы, поскольку для завершения процесса перезагрузки потребуется либо вставить дискету с системным ключом и подтвердить ее наличие в дисководе путем нажатия кнопки ОК в появившемся диалоговом окне, либо вручную ввести системный ключ с клавиатуры.
Для повышения стойкости паролей пользователей операционной системы Windows NT к взлому рекомендуется с помощью утилиты Диспетчер пользователей (User Manager) задать минимальную длину пользовательских паролей равной не менее 8 символов и включить режим устаревания паролей, чтобы пользователи периодически их обновляли. Чем выше вероятность атак на парольную защиту Windows NT, тем короче должен быть срок такого устаревания. А чтобы пользователи не вводили свои старые пароли повторно, необходимо включить режим хранения некоторого числа ранее использовавшихся паролей.
Утилита PASSPROP из состава Windows NT Resource Kit, запущенная с ключом /COMPLEX, заставляет пользователей вводить более устойчивые пароли, которые или сочетают буквы в разном регистре, или буквы с цифрами, или буквы со специальными символами. Более строгие правила фильтрации нестойких паролей можно задать после установки любого из пакетов обновления Windows NT, начиная с Service Pack 2. Тогда специальная библиотека PASSFJLT.DLL, находящаяся в каталоге \winnt_root\System32, будет следить за тем, чтобы каждый пользовательский пароль состоял не менее чем из 5 символов, не содержал имени пользователя, включал символы, по крайней мере, трех наборов из четырех возможных, составленных из прописных букв, строчных букв, цифр и специальных символов (знаков препинания и т. д.) соответственно. Чтобы задать такой режим проверки паролей пользователей, необходимо в раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControISet\Control\Lsa системного реестра с помощью программы REGEDT32 добавить параметр Noti fi cation Packages типа REG_MULTI_SZ и вписать в него строку PASSFILT. Если этот параметр уже имеется, то новую строку следует дописать после уже существующей.
Программы взлома паролей операционных систем представляют огромную опасность для их парольной защиты, сами парольные взломщики все же являются не менее ценным инструментом для системных администраторов, которые заинтересованы в выявлении слабых мест в парольной защите своих операционных систем. Основная проблема состоит не в существовании парольных взломщиков, а в том, что ими недостаточно часто пользуются системные администраторы.
Для противодействия атаки типа подбора паролей, в ОС UNIX введен механизм так называемого "затенения" (shadowing) файла паролей - он перемещается в другое место и становится недоступным обычным пользователям по чтению. Но это не сильно эффективное средство, что связано с идеологией UNIX, и вызов функции getpwent() иногда позволяет получить пароли пользователей в классическом виде. Также, иногда функция crypt() заменяется на другую (еще более медленную) хэш-функцию, и запуск старых программ-вскрывателей ни к чему не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше, чем crypt().
2 Атаки реализующие сканирование портов
2.1 Особенности протоколов, используемых при
сканировании портов
2.1.1 Протокол UDP
UDP (User Datagram Protocol, стандарт RFC-768) фактически не выполняет каких-либо особых функций дополнительно к функциям сетевого уровня (протокола IP), кроме (де)мультиплексирования пакетов с прикладными данными — то есть направления данных тому или иному приложению в зависимости от номера порта. Протокол UDP используется либо при пересылке коротких сообщений, когда накладные расходы на установление сеанса и проверку успешной доставки данных оказываются выше расходов на повторную (в случае неудачи) пересылку сообщения, либо в том случае, когда сама организация процесса-приложения обеспечивает установление соединения и проверку доставки пакетов (например, NFS) [30].
Пользовательские данные, поступившие от прикладного уровня, предваряются UDP-заголовком, и сформированное таким образом сообщение UDP отправляется на уровень IP. Получившаяся IР-датаграмма имеет структуру, показанную на рисунке 2.1.
IP-дейтаграмма с UDP-сообщением
Заголовок UDP-сообщения
|
|||||||||||||||
Рисунок 2.1 - Структура UDP-сообщения
Значения полей UDP-заголовка: Source Port — номер порта процесса-отправителя. Destination Port — номер порта процесса-получателя. Length — длина UDP-сообщения вместе с заголовком в октетах.
Checksum — контрольная сумма. Контрольная сумма вычисляется таким же образом, как и в TCP-заголовке (см. п. 2.5.2); если UDP-coобщение имеет нечетную длину, то при вычислении контрольной суммы к нему добавляется нулевой октет. После заголовка непосредственно следуют пользовательские данные, Переданные модулю UDP прикладным уровнем за один вызов.
Протокол UDP рассматривает эти данные как целостное сообщение; он никогда не разбивает сообщение для передачи в нескольких пакетах и не объединяет несколько сообщений для пересылки в одном пакете. Если прикладной процесс N раз вызвал модуль UDP для отправки данных (то есть запросил отправку N сообщений), то модулем UDP будет сформировано и отправлено N пакетов, и процесс-получатель будет должен N раз вызвать свой модуль UDP для получения всех сообщений [7].
При получении пакета от сетевого уровня модуль UDP проверяет контрольную сумму и передает содержимое сообщения прикладному процессу, чей номер порта указан в поле Destination Port.
Если проверка контрольной суммы выявила ошибку или если процесса, подключенного к требуемому порту, не существует, пакет игнорируется. В последнем случае модуль UDP может вернуть отправителю ICMP-сообщение Destination Unreachable: Port Unreachable. Если пакеты поступают быстрее, чем модуль UDP успевает их обрабатывать, то поступающие пакеты также игнорируются. Протокол UDP не имеет никаких средств подтверждения безошибочного приема данных или сообщения об ошибке, не обеспечивает приход сообщений в порядке отправки, не производит предварительного установления сеанса связи между прикладными процессами, поэтому он является ненадежным протоколом без установления соединения. Если приложение нуждается в подобного рода услугах, оно должно использовать на транспортном уровне протокол TCP.
Максимальная длина UDP-сообщения равна максимальной длине IР-датаграммы (65 535 октетов) за вычетом минимального IP-заголовка и UDP-заголовка, то есть 65 507 октетов.
Использование протокола UDP никак не изменяет положение с безопасностью передачи данных протоколом IP. Поскольку UDP не ориентирован на соединение и одно UDP-сообщение переносится в одной IP-датаграмме, злоумышленник может легко сфальсифицировать UDP-сообщение и ввести в заблуждение прикладной процесс (если только само приложение не обеспечивает безопасность передаваемых данных своими средствами) [29].
Примеры прикладных процессов, использующих протокол UDP: NFS (Network File System — сетевая файловая система), TFTP (Trivial File Transfer Protocol — простой протокол передачи файлов), SNMP (Simple Network Management Protocol — простой протокол управления сетью), DNS (Domain Name Service — доменная служба имен).