<<TableOfContents: execution failed ”] (katso myös loki)>>
OpenSSH:sta (tai Secure SHell) on tullut de facto standardi etäkäyttöön korvaten telnet-protokollan. SSH on tehnyt telnetin kaltaiset protokollat tarpeettomiksi johtuen suurimmaksi osaksi siitä, että yhteys on salattu eikä salasanoja enää lähetetä selvänä tekstinä kaikkien nähtäväksi.
Ssh:n oletusasennus ei kuitenkaan ole täydellinen, ja ssh-palvelinta käytettäessä on olemassa muutama yksinkertainen toimenpide, joilla asennusta voidaan koventaa dramaattisesti.
Käytä vahvoja salasanoja/käyttäjätunnuksia
Yksi ensimmäisistä asioista, jotka huomaat, jos ssh-palvelin on käynnissä ja alttiina ulkomaailmalle, on se, että luultavasti kirjaudut hakkerien yrityksiin arvata käyttäjätunnuksesi/salasanasi. Tyypillisesti hakkeri etsii porttia 22 (oletusportti, jossa ssh kuuntelee) löytääkseen koneet, joissa ssh on käynnissä, ja yrittää sitten brute-force-hyökkäystä sitä vastaan. Kun käytössä on vahvat salasanat, kaikki hyökkäykset toivottavasti kirjataan ja huomataan ennen kuin ne onnistuvat.
Toivottavasti käytät jo vahvoja salasanoja, mutta jos et niin yritä valita salasanoja, jotka sisältävät:
- Vähintään 8 merkkiä
- Sekoitus isoja ja pieniä kirjaimia
- Sekoitus kirjaimia ja numeroita
- Muita kuin aakkosnumeerisia merkkejä (esim. erikoismerkkejä, kuten ! ” £ $ % % ^ jne.)
Vahvojen salasanojen hyödyt eivät koske vain ssh:tä, vaan ne vaikuttavat kaikkiin järjestelmien tietoturvan osa-alueisiin. Lisätietoja salasanoista on CentOS:n dokumentaatiossa:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Jos et missään nimessä voi estää käyttäjiäsi valitsemasta heikkoja salasanoja, harkitse satunnaisesti luotujen tai vaikeasti arvattavien käyttäjätunnusten käyttämistä käyttäjätunnuksissa. Jos pahikset eivät voi arvata käyttäjätunnusta, he eivät voi myöskään murtaa salasanaa. Tämä on kuitenkin edelleen tietoturvaa epäselvyyksien kautta, ja ole tietoinen käyttäjätunnusten tietovuodosta esimerkiksi käyttäjätileiltä lähetetyistä sähköposteista.
Disable Root Logins
SSH-palvelimen asetukset tallennetaan tiedostoon /etc/ssh/sshd_config. Jos haluat poistaa root-kirjautumiset käytöstä, varmista, että sinulla on seuraava merkintä:
# Prevent root logins:PermitRootLogin no
ja käynnistä sshd-palvelu uudelleen:
service sshd restart
Jos tarvitset pääkäyttäjän oikeuksia, kirjaudu sisään tavallisena käyttäjänä ja käytä komentoa su.
Käyttäjätunnusten rajoittaminen
SSH-kirjautumiset voidaan rajoittaa vain tiettyihin käyttäjiin, jotka tarvitsevat etäyhteyttä. Jos järjestelmässä on monta käyttäjätiliä, on järkevää rajoittaa etäkäyttö vain niihin, jotka sitä todella tarvitsevat, jolloin rajoitetaan satunnaisen käyttäjän heikon salasanan vaikutusta. Lisää /etc/ssh/sshd_config-tiedostoon AllowUsers-rivi, jota seuraa välilyönnillä erotettu luettelo käyttäjätunnuksista Esimerkiksi:
AllowUsers alice bob
ja käynnistä sshd-palvelu uudelleen.
Disable Protocol 1
SSH:lla on kaksi protokollaa, joita se voi käyttää, protokolla 1 ja protokolla 2. Vanhempi protokolla 1 on vähemmän turvallinen, ja se tulisi poistaa käytöstä, ellet tiedä, että tarvitset sitä erityisesti. Etsi seuraava rivi tiedostosta /etc/ssh/sshd_config, poista sen kommentti ja muuta sitä kuvan mukaisesti:
# Protocol 2,1Protocol 2
ja käynnistä sshd-palvelu uudelleen.
Käytä muuta kuin standardiporttia
Oletusarvoisesti ssh kuuntelee saapuvia yhteyksiä portissa 22. Jotta hakkeri saisi selville, että ssh on käynnissä koneellasi, hän mitä todennäköisimmin tutkii porttia 22 tämän selvittämiseksi. Tehokas tapa on ajaa ssh:tä epästandardissa portissa. Mikä tahansa käyttämätön portti kelpaa, vaikka jokin 1024:n yläpuolella oleva portti on suositeltavampi. Monet valitsevat vaihtoehtoiseksi portiksi 2222 (koska se on helppo muistaa), aivan kuten 8080 tunnetaan usein vaihtoehtoisena HTTP-porttina. Juuri tästä syystä se ei luultavasti ole paras valinta, sillä jokainen hakkeri, joka tutkii porttia 22, tutkii todennäköisesti myös porttia 2222 varmuuden vuoksi. On parempi valita jokin satunnainen korkea portti, jota ei käytetä mihinkään tunnettuun palveluun. Tee muutos lisäämällä tällainen rivi tiedostoon /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
ja käynnistä sshd-palvelu uudelleen. Älä unohda sen jälkeen tehdä tarvittavia muutoksia reitittimesi porttien välitykseen ja mahdollisiin palomuurisääntöihin. Esimerkiksi CentOS 7:ssä (ja uudemmissa) voit muuttaa firewalld:n ssh-palvelua tekemällä kopion sen palvelutiedostosta tiedostoon /etc/firewalld/ ja muuttamalla sen porttiriviä:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Vaihda sitten porttirivi tiedostoon /etc/firewalld/services/ssh-custom.xml niin, että portti on sama kuin ssh-konfigurointitiedostossa:
<port protocol="tcp" port="2345"/>
Lopuksi poista ssh-palvelu, lisää ssh-custom-palvelu ja lataa firewalld uudelleen, jotta muutos tulee voimaan:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Tai CentOS 6:ssa lisää iptable-sääntö uuden ssh-portin avaamiseksi:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Älä unohda sulkea myös vanha portti.
CentOS 6:ssa ja uudemmissa kannattaa myös päivittää selinux, merkitä valittu portti oikein, muuten sshd ei pääse siihen käsiksi. Esim:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Koska ssh ei enää kuuntele yhteyksiä vakioportissa, sinun on kerrottava asiakkaallesi, mihin porttiin muodostaa yhteys. Käyttämällä ssh-asiakasta komentoriviltä voimme määrittää portin käyttämällä -p-kytkintä:
$ ssh -p 2345 myserver
tai jos käytät konquerorin fish-protokollaa, esim:
fish://myserver:2345/remote/dir
Jos ajattelet, että tämä kuulostaa tuskalta määrittää portti joka kerta, kun muodostat yhteyden, lisää yksinkertaisesti portin määrittelevä merkintä paikalliseen ~/.ssh/config-tiedostoosi:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Ja tiedostoon: ~/.ssh/config-tiedostolla on oltava seuraavat oikeudet:
$ chmod 600 ~/.ssh/config
Suodata SSH:ta palomuurissa
Jos tarvitset etäyhteyttä vain yhdestä IP-osoitteesta (esimerkiksi töistä kotipalvelimelle), harkitse yhteyksien suodattamista palomuurissasi joko lisäämällä palomuurisääntö reitittimeen tai iptables-ohjelmaan rajoittaaksesi pääsyn porttiin 22 vain kyseiseen IP-osoitteeseen. iptablesissa tämä voidaan toteuttaa esimerkiksi seuraavanlaisella iptables-säännöllä (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
tai käyttämällä firwalldia (CentOS 7) käytä rich-rules-sääntöjä salliaksesi ssh:n vain tietyssä portissa. Lähdeosoite voi olla yksittäinen osoite tai perusosoite bittimaskin kanssa:
SSH tukee myös natiivisti TCP-kääreitä, ja pääsyä ssh-palveluun voidaan kontrolloida samalla tavalla käyttämällä hosts.allow- ja hosts.deny-komentoja.
Jos et pysty rajoittamaan lähde-IP-osoitteita ja joudut avaamaan ssh-portin globaalisti, iptables voi silti auttaa estämään brute-force-hyökkäyksiä kirjaamalla ja estämällä toistuvat kirjautumisyritykset samasta IP-osoitteesta. Esimerkiksi iptables
Ensimmäinen sääntö kirjaa jokaisen uuden yrityksen IP-osoitteen, jolla yritetään päästä porttiin 22 recent-moduulin avulla. Toinen sääntö tarkistaa, onko kyseinen IP-osoite yrittänyt muodostaa yhteyttä neljä kertaa tai useammin viimeisten 60 sekunnin aikana, ja jos ei, paketti hyväksytään. Huomaa, että tämä sääntö edellyttäisi, että tuloketjun oletuskäytäntönä on DROP.
Älkää unohtako muuttaa porttia sopivaksi, jos käytät ssh:tä muussa kuin standardiportissa. Suodatus palomuurissa on mahdollisuuksien mukaan erittäin tehokas tapa turvata pääsy ssh-palvelimelle.
Järjestelmissä, joissa käytetään FirewallD-palvelua (CentOS 7 tai uudempi), käytä firewall-cmd:
Ensimmäinen komento poistaa sallivamman palvelusäännön, toinen asentaa säännön, joka hyväksyy vain neljä yhteyttä minuutissa ja kirjaa kaikki yhteydet.
Käytä julkisia/yksityisiä avaimia todennukseen
Salattujen avainten käyttäminen todennukseen tarjoaa kaksi pääetua. Ensinnäkin se on kätevää, koska sinun ei enää tarvitse syöttää salasanaa (ellet salaa avaimia salasanasuojauksella), jos käytät julkisia/yksityisiä avaimia. Toiseksi, kun julkisen/yksityisen avainparin todennus on määritetty palvelimelle, voit poistaa salasanan todennuksen kokonaan käytöstä, mikä tarkoittaa, että ilman valtuutettua avainta et pääse sisään – joten salasanan murtamisyritykset loppuvat.
Julkisen/yksityisen avainparin luominen ja asentaminen ssh-palvelimen käyttöön on suhteellisen yksinkertainen prosessi.
Luo ensin julkinen/yksityinen avainpari asiakaskoneeseen, jota käytät yhteyden muodostamiseen palvelimeen (tämä on tehtävä jokaisesta asiakaskoneesta, josta muodostat yhteyden):
$ ssh-keygen -t rsa
Jos et halua, että sinulta kysytään edelleen salasanaa (joka on periaatteessa salasana tietyn julkisen avaimen lukituksen avaamiseksi) joka kerta, kun muodostat yhteyden, paina enteriä, kun avainparia luodessasi kysytään salasanaa. Voit itse päättää, haluatko lisätä avaimeesi salasanan suojaavan salauksen sitä luodessasi. Jos et suojaa avainta salasanalla, kuka tahansa, joka pääsee paikalliseen koneeseesi, saa automaattisesti ssh-käytön etäpalvelimelle. Myös paikallisen koneen pääkäyttäjällä on pääsy avaimiisi, vaikka oletetaankin, että jos et voi luottaa pääkäyttäjään (tai pääkäyttäjä on vaarassa), olet todellisissa vaikeuksissa. Avaimen salaaminen lisää turvallisuutta sen kustannuksella, että ssh-palvelimelle ei enää tarvitse syöttää salasanaa, joka korvataan avaimen käyttöä varten tarvittavalla salasanalla. Tätä voidaan yksinkertaistaa entisestään käyttämällä ssh_agent-ohjelmaa
Aseta nyt käyttöoikeudet yksityiselle avaimellesi:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Kopioi julkinen avain (id_rsa.pub) palvelimelle ja asenna se authorized_keys-luetteloon:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Huomaa: kun olet tuonut julkisen avaimen, voit poistaa sen palvelimelta.
ja aseta lopuksi tiedostojen käyttöoikeudet palvelimelle:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Yllämainitut käyttöoikeudet vaaditaan, jos StrictModes on asetettu arvoon yes kohdassa /etc/ssh/sshd_config (oletusarvo).
Varmista, että oikeat SELinux-kontekstit on asetettu:
$ restorecon -Rv ~/.ssh
Nyt kun kirjaudut palvelimelle, sinulta ei kysytä salasanaa (ellet antanut salasanaa avainparia luodessasi). Oletusarvoisesti ssh yrittää ensin tunnistautua avainten avulla. Jos avaimia ei löydy tai todennus epäonnistuu, ssh palaa perinteiseen salasanatodennukseen.
Kun olet tarkistanut, että voit kirjautua palvelimeen onnistuneesti käyttämällä julkista/yksityistä avainparia, voit poistaa salasanatodennuksen kokonaan käytöstä lisäämällä /etc/ssh/sshd_config-tiedostoon seuraavan asetuksen:
# Disable password authentication forcing use of keysPasswordAuthentication no
Tiheästi kysytty kysymys (FAQ)
Q: CentOS käyttää OpenSSH:n versiota X ja uusin versio on versio Y. Versio X sisälsi vakavan tietoturva-aukon, pitäisikö minun päivittää?
A: Ei. Upstream-toimittajalla on käytäntö, jonka mukaan uusimpien versioiden tietoturvakorjaukset siirretään takaisin nykyiseen jakeluversioon. Niin kauan kuin sinulla on uusimmat päivitykset sovellettuna CentOS-jakeluusi, olet täysin korjattu. Katso lisätietoja tietoturvakorjausten takaisintuonnista täältä:
http://www.redhat.com/advice/speaks_backport.html
Q: Miten saan ssh:n sallimaan salasanattomaan avaimeen perustuvan todennuksen koneiden välillä, jotka jakavat käyttäjien kotihakemistoja NFS:n kautta?
A: SElinux estää pääkäyttäjän pääsyn NFS:n jaettuihin hakemistoihin ja tiedostoihin, jotka eivät ole oletusarvoisesti maailman luettavissa, joten sshd ei voi lukea käyttäjien avaintiedostoja tiedostossa ~/.ssh. Voit sallia pääsyn muuttamalla asetusta use_nfs_home_dirs suorittamalla seuraavan komennon superuserina:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html