中田は奮闘していたけど、アーセナルのポゼッションが圧倒的でなかなか見せる場面が無かったなあ。とはいえ、先制点の起点にはなったんだけどねえ。
しかし、ボルトンはやはり弱者の戦術というか、組み立てよりも放り込み方面なので、持ち味が発揮できない感じだなあ。辛いところですね。
それにしてもボルトンのヤースケライネンはすごいなあ。これで完封できていればヤースケライネンのゲームだったんだけどねー。
ウエストブロムウィッチの試合は途中から壊れてしまったので（笑）、ほとんど見なかったんですが、稲本がアシストしたところだけ偶然目撃。他は見るところが無かったのではないかなあ（笑）。
メーラーなんざ使えてればいいや、とか思って（何）あまり気に掛けていなかったんですが、数日前に突然ASAHIネットの「送信」がエラーではじかれるようになってしまって大あわて。
554 <ぐはは.jp[IPアドレスじゃ]>: Client host rejected: Access denied
設定などはなんにもいじくった覚えが無いため、泡食ってサポートに連絡してみたわけです。
接続先のサーバーなどを変えたり、プロトコルをSMTPやらSMTPsやらいろいろ試してみたり、いろいろと試してみたんだけどどうにも送信できない。でも結局、「ESMTPを使用」していなかったことが原因だってことがわかりますた。何も変えていないのに、という頭を切り換えて、設定をすべて洗い直してon/offしてみたら原因に行き当たったわけです。*1
しかし、トラブるといろいろ機能や情報源などを教えてもらったり調べたりするもんで、勉強になりますたよ。せっかくなのでBecky!ユーザーの皆様にはすでに知っておられることなども多いでしょうけど、メモっておくです。
Becky!ってプロトコルのログを取ることができるんですね。こんな感じに。
>>> 2006/02/12 12:11:40 <<< >>> Connecting to "mail.asahi-net.or.jp" (SSL/TLS) [2006/02/12 12:11:55] <<< 220 mail.asahi-net.or.jp ESMTP Postfix HELO [ローカルIPだよ] 250 mail.asahi-net.or.jp RSET 250 Ok MAIL FROM:<あちきの@メアド> 250 Ok RCPT TO:<宛先の@メアド> 554 <2ぐはは.jp[IPアドレスじゃ]>: Client host rejected: Access denied QUIT 221 Bye
これ便利ですねー。最初こんな機能あること知らなかったので、わざわざSSL/TLSを外してetherealしてましたよ。
あとこのあたりが参考になりました。
http://www.becky-users.net/faq/index.html
http://www.tietew.net/b2search/
また、今回サポートの方に「あちきんとこの固定IPが一部ブラックリストに載ってるよ」ということを教えていただきました*2。ほげー。なんでやねん。そもそもハニーネットは違うIPでやってるし、今通信用に使ってる固定IPってサーバーとか立ってなくなって久しいのに。で、ポインタを見たら、2月10日と11日にチクリ入れられた（笑）みたい。この件は追跡しないとあかんのですが（はーめんどー）、情報はこのあたりに出てました。
http://www.whois.sc/
上記サイト経由こちらがブラックリスト。
http://www.au.sorbs.net/
sorbsは有名ですかね。
あと、ここからはちょい余談なんだけど、今回通信のログを確認してみて、改めてHELOとかEHLOでローカルIPが漏れるの気持ち悪い、って思ったですよ。やっぱWizerd Bibleの金床さん方式でバイナリいぢくるしかねーかな（笑）。
ちなみにhttpなメールプロキシってのも見つけちゃいました。セキュリティ関係としちゃあまりお勧めしたくない感じだけど（爆笑）。
http://www.a-effect.com/motsugo.html
今度のプレゼンテーションのネタとしてSQLインジェクションなどの世間的な一断面としての現状（長いぞ（笑））を調べているんですが、なんか増えてる気がするなあ。数値的なデータを示すことはできないんですが（いろんな意味で）、少なくともこれまで多くの欠陥が改修されているのにもかかわらず、若干増であるようです。しかも特徴的なのは、同じ種類のヤツが増えてるってことなんだよねー（呆）。
これってどーゆーことなんだろう？
考えられる原因は、同じASP業者とか、同じISPを使ってるとか、あるいは同じ書籍を見ているとか、そういう感じなんすかねー。もし後者だとすると、やぱ欠陥のある書籍ってちゃんと情報を流通させないとあかんのだろうなあ。
…って実は（笑）、書籍の欠陥をまとめて公開するサイトなどを作ろうかって思っていたんだけど、どうもそういうリスキーなプロジェクトには協力してくださる方を誘えないぽいのでｗ（書き物してる人は特に誘えないかも（笑））、高木先生よろしく日記で公開しちゃおうかなとか思ってます。ぐはは。
やぱ去年とかのように言論自粛して、どちらかというと説き明かす系啓発系の日記つけてるよか、こういう路線の方がおもしろいだろうしねーヽ(´ー`)ノ
qmail完全解説―qmailを使ったセキュアなメールサーバの構築
qmailでは、そのSMTPサーバーの送信先として可能になるドメインはホストのリストを持っています。これが「rcpthosts」です。
＜中略＞
このrcpthostsファイルで送信先を限定できるので、たとえば、外部から来たメールは自分のドメインにしか配信しない、という設定ができます。この設定をすると、qmailはXXX.YYY.com宛委に配信されるメールしか受け付けなくなります。通常はこの方法でオープンリレーを抑止することになります。
rcpthostsの記述の例mydomain.co.jp 自社のドメインへ送信可能とする .mydomain.co.jp 自社のサブドメインにも送信可能とする
この時点で微妙に地雷があるのにもしかしたらお気づきかも知れません（笑）。
その数ページ後、P93に、「以下は、よく使われるrcpthostsファイルの例です。」として以下のようなサンプルが掲載されています。
localhost .sea-star.com sea-star.com .mailmagic.org mailmagic.org .tramonline.com tramonline.com .mailstandards.com mailstandards.com .name .info .biz .jp .com .net .org .gov .uk .kr .ac .am .tw .hk .cx .it .fm .to .st .cc .nu .edu .gr .su .cn .au .sg .at
同様の設定例はP50（第2部 qmailのインストールとセキュリティ、第3章 qmailのインストール）にも掲載されています（こちらはリレー先（笑）ドメインがちょっと少なくなってますが、何の慰みにもならないですね）。
さらに、この設定の意味についてはP59（第2部 qmailのインストールとセキュリティ、第4章 qmailの基礎とセキュリティを意識した基本設定）から詳しく解説されています。（4.3.1 rcpthosts）
＜前略＞
qmail-smtpdはこのRCPTのパラメータをrcpthostsに書かれている「送信可能な宛先リスト」と照合して、もしそのリストに送信先のアドレスが書かれていない場合は、配送を拒否し、そのむねをRCPTコマンドに対するエラーレスポンスとして、送信リクエストをしてきたプログラムに向かって返します。
＜中略＞
たとえば、韓国のドメインは「.kr」ですが、もしも、韓国からの迷惑メールの受信の機会が非常に多く、かつ、韓国とメールをやりとりする必要がない、ということであれば、まずはこのrcpthostsファイルに「.kr」を加えないようにすることで、サーバーが踏み台になった場合、韓国へ向かうメールはこのサーバーでは送信しない、ということができます。
うーん。
まーどこ探してもすぐ出てくるのですが、一応ポインタを一つ示しておきます。http://www.fmmc.or.jp/~fm/nwmg/TL6.1Svr/secure/mailserver8.html
基本的なことだけおさえておくと、rcpthostsに設定するのはローカルなドメインとか、プロバイダーのメールサーバーですよね。ようするに信頼すべきサーバー、ホストという意味であって、そこにだけは中継して良いですよ、という意味の設定ですよね。
ってぇことはつまり、上記のような設定を行ったら、無制限リレーサーバーになっちまいますよね（笑）。世界中信頼しまくりというか（笑）。まあおそらく、送信可能、というのと中継可能、というのを意味を取り違えている、というところなのでしょうか。
くわばらくわばら（古）。
こちらはお勧めの本です。
Extrusion Detection: Security Monitoring for Internal Intrusions
上記の本でも触れられている、作者一押しのsguilだけど、トラフィックの解析やるにしても定点観測にしても、まだまだそれなりにノウハウを持った人が見てわかる情報でしかない、という気がするんだよなあ。でもそれじゃ普通の会社とかでは実装、実運用できないっていうか、わかる人が居るか、わかる人を雇える余裕があるか、わかる人がいる会社に頼めるお金があるかしかなさそうなんだよね。
でもこの業界って、まあIT業界もそうなんだけど、いろいろ知ってる人ほど「できないヤツが悪い、勉強不足」みたいな感じの反応ばっかりのような気がするですよ。まあそりゃわかるんだけど、そもそも本業以外にそういうところにお金を割けない企業ってのは対応できなくなっちゃうんですよね。本業がWebサービスとかっていうのなら、そりゃセキュリティをしっかり考えなきゃならないところなんだけど、
とか考えると、セキュリティってのがもっと拡散して、負荷分散されてく方向か、あるいは具体的な警告まで、可能ならば予防措置までを自動化するか、そんなソリューションなのかなあ、という気がしてきますね。その自動化ってのが例えばIDPみたいなものだったりするのだろうけど、いかんせんまだ自動化するには完成度が低すぎるというか、洗練されてないんだよね。危なくて任せられないって感じ。ウイルス対策ソフトウエアなんかを見ていると、ほとんど何もしないで良いくらいかなり自動化されてきているけど、逆に肝心のエンジンが破綻しつつあるしねえ。
なんかパラダイムシフトが必要なのかなあ。
http://nekopunch.tv/rena2/
新聞の書評欄の広告にいきなり本の広告が出ていてびっくり。その昔わらかしてもらったよなー＞漫画
本出たらのぞいてみようっと。
http://www.itmedia.co.jp/enterprise/articles/0602/10/news102.html
なお同社は2月6日より調査を開始し、いったんサーバを停止したが、その後7日9時33分までの間、検証のため9回にわたりサーバを開放していた。
http://www.peachjohn.co.jp/info/apology/index.html
検証って何を検証してたんだろうかねえ。
これだけの情報では何とも言えないけど、っていうか、これだけしか情報を知らないと、もちろん情報が保護される状態で「検証」していたんだよね？とかツッコミたくもなるよなあ。
っていうか、被害者は誰なのか、被害者のためを考えて情報を出したりお知らせしたりしてるのか、という観点から見ると、まだまだとっても心許ないところが多いなあ。あちきも漏洩被害者になってしまったわけなんだけど、聞かないとわからない大事なこととかがちゃんと知らされてなかったり、リスクの認識に甘さがあったりしてるからなー。明日もう一度ツッコミ入れてみるけどね。ってほとんどクレーマーだよな（笑）。
