All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Grant <gtaylor@riverviewtech.net>
To: Brent Clark <bclark@eccotours.dyndns.org>
Cc: iptables <netfilter@lists.netfilter.org>
Subject: Re: DROP
Date: Mon, 18 Apr 2005 01:36:35 -0500	[thread overview]
Message-ID: <42635573.3010104@riverviewtech.net> (raw)
In-Reply-To: <42634792.2070307@eccotours.dyndns.org>

> I was wondering, if was adviseable to set the default policy for tables 
> nat and mangle to DROP.

I don't know if it is advisable or not but it is entirely possible.  Just as you explicitly allow traffic in through your filter chains via matching rules you will have to explicitly allow traffic in through your nat / mangle chains respectively too.  I've done this in the past and found it somewhat overkill but effective.  I don't think traffic in the mangle / nat tables reaches up to the standard TCP/IP, UDP/IP stack for your daemons to accept or drop as in port not advisable if you try to connect to an unknown / not listening service.  If you had someone hammering away at a port on your system you could very easily add a rule in either nat:PREROUTING or the respective mangle chains.  I do know that when you start firewalling in the nat and mangle table things get a lot more complicated as traffic will pass through one or more chains before it even reaches the filter table (this is esp
 ecially true with the mangle table) and thus more complicated.  I can't give you a reason 
to not do this, other than possibly excessive complexity.

> So do i need to need to go the extra mile and set the default policy for 
> tables nat and mangle to DROP.

I don't think I would do it again unless I was excessively paranoid.



Grant. . . .


  reply	other threads:[~2005-04-18  6:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-18  5:37 DROP Brent Clark
2005-04-18  6:36 ` Taylor Grant [this message]
2005-04-18 13:35 ` DROP Jason Opperisano
2005-04-22 13:54   ` DROP Stephen J. McCracken
2005-04-22 14:28     ` DROP Jason Opperisano
2005-04-22 14:34   ` DROP Stephen J. McCracken

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=42635573.3010104@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=bclark@eccotours.dyndns.org \
    --cc=netfilter@lists.netfilter.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.