Säkra ditt Linux-systems SSH-anslutning för att skydda ditt system och din data. Både systemadministratörer och hemanvändare behöver härda och säkra datorer som är anslutna till internet, men SSH kan vara komplicerat. Här är tio enkla snabbvinster för att skydda din SSH-server.
Innehållsförteckning
SSH-säkerhetsgrunderna
SSH står för Säkert skal. Namnet ”SSH” används omväxlande för att betyda antingen själva SSH-protokollet eller programvaruverktygen som tillåter systemadministratörer och användare att göra säkra anslutningar till fjärrdatorer som använder det protokollet.
SSH-protokollet är ett krypterat protokoll designat för att ge en säker anslutning över ett osäkert nätverk, som internet. SSH i Linux är byggt på en bärbar version av ÖppnaSSH projekt. Det är implementerat i en klassisk klient-server-modell, med en SSH-server som accepterar anslutningar från SSH-klienter. Klienten används för att ansluta till servern och för att visa sessionen för fjärranvändaren. Servern accepterar anslutningen och kör sessionen.
I sin standardkonfiguration kommer en SSH-server att lyssna efter inkommande anslutningar på Transmission Control Protocol (TCP) port 22. Eftersom detta är en standardiserad, välkänd hamndet är ett mål för hotaktörer och skadliga bots.
Hotaktörer lanserar bots som skannar en rad IP-adresser och letar efter öppna portar. Portarna undersöks sedan för att se om det finns sårbarheter som kan utnyttjas. Att tänka: ”Jag är säker, det finns större och bättre mål än mig för de onda att sikta på”, är ett falskt resonemang. Botarna väljer inte mål baserat på några meriter; de letar metodiskt efter system som de kan bryta mot.
Du nominerar dig själv som ett offer om du inte har säkrat ditt system.
Säkerhetsfriktion
Säkerhetsfriktion är den irritation – oavsett grad – som användare och andra kommer att uppleva när du implementerar säkerhetsåtgärder. Vi har långa minnen och kan minnas att vi introducerade nya användare till ett datorsystem och hörde dem fråga med en förskräckt röst om de verkligen var tvungna att ange ett lösenord varje gång de loggade in på stordatorn. Det – för dem – var säkerhetsfriktion.
(För övrigt krediteras uppfinningen av lösenordet Fernando J. Corbatóen annan figur i pantheonen av datavetare vars kombinerade arbete bidrog till omständigheterna som ledde till födelsen av Unix.)
Att införa säkerhetsåtgärder innebär vanligtvis någon form av friktion för någon. Företagare måste betala för det. Datoranvändarna kan behöva ändra sina bekanta metoder, eller komma ihåg en annan uppsättning autentiseringsdetaljer, eller lägga till extra steg för att ansluta framgångsrikt. Systemadministratörerna kommer att ha ytterligare arbete att göra för att implementera och underhålla de nya säkerhetsåtgärderna.
Att härda och låsa ett Linux- eller Unix-liknande operativsystem kan bli väldigt involverat, väldigt snabbt. Det vi presenterar här är en uppsättning steg som är lätta att implementera som förbättrar din dators säkerhet utan att behöva använda tredjepartsprogram och utan att behöva gräva igenom din brandvägg.
Dessa steg är inte det sista ordet i SSH-säkerhet, men de kommer att flytta dig en lång väg framåt från standardinställningarna och utan alltför mycket friktion.
Använd SSH Protocol version 2
2006 uppdaterades SSH-protokollet från version 1 till version 2. Det var en betydande uppgradering. Det gjordes så många förändringar och förbättringar, särskilt kring kryptering och säkerhet, att version 2 inte är bakåtkompatibel med version 1. För att förhindra anslutningar från version 1-klienter kan du bestämma att din dator endast accepterar anslutningar från version 2-klienter.
För att göra det, redigera filen /etc/ssh/sshd_config. Vi kommer att göra det här mycket i den här artikeln. När du behöver redigera den här filen är det här kommandot att använda:
sudo gedit /etc/ssh/sshd_config
Lägg till raden:
Protocol 2
Och spara filen. Vi kommer att starta om SSH-demonprocessen. Återigen, vi kommer att göra det här mycket i den här artikeln. Detta är kommandot som ska användas i varje fall:
sudo systemctl restart sshd
Låt oss kontrollera att vår nya inställning är i kraft. Vi hoppar över till en annan maskin och försöker SSH till vår testmaskin. Och vi kommer att använda alternativet -1 (protokoll 1) för att tvinga ssh-kommandot att använda protokollversion 1.
ssh -1 [email protected]
Bra, vår anslutningsbegäran avslås. Låt oss se till att vi fortfarande kan ansluta till protokoll 2. Vi använder alternativet -2 (protokoll 2) för att bevisa detta.
ssh -2 [email protected]
Det faktum att SSH-servern begär vårt lösenord är en positiv indikation på att anslutningen har gjorts och att du interagerar med servern. Eftersom moderna SSH-klienter som standard kommer att använda protokoll 2, behöver vi faktiskt inte ange protokoll 2 så länge som vår klient är uppdaterad.
ssh [email protected]
Och vår anslutning accepteras. Så det är bara de svagare och mindre säkra protokoll 1-anslutningarna som avvisas.
Undvik port 22
Port 22 är standardporten för SSH-anslutningar. Om du använder en annan port, lägger det till lite säkerhet genom otydlighet till ditt system. Säkerhet genom dunkel anses aldrig vara en sann säkerhetsåtgärd, och jag har kritiserat det i andra artiklar. Faktum är att några av de smartare attackbotarna undersöker alla öppna portar och avgör vilken tjänst de har, snarare än att förlita sig på en enkel uppslagslista över portar och anta att de tillhandahåller de vanliga tjänsterna. Men att använda en icke-standardport kan hjälpa till att minska bullret och dålig trafik på port 22.
För att konfigurera en icke-standardport, redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Ta bort hash # från början av ”Port”-raden och ersätt ”22” med portnumret du väljer. Spara din konfigurationsfil och starta om SSH-demonen:
sudo systemctl restart sshd
Låt oss se vilken effekt det har haft. På vår andra dator använder vi kommandot ssh för att ansluta till vår server. Kommandot ssh använder som standard port 22:
ssh [email protected]
Vår anslutning vägras. Låt oss försöka igen och specificera port 470 med alternativet -p (port):
ssh -p 479 [email protected]
Vår anslutning accepteras.
Filtrera anslutningar med TCP-omslag
TCP Wrappers är en lätt att förstå åtkomstkontrolllista. Det låter dig utesluta och tillåta anslutningar baserat på egenskaperna hos anslutningsbegäran, såsom IP-adress eller värdnamn. TCP-omslag bör användas tillsammans med, och inte istället för, en korrekt konfigurerad brandvägg. I vårt specifika scenario kan vi skärpa sakerna avsevärt genom att använda TCP-omslag.
TCP-omslag var redan installerat på Ubuntu 18.04 LTS-maskinen som användes för att undersöka den här artikeln. Den måste installeras på Manjaro 18.10 och Fedora 30.
För att installera på Fedora, använd detta kommando:
sudo yum install tcp_wrappers
För att installera på Manjaro, använd detta kommando:
sudo pacman -Syu tcp-wrappers
Det är två filer inblandade. En har den tillåtna listan och den andra har den nekade listan. Redigera avslagslistan med:
sudo gedit /etc/hosts.deny
Detta öppnar gedit-redigeraren med deny-filen laddad i den.
Du måste lägga till raden:
ALL : ALL
Och spara filen. Det blockerar all åtkomst som inte har auktoriserats. Vi måste nu godkänna de anslutningar du vill acceptera. För att göra det måste du redigera tillåtsfilen:
sudo gedit /etc/hosts.allow
Detta öppnar gedit-redigeraren med tillåt-filen laddad i den.
Vi har lagt till SSH-demonens namn, SSHD, och IP-adressen för den dator som vi ska tillåta att göra en anslutning. Spara filen och låt oss se om begränsningarna och behörigheterna är i kraft.
Först försöker vi ansluta från en dator som inte finns i filen hosts.allow:
Anslutningen nekas. Vi ska nu försöka ansluta från maskinen på IP-adress 192.168.4.23:
Vår anslutning accepteras.
Vårt exempel här är lite brutalt – bara en enda dator kan ansluta. TCP-omslag är ganska mångsidigt och mer flexibelt än så här. Det stödjer värdnamn, jokertecken och undernätsmasker för att acceptera anslutningar från olika IP-adresser. Du uppmuntras att kolla in man-sidan.
Avvisa anslutningsförfrågningar utan lösenord
Även om det är en dålig praxis, kan en Linux-systemadministratör skapa ett användarkonto utan lösenord. Det betyder att fjärranslutningsförfrågningar från det kontot inte har något lösenord att kontrollera mot. Dessa anslutningar kommer att accepteras men oautentiserade.
Standardinställningarna för SSH accepterar anslutningsförfrågningar utan lösenord. Vi kan ändra det mycket enkelt och se till att alla anslutningar är autentiserade.
Vi måste redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Bläddra igenom filen tills du ser raden som lyder med ”#PermitEmptyPasswords no.” Ta bort hash # från början av raden och spara filen. Starta om SSH-demonen:
sudo systemctl restart sshd
Använd SSH-nycklar istället för lösenord
SSH-nycklar ger ett säkert sätt att logga in på en SSH-server. Lösenord kan gissas, knäckas eller brute-forced. SSH-nycklar är inte öppna för sådana typer av attacker.
När du genererar SSH-nycklar skapar du ett par nycklar. Den ena är den offentliga nyckeln och den andra är den privata nyckeln. Den publika nyckeln installeras på de servrar du vill ansluta till. Den privata nyckeln, som namnet antyder, förvaras säkert på din egen dator.
SSH-nycklar låter dig skapa anslutningar utan lösenord som är – kontraintuitivt – säkrare än anslutningar som använder lösenordsautentisering.
När du gör en anslutningsbegäran använder fjärrdatorn sin kopia av din publika nyckel för att skapa ett krypterat meddelande som skickas tillbaka till din dator. Eftersom den var krypterad med din offentliga nyckel kan din dator avkryptera den med din privata nyckel.
Din dator extraherar sedan en del information från meddelandet, särskilt sessions-ID, krypterar det och skickar tillbaka det till servern. Om servern kan dekryptera den med sin kopia av din publika nyckel, och om informationen i meddelandet matchar det som servern skickade till dig, bekräftas att din anslutning kommer från dig.
Här görs en anslutning till servern på 192.168.4.11, av en användare med SSH-nycklar. Observera att de inte uppmanas att ange ett lösenord.
ssh [email protected]
SSH-nycklar förtjänar en artikel helt för sig själva. Praktiskt, vi har en för dig. Så här skapar och installerar du SSH-nycklar.
Inaktivera lösenordsautentisering helt och hållet
Naturligtvis är den logiska förlängningen av att använda SSH-nycklar att om alla fjärranvändare tvingas adoptera dem kan du stänga av lösenordsautentisering helt.
Vi måste redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Bläddra igenom filen tills du ser raden som börjar med ”#PasswordAuthentication yes.” Ta bort hash # från början av raden, ändra ”ja” till ”nej” och spara filen. Starta om SSH-demonen:
sudo systemctl restart sshd
Inaktivera X11-vidarebefordran
Med X11-vidarebefordran kan fjärranvändare köra grafiska applikationer från din server över en SSH-session. I händerna på en hotaktör eller illvillig användare kan ett GUI-gränssnitt göra deras illvilliga syften lättare.
Ett standardmantra inom cybersäkerhet är att om du inte har en god anledning att ha den påslagen, stäng av den. Vi gör det genom att redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Bläddra igenom filen tills du ser raden som börjar med ”#X11Forwarding no.” Ta bort hash # från början av raden och spara filen. Starta om SSH-demonen:
sudo systemctl restart sshd
Ställ in ett inaktivt timeout-värde
Om det finns en etablerad SSH-anslutning till din dator, och det inte har varit någon aktivitet på den under en period, kan det utgöra en säkerhetsrisk. Det finns en chans att användaren har lämnat sitt skrivbord och är upptagen någon annanstans. Alla andra som går förbi deras skrivbord kan sätta sig ner och börja använda sin dator och, via SSH, din dator.
Det är mycket säkrare att fastställa en tidsgräns. SSH-anslutningen kommer att avbrytas om den inaktiva perioden matchar tidsgränsen. Än en gång kommer vi att redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Bläddra igenom filen tills du ser raden som börjar med ”#ClientAliveInterval 0” Ta bort hash # från början av raden, ändra siffran 0 till önskat värde. Vi har använt 300 sekunder, vilket är 5 minuter. Spara filen och starta om SSH-demonen:
sudo systemctl restart sshd
Ställ in en gräns för lösenordsförsök
Att definiera en gräns för antalet autentiseringsförsök kan hjälpa till att motverka lösenordsgissning och brute-force-attacker. Efter det angivna antalet autentiseringsbegäranden kommer användaren att kopplas bort från SSH-servern. Som standard finns det ingen gräns. Men det är snabbt åtgärdat.
Återigen måste vi redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Bläddra igenom filen tills du ser raden som börjar med ”#MaxAuthTries 0”. Ta bort hash # från början av raden, ändra siffran 0 till önskat värde. Vi har använt 3 här. Spara filen när du gjorde dina ändringar och starta om SSH-demonen:
sudo systemctl starta om sshd
Vi kan testa detta genom att försöka ansluta och avsiktligt ange ett felaktigt lösenord.
Observera att MaxAuthTries-numret verkade vara ett mer än antalet försök som användaren tilläts. Efter två dåliga försök kopplas vår testanvändare bort. Detta var med MaxAuthTries inställd på tre.
Inaktivera rotinloggningar
Det är dålig praxis att logga in som root på din Linux-dator. Du bör logga in som en normal användare och använda sudo för att utföra åtgärder som kräver root-privilegier. Ännu mer så bör du inte tillåta root att logga in på din SSH-server. Endast vanliga användare ska få ansluta. Om de behöver utföra en administrativ uppgift bör de också använda sudo. Om du tvingas tillåta en rootanvändare att logga in, kan du åtminstone tvinga dem att använda SSH-nycklar.
För sista gången kommer vi att behöva redigera din SSH-konfigurationsfil:
sudo gedit /etc/ssh/sshd_config
Bläddra igenom filen tills du ser raden som börjar med ”#PermitRootLogin prohibit-password” Ta bort hash # från början av raden.
Om du vill hindra root från att logga in alls, byt ut ”förbjud-lösenord” med ”nej”.
Om du ska tillåta root att logga in men tvinga dem att använda SSH-nycklar, lämna ”förbjud-lösenord” på plats.
Spara dina ändringar och starta om SSH-demonen:
sudo systemctl restart sshd
Det ultimata steget
Naturligtvis, om du inte behöver SSH körs på din dator alls, se till att det är inaktiverat.
sudo systemctl stop sshd
sudo systemctl disable sshd
Om du inte öppnar fönstret kan ingen klättra in.