Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://itpm.msu.su/LDP/LinuxAdministration/linux-admin-made-easy-12.html
Дата изменения: Sun Apr 18 13:35:41 1999 Дата индексирования: Mon Oct 1 21:59:45 2012 Кодировка: Поисковые слова: shadow |
Linux can certainly be considered to be as secure -- or more secure -- than operating systems from other vendors. Admittedly, with Linux becoming more and more popular, it is becoming a very attractive target for crackers to concentrate their break-in efforts. There are exploits that are discovered from time to time, however the open nature of Linux usually means that such exploits are patched quickly, and security announcements are disseminated widely, containing either temporary workarounds or pointers to updated software.
I won't pretend to be an expert on security issues, however I am at least aware of these issues, which I believe to be a large part of the battle towards making one's systems as secure as possible. Although being aware and diligent in keeping up with security updates will in no way guarantee that a system's security measures won't be circumvented, the likelihood of a break-in is greatly reduced.
Although there have been security exploits found in external services which could have been used by crackers to break into a system (for example, the IMAP daemon exploit), I believe that it is far more likely that a determined cracker will penetrate the system from within. Compared to the handful of services communicating with the outside world, there are thousands of commands and utilities available from the shell, one or more of which may contain bugs which can be exploited to penetrate security (that being said, I must admit to recently discovering one of the servers I maintain had been compromised through an external service).
For this reason, I recommend avoiding giving out shell accounts to users unless they are absolutely necessary. Even if you consider your users completely trustworthy and have no qualms in providing them with access to the shell, all it takes is just one of these users to have a weak password. An outside cracker, finding its way into your system by exploiting this weak password, will then be able to work at his or her leisure internally, looking for further weaknesses.
There are, fortunately, things you can do to greatly increase the security of your Linux system. While a detailed discussion of security issues is beyond the scope of this document, the following checklist provides some of the most important things you should do to enhance security:
Ssh provides encrypted and compressed connections and provide substantially more security than telnet connections. You can run a ssh server (which allows incoming secure connections) as well as a client (for outgoing secure connections) under Linux. You can find binary RPM packages at ftp://ftp.replay.com/pub/replay/redhat/i386/. You will need the following files (newer versions may be available by the time you read this):
Should your Windows users be up-in-arms about no longer being able to connect to your system, they will be happy to know that several free ssh clients for Windows are available:
http://hp.vector.co.jp/authors/VA002416/teraterm.html
http://www.zip.com.au/~roca/download.html
http://www.doc.ic.ac.uk/~ci2/ssh
Note: If you do decide to switch to using ssh, make sure you implement it on all your servers. Having five secure servers and one insecure one is a waste of time, especially if you are foolish enough to use the same password for more than one server.
/etc/hosts.allow
'' as well as the
``/etc/hosts.deny
'' file to restrict access to
services to external hosts. Here is an example of how to restrict telnet
and ftp access. First, the ``/etc/hosts.allow
'' file:
# hosts.allow
in.telnetd: 204.41.178., 206.178.38., .alcdsb.on.ca, .flarc.edu.on.ca
in.ftpd: 204.41.178., 206.178.38., .alcdsb.on.ca, .flarc.edu.on.ca
Next, the ``/etc/hosts.deny
'' file:
# hosts.deny
in.telnetd: ALL
in.ftpd: ALL
/etc/inetd.conf
'' file, and disable (ie. comment
out using a ``#
'' character) any services that are not needed (if
you're using ssh as recommended above, you might wish to disable the
``telnet'' service). After you have done so, as root type
``/etc/rc.d/init.d/inet restart
'' to restart the inetd daemon
with the changes.
RPM
'' utility, you may wish to verify the integrity of your
installed packages with the following command:
rpm --verify -a
(For more information on ``RPM
'', see the
"Using the Red Hat Package Manager (RPM)" section.)
For more information on security-related issues, an excellent resource entitled, "Securing RedHat 5.x" document is available at http://redhat-security.ens.utulsa.edu/.