We will discuss the following issues:
The key components of OS security are analyzed feature by feature and then presented in integrated form with the corresponding numerical scores in the comparative security matrix.
General level of security for Linux accounts is approximately the same as for Solaris accounts with the advantage that passwords can be made of more then eight characters (Linux supports MD5 digests). As in other Unixes there is a possibility to create a separate partitions for critical accounts that need additional security. Linux does not support RBAC, but some features of RBAC can be emulated via sudo.
Linux has good support of PAM (Pluggable Authentication Modules) and thus strong authentication. The selection of PAM modules for Linux is even wider then for Solaris and far superior then in AIX and HP UX.
One of the most important account security features are password protection. There are following ways to improve standard Unix passwords-based authentication mechanism in Linux:
Requirements specified in BASF Unix account policy and UNIX Configuration Best Practice Guidelines can be satisfied both in Red Hat and Suse.
The most sought-after account on any Unix box is the root (superuser) account. It should be protected from remote exploits as much as possible (no direct remote login, etc).
Linux provides an extensive set of filesystems mounting attributes and can mount filesystem as read-only and NOSUID. Still virtualization capabilities are very rudimentary and here Linux is behind leading commercial Unixes (AIX and Solaris). That diminishes the level of security of applications achievable in Linux and make is less desirable for usage in DMZ outside of the domain where it is industry proven (webservers). In case higher level of security is needed deployment of Linux under VMware is recommended.
It's important to ensure that your system files are not open for casual editing by users and groups who are not eligible to modify them. Unix separates access control on files and directories according to three characteristics: owner, group, and other. There is always exactly one owner, any number of members of the group, and everyone else.
Default filesystem for Red Hat (ext3) supports ACL with stock 2.6 kernel. Default filesystem for Suse 9(riesner) support only standard Unix file permissions. Ext3 or XFS filesystems can be used with SUSE if ACL support is essential.
More advanced mechanism like RBAC are not present in current version of Linux, but kernel contain some features (capabilities) that permit their implementation in the future.
SUID shell scripts are a serious security risk, and for this reason the Linux kernel like commercial Unix kernels do not honor them.
The number of SUID root programs in Linux is higher then in Solaris and AIX. For example SVGAlib programs are typically SUID-root in order to access Linux machine's video hardware.
Intruders often either modify, delete, or replace existing files in order to either cover their tracks, assist them in gaining access, or to gather further information. Ensuring the integrity of the files and programs is vital in intrusion detection. SUID and SGID files are a potential security risk, and should be monitored. Because these programs grant special privileges to the user who is executing them, it is necessary to ensure that insecure programs are not installed. A favorite trick of crackers is to exploit SUID-root programs, then leave a SUID program as a back door to get in the next time, even if the original hole is plugged. Several ways to monitor those files exists in Linux:
root# rpm -Va
to verify each file on the system (you need to ensure that RPM data were not tampered. That can be done by writing them to the CD).
Linux uses a single shell (bash) for both root account and for users accounts. That does not create additional vulnerabilities and corresponds to standard practice on Solaris where ksh is usually used for both.
Linux also has Perl, TCP and Python installations enabled by default. This might create additional vulnerabities and access to those scripting languages night generally be regulated
ssh is installed by default in Linux. OpenSSH is a suite of programs used as a secure replacement for rlogin, rsh and rcp. It uses public-key cryptography to encrypt communications between two hosts, as well as to authenticate users. It can be used to securely login to a remote host or copy data between hosts, while preventing man-in-the-middle attacks (session hijacking) and DNS spoofing. It will perform data compression on your connections, and secure X11 communications between hosts.
There are several ssh implementations now. The original commercial implementation by Data Fellows can be found at The ssh home page can be found at http://www.datafellows.com.
The excellent OpenSSH implementation is based on a early version of the datafellows ssh and has been totally reworked to not include any patented or proprietary pieces. It is free and under a BSD license. It can be found at: http://www.openssh.com.
SSLeay is a free implementation of Netscape's Secure Sockets Layer protocol, developed by Eric Young. It includes several applications, such as Secure telnet, a module for Apache, several databases, as well as several algorithms including DES, IDEA and Blowfish.
PAM (the Pluggable Authentication Module) is a unified authentication scheme introduced by Sun in Solaris 2.3 and later reimplemented in most open source versions of Unix (e.g. Linux and FreeBSD). It allows the system administrator to customize the authentication services that should be used for various applications.
The applications (typically login, ftp, dtlogin, ssh and other programs that "log a user in") are built to be aware of the services PAM offers -- ie. the program knows how to get PAM to do the authentication.
In old versions of Unix the authentication code was not modular and was imbedded in login, su, passwd and all the other programs that do authentication. If you wanted to make any change to the database in which passwords were stored, or change the ground rules for how authentication was done, you had to modify and rebuild all those programs.
Both Red Hat Linux and Suse support PAM. PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries.
Linux looks quite competitive with Solaris and has wider selection of PAMs then Solaris. Both of them definitely surpass AIX and HP-UX.
When using xdm (X Display Manager) to log in, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128-bit "cookie" is generated and stored in your .Xauthority file. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide access to only that connection. See the Remote-X-Apps mini-howto, available at http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.
You can also use ssh to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no unencrypted data flows across the network.
You can also disable any remote connections to your X server by using the '-nolisten tcp' options to your X server. This will prevent any network connections to your server over tcp sockets.
Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites on which you wish to run X programs.
The problems with X security on Linux are mainly due to lesser security of its desktop managers Gnome and KDE (especially Gnome).
Linux kernel is generally less well designed and less secure that Solaris kernel or AIX kernel. As the kernel controls your computer's networking, it is important that it be very secure, and not be compromised.
identd is a small deamon that keeps track of what user is running what TCP service, and then reports this to whoever requests it. The identd that ships with most Linux distributions (xnetd) is more configurable than many people think and included the functionality of TCP wrappers. You can disable it for specific IP addresses. You can also log all identd requests
In both Red Hat and Suse they are combined in xnetd diamon.
NFS is a very widely-used file sharing protocol. It allows servers running nfsd and mountd to "export" entire file systems to other machines using NFS filesystem support built in to their kernels (or some other client support if they are not Linux machines). mountd keeps track of mounted file systems in /etc/mtab, and can display them with showmount. Many sites use NFS to serve home directories to users, so that no matter what machine in the cluster they login to, they will have all their home files. There is some small amount of security allowed in exporting file systems. You can make your nfsd map the remote root user (uid=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote root user can login or su to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote file systems. If you must use NFS, make sure you export to only those machines that you really need to. Never export your entire root directory; export only directories you need to export.
Solaris has better NFS implementation then Linux or other commercial Unixes, although IBM AIX implementation is not that bad.
In version 2.6 of the Linux kernel there are some advancements of the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel.
The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks.
It is very important that the information that comes from syslog not be compromised. Making the files in /var/log readable and writable by only a limited number of users is a good start.
Be sure to keep an eye on what gets written there, especially under the auth facility. Multiple login failures, for example, can indicate an attempted break-in.
Where to look for your log file will depend on your distribution. In a Linux system that conforms to the "Linux Filesystem Standard", such as Red Hat, you will want to look in /var/log and check messages, mail.log, and others.
You can find out where your distribution is logging to by looking at your /etc/syslog.conf file. This is the file that tells syslogd (the system logging daemon) where to log various messages.
You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the logrotate package on recent Red Hat distributions. Other distributions likely have a similar process.
If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things appeared to be tampered with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea.
Intruders typically modify log files in order to cover their tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them.
You should also be sure to separate the auth facility from other log data, including attempts to switch users using su, login attempts, and other user accounting information.
If possible, configure syslog to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login/su/ftp/etc attempts. See the syslog.conf man page, and refer to the @ option.
There are several more advanced syslogd programs out there. Take a look at http://www.core-sdi.com/ssyslog/ for Secure Syslog. Secure Syslog allows you to encrypt your syslog entries and make sure no one has tampered with them.
Another syslogd with more features is syslog-ng. It allows you a lot more flexibility in your logging and also can has your remote syslog streams to prevent tampering.
Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what they look like on a normal day. Knowing this can help make unusual things stand out.
Log configuration and log files have the same names and uses in Solaris and Linux. The functionality between the files listed is similar, but the syntax and structure can be different. In some cases, a directory of configuration files is used in Linux where only a single file is used in Solaris. For a more extensive list, refer to the Web site http://bhami.com/rosetta.html.
Comprehensive System Accounting (CSA) provides the ability to track system resource utilization per job and charge back the cost of those resources to users. It is now available as a patch to 2.4.0 kernel This has only been tested on i386 systems. An ia64 version will be available soon.
Linux patching process quality is noticeably worse then on Solaris and access to patches requires maintenance contact. Patches are distributed as updated packages and may involve updating the version of the software although enterprise Linux distributions like Red Hat and Suse are trying to do necessary work to avoid that.
According the U.S. Government’s database of computer security vulnerabilities maintained by the National Institute of Standards and Technology (http://icat.nist.gov) as of April 15, 2004, there have been more High Severity (remotely exploitable) vulnerabilities found in the Linux operating system than in Microsoft Windows. This count removes duplicate reports of the same vulnerability against multiple versions of Linux or Windows. The CERT report claims that security alerts for open source and Linux software accounted for 16 out of the 29 advisories published during the first 10 months of 2002. During those same 10 months, only seven security problems were documented in Microsoft products. NewsFactor Network - - Study Linux' Security Problems Outstrip Microsoft's
An analysis of hacker attacks on online servers in January by security consultancy mi2g found that Linux servers were the most frequently rooted, accounting for 13,654 successful attacks, or 80%t of the survey total. Windows ran a distant second with 2,005 attacks. A more specific analysis of government servers also found Linux more susceptible, accounting for 57% of all breaches. In a similar analysis last year, Windows proved far more vulnerable, with 51% of successful attacks on government servers made on some version of the Microsoft operating system.
However, the rise in successful attacks probably to a large extent reflects a lack of training and deployment expertise rather than inherent security problems in Linux.
Linux currently does not have process protection/virtualization capabilities that are equivalent to Solaris zones or AIX partitions. There are some attempts to replicate the capabilities of BSD jails but they are still in beta.
The number of books devote to Linux security is considerable and by an order of magnitude surpass the number of Solaris books. Red Hat offers four security-related training courses (approximately the same as Sun for Solaris). We judge that in area Linux surpass all other Unixes and trails only Windows.
Most security certification specialists consider Linux less secure that top proprietary Unixes (AIX and Solaris) and that requires running Linux in a special way to augment security (deeper hardening) to compensate for this.
Many people are under the misconception that since Linux has been evaluated under the Common Criteria for IT Security Evaluation (ISO Standard 15408) that Linux must be secure. But here are the facts: Linux has been certified to EAL 3+ and EAL 4 under the Common Criteria. Those are pretty basic certification that tells not much about real-world level of security of the OS. By comparison, Windows has been also certified to EAL 4. Both AIX and Trusted Solaris are capable reaching EAL 7 certification.
The Common Criteria standard states: “EAL 4 is the highest level at which
it is likely to be economically feasible to retrofit an existing product
line.” This means that if a product was not originally designed for security,
it will probably never exceed EAL 4. And as we all know Security was not a
focus of the original design of Linux.
Another widespread misconception that the NSA is going to solve
Linux’s security problems with its Security Enhanced Linux (SELinux). But
this is an urban legend. Here are a few excerpts (http://www.nsa.gov/selinux/info/faq.cfm):
Another security problem is created by the GNU General Public License (GPL) under which Linux is licensed. GPL Section 2b (emphasis added):
“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from [Linux] or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”
That is both a legal problem (due to SCO lawsuit and potential patent-infringement lawsuits) and a cultural problem that can be classified as an implicit threat to the security of any software-based intellectual property developed on Linux. It is recommended to acquire Linux only from the vendors that provide indemnification against legal threats.
Linux run on two types of hardware Classic Intel x86 architecture and EM64T-based CPUs (Intel Nocona or AMD Opteron). EMT64T is a 64 bit extension of classic Intel architecture by AMD also adopted by Intel. Generally hardware cost is the most important potential saving factor in deploying Linux and Opteron architecture is slightly more expensive. But is also slightly more secure, as if the operating system is configured to operate in 64 bit mode it is less susceptible to 32-bit oriented exploits. The latter represent about 90% of all exploits (hackers really test their code on 64 bit systems).
32 bit Intel hardware is the most hacked hardware in existence and is widely available to hackers of any country on the globe. By just switching to 64-bit hardware we can somewhat decrease security risks. The most damaging Linux virus so far, the Slapper worm, infected 20,000 systems in 100 countries in late 2002. That pales in comparison to the most damaging Windows virus, MyDoom and its variants, which infected several million computers in three weeks. But there are orders-of-magnitude more Windows machines deployed.
By just switching to 64-bit hardware we can somewhat decrease hardware-related security risks.
[an error occurred while processing this directive]