Re: [Full-Disclosure] MS should point windowsupdate.com to 127.0.0.1

["Barry Irwin" <bvi@lair.moria.org>]

> Given that scenario, please apply your scintillating logic to the
> problem of patching this machine to protect it against threats that were
> discovered *after* SP2.

I'll take a stab at this.

First off its not a nice situation to be in , HOWEVER, its not an
insurmountable problem either.

Requirement: Expensive Kit needs to talk to The Internet
 - Firstly, based on the following assumptions
   - It doesn't use some really WEIRD protocol   (Weird being one that
contains address info within the protocol stream, rather than just using the
standard TCP endpoints.  Examples being FTP, RealAudio, QUAKE etc)
   - IT isn't needing some weird protocol connecting back in (see above)
  - stated requirement is it needs to run IIS possible for exposure tot he
outside world

The solution:
Stick the kit behind a NAT gateway, on a private address. The benefit being
it can connect out without problems. If it does need some slightly strange
protocol, one can get past this either by writing an appropriate translation
module, or by using an alternate connectivity type such as socks (if
supported)
For incoming connections, once can just forward incoming port 80 connections
through to the box.  Other connections such as terminal services and the
like can be treated in a similar manner.

So far, so good, other than we are now running IIS exposed to the world.
Not all bad, the fact that its running on a private address would mean that
any bindshell type exploits will bind a port on the private address, and
this would not be forwarded through by the nat gateway ( work on deny all
allow what I know I want to let through)

One can go one step further, and put an abstraction layer between the IIS
process and the Internet.  There are a couple of ways to do this from simple
HTTP gateway solutions to something a little more complex like Apace with
Mod_proxy or even Squid running in HTTP_accelerator mode.

The use of smaller bits of gateway software works well for isolating buggy
software off the net, without compromising functionality.  I used a similar
process for sorting out the problems with a certain very buggy piece of FTP
server code, where, again it was REQUIRED to be run because other software
depended on being able to parse logs etc.  The  use of a FTP gateway further
solved the whole active/passive FTP debacle when clients were connecting
from behind firewalls aswell.

Points time:

> 1) Minus points if you say "Don't use it."  Not an option
0
> 2) Minus points if you say "Don't allow access to the Internet.  It
> *requires* access to the Internet.  (IOW, it has to be able to connect
> to "live" IP address ranges, not private IPs.)
0  - It is able to connect ti the internet at large, and receive
connectivity back
> 3) Bonus points if you can figure out how to maintain this machine with
> no interruptions of service and with no breakins.
the only two things that would need to be changed woudl be the default
gateway, and ip address/netmask.
IIS may need some tweaking to use the new ip, but I've never had to use it
so cant coment.
+2
> 4) Minus points if you say, "I'd patch it anyway.  Screw the vendor."
0 - Its better to be able to blame the vendor when things break, however, it
woudl probably be in ones interests to point out to the vendor that there
are problems, and try ascertain what their upgrade plan in for validating
software on a more recent platform.

> 5) Double minus points if you say, "I wouldn't work somewhere if they
> had those requirements."
0

Total:  I think I come out okay, unless I'm missing somethign really
obvious.

 --
Barry Irwin
bvi@moria.org
http://lair.moria.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html