Ściany ogniowe oparte o IP filter, Opracowania informatyczne
[ Pobierz całość w formacie 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:
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:
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
.
Kompatybilny filtr pakietów na licencji BSD znajduje się pod adresem
.
Najaktualniejszą wersję tego dokumentu można znaleźć pod adresem:
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
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.
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
[ Pobierz całość w formacie PDF ]