"Client terminated connection early"

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.

Any ideas?

Come on Sophos.

Don't make us switch to ESET.

We're stuck here.

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

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

OK, thanks. #8469582

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

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!