sysblog

Firewalling (1/5)

About this article

With the fast growing of the Infrastructure as a Service (IaaS) concept, usage and applicability, fueled by the cost-effectiveness demands and high-availability requirements of modern services provided in the cloud, more and more Platform as a Service (PaaS) and Software as a Service (SaaS) providers rush to find the most state of the art, performant and cost-effective IaaS provider to host the very engine of their online businesses.

These demands and the diversity of the requirements of small to medium-scale implementations, may lead to a single PaaS or SaaS provider to host its infrastructure in multiple IaaS providers, directly increasing the complexity, heterogeneity and/or disparity, either logical, virtual or physical, of the design of their globalized infrastructure.

While many IaaS providers already provide multiple services for integrated Firewalling, VPN, QoS, Caching, Load-Balancing, vRacks etc., when an infrastructure is based on a multi-vendor approach, a clean and low cost integration may be difficult to achieve.

This article will be focused on the Firewalling elements of a multi-vendor IaaS infrastructure by addressing ways to implements robust firewalls with simple low-cost solutions already available on the Open-Source Community. One of such solutions is the FWBuilder by Netcitadel, Inc. being it the one that will be referenced to build a hipotetical firewall throughout the main sections of this article.

Structure

This article is structured in five main Sections and five Annexes, enumerated below:

— Section I – Setting up the Skeleton

— Section II – Populating the Policies

— Section III – Deploying the Firewall Objects

— Section IV – Taking Advantage of Traffic Accounting

— Section V – Managing all nodes at once

— Annex I – Compiled Script for Skeleton

— Annex II – Deployment Scripts

— Annex III – SSH and DSA keys

— Annex IV – Monitoring Scripts

— Annex V – VPN: The first wall of defense

Assumptions

The contents of the following sections assume that the reader as some knownledge regarding Infrastructure and Networking design. Altough this article tends to be easy to understand for any professional in the IT business, an average understanding of the two elements pointed above will greatly enhance the experience and, hopefully, learning of the reader.

Base Environment

A minimalistic, hypothetical infrastructure will be described here in order to allow us to design a possible firewalling solution for such scenario. The infrastructure will be formed by two major platform components, being them a simple Webserver Cluster and a simple DBMS Cluster, each consisting of two nodes for core service delivery and another two nodes for High-Availability and Load-Balancing layers:

Webserver Cluster:

* 2 x HAProxy

* 2 x Apache Webserver

Database Cluster:

* 2 x MySQL Proxy

* 2 x MySQL Servers

As we’re assuming a multi-vendor infrastructure, the diverse network nodes are also assumed to be geographically distant, whose IP network addresses will uncontinous, or, in other words, not prone to be configurable in the same subnet. A theoretical addressing scheme, with interface specification, will be also used as described below:

* webclu-proxy-node-01

: eth0 IPv4 : 11.12.13.14 /24

: eth0 IPv6 : 1001:2001:3001:4001::1 /64

: gateway : 11.12.13.1

* webclu-proxy-node-02

: eth0 IPv4 : 20.21.22.23 /24

: eth0 IPv6 : 2001:3001:4001:5001::1 /64

: gateway : 20.21.22.1

* webclu-http-node-01

: eth0 IPv4 : 30.31.32.33 /24

: eth0 IPv6 : 3001:4001:5001:6001::1 /64

: gateway : 30.31.32.1

* webclu-http-node-02

: eth0 IPv4 : 40.41.42.43 /24

: eth0 IPv6 : 4001:5001:6001:7001::1 /64

: gateway : 40.41.42.1

* dbmsclu-proxy-node-01

: eth0 IPv4 : 50.51.52.53 /24

: eth0 IPv6 : 5001:6001:7001:8001::1 /64

: gateway : 50.51.52.1

* dbmsclu-proxy-node-02

: eth0 IPv4 : 60.61.62.63 /24

: eth0 IPv6 : 6001:7001:8001:9001::1 /64

: gateway : 60.61.62.1

* dbmsclu-mysql-node-01

: eth0 IPv4 : 70.71.72.73 /24

: eth0 IPv6 : 7001:8001:9001:1001::1 /64

: gateway : 70.71.72.1

* dbmsclu-mysql-node-02

: eth0 IPv4 : 80.81.82.83 /24

: eth0 IPv6 : 8001:9001:1001:1101::1 /64

: gateway : 80.81.82.1

Section I – Setting up the skeleton

This introductory section, aims to explain the fundamental concepts for proper usage of the FWBuilder interface, from installation of the application itself, to the deployment of the firewall into the configured target nodes.

Each sub-section will address a very specific component of the application and the importance of its role when designing long-term, manageable, firewalls. A few illustrations will be added on each sub-section when a clear idea of the interface is intended to be passed to the reader.

1.1. The FWBuilder

The FWBuilder is an Open-Source project being developed and improved by the Netcitadel, Inc. for more than a decade. It is a Graphical User Interface (GUI) firewall management application, serving as an abstraction layer for many firewall solutions on the market, including iptables, PF, Cisco ASA, Cisco PIX, Cisco FWSM and many more.

It’s centralized and scalable design, allows the management of literally hundreds of firewalls from a single, simple and dependable User Interface (UI).

The combined experience of its developers, sum more than 30 years of hands-on experience in networking and security technologies.

This turns the FWBuilder one of the most used and recommended Open-Source projects regarding firewall manangement.

1.2. Installing the FWBuilder

The FWBuilder can be downloaded from the http://www.fwbuilder.org. Along with an extremely well documented product, the support community around the project grants the users a reliable source of information to solve any issues that may occur.

It can be installed on 3 major Operating Systems (OS): GNU/Linux based, Windows and Mac OS X.

This article will guide the reader through an installation of the FWBuilder in a GNU/Linux OS, more specifically, the Debian 7 OS.

From the command line, enter the following command as superuser:

# apt-get install fwbuilder

This will install the FWBuilder and all it’s dependencies. As soon as the package manager finishes the installation of the newly requested packages, the FWBuilder will be ready to use.

To load the FWBuilder application, execute the following command:

$ fwbuilder

This will load the GUI, which will be explained in the next section.

1.3. User Interface – First Contact

The user will find the UI of the FWbuilder very familiar. It’s a typical and intuitive firewall GUI that allows an easy creation and deployment of firewalls, allowing a true centralized management. When the GUI is loaded, the following window will show:

front

In order to create a new firewall, the “Create new firewall” button should be pressed and the following dialog will show:

create

Here, the “NewFirewall” is set as the name of the firewall object. As we’re creating a firewall object for each of the nodes described in the environment section of this article, this name should be changed to one of the nodes, for example, “webclu-proxy-node-01”.

The initial setup for creating new FWBuilder firewall objects is completed in three simple steps:

The first step is shown above, where the user should set the firewall object name, the target software for which it should be compiled, and the target operating system where the firewall will run.

The second step is shown after clicking the “Next” button, diplaying the following dialog:

create_next

This will allow the user to choose the configuration method for the network interfaces of the target system. In order to cover the the manual interface configuration of the GUI and assuming the target node doesn’t have a SNMP server, we’ll opt to “Configure interfaces manually” by clicking “Next”:

create_next_next

On this dialog, it’s possible to configure the interfaces for the target node by clicking the ‘+’ button and entering the interface settings. If multiple interfaces exist, one can keep pressing the ‘+’ button in order to configure a new network interface for this node. As the interface configuration will be covered through the left context of the GUI interface, one can skip this dialog by clicking the “Finish” button. This will result in the following window to be displayed:

main_window

1.4. Base Firewall Object Structure

As the firewall rules may drastically increase over time for a single firewall object, a good practice to keep the simplicity of the object management is to create an initial base structure of well identified “Policy Rule Sets” (PRS) to allow a fast identification of the traffic processed through them. TheBased on this concept, we’ll create the following PSRs:

– Accounting

– Blacklist

– Default

– Inbound

– Outbound

To create a new PRS, right-click on the firewall object (in this case, the “webclu-proxy-node-01”) and left-click the “New Policy Rule Set” option. To change the PRS name, double-click the newly created PSR named “Policy_1” and change the “Name” field, located at the left-bottom corner of the displayed window. After changing it to “Accounting”, the user should have a similar content as diplayed in the following image:

new_policy

Repeat the steps to create the remaining suggested PSRs, except for “Default”, as this will not require the creation of a new PRS, since the “Policy” PRS can be renamed.

After all the PRSes are created, we’ll need to ‘route’ the traffic to each of the PSRs. This can be acomplished by making use of the “Default” PRS, by inserting “Branch” action rules:

— Configuring Outbound PRS:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Insert New Rule”.

– Right-click on Rule #0 Action column and select “Branch”.

– Drag and Drop the Outbound PRS into the “Policy ruleset object” field.

– Right-click on Rule #0 Direction and select “Outbound”.

— Configuring Inbound PSR:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Bottom”.

– Right-click on Rule #1 Action column and select “Branch”.

– Drag and Drop the Inbound PRS into the “Policy ruleset object” field.

– Right-click on Rule #1 Direction and select “Inbound”.

— Configuring Blacklist PSR:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Top”.

– Right-click on Rule #0 Action column and select “Branch”.

– Drag and Drop the Blacklist PRS into the “Policy ruleset object” field.

– Right-click on Rule #0 Direction and select “Both”.

— Configuring Accounting PSR:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Top”.

– Right-click on Rule #0 Action column and select “Branch”.

– Drag and Drop the Accounting PRS into the “Policy ruleset object” field.

– Right-click on Rule #0 Direction and select “Both”.

— Configuring a Clean-up rule:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Bottom”.

– Right-click on Rule #4 Action column and select “Deny”.

– Right-click on Rule #4 Direction and select “Both”.

The following image illustrates the current configuration:

init_structure

At this moment, any packets entering a specific “Branch” will not be allowed leave unless a “Continue” target is set at the bottom of each branch. In order to do so, the following procedures should be performed:

— Double-click the “Branch”.

— Right-click on the rules dialog and select “Insert New Rule” or “Add New Rule at the Bottom”.

— Right-click on Rule Action column and select “Continue”.

branch_continue

This rule must always be the last on each branch. Failing to do so, will cause any other rule below it to be ignored.

1.5. Configuring Interfaces

Once we skipped the network interface configuration on the previous sub-sections, these procedures will be addressed here. All the procedures here described can be replicated to create other devices in other firewall objects, as well as multiple interfaces on these same objects.

By creating interfaces in the firewall object, the FWbuilder will automatically enforce that configuration when deployed in the target firewall node. This usually is a great advantage, but the user should confirm twice any new or changed configuration, in order to grant that no incorrect settings that could stop the interface from running are present. If that happens, the remote node will stop responding from the misconfigured interface.

To create an interface on a firewall object, proceed as described below:

— Right-click on firewall object “webclu-proxy-node-01”.

— Click “New Interface”.

— Double-click on “Interface”.

— Change the name field to eth0.

— Right-click on “eth0” of the firewall object.

— Click “New Address”.

— Double-click the “webclu-proxy-node-01:eth0:ip” object.

— Change the “Address” field to: 11.12.13.14

— Change the “Netmask” field to: 255.255.255.0

— Right-click on “eth0” of the firewall object.

— Click “New Address IPv6”.

— Double-click the “webclu-proxy-node-01:eth0:ipv6” object.

— Change the “Address” field to: 1001:2001:3001:4001::1

— Change the “Netmask” field to: 64

The following image represent the current interface configuration for the IPv4 address:

interface_ipv4

The following image represent the current interface configuration for the IPv6 address:

interface_ipv6

1.6. Creating Objects

As the images presented in the previous sub-sections show, there’s a “Objects” category on the left dialog of the FWBuilder GUI. This folder contains a set of sub-categories that allow the user to create other types of objects other than firewall nodes and respective dependencies.

For now, we’ll be focused in the “Addresses” sub-category of the “Objects” main category. We’ll rely on this category to create the gateway addresses for each firewall node in order to allow us to configure the Routing table of the firewall (described in the next sub-section).

To create an Address object, go to the left upper corner of the GUI, expand the Objects category and proceed as follows:

— Right-click the “Addresses” category.

— Select “New Address”.

— Change the “Name” field contents to “webclu-proxy-node-01:gw”.

— Change the “Address” field contents to “11.12.13.1”.

address

The image above illustrates the newly created address. The user may now create all the remaining gateway addresses by repeating the specified steps for address creation.

1.7. Setting up the Routing Table

The FWBuilder also supports the configuration and maintenance of the routing table for the target nodes. This is specially useful from the point of view of centralized management for network devices or critical exposed systems.

Altough useful, it still is a dangerous configuration element that must be handled with extremelly care, as a wrong configuration entry may prevent the target node from being able to communicate out of its broadcast domain.

When used, the user must grant that all required routing table entries are configured for that particular firewall object, as the compiled configuration to be deployed, generated by FWBuilder, will replace any current configurations running on that node with the ones defined in the routing Routing Policy.

We’ll only address the default gateway entry for each firewall object referenced in this document. The user must configure any other required Routing entry and ensure that it contains all the required data in order to avoid the node from being unreachable.

The process to configure the default gateway entry in the “Routing” policy is described below:

— Double-click the “Routing” policy entry of the current firewall object.

— Right-click on the “Routing” policy rules panel.

— Select “Insert New Rule”.

— Drag the “webclu-proxy-node-01:gw” Address Object into the “Gateway” field of the Rule #0.

— Drag the “eth0” Interface Object into the “Interface” field of the Rule #0.

— Leave or grant that the “Destination” field of the Rule #0 is set to “Default”.

The following image demonstrates the result of the configuration steps described above:

routing

1.8. Compiling and Testing the Skeleton

We’re now able to compile and test the skeleton for the “webclu-proxy-node-01” firewall object. Since this skeleton isn’t allowing any inbound or outbound traffic yet, our test will be simply a compilation test in order to grant that everything is fine at this stage. The resulting script should not be installed and executed in the target node, as this will cause it to be unreachable.

To compile the skeleton, go to the FWBuilder tool bar and click on the Compile icon. This will open the following dialog:

compile_skeleton

By clicking the “Next” button, the compilation process will start. If everything is correctly configured, no errors nor warnings will occur. If the compilation process detects any errors or warnings, please review all the steps from the beggining of this document in order to fix any issues that may exist. After the compilation process is complete, the following dialog will show:

compile_skeleton_finish

The user may click on the “Inspect generated files” button to further analyze the resulting script and grant that everything is correctly generated. A copy of the resulting script from the current configuration can be found on Annex I – Compiled Script for Skeleton.

By clicking “Finish”, the dialog will close and the user will return to the main GUI window.

1.9. Section Final Thoughts

Thoughout this section, we’ve analyzed and/or reviewed some of the most important configuation elements of the FWBuilder. The user should now be familiarized with the GUI and have a clear “big picture” of the overall GUI functionalities.

The next sections will focus on creating the firewall rules for each of the hypothetical nodes described in the beggining of this document, as well as the steps for automated installation of the generated firewalls.

A final section (Section IV) will address some important aspects of the “Accounting” PRS, which will allow the integration of those results with a monitoring system.

Annex I – Compiled Script for Skeleton

annex1_firewalling

Autor: Pedro Hortas @ SysValue