W związku z moimi problemami z FortiGate zacząłem się zastanawiać po co go w ogóle używam i czy na pewno nie da się go zastąpić innym urządzeniem. I tak:
- 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:
- Użytkownik uruchamia swój komputer i loguje się do domeny.
- 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).
- Agent sprawdza IP maszyny i odpowiedź klienta (Fortinet proponuje testowanie portu TCP:139 lub TCP:445).
- 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.
- Zapora buduje sobie odpowiednie reguły.
- 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!
1 września część społeczeństwa cofała się 70 lat w czasie, część paliła w toalecie z dawno nie widzianymi znajomymi, a Henning Brauer na grupie openbsd-misc opublikował informację na temat sporej zmiany w kodzie pf (3’000 linii różnic odchudza kod o 800 linii). Zmiana dotyczy składni translacji i przekierowania adresów – nie będę one osobnymi regułami, a akcjami na regułach 
