The Ridentd server application is meant for the totally paranoid that need access to servers that require ident and don't want to give any information about local users to the remote server or its other users. Ridentd is a stand-alone replacement for identd that uses a random selection of a ispell dictionary to use as fake ident responses. The ident response is based on a (one-time randomly initialized) modulus of the local port in order to assure that one session will return the same identity during a TCP session.
The Spoofaudit network auditing tool will help you to determine what basic spoofing filters (rfc2827 & rfc3013) are present between two test points on two networks, and what anti-spoofing filters are missing. The tools are designed to work between endpoints that would not normally have filtering between them except anti-spoofing filters.
The Capibara Distributed URL Cloaking Kit is a reliable URL cloaking system using low QOS hosts and lines such as home PCs and DSL or cable connections. CDUCK combines DNS server/Web server functionality and a strict security model for the creation of reliable and safe domain Web cloaking.
MinorFS combines a small set of cooperating userspace filesystems for Linux that provide private storage to pseudo persistent processes. This allows programs that are run by a user to keep some data safe from all potential malware that runs with all this users' privileges. It further implements simple password capabilities as a way to explicitly share access with other processes or users.
The JsonMe++ (JSON Made easy for C++) library is a C++ wrapper for the JSON-Glib C library. The library makes heavy use of C++ syntactic sugar type C++ language constructs, most notably the subscript operator and cast operator as essential API components, which makes this JSON library extremely simple to use. As a result, access to a deeply nested value from a piece of JSON data can be expressed simply.
libKISSlog is a trivial lightweight C++ template library designed and written according to the KISS (Keep It Simple and Straightforward) principle. It leans heavily on STL for keeping its implementation as simple as its usage, and tries to provide C++ developers with a lightweight, paradigm-pure, and flexible alternative to logging libraries which use design and/or implementation decisions which at least the author of libKISSlog believes to be questionable. Its easiest to explain why libKISSlog would be suitable for your needs by listing the things which libKISSlog does not choose to use or do: no singletons or other forms of mutable global state, no macros, no attempt to fit the Java runtime everything model onto a C++ library, no attempt to be a Java-style (bloated) framework, no attempt to make the choice for you of whether you need thread safety, and no compromise on simplicity in order to facilitate questionable inner-loop logging practices.
Re: Preventitive Security is nice..
> Can we stop remote exploits with
> better authentication/authorization and
> well-written security policies? No,
> that wouldn't prevent a worm based on
> the OpenSSH exploit. Just run non-public
> services on non-standard ports. (A worm
> may still propogate, but it will be LOUD
> and SLOW.)
It would apear to me that most worms around are loud and slow even without checking for non-standard ports, and this does not much to stop their spreading. It might be that the
non-loud/fast worms are just not geting noticed, but a well
designed worm that checks random ports could be either loud
OR slow, but will still propogate. But what is worse, by laying
down obstacles that would requira a worm to be loud, the
worms will eventualy become louder, and the resources drawn
from non vulnerable systems by the loudness of a large amounth of infected systems will be even bigger.
The main idea for effectively working with security should be that "If we can't stop something comming in we should limmit the resources available to what it is coming in to".
For worm propagation prevention this would mean that
if you will eventualy not be able to keep atackers out,
you should make sure they will after this not be able to get
out again. Next to this you should monitor for atempts made by the server software to act like a client, that would indicate that
the server is compromized and that should trigger some
automated 'pull the plug' action.
What would effectively be needed to do this in a waterproof way would be that that the server would before getting on with its business be able to tell the operating system: 'Expect me and my children to access this and that resources, and please kill me if I access anything else'
For most services you can get to the same result by using conventional containment and sandbox techniques, and
I would like to advocate that setting up these measures should be the job of the instalation softwar for the software providing the service, but for services like ssh, this would
probably require not yet existing containment and sandboxing techniques that should be offered by the operating system.
Good old containment is the answer, but without user competence
The issues raised in this article are completely true, but the
security focus being on bugs and patches is just something of the last few years, and although the bugtraq list has done some great work on getting this part of security noticed, it has by
being so popular made many newcomers to the security field
beleive that this 'maintenance' part of security is the major
Having said this, and looking at your article for solutions, there seem to be non there that would be able to do more than ad
to the security in a minor way.
The best way to think of security is in the old way of using containment measures, but combined with newer techniques
that pressent operating systems offer or should offer.
You must just try to accept the fact that if you are running a
service, than at some point in time people will be able to breach the security and gain access to the resources that the
software running the service has access to. Having said this,
it is clear to see that the best way to work with this is by
limmiting the resources the software has access to by using
old-fasion, and new containment and sandbox techniques
like chroot enviroments, running services as unpriviledged users, user based firewalling etc.
Now comes the main problem:
Setting up these containment meassures is hard for the averadge user, and many users will not do so, or fail to
fully do so. The only way to fix this problem is for the
instalation scrips of software that offers a service to set up
these containment meassures themselves, thus not having
any need for user competence.
If you further combine this with a pull-the plug intrusion detection system, that will try to monitor for atempted access to resources the software should not need, and that will
effectively pull the plug if such is detected, you will have 99%
of your security in place, and can move the bug driven
security back to the place where it belongs, the 'maintenance' phase, but now needing only a small part of the resources.
For more information you can look at this article, or look at my proof of concept implementation of such meassures in service providing software (for the Linux platform) that is part of the CDUCK project.