| 日記 |
| 2003年2月4日(火) 久々にwebをみてみると… |
| 自宅にWebサーバー！！そこには想像以上の利用価値があった！！ いろいろつっこみどころのある記事。 まず、デメリットにある「ハッカーの被害をうける」というところ。ハッカーという言葉の使い方についてはさておくとしても、下にある「ホームページのデフォルトページを書きかえられた」と書かれてますが、本当にそれだけですんだのでしょうか？他人ごとながら心配です。さらにいえば、最近のワームはきちんと管理されていないサーバを伝播し、その結果ネットワーク全体に迷惑がかかるのですから、簡単にサーバをたててメンテはいい加減（全くのメンテナンスフリー、という表現がある）というのはまずいと思います。 よくよむと、「今では、外づけディスクに同じ内容のものをコピーすることでガードしています」と書かれています。つまり、侵入されることをふせごう、という気持ちはないのね（sigh） しかし、それ以上に問題なのはこちら。 グローバルIPアドレスがDHCPで供給されるために、接続業者が装置をリニューアルした時にアドレスがかわってしまったことくらい つまり、この人はいつかわるかわからないIP addressをDNSに登録していたわけです。DDNS運用ということでもないようですが、こんなことってゆるされるんでしょうか。たまたま別のホストにそのアドレスが振られてしまったらどうするのでしょう？そのホストで危険なスクリプトが動いているかも知れない。そうでなくとも、そのホストへの25/tcpや80/tcpへのアクセスを、不正アクセスと考えるのは、ありそうな話です。そのとき、この人はどうするのか、はなはだ疑問です。 そして、こんな原稿を掲載したインプレスも、内容についてきちんと吟味してもらいたいものです。 久しぶりに不快な記事を見ました。本来、読者が不快な思いをするような文章は書くべきでないと思いますが、この程度の意識で自宅サーバを立てるような人がいることを知ってもらうべく、あえて書きました。 ＃slammerについてはいろいろと情報が入りつつあるので、近いうちにまとめるかもしれません。 |
| 2003年2月5日(水) Slammer worm問題のまとめ |
＃嘘書いてる恐れもあります。気付いたら指摘していただけると幸いです。なお、下記以外にjanog MLの情報を参考にしています。1) 脆弱性この問題は、MS02-039と呼ばれる脆弱性に起因する。 感染先はMS SQL Server 2000およびMSDE 2000であり、この脆弱性に対するパッチは2002/8/1に発表されていた。基本的にバッファオーバーフローに起因し、1434/udpへのDoS攻撃(そして感染)を行う。ただし、サーバプログラムそのものに寄生するウィルスではなく、それ自身がメモリ上に常駐するタイプのワームである。そのため、コンピュータを再起動することにより（メモリがクリアされるため）ワームを除去することができる一方、ファイルをチェックするタイプのウィルスチェックソフトでは感染を検出することができない。 参考: 2) 症状[port139ml:02112]によれば、Pentium III (1.1GHz)のマシンで1秒間に11,000くらいのワームを放出する。これほど多くのワームが放出される原因としてはネットワークの高帯域化、PCの高性能化という要因もあるが、ワームのサイズが376バイト（キロバイトではない）と非常に小さかったことにもよるだろう。某社のスイッチではフィルタリングできなかった、という情報も有り。また、別の某社のルータはこれによるトラフィックにより「落ちた」のを観測している。いずれも、ワイヤスピードに近い高速の機器であり、ルーティングがおいつかなかったり、ルーティングテーブルの更新が間に合わなかったり、という原因が示唆されている。 ただし、日本国内においてはそれほど大きな被害は発生しなかった。それは、ZD Netによると、IP addressの上位24bit決め打ちでの攻撃を行うことから、感染した組織内で広まりやすいが外部組織には出にくいという特性があり、日本にはあまり来なかったことと、日本ではMS-SQLサーバがあまり使われていなかったことがあげられている。逆に、最も大きな影響を受けたのは韓国であったが、これは上記の逆の現象が起きたと見ることができよう。 世界レベルでは、ITRによればResponse Time、Packet Lossともに1/25 10:00ごろにするどいピークが見られることから、世界中のネットワークに対して1時間弱程度、大きな影響が見られる。逆にいえば、グローバルには1時間程度で混乱はおさまったと見ることはできる。問題の機器の切り離しや問題ポートの閉鎖について、大方のサイトでは１時間以内に処理がなされたのか、問題の機器が属するネットワークが上記のような理由で落ちてしまったためなのかは不明だが、韓国における状況などを見るに後者の影響は小さくないと考えられる。 F-secureによると、世界中に13あるルートサーバのうちの5つが落ちたと書かれている。しかし、その事実はないという情報もある。 なお、経済産業省によるレポートが公開されている。役所としてこのような情報をいち早く公開したことについては、高く評価したい。 3) 対処ホストレベルでは、このパッチをあてるのが簡単。ネットワークレベルでは、1433/udp, 1434/udpを閉じることで問題を回避できる。 4) 原因脆弱性は半年も前に知られていたにもかかわらず、なぜこれほど影響があったのだろうか。私は、当初は多くのサーバにおいてパッチがあてられていない、つまり管理をさぼっているものと考えていた。しかし、事情はそれほど単純ではなかった。 要点はITPro(ユーザ登録、ログイン必要)とZDNetの記事にある。つまり、1)パッチを容易にあてられない(パッチすると正しく動かなかったり、別の脆弱性が発生する)、2)ユーザが気付かないうちにMSDEがインストールされることがある、の2点だ。いずれにしてもOSベンダーの責任は重いと言わざるを得ない。なお、今回マイクロソフト自身の社内でも感染が起こっていたことからして、いかにパッチあて作業が困難であるかを物語っているといえよう。 もう1つの問題として、（昨日の日記にも関連するが）「放置状態」のホストが大量に存在することがあげられる。今後、常時接続環境が普及すれば、このような攻撃による被害はさらに深刻になることが予測される. 特定の相手を狙う攻撃についてはある程度の対策がなされつつあるが、不特定な脆弱サーバを踏み台にする攻撃については、ほとんど対策がなされてきていないことから、それへの対応が望まれる。どちらが主たる原因であるにせよ、2001/7/19に出現したCode Redから何も学んでいないといえよう。 参考： 5) 今後今回の件は、いくつかの点で今後に波及効果を及ぼすことが考えられる。 まず、セキュリティの脆弱性を公開することの是非が問われるだろう。今回のワームでは、この脆弱性を発見したLitchfield氏によるサンプルコードがそのまま使われていた。今後、脆弱性を発見したセキュリティ研究者がそれをどのように公開していくのか(あるいは公開すべきでないのか)、議論されることになろう。 参考： もう1つの問題として、DNSへの影響がある。 上記の通り、1433/udpや1434/udpを閉じることによりこの問題を回避できる。しかし、これらのポートはいわゆる「well-known port」ではないため、MS-SQL以外の目的で利用される可能性がある。 （手抜き解説：ここは不正確でもつっこまないでね :-） TCPやUDPによる通信では、送り元（クライアント）と送り先（サーバ）のアドレスとポート番号が必要である。ある時に利用されているポート番号が一意に決まっているため、同じ２ホスト間の通信は識別され、混乱することがない。例えばHTTPというサービスを利用する場合、サーバのポート番号としては80/tcpを利用するのが一般的である。一方、クライアントは、その時に利用されておらず、かつwell knownでないポート番号（つまり1024以上）を使う。これを何番にするかは、他の人やサービスが何番を使っているかに依存するため、実際にその通信を開始するときに決められる。ちなみに、well known portはこのように用いられるのが一般的。一方、それ以上の番号でも予約されていることもあるが、いずれもサーバとしてサービスを提供する場合の問題であり、クライアントとして他のサーバへ接続する場合には、それほど気にする必要はない（例えば、現在、手元ホストからUNIXホストへのHTTP通信では、クライアント側は予約された3382/tcpを利用している）。これ以上詳しいことはTCP/IPに関する書籍を参考のこと。 例えば、DNSのcache serverが *たまたま* これらのポートを利用して応答しようとすると、名前解決に支障が出てしまう(BINDの実装では、1回つかんだポートを再起動されるまで使いつづけるため、たまたまこれらのポートを握ってしまうとそのキャッシュサーバを利用するクライアントは名前解決が不可能になってしまう)。 ＃なお、これへの対応としては、cache serverが53/udpを利用して応答を返すようにすれば良い(こういうfilteringをしていることが判っていれば、ということにはなるが) 参考： 現在、多くの人にとってインターネットはweb (80/tcp)とメール(25/tcp, 110/tcp, 場合によっては143/tcp)、ホームページを開設している人にはFTP (20/tcp, 21/tcp)であろう。あとは名前解決で使う53/udpくらいが開いていれば十分、という使われ方が一般的と思われる。 しかし、インターネットを利用した技術、サービスはこれがすべてではないし、まだまだ新しい技術が出てくる可能性もある(今知られているところでもIP電話やGRID computingなどがあり、IP電話ではwell-knownではないudpポートのうち空いているものを利用する実装がある)。こういった問題によりポートが閉じられサービスが限定されていくと、技術的な進歩がそこで止まってしまう危惧がある。 今ひとつの問題点として、portレベルでのアクセス制限の限界がある。Joke RFCのRFC 3093ではないが、80/tcpであれば何でも通すのであれば、カプセル化により結局どんなパケットでも通ってしまう。実例としては、P2Pアプリケーションには53/udpを用いているものがあるらしい(P2Pの是非についてはここでは論じないことにする)。 |
| 2003年2月7日(金) DNS |
| 結構あちこちでドメイン名について話題になっているようなので、補足。 ドメイン名について、RFC952によれば、 <domainname> ::= <hname> <hname> ::= <name>*["."<name>] <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>] と規定されている（letとかをきちんと規定してないあたり、おおらかなものだ）。その後にでたRFC1123によると、最初の文字として数字を使うことは、ゆるされている。いずれにしても、「_」(アンダースコア)を使うことはできない(この話は概出)。 #T-Code使ってると「概出」ってすごく打ちやすいわ。うれしいかどうかはともかく :-) 今ひとつ注意すべきは、「-」を使うのはかまわないが、「-」でおわってはいけない、ということ。こちらの方は、数年前某レジストラがまちがえて登録してしまい全部削除した、ということがあったような気がするので知っている人もいるかも知れないが、念のため。 おまけ。 私の主張。来年10月に合併という話もあるので、早めにいかねば。 追記。 おととい指摘した「1434/udp filteringにともなうDNSの問題」について、JPRSがアナウンスを出しました。 |
| 2003年2月12日(水) うぐぅ |
| NREの弁当シリーズで、「健日弁当」というのがでていました。 「血液サラサラ弁当」(うめぼし、高野豆腐、キャベツ、きりぼし大根、たまねぎ、さば、かぼちゃ、ごぼうきん平、発芽玄米など)、「ポリフェノールで血液サラサラ弁当」他で、1つ680円。こういう需要ってかなりあるんでしょうね。 あとは山手線の液晶テレビでPiaきゃろ3の宣伝やってましたが、Air以来なのかな？ 写真: モナと、その向かいにいるすらりん。 だれよりあなたの… |
Akiary v.0.42+puni.net patch 0.3
