|Email Plug-in (Reporting):||1.1.0-114|
|Email Plug-in (Encryption):||1.2.1-118|
Currently there are no plans to have AMP Endpoint/Network solution integration for ESA. The reason behind this would be that there are not much configuration we can customise on ESA in regards to AMP. The AMP Scanning engine analyse a file and give its verdict. This works almost similar to the other AV scanning engines on ESA.
However, in any case, if you think it would be better to have integration option, I would recommend filing a feature request through TAC.
Regarding ESA management through SMA, we already have a feature request open for this. We can add a sighting to the FR, but again, we need a case number to attach to the FR. Can you please quickly open a case and point the TAC to CSCug60160.
Is there any plan to replace C170 and S170 in the near or mid term feature?
Is there any plan to integrate (limited functionality) email security in ASA next get firewalls?
By replacing -- loosely defined -- we're moving onto the x80 platforms in terms of hardware -- however the C170 and S170 from a glance I believe they'll still be used for the time being.
As for ESA to ASA integration functionality, at this stage there are no plans (that I myself know of).
of course, this is what I wanted to ask :) If there are any plans to move from C/S170 to C/S180 platform like you already did in 300 and 600 series.
Thanks for the info!
Quote from Cisco Doc: "Due to WCCP technology limitation, a maximum of 8 ports can be assigned per WCCP service ID"
What is the best practice on accommodating more then 8 ports for proxy on WSA? WCCP ID per protocol?
Let say I want to cover the following ports: HTTP 80, 82, 8000, 8080, 8090, 3128 HTTPS 443, 8443, FTP 8021 etc.
Basically you can create multiple WCCP service groups to accommodate this. Each one for different services.
Here is a good KB article regarding "Sample Transparent Redirection configuration using WCCP to redirect native FTP traffic". explaining this in details.
I hope this will help.
Question - will WSA support UDP 80/ UDP 443?
QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental transport layer network protocol developed by Google and implemented in 2013. QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. QUIC's main goal is to optimize connection-oriented web applications currently using TCP.
Thanks for your asking. WSA does not support QUIC at this moment. However please bear in mind that this QUIC needs both client side and server side support. According to that wiki, it appears so far only Chrome and Opera supporting this feature and there is no RFC for this feature.
If you wish to add this feature to WSA, I would recommend contacting TAC to submit a new feature request for this one.
I hope this will help.
Hi, we're creating design for new deployment.
Brief network design:
a) primary site
- two WSA S380 installed
b) secondary (DR) site
- connected to primary site with layer 2 (dark fiber)
- one virtual WSA installed
The idea is two have all three appliances configured to run in HA mode.
So if there's everything running smoothly one of both appliances on primary location will be active.
If both appliances on primary location go down virtual appliance on DR location becomes active.
I can't find information if mixing of different appliance models is supported in the release notes or user manual. It this design supported? What are limitations of WSA HA cluster?
Thanks for asking.
WSA HA is a new feature in WSA version 8.5.x which has not been General Deployment yet until now and it should be GA shortly.
According to the following User Guide and the youtube video. Currently High Availability is only for explicit deployments as transparent mode using WCCP supports load balance automatically.
Technically there is no restriction for the hardware models as long as all appliances run version 8.5 or later, however please keep in mind in case both appliances are down in your primary site, you need to ensure the vWSA in is capable handling all the traffic load.
I hope this will help.
From my knowledge, WSA does not yet support TLS 1.2 -- I believe an ID was filed for this service allowance on the WSA (and ESA+SMA) and it's under investigation.
Hi, I have a couple of questions related to WSA. I'm looking for more information on anti-malware scanning, and have a couple of questions about external DLP.
1) Is the decision for whether or not content is scanned for anti-malware based entirely on reputation? Is there any way to create policy to define which types of traffic get scanned for anti-malware? If so, how is that done, and how flexible can the policy be defined (i.e. only content from a particular subnet is scanned)? Is it possible to scan all traffic, and is scanning all traffic recommended?
2) With external DLP servers, can you please elaborate on the protocols and methods that are scanned for DLP? It looks like only HTTP, HTTPS, and FTP are supported. Which methods are scanned (PUT, GET, etc...) and with FTP, is it only scanned in the context of FTP over HTTP, or is native FTP scanned as well (Assuming it's sent to the proxy as well). With FTP, which methods are supported (put, mput)?
3) With external DLP. The AsyncOs User guide indicates the following: " Verify the external DLP server does not send the Web Proxy modified content. AsyncOS for Web only supports the ability to block or allow upload requests. It does not support uploading content modified by an external DLP server.
What exactly does this mean? If the external DLP server modifies the content to remove/mask sensitive information, will this not work with the WSA? Is the WSA only looking for a block or allow response from the external DLP server?
Different teams manage the different virus detection suites that can be included in the ESA, just wanted to make sure I understood the whole picture.
So if you have all of these in the same appliance, the likelihood that they would be detected and not delivered to the inbox is much higher. So a simplified e-mail lifecycle through an ESA would would look like:
Message Filter -> Mail Policy -> Sophos/McAfee virus scan -> AMP scan -> Outbreak and SPAM filter -> content filters (default actions taken unless content filter overrides these actions on the last step)
As a security Pro I can see a huge benefit of having these multiple layers within the appliance:
AMP -> Cisco SourceFire/AMP team
Sophos -> Sophos
Outbreak filter -> Cisco Spam and Virus Outbreak team.