68素材站

mongodb安全权限设定

68素材 2574 0

最近因为开放一个项目用的MongoDB,为了测试方便远程服务器的MongoDB没有设置权限,使用的默认端口27017,今天访问,突然发现数据都不见了,多了一个勒索信息:

All your data is a backed up. You must pay 0.021 BTC to 17jHiu7FGUX8xcotaxBnxnNZRTqU86kr8b 48 hours for recover it. After 48 hours expiration we will leaked and exposed all your data. In case of refusal to pay, we will contact the General Data Protection Regulation, GDPR and notify them that you store user data in an open form and is not safe. Under the rules of the law, you face a heavy fine or arrest and your base dump will be dropped from our server! You can buy bitcoin here, does not take much time to buy https://localbitcoins.com or https://buy.moonpay.io/ After paying write to me in the mail with your DB IP: recmydb+13h09@onionmail.org and you will receive a link to download your database dump.

怎么说呢,咱技术有限也搞不了他们,发上来给朋友们提个醒吧,还是要注意设置访问权限,不要觉得是测试就不在意,还好数据都是有备份的,而且也不是重要的数据,如果有看到的朋友可以那上面的BTC的地址还有对方的邮箱玩玩,,

47685-20180911194124131-2096232846.png

mongodb安全权限设定

如何防范此类攻击?

做好访问认证。打开你的MongoDB配置文件(.conf),设置为auth=true

 做好防火墙设置。建议管理者关闭27017端口的访问。

Bind_ip,绑定内网IP访问。

做好升级。请管理者务必将软件升级到最新版本。

可参考安全手册(https://docs.mongodb.com/manual/security/)

轻视安全问题是要付出代价的。事实上MongoDB数据库泄漏问题早在2015年就被报导过。当时Shodan(搜索引擎)的负责人John Matherly统计到有30,000个以上的MongoDB数据库实例,近600TB的数据暴露于公网之上,无需任何认证就可访问。很多版本滞后的数据库配置文件里没有做IP捆绑(bind_ip 127.0.0.1),在用户不甚了解的时候留下了安全隐患。虽然MongoDB的开发团队在下一个版本里修复了这个问题,但截止事发,仍然有数量众多的数据库管理者没来得及更新。


这次勒索事件的一个显著后果就是世界范围内存储在MongoDB数据库里数据量的大幅下滑。据Merrigan提供的信息显示,在短短3天内就有114.5TB的数据因此消失。据估计,目前网上约有50,000个开放访问的MongoDB数据库,也许用不了多久所有没做好安全措施的数据库都会被黑客攻陷。这个过程需要多久?据Gevers估算,这个过程可能用不了几周。


毫无疑问,黑客们的疯狂给人们敲响了警钟。现在应该会有很多人后悔了。


MongoDB官方建议如下:


如何知道自己有没有受到攻击:


如果已经为数据库正确配置了访问控制,攻击者应该访问不到数据,可参考安全手册(https://docs.mongodb.com/manual/security/)

验证数据库和集合。在最近的案例中,攻击者丢弃了数据库和/或集合,并用一个ransom需求的新的替换它们。

如果启用访问控制,请审核系统日志以进行未经授权的访问尝试或可疑活动。

如果已经受到攻击:


如果您是MongoDB企业支持客户,请尽快提交P1订单,我们的技术服务工程师可以指导您完成以下过程。

您的首要任务是保护您的集群以防止进一步的未授权访问。您可以参照我们的安全实践文档。

通过运行 usersInfo 来检查是否有添加,删除或修改的用户。

检查日志以查找攻击的时间。检查是否有删库或者删表,修改用户或创建赎金记录的命令。

如果你有定期对受损数据库进行备份,则可以还原最近的备份。您需要评估最近的备份和攻击时间之间可能已更改的数据量。如果您使用Ops Manager或Cloud Manager进行备份,则可以恢复到攻击之前的时间点。

如果您没有备份或以其他方式无法还原数据,那么您的数据可能会永久丢失。

您应该假设攻击者已经复制了受影响的数据库的所有数据。请按照内部安全流程对数据泄露事件进行恰当处理。

发表评论 (已有0条评论

还木有评论哦,快来抢沙发吧~