ICAP Problem with Encrypted Files

Hello sebastian schröder,

I think I don't quite understand. block-encrypted but that dont trigger - then where's the Quarantined A0040212 File was encrypted from? Was this on-access scanning during an attempt to store this xlsm on the Isilon and isn't A0040212 the desired result?

SAVDI/ICAP returns the Engine and VirusData version and the number of IDEs in the response to OPTIONS. Dunno if this helps.

Christian

Hello sebastian schröder,

I think I don't quite understand. block-encrypted but that dont trigger - then where's the Quarantined A0040212 File was encrypted from? Was this on-access scanning during an attempt to store this xlsm on the Isilon and isn't A0040212 the desired result?

SAVDI/ICAP returns the Engine and VirusData version and the number of IDEs in the response to OPTIONS. Dunno if this helps.

Christian

The Problem is, SAVDI/ICAP set xlsm or other encrypted Files in Quarantine and users cant access these data again. (Scan-On-Close)

SAVDI should dont set Files in Quarantine he cant scan e.g. encrypted - i use:

block-encrypted: YES

..but it´s dont working for me.

How can i show the VirusData Version with savdid on Windows?

thx!

Hello sebastian schröder,

as far as I understand it block-encrypted means: If a file is encrypted we can't scan it and as it is potentially harmful deny access to (i.e. block) it. BTW: There was (is?) n issue where files are blocked even when the option is not enabled.

Where/how do you want to show the VirusData Version, do you want to process it programmatically? Unless you tweaked the installation it uses the data from the SAV installation, the SAV GUI provides this information. Just curious - for what purpose do you need this information?

Christian

Hi Christian,

i used uselean204 in my config and block-encrypted yes. but the scanner set a harmles xlsx in quarantine.

Same issue when i start with block-encrypted:no.

I dont need this information, but it ll be nice to. our last icap scanner show the definitions on the isilon - i used this to monitor the icap servers - nice feature but not rlly needed.

regards

MY ICAP CONF:

# Define a channel for ICAP over IP





channel {
        # Send to the log requests received from clients
        # For debugging. Default: NO
        # logrequests: YES
    commprotocol {
        type: IP
        # IP Address to listen on, default is 0.0.0.0 (any)
        # address: 127.0.0.1
        port: 1344
        # Subnet of acceptable client IP addresses.
        # Default is to accept from any client.
        # subnet: 127.0.0.1/24
        # idle timeout in secs when waiting for a request
        # 0 is forever. Default: 0
        requesttimeout: 120
        # timeout in secs between characters when sending data
        sendtimeout: 2
        # idle timeout in secs between characters when receiving data
        recvtimeout: 30
    }
    service {
        # The name of the service, arbitrary as long as the client
        # uses the same name.
        name: avscan
        # The type of service, for now can only be avscan
        type: avscan
        scanprotocol {
            # The type of protocol in use. Can only be ICAP.
            type: ICAP
        # community.sophos.com/.../125689
        useclean204: YES
            # Version of the configuration for this service.
            # Update when changes are made that may alter the
            # result returned to the client. Default: XXX
            version: 1.01
            # Objects sent for scanning can be retained if they are
            # infected or cause the service a problem. Allowed values
            # are NONE, MALWARE, PROBLEM, ALL. ALL meaning both
            # MALWARE and PROBLEM. Default: NONE
            # retain: NONE
            # A list of file extensions for files which the client
            # should not send to this server. The list is sent as-is
            # to the client. See ICAP Transfer-Ignore header. A
            # Transfer-Complete: * header is automatically added.
            # Default is none.
            # dontsend: .jpg, .gif, .bmp, .tiff
            # 204 is the ICAP code indicating that the object
            # sent for processing is unmodified and OK and will
            # not be returned to the client. Default: NO
             allow204: YES
            # Don't automatically close the connection after a
            # transaction. Default: NO
            keepalive: YES
            # Maximum permitted size, in bytes, of the body in a request.
            # Zero is no limit. Default: 0
            # maxbodysize: 0
            # Maximum amount of memory, in bytes, to use for an object, before
            # putting it into a temporary file. Default: 1000000
            maxmemorysize: 16384
            # Maximum size of the chunks, in bytes, for returned data, 0 is
            # no maximum. Default: 0
            # maxchunksize: 0
            # Where to place and name temporary files
            # Default: <standard temp directory>/SAVDI_
            # On *nix systems: /var/tmp/SAVDI_
            tmpfilestub: C:\ProgramData\Sophos\SAV Dynamic Interface\Temp\icap_
            # The block-* options determine what to do with files
            # that result in some sort of error.
            # Any of these files may be infected.
            # NB Files identified as malware are always blocked.
            # Treat zip-bombs as malignant. Zip-bombs are compressed
            # files that have many files which are vary highly
             # compressed. They are intended to either deny use of
            # a scanner by keeping it occupied for excessive periods
            # or use excessive resources, such as disc space on the
            # end-point. Default: YES
             block-bombs: YES
            # Block encrypted files. Encrypted files cannot be scanned
            # and may harbour malware. Default: NO
             block-encrypted: YES
            # Block corrupt files. Some files are simply corrupt, others
            # may not conform to the standard, or one of its known
            # variants, but may still be usable. Default: NO
            # block-corrupt: NO
            # Block timeouts. It took too long to scan the file and
            # the scan was terminated early. (See the maxscantime
            # option in the scanner section.) Default: YES
            # block-timeouts: YES
            # The AV engine returned some other error. Scanning of the
            # file possibly did not complete. Default: YES
            # block-errors: YES
            # The AV engine caused an exception. Exceptions can be
            # considered as errors that were not caught in time.
            # Scanning of the file did not complete. Default: YES
            # block-exceptions: YES
            # At least one client (c-icap) seems to always expect a
            # body, even an empty one. Default: NO
            # forceemptybody: YES
        }
        scanner {
            # See the SAVDI documentation for details for configuring
            # SAVI
            type: SAVI
            inprocess: YES
            # Turn on auto-stop, ie zip-bomb detection
            savists: enableautostop 1
            # Turn on most of the other options
            savigrp: grpsuper 1
            # Limit the time taken to scan a file to this number of seconds
             # Zero is forever. Default: 0
            # maxscantime: 0
        }
    }
}

Hello sebastian schröder,

the scanner set a harmless xlsx in quarantine
it's not the scanner but the Isilon (i.e. I assume the message in your OP is from the Isilon). The article suggests that with useclean204: YES and one or more of the block-xxxxx: options set to No you should get the desired results. Can't say why this should be necessary though.

As I work neither with SAVDI nor an Isilon my knowledge is very limited and naturally I can't test. SAVDI enquiries didn't get much attention here in the community but Support should be able to help - otherwise how did the article come into existence.

Personally I'd monitor the request/response using wireshark, it has dissectors for HTTP and ICAP. Apparently A0040212 is returned in the response. Can't say if this is expected with block-encrypted: No but nevertheless 204 should be returned and thus the file considered as clean.

Christian

Hi Christian,

i set all 3 options to No, block-error, block-encrypted and block-corrupt - now it acts like it should!


big thx - regards,

sebastian

ps: only block-encrypted with useclean204 dont work for me

Hello sebastian schröder,

good to hear it works.
Documentation is vague - you didn't trace the exchange, did you? I'm just curious whether ICAP correctly returns 204 with only block-encrypted: No and some additional information confuses the Isilon or ICAP returns 200 unless you also set block-errors: No (I guess it's only this option).

Christian