On Tue, 18 Jan 2000, Eric Preston wrote:
>> A while back, Linux enabled ip_forward by default (again, unless
>> I am mistaken). This was NON-POSIX behaviour I believe, and
>> it was changed to default to turn off forwarding by default.
>
>Is is my imagination or is ip_forward on, on redhat 6.1 dist by default? I
>can't remember.
Let me clarify what I mean by "turn off" above... This is that
/proc/sys/net/ipv4/ip_forward is defaulted to 0 which disables
ipforwarding regardless of the ipchains policy. That is what I
meant here. RedHat 6.1 and probably all other dists too default
to not modifying the ipchains rules for default policies, so the
default is in fact ACCEPT if that is what you mean, but
forwarding wont occur due to the default proc entry which
disables ip_forward. one needs to enable FORWARD_IPV4 in
/etc/sysconfig/network on RedHat, which has the effect of echoing
"1" to the proc file...
>> goal. Things that can be done safely and securely from userland
>> - should be. Not in kernel just for the sake of it, or for
>> security through obscurity.
>
>Uhm, this wouldn't be an issue of security through obscurity, that's a
>little hard with FS/Open Source. '/sbin/ipchains -L' is hardly a secret,
>nor is 'less net/core/firewall.c'. Sorry, this is just a cheap shot.
No, I didn't mean like that. I meant that some things people
want to put in the kernel for security's sake, but which do not
really provide any security anyway. Perhaps that doesn't qualify
as security through obscurity, but I don't think things should go
into the kernel for security's sake unless the provide a true
level of security, and one which can not be equivalated in
userland with existing tools. That is what I meant to say, but
alas I was not being too clear...
>> That stated, as long as the init sequence activates the
>> firewalling scripts PRIOR to network interfaces coming up, there
>
>"As long as..." that's the crux, eh.
Well, I don't see it as a problem. One can easily modify kernel
source for the non-general case. The kernel by nature, has been
coded for the general case mostly... Nobody wants surprises
here and there...
>My original message indicated that in my situation I have to
>bring up the external interface to get it's IP, then build my
>ruleset.
Right, and I agreed. Since then I've found out about:
ipchains -i <interface>
Using it, allows you to create firewall rules based on the
interface rather than it's hard coded IP address. That way the
IP may change, and the rule changes with it without
reconfiguration. I am rewriting some of my own scripts now to
use it instead of trying to determine the IP.
I still however forsee a few possible problems that may or may
not be easily solveable... It depends on how complex ones
firewall rules are.
>> is NO security problem. Local policy issues are NOT things that
>> should EVER go into the kernel. There is absolutely no increase
>> in security by putting policy in the kernel.
>
>To tell you the truth, I'm going to defer to the immanent (eminent?)
>experts on this list and try to avoid saying what should and shouldn't go
>into the kernel.
>
>My original comment was something along the lines of, "that perhaps the
>truly paranoid might want to do something like that..." I don't remember
>suggesting petitioning the powers-that-be to make this change anywhere
>except possibly on my own system.
Well, then I misunderstood, and apologize. I agree with the idea
of possibly doing something like you suggest on isolated systems
that don't fit into the general case. My intent was to say that
making that policy the default case for the official kernel would
be bad, break many systems initscripts, and generally not be a
good thing to do.
>> >If the ipchains default policy configuration was input, output, forward ==
>> >DENY by default, something like linuxconf couldn't bring up the interfaces
>> >then the rules while leaving things wide open in the middle.
>>
>> Not everyone runs a firewall. The kernel should not enforce
>> things in itself that are easily done in userland. IP filter
>> configuration is easily done in userland - by having an
>> administrator put their scripts in the proper order - which
>> RedHat does not. I suppose you'd also like to see the kernel
>> default to a higher securelevel so that root can't change
>> immutable files too. It would be more secure that way...
>> Pointless...
>
>On reflection, it seems that perhaps anything except default forward =
>DENY might be a little silly (paranoid?), but then again, you can always
>work around this by, as you put it, ordering your initscripts properly in
>userspace and a couple of ipchains commands.
Yes, that was mainly what I was trying to say. ip_forward though
is effectively DENY allready by default via /proc. So you are
correct.
>> No. If there are no active network interfaces at boot time, then
>> there is NO WAY for ANY PACKETS to enter the machine PERIOD. The
>> init scripts can change the firewall policy first to DENY/REJECT,
>> enable the ACCEPT rules that override, and THEN bring up network
>
>My whole point from the beginning is that it's hard to build your firewall
>ruleset and load them before bringing up an interface on a DHCP system
>(I've setup a handful of home cable/adsl firewall systems, granted perhaps
>this is uncommon) without first bringing up an interface to get today's IP
>number. At no time did I suggest packets were magically appearing out
>of thin air. You're beating this dead horse and it's getting smelly.
Yes, I agreed with that part 100% at first. Now it is more like
50% after finding the "ipchains -i" option. There are still some
issues (in my understanding) of how to rewrite ipchains scripts
for PPP/DHCP which can run prior to interface activation.
I would like to work with you (in private) on perhaps solving any
issues either one of us finds with such scripts if you're
interested. Any rule using the IP number directly, or Network
number, or netmask of the interface could potentially need to be
re-written in a way that doesn't hard-code it. This may or may
not be possible. I'm looking into it now...
>> interfaces. Extending your logic, we should build "init" into
>> the kernel, and all of the rest of the initscripts that modify
>> default system policy in some way related to security. If it can
>
>Please don't put such inane comments in *my* mouth.
Sorry... perhaps too much coffee... ;o)
>> not a lot to ask. The kernel's job is not to "hand hold".
>
>See previous comment re:appropriate personnel for kernel-responsibility
>decision-making...
Oh, I agree with you 100%. I think that people such as ourselves
however as part of the community need to discuss the issues too.
Often both guru's and non-guru's alike learn something from it.
>> And you'd also have to have ipchains installed on every system,
>> including ones that have no need for ip filtering - just to
>> re-enable networking.
>
>Valid point. Less systems if only default forwarding is DENY, correct?
Well you are correct, but even moreso. Since the default forward
policy can be ACCEPT as well - forwarding will be denied anyway
due to /proc (see above). So yes, ipchains would not be required
in this case ase well. (which is the way it is now basically -
default ACCEPT on everything - but forward is denied until
ip_forward=true)..
>> Such machines are often laptops or some other system using DHCP
>> or similar, and is *HIGHLY* unlikely to be a server, or running
>> an ip firewall to begin with. If the ipchains script executed
>
>I've got nothing but boxes like this. None of them are laptops (somebody
>can send me a nice one if they like, I'd like to get a FreeS/WAN
>roadwarrior setup going ;-) Anyway, I'm not gonna pretend I know the
>*average* setup, my sample size is too small.
Right. There are many convoluted setups out there. Impossible
to determine what their needs are. That means things should be
as sane as possible to cover all possible cases in a general and
useful way. The DHCP/dynPPP problem is a special case, but
perhaps not as bad as both of us originally figured...
Another thought just occured to me, and that is the new
"netfilter" code in 2.3.x. ipchains is history now, and replaced
by netfilter in 2.3.x. I wonder how this will effect the various
things we've discussed? I'm going to check up on netfilter
now... I'd rather redo my ipchains scripts to netfilter in
anticipation of 2.4 than mess around like I had to from ipfwadm
to ipchains... ;o)
>> prior to networking going up it could test for DHCP or similar
>> being used - by examining files in sysconfig for example, and
>> could enable only what needs to be enabled in order for DHCP to
>> work, then enable full firewalling later. At any rate such a
>> system would be an extreme rarity.
>
>One man's potato is another man's potato. Rare to you,
>common to me. But I digress...
You have a good point there... ;o) For all I know, NASA could
have labs full of machines configured in a way I would call
"rare". ;o)
>Anyway, I can't be bothered to go on responding to your message, you're
>the one who forwarded this to the list, and I'm willing to guess that
>everyone'd be just as happy if I dropped this packet^H^H message on the
>floor right here.
Heheh.. Always good to end off with a good pun... ;o)
>Unable to connect to remote host: Connection refused
I'm glad to see we share a similar sense of humor through this
discussion. ;o)
Ok.. I think we've got the answers, info, etc.. for this now
from a variety of people. I also think that we agreed on things
more than we initially realized due to not saying things in a
clarified manner.
So, lets continue via private mail (with the DHCP/PPP config
probs perhaps?) or just kill the thread. I'm going to see if I
can fix my scripts in the dynamic case now...
If you're interested in this, let me know privately and we'll
discuss it.
Take care,
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateJoin the FreeMWare project - the goal to produce a FREE program in which you can run Windows 95/98/NT, and other operating systems.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:19 EST