Search This Blog

Saturday, January 31, 2009

Re: my debian does not read my own iptables script

On 2009-01-31 Bastian Blank wrote:
> 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: