All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Rodrigues <leolistas@solutti.com.br>
To: ML netfilter <netfilter@vger.kernel.org>
Subject: Re: Implications of a permissive FORWARD chain
Date: Tue, 18 Feb 2014 16:29:20 -0300	[thread overview]
Message-ID: <5303B490.6070606@solutti.com.br> (raw)
In-Reply-To: <loom.20140218T183628-993@post.gmane.org>

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




  reply	other threads:[~2014-02-18 19:29 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 [this message]
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
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=5303B490.6070606@solutti.com.br \
    --to=leolistas@solutti.com.br \
    --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.