bionic (5) firehol-return.5.gz

Provided by: firehol-doc_3.1.5+ds-1ubuntu1_all bug

NAME

       firehol-actions - actions for rules

SYNOPSIS

       accept

       accept      with     hashlimit     name     upto|above     amount/period     [burst     amount]     [mode
       {srcip|srcport|dstip|dstport},...] [srcmask prefix] [dstmask prefix]  [htable-size  buckets]  [htable-max
       entries] [htable-expire msec] [htable-gcinterval msec]

       accept with connlimit upto|above limit [mask mask] [saddr|daddr]

       accept with limit requests/period burst [overflow action]

       accept with recent name seconds hits

       accept with knock name

       reject [with message]

       drop | deny

       return

       tarpit

DESCRIPTION

       These actions are the actions to be taken on traffic that has been matched by a particular rule.

       FireHOL  will  also  pass through any actions that iptables(8) accepts, however these definitions provide
       lowercase versions which accept arguments where appropriate and  which  could  otherwise  not  be  passed
       through.

              Note

              The  iptables(8)  LOG action is best used through the optional rule parameter log since the latter
              can be combined with one of these actions (FireHOL will generate multiple firewall rules  to  make
              this happen).  For more information see log and loglimit.

       The following actions are defined:

   accept
       accept allows the traffic matching the rules to reach its destination.

       For example, to allow SMTP requests and their replies to flow:

              server smtp accept

   accept with hashlimit name upto|above
       amount/period  [burst  amount] [mode {srcip|srcport|dstip|dstport},...] [srcmask prefix] [dstmask prefix]
       [htable-size buckets] [htable-max entries] [htable-expire msec] [htable-gcinterval msec]

       hashlimit hashlimit uses hash buckets to express a rate limiting match (like the limit match) for a group
       of  connections  using  a  single  iptables  rule.   Grouping  can  be  done per-hostgroup (source and/or
       destination address) and/or per-port.

       name The name for the /proc/net/ipt_hashlimit/name entry.

       upto amount[/second|/minute|/hour|/day] Match if the rate is below or equal  to  amount/quantum.   It  is
       specified either as a number, with an optional time quantum suffix (the default is 3/hour).

       above amount[/second|/minute|/hour|/day] Match if the rate is above amount/quantum.

       burst amount Maximum initial number of packets to match: this number gets recharged by one every time the
       limit specified above is not reached, up to this number; the default is 5.  This option  should  be  used
       with caution - if the entry expires, the burst value is reset too.

       mode  {srcip|srcport|dstip|dstport},... A comma-separated list of objects to take into consideration.  If
       no mode option is given, srcip,dstport is assumed.

       srcmask prefix When --hashlimit-mode srcip is used, all source  addresses  encountered  will  be  grouped
       according to the given prefix length and the so-created subnet will be subject to hashlimit.  prefix must
       be between (inclusive) 0 and 32.  Note that srcmask 0 is basically doing the same thing as not specifying
       srcip for mode, but is technically more expensive.

       dstmask prefix Like srcmask, but for destination addresses.

       htable-size buckets The number of buckets of the hash table

       htable-max entries Maximum entries in the hash.

       htable-expire msec After how many milliseconds do hash entries expire.

       htable-gcinterval msec How many milliseconds between garbage collection intervals.

       Examples:

       Allow up to 5 connections per second per client to SMTP server:

              server smtp accept with hashlimit smtplimit upto 5/s

       You can monitor it using the file /proc/net/ipt_hashlimit/smtplimit

   accept with connlimit upto|above limit [mask mask]
       [saddr|daddr]

       accept with connlimit matches on the number of connections per IP.

       saddr  matches  on source IP.  daddr matches on destination IP.  mask groups IPs with the mask given upto
       matches when the number of connections is up to  the  given  limit  above  matches  when  the  number  of
       connections above to the given limit

       The  number  of  connections  counted  are system wide, not service specific.  For example for saddr, you
       cannot connlimit 2 connections for SSH and 4 for SMTP.  If you connlimit 2 connections for SSH, then  the
       first  2  connections  of a client can be SSH.  If a client has already 2 connections to another service,
       the client will not be able to connect to SSH.

       So, connlimit can safely be used:

       • with daddr to limit the connections a server can accept

       • with saddr to limit the total connections per client to all services.

   accept with limit requests/period burst [overflow
       action]

       accept with limit allows the traffic, with new connections limited  to  requests/period  with  a  maximum
       burst.  Run iptables -m limit --help for more information.

       The default overflow action is to REJECT the excess connections (DROP would produce timeouts on otherwise
       valid service clients).

       Examples:

              server smtp accept with limit 10/sec 100

              server smtp accept with limit 10/sec 100 overflow drop

   accept with recent name seconds hits
       accept with recent allows the traffic matching the rules to reach its destination, limited per remote  IP
       to hits per seconds.  Run iptables -m recent --help for more information.

       The name parameter is used to allow multiple rules to share the same table of recent IPs.

       For example, to allow only 2 connections every 60 seconds per remote IP, to the smtp server:

              server smtp accept with recent mail 60 2

              Note

              When  a  new connection is not allowed, the traffic will continue to be matched by the rest of the
              firewall.  In other words, if the traffic is not allowed due to the limitations set  here,  it  is
              not dropped, it is just not matched by this rule.

   accept with knock name
       accept with knock allows easy integration with knockd (http://www.zeroflux.org/projects/knock/), a server
       that allows you to control access to services by sending certain packets to "knock" on the  door,  before
       the door is opened for service.

       The  name  is  used  to  build  a  special  chain  knock_<name> which contains rules to allow established
       connections to work.  If knockd has not allowed new connections any traffic entering this chain will just
       return back and continue to match against the other rules until the end of the firewall.

       For example, to allow HTTPS requests based on a knock write:

              server https accept with knock hidden

       then configure knockd to enable the HTTPS service with:

              iptables -A knock_hidden -s %IP% -j ACCEPT

       and disable it with:

              iptables -D knock_hidden -s %IP% -j ACCEPT

       You can use the same knock name in more than one FireHOL rule to enable/disable all the services based on
       a single knockd configuration entry.

              Note

              There is no need to match  anything  other  than  the  IP  in  knockd.   FireHOL  already  matches
              everything else needed for its rules to work.

   reject
       reject discards the traffic matching the rules and sends a rejecting message back to the sender.

   reject with message
       When used with with the specific message to return can be specified.  Run iptables -j REJECT --help for a
       list of the --reject-with values which can be used for  message.   See  REJECT  WITH  MESSAGES  for  some
       examples.

       The  default  (no  message  specified)  is  to  send  tcp-reset  when  dealing  with  TCP connections and
       icmp-port-unreachable for all other protocols.

       For example:

              UNMATCHED_INPUT_POLICY="reject with host-prohib"

              policy reject with host-unreach

              server ident reject with tcp-reset

   drop; deny
       drop discards the traffic matching the rules.  It does so silently and the sender will need to timeout to
       conclude it cannot reach the service.

       deny is a synonym for drop.  For example, either of these would silently discard SMTP traffic:

              server smtp drop

              server smtp deny

   return
       return will return the flow of processing to the parent of the current command.

       Currently, the only time return can be used meaningfully used is as a policy for an interface definition.
       Unmatched traffic will continue being processed  with  the  possibility  of  being  matched  by  a  later
       definition.  For example:

              policy return

   tarpit
       tarpit captures and holds incoming TCP connections open.

       Connections  are  accepted  and  immediately  switched to the persist state (0 byte window), in which the
       remote side stops sending data and asks to continue every 60-240 seconds.

       Attempts to close the connection are ignored, forcing the remote side to time out  the  connection  after
       12-24 minutes.

       Example:

              server smtp tarpit

              Note

              As  the  kernel conntrack modules are always loaded by FireHOL, some per-connection resources will
              be consumed.  See this bug report (http://bugs.sanewall.org/sanewall/issues/10) for details.

       The following actions also exist but should not be used under normal circumstances:

   mirror
       mirror returns the traffic it receives by switching the source and destination fields.   REJECT  will  be
       used for traffic generated by the local host.

              Warning

              The MIRROR target was removed from the Linux kernel due to its security implications.

              MIRROR is dangerous; use it with care and only if you understand what you are doing.

   redirect; redirect to-port port
       redirect is used internally by FireHOL helper commands.

       Only FireHOL developers should need to use this action directly.

REJECT WITH MESSAGES

       The following RFCs contain information relevant to these messages:

       • RFC 1812 (http://www.ietf.org/rfc/rfc1812.txt)

       • RFC 1122 (http://www.ietf.org/rfc/rfc1122.txt)

       • RFC 792 (http://www.ietf.org/rfc/rfc0792.txt)

       icmp-net-unreachable; net-unreach
         ICMP network unreachable

         Generated by a router if a forwarding path (route) to the destination network is not available.

         From RFC 1812, section 5.2.7.1.  See RFC 1812 and RFC 792.

                Note

                Use  with  care.   The  sender  and the routers between you and the sender may conclude that the
                whole network your host resides in is unreachable, and prevent other traffic from reaching you.

       icmp-host-unreachable; host-unreach
         ICMP host unreachable

         Generated by a router if a forwarding path (route) to the destination  host  on  a  directly  connected
         network is not available (does not respond to ARP).

         From RFC 1812, section 5.2.7.1.  See RFC 1812 and RFC 792.

                Note

                Use  with  care.   The  sender and the routers between you and the sender may conclude that your
                host is entirely unreachable, and prevent other traffic from reaching you.

       icmp-proto-unreachable; proto-unreach
         ICMP protocol unreachable

         Generated if the transport protocol designated in a datagram is not supported in the transport layer of
         the final destination.

         From RFC 1812, section 5.2.7.1.  See RFC 1812 and RFC 792.

       icmp-port-unreachable; port-unreach
         ICMP port unreachable

         Generated  if  the  designated  transport  protocol (e.g.  TCP, UDP, etc.) is unable to demultiplex the
         datagram in the transport layer of the final destination but has no protocol mechanism  to  inform  the
         sender.

         From RFC 1812, section 5.2.7.1.  See RFC 1812 and RFC 792.

         Generated by hosts to indicate that the required port is not active.

       icmp-net-prohibited; net-prohib
         ICMP communication with destination network administratively prohibited

         This  code  was  intended  for  use  by  end-to-end encryption devices used by U.S.  military agencies.
         Routers SHOULD use the newly defined  Code  13  (Communication  Administratively  Prohibited)  if  they
         administratively filter packets.

         From RFC 1812, section 5.2.7.1.  See RFC 1812 and RFC 1122.

                Note

                This message may not be widely understood.

       icmp-host-prohibited; host-prohib
         ICMP communication with destination host administratively prohibited

         This  code  was  intended  for  use  by  end-to-end encryption devices used by U.S.  military agencies.
         Routers SHOULD use the newly defined  Code  13  (Communication  Administratively  Prohibited)  if  they
         administratively filter packets.

         From RFC 1812, section 5.2.7.1.  See RFC 1812 and RFC 1122.

                Note

                This message may not be widely understood.

       tcp-reset
         TCP RST

         The port unreachable message of the TCP stack.

         See RFC 1122.

                Note

                tcp-reset  is useful when you want to prevent timeouts on rejected TCP services where the client
                incorrectly ignores ICMP port unreachable messages.

SEE ALSO

firehol(1) - FireHOL program

       • firehol.conf(5) - FireHOL configuration

       • firehol-interface(5) - interface definition

       • firehol-router(5) - router definition

       • firehol-params(5) - optional rule parameters

       • FireHOL Website (http://firehol.org/)

       • FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

       • FireHOL Online Documentation (http://firehol.org/documentation/)

AUTHORS

       FireHOL Team.