Bekijk Volledige Versie : Beveiligen van ssh
Heb een tijd SSH draaien en ik zie toch best vaak brute force attacks, heb een sterk wachtwoord dus dat is het punt niet.
Maar nu de vraag, kan ik dit tegenhouden? en misschien sowieso ssh beter beveiligen?
Alvast bedankt...
cyberbootje
06/12/09, 13:05
Je kan een ander poort nummer gebruiken, root login uitschakelen en ssh op client ip adres vastleggen...
Zoek eens op SSH tunnel, dit scheelt al een groot stuk.
marsipulami
06/12/09, 13:10
werken met ssh certificaten
Heb een tijd SSH draaien en ik zie toch best vaak brute force attacks, heb een sterk wachtwoord dus dat is het punt niet.
Maar nu de vraag, kan ik dit tegenhouden? en misschien sowieso ssh beter beveiligen?
Alvast bedankt...
Ga eens met keys werken en schakel de mogelijgheid om een username wachtwoord combi te gebruiken uit.
Daarnaast eventueel bovenstaande opties:
- zet ssh op een andere poort
- limiteer het source ip wat toegang heeft.
Er zijn veel mogelijkheden om dat op te lossen.
Je zou sshd op een andere poort kunnen laten luisteren (dus één die niet in /etc/services opgesomd is), je zou een tool zoals fail2ban kunnen installeren ( zie http://mh-lantech.css-hamburg.de/ipcop/wiki/index.php?title=Fail2ban )
Je zou sshd zo kunnen configureren zodat mensen alleen met sshkeys in kunnen loggen.
etc . .
Wat ik altijd doe is root login disablen (wel eerst een ander account maken), en daarna het poortnummer veranderen.
Beter is natuurlijk alleen via het vlan op ssh kunnen inloggen
Zoek eens op SSH tunnel, dit scheelt al een groot stuk.
Ik heb gezocht, maar weet nog steeds niet wat je hiermee wil zeggen...
doet eens wat van je clue hier gooien zodat het zoeken specifieker kan worden...
De bruteforce attacks blijven als je key only authenticatie gebruikt, alleen komen ze er dan niet in ( root authenticatie heb ik alleen in mjin prive netwerk staan, nooit op dozen die extern zijn).
sshblock is ook een oplossing (en eventueel zelf ook erg makkelijk te schrijven, mocht je een daemon daarvoor een beetje overdreven vinden).
http://www.bsdconsulting.no/tools/sshblock-1.0.pl
Mijn ervaring met het veranderen van poorten ed dat je je zelf alleen maar loopt te pesten, daar er bij veel klanten geen andere poorten openstaan waarover je kan communiceren met ssh,.
Mvgr,
Martin
cyberbootje
06/12/09, 13:43
Aanvulling:
Je kan ook een permanente ssh block vanuit extern verkeer doen en dan met vpn eerst inloggen, je krijgt dan een ip binnen je vlan en dan pas zou je in kunnen loggen.
En als al het bovenstaande niet voldoende is kan je portknocking overwegen.
Dat is een extra laag van beveiligen, niet bedoeld ter vervanging van de huidige beveiliging.
je kan ook nog (eventueel als extra) dingen als fail2ban gebruiken
Voor servers waar ik met wachtwoord op kan, gebruik ik een token, naast het password (Swekey (http://www.swekey.com/) will do, zonder dat je een PKI omgeving hoeft te bouwen). Verder werk ik eigenlijk alleen met SSH keys. fail2ban/lfd draait op sommige servers, belangrijke zaken staan achter een transparante firewall die :22 gewoon niet toelaat vanaf vage IP's.
Verder werk ik vrijwel altijd met VPN of via een terminal server (SSL beveiligd). Even globaal wat dingen, zonder details.
Voor de fails in een normale omgeving kun je fail2dan of LFD gebruiken. Een andere poort is eigenlijk wel een vereiste, dat scheelt snel 95%+ van de zooi. Met IPtables kun je ook een fail2ban systeem maken, door te triggeren op het aantal requests per minuut.
SSH poort veranderen zal enkel je logs schoon houden. Voor de rest houd het jezelf enkel voor de gek: een goed geconfigureerde SSH server heeft geen last van de bruteforce attacks (bijvoorbeeld omdat je key only logins hebt, of omdat je regelmatig een nieuw wachtwoord neemt). Veranderen van poort is leuk om die brute force attacks niet meer te zien, maar voor de rest is het een schijnveiligheid. Wil iemand echt kwaad, is het niet lastig om de juiste poort alsnog te vinden.
Verder bovenstaande zaken meenemen. Keys werken erg goed en zijn zeer veilig. Root login uitzetten (zodat er twee accounts 'gekraakt' moeten worden) en connecties beperken tot een aantal IP's (of ranges, als je dynamisch zit). Verder natuurlijk je software (client en server) up to date houden.
Ratelimit voorbeeld (3x per minuut, bij 4e keer een drop) op basis van IPTables. (elke Linux 2.6x kernel, géén xBSD!)
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--update --seconds 60 --hitcount 4 -j DROP
Dit kun je in je rc.local zetten of in je standaard iptables file. Vergeet niet te saven :)
Randy, die Swekeys werken die ook in linux/mac omgevingen?
Ik zie in het voorbeeld script dat er namelijk een ActiveX object embedded moet worden. (Gaat vol automatisch).
Randy, die Swekeys werken die ook in linux/mac omgevingen?
Ik zie in het voorbeeld script dat er namelijk een ActiveX object embedded moet worden. (Gaat vol automatisch).
Dat is een goede Martijn. Ik zal hem vanmiddag bij @aim24 even in de Mac proppen en kijken of het werkt.
Maar voor de Linux en Mac heb je al SSH-keys. En dat zonder peagant :).
Dat klopt,
Maar ik zag (gezien de beperkte kosten) hier een mooie addon in de beveiliging van een WebApp voor wat klanten. Ik zou een App namelijk willen beveiligen met een OTP.
Belangrijk is dan wel dat het zelfde systeem feilloos/naadloos op verschillende OSen werkt. En elke keer een code sms-en is wel mooi maar ook niet altijd praktisch. (zou je dat met SSH ook kunnen doen?)
Swekeys zitten op $20.- (13,50?) per stuk. Dus dat lijkt me zeer cheap. Voor dat geld zet je zelf geen PKI infrastructuur op. Je kunt nog een dollar per stuk korting krijgen via een referal.
Ik zit nu in de tsjoek naar 024 en bedenk me dat de Swekey nog in 053 ligt. De test op de mac houdt je nog tegoed.
Geen probleem!
Ik hoor het wel van je. Voor dat geld kan je inderdaad geen PKI opzetten.
avanmessen
07/12/09, 15:43
Zo doe ik het :
http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter8.html
SSH via public key, root SSH login disabled.
1024-bit AES encryptie, veilig genoeg ...
:thumbup:
Het gebruik van keys ben ik niet echt voorstander van, met als volgende reden dat je de keys niet altijd bij je hebt op usb sitck etc. Dat als je de key verliest door bvb computer crash, kantoor die afbrand, natuurramp etc met als gevolg dat je niet meer kunt inloggen.
Manier die ik gebruik is daarom misschien beetje omslachtig maar ik kan overal in loggen zonder problemen. Ik firewall de ssh op core firewall en niet op machine's zelf, hier laat ik enkel mijn fixed ip toe van kantoor. Als ik bvb op verplaatsing ben en ik moet inloggen op ssh dan maak ik eerst verbinding met de vpn op kantoor en kan van daar weer op de ssh inloggen.
Wat leuk zou zijn is bvb gebruik te kunnen maken van je eID (geen idee of ze dat in nl al hebben) om zo te kunnen inloggen met je pasport en je pin code.
en wat is dan je achtervang voor als een keer die verbinding niet wil? kun je anders meteen je servers niet meer in als de adsl/kabel/whatever een keer storing heeft
en wat is dan je achtervang voor als een keer die verbinding niet wil? kun je anders meteen je servers niet meer in als de adsl/kabel/whatever een keer storing heeft
Dat kun je anders ook niet als de adsl niet werkt he ;) en nee ik heb geen mobile internet. Dan ga ik maar ter plaatse naar het datacenter, het is voor de ene keer dan ook geen zo een ramp en het is toch niet zo ver (voor mij).
Punt is hier dat als adsl niet werkt het meestal de hele zone/regio is (centrale) en als ik dan naar andere zone moet om adsl te hebben kan ik net zo goed naar DC gaan. Binnenkort komt hier misschien wel verandering in omdat ik 2de plaats fixed ip zal hebben met vpn, dus kunnen we deze ook toevoegen in de firewall.
Het gebruik van keys ben ik niet echt voorstander van, met als volgende reden dat je de keys niet altijd bij je hebt op usb sitck etc. Dat als je de key verliest door bvb computer crash, kantoor die afbrand, natuurramp etc met als gevolg dat je niet meer kunt inloggen.
Daarom hebben we OpenPGP smartcards, ze zijn zo groot als een pin-pas en relatief veilig. (as safe as the weakest link... and that's you)
Manier die ik gebruik is daarom misschien beetje omslachtig maar ik kan overal in loggen zonder problemen. Ik firewall de ssh op core firewall en niet op machine's zelf, hier laat ik enkel mijn fixed ip toe van kantoor. Als ik bvb op verplaatsing ben en ik moet inloggen op ssh dan maak ik eerst verbinding met de vpn op kantoor en kan van daar weer op de ssh inloggen.
En je key cached gewoon op je laptop ? :(