|
|
| (63 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| == Configuration File Processing ==
| | {{Delete|All wikilinks on the entire wiki have already been changed to point to the awall guide on git. Nothing points to this article, nor should it}} |
|
| |
|
| [[Alpine Wall]] (awall) reads its configuration from multiple
| | The current Alpine Wall User's Guide is available [https://git.alpinelinux.org/awall/about/ here]. |
| JSON-formatted files, called ''policy files''. The processing starts
| |
| from directory <tt>/usr/share/awall/mandatory</tt>, which contains
| |
| mandatory policy files shipped with APK packages. After that,
| |
| installation-specific policy files in <tt>/etc/awall</tt> are
| |
| processed.
| |
| | |
| The latter directory may also contain symbolic links to policy files
| |
| located in <tt>/usr/share/awall/optional</tt>. These are optional
| |
| policies, which can be enabled on need basis. Such symbolic links are
| |
| easily created and destroyed using the <tt>awall --enable</tt> and
| |
| <tt>awall --disable</tt> commands. <tt>awall --list</tt> shows which
| |
| optional policies are enabled and disabled.
| |
| | |
| Sometimes a policy file depends on other policy files. In this case,
| |
| the policy file must have a top-level attribute <tt>import</tt>, the
| |
| value of which is a list of policy names, which correspond to the file
| |
| names without the <tt>.json</tt> suffix. The policies listed there are
| |
| always processed before the importing policy. The order of the
| |
| generated iptables rules generally reflects the processing order of
| |
| their corresponding awall policies.
| |
| | |
| As the import directive does not require the path name to be
| |
| specified, awall expects policies to have unique names, even if
| |
| located in different directories. It is allowed to import optional
| |
| policies that are not explicitly enabled by the user. Such policies
| |
| show up with the <tt>required</tt> status in the output of <tt>awall
| |
| --list</tt>.
| |
| | |
| == List Parameters ==
| |
| | |
| Several awall parameters are defined as lists of values. In order to
| |
| facilitate manual editing of policy files, awall also accepts single
| |
| values in place of lists. Such values are semantically equivalent to
| |
| lists containing one element.
| |
| | |
| == Variable Expansion ==
| |
| | |
| Awall allows variable definitions in policy files. The top-level
| |
| attribute <tt>variable</tt> is a dictionary containing the
| |
| definitions. The value of a variable can be of any type (string,
| |
| integer, list, or dictionary).
| |
| | |
| A variable is referenced in policy files by a string which equals the
| |
| variable name prepended with the <tt>$</tt> character. If the value of
| |
| the variable is a string, the reference can be embedded into a longer
| |
| string in order to substitute some part of that string (in shell
| |
| style). Variable references can be used when defining other variables,
| |
| as long as the definitions are not circular.
| |
| | |
| Policy files can reference variables defined in other policy
| |
| files. Policy files can also override variables defined elsewhere by
| |
| redefining them. In this case, the new definition affects all policy
| |
| files, also those processed before the overriding policy. Awall
| |
| variables are in fact simple macros, since each variable remains
| |
| constant thoughout a single processing round. If multiple files define
| |
| the same variable, the definition in the file processed last takes
| |
| effect.
| |
| | |
| If defined as an empty string, all non-embedded references to a
| |
| variable evaluate as if the attribute in question was not present in
| |
| the configuration. This is also the case when a string containing
| |
| embedded variable references finally evaluates to an empty string.
| |
| | |
| == Configuration Objects ==
| |
| | |
| Configuration objects can be divided into two main types.
| |
| ''Auxiliary objects'' model high-level concepts such as services and
| |
| zones. ''Rule objects'' translate into one or more iptables rules, and
| |
| are often defined with the help of some auxiliary objects.
| |
| | |
| === Services ===
| |
| | |
| A ''service'' represents a set of network protocols. A top-level
| |
| attribute <tt>service</tt> is a dictionary that maps service names to
| |
| lists of service definition objects. A service definition object
| |
| contains an attribute named <tt>proto</tt>, which corresponds to the
| |
| <tt>--protocol</tt> option of iptables. The protocol can be defined as
| |
| a numerical value or string as defined in <tt>/etc/protocols</tt>.
| |
| | |
| If the protocol is <tt>tcp</tt> or <tt>udp</tt>, the scope of the
| |
| service definition may be constrained by defining an attribute named
| |
| <tt>port</tt>, which is a list of TCP or UDP port numbers.
| |
| | |
| If the protocol is <tt>icmp</tt> or <tt>icmpv6</tt>, an analogous
| |
| <tt>icmp-type</tt> attribute may be used. In addition, the scope of
| |
| the rule is also automatically limited to IPv4 or IPv6, respectively.
| |
| | |
| === Zones ===
| |
| | |
| === Rules ===
| |
| | |
| ==== Filters ====
| |
| | |
| ==== NAT Rules ====
| |
| | |
| === IP Sets ===
| |
| | |
| == Command Line Syntax ==
| |
| | |
| === Generating iptables and ipset Files ===
| |
| | |
| === Activating New Configuration ===
| |
| | |
| === Optional Policies ===
| |
