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
next prev parent 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.