Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

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"?

View on HN

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.

I'd agree - IPv6 is only going to get more important from now.

Yes, but while not inaccurate, I've heard this since 2000.

Google’s traffic is nearly 50% now: https://www.google.com/intl/en/ipv6/statistics.html

Are there any cell providers that don’t use native IPv6? Verizon definitely does. I’d be surprised if any big ones don’t.

Yeah, in an era when mobile device users are a pretty major customer segment, and they're essentially all native-v6, it's weird to dismiss it.

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.

* 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.

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.

[0] https://www.youtube.com/watch?v=QGbxCKAqNUE

At what cost?

Irrelevant. My point does not reference cost, or anything else but reality as it stands now.

In the UK we actually only have one provider that does - EE. They do native v6 and 464xlat for v4 connectivity where handsets support it.

Every other major provider is doing a horrible mess of IPv4 CGNAT with no native v6 still.

August 2024, "Zero-click Windows TCP/IP RCE impacts all systems with IPv6 enabled", https://www.bleepingcomputer.com/news/microsoft/zero-click-w...

> 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

If we stopped using things that had vulnerabilities, we'd be using sticks and stones by now.

Other operating systems weren't affected, so it's not inherent in the protocol itself.

Windows users with IPv6-blocking routers were protected from RCE.

Defense in depth is a viable approach if IPv6 features are not required.

Windows users with firewall-enabled routers were also protected from RCE.

https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.ht... is very worthwhile reading as a write on up this - it's nothing inherent in IPv6 and was a bug in Windows's packet processing of reassembled packets.

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.

Better disable IPv4 then, as there were zero-click vulnerabilities in Windows in that as well, e.g., CVE-2021-24074.

That’s dumb advice and makes me question anything else they’d recommend.

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.

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.

Consumer routers should be default deny so if you don't add any rules you're safe.

On the outbound?

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”.

Normal consumers have all outbound traffic open anyways.

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?

If you haven't updated your kernel since 1998, you may be vulnerable to the Ping of Death.

(I'm 90% sure this is the origin of this advice)

August 2024, https://news.ycombinator.com/item?id=41754925

That’s yet another Windows bug, not a problem with IPv6.

Windows users with IPv6-blocking routers were protected.

People who block ping should get swirlies

I'd rather swirl pings from the outside, from people who have no business at all to know about my internal infrastructures. Just GTFO.

If your internal infrastructure is not internet routable nobody would be able to ping it anyway

My comment wasn't about 'if's, but the thought of entitlement to mess around with other peoples stuff, or at least try 'look' at it.

That deserves to be flushed down the drain, or the kitchen sink.

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.

This site is about securing consumer level routers. Nobody using one of those has a network where the internal layout is valuable to a bad guy.

> 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.

RFC 4890 is a long read but the end result for home networks does have you block a handful of them.

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.

[1] https://en.wikipedia.org/wiki/Zero_trust_security_model

> 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.)

How much does disabling or filtering ping do to help, though? Won't they still saturate your downstream and put load on the firewall?

The downstream side may be relatively small and easy to saturate, but the upstream side is [typically] even smaller and easier to saturate.

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).

Don't let perfect be the enemy of good.

> 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.

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).

> But if your downlink to clogged, it probably won't matter that much that your uplink is clear.

And if your [small] uplink is clogged, it probably won't matter that much that your [large] downlink is clear.

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.

Thanks.

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.

> I do have to question disabling ICMP/ping

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.

That doesn’t get you anything. The bad guys assume every IP owned by an ISP has a customer router on 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.

> Ping is a tool I love, but it also allows a bad guy to discover your router with tracert.

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?

Reply on news.ycombinator.com