11-02-2009 11:50 AM
Hi
A new IPS driver version was downloaded today via live update. I don't know if this will have any effect on your problem or not, but I did notice that the driver version is different while the number of definitions remained the same. It is possible that the driver was just changed and they left the same definitions or the change of definitions resulted in the number of definitions.
Success always occurs in private and failure in full view.
11-02-2009 03:51 PM
floplot wrote:Hi
A new IPS driver version was downloaded today via live update. I don't know if this will have any effect on your problem or not, but I did notice that the driver version is different while the number of definitions remained the same. It is possible that the driver was just changed and they left the same definitions or the change of definitions resulted in the number of definitions.
Can someone please verify this? Hopefully the new IPS driver has better performance.
11-02-2009 04:33 PM
Hi
New one as of Nov 2 2009
Intrusion Prevention Engine version 4.5.0.67
Intrusion Prevention is monitoring 1482 signatures
Driver version 9.1.2.5
previous
Intrusion Prevention Engine version 4.5.0.67
Intrusion Prevention is monitoring 1482 signatures
Driver version 9.1.1.7
Success always occurs in private and failure in full view.
11-02-2009 04:37 PM
skypx wrote:Huh... didn't realize my NAS was this fast, since I acquired it NIS2010 has been installed. With NIS2010 installed I'm lucky if 65% of my LAN bandwidth is being used. Without NIS2010, well, a picture is worth a thousand words.
Message Edited by skypx on 11-02-2009 02:13 PM
What concerns me about these pictures is that they are not consistent with timing data. I've read through most of this thread again. When people time throughput, the differential is on the order of 20%. The graph suggests its on the order of 10000000%. A file that takes 10 seconds to transfer would according to the graph take about 10 years to transfer. Since we know that is not the case, let me suggest the possibility that the presence of NIS impinges on the data collection process so that you do not get accurate before-and-after pictures. Personally, I would not be surprised if throughput time doubled or tripled for some files no matter what security system you have. After all each bit has to be sidetracked, strings analyzed, then the bits put back into the flow to the other end of the transfer. Essentially, one action per moment becomes three actions per moment. There is no way this cannot have a significant impact on transfer speed, regardless of the analyzing product.
On the other hand, if the timings reflected the immense difference suggested by the graphs, then the throughput problem would be immense.
I think we need better data here.
11-02-2009 04:55 PM
The new IPS driver which was published today, does not have performance related fixes. It has some other updates that we had planned for a while.
-Ameya
11-02-2009 05:28 PM
mijcar wrote:
skypx wrote:Huh... didn't realize my NAS was this fast, since I acquired it NIS2010 has been installed. With NIS2010 installed I'm lucky if 65% of my LAN bandwidth is being used. Without NIS2010, well, a picture is worth a thousand words.
Message Edited by skypx on 11-02-2009 02:13 PMWhat concerns me about these pictures is that they are not consistent with timing data. I've read through most of this thread again. When people time throughput, the differential is on the order of 20%. The graph suggests its on the order of 10000000%. A file that takes 10 seconds to transfer would according to the graph take about 10 years to transfer. Since we know that is not the case, let me suggest the possibility that the presence of NIS impinges on the data collection process so that you do not get accurate before-and-after pictures. Personally, I would not be surprised if throughput time doubled or tripled for some files no matter what security system you have. After all each bit has to be sidetracked, strings analyzed, then the bits put back into the flow to the other end of the transfer. Essentially, one action per moment becomes three actions per moment. There is no way this cannot have a significant impact on transfer speed, regardless of the analyzing product.
On the other hand, if the timings reflected the immense difference suggested by the graphs, then the throughput problem would be immense.
I think we need better data here.
I agree with that picture I posted does not give an accurate measure of transfer speed, and I guess I should have posted another picture showing slowdowns incurred with NIS2010 installed; however, my intent was not to demonstrate transfer speed, but to quickly illustrate the average LAN bandwidth utilized during transfers with and without NIS2010 installed.
Your statement referring to "throughput time doubled or tripled for some files no matter what security system" is installed is a bit short sighted. I know of 2 security suites that do not incur such a penalty when transferring files to a NAS, but since this is a NIS/NA forum, I thought it best not to mention them.
11-02-2009 06:45 PM
skypx wrote:
Your statement referring to "throughput time doubled or tripled for some files no matter what security system" is installed is a bit short sighted. I know of 2 security suites that do not incur such a penalty when transferring files to a NAS, but since this is a NIS/NA forum, I thought it best not to mention them.
I'm sorry, but I don't get it. The only thing that would keep throughput time to a minimum would be to selectively not examine certain files. Now that would make sense. Certain files, based on their associations, could be eliminated as immediate threats. For example, a file called "IMGOOD" without any extension cannot be an immediate threat and there would be every reason to release that file for immediate transfer. On the other hand, if some other application were to search out IMGOOD and rename it to IMGOOD.reg, it could become a real problem. I have no idea at all what Norton's strategy or logic is on this; I'm only mentioning it to show the problems of maintaining security.
On the other hand, having admitted to not knowing Norton's strategy here, it is possible that every file most pass through Norton's tube whether it is a threat or not. That would mean Norton has to grab a byte, hand the byte on, release it, and have it sent on its way. That's an engineering concern; and I need to stay out of that one, not knowing the real process.
But I will agree that it could severly crimp the works. A slow-down of a factor of 4 or more has a real impact on any system that is constantly passing data on. I'd be interested in what comes back to us. Unfortunately, we get little information about the engineering logic, and that's what interests me the most.
11-02-2009 07:03 PM
mijcar wrote:I'm sorry, but I don't get it. The only thing that would keep throughput time to a minimum would be to selectively not examine certain files. Now that would make sense. Certain files, based on their associations, could be eliminated as immediate threats. For example, a file called "IMGOOD" without any extension cannot be an immediate threat and there would be every reason to release that file for immediate transfer. On the other hand, if some other application were to search out IMGOOD and rename it to IMGOOD.reg, it could become a real problem. I have no idea at all what Norton's strategy or logic is on this; I'm only mentioning it to show the problems of maintaining security.
Ah... Excellent point! Obviously further testing is needed, more specifically is the transfer speed the same with the .mov file I mentioned earlier, after renaming the extension. I will post the results as soon as I'm finished. Thanks for the suggestion.
11-02-2009 07:31 PM
skypx wrote:... is the transfer speed the same with the .mov file I mentioned earlier, after renaming the extension. I will post the results as soon as I'm finished. Thanks for the suggestion.
I will look forward to the report.
The strategy reminds me of a host site I once used that wouldn't let me upload exe files, but allowed me to rename files after they been uploaded. Well, that was a pointless restriction of theirs.
11-02-2009 08:10 PM
mijcar wrote:
I will look forward to the report.
My tests have been completed. For the tests I used a 961MB .mov file. The extension was renamed .old to complete the second half of the test. All tests were conducted twice, once with NIS2010 installed, and the other without. Screen shots were taken half way through the transfer.
With NIS2010 installed .mov file.
With NIS2010 installed .old file
Without NIS2010 installed .mov file
Without NIS2010 installed .old file
Based on my results I can infer the extension has no effect on the transfer speed. All LAN traffic is monitored although the NAS was added to the "Trusted" device list in NIS2010.
