Provided by: shorewall_4.4.26.1-1_all bug


       blrules - shorewall Blacklist file




       This file is used to perform blacklisting and whitelisting.

       Rules in this file are applied depending on the setting of
       BLACKLISTNEWONLY in shorewall.conf[1](5). If BLACKLISTNEWONLY=No, then
       they are applied regardless of the connection tracking state of the
       packet. If BLACKLISTNEWONLY=Yes, they are applied to connections in the
       NEW and INVALID states.

       The format of rules in this file is the same as the format of rules in
       shorewall-rules (5)[2]. The differece in the two files lies in the
       ACTION (first) column.

           Specifies the action to be taken if the packet matches the rule.
           Must be one of the following.

               May only be used if BLACKLIST_LOGLEVEL is specified in
               shorewall.conf[1](5). Logs, audits (if specified) and applies
               the BLACKLIST_DISPOSITION specified in shorewall.conf[1] (5).

               Exempt the packet from the remaining rules in this file.

               Ignore the packet.

           A_DROP and A_DROP!
               Audited versions of DROP. Requires AUDIT_TARGET support in the
               kernel and ip6tables.

               disallow the packet and return an icmp-unreachable or an RST

               Audited versions of REJECT. Require AUDIT_TARGET support in the
               kernel and ip6tables.

               Simply log the packet and continue with the next rule.

               Queue the packet to a user-space application such as ftwall
               ( The application may reinsert the
               packet for further processing.

               queues matching packets to a backend logging daemon via a
               netlink socket then continues to the next rule. See

               Queues the packet to a user-space application using the
               nfnetlink_queue mechanism. If a queuenumber is not specified,
               queue zero (0) is assumed.

               the rest of the line will be attached as a comment to the
               Netfilter rule(s) generated by the following entries. The
               comment will appear delimited by "/* ... */" in the output of
               "shorewall show <chain>". To stop the comment from being
               attached to further rules, simply include COMMENT on a line by

               The name of an action declared in shorewall-actions[4](5) or in

               The name of a macro defined in a file named macro.macro. If the
               macro accepts an action parameter (Look at the macro source to
               see if it has PARAM in the TARGET column) then the macro name
               is followed by the parenthesized target (ACCEPT, DROP, REJECT,
               ...) to be substituted for the parameter.

               Example: FTP(ACCEPT).

           The ACTION may optionally be followed by ":" and a syslog log level
           (e.g, REJECT:info or Web(ACCEPT):debug). This causes the packet to
           be logged at the specified level.

           If the ACTION names an action declared in shorewall-actions[4](5)
           or in /usr/share/shorewall/actions.std then:

           ·   If the log level is followed by "!' then all rules in the
               action are logged at the log level.

           ·   If the log level is not followed by "!" then only those rules
               in the action that do not specify logging are logged at the
               specified level.

           ·   The special log level none!  suppresses logging by the action.

           You may also specify NFLOG (must be in upper case) as a log
           level.This will log to the NFLOG target for routing to a separate
           log through use of ulogd

           Actions specifying logging may be followed by a log tag (a string
           of alphanumeric characters) which is appended to the string
           generated by the LOGPREFIX (in shorewall.conf[1](5)).

       For the remaining columns, see shorewall-rules (5)[2].


       Example 1:
           Drop Teredo packets from the net.

               DROP          net:[2001::/32]            all

       Example 2:
           Don't subject packets from 2001:DB8::/64 to the remaining rules in
           the file.

               WHITELIST     net:[2001:DB8::/64]        all




       shorewall(8), shorewall-accounting(5), shorewall-actions(5),
       shorewall-hosts(5), shorewall-interfaces(5), shorewall-maclist(5),
       shoewall6-netmap(5),shorewall-params(5), shorewall-policy(5),
       shorewall-providers(5), shorewall-route_rules(5),
       shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
       shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
       shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),


        1. shorewall.conf

        2. shorewall-rules (5)


        4. shorewall-actions

[FIXME: source]                   12/13/2011              SHOREWALL-BLRULES(5)