this post was submitted on 04 Feb 2024
141 points (96.7% liked)

Selfhosted

40218 readers
1014 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

I am running this docker image: https://github.com/nextcloud/docker with a cloudflare tunnel, meaning the webserver would see all the traffic coming from a single ip in 172.16.0.0/12 .

The documentation says:

The apache image will replace the remote addr (IP address visible to Nextcloud) with the IP address from X-Real-IP if the request is coming from a proxy in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 by default

So I thought that this is a not a problem, as other docker images can also automagically figure out the real IP address from traffic coming from cloudflare tunnels.

In the beginning it worked fine, then it was SLOW. Like 2 full minutes to load new feeds on news, waiting ages to complete a sync, and so on. I rebooted the server on those instances, and then it worked fine for a day.

So because at the time i was running it on unraid, i blamed the lag on that OS + my weird array of HDDs with decades of usage on them. Migrated to debian on a nvme array and... same lag!

Wasted hours trying to use caddy+fpm instead of apache and it's the same, worked fine for a day, then it was slow again.

Then I wondered: what if the program is "smart" and throttles it by itself without any warning to the admin if it thinks that an ip address is sending too many requests?

Modified the docker compose like this:

  nextcloud:
    image: nextcloud

became

  nextcloud:
    build: .

and I created a Dockerfile with

FROM nextcloud
RUN apt update -y && apt upgrade -y
RUN apt install -y libbz2-dev
RUN docker-php-ext-install bz2
RUN a2enmod rewrite remoteip
COPY remoteip.conf /etc/apache2/conf-enabled/remoteip.conf

with this as the content of remoteip.conf

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 10.0.0.0/8
RemoteIPTrustedProxy 172.16.0.0/12
RemoteIPTrustedProxy 192.168.0.0/16
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/12
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32
RemoteIPTrustedProxy 2606:4700::/32
RemoteIPTrustedProxy 2803:f800::/32
RemoteIPTrustedProxy 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32
RemoteIPTrustedProxy 2a06:98c0::/29
RemoteIPTrustedProxy 2c0f:f248::/32

and now because nextcloud is seeing all the different ip addresses it doesn't throttle the connections anymore!

you are viewing a single comment's thread
view the rest of the comments
[–] lud@lemm.ee 6 points 9 months ago* (last edited 9 months ago) (3 children)

If you ever got hit with a DDoS while on the free tier they'd just disconnect you.

I can't find anything that supports that statement. What is your source?

From what I understand you can do a bunch of things when under attack like requiring captchas.

[–] lemmyvore@feddit.nl -1 points 9 months ago (2 children)

Up to a certain volume they serve a page that runs some JavaScript heuristics to figure out if the client making the request is legit or not.

Past a certain volume your service is cut off completely.

The cutoff point depends on the load on their free tier network, which is shared by all freeloaders. Could be someone else under attack and you'd still get cut off.

CloudFlare is a CDN first of all, and it makes its money from paying customers. The free tier and the registrar and the DNS and the reverse proxy and basic DoS heuristics etc. are just there to generate word of mouth and free advertising. Nobody was talking about CF a few years ago when they didn't offer these free services, now every selfhoster and their dog will recommend them.

[–] lud@lemm.ee 2 points 9 months ago (1 children)

The cutoff point depends on the load on their free tier network, which is shared by all freeloaders. Could be someone else under attack and you'd still get cut off.

Again, do you have a source for that?

All the information I can find points to the ddos protection being essentially the same regardless of price plan. The paid plans just get some more features. Like extra firewall stuff.

[–] chiisana@lemmy.chiisana.net 1 points 9 months ago

On the product offering page for Free DDoS Web Protection, the features table shows that "Unmetered DDoS Protection" is available for everyone regardless of tier from Free all the way up to Enterprise. This change was rolled out on 2017-09-25, prior to this, there was a certain amount of throughput depending on price point (though, still very generous for the free tier from what I remembered).

Sometimes, people make up their mind about something and never update their knowledge, and it would appear this is one of those case here.