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...


> ---------- 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 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

Reply via email to