Rspamd: [BUG] Eset File Security 7.2 blacklists rspamd's ICAP-User-Agent

[ventulis]

Prerequisites

• [X ] Put an X between the brackets on this line if you have done all of the following:
  
  
  
  • Read about bug reporting in general: https://rspamd.com/doc/faq.html#how-to-report-bugs-found-in-rspamd
  
  
  • Enabled relevant debugging logs: https://rspamd.com/doc/faq.html#how-to-debug-some-module-in-rspamd
  
  
  • Checked the FAQs about Core files in case of fatal crash: https://rspamd.com/doc/faq.html#how-to-figure-out-why-rspamd-process-crashed
  
  
  • Tried ASAN package and obtained the ASAN report (if possible): https://rspamd.com/doc/faq.html#asan-builds
  
  
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=%E2%9C%93&q=is%3Aissue+user%3Arspamd
  
  
  • Checked that there is not already an experimental package or master branch
  
  

Describe the bug

The release notes of Eset File Security for Linux 7.2 mention that 'support' for rspamd has been 'removed'. Starting from this version users will get an "405 Forbidden Error" for every ICAP-Scan done by rspamd:

2020-09-22 17:12:34 #83140(controller) <174874>; lua; common.lua:107: eset (icap): result - FAILED with error: "ICAP/1.0 405 Forbidden - score: 0"

Cause of the Bug

Looking at EFS 7.2's /opt/eset/efs/lib/icapd library file you will find, that "Rspamd" is among the contained strings. Further Analysis (Ghidra) leads to the conclusion that the server contains a function that checks for the User Agent 'Rspamd'.
So in fact they did not "remove" support for rspamd but have blacklisted it's User Agent.

Possible Solutions

Since there are multiple approaches towards this issue, I did open this bug report to discuss possible solutions. We could:

1. Remove the User Agent, because it is not required by the ICAP protocol. This may require investigation whether other implementations uncompliantly require it.
2. Change the User Agent to something else for now; paired with the possibility that it will be blacklisted once again.
3. Set the User Agent to something less distinct that could be useful, p.e. hostname + version number.
4. Allow the administrator to change the default User Agent in the config to make it impossible to blacklist every possible one.

[vstakhov]

I would suggest to remove ESET support as an adequate answer. And write in social media about this company and their behaviour against open source software.

[andryyy]

What a dick move.

They should be lucky someone implemented their AV into Rspamd.

We should ask them why they did it.

[vstakhov]

I would suggest to ask eset about it anyway. If you are their customer and pay them money it is definitely not Rspamd issue to deal with their arrogant behaviour. I'm inclined to ban word 'eset' in Rspamd config, just because I can, lol.

[c-rosenberg]

They banned rspamd user agent in their file security. This is a per server licence (120€ for 5 servers). In the gateway security there is no ban. I would bet this is a per user licence and therefore much more expensive. I'm in contact with some of their sales guys somehow. Let's see what they are saying.

[vstakhov]

If they want to protect their product from misuse they should adjust their usage policy. Or let me know that this should also be adjusted on Rspamd side. I totally understand that business needs are the main priority for the commercial companies so I can assist from my side. But banning user-agent is just unprofessional and frustrating for their users. That's my 2 cents.

[ventulis]

I agree on the things you have proposed here.

This is a per server licence (120€ for 5 servers). In the gateway security there is no ban.

One should of course recognise that there are other Linux products by Eset that are licensed on a per user basis which have probably no ban of the rspamd user agent. But one should mention, that the "Gateway Security" product is stuck at version 4.5 while for "File Security" version > 7.0 is available; in my experience "Gateway Security" performs much worse. "Mail Security" is stuck at version 4.5 as well and would be no option for rspamd operators because rspamd is already doing most of the things that this solution would do much better.
So there are legitimate reasons besides trying to escape a per-user license model to operate the 'File Security'-ICAP-Server instead.
One should outline as well that ESET will take your money for up to three years in advance, which means that there may be operators out there which will have to deal with that problem for an extended period of time.

I'm inclined to ban word 'eset' in Rspamd config, just because I can, lol.

I would agree that regardless of any solution for this issue we should indicate Eset's attitude to potential operators. Unfortunately Eset's ICAP-Server does not provide any useful server agent to block it:

ICAP/1.0 200 OK
Methods: RESPMOD
Encapsulated: null-body=0
Preview: 16384
Transfer-Preview: *
ISTag: "d907f2511076a093-1600947274"
Max-Connections: 1024

The only pattern that I would consider quite unique enough could be the ISTag-Header, that consists of a 16 character hex string and a Unix time stamp. For the time being I have made a pull request to the documentation to make potential buyers aware of the fact.

But banning user-agent is just unprofessional and frustrating for their users.

I agree on that one. Any modification of rspamd's user agent would show them, that their 'move' was not a suitable solution.

---

Based on your feedback I would propose:

• To warn users about it in the documentation (see my pull request),
• regardless of this issue we could make rspamd's ICAP user agent more useful by adding for example a version number or config id. That would accidentially close this issue for now.

[vstakhov]

Any modification of rspamd's user agent would show them, that their 'move' was not a suitable solution.

That looks evil so I like it :) In fact, changing of User-Agent is trivial in Rspamd (see url_redirector plugin), so adding that to antivirus plugin is also trivial.

[fatalbanana]

Given "ESET File Security" or whichever is not suitable for our use because of some fine print - my inclination would be to remove all mention of said software from the documentation & make no efforts to help people continue using it.

[fatalbanana]

Exposing ability to set user-agent is fine I suppose but we shouldn't list this as supported software, particularly not with a link suggesting to change user-agent.

[andryyy]

Given "ESET File Security" or whichever is not suitable for our use because of some fine print - my inclination would be to remove all mention of said software from the documentation & make no efforts to help people continue using it.

Seconding this.

[ventulis]

Given "ESET File Security" or whichever is not suitable for our use because of some fine print - my inclination would be to remove all mention of said software from the documentation & make no efforts to help people continue using it.

I think it is more important to inform potential operators that Eset does not intend the use of that product with Rspamd and leave the fineprint to them. Not mentioning this issue at all may lead into people unnecessarily wasting time trying to implement it.

Exposing ability to set user-agent is fine I suppose but we shouldn't list this as supported software, particularly not with a link suggesting to change user-agent.

We are not suggesting anything. Informing potential buyers about the efforts made by Eset will most likely result in them making a different implementation choice, because future misoperation is apprehended.
Concerning this particular vendor we also discussed that Gateway Security would probably be supported.

[c-rosenberg]

In between Eset product management confirmed they have blacklisted rspamd because of some support issues and licence misuse. Also they said, the file security is not intended to be used to scan mails.

I asked for any alternative product - there is none.

Next to the Eset issue, we should maybe highlight in general that the support for AV products is the protocol support and it's not proven the licence for a product allows the usage with rspamd.

[vstakhov]

Yes that would be good @c-rosenberg. I just don't know should we change User-Agent as suggested or leave it as is. I'm skewed for the last option tbh...

[c-rosenberg]

I would not change the user agent just for an antivirus product. But I like the idea to add more info for debugging issues on the icap-server side. Now configure-able I think it's fine.

[ventulis]

Thank you for merging #3550 This issue is resolved in the manner that a compatible User Agent (extended/ custom) could be chosen in the config.

Wrapping up this issue however, we learned that the vendor does not want Rspamd operators to use their product. Any future reader of this issue should therefore diligently consider if he wants to use a product that might cause similar trouble in the future. Furthermore the vendor's claims that scanning mail attachments with their product would be a misuse of the license could indeed be true and should be taken into consideration.