Rss

  • linkedin

Archives for : keepass

Configure SSH for high security

There are some steps to do after SSH is installed on a system and there is a old saying that says “A chain is only as strong as its weakest link” and if you are using a weak password for your root account (or any other account) then you are extremely vulnerable. It does not matter if the communication is secure when you are easily brute forced. All steps is used on a Ubuntu 11.10 but should be the same on OpenBSD, Debian, Linux Mint or any other Linux distribution with none or very few modifications.

We are going to do the following steps

  • Create certificate
  • Set correct credentials to .ssh folder and files
  • Shut down the possibility to log in with password
  • Prevent root to log in via SSH
  • Remove less secure encryption methods
  • Enable visual identification of the server fingerprint
  • Optional: Change SSH port (does really not not increase security)

Create certificate
We are going to use a RSA-key with a key length of 4096 bits. Open a terminal and enter the following “‘ssh-keygen -t rsa -b 4096″.  1024 bits key should be enough but better to be safe than sorry.

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

Then you will be asked where to store the key. If you already got keys in id_dsa then you should enter another file name or your existing keys will be overwritten. If you are satisfied with the suggestion simply press enter.

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

It’s now time to enter a password. Use a strong password with big and small letters, numbers and symbols. The password should also be unique and stored on a secure place like in a encrypted container like Keepass.

Enter passphrase (empty for no passphrase): 2sWf3+@/’?B>.%DpBU”r
Enter same passphrase again: 2sWf3+@/’?B>.%DpBU”r
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:
31:b0:be:0b:5b:7c:f1:79:65:e4:72:42:18:08:c4:8d
The key’s randomart image is:
+–[ RSA 4096]—-+
|     o++ ..o.    |
|      Eoo ..     |
|      . o   . .  |
|     .   o o +   |
|      . S   +    |
|     . o o o     |
|    . + o .      |
|     + o .       |
|    . .          |
+—————–+

Enable the public key for authentication
The public key should be stored in ~/.ssh/authorized_keys and there can be more then one key for a single user. Just make a new row for each public key. If you key should be installed on the same system from where you just created the private key simply copy id_rsa.pub to authorized_keys

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

If you want to use the public key on another machine you could simply copy the public key using scp (secure copy). Please notice that you will replace existing authorized_keys if you already has one in place. To copy simply write the following command.

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

Set correct credentials to .ssh folder and files

Make sure that your working folder is your home folder, replace “johan” with your username.

johan@johan-laptop:~/.ssh$ cd ~
johan@johan-laptop:~/.ssh$ sudo chown -R johan:johan .ssh
johan@johan-laptop:~/.ssh$ sudo chmod -R 600 .ssh
johan@johan-laptop:~/.ssh$ sudo chmod +x .ssh

Do a test log in to test the public key

johan@johan-laptop:~/.ssh$ ssh johan@localhost
Enter passphrase for key ‘/home/johan/.ssh/id_rsa’:

After you entered the private key password you should have access to your machine, if not you will have to look for errors in the logs but I will not cover this in this guide.

Configure sshd
The next step is to modify sshd. All settings we will change is in the file /etc/ssh/sshd_config. Start to make a backup of sshd_config just in case.

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

Password:

Use desired editor to edit sshd_config. I prefer vi but I will use nano in this example

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

The following lines is going to be added or altered:

  • PermitRootLogin yes
  • #PasswordAuthentication yes
  • Ciphers

PermitRootLogin no

root should never be used since it much more secure to use a regular user instead and then you need to perform a administrative task use the command sudo instead which gives you temporary administrative rights
We are also going to prevent the possibility to log in with password (you will be forced to use the private key). Find the rows which looks like  this:

PermitRootLogin yes

Modify it to look like this

PermitRootLogin no

Find the row which look like this

#PasswordAuthentication yes

Modify it to look like this

PasswordAuthentication no

At the end Cipers is going to be added and it may not apply never installations but the default ciphers has not always been the best choices and sshd should be forced to only use the strongest ones.

Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

More information about why to alter the ciphers can be found here:
[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/

Verify these entries:

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

Save and exit

Restart to active the settings.

johan@johan-laptop:~/.ssh$ sudo service ssh restart
Password:
ssh start/running, process 2212

Enable visual identification of the servers fingerprint (Visual Host Key)
It’s not easy to verify and remember the fingerprint of a host since it’s a long hexadecimal string that may look like this one: ” 31:b0:be:0b:5b:7c:f1:79:65:e4:72:42:18:08:c4:8d” , some one may have altered the DNS record so that you in fact are trying to authenticate to a rouge server and to remember that string is near impossible. . It’s more easy to remember a visual fingerprint but it’s still not bulletproof. It’s absolute best to verify the exact string every time and that is done by most SSH clients and for example openssh stored them in ~/.ssh/known_hosts and gives you a warning if it has changed.

Do the following to enable visual host key

Edit eider /etc/ssh/ssh_config witch effects all users on the system or ~/.ssh/config to enable it for a single user.

Add the following lines (“Host * is already at top of ssh_config)

Host *
VisualHostKey yes

Test and verify
It’s now time to test and verify. You should not be able to log in without your private key and password authentication should been disabled. You should also see your visual finger print when you tries to log in.

Your SSH should be more safe now but remember that SSH probably was the most secure software from the beginning with default settings and MySQL, Apache or any other system also has to be secured.

–  Johan Ryberg

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

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

container

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

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