Linux の覚え書き

ちょっと前から巷で大騒ぎのBash脆弱性ShellShockについての顛末を。ハッキリ言ってまぁ他人事だと思っていたフシもありまして、実は作業を放り出しッ放しだった訳です。このbashというのはLinuxなどに大抵は入っているパッケージだったりするんですけど、こいつに脆弱性が見つかったということでexploitも公開されちゃっていたりと何気にヤバイ状況ではあったわけです。

Bash 脆弱性 – ShellShockについて分かりやすかったのはこのパージ。

▼ Bash 脆弱性 – ShellShock- (2) CVE-2014-6271 / CVE-2014-7169 は何が危険で問題なのかを検証してみました – CLARA ONLINE techblog

でもって何がヤバイのかは

• リモートで任意のコマンドが実行できてしまう可能性がある。
• Bash は linux 等のシステムで必ずインストールされているパッケージなので、影響が大きい。

ということの様なので早急な対応が必要そうです。

でもってmmaacc.ddo.jpを名乗るこのサーバに異変が見受けられたのが昨日…。後から見つけた限りではその前夜、3日金曜の19時台からだった様なのですが、とにかくサーバにアクセスしようとしてもレスポンスが返ってこない、何も受け付けない…という状態だったわけです。そんな訳で昨日更新しようとしたポストも諦め、何でこんなに重いのか？というところを何となく探し始めたわけですが…。

サーバに仕込んであるHotSaNICの『netstat - TCP connections』が見たことも無い状態になっていましてですね、ははぁ、これが原因か！？となった訳です。でもそもそも、何故この様なことになってしまったのかはよく分かって無かったりするんですが、取りあえずsshで入ってみたいりしてリスタートしようとしてもそのコマンドすら受け付けて貰えず…。

このサーバ、VPSなんで毎週日曜早朝にあらゆるプロセスが強制再起動してるフシがあったのでそこでサーバ自体を再起動させちゃえ…ということで先ずはその辺から作業開始なのでありました。無事、立ち上がって来たところでサボりまくっていたYumを実行、85パッケージほど更新して取りあえずログを漁ってみます。

幸いなことに、サーバの再起動以降は先のSocket statを食いつぶす様な動きは見られないのでログから3日金曜〜4日土曜あたりの動きを追ってみることにしました。

Oct 3 19:52:02 dti-vps-srv★ yum: Updated: bash-3.2-33.el5_11.4.i386

※ ★の位置にはサーバ番号が入っている

ほへ？何ですか？これは？自分ではこの時はサーバを一切触っていないので覚えがないのですが…。まぁ恐らくはサーバの所有者（VPSの提供者）が勝手にアップデートしちゃったに違いありません。緊急性が高く、余所への影響が大きいという判断なのでしょう。

でもね、その後からですよ、先のSocket食いつぶしちゃってたのは。sshで入ろうにも溢れちゃってて繋がらないとか、手の打ちようが無くなっちゃうのでどうしようもなくなっちゃいます。やるならもうちょっとしっかりして欲しいと思うのですが。いや、その前にちゃんと自分で対応しろよ、という声が聞こえて来そうなのでこの辺で終わりにします。まぁ何事も無くて良かった良かったということで。

しばらく放置気味でもあったのでここらでちょっと手を入れました。と言っても、Rejct対象を広げただけなんですが。最近の五月蠅いspam対策ということで対応。

header_checks

## Spamer御用達メーラを弾く /^X-Mailer:.*DouhouHaishin/i REJECT /^X-Mailer:.*Achi-Kochi Mail/i REJECT /^X-Mailer:.*Douhou@Mail/i REJECT /^X-Mailer:.*The Bat!/i REJECT /^X-Mailer:.*Easy DM free/i REJECT /^X-Mailer:.*007 Direct Email Easy/i REJECT # ## ヘッダにアドレスが無いものを弾く /^Return-Path:.*<#.*@.*>/ REJECT # ## 特定の拡張子を含むものを弾く /name=.*\.scr/ REJECT # ## 特定のアドレススパムを弾く /^[Rr]eturn-Path:.*info.*/ REJECT /^[Ff]rom:.*info.*/ REJECT # # ## 特定の差出し及び詐称アドレスを弾く /^[Ff]rom:.*hotmail.co.jp/ REJECT /^[Ff]rom:.*hotmeil.com/ REJECT /^[Ff]rom:.*excite.co.jp/ REJECT /^[Ff]rom:.*yahoo.co.jp/ REJECT /^[Ff]rom:.*yahoo.com/ REJECT /^[Ff]rom:.*yahoo.co.uk/ REJECT /^[Ff]rom:.*livedoor.com/ REJECT /^[Ff]rom:.*.ch/ REJECT /^[Ff]rom:.*.fr/ REJECT /^[Ff]rom:.*.at/ REJECT

とまぁ上の様な感じでバイバイしてもらいます。この後コマンドで、

/usr/sbin/postmap /etc/postfix/header_checks

と上記の様に叩いて「header_checks.db」が出来ればOK。ついでに「reject_sender」の方も追記。

reject_sender

hotmail.com REJECT hotmail.co.jp REJECT yahoo.com REJECT yahoo.co.jp REJECT excite.co.jp REJECT *.ch REJECT *.at REJECT livedoor.com REJECT mailyes.net REJECT 163.com REJECT

と上記のように追記。えぇ、この間社長さんが捕まっちゃった某社のドメインもありますね。大分ガラの悪い方々も流入しているようですし、それなりということでやはりバイバイです。

/usr/sbin/postmap /etc/postfix/reject_sender

こちらも上記のように叩いて「reject_sender.db」を作っておきます。あとはpostfixを再起動すれば出来上がり。あ、ここでは書いてませんけど、「/etc/postfix/main.cf」の方に「header_checks」と「reject_sender」の使い方は書いておかなければなりませんよ。詳しくは過去ログ参照ということで。

スパム受信拒否ルール

## Spamer御用達メーラを弾く
/^X-Mailer:.*DouhouHaishin/i REJECT
/^X-Mailer:.*Achi-Kochi Mail/i REJECT
/^X-Mailer:.*Douhou@Mail/i REJECT
/^X-Mailer:.*The Bat!/i REJECT
/^X-Mailer:.*Easy DM free/i REJECT
/^X-Mailer:.*007 Direct Email Easy/i REJECT
#
## ヘッダにアドレスが無いものを弾く
/^Return-Path:.*&lt;#.*@.*&gt;/ REJECT
#
## 特定の拡張子を含むものを弾く
/name=.*\.scr/ REJECT
#
## 特定のアドレススパムを弾く
/^[Rr]eturn-Path:.*info.*/ REJECT
/^[Ff]rom:.*info.*/ REJECT

やはり、新しい環境には新しめのOSで…ということで「VINE LINUX 3.1CR」導入を検討。今まで2.6CRのまま来てるからそれほど変わらないのだが、メジャーなアップがかかってから早1年が経過しているので、よほどのことが無い限りメンテナンスも後回しになってしまうことが考えられる。よってkernelはそれほど大きく違いが見られないが、その他が大きくバージョンの上がっている3.1CRの方を使った方が良いのではないかとの結論。細かいところでは重たくなっているという噂も見たような気がするのだが、そこは新環境も従来の約倍のスペックを確保したことだしで、なんとか使い物になるのではないかという甘〜い予測を立ててみたりとか。

以前からSmart-UPS 1400（リンク先は後継モデル）という据え置き型の無停電電源を使用していたのだが、ラックの導入を機にSmart-UPS 1400RM（リンク先は後継モデル）を追加することにした。先のモデルはPCサーバならばそれほど設置場所にも困らなかったし、使い勝手はそれなりに良かったのだが、いざラックに…となると、設置に難儀する。どうせサーバも徐々にラックへ移行することを考えれば、UPSもそれなりのものを驕っても良かろうという次第。今まで1台のUPSで、PCサーバ2台、モニタ1台、スィッチやらネットワーク系機器3台をカバーしていたことを考えれば、少しは負荷も分散出来そうな感じではある。

自宅にラックを導入した。22Uほどの手頃なもの。とは言え、やはり場所とりますね。これでサーバ周りとネットワーク周りがすっきりしました。それから同時にLANをギガビット化。難点はギガに対応してない端末が多いこと。何れは置き換えていくことになるんだろうけど、しばらくは100メガものと混在ね。それから今は最小の構成でオールインワン状態なサーバを複数台に分けようかしら。負荷分散ね。これでやっとPCサーバ、減らせるわ。

いちおう、家でも仕事でも使うことが多いのでメモ。

APC

この度 Sun MicrosystemsのJava JDK/JREに含まれる暗号化コンポーネントの一部期限切れによりPowerChute Business Edition v6.x.xにおいて、 2005年7月28日06時43分以降UPSサービスが使用できなくなります。

ちゃっちゃと対応版をダウンロードしませう…ということらしい。

巷じゃ色々と言われてるrm -rfですけど、/. J経由で詳しい実験結果が公開されているのが紹介されていたのでメモ。

What happens when the root does "rm -rf /" ?

UNIX で root が "/bin/rm -rf /" をした場合の結末として、 以下のようになるという主張を実際に見たり聞いたりしたことがあるのですが、 全て明らかに誤りです。 信じてはいけません。…

早い話が、プロセスが立ち上がっているものはそのまま動き続け、墜とすと二度と立ち上がらなくなる…というのが解らしい。記述が2000年2月だから割合早い時期に検証はされているのね。もしやっちゃったら墜とす前に復旧すれば、何事も無かったかの様に振る舞う…かもしれない。この辺は検証されていないので未確認。どうせならここまで検証して欲しいなぁと思ってみたりとか。だったら自分でやれ…というのは無しね。残念ながらそこまでの時間とリソースがございませんでして。

あとでゆっくり読もうかと思ってメモ。

・NETWORKWORLD Online - 連載 Webサーバ最適化マニュアル 第1回 最適化の方向性を考えよう

会社のメールを会社携帯電話に転送する設定。

.procmailrcの記載内容

# cat .procmailrc PATH=/bin:/usr/bin:/usr/local/bin MAILDIR=$HOME/Maildir/ DEFAULT=$MAILDIR LOGFILE=$HOME/procmail.log LOCKFILE=$HOME/.lockmail   :0 Hw : * ! ^[Ff]rom: .*melma@.* * ! ^[Ff]rom: .*ここに@文字列.* ! keitai-no-adoresu@docomo.ne.jp   :0 Hw : /dev/null

このような内容の「.procmailrc」ファイルをHOME Dirに置き、

.forwardの記載内容

\アカウントID "|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #アカウントID"

という「.forward」ファイルを同じくHOME Dirに置いておく。こうすると先の.prcmailrcで指定していた条件にマッチするものまたはマッチしないものを所定の処理させることができる。上の例では、*から始まる行で指定している特定の差出人からのメール以外を、!で指定したアドレスに転送している。/dev/nullの行は、転送対象にならなかったメールがmail boxに2通同じものが来てしまうことを避けるため捨てる処理。*の条件式は正規表現が使えるので、いろんなことを指定出来るらしい…。
何故こんなめんどくさいことを始めたかというと、隣席の某女史が乱発するメールが全て携帯に飛んできて迷惑してるから。要点のみ「必要に応じて」出してくれる分には構わないのだが、何でもかんでもメールだけで済まそうとしてる上に、決めつけ断定押しつけ口調で投げまくってるから読む気も失せる。第一、自分とは直接の担当範囲が異なるし。これが1日に20通を越えると流石に他の大事なメールが埋もれてしまい、支障を来すというのが真相。投げてる本人はそれが「仕事だと自分だけ思ってる」らしいのだが。ついでなので、特定の差出人を複数指定できることから、社外のML系やメルマガ系、業者からのご案内系も全てこちらに指定しておいた。

Postfixねた。/etc/postfix/main.cfにsmtp_client_restrictionsを設定する。

（1）/etc/postfix/reject_senderを作成

/etc/postfix/reject_sender

hotmail.com REJECT
hotmail.co.jp REJECT
yahoo.com REJECT
yahoo.co.jp REJECT

（2）postmapする。これを忘れないように。

postmap

# postmap hash /etc/postfix/reject_sender

（3）main.cfに追記。

/etc/postfix/main.cf

smtpd_client_restrictions =
permit_mynetworks
check_client_access hash:/etc/postfix/reject_sender

（4）ついでに、怪しげな奴もアボーンしたいので同じく追記。

/etc/postfix/main.cf

# 実際存在しないドメイン名が送信元メールアドレスに使われているメールの受信を拒否
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_sender_login_mismatch

（5）postfixを再起動

まだまだよく判っていないのだが、少しずつ、少しずつ。

~/xxxx-ml/config.phの修正

まず、/var/spool/ml/xxxx-ml/cfの一番最後の部分（# YOU CAN EDIT MANUALLY AFTER HERE.以下）に追記。内容はこの辺を参考に。
NONE TITLE
cfの編集が終わったら、
perl /usr/local/fml/makefml update-config.ph xxxx-ml
としてconfig.phを書き出してあげる…と。

なるほど、こうやって作業をするわけね。ということでメモ。

開設当初はテストやら何やらでゴミカウントが膨れ上がっていて…

fmlのナンバリング初期化

$ cd /var/spool/ml/xxxx-ml $ rm -rf seq summary log spool htdocs

ということで正式にアナウンスする前にちょこっと小細工。テストで増えちゃったナンバリングを0に戻して綺麗すっきり。さぁ、始めましょうかの気分をもう一度、なのでありました。