1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
This is used to send back an error packet in response to the matched
packet: otherwise it is equivalent to
.B DROP
so it is a terminating TARGET, ending rule traversal.
This target is only valid in the
.BR INPUT ,
.B FORWARD
and
.B OUTPUT
chains, and user-defined chains which are only called from those
chains. The following option controls the nature of the error packet
returned:
.TP
\fB\-\-reject\-with\fP \fItype\fP
The type given can be
\fBicmp6\-no\-route\fP,
\fBno\-route\fP,
\fBicmp6\-adm\-prohibited\fP,
\fBadm\-prohibited\fP,
\fBicmp6\-addr\-unreachable\fP,
\fBaddr\-unreach\fP, or
\fBicmp6\-port\-unreachable\fP,
which return the appropriate ICMPv6 error message (\fBicmp6\-port\-unreachable\fP is
the default). Finally, the option
\fBtcp\-reset\fP
can be used on rules which only match the TCP protocol: this causes a
TCP RST packet to be sent back. This is mainly useful for blocking
.I ident
(113/tcp) probes which frequently occur when sending mail to broken mail
hosts (which won't accept your mail otherwise).
\fBtcp\-reset\fP
can only be used with kernel versions 2.6.14 or later.
.PP
\fIWarning:\fP You should not indiscriminately apply the REJECT target to
packets whose connection state is classified as INVALID; instead, you should
only DROP these.
.PP
Consider a source host transmitting a packet P, with P experiencing so much
delay along its path that the source host issues a retransmission, P_2, with
P_2 being successful in reaching its destination and advancing the connection
state normally. It is conceivable that the late-arriving P may be considered
not to be associated with any connection tracking entry. Generating a reject
response for a packet so classed would then terminate the healthy connection.
.PP
So, instead of:
.PP
-A INPUT ... -j REJECT
.PP
do consider using:
.PP
-A INPUT ... -m conntrack --ctstate INVALID -j DROP
-A INPUT ... -j REJECT
|
