Linux, mint Internetes kiszolgáló

Átírás

1 1 Linux, mint Internetes kiszolgáló RÉSZLETES TEMATIKA 1. Linux alapok rövid áttekintése Alapok, kernel, shell, átirányítások, pipe-line-ok Parancsok, segédprogramok init scriptek fehasználók, csoportok jogosultság rendszer 2. Disztribúció választása, telepítése (debian lenny Linux rendszer telepítése, alapkonfigurációja Hálózat konfigurálása, hálózati scriptek Csomagkezelés (dselect, apt, dpkg), APT források 3. Internetes szolgáltatások alapjai Internetes alapfogalmak protokoll, port inetd szuperserver 4. DJB út, daemontools daemontools: bombabiztos megoldás a szolgáltások indítására, felügyeletére alprogramok: svscan, supervice, svc Naplózás a multilog segítségével 5. Domain név rendszer DNS alapok, hiteles választ adó és resolver funkciót megvalósító DNS djbdns (dnscache, tinydns, axfrdns) djbdns és a bind összehasonlítása 6. Apache Web szerver Telepítés csomagból, forráskódból, futtatás, tesztelés, napló állományok Virtuális Web szerverek Access Control (authentikáció) Script futtatási lehetıségek: PHP, Perl 7. PureFTP daemon Anonymous és teljes jogú felhasználók konfigurálása Védelem authentikáció Aktív és passzív mód 8. Mail szerver (MTA): qmail Levelezési alapok (MTA, MUA, MDA) SMTP, POP3, IMAP, WEBMAIL mőködése qmail elınyei, telepítése forráskódból virtuális domainek, mail-alias, forward Biztonság: SPAM szőrés, fekete - és szürkelista Egyéb funkciók: maildrop (MDA), fetchmail 9. Squid proxy szerver proxyzás elınyei cache terület kialakítása ACL-ek Naplózás, authentikáció

2 2 10. NAT, routing és firewall funkciók iptables (NAT) mőködési elve, elınyei Kernelszintő támogatás Többkártyás rendszer beállítás INPUt, OUTPUT és FORWARD szabályok Védelmi funkciók (firewall), támadási típusok Egyéb modulok betöltése 11. QoS, traffic control Forgalom korlátozás QoS segítségével Megvalósítás CBQ, HTB segítségével 12. Egyéb finomságok Cron daemon Adatmentési eszközök: tar, gzip, find,rsync, cpio 13. Ismétlés, számonkérés

3 3 Daemontools 1. Mi a daemontools, miért érdemes használni Daemontools UNIX operációs rendszer alatt mőködı szoftvergyőjtemény, mely daemonok elindítására, felügyeletére, naplózására alkalmas. A daemontools fontosabb részei svscan A hagyományos init programhoz hasonlóan folyamatokat figyel, hogy futnak-e. A /service könyvtárat és alkönyvtárait figyeli (pontosabban, hogy tartalmaznak-e run, down scripteket). Ezek a könyvtárak rendszerint egy szolgáltatást írnak le, pl. úgy, hogy az /etc könyvtárból szimbólikus linkeket készítünk, és elhelyezünk benne run/down scripteket. Az svscan egy supervise folyamatot indít minden olyan könyvtárra és alkönyvtárra, ahol run scripteket talál. svscan opcionálisan párban lévı folyamatokat is indíthat, könyvtárra és az ez alatt lévı /log könyvtárra. Minden 5 másodpercben, az svscan ellenırzést végez újra a /service könyvtáraira és alkönyvtáraira. Ha új alkönyvtárat talál, elindít egy új supervise processzt. Ha egy érzékeli, hogy egy létezı könvytárban lévı supervise folyamat megállt, akkor azt újra elindítja. supervise (supervise dir) Ez végzi ténylegesen a szolgáltatás indítását. Pontosabban a paraméterként kapott könyvtárba lép, és ott elindítja a./run scriptet. svc ( svc -opcio service ) Interaktív felhasználói interfész, mellyel az svscan mőködését tudjuk befolyásolni. -u : Up. Ha a szerviz nem fut, elindítja. Ha megállt, újraindítja. -d : Down. Ha fut a szerviz, TERM signal küld neki, ami leállítja. Ha már állt, nem indítja el. -o : Once. Ha a szerviz nem fut, elindítja. Ha megállt, nem indítja újra. -p : Pause. STOP signalt küld a szerviznek -c : Continue. CONT signalt küld a szerviznek -h : Hangup. HUP signalt küld a szerviznek -a : Alarm. ALRM signalt küld a szerviznek. -i : Interrupt. INT signalt küld a szerviznek -t : Terminate. TERM signalt küld a szerviznek -k : Kill. KILL signalt küld a szerviznek -x : Exit. supervise kilép, miután a szerviz megállt. Ha stabli rendszeren csak akkor használd ezt, ha véglegsen meg akarsz szőntetni egy szervizt, supervise az örökké tartó futásra tervezték. Példa: svc -u /service/qmail-smtp: -u paraméterrel használva elindítja a daemont (start) svc -d /service/qmail-smtp: -d leállítja a daemont (stop) svc -t /service/qmail-smtpd: -t újraindítja a daemont (restart) svstat (svstat /service) Az svstat információkat ad a paraméterben megadott szervizrıl, melyeket a supervise felügyel. Példa: # svstat /service/qmail-* /service/qmail-pop3d: up (pid 1681) seconds /service/qmail-send: up (pid 1685) seconds /service/qmail-smtpd: up (pid 31010) seconds /service/qmail-smtps: up (pid 1683) seconds multilog naplózó rendszer Adatokat olvas a stdin-rıl, opcionálisan szőri ıket és az eredményt egy vagy több naplófile-ba teszi, automatikus rotálásukról is gondoskodik. A multiloggal alapvetı naplófunkciókat meg tudunk valósítani: 1. Idıbélyeg (timestamp) Példa: # /usr/local/bin/multilog t /var/log/qmail/qmail-send A t paraméter jelzi a multilognak, hogy minden naplósor elı tegyen egy tai64n formátumú idıbélyeget. A multilog aktuális naplóját current néven látjuk. # tail -1 starting delivery : msg to remote akarki@gmail.com

4 4 A tai64n formátumú idıbélyeg a tai64local programmal vissza tudjuk alakítani # tail -1 /var/log/qmail/qmail-send/current tail64nlocal :23: starting delivery : msg to remote akarki@gmail.com Rotálás s size: automatikus rotálás, ha a fájl mérete nagyobb, mint a size-ban megadott (default 100KB) n num: rotálás n darab fájl megtartásával Példa: # /usr/local/bin/multilog t s n40 /var/log/qmail/qmail-send 5MB mérető naplófájloknál rotál, 40 db-ot tart meg. Mintaillesztés A multilog képes arra, hogy adott mintára illeszkedı sorokat másik fájlba teszi. Példa: a "simscan" sorokat egy külön fájlban is tárolja /usr/local/bin/multilog t s n40 /var/log/qmail/qmail-smtpd '-*' '+* simscan:*' /var/log/qmail/simscan 2. Összehasonlítás UNIX rendszerek alatt daemonok elindítása, leállítására többféle lehetıségünk van. inittab init.d rc.local /service Rugalmas szerviz install-eltávolítás A szerviz könnyő elsı indítása Megbízható újraindítás Könnyő, megbízható jelzés Tiszta folyamat állapotfigyelés Portolhatóság Hasonlítsuk össze a /service és az init.d (Debian alatt használt) funkciót! Rugalmas szerviz install-eltávolítás 1. /service: Létrehozzuk a megfelelı run scriptet, majd # ln -s /etc/qmail /service/ 2. init.d: Létrehozzuk a megfelelı init scriptet, majd az /etc/init.d/ könyvtárba másoljuk, majd # update-rc.d qmail defaults 30 # update-rc.d qmail -f remove A szerviz könnyő elsı indítása 1. /service: automatikus 2. init.d: # /etc/init.d/qmail start Megbízható újraindítás 1. /service: automatikus, mivel a supervise program figyeli a daemonokat, megállásuk esetén újraindítja ıket 2. init.d: NINCS RÁ MEGFELELİ FUNKCIÓ Könnyő, megbízható jelzés 1. /service: automatikus, az svc program minden funkciót támogat # svc -h /service/yourdaemon: HUP jelet küld # svc -t /service/yourdaemon: TERM jelzést küld, és automatikusan újraindítja a daemont # svc -d /service/yourdaemon: TERM jelzést küld, a daemont leállítja # svc -u /service/yourdaemon: elindítja a daemont 2. init.d Saját init scriptek kell írni, azokat megfelelıen paraméterezni (start, stop, restart, status, stb.). Tiszta folyamat, állapotfigyelés 1. /service:

5 5 Egy szerviz újraindítás után ugyanolyan állapotban indul el (pl. változók), mint bootoláskor. 2. init.d Plusz munkát igényel a változók visszaállítása, erıforrások beállítása, stb. Portolhatóság 1. /service: Mőködik minden UNIX platform alatt: Linux, BSD, UNIX 2. init.d: Az init scriptek megírásakor figyelni kell az operációs rendszer parancsait, változót. Pl. Debian: startstop-daemon, SuSE: startproc/killproc 3. Telepítés A daemontools a szabványos UNIX könyvtárstruktúrát kibıvíti, a gyökér alatt létrehozza a következı bejegyzéseket: /service /command /package (ezt nekünk kell létrehozni, az alábbi parancsokkal megtehetı) mkdir -p /package chmod 1755 /package Töltsük le a daemontools-0.76.tar.gz csomagot a /package könyvtárba, csomagoljuk ki: # cd /package # wget # tar -xvzf daemontools-0.76.tar # cd /package/admin **** FONTOS! Bizonyos libc6 verziós felett (Debian sarge, etct, lenny) szükséges az alapcsomaghoz egy javítás (patch), neve daemontools-0.76.errno.patch # wget # cd admin/daemontools-0.76 # patch -p1 <../daemontools-0.76.errno.patch Fordítsuk le, és Linux rendszerünkön ezután automatikusan elindul: # package/install Linking./src/* into./compile... Creating /service... Adding svscanboot to inittab... init should start svscan now. A fenti parancs a C forrást lefordítja, elkészíti a binárisokat. Létrehozza a / gyökér alatt a /command alkönyvtárat, s ide bemásolja a daemontools programokat (létrehozza továbbá az ezekhez tartozó szimbólikus linkeket a /usr/local/bin könyvtárba, a PATH útvonal alá is). FONTOS! A daemontools boot idejő rendszerfelügyelıje az svscanboot, amit az init indít el rendszerinduláskor (pontosabban minden futási szinten). Az /etc/inittab fájlba tesz egy sort, ami szerint az svscanboot "respawn" módban indul el, azaz az init újraindítja, ha megállna. SV:123456:respawn:/command/svscanboot Linux rendszereken azonnal elindul az svscan, BSD-ket - állítólag - újra kell indítani. ]# ps -auxw grep service root ? S 09:51 0:00 svscan /service root ? S 09:51 0:00 readproctitle service errors: Konfigurálás Hogyan tudunk egy szolgáltatást elindítani?

6 6 A példa szolgáltatás legyen a víruskeresı clamav daemona. A clamav alapkönyvtára /etc/clamav, hozzunk létre alatta egy service könyvtárat! # mkdir /etc/clamav/service Hozzunk létre egy run scriptet a fenti könyvtár alatt, tartalma: #!/bin/sh PATH="/usr/bin:/bin" exec /usr/local/sbin/clamd 2>&1 A daemontools egy futtatható run nevő scriptet keres majd a /service könyvtár alatt, ezért csináljunk szimbólikus linket a /service alá. # ln -s /etc/clamav/service /service/clamav

7 7 DNS elv és megvalósítás 1. A DNS mőködése 2. djbdns(d.j. Bernstein DNS szervere, ı a qmail szerzıje is) 3. bind (Berkeley Internet Name Daemon) Ajánlott alternatíva: djbdns A djbdns elınyei: a DNS funkciók (cache, hiteles választ adó, AXFR) jól elkülönülnek minden funkció alacsony jogú felhasználó nevében fut, chroot-olt környezetben daemontools használva a daemonok monitorozhatók stabil, nincsenek lyukak, hibák elsıdleges-másodlogos névszerverek zónái biztonságosan szinkronizálhatók (scp, rsync ssh felett) SQL, LDAP adatbázisból szintén lehet zónafile-t generálni Aki megbízható, stabil DNS szolgáltatást szeretne, a djbdns-t válassza. A DNS mőködési elve A DNS mőködésével kapcsolatban csak a legfontosabb gondolatokat írom le. Minden részletre kiterjedı, alapos dokumentációt Pásztor Miklóstól ( MTA SZTAKI/ASZI ) olvashatunk, cime: Az internet DNS, elv és konfiguráció Pásztor Miklós MTA SZTAKI/ASZI pasztor@sztaki.hu Alapfogalmak DNS (Domain Name Service) az Internet mőködéseben alapvetı, nélküle megbénulna az Internetes kommunikáció. A DNS egy osztott, hierarchikus adatbázis : az adatbázist jelenleg név szerverek százezrei szolgáltatják ki. A DNS rendszer legfontosabb feladata a név - IP cím feloldás, illetve ennek fordítottja is: IP cím - név feloldás. Az internet nevek fordított fa szerint szervezıdı hierarchiát alkotnak: A fa fordított, mert a gyökér a hierarchia legmagasabb foka. A nevek feloldása a gyökértıl kezdıdik, és fokról fokra halad elıre. A név-fa különbözı elágazási pontjaiért és ágaiért különbözı szerverek felelısek. Egy-egy szerver több ágért is felelıs lehet. A név-fa egy egy pontját domain - nak, domain névnek vagy egyszerően név- nek nevezzük. A hierarchia csúcsát 'root'-nak, gyökérnek nevezzük. Az ez alatti neveket top level domain -oknak, TLD-knek mondjuk. Amikor

8 8 az internet még csak USA hálózat volt, a következı TLD-k voltak használatosak: edu - amerikai egyetemek, oktatási intézmények com - vállalatok mil - katonai szervezetek gov - kormányhivatalok net - hálózati szervezetek org - mindenféle más szervezet arpa - az internet ısében, az Arpanetben levı gépek neveire szolglált kezdetben. Az inverz nevek feloldásánál (ld. késıbb) mind a mai napig fontos szerpe van. Az USA-n kívüli domain-ok számára az ISO 3166 szabványban meghatározott kétkarakteres országkódot kezdték használni. Példák: be - Belgium pl - Lengyelország hu - Magyarország Zónák A név-fa zónákra oszlik: egy-egy zóna a fa egyben kezelt része. Sokszor egybeesik egy aldomainnel. Például egy zóna lehet az osztaly.intezet.hu és minden név, ami a hiararchiában ez alatt van. Egy zóna például az összes TLD-t tartalmazó root zóna is. Az elsıdleges szerveren az adatok a zóna adminisztrátor munkájának eredményeképpen ténylegesen változnak. A másodlagos szerver(ek) a zóna adatait meghatározott rend szerint az elsıdleges szervertıl tükrözi(k). A tükrözés rendjét az elsıdleges szerveren a rendszeradminisztrátor a zóna konfigurációjával határozza meg. Delegálás A hierarchia egyes darabjait a zóna adminisztrátora tovább delegálhatja más szerverekre. Például az intezet.hu domain gazdája az osztaly.intezet.hu aldomain láttatását, autoritását az illetı osztály egy meghatározott gépére bízhatja a konfigurációban: mindenki felelıs és úr lehet a saját illetékességi körében (szubszidiaritás elve). A root zóna sıt még a TLD-k (edu, gov, hu stb.) is jóformán mást sem tartalmaznak mint ilyen delegálást. Így jön létre a hierarchikus, osztott adatbázis. A delegálás azonban nem feltétele a több szintő név megadásának. Például lehetséges, hogy az osztaly.intezet.hu nincs delegálva, nem különálló zóna, mégis létezik a gep.osztaly.intezet.hu domain, mert az intezet.hu zóna gazdája bevezette a pontot (.) tartalmazó gep.osztaly nevet. Ezt éppen úgy megteheti, mint a gep-osztaly vagy az osztalygepe nevek bevezetését, melyeknek hatása a gep-osztaly.intezet.hu, illetve az osztalygepe.intezet.hu nevek létrejötte. A domain neveknek ezt a teljes alakját, ami a nevet a gyökér domain-ig tartalmazza FQDN -nek (Fully Qualified Domain Name). Cím -> név hozzárendelés, reverse névfeloldás Az interneten nem csak arra van szükség, hogy nevekbıl IP címeket nyerjünk, hanem arra is, hogy IP címekbıl domain neveket. Ez a szolgáltatás - amit inverz, vagy reverz feloldásnak neveznek -, a hálózati biztonság szempontjainak erısödése miatt egyre nagyobb jelentıségő. Például sok FTP vagy levelezı szerver nem fogad el kéréseket csak olyan gépekrıl, amiknek címébıl a hozzájuk tartozó domain nevet ki lehet deríteni. Vannak szolgáltatások, amik csak bizonyos domain-okból érhetık el. A cím-név feloldás érdekében bevezették az in-addr.arpa domaint. IP címeket általában úgynevezett pontozott decimális (dotted decimal) alakban szokás megadni, ilyesformán: Az ehhez a címhez tartozó nevet úgy kapjuk meg, hogy a domain rendszertıl megkérdezzük a in-addr.arpa névhez tartozó rekordot. Az in-addr.arpa domainban éppen úgy delegálják az egyes aldomain-eket mint minden más zónában. Névszerverek funkció szerint resolver (Caching only szerverek, dnscache): csak arra szolgál, hogy feloldja a neveket a kliensek számára, delegált zónákat nem tartalmaz hiteles választ adó szerverek ( láttató, autoritatív szerverek): az adott domain nevekrıl (zónákról) ık adnak hiteles információkat A domain név-fa egy egyben delegált ágát, melyért egy szerver felelıs, zónának nevezzük. Egy zónáért felelıs névszerverek közt van egy kitüntetett, amelyen az adminisztátor a konfigurációt változtatja. Az (esetleges) többi ezt a zónát tükrözi. A kitüntetett szerverre elterjedt kifejezés az 'elsıdleges', 'primary' a tükrözı szerverekre pedig a 'másodlagos', 'secondary'. Újabban (elsısorban a 8. változatú BIND megjelenésének hatására) inkább a master és a slave neveket használják. A master és slave név azért szerencsésebb, mert nem keveredik a rezolver konfigurációknál megadható 'primary'/'secondary' szerverekkel. Egy szerver lehet egy zónára 'master' egy másikra 'slave'. Valójában gyakori is, hogy két intézmény kölcsönösen 'slave' autiritatív szerver a egymás zónáira. A névfeloldás szempontjából a 'master' és a 'slave' szerverek között semmi különbség nincsen: egyformán autoritatív mindegyik. A névszerverek a név feloldás során bármelyikhez

9 9 fordulhatnak. A valóságban a kód úgy mőködik, hogy a szerverek egy-egy zóna autoritatív szerverei közül igyekeznek azt kérdezni, amelyik gyorsabban válaszol, aminek érdekében egy ravasz algoritmust használnak: kezdetben mindegyik névszervert megkérdezik, mérik a válaszidıt, aztán azt preferálják, ami gyorsabban válaszolt, de a lassabb szerverek idıvel újra szót kaphatnak, mert minden kérdésnél 'csökken a büntetésük'. DNS zónában szereplı rekordok SOA - Start of Authority rekord, zóna kezdı rekord NS - Name Server, névszerver rekord A - Address, cím rekord CNAME - Canonical Name, kanonikus név rekord MX - Mail exchanger, levelezı szerver rekord TXT - Text, szöveges rekord HINFO - Hardware information, hardver információ rekord PTR - Pointer rekord Zóna fájl példák: tinydns zónafájl +linuxweb.hu: :7200 +mail.linuxweb.hu: : ftp.linuxweb.hu: :7200 BIND típpusú zónafájl $ORIGIN linuxweb.hu $TTL IN SOA ns1.linuxweb.hu. postmaster.wenetto.hu. ( ; serial ; refresh after 12 hours ; retry after 4 hour ; expire after 1 week ) ; minimum TTL of 1 day NS A NS A MX 10 mail mail A www A ftp A

10 10 DNS alternatívák 1: djbdns A djbdns szerzıje Daniel J. Bernstein (DJB), ı a programozója az egyik legnagyszerőbb MTA-nak is, a qmail-nak. A djbdns implementációban DNS funkciók (cache, hiteles választ adó, AXFR) jól elkülönülnek: A djbdns részei: dnscache: resolver funkciójú tinydns: hiteles választ adó névszerver axfrdns: zónatransfert megvalósító (és az 512 byte-nál nagyobb TCP válaszokat is ad) rbldns: speciális DNS szerver, melyhez elsısorban levelezı szerverek fordulnak. Ha az általuk kért IP cím szerepel az rbldns-ben, azt az IP-t blokkolják További fontos csomagok (a qmail-hez is kellenek majd) daemontools: segédprogramok győjteménye a daemonok menedzselésére (svscan, svc, supervise, multilog) ucspi-tcp: UNIX Client-Server program TCP alkalmazásokhoz (tcpserver, tcpclient, tcprules) 1. Névfeloldási alapelvek A DNS kéréseknek alapvetıen 2 fajtája van: Az elsı típusban az ún. RD (rekurzió szükséges) bit jelenik meg: rekurzív kérésnek is nevezhetjük. Rendszerint alkamazások generálnak ilyen jellegő kéréseket, pl. web böngészık a begépelt domain név feloldása céljából. A megszólított szerver a kliens operációs rendszerben megadott névfeloldó szerver (UNIX alatt az /etc/resolv.conf-ban szereplı névszerverek). A rekurzív kérésre 2 válasz adható: a keresett névhez tartozó IP cím vagy hiba, miszerint nem oldható fel a kérés. A rekurzív névfeloldó DNS szervereket dnscache-ként említhetjük. A második típus az ún. iteratív (ismételt) kérés. Tipukusan rekurzív névfeloldótól származnak ilyen kérések, a célszervertıl végleges (hiteles) választ várnak vagy annak a szervernek a címét, ami vélhetıleg ismeri a válaszadó szervert. A hiteles választ adó DNS szerverek tehát domain zónakat tartalmaznak. 2. djbdns alapelvek A rekurzív és iteratív kéréseket szét kell választanunk, a resolver funkciójú dnscache-t és a hiteles választ adó tinydns-t külön IP címen futtassuk ( akár külön hoston). IP cím szolgáltatás dnscache (53 UDP) tinydns(53 UDP) axfrdns(53 TCP) A fentiekbıl következik, hogy ugyanaz az IP címő DNS szerver NE szerepeljen delegációs (NS) rekordban és az /etc/resolv.conf-ban megadott rekurzív kérések kiszolgálójaként. 3. Általános telepítés Szükséges alapcsomagok installációja: daemontools-0.76 # cd /package # wget # tar -xvzf daemontools-0.76.tar # cd /package/admin **** FONTOS! Bizonyos libc6 verziós felett (Debian sarge, etch, lenny) szükséges az alapcsomaghoz egy javítás (patch), neve daemontools-0.76.errno.patch # wget

11 11 # cd admin/daemontools-0.76 # patch -p1 <../daemontools-0.76.errno.patch # package/install Linking./src/* into./compile... Creating /service... Adding svscanboot to inittab... init should start svscan now. djbdns-1.05 Igazából én nem szeretem, ha a programforrások nem a /usr/src alatt vannak, ezért a daemontools kivételével a többi DJB terméket már a /usr/src alá szoktam tenni. # cd /usr/src # wget # tar -xfvz djbdns-1.05.tar.gz **** FONTOS! Bizonyos libc6 verziós felett (Debian sarge, etch, lenny) szükséges az alapcsomaghoz egy javítás (patch), neve djbdns-1.05.errno.patch # wget # cd djbdns-1.05 # patch -p1 <../djbdns-1.05.errno.patch Jöhet a fordítás, telepítés # make setup check ucspi-tcp-0.88 Ez a djbdns-hez igazából nem kell, de qmail-hez igen. # cd /usr/src # wget # tar -xfvz ucspi-tcp-0.88.tar.gz **** FONTOS! Bizonyos libc6 verziós felett (Debian sarge, etch, lenny) szükséges az alapcsomaghoz egy javítás (patch), neve ucspi-tcp-0.88.errno.patch # wget # cd ucspi-tcp-0.88 # patch -p1 <../ucspi-tcp-0.88.errno.patch Jöhet a fordítás, telepítés # make setup check 4. dnscache beállítása Amennyiben saját hálózatunk névfeloldási kéréseit szeretnénk kezelni, beállíthatjuk az ISP névfeloldó szervereit vagy saját dnscache-t illetve használhatjuk mindkettıt (az ISP névszervere FORWARDER funkcióval). Konfigurálás: Hozzunk létre egy "dnslog" és egy "dnscache" felhasználót # adduser --system --no-create-home dnslog # adduser --system --no-create-home dnscache Konfiguráljuk a dnscache-t, hogy a privát IP címen fusson # dnscache-conf dnscache dnslog /etc/dnscache Ez létrehozza az /etc/dnscache könyvtárat, mely tartalmazza a napló- és kofigurációs állományokat Engedélyezzük a cache funkciók használtát a belsı hálózat privát címtartományára # touch /etc/dnscache/root/ip/

12 12 Ezzel a cache a /24 címtartományból érkezó kéréseket fogja csak kiszolgálni, a többit eldobja. Hozzunk létre több IP címet/tartományt leíró file-t a root/ip könyvtárba, amennyiben szükséges. A naplófile-ok alapételmezett helye így az /etc/dnscache/ könyvtár alá kerül. Mivel nem célszerő a konfig file-okon kívül mást az /etc alatt tartani, ezért hozzunk létre külön könyvtárat a log file-ok számára. # mkdir /var/log/dnscache # chown dnslog /var/log/dnscache Nyissuk meg kedvenc szövegszerkesztınkkel az /etc/dnscache/log/run filet. Cseréljük ki a./main részt /var/log/dnscache-re. dnscache elindítása a daemontools segítégével # ln -s /etc/dnscache /service/ 5 másodpercen belül elindul a dnscache Most már beállíthatjuk a kliens gépeken a névfeloldó szerverünket, Finomítások: A dnscache alapértelmezésben minden név visszakeresést a root DNS szerverekhez történı kéréssel kezd. Ezek az /etc/dnscache/root/servers/@ könyvtárban vannak: Célszerő fájlban felsorolt root DNS szerverek listáját ellenırízni, mert a djbdns megírása óta volt 1-2 változás. Az alábbi lista 2009 év elején aktuális. # cat /etc/dnscache/root/servers/@ Ezeket véletlenszerően kérdezgeti le a dnscache-ünk. Hogyan tudjuk az ISP-nk DNS szervereit ( ) ún. FORWARDERS-ként használni? Irjuk a cat /etc/dnscache/root/servers/@ file-ba a kívánt névszerver(k) IP címeit, felülírva az alapértelmezett root szervereket. # echo > /etc/dnscache/root/servers/@ Aztán állítsuk be a FORWARDONLY változót, majd indítsuk újra a dnscache-t! # echo 1 > /etc/dnscache/env/forwardonly # svc -t /service/dnscache Persze ezt nem minden esetben javaslom. Célszerő akkor pl., használni, ha a dnscache nem rendelkezik Internet kapcsolattal és csak a forward DNS-t látja. A dnscache alapértlemezésben 1 MB RAM-ot használ. Állítsuk ezt 10 MB-ra! # echo > /service/dnscache/env/cachesize # svc -t /service/dnscache 4. tinydns beállítása Egy adott zóna alapvetıen néhány fontos rekorddal írható le: SOA: zóna kezdı rekord NS: delegációs rekord, a domain névszervereit határozza meg, melyek a zónát kiszolgálják

13 13 A: host rekord, IP címet ad vissza a host névhez PTR: pointer (mutató) rekord, általában reverse (fordított) kérésekre használják, IP címbıl hostnevet ad vissza MX: Mail exchanger rekord, az ISZT kötelezıvé tette használatát minden domain esetén A domain leveleit kezelı szerver címét (nevét) adja vissza Miért van szükségünk tinydns szerverre? A tinydns hiteles válaszokat adó névszerver. Sokan azt hiszik, erre csak az ISP-knek van szükségük (zónák delegálása pl. a.hu zóna alá), de ez tévedés! Gondoljunk csak a belsı (privát) hálózatunkon mőködı gépek hadára. Amennyiben saját (mail, FTP, WWW, ssh, stb. ) szervereinket használjuk, azok fordított névfeloldást végezhetnek annak kiderítésére, hogy honnan jött a kérés. Ha nincs érdembeli válasz, akkor a szerver vagy nagyon lassan válaszol vagy esetleg a kérést is visszadobja. Szóval a belsı privát hálóra illik egy zónát és egy reverse (in-addr.arpa) zónát csinálni! Konfigurálás: Hozzunk létre egy "dnslog" és egy "tinydns" felhasználót # adduser --system --no-create-home dnslog # adduser --system --no-create-home tinydns Konfiguráljuk a tinydns-t, hogy az IP címen fusson, más IP-n kell fusson, mint a dnscache # tinydns-conf tinydns dnslog /etc/tinydnsc Ez létrehozza az /etc/tinydns könyvtárat, mely tartalmazza a napló- és kofigurációs állományokat A naplófile-ok alapételmezett helye így az /etc/tinydns/ könyvtár alá kerül. Mivel nem célszerő a konfig file-okon kívül mást az /etc alatt tartani, ezért hozzunk létre külön könyvtárat a log file-ok számára. # mkdir /var/log/tinydns # chown dnslog /var/log/tinydns Nyissuk meg kedvenc szövegszerkesztınkkel az /etc/tinydns/log/run filet. Cseréljük ki a./main részt /var/log/tinydns-re. tinydns elindítása a daemontools segítégével # ln -s /etc/tinydns /service/ 5 másodpercen belül elindul a tinydns Zónafile-ok készítése 1. megoldás: szövegszerkeztıvel editáljuk az /etc/tinydns/root/data állományt #zóna delegálás (NS rekord): ponttal kezdıdik, vagy Z-vel.teszt.hu: :a: in-addr.arpa: :a: #host rekord (A): egyenlıségjel =server.teszt.hu: :86400 =pc1.teszt.hu: :86400 =pc2.teszt.hu: :86400 =pc3.teszt.hu: :86400 #alias rekord (CNAME): plusz jel + +w1.teszt.hu: : w2.teszt.hu: : w3.teszt.hu: :86400 # PTR rekord: ^ jel ^ in-addr.arpa:pc1.teszt.hu.: ^ in-addr.arpa:pc2.teszt.hu.: ^ in-addr.arpa:pc3.teszt.hu.: # MX

14 14 2. megoldás: tinydns-data segédprogram használata A segédprogramok az /etc/tinydns/root könyvtárban találhatók # cd /etc/tinydns/root teszt.hu domain delegálása (ns rekord) # sh add-ns teszt.hu /24 IP tartomány reserve DNS delegálása # sh add-ns in-addr.arpa server.teszt.hu A rekordjának elkészítése # sh add-host server.teszt.hu További A rekordok: # sh add-host pc1.teszt.hu ; # sh add-host pc2.teszt.hu ; # sh add-host pc3.teszt.hu Alias (CNAME) rekord: # sh add-alias Levelezı (MX) rekord: # sh add-mx teszt.hu A tinydns szövegfile-ból egy hash-elt adatbázist hoz létre, ahonnan gyorsan visszakeresi a kért információt: data -> data.cdb # cd /etc/tinydns/data; make 5. Gyakorlati példa: tinydns és dnscache összehangolása Adott a Linux szerverünk, privát belsı hálózati címmel rendelkezik ( ), PPP (dinamikus IP) kapcsolattal az Internet felé. Meg kell oldanunk a névfeloldást az Internetes és belsı privát címek felé! Állítsunk be egy dnscache-t a IP címen # dnscache-conf dnscache dnslog /etc/dnscache Engedélyezzük a dns kéréseket a /24 belsı hálózatra # touch /etc/dnscache/root/ip/ Állítsunk be egy tinydns-t a (loopback) címen # tinydns-conf tinydns dnslog /etc/tinydnsc Készítsünk egy DNS zónát (intranet.hu) privát IP tartományra neveihez #sh add-ns teszt.hu Készítsünk egy reserve DNS zónát a /24 privát IP tartományra #sh add-ns in-addr.arpa Mondjuk meg a dnscache-nek, hogy ha az "intranet.hu" vagy " in-addr.arpa" zónákra jön kérés, akkor a helyi tinydns-hez forduljon. # echo > /etc/dnscache/root/servers/intranet.hu # echo > /etc/dnscache/root/servers/ in-addr.arpa Ellenırízzük # dnsip pc2.intranet.hu # dnsname Segédprogramok nslookup: Debian alatt már nem használatos (deprecated) host, dig parancsok DJB parancsok: 1. dnsip domain_name: visszadja a paraméterben megadott domain név IP címét # dnsip dnsname IP_cím: reverse DNS feloldást végez # dnsname

15 15 web.linuxweb.hu 3. dnsqr tipus domain: rekurzív DNS kérést végez az adott domainre, a DNS resolvert kérdezi # dnsqr ns linuxweb.hu 2 linuxweb.hu: 64 bytes, records, response, noerror query: 2 linuxweb.hu answer: linuxweb.hu NS a.ns.linuxweb.hu answer: linuxweb.hu NS b.ns.linuxweb.hu 4. dnsq tipus domain szerver: rekurzív DNS kérést végez az adott domainre, a paraméterben megadott hiteles szervert kérdezi # dnsq ns linuxweb.hu linuxweb.hu: 96 bytes, records, response, authoritative, noerror query: 2 linuxweb.hu answer: linuxweb.hu NS a.ns.linuxweb.hu answer: linuxweb.hu NS b.ns.linuxweb.hu additional: a.ns.linuxweb.hu A additional: b.ns.linuxweb.hu A dsmx domain: a domain MX rekordját adja vissza # dnsmx linuxweb.hu 0 a.mx.linuxweb.hu

16 16 Apache HTTP szerver Történet Eredete: " a patchy server " -> toldozott szerver, NCSA Web szerver fejlesztésébıl származik. Szabad forráskódú Tények: ma az Interneten futó Webszerverek többségén Apache fut. Elınyök Szabad forráskódú Kicsi erıforrásigényő Sokoldalúan konfiguráható Dinamikusan és statikusan betölthetı modulok Scripting nyelvek maximalis támogatása : Perl, CGI, PHP, Fast-CGI, Python Virtuális webszerverek Windows és Novell Netware platformra is van már Apache Telepítés Verziók 1.3 verzió: régóta mőködı, stabil 2.2 verzió: ezt is már több éve fejlesztik, sok új funkciót vezettek be Telepítés csomagból, apt segítségével történik. Debian etch alatt csomagból a 2.2 verziót használom # apt-get install apache2 Konfiguráció 1. Alapok A konfigurációs fájlok /etc/apache2 könyvtárban a debian alatt: apache2.conf: a legföbb beállításokat tartalmazza, régebbi verzióknál használatos fı konfig fájlként a httpd.conf is srm.conf, access.conf: könyvtárak, fájlok elérésével kapcsolatos jogokat tartalmazza. Ma már nem használatos Modulokkal kapcsolatos könyvrárak: mods-available: az összes elérhetı, telepített modult tartalmazza mods-enabled: az aktív modulokat tartalmazza, szimbólikus linkek a mods-available könyvtárból

17 17 Virtuális webszerverekkel kapcsolatos könyvtárak sites-available: az összes virtuális webszervert bejegyzés tartalmazza sites-enabled: az aktív virtuális webszervereket tartalmazza, szimbólikus linkek a mods-available könyvtárból SSL protokollal kapcsolatos könyvtárak ssl.crt ssl.key Az apache központi daemonja a "apache2" nevő daemon, (vagy httpd). # ps ax grep apache ? Ss 0:05 /usr/sbin/apache2 -k start 21668? S 0:00 /usr/sbin/apache2 -k start 21669? S 0:00 /usr/sbin/apache2 -k start 21670? S 0:00 /usr/sbin/apache2 -k start 21671? S 0:00 /usr/sbin/apache2 -k start 21672? S 0:00 /usr/sbin/apache2 -k start 25764? S 0:00 /usr/sbin/apache2 -k start 26023? S 0:00 /usr/sbin/apache2 -k start 26048? S 0:00 /usr/sbin/apache2 -k start 27507? S 0:00 /usr/sbin/apache2 -k start 30408? S 0:00 /usr/sbin/apache2 -k start Önálló daemonként futtatandó, az init scriptje /etc/init.d/apache2 Az apache konfigurációs file-ja: /etc/apache/apache2.conf. Nézzük ennek a lényegesebb opcióit! # 1.rész - ServerRoot "/etc/apache2" Könyvtárnév, mely alatt a server az alapértelmezett konfigurációs, hiba, és naplóállományokat tartja. Ha a konfig file-ban késıbb relatív elérési utat adunk meg, az mindig a ServerRoot-hoz képest értendı - Timeout 300 Idıtúllépés: ennyi másodperc után küld illetve kap idıtúllépést a webszerver - KeepAlive On Off Az ún. "életbantartás" engedélyezése, így kliens egy szerverkapcsolattal több dokumentumot is le tud kérni, nem kell újra felépíteni a TCP kapcsolatot. - MaxKeepAliveRequests 100 # MaxKeepAliveRequests: The maximum számú kérés, amit a szerver egy felépített, állandó kapcsolattal kezelhet # 0 korlátlamn ilyen kapcsolatot engedélyez - KeepAliveTimeout 15 # KeepAliveTimeout: Másodpercben mérve az az idı, ami a kliens felé felépült kapcsolat idıtúllépése - MPM: Multi-Processing Module: prefork illetve worker. Tesztek szerint többprocesszoros gépeken a worker jobb teljesítményt ad, viszont bizonyos modulok (PHP5) nem mőködnek vele. <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 </IfModule> <IfModule mpm_worker_module> StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule> - StartServers 5 (integer) Az Apache induláskor ennyi httpd daemont tölt be a memóriába - MinSpareServers, MaxSpareServers 5/10 (integer) A minimálisan és maximálisan tartalékolt daemonok számat lehet értékhatárok között tartani

18 18 - MaxClients 150 (integer) A szerverhez egy idıben kapcsolódó kliensek maximális száma, mely megvédi a rendszert attól, hogy túl sok egyidejő kérés "térdre kényszerítse". # 2. rész - Port 80 A kommunikációs port, amelyen a werbszerver a kliensekkel kommunikál Ezt apache2 esetén már külön fájlban adják meg, aminek neve ports.conf # cat /etc/apache2/ports.conf Listen 80 Listen User www-data Ennek a felhasznalónak a nevében fut az Apache, (s nyilván a szerver oldalon futó scriptek is!). A Unix rendszerben mindenképpen léteznie kell, s ne legyen túl "nagy" jogú felhasználó - Group www-data - ServerAdmin webadmin@linuxweb.hu.hu ( cím) Erre az -re küldi az Apache a rendszerszintő üzeneteket - DocumentRoot "/var/www" Az alapértelmezett html lapok könyvára. - DirectoryIndex index.html index.htm index.php (indító file, vagy file-ok) Az a html állomány, amelyet a webszerver visszaad a browser-nek, ha egy adott könyvtárra érkezik kérés. - UserDir public_html (könyvtárnév) A felhasználók home könyvtárának az az alkönyvtára, ahol publikus html lapokat tartja. Elérhetıség: Ekkor a /home/nszabo/public_html-bıl adja vissza az Apache az alapértelmezett html állományt. - AccesFileName.htaccess Ha létezik ilen file egy könyvtárban, akkor az Apache az ebben lévı konfigurációs beállításokat figyelembe veszi, felülbírálva a globálisan beállítottakat. - ServerSignature On Off On estében az Apache egy "aláírást" főz a szerver által generált üzenetekhez. Pl.: Apache at port 80 - Alias /név/ /név_által_reprezentált_érték/ Pl. Alias /icons/ "/usr/local/httpd/icons/" Ha az Apache találkozok az "icons" kifejezéssel, azt mindig a "/usr/local/httpd/icons"-al helyettesíti. - HostnameLookups On Off A naplófájlokban történjen-e reverse DNS feloldás a kliensekrıl. Célszerő kikapcsolni (Off), mert a DNS feloldás lassíthatja a mőködést. - ErrorLog /var/log/apache2/error.log Hibanapló helye LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent - CustomLog /var/log/apache2/access.log combined Weboldal megtekintések naplója, és formátuma 2. Könyvtárak, fájlok, webhelyek Az egyik leggyakrabban használt konfigurációs beállítások a könyvtárak, fáljok, webhelyek tulajdonságát szabályozzák. <Directory könyvtár-elérési-út> utasítás

19 19 utasítás... utasítás </Directory> <Files fájl-elérési-út> utasítás utasítás... utasítás </Files> <Location webhely > utasítás utasítás... utasítás </Location> Használhatjuk még a DirectoryMatch, FilesMatch, LocationMath kifejezéseket is. Gyakrabban használt direktívák: Options : Az adott könyvtárban elérhetı paraméterek listája, értéke lehet: All None Indexes ExecCGI FollowSymlinks MultiViews stb. AllowOverRide : Beállítja azokat az opciókat, melyet majd a könyvtár.htaccess file-ja felülírhat, értéke lehet : All None AuthConfig FileInfo Indexes Limit Options Order: kiértékeles sorrendje Allow Deny #.htaccess fájl elérésének tiltása <Files "^\.htaccess"> Order Deny,Allow Deny from All </Files> # Csak a /24 hálózatról engedjük a hozzáférést <Directory /var/www/vedett> Order Deny,Allow Allow from /24 Deny from All </Directory> - AccessFileName.htaccess Ebben a fájlban beállított opciókkal lehet felülbírálni a könyvtár alapbeállításait. Ilyenkor az adott könyvtárba kell a.htaccess nevő fájlt elhelyezni, és szerkeszteni. Fontos, hogy a.htaccess tartalma futási idıben értékelıdik ki, tehát nem igényel webszerver újraindítást. Virtuális hosztok Célja, hogy egyetlen webszerverrel több website-ot is ki tudunk szolgálni 2 típusú virtuális webszerver: IP alapú: külön IP cim vagy külön port (IP based virtualhost), IP aliassal tudonk több IP címet adni egy interface-nak Név alapú: egyedi domain nevő webszerverek (Name based virtualhost, HTTP protokoll teszi lehetıvé)

20 20 Név alapú virtuális hostok. DNS beállítások: a kiszolgálni kívánt domainek A, CNAME recordja mutasson a webszerverünk IP címére. NameVirtualHost <VirtualHost > DocumentRoot /var/www/domain1.hu ServerName ServerAlias domain1.hu </VirtualHost> <VirtualHost > DocumentRoot /var/www/domain2.hu ServerName </VirtualHost> <VirtualHost > DocumentRoot /var/www/domain3.hu ServerName </VirtualHost> Komplex beállítások port alapú virtuális hoszttal: NameVirtualHost *:81 <VirtualHost *:81> ServerAdmin nszabo@linuxweb.hu DirectoryIndex index.html index.htm index.php DocumentRoot /var/www/dijtartozas/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/dijtartozas/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all RewriteEngine On RewriteCond %{REQUEST_FILENAME}!-f RewriteCond %{REQUEST_FILENAME}!-d RewriteRule. /index.html [L] </Directory> RewriteLogLevel 3 RewriteLog /var/log/apache2/rewrite.log ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On </VirtualHost > NameVirtualHost *:443 <VirtualHost *:443> ServerAdmin nszabo@linuxweb.hu DirectoryIndex index.html index.htm index.php DocumentRoot /var/www-ssl/ <Directory /var/www-ssl/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory> SSLEngine On

21 21 SSLCertificateFile /etc/apache2/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/server.key ErrorLog /var/log/apache2/ssl/error.log LogLevel warn CustomLog /var/log/apache2/ssl/access.log combined </Virtulhost> Authentikáció A hitelesítést szolgáló beállításokat elhelyezhetjük Directory, Localtion vagy.htaccess -ben is. AuthType Basic AuthName "Jelszó a titkos oldalhoz!" AuthUserFile /etc/apache2/passwords.txt Require user nszabo #Require valid-user A titkosított jelszavakat generáltatni kell a "htpasswd" programmal # htpasswd -c /etc/apache2/passwords.txt nszabo Betölthetı modulok Az apache "ereje" a modulokban rejlik. - statikus modul: nem futási idıben töltıdik be, az apache binaris (httpd) tartalmazza, lasd # httpd -l Pl: a php-t be lehet fordítani es aktiválni, csak a.php típust kell rögzíteni a httpd.conf-bna, hogy a Apache tudja futtatni - dinamikus modul (DSO): futási idıben töldıdik be A dinamikusan betölthetı modulok az apache2 esetén az /etc/apache2/mods-available vannak. Például: # cd /etc/apache2/mods-available # cat userdir.load LoadModule userdir_module /usr/lib/apache2/modules/mod_userdir.so A LoadModule a direktíva, ami egy modul betöltésére szolgál, a mods-available könyvtárban a modulok betöltésének leírásai vannak tehát. A fenti userdir_module a felhasználók saját webkönyvtárainak publikálását engedélyezi, a ~usernév könyvtárból érhetı majd el. PHP installálás Apt csomagból történı telepítés esetén libapache2-mod-php5, php5, php5-common alapcsomagok települnek fel. # apt-get install libapache2-mod-php5 php5 A betölthetı módulok közé bekerül a php5_module. Az a2enmod segítségével aktiválhatjuk is, a php5.conf a megfelelı apache beállításokat végzi el. #cat /etc/apache2/mods-available/php5.conf <IfModule mod_php5.c> AddType application/x-httpd-php.php.phtml.php3 AddType application/x-httpd-php-source.phps </IfModule> Az.php, phtml és php3 kiterjesztésekhez a PHP modult fogja használni az Apache. A PHP saját konfigurációs fájla az /etc/php5 /apache/php.ini A PHP-nak is vennek kiterjesztései (extension), melyet szintén debian csomagból telepíthetünk. # apt-get install php5-mysql php5-gd php5-cli

22 22 # dpkg -l grep php5 ii libapache2-mod-php etch13 server-side, HTML-embedded scripting languag ii php5-cli etch13 command-line interpreter for the php5 script ii php5-common etch13 Common files for packages built from the php ii php5-gd etch13 GD module for php5 ii php5-mcrypt etch13 MCrypt module for php5 ii php5-mysql etch13 MySQL module for php5 ii php5-pgsql etch13 PostgreSQL module for php5 ii php5-snmp etch13 SNMP module for php5 CGI futtatás Használnunk kell a ScriptAlias direktívát, mely közli az Apache-val, mely könyvtárakban találhatók CGI-ként futtatandó scriptek (A SscriptAlias az Aliashoz hasonlóan mőködik). ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ A fenti sorok szerint az /usr/lib/cgi-bin könyvtár tartalmát CGI programként kezeli és megpróbálja futtatni. AddHandler cgi-script.cgi.pl Az AddHandler közli a webszerverrel, milyen kiterjesztéseket értelmezzen CGI-ként. <Directory /usr/lib/cgi-bin> Options ExecCGI </Directory> Célszerő explicit módon beállítani az adott könyvtárra a ExecCGI paramétert. Fontos, hogy a CGI fájlnak futtatási jogokkal kell rendelkezni az "Apache felhasználóra" nézve.

23 23 FTP szerver: pureftpd pureftpd A Troll-FTPd szoftverbıl fejlıdött tovább, gyors, megbízható, nincs bizonyított puffer túrcsordulás ebben a rendszerben. A feljesztés során az elsıdleges szempont a biztonság és a megbízhatóság. Kezdı rendszergazdáknak és nagy ügyfélszámú internet szolgáltatóknak is megfelelı. Hivatalos weblap: Telepíthetı debian csomagból is, a rendelkezésre álló csomagok: pure-ftpd, pure-ftpd-common, pure-ftpd-mysql, pure-ftpd-ldap, pure-ftpd-postgresql 1. Telepítés forráscsomagból A pureftpd minimális beépített opciót használ. Nézzük meg a forráskönyvtárban a./configure parancs kimenetét, s állítsuk be magunknak a kívánt opciókat! # cd /usr/src # wget # tar -xvzf pure-ftpd tar.gz # cd pureftpd #./configure --with-everything --with-paranoidmsg --with-virtualchroot # make; make install Az alapértelmezett binárisok helye: /usr/local/bin; /usr/local/sbin 2. A szerver elindítása A szerver daemon (bináris): /usr/local/sbin/pureftpd. Többféle mód van elindítása: önálló daemon, inetd, Xinetd, tcpserver, stb. # /usr/local/sbin/pureftpd -paraméterek Szokásostól eltérıen minden opciót az indítás során megadott paraméterbıl vesz. Ha szeretnénk konfigurációs file-ban megadni a paraméreket, használjuk a forráskönyvtárban lévı pure-config.pl scriptet, paraméterben magadva neki a config file-t. Példa: # /usr/local/sbin/pureftpd -A -j -H -l unix -U113:002 -Oclf:/var/log/pureftpd/pureftpd.log & -B: daemonként fut -A: chroot környezetbe kerül minden felhasználó -l unix: authentikáció típusa: unix, LDAP, SQL -O clf:/var/log/pureftpd.log: log file megadása -j: createhomedir, nem létezı home könyvtárat létrehozza -H: dontresolve, nem végez fordított DNS névfeloldást a kliens IP-re Használjuk a daemontools csomagot is, az FTP szerver elindítására, monitorozására. 1. Létrehozunk egy pureftpd könvtárat az /etc alatt # mkdir /etc/pureftpd 2. Ebbe tegyünk egy run nevő shell scriptet, a következı tartalommal:... #!/bin/sh exec /usr/local/sbin/pureftpd -A -j -H -l unix -U113:002 -Oclf:/var/log/pureftpd/pureftpd.log 2>& Készítsünk szimbólikus linket a /service alá # ln -s /etc/pureftpd /service/ 5 másodpercen belül a supervise elindítja az FTP szervert, és monitorozza is. 3. Anonymous FTP Az anonymous FTP azt jelenti, a távoli felhasználó jelszó nélkül tud belépni a szerverünkre. Pureftpd esetén a beállítása nagyon egyszerő, csak egy ftp nevő felhasználót kell létrehozni, vigyázzunk viszont, hogy jelszóval, shell-lel nem rendelkezzen.

24 24 # adduser --system ftp Ezután ftp vagy anonymous felhasználóval automatikusan be tudunk jelentkezni a szerverre, a fájltörlés alapból tiltva van. Ha használjuk a -i opciót (--anonymouscantupload), az anonymous felhasználó nem tud feltölteni. Sávszélesség korlátozást beállíthatunk központilag az anonymous felhasználóra, használjuk a -t opciót. # /usr/local/sbin/pure-ftpd -t 256:64 A fenti sor 256 KB/s feltöltési, 64 KB/s letöltési sebességet állít be. Az ftp felhasználó home könyvtárába tehetünk egy.banner fájlt, aminek tartalmát belépéskor megkapja a kliens. 4. Authentikáció, virtuális felhasználók Az FTP felhasználók hitelesítése többféle módon történhet: Unixos, hagyományos módon: ilyenkor az /etc/password fájban lévı Unix felhasználók azonosítóit használja a rendszer, login név, UID, GID, jelszó, home könyvtár. Speciális attribútumokra (quota, sávszélesség, stb) nincs lehetıség. -l unix: Unix authentikáció Virtuális: ilyenkor egy Unix felhasználó létezik csak, minden FTP kapcsolat ezzel az UID/GID-párral történik. A felhasználók adatai SQL adatbázis, LDAP vagy a pureftpd saját adatbázis (puredb) fájl tartalmazza. -l ldap:/etc/pureftpd-ldap.conf: paraméterben az LDAP konfigurációs fájlt kell megadni -l mysql:/etc/pureftpd-mysql.conf -l pgsql:/etc/pureftpd-pgsql.conf -l puredb:/etc/pureftpd.pdb Puredb Nézzük meg a pureftpd saját virtuális adatbázisának mőködését. 1. lépés: hozzunk létre egy Unix felhasználót, a puredb FTP fiókok ennek a felhasználónak a jogosultságával rendelkeznek majd. # addgroup --system ftpgroup # adduser --system --ingroup ftpgroup --home /dev/null --no-create-home --shell=/bin/false ftpuser A puredb az adatokat egy passwd-hez hasonló fájlban tárolja, az alapértelmezett helye: /etc/pureftpd.passwd. /etc/pureftpd.passwd felépítése: <account>:<password>:<uid>:<gid>:<gecos>:<home directory>:<upload bandwidth>:<download bandwidth>:<upload ratio <files quota>:<size quota>:<authorized local IPs>:<refused local IPs>:<authorized client IPs>:<refused client IPs>:<time re Az FTP fiókokkal kapcsolatos összes beállítást megtehetjük a pure-pw paranccsal. Új FTP fiók létrehozására használjuk: pure-pw useradd # pure-pw useradd <login> [-f <passwd file>] -u <uid> [-g <gid>] -D/-d <home directory> [-c <gecos>] [-t <download bandwidth>] [-T <upload bandwidth>] [-n <max number of files>] [-N <max Mbytes>] [-q <upload ratio>] [-Q <download ratio>] [-r <allow client host>[/<mask>][,<allow client host>[/<mask>]]...] [-R <deny client host>[/<mask>][,<deny client host>[/<mask>]]...] [-i <allow local host>[/<mask>][,<allow client host>[/<mask>]]...] [-I <deny local host>[/<mask>][,<deny local host>[/<mask>]]...] [-y <max number of concurrent sessions>] [-z <hhmm>-<hhmm>] [-m] # pure-pw useradd gipsz -u ftpuser -d /home/ftpusers/gipsz -r /24 -z A példában létrehoztuk a gipsz nevő FTP fiókot, home könyvtára /home/ftpusers/gipsz, a /24 IP tartományból en idıszakban # pure-pw mkdb A pureftpd.passwd fájlban lévı adatokat speciális adatbázis fájlba konvertálja (/etc/pureftpd.pdb). Ha a pure-pw -m kapcso

25 25 Felhasználó adatok módosítása: # pure-pw usermod gipsz -n N 10 Beállítjuk a quota értéket 10MB-ra és 1000 db állományra. Felhasználó adatok megjelenítése: # pure-pw show gipsz Login : gipsz Password : $1$tny5F4A0$WIC/XGaTGHsGmSJrbOwcJ. UID : 103 (ftpuser) GID : 103 (ftpgroup) Directory : /home/ftpusers/gipsz/./ Full name : Download bandwidth : 0 Kb (unlimited) Upload bandwidth : 0 Kb (unlimited) Max files : 1000 (enabled) Max size : 10 Mb (enabled) Ratio : 0:0 (unlimited:unlimited) Allowed local IPs : Denied local IPs : Allowed client IPs : /24 Denied client IPs : Time restrictions : (enabled) Max sim sessions : 0 (unlimited) FTP fiók törlése # pure-pw userdel gipsz

26 26 Levelezı szerver (MTA): qmail 1. qmail Unix alatt mőködı levelezı szerver, MTA (Message Transfer Agent). Szerzı: Daniel J. Bernstein (DJB) Általános jellemzık: biztonságos moduláris gyors egyszerő Összehasonlítás más MTA-kal: MTA fejlettség biztonság szolgáltatások sebesség sendmail komp. modularitás qmail közepes jó jó jó jó jó sendmail jó kicsi jó kicsi - nincs postfix kicsi jó közepes jó jó jó exim közepes kicsi jó közepes jó nincs Miért biztonságos a qmail? A qmail részei moduláris Részfeladatokra bontja a levelezést, minden részfeladatot külön program(rész) lát el, ezek egymástól függetlenek. minimális setuid kód Csak egyetlen program fut setuid módban: qmail-queue minimális futáttatás root felhasználóként qmail-strart, qmail-lspawn, esetleg POP3 authentikáció egyszerő, BUG-mentes kód 1.qmail-queue A levelet a queue(várakozási sor)-ba helyezi, ad a fejléchez egy"received"-sort. 2. qmail-send A kimenı queue-ból továbbítja a leveleket: helyi címzett esetén a qmail-lspawn-nak, távoli címzett esetén a qmailrspawn-nak adja avezérlést. A várakozási sorban újraütemezi a leveleket az azonnali kézbesítéshez. 3. qmail-lspawn Megkeresi a helyi felhasználót a lokális kézbesítéshez, majd meghívja a qmail-localt-t. 4. qmail-local Gondoskodik a lokális kézbesítésrıl, valamint a.qmail-file-okat is kezeli. 5. qmail-rspawn Meghívja a qmail-remote programot a távoli (nem helyi) kézbesítésekhez. 6. qmail-remote SMTP protokolon keresztül levelet küld egy távoli host-nak. 7. qmail-inject Beolvas egy levelet a standard input-ról, fejléceket ad hozzá, majd meghívja a qmail-queue programot. 8. qmail-smtpd Alapértelmezésben a 25/TCP porton figyel és leveleket fogad távoli SMTP szerverektıl. 9. qmail-qmqpd A QMQP (Quick Message Queuing Protocol, 26/TCP port) protokolt használva távoli szervereknek küld levelet.minden levelet továbbküld (relay), ezért csak hitelesített szerverektıl fogad el kéréseket. Cluster funkció esetén célszerő használni. 10. qmail-popup qmail-popup beolvassa a felhasználó nevet, jelszót POP3 kapcsolat során majd meghív egy alprogramot (chekpassword, auth_pop) az autentikációra. 11. qmail-pop3d A POP3 kapcsolat kezelését végzi. 12. chekpassword A POP3 kapcsolat hitelesítését végzi (felhasználó, jelszó ellenırzés) jelenlegi vezió: qmail-1.03

27 27 2. alap installáció qmail könyvtárának létrehozása # mkdir /var/qmail Rendszerszintü felhasználók, csoportok létrehozása Készítsük el a következı shell scriptet!... #!/bin/sh groupadd nofiles useradd alias -g nofiles -d /var/qmail/alias useradd qmaild -g nofiles -d /var/qmail useradd qmaill -g nofiles -d /var/qmail useradd qmailp -g nofiles -d /var/qmail groupadd qmail useradd qmailq -g qmail -d /var/qmail useradd qmailr -g qmail -d /var/qmail useradd qmails -g qmail -d /var/qmail... Futtassuk le! Ezzel létrehoztuk a qmail felhasználóit. Tömörítsük ki a forráscsomagot pl. a /usr/src könyvtárba: # tar -xvzf qmail-1.03.tar.gz Fordítsuk le a csomagot, elıkonfigurálás nem kell! (Ha feltétlenül változtatni akarunk, módosítsuk a conf-* állományokat! ) # cd qmail-1.03 make setup check Minimális configuráció: #./config-fast host.yourdomain.hu Ezzel telepítettük a qmail-t rendszerünkre. Most jöhetnek a finomságok! 3. Alapértelmezett kézbesítés könyvtárának kiválasztása formátumok: Mailbox A felhasználó levelei egy file-ban csücsülnek, kevésbé megbízható. Nagy fileméret esetén lassú benne a levelek szétválasztása. NFS-en keresztül problémás a lockolás miatt. Pl. a sendmail a felhasználók leveleit a /var/spool/mail/$user file-ba teszi Maildir A levelek egyenként külön file-ban vannak Gyors, megbízhatóan mőködik NFS csatolt filerendszereken is. A "maildir" könyvtár alatt ekkor 3 újabb alkönyvtár jön létre: - new: az új, nem olvasott levelek helye - tmp: átmeneti könyvtár - curr: olvasott, még nem törölt levelek könyvtára A "/var/qmail/boot" könyvtárban található indító scriptek közül válasszuk a rendszerünknek megfelelıt, majd módosítsuk a /Mailbox paramétert /Maildir/-re. # cp /var/qmail/home /var/qmail/rc Maildir esetén a felhasználók home könyvtárában lévı - tipikusan Maildir nevő- könyvár new, cur, tmp alkönyvtáraiban lesznek a levelek. A qmail alapértelmezésben nem hozza létre a felhasználó Maildir könyvtárait, használjuk a maildirmake programot erre! # /var/qmail/bin/maildirmake $HOME/Maildir/ A qmail vezérlı fájlja minden felhasználó home könyvátárában lévı.qmail fáj, ez állítja be a kézbesítés módját, forwardokat, stb. (lásd lejjebb). ~/.qmail file elkészítése # echo./maildir/ > ~/.qmail Fontos a / jel a Maildir mögé! Nyilván ezt kedvenc szövegszerkesztınkkel is megtehetjük. Célszerő ezt a /etc/skel-be betteni, hogy a user-ek létrehozásakor automatikusan legyenek Maildir-ek. 4. A qmail elindítása, run scriptek

28 28 A qmail indítására használjuk a daemontools csomagot. Hozzunk létre a qmail gyökérkönyvtára alatt egy service alkönyvtárt. Példascripteket találunk a boot/ könyvtárban, ezekbıl a home nevőt használjuk majd. Hozzunk létre a qmail gyökérkönyvtára alatt egy service alkönyvtárt: # mkdir /var/qmail/service A megfelelı szolgáltatásoknak hozzunk létre alkönyvtárakat: # mkdir /var/qmail/service/qmail-send A run shell script tartalma: #!/bin/sh exec env - PATH="/var/qmail/bin:$PATH" \ qmail-start./maildir/ A log/run shell script tartalma: #!/bin/sh exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t s n10 /var/log/qmail/qmail-send Készítsünk szimbólikus linket a /service alá, a daemontools 5 másodpecen belül elindítja az smtp szerverünket # ln -s /var/qmail/service/qmail-send /service Daemontools által elindíthatjuk, naplózhatjuk a többi qmail alprogramot is (SMTP, POP3): qmail-daemontools. Teszteljük: # echo to: nszabo /var/qmail/bin/qmail-inject Ez egy üres levelet küld a "joe"-nak, helyi kézbesítés. # echo to: nszabo@domain.hu /var/qmail/bin/qmail-inject Ez egy üres levelet küld egy külsı címre.

29 29 5. Konfigurációs file-ok: /var/qmail/control Control Default Hatáskör Leírás badmailfrom none qmail-smtpd blacklisted From addresses bouncefrom MAILER-DAEMON qmail-send username of bounce sender bouncehost me qmail-send hostname of bounce sender concurrencylocal 10 qmail-send max simultaneous local deliveries concurrencyremote 20 qmail-send max simultaneous remote deliveries defaultdomain me qmail-inject default domain name defaulthost me qmail-inject default host name databytes 0 qmail-smtpd max number of bytes in message (0=no limit) doublebouncehost me qmail-send host name of double bounce sender doublebounceto postmaster qmail-send user to receive double bounces envnoathost me qmail-send default domain for addresses without "@" helohost me qmail-remote host name used in SMTP HELO command idhost me qmail-inject host name for Message-ID's localiphost me qmail-smtpd name substituted for local IP address locals me qmail-send domains that we deliver locally me FQDN of system various default for many control files morercpthosts none qmail-smtpd secondary rcpthosts database percenthack none qmail-send domains that can use "%"-style relaying plusdomain me qmail-inject domain substituted for trailing "+" qmqpservers none qmail-qmqpc IP addresses of QMQP servers queuelifetime qmail-send seconds a message can remain in queue rcpthosts none qmail-smtpd domains that we accept mail for smtpgreeting me qmail-smtpd SMTP greeting message smtproutes none qmail-remote artificial SMTP routes timeoutconnect 60 qmail-remote how long, in seconds, to wait for SMTP connection timeoutremote 1200 qmail-remote how long, in seconds, to wait for remote server timeoutsmtpd 1200 qmail-smtpd how long, in seconds, to wait for SMTP client virtualdomains none qmail-send virtual domains and users 6. Rendszerszintő aliasok definiálása A rendszerszintő aliasok:.qmail file-ok, helyük /var/qmai/alias/ Célszerő az alábbi aliasokat definálni: A qmail sohasem küld levelet a root felhasználónak, készítsünk egy aliast, aki a root leveleit fogja megkapni. # echo adminuser > /var/qmail/alias/.qmail-root Az RFC 821 mail adminisztrátora: postmaster # echo adminuser > /var/qmail/alias/.qmail-postmaster A kézbesíthetetlen levelek feladója: mailer-daemon # echo adminuser > /var/qmail/alias/.qmail-mailer-daemon Ezután a root@domain.hu, postmaster@domain.hu, mailer-daemon@domain.hu levelei az "adminuser"-hez továbbítódnak. Minden usernek lehetnek.qmail file-jai, ezeket a $HOME alá kell létrehozni, lásd késıbb. 7. SMTP szerver Az SMTP szerver alapértelmezében a 25-ös TCP porton fogad kéréseket, többnyire 2 fı funkciója van: külsı SMTP szerverek a 25-ös portra kapcsolódnak és küldenek nekünk levelet kliens programok (Otlook Express, Thunderbird, stb.) erre a 25-ös portra kapcsolódnak, a szerverünkön át küldenek t RELAY vagy SMTP hitelesítás (authentikáció) alapján.

30 30 Elindítására többféle lehetıség van inetd (nem javasolt) Az ucspi-tcp csomagból tcpserver a) init scriptbıl indul b) daemontools indítja (JAVASOLT) Dan Bernstein írt egy minden tekintetben megbízhatóbb, sokrétőbb TCP-servert, melynek neve: ucspi-tcp. Ebben a csomagban sok hasznos programot találunk, köztük a tcpservert. A tcpserver adott hálózati porton figyel és a magadott alkalmazást indítja el (pl. qmail-smptd), konfigurálására sokféle lehetıség van. Töltsük le a csomagot, csomagoljuk ki, majd futtassuk le a setup-ot. # cd /usr/src # wget # tar -xfvz ucspi-tcp-0.88.tar.gz **** FONTOS! Bizonyos libc6 verziós felett (Debian sarge, etch, lenny) szükséges az alapcsomaghoz egy javítás (patch), neve ucspi-tcp-0.88.errno.patch # wget # cd ucspi-tcp-0.88 # patch -p1 <../ucspi-tcp-0.88.errno.patch Jöhet a fordítás, telepítés # make setup check (Ez alapértelmezésben a /usr/local/bin-be teszi a binárisokat, ha nekünk ez nem felel meg, make elıtt változtassunk a conf-bin tartalmán!) A daemotools fogja monitorozni az SMTP szervert. # mkdir /var/qmail/service/qmail-smtpd A könyvtár alatt lévı run file tartalma: #!/bin/sh QMAILUID=`id -u qmaild` NOFILESGID=`id -g qmaild` exec /usr/local/bin/softlimit -m /usr/local/bin/tcpserver -vrh -l0 -u $QMAILUID -g $NOFILESGID \ -x /etc/tcp.smtp.cdb 0 25 /var/qmail/bin/qmail-smtpd 2>&1 A log/run file tartalma (ne feledkezzünk meg a log könyvtár létrehozásáról és a jogosultság beállításáról!) #!/bin/sh exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t s n20 /var/log/qmail/qmail-smtpd Készítsünk szimbólikus linket a /service alá, a daemontools 5 másodpecen belül elindítja az smtp szerverünket # ln -s /var/qmail/service/qmail-smtpd /service Teszteljük home:~# telnet localhost 25 Trying Connected to localhost. Escape character is '^]'. 220 server.envm.klte.hu ESMTP helo mail.linuxweb.hu 250 server.envm.klte.hu mail from: nszabo@envm.unideb.hu 250 ok rcpt to: nszabo@linuxweb.hu 250 ok data 354 go ahead Hello, teszt ok qp quit 221 server.envm.klte.hu

31 31 Connection closed by foreign host. Access control (hozzáférés szabályozás) A tcpserver segítségével szabályozni tudjuk, milyen IP címekrıl fogadjon el kéréseket az SMTP szerver és milyenekrıl ne. Ehhez definiáljunk egy adatfile-t (pl. /etc/tcp.smtp), melynek tartalma: :allow :allow :deny Ekkor az SMTP szerver engedélyezi a kapcsolatot a egyedi címrıl, a / hálózatról, a többit tiltja. Az adatfile-ból generáljunk egy.cdb file-t, aminek a tartalmát majd a tcpserver figyelni fogja (-x /etc/tcp.smtp.cdb). # tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp A tcp.smtp fájlban megadhatunk további változókat, melyeket az smtp szerver haszál. A példában a QMAILQUEUE változó értéke /var/qmain/bin/simscan, ami víruskeresı és SPAMszőró motort fogja meghívni :allow,RELAYCLIENT="" :allow,RELAYCLIENT="" :allow,qmailqueue="/var/qmail/bin/simscan" RELAYING Relay-nek nevezzük, ha egy MTA levelet fogad és küld SMTP-n keresztül úgy, hogy sem a küldıcím, sem a fogadott cím nem minısül helyi címnek. /var/qmail/control/locals: azok a domainek szerepelnek itt, melyeket a qmail helyinek minısít, lokálisan kézbesít (DNS névfeloldás nélkül lokálisan kézbesíti) /var/qmail/control/rcpthosts: az itt felsorolt domanekre küldött leveleket továbbítja számunkra a qmail-smtpd (A $RELAYCLIENT változót használjuk ennek rugalmas bıvítésére) A qmail-smtpd állapotában csak a ~control/rcpthosts-ban felsorolt domainekre küld leveletet, ezt célszerő a saját IP tartománnyal kiegészíteni. A tcpservernek változókat is definiálahatunk, $RELAYCLIENT kell nekünk. Készítsünk egy fájlt az SMTP szervert korlátozás nélkül használható kliensek (legtöbbször saját IP hálózatunk, illetve a localhost) számára. Az /etc/tcp.smtp tartalma: :allow,RELAYCLIENT="" :allow,RELAYCLIENT="" :allow Hozzunk létre egy.cdb file-t! # tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp Az SMTP szerver indító scriptjében hivatkozzunk -x kapcsolóval a.cdb file-ra. 8. POP3 szerver Normál linux accountoknál a felhasználói név és jelszó ellenırzésére a checkpassword programot használhatjuk. Töltsük le, tömörítsük ki, majd telepítsük: # cd /usr/src # wget # tar -xfvz checkpassword-0.90.tar.gz **** FONTOS! Bizonyos libc6 verziós felett (Debian sarge, etch, lenny) szükséges az alapcsomaghoz egy javítás (patch), neve checkpassword-0.90.errno.patch # wget # cd checkpassword-0.90 # patch -p1 <../checkpassword-0.90.errno.patch

32 32 Jöhet a fordítás, telepítés # make setup check Alapértelmezében a létrejött bináris: /bin/checkpassword Célszerőbb önálló daemonként indítani a POP3 servert is a daemontools segédletével. # mkdir /var/qmail/service/qmail-pop3d A könyvtár alatt lévı run file tartalma: #!/bin/sh exec /usr/local/bin/softlimit -m \ /usr/local/bin/tcpserver -u 0 -g 0 -vrh -l \ /var/qmail/bin/qmail-popup `hostname`.`dnsdomainname` \ /bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir 2>&1 A log/run file tartalma (ne feledkezzünk meg a log könyvtár létrehozásáról és a jogosultság beállításáról!) #!/bin/sh exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t s n20 /var/log/qmail/qmail-pop3d Készítsünk szimbólikus linket a /service alá, a daemontools 5 másodpecen belül elindítja az smtp szerverünket # ln -s /var/qmail/service/qmail-pop3d /service Teszteljük home:~# telnet localhost 110 Trying Connected to localhost. Escape character is '^]'. +OK < @ghost.linuxweb.hu> user gipsz +OK pass nemtudom +OK list retr 1 quit +OK Connection closed by foreign host. 10. dot-qmail:.qmail kontrol file-ok A felhasználó home könyvtárának gyökerében lévı.qmail file vezérli a leveleket kézbésítését, továbbítását. 5 féle leíró van Megjegyzés: # jellel kezdödik Pl: # ez egy komment Mailbox megnevezés: / vagy. jellel kezdödik, és NEM /-el végzıdik pl../mailbox Maildir megnevezés: / vagy. jellel kezdıdik, és /-el végzıdik pl../maildir/ Forward megnevezés: &-al, számmal vagy betővel kezdıdik. Erre a címre továbbítódik a levél egy másolata pl. &masik.cim@domain.hu Alprogram megnevezése: -al kezdıdik pl. /usr/bin/maildrop A bejövı leveleket a maildrop MDA-nak (delivery agent) továbbítja

33 Virtuális domainek Mail szerverünk több domainre is fogadhat -eket. Ehhez nyilván a DNS szerverekben a mi hostunkat kell az adott domain MX rekordjára beállítani. Aztán a /var/qmail/controls/virtualdomains szerkesztése user@domain1.hu:user1 user@domain2.hu:user2 Figyeljük meg, hogy user@... lesz mindkét esetben a local része a -nek, de az elsı esetben a user1 felhasználó Maildir-ébe érkeznek a levelek, míg a második esetben a user2-jébe. 12. Patch Több ezer felhasználó esetén nem feltetlenül szükséges Unix accountot létrehozni számukra, virtuális user-ként leveleznek. Ezt támogatva íródott néhány patch_ - qmail-ldap: LDAP címtárban vannak userek - vpopmail:

34 34 SPAM és vírusvédelem A levelezı rendszerünk legkritikusabb része, hogyan tudja kivédeni az Internetrıl érkezı folyamatos SPAM áradatot. A SPAM (vírus) elleni védelmet több lépcsıben célszerő felépíteni, és figyeljünk a következı alapelvekre: Lehetıleg mindent SMTP kapcsolat szintjén végezzünk, ne lokális kézbesítéskor. Így erıforrást takarítunk meg, illetve ki tudjuk védeni a levélhamisítások miatti téves értesítéseket. Nagyobb forgalmú szervereken részesítsük elınyben a C nyelvő programkódokat pl. a Perl kóddal szemben. Egy jól mőködı SPAM szőrı vázlata RBL lista (=feketelista) Szürkelista (greylist) QUEUE alapú tartalomszőrés (simscan) 1. Vírusellenırzés (Clamav) 2. SPAM vadász (SpamAssassin) 1. RBL (fekete) lista használata Az RBL (Realtime Block List = Valós idejő blokklista) technika már régóta létezik az elektronikus levelezésben. Lényege, hogy bizonyos szervezetek kigyőjtük az olyan számítógépek, levelezı szerverek, hálózatok IP címeit, amelyrıl bizonyítottan SPAM küldés történt és ezt egy lekérdezhetı adatbázisban tárolják. A qmail-smtpd az fogadása elıtt ellenırzi, hogy a küldı IP cím szerepel-e valamelyik RBL adatbázisban, és ha igen, 451 hibaüzenettel visszautasítja az fogadásást. Ma már több típusú RBL adatbázis létezik (DNSBL=DNS alapú lista, SURBL = web cím fekete lista, stb.) Jól mőködı RBL listák: zen.spamhaus.org bl.spamcop.net psbl.surriel.com dnsbl-1.uceprotect.net Megvalósítása qmail esetén a rblsmtpd daemonnal történik (ucspi-tcp csomag része). Az SMTP szerver indító scriptjében a qmail-smtpd meghívása elı helyezzük az rblsmtp sort. Az rblsmtpd után -r paraméterrel adhatjuk meg a használandó RBL forrást (lehetsıges több -r opciót is megadni). A /var/qmail/service/qmail-smtpd/run file tartalma:... #!/bin/sh QMAILUID=`id -u qmaild` NOFILESGID=`id -g qmaild` exec envdir./env \ exec /usr/local/bin/softlimit -m \ /usr/local/bin/tcpserver -vrh -l0 -u $QMAILUID -g $NOFILESGID \ -x /etc/tcp.smtp.cdb 0 25 \ /usr/local/bin/rblsmtpd -r zen.spamhaus.org -r bl.spamcop.net -r psbl.surriel.com -r dnsbl-1.uceprotect.net \ /var/qmail/bin/qmail-smtpd 2>&1... Nézzünk meg egy qmail-smtpd naplót! :33: tcpserver: pid from :33: tcpserver: ok business business.broadband.hu: :25 : :: :33: rblsmtpd: pid 11022: /bl?ip= :33: tcpserver: end status 0 Az SMTP szerverünket levelküldésre használó kliensek szintén RBL ellenırzésen esnek át, ami kliensek esetén nem célszerő. Lehetıség van tcp.smtp fájlban ezt felülbírálni, és kivételeket megadni. Ha a $RBLSMTPD változónak üres értékkel szerepel, akkor ezekre az IP címekre nincs RBL ellenırzés Ha tehát azt szeretnénk, hogy a /24 tartományról a kliensek küldhessenek t RBL ellenırzés nélkül, tegyük a RBLSMTPD="" sztringet az /etc/tcp.smtp fájlba.

35 :allow,RELAYCLIENT="" :allow,RELAYCLIENT="",RBLSMTPD="" :allow Ne felejtsük el a tcp.smtp.cdb fájlt legeneráltatni: # cd /etc/ # tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp Az rblsmtpd használatáról bıvebb információt D. J. Bernstein oldalán találunk: 2. Szürkelista (greylist) A greylist technikai kiváló hatékonysággal használható a SPAM-et küldık ellen. Lényege, hogy a minden egyes fogadáskor az SMTP szerver feljegyzi a levélküldı IP címét ( a feladó és a címzett adatait). Ha ez az IP cím még nem szerepel az adatbázisunkban (azaz elsı próbálkozás), akkor az SMTP szerver egy ideiglenes hibával visszautasítja az kézbesítést. A küldı szerver ilyenkor vár néhány percig (5-10 perc), majd újra próbálja elküldeni számunkra az t. Legalábbis a szabvány szerint mőködı levelezı szerverek ezt teszik. Második próbálkozásra már megtörténik az kézbesítés, s ezután ezt az IP címet 30 napig már "jó" bejegyzésként kezeli a szerver, és minden esetben fogadja az t. Mi a helyzet a SPAM-küldık esetén? Nos, a spammelık általában nem szabványos levelezı szervereket használnak, hanem olyan szoftvereket, amikkel rövid idı alatt nagy számú SPAM-et tudnak kiküldeni. A greylista elsı esetben visszautasítja az ilyen kapcsolatokat, és mivel ezek nem szabványos levelezı szerverekként mőködnek, nem próbálkoznak újra ugyanilyen adatokkal. Változtatják pl. a feladó címét, más IP címrıl próbálkoznak, de ezek mind elbuknak a greylista miatt. Alap qmail esetén az alábbi jgreylist megvalósítást javaslom: A jgreylist az IP címeket állománybejegyzésekként tárolja (lehetıség van nem egyedi IP címekre, hanem C osztályú IP tartományokra ellenırzést végezni, ezt a jgreylist perl programban meg lehet adni). Pl. ha új SMTP kapcsolatot kezdeményez a IP címő szerver, akkor a jgerylist létrehozza a 193/, 193/188, 193/188/141 könyvtárstruktúrát és abban a 30 nevő fájlt. Telepítés Töltsük le a jgreylist programot a /var/qmail/bin könyvtárba. (Van perl és C nyelő verzió is, elsıre egyszerőbb perl verziót beállítani). # cd /var/qmail/bin # wget A qmail-smtpd indító scriptjében szereplı user tulajdona kell legyen a jgreylist, 0750 jogosultsággal # chown qmaild:nofiles /var/qmail/bin/jgreylist # chmod 0750 /var/qmail/bin/jgerylist A munkakönyvtár /var/qmail/jgerylist legyen, 0700 jogokkal # cd /var/qmail # mkdir -m 0700 jgreylist # chown qmaild:nofiles jgreylist Módosítsuk a qmail-smtpd run scriptet, a qmail-smtpd elıtt hívjuk meg a /var/qmail/bin/jgreylist programot. Ha RBL szőrıt használunk, a greylistet ez után célszerő meghívni. A /var/qmail/service/qmail-smtpd/run file tartalma:... #!/bin/sh QMAILUID=`id -u qmaild` NOFILESGID=`id -g qmaild` exec envdir./env \ exec /usr/local/bin/softlimit -m \ /usr/local/bin/tcpserver -vrh -l0 -u $QMAILUID -g $NOFILESGID \ -x /etc/tcp.smtp.cdb 0 25 \ /usr/local/bin/rblsmtpd -r zen.spamhaus.org -r bl.spamcop.net -r psbl.surriel.com -r dnsbl-1.uceprotect.net \ /var/qmail/bin/jgreylist \ /var/qmail/bin/qmail-smtpd 2>&1... Lássuk a logot!

36 :28: tcpserver: ok 8478 business business.broadband.hu: :25 ghost.linuxweb.hu: :: :28: jgreylist[8478]: : GREY first time :28: jgreylist[8478]: >>>220 jgreylist :28: jgreylist[8478]: <<<EHLO ghost.linuxweb.hu :28: jgreylist[8478]: >>>250 jgreylist :28: jgreylist[8478]: <<<MAIL :28: jgreylist[8478]: >>>250 jgreylist :28: jgreylist[8478]: <<<RCPT :28: jgreylist[8478]: >>>450 GREYLIST Try again later :28: jgreylist[8478]: <<<QUIT :28: jgreylist[8478]: >>>221 jgreylist :28: tcpserver: end 8478 status :28: tcpserver: status: 0/40 Egy dolgot még feltétlenül finomítanunk kell. Az SMTP szerverünket levelküldésre használó kliensek most GREYLIST-re kerülnek, ami kliensek esetén nem célszerő. A jgreylist is használja szerencsére a tcpserver tcp.smtp adatbázisát, és lehetıségünk van kivételeket megadni. x.x.x.x:allow Normal cím - kliens kapcsolat engedélyezett, de elsı alkalommal greylist-re kerül x.x.x.x:allow,jgreylist="" kliens kapcsolat engedélyezett, nincs greylist ellenırzés (WHITELIST) x.x.x.x:allow,jgreylist="we don't want your spam." kliens kapcsolat engedélyezett, minden esetben visszautásításra kerül (BLACKLIST) Ha tehát azt szeretnénk, hogy a /24 tartományról a kliensek küldhessenek t GREYLIST nélkül, tegyük a GREYLIST="" sztringet a tcp.smtp fájlba :allow,RELAYCLIENT="" :allow,RELAYCLIENT="",GREYLIST="" :allow 3. QUEUE alapú tartalomszőrés (simscan) Hatékony levelezés biztosításhoz feltétlenül szükséges az ek vírusellenırzése, SPAM szőrése. Qmail esetén lehetıségünk van a mailqueue helyett meghívni a tartalomszőrıt illetve egyénileg - a felhasználó MDA programja által- beállítani. Javaslom, hogy globális megoldásokat használjunk, mert így az összes felhasználó SPAM és víruskeresését egy konfigurációval meg tudjuk oldani. QUEUE alapú megoldások: qmail-scanner: perlben íródott, sokrétő, de nagy forgalom esetén lassú. simscan: C-ben íródott, gyors, megbízható. Használkuk most a Simscan programot, de elıbb az alábbi 3 dolgot állítsuk be. QMAILQUEUE patch: ez egy javítás, mely lehetıvé teszi az alternatív queue használatát Spamszőrésre Spamassassin: Vírusellenırzés Clamav: QMAILQUEUE patch telepítése: # cd /usr/src # wget # cd /usr/src/qmail-1.03 Ha már lefordított forrásunk van # make clean # patch -p1 <../qmailqueue-patch Fordítsuk le újra a qmail-t, elıtte célszerő leállítani a futó qmail folyamatokat # svc -d /service/qmail-* # svc -d /service/qmail-*/log # make setup check 3.2 SpamAssassin (SPAM vadász)

37 37 Telepítés Debian csomagból # apt-get install spamassassin spamc Szerkesszük a debian alatti /etc/default/spamassassin fájl, a daemon indulási paramétereinek beállításához # /etc/default/spamassassin # WARNING: please read README.spamd before using. # There may be security risks. # Change to one to enable spamd ENABLED=1 Szerkesszük a Spamassassin fı konfigurációs fájlt: /etc/spamassassin/local.cf # See 'perldoc Mail::SpamAssassin::Conf' for details of what can be tweaked. ########################################################################### # required_hits 6.0 # Kritikus pontszám, ezt elérve a levél SPAM minısítést kap rewrite_header Subject SPAM GYANUS LEVEL *** # A spamnak vélt tárgyát kiegészíti a fenti karakterekkel add_header spam Flag _YESNOCAPS_ # A spamnek vélt fejlécébe X-Spam-Flag YES NO nagybetős értékeket ad report_safe 0 # Spam ek esetén csak a fejlécet módosítja 1,2 érték esetén új report t is generál skip_rbl_checks 1 # RBL ellenırzéseket lépje-e át # WHITELIST funkció bekapcsolása auto_whitelist_path /var/spool/spamd/whitelist auto_whitelist_file_mode 0666 # Razor use_razor2 1 razor_config /etc/spamassassin/.razor/razor-agent.conf # BAYES mintaellenırzı bekapcsolása use_bayes 1 bayes_path /var/spool/spamd/bayes bayes_file_mode 0666 bayes_min_ham_num 150 bayes_min_spam_num 150 use_bayes_rules 1 bayes_auto_learn 1 bayes_auto_learn_threshold_nonspam 0.1 bayes_auto_learn_threshold_spam 10.2 # BAYES pontszámok definálása score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ Indítsuk újra a Spamassassin daemont: # /etc/init.d/spamassassin stop start

38 38 Teszteljük parancssorból: # spamassassin -t < .txt 3.3. ClamAV telepítése # apt-get install clamav clamav-daemon # apt-get install clamav-freshclam (vírusdefiníciós fájlokat frissíti) Nézzük meg az /etc/clamav/clamd.conf fájl Ha nagy forgalmú a mail szerverünk, a clamav-ot daemonként futtassuk, sokkal jobb teljesítményt érünk el, mintha a parancssori clamscan programot hívjuk meg. Használjuk a daemontools-t, a clamd biztontonságos futtatásához. Itt egy példa run script: #!/bin/sh exec 2>&1 rm -f /var/run/clamav/clamd.ctl exec setuidgid clamav /usr/sbin/clamd Az /etc/clamav/clamd.conf-ban Foreground értéket állítsuk yes-re. Másoljuk be a run scriptet az /etc/clamav könyvtárba, majd készítsünk egy szimbolikus linket a /service könyvtár alá. # ln -s /etc/clamav /service/ A vírusdefiníciós fájlok a freshclam program frissíti. Indítsuk el a háttérben, s naponta 12-szer futtasson automatikus updatet. # /usr/bin/freshclam -d -c 12 -l /var/log/clamav/update.log 3.4 Simscan telepítése A Simscan C nyelvben írt alkalmazás. Lehetıvé teszi, hogy a qmail-smtpd elutasítsa a vírusokat, a spameket, és blokkoljon bizonyos mellékleteket az SMTP beszélgetés során, így a feldolgozás terhelés az rendszerben minimális marad. A Simscan a QMAILQUEUE helyett hívódik meg (ehhez kell a qmailqueue patch), ha mindent rendben talál, ekkor az t átadja a QUEUE-nak, ellenkezı esetben visszadobja az t. Szerzı az Inter7-com csapata, ahol sok más DJB alkalmazást is találhatunk: Jelenlegi verzió 1.4, jól mőködik produkciós környezetben is. Tölsük le, csomagoljuk ki. # cd /usr/src # wget # tar -xvzf simcan tar.gz # cd simcan Hozzuk létre a simscan csoportot és felhasználót: # addgroup --system simscan # adduser --system --ingroup simscan --no-create-home simscan C forráskódú programokat elıször konfigurálnunk kell, az elérhetı opciókat a./configure --help paranccsal jeleníthetjük meg. Ebbıl adjuk meg a számunkra szükséges opciókat:./configure --enable-user=simscan --enable-clamav=y \ --enable-spam=y \ --enable-spam-hits=11 \ --enable-received=y \ Ha minden rendben, az alábbi összefogalót látjuk: Current settings

39 39 user = simscan qmail directory = /var/qmail work directory = /var/qmail/simscan control directory = /var/qmail/control qmail queue program = /var/qmail/bin/qmail-queue clamdscan program = /usr/bin/clamdscan clamav scan = ON trophie scanning = OFF attachement scan = OFF ripmime program = OFF custom smtp reject = OFF drop message = OFF regex scanner = OFF quarantine processing = OFF domain based checking = OFF add received header = ON spam scanning = ON spamc program = /usr/bin/spamc spamc arguments = spamc user = OFF authenticated users scanned = OFF spam passthru = OFF spam hits = 11 dspam scanning = OFF # make # make install-strip Simscan - Clamav jogosultások Amennyiben Clamav víruskeresıt használunk, ez a jogosultságból adódó plusz beállításokat igényel. Ennek oka, hogy a Simscan és a Clamav is saját, "kis" jogusultású felhasználó nevében fut. Megoldások: Futtassuk a Clamavot root-ként (nem javasolt) Futtassuk a Clamavot a clamav felhasználóval és állítsuk be a következıket: A /var/qmail/simscan könyvtár alap tulajdonosa simscan.root. Változtassuk a csoportot clamav-ra. # chgrp clamav /var/qmail/simscan Állítsuk be a SGID bitet a /var/qmain/simscan könyvtárra, így a simscan által létrehozott fájlok tulajdonosa a clamav csoport lesz. # chmod g+s /var/qmail/simscan/ A könyvtár joga így 2750 lesz. Az /etc/clamd.conf konfigban ellenırízzük, hogy AllowSupplementaryGroups legyen beállítva, így a clamd daemon "együtt tud mőködni" a simscan csoporttal. Teszteljük Aktiválás QMAILQUEUE=/var/qmail/bin/simscan SIMSCAN_DEBUG=2 /var/qmail/bin/qmail-inject nszabo@linuxweb.hu< .txt Utolsó lépésként mondjuk meg a qmail-nek, hogy az eredeti QMAILQUEUE helyett hívja meg a simscan programot. Ezt az /etc/tcp.smtp fájlban tudjuk beállítani, IP tartományonként :allow,RELAYCLIENT="" :allow,RELAYCLIENT="",RBLSMTPD="" :allow,qmailqueue="/var/qmail/bin/simscan" Ezzel a beállítással localhostról és a belsı hálóról jövı kéréseket szőrés nélkül tovább engedjük, a külsı kapcsolatokra meghívjuk a simscant. Módosítsuk ezt saját igényeinknek megfelelıen! Generáljuk le a tcp.smtp.cdb fájlt: # cd /etc

40 40 # tcprules tcp.smtp.cdb tcp.smt.tmp < tcp.smtp A fenti beállítással futtatott simscan a következıket végzi el A Spamassassin beállított kritikus pont (required_hits) 6.0 E pontszám alatti eket a rendszer változtatás nélkül kézbesíti. A 6.0 fölötti és 11.0 alatti ek tárgyát SPAM GYANUS LEVEL*** sztringgel egészíti ki, kézbesíti. Felhasználói oldalon lehetıség van a leválogatásra. A 11.0 fölötti pontszám esetén a rendszer hibaüzenettel visszadobja a feladónak az t, nem történik kézbesítés.

41 41 squid proxy szerver Nagyteljesítményő, skálázható WEB proxy cache kiszolgáló. Jelentése: tintahal. Alkalmas HTTPS, HTTP, FTP protokollok kezelésére. Két alapvetı üzemmódja van: http gyorsító (http accelerator): ilyenkor több klienstıl egy szerver felé irányuló kapcsolatokat vár, webszerverek elé szokták tenni. http cache: általában belsı hálózaton van, és a LAN gépeinek web forgalmát gyorsítja A squid2 szoftver fut a legtöbb Unix, Linux disztribúción Hardver: nem elsısorban CPU igényes alkalmazás, inkább a memóriára (RAM) fektessük a hangsúlyt, nem árt egy nagy mérető gyors disk (SCSI, SAS) a letöltött objektumok tárolására. Telepítés: 1. Válasszuk ki a cache számára megfelelı tárterületet. - Feltetlenül külön partíción helyezkedjen el, már az op. rendszer telepítésekor hagyjunk neki helyet - Hozzuk létre a megfelelı merető partíciót (fdisk, cfdisk), pl. /dev/hda5 - Formázzuk ext3 típusúra: # mkfs.ext3 /dev/hda5 - mountoljuk fel a filrendszerünk egy pontjára # mount -o noatime /dev/hda5 /var/squid/cache Használjuk a noatime opciót, ezzel a diszkrıl olvasást felgyorsíthatjuk, írjuk be az /etc/fstab file-ba is!!! 2. Módosítsuk a squid config file-t: /etc/squid.conf cache_dir /var/squid/cache A cache könyvtárak helye maximális cache méret (5GB) elsıszintő könyvtárak száma második szintő könyvtárak száma cache_mem 128 MB A letöltött objektumokat a squid a memóriában es cacheli, ezeknek a maximalis memóriabeli tárolását állíthatjuk itt be. Vigyázat! Ez csak a gyorsítótár által elfoglalt memória, a squid természetesen ezen felül is használ RAM-ot. acl, http_access, icp_access ACL: Access Controll List Feltétlenül definiáljunk hozzáfárás vezérlési listát (listákat), hogy illetéktelenek ne használhassák a cache-t. A squid alapból csak a helyi géprıl(localhost) engedi a hozzáférést. acl localnet src / acl neve acl típusa leírás acl all src / http_access allow localnet acl operátor szabály melyik acl-re érvényes http_acces allow localnet http_acces deny all cache_mgr squid.admin@domain.com

42 42 A squid adminisztrátorának címe, ide küld értesítést a squid, ha a cache összeomlik cache_effective_user Ezen felhasználó nevében fut a progi, tipikusan kisjogu felhasználó, alapértelmezett port a 3128 nem root-ként lehet 1024 feletti porton futtatni. cache_effective_user squid cache_effective_group nogroup 3. Hozzuk létre (csak elsı alkalommal) a cache könyvtárakat: # squid -z 4. Indítsuk el a squid-et: # /etc/init.d/squid start 5. Cliensek konfigurálása: Állítsuk be a szerverünk IP címét, vagy domain nevét a cliens böngészıben. A squid alapértelmezett portja: 3128 ACL: Access Controll List (Hozzáférés Vezérlés) Néhány példa a squid ACL-re. Általános leírás: acl definíció: acl acl_neve acl_típusa acl_leírása "filenév" acl operátorral szabály felállítása: http_access allow deny [!]acl_neve icp_access allow deny [!]acl_neve 1. forrás(kliens) IP címekre vonatkozó ACL. típus: src acl acl_név src ip_cím/netmask acl acl_név src ip_cím1-ip_cím2/netmask kliens IP címtartományok kliens IP címek Példa: acl LAN1 src /24 acl LAN2 src / /24 acl LAN3 src cél IP címekre vonatkozó ACL típus: dst Példa: acl CEL dst Forrás/cél domainekre vonatkozó ACL típus: srcdomain/dstdomain Példa: acl warez dstdomain warez.org http_access deny warez http_access allow localnet http_acces deny all 4. URL-re vonatkozó ACL-ek, reguláris kifejezések A reguláris kifejezések alapértelmezésben kis-nagybető érzékenyek. Használjuk a [-i] opciót, ha ezt nem akarjuk. típus: srcdom_regex/dstdom_regex Példa: acl bad_domains dstdom_regex -i erotica http_access deny bad_domains http_access allow localnet

43 43 http_acces deny all típus: url_regex urlpath_regex (A teljes URL-ben vizsgál) (csak a domain utáni részt vizsgálja) Példa: acl pgsm url_regex pgsm pannon http_access deny!pgsm http_access allow localnet http_acces deny all Példa: acl badurl url_regex sex.*\.avi$ (az olyan URL-ket tiltjuk, amiben szerepel a sex szó és avi kiterjesztéső állomány) http_access deny badurl http_access allow localnet http_acces deny all 5. Idıintervallumok: típus: time formátum: 6:00-16:00 (idıintervallum) S-Sunday, M-Monday, T-Thuesday, W-Wednesday, H-Thursday, F-Friday, A-Saturday (napok) Példa: acl worktime time 8:00-17:00 http_access deny!worktime http_access allow localnet http_acces deny all Nagyon fontos az ACL-ek kiértékelése: A squid soronként nézi az ACL operátotok által leírt szabályt. Ha egy kérés illeszkedik egy szabályra, akkor ennek megfelelıen engedélyezi vagy tiltja. Ha egyetlen ACL szabállyal sem egyezik, akkor az utolsó ACL ellentétét hajtja végre. Éppen ezért célszerő egy" http_access allow all vagy http_access deny all " szabályt felállítania az ütközések elkerülésére. Az ACL típusoknak illetve operátoroknak ez csak töredéke, részletesebb információ a squid dokumnetációban. A hibaüzenetek magyarítása: # error_directory /usr/share/squid/errors/english error_directory /usr/share/squid/errors/hungarian proxy authentikáció NCSA típusó felhasználó hitelesítés (tud még SMB, LDAP, stb.) 1. Felhasználó név jelszó páros létrehozása Elıször hozzunk létre a htpasswd paranccsal felhasználókat. Az apache csomag htpasswd programja tökéletesen megfelel. # htpasswd -c /etc/squid/passwd gipsz Output: New password: Re-type new password: Adding password for user gipsz Állítsuk be, hogy a squid felhasználó olvashassa a jelszófájlt. # chmod o+r /etc/squid/passwd 2. Keressük meg hol van az authentikációs program (nsca_auth). Általában az nsca_auth bináris a /usr/lib/squid/ncsa_auth. Keressük meg, hogy hol van pontosan a Debian csomagunkból: # dpkg -L squid grep ncsa_auth /usr/lib/squid/ncsa_auth 3. Álltsuk be a megfeleı paramétereket a squid.conf-ban. # mcedit /etc/squid/squid.conf auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd auth_param basic children 5

44 44 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours auth_param basic casesensitive off Az ACL részben: acl CSAK_AUTH proxy_auth REQUIRED http_access allow CSAK_AUTH auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd A jelszó fálj és auth program megadása auth_param basic children 5 Ennyi darab authentikációs processz fusson auth_param basic realm Squid proxy-caching web server A böngészıben felugró ablakban ez az üzenet jelenik meg auth_param basic credentialsttl 2 hours Ennyi ideieg érvényes a hitelesített felhasználó. Jelen példa szerint 2 óránként újra kéri a jelszót a squid. auth_param basic casesensitive off Kis-nagybetőt megkülönbözet-e a felhasználónévben acl CSAK_AUTH proxy_auth REQUIRED CSAK_AUTH nevő ACL hozunk létre, REQUIRED típusút. http_access allow CSAK_AUTH A proxy elérést csak a sikeresen authentikált felhasználóknak engedi. 4. Indítsuk a squid-et újra Transparens proxy A transparens mőködés azt jelenti, hogy kliens oldalon a böngészıben nem állítjuk be a proxy használatot, hanem egy tőzfal szabály minden 80-as portra menı kérést automatikusan a proxy-ra irányít. Beállításához a squid és iptables oldalon a következık szükségesek: squid konfigban: httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on A proxy a tőzfal gépen fut (REDIRECT) # iptables -A PREROTUNG -p tcp --dport 80 -j REDIRECT --to-ports 3128 Suid tuningolás Diszkek Tegyük külön partícióra a cache könyvtárat, és használjunk 'noatime' opciót. Ha lehet, tartsuk alacsonyan a diszk foglaltságát. 99%-ra telített partícióval lassabb sebességeket érhetünk el, mint egy 50%-ra telített diszk esetén. A filesystem kreálásakor ügyeljünk a blokkméret megválasztására. Mivel a cache-ben a tárolt objektumok túlnyomó többsége (>80%) 4 kb-nál kisebb, ezért érdemes a 2048 vagy 4096 byte-os blokkméretet preferálni. Egy diszk kb mővelet/másodpercnél többet nem képes kihozni magából,így nagyobb forgalom esetén több diszkre érdemes szétosztani a forgalmat. Squid esetén több 'cache_dir'-t is megadhatunk, és a partíciók között a beállított terület függvényében osztja szét a forgalmat, tehát nincs szükség RAID0 támogatásra. A legdrágább megoldást egy RAID kontroller vásárlása jelentheti: ebben az esetben érdemes ügyelni a kontrolleren lévı NVRAM mennyiségére. A nagyobb mérető NVRAM képes gyorsítani az I/O mőveletek sebességét, a hirtelen jött forgalomnövekedéseket (burst-öket) képes elsimítani. Másrészt RAID kontroller esetén az operációs rendszer nagyon keveset vár a mővelet befejezésére, hiszen az adatokat gyakorlatilag a kontroller NVRAM-jába írja (és ez a mővelet meglehetősen gyors), onnan pedig a kontroller fogja ütemezési mechanizmusának megfelelıen a diszkekre írni. Naplózás A naplófile-okat érdemes külön partícióra, diszkre tenni. Semmiképpen sem jó ötlet a naplófile-okat és a tárolt objektumokat ugyanazon a partíción/diszken tartani. A naplózás mértékét csökkenteni lehet, és akár ki is kapcsolhatjuk, ha egyáltalán nincs szükségünk ezekre az adatokra. Továbbá kis mértékben gyorsíthatjuk a naplózást (és

45 45 csökkenthetjük a diszk terhelését), ha buffereljük a folyamatot (buffered_logs on).

46 46 Csomagszőrés: netfilter/iptables Tartalom 1. IP csomagok haladása a tőzfalon 2. Tőzfal szabályok felépítése, szintaktikája 2.1 táblák 2.2 parancsok parancsok opciói 2.3 illeszkedés általános illeszkedés TCP illeszkedés UDP illeszkedés ICMP illeszkedés Explicit illeszkedés 2.4 Célpont/Ugrás ACCEPT célpont DROP célpont REJECT célpont DNAT célpont SNAT célpont MASQUERADE célpont REDIRECT célpont LOG célpont ULOG célpont MARK célpont TOS célpont TTL célpont MIRROR célpont QUEUE célpont RETURN célpont 3. Esettanulmányok 3.1 Proxy szerver 3.2 Csomagszintő megoldás (NAT, MASQUERADE) 3.3 Transparens proxy 4. Kapcsolat követés (Connection Tracking) 5.Példa scriptek 5.1 Egyszerő tőzfal 5.2 Összetett tőzfal A netfilter/iptables projekt a Linux 2.4 / 2.6 KERNEL tőzfal alrendszere. Funkciói (ezek a funkciók a netfilter 3 tábláját is jelölik: filter, nat, mangle): csomagszőrés (filter) Network Address Translation (NAT) csomagjelölés (mangle) A netfilter részei: A standard Linux kernelbe épített rész iptables, iptables-save, iptables-restore felhasználó oldali programok 1. IP csomagok haladása a tőzfalon Az alábbi ábra mutatja, hogyan haladhatnak végig a tőzfal gépen a csomagok, s ennek alapján jó rálátásunk lesz arra, milyen ponton, milyen lánccal szőrhetjük a csomagokat.

47 47 Az iptables felhasználói programmal szabályakot adhatunk meg. A KERNEL megvizsgálja, hogy az adott csomag illeszkedik-e a szabályra, ha igen a szabály által megjelöltcélpontra ugrik (DROP, ACCEPT, másik lánc, stb.). A szabályok megadásához használhatjuk a netfilter tábláit a beépített láncokkal, illetve saját láncokat is defianiálhatunk. A beépített láncokat NAGY BETŐVEL jelölik, megkülönböztetve a kisbetős saját láncoktól. Minden beépített lánchoz megadhatunk egy táblát is a "-t" kapcsolóval, nat, mangle és filter táblák közül. Az alapértelmezett tábla a filter tábla. A netfilter beépített láncai az áthaladás sorrendjében. Zárójelben a lánc által használható táblák nevei: PREROUTING (mangle, nat) Azok a tőzfalhoz érkezı csomagok sorolhatók ide, melyek routolási folyamat elıtt vannak. (Routolás után az dıl el, milyen irányban, úton mennek a csomagok tovább). INPUT (mangle, filter) A tőzfalra beérkezı csomagok, melyek célpontja a tőzfal valamelyik interfésze. FORWARD (mangle, filter) A tőzfalon áthaladó azon csomagok, melyeknek sem a forrása sem a célja nem a tőzfal. OUTPUT (mangle, filter, nat) A tőzfal valamely interfészérıl kiinduló, helyileg generált csomagok. POSTROUTING (mangle, nat) A tőzfalat elhagyó, routolási folyamat után lévı csomagok 2. Tőzfal szabályok felépítése, szintaktikája # iptables [-t tábla] parancs [ illeszkedési feltétel ] [célpont/ugrás] Példa: # iptables -t filter -A INPUT -s /24 -j DROP

48 táblák -t filter: tábla neve, elhagyható, mivel ez az alapértelmezés -A INPUT: parancs, az INPUT beépített láchoz adunk egy új szabályt -s /24: illeszkedés leírása, a /24 IP címtartományrıl érkezı kérések -j DROP: ugrás a DROP beépetett célpontra, ami a csomagot eldobja A tábla neve elıtt -t kapcsoló kell használnunk. Tábla neve Leírás "Network Address Translation" célokra használják, azaz a csomagok IP fejlécében történik manipuláció a leíró szabálynak megfelelıen. Adatfolyam jellegő csomagok esetén csak az elsı csomagot vizsgálja meg, az adatfolyamban lévı többi csomag automatikusan manipulálva lesz. A nat tábla által jellemzıen használt célpontok: nat DNAT: cél(destination) NAT A csomag cél IP címét írja át, PREROTUNG láncon használjuk. Pl. a tőzfalra érkezı 80-as portra jövı kéréseket a belsı web szerverre dobja. SNAT: forrás(source) NAT A csomag forrás IP címét írja át, POSTROUTING, OUTPUT láncon használjuk. Pl. egy fix IP címő gépen keresztül egy privát IP hálózat Internet elérését meg lehet oldani. MASQUEREADE: maszkolás Az SNAT speciális esete, akkor használjuk, amikor nincs FIX IP címő kapcsolata a tőzfalnak, kimenı interfész nevével használható (eth0, ppp0, stb.) Csomagjelölésre, módosításra használjuk. A csomag tartalmában és a fejlécben is tudunk vele változásokat eszközölni. Cépontok: mangle TTL: Time To Live (élettartam) Az IP fejléc TTL mezıjét módosítja TOS: Type of Service (szolgáltatés típusa) MARK: Speciálisan megjeleölhetjük a csomagot, amit késıbb más program használhat (iproute2) Kizárólagosan a csomagok szőrésére használható. A "rossz" csomagokat eldobhatjuk, naplózhatjuk, a "jó" csomagokat átengedjük. Célpontok: filter DROP ACCEPT REJECT LOG 2.2 parancsok Parancs jelölése -A, --append -D, --delete -R, --replace -I, --insert Leírás, példa # iptables -A INPUT... Beszúr egy szabályt az adott lánc végére # iptables -D INPUT 1 Töröl egy szabályt # iptables -R INPUT 1 -s j ACCEPT Adott helyen lévı szabályt kicseréli # iptables -I INPUT 1 -s j ACCEPT Adott helyen lévı szabályt kicseréli

49 49 -L, --list -F, --flush -Z, --zero -N, --new -X, --delete-chain -P, --policy -E, --rename # iptables -L INPUT Lánc szabályainak listázása # iptables -F INPUT # iptables -t nat -F Az adott tábla, lánc minden szabályát törli # iptables -Z INPUT Az adott tábla, lánc számlálóit nullázza # iptables -N test Saját lánc definiálása (kisbetős) # iptables -X test # iptables -t nat -X Saját lánc törlése. Ha nem adunk meg saját lánc nevét, akkor az adott tábla összes láncát kitörli. # iptables -P INPUT DROP Alapértelmezett cépontot, policy-t tudunk megadni egy láncra vonatkozóan # iptables -E test real Saját lánc átnevezése parancsok opciói Opció Hatáskör Leírás, példa -v, --verbose -L, -A, -I, -D, -R -n, --numeric -L --line-number -L -x, --exact -L -c, --set-counters -I, -A, -R A parancs kimenetét hosszú formában adja vissza A parancs kimenetét numerikus formában adja vissza, nem végez pl. DNS névfeloldást az IP címekhez A szabályokat sorszámmal együtt jeleníti meg A számlálókat byte formátumban jeleníti meg, nincs K, M, G jelölés Számlálók beállítása adott értékre (csomagszám, byte) # iptables -A INPUT -s c illeszkedés Az illeszkedési típusokat 5 kategróiába lehet sorolni: Általános illeszkedés: bármilyen szabály esetén használtható TCP illeszkedés: TCP protokol esetén használható UDP illeszkedés: UDPprotokol esetén használható ICMP illeszkedés: ICMP protokol esetén használható Speciális illeszkedés: state, pid-owner, limit-match, stb. Az illeszkedés szabályainak leírásánál használhatjuk a! (negálás, tagadás) kapcsolót is Általános illeszkedés -p, --protokol Illeszkedés -s, --src, --source Leírás, példa # iptables -A INPUT -p tcp A protokolra hivatkozhatunk a nevével (tcp, udp, icmp, all), számával (1, 7, 255, 0=ALL), melyek az /etc/protokols file-ban vannak leírva. A protokolokat vesszıvel elválasztva felsorolhatjuk, vagy használhatjuk az ALL jelölést, ami minden protokolra illeszkedik. # iptables -A INPUT -p tcp,udp # iptables -A FORWARD -s /24 A forrás IP címet/tartományt tudjuk leírni, formák:

50 50 -s egy db IP cím -s /24 címtartomány rövid alakban -s / címtartomány hosszú alakban -s! Negálás (tagadás) Ha nem adunk meg forrás IP címet/tartományt, alapértelmezés szerint minden csomag illeszkedik ( /0) # iptables -A FORWARD -s /24 A csomag cél IP címét/tartományát tudjuk leírni, formák: -d, --desc, --destination -i, --in-interface -o, --out-interface -f, --fragment -d egy db IP cím -d /28 címtartomány rövid alakban -d / címtartomány hosszú alakban -d! Negálás (tagadás) # iptables -A FORWARD -i eth0 Az interfész jelölésére szolgál, amin a csomag bejön. Használható Linux interfészek pl.: eth0, eth1,.., ppp0, ppp1,..., stb. Több interfészt is le tudunk vele írni: pl. eth+, ppp+ Csak a következı beépített láncokon használható: INPUT, FORWARD, PREROUTING # iptables -A FORWARD -o eth1 Az interfész jelölésére szolgál, amin a csomag elhagyja a tőzfalat. Az interfészek megnevezése az --in-interface kapcsolóval megegyezı szintaktikájú. Csak a következı beépített láncokon használható: OUPUT, FORWARD, POSTROUTING # iptables -A INPUT -f A töredék csomagokra illeszkedik. Töredék csomag esetén nem tudunk hivatkozni a forrás-cél portokra, ICMP típusra, stb, mivel ezek csak az elsı csomagban jelennek meg TCP illeszkedés Csak TCP adatfolyam jellegő csomagok esetén használható. Minden esetben használnunk kell a -p tcp (--port tcp) kapcsolót. Illeszkedés Leírás, példa # iptables -A INPUT -p tcp --sport 80 Azokat a TCP csomagokat mutatja a példa, melyeknek a forrás portja 80, azaz web szerver generálja ıket. Példák: --sport, --source-port --sport 25 egyszeres portmegadás --sport 22:80 port intervallum --sport :80 port intervallum, alsó port nincs megadva, alapértelmezése 0 --sport 22: port intervallum, felsı port nincs megadva, alapértelmezése sport! 22 negálás

51 51 --dport, --destination-port # iptables -A OUTPUT -p tcp --dport 25 A csomag célportját írja le, szintaktikája tökéletesen megegyezik a --sport szintaktikával. --tcp-flags --syn # iptables -A INPUT -p tcp --tcp-flag SYN,FIN,ACK SYN A TCP csomagban lévı flagek viszgáltatára szolgál. Lehetséges flagek: SYN, ACK, FIN, RST, URG, PSH valamint ALL, NONE --tcp-flag SYN,FIN,ACK(vizsgálandó flagek) SYN(beállított flagek) A fenti példa tehát a csomagok SYN,FIN,ACK flageket vizsgálja, és azok illeszkednek rá, melynél a SYN flag be van kapcsolva. # iptables -A INPUT -p tcp --syn Az ipchains idıkbıl maradt meg. Azok a csomagok illeszkednek rá, melynél a SYN bit be van állítva, az ACK,RST nincs. A --tcp-flags SYN,RST,ACK SYN rövidítése. Szerverek felıl érkezı kapcsolatépítı csomagok generálnak ilyet. --tcp-option # iptables -A INPUT -p tcp --tcp-option UDP illeszkedés Csak UDP csomagok esetén használható. Minden esetben használnunk kell a -p udp (--port udp) kapcsolót. Illeszkedés --sport, --source-port --dport, --destination-port Leírás, példa # iptables -A INPUT -p udp --sport 53 Az UDP csomag forrás portját írja le, szintaktikája tökéletesen megegyezik a TCP illeszkedés --sport szintaktikával. # iptables -A OUTPUT -p udp --dport 53 Az UDP csomag cél portját írja le, szintaktikája tökéletesen megegyezik a TCP illeszkedés --dport szintaktikával ICMP illeszkedés Csak ICMP csomagok esetén használható. Minden esetben használnunk kell a -p icmp (--port icmp) kapcsolót. Az ICMP csomagok nem használnak port azonosítást, a csomag típusát a fejlécben lévı icmp-type mezı mondja meg. --icmp-type Illeszkedés Leírás, példa # iptables -A INPUT -p icmp --icmp-type 8 Az ICMP csomagtípusokat megkaphatjuk az iptables helpjébıl # iptables -p icmp --help Explicit illeszkedés Explicit illeszkedésmegadása minden esetben a "-m, --match" kapcsolóval történik, amit az illeszkedés neve követ. -m limit: limit illeszkedés Megadhatjuk, hogy adott idı intervallumban az adott szabályra maximum hány illeszkedés következhet be. A többi illeszkedı csomagot eldobja. illeszkedés --limit csomag/intervallum Leírás, példa # iptables -A INPUT -m limit --limit 3/sec A példa másodpercenként 3 bejövı illeszkedést engedélyez. Az intervallumnál megadható: sec, min, hour. --limit-burst # iptables -A INPUT -m limit --limit-burst 5 -m mac: fizikai cím (MAC) illeszkedés

52 52 illeszkedés --mac-source XX:XX:XX:XX:XX:XX Leírás, példa # iptables -A INPUT -m mac --mac-source 00:00:00:00:00:01 Ellenırízhetjük vele, hogy az adott csomag milyen (helyi Ethernet hálózaton generált) generált fizikai címet használ. Csak a beépített INPUT, FORWARD, PREROUTING láncokon használható. # iptables -A FORWARD -s! m mac --mac-source \ 11:22:33:44:55:01 -j DROP Az adott IP címő, de nem megfelelı fizikai címő csomagokat eldobjuk. -m mark: csomag jelölés A mange (-t mangle) táblában használható. Adott szabályra illeszkedı csomagokat meg tudunk vele jelölni, s aztán a megjelölt csomagokat felhasználhatjuk speciális routolási, sávszélesség szőkítési célpontokra. illeszkedés --mark érték[/mask] Leírás, példa # iptables -t mangle -A INPUT -m mark --mark 1 Az érték 32 biten térolt egész szám, maximuma 2^32 ( ) lehet. -m multiport: multiport illeszkedés --source-port illeszkedés Leírás, példa # iptables -A INPUT -p tcp -m multiport --source-port 22,53,80,110 Többszörös portilleszkedést valósíthatunk meg vele. Nem port tartományt kér, mint a hagyományos port illeszkedés, hanem vesszıvel elválasztott port listát (maximum 15 db). --destination-port # iptables -A INPUT -p tcp -m multiport --destination-port 22,53,80,110 --port # iptables -A INPUT -p tcp -m multiport --port 22,53,80,110 Szintaktikája ugyanaz, mint a fenti 2 portmeghatározásnak, viszont a --port használata esetén a forrás és cél port ugyanaz. 80-as portrój jön 80-asra megy. -m owner: tulajdonos illeszkedés A helyileg generált (a tőzfalról kiinduló) csomagra alkalmazható, a csomagot létrehozó procesz tulajdonosát, csoportját, PID-jét tudjuk jellemezni. Csak az OUTPUT láncon érvényes. illeszkedés --uid-owner --gid-owner --pid-owner --sid-owner Leírás, példa # iptables -A OUTPUT -m owner --uid-owner 500 A csomagot létrehozó procesz UID-ja. # iptables -A OUTPUT -m owner --gid-owner 100 A csomagot létrehozó procesz GID-ja. # iptables -A OUTPUT -m owner --pid-owner 78 A csomagot létrehozó procesz PID-je. # iptables -A OUTPUT -m owner --sid-owner 100 A csomagot létrehozó procesz SID-je. -m state: állapot illeszkedés A kernel kapcsolatkövetı (connection tracking) kódjával mőködik együtt. A kapcsolatkövetı rendszer a csomag állapotát 4 módon értelmezi: - NEW: új kapcsolat felépítésére irányuló kérés - ESTABLISHED: már felépített kapcsolat, mindkét irányban láthatók érvényes csomagok - RELATED:új kapcsolat felépítésére irányul, ami egy már felépített kapcsolathoz csatlakozik (pl. FTP adat) - INVALID:érvénytelen kapcsolat Részletes példák a kapcsolat követés fejezetben olvashatók. illeszkedés Leírás, példa

53 53 --sate NEW,ESTABLISHED,RELATED,INVALID # iptables -A OUTPUT -m state --state \ NEW,RELATED,ESTABLISHED -j ACCEPT # iptables -A INPUT -m state --state \ RELATED,ESTABLISHED -j ACCEPT -m TOS: Type Of Sercice (Szolgáltatás Típusa) illeszkedés Az IP fejlécben lévı TOS 8 bites érték illeszkedését vizsgálhatjuk vele. A TOS lehetséges értékei (iptables -m tos -h) - Minimize-Delay 16 (0x10) - Maximize-Throughput 8 (0x08) - Maximize-Reliability 4 (0x04) - Minimize-Cost 2 (0x02) - Normal-Service 0 (0x00) illeszkedés Leírás, példa --tos érték # iptables -A INPUT -p tcp -m tos --tos 0x08 -m TTL: Time To Live (Élettartam) illeszkedés A TTL az IP fejlécben lévı 8 bites érték, minden esetben csökken eggyel, amikor a csomag áthalad egy routeren. Amikor a csomagban a TTL 0 lesz, a csomag lejár, s ezután a router eldobja a csomagot. Ezzel elkerülehetı, hogy IP csomagok "bolyonjanak" az Interneten, céltalanul. - Minimize-Delay 16 (0x10) - Maximize-Throughput 8 (0x08) - Maximize-Reliability 4 (0x04) - Minimize-Cost 2 (0x02) - Normal-Service 0 (0x00) illeszkedés Leírás, példa --ttl érték # iptables -A OUTPUT -m ttl --ttl 60 Azokat a csomagok illeszkednek a fenti szabályra, melyeknél a TTL érték Célpont/Ugrás A célpont/ugrás azt mondja meg, mit tegyen a KERNEL, ha a csomag illeszkedik az adott szabályra. "Ugrás" esetén a KERNEL egy általunk definiált láncra ugrik, és ezt a láncot kezdi bejárni. Saját új láncot a -N kapcsolóval hozhatunk létre. # iptables -N tcp_packets étrehoztunk egy saját láncot, melynek a neve tcp_packets. # iptables -A INPUT -p tcp -j tcp_packets Bejövő TCP csomag esetém a tcp_packets nevő saját láncra kerül a vezérlés és a csomag bejárja a lánc összes szabályát. Ha a saját lánc végére érünk, akkor visszakerül a vezérlés arra a beépített láncra, ahonnan indult (INPUT). Ha a saját láncon belül valahol elfogadjuk a csomagot (ACCEPT), akkor befejezıdik a saját lánc bejárása, sıt a kiinduló láncra is vonatkozóan is elfogadottnak tekintjük a csomagot. Más táblák más láncait azonban továbbra is bejárja a csomag. A "Célpont" azt a tevékenységet írja le, amit a KERNEL végrehajt illeszkedés esetén. Például elfogadhatjuk (ACCEPT) vagy eldobhatjuk (DROP) a csomagot. Néhány "Célpont" esetén a lánc és a saját lánc bejárása befejezıdik, mint ahogy ezt a fenti példa leírja. Ilyen az ACCEPT és a DROP. Más "Célpontok" végrehejtanak valamilyen mőveletet, majd dovább folyik az adott lánc, saját lánc bejárása. Jó példa ezekre a LOG, ULOG, TOS célpont. Ezek a célpontok naplózzák, megjelölik a csomagokat, majd a ugyannak a láncnak a következı szabálya értékeli ki a csomagot. Szintaktika: -j Célpont/Ugrás [opció] ACCEPT Használat: -j ACCEPT, nincs opció megadására lehetıség. Amennyiban a szabály kiértékelıdik és igaz, ACCEPT célpont esetén megszőnik az aktuális láncnak valamint ugyannak a tábla láncainak a bejárása, a csomag engedélyezett. Lehetséges van azonban például egy másik tábla szabálya esetén a csomagot eldobni.

54 DROP Használat: -j DROP, nincs opció megadására lehetıség. Amint a neve is jelzi, a célpont eldobja a csomagot. Semmilyen további további információt (hibaüzenetet) nem nyújt a csomaggal kapcsolatban, ami néha káros lehet, ilyenkor használjuk a REJECT célpontot. A csomag eldobása után minden lánc minden táblájának kiértékelése megszőnik REJECT Használat: -j REJECT [opciók] A DROP célponthoz hasonlóan szintén eldobja a csomagot, azonban egy hibaüzenet is visszaküld. Csak az INPUT, OUTPUT, FORWARD láncokon használható. A visszaküldött hibaüzenet az opció beállításával állíthatjuk be. Opció Példa --reject-with # iptables -A INPUT -p TCP --dport 22 -j REJECT --reject-with tcp-reset A fenti példa a tőzfal 22-es portjára érkezı TCP csomagokat eldobja "tcp-reset" hibaüzenettel. Hibaüzenetek típusai: Magyarázat icmp-net-unreachable icmp-host-unreachable icmp-port-unreachable icmp-proto-unreachable icmp-net-prohibited icmp-host-prohibited Alapértelmezés: icmp-port-unreachable DNAT A DNAT célpont cél (destination) NAT esetekben használatos, ilyenkor a csomag fejlécében lévı cél IP cím kerül módosításra. Tipikus felhasználási terület, amikor a publikus IP címő tőzfal mögött privát IP címő alkalmazás szerverek (WWW, FTP, mail, stb.) vannak, és a tőzfal az adott portjára érkezı kéréseket bedobja a privát címő alkalmazás szervernek. Csak a nat tábla OUTPUT és PREROUTING láncain használható. Használat -j DNAT --to[-destionation] Példa # iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination A példa azt mutatja, hogy a tőzfal 80-as TCP portjára érkezı kéréseket a es belsı gépre továbbítja, megváltoztatja a csomag cél IP címét. A DNAT használata: Magyarázat --to-destination A cél IP címet adjuk meg --to-destination IP címtartományt adunk meg. Ilyenkor a tőzfal véletlenszerően választja ki a cél IP címeket, egyfajta erıforrás elosztást (load balance) végez. --to-destination :80 A cél IP címet és portszámot adunk meg. A cél IP adott portjára dobja a kérést. Alapértelmezésben arra a belsı portra dobja, ami az eredeti dport volt. --to-destination : Port tartomámyt adunk meg. Nyilván ilyenkor a DNAT elıtt is port tartományt kell meghatároznunk. Figyeljünk arra, hogy DNAT esetén csak akkor használhatunk portot megadást, ha a kérés TCP, vagy UDP jellegő (-p tcp / -p udp) SNAT Az SNAT célpont forrás (source) NAT esetekben használatos, ilyenkor a csomag fejlécében lévı forrás IP cím kerül

55 55 módosításra. Tőzfal mögött privát IP hálózaton lévı kliensek Internet kapcsolata valósítható így meg, az Internet felé irányuló csomag forrás IP címet a tőzfal a saját publikus címére cseréli ki, így a csomagok az Interneten is életképesek lesznek. Csak a nat tábla POSTROUTING láncán használható. Használat -j SNAT --to[-source] Példa # iptables -t nat -A POSTROUTING -s /24 -o eth0 -j SNAT --to-source A példa azt mutatja, hogy a tőzfal a belsı /24 privát hálózaton kimenı csomagok IP címeit a saját publikus címére írja át. A SNAT használata: Magyarázat --to-source A forrás IP címet adjuk meg --to-source IP címtartományt adunk meg! --to-source : Port tartomámyt adunk meg MASQUERADE A MASQUERADE hasonló célokat szolgál, mint az elızıleg említett SNAT célpont. A lényeges különbség az, hogy míg az SNAT-nál konkrétan tudnunk kell a kimenı csomagok IP címét (--to-source), addig a MASQUERADE esetén elegendı a kimenı interfészre hivatkoznunk. Tipikusan dinamikusan felépülı kapcsolatok (PPP, DHCP) esetén használatos, tehát amikor a kimenı interfész IP címe folyamatosan változik. Csak a nat tábla POSTROUTING láncán használható. Opció Példa --to-ports # iptables -t nat -A POSTROUTING -s /24 -o ppp0 -j MASQUERADE A példa azt mutatja, hogy a tőzfal a belsı /24 privát hálózat, ppp0-án kimenı csomagok IP címeit a ppp0 interfész IP címére írja át. Magyarázat --to-ports 1024:30000 Az alapértelmezett cél porttartományt módosíthatjuk. Fontos, hogy egy szabályban az interfészre akkor is tudunk hivatkozni, ha még nem létezik. Igy tudunk hivatkozni pl. a ppp0-ra, még mielıtt a PPP kapcsolat felépülne REDIRECT A REDIRECT célpont adatfolyamokat, csomagokat irányít át magán a tőzfal gépen. Gyakorlati példa a transparens proxy: a tőzfal gépen proxy (squid) is fut, s az összes tőzfalon átmenı, 80-as (HTTP) portra irányuló kérést a helyi proxy portra (3128) irányítunk át. Ha nem a tőzfal gépen fut a proxy, akkor a DNAT-t kell használnunk. A REDIRECT célpont csak a PREROUTING és az OUTPUT láncokon használható, a nat táblán. Opció --to-ports Példa # iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports LOG A LOG célpont használata esetén naplózhatjuk a csomagokat, részletes információt kaphatunk ezáltal róluk, ami jól felhasználható hibavizsgálatra. A naplózás a KERNEL syslogd daemon segítségével történik.

56 56 Példa # iptables -A INPUT -s p tcp --dport 22 -j LOG Opciók --log-level Naplózás szintje, hasonlóan adható meg. mint a syslog.conf-ban --log-prefix elıtag Minden bejegyzés a syslog-ba ezzel az elıtaggal kezdıdik --log-tcp-sequence A TCP szekvencia számot is naplózza --log-tcp-options Naplózza a TCP opciót --log-ip-options Naplózza az IP opciót ULOG MARK Csomagjelölésre használhatjuk, a mangle táblán. A jelölt csomagokat ezután felhasználhatjuk az iproute2 valamilyek funkciójában: advanced routing (routing tábla módosítása), vagy sávsélesszég szabályozásra (traffic control). Opció --set-mark Példa # iptables -t mangle -A PREROUTING -s j MARK --set-mark 2 Magyarázat A példa szerint a IP cím felıl jövı csomagot 2-vel jelöljük, aztán a késıbbiekben azt a csomagot az iproute2 funkcióival szétválogathatjuk TTL TOS MIRROR QUEUE RETURN 3. Esettanulmányok Az alábbi példákon megpróbálom szemléltetni, hogyan tudjuk az ügyfeleink számára az Internet kapcsolatunkat megosztani. Alapvetıen 2 fajtája van a kapcsolat megosztásoknak: Alkalmazás szintő Csomagszintő 3.1 Proxy szerver Alkalmazás szintő kapcsolatmegosztás Ilyenkor egy speciális program, proxy (vagy meghatalmazott) szolgálja ki a kliens gépeket. Az adott protokolra irányuló kérés a proxy felé továbbítódik, a proxy lekéri az információt az eredeti helyrıl, majd az eredményt a kliens felé továbbítja. Példa: - squid: WWW, FTP, gopher proxy Elınye a proxyzásnak, hogy sokrétőbben tudja kontrolálni a kliens gép felıl érkezı kéréseket (ACL), a választ cache-eli, gyorsítja a kapcsolatot. Hátránya, hogy minden protokolra speciális proxy szervert kell használni, és rendszerint a kliens oldalon beállítani (kivéve transparens proxy). 3.2 Csomagszintő megoldás (NAT, MASQUERADE) Csomagszintő kapcsolatmegosztás

57 57 Ebben az esetben a csomagok áthaladnak a tőzfal gépen (a kliensek szempontjából gateway), a tőzfal az IP csomagok forrás címét a sajátjára cseréli (pl. SNAT) és a csomagok az Interneten már életképesek lesznek. Példa: - ipchains 2.2.X KERNEL - iptables 2.4.X KERNEL Elınye, hogy (majdnem) minden protokolt támogat, kliens oldalon csak az átjárót kell beállítani. Hátránya, hogy a proxy-hoz képest csekélyebb mértékben tudjuk kontrolálni a kliens gépeket. Példa: # iptables -t nat -A POSTROUTING -s /24 -o ppp0 -j MASQUERADE 3.3 Transparens proxy A csomagszintő és alkalmazás szintő megoldásokat használhatjuk együtt is. Ennek egy jó példája a transparens (átlátszó) proxy, amikor a tőzfalra érkezı http (80-as) portra jövı kéréseket átírányítjuk a proxy szerverre. Kliens oldalon így nem kell semmit beállítani, s nincs lehetıség a proxy megkerülésére. 1. példa: a proxy NEM a tőzfal gépen fut (DNAT) # iptables -A PREROTUNG -p tcp --dport 80 -j DNAT --to-destination : példa: a proxy a tőzfal gépen fut (REDIRECT) # iptables -A PREROTUNG -p tcp --dport 80 -j REDIRECT --to-ports Kapcsolat követés (connection tracking) A kapcsolatkövetés a netfilter/iptables csomag újdonsága. Segítségével a tőzfal képes egy adott csomag adatait memóritáblákban rögzíteni, információt nyerve az adott kapcsolat állapotáról. Egy kapcsolat 4 állapotba sorolható: NEW: új kapcsolat felépítésére irányuló kérés ESTABLISHED: már felépített kapcsolat, mindkét irányban láthatók érvényes csomagok RELATED:új kapcsolat felépítésére irányul, ami egy már felépített kapcsolathoz csatlakozik (pl. már felépült FTP kacsolat esetén adatátitelre (FTP-data) kerül sor) INVALID:érvénytelen kapcsolat Az ún "kapcsolatkövetı" tőzfalakkal sokkal nagyobb biztonságot lehet elérni. Például ha alapértelmezett szabálynak minden láncon eldobjuk a csomagokat, akkor a tőzfalról induló, oda érkezı, átmenı csomagok mind tiltva lesznek. Hibavizsgálatra, bizonyos portok engedélyezésére új szabályokat kell hozzáadnunk, amivel (akaratlanul) rést hagyhatunk a tőzfalunkon. Hogyan mőködik a kapcsolatkövetés? TCP protokol A TCP kapcsolat 3 irányú kézfogással kezdıdik. Elıször a kliens egy szinkronizáló (SYN) kérést küld a szerver felé. A szerver jóváhagyó és szinkronozáló kérést (SYN+ACK) küld vissza a kliensnek, egy végsı jóváhagyó csomag jön majd a klienstıl (SYN). Példa: iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP

58 58 # A tőzfalra csak a már felépített, érvényes kapcsolatokat engedjük iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # A tőzfalról indíthatunk új kapcsolatokat is iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT A fenti példával beállítottuk, hogy a tőzfalunkra kívülrıl nem kezdeményezhetı új kapcsolat (azaz minden port zárva van), míg a tőzfalról tetszıleges új kérés ( ping, ssh, FTP, stb.) indítható. 5. Példa scriptek 5.1 Egyszerő tőzfal Az elsı példa egy ún. egyszerő tőzfalat mutat be. A tőzfal gép közvetlenül kapcsolódik az Internetre (PPP, ADSL, mikrohullám, stb) eth0, a kliensek a tőzfal gép mögött helyzekednek el, eth1. Megvalósítandó feladat: kliens gépek Internet kapcsolatának biztosítása kliens gépek védelme tőzfal gép védelme tőzfal adminisztrálása SSH-n keresztül a belsı hálózatról #!/bin/sh # Változók beállítása INET_IFACE="eth0" INET_IP=" " LAN_IFACE="eth1" LAN_IP=" /24" # Alapértelmezések beállítása iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # A tőzfalra csak a már felépített, érvényes kapcsolatokat engedjük iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # SSH kapcsolat engedélyzése a belsı gépekrıl iptables -A INPUT -s $LAN_IP -i eth1 -p tcp --dport 22 -j ACCEPT # A tőzfalról indíthatunk új kapcsolatokat is iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # A tőzfalon át a belsı háló felé csak a már felépített, érvényes kapcsolatokat engedjük iptables -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT # A tőzfalon át a belsı háló felıl kezdeményezett új kapcsolatokat is engedjük iptables -A FORWARD -i $LAN_IFACE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # Belsı haló felıl érkezı csomagok forrás címének átírása (SNAT) iptables -t nat -A POSTROUTING -o $INET_IFACE -s $LAN_IP -j SNAT --to-source $INET_IP 5.2 Összetett tőzfal

59 59 Az elızı példa egy ún. DMZ-vel (Demilatarizált Zóna) bıvült. Itt publikus Internet szolgáltatást biztosító szerverek vannak: web, FTP, DNS, mail (SMTP,POP3). Megoldandó feladatok: kliens gépek Internet kapcsolatának biztosítása kliens gépek, DMZ, tőzfal védelme tőzfal, DMZ adminisztrálása SSH-n keresztül a belsı hálózatról DMZ-ben lévı szolgáltatások elérése kintrıl Csak a tőzfal rendelkezik publikus IP címmel ( ). A DMZ a tőzfal elsı ethernet interfészén van (eth1), /24 -es privát címtartományt használ. A kliens gépek a tőzfal második belsı kártyáján vannak (eth2), számukra a /24 -es címtartományból osztunk ki címeket. #!/bin/sh # Változók beállítása INET_IFACE="eth0" INET_IP=" " LAN_IFACE="eth1" LAN_IP=" /24" # Alapértelmezések beállítása iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # A tőzfalra csak a már felépített, érvényes kapcsolatokat engedjük iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # SSH kapcsolat engedélyzése a belsı gépekrıl iptables -A INPUT -s $LAN_IP -i eth1 -p tcp --dport 22 -j ACCEPT iptables -A FORWARD -s $LAN_IP -d $DMZ_IP -p tcp --dport 22 -j ACCEPT # A tőzfalról indíthatunk új kapcsolatokat is iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # A tőzfalon át a belsı háló felé csak a már felépített, érvényes kapcsolatokat engedjük iptables -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT # A tőzfalon át a belsı háló felıl kezdeményezett új kapcsolatokat is engedjük iptables -A FORWARD -i $LAN_IFACE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i $DMZ_IFACE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # Belsı haló felıl érkezı csomagok forrás címének átírása (SNAT) iptables -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

60 60 Forgalom korlátozás (traffic shaping) A Linux kifinomult eszközökkel rendelkezik a sávszélesség menedzselésére (angolul Traffic Control). Számos módszer létezik a hálózati forgalom osztályozására, prioritásának módosítására és korlátozására mind a feltöltési mind a letöltési irányban. A fentiek megvalósításához 2 dolog szükésges: QoS Linux kerneltámogatás Az alap debian gyári kernel modulként tartalmazza a QoS támogatást iproute2 csomag Az idevágó legfontosabb angol nyelvő dokumentáció a LARTC (Linux Advanced Routing & Traffic Control HOWTO). iproute2 Az iproute2 csomag Alexey Kuznetsov nevéhez főzıdik. Telepítsük fel debian csomagból. # apt-get install iproute2 Az iproute2 nemcsak a QoS megvalósítására szolgáló parancsokat tartalmazza, hanem a hálózati interfészek konfigrálására és routingra is használható (ifconfig, route). # ip link show 1: lo: <LOOPBACK,UP> mtu qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:df:bf:72 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0a:cd:07:08:5a brd ff:ff:ff:ff:ff:ff 69: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3 link/ppp # ip addr show 1: lo: <LOOPBACK,UP> mtu qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet /8 scope host lo 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:df:bf:72 brd ff:ff:ff:ff:ff:ff 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0a:cd:07:08:5a brd ff:ff:ff:ff:ff:ff inet /24 brd scope global eth1 inet /24 brd scope global eth1:0 inet /24 brd scope global eth1:1 69: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3 link/ppp inet peer /32 scope global ppp0 # ip route show dev ppp0 proto kernel scope link src /24 dev eth1 proto kernel scope link src /24 dev eth1 proto kernel scope link src /24 dev eth1 proto kernel scope link src default via dev ppp0 Alapfogalmak A komplex konfigurációk megértéséhez szükséges, hogy a legfontosabb fogalmakat tisztázzuk. Queueing Discipline (qdisc)

61 61 Az az algoritmus, mely a hálózati interfészen definált queue-t leírja, beleértve a bejövı (ingress) vagy kimenı (egress) forgalmat. root qdisc A root (gyökér) qdisc az eszközhöz rendelt qdisc. Classless qdisc Osztály nélküli qdisc, itt nincsenek konfigurálható alosztályok Classful qdisc Osztállyal rendelkezı qdisc. Alosztályokat tartalmazhat, melyek lehetnek osztály nélküli qdisc-ek, vagy újabb osztállyal rendelkezı qdisc-ek. Classes Az osztállyal rendelkezı qdiscben sok-sok osztály lehet, melyek mindegyike a ún. belsı osztály. Az osztály szülıje vagy egy qdisc vagy egy másik osztály. A levél (leaf) osztály egy gyermek nélküli osztály. Ehhez pontosan 1 db qdisc rendelıdik. Ez a qdisc felelıs azért, hogy errıl a levél osztályról adatokat küldjön. Amikor létrehozol egy ilyen osztályt, alapértelmezésben egy fifo qdisc rendelıdik hozzá. Amikor egy gyermek osztályt hozol létre alatta, akkor ez a qdisc törlıdik. A fifo qdisc lecserélhetı testzıleges más qdisc-re is, akár egy classful qdisc-re is. Classifier Osztályozó. Minden osztállyal rendelkezı qdisc-hez meg kell határozni, hogy melyik osztálynak kell csomagot küldenie. Ez az osztályozó feladata. Filter Szőrı. Az osztályozás szőrıkkel történik. A szőrı feltételeket definálja, ezzel határozza meg, az adott osztályba milyen hálózati forgalom sorolandó. Scheduling Ütemezés. A qdisc az osztályozás segítségével eldönti, a csomagoknak milyen sorrendben kell az interfészt elhagyni. Az ütemezést gyakran újrarendezésnek is nevezik. Shaping A csomagok késleltetésének a folyamata, így azok nem a maximális sebességgel hagyjál el az interfészt. Shaping a kimenı forgalmat befolyásolja. Másként mondva a csomagok eldobását is jelenti, s ezzel lassítja a hálózati forgalmat. Policing A csomagok késleltetése vagy eldobása azért, hogy a forgalom a konfigurált sávszélességi tartományban maradjon. Linuxon, a policy csak a csomagok eldobását jelenti, nem a késleltetését - nincs 'ingress queue'. Sávszélesség menedzsment Queue alapokon (Queuing discipline)