XPsp2 firewall - bug? - disables on certain networks

[RJ]

I've posted this a few times, but never with "full details" - so
hoping that this will clarify the question, the fault, and hopefully
others may recognise the issue and either panic or offer a solution!

We are having an issue with the XPsp2 firewall in a corporate
environment which we believe affects everyone. However, we are unable
to find any solutions for it. The result is that companies may be
exposing remote workers to firewall-less clients which, if connected
via VPN, could expose a companys network.

Here are the details, and I would really appreciate your thoughts!

We deploy firewall settings via GPO. The Domain setting is "Windows
Firewall Off". The Standard setting is "Windows Firewall On".

So – when removing a computer form the corporate LAN to any other LAN
then the firewall automatically enables. This is superb and perfect.
However…

Windows XPsp2 firewall determines connection state via the DNS suffix
of the connection. This is usually proved by the DHCP server. As
such, a DHCP server saying "internetcafe.com" for example will get the
machine to enable the firewall.

But this leaves three issues:-

1. A deliberately designed DHCP server that publishes the same DNS
domain name as the corporate domain name will get the computer to
disable the firewall and expose itself.
2. Certain DHCP servers where DNS Domain Name is not set will not send
a default "blank" domain. This makes the computer default to the DNS
domain name of the company, resulting in the firewall being disabled.
This can be seen with WatchGuard SoHo 6TC DHCP server. Windows 2003
DHCP server defaults to "blank".
3. If you use settings on the client to disable Auto IP Addressing in
the event of no DHCP server (we need this setting) – then if the
computer is plugged into any LAN without a DHCP server, the laptop
(correctly) defaults to the last known DHCP settings, including DNS
suffix, and disables the firewall!

We were just about to roll our a IPSec SecurID VPN solution to allow
users to connect over the Internet, but this discovery means that
there may be situations where a deliberately configured DHCP server
(unlikely) or a badly configured DHCP server (more likely) may well
disable the firewall on our clients and cause us major security issues
for obvious reasons.

Options that are not appropriate:-

1. Permanently enabling firewall. (On the LAN we need quite a few
ports open for remote management tools, admin access etc. These
exceptions would also be applied when remote (due to above issue) and
hence open up the system anyway)

We were under the impression the Windows firewall was a little more
intelligent than just checking DNS suffixes – e.g. actually
communicating with the Active Directory to confirm connection, but
alas not.

So – we feel anyone using XPsp2 firewall and trusting it in a
corporate environment is making a mistake – UNLESS we are wrong! If
so, please tell us where we are going wrong! Is there any 3rd party
firewall that can more accurately detect if network connections are
the corporate LAN or not?

Many thanks!

RJ

 

[John M]

Hey RJ,
You bring up valid points that I am trying to stress to my management
also. That when employees take their computers on the road, they are wide
open because we turned the firewall off.

So we turned the firewall on via group policy. Because we limited the port
exceptions by IP address we feel more confident about being secure. We only
put in subnets from sources we know and trust for both domain and standard
profile. For a user to hack in, they would have to know which port is open
and spoof an IP address that is in the allowed list. We don't allow any echo
requests for the standard profile. Thsi didn't take much work for us,
because by IM policy users are not allowed to allow connections to their
computer unless for an approved process. You may be in a different
situation.

I'm curious as to where you learned that SP2 firewall determines it's
connection via the DNS suffix, I could only find that it is determined
wether it can contact a domain controller or not.

 

[Torgeir Bakken \(MVP\)]

I'm curious as to where you learned that SP2 firewall determines
it's connection via the DNS suffix, I could only find that it is
determined wether it can contact a domain controller or not.

Hi

For the WinXP SP2 FW, contact with the domain controller is not
a part of this determination process (where did you find that
statement?).

Here is how the SP2 firewall determines if it is to activate
the domain or standard profile:

If last-received Group Policy update DNS name match any of the
connection-specific DNS suffixes of the currently connected
connections (not PPP or SLIP-based) on the computer the FW's
domain settings will be used. There is no way to change this
behavior.

From
The Cable Guy - May 2004
Network Determination Behavior for Network-Related Group Policy Settings
http://www.microsoft.com/technet/community/columns/cableguy/cg0504.mspx

<quote>
To apply this behavior to Windows Firewall settings:

() If the connection-specific DNS suffix of a currently connected
connection on the computer that is not PPP or SLIP-based (such as
an Ethernet or 802.11 wireless network adapter) matches the value
of the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group
Policy\History\NetworkName registry entry, Windows Firewall uses
the domain profile.

() If the connection-specific DNS suffix of a currently connected
connection on the computer that is not PPP or SLIP-based does not
match the value of the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group
Policy\History\NetworkName registry entry, Windows Firewall uses
the standard profile.

You can determine the connection-specific DNS suffixes of the
currently connected connections on the computer from the display
of the ipconfig command issued from a command prompt.

</quote>

Read the Cable Guy article for more about this.

 

[Ross Smith]

Thanks for the heads up. We were just about to use Windows Firewall to
secure our new laptops, if what you say is true there is absolutely no way
we can rely on it.

Not impressed Microsoft, not impressed at all...

Ross Smith
Network Manager
Robinson Construction

 

[ryanjjones]

Before I get sued by MS - please try it and let me know what you find!
Note - only certain DHCP servers (eg Watchguard SoHo6tc) will send
"nothing" as a DNS Suffix (if left blank in config) - others (MS W2K3)
will send "blank" - so DNS suffix is "" and hence different to DNS
domain and works as expected.

However setting DNS domain to your "internal DNS domain" on another DNS
server should be sufficient testing to "panic".

Torgeir Bakken - your post to one of my threads earlier (which I could
not respond to) was most helpful - and again clarifies above. However,
it does prove there are other idiots out there (Sorry John M! ) who
think/thought exactly the same as me - and hence could be getting
themsleves into a risky sitation.

John M - do you recall reading that the firewall does talk to a DC?
I'm sure I read that but clearly it is incorrect based on Torgeirs
link...?

Anyway - anyone with a solution would be most welcome!

 

[ryanjjones]

(See main response in thread). When on the road, we have set GPO to
set firewall to "on" and no exceptions. Okay - this stops remote
management tools - but our users are only remote for a short time. We
also ban/block IM. If you want to block IM you can use an IE client
instead which works entirely over the web and locked down firewalls.
We block this using 3rd party software - but you may want to consider
it as it means client firewall can be on, no exceptions, and they can
use just IE/HTTP to access IM.

HTH

http://webmessenger.msn.com

 

[John M]

I have reread the document from the cable guy and the "Deploying Windows
Firewall Settings for Microsoft Windows XP with Service Pack 2" document
from microsoft
http://www.microsoft.com/downloads/...e1-61fa-447a-bdcd-499f73a637d1&DisplayLang=en .
Even if the DNS suffix is different, the computer can get a new policy from
a different domain controller. To me, I interperet this as "If the computer
cannot contact a domain controller and get the current policy or a new
policy, then it will be on an unmanaged network". I can see where the
concern is from DHCP servers mimicking your domain settings.

We came down to two choices:
1) Make the domain profile and standard profile excatly the same, so it
wouldn't matter where the computer was and deal with the consequences of
some stuff not working for users while away from our network. Again, when
using group policy for windows firewall, when we define port exceptions, you
can not grant access by dns names, only by IP subnets.

2) Since our DNS server is accessible to the outside world, we could
manually enter the DNS server and suffix settings for all connections. This
can also be done via group policy. Thus, the computer would always be
consider on a managed network and we just configure the domain profile.

Both give us the desired results because general concensus is that it is
better to always have the firewall on no matter where the computer is.

 

[ryanjjones]

Your options both have the same effect - having firewall on all the
time.

Now with the amount of tools we need for management tools; software
deployment; audit; and general remote IT administration - so many ports
need to be open with so many exceptions - that this the firewall will
not be able to do its job. Hence the "external" standard policy is
"enabled with no exceptions". Okay you can lock it down to subnets, but
obviously, private subnets (10.x) are hardly rare!

We would not consider the exceptions we need as being secure enough for
connection to the Internet.

I have reread the document from the cable guy and the "Deploying Windows
Firewall Settings for Microsoft Windows XP with Service Pack 2" document
from microsoft
http://www.microsoft.com/downloads/...e1-61fa-447a-bdcd-499f73a637d1&DisplayLang=en
..
Even if the DNS suffix is different, the computer can get a new policy from
a different domain controller. To me, I interperet this as "If the computer
cannot contact a domain controller and get the current policy or a new
policy, then it will be on an unmanaged network". I can see where the