Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
PRZYK£ADOWY ROZDZIA£
PRZYK£ADOWY ROZDZIA£
IDZ DO
IDZ DO
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
KATALOG KSI¥¯EK
KATALOG KSI¥¯EK
TWÓJ KOSZYK
TWÓJ KOSZYK
CENNIK I INFORMACJE
CENNIK I INFORMACJE
ZAMÓW INFORMACJE
O NOWOŒCIACH
ZAMÓW INFORMACJE
O NOWOŒCIACH
ZAMÓW CENNIK
ZAMÓW CENNIK
CZYTELNIA
CZYTELNIA
FRAGMENTY KSI¥¯EK ONLINE
FRAGMENTY KSI¥¯EK ONLINE
SPIS TREŒCI
SPIS TREŒCI
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
KATALOG ONLINE
KATALOG ONLINE
Cisza w sieci
Autor: Michal Zalewski
T³umaczenie: Zbigniew Banach
ISBN: 83-7361-659-4
Tytu³ orygina³u:
Silence on the Wire
Format: B5, stron: 304
Praktyczne spojrzenie na zagadnienia bezpieczeñstwa w sieci
• Poznaj zasady dzia³ania protoko³ów sieciowych
• Naucz siê rozpoznawaæ zagro¿enia
• Zastosuj techniki obronne
W Internecie zdrowy rozs¹dek i zasady moralne, które obowi¹zuj¹ w rzeczywistym
œwiecie, trac¹ racjê bytu. Z racji coraz g³oœniejszych i coraz czêstszych kradzie¿y
danych i w³amañ do komputerów rozs¹dek zostaje zast¹piony paranoj¹ i obaw¹,
a komputerowi przestêpcy rzadko miewaj¹ wyrzuty sumienia. Bezpieczeñstwa w sieci
nie zapewnimy sobie, nie pope³niaj¹c b³êdów czy te¿ postêpuj¹c w okreœlony sposób.
Prawie z ka¿dym procesem informacyjnym wi¹¿¹ siê zagadnienia bezpieczeñstwa,
które nale¿y zrozumieæ.
„Cisza w sieci. Praktyczny przewodnik po pasywnym rozpoznaniu i atakach poœrednich”
to bardzo nietypowa ksi¹¿ka poœwiêcona technikom ochrony danych. Autor przedstawia
w niej zupe³nie inne spojrzenie na bezpieczeñstwo. Pokazuje niezwyk³e i niecodzienne
zagadnienia ochrony danych, które nie mieszcz¹ siê w ramach tradycyjnego modelu
haker — ofiara. Z tej ksi¹¿ki dowiesz siê o rzeczach, których istnienia nawet nie
podejrzewa³eœ, na przyk³ad o tym, ¿e generator liczb losowych mo¿e ujawniaæ
naciskane przez Ciebie klawisze, a postronny obserwator mo¿e zidentyfikowaæ Twój
system operacyjny, wy³¹cznie analizuj¹c pakiety sieciowe. Nauczysz siê rozpoznawaæ
takie zagro¿enia i przeciwdzia³aæ im.
• Bezpieczeñstwo generatorów liczb losowych
• Ataki na sieci prze³¹czane
• Dzia³anie protoko³u IP
• Pasywna identyfikacja systemów na podstawie pakietów IP i jej zapobieganie
• W³aœciwe stosowanie firewalli
• Techniki skanowania portów
• Identyfikacja u¿ytkowników systemów
Spójrz na budowê sieci i pracê z komputerem z zupe³nie nowej perspektywy
Spis tre
Ĉci
O autorze ....................................................................................... 11
Przedmowa ..................................................................................... 13
Wst
öp ............................................................................................ 17
Cz
öĈè I
đródäo ...........................................................................21
Rozdzia
ä 1. Säyszö, jak piszesz .......................................................................... 23
Potrzeba losowo
Ğci ......................................................................................................... 24
Automatyczne generowanie liczb losowych ............................................................ 26
Bezpiecze
Ĕstwo generatorów liczb losowych ................................................................ 27
Entropia wej
Ğcia-wyjĞcia: mówi Twoja mysz ................................................................ 28
Praktyczny przyk
áad przekazywania przerwaĔ ........................................................ 28
Jednokierunkowe funkcje skrótu .............................................................................. 31
Pedanteria pop
áaca ................................................................................................... 32
Entropii nie wolno marnowa
ü ........................................................................................ 33
Przykre skutki nag
áej zmiany paradygmatu .................................................................... 34
Wzorce czasowe wprowadzania danych .................................................................. 35
Taktyki obronne ....................................................................................................... 38
A mo
Īe generatory sprzĊtowe? ................................................................................ 38
Do przemy
Ğlenia ............................................................................................................. 40
Zdalne ataki czasowe ............................................................................................... 40
Wykorzystanie informacji diagnostycznych ............................................................ 40
Odtwarzalna nieprzewidywalno
Ğü ............................................................................ 41
Rozdzia
ä 2. Wysiäek zawsze siö opäaca .............................................................. 43
Dziedzictwo Boole’a ...................................................................................................... 43
W poszukiwaniu operatora uniwersalnego ..................................................................... 44
Prawo de Morgana w praktyce ................................................................................. 45
Wygoda jest konieczno
Ğcią ...................................................................................... 46
Ograniczanie z
áoĪonoĞci .......................................................................................... 47
Bli
Īej Ğwiata materialnego ............................................................................................. 47
Nieelektryczny komputer ............................................................................................... 48
Minimalnie bardziej popularny projekt komputera ........................................................ 49
Bramki logiczne ....................................................................................................... 49
Od operatorów logicznych do oblicze
Ĕ .......................................................................... 51
6
Cisza w sieci
Od elektronicznego minutnika do komputera ................................................................. 53
Turing i z
áoĪonoĞü zbioru instrukcji ............................................................................... 55
Nareszcie co
Ğ dziaáa ................................................................................................. 57
ĝwiĊty Graal: programowalny komputer ................................................................. 57
Post
Ċp przez uproszczenie ........................................................................................ 58
Podzia
á zadania ........................................................................................................ 59
Etapy wykonania ...................................................................................................... 60
Pami
Ċü mniejsza ....................................................................................................... 61
Wi
Ċcej naraz: potokowanie ...................................................................................... 62
Najwi
Ċksza wada potoków ....................................................................................... 63
Niebezpieczne drobne ró
Īnice ........................................................................................ 64
Rekonstrukcja danych na podstawie wzorców czasowych ....................................... 65
Bit do bitu... ............................................................................................................. 65
Praktyka ......................................................................................................................... 67
Optymalizacja z wczesnym wyj
Ğciem ...................................................................... 67
Dzia
áający kod — zrób to sam ................................................................................. 68
Zapobieganie .................................................................................................................. 71
Do przemy
Ğlenia ............................................................................................................. 72
Rozdzia
ä 3. Dziesiöè gäów Hydry ........................................................................ 73
Emisja ujawniaj
ąca: TEMPEST w telewizorze .............................................................. 73
Prywatno
Ğü z ograniczoną odpowiedzialnoĞcią .............................................................. 75
Okre
Ğlenie Ĩródáa: to on to napisaá! .......................................................................... 76
Ujawnienia typu „ojej”: *_~q'@@... a has
áo brzmi... .............................................. 77
Rozdzia
ä 4. Dla wspólnego dobra ....................................................................... 79
Cz
öĈè II
Bezpieczna przysta
þ ......................................................85
Rozdzia
ä 5. Mrugenlampy .................................................................................. 87
Sztuka przesy
áania danych ............................................................................................. 87
Od e-maila do g
áoĞnych trzasków i z powrotem ...................................................... 90
Obecna sytuacja ....................................................................................................... 95
Modem to czasem tylko modem .............................................................................. 95
Kolizje pod kontrol
ą ................................................................................................. 96
Za kulisami: pl
ątanina kabli i jak sobie z nią poradziliĞmy ...................................... 99
Mrugenlampy w komunikacji ................................................................................ 100
Konsekwencje
áadnego wyglądu .................................................................................. 101
Budujemy aparat szpiegowski... ................................................................................... 102
...i pod
áączamy go do komputera .................................................................................. 104
Jak zapobiega
ü ujawnianiu danych przez mrugenlampy i dlaczego siĊ to nie uda ....... 107
Do przemy
Ğlenia ........................................................................................................... 110
Rozdzia
ä 6. Echa przeszäoĈci ........................................................................... 111
Budowa wie
Īy Babel .................................................................................................... 111
Model OSI .............................................................................................................. 112
Brakuj
ące zdanie .......................................................................................................... 114
Do przemy
Ğlenia ........................................................................................................... 116
Rozdzia
ä 7. Bezpieczeþstwo w sieciach przeäñczanych ..................................... 117
Odrobina teorii ............................................................................................................. 118
Translacja i prze
áączanie adresów .......................................................................... 118
Sieci wirtualne i zarz
ądzanie ruchem ..................................................................... 119
Spis tre
Ĉci
7
Atak na architektur
Ċ ..................................................................................................... 122
Bufory CAM i przechwytywanie danych ............................................................... 122
Inne mo
ĪliwoĞci ataku: DTP, STP, trunking .......................................................... 122
Zapobieganie atakom ................................................................................................... 123
Do przemy
Ğlenia ........................................................................................................... 124
Rozdzia
ä 8. My kontra oni ............................................................................... 125
Logiczne mrugenlampy i ich nietypowe zastosowanie ................................................. 126
Poka
Ī mi, jak piszesz, a powiem ci, kim jesteĞ ...................................................... 127
Bitowe niespodzianki: prywatne dane dla ka
Īdego ...................................................... 128
Podatno
Ğci sieci bezprzewodowych ............................................................................. 129
Cz
öĈè III DĔungla ......................................................................133
Rozdzia
ä 9. Obcy akcent ................................................................................. 135
J
Ċzyk Internetu ............................................................................................................. 136
Naiwne trasowanie ................................................................................................. 137
Trasowanie w
Ğwiecie rzeczywistym ..................................................................... 137
Przestrze
Ĕ adresowa ............................................................................................... 138
Odciski palców na kopercie ................................................................................... 140
Protokó
á IP ................................................................................................................... 140
Wersja protoko
áu .................................................................................................... 140
Pole d
áugoĞci nagáówka .......................................................................................... 141
Pole typu us
áugi (osiem bitów) ............................................................................... 142
àączna dáugoĞü pakietu (16 bitów) ........................................................................ 142
Adres nadawcy ....................................................................................................... 142
Adres odbiorcy ....................................................................................................... 143
Identyfikator protoko
áu warstwy czwartej .............................................................. 143
Czas
Īycia pakietu (TTL) ....................................................................................... 143
Znaczniki i parametry przesuni
Ċcia ........................................................................ 143
Identyfikator ........................................................................................................... 145
Suma kontrolna ...................................................................................................... 146
Poza protokó
á IP ........................................................................................................... 146
Protokó
á UDP ............................................................................................................... 147
Wprowadzenie do adresowania portów .................................................................. 148
Podsumowanie opisu nag
áówka UDP .................................................................... 148
Pakiety protoko
áu TCP ................................................................................................. 149
Znaczniki steruj
ące: negocjowanie poáączenia TCP .............................................. 150
Inne parametry nag
áówka TCP ............................................................................... 153
Opcje TCP .............................................................................................................. 154
Pakiety protoko
áu ICMP ............................................................................................... 156
Pasywna identyfikacja systemów ................................................................................. 158
Pocz
ątki analizy pakietów IP ................................................................................. 158
Pocz
ątkowy czas Īycia (warstwa IP) ...................................................................... 159
Znacznik braku fragmentacji (warstwa IP) ............................................................ 159
Identyfikator IP (warstwa IP) ................................................................................. 160
Typ us
áugi (warstwa IP) ......................................................................................... 160
Nieu
Īywane pola niezerowe i pola obowiązkowo zerowe (warstwy IP i TCP) ..... 161
Port
Ĩródáowy (warstwa TCP) ................................................................................ 161
Rozmiar okna (warstwa TCP) ................................................................................ 162
Warto
Ğci wskaĨnika pilnych danych i numeru potwierdzającego (warstwa TCP) . 163
Kolejno
Ğü i ustawienia opcji (warstwa TCP) ......................................................... 163
Skala okna (opcja warstwy TCP) ........................................................................... 163
Maksymalny rozmiar segmentu (opcja warstwy TCP) ........................................... 163
8
Cisza w sieci
Datownik (opcja warstwy TCP) ............................................................................. 164
Inne mo
ĪliwoĞci pasywnej identyfikacji systemów ............................................... 164
Pasywna identyfikacja w praktyce ............................................................................... 165
Zastosowania pasywnej identyfikacji ........................................................................... 167
Zbieranie danych statystycznych i rejestrowanie incydentów ................................ 167
Optymalizacja tre
Ğci ............................................................................................... 168
Wymuszanie polityki dost
Ċpu ................................................................................ 168
Namiastka bezpiecze
Ĕstwa ..................................................................................... 168
Testowanie bezpiecze
Ĕstwa i analiza poprzedzająca atak ...................................... 168
Profilowanie klientów i naruszenia prywatno
Ğci .................................................... 169
Szpiegostwo i potajemne rozpoznanie ................................................................... 169
Zapobieganie identyfikacji ........................................................................................... 169
Do przemy
Ğlenia: fatalny báąd w implementacji protokoáu IP ...................................... 170
Rozbicie TCP na fragmenty ................................................................................... 172
Rozdzia
ä 10. Zaawansowane techniki liczenia baranów ..................................... 175
Wady i zalety tradycyjnej identyfikacji pasywnej ........................................................ 175
Krótka historia numerów sekwencyjnych .................................................................... 177
Jak wyci
ągaü informacje z numerów sekwencyjnych .................................................. 179
Wspó
árzĊdne opóĨnione, czyli jak narysowaü czas ...................................................... 180
àadne obrazki: galeria stosów TCP/IP ......................................................................... 182
Atraktory atakuj
ą .......................................................................................................... 190
Powrót do identyfikacji systemów ............................................................................... 193
ISNProber — teoria w praktyce ............................................................................. 193
Zapobieganie analizie pasywnej ................................................................................... 194
Do przemy
Ğlenia ........................................................................................................... 195
Rozdzia
ä 11. Rozpoznawanie anomalii ............................................................... 197
Podstawy firewalli sieciowych ..................................................................................... 198
Filtrowanie bezstanowe a fragmentacja ................................................................. 198
Filtrowanie bezstanowe a pakiety niezsynchronizowane ....................................... 200
Stanowe filtry pakietów ......................................................................................... 201
Przepisywanie pakietów i translacja adresów sieciowych ...................................... 202
Niedok
áadnoĞci translacji ....................................................................................... 203
Konsekwencje maskarady ............................................................................................ 204
Segmentowa ruletka ..................................................................................................... 205
ĝledzenie stanowe i niespodziewane odpowiedzi ......................................................... 207
Niezawodno
Ğü czy wydajnoĞü — spór o bit DF ........................................................... 208
Niepowodzenia wykrywania MTU trasy ................................................................ 208
Walka z wykrywaniem PMTU i jej nast
Ċpstwa ..................................................... 210
Do przemy
Ğlenia ........................................................................................................... 210
Rozdzia
ä 12. Wycieki danych ze stosu ............................................................... 213
Serwer Kristjana ........................................................................................................... 213
Zaskakuj
ące odkrycia ................................................................................................... 214
Ol
Ğnienie: odtworzenie zjawiska .................................................................................. 215
Do przemy
Ğlenia ........................................................................................................... 216
Rozdzia
ä 13. Dym i lustra .................................................................................. 217
Nadu
Īywanie protokoáu IP: zaawansowane techniki skanowania portów .................... 218
Drzewo w lesie — jak si
Ċ ukryü ............................................................................. 218
Bezczynne skanowanie .......................................................................................... 219
Obrona przez bezczynnym skanowaniem ..................................................................... 221
Do przemy
Ğlenia ........................................................................................................... 221
Spis tre
Ĉci
9
Rozdzia
ä 14. Identyfikacja klientów — dokumenty do kontroli! ........................... 223
Kamufla
Ī ...................................................................................................................... 224
Bli
Īej problemu ...................................................................................................... 224
Ku rozwi
ązaniu ...................................................................................................... 225
(Bardzo) krótka historia WWW ................................................................................... 226
Elementarz protoko
áu HTTP ........................................................................................ 227
Ulepszanie HTTP ......................................................................................................... 229
Redukcja opó
ĨnieĔ: paskudna prowizorka ............................................................. 229
Pami
Ċü podrĊczna .................................................................................................. 231
Zarz
ądzanie sesjami uĪytkownika: pliki cookie ..................................................... 233
Efekty
áączenia pamiĊci podrĊcznej i plików cookie .............................................. 234
Zapobieganie atakowi z wykorzystaniem pami
Ċci podrĊcznej ............................... 235
Odkrywanie podst
Ċpów ................................................................................................ 236
Trywialny przyk
áad analizy behawioralnej ............................................................ 237
Co znacz
ą te rysunki? ............................................................................................. 239
Nie tylko przegl
ądarki... ......................................................................................... 240
...i nie tylko identyfikacja ....................................................................................... 241
Zapobieganie ................................................................................................................ 242
Do przemy
Ğlenia ........................................................................................................... 242
Rozdzia
ä 15. Zalety bycia ofiarñ ........................................................................ 243
Odkrywanie cech charakterystycznych napastnika ...................................................... 244
Samoobrona przez obserwacj
Ċ obserwacji ................................................................... 247
Do przemy
Ğlenia ........................................................................................................... 248
Cz
öĈè IV Szersza perspektywa ...................................................249
Rozdzia
ä 16. Informatyka pasoĔytnicza, czyli grosz do grosza ............................. 251
Nadgryzanie mocy obliczeniowej ................................................................................ 252
Wzgl
Ċdy praktyczne ..................................................................................................... 255
Pocz
ątki pasoĪytniczego skáadowania danych ............................................................. 256
Rzeczywiste mo
ĪliwoĞci pasoĪytniczego skáadowania danych .................................... 258
Zastosowania, wzgl
Ċdy spoáeczne i obrona .................................................................. 263
Do przemy
Ğlenia ........................................................................................................... 264
Rozdzia
ä 17. Topologia Sieci ............................................................................. 267
Uchwyci
ü chwilĊ .......................................................................................................... 267
Wykorzystanie danych topologicznych do identyfikacji
Ĩródáa ................................... 270
Triangulacja sieciowa z wykorzystaniem siatkowych map sieci .................................. 272
Analiza obci
ąĪenia sieci ............................................................................................... 274
Do przemy
Ğlenia ........................................................................................................... 275
Rozdzia
ä 18. Obserwujñc pustkö ....................................................................... 277
Metody bezpo
Ğredniej obserwacji ................................................................................ 277
Analiza skutków ubocznych ataku ............................................................................... 281
Wykrywanie zniekszta
áconych lub báĊdnie adresowanych pakietów ........................... 283
Do przemy
Ğlenia ........................................................................................................... 284
Dodatki .......................................................................................285
Pos
äowie ...................................................................................... 287
Bibliografia ................................................................................... 289
Skorowidz ..................................................................................... 295
Rozdzia
ä 11.
Rozpoznawanie anomalii
Czyli czego mo
Īna siĊ dowiedzieü z drobnych
niedoskona
áoĞci w pakietach sieciowych.
W poprzednich rozdzia
áach omówiáem szereg sposobów pobierania
cz
ąstek potencjalnie uĪytecznych informacji z pozornie pozbawionych
znaczenia parametrów technicznych towarzysz
ących kaĪdemu pakietowi
danych przesy
áanemu przez sieü przez podejrzanego. Mam nadziejĊ, Īe
uda
áo mi siĊ pokazaü sposoby pozyskiwania znacznych iloĞci danych,
których udost
Ċpniania nadawca nie jest Ğwiadom (a w najlepszym razie
jest bardzo niezadowolony z powodu braku mo
ĪliwoĞci ich nieudo-
st
Ċpniania). W idealnym Ğwiecie rozliczne metody analizy pakietów
i strumieni danych pozwoli
áyby nam zmierzyü wiele spoĞród parame-
trów zdalnego systemu i przypisa
ü zaobserwowane zachowanie do sy-
gnatury konkretnego systemu operacyjnego i konfiguracji sieci.
Rzeczywisto
Ğü wygląda jednak nieco inaczej, gdyĪ wartoĞci niektórych spoĞród ob-
serwowanych parametrów zawsze przynajmniej troch
Ċ odbiegają od zakresu oczekiwa-
nego 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Īyt-
kownikó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.
W tym rozdziale 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.
198
Cz
öĈè III
i DĔungla
Wi
ĊkszoĞü spoĞród przedstawionych dalej i dających siĊ odtworzyü modyfikacji pa-
kietó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 te-
mató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 przy-
padku 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 [1] s
ą — najproĞciej rzecz ujmując — pewnego rodzaju routerami,
specjalnie zaprojektowanymi tak, by narusza
ü podstawową zasadĊ projektową route-
ró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 fire-
walle s
ą powszechnie stosowanym i dobrze rozumianym rozwiązaniem zabezpieczającym,
znajduj
ącym miejsce zarówno w sieciach domowych, jak i w wielkich korporacjach. Od-
powiednia konfiguracja firewalli pozwala odrzuca
ü, dopuszczaü lub przekierowywaü
okre
Ğlone rodzaje pakietów adresowanych do konkretnych usáug, toteĪ są one stoso-
wane 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 zabez-
pieczenie na wypadek wyst
ąpienia na chronionym serwerze problemu konfiguracyj-
nego 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 spraw-
dzaniu 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 in-
formacji. 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
Rozdzia
ä 11.
i Rozpoznawanie anomalii
199
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 por-
tach. 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 praw-
dopodobne, jednak w rzeczywisto
Ğci okazaáo siĊ to zadaniem doĞü prostym dziĊki pomo-
cy 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 znacz-
nik 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 docelo-
wym, 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 na-
g
áówka TCP okreĞlające port docelowy. Przygotowany fragment zaczyna siĊ od nie-
zerowego 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 pa-
kietu 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 ata-
kiem, 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.
200
Cz
öĈè III
i DĔungla
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 ktokol-
wiek) nawi
ązaá poáączenie, w ramach którego są wymieniane pakiety ACK. W prakty-
ce oznacza to,
Īe raczej ciĊĪko jest zdefiniowaü sensowne reguáy postĊpowania fire-
walla 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ą
1
.
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 Ma-
imona [3] w magazynie Phrack), jak równie
Ī NUL i Xmas (metody skanowania wy-
korzystuj
ące odpowiednio pakiety bez Īadnych znaczników i ze wszystkimi znacznika-
mi) 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 in-
formacje o wewn
Ċtrznej strukturze sieci (na przykáad o systemie operacyjnym i aktyw-
nych us
áugach), uáatwiające przeprowadzenie znacznie skuteczniejszego, wydajniej-
szego 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
1
Niektóre aspekty tego zachowania (czyli tendencji do odsy
áania RST w odpowiedzi na pakiety
kierowane do zamkni
Ċtych portów, a ignorowania identycznych pakietów adresowanych do portów,
na których system nas
áuchuje) wynikają z zaleceĔ RFC793, a inne są po prostu nastĊpstwem decyzji
podj
Ċtych przez twórców danego systemu.
Rozdzia
ä 11.
i Rozpoznawanie anomalii
201
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 klien-
tów a
Ī do upáyniĊcia czasu oczekiwania na faászywe poáączenia.
Mechanizm podpisów SYN dostarcza rozwi
ązanie tego problemu, polegające na ode-
s
á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 odpo-
wied
Ĩ 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 wery-
fikacji 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 powo-
duj
ący dodanie do tablicy stanów TCP odbiorcy nowego poáączenia, choü — jak pa-
mi
Ċtamy — Īądanie SYN i odpowiedĨ SYN+ACK nigdy nie zostaáy wysáane. Bez-
stanowy 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 fire-
wall nie móg
á sprawdziü jego portu ani odrzuciü niebezpiecznego pakietu, a mimo to
po
áączenie zostaje nagle nawiązane.
A to ju
Ī naprawdĊ niedobrze.
Stanowe filtry pakietów
Rozwi
ązanie problemów filtrów bezstanowych wymaga skáadowania przez firewall
niektórych informacji dotycz
ących dotychczasowego ruchu sieciowego oraz stanu
bie
Īących strumieni danych. Tylko w ten sposób moĪna niezauwaĪalnie dla uĪytkow-
nika przewidywa
ü wyniki skáadania fragmentów czy teĪ ustalaü kontekst pakietów
przesy
áanych w ramach poáączenia w celu okreĞlenia, czy naleĪy je odrzuciü jako nie-
dopuszczalne, czy te
Ī przepuĞciü do oczekującego na nie odbiorcy.
Rozwój tanich i wydajnych technik komputerowych pozwoli
á tworzyü znacznie bar-
dziej z
áoĪone i zaawansowane firewalle niĪ dotychczas. Oznacza to przejĞcie do sta-
nowego
Ğledzenia pakietów, czyli sytuacji, w której firewall nie tylko bada pojedyn-
cze pakiety, ale równie
Ī pamiĊta kontekst kaĪdego pakietu w ramach poáączenia
i sprawdza poprawno
Ğü pakietu w tym kontekĞcie. DziĊki temu firewall moĪe szczel-
nie chroni
ü sieü i odrzucaü niepoĪądane lub niespodziewane pakiety bez koniecznoĞci
polegania na umiej
ĊtnoĞci odróĪniania danych poĪądanych od niepoĪądanych przez
odbiorc
Ċ. Stanowe filtry pakietów starają siĊ Ğledziü poszczególne poáączenia i dopuszczaü
do odbiorcy tylko te dane, które faktycznie nale
Īą do aktywnych sesji, dziĊki czemu
zapewniaj
ą one znacznie lepszą ochronĊ i wiĊksze moĪliwoĞci rejestrowania ruchu
sieciowego.
202
Cz
öĈè III
i DĔungla
Filtrowanie stanowe jest oczywi
Ğcie zadaniem znacznie trudniejszym od filtrowania
bezstanowego, wymaga wi
Ċc znacznie wiĊkszych zasobów, zwáaszcza gdy firewall
chroni du
Īą sieü. Ochrona wiĊkszej iloĞci systemów wymaga, by firewall dysponowaá
du
Īą iloĞcią pamiĊci i szybkim procesorem, co pozwoli mu na bieĪąco zapisywaü
i sprawdza
ü informacje dotyczące ruchu na kablu.
Stanowa analiza pakietów wi
ąĪe siĊ teĪ z wiĊkszym prawdopodobieĔstwem wystĊ-
powania problemów i nieporozumie
Ĕ. Káopoty pojawiają siĊ w sytuacji, gdy firewall
i komunikuj
ące siĊ systemy róĪnie rozumieją bieĪący stan sesji TCP/IP, co niestety jest
jak najbardziej mo
Īliwe, biorąc pod uwagĊ niejednoznacznoĞü specyfikacji i róĪnorodnoĞü
implementacji stosu TCP/IP. Gdyby na przyk
áad firewall stosujący nieco luĨniejsze
zasady inspekcji numerów sekwencyjnych od ko
Ĕcowego odbiorcy otrzymaá pakiet
RST niemieszcz
ący siĊ w dopuszczalnym zakresie tych numerów, mógáby stwierdziü,
Īe sesja zostaáa zamkniĊta, podczas gdy odbiorca mógáby traktowaü sesjĊ jako wciąĪ
otwart
ą i oczekiwaü na dalsze dane w ramach tego poáączenia — oczywiĞcie podobny
problem pojawia si
Ċ w sytuacji odwrotnej. Tak czy inaczej, stanowa inspekcja pakietów
ma swoj
ą cenĊ.
Przepisywanie pakietów
i translacja adresów sieciowych
Zwi
Ċkszenie skutecznoĞci interpretacji pakietów oraz ochrony przed atakami omijają-
cymi regu
áy filtrujące (na przykáad z wykorzystaniem mechanizmu fragmentacji) wy-
maga
áo wyposaĪenia firewalli nie tylko w moĪliwoĞü przesyáania pakietów, ale równieĪ
modyfikacji niektórych przesy
áanych danych. Jedno z rozwiązaĔ polega na przykáad
na eliminowaniu wieloznaczno
Ğci poprzez obowiązkowe skáadanie wszystkich frag-
mentów ka
Īdego pakietu przed dokonaniem analizy pakietu zgodnie z reguáami zde-
finiowanymi przez administratora.
W miar
Ċ rozwoju coraz to bardziej zaawansowanych rozwiązaĔ staáo siĊ oczywiste,
Īe przepisywanie pakietów nie tylko jest korzystne dla sieci, ale moĪe wrĊcz stanowiü
prze
áom w kwestii bezpieczeĔstwa i moĪliwoĞci sieci, pozwalając na wprowadzanie
tak u
Īytecznych rozwiązaĔ, jak na przykáad translacja adresów sieciowych (NAT, od
ang. network address translation). Technika ta polega na odwzorowaniu okre
Ğlonych
adresów IP na inne adresy przed ich wys
áaniem i zastosowaniu operacji odwrotnej
w przypadku pakietów odsy
áanych przez chroniony system. Stanowa translacja po-
zwala mi
Ċdzy innymi implementowaü odporne na awarie infrastruktury sieciowe,
w których jeden publiczny adres IP jest w rzeczywisto
Ğci obsáugiwany przez kilka
serwerów wewn
Ċtrznych. NAT moĪe teĪ posáuĪyü do wprowadzenia w sieci we-
wn
Ċtrznej puli prywatnych (publicznie niedostĊpnych) adresów IP, pozwalając jedno-
cze
Ğnie wszystkim systemom sieci korzystaü z Internetu poprzez jeden adres publiczny
— mamy wtedy do czynienia z maskarad
ą.
W pierwszym przypadku NAT przepisuje adresy docelowe w przychodz
ących pakie-
tach na adresy pewnej ilo
Ğci róĪnych systemów po wewnĊtrznej stronie firewalla. Po-
zwala to stworzy
ü odporną na awarie infrastrukturĊ, w ramach której Īądania wy-
Ğwietlenia popularnej witryny internetowej (na przykáad http://www.microsoft.com)
Rozdzia
ä 11.
i Rozpoznawanie anomalii
203
lub udost
Ċpnienia innej popularnej usáugi są rozkáadane na wiele systemów — jeĞli
jeden zawiedzie, inne b
Ċdą mogáy przejąü jego funkcjĊ. MoĪna to osiągnąü stosując
specjalne urz
ądzenia wyrównujące obciąĪenie, ale podobne moĪliwoĞci oferuje wiele
firewalli z obs
áugą NAT.
Drugie zastosowanie, zwane popularnie maskarad
ą, polega na przepisywaniu adresów
Ĩródáowych wychodzących pakietów w taki sposób, by systemy w chronionej sieci
wewn
Ċtrznej (potencjalnie korzystające z prywatnych adresów, które nie zostaáyby
skierowane do tej sieci z Internetu) mog
áy áączyü siĊ ze Ğwiatem zewnĊtrznym dziĊki
przechwytywaniu i przepisywaniu ich po
áączeĔ wychodzących przez firewall. Systemy
sieci wewn
Ċtrznej są dla Ğwiata niewidoczne, a wszystkie ich poáączenia wychodzące
wydaj
ą siĊ odbiorcom pochodziü od firewalla. KaĪde poáączenie jest przypisywane do
konkretnego, publicznego adresu IP i okre
Ğlonego portu, po czym jest wysyáane w Ğwiat.
Pakiety powracaj
ące do tego adresu są nastĊpnie przepisywane z powrotem, by wska-
zywa
áy na system, który faktycznie nawiązaá dane poáączenie, a na koniec przesyáane
do sieci wewn
Ċtrznej. DziĊki takiemu rozwiązaniu caáa prywatna sieü stacji robo-
czych, które w za
áoĪeniu nie mają udostĊpniaü Īadnych usáug, nie jest bezpoĞrednio
dost
Ċpna z zewnątrz, co znacznie zwiĊksza jej bezpieczeĔstwo i ukrywa niektóre in-
formacje o jej strukturze, a w dodatku pozwala zaoszcz
Ċdziü na kosztownych, pu-
blicznych adresach IP dla poszczególnych stacji roboczych. Wprowadzenie maskara-
dy pozwala organizacji posiadaj
ącej tylko jeden adres publiczny stworzyü sieü
wewn
Ċtrzną liczącą setki czy wrĊcz tysiące komputerów i zapewniü kaĪdemu z nich
dost
Ċp do Internetu.
Niedok
äadnoĈci translacji
Równie
Ī translacja adresów jest zadaniem znacznie trudniejszym, niĪ mogáoby siĊ wy-
dawa
ü — dziaáanie niektórych protokoáów wyĪszego poziomu jest znacznie bardziej
skomplikowane od prostego pod
áączenia siĊ do zdalnego systemu i przesáania mu ze-
stawu polece
Ĕ. Na przykáad pradawny, lecz wciąĪ szeroko rozpowszechniony proto-
kó
á przesyáania plików FTP [4] (File Transfer Protocol) w swym najprostszym
i najpopularniejszym trybie dzia
áania wymaga nawiązania zwrotnego poáączenia od
serwera do klienta w celu przesy
áania Īądanych plików, a początkowe poáączenie na-
wi
ązane przez klienta jest uĪywane jedynie do wydawania poleceĔ. Wiele innych
protoko
áów (w szczególnoĞci obsáugujących rozmowy, poáączenia peer-to-peer, me-
chanizmy wspó
áuĪytkowania danych, transmisje multimedialne i tym podobne) ko-
rzysta z w
áasnych, niekiedy doĞü dziwnych rozwiązaĔ, wymagających poáączeĔ zwrot-
nych, przeskakiwania portów czy te
Ī dopuszczania niesesyjnej transmisji okreĞlonych
danych (na przyk
áad pakietów protokoáu UDP) z powrotem do klienta.
Z tego te
Ī wzglĊdu kaĪda implementacja maskarady, która ma poprawnie obsáugiwaü
takie protoko
áy, musi posiadaü odpowiednią liczbĊ protokoáów-pomocników. Zada-
niem tych pomocników jest analiza danych aplikacji wymienianych w ramach po
áą-
czenia, a w razie potrzeby przepisywanie pakietów i otwieranie tymczasowych szczelin
w firewallu w celu wpuszczenia po
áączeĔ zwrotnych.
I tu w
áaĞnie tkwi kolejny problem, po raz pierwszy zauwaĪony kilka lat temu w pomocniku
FTP przez Mikaela Olssona [5], a pó
Ĩniej badany równieĪ dla innych pomocników,
mi
Ċdzy innymi przez autora tej ksiąĪki [6]. Problem polega na tym, Īe pomocnicy
204
Cz
öĈè III
i DĔungla
podejmuj
ą decyzje o otwarciu szczeliny w firewallu na podstawie informacji przesy-
áanych od stacji roboczej do serwera zgodnie z okreĞlonym protokoáem. Automatycz-
nie zak
áadają teĪ, Īe dane wysyáane przez system są transmitowane w imieniu uĪyt-
kownika i za jego wiedz
ą. Nie muszĊ chyba mówiü, Īe niektóre programy — na
przyk
áad przeglądarki internetowe — moĪna podstĊpem zmusiü do wysyáania okre-
Ğlonych rodzajów danych, w tym nawet informacji „wyglądających” na protokóá nie-
obs
áugiwany przez program, a odpowiednie spreparowanie takich danych i przesáanie
ich aplikacji pozwala osi
ągnąü ten cel automatycznie. Sfaászowane dane mogą posáu-
Īyü do nakáonienia pomocnika, by na moment otworzyá firewall.
Klasycznym przyk
áadem takiego ataku jest wykorzystanie mechanizmu dziaáania prze-
gl
ądarki internetowej. Podając odniesienie do strony internetowej (lub elementu takiej
strony) rzekomo dost
Ċpnej na niestandardowym porcie HTTP na komputerze atakującego
(b
Ċdącym jednoczeĞnie jak najbardziej standardowym portem FTP), moĪna zmusiü
klienta do po
áączenia siĊ z tym zasobem i wysáania odpowiedniego Īądania HTTP.
Po
áączenie jest nawiązywane na porcie uĪywanym na ogóá przez FTP, wiĊc pomocnik FTP
firewalla zaczyna
Ğledziü tĊ transmisjĊ, oczekując na okazjĊ do udzielenia pomocy.
Przetworzenie poni
Īszego przykáadowego adresu URL sprawiáoby, Īe klient HTTP spró-
bowa
áby siĊ poáączyü z portem FTP i wysáaü coĞ, co wygląda na polecenie FTP
PORT
,
przechwycone nast
Ċpnie przez pomocnika firewalla:
HTTP://SERVER:21/FOO<RETURN>PORT MY_IP,122,105<RETURN>
Wys
áane przez klienta Īądanie byáoby dla prawdziwej usáugi FTP kompletnym beá-
kotem, a jej odpowied
Ĩ byáaby niezrozumiaáa dla przeglądarki zgáaszającej Īądanie —
ale nie o to tu chodzi. Najwa
Īniejsze, Īe napastnik ma kontrolĊ nad czĊĞcią takiego
Īądania, a mianowicie nazwą pliku, którego klient zaĪąda z serwera. Ową fikcyjną
nazw
Ċ wybiera agresor i moĪe ona zawieraü dowolne dane. Poáączenia nasáuchuje
pomocnik firewalla dla protoko
áu FTP, oczekujący konkretnego polecenia tekstowego
(
PORT
). Umieszczaj
ąc w nazwie pliku ciągi znaków wáaĞciwe Īądaniom FTP, napast-
nik mo
Īe przekonaü pomocnika, Īe uĪytkownik usiáuje w rzeczywistoĞci pobraü kon-
kretny plik z serwera. W ten oto sposób zdalny serwer uzyskuje tymczasowo mo
Īli-
wo
Ğü poáączenia siĊ z komputerem klienta (w tym przypadku na wysoce podejrzanym
porcie 31337 — 122*256+105 = 31337), a wi
Ċc atakujący zostaje wpuszczony do
systemu bez wiedzy ofiary. Ups — tego te
Ī siĊ nie spodziewaliĞmy.
Konsekwencje maskarady
Wszystkie wspomniane scenariusze ataku wi
ąĪą siĊ z wykorzystywaniem sáaboĞci
maskarady, ale ju
Ī sama jej obecnoĞü moĪe stanowiü Ĩródáo ciekawych informacji
o zdalnym systemie.
Jak ju
Ī wiemy, maskarada jest mechanizmem inwazyjnym, gdyĪ istotą jej dziaáania
jest modyfikacja wychodz
ącego ruchu sieciowego poprzez przepisywanie wybranych
cz
ĊĞci pakietów. Proces ten wykracza poza samą podmianĊ adresu i pozwala uwaĪ-
nemu obserwatorowi nie tylko wykry
ü obecnoĞü maskarady, ale równieĪ zidentyfi-
kowa
ü konkretny firewall. Pakiety pochodzące z maskarady mogą wykazywaü nastĊ-
puj
ące wáasnoĞci:
Rozdzia
ä 11.
i Rozpoznawanie anomalii
205
Czas
Īycia pakietów docierających do odbiorcy bĊdzie siĊ róĪniá od oczekiwanej
lub zmierzonej odleg
áoĞci od sieci docelowej. Pakiety pochodzące zza maskarady
b
Ċdą zawsze co najmniej o jeden przeskok „starsze” od pakietów pochodzących
z systemu bezpo
Ğrednio wykorzystującego adres IP chronionej sieci.
W wi
ĊkszoĞci przypadków w sieci Ĩródáowej wystĊpują róĪne systemy
operacyjne, ró
Īne konfiguracje takich samych systemów lub przynajmniej
ró
Īne czasy aktywnoĞci poszczególnych instalacji. KaĪdy taki system
charakteryzuje si
Ċ nieco innymi parametrami TCP/IP, omówionymi
szczegó
áowo w rozdziaáach 9. i 10. Analizując róĪne portrety TCP/IP
dla po
áączeĔ z pozoru pochodzących z tego samego adresu IP, moĪemy
z du
Īą dozą pewnoĞci rozpoznaü obecnoĞü mechanizmu translacji adresów
w konkretnym systemie, kryj
ącym za sobą sieü wewnĊtrzną.
Zewn
Ċtrzny obserwator prawdopodobnie zwróci uwagĊ na przesuniĊcie
portów
Ĩródáowych — nietypowe zjawisko spowodowane faktem, Īe poáączenia
wychodz
ące z sieci korzystają z portów efemerycznych, znajdujących siĊ
poza normalnym zakresem danego systemu operacyjnego.
Ka
Īdy system operacyjny rezerwuje okreĞlony zakres portów Ĩródáowych
w celu identyfikacji po
áączeĔ wychodzących. Firewall czĊsto odwzorowuje
maskaradowane po
áączenia, korzystając z innego zakresu portów, wáaĞciwego
jego systemowi operacyjnemu. Je
Ğli wiĊc zakres obserwowanych numerów
portów ró
Īni siĊ od zakresu wáaĞciwego wykrytemu systemowi (na przykáad
je
Ğli Linux, na ogóá korzystający z portów od 1024 do 4999, nagle wydaje siĊ
u
Īywaü znacznie wyĪszych numerów portów), moĪna wnioskowaü, Īe pakiety są
poddawane translacji adresów, a niekiedy nawet ustali
ü konkretny model firewalla.
Techniki te s
ą czĊsto stosowane i stanowią podstawĊ wykrywania maskarad oraz roz-
poznawania chronionych przez nie sieci, ale istnieje te
Ī kilka innych sposobów stwier-
dzenia obecno
Ğci przepisywania pakietów.
Segmentowa ruletka
Jednym z mniej oczywistych — a tym samym mniej popularnych — sposobów wy-
krywania obecno
Ğci przepisywania pakietów i pozyskiwania dodatkowych informacji
o konfiguracji sieci jest analiza warto
Ğci pola maksymalnego rozmiaru segmentu w otrzy-
mywanych pakietach.
Fragmentacja pakietów IP wi
ąĪe siĊ z doĞü znacznym kosztem przetwarzania po-
fragmentowanych danych, st
ąd teĪ jest czĊsto uwaĪana za zjawisko niepoĪądane
z punktu widzenia wydajno
Ğci i wielu implementatorów stara siĊ jej zapobiegaü. Jak
ju
Ī jednak wiemy, wyeliminowane fragmentacji jest zadaniem bardzo trudnym, gdyĪ
jak dot
ąd nie istnieje Īaden sposób dokáadnego, szybkiego i niezawodnego okreĞlania
maksymalnej jednostki danych (MTU) dla ustalonej trasy jeszcze przed nawi
ązaniem
po
áączenia. Nawet najlepsza z dostĊpnych metod, czyli wykrywanie MTU trasy (PMTU),
jest daleka od doskona
áoĞci, a jej wáączenie i tak powoduje spadek wydajnoĞci — sto-
sowane tu wykrywanie odpowiedniego MTU metod
ą prób i báĊdów oznacza, Īe nie-
które zbyt du
Īe pakiety trzeba odrzuciü i wysáaü ponownie.
206
Cz
öĈè III
i DĔungla
Aby zapobiec spadkowi wydajno
Ğci i niezawodnoĞci wynikającemu z wáączenia wy-
krywania PMTU oraz zmniejszy
ü narzut związany z fragmentacją, wiele firewalli sto-
suj
ących translacjĊ adresów i przepisywanie niektórych parametrów pakietów wy-
chodz
ących modyfikuje równieĪ wartoĞü pola maksymalnego rozmiaru segmentu
(MSS) w nag
áówkach TCP poáączeĔ wychodzących z sieci prywatnej, co ma na celu
dostosowanie tej warto
Ğci do MTU áącza zewnĊtrznego sieci. Nowa wartoĞü jest naj-
cz
ĊĞciej mniejsza od MTU sieci lokalnej, dziĊki czemu nadawca nie bĊdzie wysyáaá
danych, które nie zmie
Ğciáyby siĊ w áączu zewnĊtrznym. W przypadku ustawienia MTU
odpowiadaj
ącego najmniejszej wartoĞci na caáej trasie zmniejsza to ryzyko fragmen-
tacji. (Podej
Ğcie to zakáada, Īe niezgodnoĞci MTU najczĊĞciej wystĊpują w pobliĪu
systemu nadawcy lub odbiorcy, w obr
Ċbie tzw. ostatniej mili, gdzie czĊsto wystĊpują
ró
Īne áącza o niskim MTU, na przykáad áącza DSL lub bezprzewodowe, z powodu
których wi
Ċksze pakiety musiaáyby byü poddawane fragmentacji).
Sam
ą zmianĊ ustawienia MSS nieáatwo wykryü — prawdĊ mówiąc, nie istnieje Īaden
sposób stwierdzenia, czy warto
Ğü MSS ustawiá nadawca, czy teĪ zostaáa ona zmodyfi-
kowana gdzie
Ğ po drodze. Jest jednak pewien drobny kruczek. Jak juĪ wspominaáem
w rozdziale 9., algorytmy wyboru rozmiaru okna wielu wspó
áczesnych systemów mają
pewn
ą ciekawą cechĊ:
Parametr rozmiaru okna okre
Ğla iloĞü danych, jaka moĪe byü wysáana bez
konieczno
Ğci potwierdzenia. Konkretna wartoĞü tego parametru jest czĊsto
wybierana zgodnie z osobistymi wierzeniami voodoo programisty lub innymi
jego przekonaniami religijnymi. Dwie najpopularniejsze zasady g
áoszą,
Īe rozmiar okna powinien byü albo wielokrotnoĞcią MTU bez nagáówków
(maksymalnego rozmiaru segmentu, w skrócie MSS), albo po prostu warto
Ğcią
dostatecznie du
Īą i „okrągáą”. Starsze wersje Linuksa (2.0) uĪywaáy wartoĞci
b
Ċdących potĊgami dwójki (na przykáad 16 384). Linux 2.2 przerzuciá siĊ
na wielokrotno
Ğci MSS (z jakiegoĞ powodu 11 lub 22 razy MSS), a nowsze
wersje tego systemu cz
Ċsto uĪywają wartoĞci od 2 do 4 razy MSS. Sieciowa
konsola Sega Dreamcast u
Īywa wartoĞci 4096, a systemy Windows czĊsto
korzystaj
ą z 64 512.
Rosn
ąca liczba wspóáczesnych systemów (w tym nowsze wersje Linuksa i Solarisa,
niektóre wersje Windows i SCO UnixWare) korzystaj
ą z rozmiaru okna bĊdącego
wielokrotno
Ğcią MSS. DziĊki temu moĪna áatwo stwierdziü, czy ustawienie MSS pa-
kietu zosta
áo zmienione gdzieĞ po drodze, gdyĪ rozmiar okna takiego pakietu nie bĊdzie
ju
Ī konkretną wielokrotnoĞcią MSS, a najprawdopodobniej w ogóle nie bĊdzie siĊ dzieliá
przez MSS.
Porównuj
ąc MSS z rozmiarem okna, moĪna skutecznie wykrywaü obecnoĞü firewalli
stosuj
ących wyrównywanie wartoĞci MSS (czyli dostosowywanie jej do moĪliwoĞci
áącza) w wielu róĪnych systemach. Wyrównywanie MSS jest wprawdzie zachowaniem
opcjonalnym dla Linuksa i FreeBSD, ale w wielu firewallach domowych i inteligentnych
routerach DSL odbywa si
Ċ ono automatycznie. ObecnoĞü niespodziewanej wartoĞci
MSS sygnalizuje wi
Ċc obecnoĞü systemu nie tylko przepisującego pakiety, ale rów-
nie
Ī zdolnego do translacji adresów, co z kolei moĪe posáuĪyü za wskazówkĊ odno-
Ğnie poáączenia sieciowego nadawcy.
Rozdzia
ä 11.
i Rozpoznawanie anomalii
207
ćledzenie stanowe
i niespodziewane odpowiedzi
Inn
ą istotną konsekwencją stanowego Ğledzenia poáączeĔ i przepisywania pakietów
jest fakt,
Īe niektóre odpowiedzi wymagane przez specyfikacjĊ pochodzą od fire-
walla, a nie od nadawcy, co pozwala napastnikowi ca
ákiem skutecznie zidentyfikowaü
ów firewall. Gdy po
áączenie jest usuwane z tablicy stanów NAT (czy to z powodu
przekroczenia czasu po
áączenia, czy teĪ wysáania przez jedną ze stron pakietu RST,
który nie dotar
á do odbiorcy), dalszy ruch sieciowy w ramach koĔczonej sesji nie jest
ju
Ī przekazywany odbiorcy, lecz jest obsáugiwany bezpoĞrednio przez firewall.
Zgodnie ze specyfikacj
ą TCP/IP odbiorca powinien odpowiadaü na wszelkie niespo-
dziewane pakiety ACK odpowiedzi
ą RST, co ma na celu poinformowanie nadawcy,
Īe sesja, którą usiáuje kontynuowaü, nie jest juĪ obsáugiwana przez odbiorcĊ (lub nigdy
nie by
áa). Niektóre firewalle naruszają zalecenia specyfikacji i w ogóle nie odpowia-
daj
ą na takie pakiety, po prostu ignorując wszelkie pakiety, które nie wydają siĊ nale-
Īeü do Īadnej trwającej sesji. (Nie zawsze jest to postĊpowanie rozsądne, gdyĪ moĪe
prowadzi
ü do zbĊdnych opóĨnieĔ w przypadku zaniechania poprawnego poáączenia
z powodu problemów transmisyjnych).
Wiele firewalli odpowiada jednak poprawnym i spodziewanym pakietem RST, co
otwiera kolejn
ą drogĊ ich wykrywania i identyfikacji. Pakiet ten jest tworzony od zera
przez firewall, wi
Ċc jego parametry dostarczają informacji o samym firewallu, a nie
o chronionym systemie. Pozwala to wykorzysta
ü opisane w rozdziale 9. tradycyjne
techniki identyfikacji (badanie znaczników DF, warto
Ğci TTL, rozmiaru okna, doboru,
warto
Ğci i kolejnoĞci opcji itd.) do uzyskania informacji o firewallu.
Istnieje te
Ī inna moĪliwoĞü, wynikająca z nastĊpującego zapisu w dokumencie
RFC1122 [7]:
4.2.2.12 Pakiet RST: RFC-793 sekcja 3.4
Protokó
á TCP POWINIEN dopuszczaü obecnoĞü danych w otrzymanym
pakiecie RST.
OMÓWIENIE: Istniej
ą propozycje umieszczania w pakiecie RST tekstu ASCII
koduj
ącego i táumaczącego przyczynĊ wysáania RST. Nie ustalono jak dotąd
standardu dla takich informacji.
I rzeczywi
Ğcie — pomimo braku standardu niektóre systemy doáączają do pakietów
RST wysy
áanych w odpowiedzi na zbáąkane ACK opisowe (choü nierzadko tajemnicze)
komunikaty w nadziei,
Īe informacja o przyczynie báĊdu uspokoi nadawcĊ. Odpowiedzi
te cz
Ċsto zawierają wewnĊtrzne sáowa kluczowe lub przejawy czegoĞ, co wygląda na
dziwn
ą odmianĊ komputerowego humoru i są niekiedy specyficzne dla konkretnego
systemu operacyjnego, na przyk
áad
no tcp, reset
;
tcp_close, during connect
(Mac OS);
tcp_fin_wait_2_timeout
;
No TCP
(HP/UX);
new data when detached
;
tcp_lift_anchor,
can't wait
(SunOS).
208
Cz
öĈè III
i DĔungla
Je
Ğli w reakcji na problemy sieciowe lub niespodziewany pakiet przesáany do zdalnego
systemu zobaczymy pakiet RST z takim opisem problemu, a wiemy z innych
Ĩródeá,
Īe system docelowy nie uĪywa opisowych komunikatów RST, to mamy kolejną wska-
zówk
Ċ. MoĪemy na jej podstawie wydedukowaü, Īe miĊdzy nami a odbiorcą znajduje
si
Ċ inny system — prawdopodobnie stanowy firewall — i zidentyfikowaü jego system
operacyjny, porównuj
ąc treĞü komunikatu ze znanymi odpowiedziami róĪnych systemów.
Obie techniki identyfikacji okazuj
ą siĊ byü bardzo skuteczne w wykrywaniu obecno-
Ğci stanowych filtrów pakietów, jeĞli tylko moĪliwa jest obserwacja ruchu sieciowego
podczas krótkotrwa
áych problemów sieciowych. Metody te mogą równieĪ posáuĪyü
do aktywnej identyfikacji bez konieczno
Ğci namierzania samego firewalla — wystar-
czy wys
áaü do ofiary zbáąkany pakiet ACK, co pozwoli odróĪniü filtry stanowe od
bezstanowych. Na podstawie otrzymanej odpowiedzi atakuj
ący moĪe dobraü najlep-
szy sposób poradzenia sobie z firewallem (lub wykorzysta
ü tĊ wiedzĊ w inny sposób).
Niezawodno
Ĉè czy wydajnoĈè
— spór o bit DF
Wykrywanie MTU trasy (PMTU) jest kolejnym kierunkiem identyfikacji, blisko spo-
krewnionym z omówion
ą juĪ w rozdziale 9. kwestią unikania fragmentacji pakietów IP.
Nowsze wersje j
ądra Linuksa (2.2, 2.4, 2.6) i systemów Windows (2000 i XP) domyĞlnie
implementuj
ą i wáączają wykrywanie PMTU. JeĞli to ustawienie nie zostanie zmie-
nione, wszystkich pakiety pochodz
ące z takich systemów mają ustawiony bit DF, za-
pobiegaj
ący fragmentacji. Algorytm wykrywania PMTU moĪe jednak powodowaü pro-
blemy w rzadkich, ale mimo to mo
Īliwych sytuacjach.
Niepowodzenia wykrywania MTU trasy
Problem wykrywania PMTU polega na tym,
Īe jego skutecznoĞü jest caákowicie uza-
le
Īniona od zdolnoĞci nadawcy do odebrania komunikatu ICMP „fragmentation
required but DF set” i ustalenia optymalnych ustawie
Ĕ dla danego poáączenia. Pakiet,
który spowodowa
á wysáanie komunikatu, zostanie odrzucony przed dotarciem do celu,
wi
Ċc musi byü wysáany ponownie po odpowiednim zmniejszeniu jego rozmiaru.
Je
Ğli nadawca nie otrzyma tego komunikatu, to nie moĪe wiedzieü, Īe pakiet nie dotará
do celu. Powoduje to w najlepszym razie opó
Ĩnienie transmisji, a w najgorszym razie
zablokowanie po
áączenia na czas bliĪej nieokreĞlony, gdyĪ retransmitowane pakiety
równie
Ī raczej siĊ nie bĊdą mieĞciü w áączu, dla którego maksymalny dopuszczalny
rozmiar pakietu jest za ma
áy dla wysyáanych danych.
Rzecz w tym,
Īe wcale nie ma gwarancji, Īe nadawca otrzyma komunikat ICMP gene-
rowany w reakcji na pakiet niemieszcz
ący siĊ w áączu. W niektórych sieciach wszystkie
Rozdzia
ä 11.
i Rozpoznawanie anomalii
209
komunikaty ICMP s
ą po prostu ignorowane w Ĩle pojĊtym interesie bezpieczeĔstwa.
Czyli nawet gdy router wy
Ğle odpowiedni komunikat, to i tak wcale nie musi on do-
trze
ü do celu.
Sk
ąd pomysá odrzucania komunikatów ICMP? Po prostu w przeszáoĞci zdarzaáo siĊ,
Īe niektóre takie komunikaty stanowiáy zagroĪenie dla bezpieczeĔstwa. Zbyt duĪe lub
pofragmentowane pakiety ICMP powodowa
áy w wielu systemach báąd pamiĊci jądra
(tak zwany „ping of death”), natomiast wysy
áanie komunikatów ICMP na adresy roz-
g
áoszeniowe sáuĪyáo do wywoáania burzy odpowiedzi na podstawiony adres IP (atak
„Smurf”) i do wykonywania ataków DoS. Co wi
Ċcej, báĊdnie skonfigurowane systemy
cz
Ċsto interpretowaáy ogáoszenia routerów
2
— specjalny rodzaj komunikatów rozg
áo-
szeniowych — jako polecenia modyfikacji ustawie
Ĕ sieciowych. Systemy takie ak-
ceptowa
áy ogáoszenia bez sprawdzania ich wiarygodnoĞci, co stwarzaáo jeszcze jeden
ciekawy kierunek ataku. I tak w
áaĞnie doszáo do tego, Īe wielu obawia siĊ ICMP
i odrzuca jego pakiety.
W co bardziej naiwnych poradnikach bezpiecze
þstwa moĔna niekiedy znaleĒè za-
lecenie odrzucania wszystkich pakietów ICMP, i niektórzy administratorzy tak w
äa-
Ĉnie czyniñ. Widziaäem nawet takñ rekomendacjö w profesjonalnym raporcie z testów
penetracyjnych, sporz
ñdzonym rökñ znanego audytora (którego nazwiska niestety
nie mog
ö tu wymieniè).
Inn
ą kwestią potencjalnie zmniejszającą niezawodnoĞü wykrywania PMTU jest fakt,
Īe niektóre komunikaty o báĊdach pochodzą z urządzeĔ korzystających z prywatnych
adresów IP. Zdarza si
Ċ, Īe w celu zaoszczĊdzenia ograniczonej (i na ogóá kosztownej)
przestrzeni adresów publicznych interfejsy fizycznie
áączące router z firewallem zdal-
nej sieci otrzymuj
ą adresy z lokalnej puli prywatnej zamiast z puli publicznych adre-
sów kierowanych do tej sieci ze
Ğwiata zewnĊtrznego.
Wykorzystanie adresów prywatnych mo
Īe niestety caákowicie uniemoĪliwiü wykry-
wanie PMTU. Dlaczego? Dlatego
Īe jeĞli firewall odbiorcy otrzyma z zewnątrz pakiet
o rozmiarach uniemo
Īliwiających jego przekazanie do celu, to wyĞle do nadawcy komu-
nikat o b
áĊdzie ze swojego wáasnego adresu, naleĪącego do puli adresów prywatnych.
Firewall nadawcy oryginalnego pakietu mo
Īe taki pakiet odrzuciü, gdyĪ pozornie po-
chodzi on z zewn
ątrz, ale ma adres Ĩródáowy z puli prywatnej (potencjalnie nawet ta-
kiej samej, jak pula adresów w sieci prywatnej nadawcy). Firewall odrzuci taki pakiet,
gdy
Ī wygląda on na typową próbĊ podszycia siĊ pod zaufany system lokalny. W tym
jednak przypadku decyzja firewalla spowoduje sparali
Īowanie stosowanego od doĞü
niedawna mechanizmu wykrywania PMTU i pozostawi nadawc
Ċ w báogiej nieĞwia-
domo
Ğci faktu, Īe wysáany przez niego pakiet nie dotará do celu.
Co gorsza, nawet je
Ğli Īaden ze wspomnianych problemów nie wystąpi i pakiet po-
prawnie dotrze do celu, to wiele wspó
áczesnych urządzeĔ sieciowych ogranicza tem-
po wysy
áania odpowiedzi ICMP i nie dopuszcza do przekroczenia okreĞlonej liczby
2
Og
áoszenia routerów miaáy na celu umoĪliwienie automatycznej konfiguracji komputerów w sieci,
bez konieczno
Ğci rĊcznego wprowadzania ustawieĔ. Router rozgáaszaá co jakiĞ czas (lub na Īądanie)
komunikat oznaczaj
ący „jestem tutaj, skorzystaj ze mnie”. Niektóre systemy domyĞlnie przyjmowaáy
niezamawiane og
áoszenia routerów bez wiĊkszego zastanowienia, co oczywiĞcie byáo záym pomysáem.
210
Cz
öĈè III
i DĔungla
pakietów w ustalonym czasie. Równie
Ī ten zabieg stanowi dodatkowe zabezpiecze-
nie. Komunikaty ICMP mia
áy pierwotnie przeznaczenie czysto informacyjne i przed
wprowadzeniem algorytmów wykrywania PMTU nie by
áy istotne dla procesu komu-
nikacji, wi
Ċc ograniczenie tempa ich wysyáania wydawaáo siĊ dobrym sposobem obrony
przed niektórymi atakami blokowania us
áugi czy zapychania áącza.
Walka z wykrywaniem PMTU i jej nast
öpstwa
W
Ğwietle powyĪszego wiele osób uwaĪa wykrywanie PMTU na kiepski pomysá.
Technika ta daje wprawdzie pewien przyrost wydajno
Ğci, ale kosztem rzadkich, lecz
d
áugotrwaáych i czĊsto trudnych w wykryciu problemów, powodujących niemoĪnoĞü
po
áączenia siĊ w pewnymi serwerami lub nagáe zawieszanie poáączeĔ. Opracowano
wprawdzie wiele ró
Īniących siĊ skutecznoĞcią algorytmów wykrywania „czarnych
dziur”, czyli obszarów sieci, dla których nale
Īy wyáączyü wykrywanie PMTU, jednak
ich stosowanie nie rozwi
ązuje podstawowego problemu, a moĪe powodowaü dodat-
kowe opó
Ĩnienia transmisji — najczĊĞciej wtedy, gdy są one najmniej poĪądane.
Aby sprosta
ü tym trudnoĞciom i zmniejszyü iloĞü zaĪaleĔ, niektórzy producenci ko-
mercyjnych firewalli korzystaj
ą w konfiguracji swych produktów z pewnej chytrej
sztuczki: usuwaj
ą znacznik DF ze wszystkich pakietów wychodzących. Jest to drobna
i nierzadko skuteczna modyfikacja, dostarczaj
ąca jednak kolejnego sposobu wykrycia
obecno
Ğci systemu filtrującego i przepisującego pakiety. JeĞli obserwowany adres lub
sie
ü wykazuje cechy charakterystyczne dla systemów z wykrywaniem PMTU, ale
w otrzymywanych pakietach brakuje spodziewanego znacznika DF, uwa
Īny obser-
wator mo
Īe wykryü obecnoĞü firewalla i okreĞliü jego typ, tym samym zyskując ko-
lejn
ą cząstkĊ informacji bez koniecznoĞci bezpoĞredniej interakcji z ofiarą.
Do przemy
Ĉlenia
Tak ko
Ĕczy siĊ moja krótka opowieĞü o tym, jak to próby ulepszenia firewalli i zwiĊk-
szenia ich mo
ĪliwoĞci w celu utrudnienia ataku i bezpoĞredniego rozpoznania miaáy
te
Ī skutek uboczny w postaci uáatwienia ich pasywnej identyfikacji. W tym miejscu
pozwol
Ċ sobie jeszcze na maáą dygresjĊ.
Z jednym z najdziwniejszych i najciekawszych zjawisk sieciowych mia
áem do czy-
nienia w 1999 r. Nie jest ono wprawdzie bezpo
Ğrednio związane z dziaáaniem fire-
walli, ale mimo to stanowi ciekawy materia
á do przemyĞlenia dla kaĪdego, kto intere-
suje si
Ċ zagadnieniami pasywnej identyfikacji systemów poĞrednich.
Jacek P. Szyma
Ĕski, z którym przez krótki czas wspóápracowaáem, a póĨniej miaáem
przyjemno
Ğü omawiaü nietypowe i podejrzane wzorce ruchu sieciowego
3
, zauwa
Īyá
nag
áy wzrost liczby powaĪnie uszkodzonych pakietów TCP/IP przychodzących na
3
Wspó
ápraca ta zaowocowaáa w pewnym momencie powstaniem luĨnej grupy polskich badaczy,
która w latach 1999 – 2000 zajmowa
áa siĊ korelacją, Ğledzeniem i próbami wyjaĞnienia wielu
dziwnych prawid
áowoĞci w ruchu sieciowym.