Add files via upload
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
### 如何判断 Log4j 攻击成功
|
||||
|
||||
**1. 应用程序日志排查**
|
||||
|
||||
Log4j 漏洞的本质是利用 JNDI 注入,所以攻击者会在 HTTP 请求头(如 **User-Agent**、**Referer**、**X-Api-Version** 等)中注入恶意字符串
|
||||
|
||||
- **恶意字符串特征**:
|
||||
- `${jndi:ldap://...}`
|
||||
- `${jndi:rmi://...}`
|
||||
- `${jndi:dns://...}`
|
||||
- **排查方法**:
|
||||
- 检查 Web 服务器(如 Nginx, Apache)的 **access.log** 或 **error.log**,以及应用程序自身的日志
|
||||
- 使用 **grep** 命令搜索上述恶意字符串
|
||||
- **示例命令**:`grep -r "jndi:ldap" /var/log/apache2/`
|
||||
|
||||
**2. 外部网络连接排查**
|
||||
|
||||
当 Log4j 漏洞被成功利用后,受影响的应用程序会向攻击者指定的恶意 LDAP/RMI 服务器发起连接,以加载和执行恶意代码
|
||||
|
||||
- **排查方法**:
|
||||
- 检查系统的网络连接日志
|
||||
- 使用 **netstat** 或 **ss** 命令查看是否有异常的、指向外部的 TCP 连接
|
||||
- **示例命令**:`netstat -tulnp | grep LISTEN` 和 `netstat -tulnp | grep ESTABLISHED`
|
||||
- **需要警惕的连接**:
|
||||
- 应用程序进程(如 Java)发起的、指向高端口(例如 8080、9001 等)的外部连接
|
||||
- 那些不是正常业务所需、但由 Java 进程发起的异常连接
|
||||
|
||||
**3. 进程行为排查**
|
||||
|
||||
如果攻击者成功加载并执行了恶意代码,通常会产生新的进程。这些进程可能是反向 Shell、挖矿程序或其他的后门程序
|
||||
|
||||
- **排查方法**:
|
||||
- 使用 **ps -ef** 或 **top** 命令检查正在运行的进程
|
||||
- 关注与 Java 父进程不相关的、异常的子进程。例如,Java 进程下启动了一个名为 `bash` 或 `sh` 的子进程
|
||||
- **重点关注**:
|
||||
- **异常的进程名**:如 `httpd-`、`kdevtmpfsi` 等,这些通常是挖矿程序的伪装名
|
||||
- **异常的 CPU 和内存占用**:如果发现某个进程(尤其是非正常业务进程)占用了大量 CPU 资源,可能是挖矿程序
|
||||
|
||||
**4. 系统文件和计划任务排查**
|
||||
|
||||
攻击者为了实现持久化控制,通常会在系统中留下后门
|
||||
|
||||
- **排查方法**:
|
||||
- 检查 **/tmp** 或 **/var/tmp** 目录下是否有异常的可执行文件或脚本
|
||||
- 检查 **cron** 计划任务(如 **/etc/cron.d/**)或 Windows 的任务计划程序,看是否有可疑的定时任务
|
||||
- 检查用户的 **~/.ssh/authorized_keys** 文件,看是否被添加了未知的公钥
|
||||
Reference in New Issue
Block a user