Onderzoekers: veel MongoDB-databaseservers zijn publiek toegankelijk

Door een veelvoorkomende misconfiguratie van de populaire MongoDB zijn databases op tienduizenden ip-adressen probleemloos uit te lezen, zo stelt een aantal studenten van de Saarland Universiteit. Onder andere klantgegevens van een Frans telecombedrijf zijn op te vragen.

Volgens de studenten, die onderzoek doen naar cybersecurity, vergeten veel systeembeheerders een aantal veiligheidsmechanismes te activeren als zij de populaire opensource-database MongoDB installeren. Zo installeren veel Linux-distributies MongoDB standaard zo dat deze alleen op het lokale systeem is te benaderen en wordt er geen wachtwoord ingesteld. Als de database op een aparte server wordt geplaatst en in plaats van lokale toegang ook internettoegang wordt geactiveerd, zijn naast de webserver vaak ook MongoDB-databases via internet direct benaderbaar, zo stellen de onderzoekers.

In totaal wisten de studenten op 39.890 ip-adressen openstaande MongoDB-databases te lokaliseren. Veelal zijn deze met de juiste zoektermen via een zoekmachine gemakkelijk te vinden. Een van de kwetsbare databases zou in handen zijn van een Frans telecombedrijf. Klantgegevens als telefoonnummers en adressen van circa 8 miljoen Fransen waren vrij opvraagbaar. Ook kwamen de studenten veel databases tegen waarnaar ook geschreven kan worden. Ook een Duitse webwinkel 'lekte' klantgegevens, waaronder data over transacties. In beide gevallen werden de betrokken bedrijven gewaarschuwd over de verkeerde databaseconfiguratie.

Het Duitse Heise tekent aan dat niet alleen veel MongoDB-databases kwetsbaar zijn. Ook andere NoSQL-databases als Redis en de cachingsoftware Memcache zouden vaak incorrect zijn geconfigureerd waardoor data vanaf buiten ongewild is op te vragen.

Reacties (59)

[CathodioN]

Ik geloof dat een paar mensen het begrip open source niet helemaal begrepen....

Ongelofelijk zeg, dat dit soort dingen nog steeds gebeurt. Vroeger hielden we lijsten bij van publiekelijk toegangelijke FTP servers die we konden gebruiken voor file sharing (lees films). Maar dat dat nu min of meer nog steeds gebeurt verbaasd me echt.

[Reactie gewijzigd door CathodioN op 23 juli 2024 22:13]

[SlaSauS]

Het verbaast mij dat server bouwers default met dit soort onveilige configs shippen. De instelling van niet zomaar naar iedereen op het netwerk luisteren (127.0.0.1 ipv 0.0.0.0) is pas sinds vorig jaar met de release van MongoDB 2.6 standaard geworden. Schandalig dat het zo lang heeft moeten duren en er zoveel downloads zijn geweest die dus niet secure by default waren.

Los van het feit dat een sysadmin zijn server en firewal etc. netjes moet configureren en de docs moet lezen voor men dit soort software installeert vind ik het ook een verantwoordelijkheid van de makers van deze software om by default gewoon met secure instellingen te shippen. Fijn dat dat sinds 2.6 ook eindelijk bij MongoDB is doorgedrongen.

[remya]

Ik denk dat omdat de laatste tijd de NoSQL DB's steeds populairder worden er veel bedrijven zonder goede research er gebruik van zijn gaan maken. Dan krijg je inderdaad dit soort situaties.
Zeker omdat de database admins veelal alleen gewend zijn om met traditionele SQL databases te werken en security daar toch iets anders werkt.

[Verwijderd]

Security werkt daar eigenlijk hetzelfde bij, maar bij bijvoorbeeld MySQL zul je altijd bij installatie gevraagd worden om een root password in te stellen, terwijl dat bij CouchDB, Mongo etc niet bij installatie gevraagd wordt.

[sfranken]

En ook bij MySQL word door veel beheerders vergeten het e.e.a dicht te timmeren terwijl MySQL/MariaDB dat zo makkelijk maakt met "mysql_secure_installation"

[mxcreep]

Al zet je er helemaal geen root password op een database server hoort gewoon niet direct aan internet te hangen, in een apart vlan alleen bereikbaar via vpn oid.

[riotrick]

Veel webservers die aan het internet hangen worden natuurlijk vaak gebruitk om alles te: webserver, databaseserver, mailserver etc.
Dan hangt zo'n apparaat gewoon direct aan het internet. Hoeft helemaal geen probleem te zijn, een simpele firewall kan al een hoop ellende verhelpen. Daarnaast geldt natuurlijk dat je al je services afzonderlijk ook gewoon veilig wilt draaien.

[sfranken]

Mua, dan is het alleen de webserver (Apache) die verbindingen van buitenaf accepteert. Als jij Apache + MySQL hebt draaien dan accepteert MySQL alleen verbindingen vanaf "localhost", mits normaal ingesteld.

[rvl1980]

En hoe zie je voor je dat de klanten van bv al een middelgroot hostingbedrif , zeg 15.000 users, bij hun database server gaan komen.

Alles via webinterface? Alle klanten via vpn? In beide gevallen krijg je best wel ontevreden klanten... De kleinere klanten die geen flikker snappen van VPN, de grote klanten die (terecht) lopen te zeiken dat ze een directe koppeling willen en dat die webinterface zuigt...

[sfranken]

Dat is dan een andere configuratie dan de default, maar dat is ook gewoon in te stellen he. Waar ik het over had was dat niet alles zomaar open en bloot aan het net moet hangen. En als je dat dan toch doet beveilig je shizzzle dan door de basis handleidingen te lezen ;-)

[BCC]

Alles hangt tegenwoordig rechtstreeks aan het internet. Dat zie ik in de toekomst ook niet meer terug veranderen.

[RGAT]

Euh nee?...
Mijn router hangt aan het internet, alles erachter is niet zomaar van buitenaf te benaderen.
Dat sommige bedrijven hun webservers en databaseservers scheiden is goed, dat iemand dan lui is en de database volledig open gooit wat betreft beveiliging zodat de webserver zonder probleem erbij kan maakt zelfs nog niet dat de database aan het internet hangt

[sfranken]

Mua, het is wel handig als je webserver kan babbelen met je DB server. Dan volg je dus gewoon standaard protocol hiervoor, en timmer je alles wat je niet nodig hebt dicht. Ik heb meerdere DB servers aan het internet hangen, maar daar kom je niet bij zonder dat ik het wil/weet

[remya]

Zoals sfranken al zegt, is dit bij o.a. MySQL een stuk makkelijk en is er meer over op internet te vinden. Bij NoSQL db's is dat nog een stuk minder. Dit is wat ik ook bedoelde met research, er wordt gewoon simpel weg niet over na gedacht door de beheerders.

[Thystan]

Ja, of er wordt geen tijd/geld vrijgemaakt voor die beheerders om er over na te denken of er over te leren.

[Martinspire]

Dit heeft niets met research te maken. Dit is gewoon pure onkunde.

[riotrick]

Inderdaad. Maar komt helaas wel veel voor. Zeker als configuratie van servers gedaan wordt, die dat er een beetje bij doen. Bijvoorbeeld een webdeveloper die ook even snel een servertje neerhangt zonder de daarbij nodige kennis. Je ziet genoeg ellende aan het internet hangen.

[rvl1980]

Mwoa, als de gemiddelde router facbrikant een admin/1234 wachtwoord en WAN access aan zet is de wereld te klein. En aangezien developers van MongoDB alles (blijkbaar) zo noob-friendly-one-click-install willen maken, zou ik ze even verantwoordelijk houden als de case met de routerfabriekant.

Het klinkt leuk dat iemand die een mongodb opzet kennis van zaken moet hebben, maar dat hebben ze simpelweg gewoon niet. Dan kun je a) hoog en laag gaan springen dat ze dat echt moeten weten, of b) default shizzle regelen voor de onwetende klant.

Ik vind optie a) echt wel begrijpbaar en snap hem helemaal, maar je schiet er niks mee op want dan krijg je dus gewoon bovenstaande nieuwsartikelen, niet meer en niet minder. Het voed de massa onkundige gebruikers echt niet op.

[martijnve]

Wat heeft dit met open source te maken? MongoDB staat standaard open omdat ze vinden dat je het niet publiek aan het internet zou moeten hangen.

Als je het wel met een wachtwoord wilt beveiligen moet je dat zelf doen, veel mensen vergeten dat blijkbaar. Ik vind het zelf ook een beetje een vreemde keuze. Kunnen het beter default aan zetten en dat iemand die dat niet wil het uit kan zetten.

[Stackprotector]

En daarnaast accepteert MongoDB standaard connecties vanaf elke IP adressen en niet alleen localhost, dus mensen kunnen veel zeggen dat het een probleem is van de gebruiker maar MongoDB zelf kan er ook wat van.

Ik heb dit probleem trouwens een jaar geleden al aangekaart.

[Verwijderd]

Ergens heb je gelijk, dat zo'n standaard instelling niet echt zuivere koffie is, maar aan de andere kant het ook de taak van een developer / systeembeheerder om zich te verdiepen in de door hem gebruikte software.

Bijvoorbeeld Apache heeft ook standaard CGI aanstaan, waardoor een kwaadwillende code uit zou kunnen voeren. Prettig is het niet maar als sys-op zou je dit soort dingen toch na moeten lopen.

[riotrick]

Verschillende mensen / projecten hebben andere opvattingen over wat zij als standaard instelling aanbieden.
Ongeacht wat standaard gedaan is, ben je gewoon zelf verantwoordelijk om de services die je installeert/gebruikt goed te configureren.

[HollowGamer]

Het ligt eraan. Ik stel het luisteren op IP-adres uit en gebruik i.p.v. sockets.
Sockets schijnen namelijk sneller te zijn, maar nog een groot voordeel is dat deze alleen toegankelijk zijn voor bepaalde gebruikers. (E.g. je stelt de read/write.. en de user/group in).

Dit kan naar mijn weten voor (bijna) alle software: Redis, MySQL, memcached.. Het was allemaal 'zo' in te stellen.

Een groot nadeel: als je zit met meerdere systemen die je wilt samenvoegen. E.g. je hebt de database op een andere server staan.
Maar ook die kun je prima beveiligen op IP-basis. (Denk aan whitelists, etc.)

Trouwens worden deze services ook niet standaard afgeschermd door middel van poorten?
Ik zie nog weleens dat sommige het nodig vinden bijvoorbeeld MySQL poort (3306) open te zetten naar 'buiten'.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 22:13]

[MSalters]

IP loopt ook via sockets - ik neem aan dat je local sockets gebruikt. Dat is geen oplossing voor het probleem hier, want het gaat nu juist om situaties waarin de MongoDB op een andere server staat en dan werken local sockets per definitie niet.

En als je MongoDB wel lokaal gebruikt, dan is de standaard instelling (IP alleen vanaf 127.0.0.1) net zo veilig als die local sockets.

[Faeron]

Maar weinig ICT-ers bezitten de hackers-mindset. Ze hebben allemaal de engineers-mindset: zorgen dat het werkt en als het voldoet aan hetgeen gevraagd is, dan zijn we klaar. Er zijn er maar weinig die zich dan afvragen: "Kan naast het gevraagde ook een aantal ongevraagde zaken gedaan worden op hetgeen ik zojuist heb opgeleverd?" Wat ben je dan?

[Martinspire]

Mwoah, dit is niet zozeer iets voor de developers, als wel iets wat bij het testen gewoon ingebakken moet zitten. En laat nou juist daar ook de mindset "het werkt" geaccepteerd worden. Beveiliging moet ook getest worden, maar heeft vaak een lagere prioriteit

[Niemand_Anders]

Daar zit nou eigenlijk precies het hele probleem. Hoe werkt de gemiddelde programmeur? Website + database development op de eigen machine. Hoe wordt zo'n systeem meestal gedeployed? database + website op aparte machine waardoor er een totaal andere situatie ontstaat..

En ander probleem is dat enkele DocDB implementaties standaard op poort 80 draaien. Steeds meer DocDB veranderen dit momenteel naar port 8080 welke standaard op een firewall niet openstaat.

Maar DocDB's worden ook vaak op meerdere machines geinstalleerd om gebruik te maken van sharding en/of replication waardoor de database wel weer bereikbaar moet zijn voor andere nodes, maar niet voor de gehele wereld.

Systeembeheerder en developers leven vaak in aparte werelden en hebben ieder ook hun eigen taal. Als systeembeheer al bij een release wordt betrokken, dan is dit vaak helaas pas net voor de release.

Gelukkig is het wel zo dat steeds meer NoSQL producten met een http(s) interface tegenwoordig standaard een config meekrijgen waarmee zij alleen op localhost bereikbaar zijn.

Aan de andere kant, hoe lang hebben MysqlAdmin interfaces niet open en bloot aan het internet gehangen? Given enough time, history will repeat itself, only in a different context.

Relational databases zijn nu volwassen en security instellingen zijn nu conservatief. NoSQL implementaties zijn ook al jaren aanwezig, maar zijn nu ineens hot. Zo werd BerkeleyDB voorheen vooral als embedded db gebruikt, terwijl je deze nu ook steeds vaker met een http(s) interface tegenkomt. De database zelf kent geen beveiligings mechanismes omdat deze nooit bedoeld geweest is om extern benaderbaar te kunnen zijn. Beveiliging moet dus op de http(s) interface geregeld worden. Maar die zijn relatief nieuw en beveiliging is dan vaak nog niet helemaal uitgewerkt danwel gedocumenteerd.

Maar dan nog hebben we te maken met een ander issue en dat zijn de operating systems zelf. Elk OS welke ik ken wordt geleverd met een firewall, maar zowel onder Linux als Windows staat deze bij default verbindingen incoming connections toe. Anno 2015 is dat toch ook wel een verkeerde mindset?

[ToolkiT]

klopt, maar dat is niet alleen de schuld van de ICT-ers, maar vaak voornamelijk door druk van de gebruikers en onrealistische deadlines.. dan is 'het werkt' vaak belangrijker dan 'het is veilig'..
Kortzichtig maar wel hoe het in de praktijk vaak gaat..

[Verwijderd]

Klopt helaas wel

Ik werk zelf bij een klein bedrijf samen met nog een andere developer en naast development houd ik me ook bezig met serverbeheer omdat er niemand anders is om het op te pakken. Hierdoor is het best makkelijk om security issues over het hoofd te zien of te laten voor wat ze zijn als er heel veel werkdruk is.

Toen ik hier kwam werken kon je met een simpele SQL injection inloggen in vrijwel alle licenties van ons systeem, toen ik dat meldde werd er mij doodleuk verteld dat dit bekend was maar nog nooit iemand (dus geen van de vorige 6 programmeurs die aan het project gewerkt hadden) dit op had kunnen lossen.

[Verwijderd]

Ik verwachtte : Een verrekte Mongo(l)

[Verwijderd]

MongoDB ondersteunt wel authenticatie, maar dat moet je zelf activeren. Als je dat niet van stap 1 doet, dan loop je het risico dat gewoon over het hoofd te zien eens je installatie te groot wordt om enkel op localhost te draaien en je besluit om het op een andere server te zetten.

Ook in de documentatie en de tutorials van MongoDB zelf, wordt daar naar mijn mening te weining aandacht aan besteed. "Security is optional" is gewoon een totaal verkeerde mentaliteit.

Veel andere vergelijkbare producten schuiven beveiliging zelfs volledig van zich af. Wil je op een veilige manier een Solr of Elastic Search opzetten, dan moet je er maar een Nginx, Apache of andere proxy tussen zetten die de authenticatielaag voor zijn rekening neemt. Zoiets voegt een bijkomende laag aan compexiteit toe aan je setup, wat dan ook voor bijkomende problemen kan zorgen.

[Verwijderd]

Helemaal mee eens, authenticatie staat inderdaad standaard uit. Maar aan de andere kant ook wel te begrijpen, authenticatie kost overhead en een database zou met behulp van firewall regels alleen in het zelfde netwerk benaderd moeten worden (of via whitelisted IP adressen).

[Verwijderd]

Vanuit PHP verbinding maken (met username/password) naar een databank duurt hier lokaal op mijn toestel welgeteld 2 milliseconden, waarbij je dus ook nog de overhead van de TCP connectie moet aftrekken (die je bij die andere producten ook hebt). Zo'n grote overhead lijkt me dat dan toch niet hoor.

[aadje93]

de overhead zit hem niet in de tijd die het jou kost om de verbinding te maken, maar in de resources die het de cpu van apache/DB server kost om die authenticatie te verichten, daarom is zoals al meer gemeld de DB server (via vpn) in een lokaal Vlan zetten zonder authenticatie handiger. Bij hoge productiviteit merk je het verschil wel degelijk

[Delgul]

Als je een paar duizend verbindingen per seconde wil afhandelen dan gaat 2ms per verbinding toch wel tellen hoor! ;-)

[Martinspire]

Enerzijds is dit een manier om mensen snel en gemakkelijk kennis te laten maken met MongoDB. Installeren en toepassen in een simpele opdracht is zo makkelijk te doen.
Anderzijds moeten ze dit inderdaad duidelijker maken in de documentatie en desnoods een gemakkelijke manier bieden om de beveiliging te verhogen of van development naar test/productie over te zetten.
MongoDB moet het vooral hebben van zijn performance en minder van beveiliging. Dat moet iemand wel weten die het gaat implementeren. Op de frontpage staat ook niets over security en dat is toch wel iets wat een developer moet gaan opzoeken.

[kozue]

Ik vind juist helemaal niet dat ze applicaties als solr en ES nog complexer moeten maken door zaken te implementeren die anderen allang al veel beter doen dan wat ze zelf ooit zouden bouwen. Door een echte web server ervoor te hangen kun je gebruik maken van de veelzijdige configuratiemogelijkheden die deze services bieden. Voor een simpele firewall kun je ook uit de voeten met wat het OS meelevert (zoals iptables). Een halfbakken ingebouwde oplossing zoals een simpel ip filter of wachtwoord authenticatie heeft niemand wat aan.

[Riesch]

Klinkt wat mij betreft naar beheerders met een volgende volgende voltooien mentaliteit.

In het geval van *nix achtige systemen dien je altijd de config files te checken na het installeren (en al helemaal als je het door de OS installer laat installeren). Bij iets wat zo kritiek is als een server die direct aan het net hangt is dit al helemaal een must.

[svennd]

Zucht, met al die schoolse perfectionisme raak je nergens... na iedere installatie alle configs doorlezen en de volledige manual lezen is gewoon niet mogelijk. De tijd dat het kost om een systeem volledig uit te pluizen en compleet correct in te stellen kost zoveel tijd (=geld) dat een mogelijke breach gewoon goedkoper is.

Om dat risico toch zo klein mogelijk te maken, ga je er vanuit dat de default settings een aanvaardbare veiligheid geven. Wat hier dus duidelijk niet het geval is. Dus inplaats van als een "bende koeien" devs en systeem administrators als lui en dom uit te maken zouden de pijlen ook naar mongodb mogen gaan. MySQL bijvoorbeeld zal bij iedere login klagen als het een leeg root paswoord heeft. CentOS waarschuwt wanneer je als root inlogt, je hoort root user namelijk niet als "gewone" user te hanteren.

Lui devs/sysadmins zijn diegene die na dit nieuws hun systemen nog steeds niet hebben bekeken en/of beveiligt.

[Reactie gewijzigd door svennd op 23 juli 2024 22:13]

[DiedX]

Niet alleen maar de unices hoor. Dit moet gewoon default practice zijn, ook bij Windows OS-en.

[eborn]

Tja, als je uberhaubt alle traffic richting je machine klakkeloos accepteert, zonder er een firewall tussen te hangen, dan ben je ook niet echt slim bezig.

[Verwijderd]

Dit zeker ... meeste REST API's van deze server applicaties draaien op poorten die 'normaal' gesproken dicht zouden staan.

Maar vaak worden poorten maar open geslingerd omdat iemand het 'makkelijk' vind .. lees: te lui is om een VPN / SSH tunnel op te zetten.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:13]

[Verwijderd]

Dit bewijst maar weer dat de meeste beveiligingsproblemen te wijten zijn aan onwetende of luie systeembeheerders en developers.

edit : Trouwens niet alleen NoSQL databases, maar ook een heel groot aantal andere server applicaties, voornameijk die via een REST API aangesproken worden (zoals Solr en ElasticSearch) zijn, indien verkeerd geconfigureerd, vrij toegankelijk via het web.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:13]

[Martinspire]

Het is meestal niet verkeerd geconfigureerd maar juist NIET geconfigureerd. Dit is een instelling die je naderhand moet doen, omdat je eerst lokaal en in testomgeving aan het developen bent (de reden dat het volgens mij zo gemakkelijk benaderbaar is, omdat het in development gewoon handiger is). Daarna moet het live en zijn dergelijke aanpassingen nodig.

Ik vind het niet heel raar dat ze bij dit soort technieken kiezen voor een middel wat het makkelijker maakt voor het ontwikkelen. Dat is toch doorgaans het eerste wat je doet. Dat ze het uiteindelijk niet bij het testen vinden, vind ik kwalijker. Hoe goed is de rest dan getest.

En ja, het is onkunde wat de klok slaat.

[Reactie gewijzigd door Martinspire op 23 juli 2024 22:13]

[jj71]

Verbazingwekkend dat veel bedrijven nog steeds zo amateuristisch omgaan met security.

Van de IT-ers (programmeurs, beheerders en managers) bij die bedrijven mag je toch wel verwachten dat ze op z'n minst basiskennis hebben over security. Een database openlijk toegankelijk hebben via Internet betekent gewoon dat er mensen hebben zitten slapen en daar is geen goed excuus voor.

MongoDB zou ook kunnen meehelpen door standaard de security dicht te zetten en usernames en passwords verplicht te maken. Dan kan het alleen nog maar verprutst worden door iemand die opzettelijk de security uit zet. Maar zelfs al staat de security standaard uit, dan vind ik het nog in eerste instantie de verantwoordelijkheid van de IT-ers in het bedrijf die MongoDB gebruiken om ervoor te zorgen dat een database niet publiek toegankelijk is.

[chaoscontrol]

Heeft vooral te maken met segregation of duties, waardoor de sysadmin niet verantwoordelijk is voor de security en andersom.

[Verwijderd]

Iemand die zijn zaken goed op orde heeft kan vrijwel altijd prima uit de voeten met meer conventionele producten stapt niet zomaar over naar iets hips omdat het hip is.

Het is een gegeven dat bij nieuwe stromingen als NoSQL het minst gekwalificeerde volk als eerste overstapt. Zeg nou zelf hoeveel bedrijven hebben nu echt NoSQL nodig vanwege schaalbaarheid or een gedistribueerd systeem? Met een beetje extra kennis dan de meesten bezitten kun je gemakkelijk 10 tot 100 keer sneller werken in een relationele database dan men gewend is en soms zelfs heel veel meer dan dat.

Een telecom provider of een webshop zijn echt niet vergelijkbaar met Facebook of Google, die gebruik van dit soort producten zouden kunnen rechtvaardigen. Het is gewoon pure onkunde die er voor zorgt dat deze producten zoveel worden gebruikt. De gevolgen zijn vanzelfsprekend, de commentaren ook. Het punt is dat de beginkeuze voor NoSQL in eerste instantie al een verkeerde is en genomen door ongekwalificeerde volgers.

NoSQL staat ongetwijfeld leuk op een modern CV, maar geef mij maar een iemand die zich ontwikkeld in bewezen techniek en/of producten. Daar kun je namelijk veel beter op bouwen als je kwaliteit nastreeft!

Als iemand de basis en beperkingen van bewezen techniek niet beheert dan heeft die niets te zoeken in de meer extreme oplossingen die met compromissen en gedragingen komen die echt begrepen moeten worden om geen fouten te maken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:13]

[jj71]

Ok, maar het hele probleem gaat niet specifiek over NoSQL.

Het maakt niet uit wat voor software producten er worden gebruikt, je zou toch wel mogen verwachten dat IT-managers, ontwikkelaars en systeembeheerders nadenken over de security. Blijkbaar gebeurt dat in veel bedrijven helemaal niet.

[Verwijderd]

Dat security op veel plekken een ondergeschoven kindje is, is waar (net als documenteren overigens).

Mijn punt is dat volwassen producten minder risico vormen dan de leukere/sexy/trendy nieuwe producten. Het is redelijk eenvoudig een goede beheerder te vinden die een bekende relationele database server secure kan houden en/of kan auditen. Dit zal bij een nieuw product gebaseerd op nieuwe concepten en werkende vanuit andere uitgangspunten, niet het geval zijn.

In dit perspectief is de keuze voor MongoDB, daar waar de features voortkomende uit de nieuwe aanpak duidelijk niet noodzakelijk zijn, een slechte. Mijn verklaring hoe die keuze tot stand komt is wat ik heb geschreven.

Dezelfde logica is overigens net zo goed los te laten op andere soorten producten.

[Verwijderd]

Ik vind hier de schuld van de MongoDB developers groten dan die van beheerders die het verkeerd instellen.

Een database kunnen gebruiken zonder password is in ALLE gevallen NOT DONE. Ook niet lokaal. Verder moeten installaties standaard secure zijn, en niet als keuze achteraf waar je afhankelijk bent van mensen (die het altijd verknallen).

[SlaSauS]

Eens.

Het verbaasd me dat Mongo tot en met 2.4 default met een onveilige config shipte. Gelukkig is deze default eindelijk in 2.6 veranderd naar 127.0.0.1 oftewel niet zomaar beschikbaar voor iedereen op het netwerk. Iets wat lang niet iedereen nodig heeft.

[Verwijderd]

Ik vergelijke de situatie een beetje met Wifi/routers: 10 jaar terug stonden die standaard open en diende je je te verdiepen in het beveiligen ervan of een handig neefje hebben. Dat ging gigantisch mis. Nu staat standaard de beveiliging aan, veel beter.

[jj71]

Ik ben het ermee eens dat de security standaard aan zou moeten staan. Als dat bij MongoDB niet het geval was of is, dan is dat inderdaad slecht van de ontwikkelaars van MongoDB.

Maar ik vind wel dat er een verschil is tussen eenvoudige thuisgebruikers met bijv. een WiFi-router en professionele IT-ers in bedrijven. Van een gewone consument kun je niet verwachten dat deze de kennis heeft of zelfs er zich maar van bewust is dat hij/zij de security moet controleren en instellen.

Maar ik vind dat je van professionele IT-ers wel moet kunnen verwachten en dat ze ook de verantwoordelijkheid hebben om naar de security te kijken. Als ze dat niet doen dan maken ze een verwijtbare fout.

Ik vind dat de verantwoordelijkheid in eerste instantie ligt bij die IT-ers die producten zoals MongoDB inzetten, en in tweede instantie bij de ontwikkelaars van MongoDB.

[Verwijderd]

"Maar ik vind dat je van professionele IT-ers wel moet kunnen verwachten en dat ze ook de verantwoordelijkheid hebben om naar de security te kijken. Als ze dat niet doen dan maken ze een verwijtbare fout."

Dat vind ik ook. Maar na 15 jaar in de IT zeg ik dat je dat eigenlijk niet mag verwachten. En dat is lang niet altijd een geval van incompetentie of luiheid, onder druk wordt alles vloeibaar.

[Verwijderd]

Waar MongoDB ook voor wordt gebruikt: eLearning. Neem bijvoorbeeld een Amerikaans systeem, gericht op K-12. Had tot begin dit jaar MongoDB openstaan met daarin "a proprietary user identity management technology first developed more than twelve years ago. This technology enables real-time updates from multiple inputs - anything from contact info to teaching resources to learning activities.", ofwel adresgegevens van tienduizenden docenten en basisschoolleerlingen.

Of een webmail beheerder in Zimbabwe, gebruikersnamen en wachtwoorden van de klanten in plaintext op een MongoDB.

Zomaar een steekproef, genomen eind vorig jaar. Beheerders van beide systemen zijn op de hoogte gebracht.

[Verwijderd]

Zo moeilijk is het toch echt niet. Elke database geef je alleen toegang via localhost of een of twee lokale ip nummers in een netwerk achter een firewall die specifiek ook de poortnummer(s) van die database blokt.
En mogelijke REST of http(s) toegang regel je via een webserver met een module die alleen geldige opdrachten toestaat (en dus geen admin gedoe).