Scanning transfers for malware with an antivirus (ICAP)

From version 8.12.0, Syncplify Server! can hand the files that pass through a virtual site to an antivirus engine and act on its verdict: a file the engine rejects is refused, on SFTP, SCP, FTP, FTPS and in the WebClient!. The engine is asked over ICAP, the protocol antivirus and data loss prevention products offer for exactly this purpose.

This page is for whoever has to put that into production. It works the same whether Syncplify Server! runs on Windows or on Linux, and with any product that speaks ICAP. It explains how the pieces fit, what to find out about your scanner before you rely on it, and how to check for yourself that nothing gets through unscanned. If you do not own a scanner yet, the companion page Building a free ICAP scanner with ClamAV and c-icap builds one step by step.

Requirements

Content scanning needs Syncplify Server! 8.12.0 or newer and a Professional or Ultimate license (it is also available during a trial). In a high availability cluster, every node must run 8.12.0 or newer before scanning can be switched on: an older node would serve files unscanned.

How it works

1. A client uploads a file. Nothing is added while the file is being received, so the transfer runs at the speed it always did.
2. When the upload ends, the server sends the complete file to the scanner.
3. The scanner answers: clean, or rejected.
4. A clean file is kept and the client gets its normal final answer. A rejected file is removed, and the client is told why.

Three things follow from this design, and they shape everything else on this page:

• Syncplify Server! is the ICAP client. Your antivirus product is the ICAP server, called the scanner from here on. The scanner is a network service: it can run on any machine the server can reach, on any operating system. A Syncplify Server! on Windows uses a scanner on Linux, and the other way around, with no difference at all.
• Nothing is installed on the server. The antivirus that protects the operating system of the server's own machine plays no part in this, unless that product also offers an ICAP service.
• The client waits for the verdict. The final answer of an upload comes after the scan, so the time your scanner needs is time your users wait. See how long a scan takes.

The words you will meet

Term	What it is	Why it matters to you
Address	icap://host:port/service. Port 1344 is the standard ICAP port and may be left out.	It is the one thing you type into the Admin UI.
icaps://	The same protocol inside TLS. Port 11344 is what most vendors use for it, and what the server assumes when you leave the port out.	ICAP by itself is clear text: without TLS, every file travels to the scanner unencrypted.
Service name	The last part of the address. One scanner can offer several services on one port, and every product names its own.	A wrong name gets you an error, or worse, a service that answers and does not scan.
Method	RESPMOD or REQMOD. ICAP was designed for web proxies, so a file travels dressed up either as a web server's response or as a browser's request.	Antivirus products expect RESPMOD. Some data loss prevention products want REQMOD. Use what your product documents.
Preview	The server first sends the beginning of a file. The scanner may decide on that alone, or ask for the rest.	It saves time on files the scanner does not want to see. You never have to configure it.
Definitions tag	A label (ISTag) on every answer of the scanner, which changes when the scanner's state changes, for example when it loads new signatures.	When it changes, the server tests the scanner again, and can forget the verdicts it remembered.
Connection limit	How many connections the scanner accepts from one client (Max-Connections). Many products do not announce one.	It bounds how many files are scanned at once. See connections.

How a verdict is read

Every vendor signals a detection in its own way. Syncplify Server! understands the ones in use:

• Clean: the ICAP answer 204, or the file coming back exactly as it was sent (the server compares it).
• Rejected: the ICAP answers 403 or 201; a block page; any of the headers X-Infection-Found, X-Virus-ID, X-Virus-Name, X-Violations-Found, X-Response-Info: Blocked or X-Blocked; or a file that comes back changed. A scanner that repairs or redacts a file has rejected it, because the file on your storage is the one that was sent.
• Anything else, such as an error status, is not a verdict, and the file is refused.

The name of the threat is taken from those headers when the scanner sends them. Some products send them only when a setting is switched on, so look for that setting if your log shows rejections without a name.

What to find out about your scanner

Open your product's documentation and find these ten things before you open the Admin UI.

#	Question	Where the answer goes
1	What is the address: host, port and service name?	The Address of the scanner.
2	Which method does the service expect?	The Method of the scanner.
3	Does it offer ICAP over TLS, on which port, and with which certificate?	An icaps:// address, and the Certificate authority when the certificate is not one the system already trusts.
4	How many simultaneous connections does it accept, and is it licensed by connection?	Connections.
5	Does it send the name of the threat in its answer, or must that be switched on?	Nothing to enter, but your log is far more useful with it.
6	What is the largest file it scans, and what does it answer for a larger one?	Largest file to scan.
7	Does it scan every file type, or only a list?	The scanner's own settings.
8	Archives: how many levels deep and how many files does it open, and what does it do with a password protected archive?	The scanner's own settings.
9	What does it answer when its engine fails or runs out of time?	The scanner's own settings.
10	How does it load new signatures, and does it stop answering while it does?	Your choice of one scanner or two.

Questions 6 to 9 are the ones that decide whether your scanning is real.

A file the scanner did not look at is answered like a clean file

Every engine has limits, and that is fine. What matters is what the product does at the limit: does it block the file, or pass it? A scanner that passes a file it never looked at sends the same answer as for a clean file. No ICAP client can tell the two apart, and neither can the test in the Admin UI, whose two files are a few dozen bytes each.

This is not a theoretical concern. With ClamAV behind c-icap exactly as the Linux distributions package them, all of the following were answered as clean in our tests. Each of the first four carried a test signature that the same scanner reported at once in a small file:

• a file larger than 5 MiB, through one of the two service names the package offers;
• a PDF, a PNG picture and an MP4 video of any size, because the service scans only the file types on a list and these are not on it;
• any file larger than 100 MB;
• a ZIP archive inside four other ZIP archives;
• a password protected ZIP archive, which no engine can look into.

The companion page deals with each of these. Commercial products have settings of the same kind, and their defaults go both ways. Three examples, from the vendors' own documentation at the time of writing:

• Symantec Protection Engine denies by default a file that exceeds one of its limits.
• ESET Server Security for Linux has a switch, Block non-scannable files, that must be turned on for it to deny the files it cannot scan.
• Fortinet FortiSandbox answers 204, the answer for a clean file, when its verdict times out.

Whatever limit you find, tell Syncplify Server! about it. Set Largest file to scan at or below the scanner's own size limit. A larger file is then never sent: the server itself accepts it and records it (event 4111), or refuses it, as you choose. Either way you know which files went unscanned, which is exactly what a scanner that passes them silently takes away from you.

Addresses of some products

Use this table to recognize what you are looking for. It was put together from each vendor's documentation in November 2026; names and ports change between versions, so confirm yours against the documentation of the version you run.

Product	Its ICAP service runs on	Address, as documented
ClamAV behind c-icap	Linux	icap://host:1344/scanall with our setup
Symantec Protection Engine	Windows, Linux	icap://host:1344/SYMCScanRespEx-AV; TLS on port 11344
OPSWAT MetaDefender ICAP Server	Windows, Linux	icap://host:1344/OMSScanResp-AV; TLS on port 11344
Kaspersky Scan Engine, ICAP mode	Linux	icap://host:1344/resp
ESET Server Security for Linux	Linux	icap://host:port/scan
Bitdefender GravityZone Security for Storage	Its Security Server	Service name bdicap, port 1344; TLS on port 11344
Trend Micro Deep Discovery Analyzer	Appliance	icap://host:1344/response; icaps://host:11344/response
Fortinet FortiSandbox	Appliance	Service name respmod, port 1344; TLS on port 11344

Where the scanner runs

Because the scanner is a network service, the operating system of your Syncplify Server! does not limit your choice. What you need is a product whose ICAP service runs somewhere your nodes can reach.

• You already own an antivirus with an ICAP service. Use it. Ask your vendor which of their products carries the ICAP service: it is often a separate product from the one installed on desktops, sold for scanning storage systems and gateways.
• You want a free scanner. ClamAV is free and capable. It needs an ICAP server in front of it, and the one we tested, c-icap, runs on Linux: Building a free ICAP scanner with ClamAV and c-icap.
• Your environment is Windows only. You have two good options. The first is a product whose ICAP service runs on Windows, as the documentation of Symantec Protection Engine and of OPSWAT MetaDefender ICAP Server says theirs does. Microsoft's own documentation describes ICAP scanning with the Microsoft Defender Antivirus engine through MetaDefender ICAP Server. The second is to run the ClamAV scanner of the companion page on one small Linux virtual machine next to your Windows servers. ClamAV itself has Windows builds, but we know of no maintained ICAP server for Windows to put in front of it.

Wherever it runs, place it with these four points in mind:

1. Close to the server. Every scanned file is sent to the scanner in full. A scanner on the other side of a slow link turns every upload into a second upload.
2. On its own machine, in production. Scanning is hungry for processor and memory. A scanner on the server's own machine works, but the two then compete exactly when the server is busiest.
3. Reachable from every node. In a cluster each node connects to the scanner itself.
4. Reachable from nothing else. ICAP has no authentication. Anyone who can reach the port can use your scanner, so restrict it to the addresses of your nodes, in the scanner's own access list when it has one and in the firewall in any case. Use icaps:// unless the network between the server and the scanner is one you fully trust: without it, your users' files cross that network in clear text.

To check that a node can reach the scanner, run one of these on the node:

nc -vz scanner.example.com 1344

Test-NetConnection scanner.example.com -Port 1344

Add the scanner and test it

1. In the Admin UI of the virtual site, open Content scanning.

2. Click Add a scanner.

3. Give it a Name, and enter its Address, for example:

   icap://scanner.example.com:1344/scanall

4. Choose the Method your product expects. For an antivirus that is RESPMOD.

5. For an icaps:// address whose certificate was issued by your own certificate authority, paste that authority's certificate into Certificate authority (PEM). The name in the address must be a name the scanner's certificate was issued for. Accept any certificate the scanner presents switches the check off and is for a first trial only.

6. Click Test. The server does what it will do every time before it trusts this scanner:

   • it asks the scanner what it offers, and checks that the method is among it;
   • it sends a small harmless file, which must pass;
   • it sends the standard antivirus test file (the EICAR file, which every engine reports by agreement although it is harmless), which must be rejected.

   The report also shows what the scanner announces about itself: its methods, its preview size, its connection limit and its definitions tag.

7. When the test passes, click Apply, switch Scan the files of this site on, and save.

A scanner that passes the antivirus test file is not used. That is deliberate: a scanner that lets everything through looks perfectly healthy, which makes it the most dangerous way for scanning to fail. If your service is not an antivirus, for example a data loss prevention engine, it has no reason to object to that file: switch on This service is not an antivirus for it, and the server marks it with Test file check skipped wherever it is shown.

The test runs from the node whose Admin UI you are using. In a cluster, test from each node. The Status panel at the top of the page then shows, for every node, whether each scanner is in use.

Prove that it scans what you think it scans

The test in the Admin UI proves that the scanner is alive and detecting. It cannot prove that the scanner looks at large files, at archives, or at every file type. Before you go live, make these uploads yourself, as an ordinary user, with an ordinary client:

#	Upload	What must happen
1	The antivirus test file.	Rejected.
2	A ZIP archive that holds the test file.	Rejected.
3	A ZIP archive that holds the test file next to a file large enough to make the archive bigger than every size limit you found in question 6.	Rejected, or handled by Largest file to scan the way you chose. Never simply accepted.
4	A password protected ZIP archive of any harmless file.	Whatever you decided in question 8. Know the answer before a user asks.
5	If you scan downloads: copy the test file onto the storage directly, without going through the server, and download it.	Refused.

Every rejection must also appear in the log as event 4110, with the name the scanner gave.

The test file can be downloaded from the EICAR website. Expect the antivirus on your own workstation to object to it, and to the archives you build around it: that is the same file doing its job. Build them on a machine where you are allowed to.

For upload 3, the large file must be one that does not compress, or the archive will stay small. On Linux:

head -c 150M /dev/urandom > filler.bin
zip big-test.zip eicar.com filler.bin

On Windows, use any archive tool and add a video or a disk image as the large file; both are already compressed.

Upload 3 is the one that catches people. With the packaged ClamAV and c-icap settings, the archive built by these two commands was accepted in less than half a second. With the settings of the companion page it was rejected.

Decide before you go live

All of these are on the Content scanning page.

When no scanner can judge a file. By default such a file is refused. Nothing gets in unscanned because the scanner is down, and the price is that uploads fail for as long as it is down (FTP clients are answered 451, which invites them to try again later). You can choose to accept those files instead; each one is then recorded as event 4111. If you want neither, add a second scanner.

A second scanner. Up to four scanners can be listed. With Always ask the first one that is available, the second takes over when the first stops answering. With Spread the files over all of them, they share the work. Two scanners also let you update or restart one of them without your users noticing.

Largest file to scan, and what happens to a larger one. Set it at or below your scanner's own limit, as explained above. Then decide: accept larger files and have each one recorded, or refuse them.

Verdict wait. A scanner has 120 seconds by default to answer once it holds the whole file. That is enough for most files and not enough for some archives: see the figures below. A scan that runs out of time counts as a file no scanner could judge. Raise the value if your users send large archives; it can go up to an hour.

Scan downloads too. By default only uploads are scanned. Scanning downloads as well covers the files that were on the storage before you switched scanning on, the files that reach it some other way, and the files that were clean by last week's signatures. A stored file that is rejected is refused and reported, and never deleted. A verdict is remembered while the file stays the same (24 hours by default), so a file is not scanned again at every download.

Hold uploads until they are scanned. On a disk, a file shows under its name from its first byte. With this setting an upload stays under a hidden name and appears under its real name only once it is clean, so no other user and no program that watches the folder ever sees an unjudged file. With New files and overwrites, a rejected replacement also leaves the previous file untouched. One thing changes for your users: an interrupted upload of a new file cannot be resumed and must be sent again.

Excluded paths and exempt accounts. You can leave paths out of scanning, and exempt single accounts in their profile (Skip content scanning), for a trusted machine account that moves very large files. Two cautions. An excluded path is a path as each user sees it, so it applies in every user's folder tree. And a file that is renamed or moved out of an excluded path afterwards is not scanned at that moment; only download scanning looks at it later.

Ban repeat offenders. The Shield has a rule for addresses that keep uploading rejected files, Malware uploads. It is off until you switch it on.

Tell the scanner who is transferring. When this is on, the client's address and the account name travel with each file, and appear in the scanner's own log next to its detections.

Connections

Connections, in the scanner's entry, is how many connections each node keeps to that scanner for this virtual site, and so how many of its files are scanned at once. Left at zero it is 32, or fewer when the scanner announces a lower limit of its own.

Count all of them together: connections, times the nodes of your cluster, times the virtual sites that use the same scanner, must not exceed what the scanner can serve at once. A scanner that is asked for more than that makes the extra files wait, and a file that waits too long counts as one no scanner could judge.

How long a scan takes

The wait at the end of an upload has two parts: the server reads the file back and sends it to the scanner, and the scanner does its work. The first part is small. On a test machine with everything on one host it was 0.4 seconds per GiB. On remote storage (a remote SFTP server, R2FS!) the file is read back from the remote side, which takes as long as downloading it.

The second part is your scanner's, and it depends on what the file is far more than on its size. These are our figures for ClamAV on one desktop class machine, with nothing else running:

File	Time to a verdict
1 GiB of very regular data	4 seconds
64 MiB of data that does not compress	2 seconds
1 GiB of the same	30 seconds
2000 MiB of the same	1 minute
A 150 MiB ZIP archive of two files	10 seconds
A 78 MiB ZIP archive of a source code tree, 17,000 files	1 to 2 minutes
A 2 MiB ZIP archive of 9,000 small text files	40 seconds to 1 minute

Your scanner will have other figures; measure them with your own files. The lesson of ours is general, though: archives with many files take the longest, whatever their size, and the number of files a user packs into an archive is not something you control.

What this means for your users:

• Some clients give up when the final answer of an upload does not come within their own timeout. The file is then judged all the same, but the user sees an error. If your users move large files or large archives, raise that timeout in the client.
• Machine accounts that move very large files on a schedule are the usual candidates for an exemption or an excluded path.
• A size limit caps the wait, at the price of files that are not scanned.

What your users see

Nothing changes while a file is being transferred. A file is judged when its upload ends, and the client gets its final answer after the verdict.

Protocol	When a file is rejected
SFTP	Closing the file fails with the message below.
SCP	The transfer ends with that message and a nonzero exit status.
FTP, FTPS	550 with that message, in place of 226.
WebClient! and shares	That file is reported as refused, in the user's language. The other files of the same upload are not affected.

the file was rejected by the content scanner: Eicar-Signature

The last part is the name the scanner gave. A rejected upload is removed from the storage by the server itself; the account does not need the permission to delete. A rejected file is not quarantined.

When no scanner could judge a file and the site refuses such files, the message is the file could not be scanned and was refused, and FTP answers 451.

Day to day

• The Status panel of the Content scanning page shows each node's view of each scanner: Ready, Not answering, Failed its self test or Not tested yet, with the number of files judged and rejected.
• A scanner that stops answering is taken out of use after three attempts, tried again every 30 seconds, and put back as soon as it answers and passes the test again. An outage therefore costs one attempt every half minute, not a timeout per file. The console raises a notification, and the log carries event 9080 (scanner unavailable) and 9081 (back in use).
• The self test runs again whenever a scanner comes back and whenever its definitions tag changes. A scanner that fails it is not used, is tested again every five minutes, and is reported with event 9082.
• Events worth an alert: 4111 (a file was accepted without a verdict), 4112 (a file was refused because no scanner could judge it), 4113 (a rejected file could not be removed and is still on the storage), 9080 and 9082. Event 4110 records every rejected file. All of them can be delivered by webhook like any other event.
• Signatures. An antivirus is as good as its signatures are recent. Check how your product updates them and how you would notice if it stopped.
• The scanner's own log is where you find out what the scanner did with a file. The two files of the self test appear there as content-scan-probe.txt and antivirus-test-file.com.

When the test fails

The test says	What to do
The scanner could not be reached.	Nothing answered as an ICAP service at that address. Check, in this order: the host name and the port; the firewall between this node and the scanner, with the commands above; the scanner's own access list, when it refuses a client by closing the connection; that an icap:// address does not point at the TLS port, nor an icaps:// address at the plain one; and with icaps://, the certificate.
The scanner answered with an error. Check the service name in the address.	The service name is wrong (a scanner answers 404 for a service it does not have), or the scanner's access list refuses this node (403).
The service does not offer the configured ICAP method.	Switch the method, or check the service name: some products have one service per method.
The scanner rejected a harmless file, so it would reject everything.	The service refuses everything, usually because of a policy or an access rule on the scanner.
The scanner accepted the standard antivirus test file, so it is not scanning.	The address names a service that is not the antivirus (many ICAP servers ship with an echo service for testing), or the engine or its signatures are not loaded.
The scanner did not answer in time. The connection to the scanner broke during the test.	The scanner took the request and then failed on one of the two test files. Its own log for that moment says why.
This entry cannot be used as it is. Check the address and the certificate authority.	The address must start with icap:// or icaps://, and the certificate authority must be a certificate in PEM format.

A certificate problem shows as The scanner could not be reached. The usual causes are a missing certificate authority, and an address that uses a name or an IP address the scanner's certificate was not issued for.

More

• Building a free ICAP scanner with ClamAV and c-icap.
• The manual has the complete reference: every setting, what happens to a file on each kind of storage, the events, and the OnContentRejected event handler: Content scanning.