Symantec Web Gateway (SWG) - Best Practices: New Deployments
|Article:TECH144596|||||Created: 2010-11-19|||||Updated: 2014-01-30|||||Article URL http://www.symantec.com/docs/TECH144596|
What is best practice for a new Symantec Web Gateway deployment?
Before deploying SWG some steps are required in order to make the new environment appropriate for the product to perform and function correctly.
In this document we outline some pre-deployment and post-deployment steps the administrator should take to get the most from SWG.
This document does not intend to replace the documentation that comes with SWG. The following manuals in pdf format are the main source of information for SWG implementation and configuration:
Read the documentation provided with the product
Knowledge is power, and this is no exception. The documentation provided with the product in pdf format and the internet are excellent resources to build and strengthen your knowledge. The accompanying documentation explains in detail how to configure and tune the product for best results.
The SWG appliance was designed to protect the network from Web 2.0 threats such as malicious URLs, spyware, botnets, viruses and other types of malware. The manner in which you connect the SWG to the network affects its capabilities. Read the SWG Implementation Guide for more information on this topic.
A fully working network environment is key to succeed in deploying the SWG. Ideally all hosts that will interact with the SWG must be reachable from the SWG assigned IP addresses.
The fact that the SWG is able to report an internal source address into the reporting section of the GUI doesn't mean that host can be properly reached back if necessary as NAT or firewall rules may affect this traffic.
Make sure the network topology is reflected on the network section of the SWG configuration section and that all the static routes with the corresponding gateways have been entered as part of the configuration.
Hosts that could potentially have traffic blocked by SWG should be reachable by using the SWG testing tools such as ping and traceroute.
Required ports and URLs
Make sure all the required ports as listed on the Implementation Guide are allowed by local networking devices and that the SWG can reach the required URLs to transmit and receive information from the internet.
The mechanism used by SWG to block access to URLs when in blocking mode involves TCP session hijacking. This means that any device that prevents such thing on the ports SWG attaches to or, into the SWG traffic stream will also prevent SWG from working properly.
SWG functionality relies on proper and fast DNS resolution. The configured DNS servers should be within the same internal network topology and must be able to resolve local and non-local hostnames in an efficient way. SWG Interfaces that are enabled (may vary depending on the mode) should have corresponding A and PTR records on the DNS server.
If a proxy will be implemented as part of the solution, SWG's own proxy is strongly suggested.
When an external proxy is used to connect to the internet instead, it should be placed upstream of the SWG. The appliance must be properly configured to analyze that traffic and the proxy must not block any of the required ports and URLs.
Downstream web proxies will hide the source of the connections as all the traffic will be seen as coming from the proxy. Check Symantec Web Gateway (SWG) considerations and behavior when an external proxy is used
As of version 5.0.2, SWG has no built-in HA (High Availability) or Load Balancing feature.
It can rely on 3rd party Link Aggregation or Etherchannel load balancers.
To load balance SWG in inline mode, each host must function independently as a transparent bridge (OSI layer 2) with some requirements and caveats:
- The traffic passing through must be synchronous. This means that a GET request or sequence of packets going through a specific SWG must continue to flow or stream along that same host.
- The SWG hosts do not share traffic information to other SWGs on the network. For that reason, SWG only is aware of the traffic going through itself. This may affect some feature's behavior like botnet detection.
- The traffic to be load-balanced will still be bound to the default gateway's IP address, upstream of the SWG WAN port. Load balancing is not applied to the SWG's inline IP address.
Starting version 4.5.3, SWG supports VLAN traffic and can be deployed into a trunk port. For more details on VLAN settings, click the "Help" button available on the web interface inside the network configuration section of SWG.
Given the amount of variables and complexity involved into determining the requirements, the following numbers should be used only as a guideline.
|Target Customer size||<1,000||1,000 to 10,000||<700|
SWG basic configuration checks
The basic configuration will allow the administrator to confirm the SWG has been properly deployed by using some test features and monitoring tools. Some checks to be completed after the basic configuration has been finished are:
- Make sure cables are correctly attached to the right ports depending on the configuration selected on SWG
- Make sure the licenses have been installed and that is properly displayed on the GUI (go to Administration -> System Status)
- Make sure the Management interface and Inline interface have been configured with a name whenever is possible (go to Administration -> Configuration -> Network)
- Make sure the configured DNS servers and Active Directory servers can be reached from SWG by using the ping tool available into the GUI ( go to Administration -> Configuration -> Network)
- Make sure the configured networks and static routes properly reflect the topology you intend to protect.
- Make sure the network servers (email, proxy or other) are introduced into the Servers tab ( go to Administration -> Configuration -> Servers)
For SWG in Inline-only Mode:
- It is possible to configure the SWG in inline-only mode with no Management Interface enabled. While this makes the configuration less complicated, it is not recommended because it means that there is no second route to the interface if the LAN/WAN Bridge is not available.
- An SWG in inline mode uses NTLM 401 authentication. This is not supported by default on Windows 2008 and later platforms, and must be enabled manually.
- The user is identified by a transparent NTLM 401 challenge response operation when opening a new browsing session. It is important to enable NetBIOS name resolution on the Domain Controller to which the Web Gateway is sending it's NTLM requests. Otherwise the user will not be identified.
For SWG in Inline Mode and Inline + Proxy Mode:
- Make sure the cabling guidelines have been followed as detailed into the Implementation Guide. SWG must have 3 cables connected:
- Mgmt port
- Make sure all the required static routes the SWG needs to reach internal hosts are properly configured. Same tests apply when using a separate network for the management interface (required when the proxy feature is enabled).
- Ping clients to be protected by SWG on different subnets from the Inline interface make sure these are reachable (necessary for redirection to the blocking page).
- Check if network traffic is passing through the SWG. Create a basic policy to monitor all the traffic and make sure the service is enabled and the proper operating mode is set. If the traffic goes through an upstream proxy, check that the Proxy section includes the correct proxy port(s). Custom Reports entries should be populating with events that SWG is "seeing". You can customize the type of information displayed by clicking the "Change Columns" button at the top right of the screen. Is good practice to have the "Hostname" and "Local IP Address" columns visible.
- Test the bypass mode. When you configure the appliance in the inline network configuration, the appliance enters bypass mode if it cannot function or is turned off. In bypass mode, Internet traffic is routed through the LAN and WAN ports but no monitoring or blocking occurs. For bypass mode to function properly, ensure that you use the proper type of Ethernet cables to connect to the LAN.
- Make sure the Internal Network Configuration section includes all your internal networks. This helps SWG to properly identify what is coming from the inside vs. outside.
For SWG in Proxy-only Mode and Inline + Proxy Mode:
- Management interface and Inline interface(s) need to be on different subnets, but you must be able to route traffic between them for all functions to work correctly.
- The simplest solution is to install a router in NAT mode with it's internal interface on the same subnet as SWG MGMT, and it's external interface on same subnet as Inline interface(s). NAT should be enabled, and the MGMT subnet entered in the SWG config.
- Ensure that you can ping the following from both interfaces:
- DNS servers specified in the config.
- Domain Controllers servers specified in the config.
For more information on Proxy mode check Symantec Web Gateway (SWG) - Best Practices: Proxy Mode
For SWG in Port Span / Tap mode:
- Make sure the cabling guidelines have been followed as detailed into the Implementation Guide. SWG must have at least 2 cables connected:
- LAN ( Optional - see Implementation Guide for more information on this topic)
- Check if the traffic is "seen" by SWG. If the Tap port of the switch has been properly configured, the SWG should be able to "see" that traffic. Create a basic policy to monitor all the traffic and make sure the service is enabled and the proper operating mode is set. If the traffic goes through an upstream proxy, check that the Proxy section includes the correct proxy port(s). Custom Reports entries should be populating with events that SWG is "seeing". You can customize the type of information displayed by clicking the "Change Columns" button at the top right of the screen. It is good practice to have the "Hostname" and "Local IP Address" columns visible.
Article URL http://www.symantec.com/docs/TECH144596