Журнали 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:30556038 rule 10/(match) pass in on epic0: 194541071934834 &gt 1945410366113: 3097635127:3097635127(0) win 16384 &ltmss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]&gt (DF)

Sep 13 13:00:30556063 rule 10/(match) pass out on fxp0: 194541071934834 &gt 1945410366113: 3097635127:3097635127(0) win 16384 &ltmss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]&gt (DF)

Sep 13 13:01:07796096 rule 10/(match) pass in on epic0: 194541071929572 &gt 1945410366113: 2345499144:2345499144(0) win 16384 &ltmss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]&gt (DF)

Sep 13 13:01:07796120 rule 10/(match) pass out on fxp0: 194541071929572 &gt 1945410366113: 2345499144:2345499144(0) win 16384 &ltmss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]&gt (DF)

Sep 13 13:01:15096643 rule 10/(match) pass in on epic0: 194541071929774 &gt 194541036553: 49442 [1au][|domain]

Sep 13 13:01:15607619 rule 12/(match) pass in on epic0: 194541071929774 &gt 194541071853: 34932 [1au][|domain]

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

Номери правил у файлах журналу відносяться до загруженнабору правил У процесі завантаження, ваш набір правил проходить через деякі автоматизовані кроки, наприклад розширення макросів та оптимізації, які з деякою вірогідністю приведуть до того, що номери правил збережених в журналі, не завжди відповідають порядковим номерам правил в самому файлі pfconf Якщо виникає неочевидність того яке правило відповідає, використовуйте 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:52122002 rule 17/(match) pass in on epic0: 911431264846618 &gt 194541036522: [|tcp] (DF)

Sep 13 15:28:02771442 rule 12/(match) pass in on epic0: 19454107198025 &gt 19454107188025: udp 50

Sep 13 15:28:02773958 rule 10/(match) pass in on epic0: 19454107198025 &gt 19454103658025: udp 50

Sep 13 15:29:27882888 rule 10/(match) pass in on epic0: 194541071929774 &gt 194541036553:[|domain]

Sep 13 15:29:28394320 rule 12/(match) pass in on epic0: 194541071929774 &gt 194541071853:[|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 = &quot{ domain, ntp }&quot

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:41260190 2125661453 &gt 194541071953:[|domain]

Sep 30 14:27:41260253 2125661453 &gt 194541071953:[|domain]

Sep 30 14:27:41260267 2125661453 &gt 194541071953:[|domain]

Sep 30 14:27:41260638 194541071953 &gt 2125661453:[|domain]

Sep 30 14:27:41260798 194541071953 &gt 2125661453:[|domain]

Sep 30 14:27:41260923 194541071953 &gt 2125661453:[|domain]

Тепер ми маємо в журналі шість записів замість однієї

Створення журналів будь-якого роду може призвести до несподіваних наслідків, у тому числі і юридичним Як тільки ви починаєте зберігати дані журналів мережевого трафіку, ви створюєте сховище інформації про користувачів Можуть існувати хороші причини для тривалого зберігання журналів технічної інформації або даних про бізнес-процеси, проте реєстрація тільки даних достатніх для відображення стану протягом певного часу може бути цілком достатньою Ви повинні мати певне уявлення про практичні питання повязаних з генерацією даних журналів, наприклад таких як організація достатнього місця для зберігання журналу у періоді його актуальності Юридичні аспекти можуть змінюватися залежно від ваше розташування У деяких країнах і регіонах є особливі вимоги до обробки даних журналів, поряд з обмеженнями того, як ці дані повинні зберігатися Іноді від ISP потрібно зберігати журнали трафіку за певний період часу, і при необхідності надавати ці дані на запит правоохоронних органів Переконайтеся, що ви розібралися з правовими питаннями, перш ніж будувати інфраструктуру системи журналювання

Навіть при використанні фільтрації port domain в tcpdump, додавання log (all) до одного або декількох правил значно збільшує обсяг даних у ваших журналах Якщо вам необхідно журналіровать весь трафік, але ємність сховища шлюзу обмежена, може знадобитися додавання дискової памяті Крім того, запис і зберігання журналів трафіку з таким рівнем деталізації, з великою ймовірністю матиме юридичні наслідки

PF у версіях OpenBSD старіше 41 дозволяв тільки один інтерфейс pflog Це змінилося з OpenBSD 41, коли інтерфейс pflog став клонують пристроєм, а це,

відповідно, означає, що ви можете використовувати команди ifconfig для створення

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

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

$ sudo ifconfig create pflog1

Для створення постійної конфігурації в OpenBSD, створіть файл hostnamepflog1, який містить лише up та аналогічні файли hostnamepflogN для будь-яких додаткових інтерфейсів журналирования

На FreeBSD, конфігурування клонування інтерфейсів pflog проводиться у файлі rcconf, в наступному вигляді:

ifconfig_pflog1=&quotup&quot

На 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, через параметри запуску демона в rcconflocal (для OpenBSD), наступним чином:

pflogd_flags=&quot-f /dev/null&quot

На FreeBSD і NetBSD змініть рядок pflog_logfile = у файлі rcconf, потім убийте і перезапустіть процес pflogd з новими параметрами:

pflog_logfile=&quot/dev/null&quot

Далі, переконайтеся, що дані журналу, більш не збираються pflogd, передаються потрібним чином для вашої системи обробки журналів Цей крок складається з двох частин: перша – налаштуйте ваш системний журнал для передачі даних в журнал системи обробки, а потім використовуйте tcpdump для перетворення даних і впровадження їх в системний журнал системи

Щоб налаштувати syslogd для обробки даних, виберіть обєкт журналу (log facility), рівень журналювання (log level) і дію (action) і введіть результуючу рядок в / etc / syslogconf Цей пункт добре пояснюється в man-сторінці syslogconf, яку обовязково слід вивчити, якщо ви хотітет зрозуміти системні журнали Частина action – це зазвичай файл у локальній файловій системі Для прикладу, якщо ви вже створили системний журнал на loghostexamplecom для отримання ваших даних, виберіть обєкт журналу local2 з рівнем журналирования info ввівши наступний рядок:

local2info    @loghostexamplecom

Після внесення цих змін, перезавантажте syslogd щоб він прочитав нові налаштування

Далі, встановіть tcpdump для перетворення даних журналу з пристрою pflog і передачі їх Логгер, який буде відправляти дані в системний журнал Тут ми повторимо команду tcpdump з основних прикладів використаних раніше в цьому розділі, з рядом корисних доповнень:

$ sudo nohup tcpdump -lnettti pflog0 | logger -t pf -p local2info &amp

Команда nohup гарантує, що процес продовжить працювати навіть якщо не має керуючого терміналу або поміщається у фоновий режим (як ми робимо додаючи &) Опція-l з командою tcpdump вказує буферизацию рядків виводу, що корисно при перенаправлення на інші програми Опція logger додає теги pf ​​для ідентифікації даних PF в потоці і вказує пріоритет журналу з опцією -P як local2info Результат записується у файл вказаний вами на хості журналирования, із записами виглядаючими наступним чином:

pf: Sep 21 14:05:11492590 rule 93/(match) pass in on ath0: 101681031115842 &gt 82117501780: [|tcp] (DF)

pf: Sep 21 14:05:11492648 rule 93/(match) pass out on xl0: 194541071915842 &gt 82117501780: [|tcp] (DF)

pf: Sep 21 14:05:11506289 rule 93/(match) pass in on ath0: 101681031127984 &gt 82117501780: [|tcp] (DF)

pf: Sep 21 14:05:11506330 rule 93/(match) pass out on xl0: 194541071927984 &gt 82117501780: [|tcp] (DF)

pf: Sep 21 14:05:11573561 rule 136/(match) pass in on ath0: 10168103116430 &gt 10168103153:[|domain]

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

&gt 209621782153:[|domain]

Цей фрагмент журналу показує в основному активність web-оглядача з клієнта в локальній мережі за NAT, з точки зору шлюзу, із супутнім пошуком доменних імен

Джерело: Книга про PF, by Peter NM Hansteen, Переклад виконав Михайлов Олексій aka iboxjo

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*