Для системного администратора

1. Введение

Брандмауэр является одними из самых критичных компонентов сети, так как при выходе его из строя, мы потеряем доступ к внешнему миру. Помимо того, что станут недоступны наши внешние сервисы (http, mail и т.д.), так мы еще и потеряем возможность бродить по разным Интернетам!

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

С другой стороны, мы увеличиваем затраты на оборудование и не можем решить такие проблемы как прозрачная передача некоторых протоколов (SSH или IRC) между членами кластера или данными синхронизации (в нашем примере мы будем пользоваться двумя разными протоколами для отказоустойчивости и синхронизации).

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

• OpenBSD – ну, в принципе понятно, что это безопастно, надежно и практично
• Packet Filter (PF) – система пакетной фильтрации и NAT
• CARP (Common Address Redundancy Protocol) – протокол, обеспечивающий отказоустойчивость путем соединения нескольких машин виртуальным интерфейсом и отображающий их для стороннего наблюдателя как одна машина
• pfsync – протокол синхронизации таблиц состояний PF между несколькими брандмауэрами

Было бы желательно иметь с вашей стороны хорошие знания OpenBSD и PF, так как мы не будем заострять внимание на таких темах, как синтаксис команд и правила обслуживания PF. Так или иначе, данная статья содержит некоторые полезные ссылки для того, чтобы покопаться в этих темах.

2. Схема сети

Сперва посмотрим на окружающую нас действительность. В данном случае мы будем работать с очень простой и “классической” моделью:

• DMZ (172.16.240.0/24), содержащей внешние сервисы и сенсор системы обнаружения вторжений
• LAN (172.16.0.0/24), содержащей рабочие станции пользователей и серверы, не доступные извне
• Маршрутизатор, расположенной в маленькой сеточке (172.16.250.0/24), соединяющий нас с Интернет

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

• В случае компрометации брандмауэра, LAN будет защищена дополнительным уровнем фильтрации (хотя было бы предпочтительно использовать различные платформы для брандмауэра, чтобы препятствовать тому, что нападавшие поставили под угрозу внутренние брандмауэры используя ту же уязвимость [MISC17])
• Один, хоть и кластеризованный брандмауэр для LAN и DMZ является одной точкой отказа
• На каждом брандмауэре правила применяются только к ЛВС или DMZ, таким образом делая набор правил PF более понятным и более легким в поддержке

3. Базовая конфигурация

Давайте бросим беглый взгляд на основную конфигурацию системы, которая относится ко всем нашим брандмауэрам.

Мы не будем рассматривать вопрос установки системы, который очень подробно изложен на сайте OpenBSD. Единственное (очевидное) замечание заключается в том, что вы должны установить только голый минимум, чтобы препятствовать тому, что безопасность и надежность брандмауэра ставились под угрозу ненужным программным обеспечением. Поэтому, во время установки вы только должны выбрать только те наборы, которые отмеченны как “Required” в документации: bsd, baseXX.tgz, etcXX.tgz.

Спонсор поста:

Лучшие аркадные игры бесплатно.

Нет никакой необходимости в установке компилятора (compXX.tgz) или пользовательских утилит, которые могут сильно помочь злоумышленникам.

После первой перезагрузки мы можем начать настраивать некоторые файлы конфигурации; по умолчанию, OpenBSD идет с с некоторыми сервисами, включенными в inetd(8):

$ grep -v ^# /etc/inetd.conf

ident           stream  tcp     nowait  _identd /usr/libexec/identd     identd -el

ident           stream  tcp6    nowait  _identd /usr/libexec/identd     identd -el

127.0.0.1:comsat dgram  udp     wait    root    /usr/libexec/comsat     comsat

[::1]:comsat    dgram   udp6    wait    root    /usr/libexec/comsat     comsat

daytime         stream  tcp     nowait  root    internal

daytime         stream  tcp6    nowait  root    internal

time            stream  tcp     nowait  root    internal

time            stream  tcp6    nowait  root    internal

$

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

Хорошей практикой будет редактирование файла /etc/motd, в котором можно указать некоторую информацию о системе и предупредить пользователей, что все попытки доступа регистрируется и что любой несанкционированный доступ будет преследоваться по суду (см. [PUIS]).

В ходе установки вы уже должны были указать сетевые параметры, но так или иначе, вот файлы, которые необходимо подвергнуть редактированию:

• /etc/hostname.if(5) – содержит информацию о сетевых интерфейсах
• /etc/mygate(5) – содержит адрес шлюза по умолчанию
• /etc/myname(5) – содержит имя (FQDN) машины
• /etc/resolv.conf(5) – содержит информацию о DNS, доменах и т.д.

Учитывая большое количество атак, основанных на уязвимостях в системе DNS, предпочтительно не использовать эту систему, а внести адреса наиболее критических систем в файл /etc/hosts(5). Чтобы убедиться, что файл /etc/hosts(5) имеет больший приоритет, по сравнению с DNS, посмотрите файл /etc/resolv.conf(5):

lookup file bind

Пакетная фильтрация по умолчанию выключена, поэтому нам необходимо отредактировать (или создать) файл /etc/rc.conf.local(8, в котром установить переменной pf значение, отличное от NO. Так же вы можете изменить наименование файла конфигурации (по умолчанию /etc/pf.conf):

pf=""

pf_rules=/new/path/to/pf.conf

Так же вы можете установить флаг pflogd(8) в переменной pflogd_flags. И не забудьте включить IP форвардинг!

# sysctl net.inet.ip.forwarding=1

net.inet.ip.forwarding: 0 -> 1

#

Чтобы изменеия действовали после загрузки, раскомментируйте строку в /etc/sysctl.conf(5):

net.inet.ip.forwarding=1

4. Протокол CARP

CARP (Common Address Redundancy Protocol) обеспечивает резервирование системы, состоящей из нескольких хостов, находящихся в одном сетевом сегменте (redundancy group) и имеющей общий IP адрес, при этом, в случае отказа одного из хостов, доступность общего адреса обеспечивают другие члены группы. CARP также позволяет разделить нагрузку между хостами.

Создание избыточных брандмауэров является является лишь частным случаем использования CARP. Этот протокол может использоваться, чтобы гарантировать непрерывность обслуживания и/или распределение нагрузки сервисов сети.

Первоначально, группа разработчиков OpenBSD хотела сделать открытую реализацию протоколов стандарта IETF, VRRP (Virtual Router Redundancy Protocol), определенный в RFC3768, и HSRP (Hot Standby Router Protocol), определенный в RFC2281. Но Cisco, опираясь на патентное право, “категорически заявила сообществу OpenBSD, что будет защищать свои патенты на VRRP”, вынуждая, таким образом, разработчиков OpenBSD создать новый протокол, существенно отличающийся от VRRP.

CARP принадлежит семейству multicast протоколов, объединяя несколько физических компьютеров одним или несколькими виртупльными адресами. Одна из этих машин является хозяином группы (master) и отвечает на все пакеты, адресованные группе. Остальные машины (backups) находятся в режиме ожидания, готовые в любой момент занять место павшего товарища.

С определенным, задаваемым, интервалом, master объявляет о себе с помощью IP протокола 112. В случае аго отказа, функцию рассылки объявлений берет на себя другой хост группы. Выбор master осуществляется на основании большего количества выдаваемых за период времени объявлений. При возвращении прежнего master-a, функция рассылки объявлений возвращается к нему.

Как вы могли заметить, CARP только создает и управляет виртуальными интерфейсами. Для синхронизации же данных между хостами системный администратор должен использовать pfsync, rsync или какой другой протокол.

4.1 Параметры конфигурации

Конфигурирование CARP происходит с помощью команд sysctl и ifconfig. Для sysctl есть три доступных переменных:

• net.inet.carp.allow – определяет, будет ли хост обрабатывать пакеты CARP. По умолчанию – обрабатывать будет.
• net.inet.carp.log – регистрация ошибок CARP. Может иметь значения от 0 до 7, соответствуюя стандартынм уровням syslog(3). По умолчанию имеет значение 2
• net.inet.carp.preempt – если установлено в 0 (по умолчанию), то получив объявление от master, хост не будет учавствовать в выборах нового master. В противном случае, если период рассылки объявлений у хоста меньше, чем у текущего master, хост становится новым master. Эта опция таже позволяет объявить об отказе всех сетевых интерфейсов, при отказе одного из них. Фактически, если отказывает один из CARP-enabled интерфейсов, то CARP изменит значение advskew на 240 на остальных CARP-enabled интерфейсах, инициируя таким образом выборы нового master во всех подсетях, к которым был подключен хост.

Синтаксис команды ifconfig, при конфигурации CARP, выглядит следующим образом:

  ifconfig carpN create  ifconfig carpN [advbase n] [advskew n] [balancing mode] 

  [carpnodes vhid:advskew,vhid:advskew,...] [carpdev iface] 

  [[-]carppeer peer_address] [pass passphrase] [state state] [vhid host-id]

• carpN – имя виртуального carp интерфейса
• advbase, advskew – эти параметры задают временной интервал между посылками объявлений. Этот интервал (в секундах) вычисляется по формуле (advbase + (advskew / 255)). Увеличение advbase уменьшит сетевой трафик, но увеличит время выбора нового master-a. Маленькие значения advskew позволяют хосту чаще давать объявления, увеличивая вероятность стать master. advbase должен иметь значения от 1 до 255, advskew между 0 (значение по умолчанию) до 254.
• balancing – устанавливает режим балансировки. Доступными режимами являются arp, ip, ip-stealth и ip-unicast.
• carpnodes- Разделенный запятыми список пар vhid:advskew, определяющий как будет распределяться загрузка между хостами
• carpdev – определяет физический интерфейс, который принадлежит данной группе. По умолчанию, CARP использует физический интерфейс, который принадлежит той же самой подсети, что и виртуальный интерфейс.
• carppeer – позволяет указать IP адрес пиров, вместо использования multicast.
• pass – пароль, используемый для общения хостов внутри группы.
• state – перевод интерфейса в указанное состояние (init, backup или master)
• vhid – Virtual Host ID. Это уникальный номер от 1 до 255, идентифицирующий отказоустойчивую группу

4.1.1 Счетчик понижения

Помимо начальной конфигурации, с помощью ifconfig(8) можно изменить значение demotion counter, который позволяет указать, насколько хост готов стать master-ом группы. (чем выше значение счетчика, тем хост менее готов). Давайте рассмотрим данный вопрос поподробней.

Все интерфейсы CARP разделены на группы (по умолчанию, интерфейсы carp(4) принадлежат группе “carp”) и каждой группе назначен demotion counter, значение которого можно посмотреть командой:

$ ifconfig -g carp

carp: carp demote count 0

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

• Вы хотите воспрепятствовать выборам хоста в качестве мастера, например, на время его загрузки. Скрипт rc(8) может увеличить demotion counter на 128 до поднятия сетевых интерфейсов и снизить его после настройки сетевых интерфейсов и запуска необходимых сервисов (demotion counter не может быть установлен в абсолютную величину, только увеличен или уменьшен на определенное значение).

  ifconfig -g carp carpdemote 128
  
  [ ... ]
  
  ifconfig -g carp -carpdemote 128

• Вы хотите ограничить число отказоустойчивых интерфейсов carp(4) (а не всех, что происходит, когда установлен preempt). В следующем примере мы сделаем отказоустойчивыми интерфейсы carp1 и carp2, оставив остальные интерфейсы без изменеий:

  # ifconfig carp1 group morituri
  
  # ifconfig carp2 group morituri
  
  # ifconfig morituri
  
  carp1: flags=8843 mtu 1500
  
          carp: MASTER carpdev sis0 vhid 1 advbase 1 advskew 100
  
          groups: carp morituri
  
          inet 1.2.3.4 netmask 0xffffff00 broadcast 1.2.3.255
  
  carp2: flags=8843 mtu 1500
  
          carp: MASTER carpdev sis1 vhid 2 advbase 1 advskew 100
  
          groups: carp morituri
  
          inet 2.3.4.5 netmask 0xffffff00 broadcast 2.3.4.255
  
  # ifconfig -g morituri
  
  morituri: carp demote count 0
  
  # ifconfig -g morituri carpdemote 50
  
  # ifconfig -g morituri
  
  morituri: carp demote count 50
  .

4.1.2 Балансировка нагрузки

CARP предоставляет два различных способа балансировки нагрузки входящего трафика: ARP balancing и IP balancing.

Оба метода требуют предварительного создания группы балансировки на каждом хосте, с несколькими carp(4) интерфейсами, имеющих один IP адрес, но различные VHID. Все ноды carp(4) в группе формируются одинаково, за исключением различного advskew, чтобы сделать каждый хост мастером на разных VHID (пример см. ниже).

ARP balancing работает путем наложения hash-функции на MAC адрес источника для определения VHID, который должен ответить на запрос. На запрос ARP ответит только тот хост, который является master-ом для данного VHID. ARP load balancing может быть включена через ifconfig(8), установив значение “arp” функции балансировки:

# ifconfig carp0 balancing arp carpnodes 1:0,2:100

IP load balancing работает очень похоже на ARP balancing, но использует hash-функцию адресов источника и назначения для определения, какой VHID (и какой хост, соответственно) ответит на запрос.

Требованием IP balancing является необходимость получения пакета всеми хостами группы. Включается данный тип балансировки с помощью команды ifconfig(8), установкой опции “ip”. Таким образом, мы заставляем CARP использовать multicast MAC адрес для отправки трафика на все хосты группы:

# ifconfig carp0 balancing ip carpnodes 1:0,2:100

В качестве альтернативы, вы можете установить значение функции балансировки в “ip-stealth”, чтобы запретить master-у посылать пакеты со своим действительным адресом MAC в качестве источника. Таким образом мы предотвратим обучение коммутатора и продолжим рассылать широковещательные пакеты. Наконец, если у вас слишком умный коммутатор, то можете установить значение опции балансировки в “ip-unicast”.

Выбор между двумя механизмами балансировки нагрузки главным образом зависит от сетевого окружения, в которое будут помещены системы: ARP balancing работает только для клиентов локальной сети и не может балансировать трафик, выходящий за маршрутизатор, поскольку маршрутизируемый трафик всегда содержит MAC address маршрутизатора в качестве источника. Поэтому, если клиенты находятся в разных сетях, остается только IP balancing, единственный недостаток этого метода заключается в том, что трафик должен попасть на все хосты CARP, что увеличивает нагрузку на сеть.

4.2 Входные данные

Пришло время настраивать CARP на наших брандмауэрах. В данной статье мы используем две сильно различающиеся конфигурации CARP, где внутренний брандмауэр (Mickey и Minnie, между LAN и DMZ) работает в режиме active/stand-by (трафик идет только через один хост, а второй находится в горячем резерве), а внешний брандмауэр (Donald и Daisy, отделяет DMZ от internet) работает в режиме балансировки нагрузки.

Mickey

• LAN 172.16.0.200
• DMZ 172.16.240.200
• pfsync 192.168.2.200

Minnie

• LAN 172.16.0.201
• DMZ 172.16.240.201
• pfsync 192.168.2.201

Virtual address

• LAN 172.16.0.202
• DMZ 172.16.240.202

Donald

• LAN 172.16.240.100
• DMZ 172.16.250.100
• pfsync 192.168.1.100

Daisy

• LAN 172.16.240.101
• DMZ 172.16.250.101
• pfsync 192.168.1.101

Virtual address

• LAN 172.16.240.102
• DMZ 172.16.250.102

4.2.1 Active/standby конфигурация

Начнем с Mickey и Minnie: сперва, с помощью ifconfig(8) создадим устройства carp*

mickey# ifconfig carp0 172.16.0.202/24 vhid 1 pass password1 advbase 1 advskew 0

mickey# ifconfig carp1 172.16.240.202/24 vhid 2 pass password2 advbase 1 advskew 0minnie# ifconfig carp0 172.16.0.202/24 vhid 1 pass password1 advbase 1 advskew 100

minnie# ifconfig carp1 172.16.240.202/24 vhid 2 pass password2 advbase 1 advskew 100

Мы только что создали интерфейсы, назначили им IP адрес, присвоили VHID (1 для LAN, 2 для DMZ) и пароль (не самый безопасный). Так же мы решили, что Mickey будет master (присвоив Minnie более высокое значение advskew, таким образом делая интервал между объявлениями (1 + 100 / 255) выше чем интервал между объявлениями Mickey’s (1 + 0 / 255)).

Кроме того, установив переменную net.inet.carp.preempt в “1″ на Mickey, мы заставим его всегда пытаться стать master.

mickey# sysctl net.inet.carp.preempt=1

net.inet.carp.preempt: 0 -> 1

Для того, чтобы наши изменения не пропали после загрузки, необходимо внести в файлы /etc/hostname.carp* и /etc/sysctl.conf следущее:

Mickey:

/etc/hostname.carp0

inet 172.16.0.202 255.255.255.0 172.16.0.255 vhid 1 pass password1 advbase 1 advskew 0/etc/hostname.carp1

inet 172.16.240.202 255.255.255.0 172.16.240.255 vhid 2 pass password2 advbase 1 advskew 0

/etc/sysctl.conf

[...]

net.inet.carp.preempt=1

Minnie:

/etc/hostname.carp0

inet 172.16.0.202 255.255.255.0 172.16.0.255 vhid 1 pass password1 advbase 1 advskew 100/etc/hostname.carp1

inet 172.16.240.202 255.255.255.0 172.16.240.255 vhid 2 pass password2 advbase 1 advskew 100

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

4.2.2 Active/active конфигурация

Настал черед Donald и Daisy, на которых мы сконфигурируем интерфейсы, смотрящие в DMZ. Как и предыдущем примере, создаем устройства carp0 на каждом хосте зададим опцию carpnodes для назначения различных Virtual Host IDs на интерфейсы (vhids 3 и 4).

На vhid 3 мы установим значения advskew для Donald и Daisy в 0 и 100 соответственно, что позволит выступать хосту Donald в роли мастера. Для vhid 4 значения меняются на обратные, назначая, таким образом, Daisy мастером для vhid 4:

donald# ifconfig carp0 172.16.240.102/24 balancing ip carpnodes 3:0,4:100 

> pass password3

donald# sysctl net.inet.carp.preempt=1

net.inet.carp.preempt: 0 -> 1daisy# ifconfig carp0 172.16.240.102/24 balancing ip carpnodes 3:100,4:0 

> pass password3

daisy# sysctl net.inet.carp.preempt=1

net.inet.carp.preempt: 0 -> 1

Теперь мы имеем две отказоустойчивые группы с разными мастерами и одним IP адресом.

donald# ifconfig carp0

carp0: flags=8843 mtu 1500

        lladdr 01:00:5e:00:01:01

        carp: carpdev rl1 advbase 1 balancing ip

                state MASTER vhid 3 advskew 0

                state BACKUP vhid 4 advskew 100

        groups: carp

        inet 172.16.240.102 netmask 0xffffff00 broadcast 172.16.240.255

        inet6 fe80::2c0:a8ff:fe8e:b112%carp0 prefixlen 64 scopeid 0x5daisy# ifconfig carp0

carp0: flags=8843 mtu 1500

        lladdr 01:00:5e:00:01:01

        carp: carpdev rl1 advbase 1 balancing ip

                state BACKUP vhid 3 advskew 100

                state MASTER vhid 4 advskew 0

        groups: carp

        inet 172.16.240.102 netmask 0xffffff00 broadcast 172.16.240.255

        inet6 fe80::219:d2ff:fe02:6469%carp0 prefixlen 64 scopeid 0x5

Дабы не потерять сделанное при перезагрузке, редактируем файлы:

Donald:

/etc/hostname.carp0

inet 172.16.240.102 255.255.255.0 172.16.240.255 balancing ip carpnodes 3:0,4:100 pass password3/etc/sysctl.conf

[...]

net.inet.carp.preempt=1

/etc/hostname.carp1

inet 172.16.250.102 255.255.255.0 172.16.250.255 balancing ip carpnodes 5:0,6:100 pass password5

Daisy:

/etc/hostname.carp0

inet 172.16.240.102 255.255.255.0 172.16.240.255 balancing ip carpnodes 3:100,4:0 pass password3/etc/sysctl.conf

[...]

net.inet.carp.preempt=1

/etc/hostname.carp1

inet 172.16.250.102 255.255.255.0 172.16.250.255 balancing ip carpnodes 5:100,6:0 pass password5

Хотя в вышеприведенном примере всего две машины, данная конфигурация может быть легко расширена до 32 хостов. Распределение нагрузки, как бы вам не хотелось, вряд ли достигнет соотношения 50/50 – это связано с тем, что мы используем хэш адресов источника и назначения, а не объем трафика.

5. Протокол pfsync

Pfsync – это протокол, используемый пакетным фильтромдля управления и обновления таблиц состояния для stateful inspection и NAT. По умолчанию, сообщения о смене состояния рассылаются через синхронизационный интерфейс с помощью IP multicast пакетов. При этом используется IP protocol 240 и multicast-группа 224.0.0.240. Мы реализуем данную схему синхронизации таблиц состояний для получения отказоустойчивого решения, когда переход на новый master происходит без разрыва сессий клиентов.

pfsync(4) является также названием псевдоустройства, через которое происходит синхронизация таблиц (кроме состояний, созданных правилами, помеченных флагом no-sync или пакетов pfsync(4)) pfsync(4) может быть сконфигурирован на физическом интерфейсе, чтобы синхронизировать таблицы нескольких брандмауэров.

Физический синхронизационный интерфейс может быть настроен с помощью команды ifconfig(8), используя параметр syncdev. Для примера, на вашем брандмауэре вы можете выполнить команду:

# ifconfig pfsync0 syncdev rl2

Предполагаем, что интерфейс rl2 на обоих хостах находится в сети 192.168.1.0/24 (для Mickey и Minnie) или 192.168.2.0/24 (для Donald и Daisy) и брандмауэры соединены между собой “кривым(обратным)” патчкордом.

Использование “обратного” патчкорда рекомендуется потому, что pfsync не поддерживает механизмы шифрации или авторизации, поэтому при работе через коммутатор эти пакеты могут быть перехвачены злоумышленником.

В качестве альтернативы, вы можете использовать ключевое слово syncpeer для указания адреса брандмауэра, с которым осуществляется синхронизация. Система будет использовать этот адрес вместо рассылки широковещательных пакетов и вы можете использовать IPsec для защиты трафика. В случае использования syncdev вы должны иметь поддержку псевдоустройства enc(4) для инкапсуляции/деинкапсуляции трафика ipsec(4).

# ifconfig pfsync0 syncpeer 192.168.1.101 syncdev enc0

Для того, чтобы изменения не пропали после перезагрузки, внесите данные в файл /etc/hostname.pfsync0:

up syncdev rl2

6. Правила PF

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

pass quick on rl2 proto pfsync keep state (no-sync)

pass on { rl0, rl1 } proto carp keep state (no-sync)

При написании правил, имейте в виду, что с точки зрения pf(4) трафик движется через физический интерфейс. Поэтому в случае:

pass in on $ext_if [...]

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

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

# SSH on the virtual interface

pass in on $int_if inet proto tcp from $int_if:network to carp0 port ssh

Или делать NAT через перенаправление:

# Mail server accessible from the internet

rdr on $ext_if inet proto tcp from any to carp2 port $mail_ports -> $mail_srv

В любом случае, CARP прозрачен для pf(4), что касается и услуг, предлагаемых брандмауэром на его физических адресах:

# SSH on the physical address

pass in on $int_if inet proto tcp from $int_if:network to $int_if port ssh

Или для нормальной фильтрации:

# External DNS

pass in  on $int_if inet proto { tcp, udp } from $int_if:network to $dns_srv 

     port domain

pass out on $ext_if inet proto { tcp, udp } from $ext_if to $dns_srv 

     port domain

В качестве примера, приведем правила фильтрации для наших внешних брандмауэров, Donald и Daisy:

/etc/pf.conf################################################################################

# Macros and lists                                                             #

################################################################################

ext_if  = rl0                           # External interface

int_if  = rl1                           # DMZ interface

pfs_if  = rl2                           # Pfsync interface

carp_if = carp1                         # External CARP interface

mail_srv = "mail.kernel-panic.it"                               # Mail server

web_srv  = "{ www1.kernel-panic.it, www2.kernel-panic.it }"     # Web servers

dns_srv  = "{ dns1.isp.com, dns2.isp.com }"                     # DNS servers

int_fw   = "{ mickey.kernel-panic.it, minnie.kernel-panic.it }" # Internal fw

mail_ports = "{ smtp, imap, imaps }"    # Mail server ports

web_ports  = "{ www, https }"           # Web server ports

# Allowed incoming ICMP types

icmp_types = "{ echoreq, timex, paramprob, unreach code needfrag }"

# Private networks (RFC 1918)

priv_nets = "{ 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }"

################################################################################

# Options, scrub and NAT                                                       #

################################################################################

set block-policy drop

set loginterface $ext_if

set skip on lo

scrub in

# NAT outgoing connections

nat on $ext_if from !$ext_if to any -> $ext_if

# Redirect web services (with load balancing)

rdr on $ext_if inet proto tcp from any to $carp_if port $web_ports -> $web_srv 

    round-robin sticky-address

# Redirect mail services

rdr on $ext_if inet proto tcp from any to $carp_if port $mail_ports -> $mail_srv

################################################################################

# Filtering rules                                                              #

################################################################################

block all                          # Default deny

block in quick from urpf-failed    # Spoofed address protection

pass quick on $pfs_if proto pfsync keep state (no-sync)        # Enable pfsync

pass on { $int_if, $ext_if } proto carp keep state (no-sync)   # Enable CARP

block in  quick on $ext_if from $priv_nets to any

block out quick on $ext_if from any to $priv_nets

# Mail server

pass in  on $ext_if inet proto tcp from any to $mail_srv port $mail_ports

pass out on $int_if inet proto tcp from any to $mail_srv port $mail_ports

pass in  on $int_if inet proto tcp from $mail_srv to any port smtp

pass out on $ext_if inet proto tcp from $ext_if to any port smtp modulate state

# Web servers

pass in  on $ext_if inet proto tcp from any to $web_srv port $web_ports 

     synproxy state

pass out on $int_if inet proto tcp from any to $web_srv port $web_ports

# ICMP

pass in  inet proto icmp all icmp-type $icmp_types

pass out inet proto icmp all

# DNS

pass in  on $int_if inet proto { tcp, udp } from $int_if:network to $dns_srv 

     port domain

pass out on $ext_if inet proto { tcp, udp } from $ext_if to $dns_srv 

     port domain

# Internet web servers

pass in  on $int_if inet proto tcp from $int_fw to any port $web_ports

pass out on $ext_if inet proto tcp from $ext_if to any port $web_ports 

     modulate state

Разное

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

Не надоело ещё ходить с закрытым ртом? Вас интересует сколько стоит отбеливание зубов в Москве? Это не так уже и дорого, как вам кажется.

Оригинал статьи: http://www.kernel-panic.it/openbsd/carp/

Перевод: Сгибнев Михаил. Оригинал перевода