Som allerede annonceret i mit forrige blogindlæg vil jeg skrive en lille blogserie om at lave egen mail-server.
Jeg har lavet en masse valg så forvent at andre nok vil lave anderledes valg - klassisk "issue" for Linux-geeks :)
I dette indlæg når jeg kun til at have en Linux maskine online så den kan pinge maskiner indefra og kan pinges udefra.
Det første valg er styresystem. Jeg har kørt to servere et par år - en med Debian og en med Ubuntu desktop. Administration er reelt ens for mig - men der er stor forskel i hverdagen på de to. Der er markant flere program-opdateringer på en Ubuntu-maskine end en Debian. Sagen er at en Ubuntu (desktop) default installerer en masse program-pakker, der omhandler desktop-anvendelse. Det er for en vilkårlig server rart at have få programmer installeret som ikke kræver mange opdateringer. Jeg er kedelig og konservativ så Debian er et godt valg.
Naturligvis kan man snitte en en Linux-variant på tilsvarende måde - men jeg fortsætter med Debian.
Før jeg skriver lidt om installation, så skal man have købt et domæne, og lavet en navneopslag (f.eks. en A-record) for dette. Jeg har for det meste anvendt GratisDNS.dk - det har fungeret fint i mange år.
Boot maskinen. Jeg vælger tekst-mode installation, men grafisk installation er også fin. Det er samme information man skal igennem.
Vælg Danish et par gange
Vælg maskin-navn - vælg det som du skrev ind i DNS-systemet.
Vælg root-password
Til sidst skan man vælge hvor meget der skal installeres. Som det kan ses af næste billede kører jeg konservativt - kun SSH-server og basis-programmer. Resten tilføjer vi senere.
Sluttelig skal man installere GRUB (boot-program) og reboote.
Efter en genstart skal man logge ind som den valgte bruger.
Check om der er netværk udadtil f.eks. ved at pinge version2.dk - du kan forvente svartider på 30-70 ms
Vi er ikke helt igennem. Debianmaskinen kører DHCP når den ikke er sat op
og det skal ændres til fast adresse når det er en mail-server vi sætter op.
Kører du hjemme bag en router, så skal du til at finde en IP-adresse til maskinen. Kører du hostet så spring til næste afsnit.
Se hvilken adresse maskinen har med "/sbin/ifconfig eth0".
Tilsvarende skal gateway checkes med "/sbin/route" (se under Gateway).
Ofte er dine netadresser 192.168.0.x (hvor x er et lavt tal) hjemme og her kan 192.168.0.254 eller en anden "høj" adresse fint bruges som fast intern adresse set fra din router.
Tilsvarende kan 10.0.0.254 bruges hvis"/sbin/ifconfig eth0" viste 10.0.0.x. Netmasken er stort set altid 255.255.255.0 for hjemmenetværk. Gateway er den samme som den
/sbin/route viste før.
Er maskinen hjemme bag en router så går turen til routeren. Login[1] og led efter NAT - du skal nu lave en regel at den ydre IP-adresse skal routes til den indre IP adresse du lige har opsat som fast adresse.
Skift til root og rediger f.eks. med "nano /etc/network/interfaces" (alternativ til "vi") - tallene skal du ikke genbruge :)
Ret filen med din faste adresse (den indre bag routeren hvis maskinen står hjemme ellers anvend IP-adresse fra IT-udbyderen).
I /etc/hosts skal du også rette og have en linie med den interne IP-adressen - I mit tilfælde
91.221.196.203 toft.petertoft.dk
Har du valgt hosting ude til maskinen så er det naturligvis anvende den IP-adresse som du har "købt".
Genstart nettet med
/etc/init.d/networking stop && /etc/init.d/networking start
Prøv igen at pinge version2.dk igen. Den skal stadig svare.
Nu skal du prøve at pinge maskinen udefra med din eksterne IP-adresse. Det kan f.eks. gøres på https://www.wormly.com/test_remote_ping
Tilsvarende skal du kunne pinge maskinen på det navn du registerede i DNS.
Svarer maskinen, så er du langt. Nu kan vi lægge web-server på og mail-server. Det ser jeg nærmere på i næste blogindlæg.
/pto
[1] De sidste routere jeg har set fra Yousee og Telenor har login "admin" og password "password" - bekymrende....
Der er lidt kludder i et par afsnit (delvis dubleret). "Som allerede annonceret..." og "Det første valg er styresystem...." findes to gange. Og efter "Raspberry" mangler der enten et punktum eller noget tekst. Og "partiotionering".
Der var en masse snak om hvor du skulle host'e serveren. Har du valgt nogen? Så vidt jeg kan se af IP-adresserne i screenshots er det stadig hjemme-adressen, der holder for.
Alt efter overbevisning, kan man jo også bruge DHCP og så styre IP tildelingen på DHCP serveren (reservationer).
Hvis man ikke laver reservationer, kan man jo altid falde tilbage på lokale DNS opslag. :)
Granted, hjemmenetværk er små ... :D
Du skriver at du overvejede en Ubuntu Desktop og en Debian - hvorfor var en Ubuntu Server ikke inde i billedet?
Jeg har indtil fornyligt kørt det hele (www, mail, backup) via en ubuntu server og det virkede ganske fint.
Rettet - takker.
Maskinen står pt. hos Larsen Data - nice
Skal din mailserver hoste mails for flere domains? Jeg har en Postfix kørende med tre domains på den samme server. Tingene bliver en smule mere komplekst med et sådant setup. Eller måske er jeg bare ikke Postfix-ninja nok.
Med en verden fuld af spam og onde mennesker er det i det hele taget lidt en videnskab at sætte en mailserver korrekt op. Men hey, det er jo også derfor, det er sjovt! :-)
Jeg kører på en Ubuntu 12.04 LTS Server. I dag ville jeg nok vælge en "rå" Debian. Den står i privaten med en 50/50 mbit fiber. Og det som startede ud som simpel mail og http server, er i dag cloud storage (ownCloud), TV-backend (MythTV), RSS Reader (tt-rss), VPN-forbindelse (OpenVPN) og en masse andre sjove sager, jeg kan få fat i fra hele verden.
Ja da - flere domæner kommer :)
Hvordan håndtere du det her med redundans til din ownCloud? Har du en separat server der tager en kopi eller kører du et raid?
Jeg går og pønser på at have sådan en fiks sag der, men jeg har udfordringer ved at hitte ud af hvad der egentligt skal til for at jeg ikke pludselig står med bagdelen i vandskorpen og uden data.
En løsning der selvfølgelig kører på et budget. Der skal ikke smides 100000 efter en løsning, fordi så kan man bare købe hvad som helst. Men en praktisk, fornuftig løsning modtages gerne.
Kører selv med Virtualmin (en overbygning på Webmin), det tager selfølgelig en del af morskaben med at nørkle rundt i config filer, men er til gengæld supernemt at sætte op, og at administrere efterfølgende. Skal dog siges at Virtualmin giver dig hele "hosting" pakken (web,mail,ftp), så ønsker man en ren mail server er det nok ikke det helt korrekte valg.
En Mailcleaner foran og der er antispam og AV (morderligt effektivt). Firewall valget er faldet på pfSense.
Nu er det nok en lidt voldsom konstellation for et normalt hjemmesetup... men sjov er det :-)
Med mindre du vil anvende en relay-SMTP-server, er det vigtigt at du får opsat reverse DNS for din mail-servers IP-adresse. Der er mange steder på nettet at mails fra servere der ikke har korrekt rDNS, afvises. Det skal altså være muligt for en mailserver i den anden ende at verificere at din mail-servers påståede navn svarer til det der kan slås op via rDNS og at forward DNS på navnet også resulterer i den IP-adresse du anvender.
Hvordan håndtere du det her med redundans til din ownCloud? Har du en separat server der tager en kopi eller kører du et raid?
Min ownCloud-instans er ikke så gammel, og er mest på legestadiet. Lige netop redundans er en af de ting, jeg stadig overvejer. Jeg er nok bare nået til den erkendelse, at med en 5,5 TB NAS som storage er det ret omfattende at sætte redundans op mod en af de kendte tjenester på nettet. Måske man i stedet skulle lave en aftale med en anden fiberkunde/kollega/ven/whatever om at udveksle noget isenkram. Alternativt holde sin backup/spejling til vigtige ting ...
Med mindre du vil anvende en relay-SMTP-server, er det vigtigt at du får opsat reverse DNS for din mail-servers IP-adresse. Der er mange steder på nettet at mails fra servere der ikke har korrekt rDNS, afvises. Det skal altså være muligt for en mailserver i den anden ende at verificere at din mail-servers påståede navn svarer til det der kan slås op via rDNS og at forward DNS på navnet også resulterer i den IP-adresse du anvender.
Og det er en uskik som især tumperne fra Trend Micro hylder.
Hvilket bla. betyder at Amazon og andre cloududbyder bander dem ned i helvede, fordi det gøre det meget svært at håndtere virtuelle servere i skyen.
Til gengæld er det effektivt mod spam, da rigtigt meget kommer fra DHCP-adresser. Hos os afvises over 95% af alle mails validt pga. dette check. Det bør heller ikke være særlig svært for en professionel mail-udbyder at håndtere rDNS.
Min udfordring ligger bl.a. at jeg gerne så at udover mail og et par andre ting, havde et udviklingsmiljø med en virtual server jeg kan remote desktoppe til og med tilhørende ownCloud så ender det i en del plads der bliver brugt.
Jeg overvejede at have 2xNas stående og lave "redundans" til, men det garantere kun mod disk nedbrud og ikke noget andet, så er der jo det alternative med at have en af dem stående et andet sted, efter den første cloning er udført, så man kun skal trække nyt data. Men jeg synes ikke jeg har fundet en tilfredsløsning endnu.
Til gengæld er det effektivt mod spam, da rigtigt meget kommer fra DHCP-adresser. Hos os afvises over 95% af alle mails validt pga. dette check. Det bør heller ikke være særlig svært for en professionel mail-udbyder at håndtere rDNS.
Det er så noget rigtigt pladder (ikke det du siger, men løsningen) - dels er det voldtægt af standarderne, dels udelukker det alle de mailservere som f.eks. sidder på en aDSL forbindelse, men er legitime nok.
Eksempelvis så kan privatkunder hos Telenor ikke få en rDNS, selv om de har fast IP.
Og faktisk så afvises stort set ligeså meget vha. Graylisting (som så også er voldtægt af standarder), men uden at udelukke dem der reelt har en mailserver stående.
Hele dette pjat kunne løses enkelt (men hvordan får man det budskab videre?) hvis man lavede en enkelt ændring til hele e-mail paradigmet, nemlig en form for challenge response:
Jeg (chr@xxx) skal sende en mail til dig@yyy:
1 - mailen lægges i kø på min mailserver (xxx).
2 - min mailserver kontakter yyy og siger der er en mail til dig.
3 - yyy siger, ok jeg vender tilbage
4 - yyy laver navneopslag (ikke rDNS!) og finder xxx.
5 - yyy kontakter xxx og spørger om den har en mail i kø til dig fra mig.
6 - hvis ja, så beder yyy om mailen.
7 - mailen leveres.
På den måde vil det være et krav at en mailserver skal have et domæne og være legitim - dvs. hvis nogen sender spam, så kan de fanges omgående.
Ganske interessant projekt.
Jeg selv har bygget et fuldt domænehotel (mail + web) til min arbejdsplads, hvor alle informationer om både brugere og domæner ligger i en MySQL database.
System autentificering sker via libnss-mysql.
Og både Postfix og Courier (som jeg har valgt) kan også bruge MySQL. Jeg har så begrænset logins til sftp/scp og rsync via ssh, så brugerne har ikke fuld shell adgang (nogen har dog). Det er gjort med rssh.
http://libnss-mysql.sourceforge.net/
http://www.postfix.org/MYSQL_README.html
http://www.courier-mta.org/authlib/README.authmysql.html
http://www.pizzashack.org/rssh/
Jeg ville være interesseret i at se hvordan DMARC, SPF og DKIM sættes op på en mailserver i linux. Ville det være noget du kunne kaste dig ud i?
Alle 3 teknikker er anti-spam.
Det jeg mener med at sætte det op er både således at din mailserver verificerer indkommende mail op imod DMARC, men også så at den kan signere udgående mail (med DKIM).
Lige kort om teknikkerne:
SPF:
DNS Records der siger hvilke IP adresser der må sende mails for et domæne
DKIM:
Signering af emails på domæneniveau. DNS Records indeholder public key, og mail provider har private key. Alle mails bliver derefter signeret.
DMARC:
Kombinationen af de to, DMARC siger hvordan et domænes mail skal håndteres når det fejler SPF, DKIM eller begge to.
Hele dette pjat kunne løses enkelt (men hvordan får man det budskab videre?) hvis man lavede en enkelt ændring til hele e-mail paradigmet, nemlig en form for challenge response:
Jeg (chr@xxx) skal sende en mail til dig@yyy:
1 - mailen lægges i kø på min mailserver (xxx).
2 - min mailserver kontakter yyy og siger der er en mail til dig.
3 - yyy siger, ok jeg vender tilbage
4 - yyy laver navneopslag (ikke rDNS!) og finder xxx.
5 - yyy kontakter xxx og spørger om den har en mail i kø til dig fra mig.
6 - hvis ja, så beder yyy om mailen.
7 - mailen leveres.På den måde vil det være et krav at en mailserver skal have et domæne og være legitim - dvs. hvis nogen sender spam, så kan de fanges omgående.
Det lyder faktisk ret enkelt.
Ærgerligt at nogen ikke har implementeret det parallelt med det sædvanlige system.
Men det minimerer jo behovet for lappeløsningerne til SMTP.
K
Husk at sætte 'firewall' op, f.eks. med Ip Tables. Og du må gerne skrive om at gå på SSH med private keys istedet for passwords (det gør din SSH så godt som ubrugelig for uvedkommende).
Det bliver helt sikkert :)
:) ... og sætte iptables / ssh keys op og teste før du NAT'er den ud på nettet.
Jeg plejer som regel at allowe 22 ind, før jeg gør noget andet :D
Om ikke andet kan maskinen bare rebootes, iptables gemmes jo ikke automatisk :P
iptables gemmes jo ikke automatisk
Normalt gemmer man sine iptable regler i et iptables script når man mener den virker. Dette script eksekveres af init ved boot lige før netværket er oppe.
På mine rackspace servere har jeg i det store og hele fulgt rackspaces udmærkede vejledning, som alle kan tilgå her: http://www.rackspace.com/knowledge_center/article/rackspace-cloud-essent...
Det er værd at bemærke, at RS serverne er født med to netværks interfaces - et der vender ind mod det vlan man har fået tildelt (eth1) og et der vender ud mod internettet (eth0).
Første handling på første server er derfor at lukke ned for eth0 og derefter konfigurerer iptables (og ssh) med en (sic) Java baseret shell. Derefter har man et brugbart 'golden image',man kan arbejde videre med.
Med en hjemmeserver, som f.eks. Peters mailserver, kan man i ro og mag gøre ovenstående før man NAT'er, men man kan jo også bare tage chancen. Før du gør det, så prøv f.eks. at lave en 'blind' NAT for de typiske porte såsom 21, 22, 80, 443 etc. i din router og så se hvor meget trafik du lige pludselig får udefra.
Granted. Gør jeg også, mente det blot som safeguard over for at låse sig selv ude (ie. det var en bonus at de ikke gemmes automatisk). :)
Vi kører vores mailserver baseret på denne tutorial med lidt ekstra tilsat.
https://workaround.org/ispmail
Det er et fint opslagsværk hvis du fx lige skal finde ud af hvordan Dkim skal sættes op.
