'Aantal gegijzelde MongoDB-databases stijgt snel'

Volgens beveiligingsonderzoekers Victor Gevers en Niall Merrigan stijgt het aantal gegijzelde MongoDB-databases snel. Het aantal steeg zondag tot 27.000, nadat het woensdag nog op 1800 werd geschat. Gevers zegt dat er in totaal bijna 100.000 onbeveiligde databases te vinden zijn.

In eerste instantie bleek uit onderzoek van de Nederlandse Gevers dat een persoon met de naam 'Harak1r1' verschillende onbeveiligde MongoDB-databases had gegijzeld door de inhoud ervan te vervangen en losgeld te vragen aan de eigenaren. Zij konden voor 0,2 bitcoin, momenteel ongeveer 170 euro, hun databases terugkrijgen. Inmiddels zijn verschillende groepen databases aan het gijzelen, zo blijkt uit een spreadsheet van Gevers en Merrigan. Gevers en Merrigan proberen slachtoffers te helpen en houden het aantal geholpen personen bij in hun overzicht.

Uit de spreadsheet is op te maken dat Harak1r1 inmiddels ongeveer 4300 slachtoffers heeft gemaakt, terwijl een andere persoon of groep met de naam 'kraken0' goed is voor ongeveer 15.500 slachtoffers. Deze vraagt een prijs van 1 bitcoin voor het terugzetten van de database, wat neerkomt op ongeveer 844 euro. De spreadsheet toont dat er in totaal vijftien groeperingen of personen MongoDB-databases gijzelen. Onderzoeker Merrigan liet zondag weten dat het aantal getroffen databases binnen een dag van 12.000 naar 27.000 was opgelopen.

MongoDB waarschuwde zijn gebruikers onlangs via een blogpost, waarin het verschillende beveiligingsmaatregelen omschrijft. Het raadt gebruikers aan hun logbestanden na te kijken en te controleren of er bijvoorbeeld nieuwe gebruikers zijn aangemaakt. De aanvallers vervangen meestal de bestaande databases en laten een eigen tabel achter met het bericht dat het slachtoffer tegen betaling zijn originele databases terug kan krijgen. In de standaardconfiguratie laat MongoDB bijvoorbeeld poort 27017 open staan, die eenvoudig op te sporen is.

Reacties (82)

[ayse]

Maarreh... volgens mij heeft het niets met web 2.0 te maken hoor. Ik maak prima applicaties met MySQL en ZF2/Symfony/Laravel etc. Het probleem is kennis.
Er wordt verwacht dat developers de altijd cutting edge technieken gebruiken maar de pay-off is het gemis aan diepgaande kennis.
Er komt zo ongeveer elke twee weken wel iets nieuws uit waarover ik als developer moet lezen en elke maand ongeveer iets waar ik me in moet verdiepen. Dat kan natuurlijk maar tot op zekere hoogte.
Ik moet meestal op een buikgevoel beslissen of ik een bepaalde 'nieuwe' techniek ga toepassen of niet. En als ik daar dan voor kies dan is het gevolg dat ik me in die nieuwe techniek moet specialiseren. Anders krijg je ... nou ja, dit dus.

[klakkie.57th]

hmmm ik begrijp je opmerking , al vraag ik me af of jullie developers je dit zelf niet opleggen.
Ik als sysadmin gruwel ervan om steeds maar nieuwe dingen te moeten implemeneteren die nog maar nauwelijks het Alpha-stadium zijn ontgroeid.
Developers besteden haast nooit aandacht aan privacy, security, backups, disaster recovery ..... het belangrijkste is dat het er leuk uitziet, en de laatste nieuwe, al dan niet volledig nutteloze snufjes gebruikt.
Er zullen best wel een heleboel developers zijn die het perfect voor mekaar hebben maar laten we stellen dat het nu niet echt hun core-business is ..

[ATS]

Meestal zijn het niet de developers die dat soort dingen willen, maar managers, marketingafdelingen, of nog erger, salesmensen die dingen verkopen die je (nog) niet hebt maar wel gisteren opgeleverd moet worden.

[harry89]

Managers willen
Developers googlen, zien mogelijkheden en zeggen dat het wel zou moeten kunnen
Systeembeheer moet het op een of andere manier weer zien te beheren/beveiligen/etc...

Er komt zo ongeveer elke twee weken wel iets nieuws uit waarover ik als developer moet lezen en elke maand ongeveer iets waar ik me in moet verdiepen. Dat kan natuurlijk maar tot op zekere hoogte. Ik moet meestal op een buikgevoel beslissen of ik een bepaalde 'nieuwe' techniek ga toepassen of niet. En als ik daar dan voor kies dan is het gevolg dat ik me in die nieuwe techniek moet specialiseren. Anders krijg je ... nou ja, dit dus.

Dit is een van de dooddoeners, de manier waarop je besluit of een nieuwe techniek doorgang krijgt of niet.
Het kan best goed gaan hoor, als developers enigszins samenwerken met systeembeheer en van te voren of bepaalde zaken überhaupt mogelijk zijn..... Maar ik zie vaak dat het developers en sysadmins twee verschillende eilanden zijn.

[EraYaN]

Of natuurlijk de zeer populaire besparingsmanier DevOps, dan werken ze ultiem samen!

[cappie]

Een gedeelte van het probleem ligt bij de developers die geen tegengas geven bij management en klakkeloos alle nieuwe technieken, nieuwe frameworks en pet-projects van bekende developers in productie omgevingen gaan inzetten, zonder dat er voldoende kennis is van bestaande producten (die in de meeste gevallen prima werken (en eigenlijk het bestaansrecht van 80% van alle nieuwe frameworks, technieken en pet-projects teniet doen)).

Een ander gedeelte van het probleem is dat de direct leidinggevenden van developers (team leads, project managers of sales) het ontbreekt aan kennis van modern development EN de wil om modernere technieken aan te nemen.

Je wilt niet weten hoevaak ik te maken heb met partijen die ik nog moet uitleggen wat Continuous Integration, Continuous Deployment, TDD, BDD of zelfs banale zaken zoals GIT, unit-testing of een OTAP straat is...

De "fuck it, we'll do it live" en "vallen en opstaan is beter dan eerst leren en voorkomen"-mentaliteit heerst vooral bij van die design bureautjes waar je alleen witte appeltjes ziet en hipsters die nog in 2007 leven met al hun lekke WordPress websites vol met brakke plugins of bij de talloze "e-commerce"-partijen die nog nooit van het concept 'deployment' in welke vorm dan ook gehoord hebben...

schrijnend, pijnlijk, beschamend.. helemaal in 2017..

[Verwijderd]

En ik vindt het kuddegedrag beschamend waarbij niemand zich meer kritisch afvraagt of al die zaken die je noemt wel de enige beste zijn methode is en de vorm niet belangrijker is geworden dan de inhoud.
Ik heb TDD projecten gezien met heel veel bugs en slecht geschreven testen, of waar meer dan de helft en kosten zit in her echrijven van die tests, terwijl de applicaties geen reet voorstellen. Continuous Delivery is voor heel veel services overkill. Wij gebruiken een eenvoudigere blue green deployment want zovaak hoeven en willen wij geen changes pushen. En we gebruiken Kanban aftreksel ipv Agile, waarbij we vooral alle vorm wegstrepen en ons richten op de inhoud, zoals veel bedrijven al deden voordat Agile en scrum een naam hadden en een religie zijn geworden.

Het zijn altijd kleine groepen en individuen die met nieuwe ideeën komen en de meerderheid sjokt er als gelovige achteraan. In de tijd van C/C++ developers werd het snel duidelijk wie de ambacht goed vaardig was en wie niet. Met higher level talen zou je minder bugs verwachten maar het probleem is dat het niet dezelfde programmeurs zijn als vroegah, maar de drempel enorm iş verlaagd waardoor ook slechte programmeurs zich ongemerkt onder de kudde voegt. Managers kunnen ze niet goed uit elkaar halen dus ipv dat er beter wordt gecontroleerd bij de ingang worst er bijna meer geld gestoken in een QA fabriek dan de productie zelf.

Ik ben niet tegen die concepten en middelen, maar wel tegen de meute die er als gelovige achtwraanholt en geen kritische afweging maakt over hoofd- en bijzaken. Vorm is belangrijker dan de inhoud en ontwikkelaars zijn te gewend geworden om alles maar te gebruiken zonder dat ze het begrijpen (want dat is her doel van abstractie en higher level talen, in een ideale wereld waar die herbruikbare componenten bugvrij zijn).

Er worden te makkelijk afhankelijkheden gecreëerd met tientallen 3rd party libraries waarvan de meesten voor slechts een deel worden gebruikt en makkelijk zelf ontwikkeld kunnen worden. Men vergeet bij 'gemak' en technische voordelen te snel de langetwermijngevolgen voor continuïteit. 2x is mijn werkgever failliet gegaan aan afhankelijkheden met derden, zoals MongoDB en bugs in libraries van derden. En we deden alles volgens de hype van de dag.

Alle methodieken zijn geen ultieme religie en vervanging van het gezonde verstand. Alles heeft voor en nadelen, en die balans zal per geval verschillen. We worden steeds meer robots ipv creatieve wezens, programmeren wordt van ambacht tot productiewerk, althans, dat is wat managers willen, aan paar knopjes draaien om productie te maximaliseren. Die wens is vanzelfsprekend maar de praktijk is anders. QA loopt achter op instroom slechte programmeurs die niet meer weten hoe een computer werkt.

En dat heeft gevolgen voor de werkelijke kosten zoals CO2 uitstoot (energieverbruik) van de oplossingen, die grotendeels onzichtbaar blijven. Gewoon simpel houden, geen onnodige toeters en bellen, nieuwe manifest toevoegen aan Agile waarin minimalisme meer de nadruk moet krijgen, en drempel voor het maken van afhankelijkheden met derden tot een minimum moeten worden beperkt en voorkomen indien niet strict noodzakelijk.

Continuous delivery is vaak niet strikt noodzakelijk en dingen doen omdat het cool modern is of omdat iedereen het doet, is het ergste wat je kunt doen. Ook andere afwegingen maken.

Veel problemen die ik heb gezien in mijn carrière als developer en later manager is dat het misgaat wanneer je binnen een commercieel bedrijf de technische mensen teveel de strategie laat bepalen. Dan krijg je vanzelf dat hoofd en bijzaken scheef gaan lopen en de oplossingen technisch complex worden omdat ontwikkelaars zich blind staren op zaken die ze leuk vinden. Managers moeten daar vaak in meegaan om de nerds happy te houden.

[cappie]

Je bent het toch wel met me eens dat je niet onder unit tests, een vorm van versiebeheer, een OTAP straat en een vorm van automated deployment uit kunt tegenwoordig, of wel?

[MoonWatcher]

Tja, ik verbaas mij al jaren over alle web 2.0 technieken. Vrijwel alle technieken die nu core geworden zijn zoals solr, elasticsearch, varnish, mongodb, couchdb en redis zijn allemaal ontwikkeld zonder enige poging tot veiligheid. De enige manier waarop deze technieken enigsinds veilig te gebruiken zijn, is door gebruik te maken van virtuele netwerken waarbij al deze diensten alleen in een interne netwerk range draaien of door een strak firewall beleid.

[Dreamvoid]

Nog groter probleem is dat met de opkomst van BYOD je eigen netwerk ook niet veilig is, je zal elk device op je bedrijfsnetwerk individueel moeten harden met firewall en whitelist, en devices die dat niet kunnen (printers, security cameras, etc) in een speciaal subnet met firewalled router ervoor.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 20:47]

[Verwijderd]

Ahh , en daarom moet je je network niet meer beveiligen maar je endpoints.

Zodra data een device verlaat weet je niet in welke staat het aankomt op een ander device. Ook al zet je er firewall, DPI of wat dan ook tussen je moet zorgen dat de endpoints veilig zijn. In dit geval een server met een database. Deze zou alleen door het frontend benaderbaar moeten zijn en voor maintenance alleen een JEA (Just enough admin ) en JIT ( Just in time Admin) shell. Ow nee wacht dat vinden Admins alleen maar lasting.

Hej en nu zijn ineens al die problemen opgelost totdat een admin account compromised wordt maar daar hebben we 2factor auth en ATA ( advanced thread analytics ) services voor.

[Wim-Bart]

En dan nog heb je admins die op hun BYOD als Enterprise Admin op het interne netwerk inloggen.... Maar tja, mij overkomt het niet is de mentaliteit.

[Verwijderd]

dan rommelt er wat aan jouw enterprise admin procedure.

[Wim-Bart]

dan rommelt er wat aan jouw enterprise admin procedure.

Dat bedoel ik dus ook....

[Zwerver]

Dat is wel redelijk onzin natuurlijk. Elke zichzelf respecterende organisatie die BYOD toestaat, zal ook een soort van beveiligingslayer toepassen op die devices. Denk aan MobileIron, Mobile Security of minimaal via Configuration manager. Daarnaast is het best practice om devices die gevoelig zijn voor hacks (printers, security camera's, etc.) sowieso onder te brengen in een apart subnet.

[Dreamvoid]

Dat is misschien 'best practice' maar in de praktijk is dat erg zeldzaam.

[diekli]

Ik denk dat in een nabije toekomst er geen sprake meer zal zijn van subnets, of interne netwerken, zoals die de afgelopen 20 jaar ontworpen zijn.
Alle devices gebruiken (via het Internet, denk aan IPv6 via 5G) applicaties die of in de Cloud staan, of nog gehost worden in een Data Center (niet bereikbaar via MPLS/WAN etc).

Device Security zal key zijn bij IOT, en ook applicatie/data ontsluiting, maar het netwerk volledig open.

[Aetje]

Tja, dat is de afweging die een organisatie moet maken: Staan we systemen op het bedrijfsnetwerk toe die niet door het bedrijf zijn uitgeleverd (inclusief verbinden via VPN)? Zo ja, dan kun je je eigen LAN niet meer vertrouwen en heeft een firewall tussen je netwerk en het internet weinig zin meer. Dan moet je elke end node, inclusief die BYOD apparaten (die van je servers gebruik gaan maken), gaan beveiligen tegen misbruik.

Persoonlijk zou ik als security-minded beheerder zeggen: Nnnnnope. Hier is een guest VLAN dat gescheiden blijft van het bedrijfsnetwerk (liefst fysiek zelfs), hier is een Citrix portaal waar je je apps in een virtual machine krijgt. Kan je BYOD geen Citrix client ondersteunen? Dan is ie niet geschikt voor gebruik.

[Verwijderd]

byod? bring your own device?

[Dreamvoid]

Precies - je laat daarmee de zombies zelf binnen. Het heeft weinig zin om je servers van de boze buitenwereld te harden, als Harrie van de administratie zijn prive zombie Android telefoon mee naar binnen neemt.

De admin van het botnet laat de telefoon het lokale netwerk scannen, en logt vanuit het 'veilige' LAN in op je database server, en encrypt de boel, wist de logs, en niemand komt er ooit achter hoe de aanval is verlopen.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 20:47]

[Wim-Bart]

En dat is dan ook 1 van de redenen dat je een BYOD nooit moet toestaan als intern device. Zelfs niet op interne WiFi of interne Switches aansluiten. Sleutelwoord is sowieso 802.1x voor Interne devices en BYOD spul moet gewoon behandeld worden als zijnde gevaarlijke externe devices, dus altijd ontsloten worden op het netwerk buiten het bedrijf.

[Croga]

Volgens mij ben je dan gewoon struisvogel aan het spelen....
In feite zeg je hier mee dat je non-BYOD devices altijd veilig zijn. Dat is simpelweg niet zo.

Zolang je geen end-point beveiliging toepast ben je op die manier nogsteeds kwetsbaar voor de apparaten die je vertrouwt. Zodra je wél end-point beveiliging toepast is er geen enkele reden meer om de BYOD devices appart te behandelen.

[Wim-Bart]

Nee, geen enkel en dpoint device is veilig, ook niet BYOD device is per definitie onveilig. Niet voor niets moet je met zonering werken waarbij backend, frontend en client systemen gescheiden zijn. Liefst nog door echte firewall devices en niet alleen door ACL's in switches. En daarnaast moeten de clients ook nog eens aan alle kanten goed dichtgetimmerd zijn. Liefst nog met iets als een ThinOS zoals Wyse. En wanneer je mobility ondersteund iets van een Citrix client in een Sandboxed VPN oplossing zodat bij een breach van de client er geen toegang is tot poorten, shares en andere interfaces.

[Dreamvoid]

Dat zeg ik niet, maar BYOD devices zijn sowieso een risico - als je die toestaat, dan moet je elk device gaan harden. Natuurlijk, ook zonder BYOD policies is het mogelijk om een bot in je bedrijfsnetwerk te krijgen, het wordt alleen een stuk moeilijker (en je kan er zelf iets aan doen).

Maar ik geef toe, het is makkelijk om vanuit een blanco vel te zeggen 'hoe het zou moeten', je moet in de praktijk binnen de beperkingen werken die je hebt - gebruikers die bepaalde functionaliteit willen, beheerders die niet perfect zijn, infrastructuur die niet onbeperkt duur mag zijn.

[SkiFan]

Ik vertrouw geen enkel device buiten de laptops van mn medewerkers, en zelfs die zijn we naar een eigen netwerk aan het schuiven.

Mobiele devices wil ik niet op mn interne netwerk, en devices van klanten en zzp'ers ook niet.

Mobiele devices kunnen op het gasten netwerk, wat alleen toegang tot bepaalde diensten en internet heeft. ZZP'ers idem, die hoeven alleen bij SharePoint.

[Croga]

Ik vertrouw geen enkel device buiten de laptops van mn medewerkers, en zelfs die zijn we naar een eigen netwerk aan het schuiven.

Waarom zou je de laptops van je eigen medewerkers vertrouwen? Die zijn minstens net zo kwetsbaar als een BYOD en daarmee dus net zo onbetrouwbaar.

[SkiFan]

Die hebben in ieder geval endpoint protection. Maar ook die vertrouw ik niet 100% en gaan dus naar een eigen netwerk.

[erwinb]

ik zou de eerste zin aanpassen naar:
Ik vertrouw geen enkel device.
dat is de start in een moderne omgeving.
je moet gewoon alle systemen blijven controlleren en logs relateren in een SIEM/SOC. Dat kan een eerste aanzet zijn tot security. Partijen als FOX-IT en NTT Security Services kunnen je daar heel goed bij helpen.

[SkiFan]

Erwin: Dat is ook de insteek, maar ook hier heb ik met 'altlasten' te maken, dat verander je niet overnight.

[Verwijderd]

Oneens. Systemen dienen aan de bron goed beveiligd te zijn. Het is een beetje een theoretisch antwoord, maar eigenlijk zou ieder systeem zo aan het internet gehangen moeten kunnen worden. Beveiliging zou niet moeten afhangen in welk netwerk het hangt of welke clients er toegang toe hebben.

[Dreamvoid]

Dat is de 'best practice' ja, maar in de praktijk willen de BYOD gebruikers wel toegang tot het interne netwerk en dat is dan ook wat er doorgaans gebeurt.

[erwinb]

Waarom zou je BYOD gebruikers toegang geven tot je netwerk? Als een gebruiker een iPad mee neemt naar kantoor om zijn werk te kunnen doen klopt het niet. Dan moet het kantoor voorzien in een dergelijk device.
BYOD zijn leuk maar het zijn vooral Own devices die buiten de security schil van een bedrijf thuis horen.
Bij ons op kantoor zitten de BYOD op een speciaal gast netwerk. Je kan lekker internetten enz. maar je kan niet bij de bedrijfs resources

[ninjazx9r98]

Het hele punt van byod is juist dat er gewerkt wordt met een eigen device. Dat eigen device wordt dus niet meegenomen om lekker te internetten maar om te werken en dan is er dus toegang nodig tot bedrijfsresources.

[Verwijderd]

Wat een krachtige taal en een hoop verwensingen.

De oorzaak van het probleem moet worden aangepakt en die oorzaak ligt bij de ontwikkelaars van IT producten. Zowel hard- als software. Als ik een apparaat of pakket koop, verwacht ik dat dit veilig is en dat niet zelf nog hoef te beveiligen. Ik bouw ook niet mijn eigen airbag in.

De mindset dat gebruikers van IT allemaal maar aan best practices moeten doen en veel kennis van zaken moeten hebben, is totaal verkeerd. Al jaren wordt er geprobeerd best practices aan te leren, maar dat is symptoom bestrijding, aangezien je iedere keer nieuwe aanwas van gebruikers hebt. Het probleem moet bij de bron worden aangepakt, hard- en software en IT infratructuur. Wat die oplossingen zijn, weet ik (nog) niet.

[Barreljan]

yes, bring your own device

[mhjmaas]

Er zitten juist wel uitgebreide beveiligingstechnieken in MongoDB, welke ook duidelijk in de documentatie staan. (https://docs.mongodb.com/manual/security/) Het voornaamste probleem is volgens mij dat wanneer je de installatie doet en je doet simpel "Next", "Next", "Finish" dat er dan niet standaard security aan staat. De mongoDB instance is dan ook alleen maar bereikbaar vanaf de localhost. De meesten zullen daarna toch met een bepaalde tool de database willen beheren en maken dan de instance bereikbaar vanaf buiten en als er dan nog geen security geconfigureerd hebt zijn de rapen gaar.

Op een productie omgeving (of eigenlijk elke omgeving) zou simpelweg altijd security geconfigureerd moeten zijn.

Wellicht is het een idee voor MongoDB om standaard in de eerste startup een wizard te bouwen welke je helpt om direct een setup te doen met security.

[Wim-Bart]

[...]
Wellicht is het een idee voor MongoDB om standaard in de eerste startup een wizard te bouwen welke je helpt om direct een setup te doen met security.

Het zou zo moeten zijn dat standaard de boel pot dicht zit. Met een uniek gegenereeerd wachtwoord en alleen vanaf een localhost te benaderen is. Het zou zo moeten zijn dat je keihard je best moet doen om uberhaubt toegang te krijgen via het netwerk.

[hackerhater]

Standaard reageert ie alleen op localhost...........

[frickY]

Het zijn stuk voor stuk tools om applicaties te ondersteunen. Ze zouden überhaupt niet op publieke interfaces hoeven listenen en de meeste doen dat default ook niet.

Dat is een ander web2.0 probleem -- iedereen kan en doet het, en probleempjes worden met paardenmiddelen opgelost, zoals dan maar binden op 0.0.0.0 en firewalling is ook maar irritant.

[Verwijderd]

Eh... Varnish is juist gemaakt met veiligheid als een van de uitgangspunten.
Het laat eerder dingen -niet- door naar de webserver dan -wel-.

Ik gebruik het op een website van m'n startup bijv. om allerlei WordPress features van buitenaf af te schermen. Je kunt erg leuke dingen doen met redirects bijvoorbeeld.

[xzaz]

Wat kan ik doen met onze instances? Onze instances zijn alleen via localhost en 1 remote IP beschikbaar.

[Aaargh!]

Niet openzetten voor een remote (routeerbaar) IP. Zet een VPN op tussen de twee locaties en laat alleen toegang toe over het (niet-routeerbare) VPN IP van de andere machine.

[The Zep Man]

Niet openzetten voor een remote (routeerbaar) IP. Zet een VPN op tussen de twee locaties en laat alleen toegang toe over het (niet-routeerbare) VPN IP van de andere machine.

Wat de standaard zou moeten zijn voor alle 'interne' applicaties die het Internet gebruiken voor verbindingen tussen systemen.

Een VPN verbinding is een enkele laag in de beveiliging, maar wel essentieel. Je moet nog steeds de best practices toepassen m.b.t. de applicaties zelf (updates uitvoeren, veilige configuratie, etc.). Als de VPN beveiliging faalt, dan is de applicatie veilig door correcte instellingen. Als de applicatie een (hopelijk tijdelijke) kwetsbaarheid heeft, dan is deze niet vanaf buitenaf te exploiteren doordat de applicatie alleen via een VPN benaderd kan worden. Met meerdere lagen vangt men de zwakheden in de schakels af.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 20:47]

[xzaz]

Bedankt, heb er een issue voor aangemaakt met een link naar dit nieuwsbericht. Hoge Prio.

[passantr]

Kijk, da's toch mooi aan Tweakers

[Soliest]

kijk even in het linkje in het bericht:
https://www.mongodb.com/b...ck-that-ransoms-your-data

[Verwijderd]

RTFM: https://docs.mongodb.com/...ation/security-checklist/

[leuk_he]

Aangezien het zo vaak fout gaat is het duidelijk geen goede handleiding. Als ik er doorheen blader leest het als een programma, er staan links in , die weer verwijzen naar andere links.

Dit is geen checklist. Tenzij je al bekend bent met alle termen is daar niet doorheen te komen. b.v. dat je in /etc/mongod.conf, bind ip geen 0.0.0.0 moet zetten had gewoon in de chkecklist gekunt ipv naar bindip te verwijzen.

[Blokker_1999]

Dit lijkt mij wel degelijk een checklist. De titels zijn de puntjes die je moet configureren. Een checklist moet kort en bondig zijn en dat is deze lijst. Dat je daarna kan doorklikken om na te gaan hoe je alles in orde zetten maakt het net een goed startpunt.

Al zie ik er ook dingen in staan waarbij ik denk: dit zou toch elke admin moeten weten (zoals het beperken van interfaces en het afdwingen van degelijke authenticatie).

[Verwijderd]

Volgens mij zegt het meer over de professionele verantwoordelijkheid die niet genomen wordt. Als de handleiding niet duidelijk is en je hebt het vermoeden dat je je informatie niet goed kunt beveiligen, dan laat je de software in het uiterste geval links liggen. Je beroepen op: "het was onduidelijk", is gewoon onprofessioneel. Buiten de handleiding is er nog een overvloed aan kennis op sites als stackoverflow.

En wat betreft bind ip ben ik het niet met je eens, want standaard accepteert MongoDB alleen verbindingen vanaf localhost. Het is dus aangepast door iemand. Als je dat doet en je weet ook dat je geen authenticatie in je connectie string hebt en als je dan niet begrijpt wat daar de consequenties van zijn, dan is geen enkele handleiding duidelijk genoeg.

[Verwijderd]

Ik vind het verontrustend dat er staat: "Enable access control and specify the authentication mechanism"

Dat impliceert dat access control default 'uit' staat en dat is niet goed.

Maar goed, zo'n database hoort natuurlijk gewoon niet vanaf het internet benaderbaar te zijn.

[Verwijderd]

Dit is onderdeel van de manual. Als je niet verder wilt onderzoeken, dan moet je er ook gewoon niet aan beginnen. Als je dit als startpunt gaat gebruiken om met MongoDB te starten, dan slaat dat natuurlijk nergens op. Je kan daarom niet concluderen dat dit de reden is dat MongoDB’s zo slecht beveiligd zijn.

[Hawkysoft]

Ga je ook in een voertuig rijden waar je nog nooit iets over hebt gelezen of gezien? Lijkt me niet. Dus eerst studeren dan implementeren.

En voor iedereen die hier daadwerkelijk de sjaak door is. GG, well played. Nu mag je eerlijk naar je baas toe lopen om te bekennen dat je even snel iets wou implementeren zonder er enig effort in te steken.

[johnkeates]

Remote IP uitzetten.

[Verwijderd]

Ik begrip echt niet hoe er nou 100.000 databases gewoon via het internet bereikbaar zijn. Heeft niemand een firewall draaien of zo?

[Anonymoussaurus]

Ik vraag me af of SQL injecties of andere lekken door een firewall worden gezien als kwaadaardig..

[Verwijderd]

Met een firewall kom je hoe sowieso niet bij de database.

Tenzij een stomme programmeur weer rechtstreeks de invoer doorkwakt richting de database.

[Anonymoussaurus]

Wat dacht je van de lekken van firewalls waar de NSA van gebruik maakte? Die zijn gewoon te koop op internet hoor.

[RoestVrijStaal]

Natuurlijk kunnen de ontwikkelaars van MongoDB zelf ook iets aan doen.

Een klein moduletje dat pingt naar een status-server van MongoDB en als dat lukt dan dienst weigeren en de gebruiker op wijzen dat MongoDB niet op een van buitenaf toegangelijke server mag draaien.

Overigens is MongoDB's "waarschuwings-artikel" in de laatste alinea hier eerder reclame voor hun trainingen en services dan een hands-on voor hun gebruikers.

[Verwijderd]

Een klein moduletje dat pingt naar een status-server van MongoDB en als dat lukt dan dienst weigeren en de gebruiker op wijzen dat MongoDB niet op een van buitenaf toegangelijke server mag draaien.

Dit toont alleen aan dat de database server het internet op kan, maar wil niet zeggen dat de database publiek bereikbaar is vanaf het internet.

[Dreamvoid]

Het gevaar komt niet zozeer altijd van het internet, het gevaar kan ook van binnen het LAN komen.

[Verwijderd]

Natuurlijk, daarom wordt het ook aangeraden om databases in een apart VNet te draaien, waar geen directe access van allerlei cliënts op is.

[Hawkysoft]

Waarom moet mongodb dit doen? Waarom niet gewoon eerst instuderen voor het implementeren? Sorry hoor maar je hele comment is irrelevant.

[DYX]

Na het lezen hiervan was ik eigenlijk benieuwd van de definitie van 'onbeveiligd'. Dit kan in vele vormen, maar in het vorige bericht werd dit specifiek benoemd: "De meeste kwetsbare MongoDB-installaties komen voor op AWS-servers. Zij zijn vaak niet voorzien van een wachtwoord of maken gebruik van kwetsbare versies."

[r2504]

De vraag is tevens hoeveel mensen weten dat ze een MongoDB instance hebben draaien... bijvoorbeeld een Ubiquiti Unifi setup maakt ook gebruik van MongoDB (en ik moet eerlijk zijn dat ik daar de security ook nog niet van bekeken heb, al is niets per definitie zomaar bereikbaar vanaf het internet).

[pbuytels]

Dat vroeg ik me dus ook af want heb ook een aantal Unifi installaties draaien bij verschillende klanten.

Maar ik ga even op het ubiquiti forum kijken of daar wellicht al wat vragen omtrent dit topic gesteld zijn.

[johnkeates]

Het lijkt vooral dat de opkomst van slechte hipster developers snel stijgt... geen enkele weldenkende developer gaat toch bewust onbeveiligde endpoints zomaar aan het internet knopen

[core_dump]

Dat is nou het mooie van open-source, hackers hoeven zo weinig moeite te doen om gaten te vinden..

En maar de mythe in stand houden dat "de community" meteen uit puur altruïsme de fouten er gratis uithaalt..

[sfranken]

Oh? Bij OSS is het zo dat als persoon of organisatie A een hack rapporteert een ontwikkelaar aan de andere kant van de wereld het kan dichten, de patch in kan dienen en binnen redelijke tijd (36 uur?) kan er een nieuwe versie zijn + documentatie.

Moet je bij closed source eens proberen... Oh, wacht, daar kun je geen source inzien en/of geen patch indienen.

[qless]

Dit is geen fout van de software of een lek of een gat. Als jij, als gebruiker, deze software installeert luistert deze alleen naar localhost. Als je dan zelf, als gebruiker, de config wijzigt zodat de server bereikbaar is via internet, maar geen gebruikersaccounts maakt en de toegang dichtzet, ben jij, de gebruiker, in fout.

[ayse]

Overigens kun je discussiëren over of de makers van de software in dit geval de gebruiker niet beter hadden moeten bescheramen.

[Reactie gewijzigd door ayse op 25 juli 2024 20:47]

[ayse]

Help me ff. Mongo is toch standaard alleen vanaf 127.0.0.1 toegankelijk? Althans de versie v3.4.1 die ik gister installeerde...

[Anonymoussaurus]

Ja, dus gewoon vanaf je localhost.

[ayse]

Dus als dat standaard is, hebben die 27.000+ developers de config gewijzigd?

[Anonymoussaurus]

Hoe bedoel je? Welke 27.000 developers bedoel je? Het aantal gehackte databases is 27.000. Vanuit buitenaf is het natuurlijk geen 127.0.0.1, want vanuit buitenaf is natuurlijk geen localhost meer (maar dat wist je denk ik al).

[ayse]

Haha, ik bedoel, de standaard listen is 127.0.0.1. Als ik mongo op mijn VPS vanaf de host probeer te benaderen met Compass lukt dat niet tenzij ik mongo naar andere adressen laat luisteren. Waarom zijn die 27.000 databases dan wel benaderbaar geweest? (Of gaat het om nosql injectie?)

[Reactie gewijzigd door ayse op 25 juli 2024 20:47]

[Anonymoussaurus]

Hmm.. Ik denk dat het gewoon een lek is waardoor je inderdaad met een SQL injectie vanuit buitenaf andermans databases kan inzien.

Zie hier voor meer info: nieuws: Aanvaller vraagt losgeld voor gekaapte onbeveiligde MongoDB-databases

[Rutix]

Nee juist niet. Waar Gevers specifiek op zoekt zijn servers die niet alleen luisteren naar 127.0.0.1 maar ook naar externe addressen.

On December 27, Gevers stumbled upon another MongoDB server that was left open to external connections and without a password on the admin account.

De gebruikers hebben dus zeker wel de config aangepast maar waarschijnlijk of de waarschuwingen niet gelezen onder het mom van "ik weet het toch wel beter" of gewoon ontwetendheid.

[Anonymoussaurus]

Dat kon ik niet uit de tekst halen. Dank je voor de verbetering.