Dziś przywróciłem dostęp przez przeglądarkę i oto mam FortiOS v4.0,build0441,110318 (MR3). Samo przywrócenie dostępu nie było łatwe – NAT + przekierowanie portów + NAT + RDP. Jakiś kosmiczny backdoor. Ale zadziałało i już klikam ;-)

FortiToken

Z ciekawych tematów (bez rozwijania; pewnie i tak nie skorzystam) – FortiToken.

A z mniej ważnych – zmiana FSAE na FSSO (Fortinet Single Sign On), WLAN to teraz WiFi, a firmware można pobierać bezpośrednio z WebUI.

Mimo, że nie jest to zalecane, zrobiłem zdalny upgrade bezpośrednio z wczesnej wersji 4.0 MR2 i działa (Fortinet mówi o Patch Release 4 B0313 i późniejszych). Tak naprawdę zacząłem aktualizację zanim ściągnął się PDF, więc nie widziałem ;-) Teraz zabieram się za lekturę wszystkich pominiętych Release Notes‘ów.

Wszystko było w porządku gdy były dwie grupy – ‘góra’ i ‘plebs’. Rozróżniani byli kategoriami stron, do których mieli dostęp i zakresem portów (drudzy mieli w zasadzie tylko HTTP i HTTPS). Problem zaczął się w momencie rozdrobnienia ‘plebsu’ – w końcu to ludzie, którzy zajmują się księgowością, zakupami czy nieruchomościami więc przy jednoczesnym ogólnym ograniczeniu dostępu do informacji trzeba konkretnym grupom ograniczyć możliwe kategorie.

Każdej grupie stworzyłem osobny profil filtrowania (web filter profile) i przyporządkowałem w odpowiedniej podregule.

Z jakiegoś powodu zmieniłem kolejność tych reguł i nagle użytkownicy zaczęli mieć pretensje, że nie pozwalam im pracować. W sumie to tylko jedna z grup milczała i nie byłą to ‘góra’. Po kilku godzinach analiz znalazłem źródło problemu. Otóż przy zmianie kolejności podreguł, grupa dostaje profil filtrowania taki, na jakiej był początkowo pozycji. Czyli układ taki:
1 internet_P
4 internet_I
2 internet_Z
3 internet_K
spowoduje, że internet_I będzie miał profil grupy internet_Z, internet_Z – ten od internet_K, a internet_K – internet_I.
Mieszałem na różne sposoby kolejnością i jestem pewien, że profil filtrowania jest na sztywno powiązany z pozycją reguły, dla której był pierwotnie przypisany. Dziwne, prawda?
Nie chciało mi się już szukać czemu dokładnie tak się dzieje, bo może to błąd silnika, a nie sposobu zaczytywania konfiguracji.
Problem zgłosiłem i niniejszym publicznie ogłosiłem, gdyby ktoś też z tym walczył.

Warto przypomnieć publicznie również o tym, że pakiet podlega pod regułę, jeśli pasuje adres IP źródłowy i docelowy. W takim przypadku reguły bazowane na uwierzytelnianiu (ładne spolszczenie?) mające ten sam cel i źródło nie mogą współistnieć, ponieważ pakiet, którego ‘właścicielem’ jest użytkownik nie występujący w pierwszej regule, zostanie odrzucony. Trzeba to oczywiście rozwiązywać ‘podregułami’, pamiętając o ich poprawnej kolejności.
Notkę producenta można przeczytać w bazie wiedzy:

• Only the first authenticated group is allowed through a FortiGate firewall policy

Swoją drogą ciekawe co się stanie, jeśli wyrzucimy pierwszą podregułę i usuniemy całkowicie profile filtrowania. Ktoś chętny do testów czy czekamy na kolejną łatę?

Jeszcze nie miałem okazji sprawdzić tego w działaniu, ale na pierwszy rzut oka wygląda ładnie, a tego zazwyczaj się obawiam.

Zobacz także:

• Firewall Guru: Software Update – 4.0 MR2
• Firewall Guru: FortiOS 4.0 MR2 – Initial Impressions

Oprócz tego, że zarządzam produkcyjnym serwerem, zrobiłem sobie poligon, gdzie testuję różne rzeczy. Poniżej schemat dla mojego przyszłego pracodawcy ;-)

Dla sportu AS65001 to OpenBSD z OpenBGPD, AS65002 to FortiGate, a AS65003 – Linux + quagga.

• pf changes,

a także w dokumencie Following -current, gdzie znajduje się również informacja z następnego dnia o zmianie składni reguł z opcjami route-to, reply-to, dup-to and fastroute.

Osobiście uważam, że obie zmiany sprawią, że plik konfiguracyjny będzie bardziej czytelny. Zaczynam testowanie!

• FortiOS-v4.0-MR1-Release-Notes.pdf
• FGT_100A-v400-build0178-FORTINET.out
• FSAE_Setup_3.5.047.exe

Wszystko działa (nie ma problemu ze zdalną aktualizacją z 4.0).

PS C:\> Get-WmiObject -Class Win32_Product -computername DC | Where-Object { $_.name -like “Forti*” }
IdentifyingNumber : {8BB826C4-4CB5-42B0-A124-AA9B69F8CB41}
Name : Fortinet Server Authentication Extension (FSAE)
Vendor : Fortinet Inc.
Version : 3.5.047
Caption : Fortinet Server Authentication Extension (FSAE)

Fakty, które znamy (-release):

• reguły przetwarzane są z góry do dołu (a w każdej linii od lewej do prawej),
• ostatnia pasująca reguła wygrywa,
• wyjątkiem jest słowo kluczowe quick.

Powyższe oznacza, że każdy pakiet przejdzie po kolei pełny zestaw reguł. Co w przypadku, gdy logujemy (log)? Niejako jest to powiązane z akcją, więc pakiet zalogowany będzie tylko raz. Poniżej przykład:

block log all
pass in log on $int_if inet proto tcp from any to ($int_if) port ssh flags S/SA modulate state

tcpdump pokaże nam:

07:30:44.227293 rule 3/(match) pass in on xl0: 192.168.1.131.61392 > 192.168.1.64.22: S 738501558:738501558(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF)

Nowa akcja match (-current) po prostu dopasowuje pakiet i może go zalogować lub oznakować (tag), ale nie zrobi z nim nic więcej (nie zaakceptuje i nie odrzuci). Zmieniony zestaw reguł:

block log all
match in log on $int_if inet proto tcp from any to ($int_if) port ssh
pass in log on $int_if inet proto tcp from any to ($int_if) port ssh flags S/SA modulate state

da następujące wyniki:

07:36:55.505154 rule 4/(match) pass in on xl0: 192.168.1.131.61403 > 192.168.1.64.22: S 3714164883:3714164883(0) win 8192 (DF)
07:36:55.505168 rule 3/(match) match in on xl0: 192.168.1.131.61403 > 192.168.1.64.22: S 3714164883:3714164883(0) win 8192 (DF)

Czyli jeden pakiet (patrz numer sekwencyjny) dwukrotnie zalogowany. Co ważne – w logach pierw mamy pass, a potem match (niezależnie jak reguły ułożymy).

Przydatne? Myślę, że tak. Wracamy do NetFlow (oczywiście z najeżkowatą w tle – pamiętać należy, że w Polsce nie wolno wprowadzać ich do obrotu).

peeper ~ # pfctl -nf /etc/pf.conf
/etc/pf.conf:7: syntax error
peeper ~ # head -n 7 /etc/pf.conf |tail -n 1
scrub in all
peeper ~ # uname -a
OpenBSD peeper.mbs.dmz 4.6 GENERIC#0 i386

Kto podąża za -current, powinien czytać też o zmianach. Czyli:

• używamy scrub w konkretnych regułach,
• mamy nową akcję match, która dopasowuje każdy pakiet nie reagując na niego (ani pass ani block; przydatne przy logowaniu, normalizowaniu, znakowaniu i co kto jeszcze sobie wymyśli),
• fragment reassembly domyślnie włączone (próba ustawienia wyrzuci nam błędy),
• no i najważniejsze – pf jest domyślnie włączony.