Palo Alto - log forwarding
29.08.2021 | Tag Palo Alto
Log forwarding umožňuje logy generované určitou politikou dále přeposílat ke zpracování. Článek by měl ukázat základní práci s log forwardingem.
Jak bylo v dřívějším článku psáno, log forwarding umožňuje logy generované určitou politikou dále přeposílat ke zpracování a také přiřazovat tagy k adresám z těchto logů. Po sepsání toho článku mě napadlo, že by nemuselo být špatné napsat i nějaké základní seznámení s log forwardingem. Log forwarding dovede být nápomocný, pokud máme nějakou další destinaci pro ukládání logů (ať už syslog, nebo Panoramu), ale také pokud chceme o nějakém typu logů vědět přednostně třeba přes mail.
Je to dost možná jasné, ale log forwarding není pro Palo povinný. Jen pokud k firewallu existuje Panorama v roli log collectoru, pouze pomocí log forwardingu se do ní logy z politik na firewallu dostanou. Dále v případě existence nějakého centrálního SIEMu, nebo čistě syslog serveru se může log forwarding využít, aby se logy dostaly k nějaké další zpracovávací entitě. Také je možné jej použít pro přeposlání logu na email, pokud by třeba šlo o nějaké kritické pravidlo (třeba že se někdo ze standardního PC segmentu pokouší dostat přes RDP na řadiče). Těch use cases je opravdu nespočet, včetně již zmiňovaného tagování. Tak k základům.
Log forwarding se vytváří pod Objects – Log Forwarding přidáváním jednotlivých profilů. Každé pravidlo (případně další objekty, které log forwarding podporují) snese aplikovat jen jeden profil. Match listy v profilech se však dají opravdu různě kombinovat, takže klidně může být jeden základní forward profil a od něj štěpit další, specifičtější profily. Tip – pokud se vytvoří forwarding profil s názvem default, každá nově vytvořená politika si ho bude automaticky vybírat.
Kategorie logů v match listech odpovídají kategoriím logů, které jsou vidět v monitoru (traffic, threat, decryption atd.). Filtr v match listu pak přesně odpovídá syntaxi hledání v logách. Není špatné si zamýšlený filtr pro match list v log forwarding profilu napřed vyzkoušet v monitoru nad reálnými logy, případně si ho tam rovnou sestavit a pak vykopírovat.
Nahoře byl vidět default forwarding profil, který všechny typy logů bez nějakých filtrů přeposílá do Panoramy. Níže do tohoto profilu přidám další match list, který říká, aby všechny threat logy se severitou critical byly přeposílány mailem. Dále ve výpisu jsou pak vidět nově vytvořený default profil a guest profil, který odpovídá dřívějšímu článku. Default profil se může aplikovat jako standard na běžná pravidla a guest profil na pravidla řídící komunikaci z guest wifi.
V politikách se pak aplikování profilu řídí v kartě Actions. Z obrázku to asi nebude poznat, ale nově vytvořená politika si automaticky vzala profil default.
Trochu odbočka – v politikách se vždy nachází dvě výchozí pravidla, intrazone a interzone default. Definují chování boxu ke komunikaci v rámci zóny a mezi zónami, pokud provoz nepadl do specifičtějšího pravidla. S boxem přichází z výroby a nedají se smazat. Dají se ale omezeně řídit, včetně přiřazení log forwarding profilu. Před prováděním změn se musí nad pravidlem dát Override, což je k dispozici v akcích pod výpisem pravidel. Podle ozubených koleček u těchto dvou pravidel se dá poznat, jestli jsou ve svém výchozím stavu, nebo po override.
Poslední screen už ukazuje obě pravidla po override a s aplikovaným log forward profilem nad intrazone default pravidlem. Značí to ikonka listu se šipkou.
A nakonec, log forwarding profil se dá aplikovat také na security zóny pro přeposílání logů z aplikovaného zone protection profilu. Tyto logy by, tuším, měly padat do threat kategorie. A dále na globalprotect portál i gateway pro přeposílání SSL handshake logů. Ty by měly spadat do decryption kategorie.
