• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

公网扫描、攻击打在公网IP上,会增加防火墙负担吗?

  • 0关注
  • 0收藏,72浏览
粉丝:0人 关注:4人

问题描述:

如果我有一个公网IP,此公网IP部署在防火墙的接口上。

1. 防火墙untrust禁止访问trust。

2. 不开通公网访问防火墙https等页面。

3. 开启tcp等攻击防范功能。

此时公网的扫描、攻击,防火墙如何处理数据包、扫描、攻击数据包会上传CPU吗?

大量的扫描、攻击在防火墙开启对应的攻击后,会对防火墙产生负担吗?

5 个回答
已采纳
粉丝:11人 关注:9人

1. 数据包处理流程:公网扫描/攻击数据包到达防火墙untrust接口后,首先匹配接口入方向安全策略(当前untrust→trust禁止,且未开放管理页面),若策略拒绝则直接丢弃;若触发攻击防范规则(如tcp syn flood、端口扫描检测),则由攻击防范模块处理(如丢弃、限速)。
2. CPU占用情况:未触发攻击防范的普通扫描包(如tcp syn探测),若被安全策略直接拒绝,通常由硬件转发平面快速处理,CPU占用极低;触发攻击防范的数据包(如大量syn flood),需CPU参与攻击检测与处置(如统计连接数、执行限速),会占用一定CPU资源。
3. 防火墙负担影响:开启攻击防范后,大量攻击会增加CPU负担(攻击检测、日志记录等操作消耗资源),若攻击流量超过防火墙性能阈值,可能导致CPU使用率过高,影响正常业务转发。需根据防火墙型号(如F1000-E、F5000系列)的性能参数评估承载能力,必要时调整攻击防范策略(如优化检测阈值、开启硬件加速防护)。
关键命令参考:
查看攻击防范配置:display anti-attack configuration
查看CPU使用率:display cpu-usage
查看攻击日志:display logbuffer | include attack

粉丝:8人 关注:46人

不会。做好安全策略限制。不允许untrust 访问loacl就可以

粉丝:208人 关注:0人

您好,参考

  • 纯 TCP 端口扫描、SYN 攻击:绝大多数数据包硬件直接丢弃,仅少量首包上 CPU 统计
  • 仅开启基础攻击防范、不开 IPS:海量扫描对防火墙 CPU 负担极小,不影响正常业务转发;
  • 开启 IPS 七层检测时,漏洞类扫描会持续消耗 CPU,高并发下会造成设备性能瓶颈;
  • 你当前三条基线(禁止 untrust 到内网、关闭公网管理、开启基础防攻击)已经阻断攻击对内网的渗透,同时天然减少大量流量上送 CPU 的场景;
  • 最大可控开销来源是安全策略 deny 规则的日志打印,关闭后可进一步降低 CPU 占用。
  • 数据包硬件直接丢弃,说明对防火墙硬件性能也是有要求的,对吧。如果大量的扫描、攻击,类似DDOS攻击,那防火墙硬件丢弃,也会出现问题?

    Winter_luo 发表时间:15小时前 更多>>

    数据包硬件直接丢弃,说明对防火墙硬件性能也是有要求的,对吧。如果大量的扫描、攻击,类似DDOS攻击,那防火墙硬件丢弃,也会出现问题?

    Winter_luo 发表时间:15小时前
    粉丝:0人 关注:0人

    2. 不开通公网访问防火墙https等页面。包括你对外nat的服务啊。你没开启服务就不会。有服务如果被人家扫到一直攻击肯定会增加设备负担的。

    粉丝:19人 关注:2人

    一、先明确你的组网基础条件
    Untrust→Trust 默认全拦截,无放行业务;
    防火墙自身 Web/SSH/HTTPS 管理端口对公网关闭;
    已开启 TCP 泛洪、扫描防范、SYN 防护、ICMP 限速等攻击防御。
    二、公网扫描、攻击报文,防火墙完整处理流程
    所有从 Untrust 入方向到达防火墙的报文,全部会先经过硬件转发芯片 + 安全引擎两级处理,流程分层:
    1. 第一层:接口硬件快速过滤(ASIC 芯片,不占用 CPU)
    防火墙入接口硬件会优先处理:
    非法畸形报文、超大分片、校验和错误包:硬件直接丢弃,不上送 CPU;
    配置了 ACL 黑名单、端口阻断规则的扫描端口探测包:硬件快速丢弃。
    这一层是无性能损耗的,海量扫描包在此直接拦截。
    2. 第二层:全局攻击防范模块(部分报文会上送 CPU)
    开启TCP 攻击防范、扫描防范、SYN Flood 防护后,设备需要做会话统计、速率统计、源 IP 行为检测:
    扫描行为检测(端口扫描、全连接扫描)
    防火墙需要记录每个公网源 IP 的访问端口数量、连接新建速率、发包频率,判断是否为扫描源;
    这种五元组行为统计逻辑无法完全硬件卸载,少量报文会上送主控 CPU 做计数。
    SYN Flood、ICMP 泛洪、UDP 泛洪防护
    半连接表、ICMP 速率阈值、单 IP 发包限速:会话 / 计数器由 CPU 维护,海量攻击流量下,CPU 需要持续更新、判断阈值、生成黑名单封禁。
    异常 TCP 报文校验(空标志位、FIN+URG、异常分片 TCP)
    复杂 TCP 标志组合校验,硬件无法全部识别,必须上送 CPU 深度解析。
    3. 第三层:域间策略校验(你的场景几乎无开销)
    你配置untrust禁止访问trust:
    所有目的为内网 Trust 网段的报文,匹配域间 deny 策略,硬件直接丢弃,不会新建会话、不会占用 CPU;
    只有目的地址是防火墙自身公网接口 IP的报文,才会进入设备本地服务校验(你已关闭 HTTPS/SSH 管理,此类报文极少)。
    4. 第四层:IPS/Web 特征库(按需开销)
    如果你同时开启 IPS、Web 防护、病毒过滤:
    扫描流量里的 HTTP 探测、漏洞 POC、恶意请求会交给 IPS 引擎深度匹配,这是 CPU 消耗大户;仅开基础攻击防范、不开 IPS,负担会大幅降低。
    三、核心问题:大量扫描 / 攻击会不会增加防火墙负担?
    结论:一定会增加 CPU、内存负担,但分轻重两种场景
    场景 1:低强度日常公网扫描(互联网常态)
    零散端口扫描、弱探测包:
    CPU 占用小幅上涨(通常涨幅 5%~15%),设备无卡顿、无丢包;
    内存仅占用少量黑名单表项,不影响业务转发;
    设备设计时预留了对应处理余量,日常扫描无业务风险。
    场景 2:高强度、持续海量扫描 / 泛洪攻击(上万 PPS 探测包)
    负担会明显放大,存在三类资源消耗:
    CPU 开销暴涨
    海量源 IP 的端口计数、速率统计、黑名单封禁动作持续占用主控 CPU;
    若同步开启 IPS 深度检测,CPU 极易冲高至 70% 以上,严重时正常业务转发延迟、丢包。
    连接表 / 黑名单内存占用
    扫描会生成大量临时封禁黑名单、半连接会话表,占用设备内存;极端泛洪下会话表打满,正常合法连接无法新建。
    接口硬件转发资源占用
    大量无效报文占用接口带宽、硬件查表资源,挤压正常业务报文的转发队列。
    关键区分:
    即使所有攻击包最终都会被防火墙丢弃,“识别、判断、封禁” 这个防御动作本身,是消耗设备性能的;防御功能不是 “零成本”,攻击流量越大,防御逻辑的资源开销越高。
    四、为什么关闭内网访问、关闭设备管理,能减轻一部分负担?
    untrust→trust 全 deny:内网业务相关报文直接硬件丢弃,不会创建正向会话,省去会话维护开销;
    关闭防火墙公网管理端口:针对防火墙本机 IP 的暴力破解、管理端口扫描报文直接拦截,不需要处理设备本地服务认证逻辑;
    但针对公网 IP 端口的外部扫描(仅探测端口,不访问内网、不访问设备管理),该产生的 CPU 开销依然会产生,只能减少一部分,无法完全消除。
    五、减轻扫描 / 攻击性能损耗的优化配置(H3C 防火墙实操)
    1. 强化硬件层快速拦截,减少上送 CPU 报文
    plaintext
    # 开启畸形报文硬件快速丢弃
    anti-attack abnormal-packet drop enable
    # 单源IP ICMP限速,拦截ICMP扫描
    anti-attack icmp rate-limit source 10
    # SYN半连接限制,抵御端口扫描
    anti-attack syn-flood source-limit 50
    # 全局端口扫描防范,自动拉黑扫描源,缩短CPU统计周期
    anti-attack scan-detect enable
    anti-attack scan-detect blacklist duration 300

    2. 缩小 IPS 检测范围,只给业务流量开启深度防护
    不要对全部 Untrust 流量做 IPS 检测,只放行的业务端口绑定 IPS 策略,扫描探测流量不进 IPS 引擎:
    plaintext
    security-policy
    rule 10 permit destination 内网业务服务器
    application all
    ips apply policy 防护策略
    rule 100 deny

    3. 缩短扫描黑名单封禁时间、限制黑名单最大条目
    避免海量恶意 IP 长期占用内存:
    plaintext
    anti-attack scan-detect blacklist max-number 1000

    4. 接口入方向 ACL 预拦截高危端口
    在 Untrust 接口 inbound 配置 ACL,直接硬件丢弃常见扫描高危端口,不进入攻击检测模块:
    plaintext
    acl number 4000
    rule deny tcp destination-port eq 22
    rule deny tcp destination-port eq 3389
    rule deny tcp destination-port eq 3306
    interface GigabitEthernet 0/0
    packet-filter 4000 inbound

    六、补充总结
    公网扫描 / 攻击数据包不会完全不消耗性能,防御识别逻辑需要 CPU、内存资源;
    仅开启基础 TCP 攻击防范,开销偏低;叠加 IPS、应用识别后,性能损耗显著提升;
    禁止外网访问内网、关闭设备公网管理,只能降低一部分负载,无法消除外部端口扫描带来的检测开销;
    海量持续扫描 / 泛洪攻击,会推高 CPU 占用,极端场景影响正常业务转发,需通过接口 ACL、攻击限速、黑名单优化缓解。

    编辑答案

    你正在编辑答案

    如果你要对问题或其他回答进行点评或询问,请使用评论功能。

    分享扩散:

    提出建议

      +

    亲~登录后才可以操作哦!

    确定

    亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

    注册后可访问此模块

    跳转hclhub

    你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作

    举报

    ×

    侵犯我的权益 >
    对根叔社区有害的内容 >
    辱骂、歧视、挑衅等(不友善)

    侵犯我的权益

    ×

    泄露了我的隐私 >
    侵犯了我企业的权益 >
    抄袭了我的内容 >
    诽谤我 >
    辱骂、歧视、挑衅等(不友善)
    骚扰我

    泄露了我的隐私

    ×

    您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
    • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
    • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

    侵犯了我企业的权益

    ×

    您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
    • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
    • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
    • 3. 是哪家企业?(营业执照,单位登记证明等证件)
    • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
    我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

    抄袭了我的内容

    ×

    原文链接或出处

    诽谤我

    ×

    您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
    • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
    • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
    我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

    对根叔社区有害的内容

    ×

    垃圾广告信息
    色情、暴力、血腥等违反法律法规的内容
    政治敏感
    不规范转载 >
    辱骂、歧视、挑衅等(不友善)
    骚扰我
    诱导投票

    不规范转载

    ×

    举报说明