blog
blog copied to clipboard
mylamour
Your internal mediocrity is the moment when you lost the faith of being excellent. Just do it.
之前在BTCC做安全评审的时候，记录过一些内容 #41 。 主要是集中在技术角度。而今站在新的视角下，看到的安全评审又是另外一种。 在此可认为有两种方式： * 一种是**技术角度**入手，切实到每个链条的实现环节。 * 一种是从**全局观**入手，切入点是当前系统的引入，对公司整体的稳定性，安全性。 前者比较适用于小公司或者一个团队内，一个人能够把握全局的。而对于后一种，就适用于大公司，因为无法落实到细节的实施上(这一块可以由开发规范去约束)。所以必须从架构上，和业务上，以及数据流和数据依赖上，针对其对公司的其他业务系统的访问，调用。当前选择的技术栈的支撑情况，数据库的支撑情况，等方面进行综合的考虑。从各个方面都考量着安全评审专家对整个公司系统的把控。也只专注到安全上。至于性能则是由架构师进行考虑。在此过程中，难免遇到的就是有许多人喜欢不懂装懂。或者喜欢钻牛角尖。钻牛角尖并不是不好，但是要分清楚在什么时候，开发人员的视野往往都具有一定的局限性。而架构师则能理解其中的缘由。因此，架构师需要在此充当一个稳定全局的角色。并支持安全评审的意见。当然如果是一个半吊子水准的架构师，则要听天由命了。 比如从全局观来说： * 新的系统依赖了哪些现有系统 * 需要从哪里鉴权 * 链路加密 * 鉴权的方式 * 数据库用了什么 * 技术支撑是否有 * 编程语言是什么，是否是主流的，架构是否支持 * 数据是否能回流 * 数据依赖是否可控 *...
我显然不是一个数据安全专家，但是我马上就要参加DSMM测评师培训了。先纪念一下。 但是根据爬取的一些JD来看。至少要： * 设计过水印系统 * 设计过KMS系统 * 熟悉加解密算法 * 熟悉数据安全模型 * 内容安全治理 * 熟悉等保测评 等吧。这个就先暂时放这吧。 以上是我3月14左右。 2019.04.09 Update: 经历了几天的集团DSMM测评师培训，明天就要考试了。先祈祷明天能过。下个结论，上面说的话显然有些得意洋洋了。想成为一名合格的数据安全专家何其之难。入门已经是不易了。看来还是自己之前太过不知天高地厚。之前心中还有轻视之心，至今晚方知是自己唐突了。 2019.04.13 Update: 考试第三部分的报告终于算是发出去了，等待结果吧。下面补一下相关的脑图及整理的资料。 数据安全人员能力  测评师测评  DSMM架构图  数据安全能力成熟度特征 ...
# 前言 如上一篇所言，采用BanIP的方式，以及限速的方式。当然还可以采用API网关进行限制。不过这些都不是要讨论的，这篇要讨论的是，怎么通过代码层，实现常规，但是又不是那么容易被破解的方式。去达到防刷防作弊的效果。让我们再思考一下其他的方式，如何更好的做到。 # 从JavaScript AntiDebug 开始 一般来讲是有以下几种技术: * 异常环境检测（我们只想自己的代码运行在浏览器中） * 调试工具检测 * 代码完整性检测 * 数据流完整性检测 * 反模拟 正好前两天研究反调试技术，顺便翻译了一篇，详情点击[此处](http://telegra.ph/Javascirpt-Anti-Debugging-08-02) # 设计及验证  POC验证,（请无视字段。。。。），当然前提是前端也要做好反调试和加密。   前后端接入之后，但依旧不能完全的阻止攻击，在攻击者花费一定时间之后还是有可能被攻破的。那么如何在后面的阶段检测到脚本作弊，则需要对用户行为进行分析。 # 用户行为分析 简单的鼠标行为记录，加上事件记录，单击，输入focus input，等等，将其序列化，做分类即可。这个方法目前正在测试环境收集用户行为日志，将其导入到s3,然后后期分析。...
首先专家的定义是指对某一事物/领域精通，并有独到见解的人。根据我自身经历我认为SDL专家起码应该具有以下这4点基本要求.(PS: 同事说，SDL专家就是扮演好一个保姆) * 一套规范的开发/发布流程， 并能针对公司现状(规模，环境等)进行适应性改变 * 安全领域内针对多个领域的专业技能,解决问题的硬实力以及踩坑经历 * 与人的沟通能力以及跨部门的协调能力 * 部门的管理能力以及推动方案落地的能力 首先只有熟悉了开发规范，并且具有专业输出能力，才有把整个事情做出来的基本能力。但同时整个流程是不可避免的涉及到多个部门间的合作，此时跨部门协调能力，以及沟通能力毋容置疑也是十分重要的。 SDL的防护，自古以来的说法是自上而下的推动。当然在小公司中，可能是需要先有安全人员的反馈才能产出，是一种自下向上的行为。不过这种行为，在大公司内的可行性几乎为0... 1. 熟悉开发流程   根据开发流程，找到对应的人员，咨询的，技术支持的，解决问题的，职责者，对应领导，手上的项目，项目的价值等等先要梳理清楚。(**安全的目标是保驾护航，不是去阻碍业务发展。**) 2. 了解流程中需要防护的地方 下图中的总结可能仍有疏漏，抛砖引玉之用。希望能够看到更为详细的在流程中所需面临的一些基础问题。  针对出现的问题风险，一个SDL专家需要做到什么程度。在不同的领域均有造诣？还是说清晰的逻辑思维？简要梳理了下图。真正的SDL专家需要了解的技能领域。  当然很大程度上，在具体的实施上。这些事情是没有办法一个人去完成的，所以这个时候需要体现出另一个职责:带队能力。 通过带领几个安全工程师，分别处理完成不同时间线上的问题。需要安全架构去评审的交给评审工程师。该安全开发培训的交由开发去培训，该进行安全运维的去安全运维，该运营SRC的运营SRC。 分门别类的完成对应的职责。将每一部分进行精细化的运营即可。这个时候专家还需要汇总，和整体把控一下。当然，很多情况下，小公司是不可能养得起一个安全团队的。 那么，你是专家，你尽量干。。。按优先级处理。(不过小公司也不会有这么个流程，被盯梢的几率也不大。即便出了问题，做好基本防护的话，影响也不会很大) # 思考:...
这是之前为即刻Anti-Spam，针对内容安全画的思维导图：  所有的阻挡应该是威胁的一层层缓解手段，直到屏障的方式无法穿透。 # 反垃圾注册 最近公司接收到了不少的垃圾账号注册，估计都是因为积分来薅羊毛的。这些账号会自动的进行其他api交互。完整的流程应将注册邮箱与黑产邮箱数据库进行比对，以及维护一份临时邮箱注册列表，不允许临时邮箱账号进行注册。同时对注册接口进行限速以及禁止机制。这样才能比较有效的完成反垃圾注册。 * splunk， nginx access log * web服务架构: Front ->cdn-> waf1 -> waf2 -> nginx reverse proxy -> WebServer 禁ip的坑： 第一次禁了ip就不能访问，发现是禁了waf2的，然后把waf2的地址配置为回源ip之后，发现过来的ip有一个将其禁掉之后，发现是来自cdn的ip，也就是说cdn的配置(携带真实ip入waf1)并未生效. 直接设置地洞进行动态ip访问限制，1分钟访问注册6次之上的禁用30分钟。 获取源ip:...
软件架构的过程中，SOA，微服务，基于领域驱动的架构设计，敏捷开发，一大堆的名词早已经听得不能再多了。(只有当你身临其境的参与到其中，才能真正的感受到)。 本文简要纪录一下架构图的设计。 一般来讲有以下两种方式(ps:此处就不贴出每张图的具体事例了)： * 4+1视图，分别为物理视图、逻辑视图、处理视图、场景视图和开发视图 * C4模型: 上下文（Context）、容器（Container）、组件（Component）和代码（Code） 但是需要明确的是，首先你要知道你画的图是给谁看的。你要告诉他什么。不同的人不可能看到同一个图去干活的，也不一定都能看的懂。逻辑视图给谁看，开发视图给谁看。只有在最初的时候明确了要传递什么样的意图给别人。才能去好好的画每张图。 (更官方的定义参考百科) 物理视图: 什么系统在什么位置。 逻辑视图: 这些系统干什么事，有哪些功能。 处理视图: 一个请求或者一个数据怎么流向，怎么结束一个流程。 场景视图: 实体和系统的交互 开发视图: 开发怎么完成具体的模块，具体技术栈，基于什么什么。 至于第二种，针对基于容器的微服务设计实现，主要针对于敏捷开发实现。单其实也有类似之处，比如可以样理解，明确你的上下文(场景),有哪些组件（处理，逻辑），然后需要实现什么样的代码(开发)。 至于更官方的可以参考其官网。 针对这些架构图呢，在饿了么以来，由于部门需要和阿里集团侧安全部门合作密切。所以需要梳理架构，在这个过程又思考到以前自己是怎么做的架构设计。结合ATA上的一些经典好文，逐渐产生反思。 总之一句话，知行合一。干了才知道，不干是不知道的。 # 参考 * [C4Model](https://c4model.com/) * [用于软件架构的...
负载均衡和多活
负载均衡可以做的地方很多，从以下几个层面可以看出其具体的实现。 * 路由层 多DNS服务器 * 站点层 多代理服务器，一般nginx有轮询，权重，url-hash, ip-hash,fair 这5种方式，ip-hash可以储存session状态，但是不建议在此处存储seession * 服务层 应用集群部署，多实例 * 数据层 数据库集群  关于多活的设计可以参考下图，是阿里李运华的。  至于同城多活和异地多活的优劣，可以参考下图。  # 引用 * [饿了么异地多活技术实现（一）总体介绍](https://zhuanlan.zhihu.com/p/32009822)
# 传统安全的思考 安全这么多年了，似乎是没有什么实质性的变化。而唯一的诀窍似乎也是层层防御。我这么多天来一直在思考传统安全的变革何在，如何用新的技术改变。无论是从方法论还是从架构实施等方面。也读了一些文章。在这个行业中，加之从业人员水平参差不齐，大多数更是水的全靠一张嘴。 传统安全的改进点，纵观这几年。只能说是整个防御线提前，伸出触角。比如说之前的安全防御在威胁情报上不是很强。然后现在把其作为防御能力或者说感知能力提到安全防御的最前面（不一定是指落地的最前面，而是指整条防御线的最前面）。然后落实纵深防御，可是方法还是那一套。只不过是随着时间的变迁，技术的变迁。从收集log到存储log的方式都发生了变更，同样在架构上也产生了新的变化。比如redis和memcache的使用，elasticsearch的使用。有能力的公司则是根据自己的实际情况，进行造轮子，或者研发出新的产品。然而随着这些产品的使用，又会不断的暴露出新的安全隐患。而"吹嘘"正胜的AI呢，在这个环节中，似乎已经是开始助力的时候，但也没有大规模的落地，不过我相信AI作为基础设施，在未来一定是会无处不在的。 至于安全运维，似乎也是没有大的进展，AIOPS的概念可以吹一年。当然也不排除大厂落地的可能。看到大厂分享的文档上说利用怎么怎么样达到AutoOPS。据我思考来看，也只是对一些metric数据进行了分类，避免传统过程中仅仅是通过单项或几项指标去手动操作，而可以通过自动分类的情况下进行扩容等操作。 应急响应的话，老一套，如果能预先感知，在落地前发现，在网络层拦截，去避免掉攻击，那也就没有应急响应了，至于应急响应的系统，似乎是没有什么大的改进，无论是Google的FIR还是GRR等，都不是很好用，也谈不上智能，仍然是需要团队去运营的。 方方面面，均未看到有什么新的发现，在应用安全和业务安全上的对抗随着技术的变更都在不停的变化，其他方向也是，但是技术虽有变化，传统安全却依旧如此。 AI引入也确实能解决问题。或者，是不是说，我们已经身处变革之中，却未有所意识，但传统安全的新变革绝不是将已知的各个模块在防御的时间线上，拉长或者扩大。变革的出路在哪里，有待思考。 Other: 据之前看到的一篇文章说，安全行业的下一个风口应该是做对抗模拟。 # 拧螺丝的工作 小公司的话需要面面俱到，都能独挡一面。不过现实中更多的是在小公司中没有很好的接受系统化工程化的项目，导致野路子出身。对于安全来说，似乎不是很明显。但是当一旦进入大公司之后，可以明显的看到，从之前的发散式立马转变到了专一的，或者乏味的，重复的拧螺丝之中。 俗话说的招人造火箭，进去拧螺丝就是这个意思。对我而言，刚刚进入饿了么，接触到团队类型的安全工作。之前的安全工作可以说只局限到1-3个人。而现在安全团队内纯职能就有20多人，各个分工也是明确。于是乎，接到的任务也就颇为单调。似乎会让人觉得无奈，和开始思考职业道路，人生道路。 于是，经过思考，我决定，把这份有点单调的工作，先自动化流程起来。然后去推进集团内改进该平台。与此同时，继续学习安全架构，及整体的安全大局观。当然，这也就是我为什么一直在思考传统安全的变革之处。在之前，我所建设的整体的安全，和此处来看，就是他把我要的做得全部落地了。从量上发生了变化，但是质的变化，还是有待变革。整个安全行业均是如此。 似乎是安全的发展步伐慢了点。我怎么这么菜！！ 福利，关于我对反爬的思考面面观，大部分是经过实操的。 有时候，想要变革或者说创新真的很难。
打算通过批量生成进行编码后的`payload`作为数据集，进行训练自动提取IOC规则。或者自动训练出分类器进行识别。当然脚本中我不仅采用了不同的编码格式还采用了不同的文件格式，其实也可以不需要。不过目前只是针对`linux`平台的做了输出。将`$(grep linux $PAYLOADSLIST)`替换为`$(cat $PAYLOADSLIST)`即可输出所有。 关键的命令无非是分别列出各项支持的条目，然后进行输出。 * `msfvenom -l formats` * `msfvenom -l encoders` * `msfvenom -l payloads`  完整脚本如下，根绝自需修改。 ```bash #!/usr/bin/env bash ENCODERSLIST='encoders.list' PAYLOADSLIST='payloads.list' # also you can use `msfvenom...
Update: you can find script [here](https://github.com/mylamour/IlI/tree/master/tgimgsave) This is a simple image file download from telegram channel step1 : my.telegram.com去申请api step2: pip install telethon step3: use telethon download image from channel,...