mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-23 14:48:51 +01:00
b2c32ccc99
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5001 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
218 lines
8.1 KiB
XML
218 lines
8.1 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<refentry>
|
|
<refmeta>
|
|
<refentrytitle>shorewall-hosts</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>hosts</refname>
|
|
|
|
<refpurpose>Shorewall file</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall/hosts</command>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>This file is used to define zones in terms of subnets and/or
|
|
individual IP addresses. Most simple setups don't need to (should not)
|
|
place anything in this file.</para>
|
|
|
|
<para>The order of entries in this file is not significant in determining
|
|
zone composition. Rather, the order that the zones are defined in
|
|
shorewall-zones(5) determines the order in which the records in this file
|
|
are interpreted.</para>
|
|
|
|
<warning>
|
|
<para>The only time that you need this file is when you have more than
|
|
one zone connected through a single interface.</para>
|
|
</warning>
|
|
|
|
<warning>
|
|
<para>If you have an entry for a zone and interface in
|
|
shorewall-interfaces(5) then do not include any entries in this file for
|
|
that same (zone, interface) pair.</para>
|
|
</warning>
|
|
|
|
<para>The columns in the file are as follows.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ZONE</emphasis> —
|
|
<emphasis>zone-name</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The name of a zone defined in shorewall-zones(5). You may not
|
|
list the firewall zone in this column.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">HOST(S)</emphasis> —
|
|
<emphasis>interface</emphasis>:{[<emphasis>bridge-port</emphasis>:]{<emphasis>address-or-range</emphasis>[<emphasis
|
|
role="bold">,</emphasis><emphasis>address-or-range</emphasis>]...|<emphasis
|
|
role="bold">+</emphasis><emphasis>ipset</emphasis>}[<emphasis>exclusion</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The name of an interface defined in the
|
|
shorewall-interfaces(5) file followed by a colon (":") and a
|
|
comma-separated list whose elements are either:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The IP address of a host.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A network in CIDR format.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>An IP address range of the form
|
|
<emphasis>low.address</emphasis>-<emphasis>high.address</emphasis>.
|
|
Your kernel and iptables must have iprange match support.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A physical <emphasis>bridge-port</emphasis> name; only
|
|
allowed when the interface names a bridge created by the
|
|
<command>brctl(8) addbr</command> command. This port must not be
|
|
defined in shorewall-interfaces(5) and may be optionally
|
|
followed by a colon (":") and a host or network IP or a range.
|
|
See <ulink
|
|
url="http://www.shorewall.net/bridge.html">http://www.shorewall.net/bridge.html</ulink>
|
|
for details. Specifying a physical port name requires that you
|
|
have BRIDGING=Yes in shorewall.conf(5).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of an <emphasis>ipset</emphasis>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<blockquote>
|
|
<para>You may also exclude certain hosts through use of an
|
|
<emphasis>exclusion</emphasis> (see shorewall-exclusion(5).</para>
|
|
</blockquote>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>OPTIONS (Optional) — [<emphasis>option</emphasis>[<emphasis
|
|
role="bold">,</emphasis><emphasis>option</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>A comma-separated list of options from the following list. The
|
|
order in which you list the options is not significant but the list
|
|
should have no embedded white space.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">maclist</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Connection requests from these hosts are compared
|
|
against the contents of shorewall-maclist(5). If this option
|
|
is specified, the interface must be an ethernet NIC or
|
|
equivalent and must be up before Shorewall is started.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">routeback</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Shorewall should set up the infrastructure to pass
|
|
packets from this/these address(es) back to themselves. This
|
|
is necessary if hosts in this group use the services of a
|
|
transparent proxy that is a member of the group or if DNAT is
|
|
used to send requests originating from this group to a server
|
|
in the group.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">blacklist</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>This option only makes sense for ports on a
|
|
bridge.</para>
|
|
|
|
<para>Check packets arriving on this port against the
|
|
shorewall-blacklist(5) file.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">tcpflags</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Packets arriving from these hosts are checked for
|
|
certain illegal combinations of TCP flags. Packets found to
|
|
have such a combination of flags are handled according to the
|
|
setting of TCP_FLAGS_DISPOSITION after having been logged
|
|
according to the setting of TCP_FLAGS_LOG_LEVEL.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">nosmurfs</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>This option only makes sense for ports on a
|
|
bridge.</para>
|
|
|
|
<para>Filter packets for smurfs (packets with a broadcast
|
|
address as the source).</para>
|
|
|
|
<para>Smurfs will be optionally logged based on the setting of
|
|
SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the
|
|
packets are dropped.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ipsec</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>The zone is accessed via a kernel 2.6 ipsec SA. Note
|
|
that if the zone named in the ZONE column is specified as an
|
|
IPSEC zone in the shorewall-zones(5) file then you do NOT need
|
|
to specify the 'ipsec' option here.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>FILES</title>
|
|
|
|
<para>/etc/shorewall/hosts</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See ALSO</title>
|
|
|
|
<para><ulink
|
|
url="http://www.shorewall.net/Documentation.htm#Hosts">http://www.shorewall.net/Documentation.htm#Hosts</ulink></para>
|
|
|
|
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
|
|
shorewall-blacklist(5), shorewall-interfaces(5), shorewall-ipsec(5),
|
|
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
|
|
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
|
|
shorewall-providers(5), shorewall-proxyarp(5), shorewall-route_routes(5),
|
|
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
|
|
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
|
|
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
|
|
</refsect1>
|
|
</refentry> |