Given that Amazon hasn’t published a definitive list of IP addresses that would original Alexa requests, the only guidance I have seen so far is a) try to keep your end point sekrit; and b) consider restricting to the entire US-east IP ranges.
I was thinking about this, and am wondering if this is sound or security theater.
Put a proxy in front of the HA public interface. I happen to use a CloudFlare tunnel, so I’d terminate the tunnel on the proxy.
Block access to all calls except:
/auth/token <== to allow new access token generation
/auth/api/alexa <=== to allow Alexa to work
This seems like it limits the attack surface to either a) attackers who managed to exfiltrate the refresh token from Amazon; or b) actual exploits in Home Assistant’s api for Alexa or token generation.
This would not be able to implemented until after you have authorized the skill otherwise you won’t be able to being the authorization sequence to generate the refresh token.
IIRC some others have said that US Alexa. Other regions are not. However, the post is really about what attack surface is left if one restricts to those urls. As we can’t effectively limit access by IP.
Load balancers will always try to get you the closest available server, but if there are issues or updates or other things that prevent the closest, then another will be chosen.
I do not know US law on this, but EU law could prevent the usage of data centers outside EU, because the data could contain personal data.
Absolutely. I still want to focus on the core question. Is restricting access to just those two url paths security theater or actually a security improvement?
If you do not accidentally restrict the wrong ones, then it will always be a security improvement.
Maybe it will not be a big improvement, but small things might be the difference in the end.
And I know some might say it will be “security by obscurity”, but most IT security is like that, especially encryption, which is solely based on obscurity.