<<TableOfContents: execution failed “] (lásd még a naplót)>>
Az OpenSSH (vagy Secure SHell) a távoli hozzáférés de facto szabványává vált a telnet protokollt felváltva. Az SSH feleslegessé tette az olyan protokollokat, mint a telnet, ami nagyrészt annak köszönhető, hogy a kapcsolat titkosított, és a jelszavakat már nem küldik el nyílt szövegben, hogy mindenki láthassa.
Az ssh alapértelmezett telepítése azonban nem tökéletes, és egy ssh-kiszolgáló futtatásakor van néhány egyszerű lépés, amely drámaian megkeményítheti a telepítést.
Használjon erős jelszavakat/felhasználóneveket
Az egyik első dolog, amit észre fog venni, ha az ssh fut és ki van téve a külvilágnak, hogy valószínűleg naplózni fogja a hackerek próbálkozásait a felhasználónév/jelszó kitalálására. Általában egy hacker a 22-es portot (az alapértelmezett port, amelyen az ssh hallgat) keresi, hogy megtalálja azokat a gépeket, amelyeken ssh fut, majd megkísérli a brute-force támadást ellene. Erős jelszavakkal remélhetőleg minden támadást naplóznak és észrevesznek, mielőtt sikerrel járhatna.
Remélhetőleg már használsz erős jelszavakat, de ha nem, akkor próbálj meg olyan jelszavakat választani, amelyek tartalmaznak:
- Minimum 8 karakter
- Kis és nagybetűk keveréke
- Betűk és számok keveréke
- Nem alfanumerikus karakterek (pl. speciális karakterek, mint ! ” £ $ $ % ^ stb.)
Az erős jelszavak előnyei nem csak az ssh-ra jellemzőek, hanem a rendszerek biztonságának minden aspektusára hatással vannak. A jelszavakkal kapcsolatos további információk a CentOS dokumentációjában találhatók:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Ha semmiképpen sem tudja megakadályozni, hogy a felhasználók gyenge jelszavakat válasszanak, akkor fontolja meg véletlenszerűen generált vagy nehezen kitalálható felhasználónevek használatát a felhasználói fiókokhoz. Ha a rosszfiúk nem tudják kitalálni a felhasználónevet, akkor a jelszót sem tudják feltörni. Ez azonban még mindig az ismeretlenségen keresztüli biztonságot jelenti, és tisztában kell lennie a felhasználónevek kiszivárgásával olyan dolgokból, mint például a felhasználói fiókokból küldött e-mailek.
Disable Root Logins
Az SSH-kiszolgáló beállításait az /etc/ssh/sshd_config fájlban tárolja. A root bejelentkezések letiltásához győződjön meg róla, hogy a következő bejegyzés szerepel:
# Prevent root logins:PermitRootLogin no
és indítsa újra az sshd szolgáltatást:
service sshd restart
Ha root hozzáférésre van szüksége, jelentkezzen be normál felhasználóként, és használja a su parancsot.
Limit User Logins
SSH bejelentkezések korlátozhatók csak bizonyos felhasználókra, akiknek távoli hozzáférésre van szükségük. Ha sok felhasználói fiók van a rendszerben, akkor érdemes a távoli hozzáférést csak azokra korlátozni, akiknek valóban szükségük van rá, így korlátozva egy alkalmi felhasználó gyenge jelszójának hatását. Adjunk hozzá az /etc/ssh/sshd_config állományhoz egy AllowUsers sort, amelyet a felhasználónevek szóközzel elválasztott listája követ, például:
AllowUsers alice bob
és indítsa újra az sshd szolgáltatást.
Disable Protocol 1
Az SSH két protokollt használhat, az 1-es és a 2-es protokollt. A régebbi 1-es protokoll kevésbé biztonságos, ezért érdemes letiltani, hacsak nem tudja, hogy kifejezetten szüksége van rá. Keresse meg a következő sort az /etc/ssh/sshd_config fájlban, vegye ki a megjegyzést és módosítsa az ábrán látható módon:
# Protocol 2,1Protocol 2
és indítsa újra az sshd szolgáltatást.
Nem szabványos port használata
Az ssh alapértelmezés szerint a 22-es porton várja a bejövő kapcsolatokat. Ahhoz, hogy egy hacker megállapítsa, hogy az ssh fut a gépeden, valószínűleg a 22-es portot fogja vizsgálni, hogy ezt megállapítsa. Hatékony módszer, ha az ssh-t egy nem szabványos porton futtatod. Bármelyik nem használt port megteszi, bár az 1024 feletti port előnyösebb. Sokan a 2222-es portot választják alternatív portként (mivel ezt könnyű megjegyezni), ahogy a 8080-as portot is gyakran alternatív HTTP portként ismerik. Éppen ezért valószínűleg nem ez a legjobb választás, mivel minden hacker, aki a 22-es portot szkenneli, valószínűleg a 2222-es portot is szkenneli a biztonság kedvéért. Jobb, ha valami véletlenszerűen kiválasztott magas portot választunk, amelyet nem használnak semmilyen ismert szolgáltatáshoz. A módosításhoz adjunk hozzá egy ilyen sort az /etc/ssh/sshd_config fájlhoz:
# Run ssh on a non-standard port:Port 2345 #Change me
és indítsd újra az sshd szolgáltatást. Ne felejtsd el ezután elvégezni a porttovábbítás szükséges módosításait az útválasztódban és az alkalmazandó tűzfalszabályokat. CentOS 7 (és újabb) rendszereken például úgy módosíthatja a firewalld ssh szolgáltatását, hogy készít egy másolatot a service fájljáról az /etc/firewalld/ állományban, és megváltoztatja a port sorát:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Majd módosítsa a port sort az /etc/firewalld/services/ssh-custom.xml állományban, hogy a port megegyezzen az ssh konfigurációs fájlban szereplővel:
<port protocol="tcp" port="2345"/>
Végül távolítsa el az ssh szolgáltatást, adja hozzá az ssh-custom szolgáltatást, és töltse újra a firewalld-ot, hogy a változás hatályba lépjen:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Vagy CentOS 6 esetén adjon hozzá egy iptable szabályt az új ssh port megnyitásához:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Ne felejtsük el lezárni a régi portot is.
CentOS 6-on és felette a selinuxot is frissíteni kell, a kiválasztott portot helyesen felcímkézve, különben az sshd nem fog tudni hozzáférni. Például:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Mivel az ssh már nem a szabványos porton várja a kapcsolatokat, meg kell mondania a kliensének, hogy milyen porton csatlakozzon. Az ssh klienst parancssorból használva a -p kapcsolóval adhatjuk meg a portot:
$ ssh -p 2345 myserver
vagy ha például a konquerorban a fish protokollt használjuk:
fish://myserver:2345/remote/dir
Ha úgy gondolja, hogy ez úgy hangzik, hogy minden egyes csatlakozáskor meg kell adnia a portot, egyszerűen adjon hozzá egy bejegyzést a port megadására a helyi ~/.ssh/config fájlban:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
És a fájlt: A ~/.ssh/config fájlnak a következő jogosultságokkal kell rendelkeznie:
$ chmod 600 ~/.ssh/config
Szűrje az SSH-t a tűzfalon
Ha csak egy IP-címről van szüksége távoli hozzáférésre (mondjuk a munkahelyéről az otthoni szerverére), akkor fontolja meg a kapcsolatok szűrését a tűzfalán, vagy egy tűzfalszabály hozzáadásával az útválasztón vagy az iptables-ben, hogy a 22-es porton való hozzáférést csak erre az adott IP-címre korlátozza. Az iptablesben ez például a következő típusú iptables szabállyal érhető el (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
vagy a firwalld használatával (CentOS 7) a rich-rules használatával engedélyezheti az ssh-t csak egy adott porton. A forráscím lehet egyetlen cím vagy alapcím bitmaszkkal:
Az ssh szintén natívan támogatja a TCP wrappereket, és az ssh szolgáltatáshoz való hozzáférés hasonlóan szabályozható a hosts.allow és hosts.deny használatával.
Ha nem tudja korlátozni a forrás IP-címeket, és globálisan kell megnyitnia az ssh portot, akkor az iptables még mindig segíthet a brute-force támadások megelőzésében azáltal, hogy naplózza és blokkolja az ugyanazon IP-címről történő ismételt bejelentkezési kísérleteket. Például az iptables
Az első szabály rögzíti a 22-es porthoz való hozzáférés minden új kísérletének IP-címét a recent modul segítségével. A második szabály ellenőrzi, hogy ez az IP-cím az elmúlt 60 másodpercen belül négyszer vagy többször próbált-e csatlakozni, és ha nem, akkor a csomagot elfogadja. Vegye figyelembe, hogy ez a szabály alapértelmezett DROP házirendet igényel a bemeneti láncban.
Ne felejtse el a portot megfelelően módosítani, ha az ssh-t nem szabványos porton futtatja. Ahol lehetséges, a tűzfalnál történő szűrés rendkívül hatékony módszer az ssh-kiszolgálóhoz való hozzáférés biztosítására.
A FirewallD szolgáltatást használó rendszereknél (CentOS 7 vagy magasabb) használja a firewall-cmd-t:
Az első parancs eltávolítja a megengedőbb szolgáltatási szabályt, a második olyan szabályt állít be, amely egy perc alatt csak 4 kapcsolatot fogad el, és minden kapcsolatot naplóz.
Nyilvános/magánkulcsok használata hitelesítéshez
A titkosított kulcsok használata hitelesítéshez két fő előnnyel jár. Először is kényelmes, mivel nyilvános/magánkulcsok használata esetén nem kell többé jelszót megadni (kivéve, ha a kulcsokat jelszóvédelemmel titkosítja). Másodszor, miután a nyilvános/magán kulcspáros hitelesítést beállította a kiszolgálón, teljesen letilthatja a jelszavas hitelesítést, ami azt jelenti, hogy engedélyezett kulcs nélkül nem kaphat hozzáférést – így nincs több jelszófeltörési kísérlet.
Viszonylag egyszerű folyamat a nyilvános/magán kulcspár létrehozása és telepítése az ssh-kiszolgálón való használathoz.
Először hozzon létre egy nyilvános/magán kulcspárt azon az ügyfélgépen, amelyet a szerverhez való csatlakozáshoz fog használni (ezt minden olyan ügyfélgépen meg kell tennie, amelyről csatlakozik):
$ ssh-keygen -t rsa
Ha nem akarja, hogy minden egyes csatlakozáskor továbbra is kérdezzenek egy jelszót (ami gyakorlatilag egy jelszó az adott nyilvános kulcs feloldásához), akkor a kulcspár létrehozásakor csak nyomja meg az Entert, amikor a jelszót kérik. Önön múlik, hogy a kulcs létrehozásakor hozzáadja-e a kulcsához a jelszavas védőtitkosítást vagy sem. Ha nem védi jelszóval a kulcsát, akkor bárki, aki hozzáfér a helyi gépéhez, automatikusan ssh hozzáféréssel rendelkezik a távoli kiszolgálóhoz. Emellett a helyi gépen a root is hozzáfér a kulcsaidhoz, bár az ember feltételezi, hogy ha nem bízhatsz a root-ban (vagy a root kompromittálódik), akkor nagy bajban vagy. A kulcs titkosítása további biztonságot ad annak árán, hogy megszűnik a jelszó megadása az ssh-kiszolgálóhoz, amit csak a kulcs használatához szükséges jelszó megadása vált fel. Ezt tovább egyszerűsítheti az ssh_agent program használata
Most állítsd be a jogosultságokat a privát kulcsodhoz:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Másolja a nyilvános kulcsot (id_rsa.pub) a szerverre, és telepítse az authorized_keys listára:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Figyelem: miután importálta a nyilvános kulcsot, törölheti azt a kiszolgálóról.
és végül állítsuk be a szerveren a fájlengedélyeket:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
A fenti engedélyekre akkor van szükség, ha az /etc/ssh/sshd_config állományban a StrictModes értéke yes (alapértelmezett).
Győződjön meg arról, hogy a megfelelő SELinux-kontextusok be vannak állítva:
$ restorecon -Rv ~/.ssh
Most a szerverre való bejelentkezéskor nem fog jelszót kérni a rendszer (kivéve, ha a kulcspár létrehozásakor megadtál egy jelszót). Alapértelmezés szerint az ssh először a kulcsok segítségével próbál hitelesíteni. Ha nem talál kulcsot, vagy a hitelesítés sikertelen, akkor az ssh a hagyományos jelszavas hitelesítéshez tér vissza.
Mihelyt ellenőrizte, hogy sikeresen be tud-e jelentkezni a szerverre a nyilvános/magán kulcspár használatával, teljesen kikapcsolhatja a jelszavas hitelesítést a következő beállítás hozzáadásával az /etc/ssh/sshd_config fájlhoz:
# Disable password authentication forcing use of keysPasswordAuthentication no
Gyakran ismételt kérdés (GYIK)
Q: A CentOS az OpenSSH X verzióját használja, a legújabb verzió pedig az Y verzió. Az X verzió súlyos biztonsági hibát tartalmazott, frissítenem kell?
A: Nem. Az Upstream Vendornak van egy olyan irányelve, hogy a biztonsági javításokat a legújabb kiadásokból visszaportálja az aktuális disztribúciós verzióba. Amíg a legfrissebb frissítéseket alkalmazza a CentOS disztribúciójához, addig teljes mértékben foltozott. A biztonsági javítások visszaportálásával kapcsolatos további részletekért lásd itt:
http://www.redhat.com/advice/speaks_backport.html
K: Hogyan tudom elérni, hogy az ssh engedélyezze a jelszó nélküli kulcsalapú hitelesítést olyan gépek között, amelyek NFS-en keresztül megosztják a felhasználók otthoni könyvtárát?
A: A SElinux alapértelmezés szerint blokkolja a root hozzáférést az NFS megosztott könyvtárakhoz és fájlokhoz, amelyek nem olvashatók a világ számára, így az sshd nem tudja olvasni a felhasználók kulcsfájljait a ~/.ssh fájlban. A hozzáférés engedélyezéséhez módosítsa a use_nfs_home_dirs beállítását a következő parancs superuser-ként történő futtatásával:
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
.