Test harnesses are frameworks to run a bunch of automated tests on a system, verifying that it meets specified behavior. This works best when you can exhaustively list out everything that could possibly go wrong. Anything that you can match to a checklist, you can put into a test harness. Possible uses in security testing include:
These are just categories, and clearly some of these are larger than others. Unit testing is a well-understood part of software development, but it’s usually functional testing (i.e. break/fix) rather than actual security validation and verification. Can the system handle extremely large inputs, such as those used in a buffer overflow? Format strings? SQL injection? HTML injection/cross-site scripting?
This also lends itself to defense-in-depth: don’t just rely on a filtering function at a high-level if the lower-level functions can’t handle the input, since alternate input paths might bypass the filter, intentionally or unintentionally. If nothing else, the unit tests make sure that you don’t bypass such filters.
A concrete example that should be familiar to any sysadmin is a deployment checklist. Typically this might include areas like listening ports (network services), permissions, password policies, up-to-date patches, and other configurations. Two test harnesses, internal and external to the system would be useful. The internal test harness makes sure that the output of “netstat -an” doesn’t contain anything more than the expected services (not just looking for “bad” services), looks for particular strings in the policy and configuration files such as those in the /etc tree, runs a patch verification tool, baselines the file integrity checker, and verifies that file and directory permissions match your policy.
This way, you’re sure that recent OS or application changes haven’t broken your compliance or that a fat-fingered absent-minded sysadmin (not that that’s ever described me) hasn’t missed something. As we’ve all learned, “trust but verify”.
The external script might run a port scan (nmap), an OS-level vulnerability assessment (Nessus), a web server assessment (Nikto), and, if possible, some application verification. The latter works particularly well for web applications. Take the output of both test harnesses, parse as needed, and assuming everything passes, save it to your system inventory. This includes the file integrity baseline for AIDE, Tripwire, and family.
You’ll sleep better at night knowing that your systems were deployed securely and you haven’t missed something.
I have a Get Fedora Linux desktop at home. It’s actually a dual-boot system, and lately for various reasons I’ve spent far more time in Windows XP than Linux. But this evening I was back with the penguin, and thought it would probably be a good idea to update the software. I knew there had been a lot of updates, including security updates, and I was right — hundreds of them. That’s not a problem, but yum still could not handle things properly. Specifically, there were dependencies with Mozilla that yum kept choking on, and some similar problems with libgcj. The solution was inevitably to force the removal of Mozilla and its dependent libraries, install the core package by hand, and let yum figure out the remaining libraries. Part of the problem is apparently that two versions of many packages get installed (both 32- and 64-bit as this is an Athlon 64).
So why isn’t this of the highest priority? If it takes an experienced Linux admin an hour or more to sort through the problems, the average user wouldn’t have any idea how to even begin. Try explaining command-line switches, architecture migrations, and file globbing to someone, and their eyes will glaze over faster than you can say “Nick Burns”. Security updates shouldn’t require digging through the arcana of the system. If there was one thing that would turn me off Fedora (which, in general, I love), yum (and its pretty frontend, the far more useless RHN tool) would be it.
NB: Sorry, vacations and a substantially increased workload have caused me to back off blogging a bit. I’m trying to work things back in, though, and this is the first queued post of several. Some of the posts will be shorter in an effort to keep information flowing, but I hope to continue to write the longer articles that interest me (and hopefully you) on a relatively frequent basis.
Passwords are probably the most common authentication method by far, and they’ve become so common that most of us have severe difficulty remembering them. Some security folks have long recommended not writing them down, but this advice is so impractical as to be completely ignored or lead to more severe problems. The trick is to record your password more securely, and as usual, simple solutions can do the job.
There’s a clever suggestion on Slashdot (of all places) that essentially uses a substitution cipher to help you remember them. The trick is that this substitution cipher is just to avoid brute-forcing and doesn’t replace the crpytographic strength that resides (hopefully) in the actual password management function of whatever system you’re accessing.
Hah! I have embedded HTML in this blog entry that has compromised your system. It’s smart enough to attack multiple platforms (including Windows and Linux) and gives me command-line administrative level access. Don’t believe me?
Heh. You just lost your privacy.
While there are lots of dumb ways to secure wireless networks, here are the six dumbest. Read the article, there are a lot more details there.