WSUS 3 SP2 - Remote access via ISA, security considerations?

Hi all

I'm part way through implementing the MS recommended route to allow the
remote management of WSUS clients (albeit with ISA 2006) 'Implementing WSUS
with ISA Server 2004 to Manage Remote Clients' but as I'm half way through
something has smacked me rather hard in the head!

How can I enforce some type of client authentication?

For example, anyone could point their PC (via registry) to the public facing
domain name (update.ourdomain.com) and without a form of credential passing I
would expect WSUS to automatically add their machine - but unfortunately
that's not acceptable.

I've created two WSUS servers, one for internal and one external clients (as
externals will download from update.microsoft.com) and have ISA2006 up and
running nicely with routes etc. Have tested with external domain name using
various protocols and can talk to the target internal WSUS server, but
haven't created a specific web-listener or certificates as yet.

I'm really hoping some kind person will say, ah, easy, when using SSL WSUS
will authenticate the external machine before adding it by using
certificates/somehow else?

Or, ISA 2006 can collaborate with AD and therefore only selected users can
be chosen?


Edit.....

ah ha:

I spotted this:

"Adding Authentication between Chained WSUS Servers in an Active Directory
Environment"

The problem is that this document is explicitly discussing authentication
between chained WSUS servers, but I'm focussed on Client to Server!

Any thoughts?

Your advice would be more than welcome.

Thanks
Lea

"LeaUK" <> wrote in message
news:9F97C260-56E1-4A44-83BF-...

> I'm part way through implementing the MS recommended route to allow the
> remote management of WSUS clients (albeit with ISA 2006) 'Implementing
> WSUS
> with ISA Server 2004 to Manage Remote Clients' but as I'm half way through
> something has smacked me rather hard in the head!
>
> How can I enforce some type of client authentication?
>
> For example, anyone could point their PC (via registry) to the public
> facing
> domain name (update.ourdomain.com) and without a form of credential
> passing I
> would expect WSUS to automatically add their machine - but unfortunately
> that's not acceptable.

You're absolutely right, and that issue is not addressed in that document,
or in any other article discussing the implementation details, but it is an
issue of concern -- not only because you really don't want somebody else's
client connecting to your WSUS server and confusing your display, but
because, strictly speaking -- publishing an open WSUS server on the Internet
is a violation of the WSUS EULA (which has always made me wonder why that
article exists in the first place).


> I'm really hoping some kind person will say, ah, easy, when using SSL WSUS
> will authenticate the external machine before adding it by using
> certificates/somehow else?

The most common scenario in use is that the WSUS server sits behind a VPN
connection and is only available to corporate clients when connected via
VPN.

However, using the "publish via ISA Server" philosophy, using CLIENT-side
SSL certificates is the presumed solution. This is what authenticates the
client to the server under normal circumstances, but configuring client-side
certificates is not a simple task, and those who have tried have had mixed
results. The whole nature of the WUAgent=>WSUS connection is that it is
anonymous.

Security by obscurity could help... publish the web server on a non-standard
port, and map it to the WSUS server - but that won't keep a port scanning
malware monster from finding it and trying to exploit the core webserver.
(Ostensibly ISA will help prevent this, though.)

If you know the specific source address(es) of the clients, you can modify
the ISA rule to only allow connections from known sources.


> Or, ISA 2006 can collaborate with AD and therefore only selected users can
> be chosen?

Nope. The connection is anonymous. The logged on user has nothing to do with
the connection, and WSUS is oblivious to Active Directory.

You could possibly (I'm not aware of anybody who's tried this; and it just
this moment has occurred to me) configure ISA as a reverse proxy with
authentication, and then configure the WUAgent/WinHTTP to authenticate with
the *proxy*.


> "Adding Authentication between Chained WSUS Servers in an Active Directory
> Environment"
>
> The problem is that this document is explicitly discussing authentication
> between chained WSUS servers, but I'm focussed on Client to Server!

Correct. This does not addresss the client-to-server connection.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

More thoughts...

Firstly WSUS clients use Anonymous Authentication - so cannot pass AD user
credentials, so after some further reading I suspect there maybe two
solutions?


1. Company doesn't use a Root Certificate Repository, so install the Root
Cert on external client machines.

This acts as 'proof' that the client has originated from the company
infrastructure.


OR:

2. Modify the following Step 1 and 2 (to authenticate on the IIS folder
'clientwebservice' or maybe 'simpleauthwebservice') -
http://technet.microsoft.com/en-us/l...50(WS.10).aspx

Step 1: Create an authentication list
WSUS setup creates a configuration file that enables you to add an explicit
list of computers that have access to WSUS. You can find this file in the
file system of the WSUS server at:

%ProgramFiles%\Update Services\WebServices\????\Web.config

Am I along the right lines..??

Please help...and many thanks again

Lea



"LeaUK" wrote:

> Hi all
>
> I'm part way through implementing the MS recommended route to allow the
> remote management of WSUS clients (albeit with ISA 2006) 'Implementing WSUS
> with ISA Server 2004 to Manage Remote Clients' but as I'm half way through
> something has smacked me rather hard in the head!
>
> How can I enforce some type of client authentication?
>
> For example, anyone could point their PC (via registry) to the public facing
> domain name (update.ourdomain.com) and without a form of credential passing I
> would expect WSUS to automatically add their machine - but unfortunately
> that's not acceptable.
>
> I've created two WSUS servers, one for internal and one external clients (as
> externals will download from update.microsoft.com) and have ISA2006 up and
> running nicely with routes etc. Have tested with external domain name using
> various protocols and can talk to the target internal WSUS server, but
> haven't created a specific web-listener or certificates as yet.
>
> I'm really hoping some kind person will say, ah, easy, when using SSL WSUS
> will authenticate the external machine before adding it by using
> certificates/somehow else?
>
> Or, ISA 2006 can collaborate with AD and therefore only selected users can
> be chosen?
>
>
> Edit.....
>
> ah ha:
>
> I spotted this:
>
> "Adding Authentication between Chained WSUS Servers in an Active Directory
> Environment"
>
> The problem is that this document is explicitly discussing authentication
> between chained WSUS servers, but I'm focussed on Client to Server!
>
> Any thoughts?
>
> Your advice would be more than welcome.
>
> Thanks
> Lea
>

Hi Lawrence, firstly let me thank you for your detailed reply, very kind. It
also seems that I posted at same time without noticing yours first, sorry for
this. However you'll see I have raised a few things as I've been pondering
this out load so to speak…

I would greatly appreciate your further comment on my second post, should
you be able to afford time - specifically on Client-side certificates. In a
nutshell I'm assuming I can add our corporate root cert to each client, and
if a specific one exists in our CA (just realised that we do operate one)
this in tern will then act as the 'authentication' medium and allow clients
connection?

i.e., clients with our Root Cert installed on their machines will be able to
connect to our public facing internal WSUS, those without will be refused?

Is my understanding correct?

Kind regards
Lea


"Lawrence Garvin [MVP]" wrote:

> "LeaUK" <> wrote in message
> news:9F97C260-56E1-4A44-83BF-...
>
> > I'm part way through implementing the MS recommended route to allow the
> > remote management of WSUS clients (albeit with ISA 2006) 'Implementing
> > WSUS
> > with ISA Server 2004 to Manage Remote Clients' but as I'm half way through
> > something has smacked me rather hard in the head!
> >
> > How can I enforce some type of client authentication?
> >
> > For example, anyone could point their PC (via registry) to the public
> > facing
> > domain name (update.ourdomain.com) and without a form of credential
> > passing I
> > would expect WSUS to automatically add their machine - but unfortunately
> > that's not acceptable.
>
> You're absolutely right, and that issue is not addressed in that document,
> or in any other article discussing the implementation details, but it is an
> issue of concern -- not only because you really don't want somebody else's
> client connecting to your WSUS server and confusing your display, but
> because, strictly speaking -- publishing an open WSUS server on the Internet
> is a violation of the WSUS EULA (which has always made me wonder why that
> article exists in the first place).
>
>
> > I'm really hoping some kind person will say, ah, easy, when using SSL WSUS
> > will authenticate the external machine before adding it by using
> > certificates/somehow else?
>
> The most common scenario in use is that the WSUS server sits behind a VPN
> connection and is only available to corporate clients when connected via
> VPN.
>
> However, using the "publish via ISA Server" philosophy, using CLIENT-side
> SSL certificates is the presumed solution. This is what authenticates the
> client to the server under normal circumstances, but configuring client-side
> certificates is not a simple task, and those who have tried have had mixed
> results. The whole nature of the WUAgent=>WSUS connection is that it is
> anonymous.
>
> Security by obscurity could help... publish the web server on a non-standard
> port, and map it to the WSUS server - but that won't keep a port scanning
> malware monster from finding it and trying to exploit the core webserver.
> (Ostensibly ISA will help prevent this, though.)
>
> If you know the specific source address(es) of the clients, you can modify
> the ISA rule to only allow connections from known sources.

Afraid not they will be from a selection of ISP broadband providers...


>
>
> > Or, ISA 2006 can collaborate with AD and therefore only selected users can
> > be chosen?
>
> Nope. The connection is anonymous. The logged on user has nothing to do with
> the connection, and WSUS is oblivious to Active Directory.
>
> You could possibly (I'm not aware of anybody who's tried this; and it just
> this moment has occurred to me) configure ISA as a reverse proxy with
> authentication, and then configure the WUAgent/WinHTTP to authenticate with
> the *proxy*.
>

Over my head I suspect for now - I have a 2 week dealine!!
>
> > "Adding Authentication between Chained WSUS Servers in an Active Directory
> > Environment"
> >
> > The problem is that this document is explicitly discussing authentication
> > between chained WSUS servers, but I'm focussed on Client to Server!
>
> Correct. This does not addresss the client-to-server connection.
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2010)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"LeaUK" <> wrote in message
news:84498B96-34DA-40B2-909A-...

> I would greatly appreciate your further comment on my second post, should
> you be able to afford time - specifically on Client-side certificates.

There really isn't anything else I can add. As noted in my original reply,
those very few who have considered using client-side certificates have had
mixed results.

> In a
> nutshell I'm assuming I can add our corporate root cert to each client,
> and
> if a specific one exists in our CA (just realised that we do operate one)
> this in tern will then act as the 'authentication' medium and allow
> clients
> connection?

I don't believe so. A client-side certificate for authentication would need
to be generated by/for/onBehalfOf the client, and each and every client-side
certificate would need to be installed on the WSUS server, plus you would
need to implement some methodology for authentication of the client by the
WSUS server -- and I'm not even sure that capacity exists in the WSUS
application. On a LAN based connection, IPSec is actually the better way to
achieve this, and IPSec may also be a way to achieve this with public-facing
WSUS servers -- but you'll still have the complications of configuring ISA
to support IPSec through the firewall.

I suspect the simplest approach is to identify the IP source addresses of
the client systems and configure the firewall rules so that the web
publishing of the WSUS Server is only visible to clients with known IP
addresses, or originating from network with known IP subnets.

The best approach is to use VPN to authenticate the client users, which
would then provide network access to the WSUS server, via the authenticated
VPN tunnel.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Lawrence - thanks again. I'm confused though and perhaps through my lack of
certificate understanding.

Forgetting client-side certificates (I think this is confusing me further)
why do I need to generate a certificate at all?

My presumption is that the client will have the corporate Root cert in their
cert store (if not it can be simply emailed), and WU on the client uses this
information (key) to encrypt meta data passing to WSUS? WSUS will see this
new client and add it to its management console....

If the client does not have the Root cert, then it cannot encrypt the data
and one hopes it will fail joining WSUS?

If this is true then I can use this as part of the obscurity... If not
what's the point of the CA?

I would sincerely appreciate your thoughts.



>I suspect the simplest approach is to identify the IP source addresses of
>the client systems and configure the firewall rules so that the web
>publishing of the WSUS Server is only visible to clients with known IP
>addresses, or originating from network with known IP subnets.

Unfortunately this is impossible as clients will be using a multitude of
ISPs and they are not in our control.

>The best approach is to use VPN to authenticate the client users, which
>would then provide network access to the WSUS server, via the authenticated
>VPN tunnel.

Agreed, but we do not use VPNs, we're using Citrix CAGs... they have
limited VPN connectivity but it's my last option...


Kind regards
Lea

"LeaUK" <> wrote in message
news:9D3F9069-7B80-41EE-91CD-...
> Lawrence - thanks again. I'm confused though and perhaps through my lack
> of
> certificate understanding.
>
> Forgetting client-side certificates (I think this is confusing me further)
> why do I need to generate a certificate at all?

You don't. :-)

Unless you want to use SSL to connect the clients to the WSUS Server. Then
you'd need to install an SSL certificate on the server and configure WSUS to
support SSL.


> My presumption is that the client will have the corporate Root cert in
> their
> cert store (if not it can be simply emailed), and WU on the client uses
> this
> information (key) to encrypt meta data passing to WSUS? WSUS will see
> this
> new client and add it to its management console....

The Root Certificate is only used to establish *trust* between two
independent entities. If both entities have a root certificate for a
certificate authority, then both can trust certificates issued from that
authority. One of the purposes of issuing certificates is identity; another
is encryption/decryption. This is what's used to support an HTTPS connection
to a web server. A certificate is issued to the web server, and the entity
identification an dpublic key from that certificate is shared with clients
of the web server. This is how the clients know they are communicating with
the specifice web server (because only that web server could encrypt content
such that the public key will be able to decrypt it); any content from a
different web server would not be decryptable by the client using the public
key.

For client-side certificates, the interest is in establishing identity of
the *client*. In this scenario each client needs to be issued a certificate
from the certificate authority; both the server and client need to trust
that certificate authority (based on the presence of the root certificate in
the cert store), and the server needs to possess the cert/public key of each
client in order to decrypt content from the client and verify the client's
identity.


> If the client does not have the Root cert, then it cannot encrypt the data
> and one hopes it will fail joining WSUS?

If the client does not have the root cert, then it will not *trust* any
entity possessing a certificate issued by the certificate authority
identified in the root certificate.


> If this is true then I can use this as part of the obscurity... If not
> what's the point of the CA?

The CA issues certificates.

> Unfortunately this is impossible as clients will be using a multitude of
> ISPs and they are not in our control.

While I grant roaming clients may be using many different connection points
throughout their travels, each roaming client should have a "home" location
that is authoritatively identifiable. Remember, only *approvals* need to be
obtained from the WSUS server over the secured connection; the content can
be downloaded over any Internet link anywhere. Approvals can be obatined in
a matter of a minute or so. Given that approvals are not likely issued more
than once or twice a month, it's really only necessary to allow connections
to the WSUS server from established "home" locations for those roaming
clients. The "multitudes of ISPs" that may be in use can be used to download
content, but I would *NOT* recommend allowing connectivity to your WSUS
server, under any conditions, from client connections originating from "a
multitude of ISPs".



--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Firstly my apologies for not replying sooner - have been busy configuring ISA
- bit of a trauma that was ;-)

>> If the client does not have the Root cert, then it cannot encrypt the data
>> and one hopes it will fail joining WSUS?

>If the client does not have the root cert, then it will not *trust* any
>entity possessing a certificate issued by the certificate authority
>identified in the root certificate.

So, can I confirm, that without our corporate Root certificate clients could
not connect to our WSUS?

I've achieved HTTP external WSUS connections through ISA so I'll be able to
test the SSL handling soon, but your view would be more than welcome also.


>>Unfortunately this is impossible as clients will be using a multitude of
>> ISPs and they are not in our control.

>While I grant roaming clients may be using many different connection points
>throughout their travels, each roaming client should have a "home" location
>that is authoritatively identifiable. Remember, only *approvals* need to be
>obtained from the WSUS server over the secured connection; the content can
>be downloaded over any Internet link anywhere. Approvals can be obatined in
>a matter of a minute or so. Given that approvals are not likely issued more
>than once or twice a month, it's really only necessary to allow connections
>to the WSUS server from established "home" locations for those roaming
>clients. The "multitudes of ISPs" that may be in use can be used to download
>content, but I would *NOT* recommend allowing connectivity to your WSUS
>server, under any conditions, from client connections originating from "a
>multitude of ISPs".

The problem I face is that many of our external roaming machines do not
return to a 'home' location (the office for example) for many months and
therefore this time period between updates would not be acceptable

I would appreciate you expanding on why you would NOT recommend allowing
connections originating from any IP? I can only assume it's due to the lack
of strong authentication? But as mentioned earlier, a process of obscurity
is perhaps my only option with WSUS. Something like:

1. Clients need to obtain our GPO for WSUS to point to our external IP

arguably these reg entries could be made on any machine..

2. Use a different SSL port

3. We have 2 firewalls using HTTP filters, an Edge FW and ISA backend

4. The client must have a corporate Root Cert

5. Due to split DNS roaming (external) clients will connect to a separate
WSUS server to those on the LAN as this server is configured to force clients
to download from Microsoft rather than internally - because there are 1500
external clients and I want them to avoid saturating the corporate broadband
link.

Is there anything else we can do to increase security?


Many many thanks again
Lea

"LeaUK" <> wrote in message
news:C878744C-6F4D-40BE-822D-...

> So, can I confirm, that without our corporate Root certificate clients
> could
> not connect to our WSUS?

Unless you intentionally and specifically configured WSUS to use =SSL your
corporate Root Certificate doesn't make a squat bit of difference to WSUS or
the Windows Update Agent.

If you are using SSL, then you simply need to follow the very specific and
accurate instructions for implementing SSL with WSUS that are contained in
the WSUS Deployment Guide.


>>>Unfortunately this is impossible as clients will be using a multitude of
>>> ISPs and they are not in our control.
>
>>While I grant roaming clients may be using many different connection
>>points
>>throughout their travels, each roaming client should have a "home"
>>location
>>that is authoritatively identifiable. Remember, only *approvals* need to
>>be
>>obtained from the WSUS server over the secured connection; the content can
>>be downloaded over any Internet link anywhere. Approvals can be obatined
>>in
>>a matter of a minute or so. Given that approvals are not likely issued
>>more
>>than once or twice a month, it's really only necessary to allow
>>connections
>>to the WSUS server from established "home" locations for those roaming
>>clients. The "multitudes of ISPs" that may be in use can be used to
>>download
>>content, but I would *NOT* recommend allowing connectivity to your WSUS
>>server, under any conditions, from client connections originating from "a
>>multitude of ISPs".
>
> The problem I face is that many of our external roaming machines do not
> return to a 'home' location (the office for example) for many months and
> therefore this time period between updates would not be acceptable

Every machine has a "home" location, because every user has to *SLEEP*
somewhere.

Unless you truly have users who are on-the-road for hundreds of days at at
time, those machines have a "home" location.

And, if they don't, and if they truly are 'away' for hundreds of days at at
time, then =WSUS= is not the proper solution for that scenario and those
notebooks should be configured to use Automatic Updates with scheduled
installations, and installation on power-on if the scheduled installation is
missed.


> I would appreciate you expanding on why you would NOT recommend allowing
> connections originating from any IP?


The inherent insecurity would be the primary reason.

> I can only assume it's due to the lack of strong authentication?

In your scenario, this is also a primary issue. Most organizations would use
a VPN from a public connection, thus providing an authenticated and
encrypted connection. When you sacrifice both authentication and encryption,
that means *anybody* can make that connection.

> But as mentioned earlier, a process of obscurity is perhaps my only option
> with WSUS.

Obscurity as the only option is simply insufficient. You need to find
additional methods, or you need to abandon the project and use Automatic
Updates.

Think of obscurity as closing the drapes on your bedroom window. If you
still leave your front door unlocked, there's not much point is there? It
keeps the *honest* people from walking into your house, and maybe it reduces
the enticement to those who might be unduly influenced by the presence of
the open drapes (and the $1000 pearl necklace sitting on the dresser in
plain sight), but for the hard-core burglars.. the drapes are useless,
they're going to pick the lock anyway just to see what *might* be there.

> 1. Clients need to obtain our GPO for WSUS to point to our external IP
>
> arguably these reg entries could be made on any machine..

Yes. (and, in fact, GPO is not an option for use with roaming machines
outside the firewall). These machines will need to be manually configured,
either via Local Policy or Registry scripts, and, unless those users are not
local admins, they'll also have the ability to change/undo/muckWith those
settings, which could cause all sorts of havoc if such machines go hundreds
of days without being updated.


> 2. Use a different SSL port

You should do this on principle. An Internet facing WSUS server should never
be published on 80/443. At a minimum on the alternate ports of 8530/8531,
but ideally on a NON_published port pair.


> 3. We have 2 firewalls using HTTP filters, an Edge FW and ISA backend

This is good. :-)


> 4. The client must have a corporate Root Cert

No... it doesn't. The client only needs a SELF_SIGNED certificate from the
WSUS server.

And, in fact, I'm not entirely sure you can use Enterprise Certificates with
machines that are not actively connected to the domain.


> 5. Due to split DNS roaming (external) clients will connect to a separate
> WSUS server to those on the LAN as this server is configured to force
> clients
> to download from Microsoft rather than internally - because there are 1500
> external clients and I want them to avoid saturating the corporate
> broadband
> link.

This is good.


> Is there anything else we can do to increase security?

[a] Use a VPN (which you've already stated is not possible).

[b] Require IPSec to connect the client to the server.

[c] Don't use WSUS, use Automatic Updates for clients that cannot connect at
least once a month.



--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

On 2010-03-11 11:30 p.m., LeaUK wrote:

>> If the client does not have the root cert, then it will not *trust* any
>> entity possessing a certificate issued by the certificate authority
>> identified in the root certificate.
>
> So, can I confirm, that without our corporate Root certificate clients could
> not connect to our WSUS?

Installing the corporate root certificate would be the easiest way to make a
client able to use the WSUS server, if only SSL connections are available.

It probably wouldn't be the only way, and it definitely wouldn't prevent someone
from connecting to your WSUS server using a web browser or a custom tool rather
than the Windows Update Agent.

Depending on the configuration of your WSUS and other servers, it may be
possible for third parties to get a copy of the corporate root certificate.
Note that such a certificate is not normally considered to be secret, so there
is no reason to expect servers to try to hide it.

Harry.


>
> I've achieved HTTP external WSUS connections through ISA so I'll be able to
> test the SSL handling soon, but your view would be more than welcome also.
>
>
>>> Unfortunately this is impossible as clients will be using a multitude of
>>> ISPs and they are not in our control.
>
>> While I grant roaming clients may be using many different connection points
>> throughout their travels, each roaming client should have a "home" location
>> that is authoritatively identifiable. Remember, only *approvals* need to be
>> obtained from the WSUS server over the secured connection; the content can
>> be downloaded over any Internet link anywhere. Approvals can be obatined in
>> a matter of a minute or so. Given that approvals are not likely issued more
>> than once or twice a month, it's really only necessary to allow connections
>> to the WSUS server from established "home" locations for those roaming
>> clients. The "multitudes of ISPs" that may be in use can be used to download
>> content, but I would *NOT* recommend allowing connectivity to your WSUS
>> server, under any conditions, from client connections originating from "a
>> multitude of ISPs".
>
> The problem I face is that many of our external roaming machines do not
> return to a 'home' location (the office for example) for many months and
> therefore this time period between updates would not be acceptable
>
> I would appreciate you expanding on why you would NOT recommend allowing
> connections originating from any IP? I can only assume it's due to the lack
> of strong authentication? But as mentioned earlier, a process of obscurity
> is perhaps my only option with WSUS. Something like:
>
> 1. Clients need to obtain our GPO for WSUS to point to our external IP
>
> arguably these reg entries could be made on any machine..
>
> 2. Use a different SSL port
>
> 3. We have 2 firewalls using HTTP filters, an Edge FW and ISA backend
>
> 4. The client must have a corporate Root Cert
>
> 5. Due to split DNS roaming (external) clients will connect to a separate
> WSUS server to those on the LAN as this server is configured to force clients
> to download from Microsoft rather than internally - because there are 1500
> external clients and I want them to avoid saturating the corporate broadband
> link.
>
> Is there anything else we can do to increase security?
>
>
> Many many thanks again
> Lea
>
>


--
Harry Johnston
http://harryjohnston.wordpress.com