Endpoint Protection

I recently upgraded one of my clients from Symantec Antivirus 10.1 to Symantec Endpoint Protection 12.1.  Technically speaking, I completely uninstalled SAV, rebooted all systems, and then installed SEP.  Since SEP includes a firewall, I disabled the Windows Firewall and enabled the SEP firewall.  Since then, users have been complaining about application lockups and lost data.

The server has the SEP basic package (AV only) -- the server does NOT have the firewall installed.  Only the clients have the full SEP package.

Using Sysinternals' Process Monitor, I was able to see that when the application appears to lock up, it's really in an endless loop trying to read a file (but the ReadFile() function returns with result DISCONNECTED).

Using the server's Computer Management snap-in, I was able to see that the client's session is being closed after approximately 10 minutes of idle time, even if the session has open files.  With the SEP firewall disabled, the session stays open for as long as necessary, but with the SEP firewall enabled, the session is always closed after approximately 10 minutes of idle time, causing the client to lose any unsaved data in those open files.

The users do not have a problem reconnecting to the server.  Once they terminate the not-responding application, they can open it again and immediately re-open the file.  The problem is that the session is being closed, forcibly closing the application's open files.

It appears that the SEP firewall also randomly terminates the client's session to the server.  I created a utility which runs "net view \\server" every 3 minutes, and this keeps the session's idle time to 3 minutes or less.  It seems to have helped, but the sessions are still being randomly disconnected (it's just not happening after 10 minutes of inactivity now).

To make myself perfectly clear, it is the SEP firewall on the client computer which is closing the session to the server after approximately 10 minutes of network idle time.  It has nothing to do with the server (to verify this, I mapped a drive to a server which has no antivirus or firewall installed and opened a file from that drive, and the same thing happened).  With the SEP firewall disabled, there are no session/disconnection problems.

When the session is disconnected, there are no events in any of the SEP logs or the Windows event logs.

I have confirmed this behavior when using Windows XP Pro SP2 (32-bit), Windows XP Pro SP3 (32-bit), and Windows 7 Pro SP1 (32-bit) clients and Windows XP Pro SP3 (32-bit), Windows 2000 Server SP4, and Windows Server 2003 R2 SP2 (32-bit) servers.

I like the powerful control, easy application, and easy administration of the SEP firewall, but if I can't find a solution to this, I'll have no choice but to go back to using the Windows Firewall.

Has anyone else experienced these issues, and does anyone know of any possible solution (other than going back to the Windows Firewall)?

Hi,

I think with the level of analysis made by you, you can call the Tech Support for further investigation.

This is most likely because SEP uses statefull packet inspection. If the client doesn't reconnect the session to the server, the traffic from the server will be dropped after a certain period of time unless there is a rule that specifically allows this inbound traffic from the servers.

Try creating an allow rule from the server to the clients on the ports you need open and it should work.

http://www.symantec.com/business/support/index?page=content&id=TECH94334&actp=search&viewlocale=en_US&searchid=1335989631496

Torb

This is most likely because SEP uses statefull packet inspection. If the client doesn't reconnect the session to the server, the traffic from the server will be dropped after a certain period of time unless there is a rule that specifically allows this inbound traffic from the servers.

There already is a rule (above the blue line) allowing File and Printer Sharing from the server to all clients.  This rule works perfectly.  The issue is not a problem with the server connecting to the clients.

Also, the problem is not that the client is not reconnecting the session.  The problem is that the SEP firewall is forcibly closing an open session.

Using the server's Computer Management snap-in, I was able to see that the client's session is being closed after approximately 10 minutes of idle time, even if the session has open files. With the SEP firewall disabled, the session stays open for as long as necessary, but with the SEP firewall enabled, the session is always closed after approximately 10 minutes of idle time, causing the client to lose any unsaved data in those open files.

* * * * * * * *

Are you talking about terminal services (remote desktop sessions) to the server, from a client machine.  After 10 minutes of idle time in the terminal session the connection is closed? 

As a second test, you created the network share and opened the file. 

* * * * * * * * *

I just want to be sure, I am on the same page as you.

* * * * * * * * *

Now, depending on the firewall (security software) there is a pre-defined Timeout period for keeping a port open on an idle connection before it is released.  Tihs is done by design as keeping an open port on an idle connection is considered a security threat. 

Is this the case in your scenario?  Possibly.  Investigation would be necessary.  In most cases, the idle timeout for a port can be anywhere between 10 minutes and 60 minutes.  The longer, however the port remains open, the "greater" the security risk to the node which is maintaining said port open.

** Edit **

Here is a link to an older thread, indicating that in 2009, the SEP Firewall timeout was set to 4 minutes of Idle before closing a TCP session.

https://www-secure.symantec.com/connect/idea/firewall-stateful-connection-timeout

Has this increased?  Possibly, if you are indicating now close to 10.  I am looking if there is anyway to increase said timeout.  But, I have to come accross anything.  It may need to be engineered into the system.

I will update you if I find anything.

** Edit again **

http://www.symantec.com/business/support/index?page=content&id=TECH94334

From symantec.  This is a known behavior and confirmed timeout is 5 minutes.  They do provide a workaround/solution and explanation to your issue.

Are you talking about terminal services (remote desktop sessions) to the server, from a client machine.

No, I am talking about SMB connections (File and Printer Sharing).

For example, if I open an application and use that application to load a file from the server, then the SMB session is closed after approximately 10 minutes of inactivity, forcibly closing any open files (so when you go to save the file, you get an error because the file is no longer open).

Similarly, if I open the Computer Management snap-in on the client and connect it to the server (via "Connect to another computer"), then the SMB session is closed after approximately 10 minutes of inactivity, forcibly closing the open pipe (so when you hit F5 to refresh, you get an error because the pipe is no longer open).

Well, it was bound to happen.  After dealing with this for just under two weeks, I've been ordered to disable the SEP firewall and go back to using the Windows Firewall.  I can' t say that I blame my client.  After dealing with lockups and lost data, significantly reducing their efficiency and rapdily increasing their frustration, they finally reached the breaking point.  I can't say that I'm too disappointed either, since I've already wasted over 80 hours on this that I won't get paid for.  I'm lucky I still have a job.

Before the decision was made, I was able to run a few more tests, and on at least one system, the sessions are no longer being disconnected after 10 minutes...  Now they're disconnected completely at random -- it could be 10 minutes, could be 30 minutes, could be over an hour -- doing the same thing, opening the same file.  Disable the SEP firewall, and everything works perfectly.

We're not talking about a complicated setup; we're talking about using file and printer sharing to open a file on a server.  If SEP can't even handle this properly, how it is supposed to handle anything?  Then again, it was clear to me that the SEP firewall is not a good firewall to begin with when its "stateful" nature overrides rules you (as the administrator) create.  For example, create a rule to explicitly block incoming traffic from port 80.  Now open a web browser and make a request.  You guessed it, the response is let through.  What kind of security is it when the firewall overrides rules the administrator creates?  None.

After dealing with this, it's quite clear to me that the SEP firewall is neither stable nor reliable.  I'm seriously regretful that I recommended SEP in the first place.  I know my client regrets it, especially having to shell out the cash for a dedicated management system (since the SEP management application's resource usage renders a system unusable for anything else) and paying for a three-year subscription.

Symantec Antivirus was a great product.  Yes, it was slower than its competitors, but the system center management application made it worth it.  With SEP, my clients are complaining that their computers are slower than before, applications are locking up and losing data, and you need a dedicated management system (you need 2GB memory to manage a security application?  Seriously?).  With the SEP management system, you can't even see how the clients are configured, nevermind configuring the clients individually like you could with SAV/SSC.

SEP is a serious step backwards from SAV.

Hi,

I believe you should open a ticket with the tech support to go deeper in the investigation, if something needs to be improved, we should had the opportunity to work on it.

In regards of the comparison you made between SAV and SEP, you should consider a couple of things:

- SAV is not up to the current threat landscape, the malware evolved e much more complex security technologies are required, SEP 12.1 brings them;

- the SEPM is not only a policy manager like the SSC, it is a logging server too, this is its most expensive role, you may not need it but the market wants as much integration as possible in the products.

I believe you should open a ticket with the tech support to go deeper in the investigation, if something needs to be improved, we should had the opportunity to work on it.

Opening a ticket would be meaningless since my client has decided they do not want to use the SEP firewall.  As such, there would be no testing and no further investigation on our part.

Nobody is stopping you from improving your product.  However, my client is not willing to deal with application lockups and lost data to help you improve your product, and I am not willing to waste my time to help you improve your product.  That's what you have beta testers for.  Now, if you would be willing to compensate my client for their lost productivity, and pay my hourly rate for my time, then we can talk, but I think we both know that's not going to happen.

Since you brought up the point of integration, SEP is actually a step backwards in terms of integration in at least two aspects.  First, with SEPM, you can only see basic things such as if auto-protect is enabled or if the firewall is enabled; you cannot see what I consider necessities, such as the client's auto-protect configuration, firewall configuration, and firewall rules (in a mixed- or client-mode setup).  Second, with SEPM, you cannot configure the client-side settings in a mixed- or client-mode setup.  SSC allowed you to view and configure the client-side settings.  SEPM has actually removed what I consider vital integration (features that I relied on with SSC).  It is ridiculous that I, as the network administrator, cannot see how the clients are configured without walking around to each computer.

You should not assume that what you are facing is faced by everyone else (like the beta testers or Symantec employees).

Of course, we don't want you to waste time and productivity, I do believe that if you open a ticket, providing the material you've already collected will be useful to start the investigation on our side. In the worst case, we may ask you to reproduce the issue on a single test machine, not in the whole office, to collect some ad-hoc debugging logs.

The concepts behind the current SEP design are the following:

- having a control of each single setting in each single client in SAV was powerful but at the same time hard to maintain and troubleshoot, to know the settings of a single client it was required to browse several panels in a UI not always coherent; in SEP, the settings applied to a client are the policies applied to its group (server mode), in my opinion it is a good simplyfication;

- mixed or client modes assume that what you leave customizable to your users, is something you don't need to control because not critical for you, otherwise, you can still lock down almost each setting you want to prevent changes by users or use only the server mode.

In other words, I believe SEP is still flexible but with a more structured usage and this simplify the maintenance and the troubleshooting.