その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の設定になります。

■関係リンク

Firewall(ASA)での基本的な通信制御～その1

Firewall(ASA)での基本的な通信制御～その3

■サンプルファイルダウンロード

ASA設定前・設定済みのPktファイルと、機器のコンフィグファイルをダウンロードしていただけます。

pktファイルのダウンロードへ(Google Drive)

※ZIPファイルなのでジャンプ先で「エラー プレビューに問題が発生しました」と表示されますが、正常動作です。そのままダウンロードしてください。