Linux Solutions

The article will provide a reader with information on G-Data Antivirus. G-Data Antivirus is generally easy to use. The main interface clearly indicates the PC’s protection status, though it does lack a “master” everything’s-protected-and configured-correctly status indicator that’s present in many antivirus products. The scan screen isn’t as simple as it is in some other products, but is still well laid out.

G-Data AntiVirus 2011 was tested and the tests revealed that it is one of the better performers at cleaning up malware: it detected all infections on our test PC, and disinfected active malware components in 80 percent of the cases, which tied it with several other products for the top score in this test. And it removed all traces of malware infections 60 percent of the time - again, a very good showing.

In addition, G-Data AntiVirus 2011 was one of the few antivirus packages that were tested that didn’t flag a single “safe” file as potentially dangerous. Scan speed results were mixed. G-Data AntiVirus 2011 performed well in the on-demand scan tests, which determine how quickly it can run a manually initiated scan. It completed the on-demand scan of 4.5GB of data in 1 minute, 51 seconds–the third-best score in this test. On the other hand, its on-access scan times lagged. (The on-access test is a good way to see how long it will take a product to scan files as they’re opened or saved to disk.) It finished this test - scanning 4.5GB of files - in 5 minutes, 36 seconds, a below-average showing. The test also revealed that its impact on performance was slightly lower than average relative to other antivirus software.

G-Data AntiVirus 2011 can have a moderate impact on overall PC performance. It can add less than a second to startup time versus a PC with no antivirus software installed.

• Pros
Uses two antivirus engines for enhanced detection. Includes CPU Load meter. Malicious website blocking very effective against phishing. Behavioural detection catches bad programs, not good ones.

• Cons
Malware cleanup rendered one test system unbootable. Many malware-linked executables and almost all non-executable traces left behind by cleanup. Detected but failed to prevent installation of two rootkit-based key loggers.

• Bottom Line
G Data has its good points, notably accurate protection and behavioural analysis that avoids false positives. But its cleanup leaves behind way too much, it rendered one test system unbootable, and some threats managed to install despite G Data’s attempt to prevent them.
Installation, Successful and Otherwise
Immediately after installation G Data wisely prompts the user to run an update. Once the update finishes the product prompts the user to run a scan.

By reading the article, a user would have gained knowledge and understanding for G-Data AntiVirus 2011.

In this article a user will learn about securing Linux production systems. It will cover areas such as physical Security, verifying security action items, retiring linux servers with sensitive data, backups, removing unnecessary software packages, patching linux systems and closing network ports and disabling runlevel system services and Xinetd services.

Now, let’s look at following areas of cover:
Physical Security
A user should consider physical security as of high importance and for that Linux production servers should be in locked datacenters where only people with passed security checks have access. Another useful thing regarding security is to take boot loader passwords.

Verifying Security Action Items
A user should also look into scripts that can verify that all the security action items have been executed. Please note that even the best sysadmins can make mistakes and miss steps. If a user has a larger Linux environment, it would be a good investment to write scripts for checking Linux security action items.

Retiring Linux Servers with Sensitive Data
If a user is interested in retiring Linux servers with sensitive data then he/she should understand that data cannot be recovered from the hard disks. In order to verify that all traces of data are removed, the DiskSanitizer tool can be used. This tool can be operated from a floppy disk and it removes data.

Backups
If a users system gets compromised, then the backups become invaluable. Backups are of high importance as in cases like bugs, accidents etc. backups can be used to compare the current system against the backed-up system. Backups hold importance for production systems and the backups should be taken offsite for cases like disasters.

Disk Partitions
A user should be aware that servers should have separate partitions for at least /, /boot, /usr, /var, /tmp, and /home. A user shouldn’t have logging and temporary space under /var and /tmp fill up the root partition. Third party applications should be on separate filesystems as well, e.g. under /opt.

Firewall (iptables)
A user should note that firewalls can be used to protect the servers in a production network.

SELinux
Please note that SELinux is an advanced technology for securing Linux systems. Hardening Linux using SELinux technology, on its own, warrants it’s own security. The SELinux technology is recommended for securing Linux systems and this is why a user should consider using SELinux.
FTP, telnet, and rlogin (rsh)

FTP, telnet, and rlogin (rsh) are vulnerable to eavesdropping, which is one of the reasons why SSH/SCP/SFTP should be used instead. It is highly recommended not to run these services. Due to the high risk, this guide does not cover these services. It would also be a good idea not to have FTP and Telnet server RPMs installed on the system.

How to remove unecessary Software Packages (RPMs)?
It is a good idea to establish the software packages that are not necessary. This is because some of the software packages that are not necessary might not comply with the security policy. After removing the unnecessary software packages, it will be easy for a user to update nad maintain when security alerts and patches are released. A good example is of packages such as Apache or Samba installed on the system which a user doesn’t use them. Another useful advise is not to have development packages and desktop software packages (such as X Server) etc. installed on production servers. Also, packages such as FTP and Telnet daemons should not be installed as well unless there is a justified business reason for it (SSH/SCP/SFTP should be used instead).

The first step is to create a Linux image that only contains RPMs needed by the applications, and needed for maintenance and troubleshooting purposes. A good approach is to start with a minimum list of RPMs and then add packages as needed. It may be time-consuming but worth the efforts.

Useful commands
A list of useful commands that a user can note are provided below:
- If a user wants to get a list of all installed RPMs then he/she can use the following command:
rpm –qa
- If a user wants to know more about a particular RPM, then he/she can run:
rpm -qi
- If a user wants to check for and report potential conflicts and dependencies for deleting a RPM, then he/she can run:
rpm -e –test
Patching Linux Systems
A user should also note that in order to secure Linux production environments, it is a good idea to build an infrastructure for patch management. It is recommended to have a written security policy and procedure to handle Linux security updates and issues.

For example, a security policy should detail the timeframe for assessment, testing, and rollout of patches. Network related security vulnerabilities should get the highest priority and should be addressed immediately within a short timeframe.

For example, a security procedure should detail the process for assesment, testing, and rollout of patches. The assessment phase should occur within a testing lab, and initial rollout should occur on development systems first.

A separate security log should detail what Linux security notices have been received, when patches have been researched and assessed, when patches have been applied etc. For Red Hat systems, it is recommended to use Red Hat Network (RHN) for patch management. In fact, for secure environments a user can also take into account the Red Hat’s Satellite solution.

Detecting Listening Network Ports
One of the most important tasks is to detect and close network ports that are not needed.
In order to obtain a list of listening network ports (TCP and UDP sockets), a user can run the following command:
# netstat -tulp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:auth *:* LISTEN 2328/xinetd
tcp 0 0 localhost.localdomain:smtp *:* LISTEN 2360/sendmail: acce
tcp 0 0 *:ssh *:* LISTEN 2317/sshd

A user can easily see from the output that xinetd, sendmail, and sshd are listening.

On all newer Red Hat Linux distributions sendmail is configured to listen for local connections only. Sendmail should not listen for incoming network connections unless the server is a mail or relay server. If a user wants to confirm that then he/she should run a port scan from another server. In order to run a port scan from another server a user can run following command:
# nmap -sTU

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2004-12-10 22:51 CST
Interesting ports on jupitor (172.16.0.1):
(The 3131 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
113/tcp open auth

Nmap run completed — 1 IP address (1 host up) scanned in 221.669 seconds
#
Please note that the mentioned nmap command can take a while. If a user wants to remove the UDP port scan (without the option “-U”), then nmap will finish the port scan immediately. If a user runs it on the local machine it will also complete very fast. A user should also note that nmap might not show all listening network sockets if a firewall is being used to block ports.

From the output above a user can see that the xinetd daemon is listening on port auth (port 113) for IDENT. A user can also see that sendmail is not listening for remote incoming network connections.

There is another method to list all of the TCP and UDP sockets to which programs are listening is lsof:
# lsof -i -n | egrep ‘COMMAND|LISTEN|UDP’
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 2317 root 3u IPv6 6579 TCP *:ssh (LISTEN)
xinetd 2328 root 5u IPv4 6698 TCP *:auth (LISTEN)
sendmail 2360 root 3u IPv4 6729 TCP 127.0.0.1:smtp (LISTEN)
#

Closing Network Ports and Disabling Runlevel System Services
One of the most important tasks is to remove any network services from the system startup process that are not required.

On Red Hat systems if a user wants a list of all services that are started at bootup then he/she can run following command:
chkconfig –list |grep on

A user will also notice that there are quite a lot of services enabled on the system. But many runlevel services (Stand-Alone Services) are not network related services like kudzu which is responsible for detecting and configuring new and/or changed hardware on your system. This service is only run during the boot process. It is important to know that a user should not disable runlevel services that are required by the system to run smoothly.

Red Hat Runlevel System services
There are a number of Red Hat Runlevel Systerm servies that a user can enable if he/she wants to depending on his needs and requirements:
gpm needed if you want to use the mouse at the console
kudzu important for detecting new hardware
syslog important for syslog services
netfs needed only if there are NFS shares that should be mounted at boot time
network important for starting network interfaces (e.g. eth0, eth1, bonding,…)
random used for the system entropy pool
atd needed if the at(1) service is used instead of cron
apmd Advanced Power Management (APM) daemon is used for laptops and some desktops
isdn needed if ISDN is being used
iptables needed if Netfilter (iptables) Firewall is being used
ip6tables needed if ip6tables Firewall is being used
pcmcia not needed on servers - needed for laptops
irqbalance important for distributing interrupts across all CPUs
sendmail needed if Sendmail is used - Procmail should be used which is more secure
autofs needed if automounter is used - production applications should not be dependent on automounter
sshd important for logins via SSH
portmap needed if e.g. NFS is being used
nfslock needed if NFS shares are mounted
nfs needed if server runs the NFS server
mdmonitor needed only if software RAID is being used
crond important for running cron jobs
xinetd needed if xinetd services are being used, see /etc/xinetd.d/ for list of services
cups needed if CUPS is used for the printing system
rhnsd needed if server should connect to RHN to check for software updates etc.
sysstat needed to reset system statistics logs
audit needed only if Linux Audit Subsystem (LAuS) should run for collecting system call audit records
psacct needed only if kernel process accounting information is needed
smartd important for monitoring disk problems if hard disks support SMART technology
netdump important if kernel oops data and memory dumps should be sent to a Netdump server for server crashes

Please note that the start/stop scripts of all runlevel services can be found in the /etc/init.d directory. For example, if a user doesn’t know what the atd service does, then he/she can go to /etc/init.d and open the file atd. And in the script look for lines that start programs. In the atd script the “daemon /usr/sbin/atd” line starts the binary atd. Now having the name of the program that is started by this service, a user can check the online pages of atd by running man atd. This will help a user to find out more about a system service.

If a user wants to disable a service (such as the runlevel service nfs) on a permanent basis then he/she can run following command:
chkconfig nfs off

If a user wants to disable the runlevel service nfs immediately then he/she can run following command:
/etc/init.d/nfs stop

Closing Network Ports and Disabling Xinetd Services
The xinetd daemon is a replacement for inetd, the internet services daemon. It monitors the ports for all network services configured in /etc/xinetd.d, and starts the services in response to incoming connections.

If a user want to check if xinetd is enabled and running, then he/she can execute following command:
# chkconfig –list xinetd
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
# /etc/init.d/xinetd status
xinetd (pid 2619) is running…
#

If xinetd is active, it is important to check which Unix services are active and controlled by xinetd. A command is provided below that shows all the services configured in /etc/xinetd.d and wheter xinetd monitors the ports for these services:
# chkconfig –list | awk ‘/xinetd based services/,/”"/’
xinetd based services:
krb5-telnet: off
rsync: off
eklogin: off
gssftp: off
klogin: off
chargen-udp: off
kshell: off
auth: on
chargen: off
daytime-udp: off
daytime: off
echo-udp: off
echo: off
services: off
time: off
time-udp: off
cups-lpd: off
#

If a user wants to get a list of only active services for which xinetd monitors the ports, then he/she should run following command:
# chkconfig –list | awk ‘/xinetd based services/,/”"/’ | grep -v off
xinetd based services:
auth: on
#
This shows that the telnet-server RPM is not installed on the system. If the Telnet Server package telnet-server would be installed, it would show up on the list whether it’s active or not.

If a user wants to disable a service such as telnet and also wants to view how the telnet service entries are being update then a user can run following command
# chkconfig –list telnet
telnet on
# cat /etc/xinetd.d/telnet | grep disable
disable = no
# chkconfig telnet off
# chkconfig –list telnet
telnet off
# cat /etc/xinetd.d/telnet | grep disable
disable = yes
#

Please note that for the telnet service it would be better to remove the package from the system since SSH should be used instead:
# rpm -e telnet-server

It is important to investigate all active xinetd services and to disable them if they are not needed.

Here is an example how to find out what a service does. This example is based on the assumption that a user doesn’t know what the auth service does?. This can be done by running following command:
# grep ” server” /etc/xinetd.d/auth
server = /usr/sbin/in.authd
server_args = -t60 –xerror –os -E
# man in.auth
No manual entry for in.auth
# rpm -qf /usr/sbin/in.authd
authd-1.4.1-1.rhel3
# rpm -qi authd-1.4.1-1.rhel3 | awk ‘/Description/,/”"/’
Description :
authd is a small and fast RFC 1413 ident protocol daemon
with both xinetd server and interactive modes that
supports IPv6 and IPv4 as well as the more popular features
of pidentd.
# rpm -ql authd-1.4.1-1.rhel3
/etc/ident.key
/etc/xinetd.d/auth
/usr/sbin/in.authd
/usr/share/doc/authd-1.4.1
/usr/share/doc/authd-1.4.1/COPYING
/usr/share/doc/authd-1.4.1/README.html
/usr/share/doc/authd-1.4.1/rfc1413.txt
/usr/share/locale/ja/LC_MESSAGES/authd.mo
#
This example shows what can be done if there exists no online manuals for the binary in.authd that is started by xinetd. The steps above should be helpful for finding out more about services.

The auth service (aka IDENT, see RFC 1413) allows remote daemons to query information about users establishing TCP connections on the local server. In a trusted environment it helps a server to identify who is trying to use it. For example, it can provide vital information for troubleshooting and who has done what. IDENT requests are needed by some applications like IRC. A user should note that IDENT can be a security risk.

If a user wants to disable the auth service, then he/she should run the following command:
# chkconfig auth off

The xinetd daemon is quite flexible and has many features. Here are just a few functionalities of Xinetd:
- Acces control for TCP, UDP, and RPC services
- Acess limitations based on time
- Provides mechanisms to prevent DoS attacks

If a user has read this article then he/she would have learnt about physical Security, verifying security action items, retiring linux servers with sensitive data, backups, removing unnecessary software packages, patching linux systems and closing network ports and disabling runlevel system services and Xinetd services.

A few days ago I spoke on the Conficker/Downadup (C/D) worm that’s working its way around the world, infecting a huge number of Windows-based computers, and a recent story has revealed that if a Linux user who has the Wine software – a program that allows Linux users to download Windows programs – that they could be infected too.

The Superworm that has reportedly been attacking a patched vulnerability in Microsoft Windows, with a reported 6.5 million new infections in the past 4 days alone, bringing the total to an estimated 9 million machines infected.

There are a number of factors contributing to the worm’s growth. The Windows vulnerability allows for self replicating attacks in 2000, XP and Server 2003 version of the software, and the virus has been designed to exploit flash and network drives allowing it to spread across a local network at worrying pace even if just one computer is affected.

A large factor that has allowed the worm to grow is because of stubborn data managers and administrators of Windows-based systems who failed to listen to the warnings and download a security update. Microsoft released a patch to combat the worm over three months ago, but nearly one in three machines have not downloaded it, according to security company Qualys.

The C/D worm uses the autoplay function to load up files from removable devices using a simple autorun.inf file which can fool users into installing malicious code on their machines. This means that even Windows Beta 7 users could have been affected by the slithery culprit.

While autoplay can be turned off and autorun.inf files removed, the users can be easily deceived by the pop-up that appear once the removable device is plugged in. Once the worm is loaded on to a system it uses a complex algorithm based on public websites such as Google to contact their “home” servers and disables Windows Update automatically.

The clever part is that the algorithm changes every day, pointing to different domain names every day (up to 250) and are calculated using a public key – not unlike those used in security encryptions.

It would appear that no-one is safe as even a hospital in Sheffield, England has reported that more than 800 of its 7000 computers have been compromised by the worm – system administrators decided to turn off Windows security updates.

It’s easy to find a cheap security product on the internet these days. One look at the many websites that peddle free downloads and try now, buy later products and you’ll be presented with a myriad of options.

When it comes to your IT security, you should always choose the software that you believe will stop the biggest threat to your computer. When you’re on these download sites you should take your time to weigh up the benefits and pitfalls of each product carefully. Cost is generally the first thing people consider. Ultimately, you get what you pay for, but free open source products are getting better and better every few months.

Ideally you’d want an unlimited budget and you’d buy whatever you felt did everything required, and often open source software doesn’t quite cut the mustard. Evaluating every aspect of your selected product; what does it cover? Is technical support available? what about upgrades? Does the price increase after the first year? Is their really a big difference between the free version and the paid version?

Let’s look at disk encryption software. Can open source software provide a solid alternative to off the shelf products?

The first thing to consider is would you use any software that uses a proprietary encryption algorithm. At the core of any product with cryptographic services is a cryptographic module. This module generally does not have adequate testing and validation against established standards, so won’t provide the security level you require. With an open source alternative the cryptographic module will not be proprietary and is generally tightened up by a squad of security experts.

If the software is poorly designed the product will prove insecure, placing your valuable information at risk of theft or damage. The major advantage the many security experts cite is that with an open source security option, you are able to check the source code itself to ensure the encryption algorithms are implemented correctly.

This being said, just because you maybe prefer open source to ‘off the shelf’ products, you shouldn’t rest on your laurels. Even a good open source cryptographic module that has been badly implemented can lead to a serious vulnerability that could have dire consequences for your data.

You shouldn’t assume as well that it’s just the smaller open source developers that get in a mess. In May 2008, Debian has a major security failure in its GNU/Linux operating systems random number generator, making any OpenSSL keys generated during that past 20 months so predictable that they could be guessed in only a few hours.

A new Trojan that has the ability to tamper with multiple devices on a local network has been found by security researchers. The malware send users to impostor websites even if the machines are fully security shielded, or run non-Windows operating systems.

The malware is a spin off of the DNSChanger Trojan that researchers say is known to change the domain name settings of users’ systems. Researchers from the McAfee Avert Labs, claim the updated Trojan makes a single infected system pollute the DNS settings of however many computers are connected to the same local network by undermining its dynamic host configuration protocol, or DHCP, which dynamically allocates IP addresses.

Craig Schmugar from McAfee said that, “Systems that are not infected with the malware can still have the payload of communicating with the rogue DNS servers delivered to them. This is achieved without exploiting any security vulnerability.”

This Trojan is quite frightening. Imagine if you were to take your laptop to an internet café for example and it is infected by the new version of DNSChanger.

Another user comes in and connects to the same network, asking for an IP address. Your infected laptop injects as DHCP offer command that instructs the new user’s laptop to rout all DNS requests through a dodgy DNS server. The new user can not use his laptop to view trusted sites, as it would be an impostor site.

A user could take steps to avoid the Trojan. Schmugar suggests hard-coding a DNS server in a systems configuration settings. You can do this on a windows C or laptop by going in to your network connections (in control panel), scrolling down to Internet Protocol (TCP/IP) and clicking properties, then type in the primary and secondary for your DNS service.

Schmugar said that “the DHCP attack doesn’t exploit a vulnerability in either users machines or network hardware”, which allows it to work with a wide variety of everyday home routers. The Trojan uses a ndisprot.sys driver installed on the network. Then it sets up camp and monitors network traffic for DHCP requests and sends false information that contains the IP address to the DNS server.

Although the malware is not widespread, it is rather worrying that this kind of Trojan is on the horizon, and you could only imagine the chaos that would ensue if this got in to a large corporations network.

The US Computer Emergency Readiness Team is warning that attacks against Linux systems with compromised SSH keys are taking place.

The attacks use stolen SSH keys to take hold of a targeted machine and than gain root access by exploiting weaknesses in the kernel. A rootkit called Phalanx2 is then installed, which scans the system for more SSH keys. As each new SSH key is stolen new machines are vulnerable to attack.

The CERT advisory doesn’t mention the flaw in the Debian random number generator, but that is the likely entry point for attack. The flaw caused SSL keys generated for more than a year to be so predictable that they could be guessed in a matter of hours. Debian reportedly fixed the flaw in May.

After a Linux server using a weak key is identified and rooted, it gives up the keys it uses to connect to other servers. Attackers can potentially use them to access the servers that use them if both the private and public parts of the key are included. As well as this, attackers can identify other servers that have connected to the infected machine recently, information that could enable additional breaches.

Phalanx2 is the follow-on from a rootkit known as Phalanx. According to Packet Storm, Phalanx is a self-injecting kernel rootkit designed for the Linux 2.6 branch that hides in files, processes and sockets, and includes tools for sniffing a tty program and connecting it with a backdoor. Phalanx2 has been updated to systematically steal SSH keys.

Happily Phalanx2 is relatively easy to detect. One way of telling is to type “ls” at a command prompt and if it fails to show directory “/etc/khubd.p2/”. Also the “/dev/shm/” directory could contain files used in the attack.

CERT advises that keys use strong passphrases or passwords to reduce the risk of a key being stolen.

“I’m still absolutely adamant this is a problem system administrators should have handled a long time ago,” said Bill Stearns, a security researcher and incident handler for the SANS Internet Storm Center. “It’s a really big issue. If they haven’t figured it out, someone will do it for them.”

A glitch in VMware’s most recent update had its customers up in arms this week. The problems were caused by a bug from the beta version of the software that engineers failed/forgot to remove which left VMware users unable to power on virtual machines running the hypervisor software.

The bug, referred to as a “time bomb”, is code that developers insert in beta software to push users to upgrade to an application’s final version. The code is a commonly used tool for developers; however it must be removed from anything into which it has been inserted prior to final release.

The virtualisation software maker released an “express patch” on Wednesday to fix the glitch. However, VMware customers have been left a little disgruntled, and the incident has made the company look a bit amateurish.

The way people look at VMware after the cock-up is “definitely not very good,” according to Gary Chen, a Yankee Group analyst.

“This is the most publicised issue they’ve had in their history, and it’s really the sort of embarrassing bug that never should have made it past QA (quality assurance),” he told said.

In a letter posted on the company’s blog, Paul Maritz, VMware’s recently appointed chief executive officer said: “Last night, we became aware of a code issue with the recently released update to ESX 3.5 and ESXi 3.5 (Update 2).”

According to Maritz, when the time clock in a server running the updated ESX 3.5 or ESXi 3.5 software registered 12:00 a.m. on August 12, 2008, the code caused the product license to expire. As a result of this, powered-off virtual machines could not be turned on; those that had been suspended could not be awakened from that mode; and machines could not migrate using Vmotion.

The problem has also occurred with a recent patch to ESX 3.5 or ESXi 3.5 Update 2. The company has begun a review of its QA processes, Maritz said. (Which means someone’s getting the sack)

To VMware’s credit that it took less than 24 hours to come up with a patch that seems to have corrected the problem, said Chen.

“From what I’ve heard, the patch fixes the problem. You do have to give kudos to VMware for addressing the issue so quickly,” he noted.

Some users have turned to VMware’s Communities discussion pages to vent. “As a VMware Enterprise Partner and VMware Authorized Consultant, I can tell you this IS a big deal for VMware to release a product that has such grave consequences for even a relatively small portion of the total VMware user population,” wrote one user.

“A small percentage does not diminish the severity of problem for affected users and the upmost urgency is expected from a company that caters to enterprise customers who don’t have ‘downtime’ in their corporate dictionary anymore.

“Bugs happen,” the poster continued. “However, I believe this could have been prevented by not rushing an update to market which was intended to be free and compete with [Microsoft’s] Hyper V. This will no doubt teach VMware a lesson and unfortunately will cast doubt about the reliability of VMware in the enterprise. It’s a shame a clearly superior product is going to get bad publicity from this oversight. Let’s give them credit and hope they learn from their mistakes.”

Chen pointed out that most customers were glad of the quick response time from VMware: “The issue was fixed quickly, and there was lots of communication as to the status, cause and future changes to prevent another incident,” he said.

“However, some faith has been lost, as most customers I’ve talked to are disappointed that a bug like this made it past QA. Many admins have been pushing virtualisation to their executives, and this doesn’t help their case,” Chen added.

“Virtualisation is still in the emerging stages, and enterprise reliability is a huge issue that can only be proven over time,” said Chen. “Vendors have been pushing the idea that it is enterprise-ready, and an incident like this hurts not only VMware but the entire virtualisation movement. Virtualisation is inevitable and will certainly continue to proceed, but people will slow down and think more about how to protect themselves against things like this.”

“More and more people are using it, and a major incident, whether a bug or a security hack, could freeze your entire infrastructure. I think people will begin to re-evaluate their options and contingency plans for an incident like this, including perhaps diversifying their infrastructure and adopting multiple hypervisors,” Chen concluded.

A security researcher recently disclosed vulnerability in widely used Linux distributions where attackers can guess cryptographic keys, possibly leading to the forgery of digital signatures and theft of confidential information.

HD Moore, best known as the exploit researcher who creates the Metasploit penetration testing framework, called the vulnerability in Debian and Unbuntu systems “ugly” and said it would be a big job for administrators to find every flawed key, and then re-issue them.

The bug, which was noted on Tuesday by the Debian Project, is in the random number generator used to produce a variety of digital keys, including SSH (Secure Shell) keys and SSL (Secure Socket Layer) certificates.

In Moore’s blog yesterday he boasted that it was relatively easy to “guess” keys and claimed he was able to generate 1024- and 2048-bit keys in about two hours. However, He estimated that an 8192-bit RSA key set would take some 3,100 hours (about 129 days) to generate.

Moore also published several key-generating tools - collectively dubbed “Toys” - that included a shared library and a key generation script.

With this news hitting the internet, other researcher’s began to post notices on their web sites. Bojan Zdrnia, an analyst at the Internet Storm Center (ISC) said, “This is very, very, very serious and scary.”

“The development of automated scripts exploiting keys looks like a real threat to SSH servers around the world,” he added.

Symantec Corp. also warned customers of its DeepSight threat network of the vulnerability noting that, another hacker “Markus M” published a tool that automates brute-force attacks of the key weakness to the Full Disclosure security mailing list.

It’s not just users running Debian-based systems who are at risk, Moore cautioned, but virtually anyone. If data copied to other platforms has been secured by keys generated on a Debian distribution, that data could be snatched.

“There’s a lot of different areas that you’re going to have to look, not just within Debian,” Moore said. “Administrators will have to audit every single key. Even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.”
Moore, ISC’s Zdrnja and others have recommended that Debian and Ubuntu users patch their systems - updates are available - and that users and administrators regenerate all keys produced on a Debian system between September 2006 and May 13, 2008. The September 2006 date, said Moore, was when the first builds that included the flaw were made available.

Although he said the situation is serious, Moore doubted that there would be general and widespread attacks. Instead, he said the most likely outcome would be targeted attacks on systems that administered large numbers of Debian users.

Moore also discounted any connection between the Debian vulnerability and his disclosures, and brute-force attacks some vendors, including Symantec, have been tracking the last 24 hours.

“The timing is definitely funny,” he acknowledged, but said the difference - the attacks have been against user-generated passwords, not authentication keys - means the two events are probably just coincidental.

For those who follow the development of Linux and the companies that have a heavy exposure to the operating code, you will surely have come across Red Hat. This company is one of the largest developers and distributors of Linux based systems and at the forefront of many developments over the years. So how large is Red Hat?

Red Hat is actually listed on the US NASDAQ technology based stock market with a current market value in the region of $4 billion. While the share rice is currently near the 12 months high at $21, the shares have been as high as $160 in 2000 and as low as $3 in 2001. These wild swings have often reflected the prospects and marketability of Linux, although the company does also develop other open source systems to compliment their main Linux based brands – the recently released JAVA open source code being one of the more recent additions.

The Red Hat company has seen turnover increase from $278 million in 2006 to $523 million in 2008, but unfortunately profits have not gone in the same direction. The Group reported net income for 2006 of some $79 million, only to see 2007 figures fall to just under $60 million and then rebound back to $76 million for the year ended February 2008. Even though we have seen a major slump in worldwide stock markets over the last 12 months, the fact that the Red Hat share price is nudging its 12 month high says a lot for the prospects for the company.

Many analysts are forecasting a very productive and lucrative time over the next couple of years for Red Hat, a time when Linux is knocking on the door of the mass market and Red Hat is at the front of the queue.

It seems that the news for Linux just gets better and better with a commitment from Dell, HP and Lenovo that they will “strongly encourage” the production and delivery of open-source drivers which make use of the Linux kernel. So what does this mean?

The Linux kernel is the heart beat of the operation system and allows the operating system to communicate with hardware and software to ensure the smooth running of your computer system. The fact that the likes of Dell, HP and Lenovo are set to champion their cause is a major boost to an operating system which seems to be going from strength to strength.

While there have always been Linux drivers which will allow your system to communicate with other hardware and software, the move to open source drivers is a big step. This now means that the code for Linux based drivers will be in the market place and allow any skilled third party to make amendments, rather than returning to the original creator of the driver.

The move to open source drivers is the next step in the attack on the likes of Windows, which retains total control over access to their inner Windows kernel (for obvious commercial reasons). While the Linux Foundation have been very vocal in their support of the Linux operating system, the take up by Dell, HP and Lenovo allows someone else (majors in the industry) to pick up the baton and run with it on behalf of the Foundation.

There are still many who have doubts about the ability of Linux to move into the mainstream, but each increase in exposure and each addition to the Linux “fan club” is a step forward. The next few years are critical for Linux and it will be interesting to see how it develops.