1

I am currenttly refining the Firewall Rules on my DD-WRT Router. Specifically my question is about this Rule:

iptables -I INPUT -i eth1.10 -d ! 192.168.10.0/28 -j DROP

I was wondering if it was possible to somehow enforce the Rule on an Interface level, so that the interface would only respond on an ICMP Request directly to the eth1.10 (192.168.10.1/28) interface. Without this Rule, eth1 (192.168.1.1/24) is also pingable via eth1.10, which is a security flaw in my eyes. Edit for Clarifications: The Router is routing between these two subnets. I split the four Ports up on the back of the Router so i can plug my Server into Port 4 of the Router. I then associated Port 4 with eth1.10, eth1 is connected to the other 3 Ports, which are for LAN use. I want to completely isolate the network 192.168.1.0 from 192.168.10.0...

# SwitchPort Setup script
swconfig dev switch0 set enable_vlan 1 
swconfig dev switch0 vlan 1 set ports "2 3 4 6"
swconfig dev switch0 vlan 10 set ports "1 6t" 
swconfig dev switch0 set apply 
vconfig add eth1 10
ifconfig eth1.10 192.168.10.1 netmask 255.255.255.240
0

(I admit I don't understand all the switch settings but that's not relevant to the question.)

Your current rule, in filter/INPUT prevents packets from eth1.10 to reach router's owned IPs other than 192.168.10.0/28, so it indeed has the intended effect of not allowing IPs coming from eth1.10 to access 192.168.1.1.

  • Why is it needed?

    That's because a Linux system with multiple interfaces will consider its IPs as a pool and can use any of its IPs on any of its interfaces. There's no routing (forwarding) involved here. The only method I know of to deal with this is with iptables' filter/INPUT.

  • How to avoid having to specify IPs in this rule to keep it somewhat generic?

    There is a specific iptables-extensions match that can do the trick, but it has to be used twice, within an additional chain for logic glue: addrtype with and without its --limit-iface-in option. So you can replace your rule and have a rule depending on the interface's name only:

    iptables -N dropotherlocalips
    iptables -A dropotherlocalips -i eth1.10 -m addrtype --dst-type LOCAL --limit-iface-in -j RETURN
    iptables -A dropotherlocalips -i eth1.10 -m addrtype --dst-type LOCAL -j DROP
    iptables -I INPUT -j dropotherlocalips
    

    The first rule matches a local IP on the same interface only and returns (ie does nothing). The second rule drops any local IP, thus in the end drops local IPs not on the same interface.

    Note that if you want this rule to be more generic and work on any side, you can just remove -i eth1.10 in dropotherlocalips:

    iptables -A dropotherlocalips -m addrtype --dst-type LOCAL --limit-iface-in -j RETURN
    iptables -A dropotherlocalips -m addrtype --dst-type LOCAL -j DROP
    

    this would then in addition prevent eth1's side to ping 192.168.10.1.

I want to completely isolate the network 192.168.1.0 from 192.168.10.0...

You have to (but you already did, didn't you?) also add a filter/FORWARD rule for this, like:

iptables -I FORWARD -i eth1.10 -d 192.168.1.0/24 -j DROP

I don't see here how to avoid stating a LAN in the rule, unless eth1.10 is barred any destination, but then it wouldn't have to be routed at all. Or FORWARD can have a DROP policy and be only allowed routing/forwarding explictly written in rules.

With those rules, 192.168.1.0/24 is completely unavailable at the IP level from eth1.10, including 192.168.1.1.


EXTRA, to be nitpicking: ARP can still let the existence of 192.168.1.1 be known from eth1.10's LAN.

The rules above won't prevent an host behind eth1.10 to know (eg by brute-force scanning) the existence of 192.168.1.1 by way of ARP which is not filtered by iptables. That's still because of Linux considering all its IPs as a pool even when answering ARP (explanation in the default arp_filter setting, but see also below arp_announce and arp_ignore). So using arping from a Linux system in 192.168.10.0/28 (arriving on router's eth1.10) with interface eno1 (please adjust name):

$ ping -c2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 10ms

$ ip neighbour
192.168.10.1 dev eno1 lladdr b6:f2:aa:82:21:d4 REACHABLE
$ arping -c2 -I eno1 192.168.1.1
ARPING 192.168.1.1 from 192.168.10.10 eno1
Unicast reply from 192.168.1.1 [B6:F2:AA:82:21:D4]  0.552ms
Unicast reply from 192.168.1.1 [B6:F2:AA:82:21:D4]  0.552ms
Sent 2 probes (1 broadcast(s))
$ 

Since the MAC address is the same, that means 192.168.1.1 is on 192.168.10.1's host: the router.

The minimal setting to avoid this (when there isn't a complex routing configuration requiring arp_filter) would be on the router:

echo 1 > /proc/sys/net/ipv4/conf/eth1.10/arp_ignore=1

(or sysctl -w net.ipv4.conf.eth1/10.arp_ignore=1)

That is from arp_ignore:

1 - reply only if the target IP address is local address configured on the incoming interface

You could alternately use arp_filter=1 (which would be worth only if you're already using ip rule and additional tables, because you'd probably have to anyway) or even filter ARP requests with arptables to prevent this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.