From: Les Bell <lesbell@le...> - 2003-03-02 00:10:13
Craig White <craigwhite@...> wrote:
Actually, I think that ClarkConnect is based up RedHat and I think that
Redhat doesn't typically include MD5 encryption for users/passwords but
that doesn't mean that the passwords aren't encrypted. I am under the
impression that MD5 is getting a bit long in the tooth and not the
strongest of encryption methods.
Red Hat uses MD5 and shadow passwords by default, and has for some years
now. Or at least, what *feels* like years.
MD5 might be long in the tooth at just over ten years old, but its
mathematical basis is sound and it still remains "computationally
infeasible to produce two messages having the same message digest, or to
produce any message having a given prespecified target message digest". If
MD5 ever starts to become problematical, a switch to SHA-1 would be
As for ClarkConnect 'being a complete distro,' I would have to guess
that everybody's definition of what represents a complete distro is
going to differ anyway. It obviously is complete enough for the function
it is to provide, can tie into a larger frame of authenticaion methods
such as NIS and will accept the installation of binaries to extend it's
functionality. That seems fairly complete to me.
Adding software development tools like GCC to a firewall is not to complete
it, it is going to *reduce* security, as it makes it possible for a threat
agent to install rootkits and other tools from source. In fact, a
comprehensive organizational security policy will usually not permit
compilers on production systems of any kind, let alone firewalls.
I certainly wouldn't allow NIS on a firewall; there are simply too many
vulnerabilities - both known, and on the balance of probabilities, unknown
- in NIS itself and the underlying RPC/portmapper subsystems. NIS+ is
better, but I wouldn't allow even that. In any case, a firewall probably
should not participate in any distributed authentication scheme, except for
road warriors who need to poke holes in it - and even that is better done
using a VPN scheme with hardware tokens, RSA ACE server, or X.509
The inability to compile on firewall machines causes one problem - it makes
it difficult to install Net::SSLeay and thereby secure Webmin. On my
'to-do' list I have an item for building an RPM of Net::SSLeay, but it's a
long way down the list at the moment. Of course, for some people, even
running Webmin with SSL support is an unacceptable risk. Where I *do* allow
it, Webmin binds only to the internal interface of the firewall.
--- Les Bell, RHCE, CISSP