Firewall Questions (Outpost 2 and Sygate)

[msingle]

Hi,

Two questions for you.

1. Last year I downloaded the Sygate Pro trial. After running fine for a few days I noticed that it did not start up one day on a reboot (Windows 2000). I restarted it but the next few times the same thing happened so I assumed that there was something wrong with my computer or me.

Since then I've been using or trialling other firewalls: ZA Pro and free, Kerio, LookNStop, and finally decided to give Sygate free a shot. After a few days the exact same thing started happening that was happening with the Pro version.

All the other firewalls ran without any problem and I made sure that they were all completely uninstalled before using another. Any idea why Sygate keeps doing that and not the others?

2. I'm currently using the trial version of Outpost 2. Even though I'm on dialup I've been getting those Windows messenger service messages. I've followed the Outpost instructions to the letter and every once in a while one still comes through - every couple of days even though it's stopped the majority of them.

This is after none of the others ever let any through (except Sygate but I had to change one setting and it stopped it).

I know I can turn off the messenger service but would rather not because firewalls if properly configured should take care of the problem just fine as evidenced by Sygate, ZA, LNS, and Kerio.

Any ideas why this is happening with Outpost 2 even though I've set it up the way they say to for the messages to stop?

Thanks for any input.

[DolfTraanberg]

I don't know what they say to do, regarding stopping those messages, but if a firewall is unable to stop port 135 UDP don't use that firewall.

You can test your security regarding the Messenger Service at grc.com:

https://nanoprobe.grc.com/x/ne.dll?bh0bkyd2

scroll down till you see the messenger spam service and hit that button
Dolf

[msingle]

Outpost 2 seems to block it when it's in the right mood which is why I ask.

The test you sent me to did not suceed but one came through last night before I posted this for example.

Any other ideas? Is Outpost likely to blame or something else?

Thanks.

[Phant0m]

Hey msingle

Lately there have been many false reports coming from there, get secondary and so forth opinions. Scan using different Online Scanning Systems.

[DolfTraanberg]

{QUOTE-> Outpost 2 seems to block it when it's in the right mood <-QUOTE}
Hmm, I don't know if I want to depend on the good mood of my firewall...

Try this one:
https://grc.com/x/portprobe=135
and scroll down to the Messenger Spam button

[msingle]

Okay more information here that hopefully someone can be kind enough to advise me on.

I tried the GRC messenger spam tester several times yesterday and this morning and none ever got through and I didn't receive any ads from elsewhere.

A few minutes ago, though, I received another ad. From the time, direction, etc. in the Outpost 2 log it looks like it came in on SERVICES.EXE, port 666, UDP.

Does this sound right? I thought the messages came in on port 135. But there is nothing in the log on 135.

Any ideas or advice please?

Thanks.

[CrazyM]

Hi msingle

Was it a messenger service window or just a pop up ad?

{QUOTE-> A few minutes ago, though, I received another ad. From the time, direction, etc. in the Outpost 2 log it looks like it came in on SERVICES.EXE, port 666, UDP. <-QUOTE}

Was that the source port or destination port?

{QUOTE-> Does this sound right? I thought the messages came in on port 135. But there is nothing in the log on 135. <-QUOTE}

The following link might provide a little insight on a couple of different ways the messeger service spam works.
http://www.mynetwatchman.com/kb/security/articles/popupspam/netsend.htm

Regards,

CrazyM

[msingle]

CrazyM,

Thanks for the reply. It was a messenger window.

Remote port 666
Local port 1026
Application: Services.exe

I've read that article you gave me before but still a little confused because it doesn't appear to be coming in on port 135.

Do you think the rules for services.exe aren't strong enough?

Any ideas?

Thanks.

[CrazyM]

{QUOTE-> quoting: msingle link=board=23;threadid=12128;start=0#msg78279 date=1060263223]
Remote port 666
Local port 1026
Application: Services.exe <-QUOTE}

Could you clarify if this is a log entry of a permitted or blocked communication.

{QUOTE-> I've read that article you gave me before but still a little confused because it doesn't appear to be coming in on port 135. <-QUOTE}

Below is a sample from my log for last month where the remote system was using a source port of 666 and scanning destination ports 1026 and 135. Do your logs show a similar pattern?
2003.07.31 08:15:37:393 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 1026
2003.07.31 08:15:37:393 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 135
2003.07.30 23:45:43:281 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 1026
2003.07.30 23:45:43:271 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 135
2003.07.30 13:56:36:602 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 1026
2003.07.30 13:56:36:592 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 135
2003.07.29 23:16:52:532 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 1026
2003.07.29 23:16:52:532 Block Inbound UDP src 64.156.xx.xx sport 666 dst 142.173.xx.xxx dport 135

{QUOTE-> Do you think the rules for services.exe aren't strong enough? <-QUOTE}

Are you allowing any inbound for services.exe? Any inbound permitted at all?

Regards,

CrazyM

[root]

If you have Windows 2k and are still using Outpost, if you have services.exe allowed at all, it should only be for resolving DNS only. A better way is to place services.exe in the blocked applications and allow UDP out to remote port 53 to your ISPs DNS servers either with a global rule or even better yet for each application that needs it.
You should also allow DHCP out in the global rules and probably will need to make a rule for TCP out to DNS (54) to your ISPs DNS.
It's hard to tell what's been going on with your setup, but you can get some excellent help at the Outpost Forum, at www.outpostfirewall.com/forum/
If you have allowed rules for messenger, they should be set up specifically for that service, but I am not familiar with that.
I am not aware of anyone having a problem such as you are describing that would indicate something of an intermittant nature.
If, when you set up Outpost initially using the rules wizard mode, you will be prompted to allow the applications the first time. Also you may get a prompt for DNS and possibly DHCP if the global rules are not in place. I don't have a clue what that portt 666 stuff would be except possibly some malware. There are several Trojans that use that port. http://isc.incidents.org/port_details.html?port=666

[LowWaterMark]

I'm a little vague on the details now because it has been some time since I read the debate on all the different methods that messenger pop-ups could be passed, but, as the article linked above says, the ephemeral ports can also be hit on some configs with the message directly, bypassing the connection to the RPC port. (At least that's the discussion as I remember it now. :-\ )

Actually, I'd be interested in what a port scan from the Advanced Port Scanner at PCFlank says (directly targetted it at your 1026). If the messages are coming in that way, then 1026 has to be open to the Internet. Then as stated above, change the rules to block that.