Czym jest firewall?
Zapora sieciowa (firewall) jest urządzeniem zaprojektowanym do zapobiegania niepowołanemu dostępowi do sieci. Urządzeniem tym zazwyczaj jest niezależny komputer lub inny sprzętowy element sieci. Zapora stanowi jedyny punkt wejściowy do sieci lokalnej - jej zadaniem jest kwalifikacja nadchodzących z zewnątrz zgłoszeń według zadanych reguł i ich przetworzenie, co w najprostszym ujęciu sprowadza się do akceptacji, bądź odrzucenia żądania połączenia z danym serwerem usług sieciowych.
W większości przypadków kwalifikacji żądania połączenia dokonuje się bazując na adresie źródłowym pakietu. Jeśli, przykładowo, nie chcemy udostępniać usług naszego serwera użytkownikom z danej domeny, wprowadzamy odpowiednią maskę do reguł sterujących zapory i odtąd próby połączenia z naszym serwerem dla danej grupy użytkowników zakończą się komunikatem "Connection Refused" (połączenia odmówiono) lub podobnym (możliwa jest również sytuacja, gdzie połączenie jest zrywane bez prezentacji żadnego komunikatu).
Inne zadania realizowane przez zapory sieciowe
Zapory sieciowe mogą przeprowadzać analizy nadchodzących pakietów różnych protokołów. W oparciu o taką analizę, zapora sieciowa może podjąć różne działania, zatem możemy zaprogramować firewall do przeprowadzania warunkowego przetwarzania pakietów. ("Jeśli zostanie napotkany pakiet spełniający warunek A, podejmij działanie B").
Takie warunkowe struktury nazywane są regułami. Na ogół, podczas "stawiania" zapory wyposażamy ją w zestaw reguł odzwierciedlający strukturę zależności służbowych w naszej organizacji. Na przykład, załóżmy, że w firmie jest dział sprzedaży i księgowości, a strategia przedsiębiorstwa wymaga, aby tylko dział sprzedaży miał dostęp do zasobów naszego serwera. Aby wymusić realizację tej polityki, wyposażamy nasz firewall w regułę nie przyjmującą zgłoszeń połączenia otrzymywanych z działu księgowości. W takim aspekcie zapory sieciowe są tym dla sieci, czym są przywileje użytkownika dla systemu operacyjnego. Windows NT pozwala na wskazanie użytkowników mających dostęp do danego pliku lub katalogu. Jest to kontrola dostępu na poziomie systemu operacyjnego. Podobnie zapory sieciowe pozwalają na zastosowanie kontroli dostępu do zasobów naszego serwera i stacji roboczych w sieci.
Monitorowanie dostępu jest jednakże tylko częścią tego, do czego można wykorzystać nowoczesne zapory sieciowe - większość komercyjnych firewalli pozwala na kontrolę zawartości pakietów. Można to wykorzystać do odfiltrowywania niepożądanych skryptów JavaScript, VBScript i ActveX oraz plików cookies. Co więcej, mamy możliwość zdefiniowania reguł dyskryminujących poszczególne połączenia na podstawie tzw. sygnatur ataku.Sygnatury ataków są wzorcami poleceń charakterystycznymi dla danego ataku. Przypuśćmy, że nasz intruz "telnetuje' się na port 80 i wydaje szereg istotnych z jego punktu widzenia komend. Znajšc taki proces, możemy "nauczyć" firewall rozpoznawać i blokować podobne ataki na podstawie wzorca zawartego w sygnaturze. Podobne efekty można również uzyskać analizując ruch na poziomie pakietu. Nektóre programy do zdalnego wykorzystywania luk systemowych generują charakterystyczne pakiety, które można wyodrębnić i podjąć odpowiednie działania.
Z czego składa się zapora sieciowa
Zapora sieciowa w swej istocie jest raczej koncepcją, a nie produktem. Celem istnienia zapór jest przyznanie, bądź odmowa przyznania połączenia danemu użytkownikowi do danej usługi sieciowej. W bardziej ogólnym sensie zapora sieciowa składa się z odpowiedniego oprogramowania i sprzętu. Oprogramowanie może być typu freeware, shareware lub komercyjne. Sprzęt może być jakimkolwiek urzšdzeniem, na którym pracuje dany program.
Typy zapór sieciowych
Wyróżniamy dwa podstawowe typy
zapór sieciowych:
Zapory pracujące na
poziomie sieci są zazwyczaj routerami z zawansowanymi możliwościami
filtrowania pakietów. Administrator korzystajšcy z takiej zapory ma
możliwość przyznania, bądź odmowy dostępu do swego serwem w oparciu o
kilka zmiennych. Są to między innymi:
Zapory sieciowe w postaci routerów są popularne ze względu na łatwość ich zastosowania (po prostu podłącza się firewall do sieci i zaopatruje w odpowiednie reguły). Co więcej większość współczesnych routerów ma możliwość translacji/konwersji protokołów (gdzie protokół IP z zewnątrz jest tłumaczony na inne protokoły stosowane w sieci lokalnej). Dodatkową zaletą zastosowania firewalla zbudowanego w oparciu o router jest fakt, że z racji swej specyfiki urządzenie.takie jest elementem zewnętrznym z punktu widzenia naszej sieci lokalnej. Tak więc jego podłączenie do sieci nie wymaga konieczności konfiguracji dziesiątek maszyn czy usług. I wreszcie, jeśli nasza sieć jest połšczona z Internetem łączem stałym, to router i tak jest jej niezbędnym elementem. Zatem stosując firewall w oparciu o router możemy upiec dwie pieczenie na jednym ogniu. Z drugiej strony zapory sieciowe oparte na routerach maja kilka wad. Jedną z nich jest fakt, że wiele routerów jest podatnych na ataki, polegające na fałszowaniu adresu nadawcy pakietu - spoofing (aczkolwiek producenci pracują nad rozwiązaniem tego problemu). Z praktycznego punktu widzenia, istotna jest również efektywnoąć (moc obliczeniowa) routera - jeśli zadamy bardzo szczegółowe kryteria filtrowania, to w przypadku dużego natężenia ruchu przychodzącego możemy się spodziewać spadku jego wydajności. Niektóre routery nie posiadają wystarczająco szczegółowych możliwości zapisu stanu pracy. Oznacza to, że możemy potrzebować zewnętrznego oprogramowania i sprzętu do celów monitorowania pracy routera.
Zapory sieciowe realizowane w oparciu o aplikacje bramy Innym rodzajem zapory sieciowej jest firewall wykorzystujący aplikacje pośredniczšce w standardowej komunikacji typu klient-serwer. Zapora taka zwana jest również bramą proxy, bądź bramą programową (application gateway). Żądanie połączenia z daną usługą sieciowš wysłane przez zdalnego użytkownika jest obsługiwane nie bezpośrednio przez odpowiedni serwer usług, lecz podawane do niego poprzez bramę proxy. Zatem, w odróżnieniu od firewalla - filtra pakietów, nadchodzące pakiety IP nie są po przetworzeniu przesyłane do sieci lokalnej, zamiast tego brama przeprowadza swego rodzaju translację pośrednicząc pomiędzy klientem a serwerem. Zaletą stosowania bramkowania usług jest fakt zapobiegania dostaniu się pakietów IP do naszej sieci (tunelowania pakietów). Wadą jest konieczność konfiguracji odpowiedniej bramy dla każdej usługi sieciowej, w tym FTP, Telnet, HTTP, e-mail itd. Dodatkowo użytkownicy muszą wykorzystywać programy klienckie pozwalające na stosowanie bramkowania usług (w przeciwnym wypadku, użytkownicy będą musieli nauczyć się "ręcznie" obsługiwać bramę (co może być czasochłonne, uciążliwe, bądź w ogóle niemożliwe, zależnie od stopnia skomplikowania procedur). Przykładowo - w przypadku bramkowania popularnej usługi Telnet nie jest wymagana obecność po stronie użytkownika klienta świadomego istnienia bramy proxy; w takiej sytuacji jednak wymusi to na użytkowniku konieczność połšczenia się (lecz nie zalogowania) z bramš - firewallem dla danej usługi - a nie bezpośrednio z serwerem Telneta. Zastosowanie klienta wspierającego procedury bramkowania uczyni bramę transparentną z punktu widzenia użytkownika. Zapora sieciowa służy jako wejście do systemu docelowego - przechwytuje żądania połączenia i podejmuje dalsze, uprzednio zdefiniowane, kroki, np. zapytanie o jednorazowe hasło. Zachowanie użytkownika pozostaje takie samo, pod warunkiem stosowania odpowiednio zmodyfikowanych i skonfigurowanych klientów i usług.
Konstrukcja zapory sieciowej
Przy "stawianiu"
zapory sieciowej istotne jest przeprowadzenie poniższych czynności:
Rozpoznanie topologii sieci oraz potrzeb w zakresie aplikacji i protokołów
To zagadnienie jest dużo trudniejsze niż mogłoby się wydawać, zależy ono od struktury i rozmiarów danej sieci. Jeśli administrujemy sieciš jednorodnš (co jednak zdarza się dość rzadko), zadanie jest proste - będziemy mieć do czynienia z jednym systemem operacyjnym i przypuszczalnie takim samym zestawem aplikacji obecnym na każdej ze stacji.
Większość sieci, to sieci heterogeniczne, co zmusza administratora do identyfikacji każdego systemu operacyjnego i wszystkich zestawów aplikacji używanych w sieci. To z kolei wymagać może konieczności korzystania z usług ekspertów w dziedzinie bezpieczeństwa poszczególnych aplikacji.
Analiza zależności służbowychTen krok może wymagać od administratora rozpoznania potrzeb i uzgodnienia działań z poszczególnymi działami firmy podłączonymi do sieci. Musimy uniknąć sytuacji, kiedy ze względu na fizyczną odległość między poszczególnymi segmentami sieci ruch wewnętrzny będzie się odbywał poprzez którąś z naszych bram programowych. Zatem przed dokonywaniem zmian w strukturze sieci należy dokładnie przeanalizować te zależności. Cały ten proces wymaga dużego taktu. Można spotkać się z użytkownikami lub menedżerami, którzy będą sprzeciwiać się zmianom (skoro od 10 lat sieć chodzi, to po co cokolwiek zmieniać?). Konieczna jest bliska współpraca z użytkownikami i uzasadnienie im konieczności przeprowadzenia zmian. Ostatnią rzeczą jaką byśmy sobie życzyli, to rzesza niezadowolonych lokalnych użytkowników - to od nich w przyszłości będzie zależeć bez pieczeństwo sieci, to nasi użytkownicy przestrzegając (lub nie) zasad korzystania z systemów będą mieli decydujący wpływ jej bezpieczeństwo. Jeśli staraliśmy się rzeczowo (i przystępnie) uzasadnić konieczność przedsięwzięcia odpowiednich środków - nie mamy się czego obawiać; jeśli zaś wprowadziliśmy drakońskie reguły korzystania z sieci bez słowa wyjaśnienia, możemy się spodziewać oporu materii ludzkiej na każdym możliwym kroku.
Zastosowanie i testowanie zapory sieciowejPo zakupie zapory
sieciowej powinniśmy przeprowadzić intensywne testy w dwóch fazach:
Pierwsza
faza może być przeprowadzona w dowolnym czasie - nawet gdy użytkownicy
danej sieci są nieobecni (weekend, godziny wieczornonocne, etc.).
Druga faza jest bardziej skomplikowana. Należy się spodziewać wielu problemów, a nawet przejściowego zaniku funkcjonalności sieci (trzeba być przygotowanym na reakcję zdenerwowanych użytkowników). Jest wyjątkowo mało prawdopodobne, że fazę tę przejdzie się gładko już za pierwszym razem - chyba, że sieć jest całkowicie jednorodna i mamy do czynienia z tym samym zestawem aplikacji na każdej z maszyn.
Czy zapory sieciowe sš niezawodne?Odpowiedź brzmi - nie. Wiele serwerów, na których zastosowano zapory sieciowe, zostało pokonanych przez krakerów. Wynika to nie tyle z właściwości zapory sieciowej jako takiej, a raczej z zawodności tzw. czynnika ludzkiego. Najczęstszą przyczynš wadliwości zabezpieczeń firewalla sš administratorskie błędy w jego implementacji. Nie znaczy to, że niektóre zapory sieciowe nie mają słabych punktów. Owszem mają - aczkolwiek w większości przypadków luki te nie mają zbyt wielkiego znaczenia dla bezpieczeństwa sieci.
Komercyjne zapory sieciowe
Poniżej zostanie przedstawiona lista zapór sieciowych dostępnych na rynku, wraz z ich krótką charakterystyką.
AltaVista Firewall 98Typ zapory sieciowej: | programowa - brama proxy |
Producent: | Digital Equipment Corp. |
Przeznaczona dla platform: | DEC UNIX, Windows NT |
AltaVista Firewall 98 zawiera bramy dla usług: FTP, Telnet, HTTP, Mail, News, SQL*Net, RealAudio i finger. Dla usług FTP i Telnet mamy możliwość wymuszenia stosowania jednorazowych haseł. Produkt ten pracuje zarówno na platformach sprzętowych opartych o procesory Intel, jak i Alpha.
BorderMenagerTyp zapory sieciowej: | programowa |
Producent: | Novell Inc. |
Przeznaczona dla platform: | Novell NetWare |
BorderManager jest programem przeznaczonym dla sieci Novell, ale ochrania również sieci pracujące w oparciu o systemy UNIX oraz NT. Produkt ten pozwala na centralizację zarządzania siecią, szczegółowe filtrowanie oraz szybką i dokonywaną w czasie rzeczywistym analizę ruchu w sieci. BorderManager pozwala także na tworzenie "minizapór sieciowych", zabezpieczających chronioną sieć także przed atakami z sieci lokalnych.
CSM Proxy/Enterprise EditionTyp zapory sieciowej: | programowa - brama proxy |
Producent: | CSM-USA Inc. |
Przeznaczona dla platform: | Linux, Solaris i Windows NT |
CSM Proxy jest kompleksowym rozwiązaniem służącym serwerom sieciowym do filtrowania skryptów ActiveX i Java, plików cookies, poczty konferencyjnej i prywatnej. CSM Proxy wspierane jest przez Windows 95.
Firewall na przykładzie ipchains
Wszystkie informacje krążące w sieci przyjmują formę pakietów. Pakiet najogólniej dzieli się na nagłówek i ciało. Ciało zawiera informacje zrozumiałe dla aplikacji przeznaczonej do otrzymania danego pakietu. Z informacji zawartych w nagłówku interesujące dla nas, w aspekcie tego tematu, są informacje o źródle i miejscu docelowym pakietu. Możemy przyjąć, że informacje te dostępne są dla nas w formie ipsrc:portsrc oraz ipdest:portdest gdzie:
ipsrc - adres IP nadawcy pakietu
portsrc - port nadawcy pakietu
ipdest - adres IP odbiorcy pakietu
portdest - port odbiorcy pakietu
Filtr pakietów to oprogramowanie, które na podstawie informacji zawartych w nagłówku pakietu decyduje o tym co się z nim stanie. Wynikiem działania takiego oprogramowania może być:
zabronienie otrzymania pakietu: pakiet nie dostaje się do odbiorcy, do którego został skierowany
akceptacja otrzymania pakietu: pakiet dostaje się do odbiorcy, do którego został skierowany
odrzucenie pakietu: pakiet nie dostaje się do odbiorcy, do którego został skierowany a strona wysyłająca zostaje o tym fakcie poinformowana
Aktywowanie filtrowania
Aby móc kontrolować pakiety "przepływające" przez nasz interfejs sieciowy, musimy sprawdzić czy nasze jądro wspiera filtrowanie pakietów. Jeśli w katalogu /proc/net istnieje plik ip_fwchains oznacza to że tak. Jeśli natomiast plik ten nie istnieje musimy ustawić odpowiednie parametry jądra. Dla jądra w wersji 2.1 i 2.2 są to: CONFIG_FIREWALL oraz CONFIG_IP_FIREWALL. Obydwa parametry ustawiamy na "y".
Ipchains
Ipchains jest narzędziem, które umożliwia nam min. kontrolowanie parametrów filtrowania pakietów. Ustawia i kasuje reguły filtrowania pakietów, które to reguły używane są przez jądro systemu. Program ipchains jest nowszym odpowiednikiem programu ipfwadm. Zmiany dokonane przez program ipchains zostają utracone w momencie restartowania systemu, dlatego zaleca się aby raz utworzoną konfigurację zapisać jako jeden ze skryptów startowych systemu. Zakładając, że reguły filtrowania mamy zapisane w pliku /etc/ipchains.rules możemy napisać następujący skrypt startowy (/etc/init.d/packetfilter):
#! /bin/sh
# Skrypt do kontrolowania filtrowania pakietów.
# Jeśli nie zdefiniowano reguł, nie rób nic.
[ -f /etc/ipchains.rules ] || exit 0
case "$1" in
start)
echo -n "Włączam fitrowanie pakietów:"
/sbin/ipchains-restore < /etc/ipchains.rules || exit 1
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "."
;;
stop)
echo -n "Wyłączam filtrowanie pakietów:"
echo 0 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -F
/sbin/ipchains -X
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward ACCEPT
echo "."
;;
*)
echo "Użycie: /etc/init.d/packetfilter {start|stop}"
exit 1
;;
esac
exit 0
Filtrowanie
W trakcie filtrowania pakietów jądro systemu posługuje się jedną z trzech list reguł zwanych "firewall chains". Nazwy tych list to: input, output oraz forward. Kiedy pakiet przychodzi z zewnątrz (np. poprzez interfejs Ethernet) jądro używa reguł zapisanych w liście input aby zdecydować o tym co stanie się z pakietem. Jeśli pakiet "przeżył" ten krok, jądro sprawdza jego adres docelowy. Jeśli adresem docelowym jest adres innej maszyny, wtedy pakiet jest testowany pod kątem reguł zawartych w liście forward. Lista output służy do testowania pakietów tuż przed opuszczeniem systemu filtrującego (także tych, które były testowane przy pomocy reguł zawartych w liście forward). Oprócz tych trzech podstawowych list istnieje możliwość definiowania własnych.
Reguły składające się na listę przyjmują postać: "jeśli nagłówek pakietu wygląda tak, to zrób z nim to". Jeśli jakaś reguła nie odnosi się do testowanego pakietu, następna z kolei zostaje zastosowana. Jeśli żadna z reguł nie została zastosowana do pakietu, wtedy jest on traktowany zgodnie z generalną regułą bezpieczeństwa systemu. Generalna reguła bezpieczeństwa systemu może przyjmować jedną z postaci:
"wszystko co nie jest zabronione jest dozwolone"
"wszystko co nie jest dozwolone jest zabronione"
Poniższy diagram prezentuje drogę jaką przebywa pakiet przechodzący przez system z filtracją pakietów:
Opis poszczególnych stanów na powyższym diagramie:
checksum: Test sprawdzający czy otrzymany pakiet nie jest uszkodzony. Jeśli tak, jego dalsze przejście jest zabronione.
sanity: Ostatni test pakietu przed "wpuszczeniem" go do "input chain". Odrzucane są wszystkie pakiety, które mogły by "zmylić" reguły sprawdzające w następnych krokach filtracji.
input chain: Jest to pierwsza lista reguł, pod kątem których pakiet jest testowany. Jeśli wynik jest inny niż zabronienie lub odrzucenie, pakiet przechodzi dalej.
demasquerade: Stan ten zachodzi jeśli rozpatrywany pakiet jest odpowiedzią na wcześniej wysłany pakiet (request -> response) i jeśli w naszej sieci używamy "IP Masquerade".
routing decision: W tym stanie sprawdzane jest pole określające odbiorcę. W zależności czy jest to IP naszej maszyny czy innej, system podejmuje odpowiednie kroki (zobacz diagram).
local process: Proces uruchomiony na naszej maszynie, którego jednym z działań jest wymiana informacji w sieci (odbiorca i nadawca pakietów).
lo interface: Kiedy pakiety wysyłane przez lokalny proces przeznaczone są również dla procesu lokalnego w polach nagłówka odpowiadających za adres źródła i adres docelowy mają wpisany interfejs lo (loopback interface).
forward chain: Lista reguł, pod kątem której testuje się każdy pakiet przeznaczony dla maszyny innej niż nasza.
output chain: Lista reguł, pod kątem której testuje się każdy pakiet mający opuścić system.
Opis podstawowych opcji programu ipchains
Opcje dotyczące operacji na całych listach:
tworzenie nowej listy (-N)
kasowanie pustej listy (-X)
zmienienie generalnej reguły bezpieczeństwa dla wbudowanej listy (-P)
wypisanie wszystkich reguł w liście (-L)
wyrzucenie wszystkich reguł z listy (-F)
wyzerowania liczników pakietów i bajtów we wszystkich regułach (-Z)
Opcje dotyczące poszczególnych reguł w listach:
dodanie nowej reguły do końca listy (-A)
dodanie nowej reguły na określonej pozycji w liście (-I)
zamienienie reguły na określonej pozycji w liście (-R)
skasowanie reguły na określonej pozycji w liście (-D)
Przykłady użycia programu ipchains oraz dodatkowe parametry
Zabronienie odpowiadania na pakiety programu ping wysłanych z interfejsu lo (127.0.0.1):
ipchains -A input -s 127.0.0.1 -p icmp -j DENY
gdzie:
-s: adres źródła
-p: protokół (np. icmp, tcp, udp)
-j: ACCEPT|DENY|REJECT|MASQ|REDIRECT|RETURN
Usuwanie powyższej reguły z listy input:
ipchains -D input 1
lub
ipchains -D input -s 127.0.0.1 -p icmp -j DENY
Zabronienie odpowiadania na pakiety programu ping wysłanych przez jakikolwiek host:
ipchains -A input -s 0/0 -p icmp -j DENY
Adres sieciowy w opcjach -s (source) oraz -d (destination) może być podany na cztery sposoby:
przez nazwę np. localhost lub ernie.icslab.agh.edu.pl
przez IP np. 127.0.0.1 lub 206.32.128.5
przez zakres adresów IP:
199.95.207.0/32 - wszystkie od 199.95.207.0 do 199.95.207.255
199.95.207.0/255.255.255.255 - tak samo
Dozwolone jest także użycie znaku "!" (NOT) przed adresem hosta. Oznacza to, że chcemy aby rozpatrywane były wszystkie adresy nie należące do podanych np.
ipchains -A input -s ! localhost -p icmp -j DENY
Zabroń odpowiadania na pakiety ICMP wysłane przez wszystkie hosty oprócz localhost.
Jeśli wartością argumentu -p jest TCP lub UDP, mamy możliwość oprócz adresu wyspecyfikować także interesujące nas porty. Jeśli chcemy, żeby był to zakres portów używamy znaku ':'. I tak oznaczenie 6000:6010 oznacza, że odnosimy się do 11 portów od 6000 do 6010 włącznie. Jeśli pominiemy dolny zakres program domyślnie użyje 0, jeśli natomiast pominiemy górny domyślną wartością będzie 65535. Tak więc aby wyspecyfikować, że chodzi nam o wszystkie połączenia TCP przychodzące z portów poniżej 1024 użyjemy następujących argumentów: "-p TCP -s 0.0.0.0/0 :1023". Numer portu możemy także podać poprzez nazwę np. www. Dozwolone jest także używanie znaku '!' oznaczającego negację. Należy jednak uważać na miejsce, w którym znak ten występuje. Następujące dwa wpisy wyjaśniają tę różnicę:
-p TCP -d ! 192.168.1.1 www
oraz
-p TCP -d 192.168.1.1 ! www
Wpis pierwszy oznacza, że chodzi nam o port 81 na każdej maszynie oprócz 192.168.1.1, natomiast wpis drugi oznacza, że chodzi nam o wszystkie porty na maszynie 192.168.1.1 oprócz portu 81.
Za pomocą opcji "-i" możemy wyspecyfikować, do którego interfejsu sieciowego odwołuje się dana komenda (oczywiście jeśli posiadamy więcej niż jeden interfejs sieciowy). Aby sprawdzić ile interfejsów sieciowych posiada system używamy komendy ifconfig.
Aby wymazać wszystkie reguły z danej listy używamy opcji -F:
ipchains -F input
Aby wylistować wszystkie reguły z danej listy używamy opcji -L:
ipchains -L input
Bardzo użyteczną opcją jest opcja -C. Za jej pomocą możemy sprawdzić co stanie się z danym pakietem np. wchodzącym skierowanym na konkretny adres i port.
ipchains -C input -p TCP -s 192.168.1.1 6000 -d 192.168.1.2 www
odpowiedź programu może wyglądać np. tak:
packet accepted
Obsługa fragmentów pakietów
Czasami w sieci dochodzi do sytuacji kiedy jeden pakiet musi zostać podzielony na mniejsze fragmenty (ze względu np. na przepustowość). Kiedy sytuacja taka nastąpi strona odbierająca zbiera te fragmenty aby ponownie sformować z nich cały pakiet.
Problem z fragmentami polega na tym, że ważne dla nas informacje będą zawarte tylko w pierwszym fragmencie (odpowiadającym nagłówkowi). Jednym z wyjść jest skompilowanie jądra systemu z włączoną opcją "IP: always defragment". Oznacza to, że system zanim podejmie jakiekolwiek decyzje odnośnie pakietu odtworzy go w całości z nadchodzących fragmentów. Drugim rozwiązaniem jest odpowiednie sformułowanie reguł tak aby odnosiły się one także do fragmentów. Ważne jest, aby pamiętać iż w normalnym przypadku tylko pierwszy fragment (zawierający informację z nagłówka) zostanie potraktowany jak pakiet, reszta nie. Aby dana reguła traktowała tak samo wszystkie fragmenty składające się na pakiet należy przy jej specyfikowaniu użyć opcji '-f'.
Odnośniki do stron o bezpieczeństwie systemów
http://www.openna.com
http://www.ssh.org
http://www.openssh.com
http://www.jtz.org.pl
http://www.openwall.com/linux/