                            Mosty filtrujace

  Alex Dupre

   <sysadmin@alexdupre.com>

   $FreeBSD:
   doc/pl_PL.ISO8859-2/articles/filtering-bridges/article.sgml,v 1.1
   2002/09/26 17:51:23 blackend Exp $

   Czestokroc zdarza sie, ze trzeba podzielic jedna siec fizyczna
   (np. Ethernet) na dwa oddzielne segmenty, nie tworzac przy tym
   podsieci, a oba segmenty polaczyc ze soba ruterem. Urzadzenie
   laczace w ten sposob dwie sieci nazywane jest mostem. Komputer z
   FreeBSD posiadajacy dwa interfejsy sieciowe moze z powodzeniem
   pracowac jako most.

   Zadaniem mostu jest analizowanie adresow MAC (adresow
   ethernetowych) nalezacych do urzadzen przylaczonych do obu
   interefejsow sieciowych, a nastepnie przekazywaniu danych pomiedzy
   obiema sieciami tylko wtedy, gdy nadawca i odbiorca naleza do
   innych segmentow. Pod wieloma wzgledami most przypomina
   przelacznik ethernetowy wyposazony w jedynie dwa porty.

     --------------------------------------------------------------

1. Dlaczego korzysta sie z mostow filtrujacych?

   Dzieki obnizajacym sie kosztom szerokopasmowych polaczen
   internetowych (xDSL), jak rowniez z powodu niewielkiej liczby
   dostepnych adresow IPv4, coraz czesciej zdarza sie, ze firmy
   dysponuja stalym polaczeniem z Internetem, nie posiadajac przy tym
   zbyt wielu adresow IP. W takiej sytuacji przydatne jest stosowanie
   firewalla filtrujacego pakiety wysylane do Internetu i z niego
   nadchodzace. Moze sie jednak zdarzyc, ze filtrowania pakietow na
   poziomie rutera nie da sie zrealizowac, na przyklad ze wzgledu na
   podzial sieci, lub dlatego, ze to dostawca uslug interentowych
   jest wlascicielem rutera, badz tez sam ruter nie umozliwia takiego
   rozwiazania. Wtedy wlasnie wskazane jest skorzystanie z mostu
   filtrujacego.

   Firewall bedacy jednoczesnie mostem moze byc wstawiony pomiedzy
   ruter xDSL a koncentrator/przelacznik ethernetowy. Jego
   konfiguracja nie wymaga zajmowania sie numeracja IP.

     --------------------------------------------------------------

2. Instalacja

   W FreeBSD wlaczenie funkcji mostu nie jest trudnym
   przedsiewzieciem. Poczawszy od wydania 4.5 owe funkcje moga byc
   dolaczone jako moduly, nie trzeba wiec przebudowywac jadra, co
   jest znacznym udogodnieniem. Ponizej opisuje obydwa sposoby.

     WAZNE: Nie nalezy postepowac wedlug obu ponizszych przepisow:
     skorzystanie z jednego z nich wyklucza korzystanie z drugiego.
     Wybor powinien zalezec od wlasnych potrzeb i mozliwosci.

   Przed rozpoczeciem nalezy upewnic sie, ze dysponujemy przynajmniej
   dwiema kartami sieciowymi zdolnymi do pracy w trybie
   posredniczenia zarowno przy odbiorze, jak i nadawaniu; karty beda
   wysylac pakiety opatrzone niekoniecznie ich wlasnymi adresami. Co
   wiecej, by osiagnac dobra wydajnosc, powinny byc to karty PCI
   obslugujace zarzadzanie magistrala. Do takich naleza karty Intel
   EtherExpress Pro, a takze karty 3Com z serii 3c9xx. Dla
   uproszczenia konfiguracji firewalla pozytecznym okazac sie moze
   posiadanie kart dwoch roznych producentow (korzystajacych z innych
   sterownikow), by latwiej bylo odroznic interfejs podlaczony do
   rutera od interfejsu polaczonego z siecia wewnetrzna.

     --------------------------------------------------------------

  2.1. Konfigurowanie jadra

   Pierwsza z metod jest starsza, lecz sprawdzona. Na poczatek nalezy
   dodac nastepujace wiersze do pliku konfiguracyjnego jadra:

 options BRIDGE
 options IPFIREWALL
 options IPFIREWALL_VERBOSE

   Pierwszy wiersz wlacza do jadra obsluge mostu, drugi obsluge
   firewalla, a trzeci funkcje rejestrujace firewalla.

   Teraz trzeba skompilowac i zainstalowac nowe jadro. Szczegolowy
   opis tych czynnosci znalezc mozna w Podreczniku FreeBSD, w czesci
   "Building and Installing a Custom Kernel".

     --------------------------------------------------------------

  2.2. Ladowanie modulow

   Ta metoda instalacji jest nowsza i prostsza, polega jedynie na
   dodaniu ponizszego wiersza do /boot/loader.conf:

 bridge_load="YES"

   W efekcie podczas ladowania systemu wraz z jadrem zostanie
   zaladowany modul bridge.ko. Nie trzeba dodawac analogicznego
   wiersza dla modulu ipfw.ko, gdyz zostanie on zaladowany
   automatycznie po wykonaniu czynnosci opisanych w nastepnej czesci.

     --------------------------------------------------------------

3. Przygotowanie do pracy

   Przed ponownym uruchomieniem systemu oraz zaladowaniem nowego
   jadra lub modulow (w zaleznosci od wybranej metody instalacji),
   trzeba jeszcze dokonac kilku zmian w pliku konfiguracyjnym
   /etc/rc.conf. Domyslna regula firewalla jest zatrzymywanie
   wszystkich pakietow IP. Zaczniemy od skonfigurowania firewalla
   otwartego, by sprawdzic jego dzialanie przy wylaczonym filtrowaniu
   (dzieki temu maszyna bedzie mogla utrzymac polaczenie z siecia, co
   jest niezbedne w przypadku, gdy konfiguracja przeprowadzana jest
   poprzez siec). W pliku /etc/rc.conf nalezy umiescic ponizsze
   wpisy:

 firewall_enable="YES"
 firewall_type="open"
 firewall_quiet="YES"
 firewall_logging="YES"

   Pierwszy wiersz powoduje uruchomienie firewalla (ladowany jest
   modul ipfw.ko, jesli nie zostal wkompilowany do jadra), w drugim
   ustawiany jest otwarty tryb jego pracy (zgodnie z opisem w
   /etc/rc.firewall). Nastepny wiersz nakazuje nie pokazywac
   ladowanych regul, a w ostatnim wlaczane jest rejestrowanie.

   Interfejsy sieciowe sa najczesciej skonfigurowane tak, ze tylko
   jedna z kart sieciowych ma przypisany adres IP, jednakze most
   dziala tak samo rowniez wtedy, gdy adresy przypisane sa do obu
   kart lub nie sa przypisane do zadnej z nich. W tym ostatnim
   przypadku (brak IP) maszyna pelniaca role mostu bedzie jeszcze
   bardziej ukryta, gdyz nie bedzie dostepna z sieci; dostep do niej
   mozliwy bedzie poprzez konsole lub trzeci interfejs sieciowy
   odseparowany od mostu. Niekiedy dostep do sieci potrzebny jest
   programom uruchamianym podczas ladowania systemu, na przyklad do
   okreslenia nazwy domeny. W takiej sytuacji adres IP nalezy
   przydzielic interfejsowi zewnetrznemu (czyli temu, ktory polaczony
   jest z Internetem, gdzie znajduje sie serwer DNS), poniewaz most
   bedzie uruchomiony dopiero w koncowej fazie uruchamiania systemu.
   Oznacza to, ze interfejs fxp0 (jak w przykladzie) musi byc
   uwzgledniony w sekcji ifconfig pliku /etc/rc.conf, w
   przeciwienstwie do interfejsu xl0. Przydzielanie adresow IP obu
   kartom sieciowym nie ma raczej sensu, chyba, ze podczas
   uruchamiania systemu programy potrzebuja dostepu do obu segmentow
   sieci.

   Nalezy miec na uwadze, ze w sieci IP opartej na Ethernecie
   dzialaja w rzeczywistosci dwa protokoly: jednym jest oczywiscie
   IP, drugim jest ARP. Zadaniem protokolu ARP jest przeksztalcenie
   adresu IP stacji na jej adres ethernetowy (adres MAC). By mozliwa
   byla komunikacja miedzy dwoma stacjami znajdujacymi sie po dwoch
   stronach mostu, pakiety ARP musza byc przekazywane przez most.
   Protokol ARP nie jest skladnikiem warstwy IP, poniewaz jest
   uzywany tylko wtedy, gdy IP dziala w sieci Ethernet. Filtrowanie
   pakietow przez firewall w FreeBSD dotyczy warstwy IP, wiec pakiety
   innego typu (w tym takze ARP) beda przekazywane dalej bez
   filtrowania, nawet jesli konfiguracja firewalla nakazuje
   blokowanie wszystkiego.

   Mozna juz uruchomic system ponownie i korzystac z niego jak
   dotychczas. Pojawia sie nowe komunikaty dotyczace mostu i
   firewalla, most jednak nie bedzie jeszcze pracowac, natomiast
   firewall bedzie dzialac w trybie otwartym, bez jakiegokolwiek
   blokowania.

   Jesli pojawia sie jakiekolwiek problemy, nalezy sie z nimi uporac
   przed przystapieniem do kolejnego etapu pracy.

     --------------------------------------------------------------

4. Uruchamianie mostu

   Uruchomienie mostu polega na wykonaniu nastepujacej sekwencji
   polecen (nazwy przykladowych interfejsow sieciowych fxp0 i xl0
   nalezy zastapic nazwami wlasnych interfejsow):

 # sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0
 # sysctl net.link.ether.bridge_ipfw=1
 # sysctl net.link.ether.bridge=1

   Pierwsze polecenie wskazuje interfejsy obslugiwane przez most,
   drugie wlacza firewalla, wreszcie trzecie polecenie wlacza sam
   most.

   Tak skonfigurowana maszyna moze zostac wlaczona miedzy dwie grupy
   polaczonych w siec komputerow bez zaklocania ich wzajemnej
   komunikacji. Jesli to sie powiedzie, mozna dodac do pliku
   /etc/sysctl.conf wpisy net.link.ether.[cos]=[cos] zgodne z
   powyzszymi, by zostaly uwzglednione przy ladowaniu systemu.

     --------------------------------------------------------------

5. Konfiguracja firewalla

   Nastepnym krokiem jest przygotowanie regul firewalla,
   zabezpieczajacych siec wewnetrzna. Wiaze sie to z pewnymi
   utrudnieniami, gdyz nie wszystkie mozliwosci firewalla moga byc
   wykorzystywane w przypadku pakietow przechodzacych przez most.
   Trzeba tez wiedziec, ze miedzy pakietami przekazywanymi, a
   odbieranymi przez maszyne lokalna jest pewna roznica. Pakiety
   przychodzace przechodza przez firewall tylko raz, a nie dwa razy
   jak w zwyklych warunkach. Mowiac dokladniej, sa one filtrowane
   tylko przy odbiorze, tak wiec reguly zawierajace out lub xmit beda
   bezuzyteczne. Ja osobiscie uzywam starszej skladni in via, ktora
   rozsadniej sie czyta. Trzeba rowniez pamietac, ze filtrujac
   pakiety przechodzace przez most, mozna uzywac tylko polecen pass
   lub drop. Bardziej wymyslne polecenia, jak divert, forward czy
   reject sa niedozwolone. Mozna z nich korzystac tylko w odniesieniu
   do pakietow wysylanych przez maszyne mostu lub do niej
   przychodzacych (jesli oczywiscie ma ona adres IP).

   Nowoscia w FreeBSD 4.0 jest filtrowanie z utrzymywaniem stanu.
   Jest ono znacznym ulatwieniem obslugi komunikacji przez UDP,
   polegajacej najczesciej na wyslaniu zadania, a za chwile odebraniu
   odpowiedzi, z takimi samymi adresami IP i numerami portow (przy
   czym nadawca i odbiorca sa oczywiscie zamienieni miejscami).
   Praktycznie nie da sie potraktowac takiej wymiany jako pojedynczej
   sesji, poslugujac sie firewallem nie przechowujacym informacji o
   stanie polaczenia. Jednakze gdy firewall potrafi "zapamietac"
   wychodzacy pakiet UDP i zezwolic na odpowiedz w ciagu kilku
   nastepnych minut, wowczas zarzadzanie komunikacja UDP staje sie
   dziecinnie proste. Jak to zrobic, pokazuje ponizszy przyklad.
   Podobnie mozna traktowac pakiety TCP, chroni to przed niektorymi
   atakami przez uniemozliwienie dzialania oraz innymi figlami,
   prowadzi jednak do szybkiego rozrastania sie tablicy stanow.

   Spojrzmy na przykladowa konfiguracje. Zwrocmy uwage, ze na
   poczatku pliku /etc/rc.firewall umieszczono domyslne reguly dla
   interfejsu pseudosieci lo0, nie trzeba sie wiec juz nimi
   przejmowac. Inne reguly powinny byc umieszczone w oddzielnym pliku
   (np. /etc/rc.firewall.local), ktory bylby dolaczany podczas
   ladowania systemu dzieki zmianie w pliku /etc/rc.conf tego
   wiersza, w ktorym typ firewalla byl zdefiniowany jako otwarty:

 firewall_type="/etc/rc.firewall.local"

     WAZNE: Nalezy tu podac pelna sciezke, w przeciwnym razie plik
     nie zostanie zaladowany, co grozi utrata dostepu do sieci.

   Na potrzeby przykladu przyjmujemy, ze interfejs fxp0 polaczony
   jest z Internetem, natomiast xl0 z siecia wewnetrzna (LAN). Adres
   IP maszyny mostu to 1.2.3.4 (w rzeczywistosci dostawca uslug
   interenetowych nie moglby przydzielic adresu klasy A, jednak
   swietnie nadaje sie on jako przyklad).

 # Szybkie przepuszczanie pakietow, ktorych stan zostal zapamietany
 add check-state

 # Blokada sieci z RFC 1918
 add drop all from 10.0.0.0/8 to any in via fxp0
 add drop all from 172.16.0.0/12 to any in via fxp0
 add drop all from 192.168.0.0/16 to any in via fxp0

 # Maszyna bedaca mostem moze wysylac co tylko zechce
 # (jesli maszyna nie ma adresu IP, pomin ponizsze wiersze)
 add pass tcp from 1.2.3.4 to any setup keep-state
 add pass udp from 1.2.3.4 to any keep-state
 add pass ip from 1.2.3.4 to any

 # Stacje sieci wewnetrznej moga wysylac co tylko zechca
 add pass tcp from any to any in via xl0 setup keep-state
 add pass udp from any to any in via xl0 keep-state
 add pass ip from any to any in via xl0

 # Protokol TCP
 # Przepuszczanie SSH
 add pass tcp from any to any 22 in via fxp0 setup keep-state
 # Przepuszczanie SMTP jedynie do serwera poczty
 add pass tcp from any to relay 25 in via fxp0 setup keep-state
 # Informacje o obszarach moga byc przesylane tylko przez podrzedny
 # serwer nazw [dns2.nic.it]
 add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
 # Przepuszczanie zapytan ident - takie rozwiazanie jest lepsze
 # niz oczekiwanie na przekroczenie czasu
 add pass tcp from any to any 113 in via fxp0 setup keep-state
 # Przepuszczenie zakresu portow dynamicznych
 add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

 # Protokol UDP
 # Przepuszczanie zapytan DNS jedynie do serwera DNS
 add pass udp from any to ns 53 in via fxp0 keep-state
 # Przepuszczenie zakresu portow dynamicznych
 add pass udp from any to any 49152-65535 in via fxp0 keep-state

 # Protokol ICMP
 # Przepuszczanie 'pingow'
 add pass icmp from any to any icmptypes 8 keep-state
 # Przepuszczanie komunikatow o bledach generowanych przez 'traceroute'
 add pass icmp from any to any icmptypes 3
 add pass icmp from any to any icmptypes 11

 # Wszystko inne jest podejrzane
 add drop log all from any to any

   Czytelnicy majacy juz doswiadczenie z konfiguracja firewalla moga
   zwrocic uwage na brak pewnych rzeczy. W szczegolnosci, brakuje
   regul zapobiegajacych podszywaniu sie. Rzeczywiscie, wsrod
   powyzszych regul nie bylo takiej:

 add deny all from 1.2.3.4/8 to any in via fxp0

   Nakazuje ona odrzucanie pakietow, ktore nadchodza z zewnatrz, a
   udaja, ze sa z sieci wewnetrznej. Jest to zwykle stosowane w celu
   zabezpieczenia sie przed probami przeslizniecia sie przez
   filtrowanie, polegajacymi na tworzeniu falszywych pakietow,
   wygladajacych jak wyslane z sieci wewnetrznej. Klopot w tym, ze
   jest co najmniej jedna stacja polaczona z interfejsem zewnetrznym,
   ktorej nie mozna zignorowac: jest nia ruter. Zwykle jednak ochrona
   przed podszywaniem sie realizowana jest przez dostawce uslug
   internetowych na jego ruterze, nie trzeba sie wiec tym przejmowac.

   Ostatnia regula jest bardzo podobna do reguly przyjmowanej
   domyslnie, czyli odrzucania wszystkiego, co nie jest scisle
   dozwolone. Jest jednak roznica: wszystko, co jest podejrzane, jest
   rejestrowane.

   Dwie reguly odpowiedzialne sa za przekazywanie pakietow SMTP i DNS
   do serwera poczty i serwera nazw, o ile takowe serwery sa. Zestaw
   regul powinien byc oczywiscie dostosowany do wlasnych potrzeb,
   tutaj pokazany jest tylko pewien przyklad (skladnia regul jest
   dokladnie opisana w dokumentacji systemowej ipfw(8)). Trzeba miec
   na uwadze, ze aby poprawnie dzialaly "relay" i "ns", wymagane
   jest, by zapytania DNS dzialaly zanim prace rozpoczyna most.
   Dzieki temu mozna tez sie przekonac, czy adres IP zostal
   przypisany do wlasciwiej karty sieciowej. Alternatywnym
   rozwiazaniem jest wpisanie adresu IP zamiast nazwy stacji (jest to
   jedyna mozliwosc w przypadku, gdy maszyna nie ma adresu IP).

   Osoby, ktore juz kiedys mialy pewne doswiadczenia z konfiguracja
   firewalla, przyzwyczajone sa zapewne do regul reset lub forward
   dla pakietow ident (port TCP o numerze 113). Niestety, w przypadku
   mostu takie rozwiazanie nie wchodzi w gre, najlepiej jest po
   prostu przepuscic owe pakiety do ich adresata. Jest to stosunkowo
   niegrozne, gdy adresat ma wylaczona usluge ident. Mozna takze
   blokowac polaczenia z portem 113, co powoduje pewne problemy np. z
   usluga IRC (poniewaz zapytanie ident musi przekroczyc czas
   oczekiwania).

   Niezrozumiala moze wydac sie obecnosc oddzielnych regul, z ktorych
   jedne zezwalaja na wysylanie maszynie bedacej mostem, drugie
   natomiast stacjom sieci wewnetrznej. Jest tak dlatego, ze pakiety
   wysylane przez maszyne lokalna docieraja do filtra inna droga niz
   pakiety wyslane z sieci wewnetrznej. Te ostatnie musza przejsc
   przez most, natomiast pakiety wyslane lokalnie trafiaja na stos IP
   maszyny. Osobne zestawy regul obsluguja obydwa przypadki. Z kolei
   reguly zawierajace in via fxp0 odnosza sie do obu rodzajow
   pakietow. Mowiac ogolnie, piszac reguly in via trzeba zrobic
   wyjatek dla pakietow wysylanych z lokalnej maszyny, poniewaz one
   nie przyszly przez zaden z interfejsow.

     --------------------------------------------------------------

6. Podziekowania

   Duza czesc niniejszego artykulu zaczerpnieta zostala ze starego
   dokumentu o mostach autorstwa Nicka Sayera. Inspiracja bylo
   rowniez wprowadzenie do tematyki mostow napisane przez Steve'a
   Petersona.

   Bardzo dziekuje Luigiemu Rizzo za implementacje kodu mostu w
   FreeBSD, jak rowniez za czas poswiecony na odpowiedzi na moje
   pytania.

   Dziekuje tez Tomowi Rhodesowi, ktory zechcial przyjrzec sie mojemu
   tlumaczeniu tego artykulu z wloskiego (w takim jezyku napisany byl
   oryginal) na angielski.

     --------------------------------------------------------------

                  Ten i inne dokumenty mozna pobrac z
                ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

  W przypadku pytan o FreeBSD prosimy przeczytac dostepna dokumentacje
               przed kontaktem z <questions@FreeBSD.org>.
        W sprawie zapytan o te dokumentacje prosimy o kontakt z
                           <doc@FreeBSD.org>.
