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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
