 |
Қазақстан Республикасының білім және ғылым министірлігі
|
|
|
|
Қ азақ стан Республикасының білім жә не ғ ылым министірлігі
«Мирас»Колледжі мекемесі
Отчёт
Пә н / Дисциплина: Методы Защиты Информации
Мамандығ ы/ Специальность: 1304000«Вычислительная техника и ПО (по видам)»
Тобы/Группа: ВТ - 192
Курс: 4 курс
Ө тілу мерзімі/ Сроки проведения практики: 01. 09. 2022 - 28. 10. 2022
Место практики: Учреждениеколледж «Мирас»
Заместитель директора по УПР: ______________Кенжебаева. Г. У.
Руководитель практики: _____________Мустафаева Л. Т.
Отчёт Подготовил(а): Гусев Остап
Шымкент 2022г
Содержание:
Тема 1 Архитектура подсистемы безопасности OC Windows.
Тема 2 Разграничение прав пользователей OC Windows.
Тема 3 Разграничение прав доступа OC Windows.
Тема 4 Аудит событий безопасности OC Windows.
Тема 5 Разграничение прав пользователей и доступа файлам в OC Unix.
Тема 6 Принципы построения и использования криптографического интерфейса приложении OC Windows.
Тема 7 Создание, хранение и распространение криптографических ключей с помощью CryptoApi.
Тема 8 Применение CryptoApi в приложениях пакета MS Office и шифрующей файловой системе Windows.
Тема 9 Аппаратные средства криптографической защиты данных.
Тема 10 Вредоносные программы и их классификация.
Тема 11 Методы обнаружения и удаления вредоносных программ.
Тема 12 Принципы построения систем защиты от копирования.
Тема 13 Методы защиты от копирования инсталляционных дисков.
Тема 14 Методы настройки устанавливаемого ПО на характеристики компьютера.
Тема 15 Методы защиты программ от изучения.
Тема 16 Стандарты и другие нормативные документы регламентирующие защищенность ПО и обрабатываемой информации.
|
|
|
Тема 17 Безопасность ПО и человеческий фактор.
Теоретическая часть
Тема 1 Архитектура подсистемы безопасности OC Windows.
Основные компоненты подсистемы безопасности операционной системы Microsoft Windows представлены на рис. 2. 1 (ID и Р — имя и аутентификатор пользователя, Н — функция хеширования, SID — идентификатор безопасности учетной записи пользователя, АТ— маркер безопасности, SD — дескриптор безопасности объекта доступа, R — результат проверки прав доступа процесса пользователя к объекту). Ядром подсистемы безопасности является локальная служба безопасности (Local Security Authority — LSA), размещающаяся в файле lsass. exe. После загрузки операционной системы автоматически запускается процесс входа (winlogon. exe), который остается активным до перезагрузки операционной системы или выключения питания компьютера, а его аварийное завершение приводит к аварийному завершению и всей операционной системы. Этим обеспечивается практическая невозможность подмены процесса входа при функционировании системы.
После нажатия пользователем комбинации клавиш Ctrl+Alt+ +Delete процесс входа обращается к провайдеру аутентификации (динамически компонуемой библиотеке функций — DLL) для приема от пользователя его логического имени (ID) и аутентифицирующей информации (F). Стандартный провайдер аутентификации размещается в файле msgina. dll (Graphical Identification and Authentication dynamic-link library — динамически компонуемая
библиотека GINA) и в качестве аутентифицирующей информации использует пароли пользователей, введенные с клавиатуры или считанные со смарт-карты. Возможно применение других провайдеров аутентификации (например, использующих биометрическую аутентификацию). В этом случае необходимо, чтобы интерфейс к предоставляемым провайдером аутентификации функциям соответствовал определениям, содержащимся в файле winwlx. h (входит в состав любой системы программирования на языке C++ для Windows). Путь к используемому процессом входа в систему провайдеру аутентификации должен быть записан в разделе реестра HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsNTCurrentVersionWinLogon как значение параметра GinaDLL. Процесс входа использует сообщение Windows WLX WM SAS для извещения библиотеки GINA о различных событиях.
|
|
|
Для организации диалога с пользователем в библиотеке GINA должны использоваться функции WlxMessageBox, WlxDialogBox, WlxDialogBoxIndirect, WlxDialogBoxParam и Wlx- DialogBoxIndirectParam вместо соответствующих функций из набора Windows API (без префикса Wlx) для гарантии контроля процесса входа и провайдера аутентификации над стандартными диалогами Windows. Ошибка при выполнении версий процесса входа для этих функций может быть результатом попытки получения доступа к системе неавторизованного пользователя. Рабочий стол в операционной системе Windows представляет собой совокупность окон, одновременно видимых на экране. Только процессы, окна которых расположены на одном рабочем столе, могут взаимодействовать между собой, используя средства графического интерфейса пользователя Windows (Graphic User Interface — GUI). Владельцем всех рабочих столов является процесс входа. Сам процесс входа выполняется на отдельном рабочем столе, активизируемом после нажатия пользователем клавиш Ctrl+Alt+ +Delete. После успешного входа пользователя запускаемые им приложения выполняются на рабочем столе приложений (рабочем столе пользователя). После запуска хранителя экрана активизируется рабочий стол хранителя экрана. В качестве владельца всех трех рабочих столов процесс входа может осуществлять переключение между ними. При вызове функций библиотеки GINA процесс входа указывает, какой из рабочих столов является текущим (видимым). Никакой другой процесс, в том числе и программная закладка, внедренная нарушителем для перехвата паролей, не имеет доступа к рабочему столу процесса входа или хранителя экрана. Поэтому приглашение пользователю на вход в систему, выводимое этой закладкой, может располагаться только на рабочем столе приложений, с которым связаны все запущенные пользователем программы. Сообщение о нажатии Ctrl+Alt+Delete посылается только процессу входа, который, напомним, остается активным до завершения работы (перезагрузки) операционной системы или выключения питания. Для всех других процессов (в частности, для всех прикладных программ, запущенных пользователем) нажатие этой комбинации клавиш совершенно незаметно. При загрузке системы на экране компьютера вначале отображается рабочий стол процесса входа. Однако пользователь вводит имя и пароль не сразу, а только после нажатия Ctrl+Alt+ +Delete. Когда пользователь выходит из системы, то также активизируется рабочий стол процесса входа, и новый пользователь может ввести пароль для входа в систему только после нажатия Ctrl+Alt+Delete. Если в систему внедрена программная закладка для перехвата паролей, то для осуществления ею этого перехвата в этой вредоносной программе необходимо обработать нажатие пользователем комбинации клавиш Ctrl+Alt+Delete. В противном случае при нажатии пользователем этой комбинации клавиш произойдет переключение на рабочий стол процесса входа. Рабочий стол приложений станет неактивным и закладка просто не сможет ничего перехватить — сообщения о нажатии пользователем клавиш будут приходить на другой рабочий стол. Однако для всех прикладных программ факт нажатия пользователем комбинации Ctrl+Alt+Delete всегда остается незамеченным. Поэтому введенный пользователем пароль будет воспринят не программной закладкой, а провайдером аутентификации. Конечно, программная закладка может имитировать не первое приглашение операционной системы, где пользователю предлагается нажать Ctrl+Alt+ Delete для начала работы, а то приглашение, которое высвечивается после нажатия пользователем этой комбинации. Однако в обычных условиях (при отсутствии внедренной программной закладки) это второе приглашение автоматически отменяется через достаточно короткое время (от 30 секунд до 1 минуты в зависимости от версии Windows). Если второе приглашение присутствует на экране компьютера долгое время, этот факт должен насторожить пользователя. Кроме того, как показывает опыт, пользователи, имеющие достаточный опыт работы с ОС Windows, приобретают привычку начинать работу с системой с нажатия Ctrl+Alt+ Delete независимо от того, что отображается на экране. Поэтому защита операционной системы Windows от программных закладок такого рода может считаться весьма надежной. Введенные пользователем имя и пароль передаются провайдером аутентификации в службу LSA, которая обращается к пакету аутентификации (динамически компонуемой библиотеке функций) для подтверждения подлинности введенного имени пользователя. Для аутентификации локальной учетной записи, зарегистрированной на компьютере, на котором осуществляет попытку входа пользователь, используется пакет аутентификации MSV10 (из файла msvl_0. dll). В этом случае пакет аутентификации вычисляет хеш-значение пароля Н(Р) и обращается к диспетчеру учетных записей (Security Account Manager — SAM) для проверки правильности введенного пароля и возможности для пользователя с введенным логическим именем начать работу в системе (не истек ли срок действия пароля, не заблокирована ли учетная запись пользователя и т. п. ). Диспетчер учетных записей обращается к базе данных учетных записей (базе данных SAM) для извлечения информации из учетной записи пользователя с введенным логическим именем. База данных учетных записей содержится в разделе реестра НКEYLOC ALM АСНINESAM (в файле WindowsSystem32 ConfigSAM). К базе данных SAM не может быть получен доступ для чтения или изменения с помощью штатных средств операционной системы даже администратором (файл с базой данных открывается ядром операционной системы во время ее загрузки в монопольном режиме). Для редактирования базы данных SAM предназначены специальные функции из набора Windows API и специальное системное программное обеспечение (оснастки «Управление компьютером» и «Локальная политика безопасности»). Пароль пользователя в базе данных SAM хранится в виде двух хеш-значений, каждое из которых имеет длину 128 бит. Первое из этих хеш-значений формируется по алгоритму Windows NT: 1. Строка символов пароля Р усекается до 14 знаков (при необходимости) и преобразуется в кодировку Unicode, в которой каждый символ представляется двумя байтами. 2. Вычисляется хеш-значение преобразованного пароля Н(Р) длиной 128 бит (используется функция хеширования MD4). 3. Полученное хеш-значение зашифровывается по алгоритму DES с помощью ключа, выводимого из относительного номера учетной записи пользователя, Erid(H(P)). 4. Полученный результат шифрования записывается в базу данных учетных записей. Второе хеш-значение пароля пользователя вычисляется по алгоритму LAN Manager: 1. Все буквенные символы (латинского алфавита) строки пароля Р преобразуются к верхнему регистру. 2. Строка символов пароля дополняется нулями, если она короче 14 байтов, и делится на две семибайтовые половины Р1 и Р2. 3. Каждое из значений Рх и Р2 используется в качестве ключа для шифрования по алгоритму DES магической строки М= = «KGS! @#$%», в результате которого получаются два значения из 64 бит каждое — Я, = ЕР1(М) и Н2 = Еп(М). 4. Выполняется шифрование по алгоритму DES на ключе, равном относительному номеру учетной записи, результата сцепления #! и Н2 — Erid(H II ^)-5. Полученный результат шифрования помещается в базу данных SAM. Алгоритм получения хеш-значения LAN Manager является значительно менее стойким (искусственно уменьшается мощность алфавита, из которого выбираются символы пароля, а разделение пароля на две половинки облегчает его подбор в том случае, если длина пароля не превышает семи знаков, так как результат шифрования магической строки на нулевом ключе заранее известен нарушителю). Использование более «слабого» алгоритма LAN Manager объясняется необходимостью обеспечить совместимость с ранними версиями операционной системы Windows, которые могут быть установлены на рабочих станциях локальной сети организации. Другим недостатком хранения паролей пользователей в защищенных версиях Windows является то, что без учета заключительного шифрования на ключе, равном относительному номеру учетной записи, в обоих алгоритмах одинаковому паролю, случайно выбранному разными пользователями, будет соответствовать одно и то же хеш-значение. Это создает теоретическую возможность применения полномочий одного пользователя другим, узнавшим об этом факте. Относительный же номер учетной записи может быть достаточно легко получен нарушителем (встроенная учетная запись администратора, например, всегда имеет относительный номер 500). Несмотря на то, что доступ к базе данных SAM с помощью штатных средств Windows для нарушителя практически невозможен, он тем не менее может, например, скопировать содержащий ее файл на подготовленный носитель после загрузки на компьютере другой операционной системы с заранее подготовленного съемного диска (помешать этому можно только с помощью организационных мер). Затем информация из копии файла SAM восстанавливается на компьютере нарушителя, который теперь может получить доступ к базе данных учетных записей с помощью специальных программных средств. Следующим шагом нарушителя будет программный подбор паролей привилегированных пользователей, получив которые он сможет осуществить несанкционированный доступ к информации в КС. Для предотвращения подобной угрозы администратор безопасности Windows может дополнительно зашифровать хеш- значения паролей пользователей в базе данных SAM с помощью системной программы syskey. Программа syskey обеспечит шифрование хеш-значений паролей с помощью первичного ключа длиной 128 бит, хранящегося в реестре также в зашифрованном на системном ключе виде. После запуска программы syskey администратор должен выбрать способ хранения системного ключа длиной также 128 бит, который будет использован для шифрования первичного ключа: • в системном реестре (преимущество этого варианта — отсутствие необходимости присутствия привилегированного пользователя при загрузке или перезагрузке операционной системы, а недостаток — наименьшая защищенность хранения системного ключа); • в файле startup. key (длиной 16 байт) в корневом каталоге специальной дискеты (в этом случае придется отдельно позаботиться о защищенном хранении этой дискеты и ее резервной копии); • без физического сохранения системного ключа, который будет генерироваться из специальной парольной фразы длиной не менее 12 символов. Во втором и третьем вариантах при загрузке операционной системы перед появлением приглашения следует нажать комбинацию клавиш Ctrl+Alt+ Delete, появится диалоговое окно с приглашением вставить дискету с системным ключом шифрования или ввести парольную фразу. Другим вариантом усложнения задачи подбора пароля пользователя по его похищенному хеш-значению является включение параметра безопасности «Сетевая безопасность: не хранить хеш-значений Lan Manager при следующей смене пароля». Но возможность подбора пароля, хешированного по более стойкому алгоритму NTLM, у нарушителя все равно остается. Если пользователь пытается войти в систему под именем глобальной учетной записи, зарегистрированной в домене (объединении компьютеров, разделяющих общую политику безопасности и информацию об учетных записях пользователей), то пакет аутентификации MSV10 отправляет логическое имя и хеш-значение пароля пользователя сервису NetLogon для аутентификации пользователя на контроллере домена (сервере аутентификации). Далее выполняется аутентификация пользователя по протоколам LM, NTLM и NTLM 2.
|
|
|
|
|
|
|
|
|
|
|
|
