ВВЕДЕНИЕ

В современном мире постоянно приходится сталкиваться с действиями, связанными с обработкой, передачей и хранением информации. При этом недостаток безопасности в информационной сфере может привести к утечкам данных, кибератакам, нарушениям правил налоговой и банковской отчетности, а также ко многим другим проблемам, которые могут негативно повлиять на деловые процессы, жизнь и здоровье людей.

Необходимость защиты данных становится особенно важной в случае передачи конфиденциальной информации, такой как, например, пароли, ключи шифрования или конфиденциальные документы. Без должного обеспечения информационной безопасности при передаче сообщений, данные могут быть перехвачены, украдены, изменены или уничтожены. Это может привести к серьезным последствиям для организации или частного лица, таким как финансовые потери, утечка конфиденциальных данных, нарушение репутации и потеря доверия клиентов и партнеров.

Актуальность заявленной темы заключается в том, что, при обмене сообщениями необходимо обеспечить свойство гарантированного удаления конфиденциальных данных без оставления следов. Допустим, сотрудник некой компании находится в командировке, а в офисе на его рабочем компьютере, логический доступ к которому осуществляется по паролю, остался файл, который срочно потребовался руководителю. В такой ситуации сотруднику нужно каким-то образом отправить этот пароль руководителю, но даже в том случаи, когда выбранная система передачи информации обладает достаточными средствами защиты, при передаче сообщения остается информационный след. Следовательно, если аккаунт отправителя или получателя взломан, злоумышленник получает доступ ко всем паролям и иным данным, которые когда-либо были отправлены или получены. К тому же, те у кого есть доступ к системе хранения передаваемых данных, также могут получить доступ к сообщениям. Таким, образом, существует необходимость гарантированного удаления секретного сообщения после прочтения.

На сегодняшний день уже существуют системы, которые в теории могут обеспечить «одноразовость» сообщений, но, например, электронная почта или Телеграмм чат, не гарантируют удаление сообщения после прочтения, а системы на основе одноразовых ссылок руководствуются анонимностью. Следовательно, существует проблема совместного использования аутентификации и гарантированного удаления конфиденциальной информации.

В работе формулируется следующая гипотеза: система на основе одноразовых ссылок может обеспечить свойство гарантированного удаления конфиденциальной информации.

Цель работы: разработать методику защиты от перехвата аутентификационной информации в системах передачи одноразовых сообщений.

Для достижения поставленной цели необходимо решить следующие задачи:

  • проанализировать недостатки существующих решений для обмена сообщениями;
  • разработать модель системы передачи одноразовых сообщений;
  • разработать методику защиты от перехвата аутентификационной информации.

1 Анализ существующих решений для обмена сообщениями

1.1 Анализ принципов работы существующих решений для обмена сообщениями

1.1.1 Анализ принципов и особенностей работы электронной почты

Электронная почта – информационная система для обмена электронными сообщениями. Ее основное назначение – личная и деловая переписка. Принцип работы аналогичен обычной почте, но для приема и отправки сообщений используется специальное программное обеспечение [1]. Система электронной почты состоит из двух основных подсистем:

  • клиентского программного обеспечения, с которым непосредственно взаимодействует пользователь;
  • серверного программного обеспечения, которое управляет приемом сообщения от пользователя-отправителя, передачей сообщения, направлением сообщения в почтовый ящик адресата и его хранением в этом ящике до тех пор, пока пользователь-получатель его не возьмет оттуда.

Multipurpose Internet Mail Extensions (MIME) – стандарт, описывающий передачу различных типов данных по электронной почте, а также, в общем случае, спецификация для кодирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по средствам сети Интернет [2].

S/MIME (Secure Multipurpose Internet Mail Extension) – это усовершенствованный с точки зрения информационной безопасности стандарта MIME, базирующийся на использовании технологии RSA [3]. Главной характеристикой этого стандарта является иерархическая политика аутентификации, требующая для управления открытыми ключами развертывания инфраструктуры открытых ключей (PKI).

Почтовые сообщения в сети Интернет передаются посредством протокола SMTP – сетевого протокола прикладного уровня стека протоколов TCP/IP. Особенность SMTP состоит в том, что каждый физический сервер может функционировать и как SMTP клиент, и как SMTP сервер: будучи сервером, он принимает входящее сообщение и становится клиентом для пересылки сообщения следующему узлу [4]. Протокол SMTP используется для отправки сообщений, но, в случаи идентификации SMTP сервера как конечного получателя, пересылка прекращается, а письмо помещается во внутреннее, зависящее от реализации, хранилище.

Для получения сообщений из хранилища конечные пользователи используют другие протоколы: POP3 и IMAP4 [4]. Оба протокола также поддерживают роли клиента и сервера, но, обычно, только одну роль в одно время – либо клиент, либо сервер. Сервер предоставляет необходимую информацию из хранилища в ответ на протокольные команды, подаваемые клиентом.

При подключении клиента к почтовому серверу по протоколу POP3, сообщения скачиваются на устройство, а затем удаляются с сервера.

Протокол IMAP4 позволяет пользователям получать доступ к сообщениям электронной почты непосредственно на сервере электронной почты и работает путем поддержания постоянного соединения между клиентом и сервером.

С точки зрения пользователя почтовой системы существует только один компонент – это Mail User Agent (MUA). MUA – почтовый агент пользователя или почтовый клиент, обеспечивающий пользовательский интерфейс, необходимый для получения, отображения, создания и перенаправления писем. Традиционно MUA представлял собой автономное клиентское приложение.

От MUA сообщение получает Message Submission Agent (MSA) – агент отправки сообщений. Он описан как сервис, который либо доставляет сообщения, либо ретранслирует их в Mail Transfer Agent (MTA). На практике отдельных реализаций MSA не существует, его функции выполняет большинство реализаций MTA [5].

MTA – агент передачи сообщений, который отвечает за организацию пересылки. Он действует либо как сервер, принимающий сообщения от MSA или другого MTA, либо как клиент для ретрансляции другому MTA [6].

За доставку сообщений отвечает Message Delivery Agent (MDA) – агент доставки сообщений. Он отвечает за доставку электронного письма локальному получателю.

Вместе с MDA работает Mail Retrieval Agent (MRA) – агент получения сообщений. MRA могут быть внешними приложениями сами по себе или встроенными в MUA. Концепция MRA не стандартизирована в архитектуре электронной почты, так как технически эти агенты являются клиентами, когда извлекают и отправляют сообщения.

На рисунке 1.1 представлена схема передачи сообщений по средствам электронной почты.

Рисунок 1.1 – Схема работы почтовых протоколов стека TCP/IP

Ключевым недостатком данного решения является отсутствие возможности гарантированного удаления сообщения после прочтения, что приводит к развитию информационного следа, который может быть использован злоумышленниками в корыстных целях.

Так, например, прямая цитата из официальной справки Яндекс по настройке электронной почты: при скачивании писем с сервера по протоколу POP3 Яндекс Почта автоматически сохраняет копии писем на сервере, но вы можете удалять письма вручную с помощью веб-интерфейса [7]. Из пользовательского соглашения Яндекс: технология работы сервисов Яндекса может потребовать копирование (воспроизведение) контента Пользователя [8].

1.1.2 Анализ принципов и особенностей работы телеграмм чата

Telegram – кроссплатформенная система мгновенного обмена сообщениями (мессенджер) с функциями обмена текстовыми, голосовыми и видеосообщениями, а также файлами многих форматов.

Для безопасной передачи сообщений между собеседниками в Telegram разработчиками предусмотрен специальный тип соединений – секретные чаты, которые обеспечивают сквозное шифрование принципу end-to-end (E2E) и аутентификацию сообщений [9]. Секретные чаты предназначены для общения только для двух собеседников и доступны только на мобильных устройствах. В групповых чатах и на персональных компьютерах возможность использования сквозного шифрования не предусмотрена.

Обмен сообщениями по средствам секретного чата Telegram осуществляется при помощи протокола MTProto.

Протокол MTProto использует два слоя шифрования – сервер-сервер и клиент-сервер. Он работает на основе следующих алгоритмов:

  • AES – симметричный 256-битный и 512-битный алгоритм, принятый правительством США в качестве стандарта;
  • RSA – криптографический алгоритм, в основе которого лежит вычислительная сложность задачи факторизации крупных целых чисел;
  • Метод Диффи-Хеллмана, который позволяет получить двум и более собеседникам секретный ключ по незащищенному от прослушивания (но защищенному от подмены) каналу связи;
  • SHA-256, MD5 – алгоритмы хэширования, используемые во многих криптографических протоколах [10].

Обмен сообщениями состоит из трех этапов:

1) регистрация клиента – клиент вводит свой номер телефона, на который по SMS приходит пятизначный код для подтверждения номера, после этого клиент авторизуется на сервере;

2) обмен ключами – клиенты вырабатывают общий секретный ключ при помощи алгоритма Диффи-Хеллмана;

3) обработка исходящего сообщения [11].

Схема обработки сообщения представлена на рисунке 1.2.

Рисунок 1.2 – Шифрование сообщений в секретных чатах Telegram

Ключевым недостатком данного решения также является отсутствие гарантированного удаления сообщения. При отправке файлов, фотографий или видео данные хоть и шифруются по принципу E2E, хранятся они, все равно, на сервере [12]. На основании исследования, проведенного компанией Zimperium [13], где при помощи атаки на клиента удалось получить доступ к удаленным сообщениям секретного чата Telegram, можно утверждать, что если сообщения не удаляются при передаче клиент-клиент, которая, по идее, должна быть более надежной, то нет никакой гарантии того, что сообщения удаляются при передаче клиент-сервер.

1.1.3 Анализ принципов и особенностей работы систем, генерирующих одноразовые ссылки

В основе систем передачи одноразовых сообщений лежит одноразовый URL и принцип «после прочтения уничтожить». В общем случаи алгоритм работы заключается в том, что для отправки сообщения пользователю необходимо в соответствующее поле веб-приложения вставить текст сообщения (в некоторых системах можно отправлять и файлы), сообщение отправляется на сервер, а пользователю возвращается URI, который срабатывает только один раз, после чего информация стирается с сервера. Серверы таких систем не хранят никакой информации о пользователях.

Примерами таких систем выступают One-Tme Secret и Password Link. Пример работы Password Link представлен на рисунках 1.3 и 1.4.

Рисунок 1.3 – Отправка сообщения

Рисунок 1.4 – Формирование одноразовой ссылки

Обмен сообщениями в системах передачи одноразовых сообщений осуществляется по протоколу HTTP или по его защищенной версии HTTPS.

HTTP (Hypertext Transfer Protocol) – протокол передачи гипертекста представляет собой наиболее распространенный способ передачи ресурсов в Web [14]. HTTP – это клиент-серверный протокол, то есть обмен данными реализуется по схеме запрос-ответ, где запрос – это сообщение, посылаемое клиентом принимающему серверу, в качестве которого может выступать как исходный сервер, на котором генерируется веб-ресурс, так и промежуточное звено – прокси сервер [15]. Ответ от принимающего сервера возвращается обратно клиенту.

Для перехода от HTTP к HTTPS, где S означает Secured (защищенный) и подразумевает, что весь трафик передаётся в зашифрованном виде, необходимо подключить SSL сертификат. Механизм работы HTTPS представлен на рисунке 1.5.

Рисунок 1.5 – Процесс подтверждения SSL

Ключевым недостатком таких систем является тот факт, что они руководствуются анонимностью, следовательно, если сформированная ссылка будет перехвачена, злоумышленник получит доступ к сообщению.

1.1.4 Анализ принципов и особенностей работы защищенной сети

Под защищенной сетью понимают закрытую систему передачи данных с ограниченным внешним доступом. На границе между двумя или более сегментами сети, например, между внутренней сетью организации и общедоступной сетью, для фильтрации трафика размещается шлюз безопасности [16].

Деятельность организаций требует коммуникаций через общественную сеть, например, Интернет, но поскольку уровень доверия к общедоступной сети относительно низок, для устранения рисков, вызванных ею, необходимы шлюзы безопасности. Технология, позволяющая обеспечить одно или несколько сетевых соединений поверх какой-либо другой сети – VPN (virtual private network – виртуальная частная сеть).

Типы корпоративных VPN по варианту построения:

  • Intranet VPN предполагает объединение нескольких филиалов одной организации, которые распределены географически, в защищенную сеть для передачи данных по открытым каналам;
  • Remote Access VPN предназначен для построения защищенного канала связи между корпоративной сетью и отдельным пользователем, который подключается к защищенной сети извне, например, с домашнего компьютера для удаленной работы;
  • Client/Server VPN, как правило, применяется для защиты данных, которые передаются между узлами в одном сетевом сегменте, то есть для разделения одной физической сети на несколько логических;
  • Extranet VPN предназначен для возможности подключения внешних пользователей, не являющихся сотрудниками компании, например, клиентов или заказчиков [17].

Принцип работы VPN заключается в том, что VPN создает зашифрованное туннельное соединение между вашим устройством и удаленным сервером.

Ключевым недостатком такого способа передачи сообщений является высокая стоимость реализации, что при определенных условиях может нарушить принцип разумной достаточности и экономическую целесообразность. Так, например, стоимость программно-аппаратного комплекса ViPNet Coordinator в зависимости от модификации может достигать 407 000 рублей. При этом, по данным Positive Technologies бюджет, выделяемый в компании на обеспечение ИБ, в первую очередь расходуется на приведение инфраструктуры в соответствие требованиям регуляторов, а именно:

  • на разработку и адаптацию организационно-распорядительных документов;
  • на приобретение и внедрение минимально необходимых технических средств защиты, таких как антивирусы, межсетевые экраны и системы обнаружения вторжений [18].

1.2 Анализ угроз и уязвимостей безопасности информации существующих решениий для обмена сообщениями

Очевидно, самым безопасным способом с точки зрения конфиденциальности, целостности и доступности является обмен сообщениями по средствам защищенной сети, но так как его ключевым недостатком является высокая стоимость, в дальнейшем анализе рассматривать его не будем.

Определенные в подразделах 1.1.1-1.1.3 недостатки существующих решений, могут привести к ряду угроз безопасности информации, к ним относятся:

  • угроза утечки информации;
  • угроза несанкционированного доступа;
  • угроза несанкционированной модификации (искажения);
  • угроза несанкционированной подмены;
  • угроза удаления информационных ресурсов;
  • угроза отказа в обслуживании.

В таблице 1.1 приведены некоторые возможные негативные последствия от реализации угроз безопасности информации, к которым приводят эти недостатки. Обозначения уязвимостей приведены в соответствии с банком данных угроз безопасности информации Федеральной службы по техническому и экспортному контролю (далее ФСТЭК России).

Таблица 1.1 – Виды риска и возможные последствия

Вид риска (ущерба) Возможные последствие
Ущерб активам физического лица Нарушение тайны переписки

Нарушение личной, семейной тайны, утрата чести и доброго имени.

Финансовый, иной материальный ущерб физическому лицу.

Нарушение конфиденциальности (утечка)

персональных данных

Разглашение персональных данных граждан

Ущерб активам юридического лица,

индивидуального

предпринимателя

Потеря (хищение) денежных средств.

Недополучение ожидаемой (прогнозируемой)

прибыли.

Нарушение штатного режима функционирования автоматизированной системы управления и управляемого объекта и/или процесса.

Срыв запланированной сделки с партнером

В реальной компании для оценки угроз безопасности информации необходимо составить модель нарушителя. В свиязи с высокой вариативностью компаний и предприятий, будем опираться на общую характеристику источников угроз. Тогда можно составить таблицу 1.2.

Таблица 1.2 – Уязвимости

Объект воздействия Интерфейс Уязвимости
Почтовый клиент POP3 BDU:2020-03297 Уязвимость команды tls_trust_file SMTP-клиента Msmtp и POP3-клиента Mpop, позволяющая нарушителю оказать воздействие на целостность, доступность и конфиденциальность информации.

BDU:2019-04237 Уязвимость метода pop3lib apop() интерпретатора языка программирования Python, позволяющая нарушителю вызвать отказ в обслуживании.

Уязвимости, связанные с криптографическими алгоритмами.

IMAP BDU:2021-02078 Уязвимость почтового клиента Thunderbird, связанная с недостаточной проверкой вводимых данных на этапе настройки соединения IMAP STARTTLS, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации.

BDU:2019-04577 Уязвимость файла imap/message.c почтовых клиентов Mutt и NeoMutt, связанная с переполнением буфера в стеке, позволяющая нарушителю выполнить произвольный код.

Уязвимости, связанные с криптографическими алгоритмами.

Продолжение таблицы 1.2

Объект воздействия Интерфейс Уязвимости
Почтовый сервер SMTP BDU:2022-06190 Уязвимость SMTP-сервера системы управления взаимоотношениями с клиентами SuiteCRM, позволяющая нарушителю оказать воздействие на целостность защищаемой информации.

BDU:2018-00088 Уязвимость функции receive_msg (receive.c). SMTP-демона почтового сервера Exim операционной системы Debian GNU/Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код.

Уязвимости, связанные с криптографическими алгоритмами

Алгоритм шифрования MTProto BDU:2021-05754 – уязвимость, связанная с выходом операции за границы буфера, позволяющая нарушителю вызвать отказ в обслуживании.

BDU:2021-03325 – уязвимость функции LottieParserImpl::parseDashProperty, позволяющая нарушителю раскрыть защищаемую информацию.

BDU:2017-00768 – уязвимость, позволяющая нарушителю получить доступ к сообщениям секретного чата.

Уязвимости, связанные с криптографическими алгоритмами.

Веб-клиент,

веб-сервер,

линия связи клиент-сервер.

HTML-форма BDU:W01 – уязвимости, связанные с недостатками проверки вводимых данных.

Уязвимости, связанные с криптографическими алгоритмами.

HTTP,

HTTPS

BDU:W02 – уязвимости, связанные с недостатками управления доступом и защиты данных.

BDU:W03 – уязвимости, связанные с недостатками работы со структурами данных.

BDU:W04 – уязвимости, связанные с недостатками проверки подлинности.

BDU:W05 – уязвимости, связанные с недостатками управления ресурсам.

Уязвимости, связанные с криптографическими алгоритмами.

Если учесть, что риск складывается из наличия актива, нарушителя, угрозы и уязвимости, то на основании всего вышесказанного можно сделать вывод, что использование существующих решений несет в себе существенные риски как для компании, так и для частного лица [УКПК-1. ГИА].

1.3 Обоснование выбора функций безопасности

Из подраздела 1.1 следует, что гарантировать удаление сообщения после прочтения могут только системы, генерирующие одноразовые ссылки, но подраздел 1.2 свидетельствует о том, что использование таких систем все еще рискованно с точки зрения информационной безопасности.

Таким образом, необходимо повысить уровень защищенности этих систем. Сделать это можно при помощи стратегии снижения рисков. Снижение риска – воздействие на риск путем снижения вероятности реализации риска и (или) снижения негативных последствий в случае реализации риска в будущем [19].

Снизить вероятность возникновения риска можно при помощи закрытия уязвимостей. Так закрыть группу уязвимостей BDU:W01, связанных с недостатками проверки вводимых данных, можно при помощи экранирования от специальных символов. BDU:W05 от части можно закрыть при помощи экранирования от специальных символов. Это связано с тем, что экранирование работает только со строковыми значениями, следовательно, в любом случае потребуется проверка типов и допустимых значений входных данных. Закрыть группу уязвимостей BDU:W02 и BDU:W04, связанных с недостатками управления доступом и проверки подлинности, можно при помощи внедрения алгоритмов идентификации, аутентификации и авторизации [УКПКО-1. ГИА]. BDU:W03 уязвимости, связанные с недостатками работы со структурами данных в большей степени связаны не применением конкретных решений по безопасности, а с корректностью написания программного кода при разработке системы, следовательно, можно предположить, что в существующих системах на основе одноразовых ссылок данная уязвимость закрыта.

Сказать точно о том, какие криптографические алгоритмы используют системы, генерирующие одноразовые ссылки, нет возможности, так как вся информация, которую дают разработчики по теме шифрования данных – это утверждение о том, что они используют алгоритмы шифрования. Но так как эти системы разработаны и предоставляемы зарубежным вендором, можно предположить, что вероятность того, что они используют российские криптографические алгоритмы крайне мала, что ведет к дополнительным уязвимостям. Следовательно, необходимо использование отечественного шифрования по серии стандартов ГОСТ 34.

1.4 Выводы по разделу

Каждое из приведенных в данном разделе решений для обмена сообщениями обладает недостатками (высокая стоимость и сложность реализации, отсутствие функций безопасности или гарантии удаления сообщения после прочтения). Следовательно, пользователи этих систем вынуждены брать на себя существенные риски, связанные с информационной безопасностью.

С точки зрения «одноразовости» оптимальным является использование системы на основе одноразовых ссылок, но ее ключевым недостатком является отсутствие функций, обеспечивающих безопасность информации, что приводит к возникновению уязвимостей. Закрыть эти уязвимости можно при помощи внедрения алгоритмов аутентификации, идентификации и авторизации, а также шифрования по ГОСТ и экранирования от специальных символов, но провести тестирование на устойчивость к кибератакам на реальной системе не представляется возможным в связи с противозаконностью таких действий [20, 21].

Таким образом существует необходимость в разработке модели системы передачи сообщений на основе одноразовых ссылок.

2 Разработка имитационной модели защищенной системы передачи сообщений на основе одноразовых ссылок

2.1 Обоснование выбора программных продуктов для моделирования системы

Virtual Box — это среда виртуализации с открытым исходным кодом, которая позволяет запустить на одном физическом персональном компьютере сразу несколько виртуальных машин. Они полностью изолированы от реального устройства и установленных на основной операционной системе приложений. Поддержка многих операционных систем, гибкость настроек и простота использования делают данное программное обеспечение удобным инструментом для проведения экспериментов на модели.

В виртуальную сеть объединим:

  • основную операционную систему Windows 10 (сервер);
  • виртуальную машину с дистрибутивом Linux Ubuntu (клиент);
  • виртуальную машину с дистрибутивом Kali Linux (нарушитель).

Ubuntu – бесплатная система с открытым исходным кодом. Простой и интуитивно понятный интерфейс и возможность настраивать систему по своим потребностям и требованиям привело к формированию большого сообщества вокруг Ubuntu, что делает ее одним из самых популярных дистрибутивов Linux и, следовательно, может использоваться для иммиграции действий клиента при проведении экспериментов на модели.

Kali Linux - это дистрибутив Linux, который специализируется на тестировании безопасности и выборке инструментов для взлома систем. Kali Linux поставляется с предустановленными инструментами для тестирования на проникновение, анализа сетевого трафика, сканирования уязвимостей и много других инструментов и программ для различных целей, что делает его весьма удобным инструментом для имитации действий злоумышленника.

Реализация алгоритмов работы модели системы будем проводить при помощи языка программирования Python3. Python – высокоуровневый язык программирования с динамической строгой типизацией и автоматическим управлением памятью. Python обладает большим количеством как встроенных так и сторонних библиотек, поддерживает множество парадигм программирования, включая процедурное и объектно-ориентированное. Благодаря простому и понятному синтаксису код на данном языке программирования легко писать и понимать, что делает его весьма удобным инструментом для программной реализации алгоритмов.

Для создания интерфейса будут использоваться язык разметки HTML и язык описания внешнего вида CSS. HTML необходим для создания и определения структуры и содержания интерфейса пользователя, а CSS для стилизации элементов.

Таким образом для моделирования системы будут использоваться: Python3, HTML, CSS, Virtual Box, Kali Linux, Ubuntu и основная операционная система Windows 10.

2.2 Разработка структуры и принципов функционирования модели системы

Системы, генерирующие одноразовые ссылки, работают на основе клиент-серверной архитектуры по протоколу HTTP.

Клиент-серверная архитектура предназначена для разделения отделения представления данных от их обработки [22]. При работе с протоколом HTTP хранить и обрабатывать данные можно либо на стороне клиента, либо на стороне сервера.

При хранении и обработке информации на стороне клиента, скорость работы системы во многом зависит от производительности рабочей станции. К тому же, данные могут быть заблокированы или удалены пользователем, операционной системой, браузером или плагинами в любой момент, что может привести к некорректной работе разрабатываемой системы передачи сообщений. Например, если имеется определенная функция JavaScript которая обрабатывает некоторую информацию, которая затем отправляется обратно в систему, злоумышленник имеет возможность манипулировать результатом ее выполнения.

Достоинства серверной обработки данных:

  • уменьшается поток данных в сети между клиентом и сервером вследствие того, что все промежуточные операции выполняются на сервере;
  • уменьшение времени загрузки страницы, так как на стороне клиента обрабатывается только HTML-код без дополнительных программ;
  • отсутствие проблем совместимости браузеров;
  • отсутствие возможности просмотра программного кода при помощи браузера.

Таким образом, серверные вычисления являются преимущественными. Модель клиент-серверной архитектуры, на основе которой разрабатывается модель приведена на рисунке 2.1.

Рисунок 2.1 – Модель клиент-серверной архитектуры

Схема подключения виртуальных машин, представлена на рисунке 2.2. При проведении эксперементов у злоумышленника есть возможность прослушивать порты только клиента, так подключение клиента к серверу без промежуточных узлов в реальной системе маловероятно.

Рисунок 2.2 – Функциональная схема сети VirtualBox

Механизм работы системы заключается в том, что в специальное поле отправитель вводит секретное сообщение, а система возвращает ему одноразовую ссылку, которую необходимо передать получателю по любому каналу связи.

Таким образом, алгоритм работы модели системы:

  1. отправитель заходит на сайт и в специальную форму вводит секретное сообщение (текст или документ), которые отправляются на сервер;
  2. на сервере рассчитывается идентификатор сообщения;
  3. рассчитывается время удаления сообщения для ограничения времени хранения сообщения;
  4. сообщение шифруется;
  5. в базу данных записываются идентификатор, время удаления, тип (текст или файл) и половина ключа шифрования;
  6. вторая половина ключа возвращается пользователю GET-ответом в составе одноразовой ссылки;
  7. отправитель передает эту ссылку получателю по любому каналу связи
  8. получатель, перейдя по ссылке, подтверждает просмотр сообщения путем нажатия кнопки, затем на сервер отправляется POST-запрос;
  9. сервер из заголовка запроса Referer получает URL, то есть идентификатор сообщения и половину ключа шифрования, необходимую для расшифровки сообщения;
  10. выполняется проверка наличия идентификатора сообщения в базе данных;
  11. проверяется не истекло ли время хранения сообщения;
  12. в случае успешных проверок сервер расшифровывает сообщение и возвращает пользователю GET-ответ с сообщением (текст или файл), затем удаляет как сообщение, так и запись о нем в базе данных, в случае хотя бы одной отрицательной проверки пользователю возвращается GET-ответ с отказом.

Схема алгоритма приведена в приложении А. Листинг программ для реализации алгоритма приведен в Приложенииях Б. Иерархия файлов в директории представлена на рисунке 2.3.

Рисунок 2.3 – Иерархия файлов

Пример работы реальной системы приведен в первом разделе на рисунках 1.3 и 1.4. Пример работы модели системы приведен на рисунках 2.4 и 2.5.

Рисунок 2.4 – Стартовая страница

Рисунок 2.5 – Страница ответа сервера отправителю

Таким образом, разработана модель, имитирующая поведение реальной системы на основе одноразовых ссылок.

2.3 Внедрение функций, обеспечивающих информационную безопасность

2.3.1 Описание и внедрение алгоритмов идентификации и аутентификации пользователей

Аутентификация – действия по проверке подлинности субъекта доступа и/или объекта доступа, а также по проверке принадлежности субъекту доступа и/или объекту доступа предъявленного идентификатора доступа и аутентификационной информации [23]. Идентификация - действия по присвоению субъектам и объектам доступа идентификаторов и/или по сравнению предъявляемого идентификатора с перечнем присвоенных идентификаторов [23].

При доступе субъекта доступа к объекту доступа целью идентификации и аутентификации является опознавание субъекта доступа, в данном случаи этот процесс будет проходить в границах одной информационной системы. В качестве идентификатора пользователя в системе будет выступать уникальный логин, а аутентификация будет проходить с применением такого фактора знания, как пароль. Фиксация информации о пользователе будет осуществляться по средствам записи идентификационной информации в базу данных. Применительно к веб-системам идентификацию пользователя и фиксацию информации о пользователе объединяют термином «регистрация».

Таким образом, алгоритм регистрации пользователя в системе состоит из следующих этапов:

  1. пользователь вводит в HTML-форму логин, пароль и повторный пароль, который необходим для предотвращения опечаток;
  2. данные из формы передаются на сервер для дальнейшей работы обработчика форм;
  3. рассчитывается хэш пароля при помощи такой функция хэширования как SHA-256;
  4. в функцию хэширования добавляется соль для защиты от идентификации дубликатов или общих паролей;
  5. расчет времени действия учетной записи пользователя - времени, при достижении которого учетная запись будет удалена (срок действия учетной записи пользователя составляет 365 дней);
  6. проверяем наличие введенного логина в базе данных для обеспечения уникальности идентификаторов;
  7. если логина (идентификатора пользователя) нет в базе данных, проверяем совпадают ли хэши двух введенных пользователем паролей;
  8. в случае непрохождения какой-либо проверки, пользователю выводится соответствующее сообщение об ошибке;
  9. запись в базу данных логина, хэша пароля, соли, времени удаления учетной записи пользователя;
  10. вывод сообщения об успешной регистрации.

Алгоритм аутентификации пользователя:

  1. пользователь вводит в HTML-форму логин, пароль и повторный пароль, который необходим для предотвращения опечаток;
  2. данные из формы передаются на сервер для дальнейшей работы обработчика форм;
  3. если логин пользователя есть в базе данных, рассчитывается хэш от пароля, введенного пользователем и соли, полученной из базы данных;
  4. если рассчитанный хэш совпадает с хэшем из базы данных, проверяется, не истекло ли время действия учетной записи пользователя;
  5. если время действия учетной записи пользователя не истекло, предоставляется доступ к функционалу системы:
  6. в случае хотя бы одной неудачной проверки, выводится сообщение об ошибке, при этом, если время действия учетной записи пользователя истекло перед выводом сообщения об ошибке удаляется учетная запись пользователя.

Схемы алгоритмов идентификации и аутентификации приведена в Приложении В.

2.3.2 Управление доступом пользователей к функционалу системы по средствам авторизации

Авторизация - предоставление субъекту доступа прав доступа, а также предоставление доступа в соответствии с установленными правилами управления доступом [23]. Управление доступом посредством авторизации позволяет ограничить доступ к конфиденциальной информации, управлять правами пользователей и обеспечить безопасность системы в целом.

В исследуемой системе предоставление доступа пользователям к функционалу системы осуществляется на основании успешного прохождения проверок, описанных в алгоритме аутентификации.

2.3.3 Описание и внедрение алгоритмов шифрования и хэширования

В Государственном стандарте ГОСТ 34.12-2018 приведено описание двух базовых блочных шифров с длинами блоков n=128 бит и n=64 бит и длинами ключей k=256 бит. На описанный в данном стандарте шифр с длиной блока n=128 бит можно ссылаться как на блочный шифр "Кузнечик" ("Kuznechik") [24].

Алгоритм развертывания ключа для шифра «Кузнечик» использует итерационные константы Ci ∈ V128, i = 1,2, …, 32, которые определены следующим образом [24]:

, (1)

Итерационные ключи Ki ∈ V128, i = 1,2, …, 10 выбираются на основе ключа K = k255 ||…|| k0∈ V256, ki ∈ V1, i = 0,1,2…225 и определяются равенствами [24]:

;

; (2)

Алгоритм шифрования в зависимости от значений итерационных ключей Ki ∈ V128, i=1,2…,10, реализует подстановку EK1, …, K10, заданную на множестве V128 в соответствии с равенством [24]:

(3)

где a ∈ V128.

Для обеспечения безопасности паролей необходимо хранить в базе данных пользователей не сам пароль, а его хэш. При такой реализации идентификация будет происходить при помощи сравнения хэша пароля, записанного в базе, с хэшем, рассчитанным от введенного пользователем пароля.

Хэш-функция - функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:

1) по данному значению функции сложно вычислить исходные данные, отображаемые в это значение;

2) для заданных исходных данных сложно вычислить другие исходные данные, отображаемые в то же значение функции;

3) сложно вычислить какую-либо пару исходных данных, отображаемых в одно и то же значение [25].

Алгоритм и процедура вычисления хэш-функции для любой последовательности двоичных символов, которые применяются в криптографических методах защиты информации, описаны в стандарте ГОСТ 34.11-2018.

Исходными данными для процедуры вычисления хэш-кода H(M) является подлежащее хэшированию сообщение M ∈ V* и IV ∈ V512 - инициализационный вектор [25].

Алгоритм вычисления функции Н состоит из следующих этапов.

Этап 1:

1) присвоить h := IV;

2) присвоить N := 0512 ∈ V512 ;

3) присвоить Σ := 0512 ∈ V512 ;

4) перейти к этапу 2.

Этап 2:

1) проверить выполнение условия |M |< 512 (при положительном исходе перейти к этапу 3, при отрицательном к пунктам 2-7 этапа 2);

2) вычислить подвектор m ∈ V512 сообщения M: M = M||m;

3) присвоить h := gN(h, m);

4) присвоить N := Vec512(Int512(N) ⊞ 512);

5) присвоить Σ := Vec512(Int512(Σ) ⊞ Int512(m));

6) присвоить M :=M’;

7) перейти к шагу 1 этапа 2.

Этап 3:

1) присвоить m := 0511-|M| ||1|| M;

2) присвоить h := gN(h, m);

3) присвоить N := Vec512(Int512(N) ⊞ |M|);

4) присвоить Σ := Vec512(Int512(Σ) ⊞ Int512(m));

5) присвоить h := g0(h, N);

6)

7) конец работы алгоритма [25].

Значение величины h, полученное на шаге 6 этапа 3, является значением функции хэширования Н(М).

Приведенному алгоритму с длинной ключа 256 бит соответствует такая функция хэширования как SHA-256.

Так как на сегодняшний день существует множество готовых решений для внедрения описанных алгоритмов шифрования и хэширования, нет необходимости вручную программировать данные алгоритмы. Для реализации описанного алгоритма шифрования воспользуемся такой сторонней библиотекой Python3 как goscrypto, а для реализации описанного алгоритма хэширования – встроенной библиотекой hashlib.

2.3.4 Описание и внедрение функции экранирования специальных символов

Под экранированием символов подразумевается замена в тексте управляющих символов на соответствующие текстовые подстановки. Языки программирования, текстовые командные интерфейсы, языки разметок текста имеют дело со структурированным текстом, в котором некоторые символы и их комбинации используются в качестве управляющих. Экранирование специальных символов используется для того, чтобы указать системе, когда воспринимать эти символы как часть кода, а когда как обычный текст, с которым код работает.

Для преобразования специальных символов в безопасные последовательности в языке программирования Python предусмотрена функция html.escape() модуля html.

2.4 Описание алгоритма работы модели с учетом функций, обеспечивающих информационную безопасность

На основании пунктов 2.3.1-2.3.4 можно составить алгоритм работы модели системы после внедрения функций безопасности:

  1. зарегистрированный в системе отправитель заходит на сайт и в специальную форму вводит свой логин и пароль, которые POST-запросом отправляются на сервер;
  2. на сервере проверяется наличие логина пользователя в базе данных;
  3. сравнивается хэш от введенного пользователем пароля с хэшем, хранящимся в базе данных;
  4. проверяется не истекло ли время действия учетной записи;
  5. в случае успешных проверок сервер предоставляет доступ к html-странице с формой для отправки сообщения, в случаи хотя бы одной неудачной проверки сервер возвращает отправителю GET-ответ с отказом;
  6. отправитель в специальную форму вводит сообщение (текст или файл), а также логин получателя, далее производятся действия описанные в пунктах 2-4 алгоритма работы модели, представленного выше;
  7. в базу данных записываются идентификатор, время удаления, тип (текст или файл), половина ключа шифрования, а также логин отправителя и логин получателя сообщения далее производятся действия описанные в пунктах 6-7 алгоритма работы модели, представленного выше;
  8. получатель, перейдя по ссылке вводит свой логин и пароль, которые POST-запросом отправляются на сервер;
  9. на сервере выполняются проверки, описанные в пунктах 2-4 данного алгоритма работы модели;
  10. в случаи успешных проверок выполняются действия, описанные в пунктах 9-12 алгоритма работы модели, представленного выше, в случаи хотя бы одной неудачной проверки сервер возвращает отправителю GET-ответ с отказом.

Схема алгоритма приведена на рисунке В.3.

Программный код реализации алгоритма приведен в Приложениях Г. Примеры внешнего вида модели системы представлены на рисунках 2.6 – 2.9.

Рисунок 2.6 – Стартовая страница после внедрения функций безопасности

Рисунок 2.7 – Форма отправки сообщения

Рисунок 2.8 – Ответ сервера на первый запрос доступа к сообщению

Рисунок 2.9 – Ответ сервера на второй запрос доступа к сообщению

Для проверки модели на адекватность воспользуемся таким инструментом для автоматизированного тестирования как PyTest. Результат тестирования при последовательном запуске тестов представлен на рисунке 2.10. Синтаксис программы тестов приведен в Приложении Г

Рисунок 2.10 – Результат тестирования модели на адекватность

Таким образом, разработана модель системы, генерирующей одноразовые ссылки в двух вариантах: защищенном и незащищенном.

2.5 Выводы по разделу

Знание о принципах и особенностях функционирования системы позволяют построить модель, имитирующую ее действия. Знание о принципах работы функций безопасности позволяет внедрить их в алгоритм работы модели.

Таким образом, разработана модель, имитирующая действия реальной системы передачи сообщений на основе одноразовых ссылок. В работу модели внедрены алгоритмы идентификации, аутентификации и авторизации, а также экранирование от специальных символов. Следовательно доказать, что предложенные функции безопасности повышают устойчивость систем к кибератакам можно, проведя эксперименты на модели.

3 Разработка методики защиты от MITM-атак в системах, генерирующих одноразовые ссылки для передачи сообщений

3.1 Проведение экспериментов на модели

3.1.1 Описание методики проведения экспериментов

Целью проведения экспериментов на модели является проверка того, что внедренный набор функций безопасности действительно обеспечивает устойчивость к кибератакам.

Для подтверждения или опровержения данной гипотезы предполагается решить следующие задачи:

  • проэксплуатировать типовые веб-уязвимости при помощи автоматизированного сканирования по методу «черного ящика»;
  • провести ручное тестирования на устойчивость к MITM-атакам.

Метод «черного ящика» является наиболее распространенным, так как позволяет проводить тестирование быстро и без лишних настроек. Он предполагает под собой, что тестировщик не имеет знания об архитектуре, коде и внутренней структуре приложения. В качестве тестировщика будет выступать специализированное программное обеспечение.

Ручное тестирование необходимо, так как данный метод не является всеобъемлющим и может пропустить уязвимые места.

3.1.2 Описание сценариев MITM-атак

MITM-атака – атака типа «человек посередине», при которой злоумышленник становится посредником в связи между двумя сторонами, считающими, что общаются непосредственно друг с другом. Такая атака приводит к нарушению сразу всех критериев безопасности информации: конфиденциальности, целостности и доступности [26].

По данным ФСТЭК MITM-атаки могут быть реализованы:

  • через HTTP-запросы;
  • через TLS/SSL-запросы;
  • через DNS-сервер;
  • путем создания поддельной точки доступа;
  • путем навязывания использования поддельного Proxy-сервера;
  • путем подмены ответов на широковещательные запросы разрешения сетевых имен (LLMNR, mDNS, NetBIOS).

Так как в системах, генерирующих одноразовые ссылки данные передаются по протоколу HTTPS, имеет смысл рассмотреть принцип MITM-атаки на протокол SSL, представленный на рисунке 3.1. Для проведения такой атаки злоумышленник для каждого TCP-соединения создает две отдельные SSL-сессии: первая устанавливается между клиентом и злоумышленником, вторая – между злоумышленником и сервером [27].

Рисунок 3.1 – Схема MITM-атаки на HTTPS

Таким образом, при реализации MITM-атаки все данные, передаваемые от клиента к серверу, идут через устройство злоумышленника. Реализовать такую атаку можно при помощи ARP-spoofing.

3.1.3 Обоснование выбора программных продуктов для проведения экспериментов

В качестве инструмента для автоматизированного сканирования по методу «черного ящика» предполагается использовать инструмент Wapiti. Wapiti – инструмент с открытым исходным кодом, который позволяет автоматически обнаруживать такие веб-уязвимости как SQL-инъекции, XSS-атаки, кросс-сайт скриптинг, недостатки аутентификации и авторизации и прочие. К ключевым преимуществам данного инструмента относятся:

  • гибкость – возможность гибкой настройки параметров сканирования;
  • модульность – возможность замены и настройки модулей сканирования;
  • широта покрытия – возможность сканирования при помощи всех основных технологий веб-разработки, AJAX и REST.

Для ручного тестирования на возможность реализации MITM-атакам предполагается использовать такой инструмент как Ettercap. Ettercap – это программное обеспечение для анализа и мониторинга сетевого трафика в реальном времени, но в отличие от похожего инструмента Wireshark, более приспособлен для реализации MITM-атак.

Так как в защищенном варианте модели системы для передачи данных используется протокол HTTPS. Для реализации MITM-атаки потребуется настроить Proxy-сервер. Для этого предполагается использовать инструмент Burp Suite.

Все предложенные инструменты предустановлены в системе Kali Linux.

3.2 Тестирование модели незащищенной системы на устойчивость к типовым сценариям атак

3.2.1 Сканирование на наличие веб-уязвимостей до внедрения функций, обеспечивающих информационную безопасность

Запуск с Kali Linux сканирования модели системы на наличие типовых веб-уязвимостей до внедрения функций, обеспечивающих информационную безопасность, приведен на рисунке 2.11. В данном случае «--flush-session» позволяет проводить повторное сканирование, при котором не будут учитываться предыдущие результаты. Сканирование проводится с подключением всех доступных модулей.

В результате сканирования выявлено 6 уязвимостей, связанных с возможность проведения XXS-атак, а также с отсутствием заголовков безопасности.

Рисунок 3.2 – Сканирование на типовые веб-уязвимости

Отчет о результатах сканирования приведен в Приложении Д на рисунке Д.1.

3.2.2 Реализация MITM-атак до внедрения функций, обеспечивающих информационную безопасности

Для реализации атаки переключаем Kali Linux в режим «форвардинга» при помощи команды, представленной на рисунке 2.12.

Рисунок 3.3 – Подготовка Kali Linux к MITM-атаке

Запускаем Ettercap и выбираем интерфейс eth0. При помощи графического интерфейса инструмента целью ставим машину с Ubuntu и ip-адресом 10.0.2.10. Далее запускаем ARP Poisoning с прослушиванием удаленного подключения. На рисунках 3.4 и 3.5 приведены снимки экранов при установке описанных настроек.

Рисунок 3.4 – Запуск Ettercap

Рис 3.5 – запуск ARP Poisoning

Результат удачной MITM-атаки при взаимодействии пользователя с системой приведен на рисунке 3.6.

Рисунок 3.6 – Результат удачной MITM-атаки при помощи Ettercap

3.3 Тестирование модели защищенной системы на устойчивость к типовым сценариям атак

3.3.1 Сканирование на наличие веб-уязвимостей после внедрения функций, обеспечивающих информационную безопасность

Запуск с Kali Linux сканирования модели системы на наличие типовых веб-уязвимостей после внедрения функций, обеспечивающих информационную безопасность приведен на рисунке 3.7. Сканирование, как и в подпункте 3.2.1 проводится с подключением всех доступных модулей.

Рисунок 3.7 – Сканирование на типовые веб-уязвимости

По итогам сканирования уязвимостей не выявлено. Отчет о результатах сканирования приведен в Приложении Д,на рисунке Е.2.

3.3.2 Реализация MITM-атак после внедрения функций, обеспечивающих информационную безопасности

Для реализации атаки переключаем Kali Linux в режим форвардинга, а также при помощи iptables перенаправляем трафик на порт 8080, на котором будет запущен Proxy-сервер. Правило iptables приведено на рисунке 3.8.

Рисунок 3.8 – Подготовка Kali Linux к MITM-атаке

Далее снова запускаем Ettercap (рисунок 3.9).

Рисунок 3.9 – Запуск Ettercap

На рисунке 3.10 представлен пример перехватываемых данных, которыми обменивается клиент. Информация действительно передается в зашифрованном виде, но нарушитель все равно может перехватить данные настроив Proxy-сервер.

Рисунок 2.10 – Перехват HTTPS-трафика

На рисунке 2.20 приведена настройка Proxy-сервера. Он запущен при помощи Burp Suite на порту, который был указан для перенаправления трафика, а именно 8080.

Рисунок 3.11 – Настройка Proxy-сервера

На рисунках 3.12 и 3.13 представлены результаты удачных MITM-атаки при перехвате одноразовой ссылки и аутентификационной информации.

Рисунок 3.12 ­­– Результат перехвата одноразовой ссылки

Рисунок 3.13 ­­– Результат перехвата аутентификационной информации

3.4 Оценка результатов экспериментов

В результате экспериментов выявлено, что после внедрения функций безопасности закрыты шесть уязвимостей, но осталась актуальной уязвимость к MITM-атаке [УКПК-2. ГИА].

После внедрения функций безопасности для получения доступа к сообщению злоумышленнику недостаточно перехватить только одноразовой ссылки, ему также нужно перехватить аутентификационную информацию, что усложняет процесс получения несекционного доступа к сообщению, но не обеспечивает достаточную конфиденциальность. Следовательно, необходима разработка методики защиты от перехвата аутентификационной информации.

3.5 Разработка алгоритма защиты от MITM-атак на стороне сервера

3.5.1 Описание технологии строгой транспортной безопасности

Так как для перехвата аутентификационной информации реализация MITM-атаки на протокол HTTPS осуществляется при помощи подмены защищенного варианта подключения клиента на незащищенный (замена HTTPS протокола на HTTP), имеет смысл заставить клиента использовать только протокол HTTPS. Реализовать такой подход можно при помощи технологии HSTS.

HSTS – политика строгой транспортной безопасности HTTP, описанная в стандарте RFC 6797. Политика объявляется веб-сайтами через поле заголовка HTTP-ответа или другими способами, такими как, например, настройка пользовательского агента [28].

Механизм работы заключается в том, что, когда пользователь впервые получает заголовок «Strict Transport Security», браузер запоминает это и автоматически перенаправляет все будущие запросы к ресурсу через HTTPS.

Пример заголовка, который сообщает браузеру, что срок действия составляет один год: «Strict-Transport-Security: max-age=31536000». Если в течении этого срока действие SSL-сертификата прекратиться, то соединение будет автоматически разорвано.

Если при использовании политики строгой транспортной безопасности происходит попытка переключения на HTTP, браузер автоматически перенаправляет пользователя на HTTPS. Возникновение любых ошибок или предупреждений, включая ошибку проверки подлинности сертификата (не доверенный сертификат), при попытке установить безопасное соединение приводит к разрыву соединения. Это одновременно и преимущество и недостаток, так как с одной стороны HSTS во всех соединениях, кроме первого, исключает возможность подмены сертификата на самоподписанный, с другой – если подмена все-таки произошла, приводит к отказу в обслуживание (нарушение такого критерия информационной безопасности как доступность).

Исключение возможности подмены сертификата приводит к исключению возможности проведения MITM-атаки на SSL, но так как список предварительной загрузки HSTS не содержит никакой информации о самом сертификате, первое подключение остается незащищенным, следовательно, оно может быть перехвачено злоумышленником. Для борьбы с этой проблемой большинство современных браузеров использует дополнительный статический список сайтов, требующих использования протокола HTTPS. Полностью такой подход проблему не решает, так как злоумышленник все еще может скомпрометировать браузер клиента и вставить самостоятельно подписанный сертификат, который будет доверенным по умолчанию. Особенно это актуально в корпоративной инфраструктуре, где есть локальный доверенный центр, который может быть скомпрометирован и часто выступает поставщиком сертификатов для локальных сервисов.

Таким образом, для защиты от MITM-атак в системах, генерирующих одноразовые ссылки для передачи сообщений, технологии HSTS недостаточно, следовательно, вместе с ней необходимо применение других методов. Таких как двухфакторная или беспарольная аутентификация.

3.5.2 Описание метода двухфакторной аутентификации

В процессе аутентификации применяются такие факторы как:

  • фактор знания – информация, которая известна субъекту (пароль, ПИН-код, контрольное слово и так далее);
  • фактор владения – что-то, чем субъект обладает (электронная или магнитная карта, токен и прочее);
  • фактор свойства – как правило, это биометрические данные (лицо, голос, отпечатки пальцев, радужная оболочка глаза) [29].

Многофакторная или многоуровневая аутентификация – это процесс проверки подлинности объектов или пользователей, основанный на использовании, по крайней мере, двух независимых факторов аутентификации [30].

Классической формой проверки подлинности клиента является аутентификация на основе фактора знания с применением логина и пароля. Такая форма для прохождения процедуры авторизации подразумевает предоставление клиентом пары логина пароля. Демонстрация на модели показала, что однофакторная аутентификация уязвима к перехвату этой пары посредствам реализации MITM-атаки, следовательно, имеет смысл использование второго дополнительного фактора для проверки подлинности клиента.

Если принять фактор знания как первый уровень аутентификации пользователя, то в качестве второго должен выступать либо фактор владения, либо фактор свойства. Так как исследуемые системы реализованы в виде web-сайтов, отсутствует возможность дополнительно использовать специальное оборудование, как, например, сканер отпечатков пальцев или считыватель электронной карты. Следовательно, в распоряжении остаются только такие методы как:

  • электронная почта или SMS-код – пользователь получает одноразовый код ограниченного срока действия, который необходимо ввести для завершения процесса аутентификации, или ссылку, перейдя по которой он подтверждает свою личность;
  • приложение-аутентификатор – метод похож на получение кода по SMS, но вместо мобильного оператора или SMS-сервиса используется специальное программное обеспечение, где для авторизации генерируется превечный ключ (например QR-код), в котором содержится одноразовый пароль на основе криптографического алгоритма;
  • мобильные приложения – комбинация двух предыдущих методов, где вместо одноразовых кодов, паролей и ссылок используется подтверждение входа через приложение, установленное на мобильном устройстве пользователя [31].

Проблема заключается в том, что если злоумышленник прослушивает сразу несколько портов клиента, то потенциально любые данные передаваемые или получаемые клиентом могут быть перехвачены. Следовательно, двухфакторная аутентификация как способ защиты от MITM-атак сработает только в том случаи, когда аутентификационная информация передается в обход соединения между клиентом и сервером. Гарантировать это может только другой канал связи или другое устройство (рисунок 3.14), например, смартфон клиента.

Рисунок 3.14 – Применение метода 2FA

3.5.3 Применение метода беспарольной аутентификации

Если предположить, что соединение между клиентом и сервером скомпрометировано, иными словами, передаваемые логин и пароль будут перехвачены, то смысл их использования теряется. Следовательно, предлагается не передавать аутентификационную информацию между клиентом и сервером, то есть использовать метод беспарольной аутентификации [УКУК-1 ГИА]. Если учесть, что под беспарольной аутентификацией подразумевается способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей, то алгоритм аутентификации в таком случаи будет состоять из следующих этапов:

  1. пользователь отправляет запрос на аутентификацию и идентификатор на web-сервер;
  2. web-сервер отправляет запрос на аутентификацию и идентификатор пользователя на сторонний сервер аутентификации;
  3. сервер аутентификации отправляет запрос на аутентификацию на мобильное приложение пользователя;
  4. пользователь подтверждает вход;
  5. мобильное приложение отправляет ответ с подтверждением на сервер аутентификации;
  6. сервер аутентификации отправляет ответ с подтверждением на web-сервер;
  7. web-сервер предоставляет пользователю доступ к его учетной записи и функционалу системы.

Схема алгоритма приведена на рисунке 3.15. Примером реализации такого алгоритма является Telegram Login Widget.

Рисунок 3.15 – Схема алгоритма беспарольной аутентификации

3.6 Разработка рекомендаций по защите от MITM-атак на стороне клиента

Большинство современных браузеров имеют статический список сайтов, требующих использование протокола HTTPS, при наличии проблем с сертификатом браузер блокирует подключение. В таком случае пользователю будет выведено предупреждение, пример которого представлен на рисунке 3.16.

Рисунок 3.16 – Пример предупреждения о недовернном сертификате

Ключевым условием для перехвата информации, передаваемой между клиентом и сервером, является наличие у атакующего доступа к сети, следовательно, очевидная рекомендация по защите от MITM-атак – не подключаться к системе из открытых сетей.

Таким образом рекомендации для пользователя по защите от перехвата аутентификационной информации состоят в:

  • реагировании на предупреждение о недоверенном сертификате;
  • подключении к системе только из закрытой сети;
  • использовании статических таблиц для защиты сегмента сети, что также подразумевает под собой установку на роутере статического типа адресации.

3.7 Оценка эффективности разработанной методики

Докажем эффективность разработанной методики на модели угроз безопасности информации исследуемой системы.

При определении негативных последствий от реализации (возникновения) угроз безопасности информации такой вид риска (ущерба) как ущерб государству в области обеспечения обороны страны, безопасности государства и правопорядка, а также в социальной, экономической, политической, экологической сферах деятельности не учитывается, так как предполагаем, что исследуемая система ориентирована только на физических и юридических лиц. В соответствии с методикой оценки угроз безопасности информации ФСТЭК остаются риски для физических и юридических лиц.

Так как исследуемая система предназначена для обмена сообщениями, основным негативным последствием является нарушение тайны переписки, которое в зависимости от содержания передаваемых сообщений может привести к другим последствиям, приведенным в используемом методическом документе.

Для определения границ процесса оценки угроз безопасности информации и разработки модели угроз безопасности информации определим совокупность объектов воздействия и их интерфейсов. На основании примера распределения границ при оценке угроз безопасности информации между оператором и поставщиком услуг, приведенном в используемом методическом документе, к возможным объектам воздействия можно отнести: платформу виртуализации, аппаратную платформу, систему хранения данных, сетевую инфраструктуру.

Определим возможные антропогенные источники угроз безопасности информации при помощи составления модели нарушителя. Нарушители признаются актуальными для систем и сетей, когда возможные цели реализации ими угроз безопасности информации могут привести к определенным для систем и сетей негативным последствиям и соответствующим рискам (видам ущерба). Из предложенных видов нарушителей, подлежащих оценке достаточной мотивацией, обладают только:

  • отдельные физические лица (хакеры);
  • конкурирующие организации;
  • системные администраторы и администраторы безопасности;
  • бывшие пользователи.

Модель нарушителя приведена в Приложении Е. Возможные цели и уровни возможностей нарушителей по реализации угроз безопасности информации приведены в таблицах Е.1 и Е.2 соответственно. Таким образом, результат определения актуальных нарушителей при реализации угроз безопасности информации и соответствующие им возможности приведены в Таблице Е.3.

Возможные способы реализации (возникновения) угроз безопасности информации применительно к объектам воздействия приведены в Приложении Ж.

Угроза безопасности информации возможна, если имеются нарушитель или иной источник угрозы, объект, на который осуществляются воздействия, способы реализации угрозы безопасности информации, а реализация угрозы может привести к негативным последствиям. Актуальность возможных угроз безопасности информации определяется наличием сценариев их реализации.

Таким образом, доказать эффективность применения разработанной методики можно на примерах сценариев реализации угроз безопасности информации, соответствующих способам реализации угроз безопасности информации. Определение сценариев предусматривает установление последовательности возможных тактик и соответствующих им техник, применение которых реализуемо актуальным нарушителем с соответствующим уровнем возможностей.

В качестве первого примера из нового раздела банка угроз ФСТЭК на основании таблицы, приведенной в Приложении Ф, возьмем возможную угрозу несанкционированного доступа к серверу за счет подбора (восстановления) аутентификационной информации (УБИ.2.2.17). Сценарий реализации данной угрозы приведен на 3.17.

Рисунок 3.17 – Сценарий реализации угрозы несанкционированного доступа за счет подбора аутентификационной информации

В качестве второго примера из нового раздела банка угроз ФСТЭК на основании таблицы, приведенной в Приложении Ф, возьмем возможную угрозу удаления информации, обрабатываемой сервером за счет атаки типа «человек посередине». Сценарий реализации данной угрозы приведен на рисунке 3.18.

Рисунок 3.18 – Сценарий реализации угрозы удаления информации, обрабатываемой сервером за счет атаки типа «человек посередине»

Предложенная методика защиты в первом примере исключает применения техники несанкционированного доступа путем подбора учетных данных и техники компрометации многократно используемого в различных системах пароля, что приводит к разрыву цепочки тактик. Во втором примере предложенная методика обеспечит бесполезность реализации атаки типа «человек посередине» для получения первоначального доступа, что также приведет к разрыву цепочки тактик. Следовательно, приведенные угрозы перестанут быть актуальными.

Таким образом, применение разработанной методики способствует снижению количества актуальных угроз для системы, из чего можно сделать вывод об эффективности ее применения.

3.8 Выводы по разделу

Результаты эксперементов показали, что внедрение функций безопасности повысило сложность реализации MITM-атаки, но не исключило возможность ее проведения. На основании чего было принято решение о применении технологии HSTS и метода беспарольной аутентификации, а также сформулированы некоторые рекомендации для пользователя [УКОПК-1. ГИА].

Моделирование угроз безопасности информации показало снижение количества актуальных угроз безопасности информации при применении разработанной методики.

Таким образом, разработанную методику защиты от перехвата аутентификационной информации в системах передачи одноразовых сообщений можно считать эффективной.

ЗАКЛЮЧЕНИЕ

В результате выпускной квалификационной работы разработана методика защиты от перехвата аутентификационной информации в системах передачи одноразовых сообщений. Она включает в себя модель системы передачи сообщений на основе одноразовых ссылок, алгоритм беспарольной аутентификации в таких системах и рекомендации для пользователя.

В ходе работы выявлены недостатки существующих систем для обмена сообщениями, которые были исправлены в имитационной модели. Эксперименты на модели также выявили недостатки системы, которые были исправлены при помощи методики защиты от перехвата аутентификационной информации.

Таким образом, решены следующие задачи:

  • проведен анализ существующих решений для обмена сообщениями;
  • разработана модель системы передачи одноразовых сообщений;
  • разработана методика защиты от перехвата аутентификационной информации.

На основании чего можно сделать вывод, что поставленная цель достигнута в полной мере.

Полученное решение можно использовать для разработки системы передачи одноразовых сообщений на основе методов беспарольной аутентификации, устойчивой к перехвату аутентификационной информации, что является поводом для дальнейших исследований.

СПИСОК ЛИТЕРАТУРЫ

1. Күйкенов С. Т. Разработка и функционирование электронной почты в сетях // EurasiaScience. – 2020. – 74-80 c.

2. Фрид Н., Боренштейн Н. Многоцелевые расширения интернет-почты (MIME), часть первая: Формат тел интернет-сообщений. – 1996. – №. rfc2045. URL: https://www.rfc-editor.org/rfc/rfc2045 (дата обращения 22.05.2023)

3. Колосов А. А. Защищенная система обмена электронной почтой на основе сертификатов открытых ключей // Безопасность информационных технологий. – 2009. – Т. 16. – №. 1. – 112-113 c.

4. Пакулин Н. В., Тугаенко А. Н. Тестирование протоколов электронной почты Интернета с использованием моделей // Труды Института системного программирования РАН. – 2011. – Т. 20. – 125-141 c.

5. Савватеев М. Е. Особенности работы почтовых клиентов // Ученые записки Брянского государственного университета. – 2020. – №. 2 (18). – 21-24 c.

6. Гелленс Р., Кленсин Дж. RFC 6409: Отправка сообщений по почте. – 2011. URL: http://www.faqs.org/rfcs/rfc2476.html (дата обращения 23.05.2023)

7. Настроить программу по протоколу POP3 // ЯндексСправка URL: https://yandex.ru/support/mail/mail-clients/others.html (дата обращения: 05.06.2023).

8. Пользовательское соглашение сервисов Яндекса // Яндекс Правовые документы URL: https://yandex.ru/legal/rules/ (дата обращения: 05.06.2023).

9. Кожухова П. О. О криптографической стойкости сквозных защищенных соединений в мессенджерах Whatsapp и Telegram // Безопасность информационных технологий. – 2017. – Т. 24. – №. 4. – 35-43 c.

10. Карабанов Р. Ю. Как выполняется шифрование в мессенджере Telegram. – 2018. URL: 10. https://elib.psu.by/bitstream/123456789/35259/1/62-63.pdf (дата обращения: 15.06.2023).

11. MTProto Mobile Protocol // Telegram URL: https://core.telegram.org/mtproto (дата обращения: 07.06.2023). 12. Telegram Privacy Policy // Telegram URL: https://telegram.org/privacy (дата обращения: 06.06.2023).

13. Jon Paterson. Telegram App Store Secret-Chat Messages in Plain-Text Database // Zimperium URL: https://www.zimperium.com/blog/telegram-hack/ (дата обращения: 06.06.2023).

14. Кришнамурти Б., Рексфорд Д. Web-протоколы. Теория и практика // М.: БИНОМ. – 2002. – 27 c.

15. Кришнамурти Б., Рексфорд Д. Web-протоколы. Теория и практика 185 с.

16. ГОСТ Р ИСО/МЭК 27033-4-2021. Информационные технологи. Методы и средства обеспечения безопасности. Безопасность сетей. Часть 4. Обеспечение безопасности межсетевого взаимодействия с использованием шлюзов безопасности = Information technology. Security techniques. Network security. Part 4. Securing communications between networks using security gateways : национальный стандарт Российской Федерации : издание официальное : утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 19 мая 2021 г. № 391-ст : введен впервые : дата введения 2021-11-30 / разработан подкомитетом ПК 27 "Методы и средства обеспечения безопасности ИТ" Совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК) : Электронный фонд правовых и нормативно-технических документов - Текст : непосредственный.

17. Кенесбекова А. К., Смагулов Р. Б. Корпоративный VPN: принцип работы и обзор решений // Передовые научно-технические и социально-гуманитарные проекты в современной науке. Сборник статей VI международной научно-практической конференции. Москва:«Научно-издательский центр «Актуальность. РФ», 2022.–236 с. ISBN 978-5-6048247-6-4. – 2022. – 64 с.

18. Сколько стоит информационная безопасность // Positive Technologies URL: https://www.ptsecurity.com/ru-ru/research/analytics/is-cost-2017/ (дата обращения: 07.06.2023).

19. ГОСТ Р ИСО/МЭК 27005-2010. Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности = Information technology. Security techniques. Information security risk management : национальный стандарт Российской Федерации : издание официальное : утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2010 г. № 632-ст : взамен ГОСТ Р ИСО/МЭК ТО 13335-3-2007 и ГОСТ Р ИСО/МЭК ТО 13335-4-2007 : дата введения 2011-12-01 : идентичен международному стандарту ИСО/МЭК 27005:2008 "Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности" (ISO/IEC 27005:2008 "Information technology - Security techniques - Information security risk management") : Электронный фонд правовых и нормативно-технических документов - Текст : непосредственный.

20. Уголовный кодекс Российской Федерации от 13 июня 1996 года № N 63-ФЗ. УК РФ Статья 272. Неправомерный доступ к компьютерной информации // КонсультантПлюс (дата обращения: 15.05.2023).

21. Уголовный кодекс Российской Федерации от 13 июня 1996 года № N 63-ФЗ. УК РФ Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей // КонсультантПлюс (дата обращения: 15.05.2023).

22. Дубаков А. А. Сетевое программирование: учебное пособие. Санкт-Петербург, 2013. 8 с.

23. ГОСТ Р 58833-2020. Защита информации. Идентификация и аутентификация. Общие положения = Information protection. Identification and authentication. General : национальный стандарт Российской Федерации : издание официальное : утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 10 апреля 2020 г. № 159-ст : введен впервые : дата введения 2020-05-01 / разработан Федеральной службой по техническому и экспортному контролю (ФСТЭК России), Закрытым акционерным обществом "Аладдин Р.Д." (ЗАО "Аладдин Р.Д.") и Обществом с ограниченной ответственностью "Научно-производственная фирма "КРИСТАЛЛ" (ООО "НПФ "КРИСТАЛЛ") : Электронный фонд правовых и нормативно-технических документов - Текст : непосредственный.

24. ГОСТ 34.12-2018. Информационная технология. Криптографическая защита информации. Блочные шифры = Information technology. Cryptographic data security. Block ciphers : межгосударственный стандарт : издание официальное : утвержден Приказом Федерального агентства по техническому регулированию и метрологии от 4 декабря 2018 г. № 1061-ст : введен взамен ГОСТ 28147-89 : дата введения 2019-06-01 / разработан Центром защиты информации и специальной связи ФСБ России с участием Открытого акционерного общества «Информационные технологии и коммуникационные системы» (ОАО «ИнфоТеКС») : Электронный фонд правовых и нормативно-технических документов - Текст : непосредственный.

25. ГОСТ 34.11-2018. Информационная технология. Криптографическая защита информации. Функция хэширования = Information technology. Cryptographic data security. Hash-function : межгосударственный стандарт : издание официальное : утвержден Приказом Федерального агентства по техническому регулированию и метрологии от 4 декабря 2018 г. N 1061-ст : введен впервые : дата введения 2019-06-01 / Центром защиты информации и специальной связи ФСБ России с участием Открытого акционерного общества "Информационные технологии и коммуникационные системы" (ОАО "ИнфоТеКС") : Электронный фонд правовых и нормативно-технических документов - Текст : непосредственный.

26. Арзуманян Э. А., Чумаков А. А. МИТМ-атака. Угроза информационной безопасности в РФ // Znanstvena Misel. – 2019. – №. 8-1. – 37-40 с.

27. Грибунин В. Г., Стародубцев П. Е., Токарев Д. А. Решения по перехвату и чтению информации, передаваемой по сетевым протоколам, защищенным SSL //Известия Института инженерной физики. – 2014. – №. 2. –6-10 c.

28. Ходжес Дж., Джексон К., Барт А. Строгая транспортная безопасность Http (hsts). – 2012. – №. rfc6797.

29. ГОСТ Р 58833-2020

30. Богданов Д. С., Клюев С. Г. Классификация и сравнительный анализ технологий многофакторной аутентификации в Веб-приложениях //Моделирование, оптимизация и информационные технологии. – 2020. – Т. 8. – №. 1. – 17-18 c.

31. Юрьев Дмитрий Русланович, Рогова Олеся Сергеевна Сравнительный анализ двухфакторной аутентификации // Технические науки – от теории к практике. 2017. №6 (66). URL: https://cyberleninka.ru/article/n/sravnitelnyy-analiz-dvuhfaktornoy-autentifikatsii (дата обращения: 18.06.2023). 46-51 c.

Приложение А

Схема алгоритма работы ситемы

Рисунок А.1 – Схема алгоритма работы системы

Приложение Б

Программная реализация алгоритма модели системы

Б.1 Сервер

from http.server import HTTPServer, CGIHTTPRequestHandler

from threading import Thread

import cx_Oracle, time, datetime

class FirstHandler(CGIHTTPRequestHandler):

def check_url(self, URL):

if '&' in URL:

URL = 'open_message.html'

if self.path == '/':

URL = 'index.html'

self.path = URL

def do_GET(self):

self.check_url(self.path)

return CGIHTTPRequestHandler.do_GET(self)

class BaseDate(object):

def connect_db(self):

with open ('auth_db.txt', 'r') as db_file:

text = db_file.readlines()

login = text[0]

password = text[1]

return cx_Oracle.connect(f'{login[:-1]}/{password}@localhost:1521/xe')

 

def del_db(self, fromm, value):

db = self.connect_db()

db_req = f"DELETE FROM {fromm} WHERE time < '{value}';"

db_value = db.cursor().execute(db_req)

db.commit()

def start_server():

server_address = ("192.168.0.101", 3000)

with HTTPServer(server_address, FirstHandler) as httpd:

httpd.serve_forever()

def timer():

while True:

time.sleep(86400)

time_now = datetime.datetime.now()

BaseDate.del_db('users', time_now)

BaseDate.del_db('secrets', time_now)

Thread(target=timer).start()

Thread(target=start_server).start()

Продолжение приложения Б

Б.2 Клиент

<!DOCTYPE html>

<html lang = "ru">

<head>

<title>Отпарвить сообщение</title>

<meta charset="utf-8">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

<form method="post" enctype="multipart/form-data" action = "/cgi-bin/form.py">

<h3 class="form_title">ОТПРАВИТЬ СООБЩЕНИЕ<br></h3>

<div class="input_group">

<input type="text" placeholder = "Текст секретного сообщения" name = "secret"/> <br>

<input type="file" name = "secret_file"/> <br>

<small class = "text">Если Вы хотите отправить файл, оставьте поле сообщения пустым </small> <br>

<button class="big_button" type="submit" name="button" value="send"> ОТПРАВИТЬ </button> <br>

</div>

</form> <br>

</body>

</html>

Продолжение приложения Б

Б.3 Обработчик форм

import os, cgi, html, http.cookies

import check_api, html_pages

def main():

form = cgi.FieldStorage()

button = form.getfirst("button") #кнопки

if button == 'send':

secret = form.getfirst("secret")

 

if form.getfirst("secret") == '':

f = form["secret_file"]

if f.filename:

fn = os.path.basename(f.filename)

open_text = f.file.read()

data = dict()

data['file_name'] = fn

data['text_b'] = open_text

check = check_api.send_message(data, 'file')

html_pages.response(f"Отправьте ссылкку: {check}")

else:

check = check_api.send_message(secret, 'text')

if check == False: html_pages.response('Ошибка проверки получателя')

else: html_pages.response(f"Отправьте ссылкку: {check}")

if button == 'open':

url = os.environ.get("HTTP_REFERER")[26:]

text = check_api.open_message(url)

 

if text == False: html_pages.response('Ошибочная ссылка или сообщение предназначено другому пользователю')

elif text['type'] == 'text': html_pages.response(text['text'])

elif text['type'] == 'file':

html_pages.mes(text['file_name'], text['value'])

if __name__ == "__main__":

main()

Продолжение приложения Б

Б.4 Динамические страницы

def response(text):

print ("Content-type:text/html; charset=utf-8")

print()

content = f"""

<html lang = "ru">

<head>

<title>Ответ сервера</title>

<meta charset="PyCharm">

<link rel="stylesheet" href="/css/style_answer.css">

</head>

<body>

<h3 class = "text"> {text} </h3>

</body> """

print(content)

def send_message(login):

cookie = f"Set-cookie: user={login}; path=/cgi-bin/; httponly"

print(cookie)

print ("Content-type:text/html\n; charset=utf-8")

content = """

<html lang = "ru">

<head>

<title>Отпарвить сообщение</title>

<meta charset="utf-8">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

<form method="post" enctype="multipart/form-data" action = "/cgi-bin/form.py">

<h3 class="form_title">ОТПРАВИТЬ СООБЩЕНИЕ<br></h3>

<div class="input_group">

<input type="text" placeholder = "Логин получателя" name = "recipient" required//> <br>

<input type="text" placeholder = "Текст секретного сообщения" name = "secret"/> <br>

<input type="file" name = "secret_file"/> <br>

<small class = "text">Если Вы хотите отправить файл, оставьте поле сообщения пустым </small> <br>

Продолжение приложения Б

<button class="big_button" type="submit" name="button" value="send"> ОТПРАВИТЬ </button> <br>

</div>

</form> <br>

</body>

"""

print(content)

def show_message(file_name):

print ("Content-type:text/html; charset=utf-8")

print()

content = f"""

<html lang = "ru">

<head>

<title>Ответ сервера</title>

<meta charset="PyCharm">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

<button class="big_button" name="button" value="show" onclick="window.location.href = 'http://localhost:3000/files/{file_name}';"> ОТКРЫТЬ </button> <br>

</body> """

print(content)

def mes(file_name_new, open_text):

print('Content-type: application/octet-stream')

print(f'Content-Disposition: attachment; filename="{file_name_new}"')

print()

print(f'{open_text}')

Продолжение приложения Б

Б.5 API

import random, string

import gostcrypto, hashlib

import os, glob, datetime

import cx_Oracle

class BaseDate(object):

"""Работа с базой данных"""

def connect_db(self):

with open ('auth_db.txt', 'r') as db_file:

text = db_file.readlines()

login = text[0]

password = text[1]

return cx_Oracle.connect(f'{login[:-1]}/{password}@localhost:1521/xe')

def add_message(self, id, recipient, sender, message, time, key):

db = self.connect_db()

sql = f"INSERT INTO secrets (id, recipient, sender, message, time, key) VALUES ('{id}', '{recipient}', '{sender}', '{message}', '{time}', '{key}');"

db.cursor().execute(sql, [id, recipient, sender, message, time, key])

db.commit()

db.close()

def cheсk_message(self, id):

db = self.connect_db()

db_value = db.cursor().execute(f"SELECT id, recipient, sender, message, time, key FROM secrets WHERE id ='{id}';").fetchone()

try:

values = dict() #создаем словарь

values['id'] = db_value[0]

values['message'] = db_value[3]

values['time'] = datetime.datetime.strptime(db_value[4], '%Y-%m-%d %H:%M:%S.%f')

values['key'] = db_value[5]

return values

except TypeError: return False

finally: db.close()

def del_db(self, id):

db = self.connect_db()

db.cursor().execute(f"DELETE FROM secrets WHERE id = {id}")

db.commit()

db.close()

 

def encryption(message, key):

Продолжение приложения Б

obj = gostcrypto.gostcipher.new('kuznechik', key.encode('utf-8'), gostcrypto.gostcipher.MODE_ECB, pad_mode=gostcrypto.gostcipher.PAD_MODE_1)

encrypted_text = obj.encrypt(message.encode('utf-8'))

return encrypted_text

def decryption(message, key):

obj = gostcrypto.gostcipher.new('kuznechik', key.encode('utf-8'), gostcrypto.gostcipher.MODE_ECB, pad_mode=gostcrypto.gostcipher.PAD_MODE_1)

decryption_text = obj.decrypt(message).decode('utf-8')

return decryption_text

db = BaseDate()

def send_message(data, type):

id = ''.join([random.choice(string.ascii_letters + string.digits) for i in range(16)])

time = str(datetime.datetime.now() + datetime.timedelta(days = 7))

key = ''.join([random.choice(string.ascii_letters + string.digits) for i in range(32)])

kye_db = key[16:]

link = 'http://192.168.0.101:3000/' + id + '&' + key[:16]

if type == 'text':

encryption_message = encryption(data, key)

with open ('messages/' + id + '.txt', 'wb') as new_file:

new_file.write(encryption_message)

elif type == 'file':

with open ('files/' + id + '_' + data['file_name'], 'wb') as new_file:

encription_text = encryption(data['text_b'].decode('utf-8'), key)

new_file.write(encription_text)

db.add_message(id, 'Anonim', 'Anonim', type, time, kye_db)

return link

def open_message(link):

id = link[:16]

message = db.cheсk_message(id)

if message == False: return False

elif datetime.datetime.now() > message['time']: return False

else:

key = link[17:] + message['key']

text = dict()

text['type'] = message['message']

if message['message'] == 'text':

with open ('messages/' + id + '.txt', 'rb') as old_file:

encryption_text = old_file.read()

Продолжение приложения Б

try:

open_text = decryption(encryption_text, key)

except gostcrypto.gostcipher.gost_34_13_2015.GOSTCipherError: return False

finally: old_file.close()

os.remove('messages/' + id + '.txt') #удаляем

db.del_db(id)

text['text'] = open_text

elif message['message'] == 'file':

file_name = glob.glob(f'files/{id}*')[0]

with open(file_name, 'rb') as old_file:

encryption_text = old_file.read()

try:

open_text = decryption(encryption_text, key)

except gostcrypto.gostcipher.gost_34_13_2015.GOSTCipherError: return False

finally: old_file.close()

file_name_new = file_name[23:]

text['value'] = open_text

text['file_name'] = file_name_new

os.remove(file_name) #удаляем файл

db.del_db(id) # удаляем запись о файле    

return text

Приложение В

Схема алгоритма регистрации

Рисунок В.1 - Схема алгоритма регистрации

Продолжение приложения В

Рисунок В.2 - Схема алгоритма аутентификации

Продолжение приложения В

Рисунок В.3 - Схема алгоритма работы модели системы

Приложение Г

Программная реализация алгоритма модели системы
после внедрения функций безопасности

Г.1 Сервер

from http.server import HTTPServer, CGIHTTPRequestHandler

from threading import Thread

import cx_Oracle, time, datetime, ssl

class FirstHandler(CGIHTTPRequestHandler):

def do_GET(self):

self.send_response(200, "OK")

self.send_header('X-Frame-Options', 'deny')

self.send_header("X-XSS-Protection", "1; mode=block")

self.send_header('X-Content-Type-Options', 'nosniff')

self.send_header("Content-Security-Policy", "default-src 'self'")

self.send_header('Strict-Transport-Security', 'max-age=3600; includeSubDomains')

if '&' in self.path:

self.path = 'open_message.html'

if 'ssl' in self.path:

self.path = 'index.html'

if self.path == '/':

self.path = 'index.html'

return CGIHTTPRequestHandler.do_GET(self)

 

class BaseDate(object):

def connect_db(self):

with open ('auth_db.txt', 'r') as db_file:

text = db_file.readlines()

login = text[0]

password = text[1]

return cx_Oracle.connect(f'{login[:-1]}/{password}@localhost:1521/xe')

def del_db(self, fromm, value):

db = self.connect_db()

db.cursor().execute(f"DELETE FROM {fromm} WHERE time < '%s'" %value)

db.commit()

db.close()

def start_server():

with HTTPServer(('192.168.0.101', 5000), FirstHandler) as httpd:

ctx = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)

ctx.load_cert_chain('ssl/server.crt', keyfile='ssl/server.key')

Продолжение приложения Г

httpd.socket = ctx.wrap_socket(httpd.socket)

httpd.serve_forever()

def timer():

while True:

time.sleep(86400)

time_now = datetime.datetime.now()

BaseDate.del_db('users', time_now)

BaseDate.del_db('secrets', time_now)

Thread(target=timer).start()

Thread(target=start_server).start()

Продолжение приложения Г

Г.2 Стартовая страница

<!DOCTYPE html>

<html lang = "ru">

<head>

<title>Стартовая страница</title>

<meta charset="utf-8">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

<form method="post" action = "/cgi-bin/form.py">

<h3 class="form_title">ВОЙТИ<br></h3>

<div class="input_group">

<input type="text" placeholder = "Ваш логин" name = "login" minlength="5" required/> <br>

<input type="password" placeholder = "Ваш пароль" name = "password" minlength="8" maxlength="32" required/> <br>

<button class="big_button" type="submit" name = "button" value="enter"> ОТПРАВИТЬ </button> <br>

</div>

</form> <br>

<form method="post" onsubmit="return Matching_Passwords()" action = "/cgi-bin/form.py" name="R">

<h3 class="form_title">РЕГИСТРАЦИЯ<br></h3>

<div class="input_group">

<input type="text" placeholder = "Логин" name = "login_new" minlength="5" required/> <br>

<button class="generate_button" type="button" id="password_generation" onclick="Random_String()"> Сгенерировать пароль </button> <br>

<input type="password" placeholder = "Пароль" name = "password1" minlength="8" maxlength="32" id="password1" required/> <br>

<input type="password" placeholder = "Повторите пароль" name = "password2" minlength="8" maxlength="32" id="password2" required/> <br>

<button class="show_button" type="button" id="password_generation" onclick="Show_Password()"> Показать/Скрыть </button> <br>

<button class="big_button" type="submit" name="button" value="registration"> ЗАРЕГИСТРИРОВАТЬСЯ </button> <br>

<output type="text" name="registration_output" id="result"> </output>

</div>

</form> <br>

<script src="script.js"></script>

</body></html>

Продолжение приложения Г

Г.3 Страница аутентификации после перехода по ссылке

<!DOCTYPE html>

<html lang = "ru">

<head>

<title>Открыть сообщение</title>

<meta charset="utf-8">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

<form method="post" action = "/cgi-bin/form.py">

<h3 class="form_title">ВОЙТИ<br></h3>

<div class="input_group" >

<input type="text" placeholder = "Ваш логин" name = "login" minlength="5" required/> <br>

<input type="password" placeholder = "Ваш пароль" name = "password" minlength="8" maxlength="32" required/> <br>

<button class="big_button" type="submit" name="button" value="open"> ОТКРЫТЬ СООБЩЕНИЕ </button> <br>

</div>

</form> <br>

</body>

</html>

Продолжение приложения Г

Г.4 Обработчик форм

import os, cgi, html, http.cookies

import check_api, html_pages

def main():

form = cgi.FieldStorage()

button = form.getfirst("button") #кнопки

if button == 'enter':

login = html.escape(form.getfirst("login"))

password = html.escape(form.getfirst("password"))

check = check_api.check_user(login, password)

if check == True: html_pages.send_message(login)

elif check == False: html_pages.response('Ошибка входа')

if button == 'registration':

login = html.escape(form.getfirst("login_new"))

password = html.escape(form.getfirst("password1"))

registration = check_api.add_user(login, password)

if registration == True: html_pages.response('Вы зарегистрированы')

else: html_pages.response('Пользователь с таким логином уже существует, придумайте другой')

if button == 'send':

cookie = http.cookies.SimpleCookie(os.environ.get("HTTP_COOKIE"))

sender = cookie.get("user")

recipient = html.escape(form.getfirst("recipient"))

secret = html.escape(form.getfirst("secret"))

if form.getfirst("secret") == '':

f = form["secret_file"]

if f.filename:

fn = os.path.basename(f.filename)

open_text = f.file.read()

data = dict()

data['file_name'] = fn

data['text_b'] = open_text

check = check_api.send_message(data, 'file', sender.value, recipient)

if check == False: html_pages.response('Ошибка проверки получателя')

else: html_pages.response(f"Отправьте полльзователю {recipient} ссылкку: {check}")

else:

Продолжение приложения Г

check = check_api.send_message(secret, 'text', sender.value, recipient)

if check == False: html_pages.response('Ошибка проверки получателя')

else: html_pages.response(f"Отправьте полльзователю {recipient} ссылкку: {check}")

if button == 'open':

login = html.escape(form.getfirst("login"))

password = html.escape(form.getfirst("password"))

url = os.environ.get("HTTP_REFERER")[27:]

check = check_api.check_user(login, password)

text = check_api.open_message(url, login)

if check == False: html_pages.response('Ошибка входа')

elif text == False: html_pages.response('Ошибочная ссылка или сообщение предназначено другому пользователю')

elif text['type'] == 'text': html_pages.response(text['text'])

elif text['type'] == 'file':

html_pages.mes(text['file_name'], text['value'])

if __name__ == "__main__":

main()

Продолжение приложения Г

Г.5 Динамические страницы

def response(text):

print ("Content-type:text/html; charset=utf-8")

print()

content = f"""

<html lang = "ru">

<head>

<title>Ответ сервера</title>

<meta charset="PyCharm">

<link rel="stylesheet" href="/css/style_answer.css">

</head>

<body>

<h3 class = "text"> {text} </h3>

</body> """

print(content)

def send_message(login):

cookie = f"Set-cookie: user={login}; path=/cgi-bin/; httponly"

print(cookie)

print ("Content-type:text/html\n; charset=utf-8")

content = """

<html lang = "ru">

<head>

<title>Отпарвить сообщение</title>

<meta charset="utf-8">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

<form method="post" enctype="multipart/form-data" action = "/cgi-bin/form.py">

<h3 class="form_title">ОТПРАВИТЬ СООБЩЕНИЕ<br></h3>

<div class="input_group">

<input type="text" placeholder = "Логин получателя" name = "recipient" required//> <br>

<input type="text" placeholder = "Текст секретного сообщения" name = "secret"/> <br>

<input type="file" name = "secret_file"/> <br>

Продолжение приложения Г

<small class = "text">Если Вы хотите отправить файл, оставьте поле сообщения пустым </small> <br>

<button class="big_button" type="submit" name="button" value="send"> ОТПРАВИТЬ </button> <br>

</div>

</form> <br>

</body>

"""

print(content)

def show_message(file_name):

print ("Content-type:text/html; charset=utf-8")

print()

content = f"""

<html lang = "ru">

<head>

<title>Ответ сервера</title>

<meta charset="PyCharm">

<link rel="stylesheet" href="/css/style_index.css">

</head>

<body>

 

<button class="big_button" name="button" value="show" onclick="window.location.href = 'http://localhost:3000/files/{file_name}';"> ОТКРЫТЬ </button> <br>

 

</body> """

print(content)

def mes(file_name_new, open_text):

print('Content-type: application/octet-stream') #отдаем пользователю

print(f'Content-Disposition: attachment; filename="{file_name_new}"')

print()

print(f'{open_text}')

Продолжение приложения Г

Г.6 API

import random, string

import gostcrypto, hashlib

import os, glob, datetime

import cx_Oracle

class BaseDate(object):

"""Работа с базой данных"""

def connect_db(self):

with open ('auth_db.txt', 'r') as db_file:

text = db_file.readlines()

login = text[0]

password = text[1]

return cx_Oracle.connect(f'{login[:-1]}/{password}@localhost:1521/xe')

def add_message(self, id, recipient, sender, message, time, key):

db = self.connect_db()

sql = 'INSERT INTO secrets (id, recipient, sender, message, time, key) VALUES (:id, :recipient, :sender, :message, :time, :key)'

db.cursor().execute(sql, [id, recipient, sender, message, time, key])

db.commit()

db.close()

def cheсk_message(self, id):

db = self.connect_db()

db_value = db.cursor().execute("SELECT id, recipient, sender, message, time, key FROM secrets WHERE id = '%s'" %id).fetchone()

try:

values = dict()

values['id'] = db_value[0]

values['recipient'] = db_value[1]

values['sender'] = db_value[2]

values['message'] = db_value[3]

values['time'] = datetime.datetime.strptime(db_value[4], '%Y-%m-%d %H:%M:%S.%f')

values['key'] = db_value[5]

return values

except TypeError: return False

finally: db.close()

Продолжение приложения Г

def add_user(self, login, password, salt, time):

db = self.connect_db()

sql = 'INSERT INTO users (login, password, salt, time) VALUES (:login, :password, :salt, :time)'

db.cursor().execute(sql, [login, password, salt, time])

db.commit()

db.close()

def cheсk_users(self, login):

db = self.connect_db()

db_value = db.cursor().execute("SELECT login, password, salt, time FROM users WHERE login = '%s'" %login).fetchone()

try:

values = dict() #создаем словарь

values['login'] = db_value[0]

values['password'] = db_value[1]

values['salt'] = db_value[2]

values['time'] = datetime.datetime.strptime(db_value[3], '%Y-%m-%d %H:%M:%S.%f')

return values

except: return False

finally: db.close()

def del_db(self, id):

db = self.connect_db()

db.cursor().execute("DELETE FROM secrets WHERE id = '%s'" %id)

db.commit()

db.close()

 

def encryption(message, key):

obj = gostcrypto.gostcipher.new('kuznechik', key.encode('utf-8'), gostcrypto.gostcipher.MODE_ECB, pad_mode=gostcrypto.gostcipher.PAD_MODE_1)

encrypted_text = obj.encrypt(message.encode('utf-8'))

return encrypted_text

 

def decryption(message, key):

obj = gostcrypto.gostcipher.new('kuznechik', key.encode('utf-8'), gostcrypto.gostcipher.MODE_ECB, pad_mode=gostcrypto.gostcipher.PAD_MODE_1)

Продолжение приложения Г

decryption_text = obj.decrypt(message).decode('utf-8')

return decryption_text

db = BaseDate()

def add_user(login, password):

login = str(login)

password = str(password)

if db.cheсk_users(login) != False: return False

else:

salt = ''.join([random.choice(string.ascii_letters + string.digits) for i in range(16)])

hash_password = hashlib.sha256(password.encode('utf-8') + salt.encode('utf-8')).hexdigest()

time = str(datetime.datetime.now() + datetime.timedelta(days = 365))

db.add_user(login, hash_password, salt, time)

return True

def check_user(login, password):

login = str(login)

password = str(password)

user = db.cheсk_users(login)

if user != False:

hash_password = hashlib.sha256(password.encode('utf-8') + user['salt'].encode('utf-8')).hexdigest()

if hash_password != user['password']: return False

elif datetime.datetime.now() > user['time']: return False

else: return True

else: return False

def check_recipient(login):

user = db.cheсk_users(str(login))

time_del = datetime.datetime.strptime(user['time'], '%Y-%m-%d %H:%M:%S.%f')

if user == False: return False

elif datetime.datetime.now() > time_del: return False

else: return True

def send_message(data, type, sender, recipient):

user = db.cheсk_users(recipient)

id = ''.join([random.choice(string.ascii_letters + string.digits) for i in range(16)])

Продолжение приложения Г

if user != False and db.cheсk_users(sender) != False:

time = str(datetime.datetime.now() + datetime.timedelta(days = 7))

key = ''.join([random.choice(string.ascii_letters + string.digits) for i in range(32)])

kye_db = key[16:]

link = 'https://192.168.0.101:5000/' + id + '&' + key[:16]

if type == 'text':

data = str(data)

encryption_message = encryption(data, key) #шифруем сообщение

with open ('messages/' + id + '.txt', 'wb') as new_file:

new_file.write(encryption_message)

db.add_message(id, recipient, sender, type, time, kye_db)

return link

elif type == 'file':

with open ('files/' + id + '_' + data['file_name'], 'wb') as new_file:

encription_text = encryption(data['text_b'].decode('utf-8'), key)

new_file.write(encription_text)

db.add_message(id, recipient, sender, type, time, kye_db)

return link

else: return False

else: return False

def open_message(link, recipient):

try:

id = link[:16]

except TypeError: return False

message = db.cheсk_message(id)

if message == False: return False

elif datetime.datetime.now() > message['time']: return False

elif message['recipient'] != recipient: return False

else:

key = link[17:] + message['key']

text = dict()

text['type'] = message['message']

if message['message'] == 'text':

with open ('messages/' + id + '.txt', 'rb') as old_file:

encryption_text = old_file.read()

try:

open_text = decryption(encryption_text, key)

Продолжение приложения Г

except gostcrypto.gostcipher.gost_34_13_2015.GOSTCipherError: return False

finally: old_file.close()

os.remove('messages/' + id + '.txt') #удаляем

db.del_db(id)

text['text'] = f"Пользователь {message['sender']} отправил вам сообщение: {open_text}"

 

elif message['message'] == 'file':

file_name = glob.glob(f'files/{id}*')[0]

with open(file_name, 'rb') as old_file:

encryption_text = old_file.read()

try:

open_text = decryption(encryption_text, key)

except gostcrypto.gostcipher.gost_34_13_2015.GOSTCipherError: return False

finally: old_file.close()

 

file_name_new = file_name[23:]

text['text'] = f"Пользователь {message['sender']} отправиль вам файл"

text['value'] = open_text

text['file_name'] = file_name_new

return text

Приложение Д

Листинг тестов

import pytest, os, sys

import cx_Oracle

sys.path.insert(1, os.path.join(sys.path[0], '../cgi-bin'))

from check_api import add_user, check_user, send_message, open_message

@pytest.fixture(autouse=True)

def clear_db():

with open ('auth_db.txt', 'r') as db_file:

text = db_file.readlines()

login = text[0]

password = text[1]

db = cx_Oracle.connect(f'{login[:-1]}/{password}@localhost:1521/xe')

db.cursor().execute("DELETE FROM secrets")

db.cursor().execute("DELETE FROM users")

db.commit()

db.close()

@pytest.fixture

def reg():

add_user('Alisa', '12345678')

add_user('Bob123', '12345678')

def test_add_user(clear_db):

assert add_user('Alisa', '12345678') == True

assert add_user('Bob123', '12345678') == True

assert add_user('Alisa', '1234567890Ab') == False

assert add_user('User', 12345678) == True

assert add_user(12345678, '12345678') == True

assert add_user(None, '12345678') == True

assert add_user('User_1', None) == True

def test_check_user(reg):

assert check_user('Alisa', '12345678') == True

assert check_user('Bob123', '12345678') == True

assert check_user('User', '12345678') == False

assert check_user('Alisa', '12345678Ab') == False

assert check_user('Bob123', '12345678Ab') == False

assert check_user(12345, '12345678') == False

assert check_user('Alisa', 12345678) == True

Продолжение приложения Д

def test_send_messege_1(reg):

assert send_message('Test text', 'text', 'Alisa', 'Bob123') != False

assert send_message('Test text', 'text', 'Alisa', 'User') == False

assert send_message('Test text', 'text', 'User', 'Alisa') == False

assert send_message('Test text', 'text', 'User', 'Bob123') == False

def test_send_messege_2(reg):

assert send_message('Test text', 'text', 'Alisa', 12345) == False

assert send_message('Test text', 'text', 12345, 'Bob123') == False

assert send_message('Test text', 12345, 'Alisa', 'Bob123') == False

assert send_message(12345, 'text', 'Alisa', 'Bob123') != False

def test_send_messege_2(reg):

assert send_message(None, 'text', 'Alisa', 'Bob123') != False

assert send_message('Test text', None, 'Alisa', 'Bob123') == False

assert send_message('Test text', 'text', None, 'Bob123') == False

assert send_message('Test text', 'text', 'Alisa', None) == False

def test_open_message(reg):

link = send_message('Test text', 'text', 'Alisa', 'Bob123')[27:]

assert open_message(link[1:], 'Bob123') == False

assert open_message(link[:1], 'Bob123') == False

assert open_message(link, 'Alisas') == False

assert open_message(link, None) == False

assert open_message(None, 'Bob123') == False

assert open_message(12345, 'Bob123') == False

assert open_message(link, 12345) == False

assert open_message(link, 'Bob123') != 'Пользователь Alisa отправил вам сообщение: Test text'

assert open_message(link, 'Bob123') == False

if __name__ == "__main__":

pytest.main()

Приложение Е

Отчеты Wapiti

Рисунок Е.1 - Отчет Wapiti до внедрения функций безопасности

Продолжение приложения Е

Рисунок Е.2 - Отчет Wapiti после внедрения функций безопасности

Приложение Ж

Модель нарушителя

Таблица Ж.1 – Оценка целей реализации нарушителями угроз безопасности информации в зависимости от возможных негативных последствий и видов ущерба от их реализации

Виды

нарушителей

Возможные цели реализации угроз безопасности информации Соответствие целей видам риска (ущерба) и возможным негативным последствиям
Нанесение ущерба

физическому лицу

Нанесение ущерба юридическому лицу, индивидуальному предпринимателю
Специальные службы иностранных государств - - -
Террористические, экстремистские группировки - - -
Преступные группы (криминальные структуры) - - -
Отдельные физические лица (хакеры) +

(Получение финансовой или иной

материальной выгоды за счет кражи паролей, ключей и т. п. и дальнейшего их использования для получения доступа к другим ресурсам)

+

(Получение финансовой или иной

материальной выгоды за счет кражи конфиденциальных документов)

Нарушение тайны переписки
Конкурирующие организации - +

(Получение финансовой выгоды за счет увеличения кол-ва клиентов, дискредитация компании конкурента или ее полное уничтожение с целью укрепление положения на рынке, возможность стать монополистом)

Нарушение тайны переписки
Разработчики программных, программно-аппаратных средств - - -

Продолжение приложения Ж

Продолжение таблицы Ж.1

Виды

нарушителей

Возможные цели реализации угроз безопасности информации Соответствие целей видам риска (ущерба) и возможным негативным последствиям
Нанесение ущерба

физическому лицу

Нанесение ущерба юридическому лицу, индивидуальному предпринимателю
Лица, обеспечивающие поставку программных, программно-аппаратных

Средств, обеспечивающих систем

- - -
Поставщики услуг связи, вычислительных услуг - - -
Лица, привлекаемые для установки, настройки, испытаний,

Пусконаладочных и иных видов работ

- - -
Лица, обеспечивающие функционирование систем и сетей или

Обеспечивающих систем оператора

- - -
Авторизованные пользователи систем и сетей - - -
Системные администраторы и администраторы безопасности +

(непреднамеренные,

неосторожные или

неквалифицированные

действия)

+

(непреднамеренные,

неосторожные или

неквалифицированные

действия)

Нарушение тайны переписки
Бывшие пользователи +

(Получение финансовой или иной

материальной выгоды за счет кражи паролей, ключей и т. п. и дальнейшего их использования для получения доступа к другим ресурсам)

+

(Получение финансовой или иной

материальной выгоды за счет кражи конфиденциальных документов)

Нарушение тайны переписки

Продолжение приложения Ж

Таблица Ж.2 – Уровни возможностей нарушителей по реализации угроз безопасности информации

Уровень

возможностей

нарушителей

Возможности нарушителей по реализации угроз безопасности

информации

Виды нарушителей
Н1 Нарушитель,

обладающий

базовыми

возможностями

Имеет возможность при реализации угроз безопасности информации использовать только известные уязвимости, скрипты и инструменты.

Имеет возможность использовать средства реализации угроз (инструменты), свободно распространяемые в сети «Интернет» и разработанные другими лицами, имеет минимальные знания механизмов их функционирования, доставки и выполнения вредоносного программного обеспечения, эксплойтов.

Обладает базовыми компьютерными знаниями и навыками на уровне пользователя.

Имеет возможность реализации угроз за счет физических воздействий на технические средства обработки и хранения информации, линий связи и обеспечивающие системы систем и сетей при наличии физического доступа к ним.

Таким образом, нарушители с базовыми возможностями имеют возможность реализовывать только известные угрозы,

направленные на известные (документированные) уязвимости, с

использованием общедоступных инструментов

Физическое лицо (хакер)

Бывшие работники (пользователи)

Н2 Нарушитель,

обладающий

базовыми

повышенными

возможностями

Обладает всеми возможностями нарушителей с базовыми возможностями.

Имеет возможность использовать средства реализации угроз (инструменты), свободно распространяемые в сети «Интернет» и

разработанные другими лицами, однако хорошо владеет этими средствами и инструментами, понимает, как они работают и может вносить изменения в их функционирование для повышения эффективности реализации угроз.

Оснащен и владеет фреймворками и наборами средств, инструментов для реализации угроз безопасности информации и использования уязвимостей.

Конкурирующие организации

Системные администраторы и

администраторы безопасности

Продолжение приложения Ж

Продолжение таблицы Ж.2

Уровень

возможностей

нарушителей

Возможности нарушителей по реализации угроз безопасности

информации

Виды нарушителей
Имеет навыки самостоятельного планирования и реализации сценариев угроз безопасности информации.

Обладает практическими знаниями о функционировании систем и сетей, операционных систем, а также имеет знания защитных механизмов, применяемых в программном обеспечении, программно-аппаратных средствах.

Таким образом, нарушители с базовыми повышенными возможностями имеют возможность реализовывать угрозы, в том числе направленные на неизвестные (недокументированные) уязвимости, с использованием специально созданных для этого инструментов, свободно распространяемых в сети «Интернет». Не имеют возможностей реализации угроз на физически изолированные сегменты систем и сетей

Таблица Ж.3 – Актуальные нарушители при реализации угроз безопасности информации и соответствующие им возможности

Виды риска (ущерба) и возможные негативные

последствия

Виды актуального нарушителя Категория нарушителя Уровень возможностей нарушителя
Нарушение тайны переписки (У1, У2) Отдельные физические лица (хакеры) Внешний Н1
Конкурирующие организации Внешний Н2
Системные администраторы и администраторы безопасности Внутренний Н2
Бывшие пользователи Внешний Н1

Приложение И

Способы реализации

Вид нарушителя Категория нарушителя Объект воздействия Доступный интерфейс Способы реализации
1 Отдельные физические лица (хакеры) Внешний База данных Пользовательский веб-интерфейс Эксплуатация известных уязвимостей
Линия связи между клиентом и сервером Канал передачи данных между клиентом и сервером Прослушивание (захват) сетевого трафика
Сервер Пользовательский веб-интерфейс Внедрение вредоносного

программного обеспечения

Канал передачи данных между клиентом и сервером Атака типа "отказ в обслуживании"
2 Конкурирующие организации Внешний База данных Пользовательский веб-интерфейс Эксплуатация известных уязвимостей
Линия связи между клиентом и сервером Канал передачи данных между клиентом и сервером Атаки на уровне каналов и сети, приводящие к изменению маршрутов
Сервер Пользовательский веб-интерфейс Перебор паролей к учетной записи

Перебор утекших пар пользователь/пароль

Канал передачи данных между клиентом и сервером Атака типа "человек посередине"
3 Системные администраторы и администраторы безопасности Внутренний База данных Интерфейс

системы

администрирования

Нарушение цепочки услуг по администрированию
4 Бывшие пользователи Внешний База данных Пользовательский веб-интерфейс Эксплуатация известных уязвимостей
Линия связи между клиентом и сервером Канал передачи данных между клиентом и сервером Прослушивание (захват) сетевого трафика
Сервер Пользовательский веб-интерфейс Внедрение вредоносного

программного обеспечения

Канал передачи данных между клиентом и сервером Атака типа "отказ в обслуживании"

Приложение К

Показатели оценки результатов формирования компетенций, проверяемых в ходе выполнения и защиты ВКР

№ п.п. Код компетенции Перечень компонентов Средства оценки
1 УКУК-1.

ГИА

Знает: приемы использования творческого потенциала, совершенствования и развития своего интеллектуального и общекультурного уровня, профессионального роста.

Умеет: нести ответственность за принятые решения, свободно пользоваться русским языком и иностранным (со словарем).

Владеет: способностью к саморазвитию, навыками выполнения исследовательских работ, самостоятельного приобретения и использования в практической деятельности новых знаний и умений.

Уровень выполнения

пояснительной записки ВКР

Защита ВКР

2 УКОПК-1. ГИА Знает: современные тенденции обеспечения безопасности информации, технологии, методы и средства защиты информации.

Умеет: разрабатывать проектную и эксплуатационную документацию, модели угроз безопасности информации.

Владеет навыками: формирования требований по обеспечению информационной безопасности.

Уровень выполнения пояснительной записки ВКР

Защита ВКР

3 УКПКО-1.

ГИА

Знает: способы и средства защиты информации в автоматизированной системе.

Умеет: разрабатывать модели защищенных автоматизированных систем.

Владеет навыком: анализа уязвимостей, обоснования необходимости защиты информации в автоматизированной системе.

Уровень выполнения пояснительной записки ВКР

Защита ВКР

4 УКПК-1.

ГИА

Знает: методы оценки угроз и управления рисками информационной безопасности.

Умеет: определять и моделировать угрозы безопасности информации.

Владеет: навыками анализа безопасности компьютерных систем.

Уровень оформления пояснительной записки ВКР

Защита ВКР

5 УКПК-2.

ГИА

Знает: требования по защите информации в автоматизированных системах.

Умеет: осуществлять эксплуатацию систем защиты информации в автоматизированных системах.

Владеет навыками: формирования политик безопасности компьютерных систем и сетей, проведения инструментального мониторинга их защищенности.

Уровень оформления пояснительной записки ВКР

Защита ВКР

Приложение Л

Графические материалы

Рисунок Л.1 – Существующие решения

Рисунок Л.2 – Алгоритм работы модели зачищенной системы

Продолжение приложения Л

Рисунок Л.3 – Уязвимости

Рисунок Л.4 – Схемы атаки и защиты

Продолжение приложения Л

Рисунок Л.5 – Схема алгоритма беспарольной аутентификации

 

Похожие публикации
Целостное развитие творческого воображения в дидактической игре «необитаемый остров»
Дипломная работа "Целостное развитие творческого воображения в дидактической игре «необитаемый остров»" по специальности «Педагогическая психология».
Неотложная медицинская помощь на долгоиспытательном этапе при остром нарушении мозгового кровообращения
Дипломная работа по теме "Неотложная медицинская помощь на долгоиспытательном этапе при остром нарушении мозгового кровообращения"
Вопросы духовно-нравственного воспитания младшего школьника
Диплом "Вопросы духовно-нравственного воспитания младшего школьника" состоит из 80 страниц. Содержит таблицы, задания, игры, упражнения.
Разработка Интернет-магазина розничной продажи одежды
Диплом "Разработка Интернет-магазина розничной продажи одежды" состоит из 151 страниц. Содержит таблицы, диаграммы, листинг программных модулей.
Соединительные элементы в морфемной структуре слова в школьной практике
дипломная работа по теме "Соединительные элементы в морфемной структуре слова в школьной практике".