Router Security
routersecurity.org
routersecurity.org
Also articles on the page fail to show any practical implications and what does happen instead on what can happen. Don't get me wrong having your router used for DDoS and C2 is not great but it has 0 practical implications for you. The summaries on the page also omit that most of the nasty sounding issues are directly mitigated by using HTTPS.
Delivering malware will have an affect but none of these articles actually mention such cases (other than it can be done) and how prevalent this is compared to other malware delivery methods. I'd say it is safe to assume it isn't.
Also notice most of the recommendations have nothing to do with the these threats. That can be summed up to update your router and change password.
That said, I'd be skeptical and want to see real data if this guy is claiming your router is more likely to be infected and become part of a botnet than your other networked devices.
That said, it would be nice if router security wasn't absolute shit and those devs actually gave two shits about it, but I could say that about so many things.
My choices are the RT-AC86U, and the RT-AX68U if you need Wifi 6 support.
Don’t get the RT-AC88U though, it has no CAKE.
(If you’re lucky enough to have a gigabit connection, you’ll need more expensive stuff.)
They do provide access to the sources, but isn't this still a violation of GPL?
> That's because millions of home gateway routers, especially those leased to customers by their internet service providers (ISPs), leak their unique hardware ID numbers through their Internet Protocol (IP) addresses — and those hardware ID numbers can be connected to publicly available maps that show the street locations of Wi-Fi networks.
It's based on this talk apparently
> We assume a weak adversary who is remote to the target and has no privileged access. Our privacy attack lies in IPv6 addresses formed via EUI-64, which embed the interface's hardware MAC address in the IPv6 address. While EUI-64 IPv6 addresses are no longer used by most operating systems, they are commonly found in legacy and low-profit-margin customer premises equipment (CPE), e.g., commodity routers connecting residential and business subscribers. Because IPv6 CPE are routed hops (as opposed to IPv4 NATs), we can discover their MAC address via traceroute if they use EUI-64.
> These CPE are frequently all-in-one devices that also provide Wi-Fi. Crucially, the MAC address of the Wi-Fi interface is often related to the MAC address of the wide area interface, e.g., a +/-1 offset. These Wi-Fi MACs are broadcast (the 802.11 BSSID) and captured by wardriving databases that also record their physical location. By correlating the MAC addresses embedded in IPv6 home router addresses with their Wi-Fi address counterpart, we can remotely geolocate them, fusing virtual data with meatspace.
They have a tool that lets you check a given IPv6 address: https://github.com/6int/IPvSeeYou
That said, it's absolutely toxic to be telling people to just turn off IPv6. Completely makes me lose trust in the rest of the site's content.
> For years, turning off IPv6 (IP version 6) was on the long list below, but as of August 2021, I think it belongs here on the short list too. Very very few people need it and it was recently disclosed that there is a possible security issue with it.
I think you're being a bit too accusative. Every suggestion has sources to back it up if you want to see why something is recommended.
I am not sure to understand, while this is in theory doable, do these "captured by wardriving" databases exist?
And do they cover "everywhere"?
So my bet is, yeah, they do exist and they do pretty much cover everywhere.
[0]: https://www.theguardian.com/technology/2010/may/15/google-ad...
Though I believe that if Google is the adversary, they have ways (only a guess, but some kind of correlation between GPS location on mobile while connected to Wi-Fi and http requests could be one) that make the "wardriving database" unneeded, I mean, there should be a constant updating of this database, or it would turn out pretty much obsolete soon.
[1]: https://developers.google.com/maps/documentation/geolocation...
There are both open and proprietary versions.
I think early iPhones used it (with cell site data too), before they had GPS. Can’t remember their name for it.
But, all big populated areas are mapped and understood.
See Hybrid Positioning too, which is combining all available data, including Wi-Fi, to aid in rapid and accurate location information: https://en.m.wikipedia.org/wiki/Hybrid_positioning_system
Which brings the following issues:
- No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router. The router will ping both routes, and if the fast one is working, using it as main gateway. When it doesn't answer anymore, the router simply change its route. Because of NAT, this is transparent to the devices behind its network. For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix. The "solution" is to have your own address space, and use BGP to change the routes (which is out of reach for all of private consumers).
- ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN). The problem is that SLAAC only works with /64, below the devices usually won't assign themselves an IP anymore. So you can only have one network, you can't have a Guest network with a different prefix.
- As mentioned by the article, the design is terrible for privacy: SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address. EDIT: This is wrong. See throw0101a answer below.
- Captive portals: SLAAC does not directly support assigning DNS servers. So most captive portals simply break because the network's firewall blocks DNS requests as long as they don't use the proper DNS server, but the device might simply not even be able to receive it. (SLAAC has an extension where it can tell the device to receive the DNS servers from DHCPv6, but many devices simply ignore it and treat DNS like browsers do with DoH). EDIT: This is wrong. See throw0101a answer below.
- Security within networks: Because the responsibilities of who assigns IP is shifted to the devices, switches cannot prevent devices to assign themselves IP anymore. So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down.
Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT, so some applications took the liberty to assume that their local IP would always be the same visible on the internet. Not sure if that's this particular case for SIP, but it's usually broken with NAT6.
One example is Apple's APNS and Android's GCM. In IPv4 multiwan network, after the change they won't receive notifications at all for up to 30 minutes. In IPv6, the router can invalidate the old prefix, and publish a new one immediately.
Also, I'm personally not aware of any reliable way of invalidating IPV6 prefixes except waiting for the timeout. (And if it's republishing a RA, devices don't have to listen to it, and the packet might even be lost with an unreliable wifi for example). If I'm wrong here, I'd love to know about it.
In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit and reliable signaling
of that condition (such as when a Customer Edge router crashes and
reboots without knowledge of the previously employed prefixes), hosts
on the local network may continue using stale prefixes for an
unacceptably long time (on the order of several days), thus resulting
in connectivity problems. This document describes this issue and
discusses operational workarounds that may help to improve network
robustness. Additionally, it highlights areas where further work may
be needed.
Is multi-WAN without a static IPv6 assignment common? For home users, generally you get one assignment. If you do need this, then you can use IPv6 ULA internally and NPTv6 for prefix translation. You can still get mostly end-to-end connectivity because the external-internal is stateless. See "IPv6 Multihoming without Network Address Translation:
* https://datatracker.ietf.org/doc/html/rfc7157
> SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address.
Except that this hasn't been how its worked on most OSes by default for several years; see "Temporary addresses", "Cryptographically generated addresses", and "Stable privacy addresses":
* https://en.wikipedia.org/wiki/IPv6_address#Stateless_address...
> - Captive portals: SLAAC does not directly support assigning DNS servers.
For SLAAC to work you need Router Advertisements (RAs), and and with-in those you can put DNS servers (and have since 2010):
* https://datatracker.ietf.org/doc/html/rfc6106
> So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down.
And the same thing can be done with in the IPv4 world by trying to overflow a switch's ARP table. I think switch manufacturers have figured that out.
> Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT
Except that NAT re-writes both the IP and port and thus you have to use state tracking for replies and port mapping with IPv4 NAT. Whereas NPTv6 is stateless:
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Prefix Translation (NPTv6) function that provides the
address-independence benefit associated with IPv4-to-IPv4 NAT
(NAPT44) and provides a 1:1 relationship between addresses in the
"inside" and "outside" prefixes, preserving end-to-end reachability
at the network layer.
So you can send a message to a packet to a public IP:port combo and it will be mapped to an internal IP:port without much fuss since only the first /64 needs to be re-written. Of course only if your router/firewall is configured to allow new connections, which most consumer CPEs are not by default: they only allow replies to previous outgoing connections.
IMHO, most of the problems you describe haven't been a problem for years.
Not really though, because in Ipv4, a DHCP server can be authoritative, and switches can ignore IPs which are not assigned by the DHCP server. That's how it's usually figured out for Ipv4.
> Except that NAT re-writes both the IP and port and thus you have to use state tracking for replies and port mapping with IPv4 NAT. Whereas NPTv6 is stateless.
Yes, I didn't meant to state anything contrarily to that, but you still break applications which assumes that the local IP is the same than what is visible from a remote server on the internet.
For the captive portals, I stand corrected, and wasn't aware that you can now embed DNS directly in RAs, but stayed with the original implementation which delegates the DNS part to DHCP.
I probably have an outdated understanding of Ipv6, but to be fair it's quite a challenging exactly because of all the amendments that you linked. These are only some of the problems I encountered personally, and as you showed, each individual problem has a different RFC to solve it. You never know how stable they are and if they are properly implemented. And most of the time the safe default is to only work with the initial standard.
Yes, it’s incredibly common in the small business/retail/food/shop business with fibre primary and cellular backup. These places don’t have the budget for BGP, but can afford an extra €$£20-50/month for a backup cellular circuit. They don’t need static IPs, they just need working outbound internet access. And they want failover to occur within a few seconds, not 30s or 2-3mins.
Pretty sure all reasonable devices utilise privacy extensions.
> ISPs got it wrong ! I'm in Germany, tried 3 different providers, they all assign to my router a /64 subnet instead of /60 or /56 (as recommended by ARIN).
If it's wrong is subjective. If it's not a goal to upsell a business connection there might be technical limitations.
> No support for multi-homing. Example: You have two connections, a slow reliable one, and a fast unreliable one. With IPv4 you can easily setup multiwan in any proper L3 router.
Bit of a niche use-case and still very doable with NAT66.
> Captive portals: SLAAC does not directly support assigning DNS servers.
I haven't seen a captive portal that wasn't able to intercept DNS or that couldn't MITM all connections to display that page. It's a non-issue.
> So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64
IPv4 devices can conduct ARP spoofing, no biggie. If it's "very easy" to do either it's just poor switch software.
I stand corrected by throw0101a answer. This is actually not an issue
> If it's wrong is subjective. If it's not a goal to upsell a business connection there might be technical limitations.
I don't think a Guest network should be considered a business feature
> Bit of a niche use-case and still very doable with NAT66.
Yes or NPT, as I mentioned at the end of my initial answer. But it has its own con.
> I haven't seen a captive portal that wasn't able to intercept DNS or that couldn't MITM all connections to display that page. It's a non-issue.
I also stand corrected by throw0101a, this is a non-issue.
> IPv4 devices can conduct ARP spoofing, no biggie. If it's "very easy" to do either it's just poor switch software.
The actual "switch software" in IPv4 which handles that, is to use an authoritative DHCP server. This does not exist/work in IPv6.
Well obviously, but a proper switch, instead of DHCP snooping, has SLAAC and DHCPv6 snooping.
SLAAC-snooping protects against ARP poisonning, not against ARP table overflow.
It's not really that there's no support. It's more that the support isn't very good.
In theory, you send router advertisements, with priorities for all your routes, and when a connection drops, you stop sending that route's advertisements or start sending announcements showing that prefix is now didabled. And all the clients would do useful things with it.
But of course, they don't. They'll use an address from Prefix A and send it through router B. Or prefer the first announcement they see rather than the most preferred route. And that's assuming you can convince your CPE to set the preferrences you want.
By default Linux assigns a link-local ipv6 address to each interface, this can be undesirable
In that scenario, DHCPv6 would be responsible for keeping the assigned subnet filled randomly, rather than being conservative and consistent with address assignments. I don't know if anyone is doing it now, but I don't think we should dismiss IPv6 for this reason.
No, they do not lack knowledge. See the sibling comments: the issue is not a concern of what various computer and mobile OSes do, but rather with some CPE firmware still using EUI-64-based IPv6 addresses.
This allows attackers on the Internet to send out probes, find the router's Wifi interface, map it to the BSSID/SSID, and look up the SSID in geolocation database:
* https://www.blackhat.com/us-21/briefings/schedule/#ipvseeyou...
Ideally what they should be doing is contacting vendors to fix their firmware (and also creating CVEs for 'public shaming'), and not telling people to disable IPv6.
Disabling IPv6 does not solve the problem: it is still lurking there for folks that haven't read this site/advice.
Routers will hardly ever make connections themselves out to the internet, except maybe for things like DNS which hopefully are using major providers like Google which won’t leak the data anyway.
The attacker sends a ping to any random address in the /64. The router responds with an ICMP of "timeout" or "unreachable" or something. The ICMP response has the router's IPv6 address.
In badly written routers they use EUI-64 for the local-part of addresses. Further, most devices have interfaces where the MACs are sequential: so if the first interface has 2a:a9:d3:8f:c9:a8, then the next one probably has …:a9, and then :aa, etc.
Then the EUIs-64 and look them up in a Wifi geolocation database:
So it’s both having the EUI-64 address and the router responding with an ICMP message rather than being silent. Got it.
- 1x VLAN capable managed switch
- 1x any Linux capable SBC with 1x gbit ehternet port
- any systemd based Linux distro (I like Arch Linux ARM for this purpose)
Pretty much all the networking aside from firewall, and wifi setup can be configured via systemd-networkd/resolved these days.
Once you have your installation and setup done, if your HW gives you trouble you can always replace it with anything else you have at hand.
It's very flexible, and you can do a lot of things a typical router GUI would never allow you. It's great if you want to explore Linux networking. HW is cheap, low-power, doesn't need to be a "router" HW with multiple ports, and if anything happens you know you can replace the broken router with pretty much anything that has an ethernet port and can run a Linux distro.
I’ve always been concerned (probably irrationally), that it seems to halve WAN bandwidth (since all traffic has to travel both in and out of the router over the same cable). Do you find this is an issue?
I've noticed some new routers (e.g. the Eero from our ISP) can only be controlled via an app. Does that mean they can be controlled remotely?
Probably.
On top of this a lot of routers will use TR-069 that allows for remote management of your router by your ISP. So even without a app its likely it can be controlled remotely.
It's worth understanding the whys of the tradeoffs for these types of enterprise WAPs that are remote-management only. They're often installed in more or less public places like airport lobbies, hotel hallways, stadiums. The ability to gain physical access is trivial and you really don't want anyone who can get physical access to be able to configure the device. Even in corporate settings, you don't want an employee who can get access to a device to be able to configure it, either. So having remote-only management, protected by all of the usual account provisioning that would protect any other critical service, makes a lot of sense.
Does it make sense in the home? That depends. This guy, and probably a lot of consumers, really distrust any and all vendors, Ubiquiti included. But do you trust everyone in your home? I had a houseguest almost all of last summer. My wife's friend needed a place to stay after leaving his wife for a few months. I barely know the guy. I have Aruba WAPs, not Ubiquiti, but same idea. They can only be configured via an account-based mobile management app. This meant I could force his devices onto guest WiFi and there was no way for him to get around, even though he was in my house and could plug an ethernet cable into the WAPs if he wanted to. Do you trust all of your kids' friends or house party guests? More or less than the people who develop the mobile management app for your enterprise networking products?
Also, if your phone is trying to connect to your 'Bob's Hotspot' say, but you have it turned off, and someone else (er, Alice, why not) notices this and starts broadcasting 'Bob's Hotspot', does the phone send the passphrase, to Alice (who doesn't know it a priori), or is there some kind of certificate verification that it's the expected seen-before router, that fails in this case so the passphrase isn't sent?
I would trust OpenWrt more, especially their continued support for old devices, one accesspoint of mine is 11 years old, supported in the 2022 release and still going strong (128MB RAM, 32MB flash)
I have only one device that requires WPS (a wifi-only printer), but there is no other way to get it onto a wifi network.