Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 83 reacties
Submitter: himlims_

Onderzoekers van het Internet Storm Center waarschuwen voor een mogelijke toename in het aantal bruteforce-aanvallen op root-accounts via ssh. Sinds medio november zou er een duidelijke toename van het aantal aanvallen op poort 22 zijn.

"We hebben berichten gekregen over aanhoudende bruteforce-aanvallen op het root-account via ssh", aldus Guy Bruneau van ISC in een blogposting. "Dit is al ongeveer een week aan de gang vanaf verschillende ip-adressen. Ik heb ook soortgelijke activiteiten gezien op een van mijn servers sinds halverwege november."

Uit gegevens van Dshield.org blijkt dat er sinds 15 november een forse toename in het aantal aanvalspogingen op poort 22 wordt gerapporteerd. Dshield is een systeem dat wordt gevoed door firewall-logs die door beheerders vrijwillig worden gedeeld. Op basis van de data die wordt ingestuurd kunnen aanvalspatronen worden herkend.

De piek lag op 15 november, met bijna 130.000 gerapporteerde aanvalspogingen. Sindsdien is het aantal pogingen iets gedaald en schommelde het in de afgelopen dagen rond de 100.000. Ook bij Tweakers.net is een verhoogde activiteit waar te nemen. Sinds 6 november zijn er op een van de servers al 11.100 pogingen gedaan om als root in te loggen, afkomstig van 141 verschillende ip-adressen. Ook constateren we veel bruteforce-aanvallen met usernames. In de maand november waren dit ruim 57.500 pogingen.

Hoewel er in het verleden perioden zijn geweest met aanzienlijk meer aanvalspogingen op poort 22, is de stijging voor het ISC kennelijk opmerkelijk genoeg om er aandacht aan te besteden. De beveiligingsonderzoekers adviseren beheerders om niet via de standaardpoort naar een server te ssh'en en nooit als root in te loggen op een systeem, maar als reguliere gebruiker in te loggen en zonodig te sudo'en.

Activiteiten op poort 22, 5 nov tot 5 december / Dshield.org

Moderatie-faq Wijzig weergave

Reacties (83)

Installeer Denyhosts (http://denyhosts.sourceforge.net/) en/of fail2ban (http://www.fail2ban.org).

Denyhosts detecteert specifiek SSH-aanvallen (x mislukte pogingen) en blokeert dat IP-adres dan voor een tijdje via tcp-wrappers. Je hebt ook de mogelijkheid om dit te rapporteren en periodisch een lijst te krijgen van IP-adressen waar veel aanvallen vandaan komen.

Fail2ban detecteert naast bv SSH ook andere aanvallen (bv. IMAP) via scannen van de logfiles en neemt desgewenst actie (bv. tijdelijk blokkeren van het IP-adres via je firewall of een mailtje te sturen ivm een mogelijke aanval)/
scripts/programma's als denyhosts, fail2ban ed mee te laten lopen.
Is ook een aanrader. Of portknocking. ssh guard etc.
Het hier boven ook al genoemde, sneller gepost, denyhosts heeft/geeft ook de mogelijkheid om lijsten van gebande IP's te sharen. We all benefit.

Waar mogelijk ssh inloggen aan de 'binnenkant' als je zelf host. Een 2e nic op een intranet dat alleen via vpn te benaderen is. Vanaf bekende geautoriseerde IP adressen.

SELinux is ook een optie om het os verder te hardenen. Logs blijven monitoren.
Met bijvoorbeeld nagios. En back-uppen, snapshots maken enz.

[Reactie gewijzigd door pentode op 5 december 2011 11:46]

Er zijn meerdere manieren om te voorkomen dat je gehackt wordt:

- Permit root login op no in je ssh config
- SSH op een andere poort draaien
- Fail2ban
- Port knocking

Optie 1 is wat mij aangaat een verplichting en moet altijd gebruikt worden, ongeacht de verdere opties die je kiest. Zodra je als user ingelogd bent kun je een beperkte sudo opzetten, of via su - als je het wachtwoord weet - helemaal root worden.

Optie 2 is security trough obscurity, 1 portscan en ze weten waar je SSH wel openstaat. Niet aan beginnen dus, want dient practisch geen nut.
(http://www.youareanidiot.org/)

Optie 4 is prima voor thuisgebruik (er draait een daemon die je logs uitleest en op basis van regex een IP blockt in je firewall) maar niet echt useful voor productieomgevingen waar je niet maar zo iemand kan uitsluiten als die perongeluk een aantal keer het verkeerde wachtwoord opgeeft...
(http://en.gentoo-wiki.com/wiki/Fail2ban)

Optie 4 is ook prima te gebruiken voor productie-omgevingen, mensen kunnen pas connecten met SSH op het moment dat ze de juiste knock sequence uitvoeren.
(http://en.gentoo-wiki.com/wiki/Port_Knocking)

[Reactie gewijzigd door _eXistenZ_ op 5 december 2011 12:45]

Een andere oplossing is 2-factor authentication mbv Google Authenticator:
http://www.mnxsolutions.c...google-authenticator.html

voorlopig hou ik het nog bij DenyHosts, maar ga dit zeker onderzoeken..
Ik heb een aantal Linux servers en merk dat ook, er wordt constant geprobeerd in te loggen. Nu heb ik wel sterke passwords en public key authenticatie maar ik draai SSH tegenwoordig op een altenatieve poort daardoor, sindsdien wordt er nooit meer geprobeerd :)
De poort veranderen is inderdaad een snelle fix die goed werkt in de praktijk. Je kunt vrijwel geheel van deze aanvallen af komen door:
- Een alternatieve poort te gebruiken
- DenyHosts te gebruiken, die blockt IP adressen na 5 of 10 pogingen voor een week of voor altijd. Vergeet niet je eigen IP's toe te voegen aan /etc/hosts.allow zodat je zelf altijd kan blijven inloggen.
- Root login uitzetten in de sshd configuratie

Met deze drie "fixes" heb ik op geen een server meer last van brute force SSH aanvallen.
Een vrijwel onfeilbaar systeem is port knocking: je kunt niet zien dat deze 'beveiliging' aan staat (en je kunt niet zien dat SSH uberhaubt beschikbaar is op een server) en een goed ingebouwde is enkel te kraken door iemand die inlogt direct af te luisteren. Als je het helemaal goed doet (encrypted port knocking heet dat geloof ik) heb je een volledige extra beveiligingslaag. Voor de simpele versie heb je enkel 3 extra iptables regeltjes nodig. Helaas is de client-ondersteuning ervoor maar magertjes, maar als je toch al via de commandoregel SSHed kun je er prima een scriptje voor schrijven.

Ik ben er heel blij mee :)

[Reactie gewijzigd door ktf op 5 december 2011 11:43]

Zowieso de root login uitzetten in de config, maar volgens mij is de beste oplossing gewoon een paar trusted IP's in iptables zetten en de rest gewoon laten denken dat er niets te vinden is (oftewel rejecten)
Stealthen is nog beter dan rejecten en kost ook minder resources, ik weet niet of dat ook kan voor niet trusted ip's? De verbindende computer moet dan wachten op een timeout, het helpt ook onnodig verkeer tegen te gaan ook al is het misschien niet schokkend, alle beetjes helpen. En inderdaad is root inlog over internet ten alle tijden beter om uit te zetten als je echt perse overal root nodig hebt gebruik dan een degelijke goed afgeschermde vpn oid.
Zo doen we het op mijn werk ook
Alleen de trusted IP's krijgen doorgang naar SSHD. De rest wordt op firewall-niveau gedropt. Het lijkt dus net alsof er geen SSH draait
Je kunt dit ook oplossen door het volgende:

Zet "permitrootlogin" op "no" in "/etc/ssh/sshd_config". Daarna log je in met een eigen gebruikersnaam en wachtwoord. Om dan weer root toegang te bemachtigen typ je "su root -l", nu vul je je root wachtwoord in en zit je op het root account (zonder elke keer sudo ervoor te hoeven typen).

Werkt handig, daarnaast kun je ook nog SSH op een andere poort laten draaien (zie ook /etc/ssh/sshd_config) om vrijwel veilig te zijn voor brute force attacks, want ze hebben a) je gebruikersnaam nodig (zie dit als een extra "wachtwoord") b) je wachtwoord en om ook nog root toegang te krijgen c) je root wachtwoord.
Probeer eens 'fail2ban', gewoon installeren via apt-get...

Het monitort je ssh logs (auth.log) voor failed login attempts, en zodra dat er meer zijn dan 3 (of zo - zelf in te stellen) voegt het een regel toe aan de iptables configuratie voor het IP adres waarvandaan de poging kwam. Na 10 minuten wordt de regel weer weggehaald.

Ik gebruik het zelf al een tijd op alle servers die rechtstreeks op het internet staan aangesloten, en het heeft me toch een boel problemen gescheeld. Zelfs als mocht root een default of standaard wachtwoord gebruiken, dan nog duurt het te lang om dat te raden door de 10 minuten break na 3 pogingen.
De increase in aanvallen was mij ook al opgevallen, mogelijk botnets want het komt van veel verschillende ip-adressen. Wordt ook moe van de DirectAdmin messages, krijg constant waarschuwingen van "brute force attack on root" terwijl die mensen na 3 pogingen gebanned worden, DirectAdmin telt echter alle pogingen vanuit verschillende adressen bij elkaar op...

Fail2Ban ziet er interessant uit, ik run nu een Perl-script wat iets vergelijkbaars doet echter die doet alleen ssh. Zo te zien werkt fail2ban ook wanneer er op andere protocollen een aanval is.
Type, als je root gebruikt, type ook eens

faillog -u root

om te kijken of er uberhaupt mislukte root-loginpogingen zijn geweest...
Ja ga op een andere poort zitten. 'security by obscurity' heel slim NOT!

Deze hack probeert het misschien nu niet maar als er een portscan gedaan word dan is het direct weer duidelijk waar je SSH poort op zit en begint het spel weer van voor af aan.
Tegen de overvloed aan scripted scans is het toch weer een extra maatregel die je kan nemen.
Wel dus. Het is heel makkelijk om 'security by obscurity' te roepen, maar als je met zo'n maatregel het aantal hackpogingen flink kan verminderen, dan is de kans kleiner dat je gehackt wordt en is het dus een valide maatregel.

[Reactie gewijzigd door Zcuu op 5 december 2011 11:36]

Nou... Stel je bent scriptkiddie. Je hebt een beperkte hoeveelheid resources, en je wilt zoveel mogelijk ssh servers 'bruteforcen'. Ga je dan op ieder IP adres een poortscan doen over alle poorten, of kijk je of poort 22 openstaat en zo niet naar het volgende IP?

Er staan genoeg ssh poorten open. Dus waarom moeilijk doen? En nog iets, als iemand een ssh server draait op een alternatieve poort, heeft hij zeker over veiligheid nagedacht. Dus minder kans dat eenvoudige passwoorden werken.
Ben jij er een die even een term heeft gehoord of ben je je daadwerkelijk bewust van wat je zegt?

Het gebruiken van een andere port kan wel degelijk effectief zijn omdat je jezelf buiten het scripted gebeuren haalt. Dat is al een dreiging minder.
Enkel een andere poort gebruiken is niet wat hier wordt aangeraden, dat zou enkel security by obscurity zijn.
Je zult wel degelijk ook die alternatieve poort voldoende op slot moeten zetten.
Grootste reden dat ik ook een alternatieve poort gebruik is om er minder last van te hebben, niet vanwege security, want dat bied het totaal niet.
Die scripted handel resulteerde in logs van de activiteit en bans. Leuk dat ik kan zien dat mijn beveiliging werkt, maar een constante activiteit daar kan ik wel zonder. Voor mijn privé server is et voor mij prima om een andere poort te gebruiken.
En dan doe ik het trouwens alleen voor de buitenwereld, want intern gaat het wel over poort 22.

[Reactie gewijzigd door Ultraman op 5 december 2011 11:26]

Dit gaat niet om "obscurity" het gaat om het buiten houden van kansloze maar irritante en log vullende pogingen.

Het veranderen van de poort is als en een inbrekers alarm signaal lampje op je auto. Het zal de echte dief niet stoppen maar voorkomt dat iedere gelegensheid dief je alarm doet afgaan.

Hoe minder log entries hoe makkelijker het is te zien of er nieuwe en meer bedreigende pogingen worden gedaan.

Als mijn log volstaat met roor/root pogingen dan zie ik de pogingen die WEL een risico zijn niet meer. Als je de bomen omkapt, dan kun je het bos weer zien... oh wacht. Eh, iets anders dan.
Offtopic: als je een bosbeheer doet (enkele bomen omkappen om de rest te laten groeien) is meer op zijn plaats

On-topic: poort verleggen is een (mijn inziens) goede oplossing om inderdaad scripts tegen te gaan, verdere beveiliging is dan nog steeds nodig.
maar als er een portscan gedaan word
...is dat meestal op 'geprivilegeerde poorten' 1-10 000. Oa standaard in nmap.

Dus als je slim bent draai je je SSH op een 'ongeprivilegeerde poort' boven 10 000, dan moet degene die de poortscan doet hem handmatig ook boven de 10 000 laten scannen (tot 65 535), en dat kost héél veel tijd. Probeer het eens, zou ik zeggen.

Zoiets kost zomaar twee minuten per IP-adres, terwijl 'gewoon poort 22' proberen misschien maar 3 seconden duurt. Maw: Als iedereen een willekeurige poort boven de 10 000 zou kiezen, zou een 'inbreker' in dezelfde tijd 60x minder inbraak pogingen kunnen doen.

Waarom heb je een slot op je fiets, omdat die dan niet meer gestolen kan worden? Meestal gaat het er toch om, om ervoor te zorgen dat het dusdanig veel moeite / tijd kost dat een inbreker het opgeeft.
heel leuk, maar gewoon ook geen 'root' access via ssh toelaten.
"De beveiligingsonderzoekers adviseren beheerders om niet via de standaardpoort naar een server te ssh'en"

Hoe moet je dat soort mensen nu serieus nemen?
Security by obscurity is zo not-done.

Remote inloggen als root disabelen (wat ze bedoelen maar niet zeggen, het alleen niet gebruiken helpt natuurlijk niet) is uiteraard verstandig. Verder moet je natuurlijk er voor zorgen dat gebruikers met sudo-rechten een sterk wachtwoord hebben. (de rest ook maar als dat echte "gebruikers" zijn is dat misschien lastig)

[Reactie gewijzigd door martijnve op 5 december 2011 10:53]

En hoe draagt obscurity niet bij aan security? Ik ben het met je eens dat het niet je enige veiligheidsmatregel moet zijn, maar het is zeer zeker wel een extra beveiliging.

Vergelijk het met het schilderen van een tank in camouflagekleuren, het draagt niet bij een het stoppen van een kogel, maar het voegt wel obscurity toe.

Dus nee, ik ben het totaal oneens met je. Security by obscurity is echt wel done, en het voegt zeker iets toe aan de algehele security.
Je hebt er zelf meer last van dan de hacker, jij moet er met allerlei tools dagelijks in, en hoeveel moeite is het voor die hacker om één keer een portscan te draaien?
Daarbij is het absoluut nergens voor nodig als de rest van je beveiliging in orde is (wat toch zo moet zijn obscurity of niet).

Iedere hacker die achter port 22 geen SSH vindt zal een portscan draaien en de echte port in no-time vinden. Het vertraagt de hacker misschien een paar minuten, maar maakt de boel echt niet veiliger. Ik mag hopen dat iemand die te dom/lui is om een portscan te draaien toch nooit voorbij je echte beveiliging was gekomen.

[Reactie gewijzigd door martijnve op 5 december 2011 11:26]

Ik zou je sowieso niet willen aanraden om die poorten dagelijks te gebruiken. Je zet er gewoon een paar op, op bijvoorbeeld poort 20583 en op een andere server op 22492 (niet iets dat op 22 eindigt ;)). Die gebruik je alleen in noodgevallen. De rest van je ssh's maak je dan alleen intern bereikbaar dmv een vpn, of een aantal extern via een whitelist;

Noodgevallen zijn dan:
- als je je vpn even niet bij de hand hebt
- of als je ergens zit waar je ip niet in de whitelist staat
SSH is by-design gewoon veilig. Het aan de buitenwereld gewoon open hebben staan is alleen onveilig als je slechte wachtwoorden hebt. Voor VPN gaat precies hetzelfde verhaaltje op dus dat helpt ook maar minmaal.

[Reactie gewijzigd door martijnve op 5 december 2011 11:36]

Als ik mijn thuis servertje hier op kantoor in putty ingesteld heb op een andere port dan hoef ik alleen maar te dubbelklikken om in te loggen thuis. Kost me dus totaal geen extra moeite.

Aangezien er dus mensen zijn die te dom/lui zijn om een portscan te draaien, of gewoon een ip reeks op port 22 aan het scannen zijn en andere porten toevoegen dus te lang gaat duren ben je dus zeker wel ietsje veiliger.

Maar zoals hieronder ook al gezegt, ssh is veilig, je moet alleen wel een goed password hebben.

/edit, oeps, zoals hierboven en jijzelf het al zegt :P

[Reactie gewijzigd door PiepPiep op 5 december 2011 13:58]

Security by obscurity is zo not-done.
Jup. Ik gebruik echter wel tarpit voor mijn ip-tables firewall. Op die manier lijkt iedere poort open te staan, al is dat niet het geval.

Daarnaast heb ik ook anti-portscan, anti-brute force en beveiliging tegen dingen zoals x-mas pakketjes.

Als je mijn ssh server probeerd te brute forcen lig je er al na 3x een uur uit. Dan stuurt mijn server gewoon "desination unreachable" pakketjes terug :+

Natuurlijk heb ik ook een dik wachtwoord van >25 karakters 8-)
"Natuurlijk heb ik ook een dik wachtwoord van >25 karakters"

Is de paswoord hash ook zo lang dan?
"De beveiligingsonderzoekers adviseren beheerders om niet via de standaardpoort naar een server te ssh'en"

Hoe moet je dat soort mensen nu serieus nemen?
Security by obscurity is zo not-done.
Tja, maar hoeveel aanvallers zullen eerst een poortscan uitvoeren om te zien waar ze naar kunnen ssh'en? Terwijl het merendeel SSH op poort 22 heeft?
Inderdaad, beveiligen is het zeker niet, maar je voorkomt er wel mee dat de eerste de beste scriptkid met een bruteforce scriptje gaat proberen in te loggen.
Waarom zou ik als systeembeheerder mijn tijd willen besteden om te voorkomen dat het iets minder makkelijk te maken voor een scritkiddie zijn tijd te verdoen aan een aanval die bij voorbaat kansloos is omdat het systeem gewoon goed beveiligd is?

[Reactie gewijzigd door martijnve op 5 december 2011 11:27]

Omdat een bulk aan mislukte pogingen:
1. resources kosten (al is het minimaal)
2. je log vervuilen (wat het uitzoeken van andere eventuele problemen weer langer laat duren)
Een paar regels in je iptables config en het probleem is al veel minder:
http://www.la-samhna.de/library/brutessh.html

Je kan ook in je externe firewall wel een regen opnemen dat er paar X nieuwe connecties per N minuten naar port 22 mogen van dezelfde IP. Natuurlijk kunnen ze dan iets van 5 pogingen doen per uur, maar dat maakt het zo langzaam dat bruteforcen weinig zin heeft (mits strong password).
Waarom zou je je voordeur op slot willen doen ..
Diverse howto's geven duidelijk aan dat je root login moet voorkomen en zowiezo je poort naar een hoge range moet aanpassen....
Wie gebruikt nog poort 22?

EDIT: kan je onder win echt niet je poort aanapssen? Ik kan me dat bijna niet voorstellen....

[Reactie gewijzigd door neeroeter op 5 december 2011 10:49]

Ik gebruik overal poort 22, poort nummer wijzigen is imho geen security.

Wij hebben Password auth overal uit staan, alles MOET dmv van key authentication gaan, een password brute-forcen zit er bij ons dus ook niet in.

Poortnummer veranderen is alleen maar irritant.
Inderdaad: draai je SSH op een niet-standaard poort en wil je net inloggen vanaf een netwerk waarop externe verbindingen op niet-standaard poorten gefirewalled worden... kun je dus mooi niet bij je server!

Opties als 'PermitRootLogin without-password' beschermen prima tegen dit soort aanvallen.
Het wijzigen van een poort is niet altijd mogelijk - niet door beperkingen aan de server kant, maar in mijn geval doordat er een socks server / proxy / firewall tussen staat. En die staat poort 22 wel toe, maar een andere (meer willekeurige) poort niet.

Daarbij, de security through obscurity principes werken niet - SSH mits goed geconfigureerd is goed.
Jij draait de webserver ook op poort 1204? :S

Sorry maar mensen die poorten gaan aanpassen omdat ze dan denken veilig te zijn snappen niets van beveiliging.
Beveiliging draait om kansberekening ... en met elke (extra) drempel kom je dichter bij 100% veilig.
Root staat standaard uit op OSX. Ook staat poort ssh standaard uit.
Als je alleen pub/priv key pairs als auth toestaat dan kan je toch prima root-logins toestaan?
Nee want dan vertrouw je erop dat je client computers veilig zijn. Maw geen keys "verliezen".
Als je client niet veilig is, ben je sowieso verloren. Ook als je via een ander account root wordt.

Als je bedoelt dat keys van je computer gestolen kunnen worden: daarom versleutel je ze met een passphrase i.c.m. een SSH agent.

[Reactie gewijzigd door Sfynx op 5 december 2011 11:59]

Je kunt niet voorkomen dat de eindgebruiker voor het gemak het wachtwoord van zijn private key haalt. Dat blijft dus een kwestie van vertrouwen.
Beste optie is nog key authentication + user authentication op de server. Zo werkt ik nu met OpenVPN. Client heeft dus keys nodig (net als bij ssh) maar moet zich ook nog aanmelden bij de server (AD in mijn geval).
En ja, fail2ban draait bij mij ook, puur om de logs schoon te houden :-)
Zelf gebruik ik port knocking icm IP whitelists en moet zeggen dat het zeer goed bevalt.
Port knocking is erg tof maar het is wel veiligheid door obscuriteit als iemand op het zelfde netwerk zit kan hij vrij makkelijk je portknocking afluisteren en heb je er weinig aan.
Het is ongeveer net zoveel veiliger als je poort veranderen. Het helpt tegen de meute aanvallers die het niet persoonlijk op jou gemunt hebben, maar zodra er 1 is die perse bij jou wil binnen komen is het redelijk gemakkelijk te omzeilen.

Edit
sorry ik zit net weer ff over port knocking te lezen (was al weer een tijd geleden) en ik zie dat je ook encrypted knock kunt uitvoeren en dan wordt het afluisteren ook weer heel erg lastig.
Hmmm ik moet me maar weer eens in gaan lezen.

[Reactie gewijzigd door kaaas op 5 december 2011 11:46]

En bovendien psad en fwsnort.
Worden deze bruteforce aanvallen ook door botnetten gedaan? Of zit hier een ander principe achter?
Ja, vaak zijn het inderdaad botnetten die deze bruteforce aanvallen doen. Ze scannen hele ip-ranges af en als ze ergens een reagerende server hebben gevonden, zullen ze vaak een aantal gebruikers proberen met een aantal wachtwoorden en zo kijken of ze in kunnen loggen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True