Anti-Malware Cog

[GhostofGoes]

Occasionally, users will upload malicious files that slip past Discord's fairly limited protections. Thus far, thanks to the sharp eyes of the staff, we've been able to catch most of these before they had a chance to be downloaded. However, as the server grows, the risk increases of something being available and potentially downloaded before the staff notices it. The goal of this cog is to eliminate that risk by checking message attachments for malicious or other undesirable content.

Features

• Checking of files for malicious content (Current approach is to use the VirusTotal database API for this purpose)
• Automatic removal of bad files
• Alerting of the moderator team of incidents (much like the current antispam cog)
• Optional ability to filter by extensions (e.g. warn if someone uploads a non-malicious zip file)
• Stretch: plug in other file identification services, such as NSFW/hatespeech content detection, "shitpost"-grade memes, etc (like antispam, but for content, and ideally more reliable than the (IMO) unreliable garbage Discord uses)

Current working name for the cog is "sentinel".

[sco1]

Relevant meta: python-discord/meta#16

[GhostofGoes]

Ah, there's the issue I was looking for! Was positive there was an issue for this, but I couldn't find it, so figured I'd just make a new one.

[jb3]

Personally I don't feel that this warrants it's own cog. I think it is something that could be integrated into the existing filtering cog. Just add it as as a feature in there and then it gets the alerts like other filters.

However, this could slow down the filter process as every message with attachments would need to be scanned, if we can change the order of execution of filters though then that isn't an issue as we can just run message content checks first then run virus checks.

[sco1]

Having it live in ./bot/utils/ seems like a good middle ground

[jb3]

Yeah that sounds reasonable, just don't know if we need another cog for it, feels like there could be a lot of duplicated code when there is already a filtering system implemented.

[GhostofGoes]

I'll take a look and see if I can fit it into the filtering cog. The logic is a bit more complicated, since it's making API requests and caching results.

[jchristgit]

I disagree that this shouldn't be its own cog. See my comment on #160

[GhostofGoes]

Yeah, the arguments you made in #160 are spot-on. If there's a bug in the anti-malware scanning, it would be good to be able to unload it without losing filtering completely.

[GhostofGoes]

Moving here: #471