据《印度教徒报》报道，印度将放弃微软系统，选择新的操作系统和端点检测与保护系统。 备受期待的 "玛雅操作系统 "将很快用于印度国防部的数字领域，而新的端点检测和保护系统 "Chakravyuh "也将一起面世。 不过，印度国防部尚未证实此事，也未发布官方消息。 玛雅操作系统与印度国防部 由于微软产品经常出现漏洞，一个拥有 14.86 亿人口的国家不能忽视这些漏洞带来的影响。 虽然大部分国防计算机是不联网的，但仍然有相当数量的计算机是相互连接的，因此很容易受到网络威胁。 众所周知，国家支持的高级持续威胁（ATP）组织以这些系统为目标，旨在提取敏感信息或建立未经授权的网络访问，以开展网络间谍活动。 据报道，为了应对这些不断变化的网络挑战，国防部正考虑在所有连接互联网的计算机上用本土的”玛雅“ 操作系统取代微软操作系统。 ”玛雅“ 操作系统是一个基于 Linux 的发行版，从流行的 Ubuntu 操作系统中汲取灵感。 预计这一过渡将是无缝的，因为与其他 GUI（图形用户界面）操作系统一样，”玛雅“ 操作系统将提供与 Windows 相似的用户界面和功能。 据报道，”玛雅“ 操作系统将在印度独立日（即 8 月 15 日）之前在南区实施。 印度旨在利用”玛雅“ 操作系统提高安全性 印度陆军、海军和空军已经对新操作系统进行了严格评估，海军已经批准。 同时，陆军和空军正在进行全面评估。据 Gizbot 报道，一旦这些评估结束，三个军种都准备将 ”玛雅“ 操作系统集成到其服务网络中。 在向玛雅操作系统过渡的同时，还引入了 "Chakravyuh"，这是一种先进的端点恶意软件检测和保护系统。这种双管齐下的方法有望遏制针对国家数字安全的网络攻击的增加。 国防部之所以决定采用这些先进技术，是因为认识到网络威胁的不断升级。 尽管微软 Windows 操作系统广为人知，而且用户界面友好，但一些漏洞和漏洞利用，以及威胁行为者不断将 Windows 机器作为攻击目标的事实，迫使印度在玛雅操作系统和 Chakravyuh 端点安全的帮助下制定新的方针。 印度国防部正准备进行一次重大的技术变革，有可能告别微软 Windows，迎来 "玛雅 "操作系统时代。 在部署先进的 "Chakravyuh "保护系统的同时，此举标志着印度在捍卫国家数字主权方面迈出了大胆的一步。 参考链接：https://thecyberexpress.com/india-maya-operating-system-defense-ministry/ ...

Bleeping Computer 网站消息，Gafgyt 恶意软件正积极利用 Zyxel P660HN-T1A 路由器五年前曝出的漏洞，每天发动数千次网络攻击活动。据悉，漏洞被追踪为 CVE-2017-18368，是路由器设备远程系统日志转发功能中存在的严重性未验证命令注入漏洞（CVSS v3：9.8），Zyxel 已于 2017 年修补了该漏洞。 早在 2019 年，Zyxel 就强调当时的新变种 Gafgyt 可能会利用该漏洞发动网络攻击，敦促仍在使用旧固件版本的用户尽快升级到最新版本，以保护其设备免遭接管。然而自 2023 年 7 月初以来，Fortinet 仍能够监测到平均每天 7100 次的攻击活动，且攻击数量持续至今。 Fortinet 发布警报表示截止到 2023 年 8 月 7 日，FortiGuard 实验室持续监测到利用 CVE-2017-18368 漏洞的攻击活动，并在过去一个月中阻止了超过数千个独特 IPS 设备的攻击企图。 试图利用 Zyxel 路由器中的 CVE-2017-18368 漏洞（来源：Fortinet ） Fortinet 指出虽然目前还尚不清楚观察到的攻击活动中有哪一部分成功感染了设备，但自 7 月份以来，攻击活动一直保持稳定。值得一提的是，CISA 近期发布了 CVE-2017-18368 在野外被利用的情况，并将该漏洞添加到其已知利用漏洞目录中，要求联邦机构在 2023 年 8 月 28 日前修补 Zyxel 漏洞。 为应对漏洞利用的爆发，Zyxel 又更新了安全公告，提醒客户 CVE-2017-18363 只影响运行 7.3.15.0 v001/3.40(ULM.0)b31 或更旧固件版本的设备，运行 2017 年为修复漏洞而推出的最新固件版本 3.40(BYF.11) 的 P660HN-T1A 路由器不受影响。 此外，Zyxel 表示 P660HN-T1A 在几年前就已达到报废年限。因此，强烈建议用户将其更换为更新一代的产品，以获得最佳保护。 路由器感染恶意软件常见迹象包括连接不稳定、设备过热、配置突然改变、反应迟钝、非典型网络流量、开放新端口和意外重启，如果怀疑自己的设备受到网络恶意软件的攻击，用户可以执行出厂重置，将设备固件更新到最新版本，更改默认的管理员用户凭据，并禁用远程管理面板，只从内部网络管理设备。 文章来源： https://www.bleepingcomputer.com/news/security/gafgyt-malware-exploits-five-years-old-flaw-in-eol-zyxel-router/#google_vignette ...

近期，来自加拿大多伦多大学公民实验室的研究人员在国内热门输入法——搜狗输入法的加密系统中发现了漏洞，能允许网络监听者破译用户的输入内容。目前该漏洞已得到修复。 研究人员发现漏洞的软件版本涉及三大主流系统，分别是Windows 13.4版本、Android 11.20版本和 iOS 11.21版本，其内部定制的EncryptWall加密系统在Windows和Android系统中存在CBC 密文填塞（padding oracle）攻击漏洞，能让网络监听者恢复加密网络传输的明文，从而泄露敏感信息。在iOS中虽然发现了漏洞，但并不清楚具体的利用方式。 恢复的数据示例摘录，第 11 行包含键入的文本 EncryptWall加密系统旨在通过纯 HTTP POST 请求中的加密字段，将敏感流量安全地传输到未加密的搜狗 HTTP API 端点。在通过 HTTPS 发出 EncryptWall 请求的情况下，研究人员认为这些请求是安全的，但EncryptWall 请求的底层加密技术中可能存在任何缺陷。 研究人员发现，CBC 密文填塞攻击是一种早在2002年就曾出现的选择密文攻击，信息的明文可以一个字节一个字节地恢复，每个字节最多使用 256 条信息。这种攻击依赖于一种称为填充预言的侧通道的存在，它可以明确地揭示接收到的密文在解密时是否被正确填充。 研究人员于今年5月31日向搜狗报告了次漏洞，最终修复版本于7月20日正式发布（Windows 13.7版本 、Android 11.26版本  和 iOS11.25 版本 ），强烈建议搜狗输入法的用户立刻升级至上述版本。 根据研究人员的报告，搜狗输入法是最受欢迎的中文输入法，占中文输入法用户的70%，每月活跃用户超过4.55 亿。 ...

2005年3月，工信部要求所有境内网站都要进行网站备案、公安备案。 2023年8月，工信部要求所有的APP、小程序进行备案。否则…… 这绝对是一个移动互联网创业分水岭，一个划时代的政策，以后的APP一定会越来越规范、越来越正规。独立APP开发的创业之路将会堵掉一部分，下面是官方消息引用： 工信部组织开展APP备案工作：未备案不得从事APP互联网信息服务。为促进互联网行业规范健康发展，进一步做好移动互联网信息服务管理，工业和信息化部近日印发通知，组织开展移动互联网应用程序(以下简称APP)备案工作。要求在中华人民共和国境内从事互联网信息服务的APP主办者，应当依照《中华人民共和国反电信网络诈骗法》《互联网信息服务管理办法》等规定履行备案手续，未履行备案手续的，不得从事APP互联网信息服务。并要求2024年4月至2024年6月底完成巡检工作。 看来只剩十个月(300天)过渡期了，当前苹果App Store上一共有120万APP，扣掉一半不活跃的60万，平均一天要备案2000个APP，这还只是苹果的。算上小米、华为、OPPO等应用商店的APP，这备案的数量难度非常之大，工作量非常巨大。 根据网站备案的经验来看，APP备案的方式应该和网站备案一样，比如去各个IDC备案、人脸识别、公司验证、准备各种备案材料。有了网站备案的经验，APP备案的材料应该不复杂。 另外以后APP备案估计也要分为“个人备案”和“公司备案”，个人备案的APP，只有少部分功能，比如作为个人日记本使用。一旦涉及到交互、商业等行为就必须要你做公司备案。 那公司APP备案限制上少了，这也会导致很多独立开发者要开公司才能做APP，而且还要面对“版权”和“无限责任连带”的风险。 当然，你一定会问小K说：我APP不备案，你能把我怎么样?我就不备案。 我的回答的是：你APP不备案，当然不会把你怎么样。但你休想用国内的服务器、休想上架应用商店。国内的各种服务例如CDN、云存储、数据库、支付结算等等你都有没资格用。创业的门槛稍微加大。 当然上面的假设都是从APP创业者角度思考的，但对国家和普通民众来说绝对是好事。 APP备案相当于加强对App的监管，保障用户的隐私安全，很大程度上防止了电信诈骗。 其实早在10年前（2012年），移动互联网刚刚爆发的时候，工信部就考虑过要求APP备案，不过那时候还不太成熟，也就不了了之了。不过这事耽搁了10年，终于还是来了…………...

网站平台发布的涉及举报企业案件往往存在“不确定性”，这种现象源于信息传播的快速和广泛性，容易造成信息的扩散失控，导致不实消息、夸大事实或者无根据的猜测在网络上蔓延。此外，一些恶意带节奏的团体/个人出于利益或其他动机，对企业进行恶意举报或者散布谣言，故意夸大事件影响，误导公众。为更好维护保障企业和企业家网络合法权益，建立“优化营商网络环境”长效工作机制，近日，中央网信办根据《民法典》《网络安全法》《网络信息内容生态治理规定》《互联网用户账号信息管理规定》等法律法规和国家有关规定，结合举报工作实际，印发了《网站平台受理处置涉企网络侵权信息举报工作规范》（以下简称《工作规范》）。网站平台应“分类分级”处置涉企网络侵权举报信息《工作规范》第四条指出网站平台对于混淆企业主体身份的仿冒性信息、影响公众公正评判的误导性信息、不符合企业客观实际的谣言性信息、贬损丑化企业或企业家的侮辱性信息、侵害企业家个人隐私的泄密性信息、其他恶意干扰企业正常经营发展的信息等，应该重点受理处置。信息类型具体内容如下：仿冒性信息：仿冒性信息主要包括在名称、头像、简介等网络账号名称信息中，违规使用与企业相同或相似的名称标识或企业家姓名肖像的、假借企业或企业家名义发布信息的、非法镜像企业官方网站、APP，或冒用盗用企业官方网站、APP备案注册信息或其他显著要素特征的以及其他引发公众混淆企业主体身份的信息，对于误导性信息，网站平台应当严格审查。误导性信息：通过增删信息、改变顺序、调整结构等方式，曲解新闻原意的，有关部门、新闻媒体等纠正或撤销的过期信息，删减旧闻旧事发生时间、地点和处理结果，重新发布的，使用与内容严重不符的夸张标题的、强调不利事实，回避有利事实，以偏概全的、断章取义企业家或企业代表过往言论的、片面解读企业各类对外公告的、引发公众误解误读的信息等都是误导性信息。谣言类信息：谣言类信息主要包括虚构企业家隐私生活的、编造企业违法犯罪或违规生产经营的、杜撰企业家或企业员工违法犯罪或道德失范的、夸大企业或企业家生产经营困难的、歪曲企业或企业家正常生产经营和投资活动的、诋毁企业产品服务质量的、抹黑企业科技创新能力的、其他与企业客观实际情况不符的信息。侮辱性信息：对于攻击谩骂企业或企业家的、涂抹恶搞企业家肖像照片的、与色情低俗话题恶意关联的以及其他违反公序良俗丑化企业或企业家的信息归类于侮辱性信息。泄密性信息：违规披露企业家身份证、护照、社保卡、户籍档案等个人身份信息的、违规披露企业家家庭住址、电话号码、电子邮箱等个人联系信息的、其他法律法规禁止披露的隐私信息。《工作规范》对于网站平台如何处置上述类型信息以及其他恶意干扰企业正常经营发展的信息做出严格规范，要求网站平台充分掌握相关资料，及时处置，以免影响企业正常生产经营。网站平台联合监管部门及时处置举报信息对于举报人提交的举报信息应当及时判断真实性，《工作规范》指出如果提交的信息能够满足充分陈述举报事项、阐明举报理由的文字举报、提交能够证明举报内容侵权的初步证据材料、提交申明举报真实性、合法性的文字保证等条件，网站平台应当予以受理。此外，《工作规范》第二十五条和第二十六条强调网站平台受理涉股东、高管、子公司、业务合作伙伴等企业利益相关方的网络侵权信息举报，研判认为有必要采取相应处置措施的，应当报请省级网信部门审核。对重大事项，报中央网信办相关司局审核，不得滥用举报处置权利，严禁实施有偿删帖、人情删帖等违法违规行为，严禁利用举报处置权利谋取不正当利益。最后，《工作规范》要求网站平台应当建立健全规章制度，严格工作流程，规范层级把关，强化内部监督，确保依法依规受理处置涉企网络侵权信息举报，建立工作台账，如实记录涉企网络侵权信息举报受理处置全过程，留存全量数据不少于六个月，并在网信部门依法查询时，予以提供，相关账号处置情况，也应当定期报送中央网信办相关司局。同时，各级网信举报部门应当建立健全日常检查和专项检查相结合的工作制度，依法依规对属地网站平台涉企网络侵权信息举报受理处置工作实施监督管理。 ...

2023年3月知道创宇404高级威胁情报团队全球率先捕获到一个全新APT组织的武器后门，我们称为“ORPCBackdoor”，并在2023年5月对外发布了该武器后门的详细分析：Bitter 组织新攻击武器分析报告 - ORPCBackdoor 武器分析 在该报告里我们把该武器后门定位为 BITTER（“蔓灵花”）使用的最新武器，然而我们留意到近日卡巴斯基发布报告称他们于第二季度发现了一个全新的APT组织，该组织的主要攻击目标为巴基斯坦，将其命名为“Mysterious Elephant（神秘象）”。此外还发布了两篇非公开报告，第一篇报告主要描述了该组织过去几年的主要技战术（TTPS），第二篇描述了该组织对巴基斯坦外交相关部门的攻击行动。 该组织主要特点是使用了一个全新的后门，该后门通过恶意RTF文档传递到受害者机器上。恶意RTF文档通过钓鱼邮件进行投递。这个全新的后门通过RPC与C2服务器进行通信，并有在受控机器上执行文件或者命令的能力，同时该后门也可以从C2服务器上接收文件和命令并执行。经过确认，卡巴斯基发现的后门与我们率先捕获的“ORPCBackdoor”是同一个后门程序。考虑到归因存在分歧差异，由此知道创宇404高级威胁情报团队把使用“ORPCBackdoor”的“新”组织启用全新编号：APT-K-47，中文名称“神秘象”。 本文我们也会从样本整体攻击链及同源关系分析等进一步扩线分析，且我们也通过知道创宇遥测大数据观察到该组织攻击的目标除了巴基斯坦外，还有攻击其他国家的痕迹。同时经过回溯分析，我们发现该组织最早攻击活动应当开始于2022年3月份左右。本文将公布该APT组织攻击细节及相关IOC。 1. 整体攻击链 图1在APT-K01的一次攻击活动中，攻击者通过钓鱼邮件向攻击目标发送CHM文件，CHM文件使用“俄中友好、和平与发展委员会”为诱饵，相关诱饵内容如下所示。 图2从钓鱼文件的内容可以看到，该组织的攻击目标不只是卡巴斯基描述的仅针对巴基斯坦，根据前期知道创宇遥测大数据显示，该组织攻击目标为多个国家。 CHM文件恶意部分为doc.html，该文件中存在一个OBJECT对象，该对象用于创建一个每隔15分钟运行一次的计划任务，任务用于下载并执行存放在二阶服务器中的二阶恶意程序，二阶程序为MSI文件。 图3二阶MSI文件中存放着一对白加黑文件，黑文件为卡巴斯基报告中提到的ORPCBackdoor，白文件为微软官方服务文件，用于启动黑文件（OLMAPI32.dll）。 图4 2. 同源性分析 ORPCBackdoor攻击链条与印度方向所使用的技战术相重叠，其中 BITTER 组织的技战术与代码结构尤为相像，相关对比分析如下： BITTER 组织在往期的攻击活动中使用的 CHM 文件结构如下： 图5本次捕获到的 ORPCBackdoor 初始阶段的 CHM 文件结构如下： 图6两者doc.htm文件对比，下图为 BITTER 的doc.htm文件： 图7下图为ORPC的CHM文件中的doc.htm文件： 图8CHM文件从代码逻辑、功能和规避技巧等方面来看几乎一致，后续下载的二阶文件均为msi文件。 ORPCBackdoor攻击链条与南亚方向所使用的技战术相重叠，分析发现该木马曾在confucious组织使用过的网络资产里面出现过，同时我们发现同类木马也在 BITTER 组织使用过的资产上出现过。南亚方向的APT组织一直以来都存在资产方向的交叉使用，我们甚至发现过confucious与Patchwork组织出现过部分特殊字符串的重用，很难完全将某一个组织彻底同其他组织分开，目前的主要区分依据还是整个木马攻击链条的区别以及部分网络资产的区别。综合我们对其他南亚组织Sidewinder、Patchwork、cnc、confucious、BITTER、APT-K-47的分析情况来看，这几个黑客组织可能是同一组织下的不同小组，存在攻击工具、攻击目标、网络资产方面不少重叠情况。 3. ORPCBackdoor描述 3.1 样本功能综述 ORPCBackdoor共计17个导出函数，相关导出函数名称如下所示： GetFileVersionInfoA GetFileVersionInfoByHandle GetFileVersionInfoExW GetFileVersionInfoSizeA GetFileVersionInfoSizeExW GetFileVersionInfoSizeW GetFileVersionInfoW VerFindFileA VerFindFileW VerInstallFileA VerInstallFileW VerLanguageNameA VerLanguageNameW VerQueryValueA VerQueryValueW GetFileVersionInfoByHandleEx(void) DllEntryPoint 从导出函数来看ORPCBackdoor使用了version.dll模版,version.dll是一个Windows操作系统的动态链接库文件，它主要用于管理可执行文件或者DLL文件的版本信息。故我们有理由猜测ORPCBackdoor使用DLL劫持技术，采用白加黑方式用于达到一定的免杀效果，本次发现的调用文件为MicrosoftServices，但由于调用该DLL的情况较多后续BITTER组织可能会使用其他款白文件进行调用。 ORPCBackdoor恶意入口有两处，第一处为GetFileVersionInfoBy- HandleEx(void)导出函数，第二处为DllEntryPoint。 ORPCBackdoor从设计思路来看可分为两个模块，两个模块分别为初始化模块以及交互模块，整体硬编码字符采用HEX字符串保存，例如“SYSTEM INFORMATION \n”字符在ORPCBackdoor中保存的字符为"53595354454D20494E464F524D4154494F4E205C6E"，该方式可略微达到阻碍反检测以及对抗分析等目的，根据ORPCBackdoor所支持的功能，我们可以推断出该后门所处感染链前端，用于为后续行动提供基础环境。 3.1.1 初始化模块描述 初始化模块内包含多个功能模块。多个模块配合完成在与服务端交互执行的前期工作，前期工作包括了字符解析、首次运行测验、持久化、本机信息收集、C2在线检测等方面，各部分内容详述如下： 字符初始化本文前面有提及ORPCBackdoor内置的关键字符均采用TOHEXStr的方式保存，在运行过程中ORPCBackdoor会将即将使用的字符经进行解码。根据后门中的上下文调用来看，加密的字符中还包含了服务端下发的命令。 持久化ORPCBackdoor通过判断文件是否存在，从而防止多次持久化创建，在进行持久化创建前，ORPCBackdoor会判断同路径下是否存在ts.dat文件，当且文件不存在ORPCBackdoor才会创建持久化，持久化创建方式采用COM调用TaskScheduler CLSID，计划任务名称为Microsoft Update，创建完成后创建ts.dat文件。 初始信息收集初始信息收集三个部分数据，分别是进程列表、系统信息、用户信息，相关信息收集非常详尽，除基本信息外还会收集OS Build Type、Registered Owner、Install Date等信息。 交互初始化交互初始化与持久化模块类似，同样通过判断文件是否存在，从而防止与服务端同时多进程与服务端交互，判断逻辑为判断ProgramData路径下是否存在$cache.dat文件，如果文件存在ORPCBackdoor将不会与服务端建立连接，否则初始RPC调用，ProtSeq采用ncacn_ip_tcp。如果在尝试RPC调用后服务端无数据返回则休眠5分钟后继续尝试，当服务端返回命令后进入交互模块。 3.1.2 交互模块描述 交互模块与常见的命令处理逻辑相似，通过多层if-else来解析服务端执行并完成指定功能，ORPCBackdoor所支持的功能并不算多，主要为Get- Shell，其余包含一些文件处理、上传下载执行等操作。 ORPCBackdoor相关执行及对应功能描述如下： IDID指令所对应的功能较为少见，其功能是将服务端下发的一段0xF大小的数据即15位数字（eg: 818040900140701），保存在本地%ProgramData%/$tmp.txt文件中，根据该指令及前面代码流程中未出现ClientID相关生成操作，故我们猜测此步操作用于赋予受害者ID用于区分不同受害者。 INFINF指令用于上传在初始化模块-初始信息收集子模块中所收集的详尽本机信息。 DWNDWN指令所对应的模块属于精心设计过的功能模块，功能为下载文件，根据对代码的分析来看DWN功能模块设计的较为健壮，其支持在向服务端反馈每一步操作是否成功或错误原因，从而完成既定目标流程，由于ORPCBackdoor属于感染链前部分故此模块的稳定性极为重要。 RUNRUN指令用于执行指定文件，使用WinExecAPI启动文件。 DLYDLY指令为休眠指令，休眠服务端指定时长后再次运行。 CMDCMD指令为ORPCBackdoor核心指令，功能为GetShell，其所使用的处理逻辑为，解析服务端所下发的Shell指令，获取到服务端下发的Shell指令后进行指令拼接，拼接格式为cmd.exe /c |服务端下发的指令|>> c:\Users\Public\cr.dat。后续通过WinExec()API执行该条执行，执行完成后将cr.dat的内容发送至服务端，后续删除cr.dat文件从而达到一次与服务端Shell交互效果。在分析过程中，我们捕获到服务端首先会下发systeminfo命令再次获取系统信息，紧接着第二条指令为whoami。通过对ORPCBackdoor整体分析我们可以得出以下结论：ORPCBackdoor后门是一款较为精简且设计较为成熟的后门程序。无论是对自身字符的处理，抛弃常用的Socket调用转而使用RPC调用，还是为规避终端检测所采用的version.dll劫持模板，域名、程序、描述等整体一致性，我们可以看出本次攻击活动可以算得上是一次经过精心设计策划的行动，同时为了防止自身暴露也使用了新型攻击武器从而变更了其惯用的TTP。 3.2 样本细节描述 从ORPCBackdoor相关原始信息中可以看到最早的样本创建时间是2022年2月份和3月份： 图9 图10 图11：正常version.dll 图12：ORPCBackdoor 图13：通过文件判断是否进行持久化流程图13：通过文件判断是否进行持久化流程 图14：主机当前运行的进程信息收集 图15——18：极为详尽的系统信息收集 图19：服务端指令初始化 图20：RPC初始化 图21：生成ClienID 图22：生成的ClienID 图23：上传前期收集的系统信息 图24：文件下载模块 图25：RUN指令-运行指定程序 图26：休眠模块 图27：核心模块-Shell模块 图28：服务端下发的命令一 图29：服务端下发的命令二 图30：通过NdrClientCall2API收发服务端消息 4.IOC ORPCBackdoor 8AEB7DD31C764B0CF08B38030A73AC1D22B29522FBCF512E0D24544B3D01D8B3 88ecbe38dbafde7f423eb2feb6dc4a74 f4cea74c8a7f850dadf1e5133ba5e396 C&C msdata.ddns.net outlook-services.ddns.net msoutllook.ddns[.]net outlook-updates.ddns[.]net outlook-services.ddns[.]net 108.62.118.125:443 msdocs.ddns.net 作者：K&NaN@知道创宇404高级威胁情报团队 ...

2023年，本地云应用和平台持续增长。组织一直在努力最大化其应用程序的潜力，以确保无缝的用户体验，并推动业务增长。 混合云环境的兴起和容器化技术（如Kubernetes）的采用彻底改变了现代应用程序的开发、部署和扩展方式。 在数字领域，Kubernetes无疑是大多数云原生应用程序和工作负载的首选平台，被各行业广泛采用。根据2022年的一份报告，96%的公司已经或正计划在其云系统中使用Kubernetes，这个流行的开源实用程序有助于容器编排和发现、负载平衡和其他功能。 【传统部署 VS 虚拟化部署 VS 容器部署】 然而，这种转变带来了一系列新的挑战。随着应用程序复杂性的增加，对强大的可观察性解决方案的需求也在增加，这些解决方案使企业能够深入了解其容器化工作负载。Kubernetes的可观察性是在混合云环境中管理和优化容器化应用程序的一个关键方面。 在本文中，我们将深入研究Kubernetes的可观察性，探索6种有效的策略，以帮助企业在混合云环境中释放其容器化应用程序的全部潜力。这些策略以行业专业知识和实际经验为基础，旨在增强Kubernetes部署的可观察性，从而推动业务成功。 Kubernetes的可观察性 Kubernetes是管理容器化应用程序的强大工具。不过，尽管它具有强大的功能，但要跟踪混合云环境中发生的事情可能异常困难。这就是“可观察性”的用武之地。 可观察性是对特定环境中的数据进行收集、分析和处理。在Kubernetes情境中，可观察性指的是获得对于在Kubernetes集群中运行的容器化应用程序的行为、性能和健康状况的洞察。 Kubernetes的可观察性基于三个关键支柱： 日志：日志提供了关于Kubernetes集群内的行为和事件的有价值信息。它们捕获重要的细节，如应用程序输出、系统错误和操作事件。分析日志有助于排除问题、理解应用程序行为、识别模式或异常。 指标：指标提供了对Kubernetes环境性能和资源利用率的洞察。它们包括CPU使用情况、内存消耗、网络流量和请求延迟信息。监视和分析指标有助于识别性能瓶颈、计划容量和优化资源分配。 跟踪：跟踪支持对Kubernetes应用程序中跨微服务的请求流的端到端可见性。分布式跟踪捕获定时数据和不同组件之间的依赖关系，从而提供对请求路径的全面理解。跟踪有助于识别延迟问题，了解系统依赖关系，并优化关键路径以提高应用程序性能。 Kubernetes可观察性过程通常涉及从各种来源收集和分析数据，以了解系统的内部状态并提供可操作的情报。通过实施正确的可观察性策略，组织可以深入了解其应用程序和基础设施，这将帮助组织实现以下目标： 快速检测和排除问题； 提高性能和可靠性； 优化资源使用； 满足法规遵从性要求 可观察性流程正在被IT团队快速采用。到2026年，70%的组织将成功应用可观察性来缩短决策延迟，同时增加分布式、有组织和简化的数据管理流程。 实现混合云环境下Kubernetes可观察性的6条有效策略 1. 使用集中式日志和日志聚合 为了深入了解分布式系统，集中式日志记录是一种必要的策略。在Kubernetes环境中，应用程序跨越多个容器和节点，因此，从各种来源收集和分析日志变得至关重要。 集中式日志记录包括将来自不同组件的日志整合到一个易于访问的位置。集中式日志的重要性在于它能够提供系统行为和性能的整体视图。 通过Kubernetes日志记录，组织可以在Kubernetes集群中关联事件并识别模式，从而实现高效的故障排除和根本原因分析。 想要在Kubernetes中实现集中式日志记录，组织可以利用强大的日志聚合工具或云原生解决方案，如Amazon CloudWatch Logs或Google Cloud logging。这些工具提供了可扩展且高效的方式来收集、存储和分析Kubernetes集群的日志。 2. 利用分布式跟踪实现端到端可见性 在复杂的Kubernetes环境中，微服务分布在多个容器和节点，想要理解不同组件之间的请求流和交互变得极具挑战性。这就是分布式跟踪发挥作用的地方，当请求遍历各种服务时，它可以提供对请求执行路径的端到端可见性。 分布式跟踪允许组织跟踪请求从入口点到其所涉及的所有微服务的过程，捕获关于每一步的有价值信息。通过使用跟踪库或代理对应用程序进行检测，组织还可以生成显示每个服务的持续时间、延迟和潜在瓶颈的跟踪数据。 在Kubernetes中利用分布式跟踪的好处是显著的。 首先，它可以帮助组织理解服务之间的依赖关系，从而实现更好的故障排除和性能优化。当请求出现延迟或错误时，组织还可以快速识别负责的服务或组件，并采取纠正措施。 其次，分布式跟踪允许组织衡量和监视单个服务及其交互的性能。通过分析跟踪数据，组织可以识别性能瓶颈，检测低效的资源使用，并优化系统的总体响应性。这些信息对于容量规划和确保Kubernetes环境中的可扩展性都是非常宝贵的。 市场上有多种流行的分布式跟踪解决方案可用。这些工具提供了必要的工具和基础架构来有效地收集和可视化跟踪数据。通过将这些解决方案集成到Kubernetes部署中，组织可以全面了解微服务的行为并推动持续改进。 3. 集成Kubernetes与APM解决方案 为了在Kubernetes中实现全面的可观察性，必须将组织的环境与应用程序性能监控（APM）解决方案集成在一起。APM解决方案提供了超越传统指标和日志的高级监控功能，可以深入了解单个应用程序组件的性能和行为。 APM集成的主要好处之一是能够检测和诊断Kubernetes应用程序中的性能瓶颈。 使用APM解决方案，组织可以在请求遍历各种服务时对其进行跟踪，并确定高延迟或资源争用的区域。有了这些信息，组织就可以采取有针对性的操作来优化关键路径，并提高整体应用程序性能。 许多APM解决方案提供专用的Kubernetes集成，可以简化容器化应用程序的监视和管理。这些集成提供了预配置的仪表板、警报和工具库，简化了在Kubernetes环境中捕获和分析APM数据的过程。 4. 使用基于指标的监控 基于指标的监控构成了Kubernetes中可观察性的基础。它包括收集和分析关键指标，这些指标可以洞察Kubernetes集群和应用程序的运行状况、性能和资源利用率。 当谈到Kubernetes中基于指标的监控时，有以下几个基本组件需要考虑： 节点级指标：监控Kubernetes集群中单个节点的资源利用率对于容量规划和基础设施优化至关重要。CPU使用情况、内存使用情况、磁盘I/O和网络带宽等指标可以帮助组织识别潜在的资源瓶颈并确保最佳分配。 pod级指标：pod是Kubernetes中部署的基本单元。监视与pod相关的指标允许组织评估它们的资源消耗、运行状况和总体性能。关键pod级指标包括CPU和内存使用情况、网络吞吐量和请求成功率。 容器级指标：pod中的容器封装了各个应用程序组件。监视容器级指标可以帮助组织了解特定应用程序服务或流程的资源消耗和行为。CPU使用情况、内存使用情况和文件系统使用情况等指标可以帮助组织深入了解容器性能。 特定于应用程序的指标：根据应用程序的需求，组织可能需要监控特定于业务逻辑或领域的自定义指标。这些指标可能包括错误率、缓存命中率或其他相关性能指标。 【基于指标的监控架构图】 5. 使用自定义Kubernetes事件增强可观察性 自定义事件（Custom event）在Kubernetes组件之间以及Kubernetes与外部系统之间进行通信。它们可以发出重要事件的信号，例如部署、扩展操作、配置更改，甚至容器中特定于应用程序的事件。 通过利用自定义事件，组织可以在可观察性方面获得以下好处： 主动性监控：自定义事件允许组织定义和监控需要注意的特定条件。例如，组织可以创建事件来指示何时资源不足、何时pod遇到故障或何时超过特定阈值。通过捕获这些事件，组织可以在问题升级之前主动检测并解决问题。 上下文信息：自定义事件可以包含有助于排除故障和分析根本原因的其他上下文信息。组织可以附加相关的详细信息，例如错误消息、时间戳、受影响的资源或任何其他提供事件重要性的元数据。这个额外的上下文有助于更有效地理解和解决问题。 与外部系统集成：Kubernetes自定义事件可以由外部系统使用，例如监控平台或事件管理工具。集成这些系统允许组织基于特定事件触发自动响应或通知。这简化了事件响应过程，并确保及时解决关键问题。 要利用自定义Kubernetes事件，组织可以使用Kubernetes事件hook、自定义控制器，甚至使用Kubernetes API开发事件驱动的应用程序。通过定义事件触发器、捕获相关信息并对事件作出反应，组织可以建立一个强大的可观察性框架，以补充传统的监控方法。 6. 将合成监控纳入主动可观测性 合成监控（Synthetic Monitoring）会模拟用户旅程或表示与应用程序的日常交互的特定事务。这些合成测试可以安排在不同的地理位置定期运行，以模拟用户行为并测量关键性能指标。 在Kubernetes环境中集成合成监控有以下几个关键好处： 主动问题检测：合成测试允许组织在实际用户受到影响之前检测问题。通过定期模拟用户交互，组织可以识别性能下降、错误或无响应组件。这种早期检测使组织能够主动解决问题并保持应用程序的高可用性。 性能基准测试：合成监控为性能基准测试和SLA遵从性提供了基线。组织可以通过在不同位置运行一致的测试来测量正常条件下的响应时间、延迟和可用性。这些基准可以作为检测异常和确保最佳性能的参考。 地理洞察：组织可以将合成测试配置为从不同的地理位置运行，从而获得对来自不同区域的应用程序性能的洞察。这有助于识别可能影响用户体验的延迟问题或区域差异。通过基于这些见解优化应用程序的性能，组织可以确保全球一致的用户体验。 组织可以利用专门的工具将合成监控集成到Kubernetes环境中。这些工具提供了创建和调度合成测试、监控性能指标和生成报告的功能。 结语 通过使用集中式日志记录和日志聚合、利用分布式跟踪、将Kubernetes与APM解决方案集成、采用基于指标的监控、合并自定义Kubernetes事件和综合监控，组织可以增强对Kubernetes部署的行为和性能的理解。 实现这些策略将提供对分布式系统的全面洞察，支持高效的故障排除、性能优化、主动问题检测和改进的用户体验。无论是运行小型Kubernetes环境的组织，还是管理复杂的混合云部署的组织，都可以应用这些策略来发挥应用程序的最大潜力。 原文链接： https://dzone.com/articles/6-effective-strategies-for-kubernetes-observabilit ...

CSGO游戏搬砖，这个项目，这个概念相信大家已不再陌生。CSGO这款全球竞技游戏，也早已不是当初的游戏，而是带着目的，带着经济系统向大家缓缓走来，一个虚拟的空间，一种虚拟的交易，却可以活生生的创造无数个就业岗位，无数个赚钱机会，其实，这都是大的环境下的一种趋势，是财富转移的另一种形式。 实体经济短暂复苏后现在依旧要死不活，死气沉沉，很多生意都不好做了，大多数人口袋越来越空，消费越来越低迷，都开始勒紧裤腰带过日子了，毕竟活着才会看到希望!我不是唱衰实体经济，也没有不看好实体经济的意思。 01 当下，信息化产业，高科技产品，互联网产品，成了新的风口。如何能认清现实，走自己该走的路线，学习自己该有的看家本事，显得特别的重要。 多亏了各位同行的努力，花着巨额广告费在各大自媒体平台大肆宣传这个CSGO游戏搬砖项目，致使该项目被越来越多的人所熟知。他们就像抓住了救命稻草一样死死抓住该项目，指望通过此项目好好打一个翻身仗。 但大多数人，尽管你内心深处很想赚钱，但你的身体总是向着最容易，最轻微，成本最低，运动量最少的方向做出选择，而大脑的思维意识则在向最高端，最优的方式进行传达。当你下定决心交了学费，打算全身心投入项目时，你的身体却感到很累，行动迟缓，你的大脑根本指挥不了你的身体，行尸走肉罢了。就比如很多新人学习CSGO游戏搬砖，都是一时冲动，新鲜感过了，就放弃了，然后，就没有然后了! 在CSGO游戏搬砖界，利润率达到10%，意味着什么?如果滚两轮，投资1万元，月收益2000元，投资10万元，月收益就是2万元!算不上暴利，但纵观现在经济大环境，你到哪去找一个月利率20%的正规合法项目?银行三年定期存款年利率最高才3.6%，和前者相比，你还敢说20%低吗? 02 也许又有人提出质疑，什么红信概率，什么亏钱风险了等等! 朋友，你还是太年轻了，首先你问一问自己，做什么事是没有风险的?100%没有风险的事，能轮到你来操作?能承担多大的风险必然能收获多大的荣耀，这是毋庸置疑的!何况，这个项目的风险相比我看到的很多其他项目，真的微乎其微了。且CSGO游戏搬砖项目，风险高低其实也是可以人为干预的。而这和你在这一行业里待的时间长短，掌握的知识技能多寡是分不开的。 也有很多朋友，刚进这一行，被人坑了，骗了学费，在我看来，这也不叫事，进入这个行业，你所损失的一切，都会以另外一种方式返还给你，只要你不离开这个行业，一切都会变好的。只要你确实知道自己被骗了，及时展开自救，一切都还来得及，就怕你明知被骗，还不愿意承认，破罐子破摔了。成长是痛苦的，但不成长更痛苦! 03 童话做CSGO游戏搬砖三年了，在这行里我遇到的任何一个赚到钱的人，无不是经历过大风大浪的，包括我自己。我们有的学员在其他团队被割了一次又一次才真正学会什么叫搬砖。如今该行业的大佬，哪个不是在反复入坑中磨炼和提升了自己的专业和技能。新人在识别真假上，在辩人识物上，都存在各种差距，眼力劲太差，经验太少，这是可以理解的。 这行的水很深，林子大了什么鸟都有，这也是难免的，很多人项目刚学会就开始打着各种幌子割韭菜，什么骗子死全家，什么保证月入过万，什么不赚钱全额退款，什么999购买价值9000的搬砖全套教程，为了骗你入坑无所不用其极。 其实，真正的高手，都很低调，懂的人自然会来拜访，有些事不需要声张，有技术的G永远不会叫唤，倒是没有技术的G，整天嚷嚷的，也不知是为了什么? 有时候写点真货，真话，就把一大批人给得罪了，我受的攻击太多了，我怕有天顶不住了，但苦于有这么多的人还在看，还在关注，给了我写下去的勇气与信心。  ...

适用于白盒fuzzing input corpus 收集语料库 对于模糊测试工具而言，我们需要为其准备一个或多个起始的输入案例，这些案例通常能够很好的测试目标程序的预期功能，这样我们就可以尽可能多的覆盖目标程序。收集语料的来源多种多样。通常目标程序会包含一些测试用例，我们可以将其做位我们初始语料的一部分，此外互联网上也有些公开的语料库你可以收集他们做为你的需要。关于语料库的主动性选择，这个更多需要你对fuzzing 目标内部结构的了解。例如你当你要fuzzing的目标对随着输入的规模内存变化非常敏感，那么制作一批很大的文件与较小的文件可能是一个策略，具体是否是否有效取决于你经验、以及对目标的理解。此外，需要注意控制语料库的规模，太过庞大的语料库并不是好的选择，太过潘达的语料库会拖慢fuzzing的效率，尽可能用相对较小的语料覆盖更多目标代码的预期功能即可。 语料库唯一化 我们在上一小节最后提到一点，太过庞大的语料库会因为有太多的测试用例重复相同的路径覆盖，这会减慢fuzzing的效率。因此人们制作了一个工具，能够使语料库覆盖的路径唯一化，简单的说就算去除重复的种子输入，缩减语料库的规模，同时保持相当的测试路径效果。在AFL++中可以使用工具afl-cmin从语料库中去除不会产生新路径和覆盖氛围的重复输入，并且AFL++官方提示强烈建议我们对语料库唯一化，这是一个几乎不会产生坏处的友谊操作。具体的使用如下： 将收集到的所有种子文件放入一个目录中，例如 INPUTS 运行 afl-cmin： 字典 其实将字典放到这一个大节下面不是很合适，因为字典可以归类为一种辅助技巧，不过因为字典影响输入，所以我就将其划到这里了。关于是否使用字典，取决于fuzzing的目的与目标。例如fuzzing的目标是ftp服务器，我们fuzzing的目的是站在用户的视角仅能输入命令，因此我们的输入其中很大一部分可以规范到ftp提供的命令，我们更多的是通过重复测试各种命令的组合来测试目标ftp服务器在各种场景都能正确运行。又比如，当你fuzzing一个很复杂的目标时，它通常提供一个非常非常丰富的命令行参数，每一次运行时组合不同的参数可能会有更好的覆盖效果，因此可以将你需要启用的参数标记为字典添加进命令行参数列表中。最后，目标程序可能经常有常量的比较和验证，而这些环节通常会使得fuzzing停滞在此，因为模糊器的变异策略通常对应常量的猜测是非常低效的。我们可以收集目标程序中使用到的常量，定义为一个字典提供给模糊器。但目前对于AFL++来说有更好的方法解决这种需求，而无需定义字典，后面我们会介绍这些方法。 # 模糊器默认的变异策略通常难以命中if分支为true的情况，因为input做为64位，其值的空间太大了，根本难以猜测。 if (input = 0x1122336644587) { crash(); } else { OK(); } 编译前的准备 选择最佳的编译器 如我们上一节中谈到收集程序常量定义字典时，事实上收集常量并生成字典这个事情，在编译时完全可以顺便将其解决。没错，功能强大的编译器可以使我们在编译期间获得非常多有用的功能。对于AFL++的编译器选择，官方提供了一个简单的选择流程，如下 +--------------------------------+ | clang/clang++ 11+ is available | --> use LTO mode (afl-clang-lto/afl-clang-lto++) +--------------------------------+ see [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.lto.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.lto.md) | | if not, or if the target fails with LTO afl-clang-lto/++ | v +---------------------------------+ | clang/clang++ 3.8+ is available | --> use LLVM mode (afl-clang-fast/afl-clang-fast++) +---------------------------------+ see [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.llvm.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.llvm.md) | | if not, or if the target fails with LLVM afl-clang-fast/++ | v +--------------------------------+ | gcc 5+ is available | -> use GCC_PLUGIN mode (afl-gcc-fast/afl-g++-fast) +--------------------------------+ see [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.gcc_plugin.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.gcc_plugin.md) and [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.instrument_list.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.instrument_list.md) | | if not, or if you do not have a gcc with plugin support | v use GCC mode (afl-gcc/afl-g++) (or afl-clang/afl-clang++ for clang) 若你的LLVM和clang版本大于等于11，那么你可以启用LLVM LTO模式，使用afl-clang-lto/afl-clang-lto++，该模式通常是最佳的。随后依次是afl-clang-fast/afl-clang-fast++和afl-gcc-fast/afl-g++-fast。关于为什么LTO模式通常是最佳的，其中一个原因是它解决了原版AFL中边碰撞的情况，提供了无碰撞的边(edge)检测。在原本AFL中，因为其对边(edge)的标识是随机的，对于AFL默认2^16容量来说，一旦程序足够大，边的标识会重复，这种现象就算边碰撞，它会降低模糊测试的效率。此外LTO模式会自动收集目标代码中的常量制作成为一个字典并自动启用，并且社区提供的一些有用的插件和功能很多时候是要求LLVM模式(clang-fast)甚至是LTO模式(clang-lto)。 NOTE：此处涉及一点AFL度量覆盖率的工作原理，可以参考我注意的另一篇文章《基于覆盖率的Fuzzer和AFL》，写的很一般（逃 关于编译器的选择，如果可能直接选LTO模式即可。但你需要注意，LTO模式编译代码非常的吃内存，编译时间也会很久，尤其是启用某些Sanitizer的时候。 NOTE：你的计算机配置最好至少由8核心，内存最好不低于16G。请注意8核心，16G仍然不是很够用，最好32G，16核或以上，核心越多越好。因为到时候你会编译很多不同版本的程序，不同的插件、不同的sanitizer、不同策略等等，这些不同的选项往往不能兼并到一个程序上，往往需要编译多分不同配置的程序，并你会经常patch程序再编译测试patch的效果。简言之，你会编译很多次程序，你需要足够大的内存和核心来编译目标，使得你不必经常阻塞等待编译队列和结果。 编译的选项 AFL++是一个非常活跃的社区，AFL++会集成社区中、互联网上一些强大的第三方插件，这些集成的插件有一些我们可以通过设置对应的编译选项启用。对于LTO模式（afl-clang-fast/afl-clang-lto）进行编译插桩时，可以启用下面两项比较通用的特性，主要用于优化一些固定值的比较和校验。 Laf-Intel：能够拆分程序中整数、字符串、浮点数等固定常量的比较和检测。考虑下面一个情况assert x == 0x11223344，Laf-Intel会拆分为assert (x & 0xff) == 0x44 && ((x >> 8) & 0xff) == 0x33 ....这样形式，每一次只会进行单字节的比较，这样AFL就可以逐个字节的猜测，每当确定一个字节时，就会发现一个新的路径，进而继续在第一个字节的基础上猜测第二个字节，如此使得模糊器可以快速猜出0x11223344。如果你没有自己制作好的字典、丰富的语料库，这个功能会非常有用，通常建议至少有一个AFL++实例运行Laf-Intel插件。在编译前设置如下环境使用：export AFL_LLVM_LAF_ALL=1 CmpLog：这个插件会提取程序中的比较的固定值，这些值会被用于变异算法中。功能与Laf-Intel类似，但效果通常比Laf-Intel。使用该插件需要单独编译一份cmplog版本的程序，在fuzzing时指定该cmplog版本加入到fuzzing中。具体的用法如下： # 编译一份常规常规版本 cd /target/path CC=afl-clang-lto make -j4 cp ./program/path/target ./target/target.afl 编译cmplog版本 make cleanexport AFL_LLVM_CMPLOG=1CC=afl-clang-lto make -j4cp ./program/path/target ./target/target.cmplogunset AFL_LLVM_CMPLOG 使用cmplog， 用-c参数指定cmplog版本目标，因为cmplog回申请很多内存做映射因此我们设置 -m none，表示不限制afl-fuzz的内存使用。你也可以指定一个值例如 -m 1024，即1GB。 afl-fuzz -i input -o output -c ./target.cmplog -m none -- ./target.afl @@ NOTE：需要注意，两个插件并不是说谁替代谁，往往在实际fuzzing中两者都会用至少一个afl实例启用。 考虑下面两种场景。有时候你想要fuzzing的目标中，他自动的集成了很多第三方的库代码，他们会在编译中一并编译，而你并不想fuzzing这些第三方库来，你只想高效、快速的fuzzing目标的代码，额外的fuzzing第三方代码只会拖慢你fuzzing的效率。有时候你的目标会非常庞大和复杂，他们的构建往往是模块化的，有时候你只想fuzzing某几个模块。这上面两种情况都是我们fuzzing中很常遇见的，所幸AFL++提供了部分插桩编译的功能，即"partial instrumentation"，它允许我们指定应该检测那些内容以及不应该检测那些内容，这个检测的颗粒是代码源文件、函数级两级。具体用法如下： 检测指定部分。创建一个文件(allowlist.txt,文件名没有要求)，需要在其中指定应包含检测的源代码文件或者函数。 1.在文件中每行输入一个文件名或函数 foo.cpp # 将会匹配所有命名为foo.cpp的文件，注意是所有命名为foo.cpp的文件path/foo.cpp # 将会只确定的包含该路径的foo.cpp文件，不会造成意外的包含fun:foo_fun # 将会包含所有foo_fun函数     设置export AFL_LLVM_ALLOWLIST=allowlist.txt 启用选择性检测 排除某些部分。与指定某些部分类似，编写一个文件然后设置环境变量export AFL_LLVM_DENYLIST=denylist.txt以启用，这会跳过我们文件中指定的内容。 Note：有些小函数可能在编译期间被优化，内联到上级调用者，即类似于宏函数展开。这时将会导致指定失效！如果不想受此影响，禁用内联函数优化即可。此外，对于C++由于函数命名粉碎机制，你需要特别的提取粉碎后的函数名。例如函数名为test的函数可能会被粉碎重命名为_Z4testv。可以用nm提取函数名，创建一个脚本筛选出来。 添加Sanitizer检测更多BUG Sanitizer最初是Google的一个开源项目，它们是一组检测工具。例如AddressSanitizer是一个内存错误检测器，可以检测诸如OOB、UAF、Double-free等到内存错误的场景。现在该项目以及成为LLVM的一部分，相对较高的gcc和clang都默认包含Sanitizer功能。由于AFL++基本只会检测到导致Crash的BUG，因此启用一些Sanitizer可以使得我们检测一些并不会导致Crash的错误，例如内存泄露。AFL++内置支持下面几种Sanitizer： ASAN：AddressSanitizer，用于发现内存错误的bug，如use-after-free、空指针解引用（NULL pointer dereference）、缓冲区溢出（buffer overruns）、Stack And Heap Overflow、Double Free/ Wild Free、Stack use outside scope等。若要使用请在编译前设置环境变量export AFL_USE_MSAN=1。更多关于ASAN的信息参与LLVM官网对ASAN：AddressSanitizer的描述(https://clang.llvm.org/docs/AddressSanitizer.html)。 MSAN：MemorySanitizer，用于检测对未初始化内存的访问。若要启用，在编译前设置export AFL_USE_MSAN=1以启用。 UBSAN：UndefinedBehavior Sanitizer，如其名字一般用于检测和查找C和C++语言标的未定义行为。未定义行为是语言标准没有定义的行为，编译器在编译时可能不会报错，然而这些行为导致的结果是不可预测的，对于程序而言是一个极大的隐患。请在编译前，设置export AFL_USE_UBSAN=1环境变量以启用。 CFISAN：Control Flow Integrity Sanitizer，CFI的实现有多种，它们是为了在程序出现未知的危险行为时终止程序，这些危险行为可能导致控制流劫持或破坏，用于预防ROP。在Fuzzing中，CFISAN主要用于检测类型混淆。请在编译前，设置export AFL_USE_CFISAN=1环境变量以启用。 TSAN：Thread Sanitizer, 用于多线程环境下数据竞争检测。在目前，计算机通常都是多核，一个进程中通常包含多个进程，常常导致一个问题，即数据竞争。此类错误通常很难通过调试发现，出现也不稳定。当至少两个线程访问同一个变量，并且同时存在读取和写入的行为时，即发送了数据竞争，若读取在写入之后，线程可能读取到非预期的数据，可能导致严重的错误。请在编译前，设置export AFL_USE_TSAN=1环境变量以启用。 LSAN，Leak Sanitizer,用于检测程序中的内存泄露。内存泄露通常并不会导致程序crash，但它是一个不稳定的因素，可能会被利用、也可能没办法被利用，这不是一个严格意义上的漏洞。与其他Sanitizer的使用不同，需要将__AFL_LEAK_CHECK();添加到你想要进行内存泄露检查的目标源代码的所有区域。在编译之前启用 ，export AFL_USE_LSAN=1。要忽略某些分配的内存泄漏检查，__AFL_LSAN_OFF(); 可以在分配内存之前和__AFL_LSAN_ON();之后使用，LSAN不会检查这两个宏之间区域。 Note： 一些Sanitizer不能混用，而即使有些可以同时允许的Santizier也可能导致意想不到的行为影响fuzzing，这需要结合你fuzzing的目标情况而定。如果你不熟悉Sanitizer的原理，最好一个编译实例中只启用一个Sanitizer，这样通常不会出问题，而且组合Sanitizer不见得会有好效果，基于对目标的了解正确的使用Sanitizer才是最佳的实践。 有些Sanitizer提供了参数设置的环境变量，如ASAN_OPTIONS，如果你有很明确的需求可以设置该变量进一步限制Sanitizer的检测行为，这可能会提高你fuzzing的效率。如果你不熟悉、也没有明确的需求，那么保持默认即可，这通常是最实用的。 启用CFISAN的实例，可能会检测出很多crash(成百上千)，这是正常的，但大多数是无用的，甚至全是无用的，你需要注意甄别。 如果你对目标内部结构足够熟悉，你确定那些区域是线程并发的高发区域，那么你可以结合TSAN与partial instrumentation功能提高TSAN的检测效率，因为启用TSAN的实例通常fuzzing速度会大幅减慢。 通常启Sanitizer后，会大幅减慢fuzzing的速度，CPU每秒执行次数会减少，内存也会被大量消耗(AddressSanitizer会大量消耗内存，甚至可能导致计算机内存耗尽)。如果你的计算机配置不行，请斟酌一个合理的搭配。 一种Sanitizer只应该允许一个实例 。在两个实例上允许两个同样的Sanitizer是一种浪费，因为AFL++会同步所有实例的testcase，其他实例的testcase无论如何都会被该实例上的Sanitizer检测一遍，不应该启用两个相同的Sanitizer检测两遍，这会减慢效率。 暂时只想到这些，以后想到了再补充。 LLVM Persistent Mode In-process fuzzing是一个强大功能，通常比默认常规编译fuzzing的速度快得多，大概快10-20倍，并且基本没有任何缺点。如果可以，请毫不犹豫的使用Persistent mode。众所周知，AFL使用ForkServer来进行每次fuzzing，然而即便不用execve这种巨大的开销，但fork仍然是一笔不小的开。而Persistent fuzzing即一次fork进程种进行多次fuzzing，而无需每次都fork。Persistent mode提供一组AFL++的函数和宏，我们使用下面的形式,用一个while包含我们要进行Persistent fuzzing的区域。请注意，该区域的代码必须要是无状态的，要么是可以手动可靠的重置为初始状态！这样我们才能再每次fuzzing时重置进而再次fuzzing。afl-clang-fast/lto编译的情况下，只需要使用下面的形式即可，但若不是，则复杂一些。AFL++官方的仓库对Persistent Mode花了不小的篇幅讲诉，讲的也比较全面，请在此处Persistent Mode中查阅，我就不做过多描述了。 #include "what_you_need_for_your_target.h"   __AFL_FUZZ_INIT(); int main() { // anything else here, e.g. command line arguments, initialization, etc. #ifdef __AFL_HAVE_MANUAL_CONTROL __AFL_INIT(); #endif unsigned char *buf = __AFL_FUZZ_TESTCASE_BUF; // must be after __AFL_INIT // and before __AFL_LOOP! while (__AFL_LOOP(10000)) { int len = __AFL_FUZZ_TESTCASE_LEN; // don't use the macro directly in a // call! if (len < 8) continue; // check for a required/useful minimum input length /* Setup function call, e.g. struct target *tmp = libtarget_init() */ /* Call function to be fuzzed, e.g.: */ target_function(buf, len); /* Reset state. e.g. libtarget_free(tmp) */ } return 0; } Patch 大多数时候，我们fuzzing一个目标想要其达到我们预期的效果，都需要Patch。并且我们在后续fuzzing流程的持续改进中可能还会发现一些影响fuzzing效率的地方，我们又会倒回来patch，编译重新启动fuzzing。此外，有时候一些校验、检查，它们往往对于fuzzing的结果没有什么影响，但是却严重影响fuzzing的效率。此时我们通常会审查目标内部代码，将这些严重性fuzzing效率的地方Patch，或者是删除。我们都知道Persistent Mode收益十分巨大，但却要求Persistent循环区域内的代码是无状态的，有时候区域会有一些有状态的函数，但他们却并不重要，这时你可以Patch它们，使它们返回诸如硬编码之类可以，这样就变成无状态的，我们就可以使用Persistent Mode了。例如一个区域的输入可能依赖于socket IO读入，而处理socket IO是很麻烦的，因此我们可以考虑将socket fd替换为文件 fd，并patch那些受socket fd受影响区域，以便我们fuzzing正确运行。简言之，Patch最好有明确的理由，随意的Patch对模糊测试来说可能会导致很糟糕的现象，要么你对此处的Patch是基于改进fuzzing效率，要么是为了启用某些有益的fuzzing功能....总之，最好清楚自己的Patch是为了什么。但请注意，对于一次模糊测试来说Patch只是可选的，如果你对自己的工具、目标不甚了解，那么Patch对你而言可能不重要。如果你清楚目标的内部结构，并且明确知道要改进fuzzing的流程和目的，那么Patch可能是你定制化自己fuzzing的一个重要手段。 后续 目前就先写到着，后面的内容，包括build、fuzzing、评估、流程改进等等就放到下篇，最近的工作可能要忙一些其他的。  ...

谷歌宣布，从Chrome浏览器116版本开始，其安全更新频率将从过去的每两周一次压缩为每周一次，以解决攻击者通过补丁更新的时间间隔，利用N Day和0 Day漏洞进行攻击活动。 谷歌表示，Chromium 是一个开源项目，任何人都可以查看其源代码并提交漏洞修复，这些更改、修复和安全更新将添加到 Chrome 的开发版本（Beta/Canary）中，并在将其推送到正式稳定版 Chrome 之前对其进行稳定性、性能或兼容性问题测试。 这一机制虽然有良好的透明度，但也让攻击者有可乘之机，即在这些修复正式推送到稳定版 Chrome的庞大用户群之前在野外利用这些漏洞。 谷歌早在几年前就发现了这个问题，当时补丁间隔平均为 35 天，而在 2020 年，随着 Chrome 77 的发布，谷歌将间隔缩短为每两周更新一次， 通过压缩到每周的更新，Google 进一步缩短了补丁间隔，并将N Day漏洞的利用窗口机会减少到一周，从而可以有效阻止需要更复杂利用路径的漏洞利用。这无疑会对 Chrome 的安全性产生积极影响，但仍不能避免攻击者使用已知技术对某些漏洞进行有效利用。 需要注意的是，Android的生态系统让谷歌难以控制，很多情况下，谷歌发布的补丁需要几个月的时间才能将其引入第三方厂家生产的设备中。 参考来源：Google to fight hackers with weekly Chrome security updates ...

据公安部召开的新闻发布会获悉，3年来公安部部署全国公安机关开展“净网”专项行动，严打侵犯公民个人信息违法犯罪活动，锚定行业内部泄露源头，重拳打击行业“内鬼”，共抓获电信运营商、医院、保险公司、房地产、物业、快递公司等行业“内鬼”2300余名。 公安机关开辟网络空间新战场，“打源头、摧平台、断链条”，全环节摧毁犯罪生态。锚定技术类侵犯公民个人信息犯罪源头，发起打击黑客犯罪集群战役，侦破一批利用木马病毒、钓鱼网站、渗透工具、网络爬虫等黑客手段窃取公民个人信息案件；锚定行业内部泄露源头，重拳打击行业“内鬼”，2020年以来共抓获电信运营商、医院、保险公司、房地产、物业、快递公司等行业“内鬼”2300余名；锚定买卖公民个人信息的重点网络平台，抓获了一批数据中间商和物料供应商；紧盯ChatGPT、云计算、区块链、“AI换脸”等新技术、新应用、新业态，侦破一批利用人工智能技术侵犯公民个人信息的新型案件；循线深挖下游犯罪线索，连带破获大量电信诈骗、套路贷、网络盗窃、网络洗钱等违法犯罪案件，形成“以点带面，全面开花”的打击态势。 公安部聚焦人民群众“急难愁盼”，深入开展专项整治。针对快递信息泄露引发电信诈骗的问题，公安部会同中央网信办、国家邮政局联合开展为期6个月的邮政快递领域个人信息泄露治理专项行动，期间共侦破窃取、贩卖快递信息案件206起，抓获犯罪嫌疑人844名，其中快递公司内部人员240名。针对“AI换脸”导致群众被欺诈的问题，公安机关发起专项会战，侦破相关案件79起，抓获犯罪嫌疑人515名。针对装修、贷款等骚扰电话的问题，公安机关联合工商部门开展专项整治，惩处了一批非法买卖公民个人信息的金融公司、装修公司、物业公司和房地产公司，循线打掉多个电话推广犯罪团伙。 此外，构建协同作战机制，打造综合治理格局。依托“净网”专项行动，公安部与中央网信办、最高人民法院、最高人民检察院、工业和信息化部等相关单位建立了长效合作机制，从严厉惩治犯罪、突出重点整治、加强行业监管、规范依法办案、开展宣传教育等多方面协同推进，形成了保护公民个人信息和数据安全的工作合力，构建起源头治理、综合治理、系统治理的工作格局。 本文来源：北京日报 ...

近日，国内多家媒体相继发文称，前 58 员工透露集团内部借助招聘名义，倒卖大量学生简历，此事一经爆出迅速引起社会讨论。随着此事热度不断上升，网友陆续扒出  58 集团在收集到大批学生简历后，高价卖给培训机构，以此收取返利。 网易财经披露 58 集团打包售卖的简历均来自其在 2015 年收购的新华英才招聘平台，该平台主要面向的用户群体是大学生，目前收录了约 200 万份简历。整个简历倒卖过程中，58 集团会根据学生层次对简历“分门别类”，以每份 30-2000 元不等出售，其中博士生简历高达1500元每份。据悉，建立购买方包括某巨头物流公司、饮料行业独角兽及企政单位在内的近 20 家企业，依照这种”模式“，58 集团一年多来牟利高达 200万元。 对于网传倒卖用户简历一事，58 客服回应称58 不会向任何人提供任何信息，也不会倒卖信息，不会存在任何的违规、违法操作。 招聘方倒卖用户简历事件屡禁不止 事实上，58 集团并非是首家被曝参与倒卖用户简历的招聘网站，2019 年 7 月，北京市朝阳区人民法院审理了一起“智联招聘“员工参与倒卖个人信息案。 从披露的案件详情来看，2016年，郑某通过朋友认识了智联招聘的员工卢某，两年后，卢某告诉郑某，自己有便宜的“套餐”，一份简历 4.5 元，一个企业客户的账号可以有 2800 份简历，但是需要提供企业的营业执照才能获得账号。 于是乎，为谋取钱财，郑某伪造了营业执照，在智联招聘员工卢某和王某处购买账号以获得简历后，每份简历加价 1 元到 1.5 元在淘宝上销售，直到案发，共倒卖了约 16 万余份用户简历，产生极其恶劣的社会影响，同时也给智联招聘带来负面新闻。 对于员工倒卖用户简历一事，智联很快就发布声明表示对由此给用户带来的困扰道歉，强调接下来智联官方会对信息欺诈、侵犯个人信息的违法行为，实行严厉查处和坚决打击。 国内权威媒体也曾多次招聘方倒卖用户简历。2021 年 央视“3·15”晚会上就曝光了猎聘、前程无忧、智联招聘等多家招聘平台存在出售用户简历的情况。央视指出智联招聘上的企业账户只要交钱办理会员，就可以不受数量限制下载包含姓名、电话及邮箱地址等关键信息的用户完整简历，在前程无忧和猎聘网上，企业账户同样只需支付费用，便可以下载到求职者的完整简历。 央视“3·15”晚会曝光后，智联招聘、前程无忧、猎聘三家招聘平台连夜发布了道歉声明，并一再强调集团内部已经采取相应措施，升级技术手段，联合起来抵制一切侵犯用户权益的不法行为，杜绝此时事件发生。 倒卖简历严重我国违反法律法规 无可争议，现阶段大多数公民求职都是要通过招聘网站，因此简历就成了不得不”交出“的资料，同时简历中又包含了姓名、出生日期、住址、电话、电子邮箱、身份证号码、甚至是个人特长等敏感用户信息，一旦”有心人“想要利用这些信息，用户无疑处于”裸奔“状态。 但现实情况是，国内倒卖简历非常猖獗，不法分子潜伏在微信、微博、QQ 群、知识、百度贴吧等社交媒体平台上，偷偷售卖简历。想要购买简历的人员只需输入“简历”、”投递“、”招聘“等关键词，就可以很轻松找到大量销售简历的地址链接。 那么倒卖简历违法吗？当然违法！根据《刑法》第二百五十三条之一，违反国家有关规定，向他人出售或者提供公民个人信息，情节严重的，处三年以下有期徒刑或者拘役，并处或者单处罚金；情节特别严重的，处三年以上七年以下有期徒刑，并处罚金。 此外，根据《中华人民共和国个人信息保护法》第十条、第二十一条，任何组织、个人不得非法收集、使用、加工、传输他人个人信息，不得非法买卖、提供或者公开他人个人信息；不得从事危害国家安全、公共利益的个人信息处理活动。 《中华人民共和国数据安全法》在第五十一条同样规定窃取或者以其他非法方式获取数据，开展数据处理活动排除、限制竞争，或者损害个人、组织合法权益的，依照有关法律、行政法规的规定处罚。对于违反规定，给他人造成损害的，依法承担民事责任。违反本法规定，构成违反治安管理行为的，依法给予治安管理处罚；构成犯罪的，依法追究刑事责任。 招聘网站作为承接求职者与用人单位之间的桥梁，应时刻牢记简历中包含大量求职者的敏感个人信息，这些信息应该得到妥善保护并仅限于被用于招聘目的，将用户简历售卖给第三方，无论是出于商业利益还是其他目的，都是不道德且违法的行为。 对于求职简历安全问题，相关招聘平台和公司应足够重视，加强对用户数据的保护措施，加强内部监管和员工教育，杜绝将用户简历用于非法交易的行为，切勿因小利，”砸了“自己的招牌。与此同时，政府和监管机构也应加强对招聘网站的监管，制定和执行更严格相关法律法规，加大对售卖用户简历等违法行为的打击力度。 参考文章： https://baijiahao.baidu.com/s?id=1694319691515484518&wfr=spider&for=pc https://www.yuncaijing.com/news/id_13041120.html ...

提醒所有电商人：不干了就把链接下架，别被薅羊毛了。 关注Kirin博客的人都知道，虽然Kirin博客不做电商，但我还是有好几个店铺的。6月份我的某一个僵尸店铺就被一个人薅羊毛了。 事情是这样的： 我有一个僵尸店铺，一直上架的有产品，销量0的店铺。这哥们拍了产品后，就投诉了。投诉的理由是“未按约定时间发货”。 确实也是我们的疏忽，我和同事都没有登录千牛。就这样被投诉之后，淘宝扣了我100元保证金给了该用户。等真正扣钱的时候，我们才反应过来，但为时已晚。 后面我在网上搜索了一下，发现这事都快成产业链了。有的人注册了很多新帐号和支付宝帐号，大概率是开了某种可批量筛查店铺链接的软件，然后批量下单投诉。 除了软件，他们也会有问发什么快递的，如果没人搭理他也会下手。 后来松松在网上一搜，发现很多店主都有类似遭遇，有一个哥们他说呗搞了40多单，40多个不同的ID，同时进行的。另一个人也如此：半夜同时下了30几个单，一个单200多点，可以投诉，不会因延迟发货/不发货被扣款、处罚，第二天他们就申请退款了。 所以，在这里也提醒大家，店铺的商品不干了，最好下架，否则被薅羊毛了。...

...

  “丝绸之路”（Silk Road）和恐怖海盗罗伯茨（Dread Pirate Roberts）的时代可能已经过去，但暗网毒品市场似乎一如既往地盛行。随着2022年俄罗斯九头蛇Hydra市场的崩溃，我们探讨了2023年暗网毒品市场的状况。 什么是暗网，它是如何运作的？ 对于那些不太熟悉暗网及其各种暗网市场运作方式的人，请允许我解释一下…… 如果把互联网想象成一座冰山，那么我们现在所处的表层网络就是冰山的一角。表层网络仅占整个网络的4%，是人们最熟悉的部分。表层网络包含可通过搜索引擎（例如谷歌）访问的网络部分。然而，许多人没有意识到，网络的范围远远不止于此。 表层网络之下的一层是深层网络。这部分网络无法被传统搜索引擎访问，因此也不会被网络爬虫抓取。要访问深层网络中的网页和信息，用户需要正确的授权和凭证。 然而，仅仅因为网页存在于深层网络中并不意味着它是有害的。这一层中存在许多无害的项目，例如未发表的博客文章、存档的新闻报道和付费专区的文章。 深网之下是暗网（darknet，darkweb），由于其不可搜索、加密和私密的性质，为用户提供了完全的匿名性，因此访问起来更加困难。 暗网确实有一些合法用途，包括私人通信和保护机密资源。尽管如此，暗网可能因其托管丝绸之路等毒品市场、黑市和网络攻击服务而更为人熟知。其设计本身使暗网成为犯罪活动的热点，因此暗网已成为这部分网络的代名词。 洋葱路由器（TOR） 由于无法通过表面网络访问暗网，用户需要使用一种称为洋葱路由器（或TOR）的软件才能访问暗网。TOR最初由美国政府创建，是一种匿名浏览器，允许用户进入暗网并匿名化其身份。使用加密货币在暗网上进行交易，可以增加这一层的安全性和匿名性。 暗网毒品市场 暗网最广为人知的功能之一可能就是托管大规模毒品市场。最明显的莫过于2010年初“丝绸之路”市场的崛起，“丝绸之路”由罗斯·乌布里希特（Ross Ulbricht，又名恐惧海盗罗伯茨）创立，出售种类繁多的物品，但却是一个臭名昭著的毒品市场——2013年春季，毒品占所售商品销售量的70%。据估计，丝绸之路在其鼎盛时期价值3450万美元。在罗斯·乌布里希特被FBI逮捕后，丝绸之路最终于2013年10月被联邦调查局关闭。 最近，2022年又见证了另一个著名暗网毒品市场的衰落。俄罗斯暗网市场“九头蛇市场”（Hydra Market）于2015年推出，以毒品贸易等而闻名。Hydra市场逐渐发展成为暗网最大的市场之一，约占暗网活动的80%，拥有1.9万个卖家账户和1700万客户。从毒品销售方面来看，Hydra市场成为前苏联国家中最大的毒品市场。2022年4月，Hydra市场被德国警方关闭，遭遇了与丝绸之路类似的灭顶之灾。 2023年暗网毒品市场的情况 2022年Hydra市场消亡后，出现了数十个新的暗网市场，其中一些是针对前Hydra客户和供应商的暗网毒品市场。 根据来自多个安全信息来源的研究（flashpoint，chainalysis），Hydra市场关闭后，多个市场成为新的参与者，轮流引领暗网毒品市场。在运营第一个月结束时，OMG! OMG!市场的销售额已达到约1215万美元。与Hydra市场类似，许多俄罗斯暗网市场的排名也有所上升，其中最大的似乎是Mega暗网市场，仅3月份就获得了4000万美元的收入。紧随其后的是Blacksprut市场，获得约2000万美元的收入。 由于加密、匿名和隐私是暗网及各种暗网毒品市场设计的核心，因此很难获得有关毒品趋势的最新信息。《2023年世界毒品报告》的分析表明，虽然买家在毒品交易上的平均花费在增加（从2018年每笔交易100美元增加到2021年每笔交易500美元），但活跃买家和交易数量却明显减少。 有趣的是，社交媒体作为新兴毒品市场的崛起也影响了购买趋势。自我报告的数据表明，社交媒体平台已成为大麻、摇头丸和可卡因低级交易的有利平台，而新型精神活性物质在更大程度上仍通过暗网进行销售。 至于暗网毒品市场的销售对象，似乎也发生了变化。对于大多数市场来说，传统的买家最终是所售产品的最终用户，但专家认为，暗网毒品市场正开始转向批发。活跃市场、参与者和交易数量的减少，与暗网总体销售额和平均交易额的增加形成鲜明对比，表明供应商可能转而向药品分销商销售，或者扩大了产品和服务范围。 综上所述，2023年的暗网毒品市场面临着许多挑战——然而，尽管面临这些挑战，它们的反弹能力清楚地表明它们不会在短期内消失。“低水平”毒品交易社交媒体的兴起表明，暗网毒品市场将继续调整其应对措施，重点关注毒品批发分销商，而不是最终消费者。...

国内设备 华为（Huawei）： 华为S5720系列 华为S5700系列 华为S6700系列 华为S9300系列 中兴（ZTE）： 中兴S3300系列 中兴S3500系列 中兴S3900系列 中兴S5900系列 烽火（Ruijie）： 烽火RG-S2900G-E系列 烽火RG-S5750E系列 烽火RG-S7700系列 烽火RG-S9250系列 TP-Link： TP-Link JetStream T1600G系列 TP-Link JetStream T2600G系列 TP-Link JetStream T3700系列 TP-Link JetStream T4800系列 国外设备 Cisco： Cisco Catalyst 2960 Series Cisco Catalyst 3560 Series Cisco Catalyst 3850 Series Cisco Catalyst 4500 Series **HPE (Hewlett Packard Enterprise)**： HPE OfficeConnect 1920S Series HPE ProCurve 2520 Series HPE FlexNetwork 5130 Series HPE Aruba 2930F Series Dell： Dell Networking X-Series Dell Networking N-Series Dell PowerConnect 2800 Series Dell PowerConnect 5500 Series Juniper Networks： Juniper EX2200 Series Juniper EX2300 Series Juniper EX3400 Series Juniper EX4300 Series NETGEAR： NETGEAR ProSAFE GS108T NETGEAR ProSAFE GS724T NETGEAR ProSAFE JGS524E NETGEAR ProSAFE XS708E ...

随着企业和机构对更快、更稳定网络连接的需求不断增长，千兆交换机的SFP口在现代网络中扮演着关键角色。 以下是SFP口在现代网络中的几个关键应用： 数据中心网络： 在数据中心中，快速且稳定的数据传输至关重要。SFP口允许数据中心管理员根据不同的需求配置网络连接，以满足服务器之间高速数据交换的要求。 广域网连接： 通过SFP口，网络管理员可以选择合适的SFP模块，实现数据在远距离范围内的传输，适用于跨越城市、国家甚至大洲的广域网连接。 光纤网络： 光纤作为高速数据传输的理想媒介，通过SFP口连接的光纤模块可以在网络中提供出色的性能，满足高带宽和低延迟的要求。 网络冗余： SFP口也为实现网络冗余提供了可能性。通过配置冗余链路，即使一个链路发生故障，另一个链路仍然可以保持网络连接，确保网络的可靠性。 未来扩展： 随着技术的不断进步，新型的SFP模块不断涌现，支持更高的传输速率和更大的带宽。这使得网络可以更容易地进行未来扩展，以满足不断增长的网络需求。 总之，千兆交换机的SFP口作为现代网络中的重要组成部分，为网络管理员提供了灵活性、可升级性和可维护性。它不仅满足了不同网络需求的要求，还为网络的稳定性和可靠性做出了重要贡献。随着技术的不断发展，SFP口将继续在网络领域发挥重要作用，推动网络连接速度和性能的提升。 ...

小尺寸和高密度： SFP模块的尺寸只有GBIC的一半，这使得它们可以在更狭窄、更密集的空间中使用。在现代数据中心和网络设备中，机架空间的利用率至关重要，因此SFP模块的小尺寸使得设备能够容纳更多的端口，从而提高了网络连接的密度。 热插拔性质： SFP模块的热插拔性质使得网络管理员可以在设备运行时更换或添加模块，而无需关闭设备。这大大减少了维护和升级过程中的停机时间，提高了网络的可用性。 灵活性： SFP模块可以支持多种不同类型的传输媒介，包括光纤和铜缆，以及不同的传输速率。这种灵活性使网络管理员能够根据网络需求选择合适的模块，以满足不同连接的要求。 长距离传输： SFP模块支持多种传输距离，从短距离到长距离，甚至远达数十千米的距离。这使得它们在构建广域网连接和远距离传输时非常有用。 ...

厌倦了窗口混乱和手动调整？ GNOME 正在集体讨论一个自动化且用户友好的窗口管理系统。这是你需要了解的情况。 窗口管理是桌面计算的一个重要方面，几十年来一直是人们着迷和探索的话题。然而，尽管进行了多次尝试，仍然没有人能够破解完美的窗口管理解决方案的密码。GNOME 开发人员现在开始致力于彻底改变窗口管理，旨在提高生产力和用户体验。 GNOME 开发人员 Tobias Bernard 发表了一篇 ，介绍了开发人员如何考虑为未来创新 GNOME 桌面。 传统窗口系统的挑战 传统的窗口系统为我们提供了很好的服务，允许应用生成可以手动移动和调整大小的矩形窗口。然而，随着窗口数量和尺寸的增加，问题开始出现。重叠的窗口很快就会变得一团糟，使得在不隐藏其他应用的情况下访问特定应序变得困难。最大化窗口可能会遮挡桌面上的其他所有内容，从而导致混乱和效率低下。 多年来，各种操作系统引入了工作区、任务栏和切换器等解决方法来处理这些问题。然而，窗口管理的核心问题仍未解决。特别是对于儿童和老年人等计算机新手来说，手动排列窗口可能会很麻烦且乏味。 引入平铺窗口管理器 平铺窗口管理器提供了防止窗口重叠的替代解决方案。虽然它们在某些情况下运行良好，但也有其局限性。平铺窗口可能会导致效率低下，因为应用通常是针对特定尺寸和纵横比设计的。此外，这些窗口管理器缺乏关于窗口内容和上下文的知识，需要额外的手动调整，并违背了简化工作流程的目的。更不用说记住很多键盘快捷键了。 GNOME 当前的平铺功能 GNOME 已经在 GNOME 3 系列中尝试了基本的平铺功能。然而，现有的实现有一些局限性。这是一个手动过程，仅支持两个窗口，缺乏复杂布局的可扩展性，并且不会将平铺窗口分组到窗口栈中。 窗口管理的新愿景 该团队提出了一种新的窗口管理方法，重点关注符合用户期望和需求的自动化系统。他们的概念涉及窗口的三种潜在布局状态：马赛克、边缘平铺和浮动。 马赛克模式将成为默认行为，根据用户偏好和可用屏幕空间智能定位窗口并调整窗口大小。随着新窗口的打开，现有窗口将进行调整以适应新来者。如果窗口不适合当前布局，它将被放置在自己的工作区中。当屏幕接近布满时，窗口将自动平铺。 用户还可以通过将窗口拖动到现有窗口或空白区域上来手动平铺窗口。该系统提供了灵活性和便利性，使其更容易高效地执行多任务。 维护用户友好的浮动窗口 虽然平铺提供了多种好处，但 GNOME 开发人员明白，总会有用户更喜欢手动定位窗口的情况。因此，经典的浮动行为仍然适用于这些特定情况，但随着新的马赛克系统的引入，它可能不太常见。 利用窗口元数据增强性能 GNOME 旨在优化平铺体验，以从窗口收集有关其内容的更多信息。这包括窗口的最大所需尺寸以及应用最佳运行的理想尺寸范围等详细信息。通过使用这些元数据，系统可以定制窗口布局以满足用户的需求，从而提高整体可用性。 展望未来 虽然 GNOME 开发人员对这个新的窗口管理方向感到兴奋，但他们也承认与这种新颖方法相关的风险。他们计划进行用户研究以验证他们的假设并完善交互。尽管没有具体的实施时间表，但该项目可能会跨越多个开发周期，并成为 GNOME 46 或更高版本的一部分。 截至发布此内容时，还没有草案合并请求，你可以参与其中并提供反馈。 ...

地理位置：选择靠近目标用户群体的国外服务器位置是至关重要的。若用户主要集中在中国以外的地区，因您应选择位于用户所在地附近的服务商，以确保视频的传输速度。 带宽和速度：选择带宽足够且方便升级的服务商，以保证视频的传输速度。考虑选择双线或多线云服务器机房，这能提高视频网站用户的访问速度。 攻|击防御： 考虑攻|击性问题，根据自身实际情况选择高防云服务器来防御可能的攻|击。 处理器性能：选择具有卓越处理器的服务器，特别是如果您的网站加载了CPU密集型脚本。 存储容量：选择存储容量足够的服务器，以满足视频网站对存储资源的需求。 带宽和流量：在建设视频网站时，首|选大带宽服务器，以确保足够的带宽和流量支持。 不限制流量：对于内容要求不严格的视频网站，建议选择不限制流量的服务器，以确保用户能够自由地访问和观看视频。 类型和配置：确保服务器的配置能够处理大量并发数据，并满足视频网站对处理能力和网络需求的要求。 网络稳定性：选择网络稳定性较高的境外服务器类型，根据网站业务分布范围和受众群体所在位置进行考虑。 文件传输和储存：对于视频网站，考虑选择具有较大储存容量和传输速度的服务器，以便存储和传输大量的视频文件。 通过考虑这些因素，选择适合视频网站需求的国外服务器，将能够提供稳定的传输速度、高质量的视频播放体验，以及更好的用户体验。 ...