2) Парольная система должна частично или полно блокировать вход в систему для этого пользователя. После чего разблокировать доступ может только администратор или служба безопасности. Кроме того, обнаружение попытки подбора пароля может сопровождаться звуковыми сигналами. В рабочее время они будут слышны окружающим и действуют на психику взломщика. Во многом ответная реакция зависит от назначения всей компьютерной системы.
Парольная система также должна проконтролировать, не была ли это попытка войти в систему с "просроченным" паролем. Или вариант, когда злоумышленники пытаются войти с паролем пользователя, который в настоящее время отсутствует на работе (уже уволился, отпуск, болезнь и т.п.). Случаи входов в компьютерные системы уволившимися сотрудниками не так уж редки в практике. Организация работы с компьютерной системой должна учитывать, что если сотрудник отсутствует на работе, его пароль блокируется. Также, система должна проверить, не работает ли уже пользователь с таким паролем - не использует ли его кто-то вторично.
Если пароль введен правильно, система должна вывести на экран дату и время последнего входа этого пользователя в систему. Это поможет ему самому проконтролировать, не работает ли кто-нибудь, используя его пароль.
Некоторые системы имеют еще и такой параметр, как интенсивность попыток входа и задают предельно допустимое время для входа пользователя в систему, ограничивая тем самым злоумышленнику возможность подбора пароля. Это особенно актуально в тех случаях, когда наряду с ручным набором пароля все же допускается и автоматическим. Процедуры допуска в таких системах контролируют количество попыток входа в систему для каждого пользователя и пресекают возможные попытки подбора пароля.
Одна из главных задач системного администратора 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 — доменная служба имен).
Протокол TCP (Transmission Control Protocol) обеспечивает сквозную доставку данных между прикладными процессами, запущенными на узлах, взаимодействующих по сети. Стандарт протокола TCP содержится в RFC-793, уточнен в RFC-1122.
TCP — надежный потоковый (byte-stream) протокол с установлением соединения. TCP находится на транспортном уровне стека TCP/IP, между протоколом IP и собственно приложением. Протокол IP занимается пересылкой датаграмм по сети, никак не гарантируя доставку, целостность, порядок прибытия информации и готовность получателя к приему данных; все эти задачи возложены на протокол TCP.
При получении датаграммы, в поле Protocol которой указан код протокола TCP, модуль IP передает данные этой датаграммы модулю TCP. Эти данные представляют собой TCP-сегмент, содержащий TCP-заголовок и данные пользователя (прикладного процесса). Модуль TCP анализирует служебную информацию заголовка, определяет, какому именно процессу предназначены данные пользователя, проверяет целостность и порядок прихода данных и подтверждает их прием другой стороне. По мере получения правильной последовательности неискаженных данных пользователя они передаются прикладному процессу [7].
Модуль TCP выполняет передачу потоков данных между своими клиентами в обоих направлениях. Клиентами TCP являются прикладные процессы, вызывающие модуль TCP при необходимости получить или отправить данные процессу-клиенту на другом узле.
Протокол TCP рассматривает данные клиента как неинтерпретируемый поток октетов (в отличие от UDP, воспринимающего прикладные данные как отдельные сообщения). TCP разделяет этот поток на части для пересылки на другой узел в TCP-сегментах некоторого размера. Для отправки или получения сегмента модуль TCP вызывает модуль IP.
Немедленное отправление данных может быть затребовано процессом-клиентом от TCP-модуля с помощью установки флага PSH (push — протолкнуть), иначе TCP сам будет решать, как накапливать и когда отправлять данные клиента или когда передавать клиенту полученные данные. Очевидно, что применение флага PSH необходимо, например, при интерактивной работе с терминалом (программа telnet), поскольку введенную пользователем команду следует отправить на сервер немедленно, какой бы короткой она ни была. Также флаг PSH должен быть установлен приложением для последнего блока данных, отправляемых в сеансе [29].
Максимальный размер передаваемого сегмента устанавливается равным меньшей из двух величин: размера сегмента, который может принимать получатель (эта информация передается при установлении соединения) и минимального значения MTU на пути до получателя, установленного с помощью алгоритма Path MTU Discovery. Максимальный размер сегмента (без заголовков) по умолчанию равен 536 октетов.
Протокол TCP обеспечивает работу одновременно нескольких соединений. Каждый прикладной процесс идентифицируется номером порта. Заголовок TCP-сегмента содержит номера портов процесса-отправителя и процесса-получателя. При получении сегмента модуль TCP анализирует номер порта получателя и отправляет данные соответствующему прикладному процессу.
Все распространенные сервисы Интернета имеют стандартизованные номера портов. Например, номер порта сервера электронной почты — 25, сервера WWW — 80. Список стандартных номеров портов можно найти в файле /etc/services (UNIX) или C:\winnt\ system32\ drivers\etc\services (Windows 2000) [7].
Совокупность IP-адреса и номера порта называется сокетом. Сокет уникально идентифицирует прикладной процесс в Интернете. Например, сокет сервера электронной почты на хосте 1.16.195.4 обозначается как 1.16.195.4:25; часто номер порта отделяется не двоеточием, а точкой.