Sikre din SSH-server: 10 enkle tips for bedre sikkerhet

Forbedre sikkerheten til din Linux SSH-tilkobling for å beskytte systemet og dine data. Systemadministratorer og hjemmebrukere trenger å sikre datamaskiner som er eksponert for internett. SSH kan være komplekst. Her er ti enkle tiltak for å forbedre sikkerheten til din SSH-server.

Grunnleggende om SSH-sikkerhet

SSH står for Secure Shell. Navnet «SSH» brukes både om selve SSH-protokollen og om programvareverktøyene som lar systemadministratorer og brukere opprette sikre tilkoblinger til eksterne datamaskiner som bruker denne protokollen.

SSH-protokollen er en kryptert protokoll designet for å gi sikker kommunikasjon over et usikkert nettverk, som internett. SSH i Linux er basert på en portabel versjon av OpenSSH prosjektet. Den er implementert i en klassisk klient-server modell, der en SSH-server aksepterer tilkoblinger fra SSH-klienter. Klienten brukes til å koble til serveren og vise økten for den eksterne brukeren. Serveren godtar tilkoblingen og utfører økten.

Som standard lytter en SSH-server etter innkommende tilkoblinger på TCP (Transmission Control Protocol) port 22. Fordi dette er en standardisert og velkjent port, er den et mål for trusselaktører og ondsinnede roboter.

Trusselaktører bruker roboter som skanner et stort antall IP-adresser på jakt etter åpne porter. Disse portene undersøkes for å se om det finnes sårbarheter som kan utnyttes. Å tenke at «jeg er trygg, det finnes større mål for de slemme gutta å sikte seg inn på,» er en feilaktig antakelse. Robotene velger ikke mål basert på noen fortjeneste; de leter systematisk etter systemer de kan trenge seg inn i.

Du gjør deg selv til et lett offer dersom du ikke har sikret systemet ditt.

Sikkerhetsfriksjon

Sikkerhetsfriksjon refererer til irritasjonen – uansett omfang – som brukere og andre vil oppleve når sikkerhetstiltak implementeres. Mange husker introduksjonen av nye brukere til et datasystem, der de med et sukk spurte om de virkelig måtte skrive inn et passord hver gang de logget på datamaskinen. Dette var, for dem, sikkerhetsfriksjon.

(Forresten, oppfinnelsen av passordet er kreditert Fernando J. Corbató, en annen viktig figur i informatikernes verden, hvis kombinerte arbeid bidro til forholdene som førte til fødselen av Unix.)

Å implementere sikkerhetstiltak innebærer vanligvis en eller annen form for friksjon for noen. Bedriftseiere må betale for det. Databrukere må kanskje endre sine vanlige rutiner, huske et annet sett med autentiseringsdetaljer, eller legge til ekstra trinn for å koble til. Systemadministratorer vil ha ekstra arbeid med å implementere og vedlikeholde de nye sikkerhetstiltakene.

Å sikre et Linux- eller Unix-lignende operativsystem kan raskt bli svært komplisert. Det vi presenterer her er et sett med enkle trinn som kan forbedre sikkerheten til datamaskinen din uten bruk av tredjepartsapplikasjoner eller endringer i brannmuren.

Disse trinnene er ikke den ultimate løsningen for SSH-sikkerhet, men de vil flytte deg et godt stykke unna standardinnstillingene, uten å skape for mye ekstraarbeid.

Bruk SSH protokoll versjon 2

I 2006 ble SSH-protokollen oppdatert fra versjon 1 til versjon 2. Dette var en stor oppgradering. Det var så mange endringer og forbedringer, spesielt rundt kryptering og sikkerhet, at versjon 2 ikke er bakoverkompatibel med versjon 1. For å hindre tilkoblinger fra versjon 1-klienter, kan du konfigurere datamaskinen din til kun å akseptere tilkoblinger fra versjon 2-klienter.

For å gjøre dette, rediger filen /etc/ssh/sshd_config. Vi kommer til å gjøre dette flere ganger i denne artikkelen. Når du trenger å redigere denne filen, bruk denne kommandoen:

sudo gedit /etc/ssh/sshd_config

Legg til denne linjen:

Protocol 2

Lagre filen. Vi må starte SSH-demonen på nytt. Igjen, vi kommer til å gjøre dette flere ganger i denne artikkelen. Dette er kommandoen som skal brukes hver gang:

sudo systemctl restart sshd

La oss sjekke at den nye innstillingen er aktiv. Vi går til en annen maskin og prøver å koble oss til testmaskinen vår med SSH. Vi bruker alternativet -1 (protokoll 1) for å tvinge ssh-kommandoen til å bruke protokollversjon 1.

ssh -1 [email protected]

Flott, forespørselen om tilkobling ble avvist. La oss sjekke at vi fortsatt kan koble til med protokoll 2. Vi bruker alternativet -2 (protokoll 2) for å bekrefte dette.

ssh -2 [email protected]

At SSH-serveren ber om passordet er et tegn på at tilkoblingen er opprettet og at du samhandler med serveren. Fordi moderne SSH-klienter vil bruke protokoll 2 som standard, trenger vi ikke å spesifisere protokoll 2 så lenge klienten vår er oppdatert.

ssh [email protected]

Og tilkoblingen vår er akseptert. Kun de svakere og mindre sikre protokoll 1-tilkoblingene blir avvist.

Unngå port 22

Port 22 er standardporten for SSH-tilkoblinger. Å bruke en annen port gir litt ekstra sikkerhet gjennom uklarhet. Sikkerhet gjennom uklarhet regnes ikke som et reelt sikkerhetstiltak. Noen av de mer avanserte angrepsrobotene undersøker alle åpne porter og identifiserer tjenesten som er tilgjengelig der, i stedet for å anta at de vanlige tjenestene kjører på de vanlige portene. Å bruke en ikke-standard port kan redusere støy og uønsket trafikk på port 22.

For å konfigurere en ikke-standard port, rediger SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Fjern hash-tegnet # fra starten av «Port»-linjen og bytt ut «22» med det portnummeret du ønsker. Lagre konfigurasjonsfilen og start SSH-demonen på nytt:

sudo systemctl restart sshd

La oss se hvilken effekt det har hatt. På den andre maskinen vår bruker vi ssh-kommandoen for å koble til serveren vår. ssh-kommandoen bruker som standard port 22:

ssh [email protected]

Tilkoblingen vår ble avvist. La oss prøve igjen og spesifisere port 479 ved å bruke -p (port)-alternativet:

ssh -p 479 [email protected]

Tilkoblingen vår ble akseptert.

Filtrer tilkoblinger ved hjelp av TCP-innpakninger

TCP Wrappers er en lettfattelig tilgangskontrolliste. Den lar deg ekskludere og tillate tilkoblinger basert på egenskapene til tilkoblingsforespørselen, for eksempel IP-adresse eller vertsnavn. TCP-innpakninger bør brukes sammen med, og ikke i stedet for, en korrekt konfigurert brannmur. I dette scenarioet kan vi stramme opp sikkerheten ved å bruke TCP-innpakninger.

TCP-innpakninger var allerede installert på Ubuntu 18.04 LTS-maskinen som ble brukt til denne artikkelen. Det måtte installeres på Manjaro 18.10 og Fedora 30.

For å installere på Fedora, bruk denne kommandoen:

sudo yum install tcp_wrappers

For å installere på Manjaro, bruk denne kommandoen:

sudo pacman -Syu tcp-wrappers

Det er to filer involvert. Den ene har listen over tillatte tilkoblinger, og den andre har listen over avviste tilkoblinger. Rediger avvisningslisten ved å bruke:

sudo gedit /etc/hosts.deny

Dette åpner gedit-editoren med deny-filen.

Legg til denne linjen:

ALL : ALL

Og lagre filen. Dette blokkerer all tilgang som ikke er autorisert. Vi må nå godkjenne tilkoblingene du ønsker å akseptere. For å gjøre det, rediger filen for tillatte tilkoblinger:

sudo gedit /etc/hosts.allow

Dette åpner gedit-editoren med allow-filen.

Vi har lagt til SSH-demonens navn, SSHD, og IP-adressen til datamaskinen vi ønsker å tillate å opprette en tilkobling. Lagre filen, og la oss se om begrensningene og tillatelsene er i kraft.

Først prøver vi å koble til fra en datamaskin som ikke er i hosts.allow-filen:

Tilkoblingen er avvist. Vi prøver nå å koble til fra maskinen med IP-adressen 192.168.4.23:

Tilkoblingen vår ble akseptert.

Eksemplet vårt her er litt brutalt – kun én enkelt datamaskin kan koble til. TCP-innpakninger er allsidige og mer fleksible enn dette. Det støtter vertsnavn, jokertegn og nettverksmasker for å tillate tilkoblinger fra ulike IP-adresseområder. Du bør sjekke ut man-siden.

Avvis tilkoblingsforespørsler uten passord

Selv om det er en dårlig praksis, kan en Linux-systemadministrator opprette en brukerkonto uten passord. Det betyr at forespørsler om ekstern tilkobling fra den kontoen ikke har noe passord å validere. Disse tilkoblingene vil bli akseptert, men uten autentisering.

Standardinnstillingene for SSH aksepterer tilkoblingsforespørsler uten passord. Vi kan endre det og sørge for at alle tilkoblinger blir autentisert.

Vi må redigere SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Rull gjennom filen til du finner linjen som lyder med «#PermitEmptyPasswords no.» Fjern hash-tegnet # fra begynnelsen av linjen og lagre filen. Start SSH-demonen på nytt:

sudo systemctl restart sshd

Bruk SSH-nøkler i stedet for passord

SSH-nøkler gir en sikker måte å logge på en SSH-server. Passord kan gjettes, knekkes eller angripes med brute-force. SSH-nøkler er ikke like utsatt for slike typer angrep.

Når du genererer SSH-nøkler, oppretter du et par nøkler. Den ene er den offentlige nøkkelen, og den andre er den private nøkkelen. Den offentlige nøkkelen installeres på serverne du ønsker å koble til. Den private nøkkelen, som navnet antyder, oppbevares trygt på din egen datamaskin.

SSH-nøkler lar deg opprette tilkoblinger uten passord som er – motintuitivt nok – sikrere enn tilkoblinger som bruker passordautentisering.

Når du sender en tilkoblingsforespørsel, bruker den eksterne datamaskinen sin kopi av den offentlige nøkkelen til å lage en kryptert melding som sendes tilbake til din datamaskin. Fordi den ble kryptert med din offentlige nøkkel, kan din datamaskin dekryptere den med din private nøkkel.

Datamaskinen din trekker deretter ut informasjon fra meldingen, spesielt sesjons-IDen, krypterer den og sender den tilbake til serveren. Hvis serveren kan dekryptere den med sin kopi av din offentlige nøkkel, og hvis informasjonen i meldingen samsvarer med det serveren sendte til deg, er det bekreftet at tilkoblingen kommer fra deg.

Her opprettes en tilkobling til serveren på 192.168.4.11, av en bruker med SSH-nøkler. Legg merke til at de ikke blir spurt om passord.

ssh [email protected]

SSH-nøkler fortjener en egen artikkel. Heldigvis har vi en for deg. Her er hvordan du oppretter og installerer SSH-nøkler.

Deaktiver passordautentisering helt

Den logiske konsekvensen av å bruke SSH-nøkler er at hvis alle eksterne brukere må bruke dem, kan du slå av passordautentisering helt.

Vi må redigere SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Rull gjennom filen til du finner linjen som begynner med «#PasswordAuthentication yes.» Fjern hash-tegnet # fra begynnelsen av linjen, endre «yes» til «no», og lagre filen. Start SSH-demonen på nytt:

sudo systemctl restart sshd

Deaktiver X11-videresending

X11-videresending lar eksterne brukere kjøre grafiske applikasjoner fra serveren din over en SSH-økt. I hendene på en trusselaktør eller ondsinnet bruker, kan et GUI-grensesnitt gjøre deres ondsinnede formål enklere.

Et standardmantra innen cybersikkerhet er at hvis du ikke har en god grunn til å ha den på, bør du slå den av. Vi gjør det ved å redigere SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Rull gjennom filen til du finner linjen som begynner med «#X11Forwarding no.» Fjern hash-tegnet # fra begynnelsen av linjen og lagre filen. Start SSH-demonen på nytt:

sudo systemctl restart sshd

Angi en tidsavbruddsverdi for inaktivitet

Hvis en SSH-tilkobling til datamaskinen din er opprettet, og det ikke har vært aktivitet i en periode, kan det utgjøre en sikkerhetsrisiko. Det er en mulighet for at brukeren har forlatt skrivebordet sitt og er opptatt med andre ting. Alle andre som går forbi skrivebordet kan sette seg ned og begynne å bruke datamaskinen, og dermed også datamaskinen din, via SSH.

Det er tryggere å angi en tidsavbruddsgrense. SSH-tilkoblingen vil bli brutt hvis den inaktive perioden overskrider tidsbegrensningen. Vi må igjen redigere SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Rull gjennom filen til du finner linjen som begynner med «#ClientAliveInterval 0». Fjern hash-tegnet # fra begynnelsen av linjen, endre tallet 0 til ønsket verdi. Vi har brukt 300 sekunder, som er 5 minutter. Lagre filen, og start SSH-demonen på nytt:

sudo systemctl restart sshd

Angi en grense for passordforsøk

Å definere en grense for antall autentiseringsforsøk kan bidra til å forhindre passordgjetting og brute-force-angrep. Etter et bestemt antall autentiseringsforespørsler vil brukeren bli koblet fra SSH-serveren. Som standard er det ingen grense, men dette kan raskt fikses.

Igjen, vi må redigere SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Rull gjennom filen til du ser linjen som begynner med «#MaxAuthTries 0». Fjern hash-tegnet # fra begynnelsen av linjen, og endre tallet 0 til ønsket verdi. Vi har brukt 3 her. Lagre filen når du har gjort endringene, og start SSH-demonen på nytt:

sudo systemctl start sshd på nytt

Vi kan teste dette ved å prøve å koble til og med vilje skrive inn feil passord.

Legg merke til at MaxAuthTries-nummeret ser ut til å være én mer enn antallet forsøk brukeren får lov til. Etter to mislykkede forsøk blir testbrukeren vår koblet fra. Dette var med MaxAuthTries satt til tre.

Deaktiver root-pålogginger

Det er en dårlig praksis å logge på som root på din Linux-datamaskin. Du bør logge på som en vanlig bruker og bruke sudo for å utføre handlinger som krever root-rettigheter. Du bør heller ikke tillate at root logger på SSH-serveren. Kun vanlige brukere skal ha tillatelse til å koble til. Hvis de trenger å utføre administrative oppgaver, bør de også bruke sudo. Hvis du er tvunget til å tillate en root-bruker å logge på, kan du i det minste tvinge dem til å bruke SSH-nøkler.

For siste gang må vi redigere SSH-konfigurasjonsfilen:

sudo gedit /etc/ssh/sshd_config

Rull gjennom filen til du ser linjen som begynner med «#PermitRootLogin prohibit-password». Fjern hash-tegnet # fra begynnelsen av linjen.

Hvis du vil hindre root i å logge på i det hele tatt, endre «prohibit-password» til «no».
Hvis du skal tillate root å logge på, men tvinge dem til å bruke SSH-nøkler, la «prohibit-password» stå som det er.

Lagre endringene og start SSH-demonen på nytt:

sudo systemctl restart sshd

Det ultimate trinnet

Hvis du ikke trenger SSH kjørende på datamaskinen i det hele tatt, sørg for at den er deaktivert.

sudo systemctl stop sshd
sudo systemctl disable sshd

Hvis du ikke åpner vinduet, kan ingen klatre inn.