Router Security
routersecurity.org
routersecurity.org
That deserves to be flushed down the drain, or the kitchen sink.
That said: Who cares? Even if you published exact list of every single IP on your network, it doesn't do an attacker any good, because again, there's a firewall between them and your devices.
A private network will ideally present as an opaque black box to the outside.
Good luck (trying to) scanning a IPv6 /64 subnet.
I've been in IT for 20+ years, and I have yet to find a situation where blocking ICMP(v6) caused more benefits than problems.
Ditto for my home network: my last ISP had IPv6, and I had an Asus router which blocked unsolicited incoming connections: I could not SSH to any of my Macs from the outside (by default), but could ping if I knew the address (but good luck guessing 2^64).
If you want to try to enumerate the equivalent of 4.3 billion IPv4 Internets that is a single IPv6 subnet, have fun.
Best security practice is obviously to block any/all ping not intentionally sent by you, whoever the local network admin is, or otherwise only whoever or whatever is explicitly allowed to.
I think that 1. they can connect out via TCP or UDP much more easily than ICMP, 2. that blanket blocking outbound connections is a short path to madness, 3. if you don't trust a device on your LAN you should unplug it or isolate it, both of which are more effective and less disruptive, and 4. depriving yourself of the most fundamental network diagnostic tool in the name of security is cutting off your nose to spite your face.
2.) I've not suggested 'blanket blocks' (nor 'blanket allows' for that matter). Specifically, both ingress and egress ICMP should be filtered by type code.
3.) In a zero trust model[1], every LAN device is untrusted. One should perform as much isolation and filtering as possible at all the relevant network layers. Network security is "disruptive" by definition.
4.) The second paragraph of my comment suggested that ping should be explicitly allowed for anyone/any device on the LAN legitimately utilizing it.
(I'm 90% sure this is the origin of this advice)
The short list looks pretty sensible to me with those two exceptions. The long list gets a bit paranoid for me at the end - especially 32 onwards or so.
Yes, but while not inaccurate, I've heard this since 2000.
Are there any cell providers that don’t use native IPv6? Verizon definitely does. I’d be surprised if any big ones don’t.
That is, individual people, not corporate connectivity. "Customer segment" is a meaningless term here, Grandma doesn't care about customers.
A lot of this is regional, sadly. No mobile phone provider in Canada/US would not allocate ipv4 access. It'd be madness. Too many unreachable endpoints.
In fact, no endpoint anywhere in US/Canada can get by without ipv4, but many don't care about ipv6.
There will be a point where that changes, but certainly not yet.
So why does Grandma care if her router can do ipv6?
All major companies world wide, all consumer end points world wide support ipv4.
And in US/Canada, everyone does ipv4 unless they are on some political campaign against it. And it will hurt them.
No, this is a thread about homelab and prosumer routers. No consumer—not Grandma, not mom, not Aunt Alice—is adjusting or checking or modifying their settings.
This is evidenced by:
> 6. Turn off UPnP
Really? Do you know how many things that will break for the average consumer?
> So why does Grandma care if her router can do ipv6?
Does Grandma care about UPnP and/or PCP? She's probably has never heard of them, but she should care about them if she wants certain apps to work.
And if Grandma happens to use an ISP that didn't get in early on the IPv4 land rush (or doesn't have the cash to buy individual IPv4 addresses for all their customers) then she certainly should care if her router can do IPv6 (or rather someone should care on her behalf):
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
> First off I despise both Apple and that other evil empire (house of mouse) I want nothing to do with either of them. Now with that said I am one of four individuals that suggested and lobbied 15 other [American Indian] tribal nations to offer a new AppleTV device in exchange for active ROKU devices. Other nations are facing the same dilemma. Spend an exorbitant amount of money to support a small amount of antiquated devices or replace the problem devices at fraction of the cost.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion, "Roku devices don't support IPv6 in 2023 and it's costing ISPs": https://news.ycombinator.com/item?id=35047624
You may just happen to be in a part of the Internet/world that got in early on the IPv4 address land rush, and/or can afford to throw money at the problem to buy individual addresses for each of their customers: not everyone is so fortunate.
These are still consumer endpoints. And:
You may just happen to be in a part of the Internet/world that got in early on the IPv4 address land rush
Yes, that's precisely what I was discussing. Everyone in the regions I discussed can access ipv4, period. All domestic businesses do ipv4. All businesses worldwide which want access to these markets do too.
I'm not interested in ipv6 advocacy, but facts. And my statements stand.
> Everyone in the regions I discussed can access ipv4, period. All domestic businesses do ipv4. All businesses worldwide which want access to these markets do too.
At what cost?
Accessing IPv4 cost that Native American tribe a lot of money because one particular manufacturer couldn't be bother to support IPv6.
It would cost (e.g.) T-Mobile US [0] a lot of money, which would be passed on the public, to give people an IPv4 address on their handset (even using 100.64/10) and then run hardware to do CG-NAT for everyone.
Irrelevant. My point does not reference cost, or anything else but reality as it stands now.
Every other major provider is doing a horrible mess of IPv4 CGNAT with no native v6 still.
> the bug in TCP/IP that would allow a remote, unauthenticated attacker to get elevated code execution just by sending specially crafted IPv6 packets to an affected target .. That means it's wormable
Other operating systems weren't affected, so it's not inherent in the protocol itself.
Defense in depth is a viable approach if IPv6 features are not required.
I'm not convinced it would be particularly exploitable with a firewall between the system and the rest of the internet blocking unsolicited incoming traffic -which is what most consumer routers etc are doing for IPv6.
By all means enable ipv4 and v6 but remember to ensure you firewall both.
My IoT network has a very controlled list of allowed outbound targets in the ipv4 world. If I blindly enabled IPv6 I’d have to ensure I protected against that too.
Of course I also do things like intercept UDP/53 and nat it to my pihole as some devices have hardcoded dns servers, which many purists claim is an “ugly hack”.
Ping is a tool I love, but it also allows a bad guy to discover your router with tracert. Disabling icmp/ping responses prevents that.
This doesn't hold up for IPv6 though. This address space is so large, you can run SSH server on it without it ever getting scanned.
And?
So some random IP, which is already known to be in the range of a residential ISP (because of ARIN/RIPE/ASN records), is pingable. So what?
A ship is safe in harbor, but that’s not what a ship is for. If a router can’t handle IPv6 in 2024, throw it out the window.
DoS.
There may have been a time once, when some of us may have been minors, that using a command like "ping -f -s 1000" from a well-connected host to a specific dialup user's IP address may have been able to completely obliterate their connection to the point that it would fuck up their network stack enough to reliably disconnect their PPP session and send them back into redialing the local ISP's busy modem pool.
Maybe.
And that kind of thing might still work today for devices that respond to ICMP pings. (I'm no longer an angsty teenager so I wouldn't know, but angsty teenagers are still things that get made in factories every day.)
Don't let perfect be the enemy of good.
Better: Don't base your decisions on imaginary scenarios that haven't been relevant for decades.
There's no "good" in blocking ICMP packets and especially ping. You won't protect yourself from DDoS attacks but you might summon some obscure, hard to diagnose networking issues.
If you gave me your IP and your consent, I could rent a DDoS-for-hire service for lunch money and take you offline. They don't rely on their victims taking themselves offline with response packets.
Sadly there's absolutely nothing you can do on your own firewall/router to block or mitigate them - your connection's downstream just gets flooded with UDP packets and becomes totally useless. The only mitigations/blocking can be done by your ISP and their connectivity partners.
But if your downlink to clogged, it probably won't matter that much that your uplink is clear.
I've self-DoSed when 'downloading Linux ISOs' because the downlink was 100% saturated and I couldn't do much anything else because the ACKs for TCP packets couldn't get down easily (this was for something as basic as SSH sessions that suddenly got laggy when typing). I had to tell the software in question to only use ~90% of my downlink speed (DSL at the time).
And if your [small] uplink is clogged, it probably won't matter that much that your [large] downlink is clear.
Not so much any more aside from your example of saturating a really tiny link. Most routers are either based on Linux or BSD and ICMP is rate limited using a few knobs and masks icmp_ratelimit, icmp_msgs_per_sec, icmp_msgs_burst based on icmp_ratemask. Enterprise routers have even more rate limiting that factor in back plane CPU load and other vendor specific controls. Enterprise routers will appear to stop responding or appear to have packet loss but they are just silently dropping ICMP when the rate is over their set thresholds as defined by the vendor defaults or by the network administrator.
Give it a shot some time on Linux or BSD. Install iftop to watch network usage and htop or btop to watch CPU usage and flood yourself with one of the ping tools fping, hping3, nping, blitzping, etc... Ideally blizping but you may have to compile it. Just for fun start loosening the sysctl restrictions on ICMP rate limits and find the spot where your CPU load is undesirable to the point where applications lag.
On the topic of security it is a good idea to block ICMP redirects unless one knows they need it. Or conversely a more restricted approach would be to allow Echo Request, Echo Reply and maybe Destination Unreachable outbound for pmtu discovery. Address Mask Request/Reply can be considered information disclosure to some organizations. It is also a good practice to disable responding to ICMP broadcasts in the OS via sysctl unless you know you need it.
That's the only reply I got to my missive that sought to educate, and it did so with logic and reason that is actually logical and reasonable.
I will take some time exploring these things (on my own connection, at home) some sleepy day in January when I'm snowed in.
Disabling ICMP is also bad advice. If you want Path MTU discovery to work, you need ICMP. If you want to be told about TTL exceeded (which usually shows a routing loop), you need ICMP. If you are uniquely worried about ping for some reason, then block those ICMP type numbers specifically, not the entire protocol.
Here's one option:
https://shop.opnsense.com/product/dec740-opnsense-desktop-se...
1. Suggesting turning off IPv6 is ridiculous security theater. It's a known quantity deployed at scale. Dual stack or turn in your "hacker cred" card now. ;)
gulp
[0] - https://www.openbsd.org/octeon.html
[1] - https://kernelpanic.life/hardware/openbsd-router-benchmarks....
OPNsense is based on FreeBSD, runs on $100 micro PCs with PCIe quad NIC, https://www.servethehome.com/introducing-project-tinyminimic...
For something a bit more affordable, the Turris Omnia or Mox are nice options too - https://www.turris.com/
I'm not the biggest fan of OpenWRT et al (or pfSense/OPNsense, for that matter), but they're reasonably friendly for a technical user.
Personally, I still really like a small, low power x86 box running normal Linux as a firewall & router. Sadly the options are either very expensive or from questionable sources (eg aliexpress x86 low power machines are common). I miss PC Engines - https://www.pcengines.ch/eol.htm :/
Looking at https://routersecurity.org/othersgripeonrouters.php some 2019 article headline says "the worst is yet to come."
Virtually all routers do not have an admin interface exposed on Internet facing side, moreso due to CGNAT. What threats from routers are we seeing in the wild that are actually having an impact?
If the router is just a person mini-computer with some *nix OS and it's config, directly tied to a media converter from the ISP it's a thing, otherwise it's essentially next to impossible doing most of reasonable actions including properly probing the internet-side for a small potatoes audit.
Some countries have mandatory free router choice, like Italy (curiously), where at least the user is allowed by law to run it's own router so ISPs are obliged to give all settings, VoIP included, without making like of their customers needlessly harder, but that's not true in most countries. Some ISPs (i.e. Orange France) run arbitrary custom solution to makes people life harder if their put another router behind the ISP provided one. People choice is very limited even for those who would know and want to run their own home/SOHO LAN.
> At some point you will go a year or two, or more, without any updates. That's when it is time for a new router.
Is that good advice? Swapping a mature and patched platform for whatever device with new A.I. enabled half test beta firmware that just got rushed to market?
Non-updated LAN device making outbound connections puts the entire LAN at risk…
Edit: actually I forgot the like of UPnP so that's not exhaustive.
If you really want you could probably do it with two sets of interfaces but you'd still need an external device for wireguard. So same opnsense instance takes lan traffic and sends it to WG device, WG device sends it back to opnsense on a second set of interfaces and that goes out like a normal FW setup.
That way have opnsense both as perimeter device, and also benefitting from it as a LAN mgmt (DHCP etc).
To stick it all on one device you'd need virtualization I suspect. Can be done but wouldn't recommend.
VLAN for insecure IoT devices is a fallback.
Take Starlink for instance. When on IPv4, you really feel like you're on a janky network that's being rebooted every hour or two. After Starlink enabled IPv6, all sorts of things no longer required babysitting and restarting. The quality difference between IPv4 via CGNAT and native IPv6 is huge and noticeable, even for people who have no idea what's going on behind the scenes.
Perhaps regular people can naively suggest turning off IPv6 because they don't know any better and they believe the FUD they've heard and read about, but if you're putting up a web site claiming to have good advice and you put more weight on FUD over real world experience and solid reasoning, then I'd be suspicious about everything they've written.
Add "disable IPv4" too.
Some ISPs, and routers, don't even process it correctly
To avoid headaches, and extra work, disable ipv6