- •Введение
- •Глава 1. Информационно-телекоммуникационная система как объект атак, связанных с удаленным и непосредственным доступом к ее элементам
- •Механизмы взаимодействия элементов иткс
- •1.2. Понятие угрозы информационной безопасности иткс
- •1.3. Уязвимости иткс
- •1.3.1. Уязвимости иткс в отношении угроз удаленного доступа
- •1.4. Классификация и описание процессов реализации угроз удаленного доступа к элементам иткс
- •1.4.1. Классификация атак
- •1.4.1.2. Классификация удаленных атак
- •1.4.2. Описание атак как процессов реализации угроз
- •1.4.2.1. Описание процессов реализации угроз удаленного доступа к элементам иткс
- •Глава 2. Меры и средства защиты от атак, связанных с непосредственным и удаленным доступом к элементам иткс
- •2.1. Общее понятие о мерах и средствах защиты информации. Выбор актуальных направлений для защиты иткс от исследуемых атак
- •2.2. Криптографические меры
- •2.2.1. Применение криптографических протоколов
- •2.2.2. Создание виртуальных частных сетей
- •2.3. Применение межсетевых экранов
- •2.4.1. Виды межсетевых экранов
- •2.4.1.1. Фильтрующие маршрутизаторы
- •2.4.1.2. Шлюзы сеансового уровня
- •2.4.1.3. Шлюзы уровня приложений
- •2.4.2. Реализация функций межсетевых экранов
- •2.4.2.1. Механизм трансляции сетевых адресов
- •2.4.2.2. Дополнительная идентификация и аутентификация
- •2.4.3. Анализ достоинств и недостатков применения межсетевых экранов
- •2.5. Применение специфической конфигурации иткс для защиты от исследуемых атак
- •2.5.1. Применение коммутаторов в сети
- •2.5.2. Применение статических arp-таблиц
- •2.5.3. Специальные правила работы протоколов маршрутизации
- •2.5.4. Применение технологии «тонкого клиента»
- •Глава 3. Определение объектов защиты от угроз удаленного доступа
- •3.1. Определение множества объектов защиты
- •3.1.1. Определение множества типов иткс с учетом их назначения и специфики функционирования
- •3.1.2. Определение функциональных требований к иткс различных типов
- •3.1.3. Определение характеристик атак, реализуемых в отношении иткс различных типов
- •3.2.Определение множеств мер защиты, применимых для иткс различных типов
- •3.2.1. Обоснование требований безопасности для иткс различных типов
- •3.2.2. Рекомендации по реализации защиты иткс различных типов
- •3.3. Определение комплексов мер защиты иткс различных типов
- •3.3.1. Выявление соответствия применяемых мер защиты функциональным требованиям к иткс
- •3.3.2. Определение отношения рассматриваемых мер защиты к противодействию исследуемым атакам
- •Глава 4. Аналитическое моделирование процессов реализации угроз удаленного доступа к элементам иткс
- •4.1.Моделирование процессов реализации сетевого анализа
- •4.1.1. Сниффинг пакетов в сети без коммутаторов
- •4.1.2. Сканирование сети
- •4.2. Моделирование процесса реализации атаки «Отказ в обслуживании» (syn-flood)
- •4.3. Моделирование процессов реализации внедрения в сеть ложного объекта
- •4.3.1. Внедрение в сеть ложного объекта на основе недостатков алгоритмов удаленного поиска (arp-spoofing)
- •4.3.2. Внедрение в сеть ложного объекта путем навязывания ложного маршрута
- •4.4. Моделирование процессов реализации подмены доверенного объекта сети
- •4.4.1. Подмена доверенного объекта сети (ip-spoofing)
- •4.4.2. Подмена доверенного объекта сети. Перехват tcp-сессии (ip-hijacking)
- •4.5. Моделирование процессов реализации внедрения ложного dns-сервера
- •4.5.1. Внедрение ложного dns-сервера
- •4.5.2. Межсегментное внедрение ложного dns-сервера
- •Глава 5. Методика анализа и регулирования рисков при реализации нескольких угроз удаленного доступа к элементам иткс
- •5.1. Выбор параметров для осуществления количественного анализа рисков иткс
- •5.1.1. Определение видов ущерба иткс при реализации угроз удаленного доступа к ее элементам
- •5.1.2. Определение взаимосвязей между атаками и их отношения к видам наносимого ущерба
- •5.2. Определение вероятностей реализации атак
- •5.2.1. Выбор закона Пуассона в качестве закона распределения вероятностей возникновения атак
- •5.2.2. Расчет интенсивности возникновения атак
- •5.2.3. Расчет вероятности реализации атак
- •5.3. Расчет рисков реализации угроз удаленного доступа к элементам иткс
- •5.4. Расчет рисков реализации угроз, наносящих различный ущерб
- •5.4.1. Оценка ущерба от реализации атак
- •5.4.2. Оценка вероятностей реализации атак
- •5.4.3. Нахождение распределения вероятностей нанесения ущерба в условиях воздействия нескольких атак
- •Глава 6. Оценка эффективности применения комплексов мер противодействия угрозам удаленного доступа к элементам иткс
- •6.1. Понятие эффективности защиты информации
- •6.2. Алгоритм оценки эффективности применения комплексов мер
- •6.2.1. Введение функции соответствия исследуемого показателя требованиям
- •6.2.2. Расчет общей эффективности применения комплексов мер защиты иткс
- •6.3.Оценка соответствия функциональным требованиям при применении комплексов мер защиты
- •6.4. Оценка эффективности защиты иткс
- •6.4.1. Оценка вероятностных параметров реализации атак
- •6.4.1.1. Сниффинг пакетов в сети без коммутаторов
- •6.4.1.2. Сканирование сети
- •6.4.1.3. Отказ в обслуживании syn-flood
- •6.4.1.4. Внедрение ложного объекта (arp-спуфинг)
- •6.4.1.5.Внедрение ложного объекта (на основе недостатков протоколов маршрутизации)
- •6.4.1.6. Подмена доверенного объекта (ip-hijacking)
- •6.4.1.7. Подмена доверенного объекта (перехват сессии)
- •6.4.1.8. Внедрение ложного dns-сервера
- •6.4.2. Расчет рисков иткс при использовании мер противодействия угрозам удаленного доступа
- •6.4.3. Численная оценка эффективности защиты иткс
- •6.4.3.1.Оценка эффективности защиты иткс при фиксированной активности злоумышленника
- •6.4.3.2. Оценка защищенности иткс как функции от активности злоумышленника
- •6.5. Оценка общей эффективности применения комплексов мер защиты иткс
- •Заключение
- •Библиографический список
- •Глава 1. Информационно-телекоммуникационная система как объект атак, связанных с удаленным и непосредственным доступом к ее элементам 6
- •Глава 2. Меры и средства защиты от атак, связанных с непосредственным и удаленным доступом к элементам иткс 42
- •Глава 3. Определение объектов защиты от угроз удаленного доступа 87
- •Глава 4. Аналитическое моделирование процессов реализации угроз удаленного доступа к элементам иткс 112
- •Глава 5. Методика анализа и регулирования рисков при реализации нескольких угроз удаленного доступа к элементам иткс 158
- •Глава 6. Оценка эффективности применения комплексов мер противодействия угрозам удаленного доступа к элементам иткс 196
- •394026 Воронеж, Московский просп., 14
2.2. Криптографические меры
2.2.1. Применение криптографических протоколов
1. TLS (Transport Layer Security) предоставляет возможности аутентификации и безопасной передачи данных через Internet с использованием криптографических средств. Часто происходит лишь аутентификация сервера, в то время как клиент остается неаутентифицированным. Для взаимной аутентификации каждая из сторон должна поддерживать инфраструктуру открытого ключа (PKI), которая позволяет защитить клиент-серверные приложения от перехвата сообщений, редактирования существующих сообщений и создания поддельных.
SSL включает в себя три основных фазы:
1) диалог между сторонами, целью которого является выбор алгоритма шифрования;
2) обмен ключами на основе криптосистем с открытым ключом или аутентификация на основе сертификатов;
3) передача данных, шифруемых при помощи симметричных алгоритмов шифрования.
Алгоритм процедуры установления соединения по протоколу TLS handshake. Клиент и сервер, работающие по TLS, устанавливают соединение, используя процедуру handshake. В течение этого handshake, клиент и сервер принимают соглашение относительно параметров, используемых для установления защищенного соединения.
Последовательность действий при установлении TLS соединения:
1) клиент подключается к TLS-поддерживаемому серверу и запрашивает защищенное соединение;
2) клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
3) сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые так же поддерживаются сервером, и сообщает о своем выборе клиенту;
4) сервер отправляет клиенту цифровой сертификат для собственной идентификации. Обычно цифровой сертификат содержит имя сервера, имя доверенного центра сертификации и открытый ключ сервера;
5) клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;
6) для того чтобы сгенерировать ключ сессии для защищенного соединения, клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ.
В данной текущей версии протокола доступны следующие алгоритмы:
Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи) и алгоритмы технологии Fortezza.
Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES.
Для хэш-функций: MD5 или SHA [54].
2. Протокол SSH (Secure Shell ‑ безопасная оболочка) чаще всего используется для создания безопасной оболочки для доступа к другим хостам и передачи файлов по сети, для безопасности аутентификации и для обеспечения конфиденциальности данных. Он был разработан как безопасная замена Telnet и так называемых r-команд (rlogin, rsh и rcp).
С момента создания протокола SSH в 1995 г. было выпущено несколько различных его версий, главными из которых являются: версия 1.5 (также называемая SSH1) и версия 2 (SSH2). OpenSSH 2.0, выпущенный в июне 2000 г., изначально поддерживает оба протокола. (Коммерческие реализации SSH также могут поддерживать обе версии, но только путем запуска при необходимости демона sshd для версии 1, что сильно снижает производительность.)
Эти два протокола SSH не совместимы между собой, и следует определиться с тем, какой вариант вы предпочтете. В протоколе SSH1 временами возникают проблемы с безопасностью. Даже сейчас остается теоретическая возможность «атаки включением» (insertion attack) против этого протокола, но этот риск сводится к минимуму специальной заплаткой (patch) выпущенной CORE-SDI еще в 1998 г. Протокол SSH1 дольше использовался и для него существует обширная база поддержки. В SSH1 поддерживается только ассиметричное шифрование RSA, запатентованное в США в 2000 г. Однако, поскольку срок действия этого патента уже истек, это больше не проблема.
SSH2 — более новый и богатый возможностями протокол, который пока успешно выдерживает все проверки. Хотя установление соединения по протоколу SSH2 требует намного больше времени, в последних версиях OpenSSH этот процесс существенно ускорен. SSH2 поддерживает ассиметричные алгоритмы RSA и DSA.
3. IPSec (сокращение от IP Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищенного обмена ключами в сети Internet.
Стандарты. IPsec является неотъемлемой частью IPv6 — Internet-протокола следующего поколения, и необязательным расширением существующей версии Internet-протокола IPv4. Первоначально протоколы IPsec были определены в RFC с номерами от 1825 до 1827, принятых в 1995 году. В 1998 году были приняты новые редакции стандартов (RFC с 2401 по 2412), несовместимые с RFC 1825—1827. В 2005 году была принята третья редакция, незначительно отличающаяся от предыдущей.
Общая архитектура IPsec описана в RFC 4301, аутентифицирующий заголовок — в RFC 4302, инкапсуляция зашифрованных данных — в RFC 4303. Эти документы имеют статус предварительных стандартов (Proposed Standard). Ряд других RFC описывает другие детали IPsec, такие как применение различных алгоритмов шифрования, протоколы обмена ключами и т. п.
Большинство современных (2007 год) реализаций IPsec основано на RFC 2401-2412.
Техническая информация. Протоколы IPsec работают на сетевом уровне (уровень 3 модели OSI). Другие широко распространенные защищенные протоколы сети Internet, такие как SSL и TLS, работают на транспортном уровне (уровни OSI 4 — 7). Это делает IPsec более гибким, поскольку IPsec может использоваться для защиты любых протоколов базирующихся на TCP и UDP. В то же время увеличивается его сложность из-за невозможности использовать протокол TCP (уровень OSI 4) для обеспечения надежной передачи данных.
IPsec-протоколы можно разделить на два класса: протоколы отвечающие за защиту потока передаваемых пакетов и протоколы обмена криптографическими ключами. На настоящий момент определен только один протокол обмена криптографическими ключами — IKE (Internet Key Exchange) — и два протокола, обеспечивающих защиту передаваемого потока: ESP (Encapsulating Security Payload — инкапсуляция зашифрованных данных) обеспечивает целостность и конфиденциальность передаваемых данных, в то время как AH (Authentication Header — аутентифицирующий заголовок) гарантирует только целостность потока (передаваемые данные не шифруются).
Протоколы защиты передаваемого потока могут работать в двух режимах — в транспортном режиме и в режиме туннелирования. При работе в транспортном режиме IPsec работает только с информацией транспортного уровня, в режиме туннелирования — с целыми IP-пакетами.
IPsec-трафик может маршрутизироваться по тем же правилам, что и остальные IP-протоколы, но, так как маршрутизатор не всегда может извлечь информацию, характерную для протоколов транспортного уровня, то прохождение IPsec через NAT-шлюзы невозможно. Для решения этой проблемы IETF определила способ инкапсуляции ESP в UDP, получивший название NAT-T (NAT Traversal).
IPsec можно рассматривать как границу между внутренней (защищенной) и внешней (незащищенной) сетью. Эта граница может быть реализована как на отдельном хосте, так и на шлюзе, защищающем локальную сеть. Заголовок любого пакета, проходящего через границу, анализируется на соответствие политикам безопасности, то есть критериям, заданным администратором. Пакет может быть либо передан дальше без изменений, либо уничтожен, либо обработан с помощью протоколов защиты данных. Для защиты данных создаются так называемые SA (Security Associations) — безопасные соединения, представляющие собой виртуальные однонаправленные каналы для передачи данных. Для двунаправленной связи требуется два SA.
Параметры политик безопасности и безопасных соединений хранятся в двух таблицах: базе данных политик безопасности (SPD — Security Policy Database) и базе данных безопасных соединений (SAD — Security Association Database). Записи в SPD определяют в каких случаях нужно включать шифрование или контроль целостности, в то время как в SAD хранятся криптографические ключи, которые будут использованы для шифрования или подписи передаваемых данных. Если согласно SPD передаваемый пакет должен быть зашифрован, но в SAD нет соответствующего SA, реализация IPsec по протоколу IKE согласовывает с другой стороной создание нового SA и его параметры.
RFC 4301 дополнительно определяет третью таблицу — базу данных для авторизации узлов (PAD — Peer Authorization Database), предназначенную для хранения сведений об узлах, которым разрешено создавать SA с данным узлом и о допустимых параметрах этих SA.
Существует два режима работы IPsec: транспортный режим и туннельный режим.
В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE и др.).
В туннельном режиме IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищенный IP-туннель. Туннельный режим может использоваться для подключения удаленных компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Internet) между шлюзами для объединения разных частей виртуальной частной сети [30,40].
Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие — туннельный.