Checkpoint IPS – protect internal hosts only – jak to działa?

Ostatnio otrzymałem takie oto pytanie:

Jak działa Checkpoint IPS, jeżeli w konfiguracji modułu,  w sekcji “Protection scope”  wybraje jest ustawienie “Protect internal hosts only”.

Checkpoint-protect-internal-hosts-only

Precyzyjniej rzecz ujmując, pytający chciał wiedzieć, czy w takiej konfiguracji moduł IPS będzie analizował tylko ruch przepływający pomiędzy interfejsem o topologii “External” a interfejsami o topologii “Internal”, czy też może analizie będzie również poddany ruch “Internal” do “Internal”.

Odpowiedź wcale nie jest oczywista, co można zaobserwować m.in. w dyskusji na cpug.org. Również logika modułu firewall, który decyzje podejmuje zazwyczaj przed trasowaniem pakietu, tj. w sytuacji, kiedy tylko interfejs źródłowy jest znany, sugeruje że omawiane ustawienie wymusza analizę ruchu, którego źródło to interfejs o topologii “External”

Checkpoint-topology

Stan faktyczny jest taki, że analizie poddawany jest każdy ruch kierowany do interfesju “Internal” – bez względu na jego interfejs źrodłowy – zarówno “External” jak i “Internal”. Dodatkowo, w przypadku kiedy sygnatura ma typ “Server/Client”, analizie poddany będzie ruch “Internal” do “External”.

Źródło: Checkpoint sk94072

Jakie jest znaczenie praktyczne tego ustawienia? Pokażę to na przykładzie.

Firewall brzegowy z uruchomionym modułem IPS. W profilu IPS aktywna sygnatura typu “Server protection”, chroniąca serwer www Apache przed atakami na pewną podatność. Profil ruchu: 1 000 000 nowych połączeń na godzinę, z tego 100 000 w kierunku “External”->”Internal”, 200 000 “Internal”->”Internal” i 700 000 “Internal”->”External”.  Dla uproszczenia zakładam, że 50% ruchu we wszystkich kierunkach to ruch HTTP.

Wersja 1 – aktywne jest ustawienie “Protect internal hosts only”
Ruch HTTP kierowany do interfejsów “Internal” to 50%x(100 000+200 000)=150 000 połączeń na godzinę. Tyle połączeń zostanie poddanych analizie przez aktywną sygnaturę, w celu ochrony chronionych serwerów www znajdujących się za interfejsami “Internal”. Jest to analogiczne do stosowanej w Snorcie konstrukcji any -> $HOME_NET.

Wersja 2 – aktywne jest ustawienie “Perform IPS inspection on all traffic”. Ruch HTTP kierowany do wszystkich interfejsów to 50%x1 000 000=500 000 połączeń na godzinę – i wszystkie one zostaną poddane analizie. De facto sensor w tej konfiguracji chroni “cały  Internet” przed atakami – analogiczne do Snortowego any -> any

Można przywołać wiele argumentów na obronę tezy, że inspekcji powininen być poddawany cały ruch – wykrywanie hostów z sieci wewnętrznej dokonujących ataków na obce systemy, wykorzystując zasoby organizacji, że sensor powinien być odpowiednio zlokalizowany itd. W praktyce jest tak, że klienci kupując urządzenia wymiarują je do celu ochrony własnej sieci,a uruchomienie trybu ochrony “wszystkiego” może powodować problemy z wydajnością, stabilnością, aż do odmowy wykonania usługi włącznie.

Producent zaleca, w zbiorze najlepszych praktyk dotyczących wydajności, aby używać ustawienia “Protect internal hosts only”. Odmienna konfiguracja – jeżeli jest pożądana – powinna być poprzedzona testowaniem i optymalizacją profilu IPS, a jeszcze lepszym rozwiązaniem wydaje się być przerzucenie ciężaru analizy ruchu wychodzącego na zewnątrz bliżej źródła – np. na serwer proxy albo oprogramowanie uruchomione na urządzeniu klienckim.

Leave a Reply

Your email address will not be published. Required fields are marked *