<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - manpage: mention that REJECT should be used with care"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=988">988</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>manpage: mention that REJECT should be used with care
</td>
</tr>
<tr>
<th>Product</th>
<td>iptables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>iptables
</td>
</tr>
<tr>
<th>Assignee</th>
<td>netfilter-buglog@lists.netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vda.linux@googlemail.com
</td>
</tr></table>
<p>
<div>
<pre>I've got a user report. They are using the following set of rules:
-m state --state ESTABLISHED,RELATED -j ACCEPT
-m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
...<more open port snipped>...
-j REJECT --reject-with icmp-host-prohibited
and they experience aborted TCP connections. After much investigation,
the root cause was found to be ACKs with invalid checksums
not matching "-m state --state ESTABLISHED,RELATED", and therefore
falling through to the last rule.
I think that this behavior is in fact correct, so I'll propose to my users
to close it as NOTABUG and fix their rules to drop invalid packets.
Sadly, this behavior is also *not obvious*:
the above rule set looks okay at the first glance.
I propose to amend iptables manpage to help future poor victims of this quirk.
In fact, manpage doesn't mention REJECT target at all, so let's fix that too.
A pseudo-patch follows:
TARGETS
A firewall rule specifies criteria for a packet and a target. If the
packet does not match, the next rule in the chain is the examined; if
it does match, then the next rule is specified by the value of the tar‐
get, which can be the name of a user-defined chain or one of the spe‐
- cial values ACCEPT, DROP, QUEUE or RETURN.
+ cial values ACCEPT, DROP, REJECT, QUEUE or RETURN.
ACCEPT means to let the packet through. DROP means to drop the packet
on the floor. QUEUE means to pass the packet to userspace. (How the
packet can be received by a userspace process differs by the particular
queue handler. 2.4.x and 2.6.x kernels up to 2.6.13 include the
ip_queue queue handler. Kernels 2.6.14 and later additionally include
the nfnetlink_queue queue handler. Packets with a target of QUEUE will
be sent to queue number '0' in this case. Please also see the NFQUEUE
target as described later in this man page.) RETURN means stop
traversing this chain and resume at the next rule in the previous
(calling) chain. If the end of a built-in chain is reached or a rule
in a built-in chain with target RETURN is matched, the target specified
by the chain policy determines the fate of the packet.
+ REJECT discards the packet just like DROP does, but it also sends back +
an error message to the host sending the packet that was blocked.
+ Note that overzealous use of this target can break your networking
+ by generating spurious connection aborts when an unexpected packet
+ is seen. It is advisable to REJECT only packets in specific state
+ (for example, "iptables -A INPUT -m state --state NEW -j REJECT"
+ and drop the rest: "iptables -A INPUT -j DROP")
+ and/or drop invalid packets before rejecting the rest
+ ("iptables -A INPUT -m state --state INVALID -j DROP" before a generic
+ "iptables -A INPUT -j REJECT")
TABLES
- There are currently three independent tables (which tables are present
+ There are several independent tables (which tables are present
at any time depends on the kernel configuration options and which mod‐
ules are present).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>