| OSI参照モデルとTCP/IP階層構造との比較 |
|
| （注意）
TCP/IPでも、LANのイーサーネットの場合、 物理層とネットワークアクセス層を一緒にして 「ネットワークアクセス層」としている場合があります。 物理層とデータリンク層に、またがったプロトコルとして ネットワークアクセス層があるからです。 |
システム奮闘記：その18
はじめに
題名が「ルーター入門」なので、読者の方で、なんでインターネット接続で、
しかも自前で全部やっているのに、設定を知らへんねんと思われるでしょう。
特に「システム奮闘記・その2」(Linuxでサーバー構築)で
ヤマハのRTA52iの設定をしている記述があるだけに「なんで?」という
疑問を持たれる方も、おられると思います。
ここでお得意(?)の暴露しまーす！
実は、本を見ながら、適当にやっただけです！
そうなのです。本を見ながら記述通りやったり、それでも、うまくいかなかったら、
適当に触っていたら、たまたま、うまくいったのです (^^) ← 自慢してどーする！
うまく動いていたら、わざわざ勉強する気は起こらないが、そうはいかなくなった。
それは、インターネットの回線を、ISDNからADSL回線へ切り替えるためで
ヤマハのRTA52iのルーターは、ADSLに対応していない。
ADSL対応のヤマハのRTA55iに変える必要があった。
ぶっつけ本番でルーターの設定を行なうのは恐いので、だいぶ前もって
ヤマハのRTA55iを購入して、設定の予行演習を兼ねてテスト的に導入を考えた。
購入したのは良いが設定マニュアルを見て、目が点になった。
お助け舟と思い「RTA54i/RTW65b/RTW65i徹底使いこなしガイド」
（猪口修道：技術評論社）を見たが・・・。
全然、わかんない （ＴＴ）
しばらく悩んでしまった。このままでが3年前の二の舞になるのは確実。
このままの状態でADSLへ回線を切り替えても、設定はできずに
ネットを止めてしまうのは目に見えている。
そのため、RTA55iの勉強しながら設定するような悠長な事もできない。
そこで一計を案じた。現在、運用中のヤマハのRTA52iを使って、
色々、触りながら、ルーターの勉強をすることを思いついた。
ルーターの設定を見て、どれがどういう振る舞いをするのかを見たり、
ネットが使われていない時間に、ちょこちょこと設定を触って動作を確認する。
あまり誉められた方法とは言えないが、止む得ないので、そうすることにした。
だいぶ長い前置きになりましたが、ルーターの勉強のはじまりはじまり
というより、己れの無知さを暴露している感じがする・・・ (^^;;
3年間、封印していたルーターを開けるので、パンドラの箱のような感じだった。
社内に、ほこりが被ったルーター設定の本がある。
「RTA52i徹底使いこなしガイド」（猪口修道：技術評論社）
そして助っ人として「最新TCP/IPハンドブック」（若林 宏：秀和システム）
という本を取り出して、ルーターの設定やネットワークの復習を行なった。
さて、ルーターの本を読んでいくと、ネットワークの本にもよく出てくる
レイヤ構造が出てくる。さて、レイヤーとは階層構造の事を表す。
実は、編集当初、編集の量は少ないと見積もって、少しでも話を作るため、
「レイヤーとは・・・」で、くだらないギャグを書いていたが、
いつの間にか、膨大になったので、くだらないギャグを、一部だけ紹介します。
レイヤとは、お姫様の名前 ← スターウォーズのレイア姫！
レイヤとは、掛け声のこと ← そりゃ、エイヤー！
レイヤとは、鉄の紐 ← そりゃ、ワイヤー！
レイヤとは、クリスマスの夜 ← そりゃ、聖夜！
レイヤとは、野球で３人で守る場所 ← そりゃ、外野！
レイヤとは、ギリシャ神話の母なる大地の神 ← そりゃ、ガイア
お粗末さまでした。ふとんが「ふっとんだ！」の方がマシなような・・・。
「レイヤ」とは階層の事で、通信の方法が階層構造になっていて、
各階層で、個々の通信に必要な事を行なう。
| OSI参照モデルとTCP/IP階層構造との比較 |
|
|
| （注意）
TCP/IPでも、LANのイーサーネットの場合、 物理層とネットワークアクセス層を一緒にして 「ネットワークアクセス層」としている場合があります。 物理層とデータリンク層に、またがったプロトコルとして ネットワークアクセス層があるからです。 |
上の図。ネットワークの本に必ず書かれている上、今までも何度も見てきたため 全く目新しさなどは感じない。 しかし、具体的に、どういう振る舞いをしているかなどについては、 ピンとくるものがなかった。 そのため、今回のルーターを設定する前までは「だから何？」という感じだった。 本を読むと「IP層」について説明があった。 でも、これだけだと具体的なイメージが掴めないので「あっそ」という感じだ。 私は、想像力が貧困(?)なためか具体例を見ないと、なかなか理解できない 頭の構造になっている。 でも、ある図を見て「なるほど！」と思った。
| 単なるルーターとフィルター付きルーターの仕組みの違い | |
通常のIPルーティング |
フィルタリング付きIPルーティング |
|
左図のように、単なるルーターだと、IPを見て行き先を判断する。 そのため、やって来たパケットを見てIP層で判断して、一番良い行き先を探す。
しかし、右図のように、フィルター付きの場合はTCP・UDP層も仕事をする。 | |
この図を見て初めて、ルーターで具体的にフィルターリングの設定をして、 必要なパケットだけを通過させる作業と、TCP/IPの階層図とが結びついた。 これを書いた時点では、実は、まだ認識は浅かった (^^;; 階層構造の話を書きたい所だが、あまりにも知らない事が続出して、 ルーターの話なのか、TCP/IPの話なのは、わからなくなってしまうため、 今回は、割愛させていただきました m(--)m いずれ「仁義なきLAN内のパケット送信の戦い」（仮題）で書きたいと思います。 本を読み進めていると、WindowsのプロトコルNetBIOS over TCP/IPが書いてあった。 本を読んだ時点では、WindowsのNetBEUIのプロトコルをTCP/IP通信ができるように カプセリングしたと書かれていた。「へぇ〜、そんな技術があったの」と思いつつ、 しかし、その時は「関係ないや」と思い読み飛ばしたが、 この本の編集時に読み返すと「カプセリグする理由は何かなぁ」と思った。 本によると、NetBIOS over TCP/IP ができた背景には、Windowsのネットワークで、 名前解決を行なう際、昔は、NetBEUIが行なっていたが、このプロトコルの場合、 ルーターを通る事ができない。ルーター越えができない。 そこで、ルーター越えするために、開発されたのがNetBIOS over TCP/IPという。 ルーターの設定の本では、NetBIOS over TCP/IPのパケットを外に出さないように フィルタリングすることが書かれていた。 理由は、次の2点だった。
| NetBIOS over TCP/IPのパケットを外部へ出さない２つの理由 | |
| 異常課金 |
インターネット接続が、ダイヤルアップ場合。 LANの中での通信を行なう際、名前解決を行なう。 その時、もし、名前解決できない場合は、NetBIOS over TCP/IPで ルーター越えをして名前解決を行なおうとする。 ルーターはパケットを外に出すため、ダイヤルアップ接続をしてしまい、 不要な通信費が発生する。この異常課金を防ぐため。 |
| セキュリティー問題 |
インターネット上で、名前解決のパケットはノイズ以外の何物でもない。 しかも、ルーターでNATをしている時、LAN内部のプライベート アドレスなどの情報が流れる。 セキュリティー上、好ましいとは言えないため。 |
異常課金問題は、ISDN回線の常時接続をしていたため、全く関心が無かった。 セキュリティー問題。全く認識していなかった (^^;;;;;;;;; 「なんて、ええ加減な管理者なんだ！」と言われそうなので、反論します！ だって、「RTA52i徹底使いこなしガイド」（猪口修道：技術評論社）に 載っていなかったもん (^^;;; ← ますます、管理者失格の烙印が押される！ 実は、セキュリティーの問題に関しては 「RTA54i/RTW65b/RTW65i徹底使いこなしガイド」（猪口修道：技術評論社）を 読んで初めて知りました (^^;;;;; NetBEUIの話は、身近なLANでのファイル共有に関係してくるだけに、 どんなもんかいなと思い、興味本位で調べ出したら、ドツボにハマった。 そのため、この章で軽く取り上げるつもりだったのが、収まりきらず、 独立した話で取り上げました。 詳しくは「システム奮闘記・その１７」をご覧ください (^^) さて、いよいよ設定個所を見ながら勉強する運びとなった。 まずは、設定状況を見てみた。 ちなみに、XXX.YYY.ZZZ.RRR/29は、うちの会社のネットワークアドレス。 いくらオープンな私でも、これは安全保障上、秘密にせねばならない。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 10 | reject-log | XXX.YYY.ZZZ.RRR/29 | ＊ |  |
|
 |
|
| ＊ | ＊ | ＊ | |||||
| 11 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| icmp | ＊ | ＊ | |||||
| 12 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| established | ＊ | ＊ | |||||
| 13 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp,udp | ＊ | domain | |||||
| 14 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp | ftpdata | ＊ | |||||
| 15 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| udp | domain | ＊ | |||||
| 30 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp,udp | ＊ | smtp | |||||
| 31 | pass-nolog | ＊ | XXX.YYY.ZZZ.AAA | |
|
|
|
| tcp,udp | ＊ | www | |||||
上のフィルタリングを見ると、RTA52iの機能では、NetBIOS over TCP/IP の フィルタリングがないのを除くと、まともな設定になっている。 あと、「内部から外部へ出るパケットを許可する設定がないではないか」と おっしゃる方もおられると思います。それについては後述しています。 ところで、知識がないのに、比較的、まともな設定ができるのか？ 理由は、ヤマハが提供している簡単設定を行なっていたからだった (^^;; しかし、なぜ、そういう設定なのか、ほとんど理解していなかった。 そこで、本と設定との睨めっこが始まった。 まずは、設定部分を上から順番に見ていくことにした。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 10 | reject-log | XXX.YYY.ZZZ.RRR/29 | ＊ | |
|
|
|
| ＊ | ＊ | ＊ | |||||
これは、外部から社内のネットワークに入ってくるパケットの中で、 ネットワークアドレスが、XXX.YYY.ZZZ.RRR/29の物は破棄する。 XXX.YYY.ZZZ.RRR/29は、うちの会社のネットワークアドレス。 うちの会社のIP（マシン）になりすます不届き者を遮断する機能 もし、『なりすまし』をされると、内部のマシンという事で、チェックも甘いため、 メチャクチャにされることもある。 いくら、TCPWrapperなどを使って外部のアクセスを制限しても、 内部まで厳しい制限なんぞしないし、すると、不便になったりする。 そのため、身内には甘い（？）という弱点を突いた攻撃方法を防ぐ砦となる。 さて、番号11、12となるのだが、ここは理解に手こずったので、 それについては後述することにして、DNS関係の13、15を見てみた。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 13 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp,udp | ＊ | domain | |||||
これはDNS関係の設定だ。 さて、上の設定を見て「DNSのプロトコルはUDPのはず。 しかし、私は何も知らずにTCPも入れていた。ネタになる」と思った。 ネタができたと喜んだ私だが、実は、それがネタになったりする。 なぜなら、DNSはUDPのみというのは間違いだから！ ゾーン転送の時は、UDPでなくTCPを使う。 ところで「ゾーン転送」と書いたが、実は、ゾーン転送って何なのか知らなかった！！ ここまで無知だったのかと自分でも驚いてしまう！！ DNSに関する話。結構、誤解や無知が発見されたので、 DNSの設定の話でまとめることにしまーす。乞うご期待 (^^) ところで、これは外部のマシンが、うちのDNSサーバーを参照に来る時の フィルターの設定である。 そのため、最終ポートは「XXX.YYY.ZZZ.RRR/29」のネットワークアドレスでなく、 DNSサーバーのIPアドレス「XXX.YYY.ZZZ.AAA」にするべきだった。 なぜ、そんな設定をしたのか。それはルーターの本で簡単設定の方法の部分で、 ネットワークアドレスが書かれていたからだったと思う。 それと謎が一点。ルーターの簡単設定で、この設定が出てくる。 DNSサーバーを、ルーターの内部に置く置かない関係なしに。 不思議だと思ってしまうが、今更、原因を追求する気が起こらない。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 15 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| udp | domain | ＊ | |||||
これは、うちの内部のマシンが外部のDNSを参照した際、 返答のパケットを通す設定。 ここは、結果論的に言えば、問題なしの部分だ (^^)V
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 14 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp | ftpdata | ＊ | |||||
これは、FTPをした時に、接続先のサーバーから送られるデータを 受け取るためのポート。 編集時の時は、この話を知っていたが、設定当時は知らなかった！！ まぁ、簡単設定の上、設定の本を、そのままそっくり真似したら 良かっただけなので、知らなくても問題はなかった。
| FTPの時のポート |
|
| （コメント） この図を見て、PORTモードだけでなく、 PASVモードもあるぞと言われそうなので、コメントします。 上の図は、PORTモードと言われる方法で、昔からある方法です。 もう一つのPASVモードは、データの要求は21で行ないますが、 データの受取りポートは、サーバーが指定したポートを使います。 もし、サーバーは2345番のポートを指定したら、クライアントは 2345番のポートを開けて、データの受け取りを行ないます。 ちなみに、PORTモードとPASVモードの切り替えですが FTPコマンドで、PASSIVEとすれば、ON/OFFができます。 Windows98のDOSプロンプトからftpをした場合は、このコマンドはできず、 PORTモードのみでデータのやりとりを行ないます。（確認済み） |
普通なら「設定時の時、FTPのポートは21か20で混乱したのでは？」 と思われるが、全く混乱しなかった。 理由は単純だった。混乱するほど知識がありませんでした (^^)V もちろん、簡単設定を、そのまま真似したため、何も考えていなかった。 言わば「思考の停止」だった。 (--;; ポートの21と20。実際、PORTモードでFTPを使うと、 ホントに、ポート20で、データ受け取りをしているのか確認したくなった。 そこで、パケットを拾い上げるコマンド（tcpdump）を使ってみた。 tcpdump -i eth0 port 20 | cat - > ftp.dat これで、適当なマシンにFTPをしてみる。データの受け取りをしていないと ftp.dat には書き込まれないが、データを取ると、パケットのやり取りが記録される。 なかなか、tcpdumpというコマンドは面白い。 本の知識だけでなく、実際のパケットの動きが見れるからだ (^^) ここで暴露します！！ 実は、私はPASSIVEモードがあることを知りませんでした (^^;; ずーと、FTPのポートは、コマンドは21で、データは20だと思っていました。 でも、PORTモードも最初から知っていたわけでなく、2001年の秋、 このホームページが立ち上がる1、2ヶ月前のLILOのセミナーで この話を知りました。それまでは、ポート21ばかりだと思っていました (^^;; さてさて、自社でWebサーバーとメールサーバーを立ち上げていたため、 メールサーバーに入ってくるパケットと、Webサーバーにアクセスしてくる場合は 通過設定していた。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 30 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp,udp | ＊ | smtp | |||||
| ３１ | pass-nolog | ＊ | XXX.YYY.ZZZ.AAA | |
|
|
|
| tcp,udp | ＊ | www | |||||
なぜか、30番で、プロトコルの所にUDPが入っている。 なぜUDPを入れたのか、ハッキリした記憶がないが、恐らく、TCPだけでなく UDPも追加すれば、接続にトラブルがないだろうという変な安心感だと思う。 知らないと、いらない設定をしてしまう良い例かもしれない (^^;;;; ここでも失敗している。30番のSMTPの最終IPアドレスの部分で。 最終IPアドレスを、メールサーバーのIPにしなければいけない所を ネットワークアドレスを書いている。 なぜ、そうしたのか、記憶がない上、推測できる内容も思いつかない。 そのため、謎だ・・・ (--;; ところで、31番のプロトコルの部分にも、UDPが入っている。 私は「WebはTCPだから、無知だったネタにできるぞ！」と思った。 しかし、それは正しくなかった (--;; ストリームビデオなどの、動画データは、早くデータ転送するため、 信頼性よりも転送速度を重視したUDPを使う場合が多い。 まぁ、うちの会社では動画の配信がないため、UDPは閉じるべきだが、 WebはTCPのみというのは、正しいとは言えない。 ネタを作るつもりが、作ろうとした行動がネタになってしまう (^^;;; さて、難関の12番のestablishedに入る前に、 「内部から外部へ出るパケットを許可する設定」について 内部から外部へパケットを送る際、実際は、次の設定を行なう必要があった。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 100 | pass-nolog | ＊ | ＊ | |
|
|
|
| ＊ | ＊ | ＊ | |||||
これは、全ての内部のパケットは、外部へ出すという設定。 ヤマハのRTA52iで、簡単設定を行なえば、最初から設定される部分であるが、 なぜか、私が使っていたルーターでは、この設定がされていなかったし、 設定しようとしても、なぜか、登録されなかった。 それでも、なぜか、内部から外部へパケットが出ていっていたので、謎だった。 しかし、そのため、混乱した事がある。 2年くらい前、ルーターを勉強しなおそうと試みた事がある。 Webを見る時に、内部から外部へ接続を行なう。 また、メールを送信する際、外へパケットを送り出す。 一見すると、外へパケットを送る部分がない上、 設定方法を知らないため、ハチャメチャな事をしてしまう。 外部のWebや、メールを外へ出すため、次のような設定が正しいと思い込んで、 チェックを行なった。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 30 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp,udp | ＊ | smtp | |||||
| 31 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| tcp,udp | ＊ | www | |||||
結果は、ネットワークが止ってしまった (^^;; 今だと「この設定だと、全てのIPから送られたパケットが、外へ出る際、 相手先のネットワークアドレスがXXX.YYY.ZZZ.RRR/29（自分の所）なら通す」 という意味だと、わかる。明らかに、おかしい設定だ。 さて、ヤマハのルーターは、許可されていないものは禁止されるという設計だ。 そのため、他に外へ出る設定がないため、上記の設定以外のパケットは、 外へは出れなくなる。これでは、ネットワークが止ってしまうのも無理がない。 だが、当時は、真面目に考えて、これが正しいと思い込んでいた (^^;; しかし、不思議と、元の設定に戻すと、正常になった。 ルーターの設計は許可されていないものは禁止されるなのに、 何も設定していないのに、外へパケットが自由に飛んでいった。 今も、これは謎のまま。しかし、今更、謎を解く気もない・・・ (--;; さて、当時は、全く知識がなかったため、混乱しただけで、放置されることになり、 3年を経て、ルーターの勉強の時に、はじめて分かった事柄だった。 いよいよルーター設定の理解の難関の12番。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 12 | pass-nolog | ＊ | XXX.YYY.ZZZ.RRR/29 | |
|
|
|
| established | ＊ | ＊ | |||||
最初、この説明を読んだ時、チンプンカンプンだった。 「ACKを伴ったパケット」の受け入れと本には書いている。 でも、「ACKって何？」だった (^^;;; ← ネットワークの知識ゼロ丸出し。 さて、establishedとは何かを考えていると同時に、フィルター設定を見て 疑問に思っていた事があった。 それは、例えば、外部のWebへ見に行った時、Webのファイルや画像などの データが送られてくる。それらのパケットは、どうやって通しているのだろうか。 （この時点では、establishedが、その役目を果たしているとは思わなかった） そのため、独立した物として、それが何であるのか個々に並行して考えていた。 しかし、わからないため、悩んだ挙げ句、これも3年、放置されることになった。 ある日、ネットワークの本で、TCP通信の接続開始の部分を見た。 「コネクション確立」といわれる所だ。
| コネクション確立（3Wayハンドシェイク） |
|
（説明）
例えば、Webサーバーへのアクセスを考える。
(1) 接続先のサーバー（MAYUMI）接続要求信号（SYN）を送る。
(2) MAYUMIは、許可する場合、データが届いたという応答信号（ACK）を送る。
しかし、MAYUMIは、持っているコンテンツを送りたくても、
接続を要求してきたONOが、そのパケットの受付許可をしていない。
そこで、MAYUMIはACKと一緒にSYNの信号をセットで送る。
(3) もちろん、ONOは接続OKなので、返事として、ACKを送り返す
(4) 安心して、MAYUMIは、ONOに、コンテンツと一緒にACKを送る。
こんな感じて、データをやり取りする時、最初はSYN信号で相手の反応を見てそれに対してOKの場合は、返答の意味のACKの信号を送り返す。 そして、お互いが「受け取りました」の返答のACKを送って、 確認をとりながら、通信が続けられる。 このような接続確立のやりとりを「3Wayハンドシェイク」と言う。 |
コネクション確立方法がわかったのだが、まだ、この時点では、 establishedとが結び付かなかった。 結び付いたのは、ルーターの勉強をしなおした時で、establishedの 設定の説明書きを読んだ時だった。 ACK信号を通すという記述を見て、ようやく、外部のWebサーバーなどの データを取り込む仕組みがわかった。 内部のマシンが外部へ接続要求をした時の返答に、ACKが付いている。 ACKを見て、ルーターが「内部のマシンの返事だ」と判断して内部に通す。 ここに来て、ルーターのestablishedの設定と、外部から送られるデータを 受け取る方法とが結びついた！！ （ここで脱線） ONO、MAYUMIが出てきた理由。 それは、私が小野真弓のファンだからでーす！！ アコムのCMを見る度に、真弓ちゃんとデートしてみたいと思ってしまうが、 8才も離れているので、真弓ちゃんには「オッサンの相手は、せぇへん！」と 言われるがオチかも・・・ （ＴＴ） 真弓ちゃんにとって、アイフルの癒し系・チワワは最大のライバルだと思う。 私は、真弓ちゃんを選ぶが、読者のみなさんは、どちらを選びますか？ 閑話休題 ここで、本来なら、設定しておかなければいけないフィルターがある。 それは、NetBIOS over TCP/IP だ。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 1 | reject-log | ＊ | ＊ | |
|
|
|
| udp,tcp | netbios_ns-netbios_ssn | ＊ | |||||
| 2 | reject-log | ＊ | ＊ | |
|
|
|
| udp,tcp | ＊ | netbios_ns-netbios_ssn | |||||
NetBIOS over TCP/IPのパケットは、外に出ないようにする。 この設定、前にも書きましたが、全くしていませんでした。 RTA52iの再勉強中に本に書いてあったので、最後の最後で設定していました。 そのため、3年近くの間、外へパケットが漏れていましたと思う・・・ (^^;;; ここで、注目。この設定の場合、チェックがLANの項目のINについている。 他の設定では「専用線Leased」の項目なのに。 本には、ルーターでパケットをチェックするのに、4つの検問がある。 LAN側とWAN側にあるという。
| ルーターの検問所 |
 |
|
WAN側にINとOUTの検問が２つ。LAN側にINとOUTの検問が２つ。 |
本を見た時、私は思った。なんで、WANとLANの、それぞれに検問があるのか。 「WANだけに統一すればシンプルで、ええやないか」と思った。 なんで、わざわざ両サイドに検問を設け、しかも、NetBIOS over TCP/IP の場合は WAN側でなく、LAN側でフィルターを設定するのか。 考えて出しても、謎だったので、放置することにした。 しかし、この話題を先送りできるのは、編集時まであった。 ガーン・・・やっぱり調べんと、アカンのか (--;;; とういわけで、編集中に調べることにしてみたが、私が「なるほど！」と思う 本やネットの情報がなかった。 でも、よく考えると、なるほどと思う理由が推測できる。
| ルーターの出入り口 |
 |
|
ヤマハのルーターの場合、LAN側は一カ所しか接続できない。 しかし、WAN側は複数の回線と接続ができる。 |
| WAN側でシャットアウトすると |
 |
|
NetBIOS over TCP/IPは、とにかく外へ出してはいけない。 WAN側でフィルター設定すると、全てのWAN側の設定をしなければならない。 手間はかかるし、とりこぼしも出てくる可能性もある。 |
| LAN側での設定。 |
 |
| LAN側で設定すると、一カ所だけの設定で済む。極めてシンプル！ |
そう考えると、わかりやすい。 もちろん、WAN側だって、複数に接続すれば、それぞれ設定が変わってしまう。 WAN側が複数の接続がある場合は、LAN側で一括設定せずに、 個々のWAN側の設定を行なえば、きめ細かい設定が可能になる。 あくまでも推測だが、納得できたので、自己満足にひたる (^^) さて、七転八倒しながらも、ルーターの設定を、ある程度は理解したと思う。 「ある程度」と書く理由は、この奮闘記の編集中にもボロが大量に見つかっている 事実があるため、「ある程度」表現できない (--;; ある程度、理解ができたと思った時、やれやれと思った。 えっ、まだ終わっていない？ 11番のICMPのフィルターが残っているって？ さて、忍法「聞かなかった術」を使って、先に進めましょうといきたいが、 絶対に「手抜きするな！ ええ加減な事するな！」と突っ込まれるのは明白。
| 番号 | フィルター | 始点IPアドレス | 終点IPアドレス | LAN | 専用線Leased | ||
| プロトコル | 始点ポート | 終点ポート | IN | OUT | IN | OUT | |
| 11 | pass-nolog | XXX.YYY.ZZZ.RRR/29 | ＊ | |
|
|
|
| icmp | ＊ | ＊ | |||||
ルーター再勉強の時点で、これを見たが目が点になるどころか、 何の事か全く理解できませんでした （ＴＴ） そうなのです。ICMPって何か知らなかったし、本などを見ても よくわからなかったのです！！ ← 開き直って、己の無知を強調する私。 だから何とか、ゴマかして逃げようと考えたのです (--;; でも、逃げ道がないので、泣く泣く手を出しました。詳しくは後述しています。 さて、話を進めることにしてと。 封印していたRTA52iのルータのベールをめくって、やれやれと思った。 しかし、一難去ってまた一難。山あり谷あり。理由はあった。 まだ、RTA55iの設定が残っているのらー！！ これの設定を理解しない限り、当初の目的、ISDNからADSLへの 切り替え作業ができなくなる。 そのためには、設定方法を理解した上で、かつ、ISDNで問題なく稼働するのを 確かめないと、ADSLへのステップが踏めない。 しかも、ADSLへの切り替えの日が迫っている。 そこで、休む暇もなく、次のステップであるRTA55iの設定へ進むことにした。 RTA52iとRTA55iとの間には、大きな違いがある。 その一つは「動的フィルター」の存在だった。 RTA52iは「静的フィルター」のみだった。 だが、RTA55iには「静的フィルター」と「動的フィルター」の２つがある。 ここで正直な事を書きます。 RTA55iの設定段階では「動的フィルター」って何？だった (--;; このまま放置といきたい所だが、編集の段階で「動的フィルターって何？」だったら 突っ込まれるのは確実なので、調べることにした。 まずは、お助け舟と思い「RTA54i/RTW65b/RTW65i徹底使いこなしガイド」 （猪口修道：技術評論社）を見たが・・・。 全然、わかんない （ＴＴ） 3年前なら「マニュアルの設定を真似したら動いたから、ええやん」で済むが、 今は、そんな、ええ加減な事ができない。 特に、奮闘記を公開しているため、ええ加減な事を書いたら突っ込まれる。 何か良い文献がないかなぁと探していたら、良い本に巡り会えた。 「TCP/IPパケットフィルタリング」（宇野俊夫：エーアイ出版） もう一つはヤマハのルーターの技術関連のページだった。 (URL) http://www.rtpro.yamaha.co.jp/RT/firewall/index.html 動的フィルターは、ステルスと書いてある。 ステルス。お馴染のアメリカのステルス戦闘機で、レーダーに反応しないため、 隠れた感じで飛んでいる戦闘機になる。 動的フィルターは隠れた感じになると言われても、ピンとこない。 でも、なるほどと思う説明書きがあったため、理解できた。 もし、MAYUMIというサーバーがあり、そこへ攻撃する事を考えるとする。 静的フィルターだと、通過許可していないパケットが来ると「拒否」の 返答をするが、動的フィルターだと何も返事をしない。 もし、拒否返答すると、攻撃する人は接続を拒否はされるが、 サーバーMAYUMIの存在は確認できる。 しかし、返答がないと、サーバーMAYUMIの存在自体が確認できない。 まさに隠れているのでステルスと言うのが的を得ているかもしれない。 さて、具体的に図で説明してみると。
| 静的フィルターと動的フィルターの違い | |
| 静的フィルターの場合 | |
 |
（コメント） MAYUMIを狙う悪いオオカミがいました。 オオカミは、ドアの向こうにいるMAYUMIの存在を確かめる。 MAYUMIは「お断りよ！」と拒否の反応をする。 しかし、拒否反応のためオオカミは、MAYUMIの存在が確認できる。 そして無防備になる時を、虎視眈々と待つ。 |
| 動的フィルターの場合 | |
 |
（コメント） MAYUMIを狙う悪いオオカミがいました。 オオカミは、ドアの向こうにいるMAYUMIの存在を確かめる。 しかし、反応が全くないので、オオカミは、ドアの向こうには MAYUMIがいないのではと思ったりする。 そして、オオカミは諦める。 |
うーん、確かに何も返答しないのが、存在を知られないため、安全策だと思う。 これだけを考えると、動的フィルターだけ設定すれば良さそうな感じがするが、 動的フィルターは、静的フィルターとの組合わせで使う。 ここで正直に書きます！ 実は、最初、なぜ動的フィルターと静的フィルターとを組合わせで設定するのか 理解できなかった。 読者の方は「動的フィルターだけを設定して、動かなかったのだろ」と 私の書く内容を先読みされると思います。 しかし、私は相手の裏をかくのが大好きで、動的フィルターだけの設定は 全くしていませんでした。 理由は、最初の設定時に、本の設定の丸写していたため、 「動的フィルターだけでは動かない（ＴＴ）」という事は体験しませんでした。 まさに思考の停止だった (^^;;) 話は元に戻して、例えば、Webサーバーを公開している場合の設定を見てみる。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 90 | |
|
reject | する | established | ＊ | ＊ | XXX.YYY.ZZZ.AAA | 80 | WWW Server |
| 91 | |
|
pass | しない | tcp | ＊ | ＊ | XXX.YYY.ZZZ.AAA | 80 | WWW Server |
| 動的フィルターの一覧 | ||||||||||
| 番号 | 適用 | プロトコル | 送信元 | 送信先 | メモ | |||||
| 入 | 出 | 監視 | 逆方向 | 順方向 | IPアドレス | IPアドレス | ||||
| 82 | |
|
www | ＊ | ＊ | WWW Server | ||||
最初、動的フィルターの使い方を知らなかったため、本に書いてある 設定方法を真似していた。 静的フィルターで、なぜ、establishedが出てくるのかなどが謎だった。 ルーターの本には、SYN信号のみのパケットを静的フィルターで通過させると 書かれていたが、なぜ、そうするのか理解できなかった。 それどころか、ACKの信号をシャットアウトにしているため、 「通信ができなくなるはずなの？」にという混乱を起こした。 ルーターの設定の本には、わかりやすい理由が書かれていなかったため、 設定の時は、上の設定にしている理由が全く理解できなかった。 しかし、編集時に見つけたヤマハの技術のページに、明快な答えがあった。
| パケット第一弾の場合 |
 |
| （説明） 第一弾のパケットは静的フィルターのチェックを受ける。 この時、パケットはSYN（接続要求）のみを通る状態になっている。 通常、第一弾のパケットはSYNなので、問題なく通るが、 第一弾なのに、ACKを含んだ、あやしげなパケットは破棄される。 |
| パケット第２弾以降の場合 |
 |
| （説明） 第２弾以降のパケットは、動的フィルターがチェックする。 受信しているパケットが関連ない場合、動的フィルターは 静的フィルターに判断を委ねる。 静的フィルターがパケットの通過か破棄かを決める。 |
私は「なるほど！」という感じで納得した。 静的フィルターの90番でACKを含むパケットを破棄する設定にして、 91番でTCPのパケットを通過の設定にする。 フィルターの場合、上位の設定が優先される。 そのため、ACKを含まない、TCPのパケットは何かと考えると、 必然的にSYNのみのパケットになる。 RST（接続解除）、FIN（接続終了）のみについては後述しています。 動的フィルターを使う場合、第１弾のパケットのみ、静的フィルターを通るため SYNのみのパケットを通過させる設定にしておけば、後続のパケットは、 問題なく通過していくという。 巧妙なやり方だなぁと思わず感心してしまった (^^) メールサーバーを社内に構築した場合も、同じように設定すればOK！ ふと思う。第2弾以降のパケットは、動的フィルターのチェックになるが、 どうやって第1弾と第2弾以降のパケットを区別しているのか？ 考えたら疑問である。 いつもなら「まぁ、いずれわかるから、ええわ」という発想になってしまうが 奮闘記を書いている以上、そうもいかない。 そこで「最新TCP/IPハンドブック」（若林 宏：秀和システム）の P174のTCPのへッダーの解説を見てみた。
| TCPのへッダー |
 |
本は「シーケンス番号がパケットの番号」と書いている。 「なるほど！ これで番号がわかるなぁ。」と思った。 番号がわかれば、後は、パケットの第１弾の発信元と送信先などの情報と 比較したら、見分けができる。 ところで、よく見ると、へッダーの中には「受信確認番号」というものがある。 正直な所、受信確認番号が、送信パケットの番号と間違えそうになった (^^;; 「こんな混乱する名前の付け方はやめてくれー！」と思った。 一体、どういう関係なのか、本やネットで調べれば調べるほど混乱してしまった。 アリ地獄から抜けられない感じで、どんどんドツボにハマっていった。 しかし、なんとか、理解できた。 ここでポイントとなってくるのが「シーケンス番号」と「受信確認番号」 (1) シーケンス番号は、返答を求める送信データの番号 (2) 受信確認番号は、あるシーケンス番号を持ったパケットに対する返答の番号 そのため、パケットの第一弾が、静的フィルターを通り抜けた後にやってくる 後続のパケットのシーケンス番号を見れば、後続のパケットかどうか 判断できると考えられる。 ところで、シーケンス番号が連番だったり、受信したパケットのシーケンス番号と それに対する返答の受信確認番号が一致すれば、話としては、わかりやすい。 しかし、そんな単純でないため、ややこしい。 その上、コネクション確立時（3Wayシェイクハンド）の場合と、 その後のパケットのやりとりの場合とでは、「シーケンス番号」と「受信確認番号」の 割り当て方が違ってくる。
| 3Wayシェイクハンドの時 |
|
シーケンス番号はランダムで決まる。 受信確認番号は、受信したパケットのシーケンス番号に1を足した数字 |
| その後の場合 |
|
シーケンス番号は、受信したパケットの受信確認番号に送信するパケット長さを足した数字。 受信確認番号は、パケットを無事、受け取った確認の意味あいがある。 そこで、番号＊＊のパケットを受け取りましたという事を伝えるため、 受け取ったパケット番号にあたるシーケンス番号を、受信確認番号に使う。 ただし、最初のパケットだけは例外的で、シーケンス番号に１を足した数字を使う。 |
これを踏まえた上で、図式してみた。
|
「シーケンス番号」と「受信確認番号」の関係 ＷＷＷサーバーへのアクセスで考えてみる |
| 3Wayハンドシェイクの段階 |
|
(通信1) 送信側はパケット送信番号（シーケンス番号）をランダムに決める。 ここでは番号を「5」をする。  (通信2) 通信1の接続要求が届いたので、それの返答を伝えるため、 通信1のシーケンス番号にを1足した番号「6」を受信確認番号に入れる。 同時に、受信側にデータ送信の許可を得るためにを接続許可の信号送る。 その時、シーケンス番号をランダムの数字(ここでは13)送る。 (通信3) 受信側は返答と接続要求のパケットが届いたので、届いたの返答を返す。 この時、受信確認番号はシーケンス番号に1足した数字(14)を使う。 |
| その後のやりとり |
接続確立ができたので、Webのコンテンツデータを要求する。 (通信4) この時、要求データのバイト数を「8」とする。 送るシーケンス番号は、通信2で受け取った受信確認番号「6」に バイト数「14」を足した物を送るので「20」になる。 受信確認番号は、通信2のシーケンス番号に1を足した数字「14」を使う。 (通信5) 通信4の「データくれ！」の要求に対する「了解」の返答。 通信4の返答なので、受信確認番号として、通信4のシーケンス番号「20」を使う。 (通信6) 通信4の「データくれ！」の要求に対しての返答として、データを送る。 通信4の返答なので、受信確認番号は、通信４のシーケンス番号「20」を使う。 シーケンス番号は、通信4の受信確認番号にバイト数を足した数字を使う。 この場合、バイト数24なので、14+24=38 になる。 (通信7) 通信6のデータを受け取った返事。 受信確認なので、受信確認番号は、通信6のパケット番号にあたる シーケンス番号「38」を使う。 (通信8) 通信6で、全てデータを送りきれたら、この通信はないが、 Webのコンテンツのデータが1回で送れません。 そのため、いくつかのパケットに区切って送信しています。 通信6の後続パケットという意味です。 あくまでも、通信4のデータ要求に対しての返答でデータを送るため、 受信確認番号は、通信4のシーケンス番号「20」を使う。 シーケンス番号は、通信7の受信確認番号にバイト数を足したものを使う。 (通信9) 通信8のデータを受け取った返事。 受信確認なので、受信確認番号は、通信8のパケット番号にあたる シーケンス番号「52」を使う。 |
とにかくややこしい。これを編集している時も、混乱しそう (^^;; さて、こんなに複雑な仕組みにする理由が本に書いていた。 パスワード認証後に通信している所へ、なりすましで割り込む輩がいるとする。 単純に１づつ足した番号だと、侵入しやすいが、複雑にすると、困難になるからだ。 どれくらい困難になるのか、私は、侵入できるような技量がないので、 本の受け売りになってしまうが、とにかく困難になるという (^^;; まぁ、パケットの番号にあたるシーケンス番号は増加していくので、 並べるのには問題ないし、送られてくるパケットが、前のパケットに比べて シーケンス番号が大きいと、後続のパケットとして認識できるので、 動的フィルターの仕組みで、後続のパケットかどうかの判断は難しくないと思う。 理解するのが困難だった理由！ 実は、この部分を理解するのに非常に大変でした。 理由は、ネットや本などを調べていたのですが、記述によっては、 シーケンス番号と受信確認番号の割り当て方が、まちまちでした。 例えば、常に、受信確認番号がシーケンス番号に１足した数だとか、 逆に、受信確認番号がシーケンス番号そのものだとか。 そのため、どれが正しいのか混乱してしまいました (--;; その上、上の図を何度も描き直した (-_-メ) ← やーさんモードかよ！ こうなれば、実際、自分の目で確かめる以外、方法はないと考え、 Web閲覧時のパケットの動きを見るため、tcpdumpコマンドを使いました。 tcpdump -S port www > www.datでパケットのやりとりを観察して、 シーケンス番号と受信確認番号との関連を見てみました。
| パケットの動き |
| クライアントは「test.kaisha.co.jp」 ＷＷＷサーバーは「www.kaisha.co.jp」 （パケットの見方）  (1)は時間。(2)は発信元アドレスとポート番号。 (3)は接続先アドレスとポート番号。 (4)フラグの内容。SYNなら「S」、FINなら「F」が入る。 (5)シーケンス番号。(6)送信するデータのバイト数。 (7)受信確認番号 |
| 3Wayシェイクハンド |
08:59:09.083785 test.kaisha.co.jp.1059 > www.kaisha.co.jp.http: S 1939020:1939020(0) win 8192シーケンス番号と受信確認番号とのパア─を同じ色で表しました。 受信確認番号は、シーケンス番号に1を足した数字になっている。 シーケンス番号は、ここではランダムに決められています。 |
| その後 |
08:59:09.089449 test.kaisha.co.jp.1059 > www.kaisha.co.jp.http: P 1939021:1939411(390) ack 506903625 win 8760 (DF) これは「データくれ！」の要求パケット。 ここでの色分けは、上の3Wayシェイクハンドのパケットと対応しています。 シーケンス番号は受け取った受信確認番号にパケット長さ390を足した数字。 ここだけは受信確認番号は、受け取ったシーケンス番号に1を足した数字を使っています。 では、その後について「データくれ！」のパケットから見てみます。 08:59:09.089449 test.kaisha.co.jp.1059 > www.kaisha.co.jp.http: P 1939021:1939411(390) ack 506903625 win 8760 (DF) 08:59:09.089606 www.kaisha.co.jp.http > test.kaisha.co.jp.1059: . ack 1939411 win 6432 (DF) 上が「データくれ！」の要求で、下が「おぅ、わかった」の返答。 「おぅ、わかった」の返答のパケットの受信確認番号を見てみると 「データくれ！」のパケットのシーケンス番号を使っています。 08:59:09.123915 www.kaisha.co.jp.http > test.kaisha.co.jp.1059: . 506903625:506905085(1460) ack 1939411 win 6432 (DF) 「データくれ！」の要求がきたため、「おぅ、わかった」の返答に続いて送る 実際のデータ（パケット）の流れ。 「データくれ！」の返答なので、受信確認番号は「データくれ！」のパケットの シーケンス番号を使っています。 シーケンス番号は、「データくれ！」のパケットの受信確認番号に 送信するデータ（ここでは1460バイト）を足した数字になる。 08:59:09.123963 www.kaisha.co.jp.http > test.kaisha.co.jp.1059: . 506905085:506906545(1460) ack 1939411 win 6432 (DF) 実際のデータを送る際、そのままの大きさで送らずに、パケットを ある大きさに区切って送っています。1回、1回、送信、返答の繰り返しだと 効率が悪いため、2、3個のパケットを同時に送信しています。 ここでは、区切って送るデータの第２弾です。 もちろん、「データくれ！」の返答なので、受信確認番号は「データくれ！」の パケットのシーケンス番号を使っています。 送信するシーケンス番号は、第１弾のデータのパケットの返答で使われる 受信確認番号にパケット長さ（ここも1460バイト）を足した数字を使う。 第1弾のデータのパケットの返答で使われる受信確認番号は、 第1弾のデータ送信パケットのシーケンス番号と全く同じなので、 例え、応答がなくても簡単に割り当てられる 08:59:09.128605 test.kaisha.co.jp.1059 > www.kaisha.co.jp.http: . ack 506906545 win 8760 (DF) 第2弾のデータ送信パケットが無事、届いたという返答。 あれっ？ 第1弾が無事、届いたという返答は、まだのようです (^^;; こんな感じで、Webを見る側と、ＷＷＷサーバーとのやりとりが行なわれます。 |
正直な所、目が痛くなる感じがした。 ふぅ、これを調べたので疲れた。でも、やれやれと思っていたら、 FINの場合も3Wayシェイクハンドと似た事が起こる。 ウギャ─！！ やめてくれー （ＴＴ） もう、嫌。うんざりしてきた・・・ （ＴＴ） でも、押さえておかなくてはいかない点なので、簡単に説明します。
| 接続終了の時のシーケンス番号と受信確認番号について |
|
Web閲覧側が最後のデータ─パケットを受け取り、それの返答をする。 Webサーバーは返答を受け取った後、送信終了のフラグ（FIN）を送る。 Web閲覧側は、FINのフラグを見て、接続が終了だと認識する。 そして、FINを受け取った合図を送る。 その時、FINが含まれたパケットのシーケンス番号に1を足した数字を 受信確認番号として、Webサーバーに応答を返す。 |
| 念のためパケットの動き |
08:59:17.038516 test.kaisha.co.jp.1059 > www.kaisha.co.jp.http: . ack 506925453 win 7372 (DF) 08:59:25.147241 www.kaisha.co.jp.http > test.kaisha.co.jp.1059: F 506925453:506925453(0) ack 1939411 win 6432 (DF) Web閲覧側が最後のデータを受け取った合図を送る。 そして、Webサーバーが受け取った合図を知り、接続終了の合図を送る。 08:59:25.147241 www.kaisha.co.jp.http > test.kaisha.co.jp.1059: F 506925453:506925453(0) ack 1939411 win 6432 (DF) 08:59:25.148011 test.kaisha.co.jp.1059 > www.kaisha.co.jp.http: . ack 506925454 win 7372 (DF) Webサーバーが接続終了の合図を送る。 そして、Web閲覧側が接続終了の合図を受け取った事を知らせる。 |
混乱だらけのシーケンス番号と受信確認番号。 でも、受信確認番号の決定方法に、1つの法則性は見つけた！
| SYNやFINなど、バイト数が0のパケットを投げた時の返事 |
|
返事としてやってくるパケットの受信確認番号は、 投げたパケットのシーケンス番号に1を足した数字になる。 |
| その他のパケットを投げた場の返事 |
|
返事としてやってくるパケットの受信確認番号は、 投げたパケットのシーケンス番号の数字になる。 |
これだと、パケットの流れを見た時、辻褄が合う。 フフフ。ちょっと賢くなった気分 (^^) ところで、動的フィルターはTCPだけでなく、UDPでも使える。 UDPにはシーケンス番号や、受信確認番号というものがない。 どうやって判断しているのか？ いくら考えても推測すらできませんでした (--;; もちろん、TCP通信でも、動的フィルターが見分けるのに、 シーケンス番号や、受信確認番号を使っているのは、あくまでも私の推測です。 真相はヤマハに聞くしかなさそう・・・。 さて、動的フィルターのブラックボックスを探る話は、これぐらいにして、 次の話題へ飛びまーす！！ さて、DNSサーバーを公開する場合は、動的フィルターは、どうなるのか？ ゾーン転送でTCPを使う場合は、同じ設定でOKだが、 それ以外は、UDPでの通信のため、TCP通信のように、静的フィルターは SYNだけ通して、ACKをカットする設定はできない。 例え、そのような設定しても、UDPにはACKやSYN信号がないので無意味。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 35 | |
|
pass | しない | udp | ＊ | ＊ | XXX.YYY.ZZZ.BBB | 53 | DNS Server |
| 動的フィルターの一覧 | ||||||||||
| 番号 | 適用 | プロトコル | 送信元 | 送信先 | メモ | |||||
| 入 | 出 | 監視 | 逆方向 | 順方向 | IPアドレス | IPアドレス | ||||
| 81 | |
|
domain | ＊ | ＊ | DNS Server | ||||
この場合は、静的フィルターは許可せざる得ない・・・。 動的フィルターと静的フィルターの組合わせ。 LAN内にサーバーを構築した場合のパケット通過は理解できた。 次に、LAN内から外のサーバーへ見に行く場合はどうなるのか？ その時も、静的・動的フィルターのコンビネーションが活躍する。 今回は、先に結論から書くことにした。 パケットの第1弾は静的フィルターを通過して、他は動的フィルターでチェック。 そこで、第1弾のパケットを通過させれば話は簡単。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 99 | |
|
pass | しない | ＊ | ＊ | ＊ | ＊ | ＊ | pass all |
静的フィルターで外部に出るパケットは全て外に出る設定にする。
あとは動的フィルターの設定さえすればOK。非常に単純 (^^)
（注意） もちろん、外へ出してはいけないパケットもあるので、
この設定の番号「99」より若い番号でフィルターをかければＯＫ。
結論的には簡単みたいだが、ここに行き着く過程は単純ではなかった。
さて、最初、本に書いている設定法を見た時、私は驚いた。
RTA52iの時に設定していたestablishedを通過させない設定だった。
その変わりに動的フィルターが監視しているという。
最初、どうして、そうなるのか、全く理解できなかった。
一応、本には書いてあった。
|
外部のサーバーへ接続する時の 動的フィルターと静的フィルターの働き |
 |
| 外へ出るパケットを動的フィルターが記録する。 そして、返答で戻ってきたパケットを動的フィルターがチェック。 LAN内から出たパケットの返答なら通過させる。 そうでない場合は、静的フィルターのチェックに委ねる。 （注意） 返答パケットでも、一定時間が過ぎた返答が遅いパケットは破棄される。 |
最初、これを見た時、巧妙だなぁと感心した (^^) そして、動的フィルターと静的フィルターの役目が、わかった気になった。 実は、こういう時は、全くわかっていないケースが大半だけど・・・。 ところで、よく考えると、外へ出たパケットを記録しても、やってきたパケットが 外へ出たパケットの返答なのか、それとも別のパケットなのか？ どうやって見分けるのか。この時点では、全くわからなかった。 今もハッキリした事は断定できないが、TCPについては推測できる。 動的フィルターが記録するであろう物は、パケットの発信元、接続先がある。 後は何があるのか、わからなかったが、編集時に、TCPへッダーに シーケンス番号と受信確認番号がある事を知った。 そこで、動的フィルターは、外へ出たパケットのシーケンス番号を記録して、 戻ってきたパケットの受信確認番号と、記録されているケットのシーケンス番号を 照合して、合致すれば、返答ポケットと言える。 実際の所、動的フィルターが、どのデータを記録しているのかは、定かではないが、 少なくとも、外へ出たパケットのシーケンス番号と、戻ってきたパケットの 受信確認番号との照合をしていると考えられる。 でないと、送信元や送信先のIPやポートの照合だと、なりすましなど、 簡単にされると考えられるからだ。 戻ってきたパケットを受け入れる方法。 もし、静的フィルターの設定だけで行なうと、establishedを通過させる設定になる。 しかし、動的フィルターと連動させるため、establishedは使わない。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 31 | |
|
pass | しない | established | ＊ | ＊ | XXX.YYY.ZZZ.RRR/29 | ＊ | Established |
動的フィルターと静的フィルターの組合わせでできるようになったから、 establishedは使う必要がなくなったと言えば、それまでだし、 私は、establishedの設定が必要がなくなったからだと思っていた。 しかし、他に、重大な理由があった！！
| establishedの弱点 |
 |
| establishedは、外へ接続した際、接続先からの返答パケットを 受け入れる設定に使われる。 この場合、ACKを含むパケットなら何でも受け入れを意味する。 もし、悪い奴がACKを含むパケットを送り込んだら、為す術がない establishedの弱点と言える。動的フィルターの導入のお陰で、 弱点は解消されたといえる。 （ちょっと蛇足） 黒いネコの絵の感じですが、実は、悪魔のつもりで描きました。 絵心が全くないので、黒ネコになってしまいました・・・ (^^;; |
うーん、セキュリティーの問題は、いたちごっこだなぁと思う。 ここで、混乱したのはFTPの場合だった。 外部へアクセスする場合、コマンドなどのやりとりはポートは21。 データはPORTモードだと20。PASSIVEモードだと任意のポートになる。 コマンドとデータ送信のポートが違う上、2つのモードがあるため、 個々に設定する必要があるのではないかと思ったが、いらぬ心配だった。 FTPの場合、極めて単純な設定だった。 パケットの第１弾を通過させれば、あとは、モードがどうであれ、 動的フィルターが監視してくれる。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 99 | |
|
pass | しない | ＊ | ＊ | ＊ | ＊ | ＊ | pass all |
| 動的フィルターの一覧 | ||||||||||
| 番号 | 適用 | プロトコル | 送信元 | 送信先 | メモ | |||||
| 入 | 出 | 監視 | 逆方向 | 順方向 | IPアドレス | IPアドレス | ||||
| 80 | |
|
ftp | ＊ | ＊ | ftp | ||||
こんなに単純にできてしまう。 モードの違いや、ポートの違いで悩んでいた自分がアホみたい (^^;; そのため、RTA52iで開けていたポート20を、開ける必要がなくなる。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 33 | |
|
pass | しない | tcp | ＊ | 20 | ＊ | ＊ | ftp-data |
実は、FTPのセキュリティーの問題で、PORTモードだと ポート20を開けるため、侵入されやすいと言われている。 外部にFTPをする際は、PORTモードだと、どうしてもestablishedと同様、 フィルターで通過設定させておく必要があった。 しかし、動的フィルターのお陰で、その心配もなくなった。 動的フィルター。UDPのプロトコルのDNSにも適応できる。 外部のDNSサーバーを見に行く際も、動的フィルターが記録していて 返答のパケットかどうかチェックできる。 そのため、次のような設定もいらなくなる。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 35 | |
|
pass | しない | udp | ＊ | 53 | XXX.YYY.ZZZ.RRR/29 | ＊ | DNS |
外部のDNSから発信された返答のパケットは動的フィルターがチェックするので 静的フィルターを外すことが可能になる！ 動的フィルターにお陰で、静的フィルターのチェックを外すことができるので、 静的フィルターが身軽になっている感じがする。 動的フィルター。凄い機能だなぁと感心してしまう。 この際だから「全てのパケットを動的フィルターで監視してしまえ！」 と思いたくなるが、そうは簡単にいかない。 RTA55iの場合、次のパケットが動的フィルターの設定ができる。 FTP,DNS,WWW,SMTP,POP3,TCP,UDP 私は、TCPとUDPを見た時「なんだ、全てのパケットが対象やん」と思ったが、 それは認識の誤りだった。 FTPやWWWなど、個別にあるのは、各アプリケーションのデータを見て、 不正パケットかどうかチェックしているが、TCP、UDPは漠然としているだけに アプリケーションに依存していないが、最低限の事しかチェックしていない。 さて、RTA52iのルーターの設定の部分で、後述すると書いたICMPについて。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 30 | |
|
pass | しない | icmp | ＊ | ＊ | XXX.YYY.ZZZ.RRR/29 | ＊ | ICMP |
ICMPのプロトコルの通信は受け入れの設定にしている。 そもそもICMPとは何なのか？ 本には ping コマンドのプロトコルと書かれているが、それだけだと 「だから、何やねん！」となる (^^;; 本には「IP上で動作する、IPとは全く独立したプロトコル」と書いている。 でも、これを読んでも 「だから、何やねん！」となる (^^;; 逆に、pingコマンドで「ping IPアドレス」をしているのに、 IPと独立したプロトコルで動くと思うと、余計に混乱していた (^^;; ICMPのデータ構造を見てみた。
| ICMPのデータ構造 |
 |
これを最初に見た時、「IPへッダー」は目に入らなかった。（この手のミスが多い私） そのため「IPの情報も何もないのに、どないして通信するねん」と混乱した。 (--;; ドツボにハマるのは、毎度の事だが、大抵は、ドツボにハマっても理解できるまで、 ゆっくり構えようと思うが、今回は、編集中に理解しなければならない。 今年になって、次から次へと失敗談や、無知、誤解などが噴出しているため、 どんどん編集していかないと、私の記憶が消えてしまう。 いわば、記憶のタイムリミットという〆切がある。 頭を抱えてしまったが、とりあえず、IPの情報を横に置いて、 ICMPタイプと、コードを見ることにした。
| ICMP タイプ |
コード | 意 味 | 問い合わせ | エラーレポート |
| 0 | 0 | エコー応答 | ○ | - |
| １ | 0 | ネットワークへのアクセス到達不能 | - | ○ |
| 1 | 相手先のコンピューターへのアクセス到達不能 | - | ○ | |
| 2 | プロトコルは到達不能 | - | ○ | |
| 3 | ポートは到達不能 | - | ○ | |
| 以下省略します m(--)m | ||||
この表を見ても、最初は、pingコマンドと表とが結び付かなかった。 困ったなぁと思いつつ、ICMPに関するホームページを漂うことにした。 ping の解説で「ping を発信する時のパケットは、タイプ８のエコー要求で 相手が見つかった時は、タイプ0の応答を返す」と書いていた。 表を見たら、確かに、タイプ8は ping のエコー要求になっている。 そして、タイプ0は、エコーの応答になっている。 ここで始めて意味がわかった。 タイプとコードで、ICMPパケットの中身の意味がわかる。 それは、ネットワークの状況がわかる事につながる！
| ping コマンドの結果 |
[server]# ping www.kaisha.co.jp PING www.kaisha.co.jp (AAA.BBB.CCC.RRR) from XXX.YYY.ZZZ.AAA : 56(84) bytes of data. 64 bytes from www.kaisha.co.jp (AAA.BBB.CCC.RRR): icmp_seq=1 ttl=240 time=34.6 ms 64 bytes from www.kaisha.co.jp (AAA.BBB.CCC.RRR): icmp_seq=2 ttl=240 time=33.4 ms |
pingコマンドを打てば、上のような結果が出てくる。 解説には、pingを打って、応答エコーが返ってくるだけでなく、 生存時間（TTL）と、パケット到達時間も返ってくる。 パケット到達時間は、ping コマンドを打った時に、 タイプ13のタイムスタンプ要求が設定されていて、相手先に届けば タイプ14のタイムスタンプ応答が返ってくる仕組みだという。 生存時間は、ICMPパケットにあるIPへッダーのTTLが ルーターや中継マシンを一つ越えるごとに、数が１づつ減っていく。 この場合、初期値が255なので、240の場合、15ヶ所を経由したことになる。 実は、この時、ICMPパケットにIPへッダーがあることに気づいていなかった。 ただ、TTLの初期値が255で、中継の度に、値が1づつ減る事を知って、 「へぇ〜」と感心していた。 TTLが0になると、その時点で、到達不能のパケットを返すことや、 到達時間が一定時間を越えると、到達不能のパケットを返す事が書いていた。 でも、TTLが30もあれば、インターネットで、大抵の所へ行けるみたい。 身近な ping だが、色々な発見をしたので、奥が深いなぁと感心する。 色々、調べているうちに、再び、ICMPのへッダーを見る機会があった。 この奮闘記にへッダーの絵を載せるためだった。 絵を書いている時に「IPへッダー」が目の中に入ってきた。 ようやく、ここでIP通信している事が認識できた (^^;; 本を読むだけではダメ。写す作業も大事だなぁとふと思った。 写経には、手で覚える意味合いがあるのかなぁ？ さて、身近な ping 。でも、身近なものでも凶器にする輩がいるから 困ったものだと思う。
| Smurf Dos攻撃 |
 |
| ping を打つ時、発信元のIPアドレスを偽造して、 攻撃対象のホストのIPに書き換える。 そして、ブロードキャストで同じLAN内のホストにpingを打ちまくる。 それの返答が攻撃先のホストへ行く。 もし、LAN内に100台など大量にホストがあるとすると、 攻撃されるホストには、大量のパケットが流れ込むため通信不能に陥る。 |
IP偽造は、恐い話だ。IP偽造が出てきたので、それに関連する話。
| LANＤ攻撃 |
 |
| パケットを送信する際、発信元と発信先のIPアドレスを偽造して、 攻撃対象のホストのIPに書き換える。 パケットを受け取ったホストは、送信先が自分自身なので、自分自身に送ろうとする。 しかし、受け取るのも自分自身なので、それに対して応答しようとする。 そして、無限地獄に陥り、通信不能になってしまう。 （注意） これに関しては後述していますが、RTA55iでは対策済みだそうです |
こんな事を書くと「だったら、ICMPを閉じれば済むやん」と言われる。 そこで、一度、ICMPを閉じてみた。
| 静的フィルターの一覧 | ||||||||||
| 番号 | 適用 | タイプ | ログ | プロトコル | 送信元 | 送信先 | メモ | |||
| 入 | 出 | IPアドレス | ポート | IPアドレス | ポート | |||||
| 30 | |
|
pass | しない | icmp | ＊ | ＊ | XXX.YYY.ZZZ.RRR/29 | ＊ | ICMP |
ICMPを閉じた上で、外部のホストに ping を打ったが、返答はなかった。 いつもなら「返答があらへん（ＴＴ）」となりそうだが、今回は、 予測していたので、「やっぱり」という感じだった。 ICMPはTCPでも、UDPにも属さない。 もちろん、動的フィルターの設定にICMPはない。 もし、外部に対して、ping や traceroute コマンドを使う際には、 静的フィルターでICMPを開けておく必要がある。 そうでない場合は閉じても問題はない。ここは使う人の判断に委ねられる。 ふぅ、ICMPについても書くことが出来たので、やれやれと思った。 が、まだ、残っていました！！ 動的フィルターの役目で、侵入者検知機能があることを！！ さて、RTA55iの場合、次のパケットが動的フィルターで監視することができる。 FTP,DNS,WWW,SMTP,POP3,TCP,UDP 結構、色々な監視をしてくれる。 そして、侵入パケット破棄の設定をすれば、パケットを破棄してくれる。 （ただし、例外もある：例外は後述しています） 一応、TRA55iの不正パケット破棄の設定画面をつくってみました。 画像を載せるよりも、データ量は少ないので、結構、ダグで作るのも良い感じ。
| 表示インターフェイス | |
| インターフェイス情報（PP01） | プロバイダー接続に使用しています。 設定名：某プロバイダー |
| 切替 | |
| 不正アクセス検知機能（メール通知機能） | |
| 入力方向の機能選択 | 有効にする
不正アクセスを検知したとき破棄する |
| 出力方向の機能選択 | 有効にする
不正アクセスを検知したとき破棄する |
まずは代表的な侵入者として、ポートスキャンから。 ポートスキャン自体は害はないのだが、攻撃先を探す手法として知られている。 お目当てのホストがあるかどうか確認するため、SYNだけのパケットを送り ACKが返ってくるかどうか確認したり、ACKのパケットを送って RSTなどが返ってくるかどうか調べる。 返答のパケットが返ってくれば、お目当てのサーバーがあることになる。 まぁ、空き巣で例えると、玄関でピンポンを鳴らして、家の人が応対すれば 中に人がいるため、諦めるが、誰も出なければ、留守が確認できるというのと同じ。 ただし、TCPポートスキャン、UDPスキャンについては パケット破棄の設定を行なっても、破棄されない。 理由は、ヤマハのホームページに書かれていた。 侵入検知器の誤検出の可能性があるためのようだ。 特に、ポートスキャンの完全な検出は難しいようだ。 逆に、誤検出の可能性が低いものとして、先ほど挙げたLAND攻撃がある。 IPアドレスの発信元と送信先を攻撃対象にして、無限地獄に追い込む攻撃。 これは、誰がどう考えても、誤検出などあり得ない。 そのため、LANDについては、例え、パケット破棄の設定を外していても LAND攻撃のパケットは破棄される。 ルーターが検出できる物の大半は、破棄するかどうかは、ユーザーの設定次第。 その一つが「SYNフラッド攻撃」 悪意のある攻撃元は、攻撃先のホストにSYN信号を連発する。 攻撃先は、せっせとSYNとACK信号を返すが、もちろん、攻撃元は それに対するACKを返さない。 ACKが返ってこないので、攻撃先のホストは、何度も、ACKを送る。 その上、降り注いでくるSYNに対処するため、攻撃先のホストはパニックに陥る。 そして、ついにダウンしてしまうという攻撃だ。 詳しい事はヤマハのルーターの技術関連のページに掲載されています。 （ＵＲＬ）http://www.rtpro.yamaha.co.jp/RT/firewall/index.html さて、どれだけ侵入者が来ているのかログをとってみた。
| 侵入者のログ（一部を抜粋） |
2003/XX/YY 23:22:38: ICMP too large ************** > XXXXXXXXXXXXX 2003/XX/YY 23:16:43: TCP FIN and no ACK ************** > XXXXXXXXXXXXX 2003/XX/YY 10:45:21: TCP SYN and FIN ************** > XXXXXXXXXXXXX 2003/XX/YY 17:48:47: TCP SYN flooding ************** > XXXXXXXXXXXXX 2003/XX/YY 11:33:21: ICMP source quench ************** > XXXXXXXXXXXXX 2003/XX/YY 15:16:43: TCP port scan ************** > XXXXXXXXXXXXX 「*************」は攻撃元のIP。 「XXXXXXXXXXXXX」はうちの会社のホストのIP |
|
はじめ、RTA55iでログをとりだした時、結構、うちの会社に攻撃が来ているので 油断はできねぇーなぁと思った。 以前から、ルーターの外は戦場と聞いていたが、ログを見て改めて実感した。 |
侵入者検出の役目もあり、必要の応じてパケットを破棄できる。 3万5千円くらいの価格の割りには、性能は立派なもんだと感心する。 さてさて、膨大な文章になってしまったが、それだけ奥が深いことを意味する。 それプラス、私の知らなかった事、誤解していた事も多いことも意味する。 無事、RTA55iへ移行できたと思いきや、実は、まだ、話があります。 ISDNからADSLへ移行時に、悲劇をみました。 それについては、次章で紹介することにします。
ここでまとめ ルーターの設定。再勉強している間だけでなく、失敗談の編集の段階でも、 知らなかった事、誤解していた内容が噴出。 だんだん私の力量では手に負えないと不安になってきましたが、 なんとか、ここまで辿り着けました (^^;; NetBIOS over TCP/IP については、この話に入れるのには大きすぎるため、 「システム奮闘記：その17」にて、独立した章として、分けて書きました。 TCP/IPの階層構造や各レイヤーでの振る舞いの話も、 当初は書くつもりでしたが、話が大きくなってきたため、今回は割愛しました。 いずれ「仁義なきパケット送信の戦い」（仮題）で取り上げます。 DNSのゾーン転送をはじめとする話も、いずれ取り上げたいです。 それにしても、ヤマハのルーター（RTA55i）は価格は3万5千円ぐらいで 比較的、安価なルーターだが、機能の凄さと奥の深さに、さすがだと思いました。 ちなみに、中古のパソコンでLinuxを入れてADSLルーターにできます。 だけど、知識のある人以外は、ヤマハのルーターなどの購入をお勧めします。 設定の難易度だけでなく、セキュリティーの問題もあり、 市販のルーターを使う方が無難と言えるからです。 最後に、私の体験談として、ネットワークの本を読みながらの、 ルーターの設定は、非常に勉強になります。 もし、私のように本の丸写しで設定された方は、TCP/IPの本を片手に 勉強されるのをお勧めします。