Thu, 21 Sep 2006
Run Security Scans from Visio
I'm not a huge fan of Visio but the ability to connect the MBSA to individual hosts and trigger scans is very neat. I'm also assuming that you can use the Visio scripting interface to mark machines that fail as a different colour. Full details over at the Visio Connector for MBSA article.
Sat, 27 Nov 2004
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.
Tue, 23 Nov 2004
RADIUS Servers -- A cast of... well two.
In my quest to learn how RADIUS works and the correct way of running my own server I picked up both the O'Reilly RADIUS book and GNU RADIUS, A Reference Manual. Neither of which are exactly ground breaking books.
Now I've almost finished the O'Reilly book I thought it would be a good time to get my hands dirty and have a play, so I looked at XT RADIUS; which hasn't been updated since very early in 2002. Then I looked at Cistron RADIUS, which is in a slightly better state as it still has bug fixes made for it but no active development of new features. And then I tried to look at PerlRADIUS which doesn't even seem to have a valid home page these days!
So the point of this post? If you have stumbled upon this blog via my previous RADIUS posts (as my logs indicate a number of you have!) I'd suggest looking at FreeRADIUS or GNU RADIUS. I'll probably post at a later date about my experiences with these and which one I've adopted as my own implementation of choice.