[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: some reality about iptables, please

Bret Comstock Waldow wrote:

On Wed, 2003-08-27 at 00:39, Kevin Mark wrote:
On Wed, 2003-08-27 at 00:19, Bret Comstock Waldow wrote:
On Tue, 2003-08-26 at 23:14, Kevin Mark wrote:

you can read /etc/init.d/iptables comments for info.
Hmmm.  On reading, I notice a function named "initd_clear" called by an
argument of "clear".  Running this leaves the system open - all targets
are "ACCEPT".

The README in /etc/init.d points at the Debian Policy manual, and this
mentions several standard arguments for init.d scripts - "clear" isn't
one of them.

How would I find out what (if anything) calls with this argument?  If
some automated process is going to call this, it will leave my system
with an open firewall, and I need to know to plan around it.
the script can not be accessed by anyone. it can only be called inside
the script which can only be run by a root user. So it doesnt see to be
security concern (but I'm not a security expert -- will the local guru

I'll be interested to hear it too.  In theory, there must be some reason
it was put in the script in the first place...

On my system the init.d scripts are o+rx, so anyone can read and execute them, so the script itself doesn't provide protection. I didn't change anything so I must assume this is the debian unstable default for /etc/init.d/ scripts. The commands the script tries to execute, iptables, iptables-save, iptables-root will not work from a normal user account.

That the init.d script has a non-standard command targets isn't a bad thing, but it could re-inforce the fact that maybe running your iptables save/restore scripts from init.d isn't the most logical thing to do.

My guess for the reason is simple. It is there because the script provides a conveniant interface to it. If you think of the iptables rules and the service they provide as an actual 'program' (instead of an interface to kernel ip rules) then 'starting' and 'stopping' that 'program' makes sense. If you think about it as an interface to the kernel ip rules then init.d script 'targets' such as clear, panic (RH7.3)/halt, load and save make sense.

From your first message:

Bret Comstock Waldow wrote:

I can find all the sites and advice I want about how to form iptables
rules, but I can't find any decent discussion of how to enable the damn

I get the idea that an iptables firewall is set up by actually running a
bunch of "iptables -options" lines, presumably from a script.

But where do I put the script(s)?

It's about as simple as this, as root, see if iptables is running and has rules you want or don't want.

#iptables -L

Now add the rules you want. I've seen lots of other replies with links to some informative pages. If you're still wondering, or looking I'd say this is the place to start:

http://www.netfilter.org/ (aka) http://www.iptables.com/

And for specific documentation (in English):

Check around the site. There are several links to HOWTOs and examples. You may find the same theme the author of the iptables init.d script used though. "I'm a packet filtering interface not a firewall tool." _but_ the in
iterface allows you to enter rules that you can call a firewall.


I know generally about the /etc/init.d/rcX.d runlevel mechanism.  Now I
need a sensible discussion of when and HOW to run what sorts of
iptables-rules-containing scripts so I can figure out how to protect my
system.  Please don't just tell me about "runlevels" - I know they exist
You may understand this already, but indulge me anyway. I am going to re-explain a few things because questions I didn't directly address in all three quoted blocks from your emails have the same theme. "How and when do my firewall rules get applied using this init.d script?"

Generally Debian systems run at init runlevel 3 (this is a change if you're reading about how to do things the RedHat way, or were use to it).

When the init process enters a run level it runs start and stop scripts based on symbolic links in the /etc/rc<runlevel>.d directory. Normally this is the only way the /etc/init.d scripts are called.

You need to insert your own iptables rules to define your firewall and save them as 'active':
/etc/init.d/iptables save active
(Note, you may need to mkdir /var/lib/iptables.)
You don't need to 'start' the iptables 'service' before doing this because unless you're running ipchains, iptables are always 'running', they just have an empty ACCEPT ruleset.

The iptables init.d script may not be configured to 'run' automatically. If not, using update-rc.d iptables defaults may be what you want. Read man update-rc.d

When the iptables init.d script runs automatically from the rc<n>.d init symbolic link or if you call it by hand, if an iptables-save file named 'active' exists in /var/lib/iptables then that file's rules are loaded using the iptables-restore program.

Bret Comstock Waldow wrote:

1) If I use one of those tools, it does something, sets up something. What will it do? It's someone else's canned decisions about how to
implement the choices I select from what it offers.  What do I end up
with?  Are there any holes?  How will I know if other choices I make
open up holes because I don't know how it's all coordinated?

I'm working with a copy of Real World Linux Security, and the fellow
provides a complete firewall for SOHO, and then dissects it to show the
concerns and his choices.  He also links it to adaptive firewall rules
to lock out attackers.

That's cool that you want to learn how the rules work and understand them, but if you need to spend less time and get back to schoolwork, I suggest using one of the firewall tools that have been recommended more than once in replies to this thread.

I don't have a copy of 'Real World Linux Security' so I don't know what it's saying. Are they telling you about how firewall rules using iptables works? If so, aren't there lines like:

# doesn't get any traffic from us
iptables -A OUTPUT -d -j DROP

That's the 'plumbing' level access to iptables which works for all Linux kernels supporting iptables, irreguardless of distribution. In other words, your rules failing on Debian should fail on RH or Mandrake.

And it's for Redhat, Mandrake, etc.  I have to reconstruct it for Debian
to use it.  So I need to know how to plumb it.

On running it by hand as an experiment, it locks all access - no
browser, mail, etc., so I need to learn more so I can work it all out.

And there isn't a lot of discussion I've found yet about the plumbing of

A better post might be:
What am I doing wrong with iptables rules

Here are my rules. They block all access to the internet, but I cant see why.
#iptables -L
<output from command>
#iptables -t <other table(s)> -L
<output from command(s)>

2) Other people do indeed have answers to the question - and I haven't
seen so much of a discussion of these issues in any of the sources I've
Googled yet.  The Debian Security manual really falls down on this
issue.  The book I'm reading points out that many people make the
mistake of flushing the rules before adding the new ones - the default
policy is ACCEPT.

Every HOWTO and paper I've read says to flush first. I guess I am in danger of horrible network things getting me for the microsecond(s) between when the old rules are flushed and the new ones are aplied. I suppose the concern is valid for some people and helps them relax while playing freeciv or bzflag thus making them better gamers. I haven't ever sweated over it and I'm still a poor gamer.

I take flushing first and starting with a clean slate over scratching my head trying to figure out which old rule that didn't get deleted is doing what when combined with my new ruleset because I didn't flush the old rules.

My upset isn't appropriate here.  I apologize.  I think my questions are
appropriate, though.

And I don't think leaving documentation like the above is very kind or
useful for newbies.  If I'm to figure out how to solve the problem, I
need to know how, and leaving stress-inducing comments like that in
released code is a cop-out.  If it's broke, provide a solution, or at
least a decent discussion of the issues involved, so I can work one out.

Maybe I'll end up figuring one out.


It's pretty apparent that this text has bothered you. Perhaps you could post a bug against /etc/default/ipchains with a patch adding additional helpfull text, like a pointer to netfilter.org and the /usr/share/doc/ipchains/README.Debian.gz file and whatever other information you think is helpful for newbies.

The solution isn't broken. 'Works for me' :) It just isn't optimal as the other posters have pointed out. The ifup-down method sounds very sensible. I didn't have an issue with the text, infact I had a good laugh reading it when I set up my sysem for /etc/init.d/iptables.


Reply to: