ZA + uPnP (split posts)

[fax]

{QUOTE-> Main point at this time, is the adding of the LAN/router into the trusted zone. OK, this is already within the popup from zonealarm when the new network is found "Use only if you need to share files or printers with others on this network". Adding the router as trusted,.. I do have to ask "Why" there should be no need for this. I put the router as a layer of defence and like to keep this isolated. If the router is placed within the trusted zone, with default trusted zone settings, then windows is able to connect to the router via SSDP(uPnP). Yes, again, I am going from default windows settings, and also default router settings (most routers now are uPnP, and most have the uPnP enabled), so I prefer the PC not to be able to control anything within the router(and so will not simply say "yes" to making this trusted). <-QUOTE}

Yes, good point uPnP can be a security risk. No doubts...

However:

1. UPnP is disabled by default in windows XP machines
2. UPnP is disabled by default in most (if not all) router brands. At least it was in 4 different brand routers I have tried.

and:

3. UpnP si not prevented if you set in ZA your LAN/router to the Internet zone. I have just tested it now with MSN Messenger Live that uses UPnP. Apparently pre-condition for not allowing UpnP is to disabled it in the OS or in the router.

So, to summarise is still unclear the concrete risk of adding the router to trusted zone granted that your router is set-up securely (as already described in previous posts). But, for the purpose of this thread I perfectly understand why you have suggested to keep it out from the trusted zone

Fax

[Stem]

{QUOTE-> Yes, good point uPnP can be a security risk. No doubts...

However:

1. UPnP is disabled by default in windows XP machines <-QUOTE}The default setting is "Manual"(info (http://www.theeldergeek.com/ssdp_discovery_service.htm)) and will be started by svchost. You can check this yourself by re-setting the group policy (which I did at the start of this thread)
{QUOTE-> 2. UPnP is disabled by default in most (if not all) router brands. At least it was in 4 different brand routers I have tried. <-QUOTE}Not from my info/findings

{QUOTE-> 3. UpnP si not prevented if you set in ZA your LAN/router to the Internet zone. I have just tested it now with MSN Messenger Live that uses UPnP. Apparently pre-condition for not allowing UpnP is to disabled it in the OS or in the router. <-QUOTE}uPnP requires both outbound and inbound to function. With router IP as internet, no unsolicited inbound is allowed, and therefore uPnP cannot function. If set as trusted (with default trusted zone settings) then full comms can be made, and uPnP functions.
Note: Just to add, this is with ref to svchost making full uPnP, other programs do have this ability, and it would depend on the access given to that application (such programs as Utorrent can perform uPnP with allowed access)

{QUOTE-> So, to summarise is still unclear the concrete risk of adding the router to trusted zone granted that your router is set-up securely (as already described in previous posts). But, for the purpose of this thread I perfectly understand why you have suggested to keep it out from the trusted zone

Fax <-QUOTE}I am going from findings found from my supports of many users, with many different types of hardware. My thought on this stands

[fax]

{QUOTE-> The default setting is "Manual"(info (http://www.theeldergeek.com/ssdp_discovery_service.htm)) and will be started by svchost. You can check this yourself by re-setting the group policy (which I did at the start of this thread)
Not from my info/findings

uPnP requires both outbound and inbound to function. With router IP as internet, no unsolicited inbound is allowed, and therefore uPnP cannot function. If set as trusted (with default trusted zone settings) then full comms can be made, and uPnP functions.
Note: Just to add, this is with ref to svchost making full uPnP, programs do have this ability, and it would depend on the access given to that application (such programs as Utorrent can perform uPnP with allowed access)

I am going from findings found from my supports of many users, with many different types of hardware. My thought on this stands <-QUOTE}


I don't want to start an argument on this since I don't want to hijack the thread by Escalder.

But:

1. To have uPnP to work in XP, you have to install the uPnP plug-in from windows CD. Otherwise it will not work.. only Linksys routers will work without this...

Source: http://www.microsoft.com/windowsxp/using/setup/expert/crawford_02july22.mspx

2. Well, on uPnP enabled by default on routers its your experience I have a different one.... Belkin routers, Xyzel routers, former US robotics, SMC routers, etc.. have uPnP disabled by default. I only know some Linksys and D-links routers that have uPnP enabled.

3. I have set my entire LAN to internet in ZA and uPnP works fine in MSN messenger live... so apparently uPnP is not blocked...

Fax

http://img66.imageshack.us/img66/703/image1hv2.jpg

[Stem]

{QUOTE-> 3. I have set my entire LAN to internet in ZA and uPnP works fine in MSN messenger live... so apparently uPnP is not blocked... <-QUOTE}Did you read my note in my last post?
{QUOTE-> Note: Just to add, this is with ref to svchost making full uPnP, other programs do have this ability, and it would depend on the access given to that application (such programs as Utorrent can perform uPnP with allowed access)
<-QUOTE}

I would need to ask as to what network access as been given to MSN for it to be able to connect via uPnP to the router.

[fax]

{QUOTE-> Did you read my note in my last post?


I would need to ask as to what network access as been given to MSN for it to be able to connect via uPnP to the router. <-QUOTE}

Yep, I have read you last post...

MSN Messenger needs to have full access (server rights to the internet)... so it is full green checkmarks under program control.
It needs server rights in order to work (e.g. video call). But as you can see from the screenshot... I have no trusted zone except for 127.0.0.0. Svchost has no server rights to the internet.

So indeed, this confirm that there are programs (you mention BIT torrent) that will just use uPnP even if network is set to internet.... so justification on setting the router to internet to block uPnP is weak. My initial post still stand...

Fax

EDIT: NOTE that setting LAN/ROUTER to Internet zone , svchost with NO server rights to the internet and MSN messenger with NO server rights to the internet, still MSN messenger is able to connect using UPnP.... :D

[Stem]

{QUOTE-> Yep, I have read you last post...

MSN Messenger needs to have full access (server rights to the internet)... so it is full green checkmarks under program control.
It needs server rights in order to work (e.g. video call). But as you can see from the screenshot... I have no trusted zone except for 127.0.0.0

Fax <-QUOTE}
That is why MSN can connect to uPnP, because it has server rights in the internet zone. This was the point/note I was making.

From the default setup we have started on, server rights are given to svchost within the trusted zone. So if we place the router as trusted, then svchost would be allowed to connect fully via uPnP to the router. Placing the router as internet would stop this,.. but, if you where then to give svchost server rights within the internet zone, svchost could then again connect.

{QUOTE-> So indeed, this confirm that there are programs (you mention BIT torrent) that will just use uPnP even if network is set to internet.... so justification on setting the router to internet to block uPnP is weak. My initial post still stand... <-QUOTE}We are going from default installation of windows/ZA. Adding any type of server software which is allowed unsolicited inbound from the internet is a possible problem, but this point should be for another thread.

[fax]

{QUOTE-> Sorry Escaleder, I have made my last post on the uPnP issue with Stem... promise is my last... Sorry again for Hijacking your post... <-QUOTE}

Yep, an answer to Stem was due... from now on I will edit my messages no new post... Good comprimise? ;D

Sorry when things are unclear/not justified its not easy to stay silent.:gack:

Fax

[Stem]

Hello fax,
I am certainly interested in your findings, and would certainly like to go through settings you have, the comms made etc. But as noted, the thread is digressing too much from original poster. You can start a new thread on this, and/or I can split off the posts regarding this issue. But I do have to respect the member who started this/any thread. So if you wish to continue this, which I have no problem with doing, please PM me if you would like any of the posts (by you/my reply/your reply etc) from this thread moving to one where we can continue.

[fax]

{QUOTE-> Stem / Fax:
This is a solution I like. Please snip/move the non OP posts including mine if any and take your discussion to another thread, I will not give up this learning opportunity.

Fax, human nature is hard to contain as has been shown but if the OT posts can move and occur in another place we all can get on with the original thread. 160 posts and still on page 2! It's a bit much! <-QUOTE}


Absolutely fine with me... :)

Cheers,
Fax

[fax]

{QUOTE-> I would like to see Fax continue his posting. Good to see both sides of an issue:) <-QUOTE}

Thanks Gre87y for your interest and support ;D

I think I made my point on router/LAN trusted/untrusted and uPnP (i.e. theory sometimes diverge from practise), let's move forward...
I am sure there will be issues on program control I/we could input to... just don't want to hijack this thread further unnecessarily...

Cheers,
Fax

[Stem]

{QUOTE-> {QUOTE-> I think I made my point on router/LAN trusted/untrusted and uPnP(i.e. theory sometimes diverge from practise), <-QUOTE}NOTE that setting LAN/ROUTER to Internet zone , svchost with NO server rights to the internet and MSN messenger with NO server rights to the internet, still MSN messenger is able to connect using UPnP.... <-QUOTE}I was going to drop this and move forward. But lets make one point clear. uPnP will not work unless you allow inbound connections. If your setup is allowing uPnP, then your setup is allowing inbound connections.

Here is some info on the windows firewall and the exceptions needed (http://support.microsoft.com/kb/886257)
{QUOTE-> In Windows XP SP2, Windows Firewall supports the concept of exceptions. When an exception is active, it opens the firewall ports required by a program or a feature. You do not have to know the associated port numbers. Windows Firewall includes an exception for the UPnP framework that opens UDP port 1900 and TCP port 2869. <-QUOTE}

[fax]

{QUOTE-> I was going to drop this and move forward. But lets make one point clear. uPnP will not work unless you allow inbound connections. If your setup is allowing uPnP, then your setup is allowing inbound connections.

Here is some info on the windows firewall and the exceptions needed (http://support.microsoft.com/kb/886257) <-QUOTE}

If you allow me and since you made your point, I will make mine (my last on this hopefully)...

No doubt you can block uPnP however, your original statement, that triggered my reaction was:

{QUOTE-> Adding the router as trusted,.. I do have to ask "Why" there should be no need for this. I put the router as a layer of defence and like to keep this isolated. If the router is placed within the trusted zone, with default trusted zone settings, then windows is able to connect to the router via SSDP(uPnP) <-QUOTE}

This is, in context of ZA, incorrect or better saying 'incomplete' information, i.e. not putting the router to the trusted zone will not prevent uPnP ports to be active, specific rules need to be set-up to block uPnP. So, thats why I have stated that (unfortunately) theory sometimes differs from practice.

Sorry in advance to Escalader to come back on this again.

Fax

[Stem]

{QUOTE-> This is, in context of ZA, incorrect or better saying 'incomplete' information, i.e. not putting the router to the trusted zone will not prevent uPnP ports to be active, specific rules need to be set-up to block uPnP. So, thats why I have stated that (unfortunately) theory sometimes differs from practice.

<-QUOTE}Placing the LAN in the internet zone will block unsolicted inbound. So uPnP will not function. I have checked and tested this with ZA before my first post on the subject.

Simple check for you to try,
Have windows uPnP active, and the router uPnP active. Disable all "allow server" software in the internet zone. Place the LAN in the internet zone: re-boot. uPnP will not connect. Change the LAN to trusted, and have the trusted zone set to default(medium): re-boot. uPnP will connect.

NOTE:
Due to request, I have split these post from this thread (http://www.wilderssecurity.com/showthread.php?t=172579)

[fax]

{QUOTE-> Placing the LAN in the internet zone will block unsolicted inbound. So uPnP will not function. I have checked and tested this with ZA before my first post on the subject.

Simple check for you to try,
Have windows uPnP active, and the router uPnP active. Disable all "allow server" software in the internet zone. Place the LAN in the internet zone: re-boot. uPnP will not connect. Change the LAN to trusted, and have the trusted zone set to default(medium): re-boot. uPnP will connect.

NOTE:
Due to request, I have split these post from this thread (http://www.wilderssecurity.com/showthread.php?t=172579) <-QUOTE}

I think there is no use of continuing this discussion anymore... I much more prefer to continue to follow (hopefully silently) the other thread.

Of course, tuning up whatever settings, blocking server rights to the internet, and specific setting within MSN...etc... will block uPnP.

The original issue, as already mentioned, is different. ie.
placing the router into the ZA internet zone is a necessary but not sufficient conditions to block uPnP. At least in ZA....

Not allowing server rights across all programs cannot always been applied. There are (unfortunately) applications that needs server rights to work and also uPnP (if available) to control router connections and ensure smooth communications. MSN Messenger Live is an example.

In the framework of ZA, adding the router to the trusted zone is not per se a risk if the router is set-up correctly . Using uPnP to justify why the router should not be trusted is rather weak.

I prefer your other theoretical idea that the router is seen as an additional layer in your security thus isolated and set to the internet. This is fine with me.

Please also consider that (in ZA) new/unknown programs accessing the NET will need to ask for permission (both simple access and server rights to the internet) giving full control to the user on how programs will interact with the system.

I hope we can close this discussion here now.
Thank you very much for your time and dedication.

Fax

[Stem]

{QUOTE-> I hope we can close this discussion here now. <-QUOTE}If you had left your reply to uPnP, then yes, as I have shown that uPnP requires inbound connections. Your posts did indicate that only outbound is needed for this, which is incorrect, although you have not mentioned this (to confirm/deny), and the fact that your setup would of been allowing this inbound.

{QUOTE-> The original issue, as already mentioned, is different. ie.
placing the router into the ZA internet zone is a necessary but not sufficient conditions to block uPnP. At least in ZA.... <-QUOTE}I look at this, as with other issues, but I will keep with uPnP(for now). A lot of users should now be aware of possible problems of allowing an applications ability of "server" within the "Internet Zone" (This is to allow unsolictited inbound connections to an application), so I do hope now that most members will know of the possible implications of allowing unsolicted inbound. Now for what most see,.. unsolicited from the internet: this should be looked at, as at most times it is un-needed. Unsolicted from the trusted zone: most see this as allowed without question, so for me, anything that is added to this "Trusted" zone should be looked at very carefully.
possible: An application is allowed out/in within trusted zone, and out in internet. With the router as "trusted" this application as ability of control via uPnP, for me this is a possible problem. OK, call me paranoid, but I am here to be paranoid for the members who do not think of such (or should I not?).

Do not misinterpret, I am looking at end user.


{QUOTE-> Please also consider that (in ZA) new/unknown programs accessing the NET will need to ask for permission (both simple access and server rights to the internet) giving full control to the user on how programs will interact with the system. <-QUOTE}Interaction for any program on a users PC with external sources should be carefully looked at. This can be to any external IP, be it the DNS servers(which may change), to DHCP(which may change).
I personally do not see why trust in anything external to the users PC should be trusted.
I have seen post/advice in setting the DHCP/DNS as trusted to alleviate connection problems, why,.. Outbound DHCP/DNS should not be blocked. I would prefer that these problems would/should be resolved by ZA. Yes, workarounds can be use(trusted), but why not have these problem brought out/shown, and maybe ZA will fix.
I have posted myself on making rules within a firewall(rules based) where the DNS servers should be included,.. this as been seen as a possible problem if the DNS servers change,.. and yes, a possible problem,.. but consider, if you have placed these servers as trusted within ZA, and they change, then what IP you have placed as trusted remains?(you will have un-known trusted IP`s)

[fax]

{QUOTE-> If you had left your reply to uPnP, then yes, as I have shown that uPnP requires inbound connections. Your posts did indicate that only outbound is needed for this, which is incorrect, although you have not mentioned this (to confirm/deny), and the fact that your setup would of been allowing this inbound.) <-QUOTE}

Not sure I follow what you are trying to say. The best for you is to try it. Set up your router and OS with uPnP, install MSN messenger live with default settings (server rights to the internet) and put your usual sniffer in between....

{QUOTE-> I look at this, as with other issues, but I will keep with uPnP(for now). A lot of users should now be aware of possible problems of allowing an applications ability of "server" within the "Internet Zone" (This is to allow unsolictited inbound connections to an application), so I do hope now that most members will know of the possible implications of allowing unsolicted inbound. Now for what most see,.. unsolicited from the internet: this should be looked at, as at most times it is un-needed. Unsolicted from the trusted zone: most see this as allowed without question, so for me, anything that is added to this "Trusted" zone should be looked at very carefully.
possible: An application is allowed out/in within trusted zone, and out in internet. With the router as "trusted" this application as ability of control via uPnP, for me this is a possible problem. OK, call me paranoid, but I am here to be paranoid for the members who do not think of such (or should I not?). <-QUOTE}

Perfectly fine, but some application need server rights to work correctly... its like driving a car but not using its stability control because under certain conditions can be a risk.... anything can be a risk if misused.


{QUOTE-> Interaction for any program on a users PC with external sources should be carefully looked at. This can be to any external IP, be it the DNS servers(which may change), to DHCP(which may change).
I personally do not see why trust in anything external to the users PC should be trusted.
I have seen post/advice in setting the DHCP/DNS as trusted to alleviate connection problems, why,.. Outbound DHCP/DNS should not be blocked. I would prefer that these problems would/should be resolved by ZA. Yes, workarounds can be use(trusted), but why not have these problem brought out/shown, and maybe ZA will fix.
I have posted myself on making rules within a firewall(rules based) where the DNS servers should be included,.. this as been seen as a possible problem if the DNS servers change,.. and yes, a possible problem,.. but consider, if you have placed these servers as trusted within ZA, and they change, then what IP you have placed as trusted remains?(you will have un-known trusted IP`s) <-QUOTE}

The problems you/users are experiencing with ZA are related to being depended on the router for the IPs and DNS resolving while at the same time keeping the router as untrusted.

Fax

[Escalader]

Hi All:

"The problems you/users are experiencing with ZA are related to being dependant on the router for the IPs and DNS resolving while at the same time keeping the router as untrusted."

Where is the detailed list off exactly what problems should be occurring? My router has been set to untrusted for the last week.

Why is router setting as untrusted so "difficult" for ZA? or is it just 1 honestly held view? There is a difference. Does the success of ZA software depend on this setting issue? Can someone provide the ZA technical reference link on this matter?

What I'm wondering now is what do other top of the line software FW tools expect for router settings? We need input on that for comparison or as before it is just statements back and forth with no data.

[fax]

{QUOTE-> Hi All:

"The problems you/users are experiencing with ZA are related to being dependant on the router for the IPs and DNS resolving while at the same time keeping the router as untrusted."

Where is the detailed list off exactly what problems should be occurring? My router has been set to untrusted for the last week.

Why is router setting as untrusted so "difficult" for ZA? or is it just 1 honestly held view? There is a difference. Does the success of ZA software depend on this setting issue? Can someone provide the ZA technical reference link on this matter?

What I'm wondering now is what do other top of the line software FW tools expect for router settings? We need input on that for comparison or as before it is just statements back and forth with no data. <-QUOTE}

Hi!
like all problems related to failed IP allocation or failed DNS resolving. E.g. loss of connection or difficulties on the net reaching web sites. ZA has no difficulties in dealing with the router, but by default, with ZA security level set to HIGH, DNS and DHCP outgoing should be blocked. So, if you relay on the router for DNS and DHCP, you could have difficulties.

Actually I consider an anomaly in ZA that you have no problem in connecting considering that you do not have any custom rule for DNS or DHCP.

Technical reference? I think it is self explaining. May be looking into DNS +DHCP could help. Basic info are easily available on the NET.

Like http://en.wikipedia.org/wiki/Domain_name_system
or this
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

And sorry in advance for spelling mistakes, I am not native english speaker..... ;)

Fax

[Escalader]

{QUOTE->
Keep in Internet Zone:
-For use at public or questionable access points (hotel,airport,coffeeshop,...)
-AllowsOnternet access, blocks others from accessing your computer

Allows into trusted Zone:

-For trusted, secure locations only (home,office...)
-Use only if you need to share files or printers with others on this network

............

12fw <-QUOTE}

Do you think from your long experience with ZA products that this does supports the idea of putting router in internet? It says use trusted only if you need to share files and printers which I don't want to do!

[Stem]

{QUOTE-> Not sure I follow what you are trying to say. The best for you is to try it. Set up your router and OS with uPnP, install MSN messenger live with default settings (server rights to the internet) and put your usual sniffer in between.... <-QUOTE}I know very well that having those settings for a uPnP program will allow the uPnP connections, I tried to explain this to you for a couple of posts on this thread, your main reply being{QUOTE-> ....and MSN messenger with NO server rights to the internet, still MSN messenger is able to connect using UPnP.... <-QUOTE}
I Have made my point on the difference the user sees between server rights in the internet zone and the trusted zone. It is far safer for the end user to place the router as internet. If a user is going to simply allow an application any unsolicited internet inbound on any port, then that is a problem made by themselves. But such possible problems should be made very clear.

{QUOTE-> The problems you/users are experiencing with ZA are related to being depended on the router for the IPs and DNS resolving while at the same time keeping the router as untrusted. <-QUOTE}That is not correct. From one of my main setups, gateway logs posted here (http://www.wilderssecurity.com/showthread.php?p=994435#post994435). The first log was made during boot, LAN as internet, broadcast option disabled, you will note the allowed bootdhcp. (I know the returned bootdhcp was allowed by ZA, as the IP was resolved, and ZA made DNS lookup for zonelabs)
Now I changed my setup, only with a change of NIC, I then had problems due to outbound DHCP being blocked, this is a bug and is probably the same bug as others are seeing who have outbound DHCP broadcasts blocked.

{QUOTE-> like all problems related to failed IP allocation or failed DNS resolving. E.g. loss of connection or difficulties on the net reaching web sites. ZA has no difficulties in dealing with the router, but by default, with ZA security level set to HIGH, DNS and DHCP outgoing should be blocked. So, if you relay on the router for DNS and DHCP, you could have difficulties. <-QUOTE}This would infer that ZA will not allow DHCP/DNS within an internet zone set at high, so all users who connect directly to the internet will not be able to connect after installing ZA, as they would first need to place the DHCP/DNS servers as trusted (the internet zone is set at high by default)

But if we look at the user manual:-
189662
This states that DHCP broadcasts are allowed at "High" setting. It also states that only ports not being used by programs with access will be blocked, so with default DNS client active and svchost allowed internet outbound, then DNS lookups should be allowed.

[fax]

I think we are going around in cicles here.... :D

What I have tried to explain you is that your initial statement was not correct. You have then, in followup messages, corrected it. First with svchost permissions then with MSN messenger permission.... ;D

Can I recall you the original 'motives' for suggesting not to set the router as trusted?

{QUOTE-> Adding the router as trusted,.. I do have to ask "Why" there should be no need for this. I put the router as a layer of defence and like to keep this isolated. If the router is placed within the trusted zone, with default trusted zone settings, then windows is able to connect to the router via SSDP(uPnP) <-QUOTE}

I can't still recognise this is as a valid justification for placing the router as internet. For sure, you need more then the above to block uPnP communication (as we have seen). And there are better and simpler options to block uPnP without messing up with programs rules and the router.

On DNS/DHCP, yes... you are saved by the multicast rule, so you are actually finding the router and then dhcp can begin... but otherwise.....;D

And if you want to keep the router isolated, why you give to it two essential and critical tasks such as the DNS and DHCP???

Cheers,
Fax

[oldshep]

{QUOTE-> Fax says - I think we are going around in cicles here.... <-QUOTE}

That's for sure. Your messages appear to be argument for the sake of arguing. I think escalader and stem make good points about setting the router as internet. What would you do if you had your laptop connecting to an unknown network? Would you set the router as trusted?

I have changed my desktop (ZAAS V7) router IP to internet and web browsing appears unaffected. I have got a several warnings in the log about service host UDP out to the router getting blocked. But other than that, no affect in performance.

My laptop (ZAISS V7) has my LAN set to internet as well and is working fine.

So why is it better to set the router to trusted?

Oldshep

[fax]

{QUOTE-> That's for sure. Your messages appear to be argument for the sake of arguing. I think escalader and stem make good points about setting the router as internet. What would you do if you had your laptop connecting to an unknown network? Would you set the router as trusted?

I have changed my desktop (ZAAS V7) router IP to internet and web browsing appears unaffected. I have got a several warnings in the log about service host UDP out to the router getting blocked. But other than that, no affect in performance.

My laptop (ZAISS V7) has my LAN set to internet as well and is working fine.

So why is it better to set the router to trusted?

Oldshep <-QUOTE}

Hi Oldshep!
The question that originated all this mess is: which are the concrete risks of setting the router as trusted granted that the router is configured correctly and securily (long passwords, WPA2, etc...)?

The answer was: here we apply an approach that says: everything that is outside my PC is not trusted. And setting the router as trusted can allow uPnP.

If the above is the only risk that is reported, I am happily setting my router as trusted, since the valule added of setting it as internet doesn't pay back on potential problems I could experience with my connection. Moreover, setting the router as internet does not prevent uPnP to work (at least with ZA)

Yes, you can keep the router as internet and experience no problems but why you would do so?

Fax

[oldshep]

{QUOTE-> Fax says...Yes, you can keep the router as internet and experience no problems but why you would do so?
<-QUOTE}

Indeed. Why do one or the other? This is the point I have been trying to discern from the discussion here but apparently to no avail. Perhaps my own ignorance of internet communication stands in my way... Or maybe I just need a couple more beers to understand this in more detail;D

I will leave my setups as is for now and continue to monitor performance.

Regards,

Oldshep

[fax]

{QUOTE-> Indeed. Why do one or the other? This is the point I have been trying to discern from the discussion here but apparently to no avail. Perhaps my own ignorance of internet communication stands in my way... Or maybe I just need a couple more beers to understand this in more detail;D

I will leave my setups as is for now and continue to monitor performance.

Regards,

Oldshep <-QUOTE}

Yep, LOL
When I had the router on internet I have experienced problems in connecting to specific websites and sometime loosing connection or slow connection... plus a lot of firewalls logs (don't like to see internal LAN IPs being blocked without any reasons). Most of the time is OK but sometimes not...

So, the easiest and safest options was to set the router as trusted. The other would have been to create rules for allowing communication to specific services/ports....

So, unless I get a clear explanation on why I should not keep the router as trusted I will leave it as it is...;D

Fax

[Stem]

{QUOTE-> I think we are going around in cicles here.... <-QUOTE}Yes, but little by little we get to the facts.
{QUOTE-> What I have tried to explain you is that your initial statement was not correct. You have then, in followup messages, corrected it. First with svchost permissions then with MSN messenger permission....
Can I recall you the original 'motives' for suggesting not to set the router as trusted? <-QUOTE}My initial statement (post#1) remains (this was posted as a full statement, do not take parts out of context)
{QUOTE-> I can't still recognise this is as a valid justification for placing the router as internet. For sure, you need more then the above to block uPnP communication (as we have seen). And there are better and simpler options to block uPnP without messing up with programs rules and the router. <-QUOTE}From default windows installation, there are no programs that require server rights within the Internet zone for the OS to function correctly. You yourself have added server rights for an application within the Internet Zone.
{QUOTE-> with ZA security level set to HIGH, DNS and DHCP outgoing should be blocked. So, if you relay on the router for DNS and DHCP, you could have difficulties.{QUOTE->
On DNS/DHCP, yes... you are saved by the multicast rule, so you are actually finding the router and then dhcp can begin... but otherwise..... <-QUOTE} <-QUOTE}You are now contradicting yourself.
We could now go through how windows performs DHCP and what is needed, but basically, with a firewall that is SPI(pseudo UDP), only outbound DHCPboot is required. So what is "but otherwise"?
{QUOTE-> And if you want to keep the router isolated, why you give to it two essential and critical tasks such as the DNS and DHCP??? <-QUOTE}I allow outbound to my DHCP/DNS servers, be it on LAN/Internet. Why should I allow unsolicited inbound connections from these.

[Escalader]

{QUOTE-> Indeed. Why do one or the other? This is the point I have been trying to discern from the discussion here but apparently to no avail. Perhaps my own ignorance of internet communication stands in my way... Or maybe I just need a couple more beers to understand this in more detail;D

I will leave my setups as is for now and continue to monitor performance.

Regards,

Oldshep <-QUOTE}

Hi Oldshep:

Your experience matches mine! That is what I'm doing as well.

There is no reason to dumb down your security in ZA Pro based on opinions (I say Pro only because I use it).

Stronger security has always been inconvenient, you know the odd block and so on but that is just the tool doing what it was designed to do! If it is recommended for cafe's and wireless that point speaks for itself.

There are different world views on FW security. The points have been made, the experiments and tests run by Stem and others (me for example)

My router is on Internet ever since our FW moderator proved his case over many posts and actual tests. So that's good enough for me.

Other debating posts may appear but for me, I'm done with this.

Enjoy your setting it works for you it's safer so you are in good shape.

[oldshep]

Hi Escalader,

Good to know I'm not the only one seeing warning logs w/ my router in the internet zone :) .

Its weird but I don't recall any problems with this issue on my desktop when I was using ZAISS V6.5 for ~ 1 year. And my laptop has no such warnings either (ZAISS V7 and SS 5.3).

I've left the loopback adapter as trusted but the rest of the LAN is set to internet. I'll post if any problems develop.

[fax]

Hi!
not sure what you are trying to achive apart confusing the reader about statements taken out of context and network explanations per book.

The facts here are almost not existent... users may (or may be not) have connections problems that will need to be solved via specific rules.

The original question still stands: What are the CONCRETE risk of having the router set to trusted if the router is configured correctly? Can you compromise my system given that I set my router as trusted? I really don't think so!

Don't reply back about uPnP that is a non-issue and is actually a useful features for complex programs that needs full control on ports. Reminds me about the Steve Gibson outcry, some years ago, on windows xp and uPnP.

I am surprised you asking about the "otherwise". If you do not allow broadcast how the hell you can get your IP and connection from the router?
You block outbound, you block inbound and you expect everything is working fine with the router managing DNS and DHCP?

Oh... well this is getting ridicolous...:thumbd:

Cheers,
Fax

[Stem]

{QUOTE-> I am surprised you asking about the "otherwise". If you do not allow broadcast how the hell you can get your IP and connection from the router?
You block outbound, you block inbound and you expect everything is working fine with the router managing DNS and DHCP? <-QUOTE}As shown, admitted by yourself, and I know, DHCP broadcasts are allowed by ZA in the Internet "high" settings (unless, by findings, that problems exist due to bugs within ZA). Do I need to show/teach you on how DHCP functions, I would actually find this a waste of time, as you put forward that you know everyting, but then contradict yourself. I will leave my time for those who like to learn, and find actual facts rather than fiction.

Your own setup, from the use of the programs you use may require unsolicited inbound. This does not infer that all users are the same. You should base on ALL users, not your own personal needs/ or problems with your connection. I have spent many hours/days/weeks/months/years on checking setups and needs for firewalls, I base this on many setups/tests over the years, and on info gained from feedback of many users.
You should not blinker.

[fax]

{QUOTE-> As shown, admitted by yourself, and I know, DHCP broadcasts are allowed by ZA in the Internet "high" settings (unless, by findings, that problems exist due to bugs within ZA). Do I need to show/teach you on how DHCP functions, I would actually find this a waste of time, as you put forward that you know everyting, but then contradict yourself. I will leave my time for those who like to learn, and find actual facts rather than fiction.

Your own setup, from the use of the programs you use may require unsolicited inbound. This does not infer that all users are the same. You should base on ALL users, not your own personal needs/ or problems with your connection. I have spent many hours/days/weeks/months/years on checking setups and needs for firewalls, I base this on many setups/tests over the years, and on info gained from feedback of many users.
You should not blinker. <-QUOTE}

You are actually not answering the main question..Thats a pity... I would really like to know your answer given that you have spent hours/days/weeks/months/years on routers, users, etc...

Should we exchange our CVs? (just joking!) ;D

AND ZA allow broadcast on high settings... YES! I have said that thanks to that you have no connection problems (most of the time) "otherwise" if you do not allow broadcast and the router is on internet then you effectively do not allow outbound and inbound. So, it should not work if your router control DHCP and DNS. If it works its a ZA bug or another hidden option in ZA...

By the way, if you remember, the user had difficulties in connecting and communicating with the router once that option was unchecked (allow broadcoast/multicast) and he added an additional rule to resolve the issue...

Cheers,
Fax

[fax]

Stem,

more I think about this more I don't find any rationale and logic in your principle of setting the router as untrusted. Let's try to go back to the basics

Where would you need to focus your attention in terms of security of your communications? Two main areas:

1. Communications from the internet to your system and;
2. Communications from programs on your system to the internet

The router is not in 1 or 2. The router is part of your security measures. Depending on your configuration, it plays an important role in dropping unsolicited inbound connections from the internet and ensure your connection to the internet.

Would blocking communications between the router and your system and vice versa improve your security, quality of service, communication, stability, speed?? NO... absolutely not...

Any particular reasons for blocking outgoing calls to port 53 or port 67 from your system to your router apart from having your LOGs in ZA filled in by these calls? Why would you consider these legitimate calls from your system as untrusted?

Having said this, I am more and more convinced that your basic starting point, security wise, is fundamentally flawed or at least unjustified.

Cheers,
Fax

[Escalader]

{QUOTE-> Stem,

more I think about this more I don't find any rationale and logic in your principle of setting the router as untrusted. Let's try to go back to the basics

........

Having said this, I am more and more convinced that your basic starting point, security wise, is fundamentally flawed or at least unjustified.

Cheers,
Fax <-QUOTE}

Using verify and compare here is a question and the answer from BD User Forum. (where the vendor reps read about customer concerns;D )

"I think you are saying BD FW doesn't assume that the router should be trusted as with ZA design. and using the BD wizard will set up rules for my set up based on what it finds? Is that correct?" by escalader

"That is correct. BitDefender doesn't assume anything. It asks you the connection type and, based on that information, it sets the proper Firewall Default settings." answer poster private.

If BD FW is okay and Stem is okay, I for one am convinced that your position is how to put this .... fuzzy. ;D

[fax]

{QUOTE-> Using verify and compare here is a question and the answer from BD User Forum. (where the vendor reps read about customer concerns;D )

"I think you are saying BD FW doesn't assume that the router should be trusted as with ZA design. and using the BD wizard will set up rules for my set up based on what it finds? Is that correct?" by escalader

"That is correct. BitDefender doesn't assume anything. It asks you the connection type and, based on that information, it sets the proper Firewall Default settings." answer poster private.

If BD FW is okay and Stem is okay, I for one am convinced that your position is how to put this .... fuzzy. ;D <-QUOTE}

I think you missed the point... the issue here is why should the router set to untrusted and what are the concrete security risk of having the router set to trusted granted that the router is configured correctly...

Fax

[Escalader]

{QUOTE-> I think you missed the point... the issue here is why should the router set to untrusted and what are the concrete security risk of having the router set to trusted granted that the router is configured correctly...

Fax <-QUOTE}

Why do you think you are always right about what the issues are and who has to prove what and if that proof that is provided is valid? ::)

Your blinkered style is, If others disagree with you, and thus the Z world view design, you state they must be wrong, misguided and/or they have a special broken PC or a copy of ZA that has unique bugs then ".... and you say they missed the point".

What a joke. Well at least you provide entertainment for the reader.

So for all you ZA newbies out there here is Fax's advice in one line to save you reading:

"Follow his dictum's here and elsewhere don't question his logic and mention ZA bugs or test results he gets upset and HJ's your thread."

Oh and BTW don't listen to knowledgeable FW experts like Stem who carry out real tests and provide science based results, change your ZA based systems to trust your routers.

In case anyone was in doubt my own router is still set to Internet as it is not inside my PC.

[fax]

{QUOTE-> Why do you think you are always right about what the issues are and who has to prove what and if that proof that is provided is valid? ::)

Your blinkered style is, If others disagree with you, and thus the Z world view design, you state they must be wrong, misguided and/or they have a special broken PC or a copy of ZA that has unique bugs then ".... and you say they missed the point".

What a joke. Well at least you provide entertainment for the reader.

So for all you ZA newbies out there here is Fax's advice in one line to save you reading:

"Follow his dictum's here and elsewhere don't question his logic and mention ZA bugs or test results he gets upset and HJ's your thread."

Oh and BTW don't listen to knowledgeable FW experts like Stem who carry out real tests and provide science based results, change your ZA based systems to trust your routers.

In case anyone was in doubt my own router is still set to Internet as it is not inside my PC. <-QUOTE}

You have no other arguments than personal attacks, you simply want understand what I am talking about. Looks like you want to put users one against another... thats childish... Please stop spamming this thread!

Stem is doing a great job and I thank him for his dedication and time in supporting wilders users.... My question was/is very simple and I got no convincing answer. As simple as that.

There is no concrete security risk to set up my router as trusted (details in previous posts) and I would be happy to see my system compromised because my router is set this way. ;D

Cheers,
Fax

[Stem]

{QUOTE-> I think you missed the point... the issue here is why should the router set to untrusted and what are the concrete security risk of having the router set to trusted granted that the router is configured correctly...

Fax <-QUOTE}The point of this is from the view of all users, not one single setup/ user needs. Not all users on a LAN are on a trusted LAN.
If we look at a setup, lets say for a college/campus, where many users are on LAN, non would be trusted (certainly from my stand point), the gateway(router) would then have a question for trust. The router may well be capable of protection againts inbound attack (from Internet), but from within the LAN it could be compromised.
So, would you agree that simply saying add the router as trusted in all setups is not always the best approach?

You have mentioned your problems with DHCP/DNS when the router is set to Internet. I have found on base setup no such problems (but changing NIC card did shown some outbound DHCP being blocked). So, from this, there is a bug within ZA. From the help file, DHCP broadcasts are allowed within the Internet zone. So would it not be better for all to attempt to find this bug, so that ZA can be informed and correct this?

[fax]

{QUOTE-> The point of this is from the view of all users, not one single setup/ user needs. Not all users on a LAN are on a trusted LAN.
If we look at a setup, lets say for a college/campus, where many users are on LAN, non would be trusted (certainly from my stand point), the gateway(router) would then have a question for trust. The router may well be capable of protection againts inbound attack (from Internet), but from within the LAN it could be compromised.
So, would you agree that simply saying add the router as trusted in all setups is not always the best approach? <-QUOTE}

yep, absolutely agree... but we are not talking about campus, otherwise I would have mentioned it. And I am not talking about LAN trusted but only the router. In the specific case, the user (Escalader) has even a firewall in front of the router. And in my case indeed I have a LAN but with trusted and controlled/closed PCs.

{QUOTE-> You have mentioned your problems with DHCP/DNS when the router is set to Internet. I have found on base setup no such problems (but changing NIC card did shown some outbound DHCP being blocked). So, from this, there is a bug within ZA. From the help file, DHCP broadcasts are allowed within the Internet zone. So would it not be better for all to attempt to find this bug, so that ZA can be informed and correct this? <-QUOTE}

You mean DHCP broadcasting blocked or DHCP 53 blocked? At hight setting, DHCP and DNS are blocked (UDP 53, 67) and under certiain circumtances this may create problems if the router is managing DNS and DHCP and I have seen this many times (yes, broadcasting is not blocked, this is a necessary but not sufficient condition to avoid issues) . It depends also on the provider of the service (ISP), specific software like streaming, messenger, teleconference, and complex/multi connection can create huge and unnecessary logs in the firewall. Is it justifed to close connection from PC to router and vice versa from a security point of view? Not really....

But going back to the main question ... "what are the concrete security risk of having the router set to trusted granted that the router is configured correctly" ?

When thinking about optimal setting within ZA, I am thinking about the optimal combination between usability and security ..... To be clear: the issue is not... everything is working well or is not working well with the router as internet... I would like to see some concrete justifications for it to be set as it is. Otherwise is just personal preferences and I can't see any good reason for doing so apart from having ZA busy logging harmless connections.

Fax

[Stem]

This thread was split off originally to look at uPnP, that is why the "title" made.

You do keep going back to personal setup/needs which was never my point. If I was to advise to all questions based on my own setup/needs, then this would be incorrect.

{QUOTE-> At hight setting, DHCP and DNS are blocked (UDP 53, 67) <-QUOTE}This would infer a bug that allows this outbound. As this outbound is allowed on my setup. A bug that allows outbound is a major problem.


For me personally: If setting the router as "Trusted" could put "1 in 100" at risk due to setup (untrusted LAN) Then I discourage setting LAN as trusted by default.

{QUOTE-> But going back to the main question ... "what are the concrete security risk of having the router set to trusted granted that the router is configured correctly" ? <-QUOTE}As stated, it depends on the LAN.

Please do not look at this as a single setup, all setups differ, forget a single user and think of what would be best as default. (for all user needs)

[fax]

{QUOTE-> This thread was split off originally to look at uPnP, that is why the "title" made.

You do keep going back to personal setup/needs which was never my point. If I was to advise to all questions based on my own setup/needs, then this would be incorrect.

This would infer a bug that allows this outbound. As this outbound is allowed on my setup. A bug that allows outbound is a major problem.



As stated, it depends on the LAN.

Please do not look at this as a single setup, all setups differ, forget a single user and think of what would be best as default. (for all user needs) <-QUOTE}

Yes, I agree, if you have to give a generic setting that is valid for most users the LAN should not set to trusted. Unless the LAN is just one PC or few controlled PCs.

{QUOTE-> For me personally: If setting the router as "Trusted" could put "1 in 100" at risk due to setup (untrusted LAN) Then I discourage setting LAN as trusted by default. <-QUOTE}

Ok, got some sort of answer to the router issue. So, you are not so against a router as trusted depending on the specific case. For you its more a concern the LAN as trusted. If I understood well....

Fax

[Stem]

{QUOTE-> Yes, I agree, if you have to give a generic setting that is valid for most users the LAN should not set to trusted. Unless the LAN is just one PC or few controlled PCs. <-QUOTE}Thank you,
{QUOTE-> Ok, got some sort of answer to the router issue. So, you are not so against a router as trusted depending on the specific case. For you its more a concern the LAN as trusted. If I understood well....

Fax <-QUOTE}Now you see my point on this,
But, for the DHCP/DNS problems. do you think this needs to be looked at?

[fax]

{QUOTE-> Thank you,
Now you see my point on this,
But, for the DHCP/DNS problems. do you think this needs to be looked at? <-QUOTE}

If problems will arise to the user, yes... like loss of connection, problems or slow connection, difficulties in renewing IPs, etc. If instead everything is working fine and there are no problems... No need of fine tuning DHCP/DNS.

Did I understood correctly your question?

Fax

[Stem]

fax,

Well, what we need to look at is the DHCP/DNS connection problems users have, and why.

If we look at your statement:
{QUOTE-> At hight setting, DHCP and DNS are blocked (UDP 53, 67) and under certiain circumtances this may create problems if the router is managing DNS and DHCP and I have seen this many times <-QUOTE}
Most new users of ZA will be installing onto a setup that as a direct connection to the Internet, so the DHCP/DNS server will be in the Internet zone with high setttings. So from your above statement, if correct, then those users simply would not be able to connect to the Internet after installing ZA. So is there a need for all users of ZA to set the DHCP/DNS servers as "Trusted"?
{QUOTE-> (yes, broadcasting is not blocked, this is a necessary but not sufficient condition to avoid issues) <-QUOTE}Outbound DHCP broadcasts are all that is needed (with a firewall with UDP (pseudo) SPI) for DHCP, Yes, renewal DHCP will attempt outbound to IP stored for DHCP server, but if this connection cannot be made, then windows will broadcast to renew.

We have agreed that setting the LAN/Router as trusted will depend on the users setup, from your posts I see the main reason you set your router as trusted is due to intermittent connection problems{QUOTE-> When I had the router on internet I have experienced problems in connecting to specific websites and sometime loosing connection or slow connection... plus a lot of firewalls logs (don't like to see internal LAN IPs being blocked without any reasons). Most of the time is OK but sometimes not... <-QUOTE}
Now if we look at this. If as you say, DNS is blocked on Internet (as this is default to high settings), then you would not be able to connect out at all when you have the router as internet. Would you agree with this?

[fax]

{QUOTE-> fax,

Well, what we need to look at is the DHCP/DNS connection problems users have, and why.

If we look at your statement:

Most new users of ZA will be installing onto a setup that as a direct connection to the Internet, so the DHCP/DNS server will be in the Internet zone with high setttings. So from your above statement, if correct, then those users simply would not be able to connect to the Internet after installing ZA. So is there a need for all users of ZA to set the DHCP/DNS servers as "Trusted"?
Outbound DHCP broadcasts are all that is needed (with a firewall with UDP (pseudo) SPI) for DHCP, Yes, renewal DHCP will attempt outbound to IP stored for DHCP server, but if this connection cannot be made, then windows will broadcast to renew.

We have agreed that setting the LAN/Router as trusted will depend on the users setup, from your posts I see the main reason you set your router as trusted is due to intermittent connection problems
Now if we look at this. If as you say, DNS is blocked on Internet (as this is default to high settings), then you would not be able to connect out at all when you have the router as internet. Would you agree with this? <-QUOTE}

Well, I don't know the origin of the problem... ZA or not ZA fault.
I however seen hundreds of cases with connection problems due to DNS and DHCP IPs not in the trusted zone.

Thus my original reccomandation of having the router (that in that case was/is responsible for DNS and DHCP) in the trusted zone.

This setting, regardless of ZA bug or not, will avoid any potential problem and does not constitute a security risk per se.

Fax

[Stem]

{QUOTE-> Well, I don't know the origin of the problem... ZA or not ZA fault. <-QUOTE}Then should not the end user who has these problems report them directly to ZA, rather than have a "Workaround"?
{QUOTE-> Thus my original reccomandation of having the router (that in that case was/is responsible for DNS and DHCP) in the trusted zone.

This setting, regardless of ZA bug or not, will avoid any potential problem and does not constitute a security risk per se. <-QUOTE}But you have already agreed that the LAN cannot always be trusted, if you simply "Trust" the router in an untrusted LAN then there is a very real possiblilty of compromise.

[fax]

{QUOTE-> Then should not the end user who has these problems report them directly to ZA, rather than have a "Workaround"?
But you have already agreed that the LAN cannot always be trusted, if you simply "Trust" the router in an untrusted LAN then there is a very real possiblilty of compromise. <-QUOTE}

Good we are finally getting to the point I am interested in... so baseline: 1. LAN NOT trusted; 2. Router: Trusted. Which security risk in concrete terms? I would really look forward to this answer, since was the bottom line of all these posts.

By the way, you know that most seriouos vulnerabilities are indipendent from the trusting of the router, like the DNS spoofing.

On the reporting to ZA, no ones here have disputed that, if there is a problem, this cannot be sent to ZA. Was it?
Actually, more then once I have suggested to report/ask to ZA (e.g. calling home).

EDIT: reading back your message I think there is a baseline misunderstanding... when I say not trusted, I mean set to INTERNET in ZA. Not untrusted in general terms. You untrusted seems more the campus example where you actually set ZA to trust the LAN. This is clearly not secure....

Bottom line: Can we all agree that: if in ZA the LAN is set to Internet, the risk of setting the router to TRUSTED is minimal or negligible?
(Indeed there is always a risk with whatever settings.... 100% security does not exist)

Fax

[Stem]

{QUOTE-> Good we are finally getting to the point I am interested in... so baseline: 1. LAN NOT trusted; 2. Router: Trusted. Which security risk in concrete terms? <-QUOTE}IP spoofing.
Attacks against svchost which is allowed server rights (unsolicited inbound) in the trusted zone

[fax]

{QUOTE-> IP spoofing.
Attacks against svchost which is allowed server rights (unsolicited inbound) in the trusted zone <-QUOTE}

Both of these are indipendent from setting the router as internet in ZA...
With Spoofing you can jump any router/firewall (trusted/not-trusted) its just a builtin weakness of system. I think I have mentioned already the "elchapo router context" that compromised a system with spoofing. But you need some help to get into the machine before.

Uuhm...svchost can be compromised without the server right, vulnerabilities are a fact of life... don't need the help of the router.

I mean.... I can follow your arguments but in real life 99% of the risks to be compromised are not coming from the router... there are far easier ways to compromise systems without the need of touching the router.

Fax

[Stem]

{QUOTE-> With Spoofing you can jump any router/firewall (trusted/not-trusted) <-QUOTE}IP spoofing against an SPI firewall where unsolicited inbound is blocked is quite difficult (although not impossible). When you setup a "Trusted IP, such as the router, then unsolicited inbound will be allowed from that IP, so to make bypass/attack (with IP spoof as router) is much easier (even simple at times), and in such a setup I could/can easily DOS/DDOS another node on LAN(as example)

.

[fax]

{QUOTE-> IP spoofing against an SPI firewall where unsolicited inbound is blocked is quite difficult (although not impossible). When you setup a "Trusted IP, such as the router, then unsolicited inbound will be allowed from that IP, so to make bypass/attack (with IP spoof as router) is much easier (even simple at times), and in such a setup I could/can easily DOS/DDOS a node on LAN. <-QUOTE}

uuuhm.... interesting... just trying to follow.
Router does NAT and have a SPI. It is trusted in ZA.

First: How can you jump over the router? Spoofing works if your system will send a call and get back the answer... without a call from the system (my PC) and a spoofed replied by the internet ... no spoofing.

So regardless of the router in the ZA trusted zone or internet the spoofing will work, since ZA will allow the incoming that is an answer from a 'legitimate' previous call...

Spoofing can simply jump all defences.... it is difficult but possible. If I find back the DNS spoofing example I put the link here...

Found it:
"......Could this method get packets past a software firewall, yes.
Could this method get packets past a high end firewall, yes.
Does this method require a lot of planets to line up, yes....."

A very interesting reading...
http://www.dslreports.com/forum/remark,14723926
Complete post here:
http://www.dslreports.com/forum/remark,14719484

Fax

[Stem]

{QUOTE-> Router does NAT and have a SPI. It is trusted in ZA. <-QUOTE}We are talking attack from another node on untrusted LAN, with router as "Trusted"

We have been disgussing LAN/router throughout this thread. Why are you now attempting to divert this to router/internet?

[fax]

{QUOTE-> We are talking attack from another node on untrusted LAN, with router as "Trusted"

We have been disgussing LAN/router throughout this thread. Why are you now attempting to divert this to router/internet? <-QUOTE}

LAN is set to internet.... as originally posted...
Only the router is set to trusted.

Fax

[Stem]

{QUOTE-> LAN is set to internet.... as originally posted...
Only the router is set to trusted.

Fax <-QUOTE}Yes, and another node on LAN can easily spoof the router IP, and with the router as trusted the packets will be allowed unsolicited.

[fax]

{QUOTE-> Yes, and another node on LAN can easily spoof the router IP, and with the router as trusted the packets will be allowed unsolicited. <-QUOTE}

Can you give a concrete example... how the LAN can spoof the router IP?
Unless you have access to the router... what call from the LAN to the router would trigger a call back via the router to my PC though not originating from the LAN but from the router? Its a dead communication...

Once the LAN as router IP it needs to pass via the router to my system.... and my system should originally been calling the router to get back a spoofed reply.

I can't see the logic...

Fax

[Stem]

{QUOTE-> ....how the LAN can spoof the router IP? <-QUOTE}It is very easy to build(create) packets containing any header info (there is even software on the internet that will do this, you just need to know what info to place within the packet), which within a LAN I can use for "ARP poisoning", "DHCP poisoning(Invalid DHCP offer), or simple DOS attacks, these are just some of the "Attacks" I can make on a LAN where the router is trusted(all unsolicited inbound is allowed from that IP)
{QUOTE-> Unless you have access to the router... what call from the LAN to the router would trigger a call back via the router to my PC though not originating from the LAN but from the router? Its a dead communication... <-QUOTE}I will not post info on how bypasses/attacks are made, as they would be removed, as they would be against forum TOS. But I will say that in a LAN where the IP of the gateway/Router is trusted. I can force that PC to make my PC the gateway and all comms would pass through my PC.

Yes, we could go back to where you say, well these attackes can be made when the router is set to internet, but, on such attempts when the router is internet, the unsolicited inbound would cause alert/log of such event, when that IP is set as trusted, spoofed or not, there will be no alert/log.

[Escalader]

{QUOTE-> Can you give a concrete example... how the LAN can spoof the router IP?
Unless you have access to the router... what call from the LAN to the router would trigger a call back via the router to my PC though not originating from the LAN but from the router? Its a dead communication...

Once the LAN as router IP it needs to pass via the router to my system.... and my system should originally been calling the router to get back a spoofed reply.

I can't see the logic...

Fax <-QUOTE}

I can see the logic. But this is your learning thread Fax and I won't break the flow of Q and A for you.;)

My system shares a the Lan router with a second "fun oriented PC" which is used for higher risk surfing. On line gaming no in/out firewall and only free old security software.

So since nobody here should / would fully trust that PC I don't and won't trust that router! Far as I'm concerned it is part of the WWW!

This is why Stem is right again, the best generic advice for all ZA users is set the LAN/Router as Internet.

But it is good that you have accepted that approach now!

[fax]

{QUOTE-> It is very easy to build(create) packets containing any header info (there is even software on the internet that will do this, you just need to know what info to place within the packet), which within a LAN I can use for "ARP poisoning", "DHCP poisoning(Invalid DHCP offer), or simple DOS attacks, these are just some of the "Attacks" I can make on a LAN where the router is trusted(all unsolicited inbound is allowed from that IP)
I will not post info on how bypasses/attacks are made, as they would be removed, as they would be against forum TOS. But I will say that in a LAN where the IP of the gateway/Router is trusted. I can force that PC to make my PC the gateway and all comms would pass through my PC.

Yes, we could go back to where you say, well these attackes can be made when the router is set to internet, but, on such attempts when the router is internet, the unsolicited inbound would cause alert/log of such event, when that IP is set as trusted, spoofed or not, there will be no alert/log. <-QUOTE}

Nope, this attacks are as difficult as to be in the internet... and still not clear how to do them.

Let's take the example of most home network. Two PC, One Router NAT/SPI.
The router does control DHCP and DNS.

1. Router 192.168.1.1
2. My PC 192.168.1.2
3. Evil PC 192.168.1.3

All communication need to pass via the router since its the one managing DNS and DHCP. Router is closed and evil PC has not access on its configuration. Unless you are taking advantage of a router vulnerability you cannot spoof the router IP and send a a packet via the router to my PC with the same router IP.

If yes, I would really like to see an example. I think we are not talking about concrete exploit code....

Fax

[fax]

{QUOTE-> I can see the logic. But this is your learning thread Fax and I won't break the flow of Q and A for you.;)

My system shares a the Lan router with a second "fun oriented PC" which is used for higher risk surfing. On line gaming no in/out firewall and only free old security software.

So since nobody here should / would fully trust that PC I don't and won't trust that router! Far as I'm concerned it is part of the WWW!

This is why Stem is right again, the best generic advice for all ZA users is set the LAN/Router as Internet.

But it is good that you have accepted that approach now! <-QUOTE}

Hi ArrowPilot,
actually I like this nick better than your original...

I think we are all here to learn something new... if you do things without knowing why you are doing it... is not really learning ;D

Fax

[Stem]

{QUOTE-> Nope, this attacks are as difficult as to be in the internet... and still not clear how to do them.

Let's take the example of most home network. Two PC, One Router NAT/SPI.
The router does control DHCP and DNS.

1. Router 192.168.1.1
2. My PC 192.168.1.2
3. Evil PC 192.168.1.3

All communication need to pass via the router since its the one managing DNS and DHCP. Router is closed and evil PC has not access on its configuration. Unless you are taking advantage of a router vulnerability you cannot spoof the router IP and send a a packet via the router to my PC with the same router IP.

If yes, I would really like to see an example. I think we are not talking about concrete exploit code....

Fax <-QUOTE}
You base your info on what?

It is very easy to send a packet to another PC on LAN with a spoofed IP, which can be set as the router IP. The router does not perform internal SPI (packets routed internally), when the router sees a packet with a destination IP of a PC on LAN, it will forward without checking which PC (IP) the packet as originated. I can place whatever IP I want into the packets source, the router IP or even a non LAN IP.

Set up and try it yourself.

[fax]

{QUOTE-> You base your info on what?

It is very easy to send a packet to another PC on LAN with a spoofed IP, which can be set as the router IP. The router does not perform internal SPI (packets routed internally), when the router sees a packet with a destination IP of a PC on LAN, it will forward without checking which PC (IP) the packet as originated. I can place whatever IP I want into the packets source, the router IP or even a non LAN IP.

Set up and try it yourself. <-QUOTE}

Ok, yes, indeed you are right... the same applies from the internet... but from the LAN is easier since you are already starting from a trusted IP...

So, ending message for me is: you can safely set your router as trusted if you trust the LAN. Or if you like: do not set your router as trusted if your LAN is not trusted ;D

For my specific case: I can safely set my router as trusted.

Can we finally agree on this? :-*

Cheers,
Fax

[Stem]

I have no problem with you setting the router or LAN as trusted in such a setup as yours(where you know all the LAN is trusted). It as just been my point that not all users can\should do this.

My main concern is the fact that (as you have mentioned yourself) many users have problems with ZA and DHCP/DNS, and the current workaround is to set the LAN/router as trusted, which is, as we agree, not good for all users.

[fax]

{QUOTE-> I have no problem with you setting the router or LAN as trusted in such a setup as yours(where you know all the LAN is trusted). It as just been my point that not all users can\should do this.

My main concern is the fact that (as you have mentioned yourself) many users have problems with ZA and DHCP/DNS, and the current workaround is to set the LAN/router as trusted, which is, as we agree, not good for all users. <-QUOTE}

The workaround is to set DNS and DHCP as trusted not the LAN.
Looking into, for example, rule based firewall, if you do not allow DNS/DHCP you hardly can have any connection working...

For the specific case of ZA, for example, some ISP needs feedback on the "online" status of the connection, otherwise they will close the active connection and allocated the dynamic IP to another machine...

EDIT: Meanwhile I am trying to spoof and ARP poisoning with a PC in the LAN (using Cain&Abel) and I am miserably failing... well, didn't spend to much time on it and I am not going to spending more... :)

Cheers,
Fax

[Cold Pizza]

{QUOTE-> I have no problem with you setting the router or LAN as trusted in such a setup as yours(where you know all the LAN is trusted). It as just been my point that not all users can\should do this.

My main concern is the fact that (as you have mentioned yourself) many users have problems with ZA and DHCP/DNS, and the current workaround is to set the LAN/router as trusted, which is, as we agree, not good for all users. <-QUOTE}

May i add to this discussion, as i am not trying to take sides here. But, i agree totally agree with you (Stem), in reference to putting the Lan/router, as trusted, not good for all users. On my setup, NOTHING is Trusted. This also applies to the so called Heart Beat messages that ISP's pings your firewall to see what is going on, and that should be allowed for them to enter. Not with me they don't.

[Stem]

{QUOTE-> The workaround is to set DNS and DHCP as trusted not the LAN.
Looking into, for example, rule based firewall, if you do not allow DNS/DHCP you hardly can have any connection working... <-QUOTE}With a firewall with full SPI (including UDP table) as ZA is supposed to be, the user only needs to set outbound for DHCP/DNS. Certainly not allow all unsolicted inbound from the servers.

{QUOTE-> Meanwhile I am trying to spoof and ARP poisoning with a PC in the LAN (using Cain&Abel) and I am miserably failing... <-QUOTE}Now why am I not surprised by this.
By the way, I thought "cain&abel" was a "password recovery tool for Microsoft Operating Systems"(packet sniffer). Can you create and forward packets/attacks with this?

[fax]

{QUOTE-> With a firewall with full SPI (including UDP table) as ZA is supposed to be, the user only needs to set outbound for DHCP/DNS. Certainly not allow all unsolicted inbound from the servers.

Now why am I not surprised by this.
By the way, I thought "cain&abel" was a "password recovery tool for Microsoft Operating Systems"(packet sniffer). Can you create and forward packets/attacks with this? <-QUOTE}

Indeed the Cain&Abel has evolved meanwhile, you have all sort of tools... ARP poisoning, sniffing and the password recovery tools....
But I didn't spend too much time on it...

Fax

[fax]

{QUOTE-> May i add to this discussion, as i am not trying to take sides here. But, i agree totally agree with you (Stem), in reference to putting the Lan/router, as trusted, not good for all users. On my setup, NOTHING is Trusted. This also applies to the so called Heart Beat messages that ISP's pings your firewall to see what is going on, and that should be allowed for them to enter. Not with me they don't. <-QUOTE}

I think the discussion has been useful in setting the boundaries for saying: "do not trust your router". We started with UPnP and ended up that the key element for reccomending trusted/not trusted is the LAN.

There is nothing wrong to trust the router if your LAN is just your computer or if your are fully controlling the elements of your LAN (i.e. the LAN is secure and trusted).

Fax

[Stem]

{QUOTE-> Indeed the Cain&Abel has evolved meanwhile, you have all sort of tools... ARP poisoning, sniffing and the password recovery tools....
But I didn't spend too much time on it...

Fax <-QUOTE}I will have to take another look (it as been a while).

The tools I use are not available, but, for spoofing/attack for LAN testing, have a play with "Colasoft packet builder", I have used this in the past, you can download from here (http://www.download3000.com/download_17232.html) (free app)

Remember to take the router out of "Trusted" before spoofing the router IP, so that you will get alert/log in ZA. (if the router is set as trusted, and you forward a spoofed packet containing the router IP, then the packet will be allowed onto the stack)

[fax]

{QUOTE-> I will have to take another look (it as been a while).

The tools I use are not available, but, for spoofing/attack for LAN testing, have a play with "Colasoft packet builder", I have used this in the past, you can download from here (http://www.download3000.com/download_17232.html) (free app)

Remember to take the router out of "Trusted" before spoofing the router IP, so that you will get alert/log in ZA. (if the router is set as trusted, and you forward a spoofed packet containing the router IP, then the packet will be allowed onto the stack) <-QUOTE}

Thanks, I will try colasoft....

Fax

[fax]

{QUOTE-> With a firewall with full SPI (including UDP table) as ZA is supposed to be, the user only needs to set outbound for DHCP/DNS. Certainly not allow all unsolicted inbound from the servers. <-QUOTE}

Hi!
Going back to this... just a clarification... shouldn't be TCP allowed out to the remote port 53 of the DNS server IP and UDP allowed inbound and outbound to the remote port 53 of the DNS server? That is normally was it is done...

For DHCP we would allow (inbound and outbound ) port 67 from the remote port 68 of the router IP using UDP. Then you can block multicast/broadcast...

Fax

[Stem]

{QUOTE-> Hi!
Going back to this... just a clarification... shouldn't be TCP allowed out to the remote port 53 of the DNS server IP and UDP allowed inbound and outbound to the remote port 53 of the DNS server? That is normally was it is done...

<-QUOTE}For DNS: Some servers use TCP, some use UDP (but I do not know any servers that use both). Most rules based firewalls that have a predefined ruleset for DNS will have both (so you user will not have connection problems).

For the UDP to allow in both directions, this depends on the firewall. ZA is full SPI including UDP(pseudo), so only outbound should be needed. You can look at other filters/firewalls to compare, the easiest would be to look at Comodo. You will see from its network rules only outbound is allowed. For DHCP/DNS the replies are allowed due to UDP (pseudo) SPI (as ZA should be doing)


{QUOTE-> For DHCP we would allow (inbound and outbound ) port 67 from the remote port 68 of the router IP using UDP. Then you can block ulticast/broadcast... <-QUOTE}No, first, broadcasts made from the PC for DHCP are from local port 68 to remote port 67.
Again, with a firewall that contains UDP (pseudo) SPI only the outbound broadcast should be needed:-
Allow out UDP local port 68 remote IP 255.255.255.255 remote port 67

I did make a tight ruleset for Comodo (due to a PM). You can see within that ruleset (http://www.wilderssecurity.com/showpost.php?p=951314&postcount=26) the allowed outbound DHCP broadcast. This works fine with Comodo, with no need to trust the server or place a rule to allow the returned packets (the same is for all other firewalls/packet filters I have used that contain UDP(pseudo) SPI such as CHX)

[Escalader]

Stem:

Sorry to break into this learning thread but reading the clarifications for Fax here are a 2 extracts that worry me (I'm easily worried;D )

"ZA is full SPI including UDP(pseudo), so only outbound should be needed. "

"For DHCP/DNS the replies are allowed due to UDP (pseudo) SPI (as ZA should be doing)"

You mention Comodo and CHX.

What I ask you is this do either of those contain the program by program settings features that we are working on in the "How to optimize ZA Pro settings" thread ? ie block MS Media Player and games from connecting out?

[fax]

{QUOTE-> For DHCP/DNS the replies are allowed due to UDP (pseudo) SPI (as ZA should be doing) <-QUOTE}

I promise, last question.... :)

I see UDP returned from port 53 of the DNS back. DNS in the ZA is set as Internet and the logs showed UDP blocked. But set as Trusted it has no UDP in blocked.

Is this normal?? Getting confused :blink:

Fax

[Stem]

{QUOTE-> You mention Comodo and CHX.

What I ask you is this do either of those contain the program by program settings features that we are working on in the "How to optimize ZA Pro settings" thread ? ie block MS Media Player and games from connecting out? <-QUOTE}
Comodo, yes, this gives program network access control.
CHX, No, this is a packet filter, when I use this I also use SSM or PS to control program network access.

[Stem]

{QUOTE-> I promise, last question.... :)

I see UDP returned from port 53 of the DNS back. DNS in the ZA is set as Internet and the logs showed UDP blocked. But set as Trusted it has no UDP in blocked.

Is this normal?? Getting confused :blink:

Fax <-QUOTE}This is because of the bug within ZA as I have mentioned. It depends on the hardware NIC being used.
On my first setup for this testing, one NIC worked flawlessly, one had problems with blocked DHCP/DNS.
On my current setup (different hardware), ZA as no problems with DHCP/DNS on either NIC.(My settings are the same as before, broadcasts option disabled, LAN as internet, svchost only allowed outbound, DNS service active at this time, no blocked DHCP/DNS at all, (DNS servers are direct from internet, not router in this setup))

For a test in your setup: Disable the windows DNS client (Service), then check for blocked DNS replies from DNS servers (set as Internet, not trusted).

[fax]

{QUOTE-> For a test in your setup: Disable the windows DNS client (Service), then check for blocked DNS replies from DNS servers (set as Internet, not trusted). <-QUOTE}

Nope, client DNS/DHCP OFF... DNS internet... still get UDP blocked.
Anyway, does not matter... thanks anyway for the help.

Fax

[Escalader]

{QUOTE-> Hi ArrowPilot,
actually I like this nick better than your original...

I think we are all here to learn something new... if you do things without knowing why you are doing it... is not really learning ;D

Fax <-QUOTE}

Don't recall asking for an opinion on an id used elsewhere?

Many posts ago offered Fax and gre87y an email address via PM so that personal differences would not clutter up this forum.

Fax and gre87y have not taken advantage of that offer.

[fax]

{QUOTE-> Don't recall asking for an opinion on an id used elsewhere? <-QUOTE}

LoL it was a Joke... forget about it.

{QUOTE-> Many posts ago offered Fax and gre87y an email address via PM so that personal differences would not clutter up this forum.

Fax and gre87y have not taken advantage of that offer. <-QUOTE}

I don't see the point of private e-mails.
This is an open forum, so for the matters related to the post... I would like to share my info with everybody. And if a user go offtopic, Stem is very quick in cleaning and splitting the posts in more thread.

More users --> more opinions, experiences, information.
If you wanted just Stem feedback then why using an open forum?

Cheers,
Fax

[Stem]

@Escalader, fax,

Lets please stay on topic.

I know the topic as digressed a little, but I would prefer to follow this to try and find the problem with ZA and the blocking of the DNS. Unfortunatly my test PC is not seeing this problem,... so I am going to install VM`s to see if I can reproduce that way.

@fax,
You mentioned about the windows time service being broken, and the fact you now use a different server for time sync. This I presume is UDP? if so, what rules are in place for this? What I mean is, if this is UDP and only outbound is allowed for this, is the inbound (returned packets) being blocked? or is that server set as trusted?

[fax]

{QUOTE-> @fax,
You mentioned about the windows time service being broken, and the fact you now use a different server for time sync. This I presume is UDP? if so, what rules are in place for this? What I mean is, if this is UDP and only outbound is allowed for this, is the inbound (returned packets) being blocked? or is that server set as trusted? <-QUOTE}

Hi!
unfortunately I am the process of moving to VISTA on the machine... so I don't have anymore the specifc logs and I don't remember what exactly was blocked (UDP, or whatever)... for the clock, I did not make any changes in ZA, just changed the server used by the service.

Thanks and sorry,
Fax

[Stem]

Hi fax,

OK,
Will you be installing ZA onto Vista? If so, when you do, could you re-check for the blocked DNS
TIA

[fax]

{QUOTE-> Hi fax,

OK,
Will you be installing ZA onto Vista? If so, when you do, could you re-check for the blocked DNS
TIA <-QUOTE}

Yes, Ok.. I will.

Fax

[Escalader]

{QUOTE-> @Escalader, fax,

Lets please stay on topic.

I know the topic as digressed a little, but I would prefer to follow this to try and find the problem with ZA and the blocking of the DNS. Unfortunatly my test PC is not seeing this problem,... so I am going to install VM`s to see if I can reproduce that way.

@fax,
You mentioned about the windows time service being broken, and the fact you now use a different server for time sync. This I presume is UDP? if so, what rules are in place for this? What I mean is, if this is UDP and only outbound is allowed for this, is the inbound (returned packets) being blocked? or is that server set as trusted? <-QUOTE}

FYI: MS did a fix to the time service on XP 2 days ago.

[Stem]

{QUOTE-> FYI: MS did a fix to the time service on XP 2 days ago. <-QUOTE}Yes,..... can you look for any possible problems with this, what I need to see is any blocked outbound or inbound for this service (do I presume this still is UDP on ports 123?)

[Escalader]

{QUOTE-> Yes,..... can you look for any possible problems with this, what I need to see is any blocked outbound or inbound for this service (do I presume this still is UDP on ports 123?) <-QUOTE}

With this update the time.nist.gov sync failed when I tried to update,
as to UDP/123 I have no data on that.

[Stem]

{QUOTE-> With this update the time.nist.gov sync failed when I tried to update, <-QUOTE}Please explian,.. failed?
{QUOTE-> as to UDP/123 I have no data on that. <-QUOTE}this was the udp for time server.

[Escalader]

As before mine in red

{QUOTE-> Please explian,.. failed?

see attached error image

this was the udp for time server. <-QUOTE}

yes, again I can't help with this one, sorry

[Stem]

The windows time is still using UDP port 123, but when ZA is installed, this does not work in my setup, on removing ZA, time sync works again.

[fax]

{QUOTE-> As before mine in red

yes, again I can't help with this one, sorry <-QUOTE}

time.windows.com and time.nist.gov will simply fail.
Try time-a.nist.gov and it will work... :)

190217

Why would UDP be rejected for nist.gov and not for a-nist.gov. Is this a ZA issue?
Really don't know, didn't have yet the time to install a proper connection logger.

Fax

[Stem]

With ZA installed, yes it fails, with ZA uninstalled time sync works:-
I have just time sync now (UK time)

190220

[fax]

{QUOTE-> With ZA installed, yes it fails, with ZA uninstalled time sync works:-
I have just time sync now (UK time)

190220 <-QUOTE}

Did you tried with the server I have mentioned (and ZA active) and what is the difference in the call or in the response?
You will need to inspect the packets sent and received...

Fax

[Stem]

{QUOTE-> Did you tried with the server I have mentioned (and ZA active) and what is the difference in the call or in the response?
You will need to inspect the packets sent and received...

Fax <-QUOTE}As I mentioned here (http://www.wilderssecurity.com/showthread.php?p=1008325#post1008325), when ZA is installed there is no packet sent for time sync, and no log in ZA to show as blocked.

[fax]

{QUOTE-> As I mentioned here (http://www.wilderssecurity.com/showthread.php?p=1008325#post1008325), when ZA is installed there is no packet sent for time sync, and no log in ZA to show as blocked. <-QUOTE}

Delete the response by mistake... posting again.

Stem I know. I am trying to go beyond and understand why packets are blocked with some servers and NOT for others. What is the difference between the two? Do you understand the issue?

There must be an explanation that goes beyond "I have shut down ZA" and it works....

Fax

[Stem]

{QUOTE-> Stem I know. I am trying to go beyond and understand why packets are blocked with some servers and NOT for others. What is the difference between the two? Do you understand the issue? <-QUOTE}I think this is more of a case that time sync works in some setups with ZA and not in others.

{QUOTE-> There must be an explanation that goes beyond "I have shut down ZA" and it works.... <-QUOTE}I have been trying to put forward similar for the problems seen by some (not all) of DHCP/DNS problems, this should go beyond "Place the servers as trusted and it works" ;)

[fax]

{QUOTE-> I think this is more of a case that time sync works in some setups with ZA and not in others.

I have been trying to put forward similar for the problems seen by some (not all) of DHCP/DNS problems, this should go beyond "Place the servers as trusted and it works" ;) <-QUOTE}

ufff, waste of time... Did you actually tried to change the server? If not... you should say. "No I have not tried it" and "I don't know why it works with a server and not with another"...

Its like to talk to a rubber wall, anyway, good luck I am fade up with your attitude. >:(

Fax

[Escalader]

Guy's guy's this is just a technical matter so lets stay on topic;D

I tried Fax's time sync link see attached jpg's and you will see 1 fails and 1 is successful.

I did this test with ZA pro removed according to the rules provided!

Conclusion: Well one might think that this one is independent of ZA!;D

[Stem]

@Escalader,

The main point of this with the time sync (for me) is the fact that ZA silently blocks the outbound udp packet (on my setups). The server you place for the time sync is irrelevant, as for example, I can place "wilderssecurity.com" as the time server,.. yes,.. you would get a "Failed", but the outbound udp is still made to the server you place. With ZA installed there is no outbound time sync attempted(udp port 123) seen at my gateway, for whatever server I place for time sync.

[Stem]

{QUOTE-> Its like to talk to a rubber wall, anyway, good luck I am fade up with your attitude. >:(

Fax <-QUOTE}Of corse you can put forward your own opinion of me, but when it come`s to facts you appear to have a problem.

I have seen quite a number of posts by yourself, that are inaccurate even misleading, I have put replies to correct these, but you are argumentative even insulting at times due to these corrections, even though your info is proved as incorrect.
My attitude to you as been earned by yourself.

[fax]

{QUOTE-> Of corse you can put forward your own opinion of me, but when it come`s to facts you appear to have a problem.

I have seen quite a number of posts by yourself, that are inaccurate even misleading, I have put replies to correct these, but you are argumentative even insulting at times due to these corrections, even though your info is proved as incorrect.
My attitude to you as been earned by yourself. <-QUOTE}

ZA does NOT block UDP. Check your facts before posting.
This is specific to time.windows.com

Thus my follow up question: Why it fails on time.windows.com?
But if I have to post my question 5 times before you understand the issue. I state again "what a waste of time".

On the rest, no comment.

Fax
A screenshot of successful time sync, just to show you how it works...
190304

[Stem]

{QUOTE-> ZA does NOT block UDP. Check your facts before posting. <-QUOTE}I check all before posting. As I have stated, these packets are blocked on my setups. But my posting a log that shows no attempted outbound time sync proves nothing, and as ZA is not logging these blocked packets, these cannot be shown.
You did at first put forward these problems where due to the windows time sync being broken, as I have shown on my setup, time sync worked correctly untill I installed ZA.

As with your own setup, you say you have problems with DHCP/DNS when the servers are set to internet, I have posted logs to show there is no problem with this on my setups.

I can put forward further logs to show DHCP/DNS working correctly without a need to place the DHCP/DNS servers as trusted, but then you would put forward that in your own setup these do not work correctly.

As I have stated, there is a problem with ZA, there is some conflict/bug within ZA and the hardware in use, that is causing these problems. How many time do I need to state that?

I do find it strange that you put so much effort into this time sync problem, but make no effort into looking at your (and others) problems with the DHCP/DNS servers.
{QUOTE-> But if I have to post my question 5 times before you understand the issue. <-QUOTE}You keep posting info such as:-{QUOTE-> a recent MS Patch broken the service... have you tried to change the server?{QUOTE-> time.windows.com and time.nist.gov will simply fail <-QUOTE} <-QUOTE}As I have posted, without ZA installed, the service/server does not fail to time.windows.com (http://www.wilderssecurity.com/showthread.php?p=1011556#post1011556) but you have to keep trying to find workarounds for ZA, as you do for DHCP/DNS,.... these should work without the need for such workarounds.

[fax]

{QUOTE-> I check all before posting. As I have stated, these packets are blocked on my setups. But my posting a log that shows no attempted outbound time sync proves nothing, and as ZA is not logging these blocked packets, these cannot be shown.
You did at first put forward these problems where due to the windows time sync being broken, as I have shown on my setup, time sync worked correctly untill I installed ZA.

As with your own setup, you say you have problems with DHCP/DNS when the servers are set to internet, I have posted logs to show there is no problem with this on my setups.

I can put forward further logs to show DHCP/DNS working correctly without a need to place the DHCP/DNS servers as trusted, but then you would put forward that in your own setup these do not work correctly.

As I have stated, there is a problem with ZA, there is some conflict/bug within ZA and the hardware in use, that is causing these problems. How many time do I need to state that?

I do find it strange that you put so much effort into this time sync problem, but make no effort into looking at your (and others) problems with the DHCP/DNS servers.
You keep posting info such as:-As I have posted, without ZA installed, the service/server does not fail to time.windows.com (http://www.wilderssecurity.com/showthread.php?p=1011556#post1011556) but you have to keep trying to find workarounds for ZA, as you do for DHCP/DNS,.... these should work without the need for such workarounds. <-QUOTE}

Yes, you still missing the point... and you have not checked on other time servers. Unprofessional... For you everything boils down to hardware problems and setup + ZA bug.

This is not a hardware problem nor a "on my setup". DNS/DHCP are irrelevant.

I give up! :thumbd: Mission impossible.

Fax

[Stem]

{QUOTE-> Yes, you still missing the point... and you have not checked on other time servers. <-QUOTE}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 (http://www.wilderssecurity.com/showthread.php?p=1012494#post1012494)

[BILL G]

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?

[fax]

{QUOTE-> 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? <-QUOTE}


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... :wacko:

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... ;D

Fax

[Escalader]

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

.....

What does this tell us? <-QUOTE}

Dear Mr Gates: ;D

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

More later

[BILL G]

Escalader

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

[Escalader]

{QUOTE-> Escalader

I do not take kindly to Insults. Please Go to the Back of the Bus. <-QUOTE}

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!

[BILL G]

Escalader

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

[Escalader]

{QUOTE-> Escalader

No problem. I found it Funny + a matter of time. <-QUOTE}

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;D

[Escalader]

{QUOTE-> 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? <-QUOTE}

Bill:

I'm back on the bus;D

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?

[oldshep]

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.

[fax]

{QUOTE-> 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. <-QUOTE}

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

[oldshep]

{QUOTE-> Fax: 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). <-QUOTE}

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

{QUOTE-> Fax: 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/med...ser_manual.pdf
<-QUOTE}

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.

[fax]

{QUOTE-> 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. <-QUOTE}

Hi!
not my position but a way to do it... ;D
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

[oldshep]

{QUOTE->
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)
<-QUOTE}
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;D .

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

[oldshep]

{QUOTE-> I'll post when I get a chance to test it out. Thanks for the suggestion. <-QUOTE}

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?

[fax]

{QUOTE-> 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? <-QUOTE}

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

[oldshep]

{QUOTE-> try to do the same but create the expert rule at firewall level and not at program level to see if it works... <-QUOTE}
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. :thumb:
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

[fax]

{QUOTE-> 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. :thumb:
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 <-QUOTE}

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

[Stem]

{QUOTE-> 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? <-QUOTE}They are probably the DNS lookups for the ZA logging.

[oldshep]

{QUOTE-> Are you by chance using any Citrix products (web development)?? <-QUOTE}

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.

[oldshep]

{QUOTE-> They are probably the DNS lookups for the ZA logging. <-QUOTE}

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?

[Stem]

{QUOTE-> Can you explain further or maybe point me to some online reference? <-QUOTE}From my logs, the "blank" entries are corresponding to reverse DNS lookups (http://en.wikipedia.org/wiki/Reverse_DNS_lookup). 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.

[oldshep]

{QUOTE-> From my logs, the "blank" entries are corresponding to reverse DNS lookups (http://en.wikipedia.org/wiki/Reverse_DNS_lookup). 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. <-QUOTE}

Thanks Stem for the explanation and reference. 8)

[fax]

{QUOTE-> 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. <-QUOTE}

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