对扫描的一点想法

显示全部楼层 · 发表于 2021-9-27 09:42:31

看扫描进程的时候想到一个问题，大体积ISO或者压缩文件，国内一些网盘在用户上传文件的时候会检查md5，sha值等，如果一样就判定为同一个文件，上传最多就是几秒钟的事，这个被称为秒传（对此种方式的合法性，安全性和所有权等抛开不谈），不知道如果将这个方法引入eset或者其它杀软的扫描机制，和官方镜像或者认定为安全的压缩文件进行比对，相同就直接跳过，是不是可以节省一些扫描时间？

显示全部楼层 · 发表于 2021-9-27 12:13:01

这个是云信誉方面的问题了

显示全部楼层 · 发表于 2021-9-27 13:12:56

事实上大多数AV的做法是遇到体积大压缩层级多的压缩文档跳过扫描。有些甚至是遇到压缩文档就直接跳过。这样的作法无可厚非，只要压缩文档里面的病毒能被检测到就可以了。

显示全部楼层 · 发表于 2021-9-27 13:41:24

这不就是云查杀的基础吗
MD5比对

显示全部楼层 · 发表于 2021-9-27 13:45:15

pal家族发表于 2021-9-27 13:41
这不就是云查杀的基础吗
MD5比对

我的想法是本地扫描一样就直接跳过，不用进入镜像或者压缩文档内扫描了，减少消耗的时间，云端比对只是向服务器查询样本特征码。

显示全部楼层 · 发表于 2021-9-27 13:49:40

AAAFFFQQQ 发表于 2021-9-27 13:45
我的想法是本地扫描一样就直接跳过，不用进入镜像或者压缩文档内扫描了，减少消耗的时间，云端比对只是向 ...

一般信誉只记录集中格式的文件吧，不可能啥文件都记录
而且本地对波md5还需要计算md5啊大文件计算md5也是很吃资源的会卡的
你放心很多问题杀软厂商都想到的，目前的策略其实是已经很优化得了

显示全部楼层 · 发表于 2021-9-27 14:25:43

本帖最后由 PanzerVIIIMaus 于 2021-9-27 14:31 编辑

我认为这很美好
但不科学

首先，终端用户对于大多数封包就必须进行指纹计算，指纹计算除了计算资源，就完全取决于对象大小和对象所在磁盘的速度
其实，性能、效率和时间问题要综合看，在这种视角下，卡巴斯基的iChecker缓存技术就从未尝试支持操作大型对象，因为：扫描文件比检查文件自上次扫描以后是否已修改要节约时间。

而且从安全和后台角度上来说：

万一某个文件因为某些问题（比如：供应链攻击；或者因为被曝易受利用/不受支持而被归类于黑客工具等等）被报黑，而威胁文件分布于多个“原先受信任”的镜像或压缩软件中

你如何去消除影响？或者通过一个提前的措施来避免影响？
我想到的一个答案是，压缩包/镜像包内的每一个对象都列出白名单，以后拉黑的时候可以顷刻拉黑所有相关的对象

先不说这种背景之下我坚信95%的知名封包都不及格

劳资有这精力、资源和钱，多把几个普通的文件拉白，多拉几个恶意对象入库，多几分钟时间研究防病毒引擎
不比这点主意更通用、更节约成本和时间？

显示全部楼层 · 发表于 2021-9-27 22:54:47

文件太多，全网每天产生亿计的文件，加白名单加不过来，
假设1KB文件可记录1000个白名单，一兆是1000KB，含有100万白名单。一G1000兆核10亿白名单，差不多一天就要产生一G的白名单库。这可是极保守的估计。

现在加白策略就是可被运行的文件，验证签名，无签名的需要许多用户自行加白后再入服务器白名单。

显示全部楼层 · 发表于 2021-9-27 23:44:40

一个典型的量变引起质变的情况

这世界上大文件这么多且不说MD会不会重复扫描和算MD5哪个更快还两说呢

[讨论] 对扫描的一点想法