netfilter -> do you DROP or REJECT ?

Discussion in 'Linux Networking' started by daniel hagen, Nov 20, 2004.

  1. daniel hagen

    daniel hagen Guest

    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?


    daniel hagen, Nov 20, 2004
    1. Advertisements

  2. daniel hagen

    Paul Black Guest

    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.

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

    Paul Black, Nov 20, 2004
    1. Advertisements

  3. Yep, I think so.
    I reject unwanted TCP packets with tcp-reset and the rest with
    There was a discussion about this in comp.unix.bsd.openbsd.misc a few
    days ago (starting with msg-ID <cmn5v4$1mnn$> ).
    Maurice Janssen, Nov 21, 2004
  4. daniel hagen

    daniel hagen Guest

    There was a discussion about this in comp.unix.bsd.openbsd.misc a few
    That's exactly the discussion I expected :)

    daniel hagen, Nov 21, 2004
  5. 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, Nov 22, 2004
  6. daniel hagen

    daniel hagen Guest

    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.
    When there are no open ports to connect to, why shouldn't they know
    I'm here ;)
    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 hagen, Nov 22, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.