En blogg om IT-säkerhet och relaterade ämnen för dem som arbetar inom IT

Konfigurera SSH för ökad säkerhet

Det finns några steg man bör ta efter att man installerat SSH på ditt system. En kedja är inte starkare än den svagaste länken och gällande SSH är ett svagt lösenord till t.ex. root ett allvarligt hot.

Det vi skall göra är att skapa ett certifikat och stänga av möjligheten att logga in utan certifikat. Vi skall även kontrollera så att root inte får logga in då det är mycket bättre att använda sudo när administratörsrättigheter behövs. Vidare skall vi stänga ner några krypteringsmetoder som inte anses som fullt så säkra samt öppna upp för visuell identifiering av serverns “fingeravtryck”.

Skapa nyckel
Vi väljer att använda en RSA-nyckel på t.ex. 4096 bitar. Öppna ett terminalfönster och skriv in följande: ”’ssh-keygen -t rsa -b 4096”’. 1024 sägs vara tillräckligt säkert men man kan aldrig vara för säker

johan@johan-laptop:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.

Du får sedan upp en fråga var du vill spara din nyckel. Har du redan nycklar i id_dsa bör du ange ett annat namn för filen skrivs över annars. Är du nöjd med förlaget tycker du bara retur

Enter file in which to save the key (/home/johan/.ssh/id_rsa):

Sedan skall du ange lösenord. Tänk på att blanda stora och små bokstäver samt lägga in tecken och siffror. Längden är dock en mycket viktig faktor så gör det hellre längre än kort och komplext. Gärna en liten mening som hjälper dig att komma ihåg lösenordet utantill eller absolut bäst är att använda t.ex. Keepass för att både skapa slumpmässiga lösenord men även spara dem på ett krypterat och säkert sätt.

Enter passphrase (empty for no passphrase): M1tt H3ml1g@ löSe40rD
Enter same passphrase again: M1tt H3ml1g@ löSe40rD
Your identification has been saved in /home/johan/.ssh/id_rsa.
Your public key has been saved in /home/johan/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:xx:xx:xx:xx

Installera den publika nyckeln i systemet
Den publika nyckeln skall läggas i ~/.ssh/authorized_keys och det kan finnas fler nycklar än en. Se till att göra radmatning mellan nycklarna.
Om nyckeln skall installeras på samma system kopierar du helt enkelt id_dsa.pub till authorized_keys.

johan@johan-laptop:~$ cd ~/.ssh
johan@johan-laptop:~/.ssh$ cp id_rsa.pub authorized_keys

Skulle det vara en extern maskin kan du använda scp för att kopiera nyckeln, tänk då på att du inte skriver över authorized_keys om det skulle finnas existerande nycklar i filen. För att kopiera (skriva över befintlig fil) gör du följande

johan@johan-laptop:~/.ssh$ scp -p ~/.ssh/authorized_keys 192.168.0.1:.ssh/
johan@192.168.0.1’s password:
authorized_keys 100% 1839 1.2MB/s 00:00

Se även till att ~/.ssh/autorized_keys och ~/.ssh/id_rsa endast har gällande användares rättigheter. Vid problem använd chmod 600 för att åtgärda.

Konfigurera sshd
Nästa steg är att kontrollera inställningarna för sshd. Filen vi skall modifiera heter /etc/ssh/sshd_config
Börja med att skapa en säkerhetskopia av sshd_config

johan@johan-laptop:/$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup
Password:

Sedan använder vi lämplig editor för att modifiera sshd_config

johan@johan-laptop:/$ sudo nano /etc/ssh/sshd_config

Följande rader skall ändras:

• LoginGraceTime 120
• PermitRootLogin yes
• Ciphers

 

• LoginGraceTime 30

LoginGraceTime är antalet sekunder innan man blir utkastad om man inte lyckas med inloggningen. Det är en smaksak men 120 sekunder behöver man normalt sätt inte på sig. Sänk den med fördel. Dock bör du hinna ange ditt lösenord innan tiden går ut.

• PermitRootLogin no

Root behöver inte kunna logga in via ssh. Du kan använda sudo istället vilket är mycket säkrare.
Vi skall även lägga till en så att man förhindrar möjligheten att logga in med hjälp av användarnamn och lösenord vilket betyder att man tvingas använda certifikat. Lägg till:

• PasswordAuthentication no
• Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

Ciphers ändrar vi på grund av en potentiell sårbarhet i vissa krypteringsmetoder, mer information om dessa här:
[1] http://openssh.org/txt/cbc.adv
[2] http://www.cpni.gov.uk/Docs/Vulnerab…visory_SSH.txt
[3] http://www.cs.washington.edu/homes/y…pers/TISSEC04/

Kontrollera även så att följande rader så att standardinställningarna stämmer:

• Protocol 2
• UsePrivilegeSeparation yes
• StrictModes yes
• RSAAuthentication yes
• PubkeyAuthentication yes

Spara och avsluta.

Nu skall vi bara starta om sshd så att de nya inställningarna tar.

johan@johan-laptop:~/.ssh$ sudo /etc/init.d/ssh restart
Password:
* Restarting OpenBSD Secure Shell server… [ OK ]

Konfigurera ssh för visuell värdnyckel (Visual Host Key)
När man loggar in mot en viss värd är det inte så lätt att identifiera att det är rätt maskin, någon kan till exempel ha styrt om din DNS till en annan maskin och på så sätt lura dig att logga in i fel maskin för att stjäla kontouppgifter.

För att lösa detta har gänget bakom OpenSSH utvecklat en visuell representation av nyckeln så att det blir mycket lätt att känna igen sitt egna system. För att aktivera VisualHostKey skall man ändra i antingen /etc/ssh/ssh_config vilket gäller alla användare eller ~/.ssh/config för en personlig inställning

Lägg till följande i konfigurationen (“Host * finns redan överst i ssh_config)

Host *
VisualHostKey yes

Byta från standardport 22?

Det innebär ingen direkt ökad säkerhet att ändra port, men man slipper de flesta script-kiddies attacker och maskar när man flyttar sig från standardportar. Detta gäller samtliga tjänster och inte bara ssh. Det man kan skydda sig mot genom “säkerhet via oreda” är att en mask eller script som snabbt scannar nätet efter en ev. 0-day sårbarhet missar systemet vilket är mer tur än skicklighet för om någon verkligen vill in så gör man en mer noggrann kontroll av det system man vill in i. Om man ändå vill byta är det bäst att lägga sig mellan 0 och 1023 då dessa är privilegierade vilket betyder att endast konton med administrativa rättigheter kan starta tjänster och därför slipper man hamna i en riggad tjänst startad av en användare som t.ex. loggar lösenord.

Testa och verifiera
Testa att logga in i systemet. Glöm inte av att du har bytt port. Du måste även ange användarnamn om du inte har samma användarnamn på fjärrdatorn som den lokalt inloggande användare. Detta gör du genom att skriva användarnamn@server.ip

johan@johan-laptop:/$ ssh johan@localhost -p 10022
Host key fingerprint is 66:12:14:8a:31:23:4f:86:13:f2:1c:4d:33:dd:d4:67
+–[ RSA 4096]—-+
| |
| .o |
| . =o .|
| . += E|
| + S . .o|
| . + .. o|
| . o.= |
| +o+ o|
| +=o |
+—————–+
Enter passphrase for key ‘/home/johan/.ssh/id_dsa’:

Nu är du säkert inloggad i ditt system

–Johan Ryberg

Detta är fortsättningen av Sluta använda lösenord! Del 1 av 2 i vilket jag tänkte ta upp en viktig del gällande användandet av KeePass, nämligen hur man får en bra tillgänglighet till sina lösenord genom synkronisering av databasen.

Om man använder KeePass i sitt yrke är det mycket viktigt att man följer företagets policy och det är inte säkert att de exempel jag tar upp är godkända så kontrollera med er IT-avdelning innan du börjar att synkronisera ditt valv.

Det finns ett par olika alternativ och KeePass 2.x har stöd för lokal synkronisering vilket är riktigt bra när man arbetar i en organisation där många samtidiga användare använder en och samma databas. Detta löser dock inte tillgängligheten om man behöver komma åt samma databas från flera olika ställen som t.ex. från bostaden, sin laptop och arbetet.

Beroende på vilket behov av säkerhet du har så finns det olika lösningar.

Krypterat USB-minne

Mycket hög säkerhet är att lägga det krypterade valvet på ett krypterat USB-minne som man endast använder i sina egna datorer, ett exempel är TrueCrypt där man låter hela USB-minnet vara en krypterad volym. Fördelen är många som t.ex. att man löper mindre risk att överföra virus från en dator till en annan då det inte finns något användbart filsystem på USB-minnet förrän det är monterat. Även om KeePass-valvet är krypterad så är det bra att lägga till en extra nivå ifall det finns någon svaghet i ena systemets implementation.

Egen SFTP-server

En annan lösning är att installera tillägget till Dropbox som heter KeePassSync vilket ger dig möjlighet att sätta upp bland annat en SFTP-server och på så sätt synkronisera sitt KeePass-valv  på ett kontrollerat sätt där man har full kontroll på även servern.

Datalagringstjänst med krypterad container

En annan lösning som har något lägre säkerhet är att använda en datalagringslösning över Internet som t.ex. Dropbox. Självklart skall man inte lita på Dropbox och då bör man även här lägga KeePass-valvet i en krypterad container ifall någon otillbörlig får tillgång till innehållet. Nackdelen med att använda tjänster över Internet är att det inte går att kontrollera ifall någon kopierar innehållet och bearbetar det. Det är därför viktigt att man måste avgöra risken med detta mot hur värdefullt innehåll det är som man sparar. Om det är privata inloggningsuppgifter till Facebook, Gmail och andra tjänster på Internet är det normalt sett inget konstigt att spara uppgifterna på detta sätt.

Endast datalagringstjänst

Något lägre säkerhet är att helt hoppa över att kryptera valvet i en container och lägga filen direkt i Dropbox. Detta kanske också är en godtagbar lösning för många normalanvändare eftersom dem idag har “qwerty123″ eller “Lösenord1!” vilket ändå förbättrar säkerheten extremt många gånger och risken av att någon anställd hos Drobox skulle komma över filerna och sedan lyckas öppna det krypterade valvet är ändå i princip obefintligt.

Detta var några exempel på hur man kan få till en bra hantering av sina kontouppgifter, det behöver varken vara krångligt eller svårtillgängligt att skydda sina kontouppgifter på ett säkert sätt där man på varje ställe på Internet kan använda unika inloggningsuppgifter. Det går aldrig att kontrollera hur varje tjänst hanterar sina användare men det är lätt att ta kontrollen och se till att oavsett vad som händer på ena hemsidan aldrig påverkar någon annan stans.

–  Johan Ryberg

Sluta använda lösenord! Del 1 av 2

Det går dagligen att läsa om lösenord, hur dem skall hanteras, bästa policy, hur man inte skall göra och hur man skall göra. Lika ofta kan man läsa om hur ena databasen efter den andra dumpas och är det stora databaser analyseras och sammanställs som oftast innehållet och resultatet är desamma, vissa lösenord är fortfarande vanligt använda och substitution av a med @ och o med 0 (noll) är mer regel än undantag så att lösenordet är “p@ssw0rd” eller liknande.

Anledningen till denna substitution är för att policyn kräver specialtecken och många guider försöker lära användarna hur dem skall bygga sina lösenord och då ofta genom att ersätta bokstäver med tecken. Detta vet naturligtvis hackers så i ordlistorna som används vid t.ex. brute force så testar man även vanligt förekommande substitutioner.

Hur skall man då göra? Alla hemsidor kräver ju lösenord! Svaret är att man inte tänker lösenord utan man tänker teckensträng, en lång rad med slumpmässiga tecken som är helt omöjligt att komma ihåg.

Man bör alltså generera en sträng med tecken, blandad hur som helst med alla möjliga tecken som är unik för varje individuell inloggning man har. För att hålla ordning på alla dessa inloggningsuppgifter så finns det gott om olika programvaror som fungerar som lösenordsvalv. Ett jag vill göra slag för är Keepass som är ett utomordentligt verktyg som är öppen källkod och som finns till de flesta plattformar, både för PC och handdatorer.

Man låter helt enkelt Keepass hålla ordning på alla inloggningsuppgifter och du själv behöver bara komma ihåg ett enda lösenord, nämligen det som krävs för att öppna valvet. Varje gång man skapar ett nytt konto så låter man Keepass generera en unik sträng vilket gör att även om hemsida X blir hackad så avslöjar det ingenting om vilka inloggningsuppgifter man använder på andra ställen på Internet.

Det finns vissa hinder med detta, det största är att ha sina inloggningsuppgifter tillgängliga när man behöver dem samt oron att förlora alla sina lösenord då dem finns i en enda fil. Detta tänker jag ta upp i del 2.

–Johan Ryberg