IPCHAINS w Linuksie
Rusty Russell v1.0.8, 4 Lipiec 2000, 14:20:53 EST,
oryginał tego dokumentu znajduje się pod adresem:
http://netfilter.samba.org/ipchains/HOWTO.html
Wersja polska: Łukasz
Bromirski v1.0, 17 maj 2001, 01:57:32 GMT+1
oryginał tłumaczenia znajduje się pod adresem:
http://www.prosys.com.pl/~szopen/tlumaczenia/ipchains.html
Dokument ten to IPCHAINS-HOWTO (PL); W sekcji 1.4 znajdziesz adresy spod których możesz ściągnąć najświeższą
wersję. Powinieneś przeczytać również dokument NET-3-HOWTO. Dodatkowo, dokumenty
IP-Masquerading HOWTO, PPP-HOWTO, Ethernet-HOWTO i Firewall HOWTO będą również
ciekawą lekturą (a potem, dokument FAQ listy alt.fan.bigfoot).
Jeśli filtrowanie pakietów jest Ci już znane,
przeczytaj sekcję 1.2 i 1.3 a potem przejrzyj
sekcję 4.
ipchains to przepisany od nowa kod ściany ogniowej
dla IPv4 Linuksa (który jest w głównej mierze ukradziony z BSD) oraz przepisany od nowa
ipfwadm, który z kolei jest przepisanym ipfw z BSD (jak podejrzewam).Od wersji kernela
2.1.102, filtrowanie pakietów IP wymaga zarządzania.
Stary kod ściany ogniowej Linuksa nie zajmuje się
fragmentami, ma 32-bitowe liczniki (przynajmniej na platformie Intel), nie pozwala na
specyfikację protokołów innych niż TCP, UDP i ICMP, nie może wykonywać dużych zmian
na poziomie "atomów", nie można w nim podawać reguł z inwersją, ma trochę
zawiłości i może być trudny w zarządzaniu (co czyni go podatnym na błędy
użytkownika).
Aktualny kod znajduje się już w standardowej
paczce kernela od wersji 2.1.102. Dla serii kerneli 2.0, będziesz musiał ściągnąć
patch do kernela ze stron WWW. Jeśli Twój kernel 2.0 jest nowszy niż dostarczany patch,
mimo wszystko powinieneś go zastosować - te kernele są raczej stabilne (tzn. patch do
kernela 2.0.34 działa w porządku z kernelem 2.0.35). Ponieważ patch do kerneli 2.0 jest
niekompatybilny z ipportfw i patchami do ipautofw, nie zalecam używania ich dopóki
naprawdę nie potrzebujesz funkcjonalności którą oferuje ipchains.
Oficjalna strona znajduje się pod trzema adresami:
http://netfilter.filewatcher.org/ipchains
(dzięki Penguin Computing)
http://www.samba.org/netfilter/ipchains
(dzięki zespołowi SAMBA)
http://netfilter.kernelnotes.org/ipchains
(dzięki Jimowi Pickowi)
Jest również lista e-mail'owa dla reportów o
błędach, dla dyskusji, rozwijania programu i używania go. Można do niej dołączyć
wysyłając wiadomość zawierającą słowo "subscribe ipchains-list"
pod adres subscribe na serwerze east.balius.com. Poczta do listy
powinna być adresowana na "ipchains-list" na serwerze east.balius.com.
Cały ruch przechodzący przez sieć jest
przesyłany w formie pakietów. Na przykład, ściągnięcie tego pliku (powiedzmy że ma
wielkość 50kB) może spowodować otrzymanie około 36 pakietów o długości 1460
bajtów każdy (te liczby dobrałem raczej z głowy).
Początek każdego pakietu mówi gdzie podróżuje,
skąd przybył, opisuje typ i inne detale administracyjne. Ten początek każdego pakietu
nazywamy nagłówkiem [header - przyp. tłum.]. Reszta pakietu, zawierająca
faktyczne dane które są transmitowane, jest zwykle nazywana ciałem pakietu.
Niektóre protokoły, takie jak TCP, których używa
się do obsługi ruchu w sieci, obsługi poczty i zdalnego logowania, używają koncepcji
"połączenia" - zanim wysłane zostaną jakiekolwiek pakiety danych, wymieniane
są inne pakiety (ze specjalnymi nagłówkami), konfigurujące połączenie. Brzmi to
mniej więcej tak: "Chciałbym się połączyć", "OK",
"Dzięki". Dopiero wtedy zaczyna się wymiana normalnych pakietów.
Filtr pakietów to oprogramowanie które sprawdza
nagłówki pakietów w trakcie jak przez niego przechodzą i decyduje o ich losie. Może
zdecydować że anuluje pakiet ( tj. pominie pakiet jakby nigdy go nie otrzymał),
zaakceptuje go ( tj. pozwoli mu przejść dalej ) lub odrzuci ( podobnie jak anulowanie,
ale zawiadomi źródło pakietu że został on odrzucony ).
Pod Linuksem, filtrowanie pakietów jest wbudowane w
kernel łącznie z paroma jeszcze trochę innymi sprytnymi rzeczami które można zrobić
z pakietami, ale generalnie zajęcie oglądania nagłówków i decydowania o ich losie
jest w nim również.
Kontrola. Bezpieczeństwo. Czujność.
Kontrola:
Kiedy używasz Linuksa by połaczyć Twoją wewnętrzną sieć z inną
siecią (powiedzmy z Internetem) masz okazję wpuścić trochę ruchu różnego typu a
część odrzucić. Na przykład, nagłówek pakietu posiada adres docelowy pakietu, więc
możesz odrzucać pakiety które podróżują do określonych części sieci zewnętrznej.
Innym przykładem może być to: używam Netscape do oglądania archiwów Dilbert'a. Jest
tam masa reklam pochodzących z adresu doubleclick.net, więc Netscape traci czas by je
ładować. Pouczenie filtra pakietów by nie wpuszczał pakietów podróżujących do i z
tego adresu rozwiązuje ten problem (jednakże jest parę innych sposobów by zrobić to
lepiej).
Bezpieczeństwo:
Kiedy Twój Linuks jest jedynym komputerem pomiędzy chaosem Internetu
i Twoją ładną, uporządkowaną siecią, miło jest wiedzieć że możesz obłożyć
restrykcjami to co nadchodzi do Twych drzwi. Na przykład, możesz pozwolić by wszystko
wychodziło z Twojej sieci, ale możesz być zaniepokojony znanym atakiem "Ping of
Death" przeprowadzanym przez rozmaitych złośliwych ludzi. Innym przykładem może
być Twoje życzenie, by nie zezwalać na telnetowanie się na Twój komputer, mimo że
wszystkie konta mają hasła; prawdopodobnie chcesz być (jak większość ludzi) raczej
obserwatorem w Internecie a nie serwerem - po prostu nie dawać się nikomu do Ciebie
dołączać, poprzez filtrowanie nadchodzących pakietów służących do ustanawiania
połączeń.
Czujność:
Czasami źle skonfigurowana maszyna w sieci lokalnej zadecyduje o
skierowaniu paru pakietów do sieci zewnętrznej. Miło jest móc poinstruować filtr
pakietów by dał Ci znać o takich anormalnych zachowaniach; może będziesz chciał coś
z tym zrobić, albo jesteś po prostu ciekawy takich przypadków.
Potrzebujesz kernela który ma nowy kod ipchains
ściany ogniowej zawarty w sobie. Możesz to sprawdzić zaglądając do pliku "/proc/net/ip_fwchains".
Jeśli w ogóle istnieje, masz taki kernel.
Jeśli nie, to potrzebujesz kernela który spełnia
ten warunek. Po pierwsze, ściągnij źródła kernela którego potrzebujesz. Jeśli masz
kernel w wersji 2.1.102 lub wyższej, nie będziesz potrzebował patcha (jest już w
źródłach). W innym przypadku musisz zastosować patch dostępny spod adresu WWW
podanego wcześniej i ustawić konfigurację jak to pokazano niżej. Jeśli nie wiesz jak
to zrobić nie panikuj - przeczytaj Kernel-HOWTO.
Poniżej znajdują się opcje konfiguracji których
będziesz potrzebował by ustawić kernel w wersji 2.0.x:
CONFIG_EXPERIMENTAL=y
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_CHAINS=y
Dla kerneli w wersjach 2.1.x i 2.2.x musisz ustawić
następujące zmienne w konfiguracji kernel'a:
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
Narzędzie ipchains rozmawia z kernelem i mówi mu
jak filtrować pakiety. Dopóki nie jesteś programistą, lub nadzwyczaj ciekawski, tak
będziesz kontrolował filtrowanie pakietów.
Narzędzie ipchains dodaje i usuwa reguły z sekcji
filtrującej pakiety kernela. To oznacza, że cokolwiek byś nie ustawił, zostanie
stracone po restarcie; zajrzyj do sekcji "Sprawianie by reguły pozostawały na
stałe" by dowiedzieć się jak upewnić się że reguły zostaną odzyskane po
następnym uruchomieniu Linuksa.
ipchains zastępuje ipfwadm, który był używany ze
starym kodem ściany ogniowej IP. Dostępny jest zestaw użytecznych skryptów z serwera
http:
http://netfilter.filewatcher.org/ipchains/ipchains-scripts-1.1.2.tar.gz
Pakiet zawiera skrypt shellowy nazwany
ipfwadm-wrapper który pozwala Ci na filtrowanie pakietów w sposób podobny jak to
robiłeś w starych wersjach kernela. Prawdopodobnie nie powinieneś jednak używać tego
skryptu, chyba że chcesz naprawdę szybkiego sposobu upgradeu systemu który do tej pory
używał ipfwadm (jest wolniejszy, nie sprawdza argumentów itp.). Jeśli tak zrobisz, nie
musisz już praktycznie czytać tego HOWTO.
Twoje aktualne ustawienia ściany ogniowej
zachowywane są w kernelu, więc zostaną stracone w przypadku resetu maszyny.
Rekomenduję użycie skryptów "ipchains-save" i "ipchains-restore"
by zachowywać reguły. By ich użyć, ustaw reguły a potem wykonaj (jako root):
# ipchains-save > /etc/ipchains.rules
Utwórz skrypt taki jak ten:
#! /bin/sh
# Skrypt kontroli filtrowania pakietów
# Jeśli nie ma reguł, nic nie rób
[ -f /etc/ipchains.rules ] || exit 0
case "$1" in
start)
echo -n "Włączanie filtrowania
pakietów:"
/sbin/ipchains-restore
echo 1 >/proc/sys/net/ipv4/ip_forward
echo "."
;;
stop)
echo -n "Wyłączanie filtrowania
pakietów:"
echo 0 >/proc/sys/net/ipv4/ip_forward
/sbin/ipchains -X
/sbin/ipchains -F
/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
I upewnij się że zostanie on uruchomiony we wczesnej fazie procedury
startowej. W moim przypadku (Debian 2.1) wykonałem symboliczny link "S39packetfilter"
w katalogu "/etc/rcS.d" (który zostanie uruchomiony przez plikiem
"S40network").
Ten dokument HOWTO poświęcono filtrowaniu
pakietów. To znaczy decydowaniu, czy pakiet powinien móc przejść przez nasz komputer
czy nie. Jednakże Linuks, będąc tak naprawdę placem zabaw hackerów, jest na tyle
narażony że prawdopodobnie chciałbyś wiedzieć trochę więcej o filtrowaniu.
Problemem jest, że to samo narzędzie (ipchains)
używane jest do kontrolowania i maskarady i transparentnego proxy, mimo że są to
różne techniki filtrowania pakietów (aktualna implementacja Linuksa zamazuje różnice
między nimi w nienaturalny sposób, sprawiając wrażenie że obie techniki są
naturalnie blisko ze sobą związane).
Maskarada i stosowanie proxy opisane są w osobnych
HOWTO, a auto forwarding (automatyczne przekazywanie) i port forwarding (przekazywanie
portów) są kontrolowane przez osobne narzędzia, ale ponieważ tak wielu ludzi ciągle
pyta mnie o nie, włączę zestaw typowych scenariuszy i pokażę, które z narzędzi
powinno zostać użyte. Zagadnienia bezpieczeństwa każdej konfiguracji nie będą
przedmiotem dyskusji.
Poniższy przykład zakłada, że Twój zewnętrzny
interfejs nazywa się "ppp0". Sprawdź to poleceniem ifconfig
i ewentualnie zmień użyty niżej interfejs:
# ipchains -P forward DENY
# ipchains -A forward -i ppp0 -j MASQ
# echo 1 > /proc/sys/net/ipv4/ip_forward
Można kupić ścianę ogniową prosto z półki.
Doskonały jest WatchGuard FireBox. Jest taki dobry, ponieważ go lubię, jest bezpieczny,
oparty na Linuksie i ponieważ funduje również utrzymanie ipchains jak również nowego
kodu do ściany ogniowej (przeznaczonego do kerneli wersji 2.3.x i 2.4). W skrócie,
WatchGuard płaci mi za jedzenie w czasie gdy pracuje dla was. Więc weźcie pod uwagę
ich sprzęt.
http://www.watchguard.com
Utrzymujesz serwer littlecorp.com. Masz
sieć wewnętrzną i pojedyńczą linię (PPP) do Internetu (firewall.littlecorp.com
który ma adres 1.2.3.4). Używasz Ethernetu w swojej sieci lokalnej a Twoja
osobista maszyna nazywa się "myhost".
Ta sekcja pokaże różne konfiguracje które są
dosyć powszechne. Czytaj uważnie, ponieważ każda z nich jest czasami tylko
subtelnie różna od pozostałych.
W tym scenariuszu, pakiety z sieci prywatnej nigdy
nie podróżują do Internetu i vice versa. Adres IP sieci prywatnej powinien być
przydzielony z jednej z trzech puli adresów zdefiniowanych w RFC1597 (10.*.*.*,
172.16.*.* lub 192.168.*.*).
Jedynym sposobem w jaki w ogóle można się
połączyć do Internetu jest dołączenie się do ściany ogniowej, która jest jedyną
maszyną podłączoną do obu sieci naraz. Uruchamiasz program (na ścianie ogniowej)
nazywany proxy by to zrobić (są proxy do FTP, usług WWW, telnetu, RealAudio, newsów i
innych usług). Zajrzyj po więcej informacji do Firewall HOWTO.
Każda usługa z której chcesz korzystać w
Internecie, musi być uruchomiona na ścianie ogniowej (ale spójrz na "Ograniczone
wewnętrzne usługi" poniżej).
Przykład: Umożliwienie dostępu do stron WWW z sieci prywatnej do
Internetu:
Sieć prywatna ma przydzielone adresy 192.168.1.*,
komputer 'myhost' ma adres 192.168.1.100 a interfejs Ethernetowy
ściany ogniowej ma adres 192.168.1.1.
Proxy WWW (np. "squid") jest zainstalowany i skonfigurowany
na ścianie ogniowej, pracuje na porcie 8080.
Netscape w sieci prywatnej jest skonfigurowany i używa portu 8080
na ścianie ogniowej jako proxy.
DNS nie musi być skonfigurowany w sieci prywatnej.
DNS musi być skonfigurowany na ścianie ogniowej.
Nie musi być skonfigurowana domyślna bramka (gateway) w sieci
prywatnej.
Netscape na maszynie 'myhost' odwołuje się do strony http://slashdot.org
Netscape łączy się ze ścianą ogniową z portem 8080,
używając portu 1050 na własnym komputerze 'myhost'. Prosi o
stronę http://slashdot.org
Proxy sprawdza nazwę 'slashdot.org' i adres IP 207.218.152.131.
Otwiera połączenie do tego adresu IP (używając portu 1024 na interfejsie
zewnętrznym ściany ogniowej), i prosi serwer WWW (na porcie 80) o
określoną stronę.
Gdy otrzymuje stronę, kopiuje te dane do połączenia z Netscape.
Netscape (na komputerze 'myhost') rysuje stronę.
Na przykład z punktu widzenia slashdot.org,
połączenie wykonuje maszyna 1.2.3.4 (interfejs PPP ściany ogniowej) z
portu 1025, pod adres 207.218.152.131 (slashdot.org)
na port 80. Z punktu widzenia maszyny 'myhost', połączenie
wykonuje 192.168.1.100 (myhost) z portu 1025,
adresem docelowym jest 192.168.1.1 (interfejs Ethernetowy ściany ogniowej)
port 8080.
W tym scenariuszu, pakiety z sieci prywatnej nigdy
nie podróżują do Internetu i vice versa. Adres IP sieci prywatnej powinien być
przydzielony z jednej z trzech puli adresów zdefiniowanych w RFC1597 (10.*.*.*,
172.16.*.* lub 192.168.*.*).
Jedynym sposobem w jaki w ogóle można się
połączyć do Internetu jest dołączenie się do ściany ogniowej, która jest jedyną
maszyną podłączoną do obu sieci naraz. Uruchamiasz program (na ścianie ogniowej)
nazywany transparentnym proxy by to zrobić; kernel wysyła wychodzące pakiety do
transparentnego proxy zamiast wysyłać je po prostu do drugiej sieci (tzn. pomija
routing).
Transparentne proxy oznacza, że klienci nie muszą
w ogóle wiedzieć że działa jakieś proxy.
Każda usługa z której chcesz korzystać w
Internecie, musi być uruchomiona na ścianie ogniowej (ale spójrz na "Ograniczone
wewnętrzne usługi" poniżej).
Przykład: Umożliwienie dostępu do stron WWW z sieci prywatnej do
Internetu:
Sieć prywatna ma przydzielone adresy 192.168.1.*,
komputer "myhost" ma adres 192.168.1.100 a interfejs Ethernetowy
ściany ogniowej ma adres 192.168.1.1.
Transparentne proxy WWW (jak podejrzewam są patche dla squida by
pracował w tym trybie, możesz również spróbować "transproxy") jest
zainstalowany i skonfigurowany i używa portu 8080 na ścianie ogniowej.
Kernel ma zdefiniowane, by przekierowywać połączenia na port 80 do
proxy, używając ipchains.
Netscape w sieci prywatnej jest skonfgurowane do połączeń
bezpośrednich.
DNS musi być skonfigurowany w sieci prywatnej (tzn. musisz
uruchomić serwer DNS jako proxy na ścianie ogniowej).
Domyślna bramka musi być skonfigurowana dla sieci prywatnej, by
wysyłać pakiety do ściany ogniowej.
Netscape na maszynie "myhost" odwołuje się do strony http://slashdot.org
Netscape szuka nazwy slashdot.org i dostaje adres 207.218.152.131.
Otwiera połączenie do tego adresu IP przez port 1050, i prosi serwer WWW (na porcie 80)
o określoną stronę.
W momencie, gdy pakiety z komputera myhost (port 1050)
do slashdot.org (port 80) przechodzą przez ścianę ogniową, są
przekierowywane do transparentnego proxy oczekującej na porcie 8080 ściany ogniowej.
Transparentne proxy otwiera połaczenie (używając własnego portu 1025) do 207.218.152.131
na port 80 (który jest oryginalnym adresem, na który pakiety miały dojść).
Gdy proxy otrzymuje dane ze swojego połączenia z serwerem WWW,
kopiuje dane do połączenia z Netscape.
Netscape rysuje stronę.
Z punktu widzenia slashdot.org,
połączenie nadchodzi z 1.2.3.4 (interfejs PPP ściany ogniowej) i portu
1025 do 207.218.152.131 (slashdot.org) port 80. Z punktu widzenia komputera
"myhost" połączenie wykonywane jest z adresu 192.168.1.100
(myhost) i portu 1050 do adresu 207.218.152.131 (slashdot.org) i na port 80,
ale tak naprawdę rozmawia on przez transparentną proxy.
W tym scenariuszu, pakiety z sieci prywatnej nigdy
nie podróżują do Internetu i vice versa bez specjalnego potraktowania. Adres IP sieci
prywatnej powinien być przydzielony z jednej z trzech puli adresów zdefiniowanych w
RFC1597 (10.*.*.*, 172.16.*.* lub 192.168.*.*).
Zamiast używać proxy, używamy specjalnej
właściwości kernela nazywanej masquerading (maskarada). Maskarada przepisuje pakiety
kiedy przechodzą przez ścianę ogniową więc wydają się zawsze pochodzić właśnie z
niej. Następnie przepisuje od nowa również odpowiedzi, więc wyglądają tak jakby
nadchodziły od originalnego adresata.
Maskarada ma osobne moduły które obsługują "udziwnione"
protokoły, takie jak FTP, RealAudio, Quake itp. Dla bardzo trudnych do obsłużenia
protokołów, możliwe jest włączenie "auto forwardingu" który może
obsłużyć część z nich przez automatyczne ustawienie przekazywania (forwardingu) dla
określonych zestawów portów: szukaj ipportfw (w kernelach serii 2.0.x) lub ipmasqadm (w
kernelach serii 2.1.x).
Każda usługa z której chcesz korzystać w Internecie, musi być
uruchomiona na ścianie ogniowej (ale spójrz na "Ograniczone wewnętrzne
usługi" poniżej).
Przykład: Umożliwienie dostępu do stron WWW z sieci prywatnej do
Internetu:
Sieć prywatna ma przydzielone adresy 192.168.1.*,
komputer "myhost" ma adres 192.168.1.100 a interfejs
Ethernetowy ściany ogniowej ma adres 192.168.1.1.
Ściana ogniowa ma skonfigurowaną maskaradę dla dowolnych pakietów
które wychodzą z sieci prywatnej i podróżują w kierunku portu 80 hostów
Internetowych..
Netscape w sieci prywatnej jest skonfgurowane do połączeń
bezpośrednich.
DNS musi być skonfigurowany w sieci prywatnej.
Domyślna bramka musi być skonfigurowana dla sieci prywatnej i
ustawiona na ścianę ogniową.
Netscape na maszynie "myhost" odwołuje się do
strony http://slashdot.org
Netscape szuka nazwy slashdot.org i dostaje adres 207.218.152.131.
Otwiera połączenie do tego adresu IP przez port 1050, i prosi serwer WWW (na porcie 80)
o określoną stronę.
W momencie, gdy pakiety z komputera myhost (port 1050) do slashdot.org
(port 80) przechodzą przez ścianę ogniową, są przepisywane tak jakby nadchodziły z
interfejsu PPP ściany ogniowej, z portu 65000. Ściana ogniowa ma prawidłowy adres
Internetowy (1.2.3.4) więc pakiety odpowiedzi mogą wrócić bez przeszkód.
W momencie gdy pakiety z slashdot.org (port 80)
docierają do ściany ogniowej (port 65000), są przepisywane i wysyłane do myhost'a
na port 80. To prawdziwa magia maskarady, ponieważ pamięta kiedy przepisuje wychodzące
pakiety i potrafi skoordynować je z pakietami odpowiedzi i je również prawidłowo
przepisać.
Netscape rysuje stronę.
Z punktu widzenia slashdot.org,
połączenie nadchodzi z 1.2.3.4 (interfejs PPP ściany ogniowej) i portu 65000 do 207.218.152.131
(slashdot.org) port 80. Z punktu widzenia komputera "myhost"
połączenie wykonywane jest z adresu 192.168.1.100 (myhost) i
portu 1050 do adresu 207.218.152.131 (slashdot.org) i na port
80.
W tym scenariuszu, Twoja własna sieć jest
częścią Internetu i pakiety przepływają bez zmian między sieciami. Pula adresów IP
sieci prywatnej musi być przydzielona przez złożenie podania o blok adresów IP, tak by
reszta sieci wiedziała jak skierować do Ciebie pakiety. Implikuje to połączenie
stałe.
W tym przypadku, filtr pakietów jest używany do
restrykcji które pakiety mogą być przekazywane pomiędzy siecią a resztą Internetu,
np. obostrzenie że od strony Internetu można osiągnąć tylko serwery WWW Twojej sieci
prywatnej.
Przykład: Umożliwienie dostępu do stron WWW z sieci prywatnej do Internetu:
Adresy w twojej sieci prywatnej są przydzielone zgodnie z
zarejestrowanym blokiem numerów IP które otrzymałeś (powiedzmy 1.2.3.*).
Ściana ogniowa jest skonfigurowana na akceptację całego ruchu.
Netscape jest skonfigurowany do połączeń bezpośrednich.
DNS musi być skonfigurowany prawidłowo w Twojej sieci prywatnej.
Ściana ogniowa powinien być domyślną bramką dla sieci prywatnej.
Netscape na maszynie "myhost" odwołuje się do strony http://slashdot.org
Netscape szuka nazwy slashdot.org i dostaje adres 207.218.152.131.
Otwiera połączenie do tego adresu IP przez port 1050, i prosi serwer WWW
(na porcie 80) o określoną stronę.
Pakiety przechodzą przez ścianę ogniową, tak jak przechodzą
przez parę innych routerów na drodze między Tobą a slashdot.org.
Netscape rysuje stronę.
Tzn. Jest tylko jedno połączenie: z 1.2.3.100 (myhost)
port 1050, do 207.218.152.131 (slashdot.org) port 80.
Jest parę sposobów które możesz zastosować by
udostępnić Internetowi dostęp do Twoich usług w sieci, zanim zaczniesz uruchamiać
odpowiednie serwisy na ścianie ogniowej. Będą one pracowały na zasadach takich jak
proxy lub maskarada dla połączeń zewnętrznych.
Najprostszym podejściem jest zainstalowanie
"przekierowywacza", który jest odpowiednikiem proxy dla ubogich - czeka na
połączenie na danym porcie, a następnie otwiera połączenie do zdefiniowanego hosta i
portu w sieci wewnętrznej i kopiuje dane między tymi dwoma połączeniami. Przykładem
takiego programu może być "redir". Z punktu widzenia Internetu,
połączenie jest realizowane do Twojej ściany ogniowej. Z punktu widzenia Twojego
serwera w sieci prywatnej, połączenie jest realizowane ze ściany ogniowej do Twojego
serwera.
Innym podejściem (które wymaga patcha dla kerneli
serii 2.0.x dla ipportfw lub kernela w wersji 2.1.x i późniejszych) jest używanie
przekazywania w samym kernelu. Robi on tą samą robotę co program "redir"
tylko trochę w inny sposób: kernel przepisuje pakiety w trakcie gdy one przechodzą
przez ścianę ogniowąl, zmieniając ich adres docelowy i port na host i port w sieci
prywatnej. Z punktu widzenia Internetu połączenie jest realizowane do Twojej ściany
ogniowej. Z punktu widzenia serwera w sieci prywatnej, połączenie jest wykonywane z
Internetu do jego samego.
...napisał wspaniałe nowe HOWTO o maskaradzie,
które ma wiele wspólnego z tym HOWTO. Możesz aktualnie znaleźć ten dokument pod
adresem http://www.ecst.csuchico.edu/~dranch/LINUX/index-LINUX.html#ipmasq
Odnośnie większej ilości informacji o Maskaradzie
- spodziewam się znaleźć pod auspicjami Projektu Dokumentacji Linux'a na stronie http://www.metalab.unc.edu/LDP. Oficjalna
strona Maskarady to http://ipmasq.cjb.net.
Ta sekcja opisuje co tak naprawdę powinieneś
wiedzieć by zbudować sobie filtr pakietów który zaspokaja Twoje potrzeby.
Kernel zaczyna z trzema listami reguł; listy te są
nazywane łańcuchami ściany ogniowej lub po prostu łańcuchami. Nazywają sie one input
(wejściowy), output (wyjściowy) i forward (przekazujący). Kiedy pakiet przychodzi
(powiedzmy, przez kartę Ethernetową), kernel używa łańcucha wejściowego (input) by
zdecydować o jego losie. Jeśli pakiet przeżyje ten krok, kernel decyduje gdzie go
wysłać (nazywa się to routingiem). Jeśli jest skierowany do innej maszyny, sprawdza
również łańcuch przekazujący (forward). Na koniec, zanim pakiet opuści maszynę,
kernel sprawdza jeszcze łańcuch wyjściowy (output).
Łańcuch to zbiór reguł. Każda reguła mówi
"jeśli nagłówek pakietu wygląda tak, to zrobimy z nim właśnie to". Jeśli
reguła nie dotyczy pakietu, sprawdzana jest następna. Jeśli nie ma już żadnych reguł
do sprawdzenia, kernel sprawdza jeszcze główne założenie łańcucha by zdecydować co
zrobić.W bardzo bezpiecznym otoczeniu, to główne założenie mówi zwykle żeby
odrzucić ten pakiet.
Dla fanów ASCII, poniżej rysunek drogi pakietu
który przechodzi przez maszynę:
-------------------------------------------------------------------
|
ACCEPT/
lo interface |
v
REDIRECT _______
|
--> C --> S --> ______ --> D --> ~~~~~~~~ -->|forward|---->
_______ -->
h a |input |
e {Routing } |Chain |
|output |ACCEPT
e n |Chain |
m {Decision} |_______|
--->|Chain |
c i |______|
a ~~~~~~~~
| | ->|_______|
k t |
s |
| |
| |
s y |
q |
v |
| |
u | v
e v
DENY/ | |
v
m | DENY/
r Local Process REJECT | |
DENY/
| v REJECT
a |
| | REJECT
| DENY
d
-------------------- |
v
e -----------------------------
DENY
[dla jasności rysunku pozostawiono go w wersji oryginalnej - przyp.tłum.]
A teraz opiszę punkt po punkcie każdy etap:
Checksum (suma kontrolna):
To test, czy pakiet nie jest uszkodzony w jakiś sposób. Jeśli jest, zostaje odrzucony
(anulowany).
Sanity (poprawność):
To jeden z testów poprawności przed każdym łańcuchem ściany ogniowej, ale w
przypadku łańcucha wejściowego (input chain) jest najbardziej ważny. Niektóre
zniekształcone pakiety mogłyby sprawić duży problem kodowi sprawdzającemu reguły i
są one tutaj odrzucane (zostaje to odnotowane informacją w syslogu).
input chain (łańcuch wejściowy):
To pierwszy łańcuch ściany ogniowej, na którym pakiet będzie testowany. Jeśli
werdykt nie zostanie orzeczony na DENY (anulować) lub REJECT (odrzucić), pakiet
przechodzi dalej.
Demasquerade (zdemaskaradowanie):
Jeśli pakiet jest odpowiedzią na poprzedni, zamaskaradowany pakiet, jest
zdemaskaradowywany i przechodzi bezpośrednio do łańcucha wyjściowego (output). Jeśli
nie używasz maskarady IP, możesz ten etap wymazać z myśli.
Routing decision (decyzja o routingu):
Kod odpowiedzialny za routing analizuje pole przeznaczenia, by zdecydować czy pakiet ma
trafić do lokalnego procesu (sprawdź "Przetwarzanie Lokalne" poniżej) lub
przekazany do zdalnej maszyny (sprawdź "Łańcuch przekazujący" niżej).
Local process (proces lokalny):
Proces działający na maszynie może otrzymywać pakiety po decyzji z poprzedniego
punktu, jak również wysyłać pakiety (które po decyzji o routingu z puntku wyżej,
trafiają do łańcucha wyjściowego (output) ).
lo interface (interfejs lo):
Jeśli pakiety z lokalnego procesu mają trafić do lokalnego procesu, przejdą przez
łańcuch wyjściowy (output) z interfejsem ustawiony na 'lo', a potem wrócą przez
łańcuch wejściowy (input), również przez interfejs 'lo'. Interfejs ten jest zwykle
nazywany loopback'iem (pętlą zwrotną).
local (lokalnie):
Jeśli pakiet nie został wykreowany przez proces lokalny, sprawdzany jest łańcuch
przekazujący (forward), w innym wypadku pakiet przekazywany jest do łańcucha
wyjściowego (output).
forward chain (łańcuch przekazujący):
Ten łańcuch jest sprawdzany kiedy pakiet stara się przejść przez tą maszynę do
innej.
output chain (łańcuch wyjściowy):
Ten łańcuch jest z kolei sprawdzany dla wszystkich pakietów, zanim opuszczą one
maszynę.
Po pierwsze, sprawdź czy masz wersję ipchains na
której opiera się ten dokument:
$ ipchains --version
ipchains 1.3.9, 17-Mar-1999
Proszę zauważyć, że zalecam 1.3.4
(które nie ma długich opcji, takich jak '--sport'), lub 1.3.8
i wyższe - są one bardzo stabilne.
ipchains posiadają całkiem szczegółowy manual (man
ipchains), i jeśli potrzebujesz szczegółów jakiejś konkretnej opcji,
powinieneś sprawdzić interfejs programowy (man 4 ipfw), lub plik net/ipv4/ip_fw.c
znajdujący się w źródłach kernela serii 2.1.x, który jest jak najbardziej
autorytatywny.
Jest również ściąga autorstwa Scott'a Bronson'a
w paczce źródłowej, zarówno w formatach A4 i US Letter w PostScript'cie(TM).
Istnieje parę różnych rzeczy które możesz
zrobić z ipchains. Po pierwsze, możesz operować całymi łańcuchami. Zaczynasz z
trzema wbudowanymi łańcuchami: wejściowym (input), wyjściowym (output) i
przekazującym (forward), których nie możesz skasować.
Utworzenie nowego łańcucha (-N)
Skasowanie pustego łańcucha (-X)
Zmiana polityki dla wbudowanego łańcucha (-P)
Lista reguł w łańcuchu (-L)
Oczyszczenie łańcucha z reguł (-F)
Wyzerowanie liczników bajtów i pakietów we wszystkich regułach w
danym łańcuchu (-Z)
Jest kilka sposobów na manipulacje regułami wewnątrz łańcucha:
Dodaj nową regułę do łańcucha (-A)
Dodaj nową regułę na jakiejś pozycji w łańcuchu (-I)
Zastąp regułę na jakiejś pozycji w łańcuchu (-R)
Skasuj regułę na jakiejś pozycji w łańcuchu (-D)
Skasuj pierwszą z pasujących reguł z łańcucha (-D)
Jest również parę operacji na maskaradzie, które wbudowane są w
ipchains z chęci znalezienia dla nich dobrego miejsca:
Lista aktualnie maskaradowanych połączeń (-M -L)
Ustawienie timeoutów dla maskarady (-M -S) (i
sprawdź "Nie mogę ustawić timeoutów maskarady!")
Ostatnia (i najprawdopodobniej najużyteczniejsza) funkcja, pozwala Ci
co by się stało gdyby dany pakiet dotarł do danego łańcucha.
To właśnie chleb powszedni ipchains:: manipulacja
regułami. Najczęściej, będziesz używał dodawania (-A) i kasowania (-D).
Inne (-I dla wstawiania i -R dla zastępowania) są prostymi
rozszerzeniami tych koncepcji.
Każda reguła podaje zestaw wymagań, które pakiet
musi spełniać, oraz co zrobić gdy je spełnia ("target"). Na przykład,
mógłbyś chcieć zakazać wszystkim pakietom ICMP nadchodzącym z adresu IP 127.0.0.1. W
tym przypadku protokołem będzie ICMP, źródłowym adresem (source address) będzie
127.0.0.1 a celem ("target") jest "DENY" (anulowanie).
127.0.0.1 to interfejs "loopback" (pętla
zwrotna), który ma się nawet wtedy, gdy nie ma połączenia z żadną siecią. Możesz
użyć programu 'ping' by wygenerować takie pakiety (wysyła on pakiet ICMP typ 8 (echo
request - żądanie echa)) na który wszystkie współpracujące hostu powinny
odpowiedzieć pakietem ICMP typ 0 (echo reply - odpowiedź na echo). Czyni go to
użytecznym do testów.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# ipchains -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#
Widać tutaj że pierwszy ping powiódł się (parametr '-c 1' mówi pingowi
by wysłał tylko jeden pakiet).
Następnie dołączamy (-A) do łańcucha wejściowego
(input) regułę mówiącą że pakiety nadchodzące z adresu 127.0.0.1 ( '-s
127.0.0.1') i używające protokołu ICMP ('-p ICMP') powinny trafić
do anulowania (DENY) ('-j DENY').
Następnie testujemy naszą regułę, wykonując drugi raz pinga.
Nastąpi pauza, po której program podda się - po oczekiwaniu na pakiet który nigdy nie
wróci.
Możemy skasować regułę na dwa sposoby. Po pierwsze, ponieważ wiemy
że jest to jedyna reguła w łańcuch wejściowym, możemy użyć kasowania z numerem
reguły, tak jak poniżej:
# ipchains -D input 1
#
Polecenie skasuje regułę numer 1 w łańcuchu wejściowym.
Drugi sposób to lustrzane odbicie polecenie -A, ale zamiast parametru
-A wpiszemy -D. Jest to użyteczne gdy masz złożony zestaw reguł i nie chce Ci się ich
liczyć by sprawdzić, że to 37 reguły chcesz się pozbyć. W tym wypadku napiszemy:
# ipchains -D input -s 127.0.0.1 -p icmp -j DENY
#
Składnia -D musi być dokładnie taka sama jak -A (lub -I
i -R). Jeśli będzie wiele takich samych reguł, tylko pierwsza zostanie
skasowana.
Widzieliśmy już użycie parametru '-p'
by sprecyzować protokół i '-s' by sprecyzować adres źródłowy, ale są
jeszcze inne opcje które możemy podać by opisać pakiet o który nam chodzi. Poniżej
znajduje się wyczerpujące kompendium.
Adresy IP źródłowy (-s) i
przeznaczenia (-d) mogą być podane na cztery sposoby. Najbardziej
powszechnym sposobem jest podanie pełnej nazwy, takiej jak "localhost"
czy "www.linuxhq.com". Drugi sposób, to podanie numeru IP, np. 127.0.0.1.
Trzeci i czwarty sposób polegają na podaniu grupy
adresów IP, tak jak np. 199.95.207.0/24 czy 199.95.207.0/255.255.255.0.
Oba sposoby podają adresy od 199.95.207.0 do 199.95.207.255
włącznie. Cyfry po znaku '/' mówią które części adresu IP są ważne;
domyślnie przyjmowane jest '/32' lub inaczej '/255.255.255.255'
(czyli ważne są wszystkie cyfry). Do podania wszystkich adresów IP służy '/0',
które może być użyte na przykład tak:
# ipchains -A input -s 0/0 -j DENY
#
Rzadko się tego używa, ponieważ efekt tego ciągu jest dokładnie
taki jak nie podanie parametru '-s 0/0' w ogóle.
Wiele flag, włączając w to '-s' i '-d'
może mieć swoje argumenty poprzedzone przez '!' (wymawiane 'not'
czyli 'nie') by sprawdzało adresy NIE równe tym podanym. Na przykład '-s
! localhost' dotyczy wszystkich pakietów które nie pochodzą z interfejsu
localhost.
Protokół podaje się po parametrze '-p'.
Protokół może być numerem (jeśli znasz wartości numeryczne protokołów IP) lub
nazwą dla 'TCP', 'UDP' i 'ICMP'. Wielkość liter
jest nieważna, więc 'tcp' działa tak samo jak 'TCP'.
Nazwa protokołu może być poprzedzona przez znak
'!' by go odwrócić, tak jak na przykład '-p ! TCP' (warunek dotyczy wszystkie
protokołów prócz TCP).
W specjalnym przypadku gdy podajemy protokół TCP
lub UDP, można podać dodatkowy parametr specyfikujący port (lub grupę) który nas
interesuje (sprawdź "Obsługa fragmentów" poniżej). Grupę podaje się
używając znaku ':', tak jak na przykład '6000:6010' - ten przedział
dotyczy 11 portów, od 6000 do 6010 włącznie. Jeśli ominiemy dolną granicę, jest ona
przyjmowana domyślnie na 0. Jeśli ominiemy górną granicę, jest ona przyjmowana na
65535. Więc aby podać porty TCP poniżej 1024, możemy napisać '-p TCP -s
0.0.0.0/0 :1023'. Numery portów mogą być również podane jako nazwy, np. 'www'
(wskaże port 80).
Zauważ że porty również mogą być poprzedzane
znakiem '!', który powoduje ich zanegowanie. Aby podać wszystkie pakiety
TCP OPRÓCZ pakietów WWW, możesz napisać '-p TCP -d 0.0.0.0/0 ! www'.
Jest bardzo ważne, by zauważyć że podanie
-p TCP -d ! 192.168.1.1 www
jest bardzo różne w działaniu od
-p TCP -d 192.168.1.1 ! www
Pierwszy mówi o pakietach TCP do portu WWW na każdej maszynie oprócz
192.168.1.1 a drugi, o pakietach TCP na dowolne porty na maszynie 192.168.1.1
oprócz portu WWW.
Na koniec, przykład w którym chodzi nam o wszystko oprócz portu WWW
i maszyny 192.168.1.1:
-p TCP -d ! 192.168.1.1 ! www
Protokół ICMP również umożliwia podanie
dodatkowego argumentu, ale ponieważ ICMP nie posiada portów (ICMP ma typ i kod), mają
one inne znaczenie.
Możesz podać je w formie nazw ICMP (użyj 'ipchains
-h icmp' by otrzymać listę nazw) po opcji '-s' lub jako typ i kod
numeryczny ICMP, w którym typ występuje po opcji '-s' a kod po opcji '-d'.
Nazwy ICMP są raczej długie: musisz użyć tylko
tylu liter, by wskazywała jednoznacznie na którąś ze zdefiniowanych.
Poniżej mała tabelka najbardziej popularnych
pakietów ICMP:
numer |
nazwa |
wymagane przez |
0
|
echo-reply |
ping |
3
|
destination-unreachable |
ruch TCP/UDP |
5
|
redirect routing |
jeśli nie działa demon routingu |
8
|
echo-request |
ping |
11
|
time-exceeded |
traceroute |
Zauważ że nazwy ICMP nie mogą być aktualnie
poprzedzane parametrem '!'.
NIGDY NIGDY NIGDY nie blokuj wszystkich pakietów typu 3 ICMP!
(sprawdź niżej "Pakiety ICMP").
Opcja '-i' powoduje wskazanie
interfejsu. Interfejs to fizyczne urządzenie do którego pakiet dociera lub z którego
wychodzi. Możesz użyć polecenia 'ifconfig' by wylistować interfejsy
które są 'up' (działają).
Interfejs dla pakietów przychodzących (tzn.
pakietów przechodzących przez łańcuch wejściowy) jest uważany za interfejs z
którego przyszły. Odpowiednio interfejs dla pakietów wychodzących to ten, przez który
wyjdą pakiety po pokonaniu łańcucha wyjściowego. Pakiety które przechodzą przez
łańcuch przekazujący (forward), trafiają również do interfejsu wyjściowego.
Jest całkowicie poprawne podać interfejs, który
aktualnie nie istnieje - reguła nie będzie dotyczyła niczego dopóki interfejs
fizycznie nie zostanie podniesiony (nie zacznie działać). Jest to bardzo użyteczne dla
połączeń PPP do wdzwaniania się (zwykle interfejs ppp0) i podobnych.
Jako specjalny przypadek, interfejs kończący się
znakiem '+' będzie wskazywał na wszystkie interfejsy (czy istnieją czy
nie), które zaczynają się na ten ciąg znaków. Na przykład, by zdefiniować regułę
która dotyczy wszystkich interfejsów PPP, można napisać '-i ppp+'.
Nazwa interfejsu może również być poprzedzona
znakiem '!' by oznaczyć wszystkie interfejsy oprócz wskazanego.
Czasami przydatne jest pozostawienie możliwości
połączeń TCP tylko w jedną stronę. Na przykład, mógłbyś chcieć zezwalać na
połączenia do zewnętrznego serwera WWW, ale nie połączenia z tego serwera.
Najprostszym podejściem byłoby zablokowanie
pakietów TCP nadchodzących z tego serwera. Niestety, połączenia TCP wymagają tego by
pakiety mogły krążyć w jedną i drugą stronę.
Rozwiązaniem jest blokowanie tylko pakietów z
prośbą o połączenie. Nazywa się je pakietami SYN (technicznie rzecz biorąc, są to
pakiety z ustawioną flagą SYN i ze zgaszonymi flagami FIN i ACK, ale nazywamy je
pakietami SYN). Uniemożliwiając ruch tylko tym pakietom, możemy powstrzymać próby
połączeń.
Używa się do tego parametru '-y' -
jest prawidłowy tylko dla reguł które dotyczą protokołu TCP. Na przykład, by
wskazać połączenia TCP nadchodzące z adresu 192.168.1.1:
-p TCP -s 192.168.1.1 -y
I ponownie, parametr może być odwrócony przez
użycie '!', który oznacza: każdy pakiet oprócz pakietów inicjujących połączenie.
Czasami pakiet jest zbyt duży by mógł zmieścić
się naraz w maksymalnej jednostce transmisyjnej (MTU). Gdy coś takiego ma miejsce,
dzielony jest na fragmenty i wysyłany jako parę pakietów. Adresat składa fragmenty by
zrekonstruować cały pakiet.
Problem z fragmentami polega na tym, że część ze
specyfikacji wymienionych wyżej (a szczególnie: port źródłowy i przeznaczenia, typ
ICMP, kod ICMP i flaga TCP SYN) wymagają by kernel zajrzał na początek pakietu który
znajduje się tylko w pierwszym fragmencie całości.
Jeśli Twoja maszyna jest jedynym połączeniem z
siecią zewnętrzną, możesz polecić kernelowi Linuksa by składał wszystkie fragmenty
które przechodzą przez niego - kompilując kernel z opcją "IP: always
defragment" ustawioną na 'Y'. To pozwala obejść problem.
W innym przypadku, ważne jest by zrozumieć jak
pakiety traktowane są przez reguły filtrujące. Każda z reguł która wymaga informacji
których nie mamy po prostu nie będzie pasować. To oznacza że pierwszy fragment jest
traktowany jak każdy inny. Drugi i następne fragmenty nie będą tak potraktowane. Wobec
tego reguła -p TCP -s 192.168.1.1 www (podająca port źródłowy 'www')
nigdy nie będzie dotyczyć fragmentu (innego niż pierwszy fragment pakietu). Tak samo
reguła odwrotna: -p TCP -s 192.168.1.1 ! www.
Jednak możesz podać reguły dotyczące drugiego i
każdego następnego pakietu, używając parametru '-f'. Oczywiście, nie jest w tym
przypadku podawanie portów TCP czy UDP, typ czy kodu ICMP lub użycie parametru
dotyczącego flagi TCP SYN.
Niemożliwe jest również podanie, że reguła nie
dotyczy drugiego i każdego następnego pakietu przez podanie jednocześnie z parametrem
'f' parametru '!'.
Zwykle uważa się za bezpieczne przepuszczanie
kolejnych pakietów, ponieważ pierwszy powinien zostać odfiltrowany i dzięki temu
będzie niemożliwe złożenie pakietu na maszynie docelowej, jednak znane były błędy
które powodowały zawierszanie się maszyn tylko przez wysyłanie odpowiednio
spreparowanych fragmentów. Ty decydujesz.
Uwaga dla sieciowców: zniekształcone pakiety
(pakiety TCP, UDP i ICMP zbyt krótkie by kod ściany ogniowej ustalił port, kod lub typ
ICMP) są również traktowane jak fragmenty. Tylko fragmenty pakietów TCP zaczynające
się na pozycji 8 są odrzucane przez kod ściany ogniowej (w pliku syslog powinna się
pojawić o tym informacja).
Jako przykład, reguła która odrzuci fragmenty
kierowane do 192.168.1.1:
# ipchains -A output -f -d 192.168.1.1 -j DENY
Dobra, wiemy o wszystkich sposobach pozwalających na sprawdzenie
pakietu pod kątem reguły. Jeśli pakiet pasuje do niej, dzieją się następujące
rzeczy:
Licznik dla tej reguły zliczający bajty jest powiększany o rozmiar
pakietu (nagłówka i reszty).
Licznik pakietów dla tej reguły jest zwiększany.
Jeśli reguła tego wymaga, pakiet jest logowany.
Jeśli reguła tego wymaga, pole Type Of Service (Typ Usługi) jest
zmieniane.
Jeśli reguła tego wymaga, pakiet jest oznaczany (nie w wersji
kernela 2.0.x).
Adres docelowy reguły jest sprawdzany by zdecydować, co zrobić z
pakietem dalej.
Z różnych powodów omówimy je według ważności.
Akcja pakietu mówi kernelowi co robić z pakietem który pasuje do
reguły. ipchains używają parametru '-j' (jak 'jump-to' czyli
'skocz do') by podać akcję dla danego pakietu. Nazwa akcji musi być mniejsza niż 8
liter i rozróżniane są małe i duże litery ('RETURN' i 'return'
to dwie różne akcje).
Najprostszym przypadkiem jest gdy nie podano akcji. Taka reguła
(nazywana również 'zliczającą') jest użyteczna gdy po prostu chcemy tylko liczyć
pakiety danego rodzaju. Czy taka reguła odpowiada pakietowi czy nie, kernel przechodzi po
prostu do następnej. Na przykład, by zliczać ilość pakietów podróżujących do
adresu 192.168.1.1 możemy napisać tak:
# ipchains -A input -s 192.168.1.1
#
(i używając komendy 'ipchains -L -v' możemy sprawdzić
liczniki bajtów i pakietów odpowiadających danej regule).
Jest sześć specjalnych akcji dla pakietu. Pierwsze trzy: ACCEPT
(akceptacja), REJECT (anulowanie) i DENY (odrzucenie) są raczej zrozumiałe. ACCEPT
(akceptacja) pozwala pakietowi przejść. DENY (odrzucenie) odrzuca pakiet tak jakby nigdy
nie został odebrany. REJECT (anulowanie) odrzuca pakiet, ale (jeśli to nie jest pakiet
ICMP) generuje odpowiedź ICMP do źródła pakietu by poinformować, że adres docelowy
jest nieosiągalny.
Następne - MASQ mówi pakietowi by zastosować maskaradę dla pakietu.
By to działało, kernel musi być skompilowany z opcją "IP Masquerading"
włączoną. Co do szczegółów proszę zajrzeć do Masquearding-HOWTO i dodatku
"Różnice między ipchains i ipfwadm". Ta akcja jest dopuszczalna tylko dla
pakietów które przechodzą przez łańcuch forward (przekazujący).
Inną specjalną akcją jest REDIRECT (przekierowanie), która mówi
kernelowi by wysłało pakiet do lokalnego portu zamiast tam gdzie miał się udać.
Można ją zastosować tylko w przypadku protokołu TCP i UDP. Dodatkowo można podać
port (nazwę lub numer) po podaniu '-j REDIRECT' co spowoduje że pakiet
zostanie przekierowany do tego portu, nawet jeśli był zaadresowany do innego portu. Ta
akcja jest dopuszczalna tylko dla pakietów które przechodzą przez łańcuch input
(wejściowy).
Ostatnia akcją jest RETURN (zwrot) którego działanie jest identyczne
ze spadkiem na koniec łańcucha (sprawdź "Ustawianie zasad" poniżej).
Każda inna akcja wskazuje na łańcuch zdefiniowany przez użytkownika
(tak jak opisano to w "Operacje na całych łańcuchach" poniżej). Pakiet
zacznie przechodzenie przez reguły w tamtym łańcuchu. Jeśli nie zdecyduje on o losie
tego pakietu, wróci on z powrotem i zostanie sprawdzony w aktualnym łańcuchu reguł.
Czas na więcej rysunków ASCII. Rozważ dwa (proste) łańcuchy: input
(wbudowany) i Test (zdefiniowany przez użytkownika):
'input'
'Test'
--
