OpenBSD and smtpd

Finally there is a secure and easy-to-configurate substitute for ”Sendmail”, ”OpenSMTPD”!

OpenSMTPD (smtpd) first appeared in OpenBSD 4.6 and will probably replace sendmail as the default mail daemon in OpenBSD 5.1. With this in mind, I replased sendmail with smtpd when I upgraded my OpenBSD (4.8 to 5.0) routers/gateways a few weeks ago. Since they only send ”cron” emails there are not much traffic to talk about but it still feels great to finally replace the old dusty Sendmail.

Here are the steps I went through to get started with smtpd. For a reference see the maual pages at OpenSMTPD.org.

smtpd is not enabled by default. In order to use it as the system
mailer, ensure the mail queue is empty, then stop sendmail(8):

# pkill sendmail

Modify the current mailwrapper(8) settings by editing /etc/mailer.conf:

# cat /etc/mailer.conf
sendmail /usr/sbin/smtpctl
send-mail /usr/sbin/smtpctl
mailq /usr/sbin/smtpctl
makemap /usr/libexec/smtpd/makemap
newaliases /usr/libexec/smtpd/makemap

Rebuild the aliases database, and enable the daemon to run at boot:

# newaliases

# echo ”sendmail_flags=NO” >> /etc/rc.conf.local
# echo ”smtpd_flags=” >> /etc/rc.conf.local

The above parts was all taken from the manuals so here comes the parts that differs depending on the purpose with smtpd. My purpose is to accept outgoing mail from localhost (lo0) only and relay them through my Loopia email account using TLS authentication on port 587. More examples and informations can be found at calomel.org.

# cat /etc/mail/smtpd.conf
listen on 127.0.0.1 port 25
expire 4h
hostname my.local.domain
map ”aliases” { source db ”/etc/mail/aliases.db” }
map ”secrets” { source db ”/etc/mail/secrets.db” }
accept from local for local alias aliases deliver to mbox
accept from local for all relay via mailcluster.loopia.se port 587 tls auth ”secrets”

Since the mailserver uses authentication the username and password is saved in a separate file with restricted permissions.

# cat /etc/mail/secrets
mailcluster.loopia.se LOOPIA_USERNAME@mydomain.tld:LOOPIA_PASSWORD

# chmod 640 /etc/mail/secrets
# chown root:_smtpd /etc/mail/secrets

# cd /etc/mail
# makemap /etc/mail/secrets

Check the config for errors and start smtpd in the background.

# smtpd -n
configuration OK

# smtpd

See so it is working by sending an email to a local user or root depending on your  /etc/mail/aliases setup.

# smtpctl show stats | grep ‘mta.sessions=’

# echo ”A test message” | mail -s ”Subject” root

# smtpctl show stats | grep ‘mta.sessions=’

Email on successful login

If you have a server that you know nobody really should login to, it can be a good idea to track the few logins the server gets. I have done this on my OpenBSD router by telling /etc/profile (who runs on every login) to send me an email about every successful login. The line I added to /etc/profile looks like this:

echo -e ”Login on `hostname` `date` \n\n# w $(whoami)\n`w $(whoami)` \n\n# who -HTu\n`who -HTu`” | mail -s ”Login on `hostname` as (`whoami`)” root

What this do is that it collect some useful information about the user that has just logged in and sends an email to the root user. If you do not have set up an alias for the user it is possible to change ”root” in the command above to an email address. The email will look like:

Subject: Login on gw.localdomain as (username)

Login on gw.localdomain Sat Dec 17 12:04:17 CET 2011

# w username
12:04PM  up  2:37, 1 user, load averages: 0.40, 0.77, 0.90
USER    TTY FROM              LOGIN@  IDLE WHAT
username   p0 192.168.0.22    12:04PM     0 w username

# who -HTu
USER     S LINE     WHEN         IDLE    FROM
username   + ttyp0    Dec 17 12:04   .     (192.168.0.22)

Trådlös säkerhet finns det?

Efter att ha tittat på både SVTs dokumentär ”Att hacka en stormakt”, Uppdrag gransknings reportage ”Kapade nätverk” och SRs program ”Svenska Hackers” bara kliade det i fingrarna att skriva en replik.

Lite bakgrund till intrånget hos Nasa som gjordes i början av 1990-talet; här användes främst en bugg som fanns i många webbläsare som gjorde det möjligt att exekvera källkommandon direkt via en webbläsare. Den buggen är mer känd som PHF-buggen. Man kunde med andra ord besöka nästan vilken hemsida som helst och lista filen som innehöll användarnamn och krypterade lösenord som efter någon timma? knäcktes med passande program och passande ordlista.

http://www.liljedahl.me/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd

För mig helt otroligt att inte Nasa och andra organisationer rättade buggen eller på något sätt satte stopp åtminstone när den blev publik men säkerhetstänkandet var väl inte prio ett då. Frågan är då:

- Är det bättre nu?

Problemet enligt mig kvarstår dock har målet för attackerna ändrats från ”Nasa” till privatpersoner/grannen. Hur många har inte surfat på grannens trådlösa nätverk första månaden i den nya lägenheten innan ens eget bredband kopplats in? Som tur är scannar inte många av trafiken från grannen och samlar lösenord eller kontokortsnummer. Att det var möjligt att göra var det nog inte många som hade reflekterat över innan Uppdrag gransknings reportage. Tror nog många kommer få panik när de inser att deras trådlösa nätverk är oskyddat eller inställd på WEP-kryptering. Faktum är att för att WPA och WPA2 ska fungera någorlunda bra måste både lösenordet och namnet på accesspunkten ha ett unikt namn (SSID) annars är WPA och WEP ganska lika när det kommer till o-säkerhet.

Skillnaden mellan WPA och WPA2 är inte så stor som mellan WEP och WPA. I kort har WPA2 en högre kryptering via AES och CCMP medan WPA har en sämre kryptering via TKIP. WPA2 är dock bakåtkompatibel så nyare utrustning kan användas i WPA-nätverk om man så önskar.

Att som det sägs ”Hacka ett trådlöst nätverk” är idag inte svårt, man behöver knappt veta vad man gör. Det är bara att starta ett program och sedan vänta lite så är det klart. Algoritmen för ett WPA-PSK lösenord ser i kort ut enligt följande:

64-bit_nyckel = PBKDF2(mitt_lösenord, ssid, 4096, 256)

Här ser man snabbt att man har nästan alla delar i högerledet så när som på ”mitt_lösenord”. Basstationens namn, SSID visas i klartext och kan ses i listan över tillgängliga nätverk och siffrorna är konstanter. Vill man försvåra lite kan man när man sätter upp sin basstation eller ”router” välja att SSID inte ska synas. För användaren betyder det att det blir lite ”svårare” att ansluta då man måste ange namnet i en ”avancerad” anslutning. Avlyssnar man trafiken ett tag är det dock möjligt att se även SSID för en basstation som har valt att det ska vara dolt.

Efter som alla delar i algoritmen nästan är kända kan man tänka sig att sitta och prova ”lite” lösenord och det är just denna teknik som används för att ta sig in på WEP och WEP2 nätverk. Tekniken kallas för dictionary attack eller ordliste attack, ett program provar en massa kända ord/lösenord från en ordlista. Det är med andra ord mycket viktigt att de lösenord man använder inte finns med i någon ordlista! Rekommendationen är att det ska vara minst 13 slumpmässiga tecken långt samt innehåller både gemener, varsaler, siffror och specialtecken så som snabela, plus, minus och så vidare. Viktigt är också att ens SSID inte finns med på topplistan över de vanligaste namnen exempelvis ”NETGEAR”, ”default” eller ”linksys”.

För att generera ett bra lösenord måste jag rekommendera en site jag gjorde för några år sedan: passwordgenerator.se

I WPA-protokollet finns det även en känd bugg när Quality of Service (QoS) är påslaget som i kort låter klienterna dekryptera trafiken och även injicera egna paket. Det skyddar man sig bäst emot genom att stänga av QoS.

Känner man sig osäker på sitt trådlösa nätverk måste nog rekommendationen vara att använda en kabel eller kanske till och med inte alls koppla upp sig mot Internet. Speciellt inte publika nätverk, kom precis att tänka på alla mobiltelefoner som konstant är uppkopplade och skickar lösenord och annan känslig information både kort och tvärs. Finns en hel del att göra vad gällande säkerheten även för mobiltelefoner.

Tidigare skrev jag en artikel om att använda SSL/HTTPS för Facebook. Innebörden av det är att om någon skulle avlyssna min trafik så är den krypterad, vilket betyder att inga lösenord eller användarnamn skickas i klartext. Vad jag kan se så använder samtliga banksidor SSL-kryptering vilket är bra dock borde alla sidor med någon form av inloggning använda sig av det. I fallet Facebook behöver man manuellt lägga till s-ett i http och så funkar det på många andra siter också.

- Så, 20 år senare, har Internet blivit säkrare? Eller har vi gått bakåt?

Facebook och SSL

Som många andra använder jag Facebook och har länge stört mig på att de inte defaultar anslutningen till att använda SSL/HTTPS. Vad är orsaken mån tro? Klarar inte servrarna den extra belastningen? Slår ett slag för https://www.facebook.com/ !

Bra jobb med DNSSEC Tele2

När jag och min sambo flyttade in i den nya lägenheten i Västerås fick vi nöja oss med en anslutning på 8/1 Mbit/s via TV-uttaget från Tele2. Utrustningen Tele2 använde då var konfigurerad med DNSSEC-stöd. Snacka om att jag blev förvånad när de i slutet av året uppgraderade anslutningen till ett datajack med 100/100 Mbit/s och stödet för DNSSEC inte längre fanns.

Lite kort om DNSSEC så används det för att göra säkrare uppslagningar på domännamn vilket gör att det blir betydligt svårare att förfalska exempelvis webbaddresser. Det är ännu inte så utbrett men är klart något som är här för att stanna. Loopia ligger långt fram med denna teknik och erbjuder detta för samtliga .SE-domäner.

Givetvis ringde jag Tele2 för att påtala detta och personen som svarade hade ingen aning om vad DNSSEC var och när jag förklarade vad det var fick jag ett snabbt svar att ”Det har vi inte stöd för” och se bröt han samtalet. Jag skickade då ett meddelande till dem i samma ärende och efter nästan två månader fick jag samma svar igen.

För någon vecka sedan upptäckte jag till min glädje att de nu slagit på DNSSEC-stödet igen, bra jobbat! Jag ska inte gnälla om IPv6 då Hurricane Electric för inte allt för länge sedan satte upp en tunnel i Stockholm som fungerar mycket bra.

För den intresserade kan jag rekommendera Wikipedias artiklar om DNSSEC och  IPv6. Är du osäker på om din Internetleverantör har stöd för DNSSEC kan du scrolla ner en bit här på Liljedahl.ME och leta efter rubriken ”DNSSEC” i menyn till höger. Vill du sedan lägga upp en likadan widget på din WordPressblogg så har jag gjort den tillgänglig för nedladdning via WordPress.