Sterke toename SSH brute-force aanvallen
Het aantal aanvallen op servers die SSH draaien is de afgelopen dagen sterk gestegen. Sinds 11 mei is het aantal pogingen van aanvallers om zich met bruut geweld toegang tot een machine te verlenen bijna vervijfvoudigd. De aanvallers gebruiken verschillende manieren, zo beperkt men via de 'low en slow' manier het aantal pogingen om detectie door IDS/IPS systemen te voorkomen. Aan de andere kant worden ook botnets ingezet om gedistribueerde aanvallen uit te voeren. "Dit is een goed moment om je netwerk te onderzoeken om te zien welke servers SSH open hebben staan," zegt ISC handler Scott Fendley.
Beheerders die zich willen wapenen tegen het brute-force geweld hebben de keuze uit verschillende tools, zoals DenyHosts, fail2ban en BlockHosts in combinatie met TCP-Wrappers om toegang tot servers te blokkeren. Andere opties zijn het uitschakelen van directe toegang tot het root account, het niet gebruiken van eenvoudig te raden gebruikersnamen en het gebruik van sterke wachtwoorden of public key authenticatie. Ook het beperken van het aantal publiek toegankelijke services via bijvoorbeeld iptables kan helpen.
gebruiken... Heb je hier helemaal geen last van.
misschien vallen mijn servers dan net buiten hun bruteforce
IPranges ...
server aan 't internet hing, was ik echt verbaasd door dit
fenomeen, zo'n lompe aanval, maar kennelijk werkt 't, anders
gebeurde het niet. Maar ik was nog verbaasder dat de SSH
demon niet automatisch na talloze poging een host blokkeert.
Een andere beveiliging (naast een sterk wachtwoord) is zo'n
systeem waarbij je poort pas opengaat na een aantal
connectieverzoekjes naar bepaalde poorten in een bepaalde
volgorde. Ik kan even niet op de naam komen. Zelf draai ik
SSH op een andere poort, je zou het security through
obscurity kunnen noemen, maar ik noem 't "minder troep in
m'n log files en geen gerommel aan m'n deur".
http://it.slashdot.org/article.pl?sid=08/05/13/1533212
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --set --name SSH --rsource
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j DROP
Das alleen van toepassing als de aanvaller ten tijde van het
aanmaken van het keypair al op de server zat.
-Jeroen
Das alleen van toepassing als de aanvaller ten tijde van het
aanmaken van het keypair al op de server zat.
Juist niet. Alle keys die aangemaakt zijn door Debian (of
afgeleide distributies) sinds 2006 zijn erg zwak. Je hoeft
dus geen wachtwoorden meer te kraken maar kunt volstaan met
het vinden van een zwakke key.
Peter
Das alleen van toepassing als de aanvaller ten tijde van het aanmaken van het keypair al op de server zat.
Juist niet. Alle keys die aangemaakt zijn door Debian (of afgeleide distributies) sinds 2006 zijn erg zwak. Je hoeft dus geen wachtwoorden meer te kraken maar kunt volstaan met het vinden van een zwakke key.
Of natuurlijk gewoon public key authentication gaan gebruiken... Heb je hier helemaal geen last van.
als je weet van welke hosts je erbij moet kunnen? De rest
heeft er niets te zoeken.
Het argument dat je van overal ter wereld erbij moet kunnen
is bull-shit.
Je hebt ook nog DenyUsers en AllowUsers en zo zijn er nog
wel meer manieren om de boel behoorlijk dicht te houden.
- Unomi -
bepaalde ports wordt port 22 even opgezet, en na establishen
van de connectie weer dichtgezet voor nieuwe requests.
Toen ik een paar jaar geleden voor het eerst een linux
server aan 't internet hing, was ik echt verbaasd door dit
fenomeen, zo'n lompe aanval, maar kennelijk werkt 't, anders
gebeurde het niet. Maar ik was nog verbaasder dat de SSH
demon niet automatisch na talloze poging een host blokkeert.
Een andere beveiliging (naast een sterk wachtwoord) is zo'n
systeem waarbij je poort pas opengaat na een aantal
connectieverzoekjes naar bepaalde poorten in een bepaalde
volgorde. Ik kan even niet op de naam komen. Zelf draai ik
SSH op een andere poort, je zou het security through
obscurity kunnen noemen, maar ik noem 't "minder troep in
m'n log files en geen gerommel aan m'n deur".
@Un0mi: waarom is het overal vandaan bij je ssh server komen
bullshit?
wij hebben een ssh server aan het internet hangen waar we
vanaf klantlocaties op moeten kunnen komen. We weten
eenvoudig genoeg niet wat voor ip adressen daar gebruikt worden.
Om de boel veilig te houden maken we gebruik van public key
authenticatie en denyhosts om het gehamer op de deur te
minimaliseren.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
