Implement rate limiting

[TheHackerDev]

As detailed in #16, the application's design makes it vulnerable to server-side request forgery (SSRF). While there have already been some mitigations put into place, it would also benefit from one more- rate limiting.

Attackers can currently use an open BeePing instance to launch an anonymous DoS attack by routing a large amount of traffic through the BeePing system to the target server. While it is likely that the single BeePing instance would crash before the targeted system, it may not always be the case (if BeePing was running on a beefy, auto-scaling AWS instance, for example). By implementing rate limiting, we can limit the amount of traffic that can go through BeePing from one source, which would severely limit any types of DoS attacks through a BeePing instance.

I would recommend adding a configuration option in the future and a command-line flag now to address this. The rate can be user-customizable, but a good default would be something like 10 requests per second (per source IP). That wouldn't be enough to bring down most web servers, and it would give victims and BeePing instance operators a chance to block the source IP of the attack with a firewall rule.

You would have to track the source IPs that BeePing sees for a short period of time (only a few seconds, if the metric is requests per second) in order to check the request rate in the programming logic. A small database (in-memory or local filesystem-based) would be perfect for this use case; I've heard good things about Hashicorp's memdb and boltdb. Just be sure to properly wipe IP addresses from the database at the end of their life, as it could cause privacy concerns for users to have them long-lived.

Cheers,
Aaron (insp3ctre)

[yanc0]

It sounds great but I don't want to store any data on disk for scaling reason, I want to be full stateless on BeePing. I'll think of a convenient way to do this.

Thanks !

[TheHackerDev]

I don't think it'll be possible to actually store any data persistently without doing that. I suggested memdb for that reason, because it runs entirely in-memory. Redis is another option for that as well. You'll have to have some persistence across time timeframe that you want to check for rate limiting. I'd be happy to hear of other options you come up with though, this can pose an interesting engineering problem 😄 .

Aaron (insp3ctre)

[yanc0]

In memory database is fine, Redis is great for distributed BeePing cluster as well. By default we can use memdb and we can implement Redis for advanced BeePing installation after.

[TheHackerDev]

Just to be clear, I won't be able to dedicate the time to implementing a database into BeePing to solve this problem. However, if you implement it, I'd be happy to look it over.

Cheers,
Aaron (insp3ctre)

[yanc0]

Hi Aaron,

For sure it will be my work, there is a lot of refactoring needed for this feature. I'm still looking for time to do this but be certain our discussion on this issue will be implemented on BeePing.

Thanks for your review proposal.
Yann

[TheHackerDev]

Awesome, I look forward to seeing it!

Cheers,
Aaron (insp3ctre)