1 Services Deployment Administrator Guide
2 Services Deployment Guide Documentation version: 1.0 Legal Notice Legal Notice Copyright 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, the Checkmark Logo and are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. Symantec Corporation 350 Ellis Street Mountain View, CA Clients are advised to seek specialist advice to ensure that they use the Symantec services in accordance with relevant legislation and regulations. Depending on jurisdiction, this may include (but is not limited to) data protection law, privacy law, telecommunications regulations, and employment law. In many jurisdictions, it is a requirement that users of the service are informed of or required to give consent to their being monitored or intercepted for the purpose of receiving the security services that are offered by Symantec. Due to local legislation, some features that are described in this documentation are not available in some countries. Configuration of the Services remains your responsibility and entirely in your control. In certain countries it may be necessary to obtain the consent of individual personnel. Symantec advises you to always check local legislation prior to deploying a Symantec service. You should understand your company s requirements around electronic messaging policy and any regulatory obligations applicable to your industry and jurisdiction. Symantec can accept no liability for any civil or criminal liability that may be incurred by you as a result of the operation of the Service or the implementation of any advice that is provided hereto. The documentation is provided "as is" and all express or implied conditions, representations, and warranties, including any implied warranty of merchantability, fitness for a particular purpose or non-infringement, are disclaimed, except to the extent that such disclaimers are held to be legally invalid. Symantec Corporation shall not be liable for incidental or consequential damages in connection with the furnishing, performance, or use of this documentation. The information that is contained in this documentation is subject to change without notice. Symantec may at its sole option vary these conditions of use by posting such revised terms to the website.
3 Technical support If you need help on an aspect of the security services that is not covered by the online Help or administrator guides, contact your IT administrator or Support team. To find your Support team's contact details in the portal, click Support > Contact us.
5 Contents Technical support... 3 Chapter 1 About deploying Services... 7 Deploying Services step-by-step... 7 Attend training on the portal Configuring the cloud Services Chapter 2 Configuring your mail setup Pre-implementation checks Technical checks Redirecting inbound traffic to the Services infrastructure Important notes on changing MX records Restricting your traffic About configuring outbound traffic (optional) Testing outbound mail Cloud security services IP ranges Restricting open relay Chapter 3 Configuring MS Exchange Configuring Microsoft Exchange 2003 for inbound mail Configuring Microsoft Exchange 2003 for outbound mail Configuring Microsoft Exchange 2007 and 2010 for outbound mail Chapter 4 Configuring your public hosted cloud services Configuring Google Apps for inbound mail Configuring Google Apps for outbound mail Configuring Microsoft Office 365 for inbound mail Configuring Microsoft Office 365 for outbound mail... 35
6 6 Contents
7 Chapter 1 About deploying Services This chapter includes the following topics: Deploying Services step-by-step Attend training on the portal Configuring the cloud Services Deploying Services step-by-step You should have received a confirmation that contains the information that you need to deploy Services: The default and backup MX record data The default mail route The following phases are involved in deploying Services: Pre-provisioning phase: you have probably already completed these steps. Provisioning phase: your Services supplier performs these steps. Implementation phase: you carry out these steps. Step Table 1-1 Pre-provisioning phase Further information 1. Complete a provisioning form. Send the form to your account manager.
8 8 About deploying Services Deploying Services step-by-step Step Table 1-1 Pre-provisioning phase (continued) Further information Attach your signed contract along with the completed provisioning form. Attach a list of valid addresses for the Address Registration functionality along with the completed provisioning form. For further information, see the Help on Address Registration. 4. To ensure that your account is set up as soon as possible, we recommend steps to take before you submit your technical details. See Pre-implementation checks on page 15. Table 1-2 Provisioning phase Step Technical checks are carried out on the IP address and domain names you have provided in your provisioning form. These checks ensure that we can provision your organization for Services. If a check fails for any reason, we inform you of the reason by . You must inform us when you have resolved the issues, so that we can recheck your information. Your account is provisioned on the Services infrastructure. We send you a confirmation that provides your portal login details. The also contains the data and information that you need to change your MX records and to lock down your firewall. Warning: Ensure that this is not detected as spam or junk . The contains important information. Further information See Technical checks on page We send your cleaned and uploaded address list as a CSV attachment to your confirmation for you to check. For further information, see the Help on Address Registration.
9 About deploying Services Deploying Services step-by-step 9 Table 1-3 Implementation phase Step 1. Check your address lists 2. Review your inbound and your outbound routes for traffic Description Review, modify, and save your address list for each of your domains. In the portal, click Services > Services > Platform. Your list of valid addresses ensures that you only receive for legitimate users in each domain in your organization. Security drops any s that are sent to addresses on your domain that are not registered for your organization. You can manage this list yourself in the portal or use the Synchronization Tool. Review your inbound and your outbound routes for your domains. In the portal, click Services > Services > Inboundroutes and Outbound routes. Further Information 3. Check your service configuration settings When Services are fully deployed, the AntiVirus and AntiSpam services are automatically active. They are configured with default settings. Your inbound (and outbound , if provisioned) automatically pass through the cloud security services scanners. To customize the settings for AntiVirus and AntiSpam, make the necessary configuration changes before you change your MX records. See Attend training on the portal on page 13. See Configuring the cloud Services on page 13. In the portal, click Services > Services.
10 10 About deploying Services Deploying Services step-by-step Step Table 1-3 Description Implementation phase (continued) Further Information 4. Setting up Spam Quarantine Spam Quarantine enables your organization's users to view the s that the AntiSpam service has detected as spam. These s are viewable in a portal called Spam Manager. If you have Spam Quarantine enabled, Quarantine the mail is an action in your AntiSpam Detection Settings page of the portal. If Spam Manager is not enabled and you want it to be, contact: Global Client Service Initiatives For Spam Quarantine, you must have Address Registration enabled and active. The URL for Spam Manager is provided in your welcome . It has the following format: https://spammanager-xxx.messagelabs.com/login.xsp Note: If you are an existing customer adding a new domain, check your current Spam Manager URL. Use the same URL for your new domain.
11 About deploying Services Deploying Services step-by-step 11 Step Table 1-3 Description Implementation phase (continued) Further Information 5. Redirect your inbound traffic to the Symantec.cloud infrastructure. Complete the following MX record changes within five working days of receiving your confirmation . It may take up to 24 hours for MX record changes to result in full propagation. Make sure that any previous MX records in place are NOT removed until the change to Symantec.cloud has fully propagated. When the records are propagated, ensure that there are no back-up MX records left in place. If an external organization (e.g. your ISP) manages your MX records, ensure that this information is passed on to them. Define the MX records for your domains. These are provided in you Welcome . They use the following format: See Redirecting inbound traffic to the Services infrastructure on page 18. Lowest MX preference (default mail route): MX 10 clusterx.xx.messagelabs.com Second MX preference (back-up mail route): MX 20 clusterx.xx.messagelabs.com Note: When Services are provisioned and before your MX records are changed, Symantec.cloud may process some of your . s that are sent to your domain(s) by other Services customers who are provisioned on the same infrastructure as you are processed. The portal Dashboard and reports may show that has been received before the MX change.
12 12 About deploying Services Deploying Services step-by-step Step Table 1-3 Description Implementation phase (continued) Further Information 6. Configure your SMTP server or public hosted cloud service for inbound traffic. 6. Redirect your outbound mail traffic (optional) Note: We recommend that you make this redirection the first of the technical changes of the implementation process. You can perform it immediately. And it provides a good test of your client-side technical changes; outbound traffic is generally quieter than inbound traffic. Allow to come into your organization only through the Services infrastructure by defining an allow list in your firewall or your mail server. Or for public hosted cloud services, you configure inbound traffic in the portal. Configure your organization s SMTP server to have your outbound scanned. Use your assigned cluster host name rather than a single IP to ensure security and resiliency. The cluster host name is provided in your Welcome . It uses the following format: Relay outbound mail traffic to: clusterxout.xx.messagelabs.com Relay outbound mail traffic to: clusterxout.xx.messagelabs.com Reduce TTL (time to live) and DNS cache to its lowest possible setting (recommended 5-15 minutes). Configure your public hosted cloud service for outbound traffic in ClientNet. See Configuring Microsoft Exchange 2003 for inbound mail on page 27. See Configuring Google Apps for inbound mail on page 33. See Configuring Microsoft Office 365 for inbound mail on page 35. See About configuring outbound traffic (optional) on page 22. See Configuring Microsoft Exchange 2003 for outbound mail on page 28. See Configuring Google Apps for outbound mail on page 34. See Configuring Microsoft Office 365 for outbound mail on page Restrict SMTP traffic We recommend that you lock down port 25 SMTP traffic to and from your Internet gateway to the following IP ranges: See Restricting your traffic on page 21. Symantec.cloud IP Ranges Locking down port 25 prevents spam and viruses being sent directly to or from your mail server. It also enables us to balance traffic across the infrastructure if Internet conditions require it. For example, during mass mailer outbreaks, dictionary attacks, and denial-of-service attacks. Warning: If you do not accept from these IP ranges, there is a risk of partial failure.
13 About deploying Services Attend training on the portal 13 Caution: Once you have deployed your Services, your mail is scanned for viruses and spam. The AntiVirus and AntiSpam services are enabled and default settings are in place. The default settings include disclaimers and alert notifications. If you do not want to use the default disclaimer or alert notifications, change the necessary settings in the portal before you change your MX records. The Image Control and Content Control services are not active until you enable them in the portal Services pages. See Configuring the cloud Services on page 13. Attend training on the portal The portal gives you direct access to your account configuration. It lets you review the performance of the Services for your business. We recommend that you take advantage of the live WebEx sessions, which last for approximately 30 minutes each, to help you use the portal to optimize your services. For timings and access details, see Live Webinar: Cloud security services. The WebEx session covers: Service Overview: which services are included and how s are scanned Service Implementation: service defaults and portal configurations Service Optimization: portal optimization, account administration, and service continuance Tools and Resources: online self-service tools and getting support Portal Demonstration: portal URL, login requirements, and navigation tips Questions and Answers See Configuring the cloud Services on page 13. Configuring the cloud Services When Services are fully deployed, the AntiVirus and AntiSpam services are automatically active. They are configured with default settings. Your inbound (and outbound , if provisioned) passes through the cloud security services infrastructure. To customize the settings for AntiVirus and AntiSpam, make the necessary configuration changes before you change your MX records.
14 14 About deploying Services Configuring the cloud Services Note: To use the Image Control and Content Control services, you must first configure and enable them in the portal. For further information on Services, see Help on cloud security services. Note: We support public hosted cloud services from Google Apps and Microsoft Office 365. To scan inbound mail on a public hosted cloud service, you must configure an inbound route in the portal. If your organization needs to scan your outbound mail from a supported public hosted cloud service you must also configure an outbound route. See Redirecting inbound traffic to the Services infrastructure on page 18.
15 Chapter 2 Configuring your mail setup This chapter includes the following topics: Pre-implementation checks Technical checks Redirecting inbound traffic to the Services infrastructure Important notes on changing MX records Restricting your traffic About configuring outbound traffic (optional) Testing outbound mail Cloud security services IP ranges Restricting open relay Pre-implementation checks Before we complete the setup of Services, we perform certain tests. To ensure that your account is set up as soon as possible, we recommend steps that you can take before you submit your technical details.
16 16 Configuring your mail setup Pre-implementation checks Table 2-1 Check Pre-implementation checks Test Preparation Connectivity Domain check Open relay The connectivity check is an important part of the cloud security services setup. It checks that we can successfully deliver mail to your specified IP address. When performing this test, we try to deliver a test through port 25 to the postmaster address at the IP address you have provided. The domain check tests that the domains you want to use with the cloud security services are registered. The cloud security services performs a DNS check to ensure that the domain is registered. The open relay test concerns the IP addresses you want to send outbound mail from. An open relay server is an SMTP server configured for people outside of your organization to send mail through. Open relay is commonly exploited by spammers and therefore presents a security threat. To minimize the chance of this test failing, ensure that you allow the cloud security services IP ranges through your security device, such as your firewall. These IP ranges vary according to region. They can be found at: Cloud security services IP Ranges. Also ensure that your mail server is configured to relay for all domains you want to use. If a domain has not been configured but you want to proceed with the setup, inform us when completing the provisioning form. Ensure that any domains you want to use are valid and registered. Ideally, they should also have MX records present. Ensure that you have configured your mail server so that it only accepts from local addresses. If you are unsure whether your IP is an open relay, there are several Web-based tools you can use to check this, e.g.
17 Configuring your mail setup Technical checks 17 Table 2-1 Pre-implementation checks (continued) Check Test Preparation Blacklists When you add a new IP address to the Services infrastructure, we test to ensure that the IP address is not blacklisted on CBL, SBL, Spamcop, or DSBL. You can check whether your IP address has been blacklisted or not with the following sites: CBL (http://cbl.abuseat.org/) SBL (http://www.spamhaus.org/sbl/) Spamcop (http://spamcop.net/bl.shtml) DSBL (http://dsbl.org/main) Note: If your IP address is listed, we recommend that you find out why your IP address was blacklisted to prevent it happening again. See Technical checks on page 17. Technical checks The IP addresses or mail hosts and domain names that you have provided to us must pass a series of technical checks before you are provisioned with our Services. If the technical checks all complete successfully, the Provisioning Team sets up your domains on the cloud security services infrastructure. We then send a confirmation that provides your portal logon and the data and information that you need to change your MX records and to lock down your firewall. If a test has failed, you are asked to make the changes necessary to remedy the issue so that the services can be activated. The technical checks that are performed depend on the information provided, but are summarized in the following table. Table 2-2 Technical checks Domain checks: Checks that the domain is registered with the Domain Name Server (DNS) Checks that the Services are not already scanning the domain
18 18 Configuring your mail setup Redirecting inbound traffic to the Services infrastructure Table 2-2 Technical checks (continued) IP checks: Checks that open relay is not allowed Checks that your IP addresses are from valid ranges Checks that your IP addresses are not blacklisted Checks connectivity with the cloud Services infrastructure Warning: You must ensure that your SMTP server does not allow open relay. If it does, your server can be used as a spam gateway. Most current SMTP servers and firewalls allow the restriction of SMTP relay in the following ways: by IP number (so you only accept mail from our IP addresses) or by domain (so you reject that is destined for domains other than your own). See Pre-implementation checks on page 15. See Restricting open relay on page 25. Redirecting inbound traffic to the Services infrastructure To redirect your inbound traffic to the Services infrastructure, you must change your MX records. You must change your MX records for both an SMTP server and a public hosted cloud service such as Google Apps , or Microsoft Office 365. An MX record is a type of resource record in the Domain Name System (DNS) that defines how is routed. MX records point to the servers that should receive and define their priority relative to each other. Your MX records need to route your inbound through the cloud security services infrastructure, where Services scan the s. The clean s continue on to your recipients. To route your through the cloud security services infrastructure, your MX records must change to the values that we give you to ensure that all of your is scanned. They are used as pointers to where your s are delivered. To route your through Services, change the primary and the secondary MX records for your domains to the MX records that we provide you with. These are in your confirmation from us. Your New Customer confirmation contains the exact MX information that you should use. Caution: Check that the confirmation is not delivered to your spam folder. This contains very important information.
19 Configuring your mail setup Redirecting inbound traffic to the Services infrastructure 19 First, identify who hosts your domains; that is, the person or organization that is responsible for maintaining your organization s MX records or DNS settings. Your Internet service provider (ISP) may be responsible for your MX records. Typically, each provider supplies an online form to make changes. Or you may have to notify them that you require a change to your MX records. A typical set of MX records before you modify them to use Services may look like the examples in the following table. Table 2-3 MX records example Mail route Primary (lowest) MX preference (default) Second MX preference (back-up) MX record MX 10 mailhost.domain.com MX 20 relay.isp.com The new MX record entries that you should use are in the format that is shown in the following table. Table 2-4 MX records example Mail route Primary (lowest) MX preference (default mail route) Second MX preference (back-up mail route) New MX record MX 10 clusterx.xx.messagelabs.com MX 20 clusterxa.xx.messagelabs.com Ensure that these changes are completed within five working days of receiving your confirmation and that no back-up MX records remain in place. Note: As soon as the MX record changes have been made and have propagated, the Services start scanning the s that your domain receives from external senders. When Services are fully deployed, the AntiVirus and AntiSpam services are automatically active. They are configured with default settings. Your inbound (and outbound , if provisioned) passes through the Services infrastructure. To customize the settings for AntiVirus and AntiSpam, make the necessary configuration changes in the portal before you change your MX records. See Restricting open relay on page 25.
20 20 Configuring your mail setup Important notes on changing MX records Important notes on changing MX records Use only the MX records specified in your New Customer confirmation so that we can scan all of the destined to your network. The presence of non-cloud security services entries in your MX records, e.g. mailhost.your-domain.com or isp-relay.your-domain.com is a security risk. Spammers, virus writers, and fraudsters often target back-up MX record entries in an attempt to bypass the cloud Services. In this way, spam or other malicious content can be delivered to your organization directly. Your MX records should never include an entry for your mail server or any type of mail relay. It can take up to 24 hours for MX record changes to result in full propagation. However, you should allow 72 hours for changes to fully propagate across the Internet. Full propagation means that the cloud Services can scan all that your domain receives from external sources. Once your organization is provisioned with cloud Services, it is possible that we could process some of your before you have changed your MX records. This is the case if another cloud Services customer is provisioned on the same cluster as your organization. An that is sent to one of your domains by another customer passes through the scanners on its way out from the sending customer. We identify that your domains are provisioned on our system and route those s through your inbound policies and onto your provisioned gateways. So, an that is sent from another of our clients to you on your cluster means that your service configurations are applied. You may experience the following: Your disclaimers are applied. See Services > Services > disclaimers. Your AntiSpam detection settings filter spam The inbound Content Control rules that you have defined are applied Your inbound Image Control settings are applied Address Registration is operational. Your up-to-date address list must be applied. Otherwise, an that is sent from another client on your cluster is blocked because it is not found in your address list. Inbound size restrictions are applied. See Services > Services > Anti-Virus > Virus Settings. Your dashboard and reports may show that has been received for you An that is sent to you from another of our clients that is on the same cluster as you is delivered to your provisioned Mailhosts.
21 Configuring your mail setup Restricting your traffic 21 Caution: If you have asked us to send to a Mailhost that is not yet ready to accept mail, contact us immediately. See Redirecting inbound traffic to the Services infrastructure on page 18. See Restricting open relay on page 25. Restricting your traffic To ensure that your inbound s do not bypass Services, you must restrict the IP addresses you allow traffic from to the cloud security services IP ranges. By allowing s to be received only from our IP ranges, you prevent spammers bypassing the scanning service and sending mail directly to your server s IP address. Only port 25 traffic needs to be "locked down" to accept the cloud security services IP addresses. Caution: The mail server (or firewall) configuration changes given here should be completed only after full MX record propagation is complete. Allow 72 hours from your MX records having been changed for full propagation across the Internet. Depending on your organization s IT setup, you must define the IP ranges to use in your mail server, firewall, or public cloud hosted service, or any combination of these. The IP ranges that you need to configure in the allow list of your firewall, mail server, or public cloud hosted service are listed in cloud security services IP ranges. This document is also available from a link in your welcome . Note: Due to the diverse range of mail servers and firewalls in use, we cannot provide instructions or support for the configuration of IP address allow lists in firewalls or mail servers. Contact your IT department or IT consultant for assistance. However, basic instructions are provided for Microsoft Exchange See Redirecting inbound traffic to the Services infrastructure on page 18. See Configuring Microsoft Exchange 2003 for inbound mail on page 27. See Configuring Microsoft Exchange 2007 and 2010 for outbound mail on page 30.
22 22 Configuring your mail setup About configuring outbound traffic (optional) See Configuring Google Apps for inbound mail on page 33. About configuring outbound traffic (optional) All of our clients use Services for inbound scanning, and most also use the services for outbound scanning. Outbound scanning is included with your service at no additional charge, but using this feature is optional. We advise that you send your outbound through the cloud Services infrastructure to ensure that no viruses are sent out from your network. You can then be sure that we have scanned any that is sent from your organization. One threat is the exploitation of domains to spoof to appear as if it is sent from your organization. Outbound scanning also helps enforce policies if you use the Image Control and Content Control services. To have your outbound scanned, you configure your organization's SMTP server or your public hosted cloud service to send through the cloud security services infrastructure. To do so, you define the IP ranges for outbound traffic in your mail server, depending on your mail server configuration. This involves creating a mail route, for example in the following format: clusterxout.xx.messagelabs.com Refer to your New Customer confirmation for the exact outbound Mailhost information to use. Note: Due to the diverse range of mail servers in use, we cannot provide instructions or support for the configuration of IP addresses in mail servers. Contact your IT department or IT consultant for assistance. However, basic instructions are provided for Microsoft Exchange 2003, 2007, and 2010, and for the public hosted cloud services we support. See Configuring Microsoft Exchange 2007 and 2010 for outbound mail on page 30. Testing outbound mail See Configuring Microsoft Exchange 2003 for outbound mail on page 28. See Configuring Google Apps for outbound mail on page 34. You can spoof the sending of an using telnet to test that it is correctly routed through Services.
23 Configuring your mail setup Testing outbound mail 23 To test outbound mail 1 Type the following command using the outbound mail route provided: telnet clusterxout.xx.messagelabs.com 25 If the connection is accepted, the remote server responds: Trying (remote server IP) Connected to clusterx.xx.messagelabs.com. Escape character is '^'. 220 server-4.tower-50.messagelabs.com ESMTP 2 Type a valid helo command (helo and a word of more than five characters): helo mail.customer.com The remote server responds that the SMTP conversation has started: 250 server-4.tower-50.messagelabs.com 3 Type in a valid address at your domain: mail from: The remote server responds: 250 OK 4 Type an external address here: rcpt to: 250 OK 5 Then type: data This instruction tells the remote server that data is due to be received. The remote server responds: 354 go ahead