gen, ó igen, a Sendmail. Rajonghatunk sokoldalúságáértés elterjedtségéért, vagy éppen utálhatjuk nagyságáért,bonyolultságáért és biztonsági hibáiért. Az is megeshet,

hogy a levélkiszolgálók világában új fiúként egyszerûen csakadunk egy esélyt a Sendmailnek (végül is a Sendmailkétségtelenül a legnépszerûbb nyílt forráskódú programcso-mag az Interneten).Nos, ha szóba kerül a biztonság, a divatos szemlélettel ellen-tétben a Sendmailt nem kell teljesen leírni, és arra sincs szük-ség, hogy a sendmail.cf õsi írásmódját elsajátítsuk (de ténylegnem árt, ha a keményvonalas Sendmail-guruk ismerik). Ebbena hónapban ezeket és más Sendmail biztonsági kérdéseket fo-gunk boncolgatni, és a Sendmail hasznos m4 makróit felhasz-nálva gyorsan felépítünk egy biztonságos, de mûködõképesSimple Mail Transport Protocol (SMTP, azaz egyszerû levélto-vábbító szabvány) átjárót az internetes levelek kezeléséhez.

Miért (vagy miért ne) használjunk Sendmailt?A Sendmail az egyik legõsibb internetes programcsomag, amitmég mindig széles körben használnak. Elsõként a BSD UNIX4.1c változatában jelent meg (1983 áprilisában), és egészennapjainkig saját kategóriájának legkedveltebb alkalmazásamaradt. Az üzenettovábbító ügynökprogramok (MTA-k) közötta Sendmail az Internet fõ igavonója, ami a leveleket a hálóza-tok között megfelelõen és (a végfelhasználó számára) átlátszó-an közvetíti. Csakhogy a Sendmail sem mentes a hátrányoktól.Kedvezõ jellemzõi közé sorolható: a Sendmail hatalmas fel-használói közösséggel bír, ennek eredményeképpen igenkönnyû mind kereskedelmi forgalomban beszerezhetõ, mindingyenes támogatást találni hozzá, nem is beszélve a gazdagelektronikus és nyomtatott leírásokról. Kiforrottságának hálaelég megbízható és kiszámítható.Kedvezõtlen jellemzõi közé tartozik: a Sendmail hosszú tör-ténete során elég sok „cruft”-ot (régi kódot) gyûjtött össze,így aztán lassan biztonsági hibáiról és „elhízottságáról” iselhíresült. Természetesen mindkét vád vitatható. Az évek soránszámos jelentõs sérülékenységére derült fény, ugyanakkornapvilágra kerülésük után igen gyorsan ki is javították õket.A terebélyesség vádpontját illetõen tény, hogy a Sendmail kódbázisa sokkal nagyobb, mint más MTA-ké (mondjuk aQmailé vagy a Postfixé), és memóriafoglalása is kétségtelenülméretesebb – ennek azonban legalább annyira a monolitikus-ság (egyetlen végrehajtható állomány teszi elérhetõvé a legtöbbSendmail-képességet) az oka, mint a felgyülemlett régi kód-sorok. Ha jobban belegondolunk, a hosszú évek során aSendmail forrását már oly sok programozó vizsgálta át tüze-tesen, hogy nehezen képzelhetõ, hogy az elmúlt húsz évettúl sok kizárólag csak történelmi jelentõségû és elavult kódélte volna túl érintetlenül.Sokkal hasznosabb a monolitikusság kérdését vizsgálni.A Sendmailnek bizonyos feladatok ellátásához néha rendszer-gazdai jogosultsággal kell futnia, például ha több különbözõfelhasználó saját könyvtárába ír leveleket. Emiatt aztán a

Sendmail az olyan rendszereken, ahol kizárólag levéltovábbító(e-mail relay) vagy átjárófeladatokat lát el, csakis különlegesjogosultságok nélküli (unprivileged) felhasználóként futhat.A Sendmailt összetettségéért is bírálják. Beállításfájljának, asendmail.cf-nek szövevényessége nem éppen ösztönzõ, hogymást ne mondjak – véleményem szerint valahol a C program-nyelv és a szabványos kifejezések közti nehezen behatárolhatóhelyen helyezkedik el. Mindezek oka természetesen a Send-mail különleges hatékonysága (bár sokan szeretnénk, ha aSendmail inkább a C-t, a szabványos kifejezéseket vagy más,kicsit szabványosabb beállításnyelvet használna a sendmail.cf-ben – legalább ennyire bonyolult, de egyedi saját nyelvehelyett). Manapság már ez a pont is erõsen vitatható. A Send-mail jelenlegi változatait már m4 makrókon keresztül állíthat-juk be, amelyek sokkal kevesebb felhasználóellenes élménytokoznak, mint a sendmail.cf kézi szerkesztése.Egyes felhasználók véleményétõl függetlenül a Sendmail meg-kérdõjelezhetetlenül hatékony és jól támogatott program. Haa Sendmail elõnyeit többre tartjuk a hátrányainál, akkor jócsapatban vagyunk. Azonban még ennél is jobb csapatba kerül-hetünk, ha a Sendmail biztonságos futtatását is elsajátítjuk.

A Sendmail felépítéseMint korábbiakban is említettük, a Sendmail monolitikus fel-építésû a tekintetben, hogy minden tényleges munkát egyetlenvégrehajtható állomány (maga a Sendmail) végez. A Sendmail-nek két mûködési módja létezik: meghívható igény szerint,ebben az esetben feldolgozza a várakozó leveleket, majd kilép;avagy állandóan futó háttérdémonmódban is elindíthatjuk.A démonmód csak akkor szükséges, ha a kívülrõl jövõ levelekfogadása is a Sendmail feladatai közé tartozik; amennyibenviszont kizárólag levélküldésre használjuk, nem kell démon-ként futtatnunk, sõt, tulajdonképpen akár itt abba is hagyhat-nánk az olvasást, hiszen a Sendmailnek ehhez semmi szükségetovábbi beállításokra – hacsak nem akarjuk chrootolva futtatni.Az, hogy a Sendmail miképpen mûködik, erõsen attól függ,hogyan indítottuk el. Ha démonként (azaz a -bd kapcsolóval)futtatjuk, a 25-ös TCP-kapun figyeli a bejövõ SMTP-kapcsola-tokat, és idõnként megkísérli elküldeni a /var/spool/mqueue nevûkimenõsor könyvtárában összegyûlt leveleket. Ha csak úgymeghívtuk, akkor azt a kimenõ levelet próbálja meg kézbesíteni,amiért meghívtuk, illetve a /var/spool/mqueue könyvtárat ellen-õrzi egyéb, esetleg még várakozó kimenõ leveleket keresve.

A feladatMielõtt továbblépnénk, szeretném egyértelmûsíteni, mit isakarunk felépíteni. Példának az SMTP-átjárót választottam,mivel erre a feladatra egyrészt gyakran használják a Sendmailt,másrészt ennél a szerepnél igen sokat számít a biztonságosság(a legtöbb szervezetnél a nyilvánosság számára is elérhetõlevélkiszolgálók sokkal komolyabban fenyegetettségnek van-nak kitéve, mint a belsõ levélkiszolgálók).Az SMTP-átjárók esetében általában különös figyelmet kell

40 Linuxvilág

A Sendmail megerõsítéseMick megvizsgálja a Sendmail biztonsági hiányosságait, és felépít egy internetesleveleket kezelõ SMTP-átjárót.

Szaktekintély

I

© Kisk

apu Kf

t. Mind

en jog

fennt

artva

fordítani a jogosultsági szintekre, a fájljogosultságokra, és álta-lában csak annyi szolgáltatást szabad engedélyezni, amennyia levél célbajuttatásához valóban szükséges. Egy ilyen kiszol-gálón a Sendmailnek lehetõleg jogosulatlan felhasználókéntkell futnia; és csakis végsõ esetben – tehát amikor fájlokat kellírnia – szükséges chrootolni (a / egy alhalmazán), ugyanakkorúgy kell beállítanunk, hogy a leveleket csak a saját szerveze-tünknek továbbítsa, a levélszemétküldõkét (spammer) ne.Red Hat 7 alatt nem túl sok trükk kívánatos a Sendmail SMTP-átjáró megerõsítéséhez, illetve alig valamivel több lépés szük-séges a SuSE vagy más terjesztések esetében.

A Sendmail beszerzése és telepítéseTeljes biztonsággal állíthatom, hogy az általunk kiválasztottLinux-terjesztés egy vagy több Sendmail-csomagot is tartalmaz.Természetesen az, hogy tényleg fel van-e telepítve a rend-szerre, és hogy az általunk használni kívánt megfelelõ változat-ról van-e szó, már más kérdés.Ha rpm-alapú terjesztést használunk (Red Hat, Mandrake,SuSE stb.), a következõ parancs kiadásával nézhetjük meg,hogy valamilyen változatú Sendmail fel van-e már telepítve:rpm -qv sendmail

(a Debian-felhasználóknak a következõt kell beírniuk: dpkg -s sendmail – a fordító). A Red Hat és leszármazottaia Sendmailt három csomagra bontják: sendmail, sendmail-cf és sendmail-doc. A SuSE ellenben egyetlensendmail nevû csomagot használ.Tehát melyik változatot is futtatjuk? Ez idõ tájt, amikor esorokat írom, a legújabb Sendmail-változat a 8.12.2. A Red Hat7 és a SuSE 7 viszont még mindig a Sendmail 8.11 különbözõváltozatait támogatja. Amennyire tudom, semmi gondunk nemlesz, ha a terjesztésünk által támogatott Sendmail-változatnálmaradunk, feltéve, hogy az legalább 8.11.0 vagy magasabbváltozatszámú. A 8.10-es és 8.11-es változatokban nem voltnagyobb biztonsági hiba; a 8.11, tulajdonképpen „bõvített”kiadás volt: nem biztonsági lyukak foltozását tartalmazta,hanem azért adták ki, mert a Sendmail-csapat ekkor adta azSMTP-hez a TLS-titkosítást és az SMTP AUTH-továbbfejlesztéseket.Természetesen amennyiben akad némi idõnk és kedvünk, sohanem árt, ha a legfrissebb üzembiztos változatot fordítjuk éstelepítjük. A józan ész kedvéért írásunk további részeiben fel-tételezem, hogy a Sendmail 8.10.0 vagy újabb változatát hasz-náljuk (az ettõl eltérõt külön megemlítem).

Megjegyzés Debian-felhasználók számáraA Debian GNU/Linux v2.2 (Potato) még mindig a Sendmailv.8.9.3-at használja. Annak ellenére, hogy megbízható és vi-szonylag biztonságos kiadás, mostanra már két fõ változattal islemaradt (már amennyiben valaki, mint például én is, a másodikszámot tekinti fõ változatnak, hiszen az elsõ szám már egy félévtizede a nyolcas). Továbbá a 8.9.3 nem támogatja a TLS- és azSMTP AUTH-lehetõségeket (hamarosan, várhatóan május elejénmegérkezik a Woody Debian GNU/Linux v3.0 – a fordító).Amennyiben TLS-t vagy SMTP AUTH-ot szeretnénk használni,vagy egyszerûen csak nem kívánunk régi változatot futtatni,még mindig eltávolíthatjuk a csomagot, letölthetjük a legfris-sebb forráskódcsomagot a � http://www.sendmail.org-ról,majd a Sendmailt forráskódból lefordíthatjuk és telepíthetjük.A forráskódcsomag jól leírt és Linux alatt könnyedén lefordul,feltételezve természetesen, hogy mûködõképes gcc-telepítés-sel rendelkezünk.Miután a Sendmailt akár bináris csomagként a terjesztésbõl,

akár forráskódból fordítottuk és telepítettük, akad még párfeladat, amit nem árt elvégezni, mielõtt a Sendmail végrehajt-ható állományát démonként kezdenénk futtatni.

A SuSE Sendmail elõkészítéseHa SuSE-t használunk – amennyiben eddig még nem tettükvolna meg –, váltsunk rendszergazdai jogosultságra. Nyissukmeg a /etc/rc.config fájlt a kedvenc szövegszerkesztõnkkel, és azSMTP-változót állítsuk „yes”-re. Ez feltétlenül szükséges, ha aztszeretnénk, hogy a Sendmail /etc/init.d könyvtárban találhatóindítóparancsfájlja a rendszer indulásakor lefusson.Továbbá a /etc/rc.config.d/sendmail.rc.config fájlt át kell szer-kesztenünk, hogy a SENDMAIL_TYPE változó „no”-ra legyenállítva. Ezáltal tulajdonképpen azt gátoltuk meg, hogy aSuSEconfig felhasználja a /etc/rc.config.d/sendmail.rc.config-ot,

amely egyéb esetekben önmûködõen egy egyszerû Sendmail-beállítást hozna létre. Mi azonban most egy SMTP-átjárót,illetve továbbítórendszert szeretnénk beüzemelni, ami igencsaktúlmutat a sendmail.rc.config képességein. Ha gépünk csakegyszerû SMTP-kiszolgálóként fog mûködni a saját helyifelhasználóihoz, valószínûleg ezt az egy fájlt elég átszerkesz-tenünk (ehhez elõbb a SENDMAIL_TYPE változót „yes”-re kellállítanunk); ha ezt választanánk, a sendmail.rc.config teljesleírását megtaláljuk a /etc/mail/README fájlban.Miután az rc.config és a sendmail.rc.config állományokat átszer-kesztettük, futtassuk le a SuSEconfig-ot. Ezzel érvényt szerez-hetünk az rc.config és sendmail.rc.config fájlokban iméntelvégzett változtatásoknak. A démon elindításához begépel-hetjük a /init.d/sendmail start parancsot, azonban énazt javaslom, elõbb inkább várjuk meg, amíg a Sendmailtteljesen beállítjuk.

A Red Hat Sendmail elõkészítéseA Red Hat-felhasználóknak a Sendmail beállítása elõtt mind-össze egyetlen lépést kell elvégezniük: át kell szerkeszteni a/etc/sysconfig/sendmail fájlt, hogy a DAEMON változó értéke„yes” legyen. Ez mondja meg ugyanis a /etc/init.d/sendmail

indítóparancsfájlnak, hogy rendszerindításkor a Sendmailtdémonként kell futtatnia.

412002. júniuswww.linuxvilag.hu

Szaktekintély

© Kisk

apu Kf

t. Mind

en jog

fennt

artva

A Sendmail beállításaVégre-valahára nekikezdhetünk a Sendmail beállításának tar-tományunk SMTP-átjárójaként. A következõkben leírtak a 8.9-es felett a Sendmail bármely változatára érvényesek (sem-milyen körülmények közt ne futtassunk a 8.8-as változatot!).A Sendmail beállításfájl (sendmail.cf és a hozzá tartozó fájlok)egyszerûsített változatának elõállításához a következõlépéseket kell megtennünk:1. A sendmail.mc-ben engedélyezzük a szükséges képességeket.2. Ha szükséges, a sendmail.mc-ben állítsuk be a tartománynév-

álcázást (domain-name masquerading).3. Futtassuk le az m4-et, amely a sendmail.mc-bõl létrehozza

a generate.cf fájlt.4. A mailertable szerkesztésével állítsuk be a kézbesítési

(delivery) szabályokat.5. Az access szerkesztésével állítsuk be a továbbítási (relay)

szabályokat.6. Az aliases-ben állítsuk be a helyi felhasználói álneveket.7. A mailertable, access és aliases állományokat alakítsuk

adatbázissá.8. Az összes helyi gépnevet adjuk meg a local-host-names-ben.9. Indítsuk (újra) a Sendmailt.

A „sendmail.mc” érdekesebb beállításaiAz elsõ és valószínûleg legidõigényesebb feladat az SMTP-átjá-ró felállítása során a /etc/sendmail.cf elõállítása. Ezt legkönnyeb-ben a /etc/mail/sendmail.mc átírásával tehetjük meg (SuSE-rendszereken e fájl neve /etc/mail/linux.mc – más terjesztésekalatt eltérõ is lehet).A használt Linux-terjesztéstõl függõen a sendmail.mc beállításiadatait a /usr/share/doc/sendmail/README.cf (Red Hat éstársai) a /usr/share/sendmail/README (SuSE) vagy valamilyenmás állományban találjuk. Nincs elég hely arra, hogy e fájlszámos beállítási lehetõségét részletekbe menõen ismertessem.Megvizsgálom viszont azokat, amelyek biztonság tekintetébenhasznosak lehetnek vagy beállításainkat modularizálják.A Sendmail beállítását magán a sendmail.cf-en kívül, külsõfájlokból beolvasott adatokkal is megoldhatjuk. Ez két okból iscélszerû: egyrészt a sendmail.cf közvetlen szerkesztése elégkényelmetlen, a sendmail.mc-bõl történõ újralétrehozása pedignem mindig kívánatos. Másrészt amennyiben SMTP-átjárón-kon több különbözõ jogosultsággal rendelkezõ rendszergazdais lesz, jól jöhet, ha a sendmail.cf fájlt zárva tartjuk, ugyanakkora többi rendszergazdának megengedjük az álnevek és a levél-továbbítási szabályok szerkesztését (vagyis a /etc/mail/access

és /etc/mail/mailertable fájlok módosítását).A leghasznosabb külsõ beállításfájlok, amelyeket érdemesengedélyezi:• a mailertable, amely a helyi kézbesítési szabályokat írja elõ;• a virtusertable, ez virtuális tartománymegfeleltetéseket ír le

felhasználónkénti és tartományonkénti bontásban;• az access, ami meghatározza, hogy mely gépek használhat-

ják a kiszolgálót SMTP-továbbítóként.A fenti fájlokat engedélyezõ sendmail.mc-utasítások a következõk:

FEATURE(’mailertable’,

�‘hash -o /etc/mail/mailertable.db·)dnlFEATURE(’virtusertable’,

�‘hash -o /etc/mail/virtusertable.db·)dnlFEATURE(’access_db’,’hash -o

�/etc/mail/access.db·)dnl

(A mailertable és access_db képességek Red Hat alatt

alapértelmezetten érvényesek, viszont a virtusertable résztkézzel kell hozzáadni.)Minden sor arra utasítja a Sendmailt, hogy az adott fájlrahivatkozást készítsen (bár az elérési adatbázist access-nek ne-veztük access_db helyett), és annak hash-adatbázisát, illetveelérési útját használja. Hamarosan megismerhetjük, hogyhogyan használjuk fel ezeket a fájlokat, elõbb viszont végre kellmég néhány dolgot hajtanunk a sendmail.mc-ben.Ha felhasználóink elektronikus címei tartományunk szerintiekés a gép szerint, ahová bejelentkeztek, nem változnak – azazmick@polkatistas.org formátumúak mick@myron.polkatistas.org

formátum helyett, akkor kimenõ leveleik From: mezõjét való-színûleg ennek megfelelõen érdemes megváltoztatni (az ilyenáltalános címeken fogadott levelek felhasználói álneveketigényelnek – lásd késõbb).A következõ sorok olyan sendmail.mc-beállításokat mutatnakbe, melyek arra utasítják példa-SMTP-átjárónkat, hogy apolkatistas.org felhasználóitól érkezõ levelek From: mezõjétaz elõbbieknek megfelelõen írja át. A lenti példa összes sorátbe kell szúrni, vagy a megjegyzésbõl ki kell szedni:

MASQUERADE_AS(‘polkatistas.org·)dnl

MASQUERADE_DOMAIN(‘.polkatistas.org·)dnl

EXPOSED_USER(‘root·)dnl

FEATURE(‘masquerade_entire_domain·)dnl

FEATURE(‘masquerade_envelope·)dnl

• A MASQUERADE_AS direktíva azt a teljes értékû tartomány-nevet adja meg, amit a megfelelõ From: címekben szeret-nénk látni.

• A MASQUERADE_DOMAIN direktíva adja meg azt a gépet,amire a MASQUERADE_AS vonatkozik. A polkatistas.org

elõtt álló “.” azt jelenti, hogy az összes ebbe a tartománybatartozó gépnevet álcázni kell.

• Az EXPOSED_USER azt a felhasználónevet adja meg,amelynek From: címét nem szabad álcázni. A rendszer-gazda gyakori vendég e mezõben, mivel a tõle érkezõ levélsokszor figyelmeztetéseket és riasztásokat tartalmaz – ha ilyet kapunk, általában azt is tudni szeretnénk, hogymelyik géptõl érkezett.

• A masquerade_entire_domain képesség azt jelenti,hogy a MASQUERADE_DOMAIN teljes tartományként és nemgépnévként értelmezendõ; a masquerade_envelopeeredményeképpen az álcázás nemcsak az SMTP-fejlécrevonatkozik, hanem a borítékra is.

Négy másik direktívát – egy logisztikait és három biztonságijellegût – találunk az 1. listában.• Az always_add_domain képesség Red Hat és SuSE alatt

alapértelmezetten be van kapcsolva; az use_cw_file éssmrsh Red Hat alatt érvényes, a SuSE alatt viszont nem;a confSAFE_FILE_ENV beállítást pedig minden esetbennekünk kell megadnunk.

42 Linuxvilág

Szaktekintély

1. lista Néhány további sendmail.mc-képességFEATURE(always_add_domain)dnl

FEATURE(use_cw_file)dnl

FEATURE(‘smrsh·,‘/usr/sbin/smrsh·)dnl

define(‘confSAFE_FILE_ENV·,

‘/var/mailjail·)dnl

© Kisk

apu Kf

t. Mind

en jog

fennt

artva

• Az always_add_domain képesség a gép tartománynevétegyszerûen minden olyan levélhez kötelezõen hozzáadja,amely magát tartománynév nélkül azonosító géprõl érke-zik. Például ha az SMTP-átjáró levelet kap bobo felhaszná-lótól egy olyan géprõl, amely magát csak whoopeejohn

néven azonosította, a Sendmail a From: mezõt az eredetibobo@whoopeejohn helyett bobo@whoopeejohn.

polkatistas.org formátumúra írja át (de az álcázási direktí-vák itt is érvényesek).

• A use_cw_file képesség használata arra utasítja a Send-mailt, hogy a Sendmail által helyinek értékelt gépek listájáta /etc/mail/local-host-names fájlból vegye. A /etc/mail/local-

host-names egyszerû szöveges állomány, amely soronkéntegyetlen gépnevet tartalmaz. Tegyük fel, hogy példa-SMTP-átjárónk nemcsak a polkatistas.org tartományból kaplevelet, hanem a tubascoundrels.net-rõl is. Ha az átjáró neve

mail, a local-host-names fájlja a következõképpenfog kinézni:

localhost.localdomain

mail.polkatistas.org

mail.tubascoundrels.net

Az 1. listában megadott harmadik képesség azsmrsh, azaz a Sendmail korlátozott héjprogram.Ez nagyon fontos biztonsági lehetõség, amelyképes korlátozni felhasználók .forward fájljábólvégrehajtható parancsokat.Az 1. lista negyedik sora azt mondja meg a Sendmail-nek, hogy a sendmail.cf SafeFileEnvironment

változóját állítsa be – ahogy már biztosan ki is találták– a saját könyvtár (/) egy olyan alkönyvtárára, ahováa Sendmail chrootolni fog (mármint amelyik ígylett beállítva). Jelenleg ez csak akkor következik be,amikor a Sendmail fájlokat ír. Ha meggondoljuk,ennek az ötvenszázaléknyi chrootolásnak is vanértelme: pontosan a fájlírások azok, amelyek miatta leginkább aggódnunk kell, és egy ilyen chrootkör-nyezet kialakítása sokkal egyszerûbb, mintha a sokhelyen használt chroot jail-t választanánk(abban az esetben ugyanis a chrootolt program által

igényelt minden fájlszerkezetbõl, fájlból, végrehajtható állo-mányból és eszközbõl másolatot kell tartani).A 2. lista az én példa-SafeFileEnvironment-em/var/mailjail könyvtárának teljes listáját (ls -lR) mutatja be.A /var/mailjail/var/spool/mqueue/bobo és .../root fájlokat aSendmail hozta létre. Ez elõtt az egész chroot jail-környe-zetet mindössze négy paranccsal hoztam létre:

mkdir -p /var/mailjail/var/spool/mail/var/

�mailjail/var/spool/mqueuecd /var/mailjail

chown -R mail:mail *

chmod -R 700 *

Ha valakit a kéretlen kereskedelmi levelek témaköre érdekelne,számára is akad néhány jó hírem: a Sendmail alapértelmezés

432002. júniuswww.linuxvilag.hu

Szaktekintély

2. lista A /var/mailjail tartalma/var/mailjail:

total 1

drwx------ 5 mail mail 1024 Jan 22 17:09 var

/var/mailjail/var:

total 3

drwx------ 4 mail mail 1024 Jan 22 17:07 spool

/var/mailjail/var/spool:

total 2

drwx------ 2 mail mail 1024 Jan 22 17:06 mail

drwx------ 2 mail mail 1024 Jan 22 17:06 mqueue

/var/mailjail/var/spool/mail:

total 98

-rwx------ 1 mail mail 48528 Jan 22 17:06 bobo

-rwx------ 1 mail mail 47627 Jan 22 17:06 root

/var/mailjail/var/spool/mqueue:

total 0

Nem kell túl nagy jelentõséget tulajdonítani neki, dejómagam Postfix-rajongó vagyok. Postfixet és nemSendmailt futtatok a saját tartományom SMTP-átjáró-jaként (igaz, saját hálózatomon helyi levéltovábbításhozSendmailt használok). Így aztán az e cikkben leírtakból,ideértve egyáltalán a létezését is, senki ne következtes-sen arra, hogy úgy gondolom, a Sendmail a legjobbválasztás, ha valakinek MTA-ra van szüksége – eztmindenkinek magának kell eldöntenie.Megkockáztatva, hogy kétértelmûnek tûnök, azt kellmondanom, az elmúlt években meglehetõsen sok idõtfordítottam a Sendmailre és sokat segítettem másokat isa Sendmail használatában. Úgy vélem, hogy sokkaljobb, mint amennyire némelyek becsülik. Tapasztalataimszerint egyáltalán nem az a döcögõ, cammogó, töré-keny szörny, mint amilyennek néhány kritikusa beállítja.

Valójában a Sendmailt igen megbízhatónak és hatékony-nak tartom, mégha kicsit ijesztõ is a bonyolultsága.Továbbá a legutóbbi, 1997-es CERT-tanácsadó óta(number CA-1997-05), amely a Sendmail biztonsági hi-báját is tartalmazta, egyszerûen nem látom bizonyított-nak, hogy a Sendmail örökletesen ne lenne biztonságos-sá tehetõ. (A Sendmail átvizsgálása nyilván nem lettkevésbé szigorú az elmúlt öt évben, mint korábban.)Ezért azt hiszem, hogy bár más MTA-k (köztük a Postfix,Qmail és az Exim) egyértelmû elõnyökkel rendelkezneka Sendmaillel szemben a teljesítmény és a biztonságterén, egyben úgy vélem, a Sendmail elég jó minõségûahhoz, hogy megkapja a Paranoid Pingvin minõsítést(emellett az MTA-k „királyi családjából” származik: abeltenyészet miatt ugyan aggódhatok egy kicsit, deettõl még tisztelettel tartozom neki).

Mick széljegyzete

© Kisk

apu Kf

t. Mind

en jog

fennt

artva

szerint nem engedélyezi az SMTP-továbbítást (relaying), ezta levélszemétküldõk által általánosan használt módszert.A szolgáltatást ugyan a sendmail.mc-ben ki lehet kapcsolni,de tõlem ugyan meg nem tudod, hogyan. Inkább hagyjuk úgy.Továbbá a Sendmailt oly módon is beállíthatjuk, hogy mindenismert levélszemétforrásból érkezõ levelet utasítson el, amelya Realtime Blackhole List (RBL) feketelistáján szerepel. A követ-kezõ sort kell csupán beszúrunk, illetve a megjegyzésbõlkiszednünk:

FEATURE(’dnsbl’)

Ahhoz azonban, hogy ez tényleg mûködjön, elõbb fel kelliratkozni az RBL-re – honlapjuk címét megadtuk a Kapcsolódó

címek között. A weblapon feliratkozási és felhasználási taná-csokat olvashatunk, illetve néhány fontos nyilatkozatot talá-lunk (nem árt tudni, hogy míg a RBL-feliratkozás az egyéni,illetve hobbihelyek számára (Individual/Hobby Sites) ingyenes,ennek a szolgáltatásnak díjszabása is van). Az RBL felhaszná-lásával a jogosult felhasználók leveleit éppúgy megállíthatjuk,mint a levélszemetelõkét, ezért kezeljük óvatosan.Ha Red Hat 7.1-es vagy 7.2-es változatot használunk, létezikmég egy sendmail.mc lehetõség, amit érdemes megnézni – ezúttal egy olyan, amit megjegyzésbe kell tenni. Amennyibena /etc/mail/sendmail.mc fájlunk egy ilyen sort tartalmaz:

DAEMON_OPTIONS(‘Port=smtp,Addr=127.0.0.1,

�Name=MTA·)

Tegyük megjegyzésbe, úgy, hogy a dnl karaktereket a sorelejére írjuk. Ameddig mûködik, ez a sor megakadályozza,hogy a Sendmail saját hurokeszközének (loopback) csatoló-felületén kívül bármilyen más hálózatról érkezõ kapcsolatotfogadjon. Mondanunk sem kell, hogy egy SMTP-átjáró eseté-ben ez nemkívánatos (bár kétségtelenül növeli a biztonságot).Ezek voltak a számunkra legfontosabb sendmail.mc-beállítások.Léteznek természetesen más, biztonsági szempontból fontosbeállítási lehetõségek is, különös tekintettel a nem átjárószabá-lyokra (helyi kézbesítés stb.). További tájékoztatásért olvassukel a README.cf vagy a README fájlokat, amelyeket e részelején említettem.Macro-beállítófájlunk sendmail.cf-fé alakításához a következõparancsot használjuk:

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

Amennyiben macro-beállításfájlunk neve nem sendmail.mc,helyettesítsük be a linux.mc vagy az éppen használt macro-beállítófájlnévvel. A Sendmail azt várja, hogy beállításfájljátsendmail.cf-nek nevezzék; ráadásul mindig a /etc könyvtárbankeresi, így aztán a parancs e része terjesztéstõl, sõt, Sendmail-változattól függetlenül mindig így néz ki.

A kézbesítési szabályok beállításaA nehezén túl vagyunk, most már csak azt kell a Sendmailnekmegmondanunk, hogy mit csináljon a beérkezett levelekkel,milyen helyi gépnevek fogadhatók el, és milyen felhasználók,hálózatok és tartományok használhatják az SMTP-átjárót nemhelyi célú levelek küldésére.A mailertable-t a kézbesítési szabályok megadására használjuk.Egyszerû az írásmódja, és terjesztéstõl függõen a /usr/share/doc

/sendmail/README.cf vagy a /usr/share/sendmail/README

fájlban találhatjuk meg. Dióhéjban: minden sor két részbõl áll,

a célazonosítóból és a mûveletbõl. A célazonosítónak kellmegegyeznie a cél címével vagy annak egy részével; a mûveletazt mondja meg, hogy a Sendmailnek mit kell tennie azokkalaz üzenetekkel, amelyek célja megegyezett az azonosítóval.Ha az azonosító „.”-tal kezdõdik, akkor minden levélforráscím,amely a pont után megadott részre végzõdik, találatnak számít.Ha nem, a „@” jelet követõ összes karakternek meg kellegyeznie. A bobo@weird-al.polkatistas.org nem fog egyeznia polkatistas.org címmel, de egyezni fog a .polkatistas.org-gal.A mûvelet ügynök:cselekmény alakú, ahol az ügynök leheta levelezõ (a mailer, amit a sendmail.mc/linux.mc MAILER()

pontjában állíthatunk be), vagy a beépített local ügynök, illetveerror. A local ügynök természetesen azt feltételezi, hogy a leve-let valamilyen helyi felhasználónak küldjük, amit a kettõspontután adunk meg (ha a kettõspontot semmi sem követi, akkormagában az üzenetben megadott felhasználót fogja használni).Alább egy mailertable látható két különbözõ cselekménnyel:

polkatistas.org

�smtp:internalmail.polkatistas.orgmail.polkatistas.org local:postmaster

A kézbesítési szabályokon felül a Sendmailnek tudnia kell,hogy mely elektronikus levélcélokat kell a helyi (az SMTP-átjáró) gépnév rokonának tekintenie. Ezeket a /etc/mail/local-

host-names fájlban adhatjuk meg, soronként egyet:

mail.polkatistas.org

weird-al.polkatistas.org

1.23.234.2

Végül azoknak a listáját kell megadnunk, akiknek a továbbításta /etc/mail/access átszerkesztésével engedélyezzük. Az írásmódnagyon egyszerû: minden sor egy forrásnevet vagy -címettartalmaz, ami után egy cselekmény áll (a részletekért ismét aREADME.cf-et vagy az ennek megfelelõ állományt nézzük átrendszerünkön). A cselekmény lehet RELAY (továbbít),REJECT (elutasít), DISCARD (elvet), OK vagy ERROR (hiba).A gyakorlatban ezek között a RELAY a leghasznosabb cselek-mény, mivel alapesetben minden más továbbítás elutasításrakerül. A REJECT és a DISCARD cselekményeknek csak akkorvan haszna, ha egy adott RELAY-szabály alól akarunk kivé-teleket megadni. Íme, egy egyszerû access fájl:

localhost.localdomain RELAY

localhost RELAY

127.0.0.1 RELAY

192.168 RELAY

Ugye, észrevettük a valódi gépnevek hiányát a fenti példában?Ebben a példában az SMTP-átjáró mindössze kimenõ továb-bítást enged; a bemenõ levelek kizárólag helyi címekre jöhet-nek, és a kimenõ továbbításoknak is olyan gépekrõl kell érkez-niük, amelyek IP-címe a 192.168 számokkal kezdõdik (amiaz Interneten nyilvánvalóan nem megadható címtartomány).Kedvelem ezt a módszert (az IP-cím használatot), hiszen így azIP-címálcázást tûzfalszabályaimmal megakadályozhatom, igaz,nem tudom meggátolni a hamis From: levélcímek átadását(természetesen a te igényeid mások is lehetnek):

access

local-host-names

mailertable

44 Linuxvilág

Szaktekintély© K

iskapu

Kft. M

inden

jog fe

nntart

va

Kifinomultabb Sendmail biztonsági eljárásokAz SMTP AUTH (a Sendmail 8.10-es változatától fölfelé) márazonosítási lehetõséget hozott az SMTP-mûveletek világába,azaz képes megállapítani, hogy engedélyezheti-e a továbbítást.Ez különösen akkor hasznos, amikor a rendszerek vagy afelhasználók nem futtatnak saját MTA-t, mégis szeretnénekleveleket küldeni, azaz a kifelé menõ leveleket egy központiátjárón át muszáj küldeni.Ha olyan SMTP-kiszolgálót futtatunk, amely más tartományok-ból érkezõ leveleket is továbbít, nem árt, ha megismerkedünkezzel a képességgel, mivel igen fontos védelem a kéretlenkereskedelmi levelek ellen, amelyek elkövetõi jelentõs részbenaz SMTP-továbbításokban bíznak.Már csak egyetlen fájl maradt, amin finomítani lehetne: ez azaliases. Ez a fájl tartalmazza a felhasználók elektronikus leve-leinek álnévlistáját. Általában egy SMTP-átjárónak nincs szük-sége túlságosan részletes alias-adatbázisra; egész tartományok(vagy virtuális tartományok) levélcímeihez jobb, ha inkábba felhasználói adatbázist használjuk (ezt azonban hely hiányá-ban sajnos nem áll módomban leírni). Szerencsére eléggémagától értetõdõ, így nyugodtan szerkesszük át, ha szükséges.A tárgyalt négy fájlból három: a mailertable, access és aliases

állományok közvetlenül nem használhatók fel a Sendmailhez,elõször adatbázissá kell alakítanunk õket. A /etc/mail könyvtáregy hasznos kis Makefilet tartalmaz e célra. Használatáhozegyszerûen csak váltsunk a /etc/mail könyvtárba, és gépeljükbe a következõ parancsot:

Make access.db mailertable.db

A fenti parancs az aliases fájlhoz nem lesz jó, mivel ennek sajáteszköze van: a newaliases. Futtassuk le minden kapcsolónélkül a newaliases-t, és megváltoztatott /etc/aliases fájlunkönmûködõen /etc/aliases.db fájllá alakul.Egyelõre ennyi. Sok mindent nem sikerült elmondanom: különkiemelném közülük az smrsh héjprogramot (amit fõkénta helyi levélkézbesítéshez lehet felhasználni és nem az átjárók-hoz). Remélem, hogy azért sikerült néhány hasznos tippetadnom és útmutatást szolgáltatnom néhány teljesebb informá-cióforráshoz. Sok szerencsét!

Linux Journal március, 95. szám

452002. júniuswww.linuxvilag.hu

Szaktekintély

Mick Bauer (mick@visi.com) hálózati biztonsággal foglalkozó szaktanács-adó. 1995 óta a Linux elkötelezett híve, 1997 óta pedig OpenBSD prófétakénttevékenykedik. Mick minden kérdést ésmegjegyzést szívesen fogad.

Kapcsolódó címek� http://www.sendmail.net/000705securitygeneral.shtml� http://www.sendmail.net/000710securitytaxonomy.shtml� http:// www.itworld.com/Net/3314/swol-0699-security� http://www.sendmail.net/810usingantispam.shtml� http://www.sendmail.net/usingsmtpauth.shtml

© Kisk

apu Kf

t. Mind

en jog

fennt

artva