Kapittel 11. Nettverkstjenester: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Nettjenester er de programmene som brukerne direkte samhandler med i sitt daglige arbeid. De er toppen av informasjonssystemets isfjell, og dette kapittelet fokuserer på dem - de skjulte delene de er avhengige av er den infrastrukturen vi allerede har beskrevet.

Mange moderne nettverkstjenester krever krypteringsteknologi for å fungere på en pålitelig og sikker måte, spesielt når de brukes på det offentlige Internettet. X.509-sertifikater (som også kan refereres til som SSL-sertifikater) eller TLS-sertifikater) brukes ofte til dette formålet. Et sertifikat for et bestemt domene kan ofte deles mellom mer enn en av tjenestene som er omtalt i dette kapittelet.

11.1. Posttjener

Administratorer i Falcot Corp valgte ut Postfix som elektronisk posttjener, på grunn av påliteligheten og et enkelt oppsett. Designet sikrer faktisk at hver oppgave blir gjennomført i en prosess med et minimum sett av nødvendige tillatelser, et godt forebyggende tiltak mot sikkerhetsproblemer.

ALTERNATIV Exim4-tjeneren

Debian bruker Exim4 som standard e-posttjener (som er grunnen til at den første installasjonen inkluderer Exim4). Oppsettet er levert av en egen pakke, exim4-config, og automatisk tilpasset basert på svar på et sett med Debconf-spørsmål svært lik spørsmålene fra postfix-pakken.

Oppsettet kan enten være i en enkelt fil (/etc/exim4/exim4.conf.template), eller delt på tvers av en rekke oppsettssnutter lagret under /etc/exim4/conf.d/. I begge tilfeller brukes filene av update-exim4.conf som maler for å generere /var/lib/exim4/config.autogenerated. Den sistnevnte er filen som brukes av Exim4. Takket være denne mekanismen kan verdier som fås gjennom Exims debconf-oppsett - som er lagret i /etc/exim4/update-exim4.conf.conf - legges inn i Exims oppsettsfil, selv når administratoren eller en annen pakke har endret Exims standardoppsett.

Syntaksen til Exim4s oppsettsfil har sine særegenheter og en viss læringskurve; men når disse særegenheter blir forstått, er Exim4 en svært komplett og kraftig e-posttjener, noe som gjenspeiles av de titalls sidene med dokumentasjon.

→ http://www.exim.org/docs.html

11.1.1. Å installere Postfix

Pakken postfix omfatter den viktigste SMTP-bakgrunnsprosessen. Andre pakker (slik som postfix-ldap og postfix-pgsql) legger til ekstra funksjonalitet til Postfix, medregnet tilgang til kartdatabaser. Du bør bare installere dem hvis du vet at du trenger dem.

Flere Debconf-spørsmål stilles under installasjonen av pakken. Svarene gjør det mulig å generere en første versjon av oppsetstfilen /etc/postfix/main.cf.

Det første spørsmålet håndterer typen oppsett. Bare to av de foreslåtte svarene passer for en Internett-tilkoblet tjenermaskin, «Internet site» (Internett-nettsted) og «Internet with smarthost» (Internett med smartvert). Førstnevnte passer for en tjener som mottar innkommende e-post, og sender utgående e-post direkte til sine mottakere, og er derfor godt tilpasset i Falcot Corps tilfelle. Sistnevnte passer for en tjener som mottar innkommende e-post som normalt, men som sender utgående e-post via en mellomliggende SMTP-tjener - en «smartvert» - i stedet for direkte til mottakerens tjener. Dette er mest nyttig for personer med en dynamisk IP-adresse, siden mange e-posttjenere avviser meldinger som kommer rett fra en slik IP-adresse. I dette tilfellet vil en smartvert vanligvis være ISPs SMTP-tjener, som alltid er satt opp til å godta e-post som kommer fra ISPens brukere, og videresende den på riktig måte. Dette oppsettet (med smartvert) passer også for tjenermaskiner som ikke er permanent koblet til Internett, da det unngår å måtte håndtere en kø med ikke-leverbare meldinger som ikke kan leveres, og som må prøves igjen senere.

Det andre spørsmålet omfatter det fulle navnet på maskinen, som brukes til å generere e-postadresser fra et lokalt brukernavn; hele navnet på maskinen kommer opp som en del etter at-skiltet/krøllalfa («@»). For Falcots del bør svaret være mail.falcot.com. Dette er det eneste spørsmålet ved oppstart, men oppsettet den fører til er ikke komplett nok for behovene til Falcot, noe som er grunnen til at administratorene kjører dpkg-reconfigure postfix, slik at man er i stand til å tilpasse flere parametre.

Ett av de ekstra spørsmålene gjelder å få alle domenenavn knyttet til denne maskinen. Standardlisten inneholder dets fulle navn, samt noen få synonymer for localhost, men hoveddomenet falcot.com må legges for hånd. Mer generelt bør dette spørsmålet vanligvis besvares med alle domenenavnene som denne maskinen skal tjene som MX-tjener for; med andre ord, alle domenenavnene for hvem DNS sier at denne maskinen vil akseptere e-post. Denne informasjonen ender opp i mydestination-variabelen i Postfixs hovedoppsettsfil - /etc/postfix/main.cf.

Figur 11.1. Rollen til DNS MX-registrering ved sending av en e-post

I noen tilfeller kan installasjonen også spørre hvilke nettverk som skal få lov til å sende e-post via maskinen. I standardoppsettet aksepterer Postfix kun e-postmeldinger som kommer fra selve maskinen; det lokale nettverket vil vanligvis bli lagt til. Falcot Corp-administratorene la til 192.168.0.0/16 til standardsvaret. Hvis spørsmålet ikke er spurt, er den relevante variabel i oppsettsfilen mynetworks, slik som i eksemplet nedenfor.

Lokal e-post kan også leveres via procmail. Dette verktøyet tillater brukere å sortere sin innkommende e-post etter regler som er lagret i deres ~/.procmailrc-fil.

Etter dette første trinnet, fikk administratorene følgende oppsettsfil; den vil bli brukt som et utgangspunkt for å legge inn noe ekstra funksjonalitet i de neste seksjonene.

Eksempel 11.1. Innledende /etc/postfix/main.cf-fil

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

SIKKERHET «Slangeolje» -SSL-sertifikater

«Slangeolje»-sertifikatene, som ble solgt som slangeolje-«medisin» av skruppelløse kvakksalvere i gamle dager, har absolutt ingen verdi. Du kan ikke stole på dem til å godkjenne tjeneren, for de blir automatisk generert med selvsignerte sertifikater. Men de er nyttige for å gjøre utvekslingene mer private.

Generelt bør de bare brukes til testformål, og i vanlig drift må en bruke ekte sertifikater. Disse kan genereres med fremgangsmåten beskrevet i Seksjon 10.2.1.1, «Offentlig nøkkel-infrastruktur: easy-rsa».

11.1.2. Oppsett av virtuelle domener

E-posttjeneren kan motta e-post adressert til andre domener i tillegg til hoveddomenet. Disse er da kjent som virtuelle domener. I de fleste tilfeller der dette skjer, blir e-postene i siste instans ikke ment for lokale brukere. Postfix gir to interessante funksjoner for håndtering av virtuelle domener.

11.1.2.1. Virtuelle alias-domener

Et virtuelt alias-domene inneholder kun aliaser, dvs. adresser som bare videresender e-post til andre adresser.

Et slikt domene aktiveres ved å legge navnet sitt til virtual_alias_domains-variabelen, og vise til en adressekartleggingsfil i virtual_alias_maps-variabelen.

Eksempel 11.2. Direktiver til å legge i /etc/postfix/main.cf-filen

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Filen /etc/postfix/virtual beskriver en kartlegging med en ganske grei syntaks: Hver linje inneholder to felt adskilt med mellomrom: Det første feltet er alias-navnet, det andre feltet er en liste over e-postadresser der det omdirigeres. Den spesielle @domain.com-syntaksen dekker alle gjenstående aliaser i et domene.

Eksempel 11.3. Eksempel /etc/postfix/virtual-fil

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within 
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

11.1.2.2. Virtuelle postboksdomener

Meldinger adressert til et virtuelt postboksdomene er lagret i postkasser som ikke er lagt til en lokal systembruker.

Aktivering av et virtuelt postboksdomene krever navngiving av dette domenet i virtual_mailbox_domains-variabelen, og refererer til en postkassekartleggingsfil i virtual_mailbox_maps. Parameteren virtual_mailbox_base inneholder katalogen der postkasser vil bli lagret.

Parameteret virtual_uid_maps (respektivt virtual_gid_maps) refererer til filen som inneholder kartleggingen mellom e-postadressen og systembrukeren (henholdsvis gruppen) som «eier» den tilsvarende postkassen. For å få alle postkasser som eies av samme eier/gruppe tilordner static:5000 syntaksen en fast UID/GID (med verdien 5000 her).

Eksempel 11.4. Direktiver til å legge i /etc/postfix/main.cf-filen

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

Igjen, syntaksen til /etc/postfix/vmailbox-filen er ganske enkel: To felt adskilt med mellomrom. Det første feltet er en e-postadresse i et av de virtuelle domenene, og det andre feltet er plasseringen av den tilhørende postkasse (i forhold til katalogen spesifisert i virtual_mailbox_base). Hvis postboksen ender med en skråstrek (/), blir e-postene lagret i maildir-formatet; ellers blir det tradisjonelle mbox-formatet brukt. Formatet maildir bruker en hel katalog for å lagre en postkasse, hver enkelt melding blir lagret i en egen fil. I mbox-formatet, på den andre siden, er hele postboksen lagret i en fil, og hver linje som starter med «From » (From fulgt av et mellomrom) signaliserer starten på en ny e-post.

Eksempel 11.5. Filen /etc/postfix/vmailbox

# Eposten til Jean er lagret som maildir, med
# en fil per epost i en katalog satt av til formålet
jean@falcot.org falcot.org/jean/
# Eposten til Sophie er lagret i en tradisjonell mbox-fil,
# der alle epostene er lagt etter hverandre i en enkelt fil
sophie@falcot.org falcot.org/sophie

11.1.3. Restriksjoner for å motta og sende

Det økende antall uønskede e-poster (spam) krever større strenghet når man bestemmer hvilke e-postmeldinger en tjener bør akseptere. Denne seksjonen presenterer noen av de strategiene som inngår i Postfix.

KULTUR Spamproblemet

«Spam» er et generelt begrep som brukes for å betegne alle uønskede kommersielle e-poster (også kjent som UCES) som oversvømmer våre elektroniske postkasser. De skruppelløse individer som sender dem, er kjent som spammere. De bryr seg lite om de ordensforstyrrelser de forårsaker, siden det å sende en e-post koster svært lite, og bare en svært liten andel av mottakerne trenger å bli tiltrukket av tilbudene for at spamming-operasjonen tjener mer penger enn det koster. Prosessen er for det meste automatisert, og en offentliggjort e-postadresse (for eksempel på et nettforum, registrert på en adresseliste, eller på en blogg, og så videre) vil bli oppdaget av spammeroboter, og utsatt for en endeløs strøm av uønskede meldinger.

Alle systemadministratorer prøver å møte denne ordensforstyrrelsen med spamfiltre, men selvfølgelig vil spammere holde seg oppdatert for å prøve å omgå disse filtrene. Noen leier til og med nettverk av maskiner kompromittert med en orm fra ulike kriminelle organisasjoner. Nyere statistikk anslår at opptil 95 prosent av all e-post som sirkulerer på Internett er spam!

11.1.3.1. IP-baserte adgangsrestriksjoner

Direktivet smtpd_client_restrictions styrer hvilke maskiner som får lov til å kommunisere med e-posttjeneren.

Eksempel 11.6. Restriksjoner basert på klientadresse

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org

Når en variabel inneholder en liste med regler, som i eksempelet ovenfor, er disse reglene evaluert i rekkefølge fra den første til den siste. Hver regel kan akseptere meldingen, avvise den, eller overlate avgjørelsen til en følgende regel. Som en konsekvens, rekkefølge betyr noe, og ganske enkelt å bytte om på to regler kan føre til et vidt forskjellig resultat.

Direktivet permit_mynetworks, brukt som den første regelen, godtar alle e-poster som kommer fra en maskin i det lokale nettverket (som definert av oppsettsvariabelen mynetworks).

Det andre direktivet vil normalt avvise e-post fra maskiner uten et helt gyldig DNS-oppsett. Et slikt gyldig oppsett betyr at IP-adressen kan løses til et navn, og at dette navnet i sin tur går over til IP-adressen. Denne begrensningen er ofte altfor streng, siden mange e-posttjenere ikke vil ha en omvendt DNS for deres IP-adresse. Dette forklarer hvorfor Falcot administratorer forvalgte warn_if_reject-modifikatoren til reject_unknown_client-direktivet: Denne modifikatoren gjør om avvisningen til en enkel varsling registrert i loggene. Administratorene kan deretter holde et øye med antall meldinger som ville bli avvist hvis regelen faktisk ble håndhevet, og ta en avgjørelse senere hvis de ønsker å muliggjøre slik håndheving.

TIPS access-tabeller

Restriksjonskriteriet omfatter administrator-modifiserbare tabeller som lister kombinasjoner av avsendere, IP-adresser, og tillatte eller forbudte vertsnavn. Disse tabellene kan opprettes fra en ukomprimert kopi av /usr/share/doc/postfix-doc/examples/access.gz-filen. Denne modellen er selv dokumentert i sine kommentarer, noe som betyr hver tabell beskriver sin egen syntaks.

Tabellen /etc/postfix/access_clientip viser IP-adresser og nettverk; /etc/postfix/access_helo lister domenenavn; /etc/postfix/access_sender inneholder e-postadresser til avsendere. Alle disse filene må bli omgjort til nøkkeltabeller (et format som er optimalisert for rask tilgang) etter hver endring med postmap /etc/postfix/fil-kommandoen.

Den tredje direktivet tillater administratoren å sette opp en svarteliste og en hvitliste med e-posttjenere, lagret i /etc/postfix/access_clientip-filen. Tjenere i hvitlisten anses som klarert, og e-poster som kommer derfra går derfor ikke gjennom følgende filtreringsregler.

De to siste regler avviser enhver melding som kommer fra en tjener oppført i en av de angitte svartelister. RBL er en forkortelse for Remote Black List. Det er flere slike lister, men alle lister dårlig oppsatte tjenere som spammere bruker for å videresende sin e-post, samt uventede post-formidlere, for eksempel maskiner infisert med ormer eller virus.

11.1.3.2. Sjekke gyldigheten til `EHLO` eller `HELO`-kommandoer

Hver SMTP-utveksling starter med en HELO (eller EHLO)-kommando, etterfulgt av navnet på e-posttjeneren som sender; det kan være interessant å kontrollere gyldigheten av dette navnet.

Eksempel 11.7. Restriksjoner på navnet som er meldt i EHLO

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname

Det første permit_mynetworks-direktivet tillater alle maskiner på det lokale nettverket fritt å legge seg til. Dette er viktig, fordi noen e-postprogrammer ikke respekterer denne delen av SMTP-protokollen godt nok, og de kan legge seg til med meningsløse navn.

Regelen reject_invalid_hostname avviser e-poster når EHLO-visningen lister et vertsnavn med feilaktig syntaks. Regelen reject_non_fqdn_hostname avviser meldinger når annonserte vertsnavn ikke er et fullt kvalifisert domenenavn (inkludert et domenenavn så vel som et vertsnavn). Regelen reject_unknown_hostname avviser meldinger hvis det annonserte navnet ikke finnes i DNS. Siden denne siste regelen dessverre fører til altfor mange avslag, snudde administratorene denne virkningen med en enkel advarsel ved hjelp av warn_if_reject-modifikatoren som et første skritt; de kan fjerne denne modifikatoren på et senere tidspunkt, etter å ha gjennomgått resultatene av å bruke regelen.

Å bruke permit_mynetworks som den første regelen har en interessant bieffekt: De følgende regler gjelder kun verter utenfor det lokale nettverket. Dette tillater svartelisting av alle verter som varsler seg selv som en del av falcot.com, for eksempel for å legge til en falcot.com REJECT You are not in our network!-linje til /etc/postfix/access_helo-filen.

11.1.3.3. Godta eller nekte basert på annonsert avsender

Hver melding har en avsender, annonsert av MAIL FROM-kommandoen fra SMTP-protokollen; igjen, denne informasjonen kan bli validert på flere forskjellige måter.

Eksempel 11.8. Sjekking av sender

smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain, reject_unlisted_sender,
    reject_non_fqdn_sender

Tabellen /etc/postfix/access_sender gir en noe spesiell behandling for noen avsendere. Dette betyr vanligvis å liste noen av avsenderne i en hviteliste eller en svarteliste.

Regelen reject_unknown_sender_domain krever et gyldig avsenderdomene, siden det er nødvendig for en gyldig adresse. Regelen reject_unlisted_sender avviser lokale sendere hvis adressen ikke eksisterer; dette forhindrer e-poster å blir sendt fra en ugyldig adresse i falcot.com-domenet, og meldinger som skriver seg fra joe.bloggs@falcot.com aksepteres kun dersom en slik adresse virkelig eksisterer.

Til slutt, reject_non_fqdn_sender-regelen avviser e-post som angivelig kommer fra adresser uten et fullt kvalifisert domenenavn. I praksis betyr dette å avvise e-postmeldinger som kommer fra user@machine: Adressen må bli annonsert som enten user@machine.example.com, eller user@example.com.

11.1.3.4. Aksept eller avvising basert på mottaker

Hver e-post har minst én mottaker, kunngjort med RCPT TO-kommandoen i SMTP-protokollen. Disse adressene garanterer også validering, selv om det kan være mindre relevant enn kontrollene av avsenderadressen.

Eksempel 11.9. Sjekk av mottaker

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient

Regelen reject_unauth_destination er den grunnleggende regelen som krever at meldinger utenfra adresseres til oss; meldinger sendt til en adresse som ikke er betjent med denne tjeneren, blir avvist. Uten denne regelen, blir tjeneren et åpent relé som tillater spammere å sende uønsket e-post. Denne regelen er derfor obligatorisk, og den tas best inn nær begynnelsen av listen, slik at ingen andre regler kan autorisere meldingen før destinasjonen er kontrollert.

Regelen reject_unlisted_recipient avviser meldinger som sendes til ikke-eksisterende lokale brukere, noe som gir mening. Endelig avslår reject_non_fqdn_recipient-regelen ikke-fullt-kvalifiserte adresser; dette gjør det umulig å sende en e-post til jean, eller jean@machine, og krever bruk av hele adressen i stedet, som for eksempel jean@machine.falcot.com, eller jean@falcot.com.

11.1.3.5. Restriksjoner knyttet til `DATA`-kommandoen

DATA-kommandoen til SMTP avgis før innholdet i meldingen. Den gir ikke noen informasjon per se (av seg selv), bortsett fra annonsere hva som kommer etterpå. Den kan fortsatt være underlagt sjekk.

Eksempel 11.10. DATA-sjekk

smtpd_data_restrictions = reject_unauth_pipelining

Direktivene reject_unauth_pipelining fører til at meldingen blir avvist hvis avsender sender en kommando før svaret på den forrige kommando er blitt sendt. Dette beskytter mot en vanlig optimalisering som brukes av spamroboter, siden de vanligvis ikke bryr seg det grann om svar, og bare fokuserer på å sende så mange e-poster som mulig på så kort tid som mulig.

11.1.3.6. Å bruke restriksjoner

Selv om de ovennevnte kommandoene kontrollerer informasjon på ulike stadier av SMTP-utvekslingen, sender Postfix bare selve avslaget i et svar på RCPT TO-kommandoen.

Dette betyr at selv om meldingen blir avvist på grunn av en ugyldig EHLO-kommando, kjenner Postfix avsenderen og mottakeren når avvisningen varsles. Den kan da logge et mer eksplisitt budskap enn om transaksjonen hadde blitt avbrutt fra starten. I tillegg trenger ikke en rekke SMTP-klienter å forvente feil med de tidlige SMTP-kommandoene, og disse klientene blir mindre forstyrret av dette ved denne senere avvisningen.

En siste fordel ved dette valget er at reglene kan akkumulere informasjon fra de ulike stadier i SMTP-utvekslingen. Dette tillater å definere mer finkornede tillatelser, som for eksempel avvise en ikke-lokal tilkobling hvis den melder seg med en lokal avsender.

11.1.3.7. Filtrering basert på meldingsinnholdet

Gyldighets- og begrensningssystemet ville ikke være fullstendig uten å kunne sjekke meldingsinnholdet. Postfix skiller mellom sjekking av topptekster i e-postene - fra den som gjelder selve meldingskroppen.

Eksempel 11.11. Å aktivere innholdsbaserte filtre

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Begge filer inneholder en liste med vanlige uttrykk (kjent som regexps eller regexes), og tilhørende tiltak som skal utløses når e-posthoder (eller kroppen) samsvarer med uttrykket.

Eksempel 11.12. Eksempelfil /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

DET GRUNNLEGGENDE Regulært utrykk

Betegnelsen regulært utrykk (forkortet til regexp, eller regex) refererer til et felles tegnsystem for å gi en beskrivelse av innholdet og/eller strukturen til en streng med tegn. Visse spesialtegn tillater å definere alternativer (for eksempel foo|bar samsvarer med enten «foo» eller «bar»), sett med tillatte tegn (for eksempel betyr, [0-9] hvilket som helst tall, og . - et punktum - betyr hvilket som helst tegn), kvantifiseringer (s? samsvarer enten med s, eller den tomme strengen, med andre ord 0 eller 1 forekomsten av s; s+ samsvarer med en eller flere påfølgende s tegn; og så videre). Parenteser tillater gruppering av søkeresultater.

Den presise syntaksen til disse uttrykkene varierer mellom de verktøyene som bruker dem, men de grunnleggende funksjonene er like.

→ http://en.wikipedia.org/wiki/Regular_expression

Den første sjekker toppteksten som viser til programvaren for e-mail; hvis GOTO Sarbacane (en samling e-post-programvare) blir funnet, blir meldingen avvist. Det andre uttrykket styrer meldingens subjekt; hvis det nevner et virusvarsel, kan vi bestemme oss for ikke å avvise meldingen, men straks å forkaste den i stedet.

Bruk av disse filtrene er et tveegget sverd, fordi det er lett å gjøre reglene for allmenne, og som resultat miste legitim e-post. I disse tilfellene vil ikke bare meldingene gå tapt, men avsenderne får uønskede (og irriterende) feilmeldinger.

11.1.4. Oppsett av grålisting

«Grålisting» («Greylisting») er en filtreringsteknikk der en melding som i utgangspunktet er avvist med en midlertidig feilkode, og bare aksepteres etter et ytterligere forsøk etter noen tid. Denne filtreringen er spesielt effektiv mot spam som sendes av de mange maskinene som er infisert av ormer og virus, fordi denne programvaren sjelden fungerer som en full SMTP-agent (ved å kontrollere feilkode, og prøve meldinger som har feilet på nytt senere), spesielt fordi mange av de oppsamlede adressene virkelig er ugyldige, og prøve dem på nytt bare ville bety å miste tid.

Postfix leverer ikke grålisting (greylisting) fritt, men det er en funksjon, der beslutningen om å godta eller forkaste en gitt melding, kan delegeres til et eksternt program. Pakken postgrey inneholder akkurat et slikt program, laget for å være bindeleddet til denne delegerte adgangspolitikktjenesten.

Så snart postgrey er installert, kjører den som en bakgrunnsprosess, og lytter på port 10023. Postfix kan så settes opp til å bruke den ved å legge til check_policy_service-parameteret som en ekstra begrensning:

smtpd_recipient_restrictions = permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Hver gang Postfix treffer denne regelen i regelsettet, vil den koble til postgrey-bakgrunnsprosessen, og sende den informasjon om den aktuelle meldingen. På sin side, vurderer Postgrey trillingen/trippelen IP-«adresse/avsender/mottaker», og sjekker i sin database om den samme trillingen er sett i det siste. Hvis ja, svarer Postgrey at meldingen skal godtas; hvis ikke, indikerer svaret at meldingen skal avvises midlertidig, og trillingen blir registrert i databasen.

Den største ulempen med grålisting er at legitime meldinger bli forsinket, noe som ikke alltid er akseptabelt. Det øker også belastningen på tjenerne som sender mange legitime e-poster.

I PRAKSIS Svakhetene i grålisting

Teoretisk bør grålisting bare forsinke den første posten fra en gitt sender til en gitt mottaker, og den typiske forsinkelsen er i størrelsesorden minutter. Virkeligheten kan, imidlertid, avvike noe. Noen store ISP-er bruker klynger av SMTP-tjenere, og når en melding innledningsvis er avslått, er kanskje den tjeneren som prøver å gjenoppta overføringen, ikke den samme som den opprinnelige. Når det skjer, får den andre tjeneren også en midlertidig feilmelding på grunn av grålisting, og så videre. Det kan ta flere timer før overføringen er forsøkt av en tjener som allerede har vært involvert, ettersom SMTP-tjenere ved hver feil vanligvis øker forsinkelsen.

Som en konsekvens kan den innkommende IP-adressen variere i tid, selv for en enkelt sender. Men det går videre; selv avsenderadressen kan endres. For eksempel; mange postlistetjenere koder inn ekstra informasjon i avsenderadressen, for å være i stand til å håndtere feilmeldinger (kjent som bounces). Hver ny melding sendt til en adresseliste kan så trenge å gå gjennom grålisting, noe som betyr at den må lagres (midlertidig) på senderens tjener. For svært store e-postlister (med titusenvis av abonnenter), kan dette fort bli et problem.

For å redusere disse ulempene administrerer Postgrey en hviteliste med slike steder, og meldinger som kommer fra dem, blir umiddelbart akseptert uten å gå gjennom grålisting. Denne listen kan lett tilpasses de lokale behov, ettersom det er lagret i /etc/postgrey/whitelist_clients-filen.

FOR VIDEREKOMMENDE Selektiv grålisting med milter-greylist

Ulempene med grålisting kan reduseres ved å bruke grålisting bare på undergruppen av klienter som allerede regnes som sannsynlige kilder til spam (fordi de er oppført i en DNS-svarteliste). Dette er ikke mulig med postgrey men milter-greylist kan anvendes på en slik måte.

I dette scenariet, ettersom DNS-svartelister aldri utløser en endelig avvisning, blir det naturlig å bruke aggressive svartelister, medregnet de som viser alle dynamiske IP-adresser fra ISP-klienter (for eksempel pbl.spamhaus.org, eller dul.dnsbl.sorbs.net).

Siden milter-grålisting bruker Sendmails milter-grensesnitt, er postfix-siden av oppsettet begrenset til «smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock». Manualsiden greylist.conf(5) dokumenterer /etc/milter-greylist/greylist.conf, og de utallige måter å sette opp milter-grålisting på. Du vil også måtte redigere /etc/default/milter-greylist for faktisk å aktivere tjenesten.

11.1.5. Å tilpasse filtre basert på mottakeren

Seksjon 11.1.3, «Restriksjoner for å motta og sende» og Seksjon 11.1.4, «Oppsett av grålisting» gjennomgikk mange av de mulige restriksjonene. De har alle sin nytte ved å begrense mengden mottatt spam, men har alle også sine ulemper. Det er derfor mer og mer vanlig å tilpasse filtrene til mottakeren. På Falcot Corp er grålisting interessant for de fleste brukere, men det hindrer arbeidet til noen brukere som har behov for korte forsinkelser på sine e-poster (som for eksempel teknisk supporttjeneste). Tilsvarende, den kommersielle tjenesten har noen ganger problemer med å motta e-post fra noen asiatiske leverandører som kan være oppført i svartelister; trenger denne tjenesten en ikke-filtrert adresse for å kunne utveksle e-poster.

Postfix gir en slik filtertilpasning med «restriction class»-konseptet. Klassene er deklarert i smtpd_restriction_classes-parameteret, og definert på den samme måten som smtpd_recipient_restrictions. Direktivet check_recipient_access definerer deretter en tabell som legger en gitt mottaker til det riktige settet med restriksjoner.

Eksempel 11.13. Definere begrensningsklasser i main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive = reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions = permit_mynetworks,
        reject_unauth_destination,Defining restriction classes in
        check_recipient_access hash:/etc/postfix/recipient_access

Eksempel 11.14. Filen /etc/postfix/recipient_access

# Adresser som ikke filtreres
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggresiv filtrering for noen privilegerte brukere
joe@falcot.com         aggressive

# Spesialregel for den som styrer epostlisten
sympa@falcot.com       reject_unverified_sender

# Grålisting som standard
falcot.com             greylisting

11.1.6. Å integrere en antivirus

Med mange virus som sirkulerer som e-postvedlegg, blir det viktig å sette opp et antivirus på inngangspunktet til bedriftens nettverk, da, til tross for en holdningskampanje, vil noen brukere fortsatt åpne vedlegg i åpenbart frynsete meldinger.

Falcot administrators valgte clamav som sin frie antivirus. Hovedpakken er clamav, men de installerte også noen få ekstra pakker, som arj, unzoo, unrar og lha, siden de er nødvendige for at antiviruset skal analysere vedlegg arkivert i ett av disse formatene.

Oppgaven med å koble sammen antivirus og e-posttjeneren legges til clamav-milter. Et milter (kort for postfilter (mail filter)) er et filterprogram spesielt utviklet for å kommunisere med e-posttjenere. Et milter bruker et standard programmeringsgrensesnitt (API) som gir mye bedre ytelse enn eksterne e-posttjenerfiltre. Milters ble først introdusert av Sendmail, men Postfix kom snart etter.

Så snart pakken clamav-milter er installert, skal milter settes opp til å kjøre på en TCP-port i stedet for på standarden som heter socket. Dette kan oppnås med dpkg-reconfigure clamav-milter. Når du blir bedt om «Communication interface with Sendmail», svar «inet:10002@127.0.0.1».

Standard ClamAV-oppsettet passer til de fleste situasjoner, men noen viktige parametre kan fortsatt tilpasses med dpkg-reconfigure clamav-base.

Det siste trinnet er å be Postfix å bruke det nettopp oppsatte filteret. Det er en enkel sak å legge følgende direktiv til /etc/postfix/main.cf:

# Virus-sjekk med clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

Hvis antivirus skaper problemer, kan denne linjen kommenteres ut, og service postfix reload skal kjøres slik at denne endringen er tatt hensyn til.

Alle meldinger som Postfix håndterer, går nå igjennom antivirusfilteret.

11.1.7. Godkjent SMTP

Å kunne sende e-poster krever tilgang på en SMTP-tjener; det krever også nevnte SMTP-tjener for å sende e-post igjennom den. For flyttbare enheter kan det trenges jevnlig endring av oppsettet til SMTP-klienten, ettersom Falcots SMTP-tjener avviser meldinger som kommer fra IP-adresser som tilsynelatende ikke tilhører selskapet. To løsninger finnes: Enten installerer brukeren en SMTP-tjener på datamaskinen sin, eller de fortsetter å bruke selskapets tjener med noen metoder for å autentisere seg som en ansatt. Den første løsningen er ikke anbefalt siden maskinen ikke vil være permanent tilkoblet, og ikke være i stand til igjen å prøve å sende meldinger i tilfelle problemer. Vi vil fokusere på sistnevnte løsning.

SMTP-autentisering i Postfix hviler på SASL (Simple Authentication and Security Layer). Det krever installasjon av libsasl2-modules og sasl2-bin-pakker, deretter å registrere et passord i SASL-databasen for hver bruker som trenger autentisering på SMTP-tjeneren. Dette gjøres med saslpasswd2-kommandoen, som krever flere parametre. Valget -u definerer godkjenningsdomenet, som må samsvare med smtpd_sasl_local_domain-parameteret i Postfix-oppsettet. Valget -c tillater å lage en bruker, og -f kan spesifisere filen som skal brukes hvis SASL-databasen må lagres på et annet sted enn opprinnelig (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... skriv inn passordet til jean to ganger ...]

Merk at SASL-databasen ble opprettet i Postfix-katalogen. For å sikre sammenhengen, omgjør vi også /etc/sasldb2 til en symbolsk lenke som peker på databasen som brukes av Postfix, med ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2-kommandoen.

Nå trenger vi å sette opp Postfix til å bruke SASL. Først må postfix-brukeren legges til sasl-gruppen, slik at den kan få tilgang til SASL-kontoens database. Et par nye parametere må også til for å aktivere SASL, og smtpd_recipient_restrictions-parameteret må settes opp til å tillate at SASL-godkjente klienter fritt kan sende e-post.

Eksempel 11.15. Oppsett av SASL i /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]

EKSTRA Autentisert SMTP-klient

De fleste e-postklienter er i stand til å autentisere til en SMTP-tjener før den sender utgående meldinger, og ved hjelp av denne funksjonen er det en enkel sak å sette opp de riktige parameterne. Dersom klienten som brukes ikke leverer den funksjonen, er den midlertidige løsningen å bruke en lokal Postfix-tjener, og sette den opp til å videresende e-post via den eksterne SMTP-tjeneren. I dette tilfellet vil den lokale Postfixen selv være klienten som autentiserer med SASL. Her er de nødvendige parameterne:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

Filen /etc/postfix/sasl_passwd må inneholde brukernavnet og passordet for å autentisere på mail.falcot.com-tjeneren. Her er et eksempel:

[mail.falcot.com]   joe:LyinIsji

Som for alle Postfix-funksjoner, må denne filen bli omgjort til /etc/postfix/sasl_passwd.db med postmap-kommandoen.