IP filtering should default to DENY?

From: Mike A. Harris (mharris@meteng.on.ca)
Date: Mon Jan 17 2000 - 05:56:21 EST


On Mon, 17 Jan 2000, Eric Preston wrote:

This is posted to linux-kernel because I do not have POSIX, etc..
documents handy to provide pure facts, but I know other people
do. Also, I figured others would have a better job in squashing
the thread quickly - either way, and with a lot more valid points
than I could.

The thread is based on a message I wrote claiming that the boot
sequence in RedHat brings up network interfaces prior to
linuxconf enabling firewall rules thus giving a window of
opportunity at boot time at which the firewall is not enabled. I
suggested that the firewall scripts should be called PRIOR to
networking.

Next, it was suggested that the kernel's source be modified to
change the default rules to DENY instead of accept. I did not
see any reason for this since the same can be achieved in
userland without editing source, just by putting the ipchains
script ahead of the one that enables network interfaces.

This now brings up a debate that the kernel would be more secure
if it defaulted to DENY which I disagree with, and believe that
it would likely violate POSIX or UNIX98 or some other standard.
I do not have any specific info to support this, but I'll bet
someone else does know and can set things straight.

So, what is the reason for the ipfilter defaulting to ACCEPT?
(Aside from the fact that it doesn't matter, and can be done in
userland quite effectively that is... ;o)

----

>> No, that would violate POSIX, and possibly UNIX98 or other >> standards (although I can't offer a particular example). > >Frankly I don't believe you. How would that violate POSIX or UNIX98, can >you point me to where this is stated? You're telling me that POSIX or >UNIX98 defines default firewalling policy?

I was speaking non-authoritatively and thought that was clear, but perhaps not.

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.

I would put my money that POSIX or UNIX98 or some other standard that we are aiming for compliance with also details the default ip filter policy. Someone else can confirm or deny this. Either way, it is pointless because putting policy in kernel is not our 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.

>Even if it does, breaking a recommendation for security seems like a good >idea to me.

No it does not. There would be no increase in security. When the Linux kernel boots up, there are NO NETWORKING INTERFACES activated. Regardless of what the IP filter's default policies are, there is NO NETWORKING so NO effectively the kernel doesn't pass any packets - because there are not any, and can't be UNTIL the networking interfaces are activated. There isn't even a loopback interface until it is activated.

That stated, as long as the init sequence activates the firewalling scripts PRIOR to network interfaces coming up, there 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.

>> Changing the kernel's default policy is pointless. It can be >> done in userland 100% safe. > >It's not pointless.

It is pointless. If it was not, then Linus, Alan, or someone else would have done so allready. I do not want to argue with you about it because even that is pointless.

>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...

>Go look at the code. I believe the most relevent piece is in >net/core/firewall.c, in the bottom __initfunc function in the assignment >== FW_ACCEPT. Modifying the initial state of the firewalling code requires >modifying the c source and rebuilding the kernel. This is not a 100% >userland possible task. It's a 100% userland impossible task. As outlined >below it's not even 100% safe in all circumstances.

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 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 be done securely and safely from userland, then it should exist there. The fact that a system can be ran by an idiot that puts things in the wrong order is not the problem of the kernel source. Hire an admin that is not an idiot and check the configuration to ensure firewall rules come before networking is not a lot to ask. The kernel's job is not to "hand hold".

>Make it default DENY or REJECT and then no >distribution-maker/userland-app-writer could decide to open the system up >by accident, regardless of the order of scripts and bring up of >interfaces. You'd have to have a poorly written firewall ruleset to open >things wide open.

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.

>This makes the most sense. Stop the problem at the most effective point.

The most effective way is the way it is now.

>Why waste your time tracking down this particular distributions sequence >of startup scripts? Maybe a different distribution is different, I think >you can fix it for all of them this way.

And then you will require that every system requires ipchains, including boot floppies, and also that joe user knows how to re-enable the networking. What you are proposing is effectively "totally disabling networking" in kernel, and requiring a userland tool to re-enable it.

>> The kernel boots up with default >> policy of ACCEPT. This is harmless because NO interfaces are >> configured yet. A firewall script runs and changes the policies >> as per local configuration, and THEN the interfaces are brought >> up. > >I can think of at least one configuration where it will not be harmless >given an average situation. Take dynamic assignment of the external >interface IP number for example. How do you get the external IP for use in >the firewall ruleset without bringing up the interface?

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 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.

With your proposed solution of enforcing userland policy in kernel by default, here is what would happen on such a system - using your own example:

1) Kernel boots up and configures DENY or REJECT on input/output/forward chains internally. 2) Script runs that attempts to bring up network interface using DHCP or some other "dynamic assignment" method as you propose. 3) The packets do not go out nor return because ip filtering has defaulted to disabling all networking. 4) The interfaces fail to come up.

5) The ipfilter script runs and enables filter rules but there are no interfaces.

Your scenario loses. The proper way to do ANY sort of ip filtering is to activate the filter rules prior to network interfaces going up. That includes default policy and rule overrides. There are cases like DHCP et al that require special things, but again as I said above, those machines are unlikely to use ipfiltering anyways, and if they do they are rare cases which can likely be easily worked around via scripting or manually.

>Once the interface is up, the ACCEPT policy is in effect and >sure, maybe you got lucky and didn't bring up the internal >interface yet, but you're still in an default ACCEPT situation. >If you did, then you're in the aforementioned race condition to >bring up the appropriate rules. (what you say linuxconf does)

Except that the interface would not COME up because you've defaulted the kernel to DENY. ;o)

>Anyhow, you do it your way, I'll do it mine. I'll let you know if I figure >out an ultrafast racecondition exploit... ;-)

Just don't try to use your machine with DHCP. ;o)

Sorry for the long post people, but I would like to see how experienced kernel folk think about changing default policy like this. Perhaps it is I that is wrong, and something that I am overlooking.... I think that if that was the case though, it would have been changed a LONG time ago...

Take care, TTYL

-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate

Join the FreeMWare project - the goal to produce a FREE program in which you can run Windows 95/98/NT, and other operating systems.

http://www.freemware.org

- 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:15 EST