I just found this:
It says that the block page context will not allow editing lists. In my scenario, we trust the people editing the lists, and I have authorisation checks within the rulesets to help with that. It is possible that the Properties I'm tring to use might be legacy commands that used to exist but has been removed, with some cleanup still required.
Also FYI - we're running 7.3.2.
Any suggestions or comments would still be appreciated.
All of the list manipulation properties, like append, join, sort, remove, etc, are only used for the life of a single transaction. they dissolve after the request is completed and they cannot store the results of the operation statically back inside the list itself.
What you are suggesting is to have them save the results again back inside the static configuration. This just cannot be done because the lists are read-only from a user's request context.
The only persistent way to store them is by using Persistent Data storage (PDStorage) , which is only temporary over a period of time and multiple transactions. Also, PDStorage is entirely in memory and doesn't re-write the values back into the lists for you to access via policy.
The best way to do this is to move the lists off-box using subscribed lists and writing an off-boxx application to manage the data and post it to a web server. Then MWG will periodically pull the lists and use them.
Thanks eelsasser for your prompt and thorough response.
We are using external lists of some variety (I can't remember specifics at the moment) and it adds a bit of frustration at times due to it being spread across multiple systems. I was hoping to have no dependencies other than MWG being available. I understand the limitations and why they are there, however.
You can also use REST to update the lists on the MWG directly. This removes the need for an external service providing the list, but still requires an external service to perform the on-box maintenance.
There are customer's who have integration with their ticketing systems which update lists as they need to. Pretty cool stuff.
REST is what ePO uses to update lists on the MWG.
Thanks Jon. I will do some more investigation when time permits.
I have been experimenting with a room-based (ie subnet based) Internet blocking rule system, using pdstorage as a key feature. In my research for this, I found this article:
Jon, in that discussion you mention that the pdstorage timeout values are based on inactivity, not creation of the entry. This means that any time you even read the data, it's lifetime is reset back to the defaults. I wasn't aware of this before, and it made me think about ways to take advantage of that.
If I re-created all of our whitelists and blacklists in pdstorage with, for example, a 365 day timeout, then the lists would stay there for a year after they have been last used. These lists are easy to modify dynamically, and I have done this several times in the past. This sounds like a fairly ideal method, with the exception of the security of the information. I know that I can initiate a single command and wipe out all PDStorage values. This would obviously be a very bad thing that would be very time-consuming to recover from. Is it possible to protect this data in any way to prevent damage or recover from damage? Note that these lists I want to have people edit are local to sites, and are in addition to our base ruleset which is all we require in general. Quite a lot of those lists are empty.
I imagine that McAfee would not recommend going down this path, but I would be interested in hearing any thoughts.
You are correct in that I wouldnt advise going this route. Violtility is the main reason I would not recommend this. PDStorage (at least in my mind) not designed for long term storage. It is meant to store objects in memory for some persistance, but only for temporary situations. So in the case of the room based internet blocking system, it acts as a light switch. You turn it on or off. In your case, you are storing your policy IN pdstorage, this is much more complex and important for PDstorage to handle, so you have much more to lose. So unless you can ensure that your data is safe before you load it into PDstorage I wouldnt advise going this route.
It is also not a good idea to have a large ammount of PDstorage data because it is loaded into memory and could become a bear to load every time.
I think REST is the best way to go here. You can create your own portal for admins to login to, and then simplfy the view they have in order to miniminze the chance for error.