数据库劫持
# 数据库劫持经历以及惨痛教训
# 说明
出问题的是两台从腾讯云购买的云服务器,每台服务器上运行了mysql,刚开始创建测试库进行开发,后来在相同的mysql服务上创建了正式环境。因为初期调整比较多。开通了'root@%'的权限,即所有客户端都可以通过账号密码访问。密码非常简单:Aa123456。 2.前段时间凌晨三点遭到劫持,通过流量波动判断。白天连上去发现数据库已经被清空,只剩下一个recovery_data。其下有一个remake表。如下图所示:
# 妄想
因为情况已经这样了,本着数据第一的目的。计划着联系留下的邮箱,抱着尝试的心态进行沟通。(虽然别人都说付款了没不会给你恢复的。)
先询个价:
太贵了!!!
还个价:
不支持还价了,算了。
没想到过了段时间,邮件提醒数据快到期了,让大家快点付款。
看来有这几个大兄弟都进行联系了。
后来有个兄弟回复,表明他在进行付款操作。
但是他为什么要抄送其他人呢??
还邮件我想加好友:
感觉是一个巨大的骗子。
# 暴露的问题
问题1:其中一台服务器情况较好,设置了磁盘快照,还原到2天前的数据。其他数据只能根据应用程序文本日志进行追踪。另一台就没有备份,系统快照没有设定磁盘,导致需要重从头开始。
应对方法:备份,备份,备份
问题2:没有整理初始数据结构。因为ORM使用的是FreeSql,开发方式采用的是DBFirst,期间操作数据进行数据结构的修改。
应对方法:通过应用程序实体执行codeFirst同步数据结构。
问题3:一些资源数据(机场数据、行政区域数据、车型、车系等)丢失。
应对方法:重新整理资源数据。
问题4:用户,部门,组织,页面等基础数据丢失
应对方法:重新创建基础数据
# 问题总结
1.正式环境访问不开放给服务器之外或者指定IP之外的地址进行访问。即创建开发权限和部署权限以区分访问开发环境和生产环境;生产环境只在localhost环境或者指定ip地址进行操作。
2.增强数据库访问密码安全性。
3.最最最
重要的是认识到数据的重要性,对生产环境进行备份。
举例来说,订单系统,就算有快照,还原到两天前的数据,那么这两天的订单的处理方法,因为涉及到金钱,会是非常棘手的事情。
4.DBFirst的开发方式下维护好数据库数据结构以及种子数据。以实现快速部署以及快速访问。
5.维护好资源数据。