Ports and Protocols to be allowed when using a proxy in a Symantec Endpoint Protection environment.
|Article:TECH131843|||||Created: 2010-01-20|||||Updated: 2011-12-26|||||Article URL http://www.symantec.com/docs/TECH131843|
What ports and protocols do I need to allow when using a proxy in a Symantec Endpoint Protection (SEP) environment?
- LiveUpdate or a SEP module is not working when using proxy in the network.
- Virus definitions are out of date.
- Virus definitions are not updating on the Symantec Endpoint Protection Manager (SEPM).
- Virus definitions are not updating on the Symantec Endpoint Protection clients.
- Some Symantec Endpoint Protection clients are not getting definition updates.
- LiveUpdate does not complete successfully.
Proxy servers usually block some ports and protocols to enforce network security.
A. It is recommended to bypass the proxy for internal communication:
-In Internet Options, under Connections, choose LAN settings. Under Proxy Server, under where your proxy server's information is been input, check the "Bypass proxy server for local addresses"
B. The solution may also need to done for the SYSTEM account, because when LiveUpdate is scheduled to run it uses the SYSTEM account by default:
Check the SYSTEM proxy settings by following these steps...
- Click 'Start' and click 'Run'
- Type at 12:00 /INTERACTIVE "C:\Program Files\Internet Explorer\iexplore.exe" in the 'Run' box and click 'OK'
- It will create a scheduled task.
- Go to 'Scheduled Tasks' folder in 'Control Panel'
- Right click the file named 'At1' and click 'Run'. It will open an Internet Explorer page.
- Click 'Tools' menu, click 'Internet Options' and click on the 'Connections' tab.
- Verify the connection settings and proxy settings.
Change SYSTEM account Connection settings to 'Never dial a connection'.
Repair the SEP client with Add/Remove Programs.
Run LiveUpdate (Start > Run > LUALL) to verify it updates successfully
C. Ports and Protocols to be allowed in the proxy rules:
|General communication via IIS||Between clients and Symantec Endpoint Protection Manager||HTTP (TCP)||80; 8014 for MR3 or higher|
|Secure communication via IIS (optional)||Between clients and Symantec Endpoint Protection Manager||HTTPS (TCP)||443|
|Internal communication via Apache||Manager to Manager, Console to Manager, Enforcer to Manager||HTTPS (TCP)||8443|
|Browser-based remote console via Apache||From browser to Manager||HTTP (TCP)||9090|
|Embedded database communication||From Manager to embedded database||TCP||2638|
|Microsoft SQL database communication||From Manager to Microsoft SQL database||TCP||1433|
|Group Update Provider||From Group Update Provider to clients||TCP||2967|
|Protection Manager SemSvc.exe||The Protection Manager listens on the Tomcat default port||TCP||8005|
D. Domain list to be allowed:
Confirm that the correct ports and protocols are available for LiveUpdate
Make sure that the proxy allows the LiveUpdate executable to connect to the Internet through the correct ports and that the proxy allows connections to the correct domains. Read your proxy's documentation or contact the manufacturer to find out how to confirm these settings.
- LiveUpdate connects over TCP ports 80 (HTTP), 21 (FTP) and 443 (HTTPS).
- The file that connects to the Internet is LuComServer_*_*.exe in LiveUpdate 2.5 and later and Lucomserver.exe in LiveUpdate 2.0 and earlier.
The default folder for this file is C:\Program Files\Symantec\LiveUpdate.
- LiveUpdate connects via HTTP to the domains symantec.com, liveupdate.symantecliveupdate.com, and akamai.net.
If a connection fails, LiveUpdate tries to connect to one of the other listed domains. The listed domains may change because of server maintenance.
If LiveUpdate cannot make an HTTP connection, LiveUpdate connects via FTP to update.symantec.com/opt/content/onramp.
Note: Symantec does not supply IP addresses for Symantec LiveUpdate servers because the servers are not static and thus routing directly to an IP address may cause LiveUpdate to fail.
E. Other SEP/SEPM internal communications:
Communication Between Symantec Endpoint Protection Manager and SQL Server
- What network connections exist between Symantec Endpoint Protection and a remote SQL server?
The protocol is TCP. The port is 1433 by default, and is configurable.
- Is there any encryption of the traffic between SQL and Symantec Endpoint Protection Manager?
- Is there any other encryption of sensitive data between Symantec Endpoint Protection Manager and the SQL server?
Policies are converted to binary data to transfer. All passwords are encrypted.
- Are SQL credentials passed unencrypted over the network?
- When Windows Authentication mode (NTLM) is used, the "sa" account password is not required, and the "sem5" account password is not transferred, so there are no security concerns.
- When SQL server Authentication mode or mixed mode is used:
In the Configuration wizard, if the user creates a new database (instead of using an existing one), the "sa" account password is needed. In this case, the sa password is sent to the SQL server without encryption. The sa password is not stored anywhere by the product, and is used only once.
Also, the "sem5" account password is unencrypted when creating a database connection for JDBC and ODBC and uploading logs through BCP.
It is possible to mitigate the issue by using JDBC's connection properties to secure the username and password, in most cases. However, BCP requires plain user name and password.
- Are Symantec Endpoint Protection Manager console credentials passed unencrypted over the network?
- The first console user is created in the configuration wizard, and the password is encrypted. The encrypted password is transferred when the console user logs on. After the user logs on, the user can create other users, and that password is encrypted and transferred.
Symantec Endpoint Protection Manager Communication
- How are certificates implemented on the Symantec Endpoint Protection Manager?
When the Symantec Endpoint Protection Manager console is installed and configured, a .jks certificate is generated and stored under the
/tomcat/etc directory. The public key of this certificate is stored in the database. This public key is sent to clients via the sylink.xml. All the profiles/contents/packages, etc. are signed by this server certificate. A client downloads the respective content and validates the content by using the public key stored in the sylink.xml and to ensure that client to server communication is secure.
- Where are these certificates stored?
Certificate store (jks file) is stored under
/tomcat/etc. Public key of the certificate is stored in the database.
- What algorithms are used?
keyAlg = "RSA"; keyLength = "1024"; signAlg = "SHA1withRSA"
- What are the key strengths?
The password is a generated string of length 16. The key store password and key password are the same. The keyStorePath and kesyStorepassword are stored under
/tomcat/conf/Server.xml in encoded form, usingBASE64Encoder.
- Are self-signed certificates used?
Yes. Right now when we install a SPC server , a self-signed certificate is auto generated and placed under
/tomcat/etc . We also give an option to the user to import third-party certificates through SPC console. The certificate can be backed up through the SPC console.
- Where is the root certificate stored?
Certificate store (jks file) is stored under
Communication Between Symantec Endpoint Protection Managers
Are any other ports used besides TCP port 8443?
Port 8014 is used for client-to-server communication. Port 8443 is used for HTTPS communication (local console/ remote console to SPC). Port 8765 is used as a server control port, which is used to stop the Tomcat server.
Communication Between Symantec Endpoint Protection Client and Symantec Endpoint Protection Manager
- Clients connect to IIS on port 80 (8014 in post MR3 builds) in the Symantec Endpoint Protection product. How is data content secured?
Symantec Endpoint Protection server and clients while transmitting data using HTTP/HTTPS protocol possess the following data security design goals:
- Data obfuscation:
Data transmitted between Symantec Endpoint Protection Manager and Clients are always obfuscated using an encryption password (a.k.a. KCS key), thereby preventing malicious users from seeing the data content easily. We use the Twofish tool to encrypt the data. The Client uses the same encryption password to decrypt the data. For example, the profile.xml is zipped and then encrypted into the profile.dax file.
- Tamper protection:
The Symantec Endpoint Protection server uses the certificate to create the SHA1 signature (e.g., index2.dax.sig), and the client uses the certificate to verify the signature, thereby ensuring data integrity and preventing the data tampering.
- Data obfuscation:
Communication With Symantec Endpoint Protection Remote Console
- What are the stages of communication - we are told that port 9090 is used initially, then 8443 is used. Some detail on this flow please.
- Port 8443 is used for HTTPS communication between Console and server.
- Apache port 9090 is used for Remote Console WebStart. Once the Remote Console process is started, our Java code takes place and uses port 8443 to communicate to the server, the same way the local Console does.
- Port 9090 is also used by the HELP system for the HTML pages.
- How are credentials and any sensitive information secured at each phase?
Since the Console users HTTPS to communicate to the server, the data is secured during the transmission. The reporting (PHP) components use only HTTP to communicate to the server. An issue with the JDIC prevents us from using HTTPS,
Note: User name and password are not transmitted in clear text. They are blowfish encrypted using the session ID as a key.
As a mitigation, you can create restricted privilege Symantec Endpoint Protection accounts that have only the reporting functionality as their capability, but you can't get cross-domain reports with these restricted accounts.
LiveUpdate Administrator 2.x (LUA 2.x)
- How are logon credentials secured?
C:\Program Files\Symantec\LiveUpdate Administrator\tomcat\webapps\lua\jslib
- Where are credentials stored?
The credentials are stored in PostgreSQL database in adm_user table. The SHA-1 value of the password is stored in database. Note that the basis here is that it is practically impossible to reverse calculate the actual value of password given its 64 bit SHA-1 value. The user id is stored in clear text. Whenever a user tries to log on, the SHA1 value of the password entered is compared against the SHA-1 value of the password stored in the database for the corresponding user. If the value matches, then the logon is successful.
- Are these credentials securely stored?
Yes. Please refer the description in question 2 above.
F. Troubleshooting communication issues with LiveUpdate:
- Troubleshoot Communication issue:
- Make sure that you are able to browse to the websites below:
- Make sure that the perimeter firewall has exceptions for the websites above
- Run a packet capture and contact support for analysis
- Check Connectivity between Symantec Endpoint Protection client & Symantec Endpoint Protection Manager:
- Do a Secars test to Test Connectivity between Symantec Endpoint Protection client and Symantec Endpoint Protection Manager
- Other client/server connectivity troubleshooting
- Endpoint Protection Manager communication troubleshooting
- Get the SylinkMonitor logs to check the communication for any errors
- Remove corrupt definitions
- Check if the Symantec Endpoint Protection Manager has the latest definitions:
- Open the Symantec Endpoint Protection Manager
- Click on the Admin Tab
- Click on Servers
- Click on Local Site
- Click Show Liveupdate Downloads
- Make sure that the date for 32 bit and 64 Definitions for ‘Virus & Spyware Definitions’ is up-to-date
- How to read the Log.liveupdate and SESMLu.log of Symantec Endpoint Protection Manager:
- Make Sure proxy settings are configured in Symantec Endpoint Protection Manager:
Internet Explorer Uses Proxy Server for Local IP Address Even if the "Bypass Proxy Server for Local Addresses" Option Is Turned On
SEP 11 Documentation guides (Administration and Installation)
Symantec AntiVirus Corporate Edition Reference Guide
- Chapter 6, Cryptography basics
- Chapter 8, How certificates are implemented
Article URL http://www.symantec.com/docs/TECH131843