> On Sat, Jan 31, 2009 at 02:41:47AM +0100, Ansgar Wiechers wrote:
>> I also strongly recommend running a custom (stripped-down) kernel.
>
> Can you please explain why? As the distribution kernels are heavy
> modularized you won't get much less kernel code, which is one attack
> vector.
Basically for three reasons:
- I don't trust any distributor to have compiled everything except for
the absolute core functionality as modules.
- I don't trust any distributor to have disabled automatic module
loading by default.
- I don't trust any distributor to have included all the modules I need
for my firewall.
Yes, I could read their .config to understand what is or isn't included,
but frankly, by the time I have done that, I have rolled my own kernel
as well.
> The second one is also unchanged, priviledged userspace access and
> kernel code injection via /dev/mem or are a changed kernel binary.
Access to /dev/mem can be restricted with a custom kernel. As for the
"changed kernel binary": I'm not sure what you mean by that. An attacker
with root privileges could of course exchange the kernel binary, but
once an attacker gained root privileges it's "game over" anyway.
> On the other side you loose any security support for this.
Ummm... what kind of security support do you get for a self-made Linux
firewall?
>> Second problem. Don't set policies to ACCEPT without a good reason.
>
> This applies to the filter chains only. Don't set it on the nat or
> mangle tables.
Correct. I should have mentioned that I was talking about the filter
table only there. My bad.
Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
No comments:
Post a Comment