All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Kirby <sim@netnation.com>
To: Krzysztof Oledzki <ole@ans.pl>
Cc: Netfilter Development Mailinglist
	<netfilter-devel@lists.netfilter.org>,
	Pablo Neira <pablo@eurodev.net>
Subject: Re: REJECT using invalid data
Date: Fri, 10 Dec 2004 06:49:42 -0800	[thread overview]
Message-ID: <20041210144942.GA19709@netnation.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0412101439530.6072@bizon.gios.gov.pl>

On Fri, Dec 10, 2004 at 02:52:29PM +0100, Krzysztof Oledzki wrote:

> No, REJECT does not DROP. It sends back an error packet in response. So it
> sends response to broken packets.

Yes, but if REJECT can't REJECT it, it very well better DROP instead. 
Would you rather it ACCEPT it?

> Oh, but what if protocol filed is broken? With one bit error we can
> accidently match for example igmp packets with -p tcp.

"tcp", "udp", "igmp", etc., are in the IP header, which better be checked
by that point as well.  That is what I'm saying in my previous message. 
"-p tcp" by itself is matching in only the IP header, which has a
separate checksum.

> Not only for logging. You can use this to protect some hosts with
> broken IP stack like for example unpatched Win95/98, etc.

I'm not against a feature to actually match broken packets in any way. 
I'm just saying that not checking the checksum and skipping such packets
with the rule "-p tcp --dport 80" is wrong.

> So maybe broken packets should go a to different table (broken) and not
> traversal other tables and conntrack? Or any other smart solution.

Possibly.  The kernel would need to know all protocols in order to be
able to filter them before any other rules, though.

Let me make this very clear.  I am talking only about the bad checksum
case, and not about strange or "unclean" packets in any other way.

Would you ever really ever want to accept a packet with a corrupted
checksum?  Would it ever be useful?

Ideally, "-p tcp" could check just the checksums up to the IP level and
NOT the tcp checksum.  "-p tcp" with any other TCP-specific option would
then check the TCP checksum.

So, we could have an example ruleset like this that should work as
expected:

iptables -A FORWARD -d windows_box -m broken --broken-win -J DROP
iptables -A FORWARD -m unclean --some-unclean -m limit ... -J LOG
iptables -A FORWARD -p tcp --dport 80 -J ACCEPT
iptables -A FORWARD -p tcp -j REJECT --reject-with tcp-reset

The above rules would protect the Windows box, log corrupted packets,
accept TCP port 80 packets that don't have a corrupted TCP checksum,
REJECT any other valid TCP packet with a TCP RST, DROP invalid TCP
packets, and follow the policy for the rest.  Simple.

Simon-

  parent reply	other threads:[~2004-12-10 14:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.53.0412072347080.2736@bizon.gios.gov.pl>
2004-12-07 23:54 ` REJECT using invalid data Pablo Neira
2004-12-08  0:33   ` Krzysztof Oledzki
2004-12-08  0:52   ` Simon Kirby
     [not found]     ` <Pine.LNX.4.53.0412101310210.1288@bizon.gios.gov.pl>
2004-12-10 13:10       ` Simon Kirby
     [not found]         ` <Pine.LNX.4.53.0412101439530.6072@bizon.gios.gov.pl>
2004-12-10 14:49           ` Simon Kirby [this message]
2004-12-07  1:01 Simon Kirby
2004-12-07 11:07 ` Pablo Neira
2004-12-07 17:28   ` Simon Kirby
2004-12-07 22:14     ` Pablo Neira
2004-12-08  2:47       ` Kiran Kumar Immidi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041210144942.GA19709@netnation.com \
    --to=sim@netnation.com \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=ole@ans.pl \
    --cc=pablo@eurodev.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.