+ PF: Начало
+ Списки и макросы
+ Таблицы
+ Фильтрация пакетов
+ NAT
+ Перенаправление трафика
+ Шаблоны для создания наборов правил
PF: Начало
----------
Активация:
Для активизации и чтения правил конфигурации pf при начальной загрузке, необходимо в [6]/etc/rc.conf прописать следующее:
pf=YES
Для вступления изменений в силу, необходимо перезагрузить систему. Активизировать и остановить pf можно используя программу pfctl(8):
# pfctl-e
# pfctl-d
# pfctl-d
для запуска и останова соответственно. Обратите внимание, что загрузка правил при этом не производится, их необходимо подгружать отдельно, до или после запуска pf.
Конфигурация:
pf читает правила конфигурации из файла [7]/etc/pf.conf во время
загрузки, когда выполняются [8]rc.scripts. Обратите внимание, что
/etc/pf.conf - название по умолчанию и он представляет собой просто
текстовый файл, содержащий наборы правил, загружаемые и
интерпретируемые pfctl(8) и вставляемые в pf(4). Для некоторых
приложений наборы правил могут располагаться в других файлах и
подгружаться после загрузки системы. Как и другие приложения UNIX, pf
обладает большой гибкостью.
Файл pf.conf состоит из семи частей:
1. Макросы: Определяемые пользователем переменные, которые могут
содержать адреса IP, имена интерфейсов, и т.д.
2. Таблицы: Применяются для хранения списков IP адресов
3. Опции: Параметры, влияющие на работу pf
4. Scrub: Подготовка пакета к нормализации и дефрагментации
5. Очереди: Обеспечивает управление полосой пропускания и
установку приоритетов пакета.
6. Трансляции: Контроль NAT и перенаправлением пакета
7. Правила фильтрации: Осуществляют выборочную фильтрацию пакетов
на интерфейсах
За исключением макросов и таблиц порядок следования разделов в файле
должен быть таким же, но допускается отсутствие некоторых пунктов.
Пустые строки игнорируются, и строки начинающийся с # считаются
комментарием.
Управление:
После начальной загрузки управление pf может осуществляться через
программу pfctl(8). Вот несколько примеров:
# pfctl -f /etc/pf.conf загрузить pf.conf
# pfctl -nf /etc/pf.conf анализировать файл, но не загружать
# pfctl -Nf /etc/pf.conf загрузить только правила NAT из файла
# pfctl -Rf /etc/pf.conf загрузить только правила фильтрации
# pfctl -sn показать текущие правила NAT
# pfctl -sr показать текущие правила фильтрации
# pfctl -ss показать текущее состояние таблиц
# pfctl -si показать статистику правил и состояние счетчиков
# pfctl -sa показать все
Для полного списка команд смотрите man pfctl(8).
Списки и макросы
----------------
Списки:
Списки позволяют определять множества, имеющие общие признаки в
пределах правила - такие как IP адреса, номера портов и т.д. Таким
образом, вместо прописывания нескольких правил фильтрации для каждого
IP адреса, который должен быть заблокирован, мы можем определить
список IP адресов в пределах одного правила. Списки должны находиться
внутри скобок {}.
Когда pfctl(8) доходит до списка при загрузке наборов правил, он
раскладывает их на отдельные правила, для каждого элемента списка. Для
примера:
block out on fxp0 from { 192.168.0.1, 10.5.32.6 } to any
Будет преобразован в:
block out on fxp0 from 192.168.0.1 to any
block out on fxp0 from 10.5.32.6 to any
Множественные списки могут применяться не только для блокировки:
rdr on fxp0 proto tcp from any to any port { 22 80 } -> 192.168.0.6
block out on fxp0 proto { tcp udp } from { 192.168.0.1, 10.5.32.6 } to any port { ssh telnet }
Стоит отметить, что запятая в списке является необязательной.
Макросы:
Макросы - определяемые пользователем переменные, которые могут держать
IP адреса, номера портов, имена интерфейсов, и т.д. Макросы позволят
облегчить написание наборов правил и сделают поддержание набора правил
несравненно легче.
Имена макросов должны начаться с символа и могут содержать символы,
цифры, и символы подчеркивания. Названия макросов не могут носить
имена зарезервированных слов, типа pass, out, или queue.
ext_if = "fxp0"
block in on $ext_if from any to an
Это создаст макрос с именем ext_if. При использовании макроса, его
имени должен предшествовать знак $.
Макросы также могут быть расширены до списков.
friends = "{ 192.168.1.1, 10.0.2.5, 192.168.43.53 }"
Макросы могут определяться рекурсивно. В этом случае должен
использоваться следующий синтаксис:
host1 = "192.168.1.1"
host2 = "192.168.1.2"
all_hosts = "{" $host1 $host2 "}"
Теперь макрос $all_hosts расширен до значений 192.168.1.1, 192.168.1.2.
Таблицы
--------
Введение:
Таблицы используются для хранения группы адресов IPv6 и/или IPv4.
Поиски в таблице занимают гораздо меньше времени и потребляют меньше
ресурсов, чем списки. По этой причине, таблица идеальна чтобы хранить
большую группу адресов, поскольку время поиска в таблице, содержащей
50 000 адресов - не намного больше чем для 50 адресов. Таблицы могут
использоваться следующими способами:
* источник и/или адрес назначения для filter, scrub, NAT, и
redirection rules
* адрес трансляции для правил NAT
* адрес переназначения для правил редиректа
* адрес назначения для правил фильтрации route-to, reply-to, и
dup-to
Таблицы определяются в pf.conf или с помощью pfctl(8).
Конфигурация:
В pf.conf таблицы создаются используя директиву table. Следующие
атрибуты могут быть определены для каждой таблицы:
* const - содержание таблицы не может быть изменено после ее
создания. Когда этот атрибут не определен, pfctl(8) может
использоваться, чтобы добавлять или удалять адреса из таблицы в
любое время, при выполнении с securelevel(7), равным двум и выше.
* persist - заставляет ядро сохранять таблицу в памяти, даже когда
никакие правила к ней не обращаются. Без этого атрибута, ядро
автоматически удалит таблицу, когда последнее правило, ссылающееся
на нее будет отработано.
Пример:
table { 192.0.2.0/24 }
table const { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
table persist
block in on fxp0 from { , } to any
pass in on fxp0 from to any
Адреса могут также быть определены, используя модификатор типа
отрицание (или "не"):
table { 192.0.2.0/24, !192.0.2.5 }
Таблица goodguys теперь содержит адреса сети 192.0.2.0/24, за
исключением адреса 192.0.2.5.
Обратите внимание, что имена таблицы всегда включаются в <>.
Таблицы могут также могут заполняться из файлов, содержащих список
адресов IP и сетей:
table persist file "/etc/spammers"
block in on fxp0 from to any
Файл/etc/spammers содержал бы список IP адресов или сетей CIDR. Любая
строка начинающаяся с #, будет обработана как комментарий и
проигнорирована.
Управление с помощью pfctl:
Таблицы могут управляться на лету, используя pfctl(8). Например, для
добавления в таблицу :
# pfctl -t spammers -Tadd 218.70.0.0/16
Это также откроет таблицу, если она не существует. Посмотреть значения
в таблице:
# pfctl -t spammers -Tshow
Аргумент -v может использоваться совместно с -Tshow для отображнения
каждой записи в таблице. Для удаления адреса из таблицы:
# pfctl -t spammers -Tdelete 218.70.0.0/16
Для получения дополнительной информации, смотрите pfctl(8).
Определение адресов:
В дополнение к IP адресу, хосты могут обозначаться по имени. Когда имя
хоста разрешается в IP адрес, то оно может быть помещено в таблицу.
Также IP адреса могут быть введены в таблицу с использованием имени
интерфейса или ключевого слова "self", при этом в таблицу будут
добавляться все IP адреса, назначенные интерфейсу.
Соответствие адресов:
Поиск адреса в таблице возвратит наиболее соответствующее значение.
Это учитывается при создании таблиц типа:
table { 172.16.0.0/16, !172.16.1.0/24, 172.16.1.100 }
block in on dc0 all
pass in on dc0 from to any
К любому пакету, входящему через dc0 будут применяться следующие
правила:
* 172.16.50.5 - самое точное соответствие - 172.16.0.0/16; пакет
соответствует таблице и будет передаваться
* 172.16.1.25 - самое точное соответствие - !172.16.1.0/24; пакет
соответствует входу в таблицу, но тот вход инвертирован
(использует "!" модификатор); пакет не соответствует таблице и
будет блокирован
* 172.16.1.100 - точное значение 172.16.1.100; пакет соответствует
таблице и будет передан
* 10.1.4.55 - не соответствует таблице и будет блокирован
Фильтрация пакетов
------------------
Введение:
Фильтрация пакета - выборочное принятие или блокирование пакета,
проходящего через сетевой интерфейс. pf(4) может использоваться для
контроля пакетов на 3 уровне модели OSI (IPv4 и IPv6) и 4 уровне
модели OSI (TCP, UDP, ICMP, и ICMPv6). Наиболее часто используется в
качестве критериев оценки - протокол, адрес назначения, источник и
порт адресата.
Правила фильтра определяют критерии, которым пакет должен
соответствовать. Правила просматриваются последовательно. Если пакет
не соответствует правилу, содержащему ключевое слово quick, пакет
будет оценен, как не соответствующий ни одному правилу, прежде, чем
будетпросмотрен весь список. Приоритет имеет последнее правило списка,
соответствующее пакету. Есть подход "разрешать все" в начале списка,
тогда, если пакет не блокируется ни одним последующим правилом, он
будет пропущен.
Синтаксис правил:
Полный синтаксис правила:
action direction [log] [quick] on interface [af] [proto protocol] \
from src_addr [port src_port] to dst_addr [port dst_port] \
[tcp_flags] [state]
- action
Действие, которое будет применяться к пакету - это pass или block.
pass передаст пакет назад к ядру для дальнейшей обработки , в то время
как block будет реагировать в соответствии с [16]block-policy. Реакция
по умолчанию может быть отменена, определяя или block drop или block
return.
- direction
Описывает направление движения пакета - in или out.
- log
Определяет, что пакет должен быть зарегистрирован через pflogd(8).
Если правило определено как keep state, modulate state, или synproxy
state, то будет зарегистрирован только первый пакет, создавший
правило. Чтобы регистрировать все пакеты, используйте log-all.
- quick
Если пакет соответствует правилу quick, правило считают последним
правилом соответствия, и предпринимается указанное действие.
- interface
Имя сетевого интерфейса, через который проходит пакет.
- af
Семейство адреса пакета, или inet для IPv4 или inet6 для IPv6. PF
обычно способен определить этот параметр, анализируя источник и/или
адрес назначения.
- protocol
Протокол пакета:
* tcp
* udp
* icmp
* icmp6
* Имя протокола из [17]/etc/protocols
* Номер протокола от 0 до 255
* Используя [18]список
- src_addr, dst_addr
Источник/адрес назначения в заголовке IP. Адреса могут быть определены
как:
* Единственный адрес IPv4 или адрес IPv6.
* Блок сети CIDR
* Полностью определенное имя домена, которое будет определено через
DNS после загрузки правил. Все определенные имена будут заменены
IP адресами.
* Имя сетевого интерфейса. Любые адреса, назначенные интерфейсу,
будут вставлены в правило.
* Имя сетевого интерфейса, сопровождаемого / сетевой маской
(например /24). Каждый адрес на интерфейсе будет объединен с
сетевой маской, чтобы формировать блок сети CIDR
* Имя сетевого интерфейса в круглых скобках (). Это говорит PF
модифицировать правило, если IP адрес(а) на названном интерфейсе
изменяется. Это полезно на интерфейсе, получающего адрес через
DHCP или модемного соединения, поскольку не надо каждый раз
перезагружать правила.
* Имя сетевого интерфейса, сопровождаемого ключевыми словами
:network или :broadcast. В результате в правила будет загружен
адрес сети CIDR (к примеру 192.168.0.0/24) или широковещательный
адрес (к примеру 192.168.0.255)
* Таблица.
* Любое вышеупомянутое, но отрицаемое(инвертированное) с
использованием ! ("не") модификатора.
* Набор адресов, используя список
* Ключевое слово any
* Ключевое слово all, сокращенное от from any to any.
- src_port, dst_port
Порт источника/адресата. Порты могут быть определены как:
* Номер между 1 и 65535
* Имя протокола из [19]/etc/services
* Набор портов, используя список
* Диапазон:
+ ! = (не равный)
+ < (меньше чем)
+ > (больше чем)
+ <= (меньше чем или равный)
+ >= (больше чем или равный)
+ > <(диапазон)
+ <> (обратный диапазон)
Последние два - двойные операторы (они берут два параметра) и не
включают параметры в диапазон.
- tcp_flags
Определяет флаги, которые должны быть установлены в заголовке TCP при
использовании proto tcp. Флаги определяются как flags check/mask.
Например: flags S/SA - PF будет смотреть на S и A (SYN и ACK) флаги и
соответствовать правилу, если установлен флаг SYN.
state
Определяет, сохраняется ли информация о состоянии на пакетах,
соответствующих этому правилу.
* keep state - работает с TCP, UDP, и ICMP
* modulate state - работы только с TCP. PF генерирует Initial
Sequence Numbers (ISNs) для пакетов, соответствующих этому
правилу.
* synproxy state - проксирует входящие TCP соединения, что помогает
защищать сервера от TCP SYN флуда и спуфинга. Эта опция включает
функциональные возможности keep state и modulate state.
Default Deny:
Рекомендуемой практикой является "default deny".
Для создания политики "default deny":
block in all
block out all
Это заблокирует все пакеты, протоколы, IP адреса отовсюду куда угодно.
Прохождение трафика:
Теперь трафику необходимо явно пройти разрешающиее правило, чтобы быть
пропущеным. Это - то, где критерии пакета типа порта
источника/адресата, источника/адреса назначения, и протокола входят в
игру. Всякий раз, когда трафику разрешают пройти через систему сетевой
защиты, правило(а) должно быть записано настолько конкретным,
насколько это возможно. Это должно гарантировать,что только
разрешенный трафик пройдет через систему защиты.
Некоторые примеры:
# Pass traffic in on dc0 from the local network, 192.168.0.0/24,
# to the OpenBSD machine's IP address 192.168.0.1. Also, pass the
# return traffic out on dc0.
pass in on dc0 from 192.168.0.0/24 to 192.168.0.1
pass out on dc0 from 192.168.0.1 to 192.168.0.0/24
# Pass TCP traffic in on fxp0 to the web server running on the
# OpenBSD machine. The interface name, fxp0, is used as the
# destination address so that packets will only match this rule if
# they're destined for the OpenBSD machine.
pass in on fxp0 proto tcp from any to fxp0 port www
Ключевое слово quick:
Как говорилось выше, каждый пакет оценивается набором правил сверху
вниз. По умолчанию, пакет отмечен для прохода, что может быть изменено
в соответствии с любым правилом, и это может произойти несколько раз
до конца списка правил. Последнее подходящее правило "побеждает". Есть
одно исключение: использование ключевого слова quick, которое отменяет
любую дальнейшую обработку пакета и осуществляет указанное в правиле
действие над пакетом.
Посмотрим на пару примеров:
Неправильно:
block in on fxp0 proto tcp from any to any port ssh
pass in all
В этом случае блокирующее правило будет оценено, но никогда
применяться не будет, так как следующее правило разрешает любой
трафик.
Уже лучше:
block in quick on fxp0 proto tcp from any to any port ssh
pass in all
Эти првила оцениваются по другому, так как блокирующее правило указано
с параметром quick, что приведет к блокировке и прекращению обработки
пакета, пришедшего на порт ssh. Весь остальной трафик будет пропущен.
Keeping State:
Одной из важных способностей PF является "keeping state" или "stateful
inspection". Контроль состояния относится к способности PF проследить
состояние или прогресс сетевого подключения. информацию о каждом
подключении в таблице состояний, PF способен быстро определить,
принадлежит ли пакет, проходящий через систему сетевой защиты уже
установленному подключению. Если пакет принадлежит уже установленному
соединению, то проверки его правилами не происходит.
Keeping state имеет много преимуществ, включая упрощение набора правил
и повышение производительности пакетного фильтра. PF способен
согласовывать пакеты, двигающиеся в любом направлении, и так как
пакеты, соответствующие stateful подключению не проходят ruleset
оценку, время, затрачиваемое PF на обработку пакетов может быть
значительно уменьшено.
Когда в правиле установлена опция keep state, первый пакет,
соответствующий правилу создает "state" между отправителем и
получателем. Теперь не только пакеты от отправителя к получателю, но и
от получателя к отправителю не проходят проверку правилами фильтрации.
Например:
pass out on fxp0 proto tcp from any to any keep state
Таким образом любой исходящий трафик TCP от кого угодно куда угодно и
обратный трафик будет пропущен и будут созданы временные правила
"state" между отправителем и получателем. Это - хорошая особенность,
ее использование значительно улучшает работу вашей системы сетевой
защиты, поскольку поиски в правилах " state" значительно быстрее чем
прохождение пакета через правила фильтра.
modulate state работает точно так же как и keep state, за исключением
того, что это работает только с пакетами TCP. С использованием
modulate state Initial Sequence Number (ISN) исходящего соединения
будет рандомизирован. Это полезно для того, чтобы защитить
подключения, инициализированные некоторыми операционными системами, у
которых ISN легко предсказуем.
Keep state на исходящих пакетах TCP, UDP, и ICMP с рандомизацией ISN:
pass out on fxp0 proto tcp from any to any modulate state
pass out on fxp0 proto { udp, icmp } from any to any keep state
Другое преимущество keeping state - это передача ICMP трафика через
пакетный фильтр. Для примера, если keep state установлен для TCP
соединений, ICMP пакеты в обычном состоянии заблокированы, то после
установления соединения ICMP пакеты будут проходить через через
систему сетевой защиты.
Важно обратить внимание, что stateful подключения ограничены
интерфейсом, на котором они были созданы. особенно важно это на
маршрутизаторах и системах сетевой защиты, работающих с pf, особенно
когда действует политика "default deny". Если система сетевой защиты
сохраняет состояние на всех исходящих подключениях на внешнем
интерфейсе, пакетам все еще нужно явно проходить внутренний интерфейс.
Обратите внимание что правила nat, binat, и rdr неявно создают "state"
для того, чтобы пакет прошел фильтр.
Keeping State для UDP:
Каждый слышал, что для UDP нельзя создать "state" , так как это
протокол без обратной связи! В то время как истинно, что UDP сеанс
связи не имеет никакого понятия состояния (явное начало и останов
сеанса связи), это не имеет никакого воздействия на способность PF
создать состояние для UDP сеанса. В случае протоколов без "начальных"
и "конечных" пакетов, PF просто следит, сколько прошло времени с
момента прохождения первого пакета. Если время ожидания превышено,
правило "state" удаляется. Значения времени ожидания могут быть
установлены в разделе [20]вариантов pf.conf
Флаги TCP:
* F: Отправитель закончил посылку байтов.
* S: Флаг для синхронизации номеров сегментов, используется при
установлении связи.
* R: Прерывание связи.
* P: Этот сегмент требует выполнения операции push. Получатель
должен передать эти данные прикладной программе как можно быстрее.
* A: Номер октета, который должен прийти следующим, правилен.
* U: Флаг важной информации, поле Указатель важной информации имеет
смысл, если urg=1.
* E: ECE - Уведомление о перегрузке (пр.п. - не знаю что такое...)
* W: CWR - Уменьшение окна перегрузки (пр.п. - не знаю что такое...)
PF оценивает флаги когда в правиле встречается ключевое слово flags и
имеет следующий синтаксис:
flags check/mask
mask говорит смотреть только указанные флаги и check определяет, какой
флаг(и) должен "включен" в заголовке пакета для соответствия правилу.
pass in on fxp0 proto tcp from any to any port ssh flags S/SA
Вышеупомянутое правило передает трафик TCP с установленным флагом SYN,
и только при наличии флагов SYN и ACK.
Обратите внимание: в предыдущих версиях OpenBSD, поддерживался
следующий синтаксис:
. . . flags S
Теперь нет. /mask всегда должна быть определена.
Контоль флагов очень часто используется вместе с keep state правилами
для улучшения контроля за динамическими правилами.
pass out on fxp0 proto tcp all flags S/SA keep state
Это разрешило бы создание динамического правила на любом уходящем
пакете TCP с установленным флагом SYN, и только при наличии флагов SYN
и ACK.
Нужно быть внимательным при использовании флагов., понимать что
конкретно делается и почему. Советам тоже особо не верьте, так как
многие бы посоветовали создавать правило "только если флажок SYN
установлен и никакие другие". Это кончится следующим:
. . . flags S/FSRPAUEW bad idea!!
Проблема - некоторые сайты, используют флаг ECN и любой сайт,
используя ECN, пробуя соединиться с Вами, будет отклонен в
соответствии с правилом выше. Намного лучше:
. . . flags S/SAFR
В то время как это является практическим и безопасным, также ненужно
проверять флаги FIN и RST если трафик [21]scrubbed.
Процесс вычищения заставит PF блокировать любые входящие пакеты с
незаконными комбинациями флагов TCP (типа SYN и FIN или SYN и RST).
Строго рекомендуют всегда вычистить входящий трафик:
scrub in on fxp0
.
.
.
pass in on fxp0 proto tcp from any to any port ssh flags S/SA keep state
TCP SYN Proxy:
Обычно, когда клиент устанавливает соединение с сервером вне сети, pf
передает пакеты [22]установления связи между клиентом и сервером по
мере их поступления. PF также имеет способность проксировать процесс
создания соединения. При этом PF установит связь с клиентом,
инициирует установление связи с сервером и затем соединит клиента и
сервер. Преимущества этого процесса в том, что никакие пакеты не
посылаются серверу прежде, чем клиент завершит установление связи. Это
устраняет угрозу spoofed TCP SYN флуда, та как клиентское подключение
будет неспособно завершить установление связи и спуфить сервер.
pass in on $ext_if proto tcp from any to $web_server port www flags S/SA synproxy state
Теперь соединение с сервером будет проксировано пакетным фильтром.
Так как при работе synproxy state образуются динамические правила, то
SYN прокси включает в себя функциональность keep state и modulate
state.
SYN прокси-сервер не будет работать, если PF выполняется на bridge(4).
Блокирование спуфинга:
Под термином "spoofing" понимается подмена IP адреса в пакетах с целью
скрыть их реальный адрес или выдать себя за другой узел сети. При этом
злоумышленник может попытаться получить доступ к сетевым услугам,
которые ограничены некоторыми IP адресами или скрывать свой истинный
адрес при проведении атаки на сеть.
PF предлагает некоторую защиту против спуфинга с помощью ключевого
слова antispoof
antispoof [log] [quick] for interface [af]
- log
Определяет, что соответствующий пакет должен быть зарегистрирован
через pflogd (8).
- quick
Если пакет соответствует правилу quick, правило считают последним
правилом соответствия, и предпринимается указанное действие.
- interface
Сетевой интерфейс, на котором активизируется защита от спуфинга. Это
может также быть списком интерфейсов.
- af
Семейство адреса - или inet для IPv4 или inet6 для IPv6.
Пример:
antispoof for fxp0 inet
После загрузки наборов правил, там где встречено ключевое слово
antispoof правило будет расширено в два правила фильтра. Принимая, что
интерфейс fxp0 имеет адрес IP 10.0.0.1 и подсетевую маску
255.255.255.0 (то есть,/24), вышеупомянутое правило расширилось бы до:
block in on ! fxp0 inet from 10.0.0.0/24 to any
block in inet from 10.0.0.1 to any
Эти правила достигают двух вещей:
* Блокирует весь трафик, исходящий из сети 10.0.0.0/24, который не
проходит в через fxp0. Так как сеть 10.0.0.0/24 находится на
интерфейсе fxp0, пакеты с исходным адресом в этом сетевом блоке
никогда не должны появляться ни на каком другом интерфейсе.
* Блокирует весь входящий трафик с IP адреса 10.0.0.1 на fxp0. Хост
никогда не не должен посылать пакеты себе через внешний интерфейс,
так что любые входящие пакеты с исходным адресом, принадлежащим
хосту можно счесть злонамеренными.
ОБРАТИТЕ ВНИМАНИЕ: При расширении правила antispoof также блокируются
пакеты, посланные по петлевому интерфейсу к местным адресам. Эти
адреса нужно передать явно. Пример:
pass in quick on lo0 all
antispoof for fxp0 inet
Использование antispoof должно быть ограничено интерфейсами, которым
был назначен IP адрес. Использование antispoof на интерфейсе без IP
адреса приведет к правилам фильтрации типа:
block drop in on ! fxp0 inet all
block drop in inet all
С этими правилами есть риск блокирования всего прибывающего трафика на
всех интерфейсах.
Опции IP:
По умолчанию pf блокирует пакеты с установленными опциями IP. Это
затрудняет определение типа ОС такими утилитами, как nmap. Если Вы
имеете приложение, которое требует прохождения этих пакетов, типа
multicast или IGMP, Вы можете использовать директиву allow-opts:
pass in quick on fxp0 all allow-opts
Пример правил фильтрации:
Ниже - пример фильтрующих правил. Сервер с запущенным pf действует как
система сетевой защиты между маленькой, внутренней сетью и Internet.
Показаны только фильтрующие правила; правила queueing, nat, rdr и т.д.
в этом примере пропущены.
------------------------------------------------------------------------------
ext_if = "fxp0"
int_if = "dc0"
lan_net = "192.168.0.0/24"
# scrub incoming packets
scrub in all
# setup a default deny policy
block in all
block out all
# pass traffic on the loopback interface in either direction
pass quick on lo0 all
# activate spoofing protection for the internal interface.
antispoof quick for $int_if inet
# only allow ssh connections from the local network if it's from the
# trusted computer, 192.168.0.15. use "block return" so that a TCP RST is
# sent to close blocked connections right away. use "quick" so that this
# rule is not overridden by the "pass" rules below.
block return in quick on $int_if proto tcp from ! 192.168.0.15 \
to $int_if port ssh flags S/SA
# pass all traffic to and from the local network
pass in on $int_if from $lan_net to any
pass out on $int_if from any to $lan_net
# pass tcp, udp, and icmp out on the external (Internet) interface.
# keep state on udp and icmp and modulate state on tcp.
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
# allow ssh connections in on the external interface as long as they're
# NOT destined for the firewall (i.e., they're destined for a machine on
# the local network). log the initial packet so that we can later tell
# who is trying to connect. use the tcp syn proxy to proxy the connection.
pass in log on $ext_if proto tcp from any to { !$ext_if, !$int_if } \
port ssh flags S/SA synproxy state
------------------------------------------------------------------------------
NAT
---
Введение:
Трансляция Сетевого адреса (NAT) - отобразить полную сеть (или сети) к
единственному IP адресу. NAT необходим, когда количество IP адресов,
Выделенный Вам Вашим провайдером меньше чем общее количество
компьютеров, для которых Вы желаете обеспечить доступ Internet. NAT
описан в RFC 1631.
NAT позволяет Вам использовать в своих интересах зарезервированные
блоки адресов, описанные в RFC 1918. Как правило, Вы будете
использовать один или несколько блоков адресов из следующего
диапазона:
* 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
* 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
* 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)
Для работы NAT в OpenBSD необходимо иметь как минимум два сетевых
интерфейса, один из которых выходит в Internet, а второй во внутреннюю
сеть. NAT будет транслировать запросы с внутренней сети, так, как
будто они исходят от Вашей OpenBSD системы.
Как работает NAT:
Когда клиент из внутренней сети посылает запрос в Internet, создаются
IP пакеты, которые шлются к месту назначения. Эти пакеты содержат всю
информацию об обратном адресе, необходимую для получения ответа. NAT
заинтересован этими частями информации:
* Исходный адрес IP (например, 192.168.1.35)
* Исходный TCP или UDP порт (например, 2132)
Когда пакеты проходят через NAT, они изменяются таким образом, чтобы
они, казалось, исходили от NAT шлюза непосредственно. NAT будет делать
запись изменений в таблице состояний так, чтобы это могло,
a), чтобы полностью вернуть изменения на возвращающихся пакетах и
b) гарантировать, что вернувшиеся пакеты пройдут систему сетевой
защиты и не будут блокированы.
Например, могут произойти следующие изменения:
* Исходный IP: будет заменен внешним адресом шлюза (например, 24.5.0.5)
* Исходный порт: будет заменен беспорядочно выбранным,
неиспользованным портом на шлюзе (например, 53136)
Ни внутренняя машина, ни главный компьютер Internet не знают об этих
шагах трансляции. Для внутренней машины NAT система - просто шлюз
Internet. Для ресурса, распложенного в Internet пакеты прибывают
непосредственно от NAT системы; он не догадывается о существовании
клиентской машины. Когда ресурс отвечает на запрос внутренней машины
он будет обращаться к внешнему IP адресу NAT шлюза (24.5.0.5) и порту
(53136). NAT шлюз будет искать соответствующую запись в таблице ,
чтобы определить, соответствуют ли пакеты ответа уже установленному
подключению. Уникальное соответствие будет найдено на основании
комбинации IP/порта, которая говорит PF, что пакеты принадлежат
подключению, инициализированному внутренней машиной 192.168.1.35. PF
будет тогда делать обратные изменеия для приходящих пакетов и
отправлять пакеты внутренней машине.
Трансляция ICMP пакетов происходит таким же способом, но без исходной
модификации порта.
NAT и фильтрация пакетов:
ОБРАТИТЕ ВНИМАНИЕ: Оттранслированные пакеты должны все еще должны
проходить через механизм фильтрации и будут блокированы или переданы
на основании правил фильтрации. Единственное исключение будет сделано
при наличии ключевого слова pass при использовании в пределах правила
NAT. Это заставит NATed пакеты передавать через механизм фильтрации.
Также знайте, что трансляция происходит перед фильтрацией и механизм
фильтрации будет видеть оттранслированный пакет с оттранслированным
адресом IP и портом.
IP форвардинг:
Так как NAT почти всегда используется на маршрутизаторах и сетевых
шлюзах, вероятно будет необходимо допустить форвардинг пакетом между
сетевыми интерфейсами OpenBSD машины. Это осуществляется с помощью
механизма sysctl(3) :
# sysctl -w net.inet.ip.forwarding=1 # sysctl -w
net.inet6.ip6.forwarding=1 (if using IPv6)
Для того, чтобы сделать изменения постоянными, внесите в
/etc/sysctl.conf:
net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1
Эти строки присутствуют, но прокомментированны (знаком #) в заданной
по умолчанию установке. Удалите #, и сохраните файл. Форвардинг
пакетов IP будет будет разрешен после перезагрузки.
Конфигурирование NAT:
Полный формат правила NAT выглядит следующим образом:
nat [pass] on interface [af] from src_addr [port src_port] to \
dst_addr [port dst_port] -> ext_addr [pool_type] [static-port]
- nat
Ключевое слово, которое начинает правило NAT
- pass
Транслировать пакеты, полностью обходя правила фильтрации
- interface
Имя сетевого интерфейса, на который будут транслироваться пакеты
- af
Семейство адреса пакета, или inet для IPv4 или inet6 для IPv6. PF
обычно способен определить этот параметр, анализируя источник
и/или адрес назначения.
- src_addr
Внутренний адрес пакетов, которые будут оттранслированы. Исходный
адрес может быть определен как:
* Единственный адрес IPv4 или адрес IPv6.
* Блок сети CIDR
* Полностью определенное имя домена, которое будет определено через
DNS после загрузки правил. Все определенные имена будут заменены
IP адресами.
* Имя сетевого интерфейса. Любые адреса, назначенные интерфейсу,
будут вставлены в правило.
* Имя сетевого интерфейса, сопровождаемого / сетевой маской
(например /24). Каждый адрес на интерфейсе будет объединен с
сетевой маской, чтобы формировать блок сети CIDR
* Имя сетевого интерфейса, сопровождаемого ключевыми словами
:network. В результате в правила будет загружен адрес сети CIDR (к
примеру 192.168.0.0/24).
* Таблица.
* Любое вышеупомянутое, но отрицаемое(инвертированное) с
использованием ! ("не") модификатора.
возможно у Вас отключен javascript, если включен - просто обновите страницу