1 :
名無しさん@お腹いっぱい。 :
2008/07/23(水) 23:13:15 (前略)
今回の脆弱性についてはUS-CERTなどが7月上旬にアドバイザリーを公開。しかし、詳しい内容は伏せられており、
セキュリティ研究者のダン・カミンスキー氏が8月のBlackhatで発表する予定になっていた。
ところが手違いで、詳細情報が一般に公開されてしまったという。攻撃者がこれを利用すれば、悪用コードを
作成してDNSキャッシュポイズニング攻撃を仕掛けることが可能になる。
US-CERTのアドバイザリーでは、システムにこの脆弱性が存在するベンダーとしてCisco Systems、Debian
GNU/Linux、FreeBSD、富士通、Hewlett-Packard(HP)、IBM、Internet Systems Consortium(ISC)、Juniper Networks、
Microsoft、Novell、Red Hat、Sun Microsystems、SUSE Linux、Ubuntuなどを挙げている。
(以下略)
DNS脆弱性の詳報が手違いで流出
http://www.itmedia.co.jp/news/articles/0807/23/news031.html DNS終了
記事を省くな
(略した部分を貼っておきますね) このうち、Microsoftは7月の月例パッチで問題を修正。ISC、Cisco、Debian、Red Hatなどもパッチやアドバイザリーを公開した。 今回の詳細情報流出により、企業やISPが緊急に脆弱性の修正パッチを適用する必要性が一層高まったとSANSは指摘している。
たったそれだけw
5 :
名無しさん@お腹いっぱい。 :2008/07/24(木) 18:39:28
6 :
名無しさん@お腹いっぱい。 :2008/07/25(金) 09:00:09
セキュ板なのにこのレス いかに糞板なのか物語ってる
8 :
名無しさん@お腹いっぱい。 :2008/07/26(土) 13:06:04
9 :
名無しさん@お腹いっぱい。 :2008/07/26(土) 14:03:03
3)インターネットの利用を中止する もたもたしているといつ攻撃を食らうかわかったもんじゃないので 回線を引っこ抜いてそれを天井から吊り下げ首を引っ掛けちゃいましょう。
10 :
名無しさん@お腹いっぱい。 :2008/07/27(日) 00:11:56
11 :
名無しさん@お腹いっぱい。 :2008/07/27(日) 10:32:24
手違いどころじゃないよ。脆弱性情報を学会の発表か何かと勘違いしているのな。 特にDNSなど、いかに素早く対応するか真価を問われているというのに、カンファレンスで 「発表」する予定だったと。 > この脆弱性情報は当初、IOActiveのダン・カミンスキー氏によって8月のBlackhat > カンファレンスで発表される予定だったが、同氏の情報公開の遅さに業を煮やした人物が > この脆弱性にかんする自らの見解を示しており、その情報を基に攻撃コードが作成されて > いるとみられる。 > Julien Desfossezと名乗る人物がPythonで動作する攻撃コードを公開しており、 > 「動作は遅いがしっかり機能する」とコメントしている。
12 :
名無しさん@お腹いっぱい。 :2008/07/27(日) 12:18:10
つーか脆弱性自体はずいぶん前に発見して、 半年たってようやく各社パッチの準備ができたので一斉に更新して、 テストや適用の期間を見越して詳細の公表を1ヶ月遅らようとしただけ 一部で実証コードが公開されたことで、 発見者があわてて詳細を大本営発表したのが手違いというか間違いってこと 第三者による独自解析と、発見者直々の詳細レポートでは影響力が全然違うからな
13 :
名無しさん@お腹いっぱい。 :2008/07/27(日) 13:10:56
"大本営発表"とか、意味もわからずに言葉を使うなよ 以前からわかっていたものを、今年になってから騒ぎが大きくなったということ 問題はボンクラ管理者は腐るほどいるため、その警告と対策が末端まで行き渡らないってこと 水面下で対策を進めることはいいが、無駄に時間をかけることはこれを知っている悪意ある 人間の跳梁を許してしまい、逆にネット上で大問題になることが最大の周知と防御になる
221.113.139.145にtracertすると重複しますが、これでいいんですか? --- 16 27 ms 26 ms 26 ms 125.170.96.54 17 27 ms 27 ms 26 ms 210.163.253.2 18 27 ms 27 ms 27 ms 60.37.14.2 19 27 ms 28 ms 27 ms nv-kf011.ocn.ad.jp [221.113.139.145] 20 27 ms 28 ms 28 ms nv-kf011.ocn.ad.jp [221.113.139.145]
16 :
名無しさん@お腹いっぱい。 :2008/07/27(日) 15:22:34
これってDNSClientサービスをオフにしててもダメなん?
2ch.netなら、2ch.netのネームサーバがこの脆弱性にやられたら、 第三者の管理下にあるサーバを2ちゃんねる掲示板のように見せかけて運用することも可能… と言ったようなお話。 サーバ運用者は可及的速やかに対応を…という件であって、一般ユーザはまあ。
つーかDNSのクライアントを限定すればいいやン
cache poisoningってそんな大問題? 大きなサーバならあれだけど 小さなサーバならキャッシュしなければいいだけジャン
セキュ板のレベル低下に絶望した
21 :
名無しさん@お腹いっぱい。 :2008/07/28(月) 21:45:01
どう低下したか言ってくれなきゃダメよ
20じゃないけど低下を感じる部分を近くの書き込みで見ると >これってDNSClientサービスをオフにしててもダメなん? うん駄目 一つはプロバイダのDNSサーバが汚染されてたらクライアント止めても無駄と言う事実 もう一つはDNSクライアントを止めると確かにキャッシュはしなくなるが、肝心の名前解決の問い合わせを毎回外部に求めるようになる事が逆に危なくなると言う事 外部からの名前解決に答えない個人のPCの場合、キャッシュの生存時間が攻撃者には分からない為、攻撃するタイミングが分からない でも毎回聞きに出ていたら、それに折り返した攻撃がし易くなる つまりキャッシュをしない方が攻撃側には都合が良い事もある >つーかDNSのクライアントを限定すればいいやン 問題はクライアントに依存しないし、クライアントが万全でもルータがタコだと攻撃可能になっている なので、クライアントの種類に関わらず対策が必要になる 特にソフト的に何とかなる物よりも、ルータ等のハードの対応に手間取ると言われている >小さなサーバならキャッシュしなければいいだけジャン 上で書いた通りキャッシュを無くすと攻撃にさらされるタイミングが増えてしまうし、小規模でもDNSサーバを公開している場合はキャッシュが存在しない事が相手にモロにばれる 攻撃者にしてみれば入れ食い状態なので、すごく楽 正解は、汚染されてない外部DNSサーバーから引いたキャッシュをしっかり保持し、その外部DNSサーバへの問い合わせポートを完全にランダムにして予想させない事 これだけで汚染される可能性は殆ど無くなる 大騒ぎする割にはやらなきゃならない事は二つしかない 対策済みと公表されるまでは汚染される可能性のあるDNSサーバで名前解決をしない 外部に名前解決を問い合わせるポートを固定にしない
23 :
名無しさん@お腹いっぱい。 :2008/07/28(月) 23:19:21
サーバに手を入れられるなら 問い合わせのFQDNをランダムに大文字化することで 10〜20ビットほど稼げるらしいけど ポートランダム化で稼げるのもせいぜい16ビットだし
まぁサーバを動かしてる個人の場合は既に大部分がポートのランダム化は終了してるはず Windows系にしてもアップデートでランダム化は導入されたので、一番素人な層も最低限フォローされたはず でも資金を投入しないと改善できないルータの部分が厳しい ヤマハは即座に対応したけど、業務用途じゃない一般のブロードバンドルーターは一部のメーカーを除いてほったらかしと言うのが現状だからね 内部でどんなにランダム化されてても、ルータが全部同じポートに固定してたら全く意味が無くなる それでも個人のルータなんて私怨でもなきゃ誰も攻撃しないからまだ安心 狙われたら危ないけど、そもそも狙われないだろうし やっぱ怖いのはプロバイダのDNSが腐る事かな
25 :
名無しさん@お腹いっぱい。 :2008/07/28(月) 23:44:24
ルータってプロバイダに取り次ぐだけでしょ?他から覗ける訳じゃないしプロバイダがちゃんとしてれば問題ないジャン
ファーミング詐欺始まったな
>>25 確かにルータは内部と外部をNATを通して取り次ぐだけだけど・・・
確認すれば分かる事だからはっきり書くけど、ルータは内向けのポートはどんなポートでも受け付けるけど、外向けの出口は綺麗に統一されて出て行く物が多いよ
今回の攻撃手法はPCやルータが外のDNSを見に行く時に攻撃する仕組みになっている
つまり、ルータの中が見えない事は攻撃側の難度を上げる事は出来るけど、外に聞きに行く時に嘘の情報を掴まされる事は防げない
ルータが正規のDNSサーバから名前解決を貰ったと思っていても、こっそり大嘘を掴まされてルータの内側のDNSクライアントのキャッシュが汚染される可能性がある
これをやられると外部のDNSサーバがどんなにセキュリティー万全でも防げない
防ぐ為にはルータから出て行く名前解決時のポートがランダムになっている必要がある
と言う訳で、ルータの中が覗けない事は攻撃者にとって攻撃に要する時間が長くなると言う効果しかない
同じポートさえ見張っていれば、いつかは目的のパケが出てくる可能性が高い訳だしね
狙われないだろうとは書いたけど、ちょっと竹島問題でも燃え上がれば日本人を絨毯爆撃する暇人が隣の大陸に大量に発生するかも知れない事を考えると、楽観は出来ない
「Googleにアクセスしたら新しいツールバーがダウンロード出来ると言うメッセージが表示され、OK押したら竹島の写真入りウイルスだった」
とか、すごくありそうじゃないか?
だからルータの出口がランダムかどうかは重要だよ
>>24 ヤマハは対応したのかな?
ファームを見に行ったけど、順次リリースってどういうこと?
リリースノートを見てもそれらしい修正は入っていないような気がするけど。
設定変更は載ってるね。
30 :
名無しさん@お腹いっぱい。 :2008/07/29(火) 05:31:27
forward onlyにしておけばいいのではないかな
>>30 forward only は自分のキャッシュの中に答えが無い場合は、fowardersに指定された外部のDNSに名前解決しに行くという意味
forward first との違いは効率と速度の問題だけなので、キャッシュに無い場合に最終的に外部に聞きに行く事には変わりが無いよ
キャッシュを探す→見つからないなら外部に聞きに行く→それでも見つからないならもう一度自分で探す→NXDOMAIN
only との差は、最終的な答えだけをキャッシュするか、それまでに得られた答えも全部キャッシュするか
後は first に「それでも見つからなければ・・・」の処理がある分だけ最終的な解決が遅くなる事
only はキャッシュと fowarders に答えが無い場合はすぐに諦める
両方とも外部DNSサーバーに聞きに出るのは同じなので、対策はしなけりゃならない
このオプションを書くと言うことはBINDだと思うんだけど、最新版でポートのランダム化は対策されてますよ
なので、後は外部DNSサーバーの確認とルータの確認だけだと思う
(DNSサーバーがタコの場合はOpenDNSがあるし、実質ルータだけですな)
32 :
名無しさん@お腹いっぱい。 :2008/07/29(火) 09:08:36
>>31 >見つからないなら外部に聞きに行く
それここの説明と違うけど
tp://www.atmarkit.co.jp/flinux/rensai/bind915/bind915b.html
33 :
名無しさん@お腹いっぱい。 :2008/07/29(火) 09:11:58
あいや同じか間違えてました forwardersに対してだけであっても 自分の外に聞きに行くのは同じだから この問題については違いはないと・・・・
あるNSに名前解決のUDPを飛ばす → そのNSが答えを返す NSが答えを返す前に、嘘の答えを悪意者が返すってことですか? その場合、悪意者のIPアドレスはNSのとは違うと思うのですが、返答してきた人のIPアドレスは 見ていないということですか?
35 :
名無しさん@お腹いっぱい。 :2008/07/29(火) 09:21:34
>>34 そこがよく分からないよね
たしか前にinternicが乗っ取られたとき
ipアドレス確認するようにしたんじゃなかったの?
tp://www.hotfix.jp/archives/word/2005/word05-18.html
usen今だに対策してねー
ISPは対応してもルータのファームはそのままだよな。 抱き合わせでモデムルータ使ってるんだから対応汁。
>>34 ,35
UDPを使って一方方向の通信をするだけなので,
IPアドレスの詐称をすれば良いだけ。
39 :
名無しさん@お腹いっぱい。 :2008/07/29(火) 21:45:18
>>36 実家のサーバのISPにお問い合わせしたら、1日で対応してくれた。
自宅アパートで使ってるISPはランダムだった。
会社の一番大手ISPは固定だったw
41 :
名無しさん@お腹いっぱい。 :2008/07/30(水) 08:03:31
forward onlyにしておいて対策万全なforwardersとの間の通信をトンネル化しておけば問題なし
OPENDNS使えば安全?
>>41 トンネル使うって事は相手もトンネルに対応してなきゃならんわな
普通のプロバイダはそう言うサービス提供してないからなぁ
ちょっと普通のユーザーには縁のない話になるな
>>42 ・プロバイダが攻撃されてDNSキャッシュが汚染される
・自分のPCが攻撃されてDNSキャッシュが汚染される
OpenDNSを使えば上の問題は解決するし、プロバイダが対策済みならOpenDNSを使うまでもない
でも下の問題は自分で何とかしなけりゃならない
OSのアップデート、DNSクライアントのアップデート、ルータのアップデートの三つが必要
前二つは探せば何とかなるが、ルータのメーカーが対策しないと無意味に近い
で、なんで大騒ぎになってないのかな。 たいしたことではないってこと。
>>45 マルウェアに感染してそこいじられるってことはあるな
まあ実害はないかもしれないしな(攻撃を受けなかったり受けても問題なく過ごせたり) けれど対策はしておかないとマズイだろう
>>48 PCがDNSに問い合わせた結果を一時保存しておくキャッシュがPC内のどこかにあるだろうがそれが汚染されるかもってこと
外部のOpenResolverが対策済みか調べる方法ってどうすればいいの? telnet出来るならdigで調べれるけど…。
DNS Client サービスを止めてもちゃんと名前解決するんだね。 ルータをつかっているからかな?
>>53 キャッシュがないから毎回読みに行ってるだけでしょ
詐称できるんだと思う人は詐称できません
>>51 DNSの解決速度を上げる為、殆どのOSではキャッシュはメモリ上だけになってる
だからシャットダウンや再起動でキャッシュはゼロになって最初から溜め直しになる
>>53 名前解決が必要になる度に外に聞きに行ってるから
手元の情報を使えない分速度も落ちるし、CPUのパワーも使うし、相手のDNSサーバに負担もかける
何よりDNSサーバが混雑し始めると、回線速度に関係なくブラウザの表示が遅くなったりする
攻撃者にしてみれば、外に聞きに出てくる度に毎回攻撃していれば、いつかは目当てのアクセスが通り過ぎるので攻撃が成功しやすくなる
キャッシュが有効な場合はデフォルトで一週間はキャッシュが残っているので、攻撃者には一週間に一度しか攻撃するチャンスがない
毎日シャットダウンするPCの場合は実質最初の一回しか攻撃するタイミングが無いことになる
プロバイダのDNSが汚染されている場合はキャッシュが有っても無くても同じと言う事を考えると
攻撃されるタイミングが増える上にパフォーマンスも落ちるのでキャッシュ無しはお勧めできない
逆にデフォルトよりキャッシュの生存時間を延ばしておけば、それだけ攻撃されるタイミングを減らす事も可能になる
>>52 プロバイダにメールで問い合わせるのが確実
まだ対策されてないなら「はよ対策せんかいドボケがっ!」と言う追い込みにもなる
___ / \ / \ セキュ板らしい流れになってきたお / ⌒ ⌒ \ | /// (__人__) /// | . (⌒) (⌒) ./ i\ /i ヽ
59 :
名無しさん@お腹いっぱい。 :2008/07/31(木) 00:25:34
でもそれだけ汚染状態が長く続くかも知れないけどな
学校のテストの問題でファーミング詐欺の説明しろって問題で DNSを書き換えてURL偽装する てな感じで書いたんだが間違ってるかね? 名前解決が〜とかいたほうがいいのか
>>60 詐欺が行われる事を説明する為に、以下のような文言が含まれている必要があるかも
順不同
・知名度の高いサイトを偽装する
知名度が低いサイトのURLを偽装しても詐欺という結果に繋がり難い
詐欺を結論させる為には知名度を利用した思考操作が必要
・一括的な方法で不特定多数を欺瞞情報に曝す
単一目標を攻撃する方法であるフィッシング詐欺と区別する部分は、不特定多数を対象にしている部分
ファーミング詐欺という名称を用いる際に必須の説明
・「DNS」ではなく「DNSサーバー」と書く方が正しい
DNSはDomainNameSystemの略
ファーミング詐欺ではシステムの書き換えは必須とされない
・DNSサーバーに一時集積されたドメインとIPアドレスの対応表を書き換える
DNSサーバーの情報を書き換えている行為に言及しつつ
情報という曖昧な表現ではなく、実際に何を書き換えているのかの説明が欲しい
・当事者が行う各種サーバーへのアクセスを不正に誘導する
当事者視点での現象の説明を行う
手法的にはダウンロードファイルのすり替え等も可能であるが、詐欺という説明の主流のみを説明する
・偽装されたサイトを利用して個人情報の奪取を目論む
ウイルス等に感染させる攻撃行為と詐欺行為とを分別する部分
ウイルス等を利用した複合的な手法もあり得るが、目的が攻撃であるか詐欺であるかで名称が変化する
62 :
名無しさん@お腹いっぱい。 :2008/07/31(木) 08:33:54
そうだグーグルとかヤフーとか大手のところはTTLを無限大にしておけばイイヤ それかゾーン転送してそれ使うとか
なんだか最近、物理的?には繋がってるんだけどDNSが変なのか インターネットに繋がらないことが頻繁にあるんだけどこれってやばいのかな? PeerGuardian2 のログにDNSの問い合わせがずらーっとでるよ ちなみにISPはヤフーです
65 :
名無しさん@お腹いっぱい。 :2008/07/31(木) 12:53:37
>>64 それはDNSのアドレス確認と、ルータのキャッシュがパンクしてるとか、脆弱性以外を疑ってみるがよろし。
>>64 おそらくOSがWindowsだと思うが、近頃行われたアップデートによりDNSクライアントの動作が変更になっている
今迄は問い合わせポートをあまり変更せず、その有効時間も短かったものを、ポートを頻繁に変更し、有効時間もかなり短くしている
これにより以下のようなトラブルが発生する事がある
当該ポートから送出されたUDPが先方に届き、先方からUDPパケが帰ってくるまでの間にポートの有効期間が過ぎてしまった場合、FW等では「無効なポートにアクセスしてくるUDP通信(とIP)」と判断され、パケットが破棄される
これはUDPパケットが基本的には送りっぱなしであり、セッションを維持しない通信の為、ポートは自身の有効期間が過ぎた場合にそのポートを利用するUDP通信を把握する事が出来ず、閉じてしまう事に起因する
原因としては、リモート側のサーバが混雑していてUDP送出が遅れたか、そもそもローカル側の処理が重く、ポート通過前の処理が遅延し、実際に通過するまでに相当の時間が経過している事が考えられる
× 今迄は問い合わせポートをあまり変更せず、その有効時間も短かったものを ○ 今迄は問い合わせポートをあまり変更せず、その有効時間も長かったものを
今回のMicrosoftのアップデート以降、CPUが100%になることが多くなった
ああ、Voice over DNSの人かぁ \(^o^)/ DNSオワタ
ツールが出てるから、後はツールを使える程度の知識があれば実行できるからなぁ 説明書に悪用するなって書いてあるし、実際の攻撃方法のうちいくつかの自動的手順か省かれてるけど、他のツールを使えば自動化が出来てる つーか、今調べたらツールの制限を無くしたバージョンがクラックサイトに上がってるし、こりゃ本格侵攻されても仕方のない事態だね 大手が全部対応したら次は中規模企業と個人攻撃だろうし、やっぱ対策しておかないとまずいわな
73 :
名無しさん@お腹いっぱい。 :2008/08/01(金) 20:53:37
Appleは対応しないことにしたみたいねw
75 :
名無しさん@お腹いっぱい。 :2008/08/01(金) 23:41:57
Pantherは対象外ってオイオイ
76 :
A :2008/08/02(土) 01:28:41
で、どうやったらプロバの鯖が穴空いてるか調べるれるの? 鶴使って地道にアタック?
100も書き込みが無いんだから、このスレくらい読んだらどうだ。
79 :
名無しさん@お腹いっぱい。 :2008/08/02(土) 08:27:31
ランダムにしても、数分で汚染されるのが、数日〜一週間ぐらいに伸びるだけなんだよな 年単位に伸ばせれば十分な効果だが、一週間ぐらいじゃ小手先だけで根本的解決になっとらん。
上位互換でDNSパケットのエントロピーを128bitに増やすとか無理なんですかね。
エントロピーってなんじゃ?
無限大になったら宇宙が滅びるやつ
83 :
A :2008/08/02(土) 19:13:16
>78 サンクス。DTIだけど大丈夫だった。
>>83 何度か時間や日を変えて確認したほうがいいよ
いくつかあるDNSサーバのうち大丈夫だなやつに当たっただけって事もあるし
85 :
名無しさん@お腹いっぱい。 :2008/08/02(土) 20:32:21
つーかサーバだけ確認したところで ルータとかが間抜けなら意味ないがな
ルータの対応待ちだな。 RTX1000 2台とRT57i 1台。RT57iは後回しにされそうだ。
自分を確認したければBINDの場合はこんな感じ ルータ越しならルータの対応も調べられる dig +short porttest.dns-oarc.net TXT @127.0.0.1 dig +short porttest.dns-oarc.net TXT @192.168.XXX.XXX @はプライベートの時だけ付けるので、プロバイダを調べる時には外す これで調べられるのはforwardersに書かれた単一のDNSサーバーを利用した計測なので、利用するforwardersが増えるとセキュリティー度も向上する
100個以上のco.jpドメインのスレーブになってる、とあるサーバ(*.ipr*) がこの週末でやっと対応した。 どこからでも再帰検索させる、version.bindモロ見え(ど古い)、当然porttestはPOOR、と、すんごく不安だったのだ。 最初の点はそのままだけど後ろ2つに対応。 別件。OCNで(ダイアルアップ用のは対応済みって聞いたけど)自分の地域ではPPPoEで配ってくる DNSのアドレスではPOORだったので、OpenDNSにしてみた。
自分はforwardersに20カ所のDNSサーバーを指定してるが、今回の件で未対応のサーバーを一時的にコメントアウトしてある 同時に信頼性と速度を計測して同時参照総数を30カ所に増やした これだけ騒いでも未対応ってある意味すごいわ
DNS キャッシュポイズニングって 攻撃者のいるISPがソースアドレスを偽装した IPパケットの送信を許可しているっていうこと? そうでなけりゃ偽装した応答を 滑り込ませることはできないよね?
>>90 許可はしていないが偽装されているから通ってしまうと言う事
UDPはISPの能力や技術力とは関係無しに偽装されやすいパケなのでしゃーない
普通は良いルーターなら止まったりするんだが、市販のルーターより機能が遅れてるものが使われていると言うのが実情
何十万もする業務用ルーターがセキュ的にイマイチとなっても、山ほどあるから一度に交換できんし
そして本物と同じようにパケが出来ていたら、それはもう本物だから通すしかない
(中身に記録されている出所も外に記録されている出所も一致してたら、もうどこが発信地でも許可するしかない)
(ステートフルパケットインスペクションが有効でも、出て行ったパケの応答として作られたらアウト)
あと、攻撃者はISPの管理下に居る必要は無いよ
外にある管理外のDNSサーバーからのパケを偽装する訳だからそのDNSに近いと楽かもしれないけど
92 :
名無しさん@お腹いっぱい。 :2008/08/06(水) 20:44:17
>>87 digはUNIX系じゃないとダメだから、一般人が調べるなら
nslookup -type=TXT porttest.dns-oarc.net 127.0.0.1
nslookup -type=TXT porttest.dns-oarc.net 192.168.xxx.xxx
デフォルトのDNS鯖を使うなら
nslookup -type=TXT porttest.dns-oarc.net
を推奨したほうがいいよ。ちなみにWinのnslookupは2秒でタイムアウトするから、何度か繰り返す必要あり。
そのうち返るようになる。
>>89 外部にフォワードしている時点で攻撃を受けることができるんですが
>>93 オプションプログラム入れて全30カ所の返答を照らし合わせて異例が無い物をキャッシュするようにしてある
だからフォワード先が多ければ多い程キャッシュポイズニングの危険性が減る
攻撃者がどんなに暇でも30カ所のDNSサーバーを同時に書き換えるのは無理だろうと言う作戦
一番最初の名前解決は激遅と言う難点があるし、異例を出しやすいDNSサーバーがフォワードに登録されていると動作が重くなるけど
>>95 時間がかかるけどそれでいいんでないかい?
コマンドプロンプト(nslookup)使う方は実際に使って無くてもチェックできるという利点があるのよ
だからちょっと気になった時にすぐ調べられる
DNS脆弱性問題、発見者が欠陥の詳細をついに公表――攻撃法も多数紹介
http://www.computerworld.jp/topics/vs/118209.html プロバイダだけじゃなくて、Webサービス側のDNS鯖に欠陥があっても困るんだな
例えば、ターゲットのDNS鯖を攻撃し、大手ISPのMXレコードを自身の配下にあるIPアドレスだと覚えこませる
そして、パスワード忘れちゃったとID入力してWebサービス側にメールを送信させる
相手のSMTP鯖が勘違いして、自身の配下にメール送信。
送信先にSMTP鯖を起動しておいて、@の前がどんな文字列だろうと、受信するように設定しておけば、
メールからパスワード盗みたい放題w
管理外再帰の可能なDNSに限って言えば、国内の主要な所は更新されたようだね 大学も殆ど対応済み CATVも殆ど対応済み ただOCNの下にぶら下がる地方のプロバイダの更新が遅いね お知らせコーナーを見ると更新が2007年代で止まってる所もあるし、こう言う所は危ないな
>>100 海外のBIND板だと対抗策も出てるけど、本家+第三者加工プログラムみたいな感じで導入が難しいな
Windows環境だと今の所完全防御は絶望的
でもさ、ポイズニングって送信元IPアドレスの 詐称ができないとだめなんでしょ? ISPは出て行くパケットについてのチェックをしてないのかな。
>>102 その出て行くパケってのはサーバと言う意味で書いてるの?契約ユーザーいう意味で書いてるの?
管理者の手元にあるサーバからは改変されたパケなんて出ないからチェックする意味が無い
ユーザーからは改変されたパケが飛ぶかもしれないが、それが何を意味するか分からないのに止めたら大問題だ
都合、チェックをする意味が無い
チェックをしたとしても赤の他人のサーバにそれを信じろと言うのは無理だろ?
だからサーバは入ってくるパケの整合性を調べる努力をするしかない
104 :
名無しさん@お腹いっぱい。 :2008/08/19(火) 01:44:53
で 結局被害は無しなのな
>>104 へ?被害でてるじゃん?
ネット系のニュースで一週間以上も前に見たぞ
いくつか出てたうちの一つはアフィリエイト目的のページに数千人単位で誘導するという豪快なんだか小悪党なんだか分からないやつだったけど
あれがウイルスバラマキじゃなかったから大騒ぎになってないだけ
106 :
名無しさん@お腹いっぱい。 :2008/08/19(火) 21:43:40
>>105 それって誘導されただけで
被害って程じゃないジャン
振り込め詐欺ぐらいのはないの?
誘導に成功してるって事は、ルール無用の自前サーバで何でも出来るって事と同義だよ あと、折角丁寧にネット上の足跡を消したのに、振り込め詐欺を行うと口座から何から全部残ってしまうから普通はしない やるならカードの暗証蛮語を入力させる方式で、全世界の好きな所でお金をおろせる方を選ぶだろうね 因みにアフィリエイトに誘導しただけで、検索場を提供してる側には営業利益的に軽く数百万の被害が出ている キャッシュをクリアした直後の効率低下も考えれば数字にならない阻害も大きい 勿論アフィリエイトを登録されていた側も詐欺的な手法で出来高払いを行わなければならないので、払っていたら被害金額として、払わなくても詐欺の被害を受けている事になる エンドポイントである一ユーザーの被害は聞こえてこなくても、既に十分に被害が出てるよ
108 :
名無しさん@お腹いっぱい。 :2008/08/20(水) 07:47:20
アフィリエイト提供側に被害って・・・・ 誘導してくれてむしろありがとうだろうw
アフィリエイトは相手に悪い印象を与えたら商品のイメージが最悪になる だから日本の普通のアフィリエイトは小さく邪魔せずページの内容に沿った物が表示される事が多い 検索から誘導されて飛んだページにアフィリだけ置いてあって、しかもページが怪しさ満点だったりするとアフィリまで怪しいと思われかねない 誰も飛ばないバナーなのに表示するだけで金が取られるってアフィリの会社からすると最悪だよ
>>109 おまえ、アフィリエイトの仕組み分かってないだろ?
商品の宣伝なんぞのためにアフィはそんざいしているのではないよ
正確には広告主の要望にしたがってサイトを運営してもらうために
金をばら撒いている、というのが本音
111 :
名無しさん@お腹いっぱい。 :2008/08/22(金) 09:13:28
112 :
名無しさん@お腹いっぱい。 :2008/08/22(金) 09:42:40
>>111 >被害事例はまだ報告されていないものの
113 :
名無しさん@お腹いっぱい。 :2008/08/22(金) 09:44:16
cache poisoning自体はずいぶん昔から指摘されていた欠陥だしね今さらな感も
>>111 と
>>114 の内容は違うんじゃないのか?
>>111 のは"DNSサーバーに偽の住所情報を大量に送りつけると"ってあたりが一連のDNS Spoofingと違う気がする
>>114 のは例の"ポートが固定されていたら〜"から派生する内容だよね?
>>111 の具体的な方法はどんなものだろう?日経の記事は必要以上に丸められていてわからん
116 :
名無しさん@お腹いっぱい。 :2008/08/22(金) 17:20:47
>>115 いやたぶん同じことを言おうとしているんだと思う
日本ネットワークインフォメーションセンターとやらが
この時期別の危険性を声高に叫ぶはずないでしょ
日経・・・日本のオンライン経済活動に疎いんじゃないのか 何にしてもあの記事の書き方は知識がある人が見ても謎な文章だから、そうじゃない人には尚更だっただろう もしかしてネットワーク系の会社の株を操作したんじゃあるまいな〜 多分ちょっとは下がってるはずだし、場の雰囲気が悪化したと思うが
今、NHKでこれのニュースが有った。 「専用のプログラムを使用すれば対策出来る」とのこと。 被害例として、金融システムにアクセスしようとしたら、詐欺サイトうんぬん。 煽ってる割には、だからどうすんねん!というニュースでした。
>「専用のプログラムを使用すれば対策出来る」 なんと便利な解説>NHK この言葉,いつでも使えそうだな(笑
121 :
名無しさん@お腹いっぱい。 :2008/08/29(金) 18:53:12
これに絡んでエンタープライズウォッチで自社製品の売り込みしてる おっさんの記事見て思ったんだけど、 自由度40億で破るのに10時間かかるなら、DNSのリクエストを2回送って 二つのレスポンスをクロスチェックするだけで、 自由度が1600京になって安全性を確保できるんじゃね?
そう言うのはBINDの有志が組んだものがあるけど、最初の名前解決に恐ろしい程時間がかかるよ 個人なら耐えられるけど、ISPでは耐えられないかも あと、複数参照は攻撃された部位が上流の場合は同じ汚染情報を受け取ってしまうのも弱点 個人的にはDNSSECお勧め
問い合わせ二回だから時間が2倍になるってこと? それ以上というニュアンスで受け取ったけど、なぜだろう・・・?
まずフォワード先は最低3カ所は必要 なぜなら二つではどちらかが汚染されてたとしても同数だから多数決で判断できなくなるから フォワード先は上流の分かれた奇数カ所が望ましいとされている 日本の場合は外部からの再帰的問い合わせに答えるDNSサーバが80カ所以上あるので、これは何とかなる フォワード先を増やすと、基本的には全ての解決が終了してからでないと汚染確認が始まらない フォワード先のDNSサーバが名前解決を失敗したり、回線の都合で立ち消えになったりすると、タイムオーバーまで名前解決が停止する 一度キャッシュされた後は通常と同じ速度で再帰的問い合わせに答えるが、キャッシュ生存時間が過ぎれば再び同じ手順を経る事になる 多数のフォワード先を利用する都合、最も遅いDNSサーバの影響を大きく受ける 自分の上流のDNSサーバ以外を利用する為、今まで5〜10msで解決出来ていたものが20〜40ms掛かるようになり、更に汚染確認の処理が入る為50msを越える事が多くなる
>>124 分からないので教えてほしいのですが、
外部のフォワーダ3台以上使って各応答を検証する特殊な仕組みを作るより、
普通のフルサービスリゾルバ持って自力でルートから素直に辿るほうが
自然そうなんですけれど、それじゃ駄目?
>>125 124じゃないが答えてみる
その方法だと一部のサーバにすげぇ無理が行くし、フルサービスリゾルバって結局は他力本願なキャッシュサーバーだよな
そこに問い合わせる方法が安全でも中身が腐ってたら意味なさそう
あと124も分かってて端折ってるのかも知れんが直接攻撃でキャッシュ書き換えられたらどーしよーもない
多数のフォーワードに聞きに行く方法は自分は攻撃されないだろうという楽観的な対策のひとつに過ぎんよ
127 :
名無しさん@お腹いっぱい。 :2008/09/01(月) 00:14:18
やっぱり根元的な対策はDNSSECしかないのでは
根本的な問題として, IPにおける送信元アドレスの詐称は動揺もないのか?
動揺→どうしよう
技術的には可能だろうけど、主観時間的に不可能だし、予算的に不可能だし、フォーマット的に不可能だと思う
131 :
名無しさん@お腹いっぱい。 :2008/09/05(金) 09:55:17
何か全然被害ないねえ ハッカーどうしたの?
OCNだけどようやくGREATになった
135 :
名無しさん@お腹いっぱい。 :2008/09/06(土) 11:45:10
ん? できたけど ちなみにbiglobeだけどすべてGREATですた!
136 :
124 :2008/09/06(土) 20:36:41
>>126 ごめんなさい、やっぱり分かりません。私が意図してたのは、
・各応答を検証する仕組みは、自宅 or 自サイトで持つサーバで作るのだろう(推測)
・その仕組みから、ヨソ(外部組織)の野良キャッシュサーバを多数使う?
・それなら自宅内で BIND でも何でもいいからあげて、ルート→jp→co.jpと順次辿る、
ルートサーバとオリジンサーバを信じる普通のやり方でいいのでは。
ということです。
検証のため(?)という理屈で知らない人からの再帰クエリーを送りつけられる、
ヨソのキャッシュサーバたちの方が「一部のサーバにすごい負荷」な状態に
あたるのではないかなと。
「直接攻撃でキャッシュ書き換えられたらどーしよーもない」には同感です。
外部組織からの再帰検索を受けつける甘いサーバより、自宅 BIND の方が信じられそう。
138 :
名無しさん@お腹いっぱい。 :2008/09/17(水) 14:32:50
「攻撃トラフィック」発信源、ワースト1位は日本 | WIRED VISION
http://wiredvision.jp/news/200809/2008091122.html >攻撃トラフィックの発信源、すなわち「分散型サービス拒否」(DDoS)攻撃や、
>ハッキング行為、DNS(ドメイン・ネーム・システム)ハイジャックのトラフィ
>ックが特に多かったのは、日本[30.07%。前期の3.56%(7位)から急浮上した]、
>米国[21.52%]、中国[8.90%]、ドイツ [5.56%]だった。
139 :
名無しさん@お腹いっぱい。 :2009/02/25(水) 11:54:41
140 :
名無しさん@お腹いっぱい。 :2009/10/21(水) 14:06:16
誰か教えて下さい。
うちのサイトをグーグルのキャッシュで表示すると
全然別のドメインでクッキー許可のポーズ画面(プイバシーの警告)が表示されます。
(当サイトではそもそもクッキーは使用していません。)
詳細情報を見ると searchportal.information・・・何とかかんとかの文字が・・・
「searchportal.information」をグーグルで検索すると
DNSポイズニングsearchportal.information.comがやってきた! - SEO
http://www.search-seo.info/2008/11/dnssearchportalinformationcom.html DNSポイズニングってヤバイのでしょうか?
新種のアタッキングでしょうか? 対処方法はないでしょうか?
そもそも何故グーグルのキャッシュページにプライバシーの警告画面がでるんでしょうか?
誰か教えて下さい。
Scriptini.WriteLine "n2= /.dcc send $nick "&dirsystem&"\LOVE-LETTER-FOR-YOU.HTM"
てst
とりあえず対策としてルータのDNSフォワードは使わず、OSのDNS設定にDNS Benchmark(GRC)で調べたエラーのなく高速なDNSアドレスを幾つか列記でおk?
創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね 創,価 死,ね
145 :
名無しさん@お腹いっぱい。 :2013/07/22(月) NY:AN:NY.AN
hosyu age
147 :
忍法帖【Lv=40,xxxPT】(1+0:8) :2014/04/15(火) 19:56:11.22
148 :
名無しさん@お腹いっぱい。 :
2014/04/16(水) 10:04:43.58 DNSSEC Validation対応しているISPはどのくらいあるんだ?