Of gebruik denyhosts: http://denyhosts.sourceforge.net/

Of sshguard: http://www.sshguard.net/

Of fail2ban
http://www.fail2ban.org/wiki/index.php/Main_Page

Block login after 3 failed attempts for 1 hour ;-)

Of fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page

Waarom extra rotzooi op je doos installeren terwijl je simpelweg sshd kunt configgen? ;-)

omdat ook sshd lek kan zijn. fwknop is trouwens een aardige oplossing, helaas server/client

Haha, dit weet ik al heel lang. Een van mijn servers wordt ook de hele tijd aangevallen. Binnen 1 maand 9868 mislukte loginpogingen op het account root. Ben ik even blij dat ik toch een redelijk wachtwoord heb.

Dan raad ik je toch aan om denyhosts, fail2ban of sshguard te implementeren. Scheelt een hoop zooi in je logs.

Waarom niet gewoon iptables & ipt_recent gebruiken om <x> failed login attempts in <y> seconden/minuten/etc. te blokkeren? Wat mij op valt is dat ICMP droppen ook resulteert in een fors aantal minder pogingen...

Ik ben daarmee begin 2010 gestopt toen de netwerken van gecompromitteerde pc's al een poosje zo omvangrijk waren dat elke poging van een duidelijk samenhangende dictionary-attack van een ander IP-adres kwam (de loginnamen waren alfabetisch, de IP-adressen willekeurig). Fail2ban zag de verbanden niet meer en was nutteloos geworden. De aanvallers hielden duidelijk rekening met fail2ban en soortgelijke tools. Gaat dat tegenwoordig weer beter?

Je kan het ook omdraaien en de poort alleen openzetten wanneer dat nodig is. Er bestaan allerlei varianten van port knocking die dat faciliteren. Die vervangen natuurlijk niet de authenticatie, maar op de een of andere manier reageren critici van port knocking alsof dat meteen het enige is wat je nog doet. Wat ik tegenkwam in tools die dit faciliteren kwam wat omslachtig op me over, dus begon ik simpel en zette via iptable-rules de ssh-poort gedurende 30 seconden open voor nieuwe verbindingen door op een nep-URL te reageren binnen de website die op de betreffende server draait:


Er staat bij mij iets anders dan klopklop en BINNEN ;-). Er is al een rule die verkeer op bestaande verbindingen toelaat, dus er hoeft alleen even tijd gemaakt te worden om een nieuwe verbinding op te zetten. Vanuit een shell (of een script) doe je:


De ssh-toegang staat alleen open voor het IP-adres van waar de URL werd opgevraagd. Voor de authenticatie gebruik ik sleutels, dit dient alleen om de poort te camoufleren, vergelijkbaar met het gebruiken van een afwijkende poort. Ik heb sinds ik dit zo ingesteld heb, een kleine twee jaar nu, niet één brute force-aanval meer gezien, dus in al zijn eenvoud is het voor mij heel effectief. Daar moet ik wel bij aantekenen dat de ssh-toegang van buiten weinig wordt gebruikt, en dus ook deze constructie niet, wat de kans dat iemand die op de verbinding meeluistert het trucje doorkrijgt klein houdt. Maar een alternatieve poort voor ssh is nog makkelijker te doorzien, dus daar doet dit niet voor onder, en de URL is zonodig snel aangepast.

Ik hoop dat je het nu niet over je root-account hebt, je kan directe root-toegang over ssh beter uitschakelen, via een gewone user en sudo werken is beter. In plaats van een redelijk zou ik de voorkeur geven aan een sterk wachtwoord, een goede passphrase bijvoorbeeld. Maar wachtwoorden kan je voor ssh beter helemaal uitschakelen, authenticatie met sleutels heeft, zoals het artikel zegt, de voorkeur.

Als je soms vanaf computers moet werken die niet te vertrouwen zijn en waar je dus geen enkel wachtwoord in wil typen, ook niet dat van je ssh-sleutel, dan kan je de toegang op sleutel middels pam-modules aanvullen met een systeem voor one-time passwords (challenge/response), zoals opie of otpw. Beide kunnen lijsten met one-time passwords produceren die je op papier mee kan nemen (waarin otpw het beter doet omdat niet het hele otp wordt afgedrukt, je moet een prefix toevoegen, en bij opie bestaat een volgordelijke afhankelijkheid die een aanvaller in theorie kan gebruiken, uit latere passwords zijn eerdere af te leiden). Voor opie (s/key) zijn wel weer Java-applicaties voor je mobiele telefoon te vinden zodat je die kan gebruiken als een token, dat heeft otpw weer niet. Android-telefoons kan je als token gebruiken voor een derde systeem, barada. Van de drie heb ik zelf alleen opie ooit een poosje gebruikt, met die Java-applicatie op mijn telefoon, als fall-back voor sleutels als ik een keer vanaf een computer die ik niet vertrouwde moest werken. Werken vanaf een computer die je kan vertrouwen via gegenereerde sleutels heeft echter de voorkeur.

Dat was ook het probleem met sshguard. Maar de laatste versie lijkt daar veel beter in te zijn.

SSHguard FTW !!

Dat zou interessant zijn, maar ik zie eigenlijk niet hoe ze dat voor elkaar zouden moeten krijgen. Volgens hun website blokkeren ze net als fail2ban ip-adressen op basis van meldingen in logbestanden. Het is onmogelijk een ip-adres dat je nog niet gezien hebt te blokkeren voordat de poging die de melding in een logbestand doet belanden gedaan is, software is niet helderziend.

Ik denk dat het plausibeler is dat de verbetering die je ziet het gevolg is van het oprollen van grote botnets, dat is een aantal keer in het nieuws geweest, zodat aanvallen uit een pool van IP-adressen worden afgevuurd die klein genoeg zijn om wel gedetecteerd te worden door sshguard en soortgelijke tools.

DenyHosts heeft een synchronisatie functie waarmee je de hosts die je blokkeert kan delen met anderen. Hiermee kan je dus wel degelijk ip-adressen die je nog niet gezien hebt blokkeren.

Welke van deze programma's hierboven doet z'n werk het beste? SSHGuard, DenyHosts, Fail2Ban of IPQ BDB

DenyHosts heb ik ervaring mee de rest nog niet. Kunnen ze ook naast elkaar draaien of is dit af te raden?