Windows Updates

Ok, so undoubtedly I'm not the only one who's ever had to reload a Windows OS on a box that only has unfiltered Internet access. If the OS is Windows XP SP2, you can use the built-in firewall to make sure that your machine does not get infected before you download and apply all the windows updates. The same holds true for Windows Server 2003 SP1. But what if you're running plain Windows Server 2003, or any flavor of Windows 2000? You're vulnerable as all get-out, and you'd be stupid to place the machine on the Internet unfiltered, right? I mean.. surely you'd get infected in a matter of minutes, or maybe even seconds. While this is all true, I was faced with a situation where I had to do this, lest I be forced to drive 20 miles to home and grab a wireless AP with built-in NAT.. or drive 6 miles to Walmart and buy a new one for $40. So I decided to compromise. Here's the plan:

1) Put a static IP into the Windows box (this would not have worked under DHCP unless I could override *.settings). DO NOT assign a default gateway! Do memorize the default GW though.. you'll need it quite a bit :) Punch in the DNS server. Only one will suffice. Hit OK, etc.
2) Bring up a command prompt
3) 'route add ip.of.dns.server 255.255.255.255 ip.of.gateway'
4) 'nslookup www.windowsupdate.com'
5) 'route add network.number.of.windowsupdate.com 255.255.255.0 ip.of.gateway' This will allow you to hit www.windowsupdate.com. Once you're there, you might get automatically redirected to another site, like http://v4.windowsupdate.microsoft.com - make sure you do an nslookup on this and add it's IP into your routing table. Why are we adding /24's? Because we're going to make a big assumption that machines residing on the same /24 as WindowsUpdate.com's servers will not be trying to exploit us. I realize this is MS, and anything is possible. Around MS, never relax. Also, make sure you add all the /24 blocks you see.
6) Run through the normal procedure of selecting updates to apply to Windows. Once it comes time to click Install Updates, you need to put the default route in for a second: 'route add 0.0.0.0 0.0.0.0 ip.of.gateway' Then you IMMEDIATELY click Install Updates. DO NOT go mack your girlfriend. Issue a 'netstat -n' and look at the last IP. It should be something like 64.4.20.45:80. Quickly add this /24 into your routing table, then delete the default route with 'route delete 0.0.0.0'.

At this point, your box will keep fetching Windows Updates autonomously, and with no default route. If you managed to get infected in those 10 or so seconds that you were typing commands and viewing netstat output, then I feel really sorry for you. The aforementioned method worked great for me, as I am writing this blog entry on an uncompromised machine that was just reloaded w/ this exact method. To simplify things, i'll include the /24's that I added to my tables below, in case you want to just add them and pray it works:

64.4.20.0/24
64.21.49.0/24
207.46.134.0/24
207.46.245.0/24
207.46.249.0/24

Connection Limiting in iptables

Theoretically, you can change the connection limit of any TCP-based service dynamically (on the fly) using iptables. Simply set your service to a good hard maximum (the maximum number of users that would EVER access the service at one time). Then make an ACCEPT rule that matches --state ESTABLISHED --limit x/minute. Next, you can either make a DROP rule matching exactly the same ip/port as the first rule.. (if you dont care about users complaining that the service acts like its going to connect and then just sits there, as would be the case if the maximum is reached). Or, alternatively, you could code a special daemon for your service that sends out nothing but "server full" messages, and put a MANGLE rule underneath the ACCEPT rule, which redirects users to the "server full" daemon. The neat thing about this particular approach is that you only need one "server full" daemon per network. Simply MANGLE the leftover connections to hit the "server full" daemon, regardless of where it sits.