SHOREWALL-BLRULES(5) | [FIXME: manual] | SHOREWALL-BLRULES(5) |
NAME¶
blrules - shorewall Blacklist fileSYNOPSIS¶
/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[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. ACTION- {ACCEPT|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
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:
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[1](5)).
For the remaining columns, see shorewall-rules (5)[2].
Added in Shorewall 4.5.3. This is actually a
macro that expands as follows:
blacklog
•If BLACKLIST_LOGLEVEL is specified in
shorewall.conf[1](5), then the macro expands to blacklog.
•Otherwise it expands to the action
specified for BLACKLIST_DISPOSITION in shorewall.conf[1](5).
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).
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 backend logging
daemon via a netlink socket then continues to the next rule. See
http://www.shorewall.net/shorewall_logging.html[3].
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.
action
The name of an action declared in
shorewall-actions[4](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).
•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.
EXAMPLE¶
Example 1:Drop Teredo packets from the net.
Example 2:
DROP net:[2001::/32] all
Don't subject packets from 2001:DB8::/64 to
the remaining rules in the file.
WHITELIST net:[2001:DB8::/64] all
FILES¶
/etc/shorewall/blrulesSEE ALSO¶
http://shorewall.net/blacklisting_support.htm http://shorewall.net/configuration_file_basics.htm#Pairs 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-rtrules(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), shorewall-zones(5)NOTES¶
- 1.
- shorewall.conf
- 2.
- shorewall-rules (5)
- 4.
- shorewall-actions
06/28/2012 | [FIXME: source] |