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.

• 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)

• relayd z OpenBSD (i jakiś port dla FreeBSD),
• LVS,
• Heartbeat,
• mod_jk – LB dla Apache Tomcat (vide mój projekt pracowniczy w P. I. Kamsoft AD 2005).

Produkcyjnie wykorzystywałem relayd, LVS i mod_jk. Heartbeat testowałem bardzo krótko.
Konfiguracja w FortiGate jest dość prosta (pomijam politykę zapory):

1. Konfigurujemy Virtual Server
   W CLI konfigurujemy podobnie jak Virtual IP. Jako typ VIP ustawiamy server-load-balance. Rodzaj LB (server-type) możemy ustawić na: HTTP, TCP lub UDP oraz IP. Metod rozkładu obciążenia mamy do wyboru sześć: Static, Round Robin, Weighted, First Alive, Least RTT i Least Session. Do konfiguracji sprawdzania obecności (Health Check) trzeba wrócić później.
2. Definiujemy rzeczywiste serwery
   Oprócz nazwy i adresu IP podajemy port usługi, a także wagę i maksymalną liczbę połączeń. Serwery rzeczywiste przypisujemy serwera wirtualnego.
3. Definiujemy sposób sprawdzania obecności (przypisać go należy do wirtualnego serwera)
   Określamy typ (HTTP, TCP lub PING) i interwał oraz liczbę powtórzeń. W przypadku typu TCP podajemy port usługi, dla HTTP – URL i cią jaki ma być dopasowany do zawartości.
4. …no i możemy cieszyć się gotowym rozwiązaniem.

Przykładowa konfiguracja może wyglądać tak:

config firewall ldb-monitor
edit "DEV-HCH"
set type tcp
set port 80
next
end
config firewall vip
edit "DEV"
set type server-load-balance
set extip 192.168.1.230
set extintf "wan1"
set server-type tcp
set monitor "DEV-HCH"
set ldb-method first-alive
set extport 80
config realservers
edit 1
set ip 10.1.0.1
set port 80
next
edit 2
set ip 10.1.0.2
set port 80
next
edit 3
set ip 10.1.0.3
set port 80
next
end
next
end

Jedyny minus jaki dotychczas dostrzegłem, to brak jakiejkolwiek informacji w logach (pamięć, FortiAnalyzer) o tym, że dany serwer nie działa lub zmienił swój stan.

Poniżej wykres z JMeter – duży skok na początku to wyłączenie pierwszego serwera; metoda rozkładania obciążenia: First Alive i 10 sekund pomiędzy kolejnymi testami.

Innych testów nie chciało mi się robić. Środowisko testowe jeszcze trochę będzie stało (planuję m. in. testy MySQL w klastrze), więc jak ktoś chce wyniki testów LB przy konkretnych ustawieniach, proszę o kontakt.

• router / (S|D)NAT – można zastąpić czymkolwiek,
• filtrowanie stron WWW – kiedyś przyglądałem się SquidGuard, myślę, że można wrócić do tematu i przyjrzeć się temu,
• IDS  – Snort + SnortSam,
• uwierzytelnianie użytkowników w Active Directory – nie znalazłem niczego takiego!

I z racji ostatniego kryterium, postanowiłem zaprojektować sobie coś takiego samemu. Ze względu na uwielbienie pf wybrałem OpenBSD (i żeby noszenie koszulki miało uzasadnienie), który służył mi przed FortiGate. Wzorowałem się trochę na dokumentacji Fortinet (prezentacja MS Power Point), bo model, który oferują nie jest zły. Cały proces składa się z następujących kroków:

1. Użytkownik uruchamia swój komputer i loguje się do domeny.
2. Agent zdobywa informację z serwera o nazwie użytkownika (i przynależności do grup) i nazwie maszyny, z której nastąpiło logowanie (FQDN).
3. Agent sprawdza IP maszyny i odpowiedź klienta (Fortinet proponuje testowanie portu TCP:139 lub TCP:445).
4. Dane o użytkowniku przesyłane są do zapory – FortiGate dostaje nazwę użytkownika i grupy oraz adres IP. Wydaje mi się, że wystarczający jest sam adres sieciowy, natomiast pozostałe dane jedynie do prezentacji.
5. Zapora buduje sobie odpowiednie reguły.
6. Ruch od klienta jest przepuszczany.

Oczywiście świadomie rezygnuję z ‘wyklikanego’ interfejsu, bo z autopsji wiem, że takich reguł nie ma wiele i nie zmienia się ich praktycznie w ogóle. Idea tego rozwiązania od początku polegała na tym, że ktoś robi zaporę raz, a zarządzanie dostępem zrzuca się na osobę administrującą kontrolerem domeny (lub mającą oddelegowane prawa).

Pomocniczy schemat wygląda tak:

Elementami potrzebnymi będą:

• agent wyciągający dane z kontrolera domeny i przesyłający je dalej,
• demon działający na OpenBSD i modyfikujący odpowiednio reguły.

Zabieram się za podsłuchiwanie ruchu pomiędzy FortiGate, a AD, żeby przyjrzeć się jak wygląda komunikacja pomiędzy tymi elementami. Może to pomoże przy własnym rozwiązaniu, ew. uda się skorzystać z FSAE i stworzyć rozwiązanie przejściowe.

Co do programowania, to otwarcie szukam ludzi, którzy mogli by zająć się dowolnym elementem tego rozwiązania. Pomocą przy pisaniu demona pod OpenBSD mogą być źródła np. relayd (komunikacja z pf). Jeśli chodzi o Windows, to szukam sposobu na uzyskiwanie danych z AD.

Każdy palec potrafiący przycisnąć coś na klawiaturze mile widziany!