被攻击后如何统计请求频率找可疑IP,网站被攻击如何查找攻击源

被攻击后,统计请求频率是找出可疑目标地址最直接的手段,通过分析Web服务器访问日志,提取每个源IP的请求次数并排序,高频IP往往就是攻击源或跳板节点。

网站被攻击怎么查找攻击源IP?先确认日志记录是否完整

很多运维在服务器被打时第一反应是重启或封IP,但如果你连攻击源IP都还没定位,后续操作基本是盲猜,要统计请求频率,前提是访问日志还保留着,先花两分钟确认日志文件是否在、有没有被轮转覆盖。

网站有CDN也没关系,一招教你获取网站真实IP
加载中
网站有CDN也没关系,一招教你获取网站真实IP
  • Nginx默认日志路径:/var/log/nginx/access.log
  • Apache默认日志路径:/var/log/httpd/access_log或/var/log/apache2/access.log
  • 宝塔面板站点日志:/www/wwwlogs/你的域名.log
  • 如果使用CDN,源站日志记录的是回源IP,攻击源IP需要看CDN控制台的请求分析

快速查看日志尾部是否还在更新,用tail -f /var/log/nginx/access.log,如果日志文件大小异常暴增,说明攻击正在进行,此时统计频率更紧迫,如果日志被关闭或已经轮转,后文会提到实时抓包兜底方案。

nginx统计请求频率找出攻击IP的完整步骤

以Nginx默认的combined日志格式为例,每一行大概长这样:

0.113.50 - - [21/Feb/2026:14:32:10 +0800] "GET /login HTTP/1.1" 200 1024 "-" "Mozilla/5.0"

第一列0.113.50就是源IP,我们要做的,就是统计这一列在所有日志中出现的次数。

提取源IP字段

最简单的命令是先用head看几行日志,确认第一列确实是IP,没有被反向代理改写:

head -5 /var/log/nginx/access.log

如果前面还有代理层,比如Nginx前面挂了HAProxy或CDN,需要确认$remote_addr是不是真实客户端IP,多数默认配置下,$remote_addr就是连接源IP,如果日志第一列是内网IP,说明流量经过上一层代理,攻击源IP在上一层设备的日志里。

统计每个IP的请求次数并排序

核心命令如下:

被攻击后如何统计请求频率找可疑IP,网站被攻击如何查找攻击源

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

这条命令拆开看:

  • awk '{print $1}':只取每行第一个字段,也就是源IP
  • sort:把IP先排序,让相同IP挨在一起
  • uniq -c:统计每段连续相同IP的数量
  • sort -nr:按数量从大到小倒序排列
  • head -20:只输出前20个

输出样例:

  87341 203.0.113.50
  12006 198.51.100.23
   4387 192.0.2.77
   1023 203.0.113.88

第一个IP在日志窗口内请求了8万多次,而正常用户通常只有几次到几十次,这种量级的请求频率,基本可以判断为攻击源或恶意爬虫。

按时间段缩小排查范围

如果日志文件很大,全量统计会消耗较长时间,可以先按攻击开始的时间段过滤,比如攻击集中在下午两点到三点:

grep "21/Feb/2026:14:" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20

grep匹配日志中的时间戳字段,只保留那一小时的数据再统计,这样能更快定位攻击发起时间,也能观察攻击是否分阶段换IP。

Linux下统计IP访问频率命令对比:选对方法事半功倍

除了awk+sort+uniq这套基础组合,Linux下还有几类工具适合不同场景,以下是三种常见方式的对比。

awk加sort加uniq组合

  • 优点:所有Linux发行版都自带,不用安装任何软件,适合日志分析和临时排查
  • 缺点:日志量达到几十GB时,排序过程较慢,需要几分钟到十几分钟
  • 适用场景:事后分析已经存在的日志文件

goaccess实时分析工具

安装命令:

# CentOS/RHEL
yum install goaccess -y
# Debian/Ubuntu
apt install goaccess -y

运行:

goaccess /var/log/nginx/access.log --log-format=COMBINED

它会生成一个交互式终端面板,直观展示访问者IP、请求数、状态码分布,也可以生成HTML报告,适合快速观测请求频率分布,但不能像awk那样直接定制字段组合。

被攻击后如何统计请求频率找可疑IP,网站被攻击如何查找攻击源

ngxtop实时监控

安装:

pip install ngxtop

运行:

ngxtop -l /var/log/nginx/access.log

它会以类似top的形式实时刷新,默认展示访问最频繁的IP和请求路径,适合攻击正在发生时边看边判断,但需要Python环境,部分生产服务器可能没有。

工具 安装难度 实时性 定制统计字段 适合场景
awk+sort+uniq 无 否 高 事后分析
goaccess 低 准实时 低 快速生成报告
ngxtop 中 是 中 实时观测攻击源

三种方法并不冲突,可以先上ngxtop观察实时异常IP,再用awk精确统计时间窗口内的请求次数,确认攻击源地址。

确认可疑目标地址后的处理建议

统计出高频IP后,先别急着封禁,行业共识认为,单纯请求频率高不代表一定是恶意攻击,有可能是正常的大流量客户端或CDN回源节点,需要结合几个维度交叉验证。

结合请求路径、User-Agent和状态码判断

  • 高频IP反复请求同一个登录接口,且状态码多为401或200,可能是撞库或暴力破解
  • 高频IP请求路径散乱,大量返回404或499,可能是目录扫描或CC攻击
  • 高频IP的User-Agent异常统一,比如全是同一种旧版浏览器或空UA,多为脚本攻击
  • 高频IP来自多个邻近网段,可能是僵尸网络的一部分

据OWASP公开资料,暴力破解和CC攻击在日志上都会表现为单一IP短时间内的请求频率异常升高,但行为模式有明显差异,暴力破解集中在认证接口,CC攻击通常模拟正常请求路径但密集发起。

临时封禁与长期防护

临时封禁可以用iptables或firewalld:

被攻击后如何统计请求频率找可疑IP,网站被攻击如何查找攻击源

# iptables封禁单个IP iptables -I INPUT -s 203.0.113.50 -j DROP # firewalld封禁单个IP firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.50" drop' firewall-cmd --reload

也可以在Nginx层封禁:

location / {
    deny 203.0.113.50;
    deny 198.51.100.23;
}

如果攻击流量已经打满服务器带宽,单机封禁作用有限,这时候才会考虑接入高防IP或CDN,不过买之前建议先了解高防IP价格对比,不同服务商的基础防护套餐价格差异不小,而且很多是按防护峰值和带宽计费,类似北京服务器被攻击排查这类需求,机房可能自带基础流量清洗,但自己先完成频率统计,能避免把正常用户IP误封掉。

被攻击后统计请求频率常见问题答疑

网站被攻击怎么查找攻击源IP更准确?

先按请求频率筛选Top 20 IP,再结合请求路径、User-Agent、状态码和IP归属地综合判断,不要只因为请求量大就认定是攻击源,高频访问可能来自CDN节点、搜索引擎蜘蛛或企业出口IP,用whois命令或在线IP库查一下归属,确认不是关键基础设施后再处理。

没有开启访问日志还能统计请求频率吗?

可以,如果Nginx没有配置access_log,可以临时在站点配置中增加以下行,然后nginx -s reload:

access_log /var/log/nginx/emergency_access.log;

之后新的请求会被记录,如果连配置都来不及改,可以用tcpdump抓取流量,再用awk统计源IP出现次数,这种方式非常紧急,但性能开销较大,只适合定位最活跃的几个攻击IP,不能作为长期手段。

统计出的可疑IP能否直接批量封禁?

不建议直接全封,应该先排除CDN回源IP段和搜索引擎蜘蛛IP,确认攻击源后再批量处理,业内专家指出,误封CDN节点会造成全站不可访问,误封搜索引擎蜘蛛会影响收录,批量封禁时用脚本读取IP列表逐条加入防火墙规则,同时保留一份白名单以备随时解封。

首发原创文章,作者:王坚‌,如若转载,请注明出处:https://idctop.com/article/654331.html

赞 (0)
遇到攻击先查哪些日志能快速定位问题,网站被攻击怎么查日志?
上一篇 2026年9月15日 09:02
我的世界ec服务器4d装扮怎么穿戴,4d装扮穿戴方法
下一篇 2026年9月15日 09:05

相关推荐

  • 业务侧防护中防火墙与入侵检测如何联动,有哪些注意事项?

    防火墙与入侵检测联动,核心答案就一句话:让防火墙负责“拦截”,入侵检测负责“发现”,二者通过消息接口或安全管理平台协同,在攻击发生的瞬间完成封堵动作, 这句话是业务侧防护的底层逻辑,也是2026年等保2.0和实战攻防演练中反复验证过的有效路径,防火墙与入侵检测为什么必须联手各自单干时,业务侧防护漏洞在哪防火墙是……

    AI展现优化 2026年9月9日
    300
  • GEO优化获客成本比投流低多少?SEO优化与投流哪个更划算

    GEO优化获客成本通常比传统投流低30%-50%,且长期复利效应显著,适合追求稳定线索质量的B2B及高客单价行业,很多老板还在纠结是继续砸钱买流量,还是转投内容SEO,2026年的搜索生态已经变了,用户不再盲目点击广告,而是更倾向于信任经过验证的内容,GEO(生成式引擎优化)正是顺应这一趋势的新玩法,它不仅仅是……

    2026年7月10日
    7000
  • 大带宽服务器突发带宽会算入计费峰值吗,带宽峰值怎么计费

    大带宽服务器的突发带宽是否计入计费峰值,关键看计费规则:如果服务商采用95计费,突发峰值超过每月5%采样时间就会计入账单;如果采用固定带宽计费,突发不会单独计费,但会被端口上限硬性限速,大带宽服务器突发带宽是否计入95计费峰值95计费是目前大带宽服务器最常用的流量计费模式,它不按实际使用流量的平均值收费,而是取……

    2026年9月14日
    200
  • 宁波大带宽服务器如何配合外贸单据高峰?,哪家好?

    宁波大带宽服务器通过高带宽独享和低延迟本地网络,配合负载均衡与CDN调度,能完全承接外贸单据高峰期的流量压力,保证单据传输稳定不丢包,外贸单据高峰为何需要大带宽服务器外贸单据处理涉及大量邮件附件、ERP系统交互、报关文件上传下载,这些操作在年底或节假日会集中爆发,普通带宽在此时极易被占满,导致邮件发送超时、ER……

    2026年8月12日
    800
  • 切换高防策略前为何先小流量验证再放量,高防策略怎么测试?

    高防策略切换必须遵循“先在低风险小流量环境完成灰度验证,再逐步放量”的避险原则,这是一切高防接入动作的底层前提,任何脱离小流量验证的全面切换,本质上都等同于让核心业务裸奔进未知战场,高防切换为什么必须走“小流量验证”这条路很多业务方在遭遇DDoS攻击时,第一反应是从机房临时拉一条高防线路,恨不得全量IP一秒切完……

    2026年9月14日
    200
  • 带货直播高并发播放如何选CDN高防组合?,高防CDN哪家好

    带货直播高并发播放的CDN高防组合,核心答案只有一句话:用高防CDN做边缘分发与抗D清洗,配合直播源站的多级回源与智能调度,才能同时解决高并发卡顿和流量攻击两大问题,直播带货的玩法这两年大家看得多了,但技术侧的压力越来越大,头部主播开播瞬间几万人挤进同一个直播间,弹幕、点赞、下单请求同时爆发,这时候播放端如果出……

    2026年9月8日
    300
  • 阈值设太严误报多怎么平衡松紧度,如何调节阈值参数?

    把告警门槛从“一刀切的绝对值”改成“带基线参照的动态值”,让触发条件跟着业务时段和流量习惯走,误报率会明显下降,而真正的问题也不会被漏掉,这套思路在安全运营场景里天天都在上演,你问任何一个负责告警规则调优的安全工程师,他都会告诉你,把阈值调严到某个程度以后,误报不只是“多几条无关消息”而已,而是整个值班体系开始……

    2026年9月6日
    500
  • 简米科技GEO优化最新案例有哪些?,效果如何?

    GEO优化不是可选项,而是2026年企业数字营销的必答题,简米科技近期的服务案例证明,即便在竞争激烈的行业,通过精准的GEO策略也能让品牌在百度AI搜索中占据优先位置,什么是GEO优化?它与传统SEO区别在哪GEO(生成式引擎优化)是针对百度文心一言、Google SGE等AI搜索的新兴优化手段,传统SEO面向……

    2026年7月20日
    1200
  • 跨境直播推流的虚拟专用服务器怎么配置?,选哪家好?

    选择靠近目标观众区域的VPS机房,带宽至少5Mbps上行,CPU不低于2核,系统优先选Linux,再配合成熟的RTMP推流协议即可稳定开播,2026年的跨境直播行业,VPS配置不再是单纯堆参数的问题,机房位置、网络线路质量、推流软件兼容性之间的协同,才是决定画面流畅度的关键,跨境直播推流VPS买香港还是美国选择……

    2026年9月16日
    300
  • 边缘节点预热覆盖率如何监控与补刷,边缘节点预热失败怎么办?

    在CDN边缘节点做预热覆盖率监控,核心动作就一句话:先拿“应覆盖节点数”和“实际命中节点数”做对比,再按区域、运营商、URL参数把缺口拆出来,最后用定向预热任务精准补刷,而不是全量重复刷一遍,预热覆盖率为什么在边缘节点容易产生缺口很多人把预热理解成“提交一次任务,所有边缘节点都会去源站拉文件”,实际情况不是这样……

    2026年9月12日
    100

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注