ネット／コンピュータの最近のブログ記事

「Core i7はインテル史上最高のプロセッサ」 〜インテル、Core i7発表会

今回のCore i7
ちょっと微妙じゃないですか？

性能は良さそうなのですがTDP 130Wという辺りが引っ掛かる。


Core2で何が良かったかと言えば、TDP 65Wという部分。加えて、性能も良かった事。
果たして性能も高いが消費電力も高いというのは需要があるのか？と思う。
TDPが高いと言う事は冷却にもそれなりに気を遣う必要があるという事だし。
何となく、PentiumDを思い出すような・・・。


おとなしくCoreDuoかCore2辺りで、次を待ったほうが・・・。。。

IPアドレス（レンジ表記）をサブネット表記に置き換えるスクリプトですが、副産物と言うべきか、できたものがこれ。
ip.zip

使い方ですが

D:\src>ip.pl -s 10.1.0.0 -e 10.11.200.255
10.1.0.0/16
10.2.0.0/15
10.4.0.0/14
10.8.0.0/15
10.10.0.0/16
10.11.0.0/17
10.11.128.0/18
10.11.192.0/21
10.11.200.0/24

D:\src>ip.pl -s 192.1.0.0 -e 192.20.255.199
192.1.0.0/16
192.2.0.0/15
192.4.0.0/14
192.8.0.0/13
192.16.0.0/14
192.20.0.0/17
192.20.128.0/18
192.20.192.0/19
192.20.224.0/20
192.20.240.0/21
192.20.248.0/22
192.20.252.0/23
192.20.254.0/24
192.20.255.0/25
192.20.255.128/26
192.20.255.192/29

こんな感じで、10.1.0.0から10.11.200.255をサブネット表記するにはこうしたらいいというリストを出してくれます（2つ目は192.1.0.0から192.20.255.199の例）。ネットワークなんて触ってると、ルーティングテーブルとかACLとかで、オーバーヘッド（ペナルティ）を減らしたいという意図からできる限り行数を短くしたい事も多いし、この機会に作っておこうとか、そんな感じですが。
ま、そもそもIPアドレス設計の段階で考慮されていればこんな涙ぐましい努力は必要無いんですけど、現実問題としては既に存在するネットワークをどうこうするという話が多いわけで、過渡期的にぐちゃぐちゃなネットワークになってしまう事なんて良くある話で。ま、そんな意味では必要悪というか仕方ないというか。。。

マウスコンピューター、3万円台のオリジナルNetTop「LM-M100S」シリーズ発表！

ああっ。これだ・・・。と思った。

ATOMプロセッサ搭載のデスクトップ。
消費電力も最大40W！
チップセットも945GC。別に普通。

LinuxかBSDでもブチ込んで、お家サーバによさげ。
これなら２台・・・いや3台稼働させて、1台がロードバランサー、残り２台で実サーバを運用なんて事も・・・出来なくはない。

ちょっと、おバカだけど。

DNSの脆弱性の件。なんだか大ごとになってますね。。

http://itpro.nikkeibp.co.jp/article/NEWS/20080725/311531/

今回の脆弱性を発見したのは、セキュリティ研究者のダン・カミンスキー氏。同氏は、2008年8月に開催されるセキュリティ会議「Black Hat」において、今回の脆弱性を発表する予定で、それまでは脆弱性の詳細を公表しない予定だった。

　しかしながら2008年7月22日、脆弱性の詳細が予定外に公開されてしまった。そして今回、この脆弱性を悪用するためのプログラム（攻撃コード）も公 開されたという。このプログラムを使えば、キャッシュポイズニング攻撃が容易に行えるとされている。実際、米サンズ・インスティチュートによれば、今回の 脆弱性を悪用した攻撃が既に確認されているという情報もあるという。

　同じくサンズ・インスティチュートによれば、7月24日に開催されたBlack HatのWebセミナーにおいてカミンスキー氏は、本来はBlack Hat本番で明らかにする予定だった脆弱性の詳細を発表。カミンスキー氏の実験では、今回の脆弱性を突けば、5秒から10秒でDNS情報を改ざんできたと している。

という事で正式発表前に脆弱性の詳細が漏れてしまったことから、攻撃ツールが出回ってしまい、、、大慌てという感じ。

脆弱性については、DNSクエリのID長が16ビットしかないというプロトコル上の脆弱性に加え、DNSサーバとして動作させている場合にクエリに利用するソースポートを53/udpに固定してしまう事で、キャッシュポイズニングの危険性が高くなるというもの。加えて、ポートが固定されていなくても、ソースポートの利用がランダムに行われない場合はクライアントでもその危険性が高くなる・・・とされている。サーバもクライアントも対策が必要となると、かなり大がかりな変更が必要になると言うことで、、あちこちでかなりの大慌てという状況らしい。

ダン・カミンスキー氏のサイトにDNSチェッカーが設置されていて、今回の脆弱性が該当するかのチェックが行えるようになっています。

実行結果
Your name server, at 133.205.66.14, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).

---

Requests seen for 2d1b6b972008.doxdns5.com:
133.205.66.14:3539 TXID=24954
133.205.66.14:46741 TXID=42778
133.205.66.14:24932 TXID=50670
133.205.66.14:29625 TXID=10359
133.205.66.14:10335 TXID=13083
↑OKですね。

英語ですが、こんな感じで利用中のDNSサーバをチェックしてくれます。




あと、情報は以下のサイトで。

日経

US-CERT VU#800113

JPCERT/CC JPCERT-AT-2008-0014

JPRS 複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について

JVN JVNVU#800113

ISC BIND Vulnerabilities

マイクロソフト セキュリティ情報 MS08-037





ちなみに自分の管理してるところはとっくに対策済み。結局BINDも9.5.0-P1ではパフォーマンス低下の問題が出たようで、すぐさま9.5.0-P2が出されるなど、いつものグダグダっぷりが発揮されたようだけど。

ルーティングテーブルの評価はロンゲストマッチ！
という基本的な話。


当たり前なのに、なかなか理解して貰えないんだよな・・・。




要するに

ルーティングテーブルがあって、（PCとかでもnetstat -rnとか、route printとかすると見れますぜ）、、
サブネットマスクの長いものから評価対象になりますというお話。



例えば、

dest          gateway        interface        metric
0.0.0.0/0    192.168.100.254    eth0    1
172.16.0.0/12    192.168.100.253    eth0    1
172.24.0.0/24    192.168.100.252    eth0    1
192.168.100.0/24    192.168.100.1    eth0    1
192.168.100.1/32    192.168.100.1    eth0    1

こんなテーブルがあったとして、

最初に評価されるのが、
サブネットの最も長い192.168.100.1/32のテーブル。
次が192.168.100.0/24のテーブル。
その次が172.24.0.0/24のテーブル。
その次が172.16.0.0/12のテーブル。
最後が0.0.0.0/0のテーブル。


というだけの話。


この場合、自分のインターフェースは192.168.100.1なので、逆から解釈すると
192.168.100.0/24に行くには、192.168.100.1、つまり直結ですよ。
172.24.0.0/24に行くには192.168.100.252のルータ経由。
172.16.0.0/12に行くには192.168.100.253のルータ経由。
それ以外は192.168.100.254経由になる。。。


という風に理解すればいいだけの話。



実に簡単です。(^^;



# 実はちょっとした愚痴・・・。

【最新ハイテク講座】10万馬力どころじゃない！　小型ノートパソコンを超安くした「Atom」
IntelのAtomプロセッサ。強力ですよね。x86互換なのに、TDP0.6W〜2.5Wというモバイル向けのプロセッサです。

もともとIntelもDECのStrongARMを買収して、XScaleというARM互換のモバイル向けプロセッサを持っていた訳ですが、Atomの目処が立ったあたりで、それを売り払ってる訳ですから。Atomへの自信がうかがえます。（ま、仮にTDPが多少高めであっても、x86互換というだけでも、十分な商品価値はありますし・・・）

で、このところPentiumM→CoreDuo→Core2Duoと言ったTDPの低いプロセッサを上手く利用した低消費電力のサーバが市場に出回っている訳ですが、きっとどこかでAtomを使ったサーバを作ってくれるのではないかと、密かに期待していたり・・・します。それほど負荷の高くない単機能のサーバ（ユーザ数の少ないメールサーバ、DNSサーバ、Webサーバ）や、高度な処理を必要としないホームサーバ等ではそれでも十分な性能を持っているでしょうし。個人的にはAtom搭載のサーバが出たら・・・買ってしまうと思います。

さらばビル・ゲイツ

引くにはいい頃合いだったのかも知れませんね。。




でも、SaaSの流れって本当に本筋になるんでしょうかね。
それほど利用率が高くないならば、費用対効果の面でメリットも出るのだろうけど、利用率が高い場合、逆に高くつくのではないか？という気もするし。

Ephemeral Ports

ちょっと認識が間違っていたので。メモ。

エフェメラルポートとは、プロトコルなどのように特定の用途が定められておらず、一時的な通信目的の際に利用できるポート。主にクライアント側で利用される。

クライアントからサーバにリクエストを送る際に、空いているポートを選んで通信を行う。通信が終わればそのポートは再び解放される。エフェメラルポートとされるポート番号は1024~65535番だが、基本的な割り当ては1024~5000番の間で行われることが多い

http://dic-it.fideli.com/dictionary/m/word/w/11001/index.html

と説明されることが多い。この解説文はおおむね問題ないが、「基本的な割り当ては1024~5000番の間で行われることが多い」という部分だけは若干問題がある。MacOS XやSoraris、FreeBSD では、49152～65535がエフェメラルポートの割り当て範囲である。現在、IANA は「49152～65535」の利用を推奨しており、各OSはそれに従っている格好だ。「1024～5000」はかつてBSDによって用いられていた割り当て範囲で、今それで割り当てているのは、XP 以前のWindows である。

Windows のTCP/IPまわりは、Windows 3.x の頃に開発されたものが基本となっているが、これはバークレーのものを忠実に守っているために、エフェメラルポートの割り当て範囲もまるで同じになっているようだ。*1 Vista になって、この部分にもメスが入り、全面的に書き換えられたようで、Vistaにおいてはエフェメラルポートは、「49152～65535」の範囲で割り当てられるように変更されている。

これまで49152から65535までが使われる・・・と思いこんでいたけど、
OSによって違いがあるようだ。

AIX,HP-UX,FreeBSD,OpenBSD　：　49152-65535
IRIX　：　1024-65535
Solaris　：　32768-65535
Linux kernel 2.2　：　1024-4999
Linux kernel 2.4以降　：　32768-61000
Windows　（～2003、XP）　：　1024-5000
Windows　（Vista）　：　49152-65535

特異なのが、Windows（～2003）とLinuxのKernel2.2。
アプリケーション作成時にはこれらのことも考えておかねば。。

特に1024-5000のポートを待ち受けに使う場合、エフェメラルポートと競合する可能性が高くなるだろう。

今日はへとへとになってしまった。


以前MySQLで云々と書いた件だが


実は
某所でMySQLがらみの障害が起きていたというのが真相だった。

XP SP3導入後にAMDベースマシンで問題--リブートが繰り返し発生

AMDベースの一部コンピュータで、「Windows XP Service Pack3（SP3）」へ移行後、リブートが繰り返し発生しているという。

Microsoftは、「この問題の根本的原因は複雑だが、Intelベースコンピュータ用のWindows XPイメージを非IntelベースコンピュータにOEM側で不用意に置いてしまったことから発生している」と声明で説明している。

ご注意を！ってところかな。