jmason wrote:
Tim_Lopez:
Thanks for bringing our thoughts to the team.
Regarding the firewall settings, I am having problem only with Program Control. Everytime my entries hit the magic number, NIS 2012 crashes. I haven't checked what the magic number is, but it must be beyond 100 in my case. As for Port Advanced Settings, Trust Control, and Traffic Blocking, I don't often change the settings in them. I set them only once, when I first install the NIS, then I leave them at that. So, the data in the Program Control are most important to me. Besides, it is not that difficult to set the other settings under Smart Firewall again should they even go awry.
I'd like to restate my issues with NIS 2012. (1) The NIS 2012 crashes when my firewall entries hit the magic number (somewhere beyond 100, I think). (2) I am unable to put more entries into the firewall without causing NIS 2012 to crash again, so my work applications using the firewall are essentially disabled. (3) The pain is in having to manually add all the firewall entries again when another copy of the NIS is installed.
I want a backup capability because of number 3, but having a backup capability still does not solve number 2. If you have any other way of solving number 3, I am all ears.
I have been thinking all this time. If the firewall entries were being saved in a separate file, then perhaps I could just make a copy of it on my own (like backing up or exporting), assuming that I know which file it is and that the system would allow me to do so. Of course, sneaking it back (like importing) into a reinstalled and active NIS would be another story. But then, you guys must have thought of this and suggested it to us already, if it were possible.
Hi, jmason. While I understand where you are coming from - and your reaction to Tim's unwillingness to share details on this situation - there are very good reasons for why things are done the way they are.
1. If you could import/export your Firewall Rules - what's to stop a Malware writer from doing so as well?
2. Because of the problem mentioned in Item 1 - the Firewall Rules are stored in encrypted form. They are stored in such a way as to make it as difficult as possible for Malware writers to even recognize the data in the first place - and even if they did find a way to determine where the firewall ruleset data was stored - the data is gibberish when they try to analyze it.
3. Item 2 is good firewall programming practice. It is necessary - from a Security point-of-view - for things to be done this way. That is not going to change - no matter how much you kvetch - because to do so would open NIS to being manipulated by people other than Symantec and/or you.
4. To allow import/export would allow Malware writers to analyze the relationship between the ruleset as stored in the backup file - and the ruleset as stored within an active installation of NIS itself. Just the existence of these two things is enough of a crack in the Firewall armour for a dedicated cryptanalysis to occur. And eventually - a possible crack of the security procedure used to store the Firewall ruleset data in an active installation of NIS..
5. Nope. No way. Not going there. Not for all the kvetching in China, India and the Middle East combined. Get used to it. IMO, it's the way things are going to be - and rightly so.
Solution:
1. Get several people together. All of you provide the data Tim is looking for. From that, Tim will relay the info to the Product Development Team. They will analyze the data and find the set of circumstances that trigger the bug. It's going to be some obscure interaction that only occurs on a limited number of machines. The fact that it occurs with different numbers of rules in different situations for different people means the problem is not just a straightforward buffer-overflow situation.
2. If this problem was widespread - there would be far more people in this thread. Since it only occurs for people who customize their firewall rules - and only when some mysterious set of circumstances cause the firewall rulebase to become corrupt in such a fashion that it cannot be edited - the Product Team needs to look at enough submitted data from enough different people to find a similarity between the submitted datasets. That similarity will lead them to discover what is going on - and once they know that - they can fix the problem.
3. What you are going to get - as noted in posts from Symantec - is a fix for the problem. But only if you and the other people experiencing the problem get off your butts and provide the requested data.
4. DO NOT expect Tim - or anyone else at Symantec - to housekeep this item in dribs and drabs. The Product Development Team is going to want at least 6 different sets of submitted data - preferably from 6 different people - in order to have enough info to look for commonalities during the analysis of the submitted data. Product Development is not going to be even remotely interested in looking at the situation until enough data is present and in their hands that something productive will come from their analysis.
5. So, get on with it. And spread the word that "doing it Symantec's way" is IMO the only way you are going to get what you want. From a Security standpoint - there is no other viable solution vector.
