On 11.09.2008 16:52, Ian Eiloart wrote:
Now, having done that, I'm thinking PUA could be VERY useful. In fact, I've been considering banning outright the passing of executable files in archives - too many bits of malware are slipping through the net at the moment.
I don't quite see the connection. Malware should be caught by the regular malware signatures, shouldn't it? PUAs as I understand them are legitimate pieces of software that could also be put to bad uses. A blanket ban on all executables is something else still - there may conceivably exist executables that do not lend themselves to any bad use. (For example, self-extracting driver installation packages.)
It would be nice if ClamAV were to have that option - perhaps "all executables" could constitute a class of PUA, perhaps?
Technically it's probably not too difficult. But I do not see a lot of environments where such a policy could be maintained.
Probably that would need to be explicitly enabled...
Just as the present PUA sigs.
Anyway, can anyone think of a reason why anyone on a University Campus would (a) have a need to transfer files in any category below, and (b) not have access to alternative means like sftp?
(b) is easy: these alternative means require some server space where the sending party can write and the receiving party can read. Experience shows that this is a real obstacle. As for (a), of course it depends heavily on policy, as well as the precise definition of these categories, but for example:
Sub-Type: RAT is Remote Access Trojans Description: tools used to remotely access systems but can be used by system admins, for example VNC or RAdmin
VNC is quite popular for remote support, and as such frequently mailed to inexperienced users.
Sub-Type: NetTool Description: General network LAN/WAN tools, for example ip scanning, port scanners, Netcat etc.
This is an extremely broad category. Netcat, in particular, is a very educational tool and, in the absence of a global "no exe" policy, could very well be mailed around for exercises.
Sub-Type: Tool Description: General system tools, process killers/finders Example: PUA.Tool.PsKill-2
This is even broader. Many handy tools one might pass to someone with a specific problem may fall into that category. Again, if sending executables by mail isn't completely banned anyway, mailing one of these might well be legitimate and useful.
Sub-Type: Script Description: Known "problem" scripts (Javascript/ActiveX etc.)
Quite difficult. Scripts are cleartext after all. I see a big risk of false positives when, for example, including problematic script code in mail messages for discussion.
Sub-Type: Packed Description: Known "bad" packers/tools which can used to hide malware or make debugging difficult
Problematic too. I have already had several false positives in the past where a user legitimately used a script packer which was apparently also used by some malware. And that was with signatures which didn't even intend to target the packer, but the actual malware.
Sub-Type: IRC Description: IRC server based programs/malware
I don't use IRC myself, but respectable people keep telling me that it's not for bad guys only, there are legitimate uses for it, and I should try it myself to see. So I am a bit reluctant to declare all IRC server based programs "possibly unwanted". Actual malware OTOH should be caught by the regular (non-PUA) signatures already. Again, it all depends on the precise definition of what would or would not go into that category. jm2c T. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
