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