[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Secure Server



Alejandro Rodriguez Luna wrote:
> I just wanted ask about the security of services like ssh, dns, etc, 
> what is the best way to secure this services?, perhaps /etc/hosts.allow
> and /etc/hosts.deny?, or perhaps with a superserver inetd or xined?,
> 
> what's the difference among those way to secure the system?

Security is rarely an objective concept.  Who or what are you wanting to
secure the system against?  Security measures are only effective against
specific threads or classes of threats and can only be assessed in that
light.

That said, there are some things to do to secure a system against common
and general attacks.  For one thing, make sure that you always have the
latest security updates installed.  If there are vulnerabilities such as
buffer overflows, predictable random numbers, or other holes that are
discovered in the software, installing the relevant updates will keep
attackers from using those vulnerabilities.

I also use host access control and the denyhosts program to reduce the
effectiveness of brute-force password attacks against my SSH Server.
Also, disable root login over SSH, particularly with a password (so
someone can't guess your root password and use it), and if you don't
need password-based login consider disabling password authentication and
using only public-key authentication.  Private keys are much more
difficult (read: intractable in your lifetime, assuming the
computational basis of cryptography is robust) to guess than passwords,
provided that they have been generated securely (specifically
regenerated after all affected systems have updated from the Debian
OpenSSL random number problem a couple years ago).  They have the
downside that they can be stolen, although most people seem to consider
this highly unlikely when the private key is passphrase-protected.

On securing DNS, I do not run a DNS server aside from dnsmasq and have
no recommendations to offer.

If you have services which only need to be accessible from certain
networks, then using hosts.allow/hosts.deny to restrict access certainly
won't hurt.

Remember, though, that it is impossible to take a system and say "this
system is secure."  As someone a lot wiser than I has said, security is
a process, not a state.  There are things you can do, of course.  Don't
allow access to services where that access is not needed.  Apply
security updates to reduce the likelihood of an attacker being able to
bypass security measures.  Mitigate against well-known.  Monitor your
systems to notice anomalies.  Use service implementations with a good
reputation for avoiding and fixing security problems.  But don't
envision a state where you can rest and say "my system is now secure."

HTH,
- Michael


Reply to: