联系：手机/微信(+86 17813235971) QQ(107644445)
标题：注意:PostgreSQL库出现readme_to_recover勒索
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
以前恢复过不少mysql库被删除的勒索case,比如:
read_me_recover_tn勒索恢复
A_H_README_TO_RECOVER勒索恢复
A____Z____RECOVER____DATA勒索恢复
今天在PostgreSQL库中也简单了类似的勒索案例
[postgres@xifenfei database]$ psql
psql (12.8)
Type "help" for help.
postgres=> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-------------------+----------+----------+------------+------------+-----------------------
ldar-test | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
readme_to_recover | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
(5 rows)
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.0051 BTC to bc1q9p333xxxxxxxxxxxxxj2z5fs27pu3u In 48 hours,
your data will be publicly disclosed and deleted . (more information: go to http://2info.win/psg)
After paying send mail to us: rambler+3d2l7@onionmail.org and we will provide a link for
you to download your data. Your DBCODE is: xxxxx
(2 rows)
readme_to_recover=> select oid,relname from pg_class;
oid | relname
---------+-----------------------------------------------
2196735 | readme
2619 | pg_statistic
1247 | pg_type
4159 | pg_toast_2600
4160 | pg_toast_2600_index
2830 | pg_toast_2604
2831 | pg_toast_2604_index
4161 | pg_toast_3456
4162 | pg_toast_3456_index
2832 | pg_toast_2606
2833 | pg_toast_2606_index
………………
13373 | _pg_foreign_tables
13377 | foreign_table_options
13383 | _pg_user_mappings
13391 | user_mappings
13387 | user_mapping_options
(396 rows)
根据这里的readme的oid值，初步怀疑是drop所有业务表,然后创建了readme表,并且插入了勒索信息.
我做的各种数据库恢复比较多，说实话一直对pg这个特点非常不满意：
1. pg的数据存储本身依赖文件系统，通过oid(来表示库，表示表以及其他各种对象，和很多商业化数据库不一样，对于文件系统过于依赖，这样的情况如果发生了drop/truncate表等操作，表从文件系统中被删除，恢复难度较大
2. pg的表对应本身没有在每个数据块的block记录表的id信息，这样使得无法很好的进行底层基于block的扫描恢复数据，目前我知道的pdu一定的这样的功能，但是那是依赖列匹配，原则上来说对于一个稍微复杂一点的系统，这个恢复思路基本上不可行（因为列相似的数据表可能很多，导致恢复的数据过于混乱）
基于上述的两个特点，如果整个业务库被这种勒索破坏，如果没有备份，想比较好的恢复效果基本上很难（除非你运气非常好，os层面反删除恢复效果特别好，这要取决被删除的表在os上没有覆盖，文件系统元数据没有回收，系统没有识别是ssd环境等因素决定）
基于这种故障在没有备份的情况下很难恢复，那我们要做的就是：
1）有有效的备份或者容灾不被破坏;
1> 数据需要有效的备份,有条件的建议异机或者离线
2> 如果有条件可以部署延迟同步的备库,避免发生故障备库同步 被破坏
2）尽可能不让这种故障发生:
1>数据库不要暴露在公网上,减少被攻击和入侵的风险
2>数据库不要使用弱口令,减少被暴力攻破密码的风险
3>注意应用漏洞，减少通过sql注入进行数据库进行破坏
4>注意已知的数据库安全漏洞,防止被利用进行攻击
5>注意操作系统安全,因为登录了数据库服务器对于数据库来说就没有安全可言
