Re: [PATCH] iptables: new strict host model match

Previous thread: [PATCH] net headers: export dcbnl.h by Chris Leech on Thursday, February 26, 2009 - 5:54 pm. (1 message)

Next thread: Pull request: bluetooth-next-2.6 2009-02-27 by Marcel Holtmann on Thursday, February 26, 2009 - 10:35 pm. (2 messages)
From: Stephen Hemminger
Date: Thursday, February 26, 2009 - 6:52 pm

This is a simple little iptables match that can be used to create the Strong
End System model, that router and other non-Linux customers expect. There
are management and other applications that use ping and expect to only get
a response when the interface with that address is up. Normally, a Linux
system will respond to a packet that arrives for any of the system addresses
independent of which link it arrives on.

The module can be used on the INPUT chain like:

# iptables -P INPUT DROP
# iptables -A INPUT -m strict -j ACCEPT


---
 net/ipv4/devinet.c              |    1 
 net/ipv4/netfilter/Kconfig      |   12 ++++++++
 net/ipv4/netfilter/Makefile     |    1 
 net/ipv4/netfilter/ipt_strict.c |   56 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 70 insertions(+)

--- a/net/ipv4/netfilter/Kconfig	2009-02-26 17:47:03.000000000 -0800
+++ b/net/ipv4/netfilter/Kconfig	2009-02-26 17:47:08.000000000 -0800
@@ -92,6 +92,18 @@ config IP_NF_MATCH_ECN
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
+config IP_NF_MATCH_STRICT
+       tristate '"strict end system" match support'
+	depends on NETFILTER_ADVANCED
+	help
+	  This option adds a 'strict' match, which allows you to
+	  match only packets that arrive with the destinaton address matching
+	  an IP address on the incoming interface. This can be used to implement
+	  Strong End System model as defined in Internet Host Requirements
+	  (RFC1122).
+
+	  To compile it as a module, choose M here.  If unsure, say N.
+
 config IP_NF_MATCH_TTL
 	tristate '"ttl" match support'
 	depends on NETFILTER_ADVANCED
--- a/net/ipv4/netfilter/Makefile	2009-02-26 17:46:37.000000000 -0800
+++ b/net/ipv4/netfilter/Makefile	2009-02-26 17:47:08.000000000 -0800
@@ -51,6 +51,7 @@ obj-$(CONFIG_IP_NF_SECURITY) += iptable_
 obj-$(CONFIG_IP_NF_MATCH_ADDRTYPE) += ipt_addrtype.o
 obj-$(CONFIG_IP_NF_MATCH_AH) += ipt_ah.o
 obj-$(CONFIG_IP_NF_MATCH_ECN) += ipt_ecn.o
+obj-$(CONFIG_IP_NF_MATCH_STRICT) += ipt_strict.o
 
 # ...
From: Jan Engelhardt
Date: Thursday, February 26, 2009 - 8:16 pm

The match seems to make the most sense where an input device
is available, so

	.hooks = (1 << NF_INET_PRE_ROUTING) | (1 << NF_INET_LOCAL_IN) |
	         (1 << NF_INET_FORWARD)

should probably be added.
--

From: Stephen Hemminger
Date: Thursday, February 26, 2009 - 8:23 pm

On Fri, 27 Feb 2009 04:16:19 +0100 (CET)


Then routing wouldn't work...
--

From: Jozsef Kadlecsik
Date: Friday, February 27, 2009 - 1:30 am

Still, it'd worth, because for example non-matching IPv4/IPv6 packets 
could then be logged together.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary
--

From: Jan Engelhardt
Date: Friday, February 27, 2009 - 6:53 pm

How so?
--

From: Stephen Hemminger
Date: Friday, February 27, 2009 - 7:10 pm

On Sat, 28 Feb 2009 02:53:10 +0100 (CET)
I suppose it could be useful to to different chains for routed vs non-routed
packets on pre-routing chain, but on forward chain it wouldn't really
do anything useful.
--

From: Jan Engelhardt
Date: Saturday, February 28, 2009 - 1:27 am

...Ok? The hooks mask limits the use of the match to - true to its name -
hooks, so it is implies permitting the use of the match in the
PREROUTING/INPUT/FORWARD chain and chains called from it, as long as
no unlisted chain has a reference to it too. This is how most other
modules, e.g. xt_mac, act too.

Since xt_strict inspects in_dev, and in_dev is not available in
OUTPUT/POSTROUTING, I was suggesting to just limit its use to the
chains where in_dev != NULL.
Or did I misunderstood you?
--

From: Patrick McHardy
Date: Monday, March 2, 2009 - 4:02 am

I'm not sure this is correct, I think it will only allow communication
with truely on-link addresses, meaning it won't accept routed packets
going to the interface address. Generally I don't think this can be
fully done in iptables since you'd still have to deal with ARP etc.
An IPv4 sysctl might be more appropriate.

Just for the IPv4 packets, I'm wondering if the intended result could
be achieved using the addrtype match. Something like:

-m addrtype --limit-iface-in --dst-type LOCAL

should check whether the destination address is local to the receiving
interface.
--

From: Jesper Dangaard Brouer
Date: Monday, March 2, 2009 - 6:42 am

Is this no almost the same as:


inet_addr_onlink() will call
  -> inet_ifa_match(ip_hdr(skb)->daddr, ifa)

arp_ignore = 1
  -> inet_confirm_addr(in_dev, 0, tip, RT_SCOPE_HOST)
     -> inet_ifa_match(tip, ifa)


Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
--

From: Denys Fedoryschenko
Date: Monday, March 2, 2009 - 6:46 am

I guess if some "smart guy" will set static association in his ARP table, he 
can ignore this rule and "hack the host" over another ip, which sits on 
internal interface for example.
--

From: Stephen Hemminger
Date: Monday, March 2, 2009 - 11:53 am

On Mon, 2 Mar 2009 14:42:33 +0100 (CET)

That doesn't work when system already has an ARP entry and link goes down.
--

From: Patrick McHardy
Date: Monday, March 2, 2009 - 3:12 pm

I think it would make sense to define the differences in behaviour
that are expected when acting according to the strict host model.
It very unlikely that all of this can be achieved with iptables,
and if what can be done is still useful, the limitations should be
known.
--

Previous thread: [PATCH] net headers: export dcbnl.h by Chris Leech on Thursday, February 26, 2009 - 5:54 pm. (1 message)

Next thread: Pull request: bluetooth-next-2.6 2009-02-27 by Marcel Holtmann on Thursday, February 26, 2009 - 10:35 pm. (2 messages)