Tag Archives: security

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.

Zasada czystego biurka – clean desk policy

CC BY-NC-SA 2.0 Tal-Bright
CC BY-NC-SA 2.0 Tal Bright

Przemierzałem budynek, w  którym obowiązuje zasada czystego biurka (clean desk policy), a na ścianach co kilka metrów wiszą plakaty przypominające o tym fakcie. Mijając małą salę konferencyjną zobaczyłem stół przygotowany dla trzech osób, na nim dokumenty, a w promieniu kilku metrów nie było żywej duszy. Zdjęcia brak, bo wykonywanie zdjęć było zabronione (ale jak wiadomo, norma prawna zapisana w art. 278 Kodeksu Karnego nie jest respektowana przez złodziei, a intruz niekoniecznie będzie zainteresowany przestrzeganiem polityki bezpieczeństwa).

FireEye, FPC, DLP, IPS i inne słowa kluczowe dobrze sie sprzedają. Niestety najsłabszym ogniwem byli i są ludzie, a nie środki techniczne. Z drugiej strony nie ma lepszej ochrony niż zespół dobrze wyszkolonych, inteligentnych osób.

Ciekawe jak często można pracownikom przeprowadzać szkolenie z podstaw bezpieczeństwa – unikając zmęczenia materiału i mechanicznych odpowiedzi pozbawionych odrobiny refleksji – tak żeby każdy cykl szkoleń zmniejszał liczbę klikniętych linków, otwartych załączników w niezamawianej korespondencji elektronicznej, czy też pozostawionych na biurku przedmiotów.

W tym temacie: ciekawa decyzja administracyjna dotycząca poświadczenia bezpieczeństwa.

Bezpieczna komunikacja przy użyciu pojemnika z moczem

Nie wiem jak często przedstawiony poniżej sposób komunikowania się jest wykorzystywany, ale niewątpliwie jest prosty a zarazem dość bezpieczny – a tych dwóch kryteriów łącznie nie spełnia np. GPG – tutaj instrukcja wysyłania zaszyfrowanej wiadomości.speak-in-confidence

Dla wyjaśnienia – ulotka, pojemnik oraz naklejki zlokalizowane są w toalecie dla pacjentek. Pojemnik (oznakowany lub nie) pacjentka pozostawia na półce w środku, a personel regularnie odbiera cały zestaw pojemnikó. Dość skutecznie blokuje to możliwość przechwycenia wiadomości przez osobę niepożądaną.

W Wielkiej Brytanii położne rutynowo odpytują ciężarne czy mają wsparcie w domu, czy mają jakieś problemy, a czasami wprost – czy nie są ofiarami przemocy. Często podczas spotkania obecny jest mąż/partner pacjentki – co oczywiście stanowi przeszkodę, jeżeli jest on domniemanym sprawcą. Jednym ze sposobów na ominięcie tego problemu jest sprowokowanie sytuacji sam na sam przy użyciu różnych zabiegów socjotechnicznych, ale oprócz tego, jak widać na załączonym powyżej obrazku, istnieje dodatkowy kanał komunikacji.

“Proszę pozostawić nam próbkę do analizy – w toalecie, na ścianie po lewej stronie jest instrukcja.”

 

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.