Informatika | UNIX / Linux » Deim Ágoston - Utazás a Postfix körül

Kiskapu Kft. Minden jog fenntartva Szaktekintély Utazás a Postfix körül (1. rész) Kezdetben vala a Sendmail. Majd érkezett a Qmail És lám, itt van a Postfix A két korábbi rendszer már régen ismert, kiforrott, a Postfixre azonban most kezdenek felfigyelni. A cikksorozat elsõ részében bemutatjuk az írót és a program felépítését. Wietse Venema: a Programozó Mikor Isten a programozót teremtette, valószínûleg Venemára gondolt. A kódok tiszták, a programok felépítése átgondolt és logikus. Tekintsük át, milyen programok fûzõdnek a nevéhez A TCT, azaz a The Coroners Toolkit. E programon Dan Farmer-rel együtt dolgoztak A programmal betörés után kísérelhetjük meg felderíteni annak menetét. Használata nem egyszerû, de megéri megtanulni A következõ a Satan rendszerátvizsgáló eszköz, mely nemcsak a hibát mutatja meg nekünk, hanem elhárítására megoldást is javasol. Ma már kicsit idejétmúlt, a Nessus nagyobb támogatottságot

élvez
http://wwwnessusorg Azután a TCP Wrapper, mely minden Linux-változatban megtalálható program, segítségével szabályozhatjuk a hálózati szolgáltatások elérését csomagszûrõ vagy alkalmazásszintû tûzfal nélkül. És a rengeteg kis – fõleg Solaris-rendszerre írt – programon kívül a postfix. A felsorolt programok természetébõl látható, hogy az író nem sorolható a kezdõk közé, és rendkívül foglalkoztatja a biztonság témaköre. (snapshot) és a teljes kiadást (release). A pillanatfelvételek olyan programrészleteket és programokat tartalmaznak, melyeket a szerzõ még nem tart véglegesnek, míg a kiadás már a hivatalos változatot, ebbõl hiányoznak a kísérleti jellegû vagy a nem százszázalékosan kidolgozott programok. A pillanatfelvétel-változatokról egy rövid megjegyzés: Venema a saját levelezõkiszolgálójára is ezeket telepíti. A programok ezen állapotbeli üzembiztonságát sok másik program megirigyelhetné. A

rendszert úgy tervezték, hogy a távoli hálózatokkal a lehetõ legkevesebb modul érintkezzen, azok pedig a legkisebb jogosultsági szinttel rendelkezzenek. Aki megpróbál egy Postfix-alapú levelezõrendszert feltörni, annak több szinten kell keresztülverekednie magát, mire egy olyan programhoz jut, ami rendszergazdai jogosultságokkal fut. A programokat és a rendszer felépítését részletesen az 1 ábra mutatja be, ennek segítségével kövessük egy levél fogadását. • Ez a kis program gyakorlatilag egy burkoló (wrapper), a sendmailt helyettesíti, hogy az ahhoz megírt programok helyi kéréseit átfordítsa a postfix által is értelmezhetõ hívásokká, és letegye azt az elõírt könyvtárba. Ha a könyvtár mindenki által írható (world writeable), akkor egyedül is meg tudja ezt tenni, ha azonban csak egy adott csoport számára elérhetõ – az alapértelmezett csoport a maildrop – akkor a postdrop programot használja erre a célra, ami szintén a

postfix rendszer része. A Postfix gondolatvilága Amikor Venema elhatározta, hogy létrehozza a szerinte lehetõ legbiztonságosabb és leggyorsabb levelezõkiszolgálót, végignézte az addig megírt kiszolgálóprogramokat, majd összesítette azok elõnyeit és hátrányait. A következõ célt tûzte ki: az új kiszolgálónak legyen olyan sok szolgáltatása, mint a Sendmailnek, de túlbonyolított beállítások nélkül. Továbbá bizonyuljon legalább olyan biztonságosnak, mint a Qmail. És végül legyen a leggyorsabb Elmondhatjuk, hogy egyedülálló mû született Felépítését tekintve a Postfix moduláris, minden szolgáltatást külön programrész hajt végre, a jogosultságok pedig a lehetõ legalacsonyabb szintre kerültek. A rendszert két fõ beállítófájlon keresztül tudjuk módosítani, felépítésüket nagyon könnyû megérteni. A programváltozat a következõ állapotokat ismeri: a pillanatfelvételt local sendmail program adattábla maildrop

pickup Internet smtpd RBL access sendmail • pickup Begyûjti a leveleket a maildrop könyvtárból és átadja õket a cleanup programnak (magyarázatát lásd késõbb). • smtpd Fogadja a belsõ hálózaton vagy az Interneten keresztül érkezõ leveleket és különbözõ ellenõrzések után átadja azt a cleanup programnak. Itt tudjuk elõírni, hogy vizsgálja meg: a küldõ fél nyitott továbbító-e (open-relay – mindenki tud rajta keresztül levelet küldeni akárhova, a levélszemetelõk kedvenc célpontja), vagy sem. rewrite .forward resolve local mailbox incoming active qmgr smtp Internet canonical virtual deferred relocated pipe UUCP ect. Bejövõ levelek ellenõrzése Linuxvilág aliases cleanup könyvtár 66 transport Ellenõrzi, hogy nem tiltottuk-e ki a küldõt más módon, például olyan táblázatokat használva, amelyek a küldõre vonatkoznak, akár hálózati cím, egész tartománynév vagy küldõ személy szerint. De

itt akár engedélyezhetjük azt is, hogy elfogadjuk a levelet egy olyan levelezõkiszolgálótól, amelyik benne van a nyitott továbbítókat nyilvántartó adatbázisban. • cleanup • Ellenõrzi a levél fejlécét, hogy megfelel-e az elõírásoknak: a címzett megtalálható-e a rendszeren, kell-e valamilyen mûveletet végrehajtani a levél fejlécén – például a címzett nevének átírását –, esetleg meg kell-e hívnia a trivialrewrite programot. Ha végzett, akkor „lerakja” – fájlba menti – az üzenetet az incoming sorba (queue). Ebbe a sorba kerülnek tehát azok a levelek, melyeket a kiszolgáló elfogadott. smtp A nem helyi felhasználók számára továbbítja az üzeneteket. Tehát ha én az ago@lsc.hu címrõl akarok levelet küldeni az info@linuxvilag.hu címre, akkor az én kiszolgálóm ezzel kapcsolódik a Linuxvilág kiszolgálójához A távoli rendszerekkel csak smtp protokollon keresztül tartja a kapcsolatot (figyelem: nem az egész

rendszer, csak ez a részprogram!). pipe Más vagy eltérõ típusú rendszernek továbbítja az üzeneteket, de még a helyi rendszeren. Tehát én például egy adatbázisba továbbítom a leveleket, melynek szerver része fogadja a leveleket, letárolja azt, majd késõbb elküldi azokat. Leggyakoribb alkalmazása, ha UUCP-n keresztül továbbítjuk a leveleket, használhatjuk azonban ezen keresztül az lmtp protokollt ismerõ programokat is. Az lmtp protokollt használja például a Cyrus-IMAP rendszere is Ezek után a levél remélhetõleg kézbesítésre került. Ha ez mégsem történt volna meg, akkor visszapattan. Ennek kétféle Szükség esetén átírja a levél fejlécét, oka lehet: elsõként a levél nem felelt meg és visszaadja azt a cleanup progvalamilyen feltételnek és Postfixünk soha ramnak. A programot a qmgr, többé nem fog próbálkozni az elküldésével. azaz a „sorkezelõ” is meg tudja hívni. • qmgr Ezt okozhatja a levél tartalma, a küldõ

személye Az incoming sorból áthelyezi az vagy más is, például a címzett már nem találüzeneteket az activ sorba, valamint ható meg a fogadó kiszolgálón. A második felügyeli a levél sorsát. Az activ sorból szintén nem túl szerencsés eset, ha a levelet kerülnek elküldésre a levelek helyileg csak átmenetileg nem tudjuk elküldeni, vagy távolra. A sor mérete korlátozott, például a fogadó levelezõkiszolgáló nehogy túlterheljék a kiszolgálót, idõleges hibája miatt. Ekkor a levél deferred jelzõt kap, és a rendszer olyan módon például, hogy túl sok adott idõközönként, illetve idõtartamig levelet próbálnak vele elküldetni, és így nem marad elég memória az megpróbálja elküldeni. Azokról a levelekrõl, amelyeket visszautasítottak, egyéb tevékenységekre, vagy egy bejegyzést készít a bounce éppen csak a levelek fogadására. Wietse Venema, a Programozó program a bounce nevû sorba, majd a A qmgr arra is felügyel, hogy azok a

levelek, melyeket elõször próbál levél eredetijét vagy annak egy részét elküldeni – akár helyileg, akár távolra –, elsõbbséget élvezzenek visszaküldi a feladónak, kiegészítve azt a hiba okával. A bounce sor azokkal szemben, melyeket nem sikerült elõször elküldeni, és nem tárolja el a leveleket! Ha a levelet csak idõlegesen utasította ezért késõbbi továbbításra várnak. A levelek innen ahhoz a progvissza a fogadó fél, akkor egy bejegyzés kerül a defer sorba, a levelet ramhoz kerülnek, amit a továbbítás megkövetel. Ezek a local, magát pedig a deferred sorban helyezi el. Ezt a helyzetet szintén smtp és a pipe programok. A Postfix pillanatfelvételeiben a bounce program kezeli le. elérhetõ még a virtual is, erre azonban a cikksorozat késõbbi Van egy program, amihez hasonlót eddig egyetlen más levelezõrendszernél sem láttam, a master démon, amely mindig ott fut a háttérrészében térek ki. ben. Ez felügyeli az összes többi

démont, a rendszer állapotát, és • local nem engedi, hogy a rendszert alkotó programok „elvaduljanak” és A helyi felhasználók számára fogadja a leveleket, ellenõrzi megállásra vagy szolgáltatásmegtagadásra kényszerítsék a rendszert. a .forward fájlok meglétét, valamint az alias adatbázist Ha túl messzire merészkednének, akkor visszafogja õket. Mivel ez A .forward fájlokat használjuk arra, ha egy programnak akarvezérli az összes többit, és a Postfix modularitása megengedi, könnyû juk elküldeni a levelet, vagy másik címre próbáljuk azt továbbíolyan kiszolgálót készíteni, amelyik csak küldeni tud. tani. A rendszer az alábbi üzenettároló formátumokat ismeri: A következõ részben olyan rendszert állítunk be, melynek teljes a mbox és Maildir. A kettõ közötti különbségrõl egy következõ szolgáltatáskínálata, visszautasítja a levélszemetelõk küldeményeit, alkalommal írok. és nem engedi, hogy kiszolgálónkat

nyitott továbbítóként használják. A .forward fájlon keresztül a vezérlést más programoknak tudjuk adni, például a procmail-nek, bár a local önmagában Deim Ágoston (ago@lsc.hu) is képes erre. Az alias adatbázist arra használjuk, amire a neve Kedveli a sört, szereti a futást és imádja is utal: neveket leképezünk más nevekre. Jó példa erre a KisFerenc Szabó Lõrinc verseit. Nem hisz vakon egyik kisf névre alakítása, amit már akármelyik unixos rendszer elfogad rendszerben sem. Vonzódik a BSD-hez is – gyanúm szerint a windowsos rendszerek is hasonló névleképeTagja az LME-nek és a MBE-nek. Mottója: zéssel oldják meg ezt a helyzetet. A cikksorozat következõ részéa gép nem lehet fontosabb az embernél ben ezt is részletesebben ismertetem majd. • trivial-rewrite www.linuxvilaghu 2001. június–július 67 Kiskapu Kft. Minden jog fenntartva • Szaktekintély Kiskapu Kft. Minden jog fenntartva Szaktekintély Utazás a Postfix

körül (2. rész) Az elõzõ részben megismertük a Postfix szerkezetét, a levélfogadást és -továbbítást. Az elmélet után hasznos, ha tudásunkat a gyakorlatban is kipróbáljuk. E lsõ lépésként – mint mindig – telepítjük az alkalmazást. Erre két lehetõségünk is nyílik: vagy egy csomagkezelõt használunk, vagy pedig forráscsomagból rakjuk fel az alkalmazást. A csomagkezelõvel telepített változatok elõnyei közé sorolhatjuk, hogy sok beépített foltot (patch) tartalmaznak vagy az alapfordítástól eltérõ kapcsolókkal fordították (szerepel benne például a MySQLvagy OpenLDAP-támogatás). Ekkor ugyanis nem kell feltenni az adott program header és include fájljait, amelyek a terjesztésekben általában a csomagnév-dev csomagban szerepelnek, például: openldap-dev. Másik elõnye, hogy így szükségtelen fordítóprogramokat telepíteni gépünkre, ami külön hasznos, ha csak egy kicsit is gondolunk a biztonságra. Elvégre minden bit

segít! A forráscsomagokból telepített változatok kedvezõ tulajdonsága, hogy az alkalmazások közül mindig a legfrissebbet használhatjuk, valamint a C fordító segítségével finomhangolni tudjuk a binárist, illetve csak olyan támogatás kerül a binárisba harmadik fél programjához, amilyet szeretnénk. Így a postfix telepítésekor nem kell felraknunk például az openldap csomagot, mert nem igényeljük, hogy az LDAP-alapú címtárszolgáltatásokat használja. Megoldás lehet, ha mi magunk készítünk deb vagy rpm csomagot a forrásból, esetleg egy másik gépen fordítjuk le a forrást, és a célgépre a binárisokat csupán átmásoljuk. Mi azonban most a legegyszerûbb megoldásokhoz folyamodunk: elõször megnézzük a csomagkezelõvel történõ telepítést a Debian- és RedHat-rendszeren. Debian (vagy deb-alapú): # apt-get install postfix vagy # dpkg -i postfix 0.019991231pl11-1deb RedHat (vagy rpm-alapú): # rpm -Uvh postfix-20010202-4.i386rpm A

Debian Potatóban láthatóan még a régebbi változat szerepel, és a RedHat sem tud lépést tartani Wietse Venemával. A postfix legújabb változata a snapshot-20010714. A forrásból ezt fogjuk a lehetõ legegyszerûbb módon telepíteni. Elõször is látogassunk el a postfix honlapjára, a
http://www.postfixorg címre, keressük meg a Downloads pontot és válasszunk kiszolgálót. Két lehetõség áll elõttünk: vagy az utolsó hivatalos – jelenleg a Postfix Release 20010228 névre hallgató –, vagy a pillanatfelvétel-változatot (snapshot) – a cikkírás idõpontjában Postfix Snapshot 20010714 – töltjük le. Ha ezt megtettük, csomagoljuk ki a forrást a következõ módon (feltételezzük, hogy a fájl neve snapshot20010714.targz): # tar xvfz snapshot-20010714.targz -C
/usr/local/src Ez az /usr/local/src könyvtár alatt egy snapshot-20010714 nevû könyvtárat hoz létre. Amikor ez is megtörtént, akkor lépjünk be a könyvtárba és olvassuk el a

számunkra érdekes README fájlokat. Mivel jelenleg az alaprendszert telepítjük, ezt a lépést kihagyhatjuk. A következõ lépés a forrás lefordítása bináris állománnyá. A mûveletet a szokásostól eltérõen nem a configure paranccsal kezdjük, hanem egyenesen a make parancshoz fordulunk – mindenfajta kapcsoló és beállítás nélkül: # useradd -d /var/spool/postfix -s /bin/false
postfix Ezzel hozzáadtuk a rendszerhez a postfix nevû felhasználót, aki nem tud bejelentkezni, saját könyvtárnak pedig a program által használt könyvtárat adtuk meg, bár megadhattunk volna nem létezõ könyvtárat és héjat is (a /bin/false is csak akkor létezik, ha szerepel a /etc/shells fájlban). Mivel nem mindenki által írható (worldwriteable) sort fogunk használni a nem SMTP-kapcsolaton keresztül érkezõ levelek fogadására, egy maildrop csoportot is létre kell hoznunk: # groupadd maildrop Ezután kiadjuk a # make install parancsot, ez elkezdi a

telepítést. Ezzel egyenértékû a következõ parancs: # sh INSTALL.sh ugyanis a make install is ezt a parancsállományt hívja meg. Ekkor kérdésekkel kerülünk szembe, ezek nagy részére alkalmazhatjuk a felkínált lehetõségeket. Nézzük sorban: install root: [/] – Arra kíváncsi, hogy mi lesz a gyökérkönyvtár. A Unix-alapú rendszereken ez a / (perjel), azaz a gyökérkönyvtár. tempdir: [/usr/local/src/snapshot-20010714] – Ez adja meg, hogy a telepítés közben szükséges átmeneti tárolóhely hol legyen. config directory: [/etc/postfix] – A beállítófájlok helye. daemon directory: [/usr/lib/postfix] – A Postfixet alkotó démonok helye. command directory: [/usr/sbin] – Hol lesznek azok a parancsok, amelyek a Postfixet vezérlik. queue directory: [/var/spool/postfix] – A Postfix sorai, ahol a levelek feldolgozás közben tárolódnak. sendmail path: [/usr/lib/sendmail] – A Postfix Sendmail programja. newaliases path: [/usr/bin/newaliases] – A

Postfix Newaliases programja (az utóbbi kettõ használatáról még késõbb szólunk). mailq path: [/usr/bin/mailq] – A mailq program helye a rendszerben. mail owner: [postfix] – A Postfix sorainak (queue) tulajdonosa. Ha az elõbb nem Postfix-felhasználót adtuk hozzá, akkor annak a nevét kell ide beírni, akit héj és saját könyvtár nélkül létrehoztunk. setgid: [no] – Mindenki által írható (world-writeable) könyvtár, amelybe a helyileg – a Postfix Sendmail binárisán keresztül – küldött levelek kerülnek vagy pedig a könyvtár által megadott csoporthoz tartozik. Ha az adott csoport tudja csak írni a könyvtárat, akkor úgynevezett csoportjoggal (setgid) rendelkezõ program alkalmazására nyílik lehetõségünk. Ehhez a Sendmail program a Postdrop programot használja a levelek beillesztésére Ajánlott a szigorított postázás, ezért adtuk hozzá a rendszerhez a telepítés elején a maildropcsoportot. Tehát itt adjuk meg a

maildrop-csoportot, a képernyõn pedig a következõket kell látnunk: setgid:[no] maildrop manpages:[/usr/local/man] Ha mindezekkel végeztünk, a telepítés befejezõdik és a # make 54 Most megvárjuk, amíg az összes forrásfájl lefordítódik, majd a postfix futtatásához szükséges felhasználókat adjuk hozzá a rendszerhez: Linuxvilág 2. lista Az /etc/shells tartalma # /etc/shells: valid login shells /bin/bash /bin/csh /bin/sh /usr/bin/ksh /usr/bin/tcsh /bin/sash /bin/zsh /bin/false Az /etc/adduser.conf vonatkozó része # /etc/adduser.conf: `adduser configuration # See adduser(8) and adduser.conf(5) for full # documentation. # The DSHELL variable specifies the default # login shell on your # system. DSHELL=/bin/false # postfix start paranccsal tudjuk indítani az alkalmazást. Ne ijedjünk meg! Amikor legelõször indítjuk el a rendszert, a postfix az addig nem létezõ alkönyvtárakat a neki fenntartott helyen hozza létre – ez alapértelmezésben a

/var/spool/postfix –, ezek alkotják majd a sorokat. Ezt a folyamatot mutatja be az 1. lista (a 15 CD Magazin/Postfix könyvtárában található) A postfix minden indulásnál ellenõrzi, hogy léteznek-e a számára szükséges könyvtárak. Amennyiben nem, akkor létrehozza õket Ha elindult a rendszer és egyetlen naplófájlban sem jelent meg hiba – fõleg a /var/log/messages és /var/log/mail.log fájlokat nézzük át –, akkor állítsuk le a rendszert addig, amíg be nem állítjuk. Nézzük meg, hogy mi lesz a célunk: • A felhasználókat felvesszük a rendszerre, de héj nélkül. • Beállítjuk a kiszolgáló tulajdonságait: a nevét, illetve hogy melyik névtartománynak (domain) nyújt szolgáltatást. Az elsõ feladatot könnyû végrehajtani, Debian-rendszeren meg kell keresni a /etc/shells fájlt és egy sorba írjuk bele a következõt: /bin/false – ezzel felvettük az érvényes héjak közé. Elértük, hogy bár a felhasználó szerepel a rendszeren,

tehát levelet is tud fogadni, nem tud a rendszerre belépni. A második lépés, hogy átszerkesztjük a /etc/adduser.conf fájl tartalmát Keressük meg a DSHELL=/bin/bash sort és cseréljük ki azt az alábbira: DSHELL=/bin/false Ha ezzel végeztünk, elkezdhetjük beállítani a rendszert. A démonok viselkedését a master.cf fájl tartalma határozza meg, mely a sorozatunk elõzõ részében ismertetett master démont irányítja A kiszolgáló tulajdonságait alapértelmezésben a /etc/postfix/maincf-ben találjuk meg, most ezzel foglalkozunk. Elsõ dolgunk, hogy beállítsuk, hol is találhatók meg a levéltároló sorok, a programok és a démonok, valamint a jogosultságok. Ha szabályszerûen telepítettünk, akkor ezekhez a sorokhoz nem is kell nyúlnunk: # a sorok helye queue directory = /var/spool/postfix # a vezérlõ programok helye command directory = /usr/sbin # a postfix démonjainak helye daemon directory = /usr/lib/postfix www.linuxvilaghu # ki a sorok

tulajdonosa, azaz ki kezeli a sorokat mail owner = postfix A következõ sornál érdemes elidõzni. Lehet, hogy felhasználóink egyéni fájlokat hozhatnak létre saját könyvtárukban. Ha ebben egy .forward fájlt helyeznek el, akkor a bejövõ levelet az itt megadott címre tudják továbbítani vagy egy programnak továbbadni a rendszeren. Minket ez utóbbi érdekel A következõ értéknél beállított felhasználó jogosultságaival fog végrehajtódni a forward fájlon keresztül meghívott program Ezt biztonsági megfontolásokból állítsuk minél alacsonyabb szintre. A nobody felhasználó megfelelõ erre a szerepre, elvégre nem szeretnénk, hogy egy olyan parancsfájlnak adja át a felhasználó a levelet, ami például a levél tartalmát hajtja végre – abban pedig az rm -rf / szerepel és mindezt a rendszergazda jogaival teszi –, igaz? A postfix-et vagy más kiemelt jogosultságú felhasználót, illetve felhasználónevet ne állítsunk be! default privs =

nobody Ekkor minden héjprogram a nobody jogosultságaival fog futni, ami a .forward fájlból hívódik meg A következõ sor adja meg a gép teljes nevét, például: myhostname= mailserver.linuxvilaghu A mydomain érték pedig a tartományt adja meg: mydomain= linuxvilag.hu Ha helyileg (rendszeren belül) keletkezik egy levél, programból vagy felhasználó által, akkor a myorigin értékét veszi alapul. Itt már látható, hogy a Postfix az ismert értékeket más paramétereknél változóként képes kezelni. Itt a myorigin értéke a linuxvilaghu lesz: myorigin = $mydomain Az inet interfaces = all egyelõre maradhat a helyén, ugyanis ez határozza meg, hogy mely IP-címekre fogadunk el levelet. Az all mindegyiken elfogadja az SMTP-kapcsolatot. A következõ számban már néhány trükköt is elsajátíthatunk. A következõ érték adja meg, hogy mely gépnevekhez tartozó leveleket dolgozzon fel a rendszer. Ne soroljuk fel a virtuális tartományokat – azok majd egy

késõbbiekben tárgyalandó érték feladatait képezik, amelynek használatával a következõ számban ismerkedünk meg. mydestination = $myhostname,
localhost.$mydomain A tökéletes beállítás az, ha gépünknek csak ez az egy neve van. alias maps = hash:/etc/aliases alias database = hash:/etc/aliases A fenti két adattábla közül az elsõt csak a Postfix, a másodikat más programok is alkalmazhatják. Itt éppen közös adatbázist használnak Ha az alias fájlon bármit változtatunk, akkor ki kell adni a newaliases parancsot. Az utolsó fontos érték, ami ahhoz szükséges, hogy egyszerû, de mégis biztonságos és gyors levelezõkiszolgálót kapjunk, a mynetworks. A mynetworks értékbe kerülnek azok a hálózatok, ahonnan a küldés engedélyezett. mynetworks = 127.000/8 19216810/24 Ez abban az esetben igaz, ha a helyi hálózat – amely elõtt a kiszolgáló található – a 192.16800-s címeket használja Fontos megjegyezni, hogy a 127.000/8 címtartományt,

tehát a saját gépet se hagyjuk ki! A változtatások megtétele és a Postfix elindítása után a rendszer máris használható. A következõ részben egy kisebb, nem állandó kapcsolattal rendelkezõ iroda szükségleteinek kielégítésével és virtuális tartományok kezelésével ismerkedhetünk meg. Deim Ágoston (ago@lsc.hu) Kedveli a sört, szereti a futást és imádja Szabó Lõrinc verseit. Nem hisz vakon egyik rendszerben sem. Vonzódik a BSD-hez is Tagja az LME-nek és a MBE-nek. Mottója: a gép nem lehet fontosabb az embernél. 2001. augusztus 55 Kiskapu Kft. Minden jog fenntartva Szaktekintély Kiskapu Kft. Minden jog fenntartva Szaktekintély Postfix-csemegék (3. rész) A Postfix alapvetõ beállításai után kóstoljunk bele az ínyencségekbe is. T Tekintsük úgy, hogy a tévében jó kis sorozatok epizódjait nézzük – ugyanis mire minden lehetõséget végigpróbálunk, csaknem annyi idõ telik el, mintha egy nagyot tévéztünk volna.

Elsõ epizódunk: a webkiszolgálók Tételezzük fel, hogy adott egy webkiszolgáló. Ha egy kiszolgálón csak webkiszolgálónak kellene futnia, semmi keresnivalója nem lenne ott egy levelezõkiszolgálónak. De vajon miként kerülnek ki a levelek? Az olyan nem moduláris felépítésû kiszolgálókkal, mint a Sendmail vagy az Exim, biztosan érdekes feladat ezt megoldani, a Postfix azonban képes arra, hogy a különbözõ levelezési szolgáltatások egymás nélkül is kitûnõen tudjanak mûködni. A mi célunk az, hogy csak a webkiszolgáló vagy a naplófigyelõ programok – például a Swatch (lásd még Linuxvilág, 2001. augusztus, 46 oldal) – tudjanak jelentést küldeni, azaz csak tõlük fogadjunk leveleket Ehhez szükséges lépésként rá kell beszélni a Postfixet, hogy a 25-ös kapun (a kiszolgálók ezen a kapun keresztül kapják a leveleket) csak a 127.001-es címrõl fogadjon el kapcsolatot Ehhez a /etc/postfix/maincf fájlban keressük meg az inet

interfaces kezdetû sort, majd változtassuk meg az értékét (ez alapbeállításban all) localhost vagy 127.001 értékre: inet interfacels = 127.001 Milyen elõnnyel bír ez más megoldásokhoz képest? Ha a kiszolgáló levélfogadását csomagszûrõ tûzfallal akadályozzuk meg, az pásztázó programmal könnyen felderíthetõ. Látszik, hogy a kapu nyitott és a kapcsolat szûrt. A mi célunk azonban az, hogy tudomást se szerezzenek róla Ha választható megoldásként a kiszolgálót más kapun (porton) indítjuk, akkor azt az összes kaput átvizsgáló pásztázás ugyancsak könnyen felderítheti. Nézzük meg azonban a különbséget az 1. képen, ha a Postfix szolgáltatását használjuk: a felderített kapuk között a levélfogadás nem jelenik meg. Második epizódunk: SMTP démon nélkül Az elõzõ részben leírt viselkedésmódot tovább fejleszthetjük. Egyáltalán nem fogadunk levelet az smtpd-n (a Postfix 25-ös kapuján figyelõ démonon) keresztül,

csak a helyi, fájlba írt leveleket továbbítjuk. A leveleket írhatja ember, de program is Miért lehet erre szükség? Tegyük fel, hogy teljesen kényszeresek vagyunk (bár egy barátom szerint olyan nem létezik, hogy valaki túlságosan paranoid). Félünk attól, hogy valaki mégis megtudja, hogy a gépen levelezõkiszolgáló van, és a csomagszûrõ tûzfalat sem mi állítottuk be, hanem egy nem túl hozzáértõ „szaki”. Számítógépünk hálózati kapcsolón (switch) vagy jelelosztón (hub) osztozik egy vagy több olyan számítógéppel, amelyet feltörtek, mondjuk a legutóbbi bind hiba miatt. Mivel a gép rendszergazdája a csomagszûrést rosszul állította be, a hálózati kártya felõl bejövõ kapcsolatokat is elfogadja a 127.001-es forráscímrõl (ez azonban valós körülmények között lehetetlen). Az egyetlen lehetõség ekkor az, ha kikapcsoljuk az smtpd-t. Könnyen megtehetjük, csak ismernünk kell hozzá a Postfix szerkezetét. Az összes

levelezéssel kapcsolatos démont a master program felügyeli. Ebbõl pedig az következik, hogy amirõl nem tud, az nem is mûködik. A megoldás így roppant egyszerû: a /etc/postfix/master.cf fájlban keressük meg az smtpd-re vonatkozó sort, és érvénytelenítsük vagy egyszerûen töröljük ki. Egy módosított master.cf fájl tartalma látható az 1 listán 50 Linuxvilág 1. lista Postfix smtpd démon nélkül #smtp pickup cleanup qmgr rewrite bounce defer smtp showq error local inet fifo unix fifo unix unix unix unix unix unix unix n n n n - n n n 60 300 - 1 0 1 0 0 - smtpd pickup cleanup qmgr trivial-rewrite bounce bounce smtp showq error local A vastagon szedett rész mutatja, hogyan kell az adott sort megjegyzéssé tenni. Harmadik epizódunk: a „nullügyfél” Felépítése hasonló az elõzõéhez, azzal a különbséggel, hogy míg ott lehetõség nyílik a helyi levéltovábbításra, addig itt erre nincsen mód, egyedül az SMTP protokollon

keresztüli küldés engedélyezett. Összefoglalva: a nullügyfél olyan számítógép, amely a leveleket csak küldeni tudja Alkalmazása azokon a kiszolgálókon célravezetõ, amelyeken a levelezés kimerül a levélnek egy másik kiszolgálóra történõ elküldésében. Az elsõ és jelen beállítás közti eltérés, hogy az elõbbinél a rendszergazda helyileg is kaphat levelet, például a webkiszolgálótól, az utóbbinál viszont nem A nullügyfélhez szükséges, hogy Postfixünk tudja, melyik másik kiszolgálót használhatja a levélküldéshez. Ezenkívül minden olyan levelet, amely a géprõl „származik”, úgy kell elküldenünk, hogy ne látszódjon a gép teljes neve (Full Qualified Domain Name). Az utolsó szükséges beállítás a helyi levéltovábbítás tiltása az smtpd mellett. A mastercf és a maincf beállításait a 2. listán láthatjuk Negyedik epizódunk: a kapcsoltvonali elõfizetõ Gyakori eset, hogy csak telefonon keresztüli

internetkapcsolattal rendelkezünk. Ekkor két út közül választhatunk: az elsõ, hogy olyan 2. lista A Postfix beállítása a nullügyfélhez /etc/postfix/main.cf # az elküldött leveleknél mindig a tartománynév # fog látszani a @ jel után # myorigin = $mydomain a tartomány levelezésért # felelõs számítógépét keressük meg, és rajta # keresztül küldjük el a levelet relayhost = $ mydomain /etc/postfix/master.cf #smtp inet n - pickup fifo n n cleanup unix - qmgr fifo n - rewrite unix - bounce unix - defer unix - smtp unix - showq unix n - error unix - #local unix n n 60 300 - 1 0 1 0 0 - smtpd pickup cleanup qmgr trivial-rewrite bounce bounce smtp showq error local A vastagon szedett rész mutatja, hogyan kell az adott sort megjegyzéssé tenni. levelezõprogramot használunk, mely addig gyûjti a leveleket, amíg azt nem mondjuk neki, hogy elküldheti õket. Ennek a megoldásnak elõnye, hogy Postfixünket nem kell beállítani – de akkor mire jó? A

kérdés megválaszolásához ki kell emelnünk a program hátrányát Mi történik akkor, ha elfelejtjük elküldeni a leveleket, és akad köztük nagyon fontos is? Nem biztos, hogy újra tudunk csatlakozni, ha „csak” egyetlen ingyenes internetkapcsolattal (például Freestart, Kiwi) bírunk. Ha azonban helyi kiszolgálót használunk, nincs más dolgunk, csak a rendszer tudtára adni, hogy minden kapcsolatfelépítéskor küldje el a leveleket. A kapcsoltvonali beállításhoz az alábbiakat szükséges tudnunk: ki továbbítja majd a levelet; valamint hogy minden levél, amelyet az Internetre továbbítanánk, bent maradjon-e a sorban (queue). Fontos, hogy a kapcsolatot addig ne bontsuk le, amíg minden levelet legalább egyszer meg nem próbáltunk elküldeni. Ezt egy parancsfájlból fogjuk ellenõrizni. A szükséges Postfix-beállítások magyarázattal a következõk: /etc/postfix/main.cf #az alábbi gépen keresztül küldjük el a #leveleket, ez lehet például a

szolgáltató # smtp-átjárója relayhost = smtp.szolgaltatohu #visszatartjuk az smtp-n keresztül küldendõ #leveleket, amíg nincs kapcsolat defer transports = smtp A kimenõ sor önmûködõ kiürítésére parancsfájlt hívunk meg abból a fájlból, amely a vonalas (ppp) kapcsolat felépülése után hajtódik végre. A Debian-rendszer alatt a végrehajtódó parancsállományokat a /etc/ppp/ip-up.d könyvtárban külön fájlokban helyezzük el A parancsfájl neve legyen connect. A connect fájl tartalma a következõképpen nézzen ki (a Postfix GyK alapján, de azt módosítva): #!/bin/sh #kiürítjük a sort www.linuxvilaghu postfix flush # várunk, hogy minden levél közvetítése # elkezdõdjön, azaz egy smtp-kapcsolat # elinduljon a távoli kiszolgálók felé, # várunk 30 másodpercet sleep 30 # Egészen addig fenntartjuk a kapcsolatot, # ameddig minden levelet legalább egyszer # megpróbáltunk elküldeni, ennek keretében # nem engedélyezzük a poff parancs #

küldését, mentjük más néven, majd # késõbb visszamásoljuk mv /usr/bin/poff /usr/bin/poff.off # amíg új levél tartózkodik a sorban, # addig várunk, mindig 10 másodperccel # növeljük a kapcsolat idejét while mailq | grep ^[^ ]* >/dev/null do sleep 10 done # ha már nincs olyan levél, ami ne # próbált volna kimenni, akkor # visszamásoljuk a poff parancsot és # lezárjuk a kapcsolatot. mv /usr/bin/poff.off /usr/bin/poff
/usr/bin/poff Egyszer nekem szegezték a kérdést, hogy mi történik az alábbi két esetben: 1. Egy rosszindulatú felhasználó olyan parancsfájlt ír, amely a hálózati kapcsolat meglétét ellenõrzi (például egy ping parancs kimenetét vizsgálva), majd ha az él, a leveleket iszonyatos mennyiségben kezdi küldeni, mindehhez egy Perl-modult használva 2. Hálózatba vagyunk kötve, számítógépünk a hálózati és levelezõ átjáró (smart host). Valaki rossz szándéktól vezérelve kapcsolat idején levelekkel kezd minket

bombázni. Úgy tûnik, ilyenkor sosem tudjuk lekapcsolni a vonalat, és a nappali telefonálás nem olcsó mulatság. Megnyugtatok mindenkit, ez nem fordulhat elõ. Miért? Emlékezzünk vissza, hogy a Postfix beállítófájljába beillesztettünk egy olyan sort, amely minden SMTP-kapcsolatot addig késleltet, amíg külön parancsot nem adunk a sor kiürítésére Ilyen parancsot pedig csak rendszergazdai jogosultságú felhasználó vagy az õ jogaival futó parancsfájl képes végrehajtani. (Ha rajtunk kívül más is rendelkezik rendszergazdai jogosultsággal, akkor már mindegy.) Ellenérv lehet, hogy ha hálózaton nem is, de az elsõ módszert alkalmazva helyileg küldhetünk levelet, hiszen nem kell SMTPkapcsolatot használni ahhoz, hogy a Postfix elfogadja a levelet Ez igaz is, használhatjuk a maildrop könyvtárat, de ha nem helyi felhasználónak küldjük a levelet, akkor SMTP-kapcsolaton keresztül kell távoznia, ez pedig késleltetett (deferred) üzemmódban

mûködik. A Postfix modularitása – mint számos más esetben – itt is kisegít bennünket. Ötödik epizódunk: Postfix és MySQL Elõfordulhat, hogy nem szívesen veszünk fel felhasználókat a rendszerbe, még úgy sem, hogy nem létezõ héjprogramjuk (shell) van, például a /bin/false vagy a /dev/null. Az is megeshet, hogy már túl sok – például 10 000 – felhasználónk van, ezért a kiszolgáló mûködése nem hatékony, rendszere esetleg már nem is engedélyezi 2001. szeptember 51 Kiskapu Kft. Minden jog fenntartva Szaktekintély Kiskapu Kft. Minden jog fenntartva Szaktekintély újabb felhasználók felvitelét. Ez esetben eszes megoldásra van szükségünk. Ilyen lehet egy SQLvagy LDAP-kiszolgáló rendszerbe olvasztása Ekkor nemcsak a felhasználók meglétének ellenõrzését végezhetjük el, de lehetõséget biztosíthatunk a vezetõség számára, hogy letiltsa a nem fizetõ ügyfelek azonosítóit, vagy külön kvótákat alkalmazhatunk a

különbözõ elõfizetõi kategóriák felhasználói számára. A lehetõségek száma szinte a végtelenhez közelít: nem lesz olyan feladat a levelezésben, ahol ne tudnánk hasznosítani a központi adatbázist (többszörözés, adatok ki- és visszamentése stb). A Debian következõ, Woody nevû terjesztésében a támogatás már a Postfix-csomagba lesz építve. Addig azonban saját magunknak kell fordítanunk a csomagot, ha azt akarjuk, hogy MySQL-támogatás is legyen. Ehhez az include és header fájlok miatt szükségünk lesz a MySQL fejlesztõi csomagjára. Ha a MySQL-t is forrásból fordítjuk, ezek is felkerülnek a telepítés után. A Postfix fordításával már foglalkoztunk a legelsõ részben. Mivel még mindig nincs configure parancsállomány, a make programnak kell átadni változóként, de csak akkor, amennyiben a programba a MySQL táblaalapú adattárolását is be akarjuk építeni. Ha nem ez az elsõ fordítás, mindenekelõtt takarítsunk egy kicsit:

Látszik tehát, hogy az egész mindössze egy -lz lehetõséggel bõvült. Csak három karakter, de ha nem tudjuk, hogy oda kell rakni, sokat szenvedhetünk, mire rájövünk a hiba okára. A jelenlegi Postfix-terjesztésbõl hiányzik e tény megemlítése, mégis érdemes megnézni a forráscsomagban lévõ MYSQL README fájlt, mert ez a hivatalos leírás, és amennyiben késõbb változtatnak valamin, ott biztosan megtaláljuk ezeket. A csomagban szintén találhatunk egy leírást arról, hogy milyen táblákat kell létrehozni az adatbázis-kiszolgálóban, és milyen formátumban kell kitölteni egy SQL-t használó mapfájlt. Ha ezt követõen ilyen fájlra hivatkozunk, a típusnál a mysql-t kell megadni, ilyen formában: alias maps = mysql:/etc/postfix/mysql-alias.cf Ha ezt a típust szeretnénk a hash helyett alapértelmezetté tenni, akkor a default database type = hash sort a következõre kell cserélni: default database type = mysql # make tidy Ezt követõen adjuk

ki a következõ parancsot: Éjféli híradó: helyi levéltovábbítás
CCARGS=-DHAS MYSQL -I/usr/local/include/mysql
AUXLIBS=/usr/local/lib/mysql/libmysqlclient.a -lm # make -f Makefile.init makefiles A Postfix helyi levéltovábbításra saját helyi programját használja, de bármikor eltérhetünk tõle, erre ad lehetõséget a mailbox command érték. Amíg ennek értéke üres, addig a helyi démon fog végrehajtódni, eltérni csak értékadással lehet. Ha a procmailt akarjuk levéltovábbításra használni, az értéket a maincf-ben állítsuk be rá: Ha a Makefile elkészült a fenti beállításokkal, kiadhatjuk a parancsot: mailbox command = /usr/bin/procmail # make Figyelem! Postfix használata esetén a procmail-nek set-uid bittel kell rendelkeznie! Ez teszi lehetõvé, hogy mindig a címzett felhasználói jogaival tudjon futni és beleírjon a felhasználó postafiókjába. Vigyázat! Ha nem mbox, hanem Maldir/ formátumban (minden levél külön fájlban)

tároljuk a leveleinket, a procmail nem alapbeállításaival fog mûködni. Maildir-be mentéshez használjuk inkább a helyi démont, ami el is készíti a szükséges könyvtárakat, amennyiben még nem léteznek. A szokásos folyamat zajlik le, mindegyik démon külön-külön lefordítódik, és elindíthatjuk a telepítõ és beállító parancsfájlt: # sh INSTALL.sh Ha elindítjuk a Postfixet, a postconf programot használva láthatjuk, hogy a használható adattároló-típusok között megjelent a MySQLtámogatás: # postconf -m nis regexp environ mysql btree unix hash Amennyiben újabb kiadású MySQL-kiszolgálót használunk és csomagból telepítettünk, rendelkeznünk kell a zlib fejlesztõi csomagjával (zlib-dev), ugyanis most már a libmysqlclient.a tárgykönyvtárat a zlib segítségével készítik Ha viszont a MySQL-t forrásból telepítettük, a fordítást megelõzõ beállítóprogram alapértelmezettként a zlib-csomagokat használja. Ekkor az

SQL-támogatás beépítéséhez a Makefile-t a következõképpen kell indítanunk: # make -f Makefile.init makefiles
CCARGS=-DHAS MYSQL -I/usr/local/include/mysql
AUXLIBS=/usr/local/lib/mysql/
libmysqlclient.a -lm -lz 52 Linuxvilág A fogmosás: ha elsõre nem sikerül Mi történik akkor, ha a rendszeren kétféle felhasználó létezik? Egy, aki benne van a /etc/passwd fájlban, és egy, aki viszont nem, mert mondjuk a Cyrus-IMAP saját virtuális felhasználói között található. Ekkor nem a mailbox transport, hanem a fallback transport értéket kell beállítani. Ha a mastercf fájlban létezik például a cyrus bejegyzés (amennyiben nem töröltük ki, alapértelmezésben megtalálható benne), megtehetjük, hogy elõször megpróbáljuk a /etc/passwd-ben megtalálni a felhasználót, majd ha ott nincs, akkor a Cyrusnak átdobni a levelet. Az ehhez szükséges beállítások a /etc/postfix/main.cf-ben találhatók: mailbox command = fallback transport = cyrus

Remélem, mindenkinek sikerült megtalálnia az õt legjobban érdeklõ témát. A következõ alkalommal néhány nem szokványos beállítást, valamint egy irodai rendszer beüzemelését mutatjuk be. Deim Ágoston (ago@lsc.hu) Kedveli a sört, szereti a futást és imádja Szabó Lõrinc verseit. Nem hisz vakon egyik rendszerben sem. Vonzódik a BSD-hez is Tagja az LME-nek és a MBE-nek. Mottója: a gép nem lehet fontosabb az embernél. Kiskapu Kft. Minden jog fenntartva Szaktekintély Postfix-csemegék (4. rész) Folytassuk problémamegoldással: hogyan használjunk két levelezõkiszolgálót felváltva? N emrégiben egy nem átlagos, de nem is túl kirívó nehézséggel fordultak hozzám. A levél írója két postafiókkal rendelkezett, ennek megfelelõen két kiszolgálón keresztül kellett elküldenie a leveleket Saját számítógépén Postfixet futtatott, hogy kétfelé menõ leveleit ott tudja gyûjteni. Kérdése a következõ volt: miként lehetne a

legegyszerûbben megoldani, hogy hol az egyik, hol a másik kiszolgálót használja átjáróként a levelezéshez? A Postfix modularitása és futás közbeni módosíthatósága itt is a segítségünkre volt. Útmutatásaimat követve a levélíró a man-oldalak használatával a feladatot egyszerûen meg tudta oldani. A többi olvasó kedvéért azonban nézzük meg, milyen megoldást javasoltam – feltételezem, a levélíró is hasonló eredményre jutott –, és mely programokat használtam fel. Most azonban nem egy szokványos Postfix-leírás következik, mert parancsfájlírás és egy alkalmazás, a sudo beállítása is szerepel benne. Ezek a feladatmegoldás szerves részei, tehát kihagyhatatlanok, továbbá ismereteink bõvítésére is alkalmasak, hiszen a sudo sokoldalú program, és a parancsfájlok írása is még hasznunkra válhat a késõbbiek folyamán. Remélem, olvasóink örömmel fogadják ezt a kis „mixet”. #!/bin/sh # A programra a GNU GPL

felhasznÆlÆsi # szerzıdØs ØrvØnyes. A felhasznÆlÆsi # szerzıdØs a tovÆbbi rØszletekØrt megtekinthetı # a www.geekfinderhu/licenszekhtml oldalon PARANCS=/usr/sbin/postconf echo "LevØltovÆbb t ÆtÆll tÆsa a k vetkezıre: $1" sudo $PARANCS -e relayhost=$1 echo "A kiszolgÆl ÆtÆll tÆsa megt rtØnt" echo "Az œj levelezıkiszolgÆl : $1" A hozzávalók postfix Szerintem a legjobb levelezõkiszolgáló, a feladat is ennek kapcsán merült fel, így a program megléte feltétele a megoldásnak. sudo Az alkalmazás segítségével a kiszemelt felhasználók rendszergazdai jogosultságot kaphatnak a kijelölt programok futtatására, vagy éppen jogosultságokat vonhatunk meg tõlük. Beállítási állománya a /etc/sudoers, ezt azonban ne szerkesszük kézzel! Nem véletlenül mellékelik hozzá a visudo nevû segédprogramot, amelyben a vi felületét használva szerkeszthetjük a fájlt. A fájl lezárásakor és a kilépéskor ellenõrzi

a formai követelmények betartását, ezzel könnyítve meg a munkánkat. Használjuk bátran! Egy kevéske parancsfájlkészítési ismeret A most megírásra kerülõ parancsállomány nem teljesíti a komoly parancsállományok követelményeit: a hibaellenõrzést (ezt csupán nagyon csekély mértékben támogatja) és az interaktivitást. Egyszerûen adjuk meg az új kiszolgáló nevét, amelyet használni szeretnénk és beállítja. Cserébe öt perc alatt elkészíthetjük, és semmilyen parancsfájlírási gyakorlatot nem igényel. Legelsõ lépésként állítsuk be a leggyakrabban használt levéltovábbító kiszolgálót. Ehhez a /etc/postfix/maincf fájlban keressük meg a relayhost értéket, és ha még nem szerepelne a beállítások között, írjuk bele. /etc/postfix/main.cf: relayhost = mail.szolgaltatohu Csaknem készen is vagyunk, mindössze kedvenc kiszolgálónkkal kell újraolvastatnunk a beállítófájlt: root@localhost# postfix reload Következõ

lépésként írjuk meg a parancsfájlt, amely legyen a /usr/bin/relaychange: 56 Linuxvilág Ez a parancsfájl azonban semmilyen hibaellenõrzést nem végez, egyszerûen csak átveszi a parancs utáni elsõ értéket és megpróbálja végrehajtani. Ha nem jár sikerrel, azt a konzolon látni fogjuk, mert a Postfix programjai a hiba okát is visszaadják. Elemezzük a sorokat! Az elsõ sorban adjuk a rendszer tudtára, hogy ez egy parancsfájl és a végrehajtáshoz a bash segítségét kéri majd. A felhasználási szerzõdés feltételei egyértelmûek. A PARANCS változóban adjuk meg azt az utasítást, amelyikkel a Postfix futási idõben tudja változtatni a beállításait. Ennek használata után tehát már nem szükséges a beállításokat a Postfixszel újraolvastatni! Ennél a parancsfájlnál ez a lépés akár ki is maradhatott volna, hiszen csak egy változóval dolgoztunk, ha azonban a jövõben is szeretnénk parancsfájlokat írni, akkor jó, ha megszokjuk a

változók használatát. A következõ sor közli, hogy éppen mi történik majd A $1 változó a héjprogramok parancsállományaiban a parancs után álló elsõ változót jelöli: az $2 értelemszerûen a másodikat és így tovább. Most érkeztünk el a legfontosabb sorhoz: a sudo-t arra használjuk, hogy végrehajtsa számunkra a parancsot. Mint már említettem, ha valaki ezzel indít egy programot, akkor az úgy fog végrehajtódni, mintha a rendszergazda hajtotta volna végre. Ne keverjük azonban össze a SETUID bittel, ezáltal ugyanis minden felhasználónak lehetõsége nyílna a programot rendszergazdai jogosultságokkal végrehajtani! Így csak a „kiválasztottak” férhetnek hozzá. A sudo kiadása után $PARANCS változóval helyettesítjük be a postconf elérési útját a parancsba, és a -e kapcsolóval sudo /usr/sbin/postconf -e relayhost=mail.szolgaltatohu Ezután már csak a visszajelzések maradtak hátra, amelyek a korábbi sorokat tanulmányozva

egyértelmûek. Fény derül arra is, hogy a parancsállományok túlságosan egyszerûek: ha nem lenne jogosultságunk a mûveletek végrehajtására, akkor is azt írná ki, hogy a kiszolgáló átállítása megtörtént. Jelen esetben minket ez nem érint, mert mindent pontosan beállítunk, a parancsfájlt azonban érdemes továbbfejleszteni. A második lépésben szerkesszük át a /etc/sudoers fájlt. Adjuk ki a visudo parancsot, ekkor a képen (56. oldal) látható látvány fogad bennünket. Cmnd Alias POST=/usr/sbin/postconf Több parancsot az alias után vesszõvel elválasztva lehet írni, például: Cmnd Alias PARANCSOK=/usr/sbin/postconf, /usr/sbin/postfix • A következõ osztályban adhatunk jogosultságokat az egyes személyeknek vagy csoportoknak. A példából a formátuma világosan látszik. Az ALL fenntartott szó, mindenre jogosultságot ad, és mint láthatjuk, a rendszergazdának mindenhez jogosultsága van. Jelenleg felhasználónknak – bár ez minden

gépen érvényes – csak a POST-csoportban lévõ parancsokhoz postconf van használata. Ezekhez azonban nem kell külön jelszót beírnia. Ha azonosítani szeretnénk a felhasználót, a NOPASSWD: lehetõséget hagyjuk el a fájlból – ekkor a rendszer az engedélyezett parancs végrehajtása elõtt jelszót kér a felhasználótól. Mivel otthon vagyunk, nyugodtan megbízhatunk magunkban, élesben azonban a sudoers fájlba sose tegyünk a következõ sorhoz hasonlót: felhasznalonev # sudoers file. # # This file MUST be edited with the ’visudo’
command as root. # # See the sudoers man page for the details
on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification Cmnd Alias POST=/usr/sbin/postconf # User privilege specification root ALL=(ALL) ALL felhasznÆl nØv ALL= NOPASSWD:POST Szerkesszük át a fájlt, hogy a listánkon látható módon nézzen ki. Nézzük végig, mi mit is jelent a listánkban. • a Host

alias sor utáni mezõbe a számítógépek nevei tehetõk, csoportosítva. Jelenleg érdektelen a számunkra, mert csak egyetlen számítógépünk van. • A User alias sor már érdekesebb, mert ha több felhasználónk is létezik, akiknek jogosultságot szeretnénk adni arra, hogy megváltoztassák a levéltovábbító kiszolgálót, akkor csoportba tehetjük õket, és a csoport nevével hivatkozhatunk rájuk. Ez leegyszerûsíti a felügyeletet – a késõbbiek folyamán csak egy nevet kell elvenni vagy hozzáadni a csoporthoz. Nézzünk egy példacsoportot, amely ezt valósítja meg: User Alias RELAY = felhasznalonev1, felhasznalonev2, felhasznalonev3 A továbbiakban elég csak RELAY-ként hivatkozni rájuk. • A Cmnd alias nagyon fontos. Itt szintén hasonlóképpen csoportosíthatjuk a parancsokat, mint a felhasználókat. Egyelõre itt is csak egyetlen utasítás található, ha viszont a csoportosított felhasználók több parancsot is végrehajthatnak, érdemes a

parancsokat is csoportosítani. Itt csupán egy alias-t használunk. www.linuxvilaghu ALL= (ALL) NOPASSWD:ALL Ezzel teljes rendszergazdai jogosultságot adtunk a felhasználónak, amellyel a jelszó használata nélkül is bármikor élhet! Ha megszerzik vagy megfejtik a jelszavát, a rendszer elesett. A szabályok csoportokra is egyszerûen alkalmazhatók. Maradjunk elõzõ példánknál, amelyiknél egy beállítási sor a következõképpen néz ki: RELAY ALL=NOPASSWD:PARANCSOK Tehát a RELAY-csoportba tartozó felhasználók jelszó használata nélkül végrehajthatják a PARANCSOK csoportjába tartozó programokat - mintha õk lennének a rendszergazdák. Lépjünk ki a szerkesztésbõl és mentsük a módosításokat. (az E SC , majd a : billentyû lenyomása után írjuk be: wq és nyomjunk E NTER-t. Ha a fájlba szeretnénk írni, elõször az I betût nyomjuk le, majd a NYÍL billentyûkkel lépegessünk). Most már megvan a parancsfájl, él a sudoers fájl

módosítása, tehát próbáljuk is ki. felhasznalo@localhost$ relaychange mail.szolgaltatohu Level tovabbito atallitasa a kovetkezore: mail.szolgaltatohu A kiszolgalo atallitasa megtortent Az uj levelezo kiszolgalo: mail.szolgaltatohu Ellenõrizzük az eredményt, amihez ismét a postconf programra lesz szükségünk. Adjuk ki a postconf relayhost parancsot, ami visszaadja az eredményt. Figyeljük meg, hogy most hiányzik-e a -e kapcsoló. Ha az eredmény egyezik a kívánttal, hátradõlhetünk és vállon veregethetjük magunkat. Egy másik olvasónk kérésének eleget téve egyik kedvenc Szabó Lõrinc versemet kitettem a
http://www.geekfinderhu/vershtml címre E cikkre a Free Document Licence vonatkozik
http://www.gnuhu/fdlhtml Deim Ágoston (ago@lsc.hu) Kedveli a sört, szereti a futást és imádja Szabó Lõrinc verseit. Nem hisz vakon egyik rendszerben sem. Vonzódik a BSD-hez is Tagja az LME-nek és a MBE-nek. Mottója: a gép nem lehet fontosabb az embernél. 2001.

november 57 Kiskapu Kft. Minden jog fenntartva (szerkesztés (edit)) indítjuk. Az utána álló változót a Postfixnek ismernie kell, tehát a beállítási fájlba illeszthetõnek kell lennie. A levéltovábbító beállítására a realyhost értéket használjuk. A változó értékét a parancs utáni elsõ érték adja meg: $1. A relaychange mailszolgaltatohu parancs kiadása és a behelyettesítések elvégzése után a következõ értéket kapjuk: Szaktekintély Kiskapu Kft. Minden jog fenntartva Dobbantó Postfix és Cyrus Levélkézbesítõ ügynök, IMAP- és POP3-kiszolgáló, valamint virtuális felhasználók. Ez volt a feladat Debian Woody alatt Most egy sör mellett próbálom meg felidézni a nehezét. B eteszem a kedvenc FatBoy-albumomat, hátradõlök a gurulós székben, és diadalittasan mosolygok a monitorra. A munka elsõ megközelítésben nem volt bonyolult, viszont annyi apró részfeladatból állt, hogy úgy érzem, megérdemelten

koccinthatom oda a sörösdobozt a monitor oldalához. Ha te is valami hasonló tett elõtt állsz, de már szeretnél ott tartani, ahol én, ez a cikk neked szól. SMTP és IMAP, POP3 Elõttem már többen kellõ mélységben tárgyalták az említett protokollokat, ezért nem szeretném õket megismételni. Ha idõd engedi, feltétlenül olvasd el Deim Ágoston kapcsolódó cikkeit a Linuxvilág 2001. június–júliusi számától kezdve 2001 novemberéig. Részletesen beszél a Postfixrõl mint MTA-ról, és egy összehasonlító írás erejéig kitér a fõbb IMAP-, illetve POP3-kiszolgálókra. Ez a cikk viszont a türelmetlen rendszergazdáknak íródott, ezért lássuk, mit is takarnak a fenti rövidítések. Az elektronikus levelezés alapvetõen két összetevõbõl áll. Az MTA (Mail Transfer Agent) feladata a levél kézbesítése a hálózat (legyen az helyi vagy maga az Internet) különbözõ részhálózatain keresztül. A MUA (Mail User Agent) pedig az a

levelezõprogram, amit a felhasználó az elektronikus levél fogadására, elkészítésére, illetve postázására használ (pl.: Sylpheed, mutt) Az MTA-k közötti üzenetváltás protokollja az SMTP. Ha minden egyes hálózatba kötött számítógépen lenne egy MTA, akkor itt véget is érne a történet. Ez azonban kivitelezhetetlen és felesleges Kivitelezhetetlen, ha figyelembe veszszük, hogy az Internet használóinak nagy része még mindig nem rendelkezik állandó kapcsolattal és változó IP-címe van. Ugyanakkor felesleges azért, mert egy számítógépet többnyire nem használnak 2–3 embernél többen. Így egy MTA-nak csak 2–3 postaládát kellene kezelnie, ami erõforrás-pazarlás. A megoldás meglehetõsen egyszerû: egy központi gépet kinevezünk levélkiszolgálónak. Állandó kapcsolattal rendelkezik és DNS-rekordja is van, ami név alapján megmondja az IP-címét. Tárolja a beérkezõ leveleket és kézbesíti a kimenõket. A belsõ hálózatra

kötött felhasználók ugyanúgy SMTP-t használva küldenek levelet, csak beállítják az MUA-ban, hogy melyik az SMTP-kiszolgáló. Beérkezõ leveleiket pedig egy külön e célra kifejlesztett protokollon át töltik le a saját gépükre. Ez utóbbi lehet IMAP vagy POP3. Vajon IMAP-ot használjunk vagy POP3-at? Alapvetõ különbség a kettõ között, hogy az IMAP-ot azzal az elképzeléssel fejlesztették ki, hogy a levelek mindig is a központi számítógépen maradnak, és a felhasználók távolról kezelik a leveleiket. Ezzel szemben a POP3 alapvetõen arra szolgál, hogy a felhasználó az összes levelét a saját gépére tölti le, letöltés után pedig törli õket a kiszolgálóról. A válasz tehát ebben a megközelítésben a levelezõkiszolgálón lévõ tárhely függvénye. 58 Linuxvilág Válasszunk egy MTA-t! Legyen mondjuk a Postfix. Miért? Mert megbízható, kellõen moduláris, illetve gyorsan és egyszerûen beállítható. Nekem egy 166 MHz-es

Pentiumra kellett felkönyörögnöm egy ezer felhasználót kiszolgáló rendszert. Határozottan úgy érzem, hogy a Postfix jó választásnak bizonyult, mert nem érkezett panasz a sebességet illetõen. Elõször telepítsd a postfix, postfix-ldap, postfix-pcre és a postfix-doc csomagokat. Akármi is volt eddig az MTA-d, mostantól a Postfix lesz az. A postfix-ldap-ot és postfix-pcre-t a Postfix igényli, ezért kötelezõ õket telepíteni, habár most nem fogjuk egyik elõnyét sem kiaknázni. Az egyik segítségével LDAP-ból lehet venni bizonyos adattáblákat (például az alias táblát), míg a másikkal szabályos kifejezéseket (regular) lehet használni ugyanezekben a táblákban. Megjegyezném, hogy a postfix-doc a leírást nem a /usr/share/doc/postfix-doc, hanem a /usr/share/doc/postfix könyvtár alá telepíti. A telepítés során a General type of configuration? kérdésre az Internet Site – elsõ nekifutásra – jó választás, a finomhangolás így is,

úgy is kézzel fog történni. Ezt meglepõen egyszerû kérdések követik Elõbb a kiszolgáló nevét kérdezi meg, azután azt, hogyha valaki egy egyetlen tagból álló tartománynévre akar levelet küldeni, akkor hozzáragassza-e a saját tartománynevét. Így például a pisti@mail címet egészítse-e ki pisti@mail.cegnevhu-ra Ez akkor lehet érdekes, ha a belsõ hálózaton lévõ felhasználóinknak nincs erejük beírni a teljes címet, amikor a szomszédnak küldenek elektronikus levelet. Ezt követõen olyan tartományneveket kell megadnod, amelyeket a Postfix a sajátjának tekint, vagyis ha valaki a @ után ezt írja be, és a levél eljut ehhez a kiszolgálóhoz, akkor már nem küldi tovább, hanem megtartja. Az alapértelmezés többnyire megfelelõ Az utolsó kérdés azokra az IP-címtartományokra vonatkozik, amelyek SMTP-kiszolgálónak használhatják a Postfixet. Ez jellemzõen a 127.001/8 és a belsõ hálózat Az IP-címet egy / (perjel) után követõ

szám határozza meg, hogy a címbõl hány bit az alhálózati maszk. Ez például 10xxx formájú címeknél nyolc, de 192.168xx esetén tizenhat A debconf sokat segített, de azért maradt még feladat bõven neked is. A /etc/postfix/maincf állományt kell módosítanod, ez a Postfix fõ beállítófájlja. Mivel a Cyrust késõbb arra is használni szeretnénk, hogy a helyi felhasználók leveleit a megfelelõ postafiókban tárolja, a következõ változtatások szükségesek: #mailbox command = procmail -a "$EXTENSION" mailbox transport = cyrus Vagyis megjegyzésbe kell tenni a mailbox command-ot, és helyette fel kell venni a mailbox transport-ot. Ezzel a Postfix kész is, de a java még hátravan, hiszen most jön a Cyrus. Válasszunk IMAP- és POP3-kiszolgálót! Legyen mondjuk Cyrus. Miért? Mert megbízható, többféle hitelesítési módszert támogat, és az ACL-ek (Access Control List) segítségével finoman szabályozhatók a jogosultságok. Az

említett Pentium 166-oson is a Cyrusra esett a választásom. Telepítened kell a cyrus-common, cyrus-admin, tcl8.0 és a tclreadline csomagokat, a cyrus-imapd-t, illetve a cyrus-pop3d-t – attól függõen, hogy melyik protokollt szeretnéd elérhetõvé tenni. A Tcl-csomagok a cyrus-admin végett szükségesek, ugyanis a cyradm nevû felügyeleti felület Tcl-t használ. Ezek mind kérdezés nélkül települnek, úgyhogy kézzel kell egy kicsit varázsolni A cyrus-imapd, illetve a cyrus-pop3d a Cyrus IMAP-et és POP3-at megvalósító moduljai. Mind a kettõ inetd-bõl indul A telepítés során a /etc/inetd.conf a következõ sorokkal egészül ki: pop3 stream tcp /usr/sbin/tcpd imap2 stream tcp /usr/sbin/tcpd nowait cyrus /usr/sbin/pop3d nowait cyrus /usr/sbin/imapd A két modulnak közös beállítóállománya a /etc/imapd.conf Itt a következõ módosítások szükségesek: admins: bela popminpoll: 0 A Cyrus és a PAM Már csak egy feladatod maradt: meg kell

oldanod a felhasználókezelést. Mivel a pwcheck most már PAM-ot használ, csupán keresni kell egy olyan PAM-modult, ami az auth részben használható és a /etc/passwd-tõl eltérõ adatbázist használ. Én elõször a pam userdb modult próbáltam ki, ami a libpam-modules csomag része, vagyis alapból feltelepül. Ez egy tetszõleges Berkeley hash DB állományt képes feldolgozni, ahol a felhasználónevek a kulcsok és a jelszavak az értékek. Ezzel csak az a baj, hogy egyszerû szöveges formában tárolja a jelszavakat, vagyis ha valakinek sikerül megszereznie az állományt, az összes jelszó a birtokába jut Tovább keresgélve ráakadtam a pam pwdfile.so-ra, amellyel egy /etc/passwd-hez hasonló felépítésû állományt használhatunk. Az utóbbi modul a libpam-pwdfile csomag része. Tulajdonképpen egyetlen fájlt tartalmaz, a /lib/security/libpam pwdfileso-t, de ez elég is. A DES és az MD5 titkosítást is támogatja Használatához mindössze a /etc/pamd/cyrus

állományt kell szerkesztened, a következõképpen: #auth required pam unix.so nullok pam pwdfile.so pwdfile auth required /etc/imapd.passwd flock #account required pam unix.so account required pam permit.so Sok PAM-hívõ most legszívesebben a pokolba küldene a Az admins mezõ alapértelmezetten megjegyzésben van, feltétlenül ki kell tölteni, különben nincs olyan felhasználó, aki felügyelhetné a Cyrust a cyradm-on keresztül. A 0-s azonosítójú felhasználót (root) biztonsági szempontból itt nem ajánlott megadni. A Cyrus leírásában azt is megemlítik, hogy a rendszerfelügyelõnek ne hozzunk létre postafiókot A legegyszerûbb egy rendszerben is létezõ, semmilyen egyéb joggal nem rendelkezõ felhasználót admin-nak felvenni. A popminpoll azt az idõt határozza meg percben, amelynek egy felhasználó esetén két bejelentkezés között el kell telnie, ha a POP3-protokollt használja. Az alapértelmezés egy perc, ami éles rendszer esetén jó a nyers

erõ- (brute-force) támadások visszaszorítása érdekében, de amíg építed a kiszolgálót, és azt próbálgatod, hogy mely részei mûködnek, melyek nem, addig nem biztos, hogy ez lesz álmaid netovábbja. Én erre az idõszakra ezt a korlátozást kikapcsoltam. A terjesztésben is megtalálható, a SASL nevû függvénykönyvtárat nélkülözõ Cyrus-változat kétféle hitelesítést támogat: a Kerberos-, illetve a Unix-típusút. A Unix-típusú azonosítás a pwcheck démonnal mûködik. Vagyis nem elég az inetd-t futtatni ahhoz, hogy a Cyrus üzemeljen. A /etc/initd/pwcheck néven található a vezérlõ parancsfájl. A pwcheck démon két változatban található meg a Woodyban. A „standard” változat egy megadott passwd, illetve shadow állománnyal dolgozik. A PAM-os változattal viszont tetszõleges PAM-modult alkalmazhatunk a hitelesítéshez. Ha belenézel a /etc/initd/pwcheck-be, azt láthatod, hogy a futtatandó program neve /usr/sbin/pwcheck. Ez azonban

egy közvetett hivatkozás a /etc/alternatives/pwcheck-re, ami pedig a /usr/sbin/pwcheck standard-re mutat. Ezért, ha a PAM-os változattal szeretnél dolgozni (én ezt ajánlom), akkor a következõt tedd: # rm /etc/alternatives/pwcheck # ln -s /usr/sbin/pwcheck pam /etc/alternatives/pwcheck # /etc/init.d/pwcheck restart www.linuxvilaghu pam permit.so használatáért, de az account részben véleményem szerint nincs szükség semmiféle ellenõrzésre Visszatérve a pam pwdfile-ra: ennek összesen két kapcsolója van A pwdfile-t szóköz után követi a használandó állomány. A flock nem kötelezõ kapcsoló. Engedélyezi a flock() függvény használatát, vagyis bekapcsol egy olyan szerkezetet, amivel megbizonyosodhatsz róla, hogy a megadott adatbázishoz egyidejûleg nem fordul két különbözõ folyamat (lásd man 2 flock). A kapcsolóval ellenkezõ hatást fejt ki a noflock. Ahogy a súgóoldalon is olvashatod, ez a biztosíték csak addig él, amíg az összes

folyamat használja a flock-ot. Ezért a /etc/imapd.passwd-vel nagyon óvatosan kell bánni #!/usr/bin/perl -w use strict; use Fcntl ’:flock’; # A LOCK * Ælland khoz die "HasznÆlat: ".$0" {felhasznÆl } {jelsz } " if $#ARGV != 1; open (PWD,">>/etc/imapd.passwd"); flock(PWD,LOCK EX); # csak Øn hasznÆlhatom az ÆllomÆnyt seek (PWD,0,2); # ha valaki k zben elvitte volna a mutat t my $revord = $ARGV[0].":"; my $salt = join ’’, (’.’,’/’,09,’A’’Z’,’a’’z’)[rand 64, rand 64]; # s lØtrehozÆsa $record .= crypt ($ARGV[1],$salt)"[13] "; print PWD $record; flock (PWD,LOCK UN); # lock kikapcsolÆsa close (PWD); 2003. május 59 Kiskapu Kft. Minden jog fenntartva Dobbantó Kiskapu Kft. Minden jog fenntartva Dobbantó nálót sem ismer meg. Ha megvan az admin, létrehozhatsz mezei felhasználókat is, de ezeknek még nem lesz postafiókjuk. Ugyanis nemcsak a felhasználókat kell

létrehozni, de a postafiókot is. A postafiók létrehozása a cyradm nevû programmal tehetõ meg: #!/usr/bin/perl -w use strict; use IMAP::Admin; die "HasznÆlat: ".$0" {felhasznÆl } " if $#ARGV; my $mb = "user."$ARGV[0]; my $imap = IMAP::Admin->new(’Server’ => ’localhost’, ’Login’ => ’bela’, ’Password’ => ’almasretes’); die $imap->{’Error’} if $imap->create($mb); die $imap->{’Error’} if $imap->set quota($mb,2000); $imap->close; Ahogy a /etc/passwd-t csak vipw-vel szabad szerkeszteni, úgy ezzel is kellõ körültekintéssel kell bánni. Az egyetlen bökkenõ, hogy az állomány formátuma korántsem megszokott, és a passwd-re is csak messzirõl hasonlít: felhasznÆl nØv : titkos tott jelsz [ szÆm ] A szögletes zárójelek közé zárt szám jelzi, hogy milyen algoritmust használtak a jelszó titkosításakor. Akkor 13, ha a Unix crypt() függvényével történt, és 34, ha

MD5-tel. Hogyan hozzunk létre bejegyzéseket az állományban, ügyelve a flock() használatára, és minél kevesebb idõ alatt? A válasz a Perl (1. lista) Azért van szükség a flock() utáni seek()-re, mert a flock() függvény egészen addig nem tér vissza, amíg meg nem szerzi az „exkluzív zárat”. Ha azért nem kapja meg azonnal, mert valaki más már rátette a saját zárát az állományra, akkor megvárja, amíg leveszi róla. Ha a másik folyamat közben a fájlmutatót elvitte az állomány végérõl (hozzáírásra nyitottuk meg), akkor vissza kell tenni. A crypt() függvényt használom titkosításra. Ez két értéket vár: a titkosítatlan szöveget és egy kis sót (salt). A só egy két karakterbõl álló véletlen szöveg. A felhasználó-adatbázis most már feltölthetõ felhasználókkal. Mindenekelõtt vedd fel a felügyelõdet, mert a cyrus most már nem a /etc/passwd-t használja, így jelenleg egyetlen felhasz- 60 Linuxvilág # cyradm localhost

localhost userid: bela localhost password: almasretes localhost> Természetesen az almasretes nem jelenik meg a képernyõn. Itt a legegyszerûbb meghívni a súgót, ez megadja az összes használható parancsot. A pisti felhasználónévhez tartozó postafiókot a cm user.pisti paranccsal lehet létrehozni (a cm a create mailbox rövidítése). Most már nagyon közel vagy a sörhöz. Csakhogy a fõnököd most adott a kezedbe egy hajlékonylemezt. A lemezen található állomány a felhasználóneveket és a jelszavakat tartalmazza, úgy ezret A cyradm ehhez túlságosan is felhasználói beavatkozást igénylõ (interactive). A válasz a Perl Most egy olyan parancsállományt hozunk létre, ami csak egy felhasználónevet vesz át értékként, és létrehozza a megfelelõ postafiókot, sõt még egy két megabájtos tárkorlátot is beállít. Jól hangzik, már csak a megfelelõ Perl modul hiányzik. Telepítsd a libimap-admin-perl csomagot (2 lista). A program magáért

beszél, a $imap objektum {’Error’}* tulajdonsága a legutolsó meghívott elemfüggvény sikerességétõl függõen tartalmaz egy szöveges hibaüzenetet. Jöhet a sör! Az utóbbi két Perl-parancsfájlt használva lehetõségeid már korlátlanok. Bátran írj, ha valami nem úgy mûködik, ahogy leírtam, vagy valamit nem sikerült jól elmagyaráznom. Jó sörözést! A Cyrus és a Postfix programok forráskódjai a 47. CD Magazin/Cyrus könyvtárában találhatóak. Fülöp Balázs (xut@freemail.hu) 18 éves, imádja a Túró Rudit, a Debian Linuxot és a teheneket. Az ELTE Radnóti Miklós Gyakorlóiskola tanulója immár ötödik éve. Kedvenc írója Slawomir Mro ek. Leginkább a számítógépes hálózatok biztonsága érdekli. Szaktekintély Kiskapu Kft. Minden jog fenntartva Postfix kiszolgáló bõvítése Clam Antivirussal Linuxos levélkiszolgálónkat nagyteljesítményû védelmi vonallal felszerelve megvédhetjük a bajtól a sérülékeny rendszereket.

A Linux Journal 2004-es Szerkesztõi Díját a biztonsági eszközök között a ClamAV, egy teljes mértékben szabad és nyílt forrású víruskeresõ kapta, amely ugyan jellemzõen Linuxon fut, ám számos különbözõ géptípus vírusait képes felismerni. (Lásd: Linuxvilág, 2004. szeptemberi szám) Mint Reuven Lerner a díjakról szóló cikkben megjegyezte, a „ClamAV miatt az üzleti víruskeresõ programok tényleg futhatnak a pénzük után” Ez alkalommal szeretném megmutatni, hogy Postfix alapú elektronikus levél átjárónkon hogyan használhatjuk ki a ClamAV tudását. Eközben szó esik majd az Amavisd-newról, errõl a sokoldalú, elektronikus levelek feldolgozására használható démonról, amely létfontosságú összekötõként szolgál a levélkiszolgálók, mint a Postfix és a Sendmail, valamint a leveleket ellenõrzõ eszközök, mint a ClamAV és a SpamAssassin között. A rendszer felépítése A továbbiakban ismertetendõ összeállítás

természetesen nem az egyetlen lehetséges vagy jó lehetõség a ClamAV használatára. Ez ugyanakkor a legelterjedtebb megoldás – mondjuk úgy, jellegzetesnek nevezhetõ. Tegyük fel, van egy SMTP átjárónk, az internet felõl ez fogadja a saját cégünk, szervezetünk számára címzett elektronikus leveleket, a célunk pedig az, hogy az SMTP átjáró elõzetesen ellenõrizze, a levelek nem tartalmaznak-e vírust. (1 ábra) Az átjáró feladata lehet az, hogy a leveleket a helyi postaládákban helyezze el, de belsõ levélkiszolgálónak való továbbításra is beállíthatjuk. A következõkben foglaltak függetlenek a tényleges levéltovábbítási módszertõl. Ha nagy forgalmú rendszert üzemeltetünk, akkor lehetséges, hogy az SMTP átjáró helyett a víruskeresést inkább egy különálló géppel érdemes elvégeztetnünk – az itt ismertetett eszközök ekkor is mûködni fognak. Az egyszerûség kedvéért azonban, illetve igazodva a szokásokhoz, most

tegyük fel, hogy a víruskeresõ magán az SMTP átjárón fut. Levéltovábbító ügynökként (Mail Transfer Agent, MTA) Postfixet használunk, ez ugyanis egy népszerû és biztonságosan futtatható program, továbbá a ClamAV-vel is gond nélkül képes együttmûködni. Csakhogy a Postfix nem tud közvetlenül kapcsolatba lépni a ClamAV-vel, vagy legalábbis ez a kapcsolat nem megbízható. A ClamAV sem jeleskedik az elektronikus levelek 38 Linuxvilág elemzésében, inkább adatfolyamokkal tud dolgozni. Ezért van szükségünk a kisegítõ démonra, az Amavisd-new-ra. Az Amavisd-new szintén ingyenes és nyílt forrású eszköz, létének egyetlen célja az MTA-k, mint a Postfix és a Sendmail, valamint a víruskeresõ és a szemétszûrõ programok, mint a ClamAV és a SpamAssassin közötti tranzakciók közvetítése. Az Amavisd-new egyebek mellett kiválóan teljesít az elektronikus levelek MIME mellékleteinek hagyományos, a keresõk által is érhetõ

adatfájlokká alakításában. Az Amavisd-new démonja, az amavisd számos protokollon keresztül képes kommunikálni, ide értendõ az SMTP és az LMTP elektronikus levéltovábbító protokoll mellett a UNIX foglalatok rendszere is. Ebben az esetben az amavisd-t úgy állítjuk be, hogy a leveleket SMTP-n keresztül, a 10024-es számú TCP kapun át fogadja, annak helyi UNIX foglalatán keresztül lépjen kapcsolatba a ClamAV-vel, majd a levelet és a víruskeresés eredményét a 10025-ös TCP kapun adja tovább a Postfixnek. A leveleknek az SMTP átjárón keresztüli mozgását a 2 ábra szemlélteti A program beszerzése és telepítése A ClamAV és az Amavisd-new egyaránt Perlben íródott, és számos Perl-modultól függ. Mindenkinek javaslom tehát, hogy a két eszköz valamelyik újabb változatának saját terjesztéséhez készült bináris csomagját használja. Még egyszerûbb, ha az apt-get, a Yum vagy az up2date szolgáltatásaira hagyatkozunk, így nem kell

foglalkoznunk a függõségek kézi telepítések során felmerülõ gondjával. A ClamAV webhelye, amellett, hogy itt lelhetõ fel a legújabb ClamAV forráskód is, tartalmaz egy oldalt, amelyen a ClamAV különféle Linux-terjesztésekhez és egyéb operációs rendszerekhez készült bináris csomagjainak elérhetõségét gyûjtötték össze. A Red Hat vagy Fedora terjesztést használók Dag Wieers oldalán (lásd az internetes forrásokat) találnak Yum ágakat és up2date forrásokat, ClamAV-t és Amavisd-new-t egyaránt. Az Amavisd-new weboldalon további Amavisd-new csomagok forrásaira mutató hivatkozásokat is találunk, illetve a legújabb Amavisd-new forráskódot is innen tölthetjük le A ClamAV a sarge kiadása óta a Debian alapcsomagja, az Amavisd-new pedig például a SuSE rendszerekben a 9.1-es kiadás óta szerepel Ha bármelyik összetevõt forráskódból vagy önálló csomagból telepítjük, akkor a Yum, up2date vagy apt-get alapú Szaktekintély

Kiskapu Kft. Minden jog fenntartva tást, márpedig én ezt javaslom, akkor ügyeljünk arra, hogy a TCPSocket és a TCPAddr beállítás megjegyzésben maradjon. Saját Genco csomagomnál a LocalSocket elérési út alapértéke /tmp/clamd volt, amivel az a baj, hogy a /tmp bárki által írható-olvasható. Helyette javaslom a /usr/share/clamav/ clamd.sock elérési út választását, a /usr/ share/clamav engedélyeit pedig állítsuk rwxrwx értékre, vagyis vonjuk meg az egyéb felhasználók olvasási, írási és futtatási jogát. Az 1. kódrészlet utolsó beállítása a User, ez annak a felhasználónak a neve, amelynek fiókjával a clamd-nek indulása után futnia kell. A clamd-t a rootnak kell elindítania, de ha ezt a beállítást kivesszük megjegyzés1. ábra Példa levelezõrendszer 2. ábra A Postfix, az Amavisd-new bõl, majd értéket adunk neki, akkor a clamd és a ClamAV közötti adatáramlás indulás után lefokozza önmagát. A legtöbbünk számára elég

ennyit ismerni megoldással ellentétben nekünk kell ügyelnünk arra, hogy a /etc/clamav.conf fájlból A clamd indítása elõtt ellenõrizzük, az Amavisd-new-hoz tartozó telepítési leírás Prerequisites hogy van-e rendszerünkben fiókja a clamav-nek, és a /etc/ (elõfeltételek) címû részében foglaltakat teljesítsük. Sajnos clamav.conf fájlban szereplõ elérési utakra vonatkozó engea ClamAV telepítésének feltételeit eléggé hiányosan foglaldélyeket megfelelõen beállítottuk-e A fiók csoportjaként ták össze. Ha kétségeink támadtak, semmibe sem kerül saszintén érdemes a clamav-t választani Amint a következõ ját ClamAV RPM-ünk nevével kiadni az részben látni fogjuk, így könnyebben meg tudunk osztani bizonyos erõforrásokat a clamd és az amavisd között. rpm test -iv clamav csomagnév.rpm A /etc/passwd bejegyzése a clamav fiókhoz a következõ: parancsot, így láthatjuk, hogy mi hiányzik még a gépünkrõl. Ha van egy kis

szerencsénk, akkor terjesztésünkhöz elérhetõk a ClamAV és az Amavisd-new használatához szükséges Perl-modulok csomagjai. Amit mégsem találunk, azt a CPANról vagy az egyéb, a saját terjesztésünkhöz készített csomagokkal foglalkozó weboldalak valamelyikérõl tölthetjük le A ClamAV beállítása A ClamAV és az Amavisd-new telepítése után nekiláthatunk a beállítások megadásának. A ClamAV-vel kezdünk, ez az egyszerûbb. A ClamAV beállító fájlja a /etc/clamavconf Nyissuk meg a kedvenc szövegszerkesztõnkkel. Az 1 ábrán azok a beállítások láthatók, amelyeket a legtöbbeknek azonnal meg kell változtatniuk. Az elsõ sor ártatlannak tûnik, de mindenképpen tegyük megjegyzésbe. Ha ezt elmulasztjuk, a clamd nem fog futni A két LogFile. beállítás alapesetben megjegyzésként szerepel Ha engedélyezni akarjuk a naplózást, vegyük ki õket megjegyzésbõl. A naplófájlt mi választjuk ki, maximális mérete LogFileMaxSize, ennek

elérésekor a fájl felülírásra kerül A DatabaseDirectory kulcsfontosságú beállítás. A ClamAV itt tárolja a vírusaláírások adatbázisait, mondhatnánk, az agyát. Az általam telepített ClamAV RPM-ben található clamd démon úgy volt lefordítva, hogy a /usr/share/clamav könyvtárat használta erre a célra, miközben a hozzá mellékelt példa clamav.conf fájlban a /var/lib/clamav érték szerepelt, igaz, megjegyzésbe téve Úgy döntöttem, kiveszem megjegyzésbõl a sort, és /usr/share/clamav értékre módosítom, kerülendõ a félreértéseket. A LocalSocket beállítás azt határozza meg, hogy a clamd melyik foglalaton keresztül tartja a kapcsolatot a külvilággal, jelen esetben az Amavisd-new-val. Ha használjuk ezt a beállíwwwlinuxvilaghu clamav:x:52:52:ClamAV Daemon:/:/bin/false A /etc/group fájl clamav csoportfiókja pedig a következõ: clamav:x:52: Ha a clamd beállításán is túlestünk, elindításához csupán a clamd parancsot kell

kiadnunk. Ha a ClamAV-t bináris csomagból telepítettük, /etc/initd névvel valószínûleg bekerült rendszerükbe a clamd indító parancsfájlja is. Ha így van, akkor ne feledkezzünk el az engedélyezésérõl, így a clamd már a rendszer betöltésekor elindul. Ha a fájl hiányzik, akkor magunknak kell gondoskodnunk a létrehozásáról. Az Amavisd-new beállítása Ahogy a clamd, úgy az amavisd beállításait is egyetlen fájl tárolja, ez a /etc/amavisd.conf Ezzel azonban egy kicsit több munkánk lesz. A 2 kódrészlet saját /etc/amavisdconf fájlom legfontosabb elemeit tartalmazza. A 2. kódrészlet elsõ két beállítása a $daemon user és a $daemon group, ezek az amavisd futtatásához használt felhasználói és csoportfiókot adják meg. Értékük rendre legyen amavis és clamav Mint korábban említettem, szerintem érdemes közös csoportba rendelni az amavisd és a clamd fájljait, így tehát van értelme az amavisd-t is ezzel a csoporttal futtatni. Az

amavishoz tartozó /etc/passwd bejegyzés így néz ki: amavis:x:53:52:Amavisd-new Daemon:/var/amavis:/bin/false A $mydomain szervezetünk tartománynevét adja meg. A $MYHOME, amelyet az amavis fiókjának kezdõkönyvtárára 2005. január 39 Szaktekintély Kiskapu Kft. Minden jog fenntartva kell állítani, az Amavisd-new fájljainak gyökérkönyvtárát határozza meg, ez általában a /var/amavis. Erre a könyvtárra csak a root kapjon írási jogot, és a tulajdonjogot is neki adjuk. A $QUARANTINEDIR annak a könyvtárnak az elérési útja, amelybe az amavisd-vel a karanténba helyezett elektronikus leveleket el szeretnénk helyeztetni. A könyvtár tulajdonosa az amavis felhasználói fiókja legyen, és kizárólag ez kapjon írási jogot hozzá. A $db home, melyet lehetséges, hogy ki kell vennünk megjegyzésbõl, azt határozza meg, hogy az amavisd hol tárolja adatbázisait, például a gyorstárazott keresési eredményeket. A $helpers home az a könyvtár,

amelybe az amavisd saját SpamAssassin beállításait írja, és néhány további apróságot helyez el. Lehetséges, hogy alapesetben a $helpers home megjegyzésként szerepel. A $db home és a $helpers home könyvtárat az amavis felhasználói fiókja birtokolja, és kizárólag általa legyen írható. A $pid file és a $lock file, melyek szintén megjegyzésként kerülhetnek a kezünk alá, az amavisd folyamatazonosító és zárolási fájljának helyét adják meg. A $log level szabja meg, hogy az amavisd naplóüzenetei mennyire legyenek részletesek. Itt 0 - 5 közötti értéket adhatunk meg, ahol az 5 jelenti a legrészletesebb naplózást Az alapérték 0, személyes tapasztalatom szerint a 2-es szint elegendõ adatot szolgáltat, de a naplófájl sem hízik kezelhetetlen méretûre. Alapesetben az amavisd naplóüzeneteit mail erõforrásként a syslog-nak küldi el, vagyis az amavisd és a Postfix naplóüzenetei ugyanarra a helyre kerülnek. A következõ négy

beállítás az amavisd által vírus vagy levélszemét felismerésekor küldött levelekre vonatkozik. A $virus admin az az elektronikus levélcím, amelyre a vírusokról szóló értesítõket kapni fogjuk. Érvényes címnek kell lennie, ha az itt szereplõ érték még nem szerepelne benne, akkor gondoskodjunk a helyi aliases fájl frissítésérõl. A gyakorlatban itt jellemzõen a rendszergazda, vagyis a saját címünk szerepel. Arra is van lehetõség, hogy az amavisd az egyes levelek eredeti címzettjeinek vagy küldõjének küldjön értesítést, ám ezzel csak bosszúságot fogunk okozni másoknak, hiszen a levélszemetek és a vírusos levelek feladójának címe szinte mindig hamis. Jobb tehát, ha lemondunk errõl a lehetõségrõl A $mailfrom notify admin és a $mailfrom notify spamadmin rendre azt a feladócímet adja meg, amellyel az amavisd a vírusokról és a levélszemetekrõl szóló értesítõ leveleket feladja. Ezen a ponton végre elérkeztünk az

amavisd.conf lényegéhez: a ClamAV-hez tartozó víruskeresõ beállításokhoz Nálam az alapértelmezett /etc/amavisdconf fájl a teljes részt megjegyzésbe téve tartalmazta, tehát azzal kezdtem, hogy töröltem a # karaktereket a sorok elejérõl. Szükség esetén tehát ne feledkezzünk meg errõl a lépésrõl. Mindenképpen ellenõrizzük a clamd foglalatának ebben a részben megadott elérési útját. A 2 kódrészletben az alapértelmezett /var/run/clamav/clamd helyett a /usr/share/clamav/clamd.sock elérési út szerepel, ugyanaz, mint amit a /etc/clamav.conf fájlban adtunk meg Ha megfelelõen átírtuk a /etc/amavisd.conf fájlt, és beállítottuk az amavisd könyvtáraira vonatkozó engedélyeket, akkor az amavisd parancsot – kapcsolók nélkül – kiadva indíthatjuk el a programot Ahogy a clamd, úgy lehetséges, hogy 40 Linuxvilág 1. kódrészlet Nem alapértelmezett beállítások a /etc/clamav.conf fájban # Példa LogFile /var/log/clamd.log

LogFileMaxSize 5M DatabaseDirectory /usr/share/clamav LocalSocket /usr/share/clamav/clamd.sock User clamav az amavisd számára is létre kell hoznunk egy indító parancsfájlt. Javaslom, hogy elsõként a clamd-t indítsuk Így elérhetjük, hogy mire az amavisd elindul, addigra a clamd foglalata már jelen legyen. A clamd-hez hasonlóan az amavisd-t is a rootnak kell indítania. A program ezt követõen az amavisdconf fájlban megadott felhasználó és csoport jogosultságaival fut tovább. A Postfix beállításai ClamAV és Amavisd-new démonunk megkapta a kellõ beállításokat, és el is indult. Még ne dõljünk hátra, némi tennivalónk még akad, ugyanis be kell állítanunk a Postfixet a tartalomszûrésre, továbbá frissítenünk kell a ClamAV vírusadatbázisát. Egy fontos megjegyzés: a továbbiakban feltételezem, hogy a Postfix már be van üzemelve, és képes ellátni normál fogadó/továbbító feladatait. Elõször nyissuk meg kedvenc

szövegszerkesztõnkkel a /etc/postfix/master.cf fájlt, majd – amennyiben még nem szerepelnek ott – fûzzük a 3. kódrészletben látható sorokat a fájl végére. Az smtp-amavis rész a Postfix kimenõ, az amavisd-vel SMTP-n keresztül létesített kapcsolataira vonatkozik. Ide a következõ sor tartozik, ezt kell hozzáadnunk a /etc/postfix/main.cf fájlhoz, illetve átírnunk, ha már szerepel benne: content filter = smtp-amavis:[127.001]:10024 Ezzel a sorral arra utasítjuk a Postfixet, hogy a master.cf fájlban megadott smtp-amavis felületen keresztül minden bejövõ levelet küldjön ki a 127001 címre, vagyis a helyi rendszernek, mégpedig a 10024-es TCP kapun, az amavisd alapértelmezett SMTP figyelõ kapuján át. Az amavisd figyelõ kapuját a /etc/amavisdconf fájl $inet socket port beállításának átírásával változtathatjuk meg A 3. kódrészlet második szakasza azt a bejövõ felületet adja meg, amelyen keresztül a Postfixnek fogadnia kell az amavisd

által visszaadott üzeneteket. A Postfix tehát a helyi hurokfelület, a 127.001-es IP-cím 10025-ös TCP kapuján hallgatózik, ez az a kapu, amelyre alapesetben az amavisd az értesítéseket és a továbbított üzeneteket küldi. Az amavisd értesítési és továbbítási címét és kapuját rendre a /etc/amavisd.conf fájlban szereplõ $notify method és a $forward method beállítások átírásával változtathatjuk meg. A mastercf és a maincf módosítása után a Postfixet újra kell indítani. 2. kódrészlet A /etc/amavisdconf fontosabb beállításai $daemon user = ´amavis´; $daemon group = ´clamav´; $mydomain = ´pelda.org´; $MYHOME = ´/var/amavis´; $QUARANTINEDIR = ´/var/virusoslevelek´; $db home = “$MYHOME/db”; $helpers home = “$MYHOME/var”; $pid file = “$MYHOME/var/amavisd.pid”; $lock file = “$MYHOME/var/amavisd.lock”; $log level = 2; $virus admin = “mick@$mydomain”; $mailfrom notify admin = “antivirus@$mydomain”; $mailfrom notify

spamadmin = “antivirus
@$mydomain”; ### http://www.clamavnet/ [´ClamAV-clamd´, &ask daemon, [“CONTSCAN { } n”, “/usr/share/clamav/clamd.sock”], qr/ bOK$/, qr/ bFOUND$/, qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ], A rendszer ellenõrzése Mielõtt bármilyen további mûveletnek nekifognánk, ellenõrizzük a rendszert. A legegyszerûbb módszer az ellenõrzésre az, hogy küldünk magunknak egy levelet, amelybe az alábbi karakterláncot helyezzük el. Ez nem egy valódi vírus, hanem az Eicar tesztaláírásnak nevezett karakterlánc: X5O!P%@AP[4 PZX54(P^)7CC)7} $EICAR-STANDARDANTIVIRUS-TEST-FILE!$H+H* Ha minden rendben mûködik, az amavisd küldött az amavisd.conf $virus admin beállításában megadott címünkre egy levelet, eredeti üzenetünk pedig az amavisd.conf $QUARANTINEDIR beállításában megadott karanténkönyvtárba került. Az ellenõrzés idejére erõsen ajánlott a levelezési naplófájl végének elkülönítése. Adjuk ki tehát a

tail -f /var/log/mail parancsot, így elkülöníthetjük a Postfix és az amavisd naplóüzeneteit. Tapasztalatom szerint ez a leggyorsabb megoldás az esetleges hibák felismerésére, fõleg akkor, ha a korábban javasolt módon növeltük az amavisd naplójának részletességét. Ne feledjünk legalább egy tiszta próbalevelet küldeni, ezzel ellenõrizhetjük, hogy a Postfix továbbra is képes-e a szûretlen levelek fogadására és továbbítására. A ClamAV adatbázisainak frissítése Már csak egyetlen, de nem kevésbé fontos dolog van hátra, mégpedig a ClamAV vírusaláírásokat tartalmazó adatwww.linuxvilaghu 3. kódrészlet A /etc/postfix/mastercf fájlhoz hozzáadandó sorok smtp-amavis unix y -o smtp data done timeout=1200 -o disable dns lookups=yes 2 smtp 127.001:10025 inet n n - smtpd -o content filter= -o local recipient maps= -o smtpd client restrictions= -o smtpd helo restrictions= -o smtpd sender restrictions= -o smtpd recipient restrictions=permit

mynetworks,
reject unauth destination -o mynetworks=127.000/8 -o strict rfc821 envelopes=yes -o smtpd error sleep time=0 -o smtpd soft error limit=1001 -o smtpd hard error limit=1000 Kiskapu Kft. Minden jog fenntartva Szaktekintély bázisainak frissítése, illetve az ezt a mûveletet napi rendszerességgel végrehajtó cron munka megadása. A ClamAVhez tartozik egy pontosan ilyen célra készült, freshclam nevû segédprogram. Mivel a freshclam az egész rendszer legegyszerûbb eleme, és gyakorlatilag a helybõl is kifutottam, mindenkinek meghagyom az élményt, hogy maga fedezze fel a freshclam(1) és a freshclam.conf(5) súgóoldalakat Annyit azért gyorsan elmondanék, hogy a hétköznapok során csupán a freshclam -l /naplófájl/elérési/útja parancsot kell használnunk, ahol a /naplófájl/elérési/ útja azt a fájlt adja meg, amelybe a freshclam a naplóüzeneteit írja. A freshclamet néhány óránként érdemes lefuttatni. A legegyszerûbb az, ha a

freshclamet a -c és a -d kapcsolók segítségével démon módban használjuk További tudnivalókat a freshclam(1) súgóoldalon találni. Összefoglalás Munkánk eredményeként egy ClamAV alapú védelemmel felszerelt SMTP átjárót kaptunk, vagy legalábbis elindultunk az úton ennek megvalósítása felé. Akinek további kérdése maradtak, az az internetes források között Postfix és Amavisd-new oktatóanyagot egyaránt talál. Sok szerencsét! Linux Journal 2004. december, 128 szám Mick Bauer biztonsági szakember, a Linux Journal biztonsági témákkal foglalkozó szerkesztõje, biztonsági tanácsadó a Minnesota állambeli Minneapolisban. A Building Secure Servers With Linux címû kötet szerzõje (O’Reilly & Associates, 2002). 2005. január 41