Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Krunk <krunkalot@hotpop.com>
To: Netfilter <netfilter@lists.netfilter.org>
Subject: Re: Curious problem with my iptable rules.....detailed post inside, help appreciated.
Date: Sun, 18 Apr 2004 13:10:01 -0500	[thread overview]
Message-ID: <1082311801.5336.38.camel@james> (raw)
In-Reply-To: <1082228983.2270.33.camel@katala.sterenborg.info>

On Sat, 2004-04-17 at 14:09, Rob Sterenborg wrote:
> 
> Maybe it's a bit easier if you also told us what it is that you want to
> achieve

I'm approaching this with the intention of learning the proper way to
securely lock down a production system. (it's just an old mac I have).
Most of the script was adapted from a book on security which I'm reading
(only one chapter dedicated to iptables......."Real World Linux
Security" by Bob Toxin btw.) 

>  (and why you're using 2 scripts) because I think your script can
> be a lot shorter than the main script you're using right now.
> (Btw, I didn't read all of the script.)
> 
One script is the one I'm "working with" the smaller one is a bare bones
"I know this works" script so when I hit a hitch in the other one and
the roommates get ancy from not internet I can bring it up quick.

> There's a lot of DROPping going on while in the same time you have set
> policy to DROP for the INPUT, OUTPUT and FORWARD chains. That means
> *everything* is closed already : you can't get in, out or through the
> box. Only  packets you have set an ACCEPT rule for can be received, sent
> or forwarded/routed.
> 
From what I read, this is to prevent a "hole" from opening up. By having
a default policy of DROP, anything overlooked is by default dropped. I
was under the impression that having only explicitly accepted packets
allowed is a good thing.

> Setting OUTPUT policy to DROP is good. Only it might be easier to
> troubleshoot your script if you first set it to ACCEPT, do some testing
> untill it works. Then set OUTPUT to DROP and get it working again (if it
> doesn't, because then only the iptables box won't be able to send
> packets so your clients on eth1 and eth2 shouldn't notice it).
> 
When I first built the script, I did it very piecemeal...taking one
section at a time. Started with the bare minimum forward script and
built the DENY and DROP rules one by one. Testing as I went along and
correcting syntax errors etc etc. I only set the initial DROP policies
at the very end after the script was done. To test if this was the
problem I commented out the initial DROP Policies....the same problem
persisted. Since the only remedy I've found for getting it working again
after initially running the script is a hard reboot, it greatly
complicates the troubleshooting. In essence I would have to reboot after
every added line until I found the trouble maker (ugh). I was hoping
there was some glaring error in procedure that would be caught so I
wouldn't have to do this. On a side note, I eliminated all of the DROP
and REJECT rules "just to see" and it does work that way. It would seem
that there is some policy being set which my -X and -F loop is not
catching.

> You have the RELATED/ESTABLISHED rules at the bottom of your script.
> As most (accepted) packets will be matched by these rules, put these
> close to the top of your script.
> 
> Put : echo 0 > /proc/sys/net/ipv4/ip_forward
> at the top of your script, so there won't be any packet forwarding, even
> if there are rules already.
> Put : echo 1 > /proc/sys/net/ipv4/ip_forward
> at the bottom of your script so forwarding starts when all rules are in
> place.
> 

Thank you for the suggestions, they make perfect sense....I've made the
adjustments.
> You realize that the :
> - INPUT chain is for incoming packets, DESTINED FOR the iptables box.
> - OUTPUT chain is for outgoing packets, COMING FROM the iptables box.
> - FORWARD chain is for packets going through the iptables box in either
> way.
> Every packet will *only* go through one chain. 
> 
> Did you read Oskar's iptables tutorial ?
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html

I'm in the process of reading it now, I've read several other tutorials...but this is the most thorough
I've seen yet. 

Thank you.




  reply	other threads:[~2004-04-18 18:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16 23:35 Curious problem with my iptable rules.....detailed post inside, help appreciated Krunk
2004-04-17 19:09 ` Rob Sterenborg
2004-04-18 18:10   ` Krunk [this message]
2004-04-18 19:47     ` Curious problem with my iptable rules.....detailed postinside, " Rob Sterenborg
2004-04-18 22:59       ` Krunk
2004-04-19  0:11         ` Curious problem with my iptable rules.....detailed postinside,help appreciated Rob Sterenborg
2004-04-19  1:58           ` Krunk

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=1082311801.5336.38.camel@james \
    --to=krunkalot@hotpop.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox