Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

John Page
This is my first attempt at a router. Liberally borrowing from tutorials
and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD
Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
had previously been using an Asus RT-86U as both my router and wireless
access point. The apu4 can have wireless capability, but OpenBSD does
not support 802.11ac while the Asus does. So I decided to connect the
Asus to em3 of the apu4 so my wireless Windows 10 computers (both of
which have .ac) and Android phones could connect to the Asus instead of
the apu4 main router. Below is my stab at a network diagram (borrowed
and adapted) and the contents of my configuration files (again, borrowed
and adapted).

My question is: OK, I understand that people more knowledgeable than I
am say that  commercially available consumer-grade routers are not
secure. However, will I still have security risks associated with using
the Asus router when it is behind the OpenBSD/apu4 router?

Also, any suggestions or comments would be appreciated.

Thanks

John

apu4 router (running OpenBSD 6.4 -stable)

                                 ------------------------------→

                                     the internal interface

.-----------------.-----------.

|                 |   em3     | -→ Asus router -→ Windows 10 and

|   bridge0       | (no ip)   |    (RT-AC86U)     Android clients

|                 '-----------'

|                 |   em2     | static (fixed) via MAC address

'--------------.  | (no ip)   | -→ 192.168.1.3 OpenBSD only

|   vether0    |  '-----------'

|    dhcpd     |  |   em1     | static (fixed) via MAC address

| 192.168.1.1  |  | (no ip)   | -→ 192.168.1.2 OpenBSD only

'-------^------'--'-----------'

        |

        v

       em0

      dhcp

       ^

       |

Arris Surfboard SB8200

Cable Modem DOCSIS 3.1

(external interface)

       |

       v

   .-,( ),-.

 -(         )-.

(   Internet   )

 '-(       ).-'

  '--.( ).'

_/etc_/hostname.bridge0

add vether0

add em1

add em2

add em3

blocknonip vether0

blocknonip em1

blocknonip em2

blocknonip em3

up

_/etc_/hostname.vether0

inet 192.168.1.1 255.255.255.0 192.168.1.255

_/etc/dhcpd.conf_

option domain-names-servers 192.168.1.1;

subnet 192.168.1.0 netmask 255.255.255.0 {

option routers 192.168.1.1;

range 192.168.1.4 192.168.1.254;

host x1carbon {

fixed-address 192.168.1.2;

hardware ethernet xx:xx:xx:xx:xx:xx;

}

host optiplex790 {

fixed-address 192.168.1.3;

hardware ethernet xx:xx:xx:xx:xx:xx;

}

}

_/var/unbound/etc/unbound.conf_

server:

interface: 192.168.1.1

interface: 127.0.0.1

do-ip6: no

access-control: 192.168.1.0/24 allow

do-not-query-localhost: no

hide-identity: yes

hide-version: yes

forward-zone:

name: "."

forward-addr: 127.0.0.1@40

_/etc/rc.conf.local_

dhcpd_flags="vether0"

unbound_flags=""

dnscrypt_proxy

dnscrypt_proxy_flags="-l /_dev/_null -R dnscrypt.ca-1 -a 127.0.0.1:40"

sndiod_flags=NO

apmd_flags="-A"

_/etc/dhclient.conf_

ignore domain-name-servers

/etc/fstab (this is the only change from the default)

/dev/sd0a / ffs rw,noatime,softdep 1 1

_/etc/pf.conf_

int_if="{ vether0 em1 em2 em3 }"

broken="224.0.0.22 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 \

10.0.0.0/8 169.254.0.0/16 192.0.2.0/24 \

198.51.100.0/25, 203.0,113.0/24, \

169.254,0.0/16 0.0.0.0/8 240.0.0.0/4 255.255.255.255/32"

set block-policy drop

set loginterface egress

set skip on lo0

match in all scrub (no-df random-id max-mss 1440)

match out on egress inet from !(egress:network) to any nat-to (egress:0)


antispoof quick for (egress)

block in quick on egress from { $broken no-route urpf-failed } to any

block in quick inet6 all

block return out quick inet6 all

block return out quick log on egress proto { tcp udp } from any to any
port 53

block return out quick log on egress from any to { no-route $broken }

block in all

pass out quick inet keep state

pass in on $int_if inet

pass in on $int_if inet proto { tcp udp | from any to ! 192.168.1.1 port
53 rdr-to 192.168.1.1

pass in on egress inet proto tcp to (egress) port 222 rdr-to 192.168.1.2


pass in on egress inet proto tcp from any to (egress) port 2222
Reply | Threaded
Open this post in threaded view
|

Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

William Ahern-2
On Thu, Jan 24, 2019 at 04:55:50PM -0600, John Page wrote:

> This is my first attempt at a router. Liberally borrowing from tutorials
> and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD
> Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
> had previously been using an Asus RT-86U as both my router and wireless
> access point. The apu4 can have wireless capability, but OpenBSD does
> not support 802.11ac while the Asus does. So I decided to connect the
> Asus to em3 of the apu4 so my wireless Windows 10 computers (both of
> which have .ac) and Android phones could connect to the Asus instead of
> the apu4 main router. Below is my stab at a network diagram (borrowed
> and adapted) and the contents of my configuration files (again, borrowed
> and adapted).
>
> My question is: OK, I understand that people more knowledgeable than I
> am say that  commercially available consumer-grade routers are not
> secure. However, will I still have security risks associated with using
> the Asus router when it is behind the OpenBSD/apu4 router?
>
> Also, any suggestions or comments would be appreciated.

WiFi chip firmware is notoriously buggy and exploitable. I chose a Google
WiFi router (OnHub AC1900) specifically because it uses TPM-enforced secure
boot (like a Chromebook) so rootkits can't survive a reboot--at least
theoretically, but the track record is pretty good so far. And just as
importantly it automatically updates itself.

I don't trust Google not to spy on me, but I do trust them to earnestly keep
any wardriving competition at bay by regularly fixing issues and pushing
firmware updates. Secure boot and automatic updates means the WiFi security
is *reliable* (regardless of whatever that security means), and one less
thing to worry about.

Keeping the router in bridge mode and running your own DHCP and DNS
services, as you're doing, are obviously important. (Like you I have my WiFi
router bridged to an APU.) I'm not so cynical to believe Google would
implement DPI on their routers, but I find it hard to believe that they
could resist, always and forever, capturing DNS metrics.

If you're more paranoid than lazy you can setup IPSec tunnels from devices
to the gateway. It's ridiculously easy on OpenBSD using isakmpd (L2TP/IPSec)
or, especially, iked (IPSec/IKEv2 dynamic addressing). I've been using
L2TP/IPSec tunnels when traveling for many years, but haven't bothered at
home. IKEv2 dynamic address assignment does away with the need for L2TP
(npppd(8)), but I haven't cared to spend the time to reconfigure my existing
devices--desktop, personal/family laptops, work laptop, phone. Two caveats:
1) I don't know if it's possible to configure macOS or Windows (and almost
certainly not Android or iPhone) to automatically establish a tunnel on your
LAN but not elsewhere, so you'd have to remember to explicitly enable it
regularly; and 2) while I think macOS (and iPhone?) finally got solid IKEv2
support in the past couple of years, I think Android might still only
support IKEv1 and L2TP/IPSec VPNs.

Rant: Android and Linux people seem to be going crazy about Wireguard, but
Wireguard completely avoids the most difficult and complex aspect of running
VPNs--key management and routing. Of *course* Wireguard is clean and simple;
it avoids attempting to solve the dirty part, the most criticial part, the
part that cries out for automation. What you see are people throwing
together horrendous, ad hoc scripts for managing PKI and dynamic addressing
and routing issues which hopelessly poor imitations of IKE if perhaps a step
up from OpenVPN. Those hacks will only keep getting worse and more complex
over time, recapitulating all the same mistakes, whereas IKE has reached the
point where some of the complexity can be pared back. I won't be surprised
when an IKE extension is published for establishing dynamic Wireguard flows.
In the meantime there'll be (and already is!) a flood of proprietary,
incompatible policy management daemons, just like with SSL VPNs.

Next thing you know some big corporation will foist a TCP replacement upon
everybody because TCP is too old and hoary, and who doesn't want to run an
entire networking stack in each and every process that uses the network,
completely divorced from the entire stack of existing network management
(including non-invasive management) software and protocols. Also because of
security, except let's gratuitously toss in an easily abused, totally
insecure RTT feature to mitigate horrendous request latencies induced by the
very same [ad] company complaining about performance.

Reply | Threaded
Open this post in threaded view
|

Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

Florian Weber
Good morning

Why don’t you add https://www.pcengines.ch/wle200nx.htm

as your wifi card to your apu? It is supported by the athn driver and from experience, I know it works. This reduces your need for the bridge construct.




> Am 25.01.2019 um 04:54 schrieb William Ahern <[hidden email]>:
>
> 4
Reply | Threaded
Open this post in threaded view
|

Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

Peter Nicolai Mathias Hansteen
In reply to this post by John Page
On 1/24/19 11:55 PM, John Page wrote:

> This is my first attempt at a router. Liberally borrowing from tutorials
> and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD
> Firewalls,

The last title there predates PF, but if I remember correctly the
general discussion of firewalls and related network trickery is quite
good. Only do not copy the examples and expect to have them work without
extensive modification on any modern operating system.

> I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
> had previously been using an Asus RT-86U as both my router and wireless
> access point.

OpenBSD's newer-wifi protocol support unfortunately lags what is
available in various commercial products.

For that reason, in similar environments to what you describe I've tried
to get hold of APs with good radios and support for all the protocol
variants, then disabled all functionality on the access points
themselves other than the access point functionality, in some cases down
to even letting the things get the IP address for their Ethernet
interface from the OpenBSD dhcpd.

With 'dumb' access points little more than Ethernet interfaces
themselves, you get to control how things work from the sane OpenBSD
environment.

Examples closely matching this are in the tutorials and the book they
reference :)

- Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.


Reply | Threaded
Open this post in threaded view
|

Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

David Higgs
On Fri, Jan 25, 2019 at 7:59 AM Peter N. M. Hansteen <[hidden email]>
wrote:

> On 1/24/19 11:55 PM, John Page wrote:
>

> I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
> > had previously been using an Asus RT-86U as both my router and wireless
> > access point.
>
> OpenBSD's newer-wifi protocol support unfortunately lags what is
> available in various commercial products.
>
> For that reason, in similar environments to what you describe I've tried
> to get hold of APs with good radios and support for all the protocol
> variants, then disabled all functionality on the access points
> themselves other than the access point functionality, in some cases down
> to even letting the things get the IP address for their Ethernet
> interface from the OpenBSD dhcpd.
>
> With 'dumb' access points little more than Ethernet interfaces
> themselves, you get to control how things work from the sane OpenBSD
> environment.
>

I second this approach as working quite well, and is almost as easy to
manage as HostAP from within OpenBSD.  I have my commercial AP configured
to bridge each SSID/network onto a different VLAN.  My OpenBSD router can
then process each VLAN in a way appropriate to their purpose (family,
guests, streaming appliances, etc).

--david
Reply | Threaded
Open this post in threaded view
|

Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

Stefan Sperling-5
In reply to this post by Florian Weber
On Fri, Jan 25, 2019 at 08:14:43AM +0100, Florian Weber wrote:
> Good morning
>
> Why don’t you add https://www.pcengines.ch/wle200nx.htm

Our athn(4) driver is incomplete and only provides basic performance.
This driver still needs a lot of work to get it operating at full
capacity offered by ath9k devices. However, it runs without firmware and
support is expected to slowly improve over time. My own AP uses this device.

For now, a device supported by bwfm(4) is an option where 11ac performance
is required, such as https://wikidevi.com/wiki/Broadcom_BCM94350ZAE
These devices run closed-source firmware which contains an entire 802.11ac
stack. The OpenBSD driver can drive them in hostap mode so they will appear
as a regular wifi interface. All 802.11ac capabilities are enabled but
OpenBSD's ifconfig is not yet able to display or configure such capabilities.
This is being worked on.

This isn't a perfect solution either, but at least avoids much of the easy
attack surface of a standard wifi AP plastic box. E.g. there's no Web UI
that could be targeted. Firmware-level exploits are still a concern, but
that is true for any 802.11ac device. At least I am not aware of any
802.11ac devices which do not require closed-source firmware.

You will need an M.2-to-miniPCIe adapter board to fit a bwfm(4) card into
an APU, and you will need very very tiny pigtails to plug the antennas,
which are a pain to get plugged (took me an hour). But then it should work.

Reply | Threaded
Open this post in threaded view
|

Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?

Judah Kocher
In reply to this post by John Page
I was in the same position about 18 months ago when I reached the
conclusion that I didn't trust my RT-AC88U. I spent about a month
teaching myself iptables before learning about OpenBSD and PF and never
looked back. I have read and reread OpenBSD for Dummies and The Book of
PF multiple times, and spent many an hour on the OpenBSD website as well
as lurking on this mailing list filling in holes from outdated material.

I am using a mini PC from Qotom for my router and I took an old D-Link
router, set it to AP mode, disabled the DHCP server and connected it to
one NIC on it's own subnet as guest wifi. All traffic not heading to the
internet is blocked so guests never even see my network. {And thanks to
queuing, which I finally figured out, they have no idea how fast my
internet speed actually is :) } For the ASUS unit, like you I wasn't
willing to give up the wifi speeds so I set it to AP mode, disabled the
DHCP server, and am using dhcpd address reservation on the Router to
assign it an address that I block in the firewall.

Any devices connected to it have their own IPs that pass through just
fine, but traffic originating from the router itself gets nowhere. I did
a factory reset and flashed the latest Merlin Firmware when I made this
change and it has never been exposed to the internet since. Even if it
does get compromised somehow I believe this should keep it from phoning
home or otherwise causing meaningful harm.

The only "issue" is that I can't automatically update firmware. That
seems to me the lesser of evils. I check fairly regularly for updates
and can easily update it manually when required and I think this setup
also makes running older firmware a bit less of a liability.

Good luck!

Judah



On 1/24/19 5:55 PM, John Page wrote:

> This is my first attempt at a router. Liberally borrowing from tutorials
> and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD
> Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
> had previously been using an Asus RT-86U as both my router and wireless
> access point. The apu4 can have wireless capability, but OpenBSD does
> not support 802.11ac while the Asus does. So I decided to connect the
> Asus to em3 of the apu4 so my wireless Windows 10 computers (both of
> which have .ac) and Android phones could connect to the Asus instead of
> the apu4 main router. Below is my stab at a network diagram (borrowed
> and adapted) and the contents of my configuration files (again, borrowed
> and adapted).
>
> My question is: OK, I understand that people more knowledgeable than I
> am say that  commercially available consumer-grade routers are not
> secure. However, will I still have security risks associated with using
> the Asus router when it is behind the OpenBSD/apu4 router?
> Also, any suggestions or comments would be appreciated.
> Thanks
> John
> apu4 router (running OpenBSD 6.4 -stable)
>                                 ------------------------------→
>                                     the internal interface
> .-----------------.-----------.
> |                 |   em3     | -→ Asus router -→ Windows 10 and
> |   bridge0       | (no ip)   |    (RT-AC86U)     Android clients
> |                 '-----------'
> |                 |   em2     | static (fixed) via MAC address
>
> '--------------.  | (no ip)   | -→ 192.168.1.3 OpenBSD only
> |   vether0    |  '-----------'
> |    dhcpd     |  |   em1     | static (fixed) via MAC address
>
> | 192.168.1.1  |  | (no ip)   | -→ 192.168.1.2 OpenBSD only
> '-------^------'--'-----------'
>        |
>        v
>       em0
>      dhcp
>       ^
>       |
> Arris Surfboard SB8200
> Cable Modem DOCSIS 3.1
> (external interface)
>       |
>       v
>   .-,( ),-.
> -(         )-.
> (   Internet   )
> '-(       ).-'
>  '--.( ).'
> _/etc_/hostname.bridge0
> add vether0
> add em1
> add em2
> add em3
> blocknonip vether0
> blocknonip em1
> blocknonip em2
> blocknonip em3
> up
> _/etc_/hostname.vether0
> inet 192.168.1.1 255.255.255.0 192.168.1.255
> _/etc/dhcpd.conf_
> option domain-names-servers 192.168.1.1;
> subnet 192.168.1.0 netmask 255.255.255.0 {
> option routers 192.168.1.1;
> range 192.168.1.4 192.168.1.254;
> host x1carbon {
> fixed-address 192.168.1.2;
> hardware ethernet xx:xx:xx:xx:xx:xx;
> }
> host optiplex790 {
> fixed-address 192.168.1.3;
> hardware ethernet xx:xx:xx:xx:xx:xx;
> }
> }
> _/var/unbound/etc/unbound.conf_
> server:
> interface: 192.168.1.1
> interface: 127.0.0.1
> do-ip6: no
> access-control: 192.168.1.0/24 allow
> do-not-query-localhost: no
> hide-identity: yes
> hide-version: yes
> forward-zone:
> name: "."
> forward-addr: 127.0.0.1@40
> _/etc/rc.conf.local_
> dhcpd_flags="vether0"
> unbound_flags=""
> dnscrypt_proxy
> dnscrypt_proxy_flags="-l /_dev/_null -R dnscrypt.ca-1 -a 127.0.0.1:40"
> sndiod_flags=NO
> apmd_flags="-A"
> _/etc/dhclient.conf_
> ignore domain-name-servers
> /etc/fstab (this is the only change from the default)
>
> /dev/sd0a / ffs rw,noatime,softdep 1 1
> _/etc/pf.conf_
> int_if="{ vether0 em1 em2 em3 }"
> broken="224.0.0.22 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 \
> 10.0.0.0/8 169.254.0.0/16 192.0.2.0/24 \
> 198.51.100.0/25, 203.0,113.0/24, \
> 169.254,0.0/16 0.0.0.0/8 240.0.0.0/4 255.255.255.255/32"
> set block-policy drop
> set loginterface egress
> set skip on lo0
> match in all scrub (no-df random-id max-mss 1440)
> match out on egress inet from !(egress:network) to any nat-to (egress:0)
>
>
> antispoof quick for (egress)
> block in quick on egress from { $broken no-route urpf-failed } to any
> block in quick inet6 all
> block return out quick inet6 all
> block return out quick log on egress proto { tcp udp } from any to any
> port 53
> block return out quick log on egress from any to { no-route $broken }
> block in all
> pass out quick inet keep state
> pass in on $int_if inet
> pass in on $int_if inet proto { tcp udp | from any to ! 192.168.1.1 port
> 53 rdr-to 192.168.1.1
> pass in on egress inet proto tcp to (egress) port 222 rdr-to 192.168.1.2
>
>
> pass in on egress inet proto tcp from any to (egress) port 2222