ssh wachtwoord vs key
Je hoort vaak dat voor ssh authenticatie een key veiliger is dan een wachtwoord. Stel nu dat je met maar 1 wachtwoord via ssh kunt inloggen op je server en dat wachtwoord is ca. 20 tekens lang en bestaat deels uit vreemde tekens (dus in theorie niet te raden). Is een wachtwoord dan net zo veilig?
De reden waarom ik dit vraag ... een wachtwoord vind ik prettig omdat ik die vanaf iedere locatie kan toepassen. Ik ben zelf de enige die het wachtwoord kent.
Voor- en nadelen?
Verschillende locaties (en zelfs verschillende clients op één locatie) is een voorbeeld van een situatie waarin je meerdere SSH-keys gebruikt, één voor elke client. Als één client namelijk is gecompromitteerd, wil je niet meteen de toegang vanaf andere clients moeten blokkeren.
Gewijzigd op 06/12/2014 12:56:22 door John D
Ward, ik heb inderdaad gelezen dat je ook "én" kunt gebruiken, een key met een pass phrase. Maar dan moet ik dus wel altijd een key hebben. Stel dat ik op een andere locatie ben en toch een keer moet inloggen, dan kan dat dus niet.
John, begrijp ik goed dat men op root ongelimiteerd kan bruteforcen en op elke andere user niet? Dus als ik root-login disable en daarnaast 1 andere user gebruik om in te loggen zit ik "goed"?
Nee. Elke user is te bruteforcen, maar het mooie van root is dat je weet dat die user op een *nix-systeem altijd bestaat. ;-) Een slimme systeembeheerder stelt overigens zijn systeem zo in dat root-logins over het netwerk niet mogelijk zijn (zoals "PermitRootLogin no" in sshd_config). Een aanvaller moet dan én een geldige username én het bijbehorende password zien te achterhalen.
Blijft alleen nog het punt van die gestaag groeiende secure-log (of auth-log, afhankelijk van je distributie). Dat heb ik verholpen door de secure-log te scannen in een cronjob die elke 2 minuten draait. Zie ik in de laatste 1000 regels meer dan 5 mislukte loginpogingen (voor elke willekeurige gebruiker) vanaf hetzelfde IP-adres, en staat dat adres niet in een whitelist, dan resulteert dat in het commando "iptables -I INPUT -s $ip_adres -j DROP" (in jip-en-janneketaal: blokkeer die sukkel). Het adres wordt bovendien toegevoegd aan de blacklist-database die over alle servers wordt gesynchroniseerd, zodat het betreffende IP-adres binnen een paar minuten op alle servers geblokkeerd is. Dat maakt het bruteforcen er niet eenvoudiger op. ;-)
Overigens verwijs ik bepaalde urls (zoals /cgi-bin/php of alles wat met /w00t begint) door naar hetzelfde script, zodat ook pipo's die onze webservers afscannen naar bekende vulnerabilities dat niet erg lang volhouden.
Willem vp op 07/12/2014 01:24:00:
Ja, op user root kan men in principe ongelimiteerd brute forcen. Ik zie in mijn logwatch oneindig veel pogingen om met root in te loggen. Ik heb inderdaad zoals Willem al aangeeft RootLogin=No staan dus men komt er nooit in met root. Brute Force op gewone users is daarintegen makkelijk uit te sluiten door simpel de gewone user op max 3 foute logins en dan blocked te zetten. Daar kan geen brute force tegenop. Dus stel dat een username extern bekend raakt dan is bij de 3e poging brute force de pret al over. Dat noem ik niet echt brute force, 3 pogingen. Die user geef je dan wel weer vrij maar bij de 2e keer ga je toch eens kijken wat er gebeurt. Ik heb deze cron entry dagelijks om 00:10 uur:> begrijp ik goed dat men op root ongelimiteerd kan bruteforcen
/usr/sbin/logwatch --detail high --range yesterday >/var/log/logwatch.log 2>&1
Ozzie, je moet maar eens kijken naar Logwatch en dan in Detail Level of Output op 10 zetten en kijken wie en wat er zoals dagelijks (honderden) pogingen gedaan wordt op je systeem. Zowel ssh als http
Gewijzigd op 07/12/2014 11:18:09 door Aad B
Gebruik jij een panel? Ik meen dat dit soort beveiligingsfunctionaliteit hier namelijk standaard al zit ingebouwd. Maar als je dus PermitRootLogin disablet, dan ben je dus eigenlijk "veilig"?
@Aad:
>> /usr/sbin/logwatch --detail high --range yesterday >/var/log/logwatch.log 2>&1
Wat doe je hier dan precies mee? Als ik het goed begrijp overschrijft dit bestand zichzelf dagelijks? Ga jij dan iedere dag kijken wat er is gebeurd?
Ozzie PHP op 07/12/2014 11:30:22:
Ik heb dit bestand opgegeven in de round robin van logfiles en ik bewaar er 30 om terug te kijken. In het begin heb ik ook de volgende cron regel gebruikt:Wat doe je hier dan precies mee? Als ik het goed begrijp overschrijft dit bestand zichzelf dagelijks? Ga jij dan iedere dag kijken wat er is gebeurd?
/usr/sbin/logwatch --detail high --range yesterday --mailto [email protected]
Als je ze zelf per maand wil bewaren kan je de bestandsnaam ook uitbreiden met: $(date +\%d).
Gewijzigd op 07/12/2014 11:38:46 door Aad B
Wat is dat?
Ik moet nog wel e.e.a. leren met die commandline :)
Gewijzigd op 07/12/2014 11:44:29 door Aad B
Gewijzigd op 07/12/2014 12:59:14 door Aad B
Ozzie PHP op 07/12/2014 11:30:22:
Gebruik jij een panel? Ik meen dat dit soort beveiligingsfunctionaliteit hier namelijk standaard al zit ingebouwd.
Geen idee of dat erin zit. ;-) Ik ben opgegroeid in de tijd dat er nog geen panels waren, dus ik gebruik die dingen niet. En die ene keer dat ik er eens mee zit te spelen mis ik al snel een heleboel functionaliteit die ik er eigenlijk wel in zou willen hebben...
Aad B op 07/12/2014 11:00:24:
Brute Force op gewone users is daarintegen makkelijk uit te sluiten door simpel de gewone user op max 3 foute logins en dan blocked te zetten. Daar kan geen brute force tegenop.
Die werkwijze vind ik zelf onhandig om twee redenen:
1) De echte gebruiker wordt daardoor ook geweerd van het systeem.
2) Je krijgt nog steeds failed logins in je logfile.
3) De mislukte loginpogingen geven nog steeds systeembelasting.
Die drie punten ondervang je wanneer je het IP-adres van de aanvaller blokkeert. Bovendien zie ik ook wel eens dat iemand usernames zit uit te proberen: er komt dan steeds 1 failed login op een heleboel usernames. Dat soort aanvallen duurt bij mij ook maximaal twee minuten. ;-)
Maar dan blokkeer je mogelijk toch veel meer users aangezien een ip-adres niet persoonsgebonden is?
1) Over het algemeen zijn het IP-adressen uit Mexico, China, Oekraïne of andere exotische oorden. Het zal me waarlijk aan mijn *piep* *piepen* of ik daarmee 1 persoon uitsluit of een paar honderd. Ik zou er niet eens minder om slapen als zelfs het hele land geblokkeerd wordt. ;-)
2) Als er meerdere personen achter hetzelfde IP-adres zitten, is dat vaak een bedrijf of organisatie of zo. Als er legitieme gebruikers zijn die de website niet meer kunnen bereiken, gaan ze vanzelf wel klagen bij hun systeembeheerder. In het beste geval neemt die dan weer contact met ons op en dan leg ik hem haarfijn uit wat voor gebruikers hij op zijn netwerk heeft.
3) Gebruikers die een Unix-login op een van onze systemen hebben, zijn over het algemeen gebruikers die dat hard nodig hebben voor hun werk. Ik sluit liever een of andere vage gebruiker uit die al dan niet bewust een login probeert te kraken, dan iemand die 45 meter boven de grond aan twee touwtjes in een mast bungelt en probeert zijn werk te doen.
4) Na verloop van tijd wordt een blokkade wel weer opgeheven. Die tijd is echter dusdanig lang (eens in de 2 a 3 maanden heb ik er eens erg in om de boel op te schonen) dat een brute force-aanval niet heel erg effectief is.
5) De grootste groep adresdelers betreft mobiele gebruikers. Ik moet echter het eerste mobiele IP-adres nog tegenkomen dat een brute force-aanval uitvoert.
Willem vp op 07/12/2014 21:01:08:
Bij een serieuze security audit krijg je absoluut een minpunt wanneer gebruikers oneindig in kunnen loggen. Het advies resulteert dan altijd in de aanbeveling van grens op drie pogingen. Wij willen graag dat we 100% goedkeuring krijgen na een audit zodat we niet de de voorpagina Telegraaf halen bij problemen.....Die werkwijze vind ik zelf onhandig om twee redenen:
1) De echte gebruiker wordt daardoor ook geweerd van het systeem.
2) Je krijgt nog steeds failed logins in je logfile.
3) De mislukte loginpogingen geven nog steeds systeembelasting.
1) De echte gebruiker wordt daardoor ook geweerd van het systeem.
2) Je krijgt nog steeds failed logins in je logfile.
3) De mislukte loginpogingen geven nog steeds systeembelasting.
Ik kan me voorstellen dat je voor allerlei leuke webservers een dergelijke fancy geautomatiseerde blocking inbouwt maar ook dat geeft elke minuut systeem belasting. Hier op het werk hoeven we daar echt niet mee aan te komen. @Willem: Ik bedoel dat niet negatief, ik vind je beveiliging erg gaaf. Wil dat voor mezelf ook wel eens bouwen.
Gewijzigd op 08/12/2014 09:45:35 door John D
John D op 08/12/2014 09:43:29:
Bij een serieuze security audit krijg je absoluut een minpunt wanneer gebruikers oneindig in kunnen loggen. Het advies resulteert dan altijd in de aanbeveling van grens op drie pogingen. Wij willen graag dat we 100% goedkeuring krijgen na een audit zodat we niet de de voorpagina Telegraaf halen bij problemen.....
Ik blijf erbij dat een IP-block effectiever is dan het blokkeren van een gebruiker. Sterker nog, ik ben absoluut tegenstander van het na drie pogingen blokkeren. Je maakt een Denial of Service-attack daarmee wel erg eenvoudig. Ik zie veel meer in een progressieve wachttijd na elke mislukte login, eventueel aangevuld met een verplichte two-step authentication (middels bijvoorbeeld een SMS-code) na een bepaald aantal mislukte pogingen. Helaas is dat nog geen standaard functionaliteit van sshd.
Quote:
Ik kan me voorstellen dat je voor allerlei leuke webservers een dergelijke fancy geautomatiseerde blocking inbouwt maar ook dat geeft elke minuut systeem belasting. Hier op het werk hoeven we daar echt niet mee aan te komen.
Die belasting valt heel erg mee. Wanneer iemand op je server zit te hameren is de belasting veel hoger, omdat dat een heleboel disk writes (logging) oplevert. Bovendien wordt met al die inlogpogingen (in onze situatie) de externe netwerkverbinding belast, terwijl de communicatie met de databaseserver om de blacklist op te halen over het backbone-netwerk gaat (en dat netwerk heeft een veel grotere bandbreedte).
Als ik binnenkort tijd heb, ga ik eens kijken of ik die blacklist automatisch kan toevoegen aan de shun-list van onze Cisco-router, zodat de blokkering nóg eerder in de keten plaatsvindt.
Gewijzigd op 08/12/2014 11:05:19 door Willem vp