Symantec Client Security V3

[RogueSpear]

I've been using SCS for a few years now with several clients. After wrestling with the firewall policies and SCFA for what must be months on end, I've finally given up and I just created a policy that is balls out wide open. I figure that for now at least the clients are getting the benefit of IDS and ad blocking until I figure this thing out better.

If you've ever used this product then you know that the supplied documentation and online help are all but worthless. So my question is...

Does anybody know of a decent online resource or support group for this product? I've done some looking around but all I find are people having the same issues that I have (with no answers).

Specifically I am having huge problems with pRules. I've essentially given up on using required digests as file versions change. So I wanted to start using file properties, even though it's less secure. Well this works with some files and not others. There's just no rhyme or reason with half the crap this program does. And it only seems to get worse with each new version.

[DonDamm]

Not trying to be flip, but why are you using this program if it is giving you trouble or if it is not doing the job?

[RogueSpear]

Because it's what the client has invested in and is using. Now I'll be honest and admit that I got one client stuck with this product. I had always like SAV quite a bit and they were already SAV subscribers. Well they decided that they also wanted the firewall component so they got SCS. For the most part I really do still like SAV over the competition, but the incredibly, unbelievably poor tech support and responses that I have received from Symantec, have really shook my confidence in them as a whole.

I have pointed out issues to them only to be rebuffed as supposedly not knowing what I am doing. And when I present what amounts to a thesis on the issue, documenting the problem and possible solutions, I'm told either nothing at all or a curt "we'll look at it."

I finally stopped calling them altogether as the Mickey Mouse development shop they got going on was too aggravating to bear.

[RogueSpear]

I have officially given up

I created a firewall policy completely free of all pRules. In fact in the general rules, I created one master rule that allows all TCP/UDP traffic over all ports to and from any computer. The only thing I left in there were the ICMP rules since they seem to be "special" in the eyes of Symantec.

It's funny how a computer is actually more secure running in this fashion than with a policy that contains far more restrictions. I've searched high and low, put Google through a pretty good work out, but all I've been able to find online is help for running the SCS3 client in an unmanaged fashion.

Anybody have any opinions on an alternative product to this POS? I'm all ears..

[DonDamm]

Sory I don't have anything more to add. I still use SAV v10 and am quite happy with it compared to the Norton counterparts. As for the firewall etc, I rely on an older version of Zone Alarm (4.5) and use a hardware firewall in the router.

What you say is ironic, but seems to be true about greater securtity. If your client has a hardware firewall, then you are probably okay with that configuration. Otherwise, I'd think I'd remove it or disable that portion and use another product. The Symantec Firewall is an incarnationof the old AtGuard firewall which was a good one, but a pain to configure properly. My feeling was that Symantec never really managed to get that part right and document it - as you've found out.

[RogueSpear]

Well I've figured out quite a bit more on how this works, but I'm still not happy. Perhaps this is a bug, I'm not sure, but I cannot get a pRule to match an executable based on file property data. Using a required digest has always worked and is arguably the most secure method to use, but the amount of labor involved to keep all of the digests up to date is just too much. Using the option "Any Version" lets the executable use your defined rules but it is hardly practical when the executable is named setup.exe or some other generic name.

In the end, I have this thing working well enough for existing clients who are already invested in the product, but I could hardly recommend it for future considerations. The SAV client seems ok enough. It used to be rock solid but in the last couple of years Symantec just seems to make the product worse and more unreliable than the last version. It's really sad to see a product I've loved for so long turn to complete garbage.

[ravashaak]

I've used SCS for years myself. The client itself isn't so bad really (but could use some improvement: de-bloating, etc). However, managing the thing from an administrative level is outright hellish. In fact, as far as SCF goes, I gave up on pRules entirely (far too much maintenance). I do all of my blocking and allowing via General Rules...with a big fat DENY ALL (TCP/UDP) followed by a big fat DENY ALL (ICMP) as the final two rules. I also use the Trusted systems list where prudent to make my life easier.

The above method meant some work up front in order to allow everything I really needed. However, once I got a handle on the exceptions my network clients required, it has resulted in FAR less maintenance. In fact, the first time in months that I've had to add a rule was merely because I am migrating my clients to a new domain/forest, and had to add a couple of systems to the trusted list, and add a couple of new general rules because of security policy differences between domains.

If you decide you'd like to attempt this method, just let me know and I'll see what advice/help I can give to you.

- Ravashaak (currently enduring strep throat)

[ravashaak]

I also must agree with you on another point: I would never recommend this package to someone starting fresh. The only reason I use it is simply because my employer has a site license for it.

- Ravashaak (currently enduring strep throat)

[RogueSpear]

@ravashaak, I appreciate the ideas and the insight. One thing I have always tried to do is make one master policy that is, for the most part, suitable to several clients. I may give your method a shot and see how comfortable I can become with it. Perhaps an improvement to what you currently do would be to stick in some pRules for those applications you do NOT want to give access to (Kazaa, etc.).

Which brings up another idea.. Have you ever messed around with adding host names to the restricted zone? If I understand correctly, anything in the untrusted or restricted zone (talking SCS not IE here) would get literally no access. Meaning no cookies, scripts, ActiveX, etc. A frustrating limitation I have run into is that it does not seem to accept wildcards. For instance *doubleclick* . Being able to implement a blacklist of that type directly into SCS would sure solve a lot of issues right off the bat.

[ravashaak]

Perhaps an improvement to what you currently do would be to stick in some pRules for those applications you do NOT want to give access to (Kazaa, etc.).

Ya know...I haven't really thought of that one. However, I have the luxury of being able to lock down my users' systems pretty tightly...and for the most part, management backs up the policies. Between those factors, giving users as little privilege as possible, and regular system audits, we get almost zero unauthorized software installs. Doing so in my environment would likely lead to dismissal...or worse. But I am definitely tucking away that bit of advice you gave me. It might come in handy at some point...thanks

Which brings up another idea.. Have you ever messed around with adding host names to the restricted zone? If I understand correctly, anything in the untrusted or restricted zone (talking SCS not IE here) would get literally no access. Meaning no cookies, scripts, ActiveX, etc. A frustrating limitation I have run into is that it does not seem to accept wildcards. For instance *doubleclick* . Being able to implement a blacklist of that type directly into SCS would sure solve a lot of issues right off the bat.

Another good point. And my understanding of restricted zone functionality matches yours. I haven't yet implemented any SCS restricted zone blacklisting, but I'm sure it's only a matter of time. I'll need to experiment with adding hostnames to see if there's any way to bypass the lack of wildcard usage. I'd say you could block *doubleclick* by IP range, but I'm sure those greasy <insert colorful expletive here> vary their IPs enough to make effective blocking difficult.

You should make the suggestion to Symantec to add wilcard capabilities to their hostname zone implementations. Not saying they will listen or actually take action, but you never know...

- Ravashaak

[RogueSpear]

@ravashaak, LOL I've actually pointed out bugs and a solution to the bug, silver platter and all, to these chowderheads and it'll take in the area of 18 months for them to address the issue. At this point I've gone guerilla. I know it's up to me and other end users out there to figure out the quirks and come up with work arounds to the deficiencies.

Since you seem to know your way around this product pretty well.. do you know of any command line options for ALEScan.exe so that I could script a program scan towards the end of an uA install? I've searched high and low, but have not been able to find any such thing. I'm about to break down and finally learn AutoIt to try and tack this one. VBScript just doesn't seem cut out for that task.