本日未明(バックアップがなかったので0時から4時までの間)、サーバが落ちました。
朝方に再起動してみたときの症状から、まあ今回の原因は八割方PSUと見当はつきましたが、本業が片付かず、危うく日付が変わるかというところでようやく復旧できました。
ただし、メインPC用の補欠PSUで力強く仮運転しているため、明日(1900-1930JST予定)再度落として、パワーが適当で静かなPSUをセットします。
もしデータが壊れている場合は、1日前のですがバックアップがありますのでご連絡ください。
[PSU調達設置・再起動] (2009/6/13 19:10 - 20:25JST)
予定より時間がかかってすみません。
持ってきたPSUの設置自体は問題なかったんですが、RAIDの不調に見舞われたため、RAIDBOXを引っ張り出して調べたりして時間を喰いました。
…結果的に配線ミスが原因でした。
今回ファンコントローラの電源コネクタが二叉になっているのを利用してRAIDBOXに給電しようとしたのが、5Vか12Vのどっちかがうまく出てなかったものと思われます。
「普通そんなことないよなぁ〜」とか思いつつ、PSUの標準のコネクタに余裕があるならそっちで給電するべき、という教訓を得たところ。
…しかし不具合発生時には、ただミラーが2台ともFAILと表示されたので、最悪再セットアップかとちょっと焦りました。再配線と再設置の結果、現在はうまく動いている…ように見えます。
引き続き猛威をふるっているので思わず更新。不謹慎かもしれないが、FSXとかよりよっぽどおもしろい。
いや接続の大半を止められているから笑っていられるんだけど。
参考までに、1月20日23時までの23時間でこの種のメールと思われる接続が約600回あって(リトライ含めたらのべ1100回)、配信まで至ったのが2通。阻止率は実に99.7%。S25Rはいつも以上に大活躍してくれてます。
ところで、450拒絶ログを古い順に並べてみると、興味深いことがわかりました。
…ってことは、スタンドアロンのワームじゃあないですね。すり抜けたメールを見る限りオープンリレーでもなさそうなので、いわゆるBOTNETの可能性が高いです。
いわゆると書いたのは、これだけ大規模?なBOTNETを具体的に見ることができたのは、実は今回が初めてだから。正直ちょっとすげえと思ってます。
百単位のホストをイリーガルにコントロールするのって、結構簡単にできるんですねえ。いやごくろうさん。
1日経過して、他のサイトでもぼちぼち話題になってきたようです。とりあえずは、ウチだけターゲットになっているという可能性は消えてひと安心。
更新がなかったのは、サーバに関してはしばらく平穏無事だったからですが(一応迷惑メールホストのブラックリストは地味にメンテしていた)、昨日から今日にかけて、ほにゃらら.asiaとかいうサイト(一見ばらばらですが、たぶん全部同じIPアドレスに順引きされます)に誘導しようとするメールの攻撃を受けていて、S25Rのルールに引っかからないホストからの数件を配信したようです。なむし宛以外のメールもおそらく同じ内容でしょう。
それでも120ホストぐらいからのリクエストは阻止できているのですが(勘定できているのは、拒絶ログソーティングスクリプトと…送信者アドレスの@以前がかなり特徴的で容易に判別できるからなのですが)、こうやって1日やそこらでいっぺんに吐き出すべく、(たぶん)長い間一所懸命BOTやらオープンリレーやら確保してきたとしたら、ある意味感心です。まあ十中八九は感心…じゃなくて目下感染している…なんでしょうね。くれぐれもリンク先には行かない方がいいでしょう。どっちにしても、すり抜けたホストはMXでないことを確認してブラックリストに入れていますが(笑)。
迷惑メールついでに書くと、coreserverとかいうjpドメインのホストから時々リクエストが来ます。
450で弾くと、きわめて礼儀正しく再送してくるのでたまに受けたら内容は迷惑メール。
で、再び450したら、1週間ぐらい10〜30分間隔で再送してくるのでログが見にくくてしょうがない。ログソーティングスクリプトにNGワードオプションを追加したのはコイツのせいだとかせいじゃないとか(笑)。
鬱陶しくなったところで、その送信アドレスからのメールが再送されるタイミングを見計らって瞬間的に550にして止めています。
この程度の処理は手間でも何でもないのでこちらはどうでもいいんですが、このホスト、巷ではメール配信が重い(コトがある)ことで有名なようです。
どう考えても、このメール送信行為が原因としか思えないんですが?? 普通のサーバ借りて、普通のMTA使って、(たぶん)万単位の宛先にメールばらまいたら、そりゃパンクすると思いますよ。まあ実害も報告する義理もないので中途半端に伏せてますが。
で、やっと本題のサーバメンテについて。
何の因果かサーバにFedoraなんてのを使っているため、1年で寿命が来ます。
ソースコードで管理してりゃOSごと入れ替える必要はないんですけど…まあうちの場合、人間よりもyumの方が信頼できますんで(汗)。
近いうちに2日連続で休みが取れる日をつくって、Fedora10に入れ替える予定です。
日が決まったら再度予告します。
予定を大幅にオーバーしてすみません。
詳細は後刻報告しますが、いろいろあってHDDをフォーマットするところからやり直す羽目になりました。
ホームディレクトリ以下はリストアしたはずですが、dnsとかシステム設定がまだ甘いと思います。
続きは今晩やります。とにかく疲れた。
…今度はうちのせいじゃない(たぶん)
折からの嵐で基幹にカミナリでも落ちたんでしょうか? 0100から45分ほど回線が切れました。
ただその時は、モデムかルータがご臨終した可能性も考えられて、深夜ひとりで冷や汗をかいていたり。
回線(かその向こう側)のせいだとわかっていたら(あとちょっと早い時間帯だったら)、安心してサーバメンテを前倒ししてたところなんですが(痛)。
Downlink端末からの外にリクエストした複雑な(何枚も画像があるような)ページの読み込みにやたら時間がかかっていた現象について調べたら、iptables FORWARDに"-j TCPMSS --clamp-mss-to-pmtu"をつけてやれば解決する場合があるようです。
しかし試してみる以前にeth0が落ちているので、とりあえずちょっとeth0とeth1の役割を入れ替えたところ、eth1からはPPPoEできる一方、Downlinkからeth0が見えない。ifconfigした限りでは生きているように見えたのでダマされていましたが、RTL8168Bそのものがこけているようです。
それにしても、再起動したとたんに動かなくなったということは、真っ先にカーネルその他との相性が疑われるところです。心当たりとしては、しばらく不用意にyumupdatesdを動かしていたせいでシステムが怪しく書き換わったとか、namazuのインストールを通すのにかなり不必要な試行錯誤をしたとか。他方、再起動前から何らかの問題がったという可能性も捨てきれません。冒頭の問題も、単純にNICの問題なのかも!?
というわけで、4/29(火祝)の午前中2時間ほどを予定して、インストール直後以来行っていなかったシステム側のバックアップのついでに、勝手ながらちょっと調査させていただきます。
まずは「インストール直後に取ったシステムイメージ」でeth0が息を吹き返すかどうかを確認して、もしそれでも動かないか、遅い問題が改善しない場合は、信頼と実績の(!?)VT6102を増設してUplinkを任せる予定です。
ETG-Rをルータにするのは楽ですが、それでも前回放り投げたのを元に戻そうとしているのは、単なる気分的な事情に加えて実用的な害として、外からPASVでftpできなくなったからです。iptablesの設定を何年もミスっていたのは間抜けでしたが、結局そのせいではなかったみたいです。フォワード設定は間違いないはずなのに、なんでじゃろ!?
01:40〜02:40ごろの間、ネットワークを落としてしまいました。
yum updateをかけたらMissingDependencyだらけで失敗したため、カーネルとか更新したまま長い間リブートしていないせいかと思い込んで、深夜にリブートをかけたところ、pppoe-startがこけるようになっていました。
しばらく待ってもモデムをリセットしても改善しないため、結局ETG-RにPPPoEやらせる方法に戻しました(ETG-Rならあっさり接続)。
とりあえずサーバのゲートウェイの設定だけ変えて動かしているつもりですが、もし正常に動いていないようでしたらお知らせください。ただ何かあっても対応は本日夜以降になると思いますのでご了承ください。
そもそも4代目サーバ導入の際にわざわざPCルータを立てたのは、市販のルータよりもハイスペックのはずだったからなのに、まず外部のWeb表示がやたらもたつくのが最大の誤算。仮に接続の件が解決しても、今後パフォーマンス面での決定的な解決法が見つからないかぎり、PCルータは封印する予定です。
DHCPとDNSは引き続きサーバ側で走らせているので、Web表示のもたつくのが少なくともDNSのせいではないことは明らかになっていますが…もうどうでもいいや。
それより最初のMissingDependencyは…解決してなかったり(汗)。
踏み台にされずにすむためには「無効な宛先メールアドレスを指定した『リクエスト元のホストに対して』拒否」することです。これは送信者アドレスが騙られたものかどうかは問題にしません。蛇足ですがこの方法は、メール本体を受ける前に蹴るので、トラフィックが不必要に増えないという利点も持ちます。
といってもうちのサーバについては、宛先の有効性以前にS25Rで突っぱねるケースが圧倒的に多いのですが、さらに脱線すると「堅気なホストからの無効宛先は5**で一発退場」なのに対して「怪しいホストからの無効宛先は4**で保留」という逆転現象が生じています。まあ4**の方が送信キューを圧迫して嫌がられるという話もありますが。
他には「送信者アドレスのドメインと送信MTAのドメインが違っていたら蹴る」という方法も考えられますが、SPAMMERがアドレスを詐称しているのと、正当なユーザが事情があって別ドメインのMTAから送信しているのとの区別がつきにくいので、実際に制限するにはユーザに対する充分な説明と同意が必要と思われます。
…って、こういうのは自分ところからバウンスSPAMを出さない(他所に迷惑をかけない)ための対策であって、前記対策を行ってない(真正直に送信者アドレスに対してバウンスを送る)MTAから覚えのないバウンスを送りつけられることへの対策じゃあないんですよね(困)。
で、20日にそういう対策のない(と思われる)数十のホストから大量のバウンスが送られてきたっぽいです。大半のホストがロシアドメイン(*.ru)だったのがちょっと気になりましたが、それら直接のリクエスト元自体は、大半がDNSにMX登録までされている、しかもブロックしてみたら数十分間隔で半日以上再送を試みてくれるという、堅気なMTAが動いているとみなさざるを得ないホストであり、バウンスに対して無配慮だと文句を言いつつ通さないわけにいきません。
とにかく、いっぺんに何十通も送られたらさすがに笑えないので、たとえばEnvelopeFromが<>とかerrorとかbounceとか含まれているようなリクエストはバウンスとみなして一旦サーバで保留して、大元の送信元が怪しいホストだったら配信しない、みたいな対策を探索中です。
それかもっと簡単に、(誤判定が怖くて無効にしていた)ClamAVのスパムチェックを有効にした方がいいのかも。
それにしても、バウンスの踏み台を数十個温存しといて、ほぼ一斉に発動させるのが可愛気ないですね。BALシリーズでも4個までだったのに!?
気がついたらハードはそのままなのにPHPとかいろいろ動き出したので、ちょっと基板周りを強化した上でConroeL440なんか乗っけてみました。
(先代Northwood256よりちょっとだけ)処理能力の向上と静音化を両立したつもりでしたが、SATARAIDのファンが思ったよりも小型でやかましかったのは計算外です。
今回初めて旧サーバが健在な状態での移行というわけで、余裕ぶっこいて1週間かけてじっくり(というか夜な夜なちょっとずつ)セットアップしていたのですが、今回調子に乗って64bit版なんぞをインストールしてしまったため、PHPの拡張モジュールの在処が"/usr/lib64/php/modules/"になっていたのに気づかず、旧設定のphp.iniをそのまま持ってきてしまったため、mbstringあたりのモジュールが遊んでいました。おそらく午前中いっぱいPHPの出力が腐っていたのではないかと思います。ご迷惑をおかけしました。
昨年末あたりから、たまにWebサーバが落ちていました。
表面的な事象としては、特定のPHPが瞬時に大量に実行された時に、1〜2個のプロセスが何らかの理由(おそらくミューテックス絡みでデッドロック?)でSendingReplyのまま残ってしまい、ついにはServerLimitまで溜まり続ける(運が悪いとスワップまで使い切ってハードブートのやむなきに至る)という状態です。
手動でプロセスを切ったりとかhttpdリスタートとかで対処しながら色々設定変えてみましたがうまくありません。
手詰まりになったので、サーバを最新にしてみます。
※それでもダメならPHPをCGI版にする手か。
当然、この間はサーバに繋がりませんのでご了承ください。
それにしても、RSSのリクエストってどうしていつもいつも何十個もいっぺんに来るのか!?(って当たり前じゃ)
それがただのファイルだったらまだしも、全部PHPだから…(汗)。
ランレベル5不調のため、手っ取り早くランレベル3に逃げていましたが、間抜けなことにnamedが起動設定から外れていました。
外部から見ることがないため、不通の報告をいただくまで完全に気づいていませんでした。
DNSが見えないということで、じわじわと接続できなくなっていったようです。
単純な見落としでご迷惑をおかけしました。
簡単に言えば、ISPのメールサーバとは思えない名前のホストからやってくるメールを、管理者が救済するまで保留し続ける方式です。
こういうホスト≒SPAM発信源という乱暴な論理ですが、残念ながら現状ではほぼ実質的に成り立っています。
当然、発信者(のネットワーク)から直接送られてくる正当なメールもあるわけで、そういうのは先方が諦める前に管理者が気づいて救済する必要があります。
保留する可能性があるサイト名については、S25R方式を提案されているスパム対策技術のページを参照してください。
もし引っかかる可能性のあるサーバからのメールを受ける可能性がある場合はお知らせください。管理者は定期的に保留の履歴を見張っていますが、見落とすか、見つけても先方が諦めている場合も考えられますので(ちゃんとした目的で運用しているメールサーバなら、半日やそこらは諦めたりしないと思いますが)。
将来MTAをアップグレードしたら、善良な送信サイトを拒否する可能性を減らすためStarpitに移行する予定です。
S25Rの効果は絶大です。確かに管理者の仕事は増えますが、メール受けてからSPAMの中に埋もれている(かもしれない)正当なメールをチェックするのに較べたら手間的にも気分的にもはるかにマシです。
しかし、↑に書きましたように、送信元によっては管理者が気づくまで送られない場合があります。ただし設定後は(設定ミスしない限り)遅れが発生することはありません。
それさえ気をつけていただければ、SPAMに悩まされているユーザにはお薦めできると思います。
なお、いったんよそのメールボックスで受けたメールをこちらに転送しても、SPAMを弾けるわけではありません。この方式は、メールの内容でなく送信元(この場合は転送元)のホスト名で判断するため、おそらく100%転送されて(あるいは100%弾いて)しまいます。
ftpクライアントソフトから見えるディレクトリは、各ホームディレクトリが仮想ルートディレクトリ"/"として見えます。
たとえば、ユーザxxxxでログインした時の"/html/"は、実際には"/home/xxxx/html/"になります。
アクティブ・パッシブ両モードに(やっと)対応。
ただし、より安全性の高い通信手段をお勧めします。SFTPとか(遅いけど)。
FileZillaとか、UTF-8に対応している上にFTPに限らずいろいろな方法で通信できるのでお勧めです(サーバ側の対応の方が…汗)。
現在のところ、Options、AuthConfig、Limitが指定できます。
デフォルトでは、index.html(htm)が無い状態でのファイル一覧表示を「しない」設定にしています。一覧表示を行いたいディレクトリでは"+Indexes"を指示してください。
特に希望がありましたら、管理者までお知らせください。ご相談に応じます。
SSH2(ポート22)使用可。ただし希望しないユーザに対しては接続不可にしています。
ホスト認証可。暗号鍵はDSA/RSA共に対応(DSAを推奨します)。鍵サイズは、ひとまず2kBまではOKなのを確認しました。
サーバ側の標準文字コードがUTF-8になりましたので、シェル上で日本語を扱う場合は、クライアントソフトの文字コード設定をUTF-8に設定してください。
編集を各自のエディタで行うのであれば、文書の中身はこれまでどおりSJISやEUC-JPなどでも大丈夫です。アップロード時の文字コード変換は解除してください。
ただしリモートシェル上で編集する場合はUTF-8しか使えないでしょう。ちなみにテキストエディタは、現在viのみ提供しています。
Windows上のクライアントソフトとしては、TeraTerm+TTSSH最新バージョンあるいは、PedorosaといったものがSSH2にもUTF-8コードにも対応しているようです。
UNIX系OSあるいはMacOS向けのクライアントソフトの紹介は省かせていただきますが、最新の環境であれば、標準で実装されているクライアントで大丈夫だと思います。
メールサーバは"mx.dai-mine3.net"です。
対応メールソフト(Becky!/Thunderbird/OutlookExpressもかな?など)から、パスワード送信やメール受信を暗号化して行えます。
ただし、零細サーバにつきホスト認証は受けてないので、ホスト認証のNGは無視してください(暗号化機能のみ使います)。
あと、メールの内容が暗号化されるため、ウィルス対策ソフトやスパム対策ソフトが受信時に弾いてくれなくなるおそれが大です(汗)。
ウィルス/ワームについては、大抵の対策ソフトは、アクセス時に警告が出るので、受信してしまっても即致命的という事態にはならない…と思います。
転送先メールアドレスを書いた".forward"というテキストファイルを作り、各ホームディレクトリにアップすれば、そのアドレスに転送されます。
転送先がxxx@yyy.comだとすると、
xxx@yyy.com
複数のアドレスに転送したい場合は、改行して書いてください。
MTAをqmailからPostfixに変更したため、転送制御用のファイルの書式が少し変わっています。
~/.qmailの転送先指定では
&xxx@yyy.com
でしたが、~/.forwardでは先頭の"&"が不要ですのでご注意ください。
あと、パスワードが独立して設定できなくなりました。通常のログインパスワードでアクセスしてください。
転送した場合、メールは本サーバには残りません。もし残したい場合は、自分自身にも転送します。各自のメールは、おのおのホームディレクトリ下のMaildir/に保存されるので
xxx@yyy.com
~/Maildir/
のように書きます。順番はどちらが先でもかまいませんが、Maildirの後ろの"/"は忘れず書いてください。
また、~/.qmailでは相対ディレクトリ指定"./Maildir/"ができましたが、~/.forwardでは無効になるようなので、上のような書き方に揃えてください。
メールの受信を拒否したい場合は、同じく~/.forwardに
/dev/null
と書けばOKです(こちらは最後に"/"をつけないでください)。
.forward設定の詳細は、適当な書籍あるいはサイトをご参照ください(申しわけありませんがこちらでは紹介しません)。
もちろん「よくわからないけど○○に転送するように設定して」とか「××@dai-mine3.netってメールアドレスが欲しい」といった要望は承ります。
