[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Firewall Profile: Delete, Save and Restart
All,
Alex brings up a really good case for keeping the ‘Delete’ action and for modifiying the response to a ‘deny’ or ‘allow’
Let’s chat about this in a few hours, but at this point, I am for keeping it…. From: Everett, Alex D <alex.everett@unc.edu>
Sure, feel free. Yes, firing back a rule number would be helpful. -Alex From: Brule, Joseph M <jmbrule@radium.ncsc.mil> You made a really good case for the delete action. May I forward your email to the entire distro? If you want to remain anonymous that I fine, I will just
say ‘one of our members brought up this point….) Your point fired another neuron. When we issue a deny, I was thinking of the firewall sending back a simple 200 (OK) or throw an error if it comes up.
Question: Should we have the response include the ‘rule number’ in case the orchestrator wants to do the exact scenario you spelled out?
From: Everett, Alex D <alex.everett@unc.edu>
Mr. Brule, Imagine this is the ruleset that is running: allow 1.0.0.0/16 to 3.0.0.0/16 tcp dport 80 allow 2.0.0.0/16 to 3.0.0.0/16 tcp dport 443 We decided we wanted to block 4.0.0.0/16 So it becomes: deny 4.0.0.0/16 to 3.0.0.0/16 allow 1.0.0.0/16 to 3.0.0.0/16 tcp dport 80 allow 2.0.0.0/16 to 3.0.0.0/16 tcp dport 443 Now we decided that was a mistake and we want to remove it. How do we do this?
We dont want to do this: allow 4.0.0.0/16 to 3.0.0.0/16 deny 4.0.0.0/16 to 3.0.0.0/16 allow 1.0.0.0/16 to 3.0.0.0/16 tcp dport 80 allow 2.0.0.0/16 to 3.0.0.0/16 tcp dport 443 as it doesnt match the original logic. what is often done, is to retrieve the rule number and delete it: 10 deny 4.0.0.0/16 to 3.0.0.0/16 20 allow 1.0.0.0/16 to 3.0.0.0/16 tcp dport 80 30 allow 2.0.0.0/16 to 3.0.0.0/16 tcp dport 443 and we would say delete 10. Regarding save, I dont see a great use case for that option, it seems to be implied most of the time that the change is saved. Regarding restart, I assume the purpose here is to get back to the saved state if you have lots of uncommitted changes that are ephemeral. Say on cisco you wrote
a bunch of bad ACLs, but luckily you didnt do a write mem, so restarting will get you back to a good state. That said, i dont see this as a key function. -Alex From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org>
on behalf of Brule, Joseph M <jmbrule@radium.ncsc.mil> QUESTION ONE:
I would like to remove three actions from this profile. Do you consider the following actions need to be included in the 'stateless-packet-filtering' (aka firewall)
profile? ·
Delete ·
Save ·
Restart QUESTION TWO:
If you believe that any of the above actions are applicable to the firewall profile, please identify if they should be required, optional and suggested target
type(s) BACKGROUND:
The basis for inclusion of the delete, save and restart actions was a legacy document that we inherited from the forum days. Over the course of the past two weeks
I have been soliciting for use cases and examples so that I may fill in section 2.2 of the draft profile.
The following is NOT consensus attained from the actuator profile subcommittee nor any subset of the subcommittee. The following is my personal opinion only and
request confirmation or rebuttal. In the context of the stateless-packet-filtering:
DELETE: I do not see the utility of including ‘delete’ in this profile. If one needs to delete a block or allow type of rule, then it would be more appropriate
to use a deny or allow. Within the devices may very well be writing, deleting, saving etc, but at the higher language level that we are working at, the deny or allow command is sufficient.
SAVE: I do not see the utility of including ‘save’ in this profile for similar reasons. Save is especially redundant when one considers that there is the optional
persistent and running modifiers. RESTART: I do not see the utility of including ‘restart’ in this profile. We do have an optional ‘update’ action. Update is a compound action that (depending
on the product) may include a restart. About the only scenario that came to my mind for a ‘restart’ was to get back to some known good state, but I would argue that it would be more appropriate to use an update.
VR Joe Brule
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]