Sendmail now will check for obvious configuration errors when it starts up and will refuse to operate until the poor configuration is fixed or if you set the "dontblamesendmail" flag. This is a very clever solution to allow someone who really wants to - and presumable knows what he is doing or has a death wish - to disable Sendmail's minimum security checks. Yet, one hardly could set this flag accidentally.
Most of the major subsystems that come with Linux, such as Sendmail, the Apache web server, and the Samba file server come with abundant documentation and default configuration files that usually need just a tiny bit of tweaking to help you configure the subsystem correctly.
Some programs cannot be made secure and must not be used, no way, no how. Heading this list is NFS and its cohorts, portmap, and the Sun Remote Procedure Call (RPC) library that still are turned on by default on some Linux Distros. Unless NFS and portmap are thoroughly protected with firewalling, they should not be used. Period. Number two on the list is PHP. I realize that many web sites have lots of time invested in PHP but I'm sorry, it continues to have security bugs discovered frequently and these affect even those using it "properly". Find another solution or risk being hacked. I have dealt with such a likely hacked site as recently as last week.
These days, most systems other than mail servers do not receive email via SMTP (TCP/IP port 25). Thus, please do not allow Sendmail to listen on port 25. This is done by not including the "-bd" when invoking Sendmail. For Red Hat and Mandrake, edit the /etc/sysconfig/sendmail file and change:
and restart sendmail with the command:
If you really do not want to have to blame Sendmail, use Postfix instead and turn off Sendmail's set-UID bit and run it set-GID to a dedicated group instead to prevent someone else from taking advantage of its next vulnerability to be discovered. Note that Postfix is standard on SuSE now.
It Is Better To Ask Forgiveness Than Give Permission
The fourth key to keeping your Linux system secure is to use the most restrictive file permissions that you can that still allows it to operate normally. Number one here is to ensure that almost no files (including most directories and device files) have world write permission. Do not trust your Distro to have done this -- most get it wrong. I do the following to check for world-writable files:
find / ! -fstype proc -perm -2 ! -type l -ls > find.log
Exceptions to the no world write access include the /tmp/., /var/tmp/., and /usr/tmp/. directories that have permissions of 1777 and tty devices. Do not even grant world read permission normally to files whose contents are confidential or group permissions unless it makes sense to do so.
It also is important to disable programs that have their set-UID or set-GID bits set if they are not needed. This is because if a hacker can get non-privileged access, say by cracking a user's password by brute force guessing, he may be able to become root by taking advantage of a vulnerability in a program that is set-UID to root. This can be done by invoking the following commands:
find / ! -fstype proc -perm -4000 ! -type l -ls > find_uid.log
find / ! -fstype proc -perm -2000 ! -type l -ls > find_gid.log