_ 自宅からこんばんは。かえってきたよ。ただいま洗濯中。
_ きのう。曇。奥只見や尾瀬に向かうつもりだったんだけど、これから登る山が麓からまったく見えない。これじゃ山に行ってもつまらんな方針転換して、めざせ日本海。柏崎から日本海に出て R8 を南下。といっても半分ぐらいは海なんかぜんぜん見えない市街だったけど。んで、糸魚川から姫川沿いに松本方面へ。途中小谷で風呂に入ったり青木湖を自転車で一周したりして寄り道しながら松本城についたころにはもう夕方で見物できず。これからどうしよっかなーと地図とにらめっこしてたら、美ヶ原高原に道の駅が最近できてたことを発見。夏の車中泊は標高の高いところ、というセオリーにしたがって、日没間際の山登り。標高 1900m の車中泊は、やっぱり20台近いお仲間の車といっしょだった。走行距離 280km
_ 今日。霧ヶ峰方面へ。3年前のちょうどこの季節に一度来てるんだけどね。八島ヶ原湿原を歩いてぐるっと一周。その後、霧ヶ峰、車山高原と過ぎていったんだけど、ニッコウキスゲが咲いてない。霧ヶ峰にはそこそこあったけど、車山高原ではただの1本も見られず。前回来たときはあたり一面山吹色に染まっていたのにえらい差だな。失望のうちに白樺湖を5分で一周して、蓼科から今度は八ヶ岳へ。登って降りたらそこは山梨県。そろそろ帰らんといかん時間なので、昇仙峡を見物してから、渋滞必至の中央道、甲州街道を避けて奥秩父経由で一般道だけで帰還。400km。
_ つーわけで、合計 1130km でした。うち、高速道路を使ったのは行きの関越道を 100km だけ。まだまだ走れるけど、あしたはスーツ着てお仕事だよ。
_ スーツ着てお仕事。3連休遊び呆けた後、しかもこのクソ暑さの中でこの格好はキツい。出社した時点で気力、体力を使い果たした。
_ スーツいらんから、と言われた。営業にダマされた。泣くぞ。いじめか？
_ わ、びっくり。
_ うちではキャッシュ DNS に unbound が動いているから、例の件のソースポートランダム化は大丈夫なはず。
_ が、 大丈夫かどうか試してくれるところに聞いてみたらこんな結果に。
たしかに毎回違うソースポートを使ってはいるんだけど、その範囲が非常に狭い。つーかほぼ連番なので実質的にはランダム化されているとはいえない。簡単に推測できてしまう。GOOD なんてウソ。POOR だよ。Source Port Randomness: GOOD Number of samples: 26 Unique ports: 26 Range: 60722 - 62282 Modified Standard Deviation: 303 Bits of Randomness: 10 Values Seen: 62258 62259 62260 62261 62262 62263 62264 62265 62267 62266 62268 62269 62270 62271 62272 62273 62274 62275 62276 62277 62278 60722 62279 62280 62281 62282_ ところが、このチェックをするときに仕掛けておいた tcpdump の結果を見ると、連番じゃなくてちゃんとランダムなポートを使っている。
01:31:54.208779 IP 192.168.1.1.41305 > 149.20.3.35.53: 29950% [1au][|domain] 01:31:54.447453 IP 192.168.1.1.29709 > 149.20.3.36.53: 62315% [1au][|domain] 01:31:54.791519 IP 192.168.1.1.22895 > 149.20.3.37.53: 50102% [1au][|domain] 01:31:55.071285 IP 192.168.1.1.53889 > 149.20.3.38.53: 38854% [1au][|domain] 01:31:55.445470 IP 192.168.1.1.58898 > 149.20.3.39.53: 11997% [1au][|domain] 01:31:55.747117 IP 192.168.1.1.58574 > 149.20.3.40.53: 14908% [1au][|domain] 01:31:56.034227 IP 192.168.1.1.24475 > 149.20.3.41.53: 25822% [1au][|domain] 01:31:56.316282 IP 192.168.1.1.26674 > 149.20.3.42.53: 42374% [1au][|domain] 01:31:56.863225 IP 192.168.1.1.51553 > 149.20.3.43.53: 10520% [1au][|domain] 01:31:56.864561 IP 192.168.1.1.49770 > 149.20.3.43.53: 1540% [1au][|domain] 01:31:57.140193 IP 192.168.1.1.32204 > 149.20.3.44.53: 18655% [1au][|domain] 01:31:57.386678 IP 192.168.1.1.34089 > 149.20.3.45.53: 11100% [1au][|domain] 01:31:57.597258 IP 192.168.1.1.32451 > 149.20.3.46.53: 33411% [1au][|domain] 01:31:57.866292 IP 192.168.1.1.12621 > 149.20.3.47.53: 15765% [1au][|domain] 01:31:58.188048 IP 192.168.1.1.59079 > 149.20.3.48.53: 14993% [1au][|domain] 01:31:58.425784 IP 192.168.1.1.39452 > 149.20.3.49.53: 64566% [1au][|domain] 01:31:58.645783 IP 192.168.1.1.36953 > 149.20.3.50.53: 10205% [1au][|domain] 01:31:58.858594 IP 192.168.1.1.8327 > 149.20.3.51.53: 6374% [1au][|domain] 01:31:59.098778 IP 192.168.1.1.29505 > 149.20.3.52.53: 37298% [1au][|domain] 01:31:59.404197 IP 192.168.1.1.22035 > 149.20.3.53.53: 14422% [1au][|domain] 01:31:59.664684 IP 192.168.1.1.20549 > 149.20.3.54.53: 32304% [1au][|domain] 01:31:59.903818 IP 192.168.1.1.51446 > 149.20.3.55.53: 54581% [1au][|domain] 01:32:00.138176 IP 192.168.1.1.39904 > 149.20.3.56.53: 1187% [1au][|domain] 01:32:00.499806 IP 192.168.1.1.39240 > 149.20.3.57.53: 51139% [1au][|domain] 01:32:00.787345 IP 192.168.1.1.45813 > 149.20.3.58.53: 64853% [1au][|domain] 01:32:01.098789 IP 192.168.1.1.38372 > 149.20.3.59.53: 15497% [1au][|domain]_ つまりどういうことか。うちの家庭用ルータが、NAT する際にランダムなソースポートを連番に書き換えてしまってるってことだ。これじゃキャッシュ DNS で対応してもまるで意味がねーよ。
_ うちの環境にかぎって言えば、外部からうちの unbound にクエリーを投げることはできないので、こんな結果であっても毒入れしようにもできないはず。しかし、もし外部からのクエリーを受け付けるような設定になっていれば危険だった。こういうしょぼい実装の NAT 箱やファイアウォールがほかにもあるかもしれないので、キャッシュ DNS の前にそういう箱を置いている環境の人はいちおう確認しておいた方がいいかもしれない。
_ この前 DNS のソースポートランダム化が NAT 箱で連番ポートに変換しちゃうと事実上対策していないのと同じと書いたけど、でも、外から問い合わせを受け付けるようなキャッシュ DNS を NAT 箱のうしろに置くようなことなんかふつーないよね。
_ ……と思ったけど、あるな。ISP がユーザに提供しているキャッシュ DNS って、acl をかけずにわざと open resolver な設定になってることが多い。そういうところにかぎってヘビーな使われかたをすることが多いから、大手 ISP では DNS 本体の前段にロードバランサを置いてるところがそれなりにあるんじゃなかろうか。で、裏側の DNS からのパケットがロードバランサを通らず直接出ていく構成ではなく、ロードバランサが NAPT するような構成だとビンゴ。丁寧にランダムなポートをランダムなポートに書き換えてくれればいいけど、あんまり期待できない。連番になってズドン。
_ これ、BIND の入れ替えでは済まず、パケットがどう流れるかというネットワーク設計のレベルから作り直す必要があるから、現状のネットワーク構成によってはちゃんと対策するのがひじょーに大変なところもあるかもしれない。既存の利用に影響を与えないように短期間に新しい構成に移行するのはかなりの苦労だ。
_ ISP では open resolver がふつー、という常識をまず変えていかなきゃならん時代がやってきたのかな。