Poprzednia Następna Spis Treści

3. Firewall.

3.1 Oprogramowanie i czytanie.

Pownieneś przeczytać Firewall-HOWTO.

Dowiesz się stamtąd skąd wziąć ipfwadm jeśli jeszcze go nie masz. Są jeszcze inne narzędzia, które możesz ściągnąc, ale ja nie zrobiłem nic dalej bez ipfwadm. Jest on dość przyjazny i niskopoziomowy ! Widzisz dokładnie co się dzieje.

3.2 Sprawdzenie wstępne.

Wkompilowałeś IP-forwarding i -masquerading w jądro, więc możesz sprawdzić czy firewall jest w swoim domyślnym (akceptującym) stanie poleceniami:

       ipfwadm -I -l
       ipfwadm -O -l
       ipfwadm -F -l

I tak odpowiednio wyświetlane są zasady dotyczące wchodzących, wychodzących i przekazywnaych (masquerading) pakietów. -l oznacza "list".

Możliwe, że wkompilowałeś także zliczanie (accounting):

       ipfwadm -A -l

Powinieneś zobaczyć, że nie ma zdefiniowanych żadnych zasad i że domyślnym stanem jest akceptacja wszystkich pakietów. Możesz wrócić do tego stanu w każdej chwili pisząc:

       ipfwadm -I -f
       ipfwadm -O -f
       ipfwadm -F -f

-f oznacza "flush". Możliwe, że musisz tego użyć.

3.3 Zasady domyślne.

Chcę po prostu odciąc resztę świata od swojej sieci wewnętrznej i nic więcej, tak więc ostatnią (domyślną) zasadą będzie ignorowanie wszelkich pakietów pochodzących z wnętrza sieci i zaadresownych na zewnątrz. Umieściłem wszystkie te zasady (w takiej kolejności) w /etc/rc.d/rc.firewall i wykonuję ten skrypt z rc.local podczas startu.

  ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0

-S oznacza źródłowy (source) adres/maskę. -D to adres/maska przeznaczenia (destination).

Ten format dla ipfwadm-a jest trochę długi. Program ten jest inteligentny jeśli chodzi o nazwy sieciowe i niektóre popularne skróty. Zajrzyj do podręcznika systemowego.

Przypuszczalnie bardziej wygodnie jest określać niektóre lub wszystkie zasady dla wychodzącej połowy firewall-a używając opcji -O zamiast -I, ale ja określę je dla części wchodzącej.

3.4 Dziury na adres.

Przed zasadami domyślnymi muszę umieścić kilka zasad, które służą jako wyjątek od ogólnego zabronienia dostępu do serwisów zewnętrznych dla klientów wewnętrznych.

Chcę traktować adres firewall-a w sieci wewnętrznej specjalnie. Zabronię logowania się na tę maszynę o ile ktoś nie ma specjalnego pozwolenia, ale jak już się tam zalogują, to powinni mieć możliwość kontaktu ze światem.

  ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \
		       -D 0.0.0.0/0.0.0.0

Chcę także, aby klienci wewnątrz sieci mogli się komunikować z firewall-em. Może mogą go zmusić, aby wypuścił ich na zewnątrz !

  ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \
		       -D 192.168.2.100/255.255.255.255

W tym momencie sprawdź czy możesz się dostać do klientów wewnątrz sieci z zewnątrz poprzez telnet i nie możesz się wydostać. Oznacza to, że możesz się kontaktować, ale klienci nie mogą ci odpowiedzieć. Powinieneś móc się dostać wszystkimi drogami jeśli uzywasz firewall-a jako maszyny przejściowej. Spróbuj także rlogin i ping z uruchomionym tcpdump na jednej z kart. Powinieneś umieć odpowiednio wykorzystać to co robisz.

3.5 Dziury na protokół.

W następnym kroku poluźniłem trochę zasady protokół po protokole. Chcę, na przykład, wpuszczać ping-i, żeby dostać odpowiedź.

  ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \
			       -D 0.0.0.0/0.0.0.0

-P icmp to magiczne zaklęcie dla konkretnego protokołu.

Dopóki trzymam ftp-proxy pozwalam także na odwołania ftp na zewnątrz przez konkretne porty. Te docelowe porty na odległej maszynie to: 20, 21, 115

  ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
			       -D 0.0.0.0/0.0.0.0 20 21 115

Bez działającego serwera nazw nie mógłbym mieć działającego sendmail-a. Zamiast ustawić serwer nazw na firewall-u, pozwoliłem mu przepuszczać zapytania skierowane do najbliższego serwera nazw i umieściłem jego adres w plikach /etc/resolv.conf u klientów - nameserver 123.456.789.31 - w osobnej linijce.

  ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
			       -D 123.456.789.31/255.255.255.255 54

To, którego portu używa dany serwis możesz dowiedzieć się z programu tcpdump. Po prostu uruchom dany serwis przez ftp, albo telnet na danym kliencie i szukaj go na portach wejściowych albo wyjściowych na danym kliencie:

  tcpdump -i eth1 -e host client04

Plik /etc/services jest drugim ważnym źródłem.

Aby pozwolić na dostęp poprzez telnet do firewall-a z zewnątrz, musisz pozwolić klientom na wołanie na konkretnym porcie. Rozumiem dlaczego jest to potrzebne dla ftp - z powodu serwera, który ustawia strumień danych na końcu - ale nie jestem pewien dlaczego telnet także tego potrzebuje.

  ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
			       -D 0.0.0.0/0.0.0.0

Są problemy z pewnymi demonami, które sprawdzają nazwę firewall-a, żeby zdecydować jaki jest ich adres sieciowy. rpc.yppasswdd to jeden, z którym miałem problemy. Nalegał na rozsyłanie informacji, że jest on poza firewall-em (na drugiej karcie). To znaczy, że klient wewnątrz nie może się z nim porozumieć.

Zamiast uruchamiania IP-aliasing-u, albo zmiany kodu demona, odwzorowałem nazwę dla karty wewnętrznej u klientów w ich plikach /etc/hosts.

3.6 Sprawdzenia.

Teraz chcesz sprawdzić czy wciąż możesz połaczyć się telnet-em, rlogin-em lub ping-ować z zewnątrz. Z wewnątrz powinieneś móc ping-ować na zewnątrz. Powinieneś móc także połaczyć się telnet-em z firewall-em z wewnątrz a później móc robić wszystko.

To tyle. W tym momencie możesz się pouczyć o rpc/Yellow Pages i interakcji z plikiem haseł. Sieć chroniona firewall-em powinna działać tak, aby nie pozwalać nieuprzywilejowanym użytkownikom na logowanie się na firewall-u i przez to na wychodzenie na zewnątrz.. A to już historia na inne HOWTO.


Poprzednia Następna Spis Treści