周末我在公有云搭建了一套PostgreSQL 13的数据库，并建了一个名为shijw的数据库。今天上去一看，发现shijw数据库没了，名字变成readme_to_recover了，请看下图：

难道是我数据库损坏了，需要恢复？可是我服务器也没动过啊！于是咨询我运维pg的朋友，似乎也没见过：

既然没见过，那就看看，这是啥？

postgres=> \c readme_to_recover
You are now connected to database "readme_to_recover" as user "postgres".
readme_to_recover=> \d
         List of relations
 Schema |  Name  | Type  |  Owner   
--------+--------+-------+----------
 public | readme | table | postgres
(1 row)
readme_to_recover=> select * from readme;
                                                                                                text_field                                                                                                 
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 All your data is backed up. You must pay 0.0060 BTC to 1M1bhRQLFnttrJFkY1RqN9UcCMvrB4MDbT In 48 hours, your data will be publicly disclosed and deleted. (more information: go to http://iplis.ru/data03)
 After paying send mail to us: dzen+3ef8m@onionmail.org and we will provide a link for you to download your data. Your DBCODE is: 3EF8M
(2 rows)

`

糟糕，这一看就是sql注入中了勒索病毒了！

‍它很贴心地告诉我们，我们可以花 0.006 BTC（在撰写本文时约为 2280人民币）取回一份数据副本。如果我们不付钱，数据将被公开披露和删除！‍

真该死，你觉得我会上当，钱给出去也是拿不回数据的！

还好这是测试库，我重建就好了！

总结下本次PostgreSQL中勒索的原因，是因为我设置了弱密码！相当于将数据库直接裸露在外网上，这是非常可怕的一件事。

对于数据库服务器，首先网络层面需要做好足够的防护，确保所有网络设备（如路由器、交换机、防火墙等）都采用了强化的安全配置。做到主机层面不被入侵；其次是数据库，加强身份验证和访问控制：采用多因素认证和最小权限原则。并架设数据库访问安全产品，定期做好备份并异地保存！