I have a hyper-paranoid least-privilege security design on my network. I use a layer-3 switch with each port as its own VLAN, and the 10GBe uplinks as VLAN trunks. Since the individual devices do not "see" the VLAN assignment (since it's done at the switch and above), all traffic runs through the Shorewall VM instance.
I have some scripts that look at the MAC address of the traffic coming in and then I apply a security policy based on the device. Android TVs only see the web and each other, IP phones only see the SIP PBX (this blocks 302 redirects that can lead to toll fraud), and user devices like tablets and PCs require an extra step of RADIUS authentication. MAC addresses I do not have a policy for just get the public internet while being rate limited to 128kbps, but they have no concept of the intranet services provided to other devices on my inside network. A separate VM is dedicated to handling switch configuration and status, with connection information published to a Redis DB, with the firewall machines scripts subscribe to. Most modern layer-3 switches can handle 4096 VLANs, so even with stacked 48-port switches you are unlikely to run out of VLANs all the way up to a fairly large corporate campus. If you do run out, simply spawning another Shorewall VM and trunking the policy pools between Shorewall VMs takes care of that. In my particular case, I have two Shorewall VMs, and two stacked 48-port switches Each switch has a 10Gbe uplink to each of two of my VM hosts for redundancy, and one Shorewall VM is on each VM host. The VM hosts are trunked with redundant isolated Infiniband networks. This way single point of failure does not mean I lose a chunk of my network, or any of my services. I had to go this way when my wife's tolerance for network outage dropped to zero, even for patching. The added bonus, is that I can mirror all 96 of my device ports from the switch to distinct Snort IDS/IPS VM instances, so if I detect a device trying to detect or break out of a VLAN by poisoning packet headers, I can drop a hammer on the interface (i.e. DROP ALL). Scripting and automation is your friend here, doing those configurations by hand this way is probably a bad way to learn how not to configure Shorewall to or a fast way to be driven to eating Tide Pods on the way to the loony-bin... -Tim > > ---------- Forwarded message ---------- > From: James Andrewartha <jandrewar...@ccgs.wa.edu.au> > To: <shorewall-users@lists.sourceforge.net> > Cc: > Bcc: > Date: Fri, 23 Feb 2018 10:08:01 +0800 > Subject: Re: [Shorewall-users] Restricting intra-LAN traffic > On 23/02/18 10:01, Tom Eastep wrote: >> On 02/22/2018 05:39 PM, Spyros Stathopoulos wrote: >>> As there is no access control >>> from the device itself I can only limit the connection from shorewall. >> >> The value in defining multiple zones within a LAN is to define different >> rules/policies to/from the LAN. Because intra-LAN traffic within a >> subnet does not pass through the Shorewall system, rules and policies on >> that system are ineffective in controlling intra-LAN traffic. If >> different disjoint subnets are defined, traffic between the subnets does >> go through the Shorewall system, but such a setup is easily bypassed by >> LAN users who have administrative privileges on their systems. The best >> way to accomplish what you want is via firewall rules on 10.0.1.99 itself. > > What about putting the device on a separate interface and using > shorewall's bridge firewall feature? > http://shorewall.net/bridge-Shorewall-perl.html > > -- > James Andrewartha > Network & Projects Engineer > Christ Church Grammar School > Claremont, Western Australia > Ph. (08) 9442 1757 > Mob. 0424 160 877 > > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
