1 [Book] スティーリング・ザ・ネットワーク

スティーリング・ザ・ネットワーク—いかにしてネットワークは侵入されるか<-4/1 12:30までリンク先間違えてましたm(_ _)m
面白そうだなぁ。いつ発刊なんだろうと思ったら、もう発刊しているのか(^^; id:sonodamさんとこから。

2 続・ICMPのフィルタリングの戯言

お言葉をいただいて思い出した(汗、マスタリングTCP/IP応用編とTCP/IPセキュリティを眺めたり、考えたりしてみた。icmpさんからいただいコメントは参考にICMPのフィルタリングとして、こんなのどうだ！？というお言葉と解釈したので、それを起点にちょっと書いてみる。みなさま遠くからも含めて(笑 コメントありがとうございました。

• $fwcmd add allow icmp from ${oip} to any icmptype 3,4,8,11,12
• $fwcmd add allow icmp from any to ${oip} icmptype 0,3,4,11,12

許可するものとして自分を起点にout方向はICMPのtypeが3,4,8,11,12。in方向はICMPのtypeが0,3,4,11,12という感じ。

• out方向
  • type3 宛先到達不通知(Destination Unreachable)
  • type4 発信抑制(Source Quench)
  • type8 エコー要求(Echo Request)
  • type11 データグラムの時間超過(Time Exceeded for Datagram)
  • type12 データグラムのパラメータ異常(Parameter Problem on Datagram)
• in方向
  • type0 エコー応答(Echo Reply)
  • type3 宛先到達不通知(Destination Unreachable)
  • type4 発信抑制(Source Quench)
  • type11 データグラムの時間超過(Time Exceeded for Datagram)
  • type12 データグラムのパラメータ異常(Parameter Problem on Datagram)

out方向とin方向の違いは細かいことを気にせずに簡単に言ってしまうと、自分はpingを使えるけど、pingの応答は返さないという具合。out方向とin方向で共通に言える事を順に見る。

宛先到達不通知は読んで文字の如し。例えば

• ping応答でもたまに目にすることもあるような経路の途中のルータとかが応答を返す ICMP Destination Unreachable / Net Unreachable (type3 code0)とかICMP Destination Unreachable / Host Unreachable(type3 code1)。
• UDPポートに接続できなかったり、UDPポートスキャンのOpen,Close判定で利用されたりと、一部の人にはこれが重要に感じてたりすることも多い(笑 ICMP Destination Unreachable / Port Unreachable (type3 code2)。
• RFC2979とかでもブロックしてはならないとまで書かれてる、Path MTU Discovery関連の話題で、簡単に言ってしまえばMTUのサイズが大きいので小さくしろと言って、それを受け取って解釈できればMTUのサイズを小さくして通信が行えるという具合の話のなかで使用されたりする ICMP Destination Unreachable / Fragmentation Needed and DF Set (type3 code4)。ダメなルータの場合等は自分でMTUのサイズを調整しないと通信で障害が残るので、ちょっと詳しくて頼られちゃう人はこの手のトラブルでウンザリしている可能性もある。
• いけないことを想像して、IP Source Routeを指定しパケットを送信してみたなど、そんな某かのテストで出会ったこともあるかもしれないのが、ICMP Destination Unreachable / Source Route Failed (type3 code5)。

とかいった具合で、codeは15まで続くわけだ。ちゃんとフィルタリングを考えてやろうとすると、Destination Unreachableのcode毎にin方向とout方向を考えてフィルタリングかと。というか、そこまで可能なフィルタリング機構を備えた奴は少なくなかったりするかも。WindowsだとCHX-Iとかできた気がするな。

輻輳してパケット捨てちゃいましたと送られてくるのが発信抑制(Source Quench)。メッセージを受け取って期待される処理は、転送速度を下げる。転送速度上げていいよメッセージがあるわけではないので、発信抑制が送られてこなかったら、だんだんと転送速度を上げるらしい。そんな実装がちゃんとなっているのか、調べた方がいるみたい。でも、ちょっとドキュメント的には古い。けれど興味深い。ICMP Source Quench パケット処理の実装に関する実験(Dec 1996)

データグラムの時間超過はtracerouteで頻繁に接する機会が多い。tracerouteはTTLの値を１から順に増やしていって、経路を調べたりするものに使用しするが、まさにそのTTLが0の時にこのメッセージを送信元に返す。

データグラムのパラメータ異常は具体的なシチュエーションが思い浮かばない。想像してみると妙なIPヘッダのパラメータを送ることで、わざとこのメッセージを遅らせることで、fingerprintに使うこととかあるのかなぁ。というか、そいうのを期待して許可するものでは決してない(^^;;; 調べてみないと分からないことだけど、OSで特徴が現れるということはなさそう気はする(まだ言うか XprobeではICMP unreachable test,ICMP echo request/reply test,ICMP timestamp request,ICMP information request,ICMP address mask requestあたりをテストしているみたい。

で、思うんですけど、やっぱりICMPってtypeの説明やcodeの説明はどこかしこにコピーしたかのような情報はたくさん見かけるけど、結局このtypeのICMPメッセージは末端の端末には影響なくて、経路上のルータで使うようなものだけど、今どきはこれ自体も使わずに違うプロトコル使ってるんだよとか、このtypeのICMPメッセージは一見 末端の端末で意味をなさないように見えるけど、実はこういう時にこういう使いかたしていると、すげーいいんだよ。といった、実際のネットワークに密着したネットワーク構成のどの部分では、どうでこうだみたいなICMPの話がどこかで読めるといいなぁと妄想した、１日でした。そうそうHTTPプロトコルみたいな本で、ICMPプロトコルなんて本があったらないいなぁ(^^;

3 昨日

の日中は打ち合わせと課内庶務で１日が終わってしまって、年度末最後にちょっと悲しかった。

4 うちの会社

ウイルスをゲートウェイで検出した後に、Fromに対してその旨のメールを送るのやめてくれませんかね…