什么是Imperva Incapsula?
无抓取抓取浏览器为从动态公共页面进行授权提取提供管理的浏览器会话。
Imperva Incapsula是与Imperva的云基础应用保护和交付服务相关的历史名称,现在通常被称为Imperva云WAF。该服务位于受保护应用程序之前,并对传入流量应用安全控制。它的历史包括网络应用防火墙保护、机器人控制、DDoS缓解和内容交付功能。
对于遇到Imperva品牌响应的开发者,关键问题是哪个层产生了它。防火墙拒绝、浏览器挑战、上游问题和缓存响应具有不同的含义。任何一项都不应仅从解析器中缺少的字段推断。
Incapsula与Imperva云WAF的关系
Incapsula是在Imperva云应用安全历史中较旧的产品名称。当前的研究应包括 Imperva云WAF产品系列 而不是假设旧的Incapsula教程描述今天的界面或功能。
历史命名可以保留在集成说明、服务标识符或旧文档中。在诊断真实系统时保留这些标识符,但要与所有者确认部署的产品和配置。遗留标签并不证明某个功能不受支持,或者每个当前功能在原始服务中都可用。
避免将所有Imperva产品视为可互换。该公司的应用安全产品具有不同的部署模型。本文关注与Incapsula相关的云保护上下文,而不是Imperva产品组合中的每个产品。
请求路径中的反向代理位置
云应用保护服务可以在源应用程序之前接收访问者的请求,并决定如何处理该请求。这个中介位置解释了为什么边缘和源观察可能会有所不同。
一般的 HTTP中介模型 区分网关与源服务器。如果安全层在转发之前拒绝请求,则源的正常应用日志可能不包含相应的业务操作。如果请求到达源并且源失败,中介可能返回一个上游错误。
对于站点所有者,关联边缘事件、源请求和应用结果。对于访问者,保留您实际收到的响应,避免在没有证据的情况下声称源是健康或不健康的。品牌错误页面标识交付路径的一部分,不一定是根本原因。
永远不要通过寻找隐藏的源来规避其控制,去调查受保护的网站。如果您拥有该应用程序,请使用您批准的内部可观察性和管理渠道。如果您不拥有它,请要求操作员审查受影响的请求。
WAF、机器人控制、DDoS保护和缓存
应用交付可以结合多种目标重叠但不相同的功能。将它们分开有助于您选择对事件的正确响应。
| 功能 | 主要角色 | 诊断问题 |
|---|---|---|
| Web应用防火墙 | 对应用请求应用安全策略。 | 哪个请求属性或规则导致了该操作? |
| 机器人管理 | 评估和管理自动化流量。 | 自动化是被允许的吗,哪个策略处理了它? |
| DDoS保护 | 帮助在攻击流量下保持服务可用性。 | 可用性事件是否影响合法请求? |
| 内容交付和缓存 | 通过中介提供内容并重用符合条件的响应。 | 返回的表示是否最新和适当? |
| 源应用程序 | 生成业务内容并强制执行应用访问。 | 请求的操作是否到达应用并获得权限? |
该 HTTP缓存规范 定义何时可以重用存储的响应。缓存表示和安全拒绝表示是不同的东西。不要将每个意外页面视为机器人挑战,尤其是当问题可能是陈旧或依赖上下文的内容时。
该 OWASP自动威胁框架 也区分不同类型的应用滥用。这在解释机器人控制时很重要:公开只读收集工作和自动账户攻击即使都使用软件客户端也可能需要不同的策略。
Imperva响应能告诉您什么和不能告诉您什么
Imperva品牌响应可以帮助识别涉及的交付或保护服务,但它本身并不能揭示确切的规则或完整的部署。在归因原因之前对消息进行分类。
阅读响应状态、页面标题、可见解释及任何参考标识符。拒绝应记录为拒绝。超时应记录为定时失败。如果预期的页面到达但字段缺失,请在打开安全事件之前检查应用程序状态和标记。
如果供应商识别对您的团队很重要,请在内部诊断中保持单独的归因置信区间字段。“由所有者配置确认”比“由页面品牌建议”更强。这可以防止表面响应线索在后续报告中变成不支持的架构主张。
作为一个说明性示例,公共目录可能返回具有不同地区选择的正确页面。数据不匹配属于页面上下文。明确拒绝请求的响应属于访问处理。这两者看起来都可能对提取器错误,但它们的纠正措施不同。
公共数据收集器的故障排除工作流程
公共数据收集器应首先验证资源和返回的内容,然后确定故障是否在其授权控制范围内。受管客户端并不赋予收集器更改目标安全政策的权力。
- 确认确切的公共路线、请求方法和预期字段。
- 在解析之前检查最终URL、内容类型和可见响应。
- 识别明确拒绝、速率限制或上游故障消息。
- 检查是否需要允许的浏览器步骤或区域选择。
- 保持请求量在商定范围内,并检查所有相关作业。
- 将业主控制的安全决策升级,附上编辑过的证据包。
不要将被拒绝的页面保存为有效的空结果。如果收集器无法观察到公共列表,请将观察记录为不可用。空列表应表示有效页面中没有匹配记录,而不是安全层阻止访问。
将浏览器和网络更改与假设关联。如果页面需要JavaScript,浏览器可以提供所需的执行环境。如果响应是政策拒绝,改变呈现行为可能无法解决。证据应决定下一步行动。
网站所有者在政策更改后应验证什么
网站所有者在更改云WAF规则后,应共同验证合法访问、应用程序正确性和持续保护。如果变更打开了不相关的敏感路线,则恢复一名访客的访问是不够的。
从受影响的请求及其匹配事件开始。确定政策是否反映预期的应用合同。如果规则过于宽泛,则缩小其条件或建立一个明确范围内的批准集成,而不是在整个服务中禁用过滤。
分别检查缓存和动态路线。公共静态页面可能容易验证,而搜索或账户路线则具有不同的状态和授权要求。使用代表性旅程并确认应用程序结果,而不仅仅是错误屏幕的消失。
记录先前的规则、新范围、变更原因和回滚路径。对任何例外情况保持明确的所有权。没有所有者累积的安全规则在应用程序或其用户变更时变得难以评估。
无抓取和浏览器执行层
无抓取抓取浏览器 为授权的公共页面工作流程提供受管的浏览器执行。它可以提供动态内容所需的运行时,同时将访问决策留给目标。
使用 无抓取抓取浏览器文档 了解支持的浏览器功能。在验证中保持请求页面的身份、市场和所需字段明确。 云代理解释 提供有关中介路由的相关上下文,这应与应用程序权限和浏览器呈现保持独立。
围绕站点允许的工作负载和您的实际新鲜需求策划收集量。查看 无抓取定价 以了解计划的基础设施方面。更大的浏览器分配并不会扩大网站的授权或流量允许。
如果数据要求无法通过允许的公共路线满足,请寻求批准的导出或合作伙伴接口。让下游消费者看到这个差距,而不是用猜测的值填充它或反复将拒绝视为解析问题。
结论
Imperva Incapsula属于Imperva云应用保护服务的历史。了解反向代理的位置有助于区分安全决策、来源故障和内容交付行为。收集器应对返回页面进行分类并尊重访问边界;所有者应关联事件并进行狭义的政策修正。
将浏览器执行与访问政策分开
使用无抓取处理允许的公共页面工作流,并将安全结果与正常数据记录分开。
今天就注册并获得 5美元免费信用 — 无需信用卡.
索取您的5美元信用 →常见问题
Incapsula与Imperva Cloud WAF是同一个名字吗?
Incapsula是与Imperva的云应用保护服务相关的历史名称,而当前材料通常使用Imperva Cloud WAF。在应用任何旧教程的设置之前,请确认实际部署的产品。
每个Imperva错误意味着机器人检测吗?
Imperva品牌的错误并不总是意味着机器人检测。响应可能涉及应用程序安全政策、上游故障或其他交付功能。在分配原因之前,请阅读消息并关联请求与所有者侧事件。
当访问者被阻止时,源可以正常工作吗?
一个源可以在前端安全层拒绝选定请求的同时工作。拒绝可能发生在正常应用处理之前。所有者应检查边缘事件以及源日志,而访问者应报告他们实际收到的响应。
抓取者应该直接尝试访问源吗?
抓取者不应寻求未受保护的源以规避网站的安全控制。请使用经过批准的公共接口或明确的访问安排。网站所有者可以通过其授权的内部管理和可观察性渠道进行调查。