Alpine Wall: Difference between revisions

From Alpine Linux
(Created page with "This page outlines a plan for replacing the current Alpine firewall management solution, which is based on Shorewall version 3. == Proposal == We evaluated serveral existing op...")
 
(update link)
 
(15 intermediate revisions by 7 users not shown)
Line 1: Line 1:
This page outlines a plan for replacing the current Alpine firewall
{{obsolete}}
management solution, which is based on Shorewall version 3.
This page is a design and implementation plan for a new firewall
management framework. The new framework addresses the limitations
of Shorewall, which is probably the most common solution used
with Alpine.


== Proposal ==
== Proposal ==
Line 14: Line 17:
As no readily available solution was found, the proposal is to
As no readily available solution was found, the proposal is to
implement a new management framework for <code>iptables</code>, which
implement a new management framework for <code>iptables</code>, which
would integrate with the [[Alpine Configuration Framework
would integrate with the
Design|Alpine Configuration Framework]] (ACF). The framework is
[[Alpine Configuration Framework Design|Alpine Configuration
hereafter referred to as the Alpine Linux Firewall (ALF).
Framework]]
(ACF). The framework is hereafter referred to as the Alpine Wall
({{Pkg|awall}}).


== Design ==
== Design ==


ALF would consist of three major components: data model, front-end,
Awall would consist of three major components: data model, front-end,
and back-end. It also implements a plug-in architecture, which allows
and back-end. It also implements a plug-in architecture, which allows
extending the data model and functionality, in order to simplify
extending the data model and functionality, in order to simplify
Line 29: Line 34:
would also borrow some useful concepts from other firewall solutions
would also borrow some useful concepts from other firewall solutions
we evaluated, such as the Service concept as defined in the
we evaluated, such as the Service concept as defined in the
[http://www.turtlefirewall.com/manual-en/x161.html Turtle Firewall]
[https://web.archive.org/web/20170903195133/http://www.turtlefirewall.com/manual-en/x161.html Turtle Firewall]
(but generalized a bit). ALF plug-ins can contain schema extension
(but generalized a bit). Awall plug-ins can contain schema extension
modules augmenting the basic model provided by the framework.
modules augmenting the basic model provided by the framework.


Line 62: Line 67:
; <code>(protocol, port*)+</code>
; <code>(protocol, port*)+</code>
;Forwarding policy
;Forwarding policy
; <code>Zone:in, Zone:out, accept/reject/drop, masq_on/masq_off</code>
; <code>Zone:in*, Zone:out*, accept/reject/drop, masq_on/masq_off</code>
;Filtering rule
;Filtering rule
; <code>Zone:in, Zone:out, Service, accept/reject/drop, conn_limit?, flow_limit?</code>
; <code>Zone:in*, Zone:out*, Service+, accept/reject/drop, conn_limit?, flow_limit?</code>
;NAT rule
;NAT rule
; <code>snat/dnat, Zone:in, Zone:out, Service, ip4_range, port_range?</code>
; <code>snat/dnat, Zone:in*, Zone:out*, Service, ip4_range, port_range?</code>


Subnets in zone definitions can be declared using IPv4/IPv6 addresses
Subnets in zone definitions can be declared using IPv4/IPv6 addresses
(CIDR notation) or domain names. A domain name can resolve to one or
(CIDR notation), domain names, or as references to
more IP addresses.
[https://ipset.netfilter.org/ipset.man.html ipsets]. A domain name can
resolve to one or more IP addresses. The referred ipsets may be
managed manually or by some other tool.
 
If a packet with source address ''a'' arrives on interface ''i'', it
is considered to originate from zone ''Z = (I, S)'' (where ''I'' is
the set of interfaces and ''S'' is the set of subnets) if and only if
''I'' includes ''i'', and ''a'' belongs to any subnet of ''S''. In
zone definitions, ''I'' would default to the set of all interfaces and
''S'' to {0.0.0.0/0, ::}. The destination zone would be defined in a
similar way based on the packet's destination address and interface.


== Implementation Considerations ==
== Implementation Considerations ==
Line 76: Line 91:
The data model should preferably be based on some existing format,
The data model should preferably be based on some existing format,
such as JSON, XML, or YAML. In order to allow extensions to the data
such as JSON, XML, or YAML. In order to allow extensions to the data
model, ALF must define some kind of schema language. This language
model, awall must define some kind of schema language. This language
would embed the necessary information the front-end needs to
would embed the necessary information the front-end needs to
automatically generate a user interface for the extension. For
automatically generate a user interface for the extension. For
Line 86: Line 101:
requirements on the language, e.g. support for complex data types. If
requirements on the language, e.g. support for complex data types. If
we select this approach and model the data using XML, we could use XML
we select this approach and model the data using XML, we could use XML
Schema as the basis. There is also an (expired) Internet Draft on
Schema as the basis. There is also an (expired) Internet Draft on  
[http://tools.ietf.org/html/draft-zyp-json-schema-03 JSON Schema], but
[https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-03 JSON Schema], but
there seems to be no existing validator implementation in C or Lua.
there seems to be no existing validator implementation in C or Lua.


Line 101: Line 116:
The back-end modules are responsible for translating the configuration
The back-end modules are responsible for translating the configuration
data into configuration file fragments. As regards their
data into configuration file fragments. As regards their
implementation, we have to alternatives. The first alternative is to
implementation, we have two alternatives. The first alternative is to
implement them as Lua functions invoked by the framework in a defined
implement them as Lua functions invoked by the framework in a defined
way. The framework would provide a library that allows the said
way. The framework would provide a library that allows the said
Line 111: Line 126:
using a template language rather than a general-purpose programming
using a template language rather than a general-purpose programming
language. An example of a firewall-related template language is
language. An example of a firewall-related template language is
[http://ferm.foo-projects.org/download/2.1/ferm.html ferm], which
[https://ferm.foo-projects.org/download/2.1/ferm.html ferm]{{insecure url|Expired self-signed certificate}}, which
unfortunately is implemented in Perl. Ferm also lacks certain
unfortunately is implemented in Perl. Ferm also lacks certain
capabilities required to implement e.g. the Zone and Service concepts
capabilities required to implement e.g. the Zone and Service concepts
Line 126: Line 141:
will be stored in the target files, so there will be no need to
will be stored in the target files, so there will be no need to
resolve anything when activating the configuration during boot.
resolve anything when activating the configuration during boot.
== See also ==
* [[Zero-To-Awall]]
* [[How-To Alpine Wall]]
[[Category:Networking]]
[[Category:Security]]
[[Category:Development]]

Latest revision as of 11:42, 25 August 2023

This material is obsolete ...

Please feel free to help us make an up-to-date version. (Discuss)

This page is a design and implementation plan for a new firewall management framework. The new framework addresses the limitations of Shorewall, which is probably the most common solution used with Alpine.

Proposal

We evaluated serveral existing open source projects, none of which satisfied our demanding taste. The existing solutions are either too tied to specific (router) distributions, targeted to home users (with too many assumptions built-in), or depedent on bloated frameworks (usually Perl). Moreover, we would like to keep management of firewall settings and activation of such settings as two separate workflows, which would facilitate centralized management of firewall rules.

As no readily available solution was found, the proposal is to implement a new management framework for iptables, which would integrate with the Alpine Configuration Framework (ACF). The framework is hereafter referred to as the Alpine Wall (awall).

Design

Awall would consist of three major components: data model, front-end, and back-end. It also implements a plug-in architecture, which allows extending the data model and functionality, in order to simplify common organization-specific administrative tasks.

The data model would describe the firewall configuration using concepts and terminology that is roughly compatible with Shorewall. It would also borrow some useful concepts from other firewall solutions we evaluated, such as the Service concept as defined in the Turtle Firewall (but generalized a bit). Awall plug-ins can contain schema extension modules augmenting the basic model provided by the framework.

The back-end is responsible for translating the model's data into configuration files, most notably the files that can be read by iptables-restore and ip6tables-restore. Moreover, it can produce files into e.g. /etc/modprobe.d and /etc/sysctl.d if necessary. When a plug-in extends the data model, it must also provide a back-end module that interprets model extension and translates the data into iptables and other rules. The framework includes a module for interpreting the base model. The framework is responsible for ordering and aggregating the results produced by all modules into actual configuration files.

The front-end is essentially an ACF module which allows editing the data model and activating the changes with the help of the back-end. The front-end implements also a fallback mechanism that prevents the operator from locking himself out by a faulty configuration. The configuration data is stored in text files which can be directly edited. The front-end provides a command line tool for validating and activating the configuration after manual changes.

Base Model

The basic data model could roughly look like as follows:

Zone
interface*, subnet*
Service
(protocol, port*)+
Forwarding policy
Zone:in*, Zone:out*, accept/reject/drop, masq_on/masq_off
Filtering rule
Zone:in*, Zone:out*, Service+, accept/reject/drop, conn_limit?, flow_limit?
NAT rule
snat/dnat, Zone:in*, Zone:out*, Service, ip4_range, port_range?

Subnets in zone definitions can be declared using IPv4/IPv6 addresses (CIDR notation), domain names, or as references to ipsets. A domain name can resolve to one or more IP addresses. The referred ipsets may be managed manually or by some other tool.

If a packet with source address a arrives on interface i, it is considered to originate from zone Z = (I, S) (where I is the set of interfaces and S is the set of subnets) if and only if I includes i, and a belongs to any subnet of S. In zone definitions, I would default to the set of all interfaces and S to {0.0.0.0/0, ::}. The destination zone would be defined in a similar way based on the packet's destination address and interface.

Implementation Considerations

The data model should preferably be based on some existing format, such as JSON, XML, or YAML. In order to allow extensions to the data model, awall must define some kind of schema language. This language would embed the necessary information the front-end needs to automatically generate a user interface for the extension. For example, the help texts shown to the user would be placed in the schema modules.

Ideally, the base model would be described using the very same language as the model extensions, but it would impose quite demanding requirements on the language, e.g. support for complex data types. If we select this approach and model the data using XML, we could use XML Schema as the basis. There is also an (expired) Internet Draft on JSON Schema, but there seems to be no existing validator implementation in C or Lua.

Even though elegant from architecture point of view, it is unlikely that support for complex data types would be required by typical extensions. In most cases, a set of global variables of primitive types would suffice. Therefore, we could just use a very simple language for declaring such variables or implement support for a limited subset of some well-known schema language. In this alternative, the base model would not be described using this language but rather hard-coded into the front-end.

The back-end modules are responsible for translating the configuration data into configuration file fragments. As regards their implementation, we have two alternatives. The first alternative is to implement them as Lua functions invoked by the framework in a defined way. The framework would provide a library that allows the said functions to access the data model, and also otherwise assists in their implementation. The functions would report the results back to the framework, which finally would translate them into target files.

In the second alternative, the back-end modules would be implemented using a template language rather than a general-purpose programming language. An example of a firewall-related template language is ferm 🔓, which unfortunately is implemented in Perl. Ferm also lacks certain capabilities required to implement e.g. the Zone and Service concepts conveniently. However, we could introduce a new template language that would better suit our purposes. Such a language would eliminate some redundancy from the back-end modules which necessarily comes with the use of a general-purpose language. On the other hand, developing and maintaining such a language would take effort and might make the framework initially more difficult to use.

The back-end will contain functionality for domain name resolution. In the data model, hosts of groups thereof can be identified by their domain names. The back-end will resolve these to IP addresses, which will be stored in the target files, so there will be no need to resolve anything when activating the configuration during boot.

See also