Konfiguracja sieci amatorskich

Piotr Zawadzki

9 lutego 2004 roku

Spis treści

Podstawowe wiadomości o sieciach TCP/IP

Założenia

Konfiguracja rutera i ściany ogniowej

3.1

Typy routerów i ścian ogniowych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1

Tardycyjne proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2

Przeźroczyste proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.3

Maskarada i NAT

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

Dostęp do Internetu przez modem

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1

Linia dzierżawiona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.2

SDI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.3

Neostrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

Maskarada i firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.1

Idea działania filtru pakietów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.2

Idea działania translacji adresów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.3

Przykładowa konfiguracja ściany ogniowej i maskarady . . . . . . . . . . . . . . . . . . . .

Konfiguracja usług na serwerze

4.1

Serwer DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.1

Konfiguracja serwera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.2

Konfiguracja klienta w Linuksie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.3

Konfiguracja klienta w Windows 98

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2

Serwer DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3

Serwer plików i drukowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1

Konfiguracja serwera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.2

Klient SMB w Linuksie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.3

Klient SMB w Windows 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4

Serwis graficznych terminali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.1

Konfiguracja karty sieciowej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.2

Serwer TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.3

Serwer NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.4

Serwer czczionek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.5

Logi systemowe stacji

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.6

Serwer XDMCP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.7

Konfiguracja LTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5

Dostęp zdalny przez SSH

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6

Serwer HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7

Serwer pocztowy Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7.1

Ochrona przed spamem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7.2

Ograniczenie dostępu do serwera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

klasa

adr. pocz. (bin)

adr. pocz. (dec)

adr. koń. (bin)

adr. koń. (dec)

0 0000000

0 1111110

126

loop-back

0 1111111

127

0 1111111

127

10 000000

128

10 111111

191

110 00000

192

110 11111

223

1110 1111

224

1110 1111

239

11110 111

240

11110 111

247

Tab. 1: Podział przestrzeni adresowej IP na klasy

Klasa

netmask

podział adresu

przykładowy adres hosta

adres sieci

255.0.0.0

N.H.H.H

10.0.1.123

10.0.0.0

255.255.0.0

N.N.H.H

157.158.1.3

157.158.0.0

255.255.255.0

N.N.N.H

200.150.189.31

200.150.189.0

Tab. 2: Przykłady adresów IP należących do różnych klas

Podstawowe wiadomości o sieciach TCP/IP

Protokół

IP (ang. Internet Protocol ) jest beztsanowym protokołem warstwy sieciowej. Adres komputera w

sieciach IP stanowią 4 bajty. W sieciech IP adres komputera musi być unikalny, stąd adresy są centralnie
przydzielane.

Internet to sieć szkieletowa łącząca sieci komputerowe rozmieszczone na całym świecie. W takich warunkach

trudno sobie wyobrazić centralny przydział adresów IP dla stacji końcowych. Z tego względu sieciom przyłą-
czonym do Internetu przydzielane są zakresy adresów, zaś sprawa przydziału adresu IP do konkretnej stacji
jest sprawą administratora sieci lokalnej. Stąd podział adresu IP na część związaną z siecią i część związaną
z adresem hosta (właśnie tą część ustala administrator sieci lokalnej). Zależnie od rozmiaru sieci lokalnej admi-
nistrator może ubiegać się o przydział adresu klasy A – 2

adresów, klasy B – 2

adresów lub klasy C – 2

adresów. O tym czy dany adres sieciowy należy do określonej klasy decyduje kilka najstarszych bitów pierwszego
bajtu adresu IP. Taka organizacja adresów zapewnia łatwe sterowanie ruchem pakietów. Odpowiednie zależności
ilustruje Tab. T:klasyIP Przykładowe adresy poszczególnych klas ilustruje Tab. T:PrzykladyIP Dla sieci klasy
A i B liczba hostów jest olbrzymia (2

− 2 i 2

− 2, odpowiednio). Oczywiście zarządzanie tak wielkimi sieciami

jest bardzo trudne. Dlatego dopuszczono „wewnętrzny” podział sieci na podsieci. Koncepcja jest bardzo prosta,
pożyczamy cześć bitów z części adresującej hosta i traktujemy je jako adres sieci. I tak np. jeżeli dla sieci klasy
B pożyczymy jeden bajt, to maska podsieci wyniesie 255.255.255.0. Dzięki takiej operacji przekształciliśmy sieć
klasy B w 2

− 2 podsieci klasy C. Musimy odjąć 2 bowiem podsieć o numerze x.x.0 miałaby adres identyczny

z adresem sieci „matki”, zaś bajt o wartości 255 zarezerwowany jest na broadcast (rozgłoszenie do wszystkich
stacji w podsieci). Ciężar zarządzania podsieciami spoczywa na właścicielu adresu klasy B. Utworzone podsieci
mają dostęp do internetu za pośrednictwem właściciela adresu B.

Oczywiście, możliwe jest wydzielenie podsieci ustalając podział adresu na część sieciową i „hostową” we-

wnątrz z któregoś bajtów. Dla objaśnienia rozważmy podział sieci klasy C na podsieci. Wydzielmy najstarsze
3 bity ostatniego bajtu na część sieciową. Wówczas maska sieci wyniesie 255.255.255.224 (ostatni bajt binarnie
11100000). Numery powstałych w ten sposób podsieci oraz odpowiadający im zakres adresów hostów przedsta-
wia Tab. T:PodsieciIP Wprowadzenie adresu podsieci powoduje, że nie możemy już wnioskować o masce podsieci

maska (bin)

maska (dec)

adr. pocz. (dec)

adr. koń. (dec)

001 00000

010 00000

011 00000

126

100 00000

128

129

158

101 00000

160

161

190

110 00000

192

193

223

Tab. 3: Lista dostępnych podsieci dla maski 255.255.255.224.

na podstawie jej numeru IP. Stąd często stosuje się zapis adresów sieci w postaci ¡adres IP¿/¡liczba bitów maski
ustawionych na 1¿ czyli tzw. notacji CINR (ang. ). Oznacza to, że adresy IP sieci z Tab. T:PrzykladyIP możemy
zapisać jako 10.0.0.0/8, 157.158.0.0/16, 200.150.189.0/24.

Rozważmy konfigurację piątej z rozważanych podsieci (przypuśćmy, że podsieć w której wprowadzono po-

dział ma adres 157.158.17.0): adres podsieci – 157.158.17.160, maska podsieci – 255.255.255.224 (lub inaczej
adres podsieci – 157.158.17.160/21) adresy hostów – 157.158.17.161÷190, adres rozgłoszeniowy (broadcast) –
(157.158.17.160) + ¬ (255.255.255.244) = 157.158.17.191.

Powyższy przykład ilustruje również „utratę” adresów IP przy podziale na podsieci. Gdy sieć 157.158.17.0

potraktujemy jako sieć klasy C, to mamy do dyspozycji 2

− 2 = 254 adresy IP dla stacji. Tymczasem proste

sumowanie poprawnych adresów z Tab. T:PodsieciIP prowadzi do liczby 180. Oto gdzie tracimy dostępne adresy:

• mamy 6 podsieci a więc tracimy 6 × 2 = 12 adresów na adresy sieci i broadcasty,

• ze względu na to, że nie może być podsieci o numerze 0 tracimy 32 adresy (0 ÷ 31),

• tracimy również adresy powyżej 224 bowiem nie może być podsieci o numerze 11100000 (binarnie) tj. 31

adresów.

Sumując otrzymujemy liczbę 76.

Część adresów IP została wydzielona z puli przydzielanych adresów i żaden host (czy inne urządzenie siecio-

we) podłączone bezpośrednio do internetu nie może mieć takiego adresu IP. Te wydzielone pule adresów mogą
być używane wewnętrznie w sieciach lokalnych jednak nie mogą być „widziane” z zewnątrz. Adresy wydzielonych
sieci to: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

Założenia

Często spotykanym przypadkiem dostępu do internetu jest wykorzystywanie jednego statycznego numeru IP
przez grupę ludzi. Sytuacja występuje w małych firmach, szkołach, amatorskich sieciach osiedlowych czy dostępie
przez SDI czy Neostradę zaliczanych do rozwiązań HSI (ang. Home Internet Solution).

Komputer stanowiący wyjście na świat pełni jednocześnie rolę routera, ściany ogniowej (ang. firewall) i ewen-

tualnie serwera proxy. W małych firmach lub szkołach ze względu na ograniczone zasoby finansowe komputer
dostępowy może również świadczyć dodatkowe usługi dla sieci zewnętrznej (np. udostępniać strony WWW czy
konta pocztowe) i/lub sieci wewnętrznej (np. być serwerem plików i drukarek). Komputery w sieci wewnętrznej
mają przydzielone nierutowalne adresy IP, zazwyczaj z puli 192.168.x.x i przyłączone są poprzez hub lub switch
do interfejsu eth0 routera. Drugim interfejsem routera, stanowiącym wyjście na świat jest dzierżawiona linia
telefoniczna z przydzielonym statycznym numerem IP. Ruch poprzez łącze modemowe odbywa się przez interfejs
ppp0.

Konfiguracja rutera i ściany ogniowej

3.1

Typy routerów i ścian ogniowych

W zależności od konfiguracji routera i ściany ogniowej możemy mieć trzy różne konfiguracje dostępu do internetu
z sieci wewnętrznej.

3.1.1

Tardycyjne proxy

Cały ruch pomiędzy stacjami z sieci wewnętrznej i internetem jest blokowany przez router/firewall. Na kom-
puetrze zapewniającym dostęp do Internetu routing jest wyłączony. Wyjście na świat zapewniają specjalne
aplikacje, tzw. serwery proxy uruchomione na firewallu pełniące rolę pośredników między internetem a siecią
wewnętrzną. Każda usługa wymaga uruchomienia odpowiedniego serwera proxy. Typowym przykładem serwera
proxy dla protokołu HTTP (ang. Hypertext Transfrer Protocol ) jest squid. Roważmy scenariusz korzystania z
przeglądarki internetowej na stacji w sieci wewnętrznej.

• Niech sieć wewnętrzna ma adres 192.168.1.0/24, interfejs eth0 stacji 192.168.1.100 a interfejs eth0 routera

192.168.1.254, a adres statyczny adres IP routera ma wartość 1.2.3.4.

• Serwer proxy HTTP jest uruchomiony na routerze i przyjmuje połączenia tylko z sieci wewnętrznej na

porcie 8080.

• Przeglądarka internetowa na stacji jest skonfigurowana do korzystania z serwera proxy o adresie 192.168.1.254:8080.

W takiej konfiguracji ani stacja nie musi mieć skonfigurowanego DNS ani bramy zewenętrznej. Na routerze nie
musi pracować serwer DNS. Scenariusz łączności wygląda następująco:

• przeglądarka łączy się z serwerem proxy i prosi o sciągnięcie strony z zadanego adresu, np. http://www.polsl.gliwice.pl

(157.158.1.3).

• serwer proxy łączy się z http://www.polsl.gliwice.pl i przesyła wynik do stacji.

W powyższym scenariuszu stacja widzi połączenia

192.168.1.100:<port> <-> 192.168.1.1:8080

natomiast serwer z którego pobrano stronę

157.158.1.3:80 <-> 1.2.3.4:<port>

3.1.2

Przeźroczyste proxy

Cały ruch pomiędzy stacjami z sieci wewnętrznej i internetem jest blokowany przez router/firewall. Wyjście na
świat zapewniają specjalne aplikacje, tzw. serwery proxy uruchomione na firewallu pełniące rolę pośredników
między internetem a siecią wewnętrzną. Każda usługa wymaga uruchomienia odpowiedniego serwera proxy na
firewallu. Typowym przykładem serwera proxy dla protokołu HTTP działającego w tym trybie jest transproxy.
Roważmy scenariusz korzystania z przeglądarki internetowej na stacji w sieci wewnętrznej.

• Niech sieć wewnętrzna ma adres 192.168.1.0/24, interfejs eth0 stacji 192.168.1.100 a interfejs eth0 routera

192.168.1.254, a adres statyczny adres IP routera ma wartość 1.2.3.4.

• Serwer proxy HTTP jest uruchomiony na routerze i przyjmuje połączenia z sieci wewnętrznej na porcie

8080. Jądro systemu na routerze jest tak skonfigurowane, że połączenia na port 80 są automatycznie
przekierowane na port 8080. Na routerze uruchomiony jest również serwer DNS (ang. Domain Name
Service) pracujący w trybie tradycyjnego proxy (ang. caching nameserver ).

• Stacja robocza ma ustawione jako serwer DNS i domyślną bramę adres wewnętrzny routera.

• Przeglądarka internetowa na stacji jest skonfigurowana jak do bezpośredniego podłączenia do Internetu.

Scenariusz łączności wygląda następująco:

• przeglądarka łączy się z proxy DNS 192.168.1.254:53 w celu znalezienia adresu IP serwera www.polsl.gliwice.pl,

• serwer DNS na routerze przekazuje żądanie do swojego serwera DNS w Internecie i zwraca odpowiedź do

stacji 192.168.1.100,

• stacja łączy się z adresem 157.158.1.3:80 poprzez domyślna bramę czyli 192.168.1.254,

• brama automatycznie przekierowuje połączenia z portem 80 na port 8080,

• połączenie przejmuje proxy, łączy się z adresu 1.2.3.4.¡proxyport¿ na 157.158.1.3:80. Odpowiedź odsyła

do do stacji.

W powyższym scenariuszu stacja widzi połączenia

192.168.1.100:<port> <-> 157.158.1.3:80

natomiast serwer z którego pobrano stronę

157.158.1.3:80 <-> 1.2.3.4:<proxyport>

3.1.3

Maskarada i NAT

W tej konfiguracji stacje z sieci wewnętrznej mogą wymieniać pakiety z Internetem. Oprogramowanie routera
tak modyfikuje ich zawartość, że na zewnątrz wyglądają tak jak gdyby pochodziły z routera, natomiast dla
stacji wewnętrznych wyglądają tak jak gdyby pochodziły bezpośrednio z hostów internetowych. Opisany proces
przekształcania pakietów nazywamy translacją adresów NAT! (ang. NAT! ). Jeżeli translacja adresów dotyczy
interfejsu o dynamicznie przydzielanym adresie IP to nazywamy ją maskaradą. Roważmy scenariusz korzystania
z przeglądarki internetowej na stacji w sieci wewnętrznej.

• Niech sieć wewnętrzna ma adres 192.168.1.0/24, interfejs eth0 stacji 192.168.1.100 a interfejs eth0 routera

192.168.1.254, a adres statyczny adres IP routera ma wartość 1.2.3.4.

• Jądro systemu na routerze jest tak skonfigurowane, że pakiety przekazywane między interfejsami ppp0 i

eth0 są przekształcane przez moduł NAT.

• Stacja robocza ma ustawione jako serwer DNS i domyślną bramę na routerze.

• Przeglądarka internetowa na stacji jest skonfigurowana jak do bezpośredniego podłączenia do Internetu.

Scenariusz łączności wygląda następująco:

• przeglądarka łączy się z DNS 192.168.1.254:53 w celu znalezienia adresu IP serwera www.polsl.gliwice.pl.

• serwer DNS na routerze przekazuje żądanie do swojego serwera DNS w Internecie i zwraca odpowiedź do

stacji 192.168.1.100,

• stacja 192.168.1.100:¡port¿ łączy się z adresem 157.158.1.3:80 poprzez domyślna bramę czyli 192.168.1.1,

• pakiety przekazywane są na interfejs ppp0 i przekształcane przez oprogramowanie tak jak gdyby ich

nadawcą był router 1.2.3.4:¡masqport¿, i wysyłane do 157.158.1.3:80,

• odpowiedź nadchodzi więc na port 1.2.3.4:¡masqport¿ i przekazywane przez interfejs eth0 do 192.168.1.100:¡port¿.

W powyższym scenariuszu stacja widzi połączenia

192.168.1.100:<port> <-> 157.158.1.3:80

natomiast serwer z którego pobrano stronę

157.158.1.3:80 <-> 1.2.3.4:<masqport>

W powyższej konfiguracji można pominąć konfigurację serwera DNS na routerze. Na stacji można ustawić
dowolny DNS z sieci zewnętrznej. Zapytanie i opdowiedź zostaną, podobnie jak komunikacja z serwerem WWW,
w sposób przeźroczysty przekazane przez maskaradę.

3.2

Dostęp do Internetu przez modem

Dostęp do Internetu uzyskamy korzystając z protokołu PPP (pakiet ppp). Konfiguracja jest nieco odmienna dla
dostępu przez linię dzierżawioną (brak numeru na który należy się dodzwonić) oraz przez SDI.

3.2.1

Linia dzierżawiona

3.2.2

SDI

Inicjalizację połączenia PPP wykonuje następujący skrypt

*** /usr/sbin/ppp-on
#!/bin/sh
LOCAL_IP=0.0.0.0 # Local IP address if known. Dynamic = 0.0.0.0
REMOTE_IP=0.0.0.0 # Remote IP address if desired. Normally 0.0.0.0
NETMASK=255.255.255.0 # The proper netmask if needed
DIALER_SCRIPT=/etc/ppp/dialer
exec /usr/sbin/pppd lock modem crtscts /dev/modem 115200 \
$LOCAL_IP:$REMOTE_IP noipdefault netmask $NETMASK

defaultroute connect $DIALER_SCRIPT
***

Pozostawiamy ustawienie dynemiczne adresów. Ich konfiguracja nastąpi poźniej. Skrypt uruchamia demona
pppd z parametrami modemu: /dev/modem powinno być linkiem symbolicznym do urządzenia obsługującego
modem. Za dodzwonienie się do drugiej strony odpowiada DIALER SCRIPT.

*** /etc/ppp/dialer
#!/bin/sh
exec chat -v \
’’AT \
’’AT<user>\
CONNECT ’’

/etc/rc.d/init.d/named restart
***

W powyższym skrypcie ¡user¿ jest nazwą użytkownika z umowy SDI. Konfigurację demona ppp opisują pliki w
katalogu /etc/ppp: options, pap-secrets, chap-secrets

*** /etc/ppp/options
-detach
debug
modem
lock
crtscts
defaultroute
asyncmap 0
mtu 552
mru 552
user <user>
***

*** /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
<user>* <haslo>
***

*** /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client server secret IP addresses
<nazwa>* <haslo>
***

W powyższych plikach ¡user¿ jest nazwą użytkownika a ¡hasło¿ hasłem z umowy SDI. Czasami TP S.A. rozłącza
połączenie, dlatego jego odnowienie wygodnie jest umieścić w cronie Skrypt odnawiający połączenie ma postać

*** /etc/ppp/SDI
#!/bin/bash
# SDI reconnect
IS_PPP0_ON=‘ifconfig | grep ppp0 | cut -d \

-f 1‘

case "$IS_PPP0_ON" in

ppp0)

;;

echo "Starting ppp daemon to TPSA by SDI"
/usr/sbin/ppp-off
/usr/sbin/ppp-on >> /tmp/tpsa&
echo $IS_PPP0_ON;;

esac
exit 0
***

a w pliku /etc/crond dodajemy linię

*** /etc/crond
0-59/10 * * * * root /etc/ppp/SDI
***

W końcu ustawiamy serwery nazw TP S.A. w pliku /etc/resolv.conf

*** /etc/resolv.conf
search sdi.tpnet.pl
nameserver 194.204.159.1
nameserver 194.204.152.34
***

Gotowe ustawienia dla SDI można znaleźć w skrypcie ustawSDI

3.2.3

Neostrada

3.3

Maskarada i firewall

W systemie Linux maskarada i ściana ogniowa zrealizowana jako filtr pakietów wbudowana jest w jądro. Sposób
konfiguracji zależy od wersji jądra. W jądrach serii 2.0.x filtr pakietów realizowany był przez ipfw, w wersjach
2.2.x przez ipchains, a wersji 2.4.x przez iptables. Za translację (ang. mangling) adresów odpowiedzialny jest
moduł nat. Zarówno ipfw jak i ipchains są filtrami statycznymi, natomiast iptables jest filtrem dynamicznym,
który potrafi podejmować decyzję co do przepuszczenia lub zablokowania pakietu na podstawie istniejących
połączeń. Ze względu na wyjątkową elastyczność iptables

i powszechność omówimy tylko to narzędzie. Co

więcej iptables umożliwia również translację adresów. Obecnie w iptables funkcjonują trzy tablice reguł:
filter – odpwiedzialna za filtrowanie pakietów, nat – odpowiedzialna za translację adresów oraz intensywnie
rozwijana tablica mangle stanowiąca rozszerzenie nat. Dla każdej tablicy istnieje prefeiniowana lista łańcuchów
z regułami dopasowania pakietów i zestaw dozwolonych operacji na pakiecie dla którego uzyskano dopasowanie.

3.3.1

Idea działania filtru pakietów

Filtr pakietów działa w opraciu o zestaw reguł filtrowania zebranych w tablicy filter. Tablica filter jest
domyślna dlatego nie trzeba jej określać w wywołaniu iptables. Każda z reguł mówi jakie warunki powienien
spełniać pakiet i co z nim zrobić. Pakiet może być zaakceptowany lub odrzucony. Nadawca pakietu może być
poinformowany o odrzuceniu lub nie. O losie pakietu nie pasującego do żadnej z reguł decyduje konfigurowalne
zachowanie domyślne (ang. policy). Filtrowanie odbywa się z wykorzystaniem trzech łańcuchów reguł: INPUT,
FORWARD, OUTPUT. Po odebraniu pakietu podejmowana jest decyzja czy jest on skierowany do hosta czy
też powinien być dla niego wykonany routing. Pakiety skierowane do lokalnego komputera filtrowane są zgod-
nie z regułami w łańcuchu INPUT, natomiast te które powinne być skierowane na inny interfejs sieciowy są
dopasowawywane do reguł z łańcucha FORWARD

. Tylko pakiety wytworzone przez lokalne procesy filtrowa-

ne są zgodnie z regułami łańcucha OUTPUT

. Stosowanie odpowiednich łańcuchów dla komputera z dwoma

interfejsami sieciowymi ilustruje Rys. 1. Opcje iptables można podzielić na trzy zasadnicze grupy:

• zarządzanie regułami w łańcuchach filtrujących,

• określenie losu pakietu,

• specyfikacja wzorca dopasowania.

Najczęściej używanymi opcjami związanymi z zarządzaniem regułami są komendy: kasująca wszystkie reguły
zebrane w tablicy oraz dodająca wzorzec do zadanego łańcucha

iptables -F
iptables -A <łańcuch>

http://157.158.17.48/˜pz/zajecia/Linux/repository/ustawSDI/

iptables jest uważany za jeden z najlepszych filtrów pakietów.

Jest to jedna z różnic w stosunku do ipchains, gdzie decyzja o routowaniu podejmowana była dopiero po filtracji regułami

INPUT

W ipchains dopasowanie do reguł OUTPUT stosowane było również do pakietów które przetrwały filtrację regułami FOR-

WARD.

ppp0

FORWARD

eth0

INPUT

OUTPUT

siec

lokalne procesy

INPUT

OUTPUT

Rys. 1: Schemat filtrowania pakietów w iptables

Los pakietu pasującego do wzorca określa opcja -j lub domyślne zachowanie gdy dla pakietu nie zostało zna-
lezione dopasowanie. Los pakietu wyznaczają wartości ACCEPT, REJECT, DROP odpowiednio oznaczające
zaakceptowanie pakietu, jego odrzucenie i poinformowanie nadawcy o tym fakcie oraz odrzucenie bez infor-
mowania nadawcy. Domyślny los pakietu określa tzw. polityka (ang. policy) dla danego łańcucha. Pakiety dla
których nie znaleziono dopasowania w łańcuchu są obsługiwane zgodnie z domyślną polityką. Podobnie jak przy
dopasowaniu możliwe są trzy rodzaje polityki: ACCEPT, REJECT i DROP.

iptables -P <łańcuch> <polityka>
iptables -j <los_pakietu>

Wzorzec dopasowania określa parametry pakietu obejmujące specyfikację hosta źródłowego (-s), hosta docelo-
wego (-d), protokołu (-p), oraz szeregu dodatkowych parametrów zależnych od protokołu (np. dla protokołów
TCP i UDP można określać porty źródłowy i docelowy opcjami --source-port i --destination-port). Cechą
charakterystyczną iptables jest możliwość rozszerzenia funkcjonalności filtru przy użyciu modułów. Jednym
z najbardziej użytecznych jest moduł state który pozwala na podjęcie decyzji o dopasowaniu pakietu na podsta-
wie wcześniej wykonywanych połączeń. Pakiety przekazywane do modułu state klasyfikowane są na 3 kategorie:
NEW, ESTABLISHED, RELATED. Pakiety z kategorii NEW to pakiety inicjujące połączenie, a pakiety ESTA-
BLISHED to pakiety wymieniane w ramach już istniejących połączeń. Pakiety RELATED to pakiety nowych
połączeń wynikających w sposób logiczny z zasady funkcjonowania serwera danej usługi. Innym przydatnym
modułem jest psd pozwalający wykrycie skanowania portów na serwerze. Niestety obecnie

nie jest on dostęp-

ny w standardowych instalacjach większości dystrybucji. Moduły ładowane są opcją -m. Więcej informacji na
temat dostępnych opcji, modułów oraz korzystania z iptables można znaleźć na stronie domowej projektu.
Przykładową konfigurację zamieszczono w Pkt. 3.3.3.

3.3.2

Idea działania translacji adresów

Reguły translacji adresów zebrane są w tablicy nat. Tabela zawiera łańcuchy PREROUTING i POSTRO-
UTING. Miejsce ich zastosowania w procesie routowania pakietów ilustruje Rys. 2. W łańcuchu POSTRO-
UTING możliwe są dwie akcje wykonywane na pakietach: SNAT i MASQUERADE. Obie w zasadzie wykonują
to samo: w pakietach dla których uzyskano dopasowanie adres źródłowy pakietu jest zamieniany na adres in-
terfejsu na którym pakiet opuści hosta. Jednocześnie utrzymywana jest informacja o wykonanym połączeniu
i w pakietach przychodzących adres docelowy jest zamieniany na adres komputera z sieci wewnętrznej który
zainicjował połączenie. Opcja MASQUERADE ma zastosowanie gdy interfejs wyjściowy ma dynamicznie przy-
dzielany adres IP. Dla statycznych adresów IP należy stosować akcję SNAT. Akcję SNAT należy uzupełnić opcją
--to-source określającą adres wstawiony w pole adresu źródłowego. Ruch rutowany z sieci wewnętrznej dla
którego zastsowano translację adresów źródłowych wygląda tak. jakby był incjowany z interfejsu wyjściowego
routera (ppp0 w rozważanej konfiguracji).

Czasami jesteśmy zainteresowani sytuacją odwrotną. Mamy w sieci wewnętrznej serwer usługi i chcemy go

udostępnić komputerom z internetu. Jeżeli serwer ma adres z nieroutowalnego zakresu, jedynym sposobem na
jego udostępnienie jest zastosowanie na komputerze dostępowym translacji adresów docelowych. Translację tą
określamy przy użyciu wzorców wpisanych do łańcucha PREROUTING. Jedyną dozwoloną akcją jest DNAT
z opcją --to-destination określającą adres na który zostanie przekierowany ruch z zadanego portu interfej-
su dostępowego. Przykłady użycia MASQUEARDE, SNAT, DNAT można znaleźć w przykładowym skrypcie
inicjującym ścianę ogniową.

25 stycznia 2004

ppp0

INPUT

OUTPUT

FORWARD

POSTROUTING

PREROUTING

siec

POSTROUTING

PREROUTING

eth0

INPUT

OUTPUT

lokalne procesy

Rys. 2: Schemat translacji adresów w iptables

3.3.3

Przykładowa konfiguracja ściany ogniowej i maskarady

Konfiguracja routera pomiędzy siecią wewnętrzną i internetem składa się z następujących kroków:

• włączenie mechanizmów bezpieczeństwa chroniących przed typowymi atakami,

• wyblokowanie portów zapobiegających przed podszywaniem się pod nieprawdziwe adresy IP (ang. IP

spoofing ),

• zezwolenie na routowanie i włączenie maskarady,

• zezwolenie na korzystanie z usług włączonych na firewallu np. serwis www, ssh do zdalnej administracji,

itp.,

• uaktywnienie dostępu do usług świadczonych dla sieci wewnętrznej.

Przykładowy skrypt zamieszczono poniżej.
– /etc/rc.d/rc.firewall –

#!/bin/sh

# Przykladowa, restrykcyjna konfiguracja iptables dla Linuxa 2.4.
# Ten skrypt zawiera rowniez funkcje zmniejszajace szanse odciecia
# sobie dostepu do danego hosta podczas zdalnej konfiguracji.
# Pawel Krawczyk <kravietz AT aba.krakow.pl> 2001
# Adaptacja i uzupelnienia
# Piotr Zawadzki <pzawad@ps.edu.pl> 2004

# Opcje skryptu:
# flush - czysci wszystkie regulki i ustawia otwarta polityke
# temp

- konfiguruje tymczasowe regulki (patrz ponizej)

# bez opcji - konfiguruje iptables

# Kolejnosc operacji:
#

1. zerowanie wszystkich tablic

2. ustawienie restrykcyjnej polityki DROP

3. ustawienie specjalnego dostepu dla interfejsu lo

4. ustawienie specjalnego dostepu dla sieci LAN

5. konfiguracja modulu unclean

6. ustawienie odrzucania polaczen dla IDENT i SOCKS

7. zezwolenie dla pakietow ICMP Echo (ping)

8. konfiguracja stateful-inspection (modul state)

9. ustawienie dostepu dla konkresnych uslug

# 10. konfiguracja NAT i PAT
# 11. konfiguracja logowania zablokowanych pakietow

export PATH=""

# Interfejs zewnętrzny
OUTDEV="eth0"

OUTIP="157.158.17.48"
OUTBCAST="157.158.17.255"
OUTMASK="255.255.255.0"

# Interfejs sieci wewnętrznej
INTDEV="eth1"
INTIP="192.168.2.254"
INTBCAST="192.168.2.255"
INTMASK="255.255.255.0"

iptables_flush()
{
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -F
}
if [ "$1" = "flush" ]; then
iptables_flush
exit 0
fi

# Bezpieczne wywolanie iptables, gwarantujace ze
# nasze regulki zostana zaladowane albo w calosci
# albo w ogole. Zapobiega to sytuacji, kiedy tracimy
# dostep do danego hosta z powodu jednej, zle skonstruowanej
# regulki ktora miala nas do niego wpuszczac ;)
iptables() {
echo -n .
/sbin/iptables $@
if [ "$?" != "0" ]; then
iptables_flush
exit 1
fi
}

# Mozemy wlaczyc nasze nowe regulki tylko na chwile.
# Pozwala to sprawdzic, czy po ich uzupelnieniu nadal
# mamy dostep do hosta, jesli nie to automatycznie
# odzyskamy go po 30 sekundach. Skrypt nalezy tylko
# wywolac z opcja "temp".
if [ "$1" = "temp" ]; then
(sleep 30; /sbin/iptables -P INPUT ACCEPT ;\

/sbin/iptables -P OUTPUT ACCEPT ;\
/sbin/iptables -P FORWARD ACCEPT ;\
/sbin/iptables -F) &

# Zapisz wartosc do pliku
store_in_file() {

if [ -e $1 ] ; then

echo $2 > $1

}

# Włączenie routowania, załadowanie modułów
init_router() {

# Włącz routing pakietów
store_in_file /proc/sys/net/ipv4/ip_forward 1

# Zablokuj IP Spoofing
# Włącz Source Address Verification

store_in_file /proc/sys/net/ipv4/conf/all/rp_filter 1

# Ochrona przed atakami na kod defragmentacji pakietów
# tzw. SYN COOKIES
store_in_file /proc/sys/net/ipv4/tcp_syncookies 1

# Pakiety z niemożliwymi adresami IP
store_in_file /proc/sys/net/ipv4/conf/all/log_martians 1

# Wyłącz przekierowanie pakietów ICMP
store_in_file /proc/sys/net/ipv4/conf/all/accept_redirects 0

# Wyłącz source routing
store_in_file /proc/sys/net/ipv4/conf/all/accept_source_route 0

# Nie odpowiadaj na rozgłoszenia ICMP
store_in_file /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 1
}

init_scan_detect() {

if [ -f /lib/modules/‘/bin/uname -r‘/kernel/net/ipv4/netfilter/ipt_psd.o ]; then

iptables -A INPUT -m psd -m limit --limit 5/minute -j LOG

else

iptables -A INPUT -p icmp --icmp-type echo-request -m limit \
--limit 5/minute -j LOG --log-prefix "##PingScan##"
# high rate for stealth scans, since they could be legitimate connection
# attempts as well
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST \
-m limit --limit 1/s --limit-burst 5 -j LOG --log-level info \
--log-prefix "##StealthScan##"
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \
--limit 5/m -j LOG --log-level info --log-prefix "##XMASScan##"
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -m limit \
--limit 5/m -j LOG --log-level info --log-prefix "##SYN/RSTScan##"
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \
--limit 5/m -j LOG --log-level info --log-prefix "##SYN/FINScan##"

}

#######################################################################

echo -n "Installing IPtables ruleset"

# Ladujemy modul stateful-inspection dla FTP
/sbin/modprobe ip_conntrack_ftp

# Czyscimy wszystkie tablice
iptables -F
iptables -F -t nat

# Domyslnie nie wpuszczamy i nie przepuszczamy nic, wypuszczamy wszystko
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# aktywujemy przekazywanie pakietów oraz modułu filtrujace
init_router

# instalujemy reguły informujace o scanowaniu portów
init_scan_detect

# Interfejs lokalny ma specjalne prawa
iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT

# Wypuszczamy wszystko na do sieci wewnętrznej i zewnetrznej
# (o ile tylko pochodzi z serwera)
iptables -A OUTPUT -s $INTIP/32 -j ACCEPT
iptables -A OUTPUT -s $OUTIP/32 -j ACCEPT

# Logujemy pakiety wyblokowane przez modul unclean
iptables -A INPUT -j LOG -m limit --limit 10/hour -m unclean --log-prefix "INP-Unclean:"
iptables -A INPUT -j DROP -m unclean
iptables -A OUTPUT -j LOG -m limit --limit 10/hour -m unclean --log-prefix "OUT-Unclean:"
iptables -A OUTPUT -j DROP -m unclean
iptables -A FORWARD -j LOG -m limit --limit 10/hour -m unclean --log-prefix "FWD-Unclean:"
iptables -A FORWARD -j DROP -m unclean

# Odrzucamy z komunikatem ICMP Port Unreachable polaczenia
# na IDENT oraz SOCKS (czesto sprawdzane przez serwery IRC)
iptables -A INPUT -p tcp --dst 0/0 --dport 113 \
-j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p tcp --dst 0/0 --dport 1080 \
-j REJECT --reject-with icmp-port-unreachable

# Akceptujemy pakiety ICMP Echo (ping) wchodzace i wychodzace
# Akceptacja odpowiedzi jest realizowana przez modul state RELATED
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT

# Zezwalamy na wszystko co odbywa sie w ramach juz dozwolonych
# polaczen
iptables -A INPUT -p tcp -j ACCEPT -m state --state ESTABLISHED
iptables -A INPUT -p udp -j ACCEPT -m state --state ESTABLISHED
iptables -A INPUT -p icmp -j ACCEPT -m state --state ESTABLISHED
iptables -A INPUT -p icmp -j ACCEPT -m state --state RELATED
iptables -A FORWARD -p tcp -j ACCEPT -m state --state ESTABLISHED
iptables -A FORWARD -p tcp -j ACCEPT -m state --state RELATED
iptables -A FORWARD -p udp -j ACCEPT -m state --state ESTABLISHED
iptables -A FORWARD -p icmp -j ACCEPT -m state --state ESTABLISHED
iptables -A FORWARD -p icmp -j ACCEPT -m state --state RELATED
iptables -A OUTPUT -p tcp -j ACCEPT -m state --state ESTABLISHED
iptables -A OUTPUT -p tcp -j ACCEPT -m state --state RELATED
iptables -A OUTPUT -p udp -j ACCEPT -m state --state ESTABLISHED
iptables -A OUTPUT -p icmp -j ACCEPT -m state --state ESTABLISHED
iptables -A OUTPUT -p icmp -j ACCEPT -m state --state RELATED

# Indywidualne regulki akceptujace okreslone porty lub serwery
# Zalecana jest jak najwieksza szczegolowosc tych regulek,
# w razie problemow nalezy posilkowac sie regulkami LOG

# Uslugi dostepne publicznie (dostepne dla wszystkich)
# Uslugi TCP: 80 (http), 22 (SSH), 25 (SMTP), 110 (POP3), 995 (POP3S)
TCP_OUTSIDE_ALLOW=http,ssh,smtp,pop3,pop3s
# Uslugi UDP:
UDP_OUTSIDE_ALLOW=ssh
# Uslugi dostepne publicznie (dostepne dla wszystkich)
iptables -A INPUT -p tcp -j ACCEPT -m state --state NEW -m multiport -s 0/0 -d 0/0 --destination-port $TCP_OUTSIDE_ALLOW
iptables -A INPUT -p udp -j ACCEPT -m state --state NEW -m multiport -s 0/0 -d 0/0 --destination-port $UDP_OUTSIDE_ALLOW

# Uslugi swiadczone dla sieci wewnetrznej
## Serwis LTSP wymaga
TCP_LTSP=sunrpc,x11,xfs
UDP_LTSP=bootps,tftp,sunrpc,32771,nfs,xdmcp,syslog,domain

## Serwis SMB wymaga
TCP_SMB=netbios-ssn
UDP_SMB=netbios-ns,netbios-dgm
# Uslugi dostepne TYLKO dla sieci wenetrznej
TCP_INSIDE_ALLOW=$TCP_LTSP,$TCP_SMB
UDP_INSIDE_ALLOW=$UDP_LTSP,$UDP_SMB
# Uslugi internetowe dostepne z sieci wewnetrznej (wypuszczone z sieci wewnetrznej)
TCP_INTOUT_ALLOW=http,webcache,ssh,pop3s,ftp,pop3,smtp,domain,nntp
UDP_INTOUT_ALLOW=ntp,domain

# Uslugi swiadczone TYLKO dla sieci wewnetrznej
iptables -A INPUT -i $INTDEV -p tcp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $TCP_INSIDE_ALLOW
iptables -A INPUT -i $INTDEV -p udp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $UDP_INSIDE_ALLOW
iptables -A INPUT -i $INTDEV -p udp -j ACCEPT -m state --state NEW \
--destination-port 1024:

# Aktywujemy uslugi wypuszczane z sieci wewnetrznej
#iptables -A OUTPUT -o $OUTDEV -p tcp -j ACCEPT -m state --state NEW \
# -m multiport --destination-port $TCP_INTOUT_ALLOW
#iptables -A OUTPUT -o $OUTDEV -p udp -j ACCEPT -m state --state NEW \
# -m multiport --destination-port $UDP_INTOUT_ALLOW
iptables -A FORWARD -o $OUTDEV -p tcp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $TCP_INTOUT_ALLOW
iptables -A FORWARD -o $OUTDEV -p udp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $UDP_INTOUT_ALLOW

# Przerzucamy port 6699 (Napster) z zewnetrznego interfejsu
# na host w sieci lokalnej (10.1.1.3). Znane jako port
# forwarding lub Port Address Translation
#iptables -t nat -A PREROUTING -p tcp -d 251.61.252.110/32 --dport 6699 \
# -j DNAT --to-destination 10.1.1.3

# Uslugi dostepne z zewnatrz tylko dla zaufanych stacji
iptables -A INPUT -i $OUTDEV -p all -s 157.158.17.139/32 -m mac --mac-source 00:80:48:C5:66:A3 \

-j LOG -m limit --limit 10/hour --log-prefix "TRUSTED"

iptables -A INPUT -i $OUTDEV -p tcp -s 157.158.17.139/32 -m mac --mac-source 00:80:48:C5:66:A3 \

-j ACCEPT -m state --state NEW -m multiport --destination-port $TCP_INSIDE_ALLOW

iptables -A INPUT -i $OUTDEV -p udp -s 157.158.17.139/32 -m mac --mac-source 00:80:48:C5:66:A3 \

-j ACCEPT -m state --state NEW -m multiport --destination-port $UDP_INSIDE_ALLOW

iptables -A INPUT -i $OUTDEV -p udp -s 157.158.17.139/32 -m mac --mac-source 00:80:48:C5:66:A3 \

-j ACCEPT -m state --state NEW --destination-port 1024:

# czat.onet.pl
#iptables -A OUTPUT -o $OUTDEV -p tcp -j ACCEPT -m state --state NEW \
# -d 213.180.130.190 -m multiport --destination-port 5012,5013
#iptables -A FORWARD -o $OUTDEV -p tcp -j ACCEPT -m state --state NEW \
# -d 213.180.130.190 -m multiport --destination-port 5011,5012,5013

# Maskarada (NAT) dla wszystkich hostow z sieci lokalnej
iptables -t nat -A POSTROUTING -p all -s $INTIP/$INTMASK -j MASQUERADE

# Odrzuc rozgłoszenia na interfejsie zewnetrznym (generują dużo logów)
iptables -A INPUT -d $OUTBCAST/32 -j DROP
iptables -A INPUT -d 255.255.255.255/32 -j DROP

# Logujemy pakiety ktore nie zostaly zaakceptowane przez
# zadna z powyzszych regulek. Zostana one wyblokowane dzieki
# polityce DROP we wszystkich tablicach

#iptables -A INPUT -j LOG -m limit --limit 10/hour --log-prefix "INPUTPOLICY"
#iptables -A OUTPUT -j LOG -m limit --limit 10/hour --log-prefix "OUTPUTPOLICY"
#iptables -A FORWARD -j LOG -m limit --limit 10/hour --log-prefix "FORWARDPOLICY"

echo .

W skrypcie tym założono, że host stanowiący bramę na świat świadczy również szereg usług dla sieci wewnętrz-
nej. Z wielu względów bezpieczeństwa taka konfiguracja jest niekorzystna:

• na ścianie ogniowej mamy aktywne konta użytkowników, co znacznie ułatwia zadanie włamywaczowi,

bowiem proces włamania może rozdzielić na dwa etapy: zdobycie dostępu do konta użytkownika z zewnatrz
oraz zdobycia uprawnień administartora zod wewnatrz systemu,

• nieuczciwi użytkownicy mogą próbować przełamać zabezpieczenia systemu,

• na ścianie ogniowej pracuje wiele serwisów, a każdy serwis to potencjalna furtka dla napastnika.

Ze względu na powyższe argumenty o wiele lepszą konfiguracją sieci jest pozostawienie na ścianie ogniowej tylko
funkcji routowania oraz translacji adresów i przeniesienie wszelkich usług świadczonych dla sieci wewnętrznej
i zewnętrznej na wydzielony komputer w sieci wewnętrznej. Przykładowe pliki konfiguracyjne dla iptables na
bramie i serwerze wewnętrznym zamieszczono poniżej.
– /etc/rc.d/rc.firewall.brama –

#!/bin/sh

# Opcje skryptu:
# flush - czysci wszystkie regulki i ustawia otwarta polityke
# temp

- konfiguruje tymczasowe regulki (patrz ponizej)

# bez opcji - konfiguruje iptables

# Kolejnosc operacji:
#

1. zerowanie wszystkich tablic

2. ustawienie restrykcyjnej polityki DROP

3. ustawienie specjalnego dostepu dla interfejsu lo

4. ustawienie specjalnego dostepu dla sieci LAN

5. konfiguracja modulu unclean

6. ustawienie odrzucania polaczen dla IDENT i SOCKS

7. zezwolenie dla pakietow ICMP Echo (ping)

8. konfiguracja stateful-inspection (modul state)

9. ustawienie dostepu dla konkresnych uslug

# 10. konfiguracja NAT i PAT
# 11. konfiguracja logowania zablokowanych pakietow

export PATH=""

# Interfejs zewnętrzny
OUTDEV="eth0"
OUTIP="157.158.17.48"
OUTBCAST="157.158.17.255"
OUTMASK="255.255.255.0"

# Interfejs sieci wewnętrznej
INTDEV="eth1"
INTIP="192.168.2.254"
INTBCAST="192.168.2.255"
INTMASK="255.255.255.0"

# Serwer wewnatrz sieci realizujący usługi dla sieci zewnętrznej
INTERNAL_SERVER="192.168.2.100"

iptables_flush()
{
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -F
}
if [ "$1" = "flush" ]; then
iptables_flush
exit 0
fi

/sbin/iptables -P OUTPUT ACCEPT ;\
/sbin/iptables -P FORWARD ACCEPT ;\
/sbin/iptables -F) &

# Zapisz wartosc do pliku
store_in_file() {

if [ -e $1 ] ; then

echo $2 > $1

}

# Włączenie routowania, załadowanie modułów
init_router() {

# Włącz routing pakietów
store_in_file /proc/sys/net/ipv4/ip_forward 1

# Zablokuj IP Spoofing
# Włącz Source Address Verification
store_in_file /proc/sys/net/ipv4/conf/all/rp_filter 1

# Ochrona przed atakami na kod defragmentacji pakietów
# tzw. SYN COOKIES
store_in_file /proc/sys/net/ipv4/tcp_syncookies 1

# Pakiety z niemożliwymi adresami IP

store_in_file /proc/sys/net/ipv4/conf/all/log_martians 1

# Wyłącz przekierowanie pakietów ICMP
store_in_file /proc/sys/net/ipv4/conf/all/accept_redirects 0

# Wyłącz source routing
store_in_file /proc/sys/net/ipv4/conf/all/accept_source_route 0

# Nie odpowiadaj na rozgłoszenia ICMP
store_in_file /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 1
}

init_scan_detect() {

if [ -f /lib/modules/‘/bin/uname -r‘/kernel/net/ipv4/netfilter/ipt_psd.o ]; then

iptables -A INPUT -m psd -m limit --limit 5/minute -j LOG

else

}

#######################################################################

echo -n "Installing IPtables ruleset"

# Ladujemy modul stateful-inspection dla FTP
/sbin/modprobe ip_conntrack_ftp

# Czyscimy wszystkie tablice
iptables -F
iptables -F -t nat

# Domyslnie nie wpuszczamy i nie przepuszczamy nic, wypuszczamy wszystko
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# aktywujemy przekazywanie pakietów oraz modułu filtrujace
init_router

# instalujemy reguły informujace o scanowaniu portów
init_scan_detect

# Interfejs lokalny ma specjalne prawa
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT

# Wypuszczamy wszystko na do sieci wewnętrznej
# (o ile tylko pochodzi z bramy)
iptables -A OUTPUT -s $INTIP/32 -j ACCEPT

# Indywidualne regulki akceptujace okreslone porty lub serwery
# Zalecana jest jak najwieksza szczegolowosc tych regulek,
# w razie problemow nalezy posilkowac sie regulkami LOG

# Uslugi dostepne publicznie (tylko ssh do zdalnej administracji)
TCP_OUTSIDE_ALLOW=ssh
UDP_OUTSIDE_ALLOW=ssh
iptables -A INPUT -p tcp -j ACCEPT -m state --state NEW -m multiport -s 0/0 -d 0/0 --destination-port $TCP_OUTSIDE_ALLOW
iptables -A INPUT -p udp -j ACCEPT -m state --state NEW -m multiport -s 0/0 -d 0/0 --destination-port $UDP_OUTSIDE_ALLOW

# Usługi dostępne z zewnatrz i przeniesione na wydzielony serwer
TCP_DNAT_SERVICES=http,smtp,pop3,pop3s
iptables -A INPUT -p tcp -j ACCEPT
-m state --state NEW
-m multiport -s 0/0 -d 0/0 --destination-port $TCP_OUTSIDE_ALLOW

# Uslugi internetowe dostepne z sieci wewnetrznej (wypuszczone z sieci wewnetrznej)
TCP_INTOUT_ALLOW=http,webcache,ssh,pop3s,ftp,pop3,smtp,domain,nntp
UDP_INTOUT_ALLOW=ntp,domain

# Aktywujemy uslugi wypuszczane z sieci wewnetrznej
iptables -A OUTPUT -o $OUTDEV -p tcp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $TCP_INTOUT_ALLOW
iptables -A OUTPUT -o $OUTDEV -p udp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $UDP_INTOUT_ALLOW
iptables -A FORWARD -o $OUTDEV -p tcp -j ACCEPT -m state --state NEW \

-m multiport --destination-port $TCP_INTOUT_ALLOW
iptables -A FORWARD -o $OUTDEV -p udp -j ACCEPT -m state --state NEW \
-m multiport --destination-port $UDP_INTOUT_ALLOW

# Maskarada (NAT) dla wszystkich hostow z sieci lokalnej
iptables -t nat -A POSTROUTING -p all -s $INTIP/$INTMASK -j MASQUERADE

# Odrzuc rozgłoszenia na interfejsie zewnetrznym (generują dużo logów)
iptables -A INPUT -d $OUTBCAST/32 -j DROP
iptables -A INPUT -d 255.255.255.255/32 -j DROP

# Logujemy pakiety ktore nie zostaly zaakceptowane przez
# zadna z powyzszych regulek. Zostana one wyblokowane dzieki
# polityce DROP we wszystkich tablicach
#iptables -A INPUT -j LOG -m limit --limit 10/hour --log-prefix "INPUTPOLICY"
#iptables -A OUTPUT -j LOG -m limit --limit 10/hour --log-prefix "OUTPUTPOLICY"
#iptables -A FORWARD -j LOG -m limit --limit 10/hour --log-prefix "FORWARDPOLICY"

echo .

– /etc/rc.d/rc.firewall.serwer –

#!/bin/sh

# Opcje skryptu:
# flush - czysci wszystkie regulki i ustawia otwarta polityke
# temp

- konfiguruje tymczasowe regulki (patrz ponizej)

# bez opcji - konfiguruje iptables

# Kolejnosc operacji:
#

1. zerowanie wszystkich tablic

2. ustawienie restrykcyjnej polityki DROP

3. ustawienie specjalnego dostepu dla interfejsu lo

4. ustawienie specjalnego dostepu dla sieci LAN

5. konfiguracja modulu unclean

6. ustawienie odrzucania polaczen dla IDENT i SOCKS

7. zezwolenie dla pakietow ICMP Echo (ping)

8. konfiguracja stateful-inspection (modul state)

9. ustawienie dostepu dla konkresnych uslug

# 11. konfiguracja logowania zablokowanych pakietow

export PATH=""

# Interfejs zewnętrzny
OUTDEV="eth0"
OUTIP="192.168.2.100"
OUTBCAST="192.168.2.255"
OUTMASK="255.255.255.0"

iptables_flush()
{
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -F
}
if [ "$1" = "flush" ]; then
iptables_flush
exit 0
fi

/sbin/iptables -P OUTPUT ACCEPT ;\
/sbin/iptables -P FORWARD ACCEPT ;\
/sbin/iptables -F) &

# Zapisz wartosc do pliku
store_in_file() {

if [ -e $1 ] ; then

echo $2 > $1

}

# Włączenie routowania, załadowanie modułów
init_kernel_and_modules() {

# Wyłącz routing pakietów
store_in_file /proc/sys/net/ipv4/ip_forward 0

# Zablokuj IP Spoofing
# Włącz Source Address Verification
store_in_file /proc/sys/net/ipv4/conf/all/rp_filter 1

# Ochrona przed atakami na kod defragmentacji pakietów
# tzw. SYN COOKIES
store_in_file /proc/sys/net/ipv4/tcp_syncookies 1

# Pakiety z niemożliwymi adresami IP
store_in_file /proc/sys/net/ipv4/conf/all/log_martians 1

# Wyłącz przekierowanie pakietów ICMP

store_in_file /proc/sys/net/ipv4/conf/all/accept_redirects 0

# Wyłącz source routing
store_in_file /proc/sys/net/ipv4/conf/all/accept_source_route 0

# Nie odpowiadaj na rozgłoszenia ICMP
store_in_file /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 1
}

init_scan_detect() {

if [ -f /lib/modules/‘/bin/uname -r‘/kernel/net/ipv4/netfilter/ipt_psd.o ]; then

iptables -A INPUT -m psd -m limit --limit 5/minute -j LOG

else

}

#######################################################################

echo -n "Installing IPtables ruleset"

# Czyscimy wszystkie tablice
iptables -F
iptables -F -t nat

# Domyslnie nie wpuszczamy i nie przepuszczamy nic, wypuszczamy wszystko
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# aktywujemy przekazywanie pakietów oraz modułu filtrujace
init_kernel_and_modules

# instalujemy reguły informujace o scanowaniu portów
init_scan_detect

# Interfejs lokalny ma specjalne prawa
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT

# Wypuszczamy wszystko na do sieci
# (o ile tylko pochodzi z serwera)
iptables -A OUTPUT -s $OUTIP/32 -j ACCEPT

iptables -A FORWARD -j DROP -m unclean

# Indywidualne regulki akceptujace okreslone porty lub serwery
# Zalecana jest jak najwieksza szczegolowosc tych regulek,
# w razie problemow nalezy posilkowac sie regulkami LOG

# Uslugi swiadczone dla sieci wewnetrznej
## Serwis LTSP wymaga
TCP_LTSP=sunrpc,x11,xfs
UDP_LTSP=bootps,tftp,sunrpc,32771,nfs,xdmcp,syslog,domain
## Serwis SMB wymaga
TCP_SMB=netbios-ssn
UDP_SMB=netbios-ns,netbios-dgm
# Uslugi dostepne TYLKO dla sieci wenetrznej
TCP_INSIDE_ALLOW=$TCP_LTSP,$TCP_SMB
UDP_INSIDE_ALLOW=$UDP_LTSP,$UDP_SMB

# Odrzuc rozgłoszenia na interfejsie zewnetrznym (generują dużo logów)
iptables -A INPUT -d $OUTBCAST/32 -j DROP
iptables -A INPUT -d 255.255.255.255/32 -j DROP

# Logujemy pakiety ktore nie zostaly zaakceptowane przez

# zadna z powyzszych regulek. Zostana one wyblokowane dzieki
# polityce DROP we wszystkich tablicach
#iptables -A INPUT -j LOG -m limit --limit 10/hour --log-prefix "INPUTPOLICY"
#iptables -A OUTPUT -j LOG -m limit --limit 10/hour --log-prefix "OUTPUTPOLICY"
#iptables -A FORWARD -j LOG -m limit --limit 10/hour --log-prefix "FORWARDPOLICY"

echo .

Konfiguracja usług na serwerze

4.1

Serwer DHCP

Serwer DHCP (ang. Dynamic Host Configuration Protocol ) pozwala na automatyczną konfigurację interfejsów
sieciowych stacji w sieci lokalnej. Oczywiście warunkiem koniecznym jest uaktywnienie klienta usługi DHCP na
stacji.

4.1.1

Konfiguracja serwera

W dystrybucji Aurox serwer DHCP znajduje się w pakiecie dhcpd. Najważniejszym plikiem konfiguracyjnym
jest /etc/dhcpd.conf. Znjdują się w nim definicje zakresów z których będą przydzielane numery IP, definicje
globalnych parametrów sieci oraz definicje plików bootujących dla stacji bezdyskowych (por. Pkt. 4.4.2 ).
– /etc/dhcpd.conf –

default-lease-time

21600;

max-lease-time

21600;

ddns-update-style none;
allow booting;
allow bootp;

option subnet-mask

255.255.255.0;

option broadcast-address

192.168.1.255;

option routers

192.168.1.254;

option domain-name-servers

192.168.1.254;

option domain-name

"prv";

# wymagane przy usłudze terminali graficznych (LTSP)
option root-path

"192.168.1.254:/opt/ltsp/i386";

option option-128 code 128 = string;
option option-129 code 129 = text;

# dynamiczny przydział numerów IP dla podsieci
shared-network WORKSTATIONS {

subnet 192.168.2.0 netmask 255.255.255.0 {

range dynamic-bootp 192.168.1.100 192.168.1.253;
use-host-decl-names

on;

option log-servers

192.168.2.254;

filename

"/lts/vmlinuz.ltsp";

}

# statyczny przydział numerów IP
group {

use-host-decl-names

on;

option log-servers

192.168.1.254;

host ws001 {

hardware ethernet

00:E0:06:E8:00:84;

fixed-address

192.168.1.1;

filename

"/lts/vmlinuz-001.ltsp";

}

Jak widać numery sprzętowe kart Ethernet moga posłużyć jako identyfikatory służące do statycznego przydziału
numerów IP. W dystrybucji Aurox dodatkowe parametry do demona są odczytywane przez skrypt startowy
z pliku /etc/sysconfig/dhcpd.
– /etc/sysconfig/dhcpd –

DHCPDARGS=eth0

Dobrym zwyczajem jest ustawienie interfejsów sieciowych na których serwer DHCP będzie nasłuchiwał.

4.1.2

Konfiguracja klienta w Linuksie

Klient usługi DHCP zawiera pakiet dhclient. Jest on domyślnie instalowany w większości dystrybucji aby
umożliwić automatyczną konfigurację interfejsów sieciowych. Aby z niego skorzystać wystarczy zaznaczyć przy
konfiguracji sieci, że chcemy używać protokołu DHCP (Rys. 3).

Rys. 3: Wykorzystanie klienta DHCP w Linuksie

4.1.3

Konfiguracja klienta w Windows 98

W systemie Windows98 w karcie AdresIP konfiguracji protokołu TCP/IP zaznaczamy Automatycznie uzyskaj
adres IP .

4.2

Serwer DNS

Serwis DNS jest realizowany przez demona named. Pkaiet zawierający demona ma nazwę bind. Pliki konfigura-
cyjne serwisu znajdują się w katalogach /etc/ oraz /var/named W dystrybucji Aurox plik /etc/named.conf
jest automatycznie generowany przez skrypt redhat-config-bind. Niestety ze względu na istotę działania
skryptu „ręczne” wprowadzanie modyfikacji do tego pliku nie jest zalecane. Na szczęście domyślnie włącza on
plik /etc/named.custom który możemy modyfikować bez ryzyka poźniejszej utraty zawartości. Dla prywatnej
podsieci będzi on miał postać
– /etc/named.custom –

options {

directory "/var/named/";

listen-on { 192.168.1.0/24; } ;

Rys. 4: Wykorzystanie klienta DHCP w Windows98

};
zone

"." {

type hint;
file

"named.root";

};
zone

"1.168.192.in-addr.arpa" {

type master;
file

"reverse.prv.zone";

};
zone

"prv" {

type master;
file

"prv.zone";

};

Z przedstawionej zawartości pliku wynika, że serwer named będzie pełnił rolę głównego serwera DNS dla
podsieci 192.168.1.0/24 oraz serwera „cache” dla zapytań spoza sieci. W przypadku zapytań o nazwy któ-
rych nie zna odwoła się do serwrów zdefiniowanych w pliku /var/named/named.root. Plik ten można pobrać
z ftp://ftp.internic.net/domain/named.root. Definicje nazw stacji w zarządzanej przez serwer podsieci znajdu-
ją się w plikach /var/named/prv.zone oraz /var/named/reverse.prv.zone. Pliki te uzyskamy uruchamiając
następujący skrypt powłoki
– /var/named/genzone.sh –

#!/bin/sh
ZONENAME="prv"
SERVER="gate"
SUBNET="192.168.1"
SERVERIP=254
STPREFIX="ws"

ZONE=$ZONENAME.zone

REVZONE=reverse.$ZONE

echo "\$TTL 86400" > $ZONE
echo "@ IN SOA $SUBNET.$SERVERIP.

root.$SERVER.$ZONENAME (" >> $ZONE

echo " 1 ; serial" >> $ZONE
echo " 28800 ; refresh" >> $ZONE
echo " 7200 ; retry" >> $ZONE
echo " 604800 ; expire" >> $ZONE
echo " 86400 ; ttl" >> $ZONE
echo " )" >> $ZONE
echo " IN NS $SUBNET.$SERVERIP." >> $ZONE

counter=254
while [ $counter -ne 0 ]
do

if [ $counter -eq $SERVERIP ]
then

echo "$SERVER IN A $SUBNET.$SERVERIP" >> $ZONE
echo "dns IN A $SUBNET.$SERVERIP" >> $ZONE

else

echo "$STPREFIX$counter IN A $SUBNET.$counter" >> $ZONE

fi
counter=$(( $counter - 1 ))

done

echo "\$TTL 86400" > $REVZONE
echo "@ IN SOA $SUBNET.$SERVERIP. root.$SERVER.$ZONENAME (" >> $REVZONE
echo " 1 ; serial" >> $REVZONE
echo " 28800 ; refresh" >> $REVZONE
echo " 7200 ; retry" >> $REVZONE
echo " 604800 ; expire" >> $REVZONE
echo " 86400 ; ttk" >> $REVZONE
echo " )" >> $REVZONE
echo "@ IN NS $SUBNET.$SERVERIP.">> $REVZONE

counter=254
while [ $counter -ne 0 ]
do

if [ $counter -eq $SERVERIP ]
then

echo "$SERVERIP IN PTR $SERVER.$ZONENAME" >> $REVZONE

else

echo "$counter IN PTR $STPREFIX$counter.$ZONENAME." >> $REVZONE

fi
counter=$(( $counter - 1 ))

done

Należy pamiętać o inkrementacji pola serial (trzecia linia w każdym z plików) po każdorazowej modyfikacji
plików stref.

4.3

Serwer plików i drukowania

Współdzielenie plików i drukarek poprzez sieć jest możliwe począwszy od Windows For Workgroups 3.11. Od
tego czasu sieci Microsoft znacznie się zmieniły, jednak ogólna zasada pozostaje ta sama. W sieciach Microsoft
każda stacja może pełnić jednocześnie rolę klienta jak i serwera. Każda stacja jest identyfikowana poprzez nazwę
oraz grupę roboczą: obie te wartości są nadawane podczas konfiguracji klienta. W danej chwili stacja może nale-
żeć tylko do jednej grupy roboczej. Z logicznego punktu widzenia sieci Microsoft zapewniają dwie usługi WINS
(ang. Windows Internet Name Service) oraz SMB (ang. Session Message Block ). Pierwsza z nich zapewnia
translację nazw stacji na adresy sieciowe natomiast druga jest odpowiedzialna za komunikację pomiędzy stacja-
mi. Sieci Microsoft pracują w wartswie sesji siedmiowarstwowego modelu OSI/ISO. Jako protokół transportwoy

domyślnie wykorzystywany jest NetBIOS, jednak możliwa jest konfiguracja stacji tak, aby wykorzystywany był
protokół TCP/IP. Stacja pod kontrolą Linuksa może jednocześnie pełnić rolę serwera i klienta sieci Microsoft.
Co więcej może być również serwerem WINS oraz kontrolelrem domeny, co pozwala na eliminację z sieci drogich
serwerów WindowsNT.

4.3.1

Konfiguracja serwera

Obsługa sieci Microsoft wymaga zainstalowania pakietu samba i uruchomienia serwerów nmbd oraz smbd. Pierw-
szy, zależnie od konfiguracji stacji, jest klientem lub serwerem WINS, natomiast drugi jest serwerem plików
i drukarek. W dystrybucji Aurox oba demony uruchamiane są w ramach tej samej usługi o nazwie smb. Serwer
samba posiada tylko jeden plik konfiguracyjny /etc/samba/samba.conf. Składnia pliku jest podobna do jak
w plikach konfiguracyjnych Windows 3.x. Plik podzielony jest na sekcje, przy czym nazwa sekcji ujeta jest
w nawiasy kwadratowe. Obowiązkowe sekcje w pliku do global, homes, printers odpowiednio odpowiedzialne
za ogólną konfigurację serwera oraz sposób udostępnienia katalogów domowych użytkowników oraz drukarek.
Udostępnienie dodatkowych zasobów wymaga definicji nowych sekcji, przy czym nazwa sekcji jest nazwą zasobu
(ang. share). W ramach każdej sekcji nadajemy wartości opcjom kontrolującym działanie serwera. Każdy wpis
ma postać

opcja = wartość

W nazwach opcji i w nadawanych wartopściach mogą pojawić się znaki odstępu. Pomijane są jedynie odstępy
poprzedzające i następujące za znakiem ”=”. Przystępne omówienie sieci Microsoft oraz konfiguracji klientów
i serwerów można znaleźć w książce „Using Samba” udostępnianej w formie elektronicznej przez wydawnictwo
O’Reilly pod adresem http://www.oreilly.com/. Przykładowy plik konfiguracyjny zamieszczono poniżej.
– /etc/samba/smb.conf –

# Samba config file created using SWAT
# from 127.0.0.1 (127.0.0.1)
# Date: 2004/01/20 11:21:47
[global]
workgroup = LAB
netbios aliases = SAMBA
server string = Samba Server
interfaces = eth0, 192.168.1.254/24
security = USER
encrypt passwords = Yes
passwd chat debug = Yes
log file = /var/log/samba/%m.log
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = cups
os level = 65
preferred master = Yes
domain master = Yes
wins support = Yes
remote announce = 192.168.1.255
hosts allow = 192.168.2.
printing = cups
[homes]
comment = Home Directory on %L (%U)
browsable = no
#valid users = %S
read only = No
create mask = 0664
directory mask = 0775

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No
[common]
comment = Katalog wspolny

path = /home/samba
read only = No
guest ok = No
browseable = Yes

W sekcji global znajduje się definicja nazwy stacji (netbios aliases), grupy roboczej (workgroup), interfejsów z
których serwer będzie przyjmował żądania (interfaces) oraz stacji które będą obsługiwane (hosts allow). Podane
wartości parametrów (os level), (preferred master), (domain master) i (wins support) zapewniają, że serwer
linuksowy zostanie serwerem głównym dla wybranej grupy roboczej oraz będzie pełnił rolę serwera nazw. Sekcje
homes i printers definiują sposób dostępu do katalogów domowych użytkowników oraz drukarek. W przykłado-
wym pliku katalogi domowe udostępniane są wszystkie drukarki. Sekcja homes ma specjalne znaczenie. Jeżeli
logowanie się powiedzie wówczas nazwa homes jest zamieniana na nazwę katalogu domowego użytkownika. Za-
negowanie flagi (browsable) zapewni, że sekcja homes nie pojawi się w oknie przeglądania sieci i nie będzie
możliwe stwierdzenie które katalogi domowe uzytkowników są udostępnione. Ostatnia sekcja common definiuje
zasób który może być wykorzystany przez wielu użytkowników. Opcje (guest ok) kontroluje dostęp do zasobu
przez osoby które nie mają konta na serwerze natomiast (read only) oraz (browsable) czy jest mozliwy zapis
i przeglądanie zawartości.

Specjalnego omówienia wymaga kontrola dostępu do zasobów serwera. Począwszy od wersji Windows95 hasło

chroniące dostęp do zasobu przesyłane jest przez sieć w postaci zaszyfrowanej (encrypt passwords). Oznacza
to, że serwer SMB nie otrzymuje hasła w jawnej postaci i jedynym sposobem na weryfikację jego poprawności
jest porównanie postaci zaszyfrowanych. Zaszyfrowne hasła są przechowywane w pliku /etc/samba/smbpasswd.
Ponieważ bazy haseł dla systemu Linux i serwisu SMB są różne, same hasła również mogą być różne. Dopisanie
użytkownika do bazy haseł SMB uzyskujemy komendą

smbpasswd -a <nazwa_użytkownika>

Każdy użytkownik może zmienić swoje hasło również korzystając z smbpasswd.

4.3.2

Klient SMB w Linuksie

W Linuksie mamy dostęp do kilku klientów SMB. Program smbclient z interfejsem a’la FTP zapewnia dostęp
do zasobów plikowych. Opcje takie nazwa użytkownika, grupę roboczą i nazwę zasobu podajemy jako parametry
wywołania programu. Zasoby aktualnie dostępne można wylistować komendą

smbclient -L

Do drukarek dostęp uzyskujemy dzięki smbprint. Program ten jest używany przez demona drukowania CUPS
(ang. Common Unix Printing System) do wydruków na drukarkach sieciowych udostępnionych jako SMB
(http://localhost:631). Zasoby plikowe sieci SMB można również montować dzięki programom smbmount i smbumount.
Przykładowa komenda montowania katalogu domowego użytkownika jozef ma postać

mount -t smb -o workgroup=LAB,username=JOZEF //samba/jozef /mnt/jozef

4.3.3

Klient SMB w Windows 98

W menu Ustawienia →Sieć wybieramy zakładkę Idnetyfikacja i wpisujemy nazwę stacji oraz grupy roboczej Rys.
5. W zakładce konfiguracja pzostawiamy tylko klienta sieci Microsoft, sterownik karty Ethernet oraz protokół
TCP/IP (Rys. 6). Brakujące elementy doinstalowujemy (Dodaj ...) lub usuwamy (Usuń). Następnie w zakładce
Adres IP konfigurujemy automatyczną konfigurację adresu IP (Rys. 7) przy użyciu serwisu DHCP (por. Pkt.
4.1.1 ). Jeżeli pozostawimy pusty adres bramy (Rys. 8) to jako domyślna brama będzie używany host na którym
pracuje serwer DHCP. Szczegółowy opis konfiguracji bramy zamieszczono w Pkt. 3.3. Adresy serwerów DNS
również możemy pozostawić puste (Rys. 9), jeżeli na stacji stanowiącej bramę mamy uruchomiony odpowiedni
serwis por. Pkt. 4.2 . W przeciwnym razie należy uaktywnić korzystanie z serwisu DNS i na liście serwerów
(Dodaj) umieścić adresy IP odpowiednich hostów z sieci zewnętrznej.

Należy jeszcze zwrócić uwagę na powiązanie klienta sieci Microsoft z protokołem TCP/IP (Rys. 10). Dla

usługi WINS również możemy wybrać automatyczną konfigurację (Rys. 11). Jeżeli serwer SMB pracuje na innej
stacji niż serwer DHCP wółczas należy uaktywnić rozpoznawanie WINS.

Rys. 5: Identyfikacja stacji

Rys. 6: Konfiguracja sieci

Rys. 7: Konfiguracja adresu interfejsu sieciowego

Rys. 8: Konfiguracja bramy

Rys. 9: Konfiguracja klienta DNS

Rys. 10: Konfiguracja powiazania protokołu TCP/IP z klientem sieci Microsoft

Rys. 11: Konfiguracja klienta WINS

4.4

Serwis graficznych terminali

Host pod kontrolą Linuksa może pracować jako serwer bezdyskowych stacji graficznych (X Terminali). Odpo-
wiednie oprogramowanie zebrano w ramach projektu LTSP (ang. Linux Terminal Server Project ). Serwer LTSP
pozwala na boot stacji poprzez sieć, wykorzystanie oprogramowania zebranego na serwerze oraz uruchomienie
na stacjach graficznego środowiska pracy.

Start stacji bezdyskowej składa się z następujących etapów:

• incjalizacja parametrów sieciowych karty,

• pobranie jądra z sieci umieszczenie jądra w pamięci RAM,

• uruchomienie jądra,

• jądro montuje system plików / poprzez sieć,

• jądro przekazuje sterowanie procesowi init, co oznacza, że w zamontowanym katalogu / muszą znaleźć

się wszystkie biblioteki i pliki niezbędne do jego uruchomienia,

• proces init realizuje start systemu wg zawartości pliku /etc/inittab, a szczególności inicjuje RAM dysk

i pliki konfiguracyjne specyficzne dla stacji,

• uruchomienie na stacji X Serwera,

• uruchomienie klienta XDM realizującego graficzny login do serwera.

4.4.1

Konfiguracja karty sieciowej

Konfiguracja karty sieciowej jest stosunkowo prosta. W ramach projektu Etherboot opracowa zestaw obrazów
pamięci EPROM dla szerokiego zestawu kart sieciowych. Program zamieszczony w pamięci EPROM automa-
tycznie konfiguruje interfejs karty przy użyciu serwera DHCP a następnie pobiera jądro systemu przy użyciu
protokołu TFP! (ang. TFP! ) z lokalizacji wskazanej przez serwer DHCP. Jeżeli karta ma podstawkę dla
pamięci EPROM to można ją uzupełnić o oprogramowanie automatycznie konfigurujące kartę. Gdy nie może-
my lub nie chcemy samodzielnie programować pamięci EPROM możemy skorzystać ze specjalnych dyskietek
startowych zawartych w katalogu /tftpboot/lts/boot/bootroms. Są to obrazy pamięci EPROM uzupełnione
o odpowiedni program ładujący przeznaczony do umieszczenia w bootsektorze dyskietki. Dyskietkę startwową
tworzymy z obrazu komendą

dd if=/tftpboot/lts/boot/bootroms/rtl8139.lzdsk of=/dev/fd0

gdzie rtl8139.lzdsk należy zastapić obrazem stosownym do posiadanej karty sieciowej. Obrazy pamięci EPROM
można również pobrać z adresu Hello

4.4.2

Serwer TFTP

Serwis TFTP (ang. Trivial File Transfer Protocol ) służy do publicznego udostępniania plików. Każdy kto zna
adres serwera może z niego pobrać wszystkie udostępniane pliki.

Serwer TFP w dystrybucji Aurox znajduje się w pakiecie tftpd. Jedynym plikiem konfiguracyjnym demona

jest plik startowy /etc/xinetd.d/tftp.
– /etc/xinetd.d/tftp –

service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}

Specyfikujemy w nim m.in.: katalog domowy serwisu (/tftpboot), protokół, liczbę połączeń oraz nazwę użyt-
kownika na którego prawach będzie pracował serwer TFTP. Należy pamiętać o aktywacji usługi przez ustawienia
flagi disable = no. Kazdorazowa zmiana wartości flagi disable wymaga restartu supedemona xinetd

service xinetd restart

4.4.3

Serwer NFS

Za obsługę seriwsu NFS (ang. Network File System) odpowiada kilka demonów. Po pierwsze NFS oparty jest
na standardzie RPC (ang. Remote Procedure Call ) przez co wymagane jest uruchomienie demona mapowa-
nia portów portmap zawartego w pakiecie o tej samej nazwie. Programy pracujące zgodnie z RPC zgłaszają
zapytania do portmap o port na którym znajduje się serwis danej usługi. Serwis NFS jest zapewniany przez
dwa demony: rpc.mountd i rpc.nfsd. Pierwszy odpowiedzialny jest za obsługę montowania i odmontowania,
drugi za operacje na plikach. Wykaz zamontowanych systemów plików znajduje się /etc/rmtab. Oba demony
określają na podstawie pliku /etc/exports czy klient ma autoryzację dostępu do żądanego katalogu. Ogólnie w
pliku tym znajduje się tabela katalogów które mogą być zamontowane poprzez sieć. Z każdym eksportowanym
katalogiem związana jest lista komputerów oraz praw z jakimi dane katalogi mogą być montowane. W nazwach
komputerów można używać tzw. wildcards aby jednym wpisem objąć szerszą listę hostów. Przykładowy plik
konfiguarcyjny usługi NFS dla serwera LTSP zamieszczono poniżej.
– /etc/exports –

/opt/ltsp/i386

192.168.1.0/255.255.255.0(ro,no_root_squash)

/var/opt/ltsp/swapfiles

192.168.1.0/255.255.255.0(rw,no_root_squash)

#/home

192.168.1.0/255.255.255.0(rw,no_root_squash)

4.4.4

Serwer czczionek

X Serwer uruchomiony na stacji może korzystać z serwisu czczionek (tj. pobierać definicje czczionek od odpo-
wiedniego serwera). Za serwis czczionek odpowidzialny jest demon xfs. W dystrybucji X Windows są domyślnie
skonfigurowane do korzysatnia z lokalnego serwera czczionek. Aby udostępnić te czczionki również dla stacji z sie-
ci lokalnej należy w pliku konfiguracyjnym serwera /etc/X11/fs/config zakomentować linię blokującą nasłuch
serwera na porcie 7100.
– /etc/X11/fs/config –

# allow a max of 10 clients to connect to this font server
client-limit = 10
# when a font server reaches its limit, start up a new one
clone-self = on
# where to look for fonts
catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,

/usr/X11R6/lib/X11/fonts/75dpi:unscaled,
/usr/X11R6/lib/X11/fonts/100dpi:unscaled,
/usr/X11R6/lib/X11/fonts/misc,
/usr/X11R6/lib/X11/fonts/Type1,
/usr/X11R6/lib/X11/fonts/Speedo,
/usr/X11R6/lib/X11/fonts/cyrillic,
/usr/X11R6/lib/X11/fonts/TTF,
/usr/share/fonts/default/Type1,
/usr/share/fonts/ISO8859-2/misc:unscaled,
/usr/share/fonts/ISO8859-2/misc
# in 12 points, decipoints
default-point-size = 120
# 100 x 100 and 75 x 75
default-resolutions = 75,75,100,100
# use lazy loading on 16 bit (usually Asian) fonts
deferglyphs = 16
# how to log errors
use-syslog = on
# don’t listen to TCP ports by default for security reasons
# no-listen = tcp

4.4.5

Logi systemowe stacji

Logi systemowe stacji mogą być zapisywane w dzienniku na serwerze LTSP. W tym celu należy skonfigurować
demona syslogd tak aby nasłuchiwał na porcie 53 podając jako jedną z opcji startowych -r . W dystrybucji
Aurox opcje dla syslogd są odczytywane z pliku /etc/sysconfig/syslog.
– /etc/sysconfig/syslog –

# Options to syslogd
# -m 0 disables ’MARK’ messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-m 0 -r -x"
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
#

once for processing with ’ksymoops’

# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-2"

4.4.6

Serwer XDMCP

Po utworzeniu plików startowych na stacji uruchamiany jest X Serwer z opcją -query. Opcja ta powoduje, że
X Serwer przy użyciu protokołu XDMCP (ang. XDM Control Protocol ) usiłuje uruchomić na serwerze LTSP
tzw. menedżer wyświetlacza (ang. display menager ). Program ten umożliwia zalogowanie się na serwer LTSP
w trybie graficznym. Program menedżera wyświetlacza z logicznego punktu widzenia jest klientem X Serwera
uruchomionego na stacji, bowiem zleca mu wyświetlenie okienka umożliwiającego wprowadzenie nazwy użyt-
kownika i hasła. Oczywiście podajemy nazwę użytkownika istniejącego na serwerze LTSP.

W Linuksie funkcjonują obecnie trzy programy pełniące rolę menedżera wyświetlacza:

XDM (ang. X

Windows Display Manager ), GDM (ang. Gnome Display Manager ), KDM (ang. KDE Display Manager ).
W dystrybucji Aurox decyzja o tym, który z menedżerów będzie używany jest podejmowana wewnątrz skryptu
/etc/X11/prefdm. Skrypt ten poszukuje w pliku /etc/sysconfig/desktop zmiennej DISPLAYMANAGER
– /etc/sysconfig/desktop –

DESKTOP="KDE"
DISPLAYMANAGER="KDE"

Jeżeli nie ma odpowiedniego wpisu decyzja o uruchomieniu konkretnego menedżera podejmowana jest w zależ-
ności od tego który z nich został zainstalowany.

XDM

Program XDM jest menedżerem wyświetlacza opracowanym w ramach projektu XFree86. Pliki kon-

figuracyjne w dystrybucji Aurox znajdują się w katalogu /etc/X11/xdm. Najważniejsze z nich to Xaccess
i xdm-config. Pierwszy z nich kontroluje dostęp do usługi XDM. Zazwyczaj w pliku tym nie wprowadzamy
żadnych ograniczeń pozostawiając to zadanie ścianie ogniowej.
– /etc/X11/xdm/Xaccess –

* #any host can get a login window
* CHOOSER BROADCAST #any indirect host can get a chooser

Plik xdm-config definiuje położenie szeregu plików konfiguracyjnych. Plik ten określa również czy XDM po-
winien nasłuchiwać na porcie XDMCP (port 177). W tym celu należy zakomentować (poprzedzić znakiem
wykrzyknika) obecną domyślnie opcję DisplayManager.requestPort .
– /etc/X11/xdm/xdm-config –

DisplayManager.errorLogFile: /var/log/xdm-errors
DisplayManager.pidFile: /var/run/xdm-pid
DisplayManager.keyFile: /etc/X11/xdm/xdm-keys
DisplayManager.servers: /etc/X11/xdm/Xservers
DisplayManager.accessFile: /etc/X11/xdm/Xaccess
DisplayManager.willing: su nobody -c /etc/X11/xdm/Xwilling
! All displays should use authorization, but we cannot be sure
! X terminals will be configured that way, so by default
! use authorization only for local displays :0, :1, etc.
DisplayManager._0.authorize: true
DisplayManager._1.authorize: true
! The following three resources set up display :0 as the console.
DisplayManager._0.setup: /etc/X11/xdm/Xsetup_0
DisplayManager._0.startup: /etc/X11/xdm/GiveConsole
DisplayManager._0.reset: /etc/X11/xdm/TakeConsole

DisplayManager*resources: /etc/X11/xdm/Xresources
DisplayManager*session: /etc/X11/xdm/Xsession
DisplayManager*authComplain: false

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
! DisplayManager.requestPort: 0

KDM

Program kdm jest menedżerem wyświetlacza opracowanym w ramach projektu KDE (ang. K Desktop

Environment ). W dystrybucji Aurox plikiem konfiguracyjnym kdm jest /usr/share/config/kdm/kdmrc.
– /usr/share/config/kdm/kdmrc –

[General]
DaemonMode=false
PidFile=/var/run/kdm.pid
Xservers=/usr/share/config/kdm/Xservers

[X-*-Core]
AllowNullPasswd=true
AllowRootLogin=true
AllowShutdown=Root
AutoReLogin=false
Reset=/usr/share/config/kdm/Xreset
Resources=/etc/X11/Xresources
Session=/usr/share/config/kdm/Xsession
Setup=/usr/share/config/kdm/Xsetup
Startup=/usr/share/config/kdm/Xstartup

[Xdmcp]
Enable=true
Port=177
Willing=/usr/share/config/kdm/Xwilling
Xaccess=/usr/share/config/kdm/Xaccess

Najważniejsze sekcje pliku to General , X-*-Core, Xdmcp. Podobnie jak w konfiguracji XDM definiują one poło-
żenie plików konfiguracyjnych oraz czy kdm powinien nasłuchiwać zdalnych odwołań na porcie XDMCP. Należy
podkreślić, że zaprezentowany powyżej wydruk pliku jest jedynie wyciągiem z pełnego pliku konfiguracyjnego.

GDM

Menedżer GDM został opracowany w ramach projektu Gnome. Pliku konfiguracyjnym gdm w dys-

trybucji Aurox jest /etc/X11/gdm/gdm.conf. Podobnie jak plik konfiguracyjny dla kdm jest on podzielony na
sekcje. Prawidłowe działanie gdm dla zdalnych stacji wymaga odblokowania nasłuch na porcie XDMCP w sekcji
xdmcp.

4.4.7

Konfiguracja LTSP

Pakiety zawierające serwis LTSP instalują:

• w katalogu /tftpboot jądro systemu oraz obrazy pamięci EPROM dla różnych typów kart sieciowych,

• w katalogu /opt/ltsp/i386 system plików który jest montowany przez stacje jako katalog główny.

Jądro systemu które zostanie załadowane (zazwyczaj /tftpboot/vmlinuz.ltsp) jest okreslone w konfiguracji
serwera DHCP (por. Pkt. 4.1.1 ). Katalog /opt/ltsp/i386 musi być weksportowany przez serwis NFS (por.
Pkt. 4.4.3 ). Plikiem konfiguracyjnym odpowiedzialnym za odpowiednie przygotowanie plików startowych dla
poszczególnych stacji jest /opt/ltsp/i386/etc/lts.conf. Jego zawartość jest interpretowana przez skrypt
/opt/ltsp/i386/etc/rc uruchamiany bezpośrednio przez działający na stacji proces init. W pliku lts.conf
określamy domyślną konfigurację stacji. Dla stacji nietypowych możemy określić inne parametry startowe, w tym

• typ X serwera właściwy dla karty graficznej stacji,

• typ klawiatury i myszy,

• parametry monitora,

• rodzaj karty dźwiękowej.

Jeżeli chcemy dla stacji ukatywnić pliki wymiany (ang. swapfile) należy poprzez serwer NFS wyeksportować
katalog /var/opt/ltsp/swapfiles i utworzyć w nim plik o pożądanym rozmiarze i nazwie złożonej z numeru
stacji i rozszerzenia swap

dd if=/dev/zero of=/var/opt/swapfiles/192.168.1.100.swap bs=1M count=64

W przykładzie powyżej utworzono plik wymiany o rozmiarze 64 MB. W domślnej konfiguracji serwera LTSP
całe przetwarzanie danych odbywa się na serwerze. Oprogramowanie stacji służy jedynie jako swego rodzaju
wyświetlacz sieciowy. Aktywacja opcji LOCAL APS zmieni tą sytuację. Wszystkie aplikacje będą wykonywane
na stacjach, a funkcje serwera zostaną ograniczone do obsługi ruchu NFS. Należy jednak pamietać, że w takiej
konfiguracji przygotowanie odpowiedniego środowiska pracy aplikacjom wymaga wyeksportowania z prawami
do odczytu i zapisu katalogów domowych użytkowników. Jest to stosunkowo niebezpieczna operacja ze względu
na stosunkowo słabe zabezpieczenia serwera NFS.

4.5

Dostęp zdalny przez SSH

Jedną z usług oferowanych uzytkownikom może być zdalny dostęp w trybie tekstowym. Tradycyjne usługi takie
jak telnet i rlogin są jednak poważnym zagrożeniem dla systemu: w pierwszej jawnym tekstem przesyłane są
hasła użytkowników, w drugiej napastnik wykorzystując technikę podszywania się pod cudze adresy IP (ang. IP
Spoofing) może uzyskać nieuprawniony dostęp do kont użytkowników. Radą na obie bolaczki jest zastosowanie
narzędzia realizującego protokół SSH (ang. Secure Shell ). W SSH komunikacja pomiędzy klientem i serwerem
jest szyfrowana a hosty w sieci identyfikowane przy użyciu techniki podpisów cyfrowych.

Istnieje wiele narzędzi realizujących serwer oraz klienta SSH dostepnych na wiele platform sprzętowych i sys-

temów operacyjnych. Niektóre z nich są dostępne nieodpłatnie i korzystają wyłącznie z algorytmów szyfrujących
nieobciążonych ograniczeniami patentowymi. Z kolei producenci komercyjnych implementacji SSH mogą pozwo-
lić sobie na wykup licencji i stosowanie algorytmów odpłatnych. Również sam protokół SSH podlegał ewolucji
i obecnie

najbardziej aktualna wersja protokołu nosi numer 2.0

. Wszystkie poprzednie wersje posiadały pewne

niedostatki i ich stosowanie nie jest zalecane. Jednak ograniczenie się tylko wersji 2 protokołu oznacza rezygnację
z dostępu przy użyciu starszych wersji oprogramowania.

W dystrybucji Aurox instalacja serwera SSH wymaga pakietów openssh i openssh-serwer. Przy insta-

lacji serwera generowane są klucze: publiczne /etc/ssh/ssh host key.pub, /etc/ssh/ssh host rsa key.pub,
/etc/ssh/ssh host dsa key.pub ; prywatne /etc/ssh/ssh host key, /etc/ssh/ssh host rsa key, /etc/ssh/ssh host dsa key
oraz plik pomocniczy /etc/ssh/moduli. Klucze te wykorzystywane są w zalezności od konfiguracji serwera
i klienta SSH. Ważne jest aby klucze te należy przegrać na bezpieczny nośnik aby zachować ich niezmie-
nioną wartość przy aktualizacji lub ponownej instalacji systemu. Konfiguracja systemu zawarta jest w pliku
/etc/ssh/sshd config. Ważne jest również aby pliki prawo od odczytu plików zawierających klucze prywatne
oraz konfigurację serwera posiadał tylko administrator systemu.

-rw-------

1 root

root

88039 wrz 17 18:13 moduli

-rw-------

1 root

root

2474 wrz 17 18:13 sshd_config

-rw-------

1 root

root

668 gru 20 06:51 ssh_host_dsa_key

-rw-r--r--

1 root

root

590 gru 20 06:51 ssh_host_dsa_key.pub

-rw-------

1 root

root

515 gru 20 06:51 ssh_host_key

-rw-r--r--

1 root

root

319 gru 20 06:51 ssh_host_key.pub

-rw-------

1 root

root

883 gru 20 06:51 ssh_host_rsa_key

-rw-r--r--

1 root

root

210 gru 20 06:51 ssh_host_rsa_key.pub

W przykładowym pliku konfiguracyjnym serwera openssh domyślne wartości poszczególnych opcji zmiesz-

czono w komentarzu. Opcje pozbawione komentarza oznaczają odstępstwo od wartości domyślnych. Należy
jednak pamiętać, że domyślne wartości zmieniają się z wersją oprogramowania.
– /etc/ssh/sshd-config –

#Port 22
#Protocol 2,1
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:
#LoginGraceTime 120
#PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

03.02.2004

Numeru wersji protokołu nie należy mylić z wersją konkretnej implementacji serwera i/lub klienta.

# rhosts authentication should not be used
#RhostsAuthentication no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to ’yes’ to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of ’PasswordAuthentication’
#PAMAuthenticationViaKbdInt no

#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
PrintMotd no
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no

# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server

W powyższym pliku dokonano następujących odstępstw od domyslnej konfiguracji:

• ograniczono dostęp tylko dla programów klienckich wspierających najnowszą wersję protokołu,

• włączono szyfrowanie sesji X11, poprzez ich tunelowanie w łączu SSH,

• wyłączono drukowanie wiadomości dnia.

4.6

Serwer HTTP

4.7

Serwer pocztowy Postfix

W dystrybucji Aurox domyślnym serwerem pocztowym jest sendmail. Mimo wielu zalet sendmail ma jedna
bardzą poważną wadę: bardzo często wykrywane są w nim błędy pozwaljące na uzyskanie praw administratora
systemu poprzez wysłanie odpowiednio spreparowanych danych. Dalej omówimy podstawową konfigurację serwe-
ra SMTP! (ang. SMTP! ) o nazwie postfix. Przed instalacją pakietu należy sprawdzić czy w /etc/passwd
mamy wpisanego użytkownika postfix oraz w /etc/gropu grupę postdrop. Jeżeli nie, to przed rozwinięciem
pakietu należy ich utworzyć

useradd -d /var/spool/postfix -s /etc/nologin postfix
groupadd postdrop

Po instalacji pakietu wybieramy nowo zainstalowany serwera jako domyślny komendą

redhat-switch-mail

Konfiguracja serwera jest zawarta w dwóch plikach: /etc/postfix/main.cf oraz /etc/postfix/master.cf.
W celu ułatwienia konfiguracji domyślne wartości wszystkich opcji zamieszczono w pliku /etc/postfix/main.cf.default.

Serwer pocztowy postfix jest domyślnie skonfigurowany tylko na doręczanie poczty lokalnej, tj. pochodzącej

tylko od użytkowników hosta. Zezwolenie na wysyłanie i odbieranie poczty z zewnątrz uzyskujemy modyfikując
plik /etc/postfix/main.cf. Poszukujemy w pliku linii

inet_interfaces = localhost

i zastępujemy ją wpisem

inet_interfaces = all

Następnie restartujemy demona

service postfix restart

4.7.1

Ochrona przed spamem

Do ochrony przed spamem służy oprogramowanie o nazwie spamassassin. Po zainstalowaniu musimy zmusić
postfix’a do filtrowania każdej otrzymanej wiadomości analizatorem zapewnianym przezspamassassin. W tym
celu w pliku /etc/postfix/master.cf poszukujemy linii

smtp

inet

smtpd

i zamieniamy ją na

smtp

inet

smtpd

-o content_filter=postfixfilter:

Cała otrzymana poczta będzie przekazywana do użytkownika postfixfilter . Następnie zakładamy użytkownika
postfixfilter blokując mu możliwość logowania do systemu

useradd -s /sbin/nologin postfixfilter

W katalogu domowym użytkownika postfixfilter umieszczamy plik wykonywalny postfixfilter o następującej
treści

!/bin/bash
#redirect mail to spam filtering daemon and resent to adresse
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?

4.7.2

Ograniczenie dostępu do serwera

Domyślnie serwer postfix ma wyłączone przekazywanie (ang. relay) wiadomości. Aby to stwierdzić wystarczy
sprawdzić wartości zmiennych mydestination i relay domains w pliku main.cf.default. Włączenie autoryzacji
przy użyciu

SASL (ang. Simple Authentication and Security Layer ) oraz szyfrowania transmisji pomiędzy

klientem SMTP i serwerem pozwoli na używanie naszego hosta tylko wybranym osobom i dość skutecznie
utrudni życie spamerom pragącym wykorzystać nasz serwer do rozsyłania poczty. Rozprowadzany w dystrybucji
Aurox postfix ma juz wkompilowaną obsługę SASL i TLS (ang. Transport Layer Security).

SASL

Do wprowadzenia autentykacji musimy mieć zainstalowane pakiety cyrus-sasl, cyrus-sasl-plain,

cyrus-sasl-md5. Domyślnie metodą autoryzacji jest porównanie danych podanych przez program klienta z pli-
kiem sasldb. Zarządzanie użytkownikami oraz ich hasłami realizujemy komendą saslpasswd. Hasło dla już
istniejącego użytkownika ustawiamy

saslpasswd -u nazwa.mojego.kompa login

Jeżeli chcemy utworzyć dodatkowy wpis lub usunąć już istniejący dodatkowo podajemy opcję -c lub -d , odpo-
wiednio.

Użytkownik pragnący skorzystać z serwera do wysyłki poczty musi skonfigurować program pocztowy aby

korzystał z procedury uwierzytelnienia w podczas której przesyła do serwera login oraz ustalone komenda
saslpasswd hasło. Zależnie od konfiguracji serwera i klienta hasło może być przesyłane w postaci jawnej (metody
PLAIN i LOGIN) lub utajnionej (CRAM-MD5, DIGEST-MD5).

Program zarządzający hasłami saslpasswd poszukuje sasldb pliku w katalogu /etc/. Jednak aby postfix

mógł w takcie wykonania uzyskać do niego dostęp to plik ten musi znajdować się w katalogu /var/spool/postfix/etc/.
Aby spełnić oba wymagania plik z hasłami kopiujemy do katalogu postfix’a a katalogu /etc/ tworzymy od-
powiedni link symboliczny. Należy jeszcze pamiętać o zmianie uprawnień dostępu do sasldb, tak aby postfix
pracujący na prawach użytkownika i grupy postfix mógł uzyskać do niego dostęp.

mv /etc/sasldb /var/spool/postfix/etc/
ln -s /var/spool/postfix/etc/sasldb /etc/sasldb
chgrp postfix /var/spool/postfix/etc/sasldb
chmod g+r /var/spool/postfix/etc/sasldb

W takiej konfiguracji oba programy będą „zadowolone”.

Teraz musimy jeszcze poinformować serwer, że powinien korzystać z nowej funkcji. W pliku /etc/main.cf

dopisujemy

# SASL
smtpd_sasl_auth_enable = yes
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_sasl_authenticated check_relay_domains
broken_sasl_auth_clients = yes
# smtpd_sasl_security_options = noanonymous noplaintext noactive nodictionary
smtpd_sasl_security_options = noanonymous

i restartujemy serwer. Dopisanie opcji noplaintext do smtpd sasl security options zablokuje możliwość uzyskania
autoryzacji poprzez przesłanie hasła jawnym tekstem.

TLS

Protokół TLS słuzy do utajnienia danych przesyłanych w warstwie transportowej sieci, tj. przy użyciu

protokołu TCP/IP. W TLS, podobnie jak SSH wykorzystano mechanizm kluczy publicznych do identyfikowania
hostów. Jednak w przeciwieństwie do SSH mechanizm kluczy publicznych uzupełniono o możliwość potwierdza-
nia ich autentyczności przy użyciu tzw. certyfikatów. Certyfikat to nic innego jak podpis cyfrowy złożony przez
zaufaną instytucję pod danymi hosta i jego kluczem publicznym. Niestety certyfikaty kosztują, dlatego dalej zo-
stanie omówione jak można wystawić certyfikat sobie samemu. Oczywiście certyfikat taki nie daje dodatkowego
zabezpieczenia i uzyskamy poziom ochrony podobny jak w SSH.

Do obsługi certyfikatów i kluczy publicznych musimy mieć zainstalowany pakiet openssl. Proces wysta-

wiania certyfikatu rozpoczniemy od wygenerowania klucza prywatnego i publicznego instytucji certyfikującej.
Zakładamy katalog /etc/postfix/cert/ i wykonujemy w nim komendę

/usr/share/ssl/misc/CA -newca

Potwierdzamy utworzenie nowej struktury katalogów i w odpowiedzi na pytania podajemy dane instytucji
certyfikującej. Następnie wykonujemy poniższy skrypt (również w katalogu /etc/postfix/cert/)
– /etc/postfix/cert/make-postfix-cert.sh –

#! /bin/sh
# make-postfix-cert.sh
# by Craig Sanders <cas@taz.net.au>

2000-09-02

# this script is hereby placed in the public domain.
# modified by Piotr Zawadzki <pzawad@ps.edu.pl> 2004-02-05

site="minibo.iele.polsl.gliwice.pl"

# edit these values to suit your site.

COUNTRY="PL"

# ISO country code

PROVINCE="Slask"
LOCALITY="Gliwice"
ORGANISATION="Politechnika Slaska"
ORG_UNIT="SMTP Serwer"
COMMON_NAME=$site
EMAIL="pzawad@ps.edu.pl"

OPTIONAL_COMPANY_NAME="Postfix"

# leave challenge password blank
CHALLENGE_PASSWORD=""

# valid for one year
DAYS="-days 365"

# create the certificate request
cat <<__EOF__ | openssl req -new -nodes -keyout newreq.pem -out newreq.pem $DAYS
$COUNTRY
$PROVINCE
$LOCALITY
$ORGANISATION
$ORG_UNIT
$COMMON_NAME
$EMAIL
$CHALLENGE_PASSWORD
$OPTIONAL_COMPANY_NAME
__EOF__

# sign it
openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem

# move it
mkdir -p $site
mv newreq.pem $site/key.pem
chmod 400 $site/key.pem
mv newcert.pem $site/cert.pem
cd $site

# create server.pem for smtpd
cat cert.pem ../demoCA/cacert.pem key.pem >server.pem
chmod 400 server.pem

# create fingerprint file
openssl x509 -fingerprint -in cert.pem -noout > fingerprint

# create pkcs12 certificate for netscape (probably not needed)
#openssl pkcs12 -export -in cert.pem -inkey key.pem \
#

-certfile ../demoCA/cacert.pem -name "$site" -out cert.p12

# Link to postfix directory
ln -s $PWD/key.pem /etc/postfix/key.pem
ln -s $PWD/server.pem /etc/postfix/server.pem
ln -s $PWD/cert.pem /etc/postfix/cert.pem
ln -s $PWD/fingerprint /etc/postfix/fingerprint

cd ..

Jednak przed jego wykonaniem należy przypisać poprawne wartości zmiennym opisującym dane identyfikujące
serwer, tj. obiekt któremu będzie wystawiony certyfikat.

Po utworzeniu certyfikatów informujemy postfix’a, że powinien korzystać z obsługi TLS. Do pliku /etc/postfix/main.cf

dopisujemy

# TLS
smtpd_use_tls = yes
#smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/server.pem
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_CAfile = /etc/postfix/cert.pem
smptd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

i restarturtejemy serwer. Uaktywnienie opcji smtpd tls auth only zablokuje możliwość autoryzacji bez korzysta-
nia z TLS.

Konfiguracja kmail

Konfigurację klienta omówimy na przykładzie programu kmail. Przystosowanie innych

programów pocztowych do korzystania z serwera SMTP wymagającego uwierzytelnienia można znaleźć na
serwerze Wirtualnej Polski.

Konfigurację rozpoczynamy od ustawienia nowej identyfikacji odpowiadajęcej adresowi pocztowemu na ser-

werze wybierając Ustawienia →Konfiguruj: KMail. W zakładce Identyfikacja wybieramy przycisk Nowa..., po-
dajemy skrótową nazwę nowej identyfikacji i po zatwierdzeniu obowiązkowo uzupełnianiamy pola dotyczące
imienia i nazwiska oraz adresu pocztowego (Rys. 12). Jeżeli wszystko poszło pomyślnie ekran ustawień identy-

Rys. 12: Tworzenie nowej identyfikacji

fikacji powinien wyglądać podobnie jak na Rys. 13.

Następnie pozostając w okienku konfiguracyjnym kmail’a wybieramy pozycję Sieć i zakładkę Wysyłanie,

a następnie dodajemy nowy serwer SMTP którego będziemy używać do wysyłki. W odpowiednich polach wpi-
sujemy skrótową nazwę serwera, jego adres IP, port (zazwyczaj 25) oraz zaznaczmy, że serwer wymaga uwierzy-
telnienia i wpisujemy nazwę uzytkownika uprawnionego do korzystania z serwera (Rys. 14). Następnie w tym
samy okienku dialogowym wybieramy zakładkę Bezpieczeństwo służącym do wyboru zabezpieczeń stosowanych
przez serwer. Aby dowiedzieć się jakie opcje mamy do wyboru najłatwiej skorzystać z przycisku Sprawdź możli-
wości serwera ... (Rys. 15) Zalecane jest wykorzystania najmocniejszych zabezpieczeń oferowanych przez serwer
tj. włączenie szyfrowania i przesyłania hasła w postaci kodowanej przy uzyciu MD5.

Jeżeli serwer z uwierzytelnieniem jest domyślny, również nową identyfikację ustawiamy jako domyślną (wy-

bieramy identyfikację na liście i naciskamy przycisk Ustaw jako domyślne).

Gdy serwer wymagający uwierzytelnienia nie jest domyslny, a chcemy aby listy z ustawioną identyfikacją

adresu z serwera były wysyłane również poprzez SMTP z tego samego serwera w konfiguracji identyfikacji

Rys. 13: Parametry nowej identyfikacji

Rys. 14: Parametry identyfikujące serwer SMTP.

Rys. 15: Ustawienia ochrony poczty wysyłanej.

(Konfiguruj: KMail →Identyfikacja) zaznaczmy Wysyłanie i wybieramy z listy pożądany serwer SMTP (Rys.
16).

Rys. 16: Ustawienia serwera SMTP zależnie od używanej identyfikacji

Document Outline

Podstawowe wiadomosci o sieciach TCP/IP
Zalozenia
Konfiguracja rutera i sciany ogniowej
Konfiguracja uslug na serwerze

Wyszukiwarka

Podobne podstrony:
SK-cw3 2h Konfigurowanie sieci WLAN, Sieci Komputerowe
konfiguracja sieci rejestratory bcs (2)
SK ćw3 4h Konfigurowanie sieci VLAN, Sieci Komputerowe
konfigóracja sieci, Do Nauki, INFORMATYKA
Konfigurowanie sieci VLAN
2c 3 2 4 9 Lab Rozwiązywanie problemów z konfiguracja sieci VLAN
Konfiguracja sieci VLAN
Konfiguracja sieci serwer
SK ćw4B 2h Konfigurowanie sieci WLAN v3, inf, IV sem, Sieci komputerowe, Laborki
Nauka Konfiguracja sieci
Konfiguracja sieci w XP
Konfiguracja sieci i instalacja protokołów sieciowych, ♞♞♞ Hacking, HACK, Hacking
SK-cw3 2h Konfigurowanie sieci WLAN, Sieci Komputerowe
konfiguracja sieci rejestratory bcs (2)
konfiguracja sieci lokalnej

więcej podobnych podstron