computerworld.jpは3月17日に『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』と題した記事を公開したが、一部誤報があるので訂正する。 米国White Hat Securityの研究者らがまとめた2010年版の深刻なセキュリティ脅威トップ10では、DNSリバインディングが1位となった。同社では、2006年から毎年、脅威トップ10を発表している。 http://www.computerworld.jp/news/sec/177029.html 当初、この記事を読んで違和感を覚えた。DNSリバインディングという攻撃手法そのものは以前から知られているものであるし、この記事で説明されている脅威の内容についても、以前から知られているものと違わない。このタイミングでなぜ、DNSリバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
JavaScriptのXMLHttpRequestでのクロスドメイン制限を回避できるなら、iアプリはどうなんだろう？ ということで試してみた。ちなみにDocomoのiアプリは「制限したHTTP通信」をサポートしており、一応HTTPが扱えるが、携帯電話にダウンロードされたiアプリは、ダウンロード元のサーバへしかHTTP通信できない、また、HTTP以外の通信をサポートしない、という制限がある。 参考：Doja HttpConnection 「ダウンロード元のサーバへしかHTTP通信できない」という点においてJavaScript（Ajax?）と似ている。結果から言うと、iアプリもDNS Rebindingでダウンロード元以外のサーバへアクセス可能だと判明。 mydomain.comのIPアドレスを1.2.3.4にセット（1.2.3.4は自分が管理するサーバ） mydomain.com(1.2.3
先月発表されたGoogle Public DNSですが、課題であったCDNとの相性問題を解決すべくGoogleが、IETFでDNSに関連する標準規格提案を開始しました。 「DNS問い合わせメッセージの中にユーザ(クライアント)のIPアドレスを埋め込めるような追加を行おう！」という内容のものです。 先月サービスを発表してから次の月にはもう標準化を開始するという、このスピード感は凄いと思います。 「Google code blog : A proposal to extend the DNS protocol」 Google Public DNSそのものに関して「Google Public DNS解説と個人的妄想」を記事として書きましたが、その中でも「DNSを活用した他者CDNとの相性」という部分でGoogle Public DNSが抱えている課題を解説しています。 今回のInternet D
Google信者のGoogle報道に疲れた。 測定もしないで、Googleだから速い。それはないだろう。測定しました。 日本国内にGoogleがサーバー設置していたらそりゃ速いだろうが、国外なら、国内の方を使った方が良いよね。 この報道はGoogleだから速いでなく、「DNS更新が速い」って意味だと思うんだ。 事前調査から。 最初は、PINGで結果を想像してみる。Google DNSのPing応答で回線速度を想像しておく 接続は、大学→拠点間サイネット→インターネット PING 60.56.0.135 (60.56.0.135) 56(84) bytes of data. 64 bytes from 60.56.0.135: icmp_seq=1 ttl=55 time=1.69 ms ... 64 bytes from 60.56.0.135: icmp_seq=5 ttl=55 tim
シンプルでスケーラブルな分散ストレージを自社開発したライブドア 一方ライブドア執行役CTOの池邉智洋氏は，同社のブログや写真投稿サービスなどのインフラで利用中のストレージ仮想化ソフトを自社開発した事例を紹介した。ライブドアのサービス群が求める要件が「いかに安価に容量を追加できるか。過剰な機能と信頼性は不要」（池邉氏）と判断。メーカー製のネットワーク・ストレージの利用を止め，「ファイルのパスがそのままURLになるため，ファイル・システムのパスをURLに変換しなくて済む」HTTPで入出力する分散型仮想ストレージの開発に踏み切ったのだという（写真4）。 設計思想は「複数ノード間の一貫性はCAP定理に基づいて遅延を妥協し，スケーラビリティと読み出しの速さにこだわった。一方で書き込みはそこそこの速度でよく，認証とアクセス制御はアプリケーションで実装するので不要」（池邉氏）というもの。HTTPサーバー
ニューヨークではiPhoneから「はてな」が使えない
タイトルを「ぼくがはてなを使わない理由」にしようかと思ったがやめた。使わないのではなくて使えないのである。 あまり知られていないことだが、NYでiPhoneのSafariを使うとはてな（www.hatena.ne.jp）につながらない。wwwだけではなくてb.hatena.ne.jpもだめだしd.hatena.ne.jpも、とにかくhatena.ne.jpにはエラーが出てつながらない。 これは以下の条件で起こるようだ。複数台のiPhoneで再現した。 アメリカ東海岸AT&T経由で接続（3G・EDGEを問わない）ニューヨークに限らず、米国東部のボストン、フィラデルフィア、シカゴ、マイアミでも同じだった。逆に中部のミネアポリスではちゃんとつながった。はてなのユーザが多そうな西海岸もきっと大丈夫なのだろう。 Wi-Fiで接続したらこの問題は起こらないため、キャリアのAT&Tがおかしいのではないか
英語ITブログAsiajinの問い合わせアドレスに、「アジアでのドメイン名に関する問い合わせ」というのが来ていた。おおざっぱに訳すとこんな内容。 我々はグローバル企業のアジア地域でのドメイン名登録と知的財産権保護の紛争解決を行なっている組織です。貴社の確認が必要な緊急の用件でご連絡差し上げました。 2009年5月8日付けで、「JCJCインターナショナル ホールディングス社」から以下のドメインの登録申請を受け取りました。 ドメイン名: asiajin.asia asiajin.com.cn asiajin.hk asiajin.tw インターネット商標 Asiajin これらのドメイン名や商標は、貴社のものと一致するように見えます。そこで、 1. JCJC社がこれらのドメイン名を登録しても良いなら、そのまま彼らに登録を許可します。 2. もし貴社とJCJC社に全く関係がないなら、彼らは貴社の
Chromeの動作が圧倒的に速いように感じている。Chromeがリリースされた当初、それがなぜなのかよく分からなかった。グーグルだけにできて、ほかのWebブラウザ開発者にできないことなどあるように思えないが、それにしてはあまりに速いように感じたからだ。 その疑問のほとんどは、Chromeのオープンソースプロジェクト版「Chromium」の公式ブログの解説で氷解した。ブログを読んで分かったのはグーグルのエンジニアたちが信じられないほどのスピード狂であることと、そのスピードへのこだわりには2種類の“スピード”があることだ。 1つは処理速度、もう1つは応答速度だ。特に後者、ユーザーをできるだけ待たせない、イラつかせないということに対する徹底したこだわりは、すさまじい。その背後には「スピードとは、つまりお金だ」という洞察があるようだ。 0.5秒の遅延でユーザー離れ グーグル創業約1年後の1999年
セキュリティシンクタンクの米Black Hatとインターネット協会の共催によるカンファレンス「Black Hat Japan 2008」が10月5日から10日まで、東京・新宿の京王プラザホテルで開催中だ。 まず、8日までの4日間は、授業形式で詳細な知識を解説する「トレーニング」を実施、続いて9日・10日にセキュリティ専門家らによる講演「ブリーフィングス」を実施する。 9日に行われるブリーフィングスの基調講演には、セキュリティ研究者のDan Kaminsky氏が登場する。Kaminsky氏は、7月にその存在が広く公になったDNSキャッシュポイズニングの脆弱性（通称「カミンスキー攻撃」）の発見者。8月にラスベガスで行われたBlack Hatに引き続き、日本でもこの脆弱性について講演する予定だ。今回、Kaminsky氏にメールでインタビューした。 なお、ブリーフィングス2日間の参加費は8万950
こちらは独自ドメインからレンタルサーバー、フレッツ接続専用会員までトータルサポートのプロバイダー、BiG-NETです。 いつも弊社ユーザーのページにアクセスをして頂きましてありがとうございます。 http://www4.big.or.jp/~kanai/MT/archives/000840.html 404 Not Found (ファイルが見つかりません) 申し訳ございませんが、お客様がアクセス要求されました上記ページは、現在アクセスが出来ません。 弊社では、なぜアクセスできないのかと言う第三者からのお問い合わせにはお答えすることが出来ません。 もしこのページの関係者をご存知でしたら、連絡を取ってみることをお薦め致します。 何卒ご容赦下さい。
2008年7月から世界的に話題になっているDNSキャッシュ・ポイズニングを効率的に実現する手法について，発見者であるダン・カミンスキー氏が，Black Hat 2008の席上でプレゼンテーションを行いました（8月6日）。このキャッシュ・ポイズニングのぜい弱性については，いろいろ動きがありましたので，ぜい弱性に関連するイベントを追いかけておきましょう。 ■キャッシュ・ポイズニングのぜい弱性の対応経過 まずは，ぜい弱性に代表的なイベント一覧です。他の関連イベントについては， Status Tracking Note TRTA08-190B：複数の DNS 実装にキャッシュ・ポイズニングのぜい弱性 を参照してください。 2008年7月8日 BINDを含む複数のDNSサーバーが，ダン・カミンスキー氏が指摘するキャッシュ・ポイズニングを効率的に実現する手法に対してぜい弱であったことから，対策版がリリ
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
yebo blog: DNSキャッシュ汚染問題に懐疑的な研究者が納得
2008/07/15 DNSキャッシュ汚染問題に懐疑的な研究者が納得 Dan Kaminsky氏が公表したDNSのキャッシュ汚染の脆弱性について、大騒ぎするほど深刻なのか懐疑的な人が次第に多くなっているようだ。脆弱性の詳細は8月のBlack Hat会議で公表するとして、詳細がわからないまま時間(パッチを当てるために取られた時間)が経過している点が懐疑論者を増やしているものと思われる。Network Worldによると、セキュリティアナリストのRich Mogull氏が仲介して、懐疑論者のThomas Ptacek氏とDino Dai Zovi氏をKaminsky氏と引き合わせ彼の発見した内容を説明したそうだ。その後、両氏はDNSの欠陥が重大であることを確信した。キャッシュ汚染に対する攻撃法が納得できるものだったようだ。Kaminsky氏の姪サラと共にDNSのキャッシュ汚染問題の影響を説明し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
