Jump to content

Feature Request: Reduce loading overhead of Command Line Scanner (cls)


Recommended Posts

When using the Command Line Scanner (cls) to scan individual files while being uploaded to a server (we need to invoke the scanner for each file so we can reject an upload and abort an associated DB transaction), cls takes a few second to load all it's data/dictionaries/etc.

It would be better if cls supported streaming the file via the already loaded scanning daemon, or could spawn a shared scanning daemon, so as to avoid reloading all the data each time. The lack of this functionality adds significant overhead when processing a lot of files (which our systems do daily).

clamav supports this functionality using "clamdscan" instead of "clamscan. It would be good if ESET could support this as well.

Link to comment
Share on other sites

  • Administrators

This is not a proper use of the command line scanner. For the purpose of scanning uploaded files API should be used instead. Please contact your local ESET distributor for more information.

Link to comment
Share on other sites

I think maybe you mean "not intended" instead of "proper". However, I don't see much other purpose for the command line scanner if it isn't to scan files and get the results. What would the command line scanner be for if not that? Wanting it to be efficient and work with the already loaded scanning system is hardly anything special -- things like this have been around for decades. 

This is a "server product" right? It should support automation and integration into local tooling...

Can you point me to the ESET API documentation? Contacting a distributor is not normally how ones get information about APIs, nor an approach that I would deem useful. It would likely take weeks to get any form of answer. 

The only documentation I can find is related to the Server_API for interacting with the management center, which is not at all useful for what we want. Is there some other API  hidden away?

Also, using an API is highly non-flexible or generic for integration into other tooling. Basically we would end up writing a command line scanner tool to scan the file via the API -- which sounds an awful lot like what's already there...

Link to comment
Share on other sites

  • Administrators

The purpose of the on-demand scanner is to scan local disks and folders. A full disk scan is not typically done more often than once a week or month. The on-demand scanner was not designed and is not licensed for continual scanning of files.

As for API, please refer to https://www.eset.com/int/business/partner/anti-malware-sdk/. Please contact sales for more information as suggested.

Link to comment
Share on other sites

And that's exactly what I'm using the CLS for -- scanning a file on a local disk. There is nothing about the license that says I cannot scan files on my disk at will with the command line scanner. This is a server product for a *nix platform. This is exactly the sort of thing many system admins would want to do.

I just want to integrate the scanner I already have into a product I already have (as I have with so many other scanning products in the past). Why have a command line scanner if you cannot scan files with it?! I don't want to be developing custom products and developing solutions for others and deploying them. The API is not where I want to go, nor does it make logical sense for what we are doing. Maybe it's all you have to offer, that's why this is a "feature request". 

It sounds more like ESET is not the right product for *nix server solutions and I would be better off with other solutions like clamav (which seem to understand the *nix solution space better - they aren't good for "end-users" though).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...