大家好，这一期我向大家介绍下，网络方面的故障吧，一起来学习下。网络大部分的故障都是借助TC工具实现的，因此请先确保OS上已安装TC工具，Atlas 产品可能存在TC工具无netem模块(注入时提示：“Error: Specified qdisc not found”，因为 Atlas的Euler OS经过裁剪，无sch_netem.ko的内核模块)，请从CMC下载相应发行版本OS的 编译环境包，并在包中找到对应的sch_netem.ko模块，并手动加载该模块，即可使用TC的 netem模块功能，进行网络包相关的故障注入。网络错包网络错包指定时长网络包延时网络包延时指定时长网络丢包网络丢包指定时长网络包重复网络包重复指定时长网络包乱序网络包乱序指定时长网卡 Down 掉网卡性能劣化端口占用停止网络服务网络链路闪断网卡带宽受限TCP 端口占用网络驱动故障这一期Linux OS 关于网络故障的内容我们就先介绍到这，下一期我们介绍下进程方面的故障，敬请期待~

 时间倒回二十年前。1993 年，那时候 BSD 正处于水深火热，Linux 刚诞生没多久，Meta 杂志 问 Linus Torvalds：能不能推测一下 Linux 在市场上对 Unix 的影响？当时，Linus 的回答是：I have gotten various mails and seen some newsgroup messages about persons who have switched over already or would like to switch over once Linux is able to run commercial binaries, but at least so far, I doubt Linux has dented the real Unix market very much.尽管我已经看到一些人已经或者想要切换到 Linux，用于运行商业二进制文件。但目前为止，我不认为 Linux 已经严重削弱了 Unix 的市场。彼时，Linux 初出茅庐，尽管锋芒毕露，但谁也不知道以后到底会发生什么。须臾二十年，形势调转，Linux 现在的地位有目共睹。另一边，BSD “灾后重建”且大受欢迎的 386BSD 因为内部意见不同出现问题，其中三个补丁包协调员 Nate Williams、Rod Grimes 和 Jordan Hubbard 另起炉灶，于 1993 年创建了 FreeBSD。尽管还有 NetBSD 和 OpenBSD，但后来的事实证明，FreeBSD 发展最好、走得最远，是 BSD 世界里的“扛把子”。在之后的日子里，FreeBSD 没能重现 BSD 的往日荣光，反而一直生活在 Linux 的阴影之下。“Linuxism” 成为 FreeBSD 内部常常挂在嘴边的一个词，其中透露出酸酸的比较之味。一方面，FreeBSD 坚定地沿袭 Unix 的一些传统，坚决地想要与 GNU/Linux 保持距离；另一方面，FreeBSD 也在积极地寻求更长足的发展，想要至少在某些方面保持优势。 世事如棋局，得势者得天下。以势定夺，怎么看 FreeBSD 领到的剧本都是一个“大败局”。 01 成也 BSDL，败也 BSDL 正是我们的许可证，使得我们独一无二。与 GPL 尤其是 GPLv3 相比，BSDL（BSD 许可证）对很多厂商来说是非常重要的。2021 年 3 月，FreeBSD 13.0 版本最新发布。在一场采访中，FreeBSD 内核开发者 John Baldwin 如是说。他说得没错。许可证是 BSD 一族与 GNU/Linux 最显著的不同，它彰显了 FreeBSD 所继承的、与 RMS 提倡的 “Free” 完全不同的 “Libre” 哲学态度，使得以 FreeBSD 为代表的这些开源软件自成一派。在 GNU 理念里，软件本该自由，专有软件不应该存在。因此，GPL 被设计得具有传染性，并且要求所有修改后的代码都要返回上游，当初 Linus 选择 GPL 正是看重后面这一点。而 BSDL 则更接近于“公共领域”（公共领域的作品属于公有文化遗产，任何人可以不受限制地使用和加工它们），几乎给了使用者最大权限的自由，不但可以自由地使用、修改源代码，不需要返回任何修改，还可以将修改后的代码作为开源或者专有软件再发布。我们并不认可 GPL，它是一种政治宣言。我们想要将我们的许可证与政治分开。 GPL 会吓跑很多潜在用户，这只会适得其反。—— FreeBSD 创建者之一 Jordan Hubbard因此，在之后的实践中 FreeBSD 也在竭力与 GPL 划清界限。多年来，FreeBSD 一直致力于删除基础设施中的 GPL 软件，以便“迁移到现代的、CopyFree 以及许可更宽松的组件”。比如：用 LLVM 的 LLDB 替代 GDB 调试器、使用 BSDgrep 替代 GNUgrep，以及删除 libgnuregex 等等。（其中，FreeBSD 为了完成向 LLVM 的迁移，花费了十年左右的时间，因为 LLVM 是在 Apache 2.0 下获得许可，限制比 GPL 更少。） FreeBSD 的这种身份主张无可厚非，但从现实层面来考量这两个许可证，就是另一码事了。阮一峰老师在《为什么 GPL 是更好的开源许可证？》一文中作了逻辑阐述：当程序员放弃代码的版权，或者选择 BSD 许可证，他可能认为自己做出了世界上最无私的行为。很大程度上，事实确实如此。但是，我们要知道，这个世界是一个商业利益占主导的世界。一旦发生像甲骨文拥有 MySQL 这一类的事情，你的代码的价值将大大削弱，大公司先是免费利用它们，然后再设法推出取代它们的私有产品。你以为自己奉献了爱心，但是实质上变成了为大公司无偿打工。从这个角度看，GPL是更好的开源许可证。它保证了自由始终是自由，既无法被剥夺，也不是一种圈套或陷阱。 FreeBSD 的贡献者就常常被调侃为 Apple 公司的无薪员工。Apple 将社区工作都纳入了 FreeBSD，在其基础上进行了一些更改，就变成了一个专有的、非自由的操作系统。糟糕的是，Apple 还对内核和其他部分进行了分叉，并将其命名为 Darwin，这一系统基本就远离了 FreeBSD 的传统。而且，由于 Apple 支付了版税，他们可以合法地将其称为 Unix，但这笔钱也没有流向 FreeBSD。更过分的是，相较于 Netflix 等，同样是 FreeBSD 受益者，Apple 为上游做贡献的积极性也不足（因为 BSDL，贡献上游这事就全凭自觉了）。但 FreeBSD 的人对此倒也看得开：“我不会因此而责怪他们。FreeBSD 是一个 BSD 许可的项目，而不是 GPL。”John Baldwin 表示。BSD 许可证就是一个复制中心，可以为所欲为，但我们不在乎。—— Marshall Kirk McKusick ，他亲身参与了 4.3BSD 和 4.4BSD 的开发和发行，后来又深度参与了 FreeBSD因为 GPL，这种事永远不会发生在 Linux 身上。在 GPL 许可下，任何人都可以使用 Linux，但是有一个强制要求，如果修改后的版本要出售或者提供给他人，则必须根据相同的 GPL 许可把完整源代码对外发布。如此一来，GPL 可以确保 Linux 永远不会成为专有产品，所有开发者做出的贡献最终会回到社区，Linux 可以得到更好的发展。在 Linus 眼里，GPL 就是他想要的，而不是 BSDL。许可证是 Linux 成功的决定性因素之一，因为它强制你必须回馈。如果你真的想创造更大的东西，如果你想围绕它创建一个社区，BSD 许可证不一定是很好的许可证。它（BSDL）会让开发人员觉得大公司在利用他们的工作。 02 “好东西都给 Linux 了”Linux 赶上了好时候。Internet 开始风行之际，Linux 的开发者及爱好者正好能透过 Internet 实时地发布新闻、想法、提问、讨论、递送程序代码及进行错误回报。这种由 Internet 连接起来的分布式合作方式带给了 Linux 惊人的活力。这种生命力直接将 Linux 送上了可以与 BSD 分庭抗礼的位置。与此同时，在 Linux 现身之时，刚好是人们开始买得起个人计算机时。那是还没从诉讼中缓过劲的 BSD 对于当时的个人计算机所使用的 80386 硬件的支持度非常不好，Linux 几乎成为当时大众的第一选择。这一波路人缘，Linux 收割得很漂亮。BSD 缺位，Linux 趁机发展，刚从灰烬里重生的 FreeBSD 碰上的局面就很残酷：Linux 占据主导地位之后，已经形成马太效应，之后的态势呈现出强者愈强、弱者愈弱的趋势。 硬件方面，Linux 可以在许多不同的平台上运行，而 FreeBSD 则不行。硬件设备制造商更愿意为 Windows、Linux 等主流的操作系统提供驱动程序，IBM、戴尔和惠普直接支持在其服务器上运行 Linux，但处于主流之外的 FreeBSD 可能不在它们的考虑范围内。此外，Linux 的开发者数量比 FreeBSD 多出数倍，这意味着 Linux 拥有更多的贡献者和测试新硬件的机会。长期下来，最终导致 FreeBSD 的兼容性和硬件支持远远不如 Linux。比如，用户需要定期更新图形驱动程序，Linux 可以更早、更快地提供支持。软件上，Linux 软件包存储库的数量远超过 FreeBSD ，具有更大的灵活性和可用性，虽然 FreeBSD 也提供了预编译的软件包，但它仍然无法与 Linux 可用的资源进行比较。其实，这都是互为因果关系的 —— 因为 FreeBSD 市占率比 Linux 低多了，开发者少，很多软件对其的支持度就不如 Linux，这又反过来加剧了其市占率的下降 —— 一个死循环。有人评论很是贴切：“所有的好东西都给了 Linux”。看着 FreeBSD 如今的现状，用户都着急了。2020 年 3 月，一些用户开始在推特上催促 FreeBSD 基金会尽快赞助 FreeBSD，以推进对 802.11ac 支持的开发工作。要知道这个时候， Windows 和 Linux 都提供了对 802.11ac（"WiFi 5"）的良好支持，并且已经开始将重心放在 802.11ax （"WiFi 6"）上了。当时面对呼吁， FreeBSD 基金会进行回复的截图 03 FreeBSD 没有商业布局Linux 内核是个操作系统“半成品”，企业支持的重要性不言而喻。支持 Linux 的著名企业有 RedHat 、SUSE、IBM 、Canonical 等等，它们不仅贡献了许多实用性很强的发行版，如 Fedora、Ubuntu、Arch Linux、Debian、Linux Mint 等，同时确保操作系统实现快速更新。有人认为， RedHat 是 Linux 快速进入商用市场的关键性因素之一。因为对于大型企业而言，或许授权费用的多寡并不是重点，他们要的是能够说服上司及股东的解决方案。透过 RedHat 所提供的技术支持，信息部门有了底气将 Linux 列入解决方案之中。这项优势几乎是 FreeBSD 所难以匹敌的，因为 FreeBSD 几乎没有商业支持。开箱即用的 FreeBSD 提供了用于强化系统的选项因为缺乏商业公司运作的商业版本，为 FreeBSD 提供支持的企业屈指可数，没有大量企业为终端用户提供大规模的技术和服务支持。在 FreeBSD 13 发行之后的那场采访中，当被问及商业模式问题时，John Baldwin 这样回答：有很多来自像 Netflix 这样的公司，内部会有FreeBSD 专家团队开发功能，这些工作直接进入上游 FreeBSD。还有一些资源来自学术和业余爱好者。最近越来越多的工作由 FreeBSD 基金会承担，基金会接受捐赠资助。可以看出，一些接受了 FreeBSD 恩惠的企业的确在以某种方式去推动 FreeBSD 的生态发展，但与 Linux 所得到的商业支持，完全不能相提并论。就像有人说得那样：“尽管 Netflix、Apple 和 Juniper Networks 等公司都在支持 FreeBSD，但它们并没有像 Canonical 和 RedHat 等公司那样投资它，共荣共生的传奇只发生在了 Linux 上 。” 04 “大独裁者”未必是坏事One of the major problems with 386BSD seems to be the lack of co-ordination: that may sound weird coming from the Linux background, but in fact the 386BSD project seems to suffer from a lot of people working on the same thing due to the long release cycle.The NetBSD project may be a step in the right direction, but I think 386BSD has been hurt by the way it has been developed.386BSD 的主要问题之一似乎是缺乏协调管理：尽管我以 Linux 的角度和身份来看很奇怪，但事实就是这样，因为较长的发布周期，386BSD 里大量的人都在做同一件事情。NetBSD 可能走对了方向，但是 386BSD 已经因为这种开发方式受到了伤害。1993 年，Linus 一语成谶。很快，386BSD 分裂成为 FreeBSD 和 NetBSD。当时有人总结到：“BSD 走的是教堂式的学院派路线，而 Linux 则是代表了市集式的骇客精神。” Linus 是著名的独裁，而 BSD 对“独裁者模式”的嗤之以鼻是一以贯之的。有一个古老的笑话是这样的：如果你把 10 个 BSD 开发人员锁在一个房间里，当你打开门时，你会发现比萨饼不见了，BSD 开发人员死了，还有 11 个 BSD 的新变种。虽然有点自负，但我认为只要我愿意充当傀儡，我本可以阻止社区分裂。当时我在那个位置上已经 10 多年了，我觉得是时候将衣钵传给他人了。老实说，我没想到会这样（指分裂），我以为会出现很多不同发行版而已。McKusick 曾这样表示。在他看来，Linux 的独裁者模式一样不可取，一旦 Linus Torvalds 离开，就会酿成灾难，Linus 在试图创造超越他自身的一些东西，而“如果我被公共汽车撞了， BSD 不会真正受到太大影响。”这样左派又带点傲气的观点，真是典型的 BSD 的啊。而 FreeBSD 之后出现的管理和开发方式问题，多多少少也带了一些遗传在身上。 从开发过程上看，FreeBSD 与 Linux 最大的不同就是 —— 没有一个大独裁者。FreeBSD 有一个核心团队，相当于公司里的董事会，他们通过授予、撤销修改、提交新代码到代码库等权利来控制访问，其首要任务是确保整个项目处于良好状态并朝着正确的方向前进，并每 2 年选举一次。“我们主要用邮件列表进行协作，这与 Linux 内核邮件列表相同。但是，FreeBSD 基础系统是一个单一的存储库，内核、C 库以及工具链，所有基础系统实用程序，如 ls 和 shell，都在一个单一的存储库中，一起构建和发布。” FreeBSD 基金会项目开发总监 Ed Maste 在 2021 年表示。这种“核心小组”型的模式最大的缺点就是很难达成共识，从而延误时机。FreeBSD 核心团队成员 Benno Rice 就曾探讨过这个问题：开发项目的源代码是其核心资产，必须妥善保管。所以项目需要一个源代码管理系统。最初，FreeBSD 使用 CVS，这在当时是一个合理的选择，但直到 2008 年 FreeBSD 还在使用 CVS。为什么呢？因为大家对于应该用什么来代替它没有达成共识。考虑过BitKeeper、Git 和 Mercurial，最后都无疾而终了。很多社区都会反复出现长期的争论，FreeBSD 也不例外。2008 年，经过八年的争论，Peter Wemm 强行推进了向 Subversion 的转换；从那以后，抱怨声相对较少了。相比之下，Python 从 CVS 开始，2004 年转移到 Subversion，2009 年转移到 Mercurial，现在又转移到 GitHub。在 Python 社区中，一旦 PEP 获得批准，就可以继续进行了，而 FreeBSD 没有这样的机制。而 Python 社区，又是另一个以独裁者领导而著称的项目。其实，“核心小组”模式并非只有 FreeBSD 一家，GNU 项目 、Apache Web 等也都采用这种模式。但很明显，FreeBSD 的这个核心团队，并没有做好这份工作。比如著名的“ Matthew Dillon 事件”（下文会详细说），他们不但没有及时引进相应的行为准则来规范大家的行为，更是对开发者互相掐架、成员参与“Gamergate”在线骚扰活动等恶劣行为无能为力。又比如，因为缺少保证质量代码的审查流程，他们还差点让 4 万行有缺陷的代码混入 FreeBSD 内核里。 05 “FreeBSD 不会再年轻了”LWN 是这么评价 FreeBSD 的：这是一个伟大的项目，但它确实存在一些问题，特别是三点：FreeBSD 很大，它很旧，而且它行动迟缓。FreeBSD 不会变得更年轻了，它难以改变一些根深蒂固的态度。的确，从 1993 年 11 月开始，FreeBSD 出生就自带故事，而且它基于的代码非常古老。Benno Rice 说，直到 2017 年 FreeBSD 开发人员才发现自动化测试，而要进行自动化测试，软件必须具有正确的结构，但 FreeBSD 这个“老家伙”并不具备。因此，当他在一场活动中看到 Rust 社区有关自动化的演讲时，他就在想：为什么 FreeBSD 不能有这么好的东西？不光是古老，FreeBSD 还失去了活力。FreeBSD 联合创始人 Jordan Hubbard 曾经是社区最为活跃的核心人物之一，2001 年他离开了 FreeBSD 社区，去了 Apple 公司，帮 Apple 捣鼓 Darwin。在他的辞职信中，他这么说：Another reason, and I hate to say this but it probably needs saying, is that being in core is honestly not what it once was. For a old-timer like myself, who was used to a core team that was far more cohesive and generally on the same page, it's simply a painful experience a lot of the time.Perhaps this is due to overly rose-colored recollections of the old core on my part, and I do certainly recall us having more than our share of disagreement and inefficiency in the past, but on the balance core still feels too much like the pre-WWII Polish Parliment sometimes, where we're fully capable of arguing some issue right up to the point where tanks are rolling through the front door and rendering the whole debate somewhat moot.还有一些原因，我本不想但不得不说，老实说核心团队已经不像从前了。作为一个老前辈，我习惯了那样的核心团队：更加团结且大家都是一条心，一起经历了许多艰难的日子。或许是我对旧时光的滤镜太重了，在回忆里我们过去的确有更多的分歧和低效，我们的核心团队实在太“反应迟钝”了（这里用了一个典故，二战时德国都已进入波兰，而波兰国会还在商讨对策）。我们完全有能力解决问题，但就是这样：坦克都已经在门前了，一切辩论都毫无意义了。 Jordan Hubbard 在这副古老的身躯上，当我们掀开 FreeBSD 那袭表面华丽的裘衣，又会赫然发现上面还爬有一些不那么体面的虱子和臭虫。在圈子里，总是会有一些有关 FreeBSD 的“小差评”：FreeBSD 是一个很棒的操作系统，但 FreeBSD 论坛是我见过的最刻薄的论坛之一。有人在里面寻求帮助却被贬低，并让其滚回到 Linux 社区。FreeBSD 论坛成员都是 FreeBSD 的狂热分子，当话题涉及到在 FreeBSD 作用不大的组件时，就会被攻击为“Linuxism”。BSD 论坛一点也不友好。不要在那里问，他们只会让你去阅读手册。你只能靠自己。在 FreeBSD 论坛寻求帮助，得到的回复往往都是：一定是你做错了，因为 FreeBSD 永远不会错。当然，人无完人，每个社区都会有这样那样的差评，这些差评或许并不能说明些什么，但是当一些群体性事件爆发出来，FreeBSD 在文化和风气上的短板就暴露无疑了。其中最著名的就是前文曾提及的“Matthew Dillon 事件”。Matthew Dillon 是 1994 年就加入 FreeBSD 的明星成员。之所以说他是明星，是因为这哥们确实实力过硬，但不合适团队合作，不怎么在乎别人的辛苦成果，是个“Rock-star”式的人物。当初还在更新 FreeBSD 5 （现在都已经 13 了）的时候，Dillon 想打破 FreeBSD 里一个很大的内核锁，John Baldwin 也想过，于是俩人就一起干了。不出意料，两人在关键部分出现了分歧，Dillon 一意孤行地提交了更改。这引发了非常激烈的争论，在长达一个月的争吵之后，Dillon 退步了，核心团队取消了他的提交权限，他最终也离开了 FreeBSD。这不是 FreeBSD 里的孤例，还有很多类似的事件发生过。而这件事直接引起了 FreeBSD 核心团队的反思：如果 FreeBSD 当时有既定的行为准则，会不会得到更好地处理呢？Dillon 走后，Gamergate 事件直接促成了 FreeBSD 的行动。简单来说，Gamergate 是一个与性别政治有关的运动，最开始是一个已经离开的 FreeBSD 成员写了一个 Perl 脚本来阻止 Gamergate 参与者的活动，并惹怒了那批人，使得 FreeBSD 惹火上身；再后来又有 FreeBSD 成员加入 Gamergate 并开始在 Twitter 上攻击那个前成员，这下完全把 FreeBSD 拖下了水。这一事件不仅引起了激烈的讨论，攻击者随后还将对话日志泄露给了 Breitbart，核心团队别无选择，只能参与进来。2018 年， FreeBSD 确立了社区行为准则（Code of Conduct，CoC），这一准则从 LLVM 衍生而来，要求社区开发者友好耐心、热情好客、体贴、相互尊敬、对他人友善、注意不要乱说话、持不同见解时多换位思考。这是一项“修补的紧急工作”，我们最初仍然诚实地认为“精英”意味着“包容”。从那以后，我们学到了很多其他东西。—— Benno Rice06 结语2022 年 1 月，FreeBSD  基金会制定了一份时间跨度近 5 年的技术路线图，决定从面向终端用户的改进（特指笔记本和台式机）、商用服务器、工具和应用和虚拟化和容器 4 个方面为重点，以扩大和增强技术团队的实力。这份蓝图代表 FreeBSD 仍在努力朝更好的方向进发，正如 Jordan Hubbard 所说的那样，现在的 FreeBSD 应该是年轻人的天下，这样才会更具活力。早在 1990 年代我就用过 FreeBSD，当时我没什么钱，住在政府为低收入者提供的房子里，是 FreeBSD 帮助我摆脱了贫困 —— 在雅虎找到工作是因为我会用 FreeBSD，而 WhatsApp 也是用 FreeBSD 服务器为数以亿计的用户提供服务。    —— WhatsApp 联合创始人兼 CEO Jan Koum不管 FreeBSD 这盘棋下得多么艰难、多么不得势，但它给世界带来的一切是如此精彩。

这一期我们一起来看，关于存储方面的故障内容吧。SCSI 访问冲突存储链路丢包存储链路演示存储链路错包磁盘丢失Linux OS 关于存储的内容就讲到这里，下一期我们一起来看下Linux OS 关于网络的内容，敬请期待~

我们继续接上一期Linux OS相关的故障，这一期我们一起来看下Linux OS 与内存相关的故障。内存泄漏内存泄露指定量内存泄露指定次数和大小系统内存曲线泄漏Slab Cache 重复释放系统内存不足好啦，本期我们就介绍到这了，这一期我们一起学习了Linux OS关于内存方面的故障，那存储方面的故障又有哪些呢，下一期我们一起来学习下，敬请期待~

网络安全一直是IT行业最为关注的话题，Java之父James Gosling曾在采访中表示“目前，我们依然有各种各样的安全问题，网络攻击不断，如果有一种方式，可以终结网络安全隐患，那将是非常好的。”在众多的操作系统中，Linux算是比较安全的，前提是你在服务器或云端上正确的安装了Linux，并且给它提供了一定的防护。尽管这样，也无法百分百保证它不面临安全威胁。VMware威胁分析部门（TAU）在其最新威胁报告中，就Linux多云环境下的恶意软件进行了详细探讨。图片来源VMware我们都知道，Linux是世界范围内的顶级云操作系统，它为人们常用网站中超过78%的网站提供支持。黑客们都是聪明人，他们也知道针对云计算的批发要比针对Windows PC零售能赚取更多的钱。因此，黑客们把更多的精力放在了脆弱的基于Linux的多云环境上。 图片来源W^3Techs破解基于Linux的多云环境虽然破解基于Linux的多云环境很困难，但成功破解后的可观收益驱使着黑客们投入更多的精力。通常，利用破解工具来攻击基于Linux的多云环境基本是不可能完成的。但他们可以针对基于容器的基础设施中那些脆弱的认证、漏洞以及错误配置，利用远程访问工具（RATs）渗透到云环境中。一旦他们在你的云中有了一个立足点，就会尝试运行勒索软件或是部署加密组件，而这一切的目的都是为了钱。日渐复杂的勒索软件工具VMware表示，由于自己之前一直没有专注于检测这些威胁，导致Linux的恶意软件检测和预防工具长时间没有过更新。这意味着，现有的工具已经不能胜任检测与预防威胁这项工作了。而检测与预防工具的落后，却要面对更加复杂的基于Linux系统而制作的勒索软件，这些勒索软件现在的安全威胁等级更高，而且更难查找。例如，现在针对Linux的勒索软件有些已经发展到针对主机图像的地步，而想要找到这些恶意软件需要开启动态分析和主机监控。这意味着如果你的计算机中真的存在这种勒索软件，你很难清楚的知道它带来的影响。现在有不少于9个勒索软件家族在针对Linux。其中包括REvil的Linux版本；DarkSide；BlackMatter以及Defray777等。其中有几个是提供给那些没什么技术但是想赚点快钱的人的。这些人也可以通过这些勒索软件来找受害者要赎金。逍遥法外的加密劫持者加密劫持者是未经授权使用他人计算机来挖矿加密货币的人的称呼。一般加密劫持者选择的加密货币是Monero加密货币（XMR）。89%的Linux加密劫持者使用的都是XMRig的相关库。这些劫持者主要使用两种方法来达到目的。其一是利用具有窃取钱包功能的恶意软件，有时也会将恶意软件冒充为基于加密货币的应用程序。其二就是利用偷来的CPU周期挖掘加密货币。无论是那种方式，挖掘加密货币的代码都是在后台运行的，因此毫无戒心的受害者是不会发现有人在使用自的计算机挖加密货币的，他们只是会好奇自己的计算机为什么运行性能降低了，程序执行也比以前滞后。目前有7个恶意软件家族在这方面针对Linux，包括XMRig、Sysrv和Mexalz等。除了针对Linux多云环境的攻击，还有许多专门针对常见的云计算配置的攻击。例如，TeamTNT的恶意软件制作者针对开放的Kubernetes pods和Docker来部署XMRig加密软件。为了逃避对恶意软件的检测，它劫持了数据库加载机制，以此隐藏在/proc文件系统的特定目录中，从而隐藏加密器的进程。为了使自己的恶意软件能够进入到受害者的系统中，这些勒索软件的开发者中，越来越多的人使用RATs。VMware的研究团队发现，自2020年2月底以来，互联网上有超过14000个活跃的Cobalt Strike团队服务器。这个Red Team的软件是为了帮助你保护你的系统，但现在有约56%的Cobalt Strike服务器被破解了或是早就已经泄露了的Cobalt Strike实例。可以说其中大部分已经被这帮黑客利用了。网络安全近几年真的是令人头疼的问题，为了避免重蹈Apache Log4j这类开源安全问题，谷歌提出了三项安全倡议。现在VMware也发布了这篇文章来提醒你，保护好你的Linux。面对这些安全威胁，我们能做的就是给自己的计算机周全的防护。参考链接：VMware Finds Linux Malware on the Rise – The New Stack————————————————版权声明：本文为CSDN博主「、左耳」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/qq_43529978/article/details/122964991

哈喽！大家好，上一期我们对DemonCAT工具做了简单的说明，往往很多时候，测试环境用的是Linux OS，所以从这期开始我们介绍下，Linux故障模式的使用情况，后面会分为Linux OS 与CPU、内存、存储、网络、进程/线程、文件系统、系统管理共七期的介绍。那让我们先从Linux OS与CPU相关的故障开始吧。Linux OS相关的故障模式使用，包含参数、原理、命令、注意事项等相关信息。CPULinux OS内与CPU相关的故障模式。单核过载 100%多核过载 100%单核过载指定百分比多核过载指定百分比单核正弦过载多核正弦过载单核指定时间内过载指定百分比多核指定时间内过载指定百分比系统时钟跳变故障非法访问数据访问非法函数错误系统 panic关闭本地中断关于CPU方面的故障内容，我们就先介绍到这，下一期，我们一起来看下内存方面的故障又是什么样的呢，敬请期待~

原文链接：https://blog.csdn.net/m0_50065287/article/details/122943351还记得在今年年初盘点“Bug 连连”的 Android 12 时，XDA Developers 的前主编 Mishaal Rahman 曾预言：“Android 12 的 Bug 修复对谷歌而言已压力不小，由此可能导致下一版本的开发周期遭到缩减，从而引发恶性循环。”结果不到一个月，Mishaal Rahman 就被“打脸”了：上周，谷歌正式发布了 Android 13 首个开发者预览版。不可否认的是，在感受过“Android 历史上最大设计变更”的 Android 12 后，首个 Android 13 预览版似乎处在一种“珠玉在前，瓦石难当”的尴尬处境：在看过谷歌的介绍后，许多人吐槽 Android 13 “平淡无奇”、“鸡肋平庸”。但就在昨天，Android 和 Web 开发人员 @kdrag0n 发现了隐藏在 Android 13 预览版中的闪光点：谷歌 Pixel 6 等设备在安装 Android 13 预览版后，可实现完全虚拟化！这意味着，现在我们可以在 Pixel 6 或其他基于 Tensor 处理器的设备上，以接近原生的速度运行几乎任意操作系统，包括 Windows 11、Ubuntu 或 Arch Linux Arm 等 Linux 发行版。一、将 KVM 引入 Android早在 2 个月之前，Mishaal Rahman 就曾“谷歌将如何在 Android 13 中使用虚拟化”这一话题进行过分析，他坚定认为：“谷歌多年碎片化战争的下一个战场是虚拟化。”说起 Android 的虚拟化，Android 系统团队的 Will Deacon 将之称为“碎片化的狂野西部”。因为不论虚拟机是否存在于设备上，它们的作用通常都不是用来运行其他操作系统，而是用于试图增强内核安全或在 Android 操作系统之外运行杂项代码（例如 DRM、密码学和其他闭源二进制文件的第三方代码）。但在谷歌看来，“在 Android 操作系统之外运行杂项代码”这一点存在重大隐患：从上面这张 ARMv8/v9 异常模型中可以看出，虚拟机程序运行在 EL2 层，而在 ARM 命名法中，数字越大，特权级别越高，即 EL2 比行在 EL0、EL1 的代码权限更高。这也就意味着，许多闭源二进制文件的第三方代码的运行权限，比操作系统和内核还高。这显然是个安全隐患，因为在较高 EL 上运行的代码可访问低级别的所有寄存器。为解决这一安全问题，谷歌一直在寻求一个通用的虚拟化解决方案，以实现解除第三方代码的特权，并将该代码与 Android 和其他第三方程序隔离开来。关于这点，KVM 是个不错的选择。KVM，全名 Kernel-based Virtual Machine，是一个开源的系统虚拟化模块，自 Linux 2.6.20 之后，便广泛集成在各个主流 Linux 发行版中，主要使用 Linux 自身的调度器进行管理。而 Android 同样也基于 Linux 内核构建，所以谷歌自然而然会选择将 KVM 部署为通用虚拟机管理程序。但谷歌并非照搬全收，它实际上是在扩展具有额外安全功能的 KVM，即 pKVM：受保护的 KVM。当时，Mishaal Rahman 就已预测了 Android 13 可能出现的变化：“目前，市场上没有任何 Android 设备配备虚拟化模块，包括谷歌自己的 Pixel 6 也没有，但这将随着即将发布的 Android 13 版本而改变。”他补充道，据他了解，谷歌有计划在 Android 13 中引入 pKVM 和虚拟机框架的第一个版本。二、Mishaal Rahman 的预测成功这次，Mishaal Rahman 的预测成功了：通过加入全新虚拟化框架的 Android 13 预览版，@kdrag0n 完成了在 Pixel 6 中运行 Windows 11 及部分 Linux 发行版的尝试。@kdrag0n 表示：“在 Pixel 6 + Android 13 DP1 上，拥有 KVM 管理程序（接近本机性能）的成熟虚拟机。”Ta 还分享道，目前在设备上可获得完整的 EL2，而“pKVM”是可选项，可在每个 VM 的基础上启用，但对于未受保护的 VM，似乎可使用完整的 KVM 功能。为证明其运行成功，@kdrag0n 在推特上发布了一则各种 Linux 发行版作为 VM 在 Pixel 6 上启动的视频，其中包括 Ubuntu 21.10、Arch Linux Arm、Void Linux 和 Alpine Linux，甚至还有一段在 Arch 上为 arm64 编译 Linux 5.17-rc3 allnoconfig 的录屏。此后，@kdrag0n 又通过 Android 13 虚拟化，让 Pixel 6 得以运行 Windows 11 并进行了优化：“稍微提高了性能，Windows VM 现在真的可以使用了，尽管不支持硬件 GPU 加速，但 CPU、I/O 和内存压力已缓和许多。”不仅如此，@kdrag0n 还成功通过 Pixel 6 的 Windows 虚拟机，连接到电脑上（为进行键盘输入），十分顺畅地玩起了 1993 年的老游戏《毁灭战士》。但 @kdrag0n 也补充道，这是 Windows on ARM，而非 x86，并且不支持嵌套虚拟化，所以也不支持 WSA。尽管这远非完美的体验，也不如本地安装操作系统那样流畅，但能够良好运行已然不易。相信等到 Android 13 正式版支持 pKVM 时，其虚拟机体验将再度完善，届时各类操作系统在 Android 手机上的表现也值得期待。参考链接：https://blog.esper.io/android-dessert-bites-5-virtualization-in-android-13-351789/https://www.cnx-software.com/2022/02/14/android-13-virtualization-lets-pixel-6-run-windows-11-linux-distributions/https://twitter.com/kdrag0n/status/1492754683445669893

【问题描述】在安装集群前，对节点做preinstall，报如下错误：【问题原因】可能是由于操作系统版本过高导致，此问题多见于麒麟操作系统【解决方案】1、挂载系统镜像（方案里以镜像放在/opt目录下，镜像名称为rhel-server-6.8-x86_64-dvd.iso举例）mount /opt/rhel-server-6.8-x86_64-dvd.iso /media -o loop 2、配置本地yum源系统自带的Yum源在/etc/yum.repos.d文件夹内，我们通过rm命令将原文件删除建repo文件：vi /etc/yum.repos.d/local_yum.repo,然后将下面的内容复制进去[sr0]name=sr0baseurl=file:///media/enabled=1gpgcheck=0用:wq命令保存退出，执行yum repolist all3、手动安装不一致的包执行yum clean all 然后安装不一致的rpm包（可以一次性安装）yum install hesiod.arrch64（所有不一致的包可以一次性添加上）注：以上解决方案的步骤需在所有节点执行

Linux是开源的一种系统，开发者可以随心所欲的在里面进行研究和研发，本文主要介绍了如何从零开始制作一个linux iso镜像，具有一定的参考价值，感兴趣的可以了解一下一、前言    对于一个极简化的linux系统而言，只需要三个部分就能组成，它们分别是一个linux内核、一个根文件系统和引导。以下是本文制作linux iso镜像所用到的系统和软件：    OS: ubuntu 20    软件: xorriso二、制作linux内核    1、首先需要去官网选择一个需要的版本下载下来，官网下载地址：https://mirrors.edge.kernel.org/pub/linux/kernel/     2、利用tar将其解压，然后进入其目录中，然后配置内核，常见的配置有以下几种：      a、make defconfig - 默认配置      b、make allyesconfig - 创建能选yes就选yes的配置      c、make allnoconfig - 创建能选no就选no的配置      d、make menuconfig - 基于ncurser的图形化界面配置      这里采用命令make defconfig使用默认的即可，如下图所示：    3、然后使用make bzImage命令编译出内核即可，如下图所示：    编译好的内核文件在arch文件夹相应的架构文件夹下面，如下图所示：三、制作根文件系统    1、我们这里利用busybox来制作一个根文件系统，busybox可以简单理解为一个linux工具的集合。首先还是下载busybox，官网下载地址：https://busybox.net/downloads/     2、编译busybox与编译内核步骤基本一致，将下载好的压缩包进行解压，然后进入文件夹中，使用make defconfig配置默认编译选项，这里需要注意的是，在生成的.config配置文件中，需要设置CONFIG_STATIC=y，如果没有，添加即可，如下图所示：    3、然后使用make busybox install命令编译busybox，编译好后会在当前目录下面生产一个_install文件夹，如下图所示：      4、然后创建一个rootfs文件夹，并将_install文件夹下面除linuxxrc以外的所有文件及文件夹都拷贝到rootfs文件夹下面，最后创建dev等文件夹，最后在根目录下面创建init文件即可，文件内容如下图所示：    5、最后利用命令find . | cpio -R root:root -H newc -o | gzip > ../rootfs.gz将文件系统打包，至此，一个文件系统就创建完成了，如下图所示：四、BIOS    1、这里我们使用syslinux来创建bios引导的一个linux iso镜像，syslinux官方下载地址如下：https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/     2、将下载好的syslinux解压，然后创建文件夹isobios，将解压后的syslinux文件夹下面的bios/core/isolinux.bin、bios/com32/elflink/ldlinux/ldlinux.c32复制到isobios文件夹下面，如下图所示：    3、在isobios文件夹下面创建配置文件isolinux.cfg，文件内容如下所示：    4、最后，在isobios文件夹下面使用命令xorriso -as mkisofs -o ../testbios.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table ./生成iso镜像文件，如下图所示：    5、使用虚拟机vmware创建一个虚拟机，如下图所示，便是我们创建的一个linux iso镜像跑起来的样子。五、UEFI    1、uefi这里采用system-boot和syslinux配合来制作，首先，创建两个文件夹isouefi和tmp，其中，isouefi用来挂载设备，tmp文件夹用来临时存放文件以计算大小，然后在tmp文件夹下面创建EFI/BOOT和loader/entries目录，接着，将解压后的systemboot下面的uefi_boot/EFI/BOOT/BOOTx64.EFI文件拷贝到tmp/EFI/BOOT目录下面，如下图所示：    2、接着，在tmp/loader目录下面，创建文件loader.conf配置文件，第一行表示默认配置是entries目录下那个文件，第二行设置默认超时时间；然后在entries文件夹下面创建相应的配置文件，这里是mll-x86_64.conf，文件内容和bios的差不多，不在单独细说，最后再将前面准备好的内核和文件系统拷贝到tmp目录下面，如下图所示：    3、此时就可以根据tmp文件夹的总大小创建一个相同大小的img文件了，这里的tmp是11M，为了稳妥起见，这里创建一个12M的img文件，命令为truncate -s 12M uefi.img，然后使用losetup -f命令寻找一个当前未使用的逻辑设备，然后使用losetup命令将我们前面创建的img文件虚拟成改逻辑设备，接着利用mkfs.vfat将该设备格式化成vfat系统，接着使用mount命令将其挂载到isouefi文件夹下面，最后将tmp文件夹下面所有文件及其文件夹拷贝到isouefi目录下面，如下图所示：    4、接着利用umount命令取消挂载，这样我们就得到一个包含内核、文件系统等的img文件，接着创建一个iso文件夹，并且在该文件夹下面将创建一个boot文件夹，然后将img复制到iso/boot下面，最后利用xorriso工具生成iso文件即可，如下图所示：    5、最后，新建一个虚拟机，引导选择uefi，启动即可，如下图所示：六、相关链接    github链接：https://github.com/windy-purple/make_linux_iso 转载自https://www.jb51.net/LINUXjishu/798229.html

1. 错误状态在使用串口进行通信时，经常需要使用指令来赋予用户读写的权限$ sudo chmod 777 /dev/ttyUSB0但这样的权限是一次性的每次重启或者关闭计算机，插拔USB串口都无效了，炸裂！2. 解决办法查看串口ttyUSB0$ ls -l /dev/ttyUSB0可以看到所属用户组为 dialout， root用户才具有操作权限接下来查看当前用户名$ whoami然后将当前用户加入到dialout用户组，使其具有操作串口ttyUSB0的权限$ sudo usermod -aG dialout jove最后重启系统即可实现永久串口读写权限，搞定收工！转载自https://www.jb51.net/LINUXjishu/799104.html

描述DemonCAT 工具覆盖计算全栈的故障注入能力，包含芯片、硬件、网络、OS、基础组件和AI应用等故障注入能力，从底端芯片到上层应用，覆盖整个计算产品的硬件层、软件层和应用层，测试人员无需单独寻找各个组件或部件的故障注入方法和工具，通过 DemonCAT工具配合使用指南即可实现对目标的故障注入与清除，大大提升了可靠性测试的效率。 以CC视角初步构建计算产品故障注入能力，提供工具支撑：L0/L1 层 – 硬件平台L0对应芯片级别，L1 为其他硬件级别。在此级别DemonCAT将支持 CPU、NPU和GPU等芯片的故障注入能力，支持内存模块的CE/UCE的事件注入能力，支持SCSI协议 磁盘的链路故障注入，同时进一步探索交换机故障注入能力。L2 层 – 基础软件L2级别主要包括Linux OS，Docker，iSulad等应用运行所依赖的基础软件。DemonCAT目前支持Linux OS与Docker容器类故障模式共130多种。当前仍在不断地丰富Linux OS与容器的注入能力，将支持更多的 Linux OS与容器的故障模式，例如：将新增支持更多种Linux OS文件资源的注入能力、支持Android镜像的容器。L3 层 – 上层软件L3级别主要是业务应用的故障注入能力，DemonCAT将覆盖AI训练场景故障注入能力，支持AI训练模型、数据故障注入能力。同时 DemonCAT即将进一步探索更多应用的故障注入能力，例如：Java、微服务、k8s、Go等等常见的业务应用。支持的故障模式DemonCAT工具实现计算全栈故障注入版面太多，我们分为上下两期，敬请期待~

NetCat，在网络工具中有“瑞士军刀”美誉，其有Windows和Linux的版本。因为它短小精悍（1.84版本也不过25k，旧版本或缩减版甚至更小）、功能实用，被设计为一个简单、可靠的网络工具，可通过TCP或UDP协议传输读写数据。同时，它还是一个网络应用Debug分析器，因为它可以根据需要创建各种不同类型的网络连接。一、版本通常的Linux发行版中都带有NetCat（简称nc），甚至在拯救模式光盘中也由busybox提供了简版的nc工具。但不同的版本，其参数的使用略有差异。NetCat 官方地址：http://netcat.sourceforge.net/ 引用[root@hatest1 ~]# cat /etc/asianux-releaseAsianux release 2.0 (Trinity SP2)[root@hatest1 ~]# cat /etc/redflag-releaseRed Flag DC Server release 5.0 (Trinity SP2)[root@hatest1 ~]# type -a ncnc is /usr/bin/nc[root@hatest1 ~]# rpm -q ncnc-1.10-22建议在使用前，先用man nc看看帮助。这里以红旗DC Server 5.0上的1.10版本进行简单说明。假设两服务器信息：引用server1: 192.168.228.221server2: 192.168.228.222二、常见使用1、远程拷贝文件从server1拷贝文件到server2上。需要先在server2上，用nc激活监听，server2上运行：引用[root@hatest2 tmp]# nc -lp 1234 > install.logserver1上运行：引用[root@hatest1 ~]# ll install.log-rw-r--r--   1 root root 39693 12月 20   2007 install.log[root@hatest1 ~]# nc -w 1 192.168.228.222 1234 < install.log2、克隆硬盘或分区操作与上面的拷贝是雷同的，只需要由dd获得硬盘或分区的数据，然后传输即可。克隆硬盘或分区的操作，不应在已经mount的的系统上进行。所以，需要使用安装光盘引导后，进入拯救模式（或使用Knoppix工具光盘）启动系统后，在server2上进行类似的监听动作：# nc -l -p 1234 | dd of=/dev/sdaserver1上执行传输，即可完成从server1克隆sda硬盘到server2的任务：# dd if=/dev/sda | nc 192.168.228.222 1234※ 完成上述工作的前提，是需要落实光盘的拯救模式支持服务器上的网卡，并正确配置IP。3、端口扫描可以执行：引用# nc -v -w 1 192.168.228.222 -z 1-1000hatest2 [192.168.228.222] 22 (ssh) open4、保存Web页面# while true; do nc -l -p 80 -q 1 < somepage.html; done5、模拟HTTP Headers引用[root@hatest1 ~]# nc www.linuxfly.org 80GET / HTTP/1.1Host: ispconfig.orgReferrer: mypage.comUser-Agent: my-browserHTTP/1.1 200 OKDate: Tue, 16 Dec 2008 07:23:24 GMTServer: Apache/2.2.6 (Unix) DAV/2 mod_mono/1.2.1 mod_python/3.2.8 Python/2.4.3 mod_perl/2.0.2 Perl/v5.8.8Set-Cookie: PHPSESSID=bbadorbvie1gn037iih6lrdg50; path=/Expires: 0Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0Pragma: no-cacheCache-Control: private, post-check=0, pre-check=0, max-age=0Set-Cookie: oWn_sid=xRutAY; expires=Tue, 23-Dec-2008 07:23:24 GMT; path=/Vary: Accept-EncodingTransfer-Encoding: chunkedContent-Type: text/html[......]在nc命令后，输入红色部分的内容，然后按两次回车，即可从对方获得HTTP Headers内容。6、聊天nc还可以作为简单的字符下聊天工具使用，同样的，server2上需要启动监听：[root@hatest2 tmp]# nc -lp 1234server1上传输：[root@hatest1 ~]# nc 192.168.228.222 1234这样，双方就可以相互交流了。使用Ctrl+D正常退出。7、传输目录从server1拷贝nginx-0.6.34目录内容到server2上。需要先在server2上，用nc激活监听，server2上运行：引用[root@hatest2 tmp]# nc -l 1234 |tar xzvf -server1上运行：引用[root@hatest1 ~]# ll -d nginx-0.6.34drwxr-xr-x 8 1000 1000 4096 12-23 17:25 nginx-0.6.34[root@hatest1 ~]# tar czvf - nginx-0.6.34|nc 192.168.228.222 12348、参数简介这仅是一个1.10版本的简单说明，详细的参数使用还是需要看man：引用想要连接到某处: nc [-options] hostname port[s] [ports] ...绑定端口等待连接: nc -l -p port [-options] [hostname] [port]参数:-g gateway source-routing hop point[s], up to 8-G num source-routing pointer: 4, 8, 12, ...-h 帮助信息-i secs 延时的间隔-l 监听模式，用于入站连接-n 指定数字的IP地址，不能用hostname-o file 记录16进制的传输-p port 本地端口号-r 任意指定本地及远程端口-s addr 本地源地址-u UDP模式-v 详细输出——用两个-v可得到更详细的内容-w secs timeout的时间-z 将输入输出关掉——用于扫描时，其中端口号可以指定一个或者用lo-hi式的指定范围。 9、1.84版本参数简介1. nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port]2.    [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_protocol] [-x3.    proxy_address[:port]] [hostname] [port[s]]  1. -4 强制使用ipv42. -6 强制使用ipv63. -D 允许socket通信返回debug信息4.       -d 不允许从标准输入中读取5. -h 显示nc帮助文档6. -i interval 7.    指定每行之间内容延时发送和接受，也可以使多个端口之间的连接延时8. -k 当一个连接结束时，强制nc监听另一个连接。必须和-l一起使用9. -l 用于监听传入的数据链接，不能与-p -z -s一起使用。-w 参数的超时也会被忽略10. -n 不执行任何地址，主机名，端口或DNS查询11. -p 指定nc使用的源端口，受权限限制且不能余-l一起使用12. -r 指定nc使用的源端口和目的端口，不能使用系统原来就指定的那些端口13. -S 允许在RFC 2385的TCP MD5签名选项14. -s source_ip_address 15.    指定用于发包的接口的IP地址，不能和-l一起使用16. -T ToS17.    指定链接的IP服务类型（TOS）18. -C 自动换行19. -t 使nc能够与telnet交互20. -U 使用UNIX域socket21. -u 使用udp代替默认的tcp选项22. -v 输出详细报告23. -w timeout24.     一个链接一段时间无操作，则自动断开，默认无超时25. -X proxy_version26.     指定nc使用代理时所采用的协议,可选的有socksv4，socks5以及https。默认socks527. -x proxy_address[:port]28.     指定nc使用的代理地址和端口。默认设置:1080(SOCKS),3128(HTTPS)29. -z 只监听不发送任何包 三、版本差异不用系统上提供的nc版本会有说不同，其提供的参数使用方法也略有差异。例如，红旗Asianux 3.0 SP1拯救光盘上的版本是供使用的参数仅有一部分：引用# nc -hBusyBox v1.2.0 (2008.04.14-01:35+0000) multi-call binaryUsage: nc [OPTIONS] [IP] [port]Netcat opens a pipe to IP:portOptions:         -l               listen mode, for inbound connects         -p PORT         local port number         -i SECS         delay interval for lines sent         -e PROG         program to exec after connect (dangerous!)         -w SECS         timeout for connects and final net reads而在Asianux 3.0 SP1系统中提供的nc版本则是1.84的，按上面的参数用法写会执行不了：引用[root@ftpserver ~]# rpm -q ncnc-1.84-10[root@ftpserver ~]# nc -lp 1234usage: nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port]           [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version]           [-x proxy_address[:port]] [hostname] [port[s]]讲查看man文档，可见在这个版本中，-l是不能与-s、-p、-z一起使用的，-w参数也会被忽略，所以，正确的用法是：[root@ftpserver tmp]# nc -l 1234四、用在脚本中nc每次启动监听后，都会在客户端连接完成并退出的同时，服务端一同退出。所以，如果需要不断的使用nc进行数据传输，需要在脚本中使用循环。利用nc实现更多的功能，可参考其rpm提供的参考脚本：引用# rpm -qd nc/usr/share/doc/nc-1.10/Changelog/usr/share/doc/nc-1.10/README/usr/share/doc/nc-1.10/scripts/README/usr/share/doc/nc-1.10/scripts/alta/usr/share/doc/nc-1.10/scripts/bsh/usr/share/doc/nc-1.10/scripts/dist.sh/usr/share/doc/nc-1.10/scripts/irc/usr/share/doc/nc-1.10/scripts/iscan/usr/share/doc/nc-1.10/scripts/ncp/usr/share/doc/nc-1.10/scripts/probe/usr/share/doc/nc-1.10/scripts/web/usr/share/doc/nc-1.10/scripts/webrelay/usr/share/doc/nc-1.10/scripts/websearch/usr/share/man/man1/nc.1.gz转载自https://www.jb51.net/article/106898.htm

这一期我们聊一聊DemonCAT组网和架构，组网有什么样的要求？被测端配置的要求又是什么样的？Portal 与 Center 端配置要求你知道吗？OK，一起来看看吧。一、组网要求DemonCAT 主要围绕软件故障注入工具，核心是利用 Linux OS 远程连接的基本功能，来实现故障注入过程操作图形化、简单化。DemonCAT分为三部分，从表层到深层分别为DemonCAT Portal(以下简称 Portal)、DemonCAT Center(以下简称Center)以及 DemonCAT Core(以下简称 Core)，三部分属于松耦合的关系，上层都不强依赖于下层运行。 Portal是一个 Web 界面，用户利用浏览器即可访问到相关页面，在该 Web 页面上可以方便的录入被测环境、创建故障注入任务、查看支持的故障模式等操作。Center是一个后端的Http服务,它是DemonCAT的核心内容,作为 DemonCAT的大脑存在，主要负责执行故障注入任务、保存所有的操作数据。 Core是一个故障注入的工具包，它是DemonCAT的基础，是不能缺少的部分。它包含了Linux OS与Docker容器等常用的故障注入工具包，它们是基于 Linux OS进行编译得到的程序工具包。DemonCAT Core不依赖于Center与Portal，可以利用命令行进行试用。DemonCAT 三部分的组网图如上图所示，其中 Portal 依赖于 Center 提供接口运 行，Core 与 Center 属于松耦合关系，Core 可单独运行或被集成。二、被测端配置要求Core包含计算产品各种层级的故障注入能力：芯片、CPU、内存、磁盘、网卡以及进程等相关模块的故障模式，大部分故障模式是基于Linux OS进行模拟实现的，小部计算故障注入工具（DemonCAT）技术白书DemonCAT原理和功能分故障模式需要相应的硬件配合才能实现，因此不同的故障模式对被测端的要求会有所变化。    硬件配置Core是运行在Linux OS中的故障注入程序，只要 64 位的 Linux OS 可以在硬件上 运行起来，则Linux OS上就可以运行Core程序。这里给出Ubuntu OS最小要求配置，其它操作系统大致类似：上述表格为通用的基础硬件配置，满足上述配置基本可运行大部分故障注入程序，部分故障注入程序是针对特殊的相关类型硬件进行的故障注入，因此对一些硬件是具有特殊要求的： 计算芯片类故障：计算芯片类的故障注入实现，主要是通过修改芯片之中的寄存器地址，来模拟部分硬件的故障，而寄存器地址在不同的CPU型号里面是不一样的，因此是该类故障注入程序不能一次性满足所有的计算芯片；目前支持的计算芯片为鲲鹏920(Hi1620)。网络类故障：网络类故障是基于当前服务器能够与其它机器网络连通的基础之上进行注入，因此当前服务器必须存在网卡配置(虚拟或物理都可以)。对于网卡的配置无具体要求，目前主要故障是针对网卡的启停、限速、丢包等故障模式进行的模拟，除专门针对指定网卡芯片的故障需要相应网卡芯片外，其余故障对网卡的规格配置基本无要求。 磁盘类故障：磁盘类故障主要是针对磁盘的驱动链路进行的故障注入，这类故障是与硬盘的类型强相关，目前支持的硬盘主要是scsi协议的硬盘。    软件配置Core属于Linux OS下的可执行程序(暂不支持 Windows 操作系统)，依赖于Linux OS，当前支持的架构为x86_64或aarch64的常用Linux发行版（需要包含Linux安装时默认安装的一些常用软件）。目前已测试验证支持的发行版包括：EulerOS、计算故障注入工具（DemonCAT）技术白书 DemonCAT原理和功能openEuler、CentOS、Ubuntu OS、Debian OS、RHEL等。网络类与进程类故障存在特殊软件的需求：网络类故障：网络类故障模式主要为破坏网卡接收包的速率、数量以及正确性验证，这一类操作OS已提供了部分工具，Core主要对其进行了封装。因此需要满足存在 net-tools、iptoute2 等网络控制软件包。 进程类故障：进程类故障模式主要通过为指定进程加载动态链接库，从而实现进程资源的消耗或注入，加载动态链接库的方式是利用Linux OS的 GDB依附到指定的进程之中，然后通过 dlopen 函数加载so库。因此需要满足GDB程序存在。三、Portal 与 Center 端配置要求  Portal与Center为传统Web服务的前端与后端，基于故障注入的业务访问量不会很大，主要集中在后台任务运行。  硬件配置：1 核 CPU/1G 内存/20G 硬盘/1M 网络带宽，即可运行 Portal 与 Center。  软件配置：Portal与Center采用跨平台语言编写而成，支持市场主流的操作系统。但建议使用Linux系统，对Portal与Center运行具有较好维护、更高的运行效率。  欢迎大家一起参与讨论哦，下一期我们一起看下DemonCAT的架构原理，敬请期待~

漏洞名称：Linux Polkit 权限提升漏洞组件名称：Polkit影响范围：CentOS 6：polkit-0.96-11.el6_10.2CentOS 7：polkit-0.112-26.el7_9.1CentOS 8.0：polkit-0.115-13.el8_5.1CentOS 8.2：polkit-0.115-11.el8_2.2CentOS 8.4：polkit-0.115-11.el8_4.2Ubuntu 21.10 (Impish Indri) < Released (0.105-31ubuntu0.1)Ubuntu 21.04 (Hirsute Hippo) Ignored (reached end-of-life)Ubuntu 20.04 LTS (Focal Fossa) < Released (0.105-26ubuntu1.2)Ubuntu 18.04 LTS (Bionic Beaver) < Released (0.105-20ubuntu0.18.04.6)Ubuntu 16.04 ESM (Xenial Xerus) < Released (0.105-14.1ubuntu0.5+esm1)Ubuntu 14.04 ESM (Trusty Tahr) < Released (0.105-4ubuntu3.14.04.6+esm1)…漏洞类型：本地提权利用条件：1、用户认证：需要攻击者获得一个普通用户权限2、前置条件：恶意文件需要可执行权限3、触发方式：本地综合评价：<综合评定利用难度>：利用难度中等，需要攻击者获取普通用户权限。<综合评定威胁等级>：高危，能造成本地提权。漏洞分析：1、组件介绍Polkit（之前称为 PolicyKit）是一个用于在类 Unix 操作系统中控制系统范围权限的组件。它为非特权进程与特权进程通信提供了一种有组织的方式。也可以使用 Polkit 执行具有提升权限的命令。2、漏洞描述2022年1月26日，监测到一则 Polkit 组件存在本地权限提升漏洞的信息，漏洞编号：CVE-2021-4034，漏洞威胁等级：高危。该漏洞是由于 pkexec 在处理传入参数的逻辑出现问题，导致环境变量被污染，最终交由 pkexec 代码逻辑执行实现客户机权限提升。有普通权限用户的攻击者通过执行漏洞文件，触发越界读写，从而在目标系统上造成权限提升。解决方案：1、如何检测系统版本CentOS 用户可采用如下命令升级到安全版本或更高版本：yum clean all && yum makecacheyum update polkit -y验证修复，通过以下命令可查看 Polkit 是否为安全版本：rpm -qa polkitUbuntu 用户可采用如下命令升级至安全版本或更高版本：sudo apt-get updatesudo apt-get install policykit-1验证修复，通过以下命令可查看 Polkit 是否为安全版本：dpkg -l policykit-12、官方修复建议目前各 Linux 发行版官方均已给出安全补丁，建议用户尽快升级至安全版本，或参照官方说明措施进行缓解，CentOS、Ubuntu 及 Debian 用户可参考以下链接：https://ubuntu.com/security/CVE-2021-4034https://access.redhat.com/security/cve/CVE-2021-4034https://security-tracker.debian.org/tracker/CVE-2021-4034参考链接:https://ubuntu.com/security/CVE-2021-4034https://access.redhat.com/security/cve/CVE-2021-4034https://security-tracker.debian.org/tracker/CVE-2021-4034

背景：部分软件需要在系统内核为4KB下才能运行，一般Centos默认的内核是64KB，下文举例系统为CentOS7.6首先通过以下命令查询当前操作系统的pagesize大小getconf -a|grep PAGESIZE得到的结果为65536，则为64KB得到的结果为4096，则为4KB下载kernel源码包并安装依赖，此前需要配置好yum本地源等一些相关源参考下载地址：(http://vault.centos.org/7.6.1810/os/Source/SPackages/ )groupadd mockbuilduseradd mockbuild -g mockbuildwget https://vault.centos.org/7.6.1810/os/Source/SPackages/kernel-alt-4.14.0-115.el7a.0.1.src.rpm注意：这个包需要看当前的操作系统是7.6还是8.2还是其他，同时需要找到对应的内核版本，下载正确的rpm包安装依赖yum -y install gcc bc gcc-c++ ncurses ncurses-devel cmake elfutils-libelf-devel openssl-devel安装rpm包rpm -ivh kernel-alt-4.14.0-115.el7a.0.1.src.rpm安装完成后，rpm构建工程自动部署在/root/rpmbuild/SPECS/root/rpmbuild/SOURCES进入内核版本解压目录cd /root/rpmbuild/SOURCEStar zvf linux-xxxxx.tar.gzcd linux-xxxxx清理内核源目录make mrpropermake menuconfigKernel Features-->Page size (64KB)--> Page size (4KB) 保存 #Page size调整为4K。注释.config文件中的参数CONFIG_SYSTEM_TRUSTED_KEYSvim .config在CONFIG_SYSTEM_TRUSTED_KEYS参数前面添加#，将参数这行注释掉修改.config文件中的参数CONFIG_ARM64_VA_BITS。vim .config修改成下面参数CONFIG_ARM64_VA_BITS_48=yCONFIG_ARM64_VA_BITS=48编译内核make -j 64make modules_installmake install生成系统启动引导配置参数grub2-mkconfig -o /boot/grub2/grub.cfg从ibmc重启机器，选对应的操作系统