Min mailserver (del 4) - Systemadministration

Hver gang man laver en server, der er på Internettet, så kommer der en klar forpligtigelse til at holde den opdateret.
I de forrige blogindlæg (her her og her) lavede jeg en mail-server, og i denne blog-post vil jeg skrive lidt om sikker fjernadministration, firewall mv.

Opdateringer

Jeg har beskrevet hvordan man laver en mailserver baseret på Debian Linux. Derfor bør jeg følge Debians sikkerheds-mailliste: http://lists.debian.org/debian-security-announce/ og tilsvarende holde øje med at maskinen bliver opdateret løbende.

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

Til at holde øje med dette er "apticron" en god hjælp. Den giver en mail i døgnet om hvilke pakker der kan/skal opdateres.

$ sudo apt-get install apticron

En anden god ting at installere er "logwatch" som giver en daglig mail om hvilke fejl og pakkeændringer maskinen har set det sidste døgn.

$ sudo apt-get install logwatch

Sikker adgang fra Internet

Det er guld værd at kunne få fat i ens server hvor end man er. Til dette er der IMHO et værktøj, der kan anbefales langt foran alt andet: Secure Shell (SSH).

På serveren køres:

$ sudo apt-get install openssh-server

Man kan med stor fordel skifte port fra 22 til en port meget højere oppe f.eks. 32492. Det giver stort set ingen der prøver login via ssh pånær egne brugere.

$ sudo nano /etc/ssh/sshd_server

Lav følgende rettelser

  • Fra "Port 22" til "Port 32492"
  • Fra "PermitRootLogin yes" til "PermitRootLogin no"
  • Fra "PasswordAuthentification yes" til "PasswordAuthentification no"

Flere gode ideer kan f.eks. ses på dette link

De brugere som skal logge ind skal en gang lave et nøglepar, som giver adgang udefra via ssh:

$ ssh-keygen -t dsa 

Accepter placeringen ~/.ssh/id_dsa og giv et laangt password (det password/passphase der skal bruges ved SSH login om lidt.

Illustration: Privatfoto

$ cd ~/.ssh
$ cp id_dsa.pub authorized_keys
$ chmod .R go-rwx ~/.ssh  

Filen ~/.ssh/id_dsa er vigtig - den skal du have ud på de maskiner, hvorfra du skal kunne logge ind.
Kopier den ud via en usb-stick (eller evt. mail-serveren: "mail $USER < id_dsa").
Filen id_dsa kan se sådanne ud

(Opgave: Hvem kan dekode passphrasen ud fra dette?)

Fra en anden Linux/UNIX maskine kan man nu logge ind på serveren "mail.version42.dk" med

$ ssh pto@mail.version42.dk -i id_dsa -p 31007

Note: "pto" fordi det er den bruger jeg satte op. Dernæst "-p 31007" fordi det var den port jeg ændrede SSH-serveren til ovenfor.
Dette kan også sættes op i ~/.ssh/config så man slipper for at skrive så meget.

Fra Windows kan man bruge f.eks. Putty til at logge ind.
Nøglefilen skal dog først konverteres som vist på dette link

Chrome/Android har også ssh-klienter, der direkte kan anvende "id_dsa" nøglefilen - søg efter "ssh" eller "secure shell" i passende app-stores.

Firewall

Der er et par muligheder for at styre en firewall på en Linux-maskine. Jeg er konvergeret mod "ufw" som er ret nem at arbejde med

$ sudo apt-get install ufw

De porte jeg (pt.) gerne vil have oppe er

  • 80 til web-mail
  • 25 så der kan afleveres mail til serveren
  • 31007 til SSH-serveren

$ sudo su -
# ufw enable
# ufw allow 80
# ufw allow 25
# ufw allow 31007
# exit

Dvs. melodien er "ufw allow PORT" - og hvad der ikke er nævnt er lukket.
Dette blokerer bl.a. port "111" som ellers var åben og tilsvarende port 143 som "dovecot IMAP"-serveren bruger.

Som altid er I velkomne til at kommentere nedenfor.

/pto

Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Toft

Som altid er god systemadministration og sikkerhed en diskussion om paranoia. Jo mere man frygter - des mere skal man skærme af. F.eks. kan firewallen sættes til at blokere services med mindre man kommer fra kendte IP-adresser mv. Det er ikke vist ovenfor, og tilsvarende kan 24 timers respons på manglende opdatering være lang tid....

  • 0
  • 0
Henrik Knopper

Som altid er god systemadministration og sikkerhed en diskussion om paranoia.

Er det ikke for meget paranoia at bruge certifikater i stedet for alm brugernavn/password? Som du selv skriver får man meget få "hits" hvis man flytter porten op i det ukendte.

Og den anden ting - hvis 24 timers respons på en manglende opdatering er for længe, er det så ikke bedre at få maskinen til automatisk at køre en "sudo apt-get update + sudo apt-get upgrade" hver 3. time? Lidt mindre kontrol, men med en daglig mail om de ændringer der er sket kan man stadig følge med. Synes jeg.

  • 0
  • 0
Klaus Ellegaard

Man kan også diskutere, hvad en firewall skal bruges til på en server, som har ét ben og som kun kører meget få, specifikke services (som mail), der ikke har brug for portmap og lignende mareridt.

Hvis nogen kommer ind og starter en service på maskinen, så vil firewallen muligvis forhindre denne service i at snakke med omverdenen. Men så er vi jo allerede derhenne, hvor vi allligevel skal installere forfra og finde ud af, hvad vi gjorde galt.

Som med antivirus og IDS kan en firewall være den ekstra kompleksitet, der gør os dovne ("pyt med det sikkerhedshul, det tager firewallen sig af"), gør at ting ikke virker, eller ender med at lukke os ude fra en server i et andet postnummer.

Jeg siger ikke, at firewalls skal undgås for enhver pris. Det er bare endnu en vurderingssag: Har jeg virkelig brug for en firewall? Hvad er det helt præcist for et problem, jeg får løst ved at tænde for den? Og får jeg eventuelt flere problemer ud af at tænde for den, end jeg løser ved at gøre det?

"Best practice" giver jeg ikke noget for. Det må være "best practice" altid at finde ud af, hvad der vil være "best practice" for denne konkrete installation.

  • 5
  • 0
Esben Madsen

Jeg benytter personligt også fail2ban, der giver mulighed for at banne ip'er der prøver at logge uretmæssigt ind... når man kun har 3 forsøg før man er nødt til at skifte ip, så falder mængden af forsøg yderst markant... derudover blokerer jeg også fast for hele HiNet's CIDR-range (opdaterer via et bash-script en gang om ugen) da jeg flere gange oplevede mailserveren være hårdt presset og et par gange dø pga. hukommelsesmangel pga. forsøg på at levere spam fra disse ip'er (mønstret var noget i stil med ca. 10 forsøg/sekund pr ip og nogle gange fra op til en 20-30 ip'er der løbende skiftede)...

  • 0
  • 0
Claus Albøge

Normal praksis er at den private nøgle holdes privat og ikke sendes via mail!

Opret nøgler på de maskiner du arbejder på til dagligt (workstation/laptop) og kopier den offentlige nøgle til de servere du skal logge ind på. ssh-copy-id er ganske fint til formålet (men kræver selvfølgelig at du kan lave PasswordAuthentification første gang).

  • 2
  • 0
Jesper Poulsen

Hovedparten af mine mailbrugere har /usr/bin/passwd som shell. Alle kan logge ind via ssh. Det giver mulighed for at brugere selv kan skifte password uden at gøre det på en pivåben forbindelse.

Systembrugere der ikke skal bruge login har /usr/sbin/nologin som shell. Det er dermed ikke muligt at forsøge sig med f.eks. 'postfix' som brugernavn ved et loginforsøg.

  • 1
  • 0
Klaus Ellegaard

Det er altså noget fnidder.

Hvis en hacker er så ualmindeligt heldig, at hans bot rent faktisk kan gætte en username/password-kombination, skal der ikke meget ekstra held til, før botten prøver det i første eller andet forsøg. Og så er hele sikkerheds-cirkusset i fail2ban lige så væltet som Cirkus Arena i Kalundborg.

Med ssh.allow har man allerede været igennem bekymrende meget potentielt defekt kode, som gør, at man alligevel kan komme ind, hvis man har den rette "0-dAyZ" viden. Måske endda som root, og så hjælper PAM ikke, for der er vi slet ikke nået til endnu.

Bevares, ingen af dem skader, men det er mere cirkus end egentlig forebyggelse. Det tilfører samtidig noget kompleksitet og måske en masse spildtid, hvis man får lukket sig selv ude. Hvillket er ret nemt med begge metoder.

Der er også andre mere eller mindre obskure måder at prøve at narre fjenden. Her er en anden port til SSH et fint eksempel. Hvis ens botnet er stort nok, og man har en mistanke om at der efterhånden er tilpas meget bonus i at forsøge samtlige 65000+ porte, tjah, så tager ens portscanninger af en milliard IP-adresser nok et par timer ekstra. Så meget for den obskuritet (hedder det dét?)

Den eneste rigtige løsning er at forøge antallet af bits, der skal gættes, så tilpas meget, at det bliver usandsynligt. Her kommer nøgler ind i billedet - passwords skal være en halv roman lange, før de begynder at lugte sikre. Og vel at mærke ikke en rigtig roman, for den skal et eller andet botnet nok få prøvet af engang.

Så ud med alt det overflødige og ind med nøgler i en passende længde. Og eventuelt en firewall (således at botten ikke engang kommer i nærheden af sshds kode) foran, medmindre man kommer fra nogle veldefinerede adresser.

Og en firewall på samme fysiske maskine som det, man vil beskytte? Nej, vel? Så bruger man jo bare et hul i noget(tm), som vi med vilje har ladet være tilgængeligt, til at slukke for den firewall.

Pointen er, at alting er så tilpas automatiseret, så hurtigt og så distribueret, at intet snyderi virker.

Den bedste metode er stadig: definér en så lille "baseline" som overhovedet muligt, som du kan stole på (retteligt: VÆLGER at stole på). Hold den opdateret - og hold dig selv opdateret på alle tænkelige måder angående den baseline. Og glem alt om at prøve at snyde nogen, for det går bare ikke.

  • 3
  • 0
Peter Toft
  • 0
  • 0
Peter Toft

Man kan også diskutere, hvad en firewall skal bruges til på en server, som har ét ben og som kun kører meget få, specifikke services (som mail), der ikke har brug for portmap og lignende mareridt.

Det er klart bedre at smide firewallen (en anden boks) foran serveren, men er der andre maskiner i samme netværk som min så smider jeg også en ufw op på maskinen selv.

  • 0
  • 0
Baldur Norddahl

Bør man ikke skifte til elliptisk kurver: http://tools.ietf.org/html/rfc5656 ?

Det er tegn i sol og måne på at primtalskryptering kan blive svækket inden for få år. Derfor bør man allerede nu skrotte både DSA og RSA.

ssh-keygen -f /tmp/test -t ecdsa -b 521

En ECDSA nøgle på 521 bit skulle svare til en DSA eller RSA nøgle på hele 15360 bits!

Nøglefilerne fylder mindre og det skulle tilmed være hurtigere.

Ulempen er at ældre ssh klienter/servere måske ikke har support. F.eks. er der problemer med Putty, men en hurtig Google søgning antyder der findes en løsning i form af gpg-agent.

  • 0
  • 0
Thomas Kjeldsen
  • 1
  • 0
Thomas Kjeldsen

I dette tilfælde går det nok

Det er IMHO stadig en defekt vane at distribuere private nøgler, når man ligeså godt kan distribuere offentlige nøgler.

En ting er at du har privat nøglemateriale til at ligge et ukendt antal steder (det vil du ikke), en anden er at du med den praksis har forhindret dig selv i at lukke adgangen for en enkelt nøgle. Fx fra din stjålne laptop. Hvis du har samme private nøgle på alle arbejdsstationer skal du således til at distribuere ny privat nøgle til alle arbejdsstationer. Det er bagvendt og det er bøvlet. Hvis du derimod har offentlige nøgler fra dine forskellige arbejdsstationer i authorized_keys, så kan du nøjes med at fjerne linjen med den offentlige nøgle fra din stjålne laptop.

  • 1
  • 0
Jesper Nielsen

Som Peter skriver så falder forsøg på login til næsten ingen ting når men skifter port, så belastes serveren det mindre, og det betyder vel også lidt. Specielt hvis man har begrænset cpu kraft. I det store billed betyder det måske ikke så meget, men alligevel.

  • 1
  • 0
Simon Hughes

I dag har vi løsninger som f.eks. Virtualmin hvor alting virker out of the box. Det er godt nok skabt til ISPs, men med disse softwares får du, efter at have kørt installationen på en Linux boks, en gennemtestet og stabil server med mail, web, dns, ftp, etc samt features som antispam, daglig remote backup af alt, et simpelt Web GUI og - ja, den er god nok - Roundcube. Ting som SPF er der taget hånd om. SSL certifikat på HTTP, SMTP og IMAP? Ingen problem. Du skal bare oprette en bruger og et domæne. Det tager måske en halv time at få alt op at køre, inklusive køb af VPS hos f.eks. DigitalOcean.

Lige netop mailservere er et super svært projekt at begive sig ud i hvis det skal konfigureres korrekt når ikke man har megen erfaring. Og dog kan man jo sige at mailservere som regel er meget ihærdige med at levere mails, så din server kan godt være nede i et stykke tid uden at du nødvendigvis mister mails.

Det er selvfølgelig god læring - og sjovt - at få en mailserver op at køre, men der er mange config filer og timer involveret!

  • 0
  • 1
Jesper Poulsen

efter at have kørt installationen på en Linux boks, en gennemtestet og stabil server

Hvis jeg skulle bruge en færdigpakket løsning ville der ikke være meget grund til at bruge en Linux-maskine til det. Netop valgfriheden finder jeg utrolig effektiv ved opsætning af et system. Jeg bestemmer hvad der skal være og jeg bestemmer hvad der ikke skal være. Pakkeløsninger er til pakke-OS'er hvor alle valg er taget for en og hvor Modern UI er hvad man har at gøre med.

  • 0
  • 2
Simon Hughes

Først og fremmest kan du med Virtualmin kan du bestemme hvilke pakker du bruger, f.eks. sendmail eller postfix.

Desuden vil jeg da sige man godt kan betegne f.eks. Debian som et "pakke OS". Men jeg kan fornemme, du snakker om Windows? Først og fremmest ville jeg aldrig anbefale Windows til en personlig mailserver, det kan ikke køre på en 512MB VPS og er desuden også alt for dyrt.

  • 0
  • 0
Esben Madsen

jeg er for såvidt enig i at fail2ban aldrig vil blive en stor sikkerhedshjælp - grunden til at jeg bruger den er primært af rent performancehensyn: når botterne går amok med spam-mails (der bliver afvist for langt de flestes vedkommende) og loginforsøg, så kan en lille VPS med blot et par GB RAM hurtigt blive presset... under et par særligt hårde bølger har det været svært for mig selv at logge ind fordi maskinen simpelthen var overbelastet - efter jeg smed fail2ban på har jeg ikke oplevet det en eneste gang...

  • 0
  • 0
Log ind eller Opret konto for at kommentere