←back to thread

597 points classichasclass | 5 comments | | HN request time: 0.646s | source
Show context
lwansbrough ◴[] No.45010657[source]
We solved a lot of our problems by blocking all Chinese ASNs. Admittedly, not the friendliest solution, but there were so many issues originating from Chinese clients that it was easier to just ban the entire country.

It's not like we can capitalize on commerce in China anyway, so I think it's a fairly pragmatic approach.

replies(6): >>45010748 #>>45010787 #>>45010871 #>>45011590 #>>45011656 #>>45011732 #
1. imiric ◴[] No.45011590[source]
Lately I've been thinking that the only viable long-term solution are allowlists instead of blocklists.

The internet has become a hostile place for any public server, and with the advent of ML tools, bots will make up far more than the current ~50% of all traffic. Captchas and bot detection is a losing strategy as bot behavior becomes more human-like.

Governments will inevitably enact privacy-infringing regulation to deal with this problem, but for sites that don't want to adopt such nonsense, allowlists are the only viable option.

I've been experimenting with a system where allowed users can create short-lived tokens via some out-of-band mechanism, which they can use on specific sites. A frontend gatekeeper then verifies the token, and if valid, opens up the required public ports specifically for the client's IP address, and redirects it to the service. The beauty of this system is that the service itself remains blocked at the network level from the world, and only allowed IP addresses are given access. The only publicly open port is the gatekeeper, which only accepts valid tokens, and can run from a separate machine or network. It also doesn't involve complex VPN or tunneling solutions, just a standard firewall.

This should work well for small personal sites, where initial connection latency isn't a concern, but obviously wouldn't scale well at larger scales without some rethinking. For my use case, it's good enough.

replies(2): >>45012544 #>>45013770 #
2. seer ◴[] No.45012544[source]
I guess this is what "Identity aware proxy" from GCP can do for you? Outsource all of this to google - where you can connect your own identity servers, and then your service will only be accessed after the identity has been verified.

We have been using that instead of VPN and it has been incredibly nice and performant.

replies(1): >>45013422 #
3. imiric ◴[] No.45013422[source]
Yeah, I suppose it's something like that. Except that my solution wouldn't rely on Google, would be open source and self-hostable. Are you aware of a similar project that does this? Would save me some time and effort. :)

There also might be similar solutions for other cloud providers or some Kubernetes-adjacent abomination, but I specifically want something generic and standalone.

replies(1): >>45021034 #
4. shadowgovt ◴[] No.45013770[source]
It all started with an inverted killfile...
5. Mo3 ◴[] No.45021034{3}[source]
https://github.com/topics/identity-aware-proxy