ipfstat jest fajny jeśli chodzi o sprawdzenie aktualnego stanu systemu, ale zwykle chcemy mieć również jakiś log, by oglądać wydarzenia dziejące się w czasie. Służy do tego ipmon. Jest on zdolny do sprawdzania logów pakietów ( tworzonych przez słowo kluczowe log w regułach ), logu tabeli stanów i logu NAT, lub dowolnej kombinacji tych trzech. Narzędzie to może pracować zarówno na pierwszym planie, lub jako demon który loguje informacje do syslog lub pliku. Jeśli chcielibyśmy zobaczyć listę stanów w akcji, użyjemy polecenia `ipmon -o S':

# ipmon -o S
01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR udp
01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123 PR udp
01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123 PR udp
01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53 PR udp Pkts 4 Bytes 356
01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp
01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp Pkts 63 Bytes 4604

Widzimy zapytanie DNS z zewnętrznej maszyny do naszego serwera, dwa pingi xntp do dobrze znanych serwerów czasu i połączenie wychodzące ssh które trwało bardzo krótko.

ipmon jest również w stanie pokazać nam jakie pakiety są logowane. Na przykład, kiedy używamy stanów, często spotkasz pakiety takie jak ten:

# ipmon -o I
15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 1488 -A

Co to oznacza? Pierwsze pole to oczywiście stempel czasu. Drugie jest również raczej oczywiste, to interfejs na którym wydarzyło sie zdarzenie. Trzecie pole @0:2 to coś, co ludzie zwykle pomijają. To oznaczenie reguły która spowodowała zdarzenie. Pamiętasz `ipfstat -in'? Jeśli chciałbyś wiedzieć co spowodowało zalogowanie pakietu, powinieneś obejrzeć regułę 2 w grupie 0. Czwarte pole, małe `b' mówi że pakiet został zablokowany, i generalnie będziesz to ignorował, chyba że logujesz również pakiety które przepuszczasz, co spowoduje pokazanie się literki `p'. Piąte i szóste pole nie wymagają chyba wyjaśnienia - mówią skąd pakiet przyszedł i gdzie miał dotrzeć. Siódme ( PR ) i ósme pole to protokół, a dziewiąte długość pakietu. Ostatnia część, `-A' to flagi które były ustawione; ten pakiet ma ustawioną flagę ACK. Dlaczego wspomniałem na początku stany? Ponieważ często w Internecie zdarzają się lagi, pakiety są regenerowane i czasami dostaniesz dwa takie same, co spowoduje stwierdzenie przez kod odpowiedzialny za śledzenie połączeń, że to pakiet należący do innego połączenia. Być może trafi on na regułę. Zwykle zobaczysz tutaj zalogowany ostatni pakiet sesji, ponieważ kod `keep state' wyrzuci połączenie zanim ostatni pakiet będzie miał szansę dotrzeć do Twojej ściany ogniowej. To normalne zachowanie, nie denerwuj się. Innym przykładem pakietu może być:

12:46:12.470951 xl0 @0:1 S 20.20.20.254 -> 255.255.255.255 PR icmp len 20 9216 icmp 9/0

Jest to broadcast rozpoznawczy ICMP routera. Możemy to stwierdzić na podstawie typu ICMP: 9/0.

ipmon pozwala również na obejrzenie tabeli NAT:

# ipmon -o N
01/08/1999 05:30:02.466114 @2 NAT:RDR 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816]
01/08/1999 05:30:31.990037 @2 NAT:EXPIRE 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816] Pkts 10 Bytes 455

Widzimy tu przekierowanie do serwera identd, który oszukuje twierdząc, że udostępnia usługę ident dla maszyn za naszym NATem, ponieważ zwykle nie mogą one sobie same zapewnić tej usługi przy zwykłym NATcie.

Utrzymywanie stanu jest fajną sprawą, ale bardzo łatwo jest popełnić błąd decydując w którą stronę będziemy to robić. Generalnie, będziesz chciał ustawić słowo kluczowe `keep state' przy pierwszej regule która wchodzi w interakcję z pakietami inicjującymi dany rodzaj połączenia. Jednym z najczęściej spotykanych błędów jest, w momencie łączenia śledzenia stanów z filtrowaniem według flag, jest tak jak poniżej:

block in all
pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S
pass out all keep state

Reguły wyraźnie umożliwiają tworzenie połączeń do serwera telnetu pod adresem 20.20.20.20 i odsyłanie odpowiedzi ze strony serwera. Jednak gdy spróbujesz użyć tych reguł, zadziałają ale na krótko. Ponieważ wpuszczamy tylko pakiety z ustawioną flagą SYN, pozycja w tabeli stanów nigdy nie zostanie dokończona, i po przekroczeniu domyślnego czasu na ustanowienie połączenia ( 60 sekund ) połączenie zostanie zamknięte.

Możemy rozwiązać ten problem, przepisując reguły na jeden z dwóch sposobów:

block in all
pass in quick proto tcp from any to 20.20.20.20/32 port = 23 keep state
block out all

lub:

block in all
pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S keep state
pass out all keep state

Obie możliwości spowodują, że będzie możliwe nawiązanie pełnego połączenia oraz zapisanie go w tabeli stanów.

FTP to jeden z protokołów, przy którym siadasz i zaczynasz się zastanawiać `Co do cholery oni sobie myśleli?'. FTP ma wiele problemów z którymi administrator musi sobie poradzić. Co gorsza, problemy które administrator musi rozwiązać są różne dla klientów FTP i serwera FTP.

W obrębie protokołu FTP wyróżnia się dwa tryby transferu - aktywny i pasywny. Aktywny to ten, w którym serwer łączy się z otwartym portem na komputerze klienta i wysyła dane. Analogicznie, pasywny to taki, w którym to klient łączy się na otwarty port serwera i odbiera dane.

Jeśli chodzi o obsłużenie aktywnych sesji FTP, zadanie jest proste. Jednocześnie skonfigurowanie obsługi pasywnych sesji FTP będzie dużym problemem. Najpierw zajmiemy się aktywnym FTP, później pasywnym. Generalnie, obsłużymy aktywne FTP tak jak przychodzące połączenia HTTP czy SMTP; po prostu otworzymy port ftp i pozwolimy regule z `keep state' zrobić swoje:

pass in quick proto tcp from any to 20.20.20.20/32 port = 21 flags S keep state
pass out proto tcp all keep state

Powyższe reguły umożliwią nawiązywanie aktywnych połączeń FTP do Twojego serwera pod adresem 20.20.20.20.

Kolejnym wyzwaniem będzie obsłużenie pasywnego FTP. Standardowo tak działają przeglądarki WWW, więc staje się to dosyć popularne i powinniśmy pomyśleć o tym poważnie. Problemem jest to, że dla każdego połączenia pasywnego, serwer musi zacząć nasłuchiwać na jakimś nowym porcie ( zwykle powyżej portu numer 1023 ). Jest to coś w rodzaju tworzenia nowej usługi na serwerze. Zakładając że mamy dobrą ścianę ogniową, z domyślną zasadą blokowania, dostęp do tej nowej usługi ( otwartego portu ) zostanie zablokowany, a więc aktywne FTP nie będzie działało. Ale nie rozpaczaj. Jest nadzieja.

Pierwszym co mogłaby zrobić osoba próbująca rozwiązać ten problem, to otworzenie wszystkich portów powyżej 1023. Tak naprawdę, to zadziała:

pass in quick proto tcp from any to 20.20.20.20/32 port > 1023 flags S keep state
pass out proto tcp all keep state

Jest to jednak mało satysfakcjonujące. Przez przepuszczenie wszystkiego na porty powyżej 1023, tak naprawdę otwieramy się na wiele potencjalnych problemów. O ile porty 1-1023 zaprojektowano dla usług serwerowych, wiele programów używa portów wyższych niż 1023, na przykład nfsd czy Xy.

Dobre wiadomości są takie, że to twój serwer FTP decyduje, które porty zostaną otworzone by obsłużyć pasywne połączenie ftp. Oznacza to, że zamiast otwierać wszystkie porty powyżej 1023, możesz wybrać na przykład porty 15001-19999 na porty ftp i otwierać tylko ten zakres na swojej ścianie ogniowej. W przypadku serwera wu-ftpd, wykonuje się to przez dodanie do pliku ftpaccess opcji passive ports. Proszę, sprawdź szczegóły przez wywołanie strony podręcznikowej do pliku ftpaccess. Ze strony ipfilter, wszystko co musimy zrobić to dokonfigurować następujące reguły:

pass in quick proto tcp from any to 20.20.20.20/32 port 15000 >< 20000 flags S keep state
pass out proto tcp all keep state

Jeśli Cię to nie satysfakcjonuje, zawsze możesz dodać obsługę IPF w twoim serwerze FTP, lub odwrotnie.

O ile obsługa serwerów FTP jest jeszcze w IPF daleka od doskonałości, obsługa klientów FTP działa dobrze od wersji 3.3.3. Tak samo jak w przypadku serwerów FTP, mamy dwa rodzaje połączeń - pasywne i aktywne.

Najprostszym trybem z punktu widzenia ściany ogniowej jest tryb pasywny. Zakładając, że stosujesz reguły z `keep state' dla wychodzących połączeń tcp, połączenia pasywne będą działały bez dalszych zabiegów. Jeśli jeszcze tego nie robisz, zastanów się nad poniższym:

pass out proto tcp all keep state

Drugi typ ruchu, aktywny, jest trochę bardziej problematyczny, ale również rozwiązany. Transfery aktywne otwierają na serwerze port dla przepływu danych do klienta.

Jest to normalnie problematyczne jeśli pośrodku istnieje ściana ogniowa, powstrzymująca połączenia wychodzące przed wracaniem. By to rozwiązać, ipfilter zawiera proxy ipnat, które tymczasowo otwiera dziurę w ścianie ogniowej po to by serwer FTP mógł przekazać dane klientowi. Nawet jeśli nie używasz ipnat, proxy będzie działało. Poniższe reguły to minimum tego co musisz dodać do konfiguracji ipnat ( ep0 powinieneś zamienić na nazwę interfejsu który podłączony jest do sieci zewnętrznej):

map ep0 0/0 -> 0/32 proxy port 21 ftp/tcp

Po więcej detali dotyczących proxy ipfilter, wróć do sekcji Magia ukryta w NAT; proxy aplikacji. Dodatkowo, proxy ftp działa w `złą stronę' i może zostać użyte do obsługi serwera FTP za NATem, ale nie chcesz tego robić ze względów bezpieczeństwa. Naprawdę. To wielka dziura. Zajrzyj pod adres http://www.false.net/ipfilter/2001_11/0273.html by zobaczyć jak to naprawdę wygląda i dlaczego powinieneś o tym zapomnieć.

Istnieje trochę rzeczy w kernelu, które albo muszą być ustawione by ipf działał, albo generalnie dobrze jest wiedzieć o ich istnieniu przy budowaniu ścian ogniowych. Pierwsza podstawowa rzecz to włączenie przekazywania IP, ponieważ w innym przypadku ipf będzie mógł zrobić niewiele, ponieważ stos IP nie będzie routować pakietów.

IP Forwarding:

OpenBSD:

net.inet.ip.forwarding=1

FreeBSD:

net.inet.ip.forwarding=1

NetBSD:

net.inet.ip.forwarding=1

Solaris:

ndd -set /dev/ip ip_forwarding 1

Zmiany dotyczące ustawień portów:

OpenBSD:

net.inet.ip.portfirst = 25000

FreeBSD:

net.inet.ip.portrange.first = 25000
net.inet.ip.portrange.last = 49151

NetBSD:

net.inet.ip.anonportmin = 25000
net.inet.ip.anonportmax = 49151

Solaris:

ndd -set /dev/tcp tcp_smallest_anon_port 25000
ndd -set /dev/tcp tcp_largest_anon_port 65535

Inne użyteczne wartości:

OpenBSD:

net.inet.ip.sourceroute = 0
net.inet.ip.directed-broadcast = 0

FreeBSD:

net.inet.ip.sourceroute=0
net.ip.accept_sourceroute=0

NetBSD:

net.inet.ip.allowsrcrt=0
net.inet.ip.forwsrcrt=0
net.inet.ip.directed-broadcast=0
net.inet.ip.redirect=0

Solaris:

ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_respond_to_echo_broadcast 0

Dodatkowo, FreeBSD ma pewne dodatkowe zmienne sysctl:

net.inet.ipf.fr_flags: 0
net.inet.ipf.fr_pass: 514
net.inet.ipf.fr_active: 0
net.inet.ipf.fr_tcpidletimeout: 864000
net.inet.ipf.fr_tcpclosewait: 60
net.inet.ipf.fr_tcplastack: 20
net.inet.ipf.fr_tcptimeout: 120
net.inet.ipf.fr_tcpclosed: 1
net.inet.ipf.fr_udptimeout: 120
net.inet.ipf.fr_icmptimeout: 120
net.inet.ipf.fr_defnatage: 1200
net.inet.ipf.fr_ipfrttl: 120
net.inet.ipf.ipl_unreach: 13
net.inet.ipf.ipl_inited: 1
net.inet.ipf.fr_authsize: 32
net.inet.ipf.fr_authused: 0
net.inet.ipf.fr_defaultauthage: 600

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.

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?

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.

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.

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.

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

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.

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 :)

Oryginał tego dokumentu znajduje się pod adresem: http://www.obfuscation.org/ipf/

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