Linux服务器安全诊断脚本：漏洞检测与入侵痕迹排查实战

Linux服务器安全诊断脚本：漏洞检测与入侵痕迹排查实战

发布时间：2026/10/20 7:56:11
Linux服务器安全诊断脚本：漏洞检测与入侵痕迹排查实战 1. 这个脚本要解决什么问题先说个真实场景。某天凌晨三点某公司的运维同事发现数据库响应异常缓慢登录服务器一看CPU跑满网络连接有大量外连。第一反应是拔网线第二反应是“我怎么知道被搞了什么”。这种时候如果手里有一套顺手的安全诊断脚本能在几分钟内把补丁漏洞、弱口令风险、异常登录、后门文件、恶意进程一次性捋清楚后续处置会从容很多。这套“量子安全增强版诊断脚本”本质上就是把安全自查和入侵排查的常用操作沉淀成一套自动化工具。它做的事情可以概括为三块采集系统基本信息、执行漏洞风险检测、分析入侵痕迹。检测完自动生成带风险等级的报告告诉你“哪里有问题问题有多严重建议怎么处理”。写这个脚本的初衷很简单很多服务器在出现问题之前其实已经有不少“预兆”只是没人系统性地去看。比如某个月密码策略没生效、某个目录多了个奇怪的定时任务、某个账号的登录记录里有凌晨三点的异地IP。单个看都不起眼但组合在一起往往就是一次入侵的开始。这套脚本的价值就是把散落的信号收敛成一份可读的报告让非专职安全人员也能在第一时间发现异常。它适合谁用运维工程师、系统管理员、等保自查人员以及所有“想知道自己服务器到底安全不安全”的人。不需要你有很深的渗透功底只要会执行脚本、能看懂报告结论就能完成一次基础的安全体检。我也建议把这套脚本作为重要服务器的定期巡检项目比如每两周跑一次和日常备份放到同一套计划任务里。2. 整体设计思路为什么需要“增强版”这一节先讲清楚脚本背后的设计逻辑知道“为什么这么写”后面用起来才不会只停留在“跑了、出报告、看不懂”的层面。2.1 传统手动排查的痛点在没有这类脚本之前排查服务器安全状况基本靠“人肉翻”。登录服务器先看/var/log/auth.log再翻/var/log/secure然后一个个查系统账号、查 crontab、查端口、查进程。查的时候脑子里要同时记着十几个检查点漏掉任何一个都可能导致误判。更麻烦的是不同发行版的日志路径和格式还不一样。CentOS 的登录日志在/var/log/secureUbuntu 在/var/log/auth.log有些精简系统可能连/var/log/下的内容都被清理过。一个脚本如果只写死一套路径换个系统就跑不通不实用。所以设计的第一条原则就是兼容性优先。脚本里对日志路径、命令差异做了大量“存在性判断”先看文件在不在、命令在不在再决定怎么执行。这样同一个脚本可以在主流的 Linux 发行版上跑不需要针对每个系统改版本。2.2 “增强版”到底增强了什么“量子安全增强版”这个名字不是噱头。核心思路是在检测顺序和部分检测项的随机化上引入一个熵源让每次检测的“路径依赖”不同。传统脚本的检测流程是固定的模式很容易被攻击者预判他知道你会在什么时候查哪个目录、哪个文件、哪条日志就可以提前清理痕迹来绕过。而这个脚本在启动后会生成一个随机的检测序列再按这个序列执行各个模块。你这次跑是先查后门再查账户下次跑可能就先查日志再查端口。检测结果的汇总顺序也做了随机化降低外部观察者通过输出格式推断检测侧重点的可能。当然这只是第一层。第二层增强体现在检测深度上普通的漏洞检测脚本往往只看软件版本号比对CVE库报出来一堆“可能受影响”的条目实际误报率很高。这套脚本在版本比对之外还会结合补丁安装时间、服务是否实际在运行、端口是否对外开放这几个维度做综合判断。一个库有已知漏洞但如果对应服务根本没用或者补丁已经在漏洞公开之前更新了风险等级就会自动下调一级。这种多维度确认的好处是报告里的每一项都更接近“真实风险”而不是纯粹的理论风险。2.3 模块划分与流程脚本按功能拆成五个独立模块按序执行信息采集模块主机名、系统版本、内核版本、CPU和内存占用、磁盘剩余空间、最近重启时间。漏洞检测模块补丁状态、账户密码策略、暴露端口、危险服务、常见配置缺陷。入侵痕迹分析模块登录日志、账户变更、可疑进程、自启动项、文件时间线、Web后门特征。报告生成模块把检测结果写为结构化JSON文件同时输出一个可读的文本摘要。自清理模块删除运行过程中产生的临时文件只保留最终报告。之所以把信息采集放在最前面是因为后面的漏洞检测和入侵分析都依赖基础数据。比如判断一个端口是否应该开放得先知道这台机器是Web服务器还是数据库服务器这就用到采集阶段识别到的服务类型。再比如分析可疑进程需要先有个CPU和内存的基线数据才好判断哪些进程的占用“异常高”。3. 漏洞检测模块从版本比对到真实风险确认漏洞检测是整套脚本里代码量最大的部分也是误报率最需要控制的部分。这一节把几个关键检测项逐个拆开讲。3.1 补丁状态检测补丁检测不直接联网查漏洞库而是基于“补丁时间 vs 已知漏洞披露时间”做本地判断。原理不复杂绝大多数系统漏洞在官方发布安全公告后如果某台服务器在公告发布后很长时间没有更新补丁风险就会显著上升。脚本检查最近一次补丁更新时间# 取系统安装补丁/软件包的最后时间 LAST_PATCH_DATE$(rpm -qa --last 2/dev/null | head -1 | awk {print $2, $3, $4} 2/dev/null) if [ -z $LAST_PATCH_DATE ]; then LAST_PATCH_DATE$(stat -c %y /var/lib/dpkg/status 2/dev/null | awk {print $1}) fi如果是 CentOS/RHEL 系rpm -qa --last能直接看到最近安装的软件包时间如果是 Debian/Ubuntu则判断/var/lib/dpkg/status文件的修改时间这个文件在每次用 apt 安装或升级软件时都会更新。拿到这个时间后和当前日期做差超过90天没有更新就标为高危30到90天标为中危30天以内标为低危。同时输出内核版本号因为很多内核提权漏洞检查时需要对照。这个检测逻辑靠的是“补丁新鲜度”的间接判断虽然不如精确匹配CVE全面但胜在稳定可靠且不依赖外网接口。这里有个实际经验有些服务器在特殊时期会暂停更新导致补丁时间长期停留在一个旧日期这属于“管理性风险”但未必真的被漏洞影响。脚本会把补丁时间单独列出来同时也给出当前运行的内核版本和可用的最新内核版本方便人工复核。3.2 账户与口令安全检测口令安全是个老生常谈但永远不过时的话题。脚本做了这几个检查空密码账户检查/etc/shadow中密码字段为空的账户。密码过期策略读取/etc/login.defs中的PASS_MAX_DAYS、PASS_MIN_LEN等参数。拥有登录Shell的账户清单把/etc/passwd里 shell 不为/sbin/nologin或/bin/false的账户列出重点关注UID为0的账户和最近90天内新增的账户。实现的核心片段# 检查空密码用户 EMPTY_PASS_USERS$(awk -F: ($2 || $2 !!) {print $1} /etc/shadow 2/dev/null) # 找出UID 0且非root的账户特权账户异常 ADMIN_ACCOUNTS$(awk -F: ($3 0) {print $1} /etc/passwd) # 账户最后修改时间判断是否有近期新增或改动 ACCOUNT_CHANGES$(awk -F: $3 1000 || $3 0 {print $1} /etc/passwd)检测时还额外比对了最近一次新增活跃账户的时间。如果/etc/shadow中某账户的最近修改时间是“最近7天内”而系统管理员又想不起来有这回事那基本上可以列为重点核查对象。入侵者拿到权限后的常规操作之一就是创建一个隐僻的账户作为后备通道。3.3 端口与服务暴露面检测暴露面检测的逻辑是先用ss -tlnp拿到所有监听端口再结合系统里跑着的主要服务进程给出“非预期暴露”的判断。脚本只做标记不做自动封禁因为这需要人工确认业务需求。# 获取监听端口清单IPv4和IPv6 LISTEN_PORTS$(ss -tlnp 2/dev/null | awk NR1 {split($4, a, :); print a[length(a)]} | sort -nu) # 常见高危端口对比 HIGH_RISK_PORTS23 3389 5900 6379 9200 11211如果发现 6379Redis、9200Elasticsearch、11211Memcached这些端口对公网开放脚本会直接标为高危因为这三个服务默认不带认证或认证极弱基本等于把数据裸奔在公网上。SSH 端口如果监听在0.0.0.0上也会提示风险建议改为监听内网地址或用防火墙限制来源IP。3.4 关键配置风险扫描这里检查的是系统安全配置层面的常见疏漏包括SSH 是否允许 root 直接登录检查/etc/ssh/sshd_config中PermitRootLogin是否为no。防火墙是否开启检查 firewalld 或 ufw 服务状态以及 iptables 规则是否为空。关键文件权限/etc/shadow的权限是否为000或400/etc/passwd是否可被普通用户写。全局可写的文件扫描/etc/目录下权限为777的文件这类文件很容易被用来植入恶意内容。# 检查SSH root登录设置 ROOT_LOGIN$(grep -E ^PermitRootLogin /etc/ssh/sshd_config 2/dev/null | awk {print $2}) if [ $ROOT_LOGIN ! no ]; then echo SSH允许root直接登录建议禁用 fi检测这些项不需要很深的技术但对结果要结合上下文看。比如/etc/shadow权限显示为644看起来问题很严重但有些容器化环境为了挂载方便确实会放宽权限这时需要人工判断环境类型再决定是否处理。脚本在报告中会对这类条目标注“需人工复核”而不是一刀切“高危”。4. 入侵痕迹分析模块从日志和文件系统里找异常漏洞检测解决的是“有哪些口子可能被利用”入侵痕迹分析解决的是“是不是已经被利用过了”。这部分的检测思路和取证类似核心假设是攻击者在系统上的操作总会留下痕迹问题在于痕迹藏得多深、覆盖不掉的那部分能不能被发现。4.1 登录日志审计登录日志是入侵分析的第一站。脚本会解析所在系统对应的登录日志文件统计成功登录、失败登录、来源IP Top 10以及最近一次成功登录的时间。# 自动识别日志文件 AUTH_LOG for f in /var/log/auth.log /var/log/secure /var/log/audit/audit.log; do if [ -f $f ]; then AUTH_LOG$f break fi done # 提取成功登录记录 SUCCESS_LOGINS$(grep -E Accepted (publickey|password) $AUTH_LOG 2/dev/null | tail -50) # 提取失败登录记录统计暴力破解来源 FAILED_COUNTS$(grep Failed password $AUTH_LOG 2/dev/null | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -10)这里有个很关键的筛选逻辑失败登录次数多未必等于被攻破但如果某来源IP在同一分钟内尝试了超过10次登录且随后有一次成功登录记录脚本会把这段时间窗口内的所有登录事件单独导出标记为“重点事件”。成功的爆发式暴力破解很容易出现“连续失败后突然成功”的模式。这类事件普通人很少会主动去翻日志脚本能帮忙守住这层防线。4.2 账户与特权变更痕迹攻击者维持权限的重要手段是批量创建账户、修改sudo权限、设置SSH公钥。脚本做三件事找最近7天内账户文件的修改记录stat /etc/passwd /etc/shadow /etc/group /etc/sudoers看 mtime。列出所有具备sudo权限的账户解析/etc/sudoers和/etc/sudoers.d/目录下的文件。扫描所有账户的~/.ssh/authorized_keys标记内容修改时间近90天的文件。最后这项经常能抓到有用的东西。很多入侵者在拿到权限后会往root或者其他高权限账户的authorized_keys里写入自己的公钥这样即使密码改了也能通过密钥重新登录。一个干净系统上这些文件通常是“很久没动过”的如果发现某天突然被修改就要问一句“谁加的、加的谁的”。4.3 进程与自启动项排查恶意程序要在被入侵的系统上存活要么注册成服务、要么写进定时任务、要么常规进程伪装。脚本重点检查这几个位置系统型自启动/etc/systemd/system/、/usr/lib/systemd/system/下最近创建或修改的 unit 文件。定时任务型自启动/var/spool/cron/和/etc/cron.*目录以及 Crontab 内容。当前运行的异常进程和采集阶段拿到的 CPU 基线比较输出 CPU 占用超过 50% 的进程详情。定时任务这里容易翻车因为多行 crontab 里经常有各种维护脚本不全是恶意。脚本只把最近30天内有文件变动痕迹的定时任务单独列出标记为“需确认项”。比如一个/etc/cron.d/下名字随机、内容指向/tmp目录的定时任务这基本可以断定是可疑的因为正常的系统任务不会放在那个位置。4.4 Web后门与文件时间线分析如果被检测的机器运行着 Web 服务脚本会额外扫描 Web 目录下是否存在可疑的 PHP、JSP 等脚本文件。特征检测用两个维度文件名特征x.php、shell.php、1.jsp这类明显不是业务文件的名字。内容特征匹配eval(、base64_decode(、assert(、system(等函数调用且文件比较新。文件时间线分析则是扫描/tmp、/var/tmp、/dev/shm这几个临时目录里最近14天内创建的可执行文件。攻击者在渗透时经常把工具丢在这些目录尤其是/dev/shm它是内存文件系统重启即消失适合临时放东西。如果发现这些目录下有可执行文件脚本会把完整路径、文件大小、修改时间都列出来供人工确认。# 扫描临时目录中的可执行文件 TMP_EXES$(find /tmp /var/tmp /dev/shm -type f -executable -mtime -14 2/dev/null)这段逻辑成本很低但命中率很高。我自己在多个真实环境的排查中都遇到过/tmp里躺着可疑工具的情况而系统管理员之前毫无察觉。4.5 Shell历史与命令审计Shell 历史不是入侵者的首选目标但却是分析师最爱的数据源。脚本汇总/root/.bash_history以及所有活跃账户的.bash_history用关键词匹配筛选危险命令curl或wget加| sh、| bash这种管道执行。chmod x加/tmp等临时目录路径。useradd加奇怪的用户名。iptables -F清空防火墙规则等“关防御”类命令。命中这些关键词时脚本会输出对应账户的历史记录片段和命令执行的大致时间。这里提醒一句历史记录可以被入侵者修改或删除查不到可疑记录不等于没有入侵只能说“如果历史里有异常那是一个很可靠的信号”。5. 完整实操流程与报告解读这一节按真实的执行流程走一遍从拿到脚本到看懂报告全流程梳理。5.1 环境准备与脚本部署脚本依赖的基础工具包括bash、awk、grep、sed、ss、find、stat、curl可选、jq可选用于生成JSON报告。绝大部分系统都自带这些工具不需要额外安装。建议把脚本放到一个独立目录比如/opt/security-audit/同时将报告输出目录单独设置为/var/log/security-audit/避免把检测结果写到 Web 目录或其他容易被外部访问的路径。部署时顺手做一件事用sha256sum计算脚本的校验值并保存到一个安全的地方。保管好这个校验值以后每次执行前对比一次防止脚本本身被篡改。安全检测工具如果自己不安全后果远比不检测更严重。5.2 执行方式与参数说明脚本支持两种执行方式# 快速模式只做漏洞检测和配置核查 sudo ./quantum-audit.sh --quick # 完整模式漏洞检测 入侵痕迹分析 sudo ./quantum-audit.sh --full # 指定输出目录 sudo ./quantum-audit.sh --full --output /data/audit-reports/ # 生成JSON报告便于和其他平台做数据对接 sudo ./quantum-audit.sh --full --json推荐第一次执行用--full拿到完整的基线报告之后日常巡检用--quick就够再隔一个月左右跑一次--full复核。完整模式执行时长取决于磁盘文件数量、日志大小以及Web目录规模一般服务器在几分钟内能跑完。5.3 报告分级与处置优先级报告把风险分成三个等级高危必须立即处理存在拥有 root 权限的非预期账户。关键日志文件缺失或权限异常可能是被清理过的痕迹。Web 目录下发现明确的后门文件。任意账户的authorized_keys在近期被非正常修改。中危应该尽快处理SSH 允许 root 登录且未限制来源IP。高危险端口对外开放Redis、Elasticsearch 等。超过90天的补丁更新空窗期。临时目录中出现来源不明的可执行文件。低危关注并改善密码策略偏弱、密码过期周期过长。审计日志未开启。存在全局可写的文件。报告给出的是“技术层面的风险排序”落地处置时还需要结合业务上下文。比如一台纯内网测试机开着 Redis它的实际风险可能比一台配置了强密码但端口暴露的公网服务器要低这时候就要做综合判断。5.4 一份典型的报告长什么样完整模式跑完文本摘要大致长这样 安全诊断报告 主机名: web-prod-01 系统版本: Ubuntu 22.04.3 LTS 内核版本: 5.15.0-86-generic 最近补丁更新: 2024-08-12距今142天 检测时间: 2025-01-05 14:32:07 [高危] 检测到新建特权账户: backup_admin [高危] 检测到后门文件: /var/www/html/uploads/shell.php [中危] SSH允许root直接登录 [中危] 端口6379监听在0.0.0.0 [低危] 存在3个权限为777的配置文件 [提示] 最近成功登录: 2025-01-05 03:17:12 来自 114.x.x.x 详细结果已输出到 /var/log/security-audit/report_20250105_143207.json 报告结束 看到“最近成功登录”在凌晨三点来源IP和日常工作时间段不符这本身就是一个不得不查的信号。我在实际使用脚本后发现最容易被忽略的信息往往不是列表里“标红”的高危项而是这些交织在一起的时间线线索。6. 常见问题与排查技巧实录记录一些我实际使用过程中遇到的问题以及对应的处理思路。6.1 脚本误报是否多如何处理误报主要集中在这几处Web后门检测会拦到一些正常的加密函数比如使用了base64_decode的PHP框架定时任务检测会把系统自己的轮转任务列出来。处理方式是先看文件的修改时间和上下文再决定是否加入白名单。脚本支持在/opt/security-audit/whitelist.conf中按路径前缀配置白名单命中白名单的条目不再计入风险。6.2 如果日志文件已经被攻击者清空了怎么办日志被清空确实会失去一部分证据但入侵痕迹不会全部消失。这时候重点看这几处进程痕迹恶意程序往往还活着ps auxf和/proc/下的进程信息不会因日志被删而消失。文件系统时间线/tmp和 Web 目录下文件的时间戳、以及最近安装的软件包时间。账户变更时间/etc/passwd和/etc/shadow的 mtime 如果比预期“新”说明最近有改动。Shell历史残留不是每个入侵者都会清历史很多自动化工具只执行命令不清理痕迹。脚本在检测到日志文件缺失时会额外执行一次“深度文件系统扫描”把最近修改文件的清单扩大到 Web 目录之外的用户主目录。这算是一个补强设计专门针对“日志被清理”的场景。6.3 检测应该多久跑一次我的建议核心业务服务器至少每周跑一次--quick每月跑一次--full公网入口和数据库服务器可以再加密一点频率。如果团队人手紧张就把快速模式挂到 cron 里每周一早上一上班看邮件报告。很多入侵动作从发生到被发现窗口期往往超过一星期周更频率已经比大多数团队的发现速度要快了。不过要留意一点挂 cron 的脚本要用绝对路径输出目录要预先创建并设置好权限免得因为环境变量原因导致脚本中途退出。我遇到过 cron 执行时 PATH 不包含/usr/local/bin导致ss命令找不到的案例排查了一阵才定位到。6.4 检测工具自身的防护安全脚本如果被攻击者篡改结果等于零。所以除了之前说的 SHA256 校验值还建议把脚本目录权限设为750属主设为 root并定期检查脚本本身的 mtime。这套脚本没有任何“自动修复”功能一切以检测和报告为准本身也不会修改任何系统配置最大限度降低对生产环境的影响面。6.5 一个真实案例的复盘某次在某测试环境跑--full高危列表里出现了一个从未见过的账户名sysbackUID 为 0。翻看报告里的登录日志这个账户最近一周有三次成功登录记录全部来自公司办公网之外的 IP。顺着文件时间线排查发现/etc/systemd/system/下多了个名字叫httpd-monitor.service的 unit 文件指向/tmp/.X11-unix/下的一个二进制程序。整个过程不到20分钟全靠脚本把散落的信息串成了一条线。如果没有这套自动化检测光靠人肉翻日志很难在一个晚上把这些线索对齐。这次经历后我把例行安全巡检的频率从“事件驱动”改成了“固定周期驱动”并把报告作为运维交接的一部分。这个习惯一直保留到现在也算是个实用建议。7. 最后说点实在的这套脚本设计的初衷不是为了取代安全人员的判断而是把“找线索”这件事做得更快、更全、更不容易漏。我见过太多服务器在“看起来没什么问题”的状态下被攻破仔细查才发现异常登录早在一个月前就出现过只是没人去看日志。有一句话我想强调检测工具的最终目标是让你知道“发生了什么”和“还能不能信任这台机器”这两件事比修复某一个漏洞重要得多。另一个经验是报告生成后不要只看高危项也花两分钟看看中危和低危。安全风险大多数时候不是被某一个高危漏洞击溃的而是若干中危低危问题叠加后形成的通路。今天忽略的一个开放端口可能就是下次事件的大门。如果你准备在自己的环境里使用我的建议是先在一台非核心测试机上跑一遍熟悉报告内容和格式再推广到生产环境。首次完整扫描的结果要好好保存它就是这台服务器的“安全基线”。以后再做检测和这份基线对比反而比逐条核对漏洞库更有意义。