Ściany ogniowe są tematem coraz większego zainteresowania ludzi podłączonych do Internetu. Znajdują również coraz częściej zastosowanie w środku sieci umożliwiając dokładniejsze zabezpieczenie własnej sieci. Ta sekcja ma nadzieję wyjaśnić czym ściany ogniowe są, jak ich używać i jak obsługiwać mechanizmy wbudowane w kernel FreeBSD, umożliwiające ich budowę.
Notatka: Ludzie uważają zwykle, że umiejscowienie ściany ogniowej pomiędzy siecią wewnętrzną a ``Wielkim Złym Internetem'' rozwiąże ich wszystkie problemy z bezpieczeństwem. Prawdopodobnie nie zaszkodzi, ale słabo zbudowana ściana ogniowa może stać się większym zagrożeniem dla sieci niż w ogóle jej brak. Ściana ogniowa dodaje dodatkową warstwę ochronną do bezpieczeństwa twoich systemów, ale nie powstrzyma naprawdę zdeterminowanego włamywacza przed penetracją twojej sieci wewnętrznej. Jeśli oprócz skonfigurowania ściany ogniowej nie zrobisz nic w celu zabezpieczenia swojego sprzętu, ułatwisz tylko znacznie zadanie włamywaczom.
Obecnie używa się dwóch różnych rodzajów ścian ogniowych. Pierwszy rodzaj, zwykle nazywany routerem z filtrowaniem pakietów stosowany jest w instalacjach, w których kernel ma wiele interfejsów fizycznych i przekazuje między nimi lub blokuje pakiety w oparciu o zestaw reguł. Drugi rodzaj - serwery proxy, opiera się na demonach sieciowych zapewniających uwierzytelnianie i przekazywanie pakietów. Stosowany jest zwykle na komputerach z wyłączonym przekazywaniem pakietów pomiędzy interfejsami.
Czasami pojedyncze instalacje łączą oba typy ścian ogniowych - tylko określony komputer ( nazywany zwykle bastionem ) uprawniony jest do generowania ruchu bezpośrednio do Internetu i sieci wewnętrznej. Pracujące na hoście-bastionie usługi proxy są zwykle bezpieczniejsze niż inne sposoby uwierzytelniania.
FreeBSD dostarczany jest z filtrem pakietów ( IPFW ) w kernelu, na którym skoncentrujemy się w dalszej części tego dokumentu. Serwery proxy można wbudować we FreeBSD korzystając z rozwiązań firm trzecich, ale z uwagi na ich zróżnicowanie niemożliwością jest opisanie ich w tej sekcji.
Router to maszyna przekazująca pakiety pomiędzy dwoma lub większą ilością sieci. Router filtrujący pakiety posiada dodatkowy kod porównujący przekazywane pakiety do listy reguł - decydując czy dany pakiet może zostać przekazany dalej czy nie. Większość nowoczesnych systemów prowadzących routing IP ma wbudowany kod filtrujący pakiety domyślnie skonfigurowany na przepuszczanie całego ruchu. Aby zaktywować filtry musisz zdefiniować zestaw reguł określając tym samym jakie pakiety powinny być odrzucane a jakie przepuszczane.
Aby móc stwierdzić czy dany pakiet powinien zostać przepuszczony, kod filtrujący sprawdza zestaw reguł z zawartością nagłówków pakietów. Po natrafieniu na regułę pasującą do pakietu, wykonywana jest zdefiniowana akcja. Reguła może odrzucić pakiet, przekazać go, a czasami nawet wysłać pakiet ICMP do źródła pakietu z określoną informacją. Liczy się tylko pierwsza pasująca reguła, ponieważ reguły przeszukiwane są według pewnego porządku. Stąd nazwa ``łańcuch reguł''.
Dostępne kryteria sprawdzania pakietów są zróżnicowane w zależności od oprogramowania, ale zwykle możesz podać reguły określające przynajmniej źródłowy adres IP, docelowy adres IP, źródłowy i docelowy numer portu (dla protokołów obsługujących porty) lub nawet protokół (UDP, TCP, ICMP itp.).
Serwery proxy to maszyny których standardowe demony ( takie jak telnetd, ftpd itd. ) zostały zastąpione przez specjalne serwery. Nazywane są one właśnie serwerami proxy ponieważ zwykle obsługują one przechodzące przez maszynę połączenia. Można je zatem zainstalować na maszynie pełniącej funkcję ściany ogniowej. Umożliwia to klientom telnetowanie się z sieci zewnętrznej, uwierzytelnianie na ścianie ogniowej i w przypadku przejścia poprawnie tego procesu dostęp do zasobów sieci wewnętrznej (i odwrotnie dla ruchu z sieci wewnętrznej do sieci zewnętrznej).
Serwery proxy są zwykle skonfigurowane w sposób dużo bardziej bezpieczny niż zwykłe serwery, zapewniają również dużo szerszy zakres usług uwierzytelniania. Przykładem mogą być ``hasła jednorazowe'', przy których zastosowaniu nawet jeśli ktoś podsłucha twoje hasło nie umożliwi mu ono dostępu do sieci ponieważ w momencie użycia jego ważność wygasa. Ponieważ hasła używane do uwierzytelniania użytkowników na serwerach proxy nie służą zwykle do dostępu do maszyny pracującej jako serwer proxy, zainstalowanie tylnego wejścia staje się dużo trudniejsze.
Serwery proxy zapewniają również zwykle dodatkowe sposoby kontroli dostępu i uprawnień, tak by tylko np. określone hosty mogły uzyskać dostęp do serwera, lub by tylko określona liczba użytkowników mogła jednocześnie korzystać z usług serwera proxy. Wszystko zależy od oprogramowania zainstalowanego jako proxy.
IPFW, oprogramowanie dołączone do FreeBSD pełni funkcję filtra pakietów oraz systemu rozliczania z generowanego ruchu. IPFW jest zintegrowany z jądrem, a interakcję z użytkownikiem zapewnia narzędzie pracujące w przestrzeni użytkownika, ipfw(8). Razem umożliwiają one definiowanie i sprawdzanie reguł używanych przez jądro w procesie podejmowania decyzji o routingu pakietów.
IPFW składa się z dwóch części. Pierwsza zajmuje się filtrowaniem pakietów. Druga zajmuje się rozliczaniem z ruchu IP i umożliwia nadzorowanie pracy routera na podstawie reguł filtra pakietów. Dzięki temu możliwe staje się sprawdzenie np. ile ruchu generowanego jest przez określoną maszynę lub jak dużo ruchu do i z serwerów WWW router przekazuje.
Dzięki takiej a nie innej konstrukcji IPFW, możesz używać IPFW również na maszynach nie pełniących funkcje routera do filtrowania pakietów w połączeniach przychodzących i wychodzących. Jest to specyficzne zastosowanie IPFW, ale konfigurowane dokładnie tak jak konfiguruje się filtr do innych zastosowań.
Ponieważ główna część IPFW znajduje się w jądrze, będziesz musiał dodać pewien zestaw opcji do pliku konfiguracyjnego jądra - w zależności od tego co dokładnie chcesz osiągnąć. Następnie należy zrekompilować jądro. Zajrzyj do sekcji "Rekonfiguracja Jądra" (Rozdział 9) by uzyskać więcej informacji o tym jak to zrobić.
OstrzeżenieIPFW domyślnie skonfigurowany jest regułą deny ip from any to any. Jeśli nie dodasz żadnych innych reguł podczas startu, na przykład umożliwiających dostęp do maszyny przez sieć, skutecznie zablokujesz sobie jakikolwiek dostęp do komputera. Sugerujemy ustawienie opcji firewall_type=open w pliku /etc/rc.conf podczas pierwszej aktywacji ściany ogniowej a następnie dopasowanie reguł filtrowania z pliku /etc/rc.firewall po przetestowaniu całości. Dla bezpieczeństwa, powinieneś przeprowadzić konfigurację ściany ogniowej przez konsolę a nie przez ssh. Ostatecznie można skompilować jądro z dodaną opcją IPFIREWALL_DEFAULT_TO_ACCEPT. Spowoduje to zmianę domyślnego zachowania IPFW na takie, jakie uzyskasz po wpisaniu reguły allow ip from any to any.
Obecnie w konfiguracji jądra znajdują się trzy opcje związane z IPFW:
Kompiluje do jądra kod odpowierdzialny za filtrowanie.
Uaktywnia logowanie pakietów przez syslogd(8). Bez tej opcji, nawet jeśli określisz że pakiety mają być logowane nic się nie stanie.
Ogranicza ilość pakietów logowanych przez syslogd(8) dla każdej reguły z listy osobno. Opcja przydatna we wrogim środowisku, w którym chcesz logować to co robi ściana ogniowa, ale nie chcesz zapchać swoich logów.
Kiedy dana reguła z listy filtrowania pakietów osiąga wskazany limit, logowanie jest wyłączane (tylko dla tej reguły). Aby je wznowić musisz zresetować określony licznik za pomocą narzędzia ipfw(8):
# ipfw zero 4500
Gdzie 4500 to numer reguły której licznik chcesz zresetować.
Opcja zmienia domyślną regułę znajdującą się na końcu listy z ``deny'' na ``allow''. Stosując ją w konfiguracji jądra unikasz możliwości odcięcia się od systemu, co stanie się po skompilowaniu jądra tylko z opcją IPFIREWALL i bez konfiguracji ściany ogniowej. Opcja jest również użyteczna jeśli używasz ipfw(8) jako filtra dla specyficznych problemów sieciowych. Używaj jej jednak z rozwagą, ponieważ otwiera ona ścianę ogniową i zmienia sposób w jaki ona pracuje.
Notatka: Poprzednie wersje FreeBSD posiadały dodatkowo opcję IPFIREWALL_ACCT. Została ona obecnie wycofana ponieważ jej funkcjonalność zintegrowano z funkcjonalnością samej ściany ogniowej.
Konfigurację IPFW wykonuje się za pomocą narzędzia ipfw(8). Składnia może wydawać się skomplikowana, ale jest relatywnie prosta gdy już zrozumiesz ogólne zasady.
Obecnie dostępne są cztery różne kategorie poleceń: dodawanie/usuwanie, listowanie, opróżnianie i czyszczenie. Dodawanie/usuwanie jak sama nazwa wskazuje służy do konstruowania reguł, kontrolujących przepływ pakietów przez router - czy mają być akceptowane, odrzucane i ewentualnie logowane. Listowanie umożliwia sprawdzenie zawartości zestawu reguł i liczników trafień w poszczególne reguły (w ramach usług rozliczania). Opróżnianie usuwa wszystkie reguły, a czyszczenie resetuje liczniki trafień dla reguł.
Składnia dla tego polecenia jest następująca:
ipfw [-N] polecenie [index] akcja [log] protokół adresy [opcje]
W połączeniu z tą formą polecenia można użyć dodatkowo flagi:
Rozwiązuj nazwy adresów i usług.
Wydane polecenie może być skrócone do najkrótszej unikalnej formy. Prawidłowe polecenia to:
Dodaj wpis do listy reguł ściany ogniowej
Skasuj wpis z listy reguł ściany ogniowej
Poprzednie wersje IPFW używały osobnych poleceń dla kontroli ściany ogniowej i rozliczania z ruchu. Obecna wersja IPFW automatycznie zapewnia zliczanie ruchu dla każdej reguły ściany ogniowej.
Jeśli wskazano wprost wartość index reguła umieszczana jest w tym miejscu łańcucha. W innym przypadku reguła umieszczana jest na końcu łańcucha z indeksem 100 lub wyższym (nie dotyczy to domyślnej reguły umieszczonej pod numerem 65535 którą jest odrzucenie pakietu jeśli jądra nie skonfigurowano inaczej).
Dodatkowy parametr log powoduje że pakiety pasujące do reguły będą logowane na konsolę jeśli jądro zostało skompilowane z opcją IPFIREWALL_VERBOSE.
Dostępne akcje to:
Odrzuć pakiet i wyślij do źródła pakiet ICMP lub komunikat `port nieosiągalny' (w zależności od pakietu).
Prześlij pakiet normalnie (dostępne aliasy to: pass i accept)
Odrzuć pakiet ale nie informuj źródła jakimkolwiek komunikatem ICMP (dla źródła pakietu wygląda to tak jakby do naszej maszyny nie dotarł w ogóle żaden pakiet).
Uaktualnij licznik pakietów pasujących do reguły ale nie decyduj o losie pakietu (jego odrzucaniu lub zaakceptowaniu). Przeglądanie listy jest kontynuowane.
Każda akcja zostaje zinterpretowana na podstawie najkrótszego unikalnego prefiksu.
Możliwe do użycia protokoły to:
Do reguły będą pasować wszystkie pakiety IP
Do reguły pasują tylko pakiety ICMP
Do reguły pasują tylko pakiety TCP
Do reguły pasują tylko pakiety UDP
Adresy można podać w następujących formach:
from adres/maska [port] to adres/maska [port] [via interfejs]
Opcję port możesz podać tylko w połączniu z protokołem który obsługuje porty (TCP i UDP).
Opcja via może wskazać dodatkowo adres IP lub nazwę domenową lokalnego interfejsu IP, lub wprost nazwę interfejsu (np. ed0) tak, by reguła pasowała tylko do pakietów przechodzących przez wskazany interfejs. Nazwa interfejsu może dodatkowo zawierać opcjonalną maskę. Na przykład ppp* oznacza wszystkie interfejsy PPP.
Składnia używana do określenia adresu/maski podana jest poniżej:
adres
or
adres/bity-maski
or
adres:wzorzec-maski
Zamiast adresu IP można również podać prawidłową nazwę hosta. Opcja bity-maski to numer decymalny oznaczający jak wiele bitów w masce ma być ustawione - np. podanie 192.216.222.1/24 stworzy maskę która będzie pasować do dowolnego adresu z podsieci klasy C (w tym przypadku do wszystkich adresów zaczynających się od 192.216.222). Natomiast opcja wzorzec-maski to adres IP który ma być użyty do wykonania logicznej operacji `i'. Słowo kluczowe any oznacza ``wszystkie adresy IP''.
Numery portów należy blokować w ten sposób:
port [,port [,port [...]]]
by określić pojedyńczy lub wiele portów, lubport-port
by wskazać zakres portów. Możesz również połączyć jedną formę z drugą, ale zakres musi być w tym wypadku wskazany pierwszy.Dostępne opcje to:
Pakiet pasuje jeśli stanowi nie pierwszy fragment datagramu.
Pakiet pasuje jeśli dociera do interfejsu.
Pakiet pasuje jeśli ma być wysłany z interfejsu.
Pakiet pasuje jeśli nagłówek IP zawiera wskazane w liście opcje. Obsługiwane opcje IP to: ssrr (ścisłe wskazanie wprost routingu źródłowego), lsrr (swobodny routing źródłowy), rr (zapisz trasę pakietu) oraz ts (znacznik czasowy). Opcje które nie mają być ustawione w nagłówku należy wymienić poprzedzając je znakiem !.
Pakiet pasuje jeśli jest częścią już nawiązanego połączenia TCP (tzn. ma ustawione bity RST lub ACK). Możesz zoptymalizować wydajność ściany ogniowej umieszczając reguły zawierające słowo established na początku listy reguł.
Pasuje jeśli pakiet stanowi próbę nawiązania połączenia TCP (ustawiono bit SYN i zgaszono bit ACK).
Pasuje jeśli nagłówek TCP pakietu ma ustawione wskazane flagi. Obsługiwane flagi to fin, syn, rst, psh, ack oraz urg. Brak ustawionej flagi można wskazać poprzedzając jej nazwę znakiem !.
Pasuje jeśli typ pakietu ICMP pasuje do wskazanego. Lista może zostać wskazana jako zakres lub poszczególne typy rozdzielone przecinkami. Zwykle używane typy ICMP to: 0 odpowiedź na echo (na ping), 3 adres docelowy nieosiągalny, 5 przekierowanie, 8 żądanie echa (ping) oraz 11 przekroczono czas (używany do wskazania wygaśnięcia TTL, zgodnie z traceroute(8)).
Składnia tej postaci polecenia wygląda następująco:
ipfw [-a] [-c] [-d] [-e] [-t] [-N] [-S] list
Dostępne jest siedem prawidłowych flag:
Listując, pokaż liczniki dla poszczególnych reguł. Jedyny sposób by sprawdzić stan liczników.
Wylistuj reguły w formie skondensowanej.
Pokaż oprócz reguł statycznych reguły dynamiczne.
W połączeniu z opcją -d pokaż również wygasłe reguły dynamiczne.
Wyświetl ostatni czas w którym pakiet pasował do reguły. Format podawania czasu jest niekompatybilny ze składnią polecenia umożliwiającego wprowadzanie go za pomocą polecenia ipfw(8).
Polecenie ma postarać się rozwiązać listowane adresy i porty usług.
Wyświetl zestaw do którego należy dana reguła. Jeśli nie podano tego parametru wyświetlone zostaną reguły tylko z zestawu aktywnego.
Składnia umożliwiająca wyczyszczenie łańcucha wygląda następująco:
ipfw flush
Polecenie w tej formie powoduje usunięcie wszystkich reguł oprócz domyślnej reguły wymuszanej przez jądro (o numerze 65535). Powinieneś zastanowić się przed wykonaniem tego polecenia - domyślna polityka blokowania ruchu może odciąć cię od sieci.
Składania do wyzerowania jednego lub większej ilości liczników trafień pakietów w regułę wygląda następująco:
ipfw zero [index]
Jeśli polecenie zostanie użyte bez argumentu index, zerowane są liczniki dla wszystkich reguł. W przeciwnym wypadku zerowanie dotyczy tylko wskazanej reguły.
Poniższe polecenie odrzuci wszystkie pakiety z hosta evil.crackers.org na port telnet hosta nice.people.org:
# ipfw add deny tcp from evil.crackers.org to nice.people.org 23
Następny przykład odrzuca i loguje cały ruch TCP z całej sieci crackers.org (klasa C) do hosta nice.people.org (na dowolny port)
# ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org
Natomiast jeśli nie chcesz, żeby użytkownicy nawiązywali sesje X'ów do twojej sieci wewnętrznej (podsieci klasy C), poniższe polecenie wykona odpowiednie filtrowanie:
# ipfw add deny tcp from any to my.org/28 6000 setup
By sprawdzić wpisy rozliczające ruch:
# ipfw -a list
lub w krótszej wersji:
# ipfw -a l
Możesz również sprawdzić o której dana reguła została ostatni raz trafiona:
# ipfw -at l
Notatka: Poniższe sugestie są dokładnie sugestiami. Wymagania dla praktycznie każdej ściany ogniowej są inne i nie możemy podać uniwersalnych rad jak zbudować ścianę ogniową dla twojej sieci.
Podczas pierwszego konfigurowania ściany ogniowej powinieneś używać logowania tam gdzie się tylko da by szybko identyfikować problemy i poprawiać je, bez zbytniego wysiłku. Wyjątkiem będzie sytuacja, gdy masz doskonałe sieciowe stanowisko testowe i logowanie na samej ścianie ogniowej nie będzie potrzebne. Nawet po zakończeniu pierwotnej konfiguracji, rekomendujemy logowanie dla pakietów zablokowanych ( ang. ``deny'' ) ponieważ umożliwia to wyśledzenie i zidentyfikowanie potencjalnych ataków.
Notatka: Jeśli zdecydujesz się na logowanie również pakietów przepuszczanych ( poleceniem accept ), prawdopodobnie twoja ściana ogniowa wygeneruje ogromne ilości logów dla ruchu przechodzącego przez ścianę ogniową - takiego jak FTP, HTTP itp. Na pewno spowolni to system, zwiększy również opóźnienia dla pakietów. Proces syslogd zacznie również zużywać dużo czasu procesora, ponieważ będzie musiał logować dodatkowe informacje na dysk - może to w efekcie spowodować zapełnienie partycji /var/log.
Powinieneś uaktywniać swoją ścianę ogniową ze skryptu /etc/rc.conf.local lub /etc/rc.conf. Strony podręcznikowe ich dotyczące wyjaśniają wszystkie opcje i wymieniają domyślne ustawienia. Jeśli nie używasz konfiguracji domyślnej, poleceniem ipfw list można zrzucić aktualny zestaw reguł do pliku, który następnie wskażesz jako parametr w pliku rc.conf. Rezygnując z usług skryptu /etc/rc.conf.local czy /etc/rc.conf upewnij się, że ściana ogniowa jest uaktywniana zanim jakikolwiek interfejs IP zostanie skonfigurowany i uaktywniony.
Kolejny problem, to zdecydowanie się co ściana ogniowa powinna faktycznie robić. Zależy to mocno od swobody dostępu do sieci zewnętrznej jaki chcesz umożliwić, oraz jakiego typu ruch chcesz wpuszczać do sieci wewnętrznej. Podstawowe reguły można sformuować następująco:
Zablokuj wszystkie przychodzące połaczenia do portów TCP poniżej 1024. Znajdują się tu wszystkie główne, najwrażliwsze usługi - takie jak finger, SMTP (poczta) czy telnet.
Zablokuj cały przychodzący ruch UDP. Jest tylko parę użytecznych usług pracujących w oparciu o UDP, a wszystkie są tak naprawdę zagrożeniem dla bezpieczeństwa ( np. Sun RPC czy NFS ). Ma to swoje wady, ponieważ zablokowanie ruchu przychodzącego UDP blokuje odpowiedzi na wychodzące pakiety UDP. Na pewno będzie to problem np. dla osób używających w sieci wewnętrznej usługi archie (prospero). Jeśli chcesz umożliwić dostęp do tej usługi, wpuszczaj pakiety przychodzące z portów 191 i 1525 na dowolny port UDP po Twojej stronie. Przykładem innej usługi jest ntp - pakiety tej usługi przychodzą z portu źródłowego 123.
Zablokuj ruch do portu 6000 z zewnątrz. Jest on używany do połączeń do serwerów X11 i może stanowić zagrożenie dla bezpieczeństwa ( w szczególności w sytuacjach, gdy użytkownicy mają zwyczaj wydawać polecenie xhost + na swoich stacjach roboczych ). X11 używa zwykle zakresu portów zaczynających się od numeru 6000, górny limit to liczba X serwerów uruchomionych na danej maszynie. W RFC 1700 (Przydzielone Numery Portów) określono ten limit na 6063.
Sprawdź jakich portów używają serwery wewnętrzne ( np. serwer SQL itp. ). Zwykle warto te porty również zablokować od strony zewnętrznej, ponieważ zlokalizowane są poza zakresem 1-1024 określonym powyżej.
Inna wersja listy zaleceń co do konfiguracji ściany ogniowej dostępna jest pod adresem CERT : http://www.cert.org/tech_tips/packet_filtering.html
Jak już wspomniano, są to jedynie wytyczne. Musisz sam zdecydować jakich chcesz używać reguł filtrowania na swojej ścianie ogniowej. Nie możemy zaakceptować jakiejkolwiek odpowiedzialności jeśli ktoś włamie się do twojej sieci, nawet jeśli zastosowałeś się do powyższych uwag.
Wiele osób ciekawych jest, jak dużo narzutu na system powoduje użycie IPFW. Odpowiedź zależy od konstrukcji zestawu reguł i prędkości procesora. Dla większości aplikacji pracujących w oparciu o Ethernet i małych zestawów reguł, odpowiedź brzmi: ``pomijalny''. Ci, którzy chcą usatysfakcjonować swoją ciekawość, powinni czytać dalej.
Poniższe testy wykonano na wersji 2.2.5-STABLE i komputerze klasy 486-66 ( o ile IPFW zmienił się trochę w późniejszych wydaniach, nadal pracuje z podobną prędkością ). IPFW zmodyfikowano tak, by mierzył czas spędzany w funkcji ip_fw_chk i wyświetlał rezultat co 1000 pakietów.
Przetestowano dwa zestawy reguł, po 1000 testów w każdej. Pierwszy zestaw zaprojektowano tak, by oddawał najgorszy możliwy scenariusz - powtarzał regułę:
# ipfw add deny tcp from any to any 55555
Jest to najgorszy przypadek, ponieważ IPFW musi sprawdzić większość swoich testów na pakiecie zanim zdecyduje o odrzuceniu pakietu ( ponieważ nie będzie pasował, ruch był kierowany do innego portu ). Po 999 iteracji takiego testu następna reguła brzmiała allow ip from any to any.
Drugi zestaw reguł stworzono tak, by bardzo szybko pomijał testy:
# ipfw add deny ip from 1.2.3.4 to 1.2.3.4
Niepasujący źródłowy adres IP powodował pominięcie reguły bardzo szybko. Tak jak poprzednio, tysięczna reguła brzmiała allow ip from any to any.
Narzut na przetwarzanie pojedyńczych pakietów wyniósł około 2.703 ms na pakiet, lub około 2.7 mikrosekund na regułę. Teoretyczna przepustowość pakietów wynosi z tymi regułami około 370 pakietów na sekundę. Zakładając Assuming 10 Mbitowy Ethernet i rozmiar pakietu w granicach ~1500 bajtów, moglibyśmy osiągnąć tylko 55.5% wysycenie pasma.
Dla drugiego przypadku, każdy pakiet przeglądany był przez około 1.172 ms, lub w przybliżeniu 1.2 mikrosekund dla reguły. Tutaj teoretyczny limit to około 853 pakietów na sekundę, co wysyciło by 1010 Mbitowe połączenie Ethernet.
Bardzo duża liczba reguł w teście i natura samego testu nie odzwierciedla prawdziwego życia - reguły zostały wygenerowane w celu zebrania informacji o opóźnieniach a nie w celu ochrony konkretnego systemu. Poniżej parę uwag, które warto wziąć pod uwagę budując wydajny zestaw reguł:
Umieść regułę z argumentem established ( ``nawiązane'' - przyp. tłum. ) na początku zestawu, by obsłużyć od razu większość ruchu TCP. Nie umieszczaj przed tą regułą żadnego wpisu zawierającego allow tcp.
Umieść reguły często pasujące do pakietów wcześniej w zestawie reguł, niż te które pasują rzadko ( oczywiście bez zmiany sensu całego zestawu ). Możesz sprawdzić, które reguły są często wywoływane wyświetlając statystyki filtra pakietów poleceniem ipfw -a l.
| Poprzedni | Spis treści | Następny |
| Kerberos | Początek rozdziału | OpenSSL |
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the
documentation
before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.