[Cerowrt-devel] cerowrt security

[Cerowrt-devel] cerowrt security

[Aristar]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

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.

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.

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

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"

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).

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.

[-- Attachment #2: Type: text/html, Size: 4173 bytes --]

Re: [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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] cerowrt security

[Aristar]

On Mon, Oct 21, 2013 at 9:59 PM, Dave Taht <dave.taht@bufferbloat.net> wrote:
>
> 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....

Hmm, interesting. So this is why using su -c to run a service as
another user has permission issues. I assume sudo -u still retains
some root privledges, which is why it works. (Ran into this issue when
configuring my IRC bouncer, Miau)

With such limited space on the flash, I understand the reasoning for
using squashfs. Not sure of any alternatives. Although there is the
possibility of chainloading a distribution off USB stick. There's a
debian-mips guide for doing that here: (
https://wiki.debian.org/InstallingDebianOn/D-Link/DIR-825 ) though the
complexity involved in doing something similar with openwrt/cerowrt
would be extensive.

> > DNSCrypt-proxy[...]
>
> I can make it available as an optional package in ceropackages. patches
> gladly accepted.

That would be great! I still can't figure out how to get the
imagebuilder or SDK working, but perhaps I'll give it another try
sometime. Openwrt is still a bit foreign to me since I used to work on
tomato-based forks. The wiki documentation on openwrt and cerowrt are
both very old and seem assume a certain level of prior-knowledge to
the inner workings of the distribution.

> > 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

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

I only mentioned the ones I saw that weren't enabled by default in
cerowrt, and this is not (on 3.7.5).


> > 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

> It makes me nervous to think my core dns server is going to hang
> off some dns address I can't remember either.

Yeah I was wondering if some random address might screw that up.


>> Symlink Protection:
>> fs.protected_hardlinks = 1
>> fs.protected_symlinks = 1
>
> 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.
>

Interesting read. Seems like a lot of those were samba and improper
file permissions (which a better filesystem than squashfs might help
solve?)

Re: [Cerowrt-devel] cerowrt security

[Maciej Soltysiak]

> 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 confirm it works as I'm running it on cero 3.8.something.
One comment. You are suggesting to use OpenDNS. Depending on level of
paranoia (which *IS* a virtue) the question whether they keep logs or
not might be an issue. They probably do and would give the data to NSA
gladly. There are 3 other DNSCrypt resolvers which claim not to keep
the logs. They are in Holland, Japan Australia. The last one is
endorsed by prism-break.org, but I have 500ms latency.

Therefore I have bought a VM at a cloud provider in my city and
deployed the same thing they are but 7ms away. DNSCrypt-wrapper with a
default config of unbound to provide recursive, DNSSEC validated NS.
So my humble setup is:

[home.lan] <-> [dnsmasq] <-> [dnscrypt-proxy] <-> [dnscrypt-wrapper]
<-> [recursive unbound]

dnsmaqs and dnscrypt-proxy are on Cero
dnscrypt-wrapper and unbound are controlled by me, sitting on a Debian VM.

Note this leaves home.lan clients still send regular UDP to Cero. Last
mile not protected. There are other ways to configure this, like do it
on the client, and put the wrapper on cero. In any case we should be
able to have both: dnscrypt-proxy and dnscrypt-wrapper. Both need
libsodium, which in turn needs libevent-dev.

If anyone wants to check out my dnscrypt provider, it's at
178.216..201.222:2053.
Connect using:
dnscrypt-proxy -a 127.0.0.1:2053
--provider-name=2.dnscrypt-cert.soltysiak.com -r 178.216.201.222:2053
\
  --provider-key=25C4:E188:2915:4697:8F9C:2BBD:B6A7:AFA4:01ED:A051:0508:5D53:03E7:1928:C066:8F21

Test by:
dig -p 2053 google.com 127.0.0.1

Best regards,
Maciej

Re: [Cerowrt-devel] cerowrt security

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Maciej Soltysiak <maciej@soltysiak.com> writes:

> Therefore I have bought a VM at a cloud provider in my city and
> deployed the same thing they are but 7ms away. DNSCrypt-wrapper with a
> default config of unbound to provide recursive, DNSSEC validated NS.

An alternative approach is to simply run a full BIND resolver with
DNSSEC validation on the cerowrt box. That is doable, with a bit of
configuration (notably adding the root key config file). The biggest
issue is one of time: when the router boots up it doesn't know the time,
and hence can't validate DNSSEC, making it unable to contact an NTP
server. A way to solve this is to get hold of a USB GPS receiver and use
that as a time source either on the cerowrt box itself, or on another
box that the router can reach when it boots up (and configure that in
/etc/hosts or simply input an IP into the NTP config). I suppose
configuring a known good NTP server by IP (or in /etc/hosts) would work
as well.

I use this setup (with a GPS on my home server) and it works quite well. :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt security

[Richard E. Brown]

On Oct 22, 2013, at 7:59 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> A way to solve this is to get hold of a USB GPS receiver and use
> that as a time source either on the cerowrt box itself,

Speaking of this, ESR made a foray into getting a company to produce such a USB GPS receiver. I never saw that it became commercially available. Have I missed it? Thanks.

Rich

Re: [Cerowrt-devel] cerowrt security

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 603 bytes --]

well, DeLorm and other map companies have had Serial/USB/Bluetooth GPS receivers 
available for a long time.

David Lang

probably not quite what you were thinking of, but funt

On Tue, 22 Oct 2013, Richard E. Brown wrote:

> On Oct 22, 2013, at 7:59 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> A way to solve this is to get hold of a USB GPS receiver and use
>> that as a time source either on the cerowrt box itself,
>
> Speaking of this, ESR made a foray into getting a company to produce such a USB GPS receiver. I never saw that it became commercially available. Have I missed it? Thanks.