Re: Proposal to apply mask to IP address set on rule

GT> So far nobody has given examples of actual misconfigurations that would
GT> benefit from warnings.

MN> Let's firewall a subnet for 16 hosts -- QUICK!:
MN> Is 192.168.33.136/28 on a /28 boundary or not?

GW> This example is most absurd!

Apparantly I need to expand on this.

In a firewall configuration we usually prescribe fixed policies
for different networks.  I'm an ISP dealing with lots of networks
with globally routed addresses of my customers, other admins are
usually tasked with setting policies for their internal RFC 1918
networks -- in the end, it's the same job.  We have to set
policies for distinct networks, and it is the absolute exception
that a single host would stick out within its neighbourhood,
policy-wise.

Therefore, specifying networks with their base address is, while
technically not mandatory, a good operational practice and
a certainly a major convention within at least our admin team.

In this context, "192.168.33.136/28" is a fishy spec and somebody
most probably fumbled that.  It maybe a miscalcation due to lack
of coffee or a typo in the "/28" due to too much coffee.  Whatever
it is, it not QUICKLY recognizable once it made it into the config.
It is NOT obvious to someone paging over it to add some more rules
further down in the config.  The mistake can then easily remain
undetected for days/weeks/years...

That's why I think that it deserves a warning.  (Which Greg Troxel
was asking about.)

Again: I find "at.ta.ck.er/24" specs very helpful myself.
I *don't* want to prohibit them.  I *want* to see them in
dynamic blocklists as created by blocklistd(8) or sshd-9.8
onwards, and I *do* add ad-hoc filters using them manually in
cases of attacks.

Still:  with the static fw configuration files, I would benefit
from a warning when hosts bits are set.

							Martin