Ключевые слова:carp, balancer, failover, openbsd, pf, firewall, pfsync, (найти похожие документы)
From: Сгибнев Михаил <msgibnev(ого-го какая собака)gmail.com>
Date: Mon, 15 Jan 2010 17:02:14 +0000 (UTC)
Subject: Создание отказоустойчивого брандмауэра на OpenBSD с использованием CARP и pfsync
Оригинал: http://dreamcatcher.ru/bsd/012_obsd.html
Оригинал: Redundant firewalls with OpenBSD, CARP and pfsync
Перевод: Сгибнев Михаил
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) или
пользовательских утилит, которые могут сильно помочь злоумышленникам
(смотрите PUIS).
После первой перезагрузки мы можем начать настраивать некоторые файлы
конфигурации; по умолчанию, 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
$
Систему считают безопасной также с этими включенными сервисами (см.
ABSO); так или иначе, выведение из строя их всех не нанесет нам
никакого вреда.
Хорошей практикой будет редактирование файла /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" (см. CARP для получения дополнительной
информации), вынуждая, таким образом, разработчиков OpenBSD создать
новый протокол, существенно отличающийся от VRRP.
CARP принадлежит семейству multicast протоколов, объединяя несколько
физических компьютеров одним или несколькими виртупльными адресами.
Одна из этих машин является хозяином группы (master) и отвечает на все
пакеты, адресованные группе. Остальные машины (backups) находятся в
режиме ожидания, готовые в любой момент занять место павшего товарища.
С определенным, задаваемым, интервалом, master объявляет о себе с
помощью IP протокола 112. В случае аго отказа, функцию рассылки
объявлений берет на себя другой хост группы. Выбор master
осуществляется на основании большего количества выдаваемых за период
времени объявлений. При возвращении прежнего master-a, функция рассылки
объявлений возвращается к нему.
Как вы могли заметить, CARP только создает и управляет виртуальными
интерфейсами. Для синхронизации же данных между хостами системный
администратор должен использовать pfsync(4),rsync или какой
другой протокол.
4.1 Параметры конфигурации
Конфигурирование CARP происходит с помощью команд sysctl(8) и
ifconfig(8). Для sysctl(8) есть три доступных переменных:
* 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(8), при конфигурации 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(4) интерфейса
* 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
Для получения дополнительной информации обратитесь к PFFAQ.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 0
minnie# 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 -> 1
daisy# 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 0x5
daisy# 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
7. Приложения
7.1 Ссылки
[MISC17] - Filtrage applicatif : le cas des clients web, mail et p2p (MISC N?17)
[PUIS] - Practical UNIX and Internet Security, Simson Garfinkel and Gene Spafford, O'Reilly, 2003
[ABSO] - Absolute OpenBSD, Michael W. Lucas, No Starch Press, 2003
[CARP] - "CARP License" and "Redundancy must be free"
[PFFAQ] - PF: The OpenBSD Packet Filter
[RFC3768] - RFC 3768, Virtual Router Redundancy Protocol (VRRP)
[RFC2281] - RFC 2281, Cisco Hot Standby Router Protocol (HSRP)
7.2 Библиография
The Common Address redundancy Protocol (CARP)
Firewall Failover with pfsync and CARP
Firewalling with OpenBSD's PF packet filter, Peter N. M. Hansteen, 2008
The Book of PF, Peter N. M. Hansteen, No Starch Press, 2008
The OpenBSD PF Packet Filter Book, Jeremy C. Reed, Reed Media Services, 2006
Буду рад предложениям и замечаниям, чтобы улучшить эту статью на
msgibnev(ого-го какая собака)gmail.com
Угу, а патчи из -STABLE без compXX.tgz как применять?
Опять же, если злоумышленник поимел возможность запускать что угодно на фаерволе (т.е., фактически, шелл-доступ), то он может залить туда любую прогу на свой вкус. Так что выкидывание «лишних» программ создаёт больше проблем для администратора, чем для хакера.
Так как в данной топологии у нас две группы брандмауэров, то это позволит нам рассмотреть две различные конфигурации. Использование нескольких групп имеет следующие преимущества: * В случае компрометации брандмауэра, LAN будет защищена дополнительным уровнем фильтрации (хотя было бы предпочтительно использовать различные платформы для брандмауэра, чтобы препятствовать тому, что нападавшие поставили под угрозу внутренние брандмауэры используя ту же уязвимость [MISC17]) * Один, хоть и кластеризованный брандмауэр для LAN и DMZ является одной точкой отказа * На каждом брандмауэре правила применяются только к ЛВС или DMZ, таким образом делая набор правил PF более понятным и более легким в поддержке 3. Базовая конфигурация Давайте бросим беглый взгляд на основную конфигурацию системы, которая относится ко всем нашим брандмауэрам. Мы не будем рассматривать вопрос установки системы, который очень подробно изложен на сайте OpenBSD. Единственное (очевидное) замечание заключается в том, что вы должны установить только голый минимум, чтобы препятствовать тому, что безопасность и надежность брандмауэра ставились под угрозу ненужным программным обеспечением. Поэтому, во время установки вы только должны выбрать только те наборы, которые отмеченны как "Required" в документации: bsd, baseXX.tgz, etcXX.tgz. Нет никакой необходимости в установке компилятора (compXX.tgz) или пользовательских утилит, которые могут сильно помочь злоумышленникам (смотрите PUIS). После первой перезагрузки мы можем начать настраивать некоторые файлы конфигурации; по умолчанию, 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 $ Систему считают безопасной также с этими включенными сервисами (см. ABSO); так или иначе, выведение из строя их всех не нанесет нам никакого вреда. Хорошей практикой будет редактирование файла /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" (см. CARP для получения дополнительной информации), вынуждая, таким образом, разработчиков OpenBSD создать новый протокол, существенно отличающийся от VRRP. CARP принадлежит семейству multicast протоколов, объединяя несколько физических компьютеров одним или несколькими виртупльными адресами. Одна из этих машин является хозяином группы (master) и отвечает на все пакеты, адресованные группе. Остальные машины (backups) находятся в режиме ожидания, готовые в любой момент занять место павшего товарища. С определенным, задаваемым, интервалом, master объявляет о себе с помощью IP протокола 112. В случае аго отказа, функцию рассылки объявлений берет на себя другой хост группы. Выбор master осуществляется на основании большего количества выдаваемых за период времени объявлений. При возвращении прежнего master-a, функция рассылки объявлений возвращается к нему. Как вы могли заметить, CARP только создает и управляет виртуальными интерфейсами. Для синхронизации же данных между хостами системный администратор должен использовать pfsync(4), rsync или какой другой протокол. 4.1 Параметры конфигурации Конфигурирование CARP происходит с помощью команд sysctl(8) и ifconfig(8). Для sysctl(8) есть три доступных переменных: * 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(8), при конфигурации 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(4) интерфейса * 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 Для получения дополнительной информации обратитесь к PFFAQ. 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 0 minnie# 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 -> 1 daisy# 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 0x5 daisy# 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 7. Приложения 7.1 Ссылки [MISC17] - Filtrage applicatif : le cas des clients web, mail et p2p (MISC N?17) [PUIS] - Practical UNIX and Internet Security, Simson Garfinkel and Gene Spafford, O'Reilly, 2003 [ABSO] - Absolute OpenBSD, Michael W. Lucas, No Starch Press, 2003 [CARP] - "CARP License" and "Redundancy must be free" [PFFAQ] - PF: The OpenBSD Packet Filter [RFC3768] - RFC 3768, Virtual Router Redundancy Protocol (VRRP) [RFC2281] - RFC 2281, Cisco Hot Standby Router Protocol (HSRP) 7.2 Библиография The Common Address redundancy Protocol (CARP) Firewall Failover with pfsync and CARP Firewalling with OpenBSD's PF packet filter, Peter N. M. Hansteen, 2008 The Book of PF, Peter N. M. Hansteen, No Starch Press, 2008 The OpenBSD PF Packet Filter Book, Jeremy C. Reed, Reed Media Services, 2006 Буду рад предложениям и замечаниям, чтобы улучшить эту статью на msgibnev(ого-го какая собака)gmail.com
