今回投稿の Tripwire と cron.daily でのメール送信ポイント
Tripwire コマンドではなく、cron.daily 実行時の出力をメールするようにいたします。 よって、Tripwire 実行時のメール送信処理に関する次の 2 か所を変更することがポイントですの♪
- /etc/cron.daily/tripwire-check のメール送信オプションを外す。
- Tripwire ポリシーファイル tw.pol の emailto 属性を削除する。
具体的に行ったこと
- cron.daily の Tripwire スクリプトで指定しているメールオプションを外し、メールが cron.daily 実行時の出力内容となることを確認する。← 失敗しました＞＜。そしてここから困難への対処が始まる！
- Tripwire ポリシーファイルの送信メールアドレス指定を消す。
この順番でステップ♪ステップ♪ちょっとずつ！試しながら変更していきましたの。
1. cron.daily の Tripwire スクリプトで指定しているメールオプションを外す
vim /etc/cron.daily/tripwire-check
cron.daily で Tripwire のスクリプトが実行された時に、cron からのメールのみを受け取り、Tripwire からのメールを受け取らないようにします。 そのために、実行時のオプションからメールを送信する設定「–email-report」を削除します。
#!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
echo "**** Error: Tripwire database for ${HOST_NAME} not found. ****"
echo "**** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". ****"
else
test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check --email-report
fi
↓
#!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
echo "**** Error: Tripwire database for ${HOST_NAME} not found. ****"
echo "**** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". ****"
else
test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check
fi
なお、この編集内容は、以前行った作業を取りやめる内容となりますの。前の作業では、メールを送信するようにしたくて、メールオプション「–email-report」をあえて付けたのでした。
これで、Tripwire からのメールは送信されなくなりました。そして、cron 実行時の出力内容のみがメールされるようになら、、、、、、なーい＞＜！ですの！
あわわ。
ま、まずは現状復帰するために /etc/cron.daily/tripwire-check のメールを送信する設定「–email-report」を元に戻します。
★困難へ立ち向かう 1 ★cron の設定を確認する
cron 実行時の設定を確認いたしますの。コマンドはこちら。
less /etc/crontab
内容を見てみますと、メールは確かに「root」宛に送信するように設定されております。
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 12 * * * * root run-parts /etc/cron.hourly 0 2 * * * root run-parts /etc/cron.daily 33 2 * * 0 root run-parts /etc/cron.weekly 58 1 11 * * root run-parts /etc/cron.monthly
★困難へ立ち向かう 2 ★メールログを確認する
続いて、メールログを見ますと気になる記述が！「stat=Service unavailable」となっております。
Dec 28 02:02:17 oki2a24 sendmail[54583]: rBRH2Elj054582: to=test@example.com, ctladdr=<root@oki2a24.com> (0/0), delay=00:00:03, xdelay=00:00:03, mailer=esmtp, pri=36542, relay=gmail-smtp-in.l.google.com. [11.222.333.44], dsn=5.0.0, stat=Service unavailable
不可解なのは、この直前、02:01 に Logwatch のメールを送信したいたのですが、このときは成功、つまり「stat=Sent」だったのです。
Dec 28 02:01:45 oki2a24 sendmail[52415]: rBRH1gek052414: to=test@example.com, ctladdr=<root@oki2a24.com> (0/0), delay=00:00:03, xdelay=00:00:02, mailer=esmtp, pri=42052, relay=gmail-smtp-in.l.google.com. [11.222.333.44], dsn=2.0.0, stat=Sent (OK 1388163705 yd9si24917874pab.205 - gsmtp)
これは偶然失敗しただけ？それとも、cron や Sendmail の設定ミスなのでしょうか？
cron の時だけ特別なメール設定が必要なのかしら？エラーの内容は？少し調べてみて、参考になりそうなページがございましたので、メモしておきますわ。
あ、そうだ。Gmail の迷惑メールフォルダ、見てみましょう。。。
★困難へ立ち向かう 3 ★Gmail の迷惑メールフォルダにぶち込まれておりましたの！
はい、ありましたわ！cron の出力を Gmail に送信したメールは、Gmail 側で拒否されておりましたの！
The original message was received at Sat, 28 Dec 2013 02:02:14 +0900
from oki2a24.com [127.0.0.1]
----- The following addresses had permanent fatal errors -----
oki2a24@gmail.com
(reason: 550-5.7.1 [27.120.110.175 12] Our system has detected that this message is)
(expanded from: oki2a24)
----- Transcript of session follows -----
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.1 [27.120.110.175 12] Our system has detected that this message is
<<< 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
<<< 550-5.7.1 this message has been blocked. Please visit
<<< 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
<<< 550 5.7.1 more information. xa2si24913491pab.113 - gsmtp
554 5.0.0 Service unavailable
Final-Recipient: RFC822; root@oki2a24.com
X-Actual-Recipient: RFC822; oki2a24@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 550-5.7.1 [27.120.110.175 12] Our system has detected that this message is
Last-Attempt-Date: Sat, 28 Dec 2013 02:02:17 +0900
---------- 転送メッセージ ----------
From: root@oki2a24.com (Cron Daemon)
To: root@oki2a24.com
… 略 …
Logwatch のメールは届くのに、cron のメールは届かない。あるときだけ送信メール情報が変わってしまうような、Sendmail の設定ミスかしら？
そうであるとするならば、次のページが参考になりそうですの。ポイントは、メールヘッダー情報！
スパム認定された cron のメール、Tripwire とともに cron からも送信できていたメール、これらのメッセージのソースを見ることで原因に迫れないでしょうか？
★困難へ立ち向かう 4 ★メールヘッダの「Received: from」が怪しいですの！
Tripwire とともに cron からも送信できていたメールはこうですの。
Received: from oki2a24.com (oki2a24.com [127.0.0.1]) by oki2a24.com (8.13.8/8.13.8) with ESMTP id rBQH28pr040136
そしてスパム認定された cron のメールは、こう。
Received: from localhost (localhost) by oki2a24.com (8.13.8/8.13.8) id rBRH2Hlj054583;
localhost というサーバから送信されたメールと Gmail に判断されているということだと思いますの。localhost を経由することで偽装が施されたメールと判断され、スパムだと判定された、原因はこのあたりなのだと思います。
- root →転送→ user →転送→ Gmail アドレス
最初の転送時で root から user へ転送しておりますが、これは oki2a24.com メールサーバ内での処理、localhost 内での処理です。
一度 /etc/aliases の設定に従って同一マシン内のユーザ間でメールを転送してから、更に別の場所に転送した場合、転送元は localhost となる、こういうことでしょうね。
このように考えたきっかけとして、次のページが参考になりました。具体的に localhost から別のドメインに変更する方法が解説されております。
★困難へ立ち向かう 5 ★届いたメールヘッダーの Received と Sendmail 送信ログを突き合わせてちょっと考えますわ♪
では Tripwire とともに cron からも送信されていたメールはなぜ送信できていたのかしら？
Tripwire からのメールは、oki2a24.com メールサーバから別のユーザに転送されずに直接 Gmail アドレスに送信されます。この設定が cron メールにも適用されたと考えればよいのかしら？
そうしますと、sendmail は 1 回の送信処理で 2 通のメールを送っていればそのような事が可能そうです。なんだか乱暴ですし、穴もありますけれども、考えを進めるきっかけとしてそのような仮説を立ててみます。
そんな予想を元に、届いたメールヘッダの Received を確認します。両方共、Tripwire からのメールも、cron からのメールも Received: from oki2a24.com でした。
続いて /var/log/maillog を拝見します。
・・・あらら、ダメね。送信処理が 2 回、ログにきちんと記載されております。
★困難へ立ち向かう 6 ★調査の手を一時止めて、その前に施しておく設定ですの。
ふう、今日はここまでといたします。次のように設定して、様子を見てみますの。本当でしたらメールが届いていた元の通りに戻しておきますのが定石ですけれども、いろいろ試したくってわざと設定を変更いたしました。
- /etc/cron.daily/tripwire-check のメール送信オプション「–email-report」を外す
- Tripwire ポリシーファイルの送信先メールアドレス指定を削除
つまり、元々本投稿で変更しようと思っていた内容を全部施してしまって、様子をみましたの♪
・・・あらら。
・・・・・・どうしてかしら？
メール、届きますわね。スパム判定されること無く Gmail に。最終目的の Tripwire からのメールは送られず、cron からのメールのみが送られる状態で。
どうしてかしら？わかりません。
cron に記述した tripwire コマンドのメール送信オプションは削除しておりますので Tripwire ポリシーファイルのメール送信宛先部分は設定してあろうとなかろうと、メールは送られないという意味で関係ないはずです。
であれば、削除した tripwire コマンドのメール送信オプションという変更は、メールがスパム判定された時と同じですから結果が異なるということがわかりません。
と、ともかく、今までの試行錯誤を、困難へ立ち向かった記録として残しておいて、Tripwire ポリシーファイルの変更内容について、次に記しますの。
2. Tripwire ポリシーファイルの送信先メールアドレス指定を消す
- Tripwire ポリシーファイルの最適化
- クリアテキストのポリシーファイルを元にサイトパスフレーズを使ってポリシーファイルの暗号署名（tw.pol）を作成
上記の手順を以前の投稿に従って行いました♪
簡単にコマンドだけ記しますわね♪
# インストール時に付属のサンプルポリシーファイルを最適化 perl /etc/tripwire/twpolmake.pl /etc/tripwire/twpol.txt > /etc/tripwire/twpol.txt.new # ポリシーファイルの暗号署名を作成 # -m P → ポリシーファイル作成 # -c cfgfile, –cfgfile cfgfile → 暗号署名された設定ファイル # -p polfile, –polfile polfile → これから作成する暗号署名されたポリシーファイルのファイル # -S sitekey, –site-keyfile sitekey → サイトキー twadmin -m P -c /etc/tripwire/tw.cfg -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key /etc/tripwire/twpol.txt.new
おわりに
今回の変更は、以前ガンバロ！と自分を鼓舞して編集した内容を、元に戻す行為ですの＞＜。 root へのメールを転送するように設定していれば！cron 実行時の出力内容はメール送信されることを知っていれば！今回の投稿は必要なかったですの＞＜。 くすん＞＜。。。 でも大変勉強になりましたからとっても得しましたの♪
そもそも、なぜ今回の変更をしようと思ったか、最後にそれを整理いたしましょう。
先日、Sendmail の /etc/aliases を編集して root 宛のメールを Gmail に転送するようにいたしました。
その時に、次のことに気が付きましたの♪
- cron.daily の Tripwire 設定で、Tripwire から結果をメールで Gmail に送るように指定していた。
- cron.daily により Tripwire が実行されると cron から結果を root ユーザに送信していた。
1回の改ざんチェックで、同じ結果内容のレポートが 2 回、メールされておりますの！わたくしたちの場合、1 通のみで問題ありませんわ！ そこで、今回の投稿、という流れでしたの♪ ちなみに、Tripwire からのメール、cron からのメール、それぞれのメールの内容を比較してみますと次のように微妙に異なりました。おもしろいですの。
- Tripwire からのメール
改ざん検知されたファイル一覧 無し
改ざん検知されたファイル詳細 有り - cron からのメール 改ざ
検知されたファイル一覧 有り
改ざん検知されたファイル詳細 無し
最後に、他に参考になったページですの♪ありがとう存じます。
以上です。
「【試行錯誤】★11★メールは crontab 結果のみに限定させていただきますわ♪【Tripwire】わたくしだって WORDPRESS サーバの改ざん検知したい！【CENTOS】」への1件の返信
[…] 【試行錯誤】★11★メールは crontab 結果のみに限定させていただきますわ♪【Tripwire】わたくしだって WORDPRESS サーバの改ざん検知したい！【CENTOS】 | oki2a24 […]