Firewalle i proxy serwery
v.0.1 8 lipiec 1997
Mark Grennan,
markg@netplus.net
t³umacz: Ziemek Borowski <ziembor@ziembor.waw.pl>
v0.4, 8 listopad 1996
Dokument ten powsta³ w celu uczenia podstaw systemów firewalli
oraz dostarczenia niektórych szczegó³ów w zakresie ustawania
(konfigurowania) filtruj±cych i posredniczacych firwalli na Linuxie.
Oryginalna wersja tego dokumentu znajduje siê pod
adresem:
<http://okcforum.org/~markg/Firewall-HOWTO.html>
za¶ polskie t³umaczenie:
<http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html>
______________________________________________________________________
Table of Contents:
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_: <<mmaarrkkgg@@nneettpplluuss..nneett>
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-2 HOWTO <http://www.ippt.gov.pl/~ppogorze/Linux/JTZ/zrobione/>
· The Ethernet HOWTO
· The Multiple Ethernet Mini HOWTO
· Networking with Linux
· The PPP HOWTO
· TCP/IP Network Administrator's Guide by O'Reilly and
Associates
· The Documentation for the TIS Firewall Toolkit
Wêze³ pajêczyny nale¿±cy do Trusted Information System's (TIS)
posiada wspania³a
kolekcjê dokumentacji dotycz±cej firewalli i pokrewnych tematów.
Poza tym pracujê na projektem dotycz±cym bezpieczeñstwa:
,,Bezpieczny Linux''. W miejscu tym zgromadzi³em wszystkie
informacje, dokumentacje i programy
potrzebne do stworzenia bezpiecznego Linuxa. Napisz do mnie je¶li
chcesz otrzymaæ wiêcej informacji.
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 ( <<hhttttpp::////wwwwww..ttiiss..ccoomm>)
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
modemowego do twojego IPS. Spójrz na skrypt ipup-pop
Je¶li u¿ywasz modemu do ³±czenia siê z sieci± twój zewnêtrzny adres
bêdzie
przydzielony w trakcie po³±czenia.
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: <<ffttpp::////ffttpp..ttiiss..ccoomm//>.
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 <<ffttpp::////ffttpp..eeddeellwweebb..ffrr//ppuubb//ccoonnttrriibb//ffwwttkk//ssssll--ggww..ttaarr..ZZ>
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
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 serwerów proxy.
W naszym przyk³adzie u¿ywamy
tylko jednego. Ale mo¿esz mieæ wiele w celu zwiêkszenia
przepustowo¶ci
i obni¿enia mo¿liwo¶ci awarii.
Pola adresu IP i maski dzia³aj± jak w innych przyk³adach.
Specyfikujesz adres i zakres jego obowi±zywania.
88..22..33..
UUssttaawwiieenniiee uuss³³uuggii DDNNSS zzzzaa ffiirreewwaallllaa jjeesstt pprroossttyymm
zzaaddaanniieemm.. PPoottrrzzeebbaa jjeeddyynniiee uussttaawwiieenniiaa DDNNSS nnaa mmaasszzyynniiee zz ffiirreewwaalllleemm..
II iinnnnee mmaasszzyynnyy zzaa ffiirreewwaalllleemm bbêêdd±± ggoo uu¿¿yywwaa³³yy..
DDNNSS zzzzaa ffiirreewwaallllaa
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.
serwer plików i dostêp do WWW z sieci Troop).
W sieci Troop w pliku sockd.conf powinien wygl±daæ w ten
sposób:
deny 192.168.2.17 255.255.255.255
deny 0.0.0.0 0.0.0.0 eq 80
permit 192.168.2.0 255.255.255.0
a w sieci Mercenary mniej wiêcej tak:
deny 192.168.2.23 255.255.255.255
permit 192.168.2.0 255.255.255.0
To powinno zakoñczyæ konfiguracjê wszystkiego. Ka¿da z sieci jest
izolowana, z prawid³owymi ustawieniami interakcji. Ka¿dy powinien byæ
szczê¶liwy.
Dalej... Podbij ¶wiat...
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 ;-)
