How to configure and secure Linux for VMware

Ubuntu Linux comes very well configured and secured out of the box, but you can almost always make a car run a little bit faster. Likewise, we can usually find ways to tweak a server to our liking.

In the last installment of this series, Installing Linux,

    Requires Free Membership to View

we installed all necessary components of Ubuntu Linux. Now we can proceed with configuring and securing this Ubuntu installation. We'll discuss the steps in this tip.

Because the Ubuntu Server Install CD will probably not always be sitting in the server's CD-ROM drive, we need to tell Ubuntu to look elsewhere for subsequent updates. (The CD will not contain the latest packages from Ubuntu anyway.) To remove the CD media from the update sequence, we will have to comment out its entry in the file sources.list. Type:

sudo vi /etc/apt/sources.list

Find any entry line that begins with "deb cdrom" and comment out the line by prefixing the line with a "#" (pound) character. At this point, you must decide whether or not you will be pulling updates for this server from the main Ubuntu mirrors or a local apt repository. If you need to further edit the file to point to a local apt repository, do so now.

Save the file and exit the editor.

Networking configuration
Now let's take a look at the networking settings you'll want to configure.

If you have additional NICs in your server, it is time to configure them. To do this, we will have to edit the file /etc/network/interfaces.

sudo vi /etc/network/interfaces

Before we modify the file, it should resemble this:

The stanza that starts with "auto eth2" and ends with "dns-nameservers" should be copied in its entirety. Yours may not read eth2; if it doesn't, it will most likely be eth0 or eth1. Regardless, once the stanza is copied and pasted beneath (or above) the existing one, we need to make some changes to the copy.

The copy still says "eth2". Wherever it says "eth2" in the copy, you should change this to be one of the NIC IDs that you wrote down during the server installation. For example, in the following screenshot I changed the copied "eth2" to "eth0".

If you notice, I also changed the comment above the original stanza from "The primary network interface" to "The management network interface". I also changed the comment on the copy to "The VMs network interface".

You should repeat the process of copying the original stanza for each NIC the server has. The number of NICs the server has (or at least has drivers for) is the same number of NIC IDs that you recorded in the installation. All additional NICs will be dedicated to the VMs, so when you make copies, you can change their comments to "The VMs network interface" as well. Only the original NIC will be dedicated to managing the server and VMware; the rest of the NICs will be dedicated to the VMs themselves.

Once all the NICs are configured, save and exit the file. To verify that the changes we made are correct, restart networking on the server by typing:

sudo /etc/init.d/networking restart

This command may take a long time since you should not have any network cables connected. If you do not receive any errors, then everything is okay. If you do receive errors, you should go back and check the file to see if you mistyped anything. If you cannot figure out what is wrong, you may always e-mail me at akutz at lostcreations dot com.

We need to modify the /etc/hosts file so the server has a fully qualified domain name. Edit the hosts file by typing:

sudo /etc/hosts

Your hosts file will look similar to the following screenshot:

The difference between your hosts file and mine is that I have already added a FQDN for my server. To do this, look at the second line in my file. Before the host name, "vms02", I added the FQDN of the server, "vms02.lostcreations.com". Add your server's FQDN to the file, and save and exit the file.

You can confirm that your server has a FQDN by typing the following in the console:

hostname –f

This will return you server's FQDN.

If you have access to a dedicated syslog server, go ahead and instruct this server to send all of its log entries of debug level to that server. We do this by editing the file0 /etc/syslog.conf:

sudo vi /etc/syslog.conf

Add this line anywhere in the file:


Save the file and exit. Now all debug entries will get shuttled to the syslog server, in case you need to diagnose a problem with this server and cannot log into it.

Disabling services
Ubuntu Server ships with a number of services that a VMware server does not need. If the server will not be using a service, then that service does not need to be started at boot. Two of the services that I disable are alsa-utils and pcmciautils. You may find others that you wish to disable. You can see a list of services by listing the contents of /etc/init.d.

The file /etc/init.d/alsa-utils is kind enough to tell us how to disable it. To disable alsa-utils, per the file, "rename the "S50alsa-utils" symbolic link in /etc/rcS.d/ to "K50alsa-utils"". This will prevent alsa-utils from starting on boot. To stop the service now, type:

sudo /etc/init.d/alsa-utils stop

To disable pcmciautils, rename the "S13pcmciautils" symbolic link in /etc/rcS.d/ to "S87pcmciautils". This will prevent pcmciautils from starting on boot. To stop the service now, type:

sudo /etc/init.d/pcmciautils stop

Although Ubuntu Linux is a secure operating system, we can do a few things to decrease the external attack vectors.

Host.deny and hosts.allow
The hosts.deny and hosts.allow files allow us to configure which remote hosts can talk to any open port on this server if the process that opened that port has support for tcp wrappers. For example, the ssh daemon supports tcp wrappers so it will respect the ACLs defined by the hosts.deny and hosts.allow file. The Apache Web server, on the other hand, does not (by default) support tcp wrappers; therefore, the hosts.deny and hosts.allow files have no impact on which clients can access ports that the Apache process opens.

I practice explicit access control, which means that I explicitly deny all access and explicitly grant access. To explicitly deny access, edit the /etc/hosts.deny file with:

sudo vi /etc/hosts.deny

Add this line to the end of the file:


Save the file and exit. At this point, if your server were connected to the network, no remote client would be able to access any port that was opened by a process that supports tcp wrappers. This is because you have explicitly denied all clients.

Now you need to explicitly allow some clients. To do this, edit the file /etc/hosts.allow with:

sudo vi /etc/hosts.allow

Allow all remote connections to certain clients by adding the following lines to the end of the file:


Save the file and exit. As you can see, you can add entries to the file by host name and ip address -- of even domain names with wild cards in them. To learn more about the hosts access control list files, type the following at the shell:

man hosts_access

The man page that appears will describe the formats of both the hosts.deny and hosts.allow files (hint, they're the same format).

At this point, all remote clients are denied access to your server's ports that have been spawned by processes that support tcp wrappers, except for those clients you have explicitly allowed. And because the only open port at the moment is 22 for the sshd process and because the sshd supports tcp wrappers, if your server were on the network, only the explicitly allowed clients in the hosts.allow file would be able to connect to the server via ssh.

Beside hosts access file, another way to really lock down the ssh daemon is to restrict clients to using public key authentication.

Please be sure you want to do this. If you do enable this, then you will not be able to log into this server remotely with ssh with a passphrase. You will be required to have a public key. If you are unsure of this step, please read the documentation on ssh and public key authentication at sial.org.

To restrict the ssh daemon to public key authentication, edit /etc/ssh/sshd_config with:

sudo vi /etc/ssh/sshd_config

Find the line:

# PasswordAuthentication yes

…and change it to disallow password authentication:

PasswordAuthentication no

We also need to tell the ssh daemon that it should only listen on the management interface NIC. Find the line:

# ListenAddress

…and replace it with

ListenAddress MGMT_NIC_IP

…where MGMT_NIC_IP is the IP of the management network interface. Changing this setting means that the ssh daemon will not listen on the NICs dedicated to the VMs.

Save the file and exit. Restart the ssh daemon by typing:

sudo /etc/init.d/ssh restart

Now the ssh daemon will only accept public key authentication and is listening for incoming connections only on the management interface NIC.

To prevent unauthorized access to the server, we will set up iptables so that only traffic we specify is allowed. We will set these rules in /etc/rc.local so that they are enabled at boot time. Edit /etc/rc.local with:

sudo vi /etc/rc.local

Copy and paste the following iptables rules into the file, replacing MGMT_NIC_IP with the IP address of the server's management network interface.

- --- BEGIN COPY ---


# allow all incoming traffic from the management interface NIC
# as long as it is a part of an established connection
iptables -I INPUT 1 -j ACCEPT -d MGMT_NIC_IP -m state --state

# allow all ssh traffic to the management interface NIC
iptables -I INPUT 2 -j ACCEPT -p TCP -d MGMT_NIC_IP --destination-port 22

# allow all VMware MUI HTTP traffic to the management interface NIC
iptables -I INPUT 3 -j ACCEPT -p TCP -d MGMT_NIC_IP --destination-port 8222

# allow all VMware MUI HTTPS traffic to the management interface NIC
iptables -I INPUT 4 -j ACCEPT -p TCP -d MGMT_NIC_IP --destination-port 8333

# allow all VMware Authorization Daemon traffic to the management
interface NIC
iptables -I INPUT 5 -j ACCEPT -p TCP -d MGMT_NIC_IP --destination-port 902

# reject all other traffic to the management interface NIC
iptables -I INPUT 6 -j REJECT -d MGMT_NIC_IP --reject-with


# allow all outgoing traffic from the management interface NIC
# if it is a part of an established connection
iptables -I OUTPUT 1 -j ACCEPT -s MGMT_NIC_IP -m state --state

# allow all DNS queries from the management interface NIC
iptables -I OUTPUT 2 -j ACCEPT -s MGMT_NIC_IP -p UDP --destination-port 53

# reject all other traffic from localhost
iptables -I OUTPUT 3 -j REJECT -s --reject-with

# reject all other traffic from the management interface NIC
iptables -I OUTPUT 4 -j REJECT -s MGMT_NIC_IP --reject-with

- --- END COPY ---

Once you've copied and pasted the iptables into /etc/rc.local, load them by typing:

sudo /etc/init.d/rc.local start

To verify that the iptables are loaded, type:

sudo iptables –L

You will see the iptables listed in the shell. Please keep in mind that this iptables list is a fairly restrictive set -- but only with regards to the management interface NIC. This iptables ruleset does not affect the other NICs in the server, the NICs dedicated to the VMs, at all.

If you have a remote console session to the server via ssh and you cannot ping some server or you cannot ssh into another server, remember that if you want to do any of those things and almost anything else, you will have to edit the iptables ruleset. For example, this ruleset does not take into account the apt servers that you will fetching updates from. You will have to make outbound exceptions for them above rule number 3 in the OUTPUT chain or else you will receive a "connection refused" error when you try to connect to them with apt.

Start networking
At this point, it is safe to go ahead and plug in the server's Ethernet cables. Once that is completed, if all of the network information was inputted correctly, the server should be able to talk on the network.

In the next installment of this series, we'll look at how to secure VMware Server, fix a nagging bug in Ubuntu and how to monitor and back up the server.

About the author: Andrew Kutz is deeply embedded in the dark, dangerous world of virtualization. Andrew is an avid fan of .NET, open source, Terminal Services, coding and comics. He is a Microsoft Certified Solutions Developer (MCSD) and a SANS/GIAC Certified Windows Security Administrator (GCWN). Andrew graduated from the University of Texas at Austin with a BA in Ancient History and Classical Civilization and currently lives in Austin, TX with his wife Mandy and their two puppies, Lucy and CJ.

This was first published in February 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.