packet filtered что значит
Настройка Packet Filter (PF) в FreeBSD 12.1
Published on April 29, 2020
Автор выбрал COVID-19 Relief Fund для получения пожертвования в рамках программы Write for DOnations.
Введение
Брандмауэр, вероятно, является одной из наиболее важных линий защиты от кибератак. Способность настроить брандмауэр с нуля — это очень важный навык, который позволяет администратору получить контроль над своими сетями.
Packet Filter (PF) — это известный брандмауэр, поддерживаемый в рамках проекта OpenBSD для обеспечения безопасности. Если быть более точным, это инструмент фильтрации пакетов, как видно из названия, который известен простым синтаксисом, удобством для пользователей и обширным функционалом. PF — это по умолчанию хранящий состояние брандмауэр, помещающий информацию о подключениях в таблице состояния, которую можно использовать в аналитических целях. PF — это часть базовой системы FreeBSD, которая поддерживается активным сообществом разработчиков. Хотя между версиями PF во FreeBSD и OpenBSD существуют различия, связанные с разной архитектурой ядра, в целом они используют один синтаксис. В зависимости от сложности общий набор правил можно изменить, чтобы работать с любым дистрибутивом с минимальными усилиями.
В этом обучающем руководстве мы выполним сборку брандмауэра с нуля на сервере FreeBSD 12.1 с помощью PF. Вы создадите базовый набор правил, который можно использовать в качестве шаблона для будущих проектов. Также вы познакомитесь с рядом продвинутых функций PF, таких как гигиена пакетов, предотвращение атак brute force, мониторинг и логирование, а также рядом сторонних инструментов.
Предварительные требования
Перед началом выполнения этого обучающего руководства вам потребуется следующее:
Шаг 1 — Создание предварительного набора правил
Начните выполнение данного руководства, создав черновик предварительного набора правил, который обеспечивает базовую защиту и доступ к важнейшим услугам через Интернет. В настоящий момент у вас есть работающий сервер FreeBSD 12.1 с активным облачным брандмауэром.
Существует два подхода к созданию брандмауэра: отказ по умолчанию и разрешение по умолчанию. При использовании отказа по умолчанию блокируется весь трафик, а пропускается только трафик, указанный в правиле. Подход с разрешением по умолчанию делает противоположное: он пропускает весь трафик, блокируя только то, что указано в правиле. Вы будете использовать подход с отказом по умолчанию.
Войдите на сервер с пользователем non-root user:
Далее создайте ваш файл /etc/pf.conf :
Примечание. Если вы захотите посмотреть полный базовый набор правил в любой момент при выполнении руководства, см. примеры в шаге 4 и шаге 8.
Далее добавьте первое правило в ваш файл /etc/pf.conf :
Это правило блокирует все формы трафика в каждом направлении. Поскольку направление на указано, по умолчанию блокируется входящий и исходящий трафик. Данное правило является законным для локальных рабочих станций, которые необходимо изолировать от мира, однако оно во многом не пригодно к использованию на практике и не будет работать на удаленном сервере, поскольку оно запрещает трафик SSH. На деле, если бы вы активировали PF, то могли бы заблокировать для себя доступ к серверу.
Примечание. В качестве альтернативы вы можете использовать имя протокола:
PF выполняет правила последовательно сверху вниз, поэтому ваш текущий набор правил на начальном этапе блокирует весь трафик, но затем пропускает его, если он отвечает критериям на следующей линии, что в данном случае соответствует трафику SSH.
Теперь вы можете подключиться к серверу через SSH, но вы все равно можете блокировать все формы исходящего трафика. Это проблема, поскольку вы не можете получить доступ к критическим сервисам из Интернета для установки пакетов, обновления настроек времени и т. д.
Для устранения этой проблемы добавьте следующее выделенное правило в конце файла /etc/pf.conf :
Добавьте в предварительный набор правил следующие выделенные правила:
Сохраните и закройте файл.
Вы создали правило set skip для устройства закольцовывания, поскольку ему не требуется фильтр трафика, а такая фильтрация может вызывать заметное замедление работы сервера. Вы добавили правило pass out inet для протокола ICMP, которое позволяет использовать утилиту ping(8) для поиска и устранения проблем. Опция inet представляет семейство адресов IPv4.
Теперь у вас есть рабочий набор правил, который обеспечивает базовый функционал для большинства серверов. В следующем разделе мы убедимся, что все работает корректно, активировав PF и протестировав ваш предварительный набор правил.
Шаг 2 — Тестирование вашего предварительного набора правил
Наборы правил PF являются простым текстовым файлом, что означает, что при загрузке новых наборов правил не потребуются сложные процедуры. После загрузки нового набора правил старый исчезает. Очень редко, если это вообще возможно, требуется удалить существующий набор правил.
Давайте активируем PF, используя утилиту командной строки sysrc :
Проверьте внесение изменений, отобразив содержимое вашего файла /etc/rc.conf :
Результат будет выглядеть следующим образом:
Запустите PF, перезапустив сервер:
Подключение будет сброшено. Подождите несколько минут, пока не закончится процесс обновления.
Теперь снова подключитесь по SSH к серверу:
Загрузите набор правил с помощью pfctl :
Если ошибки или сообщения отсутствуют, это означает, что ваш набор правил не имеет ошибок, а брандмауэр активен.
Теперь, когда PF запущен, вы можете отключить ваш сервер от облачного брандмауэра. Это можно сделать в панели управления вашей учетной записи DigitalOcean, удалив дроплет из портала облачного брандмауэра. Если вы используете другого поставщика облачных услуг, убедитесь, что все, что вы использовали для временной защиты, отключено. Запуск двух разных брандмауэров на сервере практически точно вызовет проблемы.
В дополнение к этому перезагрузите ваш сервер еще раз:
Через несколько минут подключитесь через SSH к вашему серверу:
Теперь PF — ваш действующий брандмауэр. Чтобы проверить, что он запущен, вы можете попробовать получить доступ к данным с помощью утилиты pfctl.
Вы увидите следующие данные в таблице (значения будут варьироваться в зависимости от сервера):
Поскольку вы только что активировали набор правил, вы не увидите большое количество информации. Однако этот вывод показывает, что PF уже записал 23 совпавших правила. Это означает, что критерии набора правил были использованы 23 раза. Вывод также подтверждает, что ваш брандмауэр работает.
Ваш набор правил также разрешает исходящий трафик для доступа к ряду критически важных сервисов в Интернете, включая утилиту ping.
Давайте проверим подключение через Интернет и службу DNS с помощью ping для google.com :
Убедитесь, что у вас есть доступ к репозиторию pkgs с помощью следующей команды:
Если имеются какие-либо обновления для пакетов, выполните обновление.
Если обе службы работают, это означает, что ваш брандмауэр работает, и вы можете двигаться дальше. Хотя ваш предварительный набор правил обеспечивает защиту и необходимый функционал, это по-прежнему очень простой набор, который может быть улучшен. В остальных разделах мы будем дополнять базовый набор правил и используем некоторые продвинутые функции PF.
Шаг 3 — Дополнение базового набора правил
На этом шаге мы разберем наш предварительный набор правил, чтобы дополнить базовый набор правил. Вы измените некоторые правила и поработаете с более продвинутыми понятиями.
Включение макросов и таблиц
В предварительном наборе правил вы жестко задали все параметры для каждого правила, в нашем случае это номера портов, которые составляют список. В будущем такая конфигурация может стать неуправляемой, в зависимости от природы ваших сетей. Для большей организованности PF включает макросы, списки и таблицы. Вы уже включили списки прямо в ваши правила, но вы также можете отделить их от правил и назначить переменную с помощью макросов.
Откройте ваш файл, чтобы передать некоторые параметры в макрос:
Теперь добавьте в самый верх набора правил следующее содержание:
Измените ваши предыдущие правила SSH и ICMP, указав новые переменные:
Далее вы должны имплементировать таблицу, которая похожа на макрос, но предназначена для хранения групп IP-адресов. Давайте создадим таблицу для немаршрутизуемых IP-адресов, которые часто используются в DoS-атаках. Вы можете использовать IP-адреса, указанные в RFC6890, где определяются реестры IP-адресов особенного назначения. Ваш сервер не должен посылать пакеты на эти адреса или получать пакеты от этих адресов через общедоступные интерфейсы.
Создайте эту таблицу, добавив следующее содержание сразу после макроса icmp_types :
Теперь добавьте ваши правила для таблицы под правилом set skip on lo0 :
Защита портов SSH
Поскольку ваш порт SSH общедоступен, он может стать объектом атаки. Один из самых очевидных признаков нападения — это массовые попытки входа в систему. Например, если один IP-адрес пытается выполнить вход на ваш сервер 10 раз за секунду, вы можете предположить, что это дело рук не человека, а компьютерного программного обеспечения, которое пытается взломать ваш пароль входа в систему. Такие виды систематических эксплойтов часто называют атаками brute force, и обычно они являются успешными, если у сервера слабый пароль.
Предупреждение. Мы настоятельно рекомендуем использовать аутентификацию по открытому ключу на всех ваших серверах. Ознакомьтесь с руководством DigitalOcean по аутентификации на базе ключей.
PF имеет встроенные функции для противодействия атакам brute force и другим похожим атакам. С помощью PF вы можете ограничить количество попыток одновременного подключения с одного хоста. Если хост превышает эти ограничения, соединение будет сброшено, а сам хост будет запрещен на сервере. Для этого вы можете использовать механизм устранения перегрузки PF, который поддерживает таблицу запрещенных IP-адресов.
Измените предыдущее правило SSH, чтобы ограничить количество одновременных подключений с одного хоста, следующим образом:
Вы определили таблицу устранения перегрузки в вашем правиле SSH, но не объявили саму таблицу в вашем наборе правил.
Добавьте таблицу
под макросом icmp_types :
Ключевое слово persist позволяет создавать пустую таблицу в наборе правил. Без него PF будет жаловаться, что в таблице нет IP-адресов.
Эти меры гарантируют защиту вашего порта SSH с помощью мощного механизма безопасности. PF позволяет настраивать быстрые решения для защиты от катастрофических форм атак. В следующих разделах мы выполним действия для очистки пакетов, которые поступают на сервер.
Очистка вашего трафика
Примечание. В следующих разделах описываются базовые принципы работы протокола TCP/IP. Если вы планируете создавать веб-приложения или работать с сетью, вам будет полезно знать эти вещи. Ознакомьтесь с руководством DigitalOcean Знакомство с сетевой терминологией, интерфейсами и протоколами.
Из-за сложности протокола TCP/IP, а также действий злоумышленников пакеты часто поступают с отклонениями и неопределенностями, например с наложением фрагментов IP-адресов, поддельными IP-адресами и многим другим. Поэтому необходимо очищать трафик, прежде чем он поступит в систему. Технический термин, используемый для обозначения этого процесса, — нормализация.
Добавьте ключевое слово scrub непосредственно перед правилом block all :
Вы будете использовать стандартное значение MTU в 1500 байт, которое можно определить с помощью команды ifconfig :
Вы увидите следующий вывод, который включает ваше текущее значение MTU:
Теперь, когда у вас есть политики для обработки фрагментации, пакеты, которые попадают в вашу систему, будут единообразными и согласованными. Это желательно, поскольку огромное количество устройств обмениваются данными через Интернет.
Добавьте следующее выделенное содержание, чтобы применить antispoofing для интерфейса vtnet0 :
Сохраните и закройте файл.
Для демонстрации вашего правила для борьбы с подменой IP-адресов вы можете вывести ваш набор правил на экран в подробном виде. Правила в PF обычно написаны в сокращенной форме, но также они могут быть написаны в подробной форме. Как правило, не очень удобно писать правила таким образом, но для целей тестирования это может быть полезно.
Вы увидите примерно следующий вывод внутри части для борьбы с подменой IP-адресов:
Ваше правило для борьбы с подменой IP-адреса является последним добавлением в базовый набор правил. На следующем шаге вы примените эти изменения и выполните ряд тестов.
Шаг 4 — Тестирование базового набора правил
На этом шаге вы просмотрите и протестируете базовый набор правил, чтобы убедиться, что все работает корректно. Рекомендуется избегать применения слишком большого количества правил одновременно без тестирования. Рекомендуется начать с основ, постепенно расширяя функционал и выполнять резервное копирование при внесении изменений в конфигурацию.
Вот как выглядит ваш полный базовый набор правил:
Убедитесь, что ваш файл /etc/pf.conf идентичен полному базовому набор правил, прежде чем продолжить. Сохраните и закройте файл.
Ваш полный базовый набор правил предоставляет вам следующее:
Запустите следующую команду pfctl для выполнения пробного прогона:
Теперь, если ошибки отсутствуют, загрузите набор правил:
Если ошибок нет, это означает, что ваш базовый набор правил активен и работает корректно. Как и ранее в этом руководстве, вы выполните несколько тестов для вашего набора правил.
Первый тест — подключение к Интернету и службе DNS:
Результат будет выглядеть следующим образом:
Затем проверьте, что вы можете получить доступ к репозиторию pkgs :
Еще раз обновите пакеты, если это необходимо.
В заключение перезапустите ваш сервер:
Подождите несколько минут, пока сервер не перезагрузится. Вы выполнили и имплементировали базовый набор правил, что является важным шагом с точки зрения вашего прогресса. Теперь вы готовы к изучению некоторых продвинутых функций PF. На следующем шаге вы сможете продолжить работу по предотвращению атак brute force.
Шаг 5 — Управление таблицей устранения перегрузки
Со временем таблица устранения перегрузки
будет заполнена IP-адресами злоумышленников, и вам придется выполнять ее периодическую очистку. Маловероятно, что злоумышленник будет использовать один и тот же IP-адрес, поэтому нет необходимости хранить эти адреса в таблице в течение длительного времени.
Вы можете использовать pfctl для ручной очистки IP-адресов, которые хранятся в таблице устранения перегрузки в течение 48 часов и более с помощью следующей команды:
Вы увидите примерно следующий результат:
Это правило работает для быстрого исправления ситуации, но более надежным решением будет автоматизация процесса с помощью cron, планировщика заданий FreeBSD. Давайте создадим скрипт оболочки, который запускает эту последовательность выполнения команды.
Создайте файл скрипта оболочки в директории /usr/local/bin :
Добавьте в скрипт оболочки следующие строки:
Сделайте файл исполняемым с помощью следующей команды:
Далее вам необходимо создать задание cron. Это задания, которые будут запускаться периодически в соответствии с указанным вами временем. Часто они используются для резервного копирования или любого процесса, который необходимо запускать в одно и то же время каждый день. Создавать задания cron можно с помощью файлов crontab. Дополнительную информацию о cron(8) и crontab(5) см. в Man Pages.
Создайте файл crontab пользователя root с помощью следующей команды:
Теперь добавьте в файл crontab следующее содержимое:
Сохраните и закройте файл.
Примечание. Пожалуйста, сопоставьте каждое значение с соответствующим элементом в таблице для удобства чтения, если содержимое размещается некорректно при добавлении контента.
Это задание cron запускает скрипт clear_overload.sh каждый день в полночь, удаляя IP-адреса, которые находятся в таблице перегрузки
более 48 часов. Далее вам необходимо добавить якоря в ваш набор правил.
Шаг 6 — Добавление якорей в ваши наборы правил
На этом шаге вы должны ввести якоря, которые используются для поиска правил в основном наборе правил, либо вручную, либо из внешнего текстового файла. Якоря могут содержать элементы правил, таблицы и даже другие якоря, которые называются вложенными якорями. Давайте продемонстрируем, как работают якоря, добавив таблицу во внешний файл, а затем выполним ее извлечение в ваш базовый набор правил. Ваша таблица будет включать группу внутренних хостов, для которой вы хотите ограничить подключение к внешнему миру.
Создайте файл под именем /etc/blocked-hosts-anchor :
Добавьте в файл следующие строчки:
Сохраните и закройте файл.
Эти правила объявляются и определяются в таблице и запрещают доступ с любого IP-адреса в таблице к любым сервисам внешнего мира. Вы используете ключевое слово egress в качестве предпочитаемого метода поиска маршрута по умолчанию или выхода наружу, в Интернет.
Вам все еще необходимо объявить якорь в вашем файле /etc/pf.conf :
Теперь добавьте следующие правила якоря после правила block all :
Сохраните и закройте файл.
Теперь примените эти изменения, перезагрузив ваш набор правил с помощью pfctl :
Если ошибок нет, это означает, что в вашем наборе правил нет ошибок, а изменения активны.
Используйте pfctl для проверки запуска якоря:
Результат будет выглядеть следующим образом:
Еще одна функция якорей состоит в том, что они позволяют вам добавить правила по запросу без необходимости перезагрузки набора правил. Это может быть полезно при тестировании, быстрых исправлениях, авариях и т. д. Например, если внутренний хост действует странно, и вы хотите заблокировать для него исходящие подключения, вы можете использовать якорь, который позволяет вам быстро исправить ситуацию из командной строки.
Давайте откроем /etc/pf.conf и добавим еще один якорь:
Вы можете назвать якорь rogue_hosts и поместить его в правило block all :
Сохраните и закройте файл.
Чтобы применить изменения, перезагрузите набор правил с помощью pfctl :
Еще раз используйте pfctl для подтверждения запуска якоря:
Результат будет выглядеть следующим образом:
Теперь, когда якорь запущен, вы можете добавить к нему правила в любое время. Проверьте это, добавив следующее правило:
Теперь воспользуйтесь pfctl еще раз, чтобы убедиться, что правила активны:
Результат будет выглядеть следующим образом:
Использование якорей является ситуационным и субъективным решением. Как и для любых других функций, существуют плюсы и минусы использования якорей. Некоторые приложения, такие как интерфейс blacklistd, изначально имеют якоря. Далее мы рассмотрим подробнее процесс записи журналов в PF, что является критически важным аспектом сетевой безопасности. Ваш брандмауэр будет бесполезен, если вы не можете посмотреть, что он делает.
Шаг 7 — Запись журнала активности вашего брандмауэра
Вначале получите доступ к журналам из файла /var/log/pflog :
Результат будет выглядеть следующим образом:
На этих ранних этапах в файле /var/log/pflog может не быть данных. В очень короткий срок файл журнала начнет расти в размере.
Результат будет выглядеть следующим образом:
Теперь вы увидите подключения в реальном времени. Если это возможно, проверьте пинг сервера с удаленного компьютера, в результате чего вы увидите подключения. Сервер будет находиться в этом состоянии, пока вы не выйдете.
В Интернете есть огромное количество информации о tcpdump(8), включая официальный сайт.
Доступ к файлам журнала с помощью pftop
Для ее использования вам необходимо установить пакет pftop :
Теперь запустите бинарный файл pftop :
В результате будет получен следующий вывод (ваши IP-адреса будут отличаться):
Создание дополнительных интерфейсов журнала
Создайте дополнительный интерфейс журнала с именем pflog1 :
Добавьте в файл /etc/hostname.pflog1 следующие строки:
Теперь активируйте устройство при загрузке в вашем файле /etc/rc.conf :
Теперь вы можете контролировать и регистрировать активность брандмауэра. Это позволяет посматривать данные о том, кто подключается к серверу и какие типы подключений используются.
В этом обучающем руководстве вы включили несколько продвинутых понятий в ваш набор правил PF. Это необходимо для включения продвинутых функций, если они вам потребуются. На следующем шаге вы вернетесь к базовому набору правил.
Шаг 8 — Возврат к вашему базовому набору правил
В этом последнем разделе вы вернетесь к базовому набору правил. Это быстрый шаг, который позволит вернуться к минимальному набору функций.
Откройте базовый набор правил с помощью следующей команды:
Удалите текущий набор правил в вашем файле и замените его на следующий базовый набор правил:
Сохраните и закройте файл.
Перезагрузите набор правил:
Если ошибки при выполнении команды отсутствуют, это значит, что в вашем наборе правил нет ошибок, а ваш брандмауэр работает корректно.
Теперь удалите файл /etc/hostname.pflog1 из директории /etc :
Прежде чем выходить, перезагрузите сервер еще раз, чтобы гарантировать, что все изменения активны и сохраняются:
Подождите несколько минут, прежде чем выполнять вход на сервер.
В качестве опции, если вы хотите использовать PF с веб-сервером, ниже представлен следующий набор правил для этого сценария. Этот набор правил является достаточной отправной точкой для большинства веб-приложений.
Заключение
В этом обучающем руководстве вы настроили PF в FreeBSD 12.1. Теперь у вас есть базовый набор правил, который может служить в качестве отправной точки для всех ваших проектов FreeBSD. Дополнительную информацию о PF можно найти на странице pf.conf(5) в Man Pages.
Посетите нашу страницу FreeBSD, чтобы найти дополнительные обучающие руководства и ответы на частые вопросы.
Freebsd. Фильтрация трафика PF
Введение
Сама таблица будет иметь следующий вид:
Можно указать знак отрицания для исключения из таблицы. В данном случае будет соответствие IP 1.1.1.1, и сети 111.12.46.0/24, кроме IP 111.12.46.17. Наполнением этого файла можно заниматься вручную. Затем загрузить таблицу из файла снова:
В таблицу можно добавлять как IP адреса, так и доменные имена. Доменные имена разрешатся при загрузке. Для обновления адресов можно поставить загрузку таблицы в cron каждый час, к примеру. Однако, если хотя бы один адрес разрешить не удастся, обновление таблицы не удастся:
После загрузки можно посмотреть, что содержится в таблице:
Можно удобным образом добавить/удалить записи:
Конечно, эти записи не попадут магически в файл, и после перезагрузки таблицы их не будет.
Важно помнить о возможности проверки соответствия IP таблице. Можно проверить и доменное имя.
Задания в cron для обновления:
Теперь добавим возможность ходить на корпоративные ресурсы по портам http(s) и обратно по портам 8080 и 8443. Создаём макросы со списком портов, можно использовать названия протоколов:
Таблицу, загружаемую из файла, со списком хостов:
Для примера, в таблице будет один хост:
И собственно правила:
Дополнительные параметры фильтрации
Теперь задача интереснее. Необходимо защитить наш сервер от перебора паролей ssh. Еще одна возможность PF — лимитировать количество соединений, соответствующих правилу, по различным параметрам.
persist — держать в памяти, даже если пустая. Если не указать такое поведение, PF удалит пустую таблицу.
В данном случае max-src-conn 10 — только 10 одновременных соединений с одного адреса, max-src-conn-rate 3/10 — только 3 новых соединения за 10 секунд, overload — добавлять в таблицу адреса источника нарушителей, flush — сбрасывать все соединения от нарушителя, созданные этим правилом.
По образу и подобию — разрешение пользователю ходить на веб-сервер.
Параметры этого правила надо очень аккуратно подбирать под ваш сервис. Synproxy — включает проксирование syn запросов, защиту от synflood атак. А flush global означает сброс всех соединений с источника-нарушителя, даже если они не относятся к этому правилу.
Устаревание записей в таблицах заблокированных обеспечиваются командами такого вида:
Эта команда удалит все записи, старше часа из соответствующей таблицы. Команды поставим в крон:
Таким образом каждый час таблицы будут вычищаться.
Итоговая конфигурация
Не забывайте комментировать ваш конфигурационный файл, и он всегда будет радовать взгляд.
Заключение
Мы рассмотрели возможности PF в части фильтрации входящего и исходящего трафика. Познакомились с макросами и таблицами. И создали неплохой конфигурационный файл для файрвола, который способен отразить большинство типовых атак на сервер. Описанные технологии наша команда использует для создания шлюза Интернет Контроль Сервер. Протестировать ИКС можно в течение 35 дней или бесплатно использовать версию до 9 пользователей.
Ну а в следующей статье познакомимся с якорями, метками и трансляцией адресов (NAT). Как и прежде, будем рады вашим комментариям и пожеланиям!