2006.06_Analiza Naruszeń i Egzekwowanie Polityki Bezpieczeństwa.pdf

Narzędzia

Analiza Naruszeń

i Egzekwowanie Polityki

Bezpieczeństwa

Arrigo Triulzi, Antonio Merola

stopień trudności

W artykule przedstawiamy możliwości wykorzystania Systemu

Detekcji Włamań Sieciowych (ang. Network Intrusion Detection

System, NIDS) jako narzędzia do weryikacji specyicznych

rodzajów awarii zapory oraz jako mechanizmu wspomagającego

egzekwowanie polityki bezpieczeństwa.

wiąże się bezpośrednio z takimi czyn-

nościami jak koniguracja zapory oraz

przygotowanie infrastruktury monitorowania

logów w celu wykrycia ewentualnych nad-

użyć. Niestety, administratorzy zapominają

często o pewnej istotnej sprawie: otóż zapory

ogniowe (tak jak wszystkie inne urządzenia

przetwarzające) są zawodne. Istnieje spo-

ra liczba dobrze znanych błędów w różnych

produktach tego typu, zarówno komercyjnych

jak i wywodzących się z ruchu Open Source.

Zapory są często dzielone na dwie kategorie

w odniesieniu do początkowych założeń kon-

iguracyjnych. Kategoria pierwsza zakłada,

że wszystko to na co nie ma bezpośredniego

przyzwolenia jest zabronione . Drugie podej-

ście opiera się na twierdzeniu, że wszystko

to, co nie jest w bezpośredni sposób zabro-

nione, jest dozwolone . Patrząc z historyczne-

go punktu widzenia, w przeszłości bardziej

popularna była forma druga (tzw. zapory po-

zwalające ), jednak wraz z rozwojem Interne-

tu i pojawianiem się coraz większej liczby za-

grożeń podejście pierwsze zaczęło zyskiwać

coraz więcej zwolenników i stało się równo-

prawną alternatywą. Przy takim podejściu

mamy zazwyczaj do czynienia z tzw. białą li-

stą zasad (ang. white-listing rules ), które de-

iniują dozwolone akcje. Lista ta jest ogra-

niczona pojedynczą zasadą złap-wszystko

(ang. catch-all ), która blokuje wszystkie nie-

pożądane akcje. Pojęcie zasada (ang. rule )

w odniesieniu do zapory, to pewien opis (za-

pisany w formacie zależnym od konkretnego

produktu), który stanowi wskazówkę odno-

śnie traktowania określonego typu ruchu w

sieci. Na przykład, moglibyśmy zdeiniować

Z artykułu dowiesz się...

• wykrywać naruszenia polityki bezpieczeństwa w

odniesieniu do reguł zapory,

• wykrywać błędy w koniguracji zapory,

• stosować mechanizmy egzekwowania polityki

bezpieczeństwa.

Powinieś wiedzieć...

• posiadać przynajmniej podstawową wiedzę na

temat zapór ogniowych oraz narzędzi IDS,

• znać obsługę narzędzi OpenBSD pf oraz

Snort.

hakin9 Nr 6/2006

www.hakin9.org

S formułowanie polityki bezpieczeństwa

Różnicowa Analiza Pracy Zapory

następującą zasadę: zezwalaj na

dostęp do naszej zewnętrznej wi-

tryny korporacyjnej z wewnętrznej

sieci . Tak określona zasada jest ty-

powym przykładem wpisu do białej

listy , jako że deiniuje ona pewne

dozwolone i przewidziane zacho-

wanie. Zadanie zapory polega na

dopasowaniu każdego ruchu poja-

wiającego się w sieci do wpisów na

swojej białej liście . Jeśli dopasowa-

nie będzie udane, ruch zostanie au-

tomatycznie przepuszczony; w każ-

dym innym przypadku ruch zosta-

nie zablokowany i fakt ten zostanie

odnotowany (najprawdopodobniej

w postaci wpisu do loga).

Zastanówmy się jednak co się

stanie gdy zapora ulegnie awarii. I

właśnie w tym momencie pojawia

się problem: okazuje się ruch, któ-

ry powinien być zablokowany może

bez żadnego problemu wpływać do

naszej sieci. Spowodowane jest to

oczywiście brakiem aktywności re-

guły złap-wszystko . Awaria zapory

wiąże się też zazwyczaj z nieprawi-

dłowym działaniem mechanizmu ra-

portowania. Innymi słowy: oprócz te-

go, że podejrzane pakiety mogą bez

problemu penetrować zakątki naszej

sieci, to na dodatek nie pozostanie

po nich żaden namacalny ślad. Sy-

tuację tę można wyobrazić sobie ja-

ko strażnika, który zasnął na służ-

bie: docelowa reguła (np. zatrzy-

muj na wejściu wszystkie obce oso-

by ) jest aktywna, ale nie egzekwo-

wana ze względu na błąd systemu

(strażnik zasnął). Podsumowując, je-

śli przyjmiemy możliwość wystąpie-

nia błędów w zaporze, to nie może-

my pokładać w tym mechanizmie ca-

łego zaufania odnośnie wykrywania

Listing 1. Koniguracja narzędzia OpenBSD pf

ext_if = "ne1"

int_if = "ne2"

ext_ofice = "10.105.0.0/16"

int_lan = "192.168.10.0/24"

int_hosts_auth = "{ 192.168.10.167/32, 192.168.10.168/32, 192.168.10.189/32,

192.168.10.190/32, 192.168.10.213/32, 192.168.10.214/

32, 192.168.10.215/32 }"

( ... )

#Ten wpis będzie blokował cały ruch wchodzący na obydwu interfejsach

block in all

( ... )

#Ten wpis pozwala wewnętrznym hostom int_hosts_auth odwoływać się do sieci

10.105/16

pass in on $ int_if proto tcp from $ int_hosts_auth to $ ext_ofice keep state

lags S / SA

pass out on $ ext_if proto tcp from $ int_hosts_auth to $ ext_ofice modulate

state lags S / SA

( ... )

włamań do naszej sieci. W związku z

tym potrzebujemy jakiegoś dodatko-

wego mechanizmu, który byłby od-

powiedzialny za monitorowanie za-

chowania irewalla.

pimy się na bardziej zaawansowa-

nych produktach, przeznaczonych

do ochrony dużych sieci korpora-

cyjnych.

Transformacja mechanizmów

obsługi koniguracji zapór, od linii

poleceń do zaawansowanych inter-

fejsów graicznych sprawiła, że do

obsługi mechanizmów zabezpie-

czeń sieci korporacyjnej nie potrze-

ba już wysokce wykwaliikowanych

pracowników – dla irmy jest to nie-

wątpliwie duża oszczędność. Jed-

nak z drugiej strony, brak specja-

listycznej wiedzy mści się w przy-

padku kiedy zapora ulega awarii.

W ekstremalnych sytuacjach sła-

bo wykwaliikowany pracownik mo-

że w ogóle nie zauważyć, że coś

się popsuło..

Przy projektowaniu konigura-

cji irewalla dobrą praktyką jest bez-

pośrednie tłumaczenie reguł opisa-

nych w ramach polityki bezpieczeń-

stwa danej organizacji na reguły za-

pory. Prosta, acz efektywna polityka

bezpieczeństwa polega na zabloko-

waniu bezpośredniego dostępu z ze-

wnętrznych sieci do wewnętrznego

intranetu irmy, przy czym cały do-

zwolony ruch przechodzi przez tzw.

pełnomocników (ang. Proxies ). Za-

daniem pełnomocników jest prze-

chwytywanie i weryikacja różnych

typów ruchu w sieci (e-mail, web,

FTP, itd.) i transfer tego ruchu do

Koniguracja zapory:

projektowanie

Sposoby koniguracji zapory ewolu-

ują. Na początku proces ten był po-

strzegany jako czarna magia (ob-

sługa dostępna wyłącznie z pozio-

mu linii komend). Na dzień dzisiej-

szym irewalle oferują użytkowni-

kom zaawansowane interfejsy gra-

iczne typu pokaż i przyciśnij . Za-

pory stały się również bardziej po-

pularne w kręgach mniej doświad-

czonych użytkowników – mamy tu

do czynienia z tzw. personalnymi i-

rewallami, które można instalować

na indywidualnych stacjach robo-

czych. W niniejszym artykule sku-

Rysunek 1. Uproszczona struktura sieci postrzegana z punku widzenia

zapory

www.hakin9.org

hakin9 Nr 6/2006

Narzędzia

właściwych punktów przeznaczenia.

Procedura taka powinna być stoso-

wana zarówno dla ruchu wchodzą-

cego jak i wychodzącego.

Oczywiście i tutaj zdarzają się

tzw. wyjątki prezesa. To ostatnie

określenie wiąże się z faktem, że

wspomniane wyjątki łączą się za-

zwyczaj z dodatkowymi wymagania-

mi ze strony managementu (na przy-

kład żądanie dostępu do wewnętrz-

nej sieci z domu, lub w trakcie podró-

ży). Aby uzyskać tego typu niestan-

dardowe efekty trzeba dodać do za-

pory dodatkowe reguły. Z czasem

wyjątki się mnożą i wolno aczkol-

wiek nieuchronnie polityka prywat-

ności staje się coraz bardziej złożo-

na, co z kolei sprawia trudności przy

monitorowaniu.

Struktura sieci z punktu widze-

nia zapory powinna być jak naj-

prostsza; preferuje się tu wyodręb-

nienie dwóch warstw: wewnętrznej

i zewnętrznej . Oczywiście w prak-

tyce rzeczywistość jest bardziej

skomplikowana – irewalle posiada-

ją zazwyczaj zarówno wielokrotne

warstwy wewnętrzne (np. kilka pod-

sieci w jednej irmie) jak i zewnętrz-

ne (np. połączenia obsługiwane

przez różne podmioty ISP). Zjawi-

sko tego typu wiąże się z często

stosowaną praktyką pakowania jak

największej liczby usług w ramach

pojedynczego systemu. Jako przy-

kład można przytoczyć tu chociaż-

by systemy oferowane przez irmę

Cisco, gdzie router może służyć ja-

ko zapora, switch będź koncentra-

tor linii telefonicznej – wszystko to

w zależności od tego jakie karty

rozszerzeń dołączymy do urządze-

nia. W ramach niniejszego artykułu

będziemy rozważać urządzenie re-

prezentujące zaporę opartą na re-

gułach, która działa w kontekście

dwóch warstw: wewnętrznej i ze-

wnętrznej (patrz Rysunek 1).

Rozważmy prostą zaporę

przedstawioną na Listingu 1. Za-

pora ta opiera się na narzędziu

OpenBSD pf. W tym przykładzie

wewnętrzna warstwa sieci jest zde-

iniowana jako 192.168.10/24, zaś

cała reszta oznacza warstwę ze-

wnętrzną . W warstwie wewnętrznej

deiniujemy adres 10.105/16 jako

zdalną sieć biurową, do której nale-

ży zapewnić dostęp użytkownikom.

Podstawowa zasada naszej polity-

ki bezpieczeństwa mówi, że połą-

czenia przychodzące są dozwolo-

ne tylko wtedy gdy pojawiły się jako

odpowiedzi na żądania wychodzą-

ce z hostów podłączonych do sieci

wewnętrznej . W koniguracji mamy

wpisy deiniujące dziury oraz wyra-

żenia block in all. Zakładamy rów-

nież, że zapora OpenBSD zosta-

ła poprawnie skonigurowana – w

taki sposób, że może działać jako

router, wliczając w to weryikację

koniguracji sieciowych adresów IP.

Aby uzyskać ten efekt należy umie-

ścić wpis net.inet.ip.forwarding=1

w pliku /etc/sysctl.conf , oraz wpis

pf=YES w pliku /etc/rc.conf.local.

Dzięki temu pf będzie się automa-

tycznie włączał i wczytywał swoją

konigurację przy każdym bootowa-

niu systemu.

Przedstawione wyżej zasa-

dy tworzą mechanizm autoryza-

cji dla przepływu ruchu pomię-

dzy określonymi hostami w sieci

192.168.10/24 oraz dowolnym ho-

stem z sieci 10.105/16. Klauzula

block in all będzie blokować każ-

dą inną próbę dostępu. Z teoretycz-

nego punktu widzenia, na tym eta-

pie możemy śmiało powiedzieć, że

żadne nielegalne pakiety nie po-

winny opuścić naszej wewnętrznej

sieci. Pozostaje nam jeszcze koni-

guracja mechanizmu logowania; je-

śli wykonamy ten dodatkowy krok

to wszelkie próby naruszenia zdei-

niowanych powyżej reguł będą wy-

słane do odpowiednich hostów lo-

gujących gdzie będzie je można

monitorować.

Różnicowa Analiza

Pracy Zapory

Posiadając konigurację i przykła-

dową sieć powinniśmy pomyśleć od

wprowadzeniu dodatkowych mecha-

nizmów monitorowania w celu wyła-

pania defektów w działaniu zapory.

Optymalnie byłoby sprawdzać czy

każda z reguł określonych w konigu-

racji została zachowana, ze szcze-

gólnym uwzględnieniem reguły blo-

kującej niepożądany ruch.

W tej sytuacji potrzebna nam

będzie możliwość porównywania

w czasie rzeczywistym ruchu ze-

wnętrznego z ruchem wewnętrznym

i mechanizmu alarmowania jeśli wy-

niki porównania nie będą odpowia-

dać naszym regułom. W tym ce-

lu zmodyikujemy nasz prosty dia-

gram architektury sieci dodając dwa

punkty monitorujące (patrz: Rysu-

nek 2).

We wspomnianych punktach mo-

nitorujących możemy podłączyć do-

wolny Systemu Detekcji Włamań

(ang. Intrusion Detection System,

NIDS), dla którego określimy wyma-

gane zasady. W punktach tych mo-

żemy zastosować zarówno mecha-

nizm odzwierciedlania portów jak i

TAPy w celu przekazania ruchu do

IDS (patrz: ramka Kopiowanie ru-

chu ).

Rysunek 2. Uproszczony schemat przykładowej sieci rozszerzony o punkty

monitorujące

hakin9 Nr 6/2006

www.hakin9.org

Różnicowa Analiza Pracy Zapory

W ramiach niniejszego artyku-

łu jako NIDS użyjemy narzędzia

Snort. Przedstawione tu techniki

mogą być z powodzeniem stosowa-

ne w połączeniu z dowolnym, pro-

gramowalnym narzędziem NIDS

dostępnym na rynku. Na tym eta-

pie najczęściej występującym błę-

dem koncepcyjnym jest ograniczo-

ne myślenie w kategoriach jedne-

go kierunku przepływu ruchu. Co

prawda wykracza to trochę poza

ramy niniejszego artykułu, jednak

postaramy się przedstawić kilka

faktów mocno przemawiających za

tym aby monitorować również ruch

wychodzący. Po pierwsze, warto

wziąć pod uwagę, że najnowsze

wirusy dla systemu Windows, któ-

re oprócz generowania ogromnej

ilości wychodzących wiadomości

email (do których załączone są za-

zwyczaj poufne pliki), otwierają tyl-

ne furtki czy wręcz próbują się bez-

pośrednio połączyć do zewnętrz-

nych systemów. Działanie takie,

określone jest jako dzwonienie do

domu (ang. calling home ), może

prowadzić do całkowitego przeję-

cia przez twórcę (lub twórców) wi-

rusa kontroli nad komputerem oia-

ry. Zainfekowany komputer mo-

że być później nadużywany w nie-

malże dowolny sposób: poczynając

od rozsyłania spamu lub blokowa-

nia sieci IRC, a kończąc na włama-

niach do innych, zewnętrznych sys-

temów lub przechwytywania waż-

nych informacji przy pomocy urzą-

dzeń takich jak drukarki, serwe-

ry druku, narzędzia monitorowania

sieci lub źle skonigurowane opro-

gramowanie.

Gdybyśmy rozważali jedynie ruch

przychodzący, oczywiste byłoby, że

wystarczyłby pojedynczy sensor w

wewnętrznej warstwie naszej sieci.

Sensor ten byłby zaprogramowany

tak, aby sygnalizować wszelkie błę-

dy w koniguracji zapory w sytuacji

kiedy teoretycznie niedopuszczalny

ruch pojawia się w naszej wewnętrz-

nej sieci. Biorąc pod uwagę wysoce

prawdopodobną możliwość pojawie-

nia się niepożądanego ruchu w dru-

gą stronę, należy uznać zasadność

istnienia zewnętrznego sensora.

Kopiowanie ruchu

Aby analizować lub monitorować ruch w sieci trzeba najpierw uzyskać do niego

dostęp; aby sprostać temu zadaniu można wykorzystać hub, SPAN lub TAP. Naj-

bardziej popularna metoda węszenia przepływających pakietów opiera się na hu-

bie – urządzeniu, które potrai powtarzać pakiety na wszystkich interfejsach. W tej

sytuacji wystarczy dla danego sensora bądź sondy przełączyć interfejs na działa-

nie w tryb masowym (ang. promiscuous mode ) – i sprawa załatwiona. Oczywiście,

w sieciach korporacyjnych nie korzysta się z hubów; ze względu na wysoki stopień

zaawansowania tych topologii wykorzystuje się w tym przypadku raczej switche

bądź routery. W takim odniesieniu do śledzenia ruchu należy zaadoptować SPAN

lub TAP. Przyjrzyjmy się różnicom w tych rozwiązaniach. SPAN (skrót od angiel-

skiej nazwy Switched Port Analyzer ) określany jest również mianem odzwierciedla-

nia portów. Mechanizm ten jest bardzo prosty i polega na koniguracji przełączania

portu pod który podłączony będzie sensor lub sonda, tak aby odbierał on ruch z in-

nych portów. Mimo swojej prostoty i faktu, iż mechanizm ten jest wspierany niemal-

że przez wszystkich producentów sprzętu sieciowego, dochodzą tu do głosu pewne

niedogodności: chociażby problem dużego obciążenia sieci, który powoduje prze-

rwy w dostawie pakietów do docelowego portu SPAN; co więcej – również błędne

pakiety oraz występowanie błędów w pierwszej i drugiej warstwie zazwyczaj też łą-

czy się z występowaniem kłopotów. Inny problem wiąże się z pojemnością: na przy-

kład aby rejestrować pełny, dwókierunkowy ruch na każdym łączu o przepustowo-

ści 100 Mbps, SPAN port musiałby mieć pojemność 200 Mbps. Jeśli chcemy unik-

nąć wymienionych tu kłopotów warto rozważyć wykorzystanie TAP.

TAP (skrót od angielskiej nazwy Test Access Port), jest dedykowanym urzą-

dzeniem, zaprojektowanym w celach monitoringowych. Jest to port stałego do-

stępu, pozwalający podłączyć sensor lub sondę w celu pasywnego monitorowa-

nia. TAP przechwytuje pełny ruch - włącznie z błędami i obsługuje dane w trybie

full-duplex, przy czy strumień danych jest rozbity na dwie linie: TX i RX. Ze względu

na ostatni z wymienionych faktów, w celu odtworzenia oryginalnego ruchu potrze-

ba dwóch interfejsów sieciowych; ten sam efekt można uzyskać korzystając z wir-

tualnego interfejsu (więcej szczegółów na ten temat można znaleźć pod adresem

http://sourceforge.net/projects/bonding ). Alternatywna opcja polega na tym aby

użyć narzędzia mergecap (lub czegoś podobnego) w celu stworzenia pojedyncze-

go przepływu z dwóch strumieni danych. Można również podłączyć TAP do switcha

zaś sensor/sondę podpiąć do odzwierciedlonego portu na tym switchu, albo sko-

rzystać z agregatora w postaci portu TAP, dzięki czemu monitorowany port będzie

odbierał cały, połączony strumień ruchu. W sytuacji kiedy mamy do czynienia z za-

awansowaną architekturą sieci wyposażoną w duża liczbę różnego rodzaju sond,

warto rozważyć wykorzystanie sprzętu nowej generacji, takiego jak aparaty wypo-

sażone w wielokrotne łącza sieciowe dla rozproszonych analizatorów. W ramach

dopełnienia zaprezentowanej w tym miejscu zwięzłej analizy metodologii kopiowa-

nia ruchu w sieci, na Rysunku 4 można zapoznać się z typowym schematem podłą-

czenia TAP. Osobom zainteresowanym sugerujemy również przejrzenie poradnika

opisującego zasady rozmieszczania systemów typu IDS, dostępnego pod adresem

http://www.snort.org/docs/#deploy .

Koniguracja NIDS

– sensor wewnętrzny

Zajmijmy się teraz koniguracją we-

wnętrznego sensora. Zbiór reguł bę-

dzie określony tu bardzo prosto:

• Zmienna $INSIDE deiniuje pod-

sieć 192.168.10/24, którą określi-

liśmy wcześniej jako sieć biuro-

wą.

• Zmienna $OUTSIDE deiniuje

wszystko inne: !$INSIDE (sym-

bol wykrzyknika jest używany w

Snort do reprezentacji logiczne-

go operatora not ).

W następnym kroku rozważymy wy-

jątki określone w koniguracji zapo-

ry:

• Zmienna $EXTERNAL_OFFICE

jest zdeiniowana jako sieć, do

której autoryzujemy bezpośred-

www.hakin9.org

hakin9 Nr 6/2006

Narzędzia

nie połączenia, (konkretna war-

tość: 10.105/16).

• Zmienna $INT_HOSTS_AUTH

określa zbiór wewnętrznych syste-

mów, które mogą łączyć się bez-

pośrednio z siecią zewnętrzną. W

notacji Snort zbiór taki zapisze-

my to jako listę adresów umiesz-

czonych w nawiasach kwadra-

towych i rozdzielonych przecin-

kami np. [192.168.10.167,...]. Na

końcu zdeiniujemy kilka oczywi-

stych punktów docelowych, które

będą umieszczone w naszej we-

wnętrznej sieci: web proxy, ser-

wer mailowy oraz serwer DNS.

Zakładamy, że wszystkie te ser-

wisy są zlokalizowane na hoście

192.168.1.1, umieszczonym po ze-

wnętrznej stronie zapory (general-

nie jest to bardzo kiepskie rozwią-

zanie – w świecie rzeczywistym

usługi te powinny być zlokalizowa-

ne w streie ściśle strzeżonej – w

odniesieniu do niniejszego tekstu

zaakceptujemy takie rozwiązanie

ze względu na jego prostotę).

gi wtyczek czy też standardowego

zbioru sygnatur).

strony, jeśli już mamy zainstalowane

narzędzie NIDS, to czemu nie sko-

rzystać z jego rozszerzonych moż-

liwości?

Za dobrą praktykę uważa się

dodawanie lokalnych reguł na po-

czątku pliku z deinicją reguł stan-

dardowych (snort.conf). Przy za-

chowaniu takiej kolejności Snort

będzie najpierw brał pod uwagę

nasze reguły przepuszczające , da-

lej zastosuje swoje reguły standar-

dowe, zaś na końcu zaaplikuje re-

Dodawanie reguł IDS do

wewnętrznego sensora

Warto zapytać się w tym miejscu o

wbudowane reguły Snorta: czy jest

sens aby ich używać? Odpowiedź

zależy od lokalnej koniguracji syste-

mu. Jeśli planujemy użyć Snorta tyl-

ko w celu sprawdzania integralności

naszej zapory, to wspomniane regu-

ły nie są konieczne. Jednak z drugiej

Przyjmijmy więc co następuje:

• Zmienna $SERVICES określa

hosta na którym uruchomione są

wspomniane wyżej serwisy (ad-

res: 192.168.1.1).

Rysunek 3. Schemat podłączenia TAP

W tym miejscu mamy już wszyst-

kie potrzebne informacje potrzeb-

ne do zapisania odpowiednich re-

guł (patrz: Listing 3). Reguły te bę-

dą się odnosić do sieci zaprezento-

wanej na Rysunku 3. Należy zwró-

cić w tym miejscu uwagę na istot-

ność porządku deinicji reguł, jako

że chcemy aby reguły przepusz-

czające miały wyższy priorytet

niż końcowa reguła złap-wszyst-

ko . Wato też wspomnieć, iż w ce-

lu poprawnej obsługi przedstawio-

nego tu pliku koniguracji narzędzie

Snort należy uruchomić z opcją -o.

Dzięki przekazaniu tej opcji silnik

obsługi reguł będzie działał w try-

bie pass, log, alert . Przedstawiony

zbiór reguł jest bardzo mały i przez

to nie było okazji wykorzystać tu

wielu bardzo przydatnych właści-

wości narzędzia Snort (np. obsłu-

Rysunek 4. Uproszczona sieć ze zdeiniowanym punktem monitorowania

hakin9 Nr 6/2006

www.hakin9.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: