Bezpiecznie choć nie całkiem

Mechanizmy stosowane na co dzień do ochrony systemów informatycznych mogą zostać wykorzystane przeciw firmie, dlatego z restrykcyjnością architektur zabezpieczeń i ich konfiguracji trzeba być bardzo ostrożnym.

Mechanizmy stosowane na co dzień do ochrony systemów informatycznych mogą zostać wykorzystane przeciw firmie, dlatego z restrykcyjnością architektur zabezpieczeń i ich konfiguracji trzeba być bardzo ostrożnym.

W trosce o zapewnienie wysokiego bezpieczeństwa administratorzy sięgają po coraz wymyślniejsze środki. Stosowanie coraz mocniejszych mechanizmów i coraz lepszych zabezpieczeń mnoży problemy i wynikające z niego dodatkowe wydatki na wsparcie techniczne. Znacznie bardziej przygnębiające jest jednak to, że mechanizmy i techniki służące do ochrony użytkowników przed czyhającym na nich złem mogą zostać użyte przeciw nim, a nawet przeciw firmie. O takie sytuacje wcale nie jest trudno - przykładów z życia wziętych jest aż nadto.

Umiar w przycinaniu

Sztandarowym przykładem złego pojmowania bezpieczeństwa jest bezmyślne konfigurowanie zapór sieciowych na zasadzie "bo inni też tak robią". Krążące na listach dyskusyjnych porady, co zrobić z tym czy innym problemem, nie przedstawiają problemów w pełnym świetle - skutki ich słuchania bywają opłakane. Jedna z takich rad mówi, że należy na zaporze odcinać komunikację z adresami IP, z których nadeszły pakiety sugerujące atak. Niewątpliwie, można w ten sposób osiągnąć święty spokój, tyle że będzie to spokój pozorny.

Z wrodzonym profesjonalizmem reagują szybko i sprawnie - blokują na routerach połączenia, adresy IP, a czasami całe klasy. Zdarza się, że administrator wyłącza komunikację ze wszystkimi domenami, które mają w nazwie słowo DSL lub Neostrada. Gdy reguły blokujące dostęp obejmą całą klasę adresów IP, z firmą nie skomunikują się ani osoby pracujące w domu, ani pracownicy chcący sprawdzić pocztę podczas podróży. Za jednym razem odcięci zostaną także kontrahenci, których nieszczęście polega na tym, że lokalnie nie występuje konkurencja w telekomunikacji.

Między administratorami krążą nawet listy z adresów, które warto zablokować. Poczesne miejsce zajmują na nich klasy adresowe przypisane do takich krajów, jak Chiny czy Korea Południowa. Takie listy ograniczą liczbę przypadków spamu i ataków na serwery, ale... skąd np. administrator w firmie hostingowej ma pewność, że zarządzany przez niego wirtualny serwer WWW klienta nie powinien odpowiadać na żądania dostępu z Chin? Do restrykcji na poziomie adresów IP należy podchodzić bardzo ostrożnie.

Bezpiecznie i obosiecznie

Typowym zabezpieczeniem, stosowanym powszechnie w firmach poważnie podchodzących do bezpieczeństwa, są tokeny. Obsługa popularnych tokenów RSA SecurID w środowisku terminalowym zazwyczaj zakłada dwustopniowe uwierzytelnienie: użytkownik loguje się za pomocą loginu i hasła, a potem używa tokena do wygenerowania chwilowego kodu dostępu (passcode) na podstawie wewnętrznego kodu i znanego przez użytkownika kodu PIN.

Wiele firm rezygnuje z tego, by użytkownik podawał hasło - przyjmują, że wystarczy, aby użytkownik podał login oraz passcode. To błąd, który może się mścić, gdy atakujący posiądzie umiejętność odkrycia, jak są tworzone loginy, względnie uda mu się dokonać zdalnej enumeracji nazw użytkowników. Tu nie chodzi o uzyskanie kontroli nad systemem, ale np. zablokowanie wszystkich kont chronionych tokenami.

Jeśli serwer uwierzytelnienia chroni oprócz terminala inne usługi (VPN, bazy danych, komputery lokalne, serwisy WWW, dostęp SSH), także i one staną się niedostępne. Będzie tak, ponieważ typowe ustawienie serwera tokenowego zakłada przejście po kilku nieudanych próbach logowania w tryb odczytu następnego kodu (next token code). Wtedy, po podaniu pierwszego prawidłowego odczytu, użytkownik musi poczekać na jego zmianę i podać (lub wygenerować) nowy. Gdy nieudanych prób jest więcej, token jest blokowany, a odblokować może go tylko administrator.

Zablokowanie dostępu tokenowego wszystkim użytkownikom jest technicznie rzecz biorąc kwestią kilku minut. Efektem jest całkowity paraliż firmy - użytkownicy nie mogą skorzystać z serwera terminalowego, bowiem mają zablokowane konta. Jeśli ktoś taki atak przeprowadzi, administrator nie będzie w stanie zaprowadzić porządku w systemie w rozsądnym czasie. A zatem, jeśli koniecznie trzeba zapewnić ochronę tokenami przy jednostopniowym logowaniu, należy wybierać loginy będące ciągami losowymi i zablokować enumerację.

Wspomniany mechanizm ataku daje się z powodzeniem zastosować do stron WWW chronionych tokenami. Jest to nawet prostsze od ataku na serwer terminalowy, bowiem automaty łączące się po HTTP lub HTTPS są od dawna dostępne. Dobrym wyjściem jest zastosowanie tunelowania poprzez VPN.

Widmo "czarnej listy"

Kolejny przykład bezrefleksyjnej przesady w dziedzinie bezpieczeństwa to "czarne listy" zawierające adresy serwerów, z których wysyłany jest często spam. Umieszczenie serwera na takiej liście skutkuje odrzucaniem e-maili przezeń przesyłanych na wielu serwerach docelowych. Jeśli do umieszczenia dojdzie przypadkowo, skutki odczuwalne są prawie natychmiast - komunikacja przez usługi poczty w zasadzie przestaje działać. Ponieważ dodanie adresu do listy nie wymaga skomplikowanych zabiegów, trzeba założyć, że możliwe jest wykorzystanie czarnych list w niecnych celach.

Wystarczy wykraść login i hasło jednego z użytkowników poczty, by za pośrednictwem jego konta rozesłać spam. Adresy to nie problem - istnieją programy, tzw. harvestery, które same skopiują adresy ze stron WWW. Rozesłanie spamu skutecznie włączy automatyczne dopisanie serwera nadawcy do wielu czarnych list naraz.

Kontrola tak, ale...

Jeszcze "lepsze" efekty daje się uzyskać, włamując się poprzez sieć bezprzewodową. Sieci WLAN są bardzo często słabo chronione, a ponadto bywają podłączane bezpośrednio do sieci LAN (często spotykany, acz szkolny błąd). Mając do czynienia z taką instalacją, można nie tylko unieruchomić pocztę, ale także stosunkowo łatwo zablokować wszystkie konta użytkowników w domenach Windows.

Wystarczy enumerować użytkowników (co w większości sieci się udaje) i próbować dostępu do każdego z nich z dowolnym hasłem dotąd, aż system uniemożliwi logowanie. Sieci WLAN są dość szybkie, zatem realne jest zablokowanie tą drogą kilkuset kont w ciągu kwadransa, jeśli włamywacz wie, jak i kiedy to zrobić. Konta blokowane są najczęściej tylko na pewien czas (zwykle kilka, kilkanaście minut), ale odpowiedni wybór kolejki w programie napastnika niemal gwarantuje całkowite zablokowanie uwierzytelnień przez cały czas ataku. Bywa, że administrator jest całkiem bezradny i musi odłączyć serwer. I tak cel zostaje osiągnięty.

Enumeracja użytkowników terminalowych jest dużo trudniejsza, ale efekty ataku polegającego na blokowaniu kont są takie same jak w przypadku ataku przez WLAN. Dlatego m.in. warto zastanowić się, czy użytkowników terminalowych włączać do domeny. Gdy do centralnego dla całej firmy systemu uwierzytelnienia podłączony jest serwer terminalowy, atakujący może z tego skorzystać. Znacznie odporniejsza na tego rodzaju ataki jest konfiguracja wykorzystująca dwie domeny z odpowiednio ustawionymi relacjami wzajemnego zaufania.

Nie ufać infrastrukturze

Gdy wielooddziałowa firma korzysta z sieci IP VPN skonfigurowanych jako full-mesh (wszystkie lokalizacje widzą się nawzajem) z rozgłaszaniem trasy domyślnej, zastosowanie systemu wykrywania i blokowania ataków wydaje się niemal koniecznością. System taki, choć skutecznie chroni na przykład przed lawinowymi atakami wirusów, może posłużyć do całkowitej dezorganizacji komunikacji w całej firmie.

Jeśli włamywaczowi uda się dostać do sieci lokalnej (np. poprzez atak od strony sieci WLAN lub prozaiczne podłączenie laptopa do wolnego gniazdka), wystarczy, by zaczął bombardować system IPS pakietami ze sfałszowanymi adresami źródłowymi, dzięki czemu sonda zaczęłaby blokować komputery posługujące się nimi. Atak taki byłby możliwy z dowolnej lokalizacji, włamywacz zapewne wybrałby tę, w której najprościej dałoby się osiągnąć zamierzony skutek. W efekcie większość komputerów w firmie traci łączność i firma ma poważne problemy.

Sztuka przewidywania

Wspomniane ataki są tylko na pozór drobnymi "złośliwościami". Jeśli będą powtarzać się dostatecznie często, a przyczyna nie zostanie szybko wykryta, firmę czekają kłopoty. Administratorzy będą atakowani z zewnątrz, ale i wewnątrz organizacji, co będzie szczególnie dokuczliwe. Nieco rozwagi, dobrze pojętego konserwatyzmu i myślenia o dalszych konsekwencjach podejmowanych działań (bądź zaniechań) zawsze się przyda, by nie paść ofiarą dowcipnisia, złośliwca lub... rynkowego konkurenta.

UPS też groźny

Czasami atak może pojawić się tam, gdzie nikt się go nie spodziewa. Niektóre duże zasilacze awaryjne UPS posiadają moduł sieciowy skonfigurowany tak, by móc nim zdalnie zarządzać. Bardzo dokuczliwym atakiem byłoby uporczywe, zdalne wyłączanie takiego zasilacza. Administrator podejrzewa awarię, serwis twierdzi zgodnie z prawdą, że sprzęt jest sprawny. Ale podłączone do zasilacza serwery nie będą w tym czasie działać bezproblemowo. Między innymi dlatego warto ostrożnie podchodzić do zarządzania poprzez sieć takimi urządzeniami, jak UPS czy centrala telefoniczna.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200