shorewall-blrules
5
blrules
shorewall Blacklist file
/etc/shorewall/blrules
Description
This file is used to perform blacklisting and whitelisting.
Rules in this file are applied depending on the setting of
BLACKLISTNEWONLY in shorewall.conf(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). The
difference in the two files lies in the ACTION (first) column.
ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]]
Specifies the action to be taken if the packet matches the
rule. Must be one of the following.
BLACKLIST
Added in Shorewall 4.5.3. This is actually a macro that
expands as follows:
If BLACKLIST_LOGLEVEL is specified in shorewall.conf(5), then
the macro expands to blacklog.
Otherwise it expands to the action specified for
BLACKLIST_DISPOSITION in shorewall.conf(5).
blacklog
May only be used if BLACKLIST_LOGLEVEL is specified in
shorewall.conf (5).
Logs, audits (if specified) and applies the
BLACKLIST_DISPOSITION specified in shorewall.conf (5).
ACCEPT|CONTINUE|WHITELIST
Exempt the packet from the remaining rules in this
file.
DROP
Ignore the packet.
A_DROP and A_DROP!
Audited versions of DROP. Requires AUDIT_TARGET support
in the kernel and ip6tables.
REJECT
disallow the packet and return an icmp-unreachable or an
RST packet.
A_REJECT
Audited versions of REJECT. Require AUDIT_TARGET support
in the kernel and ip6tables.
LOG
Simply log the packet and continue with the next
rule.
QUEUE
Queue the packet to a user-space application such as
ftwall (http://p2pwall.sf.net). The application may reinsert
the packet for further processing.
NFLOG[(nflog-parameters)]
queues matching packets to a back end logging daemon via
a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html.
NFQUEUE
Queues the packet to a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not specified, queue
zero (0) is assumed.
[?]COMMENT
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
itself.
Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.
action
The name of an action declared in
shorewall-actions(5) or
in /usr/share/shorewall/actions.std.
macro
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(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 (http://www.netfilter.org/projects/ulogd/index.html).
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(5)).
For the remaining columns, see shorewall-rules (5).
Example
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
FILES
/etc/shorewall/blrules
See ALSO
http://www.shorewall.net/blacklisting_support.htm
http://www.shorewall.net/configuration_file_basics.htm#Pairs
shorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-hosts(5), shorewall-interfaces(5), shorewall-maclist(5),
shorewall6-netmap(5),shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-rtrules(5), shorewall-routestopped(5),
shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-mangle(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)