安全防护

引言如果您仔细分析过任何一个网站的申请日志，您必定会发现一些可疑的流量，那可能就是爬虫流量。依据Imperva公布的《2023 Imperva Bad Bot Report》在2022年的所有互联网流量中，47.4%是爬虫流量。与2021年的42.3%相比，增长了5.1%。在这些爬虫流量中，30.2%是歹意爬虫，比2021年的27.7%增长了2.5%。 从国内外公开的数据中能够得出，歹意爬虫简直呈现在各个行业，无论是传统行业、泛互联网，还是政企、金融等，都各种水平蒙受着爬虫的攻打，并且爬虫流量还在逐年增长。 大部分失常的爬虫能够帮忙咱们进步生产力，而歹意的爬虫不仅会造成数据透露还会影响失常用户体验。适合的反爬服务可辨认歹意爬虫并拦挡，京东云WAF的BOT治理提供了多种爬虫防护性能。 歹意爬虫的危害爬虫（Web Crawler），又称网络爬虫、网络蜘蛛、网页蜘蛛，是一种自动化程序或脚本，用于在互联网上主动地获取网页内容，并从中提取信息。 爬虫分为非法爬虫和非法爬虫或歹意爬虫。非法爬虫是恪守网络道德和法律规定，以非法、合规和敌对的形式运行的网络爬虫。这些爬虫在进行数据采集和信息获取时，遵循网站的robots.txt协定，尊重网站的隐衷政策和应用条款，以及恪守相干的法律法规。非法爬虫的目标通常是为了收集网站上公开可见的信息，并且爬取的频率和速率是正当且可控的。这些爬虫的应用合乎网站的拜访规定，不会对网站造成重大的带宽压力或资源节约。例如平时咱们用的百度、必应等搜索引擎就离不开爬虫，搜索引擎爬虫每天会在网络上爬取大量的网页进行剖析解决收收录，当用户通过关键词搜寻时，就会依照肯定的排序把相干的网页快照展示给用户。 歹意爬虫是一类不恪守网络道德和法律规定，以非法、破坏性或无害的形式运行的网络爬虫。这些爬虫通常不遵循网站的 robots.txt 协定、不尊重网站的隐衷政策，以及不恪守网站的应用条款和服务协定。歹意爬虫的目标可能包含但不限于： 破绽探测：攻击者利用爬虫程序扫描网站寻找破绽，利用破绽可实现网站提权装置后门等。数据盗取：攻击者部署爬虫非法的形式获取网站的敏感数据、个人信息、商业秘密等，可用于欺诈、垃圾邮件、身份偷盗等不良用处。刷票、薅羊毛：攻击者通过爬虫程序抢优惠券、秒杀商品等，影响流动成果。明码撞库：大规模暴力破解或撞击明码，获取用户账户的拜访权限，对网站用户的账户平安造成严重威胁。暴力破解：攻击者利用大规模僵死网络，高速、大规模攻打网站，导致服务器过载、带宽节约，影响网站的失常运行。综上，歹意爬虫对网站和企业影响重大，轻则影响网站失常运行重则影响企业失常经营。因而，通过部署反爬服务阻止歹意爬虫申请，爱护网站免受威逼十分重要。京东云WAF Bot治理提供了多种爬虫防护伎俩，可无效帮你应答各种爬虫。 歹意爬虫防护——京东云WAF Bot治理京东云WAF Bot治理反对对爬虫程序进行甄别分类，并采取针对性的流量管理策略，例如，放行搜索引擎蜘蛛流量，对歹意爬取商品信息、秒杀价格、库存信息等外围数据进行阻断，还能够应答歹意机器人程序爬取带来的资源耗费、查问业务数据等问题。 京东云WAF提供了常见爬虫UA库，提供11大类上百种商业爬虫防护，可疾速高效拦挡这类爬虫。 京东云WAF提供了歹意IP惩办，联合Web攻打防护利用大数据算法，可及时辨认并拦挡歹意IP扫描行为，无效防护漏扫描、文件遍历等爬虫行为。 京东云WAF反爬虫引擎利用算法和模型主动学习并剖析网站申请流量，提供了宽松、失常、严格3种等级的防护模式，并反对配置配置察看、人机交互、拦挡返回自定义页面等，可无效防护数据类爬虫和刷券类爬虫。 京东云WAF提供了账户平安，通过提取申请中的账号和明码主动剖析，可无效防护弱明码探测、暴力破解和撞库攻打。 京东云WAF提供了IDC威逼情报，可拦挡云上有过歹意行为的IP拜访；伪造蜘蛛情报，可拦挡伪装成搜索引擎蜘蛛的爬虫申请。 京东云WAF提供了伪造UA评分，可辨认歹意爬虫伪装成浏览器的申请行为。 京东云WAF提供了自定义BOT规定，反对多种条件叠加、同时还能够叠加前端技术、叠加威逼情报，联合多维度频次统计，可灵便反对多种业务场景下的爬虫行为，为攻防反抗提供了可配性。 2023年H1，京东云WAF帮忙云上多个客户防护了上亿次爬虫攻打，攻打的峰值QPS达到20W+/s。攻打的伎俩和目标也多种多样，有挂小区基站IP池的、有伪装成失常用户的、有常态化扫描探测的、有刷优惠券的、有刷特价商品的、有爬商品价格的。 前段时间云WAF有个客户发优惠券，刚开始的时候刷子利用私有云的函数服务和云主机刷券，客户开启云WAF的IDC威逼情报轻松应答；刷子降级了策略应用了小区基站IP池伪装成Chrome浏览器用户大量的申请优惠券接口，领导客户开启了反爬虫引擎并配置了自定义Bot规定，平时的峰值QPS只有2K，发券时候峰值QPS打到了11W。5分钟进来1405W申请，云WAF拦挡了1401W。其中被反爬虫引擎辨认了59%，被自定义BOT规定拦挡了38%，被威逼情报拦挡了3%，辨认并拦挡歹意爬虫率达到99.7%。 总结互联网上一半的流量来自于爬虫，如果您的网站没发现爬虫行为或者您的网站正蒙受歹意爬虫攻打，那么您能够试试云WAF的爬虫治理，不仅能够帮您发现爬虫行为还能够帮您防护爬虫攻打。具体能够参考：官网文档。 作者：京东科技 李文强 起源：京东云开发者社区 转载请注明起源

很久没在思否社区公布博客了，最近一段时间平安代码审计做的比拟多，因而在社区谈谈认识。在软件开发过程中，C语言作为一门根底语言应用宽泛，但也因为其自由度高、指针操作不便等特点，成为编写容易受到攻打的代码所抉择的首选语言。因而，C代码平安审计工作的重要性也就愈发凸显。本文次要从参数和指令查看、输入输出查看、字符串函数安全检查、指针越界查看、函数返回值查看、用户数据长度查看以及数据格式查看七个方面讲述C代码平安审计的基础知识。 参数和指令查看在C语言代码中，有很多函数须要应用命令行参数和环境变量参数，如command: argc argv和环境变量获取函数getenv()。参数的平安校验包含数据类型、指令格局长度等的查看。常见的最容易出破绽的argv[1]参数指针援用也可能会导致缓冲区溢出、整数溢出、越界等破绽。在代码中进行判断能够无效防止此类破绽，如下代码： if (argc != 2){ /* 参数个数谬误，请从新输出 */ return 0;}else if (strlen(argv[1]) >= MAX_LEN){ /* 参数长度谬误，请从新输出 */ return 0;}输入输出查看C代码中有一些函数会读写文件数据或者网络数据，如read()、fscanf()、getc()、fgetc()、fgets()、vfscanf()、scanf()、getchar()等。其中，gets()函数在遇到EOF字符或换行字符之前，不会进行读取文本，也就是说gets()函数会产生缓冲区溢出，因而绝不要应用gets()函数。对于其余读写函数，也要进行输入输出查看，以确保数据安全。如下代码： if (scanf("%d", &num) != 1){ /* 输出格局谬误，请从新输出 */ return 0;}else if (fwrite(buffer, sizeof(char), BUFFER_LEN, file) != BUFFER_LEN){ /* 写入文件谬误 */ return 0;}字符串函数安全检查C语言中字符串函数应用范畴宽泛，而其中较为容易出问题的就是strcpy() 和 strcat()函数。这两个函数都须要指定具体复制字符的数量，否则可能会造成缓冲区溢出。若源字符串来自于用户输出且未限度其大小，则更须要进行安全检查。如下代码： if (strcpy(dest, src) == dest){ /* 复制胜利 */}else{ /* 复制失败 */}指针越界查看指针和数组都是常见的野指针或越界拜访数据的问题，因而须要进行指针和数组的边界查看，以保障程序的平安。如下代码： if (i > 0 && i < arr_size){ /* 失常拜访 */}else{ /* 越界拜访 */}函数返回值查看在应用内存调配函数时，如malloc()、calloc()、realloc()和new()，必须要保障正当应用或开释，否则会产生堆缓冲区溢出和UAF开释重用破绽等。对于其余函数的返回值也须要进行查看，以保障代码运行的正常性。如下代码： ...

目录构造Deep Link介绍 概念利用场景提取并调用APP中的Deep Link 办法一：从AndroidManifest中提取办法二：应用MobSF办法三：应用Frida办法四：网页调用攻击面剖析 URL无验证弱主机验证窃取本地数据其余 弱主机验证-升级版防护倡议 参考链接 1.1. Deep Link介绍1.1.1. 概念Android Deep Link（深层链接） 是一种非凡的链接协定，次要用于在应用程序之间导航和交互，应用 Deep Link 能够从一个APP跳转到另一个APP中相应的页面，实现APP间的无缝跳转。 举个大家相熟的例子，浏览器关上知乎时，会提醒“关上App”，点击后，如果装置过知乎则会间接跳到利用的对应页面，如果没装置则跳转到下载利用页。 不过须要留神的是，下面的 *没装置则跳转到下载利用页* 是 Deferred deeplink（提早深度链接），他和根底的deeplink相比，如果用户没有下载APP，则疏导用户下载安装该APP，且在装置启动后立刻跳转到指定的页面或性能中。 Deferred Deep Link 能够进步用户的体验和应用程序的转化率，因为它能够让用户间接跳转到指定的页面或性能，而无需手动查找。 1.1.2. 利用场景一键跳转： 在利用外部或利用内部间接跳转到指定页面或执行特定操作的性能。传参装置： 在利用市场或者推广渠道传递参数，以便在用户装置利用后，利用能够依据传递的参数主动进行初始化或者展现特定页面。分享闭环： 在利用内分享一个商品链接，用户点击链接能够间接跳转到商品详情页面。无码邀请： 在利用内点击邀请好友的按钮，能够生成一个惟一的邀请链接，并在邀请过程中跳转到利用内的注册页面。渠道追踪： 通过deeplink跳转到利用市场，能够记录该用户从哪个推广渠道下载利用，并将该信息传递给利用后盾进行数据统计和剖析。1.2. 提取并调用APP中的Deep Link测试APP：https://github.com/hax0rgb/InsecureShop/releases 1.2.1. 办法一：从AndroidManifest中提取在AndroidManifest.xml中寻找android:scheme 能够看出，应用insecureshop://com.insecureshop/能够启动com.insecureshop.WebViewActivity这个组件。 1.2.2. 办法二：应用MobSF 1.2.3. 办法三：应用Frida通过frida hook进行监听，js脚本如下 //Modified version of <https://codeshare.frida.re/@leolashkevych/android-deep-link-observer/>//frida -U -p pid -l script.js// Define a global object to store previously seen intentsvar seenIntents = {};Java.perform(function() { var Intent = Java.use("android.content.Intent"); Intent.getData.implementation = function() { var action = this.getAction() !== null ? this.getAction().toString() : false; if (action) { // Create a unique key for the current intent by concatenating its action and data URI var key = action + '|' + (this.getData() !== null ? this.getData().toString() : ''); // Check if this intent has been seen before if (seenIntents.hasOwnProperty(key)) { return this.getData(); } else { // Mark this intent as seen by adding it to the global object seenIntents[key] = true; console.log("[*] Intent.getData() was called"); console.log("[*] Activity: " + (this.getComponent() !== null ? this.getComponent().getClassName() : "unknown")); console.log("[*] Action: " + action); var uri = this.getData(); if (uri !== null) { console.log("\\n[*] Data"); uri.getScheme() && console.log("- Scheme:\\t" + uri.getScheme() + "://"); uri.getHost() && console.log("- Host:\\t\\t/" + uri.getHost()); uri.getQuery() && console.log("- Params:\\t" + uri.getQuery()); uri.getFragment() && console.log("- Fragment:\\t" + uri.getFragment()); console.log("\\n\\n"); } else { console.log("[-] No data supplied."); } } } return this.getData(); }});hook ...

在任何新的软件开发我的项目开始时，您就应该思考软件平安。开始一个新我的项目或者会令人望而却步，因为有许多的决定要做，有许多想法必须思考分明。通常来说，这些决定和想法包含了定义我的项目需要、抉择正确的流程、抉择正确的工具以及确保软件平安。 为此，Perforce提供了一个循序渐进的分步指南，疏导您实现一个新我的项目中最耗时和最艰难的挑战，帮忙您的我的项目获得成功。 开发安全软件所需的平安编码实际一个平安的软件开发最佳实际能够简略地分为以下四个次要局部： 理解您的我的项目需要；定义您的软件开发流程；为您的项目选择适合的工具；设置DevSecOps。像Perforce公司的动态代码剖析（SAST）工具Klocwork能够在每个局部帮忙您满足举荐指南的要求。 理解您的我的项目需要在我的项目开始时，有几个因素是须要您思考的。通过扫视这些因素，您能更好地理解我的项目需要。 我的项目概述 首先，您须要花工夫理解我的项目自身，并提出有助于领导整个开发生命周期决策的问题。比方： 正在开发的是什么类型的我的项目？（嵌入式、云服务、前端/后端软件等。）这个我的项目是针对哪个行业的？（汽车、航空航天、企业、医疗、金融等。）该软件将如何应用，以及在什么环境下应用？（企业、中小企业、B2B、B2C等。）定义我的项目愿景 对应用程序将提供什么内容有一个构思，这有助于设定指导性的工作指标。通过制订一个针对客户问题、痛点以及应用程序将如何解决这些问题的明确阐明，有助于确保您提供的解决方案是正确的。 确定合规性要求 你须要确保作为我的项目的一部分，行业、供应链、业务或客户需要是否存在代码合规性要求。 此外，您还须要确定须要什么级别的保障、平安或品质合规性。这可能包含以下编码标准： CWECERTCVEOWASPDISA-STIGMISRAAUTOSAR从我的项目开始时就抉择并遵循一个规范，就能缩小将来将面对的合规性难题。 抉择灵便的编程语言 确保您的编程语言（无论是 C、C++、C#、Java 还是 JavaScript）是最适宜您的我的项目的。抉择最合适的编码语言能为您带来以下益处： 易于开发；代码的可维护性；能够接触到纯熟的开发人员；明确的编码标准和最佳实际。抉择什么语言能够决定您的软件是否放弃互相关联，以及放弃生命力。 制订设计规范 花点工夫来制订一个设计规范，这样您就能验证零碎逻辑，确定所有组件是否可能正确地一起执行，并帮忙确保软件平安。这可能就是胜利的发行与代价微小的从新设计之间的区别。 建设代码架构 布局出您的代码库，确保其东倒西歪。请务必思考以下事项： 文件命名规定；为我的项目定义模块；档次和构造。提前完成了这项工作，您就为开发人员提供了一个清晰的模板，让将来能更轻松地进行保护。 定义软件开发流程尽管对于您的我的项目需要和要求来说，软件开发流程是举世无双的，但建议您思考以下几点： 确定须要施行哪些软件平安最佳实际 依据行业的不同，您的开发我的项目可能须要遵循特定的最佳实际和规范。此时，您应该让我的项目要求与开发过程保持一致。这可能包含遵循性能平安规范（如IEC 61508）和平安编码实际（如CERT或CWE）。 像Klocwork这样的动态代码剖析工具能够帮忙您践行我的项目可能须要遵循的任何规范、最佳实际和条件。 对立开发方法 无论是麻利或瀑布，Scrum或看板，还是您目前采纳的任何其余办法，这都无关紧要。重要的是，您要使开发过程与您的业务、开发人员和开发团队打算交付我的项目的形式保持一致。 对立办法的目标是为了有一个确保组织和沟通的过程，并帮忙避免开发过程中呈现的问题。 设置您的环境 一般来说，确定并创立我的项目所需的环境来确保整个团队应用雷同的设置十分重要。最佳实际表明，应该为开发、用户验收测试(UAT)、预发和生产设置独自的环境。 应用存储库工具 应用版本控制工具（如Perforce Helix Core）来建设源代码存储库，让您的开发团队可能： 缩小解决工具和流程的工夫；防止在手动工作流程上浪费时间，使他们可能从新开始编码；高效解决数以万计的文件以及PB级的数据；将代码中更改的内容与更改起因分割起来。除了代码存储库之外，您还该当思考应用其余工具或流程来存储和跟踪其余与我的项目无关的内容。这包含： 将我的项目应用的工具和组件放在整个团队都唾手可得的中央；为打算、文档和开发人员入职培训提供一个外围地位；在项目管理软件（如 Helix ALM）或问题跟踪软件中定义工作工作。通过建设这些存储库，您能确保您的开发高效、内容平安，并且常识易于获取，新开发人员能疾速上手。 通过平安编码实际增强软件平安 通过遵循平安编码实际，在开发过程中构建平安执行，并应用平安编码工具帮忙强制执行合规性。此外，您须要为团队提供平安培训和学习材料，倒退平安文化。 将查看纳入开发流水线中 在整个开发流水线中施行安全检查，有助于强制执行良好的编码实际。在开发代码时，请务必时刻放弃安全意识。建议您在开发人员的IDE、CI/CD流水线以及夜间集成构建期间应用SAST扫描。 出于测试和重构目标，请确保让开发人员编写单元测试，质量保证人员编写功能测试。请思考所有可能的测试策略，并尽可能地创立并自动化平安和其余测试。 对您的我的项目工作和性能有一个“实现”的定义 即便工作或性能看起来曾经实现了，并曾经在开发人员桌面上编译了，也是不够的。你须要有一个明确的流程来定义工作——从头到尾。 最佳做法包含以下几点： 需要捕捉；工作范畴；定义验收规范；为代码开发单元和性能测试用例；进行同行代码评审；对集成测试、平安测试以及直到最终环境测试的所有阶段进行自动化测试。激励反馈和沟通 团队和开发人员之间的反馈和沟通对于我的项目是否胜利起着关键性作用。 重要的是，让您的开发人员可能在代码提交后取得疾速反馈，他们能力及早解决编码问题，并为其余相干人员提供无关我的项目进度、指标和潜在危险的信息。 除了自动化，为开发人员提供足够的工夫进行代码审查、布局和回顾也十分重要。这些都将有助于确保高速开发，因为不会再有交换不畅的状况了。 为您的项目选择适合的工具我的项目中还有一个重要局部是抉择正确的工具。工具的抉择很重要，因为它有助于将我的项目标准化，并使团队中的每个人都能“同频交换”。它从以下四个方面为整个团队带来了益处： 生产力；造成共识；测试和调试；更易上手。为了帮忙确保为团队抉择的工具集是最无效的，您须要思考以下几点： 钻研和查看所有工具选项，并依据我的项目和团队要求对其进行评估；理解工具抉择的成熟度以及有哪些类型的反对，如技术支持、帮忙资源和被动保护；思考工具、团队的教训程度以及招聘新开发人员的能力将受到怎么的影响；查看工具集之间的兼容性。无论您抉择哪种工具集，都倡议它包含以下内容： 代码存储库和版本控制，用于跟踪和治理对源代码、数字资产和大型二进制文件的更改；SCA和SAST工具，用于强制执行平安编码实际，并辨认缺点、破绽和合规性问题；应用程序生命周期管理工具，在我的项目的整个应用程序生命周期治理中提供端到端的可追溯性。为您的软件开发我的项目建设DevSecOpsDevSecOps是一项必不可少的软件平安最佳实际，它将DevOps的速度和规模与平安编码实际联合起来。通过采纳DevSecOps办法，您能够： 尽可能多地自动化流程——平安、配置、治理、测试等，开发人员就能腾出工夫专一于开发新的代码和性能；定义胜利/失败指标，并被动监控和报告我的项目后果。这有助于您更快地发现问题和破绽，做出更理智的决策，并在整个应用程序中强制施行我的项目要求；采取措施爱护您的基础架构。安全性不仅对您的最终产品来说很重要，并且对您公司的程序和政策也很重要。确保您从整体上思考安全性，并从上到下推动平安文化；继续监控和执行软件平安合规性。将平安工具（如 SAST、DAST 和SCA）集成到 DevSecOps 流水线中，以便在整个开发生命周期中被动跟踪和执行平安规范。抉择Perforce工具，确保软件安全性和我的项目胜利用于C、C++、C#、Java、JavaScript、Python和Kotlin的SAST工具Klocwork能够辨认平安、品质和可靠性问题。这有助于强制恪守编码标准，确保代码免受安全漏洞的影响。Klocwork的设计易于扩大到任何规模的我的项目，它为你提供了在编写代码时主动进行源代码剖析的能力。 此外，Klocwork的差别剖析使您可能仅对已更改的文件进行疾速的增量剖析，同时提供相当于残缺我的项目扫描的后果。这会帮忙您缩短剖析工夫。 通过应用Klocwork，您还能播种： 在开发晚期发现代码破绽、合规性问题和规定抵触。这有助于放慢代码审查和手动测试工作；执行行业和编码标准，包含CWE、CERT、OWASP和DISA STIG；随时报告不同产品版本的合规性。作者简介： 斯图尔特·福斯特（Stuart Foster）Klocwork和Helix QAC产品经理，Perforce ...

背景介绍容器化迁徙目标随着易盾反垃圾业务的迅速倒退，业务集群的规模也在急剧增长，传统的通过物理机来部署的形式在灵便度上越来越达不到要求，次要痛点包含但不限于：资源利用率低、集群扩容/缩容老本高、业务集群混合部署导致故障不隔离等，因而，急需一种更好的形式来晋升运维和环境治理的效率。时至今日，容器化的伎俩曾经十分成熟，并且可扩展性、敏捷性、故障隔离等方面正是容器化的劣势。同时，网易团体的云计算部门基于 K8S 研发的轻舟平台与运维团队研发的诺亚平台为此提供了弱小的底层反对技术，易盾业务集群容器化堪称瓜熟蒂落。 容器化迁徙架构迁徙的架构如下图所示，下层 nginx 分为杭州和建德两个集群，不便在不影响客户应用的状况下进行整体性能回归。业务服务全副迁徙，波及利用集群 100+。底层中间件、ddb 和 es 专用同一集群，保证数据的一致性。 容器化迁徙流程整个迁徙流程一共分为方案设计、模块部署、功能测试、性能测试、故障演练、流量比照、灰度切流、DNS 切换等八个步骤，上面咱们次要围绕流量比照这个步骤进行开展。 痛点与窘境 驱使咱们去做流量比照的起因一共有四个。• 第一，迁徙模块多、危险高，反垃圾的检测链路很长，两头波及到很多模块，两头任何一个模块出问题都会影响最终返回给客户的检测后果，咱们的保障覆盖范围须要包含整个链路。• 第二，补充线上回归用例笼罩不到的场景，目前线上回归用例通过 Goapi 保护，笼罩了所有业务以及检测器，然而做不到百分百笼罩到所有的线上逻辑。须要额定的伎俩去做补充。• 第三，开发侧的诉求，在迁徙计划的评审阶段，开发就提出诉求，上线前心愿能通过某种形式比对新老集群的流量，用大数据量去尽量笼罩到所有场景。• 最初一个起因不足成果测试伎俩，心愿通过这个流量比照做到对成果测试的回归。 流量比照实际计划选型引流平台引流平台是一个基于用户理论应用行为和应用数据，作为测试用例和数据的全自动接口效力工具。平台通过将线上用户的实在流量复制并使用于自动化回归测试当中，期间通过翻新的 Mock 机制，能够应用线上数据在测试环境实现增删改查所有类型的接口测试。应用海量用户数据，实现业务逻辑的高笼罩和精准笼罩，是现有接口测试伎俩一种无效增益伎俩。引流平台不仅可能实现低成本的日常自动化回归，同时能通过它提供的扩大能力支持系统重构降级的主动回归。 引流平台的劣势：• 不须要额定的开发成本；• 能获取到用户实在流量；• 可视化操作、性能全面； 引流平台的劣势&危险点：• 代码加强后利用响应工夫增大、TPS 升高（易盾客户对响应工夫十分敏感）；• 只反对单利用流量录制，不反对全链路；• 不反对依据条件获取指定流量； 思考到对利用性能影响以及不反对全链路，没有抉择引流的计划，然而这种思路值得咱们去借鉴。 自研工具确定指标P0需要：• 不影响线上利用性能、RT、TPS 等；• 反对全链路流量比照；• 反对历史流量回放；• 反对指定流量获取；P1需要：•尽量低的开发成本；•反对后果报告； 2. 性能拆分&流程设计性能拆分为四个模块，别离是数据获取、数据发送、后果比对和报告生成，各模块之间的交互流程如下图所示： 性能实现样本获取样本起源为了保障样本数据的真实有效并且能保持数据的新鲜度，间接把线上数据作为起源之一。QA 的音视频仓库也是数据起源之一，仓库外面存储了结构的各种格局和时长的音视频数据。除此之外还反对 EXCEL 上传的办法，上传以及标记好的 Case。 样本筛选想要获取指定类型的数据，能够通过不同字段的组合设置，在获取数据的时候，会依据字段属性进行筛选，保障获取线上样本丰盛度。譬如：targetId=8544&hitType=10&spamType=100&requestRegion=cn-beijing指定了获取业务 ID 为 8544 从北京发送的数据且命中了规定检测器且垃圾类型为色情的数据，最初获取的样本都合乎上述条件。 样本解决因为原始数据的字段很多，有一些字段不影响检测成果，譬如 callback、publishTime 等。这些抽取的样本会存数据库，为了缩小样本大小，须要将这些额定字段解决掉。有些场景须要和样本历史命中后果做比对，因而这里咱们还要把原来的命中信息作为验证字段存起来，前面用来做比对。 模块流程设计数据发送计划选型发送数据就是通过什么形式把什么数据往哪里发，数据咱们通过下面样本获取的模块曾经拿到了，接下来就是解决发送形式和发送地址的问题，这个性能正好是 Goapi 所具备的，秉承着不反复造轮子的理念，在评估过自研和间接用 Goapi 的优劣，咱们间接通过 Goapi 的 OpenApi 接口来实现数据发送的操作。 交互流程平台与 Goapi 交互流程大抵分为 6 个步骤：• Goapi 创立数据驱动的场景用例/单用例，前面数据发送都是基于此用例；• 获取用例 ID，在平台增加此用例（后端会依据 ID 调用 Goapi 接口查问用例信息）；• 更新数据驱动数据（步骤 3~6 是循环，直到所有样本跑完）；• 触发用例执行；• 轮询工作执行状态；• 获取执行后果并保留； ...

“2022可信隐衷计算峰会”于今日在北京顺利举办！会上中国信通院云计算与大数据研究所副主任闫树正式启动隐衷计算联盟互联互通推动打算，蚂蚁团体成为首批退出该打算的成员；同时峰会还公布了"隐衷计算跨平台凋谢算法协定第一局部：ECDH-PSI"，本次互联互通成绩由蚂蚁团体、中国移动、洞见科技依靠隐衷计算联盟互联互通推动打算进行了实际，相干代码实现已在隐语开源社区正式公布。 成绩详解 隐衷计算实现简单，品种繁多，需依附协定簇的系列规范做到全面互联互通：互联互通凋谢协定簇由多个子协定组成，每个子协定对隐衷计算的某一方面做了规范化和标准化，这些子协定组合起来能力使隐衷计算算法真正做到全行业的互联互通。对于单个凋谢协定而言，分为算法握手和算法执行两个步骤。握手流程实现通用算法类的参数算法对齐，平安原语相干的参数对齐。算法执行阶段包含本地算法计算，替换两头信息，实现异构平台之间的互联互通。 蚂蚁团体，中国移动，洞见科技依靠隐衷计算联盟互联互通推动打算，首先启动了基于ECDH-PSI的凋谢协定的设计与实际，隐衷汇合求交PSI，不仅能够独立应用实现联结剖析，同时也是联结建模的第一个步骤样本对齐的外围算法。 ECDH-PSI 凋谢协定架构介绍 ECDH-PSI 算法概述： ECDH-PSI的算法流程如图所示，包含五个步骤: 第一步：参与方在本地计算原始数据(如ai)的杂凑值，并将杂凑值映射到椭圆曲线上的点，而后加密失去数据(如P1i); 第二步：参与方将加密后的数据的传输给其它数据提供方，如参与方A将P1i传输给数据 提供方B; 第三步：参与方对在本地应用本人的私钥对步骤二中接管到的数据进行二次加密; 第四步：如果后果对另一个参与方可见，将步骤三中加密后的数据传输给另外一个参与方; 第五步：参与方本地计算汇合求交的后果。 注:加密指基于椭圆曲线的点乘算法和本地的密钥(如keyA)，对数据实现加密。 ECDH-PSI 算法流程： 专有协定 ECDH-PSI 分为2个阶段，握手阶段和算法主体运行阶段。 握手协定俱备的能力： 确定交互互通的算法确定运行所需参数，包含算法参数和平安原语相干的参数为缩小所应用的RTT，握手协定在一次交互中实现 算法主体基于握手协商的参数实现 PSI 计算 本次互联互通实际有三大亮点：国密算法兼容反对，算法平安公开通明，通信+互联网两个行业的三方互联。基于该实践经验，联结公布隐衷计算跨平台互联互通凋谢协定第1局部：ECDH-PSI 的协定文稿，同时相干实现代码已在隐语社区上开源公布，不便行业借鉴参考。 02 成绩共享 隐语深度反对凋谢算法协定： 隐语的算子原生反对凋谢协定，凋谢协定算子不是一个 demo，而是生产级可用。通过开源，隐语给出了凋谢协定的一种参考实现，帮忙行业更好地了解协定的内容。 互联互通文档地址： https://www.secretflow.org.cn...\_CN/index.html ECDH-PSI互联互通凋谢协定开源地址： https://github.com/secretflow... 隐语ECDH-PSI参考实现地址： https://github.com/secretflow...\_psi.h 成绩价值 以后隐衷计算企业百余家，产品出现百花齐放的状态。大多数产品异构闭源独立倒退，产品技术实现差别较大，造成跨平台无奈互联互通数据的计算孤，给数据利用各方带来了零碎反复建设和运维成本增加的问题。互联互通是升高隐衷计算产品部署老本、实现规模化利用的事实需要、和构建数据流通基础设施的必要根底。 隐衷计算的互联互通须要满足信息互通、平台自治、实现平安、后果正确、易扩大等个性。隐衷计算协定互联大抵能够分为两类：算法调度协定互联和凋谢算法协定互联。算法调度协定互联，即俗称的黑盒算法迁徙模式；凋谢算法协定互联，即俗称的白盒算法对齐模式。在理论应用中，“算法调度协定互联”和“凋谢算法协定互联”可组合应用。 当下，业界的次要摸索大多集中在算法调度层的互联互通，这种形式是基于同一算法组件迁徙实现协同计算，无需公开算法实现，然而须要应用方对“算法插件”进行可信认证。而凋谢算法协定互联，则是基于同一算法的标准流程实现工作协同计算，标准的流程更加通明和凋谢，更容易建设多边的信赖，也能在隐衷计算市场上激发更为丰盛的能够互联互通、互相协同的算法实现，因而，这一首次对算法层互联互通的凋谢协定进行了的摸索实际具备冲破引领的技术意义。

墨菲平安 2.0 产品 3 月份公布以来过来了 9 个月的工夫，在这期间播种了超过 10000+ 开发者用户，700+ 的开源我的项目 star 以及包含蚂蚁、安全、快手等在内的数十个企业版客户；在这个过程中咱们一共收集到 283 个用户给咱们产品提交的 350 个反馈和倡议。 在12月8日，咱们也开启了3.0产品的内测，内测期间感激来自 31 个用户，反馈的 154 个问题及优良倡议，目前咱们曾经进行了新一轮的优化，明天正式公布产品 3.0 ，欢送大家体验新版本，如有任何问题或倡议能够随时反馈。 一、新&老版本的切换全新 3.0 产品波及了新老版本的更替，对于新老版本的应用能够参考以下地址。 对于新版本应用：登陆 https://www.murphysec.com/ 即可体验对于老版本应用：老用户能够持续登录 https://old.murphysec.com/ 应用，咱们会在将来几个月的工夫逐渐下线老版本，请您尽快切换至新版本二、性能更新概览1、开发工具接入形式反对更多接入形式及丰盛的工作流 反对 JetBrains IDE 插件、GitLab、 CLI 、指定仓库检测、GitHub、源文件上传、二进制上传等多种检测形式可通过配置 GitLab、GitHub 的 Webhook 实现继续检测反对配置检测后果的处理条件，达到预警将及时同步反对规范模式、深度检测、二进制检测、固件检测、容器镜像检测等多种检测模式反对破绽检测、许可证合规检测、SBOM清单下载 （检测工具接入） （检测后果展现） （子工作详情） 2、团队合作新增团队合作，可创立团队、多形式邀请别人退出团队等性能 反对创立多个团队、创立多个我的项目反对通过链接、团队成员、邮箱及手机号的形式邀请别人退出团队反对通过链接、团队成员、邮箱及手机号形式分享检测报告，可抉择“仅查看”、“退出团队并查看”两种权限模式 （创立团队） （分享检测报告） 3、缺点组件减少缺点组件残缺的引入、设置负责人、生成工单等性能 显示残缺的缺点组件引入门路，让组件起源高深莫测设置缺点组件负责人，可自在指定缺点组件相干人员实现修复反对将缺点组件的问题及修复计划生成工单并提交至Jira反对一键复制主动生成的缺点组件工单优化“一键修复”的UI展现，反对通过 IDE 插件修复及 GitHub 提交 PR 修复优化缺点组件及破绽的实在利用的展现模式（深度检测可展现） （生成并提交工单至Jira） 4、许可证危险减少许可证危险解读、许可证抵触等性能 反对通过危险解读，提醒须要重点关注的许可证展现抵触的许可证，让许可证危险无处隐匿5、SBOM 清单新增 SBOM 清单不同展现模式及导出等性能 可随便切换树状构造及列表模式来展现 SBOM 清单可将 SBOM 清单通过 spdx 格局导出 ...

程序员写出蹩脚代码的起因有很多，最常见莫过于为了按时实现紧急的我的项目，以及意识不到代码品质和最佳编码实际的重要性等。 外表上看，蹩脚代码能够满足实际操作，但从久远的角度来看，它们很有可能成为一颗“定时炸弹”。因为蹩脚代码一旦呈现问题，面临的不仅仅是金钱的节约，还有更多、更重大的结果。 作为SonarQube受权合作伙伴，创实信息继续关注代码品质与平安畛域的最新动静与实际，为中国用户带来寰球范畴内的优良解决方案，帮忙企业实现开发平安经营一体化。 您是否尝试通过走捷径来取得疾速的后果？尽管每个人都花工夫亲自动手做事是最好的，但事实是，人们会利用工具和教训来帮忙实现最佳后果。但这种办法也不是完满的，某些小问题会从缝隙中溜走。 您可能会感觉，在某个要害的截止日期前及时失去后果，而疏忽一些小问题可能造成的危险是值得的。但如果每次都这么偷工减料，被疏忽的小事件就会开始沉积。 寻找工具并建设常识体系来简化劳动是科技界的首要选项。快节奏的工作和来自下级的高冀望，都给开发团队带来了交付压力，甚至在构建代码库时呈现了问题，他们也不得不交付。在每个sprint中，您的团队面临的不仅是实时产生的问题，还有来自过来我的项目问题的困扰。蹩脚的代码不会自行隐没；而且如果您漠视它太久，它可能会破费您更多的金钱。 蹩脚的代码会带来代价昂扬的结果，但清洁代码实际会帮忙您克服这些挑战。

前言：技术倒退为时代带来改革，同时技术创新性对蜜罐产生推动力。 一、新型蜜罐的诞生 技术倒退为时代带来改革，同时技术创新性对蜜罐产生推动力，通过借鉴不同技术思维、办法，与其它技术联合造成优势互补，如引入兵家作战思维的阵列蜜罐，联合生物保护色与警戒色概念的拟态蜜罐，利用人工智能、大数据等工具进步防护能力的蜜罐等，试验证实翻新思维联合或技术劣势集成后的零碎具备较高的进攻性能、诱骗能力。(1）创新型蜜罐:借鉴兵家和平思维，石乐义等人提出阵列蜜罐进攻模型，采纳分布式自选举控制策略和UDP发言人同步机制实现协同管制和同步通信，将蜜罐与实在服务伪随机变换，造成动态变化的阵列陷阱，从而升高攻击者攻打有价值资源概率。 受到生物界爱护与戒备机制启发，拟态蜜罐计划被提出，蕴含3种服务类型:服务、蜜罐、伪蜜罐。依据攻打概率抉择蜜罐或伪蜜罐部署计划，其中，伪蜜罐用作警戒色吓退攻击者，而蜜罐作为保护色模仿实在服务，从而实现实在服务针对性爱护。此外，对拟态蜜罐进行了博弈推理，验证零碎有效性。 (2）多重交融蜜罐:在《An interface diversified honeypot for malware analysis》中Laurén等人利用多接口蜜罐进行恶意软件剖析，为最底层零碎调用提供双接口，即每个零碎服务都可通过个别零碎调用编号和窃密编号被拜访，同时，对入口点进行多元化配置。多元化接口性能将可疑攻击行为与失常零碎行为拆散，防止接口为攻击者所用。Saadi等人在《Cloud computing security using IDS-AM-Clust, honeyd, honeywall and honeycomb》提出一种新架构，应用蜜网、入侵检测技术、防火墙等在云环境下构建多重防护平安零碎。 (3）对流量进行访问控制操作，阻止歹意流量进入外部。作为系统核心组件，蜜墙将零碎划分为3局部:蜜罐区、以太网区、隔离区。其中，蜜罐区由一系列诱敌深入的Sebek,Honeyd组成，进行数据捕捉、管制、剖析。Sochor等人通过剖析比照时下高交互蜜罐钻研办法和开源计划，选取最优化计划并组建可利用工具来创立零碎，该零碎蕴含Linux Debian和Web server两种高交互蜜罐。 其中，Linux Debian蕴含大量无用数据和MySQL数据库等内容，若攻击者扫描零碎，将观测到Win-dows，Linux和Cisco路由，这些设施由Honeyd模仿仿真;Web server用以响应80端口申请，应用带有破绽的Web零碎进行监控。Mysql数据库将记录存储攻击者登录、命令执行、脚本运行等流动，并将数据可视化出现。 二、蜜罐为平安防护畛域提供更多抉择 面对互联网所诞生的多种新事物，蜜罐的多种性能进一步开发，蜜罐由对外性能由繁多诱骗指标逐渐进化，造成了更多、更简单的对外性能，如将蜜罐利用于明码模式探索、网络事件监控、未受权数据拜访判断、网等，为平安防护畛域提供了更多功能抉择。 (1)面向特定需要的性能蜜罐 ①Web平安:Buda等人针对Web利用P程序安全性问题，构建Web利用蜜罐，对数据进行存储，并将数据挖掘算法利用于平安日志剖析。 ②明码模式:Mun等人通过剖析社会工程学，创立蜜罐网站，联合网络钓鱼、偷梁换柱等攻打思维构建攻打场景并实现对用户明码的模式分析与破解。 ③网络监控:Vasilomanolakis等人l5提出一种蜜罐驱动的网络事件监控器，从散布于不同地理位置(欧洲、亚洲、北美)的蜜罐感应器中获取警报数据，应用HTTPS服务接收数据同时利用公钥基础设施(Public Key Infrastructure,PKI)认证感应器。 ④电子数据取证:王传极将蜜罐技术用于电子数据取证，构建蜜网拓扑，以TCPdump,Se-cureCRT和Walleye别离监听网关端口、仿真终端程序及剖析近程日志。攻防试验中，攻打方采纳X-scan扫描主机破绽，进攻零碎记录捕捉数据流，剖析X-scan扫描类型关联度，针对入侵者的扫描行为提供电子证据。 ⑤非法数据拜访:Ulusoy等人提出MapRe-duce零碎中未受权数据拜访检测的蜜罐模型，应用数据控制器依据理论数据生成蜜罐数据，并对实在数据和虚伪数据进行同步更新。在MapReduce部件获悉蜜罐数据地位信息的前提下，确保已认证部件拜访正确实在数据。蜜罐数据遍布整个零碎，当攻击者拜访这些数据时，将向数据控制器发送警报。 ⑥恶意软件剖析:Skrzewski等人对服务器端蜜罐恶意软件监控性能进行了探索，收集恶意软件流动信息须要蜜罐和我的项目代理，而两者信息都无奈齐全笼罩，因而须要一种全面性攻打信息视图。通过比对多种蜜罐零碎收集信息，得出结论:服务器端蜜罐零碎无奈作为未知威逼的信息收集源，而客户端蜜罐则可实现此工作。 ⑦蜜罐诱骗钻研:Sochor等人剖析蜜网拓扑模型、SSH仿真感应器攻打、模仿Windows服务攻打与Web服务攻打，钻研网络威逼检测中蜜罐与蜜网吸引力，即蜜罐甜度。试验表明平安进攻措施对引诱攻击者起到重要推动作用。 Dahbul等人利用网络服务指纹识别加强蜜罐坑骗能力，构建3种攻打威逼模型来剖析指纹识别潜在平安威逼，并在此基础上建设蜜罐零碎和实在零碎，通过凋谢和配置必要端口、固定工夫戳、配置脚本等伎俩对蜜罐进行系统性加强。 ⑧攻打剖析钻研:Sochor提出基于Windows仿真蜜罐的攻打剖析计划，部署蕴含6个Dionaea蜜罐的模仿Windows分布式蜜网，进行攻打捕捉，统计攻打连接数，分析攻击类型、攻打源地理位置及其所应用操作系统类型。剖析结果表明，中度交互蜜罐对自动化攻击方式更具诱惑力，此外，因用户漠视破绽修补，导致古老攻打威逼仍然流行。 (2)针对特定攻打威逼 针对特定攻打威逼，如APT、勒索病毒、蠕虫病毒、僵尸网络、零碎入侵、DoS与DDoS攻打等，蜜罐同样能够发挥作用。 ①　APT攻打:Saud等人应用NIDS和KFSensor蜜罐对APT攻打进行被动检测，当蜜罐服务被申请调用运行时，向控制台发送警报信息。 ②　带宽攻打:针对带宽攻打，Chamotra等人定义了6种不同蜜罐部署计划，其中，ADSL路由蜜罐用以验证部署计划有效性，该蜜罐是一种低交互蜜罐，在WAN接口上仿真Telnet，SSH,SIP和HTTP服务。 ③　路由攻打:刘胜利等人提出针对Cisco路由攻打的蜜罐CHoney，该蜜罐基于dynamips模拟器实现硬件平台虚拟化并运行理论Cisco IOS进步假装性，根据所收集攻打信息，进行敏感操作等级判断，并制订相应报警规定。 ④　垃圾邮件:针对垃圾邮件，郭军权等人设计了一种联合凋谢中继和凋谢代理服务性能的分布式邮件蜜罐，进行不同地区空间部署，保证数据采集全面性，建设多种攻打信息相干数据库，通过大量攻打样本剖析影响蜜罐邮件诱骗因素及攻击者行为模式。 ⑤　无指标大范畴攻打：针对无特定指标大范畴攻打，贾召鹏等人提出一种集成多个不同内容管理系统(Content Management System, CMS)利用的蜜罐计划，利用协同管制单元抉择适合利用蜜罐对攻打做出正当相应，通过记录、监控流量和文件，获知交互信息、文件操作信息及文件快照，进而实现攻打剖析。 ⑥　歹意URL及URL重定向:Park等人提出基于虚拟环境的利用客户端蜜罐，由蜜罐代理、Hy perviser、URL爬虫和主服务形成，剖析网站恶意代码URL。Akiyama等人针对歹意URL重定向间题发展了钻研，摸索其演化过程，建设蜜罐监控零碎，将零碎长期部署于理论网络中追踪URL重定向攻打信息。 ⑦　勒索蠕虫:Moore3将蜜罐技术利用至勒索蠕虫检测，应用两种服务操控Windows平安日志，建设针对攻打的分等级计划对策:第1级，监控文件夹批改事件，并及时向管理员发送邮件告知;第2级，检测到更多流动时，对攻打软件进行信息揣测标识，用户据此断开网络账户连贯;第3级，呈现更高强度流动时，将关停网络；第4级，敞开服务。 ⑧　蠕虫病毒:Agrawal等人受“影子蜜罐”启发提出无线网络下“影子蜜网”概念，即受爱护零碎实例。应用过滤器按照MAC表查看无线网络接入节点，并利用Ettercap，Wire-shark,Payload sifting 3种工具实现分阶段联结检测异样数据包。首先利用Ettercap检测抛弃未受权接入申请，若攻击者应用ARP坑骗技术，则持续利用Wireshark通过剖析数据流速率判断攻打，最初应用Payload sifting辨认并标识蠕虫病毒指纹，转向“影子蜜网”的蜜罐，进行充沛交互。 ⑨　僵尸网络:Al-Hakbani等人A4利用节点列表、IP地址坑骗和虚伪TCP 3次握手技术等攻破僵尸网络端身份认证，进步蜜罐主机接入僵尸网络的成功率。Chamotra等人4利用分布式蜜网捕捉数据进行僵尸机检测和僵尸网络追踪，输出位于地方服务器的恶意软件库，库中数据用于重建环境并在沙盒内运行。在此期间，记录本地API调用序列并编码解决，编码序列作为僵尸机检测输出数据，应用反对向量机分类器标识。利用二进制句法特色对所检测僵尸机施行聚类解决，聚类后的僵尸机群即为某个僵尸网络，使其运行在沙盒中，记录其属性并追踪溯源。 ⑩　零碎入侵:Olagunju等人创立一种蜜网零碎用以实时检测入侵行为，该零碎蕴含4个蜜罐主机、1个核心记录主机和1个工作主机。其中，蜜罐零碎由路由器、防火墙和Linux服务器组成，Linux提供了SSH服务以诱惑攻击者进行攻打;核心记录主机进行源地址、归属地和工夫戳相干入侵信息收集;工作主机用以装置、执行重复性服务。 ...

清洁代码（Clean Code）可能让软件开发工作变得更简略、更乏味。因为如果代码不够清洁，开发人员将破费很多工夫在解决编码问题上，使他们无奈将精力投入开发新代码、解决其余更乏味的问题上。SonarQube的边写边清洁（Clean as You Code）办法可确保您批改、更新或增加的代码不会引入新问题。您的代码品质会逐步进步，您也因而有更多的工夫来解决那些乏味的问题。作为SonarQube受权合作伙伴，创实信息继续关注代码品质与平安畛域的最新动静与实际，为中国用户带来寰球范畴内的优良解决方案，帮忙企业实现开发平安经营一体化。 在往年的早些时候，Sonar从新公布了他们的网站，并开始议论“清洁代码”——这个术语您之前可能偶尔应用或据说过，但可能尚未真正地领悟并领会其精华。本篇文章将为您带来对于清洁代码及其重要性的洞察。 世界在代码上运行软件是每个组织用于经营业务的外围所在。公司应该意识到他们软件的DNA——源代码——才是真正重要的货色。它是软件中最贵重的资产。源代码不仅领导应用程序的行为形式，还领导着应用程序的执行形式。放弃这个资产的“清洁”将有助于避免它成为一种累赘。 什么是清洁代码？在一个十分高的程度上，您能够通过源代码间接控制软件的两个“品质”： 软件将如何倒退，也就是说，它外在的可变动水平有多少。这是一个十分重要的规范，它甚至嵌入了名称中——软件。如果软件不能被更改，那么还不如改个名算了。软件在执行时的体现如何，即它是否持重、牢靠、有保障、平安？换句话说，它能正确执行吗？清洁代码的另一个乏味之处在于，“清洁”这个词语有着两个不同的外延，这与它的应用形式相干：  作为一个个性，它是指代码的状态，即没有问题且白璧无瑕的代码。 作为动词，它指的是改良现有代码的实际，让代码更清洁。设想一个由清洁代码形成的世界如果您的应用程序的源代码始终遵循高标准，状况会有什么不同？ 保护所需工夫和老本将大大减少 不仅如此，技术债权也将不复存在，并且不须要补救。对应用程序进行任何更改都会变得很快。开发人员能够将更多工夫花在翻新和解决乏味且重要的问题上，而不是一直地返工。 开发者的工作环境会更好 当代码遵循最佳实际，设想一下，领有这样的源代码也变成一件轻松和欢快的事件。每个人都是代码的拥有者，就会促成团队对标准的竞相效仿，并增强开发人员的合作。 开发人员大部分工夫花在浏览和编写代码上，领有这些清洁的代码意味着对他们工作环境的显著晋升。  软件的寿命将显著减少 一个清洁的代码库让引入更改变得更加容易。没有纠缠或僵化的代码，焦躁或丧气也将云消雾散。代码的“软”属性能够持续反对业务变动，而无需替换它（这对组织来说可能代价昂扬且具备破坏性）。 运行时的危险将升高 当软件筹备好投入生产时，运行谬误和前期安全漏洞将不会呈现，这大大减少了企业面临的危险。清洁代码让每个利益相关者都受益匪浅。 论断软件正在统治世界。放弃代码清洁，为每个人发明了更好的开发和操作环境。源代码是你的要害资产，清洁地构建它、在编码时清洁它，都能防止它成为一种累赘。清洁代码静止曾经开始了，而Sonar正是这个潮流的引领者。 想要体验SonarQube或试用SonarCloud，请分割SonarQube中国官网受权合作伙伴——创实 ，咱们提供SonarQube产品的征询、销售、 施行、培训及技术支持服务。作者简介： OLIVIER GAUDINSonar首席执行官兼联结创始人文章起源：https://blog.sonarsource.com/...

前言：蜜罐技术的呈现扭转了这种被动态势，它通过吸引、诱骗攻击者，钻研学习攻击者的攻打目标和攻打伎俩，从而延缓乃至阻止攻打毁坏行为的产生，无效爱护实在服务资源。 自网络诞生以来，攻打威逼事件层出不穷，网络攻防反抗已成为信息时代背景下的无硝烟和平。然而，传统的网络进攻技术如防火墙、入侵检测技术等都是一种敌暗我明的被动进攻，难以有效应对攻击者随时随地发动的无处不在的攻打和威逼。蜜罐技术的呈现扭转了这种被动态势，它通过吸引、诱骗攻击者，钻研学习攻击者的攻打目标和攻打伎俩，从而延缓乃至阻止攻打毁坏行为的产生，无效爱护实在服务资源。 一、什么是蜜罐技术 国内蜜罐技术钻研组织Honeynet Project的创始人Lance Spitzner给出了蜜罐的权威定义:蜜罐是一种平安资源，其价值在于被扫描、攻打和攻陷。蜜罐并不向外界用户提供任何服务，所有进出蜜罐的网络流量都是非法的，都可能预示着一次扫描和攻打，蜜罐的外围价值在于对这些非法活动进行监督、检测和剖析。 蜜罐是用来吸引那些入侵者，目标在于理解这些攻打。蜜罐看起来就是一台有一个或者多个能够被攻击者利用破绽的服务器或计算机主机。他们简略的就如同一个默认装置的操作系统充斥了破绽以及被攻破的可能性。 二、蜜罐技术的倒退 蜜罐技术扭转了传统进攻的被动局面。晚期的蜜罐个别伪装成存有破绽的网络服务，对攻打连贯做出响应，从而对攻打方进行坑骗，减少攻打代价并对其进行监控。因为这种虚构蜜罐存在着交互水平低、捕捉攻打信息无限且类型繁多、较容易被攻击者辨认等问题。Spitzner等平安钻研人员提出并提倡蜜网(honeynet)技术，并在1999年成立了非赢利性钻研组织The HoneynetProjectl。蜜网(是由多个蜜罐零碎加上防火墙、入侵进攻、零碎行为记录、主动报警与数据分析等辅助机制所组成的网络体系结构，在蜜网体系结构中能够应用实在零碎作为蜜罐，为攻击者提供更加充沛的交互环境，也更难被攻击者所辨认。蜜网技术使得平安钻研人员能够在高度可控的蜜罐网络中，监督所有诱捕到的攻打流动行为。 为了克服传统蜜罐技术与生俱来的监测范畴受限的弱点，The Honeynet Project在2003年开始引入分布式蜜罐(distributed honeypot)与分布式蜜网(distributedhoneynet)的技术概念，并于2005年开发实现Kanga分布式蜜网零碎，可能将各个分支团队部署蜜网的捕捉数据进行汇总剖析。 分布式蜜罐/蜜网可能通过反对在互联网不同地位上进行蜜罐零碎的多点部署，无效地晋升平安威逼监测的覆盖面，克服了传统蜜罐监测范畴窄的缺点，因此成为目前平安业界采纳蜜罐技术构建互联网安全威逼监测体系的广泛部署模式，具备较大影响力的包含The Honeynet Project的Kanga及其后继GDH零碎、巴西分布式蜜罐零碎、欧洲电信的Leurre、Com与SGNET零碎、中国Matrix分布式蜜罐零碎等。 在互联网和业务网络中以分布式形式大量部署蜜罐零碎，特地是在蕴含提供充沛交互环境的高交互式蜜罐时，须要部署方投入大量的硬件设施与IP地址资源，并须要较多的保护人力老本。2003年，Spitzner提出了一种蜜罐零碎部署的新型模式-蜜场(honeyfarm)。基于蜜场技术概念实现的网络威逼预警与剖析零碎有Collapsar，Potemkin和 Icarus等。 三、蜜罐的指标与作用 蜜罐技术弱小而灵便，不仅能够辨认对网络上主机的攻打也能够监督和记录攻打是如何进行的。蜜罐能够和入侵检测IDS一起工作，与 IDS相比，蜜罐的误报率较低。这是因为蜜罐既不提供任何网络服务，也没有任何非法用户，但并不是网络上的闲暇设施。因而，任何流入或者流出蜜罐的网络通信都能够是做可疑的，是网络正在被攻打的一种标记。 蜜罐的次要指标是容忍入侵者攻打本身，在被攻打的过程中记录收集入侵者的攻打工具、伎俩、动机、目标等行为信息。尤其是入侵者应用了新的未知攻击行为时，收集这些信息，从而依据其调整网络安全策略，进步系统安全性能。同时蜜罐还具备转移攻击者注意力，耗费其攻打资源、意志，间接爱护实在指标零碎的作用。 四、蜜罐的分类 蜜罐能够运行任何操作系统和任意数量的服务。蜜罐依据交互水平（Level ofInvolvement）的不同能够分为高交互蜜罐和低交互蜜罐。蜜罐的交互水平是指攻击者与蜜罐相互作用的水平，高交互蜜罐提供给入侵者一个实在的可进行交互的零碎。相同，低交互蜜罐只能够模仿局部零碎的性能。高交互蜜罐和实在零碎一样能够被齐全攻陷，容许入侵者取得零碎齐全的拜访权限，并能够以此为跳板施行进一步的网络攻击。相同的，低交互蜜罐只能模仿局部服务、端口、响应，入侵者不能通过攻打这些服务取得齐全的拜访权限。 从实现办法上来分，蜜罐可分为物理蜜罐和虚构蜜罐。物理蜜罐是网络上一台实在的残缺计算机，虚构蜜罐是由一台计算机模仿的零碎，然而能够响应发送给虚构蜜罐的网络流量。 五、蜜罐防护过程 蜜罐防护过程包含诱骗环境构建、入侵行为监控、前期解决措施3个阶段。 （1）诱骗环境构建:通过构建欺骗性数据、文件等，减少蜜罐环境甜度，诱惑攻击者入侵零碎，实现攻打交互目标。交互度高下取决于诱骗环境仿真度与真实性，目前次要有模仿环境仿真和实在零碎构建计划。 模仿环境仿真计划通过模仿实在零碎的重要特色吸引攻击者，具备易部署劣势。利用一种或多种开源蜜罐进行模仿仿真，多蜜罐联合计划有利于不同蜜罐的劣势集成;将仿真程序与虚构零碎联合构建蜜罐自定义架构，进步交互度;对硬件利用模拟器实现硬件虚拟化，防止理论硬件毁坏。然而，虚构个性使模仿环境仿真计划存在被辨认危险。 实在零碎构建计划则采纳实在软硬件零碎作为运作环境，升高识别率，极大进步了攻打交互度。 在软件系统方面，采纳实在零碎接口实在主机服务、业务运作零碎等，具备较高欺骗性与交互度，但其保护代价较高且受爱护资源面临着肯定被侵害危险。在硬件设施方面，可间接利用实在设施进行攻打信息诱捕，如将物理可穿戴设施作为诱惑节点、以手机SIM卡作为蜜卡等，通过构建实在软硬件零碎环境进步诱骗度。在低能耗场景下采纳实在软硬件设施诱惑攻击者具备肯定劣势，然而对于某些数据交互频繁的业务零碎内，存在高能耗、不易部署、保护老本大等缺点。 （2）入侵行为监控:在攻击者入侵蜜罐零碎后，可利用监视器、特定蜜罐、监控零碎等对其交互行为进行监控记录，重点监控流量、端口、内存、接口、权限、破绽、文件、文件夹等对象，防止攻打造成理论毁坏，实现攻打可控性。如模块监控、事件监控、攻打监控、操作监控、流动监控等。 上述攻打入侵行为监控中，不同计划的侧重点不同，高交互蜜罐则需更强监控力度。因为监控范畴无奈全面笼罩，可能导致监控缺失结果，以致攻击者利用监控盲区侵害零碎，同时，较大监控范畴易捕获更多信息，全方位拜访监控成为一种绝对安全措施。 （3）前期解决措施:监控攻击行为所取得数据，可用于数据可视化、流量分类、攻打剖析、攻打辨认、警报生成、攻打溯源、反向追踪等。具体解决措施为:提取根底数据，以图表形式展现统计数据;剖析关联度，提供入侵行为电子证据;分类歹意特色，过滤歹意用户;剖析数据包信息，辨认潜在平安威逼;利用程度检测辨认攻打分类，前期解决措施以剖析形式，使进攻系统分析收集数据，把握攻打信息，实现改善零碎进攻计划的良性循环。 六、蜜礶部署形式 按地理位置分类，蜜罐部署形式可分为单点部署和分布式部署。单点部署将蜜罐零碎部署于同一区域，如工控零碎工业区、无线网络作用域、特定试验场景模仿区等，部署难度小，但作用范畴无限，危险感知能力弱。 分布式部署则是将蜜罐零碎部署于不同地区回，利用散布在不同区域的蜜罐收集攻打数据，因而数据收集范围广，试验数据全面，能无效感知总体攻打态势，但部署较艰难且保护老本高。 按部署归属度划分，蜜罐部署形式可分为业务范围部署和内部独立部署。前者将蜜罐部署于实在业务零碎内，从而进步蜜罐甜度和交互度。但入侵者能够利用蜜罐作为跳板转向攻打实在零碎，因此须要严格监控和数据通信隔离。内部独立部署即蜜罐与实在业务零碎处于空间隔离状态，升高将蜜罐作为攻打跳板的危险，但诱骗性能较低。当然攻打们面对蜜罐的诱捕，也不会坐以待毙，所以产生了反蜜罐应答措施。目前蜜罐钻研多为工程部署，而较少波及蜜罐基础理论。敌手与蜜罐反抗属于典型的博弈行为，能够将黄开枝、洪颖、罗文宇等人的博弈论利用至蜜罐中，通过博弈剖析验证，为蜜罐提供实践撑持。利用信令博弈、非单干不齐全信息博弈、贝叶斯不齐全信息博弈等验证推理蜜罐零碎主动性、有效性、约束条件等。 论断： 随着网络技术的一直倒退，网络上的攻击者也越来越多，攻打伎俩也曾出不穷，被动进攻的更曾经不可能齐全跟上病毒、木马的更新速度，总会有漏网之鱼。蜜罐的呈现扭转了网络安全防护的被动局面，从被动承受病毒破坏到被动诱惑病毒攻打取得信息，蜜罐的主动防御技术将会越来越受到人们的器重。

互联网跟人类社会一样，都通过特定的规定和法律来确保社会的失常运行。BGP协定就是互联网中的“规定”之一。BGP用于在不同的自治零碎(AS)之间替换路由信息，当两个AS须要替换路由信息时，每个AS都必须指定一个运行BGP的节点，来代表AS与其余的AS替换路由信息。 但这些规定可能会被人为或意外突破。毁坏 Internet 规定的最常见形式之一是 BGP 路由器通告不属于其本人的 AS 的前缀，也就是说，BGP路由器非法发表特定前缀，从而将流量从其预期目的地重定向到它本人的AS。这称为 BGP 路由劫持，也称为前缀劫持、路由劫持和 IP 劫持。 2018 年 4 月，歹意黑客颁布了一些属于 Amazon Web Services 的 IP 前缀，一些试图登录加密货币网站的用户被重定向到黑客所发明的虚伪网页之中，导致了超过 160,000 美元的损失。  除了歹意攻打，BGP 劫持的意外实例也可能产生严重后果。2008 年，巴基斯坦的一家 ISP 试图通过更新其 BGP 路由来审查 YouTube，因为在审查过程中配置谬误，整个互联网中的YouTube 流量路全都输送到了巴基斯坦 ISP，导致了寰球 YouTube 长达数小时的中断。  在理解 BGP 劫持之前，咱们须要先把握一些BGP的基础知识 。 BGP劫持之所以十分常见，很大一部分起因是因为BGP的设计者并未思考到BGP劫持的可能性，并且默认所有 BGP “谈话者”都在说真话。如果想要理解如何加重这种危险，首先要理解 BGP 前缀通告和 BGP 劫持的工作原理。   BGP 如何通告前缀？ AS 由多个路由器组成，并在其边界内蕴含特定的前缀或路由，向相邻的 AS 通告。BGP 路由器在整个 Internet 中流传这些前缀，并通过各种 AS 保护到该目的地的门路，每个 AS 负责向其街坊发表它领有并蕴含在其中的前缀，BGP 路由器中保护的 BGP 表，其中蕴含为达到该特定前缀必须通过的 AS 门路。 例如下图：  当AS 100须要与AS170建立联系时，首先须要将本人的前缀 195.25.0.0/23 通告给相邻的 AS。这样，当该信息达到 AS 170 时，路由表中的信息将包含：前缀：195.25.0.0/23AS_PATH: AS100 AS190  ...

前言：近期户外服装品牌TheNorthFace遭逢撞库攻打，thenorthface.com网站上有200,000个账户被黑。撞库攻打到底是如何胜利窃取账户数据的？ 近期户外服装品牌TheNorthFace遭逢撞库攻打，thenorthface.com网站上有200,000个账户被黑。 TheNorthFace是VFCorporation产品组合中惟一的品牌，该品牌还领有Vans、Timberland、Eastpak、Kipling、Dickies，和Napapijri。撞库攻打始于2022年7月26日，然而在2022年8月11日才被发现，网站管理员在2022年8月19日进行了住址。然而黑客曾经设法窃取了thenorthface.com网站上194,905个账户的数据。 一旦相干的敏感金融信息被黑客撞库后盗取，在网络上盗刷银行卡生产都将大海捞针。  撞库攻打的危害撞库的攻打还有着一整套的流程从拖库－洗库－撞库，同时撞库攻打产生的危害范畴十分大。拖库是指黑客利用网站或互联网产品破绽，入侵有价值的网站后盾数据库系统，把注册用户的材料数据库全副盗走的行为，包含用户注册ID（该网站的注册用户名）、登录明码、手机号、邮箱、通讯地址、好友名单以及其余隐衷信息等。 震惊业界的CSDN“拖库”事件中，有600万个注册用户的电子信箱账户和明码等信息被泄露，之后多家驰名网站的用户信息被上传到网络供用户下载。 洗库是指黑客在获得大量的用户数据之后,通过一系列的技术手段和彩色产业链，将有价值的用户数据变成现金以达到非法获利的目标。 撞库是指黑客通过收集网络上已泄露的用户名及明码信息，应用自动化批处理工具到其余网站尝试批量登录，进而失去一批能够登录的用户账号及明码，并由此盗取更多的用户个人信息。TheNorthFace遭逢的就是典型的撞库攻打。 揭秘撞库彩色产业链条当初的拖库、洗库、撞库曾经造成成熟的彩色产业链条：首先，由具备肯定技术能力的黑客团伙寻找各个网站和互联网产品的破绽，进而开发入侵工具或编写入侵脚本、入侵教程。其次，技术黑客将开发的入侵工具卖给链条的下一个节点一入侵团伙，该团伙负责具体的入侵行为，将入侵获取的数据库打包上传至收信信封(施行入侵的团伙事先筹备的服务器，用于接管入侵网站服务器或曾经管制的“肉机”的数据库数据信息)。 入侵团伙再将“信封”卖给专门的洗库团伙，洗库团伙利用批处理工具对“信封”内用户信息依据账号类别(比方游戏账号、IM账号、银行账号等)、有无财产等等维度进行分门别类的解决。 而且洗库团伙能够再将曾经分类的账号进行粗疏化的变现，对于有财产的账号间接发售变现，如间接盗取网银账户内的现金、转让游戏账号内的虚构配备等；对于没有财产价值的用户信息发售给网络广告联盟或欺骗团伙，被广泛应用于发送垃圾广告，或对被盗账号用户的好友施行欺骗。 最初，被屡次转让的用户数据最终发售给撞库团伙，撞库团伙利用这些账号及对应明码应用自动化工具尝试登录其余网站或互联网产品，获取到新的网站的用户数据持续反复以上的链条过程。可见，撞库的黑色链条的各个节点清晰，分工明确。 没有财务信息被盗侥幸的是，随着网络安全就是的晋升，此次TheNorthFace撞库事件中，黑客无奈取得敏感的财务信息，因为领取细节没有保留在网站上。 因为“咱们不会在thenorthface.com上保留支付卡详细信息的正本。咱们只保留与您的支付卡相关联的“令牌”，并且只有咱们的第三方支付卡处理器保留支付卡详细信息。该令牌不能用于在thenorthface.com以外的任何中央发动购买。”TheNorthFace公司在发送给客户的告诉中解释道。 NorthFace对此次攻打的考察显示，最有可能被盗的数据是：①　全名②　购买历史③　账单地址④　收件地址⑤　电话号码⑥　账户创立日期⑦　性别⑧　XPLRPass处分记录⑨　采取措施领有TheNorthFace品牌的VFCorporation（前身VanityFairMills）向所有受影响的客户发送了无关违规的告诉，并解释了攻打后采取的安全措施。 “一旦咱们意识到这次袭击，咱们迅速采取措施解决这种状况。这些步骤包含禁用明码和从在攻打工夫范畴内拜访的账户中删除支付卡令牌。因而，下次您在thenorthface.com购物时，您须要创立一个新的（惟一的）明码并再次输入您的支付卡信息。咱们将持续监控咱们的零碎是否存在可疑流动。” 这是曾经是TheNorthFace第二次被撞库攻打了，第一次撞库产生在2020年11月。 

摘 要 本指南形容如何利用京东云Web利用防火墙（简称WAF），对一个简略的网站（无论运行在京东云、其它私有云或者IDC)进行Web齐全防护的全过程。该指南包含如下内容： 1 筹备环境1.1 在京东云上筹备Web网站1.2 购买京东云Web利用防火墙实例2 配置Web利用防火墙2.1 减少Web利用防火墙实例的网站配置2.2 在云平台放行WAF回源IP2.3 本地验证配置2.4 批改域名解析配置3 测试Web防护成果3.1 发动失常拜访3.2 发动异样攻打3.3 剖析平安报表4 环境清理 1 筹备环境 1 .1 在京东云上筹备Web网站 在京东云上抉择CentOS零碎创立一台云主机，调配公网IP，装置Nginx，并在域名解析服务上配置域名和IP的映射。具体的Web利用信息如下： # 操作系统信息[root@waf-demo ~]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) # 装置dig命令，该命令可显示域名的解析状况bash[root@waf-demo ~]# yum install bind-utils -y[root@waf-demo ~]# dig -vDiG 9.9.4-RedHat-9.9.4-72.el7# Nginx服务信息[root@waf-demo ~]# service nginx statusRedirecting to /bin/systemctl status nginx.service● nginx.service - The nginx HTTP and reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)...在配置完域名和公网IP映射后，通过dig命令可取得域名解析状况。 ...

每一次流动大促带来的迅猛流量，对技术人而言都是一次严峻考验。如果在流动期间蒙受黑产歹意DDoS攻打，无疑是雪上加霜。电商的个性是业务常态下通常不会蒙受大流量DDoS攻打，且对提早敏感，因而只须要在流动期间按需应用DDoS防护。本篇文章由业余的平安团队为你分享如何依据 DDoS攻打状况和业务健康状况，实时调整防护策略，保障业务稳定性的同时，节俭大量平安防护和经营老本。 如果你的网站或应用程序忽然呈现大量可疑的访问量，而失常用户不能拜访或无奈连贯服务器，那很有可能是遭逢了DDoS 攻打。DDoS 是互联网彩色产业链中成熟且常见的攻打伎俩，攻打简略粗犷又无效，溯源艰难，立功成本低。 一、DDos到底是如何进行攻打的？ 咱们通过一个例子能够帮你更形象地了解它： 小王开了一间餐厅，面积不大，最多只能包容 50 位客人同时就餐。但因为滋味好菜量足，每天就餐的客人川流不息。火爆的生意引起了这条街上流氓的眼红，他派了 100 多人来小王的店里捣鬼。这些人看上去和一般顾客没什么区别，小王和服务员只能失常提供服务，但这些人只是不停地询问菜品和价格，并不点菜，霸占了所有的座位和服务员，使其余客人无奈失常就餐，最终导致餐厅开张。 这就是典型的 DDoS 攻打模式，它在短时间内发动大量申请，超过零碎可解决范畴，使指标网络或系统资源耗尽，导致服务临时中断或进行，失常用户无法访问。 DDoS 全称 Distributed Denial-of-Service，其中 Denial-of-Service 意为拒绝服务，它的目标就是使服务不能拜访。Distributed 是分布式，指的是这种攻打不是来自一个源头，有可能来源于成千上万台设施。 随着 IoT 行业倒退，物联网设施增多，在线工夫长，破绽更新周期长，成为攻击者破绽利用的温床，物联网设施逐步成为 DDoS 攻打的主力军。 据统计，2021年DDoS混合攻打大幅增长，较2020年增长80.8%，2022年DDoS攻打威逼创历年新高，超大规模攻打持续增长已成为常态。 二、DDoS 的次要攻击方式 一般来说，DDoS的表现形式次要有两种： 流量攻打，次要是针对网络带宽的攻打，即大量攻打包导致网络带宽被阻塞，非法网络包被虚伪的攻打包吞没而无奈达到主机，包含 UDP洪水攻打、ICMP洪水攻打、死亡之Ping、泪滴攻打等攻击方式。资源耗尽攻打，次要是针对服务器主机的攻打，即通过大量攻打包导致主机的内存被耗尽或CPU被内核及应用程序占完而造成无奈提供网络服务，包含 SYN flood、LAND攻打、CC攻打、僵尸网络攻击、应用程序级洪水攻打等攻击方式。依据行业权威报告显示，僵尸网络不再局限于繁多的 DDoS 攻打伎俩，而是抉择与勒索软件、挖矿木马单干进行攻打，局部则转向分布式爆破攻打，攻打伎俩的丰盛和灵便的切换使得黑灰产可能进一步升高 DDoS 攻打老本，晋升攻打成果。 三、DDoS攻打如何防备？ 咱们尽管无奈阻止歹意的攻击者向服务器发送大量不实在的拜访数据信息，但能够提前做好筹备，进步负载解决的能力。比方能够为带宽扩容，在短时间内为网站急剧扩容，提供几倍或几十倍的带宽，顶住大流量的申请。也能够购买IP 高防服务，只需在 DNS 服务商处，将待爱护的域名在 CNAME 解析到京东云为您配置的平安域名上，即可实现接入，无效抵挡 SYN Flood、UDP Flood、ICMP Flood 等各种大流量攻打。IP 高防总防护能力达到 TB 级，轻松抵挡超大流量攻打。 但某些企业用户业务常态下未蒙受大流量DDoS攻打，且对提早敏感，因而用户心愿常态下不应用DDoS防护产品和服务。只在企业大促、展会、产品发布会、新业务上线等重要流动场景，以及企业融资、并购、上市等关乎企业倒退的重大事件期间，极易蒙受竞争对手和黑产歹意DDoS攻打，须要在流动期间按需应用DDoS防护产品和服务。并由业余的平安团队提供7*24小时平安重保，监控DDoS攻打状况和业务健康状况，实时调整防护策略，保障业务稳定性的同时，也可节俭大量平安防护和经营老本。 四、DDoS定制防护服务应势而出 京东云上某电商客户，在大促后期收到威逼情报，流动期间会有大量来自海内的 DDoS 攻打。通过京东云平安团队察看，攻打流量中靠近 4 成来自海内，且 CC 攻打较多，因为客户曾经接入 IP 高防产品，CC 攻打被无效防护。攻击者发现 CC 攻打未能导致客户源站拒绝服务后，开始尝试四层大流量攻打，攻打峰值超过客户 IP 高防保底带宽，弹性防护失效后开始按天产生费用。 ...

应用程序的疾速交付并非平安的敌人，只管当初看起来仿佛如此。随着企业继续采纳云服务和基础设施，平安却逐步被抛之脑后，这是不可取的——尤其是当初继续集成/继续交付流水线已成为攻击者的次要指标。  在应用程序上线后仅仅扫描其安全漏洞是远远不够的。平安的左移办法应该在DevOps团队开始开发利用和配置基础设施的时候就启动，这样就能够在破绽影响范畴更广和修复老本更低廉之前解决它们。这就是 DevSecOps 的外围准则。  通过平安左移，企业能够在用户受到影响之前辨认谬误配置和其余平安危险。云计算在实现 DevOps 方面施展了很大作用，因而爱护云环境和工作负载能够保卫 CI/CD 流水线的平安，最终爱护客户的平安。  以下是 DevOps 团队在进行平安左移时应该思考的5个重要平安工作：  1、 与平安团队合作。 平安左移是一个重大扭转。除了设置正当的流程以及应用适合的工具之外，企业必须从新思考他们的运作形式，在 CI/CD 流水线中更早地引入软件测试流程、工具以及相干专业知识。DevSecOps 并不是简略地将平安责任塞给开发人员，而是扭转角色和冀望，并联合应用适合的工具，实现平安和开发的均衡。平安从开发周期的开始就应该领有比拟高的优先级，而不是在 SDLC 前期才开始器重。  2、 实现频繁的自动化测试。 平安左移须要尽早且频繁地测试，通过自动化的代码测试，开发人员在工作时就会收到平安问题的揭示，这样他们可能在软件进入生产环境前纠正问题。扫描破绽的自动化工具能够升高人工测试中可能呈现的人为谬误的机会，并扩充了覆盖范围，以查看更多的软件。代码在开发过程中的每个阶段都会被扫描，因而到 SDLC 前期不会积压大量待审查的代码。 平安左移的策略须要将一个或多个工具集成到 CI/CD 流水线中以寻找已知的破绽以及辨认其余平安问题。通常会应用的工具类型包含动态利用平安测试（SAST）、动静利用平安测试（DAST）、交互式利用平安测试（IAST），密钥检测和软件成分剖析（SCA）。当然，在决定将哪些新工具引入你的流程之前，你应该首先评估你现有的工具。  3、 在流程中进行浸透测试。 尽管自动化测试是 DevSecOps 的必备条件，但仅靠自动化依然可能存在无奈发现的潜在问题。例如浸透测试等手动平安评估能够通过模仿网络攻击来查看应用程序的安全性。这类额定的测试能够将平安危险降到最低并且可能捕捉到自动化测试无奈检测到的问题。 在进入生产环境之前，请一位平安工程师来帮忙你审查软件并进行浸透测试以确保所有潜在的问题都曾经失去缓解。与其在被攻击者利用之后才晓得破绽的存在，不如间接笼罩所有的根底代码并对其进行额定的测试。  4、 保障你的软件是最新的。 始终采纳最新版本的软件是网络安全的外围。开发人员必须确保他们所应用的软件（操作系统、应用程序框架以及第三方库等）放弃在最新版本，这意味着安全补丁也处于最新状态。无论是来自供应商还是开源社区的软件，下载软件更新是爱护软件平安的重要步骤。  5、 寻找平安培训的机会。 开发人员并非平安专家，但他们在平安应用程序的生产中具备关键作用，因而开发人员也应该理解平安编码和测试的基本知识。随着对软件需要的攀升，开发人员应该思考依据他们的具体角色和需要进行平安培训。适当的培训和反对能够为你提供所需的背景信息，以产生即实用又平安的代码。  谈及软件平安，没有任何灵丹妙药能够齐全确保你的代码永远平安无虞。通过采纳这些实际，您可能发现更多破绽并且在代码部署前就打上补丁。

随着软件供应链攻打浪潮愈演愈烈，Google 公布了一系列指南来确保软件包的完整性，旨在避免影响软件供应链的未经受权的代码批改。新的 Google SLSA 框架（Supply-chain Levels for Software Artifacts 软件构件的供应链级别）通过辨认 CI/CD 流水线中的问题并减小影响，为企业实现更平安的软件开发和部署流程提供倡议。  Google 的 SLSA 框架SLSA 是一个端到端框架，旨在确保软件开发和部署过程的安全性，专一于缓解因为篡改源代码、构建平台或构件仓库而产生的威逼。这些要求源于 Google 的 BAB （Binary Authorization for Borg），该受权曾经应用了8年多，并且对于 Google 的所有生产工作负载都是强制性的。  SLSA 侧重于以下两个次要准则，即所有软件工件都该当： 非单边：未经至多一个其余“受信赖的人”的明确审查和批准，任何人都无奈批改软件供应链中任何中央的软件工件。目标是预防或尽早发现危险。可审计：软件构件足够平安通明，起源与依赖项可溯源。次要目标是主动剖析起源和依赖关系以及一些特定考察。 尽管无奈做到十拿九稳，但这两个准则能够帮忙企业无效防止和缓解各种篡改和其余供应链攻打带来的危险和影响。  CI/CD 流水线流程 软件供应链是创立和公布软件构件的一系列步骤。上图展现了源代码、构建、依赖项和包的流程关系。而每个源代码、构建和软件包都能够托管在一个平台上，例如源代码治理 （Source Code Management） 或继续集成/继续部署 （CI/CD）。 SLSA 框架下的4个安全级别安全级别越高，施行的安全控制越强，攻击者越难毁坏代码： SLSA 1：要求构建过程齐全脚本化/自动化并生成出处SLSA 2：要求应用版本控制和托管生成服务来生成身份验证的出处SLSA 3：要求源和构建平台合乎特定规范，以保障源的可审计性和起源的完整性SLSA 4：要求对所有更改进行两人审查，并采纳关闭的、可重现的构建过程  将供应链爱护晋升到新的程度Google 的 SLSA 框架是朝着提高认识和建设规范的正确方向迈出的一步，这些规范将帮忙企业管制供应链危险。依据 CI/CD 流程（上图）和 SLSA 倡议，咱们能够将危险定义为以下三个阶段：  代码阶段危险：提交恶意代码 – 将易受攻击的代码上传到公司的源代码管理系统，其中可能蕴含破绽或受损的代码包。攻陷源代码管理系统 – 源代码管理系统中的谬误配置或破绽，可能导致代码、秘密和用户信息泄露和被盗。应用歹意依赖项 - 可能容许未经受权拜访管道或导致裸露/透露代码。 构建阶段危险：应用恶意代码 – 注入错误代码，并在设定流水线流程之外，未经适当的审查和批准而登程的构建过程。攻陷构建平台 – 利用破绽或谬误的配置来取得对构建服务器的拜访权，并操纵构建过程及其输入。已泄露的依赖项 – 利用已泄露或易受攻击的依赖项来获取拜访权限或操作构建服务器。 ![图片]散发阶段危险：绕过CI/CD – 将歹意构件上传到 Artifactory，绕过 CI/CD 流程，使客户裸露于恶意软件包内。应用歹意包 – 扭转零碎流程，取得对构件的拜访权，以便上传、替换或窃取构件。  爱护软件供应链爱护软件开发等简单和动静的过程免受供应链攻打，须要全面的平安解决策略，该策略须要思考到在工具，源代码和流程，构建和散发阶段中面临的各种危险。正如 SLSA  指南所强调，施行弱小的平安防护策略可强化流水线平安情况，使攻击者难以毁坏基础架构、流程或代码。  ...

开源软件平安基金会（OpenSSF）公布了一项动员打算，以进步开源软件（OSS）的适应性和安全性。古代软件供应链之所以宽泛应用 OSS，是因为它提供了更快的翻新和更高质量的产品，但因为 OSS 组件固有的破绽，其宽泛采纳会随同肯定危险。 该打算的一个重要局部是应用软件物料清单（SBOM）作为根底构建块，改善整个开源生态系统的平安情况。这个打算概述了 OSS 我的项目应如何向上游用户提供 SBOM，从而将 OSS 组件的可见性晋升到一个新的高度。因而，应用 OSS 的企业和组织将须要一套用于 SBOM 治理的流程，使他们可能生成、获取、剖析、存储、监控和共享 SBOM，以进步其本身软件供应链的安全性。   “SBOM 无处不在” 到底是什么？开源软件平安动员打算蕴含 10 个口头我的项目被称为“流动组”。第9组的指标为 “SBOM 无处不在：改良 SBOM 工具和培训，以推动其广泛应用”，旨在帮忙推动 SBOM 作为根底构建块的利用，以改善整个开源生态系统的平安情况。该打算的核心思想是让 OSS 生态系统可能为其软件的每个版本提供精确的 SBOM。对于 OSS 厂商、用户和维护者，SBOM 提供的软件产品中所有组件的最终列表，可用于在软件开发生命周期的每个阶段辨认现有破绽和新破绽。  “SBOM 无处不在”工作小组将确保现有的 SBOM 格局与记录的用例相匹配，同时开发高质量的开源工具来创立 SBOM 文档。只管目前已有相干工具，但还须要搭建更多工具。该工作小组还负责发展以 SBOM 为主题的教育流动，以推动 SBOM 在开源畛域、政府和商业行业生态系统中的利用。  值得注意的是，美国联邦政府采取了积极主动的措施，要求政府机构生产和生产的所有软件都应用 SBOMs。《对于改善国家网络安全的行政命令》指出，网络攻击的频率和复杂性的减少催化了公共和公有部门联手爱护软件供应链的场面。这也标记着 SBOM 驱动的将来曾经到来。   SBOM 驱动的将来会是什么样子？计算机科学家先驱 Alan Kay 有一句名言：“预测将来的最好办法就是发明它。” SBOM 的改革必然是一种翻新和创造。当咱们应用 SBOMs 时，咱们将找到新的办法来改良和构建目前已有的模式。对于将来的 SBOM，咱们先睹为快：  多种 SBOM 格局目前存在多种 SBOM 格局规范，而这些规范将不断改进并演变出其余规范。当下两种最常见的 SBOM 格局是 SPDX 和 CycloneDX。尽管某一种格局可能会成为行业标准，然而只有有多个规范存在，咱们仍有可能须要持续应用多种格局。因而对于 OSS 用户来说，抉择可能反对多种格局的工具则是最优计划。  ...

在之前的文章中咱们探讨了 DevSecOps 的最佳实际。“平安左移”作为这一实际的准则和理念是无奈绕过的话题。在本篇文章中，咱们将聊聊平安左移的理由及其给企业带来的益处。麻利和灵便是古代云原生技术的标记，它能够解决从构建到生产的简单数字化转型打算。随着市场变动和疫情常态化，优化软件开发生命周期（SDLC）已逐步成为公司亲密关注的焦点，特地是治理 CI/CD 流水线和 SDLC 前期生产阶段的平安危险。 借助适合的云技术，开发团队可能与 DevOps 及平安经营团队一起平安地构建和测试应用程序的代码，并最终实现更高效运行，同时缩小生产过程中的平安问题。 平安已成为市场差异化标记2020年，在已知破绽中，90%波及到Web 应用程序，这是黑客攻击的次要指标。而消费者则是最间接受害者，因为他们的个人身份信息（PII）正在被曝光并在暗网上发售。将平安代码更快地投入生产环境意味着更少的安全漏洞。同时用户隐衷和平安对消费者来说非常重要，而企业以因提供更平安的服务给消费者可能取得更多青眼和支出。  歹意攻击者在对破绽进行攻打时也在调整策略、技术和程序，其攻击速度比以往任何时候都要快，因而在没有 DevSecOps 技术以及 DevOps 流程和团队的状况下开发软件并不可取。而构建弱小的 DevOps 根底，须要对团队成员、工具和组织架构投入精力和金钱。 CI/CD 流水线中的平安左移CI/CD 流水线是开发人员的必经之路。任何步骤的故障都会触发向对应开发人员发送的告诉。 以下是 CI/CD 流水线中的三个根本阶段： 构建阶段在这个阶段，代码从源代码中获取并与其依赖项相结合。随后对代码进行编译以在生产服务器上部署最终的应用程序。容器镜像和 IaC 模板在本地进行扫描，或作为 CI/CD 工作流的一部分进行扫描。随后执行自动化测试来验证代码的真实性和品质。 部署阶段镜像仓库会受到继续监控，以确保应用程序镜像在部署之前是平安的，同时具备防护策略来阻止不平安部署。一旦源代码通过了所有测试，就会部署到各种环境中，如生产环境。 运行阶段通过环境警报和危险优先级与告诉工具的集成，以此来监控生产环境中的危险。CI/CD 流水线加了严格的法规来爱护个人身份信息。 在 DevOps 中应用 CI/CD 流水线让开发人员无需毁坏代码就可能轻松辨认缺点和软件/应用程序品质问题。当“平安左移”概念被退出到 SLDC 时，CI/CD 流水线能够失去进一步强化。平安防护左移将 DevSecOps 准则和工具自动化作为动静集成利用，以在构建-测试-运行周期中强化平安。 平安左移嵌入 CI/CD 流水线的劣势当平安左移嵌入到 CI/CD 流水线中时，企业可取得以下四个劣势： 1. 进步应用程序的平安情况适合的云平台能够扫描容器镜像，并在 IaC 模板中帮忙辨认 SDLC 中的破绽或谬误配置。寻找可能为平安经营团队提供左移扫描后果的云平安性能，并深刻理解生产环境，如果潜在的攻打门路与现有危险相结合，这些性能帮忙DevOps 和开发团队高效解决问题。 2. 在 SDLC 晚期预防平安危险在相比之下，晚期的代码问题更容易修复，且修复老本更低。而当代码进入生产环境并呈现问题时，修复老本极高。 3. 更早地将应用程序部署到生产环境平安不再是开发完结后才进行的工作。将平安更早地集成到 CI/CD 流水线中，可能防止在生产环境呈现相干问题无奈疾速解决，而导致应用程序无奈按时在生产环境中部署的状况。 4. 优化团队合作，增强平安治理通过将平安集成到 CI/CD 流水线中，并使开发人员和 DevOps 可能在应用与平安团队雷同的平台的同时，可能自行进行扫描流程，团队可能很好地合作，各部门从开发到运行时可能被动治理平安危险。 ...

应用程序曾经成为网络黑客想要渗透到企业外部的绝佳指标。因为他们晓得如果能发现并利用应用程序的破绽，他们就有超过三分之一的机会胜利入侵。更重要的是，发现应用程序破绽的可能性也很大。Contrast Security 考察显示，90%的应用程序在开发和质量保证阶段没有进行破绽测试，甚至相当一部分应用程序在生产过程中没有受到爱护。 因为企业中运行着许多有破绽的应用程序，平安团队面临的挑战是如何爱护这些应用程序免受攻打。其中一种办法是让应用程序通过实时辨认和阻止攻打来爱护本人，这就是被称为运行时利用自我爱护（Runtime Application Self-Protection）的技术。  什么是 RASP ？运行时利用自我爱护（RASP）这一概念由 Gartner 于2012年提出，这是一项新兴的平安技术，让企业得以阻止黑客入侵企业应用和数据。RASP 技术通常内置在一个应用程序或利用程序运行时环境中，可能控制应用程序的执行，并检测破绽以避免实时攻打。 当应用程序开始运行时，RASP 能够通过剖析应用程序的行为和该行为的上下文，爱护其不受歹意输出或行为的影响。RASP 通过使应用程序继续检测本身的行为，能够立刻辨认和缓解攻打，且无需人工干预。 无论 RASP 驻留在 server 的什么中央，它都将安全性整合到运行中的应用程序中。它会拦挡从应用程序到零碎的所有调用，确保它们是平安的，并间接在应用程序内验证数据申请。Web 和非 Web 利用都能够受到 RASP 的爱护。该技术不影响应用程序的设计，因为 RASP 的检测和爱护性能能够在应用程序所运行的 server 上运行。  为什么 RASP 如此重要？入侵防护系统（IPS）和网络应用防火墙（WAF）等技术通常用于运行时的应用程序爱护，但它们在查看网络流量和内容时在线工作。当它们剖析进出应用程序的流量和用户会话时，它们无奈看到流量和数据在利用外部是如何解决的。因为它们的保护措施往往不足会话终止所需的准确性，因而会耗费大量的平安团队带宽，通常只用于告警和日志收集。当初须要的是一种新型的利用爱护技术——RASP，它能够驻留在要爱护的利用的运行时环境中。  利用所面临的平安挑战在爱护 Web 利用和 API 时，通常会面临以下4种常见的平安挑战： 1、实在的攻打难以辨认。 每个应用程序有其本人独特的破绽，并且只能被非凡的攻打所利用。对于某个利用来说齐全有害的 HTTP 申请，对于另一个利用而言可能会造成毁灭性打击。同时，“在线（on the wire）”的数据可能与它在利用中所显示的不同（被称为“阻抗不匹配”问题）。 2、古代应用程序（特地是 API）应用简单的格局， 如 JSON、XML、序列化对象和自定义二进制格局。这些申请应用除了 HTTP 之外的各种协定，包含 WebSocket，它是由浏览器中的JavaScript、富客户端、挪动利用和许多其余源产生的。 3、传统的技术进攻没有成果。 WAF 通过在 HTTP 流量达到应用服务器之前对其进行剖析，齐全独立于利用而运作。只管绝大部分的大型组织都有 WAF，但其中许多企业并没有业余的团队对其进行必要的调整和保护，使其只处于“日志模式”。 4、软件正在疾速倒退，容器、IaaS、PaaS、虚拟机和弹性环境都在经验爆炸性增长。 这些技术使得应用程序和 API 能够疾速部署，但同时会将代码裸露给新的破绽。DevOps 也迅速放慢了整合、部署和交付的速度，因而确保在疾速倒退阶段的软件平安的过程变得更加简单。 侥幸的是，运行时利用自我爱护（RASP）能够解决其中的许多问题  RASP 的工作原理当 APP 中产生安全事件时，RASP 将会管制该利用并解决问题。在诊断模式中，RASP 只是公布有问题的告警。在保护模式下，它会试图阻止问题指令。例如，它能够阻止对数据库执行看起来仿佛时 SQL 注入攻打的指令。 RASP 能够采取的其余口头包含终止用户的会话、进行应用程序的执行，或向用户或平安人员收回告警。 开发人员能够通过几种形式实现 RASP。他们能够通过蕴含在应用程序源代码中的函数调用来拜访该技术，或者他们能够将一个残缺的应用程序放在一个 wrapper 中，从而只须要按下一个按钮就能够爱护应用程序。第一种办法更为准确，因为开发人员能够决定他们想要爱护 APP 的哪个局部，例如登录、数据库查问和治理性能。 无论应用哪种办法，最终的后果都是将 Web 利用防火墙与应用程序的运行时环境绑定在一起。这种与应用程序的密切联系意味着 RASP 能够更精密地调整以满足应用程序的平安需要。  ...

在之前的文章中，咱们理解了 SAST 和 DAST，本文将介绍将两者劣势相结合的平安测试技术——IAST。交互式利用平安测试（IAST）是一个自动识别和诊断应用程序和 API 破绽的技术，它联合了 SAST 和 DAST 的劣势，能够从利用外部继续监测破绽。在整个开发生命周期中，IAST通过你在开发和测试中应用的工具实时提供告警。   IAST 的显著个性是它借助插桩（Instrumentation）间接从运行的代码中收集平安信息和遥测，以辨认和诊断应用程序和 API 中的破绽。但这并不意味着你须要等到生产阶段才开始进行 IAST，而是在你写下第一行代码的时候就开始在 IDE 中应用它。 因为 IAST 能够间接拜访代码自身，它能够对每一行代码执行 SAST。此外，因为 IAST 能够拜访 HTTP 流量，它能够对每个申请和响应进行相似 DAST 的剖析。因而，IAST 联合了 SAST 和 DAST 工具的平安性能。 IAST 蕴含以下两个次要性能：  自有代码平安测试： IAST 能够主动剖析应用程序和 API 的自有代码，找出之前没被发现的破绽。IAST 可能辨认各种各样类型的破绽，不仅蕴含十大安全漏洞列表（OWASP Top 10）中的破绽，还能辨认出其余更简单的破绽。开源平安测试： IAST 还能够通过两种形式来测试开源代码库和框架的安全性。首先，IAST 能够辨认困扰开源软件的已知破绽（通常以 CVE 的模式公布）。其次，IAST 还能够辨认开源软件中未知的（“新的”或者“潜在的”）破绽。 IAST 为麻利环境提供哪些劣势？1. 测试左移IAST 在 SDLC 晚期的测试左移中施展神奇的作用。它将测试转移到 SDLC 的晚期局部，使得问题被尽早发现，缩小补救老本。 因为该平安技术有助于疾速跟踪问题报告和修复期之间的窗口期，所以能够无效缩小开发过程中的延误。 平安和开发团队都须要在开发阶段应用 SAST 和 SCA 工具，而 IAST 切实测试阶段应用的平安工具。每当 IAST 发现平安问题，都会被反馈给开发人员，让他们在开发阶段修复这些破绽。  2. 裸露破绽的起源IAST 能够简略地剖析应用程序外部，因为它能够拜访应用程序的数据流、库、框架和源代码。剖析应用程序内部结构的个性有助于开发人员疾速辨认破绽并疾速修复。  3. 准确性IAST 的要害个性之一是以极低的误报率检测可验证的、不可验证的和可能的平安问题。在收回告警的正确率方面，它比 SAST 和 DAST 优良得多，而 DAST 和 SAST 在检测的破绽数量方面也无奈与之相比。 每个组织都心愿有一个平安工具能在应用程序的所有外部流程方面为他们提供精确的报告，而不是提供虚伪报告。 尽管 DAST 返回低误报并不难，但很难定位到与破绽相干的代码行。但 IAST 和 SAST 能够提供详细信息，例如带有破绽的代码地位，以帮忙平安和开发团队进行修复。  ...

上一篇文章中，咱们探讨了 DAST 的概念、重要性及其工作原理。那在开发过程中如何查找开源软件包中的破绽并学习如何修复？本指南带你一起理解 SCA 工具及其最佳实际。现在，绝大多数代码驱动的应用程序都包含开源组件。然而，开源代码可能蕴含一些致命的破绽，比方 Log4Shell 破绽。   软件成分剖析（SCA）是查找开源软件包中的破绽并学习如何修复它们的最佳抉择，确保代码和应用程序处于平安状态。本指南将带你一起理解应用 SCA 工具时的最佳实际。 什么是软件成分剖析 SCA？软件成分剖析 Software Compostition Analysis（SCA） 是一种用于治理开源组件利用平安的办法。通过 SCA，开发团队能够疾速跟踪和剖析引入我的项目的开源组件。同时，SCA 工具能够发现所有相干组件、反对库以及它们之间间接和间接依赖关系。SCA 工具还能够检测软件许可证、已弃用的依赖项以及破绽和潜在威逼。扫描过程会生成物料清单 Bill of Materials（BOM），从而提供我的项目软件资产的残缺清单。  SCA 自身并不离奇，但随着开源组件的遍及和广泛应用，SCA 逐步成为应用程序平安我的项目的要害局部，而 SCA 工具数量也随之激增。包含 DevSecOps 在内的古代软件开发实际中，SCA 须要便于开发人员应用，同时也能让平安团队可能有能力在软件开发生命周期 Software Development Life Cycle （SDLC）内疏导和领导开发人员平安地进行开发。 为什么要应用 SCA？开源组件俨然成为每个垂直畛域软件的次要局部。而 SCA 工具有助于跟踪应用程序应用的开源组件，这从生产和平安角度来看都至关重要。 安全漏洞带来的惨痛代价Gartner 预计超过70%的应用程序因应用开源组件而产生缺点和破绽。 正如美国征信巨头 Equifax 的案例所表明，这些破绽可能会给企业和组织带来灾难性结果。   在此事件中，Equifax 最后示意，网络犯罪分子利用 Apache Struts 的破绽获取文件。随即，Equifax 在布告中确认，先前披露和修复的破绽是就是在这次数据泄露事件中歹意攻击者所利用的破绽，过后这个破绽的评分有10 分之高。而 Equifax 在破绽呈现后没有及时修复，黑客利用其零碎中未修复的 Apache Struts 破绽发动攻打，导致1.43亿用户的信用记录被泄露，其中包含姓名、出生日期、地址，以及驾驶证号码等，这是有史以来规模最大的数据泄露案。最终，此案以 Equifax 领取7亿美元的赔偿金和罚款，索赔期限缩短四年闭幕。   Equifax 破绽事件成为平安行业，尤其是应用程序平安的重要标记，因为它强调了控制措施的重要性，开源组件引入的危险该当失去治理。该破绽也揭示了对速度的要求，企业须要可能疾速，反复地查找和修复他们正在应用的开源软件包中的破绽。而在 Tidelift 2022年开源供应链报告中显示，有57%的企业认为，即便有古代平安工具的助力，在应用开源进行开发时辨认和解决安全漏洞依然是一项微小的挑战。 为什么 SCA 这么重要？越来越多的应用程序由开源代码组成。据估计，开源代码占到了利用程序代码的90%。实际上应用程序是由不同的组件组成，企业须要保障所有的组件成分都是平安的，这样才可能无效地治理和升高危险。这也正是企业在确保代码库平安时所面临的挑战。 ...

Klocwork是一款动态代码剖析和SAST工具，实用于 C、C++、C#、Java、JavaScript、Python和Kotlin，可辨认软件安全性、品质和可靠性问题，帮忙强制恪守规范。 浏览本文，您将理解Klocwork的设置步骤，助力您实现平安的最佳实际。如需理解更多对于Klocwork的信息，请分割Perforce受权合作伙伴——龙智。 在装置任何基于web的应用程序时，都必须遵循平安最佳实际。本文概述了设置Klocwork的步骤，这是一款动态剖析和SAST工具，旨在实现平安操作。Klocwork通常本地部署，并且位于防火墙之后。如有可能在互联网上裸露任何内容，则需采取额定的预防措施。 平安最佳实际与Klocwork概述Klocwork门户可接管剖析后果，用以制作对于合规、趋势和问题细节的总体报告。您登录后能够查看报告、进行问题分类并配置剖析设置。此外，Klocwork门户部署在本地或云上，可在裸机、虚拟机或容器中运行。 通过配置Klocwork的开箱即用身份验证和平安设置，能够不便地在测试设置中进行设置并尽快相熟Klocwork，但在生产环境中应用时，此时门户要解决重要数据，则须要更改其配置。 需配置的要害方面包含： 移至HTTPS (SSL/TSL 设置)关上选择性端口和路由验证和SSO从平安角度而言，以下是Klocwork组件。为简略起见，这些是默认端口号，而所有的端口号都是可配置的。 △ 采纳一或两个虚拟机的典型Klocwork服务布局 Klocwork的服务器端组件能够驻留在同一个虚拟机上，或者许可证服务能够运行在独自的虚拟机上。然而必须关上以下三个端口： 许可服务共用 (27000)许可服务Klocwork守护程序(33133)Klocwork门户 (443)配置客户端工具时须要应用许可服务公共端口和Klocwork 门户端口。 SSL/TSL对Klocwork门户和Klocwork客户端工具或浏览器之间的通信进行加密的根本技术有两种： 应用反向代理为SSL/TSL配置Klocwork门户应用反向代理通常是IT部门的抉择，因为他们相熟它们的装置和配置，并且成果良好。如果您心愿在Linux主机的443端口上部署Klocwork门户，则须要一个反向代理。 配置Klocwork自身作为SSL/TSL (https)服务运行，能够通过以下三个简略的步骤实现： 为运行Klocwork门户的主机向企业签名受权机构索取一个签名的SSL/TSL证书。在期待期间，您能够应用由kwauthconfig生成的未签名证书。运行kwauthconfig，配置用于https连贯的门户。告诉用户应用https，并应用“应用平安连贯”和新的端口号更新IDE的Klocwork插件配置。申请已签名的SSL/TSL证书 上面是生成密钥对和证书签名申请文件(.csr)的openssl命令示例。只有portal.csr文件会发送到签名机构。 openssl genrsa -out portal.key 2048openssl req -new -key portal.key -out portal.csr Country Name (2 letter code) []: US State or Province Name (full name) []: Minnesota Locality Name (eg, city) []: Minneapolis Organization Name (eg, company) []: mycompany Inc. Organizational Unit Name (eg, section) []: Defense Common Name (eg, your server's hostname) []: klocwork.mycompany.com Email Address []: me@mycompany.com收到的证书文件格式可能不同。它可能蕴含主机的证书、任何两头证书和签名机构的根证书。如果它只蕴含主机证书，则须要手动下载两头证书和根证书。须要将私钥与所有这些证书联合起来，造成密钥存储库。 ...

上一篇文章中，咱们探讨了软件供应链的概念并理解到近年来软件供应链安全事件层出不穷。为了保障软件供应链平安，咱们须要理解网络安全畛域中的一些次要技术。本篇文章将介绍其中一个重要技术——SAST。当开发软件时，咱们必须同时思考开发生命周期中的安全性和源代码性能。人为谬误是不免的，因而任何企业都会尽可能应用 SAST 工具，以最大限度地缩小进入最终应用程序的代码谬误数量，并爱护应用程序免受将来的网络攻击。 让咱们一起看看 SAST 技术到底是什么，从久远来看，它如何帮忙您的应用程序更平安，以及它如何影响企业网络爱护。 什么是 SAST？动态应用程序平安测试（Static Application Security Testing），也称为动态剖析，它通过间接查看应用程序的源代码发现各种安全漏洞，以防止企业损失。SAST 工具和扫描程序根本都是在利用程序代码齐全编译之前应用，因而也能够将它们称为“白盒”工具。 一般而言， SAST 技术在软件开发周期的晚期就被应用，并且能够在不运行代码的状况下进行测试，这让开发团队得以在最终确定各种代码个性和性能之前应用此类扫描工具。因而，被发现的任何平安问题都能够失去及时解决。任何破绽都会在开发的晚期被发现，所以应用程序的“漏洞”或平安问题都难逃“法眼”。 实时反馈一些 SAST 工具能够在开发人员编写代码时提供实时反馈，并且可能在代码传递到开发周期的下一阶段之前修复各种问题。在扫描阶段，SAST 扫描程序能够精确地指出应用程序架构代码存在问题的地位。这让有教训的程序员解决问题时信手拈来，防止了破费数天或数周的工夫钻研代码来辨认破绽的起源。 此外，大多数 SAST 技术容许开发人员自定义报告，这些报告能够通过第三方 dashboard 或其余应用程序导出和跟踪。因而与其余类型的应用程序扫描技术相比，SAST 扫描工具在解决破绽的解决方案要容易上手得多。然而在整个开发过程中，SAST 扫描工具必须在应用程序上运行屡次。这要求开发人员将SAST工具的应用与开发生命周期和排期集成，而防止他们因为代码中内置的安全漏洞而偏离开发轨道。 总之，SAST 工具能够帮忙企业在开发阶段爱护其应用程序。如果应用切当，SAST 工具能够确保您的企业永远不会启动具备显著平安问题或配置问题的应用程序。 SAST 的劣势与 DAST 及其他相似技术相比，SAST 扫描程序和工具有很多劣势。 疾速扫描与许多其余应用程序平安工具相比，SAST 扫描程序能够在绝对较短的工夫内剖析100%的利用程序代码库。实际上一些更高级的工具能够在短短几分钟内扫描多达数百万行代码。 这也让开发人员可能将 SAST 扫描与开发周期的其余部分无缝集成，从而无需将这部分工作安顿到开发日程中，或在源代码中破费大量工夫查找安全漏洞。 SAST 工具比人工更精确在浏览数百万行代码时，与人工相比，机器总是更长于捕获谬误。理论 SAST 扫描程序更可能自动识别某些破绽，比方跨站脚本攻打，缓冲区溢出和 SQL 注入破绽，比人工更牢靠、更高效。此外，可能在开发周期中更快地辨认和解决安全漏洞。 总之，企业可能将人力转移到编程或其余工作上，而不是进行耗时耗力的安全检查。 实时报告与 DAST 和其余工具相同，SAST 扫描程序会精确告诉您应用程序源代码中的问题所在，让您更及时解决问题。您和您的团队从而不用破费大量工夫去查找问题以及定位检测到的安全漏洞的起源。 事实上，优良的SAST扫描工具甚至会在程序员编写代码时间接显示利用程序代码库中的问题。SAST扫描程序会在小谬误被其余代码覆盖并变得难以检测之前捕捉它们，从而缩小整体开发工夫。 多种编程语言和开发平台兼容性SAST 工具并不像 DAST 工具那样通用，升高 SAST 扫描程序的应用门槛，可能让大多数支流编程语言和平台得以应用适配的高质量扫描工具。因而，开发人员在开发过程中应该较容易为其应用程序找到适合的 SAST 扫描套件或破绽检测工具。 SAST 的短板尽管 SAST 工具的确有很多长处，但同时也须要留神相应短板，防止应用谬误的工具。 较高的误报危险对于 SAST 工具和扫描报告，开发人员须要独自查看每个标记的谬误或破绽。因为 SAST 工具的误报率绝对较高，有问题的扫描程序可能会将代码的特定局部标记为谬误。这无疑会升高开发速度。 报告有效期短因为 SAST 工具仅生成动态报告，因而这些报告也很快过期，特地是当与开发周期快或复杂性一直增长的应用程序一起应用时。您须要在整个应用程序的开发周期中屡次运行SAST扫描，来去捕捉无心中创立或疏忽的新代码谬误以及安全漏洞。 ...

随着互联网的飞速发展，网络上的信息爆发式增长，许多企业的外围信息都存储在网上。互联网看不见、摸不着，该如何筑牢平安防线，保障利用平安，晋升网络稳定性，谨防数据泄露？始终以来，天翼云都高度重视互联网安全，推出多款平安产品，打造牢靠的平安管理体系，从利用平安、网络安全、数据安全等多层面动手，致力守护全网全站的平安，为企业、国家筑起全方位的互联网安全护城河。 护航利用平安随着互联网的疾速倒退，基于Web环境的互联网利用越来越宽泛，企业信息化建设过程中各种利用都架设在Web平台上，然而这也引起了黑客们的留神。 《2021-2022年寰球威逼剖析报告》显示，2020年到2021年歹意Web利用申请的数量激增了88%，Web利用平安爱护成为企业平安治理的一大焦点。 天翼云Web利用防火墙（边缘云版）可为企业解决这一懊恼。天翼云Web利用防火墙（边缘云版）是一款业余为网站提供平安防护的服务，可抵挡多种类型的Web利用攻打，保障企业业务平安稳固运行。 与一般的Web利用防火墙不同，天翼云Web利用防火墙（边缘云版）是分布式的，在全国的边缘节点都有防护能力，可能从威逼的源头阻击攻打流量，无效升高源站压力；借助DNS智能调度算法，能依据拜访申请调用最近进攻节点，反馈更加迅速；通过AI叠加大数据联动剖析，可主动学习客户业务类型，主动匹配防护规定，适配率达90%以上；针对0day破绽暴发事件，24小时内更新规定实现防护，升高企业业务平安危险。 守卫网络安全DDoS攻打是一种常见的、高威胁性的网络攻击伎俩。黑客利用成千上万的“肉鸡”同时向指标发动拜访，耗尽指标的网络资源或性能资源，导致网站宕机、服务器解体、内容被篡改，给企业造成损失。DDoS攻打老本很低，然而进攻它所须要的老本却很高，造成的损失往往也较大，始终是政府企业安全部门的心头大患。 天翼云深入分析DDoS攻打特点，为宽广政企客户提供天翼云DDoS高防（边缘云版）产品，该产品采纳分布式架构，具备资源丰盛、全协定防护、智能防护、业余服务四大劣势：（1）天翼云DDoS高防（边缘云版）产品可能承载T级以上DDoS攻打，做到百G抗D节点地市级笼罩，全网总防护能力可达10Tbps；（2）提供从网络层/传输层到应用层的全协定防护，网络层可做到100%荡涤，反对IPv4/IPv6双栈协定，无需扭转用户源站架构即可帮忙客户业务平滑降级到IPv6，满足平安合规要求；（3）依靠弱小的自研大数据防护集群劣势，联合多种智能剖析算法，可实现大数据联动防护；（4）为客户提供可视化治理平台，简化用户治理，同时提供7*24小时平安专家服务，让客户面对大流量攻打无后顾之忧。 保障数据安全数字时代下，数据成为数字经济倒退的外围生产因素，是国家、企业的重要资产。随着数据价值的一直晋升，数据安全危险也一劳永逸。许多中小企业尚未具备业余的数据安全防护能力，这就须要业余的公司为其提供数据安全解决方案及服务。 天翼云针对企业用户数据安全守护过程中存在的短少数据安全布局、治理经营体系不健全、数据安全技术有余三大痛点，为企业打造了一个蕴含“数据安全管理体系、数据安全经营体系、数据安全技术体系”的全面平安体系，并且提供一个具备“事先可管、事中可控、预先可审”的数据安全治理平台作为落地工具。 天翼云“3+1+1”数据安全解决方案可实现从数据采集、传输、存储、解决、替换到销毁的平安闭环，可能笼罩到用户数据安全的全生命周期，为企业提供牢靠的数据安全守护。安全性是企业一直深入数字化转型的根底，是实现我国“网络强国”策略的基石。天翼云将持续在互联网安全畛域坚守深耕，一直强化本身平安技术实力及服务能力，欠缺平安产品线，为企业、为国家筑牢线上平安防线，护航互联网安全。

「大话开源」是 OpenTEKr 社区的旗舰访谈我的项目，专一于积淀开源人的所思所行，力求摸索出乏味、有料、有品的「开源武林秘笈」。 推出播客栏目，次要是心愿以声音的模式，给大家带来 圈内圈外最 juicy 最 in 的资讯、洞察和故事，心愿能在每个凌晨洗漱、通勤路上、午间放空和睡前时刻，陪伴大家一起成长*。 <*上海疫情重大，让咱们仍旧源气满满，刚强抗疫 > 第二季/S2 本期上新，咱们邀请到了 HardenedVault赛博堡垒CEO，HardenedLinux社区发起人 Shawn，同时也请回 S2 开播嘉宾蔡书（Flomesh 创始人兼 CEO）客串主持人，来与 Shawn 同台思维碰撞。 想晓得 Linux 最后设计时埋下的安全隐患？HardenedLinux 社区的前因后果？黑客养成记？老友俩知根知底，瞧瞧蔡老师如何关上 Shawn 的话匣子，让赛博朋克风的黑客娓娓道来那些年的那些事儿，以及这些年的这些事儿，还有将来那些年掐指算算的事儿。精彩辩题 领先通晓： 自由软件 vs 开源软件：public or vendor interest?香港 vs 大陆：开源土壤异同云原生正当红，云平安亦不可漫不经心将来十年，高级防护会是很重要的趋势老派黑客圈 vs 明码朋克帮收听渠道对本节目感兴趣的小伙伴，欢送在下列平台找到咱们垂直类播客平台：小宇宙 + 汽水儿 + 苹果播客泛用型音频客户端：喜马拉雅、蜻蜓FM 开源传声筒对节目感兴趣的小伙伴，欢送在评论区随时献花或吐槽，也可微信增加 OpenSourceGalaxy 或邮件 contributor@opentekr.org 进行反馈。 纵情互动听友群：增加小助手微信 OpenTEKr007，备注 OSG 即可入群微博：OpenTEKr抖音：OpenTEKrTwitter：@kr_open /// 对于大话开源 /// 「大话开源」是一档由OpenTEKr 发动的访谈节目，专一于积淀开源人的所思所行，力求摸索出乏味、有料、有品的「开源武林秘笈」。 每一期对话，咱们会邀请南征北战的开源老兵，或冉冉升起的开源之星，来分享他们的前沿洞察、防坑指南，以及鲜为人知的走心故事。在这里，不论您是“开源发烧友”，还是“门外驻足张望的好奇宝宝”，都能够吸取与开源相干的更多心法与招数。 /// 对于 OpenTEKr /// OpenTEKr 是一家以推广开源软件和凋谢硬件技术为外围的内容社区，致力于构建一个可继续倒退的凋谢科技生态圈。基于「众有、众享、众治」的信念，咱们依循「自在与规定同在，收费与商业共生」的准则，神往科技普惠的美好未来，帮忙集体和组织通过变革性的技术创新来成就其远大抱负。

近几年，随着短视频平台衰亡，各种直播APP映入人们视线，目前社交、直播类APP行业仍是被攻打的重灾区，之前与几个做社交APP的敌人交换，平台服务端被流量攻打了，他们就放松换到高防机房，尽管高防服务器有肯定成果，然而因为社交APP波及视频流、图片等内容，再过滤攻打的同时会呈现重大卡顿、提早高的状况，所以敌人始终不太称心，在有攻打的时候关上视频、发送图片等状况下提早很大（有时候没攻打提早也高，可能很多高防复线缘故或者机房其余用户有攻打影响到整个机房环境造成进口稳定），影响用户体验，甚至会因为高防依附策略过滤造成误封用户的状况，导致一些失常用户无奈登录被拦挡的状况。理解需要之后依据这种利用场景定制了一套解决方案，采纳大量分布式节点部署，攻打流量扩散在不同的节点上，节点间可无缝切换，通过APP集成SDK跟验证端通信来调度节点，可实现无下限进攻DDOS，CC攻打，同时为用户拜访减速。随后一直有平台接入测试，为不少平台轻松防护了辣手的流量攻打，因为传统高防的有余，针对TCP端口的CC攻打没有太好的过滤策略，外加流量攻打量一直飙高，依附硬防生抗成果不现实同时防护价格昂贵等，起初这个计划的独创的平安防护引擎VEC外围性能在github上开源，同时产品通过一直历练进行了三次重构，目前产品曾经足够稳固。产品原理这个产品是一款专一于C/S架构的平安防护产品，利用分布式星散群拦挡针对用户服务器的CC攻打、DDOS攻打，通过在APP客户端集成SDK进攻模块，来实现精准疾速的切换以及链路加密通信，因为采纳了隧道加密通信技术，应用动静虚构IP连贯，因而，任何DDOS攻打流量都无奈进入隧道，同时还能够暗藏实在服务器IP。整个防护由三大模块组成，别离是客户端SDK、智能调度和身份验证。简略演示一下大略成果，有感兴趣的敌人能够进行沟通交流。市面上有不少同类商用产品，各有各的长处，这个产品是之前给敌人平台提供运维时候本人团队开发的产物，有须要的能够收费提供部署和搭建。计划演示一、生成SDK文件通过搭建jenkins在线生成SDK文件产品反对android\ios\windows三端的源码和无源码集成。轻易从搜索引擎找了一款社交APP进行演示，因为间接下载的apk文件并无源码，因而，通过逆向的形式将SDK集成进去。通过脚本进行集成之后进行测试（三端无源码集成过程后续独自写一个独立的介绍）。 二、抓包剖析首先装置原版APP进行抓包剖析。通过原版抓包能看到大量dns申请以及http明文申请数据。再将逆向集成SDK的APP进行装置并抓包。SDK启动的时候会HOOK掉APP的所有网络通讯，因为SDK和节点之间是加密传输的，因而抓包也无奈获取dns解析记录以及http、tcp等明文信息，全部都是公有加密协议进行了封包。下图为原版dns解析下图为逆向集成SDK之后抓包62001端口为SDK跟节点加密通信端口。所有数据都被加密传输，无奈解密出明文数据，防止了要害数据和内容在网上明文传输。上图为节点外面进行dns解析服务，所有的客户端dns解析都会在远端节点进行解析，从而防备了dns净化和劫持。也能够防止攻击者获取域名信息。集成SDK之后抓包看到的全部都是加密封装后的TCP数据包。 抓包看到SDK跟调配的节点203.215进行通信，在IP为203.215的节点外面将加密隧道程序断开，模仿节点被攻打产生无法访问的状况。抓包看到SDK迅速切换到调配给用户的第二个可用IP62.24所有的切换都是无感知进行的。为了防止攻击者反复拉取全副节点池，SDK的验证端做了身份辨认，token、deviceid等形式进行验证。每个用户调配的一组3个ip都不会反复，如果攻击者打死调配给他的节点IP，也只会影响到黑客本人。断线重连，节点异样霎时主动切换。SDK计划长处次要是不依附生抗来防护，而是通过大量分布式节点调度防护。其次能完满防护CC攻打，因为节点对外不提供任何业务端口，只对外开放一个加密传输隧道端口（62001）。SDK节点切换都是霎时切换，不依附域名dns解析形式。cname防护集群切换依附域名解析同时无奈实现无缝切换，并且防CC成果仍然不现实。Q & A 问答集1、端口防CC成果如何？答：SDK跟节点之间通信是建设一个加密隧道，只有APP集成SDK之后的数据才会进入，攻打量无奈进入隧道内，同时节点不对外开放任何业务端口，只有一个加密隧道通信端口62001凋谢。因而，任何针对业务端口的CC都起不到任何成果。所有的业务数据都通过封装发送到节点的加密隧道端口，达到节点之后进行解密解包将用户业务数据发送给原站服务器。2、最高能进攻多大攻打量？答：因为不是依附高防的生抗模式，全副都通过调度算法调配节点，因而，黑客攻击打死的节点也只是影响黑客本人，通过多层辨认，杜绝全副节点被拉取。用户能够在调配的一组惟一IP之间无感知切换。cname高防转发模式则会呈现掉线，提早高，过滤规定误封实在用户的状况。无感知切换是通过SDK进行解决的，不存在通过cname域名进行调度切换的弊病。3、文中提到的虚构IP如何应用？答：为了更好的爱护APP不被逆向破解，咱们倡议用户客户端链接服务端的域名解析到虚构IP，如果客户端绑定的是IP地址，能够换成咱们的虚构IP。虚构IP是一个环路IP不会在互联网上传输，然而客户端集成SDK之后就能够应用虚构IP跟咱们节点建设加密通信了。虚构IP相似127.0.0.1~127.0.0.2554、集成之后是否能够抓包到客户端明文数据？答：APP集成SDK之后会hook全副APP的通信数据封装到咱们的加密协议外面，并与节点建设加密隧道。任何数据都是加密之后传输的，通过抓包是无奈显示明文的。有的客户有独自需要，比方社交视频等APP，这类客户流媒体数据较多，如果都走节点会造成减少老本和担心额定提早等状况，因而SDK反对例外设置，比方链接第三方流媒体或者存储更新资源等无需爱护的链接进行直连拜访。5、是否能够将流媒体、图片等资源直连不进行爱护，来进步速度？答：SDK默认启动的时候会截获APP全副流量传输数据给节点，然而因为大部分用户客户端外面流媒体、图片等存储于第三方接口，无需爱护，因而，咱们会依据用户需要进行定制化转发，也就是提供第三方域名或者将须要爱护的业务应用我方提供虚构IP都能够实现。这样爱护了重要的原站服务器同时第三方无需爱护的接口又能够进行直连，既平安又疾速，无需额定多进行一次转发，也防止过多的资源带宽等耗费节省成本。 须要技术交换沟通能够加q: 278056823 vx： zenops

在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。 如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。 本期金融云原生漫谈，将和您聊一聊如何构建平安的云原生平台。 以容器和微服务为代表的云原生技术，对于金融行业来说，既是时机，也是挑战。时机在于，云原生技术正在助力银行通过差异化业务进行翻新，疾速取得更多用户的青眼；挑战在于，比任何行业都要强调平安稳固的金融业，如何在飞速更迭的技术环境下，放弃稳态业务继续倒退的同时，做到既稳又快。 金融行业云原生平台的安全性近年来失去越来越多的关注，为了满足容器的高牢靠、高性能的基本保障，平安建设至关重要，但又十分宏观，波及到方方面面。不仅仅是被动的进攻和预先的查漏补缺，也包含态势感知，主动防御等内容，应该作为一个整体去考量和布局。 容器平安包含哪几个层面？容器平安防护实际从何动手？如何从全生命周期躲避容器化革新过程中的平安问题？心愿本篇文章能带给您启发。 容器平安包含哪几个层面？Docker和K8s会不可避免地存在破绽，每次破绽修复都要大规模降级集群，每次降级有可能对下面运行的容器造成影响，对K8s的运维是十分大的压力。那么咱们如何保障容器平台平安呢？ 基于云原生平台的档次架构，咱们能够从以下4个层面来对待这个问题： 在容器及K8s层面，通常须要保障镜像平安、容器运行时平安、容器网络安全、权限平安等问题。另外，能够进一步关注K8s的Pod安全策略PSP。在平台层面，集群隔离、租户平安、用户隔离、网络ACL、审计、DevSecOps、NetworkPolicy、平台高可用、HTTPS接入平安等都是平台从平台层面提供的平安能力。平台本身的破绽扫描、组件破绽等问题须要厂商发版前做严格的漏扫，做到无效的解决。很多客户在洽购过程中，都会要求厂商提供将来每个版本的平安检测报告。在利用层面，能够通过DevSecOps在开发过程中为利用提供平安保障。另外，平台会提供利用高可用保障、利用平安接入、跨域策略、数据高可用等能力，为利用进一步提供平安保障。通常，咱们倡议针对面向的互联网利用，能够叠加上前端安全设备的WAF、DDos、防Sql注入等能力将进一步晋升利用的安全性。在运维层面，能够采纳业务高峰期的重保服务作为保障平台失常运行的另一个策略。容器平安防护实际从何动手？云原生平安离不开容器平安，容器的平安防护倡议从以下方面开始着手评估和实际： 一、基础设施层 操作系统平安：首先须要明确一点，波及容器云工作节点的操作系统要应用遵循平安准则的操作系统。应用防火墙，端口阻止等安全措施。零碎惯例安全更新和修补程序在可用后必须立刻利用，避免黑客和入侵者利用已知破绽。应用最小化操作系统，同时精简和平台不相干的预置组件，从而升高零碎的攻击面。应用第三方平安加固工具，定义了零碎上的应用程序，过程和文件的访问控制等。建设审核和日志记录流程，确保构建平台的所用的操作系统是平安合规的。网络层平安：实现治理立体业务立体流量隔离、起码的端口裸露。存储平安：定时快照和备份并对敏感数据进行加密。二、平台层平安 平安扫描：对容器调度和治理平台自身，须要先实现平安基线测试，平台平安扫描；审计：对平台层用户操作进行审计，同时也须要我的项目层面的资源和操作审计；受权：对平台履行权限管制，能基于角色/我的项目/性能等不同维度进行受权；备份：定期备份平台数据；巡检：选用具备自动化巡检能力的平台产品。三、容器平安 镜像平安：容器应用非root用户运行，应用平安的根底镜像，定时对镜像进行安全漏洞扫描；运行时平安：次要是对容器在容器平台上运行过程中的对于宿主机零碎以内平安设置，例如容器特权、晋升权限、主机PID、主机IPC、主机网络、只读文件系统等平安限度。同时倡议具备限度容器对于底层宿主机目录的拜访限度。 限度容器对于内部网络端口裸露的范畴限度。用户限定某些敏感我的项目独占宿主机，实现业务隔离；容器网络安全：能够通过Networkpolicy模板，对于所有Pod之间、Namespace和Pod之间等进行IP、端口、标签等细颗粒度的容器安全策略，同时在集群外部为Namespace划分子网、并且对于不同的namespace之间的子网设置白名单，进行访问控制。如何从全生命周期躲避容器化革新过程中的平安问题？家喻户晓，容器化革新过程中的平安问题也不容小觑。咱们通过观察发现，在过来三年业界也有一些容器失败的案例，根本问题就是：测试业务零碎迁徙到容器平台过程中，出问题运维团队不能及时处理，导致业务开发人员对容器平台的稳定性、可靠性产生质疑，最终导致我的项目失败。 因而，为了尽可能地躲避这类平安问题，倡议在容器化我的项目施行过程中，先对接现有的运维体系、平安体系和相干工具平台，在整体纳入到现有IT保障体系的根底上，将无限资源聚焦于容器平台的保障上。 再者，因为容器运维与传统运维之间有很大的技术门槛，所以也能够思考购买业余技术厂商的驻场服务，解决平台的平安加固和平台运维问题。金融企业本人聚焦于容器平台的培训、利用推广等产生IT价值的工作。 综上，云原生平台的平安建设并非欲速不达，而是一个须要不断完善、迭代积攒的过程，前期还会波及到性能布局、平台运维、降级施行、平安重保、利用迁徙、服务革新、流程设计等一系列相干问题，倡议金融企业在洽购产品的同时，器重服务，采纳甲乙双方更加紧密配合的我的项目建设/服务模式，从金融企业的本身状况登程，有针对性地躲避容器化革新过程中的平安问题，安稳且高效地实现金融级云原生平台的平安构建。 咱们置信，容器作为云原生的重要组成部分，必将紧跟云原生的倒退热潮，向更加平安、可信的方向倒退。

近日，国内权威钻研机构Forrester公布了最新的《Now Tech: Bot Management, Q4 2021》报告，对Bot治理技术及其产品利用做了权威性解读，并且从技术水准、市场份额等多个维度对寰球31家Bot治理服务商调研。 在本次Forrester寰球格局钻研之中，腾讯平安作为中国平安企业代表，位列寰球“Midesize”中型市场区间。咱们很荣幸，腾讯平安BOT治理能力失去了认可。 据Forrester的报告显示，包含腾讯在内的提供WAF相干Bot治理的供应商，其WAF-adjacent bot management在解决凭证填充、网络侦察、DDoS攻打、网络数据获取这类反抗平安攻打，以及在爱护挪动应用程序、API方面具备很强的功能性。在与电子商务工具、营销工具、其余平安工具的集成以及打击广告和流量欺诈方面具备较强的功能性。 实际上，目前互联网中很多批量流量都是Bot所产生的。据网络安全机构的报告统计，2020年40.8%的互联网流量来自Bot，Barracuda基于2021年上半年统计数据分析显示，39%的流量来自有歹意希图的Bot，这使得歹意攻打变得更加容易。 腾讯云WAF作为一款基于AI的一站式Web业务经营危险防护产品，除了阻止针对Web应用层的常见攻打，还可无效阻止爬虫、薅羊毛、爆力破解、CC等攻打，为客户的云上平安进行防护。目前，腾讯云WAF产品已广泛应用于泛互联网、金融、政务等畛域，受到了腾讯音乐、家乐福、建设银行、华住会、只玩科技等不同行业客户的好评。 在实战环节，腾讯云WAF依附寰球部署的云平台和丰盛的黑灰产反抗教训，帮忙某电商客户监测到流量骤减70%，进而为客户节俭了带宽资源；同时还帮忙某游戏客户精准阻断Bot攻打，保障了新游戏上线营销流动的顺利进行；此外，在重保客户应用场景里，实现捕捉0day破绽25个，并对超100个破绽进行应急响应。这些实战案例，失去了相干专家和用户的统一好评。 基于AI+规定库及Bot治理的腾讯云WAF，还可帮助企业躲避歹意Bot行为带来的站点用户数据泄露、内容侵权、竞争比价、库存查取、黑产SEO、商业策略外泄等业务危险问题。实现在保障客户利益的同时，无效晋升客户的平安体验。 万物上云的新生态下，企业上云已成为不可逆的趋势，面对上云后网络攻击的一直演进及流量的激增，云WAF平安解决方案的摸索和翻新已成为寰球平安厂商新的发力赛道。 腾讯云WAF依靠腾讯20多年业务平安经营及黑灰产反抗教训，可无效帮忙腾讯云内及云外用户应答业务平安防护问题。将来，腾讯云WAF还将一直优化降级产品和服务，为更多企业用户的业务平安经营保驾护航。

因为寰球网络安全行业的发展趋势、国家政策推动以及简单的平安攻打态势，中国过来20年依附买硬件、买软件、堆人力的信息安全建设思路在明天曾经遇到了瓶颈，单纯通过网络安全产品和人力的堆砌曾经无奈应答简单的平安现状。 服务模式的扭转，对人员的云平安常识储备、平安教训，提出了更高的要求； 企业资产规模减少，安全事件数量大幅减少，对企业自动化能力提出了更高的要求； 平安攻打伎俩的复杂化和规模化，使攻打老本大幅升高，企业安全事件处理老本逐渐减少 …… 或者，平安建设有更好的办法？关注今天的腾讯平安托管服务（MSS）发布会，咱们将带来答案。

数字政府已利用到咱们的生存环境中，电子政务也跟人们的生存非亲非故。一旦政务平安破防，公众的信息数据遭逢失落或窃取，带来的劫难和影响将呈几何倍增长。 由《中国信息安全》杂志、腾讯平安、腾讯研究院独特发动的勒索病毒系列沙龙第二场，咱们邀请到PCSA行业云平安联盟首席专家、太极股份首席平安官郭峰，中国科学院计算机网络信息中心研究员肖彪，腾讯研究院高级研究员宋扬三位网络安全畛域的专家，独特探讨如何共筑电子政务网络空间护城河！ 勒索软件面面观Q：对于勒索软件的意识、倒退现状和带来的危害，各位专家有什么样的认识？ 肖彪：随同计算机呈现的计算机病毒曾经存在很多年，勒索软件是一个计算机病毒，可能利用破绽、邮件或者U盘撕开第一道互联网的防护体系。基本来说勒索软件还是一个蠕虫，不仅可能对计算机系统进行毁坏、窃取，还可能进行主动的流传，主动的复制。最闻名的一个勒索软件是WannaCry，它之所以在寰球大面积暴发，外围起因就是利用了2016年CIA泄露的永恒之蓝病毒，把永恒之蓝的破绽跟蠕虫勒索相结合。 宋扬：勒索病毒逐步出现SaaS化。病毒的制作者，传播者以及获取收益，会有不同的人来实现，发动攻打的这个人他可能不懂一些技术细节，不懂编程，然而拿到病毒后他就能发动攻打。 Q：专家们在日常工作中有碰到过、看到过或解决过勒索病毒的案例吗？是否介绍一些勒索软件的高级解决办法？ 郭峰：我接触过最重大的状况是如果明天早晨不解决，今天这个城市将停水、停电。过后紧急解决了三件事，首先是派专家和相应的平安能力者去现场，第二就是做了应急处理的预案，再就是和公安及当地网信机构做了处理。 肖彪：大到各个行业，小到一些企业都面临勒索软件的攻打，有对文件加密的，有对数据库加密的，伎俩很多种。咱们感觉第一个方面是要尽可能减少破绽，第二个方面就是数据备份。 宋扬：在17年、18年的时候发现了大规模勒索软件的攻打。私有云上有工具基本上是没有大规模的侵害，但像一些公有云或者一些中小企业受到攻打的话，也会求助于腾讯平安来做数据的复原。我的了解是对于经验不足的中小企业，逐步上云能够升高一些勒索攻打的危害。 电子政务“云”变质Q：电子政务有着怎么的倒退历程和特点？ 郭峰：电子政务历程大略分为3~4个阶段，最早是从无纸化办公到电子化办公，第二轮次要是利用和信息共享，第三轮是利用在互联网加政务服务，接下来能够看失去数字政府曾经是利用在咱们生存环境当中，以大数据、大平台、大零碎的形式出现。 宋扬：电子政务在倒退过程中出现以下几个特点，第一个特点是电子政务它所承载的数据越来越多，同时也是越来越重要。这下面不仅有公务的信息，政务的信息，还有大量公众的个人信息。第二是它的一些构造或者平台更加简单，那么裸露到公网的一些触点也会越来越多。 Q：在数字中国、网络强国的这个大趋势下，如何加固数字化底座？电子政务下一步的发展趋势将如何？ 肖彪：当初大量的信息化零碎上云，而后集约化建设，集约化经营，然而网络安全工作还是分散化的，很不扎实。传统的网络安全须要更加细化，甚至波及到每一个细粒度的权限管控等。 宋扬：第一是更加平台化，之前可能是烟囱式的建设，第二个特点是它的利用在一直的下沉。从平安角度来看能够借助一些前沿的技术和理念，从技术角度来说能够做一些城市平安大脑或者说城市平安经营核心，防患于未然。对能够上云的零碎，咱们倡议能够用一些云原生平安的理念来进行平安的防护。 电子政务畛域的勒索病毒及应答措施Q：电子政务畛域的勒索病毒出现怎么的特点？2016年到2018年是勒索软件高发期，当初出现降落趋势的外围起因是什么？ 宋扬：勒索攻打或者勒索病毒有两个特点和电子政务是关系比拟严密的： ▪︎ 第一个特点是勒索攻打的攻击者，更加想攻打一些有数据价值的基础设施，电子政务平台和零碎是其重要的潜在指标之一； ▪︎ 第二个是勒索病毒逐步出现SaaS化，所谓的SaaS化就是更加流程化，分工更加明确，因为电子政务的触点在减少，那么相应的被攻打的面也在减少。 Q：在万种场景、万物互联、万云时代的趋势下，如何无效防护勒索软件在电子政务畛域造成的危害？ 肖彪： ▪︎ 第一，我认为传统的网络安全伎俩仍旧无效； ▪︎ 第二，是有了进攻伎俩后肯定要有监测伎俩，造成一个纵深监测的概念； ▪︎ 第三，网络安全工作要从以前粗暴式的、基于端模式的这种平安，变成利用的平安； ▪︎ 第四，相干的单位比如说电子政务单位，须要把网络安全攻防演习实战化常态化； ▪︎ 第五，就是网络安全的意识培训。 郭峰：当初PCSA联盟提出的观点叫全维全域的深度监控。面对中央政务零碎集中上云的趋势，在新的场景下，新的技术、新的监测伎俩、新的体系化建设、新的情报源，须要在等级爱护的根底上，再往下一层延展到供应链平安。 宋扬：咱们的教训是第一要做好传统意义上网络安全的一些产品或者理念，第二咱们更心愿引进一些先进的、翻新的一些理念和技术，比如说零信赖平安，是这两年新兴的平安理念，也是腾讯始终在尝试的事件。 零信赖无边界拜访控制系统（Zero Trust Access Control system，ZTAC）是腾讯联合本身丰盛的网络安全治理实践经验与“零信赖”理念，推出的网络边界拜访管控整体解决方案。以身份平安 、终端平安和链路平安三大外围能力，为企业内网平安和利用上云打造对立、平安和高效的拜访入口，构建全方位、一站式的零信赖平安体系。 法律法规及技术层面对要害信息基础设施的探讨Q：随着网络安全法，数据安全法，要害信息基础设施平安爱护条例的公布，专家们对关键性基础设施有何认识？ 肖彪：我做过一个数据分析，2020年全年发现攻打咱们国家电子政务外网中央级节点的挖矿或勒索软件，攻打IP大略是15000多个，2021年1月份到9月是13000多个。这些攻打IP大部分是来自于中国，然而攻击者下载歹意木马和歹意样本的行为，99%以上都是在境外，不论是勒索还是挖矿都要要依赖一些基础设施才可能失常的运行。 郭峰：网络攻击行为的演变越来越从娱乐性型商业化型变成静默型。越来越高级别的机构参加进来，原来可能是黑客分子，而后变成敌对势力，将来就变成霸权国家，这三个档次所组织的人力、物力、财力相差很大。 Q：勒索软件把能源电力、医疗卫生等公共基础设施造成大面积的瘫痪，让经济社会运行的神经中枢不能运行。专家们对关键性基础设施的平安防备有没有更好的倡议？ 郭峰：总的来说，网络安全要做到“上工治未病之病、中工治欲病之病、下工治已病之病”，整个网络安全建设的趋势，尽量把事先做得更好，做到能照管监控一体化，平战结合一体化。 肖彪： ▪︎ 第一，从国家层面来讲要增强防备； ▪︎ 第二，要在网络安全层面发展一些国内单干； ▪︎ 第三，还需增强对虚构货币的钻研； ▪︎ 第四，咱们须要有一个对立的政策和好的解决形式来面对勒索和挖矿； ▪︎ 第五，是网络安全溯源，这一块单薄我的项目需像腾讯一样的国内顶级的网络安全公司来参加钻研。 宋扬：从平安角度来说： ▪︎ 第一，最重要的是防患于未然，所以咱们提出了平安前置； ▪︎ 第二，是比拟落地的一点，是要增强运维建设人员的安全意识； ▪︎ 第三，咱们在实战中发现，做等保也是十分好的一个伎俩； ▪︎ 第四，无效针对勒索病毒的形式，是增强对云上或者异地的数据备份。

腾讯平安威逼情报联结科恩实验室、腾讯天幕等团队推出了威逼情报小程序，为您提供第一手的情报资讯，助您理解互联网威逼态势、信息泄露、DNS劫持、黑灰产、破绽情报、仿冒危险等内容。 互联网威逼态势 实时统计近30天全网裸露面、勒索、挖矿、APT、病毒木马、僵尸网络、敏感拜访等事件。 信息泄露 布控多渠道，实时监测全网信息泄露状况。 DNS劫持 寰球DNS劫持状况监测，区域级精准监控服务。 黑灰产 笼罩与业务相干的黑灰产工具、业务影响、接码行为、众包线报等内容分析监控，提供笼罩上千数据源的情报专家服务。 破绽情报 实时监测全网0-day破绽裸露事件，提供最全面的业务组件、版本与破绽资讯。 仿冒危险 全网监控互联网仿冒行为，第一工夫把握仿冒业务、工具与影响面。 依靠腾讯平安近二十年网络安全教训、情报大数据及深厚的T-Sec 威逼情报云查服务积攒，威逼情报小程序得已成为一款便捷、无效的信息工具，帮忙企业和网络安全工作者实时跟进各类安全事件与危险挑战，提前增强平安防备，为其部署、决策提供无力撑持，带来时刻相伴的安全感。

网络安全为人民，网络安全靠人民。10月11日上午，一年一度的国家网络安全“顶级盛会”——2021年国家网络安全宣传周网络安全博览会开幕式在西安隆重召开。 据理解，博览会由线下展和线上数字化展会两局部组成，线下展于10月8日起在西安国内会展中心举办；线上数字化展则于10月11日至将来一年，在国家网络安全宣传周官网上展现。 作为互联网安全当先品牌，腾讯平安携旗下腾讯天幕PaaS“腾讯平安算力盒子”、零信赖平安解决方案、云时代全场景平安经营平台Cloud SOC、安心平台、手电管等外围解决方案和平台亮相C-02展台。博览会召开以来，腾讯平安的“护航舰”展台，吸引了少量参展者，一起沉迷式体验产业平安护航之旅。 （图为网安周腾讯平安“护航舰”展台） 腾讯平安算力盒子重磅首发硬核技术打造转型动能 在产业数字化浪潮中，企业级的网络安全反抗工作具备海量数据处理、多简单策略场景、高实时性要求的独特性质，在自主研发、平安可控、算力算法方面有着更为强烈和严苛的要求。 因而，“腾讯平安算力盒子”于网安周重磅首发。该盒子基于腾讯天幕PaaS的高性能平安算力算法能力，以腾讯云星星海灵动水系AC221计算型服务器为底层硬件，聚合科恩实验室、NDR、SOC等优良产品和技术能力，是自主研发、平安可控的云原生信创平安盒子。 （ 图为国家互联网信息办公室副主任赵泽良参观理解“腾讯平安算力盒子”） 盒子内置了腾讯天幕PaaS在云原生平安、自研剖析语言、自研编译器等方面的底层核心技术。区别于传统平安进攻产品须要断网的部署形式，天幕采纳旁路部署形式，可能无变更、无侵入地对4层的申请进行ACL管控，不影响实在业务环境。 以腾讯自研平安算力算法为底层外围能力，腾讯天幕PaaS能在政企、金融、大交通等不同行业的业务场景下，联动各个环节的生态平安产品，实现一点监测、全局联动、全网阻断，帮忙企业实现有机的业技交融和全面的产业平安数字化转型。 码链联合防伪溯源 以“安心”慰“初心” 产业互联网时代，商品的全链路数字化是生产企业数字化改革的外围。商品生产、加工、分销、生产的过程中，假货窜货、数据孤岛、供应链数据断裂等问题让企业、消费者、政府监管等多方主体都深感不“安心”。 腾讯安心平台基于腾讯在一物一码、区块链等前沿技术畛域的积攒和摸索，通过给每个商品赋予一个惟一二维码，商品的每个流通环节通过二维码进行商品数据的共建，通过区块链技术来保障这些数据的不可篡改和隐衷保护性，通过最终消费者的扫码，来确认企业经营数据的真实性，让商品全流程“起源可追、去向可查”。 （ 图为参展者排队扫码体验“安心平台”） 甘肃省定西市的马铃薯在腾讯安心平台反对下，建设了产地编码规定有标准、生产档案有记录、产品包装有标识的马铃薯区块链溯源信息管理平台，每一个马铃薯都有了一张“身份证”，真正助力地标农品“走进来”，中国品牌“立起来”。另外，腾讯平安也为张裕葡萄酒打造了区块链溯源计划，建设了国内首个高端葡萄酒区块链溯源零碎，对于打造国内葡萄酒溯源生态，推动高端酒品溯源行业标准制订具备重要意义。 腾讯安心平台还基于人工智能与大数据技术，打造流量防刷模型，搭建基于营销风控的平安防护体系。深度符合行业品牌流动场景，辨认羊毛党、黄牛党、网赚团伙、内容爬虫等虚伪流量，为品牌业务保驾护航。 博览会上，独具特色的腾讯平安安心平台吸引了泛滥关注，参展者排队扫码体验安心平台是如何为张裕葡萄酒、定西马铃薯等地标农产品保驾护航的。 以“零信赖”重构信赖 筑牢产业平安基座 在云计算、大数据、5G、物联网等技术的推动下，IT不再像过来那样有明确的边界，近程办公、挪动办公等成为常态。零信赖平安提倡的全新平安思路也逐步成为企业数字化转型过程中应答平安挑战的支流架构之一。 腾讯iOA作为国内惟一被国内权威机构Forrester最新报告《2021年第三季度零信赖网络拜访》报告列入竞争者能力象限的零碎，可基于终端平安、身份平安、利用平安、链路平安的“4T”可信准则，对拜访行为进行继续信赖评估和动静受权，达到最小权限访问控制，实现终端在任意网络环境中平安、稳固、高效地拜访企业资源及数据。疫情期间，腾讯iOA胜利反对员工10万+以上的设施接入，实现近程无差别地拜访OA 站点和外部零碎、开发运维等工作。 法规的出台进一步推动行业放慢数据安全布局过程，挑战与时机共存。面向未来的新征程上，腾讯平安愿与更多企业单干，增强技术研发与数据安全技术利用、晋升平安可控能力、构建欠缺的数据安全管理体系，筑牢合规时代的“汽车网络安全底座”，独特摸索汽车网络安全行业新标杆。 （ 图为参展者理解腾讯“零信赖解决方案”） 目前，腾讯iOA在满足外部应用需要的同时，已在政府、金融、医疗、交通等多个行业畛域胜利落地，满足无边界办公运维、混合云业务、分支平安接入、利用数据安全调用、对立身份与业务集中管控、寰球链路减速拜访等六大场景的动静访问控制需要，帮忙少量用户实现新一代网络安全架构降级。 双“管”齐下防护一体 手电管携手反诈 电信网络欺骗立功案例中不法分子的欺骗伎俩层出不穷，骗子在与受害者沟通时，通常不止应用一种社交工具。因而，现有的繁多反欺诈策略难以对黑灰产进行无效治理，须要进行联防联控、跨平台地共享共治。 双“管”齐下，防护一体。本次博览会腾讯平安展台展出的腾讯手机管家和电脑管家双管联动15.0版本汇合了腾讯手机管家和电脑管家的双重能力，对挪动端和PC端联结爱护。除了以往版本各端的爱护能力外，业内还首次突破平台壁垒，实现电话、短信、婚恋社交App等跨平台的欺骗拦挡。 其中联结预警、状态通查、近程互控、利用平安四大联动能力，通过串联事先中后及端内外的残缺欺诈链路，制订全面精准的反欺诈联防联控解决方案，可能为用户带来更全面的防护能力和更丰盛的场景体验。 （ 图为参展者理解腾讯“手电管双管联动”） 此次网安周，除了上述腾讯讯天幕PaaS“腾讯平安算力盒子”、零信赖平安解决方案、安心平台、手电管等，腾讯平安还展出了云时代全场景平安经营平台Cloud SOC、进攻勒索病毒攻打准则等。 （图为云时代全场景平安经营平台Cloud SOC） 其中，Cloud SOC 是腾讯平安面向政务、金融、制造业、医疗、教育等大型企事业单位推出的一款云时代全场景平安经营平台，以平安大数据分析技术为根底，以平安检测、事件关联、相应处理及智能剖析为外围性能，以腾讯威逼情报、3D 可视化、多租户经营为特色，通过海量数据多维分析、及时预警，对威逼及时做出智能处理。 今年以来，随着《数据安全法》《要害信息基础设施平安爱护条例》《个人信息保护法》等多部法规的出台和实施，国家通过网络安全宣传周开释出信号：网络安全已成民生要事，将来将更加器重网络安全环境建设及网安产业倒退。对此，腾讯平安也将继续摸索、实际，一直夯实本身护航产业倒退的根底能力，联结多方力量构建更欠缺的产业生态体系，做好产业数字化转型的平安护航员。

10月10日下午，“2021网络安全优良翻新成绩大赛（总决赛）”在西安顺利落下帷幕。 腾讯平安 “可信终端身份认证解决方案”凭借全方位、多层次、全周期的综合劣势在20多家实力雄厚的解决方案供应商中怀才不遇，以观众评分、专家打分以及总分均第一名的傲人问题，取得了2021年CCIA平安解决方案“一等奖”！ 本次大赛由地方网信办网络安全协调局领导，中国网络安全产业联盟（CCIA）主办，致力于推选我国网络安全产业优良翻新成绩，激发网络安全企业增强自主创新能力，搭建网络安全企业、技术、人才和资本单干的平台，推动网络安全产业高质量倒退的赛事。 总决赛会集了华为、绿盟科技、深服气等十家全国顶尖的网络安全企业单位。决赛评委团亦阵容强大，由网络安全主管部门、行业用户、投融资机构、高等院校、科研机构的10位点评专家和50位观众评委独特组成。 (图为腾讯平安 “可信终端身份认证解决方案”总分获排行榜第一) “腾讯可信终端身份认证解决方案”在历经3轮比拼，历时2个多月，经层层筛选后一举夺魁！基于要害信息基础设施实现国产化的大环境趋势，腾讯平安从客户需要登程，联合各种平安技术能力，为客户提供可代替Windows AD的解决方案。 在身份认证畛域，微软AD（Active Directory，流动目录）是Windows原生的用户身份管理系统，次要用于存储、治理单位中利用账号、用户账号、特权账号，属于十分敏感的信息化根底产品，同时也是黑客入侵攻打次要对象，但为Windows而生的AD并不反对国产操作系统，企业需实现要害信息基础设施逐渐实现国产化，必然要思考AD以外的计划。 应用国产化、平安自主可控的基础设施软件曾经是国家平安策略的大方向，腾讯平安的可信终端身份认证解决方案，可无效解决企业存在的平滑退域、国产化终端治理等平安治理问题。 (10月11日总决赛颁奖仪式“腾讯可信终端身份认证解决方案”获一等奖) 整体来看，腾讯平安能够为企业提供的集中用户和组织机构治理、终端认证、基于组的权限治理等身份治理与认证服务。同时，该计划能够与第三方终端治理、网络准入、SDP、DNS等联动起来，造成一套残缺的信创终端平安生态单干体系。 目前，该计划曾经能够反对麒麟、UOS等国产操作系统，并能兼容企业原有的AD域控，反对对企业终端的分批次退域切换，并保障双轨制运行状态下，新的终端认证零碎与原有AD域环境都能够失常运行。 在利用层面，腾讯可信终端身份认证解决方案曾经在多家国有企业、政府单位及金融机构中胜利落地。以某大型团体为例，该团体信息化建设扩散，团体总部和各子企业别离建有本人的AD域。出于倒退需要，团体信息化建设要从扩散走向对立，而对立的身份认证是要害的前提条件。团体在全面实施腾讯零信赖终端身份认证解决方案后，通过一套对立的身份治理与认证零碎为所有子企业提供终端身份的对立认证，同时满足企业Windows终端和信创终端的登录认证需要。并且无效解决企业新洽购信创终端的可信认证需要，同时升高企业对AD的依赖水平。 随同着数字化深刻倒退，网络安全已成为社会经济倒退的重要前提。将来，腾讯将继续施展本身在平安行业内积攒的技术劣势，依靠腾讯公司20年为互联网10亿级用户打造的海量业务平安经营教训，助力各行各业夯实数字化转型的平安基石。

很多厂在面试的时候，都喜爱问一下对于web平安的问题，比方接下来要说的这个，什么是CSRF以及防范措施有哪些？这文章会带你搞懂CSRF。 什么是CSRF？（Cross Site Request Forgery, 跨站域申请伪造）是一种网络的攻击方式。 咱们通过一个例子来理解它： 小明登陆了一个银行网站 www.bank.com ,银行服务器发来了一个cookie, Set-Cookie:id=a3fWa; 起初小明又拜访了一个歹意网站 www.hacker.com, 这个歹意网站中有一个表单 <form action='www.bank.com/transfer' method='POST'> ...</form>小明无意间触发了这个表单，银行服务器会收到带有正确cookie的申请，而后银行服务器会执行本人定义的操作transfer，这个时候就有可能把小明账户的钱给转走。 CSRF特点攻打个别产生在第三方网站，而不是被攻打网站；攻打利用用户在被攻打网站的登陆凭证(cookie)，假冒受害者提交操作，而不是间接窃取数据；整个过程，攻击者并不能获取到登录凭证，而是冒用；跨站申请能够用各种形式：img图片的src、a标签、form表单提交等等；你说可怕不可怕？当然可怕，那须要怎么避免CSRF攻打呢？你可能会说，用户不点击进入歹意网站不就行了。这当然能够，然而你不能保障每个人都不去点击歹意网站，所以咱们还是要做主动进攻，就算用户拜访了歹意网站，也要保障咱们的网站不会收到攻打。 进攻措施咱们晓得，CSRF个别产生在第三方网站，而且攻击者只是冒用登录凭证而不是获取登录凭证数据，所以咱们制订以下防备策略： 阻止不明内部域名的拜访 同源检测Samesite Cookie提交Form表单时，增加本域能力获取的验证信息 CSRF token1. 同源检测Cookie的同源和浏览器的同源策略有所区别： * 浏览器同源策略：协定、域名和端口都雷同即同源；* Cookie同源策略：域名雷同即同源；在HTTP协定中，每个异步申请都会携带两个header,用来标记起源域名： * Origin Header* Referer Header这两个Header在浏览器发动申请时，大多数状况会主动带上，并且不能由前端批改，服务器接管到后能够依据这两个Header确定起源的域名； 非凡状况: 如果Origin和Referer都不存在，倡议间接进行阻止，特地是如果您没有应用随机CSRF Token（参考下方）作为第二次查看。 另外，CSRF大多数状况下来自第三方域名，但并不能排除本域发动。如果攻击者有权限在本域公布评论（含链接、图片等），那么它能够间接在本域发动攻打，这种状况下同源策略无奈达到防护的作用。 综上所述：同源验证是一个绝对简略的防备办法，可能防备绝大多数的CSRF攻打。但这并不是十拿九稳的，对于安全性要求较高，或者有较多用户输出内容的网站，咱们就要对要害的接口做额定的防护措施。 2. Samesite Cookie属性Chrome 51版本 开始，浏览器的 Cookie 新减少了一个SameSite属性，用来避免 CSRF 攻打。 Cookie的Samesite属性用来限度第三方Cookie, 从而缩小平安危险，它有三个值： Set-Cookie: SameSite = Strict;Set-Cookie: SameSite = Lax;Set-Cookie: SameSite = None;Strict： 最为严格，齐全禁止第三方Cookie, 跨站点时，任何状况都不发送Cookie;Lax： 限度略微宽松，大多数状况下时不发送第三方Cookie的，除了a链接、预加载申请和GET表单；None： 敞开SameSite属性，但必须同时设置Secure属性，如下： Set-Cookie: SameSite = None // 有效Set-Cookie: SameSite = None; Secure // 无效设置了Strict或Lax，根本就能阻止CSRF攻打，前提是浏览器反对SameSite属性。 ...

还有三天，首届西部云平安峰会就要在西安和大家见面了！ 作为西安地区首个聚焦云平安技术交换的平台，本次大会不仅汇聚了西安电子科技大学、西安交大等多所高校退出，还将重磅公布交融产学研各方力量的人才培养打算，为西安及西部地区积蓄云平安人才池，为西部数字经济倒退保驾护航。 始终以来，微小的人才供需缺口都是平安行业面临的痛点问题。据相干业余机构统计，目前我国网络安全人才缺口微小，达150万之多，预计2027年缺口将进一步扩充至300万。而对于新兴的云平安畛域而言，人才稀缺问题更加重大。如何造就适应当下产业需要和平安趋势的复合型人才，是西部数字化倒退的重中之重。过来两年，云鼎实验室通过举办云平安挑战赛，打造实在靶场、模仿实战攻防，邀请各路极客对多元、简单的云计算环境，开展前沿技术摸索，并从中开掘和造就了一批又一批优良网安人才。此次联结西安多所高校，又将如何打造西部格调的人才动作？ 9月26日·西安 2021首届-西部云平安峰会 期待你的退出！

随着后疫情时代促使大量经济流动向线上迁徙，游戏、直播、电子商务、线上教育等互联网行业继续凋敝，黑产团伙也从2017年下半年的司法打击重创中复苏，多向量DDoS攻打间断四年呈指数级增长。 过来，DDoS攻打较多针对大型企业，然而随着攻打老本升高，现在越来越多的黑客团伙将指标扩散至中小企业，国内一些在线教育网站、搜寻推广平台、网络游戏、BC服务平台等都受到过DDoS攻打，导致数据中心中断，重大影响业务失常运行。 9月初，腾讯平安联结绿盟科技公布《2021年上半年寰球DDoS威逼报告》，多维度出现过来半年DDoS攻打的倒退态势。国庆重保将至，腾讯平安携手腾讯产业互联网学堂、绿盟科技邀请到腾讯云抗DDoS资深平安经营经理杨欢、腾讯云抗DDoS资深平安专家梁海兵、以及绿盟科技资深平安专家等，别离带来境内、海内互联网业务DDoS防护计划与实际、2021年DDoS攻打趋势解读间断三场专题内容分享，全面解析各种DDoS攻打的应答之道，帮忙各行业用户在国庆重保降临之际，提前做好平安防护，保障业务平安可用。

近日，国内权威钻研机构Gartner公布了一份题为《Emerging Technologies:Adoption Growth Insights for Network Detection and Response》的市场钻研报告，对网络检测与响应技术（Network Detection and Response，简称NDR）的市场利用趋势进行了剖析。腾讯平安的高级威逼检测产品T-Sec NTA作为NDR技术的典型产品被该份报告提及。 Gartner指出，“只管疫情大风行造成了影响，但NDR依然是一个快速增长的市场。2020年，寰球供应商支出增长了23%(Market Share: EnterpriseNetwork Equipment by Market Segment, Worldwide, 4Q20 and 2020) ，预计从2020年到2025年，年复合增长率将放弃在19%。（Forecast: Enterprise Network Equipmentby Market Segment, Worldwide, 2019-2025, 1Q21 Update)。另外，平安入侵事件SolarWinds SUNBURST也引起人们对NDR的更多趣味。只管这一市场的增长仍有稳定，但对NDR的关注和投入趋势逐年稳固。这一市场稳固而疾速的倒退，意味着NDR产品领导者能够进行长期投入，以升高市场变动造成的投资危险。” 在本份报告中提及的腾讯平安高级威逼检测零碎T-Sec NTA（御界），离不开腾讯平安基于二十余年的技术、人才和教训积淀，在流量威逼检测与响应畛域具备了深厚的积攒，通过大量利用人工智能、机器学习等高级检测办法，可无效辨认网络中埋伏的威逼，检测成果显著优于传统检测办法，并且通过联动腾讯天幕旁路阻断造成检测响应闭环。 目前，腾讯平安高级威逼检测零碎T-Sec NTA（御界）曾经在多个行业落地利用，帮忙平安人员胜利进攻住了多种攻打。在和国内某头部银行的单干中，腾讯平安高级威逼检测零碎T-Sec NTA（御界）帮忙其胜利守护了3000多个云服务器和160个公共服务和网站，并通过警报相关性剖析将警报数量缩小76％，阻断率可达99.9%，显著进步了平安运维人员考察事件和解决警报的效率。 随着寰球数字化转型减速，平安威逼曾经成为网络空间攻防反抗的重要模式，其攻打指标遍布政治、经济、情报等多个重要板块。面对简单的安全形势，腾讯平安将继续晋升防护能力，为政企机构顺利完成数字化降级夯实底座。 参考资料： [1] Emerging Technologies: Adoption Growth Insights for NetworkDetection and Response, Nat Smith, Christian Canales, Josh Chessman,24 March2021 Gartner, Forecast:Enterprise Network Equipment by Market Segment, Worldwide, 2019-2025, 1Q21Update, Christian Canales et al., 25 March 2021 ...

在上个系列《你的DNS服务真的安全么？》里我们介绍了DNS服务器常见的攻击场景，看完后，你是否对ddos攻击忧心重重？本节我们来告诉你，怎么破局！! 首先回顾一下DDoS攻击的原理。DDoS是Distributed Denial of Service的简称，即分布式拒绝服务攻击，其利用处于不同位置的足够数量的僵尸主机产生数目巨大的数据包对一个或多个目标实施DoS攻击，耗尽受害端的网络带宽、系统资源，使受害主机或网络丧失提供正常网络服务的能力。 【传统网络对DDoS攻击的防御】 那传统网络是怎么对DDoS攻击进行安全防御的呢？简单来讲，传统安全技术的防护手段，通常是代替server端来响应client发过来的请求，并通过client的下一步动作有无跟进继续请求，来判断该请求是否来自真实用户。因为如果是肉鸡发起的攻击行为，通常不会再有下一步的动作被匹配到。而如果某个特定的client IP一旦被认定为是真实请求的IP，则该IP会被放入对应的“白名单池”，后续一段时间内，当该IP继续请求时，便会被认为是合法的。可参考如下示意图： 这只是一个简单的原理模拟图，有些在策略上可能不一定适用黑白名单IP list。 【传统权威DNS服务器对DDoS的防御手段】  知道了DDoS的常用防御手段，我们再来说说，对于传统的权威DNS服务器，是怎么防护DDoS攻击的。对于权威DNS而言，默认的请求都是基于UDP，而且DNS协议里面明确说明了DNS服务器可以限制为TCP提供的资源，所以权威DNS的DDoS攻击防御最重要的是如何防住UDP攻击。 但是UDP DDoS防御的最大的问题莫过于UDP没有会话，不能通过包的交互来判断某个请求是否为攻击行为，仅仅查看某个DNS数据报文是不可能区分是否为攻击请求或者真实用户请求的。因此传统安全技术首要地工作就在于需要将缺乏会话交互的UDP一来一回请求转换成为具有会话记录的UDP多来多回请求，它们会利用DNS协议的特点采用如下技术进行防御： 1、CNAME重传 利用DNS的特性，递归请求具有迭代查询一直到获取最终结果的特点，直接代替DNSserver给client返回一个伪造的唯一随机字符串cname域名，并根据该源IP是否继续发起针对该cname域名的请求来判定，该IP是否为正常请求。很显然，如果某个IP马上跟进发起了该cname域名的请求，则该IP是可被信任的；相对地，如果某个IP在规定的超时时间内并没有发起针对该cname域名的请求，则该IP将被判定为攻击者 2、TC重传 利用DNS的特性，在DNS请求client遇到DNS应答flag字段中TC标记为1时必然会发起TCP DNS请求的特点，直接代替DNS server给client返回一个伪造的空应答但该应答flag字段中TC标记为1，并根据该源IP是否继续发起针对该域名的TCP的DNS请求来判定，该IP是否为正常请求。很显然，如果某个IP马上跟进发起了TCP的DNS请求，则该IP是可被信任的；相对地，如果某个IP在规定的超时时间内并没有发起针对的TCP请求，则该IP将被判定为攻击者。  3、首包丢弃 利用DNS的特性，在DNS请求client在超时时间内没有收到DNS应答时会重发该请求的特点，传统安全直接丢弃该首包请求，并根据该源IP是否继续发起针对这个域名的第二次请求来判定，该IP是否为正常请求。很显然，如果某个IP针对性地发起了第二次请求，则该IP是可被信任的；相对地，如果某个IP在规定的超时时间内并没有发起第二次请求，则该IP将被判定为攻击者。 由以上信息我们可以知道，这三种手段其原理都是通过将原来的DNS的UDP一来一回请求转换成为具有会话记录的UDP多来多回请求，并通过判断第二次请求的特点来判定该源IP是否为真实用户访问行为或者攻击行为，并随之进行对应的白名单/黑名单操作。 【传统方案在权威DNS防护中存在的问题】 以上的传统方案是不是就能完全保护我们的权威DNS了呢？其实还是存在一些防护的问题。以下我们总结了权威DNS防护可能遇到的问题： 1、 首先从首包丢弃来讲，这是在权威DNS防御中基本没有被采用的技术，原因主要是递归DNS在遇到权威查询请求被丢弃时会根据SRTT算法另外选择其他的权威服务器，导致传统安全基本上无法收到所谓的“第二次请求”，因此误杀的概率极高。同时权威丢弃递归发过来的查询，会对递归服务器的资源占用造成严重影响，这种情况下递归服务器可能会根据自身保护的策略直接丢弃该域名的正常请求，有可能造成更严重的故障。 2、 其次是TC重传，相对于CNAME重传的策略，TC重传主要的好处在于并没有从数据内容信息上去进行篡改，并没有“伪造”对应的应答；而重大的缺陷在于需要安全服务DNSserver端支持TCP的请求，这个在性能上是非常大的考验，带来的被打瘫的风险反而会进一步加大。另外，有一部分ISP的 LocalDNS根本不支持TCP也是一个重要的问题。 3、 再来谈CNAME重传，前文提到了CNAME重传最大的问题在于“伪造”了一个虚构的应答，正常流程中这个“伪造”的应答只起到中间传递的结果不会有其他方面的影响，但是现实情况中，ISP侧的各种“缓存递归分离”“缓存加速应答”技术都会对正常的流程进行篡改，导致前面提到的这个“伪造”的结果被当成正确的结果直接回给终端用户；更要命地是，ISP侧的DNS各种“优化TTL”的技术还会把这种问题严重放大，最终导致严重的故障。 针对这种问题，最终我们可能看见类似的错误结果： 总结，通过上面针对性的描述，我们大概知道了这些方法用在DNS上都有或多或少的问题。当然，其实还包括一些安全集群DNS会话状态数据一致性、互联网原生丢包带来的黑白名单误杀、伪造IP攻击影响真实IP带来的误杀等各种情况下的误杀，这部分误杀带来的影响也不可小视。 【权威DNS攻击的防护重点】 说了这么多，权威DNS究竟如何防？说真的，DNS系统本身的优异性能非常关键。打铁还需自身硬，还是建议选择一款性能优异的服务器作为权威的DNS服务器。从原理上来讲，传统安全把缺乏会话交互的UDP一来一回请求转换成为具有会话记录的UDP多来多回的策略比起单纯的回复一个DNS应答更耗费计算资源。比如在同样的性能条件资源下，回复一个所谓的“cname应答”或者“tc应答”，还不如直接回复原生的DNS应答，粗略比较下来两者之间耗费CPU指令集并没有什么差别。当然前提最重要的是DNS系统要有卓越的性能，超大的带宽，有能力媲美安全服务器甚至优于安全服务器。阿里云解析DNS具备单机千万级QPS，遍布全球的超大规模集群，具备anycast的架构、依托阿里巴巴大容量、稳定的基础网络，能够轻松抵抗过亿级的DDoS攻击。阿里云解析DNS绝对值得你的信赖。（-->云解析详情页） 本文作者：kimi_nyn 原文链接 本文为云栖社区原创内容，未经允许不得转载。

如何禁止公司员工私自接随身wifi和WiFi热点成为很多公司安全部门头疼的问题，私建热点不仅对正常wifi速率影响而且可能引发有严重的重大网络安全事件。很多安全事件都是通过这种无意识的行为导致公司机密泄露。 这里介绍一款安全防护硬件，主要解决这类问题。支持黑白名单模式，能有效从根本上解决这个问题。 登陆 监控面板 防护设备 防护事件 防护规则 支持环境识别和学习功能

当地时间 8 月 3 日和 4 日，美国发生了两起大规模枪击事件，共造成 31 人死亡，51 人受伤。在枪击案几乎成为日常的美国，很多公司借助于人工智能技术，来实时定位枪击案发地点、预测犯罪行为，并成功降低了犯罪率。在刚过去的周末，美国两个州（德州和俄亥俄州）接连枪声四起，当地人被这两起噩梦一般的枪击案，惊扰得惶惶不安。 埃尔帕索枪击案现场，人们摆上鲜花祭奠亡者德州埃尔帕索大规模枪击案共造成 22 人死亡，24 人受伤，成为美国有史以来第七大最致命枪击案。 第二权利法案：笼罩美国 200 多年的持枪阴霾当地时间 8 月 3 日（周六）早上，德州埃尔帕索市（El Paso）一家沃尔玛大卖场发生枪击案。一名 21 岁的白人男子手持 AK-47，对在场的居民进行扫射，22 人无辜丧生。 而距离德州枪击案发生不到 14 个小时，大家还惊魂未定之时，俄亥俄州代顿镇又紧接着于当地时间 4 日凌晨，发生一起重大枪击事件，造成 9 人死亡，27 人受伤。 枪杀已经成为美国最常见的死因。据非营利性机「枪支暴力档案」(Gun Violence Archive)的统计，在今年，美国迄今已发生 253 起大规模枪击案（截至发稿时最新数据）。 美国 2019 年因枪击死亡人数已达到 8400 多人24 小时内连续的两起枪击事件，让美国民众处于焦虑与恐惧之中。他们举行示威活动，要求美国政府和国会积极推动控枪法律。 然而，美国合法持枪的法律历史已久，形成了根深蒂固的枪支暴力顽疾，如同阴霾一般，笼罩美国已有 200 多年。 1791 年 12 月 15 日，第二权利法案（也叫美国宪法第二修正案）被批准，即： A well regulated militia, being necessary to the security of a free state, the right of the people to keep and bear arms, shall not be infringed. ...

一、导语『洞察』是宜信安全部开发，集成应用系统资产管理、漏洞全生命周期管理、安全知识库管理三位一体的管理平台。 应用系统资产管理：对公司应用系统资产进行管理，包括系统名称、域名、重要级别、部门、负责人等。漏洞生命周期管理：对公司应用系统产生的安全漏洞进行线上提交、通告、知悉、复测、分类、风险计算、修复期限计算、邮件提醒、漏洞数据分析统计等。安全知识库管理：对安全知识、管理制度进行集中存放、线上学习、安全培训、知识传承等。『洞察』使用了Python语言进行开发，利用Flask框架+MySQL+Docker部署实现。 洞察界面截图如下： 二、设计理念应用安全管理从应用资产的风险评估开始，公司资产一旦多了之后，往往会面临资产不清晰、找不到负责人、漏洞持续跟踪成本高昂、安全知识难以沉淀、高频风险没有数据支持、不能有的放矢的解决核心问题，另外风险量化也是难题。 应用安全管理体系设计中，风险治理一般过程如下： 基于上述风险治理的实际需求，『洞察』应运而生。 三、平台亮点使用『洞察』系统后，我们实现了以下目标，请看大图： 历史漏洞一目了然 漏洞跟踪有条不紊 学习案例信手拈来 安全要求精准管控 威胁风险有理有据 量化数字实时知晓 四、使用指南平台用户分为以下5种角色 匿名用户：公司内部未登录用户普通用户：普通登录用户，指公司研发、业务、产品经理等。安全人员：安全部门进行漏洞测试、提交、跟踪修复的人员等。安全管理员：安全部门对漏洞进行审核的管理人员。超级管理员：最高权限账号，对用户的角色进行分配。以上5种角色对应的使用文档请见： 使用指南-匿名用户篇：https://github.com/creditease... 使用指南-普通用户篇：https://github.com/creditease..._user.md 使用指南-安全人员篇：https://github.com/creditease..._user.md 使用指南-安全管理员篇：https://github.com/creditease..._manager.md 使用指南-超级管理员篇：https://github.com/creditease..._user.md 五、项目地址OWASP项目地址 洞察-宜信漏洞管理平台目前已被OWASP S-SDLC项目组正式收录，更多英文版详情请见OWASP S-SDLC项目地址： https://www.owasp.org/index.p..._Secure_Software_Development_Lifecycle_Project#tab=Main https://www.owasp.org/index.p..._Secure_Software_Development_Lifecycle_Project#tab=Related_stuffs GitHub开源地址：https://github.com/creditease... 内容来源：宜信技术学院

文章首发于我的博客：查看原文 文章是学习了慕课网老师视频整理，视频地址：Web安全-XSS 文末有惊喜哦 一、什么是XSS？XSS（Cross-site scripting），跨站脚本，一种在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。这类攻击通常包含了HTML以及用户端脚本语言。二、XSS的攻击方式攻击有什么用？？=> 1、盗用cookie等，获取敏感信息；2、 破坏页面结构；3、其他～2.1 反射型发出请求时，XSS代码出现在URL中，作为输入提交到服务器，服务器端解析后响应，XSS代码随响应内容一起返回给浏览器，最后浏览器解析响应XSS代码。这个过程像一次反射，所以称为反射型XSS。这里要注意的有几个点： XSS代码出现在URL中；服务端解析响应浏览器解析代码这里的XSS代码通常是CSS，javascript或者HTML片段。 2.2 存储型存储型XSS和反射型XSS的差别在于提交的代码会存储在服务端（数据库、内存、文件系统等），下次请求目标页面时，无需再次提交XSS代码。比如，当你访问一个人的博客时(不要搞我！)，你去他的文章下面添加一些评论，这些评论一般都会存下来，如果他的博客没有作什么处理，那么，一个简单的XSS攻击就算生效了： 2.2.1 插入html片段： <img src="null" onerror="alert(“你被攻击了哦！”)" >当你在评论中插入了一个 ==img== 标签，由于图片路径找不到，所以就会执行==onerror==方法，这样，onerror中的js脚本就被触发了，每次当用户访问到这篇文章，加载到这条评论时，都会触发这个弹窗。这样，一次简单的XSS就算生效了。 <button onclick="alert('你被攻击了哦！')">点我呀</button> 向页面中插入一个按钮，诱导用户进行操作，进而被攻击了～ <iframe> <iframe>向页面中插入一个iframe(或者frame)，来插入一些小广告？～。 2.2.2 插入CSS <style> html,body{ display:none!important; }</style><link href= "">如果向你的页面中插入上面的代码，当别人访问你的页面时，将会什么也看不到. 2.2.3 插入js代码 <script>window.onload = function (){ alert('你被攻击了哦！')}</script>如果向你的页面中插入上面的代码，同样也被攻击了～。 由此得出一点，慎用==innerHTML== 三、XSS的防范措施3.1 编码对用户输入的内容进行HTML Entity编码（字符转义），不能进行原样输出。在编写HTML页面时，需要用到"<"、">"、"空格"、"&"、"引号"直接输入这些符号时，会错误的把它们与标记混在一起，非常不利于编码。所以 需要对这些字符进行转义。 CharacterEntity&&amp;<&lt;| &gt;" | &quot;空格 | &nbsp;3.2 过滤过滤掉用户输入的一些不安全的内容3.2.1 移除用户上传的DOM属性，入onclick，onerror等 3.2.2 移除用户上传的style节点，script节点，iframe节点等。 3.3 校正3.3.1 避免直接对HTML Entity进行解码 3.3.2 使用DOM Parse转换，校正不配对的DOM标签 DOMParser: 可以将存储在字符串中的 XML 或 HTML 源代码解析为一个 DOM Document。我的博客使用了第三方库htmlparser2进行过滤和校正 ...

web安全讲述确保您的 Web 站点或 Web 应用安全是十分重要的，即使是代码中很小的 bug 也可能导致隐私信息被泄露，黑客会尝试偷窃数据。这些文档提供信息帮助您使代码更安全。此处列出的面向 Web 安全的文章提供的信息可以帮助您保护站点及其代码免受攻击和数据窃取。 CSP内容安全策略xss跨站点脚本攻击CSRF 跨站点请求伪造CSP内容安全策略CSP 的主要目标是减少和报告 XSS 攻击 ，XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行，因为浏览器信任其内容来源，即使有的时候这些脚本并非来自于它本该来的地方。 CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。 Content-Security-Policy: policy 一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码, 启用发送违规报告，你需要指定 report-uri 策略指令，并提供至少一个URI地址去递交报告： Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com; report-uri http://reportcollector.example.com/collector.cgi xss跨站点脚本攻击跨站脚本攻击Cross-site scripting (XSS，为了不和CSS重名)是一种安全漏洞，攻击者利用这种漏洞可以在客户端注入恶意代码，可以完成获取cookie、session的读取，还可以利用脚本串改HTML内容，引导用户进入第三方恶意站点，主要表现就是： 将一些隐私数据像cookie、session发送给攻击者，将受害者重定向到一个由攻击者控制的网站，在受害者的机器上进行一些恶意操作。目前常见的分类包括了： 存储型【永久型】：包括了服务端的操作反射型：有服务端的参与DOM型：纯客户端的攻击存储型【持久型】主要是表现在客户端的输入内容【博客内容、表单提交、富文本编辑等】提交到服务端，被服务端保存，并在返回到客户端进行展示；如果其中含有恶意脚本<script>alert(‘我是存储型XSS攻击')</script>，并被客户端插入到文档流中，那么恶意脚本会被执行，恶意脚本可以完成读取隐私数据、重定向、修改页面展示结构等操作。 反射型【非持久型】反射型 XSS 只是简单地把用户输入的数据 “反射” 给浏览器，这种攻击方式往往需要攻击者诱使用户点击一个恶意链接，或者提交一个表单时，恶意链接中的而已脚本参数或者表单提交的恶意脚本经过服务端的关联，注入到了当前访问的文档流中，恶意脚本被执行，和存储型一样，恶意脚本都可以完成读取隐私数据、重定向、修改页面展示结构等操作。 基于DOM型这是一种纯客户端的攻击，客户端在处理页面地址链接时将恶意脚本注入到了正常文档流中，或者是编辑富文本的时候将它处赋值的含有恶意脚本的富文本插入到了文档流中，导致恶意脚本的执行。同样可以完成读取隐私数据、重定向、修改页面展示结构等操作。 防范xss保证隐私数据的安全性，添加cookie时，设置 Secure; HttpOnly，仅支持https连接和脚本无法读取。Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly处理任何用户端的输入用户端的自定义输入是完全无法保证的，所以需要进行处理，包括特殊字符的转译和限制长度等。服务端的数据转译如果服务端的数据遭到了存储型攻击，那么就需要对服务端的数据进行必要的转译编码，CSRF 跨站点请求伪造跨站请求伪造（CSRF）是一种冒充受信任用户，向服务器发送非预期请求的攻击方式。例如，这些非预期请求可能是通过在跳转链接后的 URL 中加入恶意参数来完成:<img src="https://www.example.com/index.php?action=delete&id=123">对于在 https://www.example.com 有权限的用户，这个 <img> 标签会在他们根本注意不到的情况下对 https://www.example.com 执行这个操作，即使这个标签根本不在 https://www.example.com 内亦可。 ...

现在很多iOS的APP没有做任何的安全防范措施，导致存在很多安全隐患和事故，今天我们来聊聊iOS开发人员平时怎么做才更安全。 一、网络方面用抓包工具可以抓取手机通信接口的数据。以Charles为例，用Charles可以获取http的所有明文数据，配置好它的证书后就可以模拟中间人攻击，获取https加密前的明文数据。 1.1 中间人攻击先简要地说下什么是中间人攻击： ①客户端：“我是客户端，给我你的公钥” -> 服务端（被中间人截获）。 所以现在是： 客户端->中间人 ②然后中间人把消息转给服务端，也就是： 中间人->服务端 ③服务端把带有公钥的信息发送给客户端，但是被中间截获。所以是： 服务端-[服务端的公钥] ->中间人 ④中间人把服务端的公钥替换成自己的公钥，发送给客户端，声称是服务端的公钥： 中间人-[中间人的公钥] ->客户端 ⑤客户端用得到的公钥加密，实际是用中间人的公钥进行加密，所以中间人可以用自己的私钥解密，获取原始数据，然后再用服务端的公钥对原始数据（或者修改原始数据内容）加密后发送给服务端。 这样中间人就可以获取到双方的通信数据，并可以制造虚假数据。 1.2 如何防范中间人攻击？下面开始说如何防范： 1.2.1 SSL PinningSSL Pinning的原理就是把服务端的公钥存到客户端中，客户端会校验服务端返回的证书是否和客户端保存的一致，这样就避免了中间人替换证书进行的攻击。 SSL Pinning的实现比较简单，只需要把CA证书放入项目中，通过Security framework实现NSURLSession上的SSL Pinning。如果用的是AFNetworking，代码更简单一点： 这样通过Charles抓包就会报错。 证书验证有可以只验证公钥（AFSSLPinningModePublicKey），也可以完全验证证书（AFSSLPinningModeCertificate）。 但是用SSL Pinning有个很严重的问题，就是如果证书有问题，只有发布新版本才能解决。如果新版本一直审核不通过，app的网络通信就全部挂掉了。 比如赛门铁克（Symantec）证书被google和iOS12不信任的问题。如果app内置了证书，就必须要重新发版。 1.2.2 接口内容进行加密很多的app接口只对请求的参数进行加密和各种验证，而接口返回过来的数据就是明文。如果不用SSL Pinning来防止中间人攻击，也可以把接口返回的数据也进行加密，这样抓包工具抓到包后也依然不能破解。 比如微信，微信中的接口用的是http协议，但是内容全部进行了加密。 现在常用的是对称加密，加密效率比较快。如果app里有的数据特别重要，还是要用非对称加密，非对称加密更安全，但是效率会比较慢。 二、日志2.1 Swift日志Swift中打印日志的语法可以用print，也可以用NSLog。但是尽量别用NSLog，因为Swift中用NSLog，系统日志中是能查到的。可以通过pp助手、iTools或者Xcode的Devices and Simulators 来查看系统日志。 用print打印日志就不会出现在系统日志中。 2.2 OC日志在release环境下不要输出NSLog日志。一般大家都会用宏定义解决，如下： 三、信息的存储3.1 密钥大部分的程序员喜欢直接把密钥放到宏或者常量里。 如：#define AES_KEY @“aaa123" 这样做很容易就可以被反编译出来。安全性比较差。可以用以下方法加强安全，增加破解的难度。 对密钥（A）进行加密后定义为宏（B），使用的时候进行解密得到密钥（A）。其中对密钥A加密的密钥为C。 因为在宏定义的时候我们如果定义成字符串，会直接存在data段，这样破解者很容易获取到。比较安全的做法是把C和B定义成uint8_t[]数组，这样每个字符就会放到text段的每个单独指令中。指令执行后生成字符串。这样就会很安全。 用一段长文本，按规则提取出里面的密钥，密钥是随机的。 在服务端和客户端定义一段长文本，app端随机生成起始位置和长度，把起始位置和长度进行移位等操作，生成相应的数字，对数字进行Base64编码，生成的字符串 传给服务端，服务端根据这个字符串 就能 解析出相关的密钥。 代码如下： ...

在电商行业，线上的营销活动特别多。在移动互联网时代，一般为了活动的快速上线和内容的即时更新，大部分的业务场景仍然通过 Web 页面来承载。但由于 Web 页面天生“环境透明”，相较于移动客户端页面在安全性上存在更大的挑战。本文主要以移动端 Web 页面为基础来讲述如何提升页面安全性。活动 Web 页面的安全挑战对于营销活动类的 Web 页面，领券、领红包、抽奖等活动方式很常见。此类活动对于普通用户来说大多数时候就是“拼手气”，而对于非正常用户来说，可以通过直接刷活动 API 接口的“作弊”方式来提升“手气”。这样的话，对普通用户来说，就变得很不公平。对于活动运营的主办方来说，如果风控措施做的不好，这类刷接口的“拼手气”方式可能会对企业造成较大的损失。如本来计划按 7 天发放的红包，在上线 1 天就被刷光了，活动的营销成本就会被意外提升。主办方想发放给用户的满减券、红包，却大部分被黄牛使用自动脚本刷走，而真正想参与活动的用，却无法享受活动优惠。终端用户到底是人还是机器，网络请求是否为真实用户发起，是否存在安全漏洞并且已被“羊毛党”恶意利用等等，这些都是运营主办方要担心的问题。安全防范的基本流程为了提升活动 Web 页面的安全性，通常会引入专业的风控服务。引入风控服务后，安全防护的流程大致如图所示。Web 前端：用户通过 Web 页面来参与活动，同时 Web 前端也会收集用于人机识别验证的用户交互行为数据。由于不同终端（移动端 H5 页面和 PC 端页面）交互形式不同，收集用户交互行为数据的侧重点也会有所不同。风控服务：一般大公司都会有专业的风控团队来提供风控服务，在美团内部有智能反爬系统来基于地理位置、IP地址等大数据来提供频次限制、黑白名单限制等常规的基础风控拦截服务。甚至还有依托于海量的全业务场景的用户大数据，使用贝叶斯模型、神经网络等来构建专业度较深的服务。风控服务可以为 Web 前端提供通用的独立验证 SDK：验证码、滑块验证等区分人机的“图灵验证”，也可以为服务端提供 Web API 接口的验证等。后端业务服务：负责处理活动业务逻辑，如给用户发券、发红包，处理用户抽奖等。请求需要经过风控服务的验证，确保其安全性，然后再来处理实际业务逻辑，通常，在处理完实际业务逻辑时，还会有针对业务本身的风控防范。对于活动 Web 页面来说，加入的风控服务主要为了做人机识别验证。在人机识别验证的专业领域上，我们可以先看看业界巨头 Google 是怎么做的。Google 如何处理人机验证Google 使用的人机验证服务是著名的 reCAPTCHA（Completely Automated Public Turing Test To Tell Computers and Humans Apart，区分人机的全自动图灵测试系统），也是应用最广的验证码系统。早年的 reCAPTCHA 验证码是这样的：如今的 reCAPTCHA 已经不再需要人工输入难以识别的字符，它会检测用户的终端环境，追踪用户的鼠标轨迹，只需用户点击“我不是机器人”就能进行人机验证（reCAPTCHA骗用户进行数据标注而进行AI训练的验证另说）。reCAPTCHA 的验证方式从早先的输入字符到现在的轻点按钮，在用户体验上，有了较大的提升。而在活动场景中引入人机识别验证，如果只是简单粗暴地增加验证码，或者只是像 reCAPTCHA 那样增加点击“我不是机器人”的验证，都会牺牲用户体验，降低用户参加活动的积极性。Google 的普通 Web 页面的浏览和有强交互的活动 Web 页面虽是不同的业务场景，但对于活动 Web 页面来说，强交互恰好为人机识别验证提供了用户交互行为数据收集的契机。人机识别验证的技术挑战理想的方案是在用户无感知的情况下做人机识别验证，这样既确保了安全又对用户体验无损伤。从实际的业务场景出发再结合 Web 本身的环境，如果想实现理想的方案，可能会面临如下的技术挑战：（1）需要根据用户的使用场景来定制人机识别验证的算法：Web 前端负责收集、上报用户交互行为数据，风控服务端校验上报的数据是否符合正常的用户行为逻辑。（2）确保 Web 前端和风控服务端之间通信和数据传输的安全性。（3）确保上述两大挑战中提到的逻辑和算法不会被代码反编译来破解。在上述的三个挑战中，（1）已经实现了人机识别验证的功能，而（2）和（3）都是为了确保人机识别验证不被破解而做的安全防范。接下来，本文会分别针对这三个技术挑战来说明如何设计技术方案。挑战一：根据用户使用场景来定制人机识别验证算法先来分析一下用户的使用场景，正常用户参与活动的步骤是用户进入活动页面后，会有短暂的停留，然后点击按钮参与活动。这里所说的“参与活动”，最终都会在活动页面发起一个接口的请求。如果是非正常用户，可以直接跳过以上的实际动作而去直接请求参与活动的接口。那么区别于正常用户和非正常用户就是那些被跳过的动作，对实际动作进一步归纳如下：进入页面。短暂的停留。滚动页面。点击按钮。以上的动作又可以分为必需的操作和可选的操作。对这一连串动作产生的日志数据进行收集，在请求参与活动的接口时，将这些数据提交至后端，验证其合法性。这就是一个简单的人机识别验证。在验证动作的合法性时，需要考虑到这些动作数据是不是能被轻易模拟。另外，动作的发生应该有一条时间线，可以给每个动作都增加一个时间戳，比如点击按钮肯定是在进入页面之后发生的。一些特定的动作的日志数据也会有合理的区间，进入页面的动作如果以 JS 资源加载的时间为基准，那么加载时间可能大于 100 毫秒，小于 5 秒。而对于移动端的按钮点击，点击时记录的坐标值也会有对应的合理区间，这些合理的区间会根据实际的环境和情况来进行设置。除此之外，设备环境的数据也可以进行收集，包括用户参与活动时使用的终端类型、浏览器的类型、浏览器是否为客户端的容器等，如果使用了客户端，客户端是否会携带特殊的标识等。最后，还可以收集一些“无效”的数据，这些数据用于障人耳目，验证算法会将其忽略。尽管收集数据的动作是透明的，但是验证数据合法性不是透明的，攻击者无法知道，验证的算法中怎么区分哪些是有效、哪些是无效。这已经有点“蜜罐数据”的意思了。挑战二：确保通信的安全性收集的敏感数据要发送给风控服务端，进而确保通信过程的安全。Web API 接口不能被中途拦截和篡改，通信协议使用 HTTPS 是最基本的要求；同时还要让服务端生成唯一的 Token，在通信过程中都要携带该 Token。接口携带的敏感数据不能是明文的，敏感数据要进行加密，这样攻击者无法通过网络抓包来详细了解敏感数据的内容。Token 的设计Token 是一个简短的字符串，主要为了确保通信的安全。用户进入活动 Web 页面后，请求参与活动的接口之前，会从服务端获取 Token。该 Token 的生成算法要确保 Token 的唯一性，通过接口或 Cookie 传递给前端，然后，前端在真正请求参与活动的接口时需要带上该 Token，风控服务端需要验证 Token 的合法性。也就是说，Token 由服务端生成，传给前端，前端再原封不动的回传给服务端。一旦加入了 Token 的步骤，攻击者就不能直接去请求参与活动的接口了。Token 由风控服务端基于用户的身份，根据一定的算法来生成，无法伪造，为了提升安全等级，Token 需要具有时效性，比如 10 分钟。可以使用 Redis 这类缓存服务来存储 Token，使用用户身份标识和 Token 建立 KV 映射表，并设置过期时间为 10 分钟。虽然前端在 Cookie 中可以获取到 Token，但是前端不能对 Token 做持久化的缓存。一旦在 Cookie 中获取到了 Token，那么前端可以立即从 Cookie 中删除该 Token，这样能尽量确保 Token 的安全性和时效性。Token 存储在 Redis 中，也不会因为用户在参与活动时频繁的切换页面请求，而对服务造成太大的压力。另外，Token 还可以有更多的用处：标识参与活动用户的有效性。敏感数据对称加密时生成动态密钥。API 接口的数字签名。敏感数据加密通信时，传递的敏感数据可以使用常见的对称加密算法进行加密。为了提升加密的安全等级，加密时的密钥可以动态生成，前端和风控服务端约定好动态密钥的生成规则即可。加密的算法和密钥也要确保不被暴露。通过对敏感数据加密，攻击者在不了解敏感数据内容的前提下就更别提模拟构造请求内容了。挑战三：化解纸老虎的尴尬有经验的 Web 开发者看到这里，可能已经开始质疑了：在透明的前端环境中折腾安全不是白折腾吗？这就好比费了很大的劲却只是造了一个“纸老虎”，质疑是有道理的，但是且慢，通过一些安全机制的加强是可以让“纸老虎”尽可能的逼真。本文一再提及的 Web 环境的透明性，是因为在实际的生产环境中的问题：前端的代码在压缩后，通过使用浏览器自带的格式化工具和断点工具，仍然具备一定的可读性，花点时间仍然可以理解代码的逻辑，这就给攻击者提供了大好的代码反编译机会。如果要化解“纸老虎”的尴尬，就要对前端的代码进行混淆。前端代码混淆前端的 JS 代码压缩工具基本都是对变量、函数名称等进行缩短，压缩对于混淆的作用是比较弱。除了对代码进行压缩，还需要进行专门的混淆。对代码进行混淆可以降低可读性，混淆工具有条件的话最好自研，开源的工具要慎用。或者基于 Uglify.js 来自定义混淆的规则，混淆程度越高可读性就越低。代码混淆也需要把握一个度，太复杂的混淆可能会让代码无法运行，也有可能会影响本身的执行效率。同时还需要兼顾混淆后的代码体积，混淆前后的体积不能有太大的差距，合理的混淆程度很重要。断点工具的防范会更麻烦些。在使用断点工具时通常都会导致代码延迟执行，而正常的业务逻辑都会立即执行，这是一个可以利用的点，可以考虑在代码执行间隔上来防范断点工具。通过代码混淆和对代码进行特殊的处理，可以让格式化工具和断点工具变得没有用武之地。唯一有些小遗憾，就是处理后的代码也不能正常使用 Source Map 的功能了。有了代码混淆，反编译的成本会非常高，这样“纸老虎”已经变得很逼真了。技术方案设计在讲解完如何解决关键的技术挑战后，就可以把相应的方案串起来，然后设计成一套可以实施的技术方案了。相对理想的技术方案架构图如下：下面会按步骤来讲解技术方案的处理流程：Step 0 基础风控拦截基础风控拦截是上面提到的频次、名单等的拦截限制，在 Nginx 层就能直接实施拦截。如果发现是恶意请求，直接将请求过滤返回 403，这是初步的拦截，用户在请求 Web 页面的时候就开始起作用了。Step 1 风控服务端生成 Token 后传给前端Step 0 可能还没进入到活动 Web 页面，进入活动 Web 页面后才真正开始人机识别验证的流程，前端会先开始获取 Token。Step 2 前端生成敏感数据敏感数据应包含用户交互行为数据、设备环境数据、活动业务逻辑数据以及无效数据。Step 3 使用 HTTPS 的签名接口发送数据Token 可以作为 Authorization 的值添加到 Header 中，数据接口的签名可以有效防止 CSRF 的攻击。Step 4 数据接口的校验风控服务端收到请求后，会先验证数据接口签名中的 Token 是否有效。验证完 Token，才会对敏感数据进行解密。数据解密成功，再进一步对人机识别的数据合法性进行校验。Step 5 业务逻辑的处理前面的步骤为了做人机识别验证，这些验证不涉及到业务逻辑。在所有这些验证都通过后，后端业务服务才会开始处理实际的活动业务逻辑。处理完活动业务逻辑，最终才会返回用户参与活动的结果。总结为了提升活动 Web 页面的安全性，使用了各种各样的技术方案，我们将这些技术方案组合起来才能发挥安全防范的作用，如果其中某个环节处理不当，都可能会被当作漏洞来利用，从而导致整个验证方案被攻破。为了验证技术方案的有效性，可以持续观察活动 API 接口的请求成功率。从请求成功率的数据中进一步分析“误伤”和“拦截”的数据，以进一步确定是否要对方案进行调优。通过上述的人机识别验证的组合方案，可以大幅提升活动 Web 页面的安全性。在活动 Web 页面应作为一个标准化的安全防范流程，除了美团，像淘宝和天猫也有类似的流程。由于活动运营的环节和方法多且复杂，仅仅提升了 Web 页面也不敢保证就是铁板一块，安全需要关注的环节还很多，安全攻防是一项长期的“拉锯升级战”，安全防范措施也需要持续地优化升级。参考资料https://www.google.com/recaptcha/intro/v3.htmlhttps://segmentfault.com/a/1190000006226236https://www.freebuf.com/articles/web/102269.html作者简介益国，美团点评 Web 前端开发工程师。2015年加入美团，曾先后负责过风控前端SDK和活动运营平台的研发，现负责大数据平台的研发工作。 ...

从沙箱或孵化状态毕业，或者作为一个新项目加入作为一个毕业项目，项目必须符合孵化阶段标准以及：有来自至少两个机构的提交者。已经实现并维护了核心基础结构计划（CII）的最佳实践徽章。采用CNCF行为准则。明确定义项目治理和提交者流程。这最好在GOVERNANCE.md文件中进行，并引用OWNERS.md文件显示当前和荣誉提交者。至少在主要仓库提供项目采用者的公开列表（例如，ADOPTERS.md文件或项目网站上的徽标）。获得TOC的绝对多数选票进入毕业阶段。如果项目能够表现出足够的成熟度，项目可以尝试直接从沙箱移动到毕业。项目可以无限期地保持在孵化状态，但通常预计在两年内毕业。这里介绍一下其中的核心基础结构计划（CII）的最佳实践徽章。CII最佳实践徽章计划Linux基金会（LF）的核心基础设施计划（Core Infrastructure Initiative，CII）最佳实践徽章是Free/Libre和开源软件（FLOSS）项目用于表明它们遵循最佳实践的一种方式。项目可以自愿进行自我认证，通过使用此Web应用程序来解释他们如何遵循每种最佳实践。CII最佳实践徽章的灵感来自GitHub项目众多可获得的徽章系统。徽章的使用者可以快速评估哪些FLOSS项目遵循最佳实践，因而更有可能生成更高质量的安全软件。最佳实践标准“合格”（“passing”）级别摘要这是合格标准的摘要，有关详细信息，请参阅完整的标准列表：有一个稳定的网站，说名：它做什么如何获得如何提供反馈如何贡献和首选风格明确指定FLOSS许可证项目网站支持HTTPS文档记录如何安装和运行（安全地）以及任何API有分布式公共版本控制系统，包括版本之间的变化：使用语义版本控制格式为每个发布提供唯一版本提供每个发布的更改摘要，识别任何已修复的漏洞允许提交、存档和跟踪错误报告：确认/响应错误和增强请求，而不是忽略它们有安全的、记录在案的流程来报告漏洞在14天内回复，并在60天内修复漏洞，如果漏洞是公开的使用标准的开源工具作有效的构建启用（并修复）编译器警告和类似lint的检查执行其他静态分析工具并修复可被攻击利用的问题拥有涵盖大部分代码/功能的自动化测试套件，并正式要求对新代码进行新的测试自动运行所有更改的测试，并应用动态检查：执行内存/行为分析工具（sanitizers/Valgrind等）执行模糊测试器（fuzzer）或Web扫描程序有开发者了解安全软件和常见漏洞错误如果使用加密：使用公共协议/算法不要重新实现标准功能使用开源加密技术使用保持安全的密钥长度不要使用已知损坏或已知弱算法使用具有前向保密性的算法使用密钥拉伸算法，使用迭代、加盐和哈希值存储任何密码使用加密随机数源Kubernetes的最佳实践徽章https://bestpractices.coreinf…Prometheus的最佳实践徽章https://bestpractices.coreinf…Envoy的最佳实践徽章https://bestpractices.coreinf…2019年KubeCon + CloudNativeCon中国论坛提案征集（CFP）现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集（CFP）现已开放在中国开源峰会上，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括 Linux、容器、云技术、网络、微服务等；并获得如何在开源社区中导向和引领的信息。大会日期：提案征集截止日期：太平洋标准时间 2 月 15 日，星期五，晚上 11:59提案征集通知日期：2019 年 4 月 1 日会议日程通告日期：2019 年 4 月 3 日幻灯片提交截止日期：6 月 17 日，星期一会议活动举办日期：2019 年 6 月 24 至 26 日2019年KubeCon + CloudNativeCon + Open Source Summit China赞助方案出炉啦

背景近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？需求描述对于HIDS产品，我们安全部门的产品经理提出了以下需求：满足50W-100W服务器量级的IDC规模。部署在高并发服务器生产环境，要求Agent低性能低损耗。广泛的部署兼容性。偏向应用层和用户态入侵检测（可以和内核态检测部分解耦）。针对利用主机Agent排查漏洞的最急需场景提供基本的能力，可以实现海量环境下快速查找系统漏洞。Agent跟Server的配置下发通道安全。配置信息读取写入需要鉴权。配置变更历史记录。Agent插件具备自更新功能。分析需求首先，服务器业务进程优先级高，HIDS Agent进程自己可以终止，但不能影响宿主机的主要业务，这是第一要点，那么业务需要具备熔断功能，并具备自我恢复能力。其次，进程保活、维持心跳、实时获取新指令能力，百万台Agent的全量控制时间一定要短。举个极端的例子，当Agent出现紧急情况，需要全量停止时，那么全量停止的命令下发，需要在1-2分钟内完成，甚至30秒、20秒内完成。这些将会是很大的技术挑战。还有对配置动态更新，日志级别控制，细分精确控制到每个Agent上的每个HIDS子进程，能自由地控制每个进程的启停，每个Agent的参数，也能精确的感知每台Agent的上线、下线情况。同时，Agent本身是安全Agent，安全的因素也要考虑进去，包括通信通道的安全性，配置管理的安全性等等。最后，服务端也要有一致性保障、可用性保障，对于大量Agent的管理，必须能实现任务分摊，并行处理任务，且保证数据的一致性。考虑到公司规模不断地扩大，业务不断地增多，特别是美团和大众点评合并后，面对的各种操作系统问题，产品还要具备良好的兼容性、可维护性等。总结下来，产品架构要符合以下特性：集群高可用。分布式，去中心化。配置一致性，配置多版本可追溯。分治与汇总。兼容部署各种Linux 服务器，只维护一个版本。节省资源，占用较少的CPU、内存。精确的熔断限流。服务器数量规模达到百万级的集群负载能力。技术难点在列出产品需要实现的功能点、技术点后，再来分析下遇到的技术挑战，包括不限于以下几点：资源限制，较小的CPU、内存。五十万甚至一百万台服务器的Agent处理控制问题。量级大了后，集群控制带来的控制效率，响应延迟，数据一致性问题。量级大了后，数据传输对整个服务器内网带来的流量冲击问题。量级大了后，运行环境更复杂，Agent异常表现的感知问题。量级大了后，业务日志、程序运行日志的传输、存储问题，被监控业务访问量突增带来监控数据联动突增，对内网带宽，存储集群的爆发压力问题。我们可以看到，技术难点几乎都是服务器到达一定量级带来的，对于大量的服务，集群分布式是业界常见的解决方案。架构设计与技术选型对于管理Agent的服务端来说，要实现高可用、容灾设计，那么一定要做多机房部署，就一定会遇到数据一致性问题。那么数据的存储，就要考虑分布式存储组件。 分布式数据存储中，存在一个定理叫CAP定理：CAP的解释关于CAP定理，分为以下三点：一致性（Consistency）：分布式数据库的数据保持一致。可用性（Availability）：任何一个节点宕机，其他节点可以继续对外提供服务。分区容错性（网络分区）Partition Tolerance：一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以添加一台机器，然后从其他正常的机器把备份的数据同步过来。根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP定理的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了Consistency。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了Availability。除非两个节点可以互相通信，才能既保证Consistency又保证Availability，这又会导致丧失Partition Tolerance。参见：CAP TheoremCAP的选择为了容灾上设计，集群节点的部署，会选择的异地多机房，所以 「Partition tolerance」是不可能避免的。那么可选的是 AP 与 CP。在HIDS集群的场景里，各个Agent对集群持续可用性没有非常强的要求，在短暂时间内，是可以出现异常，出现无法通讯的情况。但最终状态必须要一致，不能存在集群下发关停指令，而出现个别Agent不听从集群控制的情况出现。所以，我们需要一个满足 CP 的产品。满足CP的产品选择在开源社区中，比较出名的几款满足CP的产品，比如etcd、ZooKeeper、Consul等。我们需要根据几款产品的特点，根据我们需求来选择符合我们需求的产品。插一句，网上很多人说Consul是AP产品，这是个错误的描述。既然Consul支持分布式部署，那么一定会出现「网络分区」的问题， 那么一定要支持「Partition tolerance」。另外，在consul的官网上自己也提到了这点 Consul uses a CP architecture, favoring consistency over availability. Consul is opinionated in its usage while Serf is a more flexible and general purpose tool. In CAP terms, Consul uses a CP architecture, favoring consistency over availability. Serf is an AP system and sacrifices consistency for availability. This means Consul cannot operate if the central servers cannot form a quorum while Serf will continue to function under almost all circumstances.etcd、ZooKeeper、Consul对比 借用etcd官网上etcd与ZooKeeper和Consul的比较图。在我们HIDS Agent的需求中，除了基本的服务发现 、配置同步 、配置多版本控制 、变更通知等基本需求外，我们还有基于产品安全性上的考虑，比如传输通道加密、用户权限控制、角色管理、基于Key的权限设定等，这点 etcd比较符合我们要求。很多大型公司都在使用，比如Kubernetes、AWS、OpenStack、Azure、Google Cloud、Huawei Cloud等，并且etcd的社区支持非常好。基于这几点因素，我们选择etcd作为HIDS的分布式集群管理。选择etcd对于etcd在项目中的应用，我们分别使用不同的API接口实现对应的业务需求，按照业务划分如下：Watch机制来实现配置变更下发，任务下发的实时获取机制。脑裂问题在etcd中不存在，etcd集群的选举，只有投票达到 N/2+1 以上，才会选做Leader，来保证数据一致性。另外一个网络分区的Member节点将无主。语言亲和性，也是Golang开发的，Client SDK库稳定可用。Key存储的数据结构支持范围性的Key操作。User、Role权限设定不同读写权限，来控制Key操作，避免其他客户端修改其他Key的信息。TLS来保证通道信息传递安全。Txn分布式事务API配合Compare API来确定主机上线的Key唯一性。Lease租约机制，过期Key释放，更好的感知主机下线信息。etcd底层Key的存储为BTree结构，查找时间复杂度为O（㏒n），百万级甚至千万级Key的查找耗时区别不大。etcd Key的设计前缀按角色设定：Server配置下发使用 /hids/server/config/{hostname}/master。Agent注册上线使用 /hids/agent/master/{hostname}。Plugin配置获取使用 /hids/agent/config/{hostname}/plugin/ID/conf_name。Server Watch /hids/server/config/{hostname}/master，实现Agent主机上线的瞬间感知。Agent Watch /hids/server/config/{hostname}/来获取配置变更，任务下发。Agent注册的Key带有Lease Id，并启用keepalive，下线后瞬间感知。 （异常下线，会有1/3的keepalive时间延迟）关于Key的权限，根据不同前缀，设定不同Role权限。赋值给不同的User，来实现对Key的权限控制。etcd集群管理在etcd节点容灾考虑，考虑DNS故障时，节点会选择部署在多个城市，多个机房，以我们服务器机房选择来看，在大部分机房都有一个节点，综合承载需求，我们选择了N台服务器部署在个别重要机房，来满足负载、容灾需求。但对于etcd这种分布式一致性强的组件来说，每个写操作都需要N/2-1的节点确认变更，才会将写请求写入数据库中，再同步到各个节点，那么意味着节点越多，需要确认的网络请求越多，耗时越多，反而会影响集群节点性能。这点，我们后续将提升单个服务器性能，以及牺牲部分容灾性来提升集群处理速度。客户端填写的IP列表，包含域名、IP。IP用来规避DNS故障，域名用来做Member节点更新。最好不要使用Discover方案，避免对内网DNS服务器产生较大压力。同时，在配置etcd节点的地址时，也要考虑到内网DNS故障的场景，地址填写会混合IP、域名两种形式。IP的地址，便于规避内网DNS故障。域名形式，便于做个别节点更替或扩容。我们在设计产品架构时，为了安全性，开启了TLS证书认证，当节点变更时，证书的生成也同样要考虑到上面两种方案的影响，证书里需要包含固定IP，以及DNS域名范围的两种格式。etcd Cluster节点扩容节点扩容，官方手册上也有完整的方案，etcd的Client里实现了健康检测与故障迁移，能自动的迁移到节点IP列表中的其他可用IP。也能定时更新etcd Node List，对于etcd Cluster的集群节点变更来说，不存在问题。需要我们注意的是，TLS证书的兼容。分布式HIDS集群架构图集群核心组件高可用，所有Agent、Server都依赖集群，都可以无缝扩展，且不影响整个集群的稳定性。即使Server全部宕机，也不影响所有Agent的继续工作。在以后Server版本升级时，Agent不会中断，也不会带来雪崩式的影响。etcd集群可以做到单节点升级，一直到整个集群升级，各个组件全都解耦。编程语言选择考虑到公司服务器量大，业务复杂，需求环境多变，操作系统可能包括各种Linux以及Windows等。为了保证系统的兼容性，我们选择了Golang作为开发语言，它具备以下特点：可以静态编译，直接通过syscall来运行，不依赖libc，兼容性高，可以在所有Linux上执行，部署便捷。静态编译语言，能将简单的错误在编译前就发现。具备良好的GC机制，占用系统资源少，开发成本低。容器化的很多产品都是Golang编写，比如Kubernetes、Docker等。etcd项目也是Golang编写，类库、测试用例可以直接用，SDK支持快速。良好的CSP并发模型支持，高效的协程调度机制。产品架构大方向HIDS产品研发完成后，部署的服务都运行着各种业务的服务器，业务的重要性排在第一，我们产品的功能排在后面。为此，确定了几个产品的大方向：高可用，数据一致，可横向扩展。容灾性好，能应对机房级的网络故障。兼容性好，只维护一个版本的Agent。依赖低，不依赖任何动态链接库。侵入性低，不做Hook，不做系统类库更改。熔断降级可靠，宁可自己挂掉，也不影响业务 。产品实现篇幅限制，仅讨论框架设计、熔断限流、监控告警、自我恢复以及产品实现上的主进程与进程监控。框架设计如上图，在框架的设计上，封装常用类库，抽象化定义Interface，剥离etcd Client，全局化Logger，抽象化App的启动、退出方法。使得各模块（以下简称App）只需要实现自己的业务即可，可以方便快捷的进行逻辑编写，无需关心底层实现、配置来源、重试次数、熔断方案等等。沙箱隔离考虑到子进程不能无限的增长下去，那么必然有一个进程包含多个模块的功能，各App之间既能使用公用底层组件（Logger、etcd Client等），又能让彼此之间互不影响，这里进行了沙箱化处理，各个属性对象仅在各App的sandbox里生效。同样能实现了App进程的性能熔断，停止所有的业务逻辑功能，但又能具有基本的自我恢复功能。IConfig对各App的配置抽象化处理，实现IConfig的共有方法接口，用于对配置的函数调用，比如Check的检测方法，检测配置合法性，检测配置的最大值、最小值范围，规避使用人员配置不在合理范围内的情况，从而避免带来的风险。框架底层用Reflect来处理JSON配置，解析读取填写的配置项，跟Config对象对比，填充到对应Struct的属性上，允许JSON配置里只填写变化的配置，没填写的配置项，则使用Config对应Struct的默认配置。便于灵活处理配置信息。type IConfig interface { Check() error //检测配置合法性}func ConfigLoad(confByte []byte, config IConfig) (IConfig, error) {…//反射生成临时的IConfig var confTmp IConfig confTmp = reflect.New(reflect.ValueOf(config).Elem().Type()).Interface().(IConfig)… //反射 confTmp 的属性 confTmpReflect := reflect.TypeOf(confTmp).Elem() confTmpReflectV := reflect.ValueOf(confTmp).Elem() //反射config IConfig configReflect := reflect.TypeOf(config).Elem() configReflectV := reflect.ValueOf(config).Elem()… for i = 0; i < num; i++ { //遍历处理每个Field envStructTmp := configReflect.Field(i) //根据配置中的项，来覆盖默认值 if envStructTmp.Type == confStructTmp.Type { configReflectV.FieldByName(envStructTmp.Name).Set(confTmpReflectV.Field(i))Timer、Clock调度在业务数据产生时，很多地方需要记录时间，时间的获取也会产生很多系统调用。尤其是在每秒钟产生成千上万个事件，这些事件都需要调用获取时间接口，进行clock_gettime等系统调用，会大大增加系统CPU负载。 而很多事件产生时间的准确性要求不高，精确到秒，或者几百个毫秒即可，那么框架里实现了一个颗粒度符合需求的（比如100ms、200ms、或者1s等）间隔时间更新的时钟，即满足事件对时间的需求，又减少了系统调用。同样，在有些Ticker场景中，Ticker的间隔颗粒要求不高时，也可以合并成一个Ticker，减少对CPU时钟的调用。Catcher在多协程场景下，会用到很多协程来处理程序，对于个别协程的panic错误，上层线程要有一个良好的捕获机制，能将协程错误抛出去，并能恢复运行，不要让进程崩溃退出，提高程序的稳定性。抽象接口框架底层抽象化封装Sandbox的Init、Run、Shutdown接口，规范各App的对外接口，让App的初始化、运行、停止等操作都标准化。App的模块业务逻辑，不需要关注PID文件管理，不关注与集群通讯，不关心与父进程通讯等通用操作，只需要实现自己的业务逻辑即可。App与框架的统一控制，采用Context包以及Sync.Cond等条件锁作为同步控制条件，来同步App与框架的生命周期，同步多协程之间同步，并实现App的安全退出，保证数据不丢失。限流网络IO限制数据上报速度。队列存储数据任务列表。大于队列长度数据丢弃。丢弃数据总数计数。计数信息作为心跳状态数据上报到日志中心，用于数据对账。磁盘IO程序运行日志，对日志级别划分，参考 /usr/include/sys/syslog.h：LOG_EMERGLOG_ALERTLOG_CRITLOG_ERRLOG_WARNINGLOG_NOTICELOG_INFOLOG_DEBUG在代码编写时，根据需求选用级别。级别越低日志量越大，重要程度越低，越不需要发送至日志中心，写入本地磁盘。那么在异常情况排查时，方便参考。日志文件大小控制，分2个文件，每个文件不超过固定大小，比如20M、50M等。并且，对两个文件进行来回写，避免日志写满磁盘的情况。IRetry为了加强Agent的鲁棒性，不能因为某些RPC动作失败后导致整体功能不可用，一般会有重试功能。Agent跟etcd Cluster也是TCP长连接（HTTP2），当节点重启更换或网络卡顿等异常时，Agent会重连，那么重连的频率控制，不能是死循环般的重试。假设服务器内网交换机因内网流量较大产生抖动，触发了Agent重连机制，不断的重连又加重了交换机的负担，造成雪崩效应，这种设计必须要避免。 在每次重试后，需要做一定的回退机制，常见的指数级回退，比如如下设计，在规避雪崩场景下，又能保障Agent的鲁棒性，设定最大重试间隔，也避免了Agent失控的问题。//网络库重试Interfacetype INetRetry interface { //开始连接函数 Connect() error String() string //获取最大重试次数 GetMaxRetry() uint …}// 底层实现func (this *Context) Retry(netRetry INetRetry) error {… maxRetries = netRetry.GetMaxRetry() //最大重试次数 hashMod = netRetry.GetHashMod()for { if c.shutting { return errors.New(“c.shutting is true…”) } if maxRetries > 0 && retries >= maxRetries { c.logger.Debug(“Abandoning %s after %d retries.”, netRetry.String(), retries) return errors.New(“超过最大重试次数”) }… if e := netRetry.Connect(); e != nil { delay = 1 << retries if delay == 0 { delay = 1 } delay = delay * hashInterval… c.logger.Emerg(“Trying %s after %d seconds , retries:%d,error:%v”, netRetry.String(), delay, retries, e) time.Sleep(time.Second * time.Duration(delay)) }…}事件拆分百万台IDC规模的Agent部署，在任务执行、集群通讯或对宿主机产生资源影响时，务必要错峰进行，根据每台主机的唯一特征取模，拆分执行，避免造成雪崩效应。监控告警古时候，行军打仗时，提倡「兵马未动，粮草先行」，无疑是冷兵器时代决定胜负走向的重要因素。做产品也是，尤其是大型产品，要对自己运行状况有详细的掌控，做好监控告警，才能确保产品的成功。对于etcd集群的监控，组件本身提供了Metrics数据输出接口，官方推荐了Prometheus来采集数据，使用Grafana来做聚合计算、图标绘制，我们做了Alert的接口开发，对接了公司的告警系统，实现IM、短信、电话告警。Agent数量感知，依赖Watch数字，实时准确感知。如下图，来自产品刚开始灰度时的某一时刻截图，Active Streams（即etcd Watch的Key数量）即为对应Agent数量，每次灰度的产品数量。因为该操作，是Agent直接与集群通讯，并且每个Agent只Watch一个Key。且集群数据具备唯一性、一致性，远比心跳日志的处理要准确的多。etcd集群Members之间健康状况监控用于监控管理etcd集群的状况，包括Member节点之间数据同步，Leader选举次数，投票发起次数，各节点的内存申请状况，GC情况等，对集群的健康状况做全面掌控。程序运行状态监控告警全量监控Aagent的资源占用情况，统计每天使用最大CPU内存的主机Agent，确定问题的影响范围，及时做策略调整，避免影响到业务服务的运行。并在后续版本上逐步做调整优化。百万台服务器，日志告警量非常大，这个级别的告警信息的筛选、聚合是必不可少的。减少无用告警，让研发运维人员疲于奔命，也避免无用告警导致研发人员放松了警惕，前期忽略个例告警，先解决主要矛盾。告警信息分级，告警信息细分ID。根据告警级别过滤，根据告警ID聚合告警，来发现同类型错误。根据告警信息的所在机房、项目组、产品线等维度来聚合告警，来发现同类型错误。数据采集告警单机数据数据大小、总量的历史数据对比告警。按机房、项目组、产品线等维度的大小、总量等维度的历史数据对比告警。数据采集大小、总量的对账功能，判断经过一系列处理流程的日志是否丢失的监控告警。熔断针对单机Agent使用资源大小的阈值熔断，CPU使用率，连续N次触发大于等于5%，则进行保护性熔断，退出所有业务逻辑，以保护主机的业务程序优先。Master进程进入空闲状态，等待第二次时间Ticker到来，决定是否恢复运行。各个App基于业务层面的监控熔断策略。灰度管理在前面的配置管理中的etcd Key设计里，已经细分到每个主机（即每个Agent）一个Key。那么，服务端的管理，只要区分该主机所属机房、环境、群组、产品线即可，那么，我们的管理Agent的颗粒度可以精确到每个主机，也就是支持任意纬度的灰度发布管理与命令下发。数据上报通道组件名为 log_agent ，是公司内部统一日志上报组件，会部署在每一台VM、Docker上。主机上所有业务均可将日志发送至该组件。 log_agent会将日志上报到Kafka集群中，经过处理后，落入Hive集群中。（细节不在本篇讨论范围）主进程主进程实现跟etcd集群通信，管理整个Agent的配置下发与命令下发；管理各个子模块的启动与停止；管理各个子模块的CPU、内存占用情况，对资源超标进行进行熔断处理，让出资源，保证业务进程的运行。插件化管理其他模块，多进程模式，便于提高产品灵活性，可更简便的更新启动子模块，不会因为个别模块插件的功能、BUG导致整个Agent崩溃。进程监控方案选择我们在研发这产品时，做了很多关于linux进程创建监控的调研，不限于安全产品，大约有下面三种技术方案：方案Docker兼容性开发难度数据准确性系统侵入性cn_proc不支持Docker一般存在内核拿到的PID，在/proc/下丢失的情况无Audit不支持Docker一般同cn_proc弱，但依赖Auditd Hook定制高精确强对于公司的所有服务器来说，几十万台都是已经在运行的服务器，新上的任何产品，都尽量避免对服务器有影响，更何况是所有服务器都要部署的Agent。 意味着我们在选择系统侵入性来说，优先选择最小侵入性的方案。对于Netlink的方案原理，可以参考这张图（来自:kernel-proc-connector-and-containers）系统侵入性比较cn_proc跟Autid在「系统侵入性」和「数据准确性」来说，cn_proc方案更好，而且使用CPU、内存等资源情况，更可控。Hook的方案，对系统侵入性太高了，尤其是这种最底层做HOOK syscall的做法，万一测试不充分，在特定环境下，有一定的概率会出现Bug，而在百万IDC的规模下，这将成为大面积事件，可能会造成重大事故。兼容性上比较cn_proc不兼容Docker，这个可以在宿主机上部署来解决。Hook的方案，需要针对每种Linux的发行版做定制，维护成本较高，且不符合长远目标（收购外部公司时遇到各式各样操作系统问题）数据准确性比较在大量PID创建的场景，比如Docker的宿主机上，内核返回PID时，因为PID返回非常多非常快，很多进程启动后，立刻消失了，另外一个线程都还没去读取/proc/，进程都丢失了，场景常出现在Bash执行某些命令。最终，我们选择Linux Kernel Netlink接口的cn_proc指令作为我们进程监控方案，借助对Bash命令的收集，作为该方案的补充。当然，仍然存在丢数据的情况，但我们为了系统稳定性，产品侵入性低等业务需求，牺牲了一些安全性上的保障。 对于Docker的场景，采用宿主机运行，捕获数据，关联到Docker容器，上报到日志中心的做法来实现。遇到的问题内核Netlink发送数据卡住内核返回数据太快，用户态ParseNetlinkMessage解析读取太慢，导致用户态网络Buff占满，内核不再发送数据给用户态，进程空闲。对于这个问题，我们在用户态做了队列控制，确保解析时间的问题不会影响到内核发送数据。对于队列的长度，我们做了定值限制，生产速度大于消费速度的话，可以丢弃一些数据，来保证业务正常运行，并且来控制进程的内存增长问题。疑似“内存泄露”问题在一台Docker的宿主机上，运行了50个Docker实例，每个Docker都运行了复杂的业务场景，频繁的创建进程，在最初的产品实现上，启动时大约10M内存占用，一天后达到200M的情况。经过我们Debug分析发现，在ParseNetlinkMessage处理内核发出的消息时，PID频繁创建带来内存频繁申请，对象频繁实例化，占用大量内存。同时，在Golang GC时，扫描、清理动作带来大量CPU消耗。在代码中，发现对于linux/connector.h里的struct cb_msg、linux/cn_proc.h里的struct proc_event结构体频繁创建，带来内存申请等问题，以及Golang的GC特性，内存申请后，不会在GC时立刻归还操作系统，而是在后台任务里，逐渐的归还到操作系统，见：debug.FreeOSMemoryFreeOSMemory forces a garbage collection followed by an attempt to return as much memory to the operating system as possible. (Even if this is not called, the runtime gradually returns memory to the operating system in a background task.)但在这个业务场景里，大量频繁的创建PID，频繁的申请内存，创建对象，那么申请速度远远大于释放速度，自然内存就一直堆积。从文档中可以看出，FreeOSMemory的方法可以将内存归还给操作系统，但我们并没有采用这种方案，因为它治标不治本，没法解决内存频繁申请频繁创建的问题，也不能降低CPU使用率。为了解决这个问题，我们采用了sync.Pool的内置对象池方式，来复用回收对象，避免对象频繁创建，减少内存占用情况，在针对几个频繁创建的对象做对象池化后，同样的测试环境，内存稳定控制在15M左右。大量对象的复用，也减少了对象的数量，同样的，在Golang GC运行时，也减少了对象的扫描数量、回收数量，降低了CPU使用率。项目进展在产品的研发过程中，也遇到了一些问题，比如：etcd Client Lease Keepalive的Bug。Agent进程资源限制的Cgroup触发几次内核Bug。Docker宿主机上瞬时大量进程创建的性能问题。网络监控模块在处理Nginx反向代理时，动辄几十万TCP链接的网络数据获取压力。个别进程打开了10W以上的fd。方法一定比困难多，但方法不是拍脑袋想出来的，一定要深入探索问题的根本原因，找到系统性的修复方法，具备高可用、高性能、监控告警、熔断限流等功能后，对于出现的问题，能够提前发现，将故障影响最小化，提前做处理。在应对产品运营过程中遇到的各种问题时，逢山开路，遇水搭桥，都可以从容的应对。经过我们一年的努力，已经部署了除了个别特殊业务线之外的其他所有服务器，数量达几十万台，产品稳定运行。在数据完整性、准确性上，还有待提高，在精细化运营上，需要多做改进。本篇更多的是研发角度上软件架构上的设计，关于安全事件分析、数据建模、运营策略等方面的经验和技巧，未来将会由其他同学进行分享，敬请期待。总结我们在研发这款产品过程中，也看到了网上开源了几款同类产品，也了解了他们的设计思路，发现很多产品都是把主要方向放在了单个模块的实现上，而忽略了产品架构上的重要性。比如，有的产品使用了syscall hook这种侵入性高的方案来保障数据完整性，使得对系统侵入性非常高，Hook代码的稳定性，也严重影响了操作系统内核的稳定。同时，Hook代码也缺少了监控熔断的措施，在几十万服务器规模的场景下部署，潜在的风险可能让安全部门无法接受，甚至是致命的。这种设计，可能在服务器量级小时，对于出现的问题多花点时间也能逐个进行维护，但应对几十万甚至上百万台服务器时，对维护成本、稳定性、监控熔断等都是很大的技术挑战。同时，在研发上，也很难实现产品的快速迭代，而这种方式带来的影响，几乎都会导致内核宕机之类致命问题。这种事故，使用服务器的业务方很难进行接受，势必会影响产品的研发速度、推进速度；影响同事（SRE运维等）对产品的信心，进而对后续产品的推进带来很大的阻力。以上是笔者站在研发角度，从可用性、可靠性、可控性、监控熔断等角度做的架构设计与框架设计，分享的产品研发思路。笔者认为大规模的服务器安全防护产品，首先需要考虑的是架构的稳定性、监控告警的实时性、熔断限流的准确性等因素，其次再考虑安全数据的完整性、检测方案的可靠性、检测模型的精确性等因素。九层之台，起于累土。只有打好基础，才能运筹帷幄，决胜千里之外。参考资料https://en.wikipedia.org/wiki…https://www.consul.io/intro/v...https://golang.org/src/runtim...https://www.ibm.com/developer...https://www.kernel.org/doc/https://coreos.com/etcd/docs/…作者简介陈驰，美团点评技术专家，2017年加入美团，十年以上互联网产品研发经验，专注于分布式系统架构设计，目前主要从事安全防御产品研发工作。关于美团安全美团安全部的大多数核心开发人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。招聘信息美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们，欢迎简历请发至邮箱zhaoyan17@meituan.com具体职位信息可参考这里：https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw美团安全应急响应中心MTSRC主页：security.meituan.com ...

说明初衷：本文档用于记录所遇到的网站安全问题，并分类汇总，方便后期遇到类似问题，能够快速找到解决方案，提高效率，让程序员有更多的时间去把妹，LOL…记录规范：标题必须清晰明了，方便用户快速查找，拒绝标题党；问题放到正确的分类中；记录问题的时候先阐述问题，再列出解决方法，尽量做到有图有真相；如果有对应的资料，可以附上链接；记录问题提交人，方便追踪ApacheCookie缺少HttpOnly、Secure标识漏洞提示描述httponly是微软对cookie做的扩展，这个主要是解决用户的cookie可能被盗用的问题。大家都知道，当我们去邮箱或者论坛登陆后，服务器会写一些cookie到我们的浏览器，当下次再访问其他页面时，由于浏览器回自动传递cookie，这样就实现了一次登陆就可以看到所有需要登陆后才能看到的内容。也就是说，实质上，所有的登陆状态这些都是建立在cookie上的！假设我们登陆后的cookie被人获得，那就会有暴露个人信息的危险！当然，想想，其他人怎么可以获得客户的cookie？那必然是有不怀好意的人的程序在浏览器里运行！如果是现在满天飞的流氓软件，那没有办法，httponly也不是用来解决这种情况的，它是用来解决浏览器里javascript访问cookie的问题。试想，一个flash程序在你的浏览器里运行，就可以获得你的cookie的！修复方案一、修改php配置文件php.ini注意：YNCMS勿改此项，其程序内部提供支持，按照第二种方案修改即可session.cookie_secure = 1session.cookie_httponly = 1二、修改网站cookie配置文件，以YNCMS为例，修改/Application/Home/Conf/config.php，添加配置参数’COOKIE_SECURE’ => true, // cookie 启用安全传输’COOKIE_HTTPONLY’ => true, // httponly设置参考资料： http://www.jb51.net/article/1...cgi-bin目录问题暴力解决办法：注释掉对应信息apache icons目录问题我们如果使用了apache服务器，当我访问http://xxx.xxx.xxx/icons/时会自动显示这个目录下的所以文件列表，这行造成网站目录信息的泄露对我们的网站安全造成威胁，在 关闭apache自动目录列表功能的三种方法 这篇文章中的三种方法都不能禁止自动目录列表，你如果使用网站安全监测，会提醒你发现目录启用了自动目录列表功能，所以我们必须禁止它，经过测试，按如下步骤可以禁止：打开目录apache/conf/extra/下的文件httpd-autoindex.conf（位置可能有差异）找到Alias /icons/ “/xampp/apache/icons/” <Directory “/xampp/apache/icons”> Options Indexes MultiViews AllowOverride None Require all granted</Directory>去掉Indexes改成<Directory “/xampp/apache/icons”> Options MultiViews AllowOverride None Require all granted</Directory>重启apache服务器！暴力解决办法就是注释掉或者直接删除icons目录启用了OPTIONS方法在网站根目录目录下创建.htaccess文件，内容如下，如果您已有其他规则，请添加到第一条规则RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(OPTIONS)RewriteRule .* - [F]使用Apache的重写规则来禁用Options方法和Trace方法在Apache配置文件httpd-conf中【vhosts-conf】添加以下代码：单独禁用Trace方法：RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK）RewriteRule .* - [F]单独禁用Options方法：RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(OPTIONS)RewriteRule .* - [F]同时禁用Trace方法和Options方法RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)RewriteRule .* - [F]<VirtualHost :80> DocumentRoot “D:\wwwroot” ServerName www.abc.com ServerAlias abc.com <Directory “D:\wwwroot”> Options FollowSymLinks ExecCGI AllowOverride All Order allow,deny Allow from all Require all granted RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS) RewriteRule . - [F] </Directory></VirtualHost>启用了TRACE Method同启用了OPTIONS方法处理方法相同RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)或者在httpd.conf中添加配置：TraceEnable offX-Frame-Options头未设置在httpd.conf里面增加Header always append X-Frame-Options SAMEORIGIN关闭目录浏览权限描述<Directory “/var/www/html”> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>options中Indexes表示当网页不存在的时候允许索引显示目录中的文件解决将要设置的目录对应配置参数下的Indexes删除或者改为-Indexes（低版本可能会报错）<Directory “/var/www/html”> Options FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>或者<Directory “/var/www/html”> Options -Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>缺少"x-content-type-options"头在httpd.conf里面增加Header always set X-Content-Type-Options nosniff其他允许Flash文件与任何域HTML页面通信描述解决方法将参数AllowScriptAccess设置为never&#65279导致页面空行描述：页面的编码如果是UTF-8 + BOM，会在body开头处加入一个可见的控制符，导致页面头部会出现一个空白。这种编码方式一般会在windows操作系统中出现，比如记事本编辑器，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于html来说，BOM是个大麻烦。因为浏览器在解析html页面时，并不会忽略BOM，所以在解析html文件时，会把BOM作为该文件开头正文的一部分，这串字符也将会被直接执行（在页面中并不显示）出来。由此造成即使页面的 top或者padding 设置为0，也无法让整个网页紧贴浏览器顶部，因为在html一开头有这3个隐藏字符！解决办法：保存文件为utf-8建议不要用记事本打开开发文件 ...

在近期发布的《2018年上半年中国移动互联网行业发展分析报告》中提出，在上半年中国移动互联网关键字TOP1是“安全”，安全已成为中国移动互联网企业存亡生命线。作为平台，首先要保证输出内容的安全，其次要保证用户的人身财产安全及数据安全。安全，为立“身”之本。在过去二十多年中，伴随着移动互联网的发展，游戏行业经历很大的变化——不仅仅是从技术上的革新，游戏的实现能力更是有了飞跃的发展，但是在移动游戏逐渐成为大众休闲娱乐的主流方式的背后，其安全正受到网络黑产的巨大威胁。移动游戏发展迅猛，安全问题如影随形 据相关数据显示，截止到2018年3季度，全球移动互联网用户已超过30亿，欧美、东亚等区域渗透率近80%。从3季度基于移动互联网应用月新增占比分布数据看，游戏行业占比位居第二，且主流手机游戏应用MAU同比增长趋势明显。但是，随着硬件与开发技术的成熟相继发展成型，游戏行业安全问题也随之出现，外挂工具、系统功能漏洞、服务器宕机漏洞等问题频发，也将大幅影响游戏内平衡，使用户体验下降。可以说，无论是移动应用还是游戏，发生安全问题就如同打开“潘多拉魔盒”，不但可能危害用户切身利益，也同样会造成企业的损失。与此同时还会发生企业信誉危机，品牌口碑大幅下滑等一系列问题。在腾讯安全云鼎实验室于近日发布《2018年游戏行业安全监测报告及五大攻击趋势》的数据显示，目前游戏行业安全威胁主要包括账号类攻击、DDoS攻击、外挂和其他四大类。1. 帐号类攻击针对游戏行业的帐号类攻击，月均在数亿次/月，且持续平稳，具有长期持续性攻击的特征。（1）攻击类型分布在针对帐号的攻击中，大部分的帐号扫描其实也是为了撞库攻击做准备，少部分是基于历史密码的登录尝试。因此，在帐号安全侧，撞库相关攻击实际占据了80%以上的份额。2. DDoS 攻击 从2018年情况统计中，游戏行业仍为DDoS 攻击主要目标，其中移动 Web 游戏被攻击数量明显增加。从被攻击游戏分类看，端游与手游依然占比最大。3. 外挂2018年主要外挂集中在手游的吃鸡类游戏上，其中外挂热度排名前四的吃鸡类手游占据了超过60%的关注度，加上 PC 端的射击类游戏，射击类外挂已然占据了70%以上。4. 其他 其他攻击还包括主要集中在 App Store 平台的代充值类问题，比如：外币汇率差、黑卡和盗刷信用卡等。移动游戏行业发展，需与游戏安全比翼齐飞 移动游戏安全问题逐渐泛滥已经引起了政府监管部门的关注，政府监管部门已明显放慢了版号审批速度，实施网络游戏总量调控，同时也采取了一系列相应措施：2017年12月，中共中央宣传部、中央网信办、工业和信息化部、教育部、公安部、文化部、国家工商总局、国家新闻出版广电总局联合印发《关于严格规范网络游戏市场管理的意见》(以下简称《意见》)，部署对网络游戏违法违规行为和不良内容进行集中整治。《意见》中明确提出：“网络游戏系统安全、用户信息安全问题较为突出，个人信息泄露、账号非法交易现象较为普遍。同时，管理体制机制与市场发展还不完全匹配，相关法律法规还不够健全，方式手段还不够完善，纠错惩戒不足以形成震慑。”2018年2月5日下午，浦东网安支队召开浦东地区游戏行业网络安全工作会，会议就目前网游行业发展所导致的文化内容缺失等突出问题为背景，向浦东地区的114家网络游戏企业下发《网络游戏企业基础排摸调研表》，并开展法律法规教育，要求各单位核实并上报本单位的信息安全问题。与此同时，全国很多监管部门也在加紧行动，全面排查，加紧规范整治。在2018年12月21日举行的中国游戏产业年会上，中宣部出版局有关人士表示：“首批送审游戏已经完成审核，正在抓紧核发版号”，说明暂停已久的移动游戏审批重新启动，移动游戏行业又将迎来新的春天。而未来，移动游戏的健康发展更需要安全系统的有力加持。移动游戏主要安全攻击分析移动游戏可分为单机游戏和网络游戏两大类，基于不同类别游戏特点进行分析：1.单机游戏这类游戏所有的数据基本都在本地，面临的分析主要有内购破解，二次打包，游戏修改器等威胁。因为数据基本都在本地，攻击者可以修改本地数据达到一些非法的目的，比如：修改生命值，增加金钱，修改伤害值等。还有一些抄袭者将游戏彻底分析，或者重新二次代码，只修改游戏里面的原有包名，和游戏人物角色ui和名称，可以快速开发一款同类产品，减少开发周期。还有就是直接盗用，修改支付链接，转换为自己的，并将付费额度修改为比正版更低的价格。2.网络游戏这类游戏主要的数据是和服务器进行交互，有些战斗数据计算可能在本地或者是服务器，应对本地计算的，建议放到服务器计算，这样安全性更高。主要的威胁有：外挂，私服，第三方抄袭等。外挂：可以通过分析游戏的核心数据，分析游戏的内部代码达到一些非法操作，比如脱机挂可以自动注册游戏，进行游戏通关操作、刷金币、刷等级等；还有通过外挂可以加速游戏运行，缩短游戏打斗。私服：这种情况是通过破解游戏和服务器的通信协议自建服务器，将游戏网络地址给为自建服务器地址。第三方抄袭：破解游戏后，分析游戏的数值数据、关卡配置等一系列的数据信息。若为网络数据则通过抓包等手段进行分析，开发者只需要修改ui等手段即可以快速出一款同类游戏，减少了策划等工作。造成安全问题的技术实现分析：1.内购破解：通过暴力破解方式，绕过/破解支付校验代码，支付框架、sdk破解，造成收入严重受损。2.修改内存通过内存注入、动态调试、内存dump等操作恶意篡改游戏内容，造成游戏平衡性下降。3.二次打包篡改游戏代码、更换游戏logo、皮肤、包名，篡改后的游戏，造成扣费、流量损耗、弹广告等等，造成公司名义受损。4.游戏修改器游戏修改器对几乎所有的游戏都会造成严重破坏，修改游戏属性值，严重破坏游戏平衡，付费环节变得没有任何作用，收入变低，用户兴趣低，用户量损失。5.核心技术、数据信息丢失通过破解方式，获取游戏核心代码，对公司自主产权造成严重损害，游戏数据信息丢失、玩家个人信息数据泄露。移动游戏安全解决方案解析 1.Java代码vmp加密对dex文件进行native指令化转化，并且以native方式还原到安卓内存中，即使使用dump手段dump出当前部分代码，也是经过native处理过的代码，不会还原成APP源代码。2.动态调试保护（1）防动态注入防注入保护，能防止APP运行时通过注入的方式获取APP隐私数据、使用hook等方式劫持APP的正常运行流程等。当加固后的APP检测到注入时，APP会自动退出运行。（2）防动态调试反调试机制能够拒绝调试工具的附加操作，阻止调试器对移动应用调试分析其业务逻辑代码，一旦被加固的程序检测到有如gdb等调试操作将自动退出运行。（3）防内存dump防内存dump保护，能有效阻止gdb dump等操作，同时因为代码采用函数体分离方式和native化保护，代码都是以单个函数还原到内存中，而内存中的代码也是经过native处理，及时dump出当前代码片段，也是经过native方式处理后的代码，不会还原成源代码。3.防二次打包对签名做完整性校验保护，一旦更改签名文件，程序将不会再次运行。4.So源码混淆对SO文件做加密和自定义加载处理，除此之外还会对SO文件中字符串加密和代码混淆处理，层层防止攻击者提取SO文件和对其二进制代码做反编译和反汇编处理。对Objective-C、C、C++编译后的Native代码进行代码混淆处理，被混淆过后的代码中存在多余代码、怪癖语法、冗余逻辑判断，冗余函数调用等难以阅读和理解的代码，结合字符串加密和反调试机制等功能，让攻击者无法反编译，从而有效的保护源代码安全。5.代码虚拟化保护采用基于LLVM编译器中间层实现的虚拟化编译器，可通过虚拟CPU解释器以及虚拟IR指令，将原始CPU指令进行加密转换处理为只能由虚拟解释器解释执行的虚拟指令，能够完全隐藏函数代码逻辑，以及函数及变量之间的依赖关系。6.其他安全建议iOS安全建议，为了防止在Android端无法分析出协议，但是可以通过iOS端分析的情况发生，建议iOS端也做安全加密操作，iOS端源码混淆功能与so文件源码混淆功能相同，字符串加密、代码结构逻辑混淆、指令替换、控制流平坦化，虚假控制流等。实例解构 几维安全通过长期研究开发，形成了专有技术KiwiVM虚拟化保护方案，实现CPU指令虚拟化，对手游的核心代码进行安全编译、生成受保护的安全模块，从而避免因破解造成的安全风险。以几维安全为某移动游戏企业提供的安全加固案例为例进行解构：1、基于公司现状进行安全风险分析，梳理出该公司的安全加固需求：（1）手游基于Unity3d引擎开发，核心DLL文件存在被逆向破解的风险；（2）不具备正版校验机制，伪冒、盗版手游影响正版手游的正常运营；（3）游戏修改器、脱机挂破坏游戏的公平性，付费用户逐渐流失。2、结合该公司的特点，拟定端到端的整体安全防护方案：3．以整体安全体系架构为基础，根据需求进行单产品或产品组合部署如：在该案例中提供《KiwiVM虚拟机》和《Unity3D手游加密》方案，保护企业核心代码，保障手游正常的运营与推广。（1）提供KiwiVM虚拟化服务KiwiVM是基于Clang编译器扩展实现的VM虚拟机编译器, 在编译时直接对指定的函数［代码］实施虚拟化处理。其加密过程不可逆，攻击者无法还原代码，分析核心业务逻辑。可帮助中大型企业在通信、支付、算法、核心技术等模块进行深度加密，避免因逆向破解问题造成的经济损失。（2）Unity3D手游加密服务Unity3D手游加固服务是在APP安全加固的基础之上，针对Unity3D手游，扩展了函数级［或整体级］的DLL文件加密功能，避免DLL文件被 .NET Reflector 等破解工具提取C#源代码。与DEX加密、防二次打包、内存保护、反调试、防系统加速挂等功能配合形成一套完整的Unity3D手游加密方案。登录移动安全管理平台即可使用。DLL函数级加密为企业版，其算法有几十种可供选择，同时对这些加密算法都有高强度的加密保护，攻击者无法通过Dump内存数据来窃取C#源代码。结语 移动游戏安全系统价值在于维护公平的游戏环境、保护玩家财产、提高用户体验感。千锤百炼，锻造移动游戏安全防护黄金铠甲，为企业树立可信品牌，使用户安心驰骋在手游疆场，助力游戏行业在移动互联网大发展浪潮中更蓬勃的发展。

背景公司上市不到两周，便遭受到了黑客攻击，其中笔者团队的验证码比较容易识别，攻击者通过ORC识别刷了10几万的短信，除了造成一笔资金开销外，也给服务器带来了很大的压力；并且在阿里云的控制台当中每天都能看到很多攻击信息，却没有拦截，原因是没有购买WAF防火墙，售后也频繁催促购买其安全设施；所以技术负负责人也开始重视起安全问题来，笔者因为懂一些安全技术，所以老大希望笔者在这方面做一些规划指导，周末花了点时间根据公司的现状做了一下规划设想，下文便是当时的口述汇报，后来整理成了文字版，给读者做一些参考吧。一、网络安全威胁提到安全可能直觉上会想到安全漏洞，代码安全等问题，不过安全一般比直觉上的范围更广泛，主要有来自于六个方面：网络安全、主机安全、应用安全、数据安全、运维安全、法律风险等。1.1 网络层拒绝服务攻击，分布式拒绝服务攻击（DDoS），是最暴力、血腥、有效的攻击方式，可直接导致企业云上业务系统带宽堵塞。DDOS攻击防御有两个核心点，首先是识别谁是恶意攻击，另外就是要有足够的带宽和服务器性能来处理这些请求，DDOS攻击是在太野蛮，应对的方法也比较被动，可以使用云平台的防DDOS产品，但也会有误伤，所以遇到这种攻击也只能使用这种无奈的处理来应对。1.2 主机层云主机入侵攻击，云主机是企业云上业务系统的重要承载，攻击者通过暴力破解或配置漏洞等缺陷入侵云主机，用以构建僵尸网络、窃取数据及敲诈勒索等。主机层的风险通常是一些通用漏洞的风险，比如2016年心脏滴血事件全球的服务器都会受到此影响，因此到相对好处理，我们可以使用阿里云的安骑士产品，一键修复系统中的安全漏洞。1.3 应用层Web应用漏洞攻击，企业云上业务系统对外提供服务的诸多系统采用HTTP/S应用协议（Web），攻击者利用Web服务可能存在的诸多漏洞进行攻击，窃取业务系统数据或权限等。应用层变更最为频繁，每家的应用特点都有一些差异，所以通常应用层受攻击的可能性最大，要防御此风险需要持续不断的进行跟进，比如对开发的安全意识，安全开发进行培训，对项目上线前的测试增加安全测试部分。1.4 数据层数据窃取或篡改云上业务系统数据在传输过程中经过互联网，可能被中途窃取或篡改，造成数据完整性和机密性受到影响。数据层相对范围比较广，比如代码是否泄漏，是否有数据泄漏，以及页面挂马，网站的留言的黄赌毒关键词筛选等，因为这些数据泄漏的途径会随着应用层的变化而变化，因此数据层也同样需要持续跟进。1.5 运维层运维人员违规风险操作企业云上业务系统需要内部人员进行运维操作，如何防范高风险的运维操作至关重要。不过运维层的操作风险倒也是各个厂家的一些通用风险，因此解决方案也相对较多，比如使用堡垒机在可视化界面上分配权限，这个权限可以让一个账户指定开启多长时间，并且还可以全程监控，以及操作记录回查，因此风险不大。1.6 合规层国家等级保护2017年6月，国家网络安全法开始实施，企业安全建设不仅仅是内部驱动，同时也有法律驱动。包括实名制，以及日至留存，制定相应的企业安全防护策略等。二、安全制度大多数人可能想到安全是从安全技术上来解决，实际上安全问题不仅仅靠的是技术层面，更多的是从制度上去解决的；2.1 安全工程化这里提一下SDL，SDL是英文字母的缩写，中文名称是安全开发生命周期，他是一套安全的生成流程。最开始来自于微软，在微软2004年以前windows系统和office中存在大量安全漏洞，为了解决这些问题提出了SDL，当使用了SDL之后office、windows的安全漏洞大量降低，后来被各个厂商推广。SDL从 安全培训-》需求分析-》设计-》实施-》安全验证-》发布-》响应 这7个方面入手，每一个环节有相应的安全标准，不过微软标准版的SDL推广并不是很顺利，原因很多，但标准版SDL比较繁重是一个重要的因素，因此各家都有自己的一套SDL标准，在这方面我们也可以进行一些借鉴，制定一套自己的SDL标准，这个标准的制定一定要符合可执行可落地来为依据，可以参考我下面的落地实施部分。2.2 对外沟通2016年前以前，白帽子发现漏洞在乌云网报告，乌云网通知到各个公司，2016年7月之后乌云网关闭，一批白帽子被抓，导致白帽子发现漏洞不敢报告；不过后来各家开始组建自己的漏洞报告平台，2017年6月安全法出来之后，大部分公司要合规，因此大一些的公司通常都有自己的安全团队，比如教育行业好未来的应急响应中心；现在大家发现漏洞通常会报告给对应的平台的SRC；比如教育行业的好未来SRC：http://src.100tal.com/瓜子二手车的SRC：https://security.guazi.com/以及更多的SRC平台，如下图2.3 安全落地上面提到了安全工程化，不过SDL的标准对于我们现阶段太过于理想，所以需要针对实际情况制定一些可落地的方案安全编程规范将一些可能带来安全风险的操作写入规范当中去，比如参数的输入输出，服务器的安全配置，以及代码的安全发布流程等。安全培训很多时候开发者并不重视安全，又或许对安全缺乏了解，比如系统中有哪些安全漏洞，漏洞的危害和原理是什么样的，怎么去防止这些漏洞等等，大部分开发者的安全意识还是很弱，和互联网技术不重视安全也有关系，可能一些开发者知道一些SQL注入、XSS，但是一深入去问一下，就不知所以然，而开发者对安全起了至关重要的作用，所以很有必要对开发者进行安全意识和安全基础技术的培训，这样才能从源头解决安全问题。代码审计这个不管是对于安全的角度还是对于减少BUG的角度都是很有必要的一个环节，对每个项目设定一个代码审计人员，可以对此这些审计人员组织一次代码审计指导；安全测试目前我们项目上线做了充足的功能测试，但是安全测试相对偏少，或者说并不全面，可以专门针对测试的人进行一些安全工具的测试的指导。三、安全产品阿里云提供的安全产品比较齐全，不过价格比较贵，而目前我们没有专门负责安全的人来维护，因此选择的安全产品方向为能直接提升安全，这样才能发挥最大价值，否则便成了手有宝刀，却无刀法，下面是三个必要的安全产品：1. 安骑士前面提到了主机安全，主机安全不会经常变动，因此应对的是一些通用风险，安骑士提供一键修复通用主机漏洞的能力，可以快速修补主机安全，避免人工去修复并不知道如何去修，或者修复不及时。2. WAF防火墙WAF防火墙对应的是应用层安全，可以针对一些代码级的安全漏洞做一些安全防护，应用层变化最大，因此必要性比较大，不过要注意的是WAF防火墙只能处理代码级的漏洞，而逻辑层的却无能为力，比如上次的刷验证码，防火墙则只能将频率非常高的IP封锁，但无法阻挡刷验证码的漏洞问题。3. CA证书CA证书的作用是HTTPS，是用来对传输过程加密，比如服务器提交数据到服务器过程不被攻击者拦截，又或者我们服务器的数据不被一些网络运营商插入广告等，因此重要性也是十分重要。另外针对阿里云的安全产品较贵的，可以参考也可以参考其他家的安全产品，比如百度的云加速，就带有了WAF防火墙和防DDOS功能，地址为 su.baidu.com四、新书推荐如果对笔者的实战文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示作者：汤青松日期：2018-11-13微信：songboy8888

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦本文由腾讯游戏云发表于云+社区专栏背景：Memcached攻击创造DDoS攻击流量纪录近日，利用Memcached服务器实施反射DDoS攻击的事件呈大幅上升趋势。DDoS攻击流量首次过T，引发业界热烈回应。现腾讯游戏云回溯整个事件如下：追溯2 月 27 日消息，Cloudflare 和 Arbor Networks 公司于周二发出警告称，恶意攻击者正在滥用 Memcached 协议发起分布式拒绝服务（DDoS）放大攻击，全球范围内许多服务器（包括 Arbor Networks 公司）受到影响。下图为监测到Memcached攻击态势。仅仅过了一天，就出现了1.35Tbps攻击流量刷新DDoS攻击历史纪录。美国东部时间周三下午，GitHub透露其可能遭受了有史最强的DDoS攻击，专家称攻击者采用了放大攻击的新方法Memcached反射攻击，可能会在未来发生更大规模的分布式拒绝服务（DDoS）攻击。对GitHub平台的第一次峰值流量攻击达到了1.35Tbps，随后又出现了另外一次400Gbps的峰值，这可能也将成为目前记录在案的最强DDoS攻击，此前这一数据为1.1Tbps。据CNCERT3月3日消息，监测发现Memcached反射攻击在北京时间3月1日凌晨2点30分左右峰值流量高达1.94Tbps。腾讯云捕获多起Memcached反射型DDoS攻击截止3月6日，腾讯云已捕获到多起利用Memcached发起的反射型DDoS攻击。主要攻击目标包括游戏、门户网站等业务。腾讯云数据监测显示，黑产针对腾讯云业务发起的Memcached反射型攻击从2月21日起进入活跃期，在3月1日达到活跃高峰，随后攻击次数明显减少，到3月5日再次出现攻击高峰。攻击态势如下图所示：下图为腾讯云捕获到的Memcached反射型DDoS攻击的抓包样本：腾讯云捕获到的Memcached反射源为22511个。Memcached反射源来源分布情况如下图所示：在腾讯云宙斯盾安全系统防护下，腾讯云业务在Memcached反射型DDoS攻击中不受影响。那么，什么是Memcached反射攻击？一般而言，我们会根据针对的协议类型和攻击方式的不同，把 DDoS 分成 SYN Flood、ACK Flood、UDP Flood、NTP Flood、SSDP Flood、DNS Flood、HTTP Flood、ICMP Flood、CC 等各类攻击类型。DDoS攻击的历史可以追溯到上世纪90年代，反射型DDoS 攻击则是DDoS攻击中较巧妙的一种。攻击者并不直接攻击目标服务 IP，而是通过伪造被攻击者的 IP向开放某些某些特殊服务的服务器发请求报文，该服务器会将数倍于请求报文的回复数据发送到那个伪造的IP（即目标服务IP），从而实现隔山打牛，四两拨千金的效果。而Memcached反射型攻击因为其高达数万倍的放大倍数，更加受到攻击者的青睐。Memcached反射攻击，就是发起攻击者伪造成受害者的IP对互联网上可以被利用的Memcached的服务发起大量请求，Memcached对请求回应。大量的回应报文汇聚到被伪造的IP地址源，形成反射型分布式拒绝服务攻击。为何会造成如此大威胁？据腾讯云宙斯盾安全团队成员介绍，以往我们面临的DDoS威胁，例如NTP和SSDP反射攻击的放大倍数一般都是3050之间，而Memcached的放大倍数是万为单位，一般放大倍数接近5万倍，且并不能排除这个倍数被继续放大的可能性。利用这个特点，攻击者可以用非常少的带宽即可发起流量巨大的DDoS攻击。安全建设需要未雨绸缪早在Memcached反射型DDoS攻击手法试探鹅厂业务之时，腾讯云已感知到风险并提前做好部署，这轮黑客基于Memcached反射发起的DDoS攻击都被成功防护。与此同时，腾讯云在捕获到Memcached攻击后，及时协助业务客户自查，提供监测和修复建议以确保用户的服务器不被用于发起DDoS攻击。应对超大流量DDoS攻击的安全建议DDoS攻击愈演愈烈，不断刷新攻击流量纪录，面临超越Tbps级的超大流量攻击，腾讯云宙斯盾安全产品团队建议用户做以下应对：1.需要加强对反射型UDP攻击的重点关注，并提高风险感知能力反射型UDP攻击占据DDoS攻击半壁江山。根据2017年腾讯云游戏行业DDoS攻击态势报告显示，反射型UDP攻击占了2017年全年DDoS攻击的55%，需要重点关注此种类型攻击。此次Memcached反射型攻击作为一种较新型的反射型UDP攻击形式出现，带来巨大安全隐患，需要业界持续关注互联网安全动态，并提高风险感知能力，做好策略应对。在行业内出现威胁爆发时进行必要的演练。2.应对超大流量攻击威胁，建议接入腾讯云超大容量高防产品应对逐步升级的DDoS攻击风险。建议配置腾讯云超大容量高防产品，隐藏源站IP。用高防IP充足的带宽资源应对可能的大流量攻击行为，并根据业务特点制定个性化的防护策略，被DDoS攻击时才能保证业务可用性，从容处理。在面对高等级DDoS威胁时，及时升级防护配置，必要时请求DDoS防护厂商的专家服务。 了解腾讯云新一代高防产品：https://cloud.tencent.com/pro… 3.易受大流量攻击行业需加强防范门户、金融、游戏等往年易受黑产死盯的行业需加强防范，政府等DDoS防护能力较弱的业务需提高大流量攻击的警惕。风险往往曾经出现过苗头，一旦被黑产的春风点起，在毫无防护的情形之下，就会燃起燎原大火。参考链接：https://blog.cloudflare.com/m…http://mp.weixin.qq.com/s/b0T…问答如何防范DDos攻击？相关阅读游戏出海，如何避开DDoS这座暗礁？3行代码，为QQ轻游戏加上语音互动能力《堡垒之夜》畅爽体验的秘诀了解一下！ 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识