LOGO 首页 OA教程 ERP教程 模切知识交流 PMS教程 CRM教程 技术文档 其他文档  
 
网站管理员

你的服务端做好被攻击的防护了吗?

admin
2026年10月21日 0:42 本文热度 190

安全防护日志分析生产实战

日志里发现别人在扫我的接口

你每天看着监控面板岁月静好,却不知道互联网上有多少扫描器在对着你的服务器敲门。

01事情的起因:一条奇怪的登录日志 THE BEGINNING

事情发生在上周的一个普通工作日下午。当时我正在排查一个用户登录异常的问题,然后习惯性地去翻了翻登录日志,结果翻到了一条让我后背发凉的记录。

026-09-02 14:32:11.456  WARN  LoginController : 登录失败    username=admin, ip=185.220.101.34, userAgent=Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)2026-09-02 14:32:11.458  WARN  LoginController : 登录失败    username=root, ip=185.220.101.34, userAgent=Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)2026-09-02 14:32:11.460  WARN  LoginController : 登录失败    username=test, ip=185.220.101.34, userAgent=Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)2026-09-02 14:32:11.462  WARN  LoginController : 登录失败    username=oracle, ip=185.220.101.34, userAgent=Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)

同一秒内,同一个IP,连续尝试了4个账号,而且userAgent里明晃晃地写着Nmap Scripting Engine。这不是用户输错密码,这是有人在用扫描工具探测我的服务器。

⚠️被攻击不是概率问题,是时间问题

这一刻我才意识到:不是只有大公司才会被攻击。只要你的服务暴露在公网上,就一定会被扫描器盯上。区别只是你发没发现。

02发现攻击:日志里的不速之客 DISCOVERY

发现那条日志之后,我没有慌,而是先把服务器上所有相关日志都拉出来,做了一次全面的排查。排查的思路是:先搞清楚攻击者已经干了什么,再决定怎么处理。

第一步:确认攻击范围

我用日志统计了一下这个IP在最近24小时内的所有访问记录,结果吓了我一跳。

# 统计某个 IP 24 小时内的访问次数grep "185.220.101.34" access.log | wc -l# 结果:12843# 统计访问了哪些路径grep "185.220.101.34" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20# 结果:/login、/admin、/api/user、/wp-login.php、/.env、/actuator、/api/swagger-ui.html...

看到这个路径列表,我基本确认了:这是典型的自动化扫描行为。攻击者遍历常见的管理后台路径、配置文件路径、敏感接口路径,试图找到可以利用的入口。

第二步:确认攻击时间线

我按时间统计了一下这个IP的访问频率,发现攻击是从前一天晚上23点开始的,一开始只是零星探测,后半夜频率突然升高,到凌晨4点左右达到高峰,然后又慢慢降下来。

这个时间规律非常典型——攻击者选择在业务低峰期扫描,因为这个时候流量小,不容易被发现,而且就算服务被搞挂了,影响面也小。

📌 核心观点 ,描器是全自动运行的,它们24小时不间断地在互联网上找目标。你不需要做错什么,只要你的端口开着、服务暴露着,就一定会被扫到。被扫到不可怕,可怕的是扫到了漏洞而你不知道。

03分析攻击行为:他们在干什么 ANALYSIS

确认了有人在扫描之后,我开始系统地分析攻击行为。我拉了最近一周的所有异常日志,按类型做了分类统计。

​

▲ 攻击类型分布:暴力破解最多,扫描探测次之

统计结果一目了然,主要攻击行为有四类:

攻击类型
特征
占比
目的
暴力破解
同一IP高频尝试登录账号
42%
猜弱密码,尝试进入后台
扫描探测
遍历常见路径、端口、文件
31%
寻找可利用的漏洞入口
注入尝试
请求参数携带特殊字符
18%
测试是否存在注入漏洞
异常爬虫
高频抓取页面、接口数据
9%
爬取业务数据,或消耗资源

这四类攻击基本覆盖了互联网上90%的自动化攻击行为。它们大多不是针对你来的,而是针对所有暴露在公网上的服务来的——扫描器跑一遍全网IP,谁有漏洞就打谁。

▲ 攻击特征的四个识别维度:异常频率、陌生IP、可疑路径、畸形请求

识别攻击的四个信号

经过这次排查,我总结出识别攻击的四个信号,供大家参考:

信号一:异常频率。同一个IP在短时间内大量请求,频率远超正常人操作。比如1秒内尝试多个账号登录、1分钟内请求几百次。

信号二:陌生IP来源。攻击IP大多来自国外数据中心,或者代理服务器。正常用户的IP分布有规律,攻击IP往往分布分散、来源可疑。

信号三:可疑路径。请求的路径包含常见的敏感路径,比如admin、env、actuator、swagger-ui、wp-login等。正常用户不会访问这些路径。

信号四:畸形请求。请求参数里携带特殊字符,比如单引号、分号、SQL关键字、脚本代码等,这是注入攻击的典型特征。

ℹ️识别攻击靠日志,不靠直觉

识别攻击不靠直觉,靠日志和监控。只要你的日志记录得够全(IP、时间、路径、参数、UA、响应码),攻击行为就一定会留下痕迹。日志是你的第一道防线。

04应急处置:先阻断再说 RESPONSE

分析清楚攻击行为之后,接下来是应急处置。我的原则是:先止损,再追责,最后加固。

▲ 攻击事件处置流程:扫描→爆破→高峰→阻断→加固

第一步:立即封禁攻击IP

发现攻击后,第一件事就是把攻击IP加进防火墙黑名单。我用的是云安全组 + 服务器防火墙双保险:

# 服务器防火墙封禁 IPsudo iptables -A INPUT -s 185.220.101.34 -j DROP# 持久化规则(防止重启失效)sudo service iptables save# 查看已封禁的 IPsudo iptables -L INPUT -n | grep DROP

同时,我在云控制台的安全组里也加了规则,把这个IP段整体封掉。双保险确保即使服务器重启,封禁也不会失效。

第二步:修改所有弱密码和密钥

考虑到攻击者可能在暴力破解登录账号,我立刻检查了所有服务的账号密码,把弱密码全部改掉。包括:

• 服务器SSH登录密码,改用密钥登录并禁用密码登录
• 数据库账号密码,全部换成32位随机字符串
• Redis、MySQL等中间件,确认没有暴露在公网
• 各种管理后台的默认密码,全部重置

这一步很关键。暴力破解的原理就是猜弱密码,只要密码够强,暴力破解就没有意义。

第三步:拉黑攻击者用过的路径

攻击者扫描过的敏感路径,我在Nginx层面全部做了拦截,返回403:

# Nginx 拦截敏感路径location ~ ^/(admin|\.env|actuator|swagger-ui|wp-login|\.git) {    deny all;        return 403;}# 同时限制管理后台的访问 IP(改为你的办公室出口 IP)location /admin {    allow 192.168.1.100;       # 仅允许内网访问        deny all; }

第四步:开启全站告警

最后,我配置了告警规则:登录失败超过5次、单个IP每分钟请求超过100次、访问敏感路径等行为,全部触发告警,第一时间通知到手机。这样即使有新的攻击,我也能第一时间发现。

用新字段的版本,分两步走。

🚨 应急处置的核心是快

应急处置的核心是快。攻击者在暗处,你在明处,你每慢一分钟,他就多一分钟的机会。所以日常就要把应急预案准备好:封禁命令、告警规则、密钥轮换流程,都要提前写好。

05安全加固:亡羊补牢的五个层面 HARDENING

应急处置只是把眼前的攻击挡住了,真正要做的,是系统性地加固,让类似的攻击进不来、进得来也拿不到东西。

▲ 安全防护体系:网络层、应用层、认证层、监控层

第一层:网络层防护

• 只开放必要的端口,其他端口一律关闭
• 管理端口(SSH、数据库、Redis)只允许内网或指定IP访问
• 使用云安全组,按最小权限原则配置入站规则
• 接入Web应用防火墙(WAF),拦截常见攻击流量

第二层:应用层防护

• 所有入参做参数校验,过滤特殊字符,防止注入
• 接口做限流,防止被刷接口、耗尽资源
• 敏感路径做访问控制,未授权访问返回403
• 框架升级到最新版本,修复已知漏洞
• 生产环境关闭调试接口、管理接口、文档接口

第三层:认证层防护

• 强制使用强密码策略,密码长度不少于16位
• 支持多因素认证(MFA),登录二次验证
• 登录失败锁定策略:连续失败5次锁定30分钟
• 登录接口加图形验证码或行为验证,拦截自动化爆破
• 定期轮换密钥和密码,至少每90天一次

第四层:监控层防护

• 登录失败、权限变更、敏感操作全部记录审计日志
• 关键指标(登录失败率、接口错误率、异常流量)配置告警
• 日志集中存储,保留至少6个月,方便事后追溯
• 定期检查日志,主动发现异常行为

06攻击复盘:完整时间线 REVIEW

把整个过程串起来,完整的攻击时间线是这样的:

时间
事件
处置
前一天23:00
攻击者开始扫描端口,探测开放服务
未发现
当天00:30
扫描频率升高,开始遍历常见路径
未发现
当天04:00
攻击高峰,尝试暴力破解登录账号
未发现(业务低峰期)
当天14:32
排查问题时发现异常登录日志
确认攻击行为
当天14:40
封禁攻击IP,双保险阻断
攻击流量被阻断
当天15:00
修改所有弱密码,轮换密钥
消除弱密码风险
当天15:30
Nginx拦截敏感路径
阻止后续扫描
当天16:00
配置全站告警规则
异常行为实时通知
后续一周
持续观察,未再发现异常
攻击未再发生

复盘之后我发现,这次攻击从开始到被发现,整整过去了15个小时。如果不是那天恰好去翻日志,可能到现在都不会发现。这暴露了一个严重的问题:我们的安全监控几乎是空白的。

"安全不是有了防火墙就万事大吉,而是你的防护、监控、响应三者缺一不可。防护做得再好,没有监控,攻击进来了你不知道;监控做得再好,没有响应预案,发现了也处理不了。"

—— 复盘反思

08写在最后 WRAP UP

这次被攻击,虽然没有造成实际损失,但给我上了一课:安全不是运维一个人的事,也不是加个防火墙就完事的事,而是每个开发者都要有的意识。

你在写代码的时候,有没有想过:接口有没有做权限校验?参数有没有过滤特殊字符?密码有没有加密存储?密钥有没有写进代码仓库?这些看似小的问题,都可能成为攻击者进入系统的入口。

最后送大家一句话:网络安全的本质不是绝对的安全,而是攻击者的成本远大于收益。让你的系统难攻一点点,攻击者就会去挑别的软柿子。

你没有被攻击过,不代表你安全,只代表攻击者还没发现你。趁还来得及,去检查一下你的服务器日志吧。


阅读原文:原文链接


该文章在 2026/10/21 12:30:31 编辑过
关键字查询
相关文章
正在查询...
点晴ERP是一款针对中小制造业的专业生产管理软件系统,系统成熟度和易用性得到了国内大量中小企业的青睐。
点晴PMS码头管理系统主要针对港口码头集装箱与散货日常运作、调度、堆场、车队、财务费用、相关报表等业务管理,结合码头的业务特点,围绕调度、堆场作业而开发的。集技术的先进性、管理的有效性于一体,是物流码头及其他港口类企业的高效ERP管理信息系统。
点晴WMS仓储管理系统提供了货物产品管理,销售管理,采购管理,仓储管理,仓库管理,保质期管理,货位管理,库位管理,生产管理,WMS管理系统,标签打印,条形码,二维码管理,批号管理软件。
点晴免费OA是一款软件和通用服务都免费,不限功能、不限时间、不限用户的免费OA协同办公管理系统。
Copyright 2010-2026 ClickSun All Rights Reserved  粤ICP备13012886号-9  粤公网安备44030602007207号