Comment by geofft | Hacker News Reader

Comment by geofft | Hacker News Reader

Parent Full thread

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.

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.

On linux:

  echo 1 > /proc/sys/kernel/modules_disabled

  http://www.outflux.net/blog/archives/2009/07/31/blocking-module-loading/

Awesome, thanks.

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.

You are thinking of BSD's securelevel:

http://www.freebsd.org/doc/en/books/faq/security.html

" … 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.

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.

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.

My internal exposure was small because there weren't many people in the office (usually 2-3 at most). In a larger environment I would probably filter to specific admin access points.

I think in this "post-Snowden" era, you now need to consider not just the people on the internal network, but whether any of the gear on that network might be betraying you to the NSA.

I'm sitting here in my loungeroom looking at my printer, the PlayStation, the Media Server, a bunch of laptops, a few phones, a couple of iPads, a Mac Mini, the linux box, a RaspberryPi, the cheapo chinese adsl/wifi box, and the old NetGear ethernet switch – and wondering if any of them are taking advantage of the privileged access my home IP address has on a bunch of other internet connected networks?

Oh sure. Actually that was part of my monitoring too (periodic reporting of outgoing natted connection).

Reply on news.ycombinator.com