Re: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...which isbetter for firewall?
Hi Jeric Just an opinion.... I am right now playing with SuSE 8.0, the default kernel is 2.4.18. For your firewall - I believe iptables is the way to go....but get it from SuSE 7.3 and there is an update to 2.4.16 kernel for 7.3 This 8.0 seems to big and clumsy for a 486. - Bill "jeric" <jeric@mmcable.com> 04/24/02 04:40 PM To: <suse-security@suse.com> cc: Subject: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...which is better for firewall? Hi, Since SuSE 8.0 is coming out, I am toying with the idea of upgrading my firewall/router box. 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? At this point in those two kernel developments, is there still a security/maturity difference? 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 read that the default install GUI will not run on an old x486, but was not sure about the minimal install option. Also, if upgrading to SuSE 8.0, which kernel does it install by default? Thank you, jeric
Hi Jeric
Just an opinion.... I am right now playing with SuSE 8.0, the default kernel is 2.4.18. For your firewall - I believe iptables is the way to go....but get it from SuSE 7.3 and there is an update to 2.4.16 kernel for 7.3 This 8.0 seems to big and clumsy for a 486.
- Bill
A few years ago, fast machines and disk space was more expensive than today, so that I always preferred to run my self-compiled kernel, usually not from the SuSE kernel sources, but the original ones. Today, I have many reasons to believe that the SuSE kernel suits my needs better, and today I don't care about the disk space for more than 1000 kernel modules either. After all, the modules that aren't used shouldn't consume any memory, and the security standpoint doesn't suggest a non-modularized kernel any more. Anyway, some things _did_ change: The 2.4 kernel uses considerably less CPU, but it also needs more RAM. I've seen 8.0 running on a 486-DX/100, and it works fine. But don't run KDE on it... Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "You don't need eyes to see, | SuSE Linux AG - Security Phone: // you need vision!" | Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - -
On Thu, 25 Apr 2002, Roman Drahtmueller wrote:
any memory, and the security standpoint doesn't suggest a non-modularized kernel any more.
Could you elaborate on that a little more? I thought, that the nastiest root-kits available exploit the module mechanisms? Not true? Regards, Michael
any memory, and the security standpoint doesn't suggest a non-modularized kernel any more.
Could you elaborate on that a little more? I thought, that the nastiest root-kits available exploit the module mechanisms? Not true?
Negative... It's in one of the phrack magazines: manipulation of kernel memory through /dev/mem, thereby making in possible to introduce new code. So, you see: As long as you can manipulate memory, you're not safe.
Regards, Michael
Regards, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "You don't need eyes to see, | SuSE Linux AG - Security Phone: // you need vision!" | Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - -
Yuppa, Roman Drahtmueller wrote: [...]
Could you elaborate on that a little more? I thought, that the nastiest root-kits available exploit the module mechanisms? Not true?
Negative... It's in one of the phrack magazines: manipulation of kernel memory through /dev/mem, thereby making in possible to introduce new code. So, you see: As long as you can manipulate memory, you're not safe.
If anyone is interested, here's the article where Phrack #58 refers to in "Advances in Kernel Hacking": http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt Boris Lorenz <bolo@lupa.de> ---
On Thu, 25 Apr 2002, Roman Drahtmueller wrote:
Could you elaborate on that a little more? I thought, that the nastiest root-kits available exploit the module mechanisms? Not true?
Negative... It's in one of the phrack magazines: manipulation of kernel memory through /dev/mem, thereby making in possible to introduce new code. So, you see: As long as you can manipulate memory, you're not safe.
Ok, so the conclusion (for the slow-minded..): As long as /dev/mem is around, non-modularized kernels don't help. Right? Regards, Michael
On Thursday 25 April 2002 15:43, Michael Seewald wrote:
On Thu, 25 Apr 2002, Roman Drahtmueller wrote:
Could you elaborate on that a little more? I thought, that the nastiest root-kits available exploit the module mechanisms? Not true?
Negative... It's in one of the phrack magazines: manipulation of kernel memory through /dev/mem, thereby making in possible to introduce new code. So, you see: As long as you can manipulate memory, you're not safe.
Ok, so the conclusion (for the slow-minded..): As long as /dev/mem is around, non-modularized kernels don't help. Right?
You could also take a look at lids (www.lids.org), which can prevent /dev/mem access as well as subsequent loading of modules. It does this by a tunable control of the use of capabilities by programs. Lids can also control the access to files to make them invisible or Read-Only for just some or all programs run by root. Andreas ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been scanned for the presence of computer viruses. **********************************************************************
participants (5)
-
Andreas Baetz -
Bill.Light＠kp.org -
Boris Lorenz -
Michael Seewald -
Roman Drahtmueller