Add rate limiter for insertions and deletions

[cgzones]

Add options to rate limit insertion and deletions. Disabled by default.

[matze]

Can't we use this tower layer instead of pulling in yet another dependency?

[cgzones]

Can't we use this tower layer instead of pulling in yet another dependency?

One could, but I tried to achieve something different: Such a layer will rate-limit all requests, including viewing existing pastes. This can also being achieved via a DDOS in a proxy webserver, used for TLS encryption (nginx/apache). I tried to explicitly limit the addition and deletion of pastes to mitigate spamming and bruteforcing the deletion of a specific paste a bit.

[matze]

I'll slate this and the other open PRs for the release after the next one. A lot of good and non-controversial stuff has piled up already and deserves to be properly released.

[matze]

I was thinking a bit about the usefulness. First of all: I hope no one is running this pastebin facing the internet and I don't think that we should add complexity that could be mitigated differently for internal networks. Second: isn't this penalizing everyone instead of the caller?

[kamaradski]

I hope no one is running this pastebin facing the internet I do not recall reading this as a warning in the readme, just an idea that if you do not consider the application robust enough for the open internet, to maybe put recommended usecases in the readme, or a straight up warning to bring your own security if you expose this tool.

Second: isn't this penalizing everyone instead of the caller? Proper rate limiting is hard, especially without any user authentication. There are enough external ways to rate-limit per source ip, so i appreciate (for the time being) your efforts to keep the tool lightweight.

iptables example: `# Allow 30 connections per minute per IP to port 80 iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent
--set --name RATE_LIMIT --rsource

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent
--update --seconds 60 --hitcount 30 --name RATE_LIMIT --rsource -j DROP`

nginx example (also caddy or Traefic can do this i believe): `http { limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        proxy_pass http://localhost:8080;
    }
}

}`

fail2ban can be made to work with webserver/proxy logs and/or iptable logs

And most CDN's like Cloudflare have several methods for rate limiting available. For example if you would expose this tool to the internet via cloudflare tunnel, it would be easy to set a rate limiting rule in the WAF, on top of the usual DDOS and bot protection offered by cloudflare.

[matze]

I do not recall reading this as a warning in the readme, just an idea that if you do not consider the application robust enough for the open internet

As you say it yourself, rate limiting is hard but there are ways. I do consider the application robust enough to host it on the open internet but without any authentication it's just begging for abuse. That's what I mean by not running it as is facing the internet.

But I appreciate the concern and will add a remark in the README.md to be aware that authentication is not planned and thus it's not a good idea to host the software publicly.