Linux Server Security

News	Unix Security	Recommended Books	Recommended Links	Softpanorama Laws of Computer Security	Red Hat security	Suse Security	Linux Hardening
Seccheck	TCP Wrappers	PAM	Unix Access Control Lists (ACL)	wheel group	Apparmor	Integrity Checkers	Intrusion Detection
Linux root password recovery	Access Control	VMware	Virtualization	RPMs	SecurId	Humor	Etc

There is many common aspects in security infrastructure of Suse and Red Hat. The main differences are on the level of deferent security infrastructure (Recently Suse adopted Red Hat model in additional to its native AppArmor) as well as different daemons (ftpd, syslogd, etc)

Among elements of security infrastructure that are sufficiently close.

ACL
PAM
TCP wrappers

The TCP Wrappers package (tcp_wrappers) is installed by default and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP-wrapped service is one that has been compiled against the libwrap.a library.

When a connection attempt is made to a TCP-wrapped service, the service first references the host's access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages.

If a client is allowed to connect, TCP Wrappers release control of the connection to the requested service and take no further part in the communication between the client and the server.

In addition to access control and logging, TCP Wrappers can execute commands to interact with the client before denying or releasing control of the connection to the requested network service.

Because TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Red Hat Enterprise Linux are linked to the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.
Firewall

Among elements of security infrastructure that are different

Syslog daemon
Apparmor (suse only)

Notes:

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Google Search
Open directory	Research Index

Old News ;-)

[Oct 31, 2009] 20 Linux Server Hardening Security Tips

Nothing special but still not completely useless... Demonstrates average level of misunderstanding of security

Securing your Linux server is important to protect your data, intellectual property, and time, from the hands of crackers (hackers). The system administrator is responsible for security Linux box. In this first part of a Linux server security series, I will provide 20 hardening tips for default installation of Linux system.

freshmeat.net Project details for Lynis

Description

Security and system auditing tool

Project information
Lynis is an auditing tool for Unix (specialists). It scans the system configuration and creates an overview of system information and security issues usable by professional auditors.

This software has not the intention to be an all round solution for creating a "safe system", but to assist in automated audits. The software can be used in addition to other software, like security scanners, system benchmarking and finetuning tools.

Intended audience: security specialists, system auditors, system/network managers

Current state:
Stable releases are available, development is still in progress.

Components:
-----------------------
Changelog - Present in tarball
FAQ - Present in tarball
Logging support - Builtin
Report creation - Builtin
Man page - Present in tarball
Readme - Present in tarball
System requirements:
- Compatible operating system (see 'Supported operating systems')
- Default shell
Supported operating systems
Tested on:
- CentOS 5
- Debian 4.0
- Fedora Core 4
- FreeBSD 6.2
- Mac OS X 10.4
- OpenBSD 4.2
- OpenSuSE

Currently unsupported:
- All others (though some will work)

(did it work on your operating system? Let me know!)

Chapter 8. Basic Security

[PDF] SLES Security Guide (1993)

Linux system auditing by example by Emily Ratliff

A case study in scripting for system audit compliance

30 Apr 2007

Think you have a secure Linux® system? Following best practices during installation and setup is a must, but if you haven't set up regular system auditing, you're missing half the picture. This article discusses some existing tools and offers a couple of sample scripts to automate the process in a real-world environment.

Many articles and books have been written on how to install a secure Linux system. But once the system has been installed to meet security requirements, only half the battle is won. The second half involves ensuring that the system continues to meet its security requirements throughout its lifetime (and that you can prove it). This means that periodic system auditing is required to make sure that nothing goes wrong.

System audit requirements

The security requirements that you verify during routine system auditing should be the same requirements and security principles that guide the system installation. The three-part developerWorks series "Securing Linux" gives you an introduction on how to install a reasonably secure Linux system. Regular system auditing will also help refine the security policy used for new machine installations as it helps close the feedback loop on what subsystems are actually in use.

The first tools for meeting these requirements are system auditing and host-based intrusion detection. This article focuses on system auditing. Host-based intrusion detection systems such as tripwire, AIDE, and Samhain detect when changes have been made to the file system and are therefore critical tools for ensuring that the system retains its known state. The Linux Gazette has an interesting article, "Constructive Paranoia," on using these tools (see Resources section below for a link).

This article focuses specifically on the practical aspects of periodic system auditing based on real-world requirements from a system administrator of a subnet in a large academic network. The lessons learned by this administrator apply to everyone from business intranets to home users who want to prevent their home machine from becoming a zombie in the bot army. The administrator's system is required to undergo periodic, random system audits, during which routine audit activities (such as showing that the audit and system logs are regularly reviewed, and checking for user accounts that have lapsed), In addition, the administrator also has to address the following:

Justification for suid/sgid executables that are on the system and why they are suid/sgid

Proof that no file system with a world writable directory (/tmp and /var/tmp) has any suid/sgid files

Open ports and the impact of firewalling off of those ports

What are all those suid files for?
Identifying the suid and sgid files on your system — and disabling the unnecessary ones — is one of the fundamental rules of installing a secure system. This task is so common that the man page for find lists the parameters for this in its examples. Listing 1 is a script that executes the typical find command and also helps answer the question of what the suid file does and what package it belongs to, in order to help the administrator to identify it, and decide if it should stay on the system or be removed. (You can download the code for Listings 1, 3, and 4 from the zip file in the Download section later in this article.)

Listing 1. Abbreviated sample output on suid/sgid files
                
[root@localhost hpc]# ./find_setuids.pl /
04755 root /usr/X11R6/bin/cardinfo
       cardinfo - PCMCIA card monitor and control utility for X
pcmcia-cardinfo-3.2.7-107.3

04755 root /usr/bin/opiepasswd
       opiepasswd -  Change or set a user's password for the
       OPIE authentication system.
Opie-2.4-544.1

04755 root /usr/bin/opiesu
       opiesu  -  Replacement  su(1)  program that uses OPIE challenges
opie-2.4-544.1

04755 root /usr/bin/sudo
       sudo - execute a command as another user
sudo-1.6.7p5-117.4
Which file systems contain world writable directories?

As an administrator, you might be interested in world writable directories to meet the requirement that all user-writable file systems be mounted with the nosuid attribute. User-writable directories include users' home directories as well as any world writable directories. This requirement is in place to prevent users from creating suid executables that another user or administrator might inadvertently execute. However, if a legitimate suid executable is on the same file system as a world writable directory and is thus mounted nosuid, the suid bits are ignored and the executable will not operate correctly. You might consider implementing this restriction on your multi-user systems as well.

The script in Listing 1 also tests each regular file system for world writable directories and reports whether the file system contains a world writable directory at the end of the output. For each suid/sgid file, it also reports whether the file is on a filesystem that contains world writable directories.

Abbreviated example output on world writable directories:
/ Contains both suid/sgid files and world writable directories.

What network ports does the system use and for what purpose?

There are several ways to detect which ports are in use on your system. Nmap, netstat, and lsof are the most helpful tools.

Nmap is an extremely flexible tool that can do active and passive scanning of remote (and local) systems.

Netstat shows the network information about the local system. By default, it shows open connections.

Lsof lists open files on the system. It can be used to get information about port usage because it also shows information about network sockets.

Kurt Seifried maintains a listing of 8,457 commonly used ports. (A link to his ports list is in the Resources below.) You can use this data to help explain what the port is being used for and what the impact would be of firewalling it off. He includes information about ports that are commonly used for trojans and root kits; for example, 31337 is commonly used by Back Orifice and 12345, 12346, and 20034 are used by netbus.

Listing 2 contains a script that uses lsof and netstat to show the system's current port usage in an easily readable format.
Listing 2. Sample output from port_scan.sh:
                
[root@localhost hpc]# ./port_scan.sh
  please wait...
PORT              SERVICE         LINK
22                sshd
http://www.seifried.org/security/ports/0/22.html
25                sendmail
http://www.seifried.org/security/ports/0/25.html
123               ntpd
http://www.seifried.org/security/ports/0/123.html
631               cupsd
http://www.seifried.org/security/ports/0/631.html
46336 <-> 22      ssh             **
     
In Listing 2, the low-number ports (<1024) indicate daemons running on the system that accept incoming communication unless firewalled off. The high-number port 46336 shows an outgoing ssh connection and the port (22) that it is connected to on the other end. This means that blocking outbound communication on ephemeral ports will break commonly used client programs such as ssh. See Kurt's ports list in Resources for more details on the effects of firewalling the higher-number ports.
These scripts and tools show port usage at a point in time. The audit subsystem can be used to find out which ports have been used (for the duration of the audit log files) even if they are not currently in use. Adding the following audit rule to /etc/audit.rules will log calls to bind.

-a entry,always -S socketcall -F a0=2

The parameter -a entry,always indicates that the rule should always be invoked at the beginning of the system call execution. The -S socketcall indicates that this audit rule is for the socketcall syscall. The socketcall syscall is multiplexed on the i386 architecture, so the -F a0=2 is required to limit the audit records generated to bind only.

Other architectures handle the bind system call differently, so these commands and scripts will have to be altered slightly to handle architectures other than i386. Audit events are recorded as multiple audit records that are correlated by a shared serial number. ausearch will correlate the related records using the serial number and present them as a group. The -i flag requests that numeric values, indicating, for example, that saddr (IP address) and uid (user name) be translated to human readable text when possible.
Listing 3. Abbreviated output from ausearch
                
# ausearch -i -sc socketcall
Abbreviated example output
----
type=SOCKETCALL msg=audit(11/20/2006 11:28:43.844:10) : nargs=3 a0=0
a1=b8004004 a2=10
type=SOCKADDR msg=audit(11/20/2006 11:28:43.844:10) : saddr=inet
host:127.0.0.1 serv:631
type=SYSCALL msg=audit(11/20/2006 11:28:43.844:10) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfffaca0 a2=b8000664
a3=1 items=0 pid=3340 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=cupsd
exe=/usr/sbin/cupsd
----
type=SOCKETCALL msg=audit(11/20/2006 16:40:46.169:16) : nargs=3 a0=6
a1=b8056720 a2=10
type=SOCKADDR msg=audit(11/20/2006 16:40:46.169:16) : saddr=inet
host:192.0.34.166 serv:123
type=SYSCALL msg=audit(11/20/2006 16:40:46.169:16) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bffff9a0 a2=b80004a8
a3=6 items=0 pid=3523 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpd
exe=/usr/sbin/ntpd
This output shows that each call to bind generated three audit records. The first record type is the SOCKETCALL record, which shows the number and value of the arguments passed to bind on entry. The second record type is the SOCKADDR record, which shows the host by IP address and the port used. The third record type is the SYSCALL record, which shows whether the call to bind was successful, the arguments upon exit, gives the process ID, file executed, and shows the effective and real user and group information of the process that made the call. For our purposes, we are interested mostly in the serv: part of the SOCKADDR record, which documents the port used and the exe= field of the SYSCALL record, which documents the program that made the call to bind.
Listing 4 contains a simple script using sed and awk to compress the output of ausearch down to only the non-duplicated (time omitted) executable and port number fields.
Listing 4. Sample output from auportprint.sh:
                
[root@localhost hpc]# ./auportprint.sh
22      /usr/sbin/sshd
123     /usr/sbin/ntpd
123     /usr/sbin/ntpdate
631     /usr/sbin/cupsd
Conclusion

This article introduced some tools and techniques that can help you maintain your system's adherence to its security policy. It also gave you some simple scripts to help parse system data into an easily readable format that can help you prove the security status of the system quickly and easily to anyone less familiar with the tools and system. I hope that you can use these simple tools and techniques to create your own scripts to periodically test the security stance of your systems.

Acknowledgments

Many thanks to Kylene Hall, Dustin Kirkland, Flavio Ivan da Silva, Rodrigo Rubira Branco, and Flavio C. Buccianti for their code, suggestions, and hard work on this article.

[Jan 06, 2004] Managing Linux Security Effectively in 2004 By Benjamin D. Thomas

This article examines the process of proper Linux security management in 2004. First, a system should be hardened and patched. Next, a security routine should be established to ensure that all new vulnerabilities are addressed. Linux security should be treated as an evolving process.

Introduction

As Linux continues to gain popularity in the business world, security issues are something that cannot be ignored. In 2003, several well known Linux distributors had servers compromised. In one particular case, the vulnerability was well known in advance, but most vendors took entirely too much time to release an update. Similarly, most security problems that users face are known well in advance. As with any system, security on Linux is a process. It requires full commitment and due diligence. The secret is determining your own vulnerabilities and fixing them before anything catastrophic happens.

Although Linux security is entirely in the hands of system administrators, several improvements have been made at the kernel level. With the release of kernel version 2.6, users will now be able to take advantage of the Linux Security Module allowing greater levels of security customization, modularization, and ease of management. Another thing that has changed in the past several years is that today more of us are reliant on automated software update services. Rather than download and install patches manually, it is now easier to subscribe to a trusted source and let the system manage itself. As long as the integrity of the trusted source remains strong, automated management works flawlessly. As soon as something questionable happens, it is necessary to re-evaluate.

Solve the Problem

Addressing Linux security is like solving any problem. It must be approached with a purpose and plan. If you have been using Linux and neglecting security, it is now time to face it head on. Although the task may seems daunting in the beginning, it will soon be apparent that securing a Linux system is actually very strait forward.

In general security can be summed up into several steps. First, live by the minimum necessary rule. For example, turn off all unnecessary services, remove all programs that are not being used, and only give access when it is absolutely critical to a particular job function. Taking this simplistic approach will not only increase security, but over time will make life easier. It will eventually mean less stale-accounts to remove, less software to patch, and greater system performance.

Next, keep a software inventory of all versions used. Use this information to conduct the research necessary to ensure that all have been patched appropriately. Doing this, will greatly reduce the risk of being compromised by a known vulnerability. As simple as it may sound, doing this will make the system no longer an easy target, therefore be much less likely compromised. Unless the attacker is highly motivated highly sophisticated a hardened system will not be appealing.

Because most organizations have tens to hundreds of systems to manage, living by the minimum necessary rule, and establishing a security patch baseline is not always easy. The only way to approach Linux security is by developing a detailed plan. If server roles can be modularized, it may be much easier to determine what software is actually necessary for operation. Similarly, if multiple Web servers are on the network, they should all have the same basic set of software which again makes management easier. Planning for security, rather than trying to bolt it on after implementation is the key to success.

Setup a Routine

After a security plan is established and well underway, it also necessary to have a security routine. Security patches are released daily and your organization must have a way to deal with these. Hardening a system will only ensure a high level of security a single point in time. As time moves forward and vulnerabilities are discovered and exploits are made public, the system will become more vulnerable each day. To address this, it is necessary to monitor mailing lists, subscribe to our newsletter Linux Advisory Watch, or subscribe to an automated patch management system. When evaluating Linux distributions, it is important to take into account the frequency, timeliness, and reliability of security updates. Unfortunately, some distributions have been known to only release updates every several months in inconsistent intervals. Others are very good and release patches very soon after the vulnerability is known.

Some may wish to apply security updates daily, but it is probably more reasonable to apply them weekly. Of course, exceptions should be made for very critical updates. If production servers are going to be updated, it is advisable to first try them out in a testing environment. This is to minimize any damage that a flawed patch may cause. Also, do not forget to check the MD5 checksums of all downloaded patches. This can be done easily using the command-line tool 'md5sum.' To ensure overall system integrity, it is beneficial to a tool such as tripwire.

Being the new year, it is now the best time to establish a routine. Excuses can always be made, but now is the best time to start. Determine what is necessary to keep your systems operating securely, and pick a day each week to devote to this. Time should be spent applying security patches, reviewing logs, reviewing active user accounts, and looking for anomalies. Devoting just a little time specifically security each week can make a huge difference. It is always better to address problems before they crop up.

Concluding Remarks

Security requires both dedication and commitment. 2004 can be a good year if you expect security problems and then develop specific plans to address each of them. After the basics have been addressed, now is the time to establish a routine that will ensure security is addressed on a reoccurring basis rather than waiting for problems to surface. To maintain proper Linux security, it must be a regular part of an organization's operational maintenance. Being the beginning of a new year, it is now the perfect time to establish routines that will promote greater security. Linux is a wonderful operating system and holds a huge amount of potential. Security should not be major concern as long as it is handled properly.

Benjamin Thomas is a long time contributor to
LinuxSecurity.com and EnGarde Secure Linux.

Linux Today - Linux Vs. Windows CeBIT Panelists Weigh The OS

Linux Vs. Windows: CeBIT Panelists Weigh The OS
May 28, 2004, 21 :15 UTC (6 Talkback[s]) (3388 reads)
(Other stories by Jacqueline Emigh)

By Jacqueline Emigh
Linux Today Correspondent

Do Linux security exploits really belong in the same league as Windows security holes? Are OpenOffice and its derivatives actually as good as Microsoft Office? These are just a couple of the questions debated this week by a panel of experts at the CeBIT America show in New York City.

Comparing Linux and Windows security amounts to a "chicken and egg" issue, according to Kathy Ivens, an author and consultant.

Given that Linux is a more secure environment, it's tough to know whether this is because Linux is "inherently more secure," or because Windows is still the more prevalent environment, Ivens said, during a panel moderated by Paul Gillin, VP of Editorial at TechTarget.

Also during the session, Nicholas Petreley, an analyst and consultant at Evans Data, contended that regardless of the numbers of exploits per platform, Windows exploits are often much more severe. Citing materials produced by Microsoft itself, Petreley said that many of the growing population of worms targeting Windows let outside hackers "completely take over" a server.

In contrast, Linux exploits are generally more limited in scope, and more likely to lend themselves to insider attacks, Petreley suggested. One Linux exploit, for instance, permits information in Firebird servers to be overwritten.

Generally speaking, though, Windows is still easier to administer, according to several of the panelists. "That's where Linux is behind, especially in directory services," Petreley observed.

Jon "Maddog" Hall, president and executive director of Linux International, pointed to third-party tools, available from vendors such as IBM and Computer Associates (CA), for managing Linux along with MVS and Unix, for example.

"In enterprise environments, that's what (you're) looking for," said Hall. Yet, he admitted, companies need to pay for such tools.

"(Administrative) controls are a lot better (in Windows)," Ivens asserted, citing printer set-up as one example.

Meanwhile, other panelists pointed to freely available Linux tools such as Samba.

What about Linux on the desktop? OpenOffice and its derivatives lack some of the features of Microsoft Office, according to Mark Minasi, a writer and consultant

Petreley, though, argued that EI (Evermore Integrated) Office, an office suite from Evermore Software, contains a similar feature set to Microsoft Office. Unlike Microsoft Office, however, EI Office doesn't allow anti-aliasing of fonts, he acknowledged, attributing this distinction to a decision by authors of the Java-based program to reduce overhead. EI Office runs on both Linux and Windows.

OpenOffice types of suites also tend to come with fewer fonts, indicated Hall. One rather obvious reason is that some font creators charge for the fonts, according to Hall.

On an overall basis, Linux applications still lack the "fit and finish" of Windows apps, Minasi charged. To gain more traction on the desktop, Linux needs a better GUI, he insisted.

Ivens, however, argued that GUIs aren't necessarily the way to go for all applications. In fact, some database and accounting apps have actually taken performance hits from the advent of the Windows GUI.

"There's no reason to have a GUI to punch in numbers," Ivens said. She harkened back to the days when the MAS 90 accounting system was at its zenith. Back then, MAS 90 was sold in Unix and DOS flavors. "My clients loved it," according to Ivens.

Ivens would also like to see fewer features in today's office suites. Microsoft Office, she quipped, seems to be evolving under an illusion in Redmond that "everyone in the world is collaborating on a single document."

Yet most users take advantage of only a small fraction of Office features, and migration to Microsoft Office 2003 has been particularly slow, Ivens observed.

In terms of third-party desktop applications, Linux is now starting to catch up with Windows, panelists generally concurred. Quicken, for instance, is now available for Linux, said Hall.

Desktop gaming, however, is one area where Linux still lags, according to Petreley. Yet with increasing improvements to game consoles such as Game Cube, more consumers are migrating from Windows-based PC games to consoles.

On the other hand, Windows doesn't necessarily hold much of an edge when it comes to ease of installation, according to the CeBIT panelists. Many users don't know how tricky Windows can be to install, since Windows still comes pre-installed on most PCs, members of the CeBIT audience were told.

Hall said that he'll be more than happy if Linux ultimately captures 30 percent of the desktop space.

"Competition is good," he declared. Hall reasoned that, as a result, no operating system -- not even Linux -- should totally dominate any market.

Linux Today - Builder AU Oracle to Switch Its Programmers to Linux

"Oracle will finish switching its 9,000-person in-house programming staff to Linux by the end of 2004, the database powerhouse said Wednesday.

"In October, the company finished the Linux transition for the 5,000 programmers of its Oracle Applications software. Now the transformation has begun for those who work on the database product, said Wim Coekaerts, director of Linux engineering, in an interview at the CeBit trade show in New York..."

IT-Analysis.com - IBM's Linux Push

With the release of Linux version 2.6, Linux scalability has leapt to the point where it will support deployment on 32-way SMP machines. IBM sees this, rightly in my opinion, as an opportunity to sell Linux based solutions into an area of usage from which it had previously been excluded. This means big ERP, CRM and SCM implementations (using SAP, PeopleSoft et al). It also means big database implementations and big app server implementations. This is also an area where the 64-bit implementations of Linux will deliver value.

According to Adam Jollans, who is part of IBM's Linux Marketing Strategy team, the adoption of Linux is happening most quickly in Banking, Government and Retail, followed by sectors that use scientific or engineering applications (automotive, pharmaceuticals, life sciences, education etc.) This is unusual in some respects as the Banking industry is normally an early adopter of technology whereas Government is normally a late adopter, but these two sectors appear to be driving Linux adoption along with Retail.

Government qualifies as a special case, since many governments now see in Linux the possibility of stimulating a local IT software industry and are doing what they can to stimulate the growth of Linux skills. And naturally, IBM is doing what it can to associate itself with many of these initiatives, having set up competence centres in Moscow, Beijing and Romania and offering support for Linux based government initiatives wherever it can.

IBM is also active in stimulating Linux adoption among ISVs and Business Partners, offering incentives to migrate to Linux, which vary from market development funding and marketing assistance to big discounts on IBM Linux-based software. This is not so much a new initiative, as IBM has been enabling the Linux community for many years now, just a more aggressive push than before.

IBM also has many developers working on Linux and other key Open Source projects. Currently the count is at about 500, which if you think about it, represents a large on-going investment. However, there can be little doubt that IBM is getting an adequate return, and in any event it has another axe to grind.

IBM's "On Demand" initiative will be far more likely to deliver results if a single standard operating system emerges in the coming years. As far as I can tell, this looks likely to happen and it will be the horse that IBM is so clearly backing; Linux.

Linux Today - IT-Analysis Linux To Become A De Facto Standard

IBM, Hewlett-Packard and Sun Microsystems, among others, are creating an imperative. Their infrastructure initiatives, entitled respectively; On Demand, Adaptive Enterprise and N1, are all quite similar and aimed at the idea of virtualising the hardware layer. The primary reason for wanting to virtualise hardware is this; in the last five years or so companies have been buying servers in an ad hoc manner, tending to deploy them on a one server per application basis.

Consequently, they assembled server farms which turn out to have an average hardware utilization of about 20 percent. This is, of course, a waste of money and, in the long run, a management headache. However there are other imperatives, particularly the idea of being able to provide infrastructure as a service - dynamically, i.e. you pay for what you use and you get what you need when you need it.

So companies, especially large companies, are very receptive to the idea of corporate computer resource that is both managed and efficient - which is what IBM, HP and Sun are talking about. However, if you talk the talk you are also going to have to walk the walk, and right now, what can be delivered doesn't amount to wall-to-wall virtualisation - or anything like it.

So the question is: How is it ever going to be delivered - given legacy systems, existing server farms and the enormous difficulty involved in relocating applications in a heterogeneous network.

Blade technology, grid computing, automatic provisioning, SANs, NAS and so forth will play a part in this, but for it to work, and work well, it will require a standard OS - and there is only one candidate - Linux.

The easiest way to see the need for a standard OS is to consider why and how TCP/IP became a standard. It didn't happen because it was the best option or because it was purpose designed to run a world-wide network with hundreds of millions of nodes (it wasn't). It happened because it was the only reasonable choice at the time. The same is now true of Linux as regards hardware virtualisation. Irrespective of its other qualities, it is the only one that fits the bill.

It qualifies because it spans so many platforms - from small devices up to IBM's zSeries mainframe. It also qualifies because, like TCP/IP, it doesn't actually belong to anyone. It runs on most chips and is rapidly becoming the developer platform of choice. So the idea is starting to emerge that you virtualise storage by the use of SANs and NAS and you virtualise server hardware by the use of Linux - thus making it feasible to switch applications from one server to another automatically, and quickly. Within this capability you can cater for failover and make highly efficient use of resources.

This doesn't solve all the problems of virtualisation - and there are many, including legacy hardware that will never run Linux and legacy applications that will never run on Linux. But this doesn't actually matter. In the short run they'll get excluded from virtualisation and in the long run, they cease to exist.

The momentum is building and Linux is set to become the standard OS for hardware virtualisation in large networks. Other OSes may eventually have to impersonate the characteristics of Linux or move aside.

[Nov 15, 2002] NewsFactor Network - - Study Linux' Security Problems Outstrip Microsoft's

Open source software has surpassed Microsoft software in terms of security problems, according to an Aberdeen Group report.

"Open source software, commonly used in many versions of Linux, Unix, and network routing equipment, is now the major source of elevated security vulnerabilities for IT buyers," the report stated.

The research cited a list of advisories published by the Computer Emergency Response Team (CERT), a federally funded research and development center operated by Carnegie Mellon University.

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.

Trojan Horses and Viruses

Microsoft applications have made significant progress in avoiding virus and Trojan horse problems, according to CERT. The number of such advisories peaked in 2001 at six, but none were posted during the first 10 months of 2002.

Virus and Trojan horse advisories for Unix, Linux and open source software went from one in 2001 to two in the first 10 months of 2002.

To fully understand these figures, it is important to understand CERT's criteria for issuing an advisory, Aberdeen Group research director and report co-author Eric Hemmendinger told NewsFactor.

For example, although several viruses that affect Microsoft products have been reported this year, such threats need to reach a certain severity level before CERT will issue an advisory in response to them, he said.

New Poster Child

"Obviously, the label of poster child for security glitches moved from Microsoft to the shoulders of open source and Linux product suppliers during 2002," the Aberdeen research stated.

Hemmendinger said the greater number of security vulnerabilities in open source was connected to problems with quality assurance testing. "While there are multiple distributors of open source products, there is no single entity responsible for quality assurance or for addressing security issues," he said.

Popular Misconception

Hemmendinger noted that the CERT findings run counter to what he sees as a popular misconception: that Microsoft software suffers the most security problems.

He said that network administrators trying to assess Microsoft versus open source platform strategies "need to set aside everything you've heard over the last year and look at what the numbers actually show. Perception does not match reality."

Rationale for Change

One reason for the decreased number of Microsoft security problems may be "the beginnings of an impact of efforts Microsoft has made to improve coding practices," Hemmendinger said.

He noted that not only has Microsoft made security a major push this year, "but there have been a number of things that have gone on [in Microsoft] over the last couple years reflecting that they know security matters, and that they had to pay attention to it."

Future of Open Source

Hemmendinger predicted even more security advisories will be released for open source products in the future, while the number of Microsoft security vulnerabilities will remain flat or decrease.

"The numbers lag the adoption," he said, explaining that as open source becomes more prevalent, problems -- and scrutiny of weaknesses -- will increase.

Apple Bit, Also

"Apple's products are now just as vulnerable, now that it is fielding an operating system with embedded Internet protocols and Unix utilities," the Aberdeen reported added.

According to the CERT list, security advisories affecting Apple's OS X jumped from two in 2001 to four in the first 10 months of 2002.