I just talked with Dave Zuckerman at Symantec (the guy whose number is on the press release).

Here's a little of what I found out:

- The product, CarrierScan, sits on a box, like an NT box. - RPC is set up between the NT box and the Filer (ontap 6.1) - Any time a new file is introduced, modified, etc, the file is piped to CarrierScan. CarrierScan scans the file (with Norton). - If the file is clean, a clean bit is set on the file so it won't be scanned anymore unless it's modified. - If the file is infected, the file is removed. - The end user simply sees "access denied" to the file.

I have a couple outstanding questions with them, like what CarrierScan's abilities and action "flow" is when it finds an infected file (send e-mail, send an snmp trap, etc), but all in all I'm kind of jazzed on it.

It's obviously not a cheap product, but it seems logical to have one central point to manage and protect against virii. Integration of that into an already central file storage system is icing.

Don't want to sound like an ad for Symantec, but this product seems damn cool so far, and it runs on both the filer and netcache. The two of them working together would make an enterprise pretty bulletproof.

jamie

We've (beta) worked quite a bit on the virus scanning feature in 6.1 with NetApp and are continuing work with a virus scan vendor beta. This is an area we put significant pressure upon NetApp and have been extremely involved with their response.

Here are some of our comments which are virus scan vendor in-specific.

On Wed, Apr 11, 2001 at 12:14:29PM -0500, jamie rishaw wrote:

• The product, CarrierScan, sits on a box, like an NT box.
• RPC is set up between the NT box and the Filer (ontap 6.1)
• Any time a new file is introduced, modified, etc, the file is piped to CarrierScan. CarrierScan scans the file (with Norton).

Not quite. Only the full path to the file is sent to the NT box. The NT box then uses a CIFS share to read the file from the filer. This means that the NT box needs to be given "Backup Operator" access to the NetApp at the least.

One concern in this area is the negative impact upon file serving to the end client. We have not put significant load on this solution yet to quantify this, although in testing it has been immeasurable. NetApp said that during their own testing they were amazed to see that virus scan products generally only need to read at most 30% of a file to determine if it is infected.

Another concern is what happens if the scanner is off-line and the file can't be scanned; does the user get the file or not? The answer is, its configurable. =) Yay! You can set a timeout value to define how long the filer will try to scan the file before giving up. You can also set what happens if it gets no response - go ahead and give the user the file, or be paranoid and deny access.

• If the file is clean, a clean bit is set on the file so it won't be scanned anymore unless it's modified.

Note that this "Scan Cache" is fairly limited in the initial release. It currently only keeps track of whether a file was scanned clean or not. The "not" side of that includes:

1) File has not been scanned. 2) File was scanned and is infected. 3) Tried to scan file but an error prevented scanning.

It also does not keep track of information such as:

1) Date/time of scan. 2) DAT version / Engine / Product scanned with. 3) Scanner host that performed scan.

These could be important if you want to rescan files with a new DAT or different product, rescan files that were originally scanned by a now un-trusted scanner host, or expire scan cache entries after a particular age.

The "Scan Cache" is not persistent across reboots. A reboot clears it and requires that previously "scanned and clean" files be rescanned.

All those negatives having been said, you can manually clear the Scan Cache in case of a DAT update. Further NetApp is aware of (in fact suggested) much of the functionality listed above so it seems likely this could all be subject to future enhancements. =)

• If the file is infected, the file is removed.

I'm not sure how Symantec's product works, but in general, it is up to the virus scan product to take action on infected files.

• The end user simply sees "access denied" to the file.

Again, this will vary from virus scan vendor to vendor.

I have a couple outstanding questions with them, like what CarrierScan's abilities and action "flow" is when it finds an infected file (send e-mail, send an snmp trap, etc), but all in all I'm kind of jazzed on it.

As far as action on the infected file, possible remedies are deleting it, quarantining it (rename or move), etc. These action will probably be whatever each virus scan vendor already provides and should be configurable.

As far as notification goes, it is a little difficult for the virus scan product to send a "You have a virus!" message to the client who actually tried to open the file. What they will see is whatever Windows and/or their application does when a file open() call fails - namely the "Access denied" dialog box. Some virus scan products have a greater framework that they attach to and the message could be bubbled up this framework to virus scan admins. Also, a message will likely appear in the filer's log file.

Unfortunately, all of this will vary from virus scan vendor to vendor. One possibility is that NetApp provides a way through the RPC for the scanner host (NT) to pass along a failure message detailing why it failed to the NetApp, which could then generate a winpopup on the client that asked for the file. That's up to NetApp though and would probably be a future enhancement. =)

It's obviously not a cheap product, but it seems logical to have one central point to manage and protect against virii. Integration of that into an already central file storage system is icing.

NetApps are an amazing vector for passing viruses around - it is great that this software will help prevent that from happening.

Don't want to sound like an ad for Symantec, but this product seems damn cool so far, and it runs on both the filer and netcache. The two of them working together would make an enterprise pretty bulletproof.

In general, the virus scan support in 6.1 is a welcome relief and kicks butt in its own right. That virus scan vendors are coming quick to market with solutions that plug into it is an added bonus. For a version one try at something that isn't extremely straight-forward, NetApp did a better than expected job from this customer's perspective.

So far, the biggest drawback is the 1-to-many relationship between scanner hosts and filers. A single filer can have many scanner hosts registered with it, but a scanner host may only register with one filer. This means you have to deploy at least the same number of scanning machines as you have filers (that need to be scanned).

As far as I know (and could be wrong), there is no technical reason that a scanner host couldn't register with multiple filers. The reason they haven't initially is because one filer can easily flood one scanner, therefore the thinking was that you would want more than one scanner per filer. Unfortunately this overlooks two aspects of the situation - redundancy and variable per-filer load.

First, if I have 10 filers and 10 scanners, if one of the scanners dies (NT boxes never die, right?), one filer cannot be scanned. If all 10 scanners could register with all 10 filers, then one scanner going down would only diminish my total scanning capacity by 1/10th - a much better situation. We'd rather have a redundant pool of scanners than dedicated scanners.

Second, not all my filers have the consistent load required to fully use an entire NT scanner box. Some filers have bursty load, some have consistent load, some have overall lots of CIFS clients, some have almost none at all. Without the ability for a scanner to register with multiple filers, I cannot leverage these load patterns in the design of our anti-virus infrastructure. Multi-registration could allow us to deploy 5-8 scanners for 10 filers in an intelligent manner based on the amount and type of CIFS traffic they deal with.

I hope this lengthy mail helps everyone get a better idea of what NetApp has done in the virus scanning for filers area. If anyone has other questions, we'll be happy to give our insight, but the SAG and NetApp Customer Support are always your best bet!

-- Jeff

-- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com