IP Filter to fajna, mała paczka ściany ogniowej. Robi prawie wszystko co inne, darmowe (ipfwadm, ipchains, ipfw), ale oprócz tego jest również przenośna między platformami i potrafi parę ciekawych rzeczy których inne nie robią. Dokument ma na celu zebranie wiedzy ze śladowej dokumentacji dostępnej do tej pory dla ipfilter. Co więcej, dokument ten może służyć jako dokumentacja do filtrów pakietów zgodnych na poziomie opcji (w szczególności pf) a jeśli to będzie potrzebne wskaże różnice; jest jednak adresowany do specyficznego języka opisu reguł i ich składni, a także nie pisano go pod kątem konkretnej platformy. Wskazana jest podstawowa znajomość zagadnień filtrowania pakietów, choć z drugiej strony jeśli zbyt dobrze się w tym orientujesz, czytanie tego dokumentu jest prawdopodobnie stratą czasu. By lepiej zrozumieć zagadnienia związane ze ścianami ogniowymi, autorzy polecają lekturę 'Building Internet Firewalls', autorstwa Chapman & Zwicky, wydawnictwa O'Reilly and Associates; oraz 'TCP/IP Illustrated, Volume I', Stevens, Addison-Wesley.

Autorzy tego dokumentu ( ani tłumacz! - przyp. tłum. ) nie są odpowiedzialni za żadne uszkodzenia wynikłe w wyniku podejmowania akcji bazujących na lekturze tego dokumentu. Dokument ten pomyślano jako wprowadzenie do budowy ścian ogniowych opartych o IP-Filter. Jeśli nie czujesz się dobrze biorąc odpowiedzialność za swoje czyny, powinieneś przestać czytać ten dokument i wynająć wykwalifikowany personel by zainstalował dla ciebie ścianę ogniową.

Tam gdzie nie napisano inaczej, prawa autorskie dokumentów HOWTO należą do ich autorów. Dokumenty HOWTO mogą być reprodukowane i dystrybuowane w całości lub w części, na każdym nośniku fizycznym lub elektronicznym, tak długo jak informacje o prawach autorskich zostaną dołączone do każdej kopii. Komercyjna redystrybucja jest również zezwolona i jak najbardziej zachęcamy do niej; jednakże autorzy życzą sobie zostać o takim fakcie poinformowani.

Wszystkie tłumaczenia, prace oparte o ten dokument, lub prace zbiorowe zawierające dowolne HOWTO muszą opierać się na tej samej filozofii praw autorskich. To znaczy, nie możesz pisać prac opartych o HOWTO i narzucać jakieś dodatkowe ograniczenia na jego dystrybucję. Mogą się jednak zdarzyć wyjątki od tych reguł - proszę skontaktować się z koordynatorem HOWTO.

Krótko mówiąc, chcemy promować informacje przekazywane w tym dokumencie przez tyle dróg ile się da. Jednak życzymy sobie zachować prawa autorskie do tego HOWTO, i chcielibyśmy być informowani o jakichkolwiek planach redystrybuowania tego HOWTO.

Oficjalna strona IP Filter znajduje się pod adresem http://coombs.anu.edu.au/~avalon/ip-filter.html.

Kompatybilny filtr pakietów na licencji BSD znajduje się pod adresem http://www.benzedrine.cx/pf.html.

Najaktualniejszą wersję tego dokumentu można znaleźć pod adresem: http://www.obfuscation.org/ipf/

Tą sekcję napisaliśmy tak, by zapoznać się ze składnią poleceń ipfilter, oraz teorią ścian ogniowych w ogólności. Możliwości które tu opisano znajdziesz w każdej dobrej paczce ściany ogniowej. Ta sekcja da Ci solidne podstawy, tak by lektura i zrozumienie sekcji zaawansowanej było bardzo łatwe. Należy podkreślić, że przeczytanie tylko tej sekcji nie wystarczy do zbudowania dobrej ściany ogniowej, a zapoznanie się z sekcją zaawansowaną jest absolutnie wymagana dla każdego kto chce zbudować efektywny system bezpieczeństwa.

IPF ( Filtr IP ) posiada plik konfiguracyjny ( w przeciwieństwie do trybu pracy w której uruchamia się cały czas komendy dla każdej nowej reguły ). Plik konfiguracyjny jest zgodny z filozofią Unixa: każda nowa linia to reguła, znak '#' oznacza komentarz, możesz również wpisać regułę i po niej komentarz w jednej linii. Oczywiście dozwolone są również nadmiarowe spacje, a nawet poleca się je by zestawy reguł był czytelniejszy.

Reguły przetwarzane są z góry na dół, każda dodawana po poprzedniej. Oznacza to po prostu, że jeśli cały Twój plik konfiguracyjny wygląda tak:

block in all
pass  in all

...komputer widzi go jako:

block in all
pass  in all

Co oznacza, że po otrzymaniu pakietu, IPF najpierw stosuje regułę:

block in all

Jeśli IPF uzna, że należy przejść do następnej reguły, zinterpretuje ją:

pass  in all

W tym momencie możesz zadać sobie pytanie "a uzna, że należy przejść do następnej reguły?". Jeśli znany jest ci ipfwadm czy ipfw, prawdopodobnie nie zadasz sobie tego pytania. Potem będziesz mocno zdziwiony, dlaczego pakiety są odrzucane lub przepuszczane, podczas gdy wskazałeś inaczej. Wiele filtrów pakietów przestaje porównywać pakiety w momencie, gdy znajdą pierwszą regułę która pasuje. IPF nie jest jednym z nich.

Odmiennie, niż w przypadku innych filtrów pakietów, IPF utrzymuje flagę czy przepuścić pakiet czy nie. Dopóki nie przerwiesz porównywania, IPF sprawdzi cały zestaw reguł i podejmie decyzję czy przepuścić pakiet czy nie, na podstawie ostatniej pasującej reguły. Wygląda to tak: IPF pracuje. Dostał kawałek czasu procesora. Ma przed sobą listę do sprawdzenia, która wygląda tak:

block in all
pass  in all

Do interfejsu dociera pakiet i trzeba zabrać się do pracy. Pobiera pakiet i sprawdza pierwszą regułę:

block in all

IPF stwierdza "Jak na razie, zablokuję ten pakiet". Następnie ogląda drugą regułę:

pass  in all

"Jak na razie, wpuszczę ten pakiet", stwierdza IPF. Potem patrzy na trzecią regułę. Nie ma jej, więc sprawdza jaką decyzję podjął ostatnio - przepuścić pakiet.

W tym momencie nadszedł dobry moment by zauważyć, że nawet gdyby zestaw reguł wyglądał tak:

block in all
block in all
block in all
block in all
pass  in all

To i tak pakiet zostałby przepuszczony. Nie istnieje tutaj coś takiego jak efekt kumulacyjny. Ostatnia pasująca reguła zawsze decyduje o losie pakietu.

Jeśli miałeś już do czynienia z innymi filtrami pakietów, możesz stwierdzić że ten sposób organizacji przetwarzania jest mylący, możesz również spekulować że istnieją problemy z przenoszalnością do innych filtrów oraz, że prędkość przetwarzania reguł może być mała. Wyobraź sobie że masz 100 reguł i wszystkie pasujące były pierwszymi 10. Dla każdego pakietu sprawdzenie pozostałych reguł byłoby wielką stratą czasu. Na szczęście, istnieje proste słowo kluczowe które możesz dodać do reguły by od razu spowodować reakcję. Tym słowem jest quick.

Poniżej przedstawiono zmodyfikowaną wersję oryginalnego zestawu, tym razem z nową komendą.

block in quick all
pass  in       all

W tym przypadku, IPF sprawdza pierwszą regułę:

block in quick all

Pakiet pasuje i przeglądanie reguł na nim się kończy. Pakiet zostaje odrzucony bez żadnego piśnięcia. Nie ma żadnych komunikatów, logów, konduktu pogrzebowego. Ciasto nie zostanie podane. Co więc z następną regułą?

pass  in       all

Do tej reguły IPF nigdy nie dociera. Mogłoby jej w ogóle nie być w pliku konfiguracyjnym. Działanie reguły all i słowo quick w poprzedniej regule powoduje, że nie są już sprawdzane żadne inne reguły.

Sytuacja w której połowa pliku konfiguracyjnego do niczego się nie przydaje, jest raczej stanem niepożądanym. Z drugiej strony, IPF ma za zadanie powstrzymywać pakiety tak jak został skonfigurowany, i robi bardzo dobrą robotę. Tak czy inaczej, IPF jest również po to by niektóre pakiety przepuszczać, więc wymagana jest pewna zmiana reguł by to zadanie zrealizować.

IPF może sprawdzać pakiety pod kątem wielu kryteriów. Jednym z tych o których myślimy najczęściej jest adres IP. Istnieją pewne zakresy przestrzeni adresowej z których nigdy nie powinniśmy otrzymywać żadnych pakietów. Jednym z takich zakresów jest sieć nieroutowalna, 192.168.0.0/16 ( /16 to zapis maski w postaci CIDR. Możesz być bardziej przyzwyczajony do zapisu decymalnego, 255.255.0.0 - IPF akceptuje obydwa ). Jeśli chciałbyś zablokować 192.168.0.0/16, jednym ze sposobów jest:

block in quick from 192.168.0.0/16 to any
pass  in       all

Tym razem mamy w końcu zestaw reguł który coś dla nas robi. Wyobraźmy sobie, że dociera do nas pakiet z adresu 1.2.3.4. Sprawdzana jest pierwsza reguła:

block in quick from 192.168.0.0/16 to any

Pakiet przyszedł z adresu 1.2.3.4 a nie z 192.168.*.*, więc reguła nie pasuje. Sprawdzana jest druga reguła:

pass  in       all

Pakiet przyszedł z adresu 1.2.3.4, który zdecydowanie należy do all ( czyli dowolnego adresu ), więc jest wysyłany tam gdzie chciałby dotrzeć.

Z drugiej strony, przypuśćmy że otrzymaliśmy pakiet z adresu 192.168.1.2. Sprawdzana jest pierwsza reguła:

block in quick from 192.168.0.0/16 to any

Pakiet pasuje, więc jest odrzucany i to koniec. Ponownie, IPF nie sprawdza drugiej reguły, ponieważ pierwsza reguła która pasowała, zawierała słowo quick.

W tym momencie możesz zbudować rozszerzalny zestaw adresów, z których niektóre należy zablokować a niektóre przepuścić. Ponieważ już zaczęliśmy blokować zakresy adresów prywatnych na naszej ścianie ogniowej, zadbajmy o resztę:

block in quick from 192.168.0.0/16 to any
block in quick from 172.16.0.0/12 to any
block in quick from 10.0.0.0/8 to any
pass  in       all

Pierwsze trzy reguły blokują niektóre z zakresów adresów prywatnych.

Często zdarza się, że firmy mają najpierw sieć wewnętrzną, zanim zechcą podłączyć się do świata zewnętrznego. Tak naprawdę, sensowne wydaje się założenie, że to główny powód dla którego ludzie w ogóle rozważają ściany ogniowe. Maszyna, która pełni rolę mostu ( ang. bridge ) między siecią wewnętrzną a siecią zewnętrzną jest routerem. Router od każdej innej dowolnej maszyny różni jedna podstawowa cecha: ma więcej niż jeden interfejs.

Każdy pakiet który otrzymujesz, przychodzi którymś interfejsem sieciowym; każdy pakiet który wysyłasz wychodzi również interfejsem sieciowym. Powiedzmy że masz trzy interfejsy: pętlę zwrotną - lo0 ( ang. loopback ), xl0 ( kartę ethernetową 3COM ) i tun0 ( podstawowy tunel we FreeBSD którego używa PPP ), ale nie chcesz otrzymywać pakietów przychodzących z interfejsu tun0?

block in quick on tun0 all
pass  in               all

W tym przypadku słowo on oznacza identyfikację danych przybywających wskazanym interfejsem. Jeśli pakiet przychodzi do interfejsu tun0 ( 'on tun0' ), pierwsza reguła go zablokuje. Jeśli pakiet przyjdzie do interfejsu lo0 lub xl0, pierwsza reguła nie będzie pasowała, a druga tak i pakiet zostanie przepuszczony.

To dziwny stan, w którym decydujesz, że chcesz mieć interfejs podniesiony ( w naszym przypadku tun0 ), ale nie chcesz otrzymywać przez niego pakietów. Czym więcej jest kryteriów które sprawdza ściana ogniowa, tym jest bardziej szczelna ( lub przeciekająca ). Może chcesz otrzymywać dane przez tun0, ale nie od 192.168.0.0/16? To początek potężnej ściany ogniowej.

block in quick on tun0 from 192.168.0.0/16 to any
pass  in               all

Porównaj to do naszego poprzedniego zestawu reguł:

block in quick from 192.168.0.0/16 to any
pass  in       all

Blokujemy w nim każdy ruch pochodzący z 192.168.0.0/16, niezależnie od interfejsu. W nowym zestawie reguł, w którym używamy słów 'on tun0' blokujemy tylko pakiety, które dotarły przez interfejs tun0. Gdyby pakiet przybył interfejsem xl0 zostałby wpuszczony.

W tym momencie możesz zbudować rozszerzalny zestaw adresów, z których niektóre należy zablokować a niektóre przepuścić. Ponieważ już zaczęliśmy blokować zakresy adresów prywatnych które docierają do interfejsu tun0, zajmijmy się resztą:

block in quick on tun0 from 192.168.0.0/16 to any
block in quick on tun0 from 172.16.0.0/12 to any
block in quick on tun0 from 10.0.0.0/8 to any
block in quick on tun0 from 127.0.0.0/8 to any
block in quick on tun0 from 0.0.0.0/8 to any
block in quick on tun0 from 169.254.0.0/16 to any
block in quick on tun0 from 192.0.2.0/24 to any
block in quick on tun0 from 204.152.64.0/23 to any
block in quick on tun0 from 224.0.0.0/3 to any
pass  in       all

Widziałeś już pierwsze trzy reguły, ale nie resztę. Czwarta wskazuje klasę A, w większości zmarnowaną, a używaną głównie na pętle zwrotne. Wiele oprogramowania komunikuje się ze sobą przez adres 127.0.0.1, więc zablokowanie tego adresu przy połączeniach z zewnątrz to też dobry pomysł. Piąta linia, 0.0.0.0/8 nigdy nie powinna znaleźć się w Internecie. Większość stosów IP traktuje 0.0.0.0/32 jako domyślną bramę, a reszta sieci 0.*.*.* jest traktowana na różne dziwne sposoby, co wynika ze sposobu w jaki podejmowane są decyzję o routingu. Powinieneś traktować 0.0.0.0/8 tak jak 127.0.0.0/8. 169.254.0.0/16 zostało przydzielone przez IANA do użytku w procesie auto-konfiguracji, kiedy system nie otrzymał jeszcze adresu IP z serwera DHCP lub podobnego. Należy zwrócić uwagę, że w szczególności Microsoft Windows będą używać adresów z tego zasięgu gdy ustawione są na używanie DHCP a nie były w stanie znaleźć do tej pory serwera DHCP. 192.0.2.0/24 został również zarezerwowany dla użytku autorów dokumentacji jako przykład dzielenia na bloki. Celowo nie używamy tego zakresu, ponieważ mógłby on spowodować zamieszanie gdybyś je zablokował; wszystkie nasze przykłady używają adresów 20.20.20.0/24. 204.152.64.0/23 to blok zarezerwowany przez Sun Microsystems dla prywatnych połączeń klastrów, i zablokowanie go pozostawiamy tobie pod rozwagę. Na koniec, 224.0.0.0/3 wycina klasy D i E sieci, która używana jest głównie do ruchu multicastowego ( rozgłaszania ). Dokładniejsze definicje `klasy E' możecie znaleźć w RFC 1166.

Istnieje bardzo ważna zasada w filtrowaniu pakietów, która była odraczana do momentu omówienia blokowania sieci i brzmi ona: w momencie gdy wiesz, że określony typ danych dociera z określonych miejsc, konfigurujesz system by zezwolić tylko na ruch tego typu danych z tych określonych źródeł. W przypadku klasy nieroutowalnej, wiesz że nic z 10.0.0.0/8 nie powinno docierać do ciebie przez tun0, ponieważ nie masz żadnego sposobu by na niego odpowiedzieć. Jest to pakiet nielegalny. Tak samo należy traktować inne nieroutowalne adresy, jak również 127.0.0.0/8.

Wiele oprogramowania, dokonuje uwierzytelniania na podstawie źródłowego adresu IP. Jeśli posiadasz sieć wewnętrzną, powiedzmy 20.20.20.0/24, wiesz że cały ruch dla tej sieci może wychodzić przez lokalny ethernet. Gdyby pakiet z 20.20.20.0/24 dotarł przez połączenie PPP, jest absolutnie sensownym zrzucić go na podłogę, albo umieścić w ciemnym pokoju przesłuchań. Nie powinien w żaden sposób móc osiągnąć swojego celu. Możesz to osiągnąć stosując to co już wiesz o IPF. Nowy zestaw reguł wyglądać będzie tak:

block in quick on tun0 from 192.168.0.0/16 to any
block in quick on tun0 from 172.16.0.0/12 to any
block in quick on tun0 from 10.0.0.0/8 to any
block in quick on tun0 from 127.0.0.0/8 to any
block in quick on tun0 from 0.0.0.0/8 to any
block in quick on tun0 from 169.254.0.0/16 to any
block in quick on tun0 from 192.0.2.0/24 to any
block in quick on tun0 from 204.152.64.0/23 to any
block in quick on tun0 from 224.0.0.0/3 to any
block in quick on tun0 from 20.20.20.0/24 to any
pass  in       all

Do tej pory przepuszczaliśmy lub blokowaliśmy ruch przychodzący. By wyjaśnić, ruch przychodzący to cały ruch, który dociera do ściany ogniowej na dowolnym interfejsie. Analogicznie, ruch wychodzący to cały ruch, który ma zamiar opuścić interfejs ściany ogniowej ( obojętnie czy wygenerowany lokalnie czy tylko przekazywany ). Oznacza to, że wszystkie pakiety są filtrowanie nie tylko gdy docierają do ściany ogniowej, ale również w momencie jej opuszczania. W związku z tym implikuje to komendę `pass out all', która może lub może nie być pożądana. Tak samo jak możesz przepuszczać lub blokować ruch wchodzący, możesz robić to samo z ruchem wychodzącym.

Teraz gdy wiemy że istnieje sposób by filtrować zarówno ruch wychodzący jak i wchodzący, sami musimy znaleźć sensowne zastosowanie dla czegoś takiego. Jednym z możliwych pomysłów, jest powstrzymywanie sfałszowanych ( ang. spoofed ) pakietów przed wchodzeniem do Twojej sieci. Zamiast wypuszczać na ruterze cały ruch, ograniczymy go tylko do pakietów pochodzących z 20.20.20.0/24. Możesz to zrobić w ten sposób:

pass  out quick on tun0 from 20.20.20.0/24 to any
block out quick on tun0 from any to any

Jeśli pakiet przyjdzie z 20.20.20.1/32, zostanie przepuszczony przez pierwszą regułę. Jeśli pakiet przyjdzie z 1.2.3.4/32, zostanie zablokowany przez regułę drugą.

Możesz również wykonać podobne reguły dla adresów nieroutowalnych. Jeśli jakaś maszyna próbuje skierować pakiet przez IPF do 192.168.0.0/16, dlaczego by go nie odrzucić? Najgorsze co może się stać to to, że zaoszczędzisz trochę przepustowości:

block out quick on tun0 from any to 192.168.0.0/16
block out quick on tun0 from any to 172.16.0.0/12
block out quick on tun0 from any to 10.0.0.0/8
block out quick on tun0 from any to 0.0.0.0/8
block out quick on tun0 from any to 127.0.0.0/8
block out quick on tun0 from any to 169.254.0.0/16
block out quick on tun0 from any to 192.0.2.0/24
block out quick on tun0 from any to 204.152.64.0/23
block out quick on tun0 from any to 224.0.0.0/3
block out quick on tun0 from !20.20.20.0/24 to any

Z najbardziej ograniczonego punktu widzenia, zapis ten nie rozszerza Twojego bezpieczeństwa. Rozszerza natomiast bezpieczeństwo wszystkich innych i jest generalnie miłą rzeczą do zrobienia. Z drugiej strony, ktoś może stwierdzić, że skoro nie może rozsyłać sfałszowanych pakietów przez Twoją sieć, masz mniejsze znaczenie jako punkt przekaźnikowy dla cracker'ów i w związku z tym prawdopodobieństwo, że staniesz się celem ataku maleje.

Prawdopodobnie znajdziesz wiele sposobów użycia blokowania pakietów wychodzących. Jedną z rzeczy o których zawsze należy pamiętać, to fakt, że `in' i `out' są kierunkami odnoszącymi się do ściany ogniowej, nigdy w stosunku do dowolnej innej maszyny.

Do tego momentu, całe blokowanie i przepuszczanie pakietów odbywało się w całkowitej ciszy. Zwykle chcesz jednak wiedzieć, że jesteś atakowany, a nie zastanawiać się czy ta ściana ogniowa w ogóle Ci coś daje. Podczas gdy nie logowałbym każdego pakietu który został przepuszczony i w niektórych przypadkach wszystkich blokowanych pakietów, chciałbym wiedzieć parę rzeczy o blokowanych pakietach z 20.20.20.0/24. By to wykonać, dodajemy słowo kluczowe `log':

block in     quick on tun0 from 192.168.0.0/16 to any
block in     quick on tun0 from 172.16.0.0/12 to any
block in     quick on tun0 from 10.0.0.0/8 to any
block in     quick on tun0 from 127.0.0.0/8 to any
block in     quick on tun0 from 0.0.0.0/8 to any
block in     quick on tun0 from 169.254.0.0/16 to any
block in     quick on tun0 from 192.0.2.0/24 to any
block in     quick on tun0 from 204.152.64.0/23 to any
block in     quick on tun0 from 224.0.0.0/3 to any
block in log quick on tun0 from 20.20.20.0/24 to any
pass  in       all

Do tej pory ściana ogniowa robi dobrą robotę blokując pakiety nadchodzące z podejrzanych miejsc, ale jest jeszcze trochę do zrobienia. Jedną z rzeczy o którą powinniśmy zadbać, jest by pakiety do 20.20.20.0/32 i 20.20.20.255/32 były zrzucane na podłogę. Jeśli tego nie zrobimy, otwieramy naszą sieć na atak typu smurf. Te dwie linie zabezpieczą naszą hipotetyczną sieć przed użyciem jako przekaźnik smurf:

block in log quick on tun0 from any to 20.20.20.0/32
block in log quick on tun0 from any to 20.20.20.255/32

Dodanie tych linijek, doprowadza nas do zestawu reguł wyglądającego mniej więcej tak:

block in     quick on tun0 from 192.168.0.0/16 to any
block in     quick on tun0 from 172.16.0.0/12 to any
block in     quick on tun0 from 10.0.0.0/8 to any
block in     quick on tun0 from 127.0.0.0/8 to any
block in     quick on tun0 from 0.0.0.0/8 to any
block in     quick on tun0 from 169.254.0.0/16 to any
block in     quick on tun0 from 192.0.2.0/24 to any
block in     quick on tun0 from 204.152.64.0/23 to any
block in     quick on tun0 from 224.0.0.0/3 to any
block in log quick on tun0 from 20.20.20.0/24 to any
block in log quick on tun0 from any to 20.20.20.0/32
block in log quick on tun0 from any to 20.20.20.255/32
pass  in       all

Do tej pory przedstawialiśmy jedynie fragmenty kompletnego zestawu reguł. W momencie gdy tworzysz swój zestaw, powinieneś utworzyć reguły dla każdego kierunku i interfejsu. Domyślnie ipfilter przepuszcza wszystkie pakiety . Jest to sytuacja analogiczna do tej, w której istnieje niewidoczna reguła na początku która brzmi `pass in all' i `pass out all'. Zamiast polegać na domyślnym zachowaniu, zadbaj by wszystko było tak dokładne i konkretne jak to możliwe, interfejs po interfejsie, do momentu w którym każda ewentualność zostanie rozpatrzona.

Zaczniemy od interfejsu lo0, który będzie pracował bez ograniczeń. Ponieważ istnieją programy rozmawiające z innymi na systemach lokalnych, zezwalamy na to i utrzymujemy ten stan bez żadnych restrykcji:

pass out quick on lo0
pass in  quick on lo0

Następny jest interfejs xl0. Później będziemy nakładać ograniczenia na interfejs xl0, ale na początek zaczniemy tak jakby wszystko w naszej sieci lokalnej było warte zaufania i damy interfejsowi dokładnie to samo co w przypadku lo0:

pass out quick on xl0
pass in  quick on xl0

Na koniec, jest również interfejs tun0, który do tej pory filtrowaliśmy tylko połowicznie:

block out quick on tun0 from any to 192.168.0.0/16
block out quick on tun0 from any to 172.16.0.0/12
block out quick on tun0 from any to 127.0.0.0/8
block out quick on tun0 from any to 10.0.0.0/8
block out quick on tun0 from any to 0.0.0.0/8
block out quick on tun0 from any to 169.254.0.0/16
block out quick on tun0 from any to 192.0.2.0/24
block out quick on tun0 from any to 204.152.64.0/23
block out quick on tun0 from any to 224.0.0.0/3
pass  out quick on tun0 from 20.20.20.0/24 to any
block out quick on tun0 from any to any

block in     quick on tun0 from 192.168.0.0/16 to any
block in     quick on tun0 from 172.16.0.0/12 to any
block in     quick on tun0 from 10.0.0.0/8 to any
block in     quick on tun0 from 127.0.0.0/8 to any
block in     quick on tun0 from 0.0.0.0/8 to any
block in     quick on tun0 from 169.254.0.0/16 to any
block in     quick on tun0 from 192.0.2.0/24 to any
block in     quick on tun0 from 204.152.64.0/23 to any
block in     quick on tun0 from 224.0.0.0/3 to any
block in log quick on tun0 from 20.20.20.0/24 to any
block in log quick on tun0 from any to 20.20.20.0/32
block in log quick on tun0 from any to 20.20.20.255/32
pass  in     all

Mamy już dosyć dużo filtrowania, zabezpieczamy sieć 20.20.20.0/24 przed fałszowaniem pakietów i przed używaniem do fałszowania pakietów. Kolejne przykłady będą oparte na jednostronnym podejściu, ale miej na uwadze że to tylko dla jasności, a kiedy będziesz konfigurował swój własny zestaw reguł, musisz dodawać reguły dla każdego kierunku i interfejsu.

Ataki Odmowy Usługi ( ang. Denial of Service lub DoS ) są równie częste co exploity związane z przepełnieniem bufora ( ang. buffer overflow ). Wiele ataków DoS związanych jest z zawiłościami stosu TCP/IP systemu operacyjnego. Często, sprowadzało się to do pakietów ICMP. Dlaczego nie zablokować ich w ogóle?

block in log quick on tun0 proto icmp from any to any

W tym momencie każdy pakiet ICMP nadchodzący przez tun0 będzie logowany i odrzucany.

Oczywiście, odrzucanie całego ruchu ICMP nie jest idealną sytuacją. Dlaczego nie? Ponieważ lepiej i użyteczniej jest, gdy na ruch pakietów tego protokółu zezwalamy przynajmniej po części. Zapewne zatem będziesz chciał przepuszczać pewne rodzaje ruchu ICMP a odrzucać inne. Jeśli chcesz by działały traceroute i ping, musisz przepuszczać pakiety ICMP typu 0 i 11. Dokładnie rzecz biorąc, nie jest to dobry pomysł, ale jeśli potrzebujesz wyważyć bezpieczeństwo z jednej strony i wygodę z drugiej, IPF pozwoli ci to zrobić:

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

Pamiętaj, że kolejność w zestawie reguł jest ważna. Ponieważ każda z reguł ma słowo `quick', musimy umieścić reguły przepuszczające ( pass ) przed blokującymi ( block ), więc tak naprawdę ostatnie trzy reguły powinny się znaleźć w pliku konfiguracyjnym w tej kolejności:

pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
block in log quick on tun0 proto icmp from any to any

Dodanie tych trzech reguł do tych, które zabezpieczają przed fałszowaniem pakietów może być trochę kłopotliwe. Jednym z błędów może być włączenie nowych reguł ICMP na początku:

pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
block in log quick on tun0 proto icmp from any to any
block in     quick on tun0 from 192.168.0.0/16 to any
block in     quick on tun0 from 172.16.0.0/12 to any
block in     quick on tun0 from 10.0.0.0/8 to any
block in     quick on tun0 from 127.0.0.0/8 to any
block in     quick on tun0 from 0.0.0.0/8 to any
block in     quick on tun0 from 169.254.0.0/16 to any
block in     quick on tun0 from 192.0.2.0/24 to any
block in     quick on tun0 from 204.152.64.0/23 to any
block in     quick on tun0 from 224.0.0.0/3 to any
block in log quick on tun0 from 20.20.20.0/24 to any
block in log quick on tun0 from any to 20.20.20.0/32
block in log quick on tun0 from any to 20.20.20.255/32
pass  in       all

Problem polega na tym, że pakiet ICMP typu 0 z 192.168.0.0/16 zostanie przepuszczony przez pierwszą regułę i nie zostanie zablokowany przez regułę czwartą. Również, ponieważ używamy ICMP ECHO_REPLY (typ 0) by przepuścić pakiety do 20.20.20.0/24, z dołączonym słowem `quick', otworzyliśmy się właśnie z powrotem na atak typu smurf, negując ostatnie dwie reguły blokujące. Ups. By temu zapobiec, ustawimy reguły dotyczące ICMP po regułach zabezpieczających przez fałszowaniem pakietów:

block in     quick on tun0 from 192.168.0.0/16 to any
block in     quick on tun0 from 172.16.0.0/12 to any
block in     quick on tun0 from 10.0.0.0/8 to any
block in     quick on tun0 from 127.0.0.0/8 to any
block in     quick on tun0 from 0.0.0.0/8 to any
block in     quick on tun0 from 169.254.0.0/16 to any
block in     quick on tun0 from 192.0.2.0/24 to any
block in     quick on tun0 from 204.152.64.0/23 to any
block in     quick on tun0 from 224.0.0.0/3 to any
block in log quick on tun0 from 20.20.20.0/24 to any
block in log quick on tun0 from any to 20.20.20.0/32
block in log quick on tun0 from any to 20.20.20.255/32
pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
block in log quick on tun0 proto icmp from any to any
pass  in       all

Ponieważ blokujemy ruch sfałszowany zanim zajmujemy się pakietami typu ICMP, pakiety sfałszowane nigdy nie docierają do zestawu reguł ICMP. Bardzo ważne jest pamiętanie o takich rzeczach podczas łączenia zestawów reguł.

Ponieważ zaczęliśmy już blokować pakiety na podstawie protokołu, możemy również zacząć blokować pakiety na podstawie specyficznych cech każdego z nich. Najczęściej używa się numeru portu. Usługi takie jak rsh, rlogin i telnet są bardzo przydatne, ale również bardzo niebezpieczne jeśli chodzi o podsłuchiwanie ( ang. sniffing ) i fałszowanie. Można oczywiście pójść na kompromis i zezwolić na używanie tych usług w sieci wewnętrznej a zablokować przy wychodzeniu na zewnątrz. Można to osiągnąć w prosty sposób, ponieważ rlogin, rsh i telnet używają określonych portów TCP (odpowiednio 513, 514 i 23). W związku z tym stworzenie reguł, które te usługi zablokują jest proste:

block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 513
block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 514
block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 23

Upewnij się, że wszystkie trzy znajdują się przed regułą `pass in all', dzięki czemu zamkną sieć od zewnątrz ( część reguł odpowiadająca za ochronę przed fałszowaniem pomijam dla jasności ):

pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0
pass  in     quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11
block in log quick on tun0 proto icmp from any to any
block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 513
block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 514
block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 23
pass  in     all

Możesz również chcieć zablokować porty 514/udp ( syslog ), 111/tcp i 111/udp ( portmap ), 515/tcp ( lpd ), 2049/tcp i 2049/udp ( NFS ), 6000/tcp ( X11 ) i tak dalej. Możesz uzyskać pełną listę portów na których aktualnie nasłuchujesz używając polecenia netstat -a ( lub lsof -i, jeśli masz go zainstalowanego ).

Blokowanie UDP zamiast TCP sprowadza się do zastąpienia `proto tcp' przez `proto udp'. Reguła dla syslog'a wyglądałaby następująco:

block in log quick on tun0 proto udp from any to 20.20.20.0/24 port = 514

IPF ma również skrótowy sposób zapisu w przypadku gdy chodzi o `proto tcp' jak i proto udp jednocześnie, tak jak w przypadku portmap i NFS. Reguła dla portmap'a wyglądałaby tak:

block in log quick on tun0 proto tcp/udp from any to 20.20.20.0/24 port = 111