On Wed, 2003-08-27 at 00:39, Kevin Mark 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 account.
On Wed, 2003-08-27 at 00:19, Bret Comstock Waldow wrote:
On Tue, 2003-08-26 at 23:14, Kevin Mark wrote:<snip>
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
commment)
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 things.
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)?
#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): http://www.iptables.com/documentation/HOWTO//packet-filtering-HOWTO.html
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.
[snip]
I know generally about the /etc/init.d/rcX.d runlevel mechanism. Now IYou 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?"
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
already.
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 toThat'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 firewalling.
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)>
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 old rules.
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 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.
Cheers, Bret
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.
Jacob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
