漏扫不都这样吗？
肯定要保证关键组件最新啊，否则那些cve怎么修补上。。。


【 在 dukenuke 的大作中提到: 】
: 防火墙策略弄得再完善也不行。
: 在你的主机上装个他们的扫描工具，直接按黑名单扫你全盘。我是没能力保持全部系统
: 组件库文件都时刻保持最新，版本依赖就过不去。
: 这咋弄？
: ...................
--
FROM 36.152.157.*

但是，自己建的运行平台稳定了以后不会保持时刻同步更新的。
还有些主要开源组件，有时候会有大版本更新，好多特性会有增减。这种版本依赖没办法。
我以前一直的概念里，漏扫是从外部嗅探攻击的，用已知漏洞库从外部扫描验证的。

【 在 archblue 的大作中提到: 】
: 漏扫不都这样吗？
: 肯定要保证关键组件最新啊，否则那些cve怎么修补上。。。
:
--
FROM 166.111.35.*

一般不是补不上就不补了，挡住就行了吗。
比如我的系统里有内部的postgresql服务，只给我自己的几个应用存内部数据，防火墙上把端口都封了。那我弱密码就弱密码，旧版本就旧版本，有什么危险呢？

例如我的系统平台3年前建，用的kafka0.8，现在都3.1了，后台服务依赖都二合一了，外部API也几乎全变了，0.8官方也停止维护有一阵了。正常做法不应该是把Kafka的内部通信跟外部全封掉，完全对外隐蔽苟着么？
现在要是强制要我升级到3.1，那所有系统都得重新开发测试一轮。
不知道谁来背锅，反正开发的售后只管1年。



【 在 archblue 的大作中提到: 】
: 漏扫不都这样吗？
: 肯定要保证关键组件最新啊，否则那些cve怎么修补上。。。
:
--
修改:dukenuke FROM 166.111.35.*
FROM 166.111.35.*

甲方合理要求。基线检查。

甭管外部防火墙怎么样。

在写整改报告时，可以把自己的各种理由写上去。

举个例，内容主要涵盖：

后续运维主机和应用打补丁是谁负责的，多长时间，此服务收费情况，升级策略是？

为什么现在部署的版本不可升级？针对已知漏洞，对应手段是什么？不可升级修补，那
么采取的解决方案是？

看甲方是否接受。


【 在 dukenuke 的大作中提到: 】
: 防火墙策略弄得再完善也不行。
: 在你的主机上装个他们的扫描工具，直接按黑名单扫你全盘。我是没能力保持全部系统组件库文件都时刻保持最新，版本依赖就过不去。
: 这咋弄？
: ...................
--
FROM 119.130.154.*

也会，docker image在磁盘上是展开的

【 在 oldwatch 的大作中提到: 】
: 像这种
: 如果藏在docker容器里应该不会被抓到吧……
--
FROM 116.213.168.*