Förebyggande säkerhet med revisionsloggning för MongoDB

Databassäkerhet är ett brett ämne som sträcker sig från förebyggande mätningar till att hålla oönskade besökare utanför. Även om du skulle kunna säkra dina MongoDB-servrar fullt ut, skulle du fortfarande vilja veta om någon har försökt bryta sig in i ditt system. Och om de lyckas bryta mot din säkerhet och installera MongoDB-lösenhacket, skulle du behöva ett granskningsspår för obduktioner eller för att vidta nya förebyggande åtgärder. En granskningslogg skulle göra det möjligt för dig att hålla reda på alla som försöker logga in och se vad de gjorde i ditt system.

MongoDB Enterprise-versionen innehåller möjligheten att aktivera granskningsloggen, men communityversionen saknar denna funktionalitet. Percona skapade sin egen revisionsloggningsfunktion i deras MongoDB-härledda Percona Server för MongoDB. MongoDB- och Percona-metoderna skiljer sig från varandra och vi kommer att förklara hur man konfigurerar och använder båda.

MongoDB revisionsloggning

MongoDB-granskningsloggen är lätt att ställa in:för att aktivera granskningsloggning till en JSON-fil, lägg helt enkelt till följande avsnitt i din konfigurationsfil och starta om MongoDB:

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

MongoDB stöder fil, konsol och syslog som destinationer. För filformat finns två alternativ:JSON och BSON. I JSON ser granskningsloggraderna ut så här:

{ "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 }

Konfigurationen ovan skulle aktivera granskningsloggen för varje åtgärd av alla användare av ditt system. Om du har hög samtidighet skulle detta dramatiskt minska prestandan för ditt MongoDB-kluster. Lyckligtvis finns det möjlighet att filtrera händelser som ska loggas.

Filter för granskningsloggningen kan placeras på typen av fråga, användaren/rollfrågan eller på samlingen som frågas. Dokumentationen om revisionsloggning hos MongoDB är mycket bred och lång med många exempel. Vi kommer att ge några av de viktigaste exemplen nedan.

Autentisera mot en specifik samling:

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

Logga för flera granskningstyper:

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

Logga alla autentiseringskontroller för infogning/uppdateringar/borttagningar på en specifik samling:

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

Som du kan se kan filtren vara ganska flexibla, och du skulle kunna filtrera de meddelanden som du behöver för din revisionsspår.

Percona Server för MongoDB revisionsloggning

Percona Server för MongoDB revisionsloggning är begränsad till JSON-fil. Majoriteten av användarna kommer bara att logga till JSON-filer, men det är oklart om Percona kommer att lägga till andra loggningsmöjligheter i framtiden.

Beroende på versionen av Percona Server för MongoDB kan din konfiguration vara annorlunda. I skrivande stund har alla versioner följande syntax:

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

Denna konfigurationsskillnad har dock nyligen lösts, men måste fortfarande släppas. Efter releasen bör den följa MongoDB auditLog-direktivet igen:

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

Formatet av Percona är något annorlunda:

{ "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 }

I motsats till att MongoDB loggar allt, valde Percona att bara logga de viktiga kommandona. Att döma av källan till Perconas granskningsplugin, stöds följande frågor:autentisering, skapa/uppdatera/ta bort användare, lägg till/uppdatera/ta bort roller, skapa/släpp databas/index och de flesta viktiga administratörskommandon.

Också filtreringen av Percona Server för MongoDB revisionslogg verkar inte följa samma standard som MongoDB har. Det är ganska oklart vad den exakta filtersyntaxen och alternativen är eftersom Percona-dokumentationen är mycket kortfattad om det.

Att aktivera revisionsloggen utan filtrering skulle ge dig mer än tillräckligt med poster i din loggfil. Härifrån kan du begränsa filtret, eftersom det följer JSON-syntaxen för loggposterna.

Använda revisionsloggen

För att göra det enklare för dig själv kan det vara bäst att mata in revisionsloggen i ett ramverk för logganalys. En ELK-stack är en utmärkt miljö att göra din analys i och den gör att du enkelt kan borra ner till mer detaljerade nivåer. Om du använder en fältkartare kan du till och med göra revisionsspåret i ELK.

Som beskrivs i inledningen kan vi använda revisionsloggen för olika säkerhetsändamål. Den mest uppenbara är när du behöver den som referens under en obduktion. MongoDB-revisionsloggen ger en detaljerad översikt över exakt vad som hände. Perconas revisionslogg innehåller lite mindre information, men den borde räcka för de flesta obduktioner. Att använda granskningsloggen för obduktioner är bra, även om vi hellre skulle ha förhindrat problemet i första hand.

Ett annat syfte med granskningsloggen är att se trender hända och du kan sätta fällor på ett visst granskningsloggmeddelande. Ett bra exempel skulle vara att kontrollera frekvensen av (misslyckade) autentiseringsförsök och om detta överskrider en viss tröskel, agera efter det. Beroende på situationen kan åtgärderna skilja sig åt. En åtgärd kan vara att automatiskt blockera ip-adressen som förfrågningarna kommer från, men i ett annat fall kan du rådgöra med användaren om varför lösenordet glömdes bort. Det beror verkligen på fallet och miljön du arbetar i.

En annan avancerad förebyggande mätning skulle vara att använda MongoDB som en honungskruka och utnyttja revisionsloggen för att fånga oönskade användare. Avslöja bara MongoDB och låt vem som helst ansluta till din MongoDB-server. Använd sedan granskningsloggen för att upptäcka vad användare kommer att göra om de får göra saker utöver sina normala befogenheter och blockera dem vid behov. De flesta människor tar hellre den enkla vägen än den svåra, så honungskrukan kan avleda en attack och hackaren går vidare till nästa mål.

Slutsats

Förutom att förklara hur man ställer in granskningsloggen för både MongoDB Enterprise och Percona Server för MongoDB, förklarade vi också vad du potentiellt kan göra med den loggade informationen i granskningsloggen.

Som standard kommer ClusterControl inte att aktivera granskningsloggen, men det är relativt enkelt att aktivera det klusteromfattande med vår Config Manager. Du kan också aktivera det i konfigurationsmallarna innan du distribuerar ett nytt kluster.

Lycka till med klustringen!