full-disclosure - MS should point windowsupdate.com to 127.0.0.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: steve.wray at paradise.net.nz (Steve Wray)
Subject: MS should point windowsupdate.com to 127.0.0.1

> Schmehl, Paul L wrote:
> 
> > I just curious how you geniuses would solve this problem.  
> You have a
[great big snip]
> 
> What *kind* of Internet access?  Any reason I can't put a 
> firewall or proxy 
> of some sort between it and the Internet?  Maybe an IDS 
> running as a router?

Presumably it has to accept incoming web connections from the
internet.

Firewalls are ok if the services which must penetrate
the firewall are adequately secured.

In the outlined scenario this isn't the case, it looks as
if the web server must be vulnerable and accept incoming
connections.

IDS is an intrusion *detection* system; if you detect an
intrusion its too late in this scenario.

Reverse proxy might help I guess, if it were configured to
scrub incoming web connections. Thing is, you can't just
lock out the known hacks and filter out the URLs that match
them; what about the ones you don't know about yet? 

You'd have to be able to identify the specific URL
patterns that this hugely expensive widget needs to service
and only allow them thru the reverse proxy. I guess.

Or maybe run the web server on VMWare, having multiple identical
instances ready to run when one gets infected.
Delete it, switch to the next one and make another copy of the 
master image to replace the new one when it gets infected.
Or something like that :)