Theories on Internal DDOS Protection

[murface]

Just thinking out loud here, but:

If a web layout were as such:
DBs ->
origin servers ->
caching reverse proxy servers (RP) with websockets
auth servers ->
End users

Would it be possible to utilize many small auth servers which do dynamic ACLs in conjunction with username/password to then filter incoming requests?

The idea would be to use something like maxmind (mmdb) to filter requests with the auth layer. It could be leveraged to identify anonymizers and tor exit nodes.
Ref: https://www.maxmind.com/en/solutions/ge ... p-database

Doing this, you could filter out uncloaked users, keeping the user base safe in case their VPN is not on, and it would keep load off of the origin and RP servers.

Once authenticated, the auth server could feasibly open the firewall on one RP server to allow the user to get a 302 redirect to the server they'll then interact with for their session over a websocket.

Put a timeout on all firewall changes, and auto expire sessions.

This would at least filter out unauthenticated traffic, and if a DDOS were to hit existing connections to the RP servers would continue to exist as the WS connection stays active. New connections would be filtered out by the firewall, and the connected users would stay connected.

Of course firewall resources are finite and it could still over run a server, but the RP servers could be dynamic and numerous, hitting each RP server which wouldn't be publicly listed would be a feat. Ideally you could enable semi-short sessions, 8 hours or whatever. An RP server could come and go every day, gaining a new IP address all the time with random sub-DNS names. The auth servers could learn the backend servers via Consul.

Tracking firewall changes could be done with a light weight daemon that watches a redis instance or something as a message queue to enable or disable firewall rules set by the auth servers for the RP servers to follow.