All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Fox <mark.fox@gmail.com>
To: netfilter@vger.kernel.org
Subject: Re: Implications of a permissive FORWARD chain
Date: Wed, 19 Feb 2014 14:38:46 +0000 (UTC)	[thread overview]
Message-ID: <loom.20140219T152148-367@post.gmane.org> (raw)
In-Reply-To: 201402182152.38155.neal.p.murphy@alum.wpi.edu

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.


  reply	other threads:[~2014-02-19 14:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 17:53 Implications of a permissive FORWARD chain Mark Fox
2014-02-18 19:29 ` Leonardo Rodrigues
2014-02-18 20:02   ` Mark Fox
2014-02-18 21:03     ` Amos Jeffries
2014-02-19  1:25       ` Mark Fox
2014-02-18 22:10     ` Neal Murphy
2014-02-19  2:34       ` Mark Fox
2014-02-19  2:52         ` Neal Murphy
2014-02-19 14:38           ` Mark Fox [this message]
2014-02-19 18:12             ` Neal Murphy
2014-02-22 23:02             ` Pascal Hambourg
2014-02-26 15:42               ` Mark Fox
2014-02-18 19:57 ` Ambroz Bizjak
2014-02-19  2:38   ` Mark Fox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20140219T152148-367@post.gmane.org \
    --to=mark.fox@gmail.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.