Server: 2007年5月アーカイブ

　こんな大規模障害は管制システムダウン以来かな。今回はメインフレームの交換メンテでだそうで、オープンソースに切り替える計画の初っ端らしい。メインフレームの交換は大変そうだな…新旧の切替といっても装置があまりにもデカイからいろんな意味でひとつひとつの作業が大変だと思う…。

時事ドットコム：全日空でシステム障害＝１２２便が欠航、４万人影響－更新原因か、処理速度低下
http://www.jiji.com/jc/c?g=soc_30&k=2007052700028

更新して即障害ではなく、中旬頃入れ替えた新しいシステムで処理オーバーとは…。
身の回りでよく聞く障害事例だなー。ハードウェアが新しいからって同じプログラムが速く動くなんて過信したんでしょうね。逆に埋もれていたバグが顕在化して止まるなんて良くあるのに。これは現場のSEが経験無くて起きたのか、メインフレームだけにテスト負担が大きく経営側からテスト工程を縮小若しくは潰されたか…。続報待ち。

追記 2007/05/29
続報ではどうやらネットワーク機器も絡んでるらしい。ネットワーク機器がトラブルの原因でメインフレームにデータが滞留するのは仕様なのか不具合なのか、見極めが付かないとなるとかなり時間掛かりそうですね。意外にもネットワーク機器は新しいものの方が対応プロトコルが削られていたりしてTCP/IP以外の通信機器と相性が合わない事ってありますからね…。

【詳報】全日空システム障害はデータ滞留が焦点に、通信機器は前日に兆候も：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20070528/272597/

　NTTより15日に発生したネットワーク障害の最終報告がありました。多分今回のようなケースはNTTでも初めてなんじゃないかな。というか実際に再現するテスト環境なんてコスト的に無理だから机上のリスク計算しかできないと思う。

　私のような末端はVPNやプライベートLANのルーティング設定してそれ以外は精々数本のグローバル回線にルーティング情報を張るぐらいだから手作業で済みますが、主要回線はピアtoピアで沢山のルーターが相互に物理的な接続をしているし、常にルーティング情報は変わるから自動じゃないとやってられないと思います。

　DNSと違ってルーティング情報は直ぐに書き換えを行う仕様みたいなので、タイミング悪くトラフィックの多いときにやってしまったようですね。(DNSのキャッシュもサーバの増減時に強制的に消し去りたいと思うこともありますが…)

　NTTでは障害の連鎖に対しどのようなソフトウェア対策を行われていたか記事からは分かりませんが、実際に障害を起こしたのは古いソフトウェアで動作しているルータということでルーティング情報の書き換え連鎖を防ぐ処理が無かった為のようです。

　通信事業者としての現在の立場を考えると今回の障害は多くから非難も発生すると思いますが、ネットワーク障害について速やかに技術的な報告をする姿勢は評価したいです。

　このニュース記事見た一部ISPがルータ総点検するきっかけになれば、他社による同じ過ちの再発を未然に防止できるのではないかなっと思います。

3秒で2000ルータがダウン、NTT東フレッツ障害の原因は － ＠IT
http://www.atmarkit.co.jp/news/200705/16/ntt.html

BGPの仕組みと役割を理解する
http://www.atmarkit.co.jp/fnetwork/rensai/iprt02/iprt01.html

「フレッツサービス」および「ひかり電話」をご利用できない状況について（最終報）
http://www.ntt-east.co.jp/release/0705/070516b.html

別紙１　時系列
http://www.ntt-east.co.jp/release/0705/070516b_1.html

別紙２　発生のメカニズム
http://www.ntt-east.co.jp/release/0705/070516b_2.html

　やっとまともな情報が見つかりました。やっぱ設定ファイルだけの小手先では無理だったか。時間のあるときに再コンパイルするかな…。

FreeBSD-suPHP - PukiWiki Plus!
http://matsui.homeunix.com/index.php?FreeBSD%2FsuPHP#z90b6ff6

　昨日のDDOS攻撃の関連で調べていたら、IPアドレス別でアクセス可能な地域を制限する方法があった。方法自体はIPフィルタリングだが、どのIPがどの国で使用されてるかが情報公開されていたのでそれを利用できそうです。

　メールは基本的に全世界からアクセスされるものなので国別での接続制限というのもあまり意味がないのですが、ゲームサーバに関しては負荷の集中を避けるためと、営業範囲外のアクセスを遮断する場合があります。(国別に運営会社が決まっているとかですね)

まず、国別IPの情報はここから取得できます。
http://ftp.apnic.net/stats/

さらに一網打尽を使うと整理しやすくなります。
http://www.vector.co.jp/soft/winnt/net/se316799.html

あとは前段にFWを設けてログなし破棄をすれば十分でしょう。

　朝から開発用サーバ宛に急にスパムのエラーメールが殺到してきた。そのサーバはメールを利用するシステムでも正常にテストが行えるように別途ドメイン登録しているのですが、開発の仲間内でしか使わないこのドメイン宛に大量のスパムがやってきたため、一瞬乗っ取られた！？と思い緊急監視。そしたらメールサーバは全然送信履歴がない。どうもドメイン詐称されたっぽい。

　そこでまずは濡れ衣エラーメール自身が非常にウザイ(毎時300通って何だよ！スパム自身はこれよりもっと多いわけか…)のでデフォルトのエイリアスを削除。

　これでエラーメールにエラー返しの状態になるのですが、良く考えたら今度はpostmaster宛てにどっさりやって来る|||orz

　結局 +激しくウザイ+ ので25番をFWで止めた。別に現在進行形のプロジェクトもないし。さらにIN/OUT両方にlogを記録するように変更し、OUT側は塞がないままで監視。

　OUTのアクセスはまったくなかったので完全にドメイン詐称スパム確定(SMTP認証のみ設定してpop before smtpのような旧来のなんちゃって認証は使ってないので自信はありました)。当然、今度はスパムエラー自身をFWで止めてしまったのでお互いのサーバに負荷がかかり続けている点についてはあまり褒められることではない。

　そこでドメインの認証を行う方法がないか検索したらSPFレコードを発見。こんなレコードがあるなんて知らなかった。無知でしたスミマセン。一応設定は完了したので25番を止めたまま２～３日様子見ます。

　世の中のサーバの多くがしっかりしていればスパム量は一気に減るかもと期待。

Open Tech Press SPF解説
http://opentechpress.jp/enterprise/article.pl?sid=04/09/16/0127221

　ＧＷ中になんとか書き上げましたが、住民票を用意するのを忘れてたｗ
まあ早くても来月からなんで急いでませんが。それよりもサーバ構築のプランを急がないといけない。こちらはまだマルチドメインで利用する場合のPHP動作権限とPostfixの管理の検証をまだやってない。。
良く考えたらツール類全然作ってないや…。

総務省関東総合通信局：届出書類（届出電気通信事業）のダウンロード
http://www.kanto-bt.go.jp/com/jigyo/tetuzuki/tetuzuki04.html