Private Network Interfaces: The Forgotten Security Hole

Regardless of the type of hosting you’re using – dedicated or cloud – it’s important to take network interface security seriously. Most often, threats from the internet are the only ones mentioned. However, if you share a private network with other customers, you have just as much risk on that interface.

Many cloud providers allow you access to a private network environment where you can exchange data with other instances or other services offered by the provider. The convenience of this access comes with a price: other instances can access your instance on the private network just as easily as they could on the public interface.

Here are some security tips for your private interfaces:

Disable the private interface

This one is pretty simple. If you have only one instance or server, and you don’t need to communicate privately with any other instances, just disable the interface. Remember to configure your networking scripts to leave the interface disabled after reboots.

Use packet filtering

The actual mechanism will vary based on your operating system, but filtering packets is the one of the simplest ways to secure your private interface. You can take some different approaches with them, but I find the easiest method is to allow access from your other instances and reject all other traffic.

For additional security, you can limit access based on ports as well as source IP addresses. This could prevent an attacker from having easy access to your other instances if they’re able to break into one of them.

Configure your daemons to listen on the appropriate interfaces

If there are services that don’t need to be listening on the private network, don’t allow them to listen on your private interface. For example, MySQL might need to listen on the private interface so the web server can talk to it, but apache won’t need to listen on the private interface. This reduces the profile of your instance on the private network and makes it a less likely target for attack.

Use hosts.allow and hosts.deny

Many new systems administrators forget about how handy tcpwrappers can be for limiting access. If your firewall is down in error, host.allow and hosts.deny could be an extra layer of protection. It’s important to ensure that the daemons you are attempting to control are built with tcpwrappers support. Daemons like sshd support it, but apache and MySQL do not.

Encrypt all traffic on the private network

Just because it’s called a “private” network doesn’t mean that your traffic can traverse the network privately. You should always err on the side of caution and encrypt all traffic traversing the private network. You can use ssh tunnels, stunnel, or the built-in SSL features found in most daemons.

This also brings up an important point: you should know how your provider’s private network works. Are there safeguards to prevent sniffing? Could someone else possibly ARP spoof your instance’s private IP addresses? Is your private network’s subnet shared among many customers?

With all of that said, it’s also very important to have proper change control policies so that administrators working after you are fully aware of the security measures in place and why they are important. This will ensure that all of the administrators on your instances will understand the security of the system and they should be able to make sensible adjustments later for future functionality.

Major Hayden builds OpenStack clouds as a principal architect at Rackspace. Major is a core developer in the OpenStack-Ansible project with a focus on improving information security in OpenStack deployments. He holds multiple Red Hat and Global Information Assurance Certification (GIAC) certifications and has written extensively about securing virtualized Linux environments. Outside of OpenStack, Major has contributed to several open source projects including dracut, systemd, and Ansible. Within the Fedora Linux community, he serves on the Fedora Security Team and Fedora Server Working Group. He enjoys writing on his personal blog,, and he talks about technical topics on Twitter as @majorhayden.


  1. “you should know how your provider’s private network works. Are there safeguards to prevent sniffing? Could someone else possibly ARP spoof your instance’s private IP addresses? Is your private network’s subnet shared among many customers?”

    So what are the answers to these questions for Rackspace’s products?

  2. Nathan –

    With Rackspace’s Cloud Servers, the private network is shared between customers. That’s why it’s so important to ensure that you take the same precautions with your private network that you take with your public network.

    However, it’s not possible for customers on Cloud Servers to spoof another instance’s IP address or reply to ARP requests meant for another instance. We also apply filters to prevent one instance from being able to sniff another instance’s traffic. While this does prevent some legitimate network activity — such as multicast traffic — it adds a strong layer of security to your instances.

  3. For those coming here nowadays, Rackspace is in the process of rolling out private subnet functionality for cloud servers. It’s currently opt-in (ask a support rep via chat), but essentially you’ll select it during server creation, and you can add multiple servers to a subnet for more security.

    # Allows inbound traffic on ports 80 and 443 from a subnet
    iptables -A INPUT -s 10.XXX.XXX.XX/XX -j ACCEPT


Please enter your comment!
Please enter your name here