Cisza w Sieci

Cisza w Sieci thesaint / www.sxc.hu

W idealnym świecie rozliczne metody analizy pakietów i strumieni danych pozwoliłyby nam zmierzyć wiele spośród parametrów zdalnego systemu i przypisać zaobserwowane zachowanie do sygnatury konkretnego systemu operacyjnego i konfiguracji Sieci.

Rzeczywistość wygląda jednak nieco inaczej, gdyż wartości niektórych spośród obserwowanych parametrów zawsze przynajmniej trochę odbiegają od zakresu oczekiwanego dla konkretnego urządzenia lub konfiguracji sieci podejrzanego. Można wprawdzie zignorować te z pozoru przypadkowe i pozbawione znaczenia różnice i niezależnie od ich obecności poprawnie identyfikować system źródłowy czy też śledzić jego użytkowników, ale niekoniecznie jest to rozsądne. Na co dzień przywykliśmy ignorować tego typu irytujące drobiazgi, ale nic w informatyce nie dzieje się bez dobrego powodu (zakładając oczywiście dość luźną definicję słowa „dobry”). Zbadanie mechanizmu powstawania tych pozornie losowych anomalii i pomniejszych prawidłowości pozwoli nam uzyskać cenne informacje o niewidocznych dotąd elementach konfiguracji Sieci.

Przyjrzymy się bliżej niektórym procesom mogącym wpływać na obserwowane zachowanie systemu. Postaram się też wyjaśnić podstawową przyczynę, cel (lub bezcelowość) oraz konsekwencje stosowania mechanizmów odpowiedzialnych za to zachowanie.

Podobne artykuły:

Większość spośród przedstawionych dalej i dających się odtworzyć modyfikacji pakietów IP pochodzi oczywiście od co bardziej zaawansowanych pośrednich systemów przetwarzających dane IP. Zacznę więc od omówienia dwóch nieco zaniedbanych tematów: firewalli w ogólności i translacji adresów sieciowych (NAT) w szczególności.

Firewalle mają w założeniu być nienaruszalnymi bastionami bezpieczeństwa – w końcu im mniej wiadomo o systemie użytkownika, tym lepiej dla niego. Jednak nawet w przypadku rygorystycznego przestrzegania wszystkich reguł i ustawień wzrost złożoności tych urządzeń i coraz lepsze ich przystosowanie do sprostania współczesnym zagrożeniom sprawiają, że jednocześnie łatwiej je identyfikować za pomocą pośrednich lub pasywnych technik badawczych.

Podstawy firewalli sieciowych

Popularne firewalle są – najprościej rzecz ujmując – pewnego rodzaju routerami, specjalnie zaprojektowanymi tak, by naruszać podstawową zasadę projektową routerów tradycyjnych. Zwykłe routery mają za zadanie podejmować decyzje o trasowaniu pakietów wyłącznie na podstawie informacji dostępnych w trzeciej warstwie modelu OSI, natomiast firewalle interpretują czy wręcz modyfikują dane wyższych warstw (na przykład TCP czy nawet HTTP). Pomimo swego względnie młodego wieku firewalle są powszechnie stosowanym i dobrze rozumianym rozwiązaniem zabezpieczającym, znajdującym miejsce zarówno w sieciach domowych, jak i w wielkich korporacjach. Odpowiednia konfiguracja firewalli pozwala odrzucać, dopuszczać lub przekierowywać określone rodzaje pakietów adresowanych do konkretnych usług, toteż są one stosowane do ograniczania dostępu do wybranych funkcji i zasobów z poziomu wszystkich pakietów przechodzących przez takie urządzenie. Firewalle są więc potężnym, choć niekiedy też przecenianym środkiem bezpieczeństwa sieciowego. 

Przyczyną popularności firewalli we wszystkich środowiskach sieciowych jest to, że pozwalają one chronić wiele różnych, złożonych systemów za pomocą pojedynczego, względnie odpornego na ataki elementu oraz stanowią dodatkowe, awaryjne zabezpieczenie na wypadek wystąpienia na chronionym serwerze problemu konfiguracyjnego powodującego ujawnienie podatności pewnej funkcji lub usługi. (W skrajnych przypadkach firewalle są po prostu wykorzystywane do ukrycia złej konfiguracji i braku konserwacji chronionego systemu, najczęściej z katastrofalnymi skutkami). 

Filtrowanie bezstanowe a fragmentacja

Proste firewalle są bezstanowymi filtrami pakietów. Ich działanie polega na sprawdzaniu określonych cech każdego pakietu (na przykład portu docelowego w pakietach SYN, stanowiących próby nawiązania połączenia TCP), a następnie podejmowaniu decyzji o ich ewentualnym przepuszczeniu wyłącznie na podstawie odczytanych informacji. Analiza bezstanowa jest bardzo prosta, niezawodna i wiąże się z bardzo niewielkim zużyciem pamięci. Bezstanowy firewall może na przykład ograniczać połączenia przychodzące do serwera poczty wyłącznie do połączeń z portem 25 (czyli SMTP), po prostu odrzucając wszystkie pakiety SYN adresowane do portów innych niż 25. Nawiązanie połączenia nie jest możliwe bez tego początkowego pakietu SYN, więc napastnik nie ma możliwości sensownej interakcji z aplikacjami na innych portach. Firewall może osiągnąć taki efekt przy znacznie mniejszej złożoności od samego serwera poczty, gdyż nie musi utrzymywać zapisów aktualnie nawiązanych połączeń i ich stanu. 

Dyskretna ochrona tego typu ma tę wadę, że firewall i docelowy odbiorca mogą różnie rozumieć niektóre parametry. Napastnik może na przykład przekonać firewall, że łączy się z dozwolonym portem, a pakiety spreparować w taki sposób, by odbiorca odczytał inny port docelowy, tym samym nawiązując połączenie na porcie, który firewall miał chronić. W ten sposób agresor może uzyskać dostęp do podatnej na atak usługi czy nawet interfejsu administracyjnego, co oznacza poważne kłopoty. 

Mogłoby się wydawać, że sprowokowanie takiego nieporozumienia jest mało prawdopodobne, jednak w rzeczywistości okazało się to zadaniem dość prostym dzięki pomocy naszego starego znajomego – fragmentacji pakietów. Podejście to nosi nazwę ataku z nachodzeniem fragmentów i zostało opisane w 1995 r. w dokumencie RFC1858 [2]. Atakujący zaczyna od wysłania na dozwolony port ofiary (na przykład wspomniany już port 25) pakietu inicjującego, zawierającego początek żądania SYN dla protokołu TCP. Pakietowi brakuje tylko kawałeczka danych i zawiera on w nagłówku IP znacznik sygnalizujący obecność dalszych fragmentów, ale dlaczego firewall miałby się interesować danymi pakietu? 

Firewall bada pakiet i stwierdza, że jest to pakiet SYN o dozwolonym porcie docelowym, więc żądanie zostaje przepuszczone do odbiorcy, który jednak nie interpretuje go od razu (ze względu na omówiony w rozdziale 9. proces składania fragmentów). Pakiet jest przetrzymywany aż do zakończenia składania, czyli do momentu otrzymania ostatniego fragmentu. 

Teraz napastnik wysyła drugi fragment pakietu, spreparowany tak, by zachodził na pierwszy pakiet, ale tylko tyle, by w buforze składania fragmentów nadpisać pole nagłówka TCP określające port docelowy. Przygotowany fragment zaczyna się od niezerowego przesunięcia i brakuje mu większości nagłówka TCP, z wyjątkiem części nadpisywanej. 

Drugi fragment nie zawiera żadnych danych, na podstawie których firewall mógłby decydować o jego odrzuceniu lub przepuszczeniu (brakuje mu znaczników, typu pakietu i innych niezbędnych informacji), więc firewall bezstanowy najczęściej przepuści go bez ingerencji. Po złożeniu fragmentów pakietu przez odbiorcę drugi fragment nadpisuje oryginalne pole portu docelowego inną wartością, odpowiadającą bardziej niegrzecznemu portowi wybranemu przez napastnika. W rezultacie system odbiorcy nawiązuje połączenie na porcie, który powinien być chroniony przez firewall. 

Nie za dobrze

Starannie zaprojektowany firewall bezstanowy potrafi chronić przed tego typu atakiem, wykonując wstępne składanie pakietów przed ich analizą. Tym samym staje się on jednak nieco mniej bezstanowy i nieco bardziej zauważalny. 

Filtrowanie bezstanowe a pakiety niezsynchronizowane

Inną wadą bezstanowych filtrów pakietów jest to, że wcale nie są one tak szczelne, jak moglibyśmy tego chcieć. Filtrowanie jest możliwe tylko wtedy, gdy pojedynczy pakiet zawiera wszystkie informacje niezbędne do podjęcia przez filtr decyzji o jego obsłużeniu. Po wstępnej negocjacji połączenia komunikacja TCP jest w dużej mierze symetryczna i obie strony wymieniają na takich samych prawach takie same dane (pakiety ACK), więc sensowne filtry da się zastosować wyłącznie do fazy negocjacji. Bez śledzenia i rejestrowania połączeń nie da się ustalić, kto (i czy w ogóle ktokolwiek) nawiązał połączenie, w ramach którego są wymieniane pakiety ACK. W praktyce oznacza to, że raczej ciężko jest zdefiniować sensowne reguły postępowania firewalla dla pakietów występujących podczas transmisji, a więc ACK, FIN czy RST. 

Niemożność filtrowania pakietów po początkowym SYN nie stanowi na ogół problemu jeśli napastnikowi nie uda się dostarczyć początkowego pakietu SYN, to nie będzie on w stanie nawiązać połączenia. Jest jednak pewien haczyk: różne systemy różnie reagują na pakiety inne niż SYN kierowane do konkretnego portu, w zależności od tego, czy dany port jest zamknięty, czy też system na nim nasłuchuje. Na przykład niektóre systemy odpowiadają pakietem RST na bezpańskie pakiety FIN, chyba że właśnie na danym porcie nasłuchują – wtedy w ogóle na takie pakiety nie reagują. 

Oznacza to, że przeciwko bezstanowym filtrom pakietów można stosować techniki skanowania FIN i ACK (ta druga została po raz pierwszy opisana przez Uriela Maimona w magazynie Phrack), jak również NUL i Xmas (metody skanowania wykorzystujące odpowiednio pakiety bez żadnych znaczników i ze wszystkimi znacznikami) pozwalające zbierać niezbędne do przeprowadzenia ataku informacje o otwartych portach w systemie zdalnym lub portach chronionych przez firewall. Samo ustalenie, że konkretny port jest otwarty (bez możliwości nawiązania połączenia), nie stanowi poważnego zagrożenia, jednak takie skanowanie często ujawnia niezwykle cenne informacje o wewnętrznej strukturze sieci (na przykład o systemie operacyjnym i aktywnych usługach), ułatwiające przeprowadzenie znacznie skuteczniejszego, wydajniejszego i trudniejszego w wykryciu ataku po przełamaniu lub ominięciu pierwszej linii obrony. Możliwość ta jest powszechnie uważana za wadę firewalli bezstanowych.

Potencjalnie poważniejsze zagrożenie wynika z połączenia filtrowania bezstanowego z mechanizmem podpisów SYN (ang. SYN cookies). Służy on do ochrony systemów operacyjnych przed atakami wyczerpania zasobów, polegającymi na wysyłaniu do ofiary dużych ilości fałszywych żądań nawiązania połączenia (co samo w sobie jest operacją bardzo prostą). Zmusza to odbiorcę to wysyłania bezcelowych odpowiedzi SYN+ACK, a w dodatku do alokowania pamięci i innych zasobów niezbędnych dla dodania każdego rzekomego połączenia do tablicy stanów TCP. Zaatakowany w ten sposób system najczęściej albo zużywa większość dostępnych zasobów i tym samym pracuje coraz wolniej, albo w pewnym momencie odmawia obsłużenia kolejnych klientó aż do upłynięcia czsu oczekiwania na fałszywe połączenia.

Mechanizm podpisów SYN dostarcza rozwiązanie tego problemu, polegające na odesłaniu odpowiedzi SYN+ACK z podpisem kryptograficznym w polu początkowego numeru sekwencyjnego (dokładniej mówiąc, jest to skrót kryptograficzny, stanowiący jednoznaczny identyfikator połączenia), a następnie zapomnieniu o całej sprawie. Połączenie zostanie dodane do tablicy stanów dopiero wtedy, gdy nadawca odeśle odpowiedź ACK, której numer potwierdzający poprawnie przejdzie stosowaną procedurę kryptograficzną. 

Metoda ta ma jednak pewną wadę: dopuszcza możliwość, że pierwotny pakiet SYN i odpowiedź SYN+ACK nie zostały w ogóle wysłane. Gdyby napastnikowi udało się stworzyć podpis ISN, który zostałby pomyślnie zweryfikowany przez algorytm weryfikacji podpisu po stronie odbiorcy (czy to ze względu na bardzo dużą liczbę prób, czy też z powodu słabości samego algorytmu), mógłby on wysłać pakiet ACK powodujący dodanie do tablicy stanów TCP odbiorcy nowego połączenia, choć – jak pamiętamy – żądanie SYN i odpowiedź SYN+ACK nigdy nie zostały wysłane. Bezstanowy firewall nie mógłby wtedy wykryć momentu nawiązania połączenia, gdyż po prostu nie otrzymał takiego żądania. Nie było początkowego pakietu SYN, więc firewall nie mógł sprawdzić jego portu ani odrzucić niebezpiecznego pakietu, a mimo to połączenie zostaje nagle nawiązane. 

Michał Zalewski Grupa Wydawnicza HELION SA Onepress.pl