Poté, co úspěšně nastavíte IP a resolver, musíte začít věnovat pozornost službám, které hodláte po síti poskytovat. Tato kapitola se zabývá konfiguracemi několika malých síťových aplikací, včetně serveru inetd a programů z rodiny rlogin. Krátce se také zmíníme o rozhraní RPC (Remote Procedure Call), na kterém jsou založeny služby NFS (Network File System) a NIS (Network Information System). Bohužel konfigurace systémů NFS a NIS vyžaduje trochu více prostoru, proto budou tyto systémy probrány v samostatných kapitolách. To platí i pro elektronickou poštu a pro síťové news.
Samozřejmě v této knize nemůžeme probrat všechny síťové aplikace. Budete-li si chtít nainstalovat nějakou z aplikací, která zde není uvedena, jako například programy talk, gopher nebo Xmosaic, nahlédněte prosím na stránky jejich manuálů, kde najdete více informací.
Služby jsou často poskytovány pomocí tzv. démonů. Démon je program, který otevře určitý port a čeká na příchozí spojení. Pokud k takovému spojení dojde, vytvoří proces potomka, jenž toto spojení přijme, zatímco rodičovský proces bude stále pokračovat v odposlouchávání dalších požadavků. Tento koncept má nevýhodu v tom, že každá poskytovaná služba musí mít spuštěného démona, který odposlouchává port z důvodu případného výskytu spojení, což obecně znamená, že se plýtvá systémovými zdroji, například odkládacím prostorem.
Proto většina unixových instalací spouští tzv. "super-server", který vytvoří sockety pro většinu služeb, které současně odposlouchává pomocí systémového volání select(2). Když vzdálený hostitel požádá o některou z nabízených služeb, super-server to zaznamená a pro daný port vytvoří speciální server.
Obecně používaný super-server se nazývá inetd, internetový démon (Internet Daemon). Je spouštěn při procesu zavádění systému a seznam služeb, které má spravovat, získává ze spouštěcího souboru s názvem /etc/inetd.conf. Kromě Výše zmíněných volaných serverů existuje i spousta triviálních služeb, které provádí démon inetd sám. Tyto služby se nazývají vnitřní služby. Jednou z nich jsou služba chargen, která generuje řetězec znaků a služba daytime, která vrací systémový čas.
V tomto souboru se položka skládá z jednotlivých řádek, které jsou tvořeny následujícími poli:
service type protocol wait user server cmdline
Jednotlivá pole mají následující význam:
#
# inetd služby
ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l
telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd b/etc/issue
#finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless
login stream tcp nowait root /usr/sbin/rlogind in.rlogind
shell stream tcp nowait root /usr/sbin/rshd in.rshd
exec stream tcp nowait root /usr/sbin/rexecd in.rexecd
#
# vnitřní služby inetd
#
daytime stream tcp nowait root internal
daytime dgram udp nowait root internal
time stream tcp nowait root internal
time dgram udp nowait root internal
echo stream tcp nowait root internal
echo dgram udp nowait root internal
discard stream tcp nowait root internal
discard dgram udp nowait root internal
chargen stream tcp nowait root internal
chargen dgram udp nowait root internal
Na obrázku 9.1 vidíte vzorový soubor inetd.conf. Služba finger je uvedená jako komentář, což znamená, že není dostupná. To je často z důvodů bezpečnostních, protože může být útočníky zneužita k získání jmen uživatelů ve vašem systému.
Také služba tftp je okomentována. Služba tftp implementuje tzv. primitivní protokol pro přenos souborů (Primitive File Transfer Protocol), který umožňuje z vašeho systému přenést libovolný okolnímu světu dostupný soubor, aniž by byla prováděna jakákoliv kontrola pomocí hesla apod. To je nepříjemné zejména u souboru /etc/passwd a ještě horší je to v případě, kdy nepoužíváte stínová hesla.
Protokol TFTP obecně používají bezdiskoví klienti a X-terminály ke stahování startovacího kódu ze zaváděcích serverů. Pokud potřebujete spouštět službu tftpd z tohoto důvodu, ujistěte se, že jste omezili její rozsah pouze na ty adresáře, ze kterých budou klienti získávat soubory. To provedete tak, že příkazové řádce služby tftpd přidáte názvy těchto adresářů. Výše uvedené demonstruje druhý řádek výpisu.
Protože přístup k počítačům prostřednictvím sítě přináší mnoho bezpečnostních rizik, byly navrženy aplikace, které chrání před několika typy útoků. Některé z těchto aplikací mohou obsahovat chyby (nejdrastičtěji to demonstruje červ RTM Internet) nebo nemusí umět rozliýovat mezi bezpečnými hostiteli, od kterých budou přijímány požadavky na konkrétní službu, a nebezpečnými hostiteli, jejichž požadavky by měly zamítnout. Již jsme se krátce zmínili o službách finger a tftp. Tyto služby budete asi chtít povolit pouze "důvěryhodným hostitelůmio, což ale nelze pomocí standardního nastavení, při kterém super-server inetd poskytuje tuto službu buď všem klientům, anebo žádnému klientovi.
Pro tento účel je vhodný nástroj tcpd, tzv. zástupce démonů. U služeb protokolu TCP, které chcete monitorovat nebo chránit, je tento démon volán místo programu serveru. Nástroj tcpd zapisuje požadavky do démona syslog, kontroluje, zda je vzdálený hostitel oprávněn používat danou službu a pouze v tom případě spustí skutečný program serveru. Všimněte si, že tento postup nefunguje u služeb založených na protokolu UDP.
Chcete-li například zastoupit démona finger, musíte v souboru inetd.conf změnit odpovídající řádku následujícím způsobem:
# zastoupení démona finger
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
Pokud nepřidáte žádné řízení přístupu, bude se tato úprava klientovi jevit stejně, jako obvyklé nastavení služby finger, s tou výjimkou, že veškeré požadavky budou zapisovány s prioritou auth do souboru syslog.
Řízení přístupu je implementováno za pomoci dvou souborů, které se jmenují /etc/hosts.allow a /etc/hosts.deny. Tyto soubory obsahují položky, které některým hostitelům povolují, resp. zakazují přístup k určitým službám. Když nástroj tcpd vyřizuje od klienta s názvem hostitele biff.foobar.com požadavek na použití určité služby, jako je služba finger, vyhledá v souborech hosts.allow a hosts.deny (v uvedeném pořadí) položky odpovídající jak požadované službě, tak i hostiteli klienta. Pokud je odpovídající položka nalezena v souboru hosts.allow, bude přístup povolen bez ohledu na položky v souboru hosts.deny. Pokud ale bude odpovídající položka nalezena v souboru hosts.deny, bude požadavek odmítnut a spojení se ukončí. Jestliže se ani v jednom souboru odpovídající položka nenajde, bude požadavek přijat.
Položky v souboru s přístupy vypadají následovně:
servicelist: hostlist [:shellcmd]
Pole servicelist obsahuje seznam názvů služeb ze souboru /etc/services nebo klíčové slovo ALL. Chcete-li zadat všechny služby kromě služeb finger a tftp, použijte řetězec "ALL EXCEPT finger, tftp".
Pole hostlist obsahuje seznam názvů hostitelů nebo IP-adres, případně klíčová slova ALL, LOCAL nebo UNKNOWN. Klíčovému slovu ALL vyhovují všichni hostitelé, zatímco klíčovému slovu LOCAL vyhovují pouze názvy hostitelů, kteří neobsahují tečku.
Klíčovému slovu UNKNOWN odpovídají všichni hostitelé, u nichž selhalo vyhledávání jejich názvu nebo adresy. Název začínající tečkou vyhovuje všem hostitelům, jejichž doména je shodná s poskytnutým názvem. Například název domény .foobar.com vyhovuje hostitelům na adrese biff.foobar.com. Podobná opatření existují i pro síťové IP-adresy a pro čísla podsítí. Chcete-li více detailů, nahlédněte prosím do manuálové stránky hosts_access(5).
Chcete-li zakázat přístup ke službám finger a tftp všem hostitelům s výjimkou místních hostitelů, vložte do souboru /etc/hosts.deny následující řádku a soubor /etc/hosts.allow ponechte prázdný:
in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain
Volitelné pole shellcmd může obsahovat příkaz rozhraní, jenž bude vykonán při splnění dané položky. To je užitečné při nastavování pastiček, které mohou odhalit potenciální útočníky:
in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \
echo "request from %d@%h" >> /var/log/finger.log; \
if [ %h != "vlager.vbrew.com" ]; then \
finger -1 @%h >> /var/log/finger.log \
fi
Nástroj tcpd nahradí argumenty %h a %d skutečným názvem hostitele klienta, resp. skutečným názvem služby. Chcete-li více detailů, nahlédněte prosím do manuálových stránek hosts_access(5).
Čísla portů, na kterých jsou nabízeny jisté "standardníi. služby, jsou definovány v RFC "Assigned Numbersid. Aby mohly servery nebo klienti převádět názvy služeb na tato čísla, musí být alespoň část z tohoto seznamu uložena na každém hostiteli; tato část je uložena v souboru s názvem /etc/services. V tomto souboru má každá položka následující syntaxi:
service port/protocol [aliases]
Zde pole service definuje název služby, pole port definuje port, na kterém je daná služba nabízena, a pole protokol definuje typ používaného transportního protokolu. Obecně toto pole nabývá buď hodnoty udp, nebo hodnoty tcp. Službu je možné nabízet i pro více protokolů, stejně tak lze nabízet různé služby na stejném portu, pokud používají odlišné protokoly. Pole aliases umožňuje zadat alternativní názvy stejné služby.
Soubor services, který je dodáván společně se síťovým softwarem, nebudete muset obvykle měnit. Přesto zde uvádíme malý výpis z tohoto souboru:
# Soubor services:
#
# známé služby
echo 7/tcp # Echo
echo 7/udp #
discard 9/tcp sink null # Discard
discard 9/udp sink null #
daytime 13/tcp # Daytime
daytime 13/udp #
chargen 19/tcp ttytst source # Character Generator
chargen 19/udp ttytst source #
ftp-data 20/tcp # File Transfer Protocol (Data)
ftp 21/tcp # File Transfer Protocol (Contr
telnet 23/tcp # Virtual Terminal Protocol
smtp 25/tcp # Simple Mail Transfer Protocol
nntp 119/tcp readnews # Network News Transfer Protoco
#
# unixové služby
exec 512/tcp # BSD rexecd
biff 512/udp comsat # nová pošta
login 513/tcp # vzdálené přihlášení
who 513/udp whod # vzdálené who a update
shell 514/tcp cmd # vzdálené příkazy
syslog 514/udp # vzdálené protokolování
printer 515/tcp spooler # vzdálený tisk
route 520/udp router routed # směrovací protokol
Všimněte si, že například služba echo je poskytována na portu 7 jak pro protokol TCP, tak i pro protokol UDP a port 512 používají dvě odlišné služby, konkrétně démon COMSAT (který upozorňuje uživatele na nově došlou poštu, viz xbiff(1x)), jenž používá protokol UDP, a služba vzdáleného spouštění (rexec(1)), která používá protokol TCP.
Podobně jako soubor se službami potřebuje i síťová knihovna nějaký způsob, jakým by mohla přeložit názvy protokolů - například těch protokolů, které jsou použity v souboru services - na čísla protokolů, kterým by rozuměly IP-vrstvy ostatních hostitelů. To se provede vyhledáním daného názvu v souboru /etc/protocols. Ten obsahuje na každé řádce jednu položku. Každá položka obsahuje název protokolu a číslo sdružené s daným protokolem. Provádění změn v tomto souboru je ještě méně pravděpodobné, než zasahování do souboru /etc/services. Nyní následuje vzorový soubor protocols:
#
# Internetové (IP) protokoly
#
ip 0 IP # internet protocol
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group multicast protocol
tcp 6 TCP # transmission control protocol
udp 17 UDP # user datagram protocol
raw 255 RAW # RAW IP interface
Balík RPC neboli Vzdálené volání procedur (Remote Procedure Call) poskytuje velmi obecný mechanismus pro aplikace typu klient-server. Balík RPC vyvinula firma Sun Microsystems a v podstatě se jedná o sbírku nástrojů a knihoven funkcí. Důležitou aplikací postavenou na balíku RPC je systém NFS, síťový souborový systém, a systém NIS, síťový informační systém. Oba tyto systémy budou probírány v následujících kapitolách.
Server RPC se skládá ze sady procedur, které si může klient volat tím způsobem, že pošle serveru požadavek RPC společně s parametry procedury. Server spustí jménem klienta požadovanou proceduru a existuje-li návratová hodnota, pošle ji zpět klientovi. Aby mohl být balík RPC nezávislý na typu hardwaru, jsou všechna data předávaná mezi klientem a serverem převedena vysílajícím počítačem do tzv. formátu externího vyjádření dat (External Data Representation - XDR) a přijímající počítač je převede zpět do místního vyjádření dat.
Někdy způsobí zdokonalení RPC aplikace nekompatibilní změny v rozhraní volání procedur.
Samozřejmě, že prostá výměna serveru může způsobit spadnutí všech aplikací, které stále očekávají původní chování. Proto mají programy RPC přiděleny číslo své verze, obvykle se začíná hodnotou 1 a při každé nové verzi rozhraní RPC je tato hodnota zVýšena. Server může často současně nabízet několik verzí RPC; v takovém případě označí klient ve svém požadavku číslo verze, kterou chce ve své implementaci dané služby používat. Vlastní síťová komunikace probíhající mezi servery RPC a jejich klienty je zvláštní. Server RPC nabízí jednu nebo více skupin procedur; každá množina procedur se nazývá program a je jednoznačně určena tzv. číslem programu. Seznam definující přiřazení názvů služeb k číslům programů je obvykle uložen v souboru /etc/rpc. Na obrázku 9.2 vidíte výpis z tohoto souboru.
#
# /etc/rpc - různé služby založené na RPC
#
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rstat_svc rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
ypasswss 100009 ypasswd
bootparam 100026
ypupdated 100028 ypupdate
Obrázek 9.2 Vzorový soubor /etc/rpc
U sítí na bázi protokolu TCP/IP čelili autoři balíku RPC problému, jak sdružit čísla programů s obecnými síťovými službami. Zvolili takovou variantu, kdy každý server poskytuje pro každý program a pro každou verzi programu jak port pro protokol TCP, tak i port pro protokol UDP. Obecně budou aplikace při posílání dat používat protokol UDP a protokol TCP budou používat pouze v případě, že se posílaná data nevejdou do jediného datagramu protokolu UDP.
Samozřejmě, že klienti musí mít možnost zjistit port, na který je namapováno dané číslo programu. V tomto případě by bylo použití konfiguračního souboru příliš nepružné; jelikož aplikace RPC nepoužívají vyhrazené porty, nemůžeme mít žádnou jistotu, že port původně určený pro použití naší databázovou aplikací nebude obsazen nějakým jiným procesem. Proto aplikace RPC vyberou některý z dostupných portů a zaregistrují ho pomocí démona, tzv. mapovače portů (portmapper deamon). Tento démon se chová jako zprostředkovatel mezi všemi servery RPC, které jsou spuštěny na daném počítači: klient, který chce kontaktovat službu s daným číslem programu, se nejdříve bude dotazovat mapovače portů umístěné na hostiteli serveru, ten mu pak vrátí čísla portů TCP a UDP, na kterých může být daná služba dosažitelná.
Tato metoda má konkrétní nevýhodu v tom, že zavádí princip jediného selhání, podobně jako to činí démon inetd u standardních služeb. Avšak tento případ je ještě horší, protože když selže démon mapující porty, ztratí se veškeré informace o portech RPC; to obvykle způsobí, že budete muset manuálně znovu nastartovat všechny servery RPC nebo budete muset znovu nastartovat celý počítač.
V Linuxu se program na mapování portů nazývá rpc.portmap a je umístěn v adresáři /usr/sbin. Kromě toho, že je třeba se ujistit, zda je démon mapující porty skutečně spouštěn ze souboru rc.inet2, není třeba žádná další konfigurace.
Ke spouštění příkazů na vzdálených hostitelích existuje spousta možností. Jsou to například příkazy rlogin, rsh, rcp a rcmd. Všechny tyto příkazy vyvolají na vzdáleném hostiteli příkazový interpret a umožní uživateli spouštět programy. Samozřejmě, že klient musí mít na hostiteli, na kterém hodlá spouštět příkazy, založený účet. Tedy všechny tyto příkazy provádějí ověření totožnosti. Klient obvykle sdělí serveru své přihlašovací uživatelské jméno a server okamžitě požádá o zadání hesla, které je ověřeno běžným způsobem.
Avšak u konkrétních uživatelů je někdy vhodné nevyžadovat ověření totožnosti. Když se například často přihlaýujete k ostatním počítačům v lokální síti LAN, měli byste být do ní vpuštěni, aniž byste museli pokaždé zadávat své heslo.
Vypnutí ověřování totožnosti je vhodné pouze u malého počtu hostitelů, jejichž databáze hesel jsou synchronizovány, nebo u malého počtu privilegovaných uživatelů, kteří musí z administrativních důvodů přistupovat k mnoha počítačům. Kdykoliv chcete lidem povolit přihlášení k vašemu hostiteli bez zadání přihlašovacího id nebo hesla, ujistěte se, že náhodně nepovolíte přístup někomu jinému.
Vypnutí ověřování totožnosti u příkazů z rodiny r lze provést dvěma způsoby. První z nich je určen pro superuživatele, a umožňuje povolit přihlašování několika nebo všech uživatelů na několik nebo všechny hostitele (později uvedené případy jsou velmi neššastné), aniž by byli dotazováni na heslo. Tento přístup řídí soubor, který se jmenuje /etc/hosts.equiv.
Soubor obsahuje seznam hostitelů a jmen uživatelů, kteří jsou považováni za rovnocenné s uživateli místního hostitele. Druhý způsob je pro uživatele, kteří povolí dalším uživatelům z určitých hostitelů přístup ke svému účtu. Tito uživatelé mohou být vypsáni v souboru .rhosts, který se nachází v domovském adresáři daného uživatele. Z bezpečnostních důvodů musí být tento soubor vlastněn uživatelem nebo superuživatelem a tento soubor nesmí být symbolickým odkazem, v opačném případě bude ignorován.
Když klient požádá o službu z rodiny r, vyhledá se nejprve jeho hostitel a jeho uživatelské jméno v souboru /etc/hosts.equiv a potom v souboru .rhosts uživatele, pod jehož účtem se chce daný uživatel přihlásit. Jako příklad předpokládejme, že uživatel janet pracuje na hostiteli gauss a pokouší se přihlásit k účtu uživatele joe na hostiteli euler. V následujícím výkladu budeme považovat uživatele Janet za uživatele klienta a uživatele Joe za místního uživatele. Nyní napíše uživatel Janet na hostiteli gauss příkaz:
$ rlogin -l joe euler
Server nejprve zkontroluje v souboru hosts.equiv, zda má být uživateli Janet povolen volný přístup, a pokud neuspěje, pokusí se tohoto uživatele vyhledat v souboru .rhosts, který se nachází v domovském adresáři uživatele joe.
Soubor hosts.equiv na hostiteli euler vypadá asi takto:
gauss
euler
-public
quark.physics.groucho.edu andres
Každý záznam se skládá z názvu hostitele, za nímž může volitelně následovat jméno uživatele. Jestliže se na řádce objeví pouze samotný název hostitele, bude všem uživatelům daného hostitele umožněn přístup ke svým místním účtům bez jakékoliv kontroly. Ve Výše uvedeném příkladu bude uživateli Janet povoleno přihlášení ke svému účtu s názvem janet, pokud se bude přihlašovat z hostitele gauss, a totéž bude platit i pro kteréhokoliv dalšího uživatele s výjimkou uživatele root. Pokud se ale bude chtít uživatel Janet přihlásit jako uživatel joe, bude obvyklým způsobem požádán o zadání hesla.
Je-li za názvem hostitele uvedeno jméno uživatele, jako je tomu na poslední řádce Výše uvedeného příkladu, bude tomuto uživateli umožněn přístup ke všem účtům kromě účtu root bez hesla.
Před názvem hostitele může být uveden symbol minus, viz položka "-publiciŮ. V tomto případě požadujeme, aby hostitel public ověřoval totožnost všech účtů, bez ohledu na to, jaká práva mají uživatelé přidělena ve svých souborech .rhosts.
Formát souboru .rhosts je identický s formátem souboru hosts.equiv, ale jeho význam je poněkud odlišný. Podívejte se na soubor .rhosts uživatele Joe na hostiteli euler:
chomp.cs.groucho.edu
gauss janet
První položka povolí uživateli joe volný přístup v případě, že se přihlaýuje z hostitele chomp.cs.groucho.edu. Tato položka neovlivní práva žádného dalšího účtu na hostiteli euler nebo chomp. Druhá položka je variací Výše uvedeného, která spočívá v tom, že uživateli janet bude povolen volný přístup k účtu uživatele Joe, pokud se přihlásí z hostitele gauss.
Pamatujte, že název hostitele klienta je získán pomocí reverzního mapování adresy volajícího hostitele na název hostitele, takže tento postup nebude fungovat u hostitelů, které resolver nezná. Název hostitele klienta odpovídá názvu uvedenému v souborech hosts, pokud je splněn jeden z následujících případů: