Cisco ASA - Force all traffic through SaaS Web Filter
772
As subject really. I have a network behind an ASA 5505 and we need to monitor web usage. We have an agreement with Webroot and their Web Security SaaS. Question is, how can I force all outbound traffic to go out via the Webroot proxy servers?
Since I don't know anything about your existing rulebase, network topology, or organization, I can only tell you that the standard method for providing web access in a corporate environment is to either:
1.) Host the proxy server internally, and implement a firewall rule allowing the proxy server outbound access via http, https, ftp, and other neccessary protocols.
or
2.) Host the proxy server externally, and implementing a rule allowing your desktops and other neccessary systems access to the proxy server via SOCKS, http-proxy, or whatever the case may be.
In reality, a combination of these approaches is typically taken, positioning the proxy server in a DMZ and managing access to it from the internal network, and it's access outbound.
From the nature of your question I gather that you either have an outbound allow all policy, or an outbound allow http/https from any to any rule above your deny all. In either case, these policies are incompatible with proxy enforcement and must be removed if you want to proceed. Should you have existing business process that rely on these rules being there, you must ensure that appropriate rules are created such that the business processes are not broken when the 'any' rule is removed. If you don't have your business processes fully documented, you will need to comb through firewall logs to ensure there is no loss in service. You have quite a project ahead of you, and I feel for you.
Cisco ASA has two features which can work in conjunction with an external web filtering service:
URL Filtering on the ASA inspects http requests and checks them against a filtering server which could be internal or external. It is possible to set up cacheing of the response to reduce the number of lookups.
WCCP (Web Cache Communication Protocol) can be configured on the ASA to force http requests to go via a cacheing server, and many web filtering servers are cache servers - so presumably they could serve up a forbidden page instead of banned sites.
Whether webroot are able to support either of these methods, I can't say, but theoretically I think a SaaS web filtering service could use either to deliver their service without having to roll out any config or executables to clients.
Since I don't know anything about your existing rulebase, network topology, or organization, I can only tell you that the standard method for providing web access in a corporate environment is to either:
1.) Host the proxy server internally, and implement a firewall rule allowing the proxy server outbound access via http, https, ftp, and other neccessary protocols.
or
2.) Host the proxy server externally, and implementing a rule allowing your desktops and other neccessary systems access to the proxy server via SOCKS, http-proxy, or whatever the case may be.
In reality, a combination of these approaches is typically taken, positioning the proxy server in a DMZ and managing access to it from the internal network, and it's access outbound.
From the nature of your question I gather that you either have an outbound allow all policy, or an outbound allow http/https from any to any rule above your deny all. In either case, these policies are incompatible with proxy enforcement and must be removed if you want to proceed. Should you have existing business process that rely on these rules being there, you must ensure that appropriate rules are created such that the business processes are not broken when the 'any' rule is removed. If you don't have your business processes fully documented, you will need to comb through firewall logs to ensure there is no loss in service. You have quite a project ahead of you, and I feel for you.
Cisco ASA has two features which can work in conjunction with an external web filtering service:
Whether webroot are able to support either of these methods, I can't say, but theoretically I think a SaaS web filtering service could use either to deliver their service without having to roll out any config or executables to clients.