水無月ばけらのえび日記

迷走する教訓

Internet Watch にも「レンタルサーバー会社の安全性を認証する第三者機関を～ACCS久保田理事 (internet.watch.impress.co.jp)」というのが出ましたね。

裁判が結着していないことがどう関係するのか良く分からないですね。office さんが何をしたかということは、ACCS・ファーストサーバが管理責任を果たしていたかどうかということとは関係ないのではないでしょうか。office さんがアクセスしていなかったら「管理責任を果たしていなかったことが発覚しなかった」可能性は高いですが、だからといって「管理責任を果たしていた」ということになるわけではないでしょう。

それにしても「実行犯」ですか。まだ無罪が推定されているはずなのに完全に犯人扱いしてしまっているのは……まあ、アクセスしたこと自体は争っていないわけですし、それはそれで仕方ないようにも思います。しかし、この言葉から「奴 (officeさん) さえいなければ何も問題なかったのに」というニュアンスがにじみ出てしまっているような気がするのですよね。

なんかこれも論点がずれているような気がしますね。今回の話は別にファーストサーバのサーバにパッチが当たっていなくて root を取られたというような話ではないわけで、

• ファーストサーバが配布していた csvmail.cgi が脆弱だった
• ACCS (ヨセフアンドレオン) はその脆弱な CGI を何の疑いもなく運用していた
• そこで本来は必要ない個人情報まで必須項目にして個人情報を集めていた
• しかも SSL すら使っていなかった
• ファーストサーバは「古い CGI は脆弱だ」とアナウンスしていたのに ACCS (ヨセフアンドレオン) はそれを無視した

というような話でしょう。

※ちなみにファーストサーバには当時から SSL のサービスはありましたので、SSL を使っていなかったのはファーストサーバ側の都合によるものではなく ACCS 側が (おそらくは費用と相談して) 選択した結果です。

このような話になることを避けるのに必要なのは「サーバー会社が適切な管理を行なっているかどうかを認証する第三者のチェック機関」なのですか? 今回 ACCS はたまたまサーバ会社が配布していた CGI を使っていましたが、これがそうではなくて、そこらで配布されているフリーの CGI を使っていたらどうでしょう。あるいはヨセフアンドレオンが自作していたらどうでしょう。 サーバ会社を監査して何か意味があるのでしょうか。

本当に必要なのは CGI の監査であり、Web サイトの監査でしょう。ここには当然 Web サーバの監査は含まれるでしょうが、サーバ会社の監査は必要ないはずです。

しかし調査報告書 (www.askaccs.ne.jp)はけっこうまともなことを言っていたと思うのですが、どうして理事はこうなってしまうのでしょうね。

※あるいは、久保田理事は故意に論点をずらしているのかなぁ、という気もします。「セキュリティがショボイサーバ会社が悪いハッカーに侵入された」というようなイメージを植え付けられれば、「ACCS は悪くない、仕方ない」という印象を持ってもらえそうですし。

• 「迷走する教訓」にコメントを書く

関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / ファーストサーバ

まだダメ

だいぶ直したつもりなのに未だに固まるようですね。申し訳ないです。

ひとまず、負荷が高そうな日記再読込を少なくしてみるテストということで、日記にコメントがついても日記のデータをリロードしなくなりました。これには当然副作用があって、日記側に表示されるコメント件数が更新されない可能性があります。

というわけでけっこう大きな問題があるのですが、しばらくの間これで様子を見ることにします。

• 「まだダメ」にコメントを書く

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

不正アクセス禁止法に抵触しない程度の簡単なバックドアって?

更新: 2004年10月7日

「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る (www.itmedia.co.jp)。

これはあてつけなのかなぁ。いやまあ、全く同感なのですけれども。

ええと……「不正アクセス禁止法に抵触しない程度の簡単なバックドア」っていったい何でしょう。バックドアを仕掛けたという言葉が文字通りであるのなら、それが簡単であったかどうかは違法性とは全く関係ないような気がしますけれども。

逆に、個人的には ng_file=csvmail.cgi のほうこそ「不正アクセス禁止法に抵触しない程度の簡単な」アクセスだと思うのですよね。ただのディレクトリトラバーサルですし。

※もしこれがバックドアだとしても、仕掛けたのは office さんではなく morikawaさんでしょうし。:-)

※2004-10-07 追記: IT Media の上記引用部分は修正され、「検索エンジンを利用しただけで、ある有名大学のWebサイトから大学の教職員名簿がまるごと見えてしまった」と改められました。また NIS/ネット情報セキュリティ研究会 (www.e-secure.jp)にも訂正のコメントが出ています (shinさん情報ありがとうございます)。

• 「不正アクセス禁止法に抵触しない程度の簡単なバックドアって?」へのコメント (6件)

関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件

復活ならず

「@nifty パレットのセキュリティホール まとめ」が復活するかと思いきや……。

残念。

• 「復活ならず」にコメントを書く

関連する話題: セキュリティ / IPA

.NET Framework のバージョンを調べる

例の GDI+ の脆弱性は .NET Framework にも影響します。最新の SP では対応されていますので、.NET Framework 1.0 なら SP3 に、.NET Framework 1.1 なら SP1 にする必要があります。

クライアントマシンは速攻でアップグレードしていますのでまあ問題ないと思うわけですが、ふと、「そういえばサーバにちゃんと SP 入れたっけ」という疑問を抱きました。そもそも .NET Framework のバージョンをどうやって確認できるのか良く分からなかったのですが、「.NET Framework に Service Pack がインストールされているかどうかを確認する方法 (support.microsoft.com)」というドキュメントの存在を教えてもらって解決。いや、解決したと思ったのですが……。

……いったい、誰に予想することができたであろうか。これが長い戦いの始まりであるなどと……。

ドキュメントで示されている確認方法は 3つ。

• XP の場合、管理ツールの [Microsoft .NET Framework 1.1 Configuration] でバージョン情報を見ることができる (ちなみに Windows 2000 の場合は管理ツールも Configuration もありますが、バージョン情報は見られません)。
• MMC で [.NET Framework Configuration] のスナップインを追加してプロパティを確認する。
• 直接 mscorcfg.dll のプロパティを見て確認する。

どの方法を使って調べても、バージョンは 1.1.4322.573 でした。該当ドキュメントの表によれば、これは SP1 の当たっていない .NET Framework 1.1 のバージョンです。

これはマズイ、と思って慌てて SP1 を拾ってきて当てようとしたのですが……。

無視してインストールし、その後再びバージョンを確認するも 1.1.4322.573 のままで変化なし。

……というわけでお手上げなので私の .NET の師匠であるむらまさ先生 (www.fprog.org)に相談してみたのですが、mscorcfg.dll ではなく mscorlib.dll のバージョンを調べると、ちゃんと 1.1.4322.2032 になっていることが判明。考えてみれば Configuration 自体は GDI+ の脆弱性には関係なく、mscorlib.dll が更新されていれば問題ないはずです。

そんなわけで、これで問題なかろうという結論に達しました。

※しかしこの MS のドキュメントの立場はいったい……。というかまあ、単純に間違っていると思うわけですが。

• 「.NET Framework のバージョンを調べる」にコメントを書く

関連する話題: セキュリティ / Microsoft / .NET

修正話

いちおう安定してきたような気がするので、詳細ログを取るのをやめました。

日記にコメントをつけたりするとちょっと微妙な動作になりますが、これは負荷が高いため。

日記にコメントをつけると、日記のデータファイルのタイムスタンプが更新されるようになっています。これは古いキャッシュが破棄するためなのですが、そのためだけに 2メガ超の日記データがリロードされてしまうので効率が悪いです。

うまくキャッシュだけ破棄したい感じなのですが、キャッシュの仕組み自体が微妙なので見直したいところではあります。

• 「修正話」へのコメント (8件)

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

セッション固定攻撃

IEやMozillaなどにセキュリティ・ホール，なりすましを許す可能性あり (itpro.nikkeibp.co.jp)……って非常に興味深い話ですね。Session Fixation (セッション固定) というのは知りませんでした。

当然、某所ではこれが楽勝でできるので再びピンチ。

そして、以前検証用に作成した「Cookie 操作装置」という CGI が攻撃に使用できる可能性があることが分かったので、とりあえず動作しないようにパーミッションを落としておきました。

• 「セッション固定攻撃」にコメントを書く

関連する話題: セキュリティ

誕生日

今日はボブサップの 30歳の誕生日ですよ、なんと。

• 「誕生日」にコメントを書く

関連する話題: 出来事

まだまだ修正中

デッドロックの件ですが、lock をやめたら泥沼化した原因が発覚しました。単純に Moniter.TryEnter した後で Monitor.Exit するオブジェクトを間違えていたようです。

というわけでこれで直ったはずなのですが、本来ならそういう間違いをしていれば SynchronizationLockException という例外が throw されるはずなので、なにかもっと別の原因があるのかもしれません。あるいは System.Threading.Monitor じゃなくて System.Threading.ReaderWriterLock を使った方が良いのかもとかいろいろありますが、まあとりあえずこれで様子見ということで。

ついでに IT Media にリンクしない機能の実装を見直し。ついでに、他サイトへのリンクの後ろにはドメインを表示するようにしてみました。

あと hatomaru.dll のバグとしてはキャッシュ関係がおかしいことが判明していて、If-Modified-Since つきのリクエストに対して

• 304 で応答しなければならないはずなのに 200 応答する
• 200 で応答しなければならないはずなのに 304 応答する

という現象が発生することがあります。単純にステータスコードが逆になっているわけではなくて、正しく応答できる場合もあったりするので微妙です。この辺をちょっと見直そうかなと。

• 「まだまだ修正中」へのコメント (2件)

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

まだ修正中

泥沼中。

とりあえず詳細なログを取って調べたところ、MessageParser が呼ばれるたびに ngurl.xml が更新されているとみなされて Table のロックとリロードが発生していることが判明。一回のセッションで 10回くらい呼ばれたりしているし……。

※ちなみに ngurl.xml というのは IT Media にリンクしない機能を追加したときに追加した、リンク禁止 URL のデータです。

これは単純なバグだったので修正しました。これでロック回数がメチャクチャ減ったはずなので、かなり死ににくくなったはず (しかもかなり速くなったはず)。ひょっとすると完全に直ったのかも。……直っているといいなぁ。

• 「まだ修正中」にコメントを書く

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

わかりにくい MS04-028

MS04-028 (www.microsoft.com) ですが、Windows XP SP2 の環境で Windows Update すると、パッチが当たる……と思いきや、こんな不吉としか思えないダイアログが。

で、「はい」を押すと「JPEG 処理 (GDI+) のセキュリティ更新プログラムでコンピュータを更新する方法 (www.microsoft.com)」に遷移。

一瞬意味が分からなかったのですが、要するにこういうことみたいですね。

• Windows Update すると「検出ツール」がインストールされる。これ自体はパッチではない
• 検出ツールが動作して出現したダイアログで「はい」を押すと、説明ページに誘導される
• そこを読むと、Office Update の必要があることが分かる
• Office Update するとパッチが当たる

まあ Windows Update しただけでは Office が更新されないという問題がありますので、それに対するソリューションなのだろうと思いますが、ちょっと混乱しますね。出るメッセージをもう少し工夫できなかったのでしょうか。

そのリンク先のページも微妙で、

って、Windows XP のユーザは対象なのか対象でないのか分かりにくいです。たぶん「対象でない」が正解だと思いますが……。

まとめるとこんな感じ?

• Microsoft Office は OS の種類にかかわらず全て脆弱なので、パッチを当てる必要がある。
• Windows XP SP2 の場合、OS は脆弱ではない。
• SP2 でない XP と Windows Server 2003 の場合、OS が脆弱なのでパッチを当てる必要あり。
• その他の Windows (Windows 2000 など) は OS は脆弱ではないのだが、脆弱なコンポーネントがインストールされている可能性があり、まずそれを調べる必要がある。脆弱だったらパッチ。

• 「わかりにくい MS04-028」へのコメント (2件)

関連する話題: セキュリティ / Microsoft / Windows / Windows XP / Microsoft Office

ここぞという時のフロッピーディスク

スラッシュドットで「フロッピーはまだ必要か? (slashdot.jp)」という話が出ていますが、今日まさにフロッピーディスクのお世話になる出来事が。

Windows がセーフモード + コマンドプロンプトでしか起動しなくなり、ネットワークカードも CD-ROM ドライブも認識しない……などという事態になると、もうフロッピーディスクしかないでしょう。やっぱりいざというときにはまだ使えるのかな、という感じです。

• 「ここぞという時のフロッピーディスク」にコメントを書く

関連する話題: 出来事

修正中

ロックに失敗したらロックを諦めて例外を出すようにしたところ、例外がぞろぞろと。そりゃそうか。

どうも spam 判定ルーチンで死んでいるようなので、その辺りをこちょこちょと修正してみました。これで直ると良いのですが、全く自信なし。

• 「修正中」にコメントを書く

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

脆弱性届出話

更新: 2004年11月4日

「脆弱性情報届出制度は運用しながら改善を～パネルディスカッション (internet.watch.impress.co.jp)」という話ですが、

前に報道されていた話と比較すると、

• 件数が増えた
• 「個人情報漏洩に繋がる脆弱性は届け出られていない」という話が消えた(!)

というところでしょうか。後者はたまたま今回は言っていないだけという可能性もありますが、何となくそうではない気がします。

当然というか問題点がいろいろ出ているようで、

まあ前者は「頑張ってください」というより他ないですね。端から見て何が届け出られているのか分からないので、どうしようもありません。ひょっとすると、某サーバ屋のアレなんかみんなして届け出ていたりするのかもしれない……と思ったりするわけですが、だからといって「きっと届け出られているだろうから良いだろう」というのも外れているかもしれないわけで。届出の情報が公開されない限り、重複は回避できないでしょう。

それから後者、これ、悲しいことにホントに連絡が取れない場合というのが実際にあるようですね。その場合は

……ということになるのですが、そうなったときに発見者はどうすれば良いのかというのが気になるところです。

密かに修正ということはもう期待できませんので、放置なのか、公開なのかの二択になると思いますが……当然、発見者は放置したくないから届け出ているわけでして……情報を公開したほうが良いものかどうか悩みます。

これは激しく同意で、私も一番気になっているところです。高木さんは流石に発見者の気持ちが良く分かっていらっしゃるようで。

しかし少なくとも最初の項目については、ガイドラインで「個人情報漏洩の時は情報を公開する必要がある」としているわけです。逆に言えば、それ以外の時は公開しなくて良いということですから、むしろ制度として「個人情報が漏洩していない場合はヤミ改修で良い」と認めているものだと理解していました。

もっとも、脆弱性によって個人情報が漏洩したかどうかというのは非常に微妙な部分があります。たとえば XSS などはセッション Cookie が盗まれてセッションハイジャックが行われる可能性があり、ログインによって個人情報が閲覧できるなら、個人情報漏洩の可能性もあるはずなのです。しかし実際にはロクな調査もしないで、「XSS がありましたが実害なし」などという判断をして終了ということになるケースがほとんどです。XSS が発覚しても、「この XSS は Cookie を使ってログインするサーバとは別のサーバのものなので、セッションハイジャックのおそれはありません」などと言ってもらえれば、それはそれで安心できると思うのですが……。

※そう言ってもらえない場合というのは、漏洩の可能性が否定できない = 情報公開しようねということになるはず。

ちなみに、届け出られて修正された脆弱性が 5件あるということですが、そのうちの 1件は某 ISP (ニフティではありません) の検索フォームの XSS です。これも全く情報公開された形跡がないですね。

あと、面白いと思ったのは脆弱性情報の届出状況のグラフ (internet.watch.impress.co.jp)。所々にぼこっと大きな山ができているのは、「貯めていたものを一気に吐き出した」人がいるからなのかなぁと思ったり。手持ちの脆弱性がたくさんある場合は、まとめて一度に送るでしょうからね。

※2004-11-04 追記:「某サーバ屋のアレ」は届け出てみたところ、普通に取り扱われて普通に修正の連絡を受けました。つまり、私以外の誰も届け出ていなかったものと思われ……「誰かが届け出ているだろう」という発想はしちゃ駄目みたいです。

• 「脆弱性届出話」にコメントを書く

関連する話題: セキュリティ / IPA / 思ったこと / 情報セキュリティ早期警戒パートナーシップ

デッドロック対策

デッドロックの原因は全く分かりません。クリティカルセクションの中で別のロックを要求しているような部分はないし……。

とあえず後ろ向きの対策として、ロックが必要なところで頑張りすぎないようにしてみました。

try{
    if(!Monitor.TryEnter(target, DataConst.LockInterval))
        throw new LockFailException("ロックに失敗しました。");

    ……クリティカルセクション……

} finally {
    Monitor.Exit(target);
} 

こんな感じ。ちなみに LockFailException はカスタム例外です。DataConst.LockInterval の値は定数で、とりあえず 5000 にしてあります。5秒待ってロックできなかったら諦めて、例外を吐いて終了する感じ。

• 「デッドロック対策」にコメントを書く

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

デッドロック

掲示板書き込みのファイル保存処理を非同期にしたのですが、にもかかわらず ThreadAbortException が発生。CPU 使用率 100% で書き込み不能状態が続いていました。解決していたと思っていただけにがっくり。

こうなると、どこかでデッドロックが発生しているのではないかという疑いが濃厚です。というか、ロックの仕組みをあんまりちゃんと理解しないで lock ステートメントを使っているのが問題のような気がしますが。

……ともあれ、まだ「突然書けなくなる」現象は直っていないようです。ごめんなさい。

• 「デッドロック」にコメントを書く

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

バカ日本地図が本に

ちょっと前の日記で触れた借力(ちゃくりき) (www.chakuriki.net)のバカ日本地図がやじうま Watch (internet.watch.impress.co.jp) で紹介されていますね。本が出た (www.amazon.co.jp)のだそうで。

• 「バカ日本地図が本に」にコメントを書く

関連する話題: 出来事

人狼戦術考

しつこく「人狼BBS (ninjinix.x0.com)」を読んでいます。参加する気はないので、考えたことなどを気楽にメモしておきます。

• 村人が勝利するためにしなければならないのは、白・黒を確定しグレーゾーンを狭めて行くこと。
• 能力者の能力はグレーを狭めるために存在するのであり、能力者を守るためにグレーゾーンを広げるのは本末転倒。
• 逆に人狼はグレーを狭めずに白を狩って行くことが望ましい。
• 人狼の方が数が少ないのに勝率がほぼ五分なのは、初期状態で圧倒的な情報格差があるから (だと思う)。人狼は誰が人間なのか全て把握している。

個人的にはこう思います。

• 人の態度などは、あまり推理の材料にはならない。怪しい態度の人に「こいつは怪しい、人狼っぽい」と言うこともできるし、「人狼ならそんな怪しまれるような行動は取らないはず」と言うこともできる。裏、裏の裏、裏の裏の裏……があるのでなんとでも言いがかりはつけられる。
• 犠牲者が出た後に名乗り出た能力者は信用できない。一人だけ名乗り出た場合でも、本物が既に死亡して偽物だけが名乗り出ている可能性を否定できない。
• 霊能者の能力は、他の村人にとってはあまり役に立たない。犠牲者が多数出た後に名乗り出るパターンが多くなるのだが、犠牲者が多数出ている時点では信用できない。実際、終盤に一人だけ登場した霊能者が人狼というパターンは多い。

私が村人なら、勝つためにまず以下の取り決めをします (ただしこれは狩人・共有者が存在する場合)。

• 狩人以外の能力者 (霊能者含む) は、最初の犠牲者が出る前に必ず名乗り出ることとする。
• 共有者が名乗り出る場合は、同時に相手の名前を挙げること (こうすると、狂人が相手の名前を挙げずに共有者として名乗り出て、それに人狼が呼応するというパターンを排除できる。といってもまず起きないと思いますが)。
• 犠牲者が出た後に名乗り出た者は問答無用で偽物とみなし、優先的に処刑対象とする。

この三点を徹底すれば、初日に一人だけ名乗り出た能力者は本物とみなすことができます。本人を白確定できますし、その能力も信用できるということになります。複数が名乗り出た場合も、その中に確実に本物が含まれていると考えることができます。

※個人的に霊能者の能力は役に立たないと思っているのですが、一人だけ名乗り出れば白確定ですので、手数を無駄にせずに白確定者を増やすことができます。複数名乗り出ればグレー濃厚ですので、どちらにしても意味はあります。また、後になって人狼や狂人が霊能者を騙ることを防ぐことができます (初日に名乗り出るしかなく、様子を見て臨機応変に名乗り出るかどうか決めるという選択肢がなくなる)。

その上で、こう運用します。

• 黒確定者がいれば処刑 (あたりまえ)。
• そうでない場合、白確定者の間で協議して処刑対象を決定し、事前に公表。全員で同じ人に投票する。
• 占い師が一人なら、占い対象は事前に公表せず、占い後に公表。ただし処刑対象と重ならないように占うこと。
• 狩人は名乗り出ず、ひそかに占い師をガード。処刑対象になっても黙って処刑される。
• 占い師が複数名乗り出ている場合はその片方をガードするか、白確定者をガードするか、占い対象者をガード (要するに人狼に襲われそうな者をガード。うまくブロックできればラッキーくらいの気持ちで)。

能力者が複数名乗り出た場合は、こう対処します。

• 占い師の偽物 …… 前述の条件により本物が含まれていることが確定している。占い対象を事前に白確定者の間で協議して決め、同じ対象を占わせれば良い。占い結果がいずれも白であれば白確定、いずれも黒であれば黒確定。分かれた場合も優先的に処刑。名乗り出た占い師のうち一人が殺害された場合、残った者の占いは信用できない上にグレーが濃いので優先的に処刑します。
• 共有者の偽物 …… 信用できる占い結果が出せる状態なら全く問題ありません。誰か一人を占います。黒判定ならそのペアを処刑。白判定なら逆のペアを処刑。
• 霊能者の偽物 …… 単にグレーが濃い村人とみなして優先的に処刑します。もちろん両方とも。

※占い対象を公表すると人狼はそこに襲撃をかぶせるかもしれませんが、大きな問題はないと考えます。そのぶん既存の白確定者が喰われなくなるので、白確定者の数を維持できます。また、そもそも狼にヒットしている場合は喰われない訳ですし、狩人のファインプレーもあり得ます。

これで村人の勝率はかなり上がると思うのですが、占い師の偽物が出ないと人狼はほぼ負け確定になりますので、確実に偽占い師が登場します。そこで占い師の襲撃に成功したりすると、いつものような混乱の泥沼にはまっていく可能性があります。……というか、是非そうなって欲しいですね。やっぱり疑惑が疑惑を呼ぶ展開が面白いわけで……。

• 「人狼戦術考」へのコメント (10件)

関連する話題: 思ったこと

人狼考

やっばり「人狼BBS (ninjinix.x0.com)」を読んでいます。

いろいろな村で、偽物の占い師よりも本物の占い師のほうが怪しく見える (と私には思える) のが興味深いです。

このゲームでは本物も偽物も等しく疑われるわけですが、本物が疑われると「本物なのに何で信じてくれないんだ!」と思ってしまうのでしょう。偽物は疑われても「当然疑われるだろうなぁ」と思って平然としていられます (しかも人狼なら相談相手もいます)。その結果、本物が感情的になって支離滅裂になり、偽物のほうが冷静でいるというのも十分にある話でしょう。

• 「人狼考」にコメントを書く

関連する話題: 思ったこと

人狼

むらまさ先生 (www.fprog.org)が紹介していた「人狼BBS (ninjinix.x0.com)」が面白くてはまっています。といっても参加しているわけではなくて、過去ログを読んでいるだけなのですが、それでも十分楽しめます。勉強になるし。

• 「人狼」にコメントを書く

関連する話題: 出来事 / 思ったこと

StackOverflowException

HTML リファレンスを作っているのですが、System.StackOverflowException などという不吉な名前の例外が出てしまったりして。

ドキュメントを見るとこんな感じ。

まあそのまんまスタックオーバーフローなわけですが、再帰処理が無限ループしているのかしら。

• 「StackOverflowException」にコメントを書く

関連する話題: プログラミング / C#

昆虫

なんとなく激写してみたので。

• 「昆虫」にコメントを書く

関連する話題: 写真

SP2 でファイアウォールがリセット

私のマシンでは IIS の FTP サーバが動いていたりするのですが、何故かうまくファイルを転送できなくてちょっと戸惑いました。

いや、何故も何も原因は明らかに Windows ファイアウォールで、「例外」にポート 21 を指定したらすぐに解決したのですが……以前はファイアウォール有効かつ 21 と 80 と 8080 は穴開けという設定にしていたので、SP2 インストール後もそうなっているものとばかり思っていました。

以前の設定が引き継がれないというのも変な話ですが、よくよく考えると、元々ファイアウォールを使っていなかった人もデフォルトでファイアウォール有効になるような方針ですから、そのポリシーで行けばリセットされて当然なのかもしれません。

• 「SP2 でファイアウォールがリセット」にコメントを書く

関連する話題: Microsoft / Windows / Windows XP

脆弱性届出は 67件

「IPAへのぜい弱性情報の届け出，開始から2カ月弱で67件に (itpro.nikkeibp.co.jp)」だそうですが、67件という数字には驚きました。思ったより少ないですね。

そして修正されたのが 5件、すなわち 1割ですか。まあ、届け出てから 1ヶ月以上経ってから取扱い開始になったりすることもあるようですので、もう少し気長に待ってみた方が良いのかも知れません。

• 「脆弱性届出は 67件」へのコメント (2件)

関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ