9. Zabawa z ipf!

Ta sekcja być może nie nauczy Cię niczego nowego o ipf, ale może podjąć parę problemów do których sam jeszcze nie doszedłeś, lub skierować twój mózg w stronę wynalezienia czegoś interesującego o czym nie pomyśleliśmy.

9.1 Filtrowanie localhost

Dawno dawno temu, w bardzo dalekim uniwersytecie, Wietse Venema stworzył paczkę tcp-wrapper i odtąd, była ona dodawana jako dodatkowa warstwa ochronna do usług sieciowych na całym świecie. Bardzo fajna sprawa. Ale, tcp-wrappers mają problemy. Na początek, chronią tylko usługi TCP jak sugeruje nazwa. Po drugie, chronią tylko usługi uruchamiane z poziomu inetd lub po skompilowaniu programu z biblioteką libwrap. Powoduje to gigantyczne dziury w bezpieczeństwie twojej maszyny. Możemy je zakryć, przez użycie ipf w stosunku do lokalnej maszyny. Na przykład, mój laptop jest często podłączany bezpośrednio, lub wdzaniam się do sieci którym niezbyt ufam, a w związku z tym używam poniższego zestawu reguł:

pass in quick on lo0 all
pass out quick on lo0 all

block in log all
block out all

pass in quick proto tcp from any to any port = 113 flags S keep state
pass in quick proto tcp from any to any port = 22 flags S keep state
pass in quick proto tcp from any port = 20 to any port 39999 >< 45000 flags S keep state
pass out quick proto icmp from any to any keep state
pass out quick proto tcp/udp from any to any keep state keep frags

Wyglądały one tak już od dłuższego czasu i nie dotykały mnie żadne problemy w związku z tym, że używałem załadowanego na stałe ipf. Jeśli chciałem uszczelnić je jeszcze bardziej, mogłem zacząć stosować proxy FTP przez NAT i dodać trochę reguł by zabezpieczyć się przed preparowaniem pakietów. Ale tak skonfigurowany komputer jest dużo bardziej restrykcyjny w stosunku do sieci lokalnej niż zwykły komputer. Są one dobre w sytuacji, gdy masz maszynę która ma masę użytkowników, a chcesz być pewien, że żaden z nich nie uruchomi żadnej usługi której nie powinien. Nie zatrzyma to złośliwego hackera z dostępem do konta root'a przed poprawką w twoich regułach ipf i wystartowaniem usługi, ale powstrzyma większość ludzi, zapewni bezpieczeństwo twoim usługom nawet w podejrzanej sieci lokalnej. Duże zwycięstwo, moim zdaniem. Używanie filtrowania w odniesieniu do lokalnej maszyny, w połączeniu z mniej restryktywną `główną ścianą ogniową' może rozwiązać wiele problemów wydajnościowych, jak również wiele politycznych koszmarów w stylu `Dlaczego nie działa ICQ?', albo `Dlaczego nie mogę uruchomić serwera WWW na mojej stacji roboczej? To przecież MOJA STACJA!!'. Kolejne zwycięstwo. Kto powiedział, że nie możemy zapewnić bezpieczeństwa i wygody jednocześnie?

Jaka ściana ogniowa? Filtrowanie transparentne.

Jednym z podstawowych problemów przy stawianiu ściany ogniowej, jest integralność jej samej. Czy ktoś może włamać się na twoją ścianę ogniową i zmienić reguły? Jest to częsty problem przed którym stają administratorzy, szczególnie gdy używają ścian ogniowych opartych o maszyny Unix/NT. Niektórzy używają ich w formie rozwiązań sprzętowych, tzw. blackbox, sugerując się wrażeniem, że zamknięte systemy lepiej zabezpieczają sieć. Mamy lepszy sposób.

Wielu administratorów sieci zna zagadnienie mostu ethernetowego ( ang. ethernet bridge ). Jest to urządzenie które łączy dwa oddzielne segmenty ethernetowe by stworzyć z nich jeden. Most ethernetowy używany jest zwykle do połączenia dwóch budynków, zmieniania prędkości w sieci i przedłużenia maksymalnej długości okablowania. Ostatnie wersje Linuksa, OpenBSD, NetBSD i FreeBSD które zamieniają PeCety warte tysiące złotych w mosty warte setki! To co wszystkie most mają wspólnego, to fakt że znajdują się w połowie połączenia między dwoma maszynami, które nie wiedzą o jego istnieniu. Wchodzimy w świat ipfilter i OpenBSD.

Mostowanie ethernetu ma miejsce w warstwie drugiej modelu ISO. IP na warstwie trzeciej. IP Filter jest głównie zainteresowany warstwą trzecią, ale zajmuje się również warstwą drugą ponieważ ma dostęp do interfejsów. Poprzez połączenie IP Filter i urządzenia mostującego z OpenBSD, możemy stworzyć ścianę ogniową która jest zarówno niewidzialna jak i nieosiągalna. System nie potrzebuje adresu IP, nie musi nawet ujawniać swojego adresu ethernetowego. Jedynym znakiem że gdzieś jest filtr, mogą być trochę większe opóźnienia niż te generowane przez okablowanie kategorii piątej, a część pakietów po prostu nie dociera tam gdzie powinna.

Konfiguracja takiego rodzaju zestawu reguł jest zadziwiająco prosta. W OpenBSD, pierwsze urządzenie mostujące ma nazwę bridge0. Powiedzmy że mamy dwie karty sieciowe, xl0 i xl1. By zamienić tą maszynę w most, wszystko co trzeba zrobić to wprowadzić następujące trzy komendy:

brconfig bridge0 add xl0 add xl1 up
ifconfig xl0 up
ifconfig xl1 up

W tym momencie, cały ruch przychodzący do xl0 jest wysyłany do xl1 i odwrotnie. Zauważ, że żadnemu z interfejsów nie przydzielono adresu IP, my również tego nie zrobiliśmy. Tak naprawdę, najlepiej tego nie robić.

Reguły zachowują się generalnie tak jak dotychczas. Mimo że istnieje urządzenie bridge0, nie filtrujemy pakietów w oparciu o nie. Reguły dalej oparte są o któryś z interfejsów, co sprawia że ważne jest która karta sieciowa jest podłączona do którego kabelka. Zacznijmy od podstawowego filtrowania by zilustrować to co się dzieje. Zauważmy, że twoja sieć wyglądała tak:

20.20.20.1 <---------------------------------> 20.20.20.0/24 koncentrator

To znaczy, że mamy ruter na 20.20.20.1 połączony do sieci 20.20.20.0/24. Wszystkie pakiety z sieci 20.20.20.0/24 przechodzą przez 20.20.20.1 by wyjść do świata zewnętrznego i odwrotnie. Dodajemy teraz most ipf:

20.20.20.1 <-------/xl0 IpfBridge xl1/-------> 20.20.20.0/24 koncentrator

Oraz następujący zestaw reguł na nim:

pass in quick all
pass out quick all

Z załadowanymi tymi regułami, funkcjonalność jest identyczna. Jeśli chodzi o ruter 20.20.20.1 i sieć 20.20.20.0/24 oba rysunki opisujące sieć są identyczne. Zmieńmy trochę reguły:

block in quick on xl0 proto icmp
pass in quick all
pass out quick all

Nadal 20.20.20.1 i 20.20.20.0/24 myślą, że sieć jest identyczna, ale jeśli 20.20.20.1 spróbuje wykonać ping do 20.20.20.2 nie dostanie odpowiedzi. Co więcej, 20.20.20.2 nie dostanie w ogóle pakietu. ipfilter przechwyci pakiet zanim dotrze on do drugiego końca wirtualnego drutu. Filtr z mostem możemy postawić gdziekolwiek. Używając tej metody, możemy ograniczyć koło zaufania do pojedyńczych maszyn, jeśli tylko starczy nam kart sieciowych :-).

Blokowanie icmp ze świata jest raczej śmieszne, szczególnie jeśli jesteś administratorem i lubisz pingować świat, wykonywać traceroute czy zmieniać swoje MTU. Skonstruujmy lepszy zestaw reguł by skorzystać z kluczowej zalety ipf: sprawdzania stanów.

pass in quick on xl1 proto tcp keep state
pass in quick on xl1 proto udp keep state
pass in quick on xl1 proto icmp keep state
block in quick on xl0

W tej sytuacji, sieć 20.20.20.0/24 ( może lepiej będzie ją nazywać siecią xl1 ) może teraz osiągnąć świat, ale świat nie może osiągnąć sieci i nie może nawet sprawdzić dlaczego. Router jest dostępny, maszyny są aktywne, ale świat nie może po prostu wejść. Nawet gdyby router został zaatakowany, ściana ogniowa nadal będzie aktywna i będzie działać poprawnie.

Na razie filtrowaliśmy tylko na podstawie interfejsu i protokołu. Mimo, że mostowanie wykonywane jest na warstwie drugiej, nadal możemy ograniczać dostęp na podstawie adresu IP. Zwykle mamy uruchomione parę usług, więc nasz zestaw reguł może wyglądać tak:

pass in quick on xl1 proto tcp keep state
pass in quick on xl1 proto udp keep state
pass in quick on xl1 proto icmp keep state
block in quick on xl1 # nie, wpuszczamy tylko tcp/udp/icmp proszę pana
pass in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state
pass in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state
pass in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state
pass in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state
block in quick on xl0

Mamy teraz sieć w której 20.20.20.2 jest serwerem nazw dla strefy, 20.20.20.3 obsługuje przychodzącą pocztę, a 20.20.20.7 jest serwerem WWW.

Mostowanie w wykonaniu IP Filter nie jest jednak doskonałe i musimy to przyznać.

Po pierwsze, zauważysz że wszystkie reguły używają kierunku in, zamiast kombinacji in i out. Dzieje się tak dlatego, że obecnie kierunek out nie jest zaimplementowany w OpenBSD. Oryginalnie chodziło o powstrzymanie spadków wydajności jeśli używało się wielu interfejsów. Prowadzi się prace nad przyśpieszeniem pracy, ale nadal ten kierunek pozostaje niezaimplementowany. Jeśli naprawdę potrzebujesz tej funkcjonalności, może będziesz mógł pomóc pracując przy kodzie, lub spytać ludzi z OpenBSD jak mógłbyś pomóc.

Po drugie, używanie IP Filter z mostowaniem, sprawia że używanie funkcjonalności NAT nie jest zalecane, jeśli nie bezpośrednio niebezpieczne. Pierwszym problemem jest oznajmienie o obecności filtrującego mostu. Drugim problemem byłoby to, że most nie ma adresu IP który mógłby używać do maskarady, co spowoduje prawdopodobnie bałagan jeśli nie błąd kernel panic. Możesz, oczywiście, ustawić adres IP dla interfejsu wychodzącego by NAT działał, ale znikają wtedy zalety wynikające z mostowania.
Używanie transparentnego filtrowania przy naprawie błędów w projektowaniu sieci

Wiele firm zaczęło używać IP zanim myśleli w ogóle o ścianach ogniowych czy podziale na podsieci. Mają teraz sieci wielkości klasy C czy nawet większe, które zawierają ich wszystkie serwery, stacje robocze, routery, maszyny do kawy i generalnie wszystko. Horror! Przenumerowanie, z poprawnym podziałem na podsieci, poziomy zaufania, filtry i tak dalej jest zarówno czasochłonne i kosztowne. Wydatek w postaci sprzętu i godzin roboczych ludzi już sam w sobie zwykle powstrzymuje większość firm przed rozwiązaniem tego problemu, nie mówiąc już nawet o okresie niedziałania sieci. Typowa problematyczna sieć wygląda jak poniżej:

20.20.20.1 router 20.20.20.6 unix server
20.20.20.2 unix server 20.20.20.7 nt workstation
20.20.20.3 unix server 20.20.20.8 nt server
20.20.20.4 win98 workstation 20.20.20.9 unix workstation
20.20.20.5 intelligent switch 20.20.20.10 win95 workstation

...tylko jest z 20 razy większa, zaśmiecona i w większości nieudokumentowana. W idealnej sytuacji, chciałbyś mieć wszystkie serwery w jednej podsieci, stacje robocze w drugiej a przełączniki ( ang. switch ) w trzeciej. Wtedy router filtrowałby pakiety pomiędzy podsieciami, dając stacjom roboczym ograniczony dostęp do serwerów, żadnego dostępu do przełączników, a tylko administrator miałby dostęp do maszynki do kawy. Nigdy nie widziałem sieci opartej o klasę C w takim porządku. IP Filter może pomóc.

Na początek, rozdzielimy router, stacje robocze i serwery. Potrzebujemy dwóch koncentratorów ( lub dwa przełączniki ), które i tak prawdopodobnie mamy, oraz maszynę z zainstalowanym IP Filter i trzema kartami sieciowymi. Podłączymy wszystkie serwery do jednego huba, a stacje robocze do drugiego. Normalnie połączylibyśmy następnie oba koncentratory ze sobą, a potem do rutera. Zamiast tego, podłączymy router do interfejsu IPF xl0, serwery do interfejsu xl1, a stacje robocze do interfejsu xl2. Diagram naszej sieci będzie wyglądał podobnie do tego:

| 20.20.20.2 unix server
router (20.20.20.1) ____________| 20.20.20.3 unix server
| / | 20.20.20.6 unix server
| /xl1 | 20.20.20.7 nt server
------------/xl0 IPF Bridge <
xl2 | 20.20.20.4 win98 workstation
\____________| 20.20.20.8 nt workstation
| 20.20.20.9 unix workstation
| 20.20.20.10 win95 workstation

Tam gdzie do tej pory nie było nic tylko kable połączeniowe, mamy most filtrujący który zapewnia nam, że nie trzeba modyfikować konfiguracji komputerów. Prawdopodobnie od razu włączyliśmy również mostowanie, więc sieć zachowuje się normalnie. Następnie, zaczynamy z zestawem reguł podobnym trochę do naszego ostatniego:

pass in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state
pass in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state
pass in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state
pass in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state
block in quick on xl0
pass in quick on xl1 proto tcp keep state
pass in quick on xl1 proto udp keep state
pass in quick on xl1 proto icmp keep state
block in quick on xl1 # nie, wpuszczamy tylko tcp/udp/icmp proszę pana
pass in quick on xl2 proto tcp keep state
pass in quick on xl2 proto udp keep state
pass in quick on xl2 proto icmp keep state
block in quick on xl2 # nie, wpuszczamy tylko tcp/udp/icmp proszę pana

Ponownie, ruch nadchodzący ze strony rutera ograniczony jest do DNS'u, SMTP i HTTP. Na razie, serwery i stacje robocze nie mają ograniczeń w ruchu. Zależnie od rodzaju firmy, może być coś w dynamice sieci co Ci się nie podoba. Być może w ogóle nie chcesz by stacje robocze miały dostęp do serwerów? Wyrzuć reguły dla xl2:

pass in quick on xl2 proto tcp keep state
pass in quick on xl2 proto udp keep state
pass in quick on xl2 proto icmp keep state
block in quick on xl2 # nie, wpuszczamy tylko tcp/udp/icmp proszę pana

i zamień je na:

block in quick on xl2 from any to 20.20.20.0/24
pass in quick on xl2 proto tcp keep state
pass in quick on xl2 proto udp keep state
pass in quick on xl2 proto icmp keep state
block in quick on xl2 # nie, wpuszczamy tylko tcp/udp/icmp proszę pana

Być może chcesz by dostawały się tylko do serwerów by odebrać i wysłać swoją pocztę przez IMAP? Nic łatwiejszego:

pass in quick on xl2 proto tcp from any to 20.20.20.3/32 port=25
pass in quick on xl2 proto tcp from any to 20.20.20.3/32 port=143
block in quick on xl2 from any to 20.20.20.0/24
pass in quick on xl2 proto tcp keep state
pass in quick on xl2 proto udp keep state
pass in quick on xl2 proto icmp keep state
block in quick on xl2 # nie, wpuszczamy tylko tcp/udp/icmp proszę pana

Teraz zarówno stacje robocze jak i serwery są chronione przed światem zewnętrznym, a serwery chronione są od stacji roboczych.

Być może prawdziwa jest sytuacja odwrotna, może chcesz by stacje robocze mogły mieć dostęp do serwerów, ale nie do świata zewnętrznego. W końcu, następna generacja exploit'ów działa na klientach a nie na serwerach. W tym przypadku, musisz zmienić swoje reguły dotyczące interfejsu xl2 na:

pass in quick on xl2 from any to 20.20.20.0/24
block in quick on xl2

Teraz serwery mają wolną rękę, ale klienci nie mogę połączyć się do serwerów. Możemy obniżyć trochę obostrzenia dla serwerów:

pass in quick on xl1 from any to 20.20.20.0/24
block in quick on xl1

W połączeniu z tymi dwoma, klienci i serwery mogą wymieniać dane, ale żadne z nich nie może kontaktować się ze światem zewnętrznym ( pomimo tego, że świat zewnętrzny może dostać się do paru usług ). Cały zestaw reguł wyglądać będzie tak:

pass in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state
pass in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state
pass in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state
pass in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state
block in quick on xl0
pass in quick on xl1 from any to 20.20.20.0/24
block in quick on xl1
pass in quick on xl2 from any to 20.20.20.0/24
block in quick on xl2

Pamiętaj zatem, że jeśli twoja sieć to bałagan adresów IP i maszyn różnego przeznaczenia, most z transparentnym filtrowaniem może rozwiązać twój problem, z którym musiałbyś w innym przypadku żyć i być może, któregoś dnia zostałby on wykorzystany do włamania.

Bezpieczne logowanie z komendami `dup-to' ( zrzuć do ) i `to' ( do ).

Do tej pory, używaliśmy filtrów do odrzucania pakietów. Zamiast je odrzucać, zastanówmy się nad przekazywaniem ich do innego systemu by móc zrobić z tymi informacjami coś bardziej użytecznego niż tylko logowanie za pomocą ipmon. Nasza ściana ogniowa, czy router czy most, może mieć tak dużo interfejsów jak dużo da się wsadzić do komputera. Możemy użyć tych informacji by stworzyć bezpieczne miejsce zbierania dla naszych pakietów. Dobrym przykładem byłaby implementacja sieci do wykrywania intruzów. Na początek, byłoby dobrze ukryć obecność systemów wykrywania intruzów przed światem, tak by nie mogły zostać wykryte.

Zanim zaczniemy, są pewne charakterystyki operacyjne o których musimy wiedzieć. Jeśli będziemy mieli do czynienia z pakietami, które zostały zablokowane, możemy używać zarówno słowa kluczowego to jak i fastroute ( różnice omówimy później ). Jeśli zamierzamy przepuszczać pakiety tak jak normalnie, musimy tworzyć kopię pakietów dla naszej sieci logującej przez użycie słowa kluczowego dup-to.

Metoda `dup-to'

Jeśli, na przykład, chcemy wysłać kopię wszystkiego co wychodzi przez interfejs xl3 do naszej sieci podłączonej do interfejsu ed0, możemy wstawić taką regułę:

pass out on xl3 dup-to ed0 from any to any

Możesz również mieć potrzebę wysłania tego pakietu do konkretnego adresu IP w Twojej sieci, zamiast tylko wysłać kopię i liczyć na to, że wszystko pójdzie dobrze. By to wykonać, zmodyfikujemy trochę regułę:

pass out on xl3 dup-to ed0:192.168.254.2 from any to any

Zwróć uwagę, że ta reguła spowoduje zmianę adresu przeznaczenia kopiowanego pakietu, co może zanegować użyteczność logowania. Dlatego, zalecamy tą wersję reguły jeśli jesteś pewien co do przeznaczenia logowanych pakietów ( np. nie używaj 192.168.254.2 dla logowania pakietów zarówno przeznaczonych dla serwera WWW jak i serwera poczty, ponieważ nie będziesz wiedział który pakiet miał dotrzeć do gdzie ).

Ta technika może być użyta całkiem efektywnie jeśli będziesz używał adresu IP w swojej sieci bezpieczeństwa tak jak traktowałbyś grupy rozgłaszania w prawdziwym internecie ( tzn. 192.168.254.2 może być kanałem dla analizy ruchu do HTTP, 23.23.23.23 kanałem dla sesji telnet i tak dalej ). Nie musisz mieć nawet tych adresów czy aliasów faktycznie ustawionych dla któregokolwiek adresu z sieci bezpieczeństwa. Normalnie, ipfilter musiałby używać ARP dla adresów nowego przeznaczenia ( przy użyciu czegoś w stylu ed0:192.168.254.2 ), ale możemy temu zapobiec przez stworzenie statycznych wpisów w tablicy ARP dla każdego `kanału' na naszym komputerze z ipfilter.

Generalnie, `dup-to ed0' to wszystko co jest wymagane by otrzymać nową kopię pakietu w naszej sieci bezpieczeństwa, dla celów logowania lub badań.

Metoda `to'

Metoda `dup-to' ma jedną wadę. Ponieważ ma wykonać kopię pakietu i ewentualnie zmienić jego adres docelowy, musi potrwać chwila zanim będzie gotowa zając się następnym pakietem.

Jeśli nie obchodzi nas wysyłanie pakietu do normalnego systemu a i tak mamy go zablokować, możemy używać słowa kluczowego `to' by przepchnąć ten pakiet przez proces normalnego routingu i zmusić go by wyszedł innym interfejsem niż normalnie.

block in quick on xl0 to ed0 proto tcp from any to any port < 1024

Używamy `block quick' dla routingu na interfejsie `to', ponieważ podobnie jak `fastroute', kod interfejsu `to' wygeneruje dwie ścieżki dla pakietu jeśli użyjemy `pass' a związku z tym prawdopodobnie spowoduje kernel panic.

10. Filtrowanie dziwnych sieci; najlepsze wyjście w aktualnych technologiach przeciwdziałających preparowaniu pakietów

Spędziliśmy trochę czasu śledząc szerokie zakresy adresów IP które zostały zarezerwowane przez IANA z różnych powodów, lub które nie były używane w momencie gdy pisano ten dokument. Ponieważ żadnego z tych adresów nie powinno się używać, nie powinien z niego wychodzić żaden ruch, jak również nie powinniśmy wysyłać tam niczego, prawda? Właśnie!

Więc, bez dodatkowych komentarzy, lista dziwnych sieci:

#
# s/OUTSIDE/interfejs-zewnętrzny (np: fxp0)
# s/MYNET/adres-sieci-w-formacie-CIDR (np: 1.2.3.0/24)
#
block in on OUTSIDE all
block in quick on OUTSIDE from 0.0.0.0/7 to any
block in quick on OUTSIDE from 2.0.0.0/8 to any
block in quick on OUTSIDE from 5.0.0.0/8 to any
block in quick on OUTSIDE from 10.0.0.0/8 to any
block in quick on OUTSIDE from 23.0.0.0/8 to any
block in quick on OUTSIDE from 27.0.0.0/8 to any
block in quick on OUTSIDE from 31.0.0.0/8 to any
block in quick on OUTSIDE from 69.0.0.0/8 to any
block in quick on OUTSIDE from 70.0.0.0/7 to any
block in quick on OUTSIDE from 72.0.0.0/5 to any
block in quick on OUTSIDE from 82.0.0.0/7 to any
block in quick on OUTSIDE from 84.0.0.0/6 to any
block in quick on OUTSIDE from 88.0.0.0/5 to any
block in quick on OUTSIDE from 96.0.0.0/3 to any
block in quick on OUTSIDE from 127.0.0.0/8 to any
block in quick on OUTSIDE from 128.0.0.0/16 to any
block in quick on OUTSIDE from 128.66.0.0/16 to any
block in quick on OUTSIDE from 169.254.0.0/16 to any
block in quick on OUTSIDE from 172.16.0.0/12 to any
block in quick on OUTSIDE from 191.255.0.0/16 to any
block in quick on OUTSIDE from 192.0.0.0/19 to any
block in quick on OUTSIDE from 192.0.48.0/20 to any
block in quick on OUTSIDE from 192.0.64.0/18 to any
block in quick on OUTSIDE from 192.0.128.0/17 to any
block in quick on OUTSIDE from 192.168.0.0/16 to any
block in quick on OUTSIDE from 197.0.0.0/8 to any
block in quick on OUTSIDE from 201.0.0.0/8 to any
block in quick on OUTSIDE from 204.152.64.0/23 to any
block in quick on OUTSIDE from 224.0.0.0/3 to any
block in quick on OUTSIDE from MYNET to any
# tutaj Twoje reguły przepuszczające...

block out on OUTSIDE all
block out quick on OUTSIDE from !MYNET to any
block out quick on OUTSIDE from MYNET to 0.0.0.0/7
block out quick on OUTSIDE from MYNET to 2.0.0.0/8
block out quick on OUTSIDE from MYNET to 5.0.0.0/8
block out quick on OUTSIDE from MYNET to 10.0.0.0/8
block out quick on OUTSIDE from MYNET to 23.0.0.0/8
block out quick on OUTSIDE from MYNET to 27.0.0.0/8
block out quick on OUTSIDE from MYNET to 31.0.0.0/8
block out quick on OUTSIDE from MYNET to 69.0.0.0/8
block out quick on OUTSIDE from MYNET to 70.0.0.0/7
block out quick on OUTSIDE from MYNET to 72.0.0.0/5
block out quick on OUTSIDE from MYNET to 82.0.0.0/7
block out quick on OUTSIDE from MYNET to 84.0.0.0/6
block out quick on OUTSIDE from MYNET to 88.0.0.0/5
block out quick on OUTSIDE from MYNET to 96.0.0.0/3
block out quick on OUTSIDE from MYNET to 127.0.0.0/8
block out quick on OUTSIDE from MYNET to 128.0.0.0/16
block out quick on OUTSIDE from MYNET to 128.66.0.0/16
block out quick on OUTSIDE from MYNET to 169.254.0.0/16
block out quick on OUTSIDE from MYNET to 172.16.0.0/12
block out quick on OUTSIDE from MYNET to 191.255.0.0/16
block out quick on OUTSIDE from MYNET to 192.0.0.0/19
block out quick on OUTSIDE from MYNET to 192.0.48.0/20
block out quick on OUTSIDE from MYNET to 192.0.64.0/18
block out quick on OUTSIDE from MYNET to 192.0.128.0/17
block out quick on OUTSIDE from MYNET to 192.168.0.0/16
block out quick on OUTSIDE from MYNET to 197.0.0.0/8
block out quick on OUTSIDE from MYNET to 201.0.0.0/8
block out quick on OUTSIDE from MYNET to 204.152.64.0/23
block out quick on OUTSIDE from MYNET to 224.0.0.0/3
# tutaj Twoje reguły przepuszczające...

Jeśli zamierzasz tego użyć, sugerujemy zapoznanie się z whois.arin.net i okresowe sprawdzanie tych adresów, ponieważ IANA nie powiadomi Cię jeśli przyzna któryś z nich dla nowych firm czy czegokolwiek innego. Zostałeś ostrzeżony.

11. Uwagi od tłumacza

Chciałbym podziękować następującym osobom za uwagi co do tłumaczenia, poprawki i zasugerowanie poprawek:

dereck (at) box43.pl
* literówki i dziwna zapaść w połowie zdania :)

Ściany ogniowe oparte o IP Filter
Brendan Conoboy, synk(at)swcp.com 
Erik Fichtner, emf(at)obfuscation.org 
Wersja oryginalna: Fri Mar 1 22:29:33 EST 2002
Oryginał tego dokumentu znajduje się pod adresem: http://www.obfuscation.org/ipf/ 

Tłumaczenie: Łukasz Bromirski 
lbromirski(at)mr0vka.eu.org 
Wersja tłumaczenia: 3.0, 2002/09/03 14:38:15
Oryginał tłumaczenia znajduje się pod adresem: http://mr0vka.eu.org/docs/tlumaczenia/ipf/index.html 

Tylko zarejestrowani użytkownicy mogą pisać komentarze.
Prosze zaloguj się i dodaj komentarz.

Powered by AkoComment!