RE: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...w hich is better for firewall?
The following is entirely personal opinion.
Since SuSE 8.0 is coming out, I am toying with the idea of upgrading my firewall/router box.
I prefer not to update distributions, but rather perform fresh installs, if tolerable. I've had a couple of problems when updating in the past, but I've forgotten the specifics.
It is currently running 7.0 with kernel 2.2.19 and ipchains. Is the upgrade to the better iptables worth also porting over to the less mature 2.4.x kernel?
It is debatable whether ipchains is *better* than iptables. Actually, you can never claim anything to be better than something else without specifying a metric. You will certainly find quite a number of people of the opinion that ipchains is more secure or even gives more security than iptables. You'll find a considerable number that say the opposite. It's up to you to form your own opinion.
At this point in those two kernel developments, is there still a security/maturity difference?
That depends on your measure. I prefer iptables to ipchains, but I'm not sure I trust it as much, especially the connection tracking code. There have been numerous bugs in the masquerading helpers and coding them isn't always exactly easy. Connection tracking modules are very similar to masquerading modules. I am convinced that there is a wide range of security between the different conntrack and masq modules... As far as the maturity of the kernels go, I haven't had any problems with the 2.4.10 or 2.4.16 kernels supplied by SuSE for the 7.3 distro yet. I did have some strange phenomena with earlier ones, but at least one of those was a Mantel kernel, which are clearly labelled as experimental-grade. I have pretty unspectacular machines, though, and don't use many of the fancy new kernel options. BTW, I know of a problem on a SuSE 7.0 machine with the reiserfs release on it. Seems that postfix relies on the kernel filesystem driver to report a certain error code when checking for maximum message size and some versions of reiserfs supply the wrong code. I don't know if there's an update from SuSE that rectifies the problem. I do know that the current iptables release in SuSE 7.3 has a buggy iptables-save, which creates '--reject-with reject-with' instead of '--reject-with tcp-reset'. I find this a very annoying bug and it rather unfortunate that SuSE haven't released an update yet. However, I have only informed Roman about this problem per email and haven't made any further efforts to get the problem solved -- I expected the iptables in SuSE 8.0 to be absent of this bug and have been waiting for it. But this is a problem I have with SuSE or, more specifically, with their policy of mostly patching the source code of packages they originally used when building a distro and not releasing more current versions of the original packages (i.e. the tarballs) as updates. Security-critical bugs are fixed, but my impression is that functional bugs aren't rectified as quickly, if at all. And you seldom get the features a new release of the tarball package contains. It's probably unreasonable to expect SuSE to provide updates to all software packages in the distro for its entire lifetime. I have a feeling RedHat RPMs are compatible across major version numbers, maybe this would be a beneficial compromise. However, that could also involve disadvantages I haven't though of.
And if I upgrade to 8.0 will I be able to still install it on an x486 with 64MB RAM, box using the minimal install option?
I suppose you should be able to install it. I can't say how well it'll run. I recommend against the use of KDE or Gnome, if X at all.
I read that the default install GUI will not run on an old x486, but was not sure about the minimal install option.
I don't know if it checks the CPU (don't think so), but it won't run on machines with less than 64 MB RAM. So it should attempt to run on your machine.
Also, if upgrading to SuSE 8.0, which kernel does it install by default?
2.4.18, as someone else has also already said. Cheers Tobias
participants (1)
-
Reckhard, Tobias