diff --git a/Chapter7/7-1.md b/Chapter7/7-1.md new file mode 100644 index 0000000..8feda81 --- /dev/null +++ b/Chapter7/7-1.md @@ -0,0 +1,55 @@ +### 内存马查杀思路 + +在查杀之前，首先要了解内存马的常见类型。它们通常可以分为以下几类： + +- **Filter/Servlet 类型：** 攻击者通过向 Web 容器（如 Tomcat）动态注册恶意 Filter 或 Servlet，来实现持久化控制 +- **Listener 类型：** 攻击者通过注册恶意 Listener，在特定事件发生时触发恶意代码 +- **Java Agent/Instrumentation 类型：** 这种技术可以在不修改字节码的情况下，在 JVM 运行时对已加载的类进行修改，实现更隐蔽的注入 + +**第一步：何时打进来的？** + +1. **流量分析：**监控 Web 服务器的流量。如果发现异常的 HTTP 请求，比如带有很多不寻常参数的请求，或者与正常业务逻辑不符的 URL 访问，都可能是内存马的征兆 + + 1.1 `http://your-app.com/shell.do?pwd=a1b2c3d4&cmd=whoami` + +2. **日志分析：** 检查 Web 服务器（如 Tomcat）的访问日志。如果发现一些不寻常的请求，并且这些请求没有在正常的 Servlet 或 Controller 中找到对应的处理逻辑，那么很可能是内存马在处理这些请求 + + 2.1 检查 Tomcat 的 `access_log`，发现有对 `/static/12345.css` 的请求，但该文件并不存在于硬盘上。如果这个请求的返回状态码是 200，而不是预期的 404，那么很可能是一个 Filter 内存马在默默处理这个请求 + +3. **CPU/内存异常：**内存马通常会消耗额外的系统资源。如果 Web 服务器的 CPU 或内存使用率突然升高，并且没有对应的业务高峰，需要警惕 + + 3.1 在没有业务高峰的情况下，CPU 占用率持续飙升到 90% 以上，同时内存使用量也快速增长 + +4. **工具扫描：**使用专业的 Java 安全工具或 Agent 进行扫描 + +**第二步：内存马具体位置？** + +1. 使用内存分析工具：jmap、Artha、BTrace/jfr + + 1.1 **jmap：**使用 `jmap` 可以生成 Java 堆内存的 dump 文件。通过分析这个文件，可以找到异常的对象实例 + + 1.2 **Arthas：**Arthas是一款非常强大的 Java 诊断工具。它可以在不重启应用的情况下，定位和排查问题 + + - 使用 **`sc`**（`search class`）命令查找可疑的类。例如，`sc -d org.apache.catalina.core.ApplicationContext` 可以查看 Web 容器的上下文 + - 使用 **`jad`**（`decompile`）命令反编译可疑的类，查看其代码逻辑 + - 使用 **`trace`** 和 **`watch`** 命令跟踪特定方法的调用，观察参数和返回值，判断是否有异常行为 + + 1.3 **BTrace/jfr：** 这些工具可以用于动态地跟踪 JVM 运行时行为，帮助你定位恶意代码的注入点 + +2. **检查 Web 容器注册表：**对于 Tomcat，可以检查其内部注册的 Filter、Servlet、Listener 等 + + 2.1 在 Tomcat 8 及更高版本中，可以通过 `org.apache.catalina.core.ApplicationContext` 类的 `filterConfigs`、`servletConfigs` 等字段，或者直接通过反射获取这些注册信息 + +3. **排查自定义 ClassLoader：**恶意代码可能会使用自定义的 `ClassLoader` 来加载恶意类，以绕过常规的类加载器 + + 3.1 可以通过 `jmap -clstats` 或者 Arthas 的 `classloader` 命令，查看 JVM 中存在的 `ClassLoader` 实例。如果发现一些不寻常的 `ClassLoader`，需要重点关注 + +**第三步：西内！！！** + +1. **内存中直接删除：**使用 Arthas 等工具，可以通过命令直接移除恶意对象。例如，可以调用 `ApplicationContext` 的 `removeFilterDef`、`removeServletDef` 等方法，或者通过反射将恶意实例从注册表中移除 + + 1.1 `ognl '#context=@org.apache.catalina.core.ApplicationContext@ApplicationContext, #context.removeFilterDef("filter_12345"), #context.removeFilterMap("filter_12345")'` + +2. **重启 Web 应用：**这是最直接也最彻底的清除方法。因为内存马是驻留在内存中的，重启应用会清空内存，所有恶意代码都会被清除 + + 2.2 找到 Java 进程 ID，使用 `kill -9 ` 或者通过 Tomcat 的 `shutdown.sh` 脚本关闭，然后再通过 `startup.sh` 启动 diff --git a/Chapter7/7-10.md b/Chapter7/7-10.md new file mode 100644 index 0000000..e1834b1 --- /dev/null +++ b/Chapter7/7-10.md @@ -0,0 +1,22 @@ +### 拿到攻击者 IP 怎么溯源 + +**第一步：信息收集** + +这一步是溯源的基础，我们通过已有的安全日志和数据包，快速获取攻击者的初步信息 + +- **获取攻击者 IP 和攻击方式**：这是溯源的起点。你需要从 Web 服务器日志、WAF、IPS、蜜罐等安全设备中，提取出攻击者的源 IP 地址，并分析其攻击方式（如 SQL 注入、命令执行、WebShell 上传等） +- **威胁情报平台分析**：利用威胁情报平台（如微步、安恒威胁情报中心、VirusTotal）对攻击者 IP 进行快速检测 + - **判断 IP 性质**：它是一个常规的云服务器、代理IP，还是已知的恶意 IP？ + - **获取基础信息**：查看IP地址的归属地（国家、地区）、所属的 ISP（互联网服务提供商） + - **端口和服务探测**：利用 Shodan 等工具，探测该 IP 地址开放了哪些端口，运行着哪些服务，这有助于了解该 IP 是否被用作 C&C 服务器或其他恶意用途 + +**第二步：反制** + +在获取初步信息后，我们需要进行更深层次的关联分析，试图找到更多关于攻击者的线索 + +- **域名和 Whois 查询**：如果攻击者使用了特定的域名，或者你通过日志关联到了一些域名，利用 `WHOIS` 查询这些域名的注册信息。这可能提供注册人的姓名、邮箱或电话，为后续的社工提供线索 +- **反向渗透**：如果攻击者 IP 是云服务器，你可以对其进行**有限制的反向渗透** + - **服务探测**：探测服务器上运行的服务，看是否有未知的 WebShell、木马或 C&C 通信 + - **目录遍历**：尝试访问一些常见的 WebShell 路径或目录，看是否有意外发现 + - **注意**：反向渗透有法律风险，必须非常谨慎，通常仅限于对公开服务进行被动侦查 +- **流量和网络路径追踪**：利用 `traceroute`、`ping` 等工具，可以追踪攻击流量经过的路由器、网关和 ISP 等信息。这能帮助我们了解攻击流量的来源地点，并验证其 IP 地址的真实性 \ No newline at end of file diff --git a/Chapter7/7-11.md b/Chapter7/7-11.md new file mode 100644 index 0000000..580941c --- /dev/null +++ b/Chapter7/7-11.md @@ -0,0 +1,44 @@ +### 内网报警处理方式 + +第一步：确认与隔离 + +- **确认报警的真实性**：收到内网报警后，首先要核实报警是否为误报。查看报警日志的详细信息，例如源IP、目标 IP、端口、协议、以及告警类型。与业务部门或相关人员沟通，确认报警行为是否属于正常的业务操作 +- **物理或逻辑隔离**：如果确认报警是恶意行为，必须立即隔离涉事主机。你可以通过关闭网络端口、在交换机或防火墙上设置 ACL 规则、甚至直接拔掉网线来物理或逻辑上切断该主机与网络的连接。这能有效防止攻击者进行横向移动，或恶意行为继续蔓延 + +**第二步：信息收集与初步分析** + +在隔离主机后，立即对该主机进行信息收集，为后续的分析和取证做准备 + +- **检查进程和网络连接**：使用 `netstat -anp`、`ps -ef` 等命令查看主机上是否有异常进程和网络连接。特别留意那些非正常业务进程、向外部或内网其他主机发起的连接 +- **查看日志文件**： + - **系统日志**：检查 `/var/log/secure`（Linux）或 Windows 事件日志，寻找异常登录、提权、或可疑的用户行为 + - **应用日志**：检查 Web 服务器、数据库等应用日志，看是否有异常请求或操作记录 +- **文件系统检查**： + - **近期修改文件**：使用 `find / -mtime -1` 等命令查找最近创建或修改过的可疑文件，这可能与攻击者上传的后门或工具相关 + - **敏感文件**：检查 `/tmp`、`/var/tmp` 等临时目录，看是否有恶意程序或脚本 + +**第三步：深入分析与研判** + +在收集完基础信息后，需要对这些信息进行深入分析，以确定攻击者的身份和攻击目的 + +- **溯源攻击者**： + - **IP 溯源**：如果报警源是内网 IP，可以根据该 IP 地址的分配规则或资产管理系统，定位到具体的楼层、办公室或设备 + - **用户账户**：通过查看登录日志、堡垒机日志或应用日志，定位到具体的操作账户。如果该账户属于某个员工，还需要进一步核实是其本人操作，还是账户被盗用 +- **确定攻击意图**： + - **数据窃取**：检查是否有大量数据被打包或传输到外部 + - **横向移动**：查看攻击者是否尝试连接内网其他主机，这可能是为了扩大攻击范围 + - **恶意破坏**：检查是否有关键文件被删除、修改，或系统配置被篡改 + +**第四步：清除、修复与加固** + +在明确了攻击者的身份和意图后，就可以着手进行全面的清除、修复和加固工作 + +- **恶意代码清除**： + - **杀死恶意进程**：通过 `kill` 命令或任务管理器结束恶意进程 + - **删除恶意文件**：彻底删除所有后门程序、木马、恶意脚本和上传的 WebShell +- **漏洞修复**： + - **修复漏洞**：如果是通过漏洞入侵，需要立即修复该漏洞 + - **修改密码**：如果账户被盗用，立即修改所有相关账户的密码 +- **安全加固**： + - **权限收紧**：对账户权限进行重新审计，遵循最小权限原则，限制不必要的访问权限 + - **升级系统与补丁**：安装所有必要的系统和应用补丁，提升系统安全性 \ No newline at end of file diff --git a/Chapter7/7-12.md b/Chapter7/7-12.md new file mode 100644 index 0000000..bc653ec --- /dev/null +++ b/Chapter7/7-12.md @@ -0,0 +1,22 @@ +### 怎样从日志找 WebShell 位置 + +**第一步：排查 Web 服务器访问日志（access.log）** + +WebShell 需要通过 HTTP 请求来执行命令，因此会在 Web 服务器的访问日志中留下痕迹。这是定位 WebShell 位置最直接的方法 + +- **异常请求状态码**：一个成功的 WebShell 文件通常会被频繁访问，并返回 `200` 状态码。而正常的网站文件，尤其是那些不应该被直接访问的脚本文件，如果返回了 `200`，就很可疑 +- **异常请求路径**：WebShell 的路径通常很奇怪，不符合正常的业务规则。例如： + - **深度目录**：`www.example.com/images/uploads/2023/shell.php` + - **随机文件名**：`www.example.com/1a2b3c4d.jsp` + - **伪装文件名**：`www.example.com/test.jpg.php` +- **异常请求参数**：WebShell 的请求参数通常会包含一些命令执行的关键字，例如 `?cmd=...`、`?exec=...` 或 `?id=...` +- **异常 User-Agent**：攻击者可能使用特定的工具或脚本来访问 WebShell，其 User-Agent 字段可能不正常 + +**第二步：排查 Web 服务器错误日志（error.log）** + +WebShell 可能会在运行中产生错误，这些错误通常会被记录在错误日志中 + +- **PHP 错误**：如果一个 PHP 文件尝试执行一个它没有权限执行的操作，或者语法错误，错误日志中会记录下该文件的完整路径。例如：`PHP Warning: file_put_contents(/var/www/html/malicious_file.php): failed to open stream: Permission denied in /var/www/html/upload/shell.php on line 10` +- **Java 异常**：对于 Java Web 应用，WebShell 可能会抛出异常，错误日志会显示异常发生的类名和路径 + +通过这些错误信息，可以快速定位到可疑文件的具体位置 \ No newline at end of file diff --git a/Chapter7/7-13.md b/Chapter7/7-13.md new file mode 100644 index 0000000..d3002bb --- /dev/null +++ b/Chapter7/7-13.md @@ -0,0 +1,13 @@ +### 常见日志分析工具 + +**日志管理与分析平台 (SIEM)** + +这些平台能够集中收集、存储、分析和管理来自多个设备（服务器、防火墙、WAF等）的日志，是企业级安全监控的核心 + +- **ELK Stack (Elasticsearch, Logstash, Kibana)**: 这是目前最流行的开源日志分析解决方案 + - **Logstash**: 负责从各种来源收集、处理日志 + - **Elasticsearch**: 强大的分布式搜索引擎，用于存储和搜索海量日志数据 + - **Kibana**: 提供友好的Web界面，用于可视化分析、搜索和创建仪表盘 +- **Splunk**: 一款功能强大的商业日志分析平台。它提供了一个直观的界面和丰富的搜索语言，能够快速从海量数据中发现异常模式和安全威胁。Splunk拥有强大的报告和报警功能，但成本较高 +- **Graylog**: 一款功能与ELK类似的开源日志管理平台。它提供了日志收集、存储、搜索和报警等功能，并且界面友好，易于部署和管理 +- **Tenzir**: 能够将各种数据源的数据（包括日志）解析、存储和分析为通用的“事件”格式，便于安全分析 \ No newline at end of file diff --git a/Chapter7/7-14.md b/Chapter7/7-14.md new file mode 100644 index 0000000..276ef94 --- /dev/null +++ b/Chapter7/7-14.md @@ -0,0 +1,43 @@ +### 网页挂马排查思路 + +**第一步：定位恶意代码位置** + +挂马代码通常被注入到网站的静态页面或数据库中 + +- **查看网站源代码**： + - **比对原始文件**：从备份中恢复网站的原始文件，然后与当前服务器上的文件进行比对。使用 `diff` 或 `Beyond Compare` 等工具可以快速找出被修改过的文件 + - **查找可疑关键字**：在网站所有文件中搜索一些可疑的 HTML 标签或 JavaScript 代码，例如： + - ``），强制所有脚本都以文件的形式加载 +- **X-XSS-Protection**：这是一个 HTTP 响应头，可以启用浏览器内置的 XSS 过滤器。虽然它不是一个完美的解决方案，但在一些旧版浏览器中仍然有一定作用 \ No newline at end of file diff --git a/Chapter7/7-16.md b/Chapter7/7-16.md new file mode 100644 index 0000000..0ead33c --- /dev/null +++ b/Chapter7/7-16.md @@ -0,0 +1,58 @@ +### CSRF 防御方法 + +**1. 验证 HTTP Referer** + +`Referer` 是 HTTP 请求头中的一个字段，它记录了请求的来源页面。通过检查 `Referer`，可以判断请求是否来自可信的域名 + +- **优点**：简单、易于实现 +- **缺点**： + - **不可靠**：`Referer` 字段可以被伪造或被某些浏览器、安全软件禁用 + - **隐私问题**：在某些情况下，浏览器可能不会发送 `Referer` 头，导致正常请求被阻止 + +**2. 添加 CSRF Token（推荐）** + +这是防御 CSRF 最有效、最普遍的方法。CSRF Token 是一个随机生成的、只有服务器和用户端知道的令牌 + +- **工作原理**： + 1. 当用户访问一个页面时，服务器会生成一个唯一的、随机的 CSRF Token，并将其嵌入到表单中 + 2. 当用户提交表单时，这个 Token 会随请求一起发送到服务器 + 3. 服务器在处理请求前，会验证该 Token 是否有效。如果 Token 缺失或不匹配，请求就会被拒绝 +- **优点**： + - **安全性高**：攻击者无法获取用户的 Token，因此无法伪造有效的请求 + - **可防御跨站请求**：即使攻击者能诱导用户访问恶意网站，也无法获取到正确的 Token +- **实现方式**： + - **Session Token**：将 Token 存储在用户的 Session 中 + - **双重提交Cookie**：将 Token 同时存放在 Cookie 和请求参数中 + +**3. 在 HTTP 头中使用自定义属性** + +现代 Web 应用框架，如 Spring、Django 等，通常会内置 CSRF 防御机制。它们会在请求中添加一个自定义的 HTTP 头，并由服务器进行验证 + +- **工作原理**：当用户发送 AJAX 请求时，框架会自动在请求头中添加一个自定义属性，如 `X-CSRFToken`。服务器在接收请求后，会验证该 Token 是否正确 +- **优点**： + - **方便**：对于使用这些框架的开发者来说，实现起来非常简单 + - **不受 `Referer` 影响**：不依赖于浏览器的 `Referer` 头 + +**4. 验证码机制** + +在一些关键操作（如修改密码、转账）中，要求用户输入验证码，可以有效防止 CSRF 攻击 + +- **优点**： + - **安全性高**：验证码需要人工输入，无法被自动化 + - **简单直观**：用户容易理解 +- **缺点**： + - **用户体验差**：在每次操作时都要求输入验证码，会降低用户体验 + - **不适用于所有场景**：不适合频繁或批量操作 + +**5. Samesite Cookie 属性** + +`SameSite` 是一个 HTTP Cookie 属性，它可以限制 Cookie 在跨站点请求中的发送行为 + +- **工作原理**： + - **Strict**：最严格的模式，浏览器在跨站点请求时不会发送 Cookie，可以有效防御 CSRF + - **Lax**：相对宽松的模式，在顶级导航 GET 请求（如点击链接）时会发送 Cookie，但在其他情况下不会 +- **优点**： + - **浏览器原生支持**：不需要额外开发 + - **简单有效**：可以作为 CSRF 防御的第一道防线 +- **缺点**： + - **兼容性问题**：在一些旧版浏览器中可能不受支持 \ No newline at end of file diff --git a/Chapter7/7-17.md b/Chapter7/7-17.md new file mode 100644 index 0000000..e6c58d4 --- /dev/null +++ b/Chapter7/7-17.md @@ -0,0 +1,41 @@ +### SSRF 防御方法 + +**1. 验证用户输入的 URL** + +任何由用户提供的 URL，在服务端发起请求前，都必须经过严格的验证 + +- **白名单验证**：这是最安全的方法。只允许用户请求预先定义好的、可信的 URL 或 IP 地址。如果用户输入的 URL不在白名单中，就直接拒绝请求 +- **黑名单过滤**：过滤掉一些危险的 IP 地址、域名或端口。例如，过滤掉 `127.0.0.1`、`localhost`、`10.0.0.0/8`、`172.16.0.0/12`、`192.168.0.0/16` 等内网 IP 地址，以及一些高危端口如 `22`（SSH）、`3306`（MySQL）等。但是，黑名单很容易被绕过，不推荐作为唯一的防御手段 + +**2. 禁止 URL 重定向** + +许多 SSRF 攻击利用了 URL 重定向。攻击者可以提供一个外部 URL，当服务器访问它时，会被重定向到内网地址 + +- **防御方法**：在服务端代码中，**禁止自动处理URL重定向**。如果需要，应该手动检查重定向后的 URL 是否符合安全策略，例如是否指向了内网地址 + +**3. 对返回内容进行处理** + +即使攻击者成功利用了 SSRF 漏洞，我们也可以通过限制返回内容来降低风险 + +- **过滤敏感信息**：在将请求的返回内容展示给用户之前，过滤掉敏感信息，例如内网服务的详细报错信息、版本号等 +- **统一错误页面**：如果请求失败，只返回一个通用的错误页面，而不透露任何内部信息 + +**4. 最小权限原则** + +运行服务的用户和网络权限应该被严格控制 + +- **网络权限**：如果某个服务不需要访问内网资源，可以在防火墙或安全组上设置规则，**禁止其访问内网 IP** +- **服务权限**：如果某个服务只需要访问特定的外部域名，可以配置 DNS 或主机文件，将该域名解析到特定的 IP 地址，防止解析到其他恶意 IP + +**5. 使用 DNS Rebinding 防御** + +DNS Rebinding 是一种高级的 SSRF 攻击，攻击者利用 DNS 解析的特性，让服务器第一次解析时返回一个外部 IP，第二次解析时返回一个内网 IP，从而绕过防火墙的检测 + +- **防御方法**：在服务端发起请求时，首先将域名解析为 IP 地址，然后**将该 IP 地址与白名单进行比对**。在后续的请求中，都只使用这个已验证的 IP 地址，而不再次进行 DNS 解析 + +**6. 使用专门的 URL 请求库** + +使用安全的 URL 请求库，这些库通常会提供更高级的 SSRF 防御功能，例如： + +- **内置的 IP 地址校验**：可以自动识别并阻止对私有 IP 地址的请求 +- **强制使用 IP 地址**：可以配置为只接受 IP 地址作为请求目标，而不是域名，从而避免 DNS Rebinding 攻击 \ No newline at end of file diff --git a/Chapter7/7-18.md b/Chapter7/7-18.md new file mode 100644 index 0000000..be86dd6 --- /dev/null +++ b/Chapter7/7-18.md @@ -0,0 +1,7 @@ +### XXE 防御方法 + +**通用防御思路** + +- **禁用外部实体（External Entities）**：这是最根本的防御措施。确保你的 XML 解析器不会去解析 `` 中定义的外部实体 +- **禁用 DTD（Document Type Definition）**：如果业务逻辑不需要 DTD，直接禁用它能彻底解决 XXE 问题 +- **使用最新版本的解析库**：新的 XML 解析库通常会默认禁用 XXE 相关功能，或提供更安全的配置选项 \ No newline at end of file diff --git a/Chapter7/7-19.md b/Chapter7/7-19.md new file mode 100644 index 0000000..22afb4b --- /dev/null +++ b/Chapter7/7-19.md @@ -0,0 +1,35 @@ +### 文件上传防御方法 + +**1. 客户端验证** + +客户端验证通常指通过 JavaScript 在前端对文件进行检查 + +- **优点**：可以快速、友好地提示用户，减少不必要的服务器请求，提升用户体验 +- **缺点**：非常容易绕过。攻击者可以通过抓包工具（如 Burp Suite）修改 HTTP 请求，或直接禁用 JavaScript。因此，**客户端验证绝对不能作为唯一的安全措施** + +常见的客户端验证包括： + +- **文件扩展名验证**：检查文件的扩展名是否为允许的类型（如`.jpg`, `.png`, `.pdf`） +- **MIME类型验证**：检查文件的 MIME 类型（如 `image/jpeg`, `application/pdf`） +- **文件大小验证**：限制上传文件的大小，防止恶意文件过大导致服务器资源耗尽 + +**2. 服务器端验证** + +服务器端验证是防御文件上传漏洞的最后一道防线，也是最可靠的 + +- **文件扩展名白名单验证**：**强烈推荐使用白名单**。只允许上传特定、已知的安全扩展名，如 `.jpg`, `.png`, `.gif`, `.pdf`, `.zip` 等。**绝对不要使用黑名单**，因为攻击者总能找到新的绕过方式 +- **MIME 类型验证**：在服务器端验证文件头的 MIME 类型，防止攻击者通过伪造扩展名来上传恶意文件 +- **文件内容检测**：对上传的文件内容进行深度检查 + - **图片**：使用 `getimagesize()` 等函数检测文件是否为真实的图片文件 + - **压缩包**：检查压缩包中的文件列表，确保没有可执行文件或恶意脚本 +- **文件重命名**：在文件上传后，对其进行重命名，通常是使用一个随机字符串或加密哈希值作为文件名，并去除原始扩展名。这能有效防止攻击者通过文件名猜测 WebShell 的路径 + +**3. 文件存储与执行权限控制** + +即使恶意文件侥幸通过了所有验证，我们仍然可以通过权限控制来阻止它被执行。 + +- **分离存储与执行**：将用户上传的文件存储在**非Web根目录**下。这样，即使攻击者知道文件路径，也无法通过URL直接访问或执行。 +- **禁止执行权限**：将上传文件的目录设置为**不可执行**。在Nginx或Apache中，可以通过配置来禁止特定目录执行脚本文件。 + - **Nginx**：在配置文件中添加 `location` 规则，并设置 `deny all;` 或 `deny execution;`。 + - **Apache**：在 `.htaccess` 文件中添加 `php_flag engine off` 或类似的规则。 +- **最小权限原则**：Web服务器进程（如Nginx、Apache）应以低权限用户运行，并确保其对上传目录只有**写入**权限，而**没有执行**权限。 \ No newline at end of file diff --git a/Chapter7/7-2.md b/Chapter7/7-2.md new file mode 100644 index 0000000..9d1fdfb --- /dev/null +++ b/Chapter7/7-2.md @@ -0,0 +1,13 @@ +### Linux 日志存放位置 + +以下是一些重要日志文件及其作用： + +- **/var/log/messages** 或 **/var/log/syslog**：记录系统级别的一般性消息，例如内核消息、系统服务启动/停止、硬件故障等 +- **/var/log/secure** 或 **/var/log/auth.log**：记录与用户身份验证和安全相关的事件，例如登录尝试（成功或失败）、sudo 命令使用等 +- **/var/log/boot.log**：记录系统启动过程中的日志 +- **/var/log/dmesg**：记录内核环缓冲区中的消息，可以查看系统启动时硬件检测和驱动加载的信息 +- **/var/log/lastlog**：记录每个用户最后一次登录的信息，可以通过 **lastlog** 命令查看 +- **/var/log/wtmp** 和 **/var/log/btmp**：以二进制格式记录用户登录和注销的信息，可以使用 **who**、**w** 和 **last** 命令来查看 + - **wtmp**：记录所有登录和注销事件 + - **btmp**：记录所有失败的登录尝试 +- **Web 服务器日志**：例如 Apache 或 Nginx 的日志通常在 **/var/log/httpd/** 或 **/var/log/nginx/** 目录下，包括访问日志（access.log）和错误日志（error.log） \ No newline at end of file diff --git a/Chapter7/7-20.md b/Chapter7/7-20.md new file mode 100644 index 0000000..fc7b503 --- /dev/null +++ b/Chapter7/7-20.md @@ -0,0 +1,40 @@ +### CS 流量特征 + +**一、HTTP/HTTPS 通信特征** + +CS 的核心通信依赖 HTTP/HTTPS，其请求和响应具有以下独特之处： + +- **请求路径 (URI)** + - **默认路径**：早期的 CS 版本使用如 `/api/rc4`、`/pixel` 等明显特征的路径。虽然现在已不常见，但在老旧的、未及时更新的 CS 木马中仍可能出现 + - **伪装路径**：高级攻击者会配置 **Profile**，将路径伪装成正常的 URL，如 `/login`、`/css/main.css`。此时，检测的关键于**路径与请求方法的合理性**。例如，`POST /css/main.css` 或 `GET /submit` 都是极度可疑的行为 + - **长度与随机性**：某些配置文件会生成长而随机的路径，例如 `/hjd83kalsd94jfnnasd83jklfn`。在高频访问中，这种随机性反而成为一种异常 +- **User-Agent (UA)** + - **默认 UA**：早期的 CS 使用一些固定的、容易被识别的 UA 字符串 + - **伪造 UA**：攻击者会伪装成常见的浏览器 UA，如 Chrome、Firefox。然而，可以从**一致性和时效性**来判断：如果来自同一 C2 的所有 Beacon 都使用完全相同的、且已过时的 UA 字符串，则很可能存在 CS 攻击 + +**二、TLS 证书与指纹特征** + +如果 CS 使用 HTTPS 进行通信，其 TLS/SSL 证书会留下独特的指纹，这是非常强的检测指标 + +- **默认证书**：CS 服务器默认使用**自签名证书**，其 `Subject` 字段通常带有明显的默认值，例如 `CN=Major C. A. Lindheim` 或 `O=Internet Widgits Pty Ltd` +- **JARM 指纹**：这是一种主动 TLS 指纹识别技术。CS 的默认配置具有非常固定的 JARM 指纹。即使攻击者修改了证书的主题信息，默认的 JARM 指纹在很长一段时间内仍保持不变，这使得 JARM 成为检测 CS 最有效的手段之一 +- **证书透明度（CT）日志**：如果攻击者使用了看似合法的域名并申请了证书，我们可以通过检查该域名是否出现在 CT 日志中，来进一步确认和溯源 + +**三、请求与响应行为特征** + +CS 的 HTTP 通信并非简单的请求-响应，而是一种高度规律性的“心跳”模式 + +- **心跳模式**：Beacon 会以固定的时间间隔（如 10s、60s）向 C2 服务器发送请求。这种高度规律性的、永不停止的通信模式，即使在机器空闲时也存在，与正常用户行为截然不同 +- **请求与响应载荷**：心跳请求的载荷（如 Cookie、POST 数据）长度可能固定不变。而当服务器下发指令时，响应包的长度会变长。回传数据时，客户端则会发送一个 POST 请求，其 Body 部分经过加密和 Base64 编码 +- **HTTP 状态码**：CS C2 服务器的 HTTP 响应状态码绝大多数情况下都是 **200 OK**，即使请求是无效的。这是其反侦察的手段之一，与正常服务器对错误请求返回 404/500 的行为形成鲜明对比。 + +**四、DNS 与横向移动** + +为了绕过传统安全设备的检测，CS 提供了更高级的通信方式和行为模式 + +- **DNS Beacon** + - **查询类型**：通常使用 `TXT` 和 `AAAA` 记录进行数据传输，`A` 记录用于心跳 + - **子域名爆破**：Beacon 会频繁对特定域名进行 DNS 查询，查询的前缀是长而随机的字符串，用于编码数据 + - **查询频率**：与 HTTP 类似，具有固定的心跳间隔，产生持续、规律的 DNS 查询流量 +- **横向移动** + - **SMB/TCP Beacon**：用于在内网中横向移动，它们会创建命名管道或监听特定端口。异常的命名管道或内部端口连接行为是重要的检测指标 \ No newline at end of file diff --git a/Chapter7/7-21.md b/Chapter7/7-21.md new file mode 100644 index 0000000..724afba --- /dev/null +++ b/Chapter7/7-21.md @@ -0,0 +1,66 @@ +### WebShell 工具流量特征 + +**1. 蚁剑（AntSword）** + +蚁剑是一款功能强大且高度可定制的开源 WebShell 管理工具。它的流量特征主要依赖于其**编码器（Encoder）**和**连接器（Connector）**的配置 + +- **默认流量特征**： + - **POST 请求**：蚁剑通常使用 `POST` 请求，将恶意代码和命令作为参数发送 + - **加密与编码**：默认情况下，蚁剑会使用 `base64` 对数据进行编码。在流量中，可以看到一个或多个经过 `base64` 编码的参数，其值通常是 `eval()` 或 `system()` 等函数 + - **特定标识**：在某些默认的编码器中，参数名可能会包含特定字符串，但由于其高度可定制，这并非可靠的识别依据 + +**2. 哥斯拉（Godzilla）** + +哥斯拉是一个强大的 WebShell 管理工具，其核心特点是**无文件内存马**和**加密通信** + +- **流量特征**： + - **内存马通信**：哥斯拉的 WebShell 本身通常是一个无文件马，注入到 Web 容器的内存中。这意味着它没有落地文件，传统的文件查杀方法无效 + - **加密与伪装**：哥斯拉的流量与冰蝎类似，同样是**加密**的，并且其请求头可以高度定制，以伪装成正常的流量 + - **可变参数**：与冰蝎不同，哥斯拉的请求参数和值可能会**发生变化**，这使得基于参数名的检测变得困难 + +**3. 中国菜刀（Chopper）** + +中国菜刀是一款老牌且经典的 WebShell 管理工具。它的流量特征**非常明显**，是传统 WAF 和 IDS 重点防御的对象 + +- **流量特征**： + - **明文传输**：菜刀的流量通常是**明文**的。它使用 `base64` 编码，但没有进行加密 + - **特定参数**：它会固定使用一个名为 `z0`、`z1` 或其他简单字符的参数来传递恶意代码 + - **URL请求特征**：菜刀的URL请求中通常会包含 `eval()`、`assert()` 等关键字，这些关键字是其命令执行的标志 + - **固定请求头**：菜刀的 `User-Agent` 字段通常是固定的，例如 `User-Agent: baiduspider`。 + +**4. 冰蝎 v1.0** + +冰蝎的第一个版本，其流量特征相对简单，容易被传统的安全设备检测到 + +- **通信方式**：使用 `AES` 加密，密钥固定为 `0x24` +- **请求特征**：URL 中带有 `?pass=xxx` 参数，其中 `pass` 是加密密钥的标识符 +- **响应特征**：服务器返回的数据也是加密的，但由于其加密算法简单，很容易被解密分析 + +**5. 冰蝎 v2.0** + +冰蝎 v2.0 在 v1.0 的基础上进行了重大改进，旨在增强隐蔽性 + +- **通信方式**：引入了 **动态密钥**。在首次连接时，客户端会发送一个包含随机 `user-agent` 和 `cookie` 的请求，服务器根据这些信息生成一个 AES 加密密钥，并在后续通信中使用 +- **请求特征**： + - **无固定参数**：URL 中不再有明显的 `?pass=` 参数，取而代之的是将加密数据隐藏在请求头中 + - **伪装请求头**：`user-agent`、`cookie` 等请求头的值都是随机生成的，以模仿正常的浏览器行为 + +**6. 冰蝎 v3.0** + +这是目前最常见且最具威胁的版本，它在 v2.0 的基础上进一步升级了通信协议，大大增加了检测难度 + +- **通信方式**：引入了**双向加密和随机密钥**，通信过程更为复杂。客户端和服务器会进行一次类似于 TLS 握手的加密协商过程 +- **流量特征**： + - **无固定长度**：与 v2.0 不同，v3.0 的数据包长度不再固定，而是随着传输数据的大小而变化。这使得基于数据包长度的检测方法失效 + - **伪装通信**：v3.0 的通信流量可以伪装成各种协议，例如 **WebSocket、HTTP2** 等，以逃避传统的网络流量分析工具 + - **请求参数**：v3.0 不再将加密数据放在请求头，而是将其隐藏在**请求体**中，并且可以通过定制来伪装成正常表单提交或 JSON 数据 + - **TLS 指纹**：如果使用 HTTPS，v3.0 的自签名证书和 TLS 握手过程会产生独特的指纹。然而，攻击者可以通过定制 `Malleable C2` Profile 来改变这些指纹 + +**7. 冰蝎 v4.0** + +冰蝎 v4.0 在隐蔽性上更上一层楼，主要增强了**免杀和无文件攻击**能力 + +- **通信方式**：继续沿用 v3.0 的加密通信协议，但加入了更高级的内存马技术 +- **流量特征**： + - **无文件落地**：v4.0 的 WebShell 通常是一个无文件马，直接注入到 Web 容器的内存中。这意味着它没有落地文件，无法通过文件查杀来定位 + - **流量混淆**：利用**多层混淆和编码**，使得流量分析变得极其困难 \ No newline at end of file diff --git a/Chapter7/7-22.md b/Chapter7/7-22.md new file mode 100644 index 0000000..c9d908c --- /dev/null +++ b/Chapter7/7-22.md @@ -0,0 +1,68 @@ +### 日志被删除如何排查 + +**1. 内存取证 (Memory Forensics)** + +这是最重要的一个步骤，也是最可能找到线索的地方 + +**措施：** + +- **日志进程的内存：** 即使日志文件被删除，日志服务（如 `rsyslogd`、`journald` 等）在运行时，其内存中可能仍然保留着最近的日志记录 +- **文件系统缓存：** 操作系统内核在删除文件后，可能不会立即清除其在内存中的缓存 +- **进程活动：** 攻击者执行删除命令（例如 `rm -rf /var/log/*`）的进程信息，以及该进程的父进程、子进程，都可能存在于内存中 + +**操作方法：** + +1. **紧急制作内存镜像：** 在不重启系统的情况下，使用工具（如 **`LiME`**、**`FTK Imager`**、**`Magnet RAM Capture`**）立即抓取系统内存镜像 +2. **分析内存镜像：** 将抓取的内存镜像导入专业的取证工具（如 **`Volatility`**、**`Rekall`**） +3. **查找关键信息：** + - **`pstree` 或 `pslist`：** 查看当前和已终止的进程列表，寻找可疑的进程 + - **`cmdline`：** 查看进程的命令行参数，看看是否有 `rm` 或其他可疑的删除命令 + - **`filescan` 或 `sockets`：** 检查打开的文件句柄和网络连接，寻找与攻击者相关的线索 + - **`dumpfiles`：** 尝试从内存中恢复已删除的文件数据 + +**2. 磁盘取证 (Disk Forensics)** + +即使文件被删除，数据通常不会立即被擦除，只是其在文件系统中的索引（inode）被标记为可用 + +**措施：** + +- **数据残留：** 只要数据块没有被新数据覆盖，就有恢复的可能性 +- **文件系统元数据：** 文件系统的元数据（如日志删除的时间戳、执行删除的用户等）可能仍然存在 + +**操作方法：** + +1. **创建磁盘镜像：** 使用 `dd` 或其他取证工具（如 `EnCase`、`FTK`）对受影响的磁盘进行物理或逻辑镜像，确保不对原始数据进行任何修改 +2. **使用文件恢复工具：** + - **`foremost` 或 `scalpel`：** 这类工具基于文件头和文件尾的特征来搜索和恢复数据，可以尝试恢复 `.log`、`.gz` 或其他可能被删除的文件 + - **`extundelete` 或 `testdisk`：** 这类工具专门针对文件系统的特性，可以恢复被删除的文件 +3. **分析文件系统日志（如果可用）：** + - 某些文件系统（如 ext4）有自己的日志，可能会记录文件的创建、删除等操作。 + +**3. 统和服务日志检查** + +虽然主日志被删了，但还有一些其他地方可以寻找线索 + +**措施：** + +- **独立日志：** 某些应用程序或服务有独立的日志目录，可能不在 `/var/log` 下 +- **审计日志：** 如果系统开启了审计功能（如 **`auditd`**），它会独立记录系统调用，包括文件的删除操作。这通常是排查此类问题的“黄金”线索 + +**操作方法：** + +- **检查独立应用日志：** 查看 web 服务（如 **Nginx** 或 **Apache** 的 `access.log`）、数据库、容器服务（如 **Docker**）的日志目录。这些日志可能记录了攻击者入侵的原始入口 +- **检查 `auditd` 日志：** 检查 `/var/log/audit/audit.log` 或其指定位置。搜索关键词如 `delete`、`unlink`、`rm`，或者可疑的用户 ID +- **`bash` 历史记录：** 检查 `/root/.bash_history` 或其他用户的 `~/.bash_history`。攻击者如果未清除此文件，可能会留下痕迹。不过，有经验的攻击者通常会清除或禁用此功能 + +**4. 网络流量分析** + +攻击者在入侵和删除日志后，可能还会进行数据回传或保持远程连接 + +**措施：** + +- **攻击者通信：** 可能会有与外部 C&C（命令与控制）服务器的通信 +- **数据外泄：** 攻击者可能在删除日志前已经窃取了数据 + +**操作方法：** + +- **分析网络设备日志：** 检查防火墙、路由器或入侵检测系统（IDS/IPS）的日志 +- **分析网络流量捕获文件：** 如果在事发时有网络流量捕获（如 `pcap` 文件），可以使用 **`Wireshark`** 或 **`Zeek`** 等工具进行深度分析 \ No newline at end of file diff --git a/Chapter7/7-23.md b/Chapter7/7-23.md new file mode 100644 index 0000000..88b58f2 --- /dev/null +++ b/Chapter7/7-23.md @@ -0,0 +1,23 @@ +### 常见加固手段 + +**1. 系统和应用程序加固** + +- **及时更新和打补丁**：定期检查并安装操作系统、应用程序和依赖库的最新补丁，以修复已知的安全漏洞 +- **禁用不必要的服务和端口**：关闭那些不用于业务的端口和服务。例如，如果你的服务器不需要 FTP 服务，就把它禁用掉 +- **最小化权限原则**：所有用户和程序都应该只拥有完成其任务所必需的最小权限。不要使用 root 或管理员账户来运行日常服务 +- **修改默认配置**：更改系统、应用和设备的默认密码、默认端口和默认配置，这些默认值常常是攻击者首先尝试的目标 +- **日志审计**：开启并配置详细的日志记录，以便在安全事件发生后进行溯源和分析。同时，需要定期审查这些日志 + +**2. 网络和边界加固** + +- **防火墙配置**：在网络边界和服务器上部署防火墙，并配置严格的访问控制列表（ACL），只允许必要的流量通过 +- **入侵检测/防御系统 (IDS/IPS)**：部署 IDS/IPS 来监控网络流量，识别并阻止恶意行为，如端口扫描、缓冲区溢出攻击等 +- **网络分段**：将网络划分为不同的区域（如生产区、开发区、办公区），并通过防火墙或 VLAN 隔离，避免攻击者从一个区域轻易地横向移动到另一个区域 +- **禁用非加密协议**：优先使用加密协议，如 HTTPS、SSH、SFTP 等，而不是 HTTP、Telnet、FTP 等明文协议 + +**3. 数据和身份管理加固** + +- **强密码策略**：强制用户使用复杂且不重复的密码，并定期更换。可以配合多因素认证（MFA）来进一步提高账户安全性 +- **数据加密**：对敏感数据进行加密，无论是在传输过程中（例如使用 TLS/SSL）还是在存储时（例如对数据库或磁盘进行加密） +- **备份和恢复策略**：制定并定期执行数据备份，并测试恢复流程，以确保在发生数据损坏或勒索软件攻击时能够快速恢复 +- **身份认证和授权**：使用集中式的身份管理系统（如 LDAP 或活动目录），并对不同角色的用户进行精细化的权限管理 \ No newline at end of file diff --git a/Chapter7/7-24.md b/Chapter7/7-24.md new file mode 100644 index 0000000..f9b9566 --- /dev/null +++ b/Chapter7/7-24.md @@ -0,0 +1,21 @@ +### 挖矿病毒特征 + +**1. 异常高的 CPU 和 GPU 使用率** + +这是最明显的特征。当你的电脑被植入挖矿病毒后，即使你没有运行任何大型程序（比如游戏或视频编辑软件），任务管理器或活动监视器中显示的**CPU 和 GPU使用率也会异常地高**，通常会持续在 90% 甚至 100% 左右。这会直接导致你的电脑性能显著下降，变得卡顿、响应迟钝 + +**2. 计算机过热和风扇噪音增大** + +由于 CPU 和 GPU 长时间处于高负载状态，会产生大量的热量。你会发现你的电脑，尤其是笔记本电脑，**机身变得非常烫**。为了散热，电脑的风扇会一直高速运转，产生持续且刺耳的噪音 + +**3. 电池续航时间急剧缩短** + +对于笔记本电脑用户来说，挖矿病毒会持续消耗电量，导致**电池续航时间比平时短得多**。你可能会发现，原本能用几个小时的电量，现在只用一两个小时就耗尽了 + +**4. 难以识别的进程** + +在任务管理器中，你可能会发现一个或几个**陌生的、占用大量 CPU 资源的进程**。这些进程的名字往往是随机的字母和数字组合，或者伪装成正常的系统进程，例如 `svchost.exe` 或 `explorer.exe`，但它们的实际位置和正常进程不同 + +**5. 网络流量异常** + +虽然挖矿病毒主要消耗的是计算资源，但在挖掘和提交计算结果时，也会产生一定的网络流量。你可以使用网络监控工具来检查是否有**异常的、持续的对外连接**，尤其是一些指向未知 IP 地址的连接 \ No newline at end of file diff --git a/Chapter7/7-25.md b/Chapter7/7-25.md new file mode 100644 index 0000000..3237de6 --- /dev/null +++ b/Chapter7/7-25.md @@ -0,0 +1,46 @@ +### 挖矿病毒应急思路 + +**1. 遏制** + +当发现病毒时，首要任务是阻止其进一步扩散，并保留现场证据 + +- **确认事件**：通过告警、资源占用异常（CPU、GPU 飙升）、网络流量异常、可疑进程等现象，确认是挖矿病毒事件 +- **隔离受感染主机**： + - **物理隔离**：最直接的方式，拔掉网线或断开 Wi-Fi 连接 + - **网络隔离**：在交换机或防火墙上，将受感染主机的 IP 或 MAC 地址加入黑名单，或将其移动到隔离的 VLAN 中 +- **保留现场**：不要急于重启或关机，这会丢失宝贵的内存数据 + +**2. 取证与分析** + +这是溯源和清除的关键环节 + +- **内存取证**： + - 使用 Volatility 等工具对受感染主机的内存进行镜像 + - 分析内存镜像，寻找恶意进程、网络连接、注入的 DLL、rootkit 痕迹等 +- **系统取证**： + - **进程分析**：使用 Process Explorer 或 Process Monitor，查找 CPU 或 GPU 占用率异常的进程。注意那些名字可疑或隐藏在系统目录下的进程 + - **网络分析**：使用 Wireshark 或 TCPView，检查是否有异常的网络连接，特别是连接到矿池的 IP 地址或域名 + - **文件分析**：查找可疑的文件，如挖矿程序、配置文件、定时任务脚本等。注意文件的时间戳，并寻找隐藏或伪装的文件 + - **启动项与定时任务**：检查系统的自启动项（注册表、启动文件夹）和定时任务（`schtasks`），找出病毒的持久化机制 + - **日志分析**： + - **系统日志**：检查是否有异常的登录记录、服务启动失败等 + - **安全日志**：查看是否有暴力破解、提权等事件 +- **恶意文件分析**： + - **静态分析**：使用反汇编工具或在线沙箱（如 VirusTotal），查看恶意文件的哈希值、字符串、行为特征等 + - **动态分析**：在隔离环境中运行恶意文件，观察其行为，包括创建或修改哪些文件、连接哪些 IP 地址、如何进行提权等 + +**3. 彻底清除与修复** + +基于分析结果，制定详细的清除计划 + +- **清除恶意程序**： + - 根据分析结果，终止恶意进程 + - 删除所有相关的恶意文件、启动项和定时任务 + - 清除注册表中与病毒相关的键值 +- **修复漏洞**： + - 如果病毒是通过系统漏洞（如永恒之蓝）传播的，立即打上相应的补丁 + - 关闭不必要的端口和服务 + - 修改弱口令，强制所有用户使用强密码 +- **全网扫描**： + - 使用企业级的杀毒软件对全网进行扫描，确保没有其他被感染的主机 + - 对所有主机进行安全基线检查，加固配置 \ No newline at end of file diff --git a/Chapter7/7-26.md b/Chapter7/7-26.md new file mode 100644 index 0000000..1b8b3cf --- /dev/null +++ b/Chapter7/7-26.md @@ -0,0 +1,16 @@ +### 如何判断钓鱼邮件 + +**1. 检查发件人信息** + +这是判断钓鱼邮件最直接、最有效的方法 + +- **发件人地址异常**：即使邮件显示的发件人名字是你熟悉的，也要仔细查看完整的邮件地址。例如，一封声称来自“Apple”的邮件，其发件人地址可能不是 `@apple.com`，而是类似 `@app1e.com`（数字 1 替代字母 l）或者 `@apple-support.com` 的地址 +- **企业邮箱与公共邮箱混淆**：正规公司通常会使用自己的企业邮箱后缀（如 `xxx@company.com`），而不会使用 `Gmail`、`Hotmail` 或 `163.com` 等公共邮箱发送重要通知 +- **发件人与内容不符**：如果邮件主题是关于银行账户的，但发件人却是一个电商网站的地址，那这封邮件极有可能是钓鱼邮件 + +**2. 警惕可疑的链接和附件** + +钓鱼邮件的主要目的就是诱导你点击链接或下载附件 + +- **悬停检查链接**：**不要直接点击任何可疑链接**。将鼠标悬停在链接上（不要点击），浏览器或邮件客户端的左下角通常会显示出真实的跳转地址。如果显示的地址与文字描述不符，或者是一个看起来杂乱无章、包含大量数字和特殊字符的网址，那么这个链接很可能有问题 +- **附件类型可疑**：当心那些扩展名为 `.exe`、`.scr`、`.zip`、`.rar`、`.js`、`.vbs` 或 `.bat` 的附件。即使是 Word、Excel 文档，也要警惕那些要求你“启用宏”才能查看的提示，这很可能是恶意代码 \ No newline at end of file diff --git a/Chapter7/7-27.md b/Chapter7/7-27.md new file mode 100644 index 0000000..8304c4f --- /dev/null +++ b/Chapter7/7-27.md @@ -0,0 +1,32 @@ +### 暴露面梳理怎么做 + +**1. 梳理资产** + +这是暴露面梳理的第一步，也是基础。你必须知道你有什么，才能知道要保护什么 + +- **网络资产**：识别所有 IP 地址、域名、子域名、开放端口、服务和应用 +- **物理资产**：包括服务器、电脑、手机、IoT 设备等 +- **第三方资产**：云服务（AWS、Azure、阿里云）、SaaS 应用（Salesforce、Workday）、外包服务商等。这些都是你无法完全控制，但可能成为攻击入口的点 +- **人员资产**：员工、供应商、合作伙伴。人是最大的漏洞，钓鱼邮件、社会工程学都以人为目标 + +**2. 识别攻击入口** + +梳理完资产后，你需要从攻击者的角度思考，他们会从哪里下手 + +- **外部暴露面**：这是最常见的攻击入口 + - **Web 应用**：包括网站、Web API、后台管理系统等。可能存在 SQL 注入、跨站脚本（XSS）、文件上传漏洞等 + - **开放端口和服务**：如 SSH、RDP、FTP、数据库服务等。配置不当、弱口令、未打补丁的服务都可能被利用 + - **域名和子域名**：子域名接管、域名劫持等都是常见的攻击手法 + - **邮件系统**：钓鱼邮件是获取内部权限的有效方式 +- **内部暴露面**：一旦攻击者进入内部网络，他们会寻找更多的弱点 + - **内部 Web 应用**：许多内部应用的安全防护比不上外部应用 + - **内网资产**：未打补丁的操作系统、配置错误的设备、共享文件夹权限过大等 + - **人员行为**：员工在社交媒体上泄露公司信息、使用弱密码等 + +**3. 持续监控与更新** + +暴露面梳理不是一次性的任务，而是一个持续的过程 + +- **自动化监控**：使用自动化工具定期扫描和监控你的资产 +- **资产变更管理**：建立资产变更登记制度，确保新上线的服务、应用都能被及时纳入梳理范围 +- **威胁情报**：订阅威胁情报，了解最新的漏洞和攻击手法，及时更新你的防御策略 \ No newline at end of file diff --git a/Chapter7/7-28.md b/Chapter7/7-28.md new file mode 100644 index 0000000..35b4e8a --- /dev/null +++ b/Chapter7/7-28.md @@ -0,0 +1,5 @@ +### netstat 和 ss 命令的区别 + +`netstat` 是一个比较传统的工具，长期以来都是网络诊断的首选。然而，随着网络流量和连接数的不断增长，`netstat` 在处理大量数据时会变得非常慢，因为它需要遍历 `/proc/net` 目录下的所有文件来收集信息 + +`ss` (socket statistics) 是 `netstat` 的现代替代品，它利用了 Linux 内核中 **Netlink** 协议的优势。Netlink 是一种用于内核与用户空间进程之间通信的套接字机制。因此，`ss` 可以直接从内核获取套接字统计信息，而无需解析 `/proc` 文件，这使得它在性能上远远优于 `netstat`，尤其是在系统有大量连接时 \ No newline at end of file diff --git a/Chapter7/7-29.md b/Chapter7/7-29.md new file mode 100644 index 0000000..934b1e4 --- /dev/null +++ b/Chapter7/7-29.md @@ -0,0 +1,17 @@ +### Windows 日志存储位置 + +主要的日志类别及其文件如下： + +- **应用程序日志 (Application)**： + - **文件路径**：`%SystemRoot%\System32\Winevt\Logs\Application.evtx` + - **内容**：记录由应用程序产生的事件，例如程序启动、停止、崩溃或错误信息 +- **安全日志 (Security)**： + - **文件路径**：`%SystemRoot%\System32\Winevt\Logs\Security.evtx` + - **内容**：记录与安全相关的事件，例如用户登录/注销、权限更改、文件访问等。这对于应急响应和取证分析非常重要 + - **注意**：安全日志默认是关闭许多详细审计功能的，需要通过组策略（Group Policy）来启用更详细的审计策略 +- **系统日志 (System)**： + - **文件路径**：`%SystemRoot%\System32\Winevt\Logs\System.evtx` + - **内容**：记录由 Windows 操作系统组件产生的事件，例如驱动程序加载失败、硬件错误、服务启动/停止等 +- **Setup 日志 (Setup)**： + - **文件路径**：`%SystemRoot%\System32\Winevt\Logs\Setup.evtx` + - **内容**：记录 Windows 安装、升级或服务包安装过程中的事件 \ No newline at end of file diff --git a/Chapter7/7-3.md b/Chapter7/7-3.md new file mode 100644 index 0000000..239ef47 --- /dev/null +++ b/Chapter7/7-3.md @@ -0,0 +1,29 @@ +### 常见 Windows 事件 ID + +**1. 安全事件日志（Security Log）中常见的事件 ID** + +安全日志是我们进行应急响应和入侵分析时，最需要关注的。以下是一些常见的安全事件 ID 及其含义： + +- **ID 4624**：**成功登录**。这表示用户成功登录到系统。在排查入侵时，我们会特别关注登录的来源（网络登录、远程桌面等）和登录的用户 +- **ID 4625**：**登录失败**。这是入侵者进行暴力破解或密码猜解的常见痕迹。当看到大量连续的 4625 事件时，通常意味着有恶意登录尝试 +- **ID 4648**：**使用显式凭据登录**。这通常表示某个服务或进程使用与当前登录用户不同的凭据来运行，在排查横向移动和特权滥用时很有用 +- **ID 4672**：**分配了管理员特权**。当一个用户通过提权（如 Runas）获得管理员权限时，会产生此事件 +- **ID 4720**：**创建用户账户**。攻击者为了持久化控制，通常会创建新的用户。这个事件 ID 是检测账户异常创建的关键 +- **ID 4724**：**重置密码**。管理员或拥有相应权限的用户重置了另一个用户的密码 +- **ID 4732 / 4733**：**用户被添加到安全组 / 从安全组中移除**。攻击者可能会将自己的账户添加到管理员组（如 Administrators），以获取更高权限 +- **ID 4768 / 4769**：**Kerberos 票证请求**。这些事件与 Kerberos 身份验证有关，在排查域环境下的哈希传递、黄金票据等攻击时非常重要 + +**2. 系统事件日志（System Log）中常见的事件 ID** + +系统日志可以帮助我们了解系统运行状态和是否存在异常 + +- **ID 1074**：**系统关机或重启**。如果系统意外重启，这个事件会提供关机的原因 +- **ID 6005**：**系统启动**。表示事件日志服务已启动，通常在系统开机后记录 +- **ID 6006**：**系统关机**。表示事件日志服务已停止，通常在系统关机前记录 + +**3. 应用事件日志（Application Log）中常见的事件 ID** + +应用日志帮助我们了解特定程序运行中出现的问题。 + +- **ID 1000**：**应用程序崩溃或错误**。这是一个非常通用的事件 ID，表示某个应用程序遇到了错误并停止运行 +- **ID 1001**：**Windows 错误报告**。记录了应用程序崩溃的详细信息，这对于定位恶意软件或服务异常终止非常有用 \ No newline at end of file diff --git a/Chapter7/7-30.md b/Chapter7/7-30.md new file mode 100644 index 0000000..56b3cff --- /dev/null +++ b/Chapter7/7-30.md @@ -0,0 +1,50 @@ +### 云产品的应急思路 + +**1. 明确责任边界** + +你需要清楚地知道哪些安全责任由云服务提供商（如 AWS、Azure、GCP）承担，哪些由你承担 + +- **云厂商（如阿里云、腾讯云）**：负责底层基础设施（物理服务器、网络、数据中心）的安全 +- **客户（你）**：负责云上租户内的安全，包括云服务器（ECS/CVM）、云数据库、应用系统、数据安全以及**身份与访问管理（IAM）** + +在接到告警或发现异常时，第一步是判断问题是否属于你的责任范畴。例如，如果你的 ECS 实例被挖矿病毒入侵，这是你的责任；但如果云厂商的控制台出现大面积无法访问，那通常是云厂商的责任 + +**2. 身份与访问管理（IAM）优先** + +在云环境中，**API 密钥泄露**是导致大规模入侵事件的常见原因。一个高权限的 AccessKey 被盗，攻击者可以利用它来创建新的云主机、删除数据、修改安全组规则，甚至进行横向移动 + +- **应急响应操作（以阿里云为例）**： + - **立即禁用**或**删除**可疑的 RAM 用户或 AccessKey + - **排查操作日志**：在**云审计（CloudTrail）**中，通过日志分析攻击者执行了哪些操作，例如 `RunInstances`、`DeleteObject` 等 + - **强制 MFA**：对所有高权限用户强制开启多因素认证 + +**3. 利用云原生安全和监控产品** + +云厂商提供了强大的日志和监控服务，它们是应急响应的“黑匣子”，能提供详细的事件时间线和攻击路径 + +- **阿里云**： + - **云审计（ActionTrail）**：记录所有 API 调用，是分析攻击者行为的核心日志 + - **日志服务 SLS**：收集各类日志，如 ECS 的操作系统日志、VPC 流日志等，为分析提供基础 + - **态势感知**：对云上资产进行安全评估和威胁检测，可以发现恶意文件、异常登录等 +- **腾讯云**： + - **云审计（CloudAudit）**：记录账户下的所有 API 操作 + - **日志服务 CLS**：提供日志收集和分析能力 + - **云防火墙/安全组**：监控并阻断恶意流量 +- **华为云**： + - **云审计服务（CTS）**：记录云服务的操作事件 + - **网络流量分析（NTA）**：分析网络流量，发现异常行为 + +**4. 隔离与遏制** + +快速遏制是防止损害扩大的关键。在云上，隔离的操作更加灵活和高效 + +- **修改安全组/网络 ACL**：通过修改安全组或网络 ACL 规则，可以快速阻断恶意 IP 地址或端口的流量 +- **断开云主机网络**：直接将受感染的云主机从 VPC 网络中隔离。在阿里云中，可以通过修改 ECS 的安全组使其无法访问任何网络 +- **创建快照**：在执行任何破坏性操作前，为受感染的云主机创建快照。这个快照是进行**取证分析**的重要依据，可以让你在后续分析中还原当时的环境状态 + +**5. 自动化与编排** + +手动应急响应在面对大规模入侵时会非常缓慢。利用云厂商提供的自动化工具，可以大大提升效率 + +- **Serverless 函数（阿里云 FC、腾讯云 SCF）**：编写函数，在收到告警（如威胁情报告警）时，自动执行响应操作，例如修改安全组、禁用 AccessKey +- **基础设施即代码（IaC）**：使用 **Terraform** 或 **ROS（阿里云）** 等工具，可以快速部署一个干净、已加固的新环境，然后将应用切换过去，这比修复一个受感染的云主机要快得多 \ No newline at end of file diff --git a/Chapter7/7-31.md b/Chapter7/7-31.md new file mode 100644 index 0000000..9fe348c --- /dev/null +++ b/Chapter7/7-31.md @@ -0,0 +1,23 @@ +### DNS 重绑定漏洞原理 + +**1. 攻击原理：两次 DNS 解析的“重绑定”** + +DNS 重绑定攻击的核心在于**“两次”**和**“重绑定”**这两个关键步骤 + +**第一步：第一次 DNS 解析（公网地址）** + +1. **攻击者准备：** 攻击者控制一个恶意域名，例如 `rebind.attacker.com`，并在其 DNS 服务器上配置该域名 +2. **用户访问：** 用户在浏览器中访问一个恶意网站，该网站包含一个加载 `rebind.attacker.com` 资源的脚本 +3. **DNS 解析：** 浏览器向 DNS 服务器请求解析 `rebind.attacker.com` +4. **恶意响应：** 攻击者的 DNS 服务器返回一个正常的**公网 IP 地址**（例如 `1.1.1.1`）和一个非常短的 **TTL（Time-to-Live）**值，比如 10 秒 + - **TTL** 是 DNS 记录的有效期，它告诉浏览器在 TTL 时间内可以缓存这个解析结果。很短的 TTL 值是攻击成功的关键 +5. **建立信任：** 浏览器接收到公网 IP 后，与 `rebind.attacker.com `建立连接，加载恶意脚本。此时，浏览器认为该脚本是安全的，因为它来自一个公网域名 + +**第二步：第二次DNS解析（内网地址）** + +1. **TTL 过期：** 恶意脚本被加载后，会等待一个比 TTL 值稍长的时间（例如 12 秒） +2. **发起请求：** 脚本向同一个域名 `rebind.attacker.com` 发起一个新的请求（例如，一个 AJAX 请求） +3. **重新解析：** 由于第一次的 DNS 记录已经过期（TTL 超时），浏览器会再次向 DNS 服务器请求解析`rebind.attacker.com` +4. **重绑定：** 这一次，攻击者的 DNS 服务器不再返回公网 IP，而是返回一个**内网 IP 地址**（例如 `192.168.1.1`） +5. **绕过策略：** 浏览器接收到这个内网 IP 后，由于它认为这个新的请求仍然来自“同源”的 `rebind.attacker.com`，而其解析结果却是内网 IP，浏览器会认为该请求是合法的，并将其发送到内网地址`192.168.1.1` +6. **攻击成功：** 此时，恶意脚本已经成功绕过同源策略，可以直接访问和控制内网中的设备，如路由器、摄像头或打印机 \ No newline at end of file diff --git a/Chapter7/7-32.md b/Chapter7/7-32.md new file mode 100644 index 0000000..5a3184a --- /dev/null +++ b/Chapter7/7-32.md @@ -0,0 +1,9 @@ +### Token 和 Referer 的安全等级谁高 + +Token 的安全等级远高于 Referer + +以一个简单的比喻来说： + +- **Token** 就像一张带有防伪标记和有效期的**银行卡**，只有验证了卡片和密码（以及有效期），才能进行交易 +- **Referer** 就像你告诉收银员你是从哪个商场进来的，这个信息谁都可以随口编造，收银员不会拿这个来验证你的身份。 + diff --git a/Chapter7/7-33.md b/Chapter7/7-33.md new file mode 100644 index 0000000..aa683c6 --- /dev/null +++ b/Chapter7/7-33.md @@ -0,0 +1,31 @@ +### 任意文件下载漏洞防御方法 + +**1. 严格校验用户输入** + +这是最根本也是最重要的防御措施。在处理文件下载请求时，绝对不能相信用户提供的任何文件路径信息 + +- **白名单机制：** 建议使用**白名单**来限制用户可下载的文件。即只允许下载特定目录下的特定文件。例如，你可以定义一个允许下载的文件列表，当用户请求文件时，先检查请求的文件名是否在白名单中 +- **黑名单机制（不推荐）：** 尽管可以通过黑名单来过滤一些危险的文件名（如`../`、`../../`、`/etc/passwd`、`C:/Windows/win.ini`），但这种方法很容易被绕过。攻击者可以使用编码（如 URL 编码）或者其他技巧来绕过黑名单，因此不推荐单独使用黑名单 +- **路径规范化：** 在处理用户输入的文件路径前，必须对路径进行规范化。你可以使用编程语言提供的函数来获取文件的规范路径，然后检查这个路径是否在你的下载目录下。例如，在 Python 中可以使用`os.path.abspath()`来获取绝对路径 +- **禁止使用路径穿越符：** 检查用户输入中是否包含 `../` 或 `..\` 等路径穿越符。如果发现，应立即拒绝请求或进行特殊处理 +- **限定下载目录：** 所有可供下载的文件都应存放在一个**专门的、与 Web 根目录隔离**的下载目录中。下载请求应该只允许访问这个目录下的文件 + +**2. 权限控制** + +- **最小权限原则：** Web 服务器（如Nginx、Apache）或运行 Web 应用的账户，应该以**最小权限**运行。不要使用`root` 或 `Administrator` 等高权限账户。这样即使出现漏洞，攻击者也无法下载到系统关键文件 +- **文件权限设置：** 确保 Web 目录下的文件权限设置正确。例如，配置文件、日志文件、数据库文件等敏感文件应设置为只有特定用户才能读取，并且禁止 Web 应用账户读取 + +**3. 编程实现中的安全实践** + +- **使用绝对路径：** 在代码中，永远使用**绝对路径**来构建文件下载的路径。不要使用用户提供的相对路径 +- **文件名或 ID 映射：** 更好的一种方法是，不要直接暴露文件名给用户。你可以为每个可下载文件生成一个**唯一的ID**，并将其存储在数据库中。用户请求时，只提供这个 ID，后端程序根据 ID 从数据库中查找对应的文件路径并进行下载。这样可以彻底避免用户直接操纵文件名 + +例如： + +- **不安全的方式：** `download.php?file=../../etc/passwd` +- **安全的方式：** `download.php?id=123` （ID 123 对应的是一个安全的、预设的文件路径） + +**4. Web 应用防火墙（WAF）** + +- **部署 WAF：** 在 Web 服务器前部署 Web 应用防火墙（WAF）。WAF 可以帮助你检测和拦截包含路径穿越（Path Traversal）攻击特征的请求，如 `../`、`/etc/passwd` 等，从而在请求到达应用服务器前就将其拦截 + diff --git a/Chapter7/7-34.md b/Chapter7/7-34.md new file mode 100644 index 0000000..1d91eab --- /dev/null +++ b/Chapter7/7-34.md @@ -0,0 +1,40 @@ +### 怎么修改 TTL 值 + +**1. 修改操作系统中的默认 TTL 值** + +在应急响应中，我们有时需要修改操作系统默认的 TTL 值来测试网络路径或规避某些防火墙策略 + +**在 Windows 上** + +1. 打开注册表编辑器：在“运行”中输入 `regedit` 并回车 +2. 导航到以下路径： `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters` +3. 在右侧窗格中，右键点击空白处，选择“新建” -> “DWORD (32 位) 值”，将其命名为 `DefaultTTL` +4. 双击 `DefaultTTL`，选择“十进制”，输入你想要设置的 TTL 值（例如，64、128 或 255） +5. 重启电脑使设置生效 + +**在 Linux 上** + +1. 打开终端，编辑 `sysctl.conf` 文件： `sudo nano /etc/sysctl.conf` +2. 在文件末尾添加或修改以下行： `net.ipv4.ip_default_ttl = 64` 你可以将 `64` 修改为你想要的值 +3. 保存并退出文件 +4. 运行以下命令使配置立即生效： `sudo sysctl -p` + +**2. 修改 DNS 记录的 TTL 值** + +在应急响应场景中，我们经常需要快速更新 DNS 记录以指向新的服务器或 IP 地址，例如在进行 DNS 切换或故障转移时。这时，DNS 记录的 TTL 值就非常重要 + +**TTL 值越低，DNS 记录的更新就越快，但会增加 DNS 服务器的查询负载** + +**TTL 值越高，DNS 记录的更新就越慢，但可以减少 DNS 服务器的负载** + +**如何修改：** + +你需要在你的域名注册商或 DNS 服务提供商的管理界面中进行修改 + +1. 登录你的 DNS 服务商（如 GoDaddy, Cloudflare, 阿里云 DNS 等） +2. 找到你想要修改的域名，进入 DNS 记录管理页面 +3. 找到对应的 A 记录、CNAME 记录或 MX 记录 +4. 你会看到一个 **TTL** 字段，通常以秒为单位。将其修改为你需要的值 + - **应急场景**：当需要快速切换时，建议将 TTL 值降低到 **60 秒**甚至 **300 秒（5 分钟）** + - **正常运行**：一般情况下，可以设置为 **3600 秒（1 小时）**或 **86400 秒（1 天）** +5. 保存修改 diff --git a/Chapter7/7-35.md b/Chapter7/7-35.md new file mode 100644 index 0000000..7fc8960 --- /dev/null +++ b/Chapter7/7-35.md @@ -0,0 +1,114 @@ +### Linux 怎么查看程序调用了哪些文件 + +**1. 使用 `lsof` 命令** + +`lsof` (list open files) 是最强大和最常用的工具，它可以列出当前系统所有打开的文件，包括普通文件、目录、网络套接字等 + +**基本用法：** + +要查看特定程序（通过 **PID** 或 **进程名**）打开了哪些文件，你可以使用以下命令： + +- **按进程名查看：** + + ```bash + lsof -c + ``` + + 例如，要查看 `nginx` 进程打开了哪些文件，可以运行： + + ```bash + lsof -c nginx + ``` + +- **按进程 ID (PID) 查看：** + + ```bash + lsof -p + ``` + + 首先，你需要找到程序的 PID。比如，使用 `ps aux | grep nginx` 或 `pgrep nginx`。然后，用找到的 PID 来查看： + + ```bash + lsof -p 12345 + ``` + +**常见输出字段：** + +`lsof` 的输出通常包含以下列： + +- **COMMAND**：命令名 +- **PID**：进程 ID +- **USER**：用户 +- **FD**：文件描述符 (File Descriptor) + - `cwd`：当前工作目录 + - `txt`：程序的可执行文件 + - `mem`：内存映射文件 + - `数字`：普通文件，后面通常跟着 `r` (读)、`w` (写) 或 `u` (读写) +- **TYPE**：文件类型（如 `REG` 表示普通文件，`DIR` 表示目录） +- **NAME**：文件名 + +**2. 使用 `strace` 命令** + +`strace` 工具用于跟踪系统调用和信号。它可以记录程序在运行过程中对文件进行的各种操作，如 `open()`、`read()`、`write()` 等。 + +**基本用法：** + +- **启动时跟踪新程序：** + + ```bash + strace + ``` + + 这个命令会启动程序，并实时打印出它所有的系统调用。要只看文件相关的调用，可以使用 `-e` 选项： + + ```bash + strace -e trace=file + ``` + + 或者，更精确地跟踪 `open` 调用： + + ```bash + strace -e open + ``` + +- **跟踪正在运行的程序：** + + ```bash + strace -p + ``` + + 这会附加到指定的 PID 上，并开始跟踪其系统调用 + +`strace` 的输出非常详细，可以帮助你了解程序是如何与文件系统交互的，例如它尝试打开哪个文件、是否成功、返回的文件描述符是什么等等 + +**3. 查看 `/proc` 文件系统** + +`/proc` 是一个虚拟文件系统，提供了对内核数据结构的访问。每个正在运行的进程都有一个对应的目录 `/proc/` + +- **`/proc//fd/` 目录：** 这个目录包含了进程打开的所有文件描述符的符号链接。你可以通过列出这个目录的内容来查看： + + ```bash + ls -l /proc//fd/ + ``` + + 这个命令会列出所有文件描述符及其指向的真实文件路径 + +- **`/proc//exe` 文件：** 这是一个指向程序可执行文件的符号链接 + + ```bash + readlink /proc//exe + ``` + +- **`/proc//cwd` 文件：** 这是一个指向程序当前工作目录的符号链接 + + ```bash + readlink /proc//cwd + ``` + +**总结** + +- **`lsof`**：最直接、最常用的工具，**可以快速查看**一个程序当前打开了哪些文件。当你想知道“这个程序现在正在使用什么文件？”时，首选 `lsof` +- **`strace`**：用于 **跟踪程序动态行为**。当你想知道“这个程序在运行过程中**尝试**打开或访问了哪些文件？”或者想调试为什么某个文件无法打开时，`strace` 是最佳选择 +- **`/proc` 文件系统**：这是一个 **低级** 的方法，提供了对进程状态的直接访问。当你无法使用 `lsof` 或 `strace` 时，或者需要编写脚本来获取信息时，`/proc` 是一个可靠的备选方案 + +通常情况下，**`lsof -c `** 是解决大多数问题的起点，因为它简单、直接且输出清晰 \ No newline at end of file diff --git a/Chapter7/7-36.md b/Chapter7/7-36.md new file mode 100644 index 0000000..69d73fb --- /dev/null +++ b/Chapter7/7-36.md @@ -0,0 +1,13 @@ +### CMD 命令行如何查询远程终端开放端口 + +**1. 使用 `netstat -ano` 找到可疑的端口和对应的 PID** + +运行 `netstat -ano` 后，你会看到一个详细的列表，包含： + +- **协议 (Proto)**: TCP 或 UDP +- **本地地址 (Local Address)**: 本地IP地址和端口号 +- **外部地址 (Foreign Address)**: 远程IP地址和端口号 +- **状态 (State)**: 连接状态，例如 `ESTABLISHED` (已建立连接)、`LISTENING` (正在监听) +- **PID**: 进程 ID + +你可以通过查找 `LISTENING` 状态的端口，或者 `ESTABLISHED` 状态的陌生外部地址，来定位可疑的网络活动 \ No newline at end of file diff --git a/Chapter7/7-37.md b/Chapter7/7-37.md new file mode 100644 index 0000000..ab7434b --- /dev/null +++ b/Chapter7/7-37.md @@ -0,0 +1,104 @@ +### 查看服务器是否存在可疑账号、新增账号 + +**Windows 服务器排查** + +在 Windows 系统中，我们可以通过命令行工具、注册表和日志来查找异常账号 + +**1. 使用命令行检查** + +- **查看本地所有用户账号** 使用 `net user` 命令可以列出系统上的所有本地用户。仔细检查是否有不认识或命名异常的账号，例如：`tempadmin`、`testuser`、`service_a` 等 + + ```bash + net user + ``` + +- **查看新增的管理员账号** 使用以下命令可以查看本地管理员组的成员。如果发现新的或不熟悉的账号，需要重点排查 + + ```bash + net localgroup administrators + ``` + +- **查看最近创建的账号** `lusrmgr.msc`（本地用户和组）是一个图形化界面，可以按创建日期排序。在命令行中，我们通常需要结合 **安全日志** 来进行排查 + +**2. 检查安全事件日志** + +这是最可靠的方法之一。Windows 会记录用户创建、修改和删除等操作到安全事件日志中 + +- **事件查看器（Event Viewer）** + + 1. 打开事件查看器 (`eventvwr.msc`) + 2. 导航到“Windows 日志” -> “安全” + 3. 使用“筛选当前日志”功能，输入以下**事件 ID** 进行筛选： + - **4720**: 创建用户账号 + - **4722**: 启用用户账号 + - **4724**: 重置用户密码 + - **4732**: 将用户添加到本地安全组（如管理员组） + - **4728**: 将用户添加到全局安全组 + + 通过筛选这些事件 ID，你可以快速定位到账号被创建、启用或权限提升的时间点，并查看操作者（通常是 SYSTEM 或其他管理员账号） + +**Linux 服务器排查** + +在 Linux 系统中，我们可以通过检查系统文件和命令历史来发现异常账号 + +**1. 检查关键系统文件** + +- **`/etc/passwd` 文件** 这个文件包含了系统上所有用户的信息，每行代表一个用户。通常，系统的服务账号会以 `/sbin/nologin` 或 `/bin/false` 结尾，而可登录的用户通常以 `/bin/bash` 或 `/bin/sh` 结尾。 你可以使用 `cat` 或 `less` 命令查看，重点关注 UID（用户 ID），UID 小于 1000 的通常是系统账号，而 UID 大于 1000 的是普通用户 + + ```bash + cat /etc/passwd + ``` + + 要找到 UID 大于 1000 的账号，可以使用： + + ```bash + awk -F: '$3 >= 1000 {print $1}' /etc/passwd + ``` + +- **`/etc/shadow` 文件** 这个文件包含了用户的密码哈希值和密码过期信息。虽然不能直接看到密码，但它能确认用户的存在 + + ```bash + cat /etc/shadow + ``` + +- **`/etc/group` 文件** 这个文件定义了用户组。你可以检查 `sudo`、`wheel` 或 `root` 等特权组，看是否有可疑用户被添加 + + ```bash + cat /etc/group + ``` + +**2. 查看登录历史和命令历史** + +- **查看用户登录历史** 使用 `last` 命令可以查看所有用户的登录历史。检查是否有不正常的登录时间、来源 IP 地址或登录用户。 + + ```bash + last + ``` + + 使用 `who` 命令可以查看当前登录的用户 + + ```bash + who + ``` + +- **查看命令历史** 检查 `/root/.bash_history` 或 `/home//.bash_history` 文件，看是否有添加用户的命令（如 `useradd`） + + ```bash + cat /root/.bash_history | grep "useradd" + ``` + + **注意**：攻击者可能会清除命令历史，所以这不能作为唯一的判断依据 + + + +**3. 检查审计日志（Auditd）** + +如果你的 Linux 服务器配置了 `auditd` 服务，那你可以通过审计日志来获取更详细的信息。`auditd` 会记录系统上几乎所有的操作 + +- **事件 ID** `auditd` 记录用户创建的事件 ID 是 **1000**。你可以通过 `ausearch` 命令来查询： + + ```bash + ausearch -ua root -i | grep 1000 + ``` + + 这个命令可以帮助你查找由 root 用户执行的账户创建操作 \ No newline at end of file diff --git a/Chapter7/7-38.md b/Chapter7/7-38.md new file mode 100644 index 0000000..01cd2bd --- /dev/null +++ b/Chapter7/7-38.md @@ -0,0 +1,110 @@ +### 查看服务器是否存在隐藏账号、克隆账号 + +**Windows 服务器排查** + +攻击者在 Windows 上克隆或隐藏账户通常利用注册表和用户 SID（安全标识符）的特性。 + +**1. 排查克隆账户** + +克隆账户是指攻击者创建一个新的用户，然后修改注册表，使其拥有与某个高权限账户（如管理员）完全相同的 SID 和权限，但名字可能正常或看似无害 + +- **使用 `wmic` 命令检查** 使用 `wmic useraccount` 命令可以列出所有用户及其 SID。你需要重点检查以下情况： + + 1. **SID 异常**：正常用户的 SID 最后一位通常是 1000 以上的递增数字 + 2. **用户与 SID 不匹配**：特别是那些用户名看起来正常，但 SID 和其他用户（如管理员）完全相同的账户 + + ```bash + wmic useraccount get name,sid + ``` + + 正常情况下，一个用户对应一个唯一的 SID。如果发现两个用户拥有相同的 SID，则很可能存在克隆账户 + +- **检查本地用户和组** 虽然在 `lusrmgr.msc` 中通常能看到克隆账户，但有时候攻击者会用一些技巧隐藏，所以结合 `wmic` 检查更保险。 + +**2. 排查隐藏账户** + +攻击者会通过修改注册表来隐藏账户，使其在 `net user` 或 `lusrmgr.msc` 中不显示 + +- **检查注册表** + + 1. 打开注册表编辑器：`regedit` + + 2. 导航到：`HKEY_LOCAL_MACHINE\SAM\SAM` + + 3. 你需要 SYSTEM 权限才能访问这个路径。可以通过 `psexec` 获取一个 SYSTEM 权限的 `cmd` 来进行查看： + + ```bash + psexec -s -i cmd + ``` + + 4. 在 SYSTEM 权限的 `cmd` 中再次打开 `regedit`，导航到该路径 + + 5. 你会在 `SAM\Domains\Account\Users\Names` 下看到所有账户名 + + 6. 在 `SAM\Domains\Account\Users` 下，每个子项代表一个账户，其名称是十六进制的 RVA（相对虚拟地址） + + 7. **对比 `Users\Names` 和 `Users` 下的键值。** 如果 `Users` 下存在某个键值（账户）但在 `Users\Names` 下没有对应的名称，那么这个账户就是隐藏账户 + +- **日志审计** 结合 **安全日志**（事件 ID 4720）进行排查，即使账户被隐藏，其创建记录也可能被保留 + +**Linux 服务器排查** + +在 Linux 上，隐藏账户通常是利用系统文件的特性，而克隆账户则相对少见，但可以通过其他方式实现权限提升 + +**1. 排查隐藏账户** + +攻击者通常通过修改 `/etc/passwd` 和 `/etc/shadow` 文件，删除用户名，但保留账户的其他信息，或者创建没有名称的账户 + +- **检查 `/etc/passwd` 文件** + + 1. 查找没有用户名的账户： + + ```bash + grep -v '^[a-zA-Z]' /etc/passwd + ``` + + 这个命令会过滤掉所有以字母开头的行，如果输出结果有非空的行，可能存在隐藏账户 + + 2. 查找空用户名账户： + + ```bash + cat /etc/passwd | awk -F: '($1 == "") { print }' + ``` + + 这种方法可以查找用户名为空的账户 + + 3. 检查 UID 为 0 的账户： + + ```bash + awk -F: '($3 == 0) { print }' /etc/passwd + ``` + + UID 为 0 的账户拥有 root 权限。理论上只有一个 root 账户的 UID 为 0，如果出现多个，则很可能是克隆账户 + +**2. 检查克隆账户** + +Linux 上的克隆账户通常是指多个账户拥有相同的 UID，从而共享相同的权限 + +- **检查相同 UID 的账户** 使用 `awk` 命令查找 UID 重复的账户，这通常是克隆 root 权限账户的迹象 + + ```bash + awk -F: '{print $3}' /etc/passwd | sort | uniq -d + ``` + + 这个命令会找出 `/etc/passwd` 文件中所有重复的 UID。如果输出结果有 0，说明存在多个 UID 为 0 的账户。然后，你可以用 `grep` 查找这些 UID 对应的用户名 + + ```bash + grep ":0:" /etc/passwd + ``` + +**3. 检查 SSH 授权文件** + +攻击者也可能通过在 `.ssh/authorized_keys` 中添加公钥来持久化，从而无需密码即可登录 + +- **检查所有用户的 `.ssh` 目录** + + ```bash + find /home -name "authorized_keys" + ``` + + 找到文件后，检查其内容，看是否有不认识的公钥 \ No newline at end of file diff --git a/Chapter7/7-39.md b/Chapter7/7-39.md new file mode 100644 index 0000000..90e8457 --- /dev/null +++ b/Chapter7/7-39.md @@ -0,0 +1,21 @@ +### SQL 注入用转义字符防御时，如果遇到数据库的列名或是表名本身就带着特殊字符怎么办 + +在这种情况下，**不应该**对这些数据库对象名称使用转义字符，因为它们是数据库的合法标识符，而不是用户输入的数据。如果进行了转义，数据库将无法正确识别这些对象 + +**正确的做法：使用反引号或双引号进行引用** + +为了正确地处理包含特殊字符的列名或表名，标准的做法是使用**反引号（`）**或**双引号（"）**将这些标识符括起来。不同的数据库系统有不同的规定： + +- **MySQL**：使用**反引号（`）** + + ```sql + SELECT `user-name` FROM `user's_data` WHERE id = 1; + ``` + +- **PostgreSQL、Oracle、SQL Server**：使用**双引号（"）** + + ```sql + SELECT "user-name" FROM "user's_data" WHERE id = 1; + ``` + +**注意**：这种引用方法只用于处理**数据库对象名**，不应用于处理**用户输入数据** \ No newline at end of file diff --git a/Chapter7/7-4.md b/Chapter7/7-4.md new file mode 100644 index 0000000..d27f6ca --- /dev/null +++ b/Chapter7/7-4.md @@ -0,0 +1,24 @@ +### 为什么 aspx 木马的权限会比 asp 木马的权限更高 + +**ASP 木马的权限 (老式技术)** + +早期的 **ASP** 技术，在 IIS 中运行时，通常会使用一个叫做 `IUSR` 的匿名用户账户 + +- **账户权限低**：`IUSR` 账户的权限被严格限制，它只能访问一些特定的文件和目录，比如网站的根目录 +- **执行后果**：如果你上传一个 ASP 木马并成功执行，这个木马的所有操作都将以 `IUSR` 的权限进行。它可能能读取或写入网站目录里的文件，但无法访问系统核心文件，也无法创建新的系统管理员账户 +- **总结**：ASP 木马的危害被**账户权限**牢牢限制在了一个较低的水平 + +**ASP.NET (ASPX) 木马的权限 (新式技术)** + +**ASP.NET** 是微软推出的新一代 Web 技术，它采用了更现代的权限管理模型：**应用程序池 (Application Pool)**。 + +每个 ASP.NET 应用都运行在一个独立的应用程序池中，而每个应用程序池都使用一个特定的**账户身份**来运行 + +这个身份决定了它的权限！！！ + +问题就出在这里： + +- **默认配置（安全）**：在现代 IIS 中，应用程序池的默认身份是 `ApplicationPoolIdentity`。这是一个非常安全的低权限账户，它的权限和 ASP 的 `IUSR` 账户类似，甚至更低。在这种情况下，ASP.NET 木马的权限也很低，无法造成太大危害 +- **错误配置（危险）**：出于某些历史或方便的原因，一些管理员为了解决权限问题，会**手动将应用程序池的身份更改为高权限账户**，最常见的就是 `SYSTEM` 账户 + - **`SYSTEM` 账户**：这是 Windows 操作系统中**权限最高的本地账户**。它几乎可以执行任何操作，包括读写系统核心文件、创建新的管理员、停止或启动系统服务等 + - **执行后果**：如果攻击者上传的 ASP.NET 木马恰好运行在一个配置为 `SYSTEM` 账户的应用程序池中，那么这个木马就会**继承 `SYSTEM` 的所有权限**。此时，它将拥有对整个服务器的完全控制权，可以为所欲为 diff --git a/Chapter7/7-40.md b/Chapter7/7-40.md new file mode 100644 index 0000000..a027641 --- /dev/null +++ b/Chapter7/7-40.md @@ -0,0 +1,64 @@ +### 有哪些 SQL 语句无法使用预编译的方式 + +**1. 动态的数据库对象名称** + +预编译的参数只能用于替换 SQL 语句中的**值**（`VALUES`），而不能用于替换**表名**、**列名**、**排序字段**（`ORDER BY`）或**数据库名** + +例如，你不能这样做： + +```java +// 错误的预编译用法 +String sql = "SELECT * FROM ? WHERE id = 1"; +PreparedStatement pstmt = conn.prepareStatement(sql); +pstmt.setString(1, "users"); // 无法将表名作为参数传入 +``` + +**2. 动态的 SQL 关键词或子句** + +像 `SELECT`、`FROM`、`WHERE`、`GROUP BY`、`ORDER BY `等 SQL 关键词或整个子句都无法作为参数传入 + +例如，如果你想根据用户输入动态改变排序规则，你不能这样做： + +```java +// 错误的预编译用法 +String sql = "SELECT * FROM products ORDER BY ?"; +PreparedStatement pstmt = conn.prepareStatement(sql); +pstmt.setString(1, "price DESC"); // 无法将排序规则作为参数传入 +``` + +**3. 动态的 `IN` 子句中的值列表** + +`IN` 子句中的值列表长度是可变的，预编译的占位符数量是固定的。因此，你不能直接将整个列表作为参数传入 + +例如，如果你想查询多个ID的用户，不能这样做： + +```java +// 错误的预编译用法 +String sql = "SELECT * FROM users WHERE id IN (?)"; +PreparedStatement pstmt = conn.prepareStatement(sql); +pstmt.setString(1, "101, 102, 103"); // 字符串“101, 102, 103”会被当作一个值 +``` + +**正确的做法：动态生成占位符** + +对于这种情况，你需要在代码中根据用户输入的列表动态生成相应数量的占位符 + +```java +// 正确的做法 +List userIds = getUserIdsFromInput(); // 假设用户输入：101, 102, 103 +StringBuilder sqlBuilder = new StringBuilder("SELECT * FROM users WHERE id IN ("); +for (int i = 0; i < userIds.size(); i++) { + sqlBuilder.append("?"); + if (i < userIds.size() - 1) { + sqlBuilder.append(", "); + } +} +sqlBuilder.append(")"); + +String sql = sqlBuilder.toString(); // 生成的SQL：SELECT * FROM users WHERE id IN (?, ?, ?) +PreparedStatement pstmt = conn.prepareStatement(sql); +for (int i = 0; i < userIds.size(); i++) { + pstmt.setInt(i + 1, userIds.get(i)); +} +ResultSet rs = pstmt.executeQuery(); +``` \ No newline at end of file diff --git a/Chapter7/7-41.md b/Chapter7/7-41.md new file mode 100644 index 0000000..d62c8bf --- /dev/null +++ b/Chapter7/7-41.md @@ -0,0 +1,10 @@ +### SYN 开放链接原理 + +SYN 扫描的原理是基于 **TCP（传输控制协议）三次握手** 的过程，但它并不会完成完整的三次握手 + +1. **发送 SYN 包**：渗透测试工具（如 Nmap）向目标主机的特定端口发送一个 **SYN（同步）** 数据包。这个包的作用是发起一个连接请求 +2. **接收 SYN/ACK 包**： + - 如果目标主机的端口处于 **开放（Open）** 状态，它会响应一个 **SYN/ACK（同步/确认）** 数据包，表示它接受了连接请求，并准备好进行下一步的确认 + - 如果端口处于 **关闭（Closed）** 状态，目标主机通常会响应一个 **RST（复位）** 数据包，表示拒绝连接 + - 如果端口被防火墙过滤（**Filtered**），可能不会有任何响应，或者收到一个 ICMP（Internet 控制消息协议）的“目标不可达”消息 +3. **发送 RST 包**：这是 SYN 扫描最关键的一步。在收到 SYN/ACK 包后，渗透测试工具并不会像正常连接那样发送最终的 ACK 包来完成三次握手。相反，它会立即发送一个 **RST（复位）** 数据包来终止连接 \ No newline at end of file diff --git a/Chapter7/7-42.md b/Chapter7/7-42.md new file mode 100644 index 0000000..d70b34b --- /dev/null +++ b/Chapter7/7-42.md @@ -0,0 +1,44 @@ +### 了解 Linux /proc 目录吗 + +**`/proc` 目录的主要作用** + +`/proc` 目录主要用于以下几个方面： + +1. **进程信息**：这是它最重要的功能。每个正在运行的进程都有一个以其**进程 ID (PID)** 命名的子目录。例如，PID 为 `1234` 的进程，其所有信息都存放在 `/proc/1234/` 目录下 +2. **系统信息**：它提供了大量关于系统硬件和内核状态的信息 +3. **内核参数调优**：通过修改 `/proc/sys/` 目录下的文件，你可以动态地调整内核参数，而无需重启系统 + +**常见的 `/proc` 子目录和文件** + +下面详细介绍一些在应急响应和系统管理中特别常用的文件和目录 + +**1. 进程相关的目录：`/proc//`** + +- `/proc//cmdline`: 存储进程的完整启动命令，包括所有参数。这对于识别可疑进程非常有用 +- `/proc//exe`: 一个指向进程可执行文件的符号链接。通过 `ls -l` 可以看到它实际指向的文件路径，比如 `/usr/bin/nginx` +- `/proc//cwd`: 指向进程的当前工作目录 +- `/proc//fd/`: 存放了该进程所有打开的文件描述符的符号链接。我之前提到的 `ls -l /proc//fd/` 命令就是在这里工作的。通过它你可以迅速定位进程打开了哪些文件和网络连接 +- `/proc//status`: 提供了更详细的进程状态信息，比如进程名、父进程ID、内存使用情况（`VmSize`）、进程权限（`Uid`） + +**2. 系统信息文件** + +- `/proc/cpuinfo`: 包含CPU的详细信息，如型号、核心数、缓存大小等 +- `/proc/meminfo`: 显示系统内存使用情况，包括总内存、可用内存、缓冲区和缓存 +- `/proc/version`: 包含Linux内核版本信息 +- `/proc/mounts`: 包含了当前系统中所有已挂载的文件系统，包括设备、挂载点、文件系统类型和挂载选项 + +**3. 内核参数文件：`/proc/sys/`** + +这个目录允许你查看和修改内核的运行时参数 + +- `/proc/sys/net/ipv4/ip_forward`: 控制 IPv4 数据包转发功能。值为 `1` 表示开启路由，`0` 表示关闭 +- `/proc/sys/fs/file-max`: 控制系统范围内可以打开的最大文件句柄数 +- `/proc/sys/kernel/hostname`: 显示或设置系统主机名 + +你可以用 `echo` 命令来修改这些参数，例如： + +```bash +echo 1 > /proc/sys/net/ipv4/ip_forward +``` + +**注意：** 这种修改是临时的，系统重启后会失效。如果需要永久生效，应该修改 `/etc/sysctl.conf` 文件 \ No newline at end of file diff --git a/Chapter7/7-43.md b/Chapter7/7-43.md new file mode 100644 index 0000000..022ad15 --- /dev/null +++ b/Chapter7/7-43.md @@ -0,0 +1,103 @@ +### 如何监控 Linux 文件操 + +**1. Auditd** + +**`Auditd`** 是 Linux 内核提供的、功能最强大且最专业的审计工具。它可以记录几乎所有的系统调用，包括文件读、写、执行等操作，并能根据规则进行过滤。 + +**优点：** + +- **全面而精准**：可以精确地监控指定用户、指定目录或特定系统调用 +- **安全性高**：即使系统被入侵，攻击者也很难篡改 `auditd` 的日志 +- **可配置性强**：可以通过规则文件（`/etc/audit/audit.rules`）自定义监控策略。 + +**如何使用：** + +1. **安装**：大多数发行版默认已安装。如果没有，可以通过 `yum install audit` 或 `apt-get install auditd` 来安装 + +2. **添加监控规则**： + + - 监控 `/etc/` 目录下所有文件的写入、修改和权限变更： + + ```bash + auditctl -w /etc/ -p wa -k etc_changes + ``` + + - 监控所有对 `rm` 命令的调用： + + ```bash + auditctl -a always,exit -F arch=b64 -S unlink -S unlinkat -k file_deletion + ``` + +3. **查看日志**：日志默认存放在 `/var/log/audit/audit.log`，可以使用 `ausearch` 和 `aureport` 等工具进行查询和分析 + +**适用场景：** + +- **安全审计**：监控关键系统文件和目录，确保符合安全合规要求 +- **事后取证**：当发生安全事件时，可以从日志中追踪攻击者的文件操作行为 + +**2. inotifywait** + +`inotify` 是 Linux 内核提供的文件系统事件监控接口，而 **`inotifywait`** 是一个命令行工具，它利用这个接口实时监控文件或目录的事件，比如创建、删除、修改等 + +**优点：** + +- **实时性**：可以实时监控文件系统的变化 +- **轻量级**：安装和使用都很简单，对系统资源占用很小 +- **精确监控**：可以监控特定的事件类型 + +**如何使用：** + +1. **安装**：`yum install inotify-tools` 或 `apt-get install inotify-tools` + +2. **开始监控**： + + - 实时监控 `/tmp` 目录下的创建、删除、移动和写入操作： + + ```bash + inotifywait -m -r -e create,delete,move,modify /tmp/ + ``` + + - `-m`：持续监控 + + - `-r`：递归监控子目录 + + - `-e`：指定要监控的事件 + +**适用场景：** + +- **脚本化监控**：可以轻松地集成到 shell 脚本中，当发生特定文件操作时，自动触发报警或执行其他操作 +- **快速排查问题**：例如，某个应用程序突然写入了大量日志文件，你可以用 `inotifywait` 来快速定位是哪个文件被修改了 + +**3. FIM 工具** + +**FIM** 工具，如 **Tripwire** 和 **AIDE**（Advanced Intrusion Detection Environment），通过定期计算文件的哈希值（如 SHA256），来监控文件的完整性。如果哈希值发生变化，则说明文件被修改 + +**优点：** + +- **强大的事后取证能力**：能够准确地识别出哪些文件在何时被修改 +- **防御篡改**：可以检测到攻击者对系统文件、恶意软件的篡改 + +**如何使用（以 AIDE 为例）：** + +1. **安装**：`yum install aide` 或 `apt-get install aide` + +2. **创建基线数据库**：在系统干净时运行，生成文件的哈希值数据库 + + ```bash + aide --init + ``` + +3. **移动数据库**：将生成的 `aide.db.new.gz` 文件改名为 `aide.db.gz` 并移动到安全位置 + +4. **定期检查**： + + ```bash + aide --check + ``` + + 这会与基线数据库进行对比，并报告所有变更 + +**适用场景：** + +- **系统加固**：定期检查关键系统文件（如 `/etc`、`/bin`）是否被非法修改 +- **入侵检测**：当怀疑系统被入侵时，FIM 工具能迅速找出被篡改的文件 diff --git a/Chapter7/7-44.md b/Chapter7/7-44.md new file mode 100644 index 0000000..a684076 --- /dev/null +++ b/Chapter7/7-44.md @@ -0,0 +1,17 @@ +### Windows Defender 安全机制 + +**1. 实时保护** + +这是最基础也是最重要的功能。它会持续监控你的系统，检查你打开、下载或运行的每一个文件和程序。如果发现任何可疑行为或已知的恶意软件，它会立即阻止并隔离威胁 + +**2. 云端保护** + +这是 Defender 现代化的关键。当一个新文件被发现时，Defender 会快速将它的哈希值发送到微软的智能安全图谱 (Microsoft Intelligent Security Graph)。这个庞大的数据库包含了来自全球数十亿台设备的威胁情报。如果这个文件已经被识别为恶意，Defender 会在**毫秒级**的时间内做出响应，阻止威胁。即使是一个全新的、未知的病毒，如果它的行为模式与已知的恶意软件相似，云端也会快速分析并标记它 + +**3. 行为监控** + +Defender 不仅仅依赖签名库。它还会监控程序的**行为**。例如，如果一个正常程序突然开始尝试修改系统关键文件、加密你的个人文件（勒索软件的典型行为），或者尝试进行网络连接，Defender 就会将其标记为可疑并阻止。这种机制可以有效防御那些没有被病毒库收录的“零日漏洞”攻击。 + +**4. 防火墙与网络保护** + +Windows Defender 防火墙是另一道重要的防线。它可以控制进出你电脑的所有网络流量。你可以设置规则来允许或阻止特定程序访问网络，从而防止恶意软件与外部服务器进行通信，或者阻止黑客从外部入侵你的系统 \ No newline at end of file diff --git a/Chapter7/7-45.md b/Chapter7/7-45.md new file mode 100644 index 0000000..b95ffdb --- /dev/null +++ b/Chapter7/7-45.md @@ -0,0 +1,39 @@ +### 什么是 TCP 粘包/拆包 + +**什么是 TCP 粘包？** + +**TCP 粘包 (Nagle's Algorithm)** 指的是发送方发送的多个数据包，在接收端看起来就像是一个大的数据包。简单来说，就是多个独立的报文被“粘”在一起了 + +这通常发生在以下情况： + +- **发送方发送频率快，数据量小**：当发送方以极快的速度发送多个小数据包时，TCP 协议的 **Nagle 算法**会为了提高网络利用率，将这些小数据包缓存起来，直到积累到一定大小或者收到接收方的 ACK 确认后，才一次性发送出去 +- **接收方读取速度慢**：当接收方应用程序从缓冲区读取数据时，如果一次性读取了多个数据包，就会发生粘包 + +**举个例子：** + +假设客户端连续发送了两个数据包，内容分别是 `“Hello”` 和 `“World”` + +1. 发送方将 `“Hello”` 发送出去 +2. 发送方很快又发送 `“World”`，但此时网络可能拥塞，或 Nagle 算法正在等待 +3. TCP 将这两个数据包合并，一次性发送给接收方 +4. 接收方在接收缓冲区中收到的是 `“HelloWorld”` + +接收端的应用程序在读取时，无法区分出这是两个独立的消息，因此造成了**粘包**问题 + +**什么是 TCP 拆包？** + +**TCP 拆包**与粘包相反，指的是一个完整的数据包被拆分成多个小数据包进行发送 + +这通常发生在以下情况： + +- **发送的数据包过大**：当发送的数据包超过 TCP 缓冲区的最大值时，TCP 会自动将其拆分为多个数据包进行传输 +- **网络传输过程中出现拥塞**：网络拥塞时，路由器或防火墙可能会对数据包进行分片（fragmentation）。 + +**举个例子：** + +假设客户端发送了一个 2000 字节的数据包，但网络 MTU（最大传输单元）是 1500 字节 + +1. 发送方将 2000 字节的数据包拆分为两个数据包：第一个 1500 字节，第二个 500 字节 +2. 接收方在接收缓冲区中先收到 1500 字节的数据，然后又收到 500 字节的数据 + +接收端应用程序在读取时，可能只读取到一部分数据，导致无法获得一个完整的消息，从而造成**拆包**问题 \ No newline at end of file diff --git a/Chapter7/7-46.md b/Chapter7/7-46.md new file mode 100644 index 0000000..1b2210d --- /dev/null +++ b/Chapter7/7-46.md @@ -0,0 +1,18 @@ +### session 的工作原理 + +**Session 的基本工作流程** + +Session 的核心思想是：将用户的状态信息存储在**服务器端**，而客户端（浏览器）只存储一个**唯一标识符** + +1. **用户初次访问**：当用户第一次访问 Web 应用时，服务器会执行以下操作： + - **创建 Session 对象**：在服务器端为这个新用户创建一个 Session 对象 + - **生成唯一标识符**：为这个 Session 对象生成一个唯一的 ID，通常称为 **Session ID** + - **存储状态信息**：可以将用户的登录状态、购物车内容等信息存入这个 Session 对象 + - **发送 Session ID**：将 Session ID 作为响应的一部分，发送给浏览器。通常，这个 Session ID 会被嵌入在 **Cookie** 中，名字可能类似于 `JSESSIONID` +2. **浏览器存储 Session ID**： + - 浏览器接收到服务器的响应后，会将这个包含 Session ID 的 Cookie 存储起来 +3. **用户后续访问**：当用户再次访问同一 Web 应用时，浏览器会自动在请求头中带上之前存储的 Session ID Cookie +4. **服务器识别用户**： + - 服务器接收到请求后，会从请求头中解析出 Session ID + - 服务器根据这个 Session ID，在服务器端的 Session 存储中找到对应的 Session 对象 + - 这样，服务器就能识别出是哪个用户在操作，并获取其之前的状态信息（例如，用户已经登录） \ No newline at end of file diff --git a/Chapter7/7-47.md b/Chapter7/7-47.md new file mode 100644 index 0000000..bd0c1bc --- /dev/null +++ b/Chapter7/7-47.md @@ -0,0 +1,50 @@ +### HTTP 长连接和短连接的区别 + +**什么是 HTTP 短连接？** + +**HTTP 短连接**指的是浏览器和服务器每进行一次 HTTP 操作（如获取一个 HTML 文件、一张图片或一个 CSS 文件），就建立一次 TCP 连接，传输完毕后立即断开连接 + +**工作流程：** + +1. **建立连接**：客户端（浏览器）向服务器发起 TCP 连接（三次握手） +2. **发送请求**：客户端发送 HTTP 请求 +3. **发送响应**：服务器发送 HTTP 响应 +4. **断开连接**：服务器和客户端立即断开 TCP 连接（四次挥手） +5. **重复**：如果客户端还需要请求其他资源，就必须重复上述所有步骤 + +**特点：** + +- **优点**：实现简单，服务器在请求处理完毕后立即释放资源，适合请求频率较低的场景 +- **缺点**： + - **性能开销大**：每次请求都需要经过 TCP 三次握手和四次挥手，这会增加大量的网络延迟 + - **资源消耗高**：大量的连接建立和断开操作会消耗服务器和客户端的 CPU 和内存资源 + +**什么是 HTTP 长连接？** + +**HTTP 长连接**（也称作 **HTTP Keep-Alive** 或 **HTTP Persistent Connection**）指的是浏览器和服务器建立 TCP 连接后，在一次请求/响应完成后，不会立即断开连接，而是保持连接状态。后续的请求和响应可以在这个已建立的连接上继续进行 + +**工作流程：** + +1. **建立连接**：客户端向服务器发起 TCP 连接（三次握手） +2. **发送请求**：客户端发送 HTTP 请求 +3. **发送响应**：服务器发送 HTTP 响应 +4. **保持连接**：连接保持打开状态 +5. **重复**：客户端继续在这个连接上发送下一个请求，直到客户端或服务器决定关闭连接 +6. **断开连接**：当某个条件满足时（例如达到超时时间或请求数量上限），连接才会断开 + +**特点：** + +- **优点**： + - **性能更高**：省去了大量的 TCP 连接建立和断开的开销，显著减少了网络延迟 + - **资源利用率高**：减少了服务器的 CPU 和内存资源消耗 +- **缺点**： + - **资源占用**：服务器需要为每个活跃的连接维护状态，如果连接数量过多，可能会占用大量服务器资源 + - **实现复杂**：服务器端需要更精细的超时管理机制 + +| 特性 | 短连接 (Non-Persistent) | 长连接 (Persistent) | +| --------- | --------------------------- | -------------------------------------------- | +| 连接管理 | 一次请求/响应后立即断开 | 保持连接，重复利用 | +| TCP 开销 | 高（每次请求都需建立/断开） | 低（只在首次建立和最后断开） | +| 性能 | 低，网络延迟高 | 高，传输效率更高 | +| 应用场景 | 访问频率低的静态网页 | 频繁请求、动态内容多的网站，如电商、社交媒体 | +| HTTP 版本 | HTTP/1.0 默认 | HTTP/1.1 默认开启 | \ No newline at end of file diff --git a/Chapter7/7-48.md b/Chapter7/7-48.md new file mode 100644 index 0000000..2169753 --- /dev/null +++ b/Chapter7/7-48.md @@ -0,0 +1,55 @@ +### Xrange() 和 range() 返回的是什么 + +**`range`** + +在 Python 2 中，`range()` 函数返回一个**列表（list）**。它会立即生成所有数字，并将它们存储在内存中 + +```python +# Python 2 +my_list = range(5) +print my_list +# 输出: [0, 1, 2, 3, 4] +``` + +**优点：** + +- 它可以直接用于索引和切片，因为返回的是一个列表 + +**缺点：** + +- **内存消耗大**：如果你需要生成一个非常大的数字序列（例如 `range(1000000000)`），它会占用大量的内存，可能导致程序崩溃或运行缓慢 +- **速度慢**：生成大列表需要时间，这会影响程序的启动速度 + +**`xrange`** + +在 Python 2 中，`xrange()` 函数返回一个**生成器对象（xrange object）**。它并不会一次性生成所有数字，而是在你迭代它的时候，按需**惰性（lazily）**地生成每一个数字 + +```python +# Python 2 +my_generator = xrange(5) +print my_generator +# 输出: xrange(5) +``` + +**优点：** + +- **内存效率高**：它只存储生成规则，而不是所有数字，因此非常节省内存，即使处理巨大的数字序列也毫无压力 +- **速度快**：因为它不需要提前生成整个列表，所以速度非常快 + +**缺点：** + +- 不支持索引和切片，因为对象中并没有存储所有数字。你只能通过循环来访问其中的元素 + +**Python 3 中的变化** + +在 Python 3 中，`range()` 函数被重新设计，它的行为和 Python 2 中的 `xrange()` 一样，返回一个**可迭代对象（range object）**，而不是列表 + +`xrange()` 函数在 Python 3 中被移除 + +| 特性 | Python 2 range() | Python 2 xrange() | Python 3 range() | +| -------- | ---------------------- | ---------------------- | ------------------------- | +| 返回类型 | list (列表) | xrange object (生成器) | range object (可迭代对象) | +| 内存使用 | 高（立即生成所有数字） | 低（惰性生成） | 低（惰性生成） | +| 支持索引 | 是 | 否 | 是 | +| 性能 | 慢（处理大序列时） | 快 | 快 | +| 是否推荐 | 不推荐 | 推荐 | 推荐 | \ No newline at end of file diff --git a/Chapter7/7-49.md b/Chapter7/7-49.md new file mode 100644 index 0000000..858d5d8 --- /dev/null +++ b/Chapter7/7-49.md @@ -0,0 +1,38 @@ +### 怎么防重放攻击 + +**1. 使用一次性令牌 (Nonce) 或时间戳** + +这是最常见也最有效的防范手段。核心思想是确保每个请求都是唯一的，即使被截获也无法再次使用 + +- **一次性令牌 (Nonce)**: 这是一个随机生成的、只使用一次的字符串 + - **工作原理**: 服务器在发送给客户端的页面中嵌入一个隐藏的 Nonce。客户端在发送请求时，必须将这个 Nonce 包含在内。服务器端会验证这个 Nonce 是否被使用过。如果 Nonce 数据库中已存在，则拒绝该请求 + - **优点**: 安全性高，能有效防止攻击者重复使用旧的请求 + - **缺点**: 需要在服务器端维护一个 Nonce 数据库，增加了状态管理的复杂性 +- **时间戳 (Timestamp)**: 在请求中加入当前时间戳 + - **工作原理**: 客户端在发送请求时，将当前时间戳也作为参数发送。服务器接收到请求后，会检查时间戳是否在设定的有效时间窗口内（例如，30秒）。如果时间戳过期，则拒绝请求 + - **优点**: 实现简单，不依赖于 Nonce 数据库 + - **缺点**: 依赖于客户端和服务器时间的同步，如果两者时间差异较大，可能会导致正常请求被拒绝 + +**2. 添加序列号** + +在通信协议中为每个请求添加一个递增的序列号 + +- **工作原理**: 客户端在发送请求时，将一个单调递增的序列号也包含在内。服务器端会记录每个客户端会话的最新序列号。如果收到一个序列号比当前记录的小或等于的请求，则认为这是重放攻击，并拒绝该请求 +- **优点**: 简单有效，特别适用于有序的协议 +- **缺点**: 如果序列号在传输过程中丢失或被修改，可能会导致同步问题 + +**3. 使用安全哈希和消息认证码** + +这种方法可以验证消息的完整性和来源，从而发现消息是否被篡改或重放 + +- **工作原理**: 客户端在发送请求时，使用共享密钥对整个请求数据（包括时间戳或 Nonce）计算一个**消息认证码 (MAC)**，并将 MAC 附加在请求后面。服务器端收到请求后，用同样的密钥和数据重新计算 MAC，如果两个 MAC 不匹配，则请求无效 +- **优点**: 提供了数据完整性校验和来源认证，能够防御篡改和重放攻击 +- **缺点**: 需要安全地管理和分发共享密钥。 + +**4. 限制请求有效期** + +即使没有上述复杂的机制，也可以通过限制请求的有效期来增加重放攻击的难度 + +- **工作原理**: 服务器可以为每个请求设置一个短暂的生命周期。例如，当客户端请求登录凭证时，服务器可以返回一个有效期为 5 分钟的令牌。如果攻击者截获了这个令牌，它只能在 5 分钟内使用，过期后即失效 +- **优点**: 简单且易于实现 +- **缺点**: 不能完全防止在短时间内进行的重放攻击 \ No newline at end of file diff --git a/Chapter7/7-5.md b/Chapter7/7-5.md new file mode 100644 index 0000000..804b9ae --- /dev/null +++ b/Chapter7/7-5.md @@ -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** 文件，看是否被添加了未知的公钥 \ No newline at end of file diff --git a/Chapter7/7-50.md b/Chapter7/7-50.md new file mode 100644 index 0000000..89a59d8 --- /dev/null +++ b/Chapter7/7-50.md @@ -0,0 +1,85 @@ +### 讲讲 SYN FLOOD 原理，防御，检测手段 + +**SYN Flood 攻击原理** + +SYN Flood 是一种利用 TCP 三次握手过程中的漏洞发起的攻击 + +**正常的三次握手流程：** + +1. **SYN**：客户端向服务器发送一个 `SYN` 包，请求建立连接 +2. **SYN-ACK**：服务器收到 `SYN` 包后，分配资源，并回复一个 `SYN-ACK` 包 +3. **ACK**：客户端收到 `SYN-ACK` 后，回复一个 `ACK` 包，三次握手完成，连接建立 + +**SYN Flood 攻击原理：** 攻击者利用这个过程，向服务器发送大量的 `SYN` 包。但与正常连接不同的是，攻击者不会回复第三步的 `ACK` 包 + +1. **大量 SYN 包**：攻击者利用伪造的源 IP 地址（以隐藏自己的真实身份），向目标服务器发送海量的 `SYN` 包 +2. **服务器资源耗尽**：服务器收到每个 `SYN` 包后，都会为它在半开连接队列（Half-Open Connection Queue）中分配一个连接状态，并发送一个 `SYN-ACK` 包 +3. **无响应**：由于攻击者使用的是伪造的 IP 地址，服务器发送的 `SYN-ACK` 包永远不会被响应 +4. **队列饱和**：随着半开连接队列被大量伪造连接迅速填满，服务器无法再处理新的合法连接请求。最终，新的正常用户无法连接，导致服务不可用，即达到了拒绝服务攻击的目的 + +这种攻击的危害在于，攻击者利用极小的代价，就可以耗尽服务器大量的内存和 CPU 资源 + +**SYN Flood 防御手段** + +防御 SYN Flood 攻击主要从两个方向入手：**增加服务器处理能力**和**优化连接处理机制** + +**1. 调整 TCP/IP 参数** + +这是最简单直接的防御措施，可以通过修改 Linux 内核参数来增加半开连接队列的容量和缩短超时时间 + +- **`net.ipv4.tcp_max_syn_backlog`**: 增加这个参数的值，可以增大半开连接队列的容量 +- **`net.ipv4.tcp_synack_retries`**: 减少服务器发送 `SYN-ACK` 重试的次数，从而缩短半开连接的超时时间，更快地释放资源 + +**2. SYN Cookie** + +这是一种非常有效的防御机制，它改变了服务器处理 `SYN` 包的方式，使其在受到攻击时表现得更加健壮 + +**工作原理：** + +1. **不分配资源**：服务器收到 `SYN` 包后，不会立即为它分配资源 +2. **生成 Cookie**：服务器将客户端的 IP、端口、MSS 等信息，加上一个服务器独有的密钥，通过哈希算法生成一个 `SYN Cookie` +3. **发送 SYN-ACK**：服务器把这个 `SYN Cookie` 作为 TCP 序列号，发送 `SYN-ACK` 包 +4. **客户端回复**：如果客户端是合法的，它会回复一个 `ACK` 包，该包中的序列号正是 `SYN Cookie` 加 1 的值 +5. **验证 Cookie**：服务器收到 `ACK` 包后，不检查半开连接队列，而是根据其中的序列号，反向计算并验证 `SYN Cookie`。如果验证成功，才分配资源并建立连接 + +这种机制的优点是，在完成三次握手前，服务器不会为连接分配任何资源，从而大大降低了被 SYN Flood 攻击的风险。 + +**3. 硬件和软件防火墙** + +现代防火墙和入侵检测系统（IDS）通常内置了 SYN Flood 检测和防御功能 + +- **速率限制**：对来自同一 IP 或同一网段的 `SYN` 请求进行速率限制 +- **白名单/黑名单**：通过规则限制可疑 IP 的访问 +- **使用负载均衡器**：将请求分发到多台服务器，可以分散攻击流量 + +**SYN Flood 检测手段** + +及时发现 SYN Flood 攻击是防御的第一步。 + +**1. 系统网络状态监控** + +使用 `netstat` 或 `ss` 命令是监控 TCP 连接状态最常用的方法 + +```bash +# 查看所有 TCP 连接 +netstat -nt | grep tcp +# 使用 ss 查看 SYN_RECV 状态的连接 +ss -s +``` + +- 在正常情况下，`SYN_RECV` 状态的连接数量应该很小。如果这个数字突然暴增，就可能正在遭受 SYN Flood 攻击 + +**2. 网络流量分析** + +使用网络抓包工具（如 `tcpdump`）可以对流量进行深入分析 + +```bash +# 只抓取 SYN 包 +tcpdump -n 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' +``` + +- **分析结果**：如果抓到的流量中，大部分都是带有伪造源 IP 的 `SYN` 包，且没有后续的 `ACK` 包，那么基本可以断定是 SYN Flood 攻击 + +**3. IDS/IPS 日志** + +如果系统中部署了入侵检测系统（IDS）或入侵防御系统（IPS），它们会记录可疑的网络流量。通过查看 Snort、Suricata 等工具的日志，可以快速发现大量来自同一源 IP 或不同源 IP 的 `SYN` 攻击事件 \ No newline at end of file diff --git a/Chapter7/7-51.md b/Chapter7/7-51.md new file mode 100644 index 0000000..f0f007f --- /dev/null +++ b/Chapter7/7-51.md @@ -0,0 +1,63 @@ +### 讲讲 UDP 反射放大的原理，防御，检测手段 + +**UDP 反射放大攻击原理** + +UDP 反射放大攻击利用的是 **UDP 协议的无连接性**和一些 **特定协议的请求/响应不对称性**。攻击者不会直接攻击目标，而是通过中间服务器作为“放大器”，将小流量的请求放大成大流量的响应，然后将这些响应全部导向受害者 + +**工作流程：** + +1. **伪造请求**：攻击者首先伪造一个请求包，将**源 IP 地址**设置为受害者的 IP 地址。这个请求包通常非常小 +2. **发送给放大器**：攻击者将这个伪造的请求包发送给互联网上大量的开放服务，这些服务被称为“放大器”，例如 DNS 服务器、NTP 服务器、SSDP 服务等 +3. **触发放大**：这些放大器收到请求后，由于 UDP 协议不需要验证源 IP，它们会认为这个请求是合法的，并生成一个相应的响应包 +4. **反射与放大**：这个响应包被发送到伪造的源 IP 地址，即受害者的服务器。关键是，某些协议的响应包要比请求包大得多。例如，一个 60 字节的 DNS 查询请求，可能得到一个 3000 字节的响应。这个比率就是**放大倍数（Amplification Factor）** +5. **洪水攻击**：攻击者利用少量的请求流量，就可以通过成百上千个放大器，将巨大的响应流量反射到受害者服务器，导致其网络带宽耗尽，服务不可用 + +**UDP 反射放大攻击防御手段** + +防御这类攻击需要从多个层面入手，包括源头控制、网络路由和目标保护。 + +**1. BCP38（入站过滤）** + +**这是从源头遏制攻击的最佳方法。** BCP38 是 RFC2827 提出的最佳实践，要求网络服务提供商（ISP）在其网络边缘，对所有出站的数据包进行源 IP 地址验证 + +- **工作原理**：ISP 检查其客户发出的数据包。如果数据包的源 IP 地址不属于该客户分配的 IP 地址块，ISP 就应该丢弃这个数据包 +- **防御效果**：这可以阻止攻击者伪造源 IP 地址，从而使反射放大攻击无法成功。 + +**2. 服务端加固** + +作为服务器管理员，可以对自己的服务进行配置，防止被用作放大器 + +- **关闭不必要的 UDP 服务**：例如，如果不需要 DNS 解析或 NTP 服务，应关闭 UDP 端口 53 和 123 +- **限制请求速率**：对高放大倍数的 UDP 服务（如 DNS、NTP）设置请求速率限制 +- **禁用不安全的协议功能**：例如，禁用 DNS 服务的递归查询功能，或只允许内部 IP 进行递归查询 + +**3. 网络流量清洗（Traffic Scrubbing）** + +当攻击发生时，这是最有效的应对措施 + +- **工作原理**：流量清洗服务提供商（如 Cloudflare, Akamai）拥有巨大的网络带宽。当检测到 DDoS 攻击时，会将受害者的流量引导到其清洗中心 +- **过滤机制**：清洗中心通过协议分析和异常流量检测，识别并丢弃恶意流量，只将干净的正常流量转发给受害者 +- **防御效果**：这能有效吸收和过滤掉大量的反射放大流量，保护目标服务器 + +**4. 限制 UDP 速率** + +在防火墙、路由器或服务器上，对 UDP 流量进行速率限制 + +- **工作原理**：配置防火墙规则，限制特定 UDP 端口（如 53, 123）的入站流量速率 +- **优点**：简单易行 +- **缺点**：可能会误伤正常的 UDP 流量，导致服务不可用 + +**UDP 反射放大攻击检测手段** + +检测这类攻击通常依赖于流量监控和异常行为分析 + +**1. 流量监控与分析** + +- **流量突然暴增**：这是最直观的指标。监控网络流量图，如果 UDP 入站流量在短时间内激增，可能就是遭受了攻击 +- **端口异常**：分析入站流量。如果来自不常用或特定的 UDP 端口（如 53、123、1900）的流量异常增多，可能就是攻击正在进行 +- **数据包大小**：使用 `tcpdump` 或流量分析工具，观察入站 UDP 包的大小。如果大部分入站 UDP 包都异常大，而对应端口的出站请求包却很少，这正是反射放大攻击的典型特征 + +**2. 系统日志与连接状态** + +- **系统负载**：检查服务器的 CPU 和网络接口的负载情况。大量的入站流量会消耗 CPU 资源进行数据包处理，并迅速填满网络带宽 +- **服务日志**：查看 DNS、NTP 等服务的日志，如果发现异常多的请求，特别是来自大量的不同 IP 地址的请求，可能是攻击者在扫描和利用放大器 \ No newline at end of file diff --git a/Chapter7/7-6.md b/Chapter7/7-6.md new file mode 100644 index 0000000..ce69380 --- /dev/null +++ b/Chapter7/7-6.md @@ -0,0 +1,23 @@ +### 给你一个告警的内网 IP，怎么快速定位到他在哪栋楼哪层 + +**（优质的甲方是会给资产表的！！！）** + +**1. 找到 IP 地址所在的子网掩码** + +​ 1.1 通过查看 IP 地址和子网掩码可以确定这个 IP 地址所在的子网范围，从而缩小搜索范围 + +**2. 确定 IP 地址的 MAC 地址** + +​ 2.1 可以通过 ARP 请求获取到 IP 地址对应的 MAC 地址，然后查找交换机或路由器的 ARP 缓存表，找到 MAC 地址对应的端口 + +**3. 确定交换机或路由器的位置** + +​ 3.1 根据找到的交换机或路由器的端口，可以通过查看设备的物理位置和 IP 地址，确定设备的位置 + +**4. 确定线缆连接位置** + +​ 4.1 如果找到的设备有多个端口，则需要检查哪个端口连接了目标 IP 地址所在的子网，进而找到线缆的连接位置 + +**5. 确定线缆的路径** + +​ 5.1 根据线缆的连接位置，可以确定线缆的路径，从而确定目标IP地址的物理位置 \ No newline at end of file diff --git a/Chapter7/7-7.md b/Chapter7/7-7.md new file mode 100644 index 0000000..4271aff --- /dev/null +++ b/Chapter7/7-7.md @@ -0,0 +1,52 @@ +### SQL 注入防御方法 + +**1. 使用预编译语句** + +这是最有效、也是最推荐的防御方法。预编译语句会先将 SQL 语句发送到数据库进行编译，然后将用户输入作为参数传递给编译好的语句。这样一来，用户输入的数据就无法改变 SQL 语句本身的结构 + +- **原理**：将 SQL 语句与用户输入的数据分开处理。数据库会把用户输入的内容看作纯粹的**数据**，而不是可执行的**代码** +- **示例**： + - **不安全的代码**：`"SELECT * FROM users WHERE username = '" + userInput + "';"` + - 如果 `userInput` 是 `' OR 1=1 --`，整个语句就变成了 `SELECT * FROM users WHERE username = '' OR 1=1 --;`，从而绕过登录验证 + - **安全的预编译语句**：`"SELECT * FROM users WHERE username = ?;"` + - 这里的问号 `?` 是一个占位符。无论用户输入什么，都会被当作 `username` 字段的值来处理，而不是 SQL 代码 + +**2. 对所有用户输入进行严格验证和过滤** + +永远不要相信用户的任何输入。在将数据送入数据库之前，必须对其进行验证和过滤 + +- **白名单验证**：只允许特定的字符、格式或值通过。例如，如果某个输入框只接受数字，那么就只允许数字通过 +- **黑名单过滤**：禁止某些特定的危险字符或字符串，如单引号 `'`、分号 `;`、双破折号 `--` 等。但是，这种方法很容易被绕过，不推荐作为主要的防御手段 + +**3. 使用 ORM 框架** + +许多现代编程语言的框架都提供了 ORM 工具，例如 Java 的 Hibernate、Python 的 SQLAlchemy、PHP 的 Eloquent。这些框架通常内置了对 SQL 注入的保护机制 + +- **优点**： + - **安全性**：ORM 框架会自动处理参数绑定，将开发者从手动编写安全 SQL 语句的繁琐工作中解放出来 + - **易用性**：开发者可以使用面向对象的方式操作数据库，无需直接编写 SQL 语句 + +**4. 最小权限原则** + +为数据库账户分配最小的权限。一个账户如果只需要读取数据，就只给它 `SELECT` 权限，不要给它 `INSERT`、`UPDATE` 或 `DELETE` 权限 + +- **好处**：即使攻击者成功注入了 SQL 代码，也无法执行超出该账户权限范围的操作，如删除整个数据库 + + + +**5. 错误信息处理** + +不要向用户暴露详细的数据库错误信息。攻击者可以利用这些信息来了解数据库结构、版本等，从而更容易发起下一次攻击 + +- **正确做法**：当数据库查询失败时，只向用户显示一个通用的、友好的错误页面，并在后台日志中记录详细信息，供开发者排查 + +**6. 使用 Web 应用防火墙（WAF）** + +WAF 可以在 Web 应用之前对 HTTP 请求进行过滤和拦截，它可以识别并阻止包含 SQL 注入特征的恶意请求 + +- **优点**： + - **全面保护**：可以为整个应用提供一层额外的保护 + - **实时拦截**：在攻击到达应用之前就将其阻止 +- **局限性**： + - WAF 的规则可能需要不断更新，以应对新的攻击方式 + - 可能会有误报，影响正常用户的访问 \ No newline at end of file diff --git a/Chapter7/7-8.md b/Chapter7/7-8.md new file mode 100644 index 0000000..eb3bdb2 --- /dev/null +++ b/Chapter7/7-8.md @@ -0,0 +1,17 @@ +### 数万条告警怎么快速找到攻击成功的告警 + +优先**过滤掉无效告警和误报告警**，从而大幅降低分析成本 + +- **无效告警的判断**：无效告警通常是由于攻击者对非活跃或不存在的资产进行扫描而产生的。例如，攻击者对某个 C 段进行批量扫描，尽管安全设备产生了告警，但如果被扫描的 IP 根本没有运行任何服务，那么这个告警就是无效的 +- **误报告警的判断**：误报告警通常是由于安全设备的特征规则被非攻击行为意外触发。我们可以通过以下方式来判断： + - **流量分析**：分析流量数据包，看它是否符合正常的业务操作 + - **HTTP状态码与页面回显**：检查告警中 URL 的 HTTP 状态码。如果状态码是 404（未找到），或者页面回显数据是通用错误信息，那么这很可能是一次**未成功**的攻击尝试，可以作为误报的判断条件 + +经过第一步的筛选后，剩下的告警就更有分析价值了。我们需要从这些“待分析告警”中提取**攻击特征**，并将其与**情报线索**进行关联 + +- **提取攻击特征**：从告警日志中提取关键信息，例如攻击的 Payload + - 例如，在告警数据中发现 `/index/index/index?options=id)%2bupdatexml(...)` 这段 Payload +- **情报关联**：将提取的攻击特征与**攻击特征规则库**进行匹配 + - 通过匹配，我们发现上述 Payload 与 **ThinkPHP5 框架的 SQL 注入漏洞**相关联 +- **资产指纹核查**：在获取到情报线索后，并不是所有关联的告警都需要深入分析。我们需要结合**资产指纹信息库**进行核查 + - 继续上面的例子，如果被攻击的资产并没有使用 ThinkPHP5 框架，那么尽管 WAF 发出了告警，但这起攻击尝试是**不可能成功**的。这种情况下，我们可以将这条告警排除，从而进一步缩小分析范围 \ No newline at end of file diff --git a/Chapter7/7-9.md b/Chapter7/7-9.md new file mode 100644 index 0000000..ecbe2a8 --- /dev/null +++ b/Chapter7/7-9.md @@ -0,0 +1,44 @@ +### WebShell 查杀后仍有流量怎么办 + +**第一步：确认并隔离威胁** + +- **立即隔离**：最重要的一步是立即将受感染的服务器从网络中隔离出来。拔掉网线，或者在防火墙上设置策略，切断所有入站和出站的网络连接。这能防止攻击者继续控制服务器，并阻止他们进行横向移动，感染其他内网资产 +- **确认流量来源**： + - **查看进程**：使用 `netstat -ano` （Windows）或 `netstat -anp` （Linux）命令，查找建立异常外连的进程 + - **关联PID**：找到可疑进程的PID（进程ID），然后使用 `ps -ef | grep [PID]` （Linux）或任务管理器（Windows）来确定该进程的详细信息，包括其父进程、启动路径和命令行参数 + +**第二步：分析与清除持久化机制** + +当 WebShell 被清除后，外连流量依然存在，这表明攻击者已经利用 WebShell **留下了后门** + +- **排查计划任务**：攻击者最常用的持久化方式之一就是利用计划任务 + - **Linux**：检查 `/etc/crontab`、`/etc/cron.d/`、`/var/spool/cron/` 和用户的 `crontab -l`，查找是否有可疑的定时任务，例如定时执行脚本或下载恶意文件的任务 + - **Windows**：使用 `schtasks` 命令或任务计划程序来检查是否存在异常的定时任务 +- **排查自启动项**：恶意程序可能会通过系统自启动项实现开机自启 + - **Linux**：检查 `/etc/rc.local`、`/etc/profile`、`~/.bashrc` 等文件 + - **Windows**：检查注册表的 `HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run` 和 `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run` +- **排查系统服务**：攻击者可能会创建新的系统服务 + - **Windows**：使用 `services.msc` 或 `sc query state=all` 命令检查是否有异常服务 + - **Linux**：检查 `/etc/init.d/` 或 `/lib/systemd/system/` 目录 +- **排查系统后门文件**：恶意文件可能被伪装成系统文件，藏在 `/tmp`、`/var/tmp` 或 `/var/shm` 等临时目录，甚至是 `/bin` 或 `/usr/bin` 下 + +**第三步：取证与溯源** + +在清除所有威胁后，我们需要进行更深入的取证，以了解攻击者是如何入侵的 + +- **检查日志**： + - **Web日志**：分析Web服务器的 `access.log` 和 `error.log`，查找可疑的入侵路径 + - **系统日志**：检查 `/var/log/secure` 或 `auth.log`，看是否有异常登录或权限提升记录 + - **其他日志**：检查数据库、FTP 等服务的日志，寻找可疑的活动 +- **文件时间戳**：使用 `ls -alt` 命令，查看最近修改的文件，这有助于发现攻击者新创建的恶意文件 +- **威胁情报**：将可疑的 IP 地址、域名、文件哈希值提交到威胁情报平台，看它们是否与已知的恶意活动相关 + +**第四步：修复漏洞并加固** + +- **漏洞修复**：定位并修复被利用的漏洞。如果攻击者是通过 WebShell 入侵的，很可能是因为 Web 应用存在漏洞，例如文件上传、代码执行或反序列化漏洞 +- **权限收紧**： + - **应用权限**：将 Web 应用以低权限用户运行，限制其对文件系统的读写权限 + - **账户权限**：删除攻击者创建的任何后门账户，并修改所有关键账户的密码 +- **安全设备加固**： + - **WAF/IPS**：更新 WAF 和 IPS 的规则，以阻止已知的攻击 Payload + - **端点安全**：在服务器上部署 EDR，增强对恶意进程的检测和响应能力 \ No newline at end of file diff --git a/Chapter7/README.md b/Chapter7/README.md index 8b13789..9eecb4f 100644 --- a/Chapter7/README.md +++ b/Chapter7/README.md @@ -1 +1,20 @@ +# 网安面试题（涵盖护网、红队、逆向、二进制） +上万道安全面试题已经全部为您划分好，适用于网络安全所有岗位！！！ + +HR：请问………… + +我：叽里咕噜说啥呢，看看八股文上写了没 + +（Summary.md 是目录噢！！） + +**🙏 特别感谢名单** + +在整理和完善本项目的过程中，以下朋友给予了宝贵的帮助与支持，在此表示诚挚的感谢！（排名不分先后） + +- **@用户名1** —— 提供了大量安全面试题方向的补充 +- **@用户名2** —— 纠正了多个问题的答案与表述 +- **@用户名3** —— 贡献了真实面试题经验分享 +- **@用户名4** —— 对内容结构与目录提出改进建议 + +如果您也愿意参与本项目，欢迎通过 **微信: XR3327026244** 投稿面试题或反馈问题，我们会在后续版本中加入您的名字