Laboratorium Systemów Operacyjnych

TCP/IP w systemie Unix

autor: Janusz Karmański

Komunikacja w sieci pracującej pod kontrolą systemu Unix odbywa się w opraciu o protokoły z rodziny TCP/IP. Są to zarazem podstawowe protokoły używane do komunikacji w Internecie. Listę protokołów obsługiwanych przez dany serwer można znaleźć w pliku /etc/protocols.

. 

Powiązania pomiędzy protokołami z rodziny TCP/IP

Protokół IP

Każdy komputer w sieci ma przypisany czterobajtowy numer IP. Numer IP składa się z dwóch części: numeru sieci Net-ID oraz numeru komputera (hosta) Host-ID. Obie części mogą różnić się rozmiarem, w związku z czym zdefiniowane są trzy klasy adresów IP:

Klasa A    siec.host.host.host         przy czym pierwszy bit adresu jest równy 0
Klasa B    siec.siec.host.host         przy czym pierwsze dwa bity adresu są równe 10
Klasa C    siec.siec.siec.host         przy czym pierwsze trzy bity adresu są równe 100

Klasa A obejmuje 127 bardzo dużych sieci o maksymalnej liczbie 16 milionów hostów (trzy bajty na numer hosta). Klasa B oznacza 16000 dużych sieci o maksymalnej liczbie 65000 hostów. Klasa C to 2 miliony sieci o maksymalnej liczbie 256 hostów.

Przykładowo klasa B jest klasą adresów używanych na Politechnice Śląskiej - wszystkie adresy zaczynają się od liczb 157.158. Dodatkowo wykorzystywany jest mechanizm podsieci - dwubajtowy numer hosta podzielony jest na 11 bajtów adresu podsieci oraz 5 bajtów faktycznego numeru komputera w podsieci. Tak więc w każdej podcieci może znajdować się fizycznie max. 32 - 2 = 30 komputerów (pierwszy adres z przedziału zarezerwowany jest dla numeru sieci, a ostatni dla adresu rozgłoszeniowego - broadcast). Rozwiązanie takie jest możliwe dzięki stosowaniu maski sieci równej 255.255.255.224 (bity równe 1 odpowiadają bitom sieci, ostatnie 5 bitów równych 0 mówi, że odpowiadające im pięć bitów w adresie IP to numer hosta).
 

Protokół ARP

Aby pakiet IP mógł być przesłany w sieci musi zostać umieszczony w ramce odpowiedniej dla łącza fizycznego danej sieci (np. dla sieci Ethernet). Ramka taka musi zawierać adres komputera docelowego, ale nie adres IP będący logicznym adresem stosowanym w sieci Internet, lecz fizyczny adres karty sieciowej w komputerze docelowym. Jeżeli adresatem pakietu jest komputer pracujący w tej samej podsieci co nadawca (można to sprawdzić znając adresy IP nadawcy oraz adresata a także maskę danej sieci) pakiet jest przesyłany bezpośrednio do niego. W przeciwnym razie pakiet przesyłany jest do rutera, który następnie sam martwi się co z nim dalej zrobić.

Aby jednak przesłać ramkę do adresata trzeba jak już wspomniano znać jego adres fizyczny. Do uzyskania adresów fizycznych komputerów pracujących w podsieci stosowany jest protokół ARP (Address Resolution Protocol). Host lub router chcący uzyskać adres fizyczny komputera o znanym numerze IP wysyła ARP broadcast z zapytaniem o numer IP. Broadcast ten odbierany jest przez wszystkie komputery w sieci. Jeżeli któryś z nich stwierdzi, że to jego numer IP, odsyła odpowiedź z której można odczytać jego numer fizyczny. Aby w przyszłości nie pytać się ponownie o ten sam adres otrzymana odpowiedź jest przez system buforowana.

Polecenie systemowe arp pozwala na zadawanie pytań o fizyczne adresy kart komputerów o znanym adresie IP. Wywołane z opcją -a wyświetla wszystkie znane adresy.

Protokoły UDP oraz TCP

Numery IP identyfikują komputery w sieci, nie mówią natomiast nic o aplikacji będącej adresatem pakietu. Tym zajmują się protokoły warstwy transportowej TCP oraz UDP. Adresacja na poziomie tych protokołów wykorzystuje pojęcie portu. Port jest to 16-bitowa liczba całkowita, identyfikująca adresata (aplikację), który ma odebrać pakiet, jak również jego nadawcę. Część numerów portów (przeważnie mniejsze od 1024) przypisanych jest na stałe do pewnych usług (protokołów wyższych warstw), jak Telnet (port 23), FTP (porty 20 i 21) czy HTTP (zazwyczaj port 80). Porty o wyższych numerach od 1024 mogą być używane do komunikacji przez dowolne aplikacje użytkownika.

Protokół UDP jest prostym protokołem bezpołączeniowym - wysyłając pakiet nie mamy żadnej pewności czy dotrze on do adresata. W odróżnieniu od UDP protokół TCP jest znacznie bardziej złożonym protokołem opartym na nawiązywaniu połączeń między nadawcą a odbiorcą przesyłanych pakietów. Każdy odebrany pakiet powoduje wysłanie potwierdzenia. Jeżeli pakiety nie dojdą do adresata i nadawca nie otrzyma potwierdzenia będą one retransmitowane. W celu uniknięcia przekłamań pakiety są numerowane oraz zaopatrzone w sumę kontrolną.

Poniższy rysunek przedstawia przykładową drogę jaką przebywa pakiet protokołu FTP między dwoma komputerami - klientem i serwerem:

Routing

Jeżeli adresat pakietu znajduje się w innej podsieci niż nadawca pakiety przekazywane są między sieciami przez routery. Po otrzymaniu pakietu router sprawdza czy docelowy adres IP pakietu odnosi się do sieci lokalnej, przekazując w takim przypadku pakiet bezpośrednio do adresata. W przeciwnym razie router sprawdza w tzw. tabeli routingu jaka jest najlepsza droga do podsieci docelowej. Tabela routingu zawiera listę routerów obsługujących znane podsieci. Jeżeli w tabeli routingu nie będzie informacji o danej sieci docelowej pakiet przekazywany jest do pewnego domyślnego routera.

Aby tabele routingu zawierały zawsze aktualne informacje (i np. nie kierowały pakietów przez routery które przestały działać) routery automatycznie wymieniają między sobą ich zawartość za pomocą odpowiednich protokołów routingu.

Tabelę routingu można wyświetlić za pomocą polecenia netstat -r. To samo polecenie wywołane bez parametrów wyświetli natomiast wszystkie aktywne (nawiązane) połączenia sieciowe. Informacje o tym czy istnieje fizyczne połączenie z dowolnym hostem IP można uzyskać za pomocą polecenia ping. Wysyła ono co sekundę pakiet kontrolny do maszyny docelowej i informuje o otrzymaniu odpowiedzi lub jej braku. Z kolei polecenie traceroute wysyła pakiety mające ograniczny czas życia w sieci i pozwala prześledzić krok po kroku drogę jaką one przebywają (routery przez które przechodzą).

Konfiguracja systemu

Zanim przystąpimy do konfigurowania usług udostępnianych przez nasz serwer trzeba skonfigurować i przetestować połączenie komputera z siecią.  Program netcfg umożliwia wygodne konfigurowanie interfejsów sieciowych.  Ważniejsze pliki konfiguracyjne (modyfikowane m. in. przez netcfg) w systemie Linux, o których warto wiedzieć, to:

/etc/hosts
W tym pliku musi znajdować się adres oraz nazwa naszego komputera, a także opcjonalnie adresy i nazwy innych komputerów w sieci. Przykładowa zawartość pliku:

## Configured using SAM by root on Mon Jun  5 17:38:22 1995

# @(#)$Header: hosts,v 1.8.109.1 91/11/21 12:01:46 kcs Exp $

#

# The form for each entry is:

# <internet address>    <official hostname> <aliases>

#

# For example:

# 192.1.2.34    hpfcrm  loghost

#

# See the hosts(4) manual page for more information.

# Note: The entries cannot be preceded by a space.

#       The format described in this file is the correct format.

#       The original Berkeley manual page contains an error in

#       the format description.

#

127.0.0.1       localhost       loopback

157.158.11.129  homer homer.iinf.gliwice.edu.pl  hp750

157.158.11.158  nale    # CISCO router

157.158.11.157  hp3sinet.iinf.gliwice.edu.pl hp3sinet

157.158.11.130  bart bart.iinf.gliwice.edu.pl

157.158.11.155  room414

/etc/host.conf
Plik mówi skąd należy pobierać adresy komputerów. Zazwyczaj ma on następującą postać:

order hosts,bind

multi on

Pierwszy wiersz mówi, że adresów komputerów należy szukać najpierw w pliku /etc/hosts, a dopiero jeżeli plik hosts nie zawiera wpisu dla szukanego komputera, należy posłać zapytanie do serwera nazw. Następny wiersz wymusza przekazywanie wszystkich znalezionych w pliku hosts adresów szukanego komputera, a nie tylko pierwszego z nich.

/etc/resolv.conf
Plik konfiguracyjny tzw. "resolwera" nazw.  Słowo domain pozwala zdefiniować domenę do której należy komputer. Po słowie search można podać domeny, które będą automatycznie przeszukiwane. Słowo nameserver określa adres serwera DNS, może być powtórzone wielokrotnie. Przykładowa zawartość pliku:

domain iinf.polsl.gliwice.pl

search iinf.polsl.gliwice.pl polsl.gliwice.pl

nameserver 157.158.11.129

Demony usług sieciowych

Demony sieciowe to programy pracujące na serwerze Unixowym odpowiedzialne za udostępnianie różnych usług jak Telnet (demon telnetd) czy Ftp (demon ftpd). W systemie Linux programy te znajdują się w kartotece /usr/sbin, a ich nazwy przeważnie zaczynają się od przedrostka in.(np. in.telnetd, in.ftpd, in.rlogind).

Chcąc skorzystać z którejś z usług oferowanych przez serwer Unix'a program (klient danej usługi) uruchamiany przez użytkownika na jego komputerze musi nawiązać połączenie z odpowiednim demonem sieciowym (serwerem danej usługi) pracującym na serwerze. Istnieją dwa tryby pracy demonów sieciowych:

• niezależny - demon rozpoczyna pracę przy starcie systemu Unix i jest obecny cały czas "w tle", nasłuchując na odpowiadającym mu porcie nadchodzących pakietów TCP lub UDP. W tym trybie pracuje min. serwer pocztowy sendmail oraz (opcjonalnie) serwer WWW Apache.

• uruchamiany przez inetd - demon uruchamiany jest jedynie w razie potrzeby przez program inetd. W tym trybie pracuje większość demonów sieciowych, min. telnetd, ftpd, fingerd itd.

inetd

Inetd odpowiedzialny jest za odbieranie pakietów z interfejsu sieciowego i uruchamianie dla nich odpowiednich demonów sieciowych. Do konfiguracji jego pracy służą pliki /etc/services oraz /etc/inetd.conf. Pierwszy z nich zawiera listę łączącą numery portów z dostępnymi na nich usługami (początkowy fragment pliku):

#/etc/services

#

#nazwa          numer portu     aliasy          komentarz

#

tcpmux          1/tcp                           # rfc-1078

echo            7/tcp

echo            7/udp

discard         9/tcp           sink null

discard         9/udp           sink null

systat          11/tcp          users

daytime         13/tcp

daytime         13/udp

netstat         15/tcp

qotd            17/tcp          quote

chargen         19/tcp          ttytst source

chargen         19/udp          ttytst source

ftp-data        20/tcp

ftp             21/tcp

telnet          23/tcp

smtp            25/tcp          mail

time            37/tcp          timserver

time            37/udp          timserver

rlp             39/udp          resource        # resource location

name            42/udp          nameserver

whois           43/tcp          nicname         # usually to sri-nic

domain          53/tcp

domain          53/udp

mtp             57/tcp                          # deprecated

bootps          67/udp                          # bootp server

bootpc          68/udp                          # bootp client

tftp            69/udp

gopher          70/tcp                          # gopher server

rje             77/tcp

finger          79/tcp

http            80/tcp                          # www is used by some broken 

www             80/tcp                          # progs, http is more correct

link            87/tcp          ttylink

kerberos        88/udp          kdc             # Kerberos authentication--udp

kerberos        88/tcp          kdc             # Kerberos authentication--tcp

supdup          95/tcp                          # BSD supdupd(8)

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

Drugi plik konfiguracyjny /etc/inetd.conf mówi demonowi inetd, co powinien zrobić po otrzymaniu żądania połączenia z konkretną usługą - a dokładnie jaki demon sieciowy uruchomić. Wygląda on zazwyczaj następująco (początkowy fragment):

#/etc/inetd.conf

#

#usługa  rodzaj gniazda protokół flagi użytkownik program_obsługi[argumenty]

#

#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

time            stream  tcp      nowait  root     internal

time            dgram   udp      wait    root     internal

#

# These are standard services.

#

telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.ftpd

#fsp    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.fspd

#

# Shell, login, exec and talk are BSD protocols.

#

shell   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd

login   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind

#exec   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rexecd

talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd

ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd

#

# Mail, news and uucp services.

#

smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.smtpd

#nntp   stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/in.nntpd

#uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico

#comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat

#

# Pop et al

#

#pop-2  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d

#pop-3  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d

#

# `cfinger' is for the GNU finger server available for Debian.  (NOTE: The

# current implementation of the `finger' daemon allows it to be run as `root'.)

#

#cfinger stream tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd

#finger stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.fingerd

#netstat        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/netstat

#systat stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx

#

# Tftp service is provided primarily for booting.  Most sites

# run this only on machines acting as "boot servers."

#

#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd

#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot

#bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120

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

Jak widać z powyższego pliku inetd.conf, program inetd nie uruchamia zazwyczaj odpowiedniego demona sieciowego bezpośrednio (chociaż mógłby to robić), ale korzysta z pośrednictwa tcpd.

tcpd

Program tcpd pośredniczy w wywoływaniu właściwych demonów sieciowych realizując jednocześnie dwie ważne funkcje:

• zapewnienie mechanizmów kontroli dostępu do usług. Pozwala określić jacy użytkownicy mają (lub nie mają) dostęp do poszczególnych usług, oraz z jakich komputerów jest możliwe (niemożliwe) korzystanie z tych usług.

• rejestracja wszystkich prób dostępu do systemu w odpowiednich logach (patrz katalog /var/log). Ich późniejsza analiza może umożliwić administratorowi np. wykrycie nielegalnych prób wejścia do systemu.

Reguły dostępu do usług definiowane są w plikach /etc/hosts.allow oraz /etc/hosts.deny. Tcpd najpierw przeszukuje plik hosts.allow. Jeżeli znaleziona zostanie reguła pasująca do użytkownika i/lub komputera żądającego usługi, zgłoszenie jest realizowane. W przeciwnym razie przeszukiwany jest plik hosts.deny. Jeżeli tym razem znaleziona zostanie reguła pasująca do użytkownika i/lub komputera żądającego usługi, zgłoszenie jest odrzucane. W przeciwnym razie zgłoszenie jest realizowane (polityka domyślna również przy pustych plikach /hosts.allow oraz /hosts.deny, lub ich braku).

Format reguł definiowanych w omawianych plikach jest następujący:

usługi: komputery [: spawn/twist (polecenie)]

gdzie:

• usługi - lista oddzielonych przecinkami programów demonów sieciowych (np. in.ftpd) do których odnosi się dana reguła.

• komputery - lista oddzielonych przecinkami nazw komputerów, adresów IP, lub wzorców adresów (patrz dalej).

• polecenie - opcjonalne polecenie wykonywane przy każdym dopasowaniu bieżącej reguły. Może zawierać pewne znaki specjalne, min.:

• %h - nazwa (lub adres IP jeżeli nazwa jest niedostępna) komputera korzystającego z usługi,

• %u - nazwa użytkownika lub "unknown"

• %c - odpowiada %u@%h

• %d - nazwa procesu wywoływanego demona

Wzorce nazw komputerów można tworzyć rozpoczynając nazwę domeny kropką (np. .gliwice.pl), co oznacza wszystkie komputery z podanej domeny oraz jej pod-domen, lub też kończąc fragment adresu kropką - wtedy pozostała jego część może mieć dowolne wartości (np. 157.158. oznacza wszystkie komputery o adresach 157.158.x.x). Inna możliwość to zdefiniowanie podsieci za pomocą pary sieć/maska, np. 157.158.11.160/255.255.255.224.

Specjalne znaczenie mają słowa:

• ALL - wszystkie komputery lub wszystkie usługi

• PARANOID - komputery których nazwa nie odpowiada nazwie pobranej z serwera DNS dla adresu IP nadawcy pakietu. Pozwala to wykrywać pakiety od komputerów próbujących podszywać się pod cudze nazwy.

• lista1 EXCEPT lista 2 - wszystkie komputery (lub usługi) z listy 1 oprócz tych wymienionych na liście 2.

Opcja spawn (program) uruchomia program w momencie, kiedy ktoś próbuje skorzystać z danej usługi, a następnie umożliwia dalsze logowanie. Opcja twist (program) tak jak wyżej uruchamia program, ale nie pozwala na skorzystanie z usługi.

Przykłady plików hosts.allow oraz hosts.deny:

#/etc/hosts.allow

#

# dostęp do ftp dla wszystkich

in.ftpd:    ALL

#

# dostęp do usług telnet oraz finger tylko z sieci Politechniki Śląskiej

in.telnetd, in.fingerd:    .polsl.gliwice.pl

#

#/etc/hosts.deny

#

# zakaz dostępu komputerom o "podejrzanych" nazwach do wszystkiego, 

# wysyłanie administratorowi listu o próbie dostępu:

ALL:    PARANOID:    twist (echo Próba dostępu PARANOID do usługi %d przez %c | /bin/mail -s "PARANOID" root)

#

# zakaz dostępu dla wszystkich do usługi talk:

in.talk:    ALL

Więcej informacji na temat demona tcpd oraz formatu jego plików konfiguracyjnych po wydaniu poleceń man tcpd oraz man 5 hosts_access.

Inne mechanizmy ograniczenia dostępu do systemu

Plik /etc/ftpusers zawiera listę użytkowników, którzy nie mogą logować się do systemu za pomocą usługi ftp. Dla zwiększenia bezpieczeństwa systemu powinien on zawierać nazwy użytkowników "specjalnych" - wykorzystywanych przez różne programy usługowe (np. uucp, mail, news) oraz obowiązkowo root'a.

Plik /etc/securetty z kolei zawiera listę terminali z których może się logować użytkownik root.

Zadania do wykonania

Uwaga: Przed modyfikacją dowolnego pliku konfiguracyjnego zachować jego oryginalną wersję. Po zakończeniu laboratorium odtworzyć stan systemu z przed jego rozpoczęcia.

1. Za pomocą polecenia ping sprawdzić jakość połączenia dla hostów:

• 157.158.1.3

• www.ietu.katowice.pl

• homer.fil.us.edu.pl

• 128.214.248.6

• ftp.microsoft.com

2. Za pomocą traceroute zbadać drogę do powyższych serwerów. Czy droga do konkretnego serwera musi za każdym razem być taka sama?

3. Wyświetlić tabelę routingu lokalnego komputera za pomocą polecenia netstat. Zinterpretować poszczególne pozycje w tabeli. Odczytać z uzyskanej tabeli adres IP domyślnego rutera. Podać fizyczny adres domyślnego routera (polecenie arp).

4. Używając programu Telnet i protokołu HTTP ściągnąć z serwera www.polsl.gliwice.pl stronę główną (index.html).

5. Skonfigurować system tak, aby :

• zapewnić automatyczne przeszukiwanie domeny icm.edu.pl. Jak (i dlaczego) wpłynęłoby na wydajność systemu dodanie automatycznego przeszukiwania domeny edu.pl?

• adres komputera zeus.polsl.gliwice.pl nie był nigdy pobierany z serwera DNS, ale pamiętany lokalnie.

• użytkownik root mógł logować się tylko z pierwszej konsoli (telnet'em ani ftp'em również nie)

• można było wejść telnetem tylko z lokalnej sieci oraz z komputera moj.komputer.w.chalupie.pl

• przy próbie wejścia telnetem z komputera o podejrzanej nazwie (patrz PARANOID) użytkownik powinien zobaczyć informację "dostęp niedozwolony.....", a do root'a powinien zostać wysłany mail z adresem komputera z którego miała miejsce próba dostępu.

• wszystkie wejścia ftp'em ze świata były dozwolone, ale natychmiast raportowane administratorowi (nie dotyczy wejść z sieci lokalnej)

• z komputerów konkurencyjnej firmy (np. o domenie microsoft.com) nie można było skorzystać z usługi ftp naszego serwera.

• wszystkie pozostałe usługi (oprócz poczty, WWW,  telnet oraz ftp) były zabronione.
  Uwaga: Wszystkie powyższe ograniczenia powinny być zapewnione jednocześnie.

6. Przekonfigurować demon httpd tak, aby pracował na porcie 1080 i był uruchamiany nie przy starcie systemu, a jedynie w razie potrzeby. Jakie mechanizmy bezpieczeństwa oferuje httpd ? (zapoznać się z plikami konfiguracyjnymi oraz dokumentacją).

7. Zapoznać się z protokołami obsługiwanymi przez system (/etc/protocols). Spróbować krótko wyjaśnić przeznaczenie przynajmniej części z nich.

Lokalizacja potrzebnych narzędzi (być może) nie dostępnych na domyślnej ścieżce:

/sbin/arp
/usr/sbin/setup
/usr/sbin/traceroute

Uwaga: Proszę spodziewać się niespodziewanej kartkówki na początku zajęć (sprawdzającej znajomość instrukcji

---