ZA + uPnP (split posts)

I checked all servers, I even entered "wilderssecurity.com" as time server, just to see if the outbound UDP was allowed, it was not. Read my post

 

Date + Tlme Tests
Wind XP-SP-2
ZAF V7.0.302.000

Test #1 ZA ON
time. nist. gov Fail D+T Error = The Peer is Unreachable
time.windows.com OK
time-a.nist.gov OK

Test#2 Windows Firewall ON = Same as Test # 1

Test# 3 NO Firewall = Same as Test #1

Only 1 Related ZA LOG Entry

GHP for win32 services could not accept a (n) UDP port123 conn.

from 192.43.244.18:123

Direction Incoming(accept)

Action Taken Blocked

CT1

Source DNS time.nist.gov

What does this tell us?

 

From you results? That ZA is irrelevant and that there is a problem with "time.nist.gov". Actually I have tried now to sync with time.nist.gov and it works... (with ZA ON and ZA OFF) but windows.com fails with or without ZA.

Looks like everybody is getting a different result, you have problems with nist.gov, escalader with nist.gov and windows.com, myself with windows.com and stem with all servers...

May be if the response is delayed it is just dropped by the system and you fail to sync? So, just timing issues? No idea...

Fax

 

Dear Mr Gates:

I will now sign out of wilders and duplicate your tests and then return with my results.

More later

 

Escalader

I do not take kindly to Insults. Please Go to the Back of the Bus.

 

Sorry, Bill no insult intended!

I am already on the back of the bus and trying out your tests and will report later!

Just like to test things myself, your post was interesting that's all, I fear you read too much into my writing style.

Again, no insult intended!

 

Escalader

No problem. I found it Funny + a matter of time.

 

Boy are you right, some days I lose time trying to find the time at this point in time, thanks for going see you next time

 

Bill:

I'm back on the bus

Attached are my results repeating your experiments in time travel with ZA installed and with it replaced by latest version of Comodo.

As to what it all tells us, for me anyway it implies timeout problems with some time servers, that Comodo V2.4 doesn't automatically disable windows FW so users of Comodo will have to watch for that one and that your ZAF V7.0.302.000 has issues with UDP incoming.

What does it all tell others?

 

When this thread started many moons ago, the issue of placing the router (or local LAN) as trusted was being discussed and I have a question pertaining to that subject.

My setups are: Desktop - WinXP SP2, ZAAS 7.0.337, Spysweeper 5.3, Nod32 2.7, IE7

Laptop: WinXP SP2, ZAISS 7.0.337, Spysweeper 5.3, IE7.

My issue is that always on my laptop and sometimes on my desktop - when I have the router set to "Internet", I get web page loading failures:

"Internet Explorer cannot display the webpage"

Most likely causes:
You are not connected to the internet
blah, blah, blah

These problems are always accompanied by ZA warning logs - Medium, Firewall, UDP, svchost.exe, Source (my PC), Destination (My router - port 53), outgoing.

This can be fixed immediately by either changing the router to "trusted" or by allowing outgoing DNS (UDP port 53) in the custom settings menu of the Firewall Main menu.

My question is which solution is best and what are the security differences if any. I would prefer not to re-kindle the argument about whether it is really safe to have the router listed as "trusted" or not. In my setup, mine are the only PCs connected and the wireless is shut down - so I believe it is pretty safe to just list the router as trusted.

To recap - Is it better to just list the router as trusted or to allow outgoing DNS (UDP port 53) in the custom settings menu of the Firewall Main menu?

Thanks for any comments.

 

What we concluded here is that adding your router to the trusted zone is a potential security risk only if the elements in your LAN are not trustful. Given that you do not have a LAN, or your LAN is basically your PC, I don't see any security risk of having the router set to trusted.

Only if your router will be compromised, you will be at risk. If this is the case, setting the router to ZA internet zone will not make you safer (e.g. if the router is owned, DNS can be replaced and all packets intercepted/re-directed).

The issue of DNS added to the trusted to resolve ISP connection problems is also discussed in the ZA manual (page 255). Adding it to the trusted zone is regarded as safe. http://download.zonelabs.com/bin/media/pdf/zaclient70_user_manual.pdf

Hope this helps,
Fax

 

Thanks, I was aware of your position on that particular issue.

Thanks for the reference. I read this page of the manual and it refers to ISP heartbeats, setting your ISP to trusted, ICMP ping messages,... This may be another way to rectify connectivity problems in my case. I will experiment with this procedure. I'm not sure it applies in my situation as there is no incoming blocked in my logs (see attached fig.) Only log listings are outgoing UDP from my PC to my router.

But... The method I was talking about is not addressed on page 255 of the manual. Namely changing the custom settings to "allow outgoing DNS (UDP Port 53) See attached pic. - first check box. By placing a check in that check box, connectivity is immediately restored. My question is... Is that a security risk?

Thanks.

 

Hi!
not my position but a way to do it...
The example I have reported its not your same problem but the solution (adding DNS to the trusted zone) is the same as per your case (your router as trusted).

But if you want to have another way, you can allow outgoing to DNS in the internet zone.

I would personally opt (if you really need to have a specific rule) to create an expert rule (for svchost.exe) to allow UDP on port 53 where you will specific the source (your IP; any port) destination (your router; port DNS)

Hope this helps,
Fax

 

I assume you mean an expert rule in program control (not an expert firewall rule). Never played with expert rules before so I'll give it a shot. I should say that generic host processes for Win32 services (svchost.exe right?) already has 3 green bars (super trust level) and green checks in trusted and internet access and trusted server. But I added the rule you suggested anyway: allow, from my PC any port, to my router port 53, protocol UDP. I presently have the rule disabled and my router set to "internet", but unfortunately, the internet is working flawlessly at the moment so I can't test it .

I'll post when I get a chance to test it out. Thanks for the suggestion.

 

Tried the expert rule without success today. Maybe I did it wrong? (see attached picture) Otherwise, I'd have to say that this solution doesn't work. Any other suggestions?

Was this expert rule approach suggested so as to provide tighter control as compared to the "Allow outgoing DNS (UDP Port 53) check box?

 

Hi!
try to do the same but create the expert rule at firewall level and not at program level to see if it works...

I personally don't use expert rules and I can't remember now if firewal rules have priority over program rules.... I think yes... I will check...

Yes, this suggestion is tighter.... general rule will allow outgoing DNS on any IP.

Cheers,
Fax

 

I had to wait a while for the web page loading problem to reappear but I was able to test the expert (firewall) rule on each of my PCs and it appears to work in both cases.
I'm going to leave it active for the next few days and see if any web loading problems come back.

A couple of final questions:

1.)Do you think this expert firewall rule is a tighter setup as compared to setting the router as "trusted"?

2.) Take a look at the attached log picture and let me know what you think of the four "low" rated logs (towards the bottom). These four entries are related to triggering the expert rule (which I had set to log). Each of the 2 svchost entries are followed by another entry where the "program" box is left blank. Any idea what those mean?

Thanks

 

1. Yes, this expert rule limit communication from your system to the router for DNS services. While trusting the router means not filtering any 'internal' communication between the router and the PC.

2. NO clear idea on what are exactly those DNS calls. Are you by chance using any Citrix products (web development)??

Cheers,
Fax

 

They are probably the DNS lookups for the ZA logging.

 

Nope. Never heard of Citrix and don't do web development.

Anyways, thanks for the help with that. Its nice to have a more restrictive method for handling this issue... especially for the laptop when on travel.

 

Thanks Stem. I was curious about the "double entry" in the ZA logs... Svchost.exe followed by something else (program left blank). Maybe it has to do with the details of the actual DNS lookup process. Can you explain further or maybe point me to some online reference?

 

From my logs, the "blank" entries are corresponding to reverse DNS lookups. ZA makes logs of connections, if there is no cache of the domain name for the IP, then a reverse DNS lookup is made(Query name=IP.in-addr.arpa), so in the ZA log you will see the name, and not the IP, this is done by vsmon.exe, which is probably why you do not see the program name entry.

 

Thanks Stem for the explanation and reference.

 

Yep, when on travel.. you will nevertheless get a a ZA pop about a new network (wireless or wired). You set it to internet and you will be 'fine' (if the network is trustful. In this specific case I would just not create an expert rule for the DNS unless also the new network has connection problems...

Indeed, I have missed completely that those 4 logs were 'accepted' and not 'blocked' by ZA. Sorry, I was to fast into looking at the entries....

Cheers,
Fax