Przed przeczytaniem warto zapoznać się z kilkoma podstawowymi pojęciami, dotyczącymi komunikacji w Internecie.
STRESZCZENIE: Prezentacja pojęć związanych z zaporami sieciowymi i ich systematyka. Praktyka, czyli realizacja zapory w systemie Linux. Wskazanie zagadnień dla szczególnie zainteresowanych tematyką ochrony sieci wewnętrznej.
Zapora sieciowa (ang. firewall - ściana przeciwogniowa) - jeden ze sposobów zabezpieczania sieci/komputera/serwera przed intruzami. Termin określający sprzęt komputerowy wraz ze specjalnym oprogramowaniem bądź samo oprogramowanie blokujące niepowołany dostęp do sieci komputerowej, komputera, serwera itp. na której straży stoi.
Firewalle można podzielić na dwa typy, biorąc pod uwagę sposób działania: firewalle filtrujące ruch IP oraz serwery proxy.
Są bezpieczne, ale mają kilka ograniczeń. Można zablokować dostęp do sieci, ale nie da się uzyskać informacji o tym, kto korzysta z dostępu do sieci lokalnej lub z sieci lokalnej do Internetu. Jeśli administrator chce przyznać dostęp do sieci lokalnej komuś z zewnątrz, musi automatycznie udostępnić swoją sieć wszystkim spod danego adresu (a często jeden adres ma wiele komputerów z jednej sieci lokalnej).
Pakiety mogą być filtrowane statycznie lub dynamicznie.
Wadą tych firewalli są duże wymagania sprzętowe i brak elastyczności. Jeśli pojawia się nowa usługa, z której chcą korzystać użytkownicy, trzeba zainstalować na serwerze proxy dodatkowy program udostępniający ją użytkownikom sieci lokalnej.
Niekiedy cały ruch lokalny jest kierowany do serwera proxy za pomocą oprogramowania klienta i wtedy każdy wewnętrzny host musi mieć je uruchomione (najbardziej popularne oprogramowanie to SOCKS czy zmodyfikowany WinSock). Jedyną informacją używaną przy konfiguracji jest wtedy adres IP i maska podsieci, gdyż klient przekierowuje cały ruch nielokalny do serwera proxy. Jeśli serwer używa innego protokołu do komunikacji z klientami, cały ruch jest tłumaczony w obrębie serwera proxy na IP i przekierowywany do zdalnego serwera. Niestety, oprogramowanie klienta proxy nie jest uniwersalne, a wiele serwerów proxy jest oferowanych z oprogramowaniem klienta tylko do Windows.
Jeśli serwer proxy pracuje bez oprogramowania klienta i nie wymaga żadnej specjalnej konfiguracji wewnętrznych hostów w sieci lokalnej, mówimy o przezroczystym serwerze proxy (transparent proxy). Przezroczyste proxy oznacza, że klient nie musi wiedzieć o użyciu oprogramowania typu proxy i nie musi być specjalnie konfigurowany. Przykładowo: firewall jest skonfigurowany do przekierowywania wszystkich połączeń do portu 80 na port 8080 na którym pracuje tranparent proxy. Przy próbie pobrania dowolnej strony WWW, transmisja przekierowywana jest na port 8080, a następnie wszystko odbywa się jak w poprzednim przykładzie.
Jeśli ktoś nie chce, by zdalny system rozpoznał rzeczywiste adresy IP w sieci wewnętrznej, może użyć zaimlpementowanej w większości firewalli funkcji tłumaczenia adresów.
Proces ten może być przeprowadzony na trzy sposoby:
W przypadku translacji NAT wszystkie wewnętrzne adresy IP zostają ukryte, poza jednym, który może być dowolnym poprawnym adresem IP i który będzie widoczny na zewnątrz sieci lokalnej. Ponieważ komputery są ukryte pod jednym adresem IP, ściana ognia nie ma możliwości sprawdzenia, do którego z komputerów w sieci wewnętrznej jest skierowane połączenie.
W przypadku statycznego tłumaczenia adresów każdy lokalny adres IP jest ukryty pod oddzielnym adresem.
Wiele urządzeń stosuje zarówno ukrywanie NAT, jak i translację statyczną, co pozwala na przydzielanie osobnych adresów tylko tym komputerom, które tego potrzebują. W większości serwerów proxy jest używana translacja numerów portów PAT. Ruch na zewnątrz jest tłumaczony tak jak ukrywanie NAT, ale adresy są schowane za adresem ściany ognia, porty zaś zostają odwzorowane na porty konkretnego systemu w celu umożliwienia ruchu przychodzącego.
Pakiet netfilter (komenda iptables) służy do obsługi filtrowania pakietów w Linuksie przez jądro w wersji 2.4, oraz ustawiania maskarady.
Podstawowym pojęciem jest łańcuch (chain). Łańcuch jest to zbiór reguł filtrujących. Istnieją trzy standardowe łańcuchy: input, forward i output; łańcuchy dodatkowe prerouting i forward; ponadto użytkownik może tworzyć własne łańcuchy. Łańcuch jest listą reguł do których po kolei jest porównywany pakiet. Jeśli pakiet pasuje do którejś z reguł, wykonywana jest akcja zdefiniowana wewnatrz tej reguły. Reguły definiujemy właśnie komendą iptables. Jeśli pakiet nie pasuje do żadnej reguły wykonywana jest akcja zdefiniowana w polityce danego łańcucha. Tylko łańcuchy podstawowe i dodatkowe mają własną politykę, łańcuchy utworzone przez użytkownika nie mają własnej polityki, a pakiet po przejściu przez taki łańcuch wraca do łańcucha z którego został wywołany.
Pakiet sprawdzany jest najpierw w łańcuchu PREROUTING. Następnie podjemowana jest decyzja czy pakiet skierowany jest do komputera lokalnego i wtedy przechodzi przez łańcuch INPUT i dociera do procesów lokalnych, czy też do jednej z sieci, do których dany komputer jest ruterem. W takim wypadku podejmowana jest decyzja o rutingu danego pakietu (w uproszczeniu - definiowana karta sieciowa przez którą należy dany pakiet dalej przesłać) i pakiet trafia do łańcucha FORWARD. Pakiety wygenerowane przez procesy lokalne (np. przeglądarkę www wysylającą zapytanie o stronę) przechodzą przez łańcuch OUTPUT. Następnie wszystkie pakiety przechodzą przez łańcuch POSTROUTING i są wysyłane na karty sieciowe.
Podstawowe łąńcuchy należą do tabeli filter. Jest to główna tabela służąca do definiowania reguł filtrowania pakietów. Dodatkowo istnieje tabela nat, w której definiujemy popularną "maskaradę" oraz tabela mangle służąca do zmieniania zawartości pakietów przechodzących przez nasz firewall. Nie wszystkie łańcuchy istnieją w poszczególnych tabelach.
Strona projektu: www.netfilter.org
Podręczniki w sieci:
Jedne z wielu programów mających uczynić konfigurację IPTables wygodniejszą:
Jeśli chcesz postawić serwer proxy potrzebujesz jednego z niżej wymienionych pakietów:
Trusted Information System ( http://www.tis.com) jest fragmentem kolekcji programów zaprojektowanych dla firewalli. Program ten udostępnia podobne rzeczy jak SOCK, ale jest zbudowany na innych zasadach. Tam gdzie Socks posiada jeden program, przeprowadzający wszystkie transakcje z internetem, TIS dostarcza jednego programu dla każdego z narzędzi których chcesz użyć w firrewallu.
Dla pokazania kontrastu użyjmy przykładów WWW i dostępu za pomocą telnetu. Używając SOCKS, ustawiasz jeden plik konfiguracyjny i jednego demona. Używając tego pliku tak telnet jak i WWW są dostępne, podobnie jak inne usługi których nie zakazałeś.
W pakiecie TIS ustawiasz osobno demona dla WWW i Telnetu z osobnymi plikami konfiguracyjnymi. Po zrobieniu tego inne usługi internetowe są zakazane dopóki ich explicite nie ustawisz. Jeśli demon dla specyficznych usług jest niedostępny (tak jak talk), istnieją ,,plug-in-y'' dla demona, ale nie tak elastyczne i łatwe w konfiguracji jak inne narzędzia.
Różnica wygląda na niewielką, jest jednak istotna. SOCKS pozwala Ci być spokojnym. Przy kiepsko ustawionym SOCKS serwerze ktoś z wewnątrz może uzyskać większy dostęp do Internetu niż było początkowo planowane. Z pakietem TIS ludzie wewnątrz sieci mają jedynie taki dostęp na jaki zezwolił administrator.
SOCKS jest łatwiejszy do konfiguracji, łatwiejszy do kompilacji i pozwala na większą elastyczność. TIS jest bardziej bezpieczny, jesli chcesz ustawiać użytkowników wewnątrz chronionej sieci. Oba dostarczają całkowitego bezpieczeństwa z zewnątrz.
Podręczniki w sieci:
Zapory często mają służyć ochronie sieci wewnętrznej, a nie pojedynczego komputera.
Strona związana z tą tematyką:
Bartłomiej Szewczyk -
Zapory
Pozostając w temacie architektury zapór sieciowych, należy wspomnieć o dyskusji na temat wyższości firewalli sprzętowych nad programowymi, bądź jej braku. Pewne światło rzuca na nią artykuł na www.networld.pl. Zawiera on również przegląd oferty firewalli dla przedsiębiorstw.
źródła:
LINUX+ (Styczeń 2005) - Piotr Machej: Bezpieczne łączenie się z Internetem, Vuumur
TELNET FORUM (Marzec 2002) - Piotr Morawski: Sztuka obrony koniecznej
TELNET FORUM (Grudzień 2002) - Radosław Zaraziński : Bezpieczeństwo systemów Unix - Okazja czyni hakera
Karol Krysiak: Sieci Komputerowe - Kompendium
Bezpieczeństwo w systemach komputerowych -
referat
wikipedia.org