So I think this is mostly reasonable advice, but I do have to question disabling ICMP/ping and IPv6. I'm not aware of any actual attack that ping allows? And IPv6 should be fine if you have a firewall (which I would rather expect any regular COTS consumer router to have). The link on that suggestion describes a very specific problem where your router is also your WiFi AP and uses the old approach of just shoving the entire MAC address in to its v6 address, but am I wrong in thinking that it would be weird to see that actually happening in a new router, where new is "still getting security updates"?
I'd agree - IPv6 is only going to get more important from now. Especially with ISPs doing rollouts paired with moving v4 to address conserving mechanisms like CGNAT.
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.
> 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
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.
Customer segment? This is a thread about consumer edge routers.
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.
> Customer segment? This is a thread about consumer edge routers.
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.
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.
No, this is a thread about homelab and prosumer routers. No consumer
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.
>> You may just happen to be in a part of the Internet/world that got in early on the IPv4 address land rush
> 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.
I think the problem with ipv6 is that people may enable firewall rules on ipv4, but completely forget about v6. With auto configuration you may be leaving yourself wide open.
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”.
What router software makes it easy to enable the firewall for ipv4 but leave ipv6 completely open? Are these routers without a real firewall at all that just rely on NAT as a pseudo-firewall?
What do you think about black box/IoT/whatever hosts on your LAN pinging external hosts with unknown payloads while you're not using them?
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.
> What do you think about black box/IoT/whatever hosts on your LAN pinging external hosts with unknown payloads while you're not using them?
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.
1.) Carried out, that logic suggests not performing any outbound filtering because LAN hosts could simply find another way, protocol or port, out? I understand that 99.9% of LANs are configured default-allow LAN outbound. But the premise of your statement is untrue if the firewall is configured default-deny in all directions on all interfaces.
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.
How would somebody ping your internal network from the outside? Your firewall should block the ping getting past the router, regardless of the external interface responding.
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.
Network metadata is sometimes valuable all by itself. Investment firms buy satellite imagery to identify the number and models of cars in corporate parking lots, for better inferring internal business conditions. Frequency of pizza deliveries to the Pentagon revealed when major ops were taking place.
A private network will ideally present as an opaque black box to the outside.
> 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.
> I'm not aware of any actual attack that ping allows?
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.)
Believe it or not, blocking ping at your router would have done absolutely nothing to prevent this, as those packets would likely have still been delivered to the router and possibly saturated the link anyway, regardless of whether the recipient was dropping them or not. That is why nearly all DoS flood-style attacks are UDP-based — unless you are behind a CGNAT or an upstream restrictive firewall, you can't really opt out of those packets being routed to you.
Believe it or not, blocking pings at the router prevents said router from responding to pings, and this eliminates 50% of the problem on symmetric connections (and >50% on asymmetric connections).
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.
Yep, having been a recent victim, the cheap 'booter' services are still doing NTP & DNS reflection attacks. They're easy to do and require very few resources on the part of the attacker. Flooding a 1G service to the point of total uselessness is trivial and cheap.
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.
> Believe it or not, blocking pings at the router prevents said router from responding to pings, and this eliminates 50% of the problem on symmetric connections (and >50% on asymmetric connections).
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 that kind of thing might still work today for devices that respond to ICMP pings.
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.
I recently installed fiber (IPv4 only via this ISP, :/). The moment I connected OPNsense I got all kind of connections on the usual suspect ports. The whole IPv4 address space is scanned within an hour.
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.
Disabling IPv6 in 2024 is bad advice. IPv6 adoption is undeniably on the rise. Better advice would be to ensure that the IPv6 firewall is configured to sane defaults, i.e. allow established/related, drop invalid, reject unexpected, just like you'd expect an IPv4 firewall to be.
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.
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. ;)
Oh these are nice, I didn't realise they'd updated them with 2.5Gbit ports :)
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 :/
It's a worthy investment because it's not a retail throwaway item. Also, it comes with a business OPNsense license with 1 year of business updates. After that, it can either stay on that series, run the FOSS version, or one can purchase an S&S uplift later to get time period of additional business updates. Plus, the 2 10 GbE ports can do 10G switching more-or-less flat out (not necessarily over a WG or OpenVPN tunnel though). Until you get 20G internet for whatever reason, it's the last home/small business router you'll ever buy.
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?
The real main point is: how much control users of commercial routers could have with a reasonable effort (I mean, I know most are GNU/Linux machines, where the OEM sometimes respect the GPL providing the sources but there is no easy custom build and rom flash with very few exception like the little GL.iNet devices).
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.
I’m much more comfortable use something like opnsense. Router manufacturers seem to just yolo it judging by backdoors etc found frequently
> 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?
Yes. If the thing sitting on the external side of your network, exposed to the open internet, isn't getting security patches, then it's time to replace it with something that is.
If you've port scanned your public IP(s) and there are zero open ports, then you only have to worry about bugs in the TCP/IP stack, services listening on UDP, and intentional backdoors (which shouldn't happen but keep popping up). If there are exposed ports, then there's even more attack surface.
Edit: actually I forgot the like of UPnP so that's not exhaustive.
Directly no not to my knowledge. Seems like a bit of an esoteric layout to be honest.
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.
I get reducing your attack surface, but to what extent do modern devices still trust the network by default? Laptops and phones have to assume that the WiFi network is not under the control of the user. I guess printers etc assume they are in a trusted network?
It really is difficult to take this seriously when they suggest disabling IPv6. There are already quite a good number of ISPs that use CGNAT for IPv4, which often means that connections die or are intentionally killed in short amounts of time, which can be a huge PITA for certain uses (interactive shells, large downloads, et cetera).
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.
People incl home users have a lot of uses for e2e connectivity. But it's of course a self-fulfilling prophecy, when we make the internet more like TV ("receive only") the network effects curve down and people use less of it.
