Forebyggende sikkerhed med revisionslogning til MongoDB

Databasesikkerhed er et bredt emne, der strækker sig fra forebyggende målinger til at holde uønskede besøgende ude. Selvom du ville være i stand til at sikre dine MongoDB-servere fuldt ud, vil du stadig gerne vide, om nogen har forsøgt at bryde ind i dit system. Og hvis det lykkes dem at bryde din sikkerhed og installere MongoDB løsesum-hacket, har du brug for et revisionsspor til obduktioner eller for at tage nye forebyggende foranstaltninger. En revisionslog ville gøre dig i stand til at holde styr på alle, der forsøger at logge ind og se, hvad de gjorde i dit system.

MongoDB Enterprise-versionen indeholder muligheden for at aktivere revisionsloggen, men fællesskabsversionen mangler denne funktionalitet. Percona skabte deres egen revisionslogningsfunktionalitet i deres MongoDB-afledte Percona Server til MongoDB. MongoDB og Percona tilgange er forskellige fra hinanden, og vi vil forklare, hvordan man konfigurerer og bruger dem begge.

MongoDB revisionslogning

MongoDB revisionsloggen er nem at konfigurere:for at aktivere revisionslogning til en JSON-fil skal du blot tilføje følgende sektion til din konfigurationsfil og genstarte MongoDB:

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

MongoDB understøtter fil, konsol og syslog som destinationer. For filformater er der to muligheder:JSON og BSON. I JSON ser revisionsloglinjerne sådan ud:

{ "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 ovenfor ville aktivere revisionsloggen for hver eneste handling af enhver bruger af dit system. Hvis du har høj samtidighed, vil dette dramatisk reducere ydeevnen af ​​din MongoDB-klynge. Heldigvis er der mulighed for at filtrere hændelser, der skal logges.

Filtre til revisionslogningen kan placeres på forespørgselstypen, bruger-/rolleforespørgslen eller på den samling, der forespørges. Dokumentationen om revisionslogning hos MongoDB er meget bred og lang med mange eksempler. Vi vil give nogle af de vigtigste eksempler nedenfor.

Godkendelse mod en bestemt samling:

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

Log for flere revisionstyper:

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

Log alle godkendelsestjek for indsættelse/opdateringer/sletninger på en bestemt samling:

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

Som du kan se, kan filtrene være ret fleksible, og du ville være i stand til at filtrere de beskeder, du har brug for til dit revisionsspor.

Percona Server til MongoDB revisionslogning

Percona Server til MongoDB revisionslogning er begrænset til JSON-fil. De fleste brugere vil kun logge på JSON-filer, men det er uklart, om Percona vil tilføje andre logningsfaciliteter i fremtiden.

Afhængigt af versionen af ​​Percona Server til MongoDB kan din konfiguration være anderledes. I skrivende stund har alle versioner følgende syntaks:

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

Denne konfigurationsforskel er dog for nylig blevet løst, men skal stadig frigives. Efter udgivelsen skulle den følge MongoDB auditLog-direktivet igen:

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

Formatet af Percona er lidt anderledes:

{ "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 modsætning til at MongoDB logger alt, valgte Percona kun at logge de vigtige kommandoer. At dømme ud fra kilden til Percona audit plugin, understøttes følgende forespørgsler:godkendelse, opret/opdater/slet brugere, tilføje/opdater/fjern roller, opret/slip database/indeks og de fleste af de vigtige admin-kommandoer.

Også filtreringen af ​​Percona-serveren til MongoDB-revisionsloggen ser ikke ud til at følge den samme standard, som MongoDB har. Det er ret uklart, hvad den nøjagtige filtersyntaks og -muligheder er, da Percona-dokumentationen er meget kortfattet om det.

Aktivering af auditlog uden filtrering vil give dig mere end nok poster i din logfil. Herfra kan du indsnævre filteret, da det følger JSON-syntaksen for logposterne.

Brug af revisionsloggen

For at gøre det nemmere for dig selv, kan det være det bedste at føre revisionsloggen ind i en loganalyseramme. En ELK-stak er et glimrende miljø at lave din analyse i, og den gør det nemt for dig at bore ned til mere detaljerede niveauer. Brug af en feltkortlægger ville endda give dig mulighed for at lave revisionssporet inde i ELK.

Som beskrevet i indledningen kan vi bruge revisionsloggen til forskellige sikkerhedsformål. Den mest oplagte er, når du har brug for den som reference under en obduktion. MongoDB-revisionsloggen giver et detaljeret overblik over, hvad der præcist skete. Perconas revisionslog indeholder lidt mindre information, men den burde være tilstrækkelig til de fleste obduktioner. Det er fantastisk at bruge revisionsloggen til obduktioner, selvom vi hellere ville have forhindret problemet i første omgang.

Et andet formål med revisionsloggen er at se tendenser, der sker, og du kan sætte fælder på en bestemt revisionslogmeddelelse. Et godt eksempel ville være at kontrollere hastigheden af ​​(mislykkede) godkendelsesforsøg, og hvis dette overstiger en vis tærskel, skal du handle efter det. Afhængigt af situationen kan den trufne handling variere. En handling kunne være automatisk at blokere den ip-adresse, anmodningerne kommer fra, men i et andet tilfælde kan du rådføre dig med brugeren om, hvorfor adgangskoden blev glemt. Det afhænger virkelig af den sag og det miljø, du arbejder i.

En anden avanceret forebyggende måling ville være at bruge MongoDB som en honeypot og udnytte revisionsloggen til at fange uønskede brugere. Bare eksponer MongoDB og lad enhver oprette forbindelse til din MongoDB-server. Brug derefter revisionsloggen til at opdage, hvad brugere vil gøre, hvis de får lov til at gøre ting ud over deres normale beføjelser, og bloker dem, hvis det er nødvendigt. De fleste mennesker tager hellere den nemme vej end den hårde, så honningpotten kan aflede et angreb, og hackeren vil gå videre til det næste mål.

Konklusion

Udover at forklare, hvordan man opsætter revisionsloggen for både MongoDB Enterprise og Percona Server til MongoDB, forklarede vi også, hvad du potentielt kunne gøre med de loggede data inde i revisionsloggen.

Som standard vil ClusterControl ikke aktivere revisionsloggen, men det er relativt nemt at aktivere den i hele klyngen ved hjælp af vores Config Manager. Du kan også aktivere det i konfigurationsskabelonerne, før du implementerer en ny klynge.

Glædelig klyngedannelse!