0

I'm trying to work out some basic knowledge of rate-limiting for my server security so I know how it works. Seems pretty simple as there are different algorithms as well as IP limiting methods. This is not what my question is about, I will be using packages in the end but, in playing around I have discovered:

If I google or use any search to check my IP i get my public address (VPN)

  • Example: 198.8.92.83 (or whatever the VPN session address is) (not actual address)

I check my VPN address in my network settings

  • Example: 10.11.3.2 (this seems to not change when VPN session is toggled) (not actual address)

My private address is never seen anywhere.

  • Example: 188.177.3.88 (not actual address)

When I query for users IP with middleware on Parse Back4App I get

  • Example: 10.4.44.234 (not actual address)

But this IP 4th number changes every request if my VPN is active or not

This is very confusing, if it's confusing to me (weather a beginner or not) how can an IP rate limiter/blacklister do an effective job when an IP is always changing? Question 1...

Question 2, why is my VPN address different than my IP from my request to my server?

What I'm using to get query address:

app.use(function(req, res, next) {
  req.headers['x-real-ip'] = req.ip;
  next();
});

Parse.Cloud.define('geoLookup', function(request, response) {
  var clientIP = request.headers['x-real-ip'];
});

Reference

1 Answer 1

1

You are not checking the users IP address in most cases here:

  • my public address (VPN)
    is the IP address of the VPN endpoint. While it is unique on the internet it is shared with many other users using the same VPN.
  • my VPN address in my network settings
    is the IP address of your machine in your local network. Usually this is an IP address in the private network range. It is not routable on the internet, not unique and is associated with different systems in different LAN.
  • My private address
    is the IP address of your router or in case of CG-NAT some router in the infrastructure of your ISP. It is thus shared with other systems in your LAN or even with other users of the ISP.
  • users IP with middleware on Parse Back4App
    looks like some IP address of an internal infrastructure, similar to your IP address in your local LAN. It is thus shared too.

None of these IP address can be used to uniquely identify a user. Some are internal IP only and can not be used at all, others usually represent multiple machines. Apart from that the VPN exit and the IP allocated by the ISP are often dynamic, i.e. they can change over time.

Which means relying on the IP address to identify a specific user on the internet is not a good idea in the first place. Any rate limiting or black listing will only work for a short term and can often be easily explicitly bypassed by reconnecting to the ISP or by using a different VPN endpoint. Additionally there is a risk of overblocking, i.e. of blocking other users behind the same IP address. As long as one is aware of these limitations it might be used as a short term mitigation against attacks, but not as a reliable long term prevention method.

3
  • Something you might want to note that is in any scenario where rate-limiting is occurring, you have to worry about distributed attacks, which means the attacker is going to be starting with a bunch of different IP addresses anyways, often tuned to avoid hitting rate limits in the first place. Commented Dec 30, 2021 at 23:08
  • Very good to know. I'm assuming that the best rate limiting (assuming a threat model using an authorized user as a threat agent) will be the best model with the most protection against most attacks. In the end I'll go with a package but I'd like to know how it all works as I might slip in some custom rate limiting for users calling cloud code. The more layers the better.
    – RobbB
    Commented Jan 1, 2022 at 22:51
  • @RobbB: The best model should not only provide the best protection but also should only have acceptable side effects. Simply blocking everything will for sure offer the best protection but the side effects will unlikely be acceptable. Commented Jan 2, 2022 at 7:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .