Maybe you already knew: MS is giving away Services for Unix 3.5 (SFU), which can give you a very functional *nix commandline on a Windows box. No more struggling with Cygwin, looking for windows ports of your favorite commandline tools, etc.
But did you know about the Interop Systems Tools Warehouse? Here you can pick up dozens of *nix tools which will run just fine within the SFU environment. Take a walk on the *nix side, baby!
2004/08/30
Network Access Quarantine recipe
Awhile back, we noticed that MS now gives you a way to check for and update hotfixes, AV, and firewall software before connecting VPN clients. This is big stuff; the VPN is the entry point for quite a few malware breakouts. You control your LANs; isn't it time you controlled the VPN?
Security Focus' John Hassel has written a step-by-step guide to building a VPN quarantine control system. While this requires Win2003 server as your VPN endpoint, we think this is a great justification for upgrading at least one of your servers. This could be one of the three best steps you'll take all year in terms of minimizing malware outbreaks. (The other two? Service Pack 2, and keeping enterprise antivirus up to date.)
- Part 1
- Part 2
2004/08/28
Rule the rack
Racking up a few servers are you? Worried about getting everything to fit right? This tape measure, graduated in inches and rack units, could be a big help. Fifteen bucks gets you one.
Registry Cleaners = placebos
UPDATE (2005/10/10): Mark Russinovich has a few things to say about registry cleaners. I've added a few comments at the end of the article in an attempt to interpret.
It's time for a little adminfoo debunking. I've noticed a bit more hype lately about various 'registry cleaner' utilities, and I have this to say about them: bunk!
First, a short explanation of what the registry is. If you remember the old days of Windows 3.1, you may recall the old *.ini files (unix people should be thinking of *.conf files). These were text files which held configuration data for a program - things like where program data might be found, or user preferences such as window size and placement, etc. As Windows evolved, the decision was made to centralize all of these *.ini files into one central repository. And so the registry was born. It is now several files, but essentially it is accessed like a single database. Registry keys hold values and data.
The basic registry cleaner parses the whole registry looking for keys which point to things (files or other registry entries) which are not there. Some cleaners claim to do more, "healing" broken entries (I would be especially wary of these!). Bottom line is, if you have an actual bad registry entry (as opposed to just an extra one), you already know it because something is throwing errors. But folks, it's been a long time since I've seen a system error which could be traced back to a bad registry entry.
Let's take a few registry cleaner vendor claims and examine them (claims in italic; response in normal text):
It's time for a little adminfoo debunking. I've noticed a bit more hype lately about various 'registry cleaner' utilities, and I have this to say about them: bunk!
First, a short explanation of what the registry is. If you remember the old days of Windows 3.1, you may recall the old *.ini files (unix people should be thinking of *.conf files). These were text files which held configuration data for a program - things like where program data might be found, or user preferences such as window size and placement, etc. As Windows evolved, the decision was made to centralize all of these *.ini files into one central repository. And so the registry was born. It is now several files, but essentially it is accessed like a single database. Registry keys hold values and data.
The basic registry cleaner parses the whole registry looking for keys which point to things (files or other registry entries) which are not there. Some cleaners claim to do more, "healing" broken entries (I would be especially wary of these!). Bottom line is, if you have an actual bad registry entry (as opposed to just an extra one), you already know it because something is throwing errors. But folks, it's been a long time since I've seen a system error which could be traced back to a bad registry entry.
Let's take a few registry cleaner vendor claims and examine them (claims in italic; response in normal text):
-
...your registry gets stuffed with corrupt and orphaned entries. Many invalid records remain in the registry long after the corresponding applications were removed. This slows down your computer and can cause errors in other installed programs. A large registry is no slower than a small one, since Windows does not have to read the registry sequentially until it hits the right key and value. The registry is mapped, acting more like a database than a large file, so the program can go right to the key it needs and retreive a value. Notice how no registry cleaner product ever advertises actual measurements of speed gains? Finally, the difference between a 'large' registry and a 'small' one might be all of 20 mb (or 60 mb in really extreme cases). On today's computers that's a negligible amount of space.
-
...and can cause errors in other installed programs. Programs keep registry entries within their own keys and rarely if ever reference keys written by other programs. Today's programming best practices include building an uninstall routine which removes these entries when the program is removed. While it's fair to say that many older programs don't do this, and even many modern programs don't do it as well as they should, it's also true that registry keys, values, and data left behind by uninstalled/abandoned programs are simply never referenced. They take up very little space on your system.
-
Advanced "Deep" registry clean. There are thousands of programs out there - many of which can write thousands of combinations of registry keys/values/data. Do the math and you quickly discover millions of possible combinations, few of which are publicly documented by the program's makers. The idea that some omnipotent registry cleaning tool is aware of what all these programs "should" have entered in the registry, and will properly remove or correct each individual entry, seems silly to me.
-
Problems with the Windows registry are a common cause of Windows crashes and error messages. Not in my experience, or the experience of any of the professionals I asked about this. Ask yourself: when was the last time you had a problem with Windows and you were sure that problem was traceable to a registry entry?
- For example, a registry key pointing to a non-existing file is invalid and must be deleted. Statements like this appeal to the neat freak in all of us. But again, there's very little actual need to do this, since the entry will simply never be referenced, and the key or value takes up only a few bytes on your hard disk. It's like saying all unused files MUST be deleted from your system: sure they aren't doing anything anymore, but if they aren't hurting anything and you have gigabytes to spare, what's the point?
... there's a lot more in this vein. But really all registry cleaners make the same tired, unprovable claims over and over again. Bottom line: most users have no need for this class of utility, and should not be fiddling with the registry anyway. Make changes to software via the software's provided interface, and let the software and the system handle the registry! This is snake-oil, folks, and you shouldn't be buying it unless you've got money to burn.
Troubleshooting pros will occasionally make setting changes directly in the registry. But it's like taking the back off of your TV set: don't do it unless you know what you're doing. Even if you do know what you're doing, you should always back up the registry before making any changes. If you insist on using a registry cleaner placebo, you'd be very wise to backup your registry first.
In closing I will contradict myself just a bit. Some folks do have a legitimate need for registry cleaners. Typically these are programmers and QA staff developing new software. In their dev and test routines they may install and uninstall the same software hundreds of times, and each time they need to be sure to remove all artifacts of the prior install, including registry entries. In this case, a registry cleaner may be justified - though most of the folks I know will write a script which specifically strips out the registry entries used by the program they are testing.
That's my rant. I'd love to be proven wrong, so if you can find measurable evidence of a registry cleaner doing any real good in the world, hit the comment link!
UPDATE (2005/10/10): I read Mark Russinovich's recent comments on Registry Junk with great interest. As you may know, Mark is the leading light behind the supremely respected sysinternals.com, so he's like E.F. Hutton in my book. When he speaks, I listen!
When I first started reading his article, I thought: yay, Mark and I agree! But actually he presents a more nuanced picture, going deep into a special situation I hadn't considered before: uninstallers that leave bogus keys in HKEY_USER registry key/value sets. However I beleive the situation Mark describes is pretty rare (especially in on-the-job situations), and leads to actual problems a vanishingly small amount of the time. Mark ends up concluding that "Registry cleaners will continue to have a place in the anal-sysadmin’s tool chest". Hmm! I've been called anal before ... but even after taking Mark's comments to heart, I still conclude that Registry cleaners are uncalled for 98% of the time they are used. Your mileage may vary.
2004/08/23
First Things First
For those of you wanting to get started implementing or learning about security, I highly recommend SANS' First Things First paper. Starting with the venerable OSI model and moving quickly through a few network device and protocol primers, various network security methodologies, antivirus, and finally various host-hardening guides, this is the nuts and bolts of security exposed in a purposeful way. I particularly applaud this guide for directing people right to the RFC's for various network protocols, rather than more 'explanations of explanations' type documentation which is becoming all too common these days.
Excellent reading for anyone who wants to become a better admin, whether focused on security or not.
-Thanks to the folks writing the ISC Handlers Diary, which has become part of my daily morning read.
Excellent reading for anyone who wants to become a better admin, whether focused on security or not.
-Thanks to the folks writing the ISC Handlers Diary, which has become part of my daily morning read.
2004/08/20
Windows Startup Online and EventID.net
UPDATE 2005/08/22: Just over a year later, I have found Tasklist.org, another resource which maps programs and vendors to .exe names.
Yesterday I was troubleshooting some odd issues with my new laptop. Although unrelated, I noticed quite a few programs being started automatically when I boot my system up - most of them added by the laptop vendor. So I began investigating to see what they were. This isn't as easy as it should be - while MSCONFIG is a big help, you're still left wondering what 'TpKmapAp.exe' or 'SynTPEnh.exe' actually do, and whether or not you need them starting up every time you boot your computer.
And that's where windowsstartup.com's very handy database of startup programs comes in. It's actually meant as the backend database for their Startup Inspector program (which I haven't tried yet, though it looks nice and is free), but you can query it directly via the web. Excellent idea!
(Added 11/23/2004) For entries missed in the StartupInspector database, I recommend you try ProcessLibrary.com, a similar tool. Between these two, most startup programs should be identified.
I'll round out this post with a similar web database: EventID.net, an online database of things you might find in your event log. Query results will often provide more in-depth explanations of what the log entry means, and what you should do about it. Highly recommended for all you universal troubleshooters.
Yesterday I was troubleshooting some odd issues with my new laptop. Although unrelated, I noticed quite a few programs being started automatically when I boot my system up - most of them added by the laptop vendor. So I began investigating to see what they were. This isn't as easy as it should be - while MSCONFIG is a big help, you're still left wondering what 'TpKmapAp.exe' or 'SynTPEnh.exe' actually do, and whether or not you need them starting up every time you boot your computer.
And that's where windowsstartup.com's very handy database of startup programs comes in. It's actually meant as the backend database for their Startup Inspector program (which I haven't tried yet, though it looks nice and is free), but you can query it directly via the web. Excellent idea!
(Added 11/23/2004) For entries missed in the StartupInspector database, I recommend you try ProcessLibrary.com, a similar tool. Between these two, most startup programs should be identified.
I'll round out this post with a similar web database: EventID.net, an online database of things you might find in your event log. Query results will often provide more in-depth explanations of what the log entry means, and what you should do about it. Highly recommended for all you universal troubleshooters.
2004/08/19
Transferring ownership of files
If you're a Windows admin, you've probably 'taken ownership' of files in the past. Did you know it's also possible to 'give ownership'? The normal GUI won't allow you to do it (unless your on a Win2003 server box), but this article shows the way for NT and Win2000 using subinacl.exe.
2004/08/17
Manage your passwords!
Even if you work in a single-signon (SSO) environment, I'll bet you have at least 20 passwords. Probably more.
How are you keeping track of them all? Not the dreaded sticky note on the monitor I am sure - because you're a professional. But here's a funny thing: last Friday I visited a respected professional in his cube and watched him peek at a slip of paper from an unlocked drawer as he logged on to one of our lesser-used servers. He looked sort of sheepish doing it, but it's a real problem. You're supposed to create hard-to-crack passwords that are difficult to remember, and you're supposed to remember them without writing them down. Catch-22.
There are a lot of out there. I use Bruce Schneier's Password Safe for these reasons:
- I trust Bruce. He's a clear thinker and a hype basher.
- It's small enough to fit easily on a floppy (remember those?) or a USB key.
- No install routine, so I can store it on a network share and access from anywhere.
- It's secure - and it's simple. That's the goal y'know: security made simple.
Of course you should choose whichever password manager you like - just about any password manager is more secure than a piece of paper in a drawer or a wallet, and if it's not comfortable you won't use it. Once you have and use a password manager, you will be more inclined to use really hard passwords - I usually generate random ones with Password Safe.
I keep two password files - one work related and one for my psersonal stuff. Every so often I dump the work related one to a floppy. I write the password on the floppy, seal it in an envelope, sign across the flap, and give it to my boss - in exchange for the old one. This means my replacement can get right to work after I have spontaneously combusted. Might also be handy if the server breaks - I won't have to wait for the full restore to get my passwords back!
I keep a copy of my 'not work' password file in our fireproof safe at home. But it'd be just as good to have a friend or relative hang on to it.
2004/08/16
Linux: simple 'snapshot' backups with rsync
If adminfoo seems a little windows-centric, that's because, well, it is. It's not meant to be, but I don't have much choice in the matter, since I spend about half of my waking hours thinking about Windows. It's not a prejudice issue ... and to prove it (again!) I bring this note about backups on Linux.
One of the sexiest things about Netapp is those cool snapshot pseudo-backups. This article shows how to create a poor-man's functional snapshot on Linux, basically by the smart use of rsync, cp, and mv commands. It is well thought out, and finds an exciting strength in the *nix way of running a filesystem. As the author leads you through his excellent backup strategy for Linux, he also provides a thoughtful grounding on some Linux file management basics. An excellent return to first principles for gurus, and a wonderful and practical walk through for Linux newbs.
Highly recommended. (Oh, and if you'd like more *nix articles here, why not sign up and submit them?)
2004/08/12
Antivirus: defense in depth
MS has released a 90-page Antivirus Defense-in-Depth Guide which is well worth a read. Although you'll already be familiar with many of the concepts outlined in the Guide, it brings everything together in a nice framework overview, and may well expose a few specific tips/tricks you hadn't been aware of. If nothing else, print out chapter 4 (Outbreak Control and Recovery) and keep it at your desk to use as a plan of attack when outbreaks do occur.
In related news, Jeffrey Lee Parson (pictured on the right) has pled guilty to releasing one strain of the MSBlast malware that was so troublesome last year, and will be sentenced in November.
Subscribe to: Posts (Atom)