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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
