[ Pobierz całość w formacie PDF ]
.Użycie flagi -i lub -o pokaże listę reguł dla odpowiedniopakietó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 -ho2451423 pass out on xl0 from any to any354727 block out on ppp0 from any to any430918 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keeZ przykładu powyżej widać, że prawdopodobnie dzieje się coś nienormalnego, ponieważ mamy bardzo dużozablokowanych pakietów wychodzących, nawet przy użyciu reguły pass out.Coś może wymagać tutaj dalszegozainteresowania, albo po prostu pracuje bez zarzutu.ipfstat nie może powiedzieć ci czy twoje reguły są dobre czyzłe, może ci tylko powiedzieć co się dzieje przy użyciu twoich reguł.By dalej odpluskwiać swoje reguły, 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 frOstatnią naprawdę interesującą informacją w ipfstat, jest zrzut tabeli stanów.Wykonuje się to dodając opcję -s':# ipfstat -s281458 TCP319349 UDP0 ICMP19780145 hits5723648 misses0 maximum0 no memory1 active319349 expired281419 closed100.100.100.1 -> 20.20.20.1 ttl 864000 pass 20490 pr 6 state 4/4pkts 196 bytes 17394 987 -> 22 585538471:2213225493 16592:16500pass in log quick keep statepkt_flags & b = 2, pkt_options & ffffffff = 0pkt_security & ffff = 0, pkt_auth & ffff = 0Widzimy, ż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 nakońcu linijki, inne stany są niekompletne i opiszemy je pózniej).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ązanejsesji TCP.Licznik ten jest zmniejszany z każdą sekundą gdy wpis nie jest używany, aż w końcu połączenie zostaniezerwane jeśli zostanie pozostawione bezczynnie.Licznik jest również zerowany na wartość 864000 za każdymrazem, 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 tegomożna odczytać porty po obu stronach - 987 i 22, co oznacza że ten wpis symbolizuje połączeniu z adresu100.100.100.1 portu 987 na adres 20.20.20.1 na port 22.Bardzo duże numery w drugiej linijce to numerysekwencyjne TCP wygenerowane dla tego połączenia, pomagające zabezpieczyć je przed wpuszczeniemdodatkowych, spreparowanych pakietów.Pokazane jest również okno TCP.Trzecia linia stanowi wynik reguły którazostała wygenerowana przez regułę keep state i pokazuje ona że jest to połączenie przychodzące.7.2 Narzędzie ipmonipfstat 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 tychtrzech.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 S01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR udp01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123 PR udp01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123 PR udp01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53 PR udp Pk01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22 PR tcpWidzimy zapytanie DNS z zewnętrznej maszyny do naszego serwera, dwa pingi xntp to dobrze znanych serwerówczasu 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ęstospotkasz pakiety takie jak ten:# ipmon -o I15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 14Co to oznacza? Pierwsze pole to oczywiście stempel czasu.Drugie jest również raczej oczywiste, to interfejs naktórym wydarzyło sie zdarzenie.Trzecie pole @0:2 to coś, co ludzie zwykle pomijają.To oznaczenie reguły któraspowodował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 generalniebę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ą one skąd pakiet przyszedł i gdzie miał dotrzeć [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.Użycie flagi -i lub -o pokaże listę reguł dla odpowiedniopakietó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 -ho2451423 pass out on xl0 from any to any354727 block out on ppp0 from any to any430918 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keeZ przykładu powyżej widać, że prawdopodobnie dzieje się coś nienormalnego, ponieważ mamy bardzo dużozablokowanych pakietów wychodzących, nawet przy użyciu reguły pass out.Coś może wymagać tutaj dalszegozainteresowania, albo po prostu pracuje bez zarzutu.ipfstat nie może powiedzieć ci czy twoje reguły są dobre czyzłe, może ci tylko powiedzieć co się dzieje przy użyciu twoich reguł.By dalej odpluskwiać swoje reguły, 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 frOstatnią naprawdę interesującą informacją w ipfstat, jest zrzut tabeli stanów.Wykonuje się to dodając opcję -s':# ipfstat -s281458 TCP319349 UDP0 ICMP19780145 hits5723648 misses0 maximum0 no memory1 active319349 expired281419 closed100.100.100.1 -> 20.20.20.1 ttl 864000 pass 20490 pr 6 state 4/4pkts 196 bytes 17394 987 -> 22 585538471:2213225493 16592:16500pass in log quick keep statepkt_flags & b = 2, pkt_options & ffffffff = 0pkt_security & ffff = 0, pkt_auth & ffff = 0Widzimy, ż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 nakońcu linijki, inne stany są niekompletne i opiszemy je pózniej).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ązanejsesji TCP.Licznik ten jest zmniejszany z każdą sekundą gdy wpis nie jest używany, aż w końcu połączenie zostaniezerwane jeśli zostanie pozostawione bezczynnie.Licznik jest również zerowany na wartość 864000 za każdymrazem, 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 tegomożna odczytać porty po obu stronach - 987 i 22, co oznacza że ten wpis symbolizuje połączeniu z adresu100.100.100.1 portu 987 na adres 20.20.20.1 na port 22.Bardzo duże numery w drugiej linijce to numerysekwencyjne TCP wygenerowane dla tego połączenia, pomagające zabezpieczyć je przed wpuszczeniemdodatkowych, spreparowanych pakietów.Pokazane jest również okno TCP.Trzecia linia stanowi wynik reguły którazostała wygenerowana przez regułę keep state i pokazuje ona że jest to połączenie przychodzące.7.2 Narzędzie ipmonipfstat 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 tychtrzech.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 S01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR udp01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123 PR udp01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123 PR udp01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53 PR udp Pk01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22 PR tcpWidzimy zapytanie DNS z zewnętrznej maszyny do naszego serwera, dwa pingi xntp to dobrze znanych serwerówczasu 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ęstospotkasz pakiety takie jak ten:# ipmon -o I15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 14Co to oznacza? Pierwsze pole to oczywiście stempel czasu.Drugie jest również raczej oczywiste, to interfejs naktórym wydarzyło sie zdarzenie.Trzecie pole @0:2 to coś, co ludzie zwykle pomijają.To oznaczenie reguły któraspowodował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 generalniebę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ą one skąd pakiet przyszedł i gdzie miał dotrzeć [ Pobierz całość w formacie PDF ]