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.
Als ik me goed herinner werk je met CentOS en dan kan je logrotate terugvinden ergens in de cron of in /etc/cron.daily. De logrotate config in /etc/logrotate.conf en in /var/log vind je vrijwel alle logfiles. Misschien toch snel eens logwatch draaien en kijken wat er allemaal op je systeem gebeurt. Je hebt nu geen flauw idee wat er dagelijks aan je deur staat te beuken? Want ook zonder gepubliceerd domein of website is jouw ip allang ontdekt door russen, roemenen en andere obscure figuren. Logwatch geeft een handig overzicht en desgewenst uitgebreid in hoogste level.
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.
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.
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 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.
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.
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.
