ip_filter.pdf

Ściany ogniowe oparte o IP Filter

Brendan Conoboy, synk@swcp.com

Erik Fichtner, emf@obfuscation.org

Wersja oryginalna: Sat Jul 21 02:37:55 EDT 2001

Oryginał tego dokumentu znajduje się pod adresem: http://coombs.anu.edu.au/~avalon/ip-filter.html

Tłumaczenie: Łukasz Bromirski, l.bromirski@mr0vka.eu.org

Wersja tłumaczenia: 2.0, $Date: 2002/03/19 22:33:42 $

Oryginał tłumaczenia znajduje się pod adresem: http://mr0vka.eu.org/tlumaczenia/ipf.html

Dokument ten jest pomyślany jako wprowadzenie dla nowych użytkowników paczki IP Filter tworzącej ścianę

ogniową. Jednocześnie, ma nauczyć użytkownika niektórych fundamentalnych zasad projektowania dobrych ścian

ogniowych.

1. Wprowadzenie

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 .

1.1 Oświadczenie

Autorzy tego dokumentu (ani tłumacz!) 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ą.

1.2 Prawa autorskie

Tam gdzie nie napisano inaczej, prawa autorskie dokumentów HOWTO należą do ich autorów. Dokumeny 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 pochwalana; jednakże autorzy chcieliby 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.

W skrócie, chcemy promować informacje przekazywane w tym dokumencie przez tyle dróg ile się da. Jednakże,

życzymy sobie zachować prawa autorskie do tego HOWTO, i chcielibyśmy być informowani o jakichkolwiek

planach redystrybuowania tego HOWTO.

1.3 Skąd uzyskać ważne rzeczy

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/

2. Podstawy ścian ogniowych

Tą sekcję zaprojektowano 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.

2.1 Dynamika pliku konfiguracyjnego i kolejność

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

2.2 Podstawy przetwarzania reguł

Reguły przetwarzane są z góry na dół, każda dodawana po poprzedniej. To po prostu oznacza, że jeśli całym twoim

plikiem konfiguracyjnym jest:

block in all

pass in all

Komputer widzi je 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; IPF nie jest jednym z nich.

Inaczej 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 roboty. Pobiera pakiet i sprawdza pierwszą regułę:

block in all

IPF na razie 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

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.

2.3 Kontrolowanie przetwarzania reguł

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 sprawdzane są już ż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ć.

2.4 Podstawy filtrowania po adresie IP

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ć nierutowalna, 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 robi coś dla nas. 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 pakiet 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 adresów prywatnych.

2.5 Kontrola interfejsów

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

Ruter od każdej innej dowolnej maszyny różni jedna podstawowa rzecz: 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 FreeBDS 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.

2.6 Użycie adresu IP i nazwy interfejsu jednocześnie

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 rutingu. 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ń klusterów, i

zablokowanie go pozostawiamy tobie pod rozwagę. Na koniec, 224.0.0.0/3 wycina 'Klasę D i E' sieci która używana

jest głównie do ruchu multicastowego (rozgłaszania), choć 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 nierutowalnej, wiesz że nic z

10.0.0.0/8 nie powinno docierać do ciebie na tun0 , ponieważ nie masz żadnego sposobu by na niego odpowiedzieć.

Jest to pakiet nielegalny. Tak samo należy traktować inne nierutowalne adresy, jak również 127.0.0.0/8>.

Wiele oprogramowania, wykonuje autoryzację na podstawie adresu źródłowego 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ć 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

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: