Журналы PF: Основы

Информация  попадающая  в  журналы  PF  и  уровень  детализации  ведения  журнала определяется  вашим  набором  правил.  Основы  журналирования просты:  для  каждого правила, которое должно добавлять данные в журнал, добавляется ключевое слово log. Когда вы загружаете  набор  правил с добавлением log к одному или более правилам, любые  пакеты  начинающие соединение в соотвествии с правилом (bloked, passed,  или matched)   копируются на устройство pflog. Кроме того, PF  будет  хранить  некоторые дополнительные данные, такие как штамп времени  (временную метку), интерфейс, на котором  пакет  был  пропущен  или   заблокирован,  и  связанный  номер  правила  из

загруженного набора правил.

Данные журнала PF собираются демоном журналирования pflogd, который запускается по умолчанию, при  запуске PF  в  процессе начальной загрузки  системы.  По  умолчанию, данные  журнала  хранятся  в  /var/log/pflog.  Журналы  пишутся  в  бинарном  формате предназначенном для чтения с  использованием tcpdump. Дополнительные инструменты для извлечения и  отображения информации из вашего журнала, мы обсудим несколько позже. Формат файла журнала хорошо документирован и широко поддерживаются.

Для начала приведём простой пример журнала. Начнём с добавления ключевого слова log в необходимые правила:

block log

pass log quick proto { tcp, udp } to port ssh

Перезагрузив  набор  правил,  вы  должны  увидеть  изменение  метки  времени  файла

/var/log/pflog  и  возростание  его  размера.  Чтобы  разобрать,  что  в  данный   момент находится в файле, используйте tcpdump с опцией -r для чтения содержимого файла.

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

$ sudo tcpdump -n -ttt -r /var/log/pflog

Например,  далее  приводятся  только  первые  строки  файла  занимающего  несколько экранов:

$ sudo tcpdump -n -ttt -r /var/log/pflog

tcpdump: WARNING: snaplen raised from 96 to 116

Sep 13 13:00:30.556038 rule 10/(match) pass in on epic0: 194.54.107.19.34834 > 194.54.103.66.113: 3097635127:3097635127(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]> (DF)

Sep 13 13:00:30.556063 rule 10/(match) pass out on fxp0: 194.54.107.19.34834 > 194.54.103.66.113: 3097635127:3097635127(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]> (DF)

Sep 13 13:01:07.796096 rule 10/(match) pass in on epic0: 194.54.107.19.29572 > 194.54.103.66.113: 2345499144:2345499144(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]> (DF)

Sep 13 13:01:07.796120 rule 10/(match) pass out on fxp0: 194.54.107.19.29572 > 194.54.103.66.113: 2345499144:2345499144(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]> (DF)

Sep 13 13:01:15.096643 rule 10/(match) pass in on epic0: 194.54.107.19.29774 > 194.54.103.65.53: 49442 [1au][|domain]

Sep 13 13:01:15.607619 rule 12/(match) pass in on epic0: 194.54.107.19.29774 > 194.54.107.18.53: 34932 [1au][|domain]

Программа tcpdump весьма гибкая, особенно в отношение вывода результата, предлагая несколько вариантов вывода. Формат данного примера следует  опциям указанным для tcpdump. Программа практически всегда отображает  дату и время поступления пакета (длинный формат данных определяется опцией -ttt). Далее, tcpdump перечисляет номер правила в загруженном наборе правил, интерфейс с которого появился пакет, исходный и целевой адрес   и  порт (опция -n сообщает tcpdump отображать IP адреса а не имена хостов), и различные свойства пакетов.

Примечание

Номера правил в файлах журнала относятся к загруженнабору правил. В процессе загрузки, ваш набор правил проходит через некоторые автоматизированные шаги, например расширение макросов и оптимизации, которые  с некоторой вероятностью приведут к тому, что номера правил хранимых в журнале, не всегда соответствуют порядковым номерам правил в самом файле pf.conf. Если возникает неочевидность того какое правило  соответствует, используйте pfctl -vvs rules и изучите полученный вывод.

В нашем примере вывода tcpdump мы видим, что правило 10 (rule 10)  загруженного набора  правил  кажется  всеобъемлющим  и  соответствует   запросам  IDENT  и  обзору доменных имён. Этот тип вывода вы найдёте весьма полезным в процессе отладки и очень важно, чтобы данные такого рода были постоянно доступны, что позволит контролировать вашу  сеть.  Приложив  немного  усилий  и  внимательно  изучив  страницы  руководства tcpdump, вы должны быть в состоянии извлечь полезную информацию из вашего журнала данных.

Для живого отображения движения данных журнала, используйте tcpdump  для  чтения информации журнала непосредственно с устройства журналирования. Чтобы сделать это, используйте опцию -i для указания интерфейса с которого читает tcpdump:

$ sudo tcpdump -nettti pflog0

tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG

Sep 13 15:26:52.122002 rule 17/(match) pass in on epic0: 91.143.126.48.46618 > 194.54.103.65.22: [|tcp] (DF)

Sep 13 15:28:02.771442 rule 12/(match) pass in on epic0: 194.54.107.19.8025 > 194.54.107.18.8025: udp 50

Sep 13 15:28:02.773958 rule 10/(match) pass in on epic0: 194.54.107.19.8025 > 194.54.103.65.8025: udp 50

Sep 13 15:29:27.882888 rule 10/(match) pass in on epic0: 194.54.107.19.29774 > 194.54.103.65.53:[|domain]

Sep 13 15:29:28.394320 rule 12/(match) pass in on epic0: 194.54.107.19.29774 > 194.54.107.18.53:[|domain]

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


Примечание

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

Журналирование всех пакетов: log (all)                                 Для  общей отладки и простоты мониторинга, регистрация первого пакета  соединения предоставит  достаточное  количество  информации.  Однако,  иногда  может  возникнуть потребность в регистрации всех пакетов, соответствующих определённым правилам. Для того, чтобы это сделать,  используйте в правилах которые необходимо контролировать опцию (all).  Сделав это изменение в наших правилах мы должны получить примерно следующее:

block log (all)

pass log (all) quick proto tcp to port ssh keep state

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

udp_services = "{ domain, ntp }"

pass log (all) inet proto udp to port $udp_services

Имея эти правила, мы рассмотрим пример когда русский сервер имён посылает запрос доменного имени на сервер нашей сети:

$ sudo tcpdump -n -ttt -i pflog0 port domain

tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG

Sep 30 14:27:41.260190 212.5.66.14.53 > 194.54.107.19.53:[|domain]

Sep 30 14:27:41.260253 212.5.66.14.53 > 194.54.107.19.53:[|domain]

Sep 30 14:27:41.260267 212.5.66.14.53 > 194.54.107.19.53:[|domain]

Sep 30 14:27:41.260638 194.54.107.19.53 > 212.5.66.14.53:[|domain]

Sep 30 14:27:41.260798 194.54.107.19.53 > 212.5.66.14.53:[|domain]

Sep 30 14:27:41.260923 194.54.107.19.53 > 212.5.66.14.53:[|domain]

Теперь мы имеем в журнале шесть записей вместо одной.

Ответственное журналирование!

Создание журналов любого рода может привести к неожиданным последствиям, в том числе и юридическим. Как только вы начинаете  хранить  данные  журналов  сетевого  трафика,  вы  создаёте  хранилище  информации  о  пользователях.  Могут существовать хорошие причины для длительного хранения журналов технической информации или данных о бизнес-процессах, однако регистрация только данных достаточных для  отображения состояния в течение определённого времени может быть вполне достаточной. Вы должны иметь  некоторое представление о практических вопросах связанных с генерацией данных журналов,  например  таких  как  организация  достаточного  места  для  хранения  журнала  в  периоде  его  актуальности. Юридические аспекты могут изменяться в зависимости от ваше местоположения. В некоторых странах и  регионах имеются особые требования к обработке данных журналов, наряду с ограничениями того, как эти данные должны сохраняться. Иногда от ISP требуется сохранять журналы трафика за определённый период  времени, и при необходимости предоставлять эти данные по запросу правоохранительных органов. Убедитесь, что вы разобрались с правовыми вопросами, прежде чем строить инфраструктуру системы журналирования.

Даже при использовании фильтрации port domain в tcpdump, добавление log(all) к одному или нескольким правилам значительно увеличивает объём данных в  ваших журналах. Если  вам  необходимо  журналировать  весь  трафик,  но   ёмкость  хранилища  шлюза ограничена, может потребоваться добавление  дисковой памяти. Кроме того, запись и хранение журналов трафика с таким уровнем детализации, с большой вероятностью будет иметь юридические последствия.

Журналирование нескольких интерфейсов pflog                 

PF в версиях OpenBSD старее 4.1 позволял только один интерфейс pflog. Это изменилось с   OpenBSD   4.1,   когда   интерфейс   pflog   стал   клонируемым   устройством,   а   это,

соответственно, означает, что вы можете использовать команды ifconfig для  создания

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

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

$ sudo ifconfig create pflog1

Для создания постоянной конфигурации в OpenBSD, создайте файл  hostname.pflog1, содержащий только up и аналогичные файлы hostname.pflogN для любых дополнительных интерфейсов журналирования.

На FreeBSD, конфигурирование клонированых интерфейсов pflog производится в файле rc.conf, в следующем виде:

ifconfig_pflog1="up"

На NetBSD, клонирование pflog не поддерживалось на момент написания главы.

Как вы видели в Главе 6, направление информации журнала для  различных  частей набора правил на  отдельные интерфейсы, позволяет  передавать данные журнала PF различным приложениям. Это облегчает  передачу требуемой информации специальным программам,  таким  как  spamlogd,  в  то  время,  как  другие  части  журнала  PF  будут передаваться другим программам обработки.

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

Длительное   использование   BSD   подскажет   вам,   что   традиционная    система журналирования syslog – основана на несколько наивном  управлении  данными, через передачу UDP с других хостов, и частым  упоминанием о возможности DoS атак. Кроме того,  существует  риск  того,  что  информация  журналов  будет  потеряна  при  высокой нагрузке на любой из отдельных систем или сетей. Таким образом, следует рассматривать вопрос  о  создании  удалённого  журналирования только  если  все  участвующие хосты находятся  в  хорошо  защищённой  сети.  На  большинстве  BSD  систем,   syslogd  не настраивается  по  умолчанию  для  приёма  данных  с  других  хостов.  (Смотрите  man- страницу   syslogd   для   получения   информации   о   подключении   демона   к   приёму информации   с    других   хостов,   если    вы    планируете   использовать   удалённое журналирование).

Если вы всё таки планируете проводить журналирование PF посредством  syslog, далее следует короткий рецепт того, как это сделать. В стандартных  установках PF, pflogd копирует  журналируемые  данные  в  файл  журнала.   Если  вам  необходимо  сначала сохранять данные журнала на удалённой  системе, необходимо отключить накопление данных pflog изменив его файл журнала на /dev/null, через параметры запуска демона в rc.conf.local (для OpenBSD), следующим образом:

pflogd_flags="-f /dev/null"

На FreeBSD и NetBSD измените строку pflog_logfile= в файле rc.conf, затем  убейте и перезапустите процесс pflogd с новыми параметрами:

pflog_logfile="/dev/null"

Далее,  убедитесь,  что  данные  журнала,  более  не  собираемые  pflogd,  передаются требуемым образом для вашей системы обработки журналов. Этот  шаг состоит из двух частей:  первое  –  настройте  ваш  системный  журнал  для  передачи  данных  в  журнал системы  обработки,  а  затем  используйте   tcpdump  для  преобразования  данных  и внедрения их в системный журнал системы.

Чтобы настроить syslogd для обработки данных, выберите объект журнала (log facility), уровень журналирования (log level) и действие (action) и введите результирующую строку в /etc/syslog.conf. Этот пункт хорошо объясняется в  man-странице syslog.conf, которую обязательно следует изучить, если вы хотитет понять системные журналы. Часть action – это обычно файл в  локальной файловой системе. Для примера, если вы уже создали системный журнал на loghost.example.com для получения ваших данных, выберите объект журнала local2 с уровнем журналирования info введя следующую строку:

local2.info    @loghost.example.com

После  внесения  этих  изменений,  перезагрузите  syslogd  чтобы  он  прочитал  новые настройки.

Далее, установите tcpdump для преобразования данных журнала с  устройства  pflog и передаче их логгеру, который будет отправлять данные в  системный журнал. Здесь мы повторим команду tcpdump из основных примеров использованных ранее в этой главе, с рядом полезных дополнений:

$ sudo nohup tcpdump -lnettti pflog0 | logger -t pf -p local2.info &

Команда  nohup  гарантирует,  что  процесс  продолжит  работать  даже  если  не  имеет управляющего терминала или помещается в фоновый режим (как мы делаем добавляя &). Опция -l с командой tcpdump указывает буферизацию  строк вывода, что полезно при перенаправлении   на   другие   программы.    Опция   logger   добавляет   теги   pf   для идентификации данных PF в потоке  и указывает приоритет журнала с опцией -p как local2.info. Результат  записывается в файл указанный вами на хосте журналирования, с записями выглядящими следующим образом:

pf: Sep 21 14:05:11.492590 rule 93/(match) pass in on ath0: 10.168.103.11.15842 > 82.117.50.17.80: [|tcp] (DF)

pf: Sep 21 14:05:11.492648 rule 93/(match) pass out on xl0: 194.54.107.19.15842 > 82.117.50.17.80: [|tcp] (DF)

pf: Sep 21 14:05:11.506289 rule 93/(match) pass in on ath0: 10.168.103.11.27984 > 82.117.50.17.80: [|tcp] (DF)

pf: Sep 21 14:05:11.506330 rule 93/(match) pass out on xl0: 194.54.107.19.27984 > 82.117.50.17.80: [|tcp] (DF)

pf: Sep 21 14:05:11.573561 rule 136/(match) pass in on ath0: 10.168.103.11.6430 > 10.168.103.1.53:[|domain]

pf: Sep 21 14:05:11.574276 rule 136/(match) pass out on xl0: 194.54.107.19.26281

> 209.62.178.21.53:[|domain]

Этот фрагмент журнала показывает в основном активность web-обозревателя с клиента в локальной сети за NAT, с точки зрения шлюза, с сопутствующим поиском доменных имён.

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

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

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

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