[Cerowrt-devel] cerowrt security

[Dave Taht]

Obviously security is on everyone's mind right now, and I have been
taking what steps I can to improve matters over the past several weeks.

Next up is https support.

The whole /dev/random and entropy issue has bugged me for YEARS, I am 
glad various parties are making a dent in it.

That said, I'm not into security theater... 

On Mon, Oct 21, 2013 at 09:31:12PM -0400, Aristar wrote:
> I understand this may be out of the scope of cerowrt right now since we're
> trying to get closer to a stable release and it's primary focus is on
> reducing buffer bloat, but as we get closer to a distribution I do have
> some security suggestions for consideration in the future.

Cerowrt has multiple goals documented in multiple places. Bufferbloat was
primary, of course, but better security has always been on the roadmap.

One of my big bugaboos is privilege separation. The squashfs filesystem
supports nothing more than uid 0, and most processes run as root, which
is just pain wrong... I'd like the front end web server to be running
as a very restricted user in particular and using fastcgi to be talking
to the config....

> DNSCrypt-proxy ( http://www.opendns.com/technology/dnscrypt/ ) Is becoming
> popular with a lot of router firmwares such as Tomato-USB and DD-WRT. It
> runs as a local service which proxies DNS requests to OpenDNS (or any other
> compatible DNS providers) with an encrypted connection, secure from
> evesdropping or MITM attacks. There is a wiki tutorial on openwrt here (
> http://wiki.openwrt.org/inbox/dnscrypt ) however it's a bit out of date.
> Not sure why it hasn't been included in openwrt trunk yet (
> https://dev.openwrt.org/ticket/12969 ). I've been running the latest
> version I could find (1.3.2 from this thread here:
> https://forum.openwrt.org/viewtopic.php?id=36380&p=3 ) on cero 3.7.5, it
>  requires setting dnsmasq to use 127.0.0.1 for dns requests. Perhaps if
> this makes it into trunk we'd be able to consider it in the future? The
> full source is available here: https://github.com/opendns/dnscrypt-proxy -
> notably, it requires libsodium to function.

I can make it available as an optional package in ceropackages. patches
gladly accepted.

> sysctl.conf network hardening:
> 
> source address verification to protect against IP spoofing
> net.ipv4.conf.default.rp_filter=1
> net.ipv4.conf.all.rp_filter=1
> more information here:
> http://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering

Well, I'd like igmp and pimd to actually work, too.

I'd REALLY like BCP38 to "just work" too. I'd argue that's more generic
and harder to do right than rp_filter.

I was actually under the impression these two were set by default these days.

> 
> Enable RFC 1337 to protect against time-wait assassination hazzards:
> net.ipv4.tcp_rfc1337 = 1
> I think only Linux hosts seem to support this so far, but since it's part
> of the RFC standard I don't see why this shouldn't be enabled by default.
> more information: http://tools.ietf.org/html/rfc1337)
> Other information: "This boolean enables a fix for 'time-wait assassination
> hazards in tcp', described in RFC 1337. If enabled, this causes the kernel
> to drop RST packets for sockets in the time-wait state. Default: 0"

Hmm. Dunno. 

> 
> IPv6 Privacy Extensions (RFC 4941) ( http://tools.ietf.org/html/rfc4941 )
> net.ipv6.conf.all.use_tempaddr = 2
> net.ipv6.conf.default.use_tempaddr = 2
> TLDR version: "IPv6 typically uses a device's MAC address when choosing an
> IPv6 address to use in autoconfiguration. Privacy extensions allow using a
> randomly generated IPv6 address, which increases privacy"
> Ubuntu enables this by default (and probably other distros too).

It is possibly less useful on a router that usually sets it's interfaces to
whatever::1:1/64 whatever::2:1/64

That said, I would actually like it very much if it could use privacy addresses
for some stuff, so long as the dynamicism in it was up to homenet standards.
It isn't. It makes me nervous to think my core dns server is going to hang
off some dns address I can't remember either.
 
> Symlink Protection:
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1
> "A long-standing class of security issues is the symlink-based ToCToU race,
> most commonly seen in world-writable directories like /tmp/. The common
> method of exploitation of this flaw is crossing privilege boundaries when
> following a given symlink (i.e. a root user follows a symlink belonging to
> another user)."


> More information here (with a lot of refernces)
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection
> Not entirely sure how this would effect cerowrt, or if it's even important
> at all with our current filesystem layout but worth looking into.


Well I'm not sure if this is a real problem or not. I'd certainly like a 
security minded individual to try out the attacks outlined here:

http://securityevaluators.com/content/case-studies/routers/soho_service_hacks.jsp

The successful ones were mostly an exploit via symlink against samba.


> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel