Firewalle i proxy serwery Firewalle i proxy serwery Mark Grennan, [e-mail] v0.4, 8 listopad 1996 Wersja polska: Ziemek Borowski [e-mail] v0.1 8 lipiec 1997 Dokument ten powstał w celu uczenia podstaw systemów firewalli oraz dostarczenia niektórych szczegółów w zakresie ustawania (konfigurowania) filtrujących i posredniczacych firwalli na Linuxie. Oryginalna wersja tego dokumentu znajduje się pod adresem: http://okcforum.org/~markg/Firewall-HOWTO.html zaś polskie tłumaczenie: http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html Niniejsza wersja opisuje stan z 1997 roku. Jeśli nadal używasz jąder z serii 2.0 (nie 2.2 lub 2.4) to jest to dokument dla Ciebie. Następna wersja tego dokumentu opisuje ew. poza ipfwadm także ipchains (dostępne z jądrami 2.2) -- zawiera tyle błędów, że należałoby je napisać od nowa. Jeśli szukasz informacji na temat budowania firewalli pod linuksem odsyłam raczej do tłumaczeń dokumentacji IPtables wykonanych przez Łukasza Bromirskiego http://mr0vka.eu.org/. 1. Wprowadzenie Dokument ten Firewall-HOWTO został napisany przez Davida Ruddera mailto:[e-mail]. Chciałbym Mu podziękować za zezwolenie na uaktualnienie jego pracy. Firewalle zyskały ostatnio wielką sławę jako defintywne rozwiązanie w dziedzinie bezpieczeństwa Internetu. Większość tej sławy jest zasłużona, jednak część wynika z nieporozumienia. To JTZ ma na celu przegląd: czym są firewalle, jak je konfigurować, czym są serwery proxy i jak je konfigurować oraz aplikacje (zastosowania) tej technologii poza zakresem bezpieczeństwa. 1.1 Informacja zwrotna, uwagi. Wszelkie uwagi będą mile widziane. Proszę: DONOŚCIE O WSZELKICH NIEŚCISŁOŚCIACH W TYM DOKUMENCIE . Jestem człowiekiem, i jestem omylny. Jeśli znajdziesz jakieś popraw je (w moim najwyższym interesie). Będę próbował odpowiedzieć na wszystkie listy, ale jestem zajętym człowiekiem, tak więc nie obrażaj się proszę jeśli nie odpowiem. Mój adres: [e-mail] 1.2 Deklaracje NIE ODPOWIADAM ZA JAKIEKOLWIEK ZNISZCZENIA WYNIKAJĄCE ZE STOSOWANIA TEGO DOKUMENTU Dokument ten jest pomyślany jako wprowadzenie do technologii firewalli i serwerów proxy. Nie jestem, i nie zamierzam sobie rościć pretensji do bycia ekspertem w sprawach bezpieczeństwa. Jestem po prostu człowiekiem który przeczytał co nieco, i pasjonuje się komputerami bardziej niż inni. Proszę, pisząc ten tekst chcę pomóc ludziom zaznajomić się z tym tematem, i nie jestem gotów dawać głowy za dokładność podawanych przeze mnie danych. 1.3 Copyright Jeśli nie jest powiedziane inaczej, prawa autorskie dokumenty z serii Linux Jak To Zrobić należą do każdego z autorów. Mogą być powielane i rozpowszechniane w w całości w częściach, w formie ,,papierowej'' i elektronicznej dopóki wszędzie (w każdej z części) zachowana jest informacja o prawach i autorstwie. Komercyjna redystrybucja jest dozwolona i wskazana; jednakże, autor powinien być poinformowany o tym fakcie. Wszystkie tłumaczenia, poprawki językowe, i prace włączające muszą zawierać niniejszą notę o prawach autorskich. Jeśli masz jakieś zapytania, proszę o kontakt: Mark Grennan mailto:[e-mail]. 1.4 Moje pobudki do tej pracy. Pomimo wielu dyskusji w grupach comp.os.linux.* (w ciągu ostatniego roku) na temat firewalli wydaje mi się trudnym znalezienie informacji których potrzebowałem do ustawienia i skonfigurowania firewalla. Oryginalna wersja tego HOWto była pomocna, ale nieaktualna. Mam nadzieję, że ta poprawiona wersja ,,Firewall HOWto'' autorstwa Davida Ruddera dostarczy wszystkim informacji jakiej potrzebują do stworzenia działających ,,ścian ognia'' w ciągu godzin, nie tygodni. Poza tym uważam że powinienem zwrócić mój dług społeczności Linuxowej. 1.5 TODO (do zrobienia) Instrukcje na temat ustawień klientów Znalezienie dobrych serwerów proxych dla usług bazujących na UDP działających na Linuxie. 1.6 Zobacz także: NET-3 HOWTO The Multiple Ethernet Mini HOWTO Networking with Linux The PPP HOWTO TCP/IP Network Administrator's Guide by O'Reilly and Associates The Documentation for the TIS Firewall Toolkit Węzeł pajęczyny należący do Trusted Information System's (TIS) posiada wspaniała kolekcję dokumentacji dotyczącej firewalli i pokrewnych tematów. Poza tym pracuję na projektem dotyczącym bezpieczeństwa: ,,Bezpieczny Linux''. W miejscu tym zgromadziłem wszystkie informacje, dokumentacje i programy potrzebne do stworzenia bezpiecznego Linuxa. Napisz do mnie jeśli chcesz otrzymać więcej informacji. 2. Understanding Firewalls Firewall - ,,ściana ogniowa'' jest terminem wziętym z konstrukcji samochodu. W samochodach firewalle fizycznynie oddzielają silnik od pasażerów. To znaczy, że chronią one pasażerów w wypadku gdy silnik zapali się cały czas dostarczając kontroli nad nim. Komputerowe firewalle są urządzeniami, które chronią sieci prywatne od części publicznej (jakiej jak Internet). Komputer będący ,,ścianą ognia'' od tej chwili nazywany ,,firewallem'' może (musi) być obecny tak w sieci chronionej jak i w Internecie. Chroniona sieć nie może być osiągalna z Internetu, podobnie jak Internet nie może być osiągalny z chronionej sieci. Dla niektórych dosięgnięcie Internetu z izolowanej sieci jest możliwe jedynie poprzez zalogowanie się na firewallu (telnetem) i penetracja Sieci stamtąd. Najprostszą formą firewalla jest podwójnie zadomowiony system (tj. system z podwójnym połączeniem sieciowym). Jeśli możesz ZAUFAĆ WSZYSTKIM swoim użytkownikom, możesz prosto skonfigurować Linuxa (wyłączając przy kompilacji jądra forwarding / gatewaying) Mogą oni logować się na tym systemie i używać aplikacji sieciowych takich jak telnet, FTP, czytać pocztę i innych jakich dostarczasz. Z takim ustawieniem, tylko jeden komputer z twojej sieci widzi resztę świata poza firewallem. Pozostałe systemy w twojej chronionej sieci nie potrzebują nawet ustawienia domyślnego routingu. Aby powyższy firewall działał MUSISZ UFAĆ WSZYSTKIM SWOIM UŻYTKOWNIKOM Nie jest to zalecane rozwiązanie. 2.1 Wady firewalli Problemem filtrujących firewalli jest to, że ograniczają dostęp do twojej sieci z Internetu. Tylko usługi na filtrowanie których zezwoliłeś są dostępne. Na serwerach proxych użytkownicy mogą autoryzować się na firewallu i dopiero wtedy mają (z systemu wewnątrz sieci prywatnej) dostęp do Internetu. Poza tym, nowe typy klientów sieciowych i serwerów przybywają prawie codziennie. Musisz wtedy wynaleźć nowy sposób zezwolenia na kontrolowany ich dostęp do twojej sieci, zanim będą użyte. 2.2 Typy firewalli Istnieją dwa typy firewalli: firewalle filtrujące IP - blokują cały ruch, ale przepuszczają dopuszczony. serwery proxy - serwery połączeniowe - wykonują połączenie sieciowe za ciebie. Filtujące firwalle Firewalle filtrujące działają na poziomie pakietów IP. Są zaprojektowane do kontroli przepływu bazując na adresie źródłowym, docelowym, porcie i typie pakietu (zawartych w każdym z pakietów). Ten typ firewalli jest bardzo bezpieczny, ale traci wiele typów zapisu. Może zablokować ludziom z dostęp z sieci prywatnej, ale nie powie, kto dostał się do twojego systemu publicznego, ani kto wyszedł z sieci lokalnej do Internetu. Filtrujące firewalle są bezwzględnymi filtrami. Nawet jeśli chcesz dać komuś z zewnątrz dostęp do twoich serwerów ,,prywatnych'' nie jesteś w stanie bez dania tego dostępu wszystkim (tłum. jak rozumiem spod tego adresu) Linux posiada opcję filtrowania pakietów w jądrach powyżej 1.3.x. Serwery proxy Serwery proxy pozwalają na niebezpośredni dostęp do Internetu, przez firewall. Najlepszym przykładem jak to pracuje jest osoba telnetująca się do systemu i stamtąd wykonująca następne połączenie. Tylko że w wypadku serwerów proxy proces ten następuje automatycznie. Gdy łączysz się z proxy serwerem za pomocą oprogramowania klienckiego startuje on swojego klienta i dostarcza ci danych których zarządzałeś. Ponieważ serwery proxy podwajają każde połączenie, możliwe jest zapisywanie każdego z nich. Wspaniałą rzeczą w serwerach proxy jest to, że są w pełni bezpieczne, gdy są prawidłowo ustawione. Nie pozwalają nikomu przejść. Nie dokonują bezpośredniego routingu. 3. Ustawianie firewalla 3.1 Wymagania sprzętowe. Naszym przykładem nich będzie komputer i486-DX66 z 16 Mb RAMu oraz 500Mb partycją Linuxową. System ten posiada dwie karty sieciowe, jedną połączoną z naszą siecią prywatną, a drugą do sieci lokalnej nazywanej strefą zdemilitaryzowaną (DMZ). DMZ posiada router połączony do Internetu. Jest to całkiem przyjemny standard dla biznesu. Powinieneś użyć jednej karty sieciowej oraz modemu z PPP do intenetu. Firewall powinien posiadać dwa adresy IP. Znam wielu ludzi posiadających małe LANy w domu z dwoma lub trzema komputerami. Możesz rozpatrzyć następujący model: włożyć wszystkie modemy do komputera z Linuxem (np. starą i386) i połączyć wszystkie do Internetu łączem komutowanym. Z takim ustawieniem, gdy tylko jedna osoba ciągnie dane może użyć wszystkich modemów (a więc i działać 2-3 krotnie szybciej ; -). 4. Oprogramowanie dla firewalli 4.1 Dostępne pakiety Jeśli wszystkim czego potrzebujesz jest filtrujący firewall potrzebujesz jedynie Linuxa i podstawowych pakietów sieciowych. Jednym z pakietów który może nie zawierać się w twojej dystrybucji jest IP Firewall Administration tool (przyp. tłum. w RedHacie 4.0 i Debianie 1.2.* jest) (IPFWADM) z http://www.xos.nl/linux/ipfwadm/ Jeśli chcesz postawić serwer proxy potrzebujesz jednego z niżej wymienionych pakietów: SOCKS TIS Firewall Toolkit (FWTK) 4.2 TIS Firewall Toolkit kontra SOCKS 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 s 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 jednego demona dla (osobno) 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 są ł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. Opiszę proces instalacji obydwu. 5. Przygotowanie Linuxa 5.1 Kompilacja jądra. Zacznij od świeżej instalacji twojej dystrybucji Linuxowej (ja użyłem RedHata 3.0.3 (Picasso) i poniższe przykłady bazują na tej dystrybucji). Im mniej oprogramowania zainstalujesz tym mniej będzie w nim dziur, tylnych wejść i / lub błędów wprowadzających do twojego systemu problem bezpieczeństwa, więc zainstaluj jedynie minimalny zestaw aplikacji. Użyj stabilnego jądra. Ja użyłem 2.0.14. Oto jest dokumentacja podstawowych ustawień: Będziesz potrzebował rekompilować jądro sytemu z odpowiednimi opcjami. (patrz Kernel-HOWto, Ethernet-HOWto oraz NET-2 HOWto jeśli nie zrobiłeś tego wcześniej). Oto są sieciowe ustawienia które poznałem wykonując komendę make config Under General setup Turn Networking Support ON Under Networking Options Turn Network firewalls ON Turn TCP/IP Networking ON Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP filtering) Turn IP Firewalling ON Turn IP firewall packet loggin ON (this is not required but it is a good idea) Turn IP: masquerading OFF (I am not covering this subject here.) Turn IP: accounting ON Turn IP: tunneling OFF Turn IP: aliasing OFF Turn IP: PC/TCP compatibility mode OFF Turn IP: Reverse ARP OFF Turn Drop source routed frames ON Under Network device support Turn Network device support ON Turn Dummy net driver support ON Turn Ethernet (10 or 100Mbit) ON Select your network card Teraz możesz dokonać rekompilacji i reinstalacji jądra oraz zrestartować system. Twoja karta/y sieciowa/e powinny pojawić się w trakcie procedury startowej. Jesli tak się nie dzieje sprawdź w innych JTZ, i próbuj dopóki nie będą działać. 5.2 Ustawienie dwóch kart sieciowych Jeśli masz dwie kary sieciowe w swoim komputerze w większości przypadków potrzebujesz dodać twierdzenie w pliku /etc/lilo.conf opisujące ich IRQ i adresy. W moim wypadku wygląda to tak: append= " ether=12,0x300,eth0 ether=15,0x340,eth1 " 5.3 Ustawienie adresów sieciowych Jest to naprawdę interesująca część. Teraz jest czas na podjęcie kilku decyzji. Dopóki nie chcemy dać dostępu komputerom z Internetu do żadnej z części naszej sieci lokalnej nie musimy używać prawdziwych adresów. Istnieją numery wydzielone z internetowych do ustawienia odrębnych sieci prywatnych (przyp. tłumacza: klasa A 10.0.0.0-10.255.255.255, klasy B, i klasy C: 192.168.0.0.0-192.166.255.255) Ponieważ każdy potrzebuje więcej adresów i ponieważ adres nie mogą się powtarzać w Internecie jest to dobry wybór. Wybraliśmy jedną z tych klas: 192.168.2.xxx, i użyjemy jej w naszym przykładzie. Twój serwer proxy będzie członkiem obu sieci i będzie przekazywał dane do i z sieci prywatnej. 199.1.2.10 __________ 192.168.2.1 192.168.2.2 _ __ _ \ | | / ____/__________ | \/ \/ | \| Firewall |/ | Stacja | / Internet \--------| |------------| Robocza | \_/\_/\_/\_/ |__________| |_______________| Jeśli używasz filtrującego firewalla możesz używać tych numerów stosując IP masquearading Firewall będzie przesyłał pakiety i tłumaczył numery IP na ,,PRAWDZIWE'' adresy w Internecie. Musisz przydzielić prawdziwy adres IP karcie sieciowej widocznej z Internetu (na zewnątrz). I przydzielić adres 192.168.2.1 karcie Ethernetowej wewnątrz. To będzie adres IP twojego gatewaya/proxy. Możesz przydzielić pozostałym maszynom ze swojej sieci numery z zakresu 192.168.2.2-192.168.2.254. Odkąd używam RedHat Linux do ustawienia sieci przy starcie dodaję plik ifcfg-eth1 w katalogu /etc/sysconfig/network-scripts/. Jest on czytany w trakcie startu systemu i ustawiania sieci i tablic routingu. Mój ifcfg-eth1 wygląda następująco: #!/bin/sh #>>>Device type: ethernet #>>>Variable declarations: DEVICE=eth1 IPADDR=192.168.2.1 NETMASK=255.255.255.0 NETWORK=192.168.2.0 BROADCAST=192.168.2.255 GATEWAY=199.1.2.10 ONBOOT=yes #>>>End variable declarations Możesz także użyć tego skryptu do automatycznego połączenia modemowego do twojego IPS. Spójrz na skrypt ipup-pop Jeśli używasz modemu do łączenia się z siecią twój zewnętrzny adres będzie przydzielony w trakcie połączenia. 5.4 Testowanie twojej sieci Zacznij od sprawdzenia ifconfig i trasowania (routingu) jeśli masz dwie karty wynik polecenia ifconfig powinien wyglądać następująco: #ifconfig lo Link encap:Local Loopback inet addr:127.0.0.0 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 RX packets:1620 errors:0 dropped:0 overruns:0 TX packets:1620 errors:0 dropped:0 overruns:0 eth0 Link encap:10Mbps Ethernet HWaddr 00:00:09:85:AC:55 inet addr:199.1.2.10 Bcast:199.1.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 TX packets:0 errors:0 dropped:0 overruns:0 Interrupt:12 Base address:0x310 eth1 Link encap:10Mbps Ethernet HWaddr 00:00:09:80:1E:D7 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 TX packets:0 errors:0 dropped:0 overruns:0 Interrupt:15 Base address:0x350 a twoja tablica trasowania mniej więcej tak: #route -n Kernel routing table Destination Gateway Genmask Flags MSS Window Use Iface 199.1.2.0 * 255.255.255.0 U 1500 0 15 eth0 192.168.2.0 * 255.255.255.0 U 1500 0 0 eth1 127.0.0.0 * 255.0.0.0 U 3584 0 2 lo default 199.1.2.10 * UG 1500 0 72 eth0 Uwaga: 199.1.2.0 jest numerem interface po internetowej stronie firewalla zaś 192.168.2.0 jest wewnątrz. Teraz spróbuj pingnąć się do Internetu z firewalla. Ja zwykłem używać nic.dnn.mil jako punktu testowego (w Polsce doradzałbym bilbo.nask.org.pl 148.81.16.51). Jest to wciąż dobry test, ale nie dostarcza tylu informacji ile by się chciało. Jeśli nie rusza za pierwszym razem spróbuj zapukać do innych komputerów poza swoją siecią lokalną. Jeśli nie działa to znaczy że twoje połączenie PPP jest źle ustawione. Przeczytaj jeszcze raz Net-2 HOWto i spróbuj jeszcze raz. Następnie pingnij się z firewalla do komputera wewnątrz chronionej sieci. Każdy komputer powinien móc sondować inny. Jeśli nie spójrz jeszcze raz do Net-2 HOWto i popraw ustawienia w swojej sieci. Teraz spróbuj pingnąć zewnętrzny adres z wewnętrznej części chronionej sieci. (Notka: to nie jest żaden z numerów IP zaczynających się od: 192.168.2.xxx.) Jeśli jest to możliwe, to znaczy że nie wyłączyłeś przesyłania IP w konfiguracji jądra. Upewnij się, że tego chcesz. Jeśli zostawisz tę opcję włączoną, musisz zapoznać się z częścią tego dokumentu opisującą filtrowanie pakietów IP. Teraz spróbuj sondować internet zza swojego firewalla. Użyj tego samego adresu co poprzednio (np. bilbo.nask.org.pl). Znowu, jeśli wyłączyłeś IP Forwarding nie powinno działać. Albo powinno, jeśli włączyłeś. Jeśli masz ustawiony IP Forwarding i używasz ,,PRAWDZIWYCH'' (nie 192.168.2.*) adresów IP i nie możesz wyjść na zewnątrz, ale możesz się dostać do internetowej strony swego firewalla sprawdź czy następny router przepuszcza pakiety z twojej sieci lokalnej (twój dostawca usług internetowych powinien coś o tym wiedzieć). Jeśli przydzieliłeś swojej sieci adresy 192.168.2.* pakiety i tak nie będą filtrowane. Jeśli przechodzą mimo wszystko i masz IP masquerading włączone ten test też został zdany. Masz teraz podstawową konfigurację systemu. 5.5 Zabezpieczanie firewalla. Firewall nie spełnia swojego zadania jeśli zostawia otwarte okno dla ataków przez nieużywane usługi. ,,Źli chłopcy'' mogą zdobyć twierdzę i zmodyfikować ją dla swoich potrzeb. Zacznij wyłączać niepotrzebne usługi. Spójrz na /etc/inetd.conf. Plik ten kontroluje coś co jest nazywane ,,super serwerem''. Kontroluje uruchamianie usług na żądanie. Kompletnie wyłącz: netstat, systat, tftp, bootp oraz finger. Aby wyłączyć usługę wystarczy postawić znak # (tzw. hash) jako pierwszy znak w linii. kiedy to zrobisz wyślij sygnał HUP do procesu inetd pisząc: " kill -HUP < pid > " , gdzie < pid > jest numerem procesu inetd. Spowoduje to powtórne przeczytanie przez inetd pliku konfiguracyjnego (inetd.conf) i restart. Sprawdź teraz czy jesteś w stanie dostać się do portu obsługującego netstat telnet localhost 15 Jeśli otrzymasz wynik z netstata nie zrestartowałeś inetd prawidłowo. 6. Konfigurowanie filtrowania IP (IPFWADM) By zacząć musisz włączyć przesyłanie pakietów IP w swoim jądrze i twój system powinien odsyłać wszystko co mu się prześle. Twoja tablica trasowania powinna być ustawiona i powinieneś miś dostęp tak wewnątrz jak do zewnętrznej Sieci. Ale budujemy firwalla tak więc trzeba ograniczyć wszystkim dostęp do niego. W moim systemie stworzyłem parę skryptów ustawiających zasady odsyłania pakietów i polityki dostępu. Wywołuję je z w skryptach z /etc/rc.d w czasie konfiguracji. Domyślnie IP Forwarding w jądrze systemu odsyła wszystko. Dlatego twoje skrypty startowe firewalla powinny rozpoczynać swoja pracę od zakazania dostępu dla wszystkich i zerwania wszelkich połączeń dozwolonych w poprzednim uruchomieniu ipfw. Skrypt ten wykorzystuje pewien trick. # # Ustawianie rozliczania i odsyłania pakietów IP # # Forwarding # # Domyślnie wszystkie usługi są zakazane. ipfwadm -F -p deny # Zerwij wszystkie połączenia ipfwadm -F -f ipfwadm -I -f ipfwadm -O -f Teraz mamy doskonały firewall. Nic nie przechodzi. Bez wątpliwości pewna cześć usług powinna być przesyłana (i tego dotyczy następny przykład). # przesyłanie poczty do twojego MTA ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25 # przesyłanie połączeń pocztowych do innych MTA ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0 1024:65535 # przesyłanie WWW do twojego serwera /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80 # przesyłanie WWW do serwerów zewnętrznych /sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0 1024:65535 # przesyłanie ruchu DNS /sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 196.1.2.0/24 Możesz byc zaintersowany w rozliczaniu ruchu przechodzącego przez twój firewall. Poniższy skrypt liczy każdy z pakietów. Powinieneś dodać linię albo liczyć ruch tylko dla jednego systemu. # Zerwanie wszystkich połączeń ipfwadm -A -f # Rozliczanie /sbin/ipfwadm -A -f /sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24 /sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24 Jeśli potrzebowałeś firewalla filtrującego możesz skończyć lekturę. Miłego konfigurowania. ; -) 7. Instalowania serwera proxy - TIS 7.1 Pobranie oprogramowania TIS FWTK jest dostępny pod adresem: ftp://ftp.tis.com/. Nie popełnij tego błędu co ja. Kiedy dostaniesz się na serwer TIS PRZECZYTAJ ,,README'' Pakiet TIS fwtk jest w ukrytym katalogu na ich serwerze. TIS wymaga być wysłał email do [e-mail] zawierającego tylko słowo SEND w ,,ciele'' wiadomości aby poznać nazwę tego ukrytego katalogu (nie jest potrzebny temat dla tego listu). Ich system wyśle Ci wiadomość z nazwą katalogu w ciągu 12 godzin. Piszę o wersji 2.0 (beta) TIS FWTK. Wersja ta kompiluje się dobrze (z pewnymi wyjątkami) i wygląda że wszystko pracuje (u mnie). Gdy zostanie opublikowana wersja pełna uaktualnię to HowTo. Aby zainstalować FWTK stwórz katalog fwtk-2.0 w /usr/src. Przenieś tak kopię (fwtk-2.0.tar.gz) odpakuj ją (tar zxf fwtk-2.0.tar.gz). FWTK nie pośredniczy w przekazywaniu SSL (bezpieczne dokumenty w WWW) ale posiada dodatek napisany przez Jean-Christophe Touvet. Jest on dostępny pod adresem ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z. Touvet nie świadczy wsparcia technicznego dla tego kodu. Używam zmodyfikowanej wersji: włączyłem moduł dostępu do bezpiecznych serwerów news Netscape napisany przez Eric Wedel ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z. W naszych przykładach będę używał wersji Wedel'a. Aby go zainstalować po prostu strwóż katalog ssl-gw w katalogu /usr/src/fwtk-2.0 i wsadź tam odpowiednie pliki. Kiedy instalowałem tę bramę potrzebne były drobne zmiany zanim mogłem skompilować resztę zestawu. Pierwsza zmiana nastąpiła w pliku ssl-gw.c . Nie potrafił włączyć jednego z plików include. #if defined(__linux) #include <sys/ioctl.h> #endif Druga zmiana polegała na stworzeniu pliku Makefile. Skopiowałem jeden z innej ,,bramy'' i zastąpiłem nazwę tego modułu nazwą ssl-gw. 7.2 Kompilacja TIS FWTK Wersja 2.0 FWTK kompiluje się łatwiej niż poprzednie. Wciąż jednak jest kilka rzeczy które powinny być zmienione zanim wersja beta będzie się kompilować bez przeszkód. Pozostaje mieć nadzieję, że do tak się stanie w pełnej wersji. Aby to poprawić zacznij zmiany od katalogu /usr/src/fwtk/fwtk i skopiuj plik Makefile.config.linux na Makefile.config. Nie uruchamiaj FIXMAKE. Instrukcja mówi byś to zrobił. Jeśli chcesz zniszczyć Makefile we wszystkich podkatalogach... Wykonałem poprawkę do fixmake Problem polegał na tym, że fixmake dodawał '.' i '' do włączanych do Makefile linii. sed 's/^include[ ]*\([^ ].*\)/include \1/' $name .proto > $name Następnie będziemy musieli wyedytować Makeconfig.file. Potrzebne będą dwie zmiany. Autor programu ustawił źródła programu w swoim $HOME/. My kompilujemy w /usr/src i powinniśmy zmienić zmienną FWTKSRCDIR. FWTKSRCDIR=/usr/src/fwtk/fwtk Po drugie, przynajmniej niektóre Linuxy używają bazy danych w formacie gdbm. W Makefile.config jest używana dbm Zapewne będziesz musiał to zmienić. Ja w RedHacie 3.0.3 musiałem. DBMLIB=-lgdbm Ostania poprawka jest w katalogu x-gw. Błąd w wersji beta jest w pliku socket.c. Poprawka polega na usunięciu tych linii. #ifdef SCM_RIGHTS /* 4.3BSD Reno and later */ + sizeof(un_name->sun_len) + 1 #endif Jeśli dodałeś ssl-gw do swojego katalogu źródeł trzeba jeszcze dodać do listy katalogów w Makefile. DIRS= smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw x-gw ssl-gw Teraz uruchom make. 7.3 Instalacja TIS FWTK Uruchom make install. Standardowo katalogiem instalacyjnym jest /usr/local/etc. Możesz to zmienić (ja tego nie zrobiłem) na bardziej bezpieczny katalog. Ja zmieniłem prawa dostępu do niego na chmod 700 . Na koniec pozostała nam konfiguracja firewalla. 7.4 Konfiguracja firewalla TIS FWTK Teraz naprawdę rozpoczynamy. Musisz nauczyć system wywoływania tych nowych usług i stworzyć tablice do ich kontroli. Nie próbuję przepisywać tutaj dokumentacji do TIS FWTK. Chcę pokazać takie ustawienia jakie u mnie działały i wyjaśnić problemy jakie spotkałem. Istnieją trzy pliki kontrolujące firewalla. /etc/services mówiący systemowi jaki port obsługuje jaką usługę. /etc/inetd.conf mówiący serwerowi inetd jaki program wywołać gdy ktoś będzie się dobijał do zadanego portu. /usr/local/etc/netperm-table mówiący FWTK kto jest dopuszczony a kogo winno się odrzucać przy danej usłudze. Aby uzyskać poprawne funkcjonowanie FWTK powinieneś wyedytować te pliki poczynając od góry. Edycja jedynie services bez inetd.conf i netperm-table ustawionych prawidłowo uczyni twój system niedostępnym. Plik netperm-table Plik ten odpowiada za kontrolę kto ma dostęp do usług nadzorowanych przez TIS FWTK. Powinieneś myśleć o ruch z obu stron firewalla. Ludzie z zewnątrz twojej sieci powinni zidentyfikować się przed otrzymaniem dostępu, ale ludzie z wewnątrz mogą zostać dopuszczeni od razu. Aby ludzie moli się zidentyfikować firewall używa programu o nazwie authsrv do trzymania bazy danych o użytkownikach i ich hasłach. Sekcja dotycząca autentyfikacji w netperm-table pozwala kontrolować gdzie jest trzymana baza danych i kto ma do niej dostęp. Miałem trochę kłopotów z blokowaniem dostępu do usług. Weź pod uwagę że linia którą pokazuję używa '*' do dawania dostępu dla każdego do tej usługi. Prawidłowe ustawienie tej linii jest następujące: '' authsrv: premit-hosts localhost jeśli chcesz zachować ją pracującą. # # tablica konfiguracji serwera proxy # # Autentyfikacja: reguły serwera i klienta authsrv: database /usr/local/etc/fw-authdb authsrv: permit-hosts * authsrv: badsleep 1200 authsrv: nobogus true # Aplikacje klienckie używające serwera autentyfikacji *: authserver 127.0.0.1 114 Aby zaincjalizować bazę danych wykonaj su do root`a i uruchom ./authsrv w katalogu /var/local/etc by stworzyć rekord opisujący administratora systemu. Oto jest przykładowa sesja. Przeczytaj dokumentację FWTK, by dowiedzieć się jak dodać użytkowników i grupy. # # authsrv authsrv# list authsrv# adduser admin " Auth DB admin " ok - user added initially disabled authsrv# ena admin enabled authsrv# proto admin pass changed authsrv# pass admin " plugh " Password changed. authsrv# superwiz admin set wizard authsrv# list Report for users in database user group longname ok? proto last ------ ------ ------------------ ----- ------ ----- admin Auth DB admin ena passw never authsrv# display admin Report for user admin (Auth DB admin) Authentication protocol: password Flags: WIZARD authsrv# ^D EOT # Kontrola przez bramę telnetu (tn-gw) polega na prostym przesłaniu i jest to pierwsza którą powinieneś ustawić. W moim przykładzie pozwoliłem komputerom z wnętrza sieci prywatnej na dostęp bez autentyfikacji (permit-hosts 19961.2.* -passok). Ale inni użytkownicy powinni wprowadzić swoją nazwę użytkownika i hasło. (permit-hosts * -auth) Poza tym pozwoliłem jednemu innemu systemowi (196.1.2.202) na dostęp do firewalla bezpośrednio, bez przechodzenia przez procedury na nim. Sprawiają to dwie linie z inetacl-in.telnetd Wyjaśnię ich działanie potem. Powinieneś zachować krótki czas timeoutu. # reguły dostępu telnetu do firewalla: tn-gw: denial-msg /usr/local/etc/tn-deny.txt tn-gw: welcome-msg /usr/local/etc/tn-welcome.txt tn-gw: help-msg /usr/local/etc/tn-help.txt tn-gw: timeout 90 tn-gw: permit-hosts 196.1.2.* -passok -xok tn-gw: permit-hosts * -auth # Tylko administrator może wykonać telnet na port 24 firewalla. netacl-in.telnetd: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd I to samo z r-command. # reguły dostępu rlogin do firewalla rlogin-gw: denial-msg /usr/local/etc/rlogin-deny.txt rlogin-gw: welcome-msg /usr/local/etc/rlogin-welcome.txt rlogin-gw: help-msg /usr/local/etc/rlogin-help.txt rlogin-gw: timeout 90 rlogin-gw: permit-hosts 196.1.2.* -passok -xok rlogin-gw: permit-hosts * -auth -xok # Tylko administrator może wykonać telnet na port 24 firewalla. netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind -a Nie powinieneś dawać nikomu bezpośredniego dostępu do firewalla, włączając w to dostęp prze FTP (tak pobieranie jak i wkładanie). Jeszcze raz, linie zawierające permit-hosts pozwalają każdemu w chronionej na wolny dostęp do Internetu, zaś wszyscy inni muszą się autentyfikować. Włączyłem zapisywanie każdego pliku pobranego i wysłanego do mojej konfiguracji. (-log { retr stor }) Timeouty FTP dają ci kontrolę nad tym jak długo będą utrzymywane ,,złe'' połączenia i jak długo będą utrzymywane połączenia bez żadnej aktywności. # reguły dostępu ftp do firewalla ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt ftp-gw: help-msg /usr/local/etc/ftp-help.txt ftp-gw: timeout 300 ftp-gw: permit-hosts 196.1.2.* -log { retr stor } ftp-gw: permit-hosts * -authall -log { retr stor } WWW, Gopher i bazujące na przeglądarkach FTP jest kontrolowane przez http-gw. Pierwsze dwie linie tworzą katalog gdzie będą składowane pliki i dokumenty z FTP i WWW. Przy czym są one własnością root`a i są składowane w katalogu dostępnym tylko dla niego. Połączenia WWW powinny być bardzo krótki. W ten sposób można kontrolować jak długo użytkownicy będą utrzymywać błędne połączenia. # reguły dostępu dla WWW i Gophera http-gw: userid root http-gw: directory /jail http-gw: timeout 90 http-gw: default-httpd www.afs.net http-gw: hosts 196.1.2.* -log { read write ftp } http-gw: deny-hosts * ssl-gw ustawia się tak samo ja i inne bramy. Bądź z nią ostrożny. W tym przykładzie pozwalam wszystkim z sieci chronionej na łączenie się z każdym z serwerów na zewnątrz z wyjątkiem adresów 127.0.0.* i 192.1.1.* oraz (wtedy) na otwieranie portów 443 do 563 używanych jako znane porty dla SSL. # zasady dla bramy ssl: ssl-gw: timeout 300 ssl-gw: hosts 196.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 } ssl-gw: deny-hosts * Poniżej znajduje się przykład jak użyć plug-gw aby pozwolić na połączenie do serwera news. W tym przykładzie zezwalam każdemu z sieci lokalnej na dostęp do tylko jednego systemu i tylko na porcie zajętym przez news. W drugiej linii pozwalam serwerowi news przesłać dane z powrotem do chronionej sieci. Ponieważ większość klientów spodziewa się, że pozostaje podłączenie w czasie gdy użytkownik czyta wiadomości timeout dla news powinien być długi. # brama dla modułu plug-gw i NetNews plug-gw: timeout 3600 plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp Brama dla fingera jest prosta. Każdy z chronionej sieci powinien się załogować i wtedy pozwalamy mu na użycie fingera na firewallu. Pozostali nie po prostu dostają wiadomość. # uruchomienie usługi finger netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt Nie mam ustawionych usług dla poczty elektronicznej i X-Windows więc nie daję przykładów. Jeśli ktoś ma działający przykład, proszę o przysłanie mi. Plik inetd.conf Oto jest kompletny plik /etc/inetd.conf . Wszystkie niepotrzebne usługi zostały wykomentowane. Włączyłem pełny plik aby pokazać co wyłączyć i jak ustawić nową usługę w ścianie ognia. {od tłumacza: nie przekładam typowych dla tego pliku linii} #echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal # brama FTP w ścianie ognia ftp-gw stream tcp nowait.400 root /usr/local/etc/ftp-gw ftp-gw # brama Telnetu w ścianie ognia telnet stream tcp nowait root /usr/local/etc/tn-gw /usr/local/etc/tn-gw # local telnet services telnet-a stream tcp nowait root /usr/local/etc/netacl in.telnetd # brama Gophera w ścianie ognia gopher stream tcp nowait.400 root /usr/local/etc/http-gw /usr/local/etc/http-gw # brama WWW w ścianie ognia http stream tcp nowait.400 root /usr/local/etc/http-gw /usr/local/etc/http-gw # SSL w ścianie ognia ssl-gw stream tcp nowait root /usr/local/etc/ssl-gw ssl-gw # NetNews firewall proxy (using plug-gw) nntp stream tcp nowait root /usr/local/etc/plug-gw plug-gw nntp #nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd # SMTP (email) w ścianie ognia #smtp stream tcp nowait root /usr/local/etc/smap smap # # Shell, login, exec and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd #talk dgram udp wait root /usr/sbin/tcpd in.talkd #ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd #dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd # # Pop and imap mail services et al # #pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d #pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d #imap stream tcp nowait root /usr/sbin/tcpd imapd # # The Internet UUCP service. # #uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l # # Tftp service is provided primarily for booting. Most sites # run this only on machines acting as " boot servers. " Do not uncomment # this unless you *need* it. # #tftp dgram udp wait root /usr/sbin/tcpd in.tftpd #bootps dgram udp wait root /usr/sbin/tcpd bootpd # # Finger, systat and netstat give out user information which may be # valuable to potential "system crackers." Many sites choose to disable # some or all of these services to improve security. # # cfinger is for GNU finger, which is currently not in use in RHS Linux # finger stream tcp nowait root /usr/sbin/tcpd in.fingerd #cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd #systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx #netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet # # Time service is used for clock syncronization. # #time stream tcp nowait root /usr/sbin/tcpd in.timed #time dgram udp wait root /usr/sbin/tcpd in.timed # # Authentication # auth stream tcp wait root /usr/sbin/tcpd in.identd -w -t120 authsrv stream tcp nowait root /usr/local/etc/authsrv authsrv # # End of inetd.conf Plik /etc/services Tutaj się wszystko zaczyna. Gdy klient łączy się ze ścianą ognia dzieje się to na tzw. dobrze znanym porcie (niższym od 1024). Na przykład telnet łączy się na porcie 23. Serwer inetd słyszy prośbę o połączenie, i szuka nazwy tej usługi w /etc/services. Później wzywa programy wyznaczony dla tej usługi w /etc/inedt.conf Niektóre z usług nie są normalnie tworzone przez wywołanie w /etc/serwices. Można przydzielać niektóre porty jak chcemy, Na przykład ja przydziałem usłudze ,,telnet administratora'' (telnet-a) port 24. Ty możesz przydzielić tę usługę na portowi 2323, jeśli chcesz. Dla administratora (CIEBIE) bezpośrednie połączenie ze ścianą ognia na porcie 24 nie 23 noże być potrzebne, jeśli masz ustawioną swoją chronionej sieci. telnet-a 24/tcp ftp-gw 21/tcp # this named changed auth 113/tcp ident # User Verification ssl-gw 443/tcp 8. Serwer proxy SOCKS 8.1 Konfigurowanie serwera Proxy SOCKS proxy server dostępny jest z adresu: ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz. Zawiera przykładowy plik konfiguracyjny w katalogu nazwanym: " socks-conf " . Zdekompresuj i untaruj te pliki w dowolnym katalogu i postępuj według instrukcji. Miałem kilka problemów kiedy kompilowałem go. Upewnij się, że twój Makefile jest prawidłowy. Jedną z ważniejszych rzeczy jest pamiętanie o konieczności dodania serwera proxy do /etc/inetd.conf. Aby móc odpowiedzieć na żądania musisz dopisać następującą linię: socks stream tcp nowait nobody /usr/local/etc/sockd sockd 8.2 Konfiguracja serwera proxy Program SOCKS potrzebuje dwóch oddzielnych plików konfiguracyjnych. Jeden z nich mówi tym komu udzielić dostępu a drugi w jaki sposób przekazywać żądania do właściwego serwera proxy. Plik decydujący o dostępie powinien znajdować się na serwerze. Plik dotyczący przekazywania dostępu (routingu) powinien znajdować się na każdej z maszyn Unixowych. W wypadku DOSa i częściowo MaCów komputery powinny mieć swój własny routing. Plik dostępu.Access File W wersji 4.2 Beta SOCSKsów plik dostępu nazywa się " sockd.conf " . powinien zawierać dwie linie: zezwolenia i zakazu. Każda z linii posiada trzy pozycje: identyfikator (permit/deny) adres IP modyfikator adresu Identyfikator to permit lub deny Powinieneś użyć obu: każdy we właściwej linii. Adres IP powinien zawierać czterobajtowy adres w typowej dal IP notacji. np. 192.168.2.0. Modyfikator adresu także jest normalnym IP i pracuje jak maska. Rozwinięcie tego adresu da 32 bity (1 albo zero). Na przykład, w tej linii: permit 192.168.2.23 255.255.255.255 zezwalam na dostęp maszynom w których adres pasuje co do bitu z zadanym: pasuje tu tylko 192.168.2.23 permit 192.168.2.0 255.255.255.0 zezwala na dostęp maszynom z gdyby od 192.168.2.0 do 192.168.2.255, w formie całej klasy C. Nie powinieneś mieć następującej linii: permit 192.168.2.0 0.0.0.0 dającej dostęp dla wszystkich adresów. Tak więc pierwsza linia daje zezwolenie dla tych adresów którym chcesz go dać, a druga zakazuje reszcie. Aby zezwolić na dostęp wszystkim z klasy 192.168.2.xxx potrzeba linii: permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 Zwróć uwagę na pierwsze " 0.0.0.0 " w linii zakazu. Z maską 0.0.0.0 taki adres nie istnieje. Wszystkie zera zostały tam wprowadzone bo są łatwe do zapisu. Dopuszczalne jest umieszczenie większej ilości jeden zapisów w każdej z linii. Konkretni użytkownicy mogą ponadto otrzymać lub tracić prawo dostępu. jest to wykonywane przy pomocy autentyfikacji przy pomocy ident. Nie wszystkie systemu używają ident, włączając w to Trumpet Winsock , dlatego też nie włączam tu przykładów. Dokumentacja do SOCKS jest całkiem dobra w tej kwestii. Tablica trasowania Tablica routingu w SOCS jest niestety nazywana socks.conf. Tablica routingu mówi klientom SOCKS kiedy używać socks a kiedy nie. Na przykład, w twojej sieci 192.168.2.3 nie potrzebuje używania socks do połączenia z 192.168.2.1. Po prostu łączy się bezpośrednio, po Ethernecie. Definiuje się automatycznie 127.0.0.1 jako loopback. Oczywiste jest, że nie potrzebujesz rozmawiać przez ścianę ogniową z samym sobą... Są trzy typy rekordów: deny direct sockd Deny mówi SOCKS kiedy ma odmówić żądaniu. Rekord ten ma takie same trzy pola jak sockd.conf: identyfikator, adres i maska. Ogólnie, dopóki jest to modyfikowane przez sockd.conf, maska w pliku dostępu jest ustawiona na 0.0.0.0. Jeśli chcesz pozwolić na dzwonienie do siebie możesz to zrobić tutaj. Rekord direct mówi które do których adresów nie używać SOCKS. Te adresy będą doręczone bez serwera proxy. Jeszcze raz, mamy trzy pola: identyfikator, adres i maska. direct 192.168.2.0 255.255.255.0 W ten sposób kierujesz bezpośrednio cały ruch w chronionej sieci. Rekord z sockd mówi komputerowi które z hostów są serwerem SOCKS Składnia jest następująca: sockd @=<serverlist> <IP address> <modifier> Zwróć uwagę na fragment: @= . Pozwala on na wprowadzenie listy serwerów proxy. W naszym przykładzie używamy tylko jednego. Ale możesz mieć wiele w celu zwiększenia przepustowości i obniżenia możliwości awarii. Pola adresu IP i maski działają jak w innych przykładach. Specyfikujesz adres i zakres jego obowiązywania. DNS zza firewalla Ustawienie usługi DNS zza firewalla jest prostymzadaniem. Potrzeba jedynie ustawienia DNS na maszynie z firewallem.I inne maszyny za firewallem będą go używały. 8.3 Współpraca z serwerami proxy Unix Aby twoje aplikacje działały z serwerami proxy potrzebujesz je zsockisy... ( " sockified " ). Będziesz potrzebował dwóch różnych telnetów (jeden do komunikacji bezpośredniej drugi przez serwer proxy). SOCKS przychodzą z instrukcją jak zSOCKifikować program, i z paroma programami przygotowanymi na tę modłę. Jeśli używasz zSOCKIfowanej wersji gdziekolwiek bezpośrednio SOCKS automatycznie przełączy cię na właściwą wersję. Z tego powodu trzeba zmienić nazwy wszystkich programów w naszej chronionej sieci i zstąpić je wersjami zSOCKisowanymi. Finger stanie się finger.orig, telnet stanie się telnet.orig i tak dalej. Musisz powiedzieć SOCKS o każdym w pliku include/socks.h. Dobre programy są w stanie dostarczać tablic trasowania i zsocksifikować się same. Jednym z nich jest Netscape Navigator. Możesz używać serwerów proxy przez wprowadzenie adresu serwera (192.168.2.1 w naszym wypadku) w polu SOCKs w Menu Proxies. Każda aplikacja potrzebuje przynajmniej minimalnej informacji o tym co jest serwerem proxy. MS Windows i Trumpet Winsock Trumpet Winsock przychodzi z wbudowanymi możliwościami współpracy z serwerem proxy. W setup menu wprowadź adres serwera, i adresy komputerów dostępnych bezpośrednio. Program przekieruje na serwer wszystkie pakiety mające wyjść na zewnątrz. Ustawienie serwera pośredniczącego do pracy z pakietami UDP. Pakiet SOCKS pracuje jedynie z pakietami TCP, pomijając UDP. Powoduje to trochę mniejszą jego użyteczność. Wiele użytecznych programów, takich jak na przykład talk i Archie używa UDP. Jest jednak pakiet który może być użyty jako serwer proxy dla UDP: UDPrelay stworzony przez Toma Fitzgeralda [e-mail]. Niestety w chwili pisania tego tekstu nie jest on zgodny z Linuxem. 8.4 Wady serwerów proxych Serwer proxy, jak pokazałem powyżej jest narzędziem bezpieczeństwa. Używanie go zwiększa dostępność do Internetu z ograniczoną liczbą adresów wiąże się jednak z wieloma niedogodnościami. Serwer proxy pozwala na większą dostępność internetu z sieci chronionej, ale pozostawia wnętrze całkowicie niedostępne z zewnątrz. Oznacza to brak możliwości uruchomienia wewnątrz sieci rozmaitych serwerów, talk i archie, oraz bezpośredniego wysyłania listów do chronionej sieci. Poniższe uchybienia wyglądają nieznacząca, ale sposób myślenia przebiega następująco: Otrzymałeś informację o błędach w twojej chronionej sieci. Jesteś w domu, i decydujesz się sprawdzić to. Ale nie możesz. Nie jesteś w stanie dostać się do żadnego z komputerów ponieważ znajdują się za ścianą ogniową. Twoja córka poszła do college`u. Chciałbyś wysłać jej list. Chcesz z nią porozmawiać o pewnych prywatnych sprawach, i wolałbyś raczej by twoja poczta była kierowana bezpośrednio na twój komputer. Ufasz swojemu administratorowi, ale to jednak prywatna poczta. Niemożliwość użycia usług działających z UDP jest wielką wadą serwerów proxych. Choć mam nadzieję, że już niedługo. Przypadek FTP pokazuje jeszcze jeden problem z serwerami proxymi. Kiedy pobieram pliki lub wydaję komendę ls, serwer FTP otwiera gniazdo (,,socket'') na maszynie klienckiej i wysyła o tym informację. Serwer proxy nie pozwala na to, tak więc FTP nie działa w sposób prawidłowy. Poza tym serwery pośredniczące działają powoli. Z powodu większej wydajności większość innych metod dostępu do Internetu będzie szybsza. Jeśli masz przydzielony adres IP, i nie martwisz się o bezpieczeństwo, nie używaj ścian ogniowych i/lub serwerów proxych. Jeśli nie masz nr. IP, i także nie martwisz się o bezpieczeństwo swojej sieci, możesz użyć jednego z ,,emulatorów IP'' takich jak Term, Slirp lub TIA. Term jest dostępny z ftp://sunsite.unc.edu/, Slirp z ftp://blitzen.canberra.edu.au/pub/slirp, zaś TIA z http://markertplace.com/. Pakiety te pracują szybciej, pozwalają na szybsze połączenia i na większy dostęp z sieci wewnętrznej do internetu. Serwery pośredniczące są dobre dla tych który mają duże sieci z komputerami mającymi mieć dostęp ,,w locie'' do internetu z jednorazowym ustawieniem, i minimalnym wkładem pracy potem. 9. Konfiguracja zaawansowana. Przedstawiłem jedną konfigurację, którą wypróbowałem przez stworzeniem tego dokumentu. Przy czym ten zarys powinien wystarczyć dla większości ludzi. Myślę że poniższy opis zaawansowanych konfiguracji może rozwiać pozostałe wątpliwości. Jeśli oprócz tego masz jeszcze jakieś pytania poza tym co opisałem, albo cię to po prostu interesują cię szczegóły związane ze firewallami i serwerami proxy możesz przeczytać poniższy fragment. 9.1 Wielkie sieci wymagają położenia nacisku na bezpieczeństwo Powiedzmy, na przykład, że jesteś szefem milicji obywatelskiej i chcesz ,,usieciowć'' swoją siedzibę. Masz pięćdziesiąt komputerów i 32 nr IP (5 bitów). Potrzebujesz możliwości dania różnych poziomów dostępu do sieci ponieważ powierzasz swoim współpracownikom różne zadania. Poza tym będziesz potrzebował izolacji określonych miejsc w sieci od reszty. Poziomy dostępu: Poziom zewnętrzny - ukazywany wszystkim, tutaj werbujesz i zdobywasz nowych ochotników. Troop poziom ten przeznaczony jest dla ludzi którzy otrzymali dostęp z poziomu zewnętrznego. Tutaj jest miejsce gdzie uczysz o rządzie dusz i jak zrobić bombę. Mercenary Tutaj jest miejsce gdzie naprawdę planujesz chronić. Tutaj składujesz wszelkie informacje o tym jak rządy trzeciego świata zamierzają podbić świat, twoje plany dla Newt Gingich, Oklahoma City, składujesz tajne informacje. Konfiguracja sieci Numery IP są ustawione w następujący sposób: 1 numer to 192.168.2.255, będący adresem rozgłoszeniowym nie używanym 23 z 32 adresów IP jest przydzielonych dla maszyn dostępnych w Internecie. 1 dodatkowy adres IP został przydzielony Linuxowi 1 dodatkowy adres IP został przydzielony innemu linuxowi 2 numery IP zostały przydzielone routerowi 4 pozostałe pozostają odłączone ale otrzymują nazwy domenowe: paul, ringo, john, george . chroniona sieć ma numer 192.168.2.xxx Teraz budujemy dwie izolowane sieci, każda w innym pokoju. Są one trasowane przez ekranowany ethernet i są kompletnie niewidoczne z innych pomieszczeń. Na szczęście ekranowany Ethernet zachowuje się tak samo jak zwyczajny ethernet. Każda z tych sieci jest połączona do jednej ze stacji linuxowych na dodatkowych adresach IP. Są to serwery plików połączone do obu chronionych sieci. Jest tak, ponieważ planujemy dać dostęp tak dla sieci Troops ja i wyższej. Serwer plików nosi numery 192.168.2.17 dla sieci Troop i 192.168.2.23 dla sieci Mercenary. Mają różne adresy ponieważ mają dwie różne karty sieciowe. network. IP Forwarding jest wyłączony. IP Forwarding na obu stacjach linuxowych także jest wyłączony. Router nie powinien przesyłać pakietów przeznaczonych dla sieci 192.168.2.xxx dopóki mu tego wprost nie powiemy, tak więc dostęp do internetu pozostaje wyłączony. Wyłączenie przesyłania IP ma na celu zablokowanie połączeń z sieci Troop do sieci Mercenary na odwrót. Serwer NFS może ponadto oferować różne pliki dla różnych sieci. To łatwe przy drobnych operacjach z symbolicznymi odniesieniami można zrobić w ten sposób że wspólne pliki są dzielone przez wszystkich. Użycie tego typu ustawień i różnych kart sieciowych umożliwia Ci zastosowanie jednego serwera plików dla trzech sieci. Serwer proxy Teraz, dopóki wszystkie trzy poziomu będą możliwe do pracy w ramach wyznaczonych zadań będą potrzebowały dostępu do sieci. Zewnętrzna sieć jest połączona bezpośrednio z internetem, tak więc nie ma tu zastosowania dla serwera pośredniczącego. Sieci Mercenary i Troop znajdują się za ścianą ogniową więc potrzebny im serwer proxy. Konfiguracja obu jest bardzo podobna. Oba mają takie same adresu IP. Jedyna różnica polega na nieco innych parametrach. Nie każdy może użyć serwera plików dla dostępu do Interntu. Wystawia to go na wirusy i inne brzydkie rzeczu. Nie chcemy zezwolić sieci Troop na dostęp do WWW. Przechodzą szkolenie I jaki kolwiek przepły informacji mógłby zniszczyć jego efekty. Tak więc w pliku sockd.conf w linuxie w sieci Troop znajdzie się następująca linia. deny 192.168.2.17 255.255.255.255 a w stacji przeznaczonej dla Mercenary: deny 192.168.2.23 255.255.255.255 Teraz w stacji linuxowej sieci Troop wpisujemy: deny 0.0.0.0 0.0.0.0 eq 80 Ten tekst mówi że zabraniamy dostępu wszystkich maszynom próbującym się dostać do portu równego (eq) 80 (http). Nadal pozwala się na dostęp do wszystkich usług z wyjątkiem WWW. Teraz oba pliki powinny zawierać linie: permit 192.168.2.0 255.255.255.0 by zezwolić wszystkim komputerom z sieci 192.168.2.xxx na użycie tego serwera pośredniczącego zamiast tego który został zakazany (np. serwer plików i dostęp do WWW z sieci Troop). W sieci Troop w pliku sockd.conf powinien wyglądać w ten sposób: deny 192.168.2.17 255.255.255.255 deny 0.0.0.0 0.0.0.0 eq 80 permit 192.168.2.0 255.255.255.0 a w sieci Mercenary mniej więcej tak: deny 192.168.2.23 255.255.255.255 permit 192.168.2.0 255.255.255.0 To powinno zakończyć konfigurację wszystkiego. Każda z sieci jest izolowana, z prawidłowymi ustawieniami interakcji. Każdy powinien być szczęśliwy. Dalej... Podbij świat... 10. Od tłumacza. Zdaję sobie sprawę ile w tym tekscie jest potknięć językowych, przeinaczeń. Jeśli któreś cię drażnią prześlij mi swoje uwagi. Aha, jeszcze jedno. Wyrażenia firewall i ściana ogniowa oraz proxy i serwer pośredniczący traktuję (przynajmniej na razie) zamiennie. (choc już większość polskich odpowiedników (na życzenie publiczności) usunąłem. Celowo pozostawiam tekst bez zwyczajowego (c) tłumacza ;-)