Static Windows: is this insane, or what?

Is it possible to have a reasonably secure Windows installation without using Windows update?

Yes, I really mean it. In my experience MS's update stream tends to be beta-quality at best, and lots of regressions happen during updates. Perhaps it wouldn't be so bad if I also updated my drivers all the time... But I don't, because unlike Linux Windows does not nicely handle all the updating for you automatically when you type in a few commands. Which is why I'm wondering, if maybe instead of a Linux style constantly-updated Windows install, it's possible to have an OpenBSD style "install and forget" setup that's still secure enough for day-to-day use.

What I'm thinking:

- Disable unnecessary services to reduce the security risks involved
- Enable DEP for everything
- Use SRP, a HIPS, and/or sandboxing to restrict IE and anything using MSHTML (or install IE8, though I'm not sure if that completely replaces the earlier MSHTML engine or what).
- Likewise, disable everything risky in IE (set security to max for all zones).
- Follow the usual security procedures with HIPS or sandboxing

But I still wonder if that would be enough. Thoughts?

 

theoretically it might work but practically life is too short for such an exercise that offers hardly any or no return on effort spent

 

Personally I don't auto update... ever. As a matter of fact, I usually wait quite some time before applying service packs. I don't even like XP SP3. I do check things out and apply ones that seem to adjust issues I see as relevant to me.

But there have been many many times that I install XP SP2 from my unattended dvd, and don't bother to update. I have had no issues. But then, I am doing things likely very different from those that might need to remain updated, and I am re-installing/re-imaging quite often.

Sul.

 

It would be for me.. is it for you? I am afraid only you can answer that question. If you have imaging etc for backup, it is always fun to try things out. Live on the edge for awhile and find it is actually more stable than everyone says. But veer too far, and you will certainly have an accident.

Solution -- don't veer too far without some good safety gear. Then be a dare-devil and enjoy it while it lasts.

Sul.

 

My thoughts? "Reasonably secure" only depends on one's own definition of "reasonable". By my personal standards, no, it wouldn't be reasonably secure to go without installing security patches to known vulnerabilities in the most targeted software platform in human history.

I also have rather different experiences regarding the quality of MS's patches. On my own rather varied systems (varied both in terms of hardware configuration and software installed on the systems), I think I've had precisely one problem worth noticing with an update in about ten years - and that could be corrected by doing something I should've done already anyway. If Microsoft's patches feel like "beta quality at best" and often cause issues on your system, then I submit there's something "wrong" with your system, such as perhaps poorly coded third party software, hardware issues, extremely unusual hardware or software configuration or just plain catastrophically bad luck. And I don't update my drivers all the time, either - just when I have a really good reason (large performance benefit that matters to me, or security fixes).

Now, you could try to slap all kinds of security software and workarounds on the vulnerabilities to make them less of an issue, but personally, I would consider that far, far too much work for absolutely no gain, seeing how the updates don't do any harm about 99,999% of the time.

As far as automatic updates are concerned, you don't have to do those. If you wish, you could visit MS Update manually once a month or so, perhaps a week after patch Tuesday when you've had time to read what other folks are complaining about regarding the latest patches.

 

I remember when blaster was floating around. I did not update soon enough, and seen it attempt to hit me. I updated pretty soon after that lol. But it was mitigated in my system, but most were not so lucky. If I remember correctly, those using pirated OS could not update or something, so they got it usually.

I have had many issues with M$ updates, as have many I know. Normally it causes a certain issue or a certian software to not work properly.

Even SP2 required a reg tweak in the beginning to navigate other shares. I cannot recall now what it was exactly, only that I still have the .reg file for when I encounter it.

I personally trust my system without updates, but as you say, it is easier to update rather than lock it down so tight. I don't enjoy that any more. So I just look at the updates and see what they address. Critical ones are usually installed, but there are many many 'normal' ones that I don't install because they don't apply to me.

Sul.

 

No it's not insane. You just need to understand what you're doing. The solution you propose is definitely beyond the skill of 99.9963% of users. But if you can whitelist your box, then sure, you're good.
Mrk

 

Thanks for the responses guys. I figure I'll set up a no-updates partition and see how it fairs... I will take measures to make sure it doesn't infect anyone else if something does go wrong, though, and I can always fall back to Linux if I need to.

Re life being too short - my day job involves setting up and repairing computers for various companies, with operating systems ranging from Windows XP to Opensolaris. So the more I know about this stuff, the better.

 

I'm still on XP SP2 with no-updates

I rely on common sense and disabled services etc, no Active X, NoScript, and good AV etc for detection. No problems or infections here, and i purposely surf to malware sites, and download nasties from them. Often i'll get prompted if there's malware they recognise, then i don't DL them, only new stuff to send to vendors. I do NOT run the nasties

Not recommending everyone does that, but it does show how safe you can be without updates.

 

There's nothing insane about it. None of my PCs auto-update. My primary system hasn't changed in years. Even the registry is exactly the same as it was last week, last month, and last year. Short of using a LiveCD, a static system protected by a default-deny policy is about as secure as you can get.

 

Now that I think about it there are a few ways to do this.

The first one I thought of was the LUA + SRP method. This one seems pretty strong; the biggest weak point I can see would be a remote exploit through the firewall, and that could be avoided by using a third-party FW like PCTools or somesuch. Not the most convenient setup, but quite secure.

Another possibility would be to use a HIPS/Firewall like PCTools our Outpost. Tell it to consider everything on a known clean system safe, and add rules for apps you want... Then tell it to kill non-whitelisted apps without asking for confirmation. If it doesn't have a rule, it gets killed. That would be pretty safe and a bit more convenient.

(Interestingly Returnil 2008 would be better than 2010 for the latter purpose, since its anti-exec plugin is customizable. It might actually be more secure in some ways than 2010 when set up right.)

Finally, I'm thinking it might be possible to make GeSWall isolate everything except a specific list of apps, instead of just internet-facing stuff. That wouldn't be as secure (malware could still run though it couldn't spy on you effectively), but it would me much more convenient (games and whatnot could also run without whitelisting).

I'm leaning towards the second option, though I have some other ideas that I'll post elsewhere...

 

I don't know about the new versions of Outpost, but on older versions I modified my preset.lst to have all my apps clearly defined with rules pre-configured.

Later, I started getting tired of all the firewall prompts, and I simply deleted the preset.lst file contents and made 2 rules -- allow it or deny it. This way, when a new program came up, it was simple choise. In outpost you could set it to DenyMost and it would only let what was allowed get access, everything else was denied.

Sul.

 

The weakness in this type of configuration would be the malicious usage of legitimate system executables. Several system executables don't need to be able to run during normal usage, the registry editor and all system configuration apps to name a few. I used SSM, aka classic HIPS to whitelist user apps and the system executables necessary for normal operation and to control what other executables each one is allowed to start and be started by. Internet access is treated the same way. The OS executables don't have internet access. User apps have only as much outbound access as they need to function normally. All internet apps are forced to connect out through Proxomitron, which filters undesired web content. I've used this for about 5 years now on several operating systems from 98 through XP. Several people use these PCs. Most know nothing about securing a PC. They stay clean and run the same, day after day.

 

Mmm true. Perhaps the other capabilities of the HIPS/firewall would help with that though?

 

You could also look at system level virtualization to enforce the state of Windows and close the hole of malware persistence if said malware is able to circumvent your strategy. It would also give you the ability to roll back a misconfiguration as you work through the process of realizing the end goal.

Mike

 

I don't know which other HIPS or HIPS/firewall combinations have this ability or what they're calling it. SSM labelled it as parent-child dependencies. When set up well, that ability alone will defeat most attacks that maliciously use legitimate system processes. Just permitting, blocking, or restricting an executable to administrative use isn't sufficient. The PDF reader, the registry editor, and cmd.exe are all legitimate apps, but you don't want a PDF to be able to modify your registry or obtain command line access. If you approach this from a default-deny aspect and only give each executable access to just what it needs to function normally, you're effectively creating a policy sandbox that isolates the attack surface from everything else. Vulnerabilites will always be found in user apps along with exploits for them. You can't patch your way to security. If that was possible Internet Explorer would be the safest app in existence. Begin with accepting the fact that your attack surface apps are vulnerable and that they will on occasion be successfully exploited. Your security policy then becomes isolating these from your core system, preventing a compromised app from becoming a compromised system. HIPS is one way. Sandboxing and virtualization are also options. So is a combination of these. The method used is not that important, as long as you do it.

Static Windows is very possible and can be among the best protected systems out there. There's more than one way to achieve it, which proves a point I've tried to make for a long time. Security apps don't protect you. Your security policy does. Your apps and system configuration enforce that policy and should be selected on their ability to support that policy. Trying to secure a system without a policy as a guide results in a piecemeal approach that's strong in some places and weak or missing in others.

Regard freestanding HIPS and HIPS/firewall suites, I prefer to keep these separate for many reasons. The primary reason is the attack surface. The internet firewall is the front edge of your attack surface. I consider HIPS to be part of the core system. With a combined suite, the HIPS can be targeted via the firewall since they're one and the same. With a separate HIPS that has no internet access, it is not part of the attack surface and can't be directly attacked. IMO, this is no different than having the browser integrated with the OS. We all know what integrating a browser and an OS can result in, example: IE6 and windows.

 

I must confess that I haven´t patched my machine for the last 2 years, my system is running so stable that I´m afraid patches will screw things up. Of course I am taking a risk with this approach, but I´m confident enough that my HIPS will stop most (if not all) drive by attacks.

I´m also using SSM in this way, basically you whitelist certain apps, give them certain permissions, or block them from doing stuff. Especially the "parent-child process control" feature found in most classical HIPS seems to be one of most simple but also most powerful functions to stop drive by attacks. Although I have to admit that strangely enough, no one has ever done some real extensive testing.

 

Hmm... Don't know what went wrong, but it seems (judging from Rootkit Revealer results, hidden files and stuff) like I picked up a nasty. I was using Privatefirewall FWIW with everything turned up to maximum - not sure why it didn't say anything. Maybe the infection occured during the brief period before I installed it? Nah, that doesn't make sense, it would have reported the numerous threads that were listening for packets on various ports...

At any rate, I don't know how it happened, but I am beginning to suspect that the other Windows box on my home network is infected. Previous scans on it with gmer showed nothing, same with MBAM, but I think I'll nonetheless try out Rootkit Revealer on it, seeing as that caught whatever it was on the netbook. Then it's back to the drawing board.

(And thank the gods for Macrium Reflect. )

 

This is very difficult to test or to call any such testing "extensive". There's a lot of variables and testing criteria that have to be defined for the testing to have any meaning, not the least of which is the security policy the classic HIPS is enforcing. I was beta testing SSM starting at version 1.94 and continued testing until development stopped. During that time, I visited every malicious page I could find, located and tested its ability to defend against a substantial number of new exploits that targeted both Windows and specific applications. I've collected and used about 80MB of malicious code during this test period. The primary focus of this testing was on its ability to enforce a default-deny security policy and on its ability to effectively isolate attack surface applications. I tested its ability to act as a parental/user control device to a limited extent and its ability to create and maintain separate user and administrator modes on operating systems that weren't designed to do so to the limits of my abilities. My testing was not comprehensive by any means. Comprehensive testing would require much more time than I have along with more equipment, more operating systems, and more knowledge/skill than I possess. This limited testing has led me to one conclusion, which I've already mentioned. An app like SSM is only as good as the policy it's enforcing and the users ability to configure it. There isn't all that much to be tested with the HIPS software itself. The different components are either going to work or they're not. It's ability to intercept dll injection, new drivers, its ability to detect changes in an applications integrity are all fairly simple to test. With "real world" testing of its ability to prevent unwanted changes to your system, it's the user that's actually being tested.

 

Well, I'm not sure if it´s so difficult to test, if I´m correct there are certain professional testing tools available, like Immunity CANVAS Professional for example. With such a tool you could easily test a HIPS like SSM against lots of exploits, it´s a pity that no one has ever done this.

http://www.immunitysec.com/products-documentation.shtml

 

@Rasheed187

Just had a look at CANVAS, didn't know about it so

Have you seen ALL the hoops you have to go through just to install everything
View attachment README.txt

If i've got a spare week i might

 

I'm sure the developers also had access to all kinds of testing tools. A rootkit detection tool can show just how much is hooked by SSM. Very little happens on a system that doesn't go through an app like SSM at some point. Yes, it may be possible via some buffer overflow or application vulnerability to gain access to some component or memory area, but until it enables an attacker to execute some type of malicious payload, it's worthless. Most "tests" start with the premise "what if something executes and does.....". With default-deny, that doesn't happen unless that "something" is known to the system and the activity it intends to perform is already allowed. In a true default-deny system, those tests will never run and neither will any malware that uses those methods. If a process is allowed to do something malicious, it's the rules and probably the security policy they're enforcing that's flawed. That's the difficulty with testing, not just classic HIPS but any security app. Configuration is everything. What ends up getting tested is the users ability to assemble a viable security policy and their ability to select and configure their system and security apps to enforce that policy.

 

But sometimes there is a situations when User is ready to overwrite all policies just to run the program They believe to be safe...

So all those tests act as "what if user allows it to execute..."

THIS is the problem with all HIPS, white-listing and default deny policies...

 

If the security policy and/or configuration allows the user to install or run an unknown, it can't be regarded as a static system. That said, few systems are truly static. Even systems intended to be static need to be altered at times for various reasons. Part of building a security policy is separating and defining the roles of the administrator and the users. The default-deny aspect of the policy is in force during normal, non-administrative usage. On my PCs and several that I maintain, installing and/or updating the system is the administrators job. The users can't alter the system. If a user wants a new app, I'll install it, provided it's clean and behaves properly. That policy just saved me a lot of work on a clients PC. They ran into the fake "you're infected" ads that look like part of the system. Even though I've explained this to them on several occasions, I got a call from them telling me that "the AV says we're infected and we have to install this software, but it won't install." IMO, default-deny more than made up for any inconvenience it causes with this one occasion alone. The last time, it took me 2 days to get their system back the way it was.

The security policy should spell out the procedure for updating and modifying the system. On mine, the procedure is as follows:

1. Make a full system backup before installing anything. Don't rely on an uninstaller.
2. Upload the file to be installed to VirusTotal and scan. If too large, use something like HouseCall to scan the containing folder.
3. If possible, install the new software on a test system first, either real or virtual, making certain that it behaves properly and doesn't conflict with anything already installed.
4. Monitor the install process with an app like Inctrl5. It will report every new, altered, and deleted file plus all registry changes made by the installer. If the install reports for all changes to the system are saved, it becomes possible to account for every file on the system and what application is responsible for it. Also monitor the first launch of the installed software.
5. Keep the security apps running during the install process, whether the vendor likes it or not, especially the HIPS and internet firewall. READ ALL THEIR PROMPTS. They can alert you to apps trying to install toolbars, adware, and calling home without your consent. An installer that calls home can easily download more files that you didn't scan as part of the install process. That makes it possible for an installer to scan clean but still be malicious.

This may seem inconvenient, but it's much less so that removing a rootkit or trojan. On a system intended to be static, there isn't as much installing as there is on other systems. It isn't necessary up install the newest version of an app unless the vulnerability that's fixed directly affects you. If your configuration is good, a vulnerable application will be effectively isolated from the rest of the system, making the vulnerability useless to an attacker.

Static Windows works. It can be extremely secure, but it does restrict the user. The user has to decide if it's right for them. I regard most of my operating systems and apps as tools. I want them to work the same every time. On those, a static system fits what I do. I also have one that I use for play. That system is restricted but it's not static. There's many factors in deciding if a static system is right for you, but the primary factor boils down to one simple question. Is that PC going to be a tool or a toy?