解決策 1:
<オール>解決策 2:
知っています、知っています - しかし、それは本当に偏執的で悲しい真実です;) もちろんたくさんのヒントがありますが、システムが具体的に標的にされていた場合、それを伝えることは不可能かもしれません.完全に安全なものは何もないことを理解しておくとよいでしょう。しかし、より安全に取り組む必要があるため、代わりに他のすべての回答を指摘します;)
システムが侵害された場合、システム ツールを信頼して真実を明らかにすることはできません。
解決策 3:
Tripwire は一般的に使用されるツールです。システム ファイルが変更されたときに通知しますが、明らかに事前にインストールしておく必要があります。それ以外の場合は、知らない新しいユーザー アカウント、認識できない奇妙なプロセスやファイル、明らかな理由もなく帯域幅の使用量が増加しているなどの項目が通常の兆候です。
Zabbix などの他の監視システムは、/etc/passwd などのファイルが変更されたときに警告するように構成できます。
解決策 4:
過去に気になったこと:
- アイドル状態であるべきシステムの高負荷
- 奇妙なセグメンテーション違反。
ls
などの標準ユーティリティから (これは壊れたルート キットで発生する可能性があります) /
の隠しディレクトリ または/var/
(ほとんどのスクリプト キディは、自分の足跡を隠すにはあまりにも愚かで怠け者です)netstat
そこにあってはならない開いているポートを示します- 通常は異なるフレーバーを使用するプロセス リスト内のデーモン (例:
bind
、しかしあなたは常にdjbdns
を使用します )
さらに、ボックスが侵害されているという信頼できる兆候が 1 つあります。システムを継承した管理者の勤勉さ (更新など) に不満がある場合は、注意してください!
解決策 5:
kill
経由でハッキングされたサーバーをチェックする方法があります -
基本的に、「kill -0 $PID」を実行すると、プロセス ID $PID に nop シグナルが送信されます。プロセスが実行中の場合、kill コマンドは正常に終了します。 (FWIW、nop kill シグナルを渡しているため、プロセスには何も起こりません)。プロセスが実行されていない場合、kill コマンドは失敗します (終了ステータスがゼロ未満)。
サーバーがハッキングされたり、ルートキットがインストールされたりすると、最初に行うことの 1 つは、影響を受けるプロセスをプロセス テーブルなどから隠すようにカーネルに指示することです。プロセス。つまり、これは
a) このチェックは詳細なチェックではありません。適切にコード化されたインテリジェントなルートキットにより、カーネルが「プロセスが存在しません」という応答を返し、このチェックが不要になるためです.b) いずれにしても、ハッキングされたサーバーが「悪い」プロセスが実行されています。通常、PID は /proc の下に表示されません。
だから 、これまでここにいた場合、方法は、システムで使用可能なすべてのプロセスを kill -0 し (1 から /proc/sys/kernel/pid_max まで)、実行されているが報告されていないプロセスがあるかどうかを確認することです/プロセス。
いくつかのプロセスが実行中として表示されるが、/proc で報告されない場合、どう見ても問題がある可能性があります。
これをすべて実装する bash スクリプトを次に示します - https://gist.github.com/1032229 。それをいくつかのファイルに保存して実行します。proc で報告されていないプロセスが見つかった場合は、掘り下げ始める手がかりが必要です。