This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

"Client terminated connection early"

Hi there!,

 

  

So when I send the EICAR file for example, it says that my client disconnects (It doesn't.)

 

But some other files that I send DOES not say that the client disconnects and continues either clearing the file or marking it as a violation.

Which should exclude any syntax related errors.

 

This pattern is consistent as well. The same file works each time, and each file that doesn't work, never work.

 

 

In wire shark I can see that the server returns;

500 Server Error

505 Unsupported Protocol or Version

 

 

Why is it saying that the client is disconnected on certain files? And how do I stop it?

 

Any ideas?



This thread was automatically locked due to age.
Parents
  • Hi Jeff,

    In your savdid.conf please can you check the scanprotocol section to see if SUBDIR is specified? 

    Regards,

    Stephen

  • Yes, and I've tried with DIR as well.

  • Hi Jeff,

    Are you able to share your SAVDID Conf file please?

    Please can you also confirm how you are sending the files for scanning/which ICAP client you are using?

    Regards,

    Stephen

  • # No of worker threads to start up
    threadcount: 8
    maxqueuedsessions: 4


    onexception: REQUEST  
    onrequest: SESSION

    log {
    type: FILE
    logdir: C:\ProgramData\Sophos\SAV Dynamic Interface\Logs\
    loglevel: 3
    }

    channel {


    logrequests: YES

    commprotocol {
    type: IP
    address: xxxxxxxx 
    port: 1344
    sendtimeout: 2
    recvtimeout: 2
    }

    service {
    name: avscan
    type: avscan

    scanprotocol {
    type: ICAP
    allowscanfile: SUBDIR (Have tried with removing completely, subdir and dir)
    version: 1.01
    allow204: YES
    tmpfilestub: C:\ProgramData\Sophos\SAV Dynamic Interface\Temp\icap_
    }

    scanner {
    type: SAVI
    inprocess: YES
    savists: enableautostop 1 savigrp: grpsuper 1
    }
    }
    }

     

    My message from the wirecap.

     

     

     

    Here's the wirecap:

     

     

    And as you can see, there's no disconnect of the client, only after I receive the Server Error from the server. [Last entry]

  • It only seems to affect normal files. (.exe, .com, etc)

    Does not affect .zip or .rar files. They work fine.

  • Here are some comments from one of my colleagues:

    • ‘threadcount’ is set to 8.  We recommend that you have no more than 2x the number of cores on the system for ‘threadcount’.  Is this a 4 core system?
    • The ‘loglevel’ set to 3 which is not a valid value.  You can have 0, 1, or 2.
    • Unlikely it’s the issue, but it might be worth increasing the value of ‘recvtimeout’ just in case the connection is being closed because the sending client is taking big pauses whilst sending and hitting this timeout.
    • In the ‘scanprotocol’ section there is an entry for ‘allowscanfile’.  This is not an option supported by ICAP.  ICAP only supports scanning file streams, it does not provide the facility to instruct the scanner to scan a file by path.
    • The ‘scanner’ section appears to have all the scanning options on one line, that may be a copy/paste error but just in case, each option must be on a line of its own

     

    • Looking at the wireshark image the data string is definitely not eicar. It shows as a file called ‘note.pdf’, so if you have created a PDF file that contains the eicar string then no, this will not get detected.  Our detection of eicar is specifically against the actual eicar test file (eicar.com), we do not have detection that looks for the eicar string in every other file type.
  • Addressing them in numbers;

    1. It's a 2 core system. We changed to 4. Still the same problem though.

    2. We tried to get more debug logs while trying to identify the problem, trying to fix it ourselves. (a lot companies hide additional logs that way) Too bad you didn't.

    3. Tried with >60, but nothing changed. 

    4. We've now tested without, and it's still the same problem.

    5. Copy-paste problem.

    6. Sure, sorry about the confusion. Yes, it's the EICAR-String, (check the hexa-data). But that's simply because we've tried with different file-endings (in this case, .pdf), just to find SOMETHING else, other than the 500 server error.

    The only files that reports a VIRUS is [note2.zip] and [note2.rar] (CONTAINERS). Which both contain the [note.exe], (which contain the eicar-string).

     

    So. 

    We've been stuck here since the 8th.

    Getting kinda tired of this.

  • Hi Jeff,

    I appreciate this is frustrating, have you created a support case? We can escalate your ticket and add steps, but we may well need to involve development. 

    In the meantime, have you run this test locally on the server that is running SAVDI? I wonder if the configuration of Sophos AV is only looking at archives and we need to check that configuration rather than the SAVDI config.

    Stephen

  • Yes please!

    Did not know we could create a support case. Please do!

    Ok.

  • Please send me your support case id when you have created it. bottom right of the screen if you've not done this before.

    Stephen

  • Thanks Jeff,

    Are you able to confirm if you can run these tests locally on the server and remove SAVDI from the equation? 

    Regards,

    Stephen

Reply Children
  • It actually works fine locally.

    Even normal files [eicar.com] and also archives.

    So it seems to be SAVDI related.

  • Hello,

     

    We have this kind of issue with our system,.

    Can you tell me what are the modifications you have made please ?

     

    Regards,

    Xavier

  • Hey Xavier, 

    I'm sorry, it was some time ago.

     

    But I remember I ended up solving it by modifying our ICAP Encapsulated lengths.

     

    "

    Encapsulated: req-hdr=0, res-hdr=X, res-body=X

    "

     

    My implementation miscounted one '\r\n' into the wrong section.

    Which made SAVDI miss-parse.

    Which made the SAVDI disconnect. (Thanks for the wonderful logging Sophos)

     

    As for why only zipped files worked, I have no idea. 

    But if you have problems, be sure to look into making sure the lengths are correct.

     

    I've implemented a few other providers as well, and a few actually count these differently (don't ask me why).

    Had to add two different options for counting, one that added 2 in length of the encapsulated data length in the response. (res-body)

    I have this option enabled for Sophos. 

    So look into adding 2 in the length of the encapsulated data. Maybe that works.

     

    Good luck!