Bridge+Firewall

Autor: Peter Breuer, ptb@it.uc3m.es
v1.1, 23 Grudnia 1996
Wersja polska: Bartosz Maruszewski B.Maruszewski@jtz.org.pl
v1.01, 26 Lipca 1997


W oryginalnym dokumencie na temat Bridge'a opisane są inne sposoby podejścia. Jest to Bridge mini-HOWTO napisane przez Chrisa Cole'a <chris@polymer.uakron.edu>. Wersja, na której bazowałem to 1.03 z 23 Sierpnia 1996. Oryginał tego dokumentu znajduje siê na ftp.icm.edu.pl w katalogu /pub/Linux/sunsite/docs/HOWTO/mini. Dokument ten jest napisany w standardzie ISO-8859-2.

1. Co, jak i dlaczego ?

1.1 Co.

Bridge jest to inteligentne połączenie pomiêdzy dwoma kartami sieciowymi. Firewall jest to inteligentny izolator.

1.2 Dlaczego.

Możesz chcieæ bridge'a jeśli masz kilka komputerów:

"Kilka komputerów" to może byæ np. trzy jeśli mają byæ rutowane, bridge'owane albo po prostu od czasu do czasu zmieniają swoje miejsce pobytu. Możesz także chcieæ mieæ bridge tylko dla zabawy, żeby siê dowiedzieæ co on robi - ja właśnie dlatego sobie go postawiłem.

Jeśli naprawdê chcesz go postawiæ z pierwszego powodu, to poczytaj lepiej NET-3-HOWTO albo Serial-HOWTO a znajdziesz tam lepsze obejścia.

Firewall jest ci potrzebny jeśli:

Ja tu potrzebowałem tego drugiego. Przepisy na naszym uniwersytecie zabraniały nam graæ rolê dostawcy Internet-u dla studentów.

1.3 Jak.

Zacząłem bridge'owaæ dwie karty sieciowe w maszynie z firewallem a skoñczyłem na firewall-owaniu wraz z bridge'owaniem bez usuwania jednej z funkcji. Wydaje siê to działaæ znacznie bardziej wydajnie niż każda z konfiguracji osobno. Mogê na przykład wyłączyæ firewall a bridge dalej działa albo odwrotnie jeśli chcê byæ bardziej bezpieczny.

Stawiałbym na to, że kod bridge'a jest tuż nad fizycznym poziomem urządzenia a kod firewalla jest o jeden poziom wyżej, tak że połaczenie bridge'a z firewallem działa tak jakby to była jednośæ a nie jakby działały równolegle.

  -> wej. bridge'a -> wej. firewalla -> jądro -> wyj. firewalla -> wyj. bridge'a

Nie ma innego sposobu na wytłumaczenie dlaczego maszyna może byæ "konduktorem" i izolatorem w tym samym czasie. W każdym razie wydaje siê to działaæ razem bardzo dobrze. Oto co ja robiê ...

2. Bridge.

2.1 Oprogramowanie.

Zdobądź konfigurator do bridge'a BRCFG.tgz.

2.2 Najpierw poczytaj.

Przeczytaj Multiple-Ethernet, żeby siê dowiedzieæ jak rozpoznaæ i skonfigurowaæ wiêcej kart sieciowych.

Wiêcej szczegółów na temat magii startowania, które możesz potrzebowaæ jest w BootPrompt-HOWTO.

Może obêdzie siê bez NET-3-HOWTO. Jest to dobry i długi dokument i bêdziesz musiał wybraæ sobie to czego potrzebujesz.

2.3 Konfiguracja startu systemu.

Po przeczytaniu powyższego dowiesz siê, że musisz skompilowaæ jądro, żeby rozpoznało drugie urządzenie ethernet-owe podczas startu oraz, że musisz dodaæ liniê do pliku /etc/lilo.conf i uruchomiæ lilo:

        append = "ether=0,0,eth1"

Zauważ, że jest tu eth1. eth0 jest pierwszą kartą a eth1 jest drugą kartą. Zawsze możesz podaæ parametry podczas startu kiedy lilo ich oczekuje. Oto przykład dla trzech kart:

        linux ether=0,0,eth1 ether=0,0,eth2

Ja używam loadlin.exe, aby uruchomiæ Linux-a:

        loadlin.exe c:\vmlinuz root=/dev/hda3 ro ether=0,0,eth1 ether=0,0,eth2

Zauważ, że to zmusza jądro do szukania podczas startu. Nie bêdzie to miało miejsca jeśli załadujesz sterowniki ethernet-owe jako moduły (ze wzglêdów bezpieczeñstwa ponieważ kolejnośæ szukania nie może byæ określona). Wiêc jeśli używasz modułów, to bêdziesz musiał dodaæ parametry określające IRQ i port w pliku /etc/conf.modules - to jest mój przykład:

             alias eth0 3c509
             alias eth1 de620
             options 3c509 irq=5 io=0x210
             options de620 irq=7 bnc=1

Możesz sprawdziæ czy używasz modułów przez ps -aux i zobaczenie czy jest proces kerneld i czy w katalogu /lib/modules/`uname -r` są pliki *.o. (w miejsce uname -r wstaw wynik tego polecenia). Jeśli masz proces kerneld albo w podanym katalogu są pliki *.o, to wyedytuj plik /etc/conf.modules i przeczytaj uważnie stronê podrêcznika systemowego na temat depmod.

Zauważ też, że do niedawna (2.0.25) sterownik 3c509 nie mógł byæ użyty jako moduł dla wiêcej niż jednej karty. Widziałem gdzieś łatê, która naprawia tê niedogodnośæ. Może on byæ w jądrze kiedy to czytasz.

2.4 Konfiguracja jądra.

Skompiluj jądro z włączoną opcją bridge.

 CONFIG_BRIDGE=y

Ja skompilowałem także z włączonymi opcjami firewalling, IP-forwarding, IP-masquerading i resztą. Ale tylko jeśli chcesz mieæ także firewall.

CONFIG_FIREWALL=y
CONFIG_NET_ALIAS=y
CONFIG_INET=y
CONFIG_IP_FORWARD=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y

Nie potrzebujesz tego wszystkiego. To czego potrzebujesz, to standardowa konfiguracja sieci:

CONFIG_NET=y

i nie sądzê, żebyś siê musiał przejmowaæ innymi opcjami związanymi z siecią. Wszystkie opcje, których właściwie nie wkompilowałem w jądro mam dostêpne jako moduły i mogê je dodaæ później.

Zainstaluj nowe jądro, uruchom lilo i zresetuj z nowym jądrem. W tym momencie nic siê nie powinno zmieniæ.

2.5 Adresy sieciowe.

Chris twierdzi, że bridge nie powinien mieæ adresu IP, ale to nie jest to ustawienie opisane tutaj.

Bêdziesz chciał używaæ tej maszyny do łączenia siê z siecią wiêc potrzebujesz adresu i musisz siê upewniæ, że masz skonfigurowane poprawnie urządzenie "loopback", tak żeby twoje oprogramowanie mogło komunikowaæ siê z miejscami, z którymi spodziewa siê, że bêdzie siê mogło porozumieæ. Jeśli nie bêdzie tego urządzenia, to serwis nazw albo inny serwis sieciowy może nie działaæ. Przeczytaj NET-3-HOWTO, ale twoja standardowa konfiguracja powinna już to za ciebie zrobiæ:

   ifconfig lo 127.0.0.1
   route add -net 127.0.0.0

Bêdziesz musiał nadaæ adres obojgu kartom. Ja dopasowałem swój /etc/rc.d/rc.inet1 w Slackware 3.x, aby ustawiæ moje dwie karty. A ty powinieneś także poszukaæ gdzie jest konfiguracja sieci u ciebie i podwoiæ instrukcje. Załóżmy, że masz już adres: 192.168.2.100 (jest to prywatny zarezerwowany adres sieciowy, ale nieważne - nikomu nie zaszkodzi jeśli użyjesz tego adresu przez pomyłkê) wtedy masz już pewnie liniê:

  ifconfig eth0 192.168.2.100 netmask 255.255.255.0 metric 1

w swojej konfiguracji. Pierwsze co pewnie bêdziesz chciał zrobiæ to podzieliæ przestrzeñ adresową na pół, tak że możesz potem te dwie połowy bridge'owaæ. Wiêc dodaj liniê. która zredukuje maskê tak, że bêdzie ona adresowaæ mniejszą ilośæ maszyn:

  ifconfig eth0 netmask 255.255.255.128

Spróbuj tego też. Powoduje to obciêcie przestrzeni adresowej do zakresu od .0 do .127.

Teraz możesz ustawiæ swoją drugą kartê w drugiej połowie adresów. Upewnij siê, że nikt jeszcze takiego adresu nie ma. Dla symetrii ja ustawiłem ją na 228 (128+100=228). Każdy adres bêdzie siê tak zachowywał dopóki nie znajdzie siê w masce tej pierwszej karty - a nawet wtedy, no może. Unikaj adresów specjalnych takich jak .0, .1, .128 o ile naprawdê wiesz co robisz.

  ifconfig eth1 192.168.2.228 netmask 255.255.255.128 metric 1

To powoduje zmniejszenie zakresu adresów drugiej karty do .128 do .255.

2.6 Ruting sieci.

Powyższe może byæ wystarczającą konfiguracją dla działającego bridge'a, ale ja bêdê miał także firewall i chcê kontrolowaæ fizyczne przeznaczenie niektórych pakietów. Nawet wtedy trzeba siê pilnowaæ przed spoofingiem.

Mam małą sieæ maszyn dołączonych do hub-a na eth0, wiêc konfigurujê tam sieæ:

  route add -net 192.168.2.128 netmask 255.255.255.128 dev eth0

128 byłoby 0 gdybym miał pełną klasê C. "dev eth0" nie jest tu potrzebne ponieważ adres karty zalicza siê do tej sieci, ale może byæ potrzebne dla ciebie.

Na drugiej karcie mam liniê idącą prosto do dużego rutera, któremu ufam.

                                            client 129
         __                                        |     __
client 1   \    .0                    .128         |   /   net 1
client 2 --- Hub - eth0 - Kernel - eth1 - Hub - Router --- net 2
client 3 __/       .100            .228         .2 |   \__ net 3
                                                   |
                                            client 254

Dołączam adres tego rutera do tej karty jako statyczny ponieważ inaczej zaliczałby siê on do maski tej pierwszej karty i jądro źle kierowałoby pakiety do tego dużego rutera.

  route add 192.168.2.2 dev eth1

Ja go nie potrzebujê ponieważ nie mam wiêcej maszyn w tej połówce przestrzeni adresowej, ale deklarujê sieæ także na tej drugiej karcie

  route add -net 192.168.2.128 netmask 255.255.255.128 dev eth1

Muszê także wysłaæ wszystkie nie lokalne pakiety w świat, wiêc informujê jądro, żeby wysyłało je do dużego rutera:

  route add default gw 192.168.2.2 

2.7 Konfiguracja karty.

To tyle odnośnie standardowego ustawiania sieci, ale my mamy bridge wiêc musimy na obydwu (?) kartach słuchaæ pakietów, które nie są przeznaczone dla nas. Nastêpujące dwie linie powinny siê znaleźæ w pliku konfigurującym sieæ:

  ifconfig promisc eth0
  ifconfig promisc eth1

Na stronie podrêcznika systemowego napisane jest, że allmulti=promisc, ale u mnie to nie działało.

2.8 Dodatkowy ruting.

Jedno co zauważyłem, to to, że musiałem przynajmniej drugą kartê ustawiæ w tryb, w którym odpowiadałaby ona dużemu ruterowi jakie maszyny chowam w swojej sieci.

  ifconfig arp eth1

Na wszelki wypadek zrobiłem to samo dla pierwszej karty.

  ifconfig arp eth0.

2.9 Konfiguracja Bridge'a.

Umieśæ włączanie bridge'owania w swoim pliku konfiguracyjnym:

    brcfg -enable

Powinieneś to próbowaæ w czasie rzeczywistym cały czas oczywiście! Konfigurator bridge'a poda parê liczb. Możesz poeksperymentowaæ włączając i wyłączając porty - jeden za każdym razem.

   brcfg -port 0 -disable/-enable
   brcfg -port 1 -disable/-enable

Polecenie brcfg pokaże ci raport w każdej chwili. Zobaczysz, że bridge słucha, dowiaduje siê i potem przekazuje pakiety. (Nie rozumiem dlaczego kod powtarza te same adresy sprzêtowe dla obu moich kart, ale nieważne ... HOWTO Chrisa mówi, że to dobrze)

2.10 Wypróbuj.

Jeśli cały czas wszystko u ciebie działa, to wypróbuj swoją konfiguracjê w rzeczywistości - wyłącz obie karty i uruchom swój plik konfiguracyjny:

    ifconfig eth0 down
    ifconfig eth1 down
    /etc/rc.d/rc.inet1

Jeśli masz szczêście, to różne podsystemy (nfs, ypbind, itp) nie zauważą tej zmiany. Nie próbuj tego o ile nie siedzisz przy klawiaturze.

Jeśli chcesz byæ bardziej ostrożny niż teraz, powinieneś wyłączyæ tyle demonów ile siê da i odmontowaæ katalogi nfs. Najgorszym co może siê staæ, to to, że bêdziesz musiał zrestartowaæ komputer w trybie jednego użytkownika (parametr "single" dla lilo lub loadlin) i zmieniæ wszystko na stan taki jaki był przed zmianą konfiguracji.

2.11 Sprawdzenia.

Sprawdź czy na każdym interfejsie jest inny ruch:

        tcpdump -i eth0    (w jednym oknie)
        tcpdump -i eth1    (w drugim oknie)

Powinieneś siê przyzwyczaiæ do używania tcpdump do szukania przyczyn niektórych zdarzeñ, które nie powinny mieæ miejsca a mają.

Na przykład szukanie pakietów, które przeszły przez bridge do drugiej karty z wewnêtrznej sieci. W tym przykładzie szukam pakietów z maszyny o adresie .22:

       tcpdump -i eth1 -e host 192.168.2.22

Potem wyślij ping-a z maszyny .22 do rutera. Powinieneś zobaczyæ raport o tym pakiecie.

W tym momencie powinieneś mieæ w pełni działający bridge z dwoma adresami. Sprawdź czy możesz je pingowaæ z zewnątrz i z wewnątrz sieci oraz, że możesz siê łączyæ z jednej sieci do drugiej i z zewnątrz.

3. Firewall.

3.1 Oprogramowanie i czytanie.

Powinieneś przeczytaæ Firewall-HOWTO.

Dowiesz siê stamtąd skąd wziąæ ipfwadm jeśli jeszcze go nie masz. Są jeszcze inne narzêdzia, które możesz ściągnąæ, ale ja nie zrobiłem nic dalej bez ipfwadm. Jest on dośæ przyjazny i niskopoziomowy ! Widzisz dokładnie co siê dzieje.

3.2 Sprawdzenie wstêpne.

Wkompilowałeś IP-forwarding i -masquerading w jądro, wiêc możesz sprawdziæ czy firewall jest w swoim domyślnym (akceptującym) stanie poleceniami:

       ipfwadm -I -l
       ipfwadm -O -l
       ipfwadm -F -l

I tak odpowiednio wyświetlane są zasady dotyczące wchodzących, wychodzących i przekazywanych (masquerading) pakietów. -l oznacza "list".

Możliwe, że wkompilowałeś także zliczanie (accounting):

       ipfwadm -A -l

Powinieneś zobaczyæ, że nie ma zdefiniowanych żadnych zasad i że domyślnym stanem jest akceptacja wszystkich pakietów. Możesz wróciæ do tego stanu w każdej chwili pisząc:

       ipfwadm -I -f
       ipfwadm -O -f
       ipfwadm -F -f

-f oznacza "flush". Możliwe, że musisz tego użyæ.

3.3 Zasady domyślne.

Chcê po prostu odciąæ resztê świata od swojej sieci wewnêtrznej i nic wiêcej, tak wiêc ostatnią (domyślną) zasadą bêdzie ignorowanie wszelkich pakietów pochodzących z wnêtrza sieci i zaadresowanych na zewnątrz. Umieściłem wszystkie te zasady (w takiej kolejności) w /etc/rc.d/rc.firewall i wykonujê ten skrypt z rc.local podczas startu.

  ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0

-S oznacza źródłowy (source) adres/maskê. -D to adres/maska przeznaczenia (destination).

Ten format dla ipfwadm-a jest trochê długi. Program ten jest inteligentny jeśli chodzi o nazwy sieciowe i niektóre popularne skróty. Zajrzyj do podrêcznika systemowego.

Przypuszczalnie bardziej wygodnie jest określaæ niektóre lub wszystkie zasady dla wychodzącej połowy firewall-a używając opcji -O zamiast -I, ale ja określê je dla czêści wchodzącej.

3.4 Dziury na adres.

Przed zasadami domyślnymi muszê umieściæ kilka zasad, które służą jako wyjątek od ogólnego zabronienia dostêpu do serwisów zewnêtrznych dla klientów wewnêtrznych.

Chcê traktowaæ adres firewall-a w sieci wewnêtrznej specjalnie. Zabroniê logowania siê na tê maszynê o ile ktoś nie ma specjalnego pozwolenia, ale jak już siê tam zalogują, to powinni mieæ możliwośæ kontaktu ze światem.

  ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \
                       -D 0.0.0.0/0.0.0.0

Chcê także, aby klienci wewnątrz sieci mogli siê komunikowaæ z firewall-em. Może mogą go zmusiæ, aby wypuścił ich na zewnątrz !

  ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \
                       -D 192.168.2.100/255.255.255.255

W tym momencie sprawdź czy możesz siê dostaæ do klientów wewnątrz sieci z zewnątrz poprzez telnet i nie możesz siê wydostaæ. Oznacza to, że możesz siê kontaktowaæ, ale klienci nie mogą ci odpowiedzieæ. Powinieneś móc siê dostaæ wszystkimi drogami jeśli używasz firewall-a jako maszyny przejściowej. Spróbuj także rlogin i ping z uruchomionym tcpdump na jednej z kart. Powinieneś umieæ odpowiednio wykorzystaæ to co robisz.

3.5 Dziury na protokół.

W nastêpnym kroku poluźniłem trochê zasady protokół po protokole. Chcê, na przykład, wpuszczaæ ping-i, żeby dostaæ odpowiedź.

  ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \
                               -D 0.0.0.0/0.0.0.0

-P icmp to magiczne zaklêcie dla konkretnego protokołu.

Dopóki trzymam ftp-proxy pozwalam także na odwołania ftp na zewnątrz przez konkretne porty. Te docelowe porty na odległej maszynie to: 20, 21, 115

  ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
                               -D 0.0.0.0/0.0.0.0 20 21 115

Bez działającego serwera nazw nie mógłbym mieæ działającego sendmail-a. Zamiast ustawiæ serwer nazw na firewall-u, pozwoliłem mu przepuszczaæ zapytania skierowane do najbliższego serwera nazw i umieściłem jego adres w plikach /etc/resolv.conf u klientów - nameserver 123.456.789.31 - w osobnej linijce.

  ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
                               -D 123.456.789.31/255.255.255.255 54

To, którego portu używa dany serwis możesz dowiedzieæ siê z programu tcpdump. Po prostu uruchom dany serwis przez ftp, albo telnet na danym kliencie i szukaj go na portach wejściowych albo wyjściowych na danym kliencie:

  tcpdump -i eth1 -e host client04

Plik /etc/services jest drugim ważnym źródłem.

Aby pozwoliæ na dostêp poprzez telnet do firewall-a z zewnątrz, musisz pozwoliæ klientom na wołanie na konkretnym porcie. Rozumiem dlaczego jest to potrzebne dla ftp - z powodu serwera, który ustawia strumieñ danych na koñcu - ale nie jestem pewien dlaczego telnet także tego potrzebuje.

  ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
                               -D 0.0.0.0/0.0.0.0

Są problemy z pewnymi demonami, które sprawdzają nazwê firewall-a, żeby zdecydowaæ jaki jest ich adres sieciowy. rpc.yppasswdd to jeden, z którym miałem problemy. Nalegał na rozsyłanie informacji, że jest on poza firewall-em (na drugiej karcie). To znaczy, że klient wewnątrz nie może siê z nim porozumieæ.

Zamiast uruchamiania IP-aliasing-u, albo zmiany kodu demona, odwzorowałem nazwê dla karty wewnêtrznej u klientów w ich plikach /etc/hosts.

3.6 Sprawdzenia.

Teraz chcesz sprawdziæ czy wciąż możesz połączyæ siê telnet-em, rlogin-em lub ping-owaæ z zewnątrz. Z wewnątrz powinieneś móc ping-owaæ na zewnątrz. Powinieneś móc także połączyæ siê telnet-em z firewall-em z wewnątrz a później móc robiæ wszystko.

To tyle. W tym momencie możesz siê pouczyæ o rpc/Yellow Pages i interakcji z plikiem haseł. Sieæ chroniona firewall-em powinna działaæ tak, aby nie pozwalaæ nieuprzywilejowanym użytkownikom na logowanie siê na firewall-u i przez to na wychodzenie na zewnątrz.. A to już historia na inne HOWTO.

4. Od tłumacza.

Tłumaczenie to jest chronione prawami autorskimi © Bartosza Maruszewskiego. Dozwolone jest rozprowadzanie i dystrybucja na prawach takich samych jak dokument oryginalny.

Jeśli znalazłeś jakieś rażące błêdy ortograficzne, gramatyczne, składniowe, techniczne to pisz do mnie:

B.Maruszewski@jtz.org.pl

Oficjalną stroną tłumaczeñ HOWTO jest http://www.jtz.org.pl/

Aktualne wersje przetłumaczonych dokumentów znajdują siê na tejże stronie. Dostêpne są także poprzez anonimowe ftp pod adresem ftp.jtz.org.pl w katalogu /HOWTO.

Przetłumaczone przeze mnie dokumenty znajdują siê także na mojej stronie WWW. Są tam też odwołania do Polskiej Strony Tłumaczeniowej.

Kontakt z naszą grupą, grupą tłumaczy możesz uzyskaæ poprzez listê dyskusyjną jtz@ippt.gov.pl. Jeśli chcesz siê na nią zapisaæ, to wyślij list o treści subscribe jtz Imiê Nazwisko na adres majordomo@ippt.gov.pl