Small Mosaic


Categories:

/books
/career
/cloud
/codinghorrors
/events
/geekstuff
/justdont
/languages
/languages/bash
/linkshot
/magazines
/meta
/misctech
/movies
/nottech
/operatingsystems
/operatingsystems/linux
/operatingsystems/linux/debian
/operatingsystems/solaris
/perl
/presentations
/programming
/python
/ruby
/security
/security/apache
/security/tools
/serversmells
/services
/services/dns
/sites
/specifications
/sysadmin
/testing
/tools
/tools/commandline
/tools/firefox
/tools/gui
/tools/network
/tools/online
/tools/online/greasemonkey
/tools/puppet
/unixdaemon

Archives:

May 20131
April 20131
March 20131
February 20133
January 20135
July 20111
June 20112
May 20113
April 20112
March 20117
January 20111
Full Archives

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.

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2006/09/21 07:38 | /security/tools | Permanent link to this entry | This entry and same date


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:

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 and same date


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.

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2004/11/23 22:47 | /security/tools | Permanent link to this entry | This entry and same date


books career cloud codinghorrors events geekstuff justdont magazines meta misctech movies nottech operatingsystems/linux operatingsystems/linux/debian operatingsystems/solaris perl programming python ruby security security/tools serversmells services/dns sites sysadmin testing tools tools/commandline tools/firefox tools/gui tools/network tools/online tools/online/greasemonkey tools/puppet unixdaemon

Copyright © 2000-2010 Dean Wilson XML feed logo