Tag Archives: firewall

Security through obscurity wiecznie żywe

CC BY-NC 2.0 Glen Darrud
CC BY-NC 2.0 Glen Darrud

P.T. Pan Klient zażądał dzisiaj, żeby zablokować skanowanie jego systemów (udostępnionych publicznie usług) przez Shodan. Jako że Shodan nawiązując połączenie niczym szczególnym się nie wyróżnia, to technicznie należaloby to zrealizować blokując ruch z określonej grupy adresów źródłowych (z których Shodan dokonuje skanowania). Podejście to ma masę słabości, poczynając od tego, że Shodan takiej listy nie publikuje, a to co można znaleźć w sieci to zapis pewnego wycinka rzeczywistości w określonej chwili, bez gwarancji, że zebrane adresy będą niezmienne w przyszłości.

Inżynier, który pracował nad tym zgłoszeniem, zrobił dobrą robotę, i zasugerował uszczelnienie polityki firewalla tak, aby tylko rzeczywiście niezbędne zasoby były dostępne publicznie, a także regularne testy bezpieczeństwa, aplikowanie poprawek i innych rozwiązań usuwających ewentualne podatności – zamiast blokowania skanera. Pan Klient jednak wie lepiej, płaci i wymaga, tak więc koniec końców zaimplementowana została reguła blokująca kilkadziesiąt adresów mniej lub bardziej powiązanych z Shodanem. Inne niż Shodan skanery, w tym potencjalni atakujący, mogą dalej prowadzić rekonesans ze swoich (lub cudzych) adresów. Ponieważ rezultatu tych działań nie będzie widać na shodan.io to Pan Klient będzie spał spokojniej, może nawet zmniejszy częstotliwość testów penetracyjnych, a z poczynionych oszczędności ktoś przyzna mu premię.

A kiedy padną ofiarą ataku… winny będzie MSSP, który przegrał zawody w kopaniu się z koniem.

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.

Dostawa urządzenia firewall – Sąd Okręgowy w Warszawie [ZP/OI/54/12]

Informacja publiczna uzyskana w dniu 11.12.2014 w odpowiedzi na wniosek z dnia 28.11.2014. Zapytanie dotyczyło zamówienia publicznego pod tytułem:
“Upgrade urządzenia firewall Fortigate FG-620B, dostawa urządzenia firewall Fortigate FG-300C oraz urządzenia firewall Fortigate FG-200B wraz z aktualnymi oprogramowaniami i konfiguracją, a także aktualizacja oprogramowania w urządzeniu FortiAnalizer 1000C wraz konfiguracją, wsparcie techniczne oraz szkolenie z obsługi przedmiotowych urządzeń”

Zamawiający: Sąd Okręgowy w Warszawie

Treść odpowiedzi:

SO-ado 065-1182_14

Załączniki do odpowiedzi na zapytanie:

SOWAW-image2014-12-11-145437
SOWAW-image2014-12-11-145906
SOWAW-image2014-12-11-150341
SOWAW-image2014-12-11-151020
SOWAW-image2014-12-11-151207

Dostawa zapór sieciowych – Urząd Patentowy RP [BG-II/211/28/2014]

Informacja publiczna uzyskana w dniu 08.12.2014 w odpowiedzi na wniosek z dnia 28.11.2014. Zapytanie dotyczyło zamówienia publicznego pod tytułem:
“Dostawa zapór sieciowych typu Edge Firewall i Internal Firewall wraz z instalacją i konfiguracją”

Zamawiający: Urząd Patentowy RP

Treść odpowiedzi:

UPRP-BG-II_211_28_2014

Załączniki do odpowiedzi na zapytanie:

UPRP-300004-2014
UPRP-SIWZ_08
UPRP-MONOLIT

Dostawa urządzeń do ochrony sieci – Krajowe Biuro Wyborcze [ZP-3710-23/14]

Informacja publiczna uzyskana w dniu 28.11.2014 w odpowiedzi na wniosek z dnia 27.11.2014. Zapytanie dotyczyło zamówienia publicznego pod tytułem:
“Zakup, dostawa i wdrożenie 50 urządzeń do ochrony sieci z systemem do centralnego zarządzania dla Krajowego Biura Wyborczego i delegatur Krajowego Biura Wyborczego”

Zamawiający: Krajowe Biuro Wyborcze

Treść odpowiedzi:

KBW-ZP-3710-23_14

Dokumenty dostępne pod adresem http://pkw.gov.pl/zamowienia-publiczne/zakup-dostawa-i-wdrozenie-50-urzadzen-do-ochrony-sieci-z-systemem-do-centralnego-zarzadzania-dla-krajowego-biura-wyborczego-i-delegatur-krajowego-biura-wyborczego.html w dniu 18.02.2015:

ZP-3710-23-14zawiadomienie o wyborze najkorzystniejszej oferty
ZP-3710-23-14zawiadomienie o poprawieniu oczywistej omyłki rach

SIWZ_23_14 – AK

Załącznik do odpowiedzi na zapytanie:

SKMBT_C45214112814130-oferta na UTM-y