NIS 2004 Pro Blocking Mcafee Spamkiller 2004

Hello all...
I have been running Norton Firewall for several years now, and am very familiar with it's settings and advanced features... BUT I have recently run into a problem that has me quite frustrated... and I am hoping someone may be able to help me out.
I recently purchased McAfee's Spam Killer 2004. I have been using the older 4.0 version for quite some time now, and figured an upgrade was maybe in order...
Since Norton, and McAfee are in competetion with each-other, neither has any information posted on their web-sites, and norton does not recognize McAfee Spamkiller as a Auto-configurabe application. Basically, in order to complete the SpamKiller set-up, I had to disable my firewall temporarily.
Set-up is now complete, and I can't get Spamkiller to run correctly, unless I disable NIS. With the firewall running, if I try to open MSK, it says "Spamkiller is unable to communicate with it's server... <etc>". If I disable NIS, it runs great.
So I looked into the NIS logs, and noticed this:

-------------
Details: Rule "Implicit block rule" blocked (localhost,2010)
Inbound TCP connection
Local address,service is (localhost,2010)
Remote address,service is (localhost,1611)
Process name is "C:\Program Files\McAfee\SpamKiller\MSKSrvr.exe"
-------------

I have already set a rule to allow localhost (127.0.0.1) access to the ports that appear in the logs that are blocked. But it continues to block it out... I have verified that the MSKSrvr.exe (along with other MSK executables) are in the program list with "Permit All" access.

What is the "Implicit rule block", and is that my problem? Anyone know a work-around or a filter I may need to add/modify/remove to help my Spamkiller work....

Thanks for the time!!
Brandon

 

Hi Brandon

... and welcome to Wilders

Have you changed the default loopback rules at all?

Check all your rules in General/System Wide, Program Control and Trojan for anything that may be blocking the application. One would expect with a permit all, that it would work.

You could also try deleting any existing rules and try the following if the local service/port 2010 is constant.

Protocol: TCP
Action: Permit
Direction: Inbound
Application: MSKSrvr
Local Service: 2010
Local Address: Any Address
Remote Service: Any
Remote Address: 127.0.0.1

The "Implicit block rule" is the default action of the firewall - block anything for which there are no rules.

Are you using the Spam filter in NIS? Are you using NAV?
Just wondering if there may be the potential for conflicts if you are.

Regards,

CrazyM

 

To follow up on what CrazyM, said there are two possibilities that come to my mind here.

First, let's carefully check your Loopback rules. If you have not modified your loopback rules from the time NIS 2004 was installed, you should have two loopback rules. You should be able to find these under the General Rules in NIS 2004 (it was called System-Wide rules in earlier versions).

I want you to find each of these rules and select Edit (or Modify, as the case may be) so that you can actually walk through the detail tabs for the various settings, not just the 'summary' specification of the rule. Check off items below one by one and (if everything is correct) hit cancel (i.e., don't change anything and then save).

Code:

[B]Default Inbound Loopback[/B]
Rule in use:    YES
Logging:        NO
Protocol:       TCP or UDP
Action:         Permit 
Direction:      Inbound 
Local  Ports: Any 
[B]Local  [/B] Address:  [B]127.0.0.1[/B]
Remote Ports: Any
[B]Remote [/B] Address: Any Address
------------------------------------------------------
[B]Default Outbound Loopback[/B]
Rule in use:    YES
Logging:        NO
Protocol:       TCP or UDP
Action:         Permit 
Direction:      Outbound
Local  Ports: Any
[B]Local  [/B] Address: Any Address
Remote Ports: Any
[B]Remote [/B] Address: [B]127.0.0.1[/B]
 

Note that these two rules differ in more than the simple fact that one is for Inbound and the other in for Outbound. For example, on the Inbound Rule, the Local Address is 127.0.0.1; on the Outbound Rule, the Remote Address is 127.0.0.1 . Now, that Inbound Loopback rule, do you know how to change the Local Address to 127.0.0.1 (yes, it's important in this instance)? Unless they've changed the interface in NIS 2004, you need to click on a command button labeled Adapters (on the "Computer tab in the "Modify Rule" window) and then change the entry there to be only 127.0.0.1, rather than simply "Any"

I suspect you won't find any problems there if you haven't been modifying the General Rules yourself. So, that brings us to the second possibility.

Find your Hosts file. Open it with Notepad (it's a plain text file). Unless you've deliberately used some utility (other than NIS) to block specific remote IP addresses, the list there should be quite short. So, cut and paste what you find there in a reply.

You see, there's an incredibly simple little trick used by some malware such that, once it gets on your machine, it redirects (using the Hosts file) traffic to a whole bunch of security vendors to 127.0.0.1 (which, of course, is your local machine). Bingo, no capability to contact the vendors' websites anymore. Now, when NIS/NPF sees 127.0.0.1, it automatically calls it LocalHost (well, it is now LocalHost! ) in its report; the fact that the software McAfee Anti-Spam in this case might have been trying to reach, say www.mcafee.com is now irrelevant. The Hosts file redirected that traffic to 127.0.0.1 and, to NIS/NPF, that's LocalHost!

There's one other possibility here, but I think you should check out the two above first.

 

Thanks to both of you for the quick replies!!
I have checked the host table, and it's just the way I last left it. It has the 127.0.0.1 localhost mapping, plus the other 5 entries I manually put in there, other than that the file is clean.

I don't believe I have disabled the Norton Anti-Spam tool... I'll have to give that a shot and see what happened there...

I'll also have to play with the default loopback rules, I suspect that is where i am having my problem.... I'll let you know what comes of it! Thanks again!!!

Brandon Woods