/usr/share/doc/HOWTO/pl-html/Firewall-HOWTO.pl.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Firewalle i proxy serwery</TITLE>


</HEAD>
<BODY>
<H1>Firewalle i proxy serwery<BR></H1>

<H2>Mark Grennan,
<A HREF="mailto:markg@netplus.net">markg@netplus.net</A><BR>
v0.4, 8 listopad 1996<BR>
<B>Wersja polska: Ziemek Borowski
<A HREF="mailto:ziembor@ziembor.waw.pl">ziembor@ziembor.waw.pl</A></B>
v0.1 8 lipiec 1997 </H2>
<P><HR>
<EM>Dokument ten powsta³ w celu uczenia podstaw systemów firewalli
oraz  dostarczenia  niektórych szczegó³ów w zakresie ustawania
(konfigurowania) filtruj±cych i posredniczacych firwalli na Linuxie. Oryginalna wersja tego dokumentu znajduje siê pod
adresem:
<A HREF="http://okcforum.org/~markg/Firewall-HOWTO.html">http://okcforum.org/~markg/Firewall-HOWTO.html</A>
za¶ polskie t³umaczenie:
<A HREF="http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html">http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html</A>
<B>Niniejsza wersja opisuje stan z 1997 roku. Je¶li nadal u¿ywasz j±der
z serii 2.0 (nie 2.2 lub 2.4) to jest to dokument dla Ciebie. Nastêpna
wersja tego dokumentu opisuje ew. poza ipfwadm tak¿e ipchains
(dostêpne z
j±drami 2.2) -- zawiera tyle b³êdów, ¿e nale¿a³oby je napisaæ od nowa.
Je¶li szukasz informacji na temat budowania firewalli pod linuksem
odsy³am raczej do t³umaczeñ dokumentacji IPtables wykonanych przez
£ukasza Bromirskiego http://mr0vka.eu.org/.</B></EM>
<HR>
<H2><A NAME="s1">1. Wprowadzenie</A></H2>

<P>Dokument ten Firewall-HOWTO zosta³ napisany przez Davida Ruddera
<A HREF="mailto:drig@execpc.com">mailto:drig@execpc.com</A>.
Chcia³bym Mu podziêkowaæ za zezwolenie na uaktualnienie jego pracy.
<P>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.
<P>
<H2>1.1 Informacja zwrotna, uwagi.</H2>

<P>Wszelkie uwagi bêd± mile widziane.
<B> Proszê: DONO¦CIE O WSZELKICH
NIE¦CIS£O¦CIACH W TYM DOKUMENCIE </B>.
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.
<P><EM>Mój adres:    <B>
<A HREF="markg@netplus.net">markg@netplus.net</A> </B></EM>
<P>
<H2>1.2 Deklaracje</H2>

<P><B> NIE ODPOWIADAM ZA JAKIEKOLWIEK ZNISZCZENIA WYNIKAJ¡CE ZE
STOSOWANIA TEGO DOKUMENTU </B> 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.
<P>
<H2>1.3 Copyright</H2>

<P>Je¶li nie jest powiedziane inaczej, prawa autorskie
dokumenty z serii <EM> Linux
Jak To Zrobiæ </EM>
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.
<P>Wszystkie t³umaczenia, poprawki jêzykowe, i prace w³±czaj±ce
musz± zawieraæ niniejsz± notê o prawach autorskich.
<P>Je¶li masz jakie¶ zapytania, proszê o kontakt:
Mark Grennan 
<A HREF="mailto:markg@netplus.net">mailto:markg@netplus.net</A>.
<P>
<H2>1.4 Moje pobudki do tej pracy.</H2>

<P>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.
<P>Poza tym uwa¿am ¿e powinienem zwróciæ mój d³ug spo³eczno¶ci
Linuxowej.
<P>
<H2>1.5 TODO (do zrobienia)</H2>

<P>
<UL>
<LI> Instrukcje na temat ustawieñ klientów</LI>
<LI>  Znalezienie dobrych serwerów proxych dla us³ug
bazuj±cych na UDP dzia³aj±cych na Linuxie.</LI>
</UL>
<P>
<H2>1.6 Zobacz tak¿e:</H2>

<P>
<UL>
<LI>
<A HREF="http://www.jtz.org.pl/Html/NET-3-HOWTO.pl.html">NET-3 HOWTO</A></LI>
<LI>
<A HREF="http://www.linux.com.pl/LDP/HOWTO/">The Multiple Ethernet Mini HOWTO</A></LI>
<LI>
<A HREF="">Networking with Linux</A></LI>
<LI>
<A HREF="http://www.jtz.org.pl/Html/PPP-HOWTO.pl.html">The PPP HOWTO</A></LI>
<LI>
<A HREF="http://www.ora.com/">TCP/IP Network Administrator's Guide</A> by O'Reilly and
Associates</LI>
<LI>The Documentation for the TIS Firewall Toolkit</LI>
</UL>
<P>Wêze³ pajêczyny nale¿±cy do 
<A HREF="http://www.tis.com/">Trusted  Information System's (TIS) </A> posiada wspania³a
kolekcjê dokumentacji dotycz±cej firewalli i pokrewnych tematów.
<P>Poza  tym pracujê na projektem dotycz±cym bezpieczeñstwa:
,,Bezpieczny  Linux''.  W  miejscu  tym  
<A HREF="">zgromadzi³em</A> wszystkie informacje, dokumentacje i programy
potrzebne do stworzenia bezpiecznego Linuxa. Napisz do mnie je¶li
chcesz otrzymaæ wiêcej informacji.
<P>
<H2><A NAME="s2">2. Understanding Firewalls</A></H2>

<P> 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.
<P>Komputerowe firewalle s± urz±dzeniami, które chroni± sieci
prywatne od czê¶ci publicznej (jakiej jak Internet).
<P>  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.
<P>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.
<P>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.
<P>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.
<P>
<P>Aby powy¿szy firewall dzia³a³ <B>MUSISZ UFAÆ WSZYSTKIM SWOIM U¯YTKOWNIKOM </B> Nie jest to zalecane
rozwi±zanie.
<P>
<H2>2.1 Wady firewalli</H2>

<P>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.
<P>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.
<P>
<H2>2.2 Typy firewalli</H2>

<P>Istniej± dwa typy firewalli:
<P>
<OL>
<LI>  firewalle filtruj±ce IP - blokuj± ca³y ruch, ale
przepuszczaj± dopuszczony.</LI>
<LI> serwery proxy   - serwery po³±czeniowe - wykonuj± po³±czenie
sieciowe za ciebie.</LI>
</OL>
<P>
<H3>Filtuj±ce firwalle</H3>

<P>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).
<P>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.
<P>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)
<P>Linux posiada opcjê filtrowania pakietów w j±drach powy¿ej 1.3.x.
<P>
<H3>Serwery proxy</H3>

<P>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¶.
<P>Poniewa¿ serwery proxy podwajaj± ka¿de po³±czenie, mo¿liwe jest
zapisywanie ka¿dego z nich.
<P>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.
<P>
<H2><A NAME="s3">3. Ustawianie firewalla</A></H2>

<H2>3.1 Wymagania sprzêtowe.</H2>

<P>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.
<P>Jest to ca³kiem przyjemny standard dla biznesu. Powiniene¶ u¿yæ
jednej karty sieciowej oraz modemu z PPP do intenetu.
<P>Firewall powinien posiadaæ dwa adresy IP.
<P>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 ; -).
<P>
<P>
<H2><A NAME="s4">4. Oprogramowanie dla firewalli</A></H2>

<H2>4.1 Dostêpne pakiety</H2>

<P>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 <B>
<A HREF="http://www.xos.nl/linux/ipfwadm/">http://www.xos.nl/linux/ipfwadm/</A></B>
<P>
<P>Je¶li chcesz postawiæ serwer proxy potrzebujesz jednego z ni¿ej
wymienionych pakietów:
<OL>
<LI>SOCKS</LI>
<LI>TIS Firewall Toolkit (FWTK)</LI>
</OL>
<P>
<H2>4.2 TIS Firewall Toolkit kontra SOCKS</H2>

<P>Trusted Information System (<B>
<A HREF="http://www.tis.com">http://www.tis.com</A></B>)
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.
<P>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¶.
<P>
<P> 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.
<P>
<P> 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.
<P>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.
<P>
<P> Opiszê proces instalacji obydwu.
<H2><A NAME="s5">5. Przygotowanie Linuxa</A></H2>

<H2>5.1 Kompilacja j±dra.</H2>

<P>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.
<P>U¿yj stabilnego j±dra. Ja u¿y³em 2.0.14.
Oto jest dokumentacja podstawowych ustawieñ:
<P>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ê <CODE> make
config</CODE>
<P>
<OL>
<LI>Under General setup
<OL>
<LI>Turn Networking Support ON</LI>
</OL>
</LI>
<LI>Under Networking Options
<OL>
<LI>Turn Network firewalls ON</LI>
<LI>Turn TCP/IP Networking ON</LI>
<LI>Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP
filtering)</LI>
<LI>Turn IP Firewalling ON</LI>
<LI>Turn IP firewall packet loggin ON (this is not required but
it is a good idea)</LI>
<LI>Turn IP: masquerading OFF (I am not covering this subject
here.)</LI>
<LI>Turn IP: accounting ON</LI>
<LI>Turn IP: tunneling OFF</LI>
<LI>Turn IP: aliasing OFF</LI>
<LI>Turn IP: PC/TCP compatibility mode OFF</LI>
<LI>Turn IP: Reverse ARP OFF</LI>
<LI>Turn Drop source routed frames ON</LI>
</OL>
</LI>
<LI>Under Network device support
<OL>
<LI>Turn Network device support ON</LI>
<LI>Turn Dummy net driver support ON</LI>
<LI>Turn Ethernet (10 or 100Mbit) ON</LI>
<LI>Select your network card</LI>
</OL>
</LI>
</OL>
<P>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æ.
<P>
<H2>5.2 Ustawienie dwóch kart sieciowych</H2>

<P>Je¶li masz dwie kary sieciowe w swoim komputerze w wiêkszo¶ci
przypadków potrzebujesz dodaæ twierdzenie w pliku
<CODE>/etc/lilo.conf</CODE> opisuj±ce ich IRQ i adresy. W moim wypadku
wygl±da to tak:
<PRE>
  append= &quot; ether=12,0x300,eth0 ether=15,0x340,eth1 &quot; 
</PRE>
<P>
<H2>5.3 Ustawienie adresów sieciowych</H2>

<P>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.
<P>Wybrali¶my jedn± z tych klas: 192.168.2.xxx, i u¿yjemy jej w naszym
przyk³adzie.
<P>
<P>Twój serwer proxy bêdzie cz³onkiem obu sieci i bêdzie przekazywa³
dane do i z sieci prywatnej.
<P>
<PRE>
      199.1.2.10  __________  192.168.2.1  192.168.2.2
   _ __ _    \ |     | /      ____/__________
   | \/ \/ |    \| Firewall |/      | Stacja    |
  / Internet \--------|     |------------| Robocza    |
  \_/\_/\_/\_/    |__________|      |_______________|
</PRE>
<P>Je¶li  u¿ywasz filtruj±cego firewalla mo¿esz u¿ywaæ tych numerów
stosuj±c 
<A HREF="">IP masquearading</A>
Firewall bêdzie przesy³a³ pakiety i t³umaczy³ numery IP na
,,PRAWDZIWE'' adresy w Internecie.
<P>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.
<P>
<P> Odk±d u¿ywam RedHat Linux
<P>do ustawienia sieci przy starcie dodajê plik <CODE> ifcfg-eth1</CODE>
w katalogu <CODE>/etc/sysconfig/network-scripts/</CODE>. Jest on czytany
w trakcie startu systemu i ustawiania sieci i tablic routingu.
<P>Mój <CODE>ifcfg-eth1</CODE> wygl±da nastêpuj±co:
<P>
<PRE>
  #!/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
</PRE>

Mo¿esz  tak¿e  u¿yæ tego skryptu do automatycznego po³±czenia
modemowego do twojego IPS. Spójrz na skrypt <CODE>ipup-pop</CODE>
<P>Je¶li u¿ywasz modemu do ³±czenia siê z sieci± twój zewnêtrzny adres
bêdzie
przydzielony w trakcie po³±czenia.
<P>
<H2>5.4 Testowanie twojej sieci</H2>

<P>Zacznij od sprawdzenia <CODE> ifconfig </CODE> i trasowania (routingu)
je¶li masz dwie karty wynik polecenia <CODE>ifconfig</CODE> powinien
wygl±daæ
nastêpuj±co:
<P>
<PRE>
 #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
</PRE>
<P>a twoja tablica trasowania mniej wiêcej tak:
<P>
<PRE>
 #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
</PRE>
<P><B>Uwaga:</B> 199.1.2.0 jest numerem interface po internetowej
stronie
firewalla za¶ 192.168.2.0 jest wewn±trz.
<P>Teraz spróbuj pingn±æ siê do Internetu z firewalla. Ja zwyk³em u¿ywaæ
nic.dnn.mil jako punktu testowego (w Polsce doradza³bym
<CODE>bilbo.nask.org.pl</CODE> 148.81.16.51). Jest to wci±¿ dobry test,
ale nie dostarcza tylu informacji ile by siê chcia³o. 
<P>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.
<P>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.
<P>Teraz spróbuj pingn±æ zewnêtrzny adres z wewnêtrznej czê¶ci
chronionej sieci.
<P>(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.
<P>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¶.
<P>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æ).
<P>
<P>Je¶li przydzieli³e¶ swojej sieci adresy 192.168.2.*
pakiety i tak nie bêd± filtrowane. Je¶li przechodz± mimo wszystko
i masz
<CODE>IP masquerading</CODE> w³±czone ten test te¿ zosta³ zdany.
<P>Masz teraz podstawow± konfiguracjê systemu.
<P>
<H2>5.5 Zabezpieczanie firewalla.</H2>

<P>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.
<P>Zacznij wy³±czaæ niepotrzebne us³ugi. Spójrz na
<CODE>/etc/inetd.conf</CODE>.
Plik ten kontroluje co¶ co jest nazywane ,,super serwerem''.
Kontroluje uruchamianie us³ug na ¿±danie.
<P>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: <B> &quot; kill -HUP  &lt; pid &gt;  &quot; </B>,
gdzie  &lt; pid &gt;  jest numerem procesu inetd.
Spowoduje to powtórne przeczytanie przez inetd pliku konfiguracyjnego
<P>(inetd.conf) i restart.
<P>Sprawd¼ teraz czy jeste¶ w stanie dostaæ siê do portu obs³uguj±cego
netstat
<CODE> telnet localhost 15</CODE>
Je¶li otrzymasz wynik z netstata nie zrestartowa³e¶ inetd
prawid³owo.
<P>
<H2><A NAME="s6">6. Konfigurowanie filtrowania IP (IPFWADM)</A></H2>

<P>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.
<P>Ale budujemy firwalla tak wiêc trzeba ograniczyæ wszystkim dostêp
do niego.
<P>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 <CODE> /etc/rc.d </CODE>
w czasie konfiguracji.
<P>Domy¶lnie <CODE>IP Forwarding</CODE> 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.
<P>
<PRE>
 #
# 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
</PRE>

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).
<P>
<PRE>
 # 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
</PRE>
<P>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.
<P>
<PRE>
 # 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
</PRE>

Je¶li potrzebowa³e¶ firewalla filtruj±cego mo¿esz skoñczyæ lekturê.
Mi³ego konfigurowania. ; -)
<P>
<H2><A NAME="s7">7. Instalowania serwera proxy - TIS</A></H2>

<P>
<P>
<H2>7.1 Pobranie oprogramowania</H2>

<P>
<P>TIS FWTK jest dostêpny pod adresem: <B>
<A HREF="ftp://ftp.tis.com/">ftp://ftp.tis.com/</A></B>.
<P>Nie pope³nij tego b³êdu co ja. Kiedy dostaniesz siê na serwer TIS
<B> PRZECZYTAJ ,,README''</B>
Pakiet TIS fwtk jest w ukrytym katalogu na ich serwerze.
<P>TIS wymaga byæ <B>wys³a³ email do fwtk-request@tis.com</B>
zawieraj±cego tylko s³owo <B>SEND</B> 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.
<P>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.
<P>Aby zainstalowaæ FWTK stwórz katalog <CODE> fwtk-2.0</CODE>
w <CODE>/usr/src</CODE>. Przenie¶ tak kopiê (fwtk-2.0.tar.gz)
odpakuj j± (tar zxf fwtk-2.0.tar.gz).
<P>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 <B>
<A HREF="ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z">ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z</A></B>. Touvet nie ¶wiadczy wsparcia technicznego dla tego kodu.
<P>U¿ywam zmodyfikowanej wersji: w³±czy³em modu³ dostêpu do
bezpiecznych
serwerów news Netscape napisany przez Eric Wedel
<A HREF="ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z">ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z</A>.
<P>
<P>W naszych przyk³adach bêdê u¿ywa³ wersji Wedel'a.
<P>Aby go zainstalowaæ po prostu strwó¿ katalog <CODE> ssl-gw</CODE> w
katalogu
<CODE>/usr/src/fwtk-2.0</CODE> i wsad¼ tam odpowiednie pliki.
Kiedy instalowa³em tê bramê potrzebne by³y drobne zmiany zanim mog³em
skompilowaæ
resztê zestawu.
<P>Pierwsza zmiana nast±pi³a w pliku <CODE> ssl-gw.c </CODE>.
Nie potrafi³ w³±czyæ jednego z plików include.
<P>
<PRE>
 #if defined(__linux)
 #include    &lt;sys/ioctl.h>
 #endif
</PRE>

Druga zmiana polega³a na stworzeniu pliku <CODE>Makefile</CODE>.
Skopiowa³em jeden z innej ,,bramy'' i zast±pi³em nazwê tego modu³u
nazw± <CODE>ssl-gw</CODE>.
<P>
<H2>7.2 Kompilacja  TIS FWTK</H2>

<P>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.
<P>Aby to poprawiæ zacznij zmiany od katalogu
<CODE>/usr/src/fwtk/fwtk</CODE>
i skopiuj plik <CODE> Makefile.config.linux </CODE> na
<CODE> Makefile.config</CODE>.
<P><B>Nie uruchamiaj  FIXMAKE</B>.
Instrukcja mówi by¶ to zrobi³. Je¶li chcesz zniszczyæ Makefile
we wszystkich podkatalogach...
<P>Wykona³em poprawkê do <CODE>fixmake</CODE> Problem polega³ na tym,
¿e <CODE>fixmake</CODE> dodawa³ '.' i '' do w³±czanych do
<CODE>Makefile</CODE>
linii.
<P>
<PRE>
 sed 's/^include[    ]*\([^ ].*\)/include \1/' $name .proto > $name
</PRE>
<P>Nastêpnie bêdziemy musieli wyedytowaæ <CODE>Makeconfig.file</CODE>.
Potrzebne bêd± dwie zmiany.
<P>Autor programu ustawi³ ¼ród³a programu w swoim <CODE>$HOME/</CODE>.
My kompilujemy w <CODE>/usr/src</CODE> i powinni¶my zmieniæ zmienn±
FWTKSRCDIR.
<P>
<PRE>
 FWTKSRCDIR=/usr/src/fwtk/fwtk
</PRE>
<P>Po drugie, przynajmniej niektóre Linuxy u¿ywaj± bazy danych w
formacie
<CODE>gdbm</CODE>. W <CODE> Makefile.config</CODE> jest u¿ywana <CODE>dbm</CODE>
Zapewne bêdziesz musia³ to zmieniæ.
Ja w RedHacie 3.0.3 musia³em.
<P>
<PRE>
 DBMLIB=-lgdbm
</PRE>

Ostania poprawka jest w katalogu x-gw. B³±d w wersji beta jest w
pliku
<CODE>socket.c</CODE>. Poprawka polega na usuniêciu tych linii.
<P>
<PRE>
 #ifdef SCM_RIGHTS /* 4.3BSD Reno and later */
            + sizeof(un_name->sun_len) + 1
 #endif
</PRE>

Je¶li doda³e¶ <CODE>ssl-gw</CODE> do swojego katalogu ¼róde³ trzeba
jeszcze dodaæ
do listy katalogów w  Makefile.
<P>
<PRE>
 DIRS=  smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw
 x-gw ssl-gw
</PRE>
<P>Teraz uruchom <B>make</B>.
<P>
<P>
<H2>7.3 Instalacja TIS FWTK</H2>

<P>Uruchom <CODE>make install</CODE>.
Standardowo katalogiem instalacyjnym jest <CODE>/usr/local/etc</CODE>.
Mo¿esz to zmieniæ (ja tego nie zrobi³em) na bardziej bezpieczny
katalog.
Ja zmieni³em prawa dostêpu do niego na <CODE> chmod 700 </CODE>.
<P>Na koniec pozosta³a nam konfiguracja firewalla.
<P>
<H2>7.4 Konfiguracja firewalla TIS FWTK</H2>

<P>Teraz naprawdê rozpoczynamy. Musisz nauczyæ system wywo³ywania tych
nowych
us³ug i stworzyæ tablice do ich kontroli.
<P>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.
<P>Istniej± trzy pliki kontroluj±ce firewalla.
<P>
<P>
<UL>
<LI>/etc/services
<UL>
<LI>mówi±cy systemowi jaki port obs³uguje jak± us³ugê.</LI>
</UL>
</LI>
</UL>

<UL>
<LI>/etc/inetd.conf
<UL>
<LI>mówi±cy serwerowi inetd jaki program wywo³aæ gdy kto¶ bêdzie siê
dobija³ do zadanego portu.</LI>
</UL>
</LI>
</UL>

<UL>
<LI>/usr/local/etc/netperm-table
<UL>
<LI>mówi±cy FWTK kto jest dopuszczony a kogo winno siê odrzucaæ
przy danej us³udze.</LI>
</UL>
</LI>
</UL>
<P>Aby uzyskaæ poprawne funkcjonowanie FWTK powiniene¶ wyedytowaæ te
pliki
poczynaj±c od góry. Edycja jedynie <CODE>services</CODE> bez inetd.conf
i
netperm-table ustawionych prawid³owo uczyni twój system
niedostêpnym.
<P>
<P>
<H3>Plik netperm-table</H3>

<P>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.
<P>Aby ludzie moli siê zidentyfikowaæ firewall u¿ywa programu o nazwie
<B>authsrv</B>
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.
<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:
'' <CODE>authsrv: premit-hosts localhost</CODE> je¶li chcesz zachowaæ
j± pracuj±c±.
<P>
<PRE>
 #
 # 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
</PRE>
<P>Aby zaincjalizowaæ bazê danych wykonaj <CODE>su</CODE> do root`a i
uruchom
<B>./authsrv</B> w katalogu <CODE> /var/local/etc </CODE>
by stworzyæ rekord opisuj±cy administratora systemu.
<P>Oto jest przyk³adowa sesja.
<P>Przeczytaj dokumentacjê FWTK, by dowiedzieæ siê jak dodaæ
u¿ytkowników i
grupy.
<P>
<P>
<PRE>
  #
  # authsrv
  authsrv# list
  authsrv# adduser admin  &quot; Auth DB admin &quot; 
  ok - user added initially disabled
  authsrv# ena admin
  enabled
  authsrv# proto admin pass
  changed
  authsrv# pass admin  &quot; plugh &quot; 
  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
  #
</PRE>

Kontrola przez bramê telnetu (tn-gw) polega na prostym przes³aniu
i jest to pierwsza któr± powiniene¶ ustawiæ.
<P>W moim przyk³adzie pozwoli³em komputerom z wnêtrza sieci prywatnej
na dostêp bez autentyfikacji (permit-hosts 19961.2.* -passok).
<P>Ale inni u¿ytkownicy powinni wprowadziæ swoj± nazwê u¿ytkownika i
has³o.
(permit-hosts * -auth)
<P>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 <CODE>inetacl-in.telnetd</CODE>
<P>Wyja¶niê ich dzia³anie potem.
<P>Powiniene¶ zachowaæ krótki czas timeoutu.
<P>
<PRE>
 # 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
</PRE>

I to samo z r-command.
<P>
<PRE>
 #  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
</PRE>
<P>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).
<P>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.
<P>(-log { retr stor })
<P>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.
<P>
<PRE>
 #  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 }
</PRE>

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.
<P>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.
<P>
<PRE>
 # 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   *
</PRE>
<P><CODE>ssl-gw</CODE> 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.
<P>
<PRE>
# 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   *
</PRE>
<P>Poni¿ej znajduje siê przyk³ad jak u¿yæ <CODE>plug-gw</CODE> 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.
<P>W drugiej linii pozwalam serwerowi news przes³aæ dane z powrotem do
chronionej
sieci.
<P>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.
<P>
<PRE>
 # 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
</PRE>
<P>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¶æ.
<P>
<PRE>
 # 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
</PRE>
<P>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.
<P>
<P>
<H3>Plik inetd.conf</H3>

<P>Oto jest kompletny plik <CODE> /etc/inetd.conf </CODE>.
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}
<P>
<PRE>
 #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  &quot; boot servers. &quot; 
 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
</PRE>
<P>
<H3>Plik /etc/services</H3>

<P>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 <CODE> inetd</CODE>
s³yszy pro¶bê o po³±czenie, i szuka nazwy tej us³ugi w
<CODE>/etc/services</CODE>. Pó¼niej wzywa programy wyznaczony  dla tej
us³ugi
w <CODE> /etc/inedt.conf</CODE>
<P>Niektóre z us³ug nie s± normalnie tworzone przez wywo³anie w
<CODE>/etc/serwices</CODE>.
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.
<P>
<P>
<PRE>
 telnet-a    24/tcp
 ftp-gw     21/tcp      # this named changed
 auth      113/tcp  ident  # User Verification
 ssl-gw     443/tcp
</PRE>
<P>
<P>
<H2><A NAME="s8">8. Serwer proxy SOCKS</A></H2>

<H2>8.1 Konfigurowanie serwera Proxy</H2>

<P>SOCKS proxy server dostêpny jest z adresu:
<A HREF="ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz">ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz</A>.
Zawiera przyk³adowy plik konfiguracyjny w katalogu nazwanym:
&quot; socks-conf &quot; . 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
<CODE>Makefile </CODE> jest prawid³owy.
<P>Jedn± z wa¿niejszych rzeczy jest pamiêtanie o konieczno¶ci dodania
serwera proxy do <CODE>/etc/inetd.conf</CODE>.
Aby móc odpowiedzieæ na ¿±dania musisz dopisaæ nastêpuj±c± liniê:
<P>
<PRE>
 socks stream tcp nowait nobody /usr/local/etc/sockd sockd
</PRE>
<P>
<H2>8.2 Konfiguracja serwera proxy</H2>

<P>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.
<P>
<H3>Plik dostêpu.Access File</H3>

<P>W wersji 4.2 Beta SOCSKsów plik dostêpu nazywa siê
&quot; sockd.conf &quot; .
powinien zawieraæ dwie linie: zezwolenia i zakazu. Ka¿da z linii
posiada trzy
pozycje:
<P>
<UL>
<LI>identyfikator (permit/deny)</LI>
<LI>adres IP</LI>
<LI>modyfikator adresu</LI>
</UL>

Identyfikator to <CODE>permit</CODE> lub <CODE> deny</CODE>
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:
<P>
<PRE>
  permit 192.168.2.23 255.255.255.255
</PRE>

zezwalam na dostêp maszynom w których adres pasuje co do bitu  z
zadanym:
pasuje tu tylko 192.168.2.23
<P>
<PRE>
  permit 192.168.2.0 255.255.255.0
</PRE>

zezwala na dostêp maszynom z gdyby od 192.168.2.0 do 192.168.2.255,
w
formie ca³ej klasy C.
<P>Nie powiniene¶ mieæ nastêpuj±cej linii:
<P>
<PRE>
  permit 192.168.2.0 0.0.0.0
</PRE>

daj±cej dostêp dla wszystkich adresów.
<P>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:
<P>
<PRE>
  permit 192.168.2.0 255.255.255.0
  deny 0.0.0.0 0.0.0.0
</PRE>

Zwróæ uwagê na pierwsze  &quot; 0.0.0.0 &quot;  w linii zakazu.
Z mask± 0.0.0.0 taki adres nie istnieje. Wszystkie zera
zosta³y tam wprowadzone bo s± ³atwe do zapisu.
<P>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
<CODE>ident</CODE>.  Nie wszystkie systemu u¿ywaj± <CODE>ident</CODE>,
w³±czaj±c w to
<CODE> Trumpet Winsock </CODE>, dlatego te¿ nie w³±czam tu przyk³adów.
Dokumentacja do SOCKS jest ca³kiem dobra w tej kwestii.
<P>
<H3>Tablica trasowania</H3>

<P>Tablica routingu w SOCS jest niestety nazywana
<CODE>socks.conf</CODE>.
<P>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±...
<P>S± trzy typy rekordów:
<P>
<UL>
<LI>deny</LI>
<LI>direct</LI>
<LI>sockd</LI>
</UL>
<P><CODE>Deny</CODE> mówi SOCKS kiedy ma odmówiæ ¿±daniu. Rekord ten ma
takie
same trzy pola jak <CODE>sockd.conf</CODE>: identyfikator, adres i
maska.
Ogólnie, dopóki jest to modyfikowane przez <CODE>sockd.conf</CODE>,
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.
<P>Rekord <CODE>direct</CODE> mówi które do których adresów nie u¿ywaæ
SOCKS.
Te adresy bêd± dorêczone bez serwera proxy.
<P>Jeszcze raz, mamy trzy pola: identyfikator, adres i maska.
<P>
<PRE>
  direct 192.168.2.0 255.255.255.0
</PRE>

W ten sposób kierujesz bezpo¶rednio ca³y ruch w chronionej sieci.
<P>Rekord z <CODE>sockd</CODE>
mówi komputerowi które z hostów s± serwerem SOCKS
<P>Sk³adnia jest nastêpuj±ca:
<PRE>
 sockd @=&lt;serverlist> &lt;IP address> &lt;modifier>
</PRE>

Zwróæ uwagê na fragment: @= .
Pozwala on na wprowadzenie listy serwerów proxy.
W naszym przyk³adzie u¿ywamy
tylko jednego. Ale mo¿esz mieæ wiele w celu zwiêkszenia
przepustowo¶ci
i obni¿enia mo¿liwo¶ci awarii.
<P>Pola adresu IP i maski dzia³aj± jak w innych przyk³adach.
Specyfikujesz adres i zakres jego obowi±zywania.
<P>
<H3>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.</H3>

<H2>8.3 Wspó³praca z serwerami proxy</H2>

<H3>Unix</H3>

<P>Aby twoje aplikacje dzia³a³y z serwerami proxy
potrzebujesz je zsockisy... ( &quot; sockified &quot; ).
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. <CODE>Finger</CODE> stanie
siê <CODE>finger.orig</CODE>, <CODE>telnet</CODE> stanie siê
<CODE>telnet.orig</CODE> i
tak dalej.
Musisz powiedzieæ SOCKS o ka¿dym w pliku <CODE>include/socks.h</CODE>.
<P>
<P>
<P>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.
<P>
<H3>MS Windows i Trumpet Winsock</H3>

<P>Trumpet Winsock przychodzi z wbudowanymi mo¿liwo¶ciami wspó³pracy z
serwerem proxy. W
<CODE> setup </CODE> menu wprowad¼ adres serwera, i adresy
komputerów dostêpnych bezpo¶rednio. Program przekieruje na serwer
wszystkie pakiety maj±ce wyj¶æ na zewn±trz.
<P>
<P>
<H3>Ustawienie serwera po¶rednicz±cego do pracy z pakietami UDP.</H3>

<P>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 <CODE>talk</CODE> i <CODE>Archie</CODE>
u¿ywa UDP. Jest jednak pakiet
który mo¿e byæ u¿yty jako serwer proxy dla UDP: UDPrelay
stworzony
przez Toma Fitzgeralda 
<A HREF="fitz@wang.com">fitz@wang.com</A>. Niestety w chwili
pisania tego tekstu nie jest on zgodny z Linuxem.
<P>
<P>
<H2>8.4 Wady serwerów proxych</H2>

<P>Serwer proxy, jak pokaza³em powy¿ej jest
<CODE>narzêdziem bezpieczeñstwa</CODE>.
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, <CODE>talk</CODE> 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:
<P>
<UL>
<LI> 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±. 
</LI>
<LI>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.
</LI>
<LI>Niemo¿liwo¶æ u¿ycia us³ug dzia³aj±cych z UDP jest wielk± wad±
serwerów proxych. Choæ mam nadziejê, ¿e  ju¿ nied³ugo.</LI>
</UL>
<P>Przypadek FTP pokazuje jeszcze jeden problem z serwerami
proxymi. Kiedy pobieram pliki lub wydajê komendê <CODE>ls</CODE>,
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.
<P>
<P>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.
<P>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
<CODE>Term</CODE>, <CODE>Slirp</CODE> lub <CODE>TIA</CODE>. Term jest dostêpny z
<A HREF="ftp://sunsite.unc.edu/">ftp://sunsite.unc.edu/</A>, Slirp z 
<A HREF="ftp://blitzen.canberra.edu.au/pub/slirp">ftp://blitzen.canberra.edu.au/pub/slirp</A>, za¶ TIA z 
<A HREF="http://markertplace.com/">http://markertplace.com/</A>.
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.
<P>
<H2><A NAME="s9">9. Konfiguracja zaawansowana.</A></H2>

<P>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.
<P>
<P>
<H2>9.1 Wielkie sieci wymagaj± po³o¿enia nacisku na bezpieczeñstwo</H2>

<P>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.
<P>Poziomy dostêpu:
<P>
<OL>
<LI>Poziom zewnêtrzny - ukazywany wszystkim, tutaj werbujesz i zdobywasz
nowych ochotników.
</LI>
<LI><B>Troop</B>
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ê.
</LI>
<LI><B>Mercenary</B>
Tutaj jest miejsce gdzie <EM>naprawdê</EM> 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.</LI>
</OL>
<P>
<H3>Konfiguracja sieci</H3>

<P>Numery IP s± ustawione w nastêpuj±cy sposób:
<P>
<P>
<UL>
<LI>1 numer to 192.168.2.255, bêd±cy adresem rozg³oszeniowym
nie u¿ywanym</LI>
<LI>23 z 32 adresów IP jest przydzielonych dla maszyn dostêpnych w
Internecie.</LI>
<LI>1 dodatkowy adres IP zosta³ przydzielony Linuxowi</LI>
<LI>1 dodatkowy adres IP zosta³ przydzielony innemu linuxowi</LI>
<LI>2 numery IP zosta³y przydzielone routerowi</LI>
<LI>4 pozosta³e pozostaj± od³±czone ale otrzymuj± nazwy domenowe: paul, ringo,
john, george .</LI>
<LI>chroniona sieæ ma numer 192.168.2.xxx</LI>
</UL>
<P>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.
<P>
<P>Ka¿da z tych sieci jest po³±czona do jednej ze stacji linuxowych na
dodatkowych adresach IP.
<P>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. 
<P>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. <CODE>IP Forwarding</CODE> jest wy³±czony.
<P><CODE>IP Forwarding</CODE> 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.
<P>Serwer NFS mo¿e ponadto oferowaæ ró¿ne pliki dla ró¿nych sieci.
<P>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.
<P>
<H3>Serwer proxy</H3>

<P>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. 
<P>
<OL>
<LI>Nie ka¿dy mo¿e u¿yæ serwera plików dla dostêpu do Interntu. 
Wystawia to go na wirusy i inne brzydkie rzeczu. 

</LI>
<LI>Nie chcemy zezwoliæ sieci Troop na dostêp do WWW. Przechodz± szkolenie 
I jaki kolwiek przep³y informacji móg³by zniszczyæ jego efekty.
</LI>
</OL>
<P>Tak wiêc w pliku <CODE>sockd.conf</CODE> w linuxie w sieci Troop znajdzie
siê nastêpuj±ca linia.
<P>
<PRE>
  deny 192.168.2.17 255.255.255.255
</PRE>

a w stacji przeznaczonej dla Mercenary:
<P>
<PRE>
  deny 192.168.2.23 255.255.255.255
</PRE>

Teraz w stacji linuxowej sieci Troop wpisujemy:
<P>
<PRE>
  deny 0.0.0.0 0.0.0.0 eq 80
</PRE>

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.
<P>Teraz oba pliki powinny zawieraæ linie:
<P>
<PRE>
  permit 192.168.2.0 255.255.255.0
</PRE>

by zezwoliæ wszystkim komputerom z sieci 192.168.2.xxx na u¿ycie
tego serwera po¶rednicz±cego zamiast tego który zosta³ zakazany (np.
serwer plików i dostêp do WWW z sieci Troop).
<P>
<P>W sieci Troop w pliku <CODE>sockd.conf</CODE> powinien wygl±daæ w ten
sposób:
<P>
<PRE>
  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
</PRE>
<P>a w sieci Mercenary mniej wiêcej tak:
<P>
<PRE>
  deny 192.168.2.23 255.255.255.255
  permit 192.168.2.0 255.255.255.0
</PRE>
<P>To powinno zakoñczyæ konfiguracjê wszystkiego. Ka¿da z sieci jest
izolowana, z prawid³owymi ustawieniami interakcji. Ka¿dy powinien byæ
szczê¶liwy.
<P>Dalej... Podbij ¶wiat... 
<H2><A NAME="s10">10. Od t³umacza.</A></H2>

<P>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 <CODE>firewall</CODE> i <CODE>¶ciana ogniowa</CODE>
oraz <CODE>proxy</CODE> i <CODE>serwer po¶rednicz±cy </CODE> traktujê 
(przynajmniej na razie) zamiennie. (choc ju¿ wiêkszo¶æ polskich
odpowiedników (na ¿yczenie publiczno¶ci) usun±³em. 
<P>Celowo pozostawiam tekst bez zwyczajowego (c) t³umacza ;-) 
<P>
</BODY>
</HTML>
doc-linux-pl-html 2002.06.14-3 / usr / share / doc / HOWTO / pl-html / Firewall-HOWTO.pl.html
