plik

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63

e-mail: helion@helion.pl

PRZYK£ADOWY ROZDZIA£

IDZ DO

ZAMÓW DRUKOWANY KATALOG

KATALOG KSI¥¯EK

TWÓJ KOSZYK

CENNIK I INFORMACJE

ZAMÓW INFORMACJE

O NOWOŒCIACH

ZAMÓW INFORMACJE

O NOWOŒCIACH

ZAMÓW CENNIK

CZYTELNIA

FRAGMENTY KSI¥¯EK ONLINE

SPIS TREŒCI

DODAJ DO KOSZYKA

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

öĈè 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

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

Ċ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

öĈè 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

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

öĈè III DĔungla ......................................................................133

Rozdzia

ä 9. Obcy akcent ................................................................................. 135

Ċ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

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

Ğ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

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

öĈè 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

ą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-

Ċ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

öĈè III

i DĔungla

Ċ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ü

áą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

Ī 25. Nawiązanie poáączenia nie jest moĪliwe bez tego początkowego pakietu SYN,

Ċ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

Ċ 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

Ī 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-

áó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

ö on jednak nieco mniej bezstanowy i nieco bardziej zauwaĔalny.

200

öĈè 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

á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 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

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-

á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-

Ċ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

áą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

öĈè 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á

Īą 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-

Ċ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-

ą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,

Ċdzy innymi przez autora tej ksiąĪki [6]. Problem polega na tym, Īe pomocnicy

204

öĈè 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-

ądarki internetowej. Podając odniesienie do strony internetowej (lub elementu takiej

strony) rzekomo dost

Ċpnej na niestandardowym porcie HTTP na komputerze atakującego

Ċ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.

áą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-

Ğü 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

ĊĞ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

Ċ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.

Ī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

Ğli Linux, na ogóá korzystający z portów od 1024 do 4999, nagle wydaje siĊ

Ī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

Ī 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

áą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

öĈè 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-

ĊĞ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

Ċ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

Ī 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

Ī 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

öĈè III

i DĔungla

Ğ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

Ċ 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-

Ī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,

Ċc musi byü wysáany ponownie po odpowiednim zmniejszeniu jego rozmiaru.

Ğ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.

ą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-

á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

Ċsto interpretowaáy ogáoszenia routerów

— 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

á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.

Czytaj dalej...

210

öĈè 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

Ğ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

áugotrwaáych i czĊsto trudnych w wykryciu problemów, powodujących niemoĪnoĞü

áą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

Ī 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

, zauwa

Īyá

nag

áy wzrost liczby powaĪnie uszkodzonych pakietów TCP/IP przychodzących na

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.