Nederlandse webhoster Alfahost meldt poging tot inbraak op systemen

Nederlandse webhoster Alfahost waarschuwt gebruikers voor een mogelijke hackpoging. De provider heeft uit voorzorg de wachtwoorden van gebruikers gereset en doet momenteel onderzoek naar het incident. Het is niet duidelijk of de hackpoging is geslaagd.

In een e-mail aan gebruikers meldt Alfahost dat het bedrijf een potentieel beveiligingsrisico heeft gevonden in zijn hostingomgeving, zo blijkt uit een forumtopic op Gathering of Tweakers. "We hebben een poging tot inbraak in onze systemen geïdentificeerd. Op dit moment hebben we een onderzoek gestart en nemen we passende maatregelen om jouw data nog beter te beschermen", zo schrijft de provider. De website en de DirectAdmin-portal van Alfahost waren tijdelijk offline, maar lijken inmiddels weer te werken.

Alfahost heeft naar eigen zeggen de wachtwoorden van gebruikers uit voorzorg gereset. Gebruikers dienen vervolgens zelf een nieuw wachtwoord in te stellen om weer toegang tot hun accounts te krijgen. De provider geeft hiervoor instructies in zijn e-mail. Het bedrijf raadt gebruikers daarnaast aan om wachtwoorden van diensten waarbij hetzelfde wachtwoord wordt gebruikt ook aan te passen.

Het is niet duidelijk of de inbraakpoging op de systemen van het bedrijf daadwerkelijk is geslaagd. Tweakers heeft vragen uitstaan bij Alfahost, maar de provider heeft hierop nog niet gereageerd. Ook moederbedrijf TWS kon niets vertellen over het mogelijke beveiligingsincident. Tweakers zal dit artikel updaten wanneer er meer details bekend zijn.

Reacties (116)

[HKLM_]

De portal mijn.alfahost.nl is nog down. In deze portal doe je je bestellingen, beheer je de gegeven, pas je DNS aan etc. De website is er wel weer maar een product bestelling kan nog niet.

Tijdens de kerst was er ipv de website een wordpress setup te zien voor een korte periode. Pas vanaf maandag avond hebben ze alles plat gehaald en zijn ze (zichtbaar) aan het herstellen.

Ondanks dat direct admin het weer doet, is het extreem traag, en sql error dat items niet kunnen worden gevonden.

[Reactie gewijzigd door HKLM_ op 22 juli 2024 19:43]

[IPrange.net]

Ze zijn druk bezig met het herstellen van WHMCS. Inmiddels staat er weer een standaard installatie (http://mijn.alfahost.nl/index.php) zonder template en logo's. Ik hoop voor ze dat er geen klantgegevens zijn gelekt.

[Reactie gewijzigd door IPrange.net op 22 juli 2024 19:43]

[Q]

Die site werkt niet (meer) en op https:// zie ik een self-signed certificaat.

[IPrange.net]

Klopt. Volgens mij zijn ze opnieuw begonnen. Ze hadden de laatste versie van WHMCS geïnstalleerd met een oude DB backup van versie 7.7.1 dat gaat niet werken. Ze zullen eerst de juiste versie moeten downloaden voordat ze naar de laatste kunnen.

[HKLM_]

Ik heb alleen niet het idee dat ze er 24/7 aan werken.... aangezien ze bijna 5 dagen verder zijn. Zodra ze weer up zijn move ik per direct alles weg. Ook de communicatie over wat de verwachtingen zijn kunnen een stuk beter.

[Reactie gewijzigd door HKLM_ op 22 juli 2024 19:43]

[boyette]

klopt er zijn alleen wijzigingen tussen 0900 en 1700
maar alle vitale functies zijn hersteld en er is support voor klanten.dus dat kan. niets mis mee voor een low budget provider

[HKLM_]

Hoezo zijn alle functies hersteld? Je kan nog steeds geen DNS records wijzigen, of verhuistokens aanvragen.

Support is echt ver te zoeken hoor.

[Reactie gewijzigd door HKLM_ op 22 juli 2024 19:43]

[boyette]

Dit is een low budget provider met zeer beperkte support.
Vanwege de actuele situatie is er een nieuw ticket systeem gestart.
Ook is er telefonische support op verzoek beschikbaar.

dat met die DNS records was volgens mij van te voren ook al.
En heeft helemaal niets met het huidige incident te maken.

[Reactie gewijzigd door boyette op 22 juli 2024 19:43]

[HKLM_]

Dat het low budget is weet ik en normaal is dat prima ook voor support. Nu heb je alleen een speciale situatie en dan kan je low budget zijn dan werk je gewoon kei en kei hard om functies weer beschikbaar te maken.

Direct Admin geeft bij mij SQL fouten, DNS is noet beschikbaar, Verhuistokens kunnen niet worden afgegeven low budget of niet de basis werkt niet eens.

Als ik op werk een dergelijke (crash) zou hebben zou ik en mijn collega ook 24\7 werken om onze klanten te fixen hoe low budget je ook bent.

[Reactie gewijzigd door HKLM_ op 22 juli 2024 19:43]

[boyette]

24/7 dat past totaal niet bij het servicelevel wat je normaal gesproken kunt verwachten.
Dat ze dit binnen een paar dagen weer redelijk onder controle hebben lijkt me gewoon prima.

Een paar weken zou normaal in een dergelijke situatie bij een absoluut low budget product.

[FreshMaker]

24/7 dat past totaal niet bij het servicelevel wat je normaal gesproken kunt verwachten.
Dat ze dit binnen een paar dagen weer redelijk onder controle hebben lijkt me gewoon prima.

Een paar weken zou normaal in een dergelijke situatie bij een absoluut low budget product.

Volgens mij moet je onderscheid maken tussen hetgeen je aanbied ( de lowbudget hosting) en de bedrijfsprocessen.
Dat je klantvragen en de daaruit vloeiende werkzaamheden op een laag pitje zet, is dan te verwachten.
Maar dat je je eigen infra ook met low budget aanpakt, lijkt me geen goede oplossing.

Wat @HKLM_ aangeeft, hoe low budget het ook is, je dienst ( bedrijf ) moet door, nu wordt het meer een hobbyproject, en kan je je kleine omgeving als klant misschien net iets beter elders gaan wegzetten.

[cricque]

Een bedrijf zal altijd kijken om te besparen, en als alles werkt met een low bidge5 oplossing, waarom niet ? Als je moest weten wat er achter sommige saas apps steekt, zou je nog grote ogen trekken

[IPrange.net]

Dat kan ik me voorstellen. Ik hoop voor de klanten dat men laat weten wat er is gebeurd (wat er gehackt is). En dat ze dit melden bij de AP (volgens de AVG).

[Q]

Jouw omschrijving van wat er is gebeurd klinkt in mijn oren alsof ze dus gewoon gehacked zijn maar dat niet willen toegeven.

[Zebby]

Zolang ze het niet zeker weten, waarom zouden ze dan mogelijke misinformatie uitgeven? Vind het niet gek dat ze focus houden op herstel en analyse voordat ze zeggen dat er lekken zijn die er misschien helemaal niet zijn.

[Q]

Als je een omgeving van scratch opnieuw aan het opbouwen bent - een zeer kostbare operatie - doe je dat niet zonder hele goede redenen. Maar we wachten het wel af, het maakt ook verder niet uit.

[Accretion]

Ze hebben gewoon alles gewiped bij de eerste indicatie van een hack.

Heel slim, dan kun je alleen maar zeggen: "we denken dat er een hack was".

En kan onderzoek verder ook niks opleveren

[FreshMaker]

Ze hebben gewoon alles gewiped bij de eerste indicatie van een hack.

Heel slim, dan kun je alleen maar zeggen: "we denken dat er een hack was".

En kan onderzoek verder ook niks opleveren

Je geeft jezelf dan een onzekere toekomst.
Zouden er persoonsgegevens opduiken, kan de boete zomaar enorm veel hoger uitvallen

[SPee]

Misschien hun backup of systeem configuraties niet goed op orde?
Als je alleen van de db een backup maakt en niet van configuratiebestanden (etc.) dan kun je bij sommige producten vrijwel opnieuw beginnen.

[HKLM_]

Ik schijf alleen wat mijn bevindingen als klant zijn van de afgelopen vijf dagen Ieder voor zich om daar conclusies uit te trekken haha

[Reactie gewijzigd door HKLM_ op 22 juli 2024 19:43]

[StefanJanssen]

Het bedrijf raadt gebruikers daarnaast aan om wachtwoorden van diensten waarbij hetzelfde wachtwoord wordt gebruikt ook aan te passen.

Worden de wachtwoorden bij hun dan niet gesalt?

[Bender]

Hackers kunnen wachtwoorden van klanten ook gereset hebben, waardoor ze alsnog in kunnen loggen.
Een extra reset daarna is daardoor raadzaam.

[boyette]

that makes sense.. ik had al een tijdje het idee dat er super admin access was op direct admin.

dat zou idd de enige reden zijn waarom je die wachtwoorden zou willen resetten.
alle ww van alle e-mailadressen van alle domeinen zijn nml ook gereset

[Ventieldopje]

Als ze als MD5 worden opgeslagen bijvoorbeeld maakt dat weinig meer uit

[ilaurensnl]

MD5 is een hash; met een salt heb je een eigen wachtwoord (phrase) om zo de gegevens beter te beschermen.

[Ventieldopje]

Ik weet wat MD5 is en wat salten doet, ik weet ook dat MD5 gewoon geen veilige hashing methode meer is om te gebruiken. Het is erg snel en zonder hoge kosten te kraken.

[NoUser]

Zelfs kraken mag je het toch niet meer noemen ?
Er zijn immers al precompiled rainbow tables te verkrijgen.

[BlueSpirit]

Wel beter, maar puur MD5 is zo snel te kraken, dat een beperkte salt (lees 4 tekens) op een wachtwoord van 6-8 tekens niet direct een hele nuttige toevoeging is voor de grotere "kraak initiatieven". Dit omdat er niet aan de "cost" gedacht word bij "enkel" md5.

[Icekiller2k6]

Als ze op de login page een script toevoegen dan heb je niets aan het feit dat database wachtwoorden beveiligd zijn.
Encryptie gebeurd aan server kant, dus voor je het door je hash algo gooit kun je het nog zien.

[Raymond Deen]

Hash kan ook gewoon door de client berekend worden hoor; kan me zelfs wel voorstellen dat dat vaak gebeurt omdat dat weer een beetje processortijd -en dus geld- scheelt op de server. Het is bovendien veiliger omdat het wachtwoord niet over de lijn gaat.

[Argantonis]

Dit is complete onzin, als je het wachtwoord al client-side hashed dan IS die hash gewoon je feitelijke wachtwoord en voegt dat helemaal geen beveiliging toe.

[Pinkys Brain]

Helpt niet voor de desbetreffende website, maar hergebruikte wachtwoorden zijn dan een veel kleiner probleem. Dit had daarom 20 jaar terug al in de http standaard moeten zitten.

[Icekiller2k6]

Dat kan, maar is standaard niet gedaan... enigste voorbeeld dat ik me zo voor de geest kan halen is Mega.

[aikebah]

Leuk gedacht, maar wel misgedacht. Als je client-side hasht dan is de hash van je password voor het authenticatie-mechanisme je password.
Aan username en hash heb je dan voldoende om in te loggen.

[Blokker_1999]

Salt maakt het moeilijker, niet onmogelijk. Is sowieso aan te raden nooit wachtwoorden te hergebruiken. Gebruik een goede wachtwoordmanager en unieke wachtwoorden per site.

[init6]

Dit, en websites moeten toch echt eens een keer over gaan op 2FA

[RoestVrijStaal]

2FA voor je inlog bij een webhoster?

Afhankelijk wat voor dienst je gebruikt en op welke schaal (hobby of werk), vind ik 2FA best overkill in deze situatie.

Een iets snellere win voor Alfahost zou zijn om per nieuwe login met een ander ip-adres de gebruiker een mail versturen dat er is ingelogd met een tot dan toe onbekend ip-adres voor die gebruiker.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 19:43]

[BlueSpirit]

2FA overkill? Je kan gewoon een app op je telefoon als 2FA gebruiken. Dat is simpel en goedkoop te implementeren en dan is er geen risico voor misbruik van deze domeinen etc door kwaadwillenden.

[RoestVrijStaal]

2FA met een app is nog erger.

Wat als je smartphone gejat, of hardwarematig/softwarematig "kapot" is? Juist, dan kun je niet meer bij je account

[lilmonkey]

Onzin, daar zijn backup-codes en/of backup-factoren voor.

[RoestVrijStaal]

En waar laat je die backup dan?

Het is een verplaatsing van het probleem, geen oplossing.

Ik heb ongeveer hetzelfde meegemaakt als wat BeosBeing zei in een ander artikel.

In mijn geval was het herstellen van accounts met 2FA-met-een-app zoveel gedoe (bij één geval moest ik zelfs een selfie maken met ID kaart en al) dat 2FA-met-een-app voor mij heeft afgedaan.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 19:43]

[DerDee]

Je legt het probleem van 1 website bij het idee MFA/2FA. Als je een authenticatie app gebruikt en verlies ervan je ID moet opsturen is in theorie veilig, maar er zijn vele eenvoudigere methodes. Kijk naar Google, die bieden legio aan mogelijkheden. Het voorbeeld van BeosBeing is dan ook het slechtste dat er bestaat.
Google -> 1. Telefoon 2. sms/bellen 3. vragenlijst 4. backupcodes. Als je daar niet meer in je account komt is de vraag of het wel echt je account is wat mij betreft.

Sites die niet goed omgaan met je inlog gegevens moet je gewoon geen gebruik van maken. Makkelijkste voorbeeld is als ze mijn wachtwoord terugmailen. Dat werd vroeger vaak gedaan, daarom altijd registreren met een internet bekend wachtwoord, daarna aanpassen in een van mijn password manager als ik het niet via de mail terugkrijg. Zo wel account verwijderen en nooit meer op die site komen. Zo geldt het ook voor vage 2FA methode, simpelweg proberen account te verwijderen en aangeven dat je 2FA methode niet ok vind. Bij mij lopen al mijn 2FA via microsoft authenticator en authy, dat zijn gevestigde jongens met prima backup oplossingen.

[Onoffon]

Als sites de 1e keer je WW mailen betekent niet automatisch dat ze je wachtwoord niet salted/encrypted opslaan bij het aanmaken ervan.

Je moet je pas zorgen gaan maken als ze je wachtwoord plain text mailen met de 'wachtwoord vergeten' functionaliteit. Maar ik heb dit al een aantal jaar niet meer gezien/gehoord.

[DerDee]

In theorie is dat zo inderdaad, bij het aanmaken van een account kan gelijk de mail worden getriggerd met het plain wachtwoord doorgegeven. Of je dit moet willen is ook maar de vraag, maar het was idd niet direct onveilig. 99% van de sites die je wachtwoord terugmailde stond het eigenlijk ook plain in database, dat was mijn ervaring, ook met vaker aanspreken van de webdevelopers. Gelukkig is dit iets dat we laatste jaren niet meer snel terug zien en was meer aangedragen als een ietwat extreem voorbeeld van een site waar je zo ver mogelijk uit de buurt wilt blijven als het gaat om je data en wachtwoorden veilig te houden.

Dat laatste is uiteraard helemaal zo, meest extreem luie developers die dat deden. Ook lang vasthouden aan enkel md5 hash was een groot probleem. Gelukkig is dat allemaal 10+ jaar terug dat dit echt problemen waren.

[StefanJanssen]

En waar laat je die backup dan?

Uitgeprint in een map met belangrijke documenten.

Inbrekers hebben er niets aan (want geen wachtwoord) en hackers kunnen er niet bij (want analoog in je huis). Alleen als jij specifiek getarget wordt zullen ze het kunnen gebruiken en als jij zo belangrijk werkt doet dat dat een risico is leg je het in een kluis, al dan niet bij een bank.

Maar jij en ik zullen niet bij die groep horen die specifiek getarget wordt door hackers.

[Blokker_1999]

• LastPass slaat het op op hun eigen servers, beschermd met encryptie waarvan enkel jij het sterke wachtwoord hoort te kennen.
• Microsoft Authenticator maakt regelmatig backups naar OneDrive
• Google Authenticator maakt regelmatig backups naar Google Drive
• KeePass (met plugin voor TOTP) maakt backups offline die je zelf kunt veilig stellen

Dat jij een slechte keuze hebt gemaakt en niet voor backups hebt gekozen kan je de techniek niet verwijten. Ik heb recent een nieuwe telefoon gekocht en was onmiddelijk weer vertrokken met de MS Authenticator die all mijn 2FA afhandelt.

[hawke84]

1password. Synced via iCloud bijvoorbeeld. Werkt al jaren top.

[!GN!T!ON]

Die zet je op een USB stick in de la, op je HDD op een computer thuis. Als je met apps gaat werken waar die backup érgens anders komt te staan waar je geen controle over hebt en dan dus foto's moet gaan opsturen e.d. dan ben je gewoon niet handig bezig...

Of nog beter, gebruik een yubikey of soortgelijk.

[Wim-Bart]

Recovery keys, backup van je key generator. Zo veel opties. Gebruik het al jaren en mijn Authenticator database is vanaf mijn Lumia 920, 935, 950, Lenovo Android en nu mijn Nokia 720 Android zonder enige issues meegekomen. En heeft zelfs een gecrashde telefoon (Lenovo) 7 overleeft.

[Blokker_1999]

Dus als jij je huissleutels verliest dan heb jij pech en ga je een nieuwe woning zoeken?

Het is een heel flauw excuus dat je daar opgeeft. De betere 2FA apps maken uit zichzelf backups, backuppen zichzelf naar de cloud of worden meegenomen in de standaard backup van je telefoon. Je telefoon vervangen is voldoende om weer vertrokken te zijn.

[ilaurensnl]

2FA is echt niet overkill; een webhost kan prive gegevens bevatten van gebruikers (website), eigen gegevens van bijvoorbeeld e-mail.

[RoestVrijStaal]

Goed lezen!

Ik zei al:

Afhankelijk wat voor dienst je gebruikt en op welke schaal (hobby of werk), (...)

[ilaurensnl]

Dan was ik je net voor; omdat dat er nog niet stond.
Maar zelfs als hobby project zou je niet willen dat iemand je content kan veranderen; emails verstuurd etc etc.

[logix147]

Opt-in/out, ik vind persoonlijk 2FA nergens overkill, kost me 2 tellen extra en niemand anders kan erop inloggen fijn idee.

[Blokker_1999]

Ik heb 2FA zelfs op mijn hobby projecten staan. Wanneer het aankomt op het beveiligen van je gegevens is het vandaag gewoon een must. Wachtwoorden alleen zijn achterhaald en onveilig. De toekomst is wachtwoordloos.

Als je toestaat dat iemand kan inloggen en gewoon een notificatie mail stuurt is het al te laat, want dan zit een aanvaller mogelijks al binnen. Wil je dat die gebruiker bevestigd door op een link in de mail te klikken (dan heb je trouwens ook gewoon 2FA, iets wat jij net niet wenst) dan moet je al zeker zijn dat om te beginnen de mailbox niet dezelfde login gegevens gebruikt maar het is ook nog eens veel langzamer dan in een authenticator app te bevestigen of een code over te nemen uit die app.

[Wim-Bart]

MFA overkill voor je admin omgeving? Waar je bijna nooit inlogt... Sorry maar dit is zeker een omgeving waar je MFA moet gebruiken.

[Wim-Bart]

Waar lees je nooit? En iedere admin interface waar je met admin rechten werkt hoort achter een MFA oplossing te zitten. Met een Authenticator of RSA key.

[Polderdijk]

Als er op een ander niveau is ingebroken is 2FA leuk, maar dit is dan niet ineens een magisch iets om inbraken tegen te houden.

Het kan wel helpen tegen random inlog pogingen in de hoop erdoor te komen. Maar zolang we niet weten hoe de hackers binnen zijn gekomen, weten we nog niks.

[logix147]

Als ik je mijn Steam wachtwoord en e-mail geef kom je niet veel verder zonder mijn guard... idem met mijn iCloud of mijn Authenticators. Volgens mij is heel de bedoeling van die 2FA dat je op/met een 2de device bevestigd dat jij ook jij bent...

Dan kan je dus wel wachtwoorden weten maar zonder die 2de factor kom je nergens.

[roooii]

Klopt, aan de voorkant houd het mensen tegen en als ik je dan mijn wachtwoord geef dan kun je nog steeds niet inloggen. Maar als er aan de achterkant wordt ingebroken dan beschermen 2fa of andere authenticators niet.

[DerDee]

Wat heb je nog aan gebruikersnamen en wachtwoorden als je al in de achterkant bent? Dit is enkel informatie die interessant is om op andere websites in te loggen, dan is 2FA wel degelijk een prima bescherming.

[logix147]

Je snapt het niet. Als je aan de voorkant 2 factoren nodig hebt en de dieven hebben alleen factor 1 hoe ver komen ze dan met dat wachtwoord?

Precies nergens, want de tweede factor ontbreekt. Sommige diensten vinden een ander IP al verdacht en mailen dan nog een code om te verifiëren. Als elke dienst 2FA zou aanbieden is wachtwoorden jatten zinloos want je komt er nergens mee in.

Als ze aan de achterkant inbreken zou men hoe dan ook niet zomaar aan je data zelf moeten kunnen, maar dat is een andere kwestie, men gaat meestal voor een snelle grab en dat zijn users en passwords om die op e-mail accounts enzo te proberen dan ben je dus wel binnen als dat lukt.

[kijkje]

Kan bijvoorbeeld ook zijn dat de hackers tijd hebben mee kunnen kijken met elke inlog request die binnen kwam, daar staat over algemeen het wachtwoord wel in. Zolang ze niet zeker weten wat er is gebeurd is dat veiligste advies.

[Pinkys Brain]

Als de front end een tijdje gehacked is geweest helpt dat niet.

Je moet een challenge/response PKI methode gebruiken om de login gegevens veilig te houden als de webserver gehacked is geweest (even aangenomen dat de login controle apart is en die server niet gehacked is). Niet noodzakelijk 2fa, kan ook met een client certificaat.

[zx9r_mario]

Whmcs?

[IPrange.net]

Whmcs?

De tool voor het automatiseren van hostingonderdelen. Zoals webhosting en domeinregistraties. Zie https://www.whmcs.com

[Reactie gewijzigd door IPrange.net op 22 juli 2024 19:43]

[Bender]

AlfaHost gebruikt WHMCS voor het klantenpaneel.
Maar het is me niet duidelijk wat de aanleiding van je vraag is.

[zx9r_mario]

De vraag is of Direct admin of whmcs getroffen is door de inbraakpoging.

[Bender]

Of de server, of een server beheertool, of een wachtwoord manager, of mailbox, etcetc.
In alle gevallen is het mogelijk een wachtwoord te raden als ze niet veilig genoeg zijn (en er geen zaken als firewalls goed voor ingericht zijn).

Op basis van deze informatie kan het vrijwel alles nog zijn.

[IPrange.net]

En als het WHMCS is dan worden DirectAdmin wachtwoorden daarin opgeslagen. Dus het is logisch dat ze die dan ook resetten.

Hun WHMCS is inderdaad stuk. Het enige wat nog werkt is de status pagina .

[Reactie gewijzigd door IPrange.net op 22 juli 2024 19:43]

[boyette]

maar die is niet gereset.
wel alle ww van alle e-mailadressen op alle domeinen zijn gereset en random gemaakt.

[Ninaomi]

Whmcs is opzich veilig

[michielonline]

Beetje rare titel, elke webhoster, sterker nog, elk publiek IP wordt dagelijks op gepoogd op in te breken (al dan niet op hele intelligente manieren), dat is geen nieuws. Als het gelukt is, dat is nieuws...
Feit dat ze wachtwoorden aan het resetten zijn geweest zegt genoeg lijkt me. "ff" de wachtwoorden van al je gebruikers aanpassen doe je niet zonder reden.

[Zomaareenmening]

Dat dacht ik ook al over die titel . check eens een gemiddeld log van een server ip. Gaat heel de dag door die inbraakpogingen. Via allerlei sniffers etc etc.

[PizZa_CalZone]

Letterlijk, ik was al driftig bezig, mentaal mijn verhaal een vorm te geven over dit punt.

Toen las ik jouw bericht, je haalt de woorden uit mn mond. Dit is duidelijk geen poging tot hacken. Dit is meer want anders is het geen nieuws.

Vraag het anders eens aan m'n fail2ban.

[Reactie gewijzigd door PizZa_CalZone op 22 juli 2024 19:43]

[padoempats]

Lijkt me dat er wel dagelijks pogingen zijn, al zijn het toevallig voorbij komende scans

[GieltjE]

Bij ons practisch elke seconde (gemiddeld), dan hebben we het bij lange na niet over de aantallen die een partij als deze host. Gelukkig goede detectie en automatische blokkade.

Neem aan dat ze zoiets melden er daadwerkelijk iets gebeurd is, anders kunnen ze bezig blijven.

[Oon]

Je hoeft maar een VPSje te hebben met een standaard setup en je krijgt al constant portscans en bruteforce pogingen. Tegenwoordig kun je gewoon niet meer zonder fail2ban en moet je echt zorgen dat plaintext SSH auth uitstaat, anders dan ben je de helft van je resources kwijt aan mislukte inlogpogingen.

[GieltjE]

Of beter ssh (of rdp als je die inclinatie hebt) alleen toestaan via een fatsoenlijke vpn.

[Tomaat]

Of alleen met public key en wachtwoordinlog uitzetten.

[Anoniem: 420148]

Niet "of", "en". Je hangt ook geen SSH-poort aan het internet. Authenticatiemethodes of wachtwoordsterkte is geen beveiliging tegen veiligheidsproblemen met de ssh-server. RDP werd laatst ook niet gehackt omdat iemand de wachtwoorden kon bruteforcen, maar omdat de RDP-server zelf kwetsbaar was.

[Oon]

Ik hang veel liever een SSH-poort aan het internet waarmee ik op een veilige manier (lees: private key met een passphrase) kan inloggen op mijn netwerk dan een RDP-server. Of je nu verbinding maakt met SSH of een gewone VPN maakt zo goed als geen verschil, beide ondersteunen het gebruik van keys en beide hebben de mogelijkheid om zelf aan te geven welke ciphers je toestaat.

Als je alleen verbinding maakt om op afstand bij één server te komen of specifiek voor SSH dan win je vrij weinig door daar een VPN tussen te zetten

[Anoniem: 420148]

Goed, je mag denken dat openssh-server onfeilbaar is, maar dat is het niet. Daar komt dan nog eens bij kijken dat de doorsnee thuishobbyist met z'n eigen Pi/NAS niets aan hardening of best practices doet en je hebt een recept om gepakt te worden. Er zitten niet voor niets miljoenen devices in botnets.

https://www.cvedetails.com/cve/CVE-2003-0786/
https://www.cvedetails.co...Openssh.html?vendor_id=97

Als je het verschil tussen een VPN en direct een server aan het internet hangen op de beheerpoort niet snapt, moet je er denk ik al niet aan beginnen om je devices aan het internet bloot te stellen.

[Reactie gewijzigd door Anoniem: 420148 op 22 juli 2024 19:43]

[Oon]

Maar je laat het nu klinken alsof er nooit CVE's gepubliceerd worden over VPN servers. Met de grote hoeveelheid VPN software en verschillende (hele slechte) tutorials op het internet is voor een leek die voor het eerst iets met Linux doet een VPN net zo gevaarlijk. Er is zeker wel verschil, maar met de juiste kennis is een SSH-server gewoon veilig op te zetten, en een VPN-server ook. Zonder die juiste kennis heb je altijd risico. Het is absoluut niet alsof het opzetten van een VPN met de standaardconfiguratie zomaar je SSH-server goed gaat beveiligen.

[Anoniem: 420148]

Verschil tussen een NAS/Pi/VM met SSH aan het internet hangen gelijk raakgeschoten is. Inbreken op een VPN-server geeft je niet automatisch toegang tot de resources binnen het netwerk. In het geval van een VPN-server moet je dus een CVE voor VPN en SSH tegelijk pakken.

[Oon]

Dan ga je er vanuit dat die SSH-server direct toegang heeft tot het verdere netwerk, wat helemaal niet zo hoeft te zijn. Als je SSH voor root helemaal uitschakelt, sudo alleen toestaat met een wachtwoord (dus twee factoren tot je bij root komt) met een user account dat verder geen toegang heeft behalve zijn eigen mapje/processen, dan dek je al een flinke attack vector af. Als je dan ook netjes zorgt dat die SSH-server geen directe verbinding heeft met andere servers (oftewel geen eigen private keys die toegang geven tot andere servers) en dat een SSH-tunnel niet is toegestaan, dan kunnen ze zo goed als niks met met die ene server behalve waar die user zelf bij kan op die server.

Het ligt er allemaal maar aan hoe het opgezet is

[MrMarcie]

Precies, en dat 'en' werkt goed.

[FreshMaker]

Zo hangt er in mijn netwerk een Pi die alleen dat doet, SSH / VPN acces bieden
op een nonstandard port ( obscurity ) kan ik me aanmelden via een ssh-tunnel, en dan mijn rdp's benaderen.
Bij voorkeur over Wireguard, maar niet overal en op elk systeem kan je dat zomaar inzetten, net zoals OpenVPN ook niet zomaar even "portable" te gebruiken is.

powershell + ssh is in veel gevallen gewoon te gebruiken.

[jjjeck]

security by obscurity is geen goed advies; poortscanners hebben dit zo door.

Ik hoop dat je naast je obscurity meer maatregelen heb getroffen (zoals eerder genoemde alleen inloggen via keys, fail2ban etc etc).

[FreshMaker]

Uiteraard, maar zo'n commentaar wordt oneindig lang, als ik ook al mijn config files en acceslogs elke keer moet plaatsen.

Aangepaste poorten helpt iets, net zoals ik voor direct acces ook Guacamole gebruik, en Remote-IT.

[HollowGamer]

Maar hoe neem je dan de VPS over? Naar mijn weten is SSH met keys (zonder direct root, luisteren op andere poort, fail2ban, allow-list, ..) gewoon veilig.

RDP hangt erg af van de versie. De meeste (zouden) zijn versleuteld en moeten werken met certificaten. Zelf hang ik hier wel graag eerst een VPN tussen.

[Anoniem: 420148]

Naar mijn weten is SSH met keys (zonder direct root, luisteren op andere poort, fail2ban, allow-list, ..) gewoon veilig.

Het is veilig totdat er een probleem met het protocol of openssh naar buiten komt. Zoals ik al zei, RDP werd op dezelfde manier gepakt. Niet omdat het makkelijk was om username+password te raden, maar omdat de server zelf een bug had. Dat betekent dus dat iemand potentieel zonder credentials (of dat nou wachtwoord of key is) binnen zou kunnen komen. Daarnaast wordt je hele log volgespamt door hackchinezen/russen die constant aan het bruteforcen zijn.

Als je een VPN voor RDP hangt, dan moet je dat ook voor SSH doen.

[beerse]

vpn, ssh, rdp... uiteindelijk is er een poort op je router dat open staat en reageert met het door jou daar ingestelde protocol. Dat protocol is in de meeste gevallen wel herkenbaar en de tegenpartij kan/zal daar langs proberen in te loggen of dat nu rdp, ssh, of om het eender welk vpn of tunnel protocol.

En daarna zal conform dat protocol geprobeerd worden toegang te krijgen.

Toegegeven, als je zelf protocollen gaat stapelen (rdp via een ssh-tunnel viia een vpn verbinding) wordt het wel 'lastig' om toegang te krijgen, Zeker als de tunnel protocollen via niet standaard poorten lopen.

[Blokker_1999]

Al passen hackers zich ook aan als ze merken dat er een fail2ban draait. Dan verspreiden ze de load onder al hun bots en krijg je 2 a 3 keer in korte tijd een poging van hetzelfde adres en daarna niet meer.

[Hakker]

Het is misschien security through obscurity maar ik hang mijn ssh ook niet aan de standard poort. Je wilt niet weten hoeveel dat al scheelt.

[FreshMaker]

@Oon

https://github.com/skeeto/endlessh

Leuk om een beetje te f**ken met die lui

https://www.youtube.com/watch?v=SKhKNUo6rJU

[Reactie gewijzigd door FreshMaker op 22 juli 2024 19:43]

[Oon]

Precies dat ja. Combineer dat met fail2ban of een vergelijkbaar stuk software en je kan in principe transparant iedere niet-bestaande gebruikersnaam, zoveelste poging vanaf een IP-adres of gewoon alle pogingen tot plaintext auth doorsturen naar een eindeloze stream.
Wanneer je zelf een probleem hebt met je key en doorgestuurd wordt naar plaintext auth kun je meteen cancellen, maar zoals in die video aangegeven doen veel bots dat niet.

[Hendrik53]

Even testen met https://internet.nl.

Zeer slechte score website: 45%. Geen DNSSEC, onvoldoende HTTPS, geen HTST enz.
En de e-mail is al niet veel beter: 48%
. Geen DMARC, oude TLS, geen DANE, en onveilige certificaat handtekeningen....

Voor beiden zou 80% toch zeker haalbaar moeten zijn.

[protected22]

Wel goed dat ze gelijk actie ondernemen en mensen hun passwords aanpassen/resetten.

[LiquidCrystal]

Op de site zelf onder het kopje "Nieuws & Aankondigingen" (link) wordt er niets gemeld over de problemen.

Sterker nog, het meest recente bericht is van 8 februari 2019!

[Yalopa]

Telkens ik dit soort replies lees bij een bericht over een hack denk ik, wat vind jij dat ze (hadden) moeten doen?

[Blubkens]

Gewoon iets toch? Vindt jij ook niet?

[HKLM_]

Hun website draait op wordpress zal me niks verbazen als het een niet ge-update versie was of een plug-in ofzo die verzuimd is te updaten.

[Blokker_1999]

Zelfs een site die volledig up to date is kan kwetsbaar zijn. Het duurt altijd enige tijd wanneer een nieuwe 0-day uitkomt en de patch beschikbaar komt.

[CyberMania]

Inderdaad of ze zijn simpelweg alleen een reseller.

[Reactie gewijzigd door CyberMania op 22 juli 2024 19:43]

[elparia]

Ze zijn geen reseller, wel maken ze gebruik van wat standaard zaken om snel een hoster te zijn.