Beveilig de SSH-verbinding van uw Linux-systeem om uw systeem en gegevens te beschermen. Zowel systeembeheerders als thuisgebruikers moeten computers die op het internet zijn gericht versterken en beveiligen, maar SSH kan gecompliceerd zijn. Hier zijn tien eenvoudige quick-wins om uw SSH-server te helpen beschermen.
SSH-beveiligingsbeginselen
SSH staat voor Veilige Shell . De naam "SSH" wordt door elkaar gebruikt om ofwel het SSH-protocol zelf aan te duiden, ofwel de softwaretools waarmee systeembeheerders en gebruikers veilige verbindingen kunnen maken met externe computers die dat protocol gebruiken.
Het SSH-protocol is een gecodeerd protocol dat is ontworpen om een veilige verbinding te bieden via een onveilig netwerk, zoals internet. SSH in Linux is gebouwd op een draagbare versie van het OpenSSH project. Het is geïmplementeerd in een classic client-server model , met een SSH-server die verbindingen van SSH-clients accepteert. De client wordt gebruikt om verbinding te maken met de server en met Scherm de sessie met de externe gebruiker. De server accepteert de verbinding en wordt uitgevoerd de sessie.
In de standaardconfiguratie luistert een SSH-server naar inkomende verbindingen op het Transmission Control Protocol ( TCP ) poort 22. Omdat dit een gestandaardiseerde, bekende haven , het is een doelwit voor dreigingsactoren en kwaadaardige bots .
Bedreigingsactoren lanceren bots die een reeks IP-adressen scannen op zoek naar open poorten. De poorten worden vervolgens onderzocht om te zien of er kwetsbaarheden zijn die kunnen worden misbruikt. Denken: "Ik ben veilig, er zijn grotere en betere doelen dan ik waar de slechteriken op kunnen mikken", is een verkeerde redenering. De bots selecteren geen doelen op basis van verdiensten; ze zijn methodisch op zoek naar systemen die ze kunnen doorbreken.
U nomineert uzelf als slachtoffer als u uw systeem niet heeft beveiligd.
Beveiligingswrijving
Beveiligingsfrictie is de irritatie - in welke mate dan ook - die gebruikers en anderen zullen ervaren wanneer u beveiligingsmaatregelen implementeert. We hebben lange herinneringen en kunnen ons herinneren dat we nieuwe gebruikers kennis hebben gemaakt met een computersysteem, en ze met een gruwelijke stem horen vragen of ze werkelijk moest een wachtwoord invoeren elke keer ze logden in op het mainframe. Dat was voor hen een veiligheidswrijving.
(Overigens wordt aan de uitvinding van het wachtwoord toegeschreven Fernando J. Corbató , nog een figuur in het pantheon van computerwetenschappers wier gecombineerde werk bijdroeg aan de omstandigheden die leidden tot de geboorte van Unix .)
Het invoeren van beveiligingsmaatregelen brengt voor iemand meestal een vorm van wrijving met zich mee. Bedrijfseigenaren moeten ervoor betalen. Het kan zijn dat de computergebruikers hun vertrouwde praktijken moeten veranderen, of een andere set authenticatiedetails moeten onthouden, of extra stappen moeten toevoegen om succesvol verbinding te maken. De systeembeheerders zullen extra werk moeten doen om de nieuwe beveiligingsmaatregelen te implementeren en te onderhouden.
Het verharden en vergrendelen van een Linux- of Unix-achtig besturingssysteem kan erg snel betrokken raken. Wat we hier presenteren, is een reeks eenvoudig te implementeren stappen die de beveiliging van uw computer zullen verbeteren zonder dat er applicaties van derden nodig zijn en zonder door uw firewall te graven.
Deze stappen zijn niet het laatste woord in SSH-beveiliging, maar ze zullen je een heel eind vooruit helpen ten opzichte van de standaardinstellingen, en zonder al te veel wrijving.
Gebruik SSH-protocol versie 2
In 2006 is het SSH-protocol bijgewerkt van versie 1 naar versie 2 . Het was een flinke upgrade. Er waren zoveel veranderingen en verbeteringen, vooral rond encryptie en beveiliging, dat versie 2 niet achterwaarts compatibel is met versie 1. Om verbindingen van versie 1 clients te voorkomen, kun je bepalen dat je computer alleen verbindingen van versie 2 clients accepteert.
Bewerk hiervoor het
/ etc / ssh / sshd_config
het dossier. We zullen dit in dit artikel veel doen. Elke keer dat u dit bestand moet bewerken, is dit de opdracht die u moet gebruiken:
sudo gedit / etc / ssh / sshd_config
Voeg de regel toe:
Protocol 2
En sla het bestand op. We gaan het SSH-daemonproces opnieuw starten. Nogmaals, we zullen dit in dit artikel veel doen. Dit is de opdracht die u in elk geval moet gebruiken:
sudo systemctl herstart sshd
Laten we eens kijken of onze nieuwe instelling van kracht is. We springen over naar een andere machine en proberen SSH op onze testmachine te plaatsen. En we zullen de
-1
(protocol 1) optie om het
ssh
opdracht om protocolversie 1 te gebruiken.
ssh -1 [email protected]
Geweldig, ons verbindingsverzoek is afgewezen. Laten we ervoor zorgen dat we nog steeds verbinding kunnen maken met protocol 2. We gebruiken de
-2
(protocol 2) optie om het feit te bewijzen.
ssh -2 [email protected]
Het feit dat de SSH-server ons wachtwoord vraagt, is een positieve indicatie dat de verbinding tot stand is gebracht en dat u met de server communiceert. Omdat moderne SSH-clients standaard protocol 2 gebruiken, hoeven we protocol 2 niet te specificeren zolang onze client up-to-date is.
ssh [email protected]
En onze verbinding is geaccepteerd. Het zijn dus alleen de zwakkere en minder veilige protocol 1-verbindingen die worden afgewezen.
Vermijd poort 22
Poort 22 is de standaardpoort voor SSH-verbindingen. Als u een andere poort gebruikt, voegt dit een beetje beveiliging door onduidelijkheid toe aan uw systeem. Veiligheid door onduidelijkheid wordt nooit als een echte veiligheidsmaatregel beschouwd, en ik heb er in andere artikelen tegen uitgescholden. Sommige van de slimmere aanvalsrobots onderzoeken zelfs alle open poorten en bepalen welke service ze voeren, in plaats van te vertrouwen op een eenvoudige opzoeklijst van poorten en ervan uitgaande dat ze de gebruikelijke services bieden. Maar het gebruik van een niet-standaard poort kan helpen om het geluid en het slechte verkeer op poort 22 te verminderen.
Bewerk uw SSH-configuratiebestand om een niet-standaardpoort te configureren:
sudo gedit / etc / ssh / sshd_config
Verwijder het hekje # aan het begin van de "Port" -regel en vervang de "22" door het poortnummer van uw keuze. Sla uw configuratiebestand op en start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
Laten we eens kijken welk effect dat heeft gehad. Op onze andere computer gebruiken we de
ssh
commando om verbinding te maken met onze server. De
ssh
commando gebruikt standaard poort 22:
ssh [email protected]
Onze verbinding is geweigerd. Laten we het opnieuw proberen en poort 470 specificeren met de optie -p (poort):
ssh -p 479 [email protected]
Onze verbinding is geaccepteerd.
Filter verbindingen met behulp van TCP-wrappers
TCP Wrappers is een gemakkelijk te begrijpen toegangscontrole lijst . Hiermee kunt u verbindingen uitsluiten en toestaan op basis van de kenmerken van het verbindingsverzoek, zoals IP-adres of hostnaam. TCP-wrappers moeten worden gebruikt in combinatie met, en niet in plaats van, een correct geconfigureerde firewall. In ons specifieke scenario kunnen we de zaken aanzienlijk aanscherpen door TCP-wrappers te gebruiken.
TCP-wrappers waren al geïnstalleerd op de Ubuntu 18.04 LTS-machine die werd gebruikt om dit artikel te onderzoeken. Het moest worden geïnstalleerd op Manjaro 18.10 en Fedora 30.
Gebruik dit commando om op Fedora te installeren:
sudo yum installeer tcp_wrappers
Gebruik deze opdracht om op Manjaro te installeren:
sudo pacman -Syu tcp-wrappers
Er zijn twee bestanden bij betrokken. De ene bevat de toegestane lijst en de andere bevat de geweigerde lijst. Bewerk de weigerlijst met:
sudo gedit /etc/hosts.deny
Dit opent het
gedit
editor met het deny-bestand erin geladen.
U moet de regel toevoegen:
ALLES: ALLES
En sla het bestand op. Dat blokkeert alle toegang die niet is geautoriseerd. We moeten nu de verbindingen autoriseren die u wilt accepteren. Om dat te doen, moet u het allow-bestand bewerken:
sudo gedit /etc/hosts.allow
Dit opent het
gedit
editor met het allow-bestand erin geladen.
We hebben de naam van de SSH-daemon toegevoegd,
SSHD
, En het IP-adres van de computer waarmee we verbinding kunnen maken. Sla het bestand op en laten we kijken of de beperkingen en machtigingen van kracht zijn.
Eerst proberen we verbinding te maken vanaf een computer die niet in de
hosts.allow
het dossier:
De verbinding is geweigerd. We zullen nu proberen verbinding te maken vanaf de machine op IP-adres 192.168.4.23:
Onze verbinding is geaccepteerd.
Ons voorbeeld hier is een beetje brutaal: slechts één computer kan verbinding maken. TCP-wrappers zijn behoorlijk veelzijdig en flexibeler dan dit. Het ondersteunt hostnamen, jokertekens en subnetmaskers om verbindingen van reeksen IP-adressen te accepteren. U wordt aangemoedigd bekijk de man-pagina .
Verbindingsverzoeken weigeren zonder wachtwoorden
Hoewel het een slechte gewoonte is, kan een Linux-systeembeheerder een gebruikersaccount zonder wachtwoord aanmaken. Dat betekent dat externe verbindingsverzoeken van dat account geen wachtwoord hebben om te controleren. Die verbindingen worden geaccepteerd, maar niet geverifieerd.
De standaardinstellingen voor SSH accepteren verbindingsverzoeken zonder wachtwoorden. We kunnen dat heel gemakkelijk wijzigen en ervoor zorgen dat alle verbindingen worden geverifieerd.
We moeten uw SSH-configuratiebestand bewerken:
sudo gedit / etc / ssh / sshd_config
Blader door het bestand totdat u de regel ziet met "#PermitEmptyPasswords no." Verwijder de hasj
#
vanaf het begin van de regel en sla het bestand op. Start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
Gebruik SSH-sleutels in plaats van wachtwoorden
SSH-sleutels bieden een veilige manier om in te loggen op een SSH-server. Wachtwoorden kunnen worden geraden, gekraakt of brute-forced . SSH-sleutels staan niet open voor dergelijke soorten aanvallen.
Wanneer u SSH-sleutels genereert, maakt u een paar sleutels aan. De ene is de openbare sleutel en de andere is de privésleutel. De openbare sleutel is geïnstalleerd op de servers waarmee u verbinding wilt maken. De privésleutel, zoals de naam doet vermoeden, wordt veilig bewaard op uw eigen computer.
Met SSH-sleutels kunt u verbindingen tot stand brengen zonder wachtwoord die - contra-intuïtief - veiliger zijn dan verbindingen die wachtwoordverificatie gebruiken.
Wanneer u een verbindingsverzoek doet, gebruikt de externe computer de kopie van uw openbare sleutel om een gecodeerd bericht te maken dat naar uw computer wordt teruggestuurd. Omdat het is versleuteld met uw openbare sleutel, kan uw computer het ontsleutelen met uw privésleutel.
Uw computer haalt vervolgens wat informatie uit het bericht, met name de sessie-ID, versleutelt die en stuurt het terug naar de server. Als de server het kan decoderen met een kopie van uw openbare sleutel, en als de informatie in het bericht overeenkomt met wat de server naar u heeft gestuurd, wordt bevestigd dat uw verbinding van u afkomstig is.
Hier wordt verbinding gemaakt met de server op 192.168.4.11, door een gebruiker met SSH-sleutels. Merk op dat ze niet om een wachtwoord worden gevraagd.
ssh [email protected]
SSH-sleutels verdienen een artikel helemaal voor zichzelf. Handig, we hebben er een voor u. Hier is hoe u SSH-sleutels aanmaakt en installeert .
VERWANT: SSH-sleutels maken en installeren vanuit de Linux-shell
Schakel wachtwoordverificatie helemaal uit
De logische uitbreiding van het gebruik van SSH-sleutels is natuurlijk dat als alle externe gebruikers gedwongen worden deze te gebruiken, u wachtwoordverificatie volledig kunt uitschakelen.
We moeten uw SSH-configuratiebestand bewerken:
sudo gedit / etc / ssh / sshd_config
Blader door het bestand totdat u de regel ziet die begint met "#PasswordAuthentication yes". Verwijder de hasj
#
verander vanaf het begin van de regel de "ja" in "nee" en sla het bestand op. Start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
Schakel X11 Forwarding uit
Met X11-forwarding kunnen externe gebruikers grafische applicaties vanaf uw server uitvoeren via een SSH-sessie. In de handen van een bedreigingsacteur of kwaadwillende gebruiker kan een GUI-interface hun kwaadaardige doeleinden gemakkelijker maken.
Een standaardmantra in cybersecurity is: als je geen bonafide reden hebt om het aan te zetten, zet het dan uit. We doen dit door uw SSH-configuratiebestand te bewerken:
sudo gedit / etc / ssh / sshd_config
Blader door het bestand totdat u de regel ziet die begint met "# X11Forwarding no." Verwijder de hasj
#
vanaf het begin van de regel en sla het bestand op. Start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
Stel een inactieve time-outwaarde in
Als er een SSH-verbinding met uw computer tot stand is gebracht en er gedurende een bepaalde tijd geen activiteit op heeft plaatsgevonden, kan dit een beveiligingsrisico vormen. De kans bestaat dat de gebruiker zijn bureau heeft verlaten en ergens anders bezig is. Iedereen die langs zijn bureau komt, kan gaan zitten en aan de slag met zijn computer en, via SSH, jouw computer.
Het is veel veiliger om een time-outlimiet in te stellen. De SSH-verbinding wordt verbroken als de inactieve periode overeenkomt met de tijdslimiet. We zullen nogmaals uw SSH-configuratiebestand bewerken:
sudo gedit / etc / ssh / sshd_config
Blader door het bestand totdat u de regel ziet die begint met "#ClientAliveInterval 0". Verwijder de hash
#
Wijzig vanaf het begin van de regel het cijfer 0 in de gewenste waarde. We hebben 300 seconden gebruikt, dat is 5 minuten. Sla het bestand op en start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
Stel een limiet in voor wachtwoordpogingen
Het definiëren van een limiet voor het aantal authenticatiepogingen kan het raden van wachtwoorden en brute-force-aanvallen helpen voorkomen. Na het aangegeven aantal authenticatieverzoeken wordt de verbinding van de gebruiker met de SSH-server verbroken. Standaard is er geen limiet. Maar dat is snel verholpen.
Nogmaals, we moeten uw SSH-configuratiebestand bewerken:
sudo gedit / etc / ssh / sshd_config
Blader door het bestand totdat u de regel ziet die begint met "#MaxAuthTries 0". Verwijder de hasj
#
Wijzig vanaf het begin van de regel het cijfer 0 in de gewenste waarde. We hebben er hier drie gebruikt. Sla het bestand op toen u uw wijzigingen aanbracht en start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
We kunnen dit testen door te proberen verbinding te maken en opzettelijk een onjuist wachtwoord in te voeren.
Merk op dat het MaxAuthTries-nummer één meer leek te zijn dan het aantal pogingen dat de gebruiker was toegestaan. Na twee mislukte pogingen wordt de verbinding met onze testgebruiker verbroken. Dit was met MaxAuthTries ingesteld op drie.
Schakel root-aanmeldingen uit
Het is een slechte gewoonte om in te loggen als root op uw Linux-computer. U moet inloggen als een normale gebruiker en gebruiken
sudo
om acties uit te voeren waarvoor root-rechten vereist zijn. Sterker nog, je moet root niet toestaan in te loggen op je SSH-server. Alleen gewone gebruikers mogen verbinding maken. Als ze een administratieve taak moeten uitvoeren, moeten ze
sudo
te. Als u een rootgebruiker moet toestaan in te loggen, kunt u deze in ieder geval dwingen SSH-sleutels te gebruiken.
Voor de laatste keer zullen we uw SSH-configuratiebestand moeten bewerken:
sudo gedit / etc / ssh / sshd_config
Blader door het bestand totdat u de regel ziet die begint met "#PermitRootLogin verbied-wachtwoord" Verwijder de hash
#
vanaf het begin van de lijn.
- Als je wilt voorkomen dat root inlogt, vervang dan “verbied-wachtwoord” door “nee”.
- Als je root toestemming geeft om in te loggen, maar ze dwingt SSH-sleutels te gebruiken, laat je "verbied-wachtwoord" staan.
Sla uw wijzigingen op en start de SSH-daemon opnieuw:
sudo systemctl herstart sshd
De ultieme stap
Als je SSH helemaal niet op je computer nodig hebt, zorg er dan voor dat deze is uitgeschakeld.
sudo systemctl stop sshd
sudo systemctl uitschakelen sshd
Als je het raam niet opent, kan niemand erin klimmen.
