FreeBSD Logo               

Skąd pobrać FreeBSD? Wybierz serwer ftp:
 

 


Dokumentacja
 
manuale  
  faq 
 
handbook

Jak to zrobić?
  Instalacja
  Komendy
  Usługi
  Upgrade
  NFS
  Jądro
  SDI-PPP
  Identyfikacja
  Quota
  OpenSSH
  TelnetSSL 
  Agenci MTA
  POP3 i SMTP
  Autoryzacja
  Serwer WWW
  Serwer NEWS
  Serwer Nazw
  ProFTPD
  IPv6
  Squid
  Samba
  DHCP
  Dummynet
  Ipfilter
  PF
  Polonizacja
  VMvare
  Udostępnianie
  Mały Router
 
Terminal
  Linux2FreeBSD

Niusy
  pl.comp.os.bsd

Po polsku
  bsdzine.org
  freebsd.pl
  www.bsd4u.org
  www.bsdguru.org
  bofh.vt.pl

Po innemu
  bsdvault.net
  freebsdhowtos.com
  freebsd-howto.com

Linkownia



Studio reklamowe

Usługi informatyczne MAC






Firewall dla sieci domowej lub małego biura



Uwaga:
Przedstawiony opis jest FAQ dla OpenBSD. Można go spokojnie wykorzystywać do konfigurowania swojego firewall'a dla FreeBSD 5.3. Dodatkową zalętą dla pf jest niewątpliwie to iż zestawy reguł można rozbudować spokojnie o obsługę ALTQ pozwalającego dzielić nasze łącze dynamicznie.



Spis treści


Wstęp

W tym FAQ zostanie omówiony przykład wykorzystania maszyny z OpenBSD i działaj.cym PF do zbudowania firewalla i bramki NAT dla niewielkiej sieci w domu lub biurze. Głównym celem jest udostępnienie połączenia z Internetem komputerom w sieci wewnętrznej, a także umożliwienie ograniczonego dostępu z Internetu do maszyny spełniaj.cej rolę ściany ogniowej. Kompletny przykład będzie można znaleźć na końcu tego dokumentu.

Sieć

Topologia sieci wygląda następująco:
    
  [ KOMP1 ]    [ KOMP3 ]
      |            |                               ADSL
   ---+------+-----+------- fxp0 [ OpenBSD ] ep0 -------- ( Internet )
             |
         [ KOMP2 ]

Do sieci wewnętrznej przyłączonych jest kilka maszyn, co prawda na schemacie zaznaczone są trzy, ale w tym przypadku ich ilość nie ma żadnego znaczenia. Komputery te wykorzystywane są. do codziennych zadań takich jak: przeglądanie stron www, wysyłanie poczty elektronicznej, rozmów, itd., za wyjątkiem KOMP3, który służy również jako niewielki serwer WWW. Przestrzeń adresowa sieci wewnętrznej zawiera się w bloku 192.168.0.0 / 255.255.255.0.

Router zbudowany na bazie OpenBSD to komputer z procesorem Pentium 100 i dwiema kartami sieciowymi: 3Com 3c509B (ep0) i Intel EtherExpress Pro/100 (fxp0). Połączony jest on z Internetem łączem ADSL, a do udostępniania połączenia innym komputerom wykorzystywany jest NAT. Adres IP dla zewnętrzenego interfejsu uzyskiwany jest dynamicznie od Dostawcy Usług Internetowych.

Założenia

Założenia, którymi należy kierować się przy budowie regułek filtrowania:
  • Umożliwienie niczym nieograniczonego dostępu do Internetu komputerom z sieci wewnętrznej.
  • Zastosowanie regułek filtra zapewniających "domyślne blokowanie" ruchu przychodzącego.
  • Przepuszczanie ruchu z Internetu skierowanego do następujących portów:
    • SSH (TCP port 22): używany do zdalnej administracji ściany ogniowej.
    • Auth/Ident (TCP port 113): używany przez niektóre usługi, takie jak SMTP czy IRC.
    • ICMP Echo Requests: ten typ pakietów ICMP jest używany przez program ping(8).
  • Przekierowanie poł.czeń na porcie 80 protkołu TCP (które są próbą połączenia się z serwerem WWW) do komputera KOMP3. A także przepuszenie przez firewall ruchu na porcie 80 protokołu TCP przeznaczonego dla COMP3.
  • Logowanie statystyk filtra pakietów dla zewnetrznego interfejsu sieciowego.
  • Wysyłanie domyślnej odpowiedzi TCP RST lub ICMP Unreachable na zablokowane pakiety.
  • Stworzenie zestawu reguł, który będzie prosty i zrozumiały.

Wymagania

Podczas pisania tego FAQ przyjęto, że OpenBSD został poprawnie skonfigurowany do przyszłej pracy jako router, włączając w to właściwe przygotowanie sieci, połączenia z Internetem, oraz ustawienia zmiennej sysctl net.inet.ip.forwarding na "1".

Budowanie zestawu reguł

Wykonanie poleceń zawartych w następujących podrozdziałach zaowocuje otrzymaniem kompletnego zestawu reguł spełniającego wszystkie warunki podane powyżej.

Makra

Poniższe makra mają na celu ułatwienie zrozumienia oraz usprawnienie zarządzania zestawem reguł:
int_if = "fxp0"
ext_if = "ep0"

tcp_services = "{ 22, 113 }"
icmp_types = "echoreq"

priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

comp3 = "192.168.0.3"

Pierwsze dwie linie określają na jakich interfejsach będzie odbywać się filtrowanie. Trzecia linia zawiera liste portów TCP (SSH i ident/auth), do których ruch z Internetu ma być przepuszczany. W czwartej linii określone są typy komunikatów ICMP, które nie będą blokowane. W piątej linii wyszczególnione są adresy pęlti zwrotnej oraz zarezerwowane bloki sieci opisane w RFC 1918. Ostatnia linia określa adres IP komputera KOMP3.

Uwaga: Jeśli połączenie ADSL odbywa się poprzez PPPoE, wtedy filtrowanie oraz translacja pakietów odbywać się będzie na interfejsie tun0 a nie na ep0.

Opcje

Dwie poniższe opcje włączają. domyślne odpowiedzi na zablokowane pakiety dla reguły block, a także zbieranie różnego rodzaju statystyk dla zewnętrznego interfejsu sieciowego.
set block-policy return
set loginterface $ext_if

Normalizacja pakietów

Nie istnieje żaden ważny powód dla którego nadchodz.ce pakiety nie miały by zostać poddane normalizacji. Włączenie normalizowania pakietów odbywa się przez dodanie jednej, prostej linii:
scrub in all

Translacja adresów

Wł.czenie translacji adresów (NAT) dla hostów w sieci wewnętrznej uzyskuje się przez dodanie regułki nat:
nat on $ext_if from $int_if:network to any -> ($ext_if)

Jako że adres IP dla zewnętrznego interfejsu sieciowego jest uzyskiwany dynamicznie, nazwa interfejsu na którym odbywa się mapowanie adresów została wzięty w nawiasy, dzięki temu PF zostanie powiadomione o każdej zmianie adresu.

Przekierowanie

Pierwsze przekierowanie w tym zestawie reguł jest dla ftp-proxy(8), aby klient FTP w sieci lokalnej mógł bez problemów połączyć się z serwerami FTP w Internecie.
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

Proszę zauważyć, że regułka ta obsługuje jedynie połączenia FTP na porcie 21. Je.li zajdzie potrzeba umożliwienia korzystania z innych numerów portów, konieczne będzie podanie ich w postaci listy, na przykład: from any to any port { 21, 2121}

Druga regułka rdr służy do przekierowania prób połączeń z portem 80 protokołu TCP firewalla. Poprawne połączenia z tym portem pochodzą od użytkowników chc.cych uzyskać dostęp do serwra WWW. Połączenia te powinny zostać przekierowane do komputera KOMP3:

rdr on $ext_if proto tcp from any to any port 80 -> $comp3

Regułki filtra pakietów

Po ustawieniu NAT i przekierowań można przystąpić do konfiguracji filtra pakietów. Filtr będzie pracował zgodnie z zasadą "domyślnego blokowania":
block all

W tym miescu żaden ruch nie jest przepuszczany przez scianę ogniową, nawet ten pochodzący z sieci wewnętrznej. Kolejne regułki będą umożliwiały przejście datagramów zgodnie z wytycznymi podanymi wcześniej.

Każdy system UNIX posiada intefejs pętli zwrotnej nazywany "loopback". Jest to wirtualny interfejs sieciowy używany przez procesy do komunikacji z innymi aplikacjami uruchomionymi w lokalnym systemie. Cały ruch na tym interfejsie powinnien być przepuszczany bez żadnych ograniczeń. W OpenBSD interfejs "loopback" nazywa się: lo(4).

pass quick on lo0 all

Pakiety posiadaj.ce jako adres docelowy lub źródłowy, jeden z adresów opisanych w RFC 1918, przechodzące w dowolnym kierunku przez interfejs zewnętrzny zostan. zablokowane - te adresy nigdy nie powinny pojawić się w Internecie. Wprowadzenie tych regułek daje gwarancje, że żaden z zarezerwowanych adresów nie przedostanie się do Internetu, a także zapobiega przyjmowaniu pakietów ze świata posiadających jako adres źródłowy jeden z adresów z RFC 1918.

block drop in  quick on $ext_if from $priv_nets to any
block drop out quick on $ext_if from any to $priv_nets

Należy zwrócić uwagę, że block drop okre.la, że filtr PF nie ma wysyłać TCP RST lub ICMP Unreachable w odpowiedzi na zablokowane pakiety. Adresy z RFC 1918 nie istniej. w Internecie, żaden pakiet wysłany pod ten adres nie dotrze do miejsca przeznaczenia. Opcja quick mówi, że PF ma przerwać sprawdzanie dalszej części zestawu je.li pakiet pasował do tej regułki. Pakiety pochodzące lub skierowane do sieci $priv_nets będą natychmiast odrzucone.

Następna regułka otwiera porty dla usług, które mają być udostępnione w Internecie:

pass in on $ext_if inet proto tcp from any to ($ext_if) \
   port $tcp_services flags S/SA keep state

Podanie portów w postaci makra $tcp_services sprawia, że łatwo dodać kolejne usługi, które mają zostać udostępnione. Wystarczy wyedytować makro i ponownie załadować zestaw reguł. Podobnie sprawa ma się z usługami bazującymi na protokole UDP, potrzeba tylko utworzyć makro $udp_services i dodać bardzo podobną regułkę, jak ta pokazana powyżej, z opcją proto udp.

Dodatkowo, obok reguły rdr, która przekierowuje ruch skierowany do serwera WWW do komputera KOMP3, konieczne jest przepuszczenie tego ruchu przez firewall:

pass in on $ext_if proto tcp from any to $comp3 port 80 \
    flags S/SA synproxy state

Aby odrobinę poprawić bezpieczeństwo zastosowano TCP SYN Proxy, który dodatkowo zabezpiecza serwer przed atakami z zewnątrz.

Aby "aktywne" połączenia FTP działały wewnątrz sieci LAN, następująca reguła musi być wstawiona by przepuszczać połączenia sesji ftp inicjowane przez serwer FTP z powrotem do klienta. Ponieważ w aktywnych połączeniach FTP pośredniczy ftp-proxy, to właśnie ten program przyjmie połączenie z serwera i będzie pośredniczył w komunikacji z klientem w sieci LAN.

pass in on $ext_if inet proto tcp from port 20 to ($ext_if) \
    user proxy flags S/SA keep state

Przepuszczenie pakietów ICMP:

pass in inet proto icmp all icmp-type $icmp_types keep state

Podobnie jak makro $tcp_services, makro $icmp_types może być w łatwy sposób zmienione by umożliwić przepuszczanie innych typów pakietów ICMP przez firewall. Proszę zwrócić uwagę, że regułka ta odnosi się do wszystkich interfejsów sieciowych.

Kolejne regułki przepuszczają ruch z lub do sieci wewnętrznej. Przykład zakłada, że użytkownicy na wewnętrznym interfejsie dokładnie wiedzą co robią i nie będą powodować problemów. To niekoniecznie prawidłowe założenie, mniejsza swoboda może być bardziej odpowiednia w niektórych przypadkach.

pass in on $int_if from $int_if:network to any keep state

Powyższa regułka zezwala hostom z sieci lokalnej na wysyłanie pakietów przez scianę ogniow., nie umożliwia natomiast na nawiązanie połączenia routera z komputerem z sieci wewnętrznej. Czy to dobre rozwiązanie? Odpowiedź uzależniona jest od kilku elementów konfiguracji sieci. Jeżeli firewall jest jednocześnie serwerem DHCP, przed przydzieleniem adresu konieczne może być sprawdzenie czy nie jest on już przypisany do innego hosta. Jeżli firewall ma możliwość nawiązania połączenia z maszyn. w sieci lokalnej, każdy kto zaloguje się do routera będzie miał dostęp do komputrów wewnątrz sieci lokalnej. Należy jednak pamiętać, że nie jest to właściwie żadna znacząca poprawa bezpieczeństwa - jeśli ktoś niepowołany uzyska dostęp do bramki, będzie też najprawdopodobniej mógł zmienić reguły filtra pakietów. Dodanie następnej regułki sprawi, że firewall będzie mógł bez przeszkód komunikować się z maszynami w sieci wewnętrznej:

pass out on $int_if from any to $int_if:network keep state

Ważne jest to, że je.li obie powyższe linie będą umieszczone w pliku konfiguracyjnym, dyrektywa keep state nie jest konieczna - wszystkie pakiety będą mogły wyjść poprzez zewnętrzny interfejs bez konieczności śledzenia stanów. Jednakże, jeżeli linia zaczynająca się od pass out nie będzie dodana, konieczne jest umieszczenie w linii rozpoczynającej się od pass in opcji keep state. Dzięki zastosowaniu śledzenia stanów można osiągnąć pewną poprawę wydajności - tablice stanów są sprawdzane zanim datagram zostanie sprawdzony poprzez reguły, ale poprawa wydajności dotyczyć będzie w głównej mierze bardzo obciążonych filtrów, a że ten przykładowy system jest bardzo prosty, raczej mało prawdopodobne aby można było zauważyć różnice.

Ostatnie regułki zezwalają na przepuszczenie ruchu wychodzącego przez zewnętrzny interfejs sieciowy.

pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state

Ruch na protokołach TCP, UDP i ICMP jest przepuszczany do Internetu, a śledzenie stanów pozwala przepuścić pakiety, które są odpowiedzią na wysłane datagramy.

Kompletny zestaw reguł

# makra
int_if = "fxp0"
ext_if = "ep0"

tcp_services = "{ 22, 113 }"
icmp_types = "echoreq"

priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"
	  
comp3 = "192.168.0.3"

# opcje
set block-policy return
set loginterface $ext_if

# normalizacja datagramów 
scrub in all

# nat/rdr
nat on $ext_if from $int_if:network to any -> ($ext_if)
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 \
   port 8021
rdr on $ext_if proto tcp from any to any port 80 -> $comp3

# regułki filtra pakietów
block all

pass quick on lo0 all

block drop in  quick on $ext_if from $priv_nets to any
block drop out quick on $ext_if from any to $priv_nets

pass in on $ext_if inet proto tcp from any to ($ext_if) \
   port $tcp_services flags S/SA keep state

pass in on $ext_if proto tcp from any to $comp3 port 80 \
   flags S/SA synproxy state

pass in on $ext_if inet proto tcp from port 20 to ($ext_if) \
   user proxy flags S/SA keep state

pass in inet proto icmp all icmp-type $icmp_types keep state

pass in  on $int_if from $int_if:network to any keep state
pass out on $int_if from any to $int_if:network keep state

pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state



Więcej w orginalnym artukule http://www.openbsd.org



marzec 2005





Kontakt  

© 2001-2009 FreeBSD Projekt
Wszelkie Prawa Zastrzeżone.