1193 lines
99 KiB
TeX
Executable File
1193 lines
99 KiB
TeX
Executable File
\documentclass[a4paper, final]{article}
|
||
%\usepackage{literat} % Нормальные шрифты
|
||
\usepackage[14pt]{extsizes} % для того чтобы задать нестандартный 14-ый размер шрифта
|
||
\usepackage{tabularx}
|
||
\usepackage{booktabs}
|
||
\usepackage[T2A]{fontenc}
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage[russian]{babel}
|
||
\usepackage{amsmath}
|
||
\usepackage[left=25mm, top=20mm, right=20mm, bottom=20mm, footskip=10mm]{geometry}
|
||
\usepackage{ragged2e} %для растягивания по ширине
|
||
\usepackage{setspace} %для межстрочного интервала
|
||
\usepackage{moreverb} %для работы с листингами
|
||
\usepackage{indentfirst} % для абзацного отступа
|
||
\usepackage{moreverb} %для печати в листинге исходного кода программ
|
||
\usepackage{pdfpages} %для вставки других pdf файлов
|
||
\usepackage{tikz}
|
||
\usepackage{graphicx}
|
||
\usepackage{afterpage}
|
||
\usepackage{longtable}
|
||
\usepackage{float}
|
||
|
||
% Рекомендуется для biblatex (кавычки/локализация цитат и т.п.)
|
||
\usepackage{csquotes}
|
||
|
||
% ГОСТ-стили для biblatex
|
||
\usepackage[
|
||
backend=biber,
|
||
bibstyle=gost-numeric, % ссылки вида: [1]
|
||
citestyle=gost-numeric,
|
||
sorting=none % порядок в списке = по первому цитированию
|
||
]{biblatex}
|
||
|
||
% Все источники хранятся в отдельном файле
|
||
\addbibresource{refs.bib}
|
||
|
||
\renewcommand*{\bibfont}{\small}
|
||
|
||
% \usepackage[paper=A4,DIV=12]{typearea}
|
||
\usepackage{pdflscape}
|
||
% \usepackage{lscape}
|
||
|
||
\usepackage{array}
|
||
\usepackage{multirow}
|
||
|
||
\renewcommand\verbatimtabsize{4\relax}
|
||
\renewcommand\listingoffset{0.2em} %отступ от номеров строк в листинге
|
||
\renewcommand{\arraystretch}{1.4} % изменяю высоту строки в таблице
|
||
\usepackage[font=small, singlelinecheck=false, justification=centering, format=plain, labelsep=period]{caption} %для настройки заголовка таблицы
|
||
\usepackage{listings} %листинги
|
||
\usepackage{xcolor} % цвета
|
||
% \usepackage{hyperref}% для гиперссылок
|
||
\usepackage{enumitem} %для перечислений
|
||
|
||
\newcommand{\specialcell}[2][l]{\begin{tabular}[#1]{@{}l@{}}#2\end{tabular}}
|
||
|
||
|
||
\setlist[enumerate,itemize]{leftmargin=1.2cm} %отступ в перечислениях
|
||
|
||
% \hypersetup{colorlinks,
|
||
% allcolors=[RGB]{010 090 200}} %красивые гиперссылки (не красные)
|
||
|
||
% подгружаемые языки — подробнее в документации listings (это всё для листингов)
|
||
\lstloadlanguages{ SQL}
|
||
% включаем кириллицу и добавляем кое−какие опции
|
||
\lstset{tabsize=2,
|
||
breaklines,
|
||
basicstyle=\footnotesize,
|
||
columns=fullflexible,
|
||
flexiblecolumns,
|
||
numbers=left,
|
||
numberstyle={\footnotesize},
|
||
keywordstyle=\color{blue},
|
||
inputencoding=cp1251,
|
||
extendedchars=true
|
||
}
|
||
\lstdefinelanguage{MyC}{
|
||
language=SQL,
|
||
% ndkeywordstyle=\color{darkgray}\bfseries,
|
||
% identifierstyle=\color{black},
|
||
% morecomment=[n]{/**}{*/},
|
||
% commentstyle=\color{blue}\ttfamily,
|
||
% stringstyle=\color{red}\ttfamily,
|
||
% morestring=[b]",
|
||
% showstringspaces=false,
|
||
% morecomment=[l][\color{gray}]{//},
|
||
keepspaces=true,
|
||
escapechar=\%,
|
||
texcl=true
|
||
}
|
||
|
||
\textheight=24cm % высота текста
|
||
\textwidth=16cm % ширина текста
|
||
\oddsidemargin=0pt % отступ от левого края
|
||
\topmargin=-1.5cm % отступ от верхнего края
|
||
\parindent=24pt % абзацный отступ
|
||
\parskip=5pt % интервал между абзацами
|
||
\tolerance=2000 % терпимость к "жидким" строкам
|
||
\flushbottom % выравнивание высоты страниц
|
||
|
||
|
||
% Настройка листингов
|
||
\lstset{
|
||
language=python,
|
||
extendedchars=\true,
|
||
inputencoding=utf8,
|
||
keepspaces=true,
|
||
% captionpos=b, % подписи листингов снизу
|
||
}
|
||
|
||
% Настройка содержания
|
||
\usepackage{tocloft}
|
||
\usepackage[hidelinks]{hyperref}
|
||
|
||
% section в содержании НЕ жирным
|
||
\renewcommand{\cftsecfont}{\normalfont}
|
||
\renewcommand{\cftsecpagefont}{\normalfont}
|
||
|
||
% убрать отступ у subsection
|
||
\setlength{\cftsubsecindent}{0pt}
|
||
|
||
|
||
|
||
\begin{document}
|
||
% ТИТУЛЬНЫЙ ЛИСТ
|
||
\begin{center}
|
||
\hfill \break
|
||
\hfill \break
|
||
\normalsize{МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ\\
|
||
федеральное государственное автономное образовательное учреждение высшего образования \\
|
||
САНКТ-ПЕТЕРБУРГСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ПЕТРА ВЕЛИКОГО\\[10pt]}
|
||
\normalsize{Институт компьютерных наук и кибербезопасности}\\[10pt]
|
||
\normalsize{Высшая школа технологий искусственного интеллекта}\\[10pt]
|
||
\normalsize{Направление: 02.03.01 <<Математика и компьютерные науки>>}\\
|
||
|
||
\hfill \break
|
||
\hfill \break
|
||
\hfill \break
|
||
\large{Отчёт по практическим работам по дисциплине}\\
|
||
\large{<<Защита информации>>}\\
|
||
|
||
\hfill \break
|
||
\hfill \break
|
||
\hfill \break
|
||
\end{center}
|
||
|
||
\small{
|
||
\begin{tabular}{lrrl}
|
||
\!\!\!Студент, & \hspace{2cm} & & \\
|
||
\!\!\!группы 5130201/20101 & \hspace{2cm} & \underline{\hspace{3cm}} & Тищенко А. А. \\\\
|
||
\!\!\!Руководитель & \hspace{2cm} & & \\
|
||
\!\!\! & \hspace{2cm} & \underline{\hspace{3cm}} & Силиненко А. В. \\\\
|
||
&&\hspace{4cm}
|
||
\end{tabular}
|
||
\begin{flushright}
|
||
<<\underline{\hspace{1cm}}>>\underline{\hspace{2.5cm}} 2026г.
|
||
\end{flushright}
|
||
}
|
||
|
||
\hfill \break
|
||
\hfill \break
|
||
\begin{center} \small{Санкт-Петербург, 2026} \end{center}
|
||
\thispagestyle{empty} % выключаем отображение номера для этой страницы
|
||
|
||
\newpage
|
||
\tableofcontents
|
||
\thispagestyle{empty} % выключаем отображение номера для этой страницы
|
||
|
||
\newpage
|
||
\section*{Введение}
|
||
\addcontentsline{toc}{section}{Введение}
|
||
|
||
В рамках курса <<Защита информации>> было выполнено несколько практических работ, по результатам которых был составлен данный отчёт, содержащий информацию по всем практическим работам. Отчетная информация по каждой работе – это отдельный раздел в общем отчете.
|
||
|
||
В отчёте представлены результаты следующих практических работ:
|
||
\begin{enumerate}
|
||
\item Практическая работа №1. Анализ уязвимостей программного обеспечения. Данная практическая работа посвящена анализу уязвимостей программного обеспечения с использованием Банка данных угроз безопасности информации ФСТЭК России~\cite{fstec-bdu}. В ходе выполнения работы предусмотрено изучение структуры разделов «Угрозы» и «Уязвимости», а также поиск уязвимостей по заданным критериям. Особое внимание уделяется выявлению уязвимостей, соответствующих используемым версиям операционных систем личных устройств, и рассмотрению возможных мер по их устранению.
|
||
\item Практическая работа №2. Разработка и исследование системы аутентификации и авторизации. Данная практическая работа посвящена разработке системы доступа пользователей к конфиденциальным данным и исследованию стойкости паролей к атаке методом грубой силы. В ходе выполнения работы реализованы утилита управления пользователями, утилита доступа к конфиденциальным данным и программа перебора паролей, а также проведено экспериментальное исследование зависимости времени взлома от длины пароля.
|
||
\item Практическая работа №3. Реализация моделей дискреционного и мандатного управления доступом. Данная практическая работа посвящена расширению системы из работы №2 путём реализации моделей DAC (дискреционный доступ) и MAC (мандатный доступ) на основе модели Белла–Лападулы.
|
||
\item Практическая работа №4. Межсетевое экранирование средствами \texttt{iptables}. Данная практическая работа посвящена настройке межсетевого экрана в Linux, формированию политики фильтрации сетевого трафика и экспериментальной проверке пропуска разрешённых соединений и блокировки запрещённых пакетов с использованием \texttt{tcpdump}.
|
||
\item Практическая работа №5. Разработка клиент-серверного приложения для конфиденциального обмена сообщениями. Данная практическая работа посвящена разработке TCP-приложения с поддержкой шифрования 3DES-CBC с затравкой (выработка ключа сессии на основе SHA-256), контроля целостности сообщения на основе MD5 в соответствии с индивидуальным заданием, дополнительного режима HMAC-SHA256, а также проверке корректности шифрования с помощью анализа трафика.
|
||
\end{enumerate}
|
||
|
||
\newpage
|
||
\section{Анализ уязвимостей программного обеспечения}
|
||
\subsection{Цели и задачи работы}
|
||
|
||
Практическая работа №1 по дисциплине «Защита информации» посвящена анализу уязвимостей программного обеспечения с использованием Банка данных угроз безопасности информации ФСТЭК Российской Федерации.
|
||
|
||
Цель работы: получение практических навыков работы с Банком данных угроз ФСТЭК России~\cite{fstec-bdu}, содержащим сведения об угрозах безопасности информации и уязвимостях программного обеспечения.
|
||
|
||
Для достижения поставленной цели в ходе выполнения работы были определены следующие задачи:
|
||
|
||
\begin{enumerate}
|
||
\item Ознакомление со структурой раздела <<Угрозы>> Банка данных угроз безопасности информации ФСТЭК России.
|
||
\item Ознакомление со структурой раздела <<Уязвимости>> Банка данных угроз.
|
||
\item Поиск информации в разделе <<Уязвимости>> по заданным критериям.
|
||
\item Определение версий операционных систем, используемых на личном смартфоне и персональном компьютере.
|
||
\item Поиск уязвимостей с уровнем опасности <<Критический>> и <<Высокий>>, соответствующих используемым версиям операционных систем, а также анализ и применение рекомендованных мер по их устранению.
|
||
\end{enumerate}
|
||
|
||
Выполнение данной работы позволяет сформировать практические навыки анализа актуальных угроз и уязвимостей, а также повысить уровень понимания механизмов обеспечения информационной безопасности современных информационных систем.
|
||
|
||
\subsection{Знакомство с разделом <<Угрозы>> Банка угроз}
|
||
Раздел <<Угрозы>> Банка данных угроз безопасности информации ФСТЭК России предназначен для систематизированного представления сведений об актуальных угрозах безопасности информации. Данный раздел содержит структурированную информацию, позволяющую оценить характер угроз, возможные последствия их реализации и способы противодействия.
|
||
|
||
Раздел включает в себя следующие основные аспекты:
|
||
|
||
\begin{enumerate}
|
||
\item Классификация угроз: угрозы распределяются по различным категориям в зависимости от источника возникновения, способа реализации и объекта воздействия. Это позволяет упорядочить информацию и упростить её анализ.
|
||
|
||
\item Описание угроз: для каждой угрозы приводится развернутое описание, включающее возможные сценарии реализации, цели нарушителя и потенциальные последствия для информационной системы.
|
||
|
||
\item Объекты воздействия: указываются типы информационных систем, ресурсов или процессов, на которые может быть направлена угроза.
|
||
|
||
\item Уровень опасности: каждой угрозе присваивается определённый уровень опасности, отражающий степень потенциального ущерба при её реализации.
|
||
|
||
\item Рекомендации по противодействию: приводятся общие меры и подходы, направленные на предупреждение реализации угрозы или снижение возможных негативных последствий.
|
||
\end{enumerate}
|
||
|
||
\subsection{Знакомство с разделом <<Уязвимости>> Банка угроз}
|
||
|
||
Раздел <<Уязвимости>> Банка данных угроз безопасности информации ФСТЭК России предназначен для получения сведений об актуальных уязвимостях программного обеспечения и их характеристиках. В рамках работы были рассмотрены подразделы: <<Список уязвимостей>>, <<Наиболее опасные уязвимости>> и <<Инфографика>>.
|
||
|
||
Список уязвимостей представляет собой структурированный перечень выявленных уязвимостей в программном обеспечении. Для каждой уязвимости указывается идентификатор, наименование, описание, затронутое программное обеспечение и его версии, уровень опасности, а также оценка по шкале CVSS. Уязвимости классифицируются по уровню критичности (критический, высокий, средний и др.), что позволяет определить приоритетность их устранения. Также приводятся рекомендации по устранению или минимизации последствий эксплуатации уязвимости.
|
||
|
||
Подраздел <<Наиболее опасные уязвимости>> содержит перечень уязвимостей с наивысшим уровнем опасности. Как правило, к ним относятся уязвимости, позволяющие выполнить удалённое выполнение кода, повысить привилегии, обойти механизмы аутентификации или получить несанкционированный доступ к информации. Данный раздел позволяет оперативно определить наиболее критичные риски для информационных систем (см. рис.~\ref{fig:top_vuln}).
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth]{img/top_vulnerabilities.png}
|
||
\caption{Пример отображения наиболее опасных уязвимостей}
|
||
\label{fig:top_vuln}
|
||
\end{figure}
|
||
|
||
Подраздел <<Инфографика>> предназначен для наглядного представления статистических данных по уязвимостям. В нём отображается распределение уязвимостей по уровням опасности, типам ошибок, видам программного обеспечения и производителям. Инфографика позволяет визуально оценить текущее состояние защищённости программных продуктов и выявить наиболее проблемные направления (см. рис.~\ref{fig:stats_vuln}).
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth]{img/vulnerability_stats.png}
|
||
\caption{Пример статистического распределения уязвимостей}
|
||
\label{fig:stats_vuln}
|
||
\end{figure}
|
||
|
||
\newpage
|
||
\subsection{Версии ОС, используемые в личных устройствах}
|
||
|
||
На личном компьютере используется операционная система Ubuntu 25.10 (см. рис.~\ref{fig:laptop-os-version}).
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.5\linewidth]{img/laptop-os-version.png}
|
||
\caption{Версия операционной системы личного компьютера}
|
||
\label{fig:laptop-os-version}
|
||
\end{figure}
|
||
|
||
На личном мобильном устройстве используется операционная система Android 11 с графической оболочкой MIUI Global 12.5.14, сборка 12.5.14.0 RKURUXM (см. рис.~\ref{fig:mobile-os-version}).
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.5\linewidth]{img/mobile-os-version.jpg}
|
||
\caption{Версия операционной системы личного мобильного устройства}
|
||
\label{fig:mobile-os-version}
|
||
\end{figure}
|
||
|
||
\subsection{Уязвимости ОС личного компьютера}
|
||
|
||
Для поиска уязвимостей ОС личного компьютера на сайте Банка данных угроз безопасности информации ФСТЭК России были использованы следующие критерии:
|
||
\begin{enumerate}
|
||
\item Операционная система: Ubuntu 25.10.
|
||
\item Уровень опасности: высокий.
|
||
\end{enumerate}
|
||
Использовался уровень опасности <<высокий>>, так как критических уязвимостей для данной ОС не найдено.
|
||
|
||
По заданным критериям было найдено 10 уязвимостей (см. рис.~\ref{fig:laptop-vulnerabilities}).
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth]{img/laptop-vulnerabilities.png}
|
||
\caption{Уязвимости ОС личного компьютера}
|
||
\label{fig:laptop-vulnerabilities}
|
||
\end{figure}
|
||
|
||
Наиболее свежей является уязвимость BDU:2025-15300 <<Уязвимость интерфейсов cpu\_latency\_qos\_add, remove, update\_request модуля drivers/ufs/core/ufs-sysfs.c драйвера поддержки устройств SCSI ядра операционной системы Linux связана с ошибками синхронизации при использовании общего ресурса («Ситуация гонки»). Эксплуатация уязвимости может позволить нарушителю, действующему удаленно, вызвать отказ в обслуживании>>. Развёрнутое описание уязвимости представлено на рисунке~\ref{fig:laptop-vulnerabilities-details}.
|
||
|
||
Базовый вектор уязвимости CVSS 2.0: AV:A/AC:L/Au:S/C:C/I:C/A:C.
|
||
|
||
AV: A (Access Vector: Adjacent Network) — параметр, указывающий на то, что атакующий должен находиться в той же локальной сети или в непосредственной сетевой близости (например, в одной Wi-Fi сети) для реализации атаки.
|
||
|
||
AC: L (Access Complexity: Low) — низкая сложность эксплуатации уязвимости. Для успешной атаки не требуется выполнения сложных условий или специальной подготовки среды.
|
||
|
||
Au: S (Authentication: Single) — для осуществления атаки требуется прохождение аутентификации один раз. Это означает, что атакующий должен обладать учетной записью или иным способом пройти проверку подлинности.
|
||
|
||
C: C (Confidentiality Impact: Complete) — полное нарушение конфиденциальности. Уязвимость позволяет получить полный доступ к защищаемой информации.
|
||
|
||
I: C (Integrity Impact: Complete) — полное нарушение целостности. Злоумышленник может изменять или уничтожать данные без ограничений.
|
||
|
||
A: C (Availability Impact: Complete) — полное нарушение доступности. Эксплуатация уязвимости может привести к отказу в обслуживании или полной недоступности системы.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.9\linewidth]{img/laptop-vulnerabilities-details.png}
|
||
\caption{Развёрнутое описание уязвимости BDU:2025-15300}
|
||
\label{fig:laptop-vulnerabilities-details}
|
||
\end{figure}
|
||
|
||
Уязвимость была устранена в версии 25.10-6.17.0-14.14, поэтому для её устранения достаточно было обновить ОС до этой версии.
|
||
|
||
\newpage
|
||
\subsection{Уязвимости ОС личного мобильного устройства}
|
||
|
||
Для поиска уязвимостей ОС личного мобильного устройства на сайте Банка данных угроз безопасности информации ФСТЭК России были использованы следующие критерии:
|
||
\begin{enumerate}
|
||
\item Операционная система: Android 11.
|
||
\item Уровень опасности: критический.
|
||
\end{enumerate}
|
||
|
||
По заданным критериям была найдена 1 уязвимость (см. рис.~\ref{fig:mobile-vulnerabilities}).
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth]{img/mobile-vulnerabilities.png}
|
||
\caption{Уязвимости ОС личного мобильного устройства}
|
||
\label{fig:mobile-vulnerabilities}
|
||
\end{figure}
|
||
|
||
Развёрнутое описание уязвимости BDU:2023-08587 <<Уязвимость функции \\ callback\_thread\_event (com\_android\_bluetooth\_btservice\_AdapterService.cpp) операционной системы Android связана с использованием памяти после её освобождения. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, выполнить произвольный код>>, представлено на рисунке~\ref{fig:mobile-vulnerabilities-details}.
|
||
|
||
Базовый вектор уязвимости CVSS 2.0: AV:N/AC:L/Au:N/C:C/I:C/A:C.
|
||
|
||
AV: N (Access Vector: Network) — параметр, указывающий на то, что атакующий может осуществить атаку удалённо через сеть (например, через Интернет), без необходимости физического доступа или нахождения в локальной сети.
|
||
|
||
AC: L (Access Complexity: Low) — низкая сложность эксплуатации уязвимости. Для успешной атаки не требуется специальных условий или сложной подготовки.
|
||
|
||
Au: N (Authentication: None) — для эксплуатации уязвимости не требуется аутентификация. Атакующий может выполнить атаку без наличия учетной записи или прохождения процедуры входа в систему.
|
||
|
||
C: C (Confidentiality Impact: Complete) — полное нарушение конфиденциальности. Уязвимость позволяет злоумышленнику получить полный доступ к конфиденциальной информации.
|
||
|
||
I: C (Integrity Impact: Complete) — полное нарушение целостности. Атакующий может изменять, подменять или удалять данные без ограничений.
|
||
|
||
A: C (Availability Impact: Complete) — полное нарушение доступности. Эксплуатация уязвимости может привести к полной недоступности системы или отказу в обслуживании.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.9\linewidth]{img/mobile-vulnerabilities-details.png}
|
||
\caption{Развёрнутое описание уязвимости BDU:2023-08587}
|
||
\label{fig:mobile-vulnerabilities-details}
|
||
\end{figure}
|
||
|
||
\newpage
|
||
\phantom{}
|
||
\newpage
|
||
\section{Разработка и исследование системы аутентификации и авторизации}
|
||
|
||
\subsection{Цели и задачи работы}
|
||
|
||
Практическая работа №2 по дисциплине <<Защита информации>> посвящена разработке системы доступа пользователей к конфиденциальным данным и исследованию стойкости паролей к атаке методом грубой силы.
|
||
|
||
Цель работы: разработать систему аутентификации и авторизации пользователей и исследовать стойкость паролей к атаке методом грубой силы.
|
||
|
||
Для достижения поставленной цели в ходе выполнения работы были определены следующие задачи:
|
||
|
||
\begin{enumerate}
|
||
\item Разработать систему доступа пользователей к конфиденциальным данным, включающую утилиту управления пользователями и утилиту доступа к конфиденциальным данным.
|
||
\item Разработать программу взлома паролей методом грубой силы.
|
||
\item Исследовать стойкость паролей в зависимости от их длины при использовании алгоритма хэширования MD5 (индивидуальный вариант задания).
|
||
\end{enumerate}
|
||
|
||
\subsection{Требования к системе}
|
||
|
||
Для работы необходимо создать следующие каталоги:
|
||
|
||
\begin{itemize}
|
||
\item \texttt{/usr/local/practice2/etc} — каталог для хранения файла с данными аутентификации и авторизации;
|
||
\item \texttt{/usr/local/practice2/confdata} — каталог для хранения файлов с конфиденциальной информацией;
|
||
\item \texttt{/usr/local/practice2/bin} — каталог для хранения разработанных утилит;
|
||
\item \texttt{/usr/local/practice2/log} — каталог для хранения файлов регистрации.
|
||
\end{itemize}
|
||
|
||
Права доступа на чтение, запись и выполнение всех каталогов и файлов системы предоставляются только пользователю root.
|
||
|
||
Данные аутентификации хранятся в файле \texttt{/usr/local/practice2/etc/passwd}. Каждая строка соответствует одному пользователю и имеет структуру:
|
||
|
||
\begin{center}
|
||
\texttt{<логин>:<хэш\_пароля>:<идентификатор>:<права>:<ФИО>}
|
||
\end{center}
|
||
|
||
Поддерживаются следующие права доступа: \texttt{r} — чтение, \texttt{w} — запись, \texttt{d} — удаление. Права на файл паролей предоставляются только пользователю root.
|
||
|
||
Пароль должен содержать только символы в кодировке ASCII: буквы A–Z и a–z, цифры 0–9, специальные символы \texttt{!@\#\$\%\^{}\&*()}. Первый символ пароля должен быть буквой.
|
||
|
||
\subsection{Характеристики ПК и среда разработки}
|
||
|
||
Работа выполнялась на персональном компьютере со следующими характеристиками:
|
||
|
||
\begin{itemize}
|
||
\item Процессор: AMD Ryzen 5 5500U
|
||
\item Оперативная память: 16 ГБ
|
||
\item Операционная система: Ubuntu 25.10
|
||
\end{itemize}
|
||
|
||
В качестве среды разработки использовался редактор Cursor. Язык программирования — Python 3.14. Для хэширования паролей используется алгоритм MD5 (индивидуальный вариант задания), реализованный с использованием модуля \texttt{hashlib} стандартной библиотеки Python.
|
||
|
||
\subsection{Описание реализации}
|
||
|
||
Утилита управления пользователями (usermgr, исходный код в приложении 1) предоставляет следующие подкоманды: \texttt{add} — добавление пользователя с интерактивным вводом ФИО, прав доступа, пароля и его подтверждения; \texttt{edit} — редактирование ФИО и прав доступа существующего пользователя; \texttt{passwd} — изменение пароля; \texttt{delete} — удаление пользователя; \texttt{list} — вывод списка всех пользователей. Пароль хранится в виде MD5-хэша (128 бит, 32 шестнадцатеричных символа). Все операции с файлом паролей регистрируются в журнале \texttt{log/usermgr.log}.
|
||
|
||
Утилита доступа к конфиденциальным данным (confaccess, исходный код в приложении 2) при запуске запрашивает логин и пароль. При успешной аутентификации выводится приветствие <<Привет, <ФИО>>> и справка по доступным командам. При вводе неверных данных запрос повторяется. Завершение работы происходит по команде \texttt{exit} или сигналу SIGINT (Ctrl+C). Все попытки входа и действия с конфиденциальными данными регистрируются в журнале \texttt{log/access.log}. Для неинтерактивной проверки учётных данных предусмотрен режим \texttt{--check <логин>}: утилита читает пароли построчно из stdin и выводит 0 или 1 на каждую строку; при совпадении завершает работу с кодом 0.
|
||
|
||
Поддерживаемые команды приведены в таблице~\ref{tab:commands}.
|
||
|
||
\begin{table}[h!]
|
||
\centering
|
||
\caption{Команды утилиты confaccess}
|
||
\label{tab:commands}
|
||
\begin{tabularx}{\textwidth}{llX}
|
||
\toprule
|
||
Команда & Требуемые права & Описание \\
|
||
\midrule
|
||
\texttt{create <file>} & w & Создание нового пустого файла в confdata \\
|
||
\texttt{read <file>} & r & Вывод содержимого файла \\
|
||
\texttt{append <file> <text>} & w & Добавление строки в конец файла \\
|
||
\texttt{copy <src> <dst>} & r, w & Копирование файла в confdata \\
|
||
\texttt{remove <file>} & d & Удаление файла из confdata \\
|
||
\texttt{help} & — & Вывод справки \\
|
||
\texttt{exit} & — & Выход из программы \\
|
||
\bottomrule
|
||
\end{tabularx}
|
||
\end{table}
|
||
|
||
Копирование разрешено только в каталог \texttt{confdata} или внутри него. Копирование из \texttt{confdata} в другие каталоги и перезапись существующих файлов запрещены.
|
||
|
||
Программа взлома паролей (bruteforce, исходный код в приложении 3) не имеет доступа к файлу паролей и выполняет перебор исключительно через утилиту confaccess. При запуске bruteforce создаёт один процесс \texttt{confaccess --check <логин>} и передаёт ему пароли построчно; утилита проверяет каждый пароль (хэширование MD5 и сравнение с данными из \texttt{passwd}) и возвращает результат. Перебор выполняется последовательно, начиная с длины 1. При нахождении совпадения фиксируются найденный пароль, количество итераций и затраченное время. Перебор прекращается при обнаружении пароля, достижении заданной максимальной длины или истечении восьмичасового лимита.
|
||
|
||
\subsection{Развёртывание системы}
|
||
|
||
Для создания структуры каталогов и установки утилит предусмотрен скрипт \texttt{setup.sh} (приложение 4). При запуске с правами суперпользователя скрипт также выставляет ограничительные права доступа. Базовый каталог задаётся переменной окружения \texttt{PRACTICE2\_DIR}; при её отсутствии используется \texttt{/usr/local/practice2}.
|
||
|
||
Установка системы выполняется следующим образом:
|
||
|
||
\begin{verbatim}
|
||
chmod +x setup.sh
|
||
sudo ./setup.sh
|
||
\end{verbatim}
|
||
|
||
Результат выполнения скрипта представлен на рисунке~\ref{fig:lab2-setup}.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.6\linewidth]{img/lab2-setup.png}
|
||
\caption{Результат выполнения скрипта setup.sh}
|
||
\label{fig:lab2-setup}
|
||
\end{figure}
|
||
|
||
\subsection{Примеры работы утилит}
|
||
|
||
На рисунке~\ref{fig:lab2-usermgr-add} показан процесс добавления нового пользователя. На рисунке~\ref{fig:lab2-usermgr-list} — список пользователей после добавления нескольких учётных записей.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth]{img/lab2-usermgr-add.png}
|
||
\caption{Добавление нового пользователя}
|
||
\label{fig:lab2-usermgr-add}
|
||
\end{figure}
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth]{img/lab2-usermgr-list.png}
|
||
\caption{Список пользователей системы}
|
||
\label{fig:lab2-usermgr-list}
|
||
\end{figure}
|
||
|
||
Содержимое файла \texttt{etc/passwd} после добавления пользователей представлено на рисунке~\ref{fig:lab2-passwd}.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=\linewidth]{img/lab2-passwd.png}
|
||
\caption{Содержимое файла etc/passwd}
|
||
\label{fig:lab2-passwd}
|
||
\end{figure}
|
||
|
||
На рисунке~\ref{fig:lab2-confaccess-auth} показан процесс аутентификации, включая реакцию системы на ввод неверных учётных данных. На рисунке~\ref{fig:lab2-confaccess-commands} — пример выполнения команд с проверкой прав доступа.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.65\linewidth]{img/lab2-confaccess-auth.png}
|
||
\caption{Аутентификация в утилите confaccess}
|
||
\label{fig:lab2-confaccess-auth}
|
||
\end{figure}
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.5\linewidth]{img/lab2-confaccess-commands.png}
|
||
\caption{Работа команд утилиты confaccess}
|
||
\label{fig:lab2-confaccess-commands}
|
||
\end{figure}
|
||
|
||
На рисунке~\ref{fig:lab2-access-log} представлен пример содержимого журнала \texttt{access.log} с записями об успешных и неуспешных попытках входа и выполненных операциях.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.6\linewidth]{img/lab2-access-log.png}
|
||
\caption{Содержимое файла журнала access.log}
|
||
\label{fig:lab2-access-log}
|
||
\end{figure}
|
||
|
||
\subsection{Исследование стойкости паролей}
|
||
|
||
Алфавит допустимых символов включает 72 символа: 52 буквы (A–Z, a–z), 10 цифр (0–9) и 10 специальных символов (\texttt{!@\#\$\%\^{}\&*()}). Поскольку первый символ пароля должен быть буквой, для него допустимы только 52 варианта.
|
||
|
||
Максимальное количество итераций для пароля длиной $n$ вычисляется по формуле:
|
||
|
||
\[
|
||
N(n) = 52 \cdot 72^{n-1}
|
||
\]
|
||
|
||
Расчётное максимальное время взлома определяется как $t_{\max}(n) = N(n)\,/\,v$, где $v$ — скорость проверки паролей через утилиту confaccess. Величина $v$ получена по трём запускам программы bruteforce на том же ПК для паролей длиной 2, 3 и~4 символа (хэширование MD5): средняя скорость составила $v \approx 2{,}4 \times 10^4$ проверок в секунду. Столбцы \textit{Эксп. итераций} и \textit{Эксп. время} отражают число попыток и длительность перебора на длине $n$ до нахождения пароля в соответствующем запуске.
|
||
|
||
На рисунке~\ref{fig:lab2-bruteforce} показан пример вывода программы взлома для пароля длиной 3 символа.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=0.5\linewidth]{img/lab2-bruteforce.png}
|
||
\caption{Результат работы программы взлома bruteforce}
|
||
\label{fig:lab2-bruteforce}
|
||
\end{figure}
|
||
|
||
Эксперименты проводились для длин 2, 3 и 4 символов. Для длины 5 расчётное максимальное время при измеренном $v$ составляет около $6 \times 10^4$~с (порядка суток), поэтому полный перебор на практике не выполнялся; для больших длин $t_{\max}$ ещё выше. Результаты приведены в таблице~\ref{tab:bruteforce}.
|
||
|
||
\begin{table}[h!]
|
||
\centering
|
||
\caption{Результаты исследования стойкости паролей (MD5, $v \approx 2{,}4 \times 10^4$ проверок/с)}
|
||
\label{tab:bruteforce}
|
||
\begin{tabularx}{\textwidth}{crrcc}
|
||
\toprule
|
||
Длина & $N$ & $t_{\max}$, с & Эксп. итераций & Эксп. время, с \\
|
||
\midrule
|
||
2 & $3\,744$ & $0{,}16$ & $134$ & $0{,}006$ \\
|
||
3 & $269\,568$ & $11$ & $9\,638$ & $0{,}40$ \\
|
||
4 & $19\,408\,896$ & $818$ & $693\,926$ & $30{,}5$ \\
|
||
5 & $1\,397\,440\,512$ & $58\,900$ & \multicolumn{2}{c}{не проводился} \\
|
||
6 & $1{,}01 \times 10^{11}$ & $4{,}24 \times 10^6$ & \multicolumn{2}{c}{не проводился} \\
|
||
7 & $7{,}24 \times 10^{12}$ & ${\approx}3{,}05 \times 10^{8}$ & \multicolumn{2}{c}{не проводился} \\
|
||
8 & $5{,}22 \times 10^{14}$ & ${\approx}2{,}2 \times 10^{10}$ & \multicolumn{2}{c}{не проводился} \\
|
||
\bottomrule
|
||
\end{tabularx}
|
||
\end{table}
|
||
|
||
\subsection{Выводы}
|
||
|
||
В ходе практической работы была разработана система доступа пользователей к конфиденциальным данным, включающая утилиту управления пользователями, утилиту доступа и программу взлома паролей методом грубой силы. Реализован механизм хэширования паролей на основе алгоритма MD5 (индивидуальный вариант задания), система разграничения прав доступа и журналирование всех операций.
|
||
|
||
Теоретический анализ показал, что количество итераций, необходимых для полного перебора паролей, экспоненциально возрастает с увеличением их длины. Экспериментальное исследование позволило оценить реальную скорость перебора и подтвердить теоретические оценки. Полученные результаты демонстрируют, что использование паролей длиной 6 символов и более существенно затрудняет атаку методом грубой силы.
|
||
|
||
\newpage
|
||
\section{Реализация моделей дискреционного и мандатного управления доступом}
|
||
|
||
\subsection{Актуальность темы}
|
||
|
||
Модели управления доступом являются фундаментом систем защиты информации. Дискреционное управление (DAC) позволяет владельцам объектов гибко назначать права, однако не защищает от утечки информации через легитимных пользователей. Мандатное управление (MAC) на основе меток конфиденциальности обеспечивает принудительный контроль потока информации и применяется в системах с повышенными требованиями к защите. Изучение и практическая реализация обеих моделей в контексте дисциплины <<Защита информации>> позволяет закрепить понимание механизмов разграничения доступа и их ограничений.
|
||
|
||
\subsection{Цели и задачи работы}
|
||
|
||
Практическая работа №3 по дисциплине <<Защита информации>> посвящена реализации моделей дискреционного (DAC) и мандатного (MAC) управления доступом на базе системы, разработанной в практической работе №2.
|
||
|
||
Цель работы: изучить особенности моделей DAC и MAC и реализовать их в рамках существующей системы аутентификации и авторизации.
|
||
|
||
Задачи работы:
|
||
\begin{enumerate}
|
||
\item Изучить особенности дискреционного управления доступом и модель Харрисона–Руззо–Ульмана.
|
||
\item Разработать систему DAC с владением объектами, произвольным назначением прав и контролем на основе матрицы (списка) доступа.
|
||
\item Изучить особенности мандатного управления доступом и модель Белла–Лападулы.
|
||
\item Разработать систему MAC с метками безопасности для субъектов и объектов и свойствами модели Белла–Лападулы.
|
||
\end{enumerate}
|
||
|
||
\subsection{Краткие сведения о DAC и MAC}
|
||
|
||
\textbf{Дискреционное управление доступом (DAC)} основано на произвольном назначении прав владельцем объекта. Каждый объект имеет владельца, который может назначать и передавать права доступа другим субъектам. Контроль осуществляется на основе матрицы доступа или списков доступа (ACL), где для каждой пары (субъект, объект) указаны разрешённые операции. Модель Харрисона–Руззо–Ульмана формализует операции над матрицей доступа (создание/удаление субъектов и объектов, выдача и отзыв прав).
|
||
|
||
\textbf{Мандатное управление доступом (MAC)} основано на метках конфиденциальности, назначаемых суперпользователем. Субъекты и объекты получают метки (уровни), и доступ определяется правилами, не зависящими от воли пользователей. Модель Белла–Лападулы реализует два основных свойства: <<нет чтения сверху>> (субъект может читать только объекты с уровнем не выше своего) и <<нет записи вниз>> (субъект может записывать только в объекты с уровнем не ниже своего), что предотвращает утечку информации с высокого уровня на низкий.
|
||
|
||
\subsection{Требования к разрабатываемым системам}
|
||
|
||
Структура каталогов аналогична работе №2, но с базовым путём \texttt{/usr/local/practice3} (переменная \texttt{PRACTICE3\_DIR}):
|
||
|
||
\begin{itemize}
|
||
\item \texttt{etc/} — файлы настроек: \texttt{passwd}, \texttt{access\_mode}, \texttt{acl}, \texttt{subject\_labels}, \texttt{object\_labels};
|
||
\item \texttt{confdata/} — конфиденциальные файлы;
|
||
\item \texttt{bin/} — утилиты;
|
||
\item \texttt{log/} — журналы.
|
||
\end{itemize}
|
||
|
||
\textbf{DAC:} у каждого объекта — владелец; владелец может назначать права через команду \texttt{grant}; контроль по списку доступа (ACL) в формате \\ \texttt{путь:владелец:пользователь:права,...}.
|
||
|
||
\textbf{MAC:} метки безопасности (0 — несекретно, 1 — ДСП, 2 — секретно) назначаются суперпользователем через \texttt{usermgr}; субъекты не могут менять метки; проверка по свойствам Белла–Лападулы.
|
||
|
||
Режим проверки (BOTH — DAC и MAC, DAC\_ONLY, MAC\_ONLY) задаётся администратором через \texttt{usermgr set-mode} и доступен только root.
|
||
|
||
\subsection{Описание реализации}
|
||
|
||
Система построена на базе кода из практической работы №2. Утилита \texttt{usermgr} расширена админскими подкомандами (приложение 5): \texttt{set-mode BOTH|DAC\_ONLY|MAC\_ONLY} — установка режима проверки; \texttt{show-mode} — вывод текущего режима; \texttt{edit <логин> --label <0|1|2>} — установка метки субъекта; \texttt{set-label <путь> <0|1|2>} — установка метки объекта. Все админские команды требуют прав root.
|
||
|
||
Утилита \texttt{confaccess} (приложение 6) полностью переработана. При \texttt{create} объект получает владельца (текущий пользователь) и запись в ACL; при операциях \texttt{read}, \texttt{append}, \texttt{remove} проверяется наличие соответствующего права в ACL. Команда \texttt{grant <пользователь> <путь> <права>} доступна только владельцу объекта. Для MAC при каждой операции проверяются свойства Белла–Лападулы: чтение разрешено при уровне субъекта $\ge$ уровня объекта; запись (append, create, remove) — при уровне субъекта $\le$ уровня объекта. Конфигурация путей вынесена в \texttt{config.py} (приложение 7). Скрипт \texttt{setup.sh} (приложение 8) создаёт структуру для practice3 и инициализирует файлы \texttt{access\_mode}, \texttt{acl}, \texttt{subject\_labels}, \texttt{object\_labels}.
|
||
|
||
\subsection{Развёртывание и примеры работы}
|
||
|
||
Установка выполняется аналогично работе №2:
|
||
|
||
\begin{verbatim}
|
||
chmod +x setup.sh
|
||
PRACTICE3_DIR=/tmp/practice3 ./setup.sh
|
||
\end{verbatim}
|
||
|
||
Результат выполнения скрипта представлен на рисунке~\ref{fig:lab3-setup}.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
% Заглушка: добавить скриншот img/lab3-setup.png
|
||
\includegraphics[width=0.6\linewidth]{img/lab3-setup.png}
|
||
\caption{Результат выполнения скрипта setup.sh (practice3)}
|
||
\label{fig:lab3-setup}
|
||
\end{figure}
|
||
|
||
Примеры работы утилит: переключение режима \texttt{usermgr set-mode}, установка меток, работа \texttt{confaccess} с командами \texttt{create}, \texttt{grant}, \texttt{read} — на рисунках~\ref{fig:lab3-usermgr} и~\ref{fig:lab3-confaccess}.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
% Заглушка: добавить скриншот img/lab3-usermgr-mode.png
|
||
\includegraphics[width=0.6\linewidth]{img/lab3-usermgr-mode.png}
|
||
\caption{Работа usermgr: set-mode, show-mode, set-label}
|
||
\label{fig:lab3-usermgr}
|
||
\end{figure}
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
% Заглушка: добавить скриншот img/lab3-confaccess.png
|
||
\includegraphics[width=0.6\linewidth]{img/lab3-confaccess.png}
|
||
\caption{Работа confaccess: create, grant, read}
|
||
\label{fig:lab3-confaccess}
|
||
\end{figure}
|
||
|
||
\subsection{Примеры содержимого служебных файлов}
|
||
|
||
\textbf{Список доступа (ACL) для DAC} — файл \texttt{etc/acl}. Каждая строка: \texttt{путь:владелец:пользователь1:права1,пользователь2:права2,...}. Пример:
|
||
|
||
\begin{verbatim}
|
||
report.txt:alice:alice:rwd,bob:r
|
||
secret.txt:bob:bob:rwd
|
||
\end{verbatim}
|
||
|
||
Владелец \texttt{report.txt} — alice (полные права rwd); bob имеет только чтение (r).
|
||
|
||
\textbf{Метки конфиденциальности для MAC} — файлы \texttt{etc/subject\_labels} (субъекты) и \texttt{etc/object\_labels} (объекты). Формат: \texttt{идентификатор:уровень}, где уровень — 0 (несекретно), 1 (ДСП), 2 (секретно). Пример:
|
||
|
||
\begin{verbatim}
|
||
# subject_labels
|
||
alice:1
|
||
bob:0
|
||
|
||
# object_labels
|
||
report.txt:0
|
||
secret.txt:2
|
||
\end{verbatim}
|
||
|
||
Примеры содержимого файлов ACL и меток представлены на рисунках~\ref{fig:lab3-acl} и~\ref{fig:lab3-labels}.
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
% Заглушка: добавить скриншот img/lab3-acl.png
|
||
\includegraphics[width=0.7\linewidth]{img/lab3-acl.png}
|
||
\caption{Содержимое файла etc/acl (список доступа DAC)}
|
||
\label{fig:lab3-acl}
|
||
\end{figure}
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
% Заглушка: добавить скриншот img/lab3-labels.png
|
||
\includegraphics[width=0.7\linewidth]{img/lab3-labels.png}
|
||
\caption{Содержимое файлов subject\_labels и object\_labels (метки MAC)}
|
||
\label{fig:lab3-labels}
|
||
\end{figure}
|
||
|
||
\subsection{Выводы}
|
||
|
||
В ходе практической работы №3 на базе системы из работы №2 реализованы модели дискреционного и мандатного управления доступом. DAC реализован через список доступа (ACL) с владельцами объектов и командой \texttt{grant} для произвольного назначения прав. MAC реализован на основе модели Белла–Лападулы с тремя уровнями меток и проверкой свойств <<нет чтения сверху>> и <<нет записи вниз>>. Режимы проверки (BOTH, DAC\_ONLY, MAC\_ONLY) позволяют гибко настраивать систему; переключение доступно только администратору (root). Полученный опыт демонстрирует принципиальные различия между дискреционным и мандатным подходами к управлению доступом и их практическую реализацию в информационных системах.
|
||
|
||
|
||
\newpage
|
||
\section{Межсетевое экранирование средствами iptables}
|
||
|
||
\subsection{Актуальность темы}
|
||
|
||
Межсетевое экранирование является одним из базовых механизмов сетевой защиты информационных систем. Локальный хостовый межсетевой экран позволяет минимизировать поверхность атаки, явно разрешая только необходимый трафик и блокируя все остальные соединения по принципу <<запрещено всё, что не разрешено>>. Практическая настройка \texttt{iptables} в рамках курса <<Защита информации>> позволяет закрепить представление о пакетной фильтрации, ролях цепочек \texttt{INPUT}, \texttt{OUTPUT}, \texttt{FORWARD} и о проверке работоспособности правил на реальном стенде.
|
||
|
||
\subsection{Цели и задачи работы}
|
||
|
||
Цель работы: получение базовых знаний по настройке межсетевого экрана в ОС Linux и реализация заданной политики доступа.
|
||
|
||
Задачи работы:
|
||
\begin{enumerate}
|
||
\item Изучить межсетевой экран \texttt{iptables}: принципы обработки пакетов, основные цепочки, действия по умолчанию, параметры правил фильтрации.
|
||
\item Развернуть лабораторный стенд на базе виртуальных машин VirtualBox.
|
||
\item Реализовать заданную политику доступа: разрешить loopback, DNS, исходящий ping, входящий ping только от конкретного адреса, HTTP/HTTPS; заблокировать всё остальное.
|
||
\item Проверить корректность реализации политики.
|
||
\item Проконтролировать прохождение пакетов утилитой \texttt{tcpdump}.
|
||
\end{enumerate}
|
||
|
||
\subsection{Схема стенда}
|
||
|
||
Стенд реализован на базе двух виртуальных машин VirtualBox с ОС Ubuntu Server 22.04. Каждая машина имеет два сетевых адаптера:
|
||
\begin{itemize}
|
||
\item \textbf{Adapter~1 (NAT)} --- доступ в Интернет (DNS, HTTP/HTTPS, ICMP);
|
||
\item \textbf{Adapter~2 (Internal Network <<intnet>>)} --- изолированная сеть \texttt{192.168.100.0/24} для связи между машинами.
|
||
\end{itemize}
|
||
|
||
Схема стенда представлена на рисунке~\ref{fig:lab4-topology}, адресация узлов --- в таблице~\ref{tab:lab4-addr}.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab4-stand.png}
|
||
\caption{Схема лабораторного стенда}
|
||
\label{fig:lab4-topology}
|
||
\end{figure}
|
||
|
||
\begin{table}[H]
|
||
\centering
|
||
\caption{Адресация узлов стенда}
|
||
\label{tab:lab4-addr}
|
||
\begin{tabularx}{\textwidth}{l l l X}
|
||
\toprule
|
||
Узел & Интерфейс & IP-адрес & Назначение \\
|
||
\midrule
|
||
\multirow{2}{*}{firewall-host} & enp0s3 (NAT) & 10.0.2.15/24 & Доступ в Интернет \\
|
||
& enp0s8 (intnet) & 192.168.100.1/24 & Внутренняя сеть \\
|
||
\midrule
|
||
\multirow{2}{*}{external-client} & enp0s3 (NAT) & 10.0.2.15/24 & Доступ в Интернет \\
|
||
& enp0s8 (intnet) & 192.168.100.2/24 & Внутренняя сеть \\
|
||
\bottomrule
|
||
\end{tabularx}
|
||
\end{table}
|
||
|
||
DNS-запросы обрабатываются службой \texttt{systemd-resolved} (\texttt{127.0.0.53}), перенаправляющей их DNS-серверу NAT-шлюза VirtualBox (\texttt{10.0.2.3}). Управление виртуальными машинами осуществлялось по SSH через проброс портов VirtualBox.
|
||
|
||
\subsection{Принципы обработки пакетов в \texttt{iptables}}
|
||
|
||
Утилита \texttt{iptables} организует правила фильтрации в виде таблиц и цепочек. В работе использовалась таблица \texttt{filter} (по умолчанию), содержащая три встроенные цепочки:
|
||
\begin{itemize}
|
||
\item \texttt{INPUT} --- входящие пакеты, адресованные локальным процессам;
|
||
\item \texttt{OUTPUT} --- исходящие пакеты локальных процессов;
|
||
\item \texttt{FORWARD} --- транзитные пакеты (маршрутизация).
|
||
\end{itemize}
|
||
|
||
Пакет последовательно сравнивается с правилами цепочки. При совпадении выполняется действие: \texttt{ACCEPT} (пропустить), \texttt{DROP} (молча отбросить) или \texttt{REJECT} (отбросить с уведомлением). Если ни одно правило не сработало, применяется политика по умолчанию.
|
||
|
||
Модуль \texttt{conntrack} позволяет отслеживать состояния соединений. Правило с параметром \texttt{-{}-ctstate ESTABLISHED,RELATED} пропускает ответные пакеты уже установленных соединений без необходимости дублировать на цепочке \texttt{INPUT} отдельные правила по исходным портам для DNS, HTTP/HTTPS и для \texttt{echo-reply} на исходящий \texttt{ping}: при расположении этого правила \textbf{выше} узких правил ответный трафик срабатывает в нём, а счётчики у гипотетических строк \texttt{INPUT} с~\texttt{-{}-sport~53}/\texttt{80}/\texttt{443} оставались~бы нулевыми. На~\texttt{INPUT} явно заданы только новые входящие сценарии: SSH (для стенда), loopback и входящий \texttt{echo-request} с разрешённого адреса \texttt{192.168.100.2}.
|
||
|
||
\subsection{Реализация политики фильтрации}
|
||
|
||
Перед настройкой все существующие правила были сброшены:
|
||
\begin{verbatim}
|
||
sudo iptables -F && sudo iptables -X
|
||
sudo iptables -t nat -F && sudo iptables -t mangle -F
|
||
\end{verbatim}
|
||
|
||
Примеры команд добавления правил:
|
||
|
||
Разрешение loopback-трафика (\texttt{-i~lo} --- входящий интерфейс loopback):
|
||
\begin{verbatim}
|
||
sudo iptables -A INPUT -i lo -j ACCEPT
|
||
\end{verbatim}
|
||
|
||
Разрешение DNS-запросов (\texttt{-p~udp}, порт~53):
|
||
\begin{verbatim}
|
||
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
|
||
\end{verbatim}
|
||
|
||
Разрешение входящего ping только от конкретного адреса (\texttt{-{}-icmp-type echo-request} --- тип~8, параметры \texttt{-s} и \texttt{-d} --- адреса источника и назначения):
|
||
\begin{verbatim}
|
||
sudo iptables -A INPUT -p icmp --icmp-type echo-request \
|
||
-s 192.168.100.2 -d 192.168.100.1 -j ACCEPT
|
||
\end{verbatim}
|
||
|
||
Полный набор правил, реализующий заданную политику доступа:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
# SSH (для сохранения удалённого доступа к стенду)
|
||
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
|
||
sudo iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
|
||
# Уже установленные и связанные соединения
|
||
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
|
||
sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
|
||
# Loopback
|
||
sudo iptables -A INPUT -i lo -j ACCEPT
|
||
sudo iptables -A OUTPUT -o lo -j ACCEPT
|
||
# DNS (UDP и TCP, порт 53; ответы на INPUT через ESTABLISHED,RELATED)
|
||
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
|
||
sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
|
||
# HTTP и HTTPS (ответы на INPUT через ESTABLISHED,RELATED)
|
||
sudo iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
|
||
sudo iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
|
||
# Исходящий ping (echo-reply на INPUT через ESTABLISHED,RELATED)
|
||
sudo iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
|
||
# Входящий ping только от 192.168.100.2
|
||
sudo iptables -A INPUT -p icmp --icmp-type echo-request \
|
||
-s 192.168.100.2 -d 192.168.100.1 -j ACCEPT
|
||
sudo iptables -A OUTPUT -p icmp --icmp-type echo-reply \
|
||
-s 192.168.100.1 -d 192.168.100.2 -j ACCEPT
|
||
# Политики по умолчанию
|
||
sudo iptables -P INPUT DROP
|
||
sudo iptables -P OUTPUT DROP
|
||
sudo iptables -P FORWARD DROP
|
||
\end{verbatim}
|
||
}
|
||
|
||
Правило для SSH не входит в задание, но необходимо для сохранения удалённого доступа; оно добавлено до включения политик \texttt{DROP}. Отдельные правила \texttt{INPUT} с~\texttt{-{}-sport} для ответов DNS/HTTP(S) и с~\texttt{echo-reply} для исходящего \texttt{ping} не используются: этот трафик обрабатывается правилом \texttt{ESTABLISHED,RELATED}.
|
||
|
||
Итоговое состояние таблицы \texttt{filter} (\texttt{iptables -L -n -v -{}-line-numbers}):
|
||
|
||
{\scriptsize
|
||
\begin{verbatim}
|
||
Chain INPUT (policy DROP 0 packets, 0 bytes)
|
||
num pkts bytes target prot in source destination
|
||
1 162 10124 ACCEPT tcp * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
|
||
2 312 142K ACCEPT all * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
|
||
3 12 780 ACCEPT all lo 0.0.0.0/0 0.0.0.0/0
|
||
4 8 672 ACCEPT icmp * 192.168.100.2 192.168.100.1 icmptype 8
|
||
|
||
Chain FORWARD (policy DROP 0 packets, 0 bytes)
|
||
|
||
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
|
||
num pkts bytes target prot out source destination
|
||
1 119 21028 ACCEPT tcp * 0.0.0.0/0 0.0.0.0/0 tcp spt:22
|
||
2 289 33680 ACCEPT all * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
|
||
3 12 780 ACCEPT all * lo 0.0.0.0/0 0.0.0.0/0
|
||
4 28 1982 ACCEPT udp * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
|
||
5 0 0 ACCEPT tcp * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
|
||
6 4 240 ACCEPT tcp * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
|
||
7 10 600 ACCEPT tcp * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
|
||
8 4 336 ACCEPT icmp * 0.0.0.0/0 0.0.0.0/0 icmptype 8
|
||
9 8 672 ACCEPT icmp * 192.168.100.1 192.168.100.2 icmptype 0
|
||
\end{verbatim}
|
||
}
|
||
|
||
\subsection{Проверка реализованной политики}
|
||
|
||
\textbf{DNS.} Команда \texttt{nslookup} на firewall-host успешно разрешает имена:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
$ nslookup example.com
|
||
Server: 127.0.0.53
|
||
Address: 127.0.0.53#53
|
||
|
||
Non-authoritative answer:
|
||
Name: example.com
|
||
Address: 104.18.26.120
|
||
Name: example.com
|
||
Address: 104.18.27.120
|
||
\end{verbatim}
|
||
}
|
||
|
||
\textbf{HTTP/HTTPS.} Утилита \texttt{curl} успешно получает ответ от внешнего сервера как по HTTP, так и по HTTPS:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
$ curl http://example.com
|
||
<!doctype html><html lang="en"><head><title>Example Domain
|
||
</title>...</html>
|
||
|
||
$ curl https://example.com
|
||
<!doctype html><html lang="en"><head><title>Example Domain
|
||
</title>...</html>
|
||
\end{verbatim}
|
||
}
|
||
|
||
\textbf{Исходящий ping.} Защищаемый хост пингует внешние адреса:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
$ ping -c 4 8.8.8.8
|
||
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
|
||
64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=12.0 ms
|
||
64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=11.9 ms
|
||
64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=11.3 ms
|
||
64 bytes from 8.8.8.8: icmp_seq=4 ttl=255 time=11.4 ms
|
||
|
||
--- 8.8.8.8 ping statistics ---
|
||
4 packets transmitted, 4 received, 0% packet loss
|
||
\end{verbatim}
|
||
}
|
||
|
||
\textbf{Входящий ping от разрешённого адреса.} С external-client (\texttt{192.168.100.2}) ping проходит:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
arity@external-client:~$ ping -c 4 192.168.100.1
|
||
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.433 ms
|
||
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.369 ms
|
||
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.440 ms
|
||
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=0.398 ms
|
||
|
||
--- 192.168.100.1 ping statistics ---
|
||
4 packets transmitted, 4 received, 0% packet loss
|
||
\end{verbatim}
|
||
}
|
||
|
||
\textbf{Блокировка запрещённого трафика.} На узле \texttt{external-client} запущен \texttt{python3 -m http.server 8080}; исходящий TCP на порт~8080 в политику не входит (разрешены только 53, 80, 443), поэтому с \texttt{firewall-host} соединение не устанавливается:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
$ timeout 5 nc -vz 192.168.100.2 8080
|
||
nc: connect to 192.168.100.2 port 8080 (tcp) failed: Connection timed out
|
||
\end{verbatim}
|
||
}
|
||
|
||
\subsection{Контроль трафика средствами \texttt{tcpdump}}
|
||
|
||
Для подтверждения прохождения пакетов использовалась утилита \texttt{tcpdump}. Ниже приведён вывод при выполнении \texttt{ping} от external-client к firewall-host:
|
||
|
||
{\footnotesize
|
||
\begin{verbatim}
|
||
$ sudo tcpdump -i any -n icmp
|
||
18:26:20.960046 enp0s8 In IP
|
||
192.168.100.2 > 192.168.100.1:
|
||
ICMP echo request, id 2, seq 1, length 64
|
||
18:26:20.960119 enp0s8 Out IP
|
||
192.168.100.1 > 192.168.100.2:
|
||
ICMP echo reply, id 2, seq 1, length 64
|
||
18:26:21.990542 enp0s8 In IP
|
||
192.168.100.2 > 192.168.100.1:
|
||
ICMP echo request, id 2, seq 2, length 64
|
||
18:26:21.990587 enp0s8 Out IP
|
||
192.168.100.1 > 192.168.100.2:
|
||
ICMP echo reply, id 2, seq 2, length 64
|
||
...
|
||
8 packets captured
|
||
\end{verbatim}
|
||
}
|
||
|
||
На интерфейсе \texttt{enp0s8} видны входящие ICMP echo-request от \texttt{192.168.100.2} и исходящие echo-reply, что подтверждает работу правила входящего ping от разрешённого адреса.
|
||
|
||
Аналогичным образом были зафиксированы DNS-пакеты (\texttt{sudo tcpdump -i any -n port 53}): запрос от \texttt{127.0.0.1} к \texttt{127.0.0.53} через loopback, перенаправление к \texttt{10.0.2.3} через \texttt{enp0s3} и получение ответа. При выполнении \texttt{curl http://example.com} вывод \texttt{tcpdump} с фильтром \texttt{tcp port 80} зафиксировал трёхстороннее TCP-рукопожатие (SYN, SYN-ACK, ACK), HTTP-запрос \texttt{GET / HTTP/1.1} и ответ \texttt{HTTP/1.1 200 OK}, подтверждая корректную работу правила для порта~80.
|
||
|
||
\subsection{Выводы}
|
||
|
||
В ходе практической работы №4 на стенде из двух виртуальных машин VirtualBox настроена политика межсетевого экранирования средствами \texttt{iptables}. Реализована схема с политикой \texttt{DROP} по умолчанию и разрешающими правилами для loopback, DNS, исходящего ping, входящего ping от адреса \texttt{192.168.100.2} и HTTP/HTTPS; ответный трафик по этим сценариям на цепочке \texttt{INPUT} обрабатывается правилом \texttt{ESTABLISHED,RELATED}. Экспериментальная проверка подтвердила пропуск разрешённого трафика и блокировку соединений, не описанных в политике. Анализ трафика утилитой \texttt{tcpdump} продемонстрировал соответствие наблюдаемой сетевой активности заданным правилам фильтрации.
|
||
|
||
|
||
\newpage
|
||
\section{Разработка клиент-серверного приложения для конфиденциального обмена сообщениями}
|
||
|
||
\subsection{Актуальность темы}
|
||
|
||
Обеспечение конфиденциальности и целостности данных при передаче по сети является одной из ключевых задач информационной безопасности. Даже при использовании защищённых протоколов транспортного уровня понимание механизмов симметричного шифрования и контроля целостности на уровне приложения позволяет проектировать системы с дополнительным эшелоном защиты. Практическая реализация клиент-серверного приложения с шифрованием и хэш-контролем в рамках курса <<Защита информации>> закрепляет навыки работы с криптографическими примитивами и демонстрирует их влияние на передаваемый трафик.
|
||
|
||
\subsection{Цели и задачи работы}
|
||
|
||
Цель работы: разработка клиент-серверного приложения для обмена короткими сообщениями по протоколу TCP с обеспечением шифрования и контроля целостности.
|
||
|
||
Задачи работы:
|
||
\begin{enumerate}
|
||
\item Получить базовые знания по использованию криптографических функций библиотеки \texttt{cryptography} в Python.
|
||
\item Разработать клиент-серверное приложение для обмена шифрованными сообщениями с контролем целостности.
|
||
\item Проверить работу приложения в различных режимах, в том числе с помощью программы анализа трафика \texttt{tcpdump}.
|
||
\end{enumerate}
|
||
|
||
\subsection{Описание алгоритма шифрования}
|
||
|
||
\textbf{3DES (Triple DES)} — симметричный блочный шифр, основанный на трёхкратном применении алгоритма DES в режиме EDE (Encrypt–Decrypt–Encrypt) с тремя независимыми подключами. Размер блока — 64 бита (8 байт), длина ключа — 192 бита (24 байта, из которых 168 бит являются эффективными ключевыми битами, а оставшиеся 24 бита — биты чётности). Несмотря на то что 3DES считается устаревшим и уступает AES по производительности, он по-прежнему обеспечивает достаточный уровень стойкости для учебных задач.
|
||
|
||
В разработанном приложении используется режим сцепления блоков \textbf{CBC} (Cipher Block Chaining): каждый блок открытого текста перед шифрованием складывается по модулю 2 с предыдущим блоком шифротекста (для первого блока — с вектором инициализации IV). Это обеспечивает зависимость каждого блока шифротекста от всех предшествующих блоков, затрудняя анализ повторяющихся фрагментов. Дополнение до границы блока выполняется по схеме PKCS7.
|
||
|
||
\textbf{Шифрование с затравкой (солью).} Для каждого сообщения генерируется случайная 16-байтовая затравка (salt). Ключ 3DES длиной 24 байта вычисляется как первые 24 байта хэша SHA-256 от конкатенации мастер-ключа из файла и затравки: $K_{\mathrm{3DES}} = \mathrm{SHA\text{-}256}(K_{\mathrm{file}} \mathbin\| \mathrm{salt})[{:}24]$. Кроме того, для каждого сообщения генерируется случайный 8-байтовый IV. Затравка и IV передаются вместе с шифротекстом в открытом виде, что позволяет получателю воспроизвести ключ. Благодаря уникальности затравки и IV одинаковые открытые тексты порождают различные шифротексты, что исключает атаки на основе повторения.
|
||
|
||
\textbf{Контроль целостности} реализован с помощью хэш-функции MD5 для открытого текста сообщения (пункт~2.4 задания: алгоритм хэширования в соответствии с индивидуальным заданием, как в практической работе №2). При включённой опции \texttt{-{}-integrity} отправитель вычисляет MD5-хэш открытого текста и передаёт его вместе с данными. Получатель вычисляет MD5 самостоятельно и сравнивает с полученным значением; при расхождении выводится предупреждение о нарушении целостности. Выработка 24-байтового ключа 3DES из файлового ключа и соли, напротив, выполняется через SHA-256 и не входит в требование п.~2.4 о хэше сообщения.
|
||
|
||
\textbf{HMAC-SHA256.} Дополнительно реализован режим HMAC (Hash-based Message Authentication Code) на основе SHA-256: $\mathrm{HMAC} = \mathrm{HMAC\text{-}SHA256}(K_{\mathrm{file}},\; \mathrm{plaintext} \mathbin\| \mathrm{salt})$. В отличие от дайджеста в режиме \texttt{-{}-integrity}, HMAC использует секретный ключ и обеспечивает аутентификацию отправителя. Режимы \texttt{-{}-integrity} (MD5 дайджест сообщения) и \texttt{-{}-hmac} (HMAC-SHA256) взаимоисключающие.
|
||
|
||
\subsection{Описание реализации}
|
||
|
||
Приложение реализовано на языке Python~3.14 в виде единого файла \texttt{main.py} (исходный код приведён в приложении~9). Для криптографических операций используется библиотека \texttt{cryptography}. Управление зависимостями осуществляется менеджером \texttt{uv}.
|
||
|
||
\textbf{Протокол обмена.} Сообщения передаются по TCP в формате: 4~байта длины (big-endian) + JSON-объект. Структура JSON-объекта:
|
||
|
||
\begin{verbatim}
|
||
{
|
||
"encrypted": true/false,
|
||
"salt": "hex (16 байт)",
|
||
"iv": "hex (8 байт)",
|
||
"data": "hex шифротекст / открытый текст",
|
||
"hash": "MD5 hex (если включён --integrity)"
|
||
}
|
||
\end{verbatim}
|
||
|
||
\textbf{Полнодуплексный обмен} обеспечивается двумя потоками: один читает ввод пользователя и отправляет сообщения, второй принимает входящие сообщения и выводит их на экран.
|
||
|
||
\textbf{Режимы запуска} задаются ключами командной строки: \texttt{-{}-encrypt} включает шифрование 3DES-CBC, \texttt{-{}-integrity} включает контроль целостности на основе MD5, \texttt{-{}-hmac} включает HMAC-SHA256 (несовместим с \texttt{-{}-integrity}), \texttt{-{}-test-integrity} активирует режим отправки сообщений с заведомо некорректным хэшем или HMAC (требует \texttt{-{}-integrity} или \texttt{-{}-hmac}).
|
||
|
||
\textbf{Защита ключа.} Мастер-ключ считывается из файла (по умолчанию \texttt{key.txt}). При запуске программа проверяет права доступа к файлу ключа и завершает работу с ошибкой, если файл доступен для чтения группе или другим пользователям (права более открытые, чем \texttt{600}).
|
||
|
||
\subsection{Команды сборки и запуска}
|
||
|
||
Установка зависимостей:
|
||
\begin{verbatim}
|
||
uv sync
|
||
\end{verbatim}
|
||
|
||
Создание файла ключа:
|
||
\begin{verbatim}
|
||
openssl rand -hex 32 > key.txt
|
||
chmod 600 key.txt
|
||
\end{verbatim}
|
||
|
||
Запуск сервера и клиента (примеры):
|
||
\begin{verbatim}
|
||
uv run main.py server --port 9000
|
||
uv run main.py client 127.0.0.1 9000
|
||
|
||
uv run main.py server --port 9000 --encrypt
|
||
uv run main.py client 127.0.0.1 9000 --encrypt
|
||
|
||
uv run main.py server --port 9000 --encrypt --integrity
|
||
uv run main.py client 127.0.0.1 9000 --encrypt --integrity
|
||
\end{verbatim}
|
||
|
||
\subsection{Проверка работы приложения}
|
||
|
||
\subsubsection{Передача сообщений без шифрования}
|
||
|
||
При запуске без флагов сообщения передаются открытым текстом. На рисунке~\ref{fig:lab5-plain} показан вывод серверной и клиентской частей приложения.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth]{img/lab5-plain.png}
|
||
\caption{Обмен сообщениями без шифрования}
|
||
\label{fig:lab5-plain}
|
||
\end{figure}
|
||
|
||
Анализ трафика утилитой \texttt{tcpdump} (рис.~\ref{fig:lab5-plain-tcpdump}) подтверждает, что текст сообщения передаётся в открытом виде и может быть прочитан непосредственно из дампа пакетов.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-plain-tcpdump.png}
|
||
\caption{Дамп трафика (\texttt{tcpdump}) при передаче без шифрования — текст виден}
|
||
\label{fig:lab5-plain-tcpdump}
|
||
\end{figure}
|
||
|
||
\subsubsection{Передача сообщений с шифрованием}
|
||
|
||
При включённой опции \texttt{-{}-encrypt} сообщения шифруются алгоритмом 3DES-CBC с затравкой. На рисунке~\ref{fig:lab5-enc} показан вывод приложения: видны параметры шифрования (соль, производный ключ, IV, шифротекст) и результат расшифровки.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-enc.png}
|
||
\caption{Обмен сообщениями с шифрованием 3DES-CBC}
|
||
\label{fig:lab5-enc}
|
||
\end{figure}
|
||
|
||
Дамп трафика (рис.~\ref{fig:lab5-enc-tcpdump}) показывает, что в пакетах присутствует только шифротекст в виде hex-строк; читаемый текст сообщения отсутствует.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-enc-tcpdump.png}
|
||
\caption{Дамп трафика при передаче с шифрованием — текст не виден}
|
||
\label{fig:lab5-enc-tcpdump}
|
||
\end{figure}
|
||
|
||
\subsubsection{Шифрование с контролем целостности}
|
||
|
||
При одновременном использовании флагов \texttt{-{}-encrypt} и \texttt{-{}-integrity} к зашифрованному сообщению добавляется MD5-хэш открытого текста. На стороне получателя после расшифровки вычисляется собственный MD5 и сравнивается с полученным (рис.~\ref{fig:lab5-enc-int}).
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-enc-int.png}
|
||
\caption{Обмен сообщениями с шифрованием и контролем целостности}
|
||
\label{fig:lab5-enc-int}
|
||
\end{figure}
|
||
|
||
\subsubsection{Тестирование контроля целостности с некорректным хэшем}
|
||
|
||
В режиме \texttt{-{}-test-integrity} отправитель намеренно передаёт некорректный хэш. Получатель обнаруживает расхождение и выводит предупреждение (рис.~\ref{fig:lab5-test-int}).
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-test-int.png}
|
||
\caption{Обнаружение некорректного хэш-значения}
|
||
\label{fig:lab5-test-int}
|
||
\end{figure}
|
||
|
||
\subsubsection{Демонстрация шифрования с затравкой}
|
||
|
||
При отправке одного и того же сообщения дважды шифротексты различаются благодаря случайной затравке и IV (рис.~\ref{fig:lab5-salt}).
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-salt.png}
|
||
\caption{Разные шифротексты для одинаковых сообщений (эффект затравки)}
|
||
\label{fig:lab5-salt}
|
||
\end{figure}
|
||
|
||
\subsubsection{Контроль целостности и аутентификация с HMAC-SHA256}
|
||
|
||
При использовании флага \texttt{-{}-hmac} вместо \texttt{-{}-integrity} к каждому сообщению прикладывается код HMAC-SHA256, вычисленный с использованием секретного ключа и случайной затравки. На рисунке~\ref{fig:lab5-hmac} показан обмен сообщениями в режиме \texttt{-{}-encrypt -{}-hmac}: видны HMAC-затравка, вычисленный HMAC на стороне отправителя и результат проверки на стороне получателя. При отправке одного и того же сообщения повторно значение HMAC отличается благодаря новой затравке.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-hmac.png}
|
||
\caption{Обмен сообщениями с HMAC-SHA256: аутентификация и контроль целостности}
|
||
\label{fig:lab5-hmac}
|
||
\end{figure}
|
||
|
||
На рисунке~\ref{fig:lab5-hmac-fail} показана проверка режима \texttt{-{}-test-integrity} совместно с \texttt{-{}-hmac}: отправитель передаёт намеренно некорректный HMAC, получатель обнаруживает несоответствие и сообщает о неудачной аутентификации.
|
||
|
||
\begin{figure}[H]
|
||
\centering
|
||
\includegraphics[width=0.85\linewidth]{img/lab5-hmac-fail.png}
|
||
\caption{Обнаружение некорректного HMAC — отправитель не аутентифицирован}
|
||
\label{fig:lab5-hmac-fail}
|
||
\end{figure}
|
||
|
||
\subsection{Выводы}
|
||
|
||
В ходе практической работы №5 разработано клиент-серверное приложение для конфиденциального обмена сообщениями по протоколу TCP. Реализовано шифрование 3DES-CBC с затравкой (ключ сессии из SHA-256), обеспечивающей различные шифротексты при одинаковых открытых текстах, контроль целостности сообщения на основе MD5 (как в индивидуальном задании и практической работе №2) и дополнительный режим HMAC-SHA256 для аутентификации отправителя. Экспериментальная проверка с помощью \texttt{tcpdump} подтвердила, что при включённом шифровании содержимое сообщений не передаётся в открытом виде, а при включённом контроле целостности получатель успешно обнаруживает намеренно повреждённые сообщения.
|
||
|
||
|
||
\newpage
|
||
\section*{Заключение}
|
||
\addcontentsline{toc}{section}{Заключение}
|
||
|
||
В ходе выполнения практической работы №1 был проведён анализ уязвимостей программного обеспечения с использованием Банка данных угроз ФСТЭК России. Были изучены структура разделов <<Угрозы>> и <<Уязвимости>>, определены версии операционных систем личного компьютера и смартфона, а также выполнен поиск уязвимостей с уровнем опасности <<Критический>> и <<Высокий>>. Проведён анализ наиболее актуальных уязвимостей, рассмотрены их характеристики и векторы CVSS, а также рекомендации по устранению. В процессе выполнения работы были получены практические навыки поиска, анализа и оценки уязвимостей информационных систем.
|
||
|
||
В ходе выполнения практической работы №2 была разработана система доступа пользователей к конфиденциальным данным. Реализованы утилита управления пользователями с хэшированием паролей по алгоритму MD5 (индивидуальный вариант задания), утилита доступа с разграничением прав и журналированием операций, а также программа взлома паролей методом грубой силы. Проведено исследование стойкости паролей в зависимости от их длины, результаты которого подтвердили экспоненциальную зависимость числа итераций от длины пароля и продемонстрировали практическую устойчивость достаточно длинных паролей к атаке полного перебора.
|
||
|
||
В ходе выполнения практической работы №3 на базе системы из работы №2 реализованы модели дискреционного (DAC) и мандатного (MAC) управления доступом. DAC реализован через список доступа с владельцами объектов и командой выдачи прав; MAC — на основе модели Белла–Лападулы с тремя уровнями меток конфиденциальности. Реализация демонстрирует принципиальные различия между подходами и их практическое применение.
|
||
|
||
В ходе выполнения практической работы №4 на стенде из двух виртуальных машин VirtualBox настроена политика межсетевого экранирования средствами \texttt{iptables}. Реализованы правила фильтрации, разрешающие loopback-трафик, DNS, ICMP и HTTP/HTTPS, а все прочие соединения блокируются. Корректность работы правил подтверждена тестовыми соединениями и анализом пакетов утилитой \texttt{tcpdump}.
|
||
|
||
В ходе выполнения практической работы №5 разработано клиент-серверное приложение для конфиденциального обмена сообщениями по протоколу TCP. Реализовано шифрование 3DES-CBC с затравкой (производный ключ через SHA-256), контроль целостности сообщения MD5 и режим HMAC-SHA256 для аутентификации отправителя. Анализ трафика утилитой \texttt{tcpdump} подтвердил, что при включённом шифровании содержимое сообщений не доступно в открытом виде, а режим тестирования продемонстрировал корректное обнаружение нарушений целостности.
|
||
|
||
\newpage
|
||
\printbibliography[heading=bibintoc]
|
||
|
||
\newpage
|
||
\section*{Приложение 1. Исходный код файла usermgr.py из практической работы №2}
|
||
\addcontentsline{toc}{section}{Приложение 1. Исходный код файла usermgr.py из практической работы №2}
|
||
\label{app:usermgr}
|
||
\lstinputlisting{../lab2/usermgr.py}
|
||
|
||
\newpage
|
||
\section*{Приложение 2. Исходный код файла access.py из практической работы №2}
|
||
\addcontentsline{toc}{section}{Приложение 2. Исходный код файла access.py из практической работы №2}
|
||
\lstinputlisting{../lab2/access.py}
|
||
|
||
\newpage
|
||
\section*{Приложение 3. Исходный код файла bruteforce.py из практической работы №2}
|
||
\addcontentsline{toc}{section}{Приложение 3. Исходный код файла bruteforce.py из практической работы №2}
|
||
\label{app:bruteforce}
|
||
\lstinputlisting{../lab2/bruteforce.py}
|
||
|
||
\newpage
|
||
\section*{Приложение 4. Исходный код файла setup.sh из практической работы №2}
|
||
\addcontentsline{toc}{section}{Приложение 4. Исходный код файла setup.sh из практической работы №2}
|
||
\lstinputlisting{../lab2/setup.sh}
|
||
|
||
\newpage
|
||
\section*{Приложение 5. Исходный код файла usermgr.py из практической работы №3}
|
||
\addcontentsline{toc}{section}{Приложение 5. Исходный код файла usermgr.py из практической работы №3}
|
||
\lstinputlisting{../lab3/usermgr.py}
|
||
|
||
\newpage
|
||
\section*{Приложение 6. Исходный код файла confaccess.py из практической работы №3}
|
||
\addcontentsline{toc}{section}{Приложение 6. Исходный код файла confaccess.py из практической работы №3}
|
||
\lstinputlisting{../lab3/confaccess.py}
|
||
|
||
\newpage
|
||
\section*{Приложение 7. Исходный код файла config.py из практической работы №3}
|
||
\addcontentsline{toc}{section}{Приложение 7. Исходный код файла config.py из практической работы №3}
|
||
\lstinputlisting{../lab3/config.py}
|
||
|
||
\newpage
|
||
\section*{Приложение 8. Исходный код файла setup.sh из практической работы №3}
|
||
\addcontentsline{toc}{section}{Приложение 8. Исходный код файла setup.sh из практической работы №3}
|
||
\lstinputlisting{../lab3/setup.sh}
|
||
|
||
\newpage
|
||
\section*{Приложение 9. Исходный код файла main.py из практической работы №5}
|
||
\addcontentsline{toc}{section}{Приложение 9. Исходный код файла main.py из практической работы №5}
|
||
\label{app:lab5-main}
|
||
\lstinputlisting{../lab5/main.py}
|
||
|
||
\end{document}
|