Тестирование вашей настройки PF

Теперь  пришло время сдуть пыль с  точной спецификации,  описывающей,  как ваши настройки   должны   работать.   Физическое    расположение   нашего   примера   сети сосредоточена вокруг шлюза подключенного к Интернету через $ext_if. В приложении к шлюзу через $int_if имеется локальная сеть с рабочими станциями и, возможно, один или несколько серевров для местного применения. И наконец, мы имеем DMZ подключенный через $dmz_if, населенный серверами, предлагающих услуги локальной сети и Интернета.

Рисунок 9-2 показывает логическую схему сети.

Соответствующие спецификации набора правил выглядят следующим образом:

·                  Машины вне нашей сети, должны иметь доступ к сервисам наших серверов в DMZ, и не иметь доступа к локальной сети.

·                  Машины в нашей локальной сети, прикрепленные через $int_if, должны  иметь

доступ   к   нашим   сервисам,   предлагаемых   сереврами   в   DMZ   и   доступ   к определенному перечню сервисов за пределами нашей сети

·                  Машины в DMZ должны иметь доступ к некоторым сетевым сервисам во внешнем мире.

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

Рисунок 9-2. сеть с серверами в DMZ

Задача  состоит  в  том,  чтобы  убедиться  что  набор  правил,  фактически  реализует спецификацию.  Мы  должны  проверить  настройки.  Полезный   тест   можно  было  бы попробовать изображенный в таблице 9-1. Вашей  конфигурации может потребоваться другие тесты или могут отличаться в  некоторых частностях. Ваш реальный тестовый сценарий должен указать,  как  пакеты и соединения должны быть зарегистрированы. Главное, что вы должны решить, это ожидаемый и желаемый результат для каждого из ваших тестов должно быть определен перед началом тестирования. В общем, вы должны проверить   использование   приложений,   которые   как   вы   ожидаете   должен   иметь пользователь. Такие как веб браузер или почтовый клиент в различных ОС. Соединения должны просто быть приняты или отброшены, в  соответствии со спецификацией. Если один или более из ваших основных  тестов дает неожиданные результат, переходите к отладке набора правил.

Таблица 9-1. простой набор правил, в случае проверяющей последовательности

Тестируемое действие                                                         Ожидаемый результат

Попробовать соединиться из локальной сети на каждый разрешенный порт на серверы в DMZ

Попробовать соединиться из локальной сети на каждый разрешенный порт на серверы вне нашей сети Попробовать соединиться на любой порт из DMZ в локальную сеть

Попробовать из DMZ на каждый разрешенный порт на серверы вне нашей сети

Попробовать соединиться извне нашей сети на $webserver в DMZ на каждый порт на $webports

Попробовать соединиться извне нашей сети на $webserver в DMZ на порт 25 (SMTP)

Попробовать соединиться из вне нашей сети на

$emailserver в DMZ на 80 порт (HTTP) Попробовать соединиться извне нашей сети на

$emailserver в DMZ на 25 порт (SMTP)

Попробовать соединиться извне нашей сети на один или более машин в локальной сети

Соединение должно пройти Соединение должно пройти

Соединение должно быть заблокировано Соединение должно пройти

Соединение должно пройти

Соединение должно быть заблокировано Соединение должно быть заблокировано Соединение должно пройти

Соединение должно быть заблокировано

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

Прежде чем погрузиться в набора правил, вы можете легко определить является ли PF конфигурация причиной проблемы. Сделайте так, отключите PF используя pfctl –d, чтобы посмотреть исчезла ли проблема. Если проблема не  устраняется когда PF отключен, вы должны  обратиться  к  отладке  других  частей  конфигурации. С  другой  стороны,  если проблема   исчезла   после   отключения   PF,   и   вы   собираетесь   начать   исправлять конфигурацию PF,  убедитесь, что PF включен и, что ваш набор правил загружен, этой командой:

$ sudo pfctl -si | grep Status

Status: Enabled for 20 days 06:28:24            Debug: err

Status: Enabled говорит нам, что PF включен, нужно попытаться посмотреть загрузились правила используя различные команды:

$ sudo pfctl -sr

match in all scrub (no-df max-mss 1440) block return log all

block return log quick from <bruteforce> to any anchor "ftp-proxy/*" all

Здесь, pfctl –sr эквивалентно pfctl –s правилам. Фактический вывод  вероятно, будет немного  больше, чем  показано здесь,  но  это  хороший  пример  того,  что  вы  должны

ожидать, чтобы увидеть, когда набор правил загружен. Для отладки, попробуйте добавить

–vv  флаг  в  командную  строку  pfctl,  вы  увидите  количество  правил  и   некоторую дополнительную отладочную информацию примерно как эту:

$ sudo pfctl -vvsr

@0 match in all scrub (no-df max-mss 1440)

[ Evaluations: 341770   Packets: 3417668  Bytes: 2112276585  States: 125  ] [ Inserted: uid 0 pid 14717 State Creations: 92254 ]

@1 match out on nfe0 inet from 10.0.0.0/8 to any queue(q_def, q_pri) nat-to (nfe0:1) round-robin static-port

[ Evaluations: 341770   Packets: 0        Bytes: 0           States: 0    ] [ Inserted: uid 0 pid 14717 State Creations: 0    ]

@2 match out on nfe0 inet from 192.168.103.0/24 to any queue(q_def, q_pri) nat-to (nfe0:1) round-robin static-port

[ Evaluations: 68623    Packets: 2138128  Bytes: 1431276138  States: 103  ] [ Inserted: uid 0 pid 14717 State Creations: 39109 ]

@3 block return log all

[ Evaluations: 341770   Packets: 114929   Bytes: 62705138    States: 0    ] [ Inserted: uid 0 pid 14717 State Creations: 0    ]

@4 block return log (all) quick from <bruteforce:0> to any

[ Evaluations: 341770   Packets: 2        Bytes: 104         States: 0    ] [ Inserted: uid 0 pid 14717 State Creations: 0     ]

@5 anchor "ftp-proxy/*" all

[ Evaluations: 341768   Packets: 319954   Bytes: 263432399   States: 0    ] [ Inserted: uid 0 pid 14717 State Creations: 70   ]

Теперь вы должны выполнять структурированную пошаговую загрузку набора  правил. Найти  правила,  которые  соответствуют  расследованию  пакетов.   Какое  последнее соответствующее правило? Если больше чем одно  соответствующее правило? (как вы, наверное, помните из предыдущих глав, когда пакет соответствует правилу quick оценка останавливается, и все, что  quick правило определяет происходит с пакетом). Если так, вам нужно проследить за оценкой правил до тех пор, пока вы не дойдете до конца набора правил или пока пакет не будет соответствовать правилу quick, которое затем завершает процесс. Если ваш набор правил проходит в конце где-то в другом, чем в ожидаемом вами

соответствующем правиле месте, вы нашли свою логическую ошибку.

Логические ошибки в наборе правил как правило, делятся на три типа:

·                  Ваше правило, не соответствует, потому что оно никогда не оценивается. Имеется quick правило ранее, и поэтому все оценки правил на этом останавливаются.

·                  Ваше  правило  оценивается, но  пакет  не  соответствует  в  конце  концов,  из-за

критериев правила.

·                  Ваше правило оценивается, правило соответствует, но пакет также  соответсвует другом правилу позже в наборе правил. Последнее соответствие правило является тем, которое определяет что происходит с вашим соединением.

В главе 8 введен tcpdump как ценный инструмент для чтения и интерпретации логов PF. Программа также очень хорошо подоходит для просмотра трафика,  который проходит через определенный интерфейс. То, что вы узнали о логах PF и как использовать tcpdump в фильтрации пригодится, когда вы хотите  разыскать какие именно пакеты достигают какого интерфейса. Вот пример использования tcpdump для просмотра TCP трафика на xl0 интерфейсе (но не показано SSH или SMTP трафик) и распечатывает результат в очень подробном режиме (vvv):

$ sudo tcpdump -nvvvpi xl0 tcp and not port ssh and not port smtp tcpdump: listening on xl0, link-type EN10MB

21:41:42.395178 194.54.107.19.22418 > 137.217.190.41.80: S [tcp sum ok] 3304153886:3304153886(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale

0,nop,nop,timestamp 1308370594 0> (DF) (ttl 63, id 30934, len 64)

21:41:42.424368 137.217.190.41.80 > 194.54.107.19.22418: S [tcp sum ok] 1753576798:1753576798(0) ack 3304153887 win 5792 <mss 1460,sackOK,timestamp 168899231 1308370594,nop,wscale 9> (DF) (ttl 53, id 0, len 60)

Соединения показанные здесь успешно соединяются с вебсайтом. Есть более интересные

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

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

·                  Использование tcpdump в фильтрации, чтобы извлечь только нужную информацию,

чтобы  увидеть  только  те  пакеты,  которые  должны  соответствовать   вашему конкретному случаю, таких как порт SMTP и назначение 192.0.2.19.

·                  Найти  место,  где  ваши  предположения  не  соответствуют  реальности   вашего

сетевого трафика.

·                  Включите  ведение  журнала  для  правил,  которые  могут  быть   вовлечены,  и посмотрите через tcpdump на соответствующий в pflog интерфейс, чтобы увидеть действительно соответствующие правилам пакеты.

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

Знайте вашу сеть и сохраняйте контроль                               Повторяющаяся  тема  в  этой  книге  в  том,  что  PF  и  связанные  с  ним  инструменты позволяют относительно легко для вас, как сетевого администратора, брать под контроль сети и заставить вести ее так как вы хотите, чтобы она себя вела. Иными словами, строить

сеть вам нужно.

Запуск сети может быть веселым, и я надеюсь, вам понравился этот тур, я считаю это

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

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

вам нужно. Это когда самое интересное начинается!

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

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

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

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