SSH (Secure Shell) er en nettverksprotokoll som er mye brukt for å oppnå fjerntilgang til blant annet Linux- og Unix-maskiner. I utgangspunktet tilbyr den kryptert tilgang til et kommandolinjegrensesnitt og ble opprinnelig designet for å være et sikkert alternativ til telnet, men den støtter også «tunneling», hvor SSH fungerer som en kryptert kanal for overføring av ikke-krypterte datastrømmer over et nettverk.
SSH i seg selv er relativt sikkert, selv om det har blitt funnet en del alvorlige sårbarheter i blant annet OpenSSH, som anses for å være den mest utbredte implementasjonen av SSH.
Likevel angripes de fleste maskiner som tilbyr SSH via Internett stadige angrep, stort sett fra infiserte maskiner. Årsaken til dette er at mange ikke har sikret SSH-oppsettet på maskinen godt nok.
Daniel Wesemann ved SANS' Internet Storm Center skriver i dette blogginnlegget at data fra brannmurlogger som DShield samler inn globalt, viser at fortsatt pågår massive angrep mot SSH hvor det forsøkes å gjette kombinasjoner av brukernavn og passord.
- Dersom du har en SSH-server åpen mot Internett og ditt brukernavn og passord ikke er minst åtte tegn lange, er boksen din nå invadert eller i ferd med å ble det, skriver Wesemann.
I tillegg til gode brukernavn og passord, finnes det en rekke tiltak man som SSH-administrator kan gjøre for å gjøre det vanskeligere eller umulig for angriperne å utføre disse angrepene.
Linux-distributøren CentOS har utarbeidet denne listen over forholdsvis enkle tiltak.
Blant annet er det viktig å begrense skaden som kan gjøres dersom uvedkommende greier logge seg på maskinen via SSH. Det ene er å forby direkte root-tilgang via SSH. Det betyr at alle innlogginger via SSH må skje via en annen brukerkonto enn root, typisk en konto med begrensede privilegier. Fra denne kontoen kan man alltids starte prosesser ved hjelp av sudo eller ved å bruke su-kommandoen. I listen fra CentOS er det beskrevet hvordan man forbyr root-innlogging via SSH.
Dersom ikke alle brukerne av maskinen må kunne logge seg på via SSH, kan man lage en liste over de enkeltbrukerne som tillates tilgang. Da vil ingen andre brukernavn kunne benyttes. Listen skrives inn i konfigurasjonsfilen for SSH-tjenesten, typisk sshd_config.
Et viktig tiltak er kun å tillate versjon 2 av SSH-protokollen. Versjon 1 har visse iboende designfeil som gjør den sårbar. Derfor bør den ikke brukes. Også dette gjøres i konfigurasjonsfilen til SSH-tjenesten.
SSH lytter vanligvis til port 22, og de fleste angrep forsøker derfor å oppnå tilgang til nettopp denne porten. Ved å bytte til et ubrukt portnummer langt oppe i rekken, gjør man det vanskeligere for en angriper å kontakte SSH-tjenesten på maskinen. Brukerne som skal tillates tilgang til maskinen, må selvfølgelig få vite hvilken port som benyttes, slik at de kan oppgi dette ved innloggingen.
Dersom tilgangen til maskinen med SSH-serveren kan begrenses til et mindre antall IP-adresser, bør man legge inn et filter i brannmuren man benytter, slik at bare de oppgitte IP-adressene får tilgang til den porten som SSH-tjenesten lytter til.
Det siste tiltaket CentOS nevner, er å bruke offentlige og private nøkkelpar i stedet for eller i tillegg til passord. Med dette vil kun klientmaskiner hvor det har blitt tildelt et nøkkelpar, kunne brukes for å logge inn på serveren.
CentOS har oppgitt detaljer om hvordan dette kan gjøres på maskin med nettopp CentOS som operativsystem, men det meste kan gjøres på omtrent samme måten også på andre systemer.
I tillegg til dette anbefaler Wesemann SSH-administratorer om at det benyttes brukernavn som er vanskelige å gjette. Gjerne brukernavn som inneholder tall eller spesialtegn. Han anbefaler også at man skanner nettverket for å finne ut hvilke maskiner og andre enheter som faktisk tilbyr SSH-tjenester. Det er ikke sikkerhet at man vet om alle.
Et verktøy som Fail2ban tilbyr en automatisert prosess som sperrer IP-adresser ute dersom de har ført til for mange passordfeil.
Dessuten bør man følge med på loggene for å se om det dukker opp uvanlige oppføringer.
