Postfix + LDAP + ldapbrowser + IMAP + webmail ArchLinux-on

Ez a blog ahhoz ad segítséget, hogyan lehet egy minimális adminisztrációs igényű levelezőkiszolgálót építeni, amelyik LDAP címtárban tárolja a felhasználó adatait. A megoldáshoz az ArchLinux disztribúciót választottam.

Telepítsük először az openldap csomagot!

pacman -S openldap
groupadd ldap
useradd -g ldap -d /none -s /bin/false ldap

/etc/rc.d/slapd:

SLAPD_OPTIONS="-u ldap -g ldap -4"
SLURPD_START="auto"
SLURPD_OPTIONS=""

chgrp ldap /etc/openldap/slapd.conf
chmod 640 /etc/openldap/slapd.conf

Generáljunk egy erős jelszót az LDAP menedzser számára:

slappasswd

Szerkesszük a slapd.conf-ot (Szükségünk lesz még a qmail.schema nevű sémára. Tőlem egy módosított verziót tölthetsz le)!

/etc/openldap/slapd.conf:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/qmail.schema

pidfile   /var/lib/openldap/slapd.pid
argsfile  /var/lib/openldap/slapd.args

database      bdb
suffix           "dc=aaaa,dc=fu"
rootdn          "cn=Manager,dc=aaaa,dc=fu"

rootpw          {SSHA}KzyLGC4ynKtqy9ppuV7R9eZjvM96E8S5
directory       /var/lib/openldap/openldap-data

index   objectClass     eq

Az alapértelmezett DB_CONFIG fájlt bemásoltam az openldap adatkönyvtárába:
cd /var/lib/openldap/openldap-data
mv DB_CONFIG.example DB_CONFIG

chown -R ldap:ldap /var/lib/openldap

Végül indítsuk el a slapd-t!

/etc/rc.d/slapd start

Ha minden jól ment, akkor a 389/tcp porton elérhető az openldap szerverünk:

tcp     0    0 0.0.0.0:389     0.0.0.0:*     LISTEN

Már csak arra van szükség, hogy a /etc/hosts.allow fájlban megmondjuk, hogy ki csatlakozhat az LDAP kiszolgálónkoz. Vegyük fel a localhost-ot, ill. annak az IP-címét, aki a felhasználókat fogja majd kezelni:

/etc/hosts.allow:

slapd: 127.0.0.1 1.2.3.4 : ALLOW

Telepítsük a postfix csomagot!

pacman -S postfix

Mivel virtuális felhasználókat veszünk majd fel, hozzunk létre nekik egy könyvtárat:

groupadd vmail
useradd -g vmail -d /var/vmail -s /bin/false vmail
mkdir ~vmail
chown vmail:vmail ~vmail/

Szerkesszük a main.cf fájlt:

/etc/postfix/main.cf:

alias_database = $alias_maps
alias_maps = hash:/etc/postfix/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
html_directory = no
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/man
myhostname = mail.bbbb.fu
mynetworks = 1.2.3.0/24, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /etc/postfix/sample
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
unknown_local_recipient_reject_code = 550
virtual_gid_maps = static:102
virtual_mailbox_base = /var/vmail/
virtual_mailbox_domains = mail.aaaa.fu
virtual_mailbox_maps = ldap:/etc/postfix/ldap-virtual.cf
virtual_uid_maps = static:1002

Indítsuk el a postfix-et is:

/etc/rc.d/postfix start

Telepítsük a dovecot IMAP szervert!

Mivel az archlinux-ban elérhető dovecot csomag nem tartalmaz ldap támogatást, ezért fordítsuk le mi magunk a dovecot-ot.

wget http://www.dovecot.org/releases/1.0/dovecot-1.0.13.tar.gz
tar zxvf dovecot-1.0.13.tar.gz
cd dovecot-1.0.13
./configure --disable-ipv6 --with-ldap

Szükségünk lesz még az alábbi csomagokra is a fordításhoz:

pacman -S make gcc bison flex

Majd folytassuk a telepítést:

make
su -c "make install"

Szerkesszük ezután a dovecot.conf-ot:

/usr/local/etc/dovecot.conf:

base_dir = /var/run/dovecot/
protocols = imap
ssl_disable = yes
verbose_proctitle = yes
first_valid_uid = 1002
last_valid_uid = 1002
first_valid_gid = 102
last_valid_gid = 102
valid_chroot_dirs = /var/vmail
maildir_copy_with_hardlinks = yes
disable_plaintext_auth = yes

protocol imap {
     listen = 127.0.0.1:143
     ssl_listen = 127.0.0.1:943
}

auth_verbose = yes

auth default {
  mechanisms = plain
  #user = dovecot-auth
  passdb ldap {
    args = /usr/local/etc/dovecot-ldap.conf
  }
  userdb ldap {
    args = /usr/local/etc/dovecot-ldap.conf
  }
}

Hozzunk létre egy felhasználót a dovecot számára, majd indítsuk el:

groupadd dovecot
useradd -g dovecot -d /none -s /bin/false dovecot
/usr/local/sbin/dovecot

Telepítsünk apache-ot és php-t!

pacman -S apache php

Kapcsoljuk be az ldap és imap támogatást, amihez csak annyi kell, hogy töröljük a komment jelet a két modul hivatkozásáról:

/etc/php/php.ini:

extension=imap.so
extension=ldap.so

Az apache alapértelmezett konfigja is rögtön használható, ha kikommentezzük a unique_id_module-t és engedélyezzük a mod_php5-t:

/etc/httpd/conf/httpd.conf:

#LoadModule unique_id_module        modules/mod_unique_id.so
LoadModule php5_module             modules/libphp5.so

Ezután már indítható is az apache:

/etc/rc.d/httpd start

Telepítsünk a squirrelmail nevű webmail programot!

Az archlinux default apache konfigjában a DocumentRoot a /home/httpd/html alatt van (- lehet, hogy ezt egy ügyesebb helyre akarjuk majd tenni), ezért lépjünk abba a könyvtárba:

cd /home/httpd/html

Töltsük le a squirrelmail legfrissebb verzióját. Ezután csomagoljuk ki, és konfiguráljuk:

tar zxvf squirrelmail-1.4.13.tar.gz
cd squirrelmail-1.4.13
config/conf.pl

Állítsuk be
– az “Organization Preferences” (1) menüben a “Provider name” és “Provider link” változókat (7) és (8)
– a “Server Settings” (2) menüben az IMAP szerver típusát (A): dovecot
– a “General Options” (4) menüben a “Data Directory” (1) és az “Attachment Directory” (2) paramétereket: /home/httpd/sm/data ill. /home/httpd/sm/attach

Végül mentsük el a beállításokat, ill. hozzuk létre a beállított adat és melléklet könyvtárakat:

mkdir -p /home/httpd/sm/data
mkdir /home/httpd/sm/attach
chown -R nobody:nobody /home/httpd/sm

Telepítsük az ldapbrowser nevű LDAP menedzselő programot!

Most, hogy a nehezén túl vagyunk, és működik a csillogó LDAP címtár alapú levelező rendszerünk, már csak egy lépés választ el minket attól, hogy hátra dőlhessünk: a (virtuális) felhasználók kezelését rá kell bízzuk egy lelkes, de nem feltétlen túlképzett személyre. Vagy gyorsra.

Ehhez csak annyi kell, hogy telepítsünk a gépére egy (lehetőleg) grafikus felületű, kattintgatós programot, amivel felhasználókat tud felvenni a rendszerbe. A választásom azért esett az ldapbrowser-re, mert Java alapú, így bármilyen gépen (még vindózén is) elfut, ahol van Java futtató környezet, azaz JRE (vagy JDK). További előnye, hogy támogatja az SSL alapú LDAP kapcsolatokat is.

A program a http://www-unix.mcs.anl.gov/~gawor/ldap/download.html címről tölthető le. Csak ki kell csomagolni a letöltött fájlt, és máris használható a program. Töltsük le a templates.config ill. a qmailUser.template fájlokat, és másoljuk be a templates könyvtárba.

A programot elindítva hozzunk létre egy kapcsolatot, amint az az alábbi ábrán látható:

uj kapcsolat letrehozasa

Készítettem egy o=szamlazas
nevű szervezeti egységet. Nem kötelező, de jobbnak tartom, ha nem ömlesztjük a felhasználókat a dc=aaaa,dc=fu alá közvetlenül. Ezt megtehetjük a users.ldif importálásával, amely tartalmaz egy joska@mail.aaaa.fu című felhasználót is (csak a példa kedvéért).

Ha sikerült az importálás, akkor az alábbihoz hasonló eredményt kapunk:

importalas utan

Ha új felhasználót akarunk felvenni, akkor jelöljük ki az “o=szamlazas” konténert, majd kattintsunk az Edit, Add Entry, qmailUser menüpontokra. Töltsük ki a megjelenő ablakot az alábbihoz hasonlóan. A userPassword mezőnél csak gépeljük be az ún. “clear-text” jelszót, majd a “Set” gombra kattintva írjuk be mégegyszer, és a program előállítja az ábrán is látható kódolt verziót.

uj felhasznalo

Ha mindent jól csináltunk, akkor megjelenik gerzson felhasználónk:

gerzson, az uj felhasznalo

Ha pedig küldünk Gerzsonnak egy levelet, akkor azt meg is fogja kapni, ha gerzson néven bejelentkezik a squirrelmail-be.

Záró gondolatok

Ez a leírás az elinduláshoz ad segítséget, hogy kialakítsunk egy használható és működő rendszert. Azonban több mindent optimalizálni lehet a hatékonyabb működés érdekében, amelyek különösen nagyobb rendszernél lehetnek érdekesek:

– indexelni lehet pl. a maildrop attribútumot, és finomhangolni lehet az openldap adatbázisát, ill. replikációt is beállíthatunk. Érdemes még időnkét snapshot-okat készíteni az LDAP adatbázisról. Jól szokott jönni, ha nagyon kell.
– a postfix-hez vírus- és spamszűrés is adható
– az apache, a php és a squirrelmail számtalan beállítási lehetőséggel rendelkezik, amelyeket érdemes alaposabban megnézni
– stb.

Félreértések a statisztikai szűrők kapcsán

Nemes Dániel egy érdekes előadást tartott a tavalyi Hacktivity-n “A SPAM-ektől az összetett fenyegetésekig – technológia támadástól védekezésig” címmel. (Az előadás videoja a Hacktivity 2007 oldaláról letölthető)

A védekezés lehetőségeinél szóba került a bayes-i (=statisztikai) elv, amelynek kapcsán pár dolgot helyre szeretnék tenni. Ki tudja? Talán az idei Hacktivity 2008-on lehetőségem lesz rá.

Az előadó az alábbi problémákat látja a Bayes elv használatában (nem szó szerint idézve):

1. Meg kell húzni egy határértéket [hogy mettől tekintjük spamnek a levelet], de hol húzzuk meg? Nehéz pontosan meghatározni. Ha túl magasan húzom meg, akkor kevés spamet ismer fel, ha pedig túl alacsonyan húzom meg a határt, akkor a jó levelekre is harap a szűrő.

A legtöbb statisztikai algoritmust használó spamszűrőben egy jól eltalált alapértelmezett érték van,
a clapf-nál ez 92% (0.92). Ha a felhasználó módosítani akarja, szíve joga, azonban a legtöbb esetben a 92% megfelelő. Hihetetlenül hangzik, de a határ meghúzása valójában kevéssé lényeges. Ennek az az oka, hogy (megfelelő tanítás után) a jó levelek spam valószínűsége 0.00xx (0-1%) körül, míg a spam levelek valószínűsége a 0.99xx (99-100%) körül szóródik. A bogofilter-ben található finomhangoló program pl. akár 55%-nál is képes meghúzni a spam határt (más paraméterek egyidejű módosítása mellett).

Hogy mégis van némi szerepe a a spam határ megválasztásának, az azért van, mert (különösen a magyar levelezők életében) vannak olyan jó levelek, amelyek úgy néznek ki, mint egy spam, és olyan spamek is vannak, amelyek úgy néznek ki, mint a jó levelek. Ha mindezt grafikonon ábrázoljuk, akkor egy kettős haranggörbét kapunk. Jól látható, hogy van egy bizonytalan zóna (unsure felirattal), amelybe mind jó levelek, mind pedig spamek is esnek. Ez abban az esetben fordulhat elő, ha a levél teljesen ismeretlen, vagy ha közel hasonló számú jó ill. spam levélre jellemző tokent tartalmaz.

D2S levelek valoszinusege
A Death2Spam projekt kategorizálta ~117k levél spam valószínűségének eloszlása.
Forrás: http://www.death2spam.com/d2s2/images/UserProbsDistrib.gif

Egy másik grafikon az inverz khi-négyzet nevű statisztikai összegző algoritmus okozta tipikus eloszlást mutatja. A vízszintes tengelyen a levelek spam valószínűsége látható, míg a függőleges tengelyen a levelek száma (logaritmikus skálán). Noha az előbb említett bizonytalan zóna itt is megfigyelhető, azonban ez – ha lehet fokozni – még drámaibb módon választja szét a jó és a spam leveleket. A jó levelek zömének a spam valószínűsége 3% alatt van, míg a spam levelek valószínűsége 98% felett van.

a levelek statisztikai valószínűségének eloszlása inverz khi-négyzet algoritmus esetén
A SpamBayes projekt egyik felhasználójának ilyen eloszlást mutattak a leveleinek valószínűségei inverz khi-négyzet összegző algoritmust használva.
Forrás: http://spambayes.sourceforge.net/images/chi2_graph.png

2. Honnan származik az adatbázis minta, amivel tanítom? Ha az enyém, akkor nem reprezentatív. Ha egy szervezet gyűjti össze, akkor az én email forgalmam szempontjából irreleváns.

A statisztikai szűrők pontossága a tanítással arányos. Ezért nagyon fontos, hogy a felhasználó saját levelei megfelelően reprezentálva legyenek a statisztikai spamszűrő adatbázisában, ellenkező esetben hibákat fog véteni a program. A jó levelekre jellemző, hogy ahány felhasználó, annyiféle jó leveleik vannak, továbbá a jó leveleik általában lassan változnak. A spameket viszont ezzel ellentétben nagy tömegben küldik ki, lényegében azonos tartalommal, és a spam gyorsan változik (bár a havi pár ezer spam leveleimben jó, ha 10-féle spam váltja egymást).

Ebből az következik, hogy (elvben) az a legjobb, ha a ham adatbázisunkat a saját leveleink alapján állítjuk össze, míg a spam adatbázist egy nagy, profi és speciálisan ezzel foglalkozó cégtől szerezzük be, akik rengeteg spammel találkoznak, így nagyon reprezentált és aktuális mintával rendelkeznek.

A gyakorlatban ez azonban nem működik, mert aligha van olyan anti-spam gyártó cég, aki a drága áron (értsd: költsége van) összeszedett adatbázisát ingyen (vagy akár térítés ellenében) szétosztaná. De nem is van erre feltétlen szükségünk, mert pl. vállalati környezetben bőven elég lehet 1-2 hónapnyi összegyűjtött spam levél, ill. egy csapda email cím segítségével a spammereket is megkérhetjük, hogy segítsenek frissen tartani a spam leveleinket (anélkül, hogy a felhasználóinknak találkozniuk kellene az ilyen spamekkel). Hihetetlen, de a spammerek meg is teszik ezt a szívességet (persze, nem önszántukból, de ez most mindegy).

3. Folyamatos menedzsmentet igényel. Ki végzi el? A rendszergazda vagy egy 3. fél?

Nem igényel. A saját gépemen futtatott clapf-ot persze folyamatosan szemmel tartom, de ez azért egyedi jelenség, mert a programot én fejlesztem, és – mint fejlesztő – új funkciókat tesztelek, csiszolgatom, stb. A felhasználók szempontjából a clapf egy láthatatlan köztes alkalmazás, amely úgy működik, mint az ember veséje, azaz rendesen nem is tudjuk, hogy van olyanunk is.
Ha pedig “folyamatos menedzsment” alatt a folyamatos tanítástól félünk, akkor hadd nyugtassak meg mindenkit: ha van egy erős kezdeti tanítás (amit tipikusan a vállalat rendszergazdája végezhet el – amit elég egyszer megtenni), akkor aligha kell a felhasználóknak folyamatosan tanítani a token adatbázist.

4. Bayes mérgezés.

Ez akár még működhet is, de a) ez időt és befektetést igényel a spammertől, márpedig ők minél hamarabb túl akarnak esni a levélszemét kiküldésén, b) a felhasználónak automatikus tanításra kell beállítani a spamszűrőjét, és c) a spamszűrőnek fel kell használnia a nem standard levél fejléceket is. Ez implementáció függő, vannak olyan spamszűrők, amelyek csak bizonyos fejléc elemekkel foglalkoznak (pl. Subject, From, To, Received és esetleg a Message-ID), a többit pedig figyelmen kívül hagyják. Ebben az esetben aligha fog működni a trükk. Ha pedig mégis átcsúszik végül a spam levél, akkor egyetlen tanítás semlegesítheti a spammer trójai tokenjeit, és kezdheti a spammer az egész cécót elölről.

5. Töltelékszavak a levél elején, végén, közepén, hogy ezek lerontsák a felismerés hatékonyságát. Spamre nem jellemző szavakat tesznek bele, így fog átjutni a spamszűrőn. Ha tanítod, akkor mérgezi az adatbázist, sokkal rosszabbul fog működni.

J.G. Cumming végzett egy tesztet, amelyben egy spamként felismert piko spamet módosított úgy, hogy a Wikipedia-ról, a szótárfájlból véletlenszerűen ollózott be töltelékszavakat. Az eredmény: a piko spam tízezerszámra küldött mutációiból mindössze 0.04% jutott át. Elhanyagolható.

6. A nem szöveges, pl. kép alapú spamekkel mit kezdenek ezek a programok?

A csak képes mellékletet tartalmazó spam is tartalmaz használható szöveges részt (nem az ilyen levelek végén található kötelező (sic!) szósalátára gondolok), pl. a szükséges HTML részlet, domain nevek, SMTP útvonal (a “Received” fejlécekből), stb. Emellett – ha a spamszűrő bizonytalan – a feladó IP-címét össze lehet vetni feketelistákkal, vagy kimondhatjuk azt is, hogy ha valaki képet küld, és a levele nem jó levél (azaz a spam valószínűsége egy bizonyos határ alatt van), akkor azt spamnek tekintjük. Ezt az utóbbi elvet használva, jó ha 2 fals pozitívom volt az utóbbi hónapokban, cserébe viszont meg tudtam fogni egy nagy halom képes spamet.

7. A Bayes alapú technológiák megbízhatósága kétséges, kétségbe vonható.

Megcáfolva. A bizonyítást ld. fentebb, ill. a SPAMtelenül című könyvemben, amely az áprilisi könyvfesztiválon mutatkozik be. Ja, és hogy miért hoztam elő a témát? Mert Nemes Dániel megemlítette az inverz “csí” – vagy helyesebben: khi (a görög ABC betűje után szabadon) – algoritmust, és a clapf terméknév is elhangzott (mint ami az előbbi nehéz nevű algoritmust használja), amit innen is szeretnék megköszönni. Hátha idén azt is megtudhatja a Hacktivity közönsége, hogy mi az a clapf, és hogyan képes állni a sarat a spammerek trükkjeivel szemben….