web-dev-qa-db-ja.com

過剰なPostgres Docker CPU消費

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
_

アルパインにはpsコマンドの限定バージョンが付属していることがわかりました。これを実行する：

_apk --no-cache add procps
_

拡張バージョンを取得し、ログ内のps関連エラーを防止します。これを含むようにPostgresイメージを更新しましたが、これまでのところ問題は再発していません。推測は、失敗後にコマンドを繰り返し実行しようとしてCPUがスラッシュされていることです。

診断

以下の回答のとおり、私はハッキングされたことが判明しました。私は現在彼らがどうやって入ったかに途方に暮れています。 SSH証明書/パスワードアクセスなしでrootが無効になっている特定のユーザーにサーバーがロックされています。 （「最後」には、ハッキングされていない限り、私のアクセスのみが表示されます。）postgresqlへのパブリックアクセスはありません。非常に強力なデータベース管理者パスワード。現在、他の1つのコンテナからのみアクセスされています。サーバーのWebサイト経由でアクセスした可能性が高いようですが、この場合はホストOSではなく、コンテナのオペレーティングシステムまでしかアクセスしていません。 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/ =

postgresqldockercpu
5
vipes

あなたはハッキングされており、ハッカーのために暗号通貨を採掘しています。

彼らはあなたのpostgresqlサーバーのスーパーユーザーアカウントのパスワードを推測することで侵入しました。次に、lo_export機能を使用して、任意のシェルコマンドを実行するユーザー定義関数のバイナリを削除しました。それがfun308928987であり、このバイナリをラップするために作成されたSQL関数です。

最善のクリーンアップは、サーバーを破壊して再構築することです。今回は、スーパーユーザーアカウントに実際の強力なパスワードを設定します。あるいは、pg_hba.confを変更して、外部ユーザーからのスーパーユーザー接続、できれば任意の接続を許可しないようにします。

3
jjanes