Этот раздел показывает, как сформировать Правила для стратегии защиты CheckPoint FireWallЦ1 в сети с простой конфигурацией, и затем расширить ее до масштабов крупного предприятия.
Следующий пример демонстрирует, как можно развернуть CheckPoint FireWallЦ1 в сетевой конфигурации. Обратите внимание, что это - не рекомендуемая конфигурация, а просто пример для иллюстрации возможностей продукта.
Рисунок 1. Конфигурация Простой Сети.
В этом примере, CheckPoint FireWallЦ1 будет установлен на шлюзе (именуемом "монах").
Для конфигурации на рис 1. типичная стратегия защиты могла бы быть:
Эта стратегия защищает частную сеть от доступа извне, но не накладывает никаких ограничений на функционирование компьютеров внутренней сети.
Сначала рассмотрим, как данная стратегия защиты может быть выполнена в CheckPoint FireWallЦ1. Затем проследим, как эта стратегия защиты может видоизменяться, "обрезая" и блокируя потенциальные "обходы".
Чтобы реализовать стратегию защиты, необходимо выполнить следующие действия:
Нет необходимости определять всю сеть для CheckPoint FireWallЦ1 - только те объекты, которые используются в Правилах. Для конфигурации, описанной на рис 1., необходимо определить Gateway (монах), почтовый сервер (mailsrvr) и локальную сеть (localnet).
Нет необходимости определять обычные сетевые услуги. Они уже имеются в CheckPoint FireWallЦ1. Определяются только те специальные услуги, которые являются частью вашей стратегии защиты.
Определение сетевых объектов и услуг не представляет сложности. В большинстве случаев, необходимо только определить имя, так как CheckPoint FireWallЦ1 может получить параметры объекта из соответствующего файла, базы NIS+ или базы данных DNS.
Следующий шаг в реализации стратегии защиты - создать Базу Правил с использованием редактора. В редакторе Базы Правил правила выражены в терминах следующих элементов:
первые три элемента описывают попытку связи.
Источник — Откуда пакет исходит
Адресат — Куда пакет идет
Сервис —Тип приложения
Обратите внимание:Если Вы ставите параметр "Любой" в графе источника или адресата, все TCP , UDP и RPC приложения, даже те, что не определены в Диспетчере Сервисов, будут разрешены. Даже если используется неизвестное приложение базы данных, CheckPoint FireWallЦ1 защищает выходной трафик и гарантирует, что будут пропущены ответы, но ничто больше.
Следующие два элемента указывают на то, что должно быть выполнено.
Действие— Что должно быть выполнено в данном сеансе связи
Регистрация —Регистрировать пакет или выдать сигнал тревоги
Последний элемент указывает, на какой модуль FireWall будет установлено правило, определенное первыми пятью элементами.
Установить на — FireWall модуль, который будет обрабатывать это правило
В этом простом примере имеются только два правила в соответствии со стратегией, изложенной выше.
Первое правило (внешние сети могут посылать только почту на почтовый сервер) может быть выражено в редакторе Правил следующим образом:
| 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 |
Рисунок 2. Два предыдущих Правила показаны в окне Редактора Правил.
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 ни в коем случае не допустит прохождения нераспознанных пакетов. Преимущества явного определения подобного правила:
Рисунок 3. Законченная База Правил.
Правила, описанные выше, имеют недостаток - они предоставляют компьютерам локальной сети доступ к ресурсам Gateway (подразумевается, что они имеют соответствующие регистрационные записи на UNIXо системах). Обычно такая ситуация нежелательна. Чтобы предотвратить доступ с любого компьютера (не только с локального) к Gateway, необходимо добавить правило (предшествующее остальным) следующим образом:
| Source | Destination | Services | Action | Track | Install On |
| Any | monk | Any | Reject | Long Log | Gateways |
Защита Gateway подобным способом, делает его недоступным другим пользователям и приложениям (кроме консоли управления CheckPoint FireWallЦ1). Gateway становится невидимым сетевым объектом как для клиентов сети, так и за ее пределами.
Рисунок 4. Окно Редактора Правил с правилом защиты самого 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 | Src |
Поле Install On определено как Src в этом правиле потому, что по умолчанию шлюз устанавливает правила только на входящий трафик. Правило определено для компьютера с именем monk, но так как monk определен как Src, правило действует только на выходящий трафик (правило применяется только к пакетам, порождаемым и отправляемым с компьютера monk). Если бы поле Install On было бы определено как Gateway, правило применялось бы только к пакетам приходящим на monk и порожденным на нем. Другими словами, ни к каким пакетам вообще.