简介：burpFakeIP-master.zip 面向从事 Web 安全测试与渗透测试的安全研究员，提供一款基于 Burp Suite 的 IP 伪装插件，用于在发起请求时模拟不同源 IP，从而隐藏真实身份、验证基于 IP 的访问控制策略或模拟多地区用户访问。资源包共 12 个文件，以 9 张 png 界面与配置截图、1 个 py 脚本、1 个 txt 测试文件及 1 个 md 说明文档为主，压缩包约 1.09MB，体积轻量，便于快速解压查阅。目前已有 413 人学习下载。借助截图可直观了解插件在 Burp Suite 中的加载与参数配置过程，py 脚本与说明文档则帮助理解其实现思路与使用方式，适合希望扩展 Burp 插件能力、研究请求源地址改写机制的安全从业者参考，使用时须遵守法律法规并在授权范围内测试。
1. 一个把伪造 IP 塞进 Burp 的小插件，到底解决谁的痛点
做渗透测试的人大概都遇到过这种场景：目标站点对来源 IP 做了限制，或者后台白名单只放行某几个网段，你在本地怎么改请求头都绕不过去，因为服务端校验的是 TCP 层的真实地址，而不是你手写的X-Forwarded-For。这时候如果能在 Burp Suite 里直接伪造源 IP，让经过代理的请求带上一个可控的地址，很多测试就能继续往下走。burpFakeIP-master.zip 就是干这件事的——它是一个 Burp Suite 的 Java 插件，编译打包后加载进 Burp，在 Proxy 拦截的请求上做 IP 伪造处理。适合已经熟悉 Burp 基本操作、需要针对 IP 限制类逻辑做验证的安全从业者，新手也能照着步骤装起来，但得先搞清楚它的边界在哪，别指望它万能。
2. 插件原理与加载：从 jar 包到 Burp 里的一个标签页
2.1 它改的是什么，不改的是什么
先把预期摆正。这个插件的核心动作是在 Burp 的请求处理链路上介入，对经过 Proxy 的 HTTP 请求做源地址相关的伪造处理。要理解它为什么有时管用有时不管用，得区分两个层面：应用层和网络层。应用层的东西，比如X-Forwarded-For、X-Real-IP、Client-IP这些请求头，服务端如果只是简单读取头部做判断，那伪造头部就能生效，这类需求其实用 Burp 自带的 Match and Replace 也能做，插件在这里的价值是把规则集中管理、批量生效。网络层的东西，比如服务端直接看 socket 的对端地址，那任何应用层的头部伪造都没用，插件也改不了 TCP 连接的真实源地址——它跑在 Burp 的扩展 API 里，能碰的是请求对象，不是网卡。
所以这个插件的定位是：把「伪造来源标识」这件事在 Burp 内部做成可配置、可开关、可批量应用的能力，而不是一个网络层的地址欺骗工具。搞清这一点，后面调参数和排查问题时就不会走偏。常见做法是把它当成请求头的批量注入器来用，配合目标站点的实际校验逻辑去试，而不是无脑打开就以为所有 IP 限制都能过。
2.2 编译打包：没有现成 jar 就自己 build
下载下来的 burpFakeIP-master.zip 是源码包，解压后是标准的 Java 工程结构，通常带pom.xml或build.gradle。Burp 的扩展 API 依赖的是它自带的接口 jar，编译时需要把 Burp 安装目录下的burp-extender-api.jar引入 classpath。以 Maven 工程为例，先确认本机有 JDK，Burp 扩展对 JDK 版本有要求，老版本 Burp 用 JDK 8 比较稳，新版本可以上 11 及以上，具体看你的 Burp 版本。
# 解压源码包 unzip burpFakeIP-master.zip cd burpFakeIP-master # 确认工程结构，找构建文件 ls -la # 常见输出：pom.xml src/ README.md # 如果工程里没有把 burp-extender-api 配进依赖，手动装到本地仓库 # 路径按你本机 Burp 安装位置调整 mvn install:install-file \ -Dfile="/path/to/BurpSuite/burp-extender-api.jar" \ -DgroupId=net.portswigger \ -DartifactId=burp-extender-api \ -Dversion=2.3 \ -Dpackaging=jar # 打包，跳过测试加快速度 mvn clean package -DskipTests这段命令的逻辑是：先解压看结构，再把 Burp 的扩展 API jar 装进本地 Maven 仓库，最后打包。参数上-DskipTests是因为这类小插件通常没写单测，跑测试只会拖时间；-Dversion填什么不重要，只要和pom.xml里声明的依赖版本对得上就行。打包成功后产物在target/目录下，文件名一般是burpFakeIP-<version>.jar或带-jar-with-dependencies后缀。这里有个血泪经验：如果pom.xml里用了 shade 或 assembly 插件打胖包，优先选带依赖的那个 jar，否则加载时可能报NoClassDefFoundError。
如果工程是 Gradle 的，命令换成./gradlew build，产物在build/libs/下，逻辑一样。没有构建工具的老式工程，就用javac手动编译再jar打包，但这种情况少见，多数源码包都带了构建文件。
2.3 加载进 Burp 并确认生效
打包出 jar 之后，打开 Burp，进 Extender 标签页，Add 扩展，类型选 Java，指向刚打出来的 jar。加载成功的标志是 Extender 的 Output 或 Errors 里没有红色报错，并且 Burp 主界面多出一个该插件的标签页或菜单项。如果加载后没反应，先看 Errors 面板，最常见的是 JDK 版本不匹配和 API 版本不匹配两类。
Burp -> Extender -> Extensions -> Add Extension type: Java Extension file: target/burpFakeIP-<version>.jar 加载后检查： - Extender -> Errors 无异常堆栈 - 顶部出现插件对应 Tab - Proxy -> Intercept 打开后请求能被插件处理加载这一步的坑在于 Burp 版本差异。新版 Burp 对扩展 API 有调整，老插件直接加载可能报方法找不到；反过来老版本 Burp 加载新编译的插件也可能不认。遇到这种情况，要么换对应版本的 Burp，要么改源码里的 API 调用。我一般会先在 Extender 里看加载日志的完整堆栈，堆栈第一行的类名和方法名基本就指向问题所在，比盲目换版本高效。
3. 伪造规则怎么配：请求头注入与拦截联动
3.1 规则配置的字段与含义
插件加载后，配置界面通常围绕几个核心字段展开：目标匹配（决定对哪些请求生效）、伪造的 IP 值（填什么地址）、注入位置（请求头还是其他位置）、开关状态。不同实现细节会有差异，但思路一致。配置时最关键的是「目标匹配」这一项，如果填得太宽，所有经过 Burp 的请求都被改，包括你访问 Burp 自身更新、访问其他测试目标的流量，容易把无关请求搞乱；填得太窄，又可能漏掉真正要测的接口。
常见做法是按 Host 或 URL 正则来限定范围，只对目标域名生效。伪造的 IP 值建议用保留地址段，比如127.0.0.1、10.x.x.x、192.168.x.x这类内网地址，或者目标站点所在网段的地址，具体填哪个取决于你要验证的校验逻辑。如果目标是验证「内网 IP 是否被信任」，就填内网段；如果验证「特定 IP 是否在白名单」，就填那个 IP。别随手填公网地址，一是没意义，二是可能触发目标的风控。
典型配置项（字段名以实际插件为准）： Match/Host: ^target\.example\.com$ Fake IP: 10.0.0.8 Header: X-Forwarded-For Enabled: true上面这段是配置思路的示意，不是某个固定版本的字段名。参数说明：Match用正则限定生效范围，锚定首尾避免误匹配子域；Fake IP填你要伪装的地址；Header指定注入到哪个请求头，如果插件支持多头部同时注入，可以把X-Real-IP、Client-IP一起配上，覆盖服务端可能读取的不同字段。这一步的玄学在于，不同框架读的头部不一样，Spring 系常看X-Forwarded-For，有些网关看X-Real-IP，还有看Forwarded标准头的，多配几个总没坏处。
3.2 和 Proxy 拦截配合的实操流程
配好规则不等于生效，得走一遍完整链路验证。流程是：打开 Proxy 的 Intercept，浏览器配好 Burp 代理，访问目标站点，在拦截到的请求上确认插件是否已经改写了头部。如果插件是在请求发出前自动处理，你在 Intercept 里看到的应该已经是改写后的请求；如果插件依赖手动触发，就得在拦截界面点对应按钮。
1. Proxy -> Intercept -> Intercept is on 2. 浏览器访问目标 URL 3. 在拦截到的请求里检查头部： X-Forwarded-For: 10.0.0.8 4. 放行请求，在 HTTP history 里回看确认 5. 对比关闭插件时的请求，确认差异只出现在预期头部这段流程的价值在于建立对照。很多人配完规则直接放行，看到响应正常就以为生效了，其实可能插件根本没匹配上，请求原样发出去了。正确做法是开一次关一次，对比 HTTP history 里两条请求的头部差异，差异符合预期才算配置成功。如果开了插件但头部没变，回到上一节的匹配规则排查，八成是正则没匹配上 Host。
3.3 用 Repeater 做单请求验证
Proxy 拦截适合看批量流量，单点验证用 Repeater 更干净。把一条请求发到 Repeater，改好头部，反复发送看响应变化。这里要注意，Repeater 里手动改的头部和插件自动注入的头部可能叠加，验证插件效果时最好先关掉手动修改，只看插件注入的结果。
操作顺序： HTTP history 右键 -> Send to Repeater Repeater 中确认插件注入的头部存在 修改 Fake IP 值，重发，观察响应差异 记录哪些 IP 值触发了不同响应（白名单命中/拒绝/报错）参数层面，Repeater 里重点观察的是响应状态码和响应体里的提示信息。如果换 IP 后响应从 403 变成 200，说明伪造生效且命中了信任逻辑；如果响应完全没变，要么插件没生效，要么服务端根本不看这个头部。这一步是判断「插件有没有用」的最快方式，比在 Proxy 里翻历史记录高效得多。
4. 避坑与排查：五条踩过的记录
4.1 加载报 NoClassDefFoundError
现象：Extender 里加载 jar 后立刻报错，堆栈里有NoClassDefFoundError，插件标签页出不来。原因：打出来的是瘦包，依赖的第三方库没打进去，Burp 的 classloader 找不到对应类。解决：改用 shade/assembly 插件打胖包，或者把缺失的依赖 jar 一起放进 Burp 的扩展加载路径。判断方法很简单，看报错里缺的类名是不是工程pom.xml里声明的依赖，是的话就是打包问题。
4.2 插件加载成功但请求头没变化
现象：Extender 无报错，插件界面也在，但拦截到的请求头部原封不动。原因：匹配规则没命中，最常见的是 Host 正则写错，比如带了端口号没处理，或者用了.*之外的写法导致大小写不匹配。解决：把匹配规则临时放宽到.*测试，确认插件本身工作正常，再逐步收紧到目标 Host。另外检查插件是否处于启用状态，有些实现默认关闭，需要手动打开开关。
4.3 改了 IP 但服务端行为不变
现象：头部确实注入了伪造 IP，但目标响应和没改一样。原因：服务端校验的不是这个头部，或者校验发生在更底层。比如某些框架只信任来自可信代理的X-Forwarded-For，你从本地直接发，它认为不可信就忽略；还有的直接看 socket 地址，应用层头部完全不参与判断。解决：先确认目标技术栈读哪个头部，用 Repeater 逐个头部试；如果所有头部都无效，基本可以判定是网络层校验，这个插件帮不上忙，得换思路。
4.4 伪造 IP 触发风控或封禁
现象：测试过程中目标开始返回 403、验证码，或者直接断开连接。原因：伪造的 IP 值命中了目标的风控规则，比如填了公网地址被识别为异常来源，或者短时间内大量不同 IP 请求触发频率限制。解决：只用保留地址段做测试，控制请求频率，验证完及时关掉插件。血泪经验是别拿生产环境的目标做高频伪造测试，容易把测试账号甚至出口 IP 搭进去。
4.5 Burp 版本升级后插件失效
现象：换了新版 Burp，原来能用的插件加载报错或功能异常。原因：Burp 扩展 API 在新版本里有变动，老插件调用的接口签名变了。解决：回退到插件适配的 Burp 版本，或者改源码适配新 API。改源码时重点看报错堆栈指向的方法，对照新版 API 文档调整参数类型和返回值。没有后悔药，升级前先在测试环境验证插件兼容性，别在生产测试机上直接升。
5. 进阶：把伪造逻辑做成可复用的验证套路
插件本身不复杂，真正有价值的是把它嵌进一套可复用的验证流程里。我一般的做法是：针对每个有 IP 限制逻辑的目标，先建一个配置快照，记录匹配规则、伪造 IP 值、注入的头部列表，验证通过后存档。下次遇到同类目标，直接套用快照改 Host 就行，省去重新试头部的时间。这个习惯来自一次翻车——当时在一个目标上试了七八种头部组合才找到生效的那个，结果换了个目标全忘了，又从头试一遍。
更进一步，可以把「哪些 IP 值触发了什么响应」做成一张对照表，验证时按表推进，而不是随机填值。比如下面这种记录方式：
| 伪造 IP 值 | 注入头部 | 响应状态 | 响应特征 | 结论 |
|---|---|---|---|---|
| 127.0.0.1 | X-Forwarded-For | 200 | 正常页面 | 本机地址被信任 |
| 10.0.0.8 | X-Forwarded-For | 200 | 正常页面 | 内网段被信任 |
| 203.0.113.5 | X-Forwarded-For | 403 | 拒绝访问 | 公网地址被拦 |
| 10.0.0.8 | X-Real-IP | 403 | 拒绝访问 | 该头部不被读取 |
这张表的作用是把「试」变成「有据可查地试」。填值的时候优先用文档保留段（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8），这些地址不会真的指向外部主机，测试时不会误伤。注入头部按目标技术栈的常见读取顺序排：先X-Forwarded-For，再X-Real-IP，再Client-IP，最后试标准的Forwarded。每换一个头部就重发一次，记录响应，别一次改多个变量，否则出了问题不知道是哪个改动导致的。
还有一个容易被忽略的点：验证完记得把插件关掉或者把规则禁用。有次测试完忘了关，后面正常浏览其他站点时请求全被注入了伪造头部，虽然没造成实际影响，但排查了半天才想起来是插件没关。从那以后我每次结束测试都强制走一遍「关插件、清规则、看 HTTP history 确认无残留注入」的收尾流程，这个习惯帮我省了不少莫名其妙的排查时间。希望帮到你。
本文还有配套的精品资源，点击获取
)
