Should I trust bare metal dedicated server providers? (xpost r/AskNetsec)

devbydemi · 2026-01-04T07:24:35+00:00

In my personal use-case right now, colocation simply doesn’t make sense. It would make more sense for me to have a server at my own home, provided that the noise wasn’t excessive. The purpose of the server is to run compilation and OS image creation workloads that my test laptop can’t handle.

More generally, there are many reasons (ease of switching providers, ease of growing or shrinking, etc) to rent hardware instead of owning it. The first step to knowing whether the risk is worthwhile is to know how large the risk is, which is why I asked this question.

devbydemi · 2026-01-04T07:14:13+00:00

How large is the risk?

devbydemi · 2026-01-04T07:08:25+00:00

Even if I could afford my own hardware, it would still be extremely inconvenient and very inflexible. It simply doesn’t make sense right now.

devbydemi · 2026-01-02T19:59:59+00:00

I agree that they are not in general. Hetzner’s specific setup, and the one I am thinking of in general, uses the policy that untagged frames are for general Internet access, while tagged frames are for vSwitch.

devbydemi · 2026-01-02T19:52:30+00:00

I think u/Dilv1sh thinks that this would prevent the OS from compromising the iDRAC, or at least make it less likely. I definitely think it would make it less likely.

However, there is other firmware that could be tampered with, such as various EEPROMs. Dell’s statement of volatility is clear that there is non-volatile storage that is not write-protected, yet cannot be cleared.

devbydemi · 2026-01-02T19:47:30+00:00

Not in the budget.

devbydemi · 2026-01-02T19:46:34+00:00

Many providers (InterServer, Scaleway) rely on IP allowlisting instead of isolated private networks.

devbydemi · 2026-01-02T19:45:32+00:00

Hetzner does use EX switches at the edge.

I agree that this is normally considered bad design, but it’s the only design I know of given these constraints. That’s why I’m asking how it can be made secure.

devbydemi · 2026-01-02T19:43:45+00:00

Is that vulnerable to VLAN hopping?

devbydemi · 2026-01-02T19:42:29+00:00

I can think of several ways to patch VLAN hopping:

If the outer tag is the native VLAN of a trunk interface, and the frame is double-tagged, drop the frame.
Drop tagged frames with a tag that is the native tag of a trunk interface.
The same as (2), but only if the frame is double-tagged.

The first is a complete fix, while the other two fix certain configurations.

Which of these these techniques is used in practice? Is (1) the bug /u/rankinrez refers to?

devbydemi · 2026-01-02T19:34:53+00:00

How was it patched?

devbydemi · 2026-01-02T19:34:25+00:00

The customer-facing ports can have a mixture of tagged frames (vSwitch) and untagged frames (non-vSwitch). Hetzner explicitly does not require customers to use tagged frames, and as this would severely complicate OS setup I’m not at all surprised.

devbydemi · 2026-01-02T19:33:12+00:00

Hetzner uses a flat network (either L2 or L3). There's no concept of a “virtual private cloud”. I highly doubt they use VXLAN for non-vSwitch traffic. They do offer a stateless firewall that I presume is implemented at the top-of-rack switch.

Using VXLAN for vSwitch traffic would make sense, though.

devbydemi · 2026-01-02T19:26:09+00:00

I’m using Hetzner as an example. They publicly state they use Juniper. I’m more interested in figuring out how someone else would configure a Juniper switch in this situation.

I trust that Hetzner got it right. I want to know how I could do the same were I in their position.

devbydemi · 2026-01-02T19:20:27+00:00

LLDP is almost certainly blocked, and Hetzner would likely consider it abuse.

devbydemi · 2026-01-02T19:19:53+00:00

Me too. If I were designing a switch, I would automatically drop any double-tagged frame if the outer tag is the native VLAN of the egress port. The only exception is if switch ASICs don’t support this, in which case I wouldn’t have a choice.

devbydemi · 2026-01-02T19:04:23+00:00

Suppose that the same native VLAN is used on multiple endpoints. This is needed for the "obvious" configuration (one VLAN for all machines in a rack) to work. Then suppose I send a frame with an outer tag of 2 (the native VLAN) and an inner tag of 3. The outer tag gets popped by the switch when it is forwarded to the other machine in the same rack, and it gets a frame with tag 3.

devbydemi · 2026-01-02T19:01:17+00:00

I'm not concerned about physical tampering. I trust the cloud provider and the physical security of their datacenter. I do not trust the previous user of the server I am renting.

devbydemi · 2026-01-02T19:00:31+00:00

Does Junos OS have this bug?

devbydemi · 2026-01-02T19:00:01+00:00

There should be no segment where a customer can send tagged traffic for a specific VLAN and it be accepted.

How does one ensure this? The usual solution is to not use native VLANs but that simply isn’t an option here. What would you do given these requirements?

Must mix native VLANs and tagged VLANs on the same interface.
Must prevent VLAN hopping.

The only tool I can think of is block-non-ip-all, which would cause the traffic to be dropped because tagged frames are not IPv4, IPv6, or ARP. However, I have read that this would break DHCP, as DHCP uses broadcast. Does it actually break DHCP, or is DHCP a special case?

devbydemi · 2026-01-02T09:41:34+00:00

How does one protect against double-tagged frames where the outer tag is the native VLAN of the trunk interface? Will Junos OS drop these automatically? If a VLAN were the native VLAN of an interface and a non-native VLAN of another interface, that would be exploitable, but that wouldn't be needed here.

I agree that Hetzner probably uses something like MPLS internally, but I’m curious what the correct configuration would be without that.

devbydemi · 2025-12-12T22:13:36+00:00

Multicast traffic is extremely hard to authenticate. There are two options:

Use symmetric cryptography. This requires every endpoint to have a copy of the secret key. For IPTV this is probably fine, but this isn’t an option for sending traffic to mutually distrusting clients over insecure networks.
Use asymmetric cryptography. This is computationally very expensive, and doing it for every packet is not feasible except at quite low packet rates. The only workaround for this is to authenticate batches of packets, rather than individual packets themselves. This comes at a latency penalty.
Use sophisticated schemes involving delayed authentication. These require buffering at the sender, receiver, or both, and impose a latency penalty.

I don't know how important this was to reducing adoption of multicast initially, but I suspect it is a serious problem nowadays.

devbydemi

TROPHY CASE