                                Mosty filtrujace

  Alex Dupre

   <sysadmin@alexdupre.com>

   Zmiana: 43184
   2013-11-13 autorstwa hrs.
   Abstrakt

   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.

   [ HTML z podzialem na podstrony / Pojedyncza strona HTML ]

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

   Spis tresci

   1. Dlaczego korzysta sie z mostow filtrujacych?

   2. Instalacja

   3. Przygotowanie do pracy

   4. Uruchamianie mostu

   5. Konfiguracja firewalla

   6. Podziekowania

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.
