You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--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
The text was updated successfully, but these errors were encountered:
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
Description
No response
What should be in the docs?
No response
The text was updated successfully, but these errors were encountered: