▎各位 Buffer 晚上好,FreeBuf 甲方群话题讨论第 230期来了!FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论,Kiki 群助手每周整理精华、干货讨论内容,为您提供一手价值信息。
话题抢先看
1. 日志采集过程中,如何确保日志数据的完整性,防止篡改和损坏?
2. 如何确保细粒度的访问控制,以防止未经授权的用户访问敏感日志数据?
3. 如何确保在灾难事件中快速有效地恢复服务?
4. 有没有能打乱代码结构的JS混淆工具?
话题一
日志采集过程中,如何确保日志数据的完整性,防止篡改和损坏?
舍得成本的话,就加密,数字签名,多机热备。我们是用了几台服务器专门做日志采集的,网络隔离非常严格,专机专用。
冗余备份:将日志数据存储在不止一个地方,以防止某一份数据的损坏或丢失;
数据校验:使用校验、散列函数等技术来验证日志数据的完整性;
数据加密:使用加密技术来保护日志数据,以防日志数据被窃取或更改;
数据版本控制:使用版本控制系统来管理日志数据的修改,以便在遇到问题时回滚到以前的版本;
审计日志:记录所有对日志数据的操作,以便在遇到问题时进行审计和分析。
日志和业务服务器分离,确保业务服务器攻陷后不影响已经生成的日志。日志服务器自身做好加固和相关基线工作。
标准做法是在SIEM日志审计设备收集上来的日志做完整性签名,因为审计日志不是敏感数据所以暂不需要加密,只需要完整性保护。完整性保护需要给日志用签名与验证签名服务器和密钥进行SM2/SM3 的签名,和验证签名保证其完整性。并且日志审计设备在隔离的安全区域,通过加密隧道和认证才可以访问, 也符合相关的密码保护合规标准。
比如数据源那边优先使用TCP Syslog, 然后使用Agent采集的数据源做Agent监控,避免Agent长期离线。数据库读取的随机时间范围内的日志条数做对比,另外日志存储服务器权限控制,管理员操作定期审计。
日志按照资产价值做相对应定期异地备份,可以在一定程度上缓解这个问题。
加密传输,日志备份、严格的读写权限、对日志收集传输进行监控审计。
Q:如何确保细粒度的访问控制,以防止未经授权的用户访问敏感日志数据?
这个就是做好权限管理和审计了。
只给固定的人员开启访问权限,其他访问必申请,这个应该还好,应该主动愿意看日志的人也不多。
细粒度的访问控制不太好搞,一般也就是ABACRBAC就行了。
ALC访问控制,再加个操作审核。
要求比较严格的话,日志服务器开启ACL控制,必要的时候上堡垒机审计。
控制权限划分,设置审计策略。
1. 网络控制,开白名单访问IP,限制到访问端口;
2. 权限控制到人,IP和MAC和人做绑定。
Q:如何确保在灾难事件中快速有效地恢复服务?
建立数据备份系统,制定灾难恢复计划,评审灾难恢复计划的可执行性并且每季度检查。
权限申请、审批,谁审批谁负责制。
这个问题要看场景的吧,不能这么绝对。审批的人应该负授权是否合理的责任,申请人负在权限范围内造成的敏感信息泄露的责任吧。
这个是的,不过宣贯要从这儿做起,出了事,分锅肯定是按照职能权限来的。不过在审批时候,就要对下对上都得承担一定的责任了。
审批也就是流程控制做卡点合规内控而已,想靠这个去限制其实不现实,很多流程到了也就点点就过,没负担。
应急预案,演练。保障恢复流程顺畅;冗余(多云,多节点)、备份保障恢复流程高效。持续改进,查漏补缺,保障流程和方案不断提升。大致这么多。
应急到最后,就看托底的备份是不是还存在,是否可用,数据缺失多少。
灾难不仅仅是数据丢失。
嗯,但领导关注的是业务连续,因为除了对社会影响大的安全事件,首先在企业内部就做了封闭,我们要做的应急是尽量内外上下都无感。
按照SLA的一些标准操作,我个人的理解是: 1. 建立灾难恢复计划,保证出现系统问题可以按照计划流程以及人员配置迅速进行修复和启动系统; 2. 提前做好数据备份,当因为勒索而系统无法使用时可以迅速还原数据,减少损失; 3. 用HA建立备份系统,备份系统数据与主系统数据保持同步,一旦发生问题可以切换到子系统; 4. 也可以使用云厂商提供的灾难恢复的产品功能进行恢复(节省时间和人力)。
话题二
有没有能打乱代码结构的JS混淆工具?
JScambler、JShaman(商业版,但是有在线免费版本)。
这两个不太行,要那种打乱结构的,不是替换关键词啥的。
UglifyJS、Terser、Jscrambler、Obfuscator。
这种都不行。这种主要慢慢打断点,还能调出密钥,就看看有没有直接打乱代码结构的。
那过于混淆了,我建议通过加密来解决。
把一些关系敏感信息或者整体的JS都进行加密,因为如果修改主体结构,可能会导致代码不可读的,稳定性、可用性很差,还有不好维护。不过商业化工具我没怎么了解过。
再怎么混淆了也不能避免被调试出密钥吧,只是增加了难度。
逆向还是可以的,就是难度问题。
是啊,现在难度还是不够,反调试都加了,就看看有没有更牛逼的方案。
你这个做了字符编码和字符串拼接吧?
这种就是var return,if啊太清晰了,代码结果很容易识别。然后就可以猜到大概的加密位置,慢慢打断点就能调出来。x这种都是乱码再编码后的。
那你还是看看加密吧。
混淆跟加密有啥区别,有工具吗?还有种通过包含加密文件调用的方案,但是有的系统不适用,那个倒是无法调试。
混淆侧重代码更难以理解和修改,加密侧重将数据转换为不可读的加密信息。
而且加密信息在没有密钥情况下几乎不可逆向,我觉得你们的代码信息还不至于让人家用这么大算力去破解,还有时间。
前端加密就能防住前端的代码调试吗?
能防住,但是你说完全防住,谁也不敢保证。
话说你们总不能把对称密钥放在JS里吧,放进去再混淆也没用。前端加密方案不都是RSA加AES么。
单用的AES,很难受。
浏览器动态调试,结合请求啥的,大概位置还是挺好定位的。
对称就是AES、DES,非对称就常见RSA、DSA这些,看你们怎么使用。
我假设个场景,前端对数据包做验签,加签过程有使用到这个密钥。为了防止前端密钥泄露,如何使用RSA对这个密钥做非对称加密,让前端浏览器无法动态调试出这个密钥?
RSA加密密钥,发送到前端和前端浏览器-->在使用私钥进行解密加密的密钥-->使用密钥被解密,就可以使用密钥对数据包的加签,就算密钥泄露也是加密后的,无法解密,不过还是只是加大难度,总会有办法。
1. 如果是单向验签,是基于HMAC,公钥是公开的,不存在密钥泄露的问题;
2. 如果是双向的,因为前端调试必然会调试出私钥,为了保证安全就需要上硬件,如CA硬件。
AES密钥随机生成,RSA加密AES密钥。服务端RSA解密获取AES密钥,再解密数据。另外加入Nonce防止重放。应该大部分都是这么做的。
Q:领导说今年重点工作是建立资产图谱,如何建立图谱?
A1: 公司规模多少?先根据资产数量,预估是上工具还是Excel表。 A2: 我们目前是Excel表,用来迎27001的。 A3: 那就继续Excel表,字段弄好,用共享看板的形式。 A4: 先自己确定一部分字段,最好结合漏扫需求比如重要性、区域之类的,再结合业务,最后和领导确认一下, 以领导意见为主。
Q:服务架构下大家是如何对众多API进行安全测试的,尤其是未授权访问这种漏洞?
A: 流量收集:接入层镜像收集流量;
流量检测:不要检测所有接口,聚焦敏感接口或者你关心的某类接口,做接口资源池和身份池,流量重放看返回是否一致,所有接口检测公共接口会大量误报;
白盒思路:看一下公司所有接口代码判断身份逻辑的代码,去匹配库里所有代码是否有接口未引用类和代码片段。
Q:公司内部的一个对象存储因为某个业务,领导让把对象存储发布到公网上,请问内部对象存储适合发布到公网上吗?有哪些比较好的防护措施?
A1: 分布式对象存储。 A2: 如果只是技术问题,那么:
1. 加密传输;
2. 身份验证和授权;
3. 访问控制;
4. 底层数据加密和备份;
5. 监控和日志;
6. 审计和漏扫;
7. 版本控制。A3: 互联网使用独立的Aksk,关闭该Aksk的所有List和删除等不必要权限,仅允许上传下载权限。对于具体的OSS对象,不开放永久公开访问,仅允许上述Aksk申请临时访问链接,一小时有效。 A4: 使用OSS存储,应该都可以满足。 A5: Aksk放在服务端不能放在App端,服务端验证好用户身份和资源所属关系后,再申领临时URL下发给客户。 A6: 云上的OSS对象存储还好,关键是办公机房内部的一个分布式对象存储。 A7: OSS的弊端主要在没有C端用户资源所属关系的管理模型,所以建议不能直接暴露给C端,要走个中间层进行资源的鉴权。
Q:考法对安全的助力是什么?
A1: 我觉得是转职做合规,当然是大型企业才需要吧,小型企业合规也是凑合。 A2: 1. 更好的司法解释; 2. 更好的保护企业利益,哪怕是在跟监管机构也可以引用法条有理有据; 3. 对司法流程更加理解透测; 4. 对立法精神更好的理解本源; 5. 你可以说自己是真正的企业在安全方面的责任人,有法律背书的。
思科产品曝出高危漏洞,允许黑客远程控制统一通信系统 泄露TB级数据,云平台宕机,全球巨头施耐德被勒索攻击 奔驰源代码意外泄露,暴露内部敏感数据 网络战新高度!俄罗斯280台服务器被摧毁,200万GB数据丢失
原文始发于微信公众号(FreeBuf):如何保障日志完整性;JS代码深度混淆 | FB甲方群话题讨论
免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论