I am currently accustomed to using tools like fail2ban to keep unwanted traffic away from my servers by banning IPv4 addresses: too many bad log entries per IP, ban the IP.

However when the world completes the migration to IPv6, banning single addresses probably won't work anymore, since a "normal" botnet computer or attacker posses quite many IPv6 addresses?

If I want to block IPv6 users what would be the best way to accomplish this? Use a certain IP mask or something else?

How about doing "upscaling heuristics" when you get multiple individual hits inside IPv6 then ban the whole block?

For me it is more important to mitigate the threat. If some poor genuine users to belong to the same block with blocked IPs then it is an issue between those people and their ISP to get that netblock cleared.


Banning per /128 does not scale when a subnet of /64 size is used for an attack. You will end up with 2^64 entries in the table, potentially causing a denial of service.

End-users will always receive a /56 per global address assignment policy. Businesses will always receive a /48 per global address

See: https://tools.ietf.org/html/rfc6177 /128 should never be assigned to a server/user, minimum assignment to another entity (server/vps customer) should be a /64. Minimum assignment to a site should be a /56. Giving out /128s is fundamentally broken and should be considered a configuration error.

I therefore recommend temporary banning per /64, given that a typical end-user will only have access to 2^8 /64s, it should not introduce too many entries in the banning table.

| improve this answer | |
  • 1
    Blocking an entire /64 due to one problematic IP is going to cause legitimate users to be blocked. – kasperd Dec 14 '14 at 12:49
  • 1
    Yes, but only if they are on the same site.. So yes, a user VLAN could get blocked inside one building. Or all VMs belonging to a customer if one of the VMs misbehave in a cloud. Assigning a /64 to multiple users for servers is problematic in many many ways, that's broken. But the denial of service attack surface of blocking per /64 is much lower than with /128. – Wilco Baan Hofman Dec 15 '14 at 19:55

Any answer to your question will involve some amount of guessing. IPv6 deployments are still few enough that we simply don't know yet, what exactly the threat scenario will look like.

The large number of IPv6 addresses will introduce multiple changes to the threat scenario you will have to consider.

First of all with IPv4 it is entirely feasible for an attacker to scan the default port number for some vulnerable service across all 3700 million routable IPv4 addresses. Such untargeted attacks are not feasible with IPv6. Those attacks you still see will have to be more targeted. Whether this means we'll have to change much in our handling of the attacks remains to be seen.

The primary purpose of banning IPs based on log messages would be to reduce noise in the logs and to some extent to reduce system load. It shouldn't serve as protection against exploits. An attacker who knows a weakness would be inside before the banning kicked in, so to protect against that you have to patch vulnerabilities - just like you have always had to.

Banning individual IPv6 addresses might be sufficient to reduce noise in logs. But that is not a given. It is not unlikely that an attacker might use a new IP address from the range available to them for every connection. If attackers were to behave like that banning individual IPv6 addresses is not only going to be ineffective, but you may even inadvertently cause a DoS attack on yourself by using all your memory for firewall rules.

You can't know the length of the prefix available to each individual attacker. Blocking a too short prefix will cause a DoS attack by covering legitimate users as well. Blocking a too long prefix will be ineffective. Password brute force attempts in particular are likely to use a large number of client IPv6 addresses.

In order to be effective against attackers switching IPv6 address on each request and in order to keep memory usage down, you have to block ranges, and due to not knowing prefix lengths in advance, you have to adjust the prefix lengths dynamically.

It is possible to come up with heuristics already now. How well they'll work we don't know yet.

One heuristic would be for every prefix length to define a threshold of how many IPs it takes to block a prefix of that length. And blocking should only be applied at a specific length, if a longer prefix wouldn't be sufficient. In other words you need enough individually blocked IPs in each of the two halfs in order to actually initiate a block.

For example one might decide that in order to block a /48, there must be 100 blocked IPs in each of the two /49s making up the /48. The longer the prefix the smaller the number of IPs needed to block it would have to be, but in every case they would have to be spread across both halfs.

| improve this answer | |
  • 2
    Almost 5 years later, any reconsideration of IPv6 and Fail2ban? – Paul Jul 7 '19 at 15:51

You should stick to banning single addresses.

It's not defined how many addresses will be given to end-users. Some ISPs may give a whole subnet and others only one address.

| improve this answer | |
  • Same answer for your second question. As you can't know which network setup is defined on the other side, you may end in blocking a lots of users. – Pierre-Yves Gillier Sep 25 '14 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.