Re: some reality about iptables, please
Bret Comstock Waldow wrote:
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
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
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...
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:
It's about as simple as this, as root, see if iptables is running and
has rules you want or don't want.
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)?
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.
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?"
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
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
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
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.
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.
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:
#192.168.1.1 doesn't get any traffic from us
iptables -A OUTPUT -d 192.168.1.1 -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
<output from command>
#iptables -t <other table(s)> -L
<output from command(s)>
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.
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.
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
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.
My upset isn't appropriate here. I apologize. I think my questions are
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.
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.