Ero sivun ”SSH-turvatoimet” versioiden välillä
(neutraalimpaan suuntaan joo) |
|||
Rivi 27: | Rivi 27: | ||
== Yhteyden salliminen vain tietyiltä käyttäjiltä == | == 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 | 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 | AllowUsers joku jokutoinen | ||
== Portin vaihto == | == Portin vaihto == |
Versio 20. kesäkuuta 2013 kello 19.06
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
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
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ä.