mjhjmtu

Which rule could we apply on iptables to limit amount of downloaded traffic, for example we need to limit customer so he can download only 400 Kilobytes in a minute from one ip address ? If he downloads more, then block his ip for 5 minutes ? Not apache/nginx, but rather iptabes. I would like to close the network connectivity to people who trying to get > 400kb in one minute frame.

This answer assumes this is an XY Problem, and what you actually want is some way to limit server resource usage on a per-user basis to protect against DoS attacks.

First off, there are much better options that don't involve using just iptables, namely:

1. Use rate limiting built into whatever server software you're using. Most major web servers have support for this built in or as a standard module. It's also the canonical way to rate-limit access to a specific service on a single system. This has three big advantages over using iptalbes:
   
   
   • It doesn't block anyone, but it doesn't allow them to exceed their bandwidth cap either (provided you limit the number of connections per source IP).
   
   
   • It doesn't clutter your firewall with things that are application-level policy.
   
   
   • It is generally very easy to set up. With NGinx, it's quite literally one line (five if you include per-source connection limiting). For Apache, it's two lines (not including the line to load the module).
   
   


2. Use some reverse proxy software (this can even run directly on your application server in some cases) to provide rate limiting. Squid is one of the best examples of this approach, but most reverse proxy options have some kind of support for it. This is the canonical approach if you have multiple backend systems.


3. Adjust the TCP window scaling parameters. This is reliable and won't break your client if done correctly, and doesn't require any dynamic adjustment once it stabilizes. However, it's non-trivial to set up, and a smart client can work around this to improve performance. This can be done with any server software with some work, but is also limited to per-connection rate limiting.


4. Use network device queue disciplines combined with connection marking from iptables to do real per-connection rate limiting. This is extremely complex to set up, but has two distinct advantages, namely that it is 100% protocol agnostic (you can use it with anything), and it provides extremely deterministic behavior (which simplifies testing).

If you for some reason absolutely have to use nothing more than iptables, you have three general options:

1. Use the limit match by itself. This will allow you to limit the number of packets per unit time. By doing some simple math with the MTU for the link, you can easily arrive at a cap for the requested bandwidth.
   For example, to get 400 kilobytes per minute on a link with a MTU of 1500 (standard for Ethernet), you would be looking at a limit of 4 packets per second, or 267 per minute (neither is exact, but they're both within 1%). You will however have to add a rule for each client IP, as the limit is shared for everything that matches the rule.


2. In a slightly more sophisticated setup, you could use the hashlimit match instead, which would allow for slightly better handling, but suffers from the same rule-per-client limitation as above.


3. If you absolutely want reactive rate limiting (this is a seriously bad idea, to a degree I absolutely can not emphasize enough here, it will break user expectations on many levels, and is extremely hard to debug by itself, and makes debugging other issues much more difficult), then take a look at the rateest match and target. The target collects data, which you can then match on with the match. That in turn can use the LOG target to trigger action by a userspace helper program which can block the IP.