Ipchains_howto_PL.doc

(310 KB) Pobierz
Ipchains howto

Ipchains howto

 

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

 

1. Wprowadzenie

    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.

1.1 Co?

    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.

1.2 Dlaczego?

    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).

1.3 Jak?

    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.

1.4 Gdzie?

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.

 

2. Podstawy filtrowania pakietów

2.1 Co?

    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ż.

2.2 Dlaczego?

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.

2.3 Jak?

2.3.1 Kernel z filtrowaniem pakietó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.

2.3.2 ipchains

    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.

2.3.3 Sprawianie by reguły pozostawały na stałe

    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 </etc/ipchains.rules || exit 1
        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").

 

3. Jestem skołowany! Routing, masquerading, porforwarding, ipautofw...

    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.

 

3.1 Trzy linijkowy Przewodnik Rusty'ego do Masquerading'u

    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

3.2 Bezpłatna promocja: WatchGuard rządzi

    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

 

3.3 Powszechne konfiguracje ze ścianami ogniowymi

    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.

 

3.3.1 Sieć prywatna: tradycyjne proxy

    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:

  1. 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.
  2. Proxy WWW (np. "squid") jest zainstalowany i skonfigurowany na ścianie ogniowej, pracuje na porcie ...
Zgłoś jeśli naruszono regulamin