Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
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
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
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.
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
On Fri, Jan 25, 2019 at 7:59 AM Peter N. M. Hansteen 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
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
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.
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
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 : > > 4
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
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.