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.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.