Sikre Linux-systemets SSH-tilkobling for å beskytte systemet og dataene dine. Både systemadministratorer og hjemmebrukere trenger å herde og sikre datamaskiner som vender mot Internett, men SSH kan være komplisert. Her er ti enkle raske gevinster for å beskytte SSH-serveren din.
Innholdsfortegnelse
Grunnleggende om SSH-sikkerhet
SSH står for Sikkert skall. Navnet «SSH» brukes om hverandre for å bety enten selve SSH-protokollen eller 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 en sikker tilkobling over et usikkert nettverk, for eksempel internett. SSH i Linux er bygget på en bærbar versjon av OpenSSH prosjekt. Den er implementert i en klassisk klient-server-modell, med en SSH-server som aksepterer tilkoblinger fra SSH-klienter. Klienten brukes til å koble til serveren og vise økten til den eksterne brukeren. Serveren godtar tilkoblingen og utfører økten.
I standardkonfigurasjonen vil en SSH-server lytte etter innkommende tilkoblinger på Transmission Control Protocol (TCP) port 22. Fordi dette er en standardisert, velkjent havner det et mål for trusselaktører og ondsinnede roboter.
Trusselaktører lanserer roboter som skanner en rekke IP-adresser på jakt etter åpne porter. Portene blir deretter undersøkt for å se om det er sårbarheter som kan utnyttes. Å tenke: «Jeg er trygg, det er større og bedre mål enn meg for de slemme gutta å sikte på», er falsk resonnement. Robotene velger ikke mål basert på noen fortjeneste; de leter metodisk etter systemer de kan bryte.
Du nominerer deg selv som et offer hvis du ikke har sikret systemet ditt.
Sikkerhetsfriksjon
Sikkerhetsfriksjon er irritasjonen – uansett grad – som brukere og andre vil oppleve når du implementerer sikkerhetstiltak. Vi har lange minner og kan huske at vi introduserte nye brukere til et datasystem, og hørte dem spørre med en forferdet stemme om de virkelig måtte skrive inn et passord hver gang de logget på stormaskinen. Det – for dem – var sikkerhetsfriksjon.
(Forresten krediteres oppfinnelsen av passordet Fernando J. Corbatóen annen figur i pantheonet av informatikere hvis kombinerte arbeid bidro til omstendighetene som førte til fødselen av Unix.)
Å innføre sikkerhetstiltak innebærer vanligvis en eller annen form for friksjon for noen. Bedriftseiere må betale for det. Databrukerne må kanskje endre sine vante praksiser, eller huske et annet sett med autentiseringsdetaljer, eller legge til ekstra trinn for å koble til. Systemadministratorene vil ha ekstra arbeid å gjøre for å implementere og vedlikeholde de nye sikkerhetstiltakene.
Å herde og låse ned et Linux- eller Unix-lignende operativsystem kan bli veldig involvert, veldig raskt. Det vi presenterer her er et sett med enkle å implementere trinn som vil forbedre sikkerheten til datamaskinen din uten behov for tredjepartsapplikasjoner og uten å grave gjennom brannmuren.
Disse trinnene er ikke det siste ordet i SSH-sikkerhet, men de vil flytte deg et godt stykke frem fra standardinnstillingene, og uten for mye friksjon.
Bruk SSH Protocol versjon 2
I 2006 ble SSH-protokollen oppdatert fra versjon 1 til versjon 2. Det var en betydelig oppgradering. Det var så mange endringer og forbedringer, spesielt rundt kryptering og sikkerhet, at versjon 2 ikke er bakoverkompatibel med versjon 1. For å forhindre tilkoblinger fra versjon 1-klienter, kan du bestemme at datamaskinen din kun godtar tilkoblinger fra versjon 2-klienter.
For å gjøre det, rediger filen /etc/ssh/sshd_config. Vi kommer til å gjøre dette mye gjennom denne artikkelen. Når du trenger å redigere denne filen, er dette kommandoen du skal bruke:
sudo gedit /etc/ssh/sshd_config
Legg til linjen:
Protocol 2
Og lagre filen. Vi skal starte SSH-demonprosessen på nytt. Igjen, vi kommer til å gjøre dette mye gjennom denne artikkelen. Dette er kommandoen som skal brukes i hvert tilfelle:
sudo systemctl restart sshd
La oss sjekke at vår nye innstilling er i kraft. Vi hopper over til en annen maskin og prøver å SSH på testmaskinen vår. Og vi bruker alternativet -1 (protokoll 1) for å tvinge ssh-kommandoen til å bruke protokollversjon 1.
ssh -1 [email protected]
Flott, forespørselen vår om tilkobling er avvist. La oss sørge for at vi fortsatt kan koble til protokoll 2. Vi bruker alternativet -2 (protokoll 2) for å bevise faktum.
ssh -2 [email protected]
Det faktum at SSH-serveren ber om passordet vårt er en positiv indikasjon på at tilkoblingen er opprettet og at du samhandler med serveren. Faktisk, 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 vår forbindelse er akseptert. Så det er kun de svakere og mindre sikre protokoll 1-forbindelsene som blir avvist.
Unngå port 22
Port 22 er standardporten for SSH-tilkoblinger. Hvis du bruker en annen port, gir det litt sikkerhet gjennom uklarhet til systemet ditt. Sikkerhet gjennom uklarhet regnes aldri som et ekte sikkerhetstiltak, og jeg har i andre artikler uttalt meg mot det. Faktisk undersøker noen av de smartere angrepsrobotene alle åpne porter og bestemmer hvilken tjeneste de har, i stedet for å stole på en enkel oppslagsliste over porter og antar at de tilbyr de vanlige tjenestene. Men å bruke en ikke-standard port kan hjelpe med å redusere støyen og dårlig trafikk på port 22.
For å konfigurere en ikke-standard port, rediger SSH-konfigurasjonsfilen:
sudo gedit /etc/ssh/sshd_config
Fjern hash # fra starten av «Port»-linjen og erstatt «22» med 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 datamaskinen vår bruker vi ssh-kommandoen for å koble til serveren vår. ssh-kommandoen bruker som standard port 22:
ssh [email protected]
Vår forbindelse er avvist. La oss prøve igjen og spesifisere port 470 ved å bruke -p (port)-alternativet:
ssh -p 479 [email protected]
Vår tilkobling er akseptert.
Filtertilkoblinger ved hjelp av TCP-innpakninger
TCP Wrappers er en enkel å forstå tilgangskontrollliste. 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 riktig konfigurert brannmur. I vårt spesifikke scenario kan vi stramme opp betraktelig ved å bruke TCP-innpakninger.
TCP-innpakninger var allerede installert på Ubuntu 18.04 LTS-maskinen som ble brukt til å undersøke denne artikkelen. Den 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 den tillatte listen, og den andre har den avslåtte listen. Rediger avvisningslisten ved å bruke:
sudo gedit /etc/hosts.deny
Dette vil åpne gedit-editoren med deny-filen lastet inn i den.
Du må legge til linjen:
ALL : ALL
Og lagre filen. Det blokkerer all tilgang som ikke er autorisert. Vi må nå godkjenne tilkoblingene du ønsker å godta. For å gjøre det, må du redigere tillatelsesfilen:
sudo gedit /etc/hosts.allow
Dette vil åpne gedit-editoren med tillat-filen lastet inn.
Vi har lagt til SSH-demonnavnet, SSHD, og IP-adressen til datamaskinen vi skal 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 på IP-adressen 192.168.4.23:
Vår tilkobling er akseptert.
Eksempelet vårt her er litt brutalt – bare en enkelt datamaskin kan koble til. TCP-innpakninger er ganske allsidige og mer fleksible enn dette. Det støtter vertsnavn, jokertegn og nettverksmasker for å godta tilkoblinger fra områder med IP-adresser. Du oppfordres til sjekk 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 å sjekke mot. Disse forbindelsene vil bli akseptert, men uautentisert.
Standardinnstillingene for SSH godtar tilkoblingsforespørsler uten passord. Vi kan endre det veldig enkelt, og sørge for at alle tilkoblinger er autentisert.
Vi må redigere SSH-konfigurasjonsfilen din:
sudo gedit /etc/ssh/sshd_config
Bla gjennom filen til du ser linjen som lyder med «#PermitEmptyPasswords no.» Fjern hash # 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 brute-forced. SSH-nøkler er ikke åpne 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 er installert på serverne du ønsker å koble til. Den private nøkkelen, som navnet antyder, oppbevares sikkert på din egen datamaskin.
SSH-nøkler lar deg opprette tilkoblinger uten passord som er – kontraintuitivt – 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 datamaskinen din. Fordi den ble kryptert med din offentlige nøkkel, kan datamaskinen din dekryptere den med din private nøkkel.
Datamaskinen din trekker deretter ut noe 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, bekreftes det at tilkoblingen din kommer fra deg.
Her opprettes en tilkobling til serveren på 192.168.4.11, av en bruker med SSH-nøkler. Merk at de ikke blir bedt om passord.
ssh [email protected]
SSH-nøkler fortjener en artikkel for seg selv. Praktisk, vi har en til deg. Her er hvordan du oppretter og installerer SSH-nøkler.
Deaktiver passordautentisering helt
Selvfølgelig er den logiske utvidelsen av å bruke SSH-nøkler at hvis alle eksterne brukere blir tvunget til å adoptere dem, kan du slå av passordautentisering helt.
Vi må redigere SSH-konfigurasjonsfilen din:
sudo gedit /etc/ssh/sshd_config
Rull gjennom filen til du ser linjen som starter med «#PasswordAuthentication yes.» Fjern hash # fra begynnelsen av linjen, endre «ja» til «nei», 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 standard mantra innen cybersikkerhet er at hvis du ikke har en god grunn til å ha den slått på, slå den av. Vi gjør det ved å redigere SSH-konfigurasjonsfilen din:
sudo gedit /etc/ssh/sshd_config
Bla gjennom filen til du ser linjen som starter med «#X11Forwarding no.» Fjern hash # fra begynnelsen av linjen og lagre filen. Start SSH-demonen på nytt:
sudo systemctl restart sshd
Angi en tidsavbruddsverdi for inaktivitet
Hvis det er en etablert SSH-tilkobling til datamaskinen din, og det ikke har vært aktivitet på den på en periode, kan det utgjøre en sikkerhetsrisiko. Det er en sjanse for at brukeren har forlatt skrivebordet sitt og er opptatt andre steder. Alle andre som går forbi skrivebordet deres kan sette seg ned og begynne å bruke datamaskinen sin og, via SSH, datamaskinen din.
Det er mye tryggere å etablere en tidsavbruddsgrense. SSH-tilkoblingen vil bli avbrutt hvis den inaktive perioden samsvarer med tidsbegrensningen. Nok en gang vil vi redigere SSH-konfigurasjonsfilen din:
sudo gedit /etc/ssh/sshd_config
Rull gjennom filen til du ser linjen som starter med «#ClientAliveInterval 0» Fjern hash # fra starten av linjen, endre sifferet 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 å hindre passordgjetting og brute-force-angrep. Etter det angitte antallet autentiseringsforespørsler, vil brukeren bli koblet fra SSH-serveren. Som standard er det ingen grense. Men det blir raskt rettet opp.
Igjen, vi må redigere SSH-konfigurasjonsfilen din:
sudo gedit /etc/ssh/sshd_config
Bla gjennom filen til du ser linjen som starter med «#MaxAuthTries 0». Fjern hash # fra starten av linjen, endre sifferet 0 til ønsket verdi. Vi har brukt 3 her. Lagre filen når du gjorde 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.
Merk at MaxAuthTries-nummeret så ut til å være én mer enn antallet forsøk brukeren fikk lov til. Etter to dårlige forsøk blir testbrukeren vår frakoblet. Dette var med MaxAuthTries satt til tre.
Deaktiver rotpålogginger
Det er dårlig praksis å logge på som root på din Linux-datamaskin. Du bør logge på som en vanlig bruker og bruke sudo til å utføre handlinger som krever root-privilegier. Enda mer bør du ikke la root logge på SSH-serveren din. Bare vanlige brukere skal få lov til å koble til. Hvis de trenger å utføre en administrativ oppgave, bør de også bruke sudo. Hvis du blir 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 din:
sudo gedit /etc/ssh/sshd_config
Bla gjennom filen til du ser linjen som starter med «#PermitRootLogin prohibit-password» Fjern hash # fra starten av linjen.
Hvis du vil forhindre at root logger på i det hele tatt, bytt ut «forby-passord» med «nei».
Hvis du skal tillate root å logge på, men tvinge dem til å bruke SSH-nøkler, la «forby-passord» være på plass.
Lagre endringene og start SSH-demonen på nytt:
sudo systemctl restart sshd
Det ultimate trinnet
Selvfølgelig, hvis du ikke trenger SSH kjører 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.