Container Firewall Rules Management

Container Firewall Management via Platform UI

An easy-to-use graphical interface allows users to examine and modify the predefined set of firewall rules that are installed on every node on the platform, with the exception of bespoke Docker and Windows-based containers. Click the Settings button next to the preferred environment to open this section, then select the Firewall option from the menu.

The Following Tabs Are Located Here

• Overview: This page provides broad details regarding the firewall function. You can view the Isolated Environment Groups that the current environment belongs to and change the Firewall State, which is enabled by default for all containers.
• Inbound Rules: You can control inbound requests using this tab. By default, requests that are not on this list are turned down.
• Outbound Rules: This tab allows you to control outgoing connections. Connections that are not listed here are allowed by default.

Default Firewall Rules

The Inbound and Outbound Rules sections of a newly created container are automatically filled in by the platform with the information required for the container to function correctly.

The rules in this instance are arranged in layers and follow this structure:

• The first record has the highest priority (1), is gray-colored (non-editable/mandatory), and grants platform infrastructure access to containers for managing tasks such as SSH key generation, configuration generation, password resets, script execution, and so forth.
  • Access to the relevant services is made available to SSH Gate and Web SSH services.
  • The container can be accessed without a public IP address thanks to shared load balancers.
• User-added and default rules (connected to the stack) are also included.

Because it has the lowest priority (65535), this non-editable gray record is always the last one to be created and prevents any incoming connections that violate the previously stated restrictions.

In order to accommodate new needs, the platform can automatically update the set of default firewall rules while dealing with the container (e.g., adding mount points, installing FTP add-ons, etc.). A 10-point priority step is added to each default record, allowing custom rules to be put in between.

Adding Container Default Rules

You can use the OPEN_INBOUND_PORTS environment variable to define custom ports that the container firewall should open during node construction if necessary, such as for automation solutions.

Step 1. Go to the dashboard, pick “New Environment,” choose the software stack you want, and then go to the Variables settings area.

Step 2. Enter a new variable named OPEN_INBOUND_PORTS in the specified format:

"OPEN_INBOUND_PORTS": "{port1}, {port2}, ... , {portN}"

In this case, {portN} represents either a specific port (e.g., 1234) or a range of ports (e.g., 33062-34000) that will be opened in the inbound firewall rules (for both TCP and UDP protocols) once the container is created.

Step 3. After the container is created, you can review the firewall rules that have been applied.

Rules Management

The tools panel above the list has a series of buttons that make it easier to manage current firewall rules and add new ones: Add, Edit, Remove, Disable (Enable), and Refresh.

When creating a new firewall rule, the following parameters must be entered:

Select the necessary environment layer for nodes.

• Name: Give this record a name (you can choose from frequently used presets).
• Protocol: Select the TCP, UDP, or TCP/UDP protocol type.
• Port Range: Indicate which ports should be opened or closed for connections. For example, you can specify port 80 or a range of ports, 1024–2048. If you want the rule to apply to all ports, leave this box empty.
• Source: Choose the source of the request:
• Personalized IP Address(es): CIDR blocks and IPv4/IPv6 addresses separated by commas (e.g., 10.0.0.1, 10.0.0.0/24).
• Predefined ranges: Internet (Public Access), Local Network, All, All IPv4, All IPv6.
• Environment Nodes: Any sort of node (layer) from any environment in your account may be used; when a layer is scaled in or out, this rule is automatically updated with the necessary IP addresses.
• Priority: Establish the order in which the rules are applied (lower values are applied first).
• Action: Specify what to do (allow or deny) in response to a matching request.

All of the parameters mentioned above can be adjusted if necessary for any default or custom rule, with the exception of the Nodes field, which cannot have its target layer altered. You can use the Disable/Enable buttons to temporarily disable certain rules for testing purposes and then re-enable them at a later time. When the server undergoes modifications (like a topology change), the Refresh button can be used to update the set of rules without having to restart the whole thing.

Firewall Use Cases

Using request parameters such as the IP address, connection protocol, and port of the originating node, you may manage who can access your nodes. In the guide that follows, we’ll examine a basic example of preventing a certain IP address from accessing a container by using either:

1. User Interface
2. SSH Connection

Additionally, you may need to use the platform API to make firewall adjustments if you’re building up an automation solution for container lifecycle management. For a list of pertinent techniques, see the reference that has been provided.

Restrict Access via User Interface

As previously shown, the platform provides an easy-to-use and reliable graphical user interface (GUI) for controlling container firewall settings straight from the dashboard.

Step 1. To open the control panel, click the Settings button next to the environment you want to use, then open the tab and go to the Firewall section.

Go to the Inbound Rules tab and select Add from there. On the other hand, if you want to control container traffic leaving the system, select the Outbound Rules tab; the parameters for the rules are similar to what’s explained below.

Step 2. You may set up additional requirements for a container to process incoming requests within the opened Add Inbound Rules box.

To restrict a connection from a specific IP (as per our example), complete the fields as outlined:

• Nodes: Choose the container (like Tomcat) to which access has to be restricted.
• Name: Type in the required rule name (my-rule, for example).
• Protocol: Select the necessary TCP protocol.
• Port Range: To prevent access to any port, leave this field empty.
• Source: Select Custom IP Address(es) and enter the required IP address (e.g., 111.111.111.111) in the IP Address Range field that is supplied.
• Priority: Give this rule a suitable number (such as 900 to apply it before default rules).
• Take Action: Select Deny.
• To store and apply your rule automatically, click Add.

Step 3. When attempting to connect to your node from the specified IP address (111.111.111.111), users will encounter the following page.

By following these steps, you can effectively restrict access to your containers from any specified IP address.

Restrict Access via SSH

Alternatively, while gaining access to the node via SSH Gate, you can directly define firewall rules for your container via the terminal.

Step 1. Using the Web SSH option straight from the platform dashboard is the simplest way to gain SSH access to a node. Simply click on the button that corresponds to the node you require. After you’re connected, make sure the container firewall is turned on by looking in the /etc/jelastic/metainf.conf file.

cat /etc/jelastic/meta info.conf

Make sure that the /etc/jelastic/metainf.conf file’s FIREWALL_ENABLED value is set to “1” in this scenario. Get in touch with your hosting company to activate firewall protection for your account if it’s not set up properly.

Step 2. Then, using a text editor such as vim, you will need to alter the /etc/sysconfig/iptables-custom file.

To set up firewall rules, use the iptables-save tool format. For instance, to block access from a specific IP address like 111.111.111.111, you can use the following command:
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
\#

Step 4. Apply your custom firewall settings to the list of container default rules using the following command:

sudo /usr/bin/jem firewall fwstart

Step 5. Now, you can view the list of currently active firewall rules for your container by running the following command:

sudo jem firewall list {table} {options}

Here:

1. {table} – specifies the target iptable (filter, nat, mangle, raw)
2. {options} – lists iptable parameters, which should be applied

Your custom rule has been applied after the default rules, effectively denying access to your node from the IP address 111.111.111.111.

Setting Rules via Platform API

Firewall rules may need to be configured programmatically for specific purposes, such as automation or custom scripts. The relevant techniques listed in the environment > Security part of the platform API specification can be used to do this:

• AddRule: Establishes a fresh rule.
• AddRules: Inserts additional rules.
• EditRule: Adjusts a rule’s parameters that already exist.
• GetRules: Shows the environment’s rules list – RemoveRule: Deletes a rule
• RemoveRules: Gets rid of several rules
• SetFirewallEnabled: Makes the firewall operational.
• SetRuleEnabled: This activates a pre-existing rule.
• SetRules: Switches out the current rules

By filtering both desirable and undesired connections, you can greatly improve application security and efficiently manage node accessibility on your account by configuring your Container Firewall in this manner.