Container Firewall Rules Management for Convenient Control of Inbound and Outbound Traffic

13

Newly released Jelastic Shield 5.4 rolled out a possibility to manage inbound and outbound firewall rules on the container level through a convenient graphical interface. In this article, we will provide a detailed instruction on how to set up and manage the required connection rules, as well as what use cases can be covered using this firewall implementation.

954-1-convenient-control-of-inbound-and-outbound-traffic

Jelastic Container Firewall feature provides a possibility to control your nodes availability both from inside and outside of the platform. It analyzes such parameters as the incoming request source, protocol, target node port, etc to flexibly manage access to your containers through setting the required connection rules.

Container Firewall Management via Jelastic UI

Each node at Jelastic PaaS (excluding custom Docker– and Windows-based containers) is provisioned with a set of firewall rules, which can be reviewed and managed through a comfortable graphical user interface. The appropriate section can be accessed by clicking on the Settings button next to the required environment and selecting the Firewall menu item.

954-1-firewall-management-within-dashboard

Here, the following tabs are available:

  • Overview – provides general information on the feature, allows to change Firewall State (which is enabled for all containers by default) and shows Isolated Env Groups the current environment is included to;
  • Inbound Rules – allows to manage incoming requests (not listed ones will be denied by default);
  • Outbound Rules – allows to control outgoing connections (not listed ones will be allowed by default).
Tip: If you want to restrict access between the environments on a single account, it can be automatically configured by means of the Network Isolation feature.

Default Firewall Rules

When you create a new container, Jelastic automatically fills the Inbound and Outbound Rules sections with a number of records, required for the proper container operability.

954-1-default-firewall-rules

Here, rules are grouped by layers and are marked with the following color labels:

  • grey for the default non-editable records (i.e., the obligatory ones);
  • white for other default (stack-related) and user-added (either by an environment owner or his collaborators) rules.
Note: Apply changes to the default rules only in case you know exactly what you are doing, since these records are required to ensure proper stack-specific functionality and to provide particular features support (e.g., to allow SSH, HTTP, HTTPS or FTP connections).

The very first record has the highest priority (1) and allows Jelastic infrastructure to access a container. During further operating with the appropriate server, e.g., performing some management operations (like adding mount points, installing FTP add-on, etc.), the list of default firewall rules can be automatically complemented by the system according to the required preferences. Herewith, each new rule is added with a 10 points priority step, allowing to insert extra ones in between the default records further without the necessity to edit the already applied connection permissions.

Rules Management

For convenient management of the already existing firewall rules and providing the new ones, the tools panel above the list contains a set of buttons, namely: Add, Edit, Remove, Disable (Enable) and Refresh.

954-1-tools-panel-for-convenient-firewall-rules-management

When adding a new firewall rule, the following parameters should be defined:

  • Nodes – to select the required environment layer;
  • Name – to provide the name for this record (can be expanded to select from a number of commonly used rules);
  • Protocol – to set the required protocol type (TCP, UDP or TCP/UDP);
  • Port Range – to define a particular port (e.g., 80) or their range (e.g., 1024-2048) to be opened/closed for connection; leave this field blank to apply the rule to all ports;
  • Source – to select the request source:
    • Custom IP Address(es) – a comma-separated list of IPv4/IPv6 addresses and CIDR blocks (e.g., 10.0.0.1,10.0.0.0/24);
    • Predefined ranges – All, All IPv4, All IPv6, Local Network, Internet (Public Access);
    • Environment Nodes – node type (layer) from any environment on an account (subsequently, this rule will be automatically complemented/diminished with the required node IPs when the appropriate layer is scaled in/out);
  • Priority – to set a rule priority (where rules with lower values will be applied first);
  • Action – to define the required action upon receiving the matching request (either allow or deny).

954-1-parameters-for-new-firewall-rule

Subsequently, if meeting the necessity to Edit any default or custom rule, you’ll be able to adjust all of the above-described parameters except the Nodes field (i.e., target layer cannot be switched). Also, for testing purposes, you can temporarily disable particular rule records and reapply them later on with the appropriate Disable/Enable buttons. And the Refresh button can come in handy to update the list of rules after some server adjustment (e.g., its topology change) without the necessity to restart the whole server.

Firewall Use Cases

Access to your nodes can be controlled basing on such request parameters as its source node’s IP address, connection protocol, port and so on. In the guide below, we’ll consider the basic example of blocking access to a container for a particular IP address, applied via either:

  • User Interface;
  • SSH connection.
Note: Before following this instruction, ensure that the appropriate container is provided with a Public IP address.

Also, when preparing some container life-cycle’s automation solution, you may need to apply the required firewall changes via the Jelastic API – examine the list of the appropriate methods within the linked reference.

Restrict Access via User Interface

So, as it was partly shown above, Jelastic provides a pretty easy-to-use but powerful enough GUI to manage container firewall directly via the dashboard.

1. To access the appropriate control panel, click the Settings button next to the required environment and switch to the Firewall section within the opened tab.

954-1-restrict-access-via-user-interface

Here, select the Inbound Rules tab and click on the Add button (obviously, if the external container traffic should be limited, you’ll need to choose the Outbound Rules subsection, whilst all rule parameters to set will be similar to the described below ones).

2. In the opened Add Inbound Rules form you can configure a new condition for the incoming requests’ processing by a container.

954-1-add-inbound-rules

In order to deny the connection from a particular IP address (according to our suggested use case example), fill in the fields as follows:

  • Nodes – chose a container to restrict access to (tomcat in our case);
  • Name – input any desired rule name (e.g., my-rule);
  • Protocol – select a required protocol (TCP);
  • Port Range – deny access to all ports by leaving this field blank;
  • Source – choose the Custom IP Address(es) option and type the necessary IP address in the appeared IP Address Range field (111.111.111.111);
  • Priority – set the appropriate priority for this record (e.g., 900 to be applied before the default rules);
  • Action – select the Deny option.

Click Add to save and automatically apply your rule.

3. Now, when trying to connect to your node from the specified 111.111.111.111 IP address, a user will be shown the following page:

954-1-deny-access-to-containers-from-any-ip-address

This way you can deny access to your containers from any IP address.

Restrict Access via SSH

Alternatively, you can configure firewall rules for your container via terminal when accessing the node through Jelastic SSH Gate.

Note: All the firewall rules changes, applied via SSH, won’t be displayed within the container firewall settings within dashboard UI. Beside of that, such manually added connection permissions will be of more priority (i.e., will be applied first) than the UI-set ones.

1. The simplest way to access node via SSH is to call the appropriate Web SSH option directly from the Jelastic dashboard – just click the same-named button next to the required node. Once connected, check the /etc/jelastic/metainf.conf file to ensure that container firewall is actually turned on:

cat /etc/jelastic/metainf.conf

954-1-restrict-access-via-ssh

Here, the FIREWALL_ENABLED parameter should be equal to “1”. If not, contact support and request enabling of firewall protection for your account.

2. Next, you need to modify the /etc/sysconfig/iptables-custom file (e.g., with a vim editor):

954-1-configure-container-firewall-rules-via-terminal

3. Declare the required firewall rules using the iptables-save tool format. For example, the following code should be used to deny access from a particular IP address (e.g., 111.111.111.111):

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-I INPUT -s 111.111.111.111 -p tcp -m state –state NEW -m tcp –dport 1111 -j DROP
COMMIT
#

954-1-declare-required-firewall-rules

4. Use the next command to apply your custom firewall settings to the list of container default rules:

sudo /usr/bin/jem firewall fwstart

954-1-custom-firewall-settings-to-container-default-rules

5. Now, you can check the list of the currently operating firewall rules for your container by executing the following command:

sudo /usr/bin/jem firewall list filter -vn

954-1-list-of-current-firewall-rules-for-container

As you can see, now access to your node from the 111.111.111.111 IP address is denied.

Setting Rules via Jelastic API

In some cases (e.g., for custom scripts, automatizations, etc.), you may need to configure firewall rules through the code. To do this, you can use the appropriate methods from the environment > Security section in the Jelastic API documentation:

  • AddRule – creates a new rule;
  • AddRules – adds several rules;
  • EditRule – changes parameters of an existing rule;
  • GetRules – shows a list of rules for the environment;
  • RemoveRule – deletes a rule;
  • RemoveRules – removes several rules;
  • SetFirewallEnabled – switches on a firewall;
  • SetRuleEnabled – enables an existing rule;
  • SetRules – replaces existing rules.

This way, managing your Сontainer Firewall allows you to effectively control availability of nodes on your account and to significantly increase applications security by filtering desired and undesired connections.

Try out yourself by registering a free trial at our Jelastic PaaS platform.

As always, feel free to ask for a help from Jelastic technical expert assistance at Stackoverflow in case you have any questions on your Сontainer Firewall.
SOURCEJelastic, Inc.