Why is Win Explorer accessing the Net?

[Walter Roberson]

:On 23 Dec 2003 16:02:22 GMT, Walter Roberson spoketh


:>Now, not having control over the corporate Exchange servers, how
:>can I configure the client to stop the server from remembering the
:>ip + port (both of which could have been dynamically allocated) --
:>or how can I *reasonably* configure a stateful firewall to
:>recognize this situation and make the appropriate back-connection
:>even if the public IP has been long ago reallocated?

:Simple: A client should never connect to Exchange through a firewall. If
:external users needs to connect to Exchange, use VPN.

My firewalls are also VPN devices, and do exactly the same kind of
adaptive security on connections over IPSec tunnels as is done
for non-tunneled connections. Also, using a VPN would not solve
the issue that the public IP address might have changed.

If I understand correctly, you are suggesting that the way to
"secure" this MS product is to construct a LAN to LAN VPN that
presents internal IP addresses to both sides, and which deliberately
has adaptive security disabled for the tunnel, allowing -all-
connections through the tunnel ? Doesn't sound very secure to me.
(No, I don't particularily trust the corporate Exchange servers.)

Or are you suggesting that rather than a LAN to LAN VPN, that I should
be installing VPN client software on each of the user machines and have
that connect through to the server? This possibility would not
offer any relief to the issue that the Exchange (pre-AD) server wants
to be able to connect back to the client at arbitrary times
several days later -- not, that is, unless the clients are to be
expected to maintain permanent host->server VPN connections just
in case the Exchange server wants to chat.

 

[Lars M. Hansen]

On 23 Dec 2003 17:08:53 GMT, Walter Roberson spoketh

:On 23 Dec 2003 16:02:22 GMT, Walter Roberson spoketh


:>Now, not having control over the corporate Exchange servers, how
:>can I configure the client to stop the server from remembering the
:>ip + port (both of which could have been dynamically allocated) --
:>or how can I *reasonably* configure a stateful firewall to
:>recognize this situation and make the appropriate back-connection
:>even if the public IP has been long ago reallocated?

:Simple: A client should never connect to Exchange through a firewall. If
:external users needs to connect to Exchange, use VPN.

My firewalls are also VPN devices, and do exactly the same kind of
adaptive security on connections over IPSec tunnels as is done
for non-tunneled connections. Also, using a VPN would not solve
the issue that the public IP address might have changed.

If I understand correctly, you are suggesting that the way to
"secure" this MS product is to construct a LAN to LAN VPN that
presents internal IP addresses to both sides, and which deliberately
has adaptive security disabled for the tunnel, allowing -all-
connections through the tunnel ? Doesn't sound very secure to me.
(No, I don't particularily trust the corporate Exchange servers.)

Or are you suggesting that rather than a LAN to LAN VPN, that I should
be installing VPN client software on each of the user machines and have
that connect through to the server? This possibility would not
offer any relief to the issue that the Exchange (pre-AD) server wants
to be able to connect back to the client at arbitrary times
several days later -- not, that is, unless the clients are to be
expected to maintain permanent host->server VPN connections just
in case the Exchange server wants to chat.

No, I'm suggesting that the way to protect your LAN is to use VPN for
external clients to connect to internal network resources. It has very
little to do with Microsoft or anyone elses product.

Just because you have a LAN to LAN VPN, that doesn't mean it has to be
allowing all traffic both ways, but that ofcourse depends on your VPN
solution. Some products allows you to define what type of traffic are
allowed, and some does not. It should also be possible to limit which IP
addresses can be accessed through the VPN, so that clients connecting in
will only have access to whichever servers they need access to and not
to the entire network, but again, that depends on your VPN solution...

As a network admin, I'm more likely to trust the corporate Exchange
server than I am to trust computers connecting in via VPN. At least, I
know what is running on the Exchange server, but I don't know what is
running on the client computer...

With a LAN to LAN VPN, I would expect there to be a permanent
connection, so that when you launch Outlook, it will have immediate
access to the Exchange server (limited by available bandwidth only) and
any other servers you need for the connection (WINS and authentication
servers). This way, when you close Outlook, it can tell Exchange
"goodbye", and Exchange won't be attempting to connect to the client
until you log back in ...

Lars M. Hansen
www.hansenonline.net
Remove "bad" from my e-mail address to contact me.

 

[Leythos]

:MS makes great software for the business and home, it's simple to
:install, easy to use, and on the average, has more features that any GNU
r Open Source product available.

:If you don't know how to secure something it only takes about an hours
:time to research it to figure it out.

Unless it's peered MS Exchange (pre-AD) servers. The MS
documentation gives a very short list of ports that has little
relationship to reality. I analyzed the firewall logs to see
what ports were actually being used -- it was over 20 different
protocols. And it continues to surprise me; I noticed in my
logs this morning that the traffic flow has changed again since
the last time I analyzed about 3 weeks ago.

Here's an issue that I've run into that perhaps you could clue
me in on:

Client contacts Exchange Server (pre-AD). Client negotiates
a port via RPC (TCP 135). Client holds short TCP conversation and
drops the connection. Later (a few hours, up to a couple of weeks),
Exchange server wishes to send information to client. Exchange
server attempts to contact client at -same- IP address and port
that client used last time they connected many days before.
Firewall does not let server through because the original port
the client used was dynamically allocated and the TCP connection
had been closed long ago. Exchange server retries and retries
and retries, persisting in attempting to contact the dynamic
TCP port for over a week.

Now, not having control over the corporate Exchange servers, how
can I configure the client to stop the server from remembering the
ip + port (both of which could have been dynamically allocated) --
or how can I *reasonably* configure a stateful firewall to
recognize this situation and make the appropriate back-connection
even if the public IP has been long ago reallocated?

It sounds like you are setup wrong, in that you don't do RPC over the
internet or through the firewall. You appear to be external to the
firewall and should be using a VPN tunnel to connect to the exchange
LAN.

Also, if you are in the FW LAN and the Exchange is in the FW DMZ you
don't have to allow RPC between them - I've setup a oneway LAN ANY > DMZ
and use Exchange just fine - you have to enter the password each time
you open outlook, and the check-for-messages has to be configured, but
you don't have to let the exchange server hit the LAN.

You can also setup RCP between the LAN and the DMZ and between the E2K
box in the DMZ and the LAN and it works also (I don't like this method).

 

[Leythos]

My firewalls are also VPN devices, and do exactly the same kind of
adaptive security on connections over IPSec tunnels as is done
for non-tunneled connections. Also, using a VPN would not solve
the issue that the public IP address might have changed.

Actually you are wrong:

The E2K Server sitting behind a firewall, should be on a fixed IP, or no
one will find it.

The clients can use VPN routers / other with Dynamic IP's.

The VPN's are setup with Aggressive mode user/password with shared key
and work easily with Dynamic IP addresses on the client side.

Done this many times.

 

[Hairy One Kenobi]

Actually you are wrong:

The E2K Server sitting behind a firewall, should be on a fixed IP, or no
one will find it.

Hesitates, tucks fingers in belt, treads anyway.. no "need" for a static
behind the firewall - if it's NAT (as most probably are) then it's
irrelevant; if it's direct, then you might be better considering a lookup on
one of a set of owned IPs (just in case someone takes a distributed offence
to your specific address)

General comment holds, of course.

The clients can use VPN routers / other with Dynamic IP's.

The VPN's are setup with Aggressive mode user/password with shared key
and work easily with Dynamic IP addresses on the client side.

Done this many times.

<imagine - if you will - a chunk from one of the replies by Pete>

...and similar Festive Clichés to all concerned!

H1K

 

[chris]

On Tue, 16 Dec 2003 08:39:45 GMT, Vance Roos spoketh

I run Win XP Pro and I recently got a message from my Sygate Pro 5.0
firewall which said:

==== START QUOTE ====
"Windows Explorer is trying to broadcast an ICMP Type 10 (Router
Solicitation) packet to [224.0.0.2]. Do you want to allow this
program access to the network?"
==== END QUOTE ====

Simply disable the IRDP in the registry. The value name is
"HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\[InterfaceName]\PerformRouterDiscovery".
Set the value to 0 (zero), and it'll stop.

Isn't it a bit odd that Explorer is the process reported doing the
discovery? Doesn't this discovery occur when tcpip or the ppp comes
up which may happen before explorer is running?


Of course, it won't be long before the adware/spyware programs learn
how to use the built-in system calls instead of directly trying to go
the network. As an example, the services.exe can handle most of the
system calls a spyware program would make and the software firewall
would just see the generic services.exe .

-Chris

 

[David]

You don't mention the version of Exchange server, but I would use
Exchange Web access. It's not very cost effective to set up a vpn unless
the users need other lan access also. You can use SSL to encrypt and
also client certificates to make authentication tighter.

Avoid using anything over the internet that requires access to the
portmapper unless it is over a vpn or other secure link. There are still
unresolved issues with it and probably always will be.

 

[Lassi =?iso-8859-1?Q?Hippel=E4inen?=]

Isn't it a bit odd that Explorer is the process reported doing the
discovery? Doesn't this discovery occur when tcpip or the ppp comes
up which may happen before explorer is running?

It is Microsoft policy that Explorer cannot be separated from the
operating system. They claimed that in court, so they must live by it...

Of course, it won't be long before the adware/spyware programs learn
how to use the built-in system calls instead of directly trying to go
the network. As an example, the services.exe can handle most of the
system calls a spyware program would make and the software firewall
would just see the generic services.exe .

Something like the "Windows shatter attack"?

-- Lassi

 

[Lars M. Hansen]

Isn't it a bit odd that Explorer is the process reported doing the
discovery? Doesn't this discovery occur when tcpip or the ppp comes
up which may happen before explorer is running?

It is Microsoft policy that Explorer cannot be separated from the
operating system. They claimed that in court, so they must live by it...
[/QUOTE]

You are confusing "Explorer" with "Internet Explorer". Explorer _is_ the
OS, thus it is making the router discovery requests.



Lars M. Hansen
www.hansenonline.net
Remove "bad" from my e-mail address to contact me.

 

[chris]

It is Microsoft policy that Explorer cannot be separated from the
operating system. They claimed that in court, so they must live by it...

You are confusing "Explorer" with "Internet Explorer". Explorer _is_ the
OS, thus it is making the router discovery requests.[/QUOTE]

Explorer is not the OS. It is just a shell/user interface. For
example, you can run cmd.exe as your shell just fine. You can even
kill explorer using task manager and all the other programs continue
just fine.

Explorer talks to the network by making calls to the underlying
network subsystem, but it should not be doing the actual router
discovery. My guess is that the software firewall is trying to
identify what program was talking to the network when the router
discovery occured.


-Chris

 

[Black Baptist]

Lassi Hippeläinen rambled on in microsoft.public.windowsxp.general:

I run Win XP Pro and I recently got a message from my Sygate Pro 5.0
firewall which said:

==== START QUOTE ====
"Windows Explorer is trying to broadcast an ICMP Type 10 (Router
Solicitation) packet to [224.0.0.2]. Do you want to allow this
program access to the network?"
==== END QUOTE ====

When I look it up it seems that 224.0.0.2 is for something called
"Local Network Control Block" (See
http://www.faqs.org/rfcs/rfc3171.html)

My QUESTION to the newsgroup is should I allow Windows Explorer access
to the Net in order for it to go to that IP address?

That seems to be an attempt to discover a router in your LAN. Since your
internal LAN traffic has no business in the Internet, I'd order the FW
to silently discard those packets, no matter what application is sending
them.

-- Lassi

If he did that then running a url from the start menu won't work.

 

[Alan P]

Lars Hansen states how Windows is better,,,

Yet his own website is hosted on Linux?

http://uptime.netcraft.com/up/graph/?host=hansenonline.net

Apache/2.0.40 (Red Hat Linux)

 

[Lars M. Hansen]

On Sun, 11 Jan 2004 21:33:59 +0000 (UTC), "Alan P"

Lars Hansen states how Windows is better,,,

Yet his own website is hosted on Linux?

http://uptime.netcraft.com/up/graph/?host=hansenonline.net

Apache/2.0.40 (Red Hat Linux)

If you'd care to read some of the stuff I've posted in the past two
years, I think you'll find that I'm firmly in both camps. The fact that
I replaced my IIS 4.0 box with an Apache box a year ago is irrelevant in
this regard.


Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)

 

[Alan P]

Sorry :-(

Apology offered

On Sun, 11 Jan 2004 21:33:59 +0000 (UTC), "Alan P"


If you'd care to read some of the stuff I've posted in the past two
years, I think you'll find that I'm firmly in both camps. The fact that
I replaced my IIS 4.0 box with an Apache box a year ago is irrelevant in
this regard.


Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)

 

[Alan P]

//> Explorer is not the OS. It is just a shell/user interface. For

example, you can run cmd.exe as your shell just fine. You can even
kill explorer using task manager and all the other programs continue
just fine.

Then network neighbourhood wouldn't work :-|

 

[Lars M. Hansen]

On Mon, 12 Jan 2004 14:54:55 +0000 (UTC), "Alan P"

Sorry :-(

Apology offered

Accepted.

Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)

 

[NeoSadist]

//> Explorer is not the OS. It is just a shell/user interface. For

No, depends on the windows version. Explorer is often the desktop manager,
which means if you reset it, it will act like it just rebooted (but it
won't reboot).

Then network neighbourhood wouldn't work :-|

No, the former poster is telling the truth. Internet explorer and explorer
are both basically the same thing, and with win98 and above they're so
firmly entrenched that you cannot remove them. They're not the OS, but
with as integrated as they are into windows, they might as well be.
Forcefully delete explorer.exe from where it is and the SFC cache, and
watch your OS disappear.

Sure, but that's retarded. If you wanna run programs from the shell, get
Linux. There have been major case studies that point to the fact that 1)
windows is becoming too integrated because microsoft's trying to shut other
apps out of their OS, and 2) that this integration only further amplifies
all security and stability problems windows has. I'm not a
"microsoft-hater", but it's the truth, and I have seen and demonstrated
these things before.

 

[Alex Nichol]

Lars Hansen states how Windows is better,,,

Yet his own website is hosted on Linux?

http://uptime.netcraft.com/up/graph/?host=hansenonline.net

Apache/2.0.40 (Red Hat Linux)

Linux makes a lot of sense as a host for a straight web server. That
has nothing to do with relative merits of Linux and Windows as a desktop
'client' system