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
| ||
|
From: bvi at lair.moria.org (Barry Irwin) Subject: MS should point windowsupdate.com to 127.0.0.1 > 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@...ia.org http://lair.moria.org
Powered by blists - more mailing lists