New Messages
Subject: Landmining the cracker's playing field I was sometimes on the verge of cancelling my subscription because of the lack of quality of some articles. The hoax about password-secured shell scripts some months back topped it all -- I hope no beginning sysadmin fell for that all too easily circumventable “security”. Focus on Linux got you back some sympathies, though it's not what all sysadmins need foremost. But now -- congratulations! - The September issue is neat, especially the part about landmining system commands. Since most of us don't have sources, the wrapper variant would have deserved a little more attention. Especially pointing out that hiding would be achieved by putting the originals into a directory with only the x-bits set, maybe even an unguessable subdir thereof. Calling it without letting on the uninitiated is tricky: If you call it by absolute path, that's visible in ps -f. If you tack it onto the front of $PATH, it would be visible in all commands that offer a shell escape. You shouldn't then allow calling a system call tracer (truss/strace), which would show the precise exec() call. Since many systems have readable executables, the name of the hidden directory should not be stored within a static string, but rather be constructed from single characters at run time.
Greetings Daniel, I'm glad you enjoyed my article. Since your letter to the editor specifically mentioned my piece, the editor was kind enough to forward your message to me so that I could respond to you in person. Let me first say that systems administrators without source code or a more in-depth knowledge of programming do indeed have it harder when it comes to this sort of booby-trapping, but I think that can be said of pretty much anything related to computer security. My article certainly did not cover a comprehensive security plan, and was far, far from describing all that I would do to harden an exposed critical system. There's a very long checklist to go through when hardening a system: redoing all of the system permissions, proper logging, setting up constant monitoring programs, and removing all nonessential binaries, directories, files, and configuration entries, to name a very few. In my opinion, when a systems administrator finishes hardening an exposed system, it should look very little like what came off the install media. My article was meant to target a very specific instance: how to catch crackers when your properly hardened system has already been compromised. I think that most of your concerns deal more with the hardening process than the landmining one, but I'll address your points individually. When the intruder already has privileged access on the target machine, hiding things in directories with only the execute bit set doesn't achieve a great deal. In fact, setting up a ‘‘hidden'' directory might attract more attention if the rest of the system is not set up the same way. I do, however, strongly suggest removing read/write bits on as many things as possible on the system (including most executable programs) as part of the initial hardening process before the machine hits the network. Your concerns about how to call the ‘‘good'' binary are well warranted if you've put them in a secret directory somewhere. In the scenario I was envisioning, I'm not sure the problems you describe would exist, though. When I spoke of hiding the ‘‘good'' binary, I was thinking that things are better hidden in plain sight. For example, if you wrap ps, rename the real ps to some other unused system binary that you've already removed, like telnet. The problems you mention with the path showing up somewhere in a ps listing (again, a good program to landmine anyway, and then you've been warned when the cracker runs it) aren't as much of an issue if you're hiding the‘‘good'' binary where another binary would commonly be. In any case, if the systems administrator is passing arguments to a program, it's more likely to be spotted, no matter what it's called. If a cracker is sitting on the target machine watching, and the systems administrator runs anything with the flags ef or auxww, then the cracker has most likely spotted the ‘‘good'' ps. But then how was the cracker watching undetected in the first place, unless she brought along her own precompiled binaries? If the cracker is toting along precompiled binaries specifically for the target platform, the systems administrator is already in a lot of trouble, anyway. As far as tracing kernel streams and otherwise disecting system calls and strings within binaries (trace, strace, truss, strings, and others), this again falls into the category of removal during the hardening phase or possibly landmining. Why leave tools lying around for the crackers to use against the systems administrator? If the need should arise for the systems administrator to use one of these tools, s/he could simply transport it over from another machine or some form of read only removable media (preferred). Thanks for reading and bringing up your points so that I could clarify some things outside of the scope of the article. I hope I've adequately addressed your issues and answered your questions.
Amy Rich
Subject: Maintaining Patch Levels with Open Source BSDs Hello, Very good article about CVS and CVSup. I'd just like to add that in our organization we keep two servers, one for 2.2.8-stable and the other for 3.2-stable. Each night they sync via cvsup with one of the cvsup servers, do a make buildworld, scan /sys/compile, and build a dozen kernels. Each time we want to update some of our machines, we just NFS mount /usr/src and /usr/obj from the appropriate server and do a make installworld, cd /sys/compile/THISMACHINEKERNEL make install and reboot. This way we can make our updates fast even on old and slow 486 we use for DNS, dialup, etc. As an example, on Friday I upgraded our comp chem lab (12 workstations) in ~1 hour from 3.2-RELEASE to 3.3-RC. The users in the room stopped their work just for the reboot of the new kernel.
Regards,
Thanks for the additional information. -- AA |