Мошак_Птицына_ Учебное пособие. Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский
 Скачать 3.09 Mb.
|
|
4.2. Организационно-технические решения для защиты корпоративной МСС 4.2.1. Общие технические решения для корпоративной защиты МСС 1. Пользователи должны иметь доступ к сетевым серверам, выделенным в отдельный сегмент, через строго определенный набор протоколов связи и приложений с использованием прокси-механизмов. 2. Пользователи, внешние по отношению к сети, не должны иметь доступа к ресурсам корпоративной сети региона за исключением ресурсов демилитаризованных зон «открытого» контура ЛВС согласно строго определенному набору протоколов связи и приложений. 3. Удаленное администрирование систем безопасности в сети должно осуществляться с использованием шифрования трафика управления IP- уровнем или с использованием протоколов управления, поддерживающих шифрование данных (SNMP v3). 4. Управление активным сетевым оборудованием корпоративной сети должно контролироваться специалистами отдела информационной безопасности с использованием механизмов регулярного аудита сетевого оборудования. Подсистема аудита должна управляться подразделениями информационной безопасности. 5. Защита сети должна основываться на следующих решениях: – магистральное шифрование сетевого трафика в сегменте региональной сети при передаче между «закрытыми» контурами ИС; – построение системы защиты сетевого уровня с помощью виртуальных частных VPN-сетей при передаче трафика между «открытыми» контурами ИС; – использование брандмауэров для разграничения ресурсов физических и виртуальных сетей подразделений ИС; – применение средств фильтрации информации на прикладном уровне и прокси-систем наряду с пакетными фильтрами; – создание сегментов ЛВС на основе оборудования структурированной кабельной системы, и обеспечение защиты физического уровня на этой основе; – минимизация количества точек доступа к периметру «открытых» контуров ИЭ и их обязательный контроль; – применение средств усиленной аутентификации пользователей и ресурсов корпоративной сети; – применение систем обнаружения вторжений на сетевом, системном и прикладном уровнях; – обеспечение удаленного администрирования и аудита всех компонентов системы безопасности, организация регистрации событий и подотчетность пользователей и администраторов. 5. Необходимо применять специальное антивирусное программное обеспечение ко всей почте, а также осуществлять автоматический антивирусный контроль ЛВС и почтовых серверов. 4.2.2. Технические решения для защиты корпоративной МСС на базе сканеров безопасности Одним из важнейших элементов технологии IP-безопасности организации является периодическая оценка корпоративной сетевой безопасности. Одним из методов автоматизации процессов такой оценки является метод, построенный на технологии интеллектуальных программных агентов или сканеров безопасности. Они предназначены для сканирования известных уязвимостей сетевых служб и неверных параметров конфигурации ОС, приводящих к «отказу в обслуживании», выявления уязвимостей, специфичных для конкретной сетевой ОС, проверки надежности службы NFS, проверки служб удаленного доступа и т. д. Сканеры безопасности включают в себя продукты семейства Internet Scanner и System Scanner от ISS [24]. Они управляются централизованно и обеспечивают тестирование и создание отчетов с консоли безопасности. Система System Scanner (S2) установлена на серверах и брандмауэрах. Консоль управления S2 - на АРМ администратора безопасности ИС, система Internet Scanner - на АРМ администратора безопасности ИС и настроена на проверку уязвимости серверов ИС, маршрутизаторов, брандмауэров, DNS- сервера и т. д. Тестирование безопасности системы должно выполняться ежедневно при наименьшей загрузке протестированных ресурсов с экспортом результатов в базу данных аудита. 4.2.3. Технические решения для защиты корпоративной МСС на базе систем обнаружения вторжений Сканеры безопасности позволяют оценить безопасность корпоративной сети. Однако они не обнаруживают проникновение злоумышленника в сеть, поэтому вторым необходимым элементом защиты сети является система быстрого обнаружения и реагирования на атаки RealSecure [24], которая позволяет обнаружить атаку на сетевой узел путем обнаружения статистических шаблонов сетевого трафика и сравнения их с масками, хранящимися в базе данных. 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. Использование вычислительных ресурсов хостов, которым они управляют. Высокое потребление системных ресурсов при необходимости детального мониторинга (производительность процессора, потребление локального диска и архивной памяти). 4.2.4. Организационно-технические решения для защиты сетевого оборудования Для защиты сетевого оборудования необходимо выполнить следующие настройки и операции. 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. Параметры аудита внешнего маршрутизатора должны включать аудит нарушений, правила фильтрации и другие ограничения, а также все команды пользователя на уровнях привилегий. Вся информация аудита должна автоматически отправляться на сервер аудита безопасности для дальнейшего анализа. Данные системного журнала также должны быть отправлены на сервер аудита безопасности. 4.2.5. Организационно-технические решения для организации защиты межсетевого взаимодействия Одной из базовых задач построения защищенных корпоративных сетей является проблема защиты информации в процессе ее передачи по открытым каналам связи. Использование технологии защищенных виртуальных сетей VPN позволяет обеспечить криптозащиту информации при организации защищенных каналов связи или защищенных туннелей между «открытыми» контурами ЛВС взаимодействующих систем [18, 25 - 29]. VPN-агенты могут осуществлять функции шифрования/расшифрования, аутентификации, а также контроль целостности сообщения посредством электронной цифровой подписи (ЭЦП) или имитовставки (ИВ). Как правило, VPN-агенты поддерживают несколько стандартных протоколов организации защищённых туннелей, которые могут применяться на разных уровнях логической структуры эталонной модели архитектуры BOC. Хотя эти протоколы могут находиться на всех уровнях эталонной модели, средства VPN являются только теми, которые полностью прозрачны для сетевых служб и приложений пользователя. Это протоколы защищенных туннелей канального, сетевого и транспортного уровней. Эти три уровня, которые в терминах модели BOC образуют логическую структуру транспортной системы зоны взаимодействия открытых систем, также называются уровнями VPN. Чем ниже уровень эталонной модели, на которой реализована защита, тем она прозрачнее для приложений и невидима для пользователей. Однако снижение этого уровня снижает количество реализуемых услуг по обеспечению безопасности и усложняет управление. Чем выше уровень безопасности по модели OSI, тем шире спектр услуг безопасности, тем надежнее контроль доступа и проще настроить систему безопасности. Однако в этом случае увеличивается зависимость от используемых протоколов обмена и приложений. Существует два способа создания безопасных туннелей данных на уровне LAN и оконечных устройств [18]. Туннели уровня LAN обычно прозрачны для рабочих станций. В этом случае рабочие станции отправляют все сообщения в виде обычного текста. Кодер отбирает и кодирует пакеты, а декодер на противоположном конце канала декодирует сообщения и передает их сетевому серверу. Шифрование на уровне целевой системы выполняется на рабочей станции или сервере. В незашифрованном виде пакеты вообще не передаются по сети. Существует два типа такой связи: «клиент-клиент» (кодер и декодер установлены на конечных системах, а незашифрованных пакетов вообще нет) и «клиент-сеть» (клиент взаимодействует с системой шифрования сетевого уровня). Защита информации в процессе передачи по открытым каналам связи основана на выполнении следующих функций: – аутентификация взаимодействующих сторон; – криптографическое закрытие передаваемых данных; – подтверждение подлинности и целостности доставленной информации; – защита от повтора, задержки и удаления сообщений; – защита от отрицания фактов отправления и приема сообщений. Примечание 4.1. Выбор методов и средств защиты технологии виртуализации следует проводить с учетом требований [30]. 4.2.5.1. Протоколы VPN канального уровня OSI Протокол туннелирования точка-точка (PPTP) был разработан Microsoft при поддержке Ascend Communications, 3Com/Primary Access, ECI-Telematics и US Robotics для обеспечения стандартного протокола туннелирования точка-точка. PPTP не указывает конкретные методы аутентификации и шифрования. Протокол L2F туннелирования (Layer-2 Forwarding), разработанный Cisco Systems при поддержке компаний Shiva и Northern Telecom, также соответствует канальному уровню модели OSI. В этом протоколе также не указаны конкретные методы аутентификации и шифрования. В отличие от PPTP, L2F позволяет использовать не только PPP, но и другие протоколы, например SLIP, для удаленного доступа к своему интернет-провайдеру. Интернет-провайдеры не должны настраивать адреса и проверять подлинность при создании безопасных каналов по глобальной сети. Кроме того, различные протоколы сетевого уровня могут использоваться для передачи данных через защищенный туннель, а не только через IP, как в PPTP. Протокол L2F стал компонентом операционной системы Cisco IOS и поддерживается на всех выпускаемых устройствах взаимодействия и удаленного доступа. Протоколы PPTP и L2F были представлены на рассмотрение Целевой группы по проектированию Интернета (IETF), и в 1996 году соответствующие комитеты приняли решение объединить их. Результирующий протокол, включавший лучшие из PPTP и L2F, назывался Layer-2 Tunneling Protocol (L2TP). Поддерживается компаниями Cisco, Microsoft, 3Com, Ascend и многими другими производителями. Гибридный протокол L2TP сочетает в себе лучшие функции вышеуказанных протоколов и добавляет новые функции. Протокол L2TP может поддерживать любые протоколы высокого уровня и обеспечивает управление потоком данных, удаленную аутентификацию пользователей, безопасную установку виртуальных соединений, а также позволяет открывать несколько туннелей между пользователями, каждый из которых администратор может выделить приложению. Как и предыдущие протоколы канального уровня, спецификация L2TP не описывает методы аутентификации и шифрования. Таким образом, протокол L2TP является расширением протокола PPP с помощью функций аутентификации удаленных пользователей, установления безопасного виртуального соединения и управления потоком данных. Протоколы CHAP/PAP или другие могут использоваться для аутентификации в корпоративной сети до начала сеанса PPP. Гарантированная доставка информации в сеансе обеспечивается нумерацией защищенных кадров в соединении, восстановлением потерянных и искаженных кадров. Протокол L2TP предусматривает три этапа установления соединения: установление соединения с удаленным сервером LAN; Аутентификация пользователя; Конфигурирование безопасного туннеля. Протоколы защищенных туннелей на канальном уровне не зависят от протоколов сетевого уровня модели OSI, над которыми работают локальные сети, входящие в состав виртуальных сетей. Они позволяют создавать безопасные каналы для связи между удаленными компьютерами и локальными сетями, работающими по разным протоколам сетевого уровня. Пакеты этих протоколов криптографически защищены и инкапсулируются в IP-пакеты Интернета, которые транспортируются к месту назначения, образуя безопасные виртуальные каналы. Многопротокольность – является основным преимуществом протоколов инкапсуляции канального уровня. Однако формирование криптографически защищенных туннелей между «открытыми» контурами взаимодействующих систем на основе протоколов канального уровня приводит к трудностям конфигурирования и поддержки виртуальных каналов связи. Кроме того, в протоколах формирования безопасных туннелей на канальном уровне не указаны конкретные методы шифрования, аутентификации, проверки целостности каждого передаваемого пакета, а также средства управления ключами. Из вышесказанного можно сделать вывод, что протоколы для создания безопасных виртуальных линий связи на канальном уровне лучше всего подходят для защиты связи при удаленном доступе к LAN. 4.2.5.2. Протоколы VPN сетевого уровня модели OSI Спецификация, описывающая стандартные методы для всех компонентов и функций защищённых виртуальных сетей, представляет собой протокол Internet Protocol Security (IPsec), соответствующий сетевому уровню модели OSI и являющийся частью шестой версии протокола IP-IPv6. IPsec иногда еще называют протоколом туннелирования третьего уровня (Layer-3 Tunneling). IPsec предоставляет стандартные методы проверки подлинности пользователей или компьютеров при инициировании туннеля, стандартные методы шифрования конечных точек туннеля, создания и проверки цифровой подписи, а также стандартные методы обмена криптографическими ключами между конечными точками и управления ими. Этот гибкий стандарт предлагает несколько способов выполнения каждой задачи. Методы, выбранные для одной задачи, обычно не зависят от методов для других задач. Для функций аутентификации IPsec поддерживает цифровые сертификаты популярного стандарта X.509. Туннель IPsec между двумя локальными сетями может поддерживать несколько отдельных каналов передачи данных, что приводит к тому, что этот тип приложения обладает преимуществом масштабирования по сравнению с технологией уровня 2. IPsec может использоваться совместно с L2TP. Вместе эти два протокола обеспечивают наивысший уровень гибкости в защите виртуальных каналов. Дело в том, что спецификация IPsec ориентирована на IP и, таким образом, бесполезна для трафика любых других протоколов сетевого уровня. Протокол L2TP не зависит от транспортного уровня, который может быть использован в гетерогенных сетях. Архитектура семейства протоколов IPsec (рис.4.2) включает в себя: – протокол управления ключами (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 с протоколом, защита которого обеспечивается. Протокол обмена ключевой информацией 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). Верхний уровень Средний уровень Нижний уровень Рис.4.2. Архитектура семейства протоколов IPsec Согласно протоколу IKE, при формировании безопасного виртуального туннеля взаимодействующие стороны должны разработать общий контекст безопасности (Security Association, SA) и только затем использовать элементы этого контекста [31]. Контекст безопасности SA для любого протокола представляет собой согласованный набор параметров, определяющих услуги и механизмы, предоставляемые этим протоколом для защиты трафика в сеансе связи, копия которого доступна каждой из сотрудничающих сторон. Контекст безопасности по существу представляет собой общее согласованное состояние отправителя и получателя, которое, в частности, определяет предоставляемые услуги, используемые криптографические алгоритмы и ключи в сеансе. Таким образом, основной целью IKE является автоматическое обеспечение безопасности согласования контекста безопасности для семейства протоколов IPsec между участниками мультимедийного сеанса. Протокол согласования контекста безопасности и управления ключами (IKE) Протокол аутентифицирую щего заголовка (АН) Протокол инкапсулирующ ей защиты содержимого (ESP) Алгоритмы согласование контекстов параметров и управления ключами безопасности Алгоритмы аутентификации Алгоритмы шифрования Домен интерпретации (DOI) В работе 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. Протокол аутентифицирующего заголовка АН и протокол инкапсулирующей защиты содержимого ESP. Как упоминалось выше, при формировании защищенного виртуального канала взаимодействующие стороны должны разработать общий контекст безопасности SA и только затем использовать элементы этого контекста, такие как алгоритмы и ключи. Для семейства IPsec такими контекстами безопасности являются ESP SA и AH SA (общее название этих контекстов безопасности - IPsec SA). Протокол заголовка аутентификации AN обеспечивает аутентификацию источника данных, проверку его целостности и подлинности после приема, а также защиту от навязывания повторяющихся сообщений. Протокол инкапсуляции содержимого ESP обеспечивает криптографическое закрытие пакетов передаваемых сообщений, а также выполняет все функции протокола AS. ESP может поддерживать функции шифрования и аутентификации/целостности в любой комбинации, то есть либо группу функций, только аутентификацию/целостность, либо только шифрование. Протоколы АН и ESP не зависят от конкретных криптографических алгоритмов. Могут использоваться любые методы аутентификации, типы ключей (симметричные или несимметричные), алгоритмы шифрования и выделения ключей. Например, каждая страна может использовать свой собственный алгоритм, соответствующий национальным стандартам. В настоящее время регистрируются два значения аутентификации для протоколов AS и ESP - HMAC-MD5 (Hashed Message Authentication Code - Message Digest версии 5) и HMAC-SHA1 (Hashed Message Authentication Code - Secure Hash Algorithm версии 1). Эти алгоритмы являются алгоритмами аутентификации секретного ключа. Если секретный ключ известен только передающей и принимающей сторонам, он обеспечивает аутентификацию источника данных, а также целостность пакетов, передаваемых между двумя сторонами. Алгоритм по умолчанию определяет алгоритм HMAC-MD5. Для ESP зарегистрировано семь алгоритмов шифрования. Стандарт шифрования данных, как и алгоритм НМАС-MD5, является стандартом по умолчанию для совместимости с IPsec. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC5, IDEA, Blowfish и ARCFour. Протоколы AH и ESP поддерживают два режима: а) туннельный режим. IP-пакеты защищены полностью, включая заголовки. Это главный режим. В этом режиме каждый обычный IP-пакет помещается полностью в криптографически защищенную форму в конверте IPsec, который, в свою очередь, инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуется на выделенных шлюзах безопасности, которые могут быть маршрутизаторами или брандмауэрами. Между этими шлюзами формируются безопасные туннели IPsec. Туннелирование IP-пакетов полностью прозрачно для конечных пользователей. В оконечных системах туннельный режим может использоваться для поддержки удаленных и мобильных пользователей. В этом случае компьютеры этих пользователей должны иметь программное обеспечение, реализующее туннель IPsec. Протокол заголовка аутентификации AN [RFC1826], [RFC1827] обеспечивает аутентификацию источника данных, проверку его целостности и подлинности после приема и защиту от навязывания повторяющихся сообщений. В основе обеспечения целостности и аутентификации данных лежит шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function); б) транспортный режим. Только содержимое исходного IP-пакета помещается в конверт IPsec в криптографически защищенной форме, и исходный IP-заголовок добавляется к принятому конверту. Соответственно, в транспортном режиме заголовок IPsec помещается между заголовками сети (IP) и транспорта (TCP или UDP) обычного IP-пакета. Транспортный режим быстрее туннельного и предназначен для использования на терминальных системах. Это может использоваться для поддержки удаленных и мобильных пользователей и защиты информационных потоков в локальных сетях. В транспортном режиме IPsec помещает только содержимое защищаемого IP- пакета и добавляет исходный IP-заголовок к полученному конверту. Заголовки блоков протоколов AN и ESP расположены в транспортном режиме после заголовка IP-пакета источника и перед заголовками протокола верхнего уровня, а в туннельном режиме - после заголовка внешнего IP- пакета и перед заголовком исходного IP-пакета (рис.4.3). Транспортный режим Туннельный режим [IPисх.][AH][сервисный блок TCP/UDP] [IPвнеш.][AH][IPисх.][ сервисный блок TCP/UDP] [IPисх][ESP][ сервисный блок TCP/UDP] [IPвнеш.][ESP][IPисх.][ сервисный блок TCP/UDP] [IPисх.][AH][ESP][ сервисный блок TCP/UDP] Рис.4.3. Расположение полей заголовков протокольных блоков в транспортном и туннельном режимах Сравнение различных режимов для протоколов АН и ESP представлено в табл. 4. 3. Таблица 4.3. Сравнение различных режимов для протоколов АН и ESP Протокол Транспортный режим Туннельный режим АН Идентифицирует протокол- пассажир IP, а также отдельные части заголовка IP и заголовка расширений IPv6 Идентифицирует весь внутренний пакет IP (заголовок и протокол-пассажир внутреннего пакета IP), а также отдельные части внешнего заголовка IP и внешних заголовков расширений IPv6 ESP Шифрует протокол-пассажир IP и все заголовки расширений IPv6, следующие за заголовком ESP Шифрует внутренний пакет IP ESP с аутентификацией Шифрует протокол-пассажир IP и все заголовки расширений Ipv6, следующие за заголовком ESP. Идентифицирует протокол- пассажир IP и заголовок IP. Шифрует внутренний пакет IP. Идентифицирует внутренний пакет IP. Протоколы АН и ESP могут комбинироваться разными способами. Если используется транспортный режим, то аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием, протокол АН должен применяться после протокола ESP. В туннельном режиме протоколы АН и ESP применяются к разным вложенным пакетам и, кроме того, в данном режиме допускается многократная вложенность туннелей с различными начальными и/или конечными точками. Поэтому в случае туннельного режима число возможных комбинаций по совместному использованию протоколов АН и ESP существенно больше. 4.2.5.3. Протоколы VPN сеансового уровень модели OSI Безопасные виртуальные каналы также могут генерироваться на сеансовом уровне модели OSI. Для этого применяются так называемые «посредники каналов» (circuit proxy). Посредник работает над транспортным уровнем, шифрует и передает трафик из защищенной сети в общедоступный Интернет для каждого сокета по отдельности. При приеме выполняется обратная процедура. IP-сокет идентифицируется комбинацией TCP- соединения и определенного порта или указанного UDP-порта. SSL/TLS (Secure Sockets Layer/Transport Layer Security), разработанный Netscape Communications, является наиболее популярным протоколом для шифрования на уровне сеанса. Этот протокол создает безопасный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность данных, циркулирующих через туннель. Ядром протокола SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем организации RSA Data Security. Для стандартизации связи клиент-серверных приложений TCP/IP через сервер-посредник (брандмауэр) IETF утвердил протокол, называемый SOCKS. Пятая версия этого протокола (SOCKS5 [RFC1928]) используется для стандартизированной реализации канальных посредников в настоящее время. SOCKS5 поддерживает приложения, требующие контроля над направлениями информационных потоков и настройки условий доступа в зависимости от атрибутов пользователя и/или информации. Согласно протоколу SOCKS5, клиентский компьютер устанавливает аутентифицированный сеанс с прокси-сервером. Использование этого прокси - единственный способ взаимодействия через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрошенные клиентом. Поскольку брокер знает о трафике на уровне сеанса (сокета), он может осуществлять тщательный контроль, например, блокировать конкретные пользовательские приложения, если у них нет необходимых полномочий. В отличие от виртуальных сетей, защищенных на сеансовом уровне модели OSI, виртуальные сети, защищенные на уровне канала или сетевом уровне, обычно просто открывают или закрывают канал для всего трафика в аутентифицированном туннеле. Это может быть проблемой, если ЛВС на другом конце туннеля не является надежной. Кроме того, установленные туннели канального и сетевого уровней работают одинаково в обоих направлениях, а защищенные сеансовым уровнем виртуальные сети обеспечивают независимое управление передачей в каждом направлении. Виртуальные сети прокси-канала IPsec ориентированы на IP. Если IPsec по существу различает защищенные виртуальные каналы между различными парами взаимодействующих сторон, протокол SOCKS5 предоставляет защищенные туннели для каждого приложения и сеанса по отдельности. Аналогично протоколам туннелирования IPsec и канального уровня, виртуальные сети сеансового уровня могут использоваться с другими типами протоколов VPN, поскольку эти технологии не являются взаимоисключающими. 4.2.5.4. Распределение криптографических ключей и согласование параметров защищенных туннелей При создании безопасных виртуальных сетей одной из наиболее важных функций является распределение криптографических ключей и согласование параметров безопасного туннеля. Эти функции выполняются при формировании каждого криптографически защищенного туннеля. На уровне сети и сеанса модели OSI в большинстве случаев используются асимметричные криптосистемы, на основе протоколов распределения временных (сеансовых) ключей (SKIP, ISAKMP, SSL Handshake Protocol). При использовании этих криптосистем временные ключи распределяются с использованием главных открытых ключей. Распределение временных ключей на сетевом уровне чаще всего осуществляется алгоритмом Диффи-Хеллмана [32]. На уровне сеанса временные ключи обычно распределяются с использованием асимметричных систем, таких как RSA и El Gamal. В протоколах формирования защищенных туннелей на канальном уровне модели OSI (PPTP, L2F, L2TP) временные ключи чаще всего генерируются на основе паролей пользователей [33]. Генерация осуществляется каждой стороной информационного взаимодействия после взаимной аутентификации. Согласование двух временных ключей, генерируемых противоположными сторонами для одного защищаемого туннеля, обеспечивается их расчётом на основе одних и тех же параметров, включающих в себя согласованное случайное число или временную метку, а также хэш-функцию от пароля. Учитывая, что пароли являются аналогами основных ключей симметричного шифрования, более эффективным способом распределения временных ключей на канальном уровне является централизованное их распределение, например, на основе протокола Kerberos. В зависимости от простоты реализации и достигаемой степени безопасности возможны следующие способы построения защищенного канала между двумя узлами компьютерной сети: – для каждого соединения, устанавливаемого от имени какого-либо программного приложения; – между сетевыми узлами и создание в рамках этого канала отдельных защищенных соединений, устанавливаемых от имени программных приложений; Формирование защищенного виртуального канала для каждого соединения предполагает реализацию следующих этапов: – выдача запроса одной из сторон и достижение соглашения на создание защищенного туннеля; – аутентификация сторон, которая выполняется с помощью ранее распределенных основных ключей шифрования или назначенных паролей; – распределение временных ключей и согласование параметров защищенного туннеля. Вторая и третья фазы чаще всего пересекаются друг с другом, и аутентификация выполняется совместно с распределением временных ключей. Исключением является только случай проверки подлинности сторон осуществляемой на основе парольных методов. В случае формирования между двумя сетевыми узлами общего защищенного канала, в контексте которого создаются отдельные защищенные соединения, перечисленные этапы выполняются также и при создании каждого защищенного соединения, устанавливаемого от имени программных приложений взаимодействующих сторон. Формирование между двумя сетевыми узлами общего защищенного канала и создание на его базе отдельных защищенных соединений характеризуется более высокой сложностью реализации. Однако в этом случае снижается уязвимость закрытых основных ключей, служащих для распределения главного сеансового ключа, и может быть обеспечено более эффективное расходование компьютерных ресурсов, затрачиваемых на генерацию временных ключей. Снижение ресурсных издержек на генерацию временных ключей достигается за счет переноса основной части вычислений на стадию распределения и генерации главного сеансового ключа. 4.2.3. Организационно-технические решения для организации защиты межсетевого взаимодействия с применением межсетевых экранов Для межсетевой защиты в корпоративной сети и ее экранирования от атак извне, для обнаружения и регистрации внешних атак необходимо применение межсетевых экранов [13]. С помощью журналов аудита межсетевых экранов необходимо отслеживать: – попытки соединения с ЛВС «открытого» контура с неразрешенных IP- адресов; – попытки использования неразрешенных протоколов уровня TCP/UDP и соединения с неразрешенными портами серверов ЛВС «открытого» контура извне; – попытки компрометации защищенных IP-соединений к ресурсам корпоративной сети; – попытки использования незащищенных IP-соединений при межсетевом взаимодействии в региональной корпоративной сети. Для оперативного анализа информации аудита необходимо настроить журнал syslogd межсетевых экранов таким образом, чтобы события аудита дублировались на сервер аудита службы безопасности, т. е. для всех межсетевых экранов хост loghost в файле /etc/hosts должен ссылаться на сервер аудита службы безопасности. Для обеспечения надежности функционирования механизмов фильтрации трафика необходимо резервировать межсетевые экраны. Известно [16], что любые механизмы защиты вносят временную, протокольную и потоковую избыточность в информационное окружение сети и приводят к ухудшению ее характеристик. Эти виды избыточности при проектировании защищенной корпоративной МСС должны быть учтены в ее критериях эффективности и ограничениях задач анализа [16]. Прикладные аспекты указанной проблемы связаны с повышением качества проектирования защищенных МСС, что в конечном итоге приводит к повышению эффективности использования сетевых ресурсов и сокращению затрат на их создание. В Приложении 1 приведена формализация процессов предоставления механизмов защиты в корпоративной мультисервисной сети. 4.3. Организационно-технические решения по настройке журналов аудита на объектах мониторинга ИС Система мониторинга ИБ ИС для выявления инцидентов ИБ постоянно осуществляет сбор и анализ событий журналов штатного аудита подконтрольных объектов ИС, в том числе СЗИ. При регистрации событий должны быть выполнены следующие требования: 1. Полнота регистрируемых событий должна быть достаточна и не избыточна для доказательного разбора ситуации; 2. Должна быть обеспечена максимально возможная независимость данных аудита от администратора контролируемой системы; 3. Должна быть обеспечена невозможность несанкционированного искажения журналов аудита, в том числе и администраторами контролируемой системы; 4. Хранение журналов аудита должно быть обеспечено в течение сроков, определенных руководящими документами ИБ организации. Независимо от типа операционной системы в журналах штатного аудита должны регистрироваться следующие события: 1. Идентификационная информация, в том числе и попытки подбора пароля пользователями; 2. Операции, отвергнутые ИС из-за недостатка полномочий у пользователей; 3. Факты модификации конфигурационных файлов ИС; 4. Факты изменения администраторами полномочий пользователей «закрытого» и «открытого» контура ИС; 5. Факты отключения системы аудита администраторами; 6. Факты запуска и останова ИС. 4.3.1. Организационно-технические решения по настройке и сбору данных журнала аудита ОС HP-UX Получение данных журнала аудита ОС HP-UX может осуществляться двумя способами: 1) на сервер, с консоли «root» инсталлируется агент, который в режиме «on-line» передаёт свой аудит. На серверной части обработки аудита, на основе двоичных событий аудита в формате ОС HP–UX формируются события для записи в базу данных сервера аудита службы безопасности. Достоинство данного режима заключается в следующем: – агент осуществляет полностью автоматический режим управления подсистемой аудита (устанавливает для подсистемы аудита вспомогательный файл аудита, размер вспомогательного файла аудита, осуществляет сбор информации из файлов wtmp, btmp, sulog для генерации более качественных записей в БД, осуществляет контроль за размером файлов wtmp, btmp, sulog); – ручная работа администраторов (пользователей «root» и «auditor») минимальна, и сводится только к инсталляции агента и добавлению событий, подлежащих аудиту; 2) вторая схема предполагает накопление аудита на подконтрольных объектах и дальнейшее использование службы удаленного доступа к их файловым системам (например, по протоколу FTP) для переноса данных аудита на сервер аудита службы безопасности. После разбора, преобразования, аудит записывается в базу данных сервера аудита службы безопасности. Недостатки такого подхода заключаются в следующем: – наличие ручной работы администраторов по управлению подсистемой аудита (установка вспомогательного файла аудита, размера файла); – политика безопасности на серверах под управлением ОС HP-UX разрешает читать и записывать файлы аудита только пользователю «root», это обеспечивается установкой прав доступа на файлы аудита (0600). Следовательно, для чтения данных аудита необходимо использовать учетную запись «root»; – администратор должен как минимум раз в сутки переписывать заполненные файлы аудита с подконтрольных серверов на сервер аудита службы безопасности. Очевидно, что при большом потоке данных аудита съем аудита должен осуществляться чаще. Соотношение размера файлов аудита и периодичности их съема должны быть установлены в ходе опытной эксплуатации. 4.3.2. Организационно-технические решения по настройке и сбору данных журнала аудита СУБД Oracle Требования к настройкам журнала штатной подсистемы регистрации событий. Штатная процедура регистрации событий (ШПРС) СУБД Oracle опциональна. Опции аудита устанавливаются при помощи SQL-команды AUDIT. При эксплуатации с включенным аудитом требуется определенный расход вычислительных ресурсов СУБД, необходимый для генерации записей аудита. В случае неграмотной настройки аудита (например, включения аудита на применение всех привилегий ко всем объектам) может привести к полной неработоспособности СУБД из-за недостатка вычислительных ресурсов. Кроме того, при переполнении таблицы аудита, SQL-операции с БД, которые вызывают появление новых записей в таблице аудита, перестают выполняться. Поэтому необходимо точное определение перечня необходимых событий аудита и перечня объектов БД, для которых необходимо включить аудит. В подсистеме аудита СУБД Oracle можно настроить аудит по следующим критериям: – можно выполнять аудит конкретных SQL-операторов безотносительно к конкретным объектам. Например, можно генерировать запись аудита каждый раз, когда какой-либо пользователь выполняет оператор DROP TABLE, и не учитывать, к какой таблице относится этот оператор; – можно выполнять аудит использования мощных системных привилегий. Например, генерировать запись аудита каждый раз, когда какой- либо пользователь применяет системную привилегию SELECT ANY TABLE для запроса к таблице БД; – можно выполнять аудит определенных SQL-операторов для конкретных объектов БД. Например, генерировать запись аудита каждый раз, когда какой-либо пользователь удаляет запись из таблицы MODES; – можно выполнять формирование одной аудиторской записи на применение каждого тип SQL-оператора в течение сеанса работы пользователя. Наименее ресурсоемким и минимально необходимым является аудит привилегии CREATE SESSION, включение которого позволяет фиксировать факты регистрации и завершения работы пользователей. При наличии указанных фактов подсистема анализа способна выявить нетипичную активность пользователей: – регистрация пользователя в СУБД в нерабочее время; – регистрация с нетипичного для данного пользователя компьютера (терминала); – регистрация пользователя в СУБД с именем, несоответствующим его имени в ОС. С целью улучшения качества контроля, аудит для контролируемых объектов БД необходимо установить для всех пользователей СУБД. Для минимизации ресурсов, потребляемых аудитом, необходимо воспользоваться возможностью формирования одной аудиторской записи на каждый тип SQL-выражения. СУБД Oracle генерирует записи аудита только после того, как аудит разрешен и для него установлены соответствующие опции. Например, можно установить опции аудита для конкретных субъектов. В Oracle разрешается сохранять генерируемые записи аудита либо в журнале аудита базы данных (фактически таблица записей аудита входит в состав контролируемой БД), либо в таком же журнале операционной системы, в которой работает СУБД Oracle Server. При использовании журнала аудита базы данных можно легко просматривать и находить записи аудита с помощью SQL-запросов и предварительно созданных для этого журнала представлений словаря данных. 4.3.3. Организационно-технические решения по настройке и сбору данных журнала аудита ОС Windows Подсистема аудита ОС Windows обеспечивает регистрацию событий, связанных с работой ОС, и функционирование механизмов сохранения данных о событиях в журналы событий. В ОС Windows по умолчанию создаются следующие журналы событий: – система (system); – приложение (application); – безопасность (security); – установка (setup); – перенаправленные события (forwarded events). Системный журнал содержит события, записываемые системными компонентами ОС. Например, в журнале системы регистрируются сбои при загрузке драйвера или других системных компонентов в процессе загрузки системы. Типы событий, которые регистрируются компонентами системы, определены на уровне операционной системы. В журнале приложений фиксируются события, относящиеся к работе приложений и программ. События, регистрируемые в журнале приложений, определяются разработчиками соответствующих приложений. Журнал безопасности содержит события, связанные с безопасностью. Например, успешные и неуспешные попытки входа в систему, события, относящиеся к использованию ресурсов, такие как создание, открытие и удаление файлов и других объектов. В журнале установки фиксируются события, связанные с установкой и обновлением системы, ее ролей, компонентов и приложений. Журнал перенаправленных событий используется для хранения событий, собранных с удаленных компьютеров. Состав событий, регистрируемых подсистемой аудита ОС Windows, определяется политикой аудита и настройками аудита конкретных объектов доступа (файлов, каталогов, ключей реестра, объектов каталога Active Directory и т. д.). Параметры политики аудита ОС Windows подконтрольных объектов необходимо настроить следующим образом: – аудит входа в систему (audit logon events) – успех (success), отказ (failure); – аудит изменения политики (audit policy change) – успех; – аудит управления учетными записями (audit account management) – успех, отказ; – аудит доступа к объектам (audit object access) – успех, отказ; аудит доступа к службе каталогов (audit directory service access) – успех, отказ; – аудит системных событий (audit system events) – успех; – аудит отслеживания процессов (audit process tracking) – успех. Для контроля функций управления локальными политиками подконтрольных объектов дополнительно необходимо настроить аудит |