Nieuws
image

XS4ALL-klanten doelwit SSH-aanvallen

donderdag 12 augustus 2010, 12:10 door Redactie, 29 reacties

Internetprovider XS4ALL waarschuwt klanten voor een toename van SSH brute force-aanvallen, zwakke wachtwoorden zijn namelijk de oorzaak dat aanvallers servers overnemen. Een aantal van de incidenten is gerelateerd aan een beveiligingslek in phpMyAdmin, waarbij kwaadaardige software in de server wordt geïnjecteerd, zegt XS4ALL Chief Security Officer (CSO) Scott McIntyre tegenover Security.nl. De malware is volgens McIntyre een 'ssh brute forcer'.

De CSO merkt op dat dat de aanval alleen succesvol is vanwege zwakke wachtwoorden op de gehackte servers. De provider wil niet zeggen om hoeveel aanvallen het precies gaat, maar laat weten dat het percentage aanvallen in de laatste dagen met 150% tot 200% is toegenomen. "Dat zijn unieke bronnen van SSH brute force-aanvallen van buiten ons netwerk", aldus McIntyre.

Klachten
De aanval zorgde voor een "korte piek" in klachten over XS4ALL-klanten, van wie de gehackte servers werden gebruikt voor het uitvoeren van brute-force SSH-aanvallen op andere netwerken. "In een handvol gevallen ging het om klanten met een lekke phpMyAdmin, maar in veel andere gevallen was het zwakke authenticatie en ontbrekende firewalls op de aan het internet hangende SSH daemons", laat de CSO weten.

In absolute getallen gaat het nog steeds om een zeer klein aantal klanten, maar de plotselinge toename op één dag was volgens McIntyre opmerkelijk. Daarnaast zijn ook klanten van andere providers doelwit. "Het is niet per definitie dat alleen XS4ALL-klanten doelwit zijn, het is alleen dat wij er ons van bewust zijn."

Geen wachtwoorden
De internetprovider adviseert klanten om nooit beheerapplicaties op hun eigen servers aan het internet te hangen. "PhpMyAdmin zou achter een firewall en/of .htaccess-achtige bescherming moeten." Daarnaast zouden SSH daemons niet zonder firewalls en tcp_wrappers moeten draaien, en waar mogelijk geen toegang op wachtwoorden toestaan, maar SSH sleutels gebruiken. De aanvallen zijn inmiddels ook door het Internet Storm Center opgemerkt. Het zou gaan om een nieuw brute force script, mogelijk genaamd dd_ssh.

Reacties (29)
12-08-2010, 13:10 door Anoniem
Ik zit op Telfort en ik heb al een week of zo last van deze brute force aanval.

Heb ik ook gerapporteerd:
http://www.security.nl/artikel/34063/1/Bruteforce_dictionary_botnet_attack.html
12-08-2010, 13:42 door rsterenb
Niets nieuws: dit speelt al jaaaren. SSH aan internet hoort geen password auth te hebben; als je public/private key auth gebruikt dan heb je hier nauwelijks last van (attempts genoeg, maar geen enkele die lukt), want de kans dat iemand je private key kan faken is toch wel erg klein. En natuurlijk moet je de private key niet laten slingeren...
12-08-2010, 13:45 door SirDice
Door rsterenb: Niets nieuws: dit speelt al jaaaren. SSH aan internet hoort geen password auth te hebben; als je public/private key auth gebruikt dan heb je hier nauwelijks last van (attempts genoeg, maar geen enkele die lukt), want de kans dat iemand je private key kan faken is toch wel erg klein. En natuurlijk moet je de private key niet laten slingeren...
De kans dat iemand mijn wachtwoord bruteforced acht ik ook niet heel erg groot. In de eerste plaats omdat er een fatsoenlijk wachtwoord op zit. En als tweede gaat de boel op slot voor 1 a 2 (random tijd) uur na 4 foute logins.
12-08-2010, 13:51 door Anoniem
Of je hangt er een honepot aan om te zien wat ze aan het uitspoken zijn http://code.google.com/p/kippo/
12-08-2010, 14:00 door Anoniem
Kan je systemen na een aantal mislukte inlogpogingen niet automatisch een IP ban geven ? Op deze wijze kan je aanvallers blokkeren bij een brute force attack (tenzij de attack echter distributed is en steeds weer andere adressen gebruikt), terwijl legitieme gebruikers niet worden buitengesloten ?
12-08-2010, 14:09 door Anoniem
Het is niet altijd mogelijk om met SSH sleutels te werken, een veel gebruikte oplossing is om je eigen IP te white-listen in je IP tables op SSH, werkt overal en daarmee moet de aanvaller eerst jouw IP spoofen, wat vrijwel ondoenlijk is, en dat in combinatie met een sterk wachtwoord. Ik zeg altijd: 26 tekens, evenveel als het alfabet, en je zit goed. Er is geen computer ter wereld die 26 karakters kan kraken.
12-08-2010, 14:20 door Anoniem
SirDice: als je met "de boel" bedoelt dat het betreffende IP adres geen toegang meer heeft werkt dat slecht tegen een botnet... Bovendien heeft zo'n net alle tijd.
12-08-2010, 14:53 door SirDice
Door Anoniem: Kan je systemen na een aantal mislukte inlogpogingen niet automatisch een IP ban geven ? Op deze wijze kan je aanvallers blokkeren bij een brute force attack (tenzij de attack echter distributed is en steeds weer andere adressen gebruikt), terwijl legitieme gebruikers niet worden buitengesloten ?
Er zijn meerdere oplossingen maar zelf gebruik ik sshguard.

SirDice: als je met "de boel" bedoelt dat het betreffende IP adres geen toegang meer heeft werkt dat slecht tegen een botnet... Bovendien heeft zo'n net alle tijd.
Tegen die distributed aanvallen doe je inderdaad niet zo veel op deze manier, dat klopt. Ik kijk echter regelmatig in m'n log files en voeg eventuele notoire IP adressen zelf toe aan een lijst om te blokkeren.

Omdat ik van te voren niet weet waar ik zit of wanneer ik remote toegang nodig heb is het whitelisten of het gebruik van sleutels niet werkbaar voor mij.
12-08-2010, 15:05 door Anoniem
Door SirDice:

Omdat ik van te voren niet weet waar ik zit of wanneer ik remote toegang nodig heb is het whitelisten of het gebruik van sleutels niet werkbaar voor mij.

Die snap ik niet helemaal. Je kan je key toch meenemen op bijvoorbeeld een USB key? (op zijn beurt voorzien van de nodige beveiliging natuurlijk). White en blacklisten in dit scenario lijkt me erg arbeidsintensief.
12-08-2010, 15:50 door Anoniem
Zie ook:
http://isc.sans.edu/diary.html?date=2010-08-10
12-08-2010, 16:10 door wizzkizz
Door SirDice:
SirDice: als je met "de boel" bedoelt dat het betreffende IP adres geen toegang meer heeft werkt dat slecht tegen een botnet... Bovendien heeft zo'n net alle tijd.
Tegen die distributed aanvallen doe je inderdaad niet zo veel op deze manier, dat klopt. Ik kijk echter regelmatig in m'n log files en voeg eventuele notoire IP adressen zelf toe aan een lijst om te blokkeren.

Omdat ik van te voren niet weet waar ik zit of wanneer ik remote toegang nodig heb is het whitelisten of het gebruik van sleutels niet werkbaar voor mij.
Ik gebruik ook een oplossing om na 5 foutieve logins een uur de toegang te blokkeren, maar op mijn machines zie ik de laatste tijd heel veel verschillende ip-adressen die vrijwel tegelijkertijd een of twee opties proberen. Dus blacklisten helpt dan niet zo.

Maar goed, ik maak me niet zoveel zorgen. Op 1 machine, die ook als webserver ingericht is, is via ssh alleen toegang mogelijk met een sleutel en het spreekt voor zich dat ftp etc. uitgeschakeld is.
De andere machine die ik als proxy-server gebruik om het loggen door ISP's te omzeilen, accepteert zowel sleutels als c/r wachtwoorden, maar daar heeft slechts 1 account toegang via ssh. En dat is voorzien van een degelijk wachtwoord.
12-08-2010, 16:12 door SirDice
Door Anoniem:
Door SirDice:

Omdat ik van te voren niet weet waar ik zit of wanneer ik remote toegang nodig heb is het whitelisten of het gebruik van sleutels niet werkbaar voor mij.

Die snap ik niet helemaal. Je kan je key toch meenemen op bijvoorbeeld een USB key? (op zijn beurt voorzien van de nodige beveiliging natuurlijk). White en blacklisten in dit scenario lijkt me erg arbeidsintensief.
Wat dus betekend dat ik altijd die USB key bij me zou moeten hebben, da's dus niet zo handig voor mij.
12-08-2010, 16:20 door Anoniem
@SirDice:

Waarom is dat niet zo handig? USB sticks zijn eenvoudig aan een sleutelbos vast te maken, en ik heb er laatst ook al één voorbij zien komen in de vorm van een sleutel, van degelijke kwaliteit...

~JJ
12-08-2010, 17:06 door SirDice
D'r zit al genoeg aan m'n sleutelbos. Daar hoef ik echt niet nog meer bij.

Bovendien staat het al zo'n 10 jaar zo en zie ik ook al 10 jaar lang die bruteforce aanvallen voorbij komen. Tot op heden is het nog nooit iemand gelukt. Ik zie de komende 10 jaar dan ook met een gerust hart tegemoet.
12-08-2010, 17:20 door ej__
Door SirDice: D'r zit al genoeg aan m'n sleutelbos. Daar hoef ik echt niet nog meer bij.

Bovendien staat het al zo'n 10 jaar zo en zie ik ook al 10 jaar lang die bruteforce aanvallen voorbij komen. Tot op heden is het nog nooit iemand gelukt. Ik zie de komende 10 jaar dan ook met een gerust hart tegemoet.

Daarnaast: vertrouw jij een willekeurige computer waar je je belangrijkste key in steekt, en dan nog het bijbehorende wachtwoord er bij typt ook? Redelijk dom. Dan is SirDice's methode beter. Alternatief kun je opie/skey oplossingen gebruiken.
12-08-2010, 17:36 door SirDice
Door ej__: Daarnaast: vertrouw jij een willekeurige computer waar je je belangrijkste key in steekt, en dan nog het bijbehorende wachtwoord er bij typt ook?
Ook niet geheel onbelangrijk inderdaad.
12-08-2010, 19:03 door soeperees
Gebruik gewoon een vreemde port voor ssh en je heb al veel minder last.
12-08-2010, 20:38 door ej__
Door soeperees: Gebruik gewoon een vreemde port voor ssh en je heb al veel minder last.
Deze briljante techniek staat bekend als 'security by obscurity'. Geweldige oplossing.
13-08-2010, 09:14 door Anoniem
Door ej__:
Door soeperees: Gebruik gewoon een vreemde port voor ssh en je heb al veel minder last.
Deze briljante techniek staat bekend als 'security by obscurity'. Geweldige oplossing.
Ja, dit is geen oplossing voor het probleem van brute-forcing an-sich... Maar aangezien het gros alleen op de default poorten hameren, zal dit je logfiles wel een stuk rustiger maken (en dus kleiner houden).

Als je echt per-se op die machine moet komen vanaf willekeurige, publieke, IP adressen is 'n port-knocker handiger om management poorten voor de buitenwereld gesloten te houden. :)
13-08-2010, 09:57 door Anoniem
ssh draaien op poort 443, met je private key inloggen, en geen root login op je ssh. Dan kunnen ze proberen wat ze willen maar met een 4kb private key hoop ik toch dat ze geduld genoeg hebben.

Het mooie van ssh op poort 443 draaien is dat het in praktisch elke "oude" firewall naar buiten toe openstaat. Dan kan je er ook nog eens vanuit bijna overal bij. Anders kan je ssh sessie nog verpakken in http headers om next gen firewalls te omzeilen.

En over degene die een honeypot wilde plaatsen. Wat er gebeurt als ze je wachtwoord hebben? scannertje + bruteforcer installeren en dan staat jouw server het zelfde te doen als die van hun, en er wordt waarschijnlijk een botje geinstalleerd. Ik raad dit overigens af als je xs4all hebt, want dan ben je binnen 2 uur afgesloten en dan kan je aan helpdesk uit gaan leggen dat je niet geinfecteerd bent. Want ze vragen om de logs van je virusscanner, of de door hun aanbevolen virusscanner, dat je weer "clean" bent. Voor je door die rompslomp heen bent ben je een dag verder = downtime.

--Mystic^
13-08-2010, 10:10 door soeperees
@ej__
Het gebruik van een andere port dan de standaard is geen 'security by obscurity'. Het is namelijk geen securitymaatregel. Iemand die binnen wil komen heeft met een portscan zo uitgevonden op welke port ssh draait.
Het is wel een eenvoudige manier om je logfiles schoon te houden van scriptkiddy-bruteforce-aanvallen.

Ik heb voor deze maatregel gekozen nadat ik zes jaar geleden zo veel mislukte inlogpogingen in mijn log had staan, dat mijn logfiles binnen een halfjaar meer dan een gigabyte groot waren.
13-08-2010, 10:12 door gelul
Door ej__:
Door soeperees: Gebruik gewoon een vreemde port voor ssh en je heb al veel minder last.
Deze briljante techniek staat bekend als 'security by obscurity'. Geweldige oplossing.

niet geweldig maar geautomatiseerde aanvallen hou je zo wel buiten de deur omdat die standaard naar port 22 gaan.
een port scan naar alle 65000 poorten duurt namelijk een eeuwigheid en zal alleeen gedaan worden als iemand specifiek jouw server op de korrel heeft.

en als je echt wil overdrijven kan je ip-whitelisting gebruiken in combinatie met portknocking, ip ban na x aantal mislukte pogingen en certificaten.

overigens enkel certificaten gebruiken raad ik ten stelligste af aangezien je bak dus wijd open ligt bij een 0-day exploit of een vergeten te draaien patch voor je ssh-server.
13-08-2010, 10:43 door Anoniem
Andere port draaien (houd de logs schoon)
Alleen via sleutel toestaan (en liefst ook met wachtwoord)
Directe root toegang verbieden (naar root via sudo/su)
En ook niet onbelangrijk, alleen SSH2 en hoger toestaan.
13-08-2010, 11:46 door Anoniem
Door gelul: overigens enkel certificaten gebruiken raad ik ten stelligste af aangezien je bak dus wijd open ligt bij een 0-day exploit of een vergeten te draaien patch voor je ssh-server.
Een lek in de certificaat-authenticatie verdwijnt echt niet als je ook met passwords aan kan loggen. Misschien bedoelde je dat je dan een fall-back tot je beschikking hebt tot de zero-day gepatcht is, maar als het om vergeten patches gaat dan snap ik niet waarom je advies iets oplost.
13-08-2010, 12:11 door rsterenb
Door Anoniem: En over degene die een honeypot wilde plaatsen. Wat er gebeurt als ze je wachtwoord hebben? scannertje + bruteforcer installeren en dan staat jouw server het zelfde te doen als die van hun, en er wordt waarschijnlijk een botje geinstalleerd. Ik raad dit overigens af als je xs4all hebt, want dan ben je binnen 2 uur afgesloten en dan kan je aan helpdesk uit gaan leggen dat je niet geinfecteerd bent. Want ze vragen om de logs van je virusscanner, of de door hun aanbevolen virusscanner, dat je weer "clean" bent. Voor je door die rompslomp heen bent ben je een dag verder = downtime

1. SSH wordt doorgaans niet op Windows systemen gebruikt; RDP is daar nuttiger. Volgens mij heeft XS4ALL alleen een aanbevolen virusscanner voor Windows, niet voor *nix en alles wat daarop lijkt. Dus wordt dat lastig overhandigen..
2. Afhankelijk van de drukte duurt het waarschijnlijk langer dan een dag voordat je weer up bent; zeker als er een weekend tussen zit. Maar, je kan iig nog via de proxy interneppen dus da's tenminste nog iets...
13-08-2010, 14:35 door Anoniem
Wat helpt: http://www.dennisbaaten.com/2008/11/20/alleen-nederlandse-ip-adressen/
Of gebruik http://denyhosts.sourceforge.net/

Een meer fundamentele oplossing is natuurlijk http://www.sshguard.net/ en gebruik van public/private key auth.
13-08-2010, 18:04 door SirDice
Door Anoniem: En over degene die een honeypot wilde plaatsen. Wat er gebeurt als ze je wachtwoord hebben? scannertje + bruteforcer installeren en dan staat jouw server het zelfde te doen als die van hun, en er wordt waarschijnlijk een botje geinstalleerd.
Ik stel voor dat je even de documentatie van die honeypot leest.
13-08-2010, 18:07 door SirDice
Door gelul: een port scan naar alle 65000 poorten duurt namelijk een eeuwigheid en zal alleeen gedaan worden als iemand specifiek jouw server op de korrel heeft.
Niet echt. Je vergeet dat die gasten alle tijd van de wereld hebben en dat het scannen voornamelijk geautomatiseerd gebeurd. Het maakt ze echt niks uit of die scan 10 minuten duurt of een week.
17-08-2010, 18:10 door Anoniem
fail2ban gebruiken, en een simpele regel erin die alle ip's die proberen in te loggen op een niet-bestaand account meteen x uur in de vuurmuur gooien is verbazingwekkend effectief. Het grapigge is dat meteen een andere node in het botnet het over probeert te nemen, en nadat die geblokked is weer de volgende, etc, etc :

^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$

Wat ook wel erg handig is, is een centrale syslog server opzetten voor al je systemen, en alles eruit filteren wat geen probleem is / wat bekend is. En het resultaat als een tail -f langs laten komen. Dit heeft al zo vaak ertoe geleid dat ik
de meeste vreemde problemen gevonden heb nog voor ze een echt probleem waren.. Zowieso ben je nadat je dit opgezet hebt, eerst een week bezig met het fixen van allemaal bugs waarvan je niet eens wist dat ze bestonden.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search