How To Block Cloud-Metadata Requests With BetterShield?

With BetterShield, on from the start: refuse requests plugins send to the addresses where a cloud server keeps its credentials, let your own services through, and undo it.

What it does

A cloud server answers a request to its metadata address with facts about itself, and on several clouds with the credentials it runs under. Nothing on the internet can reach that address, but the server itself can, so a plugin that fetches whatever address it is handed can be pointed at it. Server detail protection refuses those requests, whichever plugin makes them. It is under Hide site details on BetterShield › Protection › Hardening. Unlike the other 29 fixes, it is on from the start: it is switched on when BetterShield is activated, and by the update that brought it on sites that already ran BetterShield. It has an undo like the rest.

• Refuses a request to a cloud-metadata address made through WordPress, whichever plugin makes it. In the fix’s own words, that is “169.254.169.254 and the rest of the link-local ranges, 100.100.100.200, fd00:ec2::254 and metadata.google.internal, written out, spelled another way, or as a name that resolves to one of them.”
• Refuses a redirect that leads to one of them, so an address that answers “go there instead” does not get around it.
• Lets requests into this server’s own network through. They are never refused, so a search, cache or other service on a private address keeps working; each is noted in the activity log once a day for each address and plugin. Requests to this site’s own address, which WordPress makes to run its schedule, are left alone.
• Tells the plugin why. The refused request gets “BetterShield refused this request because it was going to a cloud-metadata address, where a cloud server keeps its credentials. The activity log names the plugin that made it. If that plugin needs the address, let it through under Protection › Hardening.”, and the activity log names that plugin.
• Stands aside on the store’s cart and checkout, and in safe mode.
• Writes no files, and works on any web server.

What it does not reach: it sees only requests made through WordPress, so a plugin that opens its own connection goes around it.

Step 1: Block Cloud-Metadata Requests

There is nothing to do to turn it on. Open BetterShield › Protection › Hardening and find Server detail protection under Hide site details: the row shows On since and Undo never expires. After the update that brought it, the release panel on the Overview says one of the things it added is already switched on, and lists this fix first: “On after this update.”

Its one option is a list of addresses to let through. The field shows only while the switch is off, so to change it:

1. Turn the switch off.
2. Type the addresses in Addresses to let through.
3. Press Preview the change. It lists what applying would do, including “Lets these through, neither refused nor noted:” with your list. Nothing changes.
4. Turn the switch on again.

An entry it cannot use is named before anything changes: ”“…” is not a host name, an address or a range that can be let through.”

Monitor first cannot watch it in advance: while the fix is off, its panel points you to the preview instead. Other ways to change it:

• WP-CLI: wp bettershield harden cloud_metadata --undo --user=admin switches it off, and wp bettershield harden cloud_metadata --allow=search.internal,10.0.0.0/24 --user=admin switches it on with a list; --dry-run previews. To change the list from the terminal, undo it first. See WP-CLI commands.
• An AI assistant allowed to make changes can apply it. Taking it off needs a plan you agree to.

Recommended settings

We recommend leaving it on for every site. If one plugin really needs a metadata address, list that address under Addresses to let through rather than switching the whole fix off.

What it can break, and how to undo

• A plugin that needs one of these addresses. Its request is refused with the message above, and the activity log names it. Let the address through (switch off, list it, switch on), or leave the fix off.
• Requests into your server’s own network are not broken: they go through and are only noted.
• The store’s cart and checkout are not touched, because it stands aside there.

To undo, turn the switch off. In the fix’s words, “A request to a cloud-metadata address goes out again, and requests into this server’s own network are no longer noted.” “Hardening undone” is logged, rated High because it was switched off by hand, so email alerts send it as it happens. With Ask for my password before removing a protection on, that asks for your password. Once you switch it off, it stays off: later updates and reactivating BetterShield do not switch it on again. Safe mode pauses it, and deactivating BetterShield stops it.

Final Outcome

The row. On since, Undo never expires, and “This one has no effect a page view can check, so it is reported from your settings.”

• The activity log. “Hardening applied” when it was switched on, at activation or at the update. “Request to a cloud-metadata address refused” (Medium) names the plugin that made the request, and “Request into this server’s own network” notes one that was let through.
• Findings. It has no finding of its own. While it is on, Some protections that are switched on are not working (Medium) names it if it reads as on but is no longer in force, for example because another plugin took it off.
• From the terminal. wp eval 'var_dump( wp_remote_get( "http://169.254.169.254/" ) );' prints an error carrying the refusal above, straight away, and the activity log records it.

On multisite

Each site has its own switch.

Related

• Hardening
• Hide the WordPress version
• Hide usernames
• Activity log
• What BetterShield contacts
• Score and findings

This is how you can block cloud-metadata requests with BetterShield.

Getting Stuck? Feel free to contact our Dedicated Support Team.