netfilter -> do you DROP or REJECT ?

Howdy NG,

I'd like to discuss your preferred way handling unaccepted
packets in netfilter/ iptables. As I dealt with nmap
these days I recognized that hiding isn't possible.

If connections are DROPped it can be recognized
as filtered. If connections are REJECTed the port is
closed. In both cases connecting to the port is impossible.

Not responding to PING is also no extra-security, cause
if the requested host would not be online, the replying host
would be told "destination unreachable".

Did I get that right?

So I decided to allow ping-replies and changed my rules
from DROP to REJECT --reject-with *.

How do you guys handle this stuff?

Greetz

Daniel

daniel hagen wrote:
> If connections are DROPped it can be recognized
> as filtered. If connections are REJECTed the port is
> closed. In both cases connecting to the port is impossible.
>
> Not responding to PING is also no extra-security, cause
> if the requested host would not be online, the replying host
> would be told "destination unreachable".

Not allowing in pings can add to security. First of all, there was the
ping of death (1996) which was capable of crashing machines. Secondly,
some viruses/worms ping a target to detect if it exists before
attempting a TCP connection. I'm guessing there is some performance
benefit in doing ping rather than trying a TCP connection which may take
some time to timeout.


> So I decided to allow ping-replies and changed my rules
> from DROP to REJECT --reject-with *.
>
> How do you guys handle this stuff?

Personally, I drop the lot. Don't see why I should tell anyone anything
I don't have to.

Pual

daniel hagen wrote:
>Howdy NG,
>
>I'd like to discuss your preferred way handling unaccepted
>packets in netfilter/ iptables. As I dealt with nmap
>these days I recognized that hiding isn't possible.
>
>If connections are DROPped it can be recognized
>as filtered. If connections are REJECTed the port is
>closed. In both cases connecting to the port is impossible.
>
>Not responding to PING is also no extra-security, cause
>if the requested host would not be online, the replying host
>would be told "destination unreachable".
>
>Did I get that right?

Yep, I think so.

>So I decided to allow ping-replies and changed my rules
>from DROP to REJECT --reject-with *.
>
>How do you guys handle this stuff?

I reject unwanted TCP packets with tcp-reset and the rest with
icmp-port-unreachable.
There was a discussion about this in comp.unix.bsd.openbsd.misc a few
days ago (starting with msg-ID <cmn5v4$1mnn$(E-Mail Removed)> ).

--
Maurice

> There was a discussion about this in comp.unix.bsd.openbsd.misc a few
> days ago (starting with msg-ID <cmn5v4$1mnn$(E-Mail Removed)> ).
>
> --
> Maurice

That's exactly the discussion I expected

thanks.

On Sat, 20 Nov 2004 22:46:22 +0100, daniel hagen <(E-Mail Removed)> wrote:
> Howdy NG,
>
> I'd like to discuss your preferred way handling unaccepted
> packets in netfilter/ iptables. As I dealt with nmap
> these days I recognized that hiding isn't possible.
>
> If connections are DROPped it can be recognized
> as filtered. If connections are REJECTed the port is
> closed. In both cases connecting to the port is impossible.
>
> Not responding to PING is also no extra-security, cause
> if the requested host would not be online, the replying host
> would be told "destination unreachable".
>
> Did I get that right?
>
> So I decided to allow ping-replies and changed my rules
> from DROP to REJECT --reject-with *.
>
> How do you guys handle this stuff?

Ping itself can be used for certain DoS attacks by spoofing the return
address, so you do not know where it comes from, and your system will
repeatedly attempt to answer it to an IP that did not request it.

Some worms use ping to find IPs to attempt to attack, so dropping ping can
slow those up and minimize those from attempting further attack on you.

Dropping all packets you do not want to accept (not responding to SYN)
should slow up those crack attempts and prevent any actual attempt to
connect. But ident (113) is one port that is better rejected than
dropped, because things that may use it like smtp and icq will connect
faster if there is a response (accepted or rejected) than timeout waiting
for SYN response (dropped).

"David Efflandt" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...

> Ping itself can be used for certain DoS attacks by spoofing the return
> address, so you do not know where it comes from, and your system will
> repeatedly attempt to answer it to an IP that did not request it.

These kind of attack can be controlled by using the -m limit options,
can't it? A rule can be created which accepts just one echo-request
and drops any following from same IP.

> Some worms use ping to find IPs to attempt to attack, so dropping ping can
> slow those up and minimize those from attempting further attack on you.

When there are no open ports to connect to, why shouldn't they know
I'm here

> Dropping all packets you do not want to accept (not responding to SYN)
> should slow up those crack attempts and prevent any actual attempt to
> connect. But ident (113) is one port that is better rejected than
> dropped, because things that may use it like smtp and icq will connect
> faster if there is a response (accepted or rejected) than timeout waiting
> for SYN response (dropped).

Well I was pointed to a discussion like this on some unix.misc newsgroup and
they said something about RFC-conformity of network traffic. If you want
to stay conform, you just have to RST closed tcp-ports and answer
"destination-unreachable" on closed udp-ports.

Putting it all together:
RSTing and limiting (SYN-flood) incoming connection-request
will not be any security-disadvantage in comparison with DROPing?

daniel