Wielka debata: Zabezpieczanie poprzez ukrywanie

Autor: Jesper M. Johansson i Roger Grimes

Opublikowano: 28 października 2008

Zawartość strony

	Wprowadzenie do tematu zabezpieczania poprzez ukrywanie
	Ocena metod zabezpieczania
	Ukrywanie konta administratora
	Stanowisko Rogera
	Kolej na Jespera
	Wszystko sprowadza się do zarządzania ryzykiem
	Nie zmieniajcie ustawień domyślnych według Steve’a Riley
	Zmiana nazwy konta administratora według Aaron Margosis

 

Termin "zabezpieczanie poprzez ukrywanie" (ang. security by obscurity) spotyka się często z drwiną ze strony osób odpowiedzialnych za bezpieczeństwo, w szczególności tych uważających siebie za ekspertów. Zabezpieczanie przez ukrywanie to w pewnych kręgach niemal obelga, cytując Wikipedię (en.wikipedia.org/wiki/Security_through_obscurity), reprezentuje jeden z najbardziej kontrowersyjnych aspektów bezpieczeństwa. Często słyszymy pogardliwe uwagi kierowane do osób, których wysiłek jest kwitowany jako "jedynie zabezpieczanie poprzez ukrywanie".

Zabezpieczanie poprzez ukrywanie jest, w uproszczeniu, niezgodne z zasadą Kerckhoffsa, która głosi, iż system powinien być bezpieczny ze względu na swój projekt, a nie ponieważ przeciwnicy nie znają tego projektu. Zgodnie z podstawowym założeniem zasady Kerckhoffsa żaden sekret długo się nie utrzyma.

Dobry przykład stanowi protokół uwierzytelniania Windows NT® LAN Manager (NTLM), który był początkowo uważany za tajemnicę projektową. Jednak w celu zaimplementowania współpracy z systemami operacyjnymi UNIX zespół tworzący produkt Samba musiał poddać protokół inżynierii wstecznej. Efektem było udostępnienie najbardziej kompletnej dokumentacji protokołu NTLM (monyo.com/technical/samba/translation/ntlm.en.html), jak również odkrycie wielu błędów. Ze względu na to, iż tak duża część zabezpieczeń wywodzi się z kryptografii i tyle sekretnych projektów zostało ujawnionych, wielu specjalistów ds. zabezpieczeń wierzy, że wszystkie mechanizmy ochrony informacji powinny spełniać zasadę Kerckhoffsa.

Ale czy zabezpieczanie poprzez ukrywanie to zawsze zły pomysł? W niniejszym artykule pokażemy, na czym polega zabezpieczanie poprzez ukrywanie. Spróbujemy w pewnym stopniu wyjaśnić, dlaczego niektórzy uważają je za stratę czasu (a inni nie), a także pokażemy, dlaczego odpowiedź jest zwykle dużo bardziej skomplikowana niż to się z pozoru wydaje.

Wprowadzenie do tematu zabezpieczania poprzez ukrywanie

Termin zabezpieczanie poprzez ukrywanie nie dotyczy projektów, które nie robią absolutnie nic w kierunku złagodzenia problemu. Na przykład organizacja, która blokuje ruch Network News Transfer Protocol (NNTP) na routerach granicznych, aby uniemożliwić pracownikom czytanie grup dyskusyjnych, a jednocześnie zezwala na wychodzący ruch Secure Shell (SSH), nie stosuje zabezpieczania poprzez ukrywanie. Ponieważ SSH może tunelować dowolny protokół, problem nie jest ukryty. Niemądry mechanizm zabezpieczający, który został zaimplementowany, nie robi nic poza uniemożliwianiem uprawnionym użytkownikom realizowania uzasadnionych zadań bez łamania reguł zabezpieczeń. Takich przedsięwzięć nie można skategoryzować jako zabezpieczania poprzez ukrywanie, ponieważ są one niemądre i bezsensowne.

Jak wskazuje słowo "zabezpieczanie" w wyrażeniu "zabezpieczanie poprzez ukrywanie", przedsięwzięcie powinno w pewien sposób zwiększać bezpieczeństwo. Jednak jak również wskazuje nazwa (i na tym polega problem), nie robimy właściwie nic, aby zatrzymać ataki na jeden lub więcej wektorów (wektor ataku to zasadniczo środki pozwalające osobie atakującej dostać się do systemu).

Przypuśćmy, że mamy na przykład podatny na ataki serwer sieci Web, który może zostać zaatakowany za pośrednictwem protokołu TCP poprzez port 80 przy użyciu złośliwego kodu wykorzystującego lukę zabezpieczeń oprogramowania. Aby powstrzymać określony wektor, możemy zainstalować poprawki na serwerze sieci Web lub wyłączyć go. Obie te akcje całkowicie zablokują dany wektor. Możemy częściowo zatrzymać wektor ataku, wykorzystując zaporę lub zabezpieczenie IPsec do zamknięcia portu 80 dla wszystkich komputerów poza kilkoma wybranymi. To nie zatrzyma w pełni wektora ataku, ale znacznie zredukuje skalę problemu.

Natomiast zabezpieczanie poprzez ukrywanie wiąże się z podjęciem kroków, które nie zatrzymują wektora ataku, a jedynie go ukrywają. Możemy na przykład zdecydować się na skonfigurowanie dla serwera sieci Web portu 81 zamiast 80, aby tylko osoby, które wiedzą gdzie szukać serwera sieci Web, mogły go odnaleźć. Przynajmniej tak to wygląda w teorii. W rzeczywistości przeniesienie serwera sieci Web na port 81 zatrzymuje tylko niektóre ataki i przysparza kłopotów głównie użytkownikom końcowym. Kompetentny intruz uruchomiłby po prostu skaner portów i narzędzie analizujące nasłuchujące usługi na wysokiej liczbie portów w celu wykrycia serwerów sieci Web na niestandardowych portach. Jak tylko uda mu się odnaleźć jakiś serwer, może rozpocząć atakowanie go, ponieważ wektor ataku nie został tak naprawdę wyeliminowany, a jedynie (tymczasowo) ukryty.

Czy to oznacza, że nie powinniśmy nawet próbować? Odpowiedź brzmi: to zależy. Podobnie jak w przypadku innych aspektów związanych z dziedziną ochrony informacji, wszystko sprowadza się do zarządzania ryzykiem. Aby pomóc czytelnikom w zrozumieniu kluczowych czynników, które należy wziąć pod uwagę, zaprezentujemy szybki przegląd kilku dodatkowych metod zabezpieczania poprzez ukrywanie, a następnie w sposób szczegółowy zajmiemy się jedną z nich, a mianowicie zmianą nazwy konta Administrator.

 Do początku strony

Ocena metod zabezpieczania

Istnieje wiele przykładowych metod zabezpieczania poprzez ukrywanie. Mogą to być akcje podejmowane przez menedżerów systemu i sieci lub inicjowane przez programistów. Wszystkie one mają jeden cel, a mianowicie zmniejszenie podatności na ataki luk zabezpieczeń poprzez ukrycie ich przed potencjalnymi wrogami.

Czy część z tych procedur nie przynosi przynajmniej niewielkich korzyści? Czy sprawiedliwe jest stwierdzenie, że wszystkie metody zabezpieczania poprzez ukrywanie są bezcelowe? Z pewnością można znaleźć zwolenników chociaż niektórych z tych metod. Na przykład w systemie Windows® można ukryć litery dysków w Eksploratorze Windows. Wiele środowisk, w szczególności szkolnych laboratoriów komputerowych, wykorzystuje tę technikę do powstrzymywania użytkowników przed zapisywaniem danych na twardym dysku. Oczywiście wiele aplikacji nadal potrafi zapisywać dane na twardym dysku, a zatem metoda ta ma niewielką wartość jako rozstrzygający środek zabezpieczający. Jednak instytucje, które zaimplementowały tę metodę, często twierdzą, że zredukowało to ilość danych na twardym dysku.

Innego typu praktyką zabezpieczania poprzez ukrywanie często implementowaną w systemie Windows jest wyłączanie administracyjnych udziałów sieciowych (takich jak C$, Admin$ itd.). Ma to służyć powstrzymaniu intruzów przed zdalnym łączeniem się z komputerem. W rzeczywistości nie tylko nie jest to prawdą, ale osoba atakującą posiadająca konto, które może wykorzystywać udziały administracyjne, może zdalnie włączyć te udziały. Mimo to wiele organizacji zarzeka się, że wyłączenie udziałów administracyjnych pozwoliło im zredukować częstotliwość pojawiania się złośliwego oprogramowania w ich sieciach.

Jednym z naszych ulubionych przykładów nietrafionych przedsięwzięć jest ustawienie "Zezwalaj na oddokowywanie bez potrzeby logowania się" (Allow undock without having to log on) w systemie Windows. Jeśli ustawienie to jest wyłączone, przycisk " Oddokuj komputer" (Undock computer) na ekranie logowania zostaje ukryty. Koncepcja jest taka, że w ten sposób osoba atakująca nie może w elegancki sposób oddokować komputera. Oczywiście może po prostu włożyć komputer i stację dokującą do torby i zabrać je ze sobą, niezależnie od tego czy przycisk jest czy nie jest widoczny. Metody tej nie można nawet nazwać zabezpieczeniem poprzez ukrywanie.

Innym jasnym przykładem jest ustawienie "Zezwalaj operatorom serwera na planowanie zadań" (Allow Server Operators to schedule tasks), które jak wskazuje jego nazwa, umożliwia planowanie zadań użytkownikom należącym do grupy Operatorzy serwera. Jest to wrażliwa kwestia, ponieważ tego typu zadania mogą być uruchamiane jako System lokalny i jedynie administratorzy powinni mieć możliwość umieszczania w harmonogramie zadań działających w tym kontekście. Oczywiście operatorzy serwera mogą potencjalnie uczynić się administratorami przy pomocy różnych wektorów, a zatem uniemożliwienie im planowania zadań w ten sposób ma w rzeczywistości minimalną wartość.

Mimo to wiele organizacji lubi to ustawienie, ponieważ dzięki niemu inżynierowie mogą być operatorami sieci a nie administratorami, co zmniejsza prawdopodobieństwo, że przypadkowo uszkodzą oni serwer. Ta metoda może sama w sobie przynosić pewne korzyści.

A zatem jaki jest werdykt? To oczywiste, że pewne problemy mogą być bardzo skomplikowane. Spędziliśmy wiele przyjemnych godzin, debatując na temat tych metod. Roger zdecydowanie należy do obozu, który docenia wartość tego typu praktyk. Z kolei Jesper wierzy, że w większości sytuacji są one co najmniej stratą czasu. Przyjrzyjmy się jednemu z najczęściej przytaczanych i najbardziej kontrowersyjnych przypadków zabezpieczania poprzez ukrywanie, a mianowicie modyfikowaniu nazwy konta Administrator. Roger będzie przemawiał za zastosowaniem tej metody, Jesper przeciwko. Eksperci w dziedzinie bezpieczeństwa Aaron Margosis oraz Steve Riley również zabiorą głos w dyskusji, odpowiednio w sekcjach "Zmiana nazwy konta administratora" oraz "Nie zmieniajcie ustawień domyślnych".

 Do początku strony

Ukrywanie konta administratora

Operacja zmiany nazwy konta administratora o identyfikatorze względnym (RID) 500 na nazwę inną niż powszechnie znana jest często zalecana przez specjalistów ds. bezpieczeństwa i została umieszczona w kilku poradnikach firmy Microsoft dotyczących ochrony systemu. Zasady grup zawierają nawet ustawienie służące do zmiany nazwy konta administratora, jak pokazano na Rysunku 1. Idea jest taka, że jeśli nazwa konta administratora zostanie zmieniona, intruzowi trudniej będzie zalogować się do systemu w roli prawdziwego administratora. Oczywiście niewątpliwy problem związany z zastosowaniem zasad grupy w tej operacji polega na tym, że konto administratora o zmienionej nazwie będzie miało tę samą nazwę na każdym komputerze, na którym zostanie zastosowana ta zasada grupy. To obniża wartość ukrycia w tej konkretnej metodzie zabezpieczania.

Rysunek 1: Zmiana nazwy konta administratora.

W tym kontekście ważne jest również uświadomienie dobie, że dowolny użytkownik z uprawnionym kontem może pobrać nazwę konta administratora, niezależnie od tego czy nazwa ta została zmieniona. Konto administratora zawsze posiada identyfikator RID równy 500. Pytając po prostu o nazwę konta o RID 500, każdy użytkownik posiadający konto może zobaczyć, co zostanie wywołane, jak pokazano na Rysunku 2.

Rysunek 2: Odnajdowanie kont administratora o zmienionej nazwie.

 Do początku strony

Stanowisko Rogera

Głównym argumentem powtarzanym przez przeciwników zmiany nazwy konta administratora jest to, że można łatwo przekonwertować dowolną nazwę konta podmiotu zabezpieczeń do związanego z nim identyfikatora zabezpieczeń (SID) i odnaleźć identyfikator RID. A prawdziwe konto administratora zawsze posiada identyfikator RID równy 500. A zatem jeśli intruz może łatwo przekonwertować nazwy kont użytkowników do kombinacji SID/RID i określić RID 500, po co w ogóle się kłopotać?

Jednak nie jest to takie proste. W celu przeprowadzenia translacji nazwy konta użytkownika-do-SID/RID trzeba posiadać dostęp do portów NetBIOS lub LDAP. Większość granicznych zapór sieciowych nie zezwala na tego typu dostęp za pośrednictwem Internetu, a zatem, o ile intruz kompletnie nie ominie zapory, nie będzie mógł dokonać żadnej konwersji. Co więcej anonimowe translacje identyfikatorów SID nie działają w systemie Windows XP i późniejszych wersjach systemu Windows, za wyjątkiem kontrolerów domeny (DC). W przypadku większości komputerów z dostępem z zewnątrz (czyli tych najbardziej narażonych na ryzyko), intruz potrzebowałby poświadczeń uwierzytelniających do przeprowadzenia translacji nazwa-do-SID.

A zatem istnieje sporo rzeczywistych wielowarstwowych przeszkód, które trzeba ominąć w celu rozpoczęcia ataku translacyjnego. A nawet jeśli intruzowi uda się dojść tak daleko, ląduje w tym samym miejscu, w którym znalazłby się, gdyby nazwa konta nie została zmieniona. Zmiana nazwy konta administratora może jedynie zwiększyć bezpieczeństwo, z pewnością nie może mu zaszkodzić.

Jest to kolejny sekret Jeśli intruz nie zna nazwy konta administratora, staje się ono kolejną "sekretną" etykietą, analogiczną do hasła, którą intruz musi zdobyć. Co prawda nazwy kont użytkowników są zwykle znacznie dużo mniej złożone niż hasło administratora, ale zawsze jest to dodatkowa przeszkoda, która eksponencjalnie komplikuje problem zgadywania/łamania haseł. Czytelnicy, którzy przeprowadzali kiedykolwiek testy penetracyjne haseł, wiedzą, ile starań trzeba dołożyć, aby odgadnąć zarówno nazwę, jak i hasło użytkownika. To znacznie komplikuje już bardzo trudne zadanie.

Powstrzymuje zautomatyzowane złośliwe programy i skrypciarzy amatorów Już od 22 lat zajmuję się obroną zabezpieczeń systemu Windows, od ponad 5 lat posiadam również 8 maszyn-przynęt podłączonych do sieci Internet, działających pod kontrolą systemu Windows. Przez cały ten czas nigdy nie widziałem, aby zautomatyzowane złośliwe programy (stanowiące większość wszystkich ataków) kiedykolwiek wykorzystywały inną nazwę konta użytkownika niż Administrator (lub root w przypadku systemów *NIX). Zmieniając nazwę konta administrator, natychmiastowo blokujemy całe złośliwe programy bazujące na nazwie Administrator. A to pozwala zredukować zagrożenie bezpieczeństwa.

To samo dotyczy skrypciarzy amatorów. Każda instrukcja dla początkujących hackerów, jaką znam, wspomina o technikach translacji nazwa-do-SID, lecz z jakiegoś powodu nigdy nie została ona zastosowana na żadnej z moich przynęt, jeśli posiadałem również "fałszywe" konto Administrator w celu zniechęcenia ich. Dobrzy hakerzy powinni zawsze weryfikować, czy odnalezione przez nich konto Administrator jest prawdziwym kontem administratora (RID 500), niemniej jednak tego nie robią. Nie wiem dlaczego, być może wynika to z lenistwa hakerów i zwykłej ludzkiej natury.

Zatrzymuje również większość profesjonalistów To zaskoczy wiele osób. Ponieważ od lat prowadzę maszyny-przynęty, szybko nauczyłem się rozpoznawać różnice między zautomatyzowanymi atakami, skrypciarzami amatorami i profesjonalistami. W ciągu ostatnich lat przy milionach zaraportowanych ataków przeciwko moim przynętom, nigdy nie widziałem, aby profesjonalista dokonywał translacji identyfikatora SID, gdy istniało fałszywe konto Administrator.

Jestem pewny, że niektórzy profesjonalni przestępcy przeprowadzają translację identyfikatora SID, ale jestem skłonny założyć się, że stanowią oni rzadko spotykaną mniejszość. Dlaczego profesjonaliści nie korzystają z tej metody? Podejrzewam, że nie chce im się próbować czegoś tak mało popularnego.

Upraszcza ostrzeganie Teraz pewnie przeciwnicy ukrywania mogą zauważyć, że gdyby metoda zmiany nazwy konta administratora upowszechniła się, straciłaby swoją wartość jako techniki ukrywania. Argument jest taki, że złośliwe programy, skrypciarzy amatorzy i profesjonaliści zmieniliby domyślną taktykę tak, aby poszukiwać nazw innych niż tylko Administrator. I jest to rzeczywista obawa. Na szczęście nie zmienia ona niezbędnego warunku. Po pierwsze, jeśli super uprzywilejowane konto systemu Windows nie nosi nazwy Administrator, złośliwy haker musi się bardziej napracować. To po prostu fakt. A jeśli złośliwy haker musi się bardziej napracować, istnieje mniejsze prawdopodobieństwo, że będzie próbował tego typu ataku, a być może pozwoli jednej z pozostałych warstwowych technik obrony wykryć wcześniej niepożądaną aktywność.

I to prowadzi do ostatniego argumentu przemawiającego za zmianą nazwy. Jeśli konto administratora nie nosi nazwy Administrator i stworzymy inne konto o tej nazwie, jak pokazano na Rysunku 3, otrzymujemy wygodny mechanizm ostrzegania. Jeśli mechanizm monitorowania zdarzeń wykryje próbę logowania przy użyciu domyślnej nazwy, zdarzenie to powinno zostać natychmiast zbadane.

Rysunek 3: Rejestrowanie prób użycia konta pułapki o nazwie Administrator może służyć jako wczesne ostrzeżenie.

Nasze dzienniki zdarzenia są pełne "złych" logowań, które nic nie oznaczają. Zazwyczaj to po prostu użytkownik (lub system Windows) usiłuje zalogować się przy użyciu błędnego hasła. Jak możemy w prosty sposób odróżnić zwykłe próby logowania od tych złośliwych, jeśli nasze konto administratora nosi nazwę Administrator? Natomiast jeśli nigdy nie używaliśmy konta o nazwie Administrator i wykryjemy próbę logowania z wykorzystaniem tej nazwy, mamy prawo podejrzewać złośliwy atak. Wczesne, subtelne ostrzeżenie stanowi bardzo cenną informację w dzisiejszym świecie zabezpieczeń.

 Do początku strony

Kolej na Jespera

Podobnie jak argumenty przemawiające za zmianą nazwy konta administratora, istnieją także argumenty przemawiające przeciwko niej. Jednak zanim się nimi zajmiemy, muszę przyznać, iż ostatnie spostrzeżenie Rogera jest całkiem trafne. Jednak w środowisku o wysokim stopniu zarządzania każde logowanie przy użyciu konta Administrator powinno być sprawdzane, ponieważ konto to nie powinno być wykorzystywane w ogóle (poza sytuacją przeprowadzania awaryjnego odzyskiwania).

Jest nieużyteczna Głównym zagrożeniem, jakie ma redukować zmiana nazwy konta administratora, jest ryzyko zdalnego zgadywania hasła. Jednak tylko użytkownik, który nie posiada innego autoryzowanego konta na komputerze, mógłby zostać odstraszony przez zmianę nazwy konta administratora. Osoba atakująca zazwyczaj testuje serię losowych haseł w celu zalogowania się do konta administratora. Tego typu intruz otrzymuje identyczny komunikat o błędzie niezależnie od tego, czy wprowadził błędną nazwę konta czy hasło.

To podważa słuszność jednego z głównych argumentów przemawiających rzekomo za zmianą nazwy konta administratora, a mianowicie twierdzenia, iż zniechęci ona skrypciarzy amatorów. Nie zrezygnują oni ani trochę wcześniej niż w sytuacji, gdy nazwa konta administratora nie została zmieniona, ponieważ nie zauważą żadnej różnicy! Spróbują losowo odgadnąć hasło taką samą ilość razy, a następnie zajmą się kolejną potencjalną ofiarą.

A to oznacza, że dopóki hasło administratora jest wystarczająco silne, aby odeprzeć atak, zmiana nazwy konta nie stanowi żadnej dodatkowej wartości. Powiedzmy, że mamy na koncie Administrator 15-znakowe hasło składające się z dużych i małych liter, cyfr i symboli wybranych z całego zestawu oferowanego przez klawiaturę. Odgadnięcie hasła za pośrednictwem sieci zajmie około 591 310 404 907 lat. Dla porównania wszechświat istnieje około 43 razy krócej.

A teraz powiedzmy, że zmieniamy nazwę konta administratora i ustawiamy jedną z 1000 możliwych wartości. Przedłużylibyśmy czas zgadywania hasła do 591 310 404 906 787 lat, czyli okresu o 43 161 razy dłuższego niż czas istnienia wszechświata. Czy jesteśmy dzięki temu bezpieczniejsi? Oczywiście, o trzy rzędy wielkości bezpieczniejsi. Czy zmniejszyliśmy prawdopodobieństwo, że osoba atakująca odgadnie nasze hasło? Cóż w obu przypadkach jest ono nieskończenie małe. Innymi słowy, w rzeczywistości zmiana nazwy konta administratora praktycznie nie poprawiła naszej sytuacji. Sam fakt, iż zmiana nazwy konta powstrzymuje złośliwe programy usiłujące ją wykorzystać, nie oznacza, że programy te odniosłyby sukces w przypadku niedokonania tej zmiany. W rzeczywistości jeśli wykorzystujemy silne hasło (co powinniśmy robić), mamy praktyczną gwarancję, że ataki nie powiodą się niezależnie od nazwy konta.

To prawda, że wiele poradników dotyczących bezpieczeństwa wymaga zmiany nazwy konta Administrator. Ale to nie czyni tej operacji wartościową, ani nawet prawidłową metodą zabezpieczania. Po prostu pozbawia nas możliwości dokonania właściwej decyzji dotyczącej zarządzania ryzykiem w tym aspekcie. Poradniki dotyczące bezpieczeństwa bardzo często wymagają konfiguracji ustawień, które nie czynią żadnej różnicy, a w wielu wypadkach nawet nie istnieją. Ostatecznie, aby rozwijać się w dziedzinie bezpieczeństwa, musimy wyjść ponad wymagania i naprawdę przeanalizować pewne kwestie oraz ocenić, czy wybrane metody zabezpieczeń mają sens. Należy pamiętać przy tym o jednej ważnej sprawie: sam fakt, iż dana funkcja jest atakowana przez intruzów, nie jest wystarczającym powodem, aby dokonać jej modyfikacji. Należy zmodyfikować tę funkcję tylko wtedy, gdy istnieją uzasadnione obawy, że w przeciwnym przypadku ataki będą skuteczne.

Jeśli założymy silne hasło, prawdopodobieństwo powodzenia ataku jest praktycznie zerowe, niezależnie od nazwy konta. A zatem o ile posiada się silne hasło, nie istnieje praktycznie żaden konkretny powód przemawiający za zmianą nazwy konta. Co więcej, jeśli ktoś, tak jak ja, działa w myśl zasady, że komputer będzie prawdopodobnie bardziej stabilny, im mniej podrasowań i modyfikacji będziemy na nim dokonywać (przy okazji, to ogólnie znany fakt), jest to kolejny powód przemawiający za pozostawieniem oryginalnej nazwy konta administratora.

Koncentruje uwagę na mało wartościowych zabezpieczeniach Jeden z problemów związanych z metodami zabezpieczania poprzez ukrywanie jest to, że pociągają one za sobą ryzyko odwrócenia uwagi organizacji od bardziej wartościowych zabezpieczeń. Czas i wysiłek włożony na przykład w zmianę nazwy konta administratora nie mógł zostać wykorzystany w inny sposób. Jeśli ten inny sposób oferowałby większą wartość niż zmiana nazwy kont administratora, organizacja na tym straciła. Być może nie brzmi to jak prawdziwy koszt, ale wystarczy wyobrazić sobie zmianę nazw 50000 kont Administrator.

Co gorsza istnieje realne zagrożenie, iż po zastosowaniu tego mało wartościowego zabezpieczenia dyrekcja organizacji stwierdzi, że to wystarczy. Zarząd może nie zawsze rozumieć minimalną wartość metod zabezpieczania poprzez ukrywanie i może nie podjąć żadnych dodatkowych kroków, co może spowodować narażenie organizacji na poważne ryzyko. Choć zagrożenia tego można łatwo uniknąć, jeśli zarząd po prostu poświeci trochę czasu i wysiłku na zrozumienie wartości implementowanych metod zabezpieczeń.

Jest kosztowna pod względem zarządzania W zależności od sposobu implementacji zabezpieczenia zarządzanie nim może stać się dość kosztowne. Jeśli skonfigurujemy po prostu obiekt zasad grupy (GPO) dla zmiany nazwy konta administratora, koszt jest bardzo niski. Wszyscy będą znali nazwę, a trud wdrożenia będzie prawie zerowy. Jednak uzyskiwana wartość również będzie minimalna, ponieważ, jak wspominałem, każda osoba posiadająca konto będzie znała nazwę. A zatem, aby czerpać jak największe korzyści z tego mechanizmu ukrywania, trzeba zastosować różne nazwy na różnych hostach, a ten system staje się dość kosztowny pod względem zarządzania.

Dużo lepiej byłoby zastosować narzędzie to generowania haseł, takie jak passgen (protectyourwindowsnetwork.com/tools.htm) do ustawienia 100-znakowych w pełni losowych haseł dla wszystkich kont Administratora w sieci i do codziennego zarządzania wykorzystywać inne konta. Biorąc pod uwagę fakt, iż konto Administrator służy jedynie do odzyskiwania po awarii (za wyjątkiem systemu Windows Small Business Server 2003), nie powinno to w ogóle wpłynąć na system zarządzania siecią. Ponadto intruz miałby większe szanse na odnalezienie igły na dnie Pacyfiku niż na prawidłowe odgadnięcie hasła któregokolwiek z kont administratora. Gdy system koncertuje się na silnych, unikatowych hasłach, skrypciarze amatorzy mogą zgadywać, co tylko zechcą.

 Do początku strony

Wszystko sprowadza się do zarządzania ryzykiem

Praktycznie każdą metodę zabezpieczania poprzez ukrywanie można przeanalizować w zaprezentowany przez nas sposób. Istnieją zalety i wady każdego schematu i podejście, które sprawdza się w jednej organizacji, wcale nie musi odpowiadać potrzebom innej organizacji. W końcu wszystko sprowadza się do problemu zarządzania ryzykiem. Czy ryzyko przynajmniej równoważy koszt zaimplementowania rozwiązania? Każda podejmowana decyzja dotycząca ochrony zasobów informacyjnych musi stanowić poinformowaną decyzję zarządzania ryzykiem i rzadko kiedy wybory są czarno-białe.

To prawda, niektóre decyzje zostały podjęte za nas. Na przykład, chociaż możemy oczywiście nie decydować się na szyfrowanie informacji pochodzących z kart kredytowych lub przechowywać kody do weryfikacji tych kart, dowolna z tych decyzji pociąga za sobą utratę możliwości akceptowania kart kredytowych jako formy płatności. Prawdopodobny negatywny wpływ tej decyzji na firmę powoduje, że tak naprawdę nie mamy wyboru. Innymi słowy, chociaż jest to z pewnością decyzja dotycząca zarządzania ryzykiem, jej podjęcie nie przysparza większych trudności.

Prawdą jest również to, że nikt o zdrowym umyśle nie łączyłby otwartej sieci bezprzewodowej z wewnętrzną siecią odpowiedzialną za funkcjonowanie przedsiębiorstwa. Jednak to wcale nie znaczy, iż nie jest to decyzja z zakresu zarządzania ryzykiem. Jest. Ktoś może zdecydować się na wybranie takiej opcji i jeśli tak zrobi, powinien ponieść konsekwencje (co w rzeczywistości niestety prawie nigdy się nie zdarza).

Kluczowy krok polega na jasnym wyartykułowaniu problemu, który musi zostać rozwiązany, a także proponowanych rozwiązań wraz z ich zaletami i wadami. Takie podejście zapewnia dostęp do informacji, które są potrzebne do podjęcia świadomej decyzji z zakresu zarządzania ryzykiem. Bez tych informacji decyzje można oprzeć jedynie na przeczuciu, co rzadko stanowi dobre rozwiązanie.

 Do początku strony

Nie zmieniajcie ustawień domyślnych według Steve’a Riley

Jestem po stronie "nie zmieniać" w sporze na temat modyfikowania nazwy. To nie jest nawet kwestia bezpieczeństwa, chodzi o zarządzanie systemem. W miarę jak spędzam więcej czasu, zajmując się problemem zarządzania systemami (ponieważ zarządzanie i bezpieczeństwo stają się jednym), staję się coraz większym zwolennikiem nie zmieniania niczego, co może potencjalnie zwiększyć wrażliwość systemu. A jeden z niemal gwarantowanych sposobów zwiększenia wspomnianej wrażliwości polega właśnie na zmodyfikowaniu ustawień domyślnych. Istnieją dwa (no dobrze trzy) powody, dla jakich ludzie zmieniają ustawienia domyślne:

• Istnieje znane wymaganie dotyczące funkcjonalności zapewnianej przez zmianę.

• Istnieje przypuszczenie, że zmiana poprawi bezpieczeństwo.

• (Uwaga: niedorzeczność) Ktoś przeczytał o tym w artykule.

Jeśli musimy przeprowadzić zmianę domyślnej nazwy z powodu numer 1, możemy śmiało zabierać się do pracy. Tego typu zmiany rzadko skutkują niestabilnością systemu, ponieważ są zwykle wcześniej testowane.

Jeśli planujemy przeprowadzić zmianę nazwy domyślnej z powodu numer 2, warto rozważyć tę kwestię raz jeszcze. Tego typu zmiany nie są prawie nigdy testowane przez producenta oprogramowania i z tego powodu, producent nie może przewidzieć, w jaki sposób system będzie zachowywał się po dokonaniu zmiany. Ponadto z reguły istnieją dużo lepsze opcje alternatywne, które zapewnią prawdziwą ochronę.

Co z tego, że intruz zna nazwę konta? To hasło i jego siła powstrzymują go przed dostaniem się do systemu. Pragnienie zmiany domyślnych nazw konta, takich jak Administrator czy Gość, na trudne do odgadnięcia odpowiedniki często w rzeczywistości sygnalizuje chęć uniknięcia silnych haseł. Należy naprawić prawdziwy problem (słabość haseł) i w ten sposób można uniknąć zwiększania wrażliwości systemu (zmiany nazw domyślnych).

 Do początku strony

Zmiana nazwy konta administratora według Aaron Margosis

Jesper, w idealnym świecie miałbyś zupełną rację. Hasła byłyby zawsze wystarczająco silne, aby czynić metodę zgadywania "brute force" niewykonalną, a lokalne konta administratora -500 służyłyby jedynie do awaryjnego odzyskiwania. W rzeczywistym świecie jest jednak inaczej.

Pomimo iż pierwszorzędnie rozpowszechniasz wiedzę w dziedzinie bezpieczeństwa, w szczególności w ramach rewelacyjnej serii artykułów dotyczących długich haseł ("The Great Debates: Pass Phrases vs. Passwords" części 1, 2 i 3 pod adresem technet.microsoft.com/pl-pl/library/cc512613(en-us).aspx, technet.microsoft.com/pl-pl/library/cc512609(en-us).aspx oraz technet.microsoft.com/pl-pl/library/cc512624(en-us).aspx), wielu administratorów systemu nadal nie posiada aktualnej wiedzy na temat tego, jak wyglądać powinno silne hasło.

Jeszcze nie tak dawno temu hasło składające się z ośmiu losowych znaków wyznaczonych z wieloznakowych zbiorów uważane było za silne. Prawo Moore'a sprawiło, iż stanowisko to jest już nieaktualne. Edukacja użytkowników (i administratorów systemu) stanowi słabe ogniwo i najprawdopodobniej tak już pozostanie, przynajmniej dopóki temat siły haseł nie stanie się gorącym tematem, którym zainteresują się telewizyjne serwisy informacyjne.

A zatem biorąc pod uwagę fakt, iż obecnie zgadywanie rzeczywistego hasła nie trwa 600 miliardów lat i może być przeprowadzone w czasie lunchu, dodanie mnożnika x1000 może stanowić prawdziwą wartość. Co więcej w przypadku zautomatyzowanych ataków, które usiłują włamać się do konta o nazwie Administrator, zmiana nazwy konta stanowi skuteczne narzędzie obrony.

Czas i nakład pracy związany ze zmianą nazwy konta administratora jest zwykle niewielki. Zazwyczaj, jak wspomniałeś, jest to proste ustawienie GPO. Co więcej standard Federal Desktop Core Configuration zatwierdzony przez rząd amerykański (csrc.nist.gov/fdcc) wymaga zmiany nazwy konta -500. Modyfikacja nazwy stanowi zaledwie jedno z wielu wymaganych ustawień i nie zaobserwowałem, aby zajmowało ono zbyt wiele czasu bądź uwagi. Nie widziałem również nikogo, kto miałby złudzenia co do prawdziwej wartości tego zabezpieczenia i nie słyszałem jeszcze nikogo, kto powiedziałby "Nie musimy zarządzać poprawkami, bo zmieniliśmy nazwy kont administratorów".

Czy zmiana nazwy przynosi jakieś korzyści, gdy zmieniona nazwa konta jest taka sama w obrębie całej organizacji? Nie ma ona wielu zalet, ale posiada kilka. Po pierwsze blokuje zautomatyzowane ataki, które oczekują istnienia konta Administrator, a po drugie zestaw potencjalnych intruzów niekoniecznie stanowi podzbiór "wszystkich osób", które znają nową nazwę. Większe ryzyko istnieje, gdy lokalne konta administratorów, o nazwie zmienionej bądź nie, posiadają to samo hasło w obrębie całej organizacji. Zarządzanie nimi pozostaje większym i ważniejszym problemem. Wyłączenie konta -500 stanowi jeden ze sposobów radzenia sobie z tą kwestią, ale blokuje ważny mechanizm odzyskiwania, gdy konta domenowe nie mogą zostać wykorzystane. Wspomnę również, że nasze poradniki dotyczące zabezpieczeń od dawna zalecają zmianę nazw kont domyślnych, więc operacja ta została dobrze przetestowana i jest w pełni wspierana.

Chyba wszyscy wiemy już, że metody ukrywania same w sobie nie stanowią odpowiedniej obrony. Jednak mogą poprawić skuteczność innych technik zabezpieczania i dane przedstawione przez Rogera wyraźnie to ilustrują. Dopóki koszt ich implementacji jest mały, organizacje nie powinny ich wykluczać.

O autorach

Jesper M. Johansson to Software Architect zajmujący się oprogramowaniem zabezpieczającym oraz stały współpracownik magazynu TechNet Magazine. Posiada tytuł PhD w dziedzinie Management Information Systems i ponad 20-letnie doświadczenie w obszarze bezpieczeństwa. Został wyróżniony tytułem Microsoft MVP w zakresie Enterprise Security. Najnowsza książka Jespera to Windows Server 2008 Security Resource Kit.

Roger Grimes (CPA, CISSP, MCSE: Security) pracuje jako Senior Security Consultant w zespole Microsoft ACE, jest autorem bądź współautorem ośmiu książek dotyczących zabezpieczeń komputerów, napisał ponad 200 artykułów prasowych. Często zabiera głos jako lektor na konferencjach oraz jako specjalizujący się w dziedzinie bezpieczeństwa felietonista magazynu InfoWorld.

Do początku strony

---