各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 246期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

话题抢先看

1、日常中我们往往会使用密码本（如主机上存放的Excel表格或txt）。而密码本存在的本身就是一个安全问题，在攻防中也经常成为内网大规模沦陷的诱因。有没有什么方法可以缓解或者解决密码本带来的问题？
2、有一些依赖组件（存在于Web应用中的第三方组件如阿里Druid、帆软ReportServer）存在弱口令，安全部门如何应对这种形式的弱口令带来的问题？
3、对于不规范开发的应用（如请求中直接传递SQL或Bash语句）往往会让内部安全设备产生大量误报，但它们又确实存在安全风险。对于这种情况安全部门该怎么处理？
4、对于不规范开发的应用，如果业务不便于更新迭代，安全部门该如何与业务部门协调，通过什么方法最大程度解决安全隐患？

背景：在日常业务中存在一些由于业务开发或者流程不规范导致的安全问题，比如密码问题、业务逻辑问题，聊一聊对于它们的解决方法。

Q：日常中我们往往会使用密码本（如主机上存放的Excel表格或txt）。而密码本存在的本身就是一个安全问题，在攻防中也经常成为内网大规模沦陷的诱因。有没有什么方法可以缓解或者解决密码本带来的问题？

A1：

密码问题，双因素，多因素，密码复杂度。

逻辑问题，开展渗透测试，开展源代码检查。

A2：

基本用密码托管软件，有加密功能。

A3：

但是密码托管解决不了100%，好多不支持代填。

A4：

为啥非要纠结代填，代填不是一个辅助功能，而不是主要功能吗，密码托管的主要功能是安全的托管密码，不是帮你输入密码。

A5：

使用密码管理系统托管密码管理，密码本打印出来存放保险柜供应急使用。

A6：

1、推荐一个KeePass，本地保存或者云端保存都会加密

2，不用密码，所有设备上统一认证，统一授权，统一管理

A7：

我就是KeePass+OneDrive。

A8：

密码本存放在一个独立设备，用的时候打开，只能手输，但效率减半。

A9：

啥年代了还用密码本，直接数字证书，手机验证码，手机App扫码登录。

A10：

企业分大小、也分成本控制，用密码文档非常正常，尤其是多人用途。

A11：

其实真的不用密码本，以前搞分级保护，被看见有所谓密码本都要被会上通报。所以一直就记几个密码来用。不好之处是，自己在外用的密码也潜移默化的变成了“几个”之一。

A12：

直接问题上使用密码保护工具，文档加密，密码工具等等，间接问题上降低多种密码的记忆，比如增加SSO等方式，统一账户。

A13：

我这边密码文档加2层压缩包、加2层强密码。压缩包加密，每次解压查看，Excel加密没啥效果，加密套机本身有问题。

A14：

我们的放在内部WiKi上，通过权限管理来限制访问。

A15：

1. 使用密码管理器

2. 实施多因素认证（MFA）

3. 定期更换密码

4. 限制访问权限

5. 使用加密文件

6. 审计和监控

7. 教育和培训

8. 使用凭证管理系统

9. 环境隔离

10. 使用硬件安全模块（HSM）

A16：

日常中我们严禁使用密码本，堡垒机代填yyds，服务器密码开发都不知道，密码本没有意义。

A17：

我堡垒机不配置目标密码，免得堡垒机被一波干掉。

A18：

建立自己生成密码的算法，按应用的名称、功能、时间生成密码，这样就不用密码本了。

A19：

像这样设置一个加密盘，专门用于存放密码和敏感信息那些。搞个密码盘，全员都用，简单又安全。

A20：

对于业务和企业另当别论。我的实战经验就是策略强制。比如PC密码就用域下发策略，强制密码规则。邮箱定期检查密码是否符合规则。核心业务也如是。

A21：

我们使用KeePass软件，将密码项分拆为几组，如生产服务器、生产数据库、网络设备、安全设备等等，分别有不同人员管控，主密钥打印保存在部门领导处。KeePass库文件在机房的服务器上部署，做好网络访问控制，仅允许指定主机访问。KeePass中各类密码定期更新，及时同步。

A22：

我们的方法也是用KeePass工具本地化管理，放在内部云盘上做协同，并且根据不同的类型，比如，普通用户，系统管理员，超级管理员，设定不同的访问数据库，而且每个数据库的主密码，嵌套在其他的数据库里，使用随机密码生成。密码管理器定时关注更新版本。如果是文本存档，必须再做加密。且超管权限的数据库，只允许个别几个人访问，路径在云盘上做控制。

A23：

1. 密码软件，比如LastPass、1Password之类的，这个最佳实践是单独给生成一个随机密码

2. MFA,除了传统的短信，邮件，软硬令牌之外，我现在最喜欢的是Passkey。现在有指纹验证的Windows+浏览器可以配置Passkey,海外很多网站都支持。如果没有指纹验证，可以买类似的YubiKey 这种的key也不错，国内也有。

3. 生产环境中的密钥，这个最核心的点就是最好不要存在任何人手里，只能留在生产环境。KMS是很省心的。

YubiKey 这种的好处是一个就行了。不像软Token，有多少网站添加多少行，感觉找到那一行太难了。缺点就是贵，国内都得300多一个。

A24：

我看这个问题是针对本地密码的，如果只是使用2MF和复杂密码口令，先不说企业能不能落地，有个简单的办法就是用数据保险箱PC版，就是把你要保护的密码本和敏感数据放在保险箱里，进行文件加密保护和访问时候用账户密码验证。这样你只需要记住保险箱的账户密码就够了，其余的密码都放在保险箱里保管。

A25：

前面说用系统网盘，在护网中被打穿一波带走案例太多了，我周边4月就有过，文档本身要能拿的走、不能用是关键。

A26：

见过只记明文例如12345，然后MD5几次后截取不同长度做密码。

A27：

以前做乙方，部署设备还真试过甲乙方各拿一半密码。

Q：有一些依赖组件（存在于Web应用中的第三方组件如阿里Druid、帆软ReportServer）存在弱口令，安全部门如何应对这种形式的弱口令带来的问题？

A28：

尽量使用统一认证，减少要记的密码量。

A29：

能改造的做好改造，不能改造的做好访问控制。

A30：

定期漏扫、定期审计。

A31：

漏扫扫不到这种应用弱口令吧，我们通过流量去监测的，抓到直接整改，不然等保过不去。

A32：

可以自己写脚本检测，有弱口令扫描的工具的。

A33：

硬编码的问题，就要多角度干了，主要是跟人打战，不是弱密码问题。

A34：

通过应用安全基线对常用组件、数据库、中间件做安全配置要求。

A35：

事前:对开发做些审计和要求

事中:通过流量设备审计，很多态势感知或者其它安全设备都可以做到这个功能。

事后:告警处置开发

A36：

新上线的系统，要求必须有用户密码复杂度规则，可以通过配置，不允许设置弱密码。原来老旧系统，只能通过比对方式定期检查。

A37：

如果有分散的应用有密码，最好也开发一套自己的Auth接口，通过用户获取密码认证，不要单独再应用保存密码。

A38：

主动出击！！！ WAF写规则，场景的第三方组件模拟禁用掉访问，/Druid /Swagger等等，这种是最稳的。

A39：

这种，你能让安全部门扫到，就能被外部攻击扫到，我的建议是，既然扫到了，如果不改，就直接帮他们改了。被人黑了也是一样的效果。SSO单点认证肯定是对的，但是问题是要所有系统支持。这个挺难打通的。比如。我给你们找几个例子。

比如公有云的命令行工具，你要再本地使用，基本上是要配置AK/SK的，那其实基本上就是key外泄了。然后AWS的CLI现在支持SSO了https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-chap-authentication.html

就是一个命令行工具支持了SSO。

然后邮箱，微软的Exchange Oneline，直接干掉了原来的协议（POP3之类的），用他们的新协议，这个协议是支持SSO认证的。需要弹网页登录（跟网页认证一模一样）

https://learn.microsoft.com/zh-cn/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online

这个是客户端就要启用新式身份认证，也就是你要用任何客户等登录Exchange，都是要跳到网页登录。然后Exchange可以判断要不要MFA验证一下。

A40：

然后咱们让国产信创化，又回到了原地，我们之前用的Exchange，现在都换成信创邮箱了。

A41：

所以需要系统支持。微软刚做完这个验证的时候，几乎所有的邮箱客户端都没法登录Exchange Online了。要说方法，都很简单，关键是落地，特别是100%落地，太难了。AWS这个，我暂时没见到第二家有支持的。

A42：

使用临时AK/SK是不是也比较好。

A43：

SSO本质上就是用临时AK/SK，但是给你一个比较简便的授权方式，没有这个SSO的话，你很难给不同的人分配这个东西。他们也觉得麻烦。

Q：对于不规范开发的应用（如请求中直接传递SQL或Bash语句）往往会让内部安全设备产生大量误报，但它们又确实存在安全风险。对于这种情况安全部门该怎么处理？

A44：

流量监测，代码审计都可以发现，及时监控通报整改。

A45：

必须整改，请求中都带SQL和Bash了，这风险还不高吗？

A46：

制定编码要求，评审安全需求，要是都不肯的话，那就修改安全策略加白。

A47：

合理的SQL产生误报加白处理，不合理的SQL要求改造应用可以结合资产情况建立列表快速加白。

A48：

只要WAF不加白，他们就必须整改，先整改，规定时间之后检测通报。

A49：

禁止，不然以后开发都抱侥幸心理，后患无穷。

A50：

把不规范的安全编码方式直接看作一类风险，使用IDE插件在开发阶段或CI阶段就将此类问题暴露给研发人员，在应用上线前消灭大部分的不规范编码，省的后续扯皮。

A51：

没错，在上线之前就按照编码规范进行代码审计，不规范的不允许上线，安全要求前置；找领导申请预算搞开发安全对开发人员进行安全意识培训，建立健全安全编码规范和要求。

A52：

经常有遇到那种参数超级大，还带SQL语句的客户那边的WAF一直告警，让整改就说功能影响太大不能动，写的时候没有安全和规范，全是老代码。

A53：

最近PoC测试到，某家WAF对这个有自学习或者是正常语句不告警的功能但是实力效果没详细试试。 只会针注入常用的字符串匹配等机制。看初步效果还不错。

A54：

前阵子部委的电视电话会议，请的某部研究所的领导讲课，他们还说了，工作密码和生活密码要分开，不然直接社工库就突破了。

A55：

引入一些合理的开发规范，比如加入一些强要求的措施，但是这块需要与开发部门进行沟通协商，比如使用阿里巴巴的开发规范和要求，基本上可以满足日常需要，做开发的应该都知道。

Q：对于不规范开发的应用，如果业务不便于更新迭代，安全部门该如何与业务部门协调，通过什么方法最大程度解决安全隐患？

A56：

解决不了，配WAF策略，用虚拟补丁缓解。

A57：

尽量隔离网络，安全监控设备重点关注。

A58：

看具体业务场景了，但估计也只能相信买的安全设备有用了。

A59：

业务部门是业务部门，开发部门是开发部门，不能混为一谈吧，理想情况是拉着业务部门，讲业务风险，一起找开发部门改。

A60：

开发层面的整改好像不太容易，特别是有些开源组件，特别多依赖，动一个又要牵扯出好几个，这个问题比较难搞。

A61：

还是要评估资产重要性数据重要性，如果风险整体较低可以使用WAF或者访问控制等补偿性控制措施来降低风险。

A62：

先风评一轮，内外部整改一轮，之后上手段只需监控，协调的话就是戴高帽，讲政策，威逼之，告领导。

A63：

下正式整改通知，让他们列整改计划，先期通过功能限制、WAF策略这些加固，把安全能做的做到位，同时让他们做好整改期间的安全监控，出了事他们自己背锅。

A64：

干不过业务，说服不了领导，只能建议买保险，同时做好跑路准备。

A65：

买保险属于风险转移处置，是个风险处置办法。

A66：

上家单位工作的时候，我去别的省公司支援，扫了一堆漏洞。

然后，那边的兄弟说：这2个漏洞是我们运维部门管的，帮我们抹掉，但是我们还是会修复的。另外，有几个市场部门的漏洞，他们一直没改，之前忘了把IP报给你们，你们在报告里面加上吧......

A67：

只能把风险算出來給领导，让他自己判断，通常说完都是没钱/没人力，然后就没然后了。那些系统都比我年纪还大。

A68：

甚至研发说，这代码我不敢动一点，要是出问题就是一张事故单。

A69：

确实难啊，老代码、老框架、老语言、老机器。你微微一动，天都塌了。

本周话题总结

本期话题探讨了在日常业务中由于开发或流程不规范导致的安全问题和解决方案。针对密码本安全问题，推荐使用密码托管软件（如KeePass）、密码管理系统，实施多因素认证，定期更换密码，限制访问权限，使用加密文件，审计监控，教育培训，使用凭证管理系统、环境隔离、硬件安全模块等方法缓解。

有一些依赖组件存在弱口令，应对措施有使用统一认证、改造或控制访问、定期漏扫审计、流量监测、写脚本检测、设置安全基线、开发Auth接口、WAF写规则等，新系统应设密码复杂度规则，老旧系统定期比对检查。

对于不规范开发的应用，安全部门可通过流量监测、代码审计发现问题并整改，制定编码要求，评审安全需求，合理加白或禁止，利用IDE插件提前暴露问题，上线前代码审计，与开发部门沟通引入规范，若业务不便更新迭代，可评估风险后采取补偿性控制措施。

近期群内答疑解惑

Q：有画攻击线路图趁手的工具吗？我要对外展示攻击线路。

A1：

Xmind。

A2：

Visio。

A3：

我以前用Axure，就是产品经理画原型用的工具，但其实最好还是Visio

A4：

https://icraft.gantcloud.com/editor推荐这个，比很多公司专业设计出的PPT还好看。

Q：有什么办法可以知道所有服务器里面是否跑的有容器服务？跑的有Docker之类。

A1：

像我们是给服务器装上HIDS，就能看到了。

A2：

堡垒机可以批量查，有装一些平台的探针或者Agent的也可以查，什么都没有，就先扫端口，大概看一下。

A3：

有Nessus的话，把凭证扔进去扫就知道了。

Q：如何给不懂的领导科普信息安全，提升领导安全重视度？

A1：

去搜些案例，判多少年，罚多少钱的那种。科普不了的，只有和他讲案例、违规处罚这些关系到经济利益的他就懂了。

A2：

先做个内部评估，提出风险和方案，他不理，就主动和监管沟通，做个安全监督管理，反推回来，老板就后悔早该听你的了。

A3：

你不需要额外的做这些工作其实，你先不停的做员工的安全意识培训。先把动静整起来。剩下的你只需要一个机会，你问出这样的问题，说明你们公司就是事件驱动型的安全环境。等网安通报，等监管上门，或者等一次严重的信息安全事件。到时候你发挥你carry全场的能力就行，没有什么比打脸更直观的教育方式了。

有机会汇报一些项目立项，立项不批再找相关联的事件，比如你要上防病毒、EDR啥的，项目不批，就天天发感染病毒通报，评估项目被毙，就让网监来通报，上权限管理、DLP不批，就天天找数据泄漏的事件通报，通报3次不处理就会勒令整改。

Q：外部扫描出来的jQuery这种漏洞你们改吗，一般选隐藏版本号还是升级版本？

A1：

看风险被利用程度吧，难就改版本号，简单就升级。

A2：

前期不会管，后期持续运营阶段会定低危，拉长修复周期让开发慢慢处理，能升级的升级，不能的隐藏版本号。

Q：大家扫出来的漏洞怎么处理，怎么分配的，怎么知道这是属于运维的还是研发的？

A1：

我一般这样分的，操作系统和数据库的漏洞，给运维，其他的漏洞给开发。

A2：

需要做风险评级呀，过风险阈值的，按评分分发给对应负责部门进行修复。

A3：

找出真正有危害的漏洞，拉个群拉个会多处理多几次就知道找谁了。

送你一本网安人的“小绿书”

光看不过瘾？想要加入话题深入交流？

那就来FreeBuf知识大陆电台小程序

网安人的“小绿书”

找报告、搜文档
行业新闻 、经验分享、职场八卦、同行互动

AI变声和匿名功能

专为社恐人士打造

让大家以更轻松的姿态

随时随地，想聊就聊

我们已经邀请数位网安行业大牛开设电台房间

等你来「撩」

扫码进入小程序，参与话题讨论

甲方群最新动态

上期话题回顾：

办事处网络安全监控与事件响应；国外员工终端安全性怎么保障

活动回顾：

迈向安全服务化，探索网安行业和社区发展新动能 | FCIS 2024网络安全创新大会举行

近期热点资讯

德勤遭勒索攻击，被窃取机密数据超1TB

新型安卓系统银行恶意软件能窃取77家金融机构的账户凭证

I-O Data路由器0Day漏洞被利用，无修复补丁
知名伏特加品牌因勒索攻击而倒闭

警惕这类黑产，近百万老年机被远程控制，每月莫名扣费……

FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群、3群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1300+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。