Предварителна защита с регистриране на одит за MongoDB

Сигурността на базата данни е широка тема, която се простира от превантивни измервания до предпазване от нежелани посетители. Дори и да сте в състояние да защитите напълно вашите MongoDB сървъри, все пак бихте искали да знаете дали някой се е опитал да проникне във вашата система. И ако успеят да нарушат сигурността ви и да инсталират хака за откуп на MongoDB, ще ви е необходима одитна пътека за следклани или за предприемане на нови превантивни мерки. Регистърът за одит ще ви позволи да следите всеки, който се опитва да влезе, и да видите какво е правил във вашата система.

Версията на MongoDB Enterprise съдържа възможността за активиране на дневника за одит, но версията на общността няма тази функционалност. Percona създаде своя собствена функционалност за регистриране на одит в своя Percona сървър, извлечен от MongoDB за MongoDB. Подходите MongoDB и Percona са различни един от друг и ние ще обясним как да конфигурирате и използвате и двата.

Регистриране на одит на MongoDB

Регистърът за одит на MongoDB е лесен за настройка:за да активирате регистрирането на одит в JSON файл, просто добавете следния раздел към вашия конфигурационен файл и рестартирайте MongoDB:

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

MongoDB поддържа файл, конзола и системен журнал като дестинации. За файловите формати има две опции:JSON и BSON. В JSON редовете на журнала за одит изглеждат подобно на това:

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

Конфигурацията по-горе ще позволи регистрационния файл за одит за всяко действие от всеки потребител на вашата система. Ако имате висок паралел, това драстично ще намали производителността на вашия MongoDB клъстер. За щастие има опция за филтриране на събития, които трябва да бъдат регистрирани.

Филтрите за регистриране на одита могат да бъдат поставени върху типа на заявката, заявката на потребител/роля или върху колекцията, която се отправя към заявка. Документацията за регистриране на одит в MongoDB е много обширна и дълга с много примери. По-долу ще дадем някои от най-важните примери.

Удостоверяване спрямо конкретна колекция:

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

Регистрирайте се за няколко типа одит:

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

Регистрирайте всички проверки за удостоверяване за вмъкване/актуализации/изтриване на конкретна колекция:

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

Както можете да видите, филтрите могат да бъдат доста гъвкави и ще можете да филтрирате съобщенията, които са ви необходими за вашата одитна пътека.

Percona сървър за регистриране на одит на MongoDB

Сървърът Percona за регистриране на одит на MongoDB е ограничен до JSON файл. Повечето потребители ще влизат само в JSON файлове, но не е ясно дали Percona ще добави други съоръжения за регистриране в бъдеще.

В зависимост от версията на Percona Server за MongoDB, вашата конфигурация може да е различна. Към момента на писане всички версии имат следния синтаксис:

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

Тази разлика в конфигурацията обаче наскоро беше разрешена, но все още трябва да бъде пусната. След освобождаването трябва да следва отново директивата MongoDB auditLog:

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

Форматът на Percona е малко по-различен:

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

За разлика от MongoDB да регистрира всичко, Percona избра да регистрира само важните команди. Съдейки по източника на приставката за одит на Percona, се поддържат следните заявки:удостоверяване, създаване/актуализиране/изтриване на потребители, добавяне/актуализиране/премахване на роли, създаване/пускане на база данни/индекс и повечето от важните администраторски команди.

Също така филтрирането на Percona Server за MongoDB одит журнал изглежда не следва същия стандарт като MongoDB. Не е ясно какъв е точният синтаксис и опции на филтъра, тъй като документацията на Percona е много кратка за това.

Активирането на auditlog без филтриране ще ви даде повече от достатъчно записи във вашия регистрационен файл. От тук можете да стесните филтъра, тъй като той следва синтаксиса на JSON на записите в регистрационния файл.

Използване на регистрационния файл за одит

За да улесните себе си, може да е най-добре да подадете дневника за одит в рамка за анализ на регистрационни файлове. ELK стекът е отлична среда за извършване на вашия анализ и ви позволява доста лесно да стигнете до по-подробни нива. Използването на полеви картограф би ви позволило дори да направите одитната пътека в ELK.

Както е описано във въведението, можем да използваме дневника за одит за различни цели за сигурност. Най-очевидният е, когато имате нужда от него като справка по време на аутопсия. Регистърът за одит на MongoDB предоставя подробен преглед на това какво точно се е случило. Ревизионният дневник на Percona съдържа малко по-малко информация, но би трябвало да е достатъчен за повечето аутопсии. Използването на ревизионния дневник за аутопсиите е страхотно, въпреки че бихме предпочели да предотвратим проблема на първо място.

Друга цел на регистъра на одита е да видите случващите се тенденции и бихте могли да зададете капани на определено съобщение за одитния дневник. Добър пример би бил да проверите процента на (неуспешните) опити за удостоверяване и ако това надхвърли определен праг, действайте според него. В зависимост от ситуацията предприетите действия могат да се различават. Едно от действията може да бъде автоматично блокиране на IP адреса, от който идват заявките, но в друг случай можете да се консултирате с потребителя защо паролата е забравена. Наистина зависи от случая и средата, в която работите.

Друго усъвършенствано измерване с изпреварващо действие би било използването на MongoDB като honeypot и използването на дневника за одит за улавяне на нежелани потребители. Просто изложете MongoDB и позволете на всеки да се свърже с вашия MongoDB сървър. След това използвайте регистъра на одита, за да откриете какво ще направят потребителите, ако им бъде позволено да правят неща извън нормалните им правомощия и да ги блокирате, ако е необходимо. Повечето хора по-скоро поемат по лесния, отколкото по трудния път, така че медният съд може да отклони атака и хакерът ще премине към следващата цел.

Заключение

Освен че обяснихме как да настроите регистрационния файл за одит както за MongoDB Enterprise, така и за Percona Server за MongoDB, ние също така обяснихме какво потенциално бихте могли да направите с регистрираните данни в регистъра за одит.

По подразбиране ClusterControl няма да активира регистрационния файл за одит, но е сравнително лесно да го активирате в целия клъстер с помощта на нашия Config Manager. Можете също да го активирате в шаблоните за конфигурация, преди да разположите нов клъстер.

Приятно групиране!