All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@vger.kernel.org
Subject: Re: how to harden iptables rules?
Date: Fri, 05 Mar 2010 01:00:50 +0100	[thread overview]
Message-ID: <4B9049B2.4010000@plouf.fr.eu.org> (raw)
In-Reply-To: <1267703243.22478.57.camel@etppc09.garching.physik.uni-muenchen.de>

Christoph Anton Mitterer a écrit :
> 
>>> -A INPUT	-m state  --state ESTABLISHED,RELATED	-j ACCEPT
>> Mostly agree, although I would drop some ICMP types such as redirect or
>> source quench that may be harmful.
> Why would ICMP packets match this rule? Are they (well at least errors
> in response to some IP traffic) counted as RELATED?

Yes, "valid" ICMP error messages are RELATED (not ESTABLISHED as I
wrongly stated).

> But probably not things like echo-request, right? What should it relate
> to?

ICMP echo requests are NEW, and "valid" (for conntrack) ICMP echo
requests are ESTABLISHED.

> Well,.. does it really? I've always thought no ICMP error messages would
> be generated on errors with ICMP packets?

An ICMP error message must not be sent in reply to an ICMP error
message, but may be sent in reply to an ICMP message that is not an
error type, such as echo.

> btw: Now that I generally block ICMP (except echo-request and
> ESTABLISHED),... would I still need things like:
> net.ipv4.conf.all.accept_redirects = 0
> net.ipv6.conf.all.accept_redirects = 0

Yes, because valid ICMP redirect messages are RELATED.

> And does someone know whether the log_martians setting only affects
> whether martians are logged or also whether they're really discarded?

Martians are discarded anyway.

>>> 3) What I never clearly understood: Do I have to handle (drop)  
>>> "external packets" with:
>>> -a source address of 127.x.x.x or :1
>>> -a destination address of 127.x.x.x or :1
>>> -a source address that matches one of the addresses of my other  
>>> interfaces (e.g. 88.88.88.88 if that is the address of eth0)
>> This is not critical, because the IP stack already discards such packets.
> Great great,... and I again assumes that this happens "before" netfilter
> comes in place?

This happens at the input routing decision between PREROUTING and INPUT
or FORWARD.

> Well but what I've understood from what you've wrote, this kind of stuff
> is discarded automatically by the kernel anyway,... so no need to take
> manual actions, right?

Well, you're never too sure...

> my interface has e.g. again the address 88.88.88.88
> someone sends packets with destination address 88.88.88.11 to that
> interface (which should be not handled by it)...

An interface should handle any local address, i.e. any address assigned
to itself or to any other interface of the system. Only packets with a
local destination go through the INPUT chains. Otherwise, it depend
whether forwarding is enabled or not : if yes, the packet is forwarded,
if not it is discarded at the input routing decision.

The question is : when a host has multiple interfarce, do you want to
allow packets on an interface but to the address of another interface ?
If yes (weak host model), just filter by interface. If no (strong host
model), filter by interface and by address.

> uhm.... Rethinking this scenario, I'd guess that packets with
> dest=88.88.88.11 would be considered as packets to be forwarded, right?

Yes if this address is not local.

> So they should be either dropped because of my:
> :FORWARD DROP
> policy or my:
> net.ipv4.ip_forward=0
> right?

Right.

  reply	other threads:[~2010-03-05  0:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-03 16:20 how to harden iptables rules? Christoph Anton Mitterer
2010-03-03 17:41 ` Pascal Hambourg
2010-03-04 11:47   ` Christoph Anton Mitterer
2010-03-05  0:00     ` Pascal Hambourg [this message]
2010-03-05  2:48       ` IP-in-IP matching Andrew Kraslavsky
2010-03-04 12:34   ` how to harden iptables rules? Mart Frauenlob
2010-03-04 16:56     ` Pascal Hambourg

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=4B9049B2.4010000@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@vger.kernel.org \
    /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.