For you to determine whether you think Linux is a secure operating system, there are a few pieces of information you should be aware of before making your decision:
Is it more secure to compile driver support directly into the kernel, instead of making it a module?
Answer: Some people think it is better to disable the ability to load device drivers using modules, because an intruder could load a trojan module or himself load a module that could affect system security.
However, in order to load modules, you must be root. The module object files are also only writable by root. This means the intruder would need root access to insert a module. If the intruder gains root access, there are more serious things to worry about than whether he will load a module.
Modules are for dynamically loading support for a particular device that may be infrequently used. On server machines, or firewalls for instance, this is very unlikely to happen. For this reason, it would make more sense to compile support directly into the kernel for machines acting as a server. Modules are also slower than support compiled directly in the kernel.
Answer: Well, you've taken the first step, and admitted that it has been a cause of exploit in the past. There have been several papers written on it's insecurity. Their new version, FrontPage 98 apparently hasn't gotten much better. Read this article, for an interesting overview of the issues at hand http://www.mr.net/~fritchie/frontpage.html
Also, the Microsoft FrontPage Security Hell is available here http://www.worldgate.com/~marcs/fp/
Instructions for installing and configuring, as well as building awareness, is available at the FrontPage Awareness Site available at http://frontpage.netnation.com/
Answer: Well, the obvious answer is to read and follow the procedures outlined in this document.
Assuming you have done that, and you are not currently aware of one of your machines already being exploited, and perhaps less obviously, download some of the exploits from http://www.rootshell.com and see if they work on your machine.
Answer: This information is covered in the Firewall-HOWTO, as well as in the Firewalls and Border Patrol section of this document. You should keep in mind that the ipfwadm(8) command is specific to the 2.0 release of the kernel. Version 2.2 will feature a much improved firewall, called IP Chains. You can find more information on IP Chains in the Firewalls section of this document.
Answer: The best thing you can do here is to check your Linux vendor's errata for any preconfigured packages in their updates archive for your current distribution.
You should also already be subscribed to one of the informational security mailing lists, or at least the announce list from your vendor, describing the procedure for finding the proper updates.
Answer: See the section on root security. This is done intentionally to prevent remote users from attempting to connect via telnet to your machine as root, which is a serious security vulnerability. Don't forget, potential intruders have time on their side, and can run automated programs to find your password.
How do I enable shadow passwords on my Red Hat 4.2 or 5.x system?
Answer: Shadow passwords is a mechanism for storing your password in a
file other than the normal /etc/passwd file. This has
several advantages. The first one is that the shadow file,
/etc/shadow, is only readable by root, unlike
/etc/passwd, which must remain readable by everyone. The
other advantage is that as the administrator, you can enable or
disable accounts without everyone knowing the status of other users
accounts.
The /etc/passwd file is then used to store user and group
names, used by programs like /bin/ls to map the user ID to
the proper username in a directory listing.
The /etc/shadow file then only contains the username and his/her
password, and perhaps accounting information, like when the account
expires, etc.
To enable shadow passwords, run /usr/bin/pwconv as root, and
/etc/shadow should now exist, and be used by applications.
Since you are using RH 4.2 or above, the PAM modules will
automatically adapt to the change from using normal
/etc/passwd to shadow passwords without any other change.
Since you are interested in securing your passwords, perhaps you would also be interested in generating good passwords to begin with. For this you can use the pam_cracklib module, which is part of PAM. It runs your password against the Crack libraries to help you decide if it is too easily guessable by password cracking programs.
Answer:
1.Get the latest version of SSLeay from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL
2.Build and test and install it!
3.Get the latest version of the Apache source
4.Get Apache SSLeay extensions from ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz
5. Unpack it in the apache-1.2.5 source directory and patch Apache as per the README.
6.Configure and build it.
You might also try http://www.replay.com which has many pre-built packages, and is located outside of the United States.
Answer: The Red Hat distribution, especially RH5.0, contains a great number of tools to change the properties of user accounts.
pwconv(8) and unpwconv(8) programs can be
used to convert back and forth between shadow and non-shadowed
passwords.
pwck(1) and grpck(1) programs can be used
to verify proper organization of the passwd and group files.
useradd(8), usermod(8), and
userdel(8) can be used to add, delete and modify user
accounts. The programs groupadd, groupmod, and groupdel will do the
same for groups.
gpasswd(1)./etc/shadow for password information, otherwise it won't.
See the respective man pages for further information.
Answer: I bet you didn't know about http://www.apacheweek.org did you?
You can find information on User Authentication at http://www.apacheweek.com/features/userauth as well as other web server security tips from http://www.apache.org/docs/misc/security_tips.html
Any shell script set to run as root can gain unauthorized root access to ordinary users. It is therefore disabled in the kernel from operating. The details about how one can break a setuid shell script are posted regularly on Usenet. Set-User-ID programs are one of the most common methods of intrusion, especially by means of buffer overflow.
See the UNIX FAQ for more information on how this actually works.