| ||
Mandrake has produced an excellent collection of Python scripts that are collectively known as msecthe Mandrake security tools. Msec is a well-designed tool that handles many routine tasks required by certain security practices and can implement many good access restriction policies. However, it can also become an administration nightmare if incorrectly implemented. If you choose to take advantage of msec, realize that it creates a secure environment by defaultnew services may still introduce new vulnerabilities and security patches must still be installed.
Msec is installed by default on all Mandrake Linux distributions. The first encounter with msec occurs during the installation process when you receive the prompt that asks for the level of security you want to use. This level ranges from 0 (no security) to 5 (strict security). Level 3 is probably the best choice because it is easier to increase the level (go to 4 or 5) than decrease a level that you have discovered is too restrictive .
Msec security is defined in the /var/lib/msec/security.conf file. The few entries in this file can be overridden by the /etc/security/msec/security.conf file. The core of msec's utilities exists in the /usr/share/msec directory:
[mike@corrino msec]$ ls cleanold.sh level.0 man.py perm.5 compile.py level.1 man.pyo Perms.py compile.pyo level.2 mseclib.py Perms.pyo ConfigFile.py level.3 mseclib.pyo promisc_check.sh ConfigFile.pyo level.4 msec.py security_check.sh Config.py level.5 perm.0 security.sh Config.pyo libmsec.py perm.1 shadow.py diff_check.sh libmsec.pyo perm.2 shadow.pyo draksec_help.py Log.py perm.3 draksec_help.pyo Log.pyo perm.4
Thus, it is possible to customize the inner workings of msec. Keep in mind that many checks can be extended by the configuration files. It is not advisable to modify these files unless you are comfortable with Python and have a clear goal in mind.
Msec affects many environment variables and file permissions. Consequently, you may notice that even if you manually change the permissions for the /etc/inetd file, msec will silently (although a log entry will be generated) change the ownership to root.root and the mode to 644. The file ownership and permissions are controlled by the perm.0, perm.1, perm.2, perm.3, perm.4, and perm.5 files in the /usr/share/msec directory. Each file suffix (05) corresponds to the current msec level. You can modify these files if you want to add or remove certain entries. Note that if you change the msec level to 4 or 5, you will have to add users to the ntools or ctools user groups to access common network or compiler binaries. For example, Table 9-2 contains a few entries and their settings under levels 3, 4, and 5.
File or Directory | Owner. Group (3) | Perm. (3) | Perm. (4) | Owner.Group (4) | Owner.Group (5) | Perm. (5) |
---|---|---|---|---|---|---|
/usr/bin/ | root.root | 755 | root.adm | 751 | root.root | 711 |
/usr/bin/cc | root.root | 755 | root.ctools | 750 | root.ctools | 750 |
/usr/bin/finger | root.root | 755 | root.ntools | 750 | root.ntools | 750 |
/usr/bin/g++* | root.root | 755 | root.ctools | 750 | root.ctools | 750 |
/usr/bin/gcc* | root.root | 755 | root.ctools | 750 | root.ctools | 750 |
/usr/bin/ssh | root.root | 755 | root.ntools | 750 | root.ntools | 750 |
/usr/bin/telnet | root.root | 755 | root.ntools | 750 | root.ntools | 750 |
/usr/bin/w | root.root | 755 | root.ntools | 750 | root.ntools | 750 |
/usr/bin/who | root.root | 755 | root.ntools | 750 | root.ntools | 750 |
Also found in the /usr/share/msec directory are six files (level.0 through level.5) that define each possible security setting for the corresponding msec level. These are plaintext files with easily understood variables and values. For example, Table 9-3 shows the settings for password management under levels 3, 4, and 5.
Level.n File Entry | Description | Level 3 | Level 4 | Level 5 |
---|---|---|---|---|
enable_password | Yes/No. | Yes | Yes | Yes |
password_aging | Maximum age of a password (days). | 99999 | 60 30 | 30 15 |
password_history | Number of previous passwords to store. Users cannot create a new password that matches one in the history file. |
|
| 5 |
password_length | Minimum number of characters . Minimum number of digits. Minimum number of uppercase letters . | 4 0 0 | 6 1 1 | 8 1 1 |
Most of the remaining settings have either Boolean values (yes or no) or have clear possibilities. For example, set_user_umask accepts a three-digit UMASK value such as 022 or 027.
If you choose to modify the level.n files to define a custom policy, be sure to document changes so that other administrators can understand the impact and implications of each modified setting.
Note | If you read through the man pages carefully , you will discover that the recommended method for modifying the permissions (perm.n) and settings (level.n) for a particular msec level is to create two files: /etc/security/msec/perm.local and /etc/security/msec/level.local. This is the best way to make system-specific changes without corrupting the original msec definitions. |
Tip | Within each of the perm.n files, the asterisk (*) serves as a wildcard to match zero or more characters and the question mark (?) serves as a wildcard to match zero or one character. Thus, /usr/bin/gcc* matches /usr/bin/gcc, /usr/bin/gcc-3.2.2, and /usr/bin/gcc3.2-version. The string /usr/lib/rpm/rpm? matches /usr/lib/rpm/rpm, /usr/lib/rpm/rpmb, /usr/lib/rpm/rpmd, and so on. |
Now that we've covered some of the specific point tests that msec performs , let's take a look at security checks controlled by the security.conf file. Each test, described in Table 9-4, is performed on a periodic basis.
Setting | Default (Level 3) | Description |
---|---|---|
CHECK_SHADOW | Yes | Verifies that no user has an empty password in the /etc/shadow file. |
CHECK_SUID_MD5 | Yes | Verifies the checksums generated for each suid and sgid file. Checksums are generated daily. |
CHECK_UNOWNED | No | Checks for unowned files. If the UID of a file's owner or group does not exist in the /etc/passwd file, it is considered unowned. Files with nobody UID or nogroup GID are also considered unowned. |
CHECK_SECURITY | Yes | Performs daily security checks. This entry triggers all other entries. If this is set to No, other checks will not be performed. |
CHECK_PASSWD | Yes | Verifies that no user has an empty password in either the /etc/passwd or /etc/shadow file. Also checks for accounts other than root with UID 0. |
SYSLOG_WARN | Yes | Sends all reports to syslog. |
CHECK_SUID_ROOT | Yes | Checks for new or removed suid root files. |
CHECK_PERMS | Yes | Checks file permissions in users' home directories. |
MAIL_EMPTY_CONTENT | No | Mails a report even if nothing has changed from the previous time msec tests were performed. |
CHECK_WRITABLE | Yes | Checks for world- writeable files ( o+w ). |
CHKROOTKIT_CHECK | Yes | Performs root kit checks. The chkrootkit application must be installed in the /usr/sbin directory (http://www.chkrootkit.org). Note that chkrootkit can identify the default configuration of most root kits, but many root kits can be trivially modified to avoid detection. This is by no means foolproof! |
CHECK_PROMISC | No | Checks if the network device(s) are running in promiscuous mode. Runs the /sbin/ip link list command to check for the PROMISC flag on an interface. This is reliable, but the PROMISC flag can be suppressed by certain root kits. |
CHECK_SGID | Yes | Checks for new or removed SGID root files. |
RPM_CHECK | Yes | Checks the RPM database's integrity and monitors whether any files have been modified. |
TTY_WARN | No | Sends reports to the TTY. |
MAIL_WARN | Yes | Sends reports to an e-mail address. |
CHECK_OPEN_PORT | Yes | Checks for open ports with the netstat command. This tests for ports that have been opened or closed compared to the previous time the test was performed. |
Check the /var/lib/msec/security.conf file for the default settings at your particular msec level.
Msec writes information to syslog, which typically goes to the /var/log/messages file. You can watch this file for msec output. Log entries may be indicative of RPM upgrades that replaced system files and applied incorrect permissions, the ownership of logfiles changing due to different utilities writing to them, or possibly malicious activity. Hopefully, the results will be innocuous , as shown by the logfile in the following example. The changes in this logfile merely remove the world-readable bit from the logfiles and change their group ownership to adm (the administrators). A change from world-writable would have been immediate cause for alarm, as might a change of file ownership from any nonroot user to root.
Sep 21 18:01:03 host msec: changed mode of /var/log/wtmp from 664 to 640 Sep 21 18:01:03 host msec: changed group of /var/log/wtmp from utmp to adm Sep 21 18:01:03 host msec: changed mode of /var/log/ksyms.1 from 644 to 640 Sep 21 18:01:03 host msec: changed group of /var/log/ksyms.1 from root to adm Sep 21 18:01:03 host msec: changed mode of /var/log/ksyms.0 from 644 to 640 Sep 21 18:01:03 host msec: changed group of /var/log/ksyms.0 from root to adm Sep 21 20:01:02 host msec: changed mode of /var/log/XFree86.0.log from 644 to 640 Sep 21 20:01:02 host msec: changed group of /var/log/XFree86.0.log from root to adm
If you choose to rely on msec for security monitoring of your host, then it is extremely important to realize its deficiencies. While msec runs comprehensive checks of user and file system settings, it does so on a periodic, predictable basis. Problems, or compromises, may not become apparent until hours later when msec performs a particular check. The msec checks also rely on user-space utilities, which means that more sophisticated kernel Trojans and root kits will easily fly under the msec radar. This information shouldn't deter you from running msec in an advanced security mode. Like all security tools, msec is not a panacea for any type of compromise. It can be used to good effect to minimize administration mistakes and catch unsophisticated hackers, but not a focused attack.
| ||