Ssh beveiliging

Door 4ourty2 op vrijdag 10 oktober 2008 21:15 - Reacties (22)
Categorie: -, Views: 5.900

Ik loop nu al een paar jaar rond met het idee om linux eens echt te gaan gebruiken en recentelijk ben ik daar mee begonnen. Ik was al eens eerder begonnen maar ik had toen toch meer zin om te gamen :'). Dit blog gaat over de ervaringen die ik ermee opdoe, de problemen die ik tegenkom met natuurlijk de bijbehorende oplossingen.

Een van de mooie dingen in linux is dat je met behulp van ssh je hele machine kan beheren. Alleen is een standaard ssh opstelling niet de veiligste oplossing. Zodra jij ssh installeert en je sluit je pc aan op het internet duurt het niet lang voordat men probeert toegang te krijgen tot je machine m.b.v. brute force attacks. Hieronder een klein stukje van mijn /var/log/auth.log file.



Oct 5 12:52:05 System sshd[4493]: Did not receive identification string from 189.101.43.12
Oct 5 12:56:18 System sshd[4496]: reverse mapping checking getaddrinfo for bd652b0c.virtua.com.br [189.101.43.12] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 5 12:56:18 System sshd[4496]: Invalid user admin from 189.101.43.12
Oct 5 12:56:18 System sshd[4496]: pam_unix(sshd:auth): check pass; user unknown
Oct 5 12:56:18 System sshd[4496]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=189.101.43.12
Oct 5 12:56:20 System sshd[4496]: Failed password for invalid user admin from 189.101.43.12 port 50100 ssh2
Oct 5 12:56:23 System sshd[4499]: reverse mapping checking getaddrinfo for bd652b0c.virtua.com.br [189.101.43.12] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 5 12:56:23 System sshd[4499]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=189.101.43.12 user=root
Oct 5 12:56:24 System sshd[4499]: Failed password for root from 189.101.43.12 port 50177 ssh2


Zoals je ziet probeert een machine om de 2 seconden bij mij in te loggen.
Daar gaan we wat aan doen. Ik draai trouwens Debian unstable maar deze oplossing zou ook op andere distros moeten werken.De oplossing die ik gebruikt heb is om met keys te gaan werken, een andere poort te gebruiken en root login te disablen.

Het eerste wat we gaan doen is root login over ssh disablen en de gebruikte poort wijzigen.Gebruik je favoriete tekst-editor om de sshd_config file te openen. Mijn favoriete tekst-editor is nano maar die kan je dus invullen zoals je zelf wilt.
Uiteraard moet je het volgende commando als root uitvoeren (sudo of su).

System:~# nano /etc/ssh/sshd_config

In de config file verander je de volgende regels.

Port 22 > Port 443 (ik gebruik zelf 443 maar je kan natuurlijk iedere willekeurige poort gebruiken)
PermitRootLogin yes > PermitRootLogin no


Als je nu een dag zou wachten en dan met nano /var/log/auth.log opent zul je zien dat je al heel wat minder brute force attempts voorbij ziet komen.
Maar het kan natuurlijk nog veiliger. Hiervoor gebruiken we key authentication. Bij key authentication heb je op de server en de client een key nodig. Die 2 keys matchen en alleen met de juiste keys zul je in kunnen loggen. Ik gebruik voor mijn laptop, telefoon en usb stick elk een andere key. Mocht ik dan ooit 1 van die apparaten kwijtraken hoef ik alleen maar de desbetreffende key weg te gooien en het apparaat kan niet meer bij mijn pc. (de usb variant is voor als ik bij andere mensen thuis ben en ik wil bij mijn eigen pc). In dit voorbeeld maak ik de key voor op mijn usb stick.

Voor het maken van de key gebruiken we ssh-keygen.
Dit voeren we uit als user.

(username)@System:~$ ssh-keygen

Geeft ons de volgende output.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ulyssesnl/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ulyssesnl/.ssh/id_rsa.
Your public key has been saved in /home/ulyssesnl/.ssh/id_rsa.pub.
The key fingerprint is:
22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22 ulyssesnl@System (dit is normaal natuurlijk volledig random)


Als je een passphrase invult is je key file beveiligt met een wachtwoord, mocht iemand je key vinden kunnen ze er nog niks mee (behalve meenemen en brute force attacks uitvoeren op de keyfile, ondertussen moet je de key al verwijderd kunnen hebben). Het voordeel van geen passphrase gebruiken is dat je veilig in kan loggen zonder dat je een wachtwoord hoeft te gebruiken maar met passphrase is uiteraard veiliger.

als je nu de inhoud van /home/(username)/.ssh bekijkt.

(username)@System:/root$ ls /home/(username)/.ssh/

Zou je de volgende output moeten krijgen.

id_rsa id_rsa.pub

Bij mij ziet het er als volgt uit.

authorized_keys id_rsa id_rsa.pub werk werk.pub

De .pub file is trouwens de server side file en de file zonder extensie is de client file.

De id_rsa en id_rsa.pub files heb je net aangemaakt.
Het eerste wat we doen is de filenaam wijzigen zodat je weet wat het is.

(username)@System:/root$ mv /home/(username)/.ssh/id_rsa /home/(username)/.ssh/usb
(username)@System:/root$ mv /home/(username)/.ssh/id_rsa.pub /home/(username)/.ssh/usb.pub


Nu moeten we de .pub file in de authorized_keys zetten. Als dit je eerste key is bestaat dit bestand nog niet maar het aanmaken gaat op dezelfde manier als er een extra key aan toevoegen.

(username)@System:/root$ cat /home/(username)/.ssh/usb.pub >> /home/(username)/.ssh/authorized_keys

Ik gebruik meestal putty om via ssh op mijn systeem te komen en daarvoor moet je de client key nog omzetten. Hiervoor gebruiken we puttygen. Puttygen zit in het pakketje putty-tools dus gaan we die eerst installeren.

(username)@System:/root$ apt-get install putty-tools

Nu kunnen we met puttygen onze key omzetten.

(username)@System:/root$ puttygen /home/(username)/.ssh/usb -o /home/(username)/.ssh/usb.ppk
Enter passphrase to load key:


Nu laadt je in putty de .ppk key.
En probeer je in te loggen met ssh op je machine.
Mocht je nou niet kunnen inloggen moet je in je sshd_config regels aanpassen (of zelf toevoegen).
Dit moet uiteraard weer als root.

System:~# nano /etc/ssh/sshd_config

RSAAuthentication no > RSAAuthentication yes
PubkeyAuthentication no > PubkeyAuthentication yes


Na de wijzigingen moeten we eerst de ssh daemon opnieuw starten.

System:~# /etc/init.d/ssh restart

Als na de herstart het inloggen werkt gaan we de keyboard authentication van ssh disablen.

Let op doe dit alleen als je zeker weet dat je inlogt m.b.v. de key. als je ssh login een error geeft over de key maar toch ingelogt is betekent dit dat je ingelogd bent met keyboard authentication. Als je dan keyboard authentication disabled kun je niet meer via ssh naar je pc toe totdat je lokaal de config files gewijzigt hebt.

In de config file verander je de volgende regel en daarna doen we weer een restart.

PasswordAuthentication yes > PasswordAuthentication no
System:~# /etc/init.d/ssh restart

Nu is je ssh verbinding een stuk veiliger geworden.

Volgende: Overstappen 12-'08 Overstappen

Reacties


Door Tweakers user LuckY, vrijdag 10 oktober 2008 21:56

Dit is wel handig Materiaal;
Ga ik zeker een keer gebruiken . Binnenkort maar eens een debian installeren op een virtual machine.
Hier heb ik veel aan ; Bedankt.

Door Tweakers user et36s, vrijdag 10 oktober 2008 21:57

Hm klinkt erg goed misschien mijn eigen servers ook eens onder handen nemen.

Alleen heb ik net even /var/log/auth.log gecontroleerd en volgens die log heeft niemand een poging gedaan om binnen te komen. Al heb ik uiteraard wel de standaard poort gewijzigd.

Door Tweakers user et36s, vrijdag 10 oktober 2008 22:03

Ik mis alleen het feit dat je ssh niet opnieuw start? Anders worden de wijzigingen namelijk niet doorgevoerd.

/etc/init.d/ssh restart

Door Tweakers user 4ourty2, vrijdag 10 oktober 2008 22:05

@ ets36s

Uiteraard moet je ssh opnieuw starten dank je ik heb het even toegevoegd.
Als je je poort wijzigt zal je waarschijnlijk nooit een brute force attack voor je kiezen krijgen tenzij iemand eerst een poortscan doet. De meeste geautomatiseerde attacking machines zullen zover niet gaan.

[Reactie gewijzigd op vrijdag 10 oktober 2008 22:09]


Door isama, vrijdag 10 oktober 2008 22:36

hmmmz, ik heb alleen de standaard poort veranderd naar poort 443 (om door de schoolproxy heen te komen en tegen dit soort geintjes) en ik heb nergens last van.

Door Tweakers user Gerco, vrijdag 10 oktober 2008 23:28

Ik gebruik denyhosts tegen die brute force attacks. Na een instelbaar aantal login attempts wordt een IP voor een bepaalde tijd of voor eeuwig in /etc/hosts.deny gezet en kan hij dus niet meer connecten. Best handig en als je het zo inregelt dat een host maximaal een x uur niet meer kan connecten heb je ook niet al teveel last met mensen die hun password vergeten en zich zo laten blocken :)

Bij mij staat het op 10x verkeerd en 24 uur block, werkt perfect.

Door Tweakers user siepeltjuh, zaterdag 11 oktober 2008 00:26

Optie van Gerco lijkt me een stuk makkelijker, geen gedoe met keys. In het blog gegeven artikel geeft me het 'och shit usb met key vergeten' gevoel.

Niet dat het niet goed is, heel veilig, maar tmoetook makkelijk in gebruik zijn.

Natuurlijk zitten ook aan de ban methode haken en ogen. Iemand kan eenvoudig op een ander ip verder gaan, of als het via een bot netwerk gaat zijn er flink wat attempts mogelijk. In mijn ogen is het iig voor een thuis systeem afdoende.

Bij een systeem met zeer kritische processen moet je een fatsoenlijke corperate firewall plaatsen + dmz en hele reutemeteut.

Door Tweakers user 4ourty2, zaterdag 11 oktober 2008 00:39

Het nadeel met de optie van Gerco is dat als ze in die 10 keer die ze mogen proberen puur toevallig het goede raden dat ze binnen zijn. Maar mijn manier is ook maar 1 manier van de vele manieren om het op te lossen en volgens mij is het de veiligste (als dit niet zo is hoor ik het graag :) hoe veiliger hoe beter).

[Reactie gewijzigd op zaterdag 11 oktober 2008 00:40]


Door Tweakers user siepeltjuh, zaterdag 11 oktober 2008 00:57

Nou ja hoe veiliger hoe beter, het moet wel bruikbaar blijven.

Als je een wachtwoord gebruikt als Not3nd0P weet ik zeker dat ze niet in 10 pogingen binnen zijn. Hoewel ik zelf nooit een woord zou kiezen, maar willekeurige reeks, die begint midden in het alfabet. (meeste brute force begint bij a en gaat tot z of reverse)

En voor een thuis desktop systeempje lijkt me het echt geen giga issue. belangrijke data moet je toch altijd in alle gevallen offline bewaren (brand / diefstal / etc)

Er zijn meer optie natuurlijk, maar vind die van jou wel erg veilig en in mijn eigen geval gewoon niet handig, ik vergeet gewoon tevaak spullen als bijvoorbeeld usb key.

Ben erg benieuwd naar je komende blogs over debian.

Door Tweakers user PeterSelie, zaterdag 11 oktober 2008 07:31

Er zijn meer optie natuurlijk, maar vind die van jou wel erg veilig en in mijn eigen geval gewoon niet handig, ik vergeet gewoon tevaak spullen als bijvoorbeeld usb key.
Keys van een systeem dat schijnbaar dermate belangrijke software of andere data bevat dat het op een dergelijke manier beveiligd dient te worden zal je niet zomaar vergeten of rond laten slingeren. Kwestie van verantwoordelijkheid en een stukje gewenning.
Overigens is deze manier helemaal niet zo moeilijk of vervelend zoals je doet overkomen siepeltjuh, zorg gewoon dat overal waar je eventueel toegang tot je systeem dient te hebben je de key bij je hebt, zet deze des noods op je telefoon of het SD kaartje hiervan..

Door Tweakers user Pantagruel, zaterdag 11 oktober 2008 08:38

Leuke blog entry, maar uiteindelijk niets meer dan een 13 in een dozijn beschrijving (als in how-to's genoeg hoe je ssh toegang middels key/token access kan beveiligen), wel handig als eigen geheugen steuntje.

Opbouwende 'kritiek'
Als je dingen als DenyHost en/of Fail2Ban in dit blogje mee zou nemen en een stukje mbt ssh tunneling (bijv. imap/pop/http over de gebruikte ssh verbinding) zou toevoegen heeft t meer waarde tov de hand vol losse how-to's die je anders zou gebruiken.

Door Tweakers user fractal, zaterdag 11 oktober 2008 09:13

Ik heb ssh op de standaard poort laten staan en werd knap beroerd van de attacks (een tail -f van het logfile was niet "bij te houden" zo snel ging het) en heb Fail2Ban geÔnstalleerd. DenyHost ken ik niet uit ervaring.
Na 5 mislukte pogingen zet Fail2Ban het betreffende ip-adres in de blacklist waar ze toen ik begon na 10 minuten weer uit kwamen. Dat bleek te kort want je zag zo hetzelfde ip-adres weer aan de gang gaan. <g>
Uiteindelijk heb ik er maar 24 uur van gemaakt en dat helpt uitstekend <g>

Door Tweakers user LinuX-TUX, zaterdag 11 oktober 2008 12:59

:) Ik ken het probleem, vriend van me had het ook en vroeg zich af waarom ik er nooit last van had :Y) (terwijl hij ook een account had op mijn server ... d0h)

Ik heb gewoon een HELE vage poort gekozen om SSH op te draaien en afgelopen 7 jaar zo nu en dan een foute login attempt gehad, maar geen brute force voorbij zien komen.

Keys zijn leuk, totdat je ergens een keer in een hotel zit zonder laptop/usb stick ... en dan? Ja, je hebt de key ook op je micro SD kaartje staan in je mobiel, maarja, zie die key maar eens op die hotel PC te krijgen.

Met andere woorden, poort verandering was voor mij al genoeg en blijft vooral bruikbaar.

@ UlyssesNL:
Waarom een poort kiezen waar al de afspraak over gemaakt is om voor HTTPS te gebruiken? Vroeg of laat zal iemand die random sites scanned voor Apache/IIS vulnerabilities er toch achter komen wat er achter die poort zit. Just my 2 cents :Y)

Door Tweakers user 4ourty2, zaterdag 11 oktober 2008 13:32

@pantagruel
Thx voor de opbouwende kritiek. Toevallig was ik al van plan om het binnenkort over tunneling te gaan hebben.

@Linux-Tux
Ik heb die poort gekozen omdat je dan geen gezeur hebt met proxies waar je niet doorheen komt. En ook al zou ik mijn usb stick kwijt raken dan kan ik nog ssh-en met mijn telefoon zelf. Daar kan ik dan weer tijdelijk de keyboard authentication aanzetten.

Door Tweakers user Floort, zaterdag 11 oktober 2008 14:52

SSH draaien op een niet standaard poort maakt bijna niks uit voor de beveiliging. Een redelijk password is niet te bruteforcen, zeker niet met een halve poging per seconde. Zodra je certificaten hebt opgezet kan je "PasswordAuthentication" op "no" zetten en hoef je je helemaal geen zorgen meer te maken over bruteforce. En als je band breedte wilt besparen kan je ook nog de snelheid van de brute-forceers afknijpen tot 1 byte/s.

Door Tweakers user Puch-Maxi, zaterdag 11 oktober 2008 16:48

Erg leuke howto, erg nuttig ! Ga je nog meer van deze korte (security) howto's maken ?

Door Tweakers user 4ourty2, zaterdag 11 oktober 2008 17:20

@ puch maxi

Ik ga ieder geval nog meer blog postings maken.
Waaronder ook howto's. Als je een request heb kun je het ook altijd proberen natuurlijk.

Door Tweakers user Pantagruel, zaterdag 11 oktober 2008 20:35

@ UlyssesNL

Ik lees t graag.

Werkt btw fantastisch, ik haal geregeld mijn privť email over een ssh tunnel naar binnen (soms verbaas je je wel dat de usb poort te gebruiken is in een internet cafť)

Door Tweakers user domi235, vrijdag 17 oktober 2008 12:48

Handig, thanx! Ik gebruik ook al een tijdje 443, maar dan om de reden dat bijna niks anders open staat wat bruikbaar is op school :+

Door Jules, zaterdag 1 november 2008 08:12

Opzich een goede oplossing. Je blijft echter afhankelijk van de veiligheid van je sshd. Stel deze is een keer kwetsbaar dan staat je sshd nog altijd open voor de hele buitenwereld.

Je kunt er ook voor kiezen met iptables het eea af te schermen zodat niet zomaar ieder IP verbinding mag maken naar je host.

Een andere manier zou zijn dat je met je /etc/hosts.allow aan de slag gaat waar je zoals de bestandsnaam al aangeeft kunt configureren voor welke service bepaalde hosts worden toegelaten..

Door Tweakers user terabyte, woensdag 12 november 2008 21:51

Een paar jaar geleden zag ik hetzelfde probleem: volk dat via SSH probeert in te loggen. Ik heb echter een andere methode gebruikt om dit tegen te gaan.

Mijn firewall laat alleen SSH toegang vanaf specifieke IP adressen toe, nl van mijn werk, en van de universiteit (waar mijn shell-account nog steeds actief is..,).

Indien ik ergens op de wereld ben, en ik voel de noodzaak om thuis in te loggen, dan doe ik dat via de universiteit (zo goed als 100% uptime). Vandaaruit via ssh-naar mijn eigen server.

Verder is root-login uitgeschakeld

Door Tweakers user KingOfDos, dinsdag 2 december 2008 02:22

Ik draai zelf mijn SSH op poort 22, icm knockd om te zorgen dat er "niemand" bij kan komen zolang ze de juiste knockd procedure niet kennen.

Ik heb overigens een state driven iptables configuratie, dus ook iets andere iptables rules in gebruik icm knockd.

Voor Windows is er een precompiled variant te vinden op internet en veel distros hebben knockd in hun repositorys zitten. Ik heb ergens een knock.cmd, knock.sh en knock.exe files op een webserver staan, zodat ik de procedure zelf nog kan benaderen.

Ik wil ook nog iets gaan doen met "multifactor authenticatie" (iets icm SMS) vanaf onbekende IPs.

Reageren is niet meer mogelijk