Базовый запрещающий набор правил PF

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

4.  Зачем писать набора запрещающих правил по умолчанию? Самый короткий ответ это дает вам лучший  контроль. Задача пакетного фильтра держать под контролем, не дать попасться, что плохие парни могут сделать. Маркус Ранум написал очень увлекательную  и  информативную  статью,  которая  называется  “Шесть  самых  тупых  идей  в  компьютерной  безопасности” (http://www.ranum.com/security/computer_security/editorials/dumb/index.html)

Начнем, с добавления следующего правила в /etc/pf.conf:

block all

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

Теперь, мы определим несколько макросов в наборе правил, которые используем позже:

tcp_services = "{ ssh, smtp, domain, www, pop3, auth, https, pop3s }" udp_services = "{ domain }"

Здесь вы можете видеть как комбинация списков и макросов может использоваться для получения   некоторого   преимущества.   Макросы   могут    быть    списками,   и    как демонстрировалось в примере, PF понимает  правила  которые используют имена служб также хорошо, как и номера  портов, перечисленных в вашем файле /etc/services. Мы позаботимся об  использовании всех  этих  элементов и  некоторых других трюках для большей  читабельности в решении сложных ситуаций, которые требуют более  сложных наборов  правил.  Имея  эти  макросы,  мы  можем  использовать  их  в  наших  правилах, которые мы будем сейчас редактировать:

block all

pass out proto tcp to port $tcp_services pass proto udp to port $udp_services

Замечание

Не забудьте добавить сохранение состояния для этих правил, если ваша система имеет версию PF старше чем OpenBSD 4.1

Строки $tcp_services и $udp_services являются ссылками на макрос. Макросы,  которые появляются в наборе правил в этом месте расширяются, когда набор правил загружается и работающий набор правил будет иметь полные списки, которые вставляются в макросы на которые ссылаются. В зависимости от точной природы макросов, они могут вызываться одним правилом с ссылкой на макрос, расширяющуюся на несколько правил.

Даже в маленьких наборах правил, таких как этот, использование  макросов  делает правила легче для понимания и поддержки. Количество информации, которая необходима

для появления сжатого набора правил, а  также с  осмысленными именами  макросов,

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

TCP ПРОТИВ UDP

Мы позаботились, чтобы отделить TCP службы от UDP служб. Некоторые службы работают в основном на хорошо известных номерах портов и на TCP или UDP, а также несколько альтернативных между использованием TCP и UDP в соответствии с конкретными условиями.

Два протокола совершенно различных в некоторых отношениях. TCP является ориентированным на соединение и надежным, идеальный кандидат для динамической фильтрации. В отличие от  UDP,  который является не без основания не ориентированным на соединение, но PF создает и поддерживает данные эквивалентно о состоянии

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

Один общий пример где состояние информации для UDP полезно для обработки разрешения  имен. Когда вы запрашиваете имя сервера разрешить доменное имя по IP адресу или разрешить  IP адрес по имени хоста, то разумно предположить, что вы хотите получить в ответ. Сохранение информации или функциональный эквивалент о вашем UDP трафике сделает это возможным.


Перезагрузка набора правил и  просмотр ошибок                

После изменений в файле pf.conf, нам нужно загрузить новые правила как  показано далее:

$ sudo pfctl -f /etc/pf.conf

Если нет синтаксических ошибок, pfctl не должен отобразить никаких сообщение в ходе загрузки правил.

Если вы предпочитаете подробный вывод, используйте –v флаг:

$ sudo pfctl -vf /etc/pf.conf

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

$ sudo pfctl -vf /etc/pf.conf

tcp_services = "{ ssh, smtp, domain, www, pop3, auth, https, pop3s }" udp_services = "{ domain }"

block drop all

pass out proto tcp from any to any port = ssh flags S/SA keep state pass out proto tcp from any to any port = smtp flags S/SA keep state pass out proto tcp from any to any port = domain flags S/SA keep state pass out proto tcp from any to any port = www flags S/SA keep state pass out proto tcp from any to any port = pop3 flags S/SA keep state pass out proto tcp from any to any port = auth flags S/SA keep state pass out proto tcp from any to any port = https flags S/SA keep state pass out proto tcp from any to any port = pop3s flags S/SA keep state pass proto udp from any to any port = domain keep state

$ _

Сравните этот вывод с содержанием файла /etc/pf.conf, который вы на  самом деле написали.  Для  нашей  единственной  TCP  службы  правило  разворачивается  в  восьми различных  контекстах: по  одному  для  каждой  службы  в  списке.  Одно  правило  UDP заботиться только об одной службе, и оно расширяется от того, что мы включили опцию по  умолчанию.  Обратите  внимание,  что  правила  отображаются  в  полном  объеме,  с значениями по умолчанию, такие как флаги S/SA хранящие состояние применяемое в этом месте  для  любой  опции  не  указаной  в  явном  виде.  Эта  конфигурация  та,  которая загружается на самом деле.

Проверка ваших правил                                                           Если вы сделали внешние изменения в вашем наборе правил, проверьте их перед тем, как попытаетесь загрузить набор правил :

$ pfctl -nf /etc/pf.conf

Опция –n говорит PF о том, что нужно только проверить правила, без их  загрузки – покажет вам что вы имеете в сухом остатке и позволит вам  просмотреть и исправить возможные ошибки. Если pfctl найдет какие-либо синтаксические ошибки в вашем наборе правил, он выйдет с сообщением об  ошибке, которая указывает на номер строки, где произошла ошибка.

Некоторые руководства по брандмауэрам посоветуют вам убедиться что  ваша  старая конфигурация  действительно  работает,  или,  если  вы   столкнулись  с  проблемами, брандмауэр может быть в каком-то промежуточном состоянии, которое не соответствует состоянию ни до, ни  после.  Это просто не верно, когда вы используете PF. Последний допустимый загруженный набор правил будет активным до тех пор пока вы не отключите PF или пока не загрузите новый набор правил. pfctl проверяет синтакс, а затем загружает новый набор правил полностью перед переходом на новые. Как только допустимый набор правил был загружен, нет промежуточного состояния с  частичным набором правил или вообще с незагруженными правилами. Одним из следствий этого является то, что трафик, который соответсвует состоянию которые действительны в обоих, старого и нового набора правил не будет нарушена. Если вы на самом деле следовали советам из некоторых этих старых руководств и покраснели за существующие правила (это возможно, используя pfctl

–F   all   или   аналогичного)   прежде   чем   пытаться   загрузить   новые   из    вашего конфигурационного  файла,  последняя  допустимая  конфигурация   будет   оставаться

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

Тестирование измененного набора правил                            Если  у вас есть набор правил, которые pfctl загрузил без каких-либо  ошибок,  пришло время посмотреть работают ли ваши правила так, как ожидалось. Проверка разрешения имен с командой такой как $ host nostarch.com (как мы делали ранее) должно все еще работать, но выберите домен, который недоступен в последнее время (например, одной из политических  партий,  которая не  прошла голосование), чтобы  убедиться, что  вы  не тянете DNS-информацию из кеша. Вы должны способны серфить Web и  использовать несколько  связанных  с  почтой  служб,  но  из-за  природы  этого  обновленного  набора правил, пытается получить доступ к TCP службам  другие,  чем те, которые определены (SSH, SMTP и т.д.) на любой удаленной системе не сможет. И как и наш простой набор правил, ваша система должна отказаться от всех соединений, которые не соответствуют существующим  записям в таблице состояний; только обратный входящий трафик будет разрешено инициировать на этой машине.

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий