シスコサポートコミュニティ
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
告知
シスコ サポート コミュニティへようこそ!あなたの ご意見 をお聞かせください。

「エキスパートに質問」特別版Firewall 製品のトラブルシューティングについて

担当エキスパート:「 秦 昭 (シン ショウ)」

ディスカッション開催期間:2011年12月15日~2011年12月25日

12月14日に開催いたしました、CSC ライブ Expert Webcast(オンラインセミナー)のスピーカーが

セミナートピックに関する皆さんからの質問に答えます。セミナーでは聞けなかった質問や詳しく聞いてみたいことなど

この場で気軽に質問してみてください。

また、セミナーにご参加いただけなかった皆さまもこのトピックに関してのご質問がありましたら遠慮なく投稿してください。


プレゼンテーション資料のダウンロードはこちら

プレゼンテーションVoDはこちら

トピック

Cisco Firewall 製品のトラブルシューティング

~ASA/FWSM の NAT とパフォーマンス問題について ~

[質問の投稿方法]

サポートコミュニティへCisco.comIDでログインすると、この説明の右下に「返信」ボタンが表示されます。

クリックすると投稿欄が表示されますので、質問をご記入ください。

最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。


もし1つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
この「エキスパートに質問」のディスカッションスレッドに届いた質問は担当のTACエキスパートが回答しますが

すべての質問に返信できないかもしれません。
返信が得られずに開催期間が終了して残ってしまった質問については、サポートコミュニティ事務局が

通常のディスカッション フォーラムへ再掲載し、有用な情報の展開へとつなげていきます。


エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。


あなたからの質問だけでなく、他コミュニティのメンバーから寄せられた質問の展開を確認するためにも、

ぜひこのフォーラムへ再度訪問されることをお待ちしております!

10 件の返信
New Member

「エキスパートに質問」特別版Firewall 製品のト

お世話になります。

セッション後QA時にv8.3以降でNATの設定方法が変わった理由・メリットについて、

I/FレベルをNAT設定から分離できるとおっしゃっていましたが、

具体的にご説明いただけないでしょうか?

ACLの設定にReal IP Addressが設定できることと同義でしょうか?

よろしくお願いします。

Silver

「エキスパートに質問」特別版Firewall 製品のト

説明不足で申し訳ありません。

nat コマンドでルールを定義する時、インターフェース名の代わりに any を指定できることをさしています。

例えば、8.2 以前でこのような設定があるとすると、

static (inside,outside) 10.0.0.2 192.168.1.2

static (inside,dmz) 10.0.0.2 192.168.1.2

static (inside,dmz2) 10.0.0.2 192.168.1.2

static (inside,dmz3) 10.0.0.2 192.168.1.2

8.3 以降の NAT でこれを下記のように定義できます。

object network inside-server

host 192.168.1.2

object network inside-server-translated

host 10.0.0.2

!

object network inside-server

nat (inside,any) static inside-server-translated

New Member

「エキスパートに質問」特別版Firewall 製品のト

秦さん

ご回答ありがとうございます。

了解しました。

失礼します。

New Member

「エキスパートに質問」特別版Firewall 製品のト

こんにちは。わかりやすく詳しいセミナーありがとうございました。

セッション中にも質問し、幸いにも取り上げていただきましたが、表現不足でうまく意図が伝わらなかったようなので再度質問をお許しください。

ASAをIPsecVPN装置として導入した環境でDB通信に問題が生じたことがあり、Default Global Inspection の一部を削除すると問題が生じなくなったことがありました。(お客様が特定されるかもしれないため詳細は割愛させていただきます)

さまざまな環境にASAをIPsecVPN装置として導入することがあるのですが、ユーザ通信を全て把握することは困難であるため、

Default Global Inspection を導入前にあらかじめ全て削除することも考えております。その際のリスクはどのようなものがありますでしょうか。よろしくお願いします。

Silver

Re: 「エキスパートに質問」特別版Firewall 製品の

導入環境の通信特徴によりますが、リスクはあると思います。

例えば、inspect dns を削除すると、DNS Guard という機能(サーバからリプライを受け取った時点で、DNS クエリに対応する connection を teardown する機能)が効かなくなり、DNS クエリによって生成される UDP connection がデフォルト 2分の timeout まで保持されます。DNS クエリが頻発する通信環境では、connection がたくさん貯まってしまう場合があります。

FTP の場合、コマンドリファレンスに記載している下記のリスクがあります。

"If you disable FTP inspection engines with the no inspect ftp command, outbound users can start connections only in passive mode, and all inbound FTP is disabled."。

それぞれのプロトコルに対応する inspection は独自に機能を持ちますので、削除されると、それらの機能を利用できなくなります。inspection をひとつずつ説明すると長くなりますので、コマンドリファレンスにて各 inspection の詳細をご参照していただければと思います。

inspect

http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/i2.html

つまり、inspect をデフォルトのままで導入すると、ご指摘頂いた DB 通信に対して問題を起こすような場合があるですが、一方、「Default Global Inspection を導入前にあらかじめ全て削除する」ことを実施しますと、別の問題を起こす可能性もあります。

New Member

「エキスパートに質問」特別版Firewall 製品のト

Default Glocal  Inspection をあらかじめ全て削除することについてのリスクについてわかりました。

まずユーザ通信を把握して、必要に応じて設定を変更することがいいようですね。

また、この機会にあらためて Default Glocal Inspection を一通り確認しようと思います。

ご回答ありがとうございました。

New Member

「エキスパートに質問」特別版Firewall 製品のト

セミナー資料の公開ありがとうございます

NATコマンドの変更によって
ASAのDNSリライト機能にもっと複雑な処理をさせることは可能でしょうか?

具体的には、下記URLの構成で、
DMZのセグメントにもWebクライアント(192.168.100.2)がいると仮定します。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/sec/asa/caclcg1/chapter22/8629_01_22.shtml#72723

8.2以前のOSでは、下記のDNSリライト設定がされていると
static (dmz,outside) 209.165.200.225 192.168.100.10 dns

各クライアントが、server.example.com を参照したAレコードは、下記に変換されるかと思います。
DMZ配下のWebクライアントには、local(192.168.100.10)で応答
inside配下のWebクライアントも local(192.168.100.10)で応答

8.3以降のOSを利用した場合、下記のような動作をさせることは可能でしょうか。
(全てのインタフェース上でDNSインスペクトが有効な状況です)
DMZ配下のWebクライアントには、local(192.168.100.10)で応答
inside配下のWebクライアントには global(209.165.200.225)で応答

以上、よろしくお願いいたします

Silver

Re: 「エキスパートに質問」特別版Firewall 製品の

ご説明頂いた要件について、(現在手元に DNS サーバがないため、動作確認していませんが)、

設定は下記になるのではないかと思います。

ciscoasa# show run object

object network SERVER_REAL1

host 192.168.100.10

object network SERVER_REAL2

host 192.168.100.10                 <== 同じ object に nat ルールを一つしか定義できないため、

192.168.100.10 の object を二つ作る。

object network SERVER_MAPPED

host 209.165.200.225

ciscoasa#

ciscoasa#

ciscoasa# show run nat

!

object network SERVER_REAL1

nat (dmz,outside) static SERVER_MAPPED dns

object network SERVER_REAL2

nat (dmz,inside) static SERVER_MAPPED dns

ciscoasa#

ciscoasa#

ciscoasa# show nat detail

Auto NAT Policies (Section 2)

1 (dmz) to (outside) source static SERVER_REAL1 SERVER_MAPPED   dns

    translate_hits = 0, untranslate_hits = 0

    Source - Origin: 192.168.100.10/32, Translated: 209.165.200.225/32

2 (dmz) to (inside) source static SERVER_REAL2 SERVER_MAPPED   dns

    translate_hits = 0, untranslate_hits = 1

    Source - Origin: 192.168.100.10/32, Translated: 209.165.200.225/32

ciscoasa#

ciscoasa#

ciscoasa# show xlate

2 in use, 2 most used

Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice

NAT from dmz:192.168.100.10 to outside:209.165.200.225

    flags sD idle 0:01:32 timeout 0:00:00

NAT from dmz:192.168.100.10 to inside:209.165.200.225

    flags sD idle 0:00:32 timeout 0:00:00

ciscoasa#

下記のドキュメントに記載している事例と同じような考え方で、(dmz,outside) と (dmz,inside) の二つのルールにより、二回の DNS Rewrite が発生することになっています。ご参考頂ければと思います。

-----

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_overview.html#wp1181195

New Member

「エキスパートに質問」特別版Firewall 製品のト

お世話になっております。

セミナー中、OSの選択・アップグレードの考え方として、

8.2は安定指向を求める場合、8.4は新機能を使用する場合と

ご説明頂きました。

このようにご説明いただいた理由について、ご教示頂けますでしょうか。

特に、「8.2は安定指向向き」に関し、何か御社で特別な理由、指針の

ようなものがあるのでしょうか。

又、8.2のEoLは当分の間アナウンスされないとの理解でよろしいでしょうか。

Silver

Re: 「エキスパートに質問」特別版Firewall 製品の

「8.2は安定指向を求める場合、8.4は新機能を使用する場合」は、現時点で各バージョンの開発状況などに基づいて申し上げました。

7.x、8.0.x、8.1.x のバージョンは、EoL がアナウンスされており、深刻なバグが発見された場合以外のコード修正はほぼ終了しています。そのため、8.3.x 以前のバージョンを利用する場合は、8.2.x をご利用して頂くことがベストです。

8.3 を境に NAT を含む実装変更が多くあり、新しく導入された機能は比較的に不具合などが発生しやすいです。設計要件の中で、必ず利用しなければならないような新機能がなければ、あえてリスクを取ることもないかと思います。

そして、8.3.x と 8.4.x を比較する場合、8.4.x に開発リソースが集中されておりますので、8.3.x 以降のバージョンで選択するなら、問題が発生した場合の対策を考慮して 8.4.x がベターです。

現時点で、8.2 の EoL 計画が決まっておりません。

2544
閲覧回数
3
いいね!
10
返信