攻撃されたのですか、それともただのバカですか？

Debian Squeezeを使用して、いくつかのOpenVZコンテナーでサーバーを実行しています。コンテナの大部分はSqueeze、一部のLenny、および一部は既にWheezyに更新されています。ホストは、iptablesとDHCPを超えてそれを行いません。ファイルサーバー、プロキシ、メールサーバー、Kerberos、LDAPなどはすべてコンテナに入れられます。システムは長年にわたって安定して稼働し、1年以上にわたっていくつかのファイアウォールルールを除いて大きな変更はありませんでした。

2日前、突然システムがクラッシュしました。私はそれを再び持ち出すのに多くの問題を抱えていました。最初はsshでログインできませんでした。ルートログインは「あなたは存在しません。どこかに行って！' ローカルログインは正常でした。しばらくしてからsshが再び機能しました。偶然にも、bash履歴の行を再利用しませんでしたが、新しいコマンドを入力しました。このコマンドは、以前は機能しなかったがクラッシュする前に機能した行と3回チェックされました。

その後、システムは実行されましたが、SYN ACKに続いてほとんどのプロトコルのネットワークトラフィックがブロックされました。DNS、Telnet、およびSSHは問題ありませんでしたが、残りは混乱でした。数時間暗闇で釣りをし、ファイアウォールを数回リロードした後、突然すべてが再びうまくいきました。ログには疑わしいものは見つかりませんでしたが、私は法医学の専門家ではありません。

今日、コンテナクォータにより、ファイルサーバーのnscdがソケットから出てLDAPに接続しました。これまでになかったこと。また、smbdが要求するソケット（> 30）をたくさん見ました。

/ var / log / messagesはsyslogとまったく同じに見えました。/var/log/kern.logには、クラッシュの理由に関する次の追加情報があります。

/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.

最後の「sendmail」クラッシュは、マシンの再起動後です。それ以降、このようなイベントは発生しませんでした。「imapd」と「postgres」は確実に異なるコンテナで実行されます。

まあ、私は喫煙銃を見ませんが、おそらく盲目です。既知の/推定される適切なバックアップからシステムをセットアップすると、非常に大きな理由なく試してみるのが大変になります。

次に何を確認すればよいかアドバイスをいただければ幸いです。

ご協力いただきありがとうございます。

更新：クラッシュの前兆を探すのにもっと努力して、syslogで以下を見つけました。

Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)

これは重要ではないとみなされますが、まれなイベントのようです。パケットの切り捨ては、2回目のクラッシュの日にのみ存在します。使用可能なすべてのログファイルのどこにもありません。

これは、DoSのように見えます。ほとんどの場合、ネットワークまたは侵害されたコンテナの内部から発生します。

vmstatを調べて、5秒ごとに継続的に実行します（vmstat 5）。リソースが消費されている場所をメモします。また、画面を使用して、別のウィンドウでvmstat 60（毎分）を実行することもできます。これにより、長時間にわたってスパイクが発生した場合にスパイクに気付くことができます。

この状況では、システムCPU（sy）が高く、コンテキスト切り替え率（cs）が高く、IOが高い（ネットワークとディスクの両方が表示される）DoSを示します。

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   9584   6820 132432  23256    1    1   136    12    1    1 83  1 15  0  0
 0  0   9584   6696 132432  23256    0    0     0     0   20   32  0  0 99  0  1

同時に、ホスト上のネットワークトラフィックを監視します。ntopをお勧めします。つまり：

$ nload -t 10000 -u H eth0

ディスクI / Oエラーのように見えます。fsckを実行し、エラーを確認します。

ファイルシステムエラーはないかもしれませんが、D状態（I / Oを待機中）のプロセスが多数あり、カーネルが長い待機時間を通知しているため、ログにその警告が表示されるはずです。

このエラーは、プロセスがディスクにアクセスするのに非常に長い時間（120秒）待機していることを示しています。これは、プロセスに応答するにはディスクがビジーである非常に混雑したサーバーで発生します。

vmstatの下の「Waiting」をチェックすることで確認できます。