8. Specyficzne zastosowania Filtra IP - rzeczy które nie pasowały wyżej, ale są warte wspomnienia

8.1 Utrzymywanie stanu oraz flagi i serwery

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.

8.2 Radzenie sobie z FTP

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.
Konfiguracja dla serwera FTP

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.
Konfiguracja dla klientów FTP

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

8.3 Zmienne kernela dotyczące tematu

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