Re: [Shorewall-users] ARP

2018-02-23 Thread Tom Eastep 
On 02/23/2018 02:18 PM, Vieri Di Paola via Shorewall-users wrote:
> 
> 
> From: Tom Eastep 
>>>
>>> Can I avoid replying ARP requests for 192.168.200.0/24 only?
>>>
>> Yes -- add a DROP entry in /etc/shorewall/arprules.
> 
> 
> Thanks. However, I don't understand why the ARP replies were generated even 
> if I set "arp_filter=1" for that interface ($IF_LAN in my example). This 
> interface does not have any IP address configured within 192.168.200.0/24.
> 

arp_filter controls whether ARP requests for addresses on other
interfaces are answered -- but when you enable proxy_arp, ARP requests
for any address for which the system has a route (out of any interface)
are answered.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Shorewall-users] ARP

2018-02-23 Thread Vieri Di Paola via Shorewall-users 


From: Tom Eastep 
>>
>> Can I avoid replying ARP requests for 192.168.200.0/24 only?
>> 
> Yes -- add a DROP entry in /etc/shorewall/arprules.


Thanks. However, I don't understand why the ARP replies were generated even if 
I set "arp_filter=1" for that interface ($IF_LAN in my example). This interface 
does not have any IP address configured within 192.168.200.0/24.

Thanks,

Vieri

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

Re: [Shorewall-users] Restricting intra-LAN traffic

2018-02-23 Thread Tim S 
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 
> To: 
> 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

Re: [Shorewall-users] ARP

2018-02-23 Thread Tom Eastep 
On 02/23/2018 06:42 AM, Vieri Di Paola via Shorewall-users wrote:
> Hi,
> 
> 
> In my LAN I have two networks on the same physical infrastructure (no VLAN):
> 10.215.0.0/16 and 192.168.200.0/24
> 
> The LAN interface on Shorewall firewall/gateway has proxy_arp enabled for 
> some cases, but it seems to be initerfering with ARP requests. This is what I 
> see on the Shorewall box when two hosts in 192.168.200.0 try to ping each 
> other:
> 
> 12:16:54.954199 ARP, Request who-has 192.168.200.21 (30:85:a9:8e:b9:a0) tell 
> 192.168.200.249, length 46
> 12:16:54.954219 ARP, Reply 192.168.200.21 is-at 30:85:a9:8e:b9:a0, length 28
> 
> 
> The problem is that 30:85:a9:8e:b9:a0 is Shorewall's LAN interface MAC, not 
> the MAC of the host at 192.168.200.21.
> 
> I tried to add static ARP entries for the LAN interface on the Shorewall 
> system (arp -i ... -s ...), but the "is-at" replies were still the same.
> 
> Removing proxy_arp on Shorewall's LAN interface solves the issue but opens 
> others.
> 
> What can I try?
> 
> Can I avoid replying ARP requests for 192.168.200.0/24 only?
> 

Yes -- add a DROP entry in /etc/shorewall/arprules.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Shorewall-users] Shorewall 5.2.0 Beta 1

2018-02-23 Thread Tom Eastep 
On 02/23/2018 05:01 AM, Alexander Stoll wrote:
> Am 21.02.2018 um 01:38 schrieb Tom Eastep:
> 
>> 3)  With the wide availability of ipset-based blacklisting, the need
>>  for the 'refresh' command has been largely eliminated. As a result,
>>  that command has been removed.
> 
> Dear Tom,
> 
> I use traffic shaping on multiple hosts, all connected via DSL, if an ip
> change occurs "shorewall refresh" reattaches the qdiscs...
> 
> What would be the recommended way without "refresh" with 5.2?
> 

Make the interface 'optional' and use the 'shorewall reenable' command.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Shorewall-users] Restricting intra-LAN traffic

2018-02-23 Thread Tom Eastep 
On 02/23/2018 02:44 AM, Spyros Stathopoulos wrote:
> On 23-Feb-18 02:17, Tom Eastep wrote:
>> On 02/22/2018 06:08 PM, James Andrewartha wrote:
>>> 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
>>>
>>
> 
> So would it make sense to put the device in a different subnetwork (say
> 10.0.7.1/24), create a VLAN (eg. eth1:0) and a new zone out of eth1:0
> and do SNAT into the new subnetwork? I have done that to access me PPP
> modem on the WAN interface and it works but it is connected to a
> physical interface (eth0). Would such a similar approach work with VLANs?
> 

Yes. And you don't need SNAT in that case.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Shorewall-users] Restricting intra-LAN traffic

2018-02-23 Thread Bill Shirley 

On 2/23/2018 5:44 AM, Spyros Stathopoulos wrote:



So would it make sense to put the device in a different subnetwork (say
10.0.7.1/24), create a VLAN (eg. eth1:0) and a new zone out of eth1:0
and do SNAT into the new subnetwork? I have done that to access me PPP
modem on the WAN interface and it works but it is connected to a
physical interface (eth0). Would such a similar approach work with VLANs?

Spyros



Yes, a VLAN should work.  You won't need to SNAT unless the device won't
respond to other subnets.  I have two local interfaces:
lan4    192.168.4.0/24
wifi    192.168.6.0/24

Devices can reach each other.  However, my wifi router (on wifi interface) won't
let me access its configuration menu from lan4 unless I masq:
?COMMENT access point
$WIFI_IF:$ap_SFN   $lan4_net

Bill


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

[Shorewall-users] ARP

2018-02-23 Thread Vieri Di Paola via Shorewall-users 
Hi,


In my LAN I have two networks on the same physical infrastructure (no VLAN):
10.215.0.0/16 and 192.168.200.0/24

The LAN interface on Shorewall firewall/gateway has proxy_arp enabled for some 
cases, but it seems to be initerfering with ARP requests. This is what I see on 
the Shorewall box when two hosts in 192.168.200.0 try to ping each other:

12:16:54.954199 ARP, Request who-has 192.168.200.21 (30:85:a9:8e:b9:a0) tell 
192.168.200.249, length 46
12:16:54.954219 ARP, Reply 192.168.200.21 is-at 30:85:a9:8e:b9:a0, length 28


The problem is that 30:85:a9:8e:b9:a0 is Shorewall's LAN interface MAC, not the 
MAC of the host at 192.168.200.21.

I tried to add static ARP entries for the LAN interface on the Shorewall system 
(arp -i ... -s ...), but the "is-at" replies were still the same.

Removing proxy_arp on Shorewall's LAN interface solves the issue but opens 
others.

What can I try?

Can I avoid replying ARP requests for 192.168.200.0/24 only?

# ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp5s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 68:05:ca:11:64:30 brd ff:ff:ff:ff:ff:ff
inet 192.168.210.1/23 brd 192.168.211.255 scope global enp5s0
valid_lft forever preferred_lft forever
inet 192.168.212.1/24 brd 192.168.212.255 scope global enp5s0
valid_lft forever preferred_lft forever
inet6 fe80::6a05:caff:fe11:6430/64 scope link
valid_lft forever preferred_lft forever
3: enp6s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 68:05:ca:10:c3:b7 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/28 brd 172.16.0.15 scope global enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::6a05:caff:fe10:c3b7/64 scope link
valid_lft forever preferred_lft forever
4: enp7s0f0:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether e8:ea:6a:0c:4c:1c brd ff:ff:ff:ff:ff:ff
5: enp7s0f1:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether e8:ea:6a:0c:4c:1d brd ff:ff:ff:ff:ff:ff
6: enp7s0f2:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether e8:ea:6a:0c:4c:1e brd ff:ff:ff:ff:ff:ff
inet 172.28.17.105/29 brd 172.28.17.111 scope global enp7s0f2
valid_lft forever preferred_lft forever
inet6 fe80::eaea:6aff:fe0c:4c1e/64 scope link
valid_lft forever preferred_lft forever
7: enp7s0f3:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether e8:ea:6a:0c:4c:1f brd ff:ff:ff:ff:ff:ff
inet 172.20.11.62/28 brd 172.20.11.63 scope global enp7s0f3
valid_lft forever preferred_lft forever
inet6 fe80::eaea:6aff:fe0c:4c1f/64 scope link
valid_lft forever preferred_lft forever
8: enp8s5:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff
9: enp10s0:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
link/ether 30:85:a9:8e:b9:a0 brd ff:ff:ff:ff:ff:ff
inet 10.215.144.91/32 scope global enp10s0
valid_lft forever preferred_lft forever
inet 10.215.144.6/32 scope global enp10s0
valid_lft forever preferred_lft forever
inet 10.215.246.91/32 scope global enp10s0
valid_lft forever preferred_lft forever
inet 192.168.144.91/24 brd 192.168.144.255 scope global enp10s0
valid_lft forever preferred_lft forever
inet 10.215.145.241/32 scope global enp10s0
valid_lft forever preferred_lft forever
inet 10.215.145.242/32 scope global enp10s0
valid_lft forever preferred_lft forever
inet 10.215.145.81/32 scope global enp10s0
valid_lft forever preferred_lft forever
inet6 fe80::3285:a9ff:fe8e:b9a0/64 scope link
valid_lft forever preferred_lft forever
26: tun148:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 100
link/none
inet 192.168.148.1/22 brd 192.168.151.255 scope global tun148
valid_lft forever preferred_lft forever
inet6 fe80::e00e:1aef:f904:bc06/64 scope link flags 800
valid_lft forever preferred_lft forever
27: tun146:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 100
link/none
inet 192.168.146.1/24 brd 192.168.146.255 scope global tun146
valid_lft forever preferred_lft forever
inet6 fe80::2cb6:e903:de8f:e12a/64 scope link flags 800
valid_lft forever preferred_lft forever
28: tun147:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 100
link/none
inet 192.168.147.1/27 brd 192.168.147.31 scope global tun147
valid_lft forever preferred_lft forever
inet6 fe80::ac5f:bf46:8407:a3d7/64 scope link flags 800
valid_lft forever preferred_lft forever


Thanks,

Vieri

Re: [Shorewall-users] Shorewall 5.2.0 Beta 1

2018-02-23 Thread Alexander Stoll 

Am 21.02.2018 um 01:38 schrieb Tom Eastep:


3)  With the wide availability of ipset-based blacklisting, the need
 for the 'refresh' command has been largely eliminated. As a result,
 that command has been removed.


Dear Tom,

I use traffic shaping on multiple hosts, all connected via DSL, if an ip 
change occurs "shorewall refresh" reattaches the qdiscs...


What would be the recommended way without "refresh" with 5.2?

Best regards





smime.p7s
Description: S/MIME Cryptographic Signature
--
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

Re: [Shorewall-users] Restricting intra-LAN traffic

2018-02-23 Thread Spyros Stathopoulos 
On 23-Feb-18 02:17, Tom Eastep wrote:
> On 02/22/2018 06:08 PM, James Andrewartha wrote:
>> 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
>>
> 

So would it make sense to put the device in a different subnetwork (say
10.0.7.1/24), create a VLAN (eg. eth1:0) and a new zone out of eth1:0
and do SNAT into the new subnetwork? I have done that to access me PPP
modem on the WAN interface and it works but it is connected to a
physical interface (eth0). Would such a similar approach work with VLANs?

Spyros

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