Firewalls

Control Panel will need to have incoming traffic allowed to ports 80/443 & 30000->40000 and be able to communicate outbound to our licensing server on port 555. Do not block any communication between the Control Panel and the compute resources.

Where possible, we recommend that you use a hardware firewall device or Access Control List (ACL) in front of your management network, as opposed to using iptables directly on the Control Panel server. This will help avoid issues that could be caused by misconfiguration of iptables rules.

Linux has built-in IP filter modules that can provide sufficient protection from malicious traffic. Using this option we can create firewalls on all cloud nodes which need to be secured.

Firewall configuration demands strong knowledge and a clear understanding of network infrastructure. Wrongly applied rules may block important traffic and make impossible remote connections even for authorized persons. 

There are different methods of firewall configuration, including restrictive and permissive mode depending on the default behavior for unspecified traffic.  We do not recommend using restrictive methods as your first attempt for firewall configuration.

It is recommended to leave outbound connections unfiltered as your cloud nodes should be able to initiate connections to any external services. Before creating restriction rules on cloud nodes it is useful to check the services that are running and can be potentially accessible. The netstat utility can show this information for TCP and UDP respectively:

# netstat -nlpt

# netstat -nlpu 

To check the existing iptables rules you can use the following commands:

# iptables -vnL

# iptables-save

Rule insertion order is significant as the Linux ipfilter examines each packet against each rule condition sequentially by the order they were inserted in the system. The first matching rule will be applied.

The example below shows how you can configure iptables on your OnApp Controller server to lock all unnecessary access to your cloud. Please be sure to edit the rules to suit your environment before applying them to your server. If you are allowing global WebUI access, you should only need to change the IP addresses in the example below, since the ports are already configured for you.

  1. Allow local, icmp (including ping), and established connections traffic

    iptables -A INPUT -i lo -j ACCEPT
    iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
  2.  Allow SSH service access from your administrative IPs or subnets before inserting any blocking rules

    iptables -A INPUT -s 10.10.10.10 -p tcp --dport 22 -j ACCEPT 
    iptables -A INPUT -s 10.10.20.0/24 -p tcp --dport 22 -j ACCEPT 
  3. Allow http/https (OnApp WebUI) and console ports globally

    iptables -A INPUT -p tcp --dport 80 -j ACCEPT
     iptables -A INPUT -p tcp --dport 443 -j ACCEPT
     iptables -A INPUT -p tcp --dport 30000:30099 -j ACCEPT
     
  4. Reject all other incoming traffic

    iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
     
  5. Save config and set to start at boot

    iptables-save > /etc/sysconfig/iptables
     chkconfig iptables on
     service iptables start
  6. Allow all traffic on the Management network (this is critical)

    iptables -A INPUT -s 192.168.0.1/24 -j ACCEPT


    The iptables INPUT chain rules on CR servers are pre-configured by OnApp’s install script. The FORWARD chain is dynamically managed by OnApp CP software. It is not recommended to make any changes to the iptables config on CR as it can cause the guest virtual server connections unreachable.