<<TableOfContents: uitvoering mislukt “] (zie ook het logboek)>>
OpenSSH (of Secure SHell) is een de facto standaard geworden voor toegang op afstand ter vervanging van het telnet-protocol. SSH heeft protocollen als telnet overbodig gemaakt, grotendeels omdat de verbinding is versleuteld en wachtwoorden niet langer in platte tekst worden verzonden, zodat iedereen ze kan zien.
Echter, een standaard installatie van ssh is niet perfect, en bij het draaien van een ssh server zijn er een paar eenvoudige stappen die een installatie drastisch kunnen verharden.
Gebruik sterke wachtwoorden/gebruikersnamen
Eén van de eerste dingen die u zal opvallen als u ssh draait en blootgesteld bent aan de buitenwereld, is dat u waarschijnlijk pogingen van hackers zult loggen om uw gebruikersnaam/wachtwoord te raden. Meestal scant een hacker naar poort 22 (de standaardpoort waarop ssh luistert) om machines te vinden waarop ssh draait, en probeert er dan een brute-force aanval op uit te voeren. Met sterke wachtwoorden wordt hopelijk iedere aanval gelogd en opgemerkt voordat hij kan slagen.
Hopelijk gebruikt u al sterke wachtwoorden, maar als u dat niet doet, probeer dan wachtwoorden te kiezen die bevatten:
- Minimaal 8 tekens
- Mix van hoofdletters en kleine letters
- Mix van letters en cijfers
- Niet alfanumerieke tekens (b.v. speciale tekens zoals ! ” £ $ % ^ etc)
De voordelen van sterke wachtwoorden zijn niet specifiek voor ssh, maar hebben invloed op alle aspecten van systeembeveiliging. Meer informatie over wachtwoorden is te vinden in de CentOS documentatie:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Als u absoluut niet kunt voorkomen dat uw gebruikers zwakke wachtwoorden kiezen, overweeg dan om willekeurig gegenereerde of moeilijk te raden gebruikersnamen te gebruiken voor uw gebruikersaccounts. Als de slechteriken de gebruikersnaam niet kunnen raden, kunnen ze het wachtwoord ook niet kraken. Dit is echter nog steeds beveiliging door onduidelijkheid en wees je bewust van het lekken van gebruikersnamen door bijvoorbeeld emails die vanaf gebruikersaccounts worden verzonden.
Root logins uitschakelen
SSH server instellingen worden opgeslagen in het /etc/ssh/sshd_config bestand. Om root logins uit te schakelen, zorg ervoor dat u de volgende entry hebt:
# Prevent root logins:PermitRootLogin no
en herstart de sshd service:
service sshd restart
Als u root-toegang nodig heeft, log dan in als een normale gebruiker en gebruik het su commando.
Limit User Logins
SSH logins kunnen worden beperkt tot alleen bepaalde gebruikers die toegang op afstand nodig hebben. Als er veel gebruikersaccounts op het systeem zijn, dan is het zinvol om toegang op afstand te beperken tot diegenen die het echt nodig hebben, zodat de gevolgen van een toevallige gebruiker met een zwak wachtwoord beperkt worden. Voeg een regel AllowUsers toe aan /etc/ssh/sshd_config, gevolgd door een door spaties gescheiden lijst van gebruikersnamen Bijvoorbeeld
AllowUsers alice bob
en herstart de sshd service.
Disable Protocol 1
SSH heeft twee protocollen die het kan gebruiken, protocol 1 en protocol 2. Het oudere protocol 1 is minder veilig en moet worden uitgeschakeld, tenzij u weet dat u het specifiek nodig hebt. Zoek de volgende regel in het bestand /etc/ssh/sshd_config, maak er een kommentaar van en wijzig het zoals getoond:
# Protocol 2,1Protocol 2
en herstart de sshd service.
Gebruik een Niet-Standaard Poort
Standaard luistert ssh naar inkomende verbindingen op poort 22. Om een hacker te laten vaststellen dat ssh op uw machine draait, zal hij waarschijnlijk poort 22 scannen om dit vast te stellen. Een effectieve methode is om ssh op een niet-standaard poort te draaien. Elke ongebruikte poort is goed, hoewel een boven 1024 de voorkeur heeft. Veel mensen kiezen 2222 als alternatieve poort (omdat die gemakkelijk te onthouden is), net zoals 8080 vaak bekend staat als de alternatieve HTTP poort. Juist om deze reden is het waarschijnlijk niet de beste keuze, omdat elke hacker die poort 22 scant waarschijnlijk ook poort 2222 scant. Het is beter om een willekeurige hoge poort te kiezen die niet gebruikt wordt voor bekende diensten. Om de wijziging door te voeren, voeg een regel als deze toe aan uw /etc/ssh/sshd_config bestand:
# Run ssh on a non-standard port:Port 2345 #Change me
en herstart de sshd service. Vergeet niet om vervolgens de nodige wijzigingen aan te brengen aan port forwarding in je router en alle toepasselijke firewall regels. Bijvoorbeeld op CentOS 7 (en hoger) kun je de ssh service van firewalld veranderen door een duplicaat te maken van zijn service bestand in /etc/firewalld/ en de poort regel te veranderen:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Verander dan de poortlijn in /etc/firewalld/services/ssh-custom.xml zodat de poort dezelfde is als in het ssh config bestand:
<port protocol="tcp" port="2345"/>
Tot slot, verwijder de ssh service, voeg de ssh-custom service toe, en herlaad firewalld om de verandering effect te laten hebben:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Of op CentOS 6, voeg een iptable regel toe om de nieuwe ssh poort te openen:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Vergeet niet om de oude poort ook te sluiten.
Op CentOS 6 en hoger moet je ook selinux updaten, en de gekozen poort juist labelen, anders zal sshd geen toegang meer krijgen. Bijvoorbeeld:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Omdat ssh niet langer luistert naar verbindingen op de standaard poort, moet u uw client vertellen op welke poort hij verbinding moet maken. Met de ssh client vanaf de commandoregel, kunnen we de poort specificeren met de -p switch:
$ ssh -p 2345 myserver
of als u het fish protocol in konqueror gebruikt, bijvoorbeeld:
fish://myserver:2345/remote/dir
Als u denkt dat dit pijnlijk klinkt omdat u elke keer dat u verbinding maakt de poort moet specificeren, voeg dan gewoon een entry toe die de poort specificeert in uw lokale ~/.ssh/config bestand:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
En het bestand: ~/.ssh/config moet de volgende permissies hebben:
$ chmod 600 ~/.ssh/config
Filter SSH op de Firewall
Als u slechts toegang op afstand nodig heeft vanaf één IP adres (bijvoorbeeld van uw werk naar uw server thuis), overweeg dan om verbindingen te filteren op uw firewall door ofwel een firewall regel toe te voegen op uw router of in iptables om de toegang op poort 22 te beperken tot alleen dat specifieke IP adres. In iptables zou dit bijvoorbeeld bereikt kunnen worden met het volgende type regel voor iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
of met firwalld (CentOS 7) rich-rules gebruiken om ssh op alleen een specifieke poort toe te staan. Het bronadres kan een enkel adres zijn of een basisadres met een bitmask:
SSH ondersteunt ook van nature TCP wrappers en toegang tot de ssh service kan op vergelijkbare wijze worden gecontroleerd met hosts.allow en hosts.deny.
Als u niet in staat bent om bron IP adressen te beperken, en de ssh poort globaal moet openen, dan kan iptables nog steeds brute-force aanvallen helpen voorkomen door herhaalde pogingen om in te loggen vanaf hetzelfde IP adres te loggen en te blokkeren. Bijvoorbeeld, met iptables
De eerste regel registreert het IP adres van elke nieuwe poging om poort 22 te benaderen met de recente module. De tweede regel controleert of dat IP adres 4 of meer pogingen gedaan heeft om verbinding te maken binnen de laatste 60 seconden, en indien niet, dan wordt het pakket aanvaard. Merk op dat deze regel een standaard beleid van DROP op de ingangsketen zou vereisen.
Vergeet niet om de poort aan te passen als u ssh op een niet-standaard poort draait. Waar mogelijk is het filteren op de firewall een zeer effectieve methode om de toegang tot een ssh server te beveiligen.
Voor systemen die de FirewallD service gebruiken (CentOS 7 of hoger), gebruik firewall-cmd:
Het eerste commando verwijdert de meer permissieve dienstregel, het tweede installeert een regel om slechts 4 verbindingen in een minuut te accepteren en alle verbindingen te loggen.
Gebruik Publieke/Private Sleutels voor Authenticatie
Het gebruik van gecodeerde sleutels voor authenticatie biedt twee grote voordelen. Ten eerste is het handig omdat u geen wachtwoord meer hoeft in te voeren (tenzij u uw sleutels codeert met wachtwoordbeveiliging) als u publieke/private sleutels gebruikt. Ten tweede, zodra authenticatie met een publiek/privaat sleutelpaar is ingesteld op de server, kunt u wachtwoordauthenticatie volledig uitschakelen, wat betekent dat u zonder een geautoriseerde sleutel geen toegang kunt krijgen – dus geen pogingen meer om wachtwoorden te kraken.
Het is een relatief eenvoudig proces om een publiek/privaat sleutelpaar te maken en ze te installeren voor gebruik op uw ssh server.
Maak eerst een publiek/privaat sleutelpaar op de client die u zult gebruiken om verbinding te maken met de server (u moet dit doen vanaf elke client-machine van waaruit u verbinding maakt):
$ ssh-keygen -t rsa
Als u niet steeds om een passphrase (in feite een wachtwoord om een bepaalde publieke sleutel te ontgrendelen) wilt worden gevraagd wanneer u verbinding maakt, druk dan op enter wanneer u om een passphrase wordt gevraagd bij het aanmaken van het sleutelpaar. Het is aan u om te beslissen of u al dan niet de passphrase beschermende encryptie aan uw sleutel moet toevoegen wanneer u hem aanmaakt. Als u uw sleutel niet met een wachtwoordzin beveiligt, dan zal iedereen die toegang krijgt tot uw lokale machine automatisch ssh-toegang krijgen tot de server op afstand. Ook heeft root op de lokale machine toegang tot uw sleutels, hoewel men aanneemt dat als u root niet kunt vertrouwen (of root is gecompromitteerd), u echt in de problemen zit. Het versleutelen van de sleutel voegt extra veiligheid toe ten koste van de noodzaak om een wachtwoord voor de ssh server in te voeren, alleen te vervangen door het invoeren van een passphrase voor het gebruik van de sleutel. Dit kan verder worden vereenvoudigd door het gebruik van het ssh_agent programma
Nu rechten instellen op uw private sleutel:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Kopieer de publieke sleutel (id_rsa.pub) naar de server en installeer hem in de lijst authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Note: zodra u de publieke sleutel hebt geïmporteerd, kunt u deze van de server verwijderen.
en stel tenslotte de bestandsrechten op de server in:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
De bovenstaande permissies zijn nodig als StrictModes op yes staat in /etc/ssh/sshd_config (de standaard).
Zorg ervoor dat de juiste SELinux contexten zijn ingesteld:
$ restorecon -Rv ~/.ssh
Als u nu inlogt op de server, wordt u niet om een wachtwoord gevraagd (tenzij u een passphrase hebt opgegeven toen u uw sleutelpaar aanmaakte). Standaard zal ssh eerst proberen te authenticeren met sleutels. Als er geen sleutels worden gevonden of de authenticatie mislukt, dan valt ssh terug op conventionele wachtwoordauthenticatie.
Als je eenmaal hebt gecontroleerd dat je met succes kunt inloggen op de server met je publieke/privé sleutelpaar, dan kun je de wachtwoord authenticatie volledig uitschakelen door de volgende instelling toe te voegen aan je /etc/ssh/sshd_config bestand:
# Disable password authentication forcing use of keysPasswordAuthentication no
Veel Gestelde Vragen (FAQ)
Q: CentOS gebruikt versie X van OpenSSH en de laatste versie is versie Y. Versie X bevatte een ernstige beveiligingsfout, moet ik upgraden?
A: Nee. De Upstream Vendor heeft een beleid van backporting van beveiligingspatches van de nieuwste releases naar de huidige distributieversie. Zolang u de laatste updates voor uw CentOS-distributie hebt toegepast, bent u volledig gepatcht. Zie hier voor meer details over het backporteren van beveiligingspatches:
http://www.redhat.com/advice/speaks_backport.html
Q: Hoe krijg ik ssh zo ver dat wachtwoordloze, op sleutels gebaseerde verificatie mogelijk is tussen machines die de homedirectory’s van gebruikers delen via NFS?
A: SElinux blokkeert standaard de root-toegang tot NFS gedeelde directories en bestanden die niet wereld-leesbaar zijn en dus kan sshd de sleutelbestanden van gebruikers in ~/.ssh niet lezen. Om toegang mogelijk te maken, wijzigt u de instelling van use_nfs_home_dirs door het volgende commando uit te voeren als de superuser:
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