Tomasz Derlecki Michał Dworakowski

Prezentacja na temat: "Tomasz Derlecki Michał Dworakowski "— Zapis prezentacji:

1 Tomasz Derlecki Michał Dworakowski Polityka zabezpieczeń na styku sieci LAN i Internet w oparciu o systemy BSD

2 Wstęp Nieustający postęp techniczny z jakim mamy do czynienia w ostatnich latach powoduje, że komputery stają się nieodłącznym elementem działalności człowieka. Coraz więcej osób w swoim życiu codziennym zarówno w pracy, domu czy szkole wykorzystuje komputery do wymiany informacji. Sprzyja to rozwojowi sieci lokalnych oraz zwiększeniu dostępności do globalnych zasobów Internetu.

3 Wstęp Kiedy mamy już zbudowaną sieć lokalną, oraz zapewniony dostęp do Internetu należy zastanowić się nad następującymi pytaniami: Jak oddzielić nasza sieć lokalna od Internetu przy jednoczesnym zachowaniu możliwości korzystania z jego zasobów? - NAT W jaki sposób kontrolować i zabezpieczyć naszą sieć lokalną? – Firewall („zapora ogniowa”)

4 Router sprzętowy Istnieje kilka sposobów podłączenia sieci lokalnej do Internetu: Możliwe jest tu zastosowanie rozwiązania sprzętowego – komputery z naszej sieci lokalnej podłączone są do urządzenia zwanego routerem, które w zależności od technologii zapewnia nam dostęp do światowych zasobów sieci Internet.

5 Router sprzętowy

6 Router programowy Przez pojęcie routera programowego rozumiemy autonomiczny komputer, który posiada co najmniej dwa interfejsy sieciowe oraz odpowiednie oprogramowanie umożliwiające routowanie pakietów sieciowych.

7 Router programowy Podstawowa zaleta zastosowania routera programowego jest możliwość uruchomienia dodatkowych usług na takim komputerze np. serwery FTP czy www. Dodatkowo mamy możliwość skonfigurowania „zapory ogniowej” oraz NATa. A co najważniejsze w przypadku zastosowania oprogramowania open source takie rozwiązanie jest dużo tańsze gdyż nie jest do tego wymagany komputer wysokiej klasy i nie musimy kupować drogiego oprogramowania.

8 FreeBSD Jednym z takich rozwiązań dla routerów programowych może być FreeBSD jest to zaawansowanym systemem operacyjnym BSD UNIX dla komputerów zgodnych z architekturą Intel (x86), DEC Alpha. Jest on dostępny bezpłatnie i  z pełnym kodem źródłowym.

9 Ściany ogniowe oparte o IP Filter
IP Filter (ipf) usługa ściany ogniowej o sporych możliwościach, która umożliwia nam filtrowanie pakietów na wielu poziomach. Posiada ona plik konfiguracyjny (ipf.rules) zgodny z filozofią Unixa: każda nowa linia to reguła znak '#' oznacza komentarz, można również wpisać regułę i po niej komentarz w jednej linii

10 Ściany ogniowe oparte o IP Filter
Zanim zaczniemy korzystać z ipfilter oraz z ipfnat należy do pliku konfiguracyjnego /etc/rc.conf dodać następujące wpisy: ipfilter_enable="YES" ipfilter_rules="/etc/ipf.rules" ipnat_enable="YES" ipnat_rules="/etc/ipnat.rules Dodatkowo aby nasz kernel obsługiwał ipf należy skompilować jądro z następującymi wpisami konfiguracyjnymi: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK

11 ipf.rules Reguły zawarte w pliku ipf.rules przetwarzane są z góry na dół, oznacza to ze jeśli plik konfiguracyjny będzie miał postać: #blokowanie wszystkich wchodzących pakietów block in all #wpuszczanie wszystkich wchodzących pakietów pass in all Jeśli teraz do dowolnego interfejsu sieciowego dotrze pakiet to IPF zaczyna go przetwarzać. Znajduje pierwsza regułę odpowiadającą temu pakietowi - decyduje o zablokowaniu tego pakietu. Szuka w pliku następnej reguły dotyczącej tego pakietu – wpuszcza pakiet. Ponieważ ostatnia reguła decyduje o wpuszczeniu pakietu to pakiet zostaje wpuszczony.

12 ipf.rules Tak więc widać że IPF wykonuje ostatnią napotkaną regułę jaką znajdzie dla danego pakietu. Jeśli chcielibyśmy to zmienić, to znaczy spowodować aby IPF wykonywał pierwszą napotkaną regułę dla danego pakietu należy zastosować słowo kluczowe quick. Przykład: block in quick all pass in all W tym przypadku nie nastąpi przejście do drugiej reguły, gdyż na podstawie pierwszej reguły każdy przychodzący pakiet jest natychmiastowo odrzucany – IPF nie przechodzi do następnych reguł dla tego pakietu.

13 ipf.rules – filtrowanie po adresie IP
Jednym z najczęstszych kryteriów filtrowania jest adres IP, przykładowo jeśli nie chcielibyśmy otrzymywać pakietów z zakresu sieci nieroutowalnej, /16 (/16 to zapis maski w postaci CIDR, maskę można również podawać w postaci zapisu decymalnego, ) to reguła powinna wyglądać następująco: block in quick from /16 to any pass in all

14 ipf.rules – filtrowanie po adresie IP
Poniższy przykład przedstawia zapis reguł blokujących tzw. adresy nierutowalne a przepuszczający wszystkie inne zakresy adresów: block in quick from /16 to any block in quick from /12 to any block in quick from /8 to any pass in all

15 ipf.rules – filtrowanie po interfejsie sieciowym
Jak już wcześniej mówiliśmy router, a w szczególności router programowy posiada co najmniej dwa interfejsy sieciowe. Załóżmy, że nasz router oparty o FreeBSD posiada 2 karty sieciowe. Za pośrednictwem pierwszej nazwijmy ja nic0 nasz provider dostarcza nam Internet, zaś drugi interfejs sieciowy nic1 spięty jest z koncentratorem sieciowym, który odpowiada za nasza sieć lokalną. Istnieje jeszcze jeden interfejs sieciowy, jest to pętla zwrotna, którą będziemy nazywać lo0. Ipf daje nam możliwość stosowania reguł dla konkretnego interfejsu sieciowego.

16 ipf.rules – filtrowanie po interfejsie sieciowym
Wyobraźmy sobie, że na interfejsie publicznym nic0, nie chcemy żadnych adresów nierutowalnych a na interfejsie prywatnym nic1 i pętli zwrotnej lo0 chcemy przepuszczać wszystko. Wtedy zestaw reguł powinien wyglądać następująco: block in quick from on nic /16 to any block in quick from on nic /12 to any block in quick from on nic /8 to any pass in all

17 ipf.rules – filtrowanie po interfejsie sieciowym
Do tej pory blokowaliśmy tylko pakiety wejściowe, ale załóżmy np. że nie chcemy aby nasze pakiety docierały do hosta o adrsie IP (eden-tp.tu.kielce.pl alias Dla takiej sytuacji wpis w pliku /etc/ipf.rules powinien być następujący: block out quick on nic0 from any to /32

18 ipf.rules –logowanie informacji o danej regule
Jeśli chcielibyśmy wiedzieć czy nasza reguła została zastosowana do jakiś konkretnych pakietów (np. czy pakiety zostały zablokowane albo wpuszczone) należy dodać do danej reguły słowo log. Przykład: block out log quick on nic0 from any to /32

19 ipf.rules – filtrowanie konkretnych protokołów
Ipf umożliwia również filtrowanie pakietów na podstawie konkretnego protokołu. Za pomocą słowa proto możemy blokować lub przepuszcać pakiety tcp, udp i icmp. block in log quick on nic0 proto icmp from any to any Powyższy wpis spowoduje, że każdy pakiet icmp nadchodzący przez nic0 będzie logowany i odrzucany. W przypadku pakietów icmp mamy dodatkowo możliwość filtrowania typu pakietu, jest to możliwe dzięki klauzurze icmp-type. Jeśli chcielibyśmy aby działały polecenia traceroute i ping, to musimy przepuszczać pakiety icmp typu 0 i 11. pass in quick on nic0 proto icmp from any to any icmp-type 0 pass in quick on nic0 proto icmp from any to any icmp-type 11

20 ipf.rules – filtrowanie portów
Słowo kluczowe port umożliwia filtrowanie pakietów przeznaczonych na konkretny port. Niektóre usługi protokołu tcp używają ściśle określonego portu (np. ssh używa portu 22). Załóżmy że ze względów bezpieczeństwa na interfejsie nic0 chcielibyśmy zablokować ten port zaś w lokalnej sieci nic1 odblokujemy ten port. pass in quick on nic1 proto tcp from any to any port = 22

21 ipf.rules – keep state IPF potrafi śledzić połączenia i stwierdzić czy połączenie jest nawiązane czy nie. Robi to zarówno dla pakietów TCP, UDP i ICMP. Nazywa się to utrzymywaniem stanu i do zastosowania w regule ipf konieczne jest użycie słowa kluczowego keep state. block out quick on nic0 all pass in quick on nic0 proto tcp from any to /32 port = 22 keep state W momencie, w którym pierwszy pakiet SYN dociera do serwera, tworzona jest pozycja w tabeli stanu i reszta sesji ssh jest przepuszczana bez żadnej ingerencji ze strony ściany ogniowej.

22 ipf.rules – flags Problem polega na tym, że nie tylko pakiety SYN mogą dotrzeć do danego portu, ale również inne, stare pakiety. Możemy to zmienić przez zastosowanie słowa kluczowego flags: pass in quick on nic0 proto tcp from any to /32 port = 23 flags S keep state pass out quick on nic0 proto tcp from any to any flags S keep state block in quick all block out quick all

23 ipf.rules – flags Obecnie tylko pakiety TCP, skierowane do na port 23 z ustawioną tylko flagą SYN mogą dotrzeć i utworzyć pozycję w liście stanów. Samotna flaga SYN ustawiona jest tylko w pierwszym pakiecie sesji TCP (zwanej pakietem nawiązującym połączenie TCP) i to jest to co chcieliśmy tak naprawdę uzyskać. Są przynajmniej dwie zalety takiego zapisu: nie dotrą do nas żadne inne pakiety które mogłyby namieszać w tabeli stanów. Po drugie, skany portów nie powiodą się ponieważ mają ustawione również inne flagi oprócz SYN. Aktualnie, wszystkie przychodzące pakiety muszą być albo nawiązującymi połączenie albo już do niego należeć. Jeśli nadejdzie cokolwiek innego, jest albo spreparowane albo jest skanem portów

24 ipf.rules – keep frags Pojawia się jeszcze pytanie co się stanie gdy dociera do nas pakiet sfragmentowany. IPF jest przygotowany na obsługę takich sytuacji, z pomocą słowa kluczowego keep frags. Przy jego zastosowaniu, IPF będzie potrafił śledzić również sesje z pakietami, które są sfragmentowane i pozwoli im przejść pass in quick on nic0 proto tcp from any to /32 port = 23 _ flags S keep state keep frags pass out quick on nic0 proto tcp from any to any keep state flags S _ keep frags block in log quick all block out log quick all

25 Odpowiadanie na zablokowane pakiety
Dotychczas we wszystkich pokazanych regułach, które odrzucały pakiet nie było żadnej odpowiedzi od naszej ściany ogniowej do hosta który przysłał nam ten pakiet. Może to sugerować osobie wysyłającej taki pakiet, że korzystamy z jakiegoś zestawu firewall’a. Dlatego dobrze by było zmylić takiego intruza odsyłając mu komunikat, że dana usługa nie działa. W przypadku protokołu TCP najczęściej odsyłany jest komunikat RST (Reset). Aby stworzyć taką regułę należy użyć słowa kluczowego return-rst block return-rst in log proto tcp from any to /32 port = 23 block in log quick on nic0 pass in all Potrzebujemy dwóch reguł block, ponieważ return-rst działa tylko dla TCP, a my nadal chcemy zablokować protokoły takie jak UDP i ICMP

26 Odpowiadanie na zablokowane pakiety
Możliwe jest również odsyłanie wiadomości z odpowiednim komunikatem icmp, gdy ktoś wysyła pakiet UDP do portu w naszym systemie. block return-icmp(port-unr) in log quick on nic0 proto udp _ from any to /32 port = 131 port-unr ( port nieosiągalny ) jest prawidłowym komunikatem odpowiedzi ICMP jeśli na danym porcie nie nasłuchuje żadna usługa. Możemy użyć tu dowolnego typu ICMP, ale port-unr jest prawdopodobnie najlepszą odpowiedzią. Jest również domyślna w przypadku użycia return-icmp.

27 Odpowiadanie na zablokowane pakiety
Pozostaje jeszcze drobny problem ponieważ return-icmp, zwraca pakiet ICMP z adresem ściany ogniowej, a nie adresem maszyny dla której pakiet był przeznaczony. Zostało to jednak naprawione i w ipfilter od wersji 3.3 dodano nowe słowo kluczowe: return-icmp-as-dest block return-icmp-as-dest(port-unr) in log quick on nic0 _ proto udp from any to /32 port = 131

28 ipf.rules – fastroute Nasza ściana ogniowa potrafi już blokować lub przepuszczać pakiety według różnych kryteriów ale dla wszystkich pakietów zmniejszany jest TTL. Możemy jednak ukryć swoją obecność przed zbyt dociekliwymi aplikacjami takimi jak unix'owy traceroute, który używa pakietów UDP z różnymi TTL by zmapować ilość przejść pomiędzy dwoma komputerami. Jeśli chcemy, by nadchodzące traceroute działało, ale nie chcemy oświadczać że mamy tu ścianę ogniową która spowoduje dodanie jednego przejścia, możemy zrobić to regułą taką jak ta: block in quick on nic0 fastroute proto udp from any to any _ port >< 33465

29 ipnat.rules map nic0 192.168.1.0/24 -> 212.224.138.8/32
Każdy pakiet wychodzący przez interfejs nic0 ze źródłowym adresem /24, jest zamieniany jeszcze na stosie IP, tak by zawierał adres źródłowy a dopiero wtedy zostaje wysłany do swojego celu przeznaczenia. System utrzymuje listę jakie zamapowane połączenia są w trakcie tak by mógł wykonać czynność odwrotną gdy nadejdzie odpowiedź (skierowana do ) i odesłać ją do oryginalnego nadawcy.

30 ipnat.rules Problem pojawia się w przypadku kiedy nie wiemy jaki mamy adres IP naszego zewnętrznego interfejsu. Wtedy ustawienie tablicy NAT staje się dość problematyczne. Na szczęście NAT jest na tyle mądry, że potrafi zaakceptować adres w postaci 0/32. Sygnalizuje to, że musi sprawdzić sobie sam jaki właściwie adres ma interfejs zewnętrzny i prawidłowo zmodyfikować pakiet. map nic /24 -> 0/32

31 ipnat.rules Pozostaje pytanie, co dzieje się z portem źródłowym gdy wykonywane jest mapowanie. W przypadku wcześniej pokazanych reguły, port źródłowy pakietu nie zostaje zmieniony w stosunku do oryginału. W niektórych przypadki jednak nie chcemy by tak się działo. Po drodze może być jeszcze jedna ściana ogniowa, lub wiele maszyn będzie próbowało używać tego samego portu. Może to powodować kolizje i pakiet jest przepuszczany bez mapowania. ipnat pomaga w tym momencie, poprzez dostarczenie słowa kluczowego portmap: map nic /24 -> 0/32 portmap tcp/udp 1024:65535

32 ipnat.rules Niektóre aplikację wymagają pracy na publicznym adresie IP (powiedzmy że dla nas ten adres to )oraz konkretnym porcie (np. 443), pojawia się trudność kiedy chcemy korzystać z dobrodziejstw takiej aplikacji uruchomionej w naszej sieci lokalnej (np.. Na komputerze z adresem ). Aby rozwiązać ten problem, instruujemy NATa aby przemapował wszystkie połączenia przeznaczone dla :443 (publiczny interfejs) na :555. Forwardowanie portów możemy osiągnąć za pomocą słowa kluczowego rdr: rdr nic /32 port 443 -> _ /24 port 555

33 Dziękujemy za uwagę.