Implications of a permissive FORWARD chain

Implications of a permissive FORWARD chain

[Mark Fox]

I've been waffling over a permissive or restrictive FORWARD chain and have
realized that my understanding of the implications is lacking. So I'll just
ask: What are the implications of a permissive FORWARD chain?

My situation is that I am deploying a virtualization/containerization host
at a facility that has one big network for everything (servers, desktop
workstations, etc.). There is no DMZ. As one would expect, the network is
really chatty.

Traffic has to be forwarded to/from the VM/container host to/from the VMs or
containers, so a DROP policy on the FORWARD chain means carefully crafting
rules to allow traffic to be forwarded to the VMs/containers. I have no
issues with that, but it does mean that the future users of the VM/container
host would have to craft their own rules when they add new VMs/containers.

Re: Implications of a permissive FORWARD chain

[Leonardo Rodrigues]

Em 18/02/14 14:53, Mark Fox escreveu:
> I've been waffling over a permissive or restrictive FORWARD chain and have
> realized that my understanding of the implications is lacking. So I'll just
> ask: What are the implications of a permissive FORWARD chain?
>
> My situation is that I am deploying a virtualization/containerization host
> at a facility that has one big network for everything (servers, desktop
> workstations, etc.). There is no DMZ. As one would expect, the network is
> really chatty.
>
> Traffic has to be forwarded to/from the VM/container host to/from the VMs or
> containers, so a DROP policy on the FORWARD chain means carefully crafting
> rules to allow traffic to be forwarded to the VMs/containers. I have no
> issues with that, but it does mean that the future users of the VM/container
> host would have to craft their own rules when they add new VMs/containers.
>

     There's no right or wrong on how your FORWARD default rule should 
be. Being DROP or ACCEPT depends on your network security policies.

     Being ACCEPT the default action for FORWARD, your linux router will 
forward anything from one side to the other, unless it's explicity 
DROPped on the rules. Being DROP the default action, everything will be 
dropped, except explicitely ACCEPTed by your rules.

     Which one fullfit you demands ? So that's the right one for you ! 
No one can tell you, giving only the information you wrote, that DROP or 
ACCEPT is right or wrong. There's really no right or wrong here, there's 
what fullfilts your demands/needs and what doesnt.



-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: Implications of a permissive FORWARD chain

[Ambroz Bizjak]

It's worth pointing out that packets coming in from interface A with
the destination address equal to the local address of interface B will
be considered INPUT, not FORWARD. So, even if you have drop packets in
FORWARD, binding a service to a specific interface address, as a
security measure, does not actually make it reachable only via that
interface. You'd need to explicitly drop those packets in INPUT to
protect the service.

On Tue, Feb 18, 2014 at 6:53 PM, Mark Fox <mark.fox@gmail.com> wrote:
> I've been waffling over a permissive or restrictive FORWARD chain and have
> realized that my understanding of the implications is lacking. So I'll just
> ask: What are the implications of a permissive FORWARD chain?
>
> My situation is that I am deploying a virtualization/containerization host
> at a facility that has one big network for everything (servers, desktop
> workstations, etc.). There is no DMZ. As one would expect, the network is
> really chatty.
>
> Traffic has to be forwarded to/from the VM/container host to/from the VMs or
> containers, so a DROP policy on the FORWARD chain means carefully crafting
> rules to allow traffic to be forwarded to the VMs/containers. I have no
> issues with that, but it does mean that the future users of the VM/container
> host would have to craft their own rules when they add new VMs/containers.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Implications of a permissive FORWARD chain

[Mark Fox]

Leonardo Rodrigues <leolistas <at> solutti.com.br> writes:
>      There's no right or wrong on how your FORWARD default rule should 
> be. Being DROP or ACCEPT depends on your network security policies.
> 
>      Being ACCEPT the default action for FORWARD, your linux router will 
> forward anything from one side to the other, unless it's explicity 
> DROPped on the rules. Being DROP the default action, everything will be 
> dropped, except explicitely ACCEPTed by your rules.
> 
>      Which one fullfit you demands ? So that's the right one for you ! 
> No one can tell you, giving only the information you wrote, that DROP or 
> ACCEPT is right or wrong. There's really no right or wrong here, there's 
> what fullfilts your demands/needs and what doesnt.

Thanks for the reply, Leonardo. I'm not asking someone else to tell me what
is the right thing to do. What I'm wondering is what kind of damage someone
else on the network could use a machine with a permissive forwarding policy
to do. Spoofing obviously, but anything else?

With that better understanding, I'll be equipped to make that call.

In the larger context, the fact that several popular Linux distributions
come configured with a firewall that allows all forwarding, all incoming
connections and all outgoing connections is somewhat surprising.

Mark

Re: Implications of a permissive FORWARD chain

[Amos Jeffries]

On 2014-02-19 09:02, Mark Fox wrote:
> Leonardo Rodrigues writes:
>>      There's no right or wrong on how your FORWARD default rule should
>> be. Being DROP or ACCEPT depends on your network security policies.
>> 
>>      Being ACCEPT the default action for FORWARD, your linux router 
>> will
>> forward anything from one side to the other, unless it's explicity
>> DROPped on the rules. Being DROP the default action, everything will 
>> be
>> dropped, except explicitely ACCEPTed by your rules.
>> 
>>      Which one fullfit you demands ? So that's the right one for you !
>> No one can tell you, giving only the information you wrote, that DROP 
>> or
>> ACCEPT is right or wrong. There's really no right or wrong here, 
>> there's
>> what fullfilts your demands/needs and what doesnt.
> 
> Thanks for the reply, Leonardo. I'm not asking someone else to tell me 
> what
> is the right thing to do. What I'm wondering is what kind of damage 
> someone
> else on the network could use a machine with a permissive forwarding 
> policy
> to do. Spoofing obviously, but anything else?
> 
> With that better understanding, I'll be equipped to make that call.
> 
> In the larger context, the fact that several popular Linux 
> distributions
> come configured with a firewall that allows all forwarding, all 
> incoming
> connections and all outgoing connections is somewhat surprising.

That "all incoming connections" surprises me to. But then you are asking 
about FORWARD not INPUT.


Like you surmised earlier the implications for the client hosts is the 
same as if your forwarding host was not there at all.

IMHO, a permissive rule is warranted but you can do somewhat better than 
the black and white situation of accept all. Your host is in the 
position to set a few basic security policies for specific ports and 
services (eg FINGER, Windows RPC perhapse) and definitely block bogon 
traffic.

Amos

Re: Implications of a permissive FORWARD chain

[Neal Murphy]

On Tuesday, February 18, 2014 03:02:37 PM Mark Fox wrote:
> Thanks for the reply, Leonardo. I'm not asking someone else to tell me what
> is the right thing to do. What I'm wondering is what kind of damage someone
> else on the network could use a machine with a permissive forwarding policy
> to do. Spoofing obviously, but anything else?
> 
> With that better understanding, I'll be equipped to make that call.
> 
> In the larger context, the fact that several popular Linux distributions
> come configured with a firewall that allows all forwarding, all incoming
> connections and all outgoing connections is somewhat surprising.

Perhaps this will help.

In a sentence: learn the many different types of traffic flows that can exist 
and grade them (good, bad, essential, unneeded, prohibited, &cet.), then 
identify each type of traffic flow present on your network and decide whether 
or not to control it.

Contrast the following:
  1. You retain the default policies for INPUT, OUTPUT and FORWARD (ALLOW),
     thus allow all traffic into, out of, and through the system. This allows
     almost anyone, almost anywhere, to determine which services are available
     on which systems, and to attack them (SQL attacks on RDBMS servers, SQL
     injection attacks on web servers, &cet.) or to allow malware (viruses,
     trojans, &cet.) to propagate through your private internetwork of LANs.
  2. You set the default policies for INPUT, OUTPUT and FORWARD to DROP, add
     rules that allow only necessary and allowed traffic to pass into, out
     of, and through the system, and add rules/chains to LOG and REJECT (or
     DROP) traffic that is not allowed. You load the conntrack helpers that
     allow, for instance, FTP data connections that are related to FTP control
     connections. You run proxies (employing man-in-the-middle SSL) to prevent
     direct connections through FORWARD and that make deploying VoIP easier.
     You run layer 7 filters that identify and control traffic that uses non-
     standard ports or random ports. All traffic that is not explicitly
     allowed is logged and DROPped or REJECTed. You deploy an intrusion
     detection or intrusion prevention system (IDS/IPS) such as Snort or
     Suricata to identify or block traffic known to be bad. You run VPN
     servers (IPSEC, OpenVPN, and maybe even PPP over SSH) to allow certain
     systems to tunnel through to access necessary systems.

Number 1 is a plain-jane router. Number 2 is a fairly complete firewall.

In between is your gray area, and you must decide how much control you wish to 
exert over traffic into, out of, and through your system.
  - Maybe only certain LANs can access certain other LANs.
  - Maybe certain LANs (machine shop, point-of-sale, &cet.) are never allowed
    to access the internet.
  - Maybe you allow common traffic (ordinary traffic that makes a private
    internetwork of LANs useful) and certain other essential traffic and block
    the rest.
  - Maybe you allow all traffic and only block that which you know to be bad,
    undesired, or non-essential.
  - Maybe you have wireless systems on one LAN and you block their access to
    all but internet and VPN. If they need to access protected systems, they
    fire up a VPN (because wireless is, by its nature, insecure), pass all
    networking traffic through the VPN, and ignore all but VPN/ICMP traffic on
    the wireless interface.
You are still firewalling (because anything less than a fully open router is 
performing *some* firewall function), but it's not necessarily as restrictive, 
draconian or specific as a fully-featured firewall system.

Re: Implications of a permissive FORWARD chain

[Mark Fox]

Amos Jeffries <squid3 <at> treenet.co.nz> writes:

> Like you surmised earlier the implications for the client hosts is the 
> same as if your forwarding host was not there at all.

That is a salient point, Amos.

In my case, it can be argued that that's exactly what is desired. But I
agree that there are some rules that can be added to tighten things up
without unduly hampering someone who wants to add a VM or container in the
future. Spoofing can be curtailed, for example.

Thanks.

Re: Implications of a permissive FORWARD chain

[Mark Fox]

Neal Murphy <neal.p.murphy <at> alum.wpi.edu> writes:

> Perhaps this will help.
> 
> [...]

It does. Especially this:

>  This allows
>  almost anyone, almost anywhere, to determine which services are available
>  on which systems, and to attack them (SQL attacks on RDBMS servers, SQL
>  injection attacks on web servers, &cet.) or to allow malware (viruses,
>  trojans, &cet.) to propagate through your private internetwork of LANs.

What I think I may have not made clear is that I'm not dealing with LANs
here. It's a single LAN, with everything thrown onto it. That's what threw
me for a loop. It's not fire-walling between networks. It's fire-walling to
and from the same network.

Perhaps I've made the mistake of spending most of my time thinking about
protecting hosts on one network from hosts on different networks, but not
much time thinking about hosts on the same network.

In any case, it seems pretty obvious that, given the all-eggs-in-one-basket
state of the network, really tight fire-walling is in order.

Re: Implications of a permissive FORWARD chain

[Mark Fox]

Ambroz Bizjak <ambrop7 <at> gmail.com> writes:

> It's worth pointing out that packets coming in from interface A with
> the destination address equal to the local address of interface B will
> be considered INPUT, not FORWARD.

Good point. I'll have to test that out.

Re: Implications of a permissive FORWARD chain

[Neal Murphy]

On Tuesday, February 18, 2014 09:34:22 PM Mark Fox wrote:
> Neal Murphy <neal.p.murphy <at> alum.wpi.edu> writes:
> > Perhaps this will help.
> > 
> > [...]
> 
> It does. Especially this:
> >  This allows
> >  almost anyone, almost anywhere, to determine which services are
> >  available on which systems, and to attack them (SQL attacks on RDBMS
> >  servers, SQL injection attacks on web servers, &cet.) or to allow
> >  malware (viruses, trojans, &cet.) to propagate through your private
> >  internetwork of LANs.
> 
> What I think I may have not made clear is that I'm not dealing with LANs
> here. It's a single LAN, with everything thrown onto it. That's what threw
> me for a loop. It's not fire-walling between networks. It's fire-walling to
> and from the same network.
> 
> Perhaps I've made the mistake of spending most of my time thinking about
> protecting hosts on one network from hosts on different networks, but not
> much time thinking about hosts on the same network.
> 
> In any case, it seems pretty obvious that, given the all-eggs-in-one-basket
> state of the network, really tight fire-walling is in order.

Oh. On a wired LAN, outside of programming switches to prevent host-to-host 
comms that pass through the switch (bridge), you can do almost nothing to 
prevent hosts from talking to each other.

If you're talking about VMs on a single Linux host talking through a bridge 
(virtual LAN) on that Linux host, then you can probably use ebtables to 
control the bridge because, again, the Linux host will not see IP traffic 
between VMs.

In short, outside of using a managed switch/bridge, you cannot firewall hosts 
on a LAN from other hosts on that same LAN.

Re: Implications of a permissive FORWARD chain

[Mark Fox]

Neal Murphy <neal.p.murphy <at> alum.wpi.edu> writes:

> Oh. On a wired LAN, outside of programming switches to prevent host-to-host 
> comms that pass through the switch (bridge), you can do almost nothing to 
> prevent hosts from talking to each other.

That I understand. In my situation, I have a containerization host that runs
several containers. The host can do some sanitization of the traffic coming
from the network, but only so far before it forces creators of new
containers to add new rules.

> If you're talking about VMs on a single Linux host talking through a bridge 
> (virtual LAN) on that Linux host, then you can probably use ebtables to 
> control the bridge because, again, the Linux host will not see IP traffic 
> between VMs.

That was my expectation, but I'm no longer sure that it is the case. I
haven't checked on whether the host sees communication between the
containers specifically, but my guess at this point is that it does. I'm
quite sure that disabling all forwarding completely cuts off the containers
from the rest of the LAN.

My understanding was that a bridge was a layer 2 device and netfilter would
be completely out of the loop on traffic travelling across the bridge. So I
disabled all forwarding on the container host, but was surprised when that
cut the containers off.

I don't get the impression that this is specific to containers. There is
documentation
(http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt.html)
saying that one should do a 'iptables -I FORWARD -m physdev
--physdev-is-bridged -j ACCEPT' to allow traffic between a host and any KVM
guests.

> In short, outside of using a managed switch/bridge, you cannot firewall hosts 
> on a LAN from other hosts on that same LAN.

Agreed in the general case. However, in the case of a VM or container host,
it seems that one can do some fire-walling. On a better implemented network,
there wouldn't be much need, but in my case the network shouldn't be trusted.

Re: Implications of a permissive FORWARD chain

[Neal Murphy]

On Wednesday, February 19, 2014 09:38:46 AM Mark Fox wrote:
> That I understand. In my situation, I have a containerization host that
> runs several containers. The host can do some sanitization of the traffic
> coming from the network, but only so far before it forces creators of new
> containers to add new rules.
> 
> > If you're talking about VMs on a single Linux host talking through a
> > bridge (virtual LAN) on that Linux host, then you can probably use
> > ebtables to control the bridge because, again, the Linux host will not
> > see IP traffic between VMs.
> 
> That was my expectation, but I'm no longer sure that it is the case. I
> haven't checked on whether the host sees communication between the
> containers specifically, but my guess at this point is that it does. I'm
> quite sure that disabling all forwarding completely cuts off the containers
> from the rest of the LAN.

Containers *are* a different beast.
> 
> My understanding was that a bridge was a layer 2 device and netfilter would
> be completely out of the loop on traffic travelling across the bridge. So I
> disabled all forwarding on the container host, but was surprised when that
> cut the containers off.

Depends. Reasonably modern systems have the ebtables pkg available; it is the 
layer 2 version of iptables. Since the host creates and operates the virtual 
bridge and tap devices, it handles all traffic passing to and from containers; 
but I would've expected it to work at layer 2, where bridging normally 
happens. Said differently, I would expect a Linux virtual bridge to behave the 
same as a physical bridge (switch) in that each port's traffic is not visible 
to nodes on another port.

Logically at layer 2, you would:
  - allow all traffic to and from the host's IF (the bridge)
  - allow all traffic to and from the physical NIC(s)
  - block all other traffic (which should include only VM-to-VM traffic)

I've never worked at layer 2 and don't know the nuances; I'm only aware it can 
be done. You've probably just reached the limit of my knowledge.

Re: Implications of a permissive FORWARD chain

[Pascal Hambourg]

Mark Fox a écrit :
> Neal Murphy <neal.p.murphy <at> alum.wpi.edu> writes:
> 
>> If you're talking about VMs on a single Linux host talking through a bridge 
>> (virtual LAN) on that Linux host, then you can probably use ebtables to 
>> control the bridge because, again, the Linux host will not see IP traffic 
>> between VMs.

This is of course wrong. The host does the job of passing packets to and
from VMs, so it has to see the traffic.

> My understanding was that a bridge was a layer 2 device and netfilter would
> be completely out of the loop on traffic travelling across the bridge.

Not if the kernel has BRIDGE_NETFILTER=y. Then the various
net.bridge.bridge-nf-* sysctls control which kind of traffic is passed
to conntrack, iptables, ip6tables or arptables. By default all is passed.

> So I
> disabled all forwarding on the container host, but was surprised when that
> cut the containers off.

What do you mean exactly by "I disabled all forwarding" ?
Setting net.ipv4.ip_forward=0 or net.ipv4.conf.*.forwarding=0 should
have no effect on bridged traffic. However iptables' DROP or REJECT may
have an effect on IPv4 bridged packets when
net.bridge.bridge-nf-call-iptables=1.

> I don't get the impression that this is specific to containers.

It is not. It is specific to Linux bridge.

> There is documentation
> saying that one should do a 'iptables -I FORWARD -m physdev
> --physdev-is-bridged -j ACCEPT' to allow traffic between a host and any KVM
> guests.

It is simpler and more efficient to disable passing bridged IPv4 packets
to iptables with net.bridge.bridge-nf-call-iptables=0.

Re: Implications of a permissive FORWARD chain

[Mark Fox]

Pascal Hambourg <pascal <at> plouf.fr.eu.org> writes:
> [...]
> 
> This is of course wrong. The host does the job of passing packets to and
> from VMs, so it has to see the traffic.

Agreed. Certainly, that matches with what I'm experiencing.

> > My understanding was that a bridge was a layer 2 device and netfilter would
> > be completely out of the loop on traffic travelling across the bridge.
> 
> Not if the kernel has BRIDGE_NETFILTER=y. Then the various
> net.bridge.bridge-nf-* sysctls control which kind of traffic is passed
> to conntrack, iptables, ip6tables or arptables. By default all is passed.

Yes. To be clear, I'm ecstatic that this capability exists. A little
surprised too, but happy that there is another place to do some firewalling
if needed.

> 
> > So I
> > disabled all forwarding on the container host, but was surprised when that
> > cut the containers off.
> 
> What do you mean exactly by "I disabled all forwarding" ?
> Setting net.ipv4.ip_forward=0 or net.ipv4.conf.*.forwarding=0 should
> have no effect on bridged traffic. However iptables' DROP or REJECT may
> have an effect on IPv4 bridged packets when
> net.bridge.bridge-nf-call-iptables=1.

I set the policy for forwarded traffic to DROP.

> > I don't get the impression that this is specific to containers.
> 
> It is not. It is specific to Linux bridge.

Cool. That makes perfect sense.

> > There is documentation
> > saying that one should do a 'iptables -I FORWARD -m physdev
> > --physdev-is-bridged -j ACCEPT' to allow traffic between a host and any KVM
> > guests.
> 
> It is simpler and more efficient to disable passing bridged IPv4 packets
> to iptables with net.bridge.bridge-nf-call-iptables=0.

Agreed. Since I (now) want to take advantage of the firewalling ability, I
won't be doing this here, but it is good to know it is possible.

Thanks for the discussion. It's been enlightening.