Tripwireを使用してUbuntuVPS上のサーバー侵入を検出する方法
ステータス:非推奨
この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。
理由:
Ubuntu 12.04は2017年4月28日に保守終了(EOL)に達しました and no longer receives security patches or updates. This guide is no longer maintained.
代わりに参照してください:このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。
序章
オンラインサーバーを管理する場合、セキュリティは非常に複雑な問題です。 ファイアウォール、fail2banポリシー、セキュリティで保護されたサービス、およびアプリケーションのロックダウンを構成することは可能ですが、すべての攻撃を効果的にブロックしたかどうかを確実に知ることは困難です。
ホストベースの侵入検知システム(HIDS)は、コンピューターのファイルシステムと構成に関する詳細を収集することで機能します。 次に、この情報を保存して、システムの現在の状態を参照および検証します。 正常な状態と現在の状態の間に変化が見つかった場合は、セキュリティが侵害されている可能性があります。
Linuxで人気のあるホストベースの侵入検知システムはtripwireです。 このソフトウェアは、不正な変更が発生したかどうかを検出するために、さまざまなファイルシステムデータポイントを追跡できます。
この記事では、Ubuntu12.04インストールにtripwireをインストールして構成する方法について説明します。 侵入検知システムの性質上、サーバーの作成後すぐにこのガイドを実行して、ファイルシステムがクリーンであることを確認することをお勧めします。
Tripwireをインストールします
幸い、tripwireはUbuntuのデフォルトのリポジトリにあります。 apt-get
と入力すると、次のようにインストールできます。
sudo apt-get update
sudo apt-get install tripwire
このインストールでは、必要なパッケージのかなりの構成が実行されます。
まず、プルインされるメールアプリケーションを依存関係として構成します。 電子メール通知を構成する場合は、「インターネットサイト」を選択します。
インストール中にパスフレーズを選択するかどうかを尋ねられます。 これらのプロンプトの両方に対して「はい」を選択します。 構成ファイルを再構築できるかどうかを尋ねられます。 「はい」を選択します。 ポリシーファイルについても同様の質問があります。 繰り返しますが、「はい」と答えてください。
次に、サイトキーパスフレーズを選択して確認するように求められます。 Tripwireは、2つのキーを使用して構成ファイルを保護します。
-
サイトキー:このキーは、構成ファイルを保護するために使用されます。 構成ファイルが変更されていないことを確認する必要があります。変更されていない場合、検出システム全体が信頼できません。 同じ構成ファイルを複数のサーバーで使用できるため、このキーはサーバー間で使用できます。
-
ローカルキー:このキーは、バイナリを実行するために各マシンで使用されます。 これは、バイナリが同意なしに実行されないようにするために必要です。
最初にサイトキーのパスフレーズを選択して確認し、次にローカルキーのパスフレーズを選択して確認します。 必ず強力なパスフレーズを選択してください。
データベースを初期化する
インストールに続いて、インストールを初期化して構成する必要があります。 ほとんどのセキュリティプログラムと同様に、tripwireには一般的なデフォルトが付属していますが、特定のインストールに合わせて微調整する必要がある場合があります。
まず、インストール中にポリシーファイルを作成するために[はい]を選択しなかった場合は、次のコマンドを発行して作成できます。
sudo twadmin --create-polfile /etc/tripwire/twpol.txt
以前に構成したサイトパスフレーズの入力を求められます。
これにより、/etc/tripwire/
ディレクトリで指定したプレーンテキストから暗号化されたポリシーファイルが作成されます。 この暗号化されたファイルは、tripwireがチェックを実行するときに実際に読み取るものです。
これで、tripwireがシステムの検証に使用するデータベースを初期化できます。 これは、先ほど開始したポリシーファイルを使用し、その中で指定されているポイントをチェックします。
このファイルはまだシステムに合わせて調整されていないため、多くの警告、誤検知、およびエラーが発生します。 これらを参照として使用して、構成ファイルをすぐに微調整します。
データベースを初期化する基本的な方法は、次のコマンドを実行することです。
sudo tripwire --init
これにより、データベースファイルが作成され、構成で調整する必要がある事項について不平が言われます。
結果を保存して構成の決定を通知するため、ファイルに言及しているインスタンスを取得して、tripwire構成ディレクトリ内のファイルに配置できます。 チェックを実行して、リストされているファイルをtripwireconfigディレクトリのtest_results
というファイルに配置できます。
sudo sh -c 'tripwire --check | grep Filename > test_results'
このファイルを表示すると、次のようなエントリが表示されます。
less /etc/tripwire/test_results
Filename: /etc/rc.boot
Filename: /root/mail
Filename: /root/Mail
Filename: /root/.xsession-errors
. . .
システムに一致するようにポリシーファイルを構成する
これで、tripwireを開始するファイルのリストができたので、ポリシーファイルを調べて編集し、これらの誤検知を取り除くことができます。
root権限でエディターでプレーンテキストポリシーを開きます。
sudo nano /etc/tripwire/twpol.txt
test_results
ファイルで返された各ファイルを検索します。 一致する行をすべてコメントアウトします。
「ブートスクリプト」セクションでは、/etc/rc.boot
行をコメントアウトする必要があります。これは、Ubuntuシステムには存在しないためです。
(ルール名=「ブートスクリプト」、重大度= $(SIG_HI)){/etc/init.d-> $(SEC_BIN); # / etc / rc.boot-> $(SEC_BIN); /etc/rcS.d-> $(SEC_BIN);
/root
ホームディレクトリには、システムでコメントアウトする必要のあるファイルがたくさんありました。 システムに存在しないものはすべてコメントアウトする必要があります。
(ルール名=「ルート構成ファイル」、重大度= 100){/ root-> $(SEC_CRIT); #/ rootへのすべての追加をキャッチ#/ root / mail-> $(SEC_CONFIG); #/ root / Mail-> $(SEC_CONFIG); #/ root / .xsession-errors-> $(SEC_CONFIG); #/ root / .xauth-> $(SEC_CONFIG); #/ root / .tcshrc-> $(SEC_CONFIG); #/ root / .sawfish-> $(SEC_CONFIG); #/ root / .pinerc-> $(SEC_CONFIG); #/ root / .mc-> $(SEC_CONFIG); #/root/.gnome_private-> $(SEC_CONFIG); #/ root / .gnome-desktop-> $(SEC_CONFIG); #/ root / .gnome-> $(SEC_CONFIG); #/ root / .esd_auth-> $(SEC_CONFIG); #/ root / .elm-> $(SEC_CONFIG); #/ root / .cshrc-> $(SEC_CONFIG); /root/.bashrc-> $(SEC_CONFIG); #/ root / .bash_profile-> $(SEC_CONFIG); #/ root / .bash_logout-> $(SEC_CONFIG); /root/.bash_history-> $(SEC_CONFIG); #/ root / .amandahosts-> $(SEC_CONFIG); #/ root / .addressbook.lu-> $(SEC_CONFIG); #/ root / .addressbook-> $(SEC_CONFIG); #/ root / .Xresources-> $(SEC_CONFIG); #/ root / .Xauthority-> $(SEC_CONFIG)-i; #ログイン時にiノード番号を変更します#/ root / .ICEauthority-> $(SEC_CONFIG); }
私のチェックの最後の部分は、/proc
ファイルシステムのファイル記述子について不平を言っていました。 これらのファイルは常に変更されるため、構成をそのままにしておくと、定期的に誤検知が発生します。
「デバイスとカーネルの情報」セクションでは、次のことがわかります。/proc
ファイルシステムがチェック対象としてリストされています。
(
rulename = "Devices & Kernel information",
severity = $(SIG_HI),
)
{
/dev -> $(Device) ;
/proc -> $(Device) ;
}
ただし、これにより、その下のすべてのファイルがチェックされます。 特にそれは望んでいません。 代わりに、この仕様を削除し、doで確認する/proc
の下のすべてのディレクトリの構成オプションを追加します。
{/ dev-> $(デバイス); #/ proc-> $(デバイス); / proc / devices-> $(デバイス); / proc / net-> $(デバイス); / proc / tty-> $(デバイス); / proc / sys-> $(デバイス); / proc / cpuinfo-> $(デバイス); / proc / modules-> $(デバイス); / proc / mounts-> $(デバイス); / proc / dma-> $(デバイス); / proc / filesystems-> $(デバイス); / proc / Interrupts-> $(デバイス); / proc / ioports-> $(デバイス); / proc / scsi-> $(デバイス); / proc / kcore-> $(デバイス); / proc / self-> $(デバイス); / proc / kmsg-> $(デバイス); / proc / stat-> $(デバイス); / proc / loadavg-> $(デバイス); / proc / uptime-> $(デバイス); / proc / locks-> $(デバイス); / proc / meminfo-> $(デバイス); / proc / misc-> $(デバイス); }
ファイルのこの部分にいる間、/dev/pts
ファイルシステムで何かをしたいと思います。 Tripwireは、/dev
をチェックするように指示され、/dev/pts
は別のファイルシステム上にあり、指定されない限り入力されないため、デフォルトではその場所をチェックしません。 これもチェックするようにtripwireを取得するには、ここで明示的に名前を付けることができます。
{/ dev-> $(デバイス); / dev / pts-> $(デバイス); #/ proc-> $(デバイス); / proc / devices-> $(デバイス); / proc / net-> $(デバイス); / proc / tty-> $(デバイス); 。 . .
最後にコメントアウトするのは、/var/run
行と/var/lock
行です。これにより、システムはサービスによる通常のファイルシステムの変更にフラグを立てません。
(ルール名=「システムブートの変更」、重大度= $(SIG_HI)){ #/ var / lock-> $(SEC_CONFIG); #/ var / run-> $(SEC_CONFIG); #デーモンPID / var / log-> $(SEC_CONFIG); }
編集が終了したら、ファイルを保存して閉じます。
ファイルが構成されたので、tripwireが実際に読み取る暗号化されたポリシーファイルを再作成して、ファイルを実装する必要があります。
sudo twadmin -m P /etc/tripwire/twpol.txt
これを作成したら、データベースを再初期化してポリシーを実装する必要があります。
sudo tripwire --init
Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/tripit.twd
The database was successfully generated.
以前に受け取ったすべての警告は、今は消えているはずです。 それでも警告が表示される場合は、警告がなくなるまで/etc/tripwire/twpol.txt
ファイルの編集を続ける必要があります。
構成を確認する
データベースの初期化でファイルについて文句を言わなかった場合は、この時点で構成がシステムと一致している必要があります。 ただし、tripwireレポートがどのように表示されるか、および本当に警告がないかどうかを確認するためにチェックを実行する必要があります。
チェックの基本的な構文は次のとおりです。
sudo tripwire --check
システムにエラーや変更が見つからなかったことを示すレポート出力が画面に表示されます。
これが完了すると、構成が正しいことをかなり確信できます。 システムから機密情報を削除するために、ファイルを少しクリーンアップする必要があります。
作成したtest_results
ファイルを削除できます。
sudo rm /etc/tripwire/test_results
もう1つできることは、実際のプレーンテキスト構成ファイルを削除することです。 パスワードを使用して暗号化されたファイルから自由に生成できるため、これを安全に行うことができます。
プレーンテキストファイルを再生成するために必要なのは、暗号化されたバージョンを生成する場合とほぼ同じ方法で、暗号化されたファイルをtwadminに渡すことだけです。 もう一度プレーンテキストファイルにパイプします。
sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'
テキストバージョンをバックアップ場所に移動して再作成することにより、これを今すぐテストします。
sudo mv /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak
sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'
正常に機能した場合は、プレーンテキストファイルを安全に削除できます。
sudo rm /etc/tripwire/twpol.txt
sudo rm /etc/tripwire/twpol.txt.bak
電子メール通知を設定する
毎日実行するようにtripwireを構成し、自動通知も実装します。 プロセス中に、システムに変更を加えたときにデータベースを更新する方法をテストできます。
mail
コマンドを使用して、通知を電子メールアドレスにメールで送信します。 これは現在システムにインストールされていないため、リポジトリからダウンロードする必要があります。
これにより、トリップワイヤーがシステムの変化にどのように反応するかを確認する絶好の機会が得られます。
次のようなファイルをインストールします。
sudo apt-get install mailutils
そのコマンドがインストールされたので、トリップワイヤレポートをメールで送信するシステムの機能をテストしてみましょう。 tripwireに通知せずに新しいソフトウェアをインストールしたばかりなので、このレポートにも警告と変更が含まれます。
sudo tripwire --check | mail-s「Tripwireレポートuname -n
」 your_email @ドメイン .com
メッセージを送信するためにインストールしたばかりの新しいメールソフトウェアの詳細が記載されたレポートが、まもなくメールで届きます。 これはいい。 これは、tripwireがファイルシステムの変更を取得しており、メールソフトウェアも機能していることを意味します。
これで、データベースを更新するための対話型チェックを実行して、ソフトウェアの変更を「大丈夫」にする必要があります。
これを行うには、次のように入力します。
sudo tripwire --check --interactive
これにより、通常と同じテストが実行されますが、最後に、レポートを画面に出力する代わりに、テキストファイルにコピーされ、デフォルトのエディターで開かれます。
このレポートでは、変更された各ファイルについて非常に詳細に説明しています。 実際、私のマシンでは、生成されたレポートは2,275行の長さでした。 この量の情報は、実際のセキュリティ問題が発生した場合に非常に役立ちますが、私たちの場合、通常、ほとんどの場合、それほど興味深いものではありません。
重要な部分は上部にあります。 いくつかの紹介情報の後に、追加または変更されたファイルごとにチェックボックスが付いた行が表示されます。
Rule Name: Other binaries (/usr/sbin)
Severity Level: 66
-------------------------------------------------------------------------------
Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.
Added:
[x] "/usr/sbin/maidag"
Modified:
[x] "/usr/sbin"
. . .
これらのチェックボックスは、これらの変更を許可するようにデータベースを更新することを示しています。 「x」が含まれているすべてのボックスを検索し、それらが行った変更であるか、問題がないことを確認する必要があります。
変更に問題がある場合は、ボックスから「x」を削除すると、そのファイルはデータベースで更新されません。 これにより、このファイルは次回の実行時に引き続きtripwireにフラグを立てます。
どのファイルの変更で問題がないかを判断したら、ファイルを保存して閉じることができます。
この時点で、tripwireがデータベースファイルを更新できるように、ローカルパスフレーズを要求します。
すべての変更を受け入れた場合、このコマンドを再実行すると、レポートははるかに短くなり、変更はリストされないはずです。
cronでTripwireを自動化する
この機能がすべて手動で機能することを確認したので、毎朝トリップワイヤーチェックを実行するようにcronジョブを設定できます。
システムのcronjobへの編集はシステムの更新で消去される可能性があるため、rootのcrontabを使用します。
次のコマンドを発行して、rootに既にcrontabがあるかどうかを確認します。
sudo crontab -l
crontabが存在する場合は、それをファイルにパイプしてバックアップする必要があります。
sudo sh -c 'crontab -l > crontab.bad'
その後、次のように入力してcrontabを編集できます。
sudo crontab -e
crontabを初めて実行する場合は、使用するエディターを尋ねられます。 別のエディターを優先しない場合は、通常、nanoが安全な選択です。
その後、tripwireを自動化できるファイルに移動します。 毎日tripwireを実行するので、実行する時間を決定するだけで済みます。 通常、サービスは忙しい時間を邪魔しないようにピーク時以外に実行されます。
使用する必要のある形式はmin hour * * * command
です。 使用するコマンドは、以前にレポートをメールで送信するために使用したものと同じです。 これはrootとして実行されるため、sudoを使用する必要はありません。
毎日午前3時30分にトリップワイヤーを実行するには、ファイルに次のような行を配置できます。
30 3 * * * / usr / sbin / tripwire --check | mail-s「Tripwireレポートuname -n
」 your_email @ドメイン .com
これはお好みに合わせて調整できます。
結論
これで、ファイルシステムの変更に関するレポートを送信する自動侵入検知システムができました。 電子メールで送信されたレポートを定期的に確認し、変更が検出された場合は、tripwireデータベースを更新して変更を確認するか、疑わしいアクティビティを調査する必要があります。