PRACA 2 id 382388 Nieznany

Istotne zagadnienia bezpiecze´nstwa sieci komputerowej

Marcin Zi˛eba

20 czerwca 2002

Spis tre´sci

Wprowadzenie

1.1

Zagro˙zenia

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Podstawowy opis protokołu TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Protokół IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1

Protokół ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2

Protokół UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.3

Protokół TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Systemy Intrusion Detection System

2.1

Ogólna charakterystyka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Konfiguracja programu Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2

Rodzaje preprocesorów, konfiguracja . . . . . . . . . . . . . . . . . . . . . . .

2.2.3

Konfiguracja wtyczek, słu˙z ˛

acych do prezentacji wyj´scia z preprocesorów oraz

logowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.4

Tworzenie i modyfikacja reguł . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.5

Uruchamianie oraz przykładowe logi ataków . . . . . . . . . . . . . . . . . . .

Sniffery - u˙zywanie i wykrywanie

3.1

Zasada działania, metody wykrywania . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1

Zasada działania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2

Znajdowanie uruchomionego sniffera bezpo´srednio w systemie

. . . . . . . . .

3.1.3

Znajdowanie uruchomionego sniffera na podstawie analizy sieci . . . . . . . . .

3.1.4

Podsłuch w sieci przeł ˛

aczanej . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

Zagro˙zenia zwi ˛

azane z podszywaniem si˛e pod zaufane komputery . . . . . . . . . . . .

3.3

Sposoby obrony przed podszywaniem si˛e oraz podsłuchiwaniem . . . . . . . . . . . . .

3.3.1

Sieci VLAN

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.2

Szyfrowanie transmisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4

Sniffing w sieci przeł ˛

aczanej - ettercap . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1

Opis i mo˙zliwo´sci programu . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.2

Dost˛epne wtyczki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.3

Tryby działania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.4

Tryby podsłuchiwania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.5

Opcje programu, przykładowe u˙zycie . . . . . . . . . . . . . . . . . . . . . . .

3.5

Wykorzystanie w celu analizy stanu sieci . . . . . . . . . . . . . . . . . . . . . . . . . .

SPIS TRE ´

SCI

Firewalle, ich rodzaje i zastosowanie

4.1

Opis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2

Techniki skanowania sieci

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1

Znajdowanie aktywnych, u˙zywanych numerów IP

. . . . . . . . . . . . . . . .

4.2.2

Wykorzystanie protokołu TCP . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3

Rodzaje i ró˙znice pomi˛edzy ró˙znymi rodzajami firewalli. . . . . . . . . . . . . . . . . .

4.4

Przykłady u˙zycia filtru iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.1

Konfiguracja, kompilacja i instalacja j ˛

adra systemu Linux

. . . . . . . . . . . .

4.4.2

Konfiguracja wsparcia Netfilter w j ˛

adrze systemu Linux . . . . . . . . . . . . .

4.4.3

Sposób u˙zycia iptables, składnia . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.4

Prosty zestaw reguł . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.5

Omówienie ró˙znych celów tablicy „filter” . . . . . . . . . . . . . . . . . . . . .

4.4.6

Przykład konfiguracji SNAT 1:1 . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.7

Prosty DNAT dla serwera WWW

. . . . . . . . . . . . . . . . . . . . . . . . .

4.4.8

Konfiguracja prze´zroczystego proxy . . . . . . . . . . . . . . . . . . . . . . . .

4.4.9

Manipulacja polem TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.10 Próby skanowania

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5

Dodatkowe rozszerzenia IPTables

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.1

Patch-O-Matic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.2

Własne rozszerzenia IPTables . . . . . . . . . . . . . . . . . . . . . . . . . . .

Systemy zabezpiecze ´n systemu Linux

5.1

GRSecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.1

Opis zało˙ze´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.2

Sposób instalacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.3

Opis parametrów konfiguracji j ˛

adra i ich omówienie . . . . . . . . . . . . . . .

5.1.4

Podsumowanie mo˙zliwo´sci stoj ˛

acych przed GRSecurity . . . . . . . . . . . . .

Podsumowanie

Rozdział 1

Wprowadzenie

1.1

Zagro˙zenia

We współczesnych sieciach komputerowych mo˙zemy zaobserwowa´c dwa ´zródła włama´n do systemów
informatycznych. S ˛

a to włamania maj ˛

ace swoje ´zródło poza organizacj ˛

a, do której nale˙zy dany za-

sób/komputer/sie´c oraz pochodz ˛

ace z jej wn˛etrza. Naruszenia zasad bezpiecze´nstwa s ˛

a przy tym ´swia-

dome lub wynikaj ˛

ace z niewiedzy.

Najwi˛ekszy procent

stanowi ˛

a jednak włamania dokonane przez sfrustrowanych, roz˙zalonych, z ja-

kiego´s powodu niezadowolonych z pracy pracowników danej organizacjii[20, 21].

Tak wi˛ec nie tylko nale˙zy zwraca´c uwag˛e na zagro˙zenia z zewn ˛

atrz, ale przede wszystkim płyn ˛

ace

ze strony własnych pracowników, gdy˙z to oni maj ˛

a ułatwiony dost˛ep do danych, znaj ˛

a cz˛esto szczegóły,

których zna´c nie powinni, np. struktur˛e sieci, stosowane zabezpieczenia. Bardzo wa˙zn ˛

a rzecz ˛

a jest tak˙ze

zwracanie uwagi na to, co wyrzucamy. Bardzo cz˛esto w ´smieciach intruz mo˙ze znale´z´c interesuj ˛

ace

go informacje, ma do nich tak˙ze stosunkowo łatwy dost˛ep. Po ustaleniu w ten sposób np. personaliów
zatrudnionych osób, mo˙ze za pomoc ˛

a technik in˙zynierii społecznej wydoby´c potrzebne mu informa-

cje, które mog ˛

a posłu˙zy´c mu do dalszej penetracji systemu. Bardzo cz˛esto ten aspekt jest lekcewa˙zony

przy projektowaniu polityki bezpiecze´nstwa, lecz jest on bardzo wa˙zny. Tak˙ze fizyczne zabezpiecze-
nie urz ˛

adze´n mog ˛

acych słu˙zy´c do nieautoryzowanego dost˛epu przez osoby niepowołane, jest istotnym

problemem. Intruz mo˙ze próbowa´c wła´snie z nich uzyska´c dost˛ep do systemu. Dlatego bardzo wa˙zne
s ˛

a tradycyjne zabezpieczenia antywłamaniowe. ˙

Zadne zabezpieczenia przed dost˛epem do sieci przed-

si˛ebiorstwa nie spełni ˛

a swojej roli, je´sli intruz b˛edzie miał mo˙zliwo´s´c wdarcia si˛e do siedziby firmy i

fizycznego dost˛epu do urz ˛

adze´n.

Wyró˙zniamy ró˙zne rodzaje zagro˙ze´n, jakie mo˙zemy spotka´c w sieci komputerowej. S ˛

a to m.in. ataki

maj ˛

ace na celu zablokowanie działania jakiej´s usługi, lub całej sieci, pochodz ˛

ace z jednego komputera

lub wielu

, ataki maj ˛

ace na celu kradzie˙z informacji lub jej zniszczenie. W czasie normalnego działania,

ka˙zde urz ˛

adzenie posiadaj ˛

ace własny, widoczny z całej sieci numer IP, jest atakowane co najmniej kilka

razy dziennie. Jednak nie s ˛

a to jednak z reguły próby mog ˛

ace zagrozi´c naruszeniem bezpiecze´nstwa, pod

warunkiem, ˙ze dane urz ˛

adzenie/komputer jest systematycznie kontrolowane pod wzgl˛edem odporno´sci

Z danych zebranych z okazji pi˛etnastego corocznego „Computer Crime and Security Survey” przez „The Computer Se-

curity Institute” w współpracy z ”FBI’s Computer Intrusion Squad” wynika, ˙ze z przebadanych du˙zych korporacji lub agend
rz ˛

adowych 90% odnotowało naruszenia bezpiecze´nstwa w przeci ˛

agu ostatniego roku, 71% stanowił nieuprawniony dost˛ep z

wewn ˛

atrz, natomiast 25% włamania maj ˛

ace swoje ´zródło na zewn ˛

atrz organizacji. Straty finansowe poniosło z tego powodu

74% organizacji.

DoS - Denial of Service

DDoS - Distributed Denial of Service

ROZDZIAŁ 1. WPROWADZENIE

na ataki powszechnie znane. Próby te s ˛

a przeprowadzane głównie przez tzw. „script kiddie”, czyli osoby

posiadaj ˛

ace jaki´s zestaw publicznie znanych exploitów

i próbuj ˛

ace je u˙zy´c na pierwszym lepszym celu.

Znacznie gro´zniejsze mog ˛

a by´c próby maj ˛

ace na celu skompromitowanie wła´snie naszej sieci, gdy˙z z

reguły przeprowadzaj ˛

a je osoby dysponuj ˛

ace du˙z ˛

a wiedz ˛

a, i maj ˛

ace konkretny cel, aby to wła´snie do

naszej sieci uzyska´c dost˛ep. Nie zniech˛ec ˛

a si˛e, w przeciwie´nstwie do „script kiddie”

, po napotkaniu

pierwszych przeszkód. Wszelkie anomalie, jakie stwierdzamy w pracy sieci, mog ˛

a by´c wła´snie powo-

dowane przez próby sondowania naszej sieci przez intruza. Mówimy tu np. o pakietach posiadaj ˛

acych

dziwne kombinacje flag, adresy ´zródłowe lub docelowe, które nie powinny były nigdy znale´z´c si˛e w
naszej sieci. . . Im dziwniejsze i nietypowe zachowanie, tym bardziej prawdopodobne, ˙ze jest to rzecz, na
któr ˛

a powinni´smy zwróci´c szczególn ˛

a uwag˛e.

1.2

Cel pracy

Celem pracy jest przedstawienie wybranych, istotnych zagro˙ze´n zwi ˛

azanych z sieci ˛

a komputerow ˛

a, a

tak˙ze sposobów zabezpiecze´n oraz monitorowania dost˛epu do niej. Przedstawione zostan ˛

a tak˙ze spo-

soby zapobiegania eskalacji uprawnie´n intruza w systemie Linux oraz wybrane metody zapobiegania
atakom. Pokazane zostan ˛

a mo˙zliwo´sci konfiguracji firewalla dost˛epnego wraz z now ˛

a wersj ˛

a systemu

Linux 2.4 i przykłady zastosowania w celu lepszej ochrony komputerów pracuj ˛

acych w sieci wewn˛etrz-

nej przed zagro˙zeniami ze strony ogólno´swiatowej sieci Internet. Omówione b˛ed ˛

a zagadnienia zwi ˛

azane

z zagro˙zeniami wynikaj ˛

acymi z podsłuchiwania ruchu w sieci lokalnej, w szczególno´sci w sieci opartej

na przeł ˛

acznikach.

1.3

Podstawowy opis protokołu TCP/IP

Orientacja w tematach prezentowanych w nast˛epnych rozdziałach wymaga przynajmniej podstawowej
znajomo´sci działania protokołu TCP/IP, oraz budowy jego datagramów[2, 3].

1.4

Protokół IP

Protokół IP

jest protokołem warstwy trzeciej modelu sieci ISO/OSI, jest powszechnie u˙zywany w sie-

ciach rozległych i Internecie. Jego zadaniem jest implementacja dwóch podstawowych funkcji: adresacji
i fragmentacji. Pakiety IP przenosz ˛

a adresy ´zródłowy i docelowy w swoich nagłówkach. Pakiety mog ˛

by´c fragmentowane i defragmentowane w celu transmisji poprzez sieci, które obsługuj ˛

a mniejsze pa-

kiety. Ka˙zdy pakiet IP jest traktowany niezale˙znie od innych i zapewnienie pewno´sci transmisji oraz
powtórzenia zagubionych pakietów nale˙zy do protokołów warstw wy˙zszych. Nagłówek IP zawiera w
sobie m.in. pola:

• Type Of Service Pole 8 bitowe, okre´sla po˙z ˛

adan ˛

a jako´s´c, jak ˛

a nale˙zy zachowa´c przy dostarcza-

niu pakietu:

Jest to program, który przy wykorzystaniu istniej ˛

acej luki w zabezpieczeniach programu/systemu pozwala na uzyskanie

wi˛ekszych uprawnie´n lub atak DoS

S ˛

a to osoby u˙zywaj ˛

ace skryptów i exploitów napisanych przez innych, cz˛esto bez zrozumienia ich działania. Najcz˛e´sciej

u˙zywaj ˛

a narz˛edzi do automatycznego przeprowadzania ataków. S ˛

a to zwykle programy szeroko dost˛epne, tak wi˛ec znane te˙z

osobom odpowiedzialnym za bezpiecze´nstwo sieci, co powoduje, ˙ze ich wpływ na bezpiecze´nstwo jest zwykle minimalny.

Opisany w dokumencie RFC 791 - http://www.ietf.org/rfc/rfc0793.txt

ROZDZIAŁ 1. WPROWADZENIE

– Bity 0-2 Pierwsze´nstwo pakietów nad innymi, im warto´s´c jest wy˙zsza, tym jest ono wy˙z-

sze.

– Bit 3

∗ 0 Normalne opó´znienie
∗ 1 Małe opó´znienie

– Bit 4

∗ 0 Normalna przepustowo´s´c
∗ 1 Du˙za przepustowo´s´c

– Bit 5

∗ 0 Normalna niezawodno´s´c
∗ 1 Wysoka niezawodno´s´c

– Bity 6-7 Zarezerwowane do przyszłego wykorzystania.

• Time To Live Pole 8 bitowe. Czas ˙zycie pakietu, okre´sla liczb˛e w˛ezłów, po przej´sciu których

pakiet zostanie zniszczony

• Options Pole zmiennej długo´sci. Dodatkowe opcje pakietu, dokładniej opisane przy okazji oma-

wiania pisania reguł systemu IDS Snort.

• Rodzaj protokołu Pole 8 bitowe. Rodzaj protokołu warstwy wy˙zszej

• Flagi Pole 3 bitowe, okre´sla opcje zwi ˛

azane z fragmentacj ˛

a pakietów.

– Bit 0 Zarezerwowany, warto´s´c 0.

– Bit 1 (DF)

∗ 0 May Fragment, pakiet mo˙ze by´c fragmentowany
∗ 1 Don’t Fragment, pakiet nie mo˙ze by´c fragmentowany

– Bit 2 (MF)

∗ 0 Last Fragment, ostatni fragment datagramu
∗ 1 More Fragments, oznaczenie jednego z fragmentów.

Ustawienie „Don’t Fragment” spowoduje, ˙ze je˙zeli pakiet b˛edzie musiał by´c sfragmentowany, aby
doj´s´c do punktu docelowego, gdy˙z w sieci po´sredniej nie istnieje mo˙zliwo´s´c przesyłania pakietów
takiej wielko´sci, zostanie porzucony.

• Pole opcji Opcjonalne pole, szerzej omówione w rozdziale dotycz ˛

acym systemu IDS Snort.

• Suma kontrolna nagłówka Pole 16 bitowe, jest obliczane i sprawdzane w ka˙zdym w˛e´zle, przez

jaki przechodzi pakiet.

• Adres ´

zródłowy

Pole 32 bitowe.

• Adres docelowy Pole 32 bitowe.

ROZDZIAŁ 1. WPROWADZENIE

1.4.1

Protokół ICMP

Protokół ICMP

[10, 11, 4] korzysta z podstawowego wsparcia protokołu IP, tak jakby był normalnym

protokołem warstwy wy˙zszej, jednak musi by´c zaimplementowany przez ka˙zdy stos IP, gdy˙z jest inte-
graln ˛

a cz˛e´sci ˛

a protokołu IP. Komunikaty ICMP s ˛

a przesyłane przy wielu okazjach, np. je´sli datagram IP

nie mo˙ze osi ˛

agn ˛

a´c docelowego hosta lub sieci. Jako ˙ze protokół IP nie został zaprojektowany jako proto-

kół niezawodny, zadaniem komunikatów ICMP jest sygnalizacja problemów z dostarczaniem pakietów
IP do miejsca docelowego. ˙

Zadne komunikaty nie s ˛

a przesyłane, je˙zeli wyst ˛

api problem z przesłaniem

pakietu ICMP, tak˙ze ew. komunikat ICMP jest wysyłany tylko w przypadku pierwszego fragmentu pa-
kietu.

Rozró˙zniamy kilka ró˙znych rodzajów (typów) komunikatów ICMP:

• Typ 0 Echo Reply Message

– Kod 0 Odpowied´z na komunikat Echo, powinna zawiera´c te same dane, które zostały otrzy-

mane w komunikacie Echo

• Typ 1 Nieu˙zywane.

• Typ 2 Nieu˙zywane.

• Typ 3 Destination Ureachable Message

– Kod 0 Net Unreachable - komunikat wysyła w˛ezeł sieci, je˙zeli sie´c docelowa jest nieosi ˛

galna

– Kod 1 Host Unreachable - komunikat wysyła w˛ezeł sieci, w przypadku gdy host docelowy

jest nieosi ˛

agalny

– Kod 2 Protocol Unreachable - komunikat wysyła host, je˙zeli nie obsługuje danego protokołu

– Kod 3 Port Unreachable - komunikat wysyła host, je˙zeli na danym porcie nie jest dost˛epna

˙zadna usługa

– Kod 4 Fragmentation Needed - komunikat wysyła w˛ezeł sieci, je˙zeli ustawiony był bit Don’t

Fragment i istnieje konieczno´s´c fragmentacji

– Kod 5 Source Route Failed

- komunikat wysyła w˛ezeł sieci, który nie mo˙ze przesła´c pakietu

do nast˛epnego miejsca skoku.

– Kod 6 Destination Network Unknown - zgodnie z RFC 1812, komunikat ten nie powinien

by´c u˙zywany, zamiast niego nale˙zy u˙zywa´c komunikatu „Kod 0” czyli „Net Unreachable”.

– Kod 7 Destination Host Unknown - komunikat wysyłany tylko w przypadku, gdy w˛ezeł na

podstawie danych otrzymanych z warstwy ł ˛

acza, mo˙ze stwierdzi´c ˙ze pod danym adresem IP

nie ma ˙zadnego hosta.

– Kod 8 Source Host Isolated - komunikat wysyłany przez w˛ezeł sieci, je˙zeli został skonfigu-

rowany, aby nie przesyłał dalej pakietów z okre´slonym adresem ´zródłowym.

– Kod 9 Communication with Destination Network is Administratively Prohibited - genero-

wany przez w˛ezeł, je˙zeli został on skonfigurowany aby blokowa´c dost˛ep do tej sieci.

Internet Control Message Protocol - RFC 792 - http://www.ietf.org/rfc/rfc0792.txt

opcje Source Route omówione zostan ˛

a w rozdziale dotycz ˛

acym systemu IDS

ROZDZIAŁ 1. WPROWADZENIE

– Kod 10 Communication with Destination Host is Administratively Prohibited - generowany

przez w˛ezeł, je˙zeli został on skonfigurowany aby blokowa´c dost˛ep do okre´slonego hosta.

– Kod 11 Network Unreachable for Type Of Service - generowany przez w˛ezeł, je˙zeli nie

istnieje droga pozwalaj ˛

aca osi ˛

agn ˛

a´c sie´c docelow ˛

a dla pakietów posiadaj ˛

acych ustawione w

ten sposób pole Type Of Service.

– Kod 12 Host Unreachable for Type Of Service - generowany przez w˛ezeł, je˙zeli nie istnieje

droga pozwalaj ˛

aca osi ˛

agn ˛

a´c host docelowy pakietom posiadaj ˛

acym w ten sposób ustawione

pole Type Of Service.

– Kod 13 Communication Administratively Prohibited - komunikat taki jest generowany, gdy

w˛ezeł nie mo˙ze przekaza´c dalej pakietu ze wzgl˛edy na filtrowanie.

– Kod 14 Host Precedence Violation - komunikat wysyłany przez pierwszy w˛ezeł sieci, ozna-

cza, ˙ze ˙z ˛

adana warto´s´c pierwsze´nstwa pakietów nie jest dozwolona dla danej kombinacji

adresów/portów ´zródłowego/docelowego lub protokołu warstwy wy˙zszej.

– Kod 15 Precedence Cutoff in Effect - komunikat generowany, gdy został ustalony minimalny

poziom pierwsze´nstwa pakietów, a datagram został wysłany z poziomem ni˙zszym.

• Typ 4 Source Quench Message

– Kod 0 Komunikat sygnalizuje problemy z wydajno´sci ˛

a przetwarzania pakietów przez w˛ezeł

sieci lub host go wysyłaj ˛

acy, po otrzymaniu takiego komunikatu host powinien zmniejszy´c

ilo´s´c przesyłanych pakietów w jednostce czasu, do czasu a˙z przestanie dostawa´c komunikat
Source Quench.

• Typ 5 Redirect Message - zawiera adres bramki, do jakiej powinien zosta´c przesłany ruch prze-

znaczony dla okre´slonej sieci X. Sytuacja ta ma zwykle miejsce, gdy w sieci znajduj ˛

a si˛e dwie

bramki, A i B. Bramka A, po otrzymaniu pakietu i sprawdzeniu we własnej tabeli routingu, ˙ze
do docelowego adresu posiada routing przez bramk˛e B, wysyła do hosta inicjuj ˛

acego ruch, ˙ze

ruch przeznaczony do sieci X powinien by´c przesyłany przez bramk˛e B. Komunikat taki nie jest
wysyłany, je˙zeli pakiet posiada ustawione opcje Source Route.

– Kod 0 Przekierowanie pakietów dla sieci

– Kod 1 Przekierowanie pakietów dla hosta

– Kod 2 Przekierowanie pakietów dla sieci dla okre´slonego pola Type Of Service

– Kod 3 Przekierowanie pakietów dla hosta dla okre´slonego pola Type Of Service

• Typ 6 Alternate Host Address

– Kod 0 Adres alternatywny

• Typ 7 Nieu˙zywane.

• Typ 8 Echo Message

– Kod 0 Komunikat, na który host docelowy powinien odpowiedzie´c komunikatem Echo Reply

• Typ 9 Router Discovery Messages

Rozszerzenie opisane w RFC 1256 - http://www.ietf.org/rfc/rfc1256.txt

ROZDZIAŁ 1. WPROWADZENIE

– Kod 0 Komunikat rozsyła adresy routerów, szerzej opisany zostanie w rozdziale dotycz ˛

acym

snifferów.

• Typ 10 Router Solicitation Message (Router Selection)

– Kod 0 Komunikat wysyłany przy ˙z ˛

adaniu podania domy´slnego routera, wysyłany przez host.

• Typ 11 Time Exceeded Message

– Kod 0 Time To Live Exceeded In Transit - pakiet nie został dostarczony na skutek wyzero-

wania pola TTL przed dotarciem pakietu do miejsca przeznaczenia.

– Kod 1 Fragment Reassembly Time Exceeded - komunikat wysyła host docelowy, je˙zeli w

okre´slonym czasie nie otrzymał wszystkich fragmentów pakietu.

• Typ 12 Parameter Problem Message

– Kod 0 Komunikat wysyłany w przypadku napotkania bł˛edu w pakiecie, który spowodował

porzucenie pakietu

– Kod 1 Komunikat wysyłany w przypadku braku wymaganej opcji.

– Kod 2 Komunikat wysyłany w przypadku Złego rozmiaru pakietu.

• Typ 13 Timestamp Message

– Kod 0 Komunikat zawiera zapisan ˛

a na 32 bitach liczb˛e sekund od północy czasu UT

, okre-

´slaj ˛

ac ˛

a czas wysłania pakietu.

• Typ 14 Timestamp Reply Message

– Kod 0 Komunikat zawiera oprócz otrzymanego Originate Timestamp tak˙ze czas otrzyma-

nia komunikatu Receive Timestamp oraz czas wysłania odpowiedzi Transmit Timestamp

• Typ 15 Information Reqest Message

– Kod 0 Pole adresu ´zródłowego i docelowego mo˙ze by´c puste.

• Typ 16 Information Reply Message

– Kod 0 Odpowied´z zawiera wypełnione pola adresu ´zródłowego i docelowego. Obecnie pro-

tokoły RARP, BOOTP, DHCP stanowi ˛

a lepsze rozwi ˛

azanie przydziału adresu dla stacji ro-

boczych.

• Typ 17 Address Mask Request

– Kod 0 Komunikat mo˙ze by´c u˙zyty przez bezdyskow ˛

a stacj˛e robocz ˛

a, w celu uzyskania maski

sieci w czasie bootowania. Odpowied´z na taki komunikat pochodz ˛

acy z sieci zewn˛etrznej

mo˙ze ujawni´c intruzowi struktur˛e sieci, wskazuj ˛

ac jednocze´snie, jakie adresy IP posiadaj ˛

w˛ezły sieci.

• Typ 18 Address Mask Reply

Universal Time [+0000] (TZ, GMT)

Obecnie ignorowane przez wi˛ekszo´s´c stosów IP

ROZDZIAŁ 1. WPROWADZENIE

– Kod 0 Odpowied´z dla komunikatu „Address Mask Request”

• Typ 19 Zarezerwowane (dla celów bezpiecze´nstwa)

• Typ 20-29 Zarezerwowane.

• Typ 30 Traceroute

• Typ 31 Datagram Conversion Error

• Typ 32 Mobile Host Redirect

• Typ 33 IPv6 Where-Are-You

• Typ 34 IPv6 I-Am-Here

• Typ 35 Mobile Registration Request

• Typ 36 Mobile Registration Reply

• Typ 39 SKIP

• Typ 40 Photuris

– Kod 0 Zarezerwowany.

– Kod 1 Komunikat wysyłany, gdy nieznany jest indeks parametrów bezpiecze´nstwa.

– Kod 2 Poprawne parametry bezpiecze´nstwa, lecz wyst˛epuje bł ˛

ad uwierzytelnienia.

– Kod 3 Poprawne parametry bezpiecze´nstwa, lecz wyst˛epuj ˛

a problemy z odszyfrowaniem.

1.4.2

Protokół UDP

Protokół UDP jest prostym protokołem warstwy transportowej. Dokladnie opisuje go dokument RFC
768, dost˛epny pod adresem http://www.ietf.org/rfc/rfc0768.txt. Jest to protokół zawodny, tak
wi˛ec od konkretnej aplikacji zale˙zy jego niezawodno´s´c. Jest to protokół bezpoł ˛

aczeniowy. Od protokołu

IP odró˙znia go obecno´s´c dwóch 16 bitowych pól, okre´slaj ˛

acych port ´zródłowy i docelowy pakietu.

1.4.3

Protokół TCP

Protokół TCP[5, 3] jest protokołem poł ˛

aczeniowym, ze ´sci´sle okre´slonymi sposobami nawi ˛

azywania

takiego poł ˛

aczenia. Zapewnia tak˙ze niezawodno´s´c przesyłanych danych. Zawiera tak˙ze mechanizmy

sterowania przepływem informacji, za pomoc ˛

a „window” druga strona poł ˛

aczenia jest informowana, jak

du˙zo danych jest skłonna przyj ˛

a´c.

Przydatne dla nas do analizy pola protokołu TCP to:

• Sequence Number Pole 32 bitowe zawieraj ˛

ace numer sekwencyjny pakietu

• Acknowledgment Number Pole 32 bitowe, je˙zeli ustawiona jest flaga ACK, zawiera numer se-

kwencyjny, jaki nadawca spodziewa si˛e otrzyma´c.

RFC 1812 - http://www.ietf.org/rfc/rfc1812.txt - uznaje oba te komunikaty za przestarzałe i zaleca nieimplementowanie

ich w stosie IP hostów, oraz nieodpowiadanie przez w˛ezły sieci na nie. W˛ezły musz ˛

a mie´c zaimplementowan ˛

a obsług˛e tych

komunikatów

ROZDZIAŁ 1. WPROWADZENIE

Rysunek 1.1: Typowe trójfazowe nawi ˛

azanie poł ˛

aczenia TCP

• Flagi

– URG Pakiet zawiera wa˙zne, pilne dane do dostarczenia

– ACK Pakiet zawieraj ˛

acy wa˙zne pole potwierdzenia

– PSH Pakiet zawieraj ˛

acy tak ˛

a flag˛e powoduje przekazanie do aplikacji wszystkich danych do-

t ˛

ad otrzymanych i przechowywanych przez stos TCP/IP np. w buforze.

– RST Reset, przerywa poł ˛

aczenie.

– SYN Słu˙zy do nawi ˛

azania poł ˛

aczenia i zsynchronizowania numerów sekwencyjnych.

– FIN Wskazuje na koniec poł ˛

aczenia ze strony nadawcy.

Opcje protokołu TCP:

• MSS Maksymalny rozmiar segmentów danych, które mo˙ze przyj ˛

a´c dane poł ˛

aczenie.

• Window Scale Maksymalny rozmiar to 65535, ale przy wsparciu obu stron poł ˛

aczenia mo˙zliwe

jest rozszerzenie okna do wielko´sci prawie 1 GB przy pomocy tej opcji.

• Timestamp Przenosi znaczniki czasu

Opcje Timestamp oraz Window Scale zostały opisane w RFC 1323 - „TCP Extensions for High Performance” -

http://www.ietf.org/rfc/rfc1323.txt

Rozdział 2

Systemy Intrusion Detection System

2.1

Ogólna charakterystyka

Systemy IDS pozwalaj ˛

a wykry´c atak na monitorowan ˛

a przez system sie´c na podstawie ró˙znych kry-

teriów. Jednym z nich mo˙ze by´c np. analiza zawarto´sci pakietów przesyłanych do monitorowanych
systemów i porównywanie z baz ˛

a zawieraj ˛

ac ˛

a wzorce ataków, np. pakiety kierowane na port 80 w sieci

wewn˛etrznej mog ˛

a by´c sprawdzane, czy nie zawieraj ˛

a w sobie np. znanych ci ˛

agów znaków powoduj ˛

cych np. przepełnienie bufora w IIS

firmy Microsoft.

2.2

Snort

Snort[1, 6, 9] jest opartym na bibliotece libpcap snifferem który mo˙ze by´c u˙zyty jako system detekcji
i ostrzegania. Mo˙ze wykrywa´c ró˙zne próby ataków, takie jak ataki na przepełnienie bufora, skanowa-
nie „stealth”, ataki na CGI, próby dost˛epu do SMB

. W typowej konfiguracji Snort podsłuchuje pakiety

pojawiaj ˛

ace si˛e na okre´slonych interfejsach, wi˛ec jego działanie jest bardzo podobne do działania snif-

fera. Wykorzystuje on t ˛

a sam ˛

a bibliotek˛e

co popularny tcpdump. Posiada on mo˙zliwo´s´c zapisywania

przechwyconych pakietów w ró˙znych formatach. Dzi˛eki temu mo˙ze zosta´c wykorzystany jako lokalne
narz˛edzie do zbierania danych, które nast˛epnie b˛ed ˛

a przesyłane do dalszej analizy do np. centralnej bazy

w celu analizy. Ataki s ˛

a wykrywane na podstawie bazy reguł, do których dopasowywany jest pakiet.

Wcze´sniej podlega on obróbce przez preprocesory. Przy zastosowaniu biblioteki „libnet” mo˙ze on dy-
namicznie reagowa´c na przesyłan ˛

a zawarto´s´c, np. przerywaj ˛

ac sesj˛e TCP. Posiada on wiele rozszerze´n,

m.in. umo˙zliwiaj ˛

acych logowanie zdarze´n do ró˙znych baz danych (PostgreSQL, MySQL i inne poprzez

ODBC). A tak˙ze poprzez sysloga, do plików XML, wykorzystanie protokołu SMB do wysłania komu-
nikatu na stacj˛e zarz ˛

adzaj ˛

ac ˛

a pracuj ˛

ac ˛

a pod kontrol ˛

a systemu Windows firmy Microsoft, wykorzystanie

protokołu SNMP.

2.2.1

Konfiguracja programu Snort

W pliku konfiguracyjnym snort.conf

w pierwszej kolejno´sci powinni´smy zdefiniowa´c kilka zmiennych,

które b˛ed ˛

a u˙zywane przez Snorta. Zmienna HOME_NET okre´sla adres naszej/ych sieci, mo˙zemy j ˛

IIS - Internet Information Server

Protokół CIFS

libpcap - http://www.tcpdump.org/

W dystrybucji Debian plik ten znajduje si˛e domy´slnie w katalogi /etc/snort/, gdzie znajduj ˛

a si˛e tak˙ze pliki z regułami

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

zapisa´c np. tak:

var HOME_NET [10.1.1.0/24,192.168.1.0/24]

Aby ustawi´c t ˛

a zmienn ˛

a na jakikolwiek adres IP, mo˙zemy u˙zy´c słowa kluczowego „any”.

var HOME_NET any

Zmienna EXTERNAL_NET okre´sla adres sieci zewn˛etrznej, dobrym pomysłem mo˙ze by´c ustawie-

nie jej na warto´s´c „any”.

var EXTERNAL_NET any

Zmienna SMTP okre´sla adresy naszych serwerów SMTP. Podobnie zmienna HTTP_SERVER okre-

´sla adresy naszych serwerów WWW, a zmienne SQL_SERVER i DNS_SERVER odpowiednio adresy

serwerów SQL oraz DNS. Zmienne te okre´slamy, aby wyeliminowa´c cz˛e´s´c fałszywych alarmów, jakie
mo˙ze generowa´c ruch pochodz ˛

acy od tych serwerów. Zmienne te mo˙zemy ustawi´c na warto´s´c zmiennej

HOME_NET.

var SMTP $HOME_NET

var HTTP_SERVERS $HOME_NET

var SQL_SERVERS $HOME_NET

var DNS_SERVERS $HOME_NET

2.2.2

Rodzaje preprocesorów, konfiguracja

Decyzj˛e, o tym, jakie pakiety zostan ˛

a zalogowane, i ewentualnie, jakie akcje zostan ˛

a podj˛ete, zale˙zy od

preprocesorów. W zale˙zno´sci od preprocesora, ró˙zne cechy charakterystyczne pakietu s ˛

a analizowane.

Konfiguracja preprocesorów jest w formie:

preprocesor nazwa_preprocesora opcje_konfiguracyjne

Preprocesor frag2 - wsparcie defragmentacji IP

Ten preprocesor przeprowadza defragmentacje pakietów IP. Potrafi tak˙ze wykry´c ataki sfragmentowa-
nymi pakietami, które s ˛

a zwykle atakami typu DoS. Je´sli nie podamy opcji konfiguracyjnych, zostanie

u˙zyty z domy´slnymi opcjami, tj. 60 sekundowym „timeout” i 4MB buforem.

• timeout ustawia czas (w sekundach) przez jaki preprocesor b˛edzie trzymał sfragmentowany pa-

kiet. Po upłyni˛eciu tego czasu pakiet jest usuwany z bufora.

• memcap rozmiar w bajtach u˙zycia pami˛eci przez „frag2”.

Przykładowe u˙zycie:

preprocessor frag2 90,2048

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Preprocesor stream4 - kontrola stanów poł ˛

aczenia i składanie strumieni

U˙zywany w poł ˛

aczeniu z opcj ˛

a -z, dzi˛eki czemu snort generuje alarmy tylko wtedy, je˙zeli pakiet nale˙zy

do znanego, nawi ˛

azanego poł ˛

aczenia, tak˙ze w celu obrony przed narz˛edziami słu˙z ˛

acymi do ataku na Ne-

twork IDS, takimi jak stick/snot, których zadaniem o´slepienie systemu IDS. Osi ˛

agaj ˛

a ten cel, sprawiaj ˛

˙ze systemy IDS generuj ˛

a tysi ˛

ace alarmów na sekund˛e, co w konsekwencji prowadzi do ich przeci ˛

a˙zenia

i wył ˛

aczenia, lub faktu, ˙ze niektóre poł ˛

aczenia nie s ˛

a ju˙z przez nie sprawdzane i s ˛

a przepuszczane. Pa-

kiety s ˛

a najcz˛e´sciej sfałszowane, gdy˙z ich jedynym celem jest o´slepienie systemu IDS, nie za´s uzyskanie

jakiejkolwiek informacji. I nawet je´sli sam system IDS nie przepu´sci wła´sciwego ataku, bardzo praw-
dopodobne jest, ˙ze uczyni to człowiek analizuj ˛

acy logi. Za´s nawi ˛

azanie sesji TCP gwarantuje, ˙ze adres

´zródłowy nie jest sfałszowany. Tak˙ze detekcja np. prób przepełnienia bufora w pakietach nie nale˙z ˛

acych

do ˙zadnego poł ˛

aczenia, jest mało sensowna, gdy˙z taki atak jest skazany na niepowodzenie. Przeprowa-

dza tak˙ze pełne składanie w cało´s´c strumienia TCP, kontrol˛e stanu poł ˛

acze´n TCP. Mo˙ze wykry´c ró˙zne

rodzaje skanowa´n portów, detekcje u˙zywanego systemu operacyjnego, ECN

Opcje dotycz ˛

ace kontroli stanu poł ˛

acze´n:

• detect_scans Wykrywa próby skanowania niejawnego (nie u˙zywaj ˛

ace pełnego otwarcia TCP)

oraz generuje alarm w przypadku stwierdzenia takiego.

• detect_state_problems Wykrywa problemy z stanem poł ˛

aczenia TCP, ustawienie to mo˙ze ge-

nerowa´c wiele „szumu”, gdy˙z istnieje obecnie wiele implementacji stosu IP, które nie do ko´nca
trzymaj ˛

a si˛e standardów.

• keepstats [machine|binary] Trzyma statystyki sesji, opcja „machine” sprawia, ˙ze s ˛

a one w

prostym formacie, opcja „binary” sprawia, ˙ze format wyj´sciowy jest binarny.

• noinspect Wył ˛

acza kontrol˛e stanu poł ˛

acze´n.

• timeout [liczba] Ustawia licznik czasu, kiedy sesja zostanie zapomniana na „liczba” sekund,

domy´sln ˛

a warto´sci ˛

a jest 30 sekund.

• memcap [liczba] Limituje zu˙zycie pami˛eci przez „stream4” do „liczba” bajtów.

• log_flushed_streams Je˙zeli zostanie wykryte zdarzenie w strumieniu, opcja ta sprawi, ˙ze wszyst-

kie pakiety z bufora zostan ˛

a zapisane na dysk. Opcja działa tylko w poł ˛

aczeniu z logowaniem w

trybie „pcap”.

Przykładowe u˙zycie:

preprocessor stream4:

detect_scans

Składanie strumieni TCP

Preprocesor słu˙zy do składania strumieni TCP. W przypadku nie podania argumentów, w domy´slnej kon-
figuracji składane s ˛

a tylko pakiety pochodz ˛

ace od klienta usługi działaj ˛

acej na domy´slnej li´scie portów i

alarmy wyzwalane s ˛

a, je˙zeli strumie´n uznanie zostanie za zły.

Dost˛epne opcje:

• clientonly Składa tylko ruch pochodz ˛

acy od klienta.

Explicit Congestion Notification - RFC 2481 - http://www.ietf.org/rfc/rfc2481.txt

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• serveronly Składa tylko ruch pochodz ˛

acy od serwera.

• both Składany jest ruch zarówno pochodz ˛

acy od klienta, jak i serwera.

• noalerts Wył ˛

acza generowanie alarmów.

• ports [lista] u˙zywa listy portów oddzielonych spacjami, na jakich ma składa´c pakiety, opcja

„all” wł ˛

acza analiz˛e na wszystkich portach, domy´slnie w li´scie s ˛

a porty: 21, 23, 25, 53, 80, 110,

111, 143 i 513.

Przykładowe u˙zycie:

preprocessor stream4_reassemble

Preprocesor ˙z ˛

ada ´n protokołu HTTP

Preprocesor ten normalizuje ˙z ˛

adania HTTP, konwertuj ˛

ac wszystkie wyst ˛

apienia „%XX”

na odpowia-

daj ˛

ace im znaki ASCII. Jest to bardzo u˙zyteczne w celu wykrycia ci ˛

agów znaków, które intruz próbuje

zamaskowa´c poprzez umieszczenie w losowych miejscach ˙z ˛

adania „%XX”. W ten sposób próbuj ˛

ac unik-

n ˛

a´c wykrycia przez system IDS.

Dost˛epne opcje:

• [liczba] Port, na którym ma by´c prowadzona analiza ruchu.

• -unicode W celu wył ˛

aczenia analizy UNICODE, które mo˙ze by´c wykorzystane do tzw. „Web

Server Folder Traversal”

• -cginull Wył ˛

acza sprawdzanie ataków typu CGI NULL, czyli sprawdzanie, czy strumie´n za-

wiera „%00”, czasem mo˙zemy dosta´c fałszywy alarm w przypadku u˙zycia przez host ´zródłowy
„cookies” z danymi zakodowanymi „urlencode”.

Przykładowe u˙zycie:

preprocessor http_decode:

80 -unicode -cginull

Preprocesor unidecode

Jego działanie jest bardzo podobne do poprzedniego preprocesora, jednak jest o tyle lepszy, ˙ze identyfi-
kuje i klasyfikuje ataki z wykorzystaniem Unicode. Zalecany jako potencjalny zamiennik unidecode.

Preprocesor RPC

RPC

mo˙ze by´c przesyłane w innym ni˙z normalnie 4 bajtowym kodowaniu. Preprocesor normalizuje

ruch RPC w sposób podobny jak http_decode. Jako argument pobiera numer portu, na jakim urucho-
miona jest usługa RPC.

Warto´s´c XX oznacza warto´s´c znaku ASCII w systemie szesnastkowym

http://www.microsoft.com/technet/security/bulletin/ms00-078.asp

Remote Procedure Call - RFC 1831 - http://www.ietf.org/rfc/rfc1831.txt

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Preprocesor wykrywaj ˛

acy BackOrifice

Wykrywa ruch generowany przez „Back Orifice”

. Preprocesor ten korzysta z algorytmu szyfruj ˛

acego

protokołu „Back Orifice” (ale nie jego nowszej wersji „Back Orifice 2000”).

Dost˛epne opcje:

• -nobrute Wył ˛

acza atak siłowy na protokół „Back Orifice”, który jest u˙zywany w celu odszyfro-

wania ruchu. Wł ˛

aczenie tej opcji mo˙ze mie´c powa˙zny negatywny wpływ na ogólna wydajno´s´c

Snorta, jako wymagaj ˛

ace obliczeniowo.

• [liczba] Drugim argumentem jest liczba okre´slaj ˛

aca domy´slny klucz u˙zywany przy próbach

rozszyfrowania ruchu, warto´sci ˛

a domy´sln ˛

a jest 31337.

Preprocesor dekoduj ˛

acy sesje telnet

Preprocesor ten normalizuje ła´ncuchy negocjuj ˛

ace poł ˛

aczenie z protokołu telnet oraz ftp. Jego działanie

jest bardzo podobne do działania preprocesora http_decode, wyszukuje ruch, który wyłamuje si˛e ze
standardowego strumienia, i zast˛epuje go znormalizowan ˛

a wersj ˛

a, tak˙ze wzorce wyszukiwania słów

kluczowych w strumieniu nie wymagaj ˛

a modyfikacji.

Przykładowe u˙zycie:

preprocessor telnet_decode

Preprocesor wykrywaj ˛

acy skanowanie portów

Preprocesor ten wykrywa pakiety UDP i TCP, które przyjd ˛

a do X ró˙znych portów w przeci ˛

agu Y sekund.

Skanowanie niejawne, tzw. „stealth” jest zawsze wykrywane, niezale˙znie od tych ustawie´n. Pierwszym
argumentem jest/s ˛

a adresy sieci domowej.

Przykładowe u˙zycie, dla X=4, Y=3:

preprocessor portscan:

$HOME_NET 4 3 portscan.log

Preprocesor portscan-ignorehosts

Tego preprocesora nale˙zy u˙zy´c, aby unikn ˛

a´c fałszywych alarmów o skanowaniu generowanych przez

własne serwery, lub serwery o których wiemy, ˙ze utrzymuj ˛

a du˙zo poł ˛

acze´n z naszymi serwerami/sieci ˛

monitorowan ˛

a przez Snorta. Dobrym rozwi ˛

azaniem jest dodanie do tej listy serwerów DNS, z jakich

korzystamy. Listy adresów nale˙zy podawa´c rozdzielone spacj ˛

Przykładowe u˙zycie:

preprocessor portscan-ignorehosts:

$DNS_SERVERS

Back Orifice - jeden z pierwszych popularnych trojanów, wyst˛epuj ˛

acy na komputerach z systemem firmy Microsoft, po-

zwalał na zdalny dost˛ep intruza do komputera. Klient dost˛epny tak˙ze na systemy Unix.

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Grupa preprocesorów SPADE - Statistical Packet Anomaly Detection Engine

Zadaniem SPADE jest znajdowane pakietów, które mo˙zemy okre´sli´c jako interesuj ˛

ace, czyli np. pakie-

tów TCP z flaga SYN skierowanych do naszej sieci, oraz wychwycenie spo´sród tych pakietów takich,
które mo˙zemy okre´sli´c jako podejrzane, po czym zgłasza je, wraz z punktowym okre´sleniem, jak bardzo
dany pakiet jest „podejrzany”.

Punkty, jakie s ˛

a przydzielane pakietom, s ˛

a okre´slane na podstawie obserwacji ruchu w sieci. Im

mniej razy dany pakiet pojawiał si˛e wcze´sniej w sieci, tym wi˛ecej punktów otrzyma. Klasyfikacja pakie-
tów: np. pakiet z docelowym IP 10.2.3.10 i portem przeznaczenia 8080 mo˙ze by´c zakwalifikowany jako
jeden rodzaj pakietów. Tworzona jest tabela prawdopodobie´nstwa, która odpowiada zaobserwowanym
ró˙znicom w cz˛esto´sci pojawiania si˛e danych pakietów, z wi˛eksz ˛

a wag ˛

a dla pakietów zaobserwowanych

w nieodległej przeszło´sci. Dla przykładu, mo˙zemy rozwa˙zy´c:

P(destination_IP = 10.2.3.10, destinaton_port = 8080) = 10

P(destination_IP = 10.2.3.10, destinaton_port = 8079) = 0.1

Wi˛ec dla pakietu X, je˙zeli:

A(X ) = − log

(P(X ))

Otrzymujemy w pierwszym przypadku 3.32, natomiast dla pakietu przeznaczonego na port 8079

9.97. Jak mo˙zemy zauwa˙zy´c, w drugim przypadku jest to warto´s´c do´s´c du˙za. Po przekroczeniu warto´sci
granicznej ilo´sci pakietów przychodz ˛

acych w danym okresie czasu, wysyłany jest alarm. Dodatkowo

SPADE, oprócz raportowania anomali w ruchu pakietów w sieci, mo˙ze zosta´c tak˙ze u˙zyty do zebrania i
wygenerowania statystyk dotycz ˛

acych sieci, tj. ´srednia ilo´s´c podejrzanych pakietów, itp. Preprocesor ten

nie jest w stanie wykry´c, czy dany pakiet jest rzeczywi´scie niebezpieczny, gdy˙z swoj ˛

a „wiedz˛e” bazuje

tylko i wył ˛

acznie na podstawie statystyk wyst˛epowania. Nie jest te˙z w stanie wykry´c prób wykorzystania

np. bł˛edów skryptów CGI itp., gdy˙z wymaga to analizy zawarto´sci pakietu, natomiast SPADE analizuje
wył ˛

acznie niektóre cz˛e´sci nagłówka.

SPADE nie grupuje anormalnych zdarze´n, jest to zadanie korelatora, który obecnie jest w trakcie

rozwoju. U˙zycie korelatora powinno zapewni´c wykrywanie zdarze´n pozornie niezwi ˛

azanych ze sob ˛

np. bardzo wolne skanowanie, gdzie pojedyncze pakiety przychodz ˛

a co dłu˙zszy okres czasu, omijaj ˛

wykrycie.

Dost˛epne opcje:

preprocessor spade:

<anom-report-thresh> <state-file> <log-file> <prob-mode>

<checkpoint-freq>

• anom-report-thresh Jest to pocz ˛

atkowy poziom, po przekroczeniu którego pakiety s ˛

a zgłaszane

jako anormalne. Je´sli opcja ta ma warto´s´c ujemn ˛

a, Spade nie b˛edzie zgłaszał alarmów. Domy´sl-

nym ustawieniem jest -1.

• log-file Nazwa pliku, do jakiego Spade b˛edzie raportował zdarzenia. Plik ten b˛edzie odtwa-

rzany przy zako´nczeniu działania Snorta, lub po otrzymaniu przez niego sygnałów: SIGHUP,
SIGQUIT, SIGUSR1. Zapisywane s ˛

a tam: ilo´s´c pakietów przetworzonych przez Spade oraz ilo´s´c

wygenerowanych alarmów. Warto´sci ˛

a domy´sln ˛

a jest „-”, czyli standardowe wyj´scie.

• checkpoint-freq Ilo´s´c pakietów, po których przetworzeniu Spade zapisze aktualny stan tablic

prawdopodobie´nstwa do pliku. Opcja ta jest wykorzystywana, gdy˙z bardzo cz˛esto Snort jest re-
startowany co okre´slony czas, np. w celu rotacji logów.

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• state-file Nazwa pliku, do jakiego zostan ˛

a zapisane tablice prawdopodobie´nstwa. Je˙zeli plik

te istnieje w momencie uruchomienia Spade, pobrane z niego zostan ˛

a zapisane wcze´sniej tablice.

Plik ten jest uaktualniany co „checkpoint-freq” (domy´slnie 50000), na skutek otrzymania sygna-
łów: SIGHUP, SIGQUIT, SIGUSR1 lub przy zamykaniu Snorta. Aby wył ˛

aczy´c szukanie pliku

z poprzednimi tabelami, mo˙zemy wstawi´c warto´s´c „0” w to miejsce. Domy´sln ˛

a nazw ˛

a pliku jest

„spade.rcv”.

• prob-mode Jeden z czterech ró˙znych trybów obliczania tabel prawdopodobie´nstwa. Po zmianie

trybu, nale˙zy usun ˛

a´c stary plik „state-file”. Domy´sln ˛

a warto´sci ˛

a jest „3”. Mo˙zliwe argumenty

(gdzie sip = adres ´zródłowy, sport = port ´zródłowy, dip = adres docelowy, dport = port docelowy )
to:

1. aproksymacja metod ˛

a Bayesa

P(sip, sport, dip, d port)

P(sip, dip, port)

P(dip, d port)

Przykładowe u˙zycie:

preprocessor spade:

10.5 spade.rcv log.txt 3 50000

Preprocesor spade-homenet

W celu ograniczenia adresów, z jakich Spade b˛edzie przetwarzał pakiety, wykorzysta´c mo˙zemy pre-

procesor „spade-homenet”, gdy˙z domy´slnie przetwarzane s ˛

a pakiety ze wszystkich adresów. Argumen-

tami preprocesora s ˛

a adresy IP lub adresy sieci w formacie CIDR

Przykładowe u˙zycie:

preprocessor spade-homenet:

123.123.120.0/15 10.2.3.3

Wa˙zn ˛

a rzecz ˛

a jest znalezienie dobrego poziomu, po przekroczeniu którego generowane b˛ed ˛

a alarmy,

aby nie zosta´c zalanym przez zgłoszenia pochodz ˛

ace od normalnych pakietów, a tak˙ze przy zbyt wyso-

kim ustawieniu tej warto´sci, aby nie przepuszcza´c potencjalnie interesuj ˛

acych nas pakietów. Istniej ˛

a trzy

mechanizmy ustalania tego poziomu, z tego trzy s ˛

a to automatycznie dostosowuj ˛

ace poziom aby spełniał

okre´slone kryteria. Je´sli ˙zadne z nich nie spełniaj ˛

a oczekiwa´n, pozostaje mo˙zliwo´s´c r˛ecznego dobrania

tej warto´sci do´swiadczalnie.

Preprocesor spade-threshlearn

Preprocesor zwraca po pewnym czasie warto´s´c, jak ˛

a nale˙zy ustawi´c, aby otrzyma´c pewn ˛

a liczb˛e

alarmów. Po zako´nczeniu czasu obserwacji, generowany jest raport ko´ncowy. Raport po´sredni jest tak˙ze
generowany po otrzymaniu sygnałów: SIGHUP, SIGQUIT i SIGUSR1 lub przy zamkni˛eciu Snorta.

Opcje:

Classless Internet DOMAIN Routing - RFC 1519 - http://www.ietf.org/rfc/rfc1519.txt

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• num-scores Liczba wyników, jakie chcemy otrzyma´c w zadanym czasie, domy´slnie 200.

• obs-time Czas obserwacji, domy´slnie 24 godziny.

U˙zycie:

preprocessor spade-threshlearn:

<num-scores> <obs-time>

Preprocesor spade-adapt

Jest to najprostsza metoda, co jaki´s czas oblicza wa˙zon ˛

a ´sredni ˛

a aktualnego poziomu wyzwalania

alarmu i ostatnio zaobserwowany idealny poziom.

Opcje:

preprocessor spade-adapt:

<target-count> <adapt-time> <new-weight>

<interval-by-count>

• target-count Liczba analizowanych pakietów, domy´slnie 20.

• adapt-time Czas, po jakim zostanie zaktualizowany poziom wyzwolenia alarmu, domy´slnie 2.

• new-weight Waga dodawana dla nowej składowej liczonej ´sredniej, domy´slnie 0.5. Wy˙zsze war-

to´sci, powy˙zej 1.0, daj ˛

a wi˛eksz ˛

a zale˙zno´s´c od ostatnich obserwacji.

• interval-by-count Opcja decyduj ˛

aca, czy uaktualnienie odbywa si˛e po analizie okre´slonej ilo-

´sci pakietów, czy po upłyni˛eciu okre´slonego czasu. Domy´slnie wł ˛

aczona.

Preprocesor spade-adapt2

Druga metoda adaptacyjna jest bardziej skomplikowana. Nowy poziom wyzwalaj ˛

acy alarm obli-

czany jest ze ´sredniej trzech elementów, krótko, ´srednio i długoterminowego.

Opcje:

preprocessor spade-adapt2:

<target-spec> <obs-time> <NS> <NM> <NL>

• target-spec Ilo´s´c pakietów jakie chcemy otrzyma´c. Je˙zeli jest to warto´s´c >= 1, oznacza ilo´s´c

pakietów na godzin˛e, je˙zeli < 1, oznacza procent pakietów, które maj ˛

a wyzwala´c alarm. Warto´sci ˛

domy´sln ˛

a jest 0.01.

• obs-time Ilo´s´c minut, po jakim zostanie uaktualniony poziom wyzwalaj ˛

acy alarm. Domy´slnie

jest to 15 minut.

• NS Długo´s´c krótkoterminowego okresu „NS * obs-time”, domy´slnie 4, czyli 1 godzina.

• NM Liczba okresów krótkoterminowych w okresie ´srednioterminowym, domy´slnie 24.

• NL Liczba okresów ´srednioterminowych w okresie długoterminowym, domy´slnie 7.

Preprocesor spade-adapt3

Trzecia metoda adaptacyjna jest stosunkowo prosta. Poziom wyzwalaj ˛

acy alarm jest obliczany ze

´sredniej liczonej z idealnych jego warto´sci z ostatnich „N” obserwacji.

preprocessor spade-adapt3:

<target-spec> <obs-time> <num-obs>

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Opcje:

• target-spec Ilo´s´c pakietów jakie chcemy otrzyma´c, podobnie jak przy „spade-adapt2”, domy´sl-

nie 0.01.

• obs-time Ilo´s´c minut w jednym okresie obserwacji, domy´slnie 60.

• num-obs Ilo´s´c okresów obserwacji, z jakich b˛edzie liczona ´srednia, domy´slnie 168.

Preprocesor arpspoof

Jest to eksperymentalny preprocesor wykrywaj ˛

acy ataki ARP, i monitoruj ˛

acy odwzorowania pomi˛edzy

ARP i IP. Jako argumenty nale˙zy poda´c numer IP i ARP hosta.

U˙zycie:

preprocessor arpspoof

preprocessor arpspoof_detect_host:

192.168.40.1 f0:0f:00:f0:0f:00

2.2.3

Konfiguracja wtyczek, słu˙z ˛

acych do prezentacji wyj´scia z preprocesorów oraz lo-

gowania

Konfiguracj˛e wtyczek wyj´sciowych rozpoczynamy słowem kluczowym „output”, czyli ogólnie:

output nazwa_wtyczki opcje_konfiguracyjne

alert_syslog

Wtyczka loguje zdarzenia do sysloga, jako argumenty nale˙zy poda´c poziomy logowania.

output alert_syslog:

LOG_AUTH LOG_ALERT

log_tcpdump

Wtyczka loguje pakiety w binarnym formacie programu tcpdump. Jedynym argumentem jest nazwa
pliku wyj´sciowego.

output log_tcpdump:

snort.log

Bazy danych

Wtyczka loguje dane do baz danych. Obsługiwanych jest kilka baz danych, bezpo´srednio MySQL,
PostgreSQL i MSSQL, natomiast po´srednio inne bazy poprzez UnixODBC.

Opcje:

• host Je˙zeli zostanie podany, u˙zywana jest komunikacja po TCP/IP, w przeciwnym wypadku

gniazdka Unix.

• port Numer portu lub nazwa pliku b˛ed ˛

acego gniazdem Unix.

• dbname Nazwa bazy danych.

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• user Nazwa u˙zytkownika.

• password Hasło, je˙zeli poł ˛

aczenie do bazy danych wymaga uwierzytelnienia za pomoc ˛

a hasła.

• sensor_name Domy´slnie dane wysyłane s ˛

a jako ci ˛

ag znaków hex. Mog ˛

a by´c tak˙ze zapisywane w

kodowaniu base64, lub jako ASCII.

• detail Dost˛epne s ˛

a poziomy „full”(domy´slny) oraz „fast”, w którym logowane s ˛

a tylko najwa˙z-

niejsze informacje.

Przykładowe wpisy:

output database:

log, mysql, user=root password=test dbname=db host=localhost

output database:

alert, postgresql, user=snort dbname=snort

output database:

log, unixodbc, user=snort dbname=snort

output database:

log, mssql, dbname=snort user=snort password=test

Logowanie XML

Ten plugin zapisuje informacje w SNML

do pliku, lub poprzez sie´c. Mo˙zna go u˙zywa´c, aby np. zbiera´c

dane do centralnej bazy danych, a tak˙ze automatycznie wysyła´c powiadomienia o alarmach np. do CERT
Coordinatio Center.

U˙zycie:

output xml:

log, file=/var/log/snortxml

Ogólny format logowania

Wtyczka ta słu˙zy do logowania zdarze´n w pliku w formie binarnej. Sposób ten mo˙ze by´c przydatny
wtedy, je˙zeli potrzebujemy logowania zarówno szybkiego jak i efektywnego.

Opcje:

• plik Plik, do którego b˛ed ˛

a zapisywane logi.

• limit Maksymalny rozmiar pliku w MB.

Przykładowe u˙zycie:

output alert_unified:

filename snort.alert, limit 128

output log_unified:

filename snort.log, limit 128

SNMP

Wtyczka ta słu˙zy do alarmowanie i wysyłania informacji za pomoc ˛

a SNMP. Jej parametry ró˙zni ˛

a si˛e w

zale˙zno´sci od u˙zywanej wersji protokołu SNMP

Opcje i u˙zycie dla SNMP v2c:

Simple Network Markup Language - Snort Markup Language

Simple

Network

Management

Protocol

RFC

1157,1902

http://www.ietf.org/rfc/rfc1157.txt

oraz

http://www.ietf.org/rfc/rfc1902.txt

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

output trap_snmp alert, numer_sensora, trap|inform -v wersja_SNMP

-p Numer_Portu Nazwa_Hosta Nazwa_wspólnoty

Opcje i u˙zycie dla SNMP v3:

output trap_snmp:

alert, numer_sensora, trap|inform

-v wersja_SNMP -p Numer_Portu -u Nazwa_u˙

zytkownika -l authPriv

-a SHA -A Hasło_uwierzytelniaj ˛

ace -x DES -X Hasło_Prywatne Nazwa_Hosta

Definiowanie własnych reguł logowania, alarmowania

Aby dostosowa´c reguły logowania lub alarmowania do specyfiki naszego rozwi ˛

azania, mo˙zemy zdefi-

niowa´c własne reguły. Nazw˛e tak stworzonej reguły wpisujemy jako cel reguły snorta przetwarzaj ˛

acej

pakiety. Omówieniem tworzenia takich reguł zajmiemy si˛e w nast˛epnym rozdziale.

Przykładowy zapis, pozwalaj ˛

acy na logowanie alarmów jednocze´snie do bazy MySQL oraz do logów

systemowych poprzez sysloga.

ruletype redalert

{

type alert

output alert_syslog:

LOG_AUTH LOG_ALERT

output database:

log, mysql, user=snort dbname=snort host=localhost

}

2.2.4

Tworzenie i modyfikacja reguł

Reguły jakie s ˛

a dostarczane standardowo ze Snortem mog ˛

a by´c ´zródłem wielu fałszywych alarmów,

dlatego przed ich zastosowaniem nale˙zy si˛e z nimi zapozna´c. W niektórych sieciach np. poł ˛

aczenia na

porty na których komunikuje si˛e X-Windows jest normalne, w innych natomiast, jest działaniem bardzo
podejrzanym. Przykładowe reguły mo˙zemy sobie pobra´c z http://www.snort.org/. Jak zaraz zobaczymy,
edycja reguł i dodawanie nowych jest zaj˛eciem do´s´c łatwym, wymaga od nas tylko wiedzy nt. tego, jakie
pakiety w naszej sieci mog ˛

a by´c podejrzane.

Reguły Snorta od wersji 1.8 wzwy˙z mog ˛

a by´c zapisywane w kilku liniach, wymaga to dodania do

ko´nca ka˙zdej linii znaku backslash „\”. Reguły s ˛

a podzielone na dwie ró˙zne sekcje, pierwsza okre´sla,

co powinno znajdowa´c si˛e w nagłówku pakietu, a druga co w opcjach. Pierwsza sekcja zawiera akcj˛e,
jaka ma zosta´c przeprowadzona, je´sli dany pakiet b˛edzie pasował do reguły, nast˛epnie okre´slone mamy

´zródłowy i docelowy adres IP, mask˛e sieci, port ´zródłowy i docelowy. W sekcji opcji zawarta jest wia-

domo´s´c, jaka zostanie przekazana dla okre´slonej akcji, oraz informacje, jakie cz˛e´sci pakietu powinny
zosta´c sprawdzone.

Rodzaje reguł wst˛epnie zdefiniowanych:

• alert Reguła generuj ˛

aca alert i loguj ˛

aca pakiet.

• log Reguła loguj ˛

aca pakiet.

• pass Reguła przepuszczaj ˛

aca pakiet.

• activate Reguła alarmuj ˛

aca i aktywuj ˛

aca reguł˛e dynamiczn ˛

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• dynamic Reguła loguj ˛

aca, aktywowana reguł ˛

a activate

Przykładowa reguła sprawdzaj ˛

aca zawarto´s´c pakietów kierowanych na dany IP na port 111 pod

wzgl˛edem obecno´sci w nich danego ci ˛

agu mo˙ze wygl ˛

ada´c nast˛epuj ˛

aco:

alert tcp any any -> $HOME_NET 111 (content:„|00 01 86 a5|”;

msg:

„mountd access”;)

Widzimy tu tak˙ze wykorzystanie wcze´sniej omówionej przez nas zmiennej $HOME_NET. Mo˙zemy

zadeklarowa´c dowoln ˛

a zmienn ˛

a, w formacie:

var:

nazwa warto´

s´

Mo˙zemy podawa´c tak˙ze zakresy portów, jakich tyczy´c si˛e ma reguła, zakres podajemy rozdzielaj ˛

go znakiem „:”, np. „6000:6010”. Mo˙zemy poda´c tak˙ze zakresy niedomkni˛ete, np. wszystkie porty
wi˛eksze ni˙z 1024 oznaczymy „1024:”. Inn ˛

a mo˙zliwo´sci ˛

a jest negacja zarówno adresów IP jak i nume-

rów portów, u˙zywamy w tym celu „!”. Operatory „->” i „<>” słu˙z ˛

a do wskazania kierunku przepływu

pakietów, jaki ma by´c analizowany, w przypadku zastosowania operatora „<>” ´sledzone b˛ed ˛

a obie strony

poł ˛

aczenia, co pozwala np. na analiz˛e całej sesji POP3 lub telnet.

Snort wspiera tak˙ze reguły dynamiczne, tj. reguły które s ˛

a aktywowane przez inne reguły. Mo˙ze to

słu˙zy´c np. do wygenerowania alarmu je´sli reguła aktywuj ˛

aca była spełniona okre´slon ˛

a ilo´s´c razy. Przy-

kładowo, pojedyncze pakiety aktywuj ˛

ace reguł˛e nie powinny powodowa´c alarmu, gdy˙z mog ˛

a by´c tylko

próbami ataku, natomiast wi˛eksza ilo´s´c pakietów mo˙ze sugerowa´c, ˙ze dany atak był skuteczny i nale˙zy
natychmiast przeprowadzi´c wcze´sniej okre´slone w takiej sytuacji działanie. Reguła aktywuj ˛

aca jest po-

dobna do reguły alarmuj ˛

acej, natomiast reguła dynamiczna odpowiada regule loguj ˛

acej. Przykładowy

zapis reguły aktywuj ˛

acej i dynamicznej:

activate tcp !$HOME_NET any -> $HOME_NET 143 (flags:

PA;

content:

„|E8C0FFFFFF|

\bin|”; activates:

msg:

„IMAP buffer overflow!”;)

dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by:

1; count:

50;)

Powy˙zszy przykład przedstawia reguł˛e aktywuj ˛

ac ˛

a oraz reguł˛e dynamiczn ˛

a, która jest aktywowana

przez reguł˛e aktywn ˛

a po zliczeniu 50 pakietów.

Pola i opcje reguł

• msg Okre´sla wiadomo´s´c, jaka b˛edzie wypisana razem z samym pakietem w logach lub alarmach.

• logto Loguje pakiety spełniaj ˛

ace reguł˛e do pliku okre´slonego przez u˙zytkownika.

• ttl Sprawdza zawarto´s´c pola TTL.

• tos Sprawdza zawarto´s´c pola TOS nagłówka pakietu IP.

• id Sprawdza zawarto´s´c pola ID.

• ipoption Sprawdza opcje pakietu IP, mo˙zliwe jest sprawdzenie tylko jednej opcji w regule. Mo˙z-

liwe warto´sci to:

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

– rr Record Route

– eol Koniec listy opcji

– nop Brak opcji

– ts Znacznik czasu

– sec opcje zabezpiecze´n IP

– lsrr Loose Source Routing

– ssrr Strict Source Routing

– satid Identyfikator strumienia.

• fragbits Sprawdza ustawienie bitów Reserved, Don’t Fragment oraz More Fragments. Przy-

kładowy zapis fragbits:

DF+;

oznacza, ˙ze warunek b˛edzie spełniony, je˙zeli b˛ed ˛

a ustawione

wszystkie bity, w tym przypadku bit DF, stan innych jest oboj˛etny. Mo˙zemy tak˙ze u˙zy´c znaku
„*”, oznaczaj ˛

acego spełnienie warunku gdy jakikolwiek bit jest ustawiony, a tak˙ze negacje „!” np.

fragbits:

MF!;

spełnia warunek, je´sli bit MF nie jest ustawiony.

• dsize Sprawdza rozmiar pakietu. Mo˙zliwe jest u˙zycie operatorów „<” i „>”.

• flags Sprawdza flagi TCP. Aktualnie Snort rozró˙znia 9 zmiennych z tym zwi ˛

azanych, mog ˛

a one

by´c ł ˛

aczone za pomoc ˛

a podobnych operatorów, jakie s ˛

a u˙zywane przy opcji „fragbits”:

– F FIN

– S SYN

– R RST

– P PSH

– A ACK

– U URG

– 2 zarezerwowany 2 bit

– 1 zarezerwowany 1 bit

– 0 brak ustawionej flagi

• seq Sprawdza numer sekwencyjny pakietu

• ack Sprawdza pole potwierdzenia TCP

• itype Sprawdza warto´s´c pola okre´slaj ˛

acego typ komunikatu ICMP.

• icode Sprawdza warto´s´c pola okre´slaj ˛

acego kod komunikatu ICMP.

Record Route - pozwala zapami˛eta´c w pakiecie do 9 routerów, przez jakie przechodzi pakiet, u˙zytecznie przy sprawdzaniu,

jak ˛

a drog ˛

a pakiet wraca, która mo˙ze by´c inna ni˙z droga do miejsca przeznaczenia

Loose Source Routing - pozwala na okre´slenie, przez jaki router pakiet powinien przej´s´c na swojej drodze do celu. Mo˙ze

by´c u˙zywane w poł ˛

aczeniu z fałszowaniem adresów IP, pozwala to na przechwycenie odpowiedzi, która normalnie najprawdo-

podobniej zostałaby przesłana na sfałszowany adres ´zródłowy bez po´srednictwa hosta który wysłał dany sfałszowany adres. Z
tych powodów, pakiety takie powinny by´c blokowane, i nie powinny mie´c mo˙zliwo´sci opuszczenia naszej sieci.

Strict Source Routing - pozwala na okre´slenie dokładnej listy routerów, przez jakie powinien przej´s´c pakiet.

W obecnej chwili u˙zyteczne jedynie przy wykrywaniu pingowania TCP programem NMAP, który ustawia to pole na

warto´s´c 0, wysyłaj ˛

ac pakiet z ustawion ˛

a flaga TCP ACK.

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• icmp_id Sprawdza pole ICMP ECHO ID

• icmp_seq Sprawdza numer sekwencji ICMP ECHO

• content Wyszukuje w danych przenoszonych przez pakiet podanego wzorca znaków, dane bi-

narne musz ˛

a by´c zamkni˛ete pomi˛edzy „|”, np. |DEAD BEEF| , wyszukiwanie zwraca uwag˛e na

wielko´s´c liter.

• content-list Zawiera nazw˛e pliku, w jakim zapisane s ˛

a wzorce danych do wyszukania w danych

pakietu.

• offset Ustawia przesuni˛ecie, od jakiego ma zacz ˛

a´c si˛e przeszukiwanie wzorca z pola „Content”.

• depth Ogranicza zasi˛eg poszukiwania do okre´slonej ilo´sci bajtów

• nocase Ignoruje wielko´s´c liter przy przeszukiwaniu danych pakietu

• session Loguje dane z sesji TCP, mo˙ze by´c wykorzystane do zalogowania całej sesji u˙zytkow-

nika. Posiada dwie opcje printable | all, pierwsza z nich spowoduje zalogowanie tylko tego,
co u˙zytkownik mógł normalnie zobaczy´c lub wpisa´c, druga loguje wszystkie dane. Opcja ta mo˙ze
by´c u˙zyteczna np. przy analizie logów tcpdump, gdy˙z przy normalnej pracy systemu mo˙ze wpro-
wadzi´c znaczne opó´znienia.

• rpc Sprawdza serwisy RPC

i automatycznie dekoduje aplikacje, procedur˛e i wersje. Format

opcji to „aplikacja, procedura, wersja”. Mo˙zliwe jest stosowanie wzorca „*”.

• resp Aktywna odpowied´z na pakiet, opcja ta pozwala na wysłanie kilku rodzajów pakietu w

odpowiedzi, je´sli jaki´s pakiet b˛edzie pasował do reguły. Mo˙zliwe jest tym samym np. zerwanie
poł ˛

aczenia TCP:

– rst_snd Wysyła pakiet TCP RST do gniazdka, z którego przyszedł pakiet.

– rst_rcv Wysyła pakiet TCP RST do gniazdka, które otrzymało pakiet.

– rst_all Wysyła pakiet TCP RST do obu stron poł ˛

aczenia.

– icmp_net Wysyła komunikat ICMP ICMP_NET_UNREACH do nadawcy.

– icmp_host Wysyła komunikat ICMP ICMP_HOST_UNREACH do nadawcy.

– icmp_port Wysyła komunikat ICMP ICMP _PORT_UNREACH do nadawcy.

– icmp_all Wysyła wszystkie wy˙zej wymienione komunikaty ICMP do nadawcy.

• react Opcja ta w poł ˛

aczeniu z opcj ˛

a resp pozwala na zablokowanie dost˛epu do danego zasobu,

najbardziej u˙zyteczna mo˙ze by´c przy blokowaniu dost˛epu np. do okre´slonych stron WWW, za-
wieraj ˛

acych np. okre´slone słowo. Opcje, jakie mog ˛

a si˛e tu znale´z´c, to: block powoduj ˛

acy zablo-

kowanie dost˛epu i msg powoduj ˛

acy wysłanie komunikatu do przegl ˛

adarki. Przykładowy zapis:

alert tcp any 80 <> $HOME_NET any (content:

„cracks”;

msg:

„Dost˛

ep zabroniony!”; react:

block, msg;)

Istniej ˛

a sytuacje, kiedy wiemy, ˙ze poszukiwany przez nas ci ˛

ag znaków powinien wyst ˛

api´c na pocz ˛

atku pakiety, np. okre-

´slone ˙z ˛

adanie GET protokołu HTTP

RPC - Remote Procedure Call - RFC 1050, 1057, 1831

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

• reference Opcja zawiera referencj˛e do zewn˛etrznego opisu zidentyfikowanego ataki. Obecnie

zawiera wsparcie dla „Bugtraq”, „CVE”, „Arachnids”, „McAfee”. Przykładowa reguła mo˙ze wy-
gl ˛

ada´c nast˛epuj ˛

aco:

alert TCP any any -> any 21 (msg:

„IDS287/ftp-wuftp260-venglin-linux”;

\
flags:

AP; content:

„|31c031db 31c9b046 cd80 31c031db|”;

reference:

arachNIDS,IDS287; reference:

bugtraq,1387;

reference:

cve,CAN-2000-1574; )

• sid Zawiera wewn˛etrzn ˛

a referencj˛e do bazy Snorta z komunikatami o atakach.

• classtype Klasyfikuje dan ˛

a reguł˛e, pozwala to zró˙znicowa´c typ danego pakietu.

• severity Stopie´n wa˙zno´sci danej reguły, w poł ˛

aczeniu z classtype pozwala do´s´c dobrze sklasyfi-

kowa´c wa˙zno´s´c danej reguły.

• uricontent Wyszukuje ci ˛

ag znaków w URI

w danych pakietu.

• tag Pozwala „zaznaczy´c” wi˛ecej pakietów, ni˙z tylko pierwszy, który wyzwolił dan ˛

a reguł˛e. Od

momentu wyzwolenia danej reguły, wszystkie pakiety pochodz ˛

ace od ´zródłowego hosta s ˛

a „za-

znaczane”. Format zapisu:

tag:

typ, liczba, metryka, [kierunek]

– typ

∗ session Loguje pakiety nale˙z ˛

ace do sesji, która wyzwoliła reguł˛e

∗ host Loguj ˛

a pakiety pochodz ˛

ace od hosta, który aktywował reguł˛e, mo˙zliwe u˙zycie

opcji „kierunek”.

– liczba Liczba jednostek, podanych w polu „metryka”.

– metryka

∗ packets „Zaznacza” liczb˛e pakietów.
∗ seconds „Zaznacza” pakiety przez liczb˛e sekund.

– kierunek U˙zyteczny jedynie w poł ˛

aczeniu z typem host, przyjmuje warto´sci dst lub src

w zale˙zno´sci od tego, z której strony poł ˛

aczenia została wyzwolona reguła.

• ip_proto Sprawdza konkretny protokół IP, list˛e protokołów mo˙zna z reguły uzyska´c z pliku

/etc/protocols

• Sprawdza, czy ´zródłowy numer IP jest taki sam jak numer docelowy.

• stateless Pozwala na sprawdzenie pakietu, je´sli nie nale˙zy do poł ˛

aczenia.

• regex Pozwala na dopasowywanie zawarto´sci pakietów na podstawie wzorców. Moduł ten jest

jednak jeszcze w trakcie rozwoju, i nie zaleca si˛e korzystania z niego w rozwi ˛

azaniach produkcyj-

nych.

Universal Resource Identifier - RFC 1630 - http://www.ietf.org/rfc/rfc1630.txt

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Zasady konstrukcji efektywnych reguł

Nale˙zy pami˛eta´c, ˙ze wyszukiwanie charakterystycznych ci ˛

agów znaków w pakietach za pomoc ˛

a opcji

content

dopóki nie u˙zyjemy opcji nocase jest wra˙zliwe na wielko´s´c liter. Tak˙ze zwraca´c nale˙zy uwag˛e,

jakie zasady pod tym wzgl˛edem stosuje dany protokół, np. w protokole FTP polecenia zwykle s ˛

a pisane

du˙zymi literami, cho´c ka˙zdy serwer powinien zaakceptowa´c tak˙ze pisane małymi. Bior ˛

ac pod uwag˛e

przykładow ˛

a reguł˛e:

alert tcp any any -> $HOME_NET 21 (content:

„user root”;

msg:

„Logowanie FTP na u˙

zytkownika root”;)

Mo˙zemy zauwa˙zy´c, ˙ze reguła ta przepu´sci wszystkie próby logowania, gdzie zostanie u˙zyte „USER

root”

, pierwsz ˛

a poprawk ˛

a jaka si˛e nasuwa jest wi˛ec dodanie opcji nocase. Aby przy´spieszy´c przetwa-

rzanie pakietu przez reguł˛e mo˙zemy skorzysta´c z faktu, ˙ze opcja content jest sprawdzana jako ostatnia.
Przeszukiwanie danych pakietu za tym ci ˛

agiem znaków ma sens jedynie, je´sli pakiet ju˙z nale˙zy do na-

wi ˛

azanego poł ˛

aczenia TCP, a wi˛ec b˛edzie mi ˛

ał ustawione flagi ACK oraz PSH. Wszystkie inne pakiety

ju˙z po sprawdzeniu tego warunku zostan ˛

a odrzucone, wi˛ec zmniejszy si˛e ilo´s´c kosztownego czasowo

procesu przeszukiwania zawarto´sci pakietów.

2.2.5

Uruchamianie oraz przykładowe logi ataków

Snorta mo˙zemy uruchomi´c jako daemon lub w celach testowych, na pierwszym planie.

Przykładowa sesja Snorta:

# snort -c /etc/snort/snort.conf -l /var/log/snort -b -d -u snort -g snort

Log directory = /var/log/snort

Initializing Network Interface eth0

--== Initializing Snort ==--

Decoding Ethernet on interface eth0

Initializing Preprocessors!

Initializing Plug-ins!

Initializating Output Plugins!

Parsing Rules file /etc/snort/snort.conf

+++++++++++++++++++++++++++++++++++++++++++++++++++

Initializing rule chains...

No arguments to frag2 directive, setting defaults to:

Fragment timeout: 60 seconds

Fragment memory cap: 4194304 bytes

Stream4 config:

Stateful inspection: ACTIVE

Session statistics: INACTIVE

Session timeout: 30 seconds

Session memory cap: 8388608 bytes

State alerts: INACTIVE

Scan alerts: ACTIVE

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Log Flushed Streams: INACTIVE

No arguments to stream4_reassemble, setting defaults:

Reassemble client: ACTIVE

Reassemble server: INACTIVE

Reassemble ports: 21 23 25 53 80 143 110 111 513

Reassembly alerts: ACTIVE

Reassembly method: FAVOR_OLD

Back Orifice detection brute force: DISABLED

Using LOCAL time

1112 Snort rules read...

1112 Option Chains linked into 107 Chain Headers

0 Dynamic rules

+++++++++++++++++++++++++++++++++++++++++++++++++++

Rule application order: ->activation->dynamic->alert->pass->log

--== Initialization Complete ==--

-*> Snort! <*-

Version 1.8.6 (Build 105)

By Martin Roesch (roesch@sourcefire.com, www.snort.org)

===============================================================================

Snort analyzed 9085 out of 9085 packets, The kernel dropped 0(0.000%) packets

Breakdown by protocol:

Action Stats:

TCP: 3363

(37.017%)

ALERTS: 35

UDP: 2738

(30.138%)

LOGGED: 35

ICMP: 22

(0.242%)

PASSED: 0

ARP: 1031

(11.348%)

IPv6: 0

(0.000%)

IPX: 21

(0.231%)

OTHER: 1910

(21.024%)

DISCARD: 0

(0.000%)

===============================================================================

Fragmentation Stats:

Fragmented IP Packets: 0

(0.000%)

Fragment Trackers: 0

Rebuilt IP Packets: 0

Frag elements used: 0

Discarded(incomplete): 0

Discarded(timeout): 0

Frag2 memory faults: 0

===============================================================================

TCP Stream Reassembly Stats:

TCP Packets Used: 3363

(37.017%)

ROZDZIAŁ 2. SYSTEMY INTRUSION DETECTION SYSTEM

Stream Trackers: 79

Stream flushes: 11

Segments used: 72

Stream4 Memory Faults: 0

===============================================================================

Snort received signal 2, exiting

Jak mo˙zemy zauwa˙zy´c, przy ko´nczeniu pracy Snort wypisuje na ekran statystyki dotycz ˛

ace przetwo-

rzonych przez niego pakietów, wygenerowanych alarmów i zalogowanych pakietów.

Uruchamiaj ˛

ac Snorta przeł ˛

acznikiem -l okre´slili´smy katalog, do którego logowane b˛ed ˛

a pakiery

jako /var/log/snort/ i tam tez znajdziemy m.in. plik alert do którego w naszym przypadku zo-
stały zalogowane pakiety spełniaj ˛

ace nasze reguły. Przegl ˛

adaj ˛

ac ten plik, mo˙zemy zauwa˙zy´c kilka prób

ataku

Przytocz˛e poni˙zej dwa z nich:

[**] [1:257:1] DNS named version attempt [**]

[Classification: Attempted Information Leak] [Priority: 2]

06/10-16:36:41.511874 192.168.11.245:33001 -> 192.168.11.244:53

UDP TTL:64 TOS:0x0 ID:25648 IpLen:20 DgmLen:58 DF

Len: 38

[Xref => http://www.whitehats.com/info/IDS278]

Mamy tutaj rozpoznan ˛

a prób˛e sprawdzenia wersji serwera DNS. Klasyfikacja jest okre´slona jako

wyciek informacji, a poni˙zej mamy dane zalogowanego pakietu. W ostatniej linii mamy odno´snik, gdzie
mo˙zemy na temat tego typu ataku/zagro˙zenia przeczyta´c. Z reguły taka próba słu˙zy do ustalenia, czy
dany serwer DNS jest wersj ˛

a podatn ˛

a na konkretny atak, po niej za´s mo˙ze nast ˛

api´c zasadniczy atak.

[**] [1:350:1] FTP EXPLOIT x86 linux overflow [**]

[Classification: Attempted Administrator Privilege Gain] [Priority: 1]

06/10-16:35:34.748476 192.168.11.245:41082 -> 192.168.11.244:21

TCP TTL:64 TOS:0x0 ID:15788 IpLen:20 DgmLen:411 DF

***AP*** Seq: 0x1BC7A45

Ack: 0xB08BBE6F

Win: 0x1974

TcpLen: 32

TCP Options (3) => NOP NOP TS: 28396060 335563

[Xref => http://www.securityfocus.com/bid/113]

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0368]

W tym przypadku Snort rozpoznał w pakiecie prób˛e wykorzystania bł˛edu w serwisie ftpd

. Po

informacjach o samym pakiecie, w liniach Xref s ˛

a podane odno´sniki do tego typu ataków.

Ataki zostały przeprowadzone na testowy serwer b˛ed ˛

acy w sieci, w której testowany był Snort.

Atak był przeprowadzany na serwis ProFTPD, z wykorzystaniem techniki przepełnienia bufora, bł ˛

ad obecny w wersjach

1.2pre1, 1.2pre2 i 1.2pre3 ProFTPD.

Rozdział 3

Sniffery - u˙zywanie i wykrywanie

3.1

Zasada działania, metody wykrywania

Sniffer[18, 17, 16] jest to program zbieraj ˛

acy dane z sieci i loguj ˛

acy je w pewien sposób. Najwi˛ekszym

problemem jest, je´sli dzieje si˛e to bez wiedzy i udziału osoby uprawnionej do takich działa´n, któr ˛

a jest

najcz˛e´sciej administrator danej sieci. W przypadku, je˙zeli to intruzowi udało si˛e w jaki´s sposób zainsta-
lowa´c program słu˙z ˛

acy do podsłuchiwania sieci, stanowi to bardzo du˙ze zagro˙zenie dla bezpiecze´nstwa

sieci. Okrycie działaj ˛

acego sniffera w sieci jest bardzo trudne, gdy˙z jego działanie jest pasywne, nie

wysyła on ˙zadnych pakietów, a w ka˙zdym razie nie powinien. Jednak istniej ˛

a metody, które pomagaj ˛

a w

jego znalezieniu, jakkolwiek nie s ˛

a one nigdy w 100% skuteczne.

3.1.1

Zasada działania

Najcz˛esciej sniffer do efektywnego działania potrzebuje „słysze´c” cały ruch przechodz ˛

acy w naszej sieci.

Aby to osi ˛

agn ˛

a´c musi przestawi´c interfejs sieciowy w tryb promiscous. Je´sli sniffer umiejscowiony jest

na ho´scie, przez który przechodzi cały interesuj ˛

acy intruza ruch, ustawienie trybu promiscous nie jest

konieczne. Dlatego najbardziej niebezpieczne s ˛

a sniffery umieszczone w w˛ezłach sieciowych, gdy˙z tam

maj ˛

a mo˙zliwo´s´c wykrycia najwi˛ekszej ilo´sci interesuj ˛

acych ich danych.

Nale˙załoby wspomnie´c, co wła´sciwie daje ustawienie interfejsu sieciowego w tryb promiscous.

Ka˙zda karta sieciowa posiada swój własny unikalny adres, np. 00:a0:4c:09:32:91 i przyjmuje ramki
danych, które s ˛

a adresowane wył ˛

acznie do niej. W trybie promiscous natomiast odbiera wszystkie ramki,

jakie fizycznie „słyszy”. Czyli intruz mo˙ze w prosty sposób zebra´c wszystkie hasła, jakie s ˛

a przesyłane

poprzez sie´c, je´sli nie s ˛

a one szyfrowane. W dalszej cz˛e´sci postaram si˛e omówi´c kilka najprostszych

sposobów, w jaki mo˙zna si˛e przed tym zabezpieczy´c.

3.1.2

Znajdowanie uruchomionego sniffera bezpo´srednio w systemie

Wa˙znym elementem profilaktyki s ˛

a z pewno´sci ˛

a okresowe próby przeszukiwania sieci oraz komputerów

w nich b˛ed ˛

acych w poszukiwaniu interfejsów znajduj ˛

acych si˛e w trybie promiscous. Je´sli znalezienie ta-

kiego interfejsu w przypadku gdy mamy dost˛ep do wszystkich komputerów jest ´srednio skomplikowane,
to w przypadku gdy takiego dost˛epu nie mamy, jest bardzo trudne. Dlatego w takich przypadkach nale˙zy
stosowa´c inne ´srodki bezpiecze´nstwa.

Aby umie´sci´c sniffer w naszym systemie/systemach intruz musi najpierw uzyska´c do nich dost˛ep

superu˙zytkownika, gdy˙z w innym przypadku nie ma mo˙zliwo´sci uzyska´c praw wystarczaj ˛

acych do czy-

tania pakietów w takiej postaci, w jakiej otrzymuje je j ˛

adro systemu operacyjnego. Tak wi˛ec komputer,

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

na którym zostanie znaleziony działaj ˛

acy sniffer uwa˙za´c nale˙zy za skompromitowany i wymagaj ˛

acy do-

gł˛ebnej analizy, w jaki sposób uzyskano do niego uprawnienia. Bardzo wa˙zn ˛

a rzecz ˛

a jest tak˙ze zaufanie

do j ˛

adra systemu. Intruz modyfikuj ˛

ac j ˛

adro mógłby wymieni´c niektóre funkcje systemowe, aby ukry´c

obecno´s´c w systemie sniffera.

Je˙zeli jeste´smy pewni, ˙ze j ˛

adro systemu nie zostało zmodyfikowane, gdy˙z wył ˛

aczona jest mo˙zliwo´s´c

ładowania modułów j ˛

adra, oraz mo˙zliwo´s´c bezpo´sredniej modyfikacji pami˛eci a samo j ˛

adro znajduje si˛e

np. na zabezpieczonej przed zapisem dyskietce, mo˙zemy spróbowa´c ustali´c, czy w systemie zagnie´zdził
si˛e sniffer.

Pierwsz ˛

a rzecz ˛

a jak ˛

a nale˙zy sprawdzi´c, jest czy interfejs sieciowy nie znajduje si˛e w trybie promi-

scous. W przypadku, gdy j ˛

adro posiada mo˙zliwo´s´c ładowania modułów, intruz mógł za jego pomoc ˛

np. zmieni´c działanie funkcji, która przekazuje programom przestrzeni u˙zytkownika dane, tak˙ze spraw-
dzenie takie mogłoby nie by´c efektywne. Je˙zeli natomiast posiadamy sprawdzone j ˛

adro, to wystarczy

zwykle sprawdzenie ustawienia flagi promiscous na danym interfejsie.

Z troch˛e inn ˛

a sytuacj ˛

a mo˙zemy si˛e spotka´c, je˙zeli sprawdzamy komputer, który pełni np. rol˛e routera.

Z natury swej funkcji przechodzi przez niego cały ruch wychodz ˛

acy i wchodz ˛

acy do sieci wewn˛etrznej.

Lub np. jest to komputer który z racji wykonywanych na nim zada´n posiada wł ˛

aczon ˛

a flag˛e PROMISC

a wi˛ec sniffer nie potrzebuje jej ustawia´c.

Zacz ˛

a´c nale˙zy od przyjrzenia si˛e procesom, które posiadaj ˛

a czas uruchomienia zbli˙zony do czasu

działania całego systemu, oraz posiadaj ˛

a nieznane nazwy. Proces sniffera mo˙ze mie´c nazw˛e podobn ˛

a do

jednego z demonów, które normalnie działaj ˛

a w systemie w czasie normalnej pracy, aby zmyli´c mniej

do´swiadczonego administratora, który zwykle b˛edzie si˛e bał usun ˛

a´c nieznany mu proces, maj ˛

acy np.

nazw˛e „pagebuf”.

Je˙zeli nie znale´zli´smy ˙zadnych podejrzanych procesów, mo˙zemy spróbowa´c troch˛e okr˛e˙zn ˛

a drog˛e.

Zadaniem sniffera jest z reguły gromadzenie haseł. Korzystaj ˛

ac z tego faktu, mo˙zemy spróbowa´c si˛e

zalogowa´c u˙zywaj ˛

ac np. serwisu telnet, na konto o atrakcyjnej nazwie, typu „adm” czy „admin”. Na-

st˛epnie usuwamy konto lub zmieniamy hasło ju˙z w bezpieczny sposób, i przeszukujemy wszystkie za-
soby plikowe serwera pod k ˛

atem wyst˛epowania w jakim´s pliku tego hasła. Mo˙ze by´c to uwie´nczone

powodzeniem, je˙zeli sniffer nie szyfruje w ˙zaden sposób danych, jakie zbiera.

3.1.3

Znajdowanie uruchomionego sniffera na podstawie analizy sieci

Je˙zeli nie mamy bezpo´sredniego dost˛epu do komputerów znajduj ˛

acych si˛e w sieci, mo˙zemy próbowa´c

ustali´c, czy jaki´s komputer słucha w trybie PROMISC, jednak nigdy nie b˛edziemy w stanie ustali´c tego
z cał ˛

a pewno´sci ˛

Sztuczny ruch w sieci

Jednym ze sposobów oceny, czy na danym komputerze mo˙ze znajdowa´c si˛e sniffer mo˙ze by´c zbadanie
czasu jego odpowiedzi. W tym celu pingujemy cał ˛

a sie´c, mierz ˛

ac ´srednie czasy odpowiedzi ka˙zdego z

hostów. Nast˛epnie wysyłamy do sieci du˙z ˛

a ilo´s´c ramek z do nieistniej ˛

acych adresów MAC i mierzymy

powtórnie czasy odpowiedzi. Je´sli czasy te znacz ˛

aco si˛e w przypadku niektórych hostów ró˙zni ˛

a od sie-

bie, mo˙ze to ´swiadczy´c o tym, ˙ze przetwarzały one wła´snie ten zwi˛ekszony ruch w sieci, nieprzeznaczony
dla nich i st ˛

ad wynikaj ˛

a zwi˛ekszone czasy odpowiedzi. Jest to niestety metoda do´s´c zawodna.

Mo˙ze by´c to np. host z systemem IDS, który kontroluje sie´c wewn˛etrzn ˛

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

Odpytywanie reverse DNS

Je˙zeli z jaki´s hostów obserwujemy zwi˛ekszony ruch do serwerów DNS, mo˙ze to by´c tak˙ze oznak ˛

a działa-

nia sniffera. Zdarza si˛e, ˙ze intruz nie wył ˛

aczy rozwi ˛

azywania numerów IP na nazwy i sniffer po otrzyma-

niu ka˙zdego pakietu sprawdza nazwy DNS adresów ´zródłowego i docelowego. Mo˙zemy t ˛

a ewentualno´s´c

sprawdzi´c, wysyłaj ˛

ac na jaki´s okre´slony adres pakiet i sprawdzaj ˛

, czy z danego komputera przyszło

zapytanie o dany adres, o którym on nie powinien nic wiedzie´c.

Znajomo´s´c odwzorowania ARP<->IP

Metoda ta wykorzystuje fakt, ˙ze protokół ARP tworzy tablic˛e odwzorowa´n pomi˛edzy adresami MAC i
IP, dane te s ˛

a co jaki´s czas od´swie˙zane. Je˙zeli w tablicy nie ma zapisanego adresu MAC karty sieciowej,

do której system operacyjny zamierza wysła´c pakiet, wysyła on zapytanie o numer MAC, jaki posiada
adres IP.

# tcpdump -n arp

tcpdump:

listening on eth0 (...)

12:17:23.036431 arp who-has 192.168.11.245

tell 192.168.11.1

12:17:23.036501 arp reply 192.168.11.245 is-at 0:a0:4b:9:42:93

(...)

23 packets received by filter

0 packets dropped by kernel

Na przykładzie powy˙zej widzimy zapytanie pochodz ˛

ace od numeru IP 192.168.11.1, pytaj ˛

ace si˛e o

to, jaki adres MAC posiada numer IP 192.168.11.245. W drugiej linii widzimy odpowied´z, ˙ze taki adres
IP jest dost˛epny pod adresem MAC 0:a0:4b:9:42:93.

I to otwiera nam do´s´c dobr ˛

a drog˛e, aby sprawdzi´c, czy jaki´s komputer nie dysponuje informacjami,

których zna´c nie powinien. Typowy czas, po jakim s ˛

a usuwane wpisy z tablicy odwzoruj ˛

acej ARP<->IP

wynosi około 20 minut. Aby mie´c pewno´s´c, ˙ze dany komputer nie ł ˛

aczył si˛e z komputerem z którego

b˛edziemy przeprowadza´c prób˛e, nale˙załoby np. odł ˛

aczy´c kabel ł ˛

acz ˛

acy go z sieci ˛

a lokaln ˛

a na ten czas.

W pierwszym kroku, wysyłamy na nieistniej ˛

acy adres komunikat arp reply z adresem IP komputera,

który u˙zywamy do skanowania. Nast˛epnie wysyłamy np. ICMP Echo do podejrzanego hosta. Je˙zeli nie
wy´sle on wtedy komunikatu arp who-has, b˛edzie to znaczy´c, ˙ze wszedł on w posiadanie tej informacji
wcze´sniej. Aby wykluczy´c mo˙zliwo´s´c, ˙ze dany komputer posiada statyczne wpisy w tablicy ARP<->IP,
mo˙zemy spróbowa´c znów odczeka´c pewien czas, i po wysłaniu ponownie ICMP Echo sprawdzi´c, czy
przed wysłaniem odpowiedzi podejrzany host zapyta si˛e o nasz adres MAC. Komunikaty ICMP Echo
musz ˛

a w obu przypadkach posiada´c sfałszowany adres MAC, gdy˙z inaczej podejrzany komputer ju˙z po

otrzymaniu naszego pakietu zostanie „nauczony” naszego adresy MAC.

Wykorzystanie opcji Source Route

Nast˛epn ˛

a mo˙zliwo´s´c daje nam opcja Source Route datagramu IP. W tym przypadku b˛edziemy wy-

syła´c komunikat ICMP Echo z adresem docelowym podejrzanego komputera, jednak w datagramie IP
ustawimy opcj˛e Strict Source Route i jako pierwszy w˛ezeł po´srednicz ˛

acy ustawimy jeden z istnie-

j ˛

acych komputerów w sieci lokalnej. Musimy jednak mie´c pewno´s´c, ˙ze dany komputer po´srednicz ˛

acy

nie potrafi przekazywa´c pakietów. W tej sytuacji komputer po´srednicz ˛

acy powinien odrzuci´c pakiet i nie

Np. za pomoc ˛

a programu tcpdump

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

powinien on dotrze´c do celu. Je˙zeli jednak na otrzymamy odpowied´z na taki pakiet, ´swiadczy´c to mo˙ze
o tym, ˙ze podejrzany komputer dowiedział si˛e o tym pakiecie „nieoficjalnie”. Nale˙zy jeszcze sprawdzi´c
pole TTL pakietu, je˙zeli bowiem jest ono mniejsze, ni˙z pakietu wychodz ˛

acego, znaczyłoby to, ˙ze jednak

wybrany przez nas komputer po´srednicz ˛

acy poprawnie przekazuje pakiety.

Niewykrywalny sniffer?

Mo˙zliwo´s´c zbudowania sniffera niewykrywalnego konwencjonalnymi ´srodkami oczywi´scie istnieje. Po-
siadanie przez komputer numeru IP, lub nawet przez kart˛e sieciow ˛

a numeru MAC nie jest konieczne,

wystarczy, ˙ze b˛edzie ona miała fizyczny dost˛ep do okablowania sieci. Na takiej zasadzie działa np.
NIDS NetRanger firmy Cisco. Tak˙ze zablokowanie całego wychodz ˛

acego ruchu firewallem znacz ˛

aco

mo˙ze utrudni´c wykrycie sniffera.

3.1.4

Podsłuch w sieci przeł ˛

aczanej

Cho´c wydawa´c by si˛e mogło, ˙ze zastosowanie przeł ˛

aczników sieciowych całkowicie eliminuje mo˙zli-

wo´s´c podsłuchu w sieci lokalnej, jest to niestety przekonanie mylne. Nale˙załoby wyja´sni´c w tym miej-
scu działanie przeł ˛

acznika. W odró˙znieniu od prostych koncentratorów, które otrzymany ruch kieruj ˛

na wszystkie własne porty, switche zapami˛etuj ˛

a, jaki adres MAC jest dost˛epny na jakim porcie switcha,

tworz ˛

ac dynamicznie map˛e odwzorowa´c MAC<->nr. portu. Zmniejsza to domen˛e kolizyjn ˛

a, sprawia-

j ˛

ac, ˙ze dane komputery widz ˛

a jedynie przeznaczone dla nich dane, jednak wci ˛

a˙z pozostaj ˛

a w tej samej

domenie rozgłoszeniowej. Sprawia to, ˙ze wci ˛

a˙z s ˛

a podatne na ataki ARP oraz ICMP Spoofing.

Jednak takie sytuacje jest w stanie wykry´c system IDS, lub mo˙zna im zapobiec poprzez odpowiedni ˛

konfiguracj˛e przeł ˛

acznika. Najlepszym sposobem w tym przypadku byłaby konfiguracja sieci VLAN,

tworz ˛

ac zaufane grupy komputerów, w ekstremalnym przypadku składaj ˛

ace si˛e z jednego komputera i

serwerów, z których usług musi on skorzysta´c. Pewn ˛

a ochron˛e zapewnia tak˙ze rezygnacja z dynamicz-

nego tworzenia listy powi ˛

aza´n adresów MAC z portami switcha na korzy´s´c rozwi ˛

azania ze statycznie

przypisanymi adresami MAC do odpowiednich portów. Jest to rozwi ˛

azanie stosowane rzadko, gdy˙z

zmusza osoby opiekuj ˛

ace si˛e sieci ˛

a i sprawuj ˛

ace nad ni ˛

a nadzór do ka˙zdorazowego przekonfigurowania

przeł ˛

acznika po wymianie np. karty sieciowej w komputerze.

Nale˙zy za´s pami˛eta´c, ˙ze mo˙zliwo´s´c podsłuchania transmisji pakietów w przypadku np. skorzystania

z ARP Spoofingu to tylko cz˛e´s´c mo˙zliwo´sci, jakie uzyskuje intruz przy skorzystaniu z tej metody. Znacz-
nie gorsze mo˙ze by´c podszycie si˛e pod zaufany host, lub nawet przechwycenie sesji SSH w wersji 1 lub
SSL. Przy obecnie mocno rozwijaj ˛

acym si˛e handlu za pomoc ˛

a Internetu, gdzie transakcje s ˛

a przepro-

wadzane na zdawałoby si˛e bezpiecznych stronach zabezpieczanych za pomoc ˛

a SSL, jest to szczególnie

gro´zne.

ARP Spoofing

Technika ta polega na podszywaniu, udawaniu innego komputera za pomoc ˛

a protokołu ARP. Wykorzy-

stuje ona fakt, ˙ze informacje pozyskane za pomoc ˛

a komunikatu arp who-has nie s ˛

a w ˙zaden sposób

weryfikowane. Zapytania ARP kierowane s ˛

a na adres rozgłoszeniowy, a wi˛ec trafiaj ˛

a na wszystkie porty

przeł ˛

acznika. Intruz mo˙ze odpowiedzie´c na takie zapytanie, podaj ˛

ac swój adres MAC jako posiadaj ˛

acy

taki adres IP. Jak zostało ju˙z wcze´sniej wspomniane, wyniki odpowiedzi na pakiet arp who-has s ˛

a przez

pewien czas pami˛etane przez dany komputer, a wi˛ec przez taki czas dany adres MAC b˛edzie uwa˙zany za
posiadaj ˛

acy interesuj ˛

acy adres IP. Oczywi´scie, na takie zapytanie odpowie tak˙ze prawdziwy komputer.

Jednak wystarczy, ˙ze odpowied´z komputera próbuj ˛

acego si˛e podszy´c b˛edzie szybsza, aby to wpis z jego

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

adresem został zapami˛etany. Komputer podszywaj ˛

acy si˛e mo˙ze tak˙ze aktywnie wysyła´c pakiety arp

aby „nauczy´c” dany host swojego numeru MAC jak tylko przeterminuje on swój wpis dotycz ˛

acy

tego numeru IP. Dzi˛eki temu, je˙zeli sfałszowane zostanie powi ˛

azanie MAC<->IP dotycz ˛

ace routera, cały

ruch b˛edzie przesyłany wychodz ˛

acy poza sie´c lokaln ˛

a b˛edzie przesyłany do komputera intruza. Aby nie

wzbudza´c podejrze´n, mo˙ze on przekazywa´c dalej pakiety do routera, a po podobnym podszyciu si˛e pod
komputer-ofiar˛e wzgl˛edem routera, b˛edzie przez niego przechodził cały ruch wychodz ˛

acy/przychodz ˛

acy

do danego komputera.

Zastosowanie tego rozwi ˛

azania w celu podsłuchu całej sieci tak˙ze jest do´s´c proste, wystarczy wysła´c

sfałszowane odwzorowanie albo na adres rozgłoszeniowy, albo do ka˙zdego hosta osobno. Wysłanie na
adres rozgłoszeniowy mo˙ze nie by´c w tym przypadku najlepszym rozwi ˛

azaniem, gdy˙z intruz mo˙ze nie

chcie´c, aby podobne pakiety były widoczne na routerze. W dalszej cz˛e´sci zostanie opisany ten rodzaj
ataku za pomoc ˛

a programu ettercap.Zabezpieczeniem przed tego rodzaju atakiem jest np. statyczne

przypisanie wszystkich mapowa´c pomi˛edzy MAC<->IP na ka˙zdym ho´scie.

Najprostszy sposób to u˙zycie pliku /etc/ethers, który w przypadku wi˛ekszej sieci mo˙zna rozpro-

wadza´c w sposób automatyczny, np. z repozytorium CVS lub ´sci ˛

aga´c z serwera FTP. Mo˙zliwo´sci jest

bardzo wiele. W pliku tym zapisane s ˛

a odwzorowania adresów IP na odpowiednie adresy MAC.

Przykładowy plik:

# cat /etc/ethers

00:01:02:AF:D7:B0 192.168.11.1

00:01:11:11:11:11 192.168.11.3

Odwzorowania na podstawie tego pliku w prosty sposób mo˙zemy ustawi´c w systemie:

# arp -an

(192.168.11.244) at 00:02:44:0B:7D:A1 [ether] on eth0

(192.168.11.1) at 00:01:02:AF:D7:B0 [ether] PERM on eth0

# arp -f

# arp -an

(192.168.11.244) at 00:02:44:0B:7D:A1 [ether] on eth0

(192.168.11.1) at 00:01:02:AF:D7:B0 [ether] PERM on eth0

(192.168.11.3) at 00:01:11:11:11:11 [ether] PERM on eth0

Sekcja z adresem 192.168.11.3 została dodana do pliku /etc/ethers, w pierwszym wyniku po-

lecenia arp nie widzimy wpisu dotycz ˛

acego tego adresu, natomiast po zastosowaniu arp -f

w tablicy

odwzorowa´n pojawił si˛e nam wpis stały, o czym ´swiadczy znacznik PERM, dotycz ˛

acy tego adresu. Od-

wzorowanie adresu 192.168.11.244 jest natomiast wpisem dynamicznym.

ICMP Spoofing

Protokół IRDP

umo˙zliwia ropropagowanie w sieci informacji o domy´slnym routerze. Mechanizm ten

mo˙ze by´c bardzo przydatny np. przy uszkodzeniu domy´slnej bramki, aby mo˙zliwie szybko wskaza´c

Opcja -f polecenia arp ustawia statyczne odwzorowanie MAC<->IP na podstawie danych z pliku, domy´slnie jest to plik

/etc/ethers

ICMP Router Discovery Protocol - RFC 1256 - http://www.ietf.org/rfc/rfc1256.txt

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

wszystkim komputerom w sieci now ˛

a bramk˛e. Jednak jak bardzo wiele z protokołów zaprojektowa-

nych wiele lat temu

nie bierze on pod uwag˛e skali zagro˙ze´n, z jakimi spotykamy si˛e we współczesnych

sieciach. Nie posiada on po prostu ˙zadnych mechanizmów uwierzytelniaj ˛

acych, wi˛ec odpowiednio spre-

parowany datagram ICMP przekieruje cały ruch przez komputer intruza, umo˙zliwiaj ˛

a´c mu podsłuch.

Obsługa tego protokołu musi jednak by´c wł ˛

aczona na ka˙zdej stacji, która ma z tego skorzysta´c. Domy´sl-

nie w systemie Linux, je˙zeli przy konfiguracji j ˛

adra wybrali´smy optymalizacj˛e komputera jako Host a

nie Router, system b˛edzie korzystał z mechanizmu IRDP.

Format komunikatu IRDP:

• Router Advertisment Message Typ 9, Kod 0.

– Num Addrs 4 bitowe pole, okre´slaj ˛

ace liczb˛e adresów routerów, które s ˛

a ogłaszane w tej

wiadomo´sci.

– Addr Entry Size 4 bitowe pole, okre´slaj ˛

ace liczb˛e 32 bitowych słów z informacj ˛

a o adresie

routera.

– Lifetime 8 bitowe pole, okre´slaj ˛

ace liczb˛e sekund, przez jakie adres routera b˛edzie uwa˙zany

za wa˙zny.

– Router Address[i], i=1..Num Addrs Adres IP routera.

– Preference Level[i], i=1..Num Addrs Wy˙zsza warto´s´c w tym polu preferuje wybranie

danego routera jako router domy´slny.

• Router Solicitation Message Typ 10, Kod 0.

– Reserved Ustawiane jako 0, ignorowane przy odbiorze.

W momencie, gdy dany host nie posiada ˙zadnego domy´slnego routera dla danej klasy adresów, wy-

syła komunikat ICMP Router Solicitation Message, na który powinien dosta´c odpowied´z Router
Advertisment Message

z routera, je˙zeli jest on skonfigurowany do u˙zywania tego protokołu. Je˙zeli

natomiast sie´c działa normalnie i nie wyst˛epuje potrzeba wysyłania odpowiedzi dla zapyta´n hostów, ko-
munikaty Router Solicitation Message s ˛

a rozsyłane domy´slnie co pewien okres czasu okre´slony

przez administratora. Okres ten jednak nie jest stały, podlega nieznacznej losowej zmianie, aby unikn ˛

a´c

jednoczesnego wysłania komunikatów przez kilka routerów jednocze´snie.

W systemie linux, je˙zeli mamy dost˛epn ˛

a (wkompilowan ˛

a w j ˛

adro) obsług˛e sysctl mo˙zemy wył ˛

czy´c reakcj˛e na pakiety Router Advertisment Message za pomoc ˛

a modyfikacji opcji

/proc/sys/net/ipv4/conf/default/accept_ra

, je´sli tak ˛

a posiadamy.

Zakłócanie pracy przeł ˛

acznika

Je˙zeli porty przeł ˛

acznika gromadz ˛

a dane o adresach MAC w sposób dynamiczny, a jest tak w wi˛ekszo´sci

konfiguracji, zwłaszcza je´sli u˙zyte s ˛

a tanie, nie maj ˛

ace mo˙zliwo´sci zarz ˛

adzania urz ˛

adzenia, mo˙zliwe jest

dynamiczne modyfikowanie tablicy odwzorowa´n MAC<->port. W tym celu intruz musi co pewien czas
wysła´c pakiet z adresem MAC karty, do której transmisje chce podsłucha´c. Przeł ˛

acznik zaktualizuje

swoje dane, i dopóki nie dostanie jakiego´s pakietu pochodz ˛

acego od komputera podsłuchiwanego, dane

b˛edzie przesyłał do intruza. Je˙zeli u˙zywany jest protokół TCP, to dzi˛eki jego mo˙zliwo´sci retransmisji pa-
kietów, które nie dotarły, komputer-ofiara mo˙ze do´swiadczy´c co najwy˙zej krótkich zakłóce´n transmisji.

Omawiane rozszerzenie zostało opisane w dokumencie RFC w 1991

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

Istnieje tak˙ze mo˙zliwo´s´c sprawienia, aby przeł ˛

acznik zacz ˛

ał si˛e zachowywa´c tak jak zwykły hub.

Niektóre przeł ˛

aczniki po przepełnieniu ich tablic adresów MAC zaczynaj ˛

a pracowa´c jak zwykłe koncen-

tratory, po otrzymaniu na jednym porcie pakietu powtarzaj ˛

a go na wszystkie inne porty. Lepsze przeł ˛

acz-

niki posiadaj ˛

a ograniczenie ilo´sci adresów MAC, jakie mog ˛

a zosta´c przypisane do portu. W przeciwnym

wypadku wystarczy ˙ze intruz wy´sle du˙z ˛

a ilo´s´c pakietów z losowo wygenerowanymi numerami MAC,

aby przepełni´c pami˛e´c przeł ˛

acznika.

Przej˛ecie kontroli nad przeł ˛

acznikiem

Wi˛ekszo´s´c lepszych przeł ˛

aczników posiada mo˙zliwo´s´c zdalnego zarz ˛

adzania nimi za pomoc ˛

a telnet,

snmp, www. Niestety, bardzo cz˛esto osoby odpowiedzialne za infrastruktur˛e sieciow ˛

a nie zmieniaj ˛

domy´slnych haseł serwisowych, jakie posiada wi˛ekszo´s´c tego typu urz ˛

adze´n. Przy wykorzystaniu np.

programu nmap i jego mo˙zliwo´sci rozpoznania na podstawie odpowiedzi z danego IP typu systemu ope-
racyjnego znalezienie IP, na którym skonfigurowany jest dost˛ep zdalny do przeł ˛

acznika nie stanowi dla

potencjalnego intruza problemu.

# nmap -p21,23,80 -O -n xxx.xxx.xxx.xxx

Starting nmap V. 2.54BETA33 ( www.insecure.org/nmap/ )

Interesting ports on (xxx.xxx.xxx.xxx):

(The 1 port scanned but not shown below is in state:

closed)

Port State Service

23/tcp open telnet

80/tcp open http

Remote OS guesses:

3Com SuperStack II (OS v 2.0), AsanteHub 2072 Ethernet

Hub

# nmap -sU -O -n xxx.xxx.xxx.xxx

Starting nmap V. 2.54BETA33 ( www.insecure.org/nmap/ )

Warning:

OS detection will be MUCH less reliable because we did not find

at least 1 open and 1 closed TCP port

Interesting ports on (xxx.xxx.xxx.xxx):

(The 1455 ports scanned but not shown below are in state:

closed)

Port State Service

69/udp open tftp

106/udp open 3com-tsmux

161/udp open snmp

2048/udp open dls-monitor

Remote OS guesses:

3Com SuperStack II (OS v 2.0), Allied Telesyn AT-S10

version 3.0 on an AT-TS24TR hub, Asanta IntraStack Ethernet Switch (6014

DSB Versions:

BP(2.06 ), FW(1.03 )), Asanta IntraSwitch 5324, AsanteHub

2072 Ethernet Hub, Gold Card Ethernet Interface Firmware Ver.

3.19 (95.01.16).

Apparently a MIO Network interface for HP LaserJets, etc.

Posiadaj ˛

ac np. informacje przedstawione powy˙zej, intruz mo˙ze w ci ˛

agu kilku minut znale´z´c hasła

serwisowe do tego okre´slonego typu przeł ˛

acznika. Je˙zeli hasła zostały jednak zmienione, mo˙zna sko-

rzysta´c z faktu, ˙ze protokół SNMP pozwala na siłowe próby odgadni˛ecia hasła. Nawet zastosowanie

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

list kontroli dost˛epu nie gwarantuje nam bezpiecze´nstwa, gdy˙z wystarczy podsłucha´c komunikacj˛e stacji
administratora z przeł ˛

acznikiem, aby pozna´c jej IP.

Gdy intruz ju˙z posiada dost˛ep do konfiguracji przeł ˛

acznika, mo˙ze przeł ˛

aczy´c port w który jest wpi˛ety

w tzw. tryb

witched

ort

alyzer (span).

3.2

Zagro˙zenia zwi ˛

azane z podszywaniem si˛e pod zaufane komputery

Pierwszym zagro˙zeniem mo˙ze by´c wymieniane ju˙z wcze´sniej, podszycie si˛e pod router i w konsekwencji
mo˙zliwo´s´c podsłuchiwania całego ruchu wychodz ˛

acego, przychodz ˛

acego przez dany komputer. Podszy-

cie si˛e np. pod serwer DNS daje mo˙zliwo´s´c dowolnego przekierowania u˙zytkownika, np. na zaufan ˛

przez niego stron˛e, gdzie mo˙ze zosta´c nakłoniony do podania informacji poufnych. A tak˙ze przechwy-
cenia sesji ssh w wersji 1 lub ssl

3.3

Sposoby obrony przed podszywaniem si˛e oraz podsłuchiwaniem

3.3.1

Sieci VLAN

VLAN

jest to grupa urz ˛

adze´n sieciowych typu PC, drukarki sieciowe, które działaj ˛

a tak, jakby znajdo-

wały sił w jednym segmencie sieci, gdy niekoniecznie jest to prawd ˛

a. Dla przykładu mo˙zemy poda´c,

˙ze do jednego VLAN mog ˛

a nale˙ze´c np. wszystkie komputery danego wydziału, niezale˙znie od miejsca,

gdzie one si˛e znajduj ˛

a. Wszystkie zasoby sieci s ˛

a przez nie współdzielone tak jakby były one fizycznie

poł ˛

aczone w jeden segment sieci. Jest to rozwi ˛

azanie bardzo efektywne, gdy˙z pozwala na elastyczne

zmiany konfiguracji sieci bez ka˙zdorazowego udawania sił do urz ˛

adze´n sieciowych w celu przepi˛ecia

kabla. W ten sposób tak˙ze mo˙zemy zwi˛ekszy´c bezpiecze´nstwo w sieci, gdy˙z w łatwy sposób mo˙zemy
decydowa´c, jakie komputery maj ˛

a dost˛ep do jakich zasobów. Ruch pomi˛edzy VLANami mo˙ze by´c kon-

trolowany przez router/firewall/IDS, wi˛ec ten fakt tak˙ze wpływa na mo˙zliwo´sci ograniczenia dost˛epu dla
osób niepowołanych, a tak˙ze ogranicza mo˙zliwo´s´c tzw. sztormów rozgłoszeniowych

Rozró˙zniamy trzy rodzaje sieci VLAN[12]:

• Oparte na portach. Ka˙zdy port na switchu mo˙zemy przypisa´c do VLANu. Np. porty 1-5 mog ˛

nale˙ze´c do VLAN X, porty 6-14 do VLAN Y, a 15-23 do VLAN Z. Switch determinuje przy-
nale˙zno´s´c do danego VLAN na podstawie tego, z jakiego portu przychodzi pakiet. Je˙zeli jaki´s
u˙zytkownik jest przenoszony na inne stanowisko, administrator musi zmieni´c tylko numer portu,
jaki nale˙zy do danego VLANu. Jednak je˙zeli do portu wpi˛eta jest wi˛eksza liczba u˙zytkowników
przez koncentrator, wszyscy oni musz ˛

a nale˙ze´c do tego samego VLAN.

• Oparte na adresach MAC. Przynale˙zno´s´c do konkretnego VLAN jest w tym przypadku rozstrzy-

gana na podstawie adresu MAC ´zródłowego lub docelowego. Ka˙zdy switch musi przechowywa´c
tablic˛e adresów MAC i ich powi ˛

aza´n z sieciami VLAN. Zalet ˛

a tego rozwi ˛

azania jest brak koniecz-

no´sci rekonfiguracji switcha, je˙zeli jeden z u˙zytkowników zostanie przeniesiony w inne miejsce.
Wad ˛

a tego rozwi ˛

azania jest to, ˙ze adres MAC nie mo˙ze zosta´c wpisany jako członek wielu sieci

VLAN.

Mo˙zna tego dokona´c np. narz˛edziami sshmitm lub webmitm z pakietu dsniff

Virtual LAN

Sztorm rozgłoszeniowy jest z reguły wywołany przez nieprawidłowy pakiet rozgłoszeniowy, który wywołuje odpowied´z

od wszystkich odbiorców te˙z pakietem rozgłoszeniowym, w bardzo szybkim czasie powoduj ˛

a´c zapychanie sieci.

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

Rysunek 3.1: Podział sieci lokalnej za pomoc ˛

a VLAN

• Oparte na protokole. Przynale˙zno´s´c do danej sieci VLAN jest wnioskowana na podstawie proto-

kołu oraz adresów warstwy 3 modelu ISO/OSI. Jest to najbardziej elastyczna metoda, zapewnia-
j ˛

aca najbardziej logiczne pogrupowanie u˙zytkowników. Np. dla podsieci IP mo˙ze by´c przypisany

jej własny VLAN. Pozwala tak˙ze na przypisanie nieroutowalnych protokołów, takich jak NetBios,
do wi˛ekszych sieci VLAN, ni˙z protokoły routowalne.

Dwie ostatnie metody korzystaj ˛

a z oznaczania pakietów zgodnie z specyfikacja 802.1q. Pozwala to

na rozró˙znienie pakietów nale˙z ˛

acych do danej sieci VLAN na wszystkich switchach wspieraj ˛

acych sieci

VLAN.

W nowszych wersjach j ˛

adra Linux 2.4.x pojawił si˛e patch, zapewniaj ˛

acy obsług˛e sieci VLAN. Po-

zwala on na samodzielne oznakowanie pakietów, jako nale˙z ˛

acych do danej sieci VLAN. Pozwala to np.

na funkcjonowanie opartego na linuxie firewalla, b˛ed ˛

acego wpi˛etym za pomoc ˛

a tylko jednej karty sie-

ciowej do switcha, zapewniaj ˛

acego np. przypisanie danego portu do okre´slonych sieci VLAN. Jest to

oczywi´scie rozwi ˛

azanie wydajne, pod warunkiem ˙ze firewall taki ma filtrowa´c mały ruch, gdy˙z inaczej

spowodowałoby to spadek wydajno´sci sieci. Rozwi ˛

azanie to mo˙zna rozpatrywa´c np. w sytuacji, gdy

filtrujemy kilka strumieni danych 10 Mbps, natomiast port, w który wpi˛ety jest firewall jest portem 100
Mbps.

Z punktu widzenia bezpiecze´nstwa, najlepszym rozwi ˛

azaniem byłoby stworzenie tylu sieci VLAN,

ilu pracuje w sieci u˙zytkowników, oraz przekazywanie wszystkich pakietów poprzez router. Innym,
szybszym rozwi ˛

azaniem pod wzgl˛edem szybko´sci przeł ˛

aczania pakietów, jest zast ˛

apienie przeł ˛

aczników

pracuj ˛

acych w warstwie 2 modelu ISO/OSI przeł ˛

acznikami warstwy trzeciej.

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

3.3.2

Szyfrowanie transmisji

Najprostszym zabezpieczeniem i do´s´c skutecznym jest stosowanie szyfrowania transmisji. Wi˛ekszo´s´c
usług mo˙zna szyfrowa´c przy pomocy SSL. Mo˙zna do tego celu wykorzysta´c program stunnel, polskiego
autorstwa. Pozwala on na proste dodanie obsługi szyfrowanych poł ˛

acze´n do usług, które takiej obsługi

nie posiadaj ˛

a. Dzi˛eki temu mo˙zemy zaszyfrowa´c np. protokół POP3, SMTP, IMAP. S ˛

a to najpopu-

larniejsze usługi, z których najcz˛e´sciej korzystaj ˛

a u˙zytkownicy. Je˙zeli chodzi o bezpo´sredni dost˛ep do

powłoki zdalnego systemu, nale˙zy korzysta´c z ssh w wersji 2. Natomiast do kopiowania plików do/z
zdalnego serwera mo˙zna wykorzysta´c scp lub sftp.

Je˙zeli korzystamy z protokołu SSL przy przegl ˛

adaniu szyfrowanych stron WWW, nale˙zy du˙z ˛

a uwag˛e

zwraca´c na to, kto jest wystawc ˛

a certyfikatu. Je˙zeli poprzednio u˙zywali´smy ju˙z tej strony, nale˙zy zwróci´c

uwag˛e, czy w mi˛edzyczasie certyfikat nie uległ zmianie. Mo˙ze to ´swiadczy´c o tym, ˙ze kto´s próbuje si˛e
podszywa´c pod dany host.

Podobn ˛

a uwag˛e nale˙zy zwraca´c na komunikaty o zmienionym kluczu serwera w przypadku ssh.

Do´s´c dobrym zwyczajem jest wykorzystywanie do uwierzytelnienia si˛e na serwerze przy poł ˛

aczeniu ssh

klucza prywatnego z hasłem. Ani klucz, ani hasło w tym przypadku nie s ˛

a przesyłane przez sie´c, a wi˛ec

ewentualny intruz mo˙ze podsłucha´c co najwy˙zej przebieg samej sesji. A wygenerowane ostrze˙zenie o
zmianie klucza publicznego serwera powinno posłu˙zy´c za wystarczaj ˛

ace ostrze˙zenie, aby zainteresowa´c

si˛e problemem.

Niestety, istniej ˛

a usługi, których nie mo˙zna w obecnej chwili szyfrowa´c bezpo´srednio. S ˛

a to np.

protokół CIFS, czyli popularna samba/Microsoft Network, czy te˙z NFS

. W tym wypadku pozostaje

stworzenie sieci VPN

i szyfrowanie cało´sci ruchu przez ni ˛

a przechodz ˛

acego. Jest to zreszt ˛

a jedyne

rozs ˛

adne rozwi ˛

azanie w przypadku potrzeby poł ˛

aczenia dwóch odległych od siebie oddziałów firmy,

gdzie rozwi ˛

azanie polegaj ˛

ace na samodzielnym poł ˛

aczeniu fizycznie tych dwóch miejsc jest z reguły

całkowicie nieopłacalne. Du˙zo ta´nszym rozwi ˛

azaniem jest np. skorzystanie z usług jakiego´s dostawcy

usług telekomunikacyjnych lub dostawcy Internetu i po podł ˛

aczeniu obydwu biur do sieci połaczenie ich

za pomoc ˛

a VPN.

3.4

Sniffing w sieci przeł ˛

aczanej - ettercap

3.4.1

Opis i mo˙zliwo´sci programu

Aby u´swiadomi´c wszystkim, z jak ˛

a łatwo´sci ˛

a intruz mo˙ze zrealizowa´c wszystkie powy˙zej opisane ataki,

przedstawie mo˙zliwo´sci dost˛epnego dla ka˙zdego programu ettercap, dost˛epnego m.in.

http://ettercap.sourceforge.net

„Bł˛edne poczucie bezpiecze´nstwa jest gorsze ni˙z brak zabezpiecze´n”

Steve Gibson

Program wspiera aktywne oraz pasywne dekodowanie haseł z ró˙znych protokołów, m.in. pozwala na

przechwycenie u˙zytkownika i hasła w wersji 1 ssh, podsłuch szyfrowanej SSL sesji HTTPS. Dzi˛eki mo-
dułowej budowie pozwala na pisanie wtyczek współpracuj ˛

acych z programem. Za ich pomoc ˛

a mo˙zemy

np. logowa´c hasła przesyłane przez protokoły: TELNET, FTP, POP, RLOGIN, SSH1, ICQ, SMB, My-
SQL, HTTP, NNTP, X11, NAPSTER, IRC, RIP, BGP, SOCKS 5, IMAP 4, VNC, LDAP, NFS, SNMP,

Network File System - RFC 1813 - http://www.ietf.org/rfc/rfc1813.txt

Virtual Private Network

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

HALF LIFE, QUAKE 3, MSN, YMSG. Pozwala na wyszukiwanie okre´slonych ci ˛

agów znaków w da-

nych TCP/UDP i porzucenie pakietu lub zamian˛e danego ci ˛

agu na inny. A tak˙ze na wysyłanie ci ˛

agów

znaków w istniej ˛

acej sesji podszywaj ˛

ac si˛e za serwer lub klienta, bez przerywania danej sesji. Pozwala

to intruzowi na wykonywanie np. polece´n jako uwierzytelniony u˙zytkownik, na co nie pozwoliłoby
np. zalogowanie hasła u˙zytkownika, je˙zeli np. u˙zywałby on haseł jednorazowych lub jakiego´s rodzaju
tokena.

3.4.2

Dost˛epne wtyczki

Przegl ˛

ad wtyczek:

# ettercap -Np list

Your IP: 192.168.11.2 with MAC: 00:A0:5C:11:22:28 on Iface:

eth0

Loading plugins...

Done.

Available Plugins :

1) arpcop v 1.0 - Report suspicious ARP activity

2) banshee v 1.5 - They kill without discretion...

3) basilisk v 1.0 - Checks if the poisoning had success

4) beholder v 1.1 - Find connections on a switched LAN

5) dummy v 2.0 - Dummy plugin.

It does nothing !

6) golem v 1.9 - nice D.O.S. BE CAREFUL !!

7) imp v 1.2 - Retrieves some Windows names

8) lamia v 1.1 - Become root of a switches spanning tree (STP)

9) leech v 2.2 - Isolate a host from the LAN

10) ooze v 1.4 - Ping a host

11) phantom v 1.6 - Sniff/Spoof DNS requests

12) shadow v 1.8 - A very simple SYN/TCP port scanner

13) spectre v 1.3 - Flood the LAN with random MAC addresses

14) triton v 2.1 - Try to discover the LAN’s gateway

3.4.3

Tryby działania

Program posiada dwa tryby działania, oparty na bibliotece ncurses tryb interaktywny, oraz tryb tek-
stowy. W trybie tekstowym, na którym si˛e skupie, nie ma mo˙zliwo´sci wprowadzenia swoich danych do
sesji TCP, ani te˙z skorzystania z „Packet Forge”, czyli łatwego wysłania dowolnego pakietu.

Spanning Tree Protocol (IEEE 802.1) - pozwala na zastosowanie zapasowych poł ˛

acze´n pomi˛edzy switchami, aktywowa-

nych w przypadku awarii innych.

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

3.4.4

Tryby podsłuchiwania

Podsłuchiwanie oparte na adresach IP

Jest to klasyczny rodzaj podsłuchu. Program po przestawieniu interfejsu sieciowego w tryb promiscous
podsłuchuje wszystkie pakiety, które pasuj ˛

a do okre´slonego filtra IP. Np. mog ˛

a by´c podsłuchiwane

wszystkie pakiety z adresem ´zródłowym A, adresem docelowym B oraz portem przeznaczenia X.

Podsłuchiwanie oparte na adresach MAC

Podsłuch bardzo podobny do powy˙zej opisanego, jednak podajemy adresy MAC adresów, które chcemy
podsłuchiwa´c. U˙zyteczne, je˙zeli znamy adres MAC karty sieciowej okre´slonego komputera, ale np.
zmienia on cz˛esto adres IP.

Podsłuchiwanie z wykorzystaniem protokołu ARP

W tym trybie interfejs sieciowy nie jest przestawiany w tryb promiscous, gdy˙z nie ma takiej potrzeby.
Po wybraniu tego trybu ettercap zidentyfikuje si˛e wobec innych dwóch komputerów, mi˛edzy którymi
ruch chcemy podsłuchiwa´c, jako odpowiadaj ˛

acy mu drugi host. Protokół ARP, aby ograniczy´c ruch w

sieci, zawsze gdy ma tak ˛

a mo˙zliwo´s´c, zapisuje odwzorowanie MAC<->IP w tablicy ARP. Zakładaj ˛

ac,

˙ze host C podsłuchuje transmisje pomi˛edzy hostami A i B. Wtedy do komputera A zostanie wysłany

pakiet, informuj ˛

acy go, ze pod adresem MAC hosta C znajduje si˛e adres IP komputera B. I odwrotnie.

W ten prosty sposób oba hosty b˛ed ˛

a przesyła´c wszystkie pakiety przez host podsłuchuj ˛

acy C. Jedynym

sposobem na stwierdzenie, ˙ze dany host jest podsłuchiwany, jest sprawdzenia zawarto´sci tablicy ARP,
czy na pewno dany IP posiada odpowiedni adres MAC. Wymaga to niestety znajomo´sci wszystkich
adresów MAC komputerów w sieci lokalnej, co wobec jej zwykle du˙zego rozmiaru i cz˛estych zmian
najcz˛e´sciej nie jest mo˙zliwe.

Przykładowe zatrucie poł ˛

aczenia mi˛edzy komputerem w sieci LAN a routerem:

# ettercap -NzJ 192.168.1.4 192.168.1.1 00:02:44:0B:7D:A1 00:01:02:AF:D7:B0

Your IP: 192.168.1.5 with MAC: 00:A0:4B:09:42:93 on Iface:

eth0

Resolving 1 hostnames...

|==================================================>| 100.00 %

Poisoning (ARP based) :

192.168.1.1:0 <-> 192.168.1.5 <-> 192.168.1.4:0

Shutting down all threads...Done.

Przebieg „zatrucia” zalogowany programem tcpdump:

# tcpdump -env arp

(...)

20:34:29.094688 0:a0:4b:9:42:93 0:2:44:b:7d:a1 0806 42:

arp reply 192.168.1.1 is-at 0:a0:4b:9:42:93

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

20:34:29.155555 0:a0:4b:9:42:93 0:1:2:af:d7:b0 0806 42:

arp reply 192.168.1.4 is-at 0:a0:4b:9:42:93

20:34:31.171643 0:a0:4b:9:42:93 0:2:44:b:7d:a1 0806 42:

arp who-has 192.168.1.4 (0:2:44:b:7d:a1) tell 192.168.1.1

20:34:31.172036 0:2:44:b:7d:a1 0:a0:4b:9:42:93 0806 60:

arp reply 192.168.1.4 is-at 0:2:44:b:7d:a1

20:34:31.190845 0:a0:4b:9:42:93 0:1:2:af:d7:b0 0806 42:

arp who-has 192.168.1.1 (0:1:2:af:d7:b0) tell 192.168.1.4

20:34:31.191134 0:1:2:af:d7:b0 0:a0:4b:9:42:93 0806 60:

arp reply 192.168.1.1 is-at 0:1:2:af:d7:b0

(...)

260 packets received by filter

0 packets dropped by kernel

W dwóch pierwszych liniach widzimy zatrucie obu komputerów fałszywym adresem MAC. W na-

st˛epnych czterech liniach host dokonuj ˛

acy zatrucia sprawdza, czy zatrucie było udane. Sprawdza, czy

host A poproszony o odpowied´z przez host „B” o adres MAC, odpowie na adres MAC sfałszowany, czy
te˙z prawidłowy.

Istnieje mo˙zliwo´s´c modyfikacji tego scenariusza, aby zatru´c wszystkie tablice odwzorowa´n MAC<-

>IP w sieci lokalnej. W tym celu rozsyła si˛e sfałszowany adres odwzorowuj ˛

acy adres IP ofiary na adres

MAC komputera podsłuchuj ˛

acego do ka˙zdego komputera w sieci lokalnej. Mo˙zna zastosowa´c tak˙ze

wysłanie takiego komunikatu na adres rozgłoszeniowy, lecz wtedy ofiara mo˙ze wykry´c konflikt adresów
IP. W przypadku, je˙zeli ofiar ˛

a b˛edzie adres routera, przez host podsłuchuj ˛

acy przechodzi´c b˛edzie cały

ruch wychodz ˛

acy/wchodz ˛

acy do sieci, lub w przypadku u˙zycia do zatrucia adresu rozgłoszeniowego,

tylko ruch wychodz ˛

acy.

3.4.5

Opcje programu, przykładowe u˙zycie

Najcz˛e´sciej wykorzystywane opcje programu to:

• -a, --arpsniff Podsłuchiwanie oparte na protokole ARP

• -s, --sniff Podsłuchiwanie oparte na adresach IP

• -m, --macsniff Podsłuchiwanie oparte na adresach MAC

• -N, --simple Wł ˛

acza interfejs tekstowy

• -z, --silent Tryb cichy, nie zbiera wszystkich adresów MAC przy starcie

• -d, --dontresolve Nie rozwi ˛

azuje nazw komputerów w sieci

• -t, --proto Podsłuchuje tylko wybrany protokół, domy´slnie jest to TCP+UDP

• -J, --onlypoison Tylko zatruwa hosty, przydatne np. gdy wła´sciwy podsłuch b˛edzie wykony-

wany innym narz˛edziem, np. tcpdump.

ROZDZIAŁ 3. SNIFFERY - U ˙

ZYWANIE I WYKRYWANIE

• -l, --list Wy´swietla adresy MAC wszystkich komputerów w sieci

• -C, --collect Zbiera wszystkie pary u˙zytkownik/hasło z okre´slonego komputera korzystaj ˛

ac z

okre´slonych w pliku konfiguracyjnym protokołów.

• -w, --newcert Generuje nowy plik certyfikatu dla poł ˛

acze´n HTTPS, jest on u˙zywany w klasycz-

nym ataku man-in-the-middle

• -c, --check Sprawdza, czy kto´s w sieci nie „zatruwa” protokołu ARP

3.5

Wykorzystanie w celu analizy stanu sieci

Narz˛edzie to ma tak˙ze kilka cech przydatnych przy administracji sieci ˛

a komputerow ˛

a. Pozwala m.in.

na kontrol˛e jako´sci haseł u˙zywanych przez u˙zytkowników, je˙zeli musz ˛

a oni z jakichkolwiek powodów

korzysta´c z usług nieszyfrowanych.

Znacznie bardziej przydatn ˛

a cech ˛

a jest łatwa mo˙zliwo´s´c przekierowania na stacj˛e zarz ˛

adzaj ˛

ac ˛

a ru-

chu pochodz ˛

acego od danego hosta, w celu analizy, bez uciekania si˛e do rozwi ˛

aza´n sprz˛etowych, typu

konfiguracja portu switcha w tryb span, co ma negatywny wpływ na wydajno´s´c sieci.

Atak ten polega na wyst ˛

apieniu w roli po´srednika dla poł ˛

aczenia u˙zytkownika z serwerem. W tym wypadku, u˙zytkow-

nik ł ˛

aczy si˛e z po´srednikiem, i je˙zeli zaakceptuje certyfikat, nawi ˛

a˙ze z nim poł ˛

aczenie szyfrowane SSL. Po´srednik nast˛epnie

poł ˛

aczy si˛e z wła´sciwym serwerem, koduj ˛

ac z powrotem dane otrzymane od u˙zytkownika i po´srednicz ˛

ac w przegl ˛

adaniu szy-

frowanej strony WWW. U po´srednika pozostaj ˛

a zalogowane wszystkie informacje, jakie przekazał u˙zytkownik w czasie sesji z

serwerem, w dobie powszechnych sklepów internetowych i akceptacji płatno´sci za pomoc ˛

a karty kredytowej jest to szczególnie

gro´zne.

Rozdział 4

Firewalle, ich rodzaje i zastosowanie

4.1

Opis

Firewall[3, 10, 11, 8], czasami nazywany ´scian ˛

a ogniow ˛

a, jest to system, zbudowany na bazie kompu-

tera z odpowiednio skonfigurowanym systemem operacyjnym lub ju˙z gotowe urz ˛

adzenie, które wymaga

tylko konfiguracji. Rozwi ˛

azania sprz˛etowe, jako dedykowane do pełnienia tej funkcji, s ˛

a z reguły wydaj-

niejsze, i maj ˛

a wi˛ecej mo˙zliwo´sci, ni˙z rozwi ˛

azania bazuj ˛

ace na wolnodost˛epnych systemach, takich jak

rodzina systemów BSD, czy Linux. Na uwag˛e zasługuje fakt, ˙ze bardzo cz˛esto jako system operacyjny
w systemach „zamkni˛etych”, tj. tzw. black-box’ach, u˙zywany jest system z rodziny BSD, gdy˙z u˙zywana
przez nie licencja na oprogramowanie, dopuszcza mo˙zliwo´s´c modyfikacji kodu, i nie wymaga udost˛ep-
nienia tak zmodyfikowanego kodu. W naszym przykładzie opr˛e si˛e o system Linux, w wersji 2.4.x,
gdy˙z posiada on bardzo elastyczne mo˙zliwo´sci konfiguracji reguł firewalla, opartego na IPTables[13].
Przykład ten oparty b˛edzie na istniej ˛

acej sieci, gdzie został on zastosowany praktycznie.

4.2

Techniki skanowania sieci

Aby´smy wiedzieli, przed czym si˛e bronimy, musimy pozna´c wroga, czyli wiedzie´c jakich sposobów
u˙zywaj ˛

a intruzi do poznania naszej sieci. Mo˙zna zada´c sobie pytanie, przed czym si˛e broni´c lub w jakim

celu? Skanowanie jest z reguły pierwszym krokiem przed dokonaniem próby ingerencji we wn˛etrze
sieci. Ma za zadanie odkrycie przed intruzem jej struktury i rozmieszczenia usług. Zbadanie, na jakich
systemach operacyjnych s ˛

a one uruchomione. Czy ich wersje nie s ˛

a podatne na znane przez intruza

bł˛edy. Jednym słowem, maja dostarczy´c tak wiele jak si˛e da o atakowanej sieci.

4.2.1

Znajdowanie aktywnych, u˙zywanych numerów IP

W pierwszym kroku musimy si˛e dowiedzie´c, jakimi zakresami numerów IP dysponuje dana organiza-
cja. Mo˙zemy w tym celu skorzysta´c np. z bazy WHOIS

. Mo˙zemy tak˙ze spróbowa´c transferu strefy

DNS z domen ˛

a organizacji, jednak bardzo rzadko b˛edzie to operacja uwie´nczona sukcesem, na popraw-

nie skonfigurowanym serwerze DNS nie powinien by´c mo˙zliwy transfer stref, z wyj ˛

atkiem transferów

inicjowanych z adresów serwerów zapasowych. Musimy si˛e teraz dowiedzie´c jakie aktualnie hosty s ˛

aktywne. Najpro´sciej mo˙zemy dokona´c tego poprzez ping ICMP. Przykładowe wykorzystanie do tego
celu nmap:

RIPE whois.ripe.net, ARIN whois.arin.net, APNIC whois.apnic.net

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

root@localhost:˜# nmap -n -sP 192.168.11.0/24

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )

Host (192.168.11.0) seems to be a subnet broadcast address (returned 3 extra

pings).

Host (192.168.11.1) appears to be up.

Host (192.168.11.2) appears to be up.

Host (192.168.11.4) appears to be up.

...

Host (192.168.11.254) appears to be up.

Host (192.168.11.255) seems to be a subnet broadcast address (returned 4

extra pings).

Nmap run completed - 256 IP addresses (167 hosts up) scanned in 14 seconds

Jednak jest to bardzo mało wiarygodna metoda, gdy˙z protokół ICMP bardzo cz˛esto bywa filtrowany, i
pakiety wchodz ˛

ace do sieci, lub z niej wychodz ˛

ace nie s ˛

a przepuszczane. Gdy zablokujemy takie ko-

munikaty, jak „Echo Request”, „Timestamp Request”, „Information Request”, „Address Mask Request”
utrudnimy próby skanowania naszej przykładowej sieci. Jednak wci ˛

a˙z pozostaje atakuj ˛

acemu protokół

UDP oraz TCP. Na pakiet UDP wysłany na port aktywnego IP, na którym nie nasłuchuje ˙zadna usługa,
powinni´smy dosta´c ICMP „Port Unreachable”. Jednak z uwagi na fakt, ˙ze wi˛ekszo´s´c firewalli/bramek
filtruje protokół UDP do´s´c mocno, mo˙ze by´c to utrudnione. Port 53/DNS daje nam pewn ˛

a szans˛e, jednak

gdy trafimy na uruchomiony na danym ho´scie serwer DNS, tak˙ze nie dostaniemy odpowiedzi. Tak wi˛ec
wyfiltrowanie całego niepotrzebnego ruchu UDP daje nam w tym momencie du˙ze szanse na pozostanie
w ukryciu przed osobami próbuj ˛

acymi pozna´c nasz ˛

a sie´c.

4.2.2

Wykorzystanie protokołu TCP

Pozostał nam protokół TCP. Jak wiadomo, jest to protokół poł ˛

aczeniowy.

SYN skan

Sesja zaczyna si˛e od wysłania przez komputer nawi ˛

azuj ˛

acy połaczenie pakietu z ustawion ˛

a flag ˛

a SYN, na

która komputer b˛ed ˛

acy po drugiej stronie poł ˛

aczenia odpowiada pakietem z ustawionymi flagami SYN

i ACK. Flaga ACK potwierdza pakiet poprzednio odebrany od komputera nawi ˛

azuj ˛

acego poł ˛

acznie. W

odpowiedzi na pakiet SYN odebrany od hosta B, host A odpowiada pakietem z flag ˛

a ACK, potwierdzaj ˛

odebranie pakietu. Jest to tzw. pełne otwarcie. Jest ono najłatwiejsze do wykrycia przez oprogramowanie
monitoruj ˛

ace. Półotwarte poł ˛

aczenie jest trudniejsze do wykrycia, gdy˙z w odpowiedzi na wysłany w

odpowiedzi z hosta B pakiet SYN+ACK, host A wysyła pakiet z flag ˛

a RST, zrywaj ˛

ac tym samym jeszcze

nie nawi ˛

azane poł ˛

aczenie.

Te i nast˛epne rodzaje skanów mog ˛

a zosta´c bardziej ukryte, je˙zeli zostanie wł ˛

aczona opcja fragmen-

tacji pakietów, pakiety testowe s ˛

a dzielone na wiele poszczególnych fragmentów, miedzy które jest roz-

dzielony nagłówek TCP. Sprawia to, ˙ze jest to trudniejsze do wykrycia przez filtry pakietów, szczególnie,
je´sli nie kolejkuj ˛

a one otrzymanych pakietów, aby je zanalizowa´c po otrzymaniu cało´sci. W niektórych

sieciach takie składanie pakietów mogłoby mie´c znacz ˛

acy wpływ na wydajno´s´c, wi˛ec nie jest stosowane.

W systemie Linux odpowiada za to opcja CONFIG_IP_ALWAYS_DEFRAG.

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

Innym rodzajem jest skanowanie bez wysyłania pocz ˛

atkowego pakietu SYN, gdy˙z wiele firewalli jest

skonfigurowanych do logowania tylko pakietów SYN przychodz ˛

acych na okre´slone porty, wi˛ec istnieje

szansa, ˙ze próba pozostanie niezauwa˙zona. Według RFC

na dowolny pakiet wysłany na port na którym

nie słucha ˙zadna usługa, system operacyjny powinien odpowiedzie´c pakietem RST, natomiast przycho-
dz ˛

acy na port otwarty, zignorowa´c. Ro˙zne rodzaje skanów wykorzystuj ˛

a ró˙zne ustawienia flag, typowe

to np. FIN, FIN+URG+PUSH, lub nie maj ˛

a ˙zadnych. Nosz ˛

a one nazw˛e kolejno FIN scan, Xmas-tree

scan, Null scan. Jednak nie wszystkie systemy operacyjne zachowuj ˛

a si˛e w ten sposób. Wyj ˛

atkiem s ˛

m.in. produkty firmy Microsoft, Cisco, systemy HP/UX, IRIX i inne.

ACK skan

Jednym z mo˙zliwo´sci zbadania, czy mamy do czynienia z firewallem pami˛etaj ˛

acym stan poł ˛

aczenia czy

tez prostym filtrem pakietów, który blokuje jedynie pakiety z ustawion ˛

a flaga SYN, jest tzw. ACK scan.

Polega on na wysłaniu pakietu z ustawion ˛

a flag ˛

a ACK, z losowym numerem sekwencyjnym. Je˙zeli nie

dostaniemy odpowiedzi na nasz pakiet, mo˙zemy przyj ˛

a´c, ze port jest filtrowany. Porównanie z wynikiem

np. normalnego skanu SYN, mo˙ze nam da´c odpowied´z na pytanie co do rodzaju firewalla.

IdleScan

Bardzo ciekawym rodzajem skanowania jest tzw. IdleScan. Wykorzystuje on host po´srednicz ˛

acy, jest

tym samym najbardziej trudny do wykrycia. Samo wykrycie faktu skanowania z jakiego´s adresu IP nie
kieruje nas na rzeczywiste zagro˙zenie, wykrywamy tylko komputer po´srednicz ˛

acy. Ma to tak˙ze du˙ze

znaczenie dla ustalenia reguł zaufania, jakie ma firewall, gdy˙z wykorzystuj ˛

ac po´srednika, w rzeczywi-

sto´sci badamy sie´c od jego strony, a mo˙ze by´c to „zaufany” host, z którego np. jest wi˛ekszy dost˛ep
do sieci. W takim przypadku, atakuj ˛

acy mo˙ze zechcie´c najpierw zaatakowa´c po´srednika, aby dopiero z

niego spróbowa´c dosta´c si˛e do „ufaj ˛

acej”mu sieci. Ide ˛

a skanu jest wykorzystanie faktu, i˙z w wi˛ekszo´sci

przypadków mo˙zemy przewidzie´c kolejny IPID pakietu wygenerowanego przez po´srednika. Wysyłamy
mu pakiet z sfałszowanym adresem ´zródłowym, b˛ed ˛

acym adresem ofiary, odsyła on odpowied´z na sfał-

szowany adres, i dostaje z niego, lub nie, odpowied´z. Je´sli komputer po´srednicz ˛

acy nie jest obci ˛

a˙zony

ruchem, wysyłaj ˛

ac mu pakiet, mo˙zemy sprawdzi´c, pakietem z jakim IPID nam odpowie, i na tej podsta-

wie oceni´c, czy host docelowy odpowiedział naszemu po´srednikowi, czy nie. Musi by´c to jednak˙ze host
słabo obci ˛

a˙zony ruchem, generuj ˛

acy w sposób przewidywalny numer IPID.

Ident skan

Protokół ident

zezwala na sprawdzenie, z prawami jakiego u˙zytkownika działa, nawet je´sli proces nie

inicjował poł ˛

aczenia.

root@localhost:˜# nmap -I 192.168.11.245

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

Interesting ports on 192.168.11.245

(192.168.11.245):

(The 1539 ports scanned but not shown below are in state:

closed)

Port State Service Owner

RFC 793 - http://www.ietf.org/rfc/rfc0793.txt

RFC 1413 - http://www.ietf.org/rfc/rfc1413.txt

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

21/tcp open ftp nobody

22/tcp open ssh root

25/tcp open smtp root

53/tcp open domain root

80/tcp open http www-data

113/tcp open auth

119/tcp open nntp root

587/tcp open submission root

3128/tcp open squid-http proxy

5432/tcp open postgres postgres

Nmap run completed - 1 IP address (1 host up) scanned in 3 seconds

Jak mo˙zemy stwierdzi´c, pozwala to atakuj ˛

acemu na poznanie, z jakimi prawami działaj ˛

a poszcze-

gólne usługi, tym samym wskazuj ˛

ac, które z nich ewentualnie mog ˛

a by´c atrakcyjne ze wzgl˛edu na mo˙z-

liwo´s´c uzyskania wi˛ekszych praw w systemie, tym samym zasługuj ˛

ac na wi˛eksze zainteresowanie. Jed-

nak nie nale˙zy pochopnie wył ˛

acza´c tej usługi, gdy˙z pozwala ona np. sprawdzi´c usłudze zdalnej, jaki

u˙zytkownik ł ˛

aczył si˛e z ni ˛

a, co bezpo´srednio prowadzi do niego w przypadku dokonania przez niego

nadu˙zycia.

FTP bounce skan

FTP bounce scan - protokół FTP zgodnie z dokumentem „RFC 959”

pozwala na przekazanie serwerowi

FTP, gdzie i na jaki port powinien wysła´c ˙z ˛

adane przez nas dane. Pozwala pozwala to na skanowanie

sieci przy u˙zyciu serwera po´srednicz ˛

acego, a nawet je´sli posiada on np. katalog /incoming, na którym

mo˙zemy zapisywa´c i odczytywa´c z niego pliki, na transfer dowolnych danych na dowolny port w całej
sieci. W szczególno´sci, je´sli serwer FTP znajduje si˛e w sieci prywatnej firmy, pozwala to na skanowa-
nie sieci, które normalnie nie byłoby mo˙zliwe, np. ze wzgl˛edu na firewall obecny przed serwerem ftp.
Oprócz samego skanowania, jest to powa˙zna dziura w zabezpieczeniu, gdy˙z pozwala tak˙ze na całkowi-
cie anonimowe wysyłanie np. maili, wiadomo´sci news, lub wykorzysta´c do obci ˛

a˙zenia ł ˛

acz serwerów,

czyli do ataku DoS. Obecnie wi˛ekszo´s´c serwerów nie zezwala w domy´slnej konfiguracji na wykonanie
poł ˛

aczenia na adres IP inny ni˙z adres klienta do niego podł ˛

aczonego.

4.3

Rodzaje i ró˙znice pomi˛edzy ró˙znymi rodzajami firewalli.

Klasycznym najprostszy firewall posiada mo˙zliwo´s´c sprawdzania pakietów „w locie”, tzn. w przypadku
TCP/IP mo˙ze analizowa´c adres przeznaczenia, adres ´zródła, port przeznaczenia i ´zródła, ustawione flagi,
czy pakiet jest sfragmentowany, czy nie. Natomiast nie ma ˙zadnej mo˙zliwo´sci czy nale˙zy on do ju˙z
istniej ˛

acego poł ˛

aczenia. Otwiera to pole do licznych nadu˙zy´c, gdy˙z np. intruz wysyłaj ˛

ac pakiety z usta-

wionym portem ´zródłowym np. 80 bez problemu powinien przej´s´c przez firewall. Port 80 najcz˛e´sciej jest
otwarty dla poł ˛

acze´n z zewn ˛

atrz, co daje wolne pole do działania intruzowi, mo˙zliwo´s´c blokady przy-

chodz ˛

acych pakietów z ustawion ˛

a flag ˛

a SYN nie zmienia sytuacji, nie stanowi to wi˛ekszego utrudnienia

w przeprowadzeniu przez intruza rozpoznania naszej sieci. A niestety jest to kres mo˙zliwo´sci filtrowania
prostych filtrów pakietów. . . Dlatego, je˙zeli tylko mamy takie mo˙zliwo´sci, nale˙załoby u˙zywa´c firewalli

RFC 959 - http://www.ietf.org/rfc/rfc0959.txt

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

które analizuj ˛

a stan poł ˛

acze´n, tzw. state-ful. Oczywi´scie nie zawsze jest to mo˙zliwe, w przypadku sieci

o bardzo du˙zym pa´smie, wymagania co do sprz˛etu pełni ˛

acego role firewalla s ˛

a do´s´c du˙ze, cz˛esto lepiej

jest wydzieli´c tylko cz˛e´s´c ruchu, jaka b˛edzie przechodzi´c przez filtr, reszt˛e za´s filtrowa´c prostym filtrem
pakietów.

W procesie budowania reguł filtrowania, najlepsze efekty daje polityka: „co nie jest jawnie dozwo-

lone, jest zabronione”. Pami˛eta´c o tym nale˙zy zwłaszcza obecnie, gdy na komputer znajduj ˛

acy si˛e w

sieci wewn˛etrznej bez problemy mo˙ze przenikn ˛

a´c wirus lub trojan, przemycony np. w przesyłce e-mail.

Cz˛esto wykorzystuj ˛

a one własne mechanizmy przesyłania si˛e dalej, wi˛ec nale˙zy o tym pami˛eta´c, i unie-

mo˙zliwi´c im to w miar˛e mo˙zliwo´sci. Drobnym przykładem mo˙ze by´c np. zabronienie ł ˛

aczenia si˛e na

zewn ˛

atrz sieci na port 25, i wymuszenie u˙zywania jako serwera przekazuj ˛

acego poczt˛e e-mail dalej w

´swiat, wewn˛etrznego serwera firmy, na którym mo˙ze działa´c skaner antywirusowy, sprawdzaj ˛

acy cał ˛

wychodz ˛

ac ˛

a poczt˛e.

Dobra metod ˛

a zbadania, co musimy wypuszcza´c w ´swiat, zwłaszcza, gdy instalujemy filtr pakietów

dla działaj ˛

acej sieci, i nie mo˙zemy sobie pozwoli´c na dłu˙zszy przestój, jest zastosowanie reguł loguj ˛

acych

aktualny ruch. Po sprawdzeniu danego wpisu, je˙zeli dojdziemy do wniosku, ˙ze dany ruch nie jest niepo-

˙z ˛

adany, np. jest to przegl ˛

adanie stron WWW, lub ´sci ˛

aganie poczty za pomoc ˛

a protokołu SPOP-3, czyli

POP3 zabezpieczonego poprzez SSL, dopisujemy dan ˛

a reguł˛e przepuszczaj ˛

ac ˛

a. Przy zasadzie, ˙ze pierw-

sza odpowiadaj ˛

aca reguła ma zastosowanie, i maj ˛

ac reguł˛e loguj ˛

ac ˛

a na ko´ncu, w pewnym momencie

doprowadzamy do sytuacji, ˙ze do logów trafiaj ˛

a tylko anomalie i ruch niepo˙z ˛

adany, a wszystkie pakiety,

które pasuj ˛

a nam do naszych reguł, s ˛

a przepuszczane. Je˙zeli projektujemy filtr dla przyszłej, jeszcze nie

działaj ˛

acej sieci, mo˙zemy bez problemów podej´s´c do zagadnienia od strony teoretycznej, i po stworzeniu

wzorcowego zestawu reguł, rozbudowa´c go odpowiednio, zgodnie z istniej ˛

acymi potrzebami.

4.4

Przykłady u˙zycia filtru iptables

W nowej stabilnej wersji j ˛

adra Linuxa, z serii 2.4.x, która oficjalnie ujrzała ´swiatło dzienne 1 stycznia

2001 roku, mamy do dyspozycji nowy filtr, iptables, nast˛epce ipchains z serii 2.2.x i ipfwadm z 2.0.x.
Jest to uniwersalne narz˛edzie do filtrowania pakietów, translacji adresów, oraz modyfikacji pakietów.

4.4.1

Konfiguracja, kompilacja i instalacja j ˛

adra systemu Linux

Proces konfiguracji, kompilacji i instalacji nowego j ˛

adra systemu Linux jest łatwy i prosty. Najwa˙zniej-

sz ˛

a rzecz ˛

a jak ˛

a b˛edziemy potrzebowa´c s ˛

a ´zródła j ˛

adra, oraz kilka dodatkowych programów, takich jak

„make”, kompilator „gcc” i kilka innych. Z serwera ftp://ftp.kernel.org mo˙zemy pobra´c aktualne archi-
wum z j ˛

adrem linuxa. W rozwoju j ˛

adra systemu Linux zachowana jest zasada, ˙ze wersje stabilne j ˛

adra

posiadaj ˛

a jako drugi numer wersji liczb˛e parzyst ˛

a. Np. 2.4.18 jest j ˛

adrem z linii stabilnej, natomiast np.

2.5.19 jest j ˛

adrem z linii rozwojowej.

Aby sprawdzi´c jaka aktualnie jest najnowsza wersja j ˛

adra, mo˙zemy u˙zy´c polecenia „finger”.

$ finger @zeus.kernel.org

[zeus.kernel.org]

The latest stable version of the Linux kernel is:

2.4.18

The latest prepatch for the stable Linux kernel tree is:

2.4.19-pre9

The latest beta version of the Linux kernel is:

2.5.19

The latest prepatch for the beta Linux kernel tree is:

2.5.8-pre3

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

The latest 2.2 version of the Linux kernel is:

2.2.21

The latest prepatch for the 2.2 Linux kernel tree is:

2.2.21-rc4

The latest 2.0 version of the Linux kernel is:

2.0.39

The latest prepatch for the 2.0 Linux kernel tree is:

2.0.40-rc4

The latest -ac patch to the stable Linux kernels is:

2.4.19-pre9-ac2

The latest -dj patch to the beta Linux kernels is:

2.5.18-dj1

Jak mo˙zemy zauwa˙zy´c, najnowsz ˛

a stabiln ˛

a wersj ˛

a jest 2.4.18. Po pobraniu pliku ze ´zródłami j ˛

adra,

rozpakowujemy je w wybranym przez nas miejscu, maj ˛

ac jednak na uwadze, ˙ze tradycyjnym miejscem

na nie jest katalog /usr/src/linux. Po wydaniu polecenia tar -zxf linux-2.4.18.tar.gz w kata-
logu /usr/src otrzymamy rozpakowane ´zródła Linuxa. Nast˛epnie wchodzimy do katalogu, i wydajemy
konfigurujemy j ˛

adro. Mo˙zemy to zrobi´c na kilka sposobów. Je˙zeli posiadamy ju˙z plik konfiguracyjny,

np. ze starszej wersji j ˛

adra, wystarczy ˙ze wydamy polecenia make oldconfig po uprzednim skopio-

waniu do katalogu ze ´zródłami starego pliku .config. Je˙zeli w nowym j ˛

adrze jest mo˙zliwo´s´c skonfi-

gurowania nowych opcji, których nie ma w naszym starym pliku konfiguracyjnym, dana nam zostanie
mo˙zliwo´s´c ich wyboru. Je˙zeli konfigurujemy j ˛

adro, a nie posiadamy przykładowego pliku konfiguracyj-

nego, mamy do wyboru trzy interfejsy konfiguracyjne. Jednym z nich jest make config, który podob-
nie jak make oldconfig proponuje nam ró˙zne mo˙zliwo´sci do wyboru. Bardzo wygodnym interfejsem
jest make menuconfig, który uruchamia konfigurator napisany z pomoc ˛

a biblioteki ncurses. Wymaga

posiadania tej biblioteki zainstalowanej w systemie. Pozostaje jeszcze make xconfig który do pracy
wymaga uruchomienia serwera X Windows. Wymaga on bibliotek Tcl/Tk. Po skonfigurowaniu kernela,
aby go skompilowa´c, potrzebowa´c b˛edziemy oprogramowanie, którego list˛e, wraz z wymaganymi wer-
sjami, znajdziemy w Documentation/Changes. Jest to szczególnie wa˙zne je´sli chodzi o kompilator,
gdy˙z niektóre jego wersje znane s ˛

a z niepoprawnego generowania kodu j ˛

adra.

Po skonfigurowaniu pozostaje nam wyda´c polecenia make dep, make bzImage, i je˙zeli u˙zywamy

j ˛

adra zmodularyzowanego, tak˙ze make modules, make modules_install

. Po zalogowaniu si˛e na

konto administratora, nale˙zy jeszcze przekopiowa´c plik System.map do katalogu /boot/ i zmieni´c mu
nazw˛e na System.map-wersja-j ˛

adra

, czyli np. /boot/System.map-2.4.18. Kopiujemy tak˙ze plik

arch/i386/boot/bzimage

w odpowiadaj ˛

ace nam miejsce, np. do katalogu /boot/ i dopisujemy go do

u˙zywanego przez nas bootloadera.

U˙zytkownicy dystrybucji Debian powinni zamiast powy˙zszych kroków po skonfigurowaniu j ˛

adra

u˙zy´c pakietu kernel-package, i pochodz ˛

acego z niego narz˛edzia make-kpkg. Po wydaniu polecenia

make-kpkg binary_image

z ewentualnymi opcjami, zostanie zbudowany pakiet .deb, który mo˙zemy

zainstalowa´c po zalogowaniu si˛e na konto administratora.

4.4.2

Konfiguracja wsparcia Netfilter w j ˛

adrze systemu Linux

Aby u˙zywa´c pakietu iptables, musimy posiada´c wsparcie dla niego w j ˛

adrze Linuxa. Odpowiada za to

opcja konfiguracyjna CONFIG_NETFILTER. Wybieraj ˛

ac j ˛

a, mo˙zemy wybra´c nast˛epnie wiele opcji doty-

cz ˛

acych wsparcia dla poszczególnych elementów filtru.

CONFIG_IP_NF_CONNTRACK

´Sledzenie poł ˛acze´n, pakiety s ˛a zapami˛etywane, gdy przechodz ˛a przez

hosta. Jest to wymagane dla NAT oraz modułu dopasowuj ˛

acego pakiety na podstawie przynale˙z-

no´sci do poł ˛

aczenia.

Musimy by´c zalogowanii jako u˙zytkownik z UID=0, aby ta operacja odniosła skutek

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

Rysunek 4.1: Konfiguracja Netfilter w j ˛

adrze

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

CONFIG_IP_NF_FTP

Wsparcie ´sledzenia poł ˛

acze´n dla protokołu FTP, w osobnym module ze wzgl˛edu

na jego specyfik˛e

. Moduł musi zmodyfikowa´c wskutek tego nie tylko adres ´zródłowy/docelowy

pakietów, ale tak˙ze ich zawarto´s´c.

CONFIG_IP_NF_IRC

Wsparcie ´sledzenia poł ˛

acze´n dla protokołu IRC, wymagane, aby podczas u˙zy-

wania NAT działały poł ˛

aczenia DCC.

CONFIG_IP_NF_QUEUE

Wsparcie dla skierowania pakietu do przestrzeni u˙zytkownika, aby tam za

pomoc ˛

a specjalnego urz ˛

adzenia netlink uzyska´c do nich dost˛ep.

CONFIG_IP_NF_IPTABLES

Wła´sciwe wsparcie dla iptables, mo˙zliwe jest tak˙ze wybranie wsparcia

dla poprzedniej wersji narz˛edzi, czyli ipfwadm czy ipchains, ale jest to zachowane jedynie w celu
kompatybilno´sci ze starymi skryptami opartymi na tych starszych programach. Nie mog ˛

a by´c

u˙zywane równocze´snie.

CONFIG_IP_NF_MATCH_LIMIT

Bardzo u˙zyteczny moduł słu˙z ˛

acy do limitowania ilo´sci pakietów,

zwłaszcza w poł ˛

aczeniu z z celem LOG, lub je˙zeli istnieje potrzeba limitowania ilo´sci pakietów,

jaka przechodzi przez nasz filtr, np. ilo´s´c przepuszczanych ICMP „Echo Request”.

CONFIG_IP_NF_MATCH_MAC

Dopasowuje pakiet na podstawie ´zródłowego adresu Ethernet.

CONFIG_IP_NF_MATCH_MARK

Pozwala na dopasowanie pakietu zaznaczonego wcze´sniej przez cel

MARK.

CONFIG_IP_NF_MATCH_MULTIPORT

Pozwala na podawanie wielu zakresów portów dla reguły,

normalnie mo˙zliwe jest podanie co najwy˙zej jednego zakresu portów.

CONFIG_IP_NF_MATCH_TOS

Dopasowuje pakiet na podstawie pola TOS

CONFIG_IP_NF_MATCH_AH_ESP

Dotyczy pakietów IPSec.

CONFIG_IP_NF_MATCH_LENGTH

Pozwala na dopasowanie pakietu ze wzgl˛edu na jego długo´s´c.

CONFIG_IP_NF_MATCH_TTL

Dopasowuje pakiet na podstawie zawarto´sci pola TTL

CONFIG_IP_NF_MATCH_TCPMSS

Dopasowanie na podstawie pola MSS

okre´slaj ˛

acego maksymalny

rozmiar pakietów.

CONFIG_IP_NF_MATCH_STATE

Pozwala na dopasowanie pakietu w zale˙zno´sci od tego, czy jest w

jaki´s sposób powi ˛

azany z podobnymi poprzednimi pakietami, np. nale˙z ˛

acymi do tego samego

poł ˛

aczenia TCP.

CONFIG_IP_NF_MATCH_UNCLEAN

Dopasowuje wszystkie „dziwne” pakiety, nie jest wskazane wł ˛

czanie go na pocz ˛

atku ła´ncucha reguł, nie zawsze zdarza mu si˛e poprawnie pracowa´c.

CONFIG_IP_NF_MATCH_OWNER

Pakiet jest dopasowywany na podstawie lokalnego uid, gid, pid, sid

lub nazwy polecenia, z jakiego został wysłany. Pozwala to na blokowanie dost˛epu dla konkretnych
u˙zytkowników, usług.

FTP - wyró˙zniamy dwa rodzaje poł ˛

acze´n, aktywne i pasywne. W trybie pasywnym serwer podaje klientowi, z jakiego

IP:portu ma odbiera´c dane, w trybie aktywnym klient podaje do serwera, na jaki IP:port ma przesyła´c dane.

TOS - Type of Service

TTL - Time To Live

Maximum Segment Size

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

CONFIG_IP_NF_FILTER

Zasadniczy filtr pakietów. Udost˛epnia domy´sln ˛

a tabel˛e „filter”.

CONFIG_IP_NF_TARGET_REJECT

Udost˛epnia cel REJECT, pozwalaj ˛

acy na zwrócenie komunikatu

ICMP lub pakietu TCP RST, zamiast cichego upuszczenia pakietu.

CONFIG_IP_NF_TARGET_MIRROR

Cel, pozwalaj ˛

acy na zwrócenie pakietu nadawcy.

CONFIG_IP_NF_NAT

Pełny NAT, pozwala na zrobienie maskarady, przekierowania poł ˛

acze´n, udo-

st˛epnia tablice „nat”.

CONFIG_IP_NF_TARGET_MASQUERADE

Specjalny przypadek NAT, u˙zyteczny tylko je´sli u˙zywamy

dynamicznego adresu IP, w innym przypadku nale˙zy u˙zywa´c SNAT

CONFIG_IP_NF_TARGET_REDIRECT

Dodaje cel REDIRECT, pakiety przychodz ˛

ace s ˛

a mapowane

na adres interfejsu wej´sciowego, zamiast przej´s´c przez bramk˛e. U˙zyteczne przy prze´zroczystym
(transparent) proxy.

CONFIG_IP_NF_MANGLE

Dodaje tablic˛e „mangle” słu˙z ˛

ac ˛

a do modyfikacji pakietów. Modyfikacje te

mog ˛

a słu˙zy´c np. do zmiany na ich podstawie trasy routingu dla nich.

CONFIG_IP_NF_TARGET_TOS

Dodaje cel TOS, słu˙z ˛

acy w tablicy „mangle” do modyfikacji pola

TOS pakietów.

CONFIG_IP_NF_TARGET_MARK

Dodaje cel MARK, słu˙z ˛

acy w tablicy „mangle” do oznaczania pa-

kietów, mo˙ze mie´c wpływ na routing.

CONFIG_IP_NF_TARGET_LOG

Cel LOG, loguje nagłówek pakietu przez sysloga.

CONFIG_IP_NF_TARGET_ULOG

Dodaje cel ULOG, umo˙zliwiaj ˛

acy logowanie za pomoc ˛

a progra-

mów działaj ˛

acych w przestrzeni u˙zytkownika.

CONFIG_IP_NF_TARGET_TCPMSS

Cel TCPMSS pozwala na zmniejszenie MSS dla pakietów, wy-

magane w przypadku złej konfiguracji niektórych routerów, blokuj ˛

acych pakiety ICMP „Fragmen-

tation Needed”.

4.4.3

Sposób u˙zycia iptables, składnia

IPTables u˙zywaj ˛

a poj˛ecia tablicy oraz ła´ncuchów. Tablice sprawiaj ˛

a, ˙ze za pomoc ˛

a iptables mo˙zemy

modyfikowa´c wiele rzeczy, sprawiaj ˛

a, i˙z jest to uniwersalne narz˛edzie. Je˙zeli nie podajemy tablicy,

domy´slnie działamy na tablicy „filter”. Tablica „nat” słu˙zy do obsługi Network Address Translation,
czyli tłumaczenia/zmiany adresów sieciowych przy przechodzeniu pakietów przez bramk˛e, natomiast
tablica „mangle” słu˙zy do modyfikacji pakietów. W ka˙zdej tabeli s ˛

a standardowo trzy ła´ncuchu, INPUT,

OUTPUT i FORWARD. Przepływ pakietów przedstawia poni˙zszy rysunek:

Aby zrozumie´c przykładowy skrypt i potrafi´c napisa´c własny, niezb˛edna jest znajomo´s´c składni.

U˙

zycie:

iptables -[ADC] chain rule-specification [options]

iptables -[RI] chain rulenum rule-specification [options]

iptables -D chain rulenum [options]

iptables -[LFZ] [chain] [options]

SNAT - Source Network Address Translation

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

Rysunek 4.2: Przepływ pakietów w j ˛

adrze 2.4.x

iptables -[NX] chain

iptables -E old-chain-name new-chain-name

iptables -P chain target [options]

iptables -h (print this help information)

Polecenia, zarówno długie jak i krótkie opcje s ˛

a dozwolone. Opcje podane pomi˛edzy znakami [ ]

s ˛

a opcjonalne.

• --append -A chain doł ˛

acz reguł˛e do ła´ncucha

• --delete -D chain usuwa pasuj ˛

ac ˛

a reguł˛e z ła´ncucha

• --delete -D chain numer usuwa reguł˛e o danym numerze z ła´ncucha

• --insert -I chain [numer] wstawia reguł˛e w okre´slone miejsce

• --replace -R chain [numer] zamienia reguł˛e

• --list -L [chain] wypisuje reguły z danego ła´ncucha, domy´slnie wszystkie

• --flush -F [chain] czy´sci cały ła´ncuch lub wszystkie ła´ncuchy

• --zero -Z [chain] zeruje liczniki w ła´ncuchach

• --check -C chain pozwala przetestowa´c dany pakiet na ła´ncuchu

• --new -N chain tworzy nowy ła´ncuch, definiowany przez u˙zytkownika

• --delete-chain -X [chain] usuwa ła´ncuch zdefiniowany przez u˙zytkownika

• --policy -P chain target zmienia domy´sln ˛

a polityk˛e w ła´ncuchu na okre´slon ˛

a przez „target”

• --rename-chain -E stary nowy zmienia nazw˛e ła´ncucha

Ogólne opcje:

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

• --proto -p [!]

proto

protokół, mo˙zna poda´c nazw˛e np. „tcp” lub numer

• --source -s [!]

address[/mask]

okre´slenie adresu ´zródłowego, z opcjonaln ˛

a mask ˛

• --destination -d [!]

address[/mask]

okre´slenie adresu docelowego, z opcjonaln ˛

a mask ˛

• --in-interface -i [!]

nazwa[+]

okre´slenie nazwy ´zródłowego interfejsu sieciowego, opcjo-

nalny [+] pozwala na dopasowanie dowolnych znaków

• --jump -j target skok do celu „target”, istnieje mo˙zliwo´s´c załadowania rozszerze´n

• --match -m match rozszerzone dopasowani, istnieje mo˙zliwo´s´c załadowania rozszerze´n, maj ˛

cych dodatkowe opcje

• --numeric -n pomijanie rozwijania nazw DNS

• --out-interface -o [!]

nazwa[+]

podobnie jak opcja „–in-interface”, tylko dotyczy inter-

fejsu, jakim pakiety opuszczaj ˛

a bramk˛e

• --table -t table wybór tabeli (domy´sln ˛

a jest: ‘filter’)

• --verbose -v tryb gadatliwy

• --line-numbers wypisuje numery linii podczas wypisywania reguł

• --exact -x wy´swietla dokładne warto´sci

• --fragment -f w przypadku pakietów sfragmentowanych, dopasowuje tylko drugi i nast˛epne

fragmenty

• --modprobe=<command> próbuje załadowa´c moduł

• --set-counters PKTS BYTES ustawia liczniki na konkretn ˛

a warto´s´c

• --version -V wypisuje wersje pakietu iptables

4.4.4

Prosty zestaw reguł

Najprostszy zestaw reguł w przypadku jednostki nie udost˛epniaj ˛

acej ˙zadnych usług mógłby wygl ˛

ada´c

nast˛epuj ˛

aco:

iptables --flush

iptables --policy FORWARD DROP

iptables --policy OUTPUT ACCEPT

iptables --policy INPUT DROP

iptables --append INPUT --match state --state ESTABLISHED,RELATED --jump

numer protokołu mo˙zemy uzyska´c z /etc/protocols

np. reguła iptables -append FORWARD -input +0+ -jump ACCEPT zadziała, gdy pakiet nadejdzie z interfejsu posia-

daj ˛

acego w swojej nazwie „0”, np. z eth0

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

Pierwsze polecenie czy´sci wszystkie ła´ncuchy, je´sli były tam wpisane jakie´s reguły, zawsze warto je

mie´c w własnym skrypcie inicjuj ˛

acym firewall. Nast˛epnie ustawiamy domy´sln ˛

a polityk˛e dla pakietów we

wszystkich ła´ncuchach. Jest ona stosowana dla tych pakietów, które przejd ˛

a przez cały ła´ncuch i ˙zadna

reguła nie b˛edzie do nich pasowa´c. Cel „DROP” sprawia, ˙ze zostan ˛

a one „zapomniane”, i nie zostanie

na nie wysłana ˙zadna odpowied´z. W ostatniej linii dla ła´ncucha INPUT mamy reguł˛e dopasowuj ˛

ac ˛

wszystkie pakiety nale˙z ˛

ace do istniej ˛

acych poł ˛

acze´n. Nie b˛ed ˛

a akceptowane pakiety nie nale˙z ˛

ace do

˙zadnego ju˙z nawi ˛

azanego poł ˛

aczenia, a wi˛ec nikt nie b˛edzie si˛e mógł z zewn ˛

atrz poł ˛

aczy´c, ale poł ˛

aczenia

nawi ˛

azane z danego komputera b˛ed ˛

a przepuszczane. Zapewnia nam to domy´slna polityka ACCEPT w

ła´ncuchu OUTPUT.

4.4.5

Omówienie ró˙znych celów tablicy „filter”

• ACCEPT Pakiet jest akceptowany w danej regule, i opuszcza ła´ncuch reguł.

• DROP Pakiet jest ignorowany, nie jest podejmowana jakakolwiek akcja, zwi ˛

azana z tym pakietem.

• REJECT Pakiet jest ignorowany, podobnie jak w celu „DROP”, ale mo˙zliwe jest wysłanie okre´slo-

nej odpowiedzi na pakiet. Słu˙zy do tego opcja --reject-with

– icmp-net-unreachable lub net-unreach, komunikat oznacza niedost˛epn ˛

a sie´c, i mo˙ze

by´c wysłany np. przez router, je˙zeli nie potrafi on przetrasowa´c pakietu do tej sieci.

– icmp-host-unreachable lub host-unreach, komunikat oznacza brak dost˛epno´sci danego

hosta, np. zapytanie o dany IP w sieci za routerem nie przyniosło ˙zadnej odpowiedzi.

– icmp-proto-unreachable lub proto-unreach, protokół nie jest obsługiwany przez host

docelowy.

– icmp-port-unreachable lub port-unreach (jest to opcja domy´slna przy zastosowaniu

celu „REJECT”), nie mo˙zna było osi ˛

agn ˛

a´c portu na danym ho´scie, oznacza to najcz˛e´sciej, ze

nie słucha tam ˙zadna usługa.

– icmp-net-prohibited lub net-prohib Dost˛ep do sieci został zablokowany.

– icmp-host-prohibited lub host-prohib Dost˛ep do hosta zastał zablokowany.

– tcp-reset (dzi˛eki tej opcji mo˙zemy zasymulowa´c zamkni˛ety port)

• LOG Pakiet jest logowany poprzez sysloga, jest to cel, który nie ko´nczy przetwarzania ła´ncucha.

Dodatkowo dla tego celu mo˙zemy poda´c opcje:

– --log-level Okre´sla poziom logowania, mo˙zna go poda´c numerycznie, lub u˙zywaj ˛

ac na-

zwy symbolicznej. Nazwy te to w kolejno´sci od najbardziej szczegółowego poziomu: debug,
info, notice, warning, err, crit, alert, emerg.

– --log-prefix Przedrostek informuj ˛

acy o pochodzeniu reguły, przydatny podczas rozró˙z-

niania informacji w logach.

– --log-tcp-sequence Loguje numery sekwencji TCP/IP.

– --log-tcp-options Loguje opcje z nagłówka TCP.

– --log-ip-options Loguje opcje z nagłówka IP.

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

Najlepiej zilustrowa´c na przykładzie konfiguracj˛e bardziej skomplikowanego firewalla. Zało˙zenia

s ˛

a nast˛epuj ˛

ace: Komputery w sieci wewn˛etrznej u˙zywaj ˛

a adresów z klasy 10.0.0.0/8, która normalnie

nie jest routowana przez routery. Nale˙zy ona do tak zwanej klasy adresów prywatnych. W naszym
przypadku, posiadaj ˛

a one swoje odpowiedniki w postaci widocznych z zewn ˛

atrz adresów publicznych.

Na wszystkich tych adresach b˛edzie wykonywana operacja maskowania adresów ´zródłowych, tak aby
poł ˛

aczenia wychodz ˛

ace z danego prywatnego IP było maskowane na odpowiadaj ˛

acy mu adres publiczny.

Wykona to dla nas cel „SNAT”

. Jest on mo˙zliwy do u˙zycia w tablicy „nat”, u˙zywany jest w ła´ncuchu

POSTROUTING, czyli adres zmieniany jest ju˙z po dokonaniu decyzji o routingu danego pakietu. Dla
reguł działaj ˛

acych w tablicy „filter” jest on widziany jako pakiet pochodz ˛

acy od prawdziwego adresu IP.

Przybli˙zenia wymagaj ˛

a ła´ncuchy u˙zywane w tablicy „nat”.

• PREROUTING ła´ncuch jest przetwarzany przed podj˛eciem decyzji o skierowaniu pakietu

• POSTROUTING ła´ncuch jest przetwarzany, przed opuszczeniem przez pakiet bramki

• OUTPUT ła´ncuch dla pakietów generowanych lokalnie

W ła´ncuchu PREROUTING u˙zywamy zazwyczaj celu „DNAT”

, który oznacza tłumaczenie/zamian˛e

adresów docelowych pakietu. Dla reguł tablicy ”filter” s ˛

a wi˛ec te pakiety widziane ju˙z po zmianie adresu.

U˙zywane jest to np. do przekierowania jakiego´s konkretnego adresu ip na inny, lub np. tylko wybra-
nego portu. Mo˙ze by´c tak˙ze wykorzystane do rozło˙zenia obci ˛

a˙zenia na wiele serwerów pracuj ˛

acych w

sieci wewn˛etrznej, a posiadaj ˛

acych widoczny na zewn ˛

atrz jeden adres IP. W ła´ncuchu POSTROUTING

natomiast u˙zywamy „SNAT”, dzi˛eki któremu zmieniane s ˛

a adresy ´zródłowe pakietów. Dzi˛eki niemu

mo˙zliwe staje si˛e np. u˙zycie adresów z klas prywatnych dla adresacji sieci wewn˛etrznej, natomiast wy-
chodz ˛

ac z bramki w kierunku Internetu, b˛ed ˛

a one zamieniane odpowiednio na adresy publiczne. Taka

translacja jest mo˙zliwa zarówno w stosunku 1:1, jak i 1:n, n:m.

4.4.6

Przykład konfiguracji SNAT 1:1

ip addr add IP_PUBLICZNE dev eth0

iptables --table nat -flush POSTROUTING

iptables --table nat -append POSTROUTING --source IP_WEWN ˛

ETRZNY --proto tcp

-o eth0 --jump SNAT --to-source IP_PUBLICZNE

iptables --policy FORWARD DROP

iptables --append FORWARD --match state --state NEW,ESTABLISHED,RELATED --source

IP_WEWN ˛

ETRZNE --jump ACCEPT

iptables --append FORWARD --match state --state ESTABLISHED,RELATED --destination

IP_WEWN ˛

ETRZNE --jump ACCEPT

Korzystaj ˛

ac z pakietu iproute2

dodajemy adres publiczny, który b˛edziemy mapowa´c na adres we-

wn˛etrzny. W naszym przykładzie pozwalamy na poł ˛

aczenia odbywaj ˛

ace si˛e z u˙zyciem protokołu TCP, na

wszystkie adresy i porty znajduj ˛

ace si˛e w sieci zewn˛etrznej. Nale˙zy pami˛eta´c, ˙ze w przypadku, gdy ser-

wer DNS nie znajduje si˛e w sieci wewn˛etrznej, nale˙zy tak˙ze przepu´sci´c ruch do serwera DNS (UDP/53).
DNS oprócz protokołu UDP, u˙zywa tak˙ze protokołu TCP, nale˙zy o tym pami˛eta´c, przy projektowaniu
reguł. Je˙zeli istniałaby potrzeba, aby na komputerze znajduj ˛

acym si˛e w sieci wewn˛etrznej, normalnie

niedost˛epnej z zewn ˛

atrz, działała jaka´s usługa przeznaczona dla sieci zewn˛etrznej, u˙zyjemy celu DNAT

i ła´ncucha PREROUTING.

SNAT - Source Network Address Translation, translacja adresu ´zródłowego

DNAT - Destination Network Address Translation, translacja adresu docelowego

Dost˛epny m.in. ftp.inr.ac.ru/ip-routing/

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

4.4.7

Prosty DNAT dla serwera WWW

Do naszych reguł musimy doło˙zy´c reguł˛e, która b˛edzie nam zamieniała adres docelowy pakietów. Zakła-
damy, ˙ze poprzednie reguły s ˛

a tak˙ze wprowadzone. Przykładowe przekierowanie do sieci wewn˛etrznej

zapyta´n na port 80 mo˙ze wygl ˛

ada´c nast˛epuj ˛

aco:

iptables --flush PREROUTING

iptables --table nat --append PREROUTING --destination IP_PUBLICZNE

--proto tcp --destination-port 80 --jump DNAT --to-destination IP_WEWN ˛

ETRZNE

iptables --insert FORWARD --match state --state NEW --proto tcp

--destination IP_WEWN ˛

ETRZNE --destination-port 80 --jump ACCEPT

Musimy oczywi´scie pami˛eta´c o tym, ˙ze oprócz poł ˛

acze´n maj ˛

acych status NEW, powinni´smy tak˙ze

przepuszcza´c poł ˛

aczenia maj ˛

ace status ESTABLISHED, oraz ewentualnie RELATED. Poł ˛

aczenia RE-

LATED s ˛

a to poł ˛

aczenia zwi ˛

azane z głównym poł ˛

aczeniem, np. poł ˛

aczenie słu˙z ˛

ace do przesyłania da-

nych poprzez protokół FTP.

4.4.8

Konfiguracja prze´zroczystego proxy

Aby wymusi´c u˙zywanie w sieci serwera proxy, nale˙zy u˙zy´c proxy transparentnego. Mianem tym okre-

´slamy proxy, które jest prze´zroczyste dla u˙zytkownika, nie musi on ustawia´c serwera proxy we wła-
´sciwo´sciach programów jakich u˙zywa. Daje nam to du˙ze mo˙zliwo´sci kontroli tego, jakie witryny s ˛

dost˛epne z sieci wewn˛etrznej. Jak te˙z wa˙zniejsz ˛

a w pewnych wypadkach jest mo˙zliwo´s´c zmniejszenia

pasma zajmowanego np. przez ruch http. Dla bezpiecze´nstwa sieci ma to mniejszy wpływ, znacznie
wi˛eksze korzy´sci niesie mo˙zliwo´s´c blokowania dost˛epu do okre´slonych stron itp.

iptables --table nat --append PREROUTING --in-interface eth_wewn˛

etrzny

--proto tcp --destination-port 80 -j REDIRECT -to-port 3128

Cel REDIRECT mo˙ze działa´c wył ˛

acznie w tablicy „nat”, w ła´ncuchach PREROUTING lub OUT-

PUT, modyfikuje on pakiet, zmieniaj ˛

ac mu numer portu. Je´sli naszym proxy jest bardzo popularny

Squid

musimy pami˛eta´c, ˙ze musi on by´c skompilowany ze wsparciem dla transparentnego proxy. Je-

˙zeli chcemy przekierowa´c ruch http na proxy znajduj ˛

ace si˛e na innym serwerze ni˙z firewall, musimy

u˙zy´c do tego celu DNAT.

4.4.9

Manipulacja polem TTL

Maj ˛

ac do dyspozycji moduł „ttl” z IPTables mo˙zemy „zaciemni´c” obraz sieci, znajduj ˛

acej si˛e przed i

za routerem. Np. reguła nieprzepuszczaj ˛

aca pakietów ICMP z polem TTL mniejszym od okre´slonej

warto´sci sprawi wra˙zenie przy korzystaniu np. z traceroute, ˙ze przed bramk ˛

a znajduj ˛

a si˛e bramki nie

odpowiadaj ˛

ace na ICMP. Mo˙zna tak˙ze zmodyfikowa´c moduł REJECT, aby np. posiadał mo˙zliwo´s´c od-

powiedzi z fałszywym adresem ´zródłowym, co dodatkowo sprawi, ˙ze dany „traceroute” b˛edzie wzbudzał
zaufanie. Przy u˙zyciu np. poni˙zszej reguły,

iptables --append INPUT --proto icmp --match ttl --ttl-lt 4 --jump DROP

iptables --append INPUT --proto udp --match ttl --ttl-lt 4 --jump DROP

Dost˛epny m.in. z http://squid.nlanr.net/Squid/

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

otrzymujemy:

# traceroute 127.0.0.1

traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets

1 * * *

2 * * *

3 * * *

4 localhost (127.0.0.1) 0 ms 0 ms 0 ms

Jak mo˙zemy zauwa˙zy´c, interfejs loopback jest osi ˛

agalny dopiero po 3 krotnym zwi˛ekszeniu warto´sci

TTL. Dla porównania normalny wynik powy˙zszego polecenia powinien wygl ˛

ada´c tak:

# traceroute 127.0.0.1

traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets

1 localhost (127.0.0.1) 0 ms 0 ms 0 ms

4.4.10

Próby skanowania

Poni˙zej zamieszcz˛e niektóre, bardziej charakterystyczne i ciekawsze fragmenty logów.

May 7 00:05:34 katalog kernel:

rejected in IN=eth0 OUT=

MAC=00:10:5a:72:6d:b7:00:00:0c:5c:30:f0:08:00 SRC=61.33.62.60

DST=212.182.42.54 LEN=40 TOS=0x00 PREC=0x80 TTL=112 ID=49324

PROTO=TCP SPT=22 DPT=22 WINDOW=20239 RES=0x00 SYN URGP=0

Omówi˛e w pierwszej kolejno´sci znaczenie poszczególnych pól:

• IN Okre´sla interfejs wej´sciowy

• OUT Interfejs wyj´sciowy

• MAC Pierwsze 6 par liczb to adres MAC interfejsu IN, nast˛epne 6 par to adres karty sieciowej, z

jakiej otrzymali´smy pakiet. Dodatkowo dodane jest „:08:00” w sieci Ethernet.

• SRC Okre´sla adres ´zródłowy otrzymanego pakietu

• DST Adres docelowy pakietu

• LEN Długo´s´c pakietu

• TOS Pole „Type Of Service”

• PREC Pole „Type Of Precedence”

• TTL Pole „Time To Live” pakietu.

• ID Pole ID, okre´sla numer pakietu

• PROTO Okre´sla protokół, jaki przenosi pakiet

• SPT Port ´zródłowy

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

• DPT Port docelowy

• WINDOW Okre´sla rozmiar okna, jakie jest w stanie przyj ˛

a´c komputer docelowy

• RES Warto´s´c pola RES

• flagi ustawione flagi pakietu, SYN ACK FIN RST URG PSH ALL lub NONE

May 5 10:14:35 katalog kernel:

rejected in IN=eth0 OUT=

MAC=00:10:5a:72:6d:b7:00:00:0c:5c:30:f0:08:00 SRC=61.197.216.58

DST=212.182.xxx.xxx LEN=40 TOS=0x00 PREC=0x80 TTL=120 ID=31992

PROTO=TCP SPT=21 DPT=21 WINDOW=30372 RES=0x00 SYN URGP=0

Ten pakiet próbował omin ˛

a´c zwykły firewall, ustawiaj ˛

ac sobie jako port ´zródłowy port 21/ftp. W tym

wypadku wystarczaj ˛

acym zabezpieczeniem, je´sli nie u˙zywamy firewalla pami˛etaj ˛

acego stan poł ˛

acze´n,

jest blokada pakietów z ustawion ˛

a flag ˛

a SYN, pochodz ˛

acych z adresów innych ni˙z dozwolone w naszej

polityce dost˛epu.

May 5 16:36:16 katalog kernel:

rejected in IN=eth0 OUT=

MAC=00:10:5a:72:6d:b7:00:00:0c:5c:30:f0:08:00 SRC=212.183.193.174

DST=212.182.xxx.xxx LEN=48 TOS=0x00 PREC=0x80 TTL=112 ID=65302 DF

PROTO=TCP SPT=3118 DPT=12345 WINDOW=16384 RES=0x00 SYN URGP=0

W tym wypadku mamy do czynienia z poszukiwaniem aktywnych trojanów, prawdopodobnie Net-

Busa, który domy´slnie słucha na porcie 12345.

May 6 14:15:05 katalog kernel:

rejected in IN=eth0 OUT=

MAC=00:10:5a:72:6d:b7:00:00:0c:5c:30:f0:08:00 SRC=10.1.0.25

DST=212.182.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=32477 DF

PROTO=TCP SPT=8008 DPT=39731 WINDOW=31856 RES=0x00 ACK FIN URGP=0

Ten pakiet jest o wiele ciekawszy. Posiada ustawione flagi ACK i FIN oraz sfałszowany adres ´zró-

dłowy. Na takie przypadki nale˙zy zwróci´c szczególn ˛

a uwag˛e, gdy˙z mamy tu do czynienia z osob ˛

staraj ˛

ac ˛

a ukry´c swoj ˛

a to˙zsamo´s´c, oraz znajduj ˛

ac ˛

a si˛e w sieci wewn˛etrznej, gdy˙z aby by´c w stanie ode-

bra´c odpowied´z, najprawdopodobniej posiada ona kart˛e działaj ˛

ac ˛

a w trybie promisc

Zakładam, ˙ze pole

MAC w tym przypadku wyra´znie wskazuje, ˙ze pakiet przyszedł z routera, do którego podł ˛

aczony jest

komputer o adresie DST=212.182.xxx.xxx, a nie sfałszowany pakiet pochodz ˛

acy z sieci lokalnej.

Niestety, zało˙zenie takie mo˙ze by´c bł˛edne. Adres MAC tak˙ze mo˙ze by´c sfałszowany, gdy˙z akurat

w tym konkretnym przypadku istnieje mo˙zliwo´s´c wpi˛ecia np. notebooka do naszej sieci przez intruza,
i sfałszowania adresu MAC karty sieciowej. Takiej sytuacji mogłoby zapobiec statyczne przypisanie
adresu MAC do ka˙zdego portu switcha. Nie wszystkie urz ˛

adzenia na to pozwalaj ˛

a, jest to dodatkowo

czynno´s´c kłopotliwa oraz czasochłonna. Bardzo cz˛esto ta mo˙zliwo´s´c jest niewykorzystywana. Otwiera
to mo˙zliwo´s´c wykorzystania tego przez intruza i bezpo´sredniego wpi˛ecia si˛e do sieci, np. przez nieza-
bezpieczone gniazdo sieciowe w ogólnie dost˛epnym miejscu.

Tryb promisc - karta sieciowa b˛ed ˛

ac w tym trybie odbiera wszystkie ramki danych, jakie przechodz ˛

a przez podł ˛

aczone do

niej medium, a nie tylko te, które s ˛

a adresowane bezpo´srednio do niej. Pozwala to m.in. na podsłuchiwanie ruchu w sieci

ROZDZIAŁ 4. FIREWALLE, ICH RODZAJE I ZASTOSOWANIE

Apr 30 10:19:27 katalog kernel:

rejected in IN=eth0 OUT=

MAC=00:10:5a:72:6d:b7:00:00:0c:5c:30:f0:08:00 SRC=217.11.136.226

DST=212.182.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=6782 DF

PROTO=TCP SPT=8080 DPT=36447 WINDOW=17520 RES=0x00 ACK RST URGP=0

Pakiet ten ró˙zni si˛e od poprzednich ustawionymi flagami. Ma on ustawiony port ´zródłowy na port

bardzo cz˛esto u˙zywany przez ró˙znego rodzaju proxy http, wi˛ec istnieje du˙za szansa, ˙ze ruch z tego portu
jest w sieci skanowanej dozwolony i nie wzbudzi zainteresowania, omijaj ˛

ac reguły systemów IDS. U˙zyte

flagi powoduj ˛

a, ˙ze przedostałby si˛e on przez prosty firewall bez kontroli stanu poł ˛

acze´n.

4.5

Dodatkowe rozszerzenia IPTables

4.5.1

Patch-O-Matic

Ze strony domowej projektu istnieje mo˙zliwo´s´c ´sci ˛

agni˛ecia rozwojowych wersji rozszerze´n funkcjonal-

no´sci IPTables. Najłatwiej wykonamy to korzystaj ˛

ac z CVS

# cvs -d :pserver:cvs@pserver.samba.org:/cvsroot login

# cvs -z3 -d :pserver:cvs@pserver.samba.org:/cvsroot co netfilter

Spowoduje to stworzenie w aktualnym katalogu katalogu netfilter oraz ´sci ˛

agni˛ecie odpowiednich

plików. Musimy si˛e upewni´c, ˙ze w naszym katalogu ze ´zródłami kernela s ˛

a aktualne zale˙zno´sci. Naj-

pro´sciej osi ˛

agniemy to przechodz ˛

ac do niego i wydaj ˛

ac polecenie make dep.

Nast˛epnie w katalogu netfilter/userspace uruchamiamy konfiguracj˛e Patch-O-Matic.

# make patch-o-matic

Skrypt zapyta si˛e nas, które łatki chcemy nało˙zy´c na j ˛

adro, poinformuje nas, jakie s ˛

a ju˙z nało˙zone

oraz ewentualnie o nieudanym nało˙zeniu łatek. Po nało˙zeniu łatek, nale˙zy skonfigurowa´c ponownie
kernel i nast˛epnie go zainstalowa´c.

Aby skorzysta´c z nowych rozszerze´n, b˛edziemy prawdopodobnie potrzebowa´c programu iptables

w nowszej wersji.

4.5.2

Własne rozszerzenia IPTables

Ze wzgl˛edu na modułow ˛

a budow˛e, je˙zeli potrzebujemy funkcjonalno´sci, której jeszcze nie zapewnia

˙zaden moduł, mo˙zemy sami go stworzy´c[14].

Pomocna

tym

zadaniu

mo˙ze

by´c

dokumentacja

dost˛epna

pod

adresem:

http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html

opisuj ˛

aca ar-

chitektur˛e NetFilter.

Concurrent Versions System - system kontroli wersji

Rozdział 5

Systemy zabezpiecze ´n systemu Linux

5.1

GRSecurity

5.1.1

Opis zało˙ze ´n

Zało˙zeniem projektu GRSecurity jest stworzenie zestawu poprawek na j ˛

adro systemu Linux, zwi˛eksza-

j ˛

acych jego odporno´s´c na atak[7, 15, 18]. W jego skład obecnie wchodz ˛

a patche zapewniaj ˛

ace ACL

Trusted Path Execution

a tak˙ze rozbudowane mechanizmy logowania.

5.1.2

Sposób instalacji

Istniej ˛

a ró˙zne metody instalacji poprawek składaj ˛

acych si˛e na GRSecurity. Najłatwiejsz ˛

a drog ˛

a wydaje

si˛e by´c pobranie ze strony http://www.grsecurity.net poprawek na wersj˛e j ˛

adra systemu Linux,

jakiej ´zródła posiadamy

Po pobraniu pliku np. grsecurity-1.9.4-2.4.18.patch do katalogu/usr/src nakładamy po-

prawk˛e w nast˛epuj ˛

acy sposób na uprzednio rozpakowane do katalogu linux j ˛

adro:

$ cat grsecurity-1.9.4-2.4.18.patch | patch -d linux -p1

patching file Documentation/Configure.help

patching file Makefile

patching file arch/alpha/config.in

patching file arch/arm/config.in

patching file arch/cris/config.in

patching file arch/i386/config.in

patching file arch/i386/kernel/entry.S

patching file arch/i386/kernel/head.S

patching file arch/i386/kernel/ptrace.c

patching file arch/i386/kernel/signal.c

patching file arch/i386/kernel/traps.c

patching file arch/i386/mm/fault.c

Access Control List - rozbudowane listy kontroli dost˛epu

Tylko programy znajduj ˛

ace si˛e w okre´slonej lokalizacji mog ˛

a by´c uruchamiane, mo˙ze to stanowi´c ochron˛e przed urucho-

mieniem przez intruza programu np. z katalogu /temp

Sposób pobrania oraz przygotowanie do konfiguracji aktualnej wersji systemu został opisany w rozdziale dotycz ˛

acym

NetFilter.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

patching file arch/i386/mm/init.c

patching file arch/ia64/config.in

patching file arch/m68k/config.in

patching file arch/mips/config.in

patching file arch/mips64/config.in

patching file arch/parisc/config.in

patching file arch/ppc/config.in

patching file arch/s390/config.in

patching file arch/s390x/config.in

patching file arch/sh/config.in

patching file arch/sparc/config.in

patching file arch/sparc64/config.in

patching file drivers/char/mem.c

patching file drivers/char/vt.c

patching file drivers/ieee1394/video1394.c

patching file drivers/media/video/bttv-driver.c

patching file drivers/media/video/cpia.c

patching file drivers/media/video/meye.c

patching file drivers/media/video/planb.c

patching file drivers/media/video/zr36067.c

patching file drivers/media/video/zr36120.c

patching file drivers/pci/proc.c

patching file drivers/usb/ov511.c

patching file drivers/usb/pwc-if.c

patching file drivers/usb/se401.c

patching file drivers/usb/stv680.c

patching file drivers/usb/usbvideo.c

patching file drivers/usb/vicam.c

patching file fs/binfmt_aout.c

patching file fs/binfmt_elf.c

patching file fs/exec.c

patching file fs/namei.c

patching file fs/namespace.c

patching file fs/open.c

patching file fs/proc/base.c

patching file fs/proc/generic.c

patching file fs/proc/inode.c

patching file fs/proc/proc_misc.c

patching file fs/proc/proc_tty.c

patching file fs/proc/root.c

patching file fs/readdir.c

patching file grsecurity/Config.in

patching file include/asm-i386/a.out.h

patching file include/asm-i386/pgtable.h

patching file include/asm-i386/processor.h

patching file include/linux/a.out.h

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

patching file include/linux/binfmts.h

patching file include/linux/dcache.h

patching file include/linux/elf.h

patching file include/linux/fs.h

patching file include/linux/gracl.h

patching file include/linux/grdefs.h

patching file include/linux/grhash.h

patching file include/linux/grsecurity.h

patching file include/linux/kernel.h

patching file include/linux/mm.h

patching file include/linux/proc_fs.h

patching file include/linux/sched.h

patching file include/linux/spinlock.h

patching file include/linux/sysctl.h

patching file include/net/inetpeer.h

patching file include/net/ip.h

patching file init/main.c

patching file ipc/msg.c

patching file ipc/sem.c

patching file ipc/shm.c

patching file kernel/Makefile

patching file kernel/fork.c

patching file kernel/gracl.c

patching file kernel/grhash.c

patching file kernel/grsecurity.c

patching file kernel/ksyms.c

patching file kernel/printk.c

patching file kernel/sched.c

patching file kernel/signal.c

patching file kernel/sys.c

patching file kernel/sysctl.c

patching file kernel/time.c

patching file mm/mmap.c

patching file mm/mprotect.c

patching file net/ipv4/Makefile

patching file net/ipv4/af_inet.c

patching file net/ipv4/icmp.c

patching file net/ipv4/ip_gre.c

patching file net/ipv4/ip_id.c

patching file net/ipv4/ip_output.c

patching file net/ipv4/ip_sockglue.c

patching file net/ipv4/netfilter/Config.in

patching file net/ipv4/netfilter/Makefile

patching file net/ipv4/netfilter/ipt_stealth.c

patching file net/ipv4/tcp_ipv4.c

patching file net/ipv4/udp.c

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

patching file net/netsyms.c

patching file net/socket.c

patching file net/sunrpc/xprt.c

Jak mo˙zemy zauwa˙zy´c, nało˙zenie poprawek przebiegło pomy´slnie. Je˙zeli pojawi ˛

a si˛e przy nakłada-

niu poprawki jakie´s bł˛edy, a mo˙ze to nast ˛

api´c, je´sli np. chcemy nało˙zy´c jeszcze jak ˛

a´s inna poprawk˛e,

nale˙zy wtedy przejrze´c pliki *.rej i je˙zeli jest to mo˙zliwe, nało˙zy´c poprawk˛e r˛ecznie w miejscach, w
których nie udało si˛e to automatowi. Po zaaplikowaniu poprawek mo˙zemy uruchomi´c proces konfigu-
racji j ˛

adra. W tym celu wydajemy polecenie cd linux; make xconfig lub inne, wymienione przy

okazji konfiguracji NetFilter.

5.1.3

Opis parametrów konfiguracji j ˛

adra i ich omówienie

Grupy opcji konfiguracyjnych j ˛

adra, jakie dodaje poprawka GRSecurity:

Dodatkowy moduł NetFilter

CONFIG_IP_NF_MATCH_STEALTH

Jest to dodatkowa opcja pojawiaj ˛

aca si˛e w konfiguracji NetFil-

ter. Uaktywnienie tej opcji spowoduje dost˛ep do dodatkowego rozszerzenia IPTables, które po-
rzuca pakiety TCP z ustawion ˛

a flag ˛

a SYN lub pakiety UDP, skierowane do portu, na którym nie

słucha ˙zadna usługa. Je˙zeli u˙zywamy usługi NAT, powinni´smy pami˛eta´c, ˙ze rozszerzenie to nie
przepu´sci pakietów skierowanych do sieci, dla której wykonujemy translacje adresów, wi˛ec nale˙zy
je umie´sci´c na ko´ncu listy reguł.

Grupy opcji w GRSecurity[22]

CONFIG_GRKERNSEC

Opcja pozwala skonfigurowa´c wła´sciw ˛

a cz˛e´s´c tej poprawki.

CONFIG_GRKERNSEC_LOW

Opcja daje nam 4 mo˙zliwo´sci do wyboru. Trzy z nich s ˛

a to predefi-

niowane ustawienia GRSecurity, natomiast czwarta pozwala nam na wybranie wszystkich opcji
samodzielnie. Krótki opis opcji predefiniowanych:

• Low additional security Opcja ta zapewnia niski poziom dodatkowych zabezpiecze´n

lecz nie powinna powodowa´c ˙zadnych problemów z istniej ˛

acymi i działaj ˛

acymi programami.

Po jej wybraniu, wł ˛

aczane s ˛

a nast˛epuj ˛

ace opcje:

– Restrykcje dotycz ˛

ace tworzenia dowi ˛

aza´n

– Restrykcje dotycz ˛

ace kolejek FIFO

– Bezpieczne deskryptory
– Losowe identyfikatory procesów
– Wymuszanie wywołania nproc w funkcji execve()
– Losowe numery sekwencyjne pakietów IP
– Wymuszone wywołanie funkcji chdir(„/”) w ´srodowisku chroot
– Bezpieczne ładowanie mapy klawiatury

• Medium additional security ´Sredni poziom dodatkowych zabezpiecze´n. W rzadkich

przypadkach mo˙ze by´c to ´zródłem problemów ze starszym lub ´zle napisanym oprogramowa-
niem. Zakłada, ˙ze serwis identd pracuje z gid

=10. Po wybraniu dodatkowo w stosunku do

poprzedniego poziomu aktywne s ˛

a opcje:

Group ID

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Rysunek 5.1: Grupy opcji mo˙zliwe do wyboru w zakładce GRSecurity

– Losowe numery portów ´zródłowych TCP

– Zmienione numery ID ICMP Echo/Echo Reply

– Logowanie nieudanych prób wołania funkcji fork()

– Logowanie zmian czasu

– Logowanie sygnałów

– Zabronione montowanie w obr˛ebie chroot

– Zabronione tworzenie plików urz ˛

adze´n w obr˛ebie chroot

– Restrykcje na katalog /proc, montowany z gid=10.

– Losowa funkcja mmap() z projektu PaX

• High additional security Opcja ta powoduje wł ˛

aczenie wi˛ekszo´sci zabezpiecze´n, które

oferuje GRSecurity, a tak˙ze projekt PaX. Dodatkowe opcje to:

– System ACL GRSecurity

– Dodatkowe restrykcje /proc

– Restrykcje sygnałów w obr˛ebie chroot

– Restrykcje zmiany praw plików w obr˛ebie chmod

– Wł ˛

aczone dodatkowe opcje PaX

– Logowanie operacji montowania/odmontowania

– Restrykcje dotycz ˛

ace mo˙zliwo´sci ´sledzenia procesów.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Opcje zabezpieczaj ˛

ace przed atakami poprzez przepełnienie bufora

Rysunek 5.2: Grupa opcji Buffer Overflow Protection

CONFIG_GRKERNSEC_STACK

Architektura IA-32 nie pozwala na ochron˛e strony pami˛eci przed wy-

konaniem. Je˙zeli strona jest do odczytu (tak jak stos i sterta), jest tak˙ze wykonywalna. W przy-
padku wybrania tej opcji system nie pozwoli na wykonanie kodu b˛ed ˛

acego na stosie, sprawiaj ˛

wykorzystanie przepełnienia buforów zadaniem o wiele trudniejszym. Kod pochodzi z projektu
Openwall

dost˛epnego wcze´sniej dla j ˛

ader Linuxa serii 2.2.x, opracowanego prze Solar Designera.

CONFIG_GRKERNSEC_STACK_GCC

Po wybraniu tej opcji kernel wspierał b˛edzie mechanizm tram-

polin

CONFIG_GRKERNSEC_PAX

Opcja zamienna z opcj ˛

a u˙zycia poprawki Openwall. Wł ˛

aczenie jej po-

woduje, ˙ze wymuszana jest flaga niewykonywalno´sci na stronach pami˛eci. Zachowanie to powo-
duje, ˙ze niezgodne z ni ˛

a s ˛

a niektóre programy oczekuj ˛

ace, ˙ze po zaalokowaniu pami˛eci poprzez

malloc()

jest ona wykonywalna. Do wyj ˛

atków nale˙z ˛

a m.in. serwer XFree86 4.x. Istnieje mo˙z-

liwo´s´c w takim wypadku wył ˛

aczenia tego rozszerzenia w stosunku do poszczególnych plików z

pomoc ˛

a narz˛edzia chpax

CONFIG_GRKERNSEC_PAX_EMUTRAMP

Opcja wł ˛

acza obsług˛e m.in. trampolin, podobnie jak odpo-

wiadaj ˛

aca jej opcja w przypadku poprawki Openwall.

CONFIG_GRKERNSEC_PAX_MPROTECT

Wł ˛

aczenie tej opcji zapobiega:

Dost˛epny z http://www.openwall.com/linux, obecnie tak˙ze dla serii 2.4.x

Opis dost˛epny pod adresem http://users.n.ml.org/nc/ffcall/trampoline.html

Dost˛epny m.in. z http://pageexec.virtualave.net

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

• Zmianom stanu flagi wykonywalno´sci stron pami˛eci, które zostały nie zostały stworzone jako

wykonywalne.

• Zmianie wykonywalnych, tylko do odczytu stron pami˛eci na strony do zapisu.

• Tworzeniu stron wykonywalnych z nieznanej pami˛eci.

CONFIG_GRKERNSEC_PAX_RANDMMAP

Po zastosowaniu tej opcji kernel b˛edzie starał si˛e w sposób

mo˙zliwie losowy wybiera´c przestrze´n adresow ˛

a dla procesów za ka˙zdym uruchomieniem (adres

pocz ˛

atku stosu, adres bazowy dla wywoła´n funkcji mmap() a tak˙ze adres bazowy dla dynamicznie

ładowanych plików wykonywalnych). Z tego powodu utrudnia to wykorzystanie bł˛edu w progra-
mie, gdy˙z za ka˙zdym razem przesuni˛ecie adresów np. stosu jest inne.

CONFIG_GRKERNSEC_KMEM

Ustawienie tej opcji sprawia, ˙ze nawet root nie b˛edzie mógł modyfi-

kowa´c poprzez mechanizm ioctl pami˛eci kernela. Zalecane jest tak˙ze wył ˛

aczenie wsparcia dla

ładowania modułów w trakcie pracy kernela.

Opcje dotycz ˛

ace list dost˛epu ACL

Rysunek 5.3: Grupa opcji Access Control List

CONFIG_GRKERNSEC_ACL

Uaktywnienie tej opcji wł ˛

acza mechanizm list dost˛epu. W przeciwie´n-

stwie do innych dost˛epnych dla Linuxa systemów ACL zezwala na kontrol˛e dost˛epu zarówno do
procesu jak i pliku. Do korzystania z tego rozwi ˛

azania wymagane s ˛

a narz˛edzia, które mo˙zna

pobra´c ze strony domowej projektu.

CONFIG_GR_DEBUG

Opcja pozwala na wypisywanie komunikatów diagnostycznych, pomocnych przy

analizie problemów z prawidłowym ustawieniem list dost˛epu.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

CONFIG_GR_SUPERDEBUG

Opcja pozwala na wypisywanie bardziej szczegółowych komunikatów.

CONFIG_GRKERNSEC_ACL_CAPLOG

Opcja powoduje logowanie sytuacji, kiedy proces, którego wła-

´scicielem jest u˙zytkownik root nie posiada wystarczaj ˛

acych uprawnie´n ustawionych poprzez ACL.

CONFIG_GR_MAXTRIES

Opcja ustawia maksymaln ˛

a liczb˛e prób uwierzytelnienia wobec ACL, jakie

mo˙ze wykona´c u˙zytkownik, zanim zostanie zablokowany na okre´slony czas.

CONFIG_GR_TIMEOUT

Okre´sla czas (w sekundach), na jaki blokowany jest u˙zytkownik po przekro-

czeniu prób uwierzytelnienia okre´slonej w poprzedniej opcji.

Opcje dotycz ˛

ace zabezpiecze ´n systemu plików

CONFIG_GRKERNSEC_PROC

Opcja ustala prawa dost˛epu do systemu plików /proc na bardziej re-

strykcyjne. Dalsze opcje pozwalaj ˛

a na dokładniejsze skonfigurowanie restrykcji.

CONFIG_GRKERNSEC_PROC_USER

Opcja ogranicza dost˛ep zwykłym u˙zytkownikom do informacji

zwi ˛

azanych z sieci ˛

a, przegl ˛

adania tablicy symboli kernela i informacji o modułach. U˙zytkownik

widzi tak˙ze tylko własne procesy, nie ma mo˙zliwo´sci zobaczy´c wszystkich uruchomionych pro-
cesów. Odpowied´z negatywna pozwala skonfigurowa´c dla wybranych u˙zytkowników dost˛ep do
wi˛ekszej ilo´sci informacji.

CONFIG_GRKERNSEC_PROC_USERGROUP

Opcja pozwala wybra´c grup˛e, której członkowie b˛ed ˛

mogli widzie´c wszystkie procesy, informacje zwi ˛

azane z sieci ˛

a oraz informacje o symbolach i

kernelu. Opcja jest u˙zyteczna, je˙zeli u˙zywamy np. serwisu identd, który b˛ed ˛

ac uruchomiony z

prawami u˙zytkownika innego ni˙z root, musi mie´c dost˛ep do informacji zawartej w proc.

CONFIG_GRKERNSEC_PROC_GID

Pozwala na wpisanie numeru grupy, jaka b˛edzie u˙zywana w zwi ˛

azku

z poprzedni ˛

a opcj ˛

CONFIG_GRKERNSEC_PROC_ADD

Dodatkowe restrykcje, nie pozwalaj ˛

ace zwykłemu u˙zytkownikowi

przegl ˛

ada´c informacji takich jak informacje o CPU i innych urz ˛

adzeniach.

CONFIG_GRKERNSEC_LINK

Dzi˛eki tej opcji, u˙zytkownicy nie mog ˛

a pod ˛

a˙za´c za dowi ˛

azaniami, któ-

rych wła´scicielem jest inny u˙zytkownik w ogólnie dost˛epnych katalogach z ustawion ˛

a flag ˛

a +t

wyj ˛

atkiem jest sytuacja, gdy wła´scicielem dowi ˛

azania jest wła´sciciel katalogu. U˙zytkownicy nie

b˛ed ˛

a mogli tak˙ze tworzy´c twardych dowi ˛

aza´n do plików, których nie s ˛

a wła´scicielami. Je˙zeli

wł ˛

aczony jest mechanizm sysctl tworzona jest opcja linking_restrictions.

CONFIG_GRKERNSEC_FIFO

Je˙zeli aktywna jest ta opcja, u˙zytkownicy nie b˛ed ˛

a mogli pisa´c do FIFO

znajduj ˛

acych si˛e w katalogach z prawami zapisu dla wszystkich z ustawion ˛

a flag ˛

a +t których nie s ˛

wła´scicielami. Je˙zeli jest wł ˛

aczony mechanizm sysctl tworzona jest opcja fifo_restrictions.

CONFIG_GRKERNSEC_CHROOT

Pozwala skonfigurowa´c opcje dotycz ˛

ace zachowania si˛e kernela w

´srodowisku chroot

, utrudniaj ˛

ac mo˙zliwo´s´c jego opuszczenia.

CONFIG_GRKERNSEC_CHROOT_SIG

Procesy wewn ˛

atrz klatki chroot nie b˛ed ˛

a mogły wysyła´c sy-

gnałów do procesów na zewn ˛

atrz. Jedynym dozwolonym sygnałem jest sygnał null który nie

wywołuje ˙zadnej akcji, oraz sygnały wysyłane od procesu rodzica do procesu dziecka. Je˙zeli jest
wł ˛

aczony mechanizm sysctl tworzona jest opcja chroot_restrict_sigs.

Flaga ta sprawia, ˙ze z katalogu maj ˛

acego j ˛

a ustawion ˛

a pliki mo˙ze usun ˛

a´c (oprócz u˙zytkownika root) tylko wła´sciciel pliku.

chroot

zmienia katalog główny systemu

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Rysunek 5.4: Grupa opcji zabezpiecze´n systemu plików

CONFIG_GRKERNSEC_CHROOT_MOUNT

Procesy wewn ˛

atrz klatki chroot nie b˛ed ˛

a mogły montowa´c

ani przemontowywa´c systemów plików. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest

opcja chroot_deny_mount.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

CONFIG_GRKERNSEC_CHROOT_DOUBLE

Procesy wewn ˛

atrz klatki chroot nie b˛ed ˛

a mogły wykona´c

ponownego chroot, jest to metoda powszechnie u˙zywana w celu wydostania si˛e z klatki chroot
i jako taka powinna by´c zabroniona. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

chroot_deny_chroot

CONFIG_GRKERNSEC_CHROOT_PIVOT

Procesy wewn ˛

atrz klatki chroot nie b˛ed ˛

a mogły wywoły-

wa´c funkcji pivot_root(), która po raz pierwszy została wprowadzona w wersji 2.3.41 systemu
Linux. Jej działanie jest o tyle podobne do działania funkcji chroot(), ˙ze tak˙ze zmienia główny
katalog systemu, a wi˛ec mo˙ze zosta´c u˙zyta do wydostania si˛e z klatki chroot. Je˙zeli wł ˛

aczony

jest mechanizm sysctl tworzona jest opcja chroot_deny_pivot.

CONFIG_GRKERNSEC_CHROOT_CHDIR

Opcja wymusza zmian˛e aktualnego katalogu przy wywoła-

niu funkcji chroot() na katalog główny klatki chroot. Normalne wywołanie funkcji chroot()
nie zmienia aktualnego katalogu, tak wi˛ec mo˙zliwa jest w ten sposób ucieczka z klatki chroot.
Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja chroot_enforce_chdir.

CONFIG_GRKERNSEC_CHROOT_FCHDIR

Opcja zapobiega ucieczce z klatki chroot za pomoc ˛

a zmiany

katalogu funkcj ˛

a fchdir na wskazywany deskryptorem pliku procesu, który to plik znajduje si˛e

poza klatk ˛

a chroot.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

chroot_deny_fchdir

CONFIG_GRKERNSEC_CHROOT_CHMOD

Proces wewn ˛

atrz klatki chroot nie mo˙ze u˙zy´c chmod() ani

fchmod()

aby ustawi´c plikom atrybuty SUID lub SGID, gdy˙z jest to jeszcze jeden ze znanych

sposobów ucieczki z klatki chroot. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

chroot_deny_chmod

CONFIG_GRKERNSEC_CHROOT_MKNOD

Procesy wewn ˛

atrz klatki chroot nie mog ˛

a tworzy´c plików

urz ˛

adze´n. Mogłoby zosta´c to wykorzystane przez intruza np. do stworzenia pliku urz ˛

adzenia

dysku twardego, a nast˛epnie np. wyczyszczenie jego zawarto´sci lub skopiowania danych. Je˙zeli
wł ˛

aczony jest mechanizm sysctl tworzona jest opcja chroot_deny_mknod.

CONFIG_GRKERNSEC_CHROOT_PTRACE

Procesy wewn ˛

atrz klatki chroot nie mog ˛

a ´sledzi´c innych

procesów. Funkcja ptrace() pozwala na podł ˛

aczenie si˛e do innego procesu i zmienianie prze-

biegu jego wykonywania.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

chroot_deny_ptrace

CONFIG_GRKERNSEC_CHROOT_NICE

Procesy wewn ˛

atrz klatki chroot nie mog ˛

a podnosi´c swo-

jego priorytetu lub zmienia´c priorytetu procesów spoza chroot. Je˙zeli wł ˛

aczony jest mechanizm

sysctl

tworzona jest opcja chroot_restrict_nice.

CONFIG_GRKERNSEC_CHROOT_CAPS

Je˙zeli zostanie wybrana ta opcja, procesom wewn ˛

atrz klatki

chroot

zostanie zabrana mo˙zliwo´s´c ładowania modułów kernela, bezpo´sredniego dost˛epu do

urz ˛

adze´n, wykonywania zada´n systemowych oraz zwi ˛

azanych ze zmianami ustawie´n sieci, re-

startowania systemu, modyfikowania plików maj ˛

acych atrybut niezmienno´sci (immutable) oraz

zmiany czasu systemowego.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

chroot_caps

Klatka chroot jest bardzo cz˛esto u˙zywanym zabezpieczeniem przed eskalacj ˛

a uprawnie´n wynika-

j ˛

ac ˛

a z wykorzystania bł˛edu w usłudze. Cały proces, który zabezpieczamy, jest uruchamiany w wydzielo-

nym dla niego ´srodowisku, z kompletem bibliotek potrzebnych mu do działania. Je˙zeli intruz wykorzysta

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

jaki´s bł ˛

ad w danym procesie, np. uda mu si˛e uruchomi´c proces powłoki, pozostaje on wci ˛

a˙z w klatce

chroot

. Je˙zeli proces był uruchomiony jako u˙zytkownik z UID innym ni˙z 0, który nie ma ˙zadnych

praw do zapisu jakiegokolwiek pliku, do którego ma dost˛ep, jedynym skutkiem działania intruza jest
wył ˛

aczenie usługi. Jest to tak˙ze znacz ˛

acy sygnał dla administratora, ˙ze w danej usłudze s ˛

a jakie´s bł˛edy,

pozwalaj ˛

ace na uzyskanie nieuprawnionego dost˛epu do systemu. W normalnym wypadku, bez popra-

wek zapewnianych przez GRSecurity, je˙zeli usługa była działała z prawami u˙zytkownika root intruz
ma szereg mo˙zliwo´sci, za pomoc ˛

a których mo˙ze opu´sci´c chroot. Z łatk ˛

a GRSecurity i po najbardziej

restrykcyjnym skonfigurowaniu opcji dotycz ˛

acych chroot nawet u˙zytkownik root ma niewielkie mo˙z-

liwo´sci zaszkodzenia całemu systemowi.

Opcje dotycz ˛

ace audytu/logowania zdarze ´n

Rysunek 5.5: Grupa opcji audytu/logowania zdarze´n

CONFIG_GRKERNSEC_AUDIT_GROUP

Opcja daje nam mo˙zliwo´s´c wyboru grupy, do jakiej odnosi´c

si˛e b˛ed ˛

a wybrane opcje logowania exec, chdir, (un)mount oraz ipc. Jest to u˙zyteczne, je˙zeli

chcemy kontrolowa´c tylko jedn ˛

a grup˛e u˙zytkowników, a nie cały system. Je˙zeli wł ˛

aczony jest

mechanizm sysctl tworzona jest opcja audit_group.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

CONFIG_GRKERNSEC_AUDIT_GID

Opcja okre´sla GID grupy, która b˛edzie logowana. Je˙zeli wł ˛

czony jest mechanizm sysctl tworzona jest opcja audit_gid. Nale˙zy wtedy przy ka˙zdym uru-
chomieniu systemu ustawi´c t ˛

a warto´s´c poprawnie.

CONFIG_GRKERNSEC_EXECLOG

Wszystkie wywołania funkcji execve() b˛ed ˛

a logowane, nale˙zy

pami˛eta´c, ˙ze opcja ta mo˙ze generowa´c bardzo du˙zo logów. Je˙zeli wł ˛

aczony jest mechanizm

sysctl

tworzona jest opcja exec_logging.

CONFIG_GRKERNSEC_CHROOT_EXECLOG

Opcja bardzo podobna do poprzedniej, tylko w tym przy-

padku logowane s ˛

a wywołania funkcji execve() wewn ˛

atrz klatki chroot. Je˙zeli wł ˛

aczony jest

mechanizm sysctl tworzona jest opcja chroot_execlog.

CONFIG_GRKERNSEC_AUDIT_CHDIR

Logowanie wszystkich wywoła´n funkcji chdir(). Je˙zeli wł ˛

czony jest mechanizm sysctl tworzona jest opcja audit_chdir.

CONFIG_GRKERNSEC_AUDIT_MOUNT

Logowanie wszystkich montowa´n i odmontowa´n systemów

plików. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja audit_mount.

CONFIG_GRKERNSEC_AUDIT_IPC

Logowanie tworzenia i usuwania kolejek komunikatów, sema-

forów i pami˛eci współdzielonej. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

audit_ipc

CONFIG_GRKERNSEC_AUDIT_PTRACE

Logowanie wszystkich zako´nczonych sukcesem wywoła´n

funkcji ptrace(). Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja audit_ptrace.

CONFIG_GRKERNSEC_SIGNAL

Logowanie sygnałów takich jak SIFSEGV, które informuj ˛

a o wyst ˛

pieniu bł˛edu w programie. Mo˙ze by´c to spowodowane prób ˛

a wykorzystania np. jakiego´s bł˛edu

przepełnienia bufora.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

signal_logging

CONFIG_GRKERNSEC_FORKFAIL

Loguje niepowodzenia funkcji fork(). Mo˙ze by´c to sygnałem,

˙ze kto´s próbował przekroczy´c swój limit procesów. Je˙zeli wł ˛

aczony jest mechanizm sysctl two-

rzona jest opcja forkfail_logging.

CONFIG_GRKERNSEC_TIME

Logowane s ˛

a wszelkie zmiany czasu zegara systemowego. Je˙zeli wł ˛

czony jest mechanizm sysctl tworzona jest opcja timechange_logging.

Przy konfiguracji tej grupy opcji nale˙zy zwróci´c szczególn ˛

a uwag˛e, na to, co chcemy ˙zeby było

logowane. Przy wł ˛

aczeniu wszystkich opcji na ´srednio obci ˛

a˙zonym serwerze mo˙zemy si˛e spodziewa´c

przybywania logów w tempie kilku MB na minut˛e. W ci ˛

agu krótkiego czasu mo˙ze nam to zaj ˛

a´c cały

obszar przeznaczony na składowanie logów. Pozostaje jeszcze kwestia analizy logów, cz˛e´s´c mo˙zna
oczywi´scie wyfiltrowa´c za pomoc ˛

a narz˛edzi u˙zywaj ˛

acych wyra˙ze´n regularnych, jednak spor ˛

a cz˛e´s´c musi

pó´zniej przejrze´c człowiek. Istniej ˛

a oczywi´scie sytuacje, gdzie jest to dobre rozwi ˛

azanie i wymagane,

gdzie istnieje zwi˛ekszone ryzyko naruszenia bezpiecze´nstwa i wszelkie próby powinny by´c zalogowane.
Opcje te nale˙zy wł ˛

acza´c, maj ˛

ac ´swiadomo´s´c faktu, ˙ze mo˙zemy zosta´c zalani komunikatami, których

obsługa przez syslogd b˛edzie zajmowała wi˛eksz ˛

a cz˛e´s´c zasobów systemu.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Rysunek 5.6: Grupa opcji zabezpiecze´n wykonywania programów

Opcje dotycz ˛

ace wykonywania programów

CONFIG_GRKERNSEC_EXECVE

Ograniczenia ilo´sci uruchomionych procesów b˛ed ˛

a sprawdzane tak˙ze

przy wywołaniu funkcji execve(), a nie tylko, jak jest to wykonywane standardowo przy wywoła-
niach funkcji fork().

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

execve_limiting

CONFIG_GRKERNSEC_DMESG

Zwykli u˙zytkownicy nie b˛ed ˛

a mogli zobaczy´c informacji uzyskanych

poleceniem dmesg, czyli ostatnich 4kb wiadomo´sci zapisanych w buforze logowania kernela. Je-

˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja dmesg.

CONFIG_GRKERNSEC_RANDPID

Opcja zapewnia pseudo-losowe generowanie identyfikatorów pro-

cesów PID. W poł ˛

aczeniu z restrykcjami /proc utrudnia intruzowi zgadywanie numeru PID uru-

chomionych serwisów. Numer PID jest tak˙ze bardzo cz˛esto u˙zywany jako element nazwy pli-
ków tymczasowych, tworzonych przez ró˙zne procesy, wi˛ec losowo´s´c utrudnia przewidzenie nazwy
pliku tymczasowego. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja rand_pids.

CONFIG_GRKERNSEC_TPE

Pozwala wybra´c numer grupy, której członkowie nie b˛ed ˛

a mogli wyko-

nywa´c ˙zadnych plików, które nie znajduj ˛

a si˛e w katalogach, których wła´scicielem jest root i które

mog ˛

a by´c tylko przez niego zapisywane. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest

opcja tpe.

CONFIG_GRKERNSEC_TPE_GLIBC

Opcja powoduje czyszczenie ´srodowiska ze zmiennych specy-

ficznych dla biblioteki glibc takich jak np. LD_PRELOAD. Zmienne te mog ˛

a by´c wykorzystane,

aby omin ˛

a´c ochron˛e zapewnian ˛

a przez Trusted Path Execution. Zabezpiecza ponadto przed

uruchamianiem plików za pomoc ˛

a dynamicznego loadera (np. /lib/ld-linux.so.2). Je˙zeli

wł ˛

aczony jest mechanizm sysctl tworzona jest opcja tpe_glibc.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

CONFIG_GRKERNSEC_TPE_ALL

Wszyscy u˙zytkownicy z wyj ˛

atkiem b˛ed ˛

acych członkami grupy opi-

sanej powy˙zej, mog ˛

a wykonywa´c pliki b˛ed ˛

ace w katalogach, których s ˛

a wła´scicielami i nie s ˛

a one

do zapisu dla wszystkich lub dla grupy, a tak˙ze w katalogach których wła´scicielem jest root i
nie s ˛

a one do zapisu dla wszystkich. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

tpe_restrict_all

CONFIG_GRKERNSEC_TPE_GID

Numer grupy, dla której członków zastosowane zostan ˛

a restrykcje

dotycz ˛

ace Trusted Path Execution. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest

opcja tpe_gid, która musi by´c ustawiana przy ka˙zdym ponownym wł ˛

aczeniu systemu.

Jest to grupa bardzo przydatnych opcji, gdy˙z pozwalaj ˛

a one na ograniczenie mo˙zliwo´sci uruchamia-

nia własnych programów przez u˙zytkowników. W ten sposób kto´s kto przechwyci w jaki´s sposób hasło
u˙zytkownika posiadaj ˛

acego dost˛ep do powłoki, pozwalaj ˛

ace na zalogowanie si˛e na serwerze, nie b˛edzie

mógł uruchomi´c ˙zadnego skopiowanego exploita.

Osobnym zagadnieniem jest dost˛epno´s´c kompilatorów na serwerze. Je˙zeli nie ma istotnych przesła-

nek, aby zwykli u˙zytkownicy mieli do nich dost˛ep, nie powinny one znajdowa´c si˛e na serwerze. Dobrym
rozwi ˛

azaniem jest posiadanie osobnego systemu do celów kompilacji programów, lub je´sli nie jest to

mo˙zliwe lub uzasadnione ekonomicznie, mo˙zna stworzy´c ´srodowisko chroot dost˛epne tylko dla wybra-
nych u˙zytkowników, gdzie b˛ed ˛

a zainstalowane kompilatory i biblioteki. I tego ´srodowiska u˙zywa´c do

kompilacji niezb˛ednych programów.

Opcje dotycz ˛

ace dost˛epu do sieci

CONFIG_GRKERNSEC_RANDID

Opcja powoduje, ˙ze wszystkie pola ID w pakietach wychodz ˛

acych

b˛ed ˛

a losowe. Utrudnia to rozpoznanie systemu operacyjnego oraz uniemo˙zliwia wykorzystanie

serwera jako stacji po´srednicz ˛

acej w idle-scan. Kod odpowiedzialny za losowe generowanie

pakietów pochodzi z systemu OpenBSD

. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest

opcja rand_ip_ids.

CONFIG_GRKERNSEC_RANDSRC

Numer portu ´zródłowego w poł ˛

aczeniach TCP jest generowany lo-

sowo, zamiast normalnie stosowanego algorytmu inkrementacyjnego. Je˙zeli wł ˛

aczony jest mecha-

nizm sysctl tworzona jest opcja rand_tcp_src_ports.

CONFIG_GRKERNSEC_RANDRPC

Numery XID ˙z ˛

ada´n RPC s ˛

a generowane losowo. Je˙zeli wł ˛

aczony

jest mechanizm sysctl tworzona jest opcja rand_rpc.

CONFIG_GRKERNSEC_RANDPING

Odpowiedzi ICMP Echo Reply u˙zywaj ˛

a ID takiego jak odebrany

komunikat ICMP Echo.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

altered_pings

CONFIG_GRKERNSEC_SOCKET

Opcja pozwala na wprowadzenie restrykcji w dost˛epie do gniazdek

sieciowych dla okre´slonych grup u˙zytkowników.

CONFIG_GRKERNSEC_SOCKET_ALL

Opcja pozwala wybra´c grup˛e u˙zytkowników, którzy nie b˛ed ˛

mogli ł ˛

aczy´c si˛e z innymi hostami oraz uruchamia´c ˙zadnych serwisów u˙zywaj ˛

acych gniazdek.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja socket_all.

Strona domowa projektu to http://www.openbsd.org

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Rysunek 5.7: Grupa opcji zwi ˛

azanych ze ´srodowiskiem sieciowym

CONFIG_GRKERNSEC_SOCKET_ALL_GID

Numer grupy, której u˙zytkowników b˛ed ˛

a obowi ˛

azywały

restrykcje w dost˛epie do gniazdek. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

socket_all_gid

, która powinna by´c ustawiana przy ka˙zdym restarcie.

CONFIG_GRKERNSEC_SOCKET_CLIENT

Opcja pozwala wybra´c grup˛e u˙zytkowników, którzy nie

b˛ed ˛

a mogli ł ˛

aczy´c si˛e z innymi hostami, lecz b˛ed ˛

a mogli uruchamia´c serwisy. Je˙zeli wł ˛

aczony jest

mechanizm sysctl tworzona jest opcja socket_client.

CONFIG_GRKERNSEC_SOCKET_CLIENT_GID

Numer grupy, której u˙zytkownicy nie b˛ed ˛

a mogli ł ˛

czy´c si˛e z innymi hostami.

Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

socket_client_gid

, która powinna by´c ustawiana przy ka˙zdym restarcie.

CONFIG_GRKERNSEC_SOCKET_SERVER

Opcja pozwala wybra´c numer grupy, której u˙zytkownicy

nie b˛ed ˛

a mogli uruchamia´c ˙zadnych serwisów. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona

jest opcja socket_server.

CONFIG_GRKERNSEC_SOCKET_SERVER_GID

Numer grupy, której u˙zytkownicy nie b˛ed ˛

a mogli

uruchamia´c własnych serwisów. Je˙zeli wł ˛

aczony jest mechanizm sysctl tworzona jest opcja

socket_server_gid

, która powinna by´c ustawiana przy ka˙zdym restarcie.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Pierwsza grupa opcji pozwala zmniejszy´c prawdopodobie´nstwo rozpoznania rodzaju systemu ope-

racyjnego zainstalowanego na serwerze. Mo˙ze to zniech˛eci´c potencjalnego intruza, gdy˙z utrudnia wy-
korzystanie bł˛edów w uruchomionych serwisach. Intruz musi sprawdzi´c wszystkie odmiany ataków na
dany serwis, je´sli ró˙zni ˛

a si˛e one w zale˙zno´sci od systemu operacyjnego.

Druga grupa opcji pozwala ograniczy´c uruchamianie własnych serwisów przez u˙zytkowników. Dzi˛eki

temu mo˙zliwe jest ograniczenie instalowania wszelkiego rodzaju proxy czy innych usług, dzi˛eki których
ewentualnym bł˛edom intruz ma ułatwione zadanie, oraz mog ˛

acych znacz ˛

aco obci ˛

a˙zy´c sie´c lub sam ser-

wer. Restrykcja dotycz ˛

aca braku mo˙zliwo´sci ł ˛

aczenie si˛e z innymi hostami jest przydatna w przypadku

kont, na których uruchomione s ˛

a serwisy nie wymagaj ˛

ace ł ˛

aczenia si˛e z zewn˛etrznymi hostami, np. ftp.

Opcje dotycz ˛

ace wsparcia mechanizmu

sysctl

Rysunek 5.8: Opcja zwi ˛

azana z mechanizmem sysctl

CONFIG_GRKERNSEC_SYSCTL

Opcja pozwala na zmiany warto´sci opcji GRSecurity, bez potrzeby

ponownej rekompilacji kernela. Klucze które mo˙zna modyfikowa´c po starcie systemu znajduj ˛

si˛e w /proc/sys/kernel/grsecurity. Warto´s´c 1 oznacza wł ˛

aczenie opcji, warto´s´c 0 wył ˛

acze-

nie. Po ustawieniu opcji grsec_lock blokowana jest mo˙zliwo´s´c modyfikacji opcji zwi ˛

azanych z

GRSecurity.

Mo˙zliwo´s´c modyfikacji opcji bez potrzeby rekompilacji kernela jest wygodna, jednak stanowi po-

tencjalne osłabienie restrykcji, jakie zostały nało˙zone przez poprawk˛e GRSecurity. Nale˙zy pami˛eta´c, ˙ze
plik lub skrypt ustawiaj ˛

acy opcje powinien mie´c atrybut tylko do odczytu i powinien mie´c ustawione

odpowiednie opcje ACL.

W systemie Debian modyfikacje opcji mo˙zemy bardzo łatwo przeprowadzi´c korzystaj ˛

ac z pliku

/etc/sysctl.conf

, przykładowy wpis mógłby wygl ˛

ada´c nast˛epuj ˛

aco:

net/ipv4/icmp_ignore_bogus_error_responses=1

kernel/grsecurity/socket_server=1

kernel/grsecurity/socket_server_gid=1010

Opcje dodatkowe

CONFIG_GRKERNSEC_FLOODTIME

Opcja pozwala na wybranie ilo´sci sekund pomi˛edzy logowa-

niem komunikatów GRSecurity. Celem tej opcji jest ochrona przed zalewem logów.

ROZDZIAŁ 5. SYSTEMY ZABEZPIECZE ´

N SYSTEMU LINUX

Rysunek 5.9: Opcje dodatkowe

CONFIG_GRKERNSEC_FLOODBURST

Okre´sla maksymaln ˛

a liczb˛e wiadomo´sci w przedziale czasu

okre´slonym opcj ˛

a powy˙zej.

5.1.4

Podsumowanie mo˙zliwo´sci stoj ˛

acych przed GRSecurity

GRSecurity stanowi obecnie ciekawy dodatek do j ˛

adra Linuxa u˙zywanego w serwerach. Oferuje wiele

mo˙zliwo´sci zabezpieczenia systemu przed eskalacj ˛

a uprawnie´n zdobytych przez intruza ró˙znymi meto-

dami.

U˙zycie poprawek GRSecurity na normalnych stacjach roboczych raczej nie spełni swojej roli, gdy˙z

z racji swej funkcji stacje takie nie powinny udost˛epnia´c ˙zadnych usług ani umo˙zliwia´c logowania si˛e na
nie w ˙zaden sposób. Wi˛ekszo´s´c poprawek udost˛epnianych przez GRSecurity ma wpływ na wydajno´s´c
j ˛

adra, jest to kolejny powód, dla którego ten zestaw łatek jest przeznaczony zdecydowanie na systemy

pełni ˛

ace rol˛e serwerów, nie za´s na proste stacje robocze u˙zytkowników.

Rozdział 6

Podsumowanie

W pracy omówiono program „Snort”, b˛ed ˛

acy sieciowym systemem wykrywania włama´n (NIDS), snif-

fert, tj. programy słu˙z ˛

ace do podsłuchu pakietów na wybranym interfejsie, porcie lub komputerze, jak

równie˙z sciany ogniowe oraz niektóre systemy zabezpiecze´n systemu Linux.

Wi˛ekszo´s´c protokołów internetowych była projektowana, gdy jeszcze w sieci Internet znajdowały

si˛e głównie o´srodki akademickie i było ich niewiele. Nie zawsze przewidziano przy tym mo˙zliwy ich
wpływ na bezpiecze´nstwo systemów. W obecnej chwili pojawiaj ˛

a si˛e coraz lepsze mechanizmy szy-

frowania transmisji, zestawiania sieci prywatnych (VPN) oraz zabezpiecze´n przed podsłuchem. Jednak
jeszcze przez stosunkowo długi czas u˙zywane b˛ed ˛

a powszechnie ´srodki nie zapewniaj ˛

ace ˙zadnej ochrony

przed modyfikacja ich przez intruza. Barier ˛

a jest bardzo cz˛esto opór ze strony u˙zytkowników, a tak˙ze

niekompetencja osób odpowiedzialnych za stan infrastruktury informatycznej lub brak ´srodków na mo-
dernizacj˛e sprz˛etu sieciowego, która w niektórych przypadkach jest wymagana. Tak˙ze przy projektowa-
niu nowych instalacji mo˙ze si˛e pojawi´c bariera ekonomiczna, gdy˙z urz ˛

adzenia sieciowe zapewniaj ˛

ace

wi˛eksz ˛

a mo˙zliwo´s´c kontroli nad sieci ˛

a komputerow ˛

a kosztuj ˛

a cz˛esto wielokrotno´s´c ceny urz ˛

adze´n o

podobnej funkcjonalno´sci, ale o ograniczonych mo˙zliwo´sciach konfiguracyjnych, nie zapewniaj ˛

acych

du˙zego poziomu bezpiecze´nstwa.

Pewnym rozwi ˛

azaniem jest wykorzystanie darmowego, dostarczanego na warunkach licencji

GNU

General Public Licence

systemu Linux oraz programów dla niego dost˛epnych. System ten mo˙ze słu˙zy´c

jako alternatywa dla rozwi ˛

aza´n sprz˛etowych lub systemów komercyjnych, zapewniaj ˛

ac cz˛esto lepsz ˛

funkcjonalno´s´c i ze wzgl˛edu na dost˛epny publicznie kod, umo˙zliwia to łatwe rozszerzanie go o po˙z ˛

adan ˛

funkcjonalno´s´c.

W pracy został wykorzystany system Linux w wersji 2.4.19-pre9, oraz 2.4.18 z łat ˛

a GRSecurity.

U˙zyto dystrybucji Debian

w wersji rozwojowej Sid oraz w wersji testowej, która w najbli˙zszym czasie

stanie si˛e wersj ˛

a stabiln ˛

a - Woody.

Administruj ˛

ac jakimkolwiek systemem komputerowym szczególn ˛

a uwag˛e nale˙zy zwraca´c na szybki

dost˛ep do informacji o nowo odkrytych lukach w oprogramowaniu i regularne ich łatanie. Pomoc ˛

a mog ˛

tu słu˙zy´c organizacje takie jak CERT Coordination Center - http://www.cert.org/.

Dystrybucja ta miała swoje pocz ˛

atki w roku 1993, zapocz ˛

atkował j ˛

a Ian Murdock, za´s jej nazwa pochodzi od imion DEBra

i IAN Murdock. Jest to dystrybucja niekomercyjna, tworzona przez setki osób, w tym kilka z Polski. Oficjalna strona znajduje
si˛e pod adresem http://www.debian.org.

Bibliografia

[1] Martin Roesh „Snort Users Manual”

[2] Information Sciences Institute University of Southern California „RFC 791”

[3] W. Richard Stevens „Unix programowanie usług sieciowych” cz.1

[4] J. Postel „RFC 792”

[5] Information Sciences Institute University of Southern California „RFC 793”

[6] Karl Auer „Samba - serwer plików Windows SMB/CIFS dla Uniksów”

[7] Simson Garfinkel, Gene Spafford „Practical Unix & Internet Security”

[8] D. Brent Chapman, Elizabeth D. Zwicky „Building Internet Firewalls”

[9] „Pubs - Snort”

http://echelon.pl/pubs/snort.html

[10] Ofir Arkin „Network Scanning Techniques - understanding how it is done”

http://www.sys-security.com

[11] Ofir Arkin „ICMP Usage in Scanning - The complete Know-How”

http://www.sys-security.com

[12] ”Virtual LANs Flexible network segmentation for high-speed LANs”

http://www.intel.com/network/connectivity/resources/doc_library/tech_brief/virtual_lans.htm

[13] Rusty Russell „Linux 2.4 Packet Filtering HOWTO”

http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html

[14] Rusty Russell, Harald Welte „Linux netfilter Hacking HOWTO”

http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html

[15] Michał Szyma´nski „Niewidzialny administrator, czyli maskowanie obecno´sci hakera w systemie”

Software 2.0 9/2001

[16] Dominik Kruk „Namierzanie podsłuchu”

PcKurier 9-10/2002

[17] Mariusz Burdach „W˛eszenie w sieci lokalnej z zastosowaniem pakietu dsniff ”

Software 2.0 9/2001

BIBLIOGRAFIA

[18] Jan K. Rutkowski „Przepełnianie buforów i dziwne ła´ncuchy formatuj ˛

ace”

Software 2.0 9/2001

[19] Marcin Dawcewicz „Techniki skanowania sieci komputerowych”

Software 2.0 9/2001

[20] Sharon Gaudin „The enemy within”

http://www.nwfusion.com/research/2000/0508feat.html

[21] R. Azrina, R. Othman „Incident Response Experience in Malaysia”

http://www.certcc.or.kr/concert/5th/data/S3_1_azrina(MyCERT).pdf

[22] „GRSecurity - features” http://www.grsecurity.net/features.htm

Wyszukiwarka

Podobne podstrony:
Co musi zawierac praca id 11813 Nieznany
Praca 4 id 382397 Nieznany
Magnez praca id 276833 Nieznany
ciesn praca id 116790 Nieznany
Praca kontrolna nr 2I id 382664 Nieznany
Praca Licencjacka 2 id 382691 Nieznany
Mudry, praca z czakrami id 3103 Nieznany
praca domowa cw 3 id 382511 Nieznany
praca arch 210117057111 id 3824 Nieznany
kryzysy praca dypl id 251771 Nieznany
Jak pisac praca dyplomowa id 22 Nieznany
praca z geografii id 383862 Nieznany
praca niedosluch id 383707 Nieznany
praca domowa nr 6 id 383980 Nieznany
frag praca dyp AK PR id 180492 Nieznany
przewodnik praca ue[1] id 40732 Nieznany
praca dypl 1 id 382543 Nieznany
3 praca i energia id 33987 Nieznany (2)
Praca nierejestrowana id 383708 Nieznany

więcej podobnych podstron