Firewalle i proxy serwery
  Mark Grennan, markg@netplus.net
  v0.4, 8 listopad 1996
  WWeerrssjjaa ppoollsskkaa:: ZZiieemmeekk BBoorroowwsskkii zziieemmbboorr@@zziieemmbboorr..wwaaww..ppll v0.1 8
  lipiec 1997


  Dokument ten powsta³ w celu uczenia podstaw systemów firewalli oraz
  dostarczenia  niektórych szczegó³ów w zakresie ustawania (konfigurowa­
  nia) filtruj±cych i posredniczacych firwalli na Linuxie. Oryginalna
  wersja tego dokumentu znajduje siê pod adresem: <http://okcfo­
  rum.org/~markg/Firewall-HOWTO.html> za¶ polskie t³umaczenie:
  <http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html>
  NNiinniieejjsszzaa wweerrssjjaa ooppiissuujjee ssttaann zz 11999977 rrookkuu.. JJee¶¶llii nnaaddaall uu¿¿yywwaasszz jj±±ddeerr zz
  sseerriiii 22..00 ((nniiee 22..22 lluubb 22..44)) ttoo jjeesstt ttoo ddookkuummeenntt ddllaa CCiieebbiiee.. NNaassttêêppnnaa
  wweerrssjjaa tteeggoo ddookkuummeennttuu ooppiissuujjee eeww.. ppoozzaa iippffwwaaddmm ttaakk¿¿ee iippcchhaaiinnss
  ((ddoossttêêppnnee zz jj±±ddrraammii 22..22)) ---- zzaawwiieerraa ttyyllee bb³³êêddóóww,, ¿¿ee nnaallee¿¿aa³³oobbyy jjee
  nnaappiissaaææ oodd nnoowwaa..  JJee¶¶llii sszzuukkaasszz iinnffoorrmmaaccjjii nnaa tteemmaatt bbuuddoowwaanniiaa ffiirree­­
  wwaallllii ppoodd lliinnuukksseemm ooddssyy³³aamm rraacczzeejj ddoo tt³³uummaacczzeeññ ddookkuummeennttaaccjjii IIPPttaabblleess
  wwyykkoonnaannyycchh pprrzzeezz ££uukkaasszzaa BBrroommiirrsskkiieeggoo hhttttpp::////mmrr00vvkkaa..eeuu..oorrgg//..
  ______________________________________________________________________

  Spis tre¶ci











































  1. Wprowadzenie

     1.1 Informacja zwrotna, uwagi.
     1.2 Deklaracje
     1.3 Copyright
     1.4 Moje pobudki do tej pracy.
     1.5 TODO (do zrobienia)
     1.6 Zobacz tak¿e:

  2. Understanding Firewalls

     2.1 Wady firewalli
     2.2 Typy firewalli
        2.2.1 Filtuj±ce firwalle
        2.2.2 Serwery proxy

  3. Ustawianie firewalla

     3.1 Wymagania sprzêtowe.

  4. Oprogramowanie dla firewalli

     4.1 Dostêpne pakiety
     4.2 TIS Firewall Toolkit kontra SOCKS

  5. Przygotowanie Linuxa

     5.1 Kompilacja j±dra.
     5.2 Ustawienie dwóch kart sieciowych
     5.3 Ustawienie adresów sieciowych
     5.4 Testowanie twojej sieci
     5.5 Zabezpieczanie firewalla.

  6. Konfigurowanie filtrowania IP (IPFWADM)

  7. Instalowania serwera proxy - TIS

     7.1 Pobranie oprogramowania
     7.2 Kompilacja  TIS FWTK
     7.3 Instalacja TIS FWTK
     7.4 Konfiguracja firewalla TIS FWTK
        7.4.1 Plik netperm-table
        7.4.2 Plik inetd.conf
        7.4.3 Plik /etc/services

  8. Serwer proxy SOCKS

     8.1 Konfigurowanie serwera Proxy
     8.2 Konfiguracja serwera proxy
        8.2.1 Plik dostêpu. Access File
        8.2.2 Tablica trasowania
        8.2.3 DNS zza firewalla Ustawienie us³ugi DNS zza firewalla jest  prostym zadaniem. 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
        8.3.1 Unix
        8.3.2 MS Windows i Trumpet Winsock
        8.3.3 Ustawienie serwera po¶rednicz±cego do pracy z pakietami UDP.
     8.4 Wady serwerów proxych

  9. Konfiguracja zaawansowana.

     9.1 Wielkie sieci wymagaj± po³o¿enia nacisku na bezpieczeñstwo
        9.1.1 Konfiguracja sieci
        9.1.2 Serwer proxy

  10. Od t³umacza.

  ______________________________________________________________________

  11..  WWpprroowwaaddzzeenniiee

  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.


  11..11..  IInnffoorrmmaaccjjaa zzwwrroottnnaa,, uuwwaaggii..

  Wszelkie uwagi bêd± mile widziane.
   PPrroosszzêê:: DDOONNOO¦¦CCIIEE OO WWSSZZEELLKKIICCHH NNIIEE¦¦CCIISS££OO¦¦CCIIAACCHH WW TTYYMM DDOOKKUUMMEENNCCIIEE .
  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 _a_d_r_e_s_:     <<markg@netplus.net>


  11..22..  DDeekkllaarraaccjjee

   NNIIEE OODDPPOOWWIIAADDAAMM ZZAA JJAAKKIIEEKKOOLLWWIIEEKK ZZNNIISSZZCCZZEENNIIAA WWYYNNIIKKAAJJ¡¡CCEE ZZEE SSTTOOSSOOWWAANNIIAA
  TTEEGGOO DDOOKKUUMMEENNTTUU  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.


  11..33..  CCooppyyrriigghhtt

  Je¶li nie jest powiedziane inaczej, prawa autorskie dokumenty z serii
  _L_i_n_u_x _J_a_k _T_o _Z_r_o_b_i_æ 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>.


  11..44..  MMoojjee ppoobbuuddkkii ddoo tteejj pprraaccyy..

  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.


  11..55..  TTOODDOO ((ddoo zzrroobbiieenniiaa))


  ·  Instrukcje na temat ustawieñ klientów

  ·  Znalezienie dobrych serwerów proxych dla us³ug bazuj±cych na UDP
     dzia³aj±cych na Linuxie.


  11..66..  ZZoobbaacczz ttaakk¿¿ee::


  ·  NET-3 HOWTO <http://www.jtz.org.pl/Html/NET-3-HOWTO.pl.html>

  ·  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.


  22..  UUnnddeerrssttaannddiinngg FFiirreewwaallllss

  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³ MMUUSSIISSZZ UUFFAAÆÆ WWSSZZYYSSTTKKIIMM SSWWOOIIMM UU¯¯YYTTKKOOWWNNIIKKOOMM
  Nie jest to zalecane rozwi±zanie.


  22..11..  WWaaddyy ffiirreewwaallllii

  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.


  22..22..  TTyyppyy ffiirreewwaallllii

  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.


  22..22..11..  FFiillttuujj±±ccee ffiirrwwaallllee

  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.


  22..22..22..  SSeerrwweerryy pprrooxxyy

  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.


  33..  UUssttaawwiiaanniiee ffiirreewwaallllaa

  33..11..  WWyymmaaggaanniiaa sspprrzzêêttoowwee..

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



  44..  OOpprrooggrraammoowwaanniiee ddllaa ffiirreewwaallllii

  44..11..  DDoossttêêppnnee ppaakkiieettyy

  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


  Je¶li chcesz postawiæ serwer proxy potrzebujesz jednego z ni¿ej
  wymienionych pakietów:

  1. SOCKS

  2. TIS Firewall Toolkit (FWTK)


  44..22..  TTIISS FFiirreewwaallll TToooollkkiitt kkoonnttrraa SSOOCCKKSS

  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.

  55..  PPrrzzyyggoottoowwaanniiee LLiinnuuxxaa

  55..11..  KKoommppiillaaccjjaa jj±±ddrraa..

  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

     a. Turn Networking Support ON

  2. Under Networking Options

     a. Turn Network firewalls ON

     b. Turn TCP/IP Networking ON

     c. Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP
        filtering)

     d. Turn IP Firewalling ON

     e. Turn IP firewall packet loggin ON (this is not required but it
        is a good idea)

     f. Turn IP: masquerading OFF (I am not covering this subject here.)

     g. Turn IP: accounting ON

     h. Turn IP: tunneling OFF

     i. Turn IP: aliasing OFF

     j. Turn IP: PC/TCP compatibility mode OFF

     k. Turn IP: Reverse ARP OFF

     l. Turn Drop source routed frames ON

  3. Under Network device support

     a. Turn Network device support ON

     b. Turn Dummy net driver support ON

     c. Turn Ethernet (10 or 100Mbit) ON

     d. 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æ.


  55..22..  UUssttaawwiieenniiee ddwwóócchh kkaarrtt ssiieecciioowwyycchh

  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 "




  55..33..  UUssttaawwiieenniiee aaddrreessóóww ssiieecciioowwyycchh

  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 mode­
  mowego 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.


  55..44..  TTeessttoowwaanniiee ttwwoojjeejj ssiieeccii

  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



  UUwwaaggaa:: 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.


  55..55..  ZZaabbeezzppiieecczzaanniiee ffiirreewwaallllaa..

  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:  "" kkiillll --HHUUPP  << ppiidd >>  "" , 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.


  66..  KKoonnffiigguurroowwaanniiee ffiillttrroowwaanniiaa IIPP ((IIPPFFWWAADDMM))

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


  77..  IInnssttaalloowwaanniiaa sseerrwweerraa pprrooxxyy -- TTIISS



  77..11..  PPoobbrraanniiee oopprrooggrraammoowwaanniiaa


  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
   PPRRZZEECCZZYYTTAAJJ ,,,,RREEAADDMMEE'''' Pakiet TIS fwtk jest w ukrytym katalogu na ich
  serwerze.

  TIS wymaga byæ wwyyss³³aa³³ eemmaaiill ddoo ffwwttkk--rreeqquueesstt@@ttiiss..ccoomm zawieraj±cego
  tylko s³owo SSEENNDD 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.


  77..22..  KKoommppiillaaccjjaa  TTIISS FFWWTTKK

  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.

  NNiiee uurruucchhaammiiaajj  FFIIXXMMAAKKEE.  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 mmaakkee.



  77..33..  IInnssttaallaaccjjaa TTIISS FFWWTTKK

  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.


  77..44..  KKoonnffiigguurraaccjjaa ffiirreewwaallllaa TTIISS FFWWTTKK

  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.



  77..44..11..  PPlliikk nneettppeerrmm--ttaabbllee

  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
  aauutthhssrrvv 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: ´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
  ..//aauutthhssrrvv 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.



  77..44..22..  PPlliikk iinneettdd..ccoonnff

  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




  77..44..33..  PPlliikk //eettcc//sseerrvviicceess

  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





  88..  SSeerrwweerr pprrooxxyy SSOOCCKKSS

  88..11..  KKoonnffiigguurroowwaanniiee sseerrwweerraa PPrrooxxyy

  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


  88..22..  KKoonnffiigguurraaccjjaa sseerrwweerraa pprrooxxyy

  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.


  88..22..11..  AAcccceessss FFiillee PPlliikk ddoossttêêppuu..

  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.


  88..22..22..  TTaabblliiccaa ttrraassoowwaanniiaa

  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 ser­
  weró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.


  88..22..33..  zzaaddaanniieemm.. PPoottrrzzeebbaa jjeeddyynniiee uussttaawwiieenniiaa DDNNSS nnaa mmaasszzyynniiee zz ffiirree­­
  wwaalllleemm..  II iinnnnee mmaasszzyynnyy zzaa ffiirreewwaalllleemm bbêêdd±± ggoo uu¿¿yywwaa³³yy..  DDNNSS zzzzaa ffiirree­­
  wwaallllaa UUssttaawwiieenniiee uuss³³uuggii DDNNSS zzzzaa ffiirreewwaallllaa jjeesstt  pprroossttyymm


  88..33..  WWssppóó³³pprraaccaa zz sseerrwweerraammii pprrooxxyy

  88..33..11..  UUnniixx

  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.


  88..33..22..  MMSS WWiinnddoowwss ii TTrruummppeett WWiinnssoocckk

  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.



  88..33..33..  UUssttaawwiieenniiee sseerrwweerraa ppoo¶¶rreeddnniicczz±±cceeggoo ddoo pprraaccyy zz ppaakkiieettaammii UUDDPP..

  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.



  88..44..  WWaaddyy sseerrwweerróóww pprrooxxyycchh

  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.


  99..  KKoonnffiigguurraaccjjaa zzaaaawwaannssoowwaannaa..

  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.



  99..11..  WWiieellkkiiee ssiieeccii wwyymmaaggaajj±± ppoo³³oo¿¿eenniiaa nnaacciisskkuu nnaa bbeezzppiieecczzeeññssttwwoo

  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. TTrroooopp 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. MMeerrcceennaarryy Tutaj jest miejsce gdzie _n_a_p_r_a_w_d_ê 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.

  99..11..11..  KKoonnffiigguurraaccjjaa ssiieeccii

  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.


  99..11..22..  SSeerrwweerr pprrooxxyy

  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


  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.  ser­
  wer 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...

  1100..  OOdd tt³³uummaacczzaa..

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