Firewalle i proxy serwery

Mark Grennan, markg@netplus.net
v0.4, 8 listopad 1996
Wersja polska: Ziemek Borowski ziembor@ziembor.waw.pl v0.1 8 lipiec 1997

1. Wprowadzenie

Dokument ten Firewall-HOWTO został napisany przez Davida Ruddera mailto:drig@execpc.com. 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: markg@netplus.net

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:markg@netplus.net.

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:

1. firewalle filtrujące IP - blokują cały ruch, ale przepuszczają dopuszczony.
2. 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:

1. SOCKS
2. 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

1. Under General setup
   1. Turn Networking Support ON
2. Under Networking Options
   1. Turn Network firewalls ON
   2. Turn TCP/IP Networking ON
   3. Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP filtering)
   4. Turn IP Firewalling ON
   5. Turn IP firewall packet loggin ON (this is not required but it is a good idea)
   6. Turn IP: masquerading OFF (I am not covering this subject here.)
   7. Turn IP: accounting ON
   8. Turn IP: tunneling OFF
   9. Turn IP: aliasing OFF
   10. Turn IP: PC/TCP compatibility mode OFF
   11. Turn IP: Reverse ARP OFF
   12. Turn Drop source routed frames ON
3. Under Network device support
   1. Turn Network device support ON
   2. Turn Dummy net driver support ON
   3. Turn Ethernet (10 or 100Mbit) ON
   4. 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

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

 # 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

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 fwtk-request@tis.com 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

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

 #ifdef SCM_RIGHTS /* 4.3BSD Reno and later */
            + sizeof(un_name->sun_len) + 1
 #endif

 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
  #

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

 #  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 }

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

  permit 192.168.2.23 255.255.255.255

  permit 192.168.2.0 255.255.255.0

Nie powinieneś mieć następującej linii:

  permit 192.168.2.0 0.0.0.0

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

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

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>

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 fitz@wang.com. 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:

1. Poziom zewnętrzny - ukazywany wszystkim, tutaj werbujesz i zdobywasz nowych ochotników.
2. 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ę.
3. 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.

1. Nie każdy może użyć serwera plików dla dostępu do Interntu. Wystawia to go na wirusy i inne brzydkie rzeczu.
2. 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

  deny 192.168.2.23 255.255.255.255

  deny 0.0.0.0 0.0.0.0 eq 80

Teraz oba pliki powinny zawierać linie:

  permit 192.168.2.0 255.255.255.0

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

# # # #

Hosting by: Hurra Communications Sp. z o.o.
Generated: 2007-01-26 18:02:22