Repository navigation
Restrict NGINX to Cloudflare IPs only #3439
Description
Currently, anyone can access direct.nodejs.org, bypassing the Cloudflare CDN, caching and protection. It is relatively well documented that folks are using this to get around some of the blocking that was put in place for misconfigured Artifactory instances etc.
The NGINX config should be updated such that it only accepts connections from Cloudflare, removing the ability to make HTTP requests to direct.nodejs.org. As I understand it, the hostname itself needs to remain (unproxied) for SSH access etc., but I don't believe there is any need for direct HTTP access, so I believe this should be fine to do?
Activity
targos commentedon Aug 4, 2023
+1
I guess using iptables configuration might be better to avoid server overload, but if NGINX config is much easier to change, it's fine too.
nschonni commentedon Aug 4, 2023
Wouldn't the solution to that be to copy the cloudflare agent filtering rules down to NGINX for the requests to the direct.nodejs.org.
I thought the point of that endpoint was a "break glass" when cloudflare caching got messed up, so restricting to only CloudFlare IPs would defeat it's purpose
MattIPv4 commentedon Aug 4, 2023
direct.nodejs.orgisn't proxied through Cloudflare, so that wouldn't be possible. If it were to be proxied, it might as well just be removed at that point IMO.Maybe it is, and I've misunderstood its purpose. If that is the case though, it is forever going to get used by folks who want to get around blocking etc., or just don't know any better, and will keep putting additional load on the origin with no caching (and leave the origin incredibly open to DDoS etc.).
nschonni commentedon Aug 4, 2023
I'm not saying proxying it through cloudflare, I mean just copy those same firewall rules to nginx https://www.cyberciti.biz/faq/unix-linux-appleosx-bsd-nginx-block-user-agent/ if you think people are using it to bypass those specific rules
MattIPv4 commentedon Aug 4, 2023
Ah yeah, we could move the restrictions to NGINX as well as Cloudflare (or remove them from Cloudflare at that point). It still leaves the origin exposed to the world without caching though, which isn't great :/
github-actions commentedon May 31, 2024
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
MattIPv4 commentedon May 31, 2024
I don't believe this is stale, as NGINX is still serving some routes via Cloudflare.
flakey5 commentedon May 23, 2025
Sorry for bumping an old issue, but I'm curious if Access would be a good use case here?
I agree that direct.nodejs.org shouldn't necessarily be publicly accessible, but it can be helpful when debugging issues with the release worker.
This way the ports would still be open to Cloudflare ips only but people could still send requests to it directly if need be (given they have access)
targos commentedon May 25, 2025
That sounds like a good idea!
flakey5 commentedon Jul 28, 2025
Shouldn't be too complicated but just realized it would mess with ssh.
Actually doing it just needs an access policy that allows the necessary emails for otp or if we wanna use an idp, then creating a self-hosted application w/ the direct.nodejs.org public hostname & using that access policy.
But, this would cover any traffic on any port going to direct.nodejs.org and not just http, ssh can be used over access ofc but there would need to be changes to CI