きまぐれキッチン石橋と関町のびっくりドンキー

お昼に、キッチン石橋に行ってきた(過去の記事)。
ここはポアル館食べログ)と並ぶ大食いの店……ではあるんだけど、ポアル館ほどインパクトはない。というか、ポアル館との違いは、ポアル館は何も言わなくても量が多いんだけど、キッチン石橋はこちらから能動的に行動しないと、量が多くならない。たけど、大食いの要素てんこ盛りのお店なのだ。

今日はチキンカツ定食を頼んだ。
このカツのデカさ。
ただ最初出てきたとき、揚げすぎなのではと思ったのだが、これはソースが沁みているからのようだ。
カツは箸で切れるくらい柔らかい。
ご飯が何杯でも食べられてしまう。

そして夜は会社の帰りにびっくりドンキーに寄った。
カレールーが本当に少なくなっているのか、もう一度確かめたかったからだ。
結果的に、今日食べたカリーバーグディッシュは特にカレールーが少ないと感じる事はなかった。たまたまだったのかなぁ?

最後の写真はくらまえ橋郵便局にある蔵前橋~浅草橋の史跡の看板。
Timepiece Ensemble を作る時にあらかた調べたはずだったんだけど、ボクのが知らないものもあったので写真に収めた。今度、昼休みとかに散歩がてら見てこよう。惜しむらくは、史跡の説明は残っているが、名前が消えてしまっていることだ(笑)。これでは検索できないじゃないか(爆)。

1412250896 1412250899 1412250890
1412250892 1412250892l 1412250892r

オープン リゾルバ事件

勤め先の会社は三つの開発室があるんだけど、それらのネットワークを管理している。で、そのうちの一つの開発室で利用しているプロバイダから、どうも大量の不正パケットが流れた形跡があると連絡をよこしてきた。
ログをみたら、一目超然、DNS amp 攻撃だった。

ぎゃーす! そういえば、DNS の設定ってどうなってたんだっけ?<ヲイ
って色々調べたら、amatsukami.jp サーバもオープン リゾルバになっていた……orz

皆さんがウェブサイトを閲覧するとき、そのサイトを運営しているサーバに正しくアクセスするためには DNS という仕組みが不可欠である。インターネット上のサーバはすべて一意の重複することのない番号(IP アドレス)が割り振られていて、この IP アドレスはグローバル IP アドレスと言って、インターネット内で重複しないように割り振られている。例えば今あなたが見ている TAMA Networks を提供しているサーバのグローバル IP アドレスは 210.136.205.247 であり、これは世界に一つしかない IP アドレスである。この番号を他の誰かが使うことはない。
でもこの 210.136.205.247 という数字を使ってデータをやりとるするのは非常に非効率だ。この数字は将来的に変わるかもしれないし、この IP アドレスで提供されるサービスは一つに限ったことではない(FTP、メールなど)。
そこで、この数字と抽象的な名前(○○.co.jp とかのことで、これをドメイン名という)を関連づけることによって、柔軟なアクセスを提供するのが DNS という仕組みだ。たとえば、TAMA Networks のブックマークをブラウザで呼び出すと、ブラウザは amatsukami.jp にアクセスしようとする。ブラウザはまず DNS を提供しているサーバに「amatsukami.jp は何番でっしゃろ?」と問い合わせに行くのだ。すると、DNS サーバが「210.136.205.247 でんがな」と答えてくるので、ブラウザはその DNS から答えられた番号の振られているコンピュータ(サーバ)にアクセスしに行くのである。
これはなにも amatsukami.jp に限ったことではなく、世の様々なサーバ(sony.co.jp とか honda.co.jp とか)すべてがこの方法でアクセスしたいサーバを求めており、これを名前解決と言い、このような DNS サーバを「フルサービス・リゾルバ」という。

ではどのフルサービス リゾルバ DNS にアクセスしに行くのかというと、それは各プロバイダが提供している。他にも Google なんかが自由に使える DNS サーバを用意してくれたりしているし、自分で設定することも出来る。
また会社では会社で建てたフルサービス リゾルバ DNS サーバがその役を担い、ウチの会社もそうなっている。

さて、では DNS サーバというのは全世界中の IP アドレスと名前の情報を持っているのかというと、そう言うワケではない。DNS サーバは例えば「amatsukami.jp は何番よ?」と問い合わされたら過去に同じ問い合わせがないかをまず調べる(キャッシュ)。なければ、.jp を管理している DNS サーバに問い合わせに行く。すると .jp を管理している DNS サーバは「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」と返してくるので、210.136.205.247 に問い合わせに行くと、210.136.205.247  の DNS サーバ(つまりボクのサーバ)が amatsukami.jp に関する様々な名前と数字の対応を返すのである。このようにフルサービス リゾルバは、次々とより上の DNS サーバに問い合わせていくようになっていて、これを再帰呼び出しと言う。
amatsukami.jp に関する様々な名前というのは、例えば ftp.amatsukami.jp や www.amatsukami.jp など、amatsukami.jp がつく様々な名前である。ここで初めて、amatsukami.jp も 210.136.205.247 だとって返ってくるので、これを問い合わせしに来た機械に渡すのである。
この時、この「問い合わせをしに来た機械を詐称」することができる。
つまり本来は、A というコンピュータが「amatsukami.jp は何番よ?」って聞いてきたら、その結果を A に返すはずなのだが、ここを B というコンピュータに返せとすることが出来てしまうのである。
こうすることによって DNS サーバは B に答えを送ってしまうどころか、本来定義されていない情報を問い合わせる(この問い合わせ内容が、普通の DNS 問い合わせより遙かに情報量が多いように細工されている)ことによって、DNS サーバはコンピュータ B の回線をパンクさせてしまうのだ(実際には何万台という乗っ取られたパソコンをつかって、DNS サーバにこのような攻撃を行う)。
そのためフルサービス リゾルバは、インターネットの誰からでも受けてはいけないように設定しなければならない。そもそもこの名前解決の問い合わせは各プロバイダが提供しているのであって、わざわざ他人のサーバに問い合わせる必要などない。従ってウチも社内でのみ、このサービスは提供すべきなのである。

ではなぜそれがインターネット全体にも提供していたのか?
それは上の説明にも出てきた「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」という部分である。ボクのサーバは全インターネットに向けて、amatsukami.jp に関してのみ責任を持って名前解決をしなければならない(こういう DNS サーバをコンテンツ サーバという)。
amatsukami.jp のついたものに関しては、ボクのサーバだけが真実を知っているのである(実際には真実を知っているサーバを定義することが出来るが)。
そして Microsoft の DNS サーバは、フルサービス リゾルバとコンテンツ サーバを分離出来ない。もし分離したかったら、フルサービス リゾルバ用の DNS と、コンテンツ サーバ用の DNS をそれぞれ別に立てないといけないんですな(ちなみに UNIX の世界で使われている BIND という DNS のプログラムは、この二つの機能を分離出来る)。

まぁ、Windows でも BIND 使うべきなのかもしれないけどね……。

で、とりあえず会社の方はコンテンツ サーバとしての役割を他の外向けサーバに移し、ルータ側で DNS の外部ポートを閉じた。
一方の amatsukami.jp は LAN 内の Active Directory を提供しているマシンにフルサービス リゾルバを設定し、SMTP(メール)のゲートウェイをしているサーバに新たに DNS をインストールし、そちらでコンテンツ サーバとして設定した。これで amatsukami.jp サーバがオープン リゾルバではなくなった。

あー、説明が長かった……orz
ちゃんと正しく説明できているかなぁ……。