[ Pobierz całość w formacie PDF ]
zaakceptowane przez te reguły zostaną zalogowane (reguła nr 5) i usunięte (reguła nr 6).
Oczywiście gdyby nie było reguły nr 6, to zadziałałaby polityka łańcucha INPUT,
wcześniej ustawiona również na DROP& ale trochę ostrożności nikomu nie zaszkodzi.
Gdybyśmy uruchomili na naszym routerze serwer WWW (czego oczywiście ze wzglę-
dów bezpieczeństwa nie polecam) wystarczyłoby skopiować regułę nr 2 i wkleić ją
poniżej tej reguły (w wierszu poprzedzającym regułę 4) i zmienić wartość portu 22 na
80. Przypominam, że numery portów znajdziesz w pliku /etc/services.
Jak wcześniej pisałem, powinieneś zdecydować, z jakich adresów IP będziesz admi-
nistrował swoim routerem i skonfigurować swój firewall tak, aby pozwalał jedynie na
połączenia z tych adresów. Załóżmy, że będziesz łączył się protokołem SSH2 jedynie
z komputera o adresie 192.168.1.2, znajdujÄ…cego siÄ™ w twojej sieci lokalnej. Bardziej
restrykcyjna reguła, w miejsce wiersza drugiego, będzie miała postać:
Możesz również wykorzystać możliwość definiowania adresu MAC komputera upraw-
nionego do połączenia; po dokładniejszy opis zajrzyj do manuala lub HOWTO. Do
wytłumaczenia pozostaje reguła nr 3. Bardzo często różne serwery usług (np. ftp) pytają
hosta, z którego się łączymy, o nasze dane, za pomocą usługi ident działającej na por-
cie 113. Jeżeli nie byłoby reguły 3, przykładowy serwer FTP wysłałby pakiet na port 113
naszego routera i czekał na odpowiedz. Ponieważ pakiet ten zostałby usunięty przez
firewalla, nie otrzymałby żadnej odpowiedzi. W końcu otrzymalibyśmy zgodę na po-
łączenie z serwerem FTP, ale czas oczekiwania byłby dosyć długi. W wierszu 3 po-
wodujemy, że na zapytania na port 113 protokołu TCP generowany jest pakiet proto-
kołu ICMP z komunikatem: icmp-port-unreachable. Serwer FTP jest poinformowany,
RozdzIał 10. f& FIrewaII 415
że na naszym hoście usługa ident nie działa i już bez dalszej zwłoki pozwala nam się
zalogować. Zwróć również uwagę, że dla protokołu UDP nie zostały zdefiniowane żad-
ne reguły, ponieważ nie udostępniamy żadnych usług z niego korzystających. Tak na-
prawdę to udostępniamy jedynie ssh.
W tym łańcuchu również powinniśmy dokładnie zdefiniować połączenia, które można
nawiązywać z naszego routera. Jednak w ten sposób sami sobie ograniczalibyśmy funk-
cjonalność naszego routera, a może się zdarzyć, że będziemy mieli ochotę trochę po-
eksperymentować z pakietami. Jednak oczywiście w normalnych warunkach zalecam
ustawienie bardziej restrykcyjnych reguł na łańcuch OUTPUT. Reguła w wierszu dru-
gim akceptuje wszystkie pakiety należące do poprawnych połączeń. Składnia
oznacza wszystkie wadliwe pakiety, nie należące do poprawnego połączenia.
Składnia jest przeczeniem, oznacza więc wszystkie poprawne pakiety.
Reguła 3 powoduje logowanie odrzuconych pakietów, a reguła 4 ich usunięcie.
W łańcuchu FORWARD definiujemy reguły dotyczące pakietów wędrujących poprzez
nasz router. Reguły 2 i 3 oznaczają: dla połączeń protokołów TCP i UDP wchodzą-
cych na kartę eth1 ( ) z adresów sieci lokalnej 192.168.1.0/24 z portów powy-
żej 1023 przepuść pakiety nawiązujące połączenia (NEW), pakiety należące do ist-
niejących połączeń (ESTABLISHED) i pakiety związane z istniejącymi połączeniami
(RELATED). Oznacza to, że z sieci lokalnej możemy nawiązywać dowolne połączenia.
Reguły 4 i 5 oznaczają: dla protokołów TCP i UDP wychodzących z karty eth1 ( )
do sieci lokalnej 192.168.1.0/24 na porty powyżej 1023 przepuść pakiety należące do
istniejących połączeń (ESTABLISHED) i pakiety związane z istniejącymi połącze-
niami (RELATED). W domyśle nie przepuszczaj pakietów nawiązujących połączenia
do sieci lokalnej. Reguła 6 pozwala na niczym nie ograniczony ruch pakietów proto-
kołu ICMP należących do poprawnych połączeń. Jeśli pojawią się jakieś pakiety nie
należące do istniejącego połączenia, nie zostaną one przepuszczone. Ostatnie dwie re-
guły standardowo logują i wycinają wszystkie pozostałe pakiety.
I oto mamy działający i w podstawowym stopniu zabezpieczający naszą sieć firewall.
Jego dostosowanie do potrzeb rzeczywistej sieci pozostawiam oczywiście tobie. Nie
podawałem tutaj wszystkich aspektów jego konstrukcji, na które powinieneś zwrócić
uwagę, ponieważ chciałem zachować jasną strukturę konstrukcji firewalla. Jak pisałem
na początku tego rozdziału, nie jest to gotowy do zastosowania skrypt. Jest to pewien
416 SIecI komputerowe. KompendIum
przykład, który miał ci pokazać zasady tworzenia firewalla. Możesz się na nim oprzeć
jak na szkielecie, ale musisz go obudować własnymi regułami. Powinieneś przeczytać
ponownie rozdział dotyczący bezpieczeństwa, wypisując sobie zagrożenia, przed któ-
rymi powinien obronić twoją sieć firewall, a następnie zaimplementować tę ochronę
w formie poleceń w skrypcie. Warto zajrzeć na stronę domową projektu netfilter i po-
przeglądać dokumentację w poszukiwaniu przykładów, różnych nietypowych rozwią-
zań itp. Kilka ciekawych zagadnień poruszę w następnym podrozdziale.
Logi systemowe
Po uruchomieniu skryptu /etc/rc.d/firewall.start mamy działający poprawnie firewall.
Przydałoby się, abyśmy informacje o działaniu firewalla mieli w logach. W tym celu
wpisujemy na koniec pliku /etc/syslog.conf następujący kod:
i oczywiście restartujemy demona syslogd:
od tego momentu w pliku /var/log/wszystko (oraz na konsoli 12 Alt+F12) będzie-
my mieli wszystkie logi systemowe. Należy uważać, aby logi nam nie przepełniły par-
tycji, czyli należy poprawnie skonfigurować logrotate, ale to oczywiście znajdziecie
już na stronach dotyczących konfiguracji Linuksa.
Problemy z działaniem firewalla
Należy obserwować logi systemu i patrzeć, co jest wycinane przez nasze reguły. Każdy
wycięty pakiet będzie opatrzony przedrostkiem, który zdefiniowaliśmy w regułach,
np. . Dzięki temu łatwo zorientujemy się, w którym miejscu
dzieje coś niedobrego. Pamiętaj, że niektóre z usuwanych pakietów nie są logowane.
Jeśli użyjesz:
[ Pobierz całość w formacie PDF ]