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

Основные принципы работы брандмауэра

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

Два осовных термина, которые будут наиболее часто встречаться по ходу этой части руководства, это "Правило" и "Набор правил". Правило - это конфигурация или действие для просмотра или управления трафиком. Набор правил - это сумма всех правил созданных пользователем или сформированных автоматически. В pfSense, как и в большинстве брандмауеров, наборы правил оцениваютя по принципу первого совпадения, что означает если Вы читаете список правил сверху-вниз - выполняться будет только первое правило удовлетворяющее условию. После достижения соответствия и выполнения действия требуемого правилом обработка останавливается. Об этом следует помнить всегда при создании нового набора правил, особенно если эти правила касаются ограничения трафика. Разрешающие правила должны быть расположены в нижней части набора, это позволит произвести исключения на ранних стадих фильтрации.

Размер таблицы состояний

Таблица состояний брандмауера имеет свой максимальный размер, сделано это для того, чтобы предотвратить исчерпание ресурсов памяти. Каждое такое состояние занимает примерно 1Кб RAM. По умолчанию в pfSense размер таблицы состояний установлен в 10000, что значит что Вы можете иметь не более 10000 активных сетевых соединений проходящих через Ваш брандмауер, а любые дополнительные соединения будут отброшены. Это значение можно изменить на странице System -> Advanced в веб-конфигураторе (рис 6.1 "Увеличение размера таблицы состояний до 50000"). Введите требуемое число состояний и оставьте поле пустым, для того чтобы значение установилось по умолчанию.

Рисунок 6.1. Увеличение размера таблицы состояний до 50000

Входная фильтрация

Входная фильтрация имеет отношение к трафику входящему в Вашу сеть из внешней сети Интернет. При использовании multi-WAN системы Вы получите несколько таких точек входа. По умолчанию в системе pfSense применяется политика блокирующая весь трафик приходящий на WAN извне. В свою очередь ответы WAN интерфейса на трафик инициируемый внутренними сетями позволяются автоматически посредством таблицы состояний.

Выходная фильтрация

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

Из своего опыта работы многочисленными брандмауэрами множества разработчиков во множестве организаций, я могу сказать, что большинство пользователей не используют выходную фильтрацию. Это может вызвать административные проблемы, поскольку каждое новое приложение может потребовать дополнительных портов или протоколов в брандмауэре. в некоторых средах это весьма затруднительно, поскольку администраторы действительно не знают, что происходит в сети и опасаются повредить работе системы. В других системах, это не возможно по причинам политики рабочего места. Однако следует бороться за то, чтобы позволить покидать сеть минимальному необходимому трафику, насколько это возможно. Серьёзная выходная фильтрация важна по нескольким причинам:

1. Ограничить воздействие поставленной под угрозу системы -вредоносное ПО обычно использует порты не требуемые в стандартных сетях. Многие бот-вирусы используют порты для IRC, некоторые полагаются на более общие, такие как TCP 80 (HTTP) чтобы избежать выходной фильтрации. Например, если Вы запретите использование порта TCP 6667 (стандартный порт IRC), Вы сразу ликвидируете функционал множества ботов работающих по данному порту.? Вот характерный пример, который мы наблюдал - случай, когда внутренний интерфейс pfSense имел нагрузку 50-60 Мбит/с, в то время как WAN имел пропускную способность менее 1Мбит/с.

Некоторые cлучаи показывали, как боты используют систему LAN для организации DDoS атаки на различные сервера. Конкретно был использован порт UDP 80, видимо по ряду следующих причин. Во-первых, UDP позволяет отправлять большие пакеты, не завершая квитирования TCP. Для брандмауэров с сохранением состояний является нормой то, что большие пакеты TCP не будут передаваться, пока не будет успешно завершено квитирование, и это сильно ограничивает вероятность успешной DDoS атаки. Во-вторых, те кто использует выходную фильтрацию часто делают её слишком много допускающей, позволяя TCP и UDP там, где достаточно только TCP (например в случае HTTP). В конкретном случае порт UDP 80 не был разрешён набором правил выходной фильтрации, и вся DDoS билась о внутренний интерфейс, отбрасываемая брандмауэром. Я случайно заметил такое поведение - брандмауэр продолжал пыхтеть и работать без видимого ухудшения производительности, а администратор сети и не знал что происходит. Исходящий SMTP - другой характерный пример. Следует позволять SMTP только на порту TCP 25, что позволит отправлять почтовый трафик почтовому серверу вашей сети. Если ваш почтовый сервер размещён внешне, позвольте вашей сети общаться с ним только по порту TCP 25. Это позволит исключить использование вашей системы в качесте спам-зомби. Вы внесёте свой вклад в ограничение спама и препятствуете тому, чтобы ваша сеть была добавлена в черный список Интернет. Корректное решение позволяет предотвратить такие проблемы, а выходная фильтрация обеспечивает другой уровень позволяющий ограничить воздействие различных проблем.

2. Предотвращение компроментации системы - в некоторых случаях выходная фильтрация может исключить компроментацию системы. Существует множество червей и различных эксплойтов, требующих исходящего доступа при попадании во внутреннюю сеть. Удачный пример такой ситуации - червь Code Red 2001 года, который использовал систему для получения вредоносного исполняющего файла по TFTP, а затем выполнял его.

3. Ограничение несанкционирования использования приложения - великое множество приложений, вроде VPN-клиентов, P2P-клиентов, различных мессенджеров, полагаются на нетиповые порты. Используя выходную фильтрацию, Вы можете эффективно и быстро ограничить несанкционированное использование таких приложений.

4. Предотвращение утечки информации - некоторым определенным протоколам вообще никогда нельзя позволять утечку из внутренней сети.Microsoft RPC на порту TCP 135, NetBIOS на портах TCP и UDP 137-139, а так же SMB/CIFS на портах TCP и UDP 445? - типичные порты служб которым нельзя позволять покидать пределы внутренней сети. Выходная фильтрация может предотвращать утечку информации о нутренней сети в сеть Интернет и препятствует тому, что бы ваши системы инициировали попытки аутентификации с узлами в Интернет. Множество черверй полагалось на эти протоколы в недалёком прошлом.?

Подходы к выходной фильтрации

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

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

Таблица 6.1. Требования к исходящему трафику?

Затем, сконфигурируйте свои правила брандмауэра в соответствии с полученной таблицей и отбросьте всё остальное.

Другая альтернатива - включение журнала на ваши разрешающие правила и отправка журнальной (log) информации syslog серверу, для целей последующего анализа, который позволит проанализировать трафик покидающий вашу сеть. Два пакета анализа журналов поддерживают формат логов PF - fwanalog [1] и Hatchet [2]. Вы можете найти простые парсеры логов на основе сценариев, если имеете опыт работы с парсингом текстовых файлов. Это поможет создать необходимый набор правил с меньшим количеством ненужных остатков.

Блокировка против Отклонения. (Block vs Reject)

При создании правила существует два вида отклонения нежелательного трафика, это Блокировка (Block) и Отклонение (Reject)?. Блокировка реализует отклонение трафика в тихом режиме. Это поведение по умолчанию используется запрещающими правилами pfSense, следовательно в системе сконфигурированной по умолчанию, весь трафик со стороны внешней сети будет тихо отклонен. В свою очередь Отклонение ?(Reject) отправляет ответ на нежелаттельный TCP и UDP трафик, позволяя узлу, который инициирует данный трафик узнать, что в соединении ему отказано.? Хотя можно установить Reject для любого правила брандмауэра, IP протоколы кроме TCP и UDP не могут быть отклонены - в любом случае будет произведена операция типа Block.?

За прошедшие годы, среди профессионалов было много споров относительно сравнения использования Block и Reject. Некоторые утверждали, что использование Block имеет больше смысла, поскольку это "затрудняет" действия атакующих, сканирующих Интернет. Если вы используете Reject, ответ на сканирование закрытого порта сразу отсылается назад, в то время как использование Block тихо отбрасывает трафик, принуждая сканер атакующего ожидать ответ. Может быть это и так, однако, хороший сканер портов может сканировать одновременно сотни и тысяци узлов, и не дожидаться ответа от ваших закрытых портов. Существует незначительное различие в потребление ресурсов и скорости сканирования, но настолько незначительное, что его можно просто не рассматривать. Если вы блокируете весь трафик из Интернет, проявляются значительные различия между работой Block и Reject - никто не определит, что ваша система находится в on-line режиме. Если есть хотябы один открытый порт, разница минимальна, поскольку атакующий узнает что вы в режиме on-line и узнает о наличии открытых портов и о том, что вы отклоняете блокированные соединения. Поскольку нет существенного различия в блокировке через Reject, я рекомендую использовать Block для правил WAN. Для правил внутренних интерфейсов в большинстве ситуаций рекомендуется использовать Reject. Когда хост пытается получить доступ к чему либо запрещённому правилами брандмауэра, приложение пытающееся поолучить доступ может зависнуть вплоть до получения ответа (или истечения внутреннего интервала ожидания соединения - п.п.). При использовании Reject в соединение будет оказано немедленно, что позволит избежать зависания приложения. Обычно такое поведение может вызывать раздражение, но я обычно рекомендую использовать Reject, чтобы избежать возможных проблем сети при использовании Block. Есть ещё один побочный эффект который может стать решающим фактором при выборе Block или Reject. Если вы используете Reject, это позволяет пользователям легко определить свои правила выходной фильтрации, поскольку брандмауэр сообщит им что блокируется. В принципе, для внутренних пользователей возможно разобраться в правилах выходной фильтрации и при использовании Block, правда это займёт немного больше времени и усилий.

Введение в экран настройки правил брандмауэра (Firewall Rules)

В этом разделе мы проведем краткий обзор страницы Firewall->Rules. В центральном списке Вы увидите набор правил WAN, который по умолчанию имеет лишь записи блокировки частных сетей (Block privete networks) и богон-сетей (Block bogon networks). Смотрите раздел 6.5.1.3. "Блокировка частных сетей" и раздел 6.5.1.4. "Блокировка богон-сетей" для получения большего объёма информации о блокировке данного типа сетей.?

Рисунок 6.2. Правила WAN по умолчанию

Нажмите на закладку LAN, чтобы увидеть правила для LAN. По умолчанию, это только правило Default LAN -> any как видно на рисунке 6.3. "Правила по умолчанию для LAN".

Рисунок 6.3 Правила LAN по умолчанию.

Для каждого интерфейса в системе существует своя вкладка. Интерфейсы OPT будут отображаться своими описательными именами, т.е. если вы назвали свой интерфейс OPT1 как DMZ, то вкладка с его правилами будет называться DMZ.?

Нажмите кнопку [+] на экране Firewall->Rules, чтобы добавить новое правило. Кнопки сверху и снизу, позволяют добавлять новые правила. Кнопка [+] сверху добавляет правило в верх набора правил, а кнопка [+] добавляет правило вниз списка. (рисунок 6.4. "Опции добавление правил LAN"?)

Рис 6.4. Опции добавление правил LAN

Чтобы изменить правило, нажмите кнопку [e] справа, или дважды щёлкните на строке правила. Вы попадёте на страницу, где сможете произвести изменения. Смотрите раздел 6.6. "Конфигурирование правила брандмауэра" для получение дополнительной информации о доступных параметрах правил.

Правила могут быть перенесены в любую часть списка самостоятельно или в группах. Чтобы сделать это, установите флажок на правилах которые должны быть перемещены, либо щёлкните по правилу, что так же приведёт к установке его флажка, затем нажмите кнопку [<] в строке, которая должна быть под перемещёнными правилами. Когда вы перемещаете указатель мыши, появится тусклая панель указывающая, куда будут вставлены правила. После щелчка, правила будут вставлены выше выбранной строки.

Для удаления правила, нажмите кнопку [x] справо. Вы получите запрос на подтверждение удаления. Для удаления сразу нескольких правил, установите флажки в начале строк тех правил, которые должны быть удалены и нажмите кнопку [x] в низу списка.

Алиасы

Алиасы помогут Вам сгруппировать порты, узлы, сети и обращаться к созданным группам при конфигурировании правил брандмауера, NAT и шейпера. Это позволит Вам создавать более эффективные и гибкие в настройке наборы правил.

Для создания нового алиаса, перейдите на страницу Firewall -> Aliases и нажмите кнопку [+]. В pfSense, каждый алиас ограничен 299 элементами (участниками). Для добавления новых элементов к алиасу нажмите [+] в нижней части списка записей на странице Firewall -> Aliases -> Edit.

Алиасы хостов позволяют создавать группы IP адресов. Рисунок 6.5. "Пример алиаса хостов" показывает пример использования алиаса хостов для создания списка публичных web серверов.

Рисунок 6.5. "Пример алиаса хостов"?

Алиасы сетей позволяют создавать группы сетей или диапазоны IP посредством использования CIDR суммаризации. Единичные хосты так же можно включить в сетевой алиас, выбрав /32? маску сети. Рисунок 6.6. "Пример алиасов сети", показывает пример создания алиаса сети.

Рисунок 6.6. "Пример алиасов сети"?

Алиасы порта помогут произвести группировку портов и диапазонов портов. Протокол в алиасе не определяется, поскольку правило брандмауэра использующее алиас, определяет протокол. Рисунок 6.7. "Пример алиаса портов" показывает создание алиаса портов.

Рисунок 6.7. "Пример алиаса портов"?

В pfSense любое поле с красной подсветкой связано с алиасом. Если Вы введете в поле первую букву любого созданного алиаса - на экране появится выпадающий список соответствия, где Вы можете просто выбрать требуемый алиас.

Рисунок 6.8. "Автозавершение алиаса хостов" показывает, как алиас WebServers сконфигурированный ранее может использоваться в поле Destination при добавлении или редактировании правил брандмауэра. Выберите "Single host or alias", и наберите первую букву требуемого алиаса. Показываются только алиасы соответствующего типа, например для поля, требующего IP адрес или подсеть, будут отображаться только алиасы хостов или сетей.

Рисунок 6.8. Автозавершение алиасов портов

Рисунок 6.9. Автозавершение для алиаса портов

Рисунок 6.10. "Пример правила использующего алиасы" показывает правило, которое создано с использованием алиасов WebServers и WebPorts. Это правило находится на вкладке WAN и позволяет IP адрес любого источника, определённого в алиасе WebServers, который использует порты определённые в алиасе WebPorts.

Рисунок 6.10 Пример правила использующего алиасы

Если вы наведёте курсор мыши на алиас в строке правила - появится поле с содержимым алиаса. Рисунок 6.11. показывает как это выглядит для алиаса WebServers, а рисунок 6.12 - соответственно для алиаса WebPorts.

Рисунок 6.11. Содержимое алиаса WebServers

Рисунок 6.12. Содержимое алиаса WebPorts

По умолчанию ЗАПРЕЩЕНО

В сетевой безопасности существует два основных положения - по умолчанию РАЗРЕШЕНО (allow) и по умолчанию ЗАПРЕЩЕНО (Deny). Следует использовать стратегию по умолчанию ЗАПРЕЩЕНО для правил Вашего брандмауэра. Конфигурируйте свои правила на разрешение минимально необходимого трафика для потребностей вашей сети и отбрасывайте остальное. В следствии этой методики, число запрещающих правил будет минимальным. В конфигурации по умолчанию, pfSense использует? на WAN интерфейсе правило по умолчанию ЗАПРЕЩАТЬ, а на LAN - РАЗРЕШАТЬ. Весь входящий трафик Интернет запрещается, а весь трафик от LAN в интернет разрешается. Все маршрутизаторы домашнего использования используют эту методику, так же как и все проекты с открытым исходным кодом и аналогичные коммерческие решения. Однако, это не рекомендуемые параметры для работы. Пользователи pfSense часто спрашивают, "что я должен блокировать?". Такой вопрос не корректен, поскольку применим только к методике РАЗРЕШАТЬ ВСЁ по умолчанию.

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

Сокращение журнала

По умолчанию в pfSense включено журналирование (log) для правила ЗАПРЕЩЕНИЯ. Это означает, что все попытки соединения которые будут заблокированы заносятся в системный журнал. Иногда лишней информации не много, но в большинстве сред журналы сильно разростаются. У провайдеров кабельного интернета - журналы забиваются сообщениями NetBIOS от Windows машин напрямую соединёнными с широкополосными каналами. Эти хосты постоянно формируют широковещательные запросы при просмотре сети. Весь этот мусор может скрывать сообщения которые действительно могут быть важными. При добавлении на WAN интерфейс блокирующего правила без включения журналирования, этот трафик будет блокироваться, но больше не будет журналироваться.

Рисунок 6.13. Правило брандмауэра для предотвращения журналирования широковещательных сообщений

Следует добавлять подобные правила в соответствии со специфическими особенностями журнального мусора, который вы можете наблюдать в своей среде. Проверьте состояние журналов брандмауэра на странице System Logs -> Firewall, чтобы видеть, какой трафик вы блокируете и частоту данного трафика. Если какой-то трафик упоминается более чем 5 раз в минуту, вероятно следует добавить соответствующее правило блокировки, чтобы снизить лишний журнальный шум.

После установки pfSense не журналирует любой разрешённый трафик и журналирует весь отклоненный трафик. Это стандартное поведение по умолчанию практически любого брандмауэра. Такое поведение наиболее практично.

Методика создания правил

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

Что бы предотвратить блокировку web интерфейса, pfSense по умолчанию включает правило антилокаута. Это поведение конфигурируется на странице System->Advanced WebGUI Anti-lockout. Данное автоматическое правило разрешает трафик из любого источника вашей сети к любому протоколу слушающему на LAN IP. В средах осознающих безопасность, следует отключить данное правило и конфигурировать правила LAN так, чтобы только алиас доверенных хостов мог получать доступ к административным интерфейсам брандмауэра.

Так же pfSense использует функцию антиспуффинга. Эта функция реализует функциональность uRPF (Unicast Reverse Path Forwarding) в соответствии с RFC 3704. Брандмауэр проверяет каждый пакет в соответствии со своей таблицей маршрутизации и если попытка соединения происходит с исходного IP на интерфейсе, где по данным брандмауэра такой сети нет - пакет отбрасывается. Например, нечто приходящее с WAN интерфейса с адресом внутренней сети будет отбрасываться. Так же, что либо инициируемое из внутренней сети с IP источника который не находится в этом внутреннем сегменте тоже будет отбрасываться.

Опция блокировки частных сетей на WAN интерфейсе автоматически формирует правило для подсети RFC 1918. Если у вас нет частного пространства IP адресов на вашем WAN, эту опию следует включить. Опция применяется только к трафику инициируемому на стороне WAN. Из внутренней сети всё ещё возможно получить доступ к узлам частных сетей (смотрите раздел 1.7.1.1 "Частные IP адреса" для получения дополнительной информации о частных IP адресах).

Bogon networks - это сети, которые никогда не должны наблюдаться в Интернет, включая зарезервированное и не распределённое пространство IP адресов. Эти сети никогда не должны присутствовать как источник в Интернет, а их наличие указывает на спуффинг или на "угнаную" сеть используемую в злонамеренных целях. В pfSense реализован список богон-сетей, который обновляется ежемесячно. Если у вас ключена блокировка богон-сетей, ваш брандмауэр будет получать обновления списка богонов с files.pfsense.org в первый день каждого месяца. Следует убедиться, что брандмауэр разрешает DNS имена хостов, иначе обновление не будет работать. Для проверки работы DNS, перейдите на страницу Diagnostics->Ping и запустите ping на files.pfsense.org как показано на рисунке 6.20 "Тестирование разрешение имён для обновления списка богонов".

Рисунок 6.20. Тестирование разрешение имён для обновления списка богонов

Если у Вас все же наблюдаются проблемы с разрешением DNS-имен, можно вручную выполнить обновление через страницу Diagnostics -> Command, выполнив

#/etc/rc.update_bogons.sh now.

Аргумент now следующий за именем скрипта сообщает о необходимости немедленного выполнения скрипта.

Когда вы подключаете IPSec соединение, автоматически добавляется правило позволяющее удалённый тунель доступа IP адреса конечной точки к порту UDP 500 и протокол ESP на WAN IP используемом для соединения. Когда мобильные клиенты IPSec включены, трафик UDP порт 500 и протокол ESP разрешаются с любого источника. Из-за способа работы политики маршрутизации, любой трафик который соответсвует правилу определяющему шлюз будет вытеснен к Интернет и обойдёт обработку IPSec. Когда у вас есть разрешающее правило определяющее шлюз на внутреннем интерфейсе содержащем подсеть используемую IPSec соединением, и место назначения - any (любое), правило добавляется автоматически дабы инвертировать политики маршрутизации для трафика предназначенного удалённой подсети VPN. Автоматически добавляемые правила для IPSec обсуждаются более развернуто в Части 13 данного руководства.

Когда вы подключаете PPTP сервер, автоматически добавляются скрытые правила позволяющие порт 1723 TCP и протокол GRE (Generic Routing Encapsulation) к вашему WAN IP адресу с любого исходного IP. Больше информации об этих правилах можно найти в разделе Части 12, разделе "VPN и правила брандмауэра".

Правила, которые не соответствуют любым правилам определённым пользователем или любым другим автоматически добавленным правилам будут тихо блокироваться правилом запрета по умолчанию.

Если необходимо, повторите процесс пока не получите требуемый результат. Когда все необходимые диапазоны времени будут определены нажмите Save. Вы возвратитесь к списку расписаний и новое расписание будет отображено как показано на рисунке 6.25. "Список расписаний после добавления". Теперь это расписание доступно для использования в правилах брандмауэра.

Рисунок 6.25. "Список расписаний после добавления".

Чтобы создать правило брандмауэра использующее данное расписание следует добавить правило на требуемом интерфейсе. Смотрите раздел 6.2.1. "Добавление правил брандмауэра" и Раздел 6.6. "Конфигурирование правил брандмауэра" для получения более подробной информации о добавлении и редактировании правил. Для нашего примера добавьте правило блокировки трафика TCP для интерфейса LAN из подсети LAN, к любому месту назначения на порту HTTP. Когда дойдёте до установки Schedule, выберите расписание BussinesHours, которое мы только что определили, как показано на рисунке 6.26. "Выбор расписания для правила брандмауэра".

Рисунок 6.26. "Выбор расписания для правила брандмауэра"

После сохрания правила, оно появится в списке правил брандмауэра, так же Вы увидите индикацию о том, что расписание включено. Как видно из рисунка 6.27. "Список правил брандмауэра с расписанием" - это блокирующее правило, но столбец расписания указывает, что в настоящий момент правило находится в неактивном состоянии, поскольку диапазон текущего времени находится за пределами расписания. Если онавести мышь на имя расписания -будет показан диапазон времени определённый для данного расписания.

Рисунок 6.27. "Список правил брандмауэра с расписанием"

Просмотр журналов брандмауэра

Для всех запрещающих правил, а также для тех в настройках которых была установлена отметка о логировании - производится запись в журнал. Есть много способов просмотра этих записей и нельзя однозначно говорить о "лучшем методе" просмотра.? Как и все остальные журналы pfSense, логи брандмауера имеют ограничение по количеству записей. Если Вам необходимо поддерживать постоянное ведение журналов брандмауера в течении длительного промежутка времени, обратитесь к Части 22 "Системные журналы" для получения информации о копировании записей журнала на удаленный syslog сервер.?

Журналы брандмауера можно просмотреть в web-интерфейсе pfSense на странице Status -> System Logs, вкладке Firewall?. Вы можете просматривать уже отфильтрованные логи или работать с "сырыми журналами" включающими более подробную информацию, если понимаете формат журналирования PF.? Парсинг журнала черех web-интерфейс показан на рисунке 6.28. "Пример записей журнала WebGUI"?. Можно видеть шесть столбцов:

Action (Действие), Time (Время), Interface (Интерфейс), Source (Источник), Destinanion (Назначение) и Protocol (Протокол).?