R75.40VS
Руководство администратора
20 ноября 2012 г.
© 2012 Check Point Software Technologies Ltd.
Все права защищены. Данный продукт и соответствующие документы защищены авторским
правом, и распространяются по лицензированию, ограничивающему их использование,
копирование, распространение и декомпиляцию. Никакая часть настоящего продукта или
соответствующей документации не может воспроизводиться ни в какой форме, никакими
средствами без предварительного письменного разрешения со стороны Check Point. Несмотря на
все меры предосторожности, принятые при подготовке данной книги, Check Point не берет на себя
ответственность за ошибки или упущения. Данное издание и описанные в нем функциональные
возможности могут быть изменены без предупреждения.
ИНФОРМАЦИЯ ОБ ОГРАНИЧЕНИИ ПРАВ:
На использование, копирование и предоставление информации правительством действуют
ограничения, установленные в подпункте (c)(1)(ii) пункта о Правах в Положении о технических
данных и программном обеспечении в DFARS 252.227-7013 и FAR 52.227-19.
ТОВАРНЫЕ ЗНАКИ:
Список товарных знаков представлен на странице об авторском праве
(http://www.checkpoint.com/copyright.html).
Список соответствующих авторских прав и лицензий третьих сторон представлен в уведомлениях
об авторском праве третьих сторон (http://www.checkpoint.com/3rd_party_copyright.html).
Новейшая документация
Последняя версия этого документа содержится по адресу:
http://supportcontent.checkpoint.com/documentation_download?ID=16210
Для получения дополнительной технической информации посетите центр технического обслуживания Check
Point (http://supportcenter.checkpoint.com).
История редакций
Дата Описание
20 ноября 2012 г. Обновлен пункт «Особенности проводного режима» (на стр. 101)
Обновлен пункт «Обзор VPN на основе маршрутов» (на стр. 71)
5 августа 2012 г. Обновлена информация о поддержке IKEv1 («IKEv1 и IKEv2» на стр. 17)
15 июля 2012 г. Первый выпуск данного документа
Обратная связь
Check Point непрерывно работает над усовершенствованием своей документации.
Просим Вас помочь нам в этом, направляя Ваши комментарии
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on VPN R75.40VS Administration
Guide).
ВАЖНАЯ ИНФОРМАЦИЯ..................................................................................................................... 3
РЕШЕНИЕ ДЛЯ VPN КОМПАНИИ CHECK POINT ............................................................................... 9
КОМПОНЕНТЫ VPN ............................................................................................................................... 9
ТЕРМИНОЛОГИЯ .................................................................................................................................... 9
VPN SITE-TO-SITE .............................................................................................................................. 10
VPN-СООБЩЕСТВА ............................................................................................................................. 10
VPN С УДАЛЕННЫМ ДОСТУПОМ ............................................................................................................ 11
ПОРТАЛЫ ШЛЮЗА БЕЗОПАСНОСТИ ........................................................................................................ 12
IPSEC И IKE ........................................................................................................................................ 14
ОБЗОР ............................................................................................................................................... 14
IKE, фаза I .................................................................................................................................... 14
IKE, фаза II (Быстрый режим или фаза IPSec) ............................................................................ 16
IKEv1 и IKEv2................................................................................................................................ 17
Методы шифрования и проверки подлинности ........................................................................... 17
Режимы фазы I ............................................................................................................................. 18
Периодичность повторных согласований IKE и IPSec ................................................................ 18
Совершенная прямая секретность .............................................................................................. 18
Сжатие IP...................................................................................................................................... 19
Подсети и Ассоциации защиты .................................................................................................... 19
ЗАЩИТА IKE ОТ DOS-АТАК................................................................................................................... 20
Понятие DoS-атак......................................................................................................................... 20
DoS-атаки IKE ............................................................................................................................... 21
Защита от DoS-атак IKE ............................................................................................................... 21
Настройки защиты IKE от DoS-атаки в SmartDashboard ............................................................. 22
Дополнительные настройки защиты IKE от DoS-атак ................................................................. 22
НАСТРОЙКА ДОПОЛНИТЕЛЬНЫХ СВОЙСТВ IKE ....................................................................................... 23
На сетевом объекте VPN-сообщества......................................................................................... 24
На сетевом объекте шлюза безопасности .................................................................................. 24
ВВЕДЕНИЕ В VPN SITE-TO-SITE....................................................................................................... 25
ЗАЧЕМ НУЖНЫ ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ?...................................................................................... 25
Секретность .................................................................................................................................. 25
Проверка подлинности ................................................................................................................. 25
Целостность ................................................................................................................................. 25
Как это работает ........................................................................................................................... 26
VPN-сообщества .......................................................................................................................... 26
Проверка подлинности между членами сообщества .................................................................. 27
Топологии VPN ............................................................................................................................. 28
Контроль доступа и VPN-сообщества.......................................................................................... 33
Маршрутизация трафика в VPN-сообществе .............................................................................. 34
Исключенные службы .................................................................................................................. 34
ОСОБЕННОСТИ ПЛАНИРОВАНИЯ ТОПОЛОГИИ VPN ................................................................................. 34
КОНФИГУРАЦИЯ VPN SITE-TO-SITE ...................................................................................................... 34
Переход из традиционного режима в упрощенный ..................................................................... 35
Настройка ячеистого сообщества между шлюзами, управляемыми изнутри ............................ 35
Настройка звездообразного VPN-сообщества ............................................................................ 36
Подтверждение успешного открытия VPN-туннеля .................................................................... 36
НАСТРОЙКА VPN СО ШЛЮЗАМИ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫМИ ИЗВНЕ, ПОСРЕДСТВОМ PKI ................. 36
НАСТРОЙКА VPN СО ШЛЮЗАМИ БЕЗОПАСНОСТИ, УПРАВЛЯЕМЫМИ ИЗВНЕ, ПОСРЕДСТВОМ ОБЩЕГО
СЕКРЕТНОГО КЛЮЧА ............................................................................................................................ 38
КАК АВТОРИЗОВАТЬ УПРАВЛЯЮЩИЕ СОЕДИНЕНИЯ БРАНДМАУЭРА В VPN-СООБЩЕСТВАХ .......................... 39
Почему отключение неявных правил брандмауэра блокирует управляющие соединения ....... 40
Разрешение брандмауэром управляющих соединений внутри VPN.......................................... 40
Определение служб, используемых для управляющих соединений .......................................... 40
ИНФРАСТРУКТУРА ОТКРЫТОГО КЛЮЧА ....................................................................................... 41
НЕОБХОДИМОСТЬ ИНТЕГРАЦИИ С РАЗЛИЧНЫМИ РЕШЕНИЯМИ PKI ........................................................... 41
ПОДДЕРЖКА ШИРОКОГО СПЕКТРА РЕШЕНИЙ PKI .................................................................................... 41
Технология виртуальных частных сетей (VPN) улучшает существующую инфраструктуру (Интернет) в аспекте
построения и расширения существующих связей безопасным образом. Основываясь на стандартных
защитных протоколах Интернета, внедрение VPN дает возможность формирования надежных соединений
между особыми типами узлов сети – шлюзами безопасности Check Point. VPN Site-to-Site обеспечивает
надежные соединения между шлюзами безопасности, а VPN с удаленным доступом обеспечивает надежные
соединения между шлюзами безопасности и клиентами удаленного доступа.
Шлюз безопасности Check Point – это интегральное программное решение, обеспечивающее установление
связи в пределах корпоративных сетей, между удаленными пользователями и владельцами мобильных
устройств, филиалами компании и бизнес-партнерами в широком спектре открытых платформ и устройств
защиты.
Шлюзы безопасности Check Point сочетают контроль доступа, проверку подлинности и шифрования, таким
образом, гарантируя безопасность сетевых соединений в Интернете общего пользования.
При типичном развертывании шлюз безопасности Check Point подключается к корпоративной сети (из
Интернета), а программное обеспечение для удаленного доступа устанавливается на компьютеры мобильных
пользователей. Прочие удаленные узлы охраняются дополнительными шлюзами безопасности Check Point, а
связь между всеми компонентами подчиняется строгой политике безопасности.
Компоненты VPN
VPN состоит из:
терминалов VPN, таких как шлюзы безопасности, кластеры шлюзов безопасности или удаленные клиенты
(ноутбуки, мобильные телефоны), сообщающиеся посредством VPN;
объектов сертификации VPN, таких как Внутренний сертификационный центр Check Point (ICA). ICA
является частью пакета Check Point, которая служит для формирования защищенного соединения между
шлюзами безопасности, администраторами проверки подлинности и сторонними серверами. ICA
обеспечивает сертификаты для внутренних шлюзов безопасности и клиентов удаленного доступа,
связанных по линии VPN;
инструментов управления VPN. Сервер управления защитой и SmartDashboard. SmartDashboard – это
SmartConsole для доступа к Серверу управления защитой. Диспетчер VPN является частью
SmartDashboard. SmartDashboard предоставляет организациям возможность определять и развертывать
Интрасеть, а также VPN с удаленным доступом.
Терминология
При внедрении безопасной VPN широко используются ряд специальных терминов.
VPN. Зашифрованная частная сеть, осуществляющая безопасную связь между шлюзами безопасности и
терминалами VPN через сеть общего доступа, например, Интернет.
Интерфейс туннеля VPN. Интерфейс виртуального туннеля (VTI) – виртуальный интерфейс шлюза
безопасности, относящийся к существующему VPN-туннелю на основе маршрутов. VPN-туннель на основе
маршрутов работает как соединение точка-точка между двумя одинаковыми шлюзами безопасности VPN-
сообщества.
Узел. Шлюз безопасности, соединяющийся с другим шлюзом безопасности посредством интерфейса
виртуального туннеля.
Решение для VPN компании Check Point
Топология VPN. Базовым элементом VPN является линия связи или зашифрованный туннель. Линии
связи создаются между шлюзами безопасности. Множество линий связи образуют топологию. Топология
представляет собой план VPN. Две базовые топологии, по которым строится VPN, – это звездообразная и
ячеистая.
Шлюз безопасности VPN. Терминал шифрованного соединения, который может быть любым узлом,
поддерживающим среду протокола IPSec. Шлюзы безопасности могут быть отдельными модулями или
быть организованными в кластеры для «высокой доступности» и «распределения нагрузки».
VPN-домен. Группа, объединяющая хосты или сети, для которых выполняется шифрование IP-датаграмм.
Шлюз безопасности VPN является точкой входа в VPN-домен.
VPN Site-to-Site. Относится к VPN-туннелю между двумя шлюзами безопасности.
VPN с удаленным доступом. Относится к удаленным пользователям, которые получают доступ к сети
при помощи клиентского ПО, такого как Клиенты удаленного доступа Check Point или сторонние клиенты
IPSec. Шлюз безопасности Check Point обеспечивает Службу удаленного доступа для удаленных
клиентов.
Алгоритм шифрования. Набор математических процессов преобразования информации в
бессмысленную форму, при этом математические трансформации управляются специальным ключом.
Шифрование при помощи различных алгоритмов, например, 3DES и AES, обеспечивает возможность
расшифровки сообщения только теми узлами, между которыми осуществляется связь.
Целостность. Проверка целостности (с помощью хэш-функций) обеспечивает тот факт, что во время
передачи данные не были перехвачены или изменены.
Доверие. Для установления доверия между шлюзами безопасности задействованы инфраструктура
открытого ключа (PKI), сертификаты и сертификационные центры. (В отсутствие PKI шлюзы безопасности
применяют общий секретный ключ (pre-shared secret)).
IKE и IPSec. Безопасные VPN-протоколы, используемые для управления ключами шифрования и обмена
зашифрованными пакетами. IPSec – технология шифрования, поддерживающая несколько стандартов,
обеспечивающая проверку подлинности и услугу шифрования данных в частных и общественных сетях.
IKE (Internet Key Exchange) – стандарт протокола управления ключами. IKE дополняет IPSec,
предоставляя дополнительные функции, гибкость и простоту настройки.
VPN Site-to-Site
В центре VPN находится зашифрованный туннель (или линия связи VPN), созданный с помощью протоколов
IKE/IPSec. На концах туннеля пребывают либо шлюзы безопасности Check Point, либо клиенты удаленного
доступа. Первым делом узлы одного ранга, использующие линию связи, формируют доверие между собой.
Это доверие устанавливается с помощью сертификационных центров, PKI или общих секретных ключей.
Происходит обмен методами и создание ключей. Организуется зашифрованный туннель, который
поддерживается для нескольких соединений, при необходимости обновляя ключи за счет обмена ключевыми
материалами.
VPN-сообщества
Существует два базовых типа сообществ: ячейки и звезда. Топология – это набор включенных линий связи
VPN в системе шлюзов безопасности, их VPN-доменов, хостов, расположенных позади каждого шлюза
безопасности, а также их внешних удаленных клиентов.
В ячеистом сообществе каждый шлюз безопасности связан с каждым другим шлюзом безопасности.
Шлюз безопасности
Сателлитный шлюз
Центральный шлюз
ячеистый
Связь может быть дополнена соединением шлюзов безопасности в ячеистую сеть. Такой тип топологии
подходит для развертываний, затрагивающих Экстрасети, включающие сети, принадлежащие бизнес-
партнерам.
использованием как dial-up (в том числе широковещательную связь), так и LAN (в том числе беспроводную
LAN). Управление пользователями осуществляется либо посредством внутренней базы данных шлюз
безопасности Check Point, либо через внешний сервер LDAP.
Хост 1
Интернет
Удаленный клиент
Удаленный пользователь инициирует связь со шлюзом безопасности. Во время согласования протокола IKE
происходит проверка подлинности. После подтверждения существования пользователя шлюз безопасности
проверяет его подлинность, например, проверяя сертификат пользователя. После успешного завершения IKE
создается туннель; удаленный клиент соединяется с Хостом 1.
1. В GuiDBedit на вкладке Таблицы (Tables) выберите Прочие > ssl_inspection (Other > ssl_inspection).
2. В столбце Объекты (Objects) выберите general_confs_obj.
3. В столбце Поля (Fields) измените поля:
ssl_max_ver
ssl_min_ver
Глава 2
IPSec и IKE
В этой главе
ОБЗОР ................................................................................................................................................................ 14
ЗАЩИТА IKE ОТ DOS-АТАК .............................................................................................................................. 20
НАСТРОЙКА ДОПОЛНИТЕЛЬНЫХ СВОЙСТВ IKE........................................................................................... 23
Обзор
В симметричных криптографических системах обе связывающиеся стороны для шифрования и расшифровки
применяют один и тот же ключ. Материал, используемый для построения этого ключа, необходимо уметь
передать безопасным способом. Безопасный обмен информацией происходит лишь тогда, когда ключ
принадлежит исключительно связывающимся сторонам.
Целью Обмена ключами по Интернету (IKE – Internet Key Exchange) для обеих сторон является независимое
производство одинакового симметричного ключа. В дальнейшем с помощью этого ключа шифруются и
расшифровываются обычные IP-пакеты, используемые при групповой пересылке данных между
противоположными узлами VPN. IKE выстраивает VPN-туннель, проводя аутентификацию обеих сторон и
находя соответствие относительно методов шифрования и проверки целостности. Результатом работы IKE
является Ассоциация защиты (SA – Security Association).
Данное соглашение о ключах и методах шифрования также должно выполняться безопасным образом.
Поэтому IKE состоит из двух фаз. Во время первой фазы закладывается фундамент для второй. Шлюзы
безопасности версии R71 или выше поддерживают и IKEv1, и IKEv2.
Для обмена материалом для построения симметричных ключей служит часть протокола IKE, называемая
метод Диффи-Хеллмана (DH). Алгоритм Диффи-Хеллмана позволяет построить шифровальный ключ,
известный как «общий секретный ключ» (shared secret), из частного ключа одной стороны и открытого ключа
другой. Поскольку симметричные ключи IPSec получаются из ключа DH, общего для обоих узлов,
фактического обмена симметричными ключами не происходит.
IKE, фаза I
Во время первой фазы IKE происходит следующее.
Происходит проверка подлинности узлов на основании сертификатов или через общий секретный ключ.
(Если один из узлов – клиент удаленного доступа, тогда методов аутентификации может быть больше).
Создается ключ Диффи-Хеллмана. Суть протокола Диффи-Хеллмана подразумевает независимое
формирование общего ключа на обеих сторонах, причем ключ известен только связывающимся сторонам.
Между узлами происходит обмен материалом для ключа (произвольные биты и прочие математические
данные) и соглашением о методах, применяемых на второй фазе IKE.
Генерация ключа Диффи-Хеллмана в контексте производительности протекает медленно и тяжело. В
результате фазы I IKE образуется Ассоциация защиты (SA) IKE – соглашение о ключах и методах для фазы II
IKE. На рис. 2-1 показан процесс, происходящий во время фазы I IKE, который, впрочем, не обязательно
отражает фактическую последовательность событий.
Сертификат – Сертификат
Происходит проверка подлинности узлов на основании сертификатов или общего секретного ключа
Частный ключ – Открытый ключ – Открытый ключ – Частный ключ
Из совокупности произвольных битов на каждой стороне образуется частный ключ DH
Ключ DH применяется для обмена материалом для ключа (произвольные биты и прочие математические данные)
Соглашение о методах шифрования и проверки целостности на второй фазе IKE
Симметричный ключ – Материал для ключа – Материал для ключа – Симметричный ключ
Каждая сторона независимо генерирует симметричный ключ на основании ключа DH материала для ключа, который они передали
друг другу
SA IKE
Фаза II IKE
Ключ DH фазы I – Материал для ключа – Материал для ключа – Ключ DH фазы I
Ключ DH комбинируется с материалом для ключа, образуя симметричный ключ IPSec
Ключ IPSec – Ключ IPSec
IPSec
Шлюз безопасности – VPN-туннель – Пакет IPSec – Зашифрованные данные – Шлюз безопасности
Шифрование – Расшифровка
Шифрование – Расшифровка
IKEv1 и IKEv2
IKEv2 поддерживается внутри VPN-сообществ, работающих в упрощенном режиме в версиях R71 или выше.
IKEv2 – это стандарт, по-разному внедряемый в продуктах разных производителей. Внедряя IKEv2
одинаковым способом, производители способствуют повышению совместимости и интеграции. Подробнее см.
RFC 4306 и 4301.
Настройка IKEv2 происходит в окне Свойства VPN-сообщества > Шифрование (VPN Community
Properties > Encryption). Значение по умолчанию только IKEv1.
Для удаленных пользователей настройки IKE выполняются в меню Глобальные свойства > Удаленный
доступ > Аутентификация и шифрование VPN (Global Properties > Remote Access > VPN Authentification
and Encryption).
Примечание. IKEv2 не поддерживается устройствами UTM-1 Edge и VSX-объектами ранее
R75.40VS. Если в VPN-сообщество входят устройства UTM-1 Edge или указанные VSX-объекты,
параметр Шифрование должен принимать значение Поддержка IKEv1.
CAST
DES -40CP
CAST -40
NULL
AES-GCM -128
AES-GCM - 256
SHA1 (по умолч.) MD5 (по умолч.)
Проверка целостности
MD5 SHA1
SHA -256 SHA -256
AES-XCBC AES-XCBC
SHA -384 SHA -384
Значение NULL означает отсутствие шифрования пакетов; выполняется только проверка целостности.
Группы Диффи-Хеллмана
Вычисление ключа Диффи-Хеллмана (иначе называемое «согласование экспоненциального ключа»)
основывается на математических группах Диффи-Хеллмана (DH). Эти группы DH поддерживаются шлюзом
безопасности в течение прохождения обеих фаз IKE.
Режимы фазы I
Между шлюзами безопасности существует 2 режима фазы I IKE. Эти режимы относятся только к IKEv1:
Основной режим
Агрессивный режим
Если не выбран агрессивный режим, то шлюз безопасности по умолчанию работает в основном режиме,
выполняя согласование IKE с использованием шести пакетов; в агрессивном режиме согласование IKE
выполняется тремя пакетами.
Основной режим шифруется частично, с того момента, когда общий ключ DH становится известен обоим
узлам.
Основной режим менее подвержен атакам типа "отказ в обслуживании" (DoS). В основном режиме
вычисление ключа DH осуществляется после проверки подлинности. В агрессивном режиме вычисление
ключа DH выполняется одновременно с проверкой подлинности. Еще не проверенный узел имеет
возможность принудительно инициировать вычисление процессором ключа Диффи-Хеллмана на другом
узле.
Примечание. Прибегайте к агрессивному режиму, когда шлюз безопасности Check Point должен
взаимодействовать со сторонними решениями VPN, не поддерживающими основной режим.
При работе через удаленный доступ у IKE есть дополнительные режимы:
Гибридный режим. Гибридный режим представляет собой альтернативу фазе I IKE, когда шлюзу
безопасности разрешено проводить проверку подлинности по сертификатам, а клиенту – каким-нибудь
еще способом, например, при помощи SecurID. Подробнее о гибридном режиме см. Введение в VPN с
удаленным доступом.
Офисный режим. Офисный режим – это расширение протокола IKE. Этот режим призван решать
проблемы маршрутизации между клиентами удаленного доступа и VPN-доменом. Во время работы IKE
между первой и второй фазами вставляется специальный режим, который называется режим
конфигурации. В режиме конфигурации клиент удаленного доступа запрашивает IP-адрес у шлюза
безопасности. После того, как шлюз безопасности присваивает IP-адрес, клиент создает в операционной
системе виртуальный адаптер, использующий присвоенный IP-адрес. Подробнее см. в разделе Офисный
режим (на стр. 185)
Сжатие IP
Сжатие IP – это процесс сокращения размера доли данных в пакете TCP/IP. Такое сокращение может дать
существенный прирост производительности. IPSec поддерживает алгоритм сжатия IP Flate/Deflate. Deflate –
это интеллектуальный алгоритм, подстраивающий способ сжатия данных под сами данные. Решение об
использовании сжатия IP принимается на второй фазе IKE. По умолчанию сжатие IP выключено.
Сжатие IP важно для пользователей SecuRemote/SecureClient с медленной связью. Например, для модемов
коммутируемых линий передачи сжатие IP – способ ускорения линии. Шифрование шлюза безопасности
делает пакеты TCP/IP «смешанными». Такой тип данных невозможно сжать, в результате теряется скорость
передачи. При включенном сжатии IP пакеты сжимаются перед шифрованием. Это восстанавливает
потерянную полосу пропускания линии.
Шлюз безопасности защищает сеть, состоящую из двух подсетей (10.10.10.х и 10.10.11.х, для обеих маска
подсети 255.255.255.0). Второй шлюз безопасности, удаленный узел, защищает подсети 10.10.12.х и
10.10.13.х с маской подсети 255.255.255.0.
Поскольку по умолчанию в VPN-туннель создается для полных подсетей, между шлюзами безопасности
одного ранга существуют четыре SA. Когда хост А связывается с хостом В, между подсетью хоста А и
подсетью хоста В создается SA.
Хост С Интернет
Если в настройках шлюза безопасности настроена Поддержка обмена ключами для подсетей, однако, эта
опция не поддерживается второй стороной, когда хост А связывается с хостом С, между подсетью хоста А и
IP-адресом хоста С согласовывается Ассоциация защиты (SA 1). Затем та же SA используется между любым
хостом подсети 10.10.11.х и хостом С.
Когда хост А связывается с хостом В, между подсетью хоста А и хостом В согласовывается отдельная
Ассоциация защиты (SA 2).
При выключенной опции Поддержка обмена ключами для подсетей во время коммуникации шлюзов
безопасности, Ассоциация защиты согласовывается между отдельными IP-адресами; фактически, получается
уникальная SA для каждого хоста.
DoS-атаки IKE
Протокол IKE требует, чтобы принимающий шлюз безопасности выделял память для первого полученного
запроса на фазу I IKE. Шлюз безопасности отвечает и принимает другой пакет, который затем обрабатывает,
используя информацию из первого пакета.
Злоумышленник может отослать много первых пакетов IKE, назначая каждому из них разный исходящий IP-
адрес. Принимающий шлюз безопасности обязан ответить на каждый из них и выделить для каждого из них
память. Так можно занять все ресурсы процессора, не давая установить соединение законным
пользователям.
Пакеты IKE может отсылать машина, которой разрешено выполнения согласования IKE, например, шлюз
безопасности Check Point. Это – идентифицированный источник. У злоумышленника также может быть IP-
адрес, о котором принимающий шлюз безопасности не знает, например, SecuRemote/SecureClient, или шлюз
безопасности Check Point с динамическим IP-адресом. Это – неидентифицированный источник.
ike_dos_threshold
Значения: 0-100, по умолчанию: 70. Определяет максимальный процент одновременно выполняемых
согласований, превышение которого вынудит шлюз безопасности запросить защиту от DoS-атаки. Если
пороговым значением установить 0, шлюз безопасности всегда будет запрашивать защиту от DoS-атаки.
ike_dos_puzzle_level_identified_initiator
Значения: 0-32, по умолчанию: 19. Определяет уровень головоломок, отсылаемых шлюзу безопасности
известного узла. Этот атрибут определяет также максимальный уровень головоломки, который шлюз
безопасности готов решать.
ike_dos_puzzle_level_unidentified_initiator
Значения: 0-32, по умолчанию: 19. Определяет уровень головоломок, отсылаемых неизвестным узлам (таким
как SecuRemote/SecureClient и шлюзам безопасности DAIP). Этот атрибут определяет также максимальный
уровень головоломки, который шлюзы безопасности DAIP и SecuRemote/SecureClient готов решать.
ike_dos_max_puzzle_time_gw
Значения: 0-30000, по умолчанию: 500. Определяет максимальное время в миллисекундах, которое готов
потратить шлюз безопасности на решение головоломок защиты от DoS-атаки.
ike_dos_max_puzzle_time_daip
Значения: 0-30000, по умолчанию: 500. Определяет максимальное время в миллисекундах, которое готов
потратить шлюз безопасности DAIP на решение головоломок защиты от DoS-атаки.
ike_dos_max_puzzle_time_sr
Значения: 0-30000, по умолчанию: 500. Определяет максимальное время в миллисекундах, которое готов
потратить SecuRemote на решение головоломок защиты от DoS-атаки.
ike_dos_supported_protection_sr
Значения: Нет, Без сохранения состояния, Головоломки, по умолчанию: Головоломки. При загрузке в
SecuRemote/SecureClient управляет уровнем защиты, который клиент готов поддерживать.
Шлюзы безопасности используют свойство ike_dos_protection_unidentified_initiator (эквивалентно
глобальному свойству SmartDashboard Поддержка защиты IKE on DoS-атак с неидентифицированных
источников) для принятия решения о том, какую защиту потребовать от удаленных клиентов; однако,
клиенты SecuRemote/SecureClient используют ike_dos_protection. То же самое свойство клиента на шлюзе
безопасности называется ike_dos_supported_protection_sr.
Site-to-Site number_of_ISAKMP_SAs_kept_per_peer 5
Для ограничения количества туннелей, которые может открыть пользователь на один IKE, настройте
следующие поля:
Site-to-Site number_of_ipsec_SAs_per_IKE_SA 30
Свойства клиента
Некоторые свойства шлюза безопасности изменяют свое название при загрузке в SecuRemote/SecureClient.
Измененное название указывается в файле User.C следующим образом.
Названия свойств
Название свойства на шлюзе Название свойства User.C у клиента
on DoS-атак с неидентифицированных
источников)
ike_dos_supported_protection_sr ike_dos_protection
ike_dos_puzzle_level_unidentified_initiator ike_dos_acceptable_puzzle_level
ike_dos_max_puzzle_time_sr ike_dos_max_puzzle_time
Секретность
Только взаимодействующие стороны должны иметь возможность считать ту личную информацию, обмен
которой имеет место.
Проверка подлинности
Взаимодействующие стороны должны быть уверены, что соединяются именно с тем узлом, с которым
намеревались.
Целостность
Чувствительные данные должны пройти через канал связи без изменений, что должно подтверждаться
проверкой целостности.
Хост 1 Интернет
Хост 2 Зашифрован
Хост 3 Без шифрования
VPN-сообщества
Создание VPN-туннелей между шлюзами безопасности облегчается за счет настройки VPN-сообществ. VPN-
сообщество – это набор шлюзов, включенных в VPN, способных взаимодействовать посредством VPN-
туннелей.
Чтобы лучше понять концепцию VPN-сообществ, введем некоторую терминологию.
Член VPN-сообщества. Шлюз безопасности, пребывающий на одном из концов VPN-туннеля.
VPN-домен. Хосты, находящиеся за шлюзом безопасности. VPN-доменом может оказаться целая сеть,
лежащая позади шлюза безопасности, или часть этой сети. Например, шлюз безопасности может
защищать корпоративную локальную сеть и DMZ. Есть смысл называть VPN-доменом только
корпоративную локальную сеть.
VPN-узел. Член сообщества со своим VPN-доменом. Типичным примером VPN-узла является отделение
банка.
VPN-сообщество. Набор туннелей/линий связи и прочих атрибутов VPN.
VPN на основе доменов. Маршрутизация трафика VPN основывается на домене шифрования позади
каждого шлюза безопасности сообщества. В звездообразном сообществе сателлитные шлюзы
безопасности могут взаимодействовать между собой через центральные шлюзы безопасности.
VPN-домен
VPN-узел
Члены сообщества
VPN-туннель
VPN-сообщество
Методы, используемые для шифрования и обеспечения целостности данных, определяют тип туннеля,
формируемого между шлюзами безопасности, который в свою очередь является характеристикой
конкретного VPN-сообщества.
Сервер управления защитой может управлять несколькими VPN-сообществами, т. е., VPN-сообщества могут
создаваться и организовываться по мере необходимости.
Впрочем, если VPN-туннель требуется создать со шлюзом безопасности, управляемым извне (шлюз,
управляемый другим Сервером управления защитой), то возможны два варианта.
Шлюз безопасности, управляемый извне, поддерживает сертификаты, но выданные внешним центром
сертификации – тогда каждому шлюзу безопасности придется доверять центру сертификации другого
шлюза безопасности. Подробнее см. раздел «Настройка VPN со шлюзами безопасности, управляемыми
извне, посредством PKI» (на стр. 41).
Шлюз безопасности, управляемый извне, не поддерживает сертификаты – в данном случае VPN
поддерживает использование общего секретного ключа. Подробнее см. раздел «Настройка VPN со
шлюзами безопасности, управляемыми извне, посредством общего секретного ключа» (на стр. 44).
«Секретный ключ» определяется для каждого внешнего шлюза безопасности. Если имеется пять
внутренних шлюзов безопасности и два внешне управляемых шлюза безопасности, то формируется два
общих секретных ключа. Два общих секретных ключа используются пятью шлюзами безопасности,
управляемыми изнутри. Иначе говоря, все шлюзы безопасности, управляемые изнутри, при связи с
отдельным шлюзом безопасности, управляемым извне, используют один и тот же общий секретный ключ.
Топологии VPN
Самая простая топология состоит из двух шлюзов безопасности, способных создать между собой VPN-
туннель. Сервер управления защитой, поддерживающий более сложные технологии, позволяет создание
VPN-сообществ под конкретные цели организации. Сервер управления защитой поддерживает два основных
типа топологии:
ячеистая;
звездообразная.
Ячеистое VPN-сообщество
В VPN-сообществе с ячеистой топологией VPN-узел может создать VPN-туннель с любым другим VPN-узлом
сообщества:
Шлюз безопасности
Звездообразное VPN-сообщество
VPN-сообщество с топологией типа «звезда» состоит из центральных шлюзов безопасности
(«концентраторов») и сателлитных шлюзов безопасности («лучей»). В этом типе топологии сателлитный
шлюз может образовывать туннель только с узлами, чьи шлюзы безопасности определены как центральные.
Сателлитный шлюз
Центральные шлюзы
ячеистая
Сателлитный шлюз безопасности не может образовать VPN-туннель со шлюзом безопасности, который также
определен как сателлитный.
Центральные шлюзы безопасности могут образовывать VPN-туннели с другими центральными шлюзами
безопасности только в том случае, если выбрана опция Соединять центральные шлюзы безопасности
ячеистой сетью (Mesh center Security Gateway) на странице Центральные шлюзы безопасности окна
Свойства звездообразного сообщества.
Выбор топологии
Выбор топологии для VPN-сообщества зависит от общей политики организации. К примеру, ячеистая
топология, как правило, применяется для внутренней сети, в которой могут участвовать только шлюзы
безопасности, являющиеся частью сети, управляемой изнутри; шлюзы безопасности партнеров компании к
ней не допускаются.
Топология VPN «звезда» обычно приемлема для организаций, для которых важен обмен информацией с
сетями, принадлежащими внешним партнерам. Эти партнеры должны взаимодействовать с нашей
компанией, но не между собой. Шлюз безопасности организации определяется как центральный, а
партнерские шлюзы безопасности – как сателлитные.
Более сложная ситуация: у компании есть центральные офисы в двух странах: в Великобритании (Лондон) и в
США (Нью-Йорк). У каждого центрального офиса есть ряд филиалов. Филиалы должны взаимодействовать
только с тем центральным офисом, который находится с ними в одной стране; при этом они не связываются
друг с другом. Между центральными офисами в Нью-Йорке и Лондоне должна быть налажена прямая связь.
Для реализации такой политики, определим два звездообразных сообщества – лондонское и нью-йоркское.
Лондонский и нью-йоркский шлюзы безопасности настроим как «центральные». Шлюзы безопасности во всех
филиалах будут выступать «сателлитными». Это даст возможность филиалам взаимодействовать с
центральными офисами у себя в стране. А теперь создадим третье VPN-сообщество с ячеистой топологией,
включающее лондонский и нью-йоркский шлюзы безопасности.
Лондон, ЗВЕЗДА
Нью-Йорк, ЗВЕЗДА
Кроме того, шлюзы безопасности Вашингтона и Лондона должны связываться между собой, используя более
слабый DES. Рассмотрим решение:
Вашингтон, ячеистая
В данном решении шлюзы безопасности ячеистой сети Вашингтона также определены как сателлиты
Лондонской звездообразной сети. В Лондонской звезде центральные шлюзы безопасности связаны ячеистой
сетью. Шлюзы безопасности Вашингтона образуют VPN-туннели с шлюзами безопасности Лондона,
используя DES. При внутреннем взаимодействии шлюзы безопасности Вашингтона строят VPN-туннели,
используя 3DES.
Нью-Йорк Париж
Два шлюза безопасности, способных создать между собой линию связи VPN в одном сообществе, могут
войти в другое VPN-сообщество при условии, что во втором VPN-сообществе они неспособны создать между
собой линию связи. Например:
Шлюзы безопасности Лондона и Нью-Йорка входят в ячеистую сеть Лондон – Нью-Йорк. Эти два шлюза
безопасности, кроме того, входят в качестве сателлитных в VPN-сообщество со звездообразной топологией с
центром в Париже. Исходя из топологии, сателлитные шлюзы безопасности (в Лондоне и в Нью-Йорке) могут
взаимодействовать только с центральным шлюзом безопасности Парижа. Поскольку шлюзы безопасности
Лондона и Нью-Йорка не могут открыть между собой линию связи VPN, такая конфигурация возможна.
Конфигурация шлюзов безопасности в VPN-сообщество означает, что если политика контроля доступа
разрешает этим шлюзам безопасности взаимодействовать, то связь будет зашифрована. Контроль доступа
настраивается в базе правил политики безопасности.
Работая со столбцом VPN базы правил политики безопасности, можно создать правила доступа,
относящиеся только к членам VPN-сообщества. Например:
Связь возможна лишь при выполнении всех условий правила: это должно быть HTTP-соединение между IP-
адресами источника и адресата в рамках VPN-сообщества. При невыполнении любого их этих условий
правило будет работать как запрет. Если выполняются все условия, тогда правило разрешает установление
связи.
Правило из базы правил политики безопасности может подходить для обоих VPN-сообществ и хост-машин,
не принадлежащих сообществу. Например:
Правило в базе правил политики безопасности допускает HTTP-соединение между любым внутренним IP и
любым другим IP:
Под это правило подходит HTTP-соединение между хостом 1 и внутренним веб-сервером позади шлюза
безопасности 2. Соединение между хостом 1 и веб-сервером в Интернете также не противоречит данному
правилу; а соединение между хостом 1 и внутренним веб-сервером – это соединение между членами VPN-
сообщества, проходящее в зашифрованном виде; соединение между хостом 1 и веб-сервером в Интернете
проходит в открытом виде.
В обоих случаях соединение просто удовлетворяет правилу политики безопасности; зашифровано
соединение или нет – оно рассматривается на уровне VPN. VPN – это другой уровень защиты, отдельный
от уровня контроля доступа.
Исключенные службы
В окне Свойства VPN-сообществ (VPN Communities Properties) на странице Исключенные службы
(Excluded
Services) можно выбрать службы, которые не следует шифровать, например, контрольные соединения
брандмауэра. Нешифрованная служба предусматривает отсутствие формирования VPN-туннеля для этого
соединения. Подробнее о контрольных соединениях см. «Как авторизовать управляющие соединения
брандмауэра в VPN-сообществах» (на стр. 45). Обратите внимание, что исключенные службы не
поддерживаются при использовании VPN на основе маршрутов.
это действие, весь трафик между шлюзами безопасности шифруется. Шлюзы безопасности Check Point
настраиваются легче посредством использования VPN-сообществ – это и есть упрощенный режим.
Подробнее о традиционном режиме см. раздел «VPN традиционного режима» (на стр. 144).
Инструкции по настройке требуют понимания того, как строится VPN. Подробнее об этом см. в разделе
«Введение в VPN Site-to-Site» (на стр. 28).
Кроме того, вам понадобится понимание конфигурации PKI. См. «Инфраструктура открытого ключа» (на стр.
48).
Шлюз безопасности В1
(Внешний, сателлитный)
Шлюз безопасности А1
(Внутренний, центральный)
Шлюз безопасности А2
(Внутренний, центральный)
Шлюз безопасности В2
(Внешний, сателлитный)
Соединены в ячеистую сеть
Инструкции по настройке требуют понимания того, как строится VPN. Подробнее об этом см. в разделе
«Введение в VPN Site-to-Site» (на стр. 28).
Администратор хочет настроить VPN между шлюзами безопасности А и В, настроив SmartDashboard. Для
этого администратору необходимо установить политику с Сервера управления защитой на шлюзы
безопасности.
1. Сервер управления защитой успешно устанавливает политику на шлюз безопасности А. Поскольку мы
задействовали шлюз А, шлюзы безопасности А и В теперь принадлежат одному и тому же VPN-
сообществу. Впрочем, на В еще не установлена политика.
2. Сервер управления защитой пытается открыть связь с шлюзом безопасности В, чтобы установить
политику.
3. Шлюз безопасности А допускает соединение, поскольку оно удовлетворяет явно заданным правилам
для управляющих соединений, и начинает согласование IKE с шлюзом безопасности В, чтобы
сформировать VPN-туннель для управляющего соединения.
4. Шлюз безопасности В не знает, как взаимодействовать с А – у него ведь до сих пор нет политики. Таким
образом, установка политики на шлюз безопасности В не получается.
В качестве решения проблемы можно сделать так, чтобы управляющие соединения не проходили сквозь
VPN-туннель.
Сертификат Сертификат
Сертификат Шлюз безопасности В
Шлюз безопасности
Сервер управления защитой А выдает сертификаты Серверу управления защитой В, который в свою очередь
предоставляет сертификаты шлюзу безопасности В.
Сертификат Интернет
Сертификат HTTP-сервер
Шлюзы безопасности А и А получают сертификаты от предоставителя услуги PKI, который доступен через
Интернет. Сертификаты, выданные сторонними СА, могут использоваться шлюзами безопасности,
управляемыми одним и тем же Сервером управления защитой, в целях проверки.
СА в локальной сети
Если сертификат противоположного шлюза безопасности выдан сторонним СА по локальной сети, CRL
обычно загружается с внутреннего сервера LDAP, как показано на иллюстрации.
Доверие внешнему СА
Доверительное отношение – необходимое условие создания VPN-туннеля. Однако, доверительные
отношения возможны лишь если СА, подписывающему сертификат противоположного узла, «доверяют».
Доверие СА означает получение и проверку собственного сертификата СА. После проверки сертификата СА,
указанные в нем подробности и его открытый ключ можно использовать для получения и проверки других
сертификатов, выданных этим СА.
Внутреннему СА (ICA) автоматически доверяют все модули, управляемые Сервером управления защитой,
которому СА принадлежит. Внешние СА (даже ICA внешнего Сервера управления защитой Check Point)
автоматическим доверием не пользуются, поэтому модуль вначале должен получить и подтвердить
сертификат внешнего СА. Внешний СА должен обеспечить способ импортирования своего сертификата на
сервер управления защитой.
Внешний СА может быть:
1. ICA внешнего Сервера управления защитой, подробнее см. «Руководство администратора Сервера
управления защитой R75.40VS» (http://supportcontent.checkpoint.com/solutions?id=sk76540);
2. СА, сертифицированным OPSEC; определите СА с помощью опций СА на вкладке Серверы и
приложения OPSEC и получите его сертификат.
Процесс регистрации начинается с генерации пары ключей. Впоследствии запрос на сертификат реализуется
из открытого ключа и дополнительной информации о модуле. Тип запроса на сертификацию и остальной
процесс регистрации зависит от типа СА.
Проще всего, когда речь идет о шлюзе безопасности, управляемом изнутри. В этом случае на машине, на
которой установлен Сервер управления защитой, располагается ICA. Процесс регистрации завершается
автоматически.
Чтобы получить сертификат от СА, сертифицированного OPSEC, Сервер управления защитой считывает
информацию о модуле, открытый ключ и зашифровывает запрос PRCS#10. Этот запрос (который может
включать SubjectAltName для сертификатов OPSEC и расширения для Расширенного использования ключей)
передается СА вручную администратором. После того, как СА выдает сертификат, администратор может
завершить процесс, импортировав сертификат на Сервер управления защитой.
Сертификат шлюза безопасности также можно получить с помощью Автоматической регистрации. В случае
Автоматической регистрации есть возможность автоматической посылки запроса на сертификат для шлюза
безопасности сообщества со стороны доверенного СА. Автоматическая регистрация поддерживает
следующие протоколы:
SCEP
CMPV1
CMPV2
Примечание. Во время регистрации SCEP некоторые HTTP-запросы могут превышать 2К и быть
не пропущены механизмом проверки протокола HTTP, если последний включен (Web
Intelligence > Проверка протокола HTTP > Размеры форматов HTTP). Для получения
возможности передачи HTTP-запросов понадобится изменение значения по умолчанию. Если
регистрация не удается, выполните ее вручную. Подробнее см. «Руководство администратора
IPS R75.40VS» (http://supportcontent.checkpoint.com/solutions?id=sk76540);
Проверка сертификата
После получения объектом сертификата от другого объекта, необходимо выполнить следующее.
1. Проверить подпись сертификата, т. е., убедиться, что сертификат подписан доверенным СА. Если
сертификат подписан не непосредственно доверенным СА, а его подчиненным, то проверить следует
всю цепочку сертификатов вплоть до доверенного СА.
2. Проверить, не истек ли срок давности цепочки сертификатов.
3. Проверить, не отозваны ли сертификаты из цепочки. Чтобы убедиться, что серийный номер
проверенного сертификата не включен в число отозванных, загружается CRL.
Вдобавок, VPN проверяет возможность использования сертификата в данной ситуации, подтверждая, что:
Сертификат позволяет выполнять требуемое действие. Например, если для подписи данных необходим
частный ключ (напр., для аутентификации), для разрешения такого действия на сертификате
проверяется расширение KeyUsage – если таковое присутствует.
При согласовании противоположный узел использовал корректный сертификат. При создании VPN-
туннеля с модулем, управляемым извне, администратор может решить принимать только сертификаты,
подписанные конкретным СА из числа доверенных. (Также возможен прием сертификатов только с
конкретными деталями, напр. с различаемым именем).
Проверка отзыва
Для определения статуса сертификата существует два доступных метода:
1. CRL
2. Протокол статуса онлайн-сертификатов (OCSP)
CRL
VPN может загрузить CRL либо с HTTP-сервера, либо с сервера LDAP. Если CRL-хранилищем является
HTTP-сервер, модуль пользуется URL, опубликованным в CRL-расширении сертификата Точка
распределения (Distribution point) и для загрузки CRL открывает HTTP-соединение с хранилищем CRL.
Если CRL-хранилищем выступает сервер LDAP, VPN делает попытку отыскать CRL в одном из определенных
блоков учетной записи LDAP. В такой ситуации должен быть определен блок учетной записи LDAP. Если
существует CRL-расширение Точка распределения, оно публикует DN CRL, т. е., запись в директории, под
которой опубликован CRL или URI LDAP. Если это расширение не существует, тогда VPN делает попытку
отыскать CRL в самой записи СА на сервере LDAP.
OCSP
Протокол статуса онлайн-сертификатов OCSP предоставляет возможность приложениям получать
информацию о состоянии сертификата. OCSP может использоваться для получения более своевременной
информации об отзыве сертификатов, чем это возможно, используя CRL. Информацию OCSP можно
использовать для получения дополнительных сведений о состоянии сертификата. Когда клиент OCSP
передает запрос о статусе на сервер OCSP, прием сертификата задерживается до того момента, пока сервер
не предоставит ответ.
Чтобы использовать OCSP, корневой СА должен быть настроен на этот метод, а не на CRL/ Эта настройка
наследуется подчиненными СА.
Особенности PKI
СА Certificate Rollover
СА Certificate Rollover – это функция VPN-1, позволяющая продлевать сертификаты СА, которыми
подписывается клиент, и сертификаты шлюзов безопасности для VPN-трафика, не рискуя потерять
работоспособность при переходе.
Для достижения постепенного продления сертификата СА Certificate Rollover предоставляет VPN-1
возможность поддерживать несколько сертификатов СА, сгенерированных сторонними OPSEC-
совместимыми СА, например Microsoft Windows CA. Используя несколько сертификатов СА, можно
постепенно выполнять продление клиентских сертификатов и сертификатов шлюзов безопасности в течение
переходного периода, когда происходит распознавание сертификатов клиента и шлюза безопасности,
подписанных обоими СА.
Когда к СА, имеющему сертификат, добавляется еще один сертификат, он определяется как Дополнительный
и получает номер, на один больший, чем наивысший существующий номер сертификата. Первоначальный
сертификат определяется Основным.
Удалять можно только дополнительные сертификаты. СА Certificate Rollover предоставляет инструментарий
для добавления и удаления сертификатов, изменения статуса сертификатов (основной <> дополнительный).
СА Certificate Rollover служит для продления сертификатов СА с разными ключами. Для добавления
сертификата с использованием того же самого ключа, как у существующего сертификата СА (например,
чтобы продлить срок годности), загрузите сертификат со вкладки OPSEC PKI свойства СА и не пользуйтесь
СФ Certificate Rollover.
6. Теперь новый сертификат СА должен быть определен как дополнительный №1. Убедитесь в этом при
помощи «vpn mcc lca» или «vpn mcc show» («Командная строка СА Certificate Rollover» на стр. 59).
7. Запустите процессы Check Point:
cpstart
8. Установите политику на все шлюзы безопасности.
Для подписания клиентских сертификатов используйте новый дополнительный сертификат СА.
Пока большинство клиентов используют сертификаты, подписанные старым сертификатом СА, из
соображений производительности, новый сертификат СА следует оставить дополнительным, а старый –
основным. Пока новый сертификат СА не станет основным, не используйте его для подписания сертификатов
шлюзов безопасности.
Настройка OCSP
Для использования OCSP объект СА должен быть настроен на метод проверки отзывов OCSP, а не CRL.
C помощью GuiDBedit измените поле oscp_validation на true. После такой установки этот СА будет
проверять актуальность сертификата при помощи OCSP. Конфигурация распространяется на корневой СА и
наследуется подчиненными СА.
Настройка доверенного сервера OCSP с использованием GuiDBedit для objectc.c.
1. Создайте новый серверный объект типа oscp_server.
2. Настройте для серверов OCSP URL и сертификат.
3. В объекте СА настройте oscp_server. Добавьте ссылку на созданный серверный объект OCSP и
установите политику.
Шлюз безопасности А
Шлюз безопасности С
Интернет
Шлюз безопасности В
Луч А
Концентратор
Луч В
Сеанс Telnet
Сеанс FTP
Хотя это легко выполняется путем настройки звездообразного VPN-сообщества, того же результата можно
достичь, редактируя vpn_route.conf.
Интернет
Сервер управления защитой А Луч А1
Концентратор А Концентратор В
Луч В Сервер управления защитой В
Луч А2
Лучи А1 и А2 объединены в сетевую группу «A_spokes». Соответствующее правило в базе правил политики
безопасности выглядит так:
Источник Адресат VPN Служба Действие
В_Community
Hubs_Community
А_Community
Hubs_Community
Луч А1
Луч А2
Концентратор А
Сообщество А
Сообщество концентраторов
Концентратор В
Луч В
Сообщество В
Использование SmartDashboard
В SmartDashboard создайте сетевые объекты, представляющие члены VPN-сообщества и их сети.
Необходимо создать сообщество со звездообразной топологией, а для параметра Маршрутизация VPN
выбрать параметр К центру и к прочим сателлитам через центр.
3. Если свыше одного шлюза SmartLSM из одного профиля LSM будут взаимодействовать друг с другом
через центральный шлюз, измените файл так:
Кластер GWA
В данной ситуации:
Есть VTI, объединяющий кластер GWA и GWb
Есть VTI, объединяющий кластер GWA и GWс
Есть VTI, объединяющий GWс и GWb
Виртуальный интерфейс ведет себя как интерфейс «точка-точка», напрямую подключенный к удаленному
узлу. Трафик между сетевыми хостами направляется в VPN-туннель при помощи механизма IP-
маршрутизации операционной системы. Для определения доступных туннелей все также требуются
шлюзовые объекты, VPN-сообщества (с политиками контроля доступа). Однако домены шифрования VPN
для каждого шлюза безопасности одного уровня больше не нужны. Шифровать пакет или нет – это зависит от
того, направляется ли трафик через виртуальный интерфейс. Маршрутизация динамически меняется, если в
сети доступен протокол динамической маршрутизации (OSPF/BGP).
Когда соединение, начавшееся на GWb, направляется через VTI на GWc (или серверы позади GWc),
удовлетворяя неявным правилам, то уже от GWb связь осуществляется в нешифрованном виде с локальным
IP-адресом VTI в качестве исходящего IP-адреса. Если маршрутизация к этому IP-адресу невозможна,
обратные пакеты будут утрачены.
Решение состоит в следующем:
настроить статический маршрут на GWb, предохраняющий пакеты, предназначенные GWc, от
направления через VTI;
не включать его ни в какой публикуемый маршрут;
добавить карты маршрутизации, отфильтровывающие IP-адреса GWc.
нумерованный;
ненумерованный.
Нумерованный VTI
Для каждого нумерованного туннельного интерфейса VPN (VTI) задается локальный или удаленный IP-адрес.
Для каждого шлюза безопасности задается локальный IP-адрес, удаленный адрес и исходящий IP-адрес для
исходящих соединений через туннель. Удаленный IP-адрес должен быть локальным IP-адресом на
удаленном шлюзе безопасности. Одним IP-адресом могут пользоваться несколько VTI, однако, они не могут
использовать IP-адрес существующего физического интерфейса.
Нумерованные интерфейсы поддерживаются операционными системами SecurePlatform и Gaia.
Ненумерованный VTI
В случае ненумерованных VTI для каждого шлюза безопасности определяется прокси-интерфейс. Каждый
шлюз безопасности использует IP-адрес прокси-интерфейса в качестве исходящего при исходящем трафике.
Ненумерованные интерфейсы позволяют присвоить один IP-адрес каждому интерфейсу и управлять им. В
качестве прокси-интерфейса может выступать физический или кольцевой интерфейс.
Ненумерованные интерфейсы поддерживаются платформами Gaia и IPSO (3.9 и выше).
Нумерованные VTI
С помощью нового интерфейса командной строки VPN (VPN Shell) администратор создает туннельный
интерфейс VPN на принудительный модуль для каждого шлюза безопасности и «ассоциирует» интерфейс с
противоположным шлюзом безопасности. Туннельный интерфейс VPN может быть нумерованным или
ненумерованным. Подробнее о VPN Shell см. «VPN Shell» (на стр. 316).
Каждому нумерованному VTI присваивается локальный IP-адрес и удаленный IP-адрес. Перед настройкой
необходимо определить диапазон IP-адресов, присваиваемых VTI.
Кластер GWA
VTI соединяет:
ClusterXL:
Кластер GWA
member_GWA1
member_GWA2
Модули VPN:
GWb
GWc
IP-конфигурации:
Кластер GWA
member_GWA1
Внешний уникальный IP eth0: 170.170.1.1/24
Внешний VIP eth0: 170.170.1.10/24
Интерфейс синхронизации eth1: 5.5.5.1/24
IP VTI vt-GWb: Локальный: 10.0.1.11, Удаленный: 10.0.0.2
VIP VTI vt-GWb: 10.0.1.10
IP VTI vt-GWс: Локальный: 10.0.1.21, Удаленный: 10.0.0.3
VIP VTI vt-GWс: 10.0.1.20
member_GWA2
Внешний уникальный IP eth0: 170.170.1.2/24
Внешний VIP eth0: 170.170.1.10/24
Интерфейс синхронизации eth1: 5.5.5.1/24
IP VTI vt-GWb: Локальный: 10.0.1.12, Удаленный: 10.0.0.2
VIP VTI vt-GWb: 10.0.1.10
IP VTI vt-GWс: Локальный: 10.0.1.22, Удаленный: 10.0.0.3
VIP VTI vt-GWс: 10.0.1.20
GWb
Внешний уникальный IP eth0: 180.180.1.1/24
IP VTI vt-ClusterGWa: Локальный: 10.0.0.2, Удаленный: 10.0.1.10
IP VTI vt-GWс: Локальный: 10.0.0.2, Удаленный: 10.0.0.3
GWc
Внешний уникальный IP eth0: 190.190.1.1/24
IP VTI vt-ClusterGWa: Локальный: 10.0.0.3, Удаленный: 10.0.1.20
IP VTI vt-GWb: Локальный: 10.0.0.3, Удаленный: 10.0.0.2
Настройка member_GWA2
--------- Доступ к командной строке VPN shell
[member_GWa2]# vpn shell
? - This help
.. - Go up one level
quit - Quit .
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWb
VPN shell:[/] > /interface/add/numbered 10.0.1.12 10.0.0.2
GWb
Interface 'vt-GWb' was added successfully to the system
--------- Добавление vt-GWc
VPN shell:[/] > /interface/add/numbered 10.0.1.22 10.0.0.3
GWc
Interface 'vt-GWc' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWb Type:numbered MTU:1500
inet addr:10.0.1.12 P-t-P:10.0.0.2
Mask:255.255.255.255
Peer:GWb Peer ID:180.180.1.1 Status:attached
vt-GWc Type:numbered MTU:1500
inet addr:10.0.1.22 P-t-P:10.0.0.3
Mask:255.255.255.255
Peer:GWc Peer ID:190.190.1.1 Status:attached
VPN shell:[/] > /quit
[member_GWa2]# ifconfig vt-GWb
vt-GWb Link encap:IPIP Tunnel HWaddr
inet addr:10.0.1.12 P-t-P:10.0.0.2
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
[member_GWa2]# ifconfig vt-GWc
vt-GWc Link encap:IPIP Tunnel HWaddr
inet addr:10.0.1.22 P-t-P:10.0.0.3
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
При настройке VTI в кластерной среде, если не задано имя интерфейса, оно предоставляется. По
умолчанию, имя для VTI «vt-[имя противоположного шлюза безопасности]». Например, если имя
противоположного шлюза безопасности Server_2, то по умолчанию имя VTI будет vt-Server_2. Для шлюзов
безопасности, имя которых по длине превышает 12 знаков, интерфейсным именем по умолчанию будут
последние 5 знаков плюс 7-байтный хэш, полученный из имени, – так интерфейсное имя будет уникальным.
После настройки VTI на членах кластера необходимо в SmartConsole настроить VIP этих VTI.
В SmartDashboard:
1. Выберите Управление > Сетевые объекты.
2. Выберите кластер Check Point и нажмите правой кнопкой Изменить.
3. В окне Топология нажмите Изменить топологию.
4. Нажмите Загрузить топологию всех членов.
VTI показаны на топологии.
Обратите внимание, что в окне Изменить топологию перечислены на одной строке члены VTI при
совпадении следующих критериев:
имя удаленного узла;
IP-адрес удаленного узла;
интерфейсное имя.
5. Настройте VIP VTI на вкладке Топология.
6. Щелкните OK и загрузите политику.
Настройка GWb
--------- Доступ к командной строке VPN shell
[GWb]# vpn shell
? - This help
.. - Go up one level
quit - Quit
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWa
VPN shell:[/] > /interface/add/numbered 10.0.0.2 10.0.1.10
GWa
Interface 'vt-GWa' was added successfully to the system
--------- Добавление vt-GWc
VPN shell:[/] > /interface/add/numbered 10.0.0.2 10.0.0.3
GWc
Interface 'vt-GWc' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWa Type:numbered MTU:1500
inet addr:10.0.0.2 P-t-P:10.0.1.10
Mask:255.255.255.255
Peer:GWa Peer ID:170.170.1.10 Status:attached
vt-GWc Type:numbered MTU:1500
inet addr:10.0.0.2 P-t-P:10.0.0.3
Mask:255.255.255.255
Peer:GWc Peer ID:190.190.1.1 Status:attached
VPN shell:[/] > /quit
[GWb]# ifconfig vt-GWa
vt-GWa Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.2 P-t-P:10.0.1.10
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
Настройка GWс
--------- Доступ к командной строке VPN shell
[GWc]# vpn shell
? - This help
.. - Go up one level
quit - Quit
[interface ] - Manipulate tunnel interfaces
[show ] - Show internal data
[tunnels ] - Manipulate tunnel data
--------- Добавление vt-GWa
VPN shell:[/] > /interface/add/numbered 10.0.0.3 10.0.1.20
GWa
Interface 'vt-GWa' was added successfully to the system
--------- Добавление vt-GWb
VPN shell:[/] > /interface/add/numbered 10.0.0.3 10.0.0.2
GWb
Interface 'vt-GWb' was added successfully to the system
---------- Проверка конфигурации
VPN shell:[/] > /show/interface/detailed all
vt-GWa Type:numbered MTU:1500
inet addr:10.0.0.3 P-t-P:10.0.1.20
Mask:255.255.255.255
Peer:GWa Peer ID:170.170.1.10 Status:attached
vt-GWb Type:numbered MTU:1500
inet addr:10.0.0.3 P-t-P:10.0.0.2
Mask:255.255.255.255
Peer:GWb Peer ID:180.180.1.1 Status:attached
VPN shell:[/] > /quit
[GWc]# ifconfig vt-GWa
vt-GWa Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.3 P-t-P:10.0.1.20
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:1 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)
[GWc]# ifconfig vt-GWb
vt-GWb Link encap:IPIP Tunnel HWaddr
inet addr:10.0.0.3 P-t-P:10.0.0.2
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
Кластер GWA
Подробнее о командах маршрутизации и их синтаксисе см. книгу «Пакет расширенной маршрутизации Check
Point – Интерфейс командной строки».
Подробнее о включении протоколов динамической маршрутизации на VTI в среде Gaia см. раздел
«Туннельные интерфейсы VPN» в «Руководстве администратора Gaia» R75.40VS
(http://supportcontent.checkpoint.com/solutions?id=sk76540).
При пиринге с устройством, на котором активирован Cisco GRE, необходимо формирование GRE-туннеля
«точка-точка». Для конфигурации определения туннельного интерфейса воспользуйтесь следующей
командой:
1. Выполните вход.
2. Нажмите Конфиг.
3. На странице Конфигурация щелкните Check Point Firewall-1
4. На следующей странице нажмите Настройка FWVPN.
5. На странице Настройка туннеля FWVPN в поле Имя противоположного шлюза безопасности введите
имя шлюза безопасности, с которым желаете соединиться.
6. Нажмите Применить.
7. Теперь новый интерфейс числится на странице Конфигурация туннеля FWVPN.
На рисунке:
Чтобы активировать групповую рассылку на шлюзе безопасности, служащем точкой встречи, добавьте
правило в политику безопасности этого шлюза безопасности, чтобы в нешифрованном виде через него
проходили только конкретные пакеты многоадресной службы, а все остальные службы принимались только
через сообщество. Соответствующие правила доступа, открывающие возможности для многоадресных
протоколов и служб, необходимо создать на всех участвующих шлюзах безопасности, Например:
Состояние всех VPN-туннелей можно проследить в SmartView Monitor. Подробнее о слежении см. раздел
«Мониторинг туннелей» в «Руководстве администратора SmartView» R75.40VS
(http://supportcontent.checkpoint.com/solutions?id=sk76540).
Постоянные туннели
По мере роста зависимости компаний, связывающихся с другими узлами, от VPN, все критичнее становится
обеспечение непрерывного соединения. Необходимо быть уверенным в том, что VPN-туннели включены и
функционируют. Постоянные туннели активны все время – а значит, в них проще распознать неполадки и
проблемы со связью. Администраторы имеют возможность двустороннего мониторинга VPN-туннеля и
незамедлительного обнаружения проблем.
Каждый VPN-туннель сообщества может быть назначен постоянным. Поскольку постоянные туннели
постоянно отслеживаются, то при выходе VPN-туннеля из строя можно сделать запись в журнале, вывести
сигнальное сообщение или выполнить другое действие, заданное пользователем. Отслеживание VPN-
туннеля выполняется путем периодической отправки пакетов «тестирования туннеля». Пока приходят
ответные пакеты, VPN-туннель считается «действующим». Если в течение заданного периода времени
ответный пакет не поступает, VPN-туннель признается «недействующим». Постоянные туннели
устанавливаются только между шлюзами безопасности Check Point. Конфигурация постоянных туннелей
выполняется на уровне сообщества.
Она может быть задана для всего сообщества. Тогда все VPN-туннели сообщества станут постоянными.
Она может быть задана для конкретного шлюза безопасности. Эта опция используется для настройки
конкретных шлюзов безопасности на постоянные туннели.
Она может быть задана для одного VPN-туннеля. Так можно назначить постоянными конкретные VPN-
туннели между конкретными шлюзами безопасности.
VPN Site-to-Site
Connect (подключить)
Connected (подключен)
Для туннельного теста нужно два шлюза безопасности: один должен быть настроен в роли пингера, другой –
в роли ответчика. Шлюз безопасности пингера использует демон VPN для отсылки зашифрованных пакетов
тестирования туннеля шлюзам безопасности, которые настроены на прием сигнала от него. Шлюз
безопасности ответчика настроен на прием специальных пакетов тестирования туннеля по порту 18234.
Пингер отсылает сигнал типа 1 или 3. Ответчик отвечает пакетом той же длины, типа 2 или 4 соответственно.
На этапе соединения туннельный тест применяется двояко.
1. Шлюзу безопасности отправляется сообщение «connect». Если в ответ приходит сообщение «connected»,
значит связь в порядке. Если ответного сообщения нет, то сообщения «connect» после согласования IKE
посылаются повторно в течение 10 секунд.
2. Отсылается серия сообщений «test» разной длины, таким образом, определяется максимальный блок
передачи (PMTU) линии связи. Процесс занимает до 10 секунд. Этот тест выполняется для того, чтобы
убедиться, что слишком длинные TCP-пакеты не отправляются. Слишком длинные TCP-пакеты
фрагментируются и сокращают скорость передачи.
Шлюзы безопасности версии R54 и выше могут выступать как пингерами, так и ответчиками. В среде МЕР
центральные шлюзы безопасности могут служить только ответчиками.
Шлюзы безопасности с внедренной NG 5.0 и выше могут быть как пингерами, так и ответчиками. Более
старые версии этого ПО могут выступать только в роли ответчиков.
Сторонние шлюзы безопасности не могут быть ни пингерами, ни ответчиками.
Разделение VPN-туннелей
Разные производители, используя множество разных методов, внедряют туннели IPSec. В этой ситуации
администраторам приходится разбираться с различными средствами внедрения IPSec-среды.
Разделение VPN-туннелей улучшает взаимодействие и вносит масштабируемость, контролируя количество
VPN-туннелей, создаваемых между шлюзами безопасности. Существует три доступные конфигурации:
один VPN-туннель на каждую пару хостов;
один VPN-туннель на пару подсети;
один VPN-туннель на пару шлюзов безопасности.
Постоянные туннели
В окне Свойства сообщества на странице Управление туннелями выберите Задать постоянные туннели;
для вас откроются следующие три режима постоянных туннелей:
1. Все туннели сообщества
2. Все туннели конкретных шлюзов безопасности
3. Конкретные туннели сообщества
Для того, чтобы все туннели стали постоянными, выберите Все туннели сообщества. Чтобы закрыть все
постоянные туннели в сообществе, снимите этот флажок.
Опции слежения
Чтобы администратор всегда знал о состоянии VPN-туннелей, можно настроить несколько видов
сигнализации. Опции слежения меняются на странице Управление туннелями экрана Свойства
сообщества для всех VPN-туннелей или отдельно для каждого при настройке самих постоянных туннелей.
Опции здесь таковы: Журнал (Log), Всплывающее окно (Popup Alert), Почтовое сообщение (Mail Alert),
SNMP-ловушка (SNMP Trap Alert) и Пользовательская сигнализация. Выбрав один из типов сигнализации,
вы сможете немедленно идентифицировать проблему и эффективно на нее среагировать.
Разделение VPN-туннелей
В VPN-сообществе настройка осуществляется на странице Управление туннелями окна Свойства
сообщества.
Для настройки конкретного шлюза безопасности необходимо перейти на страницу VPN Дополнительно окна
свойства шлюза безопасности.
Разделение VPN-туннелей улучшает взаимодействие и повышает масштабируемость сети за счет контроля
количества VPN-туннелей, создаваемых между шлюзами безопасности одного уровня. Конфигурация
разделения VPN-туннелей может проводиться как для VPN-сообщества, так и для шлюза безопасности.
Один VPN-туннель на каждую пару хостов – VPN-туннель создается для каждого сеанса связи между
каждой парой хостов.
Один VPN-туннель на пару подсети – VPN-туннель, открытый между двумя подсетями, используется и
при дальнейших сеансах связи между этими подсетями. Это значение по умолчанию, совпадающее с
промышленным стандартом IPSec.
Один VPN-туннель на пару шлюзов безопасности – между парой шлюзов безопасности создается
VPN-туннель, который впоследствии попадает в общее пользование всех хостов, находящихся за
каждым из шлюзов безопасности.
В случае конфликта между свойствами туннеля VPN-сообщества и шлюза безопасности, являющегося
челном этого VPN-сообщества, выполняется более «жесткая» настройка. Например, если шлюз безопасности
настроен на Один VPN-туннель на каждую пару хостов, а сообщество – на Один VPN-туннель на пару
подсети, то выполняться будет Один VPN-туннель на каждую пару хостов.
Автоматический RIM
Автоматический RIM включается через графический интерфейс, если на шлюзе безопасности в качестве
операционной системы выступает SecurePlatform, IPSO или Linux. В этих системах возможно и выполнение
пользовательского сценария, впрочем, в этом нет необходимости.
В данной ситуации:
Выделенная линия
Пользовательские сценарии
Пользовательские сценарии можно запустить на любом шлюзе безопасности сообщества. Эти сценарии
выполняются тогда, когда туннель изменяет свое состояние, т. е. из «активного» становится «неактивным»
или наоборот. Такое событие может, например, стать причиной включения соединения dial-up.
Шаблон сценария custom_rim (с расширением .sh или .bat, в зависимости от операционной системы)
содержится в папке $FWDIR/Scripts. Это базовый сценарий (только для SecurePlatform, IPSO или Linux).
Пример сценария, написанного для SecurePlatform, IPSO, Linux
#!/bin/sh
# This script is invoked each time a tunnel is configured
with the RIM option
# and the tunnel changed state.
#
# You may add your custom commands to be invoked here.
# Parameters read from command line.
RIM_PEER_Security Gateway=$1
RIM_NEW_STATE=$2
RIM_HA_STATE=$3
Хост 2 Маршрутизатор 1
Настройка RIM
Настройка RIM в звездообразном сообществе
1. Откройте страницу Свойства звездообразного сообщества > Управление туннелями.
2. В разделе Постоянные туннели выберите Задать постоянные туннели. Для вас откроются следующие
три режима постоянных туннелей:
Все туннели сообщества
Все туннели конкретных шлюзов безопасности
Конкретные туннели сообщества
Подробнее об этих опциях см. «Постоянные туннели» (на стр. 88).
При выборе туннелей имейте в виду, что RIM включается лишь на тех туннелях, которые заданы как
постоянные. Если в сообществе действует МЕР, следует выбирать пункт Все туннели сообщества. Для
настройки постоянных туннелей см. «Настройка функций туннелей» (на стр. 87).
1. Выберите Включить механизм ввода трафика (RIM).
2. Нажмите Настройки…
Опции слежения
Чтобы администратор мог оперативно реагировать на изменения состояния шлюзов безопасности,
существует несколько типов сигналов. Опции слежения настраиваются на странице Свойства механизма
ввода трафика. Опции на выбор: Журнал (Log), Всплывающее окно (Popup Alert), Почтовое сообщение
(Mail Alert), SNMP-ловушка (SNMP Trap Alert) и Пользовательская сигнализация.
Глава 9
Проводной режим
В этой главе
ОБЗОР ПРОВОДНОГО РЕЖИМА ...................................................................................................................... 89
СИТУАЦИИ С ПРОВОДНЫМ РЕЖИМОМ .......................................................................................................... 89
ОСОБЕННОСТИ ПРОВОДНОГО РЕЖИМА ....................................................................................................... 92
НАСТРОЙКА ПРОВОДНОГО РЕЖИМА ............................................................................................................. 92
Хост 2 Хост 1
И шлюз безопасности М1, и шлюз безопасности М2 работают в проводном режиме и имеют доверенные
внутренние интерфейсы.
Сообщество, содержащее шлюзы безопасности М1 и М2, работает в проводном режиме.
Хост 1, расположенный за шлюзом безопасности S1, соединяется через VPN-туннель с хостом 2,
расположенным за шлюзом безопасности М1.
МЕР настроен для шлюзов безопасности М1 и М2, при этом шлюз безопасности М1 является первичным
шлюзом безопасности, а шлюз безопасности М2 – резервным. Подробнее о МЕР см. «VPN с
множественными точками входа» (на стр. 128)
В данном случае, если шлюз безопасности М1 выходит из строя, соединение перебрасывается на шлюз
безопасности М2. Пакет, отправленный хостом 2, перенаправится маршрутизатором, находящимся за
шлюзом безопасности М1, к шлюзу безопасности М2, поскольку шлюз безопасности М2 назначен резервным
шлюзом безопасности. В отсутствие проводного режима шлюз безопасности М2 был бы подвергнут проверке
состояния соединения, и связь была бы прервана, поскольку пакеты, приходящие на шлюз безопасности, с
которым связь была инициирована через другой шлюз безопасности, считались бы «неисправными».
Поскольку внутренний интерфейс шлюза безопасности М2 является «доверенным», а в сообществе
действует проводной режим, то проверка состояния соединения не выполняется, и шлюз безопасности М2
успешно подхватывает связь без потери информации.
На центральном шлюзе безопасности С активен проводной режим (но не задан внутренний доверенный
интерфейс).
Сообщество работает в проводном режиме.
Хост 1, расположенный за сателлитным шлюзом безопасности А, стремится открыть соединение через
VPN-туннель с хостом 2, расположенным за шлюзом безопасности В.
В сателлитном сообществе центральные шлюзы безопасности используются для маршрутизации трафика
между сателлитными шлюзами безопасности сообщества.
В данном случае, трафик от сателлитных шлюзов безопасности только перенаправляется шлюзом
безопасности С, не имея возможности пройти через его брандмауэр. Таким образом, нет необходимости
проводить проверку состояния соединения на шлюзе безопасности С. Поскольку сообщество и шлюз
безопасности С работают в проводном режиме, что делает их доверенными, проверка состояния соединения
пропускается. Однако, эта проверка выполняется на шлюзах безопасности А и В.
Хост 1 Интернет
Сообщество 1 Сообщество 2
Шлюз безопасности А Хост 2
Шлюз безопасности С Шлюз безопасности В
MyIntranet=>internal_clear
internal_clear=>MyIntranet
Условия совпадения представлены серией составных объектов. Выполнение этих условий устремляет
трафик в следующих направлениях:
В VPN-сообщество и из него посредством VPN-маршрутизации (MyIntranet=>MyIntranet)
Из сообщества к локальным VPN-доменам (MyIntranet=>internal_clear)
Из локальных VPN-доменов в VPN-сообщество (internal_clear=>MyIntranet)
Вашингтон – это ячеистое сообщество, а Лондон – VPN-звезда. В столбце VPN базы правил политики
безопасности введено правило направления VPN. Это значит, что для удовлетворения этому правилу
источник VPN-соединения должен находиться в сети Вашингтон, а адресат – в сети Лондон.
Это не значит, что обратные соединения из Лондона в Вашингтон запрещены (трехэтапное квитирование в
начале каждого TCP-соединения требует обратной связи); но первый пакет должен исходить из сети
Вашингтон. Если один их хостов звезды Лондон попробует открыть соединение с хостом из сети Вашингтон,
связь будет разорвана.
Такое установление направления не влияет на топологию сети Вашингтон или Лондон. Можно считать, что
оно происходит где-то между сообществами.
Непрерывное зондирование (по умолчанию). После начала сеанса все возможные IP-адреса
назначения непрерывно получают RDP-пакеты. Зондирование RDP включается при открытии
соединения и продолжается как фоновый процесс.
Одноразовое зондирование. После начала сеанса все возможные IP-адреса назначения
принимают RDP-сеанс с целью проверки маршрута. Эти результаты используются до следующей
установки политики.
Примечание. RDP-пакеты UDP не шифруются. Механизм RDP служит только для проверки
связи.
Шлюз безопасности А
В данной ситуации шлюз безопасности А имеет два внешних интерфейса: 192.168.10.10 и 192.168.20.10. У
удаленного шлюза безопасности В тоже два внешних интерфейса: 192.168.30.10 и 192.168.40.10
Если доступны все маршруты для исходящего трафика от шлюза безопасности А, то минимальной метрикой
(высшим приоритетом) обладает маршрут 192.168.10.10 – 192.168.40.10, поэтому он является самым
предпочтительным.
Как удаленные шлюзы безопасности выбирают IP-адрес локального шлюза безопасности для организации
VPN-трафика?
Поскольку для VPN доступен лишь один интерфейс, для определения, как удаленные узлы узнают IP-адрес
локального шлюза безопасности, на странице выбора линии связи в разделе Выбор IP-адреса по
удаленному узлу:
задайте Основной адрес или выберите IP-адрес из выпадающего меню Избранный адрес из таблицы
топологии;
если IP-адрес расположен позади статического NAT-устройства, выберите Статически «NAT-
ированный» IP-адрес.
Локальный шлюз безопасности имеет два IP-адреса, которые используются для VPN. Один интерфейс
используется для VPN с удаленным шлюзом безопасности А, а другой – для шлюза безопасности В.
Чтобы определить, как удаленные шлюзы безопасности узнают IP-адрес локального шлюза безопасности,
включите одноразовое зондирование с высокой доступностью в режиме резервирования. Поскольку для
каждого удаленного шлюза безопасности доступен только один IP, зондирование достаточно проводить лишь
раз.
Чтобы определить, как удаленные шлюзы безопасности узнают IP-адрес локального шлюза безопасности,
включите непрерывное зондирование с высокой доступностью в режиме резервирования. Для
зондирования IP-адреса статического NAT его следует добавить в список Зондировать следующие адреса
в окне Настройки зондирования.
Для использования обоих интерфейсов с распределением VPN-трафика между доступными линиями связи,
воспользуйтесь на локальном шлюзе безопасности зондированием с распределением нагрузки в режиме
резервирования. Тогда удаленный шлюз безопасности распределит исходящий VPN-трафик между
интерфейсами eth0 и eth1 локального шлюза безопасности.
Если значение параметра Выбор исходящего маршрута оставлено по умолчанию Таблица
маршрутизации операционной системы, локальный шлюз безопасности использует для исходящего VPN-
трафика только один локальный интерфейс; это будет маршрут с минимальной метрикой и максимально
подходящие, чтобы пакеты добрались до единственного IP-адреса удаленного шлюза безопасности, исходя
из таблицы маршрутизации.
Если исходящий от локального шлюза безопасности трафик также необходимо распределить по обеим
исходящим линиям связи, выберите значение Зондирование на основе маршрутов для параметра Выбор
исходящего маршрута на странице Выбор линии связи локального шлюза безопасности.
В данном примере интерфейс eth1 обоих шлюзов безопасности предназначен для HTTP- и FTP-трафика.
Остальной трафик направляется на интерфейс eth0.
Если доступная линия связи через eth1 прекращает откликаться на зондирование RDP, HTTP- и FTP-трафик
переключится на eth0. Можно задать, чтобы HTTP- и FTP-трафик направлялся через eth1 даже тогда, когда
линия связи eth1 перестает откликаться. Это задается при редактировании конфигурационного файла выбора
линии связи на основе служб за счет включения флага dont_failover.
Весь остальной трафик, не являющийся HTTP или FTP, будет направляться через eth0. Если линия связи
через eth0 прекратит откликаться на зондирование RDP, весь трафик будет направлен через eth1.
Так выглядит конфигурационный файл выбора линии связи на основе служб для описанной среды.
Кроме того, в SmartDashboard можно создать группу служб, включающую службы HTTP и FTP. В примере
ниже эта группа называется http_ftp_grp. C этой группой конфигурационный файл выбора линии связи на
основе служб для описанной среды будет выглядеть следующим образом:
Для использования всех трех внешних интерфейсов и распределения VPN-трафика между доступными
линиями связи необходимо включить распределение нагрузки выбора линии связи и зондирование на основе
маршрутов. Для контроля использования полосы пропускания присвойте одну или несколько линий связи
конкретной службе или службам с помощью выбора линии связи на основе служб. В данной ситуации
интерфейсы eth0 и eth1 обоих шлюзов безопасности присвоены SIP-трафику. SIP-трафик распределяется
между eth0 и eth1. Весь остальной трафик направляется через eth2.
Если одна из линий связи – через eth0 или через eth1 – прекратит реагировать на зондирование RDP, SIP-
трафик будет переброшен на другой соответствующий интерфейс. Если же прекратит реагировать на
зондирование RDP линия через eth2, тогда весь трафик пойдет через eth0 и eth1.
Интернет
Удаленный шлюз безопасности Paris_GW
Для использования всех внешних интерфейсов и распределения VPN-трафика между доступными линиями
связи на локальном шлюзе безопасности London_GW необходимо включить распределение нагрузки выбора
линии связи и зондирование на основе маршрутов. Для контроля использования полосы пропускания с
помощью выбора линии связи на основе служб присвойте интерфейс eth1 локального шлюза безопасности
HTTP- и FTP-трафику. Локальный шлюз безопасности исходящий HTTP- и FTP-трафик направит через
интерфейс eth1. Весь остальной трафик, помимо HTTP и FTP, будет направляться через eth0.
В данном примере HTTP- и FTP-трафик не переключается, а всегда направляется через интерфейс eth1,
даже тогда, когда линия связи eth1 перестает откликаться на зондирование RDP. Это задается за счет
включения флага dont_failover.
Так выглядит конфигурационный файл выбора линии связи на основе служб для описанной среды.
Поскольку конфигурация выбора линии связи на основе служб действует только для исходящего трафика
локального шлюза безопасности, удаленный шлюз безопасности может отсылать HTTP- и FTP-трафик на
любой интерфейс локального шлюза безопасности. Исходящий VPN-трафик удаленного шлюза безопасности
распределяется между интерфейсами eth0 и eth1 локального шлюза безопасности.
Если зондирование с резервированием проводить в режиме высокой доступности, а доверенную линию связи
настроить как первичный IP-адрес, доверенная линия будет использоваться для VPN-трафика. Если
доверенная линия прекратит откликаться на зондирование RDP, то для VPN-трафика будет использоваться
линия, проходящая через интерфейс eth0, и передача станет шифрованной.
Если зондирование с резервированием происходит в режиме распределения нагрузки, тогда VPN-трафик
распределяется между доступными линиями связи. Соединения, направляемые через интерфейс eth0, будут
шифроваться, в то время как соединения, направляемые через доверенную линию связи, шифроваться не
будут.
SIP-трафик направляется через доверенное соединение между двумя интерфейсами eth1 и не подвергается
шифрованию. Если доверенная линия связи прекращает откликаться на зондирование RDP, SIP-трафик
будет перенаправлен через интерфейсы eth0 и, соответственно, зашифрован.
Весь остальной трафик (не SIP) шифруется и направляется через линию связи интерфейса eth0. Однако,
если интерфейс eth0 прекратит реагировать на зондирование RDP, весь трафик будет направляться через
доверенную линию связи, не проходя шифрование.
Локальный шлюз безопасности Соединение ISDN dial-up (настроено как линия святи по
требованию)
У шлюза безопасности две внешних линии для подключения к Интернет: одна к ISP, другая – к ISDN dial-up.
Соединение ISDN dial-up сконфигурировано как линия по требованию.
Свойство Описание
В окне Топология > ISP-резервирование настройте параметры ISP-резервирования так же, как и линии
связи ISP, и режим резервирования. Параметры ISP-резервирования по умолчанию применяются к VPN-
трафику. Заимствованные настройки выбора линии связи видны в окне VPN IPSec > Выбор линии связи.
В следующей ситуации на странице ISP-резервирование была снята отметка с флажка Применить
настройки к VPN-трафику (Apply settings to VPN-traffic) – поэтому для выбора линии связи и ISP-
резервирования настроены разные параметры.
В данной ситуации:
У шлюзов безопасности А, В, С есть по два интерфейса, настроенных как линии связи ISP.
ISP-резервирование настроено на шлюзе безопасности А.
Шлюз безопасности А должен использовать ISP 1 для соединения с шлюзом безопасности В, а ISP 2 –
для соединения с шлюзом безопасности С. Если одна из линий связи станет недоступной, следует
использовать другую линию ISP.
В данной ситуации администратору шлюза безопасности А необходимо:
В окне ISP-резервирование снять отметку с флажка Применить настройки к VPN-трафику.
В окне Выбор линии связи перенастроить Выбор исходящего маршрута на Зондирование на основе
маршрутов.
Настроить таблицу маршрутизации таким образом, чтобы ISP 1 имела наивысший приоритет для
удаленного шлюза безопасности В, а ISP 2 – для удаленного шлюза безопасности С.
Обзор МЕР
Множественные точки входа (МЕР, Multiple Entry Point) – это функция, обеспечивающая решение для высокой
доступности и распределения нагрузки VPN-соединений. Шлюз безопасности, на котором установлен VPN-
модуль, является точкой входа внутренней сети. Именно этот шлюз безопасности делает сеть «доступной»
для удаленных машин. Если шлюз безопасности выходит из строя, то внутренняя сеть становится
недоступной. Среда МЕР обладает двумя и больше шлюзами безопасности, защищающими и
обеспечивающими доступ к одному и тому же VPN-домену; таким образом, удаленным шлюзам безопасности
гарантируется непрерывный доступ.
Внедрение
МЕР внедряется посредством проприетарного протокола зондирования (PP – Probing Protocol),
отправляющего специальные UDP RDP пакеты на порт 259, узнавая, достижим ли IP. Этот протокол является
собственным протоколом Check Point и не соответствует RDP, как указано в RFC 908/1151/
Примечание. Эти UDP RDP пакеты не шифруются, поскольку всего лишь проверяют
доступность узла.
Удаленный узел непрерывно зондирует или опрашивает все шлюзы безопасности с МЕР, чтобы определить,
какие из них активны, и выбирает шлюз безопасности, согласно заданному алгоритму выбора. Поскольку
пакеты RDP отправляются постоянно, состояние шлюзов безопасности известно и обновляется при каждом
изменении. В результате всегда известно, какие шлюзы безопасности активны.
Существует два доступных метода внедрения МЕР.
Явные МЕР. Этот метод реализуем только в сообществах со звездообразной топологией, в которых
присутствует более одного центрального шлюза безопасности. МЕР вносит в сеть позади шлюза
безопасности множественные точки входа. Если внедрение явных МЕР возможно, этот метод является
предпочтительным.
Неявные МЕР. Этот метод поддерживается во всех ситуациях, где есть частично или полностью
перекрывающиеся домены шифрования или настроены первичные-резервные шлюзы безопасности (см.
стр. 103). При обновлении после более ранней версии, чем NGX (R60), где неявные МЕР уже настроены,
ранее настроенная конфигурация остается.
VPN Site-to-Site
Явные МЕР
В звездообразном VPN-сообществе Site-to-Site явные МЕР настраиваются через объект сообщества. Когда
МЕР активны, «унифицированный» VPN-домен всех шлюзов безопасности рассматривается сателлитами как
VPN-домен для каждого шлюза безопасности. Этот унифицированный VPN-домен считается VPN-доменом
каждого шлюза безопасности.
Унифицированный VPN-домен
Хост 1
Выделенная линия
Удаленные узлы отсылают пакеты RDP всем шлюзам безопасности в конфигурации МЕР.
Первый шлюз безопасности, который ответил на зондирующий пакет RDP, выбирается точкой входа в
сеть. Суть метода «первый ответивший» состоит в близости. Тот шлюз безопасности ответит раньше,
который «ближе» к удаленному узлу.
VPN-туннель открывается с тем шлюзом безопасности, который ближе. Все последующие соединения
проходят через выбранный шлюз безопасности.
Если шлюз безопасности прекращает откликаться, выбирается новый шлюз безопасности.
По VPN-домену
Перед внедрением МЕР каждый IP-адрес принадлежал конкретному VPN-домену. По методу «по VPN-
домену» шлюз безопасности этого домена становится выбранной точкой входа. На схеме у звездообразного
VPN-сообщества два центральных шлюза безопасности с МЕР (М1 и М2, у каждого свой VPN-домен) и
удаленный сателлит S1.
Хост 3 Хост 2
Хост 1
Хост-2 в VPN-домене сателлита S1 инициирует соединение с хостом 1. Соединение может пройти через М1
или М2. Однако, хост 1 располагается в первоначальном домене М2. По этой причине М2 считается шлюзом
безопасности, «ближайшим» к IP-адресу назначения. Значит, М2 назначается первичным шлюзом
безопасности, а М1 – резервным шлюзом безопасности для хоста 1. Если бы в центре были еще шлюзы
безопасности, они также рассматривались бы как резервные шлюзы безопасности для М2.
Если в VPN-доменах есть частично или полностью перекрывающиеся домены шифрования, тогда
«ближайшей» точкой входа в сеть можно выбрать более одного шлюза безопасности. В результате
«первичными» станут более одного шлюза безопасности. А если в наличии более одного первичного или
резервного шлюза безопасности, для выбора шлюза безопасности применяется дополнительный алгоритм
выбора. Дополнительным алгоритмом может служить (см. «Дополнительные настройки» (на стр. 135)):
первый ответивший
произвольный выбор (для распределения нагрузки)
Для получения ответных пакетов можно на центральных шлюзах безопасности воспользоваться RIM. Если
задействован и RIM, выделенной линии необходимо задать метрику с низшим приоритетом, чем у VPN-
туннеля. У сателлита S1 одновременно может быть открыто свыше одного VPN-туннеля со шлюзами
безопасности с МЕР; например, М2 – выбранная точка входа для хоста 1, а М1 – выбранная точка входа для
хоста 3. М1 и М2 будут публиковать маршруты к хосту 1 и хосту 3; метрика низшего приоритета станет
залогом того, что выделенная линия будет использована лишь после того, как выйдет из строя один из
шлюзов безопасности.
Произвольный выбор
При использовании этого метода точкой входа для входящего трафика назначается произвольный шлюз
безопасности. Равномерное распределение входящего трафика между всеми возможными шлюзами
безопасности предотвратит перегрузку одного шлюза безопасности при избытке входящей информации.
С целью создания списка откликающихся шлюзов безопасности, последние зондируются пакетами RDP, как и
во всех остальных конфигурациях МЕР. Шлюз безопасности произвольным образом выбирается из списка
откликающихся шлюзов. Если шлюз безопасности прекращает откликаться, произвольно выбирается другой
шлюз безопасности.
Унифицированный VPN-домен
На схеме три члена МЕР (М1, М2, М3) предоставляют точки входа в сеть для трех сателлитных шлюзов
безопасности (S1, S2, S3). Сателлит S1 может быть настроен на такую очередность попыток входа: М1 – М2 –
М3, при этом максимальный приоритет у М1, а минимальный – у М3. Для сателлита S2 может быть настроена
другая последовательность: М2, М3 (а М1 даже не пробовать).
Каждый из этих приоритетов составляет правило МЕР в окне списка приоритетов МЕР, составляемого
вручную.
Пункт Описание
Окно списка приоритетов МЕР разделено на правило по умолчанию и правила, представляющие исключения
из правила по умолчанию. Правило по умолчанию действует тогда, когда:
не определено правил МЕР;
среди правил-исключений приоритета нет источника соединения.
Область правил приоритета содержит три уровня приоритета: первичный, вторичный и третичный. Поскольку
существует только три уровня приоритета, то:
нескольким центральным шлюзам безопасности может быть назначен один и тот же приоритет;
одно и то же правило может быть присвоено нескольким сателлитным шлюзам безопасности;
уровень приоритета может быть незаполненным.
Во втором правиле МЕР ниже
Неявные МЕР
Существует три метода внедрения неявных МЕР:
Первый ответивший. Выбирается первый шлюз безопасности, ответивший удаленному шлюзу
безопасности. В организации следует выбрать этот вариант, если, например, у нее есть два шлюза
безопасности, в конфигурации МЕР – один в Лондоне, второй в Нью-Йорке. Для узлов VPN-1,
расположенной в Англии, имеет смысл держать связь с Лондонским шлюзом безопасности раньше, а с
Нью-Йоркским – позже. Поскольку Лондонский шлюз безопасности географически находится ближе к
английским узлам, то и ответит он раньше, таким образом, становясь точкой входа во внутреннюю сеть.
См. «Первый ответивший» (на стр. 136).
Первичный-резервный. Один или несколько резервных шлюзов безопасности обеспечивают высокую
доступность первичного шлюза безопасности. Удаленный узел настроен на работу с первичным шлюзом
безопасности, однако, при падении последнего переключается на резервные. Такая конфигурация может
быть выгодна для организации, у которой в МЕР-среде есть два компьютера разной мощности. Есть
смысл более сильную машину настроить как первичную. Даже если машины обладают одинаковой
производительностью, одна из них может быть дешевле или иметь более быстрый доступ в Интернет.
Тогда машину с лучшим соединением с Интернетом необходимо сделать первичной. См. «Первичные-
резервные шлюзы безопасности» (на стр. 138).
Распределение нагрузки. Удаленный VPN-узел случайно выбирает шлюз безопасности, с которым
открыть соединение. Для каждой пары IP-адресов источник-адресат произвольным образом выбирается
новый шлюз безопасности. У организации может быть ряд машин одинаковой производительности. В
этом случае есть смысл задействовать распределение нагрузки, тогда машины будут использоваться
равномерно и поровну. См. «Произвольный выбор» (на стр. 133).
Неявные МЕР поддерживаются, если в одном и том же сообществе есть шлюзы безопасности с
перекрывающимися доменами шифрования. Если же они расположены в разных сообществах, для этого
домена шифрования будет использоваться только один из шлюзов безопасности.
Примечание. При обновлении после более ранней версии, чем NGX (R60), где неявные МЕР
уже настроены, ранее настроенная конфигурация остается.
Первый ответивший
В условиях отсутствия первичного шлюза безопасности все шлюзы безопасности имеют равный приоритет. А
если все шлюзы безопасности одинаково приоритетны, тогда:
Удаленные VPN-узлы отправляют пакеты RDP на все шлюзы безопасности в конфигурации МЕР.
Первый шлюз безопасности, который ответит на зондирующие пакеты RDP, выбирается в качестве точки
входа в сеть. Суть метода «первый ответивший» состоит в близости. Чем «ближе» шлюз безопасности к
удаленному VPN-узлу, тем раньше он ответит.
VPN-туннель открывается с первым ответившим шлюзом безопасности. Все последующие соединения
проходят через выбранный шлюз безопасности.
Если шлюз безопасности прекращает откликаться, выбирается новый шлюз безопасности.
В звездообразном сообществе шлюзам безопасности отправляются пакеты RDP. Первый ответивший шлюз
безопасности используется для маршрутизации при следующих условиях:
1. Существует более одного центрального шлюза безопасности.
2. Выбран один из следующих вариантов VPN-маршрутизации:
К центру и к прочим сателлитам через центр.
К центру или через центр к прочим сателлитам, в Интернет и другие VPN.
Данная настройка находится на странице Свойства сообщества > VPN Дополнительно > VPN-
маршрутизация.
В данной ситуации:
VPN-домен В
Шлюз В
Общий домен шифрования
VPN-домен С
VPN-домен А
Шлюз А
Шлюз Х
В сообществе
МЕР не задействованы.
Используется метод «первый ответивший».
Шлюз безопасности Х имеет доступ к VPN-домену А через шлюз безопасности А.
Шлюз безопасности Х имеет доступ к VPN-домену В через шлюз безопасности В.
Шлюз безопасности Х имеет доступ к VPN-домену С через шлюз безопасности А или В.
В звездообразном сообществе шлюзам безопасности отправляются пакеты RDP. Первый ответивший шлюз
безопасности используется для маршрутизации при следующих условиях:
1. Существует более одного центрального шлюза безопасности.
2. Выбран один из следующих вариантов VPN-маршрутизации:
К центру и к прочим сателлитам через центр.
К центру или через центр к прочим сателлитам, в Интернет и другие VPN.
Данная настройка находится на странице Свойства сообщества > VPN Дополнительно > VPN-
маршрутизация.
Первичные-резервные шлюзы безопасности
Резервные шлюзы безопасности обеспечивают бесперебойную работу первичных шлюзов безопасности.
Если первичный шлюз безопасности выходит из строя, соединение проходит через резервный.
В данной ситуации:
Первый шлюз безопасности настраивается как «первичный», а второй – как «вторичный». Если первичный
шлюз безопасности по какой-нибудь причине выйдет из строя, удаленный VPN-узел обнаружит, что линия
связи неактивна и отработает через вторичный шлюз безопасности. Вторичный шлюз наследует весь VPN-
домен первичного. Переключение сигнала в рамках существующего соединения не предусматривается;
текущее соединение в этом случае теряется.
После восстановления первичного шлюза безопасности новые соединения проходят через первичный шлюз
безопасности, а существующие продолжают использовать резервный шлюз.
Примечание. При использовании метода первичных-резервных шлюзов безопасности домены
шифрования не должны перекрываться.
Распределение нагрузки
Чтобы предотвратить явление переполнения одного из шлюзов безопасности соединениями, последние
можно поровну разделить между всеми шлюзами безопасности, распределив нагрузку. Когда все шлюзы
безопасности обладают равным приоритетом (без первичных) и настроены на МЕР в одном и том же
домене, можно задействовать распределение нагрузки между шлюзами безопасности. С целью создания
списка откликающихся шлюзов безопасности, последние зондируются пакетами RDP, как и во всех остальных
конфигурациях МЕР. Шлюз безопасности произвольным образом выбирается из списка откликающихся
шлюзов. Если шлюз безопасности прекращает откликаться, произвольно выбирается другой шлюз
безопасности.
Для каждой пары IP-адресов источник-адресат произвольным образом выбирается новый шлюз
безопасности. Пока IP-адреса источника и адресата остаются неизменными, соединение продолжает
проходить через выбранный шлюз безопасности.
Особенности
1. Если один из центральных шлюзов безопасности управляется извне:
VPN-домен центральных шлюзов безопасности не будет автоматически наследоваться шлюзами
безопасности, управляемыми извне.
Конфигурация RIM не будет автоматически загружена.
2. Шлюзы безопасности UTM-1 Edge не настраиваются как шлюзы безопасности с МЕР, однако способны
соединяться с шлюзами безопасности с МЕР.
3. Шлюзы безопасности DAIP, чтобы быть настроенными как шлюзы безопасности с МЕР, требуют
разрешения DNS.
Настройка МЕР
Для настройки МЕР следует принять решение о следующем:
1. Метод МЕР
Явные МЕР – см. «Явные МЕР» (на стр. 129).
Неявные МЕР – см. «Неявные МЕР» (на стр. 136).
2. При необходимости, метод возврата ответных пакетов:
NAT пула IP.
RIM – для настройки RIM см. «Настройка RIM» (на стр. 94).
Распределение нагрузки
Включить распределение нагрузки для конфигураций МЕР (соединения удаленного доступа)
2. В дереве сетевых объектов, в разделе Группы создайте группу шлюзов, выступающих в роли резервных.
3. Откройте свойства VPN первичного шлюза:
NGX R65 и R70: Свойства шлюза > VPN
R71 и выше: Свойства шлюза > VPN IPSec
4. Отметьте Использовать резервные шлюзы (Use Backup Gateways) и выберите группу резервных
шлюзов.
В таблице ниже показано, как VPN внедряется в правила в традиционном режиме. Единое правило с
действием Зашифровать регулирует и шифрование, и контроль доступа.
Пример правила шифрования в традиционной базе правил
Если источник или адресат находятся позади шлюза безопасности, но не в VPN-домене шлюза безопасности,
соединение обрывается.
Например, если источник X – Net_C, а адресат Y – Net_D, то шлюз безопасности 1 оборвет соединение,
поскольку действие гласит «Зашифровать», но это соединение зашифровать невозможно, ибо источник не
находится в VPN-домене шлюза безопасности 1.
Если источник и адресат пребывают внутри VPN-домена одного и того же шлюза безопасности, то
соединение будет принято в нешифрованном виде.
Например, если источник X – Net_A, а адресат Y – Net_B, то соединение исходит от Х и достигает шлюза
безопасности, отправляющего ответ назад на Y. Соединение не шифруется, поскольку у Y нет второго шлюза
безопасности, который расшифровал бы его. В журнале SmartView Tracker формируется запись «Обе
конечные точки в домене шифрования».
VPN-туннель
Интернет
Домен шифрования шлюза 2
Первое правило говорит о том, что соединение соответствует критериям и разрешено, если оно исходит от Х
и адресуется Y в рамках сообщества Site-to-Site.
После преобразования в упрощенный режим соединение из узла в Net_A к узлу в Net_B будет отвергнуто
новой базой правил. Это произойдет благодаря правилам сообщества, определяющим трафик между VPN-
доменами, и не относящимися к трафику в рамках VPN-домена.
Преобразованное правило в упрощенной базе правил
Чтобы разрешить эти соединения в преобразованной базе правил, их следует явно разрешить. Чтобы это
сделать, добавьте свое правило между двумя существующими для каждой цели политики из столбца
«Установить на». Например, вместо двух правил, указанных в таблице ниже, могут появиться три правила из
таблицы ниже.
Вручную добавленное правило в преобразованной базе правил шифрования
В большинстве случаев добавлять эти правила не надо. Это требуется только тогда, когда соединения внутри
домена шифрования помечены правилом шифрования. Признаком этого является появления в журнале
SmartView Tracker записи «Обе конечные точки в домене шифрования».
При обнаружении конвертером правил Auth+Encrypt, администратору приходит уведомление в виде ошибки, в
котором говорится, что конвертер не может автоматически преобразовать такие правила. В этом случае
важно перед установкой пересмотреть преобразованную базу данных, чтобы избежать погрешностей защиты.
Возможно, необходимо добавить правила, чтобы весь ранее отбрасываемый первоначальной базой правил
трафик и при новой преобразованной базе правил отбрасывался.
Типы решений
Все решения Check Point для удаленного доступа обеспечивают:
Безопасную связь с корпоративными ресурсами в масштабе предприятия.
Сильную проверку подлинности пользователей.
Точный контроль доступа.
Факторы, которые следует учитывать при выборе решения для удаленного доступа
для вашей организации
Клиентское или бесклиентное. Требует ли решение установки клиентского ПО Check Point на
удаленных терминалах? Или это бесклиентное решение, для которого достаточно веб-браузера?
Возможно в пределах организации вам понадобится несколько решений под разные нужды.
Безопасная связь и безопасность терминалов. Какими свойствами должно обладать решение?
Безопасная связь. Трафик между клиентом и шлюзом VPN шифруется. После аутентификации
пользователей, им предоставляется доступ к корпоративным ресурсам, для них открытым политикой
доступа. Это обеспечивают все решения Check Point.
Безопасность терминалов. Терминальные компьютеры все время защищены, даже когда нет
соединения с корпоративной сетью. Это обеспечивают некоторые решения Check Point.
SecuRemote
SecuRemote – безопасный VPN-клиент на IPSec с ограниченной функциональностью. Обеспечивает
безопасную связь.
Требуемые лицензии: программный блейд VPN IPSec на шлюзе. Клиент бесплатный и не требует
дополнительных лицензий.
Поддерживаемые платформы: Windows
Check Point GO
Check Point GO – это портативное рабочее пространство с виртуализированными приложениями Windows на
защищенном и зашифрованном USB Flash-накопителе. Пользователи вставляют USB-накопитель в хост и
получают безопасный доступ к своему рабочему пространству и корпоративным ресурсам посредством VPN-
технологии SSL.
Check Point GO идеально подходит для мобильных работников, подрядчиков и при аварийном
восстановлении. Виртуальное рабочее пространство отделяется от компьютера-хоста и управляет
приложениями, данными, способными работать под Check Point GO.
Обеспечивает:
Безопасную связь
Проверку безопасности
Требуемые лицензии: программный блейд VPN IPSec на шлюзе и устройствах Check Point GO.
Поддерживаемые платформы: Windows
Где достать клиент: центр поддержки Check Point (sk67820).
Для решения этих проблем требуется система безопасности, обеспечивающая надежную защиту удаленного
соединения.
Решения Check Point для VPN с удаленным доступом позволяют сформировать VPN-туннель между
удаленным пользователем и внутренней сетью организации. VPN-туннель гарантирует:
Подлинность за счет применения стандартных средств аутентификации.
Конфиденциальность за счет шифрования данных.
Целостность за счет промышленного стандарта контроля целостности данных.
Клиентское ПО Check Point для удаленного доступа расширяет возможности удаленных пользователей.
Последним предоставляется возможность безопасного доступа к чувствительным данным в сетях и на
серверах посредством VPN-туннеля, используя LAN, беспроводную LAN и разные варианты dial-up-
соединений, в том числе широковещательные. Управление пользователями происходит либо во внутренней
базе данных шлюза безопасности, либо через внешний сервер LDAP.
Режим соединения
Клиенты удаленного доступа соединяются с шлюзами безопасности, используя режим соединения.
В режиме соединения удаленный пользователь сознательно инициирует VPN-канал к конкретному шлюзу
безопасности. Последующие соединения с любым хостом позади других шлюзов безопасности в меру
необходимости приведут к прозрачному появлению дополнительных VPN-каналов.
В режиме соединения возможно:
Офисный режим. Для решения проблем маршрутизации между клиентом и шлюзом безопасности. См.
«Офисный режим» (на стр. 185).
Режим посетителя. Для ситуаций, когда клиент обязан весь трафик «клиент-шлюз безопасности»
провести через обычное TCP-соединение, порт 443.
Маршрутизация всего трафика через шлюз безопасности (режим концентратора). Для достижения
высшего уровня безопасности и качества связи.
Автосоединение. Когда приложение пытается установить связь с хостом позади шлюза безопасности,
пользователь получает приглашение инициировать VPN-канал к этому шлюзу безопасности. Например,
когда почтовый клиент пытается получить доступ к INAP-серверу позади шлюза безопасности Х,
SecureClient посылает пользователю приглашение инициировать туннель к этому шлюзу безопасности.
Профили пользователей (Профили местоположений). См. «Профили пользователей» (на стр. 168).
Профили пользователей
Перед мобильными пользователями возникает масса разных проблем связи. Утром они подключены к
локальной сети компании-партнера; вечером они подключаются за каким-нибудь NAT-устройством,
используемым в гостинице, в которой они живут.
В изменчивых условиях подключения используются разные профили пользователя. Пользователи создают
собственные профили; или администратор сети создает для них несколько профилей. Если администратор
создает профиль, профиль загружается в клиентское ПО вместе с обновлением топологии узла.
Пользователь выбирает, с каким профилем из списка ему работать. Например, с профилем, допускающим
инкапсуляцию UDP, чтобы справиться с NAT-устройством, или с профилем, разрешающим режим
посетителя, когда удаленный клиент обязан туннелировать VPN-соединение через порт 443. В профиле
содержится также сервер политики, применяемый для загрузки политики безопасности настольных систем.
Пароль шлюза безопасности. Пользователю предлагается ввести свой пароль, хранимый на шлюзе
безопасности.
Пароль ОС. Пользователю предлагается ввести свой пароль операционной системы.
RADIUS. Пользователю предлагается ввести правильный ответ, определяемый сервером RADIUS.
TACACS. Пользователю предлагается ввести правильный ответ, определяемый сервером TACACS или
TACACS+.
SAA. SAA – это API-расширение OPSEC для клиентов удаленного доступа, позволяющее применение
сторонних методов проверки подлинности, таких как биометрическая идентификация, с Endpoint Security
VPN, Check Point Mobile for Windows и SecuRemote.
Настройка проверки подлинности
На шлюзе безопасности проверку подлинности можно настроить в двух местах.
В окне Свойства шлюза на странице Аутентификация (Authentication) можно настроить доступ для
пользователей, использующих для аутентификации Пароль Check Point, SecurID, Пароль Ос, сервер
RADIUS или сервер TACACS. Вдобавок к выбранному методу по умолчанию разрешается для
аутентификации использовать клиентские сертификаты, выданные внутренним центром сертификации.
У некоторых блейдов есть собственные настройки аутентификации. Они настраиваются в окне
Свойства шлюза соответствующего шлюза в разделе Аутентификация <название блейда>.
Например, метод аутентификации для клиентов VPN IPSec настраивается в Свойства шлюза > VPN
IPSec > Аутентификация. Если вы выберете метод аутентификации для этого блейда, этим методом
должны будут пользоваться все пользователи, представляющиеся данному блейду. Для других блейдов
на других страницах можно настроить другие методы аутентификации – и пользователи будут
вынуждены использовать их.
Если вы не сделаете выбор для конкретного блейда на странице Аутентификация, соответствующие
настройки для этого блейда шлюз безопасности позаимствует со страницы аутентификации основного
шлюза.
Примечание. В предыдущих выпусках не было возможности настройки аутентификации для
конкретного блейда. Однако, начиная от версии R75, если вы задали метод аутентификации для
отдельного блейда, настройки на этой странице никак не повлияют на этот блейд.
Поиск пользователей шлюзом
Если для блейда параметры проверки подлинности берутся со страницы Аутентификация по-старому
(Legacy Authentication) основного шлюза безопасности, то при попытке пользователей представиться шлюз
безопасности выполняет поиск стандартным способом. Шлюз ищет в следующих местах:
1. Внутренняя база данных пользователей.
2. Если указанный пользователь не найден в этой базе данных, шлюз опрашивает серверы Каталога
пользователей (LDAP), определенные в учетной записи, по одному, в порядке приоритета.
3. Если информация все еще не найдена, шлюз использует внешний пользовательский шаблон, чтобы
проверить, есть ли совпадения по общему профилю. У общего профиля атрибуты по умолчанию,
применяемые к конкретному пользователю.
Если для конкретного блейда назначить метод аутентификации, шлюз будет искать пользователей по
группам, используемым для авторизации в этом блейде.
Например, в Mobile Access шлюз просматривает политику Mobile Access и выясняет, какие группы
пользователей являются частью политики. Когда шлюз пытается аутентифицировать пользователя, он
начинает его поиск в базах данных, связанных с этими группами пользователей.
В VPN IPSec шлюз просматривает VPN-сообщество с удаленным доступом, чтобы узнать, какие в него
включаются группы пользователей. Поиск пользователей производится в базах данных, связанных с этими
группами.
Поиск на основании схемы аутентификации оказывается быстрее и дает лучшие результаты. У вас могут
быть пользователи с одним именем в не связанных между собой группах. А шлюз будет знать, какой именно
пользователь подходит для блейда, поскольку владеет информацией о группах пользователей.
Дополнительные функции
VPN с удаленным доступом поддерживает другие дополнительные функции, такие как:
Разрешение проблем со связью и маршрутизацией. См. «Офисный режим» (на стр. 185) и «Решение
проблем связи» (на стр. 297).
IP-per-user/group (IP-адрес каждому пользователю или группе).
Клиенты L2TP.
Альтернативы SecuRemote/SecureClient
Чтобы избежать головной боли с установкой и поддержкой клиентского ПО, Check Point предоставляет SSL
Network Extender – простой во внедрении тонкий клиент, устанавливаемый на пользовательской машине
Для решения этих проблем требуется система безопасности, обеспечивающая надежную защиту удаленного
соединения с сетью.
Данный раздел содержит процедуры и пояснения для настройки VPN с удаленным доступом.
VPN с удаленным доступом
Пользователь сохраняет файл р12 на устройстве и указывает сертификат через удаленный VPN-
клиент.
Перед подключением к VPN с удаленным доступом пользователи представляются, вводя пароль
сертификата.
Использование регистрационного ключа:
Администратор создает регистрационный ключ и отправляет его пользователю.
Пользователь регистрирует сертификат, вводя регистрационный ключ. Дополнительно пользователь
может сохранить на устройство файл р12. Пользователь должен сделать это в период времени,
указанный администратором.
Конечные пользователи представляются этим сертификатом. Помимо этого, согласно настройкам
политики безопасности, может понадобиться пароль. Если пользователь сохранил файл р12 на
устройстве, то пароль будет необходим всегда.
Установка политики
Установите политику и сообщите пользователям создать или обновить топологию.
Отзыв сертификатов
Способ отзыва сертификатов зависит от того, управляются ли они изнутри или извне, посредством LDAP.
На шлюзе безопасности пользователи SecurID должны быть помещены в группу с внешней учетной
записью профиля, в которой в качестве метода аутентификации указан SecurID.
В расширенном виде отображается код токена, пароль с кнопками Копировать, которые позволяют людям
вырезать и вставлять значения между softID и SecureClient.
SoftID и SecureClient
Для успешного использования удаленными пользователями softID RSA выполняется следующее.
1. Администратор создает на сервере ACE удаленных пользователей.
2. За пределами канала связи администратор передает программный токен (токены) SDTID удаленным
пользователям.
3. Удаленный пользователь импортирует токены.
Офисный режим
В офисном режиме шлюз безопасности может присвоить удаленному клиенту IP-адрес. Присвоение
выполняется при подключении и аутентификации пользователя. Аренда адреса возобновляется, пока
пользователь подключен. Адрес может браться либо из общего пула IP-адресов, либо из пула IP-адресов,
указанного для группы пользователей. Адрес может быть указан как для пользователя, так и через сервер
DHCP, позволяя использование службы разрешения имен. При помощи разрешения имен DNS проще
получить доступ к клиенту из корпоративной сети.
Можно разрешить всем пользователям использовать офисный режим, а можно включить эту функцию для
конкретной группы пользователей. Это применимо, например, для предоставления конкретной группе
пользователей привилегированного доступа (напр., администраторам, которые получают доступ к локальной
сети из удаленных терминалов). Кроме того, это полезно на этапах раннего внедрения офисного режима – у
вас появляется возможность «обкатать» эту функцию на конкретной группе пользователей, в то время как
остальные пользователи продолжают работать как и раньше.
Офисный режим поддерживают:
SecureClient
Endpoint Connect
SSL Network Extender
Crypto
L2TP
VPN с удаленным доступом
Присвоение IP-адреса
Внутренние IP-адреса, которые шлюз безопасности присваивает удаленному пользователю, формируются
одним из двух методов:
пул IP-адресов;
сервер DHCP.
Пул IP-адресов
Системный администратор обозначает диапазон IP-адресов, которые будут использоваться для машин
удаленных клиентов. Каждый клиент, подающий запрос на подключение в офисном режиме, снабжается
уникальным IP-адресом из пула.
Присвоение IP-адреса на основании IP-адреса источника
IP-адреса в пуле могут быть зарезервированы и присваиваться удаленным пользователям на основании их
исходных IP-адресов. При подключении удаленного хоста к шлюзу безопасности, его IP-адрес сравнивается с
заранее заданным диапазоном исходящих IP-адресов. Если этот IP входит в заданный диапазон, тогда ему
присваивается IP-адрес офисного режима – из числа адресов, предназначенных для этой цели.
IP-адресам из этого зарезервированного пула можно придать особый набор разрешений, который будет
касаться конкретных удаленных пользователей.
Сервер DHCP
Для раздачи IP-адресов клиентам офисного режима можно использовать сервер протокола динамической
настройки хостов (DHCP – Dynamic Host Configuration Protocol). При подключении удаленного хоста к шлюзу
безопасности с использованием офисного режима, шлюз безопасности запрашивает сервер DHCP о
Антиспуфинг
При включенном антиспуфинге администратор сети задает, какие IP-адреса ожидаются на каждом
интерфейсе шлюза безопасности. Антиспуфинг обеспечивает только прием или отправку IP-адресов в
контексте соответствующих им интерфейсов шлюзов безопасности. Офисный режим представляет проблему
для функции антиспуфинга – ведь клиентская машина может подключиться и аутентифицироваться через
несколько интерфейсов, напр., через внешний Интернет-интерфейс или через интерфейс беспроводной
локальной сети. Таким образом, IP-адрес офисного режима может быть замечен на нескольких интерфейсах.
Офисный режим дополняет функцию антиспуфинга за счет проверки, действительно ли замеченный IP-адрес
офисного режима присвоен пользователю, который аутентифицировался на IP-адресе источника, указанном
в инкапсулированном IPSec пакете, т. е. внешнем IP.
VPN-домен В VPN-домен А
Решение
Существует два пути внедрения этой функции, в зависимости от того, выдан ли IP-адрес сервером DHCP или
из IP-пула.
Сервер DHCP
Если адреса офисного режима выданы DHCP-сервером? выполните следующие действия.
1. Откройте в дереве объектов объект Check Point.
2. На странице Свойства объекта > VPN IPSec > Офисный режим:
Включите офисный режим (для всех пользователей или для определенной группы).
Выберите DHCP-сервер и в поле Выдача МАС-адреса для DHCP (MAC address for DHCP
allocation) выберите рассчитывается по имени пользователя (calculated per user name).
3. Установите политику на шлюз безопасности.
4. На шлюзе безопасности запустите эту команду, чтобы получить МАС-адрес, присвоенный пользователю.
vpn macutil <имя пользователя>
5. На DHCP-сервере выполните резервирование, указав IP-адрес и MAC-адрес, назначив IP-адрес
исключительно в пользование данного пользователя.
Файл ipassignment.conf
Файл $FWDIR/conf/ipassignment.conf на шлюзе безопасности используется для внедрения функции «IP-
адрес для пользователя» (IP-per-user). Она дает администратору при подключении пользователей в офисном
режиме или с использованием L2TP возможность присваивать конкретным пользователям конкретные адреса
или группе пользователей диапазон адресов.
Пояснение синтаксиса файла см. в комментариях (строках, начинающихся на #) в примере ниже.
Примечание. Этот файл вручную следует добавить во все шлюзы безопасности.
Этот файл используется для внедрения функции «IP-адрес для пользователя» (IP-per-user). Она дает администратору при
подключении пользователей в офисном режиме или с использованием L2TP возможность присваивать конкретным пользователям
конкретные адреса или группе пользователей диапазон адресов.
Формат этого файла прост: каждая строка задает целевой шлюз безопасности, присваиваемый IP-адрес (адреса) и имя
пользователя (группы), как в примерах ниже.
|
|
|
Обратите внимание, что реальные записи не начинаются со знака диеза (#), запятые необязательны. Неверные строки
воспринимаются как комментарии. Кроме того, за именем пользователя может следовать знак диеза и комментарий. Первый
объект – имя шлюза безопасности. Это может быть имя, IP-адрес или звездочка (*), обозначающая все шлюзы безопасности.
Шлюз принимает во внимание только те строки, которые его касаются.
Второй объект – дескриптор. Это может быть ‘addr’, ‘range’ или ‘net’. ‘addr’ обозначает IP-адрес одного пользователя. Этот
префикс необязателен.
‘range’ и 'net' обозначают диапазон адресов. Эти префиксы обязательны.
Третий объект – IP-адрес или адреса. В случае единственного адреса, он указывается в обычном формате через точки. Диапазоны
задаются либо первым и последним IP-адресом, либо спецификацией сети. В любом случае необходимо также задать длину маски
подсети (‘/24’ обозначает 255.255.255.0). При указании диапазона это маска подсети. При указании сети это и маска подсети, и
определение адресов в диапазоне.
Последний объект – имя пользователя. Это может обычное имя, если пользователь аутентифицируется с помощью имени-
пароля (как гибрид или MD5) или DN, если используется сертификат.
В этой ситуации:
(10.10.5.0, 10.10.5.129), (10.10.9.0, 10.10.9.255), (70.70.70.4, 70.70.70.90) – это диапазоны исходных IP-
адресов удаленных клиентов VPN
(1.1.1.5, 1.1.1.87), (1.1.1.88, 1.1.1.95) – это IP-адреса офисного режима, которые будут присвоены
удаленным пользователям, чей исходный IP попадет в диапазон, определенный на той же строке.
Например: пользователь с исходным IP-адресом между 10.10.5.0 и 10.10.5.129 получит адрес офисного
режима между 1.1.1.5 и 1.1.1.87.
Присвоение IP на основании исходного IP-адреса включается флагом в файле \FWDIR\conf\objects_5_0.C.
Добавьте такой флаг:
om_use_ip_per_src_range (дальше идет значение)
Флагу должно быть присвоено одно из следующих значений.
[Exclusively]. Если IP удаленного хоста не найден в диапазоне исходных адресов, удаленный
пользователь не получит IP-адрес офисного режима.
[True]. Если IP удаленного хоста не найден в диапазоне исходных адресов, удаленный пользователь
получит IP-адрес офисного режима другим методом.
[False] (по умолчанию). Флаг не применяется.
Группу «IP per user/group», чтобы конкретный пользователь или группа пользователей получали один и
тот же адрес офисного режима. Это дает возможность администратору присваивать пользователям при
подключении с использованием офисного режима конкретные адреса или группам – конкретные
диапазоны/сети.
Другой сервер WINS для отдельного пользователя или группы.
Другой сервер DNS.
Другие доменные суффиксы DNS для каждой записи в файле.
Проверка синтаксиса
Синтаксис файла ipassignment можно проверить командой ipafila_check.
Из командной строки выполните: vpn ipafile_check ipassignment.conf
Существует два параметра:
warn. Отображение ошибок.
detail. Демонстрация подробностей.
Например:
1. При выбранном режиме DHCP параметры DNS и WINS загружаются с сервера DHCP. При использовании
офисного режима с DHCP и желании передать пользователю информацию о DNS и/или WINS, убедитесь,
что на вашем сервере DHCP DNS и WINS настроены на правильные IP-адреса.
2. В конфигурации сервера DHCP убедитесь, что вы обозначили адресное пространство для пользователей
офисного режима (напр., 10.130.56.0).
3. Создайте новый узел, выбрав Управление > Сетевые объекты > Новый > Узел > Хост,
представляющий сервер DHCP, и задайте имя машины, IP-адрес и маску подсети.
4. Откройте объект «шлюз безопасности», через который удаленные пользователи будут подключаться ко
внутренней сети, и выберите страницу VPN IPSec > Офисный режим. Включите офисный режим для
всех пользователей или для определенной группы.
Отметьте опцию Автоматически (использовать DHCP).
Выберите ранее созданный объект DHCP.
В поле Виртуальный IP-адрес для ответа сервера DHCP (Virtual IP address for DHCP server
replies) укажите IP-адрес из подсети IP-адресов, предназначенных для офисного режима (напр.,
10.130.56.254). Поскольку офисный режим поддерживает метод задержки DHCP для присвоения IP,
сервер DHCP можно направить туда, куда он должен отправлять свои ответы. Маршрутизация
сервера DHCP и внутренних маршрутизаторов должна быть налажена таким образом, чтобы пакеты
от сервера DHCP на этот адрес направлялись через шлюз безопасности.
Если вы хотите использовать антиспуфинг, переходите к шагу 5, иначе – к шагу 7.
Генерирование пакета
В данном пункте описано, как сгенерировать пакет SecureClient согласно настройкам, определенным в
профиле пакета.
Подготовка
Если вы еще не подготовили базовый пакет, выполните следующие действия.
1. Получите первоначальный установочный пакет SecureClient. На базе этого пакета Packaging Tool создаст
новый пользовательский пакет SecureClient.
2. Скопируйте чистый пакет SecureClient в пустую папку. Если пакет заархивирован в формате ZIP или TAR,
его следует распаковать в пустую папку.
Имея базовый пакет, сделайте следующее.
1. Запустите мастер генерирования пакета SecureClient. Это можно сделать немедленно после создания
нового профиля пакета (выбрав Да, создать профиль и сгенерировать пакет) или из главного окна
средства упаковки, подсветив созданный ранее профиль и выбрав Профиль > Генерировать.
2. Вам предложат задать исходную и целевую папки пакета.
В поле Исходная папка пакета укажите папку, в которой находится первоначальная установка
SecureClient, подготовленная вами на шаге 2. Убедитесь, что это именно та папка, в которой уже лежат
файлы установки SecureClient, а не ее материнская папка.
В поле Целевая папка пакета и имя файла укажите пустую папку, в которую будет скопирован готовый
пакет, и введите имя для генерируемого файла.
Нажмите Далее, чтобы перейти к следующему окну.
3. Если из пакета невозможно извлечь подробности (тип операционной системы, версия SecureClient,
сервисный пакет) невозможно извлечь из пакета, введите их при запросе. Если параметры пакета
конфликтуют с другим пакетом, вам будет предложено подтвердить замену старого пакета новым.
Средство упаковки выполнит запрошенные вами действия
product.ini
userc.c
userc.set
reg.ini
SecuRemoteAuthenticate.wav
SecuRemoteConnected.wav
SecuRemoteDisconnected.wav
SecuRemoteFailed.wav
logo.bmp
logging.bat
install_boot_policy.bat
collect.bat
scvins.bat
scvuins.bat
msfw.bat
harden.bat
Параметр Описание
/i pkg_name Установить
/x pkg_name Удалить
/q Автоматическая установка
Раздельная установка
Задействование
1. В файле product.ini установите SplitKernelInstall=0.
2. Установите продукт, кроме ядра.
3. Произойдет автоматическая перезагрузка, инициированная конечным пользователем.
4. После перезагрузки идет самостоятельная установка ядра.
5. Вторая автоматическая перезагрузка.
Отладка
Для отладки установки MSI выполните /l*v log_file_name_parameter. log_file_name и install_securemote.elg
используются при поиске и устранении неисправности.
Настройка на сервере
1. Установите дополнительный модуль Сервер политики с установочного DVD Check Point. Дополнение
Сервер политики должно устанавливаться только на машины, на которых установлены шлюзы
безопасности.
2. Откройте объект «шлюз безопасности», на который вы установили Сервер политики, и выберите вкладку
Общие свойства. В разделе Продукты Check Point выберите Сервер политики SecureClient.
3. Перейдите на вкладку Аутентификация. В разделе Сервер политики > Пользователи выберите группу
пользователей, которым разрешено заимствовать политики с данного сервера политики.
4. Повторите шаги 2 и 3 для каждого дополнительного сервера.
5. Перейдите на Политика > Глобальные свойства и выберите вкладку Удаленный доступ. В поле
Возвращаться к политике по умолчанию через (Revert to default policy after) введите тайм-аут для
политик безопасности настольных систем (см. Обновление политики).
6. В панели выбора политики выберите Безопасность настольных систем (Desktop Security).
7. Настройте правила входящего трафика. При помощи пункта меню Правила > Добавить правило можно
добавлять правила в политику.
В правилах для входящего трафика SecureClient (настольный компьютер) служит адресатом, и вы можете
указать пользователей, к которым применимо это правило.
8. Настройте правила исходящего трафика.
В правилах для исходящего трафика SecureClient (настольный компьютер) служит источником, и вы
можете указать пользователей, к которым применимо это правило.
9. Установите политику. Установке подлежат как политика Advanced Security на шлюзах безопасности, так и
Desktop Security – на серверах политики.
Не зашифрован Интернет
Шлюз безопасности Удаленный IPSec клиент
Процесс установления VPN для пользователя незаметен. Схема его работы описана ниже.
1. Пользователь клиента Microsoft IPSec/L2TP инициирует соединение с шлюзом безопасности.
2. Клиент Microsoft IPSec/L2TP начинает согласование IKE (обмен Интернет-ключами) с противоположным
шлюзом безопасности, чтобы начать построение зашифрованного туннеля.
3. Во время согласования IKE идет проверка идентификаторов машины удаленного клиента и шлюза
безопасности. Эта проверка подлинности выполняется с помощью сертификатов. Обе стороны
отправляют друг другу сертификаты, как средство подтверждения своей подлинности. Так
обеспечивается формирование соединения только между аутентифицированными машинами.
4. Оба узла обмениваются ключами шифрования, на этом согласование IKE прекращается.
5. Теперь между клиентом и шлюзом безопасности устанавливается зашифрованное соединение. Все
соединения между клиентом и шлюзом безопасности шифруются внутри этого VPN-туннеля с
использованием стандарта IPSec.
6. Клиент начинает короткое согласование L2TP, по окончании которого клиент может передать шлюзу
безопасности L2TP-кадры, зашифрованные и инкапсулированные IPSec.
7. Шлюз безопасности аутентифицирует пользователя клиента Microsoft IPSec/L2TP. Эта аутентификация
служит дополнением к проверке машины клиента на шаге 3. Идентификация может происходить двумя
способами:
посредством сертификата;
MD5-вызов, когда пользователю предлагается ввести имя пользователя и пароль (общий секретный
ключ).
8. Шлюз безопасности выдает удаленному клиенту IP-адрес офисного режима, чтобы клиент стал
маршрутизируемым для внутренней сети. Адрес может быть получен любым методом для офисного
режима.
9. Клиент Microsoft IPSec/L2TP соединяется со шлюзом безопасности и может просматривать и
подключаться к разным узлам локальной сети.
Сертификаты
В ходе установления L2TP-соединения выполняется два акта аутентификации. Первый: клиентская машина
и шлюз безопасности проверяют подлинность друг друга с помощью сертификатов. Затем, пользователь
клиентской машины и шлюз безопасности проверяют друг друга либо с помощью сертификатов, либо с
помощью общего секретного ключа.
У клиента Microsoft IPSec/L2TP отдельно находятся сертификаты для аутентификации IKE клиентской
машины и аутентификации пользователя.
Аутентификация пользователя
Соединение с клиентами Microsoft IPSec/L2TP требует аутентификации каждого пользователя.
Аутентификация пользователей возможна посредством:
сертификатов или
MD5-вызовов, когда пользователю предлагается ввести имя и пароль (общий секретный ключ). Пароль
сообщается пользователю за пределами канала связи.
Сертификат пользователя легко добавляется в хранилище сертификатов пользователя. Если сертификат
пользователя содержится на смарт-карте, то вставка последней в машину клиента автоматически
располагает сертификат в хранилище.
Установление L2TP-соединения
1. Нажмите Подключить, чтобы установить L2TP-соединение.
2. Для просмотра IP-адреса, присвоенного соединению, взгляните на вкладку Подробности (Details) в окне
Состояние подключения, либо воспользуйтесь командой ipconfig /all.
Дополнительная информация
Подробнее о настройке дополнительных свойства клиентов Microsoft IPSec/L2TP можно прочитать в
следующих пунктах.
1. Нечастные IP-адреса клиентов (на стр. 250).
2. Включение функции «IP-адрес для пользователя» (на стр. 190).
3. Обратные соединения (от сервера к клиенту) (на стр. 251).
Протокол L2TP определен в RFC 2661. Шифрование L2TP с помощью IPSec описано в RFC 3193. Подробнее
о протоколе L2TP и клиенте Microsoft IPSec/L2TP см. раздел помощи «Сеть и удаленный доступ к сети»
Windows 2000 и ХР.
Даже правильно настроенная политика безопасности настольных систем, важная сама по себе, не
гарантирует защиты от такого типа атаки, поскольку атака не нацелена на уязвимость в контроле доступа
машины пользователя, а использует уязвимую конфигурацию приложений клиента.
SCV – это платформа для создания и использования проверок SCV. Проверки SCV – это набор условий,
определяющих безопасность конфигурации клиентской системы – настройки браузера пользователя, текущая
версия антивирусного ПО, установленного на компьютере, надлежащая работа политики личного
брандмауэра и т. д. Эти проверки безопасности выполняются SecureClient через заранее заданные
VPN с удаленным доступом
интервалы времени. В зависимости от результатов проверки SCV шлюз безопасности принимает решение о
разрешении или блокировании связи между клиентом и локальной сетью.
Решение SCV от Check Point имеет в своем наборе ряд предварительно настроенных проверок операционной
системы и браузера пользователя. Оно также позволяет OPSEC-партнерам, например, производителям
антивирусного ПО, добавлять SCV-проверки для собственных продуктов.
Первым шагом в настройке SCV является установка администратором приложений, обеспечивающих SCV-
проверки у клиента. Во время установки приложения регистрируются как плагины SCV и записывают
значение хэш в свои DLL, чтобы избежать несанкционированного вмешательства.
Политика SCV – это свод правил или условий, основанных на проверках, выполняемых плагинами SCV. Эти
условия определяют требуемый результат каждой SCV-проверки; на основе этих результатов клиент
классифицируется как безопасно настроенный или небезопасно настроенный. Например, если
администратор хочет запретить приложения, выполняющие обмен файлами, должен определить в SCV-
политике правило, удостоверяющееся в отсутствии запущенных процессов приложений, предусматривающих
обмен файлами.
Если все проверки SCV возвращают требуемый результат, клиент считается настроенным безопасно. Если
хоть одна проверка возвращает неожиданный результат, клиент считается настроенным небезопасно.
Администратор может по собственной воле навязать SCV удаленным клиентам. В этом случае только
безопасно настроенные клиенты смогут удовлетворить правилам доступа. Если не вводить принудительных
проверок SCV, то через это правило пройдут все клиенты.
В упрощенном режиме это глобальная настройка. В традиционном режиме такая настройка выполняется
индивидуально для каждого правила. Подробнее см. «Настройки со стороны сервера» (на стр. 219).
Если клиент настроен небезопасно, шлюз безопасности либо отбрасывает соединение, либо принимает и
регистрирует в журнале (поведение в этом случае настраивается).
Если шлюз безопасности не знает SCV-статуса клиента, он инициирует проверку SCV, отправляя ICMP-
сообщение о недостижимой ошибке, содержащее SCV-запрос клиенту. Когда клиент получает этот SCV-
запрос, он пытается определить свой SCV-статус. В режиме соединения клиент еще и соединяется с
сервером политики, чтобы загрузить обновленную SCV-политику. Параллельно, после получения SCV-
запроса клиент начинает каждые 20 секунд отправлять ответные сообщения с SCV-статусом на шлюз
безопасности через UDP порт 18233 – это длится в течение 5 минут. Эти ответы используются как механизм
поддержки активности соединения с пользователем в таблицах состояния шлюза безопасности, пока клиент
пытается определить свой SCV-статус. Для поддержания активности пакетов также позвольте пользователю
открывать последующие соединения в пределах 5-минутного периода без необходимости дальнейших SCV-
запросов. После определения своего SCV-статуса клиент отправляет соответствующий ответ на шлюз
безопасности через UDP порт 18233. По получении сообщения с SCV-статусом от пользователя шлюз
безопасности принимает решение о соединении с пользователем.
SCV-проверки
SCV-проверки Check Point
При установке SecureClient к вашим услугам предоставляется ряд SCV-проверок.
Сторонние SCV-проверки
SCV-проверки могут создаваться сторонними вендорами с использованием OPSEC SCV SDK Check Point.
После установки этих приложений администратор может задействовать эти SCV-проверки в политике SCV.
Особенности SCV
В следующих пунктах описаны аспекты, которые важно знать перед настройкой SCV.
Привилегии пользователей
Для эффективного внедрения SCV предлагается рассмотреть возможность не предоставлять удаленным
пользователям административные права на их компьютерах. Предоставляя пользователям привилегии
администратора, вы позволяете им изменять системные настройки, что вызовет непрохождение проверок
SCV. Компьютер, не прошедший проверки SCV, рискует оказаться потенциальной угрозой для организации.
Например, на правах администратора вы можете захотеть, чтобы браузер пользователя не разрешал с веб-
сайтов ему загружать Java-приложения. Обычный пользователь не сможет загружать эти приложения, но
пользователь с правами администратора легко изменит настройки браузера. Правильно настроенная
политика SCV может показать, что настройки браузера были изменены, и вызвать соответствующее действие
со стороны шлюза безопасности. Впрочем, если пользователю шлюзом безопасности разрешено получать
доступ к локальной сети – то ли в силу неверной настройки политики SCV, то ли по причине незнания шлюзом
безопасности SCV-статуса пользователя, - компьютер пользователя становится потенциальной угрозой
безопасности сети.
Сама по себе политика SCV защищена. Пользователи не могут менять определяющие файлы политики SCV,
которые они получают, даже имея права администратора. Файлы политики SCV, передаваемые клиенту,
перед прибытием к адресату подписываются и эта подпись проверяется SecureClient. Если подписи не
совпадают, проверка SCV считается безуспешной.
Настройка SCV
Настройка SCV включает в себя указание параметров на сервере, со стороны клиента и настройку политики
SCV.
При неудачной проверке (Upon Verification failure). Определяет действие, которое следует
выполнить, если одна или несколько SCV-проверок клиента провалились. Варианты таковы:
заблокировать соединение с клиентом или принять его, отослав соответствующую журнальную
запись о событии.
3. Если вы используете упрощенный режим (поддерживающий VPN-сообщества), пропустите этот шаг. Если
вы используете традиционный режим, исправьте базу правил политики безопасности и добавьте к
правилам удаленного доступа SCV-проверки (правила Client Encrypt и Client Auth). Для задействования
SCV в правиле удаленного доступа щелкните правой кнопкой по вкладке действий правила и выберите
Изменить свойства > Применить правило только если проверена настройка компьютера (Edit
properties > Apply rule Only if Desktop Configuration is Verified). Закройте экран свойств, нажав ОК.
4. Измените файл local.scv в папке $FWDIR/conf и настройте политику SCV. Подробнее см. «Синтаксис
политики SCV» (на стр. 219) и «Группы local.scv» (на стр. 219).
2. Запустите SecureClient и подключитесь к шлюзу безопасности, чтобы получить политику SCV. Подробнее
см. «Безопасность настольных систем».
Группы и подгруппы
Каждая группа (set) имеет предопределенное для нее назначение. Например, одна группа может
использоваться для задания определенных параметров, другая – для указания действий, которые
необходимо выполнить при наступлении конкретного события и т. д. Группы отличаются названиями и
рекурсивной иерархией. У каждой группы могут быть подгруппы (sub-set), у каждой подгруппы могут быть свои
подгруппы и так далее. Подгруппы могут содержать логические выражения. Группы и подгруппы, имеющие
несколько подгрупп/условий, отделяются левой и правой скобкой () и начинаются с названия
группы/подгруппы. Различие между группами/выражениями с той же иерархией осуществляется при помощи
двоеточий : . Например:
В приведенном примере группа, названная SetName, имеет две подгруппы SubSetName1 и SubSetName2. У
SubSetName1 два условия (ExpressionName1_1 и ExpressionName1_2). У SubSetName2 одно условие
(ExpressionName2_1) и одна подгруппа (SubSetName2_1). Внутри SubSetName2_1 содержится одно условие
(ExpressionName2_1_1).
Выражения
Выражения вычисляются путем проверки значения выражения (которое соответствует проверке SCV) и его
сравнения со значением, определенным для этого выражения (значение в скобках). Например, для SCV-
проверки с целью мониторинга браузера при помощи SecureClient можно указать следующее выражение:
:browser_major_version (5)
Выражение проверяет, является ли версия Internet Explorer, установленная на клиенте, версией 5.х. Если
основной номер версии 5, выражение имеет значение true, в противном случае – false. Название выражения
(напр., «browser_major_version») определяется SCV-приложением и дается производителем.
Если одно за другим следуют несколько выражений, они логически умножаются, т. е., общее их значение
будет true только тогда, когда все выражения имеют значение true. В противном случае (если хотя бы одно
выражение имеет значение false) общее значение будет false. Например,
:browser_major_version (5)
:browser_minor_version (0)
Эти выражения логически умножаются. Если основной номер версии Internet Explorer 5 И дополнительный
номер 0 (т. е., версия 5.0), тогда результат true. Если версия Internet Explorer, к примеру, 4.0, то первое
выражение будет false, а второе – true, в результате они дадут нам false.
Иногда некоторые выражения могут влиять на способ подсчета других выражений. Например,
:browser_major_version (5)
:browser_minor_version (0)
:browser_version_operand (">=")
Эти выражения логически умножаются, однако, третье выражение влияет на то, как подсчитываются первое и
второе. В приведенном выше примере, если версия Internet Explorer больше или равна (≥) 5.0, то результат
будет true, в противном случае – false. Если версия Internet Explorer 4.5, результат будет false, а если 5.1 или
выше – тогда true.
Логические разделы
Как упоминалось ранее, идущие друг за другом выражения автоматически подвергаются логическому
умножению. Однако, иногда между выражениями вместо логического И необходимо поставить логическое
ИЛИ. Для этого используются ярлыки.
Ярлык begin_or (orX) начинает раздел, содержащий несколько выражений. Конец раздела помечается
ярлыком end (orX) (вместо X ставится число, позволяющие отличать между собой разные OR-разделы). Все
выражения внутри этого раздела логически складываются, возвращая единое значение для всего раздела.
Например:
:begin_or(or1)
:browser_major_version (5)
:browser_major_version (6)
:end(or1)
Этот раздел проверяет, чтобы версия Internet Explorer была 5 ИЛИ 6 – если это так, результат true, иначе –
false.
Ярлык begin_and (andX) очень похож на ярлык begin_or (orX), однако, выражения внутри него
подсчитываются и логически умножаются. Конец такого раздела обозначается ярлыком end (andX) или end
(orX). Как упоминалось ранее, выражения, просто идущее одно за другим, логически умножаются. Этот ярлык
нужен для того, чтобы помещать вложенные AND-разделы в OR-разделы. Например, если администратор
считает старые браузеры безопасными, поскольку в них мало опасных компонентов, а новые браузеры –
поскольку они содержат последние обновления безопасности, то он может определить такие правила SCV:
:begin_or (or1)
:begin_and (and1)
:browser_major_version (5)
:browser_minor_version (0)
:browser_version_operand (">=")
:end (and1)
:begin_and (and2)
:browser_major_version (3)
:browser_minor_version (0)
:browser_version_operand ("<=")
:end (and2)
:end (or1)
В приведенном выше примере первый AND-раздел проверяет, чтобы версия IE была ≥5.0, второй AND-
раздел проверяет, чтобы версия IE была ≤3.0, а вместе они логически складываются. Весь пример принимает
значение true только тогда, если версия IE больше или равна 5.0 ИЛИ меньше или равна 3.0.
send_log (type). Это выражение используется как часть раздела begin_admin (admin) – end (admin) и
определяет, отсылать ли журнал событий на Сервер управления защитой (и средство диагностики
клиента) с пометкой о том, что клиент не прошел SCV-проверку.
Слово type заменяется типом отсылаемого журнала – log или alert. Alert обозначает отсылку журнала на
Сервер управления защитой, а log – отсылку журнала на удаленное средство диагностики клиента).
mismatchmessage (“Message”). Это выражение используется как часть раздела begin_admin (admin) –
end (admin) и определяет отображение на экране удаленного пользователя всплывающего сообщения с
описанием проблемы. Текст в прямых кавычках (Message) заменяется осмысленной фразой, которая
инструктирует клиента о возможных источниках проблемы и действиях, которые нужно предпринять.
Например:
:browser_major_version (5)
:browser_minor_version (0)
:browser_version_operand (">=")
:begin_admin (admin)
:send_log (alert)
:mismatchmessage ("The version of your Internet Explorer
browser is old. For security reasons, users with old
browsers are not allowed to access the local area
network of the organization. Please upgrade your
Internet Explorer to version 5.0 or higher. If you
require assistance in upgrading or additional
information on the subject, please contact your network
administrator")
:end (admin)
В этом примере, если версия браузера IE пользователя меньше 5.0, на Сервер управления защитой
отправляется сигнал, а пользователю отображается всплывающее сообщение с описанием проблемы.
Группы local.scv
Файл политики local.scv содержит одну группу, которая называется SCVObject. Эта группа всегда должна
присутствовать, она содержит все подгруппы, имеющие отношение к SCV-проверкам и параметрам. На
данный момент у группы SCVObject 3 подгруппы.
SCVNames. Этот раздел является основным разделом определения политики SCV, в котором
определяются все SCV-проверки и действия. Это определяющая часть политики SCV, она не
обуславливает напрямую, какие SCV-проверки будут выполняться. В дальнейшем администратор из этих
групп выбирает те, которые желает выполнить на компьютере пользователя.
SCVPolicy. Этот раздел задает названия SCV-проверок, определенных в разделе SCVNames, которые
следует фактически выполнить на клиентской машине.
SCVGlobalParams. В этом разделе содержатся глобальные параметры SCV.
SCVNames
В этом разделе администратор указывает имена и различные проверки продуктов SCV. Вот общее
определение подгруппы SCV-проверки SCVNames:
: (SCVCheckName1
:type (plugin)
:parameters (
:Expression1 (value)
:Expression2 (value)
:begin_admin (admin)
:send_log (alert)
:mismatchmessage ("Failure Message")
:end (admin)
)
)
SCVPolicy
Этот раздел определяет имена SCV-проверок, подлежащих осуществлению (имена являются частью
названий SCV-проверок, заданных в SCVnames). Общая структура раздела такова:
:SCVPolicy (
:(SCVCheckName1)
:(SCVCheckName2)
)
SCVGlobalParams
:SCVGlobalParams (
:enable_status_notifications (