Firewall rule description length limitation

somebodythatiusedtoknow

To be honest your prob doing it wrong if your using books for descriptions.. The rule by itself tells you what its doing, all the description needs to be is maybe for who to contact, or sounds like your in a business setup why not just put in the change control number that requested/allowed the rule to be created.. Then if any questions on that rule you just look up the change control doc..

Yes, some places we are required to follow a strict change management procedure. It is not that we are writing novels about our rulesets, but putting a descriptive comment (comment, as in short) in the rule allows us to determine whether what the rule is used for and whether it is still what we need to use when reviewing. Some places we are required to use a generic ID of up to 26 characters. Let me give you an example of why this is an issue:

"This-is-a-24-characterID Allow x traffic from a to b"
This string is exactly 52 characters long, with an ID of 24 characters and no chance to describe the purpose of the rule. Perhaps I am doing it wrong, but it works :-)

heper

while i agree with the comments of the other members, you can always change the field yourself:

https://github.com/pfsense/pfsense/blob/RELENG_2_2/usr/local/www/firewall_rules_edit.php#L723

https://github.com/pfsense/pfsense/blob/RELENG_2_2/usr/local/www/firewall_rules_edit.php#L1254

cmb

@heper:

while i agree with the comments of the other members, you can always change the field yourself

…and break your ruleset.

The limit isn't something arbitrary we dreamed up for kicks, the descriptions are put into the ruleset as labels and those have length restrictions at the OS level because you don't want to load huge amounts of text into memory as part of your ruleset.

heper

til : descriptions are inserted into the ruleset

thanks for the input chris

somebodythatiusedtoknow

@cmb:

The limit isn't something arbitrary we dreamed up for kicks, the descriptions are put into the ruleset as labels and those have length restrictions at the OS level because you don't want to load huge amounts of text into memory as part of your ruleset.

Thanks for your reply! The limitation did seem intentional to me, but it sounds like increasing the limit would "only" cause a larger memory usage - is that correct?
A larger memory overhead could be acceptable to us depending on the size, hardware and environment.

EDIT: Nevermind, I didn't notice that the links was only for the web-interface. I think we're going to work with the limitations :)

@heper:

while i agree with the comments of the other members, you can always change the field yourself

And thank you, I will discuss this option with my coworkers while mentioning Chris' warning.

cmb

@somebodythatiusedtoknow:

Thanks for your reply! The limitation did seem intentional to me, but it sounds like increasing the limit would "only" cause a larger memory usage - is that correct?

No. The ruleset won't load at all if you exceed that limit, so nothing will work.

awebster

I think each rule should have:

Rule name: This is the current 52 character limited field that names the rule; EG: DMZ OUT, or MAIL IN, etc.
Comment: A free form text field that is just a multi-line comment field that sticks with the rule, no processing is done on it, put whatever you want, a novel or whatever. Ie: click it and a pop-up text box opens for editing it.
Tag: A tag that can be used for automation purposes for finding rules in the rulebase (A-Za-z0-9) charset limitation. Similar to comment, but something you can automate on without having to use some funky regex to find the rules. I am currently using the rule name for this with delimiters, but it isn't pretty.

KOM

I find it deliciously ironic that somone who is having problems with long firewall rule descriptions has a username so long it bleeds into the post header ;D ;D ;D

johnpoz

^ yeah that is good isn't it.. Not sure what firewall he was using, but most of the major players juniper, cisco, checkpoint all have limitations..

What were you using before that allowed you to use unlimited text fields to describe your rules? If you want to know if the rule should still be used, place a date field in there and by policy review all rules after X days, months, years.

awebster

@johnpoz:

^ yeah that is good isn't it.. Not sure what firewall he was using, but most of the major players juniper, cisco, checkpoint all have limitations..

What were you using before that allowed you to use unlimited text fields to describe your rules? If you want to know if the rule should still be used, place a date field in there and by policy review all rules after X days, months, years.

I know for a fact that both Checkpoint and Paloalto Networks have comment fields that you can put basically anything you want in them, but rule names are limited in length.
Completely agree on policy review review after X days, but rarely seen it done in practice. Just keeps the auditors happy I guess.

johnpoz

Have not been on checkpoint in well over year if not 2.. Rule names for sure were limited, I don't remember using comment field..

awebster

I'm on Checkpoint R77.20 and Paloalto Pan OS 6.1.x on a daily basis, and pfSense of course!

Actually to followup on my earlier post, one neat feature that I've seen on Checkpoint is a rule expiry field. They already have schedule like time conditions, but the expiry field just basically completely disables the rule after a certain date.
Again, great for audit compliance, would be cool to have that AND a feature that cleans up expired rules after an amount of time, and a flag to mark it as do not delete in the case of a rule that needs to be enabled from time to time but only for a certain amount of time, like remote support via SSH type of thing.