NIS 2004

Have Windows XP-SP1 Home and NIS 2004. PG 1.1 appears to be conflicting or blocking the Alert Messages from NIS. Here is what I found.

On booting up, NIS 2004 module CCAPP.exe cpu utilization jumps up and oscillates at 70-80% cpu time. CCAPP is memory resident on reboot and stays in memory. I tried adding it and all the other executables of NIS in PG with all Allowed elements active (Close Message Handling not selected). This does not solve the problem.

I know that everytime I boot up without PG 1.1, I get a CCAPP.exe alert box to block or permit internet access. This does NOT come up when PG 1.1 is installed...and the CPU time jumps way up. I even tried deactivating PG 1.1 and it does not seem to let CCAPP.exe complete whatever it wants to do. Uninstaling PG 1.1 appears to be the only way to stop the high CPU time and allow the NIS Alert Messages to pop up.

Any ideas what I can try?

 

Have you tried putting CCAPP.exe on PGs list and playing with the allows?

It may well work when being covered by PGs driver.

Maybe there are other NIS users here that have had the same or similar problems

Only guessing. Pilli

 

have you a P4 HyperThreading ?

 

Thanks for the responses.

Yes, I had ccapp.exe along with other executables of NIS in PG 1.1.

No, Don't have P4 HyperThreading.

I'm gonna reinstall PG 1.1 this AM and give it another try and check to make sure I have all major executables of NIS in PG with Allows. Maybe I overlooked one.

 

Hi,

Thanks for letting us know you have problems, as NIS is very popular. I'll be trying to test this very soon here, which speeds up fixing of any problems.

 

Hey thanks,

I reinstalled PG 1.1 and set it up again. The blocking of Alert messages and high cpu hogging by CCAPP.exe still occurs. Please note that I have the NIS-Internet Security Options-Firewall options of Program Component Monitoring and Program Launch Monitoring selected. This is where these specific Alert messages are being generated.

For test purposes, I went through NIS and NAV 2004 and added almost every executable I could find to PG with all ALLOWED options selected on each. The problem still persists on reboot. I can stop it by unselecting Program Component Monitoring and Program Launch Monitoring.

The thing I do not know yet is what will happen if/when I get an Attack alert. Will the system cpu surge and no message result? Will have to wait and see.

 

If it can help to tests, i can say that i have NAV2004 and so i have the ccap.exe client too and haven't any pb.
So i think the pb is more in the firewall part of NIS, may be.

 

Yes, I agree gkweb. It does appear to be related to the Internet Security part of NIS, not the NAV. I think CCAPP.exe serves both features if you have NIS 2004.

Here's another thing to check out. When doing a LiveUpdate of NIS/NAV 2004 and if updates are available and are being automatically installed, certain NIS/NAV modules report in the PG log that they try to gain access to various items in PG for Terminate. Even though the reporting items have Terminate Allowed, apparently Terminate access is denied by PG. Either that or the logging of PG is not correct.

The LiveUpdate does seem to download and install correctly however.

I do have question/concern?? Norton uses the LiveUpdate to also download and install program revisions automatically. I'm wondering what will happen if this occurs and the modules being updated are in PG. Is this a problem waiting to happen??

 

Might be a logging bug, we should be testing that soon. The logs shouldn't actually stop the functioning of anything as you have seen, most of the time a program like that is not actually trying to get terminate access. All will be revealed very soon

 

Shouldn't be. When an update of a module occurs NIS or NAV or something else MIGHT try to unload the process for it to be updated. Although Im sure they have the usual fallback - you need to reboot to replace these files, reboot now ?

If you have allow access for Liveupdate EXE's as well though, there wouldn't be a problem LUALL.EXE is the actual updater if I remember correctly ? will try this too anyway, with no allowances for the apps just protection on them

 

I have the automatic live Update option selected for NIS 2004 through the NAV 2004 LiveUpdate Option. This places NDETECT.exe in the system Task Scheduler (Windows XP-SP1 Home). I have NDETECT.EXE, LUALL.exe, and LuComServer.exe of NIS in PG with all Allowed elements active.

When the system is rebooted, the Task Scheduler fires off NDETECT.exe to check for a NIS new update. With PG 1.1 active, this causes CCAPP.exe to go busy (CPU 100%) and stay busy indefinitely. Apparently Live Update is sticking and cannot complete.

I deactivated PG and rebooted 10 times and CCAPP.exe works okay.

For reference, I have the following NIS/NAV 2004 executables in PG with all ALLOWED options selected:

LuAll.exe, LuComserver.exe, NDetect.exe, Luinit.exe, Aulnotify.exe, Aupdate.exe, symlcsvc.exe, ccapp.exe, ccevtmgr.exe, cclgview.exe, ccproxy.exe, ccpwdsvc.exe, ccsetmgr.exe, cfgwiz.exe, lrsend.exe, nmain.exe, sevinst.exe, smnlnch.exe, sndinst.exe, sndsrvc.exe, alertast.exe, hnetwiz.exe, logexprt.exe, urlupdat.exe, bootwarn.exe, ccimscan.exe, navstub.exe, navw32.exe, navwnt.exe, navapsvc.exe, navapw32.exe, savscan.exe, opscan.exe, qconsole.exe

NOTE:
The first time I rebooted after setting PG 1.1 deactivated, the shutdown procedure locked up on "Saving All Settings". I waited about 10 minutes and it was still stuck. I had to shut down with the power switch. This did not happen on subsequent reboots with PG deactivated.

 

Hi,

The hanging at "saving your settings" is already fixed for the new version whether PG is running or not, disabled or not Due for release in a short time

Looking at NIS Pro now, I think it might already have some protection implemented. It might be an idea to test termination and firewall leaktests. If you want to try some tests, do it while you are offline and not vulnerable please

 

The AV scanner has some protection.. Im having a hard time getting the system STABLE so I can start on this testing

There is a lot of components of these programs..

Ok now Ive added all those processes and more, as many as I could find. Not good I'll have to remove protection for some things which seem to be already protected. I would suggest you remove protection for only CCApp.exe for now, does that show the alert you mentioned on startup ?

And in regards to that - what was the alert on startup that you have when PG is disabled ? If its a legit alert, cant you always allow that ?

 

Ok well its back to working properly. The only difference would be that I've disabled NAV on this while testing. Also I haven't tried online update as I'm initally testing this on an offline machine.

When using LiveUpdate ALLOW anything you see wanting terminate access, it is probably trying to gracefully close its own processes first. This is ok, and should be allowed. With every NIS/NAV app I've added I've also given it full allow access and am not getting any log alerts - and seemingly no issues. Maybe it would be a good idea to remove protection and only protect what is actually vulnerable and needed to be added - and some more allowances for those programs which work together and are giving you log window activity

 

Gavin,

Based on your last 2 posts and referencing NIS/NAV 2004 already has some protection, I removed ALL the NIS/NAV modules from PG 1.1. On reboot, CCAPP.EXE appears to execute normally, the alert messages come out as they should, and my system appears normal. There are no logging entries appearing in PG for NIS/NAV.

So do you think NIS/NAV 2004 really does not need PG protection and should play on its own? I have been kind of working off what was said in another PG thread that any program that is part of the normal startup should be put in PG for protection.

 

Im not too sure yet, will have to do more testing. It is possible to have it all protected though on a Win2k system so Im going to test on XP for you over the weekend

 

Hey thanks...

Hopefully you will work in some fun personal time over the weekend too.

 

Sure ! am having a nice drink while I set up the new PG and NIS to test on another XP machine Actually installed the last 2 versions over the old which has worked fine. I dont recommend skipping reboots when it comes to drivers but it is possible for those who are in a hurry. I wanted to make a post maybe tomorrow about some pointers for WHAT to protect, and it should go in the help file really. But here is some food for thought.

The major points I want to explain are this. The reason for PG, the power it gives you over your own PC. You ONLY need to add key processes. As long as PG cant be killed, a user can always GET TO PG and add protection for anything which is being attacked - you can run a completely clean ruleset (minus the NEEDED things added automatically)

There is even argument that there is no need for AV protection. You didnt have it before did you ? Some will protect themselves and you should decide if its compatible. Add it if its completely compatible and just protect your realtime component, and scanner to start with. You dont need to add all the other processes unless you encounter problems. If you have a problem though, everyone can easily share information here Process Guard will work with anything that doesn't already protect itself.

NOD32 Im just realising is absolutely perfect to match with Process Guard. Like many AVs it doesnt try to protect itself completely yet. So there is no chance of 2 protection systems conflicting as I am seeing NAV can with Process Guard. KAV doesnt seem to conflict either, even though it has protection. This is because the existing protection is very cleanly coded I would presume. Within a few weeks we could easily have a list of what works and what doesn't in these threads

So lets say you didnt protect your AV and it wont start or it dies all of a sudden ? well PG is alive and well, add the process name and restart it. Killing your AV is a dead giveaway but so many trojans and trojaners still use it - there is a recent public trojan which is simply a tiny app someone made to look like a NAV tray icon.

Its still a worst case scenario - your AV should either protect itself, or you can protect it. It would be better if your AV allowed Process Guard to control protection or worked in conjunction so developers and DiamondCS might have to work together. BUT if something EVER DIES, just protect it and then restart it win/win situation. We always want to provide those powerful tools that will help users - you can use Process Guard in its default state to block all forceful DLL injectors, and you can use it to block rootkits already. Coming soon will be proper OS level protection against installing new services which is the case with only 1 popular rootkit. There is no protection like this available to the public, yet there are OS level rootkits in circulation. Its a no brainer that this is needed at the consumer level and properly implemented. If a rootkit like this is installed, then after a reboot it will get low enough in the system to hide itself against most attacks. A public protection is needed BEFORE this type of rootkit is perfected.

In a short time Process Guard will stop any rootkit - it already does when you know a service entry was written so in conjuction with a program like RegRun3 you can deny the new service entry while Process Guard stops the rootkit attack on the OS, Most importantly it can protect any user not only against public threats, this is close to pointless as we want to protect against future and theoretical dangers as well.

 

At the present time, I have nothing for NIS/NAV 2004 in PG (based on the last post by Gavin. Any update based on your "weekend" analysis of NIS/NAV 2004 as to whether anything needs to be in PG to be fully protected? Windows XP-SP1 Home...

 

I was able to get some hanging activity similar to what you saw, I'll try to get more familiar with NIS before making suggestions. After a reboot I didn't have any more problems so I couldn't be sure what happened.

Do you know if any leaktests work against it ? I would guess they dont, meaning most protections are already added. In any case I will probably suggest only adding protection for the main applications and not all the other little programs

 

I haven't tried any leaktests on it as yet. I've only run the symantec security tests and the .grc.com port tests...all okay.

Any advice or suggestions/recommendations for proper setup will be greatly appreciated.

 

About leaktests, some can't bypass firewalls if PG is installed, they are :

FireHole, PCAudit, some AWFT test, Thermite, CopyCat, PCAudit v2

all of them do one thing between DLL injection/Thread injection/code modification.

So Process Guard protect against the half of existing leaktests
(since i'm very clear on the following point, i must add that it "passes" their excutable nature, not really the leaktests "proof of concept", but atleast it prevent them to operate).

 

With this new BEAST.205.RAT on the loose, I decided to add some of NIS/NAV 2004 back into PG. I added the NIS/NAV memory resident modules ccevtmgr.exe, ccproxy.exe, ccsetmgr.exe, sndsrvc.exe, navapsvc.exe, and savscan.exe will all ALLOWED options active.

The only two memory resident modules not added are CCAPP.exe and symlcsvc.exe.

My system boots up okay and appears to be running okay. My "gut" tells me that the slow down problem is centered around CCAPP.exe and/or symlcsvc.exe.

So far so good!

 

Beast 205 is stopped by both TDS3 & PG .. Now on with my BD drinks ..