Archive for the ‘Ubuntu’ Category

Konfigurera SSH för ökad säkerhet

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

mysqlbackup-ng i ny tappning

MySQLBackup-NG är ett trevligt litet skript som tar backup på MySQL-databaser, komprimerar filen och sedan skickar iväg den med scp till önskad plats.

Jag har nästan skrivit om det totalt sedan version 1.1 som tidigare fanns på Google Code vilket betyder att 2.0 är 100% POSIX-kompatibelt och fungerar på både OpenBSD och under Linux som t.ex. Ubuntu Server 10.04.

Ni hittar MySQLBackup-NG hos github: https://github.com/jryberg/MySQLbackup-ng

–  Johan Ryberg

Använd SSH tillsammans med krypterad hemkatalog i Ubuntu

Eftersom man normalt inte tillåter lösenord via SSH utan kräver certifikat så finns det en begränsning i standardinstallationen i Ubuntu som gör det omöjligt att logga in om man har en krypterad hemkatalog. Detta är på grund av att authorized_keys ligger under /home/<användarnamn>/.ssh/ vilket ligger den krypterade hemkatalogen och är därför inte åtkomligt innan man har loggat in. Problemet är just att man inte är inloggad och därför är inte hemkatalogen dekrypterad när sshd behöver läsa filens innehåll för att avgöra om din privata nyckel tillhör den publika nyckeln.

Om man har detta problem borde likande rader i /var/log/auth.log finnas för varje misslyckat inloggningsförsök:

Jan 11 20:55:25 server su[28291]: pam_sm_authenticate: Called
Jan 11 20:55:25 server su[28291]: pam_sm_authenticate: username = [<användarnamn>]
Jan 11 20:55:25 server su[28292]: Passphrase file wrapped
Jan 11 20:55:27 server su[28292]: Error attempting to add filename encryption key to user session keyring; rc = [1]

Lösningen är som tur är väldigt enkel

Skapa först en ny katalog som du döper till /etc/ssh-public-keys/<användarnamn>/

sudo mkdir /etc/ssh-public-keys/johan

Flytta authorized_keys till /etc/ssh-public-keys/<användarnamn>/

sudo mv ~/.ssh/authorized_keys /etc/ssh-public-keys/johan/

Redigera /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

Ändra AuthorizedKeysFile till

AuthorizedKeysFile /etc/ssh-public-keys/%u/authorized_keys

Starta sedan om sshd för att förändringen skall ta

sudo service ssh restart

–  Johan Ryberg

Sätt rätt tidsstämpel på dina foton i Ubuntu 10.10

Jag råkade ut för ett intressant problem efter att jag säkerhetskopierat mina kort på min Android-telefon. Tidsstämpeln på samtliga filer sattes till tidpunkten då jag kopierade tillbaka filerna vilket gjorde att alla filer hamnade i total oordning när man tittade på dem via Galleri som är bildvisningsprogrammet som kommer tillsammans med HTC-telefoner.

Lösningen heter exif-touch vilket är ett perlscript som läser tilläggsinformationen som finns på korten och sätter rätt datum på dem.

Först måste exif-touch hämtas hem vilket görs från denna sida: http://chris.improbable.org/2007/01/8/exif-touch/
Direktlänk till scriptet: https://github.com/acdha/unix_tools/blob/master/bin/exif-touch

Spara scriptet lokalt på datorn i lämplig katalog, i mitt fall rätt i min hemkatalog /home/johan/exif-touch

Två perlbibliotek för hantering av exif-data måste också hämtas hem vilket du gör med följande kommando:

sudo apt-get install libimage-exif-perl libimage-info-perl

Kör sedan scriptet genom att skriva följande kommando

perl /home/johan/exif-touch

–Johan Ryberg

Installera VMware tools i Ubuntu 10.04 och 10.10

Så här installerar du VMware tools i Ubuntu

Lägg till VMware repository i /etc/apt/sources.list
deb http://packages.vmware.com/tools/esx/4.1latest/ubuntu lucid main restricted

Hämta VMwares nyckel
wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub -O- | sudo apt-key add -

Installera komponenterna
sudo apt-get update

sudo apt-get install vmware-open-vm-tools-kmod-source
sudo module-assistant prepare
sudo module-assistant build vmware-open-vm-tools-kmod-source
sudo module-assistant install vmware-open-vm-tools-kmod

Om du kör server UTAN X kör följande kommando
sudo apt-get install vmware-open-vm-tools-nox
Om du använder X kör du istället
sudo apt-get install vmware-open-vm-tools

Starta sedan om maskinen

— Johan Ryberg

Åtgärd om eth0 försvinner efter migrering av Ubuntu under VMware

Om man klonar en dator fysiskt eller virtuellt så brukar det uppstå problem med att eth0 försvinner.

Detta åtgärdas enkelt genom att modifiera följande fil: /etc/udev/rules.d/70-persistent-net.rules

Radera alla gamla interface som inte längre används, oftast eth0 och döp sedan om det återstående interfacet till eth0.

Spara och starta om och du borde ha fått tillbaka eth0

— Johan Ryberg

Åtgärda fel i Munin så att MySQL går att avläsa i Ubuntu 10.10

Munin fungerar inte gällande testerna för MySQL om man använder Ubuntu 10.10 på grund av det saknas vissa beroenden. Dessa installeras lätt genom att skriva följande i konsolen

sudo apt-get install libcache-cache-perl
sudo apt-get install libipc-sharelite-perl

Sedan måste testerna för MySQL aktiveras genom att skriva följande

sudo ln -sf /usr/share/munin/plugins/mysql_bytes mysql_bytes
sudo ln -sf /usr/share/munin/plugins/mysql_queries mysql_queries
sudo ln -sf /usr/share/munin/plugins/mysql_slowqueries mysql_slowqueries
sudo ln -sf /usr/share/munin/plugins/mysql_threads mysql_threads

Munin-node måste sedan startas om för att de nya inställningarna skall ta

sudo service munin-node restart

Kontrollera sedan så det inte finns några felmeddelanden efter omstart genom att skriva

sudo tail /var/log/munin/munin-node.log

— Johan Ryberg

Google Docs och "A browser error has occurred"

Själv använder jag Google Docs för vissa saker och applikationen Spreadsheets har aldrig fungerat med den nya versionen som innehåller mängder med nya funktioner och ett upparbetat gränssnitt. Jag möttes ideligen av följande felmeddelandet “A browser error has occurred” och man uppmanades att ladda om sidan så fort jag öppnade ett kalkylark.

Jag hade länge sökt efter en lösning och på Googles supportforum var det mängder med människor som hade samma problem tills idag, eller jag gav mig på problemet igen och hittade äntligen lösningen.

Firefox inställning “dom.storage.enabled” var satt till false av någon anledning. Normalt är den true men inte hos mig. Efter att jag satt den till true (skriv about:config i adressfältet) och startat om Firefox så fungerar Google Docs perfekt igen

— Johan Ryberg

Automatiskt rapport till ISP vid bruteforce-attack via SSH

Om du använder SSH och samtidigt tillåter att hela Internet får ansluta till din maskin så har du garanterat sett hur många intrångsförsök det sker. Detta är oftast inte manuella intrång utan sådana som är automatiserade via script/botnets och oftast vet inte ägaren till maskinen om detta.

denyhosts har jag skrivit om en del och det går att bygga ut systemet ytterligare via ett plugin som heter report-hack-isp och som du kan ladda ner här: http://wiki.github.com/nazar/report-hack-isp/

Detta script plockar enkelt beskrivet ut IP-adressen samtidigt som den blir blockerad av denyhosts och gör uppslag på IP/värdnamnet med whois för att plocka ut e-postadressen till abuse och skickar ett e-postmeddelande dit med ett meddelande om vad som hänt med tillhörande logg.

För att installerade detta under Ubuntu behövs ruby och whois installeras utöver en normal installation samt eventuellt sendmail eller liknande om e-postserver saknas.

— Johan Ryberg

Problem med sync av denyhosts?

Många upplever problem med att synca bannade IP-adresser och dem för följande felmeddelande:

2010-07-15 14:23:51,381 – sync : ERROR long int exceeds XML-RPC limits
Traceback (most recent call last):
File “/usr/share/denyhosts/DenyHosts/sync.py”, line 117, in receive_new_hosts
self.__prefs.get(“SYNC_DOWNLOAD_RESILIENCY”))
File “/usr/lib/python2.6/xmlrpclib.py”, line 1199, in __call__
return self.__send(self.__name, args)
File “/usr/lib/python2.6/xmlrpclib.py”, line 1483, in __request
allow_none=self.__allow_none)
File “/usr/lib/python2.6/xmlrpclib.py”, line 1132, in dumps
data = m.dumps(params)
File “/usr/lib/python2.6/xmlrpclib.py”, line 677, in dumps
dump(v, write)
File “/usr/lib/python2.6/xmlrpclib.py”, line 699, in __dump
f(self, value, write)
File “/usr/lib/python2.6/xmlrpclib.py”, line 725, in dump_long
raise OverflowError, “long int exceeds XML-RPC limits”
OverflowError: long int exceeds XML-RPC limits

Detta går att åtgärda genom att göra följande

  1. Editera /var/lib/denyhosts/sync-timestamp och ersätt tidsstämpeln med 1276467300 (eller annan godkänd Unixtidsstämpel)
  2. Editera /usr/share/denyhosts/DenyHosts/sync.py och ändra rad 55:
    från:
    fp = open(os.path.join(self.__work_dir,
    SYNC_TIMESTAMP), “a”)
    till:
    fp = open(os.path.join(self.__work_dir,
    SYNC_TIMESTAMP), “w”)

Nästa gång denyhosts syncar så skall det gå bra

— Johan Ryberg

Return top