DNSプロトコルの脆弱性情報　漏洩する

1 ：2008/07/23 〜 最終レス ：2013/07/22

（前略）
今回の脆弱性については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終了

2 ：

記事を省くな

3 ：

(略した部分を貼っておきますね)
　このうち、Microsoftは7月の月例パッチで問題を修正。ISC、Cisco、Debian、Red Hatなどもパッチやアドバイザリーを公開した。
　今回の詳細情報流出により、企業やISPが緊急に脆弱性の修正パッチを適用する必要性が一層高まったとSANSは指摘している。

4 ：

たったそれだけw

5 ：

http://qb5.2ch.net/test/read.cgi/operate/1212665493/895-ｎ

6 ：

攻撃実証コードリリース
http://japan.zdnet.com/sp/feature/07zeroday/story/0,3800083088,20377716,00.htm

7 ：

セキュ板なのにこのレス
いかに糞板なのか物語ってる

8 ：

1)まずはDNS サーバからのクエリーのソースポートが
ランダムになっているか確かめましょう。
Web-based DNS Randomness Test | DNS-OARC
https://www.dns-oarc.net/oarc/services/dnsentropy
上記サイトで確かめます。
「POOR」の表示がひとつでもあったらアウト。
みんな「GREAT」なら大丈夫。

2)DNSサーバーを変えましょう。
もたもたしているといつ攻撃を食らうかわかったもんじゃないので、
とりあえず（比較的）安全なDNSに変えちゃいましょう。
おすすめは「OpenDNS」
安全で高速なDNSを提供する「OpenDNS」 - GIGAZINE
http://gigazine.net/index.php?/news/comments/20060720_opendns/
上記サイトを参考にDNSを変更しましょう。

こんな感じでいいのかな？
間違ってたら教えてちょ

9 ：

3)インターネットの利用を中止する
もたもたしているといつ攻撃を食らうかわかったもんじゃないので
回線を引っこ抜いてそれを天井から吊り下げ首を引っ掛けちゃいましょう。

10 ：

DNSシステム脆弱性問題、発見者がついに詳細情報を公開へ
http://namidame.2ch.net/test/read.cgi/news/1217084945/
DNSシステム脆弱性問題、発見者がついに詳細情報を公開へ
2008/07/26"
http://journal.mycom.co.jp/news/2008/07/26/013/index.html

11 ：

手違いどころじゃないよ。脆弱性情報を学会の発表か何かと勘違いしているのな。
特にDNSなど、いかに素早く対応するか真価を問われているというのに、カンファレンスで
「発表」する予定だったと。
> この脆弱性情報は当初、IOActiveのダン・カミンスキー氏によって8月のBlackhat
> カンファレンスで発表される予定だったが、同氏の情報公開の遅さに業を煮やした人物が
> この脆弱性にかんする自らの見解を示しており、その情報を基に攻撃コードが作成されて
> いるとみられる。
> Julien Desfossezと名乗る人物がPythonで動作する攻撃コードを公開しており、
> 「動作は遅いがしっかり機能する」とコメントしている。

12 ：

つーか脆弱性自体はずいぶん前に発見して、
半年たってようやく各社パッチの準備ができたので一斉に更新して、
テストや適用の期間を見越して詳細の公表を１ヶ月遅らようとしただけ
一部で実証コードが公開されたことで、
発見者があわてて詳細を大本営発表したのが手違いというか間違いってこと
第三者による独自解析と、発見者直々の詳細レポートでは影響力が全然違うからな

13 ：

"大本営発表"とか、意味もわからずに言葉を使うなよ
以前からわかっていたものを、今年になってから騒ぎが大きくなったということ
問題はボンクラ管理者は腐るほどいるため、その警告と対策が末端まで行き渡らないってこと
水面下で対策を進めることはいいが、無駄に時間をかけることはこれを知っている悪意ある
人間の跳梁を許してしまい、逆にネット上で大問題になることが最大の周知と防御になる

14 ：

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]

15 ：

ｲﾝﾀｰﾈｯﾄ終了のお知らせ。DNSの脆弱性の実証コードがリリースされる。僅か数分で汚染可能
http://namidame.2ch.net/test/read.cgi/news/1216952955/

16 ：

これってDNSClientサービスをオフにしててもダメなん？

17 ：

2ch.netなら、2ch.netのネームサーバがこの脆弱性にやられたら、
第三者の管理下にあるサーバを２ちゃんねる掲示板のように見せかけて運用することも可能…
と言ったようなお話。
サーバ運用者は可及的速やかに対応を…という件であって、一般ユーザはまあ。

18 ：

つーかDNSのクライアントを限定すればいいやン

19 ：

cache poisoningってそんな大問題？
大きなサーバならあれだけど
小さなサーバならキャッシュしなければいいだけジャン

20 ：

セキュ板のレベル低下に絶望した

21 ：

どう低下したか言ってくれなきゃダメよ

22 ：

20じゃないけど低下を感じる部分を近くの書き込みで見ると
>これってDNSClientサービスをオフにしててもダメなん？
うん駄目
一つはプロバイダのDNSサーバが汚染されてたらクライアント止めても無駄と言う事実
もう一つはDNSクライアントを止めると確かにキャッシュはしなくなるが、肝心の名前解決の問い合わせを毎回外部に求めるようになる事が逆に危なくなると言う事
外部からの名前解決に答えない個人のPCの場合、キャッシュの生存時間が攻撃者には分からない為、攻撃するタイミングが分からない
でも毎回聞きに出ていたら、それに折り返した攻撃がし易くなる
つまりキャッシュをしない方が攻撃側には都合が良い事もある
>つーかDNSのクライアントを限定すればいいやン
問題はクライアントに依存しないし、クライアントが万全でもルータがタコだと攻撃可能になっている
なので、クライアントの種類に関わらず対策が必要になる
特にソフト的に何とかなる物よりも、ルータ等のハードの対応に手間取ると言われている
>小さなサーバならキャッシュしなければいいだけジャン
上で書いた通りキャッシュを無くすと攻撃にさらされるタイミングが増えてしまうし、小規模でもDNSサーバを公開している場合はキャッシュが存在しない事が相手にモロにばれる
攻撃者にしてみれば入れ食い状態なので、すごく楽
正解は、汚染されてない外部DNSサーバーから引いたキャッシュをしっかり保持し、その外部DNSサーバへの問い合わせポートを完全にランダムにして予想させない事
これだけで汚染される可能性は殆ど無くなる

大騒ぎする割にはやらなきゃならない事は二つしかない
対策済みと公表されるまでは汚染される可能性のあるDNSサーバで名前解決をしない
外部に名前解決を問い合わせるポートを固定にしない

23 ：

サーバに手を入れられるなら
問い合わせのFQDNをランダムに大文字化することで
10〜20ビットほど稼げるらしいけど
ポートランダム化で稼げるのもせいぜい16ビットだし

24 ：

まぁサーバを動かしてる個人の場合は既に大部分がポートのランダム化は終了してるはず
Windows系にしてもアップデートでランダム化は導入されたので、一番素人な層も最低限フォローされたはず
でも資金を投入しないと改善できないルータの部分が厳しい
ヤマハは即座に対応したけど、業務用途じゃない一般のブロードバンドルーターは一部のメーカーを除いてほったらかしと言うのが現状だからね
内部でどんなにランダム化されてても、ルータが全部同じポートに固定してたら全く意味が無くなる
それでも個人のルータなんて私怨でもなきゃ誰も攻撃しないからまだ安心
狙われたら危ないけど、そもそも狙われないだろうし
やっぱ怖いのはプロバイダのDNSが腐る事かな

25 ：

ルータってプロバイダに取り次ぐだけでしょ？他から覗ける訳じゃないしプロバイダがちゃんとしてれば問題ないジャン

26 ：

ファーミング詐欺始まったな

27 ：

>>25
確かにルータは内部と外部をNATを通して取り次ぐだけだけど・・・
確認すれば分かる事だからはっきり書くけど、ルータは内向けのポートはどんなポートでも受け付けるけど、外向けの出口は綺麗に統一されて出て行く物が多いよ
今回の攻撃手法はPCやルータが外のDNSを見に行く時に攻撃する仕組みになっている
つまり、ルータの中が見えない事は攻撃側の難度を上げる事は出来るけど、外に聞きに行く時に嘘の情報を掴まされる事は防げない
ルータが正規のDNSサーバから名前解決を貰ったと思っていても、こっそり大嘘を掴まされてルータの内側のDNSクライアントのキャッシュが汚染される可能性がある
これをやられると外部のDNSサーバがどんなにセキュリティー万全でも防げない
防ぐ為にはルータから出て行く名前解決時のポートがランダムになっている必要がある
と言う訳で、ルータの中が覗けない事は攻撃者にとって攻撃に要する時間が長くなると言う効果しかない
同じポートさえ見張っていれば、いつかは目的のパケが出てくる可能性が高い訳だしね
狙われないだろうとは書いたけど、ちょっと竹島問題でも燃え上がれば日本人を絨毯爆撃する暇人が隣の大陸に大量に発生するかも知れない事を考えると、楽観は出来ない
「Googleにアクセスしたら新しいツールバーがダウンロード出来ると言うメッセージが表示され、OK押したら竹島の写真入りウイルスだった」
とか、すごくありそうじゃないか？
だからルータの出口がランダムかどうかは重要だよ

28 ：

>>24
ヤマハは対応したのかな？
ファームを見に行ったけど、順次リリースってどういうこと？
リリースノートを見てもそれらしい修正は入っていないような気がするけど。
設定変更は載ってるね。

29 ：

>>28
http://www.rtpro.yamaha.co.jp/RT/FAQ/Security/VU800113.html
これの事だね
非公開β版テスターの情報によると、目下急ピッチで最終調整中らしいです
多分すぐロールアウトするんじゃないかな

30 ：

forward onlyにしておけばいいのではないかな

31 ：

>>30
forward only は自分のキャッシュの中に答えが無い場合は、fowardersに指定された外部のDNSに名前解決しに行くという意味
forward first との違いは効率と速度の問題だけなので、キャッシュに無い場合に最終的に外部に聞きに行く事には変わりが無いよ
キャッシュを探す→見つからないなら外部に聞きに行く→それでも見つからないならもう一度自分で探す→NXDOMAIN
only との差は、最終的な答えだけをキャッシュするか、それまでに得られた答えも全部キャッシュするか
後は first に「それでも見つからなければ・・・」の処理がある分だけ最終的な解決が遅くなる事
only はキャッシュと fowarders に答えが無い場合はすぐに諦める
両方とも外部DNSサーバーに聞きに出るのは同じなので、対策はしなけりゃならない
このオプションを書くと言うことはBINDだと思うんだけど、最新版でポートのランダム化は対策されてますよ
なので、後は外部DNSサーバーの確認とルータの確認だけだと思う
(DNSサーバーがタコの場合はOpenDNSがあるし、実質ルータだけですな)

32 ：

>>31
>見つからないなら外部に聞きに行く
それここの説明と違うけど
tp://www.atmarkit.co.jp/flinux/rensai/bind915/bind915b.html

33 ：

あいや同じか間違えてました
forwardersに対してだけであっても
自分の外に聞きに行くのは同じだから
この問題については違いはないと・・・・

34 ：

あるNSに名前解決のUDPを飛ばす → そのNSが答えを返す
NSが答えを返す前に、嘘の答えを悪意者が返すってことですか？
その場合、悪意者のIPアドレスはNSのとは違うと思うのですが、返答してきた人のIPアドレスは
見ていないということですか？

35 ：

>>34
そこがよく分からないよね
たしか前にinternicが乗っ取られたとき
ipアドレス確認するようにしたんじゃなかったの？
tp://www.hotfix.jp/archives/word/2005/word05-18.html

36 ：

usen今だに対策してねー

37 ：

ISPは対応してもルータのファームはそのままだよな。
抱き合わせでモデムルータ使ってるんだから対応汁。

38 ：

>>34,35
UDPを使って一方方向の通信をするだけなので，
IPアドレスの詐称をすれば良いだけ。

39 ：

>>38
頭良いな

40 ：

>>36
実家のサーバのISPにお問い合わせしたら、1日で対応してくれた。
自宅アパートで使ってるISPはランダムだった。
会社の一番大手ISPは固定だったｗ

41 ：

forward onlyにしておいて対策万全なforwardersとの間の通信をトンネル化しておけば問題なし

42 ：

OPENDNS使えば安全？

43 ：

>>41
トンネル使うって事は相手もトンネルに対応してなきゃならんわな
普通のプロバイダはそう言うサービス提供してないからなぁ
ちょっと普通のユーザーには縁のない話になるな

44 ：

>>42
・プロバイダが攻撃されてDNSキャッシュが汚染される
・自分のPCが攻撃されてDNSキャッシュが汚染される
OpenDNSを使えば上の問題は解決するし、プロバイダが対策済みならOpenDNSを使うまでもない
でも下の問題は自分で何とかしなけりゃならない
OSのアップデート、DNSクライアントのアップデート、ルータのアップデートの三つが必要
前二つは探せば何とかなるが、ルータのメーカーが対策しないと無意味に近い

45 ：

＞・自分のPCが攻撃されてDNSキャッシュが汚染され
これって”インターネットプロトコル(TCP/IP)のプロパティ画面”で次のDNSサーバーのアドレスを使うに
見覚えのないDNSサーバーが追加されてるとかそういうケースか？
ttp://www.higaitaisaku.com/o17.html

46 ：

>>45
違うー

47 ：

で、なんで大騒ぎになってないのかな。
たいしたことではないってこと。

48 ：

>>46
じゃあルータとかそういうの？

49 ：

>>45
マルウェアに感染してそこいじられるってことはあるな

50 ：

まあ実害はないかもしれないしな（攻撃を受けなかったり受けても問題なく過ごせたり）
けれど対策はしておかないとマズイだろう

51 ：

>>48
PCがDNSに問い合わせた結果を一時保存しておくキャッシュがPC内のどこかにあるだろうがそれが汚染されるかもってこと

52 ：

外部のOpenResolverが対策済みか調べる方法ってどうすればいいの？
telnet出来るならdigで調べれるけど…。

53 ：

DNS Client サービスを止めてもちゃんと名前解決するんだね。
ルータをつかっているからかな？

54 ：

>>53
キャッシュがないから毎回読みに行ってるだけでしょ

55 ：

>>38
IPアドレスって詐称できるんだ

56 ：

詐称できるんだと思う人は詐称できません

57 ：

>>51
DNSの解決速度を上げる為、殆どのOSではキャッシュはメモリ上だけになってる
だからシャットダウンや再起動でキャッシュはゼロになって最初から溜め直しになる
>>53
名前解決が必要になる度に外に聞きに行ってるから
手元の情報を使えない分速度も落ちるし、CPUのパワーも使うし、相手のDNSサーバに負担もかける
何よりDNSサーバが混雑し始めると、回線速度に関係なくブラウザの表示が遅くなったりする
攻撃者にしてみれば、外に聞きに出てくる度に毎回攻撃していれば、いつかは目当てのアクセスが通り過ぎるので攻撃が成功しやすくなる
キャッシュが有効な場合はデフォルトで一週間はキャッシュが残っているので、攻撃者には一週間に一度しか攻撃するチャンスがない
毎日シャットダウンするPCの場合は実質最初の一回しか攻撃するタイミングが無いことになる
プロバイダのDNSが汚染されている場合はキャッシュが有っても無くても同じと言う事を考えると
攻撃されるタイミングが増える上にパフォーマンスも落ちるのでキャッシュ無しはお勧めできない
逆にデフォルトよりキャッシュの生存時間を延ばしておけば、それだけ攻撃されるタイミングを減らす事も可能になる
>>52
プロバイダにメールで問い合わせるのが確実
まだ対策されてないなら「はよ対策せんかいドボケがっ！」と言う追い込みにもなる

58 ：

　 　 　 　 ＿＿＿
　 　 　 ／　　 　 　＼
　　　／　　 　 　 　 　＼ 　　セキュ板らしい流れになってきたお
　 ／ 　　⌒　　　⌒　　 ＼
　 |　 /// （__人__） /// 　|　
. (⌒) 　　　 　　 　 　 　 (⌒)
./　i＼ 　 　 　 　 　　　／i　ヽ

59 ：

でもそれだけ汚染状態が長く続くかも知れないけどな

60 ：

学校のテストの問題でファーミング詐欺の説明しろって問題で
DNSを書き換えてURL偽装する
てな感じで書いたんだが間違ってるかね？
名前解決が〜とかいたほうがいいのか

61 ：

>>60
詐欺が行われる事を説明する為に、以下のような文言が含まれている必要があるかも
順不同
・知名度の高いサイトを偽装する
知名度が低いサイトのURLを偽装しても詐欺という結果に繋がり難い
詐欺を結論させる為には知名度を利用した思考操作が必要
・一括的な方法で不特定多数を欺瞞情報に曝す
単一目標を攻撃する方法であるフィッシング詐欺と区別する部分は、不特定多数を対象にしている部分
ファーミング詐欺という名称を用いる際に必須の説明
・「DNS」ではなく「DNSサーバー」と書く方が正しい
DNSはDomainNameSystemの略
ファーミング詐欺ではシステムの書き換えは必須とされない
・DNSサーバーに一時集積されたドメインとIPアドレスの対応表を書き換える
DNSサーバーの情報を書き換えている行為に言及しつつ
情報という曖昧な表現ではなく、実際に何を書き換えているのかの説明が欲しい
・当事者が行う各種サーバーへのアクセスを不正に誘導する
当事者視点での現象の説明を行う
手法的にはダウンロードファイルのすり替え等も可能であるが、詐欺という説明の主流のみを説明する
・偽装されたサイトを利用して個人情報の奪取を目論む
ウイルス等に感染させる攻撃行為と詐欺行為とを分別する部分
ウイルス等を利用した複合的な手法もあり得るが、目的が攻撃であるか詐欺であるかで名称が変化する

62 ：

そうだグーグルとかヤフーとか大手のところはTTLを無限大にしておけばイイヤ
それかゾーン転送してそれ使うとか

63 ：

>>61
さんくす。
勉強不足だったお・・・

64 ：

なんだか最近、物理的？には繋がってるんだけどDNSが変なのか
インターネットに繋がらないことが頻繁にあるんだけどこれってやばいのかな？
PeerGuardian2　のログにDNSの問い合わせがずらーっとでるよ
ちなみにISPはヤフーです

65 ：

悪用コード公開の影響：DNSの脆弱性問題でISPに被害 - ITmedia News
http://www.itmedia.co.jp/news/articles/0807/31/news021.html
>　DNSキャッシュポイズニングの脆弱性が見つかり悪用コードが出回っている
>問題で、実際にISPのサーバが攻撃され、トラフィックが偽サイトに誘導され
>る被害が発生した。

66 ：

>>64 それはDNSのアドレス確認と、ルータのキャッシュがパンクしてるとか、脆弱性以外を疑ってみるがよろし。

67 ：

>>64
おそらくOSがWindowsだと思うが、近頃行われたアップデートによりDNSクライアントの動作が変更になっている
今迄は問い合わせポートをあまり変更せず、その有効時間も短かったものを、ポートを頻繁に変更し、有効時間もかなり短くしている
これにより以下のようなトラブルが発生する事がある
当該ポートから送出されたUDPが先方に届き、先方からUDPパケが帰ってくるまでの間にポートの有効期間が過ぎてしまった場合、FW等では「無効なポートにアクセスしてくるUDP通信(とIP)」と判断され、パケットが破棄される
これはUDPパケットが基本的には送りっぱなしであり、セッションを維持しない通信の為、ポートは自身の有効期間が過ぎた場合にそのポートを利用するUDP通信を把握する事が出来ず、閉じてしまう事に起因する
原因としては、リモート側のサーバが混雑していてUDP送出が遅れたか、そもそもローカル側の処理が重く、ポート通過前の処理が遅延し、実際に通過するまでに相当の時間が経過している事が考えられる

68 ：

× 今迄は問い合わせポートをあまり変更せず、その有効時間も短かったものを
○ 今迄は問い合わせポートをあまり変更せず、その有効時間も長かったものを

69 ：

今回のMicrosoftのアップデート以降、CPUが100%になることが多くなった

70 ：

ああ、Voice over DNSの人かぁ
＼(＾o＾)／ DNSｵﾜﾀ

71 ：

AVG Anti-Virus Version 74
http://pc11.2ch.net/test/read.cgi/sec/1216429458/700
700 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2008/07/31(木) 23:08:14
これはマジやばいっす！
http://www.itmedia.co.jp/news/articles/0807/31/news021.html

被害でたーーーｗｗ

72 ：

ツールが出てるから、後はツールを使える程度の知識があれば実行できるからなぁ
説明書に悪用するなって書いてあるし、実際の攻撃方法のうちいくつかの自動的手順か省かれてるけど、他のツールを使えば自動化が出来てる
つーか、今調べたらツールの制限を無くしたバージョンがクラックサイトに上がってるし、こりゃ本格侵攻されても仕方のない事態だね
大手が全部対応したら次は中規模企業と個人攻撃だろうし、やっぱ対策しておかないとまずいわな

73 ：

Appleは対応しないことにしたみたいねｗ

74 ：

>>73
今日アップデート出てた気がするけど？

75 ：

Pantherは対象外ってオイオイ

76 ：

で、どうやったらプロバの鯖が穴空いてるか調べるれるの？
鶴使って地道にアタック？

77 ：

100も書き込みが無いんだから、このスレくらい読んだらどうだ。

78 ：

>>76
コマンドライン使えない人なら
ttps://www.dns-oarc.net/oarc/services/dnsentropy
→ Test My DNS
コマンド使えるなら
ttps://www.dns-oarc.net/oarc/services/porttest

79 ：

ランダムにしても、数分で汚染されるのが、数日〜一週間ぐらいに伸びるだけなんだよな
年単位に伸ばせれば十分な効果だが、一週間ぐらいじゃ小手先だけで根本的解決になっとらん。

80 ：

上位互換でDNSパケットのエントロピーを128bitに増やすとか無理なんですかね。

81 ：

エントロピーってなんじゃ？

82 ：

無限大になったら宇宙が滅びるやつ

83 ：

>78
サンクス。DTIだけど大丈夫だった。

84 ：

>>83
何度か時間や日を変えて確認したほうがいいよ
いくつかあるDNSサーバのうち大丈夫だなやつに当たっただけって事もあるし

85 ：

つーかサーバだけ確認したところで
ルータとかが間抜けなら意味ないがな

86 ：

ルータの対応待ちだな。
RTX1000 2台とRT57i 1台。RT57iは後回しにされそうだ。

87 ：

自分を確認したければ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が増えるとセキュリティー度も向上する

88 ：

100個以上のco.jpドメインのスレーブになってる、とあるサーバ(*.ipr*) がこの週末でやっと対応した。
どこからでも再帰検索させる、version.bindモロ見え(ど古い)、当然porttestはPOOR、と、すんごく不安だったのだ。
最初の点はそのままだけど後ろ2つに対応。
別件。OCNで(ダイアルアップ用のは対応済みって聞いたけど)自分の地域ではPPPoEで配ってくる
DNSのアドレスではPOORだったので、OpenDNSにしてみた。

89 ：

自分はforwardersに20カ所のDNSサーバーを指定してるが、今回の件で未対応のサーバーを一時的にコメントアウトしてある
同時に信頼性と速度を計測して同時参照総数を30カ所に増やした
これだけ騒いでも未対応ってある意味すごいわ

90 ：

DNS キャッシュポイズニングって
攻撃者のいるISPがソースアドレスを偽装した
IPパケットの送信を許可しているっていうこと？
そうでなけりゃ偽装した応答を
滑り込ませることはできないよね？

91 ：

>>90
許可はしていないが偽装されているから通ってしまうと言う事
UDPはISPの能力や技術力とは関係無しに偽装されやすいパケなのでしゃーない
普通は良いルーターなら止まったりするんだが、市販のルーターより機能が遅れてるものが使われていると言うのが実情
何十万もする業務用ルーターがセキュ的にイマイチとなっても、山ほどあるから一度に交換できんし
そして本物と同じようにパケが出来ていたら、それはもう本物だから通すしかない
(中身に記録されている出所も外に記録されている出所も一致してたら、もうどこが発信地でも許可するしかない)
(ステートフルパケットインスペクションが有効でも、出て行ったパケの応答として作られたらアウト)
あと、攻撃者はISPの管理下に居る必要は無いよ
外にある管理外のDNSサーバーからのパケを偽装する訳だからそのDNSに近いと楽かもしれないけど

92 ：

>>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秒でタイムアウトするから、何度か繰り返す必要あり。
そのうち返るようになる。

93 ：

>>89
外部にフォワードしている時点で攻撃を受けることができるんですが

94 ：

>>93
オプションプログラム入れて全30カ所の返答を照らし合わせて異例が無い物をキャッシュするようにしてある
だからフォワード先が多ければ多い程キャッシュポイズニングの危険性が減る
攻撃者がどんなに暇でも30カ所のDNSサーバーを同時に書き換えるのは無理だろうと言う作戦
一番最初の名前解決は激遅と言う難点があるし、異例を出しやすいDNSサーバーがフォワードに登録されていると動作が重くなるけど

95 ：

>>92
ネットワーク設定のDNSを手動で変えて，
http://entropy.dns-oarc.net/test/
じゃダメなの？

96 ：

>>95
時間がかかるけどそれでいいんでないかい？
コマンドプロンプト(nslookup)使う方は実際に使って無くてもチェックできるという利点があるのよ
だからちょっと気になった時にすぐ調べられる

97 ：

DNS脆弱性問題、発見者が欠陥の詳細をついに公表――攻撃法も多数紹介
http://www.computerworld.jp/topics/vs/118209.html
プロバイダだけじゃなくて、Webサービス側のDNS鯖に欠陥があっても困るんだな
例えば、ターゲットのDNS鯖を攻撃し、大手ISPのMXレコードを自身の配下にあるIPアドレスだと覚えこませる
そして、パスワード忘れちゃったとID入力してWebサービス側にメールを送信させる
相手のSMTP鯖が勘違いして、自身の配下にメール送信。
送信先にSMTP鯖を起動しておいて、@の前がどんな文字列だろうと、受信するように設定しておけば、
メールからパスワード盗みたい放題ｗ

98 ：

ttp://customer.sphere.ne.jp/cgi-bin/mantis/view.cgi#mente
遅杉

99 ：

管理外再帰の可能なDNSに限って言えば、国内の主要な所は更新されたようだね
大学も殆ど対応済み
CATVも殆ど対応済み
ただOCNの下にぶら下がる地方のプロバイダの更新が遅いね
お知らせコーナーを見ると更新が2007年代で止まってる所もあるし、こう言う所は危ないな

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

トロイで遊ぼう (504)
パスワード・シリアル・ＩＤ管理ソフトについて (383)
Windows Defender Part4 (522)
【DeepGuard】F-Secure総合 Part22【ﾏﾙﾁｴﾝｼﾞﾝ】 (931)
【Hackme】ハッキング力検定サイトHackme Lv3 (361)
冒険の書ってなんですか？ (437)
--log9.info------------------
　★外国語曲宗教曲ばかりやる奴って馬鹿ぁ？★ (311)
ハモネプ (722)
夢見るジャンプの合唱音源UPお願い (151)
声域スレ (342)
Sanctus('A`)したらOsanna(ﾟ∀ﾟ)するスレ (412)
第九を意地でも歌わない奴の数→ (563)
【一般で】職場部門は廃止すべき【充分】 (139)
今の合唱に対しての不満をぶちまけろ！ (355)
【音程低いぞ】セカンドテナー【何やってんの】 (340)
（変）へんなやつが集まるスレ（合唱板） (169)
【過去の栄光】ＯＢ・ＯＧが邪魔です【ウザイ】 (372)
バスのための低音について語るスレ (812)
●●●　秋元康がAKB48を合唱ﾏｰｹｯﾄに投入　●●● (187)
【Nコン】大岡山小・根城中・安積黎明高【名門】 (221)
J.S.Bach ／ バッハ合唱作品総合スレ (185)
母なる大地よｱｯｰ！ (179)
--log55.com------------------
(　´･ω･｀)メリーブリスマス 161夜目
機動戦士ガンダムオンライン ジオン part306
機動戦士ガンダムオンライン 連邦スレ Part270
■Ragnarok Online EP:RR Lv3882　さよなら2019年■
【らておば】Tree of Savior PvPスレ Part179【三十八歳未婚】
メイプルストーリー2 Part116
機動戦士ガンダムオンラインPart7134
機動戦士ガンダムオンラインPart7135