Этот раздел показывает, как сформировать правила для стратегии защиты CheckPoint FireWall–1 в сети с простой конфигурацией, используя стратегию "диода", и затем расширить ее до масштабов крупного предприятия с использованием более детальной конфигурации.
Следующий пример демонстрирует, как можно развернуть CheckPoint FireWall–1 в конфигурации сети, изображенной на рисунке. Обратите внимание, что это - не рекомендуемая конфигурация, а просто пример для иллюстрации возможностей продукта в рамках данного документа.
Рис. 4 Пример конфигурации простой сети
В этом примере CheckPoint FireWall–1 будет установлен на шлюзе (именуемом в приведенных ниже правилах как monk).
Для показанной выше конфигурации, типичная стратегия защиты могла бы быть такой:
Эта стратегия защищает частную сеть от доступа извне, но не накладывает никаких ограничений на функционирование компьютеров внутренней сети.
Сначала рассмотрим, как данная стратегия защиты может быть выполнена в CheckPoint FireWall–1. Затем проследим, как эта стратегия защиты может быть "ужесточена", "обрезая" и блокируя потенциальные "обходы".
Чтобы реализовать политику безопасности, необходимо выполнить следующие действия:
Следующий шаг в реализации стратегии защиты - создать базу правил с использованием редактора. В редакторе базы правил правила выражены в терминах следующих элементов:
Первые четыре элемента описывают попытку соединения:
Источник - откуда соединение исходит
Назначение - куда соединение направлено
Сервис - тип приложения
Время - время суток начала соединения (новое в версии 3.0)
Обратите внимание: если Вы ставите параметр "Any" в графе источника или адресата, все TCP , UDP и RPC приложения, даже те, что не определены в диспетчере сервисов, будут разрешены. Даже если используется неизвестное приложение базы данных, CheckPoint FireWall–1 защищает выходной трафик и гарантирует, что будут пропущены ответы, но ничто больше.
Следующие два элемента указывают на то, что должно быть выполнено:
Действие - что должно быть сделано с данным соединением
Регистрация - регистрировать пакет или выдать сигнал тревоги
Последний элемент указывает, на какой модуль FireWall будет установлено правило, определенное первыми пятью элементами:
Установить на - FireWall Module, который будет обеспечивать выполнение правила
В этом простом примере имеются только два правила в соответствии со стратегией, изложенной выше.
Первое правило (внешние сети могут посылать только почту на почтовый сервер) может быть выражено в редакторе правил следующим образом:
| Source | Destination | Services | Action | Track | Install On |
| Any | mailsrvr | smtp | Accept | Short Log | Gateways |
Второе правило (локальные компьютеры могут обращаться ко всей сети: localnet и Internet) отражается в редакторе правил следующим образом:
| Source | Destination | Services | Action | Track | Install On |
| localnet | Any | Any | Accept | Short Log | Gateways |
Рис. 5 Окно редактора базы правил показывающее два первых правила
CheckPoint FireWall-1 руководствуется принципом “Что явно не разрешено, то Запрещено”. Для воплощения этого принципа, CheckPoint FireWall-1 неявно добавляет еще одно правило в конец базы правил, запрещающее все попытки связи, не описанные другими правилами.
Так как правила применяются последовательно к каждому пакету, только пакеты, не описанные первыми двумя правилами, инспектируются последней строкой. Однако, если полагаться на это неявное правило, запрещающее все пакеты, то они не будут регистрироваться потому, что регистрироваться могут только пакеты, определенные явным правилом. Чтобы регистрировать эти пакеты, необходимо явно определить правило типа "ни один из вышеупомянутых" следующим образом:
| Source | Destination | Services | Action | Track | Install On |
| Any | Any | Any | Reject | Long Log | Gateways |
Если явно не определять такое правило, CheckPoint FireWall-1 неявно определит его сам, и пакеты будут уничтожены. CheckPoint FireWall-1 ни в коем случае не допустит прохождения нераспознанных пакетов. Преимуществами явного определения подобного правила является:
Рис. 6 Полная база правил
Правила, описанные выше, имеют недостаток - они предоставляют компьютерам локальной сети доступ к ресурсам Gateway (подразумевается, что они зарегистрированы на Unix-системе). Обычно такая ситуация нежелательна. Чтобы предотвратить доступ с любого компьютера (не только с локального) к Gateway, необходимо добавить правило (предшествующее остальным) следующим образом:
| Source | Destination | Services | Action | Track | Install On |
| Any | monk | Any | Reject | Long Log | Gateways |
Защита Gateway подобным способом, делает его недоступным другим пользователям и приложениям (кроме консоли управления CheckPoint FireWall–1). Gateway становится невидимым сетевым объектом как для клиентов сети, так и за ее пределами.
Рис. 7 Окно редактора базы правил с правилом, защищающим gateway
Можно проверить, что Gateway действительно недоступен, выполняя следующий эксперимент (после того, как Вы установили базу правил). Попробуйте воспользоваться командой TELNET для обращения во внешнюю сеть через Gateway и затем обратно на Gateway. Второй TELNET потерпит неудачу.
Замечание - необходимо сознавать, что команда ping на Gateway извне будет проходить потому, что прохождение ICMP протокола разрешено по умолчанию как первое правило в окне Properties/Security Policy.
Обратите внимание: иконки, представляющие сетевые объекты, передают полную информацию о том, как система FireWall-1 будет эти объекты обрабатывать. В данном случае Gateways походит на ворота для пропуска информации, а кирпичная кладка внутри иконок указывает, что объект будет подвергнут фильтрации.
Чтобы сильнее защитить Gateway, можно добавить следующее правило, которое будет изымать любой пакет, порождаемый на Gateway:
| Source | Destination | Services | Action | Track | Install On |
| monk | Any | Any | Reject | Long Log | Source |
Поле Install On в этом правиле определено как Source потому, что по умолчанию Gateway устанавливает правила только на входящий трафик. Правило определено для компьютера с именем monk, но так как monk определен как Source, правило действует только на выходящий трафик (правило применяется только к пакетам, порождаемым и отправляемым с компьютера monk). Если бы поле Install On было бы определено как Gateway, правило применялось бы только к пакетам приходящим на monk и одновременно порожденным на нем. Другими словами, ни к каким пакетам вообще.
Рассмотрим следующую конфигурацию:
Рис. 8 Пример конфигурации сети
Эта конфигурация подобна первой, за исключением того, что добавлен общий сервер (DMZ - демилитаризованная зона). DMZ обеспечивает HTTP, FTP и другие услуги для глобальной сети, но не является инициатором никакого трафика. DMZ - фактически третий интерфейс, присоединенный к Gateway, и может быть сетью, подсетью или отдельной машиной.
Стратегия защиты для этой конфигурации аналогична стратегии защиты, рассмотренной в предыдущем примере, но содержит дополнительное правило. Это правило обеспечивает доступ по FTP и HTTP к DMZ из Internet.
| Source | Destination | Services | Action | Track | Install On |
| Any | DMZ | HTTP, FTP | Accept | Short Log | Gateways |
Рис. 9 База правил с добавленной DMZ
Обратите внимание, что в поле Install On можно определять сетевой объект по имени или функцией.
Таблица 4 Install On
| Install On | Meaning |
|
Устанавливаются на всех сетевых объектах, определенных как gateway в направлении, определяемом свойством "Apply Gateway Rules to Interface Direction" в окне Control Properties/Security Policy. |
|
Устанавливаются на входе защищенных сетевых объектов, определенных в этом правиле как Destination (обычно серверы). |
|
Устанавливаются на выходе защищенных сетевых объектов, определенных в этом правиле как Source (обычно клиенты - инициаторы трафика). |
|
Устанавливается на соответствующих интерфейсах всех маршрутизаторов. |
| Specific target | Устанавливается только на указанном обьекте, во входном и выходном направлениях. |
Если указано Gateway, то правило действует на компьютерах, определенных как шлюз (в окне Host Properties). Правило применимо ко всем пакетам, идущим в направлении, определенном в свойствах "Apply Gateway Rules to Interface Direction" в окне Control Properties/Security Policy.
Если указано Routers, то правило устанавливается на соответствующих интерфейсах на всех маршрутизаторах, используя возможность автообзора FireWall-1. CheckPoint FireWall-1 генерирует Списки Доступа для маршрутизаторов. Нужно отметить, что только со списками доступа можно реализовать лишь неполное подмножество функциональности модуля FireWall-1. Например, невозможно создавать защищенные соединения FTP как описано в "Исходящие соединения FTP".
Если объект указан по имени, правило проверяется как для входящих, так и для выходящих пакетов.
Замечание - если все модули защиты установлены на Gateway, то потребность в списках доступа на маршрутизаторах отсутствует. Маршрутизаторы, как уже было сказано, являются менее защищенными и ограничивают возможность регистрации и предупреждения чрезвычайных ситуаций, поэтому рекомендуется оставлять их открытыми и реализовывать стратегию защиты на других сетевых объектах.
После успешной аутентификации, привилегии доступа определяются индивидуальными свойствами объекта пользователя, как определено в окне свойств пользователя.
Рис. 10 Методы аутентификации для пользователя
Эти свойства включают дозволенные источники, назначения и времена суток.
Рис. 11 Разрешенные пользователю источники и назначения
Рис. 12 Разрешенное пользователю время
Spoofing - методика, где "злоумышленник" пытается получить несанкционированный доступ, изменяя содержимое IP-пакета нестандартными средствами. В результате такой пакет появляется, как если бы он был инициирован в сети с более высокими привилегиями доступа. Например, пакет из Internet может быть замаскирован под пакет из локальной сети. Если такой пакет не обнаружить, то он сможет получить неограниченный доступ к локальной сети.
FireWall-1 имеет изощренные средства для локализации подобных действий. Эти средства требуют, чтобы пакет, приходящий на соответствующий интерфейс, удовлетворял некоторым требованиям, в частности, имел тот же адрес источника, что и адрес интерфейса. Например, при возникновении подобной ситуации FireWall–1 идентифицирует пакет, приходящий из Internet и содержащий локальный IP адрес, изымает его и выдает тревогу. Этот тип "antispoofing" защиты может быть достигнут только при использовании интегрированной системы типа FireWall–1, так как данная система имеет доступ как к интерфейсу, через который пакет прибыл, так и к содержимому уровня IP пакета, а также знает все о топологии внутренней сети и умеет регистрировать подобные события и выдавать предупреждения.
Рис. 13 Включенное средство отслеживания Spoofing-а
Свойство "Antispoofing" определяется в окне свойств сетевого объекта, который будет реализовывать данное правило. Например, если Gateway должен обеспечить "antispoofing", то необходимые параметры определяются в окне свойств Gateway компьютера (рис. 14). Аналогично, параметры spoof-трэкинга маршрутизатора определены в окне свойств интерфейса маршрутизатора (рис. 13).
Рис. 14 Окно свойств хоста (OpenLook GUI)
FireWall-1 позволяет записывать полную информацию о происходящих событиях (пропущенных и задержанных пакетах) в файл регистрации. Средство просмотра файла регистрации FireWall–1 предоставляет возможность просматривать файл регистрации с помощью различных фильтров и контекстного поиска для быстрого и эффективного извлечения необходимой информации. Вы можете задать оповещение администратора когда FireWall-1 уничтожает или пропускает заданный пакет.
Сообщение может передаваться разными способами. В виде сообщения на центральную консоль, в виде почтового сообщения на один из предопределенных адресов или в виде Trap (сообщения о событиях) протокола SNMP.
Фактически, можно определить любую команду OS, которая будет выполнена в случае возникновения нештатной ситуации. Все предупреждения также регистрируются в журнале.
Дополнительно Вы можете выбрать режим просмотра записей журнала регистрации работы или активных соединений, сделав соответствующий выбор в "Drop down" списке в панели инструментов средства просмотра log-файла.
Рис. 15 Выбор типа отображаемых записей в средстве просмотра файла рагистрации
При инсталляции базы правил, чтобы привести ее в действие FireWall-1 проверяет ее на логичность и непротиворечивость, затем генерирует и загружает Инспекционный Код в каждый из заданных модулей FireWall. Если сетевой объект - маршрутизатор, FireWall-1 генерирует и устанавливает на него соответствующий Список Доступа, а не Инспекционный Код.
Стратегия защиты определена не только Базой Правил, но и параметрами в окне Control Properties/Security Policy.
Рис. 16 Окно установки свойств - политика безопасности
Эти параметры дают возможность пользователю управлять общими аспектами проверки пакетов и в то же самое время освобождают пользователя от необходимости определять рутинные подробности в редакторе базы правил.
