Перейти к содержанию

Межсетевой экран на основе зон#

Описание#

Обычные политики межсетевого экранирования применяются к каждому интерфейсу в отдельности и позволяют осуществлять фильтрацию для различных направлений трафика (входящий, исходящий и локальный) для каждого интерфейса. Данный метод организации межсетевого экрана удобен для небольших сетевых топологий. Однако по мере усложнения сетевой инфраструктуры, добавления различных виртуальных интерфейсов (VLAN, openvpn и т.д.) и при необходимости детального контроля входящего и исходящего трафика на различных интерфейсах, результирующая конфигурация существенно увеличивается. Межсетевой экран на основе зон обладает рядом особенностей, которые позволяют элегантнее организовывать защиту периметра организации.

Основной абстракцией для данной организации межсетевого экрана являются зоны. Правила межсетевого экранирования применяются для трафика, который передается из одной зоны в другую. Существуют два типа зон:

  • Транзитная зона — зона, объединяющая один или несколько сетевых интерфейсов, где адресом назначения трафика является какое-либо внешнее устройство.
  • Локальная зона — зона, обозначающая сам межсетевой экран и все его интерфейсы. Используется для трафика, адресом назначения которого является сам межсетевой экран.

Примечание

Система конфигурации позволяет создать транзитную зону, в которой отсутствуют интерфейсы. Данная особенность удобна для первоначальной настройки, но необходимо иметь в виду, что транзитная зона без интерфейсов не имеет практического смысла, так как трафик не поступает в данную зону.

Основным отличием данных типов зон является то, что для транзитной зоны по умолчанию запрещен весь входящий и исходящий трафик, в то время как для локальной зоны — разрешен. Таким образом, для транзитных зон правила межсетевого экранирования должны описывать разрешаемый тип трафика, и для локальной зоны, наоборот, запрещаемый.

Другие особенности реализации межсетевого экрана на основе зон:

  • в пределах зоны между различными интерфейсами разрешен весь трафик;
  • каждый интерфейс может быть связан только с одной транзитной зоной;
  • к интерфейсу, принадлежащему к транзитной зоне, не может быть применена индивидуальная для этого интерфейса политика межсетевого экранирования, и наоборот;
  • трафик между интерфейсами, не принадлежащими к транзитным зонам, передается без фильтрации, и к этим интерфейсам могут быть применены индивидуальные политики межсетевого экранирования.

Примечание

Управляющий интерфейс (ethm) не относится ни к одной из зон и средствами системы конфигурации его так же нельзя добавить в транзитную зону. Поэтому возможен обмен трафиком между управляющим интерфейсом и локальной зоной, а так же между ним и другими интерфейсами, не принадлежащими к транзитным зонам.

Примеры настройки межсетевого экрана на основе зон#

В этом примере производится довольно типичное разделение инфраструктуры компании на три зоны безопасности:

  • зона WAN — в данную зону добавляется uplink. Разрешена инициализация соединений с определенными сервисами в зоне DMZ и запрещена инициализация всех соединений с зоной LAN;
  • зона LAN — в данную зону добавляются интерфейсы внутренней сети компании. Разрешена установка соединений с зоной WAN и зоной DMZ.
  • зона DMZ — в данную зону выносятся сервисы, к которым необходимо осуществлять доступ из зоны WAN. Запрещены исходящие соединения в зону LAN.

На рисунке ниже показан пример реализации данной концепции:

  • Имеются три транзитных зоны (то есть точки, где трафик проходит через маршрутизатор): закрытая зона, демилитаризованная зона (DMZ) и общедоступная зона.
  • Интерфейс eth1 лежит в общедоступной зоне; eth2 лежит в DMZ; eth3 и eth4 лежат в закрытой зоне.
  • Стрелки из одной зоны в другую представляют политики фильтрации трафика, применяемые к трафику, передаваемому между зонами.
  • Трафик, передаваемый между 10.10.3.0/24 и 10.10.4.0/24, остаётся в одной и той же зоне безопасности, так что трафик между этими подсетями передается без фильтрации.

Помимо трех транзитных зон, на рисунке ниже есть и четвёртая зона – локальная зона, описывающая сам межсетевой экран.

Межсетевой-экран-основанный-на-политиках-зон-безопасности

Межсетевой экран, основанный на политиках зон безопасности

Начальная настройка IP-адресации#

На рисунке выше приведена схема сетевой адресации внутри организации. Для удобства данная схема представлена в виде таблицы ниже.

Подсеть IP адрес Устройство Зона
203.0.113.0/24 203.0.113.100 Numa Edge#eth1 WAN
203.0.113.254 Шлюз провайдера WAN
172.16.0.0/24 172.16.0.100 Сервер организации DMZ
172.16.0.254 Numa Edge#eth2 DMZ
10.10.1.0/24 10.10.1.100 АРМ1 LAN
10.10.1.254 Numa Edge#eth3 LAN
10.10.2.0/24 10.10.2.100 АРМ2 LAN
10.10.2.254 Numa Edge#eth4 LAN

Для настройки данных подсетей в Numa Edge перейдите в конфигурационный режим и выполните следующие команды:

Пример – Отображение узла конфигурации "show policy firewall"#
  1. Настройка внешнего IP адреса из подсети провайдера на интерфейсе eth1: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth1 address 203.0.113.100/24
  2. Задание описания к данному интерфейсу: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth1 description Uplink
  3. Задание IP адреса на интерфейсе, к которому подключаются сервера организации: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth2 address 172.16.0.254/24
  4. Установка описания для этого интерфейса: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth2 description DMZ
  5. Настройка IP адреса на одном из интерфейсов, к которому подключаются рабочие ПК в организации: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth3 address 10.10.1.254/24
  6. Добавление описания: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth3 description LAN1
  7. Настройка IP адреса на втором интерфейсе для рабочих ПК: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth4 address 10.10.2.254/24
  8. Добавления описания: 
    1
2
    [edit]
admin@edge# set interfaces ethernet eth4 description LAN2
  9. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  10. Просмотр получившейся конфигурации ethernet интерфейсов: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
    [edit] 
admin@edge# show interfaces ethernet  
  eth1 { 
      address 203.0.113.100/24 
      description Uplink 
  } 
  eth2 { 
      address 172.16.0.254/24 
      description DMZ 
  } 
  eth3 { 
      address 10.10.1.254/24 
      description LAN1 
  } 
  eth4 { 
      address 10.10.2.254/24 
      description LAN2 
  }

Настройка других сетевых устройств в данном примере не рассматривается.

Проверка сетевой связности между устройствами#

После настройки сетевой связности рекомендуется произвести проверку доступности устройств между собой. В дальнейшем проверка работы правил фильтрации сетевого трафика будет заключаться именно в проверке доступности или недоступности устройств, расположенных в различных зонах. Начальная и конечная проверки будут включать в себя генерацию ICMP трафика в следующих направлениях:

  • Из LAN в LAN — передача трафика внутри одной зоны.
  • Из LAN в WAN — доступ в интернет для локальных пользователей.
  • Из WAN в LAN — проверка возможности установки соединения из интернета в локальную сеть (должно быть запрещено).
  • Из WAN в DMZ — проверка доступности внутренних сервисов из интернета.
  • Из DMZ в EDGE — доступ из сервисной сети за сам маршрутизатор должен быть запрещен.
  • Из LAN в EDGE — проверка возможности управления устройством из локальной сети.
  • Из LAN в DMZ — проверка доступности внутренних сервисов внутри сети.

Данный набор тестов выбран на основании того, что затрагивает различные политики фильтрации трафика, но в то же время не является слишком избыточным. Например, для трафика между зонами LAN и WAN будет применен точно такой же набор политик, что и между зонами EDGE и WAN, поэтому имеет смысл проверять только один из этих наборов. Подробности взаимодействия политик фильтрации между зонами описаны далее в документе. Используется IP адресация устройств согласно таблице.

В данной проверке ожидается, что все устройства будут доступны по сети.

Тест 1, результат – OK. 

1
2
3
4
5
6
7
8
9
Из LAN в LAN , scr ip = 10.10.1.100, dst ip = 10.10.2.100
root@LAN1:~# ping 10.10.2.100 -c 1
PING 10.10.2.100 (10.10.2.100) 56(84) bytes of data.
64 bytes from 10.10.2.100: icmp_seq=1 ttl=63 time=1.50 ms

--- 10.10.2.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.502/1.502/1.502/0.000 ms
root@LAN1:~#
Тест 2, результат – OK. Из LAN в WAN, src ip = 10.10.1.100, dst ip = 203.0.113.254 
1
2
3
4
5
6
7
8
root@LAN1:~# ping 203.0.113.254  -c 1
PING 203.0.113.254 (203.0.113.254) 56(84) bytes of data.
64 bytes from 203.0.113.254: icmp_seq=1 ttl=63 time=1.37 ms

--- 203.0.113.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.373/1.373/1.373/0.000 ms
root@LAN1:~#

Примечание

В реальном применении для доступа устройств из локальной сети в сеть интернет потребуется настройка NAT для сокрытия адресного пространства локальной сети. Настройка NAT не рассматривается в данном примере.

Тест 3, результат – OK. Из WAN в LAN, src ip = 203.0.113.1 dst ip = 10.10.2.100 

1
2
3
4
5
6
7
root@WAN:~# ping 10.10.2.100 -c 1
PING 10.10.2.100 (10.10.2.100) 56(84) bytes of data.
64 bytes from 10.10.2.100: icmp_seq=1 ttl=63 time=1.46 ms

--- 10.10.2.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.462/1.462/1.462/0.000 ms

Тест 4, результат – OK. Из WAN в DMZ, src ip = 203.0.113.254 dst ip = 172.16.0.100 

1
2
3
4
5
6
7
root@WAN:~# ping 172.16.0.100 -c 1
PING 172.16.0.100 (172.16.0.100) 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 ttl=63 time=1.47 ms

--- 172.16.0.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.466/1.466/1.466/0.000 ms
Тест 5, результат – OK. Из DMZ в EDGE, src ip = 172.16.0.100 dst ip = 172.16.0.254 
1
2
3
4
5
6
7
root@DMZ:~# ping 10.10.1.254 -c 1
PING 172.16.0.254 (172.16.0.254) 56(84) bytes of data.
64 bytes from 172.16.0.254: icmp_seq=1 ttl=64 time=0.797 ms

--- 172.16.0.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.797/0.797/0.797/0.000 ms

Примечание

В данном тесте для проверки в качестве адреса получателя используется IP адрес 172.16.0.100 настроенный на интерфейсе eth2, который принадлежит к зоне LAN. Необходимо помнить что если адресом назначения трафика является любой IP адрес, настроенный на Numa Edge, то в не зависимости от принадлежности интерфейса к транзитной зоне, данный трафик относится к локальной зоне (в данном случае – EDGE).

Тест 6, результат – OK. Из LAN в EDGE, src ip = 10.10.1.100 dst ip = 10.10.1.254 

1
2
3
4
5
6
7
root@LAN1:~# ping 10.10.1.254 -c 1
PING 10.10.1.254 (10.10.1.254) 56(84) bytes of data.
64 bytes from 10.10.1.254: icmp_seq=1 ttl=64 time=0.720 ms

--- 10.10.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.720/0.720/0.720/0.000 ms
Тест 7, результат – OK. Из LAN в DMZ, src ip = 10.10.1.100 dst ip = 172.16.1.100 
1
2
3
4
5
6
7
root@LAN1:~# ping 172.16.0.100 -c 1
PING 172.16.0.100 (172.16.0.100) 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 ttl=63 time=1.40 ms

--- 172.16.0.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.404/1.404/1.404/0.000 ms

Создание зон безопасности#

Создание транзитных зон и добавление в них сетевых интерфейсов#

Первоначально производится создание транзитных зон и добавление в них сетевых интерфейсов согласно таблице. Для этого выполните следующие действия:

Пример – Отображение узла конфигурации "show policy firewall"#
  1. Создание узла конфигурации для зоны WAN и добавление описания к ней: 
    1
2
    [edit]
admin@edge# set zone-policy zone WAN description "WAN ZONE"
  2. Добавление интерфейса eth1 к этой зоне: 
    1
2
    [edit]
admin@edge# set zone-policy zone WAN interface eth1
  3. Создание узла конфигурации для зоны DMZ и добавление описания к ней: 
    1
2
    [edit]
admin@edge# set zone-policy zone DMZ description "DMZ ZONE"
  4. Добавление интерфейса eth2 к зоне DMZ: 
    1
2
    [edit]
admin@edge# set zone-policy zone DMZ interface eth2
  5. Создание узла конфигурации для зоны LAN и добавление описания к ней: 
    1
2
    [edit]
admin@edge# set zone-policy zone LAN description "LAN ZONE"
  6. Добавление интерфейса eth3 к зоне: 
    1
2
    [edit]
admin@edge# set zone-policy zone LAN interface eth3
  7. Добавление интерфейса eth4 к зоне: 
    1
2
    [edit]
admin@edge# set zone-policy zone LAN interface eth4
  8. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  9. Вывод конфигурации узла zone-policy: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
    [edit]
admin@edge# show zone-policy
   zone DMZ {
      description "DMZ ZONE"
      interface eth2
   }
   zone LAN {
      description "LAN ZONE"
      interface eth3
      interface eth4
   }
   zone WAN {
      description "WAN ZONE"
      interface eth1
   }

Обратите внимание, что после применения данной конфигурации, передача трафика между транзитными зонами будет запрещена. Это связано с тем, что для каждой транзитной зоны по умолчанию (если пакет не попадает ни под одну из политик) используется действие drop. Система конфигурации позволяет изменить данное действие на значения:

  • reject — запрет трафика с уведомлением отправителя;
  • accept — разрешение трафика.

Изменение значения для данного атрибута осуществляется с помощью команды:

1
2
3
4
5
admin@edge# set zone-policy zone <zone-name> default-action 
Possible completions:
  accept        Пропустить
  drop          Удалить без нотификации
  reject        Удалить и послать сообщение источнику

Важно

Изменять данные значения не рекомендуется, поскольку они влияют на весь входящий и исходящий трафик, не попадающий под другие политики. Изменения этих значений для транзитных зон может существенно подорвать их безопасность.

Дополнительно следует заметить, что поскольку интерфейсы eth1 и eth2 лежат в одной и той же зоне, передача трафика между ними происходит беспрепятственно.

Создание локальной зоны#

Для создания локальной зоны необходимо выполнить следующие команды:

  1. Создание локальной зоны: 
    1
2
    [edit]
admin@edge# set zone-policy zone EDGE local-zone
  2. Добавление описания: 
    1
2
    [edit]
admin@edge# set zone-policy zone EDGE description "Numa Edge local zone"
  3. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit
  4. Просмотр всех настроенных зон на устройстве: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
    [edit]
admin@edge# show zone-policy  
  zone DMZ { 
      description "DMZ ZONE" 
      interface eth2 
  } 
  zone EDGE { 
      description "Numa Edge local zone" 
      local-zone 
  } 
  zone LAN { 
      description "LAN ZONE" 
      interface eth3 
      interface eth4 
  } 
  zone WAN { 
      description "WAN ZONE" 
      interface eth1 
  }

Теперь межсетевой экран разделен на зоны безопасности и необходимо настроить политики фильтрации трафика между этими зонами.

Настройка политик фильтрации трафика между зонами#

Настройка базовых политик фильтрации#

Перед началом настройки сложных правил фильтрации, которые описывают различные условия прохождения трафика будет полезно создать простые правила, явно запрещающие или разрешающие приходящий трафик в определенную зону.

Для этого необходимо настроить следующие политики:

  • "ALL_ACCEPT" — безусловно разрешающая политика для передачи трафика между транзитными зонами.
  • "ALLOW_RESPONSE" — политика на основе состояния соединения, разрешающая только ответный трафик;
  • "ALL_DROP" — безусловная запрещающая политика для передачи трафика между транзитными зонами и локальной зоной.

Данные политики являются довольно универсальными, и в дальнейшем могут применяться для разрешения трафика между различными зонами в случае увеличения их количества.

Пример – Создание безусловно разрешающей политики#
  1. Создание узла конфигурации для политики ALL_ACCEPT и ввод описания для неё: 
    1
2
    [edit]
admin@edge# set policy firewall ALL_ACCEPT description "allow all traffic"
  2. Создание правила для принятия всего трафика, передаваемого в общедоступную зону: 
    1
2
    [edit]
admin@edge# set  policy firewall  ALL_ACCEPT default-action accept
  3. Фиксация настройки: 
    1
2
    [edit]
admin@edge# commit
  4. Вывод настройки межсетевого экрана: 
    1
2
3
    [edit]
admin@edge# show policy firewall  ALL_ACCEPT
   default-action accept   description "allow all traffic"

Теперь создается политика, которая разрешает только ответный трафик.

Пример – Создание политики разрешающий ответный трафик#
  1. Создание правила фильтрации для разрешения прохождения только трафика, исходящего из этой зоны (т.е. ранее установленные сеансы и связанный с ними трафик): 
    1
2
3
4
5
6
    [edit]
admin@edge# set filter STATE-GOOD rule 10 state established enable
[edit]
admin@edge# set filter STATE-GOOD rule 10 state related enable
[edit]
admin@edge# set filter STATE-GOOD rule 10 protocol all
  2. Создание узла конфигурации для политики ALLOW_RESPONSE и ввод описания для неё: 
    1
2
    [edit]
admin@edge# set policy firewall ALLOW_RESPONSE description "filter traffic to LAN zone"
  3. Создание правила rule 10 для политики межсетевого экранирования ALLOW_RESPONSE. Это правило разрешает трафик, соответствующий указанным критериям: 
    1
2
    [edit]
admin@edge# set policy firewall ALLOW_RESPONSE rule 10 action accept
  4. Применение фильтра STATE-GOOD к политике межсетевого экрана ALLOW_RESPONSE: 
    1
2
    [edit]
admin@edge# set policy firewall ALLOW_RESPONSE rule 10 match filter STATE-GOOD
  5. Фиксация настройки: 
    1
2
    [edit]
admin@edge# commit
  6. Вывод настройки межсетевого экрана: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
    [edit]
admin@edge# show filter STATE-GOOD
   rule 10 {
      protocol all
      state {
         established enable
         related enable
      }
   }
[edit]
admin@edge# show policy firewall ALLOW_RESPONSE
   description "filter traffic to LAN zone"
   rule 10 {
      action accept
      match {
         filter STATE-GOOD
      }
   }

Далее создается безусловно запрещающая политика.

Пример – Создание безусловно запрещающей политики#
  1. Создание узла конфигурации для политики ALL_ACCEPT и ввод описания для неё: 
    1
2
    [edit]
admin@edge# set policy firewall ALL_DROP description "drop all traffic"
  2. Создание правила для принятия всего трафика, передаваемого в общедоступную зону: 
    1
2
    [edit]
admin@edge# set policy firewall  ALL_DROP default-action drop
  3. Фиксация настройки: 
    1
2
    [edit]
admin@edge# commit
  4. Вывод настройки межсетевого экрана: 
    1
2
3
    [edit]
admin@edge# show policy firewall  ALL_DROP
   default-action drop   description "drop all traffic"

Применение базовых политик фильтрации#

После создания базовых политик фильтрации необходимо определить между какими зонами они будут применяться. Необходимо помнить, что политики применяются для трафика, входящего в определенную зону. То есть для такого трафика, который передается из зоны А в зону B, для конфигурации, выглядящей следующим образом: 

1
2
3
4
5
6
7
[edit]
admin@edge# show zone-policy zone B 
   from A {
       policy {
           firewall A-to-B
       }
   }

При этом настройка ответного трафика, из зоны B в зону A настраивается в узле конфигурации, относящемуся к зоне A. 

1
2
3
4
5
6
7
[edit]
admin@edge# show zone-policy zone A 
   from B {
       policy {
           firewall B-to-A
       }
   }
Для наглядности направление трафика, к которому будут применены базовые политики представлено на рисунке ниже.

Схема-применения-политик-между-зонами

Схема применения политик между зонами

Согласно данному рисунку получается следующий набор базовых политик фильтрации трафика:

  • Разрешен весь трафик LAN-to-WAN, EDGE-to-WAN, DMZ-to-WAN.
  • Разрешен только ответный трафик WAN-to-LAN, EDGE-to-LAN, WAN-to-EDGE, DMZ-to-LAN.
  • Запрещен весь трафик DMZ-to-EDGE, EDGE-to-DMZ.

Для направления трафика, который помечен как CUSTOM_POLICY будут применены более сложные правила фильтрации. Настройка этих правил описана далее в документе. Для применения настроенных политик фильтрации воспользуйтесь командами ниже.

Пример – Применение базовых политик фильтрации#
  1. Разрешение передачи любого трафика из зоны LAN в зону WAN: 
    1
2
    [edit]
admin@edge# set zone-policy zone WAN from LAN policy firewall ALL_ACCEPT
  2. Разрешение передачи любого трафика из локальной зоны EDGE в зону WAN: 
    1
2
    [edit]
admin@edge# set zone-policy zone WAN from EDGE policy firewall ALL_ACCEPT
  3. Разрешение передачи любого трафика из зоны DMZ в зону WAN: 
    1
2
    [edit]
admin@edge# set zone-policy zone WAN from DMZ policy firewall ALL_ACCEPT
  4. Разрешение только ответного трафика из зоны WAN в зону LAN: 
    1
2
    [edit]
admin@edge# set zone-policy zone LAN from WAN policy firewall ALLOW_RESPONSE
  5. Разрешение только ответного трафика из локальной зоны EDGE в зону LAN: 
    1
2
    [edit]
admin@edge# set zone-policy zone LAN from EDGE policy firewall ALLOW_RESPONSE
  6. Разрешение только ответного трафика из зоны WAN в локальную зону EDGE: 
    1
2
    [edit]
admin@edge# set zone-policy zone EDGE from WAN policy firewall ALLOW_RESPONSE
  7. Разрешение только ответного трафика из зоны DMZ в зону LAN: 
    1
2
    [edit]
admin@edge#  set zone-policy zone LAN from DMZ policy firewall ALLOW_RESPONSE
  8. Запрет любого трафика из локальной зоны EDGE в зону DMZ: 
    1
2
    [edit]
admin@edge# set zone-policy zone DMZ from EDGE policy firewall ALL_DROP
  9. Запрет любого трафика из зоны DMZ в локальную зону EDGE: 
    1
2
    [edit]
admin@edge# set zone-policy zone EDGE from DMZ policy firewall ALL_DROP
  10. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit
  11. Просмотр примененной конфигурации: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
    admin@edge# show zone-policy  
  zone DMZ { 
      description "DMZ ZONE" 
      from EDGE { 
          policy { 
              firewall ALL_DROP 
          } 
      } 
      interface eth2 
  } 
  zone EDGE { 
      description "Numa Edge local zone" 
      from DMZ { 
          policy { 
              firewall ALL_DROP 
          } 
      } 
      from WAN { 
          policy { 
              firewall ALLOW_RESPONSE 
          } 
      } 
      local-zone 
  } 
  zone LAN { 
      description "LAN ZONE" 
      from DMZ { 
          policy { 
              firewall ALLOW_RESPONSE 
          } 
      } 
      from EDGE { 
          policy { 
              firewall ALLOW_RESPONSE 
          } 
      } 
      from WAN { 
          policy { 
              firewall ALLOW_RESPONSE 
          } 
      } 
      interface eth3 
      interface eth4 
  } 
  zone WAN { 
      description "WAN ZONE" 
      from DMZ { 
          policy { 
              firewall ALL_ACCEPT 
          } 
      } 
      from EDGE { 
          policy { 
              firewall ALL_ACCEPT 
          } 
      } 
      from LAN { 
          policy { 
              firewall ALL_ACCEPT 
          } 
      } 
      interface eth1 
  }

Создание и применение специальных политик фильтрации#

Теперь создаются более сложные политики фильтрации, описывающие прохождения трафика в следующих направлениях:

  • WAN-to-DMZ — политика, разрешающая доступ из интернета c помощью протоколов HTTP,HTTPS на сервер в зоне DMZ. Дополнительно разрешается весь ICMP трафик.
  • LAN-to-DMZ — политика, разрешающая доступ из зоны LAN в зону DMZ с помощью протоколов HTTP и HTTPS а так же FTP и SSH . Весь ICMP трафик так же разрешен.
  • LAN-to-EDGE — политика, разрешающая доступ с помощью протокола SSH только для определенного адреса отправителя.

Первоначально создадим необходимые фильтры:

  • WAN_SERVICE_PORT — перечень портов, доступ к которым разрешен из публичной сети (в данном случае из зоны WAN).
  • LAN_SERVICE_PORT — порты, доступ к которым разрешен из частной сети ( зоны LAN).
  • ICMP — фильтр, описывающий ICMP трафик.
Пример – Создание фильтра WAN_SERVICE_PORT#
  1. Вначале создаем порт-группу, в которую добавляются все необходимые порты. Данный метод удобнее простого описания списка портов в правиле фильтрации, поскольку позволяет гибко управлять содержимым группы без необходимости редактирования фильтра: 
    1
2
3
4
    [edit]
admin@edge# set groups port-group PUBLIC_SERVICE_PORT port http
[edit]
admin@edge# set groups port-group PUBLIC_SERVICE_PORT port https
  2. Теперь создается фильтр WAN_SERVICE_PORT, для которого в качестве портов назначения трафика выбирается ранее созданная группа: 
    1
2
    [edit]
admin@edge# set filter WAN_SERVICE_PORT rule 10 destination port-group PUBLIC_SERVICE_PORT
  3. Синтаксис системы конфигурации требует не только указание числового или символьного обозначения портов, но и протокол, относящийся к данным портам. В данном случае порты HTTP и HTTPS работают поверх протокола TCP: 
    1
2
    [edit]
admin@edge#  set filter WAN_SERVICE_PORT rule 10 protocol tcp
  4. Теперь создается описание для данного фильтра: 
    1
2
    [edit]
admin@edge# set filter WAN_SERVICE_PORT description "Ports to which connections can be established from an WAN zone"
  5. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit
  6. Просмотр получившейся конфигурации: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
    [edit]
admin@edge# show groups port-group PUBLIC_SERVICE_PORT  
  port http 
  port https 
[edit]
admin@edge# show filter WAN_SERVICE_PORT  
  description "Ports to which connections can be established from an WAN zone" 
  rule 10 { 
      destination { 
          port-group PUBLIC_SERVICE_PORT 
      } 
      protocol tcp 
  } 
[edit]

Аналогичным образом создается правило фильтрации для доступа к сервисным портам из зоны LAN.

Пример – Создание фильтра LAN_SERVICE_PORT#
  1. Аналогично с предыдущим примером создается порт-группа PRIVATE_SERVICE_PORT в которую помимо портов HTTP и HTTPS добавляются еще порты FTP и SSH: 
    1
2
3
4
5
6
7
8
    [edit]
admin@edge# set groups port-group PRIVATE_SERVICE_PORT port http
[edit]
admin@edge# set groups port-group PRIVATE_SERVICE_PORT port https
[edit]
admin@edge# set groups port-group PRIVATE_SERVICE_PORT port ftp
[edit]
admin@edge# set groups port-group PRIVATE_SERVICE_PORT port ssh
  2. Также, аналогично предыдущему примеру создается правило фильтрации LAN_SERVICE_PORT, в которое добавляется данная группа: 
    1
2
    [edit]
admin@edge# set filter LAN_SERVICE_PORT rule 10 destination port-group PRIVATE_SERVICE_PORT
  3. Все порты работают поверх протокола TCP: 
    1
2
    [edit]
admin@edge# set filter LAN_SERVICE_PORT rule 10 protocol tcp
  4. Аналогичным образом создается описание: 
    1
2
    [edit]
admin@edge# set filter LAN_SERVICE_PORT description "Ports to which connections can be established from an LAN zone"
  5. И полученная конфигурация применяется: 
    1
2
    [edit]
admin@edge# commit
  6. Просмотр получившейся конфигурации: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
    [edit]
admin@edge# show groups port-group PRIVATE_SERVICE_PORT  
  port http 
  port https 
  port ftp 
  port ssh

[edit]
admin@edge# show filter LAN_SERVICE_PORT 
  description "Ports to which connections can be established from an LAN zone" 
  rule 10 { 
      destination { 
          port-group PRIVATE_SERVICE_PORT 
      } 
      protocol tcp 
  }

И последним этапом в настройке фильтров будет описание ICMP трафика.

Пример – Фильтр для ICMP трафика#
  1. В качестве используемого протокола выбирается ICMP трафик: 
    1
2
    [edit]
admin@edge# set filter ICMP rule 10 protocol icmp
  2. Для ICMP трафика выбирается любой тип сообщений. Детальная настройка разрешений для ICMP трафика выходит за рамки данного документа: 
    1
2
    [edit]
admin@edge# set filter ICMP rule 10 icmp type any
  3. Добавление описания для фильтра: 
    1
2
    [edit]
admin@edge# set filter ICMP description "All ICMP traffic"
  4. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  5. Просмотр получившегося фильтра: 
    1
2
3
4
5
6
7
8
    [edit]
admin@edge# show filter ICMP    description "All ICMP traffic"   rule 10 {
       icmp {
           type any
       }
       protocol icmp
   } 
[edit]

После того как требуемые фильтры были созданы, осталось применить их к политикам фильтрации трафика между зонами.

Первоначально описывается политика, регулирующая доступ из зоны WAN в зону DMZ.

Пример – Настройка политики WAN-to-DMZ#
  1. Создание политики межсетевого экранирования WAN-to-DMZ и добавления правила 10, в котором в качестве портов назначения указаны HTTP и HTTPS: 
    1
2
    [edit]
admin@edge# set policy firewall WAN-to-DMZ rule 10 match filter WAN_SERVICE_PORT
  2. Если трафик попадает под данный фильтр, то он разрешается: 
    1
2
    [edit]
admin@edge# set policy firewall WAN-to-DMZ rule 10 action accept
  3. Создание правила 20, в котором описан ICMP трафик: 
    1
2
    [edit]
admin@edge# set policy firewall WAN-to-DMZ rule 20 match filter ICMP
  4. Аналогично, разрешается ICMP трафик: 
    1
2
    [edit]
admin@edge# set policy firewall WAN-to-DMZ rule 20 action accept
  5. К трафику, который не попадает по созданные правила, применяется стандартное действие drop. Для логирования этого трафика, добавляется соответствующая настройка: 
    1
2
    [edit]
admin@edge# set policy firewall WAN-to-DMZ enable-default-log
  6. К созданной политике межсетевого экранирования добавляется описание: 
    1
2
    [edit]
admin@edge# set policy firewall WAN-to-DMZ description "Allow only destanation HTTP,HTTPS and ICMP traffic"
  7. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  8. Вывод настройки политики WAN-to-DMZ: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
    [edit]
admin@edge# show policy firewall WAN-to-DMZ                    
  description "Allow only destanation HTTP,HTTPS and ICMP traffic" 
  enable-default-log 
  rule 10 { 
      action accept 
      match { 
          filter WAN_SERVICE_PORT 
      } 
  } 
  rule 20 { 
      action accept 
      match { 
          filter ICMP 
      } 
  }
  9. Применение политики межсетевого экранирования, для трафика передаваемого из зоны WAN в зону DMZ: 
    1
2
    [edit]
admin@edge# set zone-policy zone DMZ from WAN policy firewall WAN-to-DMZ
  10. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit
    Теперь описывается политика межсетевого экранирования для трафика, передаваемого из зоны LAN в зону DMZ.
Пример – Настройка политики LAN-to-DMZ#
  1. Аналогично предыдущему примеру создается политика LAN-to-DMZ, где в правиле 10 описывается трафик, который предназначен для служб SSH, FPT, HTTP и HTTPS: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-DMZ rule 10 match filter LAN_SERVICE_PORT
  2. Трафик, попадающий под это правило разрешается: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-DMZ rule 10 action accept
  3. Правило 20 соответствует прошлому примеру: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-DMZ rule 20 match filter ICMP
  4. Трафик, попадающий под это правило разрешается: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-DMZ rule 20 action accept
  5. Аналогично прошлому примеру, весь трафик, не попадающий под разрешающие правила – запрещается, а запись о нем заносится в системный журнал: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-DMZ enable-default-log
  6. Для данной политики задается описание: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-DMZ description "Allow only destanation HTTP,HTTPS,FTP,SSH and ICMP traffic"
  7. Изменения применяются: 
    1
2
    [edit]
admin@edge# commit
  8. Вывод полученной конфигурации: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
    [edit]
admin@edge# show policy firewall LAN-to-DMZ                    
  description "Allow only destanation HTTP,HTTPS,FTP,SSH and ICMP traffic" 
  enable-default-log 
  rule 10 { 
      action accept 
      match { 
          filter LAN_SERVICE_PORT 
      } 
  } 
  rule 20 { 
      action accept 
      match { 
          filter ICMP 
      } 
  }
  9. Применение политики межсетевого экранирования, для трафика передаваемого из зоны LAN в зону DMZ: 
    1
2
    [edit]
admin@edge# set zone-policy zone DMZ from LAN policy firewall LAN-to-DMZ
  10. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
    Завершающим этапом настройки будет ограничения доступа к Numa Edge из зоны LAN. Данная настройка несет потенциальный риск потерять управления в случае ошибочных действий. Для примера доступ по SSH разрешен только с устройства 10.10.1.100.
Пример – Настройка политики LAN-to-EDGE#
  1. Создание политики фильтрации, который описывает возможность подключения к Numa Edge через протокол SSH только с устройства 10.10.1.100. В дальнейшем, можно использовать группу адресов для описания нескольких устройств, с которых возможно управление: 
    1
2
3
4
5
6
    [edit]
admin@edge# set filter EDGE-MGMT rule 10 destination port ssh
[edit]
admin@edge# set filter EDGE-MGMT rule 10 protocol tcp
[edit]
admin@edge# set filter EDGE-MGMT rule 10 source address 10.10.1.100
  2. Применение изменений: 
    1
2
    [edit]
admin@edge# commit
  3. Создание политики межсетевого экранирования, правило которого ограничивает доступ к Numa Edge: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-EDGE rule 10 match filter  EDGE-MGMT
  4. Трафик, попадающий под это правило разрешается: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-EDGE rule 10 action accept
  5. Аналогично предыдущему примеру, разрешается ICMP трафик: 
    1
2
3
4
    [edit]
admin@edge# set policy firewall LAN-to-EDGE rule 20 match filter ICMP
[edit]
admin@edge# set policy firewall LAN-to-EDGE  rule 20 action accept
  6. Весь явно не разрешенный трафик запрещен и запись о нем заносится в системный журнал: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-EDGE enable-default-log
  7. Для данной политики задается описание: 
    1
2
    [edit]
admin@edge# set policy firewall LAN-to-EDGE description "Allow SSH connection only from 10.10.1.100"
  8. Изменения применяются: 
    1
2
    [edit]
admin@edge# commit
  9. Просмотр изменений: 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
    [edit] 
admin@edge# show policy firewall LAN-to-EDGE                    
  description "Allow SSH connection only from 10.10.1.100" 
  enable-default-log 
  rule 10 { 
      action accept 
      match { 
          filter EDGE-MGMT 
      } 
  } 
  rule 20 { 
      action accept 
      match { 
          filter ICMP 
      } 
  }
  10. Применение политики межсетевого экранирования, для трафика передаваемого из зоны LAN в зону локальную EDGE: 
    1
2
    [edit]
admin@edge# set zone-policy zone EDGE from LAN policy firewall LAN-to-EDGE
  11. Применение конфигурации: 
    1
2
    [edit]
admin@edge# commit
    Настройка межсетевого экрана на основе зон завершена и теперь необходимо убедится в его правильности с помощью проверки прохождения трафика.

Проверка#

Конечная проверка будет включает в себя генерацию ICMP трафика в следующих направлениях:

  • Из LAN в LAN — передача трафика внутри одной зоны — должен быть разрешен;
  • Из LAN в WAN — доступ в интернет для локальных пользователей — должен быть разрешен;
  • Из WAN в LAN — проверка возможности установки соединения из интернета в локальную сеть — должен быть запрещен;
  • Из WAN в DMZ — проверка доступности внутренних сервисов из интернета — должен быть разрешен;
  • Из DMZ в EDGE — доступ из сервисной сети за сам маршрутизатор — должен быть запрещен;
  • Из LAN в EDGE — проверка возможности управления устройством из локальной сети — должен быть разрешен;
  • Из LAN в DMZ — проверка доступности внутренних сервисов внутри сети — должен быть разрешен.

Тест 1, результат – OK. Из LAN в LAN , scr ip = 10.10.1.100, dst ip = 10.10.2.100 

1
2
3
4
5
6
7
8
root@LAN1:~# ping 10.10.2.100 -c 1
PING 10.10.2.100 (10.10.2.100) 56(84) bytes of data.
64 bytes from 10.10.2.100: icmp_seq=1 ttl=63 time=1.50 ms

--- 10.10.2.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.502/1.502/1.502/0.000 ms
root@LAN1:~#

Тест 2, результат – OK. Из LAN в WAN, src ip = 10.10.1.100, dst ip = 203.0.113.254 

1
2
3
4
5
6
7
8
root@LAN1:~# ping 203.0.113.254  -c 1
PING 203.0.113.254 (203.0.113.254) 56(84) bytes of data.
64 bytes from 203.0.113.254: icmp_seq=1 ttl=63 time=1.37 ms

--- 203.0.113.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.373/1.373/1.373/0.000 ms
root@LAN1:~#
Тест 3, результат – OK. Из WAN в LAN, src ip = 203.0.113.1 dst ip = 10.10.2.100 
1
2
3
4
5
6
root@WAN:~# ping 10.10.2.100 -c 1
PING 10.10.2.100 (10.10.2.100) 56(84) bytes of data.

--- 10.10.2.100 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
root@WAN:~#
Тест 4, результат – OK. Из WAN в DMZ, src ip = 203.0.113.254 dst ip = 172.16.0.100 
1
2
3
4
5
6
7
root@WAN:~# ping 172.16.0.100 -c 1
PING 172.16.0.100 (172.16.0.100) 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 ttl=63 time=1.47 ms

--- 172.16.0.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.466/1.466/1.466/0.000 ms
Тест 5, результат – OK. 
1
2
3
4
5
6
7
8
Из DMZ в EDGE, src ip = 172.16.0.100 dst ip = 172.16.0.254
root@DMZ:~# ping 10.10.1.254 -c 1
PING 10.10.1.254 (10.10.1.254) 56(84) bytes of data.

--- 10.10.1.254 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@DMZ:~#
Тест 6, результат – OK. Из LAN в EDGE, src ip = 10.10.1.100 dst ip = 10.10.1.254 
1
2
3
4
5
6
7
root@LAN1:~# ping 10.10.1.254 -c 1
PING 10.10.1.254 (10.10.1.254) 56(84) bytes of data.
64 bytes from 10.10.1.254: icmp_seq=1 ttl=64 time=0.720 ms

--- 10.10.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.720/0.720/0.720/0.000 ms
Тест 7, результат – OK. Из LAN в DMZ, src ip = 10.10.1.100 dst ip = 172.16.1.100 
1
2
3
4
5
6
7
root@LAN1:~# ping 172.16.0.100 -c 1
PING 172.16.0.100 (172.16.0.100) 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 ttl=63 time=1.40 ms

--- 172.16.0.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.404/1.404/1.404/0.000 ms
Дополнительно проверяется возможность подключения к Numa Edge:

Тест 8, результат – ОК. Из LAN в Edge, src ip = 10.10.1.100 dst ip = 10.10.1.254, SSH 

1
2
3
4
5
6
7
root@LAN1:~# ssh admin@10.10.1.254
The authenticity of host '10.10.1.254 (10.10.1.254)' can't be established.
ECDSA key fingerprint is SHA256:tgO+iGtDZ8imoF7Oh4QtrSm7HaSkqnmZQpxxgeWi+Ew.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.1.254' (ECDSA) to the list of known hosts.
Numa Edge 1.0 
Password:
Тест 9, результат – ОК. Из LAN в Edge, src ip = 10.10.2.100 dst ip = 10.10.2.254, SSH 
1
2
root@LAN2:~# ssh admin@10.10.2.254
ssh: connect to host 10.10.2.254 port 22: Connection timed out

После проверки рекомендуется сохранить конфигурацию, чтобы она была доступна после перезагрузки устройства. Для этого выполните команду: 

1
2
[edit]
admin@edge# save