Postgres Docker 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-alpine。问题始于 postgres:9.6.8-alpine，但升级并没有解决。任何帮助将不胜感激，因为这让我发疯！

额外细节

运行结果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

事实证明，Alpine 附带了该ps命令的有限版本。运行这个：

apk --no-cache add procps

获取增强版本并防止ps日志中出现相关错误。我已经更新了 Postgres 图像以包含此内容，到目前为止问题还没有再次出现。推测是 CPU 正在尝试在失败后重复执行命令时受到冲击。

诊断

根据下面的答案，事实证明我被黑了。我目前不知道他们是如何进入的。服务器被锁定到具有 SSH 证书/无密码访问和 root 禁用的特定用户。（'last' 只显示我的访问权限 - 除非它被黑客入侵。）没有对 postgresql 的公共访问权限。非常强大的数据库管理员密码。当前仅从 1 个其他容器访问。似乎他们是通过服务器上的网站进入的，但在这种情况下只能进入容器操作系统，而不是主机操作系统。FWIW 我正在运行一个 Wordpress 站点、Grafana、Kibana、Traefik、Portainer 和我自己的基于 .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 的含义，创建用于包装此二进制文件的 SQL 函数。

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