その1（Firewall(ASA)での基本的な通信制御～その1）からの続きです。
その1では、ASAにホスト名・Enableパスワードを設定し、インターフェースの設定まで行いました。
ここでは通信制御を行います。
ルータのACLと似たようなものですが、設定の仕方が少し異なり、「オブジェクト」という考え方が出てきますが、Packet Tracerではオブジェクトによる制御機能が十分ではないので、とりあえずは通常のACLと同じだと思って設定しましょう。
ここでは、
PC1からSV1に対してはHTTPのみ許可
PC1SV2に対してはICMPのみ許可
というフィルタリング設定を行います。
■ACL作成
コマンドは以下の通りです。
# conf t
(config)# access-list SOTO-to-UCHI extended permit tcp host 192.168.20.1 host 192.168.10.1 eq 80
(config)# access-list SOTO-to-UCHI extended permit icmp host 192.168.20.2 host 192.168.10.1
ビミョーにルータとは違っています。また、番号でACLを指定することができません。
そして、このACLをインターフェースに適用するわけですが、以下のようなコマンドになります。
(config)#access-group SOTO-to-UCHI in interface SOTO
上記の設定画面を見ていただくとわかると思いますが、interfaceの後に設定するのは、Gi1/4などの物理インターフェースではなく、nameifを設定することになります。
今回は、SOTOインターフェースに対してin方向（SV→PCの方向）に対して許可を行いますので、上記のような設定になります。
上記設定を行うことで、インターフェースSOTOからUCHIの通信が許可されて、Pingの応答が帰ってくるようになりま・・・
・・・おや？
途中から「Destination host unreachable」になってしまい、ICMPに失敗してしまいました。
何が起きているのかとASA側のCLIを見てみると・・・
OSPFがお亡くなりになっています。
面倒なことに、アクセスリストを設定した時点で、暗黙のDenyが発動して、OSPFのHelloパケットも制御されてしまったようです。
そんなわけでアクセスリストに以下の２行を追加することになります。
(config)# access-list SOTO-to-UCHI extended permit ip host 10.10.10.1 host 10.10.10.2
(config)# access-list SOTO-to-UCHI extended permit ip host 10.10.10.1 host 224.0.0.5
224.0.0.5はOSPF Helloのマルチキャストアドレス。
また、データベースの交換やACKの応答はユニキャストを使いますので、アップデートをやり取りする隣接したルータのIPアドレスも必要になります。
これらの設定が入ることで、OSPFがネイバー関係を取り戻し、再びPingが通るようになります。
これでめでたくASAでの通信制御設定の完了で・・・
そんなわけありませんね。
これではルータACLと全く変わりません。
Firewall導入の意味がない。
やっぱりステートフルパケットインスペクションができてこそのFirewallです。
そんなわけで、次回はSPIの設定になります。
■関係リンク
■サンプルファイルダウンロード
ASA設定前・設定済みのPktファイルと、機器のコンフィグファイルをダウンロードしていただけます。
※ZIPファイルなのでジャンプ先で「エラー プレビューに問題が発生しました」と表示されますが、正常動作です。そのままダウンロードしてください。
最近のコメント