别让你的服务器变成黑客的游乐场

数据在软件系统中可谓是“镇店之宝”，没有数据，系统就像个空壳子。然而，现实中不少开发者对待数据安全的态度却有些“佛系”——更在意跑得快（性能），却忽略了跑得稳（安全）。但你永远不会知道，哪一天的“省事”会变成“事故”。

裸奔的MongoDB

记得在2017年左右，针对MongoDB未授权的攻击非常猖獗，给许多企业和个人造成了严重损失。因为MongoDB默认配置中是没有设置密码的，直接敞开大门欢迎四方宾客，黑客进来比进自己家还熟练。当时，由于好奇，我也通过 zoomeye 工具扫描过公网暴露的MongoDB实例。

使用该工具可以发现网络上已经安装过MongoDB的服务器，如果没有设置密码，我们就可以轻松登录到这些数据库中，经过实际测试，我发现里面早被打劫一空，只剩下空荡荡的勒索信息，要求受害者支付比特币以恢复数据😂。

Redis 矿工

在2019年，公司的测试同事一大早就@我说，公司的一台测试服务器非常卡，无法使用，让我帮忙去看看。我登录上去后，发现CPU已经跑到了300%，并且已经被植入了挖矿程序，kill 掉该进程后又会自动重启，非常顽劣。经过排查，定位到该恶意脚本位于redis容器中，最后停止这个容器，删掉这个redis镜像才最终解决。因为平时为了方便，测试同事未给 redis 设置相关密码，挖矿脚本通过 6379 端口接入走后门被注入了进来。

Log4j：午夜惊魂

2021年底，Log4j被曝出一个严重的远程代码执行漏洞（CVE-2021-44228），也被称为“Log4Shell”。该漏洞源于Log4j在处理日志消息时，对用户输入缺乏充分的验证，攻击者可以构造恶意的JNDI查找语句，导致服务器加载并执行来自远程的恶意代码。这使得攻击者能够在受影响的服务器上执行任意代码，造成严重的安全风险。包括百度等软件大厂都成为了该漏洞的受害者。那段时间，很多人都被大半夜叫起来紧急修复这个问题。

别图方便

很多时候，事故的源头往往是“省事儿”--数据库不设密码，端口对公网裸奔，代码不做输入校验……这些“小习惯”最终酿成“大事故”。

随着技术的发展，数据安全漏洞层出不穷。开发者和企业应保持警惕，及时关注并修复已知漏洞，采取有效的安全措施以保护数据安全。安全性是相对的，没有100%安全的系统，但100%的疏忽一定会出事。在数据库安全方面，遵循一些良好的实践可以有效提高安全性：

• 确保数据库访问必须提供用户名和密码，并且使用强密码策略。
• 如果数据库需要在公网传输，建议启用 TLS（Transport Layer Security） 加密，防止数据在传输过程中被窃听或篡改。
• 采用异地备份策略，防止数据因攻击或硬件故障丢失。
• 最小权限原则：为每个用户分配最少的权限，避免授予 root 或 admin 权限给不必要的用户。