Вопросы для подготовки к экзамену Функциональноструктурная организация информационных систем на архитектуре клиентсервер
 Скачать 443.22 Kb.
|
|
Тема 3.2. Технические решения по защите межсетевого взаимодействия и передачи информации. Средства криптографической защиты информации. 3.2.1. Общие технические решения для защиты корпоративной сети 1. Пользователи должны иметь доступ к сетевым серверам, выделенным в отдельный сегмент, через строго определенный набор протоколов связи и приложений с использованием прокси-механизмов. 2. Пользователи, внешние по отношению к сети, не должны иметь доступа к ресурсам корпоративной сети региона за исключением ресурсов демилитаризованных зон «открытого» контура ЛВС согласно строго определенному набору протоколов связи и приложений. 3. Удаленное администрирование систем безопасности в сети должно осуществляться с использованием шифрования трафика управления IP-уровнем или с использованием протоколов управления, поддерживающих шифрование данных (SNMP v3). 4. Управление активным сетевым оборудованием корпоративной сети должно контролироваться специалистами отдела информационной безопасности с использованием механизмов регулярного аудита сетевого оборудования. Подсистема аудита должна управляться подразделениями информационной безопасности. 5. Защита сети должна основываться на следующих решениях: – магистральное шифрование сетевого трафика в сегменте региональной сети при передаче между «закрытыми» контурами ИС; – построение системы защиты сетевого уровня с помощью виртуальных частных VPN-сетей при передаче трафика между «открытыми» контурами ИС; – использование брандмауэров для разграничения ресурсов физических и виртуальных сетей подразделений ИС; – применение средств фильтрации информации на прикладном уровне и прокси-систем наряду с пакетными фильтрами; – создание сегментов ЛВС на основе оборудования структурированной кабельной системы, и обеспечение защиты физического уровня на этой основе; – минимизация количества точек доступа к периметру «открытых» контуров ИЭ и их обязательный контроль; – применение средств усиленной аутентификации пользователей и ресурсов корпоративной сети; – применение систем обнаружения вторжений на сетевом, системном и прикладном уровнях; – обеспечение удаленного администрирования и аудита всех компонентов системы безопасности, организация регистрации событий и подотчетность пользователей и администраторов. 6. Необходимо применять специальное антивирусное программное обеспечение ко всей почте, а также осуществлять автоматический антивирусный контроль ЛВС и почтовых серверов. 3.2.2. Технические решения по защите сетевого оборудования Для защиты сетевого оборудования необходимо выполнить следующие настройки и операции. 1. Конфигурировать активное оборудование ЛВС со встроенной защитой и обеспечить: – авторизацию адресов системы оконечных устройств портами концентратора для доступа к этому порту только из конкретной системы оконечных устройств; – автоматическое отключение порта при несанкционированном обнаружении адреса; – режим работы портов концентратора, обеспечивающий прием пакетов, адресованных только конкретному подключенному АРМ; 2. В ЛВС на физическом и/или логическом уровнях обеспечить разделение контуров для разных функциональных целей (например, конфиденциальной информации, общего пользования и др.). 3. Выделить серверы ИС в отдельный сегмент ЛВС. 4. «демилитаризованные зоны» подключить непосредственно к компьютеру, который обеспечивает межсетевое экранирование и шифрование IP-пакетов при передаче трафика между «открытыми» контурами ИС; 5. Во внутренней «демилитаризованной зоне» разместить: – сервер DNS, «заявляющий» внешним сетям некоторое, строго регламентируемое адресное пространство, используемое приложениями для взаимодействия внешних и внутренних абонентов сети; – прочие сервера, доступ к которым должен быть обеспечен по незащищенным каналам удаленным пользователям. 6. Во внешней «демилитаризованной зоне» разместить серверы: – доступа внешних абонентов; – авторизации внешних абонентов. 7. Исключить возможность использования так называемых «опасных» сервисов (приложений) на серверах внешней «демилитаризованной зоны», что может дать потенциальному нарушителю возможность перенастроить систему, скомпрометировать ее и, опираясь на скомпрометированные ресурсы, атаковать корпоративную сеть. 8. Запретить внешний доступ к ресурсам, расположенным в «открытом» контуре ИС за пределами «демилитаризованных зон». Размещение информационных ресурсов и услуг, доступных извне (из других сетей), кроме «демилитаризованных зон» в «открытом» контуре ИС должно быть запрещено. 9. Запретить доступ из «открытого» контура ИС в обход внешнего брандмауэра уровня приложений. Контролируемый доступ от одного «открытого» контура к другому должен осуществляться с фильтрацией трафика через VPN. 10. Организовать доступ к сегменту серверов «открытого» контура ИС только через брандмауэр прикладного уровня, чтобы защитить их от атак типа «отказ в обслуживании». 11. Настраивать фильтры на брандмауэрах с учетом принципа «все, что не разрешено, запрещено». Правила фильтрации должны блокировать внешние пакеты с исходными IP-адресами компьютеров «открытого» контура, а также пакеты с установленным битом маршрутизации. 12. Минимизировать количество служб, выполняемых на хостах, оставляя только необходимые службы. 13. Брандмауэры (межсетевые экраны) прикладного уровня должны скрывать от внешних сетевых пользователей структуру корпоративной сети (IP-адреса, доменные имена и т.д.). Эти брандмауэры должны определять, какие пользователи, от каких хостов, в направлении каких хостов, в какое время, какие сервисы можно использовать. Брандмауэры должны определять способ аутентификации каждого пользователя при доступе к службе и должны фильтровать Telnet, Rlogin, FTP, SMTP, POP3, HTTP, LP, Rsh, Finger, NNTP, Sql * Net и другие, а также поддерживать внешнюю авторизацию и учет на основе протоколов RADIUS/TACACS и интегрироваться в систему обнаружения вторжений. 14. Минимизировать количество портов маршрутизатора и межсетевого экрана, открытых для TCP-соединений, предотвращать прохождение через маршрутизаторы брандмауэры пакетов с маршрутизацией по источнику, а также пакетов с направленной широковещательной передачей. 15. Организовать оперативное распространение АИБ статистических данных об использовании услуг, попытках НДД и т.д. 16. Для администрирования оборудования использовать локальную консоль или протокол SMNP v.3 для шифрования управляющего трафика. Управление другим активным сетевым оборудованием ЛВС должно осуществляться с использованием аналогичных мер информационной безопасности, описанных выше. 17. Параметры аудита внешнего маршрутизатора должны включать аудит нарушений, правила фильтрации и другие ограничения, а также все команды пользователя на уровнях привилегий. Вся информация аудита должна автоматически отправляться на сервер аудита безопасности для дальнейшего анализа. Данные системного журнала также должны быть отправлены на сервер аудита безопасности. 3.2.3. Технические решения для организации защиты межсетевого взаимодействия с применением межсетевых экранов Для межсетевой защиты в корпоративной сети и ее экранирования от атак извне, для обнаружения и регистрации внешних атак необходимо применение межсетевых экранов. С помощью журналов аудита межсетевых экранов необходимо отслеживать: – попытки соединения с ЛВС «открытого» контура с неразрешенных IP-адресов; – попытки использования неразрешенных протоколов уровня TCP/UDP и соединения с неразрешенными портами серверов ЛВС «открытого» контура извне; – попытки компрометации защищенных IP-соединений к ресурсам корпоративной сети; – попытки использования незащищенных IP-соединений при межсетевом взаимодействии в региональной корпоративной сети. Для оперативного анализа информации аудита необходимо настроить журнал syslogd межсетевых экранов таким образом, чтобы события аудита дублировались на сервер аудита службы безопасности, т. е. для всех межсетевых экранов хост loghost в файле /etc/hosts должен ссылаться на сервер аудита службы безопасности. Для обеспечения надежности функционирования механизмов фильтрации трафика необходимо резервировать межсетевые экраны. 3.2.4. Технические решения для защиты корпоративной сети на базе сканеров безопасности Одним из важнейших элементов технологии IP-безопасности организации является периодическая оценка корпоративной сетевой безопасности. Одним из методов автоматизации процессов такой оценки является метод, построенный на технологии интеллектуальных программных агентов или сканеров безопасности. Они предназначены для сканирования известных уязвимостей сетевых служб и неверных параметров конфигурации ОС, приводящих к «отказу в обслуживании», выявления уязвимостей, специфичных для конкретной сетевой ОС, проверки надежности службы NFS, проверки служб удаленного доступа и т. д. Сканеры безопасности включают в себя продукты семейства Internet Scanner и System Scanner от ISS [24]. Они управляются централизованно и обеспечивают тестирование и создание отчетов с консоли безопасности. Система System Scanner (S2) установлена на серверах и брандмауэрах. Консоль управления S2 - на АРМ администратора безопасности ИС, система Internet Scanner - на АРМ администратора безопасности ИС и настроена на проверку уязвимости серверов ИС, маршрутизаторов, брандмауэров, DNS-сервера и т. д. Тестирование безопасности системы должно выполняться ежедневно при наименьшей загрузке протестированных ресурсов с экспортом результатов в базу данных аудита. 3.2.5. Технические решения для защиты корпоративной сети на базе систем обнаружения вторжений Сканеры безопасности позволяют оценить безопасность корпоративной сети. Однако они не обнаруживают проникновение злоумышленника в сеть, поэтому вторым необходимым элементом защиты сети является система быстрого обнаружения и реагирования на атаки RealSecure, которая позволяет обнаружить атаку на сетевой узел путем обнаружения статистических шаблонов сетевого трафика и сравнения их с масками, хранящимися в базе данных. RealSecure - это система мониторинга сетевого трафика в режиме реального времени. Основная задача, которую выполняет этот продукт, - своевременное обнаружение атак. Идея их идентификации проста: любая атака соответствует определенному сетевому трафику, поэтому ее анализ позволяет определить факт проведения атаки и зафиксировать «следы» злоумышленника. Поскольку анализ информационных потоков выполняется в реальном времени, время отклика АИБ на атаку или неисправность может быть минимизировано. Система RealSecure использует распределенную архитектуру и имеет два основных компонента RealSecure Detector и RealSecure Manager. Первый компонент отвечает за обнаружение атак и реагирование на них и состоит из двух модулей - RealSecure Network Engine (RNE) и RealSecure System Agent (RSA). Сетевой агент устанавливается в «открытом» сетевом сегменте и обнаруживает атаки, «прослушивая» трафик. Системный агент устанавливается на контролируемый узел и обнаруживает несанкционированные действия, выполняемые на этом узле. Компонент RealSecure Manager отвечает за конфигурирование и сбор информации с детектора RealSecure. Управлять компонентами системы RealSecure можно как с помощью централизованной консоли, так и при помощи дополнительного модуля, подключаемого к системам сетевого управления HP OpenView (RealSecure OpenView Manager). Системы обнаружения вторжений (IDS) также отслеживают, регистрируют, анализируют и реагируют в режиме реального времени на попытки использования протоколов и служб, нарушающих политики безопасности. Эти системы делятся по методу анализа входной информации: на основе знания (сигнатуры) или на поведении субъекта (статистики). Классификация (таксономия) систем указанного класса может осуществляться по источникам информации, используемым для этих систем. Входная информация может быть записями аудита, системными загрузками или сетевыми пакетами. Термин «аудит» относится к информации, предоставляемой системой относительно ее внутренних действий и поведения. Существуют IDS сетевого уровня (прослушивание сети и анализ сетевых пакетов для обнаружения атак), системного уровня (мониторинг операционных систем для обнаружения признаков вторжения) и прикладного уровня (мониторинг отдельных приложений). IDS может анализировать события двумя способами: сигнатурным или статистическим. IDS сетевого уровня рассматриваются как эффективное средство сбора информации о событиях, происходящих в сети. Преимущества IDS сетевого уровня: 1. Он устанавливается только в наиболее важных точках сети для мониторинга всего входящего сетевого трафика и обычно состоит из нескольких однонаправленных пассивных хостов, которые перехватывают сетевой трафик в разных частях сети и сообщают об атаках на одну консоль управления. Работа хостов IDS практически не влияет на саму сеть. 2. Обнаружение сетевых атак типа «отказ в обслуживании» и «фрагментация пакетов». Анализ содержимого пакета данных позволяет выполнять поиск команд или конкретного синтаксиса, используемого в атаках. 3. Возможность анализировать «on-line» трафик, что не позволяет хакеру удалить следы своего присутствия. 4. Обнаружение и реагирование в реальном времени для сбора информации об атаке и злоумышленнике до завершения атаки. 5. Регистрация отраженных нападений или попыток подозрительных намерений нарушителя, что важно при оценке и совершенствовании политики безопасности. 6. Независимоcть от операционных систем, установленных в корпоративной сети. К недостаткам сетевых IDS можно отнести невозможность анализа зашифрованной информации противника (шифрование делает невозможным анализ интенсивности потока пакетов). Кроме того, большинство сетевых IDS не сообщают, была ли атака успешной (они сообщают только, что она была начата). После обнаружения атаки администраторы должны вручную исследовать каждый атакованный узел, чтобы определить, имело ли место вторжение. Сегодняшняя IDS на уровне приложений отслеживает события, происходящие в приложении, посредством очного аудита (securitylog или syslogd). Они обнаруживают атаки, анализируя файлы журнала приложения и сравнивая новые записи с известными сигнатурами атак. Имея прямой интерфейс с приложением и знание приложения, IDS прикладного уровня имеют гораздо больше возможностей найти подозрительную активность в приложении. При обнаружении атаки система посылает сигнал тревоги администратору или активизирует другие определенные механизмы ответа. Преимущества IDS уровня приложения: 1. Возможность подтверждения успеха или неудачи атаки на основе отложенного анализа журналов, содержащих данные о событиях, которые действительно произошли, дополняя раннее предупреждение о начале атаки с помощью IDS сетевого уровня. 2. Возможность анализа расшифрованного входящего трафика, поскольку он имеет интерфейс с приложением и может дешифровать трафик. Однако IDS прикладного уровня более уязвимы, чем IDS уровня хост-системы, и могут быть атакованы и отключены, поскольку они выполняются как приложения на хосте, что является их недостатком. IDS системного уровня анализируют активность хоста, за которой они следят, и точно определяют, какой процесс или пользователь проявляет подозрительную активность в операционной системе. Система IDS системного уровня может централизованно управлять несколькими хостами и сообщать о атаках на одну консоль безопасности. Главные преимущества. 1. Строгий контроль работы пользователя на узле, который обычно осуществляется только администратором сети (доступ к файлам, изменение прав доступа к файлам, попытки установки новых программ и/или попытки доступа к привилегированным службам), а также контроль за изменениями в ключевых системных или исполняемых файлах и т.д., что часто позволяет отслеживать несанкционированную деятельность вплоть до отдельного пользователя. 2. Распределение событий аудита по классам для упрощения конфигурации системы аудита; 3. Параметризация информации, собранной в соответствии с пользователем, классом, событием аудита, успешным/неуспешным вызовом системы; 4. Обнаружение атак, пропускающих IDS сетевого уровня (например, атак с самого атакуемого сервера). 5. Обнаруживайте и реагируйте на атаку практически в реальном времени, так как они получают прерывание от ОС, как только появляется новая запись журнала. 6. Не требуется дополнительного оборудования (установка отдельного узла IDS в сети), поскольку программное обеспечение IDS системного уровня устанавливается на существующую сетевую инфраструктуру, включая файловые серверы, веб-серверы и другие используемые ресурсы. 7. Позволяет масштабировать систему путем установки дополнительных агентов при расширении списка контролируемых сетевых узлов. Недостатки. 1. Программные агенты обычно должны устанавливаться и поддерживаться на каждом контролируемом хосте. 2. Возможность атаки «отказ в обслуживании» путем переполнения файловой системы аудита. 3. Не удается обнаружить распределенную атаку на все узлы сети, так как она отслеживает только входящий сетевой трафик на своем узле. 4. Трудности обнаружения и отражения атак типа «отказ в обслуживании». 5. Использование вычислительных ресурсов хостов, которым они управляют. Высокое потребление системных ресурсов при необходимости детального мониторинга (производительность процессора, потребление локального диска и архивной памяти). 3.2.6. Технические решения по применению аппаратно-программный комплекс шифрования «Континент» Основным назначением аппаратно-программного комплекса шифрования (АПКШ) «Континент» является защита информации, в корпоративных сетях, использующих для передачи данных протоколы семейства TCP/IP v. 4, а также защита сегментов VPN от проникновения извне. В состав АПКШ «Континент» входят следующие компоненты: – криптографический шлюз (КШ) «Континент»; – центр управления сетью (ЦУС) КШ; – программу управления сетью КШ. АПКШ «Континент» обеспечивает: – шифрование и имитозащиту данных, передаваемых по открытым каналам связи между защищаемыми сегментами сети; – защиту внутренних сегментов сети от несанкционированного доступа извне; – скрытие внутренней структуры защищаемых сегментов сети; – централизованное управление защитой сети. События аудита регистрируются в журналах аудита в виде отдельных записей. На АПКШ с установленным ЦУС формируются как журналы КШ, так и журналы ЦУС. События, происходящие на КШ, регистрируются в локальных журналах КШ. Для централизованного доступа к записям содержимое локальных журналов перемещается через ЦУС на хранение в БД на сервер БД АПКШ «Континент». В системном журнале регистрируются события, связанные с работой подсистем КШ и ЦУС, а также события, регистрируемые другими СЗИ (например, ПАК «Соболь»). Для каждого зарегистрированного события сохраняются время регистрации, описание события, категория и ряд дополнительных параметров. В журнале НСД хранятся записи о зарегистрированных событиях, свидетельствующих о возможных угрозах безопасности. Каждая запись содержит информацию о количестве зарегистрированных событий в течение одной минуты, а также ряде дополнительных параметров. В журнал НСД также осуществляется запись событий, связанных с IP-пакетами, отброшенными пакетным фильтром или не соответствующих ни одному правилу фильтрации. 21. Протокол формирования защищенного туннеля на канальном уровне PPTP (Point-to-PointTunnelingProtocol), Ответ: Протокол формирования защищённого туннеля на канальном уровне PPTP PPTP, или «Туннельный протокол точка-точка», – это сетевой протокол, который в основном используется на компьютерах с Windows. В настоящее время он считается устаревшим для использования в VPN (виртуальных частных сетях) из-за многих известных проблем безопасности. Например, АНБ может легко взломать PPTP. Тем не менее, PPTP все еще используется в определенных сетях, особенно в тех, которые используют компьютеры Windows. Принцип работы PPTP Для стандартного формирования криптозащищенных туннелей на канальном уровне модели OSI компанией Microsoft при поддержке компаний Ascend Communications, 3Com/Primary Access, ECI-Telematics и US Robotics был разработан протокол туннелирования PPTP (Point-to-Point Tunneling Protocol), представляющий собой расширение протокола PPP (Point-to-Point Protocol). В протоколе PPTP не специфицируются конкретные методы аутентификации и шифрования. Клиенты удаленного доступа в Windows NT 4.0 и Windows 98 с Dial-Up Networking поставляются с версией шифрования DES компании RSA Data Security, получившей название "шифрование двухточечной связи Microsoft" (Microsoft Point-to-Point Encryption - MPPE). Как и все технологии туннелирования, PPTP используется для инкапсуляции пакетов данных, создавая туннель для передачи данных через IP-сеть. PPTP использует схему клиент-сервер (техническая спецификация содержится в Интернете RFC 2637), которая работает на уровне 2 модели OSI. Как только VPN-туннель установлен, PPTP поддерживает два типа потока информации: Управляющие сообщения для управления и, в конечном итоге, разрыва VPN-соединения. Управляющие сообщения передаются напрямую между VPN-клиентом и сервером. Пакеты данных , которые проходят через туннель, то есть к клиенту VPN или от него. Пользователи могут получить информацию об адресе VPN-сервера PPTP у администратора сервера. Строки подключения могут быть либо именем сервера, либо IP-адресом, который администратор может предоставить пользователям напрямую. Протоколы PPTP PPTP использует GRE (General Routing Encapsulation) туннелирование для инкапсуляции пакетов данных. Он использует TCP-порт 1723 и IP-порт 47 через протокол управления транспортом (TCP). Что касается шифрования, PPTP поддерживает до 128-битных ключей и использует MPPE (Microsoft Point-to-Point Encryption). Режимы туннелирования: добровольные и обязательные PPTP поддерживает два типа туннелирования: Добровольное туннелирование . Тип туннелирования, инициируемый клиентом (например, Microsoft Windows) при существующем соединении с сервером. Обязательное туннелирование . Тип туннелирования, инициируемый сервером PPTP на интернет-провайдере, для которого требуется сервер удаленного доступа для создания туннеля. 22. Протокол формирования защищенного туннеля на канальном уровне L2F (Layer-2 Forwarding) Ответ: Канальному уровню модели OSI соответствует также протокол туннелирования L2F (Layer-2 Forwarding), разработанный компанией Cisco Systems при поддержке компаний Shiva и Northern Telecom. В данном протоколе также не специфицируются конкретные методы аутентификации и шифрования. В отличие от протокола PPTP протокол L2F позволяет использовать для удаленного доступа к провайдеру Internet не только протокол PPP, но и другие протоколы, например, SLIP. При формировании защищенных каналов по глобальной сети провайдерам Internet не нужно осуществлять конфигурацию адресов и выполнять аутентификацию. Кроме того, для переноса данных через защищенный туннель могут использоваться различные протоколы сетевого уровня, а не только IP, как в протоколе PPTP. Протокол L2F стал компонентом операционной системы IOS (Internetwork Operating System) компании Cisco и поддерживается во всех выпускаемых ею устройствах межсетевого взаимодействия и удаленного доступа. Протокол L2F обладает следующими свойствами: 1) гибкостью процедур аутентификации, предполагающей отсутствие жесткой привязки к конкретным протоколам проверки подлинности; 2) прозрачностью для конечных систем - рабочим станциям локальной сети и удаленной системе не требуется специального программного обеспечения для использования защитного сервиса; 3) прозрачностью для посредников - авторизация удаленных пользователей выполняется аналогично случаю непосредственного подключения пользователей к серверу удаленного доступа локальной сети; 4) полнотой аудита - регистрация событий доступа к серверу локальной сети осуществляется не только сервером удаленного доступа этой сети, но и сервером провайдера. В соответствии со спецификацией протокола L2F в образовании защищенного туннеля участвуют протоколы нескольких типов: 1) исходный инкапсулируемый протокол - это протокол, на основе которого функционирует локальная сеть, например, IP, IPX или NetBEUI; 2) протокол-«пассажир», в который инкапсулируется исходный протокол и который сам должен быть инкапсулирован при удаленном доступе через открытую сеть; рекомендуется протокол РРР; 3) управляющий (инкапсулирующий) протокол, который используется для создания, поддержания и разрыва туннеля (в качестве такого протокола применяется L2F); 4) протокол провайдера - используется для переноса инкапсулируемых протоколов (исходного протокола и протокола-«пассажира»); самым распространенным протоколом провайдера является IP. Следует отметить, что при использовании технологии L2F сервер удаленного доступа провайдера использует аутентификацию пользователя только для того, чтобы определить необходимость создания виртуального канала и найти адрес сервера удаленного доступа требуемой локальной сети. Окончательная проверка подлинности выполняется сервером удаленного доступа локальной сети после того, как с ним связывается сервер провайдера. Недостатки протокола L2F: 1) в нем не предусмотрено создание для текущей версии протокола IP криптозащищенного туннеля между конечными точками информационного взаимодействия; 2) виртуальный защищенный канал может быть создан только между сервером удаленного доступа провайдера и пограничным маршрутизатором локальной сети, при этом участок между компьютером удаленного пользователя и сервером провайдера остается открытым. 23. Протокол формирования защищенного туннеля на канальном уровне L2TP (Layer-2 TunnelingProtocol) Ответ: Протокол формирования защищённого туннеля на канальном уровне L2TP Протокол L2TP разработан в организации IETF при поддержке компаний Microsoft и Cisco Systems. L2TP разрабатывался как протокол защищенного туннелирования РРР-трафика через сети общего назначения с произвольной средой. Работа над этим протоколом велась на основе протоколов РРТР и L2F, и в результате он вобрал в себя лучшие качества исходных протоколов. Протокол L2TP может поддерживать любые высокоуровневые протоколы и предусматривает управление потоками данных, удаленную аутентификацию пользователей, установку защищенного виртуального соединения, а также позволяет открывать между пользователями сразу несколько туннелей, каждый из которых администратор может выделить для того или иного приложения. Как и предшествующие протоколы канального уровня, спецификация L2TP не описывает методы аутентификации и шифрования. По существу протокол L2TP представляет собой расширение РРР-протокола функциями аутентификации удаленных пользователей, установки защищенного виртуального соединения, а также управлением потока данных. Для аутентификации в корпоративной сети перед стартом сессии PPP могут применяться без участия провайдера Internet протоколы CHAP/PAP или другие. Гарантированная доставка информации в сессии обеспечивается за счет нумерации защищенных кадров в соединении, восстановления потерянных и искаженных кадров. Протокол L2TP в качестве сервера RAS использует концентратор доступа AC (Access Concentrator), в котором реализована клиентская часть L2TP и обеспечивает пользователю сетевой доступ к его ЛВС через Internet. Роль сервера удаленного доступа ЛВС выполняет сервер L2TP (L2TP Network Server), функционирующий на любых платформах, совместимых с РРР. Протокол L2TP предусматривает три этапа установления соединения: установление соединения с удаленным сервером ЛВС; аутентификацию пользователя; конфигурацию криптозащищённого туннеля. В отличие от РРТР, протокол L2TP не привязан к протоколу IP, поэтому он может быть использован в сетях с коммутацией пакетов, например, в сетях ATM (Asynchronous Transfer Mode) или в сетях с ретрансляцией кадров (frame relay). Кроме того, в протокол L2TP добавлена отсутствующая в протоколе L2F важная функция управления потоками данных. В протоколе L2TP не только объединены лучшие свойства протоколов РРТР и L2F, но и добавлены новые функции. В протокол L2TP добавлен ряд отсутствующих в спецификации протокола РРТР функций защиты, в частности, включена возможность работы с протоколами АН и ESP стека протоколов IPSec. Архитектура протокола L2TP представлена на рисунке 14.5.  Рисунок14.5 - Архитектура протокола L2TP Протоколы АН и ESP являются основными компонентами стека протоколов IPSec. Эти протоколы допускают применение пользователями по их согласованному выбору различных криптографических алгоритмов шифрования и аутентификации. На домен интерпретации DOI (Domain of Interpretation) возложены функции обеспечения совместной работы используемых протоколов и алгоритмов. Протокол L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных. В реализации Microsoft протокол L2TP использует в качестве контрольных сообщений пакеты UDP, содержащие шифрованные пакеты РРР. Надежность доставки гарантирует контроль последовательности пакетов. Настройка необходимых значений параметров туннеля проводится с помощью управляющих сообщений. Протокол L2TP может работать поверх любого транспорта с коммуникацией пакетов. В общем случае этот транспорт, например протокол UDP, не обеспечивает гарантированной доставки пакетов. Поэтому протокол L2TP самостоятельно решает эти вопросы, используя процедуры установления соединения внутри туннеля для каждого удаленного пользователя. Следует отметить, что протокол L2TP не определяет конкретных методов криптозащиты и предполагает возможность применения различных стандартов шифрования. Если защищенный туннель планируется сформировать в IP-сетях, тогда для реализации криптозащиты используется протокол IPSec. Протокол L2TP поверх IPSec обеспечивает более высокую степень защиты данных, чем РРТР, так как использует алгоритм шифрования 3-DES (Triple Data Encryption Standard). Если такой высокий уровень защиты не нужен, можно использовать алгоритм DES с одним 56-разрядным ключом. Кроме того, при помощи алгоритма НМАС (Hash Message Authentication Code) протокол L2TP обеспечивает аутентификацию данных. Для аутентификации данных этот алгоритм создает хэш длиной 128 разрядов. Положительные качества протокола L2TP делают его весьма перспективным для построения виртуальных защищенных сетей. Однако при всех своих достоинствах протокол L2TP не смог преодолеть ряд недостатков туннельной передачи данных на канальном уровне: 1) для реализации протокола L2TP необходима поддержка провайдеров ISP; 2) протокол L2TP ограничивает трафик рамками выбранного туннеля и лишает пользователей доступа к другим частям Internet; 3) в протоколе L2TP не предусмотрено создание для текущей версии протокола IP криптозащищенного туннеля между конечными точками информационного взаимодействия; 4) предложенная спецификация L2TP обеспечивает стандартное шифрование только в IP-сетях с помощью протокола IPSec. 24. Общее описание стека протоколов защиты межсетевого уровня IPsec (InternetProtocolSecurity). Ответ: Общее описание стека протоколов защиты межсетевого уровня IPSec (InternetProtocolSecurity) Спецификацией, где описаны стандартные методы для всех компонентов и функций защищенных виртуальных сетей, является протокол Internet Protocol Security (IPSec), соответствующий сетевому уровню модели OSI и входящий в состав новой версии протокола IP – IPv6. Протокол IPSec иногда еще называют протоколом туннелирования третьего уровня (Layer-3 Tunneling) . IPSec предусматривает стандартные методы аутентификации пользователей или компьютеров при инициации туннеля, стандартные способы шифрования конечными точками туннеля, формирования и проверки цифровой подписи, а также стандартные методы обмена и управления криптографическими ключами между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Для функций аутентификации IPSec поддерживает цифровые сертификаты популярного стандарта X.509. Туннель IPSec между двумя локальными сетями может поддерживать множество индивидуальных каналов передачи данных, в результате чего приложения данного типа получают преимущества с точки зрения масштабирования по сравнению с технологией второго уровня. Протокол IPSec может использоваться совместно с протоколом L2TP. Совместно эти два протокола обеспечивают наиболее высокий уровень гибкости при защите виртуальных каналов. Дело в том, что спецификация IPSec ориентирована на протокол IP и, таким образом, бесполезна для трафика любых других протоколов сетевого уровня. Протокол L2TP отличается независимостью от транспортного уровня, что может быть полезно в гетерогенных сетях, состоящих из IP-, IPX- и AppleTalk-сегментов. IPSec стремительно завоевывает популярность и станет, вероятно, доминирующим стандартом по созданию и поддержке защищенных виртуальных сетей. Архитектура семейства протоколов IPSec (рис.3.1) включает в себя: - протокол управления ключами (Internet Security Association Key Management Protocol, ISAKMP [RFC 2408] и протокол обмена ключевой информацией IKE (Internet Key Exchange) [RFC 2409].; - протокол аутентифицирующего заголовка (Authentication Header, АН); - протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP). - домен интерпретации (Domain of Interpretation, DOI), который доопределяя структуру блоков данных и задавая правила именования информации, определяющей безопасность (политики безопасности, криптографические режимы и алгоритмы), связывает IKE с протоколом, защита которого обеспечивается.  25. Протокол обмена ключевой информацией IKE (InternetKeyExchange) Ответ: Протокол обмена ключевой информацией IKE Алгоритмическая независимость протоколов АН и ESP требует предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых взаимодействующими сторонами. Эту функцию на фазе установления соединения в современной архитектуре IPsec реализует протокол обмена ключевой информацией IKE (Internet Key Exchange) [RFC 2407, 2408, 2409]. Протокол IKE принято рассматривать как расширение ISAKMP [RFC 2408], основой которого он является, хотя отдельные идеи заимствованы у Oakley (The Oakley Key Determination Protocol [RFC 2412]) и SKEME (A Versatile Secure Key Exchange Mechanism for Internet). В соответствии с протоколом IKE при формировании защищенного виртуального туннеля взаимодействующие стороны должны выработать, общий контекст безопасности (Security Association, SA) и только затем использовать элементы этого контекста. Контекст безопасности SA для любого протокола представляет собой согласованный набор параметров, определяющих услуги и механизмы, предоставляемые этим протоколом для защиты трафика в сессии, копия которых имеется у каждой из взаимодействующих сторон. Контекст безопасности – это, по сути, общее согласованное состояние отправителя и получателя, которое, в частности, определяет предоставляемые услуги, используемые криптографические алгоритмы и ключи в сессии. Таким образом, основной задачей протокола IKE является автоматическое защищенное согласование контекстов безопасности для семейства протоколов IPsec между участниками мультимедийной сессии. В работе IKE можно выделить две основные фазы (phases). На первой фазе работы IKE происходит согласование обязательных параметров контекста безопасности IKE (IKE SA), выполняется взаимная аутентификация участников, и устанавливаются сеансовые ключи. Контекст безопасности IKE SA определяет, как именно будет обеспечиваться защита последующего трафика. Для семейства IPsec такими контекстами безопасности являются ESP SA и AH SA (общим названием этих контекстов безопасности является IPsec SA). После завершения первой фазы и установления между инициатором и ответчиком контекста безопасности IKE SA любой из участников обмена может стать инициатором второй фазы. На второй фазе фактически создаётся контекст безопасности IKE SA, который определяет, как именно будет обеспечиваться защита трафика в сессии. Обязательные параметры IKE SA (алгоритм шифрования, алгоритм вычисления хэш-функции, метод аутентификации и группа Диффи-Хеллмана, которая определяет параметры ключевого материала для обмена Диффи-Хеллмана) составляют защитный набор. Во второй фазе могут выполняться обмены быстрого режима, режима новой группы, а также информационного режима. Принципиальная разница между первой и второй фазами: в ходе первой фазы друг друга аутентифицируют оконечные узлы IKE-соединения, тогда как в ходе второй фазы аутентификация осуществляется для пользователей или прикладных программ. После завершения первой фазы и установления между инициатором и ответчиком контекста безопасности IKE SA любой из участников обмена может стать инициатором второй фазы. Во второй фазе могут выполняться обмены быстрого режима, режима новой группы, а также информационного режима. В ходе второй фазы согласуются, модифицируются и удаляются контексты безопасности (которых может быть несколько) для протокола, использующего IKE. 26. Протокол аутентифицирующего заголовка (AuthenticationHeader, АН); Ответ: Архитектура семейства протоколов IPSec включает в себя: - протокол управления ключами (Internet Security Association Key Management Protocol, ISAKMP [RFC 2408] и протокол обмена ключевой информацией IKE (Internet Key Exchange) [RFC 2409].; - протокол аутентифицирующего заголовка (Authentication Header, АН); - протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP). домен интерпретации (Domain of Interpretation, DOI), который доопределяя структуру блоков данных и задавая правила именования информации, определяющей безопасность (политики безопасности, криптографические режимы и алгоритмы), связывает IKE с протоколом, защита которого обеспечивается. при формировании защищенного виртуального канала взаимодействующие стороны должны выработать, общий контекст безопасности SA и только затем использовать элементы этого контекста, такие как алгоритмы и ключи. Для семейства IPsec такими контекстами безопасности являются ESP SA и AH SA (общим названием этих контекстов безопасности является IPsec SA). Протокол аутентифицирующего заголовка АН предусматривает аутентификацию источника данных, проверку их целостности и подлинности после приема, а также защиту от навязывания повторных сообщений. Протоколы АН и ESP не зависят от конкретных криптографических алгоритмов. Могут использоваться любые методы аутентификации, типы ключей (симметричные или несимметричные), алгоритмы шифрования и распределения ключей. Например, в каждой стране может применяться свой алгоритм, соответствующий национальным стандартам. В настоящий момент для протоколов АН и ESP зарегистрировано два алгоритма аутентификации — HMAC-MD5 (Hashed Message Authentication Code - Message Digest version 5) и HMAC-SHA1 (Hashed Message Authentication Code — Secure Hash Algorithm version 1). Данные алгоритмы являются алгоритмами аутентификации с секретным ключом. Если секретный ключ известен только передающей и принимающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между двумя сторонами. Алгоритмом, использующимся по умолчанию, определен алгоритм HMAC-MD5. Протоколы AH и ESP поддерживают работу в двух режимах: Туннельный режим. IP-пакеты защищаются целиком, включая заголовки. Он является основным режимом. При работе в этом режиме каждый обычный IP-пакет помещается целиком в криптозащищенном виде в конверт IPSec, а тот, в свою очередь, инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах, в роли которых могут выступать маршрутизаторы или межсетевые экраны. Между такими шлюзами и формируются защищенные туннели IPSec. Туннелирование IP-пакетов полностью прозрачно для оконечных пользователей. На оконечных системах туннельный режим может использоваться для поддержки удаленных и мобильных пользователей. В этом случае на компьютерах этих пользователей должно быть установлено программное обеспечение, реализующее туннельный режим IPSec. В транспортном режиме в конверт IPSec в криптозащищенном виде помещается только содержимое исходного IP-пакета и к полученному конверту добавляется исходный IP-заголовок. Соответственно в транспортном режиме заголовок IPSec размещается между сетевым (IP) и транспортным (TCP или UDP) заголовками обычного IP-пакета. Транспортный режим быстрее туннельного и разработан для применения на оконечных системах. Данный режим может использоваться для поддержки удаленных и мобильных пользователей, а также защиты информационных потоков внутри локальных сетей. Протокол АН. Туннельный режим. Протокол заголовка аутентификации АН [RFC1826], [RFC1827] предусматривает аутентификацию источника данных, проверку их целостности и подлинности после приема, а также защиту от навязывания повторных сообщений. В основе обеспечения целостности и аутентификации данных лежит шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function). В туннельном режиме внутренний (первоначальный) IP-заголовок содержит целевой адрес пакета, а внешний IP-заголовок содержит адрес конца туннеля (рис.3.2).  Параметры аутентификации рассчитываются с использованием всех полей дейтаграммы IP (включая не только заголовок IP, но и заголовки других протоколов, а также пользовательские данные), которые не могут изменяться в процессе доставки. Транспортный режим. Протокол АН. При использовании протокола АН в транспортном режиме защита не накладывается лишь на те поля IP-заголовков, которые меняются на маршруте доставки непредсказуемым образом. К таким полям для протокола IPv4 относится поле Time to Live, задающее время жизни IP-пакета, а также поле Type of Service, определяющее тип его обслуживания. В транспортном режиме в конверт IPSec помещается только содержимое защищаемого IP-пакета и к полученному конверту добавляется исходный IP-заголовок (рис. 3.3).   Расположение полей заголовков протокольных блоков АН и ESP в транспортном и туннельном режимах показано на рис. 3.8. Заголовки протокольных блоков АН и ESP располагаются в транспортном режиме после заголовка исходного IP-пакета и перед заголовками протоколов верхних уровней, а в туннельном режиме – после заголовка внешнего IP-пакета и перед заголовком внутреннего исходного IP-пакета.
Рис. 3.8 - Расположение полей заголовков протокольных блоков в транспортном и туннельном режимах Протоколы АН и ESP могут комбинироваться разными способами. Если используется транспортный режим, то аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием, протокол АН должен применяться после протокола ESP. В туннельном режиме протоколы АН и ESP применяются к разным вложенным пакетам и, кроме того, в данном режиме допускается многократная вложенность туннелей с различными начальными и/или конечными точками. Поэтому в случае туннельного режима число возможных комбинаций по совместному использованию протоколов АН и ESP существенно больше. 27. Протокол инкапсулирующей защиты содержимого (EncapsulatingSecurityPayload, ESP). Ответ: Архитектура семейства протоколов IPSec включает в себя: - протокол управления ключами (Internet Security Association Key Management Protocol, ISAKMP [RFC 2408] и протокол обмена ключевой информацией IKE (Internet Key Exchange) [RFC 2409].; - протокол аутентифицирующего заголовка (Authentication Header, АН); - протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP). домен интерпретации (Domain of Interpretation, DOI), который доопределяя структуру блоков данных и задавая правила именования информации, определяющей безопасность (политики безопасности, криптографические режимы и алгоритмы), связывает IKE с протоколом, защита которого обеспечивается. при формировании защищенного виртуального канала взаимодействующие стороны должны выработать, общий контекст безопасности SA и только затем использовать элементы этого контекста, такие как алгоритмы и ключи. Для семейства IPsec такими контекстами безопасности являются ESP SA и AH SA (общим названием этих контекстов безопасности является IPsec SA). Протокол инкапсулирующей защиты содержимого ESP обеспечивает криптографическое закрытие передаваемых пакетов сообщений и предусматривает также выполнение всех функций протокола АН. Протокол ESP может поддерживать функции шифрования и аутентификации/целостности в любых комбинациях, т. е. либо и ту и другую группу функций, либо только аутентификацию/целостность, либо только шифрование. Протоколы АН и ESP не зависят от конкретных криптографических алгоритмов. Могут использоваться любые методы аутентификации, типы ключей (симметричные или несимметричные), алгоритмы шифрования и распределения ключей. Например, в каждой стране может применяться свой алгоритм, соответствующий национальным стандартам. В настоящий момент для протоколов АН и ESP зарегистрировано два алгоритма аутентификации — HMAC-MD5 (Hashed Message Authentication Code - Message Digest version 5) и HMAC-SHA1 (Hashed Message Authentication Code — Secure Hash Algorithm version 1). Данные алгоритмы являются алгоритмами аутентификации с секретным ключом. Если секретный ключ известен только передающей и принимающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между двумя сторонами. Алгоритмом, использующимся по умолчанию, определен алгоритм HMAC-MD5. Для протокола ESP зарегистрировано семь алгоритмов шифрования. Алгоритм шифрования DES (Data Encryption Standard), как и алгоритм НМАС-MD5, принят по умолчанию и необходим для обеспечения IPSec-совместимости. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC5, IDEA, Blowfish и ARCFour [10]. Протоколы AH и ESP поддерживают работу в двух режимах: Туннельный режим. IP-пакеты защищаются целиком, включая заголовки. Он является основным режимом. При работе в этом режиме каждый обычный IP-пакет помещается целиком в криптозащищенном виде в конверт IPSec, а тот, в свою очередь, инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах, в роли которых могут выступать маршрутизаторы или межсетевые экраны. Между такими шлюзами и формируются защищенные туннели IPSec. Туннелирование IP-пакетов полностью прозрачно для оконечных пользователей. На оконечных системах туннельный режим может использоваться для поддержки удаленных и мобильных пользователей. В этом случае на компьютерах этих пользователей должно быть установлено программное обеспечение, реализующее туннельный режим IPSec. В транспортном режиме в конверт IPSec в криптозащищенном виде помещается только содержимое исходного IP-пакета и к полученному конверту добавляется исходный IP-заголовок. Соответственно в транспортном режиме заголовок IPSec размещается между сетевым (IP) и транспортным (TCP или UDP) заголовками обычного IP-пакета. Транспортный режим быстрее туннельного и разработан для применения на оконечных системах. Данный режим может использоваться для поддержки удаленных и мобильных пользователей, а также защиты информационных потоков внутри локальных сетей. Туннельный режим. Протокол ESP. Независимо от режима использования протокола ESP его заголовок формируется как инкапсулирующая оболочка для зашифрованного содержимого. При использовании протокола ESP в туннельном режиме каждый исходный IP-пакет вместе с концевиком ESP шифруется и в криптозащищенном виде с заголовком ESP помещается в конверт IPSec. Сформированный конверт IPSec, в свою очередь, инкапсулируется в новый IP-пакет. Применение протокола ESP в туннельном режиме без аутентификации AH показано на рис.3.4, а с аутентификацией – на рис.3.5.   Транспортный режим. Протокол ESP. В транспортном режиме передача IР-пакета через сеть выполняется с помощью оригинального заголовка. В транспортном режиме предусматриваются и криптографическое закрытие и аутентификация. К внутреннему содержимому исходного пакета присоединяется заголовок ESP и концевик ESP протокола и содержимое шифруется. Далее аутентифицируется зашифрованный пакет. Для входящих пакетов действия выполняются в обратном порядке, то есть сначала производится аутентификация. Работа протокола ESP в транспортном режиме без AH показана на рис.3.6, с применением АН – на рис.3.7.  Расположение полей заголовков протокольных блоков АН и ESP в транспортном и туннельном режимах показано на рис. 3.8. Заголовки протокольных блоков АН и ESP располагаются в транспортном режиме после заголовка исходного IP-пакета и перед заголовками протоколов верхних уровней, а в туннельном режиме – после заголовка внешнего IP-пакета и перед заголовком внутреннего исходного IP-пакета.
Рис. 3.8 - Расположение полей заголовков протокольных блоков в транспортном и туннельном режимах Протоколы АН и ESP могут комбинироваться разными способами. Если используется транспортный режим, то аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием, протокол АН должен применяться после протокола ESP. В туннельном режиме протоколы АН и ESP применяются к разным вложенным пакетам и, кроме того, в данном режиме допускается многократная вложенность туннелей с различными начальными и/или конечными точками. Поэтому в случае туннельного режима число возможных комбинаций по совместному использованию протоколов АН и ESP существенно больше. 28. Технические решения по защите от НСД компьютерных ресурсов на уровне серверов и рабочих станций ЛВС Ответ: |