REJECT --reject-with icmp-host-unreachable vs DROP

Hi all

Just something I would like to pick someones brain with.

If I use the default policy of drop, BUT at the end of the
chain use the following

$IPT -t filter -A FORWARD -j REJECT --reject-with
icmp-host-unreachable

Would that be ok, or does is another ICMP message I can
reply back with.

Reason I ask this is because I find that by using the
default policy (DROP), some applications keep retrying to
make a
connection etc.
Where as this approach, seems to slow things down (I stand
to correction on this).

If someone could maybe help me understand this or assit I
would be most grateful.

Kind Regards
Brent Clark

Brent Clark wrote:
> Hi all
> 
> Just something I would like to pick someones brain
with.
> 
> If I use the default policy of drop, BUT at the end of
the chain use
> the following
> 
> $IPT -t filter -A FORWARD -j REJECT --reject-with
> icmp-host-unreachable
> 
> Would that be ok, or does is another ICMP message I can
reply back
> with.

icmp-host-unreachable is fine. The default for the REJECT
target is
icmp-port-unreachable which is ok too. If you want to make
troubleshooting easier you may want to want to tailor the
ICMP reply
according to the reason that a packet was blocked (ie. was a
host
blocked, a network or a port). It doesn't matter too much
though.

Do an "iptables -j REJECT --help" to see the
available reject types.

> Reason I ask this is because I find that by using the
default policy
>  (DROP), some applications keep retrying to make a
connection etc.
> 
> Where as this approach, seems to slow things down (I
stand to
> correction on this).

Most applications/IP stacks will keep retrying for a while
because with
a DROP there is no ICMP packet going back to let the sender
know that
its traffic isn't getting through. The packet is just
stopped without
letting the sender know. The sender assumes the packet was
lost and
tries again until some sort of timeout is reached.

If you use REJECT an ICMP packet is sent back so that the
sender know 
that its packet won't get through. This way it won't
bother retrying and 
will give up immediately.

Note that this isn't always true. Some applications seem to
ignore the 
ICMP reject packets coming back and will keep retrying
anyway. The 
built-in command line Windows telnet application seems to do
this. I'm 
not sure if this is a Windows thing or just the telnet
program.

There are some situations where you should just use DROP
instead of 
REJECT, usually for performance reasons where your netfilter
machine has 
to deal with a high traffic volume and can't afford to send
REJECTs. You 
might also want to use DROP when you get traffic that is
almost 
definitely malicious. There's no point in sending a nice
REJECT in this 
case.

> If someone could maybe help me understand this or assit
I would be
> most grateful.

I hope I've explained it clearly enough.

Menno

Brent Clark wrote:

> Hi all
>
> Just something I would like to pick someones brain
with.
>
> If I use the default policy of drop, BUT at the end of
the chain use 
> the following
>
> $IPT -t filter -A FORWARD -j REJECT --reject-with
icmp-host-unreachable
>
> Would that be ok, or does is another ICMP message I can
reply back with.
>
> Reason I ask this is because I find that by using the
default policy 
> (DROP), some applications keep retrying to make a
> connection etc.
> Where as this approach, seems to slow things down (I
stand to 
> correction on this).
>
> If someone could maybe help me understand this or assit
I would be 
> most grateful.

I recommend using --reject-with icmp-host-unreachable and
here are the 
reasons:

1) What is the only reason you would receive nothing?  When
a firewall 
is in place.  That's it.  Everything else you either get a
host 
unreachable, network unreachable, port unreachable, reset,
etc. 2) What 
do DDoS attacks rely on?  Slow/no connection resets.  If
your address 
space is spoofed and you do not send a reject or reset
message, the 
victim still has the connection open.  You are aiding the
cracker with 
their DDoS by DROPing the connection and not
rejecting/reseting it.
3) If I remember right, it is against RFC to DROP a
connection without 
rejecting/reseting it.  If anybody could point me to the
correct RFC, 
that would be great.

-- 
Nathaniel Hall, GSEC GCFW GCIA

Brent Clark zei:
> Hi all
>
> Just something I would like to pick someones brain
with.
>
> If I use the default policy of drop, BUT at the end of
the chain use the
> following
>
> $IPT -t filter -A FORWARD -j REJECT --reject-with
icmp-host-unreachable
>
> Would that be ok, or does is another ICMP message I can
reply back with.

If tcp, use tcp-reset instead. Different stacks can and do
react
differently to an icmp-*-unreachable message. Sending back a
tcp reset is
the correct thing to do according to the RFCs, and indeed
all tcp/ip
stacks(1) understand this.

> Reason I ask this is because I find that by using the
default policy
> (DROP), some applications keep retrying to make a
connection etc.
> Where as this approach, seems to slow things down (I
stand to correction
> on this).

Absolutely right. I personaly drop on the outside and reject
on the
inside. Precisely for this reason.

HTH,
M4

(1) Except possibly some very broken stacks such as found in
some embedded
machines. I recently had a chance to fight with the Zebra
printserver
stack. Ugly.