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 # ...
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. --
On Fri, 27 Feb 2009 04:16:19 +0100 (CET) Then routing wouldn't work... --
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 --
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. --
...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? --
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. --
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
-------------------------------------------------------------------
--
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. --
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. --
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. --
