3 ms·

It's funny. Folks used to laugh at me for being too paranoid to allow loadable kernel modules on my firewalls (actually I preferred to host the kernels on read

• geofft 13y ago
  The thing is that distros tend to use loadable modules, and if you want to avoid that you need to compile your own kernel (as you seem to be doing), and at least I am a lot happier getting security updates from my distro than being on the hook for recompiling them myself in a timely fashion. You can get most of the security benefits of avoiding loadable modules by setting the sysctl kernel.modprobe (i.e., /proc/sys/kernel/modprobe) to "/bin/false" instead of "/sbin/modprobe", late in the boot process. So everything needed to initialize your hardware is loaded, but anything that an unprivileged user attempts to autoload (like a buggy kernel module for a socket family you've never heard of) fails. I have a config like this on all the security-sensitive servers I run, which tend to have a few thousand unprivileged users. It's actually a shell script that logs the attempt and then returns false, instead of silently returning false, but "/bin/false" is good enough. But do note that this is a bit orthogonal to the issue mentioned in the article: the proposed attack involves the victim machine having the kernel and modules intact on disk, but device firmware compromised so that it changes the kernel after it's been loaded into memory.
  • dredmorbius 13y ago
    Building a kernel isn't difficult (and used to be pretty much required). Build support in many distros is quite robust. The real challenge is that once you've compiled a kernel, that's all you've got in terms of support. If you need to add filesystem support, a networking capability, additional driver support, etc., you've got to configure and build a new kernel, and test it, which is distinctly less convenient than autoloading an existing module (or even one you've newly compiled in many cases, on a running kernel). I seem to recall a kernel option or syscontrol, possibly from OpenBSD/FreeBSD, which prevents loading of additional modules once it's been set. This allows you to boot and load modules, but then no more. If your boot media are read-only, this gives a fairly high level of confidence. I cannot find a reference though.
    • pedro84 13y ago
      On linux: echo 1 > /proc/sys/kernel/modules_disabled http://www.outflux.net/blog/archives/2009/07/31/blocking-module-loading/
      • dredmorbius 13y ago
        Awesome, thanks.
    • einhverfr 13y ago
      For a firewall, the hardware is pretty constant. You don't generally need new filesystems. It's just a matter of frequently downloading the source, compiling, and rebooting (with the option to boot back if something goes wrong). If you need to test, it isn't that hard to set up a testing environments with a duplicate set of hardware if you need high availability. For lower availability needs, testing in place is sufficient. For may consulting business, my availability needs were such that testing in place with the option to roll back was sufficient.
    • GalacticDomin8r 13y ago
      You are thinking of BSD's securelevel: http://www.freebsd.org/doc/en/books/faq/security.html http://www.freebsd.org/doc/en/books/faq/security.html
  • bigiain 13y ago
    " … I am a lot happier getting security updates from my distro than being on the hook for recompiling them myself in a timely fashion." It seems to me that security updates for the kernel are only a tiny part of what a distro releases as security updates. For something like a dedicated firewall – if I've spent the time to compile my own kernel, I'm unlikely to be running all the userspace software that a distro needs to keep updated/secured. My firewall box (probably) doesn't need to update to fix newly discovered flaws in MySQL or PHP or whatever.
    • einhverfr 13y ago
      Right. Additionally everything was configured, where a network service was required (for example ssh) to be only listening on the internal interface. The external network exposure was tiny.
      • bigiain 13y ago
        Keep in mind – the people I might have called "overly paranoid" in the pre-Snowden internet era would probably advise you to secure your infrastructure just as much from internal attacks as external ones – anybody targeting you specifically (as opposed to a fly-by botnet powered net-wide vulnerability exploit) is likely to get a foothold on a less-protected machine inside your firewall via non-direct means (spear-phishing an admin's laptop or NSL-ing your OS or router vendor). That makes it far more "interesting" working out appropriate protection against high level attacks – fortunately for me it's purely a hypothetical defense, my personal (and professional) stance is that if law enforcement or state level espionage targets me, I'm hosed and will happily turn over passphrases and encryption keys to anyone with a badge (and hopefully a court order), and I assume any of the people who I rely on for security (from my ISP to my VPS provider, my SaaS vendors, my OS vendor, through to my hardware suppliers) will sell me out pretty much instantly if the NSA(/GHCQ/ASIO) ask them to. I can _probably_ trust a RaspberryPi that's never been network connected – but it'd be foolish to assume anything else digital I own isn't trivially vulnerable to the NSA if they cared enough about it.
        • einhverfr 13y ago
• jacquesm 13y ago
  You have my vote. Static kernels are the way to go for production systems. This also gets rid of some nasty dance-steps in case your boot device needs a driver that loads as a module. Ram disks to get around such limitations are pretty easily subverted and hardly anybody ever looks at what is actually going on in there which makes them an excellent place to pull tricks.
  • einhverfr 13y ago
    For firewalls, the solution is simple: Choose your hardware carefully.