Firewall rule description length limitation
-
Hello all of you,
I am currently working on migrating to pfSense firewalls. It took me a little while, but I'm pretty happy with it except for one thing especially. The description field of a firewall rule is limited to contain no more than 52 characters. This is an issue to me, as we are several people managing the firewalls. This calls for a need to use generic ID's and useful descriptions, and we find it impossible to do so with just 52 characters in most cases. We don't want to end up using an external document to keep track of the descriptions, but read a complicated ruleset with the help of descriptions and ID's.
I noticed just one other description field was limited, in the firewall schedules. This was limited to 40 characters, and all of the others (that I've checked) are unlimited. This made me think there could be a reasonable explanation to the length limitation.
So my questions:
1. Is it possible to work around this firewall rule description length limit?
2. Is there an explanation to the limitations? If yes, what is it?Best regards,
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..
-
^ Exactly what I would have said. Though in answer to your questions directly, I would have thought that 1.) No, there isn't a workaround and 2.) The limitations are there to keep your ruleset from looking like a cluttered, text-ridden mess. Most firewalls - and I've used a good many - have such limitations set on the descriptive field for that very reason.
-
+3. If you want to write novels, your FW rules' descriptions are not the place to do so. And if there's someone to inherit the work after you and requires the novels to understand the rules, then it's either a wrong person for the job, or your FW rules design sucks elephant's nuts.
-
threadshouldhavebeentitledscreennamelengthlimitation.
-
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 :-) -
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
-
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.
-
til : descriptions are inserted into the ruleset
thanks for the input chris
-
@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 :)
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.
-
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.
-
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.
-
-
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
-
^ 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.
-
^ 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. -
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..
-
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.
