Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--rest-api-host-allowlist description discrepancy #599

Open
1 of 3 tasks
rolfyone opened this issue Sep 9, 2024 · 0 comments
Open
1 of 3 tasks

--rest-api-host-allowlist description discrepancy #599

rolfyone opened this issue Sep 9, 2024 · 0 comments
Labels
fix-content Issues with the current documentation content

Comments

@rolfyone
Copy link
Contributor

rolfyone commented Sep 9, 2024

Where is the issue?

Consensys/teku#8567

--rest-api-host-allowlist is currently described in teku documentation as the list of hosts able to access a service.

In reality, it's a flag that restricts the addresses that the server will respond from.
If i had a server offering 192.168.1.1, 192.168.1.2, 192.168.1.3 ip addresses, I would be able to use this flag :
--rest-api-host-allowlist=192.168.1.3 and then any requests coming to my host that don't match the address specified in the allowlist will reject the request as 403 error. So I may choose to listen on all addresses (listen-address=""*") but if my host-allowlist is 127.0.0.1, any except for localhost will return a 403 error...

The logic behind this is around DNS rebinding attacks apparently, but this also legitimately explains why the allowlist won't support subnets, because it's not talking about the client address, it's talking about the server address.

This is further reasoning to using firewall to restrict access to the rest-api, as there was a misunderstanding that this flag was a partial solution to restricting access, which it actually isn't.

I was going to raise a PR but it's bigger than I expected so I'm raising this so that we remember to fix the description.

Issue type

  • Missing content
  • Outdated content
  • Inaccurate content

Description

No response

What should be in the docs?

No response

@rolfyone rolfyone added the fix-content Issues with the current documentation content label Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix-content Issues with the current documentation content
Projects
None yet
Development

No branches or pull requests

1 participant