SSH-turvatoimet
Tässä artikkelissa listataan erilaisia keinoja joilla luvattomia SSH-kirjautumisia voidaan välttää ja riskejä rajata.
Hyvät salasanat
Salasana jää herkästi järjestelmän heikoimmaksi lenkiksi. Käytä esimerkiksi apg:tä salasanan generoimiseen. Pitkään on suositeltu että salasanoja ei laitettaisi lapulle, mutta mikäli taipumuksenasi on tämän sijaan käyttää samaa salasanaa joka paikassa, muistilapun laatiminen lienee sittenkin parempi vaihtoehto. Mikäli käytät jonkun koneen tiettyä SSH-tiliä vain yhdeltä koneelta, avainparilla tunnistautuminen ja salasanan lukitseminen (passwd -l) saattaisi olla hyvä ratkaisu.
Pääkäyttäjänä kirjautumisen estäminen
Pääkäyttäjänä (root) kirjautumisen salliminen ssh-palvelimessa on hyvin riskialtista, sillä on olemassa monia haittaohjelmia, jotka yrittävät kirjautua ssh-palvelimelle kokeilemalla (ns. bruteforce) eri käyttäjätunnuksia ja salasanoja. Jos pääkäyttäjänä voi kirjautua, tällaisen ohjelman ei enää tarvitse muuta kuin kokeilemalla selvittää pääkäyttäjän salasana, jonka jälkeen pääsy koneeseen avautuu.
Pääkäyttäjän kirjautuminen voidaan estää muokkaamalla tiedostoa /etc/ssh/sshd_config. Tiedostossa pitäisi olla rivi
PermitRootLogin no
jos pääkäyttäjän kirjautumista ei sallita. Jos tiedostossa lukee PermitRootLogin yes, vaihda se yllä olevaan muotoon.
Jotta muutokset tulevat voimaan, on ssh-palvelin käynnistettävä uudelleen:
/etc/init.d/ssh restart
Yhteyden salliminen vain tietyiltä koneilta
Mikäli SSH:ta käytetään vain tietyiltä koneilta tai tietyistä verkoista (työpaikka tms.) nämä koneet tai verkot kannattaa määritellä ja yhteydenotot muilta koneilta estää. Myös yhteydet muilta koneilta voi usein ottaa sallitun koneen kautta, jolloin kotikone on saavutettavissa maailmalta tästä turvatoimesta huolimatta.
Eston voi toteuttaa palomuurilla tai Tcpwrappersin kautta. Jälkimmäinen tapahtuu esimerkiksi niin, että varmistaa että tiedostossa /etc/hosts.deny on rivi
ALL:ALL
ja tiedostossa /etc/hosts.allow vastaavasti (sisäverkko ja työpaikka)
sshd sshd1 sshd2: 192.168.0. .firma.example.org
Varmista, ettei tässä tiedostossa ole ALL-riviä.
Yhteyden salliminen vain tietyiltä käyttäjiltä
Usein koneella on käyttäjiä, jotka käyttävät konetta vain paikallisesti. Jotta näiden mahdollisesti huonoja salasanoja ei voisi murtaa SSH:n kautta, kannattaa määrätä sallitut SSH-käyttäjät tiedostossa /etc/ssh/sshd_config. Tähän käy avainsana AllowUsers, Allowgroups, DenyUsers tai DenyGroup
AllowUsers joku jokutoinen
Epäaktiivisten yhteyksien katkaisu
Käyttäjän unohtaessa istunnon auki esimerkiksi vieraalle koneelle, syntyy tietoturvariski. Epäaktiiviset yhteydet voi automaattisesti katkaista tietyn ajan kuluttua lisäämällä /etc/ssh/sshd_config-asetustiedostoon rivit:
ClientAliveInterval 600 ClientAliveCountMax 3
ClientAliveInterval määrittää ajan sekunteina, jonka käyttäjän tulee olla epäaktiivinen (600 sekuntia = 10 minuuttia). ClientAliveCountMax määrittää SSH-palvelimen lähettämät checkalive-kyselyt, joilla se kysyy asiakkaalta onko tämä vielä elossa.
Portin vaihto
SSH kuuntelee vakiona porttia 22, mutta sen voi laittaa johonkin muuhunkin porttiin ja torjua näin joitakin hyökkäyksiä. Laitat vain tiedostoon /etc/ssh/sshd_config seuraavasti:
#Port 22 #Entinen portti kommentoituna Port 54433 #Uusi portti
SSH-2 -protokollan käyttö
SSH-1 -protokollasta on löytynyt haavoittuvuuksia ja sen käyttöä tulisi välttää. Jotta SSH-2 olisi käytössä, /etc/ssh/sshd_config-asetustiedostossa tulee olla rivi:
Protocol 2
Kertakäyttösalasanageneraattorin käyttö
Google Authenticator ja vastaavat kertakäyttösalasanageneraattorit mahdollistavat salasanakirjautumisen tekemisen huomattavasti turvallisemmaksi. Käytännössä siinä käytetään älypuhelinsovellusta, joka tuottaa kertakäyttöisiä salasanoja.
Fail2ban
- Lue myös pääartikkeli Fail2ban
Fail2ban-skripti seuraa kirjautumisyrityksiä, ja estää yhteydet määritellyksi ajaksi (esim. 15 minuuttia) IP-osoitteista, joista epäonnistuneita yrityksiä tulee liikaa. Tämä torjuu varsin tehokkaasti mm. automatisoituja sanakirjahyökkäyksiä, jos ne tulevat yhdeltä koneelta. botnet-hyökkäyksen hajautetun luonteen vuoksi sellaista vastaan fail2banista ei ole apua, eikä muita turvatoimia ole syytä vähätellä, vaikka fail2ban olisikin käytössä.