Sat, 27 Nov 2004
Land-mining Servers
Heres the shell of an idea I've been mulling over recently, we all know
that compilers on server are bad don't we? The common wisdom (and this
is often disputed by people who use source based systems) is that people
shouldn't be compiling up new versions of software on the production
servers. By omitting the compiler suite and required header files you force
compilation to occur elsewhere.
The second reason, and I'm not so sure about how current this is, is that you deny an attacker an easy way of hiding their tracks. By leaving applications like GCC off the servers you force them to precompile rootkits and trojans to suit your system. This is where having a diverse operating system ecosystem pays dividends.
So ignoring all the special cases and caveats lets put those two basic facts together:
- Legitimate users shouldn't be compiling on servers.
- Attackers will attempt to use any compilers installed on the server.
So lets trojan GCC or something else essential in the tool-chain. Having complete access to tinker with everything is, after all, the defenders main advantage. So what do we actually want it to do? The low hanging fruit would be to send an alert (via pager / mobile phone and syslog) so we know that either the procedure has been broken or the system is under attack.
While being notified is the bare minimum we should strive for we may want to take it even further with some automated defences. To me there are two obvious approaches, firstly we can either kick them off and lock out the connecting IP address, which runs the risk of leaving the server open to either a DoS or that the cracker can re-exploit the same hole they previously used to regain access.
The other approach is to tinker with the tool-chain and ensure that it doesn't generate correct binaries. Maybe forcing it to cross-compile to a Power-PC format instead of X86. What does this gain us? At the least it will stop them compiling and then using their collection of tools to screw the system while letting them think they have working tools; this has the side effect of breaking some autorooters and raising the barrier of entry. If we are lucky they will be unskilled and either leave the server or spend enough time trying to get them working that the response team can catch or kick them.
Lastly, and this one requires the most prior planning, it would be possible using either existing honey-net applications or custom code to send the source to another more secure machine (such as a loghost) for future analysis.
This is more a brain dump than an actual plan of action but I do think it's worth considering. Especially if your production servers are all managed in batches.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2004/11/27 14:09 | /security/tools | Permanent link to this entry | This entry + same date
Copyright © 2000-2005 Dean Wilson
