5. Ładowanie i manipulowanie regułami filtra; Narzędzie ipf

Reguły Filtra IP ładowane są przez narzędzie ipf. Reguły można przechować w dowolnym pliku, ale normalnie stosuje się pliki /etc/ipf.rules, /usr/local/etc/ipf.rules lub /etc/opt/ipf/ipf.rules.

Filtr IP ma dwa zestawy reguł, zestaw aktywny i nieaktywny. Domyślnie, wszystkie operacje przeprowadzane są na zestawie aktywnym. Możesz pracować na zestawie nieaktywnym przez dodanie `-I' do linii poleceń ipf. Zestawy zamienia się miejscami przez użycie opcji `-s'. Jest to bardzo przydatne podczas testowania nowych zestawów reguł, bez usuwania starego zestawu.

Reguły można również usuwać z listy, stosując opcję `-r', ale generalnie bezpieczniejsze jest po prostu usunąć cały zestaw reguł nad którym pracujesz przy użyciu opcji `-F' i załadować go po wykonaniu zmian.

Podsumowując, najłatwiejszym sposobem by załadować zestaw reguł jest użycie polecenia `ipf -Fa -f /etc/ipf.rules'. Jeśli chodzi o bardziej skomplikowane manipulowanie zestawami reguł, sprawdź stronę podręcznika ipf(1).

6. Ładowanie i manipulowanie regułami NAT; narzędzie ipnat

Reguły NAT ładowane są przez narzędzie ipnat. Reguły NAT można przechowywać w dowolnym pliku, ale normalnie stosuje się pliki `/etc/ipnat.rules', `/usr/local/etc/ipnat.rules' lub `/etc/opt/ipf/ipnat.rules'.

Reguły można również usuwać z listy, stosując opcję `-r', ale generalnie bezpieczniejsze jest po prostu usunąć cały zestaw reguł nad którym pracujesz przy użyciu opcji `-C' i załadować go po wykonaniu zmian. Żadne aktywne mapowania nie są usuwane przy użyciu `-C', ale można je usunąć poleceniem `-F'.

Reguły NAT i aktualne mapowania można sprawdzić używając opcji `-l'.

Podsumowując, najłatwiejszym sposobem by załadować zestaw reguł jest użycie polecenia `ipnat -CF -f /etc/ipnat.rules'.

7. Monitoring i odpluskwianie

Przyjdzie kiedyś moment, że zainteresujesz się tym, co tak naprawdę robi Twoja ściana ogniowa, a ipfilter byłby niekompletny bez pełnego zestawu narzędzi monitorujących.

7.1 Narzędzie ipfstat

W swojej najprostszej formie, ipfstat wyświetla tabelę interesujących danych dotyczących tego, jak Twoja ściana ogniowa daje sobię radę, czyli między innymi ilość pakietów które zostały przepuszczone i zablokowane, czy zostały zalogowane czy nie, ile jest aktywnych pozycji w liście stanów i tak dalej. Poniżej przykład czegoś, co mógłbyś zobaczyć po uruchomieniu tego narzędzia:

# ipfstat
input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0
output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0
input packets logged: blocked 99286 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 3898 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 169364 lost 0
packet state(out): kept 431395 lost 0
ICMP replies: 0 TCP RSTs sent: 0
Result cache hits(in): 1215208 (out): 1098963
IN Pullups succeeded: 2 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
none

Jest również w stanie pokazać aktualną listę reguł. Użycie flagi `-i' lub `-o' pokaże listę reguł dla odpowiednio pakietów wchodzących i wychodzących. Dodanie opcji `-h' doda trochę użytecznych informacji, podając również 'licznik trafień' dla każdej reguły. Na przykład:

# ipfstat -ho
2451423 pass out on xl0 from any to any
354727 block out on ppp0 from any to any
430918 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keep frags

Z przykładu powyżej widać, że prawdopodobnie dzieje się coś nienormalnego, ponieważ mamy bardzo dużo zablokowanych pakietów wychodzących, nawet przy użyciu reguły `pass out'. Coś może wymagać tutaj dalszego zainteresowania, albo po prostu pracuje bez zarzutu. ipfstat nie może powiedzieć Ci czy Twoje reguły są dobre czy złe, może tylko poinformować co dzieje się przy ich użyciu.

W dalszym procesie odpluskwiania reguł, możesz zechcieć użyć opcji `-n' która pokaże numery reguł przy każdej z nich:

# ipfstat -on
@1 pass out on xl0 from any to any
@2 block out on ppp0 from any to any
@3 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keep frags

Ostatnią naprawdę interesującą informacją w ipfstat, jest zrzut tabeli stanów. Wykonuje się to dodając opcję `-s':

# ipfstat -s
281458 TCP
319349 UDP
0 ICMP
19780145 hits
5723648 misses
0 maximum
0 no memory
1 active
319349 expired
281419 closed
100.100.100.1 -> 20.20.20.1 ttl 864000 pass 20490 pr 6 state 4/4
pkts 196 bytes 17394 987 -> 22 585538471:2213225493 16592:16500
pass in log quick keep state
pkt_flags & b = 2, pkt_options & ffffffff = 0
pkt_security & ffff = 0, pkt_auth & ffff = 0

Widzimy, że mamy aktualnie jedno połączenie TCP. Dane wyjściowe będą się delikatnie różnić od wersji do wersji, ale generalnie informacje są te same. Widzimy dla tego połączenia, że jest ono w pełni nawiązane ( state 4/4 na końcu linijki, inne stany są niekompletne i opiszemy je później ). Możemy również odczytać że wpis ten ma czas życia ( ang. time to live ) 240 godzin, co jest absurdalnie długim czasem, ale ustawianym domyślnie dla nawiązanej sesji TCP. Licznik ten jest zmniejszany z każdą sekundą bezczynności, aż w końcu połączenie zostanie zerwane jeśli zostanie pozostawione bezczynnie. Licznik jest również zerowany na wartość 864000 za każdym razem, gdy użyjemy wpisu, więc połączenie nie zostanie zamknięte w trakcie jego używania. Możemy również odczytać, że przepuściliśmy przez to połączenie 196 pakietów składających się na około 17kB danych. Oprócz tego można odczytać porty po obu stronach - 987 i 22, co oznacza że ten wpis symbolizuje połączeniu z adresu 100.100.100.1 portu 987 na adres 20.20.20.1 na port 22. Bardzo duże numery w drugiej linijce to numery sekwencyjne TCP wygenerowane dla tego połączenia, pomagające zabezpieczyć je przed wpuszczeniem dodatkowych, spreparowanych pakietów. Pokazane jest również okno TCP. Trzecia linia stanowi wynik reguły która została wygenerowana przez regułę keep state i pokazuje ona że jest to połączenie przychodzące.

7.2 Narzędzie ipmon

ipfstat jest fajny jeśli chodzi o sprawdzenie aktualnego stanu systemu, ale zwykle chcemy mieć również jakiś log, by oglądać wydarzenia dziejące się w czasie. Służy do tego ipmon. Jest on zdolny do sprawdzania logów pakietów ( tworzonych przez słowo kluczowe log w regułach ), logu tabeli stanów i logu NAT, lub dowolnej kombinacji tych trzech. Narzędzie to może pracować zarówno na pierwszym planie, lub jako demon który loguje informacje do syslog lub pliku. Jeśli chcielibyśmy zobaczyć listę stanów w akcji, użyjemy polecenia `ipmon -o S':

# ipmon -o S
01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR udp
01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123 PR udp
01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123 PR udp
01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53 PR udp Pkts 4 Bytes 356
01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp
01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp Pkts 63 Bytes 4604

Widzimy zapytanie DNS z zewnętrznej maszyny do naszego serwera, dwa pingi xntp do dobrze znanych serwerów czasu i połączenie wychodzące ssh które trwało bardzo krótko.

ipmon jest również w stanie pokazać nam jakie pakiety są logowane. Na przykład, kiedy używamy stanów, często spotkasz pakiety takie jak ten:

# ipmon -o I
15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 1488 -A

Co to oznacza? Pierwsze pole to oczywiście stempel czasu. Drugie jest również raczej oczywiste, to interfejs na którym wydarzyło sie zdarzenie. Trzecie pole @0:2 to coś, co ludzie zwykle pomijają. To oznaczenie reguły która spowodowała zdarzenie. Pamiętasz `ipfstat -in'? Jeśli chciałbyś wiedzieć co spowodowało zalogowanie pakietu, powinieneś obejrzeć regułę 2 w grupie 0. Czwarte pole, małe `b' mówi że pakiet został zablokowany, i generalnie będziesz to ignorował, chyba że logujesz również pakiety które przepuszczasz, co spowoduje pokazanie się literki `p'. Piąte i szóste pole nie wymagają chyba wyjaśnienia - mówią skąd pakiet przyszedł i gdzie miał dotrzeć. Siódme ( PR ) i ósme pole to protokół, a dziewiąte długość pakietu. Ostatnia część, `-A' to flagi które były ustawione; ten pakiet ma ustawioną flagę ACK. Dlaczego wspomniałem na początku stany? Ponieważ często w Internecie zdarzają się lagi, pakiety są regenerowane i czasami dostaniesz dwa takie same, co spowoduje stwierdzenie przez kod odpowiedzialny za śledzenie połączeń, że to pakiet należący do innego połączenia. Być może trafi on na regułę. Zwykle zobaczysz tutaj zalogowany ostatni pakiet sesji, ponieważ kod `keep state' wyrzuci połączenie zanim ostatni pakiet będzie miał szansę dotrzeć do Twojej ściany ogniowej. To normalne zachowanie, nie denerwuj się. Innym przykładem pakietu może być:

12:46:12.470951 xl0 @0:1 S 20.20.20.254 -> 255.255.255.255 PR icmp len 20 9216 icmp 9/0

Jest to broadcast rozpoznawczy ICMP routera. Możemy to stwierdzić na podstawie typu ICMP: 9/0.

ipmon pozwala również na obejrzenie tabeli NAT:

# ipmon -o N
01/08/1999 05:30:02.466114 @2 NAT:RDR 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816]
01/08/1999 05:30:31.990037 @2 NAT:EXPIRE 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816] Pkts 10 Bytes 455

Widzimy tu przekierowanie do serwera identd, który oszukuje twierdząc, że udostępnia usługę ident dla maszyn za naszym NATem, ponieważ zwykle nie mogą one sobie same zapewnić tej usługi przy zwykłym NATcie.