The next step is to allow explicitly our subnets to talk to the router only. Let’s assume the router’s IP is configured to a class C private subnet like 192.168.1.1/16 and all hosts on the eth0 link should be allowed to send and receive traffic.
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever
Usally configuring a firewall by hand all the micro management stuff begins now by adding them to the USER-IN or USER-OUT chains but there’s an easier way. In a common network setup there’s often some kind of internal interface on which private subnets reside. The ALLOW_SUBNETS call just expects an interface name and all subnets configured on that interface will be allowed to talk to the router host by placing appropriate rules in:
Chain USER-IN (1 references) pkts bytes target prot opt in out source destination ... ... ACCEPT all -- eth0 * 192.168.0.0/16 0.0.0.0/0 /* ALLOW_SUBNETS_0x50e549399da8 */ Chain USER-OUT (1 references) pkts bytes target prot opt in out source destination ... ... ACCEPT all -- * eth0 192.168.1.1 192.168.0.0/16 /* ALLOW_SUBNETS_0x50e549399da8 */
Notice the comments to the right which are used to identify these rules as rules created by an ALLOW_SUBNET call. This is a good example of a logical ruleset spanning over multiple chains.
Although these rules allow primary traffic among the router and hosts of the 192.168.0.0/16 subnet additional traffic is still not allowed like link-local, service discovery or UPNP which needs to be explicitly allowed by using ALLOW_LINK_LOCAL or ALLOW_SERVICE_DISCOVERY which in turn opens up traffic originating from 169.254.0.0/16 or fe80::/10 subnets to allow use of ZeroConf address assignment like IPv4ll or Netbios|DNS based service discovery via multicast or UPNP features like available DLNA or AirPlay servers in your subnet. All these comfort features eases life on an internal link in a private subnet but these shouldn’t be available on a WAN device as they expose attack surface but since we’re on an internal link in our scenario we can safely allow them as ipturntables.sh in it’s default configuration doesn’t allow any forwarding of such traffic. Usally a router shouldn’t be allowed to use service discovery but there can be useful situations eg. when the router offers DNS multicast for hostname resolution on auto-configured subnets to specific interfaces only especially when a DHCP server isn’t available there.