[Dnsmasq-discuss] Kernel security requirements for a firewall
richardvoigt at gmail.com
richardvoigt at gmail.com
Wed Jun 24 00:02:00 BST 2009
On Tue, Jun 23, 2009 at 3:17 PM, Brad Morgan <b-morgan at concentric.net> wrote:
> I opened my mouth and admitted that my firewall (not a general purpose Linux
> machine) is still running Redhat 9. It was built when Redhat 9 was the
> latest version available and it was patched religiously until the legacy
> project up and died.
> There are only a few processes running on that machine none of which has any
> outstanding security vulnerabilities reported against it. It rejects almost
> all known ports and the few it doesn't reject are almost all forwarded to
> another machines which are kept current. Dnsmasq is one of the processes
> running on that machine as it makes sense (to me) for it to be on that
> In my experience, 90% of kernel updates are for new hardware or new feature
> support. Once a given kernel version is stable (by which I mean all known
> vulnerabilities have been patched, the other 10%of the updates), there's
> little to be gained if the new hardware or new features aren't required.
> > Running firewalls on outdated kernels is as dangerous as it can get - some
> > code injection might disable your firewall and then expose your whole LAN.
> > Brad's practice however is misguided in itself.
> > He was talking to Brad Morgan, who by his own admission does not install
> kernel updates
> > on his firewall running RH9
> Rather than make rash one-line statements about my firewall policies (which
> are not the same policies I use on numerous other systems I am responsible
> for), please put forth some valid arguments as to why my firewall kernel
> (2.4.20-46.9.legacy) is any less secure than one which is running a more
> up-to-date kernel version.
Please note that right after correcting the OP who thought his own
update policy was under attack (that's the "your own admission"
sentence you quoted above), I then refuted Matthias's claim of "as
dangerous as it can get". Here's what I said, for further discussion
in this thread where it is on-topic:
Note of course that prevention of code injection is not the kernel's
role. Limiting the damage is, a code injection attack against a
user-mode process is far more likely to achieve a successful jailbreak
on an unpatched kernel, but the user-mode process can and should be
updated with no need for a kernel-stopping reboot. And the most
up-to-date kernel is completely powerless to protect a system whose
network facing services aren't properly restricted via user account
and capabilities. Kernel updates are important, but they aren't a
A buffer overflow in a kernel module processing incoming network data
is a different story of course, but this is a very slim attack
surface, especially on a well-configured firewall (e.g. no khttpd,
> I have a database of over 1,000,000 unsuccessful attempts at penetrating my
> firewall since it was built. I can also point to numerous firewall
> appliances and firewall specific Linux distributions that are still running
> a 2.4 kernel. I believe in this application, newer is not always better.
Please note that 2.4 kernel is not synonymous with old. That kernel
is still maintained, the current patch level according to kernel.org
And even the least secure installations routinely stop the vast
majority of attacks, if only because the attack is against a specific
service that isn't even running. So a large number of stopped attacks
is no indication of security.
More information about the Dnsmasq-discuss