Hacker News Reader

Comment by nicce | Hacker News Reader

You can technically send then all the time and it is enough that they boot once. No need to know the time beforehand.

The worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).

What we _can_ do, though, while the OS is running is detecting that bogus large ICMP packets are sent continuously. At least, this would be early warning that a reboot may be risky without disabling PXE.

If you want to filter this, you should probably do that at the network level, not the host level. Ideally at switches, otherwise with firewalls.

I mean yeah, but who is letting unfiltered ICMP onto a production network?

What filters do you recommend? ICMP is pretty important and many networks have been broken by setting the wrong filters.

most firewalls limit ICMP across their boundaries, hence why ping doesn't work for a lot of places from the outside in.

This exploit is a unicast packet, which is unsolicited. For NAT, you probably don't need to do much. for ipv6 you'll need to make sure that your firewall doesn't blindly pass on ICMP ie make sure its a stateful firewall.

At least some enterprise IDS /AFW could presumably have a signature configured for this traffic scenario.

Before you manually configure a rule in your WAF you might as well just fix the vulnerability in the vulnerable component directly ^^

especially in free/open source software like edk2

Reply on news.ycombinator.com