2013-08-19 10:19 AM
シスコの技術サポートエンジニアへ質問して疑問を解決できる「エキスパートに質問」へようこそ!
ここでは、シスコのエキスパートからのアドバイスや最新の情報が得られる場として気軽に質問してみてください。
今回はアプリケーションレイヤーのセキュリティ製品(ASA-CX, Cisco Email Security Appliance(旧IronPort ESA), Cisco Web Security Appliance (旧 IronPort WSA) について、一般的なご質問にお答えします。
担当エキスパート: 秦 昭 (Zhao Qin)
シスコテクニカルサポート、Firewall テクノロジテクニカルリード
2008年入社。カスタマーサポートエンジニアとしてシスコ テクニカルサポート部門、セキュリティチームへ配属。
以降、Firewall、VPN、ACS や IPS などのテクノロジに関するサポートを担当。現在は、Firewall を最も専門とし活躍している。
ディスカッション開催期間: 9月9日(月)~9月22日(日)
[質問の回答方法]
サポートコミュニティへCisco.comIDでログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。
もし1つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
この「エキスパートに質問」のディスカッションスレッドに届いた質問は担当のTACエキスパートが回答しますがすべての質問に返信できないかもしれません。
返信が得られずに開催期間が終了して残ってしまった質問については、サポートコミュニティ事務局が今回の技術カテゴリの通常のディスカッション フォーラムへ再掲載し、有用な情報の展開へとつなげていきます。
エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。
あなたからの質問だけでなく、他コミュニティのメンバーから寄せられた質問がどう発展したかをのぞきに、ぜひこのフォーラムへ再度訪問されることをお待ちしております!
[エキスパートからの回答について]
質 問の投稿から原則数日以内に回答できるよう努めます。内容によっては、検証や確認に時間がかかる場合もありますのでご了承ください。質問の内 容によっては、エキスパートの担当範囲外の場合もございます。その際はサポートコミュニティ事務局、もしくは適切な担当から回答いたします。
ディスカッション期間を過ぎてからの投稿は、事務局より通常コミュニティへ投稿いただくようお願いさせていただくようになりますことも合わせてご理解ください。
2013-09-11 11:02 AM
ASA-CXとWSAの違いについてご教示ください。
質問1:
CXでも、URLフィルタリング、Webレピュテーションが可能だと思いますが、
WSAとCXでは、上記2つの機能に差異はあるのでしょうか?
質問2:
WSAでは、アンチマルウェア機能があると思いますが、
それ以外にWSAのみの機能はありますでしょうか?
よろしくお願いします。
2013-09-11 11:11 AM
連続ですいません。
ASA-CXでは、HTTPSトラフィックを一度複合化して、Inspectし、再暗号する機能があると思います。
また、ASA-CXでキャプチャする機能もあると思います。
該当通信をキャプチャした場合、複合化されたパケットがキャプチャされるのでしょうか?
それともHTTPSの暗号化されたパケットがキャプチャされるのでしょうか?
よろしくお願いします。
2013-09-12 02:42 PM
ご質問ありがとうございます。
> 質問1:
> CXでも、URLフィルタリング、Webレピュテーションが可能だと思いますが、
> WSAとCXでは、上記2つの機能に差異はあるのでしょうか?
URLフィルタリングとWebレピュテーションの機能に関しては、どちらの製品も同じCisco Security Intelligence Operations (SIO)より取得するレピュテーション情報に基づいて実装していますので、処理については大差がありません。ただ、関連するレポーティング機能、ロギング機能などはそれぞれ細かい実装の差異がございます。
> 質問2:
> WSAでは、アンチマルウェア機能があると思いますが、
> それ以外にWSAのみの機能はありますでしょうか?
シンプルに言うと、WSA はWeb-Proxy製品、CX はLayer-7 Firewall 製品と理解いただいて良いと思います。2つの製品間でオーバーラップする部分はございますが、前者はウェブ通信に特化しており、後者はウェブ通信以外も処理できます。そこで、WSA のみの機能として、下記のものがございます。
Caching
Anti-Malware/Anti-Virus 機能
Data Leakage Prevention (DLP)
Cookie surrogates
ブラウザでProxy設定を明示的に指定できる
逆に、CX の特徴は下記になります。
Inline 構成で利用する
ASAとOne-box でセキュリティソリューションになる
ウェブ以外の通信を対応できる
> ASA-CXでは、HTTPSトラフィックを一度複合化して、Inspectし、再暗号する機能があると思います。
> また、ASA-CXでキャプチャする機能もあると思います。
> 該当通信をキャプチャした場合、複合化されたパケットがキャプチャされるのでしょうか?
> それともHTTPSの暗号化されたパケットがキャプチャされるのでしょうか?
Access Policy に該当する通信はキャプチャ可能ですが、
Decrypt Policy に該当する通信はキャプチャはできません。
なので、復号化されたパケットがキャプチャされることはありません。
2013-09-13 08:17 AM
ご回答ありがとうございます。
たいへん、よくわかりました。ありがとうございます。
2013-09-11 04:50 PM
お世話になります。
OS の Upgrade について、ご質問させてください。
Release Notes を参照すると、たとえば、8.2 から 9.1へUpgradeする場合、
8.4.6を経由するのが必須(MUST)であるとの認識ですが、その理由は何でしょうか?
(リンクより抜粋)
You cannot upgrade directly to 9.0 or later.
You must first upgrade to Version 8.3 or 8.4 for a successful migration.
Release Notes では、下記の部分にあるように、「ACL migration が原因で、
後にダウングレードすることができない」との記載があるのですが、
この部分が8.4.6を経由するのが必須な理由でしょうか?
その他に明確な理由があれば、ぜひご教授ください。
(リンクより抜粋)
If you are upgrading from a pre-9.0 release,
because of ACL migration, you cannot later perform a downgrade;
[参考リンク]
Upgrade Path and Migrations
http://www.cisco.com/en/US/docs/security/asa/asa91/release/notes/asarn91.html#wp717607
以上、宜しくお願いいたします。
2013-09-12 03:20 PM
バージョン 8.3 を境に、ASA において NAT、Real IP Address Access-List など多くの実装変更がありました。
アップグレード時に自動的な Configuration Migration が用意されておりますが、設定によっては手動で微調整することが必要になります。
http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html
そして、9.x にアップグレードする際は、今度はUnified ACL for IPv4 and IPv6 の機能追加による ACL migration が発生します。
8.3/8.4 での Migration と 9.x の Migration を同時に処理することがかなり複雑になるため、スムーズな移行を行うために、分けて実施して頂く必要がございます。これが理由になります。
2013-09-20 10:59 AM
ご回答いただき、ありがとうございました。
2013-09-13 03:42 PM
WSAのデザインについてご教示ください。
Transparent modeでは、WCCP Redirectのサポートのみで、G/W的な形での構成はできないのでしょうか?
2013-09-13 04:41 PM
はい、残念ながら、Transparent mode でG/W的な形で、Inline 構成を利用することは、現時点の WSA 実装でサポートしておりません。
2013-09-13 05:37 PM
ご回答ありがとうございました!
2013-09-13 05:45 PM
DNSの取り扱いについてご教示ください。
たとえば、
http://www.yahoo.co.jp/
http://www.google.co.jp/
とアクセスした場合、IW_srchとしてカテゴライズされますが、
http://203.216.227.245/
http://173.194.72.94/
とIPアドレスにした場合、カテゴライズされません。
逆引きでURLの確認をしないのは仕様でしょうか?
Malware siteがipアドレスによるアクセスの場合、すりぬけてしまうことが懸念されます。
以上よろしくお願いいたします。
2013-09-17 01:40 PM
IP ベースの URL で GET リクエストを受けた場合、WSA はDNSの逆引きを行いません。
このような実装になる理由がございます。例えば、弊社サイト www.cisco.com を確認すると、逆引きで得られた名前は、弊社ではなく、コンテンツ配信サービスを提供しているAkamai社に属するものになります。
S370> nslookup www.cisco.com
A=184.26.240.170 TTL=30m
S370> nslookup 184.26.240.170
PTR=a184-26-240-170.deploy.static.akamaitechnologies.com TTL=30m
同IPアドレスより配信されるコンテンツが必ず弊社のものである保証はありません。また、ホスティングサービスを提供する会社によっては、複数のドメインに属するコンテンツを同じIPアドレスで提供する可能性も考えられます。つまり、IP アドレス情報でカテゴライズすることはあまり信頼性の高い結果が得られないと考えられます。
Malware に関しては、「Webレピュテーションおよびマルウェア対策」で対策しており、URL カテゴリに依存しない実装になっております。URL カテゴリでいわゆる「Malwareカテゴリ」が存在せず、URL カテゴライズによってMalwareをブロックすることはないと思います。
2013-09-17 05:47 PM
ご回答ありがとうございます。
MalwareサイトへIPアドレスによるアクセス拒否を確認できました。
ありがとうございました。
IPで指定した場合、カテゴライズされないので、ポルノ:ブロックのような
設定をすり抜けてしまうので、フィルタの設計は少し工夫が必要そうです。
有名サイトでは、IPアドレスでカテゴライズされるものもありましたので
じょじょにDBに取り込まれているのかと思いますので期待しています。
エキスパートの回答、ステップバイステップガイド、最新のトピックなどお気に入りのアイデアを見つけたら、あとで参照できるように保存しましょう。
コミュニティは初めてですか?これらのヒントを活用してスタートしましょう。 コミュニティの活用方法 新メンバーガイド
下記より関連するコンテンツにアクセスできます