sanewall-actions, sanewall-accept, sanewall-deny, sanewall-drop,
- Provided by: sanewall-doc (Version: 1.0.2+ds-2)
- Source: sanewall
- Report a bug
accept
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
These actions are the actions to be taken on traffic that has been matched by a particular rule.
Sanewall 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.
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 (Sanewall will generate multiple firewall rules to make this happen). For information on log and loglimit, see optional rule parameters: sanewall-rule-params(5).
The following actions are defined:
accept
For example, to allow SMTP requests and their replies to flow:
server smtp accept
accept with limit
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
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
accept with knock
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 Sanewall rule to enable/disable all the services based on a single knockd configuration entry.
reject with message, reject
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 the section called “REJECT WITH MESSSAGES” 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
deny is a synonym for drop. For example, either of these would silently discard SMTP traffic:
server smtp drop
server smtp deny
return
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
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
The following actions also exist but should not be used under normal circumstances:
mirror
MIRROR is dangerous; use it with care and only if you understand what you are doing.
redirect, redirect to-port port
Only Sanewall developers should need to use this action directly.
The following RFCs contain information relevant to these messages:
RFC 1812[3]
RFC 1122[4]
RFC 792[5]
icmp-net-unreachable, net-unreach
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.
icmp-host-unreachable, host-unreach
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.
icmp-proto-unreachable, proto-unreach
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
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
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.
icmp-host-prohibited, host-prohib
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.
tcp-reset
The port unreachable message of the TCP stack.
See RFC 1122.
Sanewall Team
Copyright © 2012, 2013 Phil Whineray <phil@sanewall.org>