パケットフィルタリングまず、パケットフィルタリングについて簡単にメモします。
TCP/IP の世界では、ネットワーク上を流れるデータのことをパケットと呼びます。
このパケットにはアプリケーションデータはもちろんのこと、それ以外にも
ポート番号、IP アドレス、MAC アドレス などのヘッダー情報が格納されています。 ルータやスイッチは、これらの情報をもとにネットワーク上のホストやサーバにパケットを転送させていますよね。
しかし、送られてきたパケットをそっくりそのままホストやサーバへ転送してしまうと、それはセキュリティ面としては好ましくありません。 もしそのパケットが悪意あるものだった場合、それが原因でコンピュータウイルスに感染してしまうなど、予期せぬトラブルを起こしてしまう恐れがあります。
そこでルータやスイッチなどのネットワーク機器は、パケットの中からヘッダー情報を取り出して検査します。
「このパケットは通しても大丈夫」 「このパケットは危なそうだから破棄しよう」 といったようにです。
こういったパケットの通信をコントロールする機能のことを、総称してパケットフィルタリングと呼びます。
↑図1：Web サーバへの不正アクセスを防ぐ
一括りにパケットフィルタリングといっても、その細かな種類はたくさんあります。
僕もまだパケットフィルタリングの種類を網羅しきれていませんが、今回メモしていく iptables はパケットフィルタリングの中でも 「
固定なパケットフィルタ」 に入るようです。
他には 「
動的なパケットフィルタ」 というモノがあります。
これはヤマハルータを使ったことがある方なら分かると思いますが、
ip filter dynamic というコマンドがありますが、まさにコレですね。
また、それ以外にも 「
ステートフルパケットインスペクション (SPI) 」というモノもあります。
こちらは Century Systems 社のルータを使っているとよく見かけますが、正直まだよく分からずに設定しています。。
…にしても僕は情けないです。
まだ静的パケットフィルタの “さわり” しかメモしていないのに
さっそくもう疲れております…。こんなに疲れということは、自分がセキュリティに対していかに
ノーマーク であったかがよく分かります。
インフラまわりのプロになるためには情報セキュリティは必須でしょうから、今後は情報セキュリティに関する記事が増えていきそうな予感です…。
Netfilter とはそもそも iptables ってなんでしょうか。
冒頭には 「iptables はファイアウォールコマンド」 と書きましたが、厳密には 「
パケットフィルタ設定コマンド」 と言えます。
もっと細かに言いますと NAT なども設定できるようですが、今回はパケットフィルタのみに重点を当てます。
と、なりますと 「パケットフィルタリングしたければ iptables を編集すればいい」 と結論になりますね。
しかし、そこで納得してコマンドの記述方法のメモをすれば良かったのですが…そうもいきませんでした。
ネットで iptables について調べていたところ、
yahoo 某知恵袋 にて以下のような文章を発見しました。
「実は、iptables自体が
Netfilter と言うカーネルモジュールのフロントエンドと言うオチだったりする。」
………
Netfilter ってなにさ。。。
気になってしまっては、そこを追究 （
したくないのにしてしまう性分…orz） してこそインフラまわりのプロに一歩近づけます。
そういったことから、まずは Netfilter について調べることにしました。
さっそく find コマンドから netfilter を検索してみたところ、
/lib/module/ ディレクトリの配下に netfilter に関連しそうなディレクトリがありました （今回の検証マシンは CentOS 6.3 でございます）。
[gen@chan ~]# find / -name netfilter
...
/lib/modules/カーネル名/kernel/net/ipv4/netfilter
/lib/modules/カーネル名/kernel/net/ipv6/netfilter
/lib/modules/カーネル名/kernel/net/netfilter
/lib/modules/カーネル名/kernel/net/bridge/netfilter
...
|
普段 /lib/modules ディレクトリに触れる機会がないので知りませんでいたが、このディレクトリ (/lib/modules/カーネル名) こそが Linux のモジュールが保存されるディレクトリのようです。
またモジュールの拡張子は 「
.ko」 とのことで、前述の ipv4/netfilter/ ディレクトリ配下を確認したところ、まさにそのモジュールたちが格納されていました。
↑図2：右側の黄緑色の文字列がモジュール名
「
iptable_filter.ko」 や 「
ip_tables.ko」 などは、まさに iptables に関連したモジュールに思えますし、「
nf_nat_ftp.ko」 や 「
nf_nat_sip.ko」 は NAT 関連の動作をしてくれるモジュールに思えます。 迷子になりそうな /lib/module/ ディレクトリの中から、こういったモジュール名を発見するとちょっと嬉しいですね。
以上のことから、こういったパケットフィルタ機能の役割となるモジュールが netfilter であり、
iptables はあくまで netfilter を設定するコマンドにすぎない ことが分かりました。
iptables はデーモンを持っていますので、すっかりパケットフィルタリングや NAT を実現させるプログラムやモジュールだと思っていましたが、そうでは無かったようです。 ここでようやく 「
iptables が netfilter のフロントエンド」 という意味が理解できました。
↑図3：iptables と netfilter の関係
個人的にこの収穫 (iptables は netfilter を操作するコマンドである、という理解) は大きいと思いました。
モジュールやカーネルについて、もう少し追求していきたいとは思いますが、今回は iptables についてのメモであることから、前述のメモに関しては別の機会に書いていこうと思います。
フォワーディング有効iptables コマンドを理解する前に、テスト環境を構築したときのメモを残します。
ヤマハルータのパケットフィルタリングのように 「受信と送信」 だけの 「
チェイン」 があればテスト環境を構築しなくても済んだのですが、iptables には 「転送」 というチェインもあったので、セグメントを分けたテスト環境を作る必要がありました。
しかし困ったことに Linux 機に LAN インターフェースを2つ設定しただけでは、セグメントを跨いだ通信が上手く確立してくれなかったのです。
↑図4：ちなみに上記は Hyper-V の仮想環境
調べたところ Linux では、パケットのフォワーディングをデフォルトで
無効 にしているようです。
このように、ただただ Linux に NIC を複数搭載してルーティングを書けば Linux ルータの完成……というわけではなく、いくつかの初期設定が必要のようです。 近い将来、Linux の理解を深めるためにも
Linux ルータ を作るつもりでいましたので、その前準備として今回メモしていきます。
まず初めに
/proc/sys/net/ipv4/ip_forward に
1 を代入します。
/proc はプロセス情報などが記載されたディレクトリですが、その中の /proc/sys/net/ ディレクトリ配下の各種フラグを操作することで Linux のネットワーク機能をカスタマイズできるようです。 ipv4/ ディレクトリは IPv4 に関する設定で、ip_forward はその名の通り IP パケットのフォワーディングを許可する設定でした。
| [gen@chan ~]# echo 1 > /proc/sys/net/ipv4/ip_forward |
次に
/etc/sysconfig/network ファイルに対して
FORWARD_IPV4=yes を追加します。
/etc/sysconfig/network ファイルは、ネットワークの基本的な設定を行うファイルですね。
むかしむかし、このファイルの存在を一切知らず 「network-scripts/ifcfg-eth0 に IP アドレスを書き込んでいるのに、なんで通信できない!?」 と嘆きまくっていたことがありました。。
[gen@chan ~]# vi /etc/sysconfig/network
...
FORWARD_IPV4=yes |
そして最後に
/etc/sysctl.conf ファイルの フォワーディングフラグを ON にします。
sysctl とはなんぞや というレベルなのですが、これは Linux カーネルのパラメータを色々と弄れる機能のようです。 iptables のようなコマンドなのか、または Netfilter のような実体なのかは分かりませんが、Linux ユーザとしては知っておくべき機能であることは間違いなさそうです。。
[gen@chan ~]# vi /etc/sysctl.conf
...
# Controls IP packet forwarding
net.ipv4.ip_forward = 1 |
以上、これら設定を適用させますと Linux がパケットをフォワーディングしてくれます。
……とはいってもここだけの話、最初は上記の設定を施しても Ping がフォワーディングしませんでした。
（なんで転送されないの!?） と頭を抱えながら調べること約1時間。 なんとなく iptables のデーモンを切ってみたところ、アッサリと Ping が通ってくれました。
まさに (・ω・`?) みたいな顔をしながら iptables 設定を確認したところ、なんと
-A INPUT -p icmp -j DROP （Ping を一切受け付けない） という一行が書かれていました。 どうやらテスト環境を構築する前に施した設定を消し忘れていたことが原因でした。 なんというボンミスw OTL
入力方法の違いここでは iptables の
入力方法の違い についてメモしていきます。
iptables を設定するとき、以下の2種類の設定方法があります。
1．iptables コマンドを使う
2．/etc/sysconfig/iptables ファイルに直接書き込む
僕はいつも 「2」 の方法で iptables を設定しています。
ただシステム的には 「1」 の方法が推奨されているようですが、僕は 「2」 の方法しか知らなかったのでその違いが分かりませんでした。
そこで以下に 「1」 の方法で iptables コマンドを実行してから一通り動作するまでの方法をメモします。
まず iptables コマンドを実行すると
メモリ上 のある領域に保存されます。
パケットフィルタリングを行う Netfilter モジュールは、そこを参照しているようです。 実行した iptables ファイルは、この時点で動作に反映されます。
↑図5：iptables コマンド実行後は、適用されるも保存はされない
しかしこのままでは OS を再起動すると iptables の設定ファイルが消えてしまいます。
そこで
/etc/init.d/iptables save コマンドから iptables の設定ファイルを
揮発性領域 へ保存する必要があります。※揮発性領域はたぶん HDD だと思う。たぶん。。
このとき動作するプログラムは iptables-save というもので、これは /etc/sysconfig/iptables ファイルに現在の設定を書き込むのと同時に、書き込まれる前の iptables ファイルを
iptables.save というファイルに保存してくれます。
↑図6：iptables-save プログラムによって再起動後も設定が生かされる
この状態になれば OS を再起動しても iptables の設定ファイルが消えることがありません。
次回起動時には iptables-restore コマンドが実行され、/etc/sysconfig/iptables ファイルがロードされますので、自動的に前回保存した iptables ファイルが反映されます。
↑図7：iptables-restore プログラムによって再起動後に設定が反映される
以上が 「1」 の iptables の動きですね。
ここまでの一連の流れを追ってみて分かったことは、「2」 の /etc/sysconfig/iptables に直接書き込むという戦法（？）は 「図7」 を直接実行していることと同じになります。
ただ 「2」 の方法で iptables ファイルを適用するには /etc/init.d/iptables restart を実行する必要がありますし、「図5」のように仮の設定がすっ飛ばしていきなり本番稼動になるのでリスクは大きそうです。
ということは、
1．iptables コマンドを使う → 慎重な人
2．iptables ファイルを変更 → 面倒くさがりな人
という方程式が成り立つと言うことになりますね。
ぼかぁ生粋の面倒くさがりやなので、胸を張って後者の設定方法を愛していこうと思います（笑）。
チェイン本メモを書いていくなかで
チェイン という言葉が何度か出てきたと思います。
ここではチェインの意味を書いていきます。
チェインを一言でたとえるなら 「
どの動作のパケットをフィルタリング対象とするか」 と僕は思っています。
チェインには3種類ありまして、以下のチェインを見ればなんとなく意味が通じると思います。
・INPUT
・OUTPUT
・FORWARD
上から順に 「
受信・送信・転送」 を意味します。
パケットを受信したときにフィルタリングしたければ、チェインは 「INPUT」。
パケットを送信するときは 「OUTPUT」 チェインになり、転送する場合は 「FORWARD」 チェインになります。
以下、3チェインを図にしたものです。
↑図8：input output forward チェイン
INPUT チェイン は、マシンからみれば 「自分自身宛」 のパケットがフィルタリングの対象となります。
図8で言うと PC1 から PC2 へ投げた通信は、PC2 から見ると全て INPUT チェインになります。 例えば PC2 が PC1 から SSH 通信を受けたくないときは、PC1 からの INPUT チェインに SSH 遮断のルールを加えることで、PC1 からの SSH 通信を破棄することができます。
OUTPUT チェイン は、マシンからみれば 「自分から送信した」 パケットがフィルタリングの対象です。
図8で言うと PC2 から投げる通信は PC2 から見ると OUTPUT チェインになります。これは INPUT の逆だと思えば理解が早いと思います。
FORWARD チェイン は、マシンからみれば 「自分を経由する」 パケットがフィルタリングの対象です。
図8で言うと PC1 から PC3 へ投げた通信は、PC2 から見ると 「自分を経由する」 ために FORWARD チェインになります。
あと iptables で NAT を実現させるためには、以下のチェインが使われるようです。
・PREROUTING
・POSTROUTING
余談ですが、個人的には FORWARD チェインの理解に一苦労しました。。
今はチェインの動きの整理できているので大丈夫ですが、自身初となるパケットフィルタリングを設定したヤマハルータでは 「IN/OUT」 の組み合わせだけで FORWARD を実現させていましたので、FORWARD チェインが現れたときは 「
！？！？！」 となったのを記憶しています。。OTL
iptables コマンドの理解ここでは iptables コマンドを理解していきます。
とはいっても、個人的に理解できない iptables コマンドの疑問を追求していきますので、相変わらず
コマンドリファレンスとしては役立たない メモとなっておりますｗ (///)
まず、最低限の iptables コマンドの書き方をメモしていきます。
（前述もしたように、今回は /etc/sysconfig/iptables ファイルを直接書き換える方法を前提にメモしていますが、どちらもコマンド形式に大差はありません）
| -A INPUT -p icmp -j REJECT |
「
-A」 について、これはチェインに対するルールの操作を意味します。
この場合は INPUT チェインに対して何をどうするかを問われていますので、「-A」 を指定して INPUT チェインを追加しています。このほかに 「-D」 は削除の動作をするなどオプションは沢山ありますが、今回のように iptables ファイルを直接参照する場合は 「-A」 が大半を占めそうですね。
「
-p」 は、プロトコルを意味します。
言うまでもなく、フィルタリングの対象となるプロトコルを示してます。 同じく上記の例では ICMP プロトコル通信のみに適用されるルールですね。
「
-j」 は、そのパケットのフィルタリング処理を意味します。
ルールにマッチしたパケットを許可する場合は 「-j ACCEPT」 と書き、パケットを破棄させる場合は 「-j DROP」 または 「-j REJECT」 と書きます。ちなみに -j は jump の意味のようですね。
以上が、とっても基本な iptables の書き方です。
また、以下はパケットが送受信されるインターフェースと、パケットの送信元 IP アドレスを指定した書式です。
-A INPUT -p icmp -i -eth0 -j REJECT
-A INPUT -p icmp -s 10.1.1.1 -j REJECT |
「
-i」 は、インターフェースを意味します。
図4（または図8） の環境で検証していますので -i は eth0 ポート、すなわち 10.1.1.254 から受けたパケットのみルールが適用されます。
「
-s」 は、送信元 (source) IP アドレスを指定しています。
このテスト環境では、PC2 から見て eth0 ポートのネットワークに属するマシンは 10.1.1.1 の PC1 だけですので、上記の2行は同じ意味となりますが、厳密には全く違う意味となることを忘れてはなりませんね。
次に、パケットの宛先にポートに TCP 22 を指定、また送信元ポートを指定した書式です。
-A INPUT -p tcp --dport 22 -j REJECT
-A INPUT --sport 32768:61000 -j REJECT |
「
--dport」 は、宛先ポート番号を指定します。
-p tcp --dport 22 と指定することで、SSH 通信のパケットに適用されるルールとなります。 上記の場合は -j オプションで REJECT アクションを指定していますので、SSH 通信を受け入れない設定となります。
「
--sport」 は、送信元ポート番号を指定します。
ここでは --sport 32768:61000 と範囲指定しており、この数値は TCP/IP 通信の送信元ポートにランダムで記載されるエフェメラルポートを指定しています。 ちなみに Linux カーネルでエフェメラルポートの割り当て範囲は、
/proc/sys/net/ipv4/lo_local_port_range に書かれていました。
あともうひとつ重要な
デフォルトポリシー について書きます。
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0] |
デフォルトポリシーといって、パケットに対するチェインの基本動作を定義する必要があります。
これはフィルタリングルールに合致しなかったパケットに対し、どういった動作を行うかを指定するもので、早い話ルール外のパケットに対するルールですね。
INPUT DROP を例に挙げますと、受信したそのパケットが INPUT チェインに追加されたルールに当てはまらなかった場合、デフォルトポリシーは DROP が定義されているため、そのパケットは破棄されます。 OUTPUT ACCEPT ではその逆ですね。
予断ですがヤマハルータのデフォルトポリシー （デフォルトフィルター） は、ルールを何も設定していない場合には
オール PASS の動作を行い、何かひとつでも設定されていれば
オール REJECT の動作になります。メモメモ。。
さて、上記は基本的な iptables コマンドの設定方法をメモしました。
このように iptables コマンドは、3種類のチェインの動き、IP アドレスとポート番号の指定さえ理解してしまえば、設定はさほど難しくありません。 僕のような素人でも、コマンドリファレンスを読みながら簡単に設定できます。
ところが中には、コマンドリファレンスを読んでも
全く理解できないコマンド もありました。
実は今回の iptables メモは、その理解できないコマンドを追い求めるために書いた記事だったりします。
ということで、以下からは個人的に理解できなかったコマンドについてメモしていきます。
パケットカウンタここでは前項に続き、個人的に (・ω・`?) こんな感じで理解できなかった iptables コマンドのメモです。
まずはデフォルトポリシーの 「パケットカウンタ：バイトカウンタ」 についてです。
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0] |
デフォルトポリシーについては前項で扱いましたが、今回は着眼点が違います。
デフォルトポリシーに定義したチェインの右側に
[0:0] という記述があり、まずはここのメモから。
この数値ですが、どうやら 「
パケットカウンタ」 と 「
バイトカウンタ」 を現しているようです。
パケットカウンタとは、フィルタリングのルールに合致したパケットの個数を記録するもので、バイトカウンタはそのパケットサイズの合計数を記録するものです。 各カッコの左側がパケットカウンタ、右側がバイトカウンタとなり、間にコロンが入ります。また、これらカウンタは各ルールごとに持っています。
例えば INPUT チェインに ICMP 通信を破棄する設定を施したとします。
この設定を施したマシンは ICMP 通信が届くと、それはフィルタリングテーブルに登録された ICMP 破棄のルールと合致しますので、このパケットは破棄されます。 iptables では、この破棄された （ルールと合致した） パケットに関しては、その
パケット数 （パケットカウンタ） と
バイト数 （バイトカウンタ） を逐一記録しています。
↑図9：ルールに合致したパケット数やサイズが記録される
図9にも書きましたが iptables の設定一覧を見るときには iptables --list コマンドを実行しますが、-v オプションを追加することで詳細なカウンタ情報を確認することができます。 このカウンタ情報、普段ならあまり気にしなくても大丈夫ですが、不正アクセスや通信の統計・集計情報を取得するには必須の情報となります。
しかし iptables デーモンを再起動してしまうと、これらのカウンタ情報が
リセット されてしまいます。 このリセットされてしまう動作こそが、デフォルトポリシーに定義された
[0:0] の記述のようです。
ちなみに、カウンタ情報を含む iptables 設定を保存するには
iptables-save -c から実行できます。
iptables-save プログラムはルールセットを /etc/sysconfig/iptables に対してのみ保存するプログラムだと思っていましたが、それはリダイレクトしない場合の動作であり、リダイレクトすることによって iptables の設定を外部ファイルとして出力もできるようです。
iptables-save -c > iptables.cfg ← カウンタ情報を含む iptables 設定ファイルの保存
iptables-restore -c < iptables.cfg ← カウンタ情報を含む iptables 設定ファイルの復元
勉強になった!! (^ω^*)
RH-Firewall-1-INPUTiptables のチェインは、NAT を覗くと INPUT / OUTPUT / FORWARD の3種類に分けられますが、ときおり
RH-Firewall-1-INPUT というチェインを見かけることがあります。
この RH-Firewall-1-INPUT ってナニモノ？ と疑問になりましたので、以下はそのメモです。
RH-Firewall-1-INPUT を結論からメモしますと、これは 「
ユーザ定義」 のチェインだそうです。
面白いことに iptables では、INPUT と FORWARD チェインには同じルールが適用されることがあるようです。
ん、どういうこと？ と、よくわからなかったので以下に INPUT と FORWARD チェインに icmp 通信を許可する設定を書いてみます。
-A INPUT -p icmp -j ACCEPT
-A FORWARD -p icmp -j ACCEPT |
ホントだ、一緒だ!!! (^ω^*)
と、このように INPUT と FORWARD チェインに共通するルールに関しては、ユーザ定義のチェインを作成して、それを適用させることができます。
また、ユーザ定義ですからチェイン名も独自に決めることができます。
以下、GEN-CHAN というチェインで ICMP と SSH 通信のみ許可させるルールを設定しました。
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:GEN-CHAN - [0:0]
-A INPUT -j GEN-CHAN
-A FORWARD -j GEN-CHAN
-A GEN-CHAN -p icmp -j ACCEPT
-A GEN-CHAN -p tcp --dport 22 -j ACCEPT |
デフォルトチェインに GEN-CHAN を定義し、INPUT と FORWARD チェインに -j GEN-CHAN チェインを指定することで、これらチェインは GEN-CHAN チェインで設定したルールが適用されます。 上記の例では INPUT と FORWARD のデフォルトポリシーを DROP にしていますので、GEN-CHAN チェインに ICMP と SSH パケットを通すルールを追加してあげたところ、通信の確立を確認しました。
前述もしましたが、確かにヤマハルータでは IN / OUT のみで FORWARD を実現させますので、そういう意味では INPUT と FORWARD チェインが同じであっても何ら不思議ではないですね。
--reject-with/etc/sysconfig/iptables ファイルに記述されたルールは、上から順に適用されていきます。
以下の図では、各種ルールにマッチしなかったパケットが 「-A INPUT -j REJECT
--reject-with icmp-host-prohibited 」 というルールによって破棄されています。
↑図10：フィルタリングは上の行が優先される
この --reject-with icmp-host-prohibited の意味がいまいち分からなかったので、そのメモです。
早い話、これはパケットを破棄するときに 「
通知を返す」 という意味のようです。
通知を返すってナンジャイ、と思ってしまいますので、以下詳細です。
この段階になってようやく触れる話題ですが、実は今回の iptables のメモでは 「パケットを破棄」 する動作に関しては、破棄アクションである
REJECT / DROP を使い分けず、同じ意味としてメモしてきましたが
厳密には違います。確かに 「パケットを破棄する」 という点では同じなのですが…、
DROP は 「破棄したら破棄しっぱなし」
REJECT は 「破棄したら ICMP パケットで送信元に “破棄されました” と通知する」
という、アフターケア的な動作が発生する点が大きく異なります。
↑図11：REJECT アクションは思いやりがある
ICMP (Internet Control Message Protocol) は IP の補助的な役割を担うプロトコルです。
ICMPv6 のメモでも少しだけ触れましたが、IPv4 のフォーマットまでは触れていなかったので、以下に描きました。 ICMP フォーマットはこんな感じです。
↑図12：ICMP パケットフォーマット (IPv4)
ICMP プロトコルの Type と Code フィールドには 1byte の領域が用意されており、そこには数字が入ります。
また Type と Code の組合せにより ICMP パケットに
意味 を持たせることができます。
「ICMP メッセージタイプ 一覧」 といったキーワードで Google 検索すればそれらの意味がすぐに分かりますので、ここでは深くは追及しませんが、たとえば Ping のレスポンスは 「
Type=0, Code=0」 が入っており、また 「
Type=3, Code=10」 であれば 「
相手がその通信を拒否している」 といったようにです。
ここで試しに iptables に Telnet (TCP 23) を reject させる設定を書いてみます。
| -A INPUT -p TCP --dport 23 -j REJECT |
上記のルールは REJECT のみ指定していますので --reject-with の指定はありません。
このルールを追加したマシンに対し Telnet 通信を投げてみると、言わずもがな通信未確立になってしまいますが、そのとき受信した ICMP パケットを wireshark にて解析したところ、その ICMP のヘッダーには以下の Type と Code が書かれていました。
↑図13：Wireshark による ICMP パケット解析
「
Type=3, Code=3」 と書かれているのが分かります。
Type=3, Code=3 を ICMP メッセージタイプ一覧から引っ張ってきたところ、この組み合わせは 「ポートが到達できない (Port unreachable)」 を意味しています。 こう見ると
よくわからんけど通信できない といった漠然とした未通信エラーとは違って、
ポートがらみで通信ができない といった切り分けができてきますね。
勘の鋭い方なら、もうお分かりかと思われます。（僕が読者ならまだ絶対分からないw）
そうです、この
Type と Code に入れる数字を調整することができるのです。続いて以下に iptables のデフォルト設定してある icmp-host-prohibited をルールに加え、いくつかのオプションもそれぞれルールに追加し、同じく Telnet 通信を投げた結果を以下に書いてみます。
ルールに追加したオプション →
--reject-with icmp-proto-unreachable 返ってきた ICMP の各フィールド →
Type=3, Code=2 (Protocol unreachable) ルールに追加したオプション → --
reject-with icmp-net-prohibited 返ってきた ICMP の各フィールド →
Type=3, Code=9 (Network administratively prohibited) ルールに追加したオプション → --
reject-with icmp-host-prohibited 返ってきた ICMP の各フィールド →
Type=3, Code=10 (Host administratively prohibited)
↑図14：ICMP が返ってくるイメージ
図14にも描きましたが、REJECT するルールに則ったケースバイケースな ICMP メッセージをレスポンスしてあげると、もっと質の良い REJECT の設定ができそうな気がしますね （図14が合っているか不安ですが…）。
--tcp-flags, --state オプション--tcp-flags, --state オプションがあり、このさっそくこのメモを残したいのですが…。
実はこれらに関しては iptables の設定以前に
TCP/IP のレベルから理解する必要があります。残念ながら今の僕にはこの知識は持ち合わせておりません。
今ここでこれらを追究してしまうと、ただでさえ長いメモがさらに長くなってしまう恐れがありますので、--tcp-flags と --state オプションについては、また別の機会にメモしていく予定です。
最後にパケットフィルタリングを設定中、ときおり 「
方向の指定」 に混乱するときがあります。
（えっと、この通信を拒否させるには LAN 側を止めればいいんだよね…）
（…ポート番号の指定は…送信元……いや宛先…だっけ…）
（……よし、これで大丈夫だ………え、違う！？ あ、逆だ！！）
……みたいな。OTL
このように混乱したとき、対処法はひとつしかありません。
紙にペンで図を描く これに尽きますよね。
昨今のデジタル社会では 「ペーパーレス」 と言われてきています。
ですがよく考えますと、それは
情報の保存媒体 がペーパーレス化していることに気づかされます。
人間がアナログである以上、紙とペンからの卒業はまだまだ先なのでしょうか…。
やっぱり 紙とペン は偉大です。
ネットワーク図を描いていると、そんなことばかり考えてしまいますｗ (*^ω^*)
スポンサーサイト
