Preventieve beveiliging met auditlogging voor MongoDB

Databasebeveiliging is een breed onderwerp dat zich uitstrekt van preventieve maatregelen tot het buiten de deur houden van ongewenste bezoekers. Zelfs als u uw MongoDB-servers volledig zou kunnen beveiligen, zou u toch graag willen weten of iemand heeft geprobeerd in te breken op uw systeem. En als ze erin slagen uw beveiliging te doorbreken en de MongoDB-ransomhack te installeren, hebt u een controlespoor nodig voor post-mortems of voor het nemen van nieuwe preventieve maatregelen. Met een controlelogboek kunt u bijhouden wie probeert in te loggen en te zien wat ze in uw systeem hebben gedaan.

De MongoDB Enterprise-versie bevat de mogelijkheid om het auditlogboek in te schakelen, maar de communityversie mist deze functionaliteit. Percona creëerde hun eigen auditregistratiefunctionaliteit in hun van MongoDB afgeleide Percona Server voor MongoDB. De benaderingen van MongoDB en Percona verschillen van elkaar en we zullen uitleggen hoe u ze beide kunt configureren en gebruiken.

MongoDB-controlelogboekregistratie

Het MongoDB-auditlogboek is eenvoudig in te stellen:om auditregistratie naar een JSON-bestand in te schakelen, voegt u eenvoudig het volgende gedeelte toe aan uw configuratiebestand en start u MongoDB opnieuw:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

MongoDB ondersteunt bestand, console en syslog als bestemmingen. Voor bestandsformaten zijn er twee opties:JSON en BSON. In JSON zien de regels van het auditlogboek er als volgt uit:

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

De bovenstaande configuratie zou het auditlogboek inschakelen voor elke actie van elke gebruiker van uw systeem. Als u een hoge gelijktijdigheid heeft, zou dit de prestaties van uw MongoDB-cluster drastisch verminderen. Gelukkig is er de mogelijkheid om gebeurtenissen te filteren die gelogd moeten worden.

Filters voor de audit logging kunnen worden geplaatst op het type query, de gebruiker/rol query of op de collectie die wordt opgevraagd. De documentatie over audit logging bij MongoDB is erg breed en lang met veel voorbeelden. We zullen hieronder enkele van de belangrijkste voorbeelden geven.

Authenticatie tegen een specifieke collectie:

    filter: '{ atype: "authenticate", "param.db": "test" }'

Log voor meerdere audittypes:

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

Log alle authenticatiecontroles voor insert/updates/deletes op een specifieke collectie:

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

Zoals u kunt zien, kunnen de filters vrij flexibel zijn en kunt u de berichten filteren die u nodig heeft voor uw audittrail.

Percona Server voor MongoDB Audit Logging

De Percona Server voor MongoDB-auditregistratie is beperkt tot JSON-bestanden. De meerderheid van de gebruikers logt alleen in op JSON-bestanden, maar het is onduidelijk of Percona in de toekomst andere logfaciliteiten zal toevoegen.

Afhankelijk van de versie van Percona Server voor MongoDB kan uw configuratie anders zijn. Op het moment van schrijven hebben alle versies de volgende syntax:

audit:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Dit configuratieverschil is echter onlangs opgelost, maar moet nog worden vrijgegeven. Na de release zou het opnieuw de MongoDB auditLog-richtlijn moeten volgen:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Het formaat van Percona is iets anders:

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

In tegenstelling tot MongoDB die alles logt, koos Percona ervoor om alleen de belangrijke commando's te loggen. Afgaande op de bron van de Percona-auditplug-in, worden de volgende zoekopdrachten ondersteund:authenticatie, gebruikers maken/bijwerken/verwijderen, rollen toevoegen/bijwerken/verwijderen, database/index maken/verwijderen en de meeste belangrijke beheerdersopdrachten.

Ook het filteren van de Percona Server for MongoDB audit log lijkt niet dezelfde standaard te volgen als MongoDB heeft. Het is vrij onduidelijk wat de exacte filtersyntaxis en -opties zijn, aangezien de Percona-documentatie er zeer beknopt over is.

Als u de auditlog inschakelt zonder te filteren, krijgt u meer dan genoeg vermeldingen in uw logbestand. Vanaf hier kunt u het filter verfijnen, omdat het de JSON-syntaxis van de logboekvermeldingen volgt.

Gebruik maken van het auditlogboek

Om het jezelf gemakkelijker te maken, is het misschien het beste om het auditlogboek in te voeren in een logboekanalysekader. Een ELK-stack is een uitstekende omgeving om uw analyses in uit te voeren en stelt u in staat om vrij gemakkelijk naar meer gedetailleerde niveaus te gaan. Als u een veldmapper gebruikt, kunt u zelfs de audittrail binnen ELK doen.

Zoals beschreven in de inleiding kunnen we het auditlogboek voor verschillende beveiligingsdoeleinden gebruiken. De meest voor de hand liggende is wanneer je het nodig hebt als referentie tijdens een autopsie. Het MongoDB-auditlogboek geeft een gedetailleerd overzicht van wat er precies is gebeurd. Het Percona-auditlogboek bevat iets minder informatie, maar zou voor de meeste autopsie moeten volstaan. Het gebruik van het controlelogboek voor autopsie is geweldig, hoewel we het probleem liever hadden voorkomen.

Een ander doel van het auditlogboek is om trends te zien gebeuren en u kunt traps instellen op een bepaald auditlogboekbericht. Een goed voorbeeld zou zijn om het aantal (mislukte) authenticatiepogingen te controleren en als dit een bepaalde drempel overschrijdt, hier actie op te ondernemen. Afhankelijk van de situatie kan de ondernomen actie verschillen. Een actie zou kunnen zijn om het ip-adres waar de verzoeken vandaan komen automatisch te blokkeren, maar in een ander geval zou u met de gebruiker kunnen overleggen waarom het wachtwoord is vergeten. Het hangt echt af van de zaak en de omgeving waarin je werkt.

Een andere geavanceerde preventieve meting is het gebruik van MongoDB als een honeypot en het gebruik van het auditlogboek om ongewenste gebruikers te vangen. Stel MongoDB gewoon bloot en laat iedereen verbinding maken met uw MongoDB-server. Gebruik vervolgens het auditlogboek om te detecteren wat gebruikers zullen doen als ze dingen mogen doen die buiten hun normale bevoegdheden vallen en blokkeer ze indien nodig. De meeste mensen kiezen liever de gemakkelijke weg dan de moeilijke, zodat de honeypot een aanval kan afslaan en de hacker naar het volgende doelwit zal gaan.

Conclusie

Naast uitleg over het instellen van het auditlogboek voor zowel MongoDB Enterprise als Percona Server voor MongoDB, hebben we ook uitgelegd wat u mogelijk kunt doen met de geregistreerde gegevens in het auditlogboek.

Standaard zal ClusterControl het auditlogboek niet inschakelen, maar het is relatief eenvoudig om het clusterbreed in te schakelen met behulp van onze Config Manager. U kunt het ook inschakelen in de configuratiesjablonen, voordat u een nieuw cluster implementeert.

Veel plezier met clusteren!