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

Restrict NGINX to Cloudflare IPs only #3439

Open
MattIPv4 opened this issue Aug 3, 2023 · 7 comments
Open

Restrict NGINX to Cloudflare IPs only #3439

MattIPv4 opened this issue Aug 3, 2023 · 7 comments

Comments

@MattIPv4
Copy link
Member

MattIPv4 commented Aug 3, 2023

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?

@targos
Copy link
Member

targos commented 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
Copy link
Member

nschonni commented Aug 4, 2023

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.

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
Copy link
Member Author

MattIPv4 commented 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.

direct.nodejs.org isn'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.

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

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
Copy link
Member

nschonni commented Aug 4, 2023

direct.nodejs.org isn'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.

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
Copy link
Member Author

MattIPv4 commented 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 :/

Copy link

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.

@github-actions github-actions bot added the stale label May 31, 2024
@MattIPv4
Copy link
Member Author

I don't believe this is stale, as NGINX is still serving some routes via Cloudflare.

@github-actions github-actions bot removed the stale label Jun 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants