Linux Gazette 2005年７月投稿記事
目次
サーバから発信される不正使用－警告－迷惑メール
顧客様,
貴殿に割当られているIPアドレスから、お節介な電子メールが発信されているとのの苦情をNOC が受け付けたのでご連絡します。
======================
こうしてウエブサーバ管理者の悪夢が始まる。続いてサーバを閉じるとのスパムコップからの通知が来る。続いて、AOLアカウントにメールが送れないとのサポート切符。
一体何が起こったのだ？
私は、Apache 、PHP 4.3.10 及び Qメールを（qpsmtpdで)走らせるレッドハット・マシンを管理している。私も、NOCの警告メール又はメール待ち行列の何れかから受け取ったヘッダのある迷惑メールのコピイを持っている。この記事では、私のウエブサーバで迷惑メール発信者の追跡に使った秘訣を、簡単に述べる。これは基本的に迷惑メールの発信元を探り当てるのに役立つ。この記事は、予防ではなく、探索と複旧に役立つ手順を含む。
手順を示せ
最初で最も分かり切った秘訣は、メール内容を読んでドメイン名の手掛かりを探すこと。迷惑メール送信者は、メールの中に沢山のURLやメールアドレスを残していることが多い。URLがサーバ内のドメインを指しているときは、これが手掛かりになる。だが、URLがサーバ内のドメインを指していないときどうするか。ここで工夫をする。
工夫は、迷惑メール内容により、基本的に二つに分かれる。
1)メールヘッダに示されるユーザID
最初のステップは、qmailキューの中でユーザIDを探すことだ。
----------------------
Received: (qmail 7984 invoked by uid 188); Thu, 14 Jul
2005 10:15:06 -0800
-----------------------
qmailプロセスを呼出したユーザIDをメールヘッダから入手する。 /etc/passwordの中でuidを検索する( grep を使うと速い)。運が良いと、uidはサーバ内の人間ユーザである。人間ユーザは、人間に関連付けるシステムユーザである。例えば、apache , qmaildはユーザだが人間ではない、一方john やsojishは人間ユーザだ。迷惑メールの作者が分かったら、ユーザファイルの分離は簡単だし、必要なら応急処置としてそのユーザを差し止める。
サーバで
suEXEC を有効にしているときは、ウエブスペースファイルも点検して、迷惑メール作成方法を解明する必要がある。私は、suEXECを cgi-bin 用には有効にしているが、php用には有効にしていない。したがって、具体的なuidが入手出来るときは、ユーザのcgiスクリプトを点検する。CGIスクリプトを用いる迷惑メールに共通する例は、正しくコンフィギュアされていない
FormMail スクリプトを通じていることである。
2) ユーザIDはApacheのものである。
メールヘッダで入手出来るユーザIDがapacheのものである。だが、apacheは人間ユーザでないので、自分では迷惑メールを作成することが出来ない。つまり、apacheの裏でひねくれた人間の脳が迷惑メールを作っていることを意味する。ひねくれた脳が誰のものかを推測することは出来ない。apacheの働きの基本概念を用いて逆行分析をしなければならない。メールを送るためにはapacheが電子メール内容を読めなければならない。apacheがその内容を読むあらゆる可能性を考えて見た。apacheが読む原資料によって、あらゆる可能性を三つの範疇に分類した：
・a) Eメール内容は、根本の文書で入手可能 ( HTML又はテキストファイルの下書きで）
・b) Eメール内容は、データベースで入手可能
・c) Eメール内容は、フォームに対し動的に与えられる（HTMLフォームを通じて与える）
2.a) Eメール内容は、根本の文書で入手可能
何故か分からないが、この考えが何時も最初に浮かぶ。Eメール内容がウエブ空間で入手可能と推定する。HTMLでも単なるテキストファイルでも何でも構わない。そのEメール内容を持っている仮想ホストをあぶり出す。あぶり出しには大変な努力が必要だ。
Eメール内容を検索したり元のヘッダのTO部分を見たり、仮想ホストが1000人もいると大変な労力なので、私は他に方法がないときしかこの方法を使わない。
2.b) Eメール内容は、データベースで入手可能
迷惑メール発信者は、電子メール内容を自分の文書ルートに持つことは、秘密が暴れ易いことを知っている。そこで、それを隠そうとする。隠素ことが出来て、十分に速くアクセスすることが出来るのは、データベースだ。どの共有ウエブサーバも、そのユーザにデータベースへのアクセスを提供する。そこで、迷惑メール発信者は、メール内容とメールアドレス全部をデータベース表の中にセーブする。その上で、php又はcgiの極めて簡単なデータベーススクリプトを用いて迷惑メール発信を開始する。これが、面倒に巻き込まれる始まりだ。
私は、MySqlでLinux を使用する。最初におこなうのは、MySqlデータベースを記憶するディレクトリに行って検索することだ。手軽なコマンドは
$ cd /var/lib/mysql
$ grep "spam_mail_content" ./* -r or "to_address_in_spam" ./* -r
神様が助けて下さるか、迷惑メール発信者が愚かなら、データベース名が判る。データベース所有者と仮想ホストをを割り出すのは簡単だ。心臓の強い工夫だが、結果は出る。
2.c) Eメール内容は、フォーム又はスクリプトに対し動的に与えられる（HTMLフォームを通じて示される）
これは迷惑メール作成者が考える最も普通の攻撃方法だ。何も痕跡を残さないと考えるし、殆どの場合、その通りだ。迷惑メール作成者は、電子メール内容とアドレスを処理するスクリプトに電子メール内容とアドレスを書込む。これは、極めて簡単なHTMLフォームで構わないか又は、ウエブマスターの知らない何か標準スクリプトの弱点を悪用する。一度、「電子メールIDのリスト」又は「それのあるデータベース」を求めるPHPフォームを見て仰天したことがある。では、そのスクリプトを追跡する方法は？
文書ルート又はmysqの中にある電子メール内容を検索するのは、何の結果ももたらさない。それでもならず者はフォーム内容を一時ファイルにセーブしている。そこで、一時ファイルの中を検索する。通常、ならず者の一時ファイルは inside /tmpディレクトリにある。grep inside /tmpをおこなって、電子メールの内容を読む。サンプルを示す。
---------
[root@my_server /tmp]# grep "J Crew" ./* -r -l
./20050708-163842-68.47.122.xx-request_body-BkhAnH
----------
The file was opened to read , and it contained details like ..
----------
Content-Disposition: form-data; name="EmailIDs
----------
これが、探している手掛かりだ。nameは、フォーム又はスクリプトに渡された引数にで使用されるかINPUTの実際の名称だ。仮想ホストの文書ルートの中でそのnameを検索する。だが、2a）と違って、ここには確実に電子メール内容を受け入れるフォームがある。
点検する前に一時ファイルが削除されていたらどうするとの疑問が浮かぶかも知れない。迷惑メールが、極めて少数の引数しか示さないときはどうするか？それらについては、祈るだけだ。ならず者サーバ状態を連続的に点検して、何か作られた「POST」を捕まえる。これには根気と集中力が要る。
まとめ
目を大きく開いて、根気よく隠れた手掛かりを探がせば、迷惑メール発信者は容易に捕まえることが出来る。システム管理者より賢い迷惑メール発信者はいない。油断をしているから入り込まれる。迷惑メール発信者を追い掛け、捕まえ、殺すのは、システム管理者の特質でなければならない。
注記：上記の工夫は、迷惑メール発信者捕獲の唯一の方法であるとか、全ての方法であるとかは、主張しない。
RHEL AS 4 環境におけるOracle10g 10.2.0.1のため
マスター・グループを殺さない新規マスターサイトの追加
この技術実験は：
http://www.linuxgazette.com/node/9855
に続く。三つのデータベース全部は RHEL 4 環境内のASMである。
二つのサイトの間の非同期複数マスター複写をOKに設定して、
第三の追加が標準ガイドラインにしたがうのをこころみる：
ステップ１．設定：
１．新規マスターファイルに複写アドミニストレータ
２．既存マスターサイトそれぞれから新規マスターサイトに対する計画的リンク
３．新規マスターサイトから既存マスターサイトそれぞれに対する計画的リンク
４．新規マスターサイトにおける計画的パージジョブ
Status OK
ステップ２．CONNECT repadmin/repadmin@orcldata (MasterDef Site)
BEGIN
DBMS_REPCAT.SPECIFY_NEW_MASTERS (
gname => 'hr_repg',
master_list => 'qws3data');
END;
Status OK
次のステップ：－
variable masterdef_flashback_scn number;
variable extension_id varchar2(50);
BEGIN
DBMS_REPCAT.ADD_NEW_MASTERS (
export_required => true,
available_master_list => 'qws3data',
masterdef_flashback_scn => :masterdef_flashback_scn,
extension_id => : extension_id,
break_trans_to_masterdef => false,
break_trans_to_new_masters => false,
percentage_for_catchup_mdef => 80,
cycle_seconds_mdef => 60,
percentage_for_catchup_new => 80,
cycle_seconds_new => 60);
END;
PL/SQL プロシージャ完了 OK
DBA_REPCATLOGから count(*)を選ぶ；
"0" が得るれる
各データベースにディレクトリオブジェクトを作成。
CONNECT SYSTEM/drbrxa@qws3data;
CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir';
CONNECT SYSTEM/drbrxa@orcldata;
CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir';
マスター定義データベースにテーブルのオブジェクトレベル・エキスポートを実行
SELECT FLASHBACK_SCN FROM DBA_REPEXTENSIONS;
497533
$export ORACLE_SID=orcldata
$expdp system/drbrxa TABLES=SCOTT.DEPT,SCOTT.EMP,DIRECTORY=DPUMP_DIR
DUMPFILE=scott_tables.dmp CONTENT=data_only FLASHBACK_SCN=497533
マスター定義サイトにおいて伝搬を再開
CONNECT repadmin/repadmin@orcldata; (MasterDef Site)
BEGIN
DBMS_REPCAT.RESUME_PROPAGATION_TO_MDEF (
extension_id => :extension_id);
END;
エキスポート・ダンプファイルを新規マスターサイトに転送
新規マスターサイトにおいてオブジェクトレベル・インスポートを実行
$export ORACLE_SID=qws3data
$impdp system/drbrxa TABLES=SCOTT.DEPT,SCOTT.EMP, DIRECTORY=DPUMP_DIR
DUMPFILE=scott_tables.dmp CONTENT=data_only TABLE_EXISTS_ACTION=append
Allow new masters to receive deferred transactions
CONNECT repadmin/repadmin@qws3data; (Newly added site)
BEGIN
DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER (
extension_id => :extension_id);
END;
注記：－
新規サイトにはシリアル伝搬は働かない。パラレルを使用する。
デル・パワーエッジ 1550 上のSUSE 企業サーバ（評価）版
７月７日は、SUSE LINUXエンタープライズ・サーバ9を古いデル・パワーエッジ1550に搭載することから始まった。
ペンチアムⅢプロセッサに、SCSIハードディスクドライブ１台（RAID構成なし）512MB RAMの着いたサーバに、全部を接続して、小型クライアントサーバネットワーク作るのに役立つと考えてイーサネット交換を設けた。初期画面に後に、最初のCD（SUSE エンタープライズ・サーバはCD４枚）で立ち上げた。ハードドライブを見出せない（ハードドライブが無い）とのメッセージが出た。２度やり直したが結果は同じ。その内、後処理の間に、SCSIのASYNプロセスをスタート出来ないと言っていたのを思い出した。ハードドライブが悪いのかと思って、別のサーバに着いていたものと交換した。今度は、ハードドライブを見出した。次の、つまり四番目の画面で、各種オプションのうち、現在のま基本(Basic)で搭載して良いかか聞いて来た。以前に搭載したとき、基本にしたら、基本パケージのコンパイルの間に、PHPソースコードをコンパイルしようとする度に、コンパイラ搭載後であっても、コンパイラが見付からぬと言って来た。そこで、今回は完全(full)をクリックした。約１時間半でOSを完全にロードした。搭載は楽だったが、Mozillaでインターネットに接続するのに苦労した。Mozillaをコンフィギュアしようとしたが、プロキシサーバを聞くドロップダウン・メニューが見付からない（いつもInternet Explorer と Konqueror で構成している）。ヘルプファイルを読んで、手動プロキシ設定はブラウザのファイルタブにあり、プロキシ設定にはダブルクリックが必要と、判った。
