Sikre Linux-systemets SSH-tilkobling for å beskytte systemet og dataene dine. Systemadministratorer og hjemmebrukere må herde og sikre datamaskiner som vender mot internett, men SSH kan være komplisert. Her er ti enkle hurtigvinninger for å beskytte SSH-serveren din.
Grunnleggende om SSH-sikkerhet
SSH står for Sikker skall . Navnet “SSH” brukes om hverandre for å bety enten selve SSH-protokollen eller programvareverktøyene som tillater systemadministratorer og brukere å lage sikre tilkoblinger til eksterne datamaskiner ved hjelp av denne protokollen.
SSH-protokollen er en kryptert protokoll designet for å gi en sikker forbindelse over et usikkert nettverk, for eksempel internett. SSH i Linux er bygget på en bærbar versjon av OpenSSH prosjekt. Det er implementert i en klassisk klient-servermodell , med en SSH-server som godtar tilkoblinger fra SSH-klienter. Klienten brukes til å koble til serveren og til vise økten til den eksterne brukeren. Serveren godtar tilkoblingen og utfører økten.
I sin standardkonfigurasjon vil en SSH-server lytte etter innkommende tilkoblinger på Transmission Control Protocol ( TCP ) port 22. Fordi dette er en standardisert, velkjent havn , det er et mål for trusselsaktø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. Botene 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 iverksetter 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 egentlig måtte oppgi passord hver gang de logget på hovedrammen. Det - for dem - var sikkerhetsfriksjon.
(Forøvrig krediteres oppfinnelsen av passordet Fernando J. Corbató , en annen skikkelse i panteonet til dataforskere hvis samlede 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 sin kjente praksis, eller huske et annet sett med godkjenningsdetaljer, eller legge til ekstra trinn for å koble til. Systemadministratorene vil ha ytterligere arbeid å gjøre for å implementere og vedlikeholde de nye sikkerhetstiltakene.
Å herde og låse 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 føre deg langt 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 fastsette at datamaskinen bare aksepterer tilkoblinger fra versjon 2-klienter.
For å gjøre det, rediger
/ etc / ssh / sshd_config
fil. Vi vil 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:
Protokoll 2
Og lagre filen. Vi skal starte SSH-demoneprosessen på nytt. Igjen, vi skal gjøre dette mye gjennom denne artikkelen. Dette er kommandoen som skal brukes i hvert tilfelle:
sudo systemctl start sshd på nytt
La oss sjekke at den nye innstillingen vår er i kraft. Vi hopper over til en annen maskin og prøver å SSH på testmaskinen vår. Og vi bruker
-1
(protokoll 1) alternativ for å tvinge
ssh
kommando for å bruke protokollversjon 1.
ssh -1 [email protected]
Flott, vår tilkoblingsforespørsel avvises. La oss sikre at vi fremdeles kan få kontakt med protokoll 2. Vi bruker
-2
(protokoll 2) alternativ 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 kommuniserer med serveren. Faktisk, fordi moderne SSH-klienter som standard bruker protokoll 2, trenger vi ikke å spesifisere protokoll 2 så lenge klienten er oppdatert.
ssh [email protected]
Og vår forbindelse er akseptert. Så det er bare de svakere og mindre sikre protokoll 1-tilkoblingene som blir avvist.
Unngå port 22
Port 22 er standardport for SSH-tilkoblinger. Hvis du bruker en annen port, legger det til litt sikkerhet gjennom uklarhet til systemet ditt. Sikkerhet gjennom uklarhet blir aldri ansett som et sant sikkerhetstiltak, og jeg har sporet det i andre artikler. 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 forutsatt at de tilbyr de vanlige tjenestene. Men å bruke en ikke-standard port kan bidra til å redusere støy og dårlig trafikk på port 22.
For å konfigurere en ikke-standard port, rediger SSH-konfigurasjonsfilen:
sudo gedit / etc / ssh / sshd_config
Fjern hash-nummeret fra starten av "Port" -linjen og erstatt "22" med portnummeret du velger. Lagre konfigurasjonsfilen og start SSH-demonen på nytt:
sudo systemctl start sshd på nytt
La oss se hvilken effekt det har hatt. På den andre datamaskinen vår bruker vi
ssh
kommando for å koble til serveren vår. De
ssh
kommandoen bruker standard port 22:
ssh [email protected]
Forbindelsen vår nektes. La oss prøve igjen og spesifisere port 470 ved å bruke alternativet -p (port):
ssh -p 479 [email protected]
Vår forbindelse er akseptert.
Filtrer tilkoblinger ved hjelp av TCP-pakkere
TCP Wrappers er lett å forstå tilgangskontrolliste . Den lar deg ekskludere og tillate tilkoblinger basert på egenskapene til tilkoblingsforespørselen, for eksempel IP-adresse eller vertsnavn. TCP-innpakninger skal brukes sammen med, og ikke i stedet for, en riktig konfigurert brannmur. I vårt spesifikke scenario kan vi stramme opp ting betydelig ved å bruke TCP-innpakninger.
TCP-pakkere 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 installer tcp_wrappers
For å installere på Manjaro, bruk denne kommandoen:
sudo pacman -Syu tcp-innpakninger
Det er to filer involvert. Den ene har den tillatte listen, og den andre den nektet listen. Rediger nektelisten ved å bruke:
sudo gedit /etc/hosts.deny
Dette vil åpne
gedit
redaktøren med deny-filen lastet inn.
Du må legge til linjen:
ALLE: ALLE
Og lagre filen. Dette blokkerer all tilgang som ikke er autorisert. Vi må nå godkjenne forbindelsene du ønsker å godta. For å gjøre det må du redigere tillatelsesfilen:
sudo gedit /etc/hosts.allow
Dette vil åpne
gedit
redigeringsprogram med tillatt fil lastet inn.
Vi har lagt til SSH-daemonnavnet,
SSHD
Og IP-adressen til datamaskinen vi skal tillate å opprette en forbindelse. Lagre filen, og la oss se om begrensningene og tillatelsene er i kraft.
Først skal vi prøve å koble til fra en datamaskin som ikke er i
verter. tillate
fil:
Forbindelsen nektes. Vi prøver nå å koble fra maskinen på IP-adressen 192.168.4.23:
Vår forbindelse er akseptert.
Eksemplet vårt her er litt brutalt - bare en datamaskin kan koble til. TCP-pakkere er ganske allsidige og mer fleksible enn dette. Den støtter vertsnavn, jokertegn og nettverksmasker for å godta tilkoblinger fra IP-adresser. Du oppfordres til å sjekk ut mannssiden .
Avvis tilkoblingsforespørsler uten passord
Selv om det er 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 ikke godkjent.
Standardinnstillingene for SSH godtar tilkoblingsforespørsler uten passord. Vi kan endre det veldig enkelt, og sikre at alle tilkoblinger er autentiserte.
Vi må redigere SSH-konfigurasjonsfilen din:
sudo gedit / etc / ssh / sshd_config
Bla gjennom filen til du ser linjen som heter "#PermitEmptyPasswords no." Fjern hasjen
#
fra starten av linjen og lagre filen. Start SSH-demonen på nytt:
sudo systemctl start sshd på nytt
Bruk SSH-nøkler i stedet for passord
SSH-nøkler gir et sikkert middel til å logge på en SSH-server. Passord kan gjettes, sprekke eller brutalt tvunget . 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 vil koble til. Den private nøkkelen, som navnet antyder, holdes sikker på din egen datamaskin.
SSH-nøkler lar deg opprette tilkoblinger uten passord som er - kontraintuitivt - sikrere enn tilkoblinger som bruker passordgodkjenning.
Når du ber om en tilkobling, bruker den eksterne datamaskinen sin kopi av den offentlige nøkkelen til å lage en kryptert melding som sendes tilbake til datamaskinen. Fordi den ble kryptert med den offentlige nøkkelen din, kan datamaskinen kryptere den med din private nøkkel.
Datamaskinen din henter ut litt informasjon fra meldingen, spesielt økt-ID, krypterer den og sender den tilbake til serveren. Hvis serveren kan dekryptere den med kopien av den offentlige nøkkelen din, og hvis informasjonen i meldingen samsvarer med det serveren sendte deg, er det bekreftet at forbindelsen kommer fra deg.
Her blir det koblet til serveren 192.168.4.11 av en bruker med SSH-nøkler. Vær oppmerksom på at de ikke blir bedt om å oppgi passord.
ssh [email protected]
SSH-nøkler fortjener en artikkel for seg selv. Vi har en for deg. Her er hvordan du oppretter og installerer SSH-nøkler .
I SLEKT: Hvordan lage og installere SSH-nøkler fra Linux-skallet
Deaktiver passordgodkjenning helt
Den logiske utvidelsen av å bruke SSH-nøkler er selvfølgelig at hvis alle eksterne brukere blir tvunget til å vedta dem, kan du slå av passordgodkjenning helt.
Vi må redigere SSH-konfigurasjonsfilen din:
sudo gedit / etc / ssh / sshd_config
Bla gjennom filen til du ser linjen som begynner med "#PasswordAuthentication yes." Fjern hasjen
#
fra begynnelsen av linjen, endre “ja” til “nei”, og lagre filen. Start SSH-demonen på nytt:
sudo systemctl start sshd på nytt
Deaktiver videresending av X11
X11-videresending lar eksterne brukere kjøre grafiske applikasjoner fra serveren din over en SSH-økt. I hendene på en trusselsaktør eller ondsinnet bruker, kan et GUI-grensesnitt gjøre deres ondartede formål lettere.
Et standardmantra innen cybersikkerhet er at hvis du ikke har en god grunn til å slå den på, slå den av. Vi gjør det ved å redigere SSH-konfigurasjonsfilen:
sudo gedit / etc / ssh / sshd_config
Bla gjennom filen til du ser linjen som begynner med "# X11Videresendingsnr." Fjern hasjen
#
fra starten av linjen og lagre filen. Start SSH-demonen på nytt:
sudo systemctl start sshd på nytt
Angi en inaktiv tidsavbruddsverdi
Hvis det er en etablert SSH-forbindelse til datamaskinen din, og det ikke har vært noen aktivitet på den i en periode, kan det utgjøre en sikkerhetsrisiko. Det er en sjanse for at brukeren har forlatt skrivebordet og er opptatt andre steder. Alle andre som går forbi skrivebordet sitt, kan sette seg ned og begynne å bruke datamaskinen og via SSH datamaskinen din.
Det er mye tryggere å etablere en tidsavbruddsgrense. SSH-forbindelsen blir avbrutt hvis den inaktive perioden samsvarer med tidsfristen. Nok en gang redigerer vi SSH-konfigurasjonsfilen din:
sudo gedit / etc / ssh / sshd_config
Bla gjennom filen til du ser linjen som begynner med "#ClientAliveInterval 0" Fjern hasjen
#
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 start sshd på nytt
Sett en grense for passordforsøk
Å definere en grense for antall godkjenningsforsøk kan bidra til å hindre passordgissing og brutale kraftangrep. Etter det angitte antallet godkjenningsforespørsler, blir brukeren koblet fra SSH-serveren. Som standard er det ingen grense. Men det løses raskt.
Igjen, vi må redigere SSH-konfigurasjonsfilen din:
sudo gedit / etc / ssh / sshd_config
Bla gjennom filen til du ser linjen som begynner med "#MaxAuthTries 0". Fjern hasjen
#
fra begynnelsen av linjen, endre tallet 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 bevisst skrive inn feil passord.
Merk at MaxAuthTries-nummeret så ut til å være ett mer enn antall prøver brukeren fikk tillatelse. Etter to dårlige forsøk kobles testbrukeren vår fra. Dette var med MaxAuthTries satt til tre.
Deaktiver Root Log Ins
Det er dårlig praksis å logge på som root på Linux-datamaskinen din. Du bør logge på som en vanlig bruker og bruke
sudo
for å utføre handlinger som krever rotprivilegier. Enda mer, du bør ikke tillate root å logge på SSH-serveren din. Bare vanlige brukere skal ha lov til å koble til. Hvis de trenger å utføre en administrativ oppgave, bør de bruke
sudo
også. Hvis du blir tvunget til å tillate en rotbruker å 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 begynner med "#PermitRootLogin prohibit-password" Fjern hash
#
fra starten av linjen.
- Hvis du i det hele tatt vil forhindre at root logger inn, erstatter du "prohibit-password" med "no".
- Hvis du skal tillate root å logge på, men tvinge dem til å bruke SSH-nøkler, må du la "prohibit-password" være på plass.
Lagre endringene og start SSH-demonen på nytt:
sudo systemctl start sshd på nytt
Det ultimate trinnet
Hvis du ikke trenger SSH på datamaskinen din i det hele tatt, må du selvfølgelig sørge for at den er deaktivert.
sudo systemctl stopp sshd
sudo systemctl deaktivere sshd
Hvis du ikke åpner vinduet, kan ingen klatre inn.
