过高的Postgres码头CPU消耗

Question

我正在使用Postgres容器运行一些小型非关键应用程序和站点。它已经稳定了一段时间，但是现在容器在运行了很短一段时间之后，已经开始消耗一些严重的CPU。我已经删除了使用Postgres容器的所有其他容器，即使在启动新实例之后，过度的CPU使用也会再次发生。在我的主机(docker stats)中，我看到了以下内容：

CONTAINER ID        NAME                                              
CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS cd553249727d        data_postgresql.1.ft2gof5jci25xs5w5uqw6eezi                
814.52%             22.11MiB / 46.95GiB   0.05%               129kB / 116kB       0B / 692kB          23

这个(top)：

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
28923 70        20   0  633580  19664    488 S 696.7  0.0   2408:51 Dp2N

在容器(top)中，我看到以下内容：

Mem: 42042244K used, 7183656K free, 3622600K shrd, 1952K buff, 30585480K cached
CPU:  63% usr   9% sys   0% nic  26% idle   0% io   0% irq   0% sirq
Load average: 9.77 9.70 9.66 13/508 11090
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
   94     1 postgres S     618m   1%   3  58% ./Dp2N    <----- WTF?!?!?
   53    52 postgres S     1588   0%   1   1% {systemd} /bin/sh ./systemd
   47     1 postgres S     163m   0%   8   0% postgres: postgrea67 postgres 10.2
   22     1 postgres S     161m   0%   0   0% postgres: autovacuum launcher proc
   20     1 postgres S     161m   0%   8   0% postgres: writer process
   21     1 postgres S     161m   0%   5   0% postgres: wal writer process
    1     0 postgres S     161m   0%   0   0% postgres
   19     1 postgres S     161m   0%   8   0% postgres: checkpointer process
   23     1 postgres S    19988   0%   1   0% postgres: stats collector process
11081    53 postgres R     1588   0%   4   0% [systemd]
   33     0 root     S     1576   0%   9   0% sh
   52    47 postgres S     1568   0%  10   0% sh -c setsid ./systemd
   39    33 root     R     1508   0%  11   0% top
11083 11081 postgres Z        0   0%   5   0% [grep]
11084 11081 postgres Z        0   0%   4   0% [awk]

查询活动(不知道select fun308928987('setsid ./systemd')做什么)：

postgres=# select backend_start, usename, application_name, client_addr, client_hostname, query from pg_stat_activity;
         backend_start         |  usename   | application_name | client_addr | client_hostname |                                                    query
-------------------------------+------------+------------------+-------------+-----------------+-------------------------------------------------------------------------------------------------------------
 2018-05-23 07:34:14.694057+00 | postgres   | psql             |             |                 | select backend_start, usename, application_name, client_addr, client_hostname, query from pg_stat_activity;
 2018-05-23 01:26:55.235556+00 | postgrea67 |                  | 10.255.0.2  |                 | select fun308928987('setsid ./systemd');
 2018-05-23 07:26:03.519231+00 | postgrea67 |                  | 10.255.0.2  |                 | select fun308928987('setsid ./systemd');

在服务日志中，还存在大量此错误的实例：

data_postgresql.1.ft2gof5jci25@IS-57436    | ps: bad -o argument 'command', supported arguments: user,group,comm,args,pid,ppid,pgid,etime,nice,rgroup,ruser,time,tty,vsz,stat,rss

如果我在容器中终止了Dp2N进程，那么CPU的使用就会恢复正常，但是会有一些东西会立即将该进程恢复正常。我在谷歌上搜索了一下，看看是否能在Dp2N上找到任何信息，但都没有用。它位于一个外部安装的卷中：

/ # ls -al /var/lib/postgresql/data/pgdata/Dp2N
-rwxrwxrwx    1 postgres postgres   1886536 May 22 23:25 /var/lib/postgresql/data/pgdata/Dp2N

但它似乎是创造出来的，因为据我所见，它并不是基本形象的一部分。

我用的是postgres:9.6.9-高山。问题从postgres开始:9.6.8-高山，但升级并没有解决它。任何帮助都会非常感谢，因为这是让我发疯！

附加细节

运行file的结果：

sudo file /var/data/pgdata/pgdata/Dp2N
/var/data/pgdata/pgdata/Dp2N: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=bcb5ccf2bc22d1fcb0676506d7c7f31a9b7148bc, stripped

事实证明，阿尔卑斯附带了一个有限版本的ps命令。运行此命令：

apk --no-cache add procps

获取增强版本，并防止日志中与ps相关的错误。我已经更新了Postgres的图片，包括这个，到目前为止，问题还没有重新出现。推测是CPU正在被鞭打，试图在失败后反复执行命令。

诊断

根据下面的答案，我被黑了。我现在不知道他们是怎么进来的。服务器锁定为具有SSH证书/无密码访问并禁用根用户的特定用户。(“最后”只显示我的访问权限--除非它被黑客攻击。)没有对postgresql的公共访问。非常强的数据库管理密码。目前只能从其他一个容器访问。看起来他们很可能是通过服务器上的网站进入的，但在这种情况下，他们只接触到容器操作系统，而不是主机操作系统。FWIW我运行一个Wordpress网站，Grafana，Kibana，Traefik，维护者和我自己的基于.NET的API。我首先从Wordpress的安定开始，因为我以前经历过插件相关的感染。

为教育目的：

https://www.imperva.com/blog/2018/03/deep-dive-database-attacks-scarlett-johanssons-picture-used-for-crypto-mining-on-postgre-database/

Answer 1

您已经被黑客入侵，现在正在为黑客挖掘加密货币。

他们是通过猜测postgresql服务器超级用户帐户的密码而进入的。然后，他们使用lo_export工具删除执行任意shell命令的用户定义函数的二进制文件。这就是fun308928987，它是为包装这个二进制文件而创建的。

最好的清理是只销毁服务器并重建它，这一次为超级用户帐户设置一个实际的强密码。或者更好的是，也可以将pg_hba.conf更改为不允许超级用户连接，或者最好是允许来自外部世界的任何连接。