Lack of interest CIDR Notation for IP Blocking

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Morgan

Active member
I would like to use CIDR notation to specify ranges of IP Addresses to block instead only using * characters. Consider the following:
Code:
49.145.96.*
49.145.97.*
Could become:
Code:
49.145.96.0/23

Of course this is a simple example and likely I would prefer to block much larger groups of addresses such as the address block which this IP is announced in:
Code:
49.145.96.0/19
 
Upvote 3
This suggestion has been closed. Votes are no longer accepted.
Yeah this could be useful for sure...
_______________________________________
49.145.0/16
range: 49.145.0.0 - 49.145.255.255
_______________________________________
49.145.0/17
range: 49.145.0.0 - 49.145.127.255
_______________________________________
49.145.0/18
range: 49.145.64.0 - 49.145.127.255
_______________________________________
but then when you need to block
range: 49.145.0.0 - 49.145.55.255
you need to block
49.145.0.0/19
49.145.32.0/20
49.145.48.0/21
this can get confusing...
___________________________________

...to be honest I don't think that most people understand CIDR ranges well enough for this to be useful to them
(
also you could block millions of ip addresses without even realizing it
49.0/8
range: 49.0.0.1 - 49.255.255.254
)
and if you really want to stop network traffic like that, I would think it is better to do it at the router or firewall level and not in your public folders on your webserver..
...though for those that can utilize it and don't have access to the firewall or router that their server is behind will surely appreciate it.

I only know the bit that I know because I got sick at some point of people attacking my server so I started building a report of activity from attacking addresses and once the info has been noted...I route them out of my hair. I doubt many people who actually run sites care to learn about blocking cidr ranges just to block people from registering on their forum. If they are taking the time and learning how to calculate CIDR ranges I would feel safe saying they are wanting to stop traffic before it hits their webserver.
 
The forum I help out with is on a shared system so using iptables isn't realistic. And while CIDR notation is clearly not for everyone and can easily block a large number of address, 49.* could do just as much damage as 49.0/8 and we don't see people complaining that the * is to easy to misuse. Ultimately if you don't understand CIDR notation, that's ok, * wildcards shouldn't be removed, I was suggesting that CIDR format be also supported in addition.

They could even link to a CIDR calculator, wikipedia page on CIDR, or even just not mention it at all (and if someone does send a CIDR block then use it).
 
lol @ not mentioning it all :-)

but honestly I think about it a little bit more and I suppose there is ways to get past the ease of use ability as I have thought of one myself but I have to admit I did not realize you could go as far as 49* with what is current mostly because I don't actually run a forum, I install it and try not to break it while trying to learn php...so I have literally never had to use that option so I also I had not seen the comment under the ip to ban box showing the usage example.

As I said this thread has kind of stuck in my head all day and I can see a valid point with this. If it is possible for this to be done and not remove what is in place already I would say I would have no problem with it being added in.
 
What gets even more confusing to trying to do it for IPv6 addresses. The numbers becomes so large it's impossible to do the math. Then I was doing some testing with those Online CIDR calculators and IPv6 ranges and they all spit out different results, so they are not reliable. I only found one so far that seemed to be accurate was: http://www.unlocktheinbox.com/ipcidr.aspx

I definitely see the benefit of CIDR notation..
 
Blocking IPs at the application level for anything beyond the occasional obnoxious user isn't really that useful. If it's a DDoS attack for example, it's already too late if the network traffic reaches the application level. In most cases, CIDR blocking is probably only going to be understood by someone who has access to block the traffic before it gets to the application layer (which is better anyway).

On a side note, we use DDoS mitigation hardware to simply drop the packets into nothingness as they pass through (it's not a router or anything else that has an addressable IP/MAC address so someone couldn't target that device for attack). It just looks at traffic as it passes through and can drop the packets before it gets to our router. It's quite a fun little device. :)
 
I would like to use CIDR notation to specify ranges of IP Addresses to block instead only using * characters. Consider the following:
Code:
49.145.96.*
49.145.97.*
Could become:
Code:
49.145.96.0/23

Of course this is a simple example and likely I would prefer to block much larger groups of addresses such as the address block which this IP is announced in:
Code:
49.145.96.0/19

I think for the majority of users, learning to subnet is going to be a pain. Even I have to bring out the subnetting calculator from time to time to verify I'm doing things correctly, or I'm understanding things correctly.
 
Blocking IPs at the application level for anything beyond the occasional obnoxious user isn't really that useful. If it's a DDoS attack for example, it's already too late if the network traffic reaches the application level. In most cases, CIDR blocking is probably only going to be understood by someone who has access to block the traffic before it gets to the application layer (which is better anyway).

On a side note, we use DDoS mitigation hardware to simply drop the packets into nothingness as they pass through (it's not a router or anything else that has an addressable IP/MAC address so someone couldn't target that device for attack). It just looks at traffic as it passes through and can drop the packets before it gets to our router. It's quite a fun little device. :)

Nobody here said this tool was meant to prevent a DDOS anyways. There ARE situations where blocking ranges in the application is "ok". Maybe you don't have root access to configure a firewall or you don't understand iptables. Sure there are ways to do this more effectively, but clearly having a list of blocked addresses was important enough that XenForo included it even though there are other options to perform the exact same thing often with much less resources as well.

I agree with you that when possible you should use a different approach, but the tool exists and already does a wildcard matching. CIDR matching is only more accurate and specific, why wouldn't this ability be positive? Are you concerned about the CIDR format or the ability to block addresses in the application? For someone who understands CIDR notation this is a huge benefit and for someone who doesn't understand CIDR notation then they will be unlikely to even know what it means to start attempting to use it. For those who can understand CIDR notation this is a great feature and for those who don't, they will gloss over it.

I think for the majority of users, learning to subnet is going to be a pain. Even I have to bring out the subnetting calculator from time to time to verify I'm doing things correctly, or I'm understanding things correctly.

Sure, but the majority of users also never make it to this page and the majority of these "problem" child users probably just pay someone else to install, upgrade and customize their installations of XenForo. Do you expect these same users to understand what 8.0.43.* would block?
 
Sure, but the majority of users also never make it to this page and the majority of these "problem" child users probably just pay someone else to install, upgrade and customize their installations of XenForo. Do you expect these same users to understand what 8.0.43.* would block?

True, but in the same right, why not just install pfsense? You achieve the same functionality, and even more.
 
True, but in the same right, why not just install pfsense? You achieve the same functionality, and even more.
So because a user doesn't understand something the answer is to simply require additional software? Additionally deployment of pfsense is meant more as a NAT/router solution rather than a firewall. Secondly, it certainly wouldn't work in a scenario where you don't have control over the network. I would imagine there are quite a few installations of XenForo that are hosted and may not have root access (for iptables). I would venture to say that those who are hosted, pfSense or any similar solution is not possible.
 
So because a user doesn't understand something the answer is to simply require additional software? Additionally deployment of pfsense is meant more as a NAT/router solution rather than a firewall. Secondly, it certainly wouldn't work in a scenario where you don't have control over the network. I would imagine there are quite a few installations of XenForo that are hosted and may not have root access (for iptables). I would venture to say that those who are hosted, pfSense or any similar solution is not possible.

Is it reasonable however for someone with that much knowledge of subnetting to be content and satisfied with shared hosting, and the lack of root access?
 
Is it reasonable however for someone with that much knowledge of subnetting to be content and satisfied with shared hosting, and the lack of root access?
Good point, but sometimes you aren't in charge. Specifically, I manage an install of XenForo on such a system. Sure I could complain and push for it to move, or I could enjoy my life and play some video games instead. I usually prefer the latter option.
 
I agree, it's frustrating to either block unrelated IPs or make several entries. And if a net is re-allocated it'll be very troublesome to update the IPs.
 
Top Bottom