1. 项目概述从登录失败的“噪音”中识别攻击信号在Linux系统的日常运维和安全审计中/var/log/secure对于RHEL/CentOS/Fedora等使用systemd-journald和rsyslog的系统或/var/log/auth.log对于Debian/Ubuntu等系统是一个再熟悉不过的文件。它记录了所有与系统认证相关的活动尤其是用户登录、注销、sudo提权等关键事件。对于大多数管理员来说查看这个日志往往是在用户报告“登录不上”的时候匆匆一瞥解决完“密码错误”或“权限问题”就关掉了。然而这个日志文件远不止是一个故障排查工具它更像是一个24小时不间断的“安全雷达”而其中频繁出现的“用户登录失败”记录就是雷达屏幕上最需要被仔细甄别的原始信号点。把这些失败记录简单地视为“用户输错了密码”可能会让你错过正在发生的撞库攻击、暴力破解、甚至是已经成功的权限维持行为。一次失败的登录是噪音十次可能是用户健忘但成百上千次、来自不同IP、针对不同用户名的失败尝试就是清晰可辨的攻击旋律。本次分享我将结合多年一线运维和应急响应的经验带你深入/var/log/secure日志的肌理系统性地讲解如何从海量的登录失败记录中抽丝剥茧构建出一套主动发现安全隐患的分析方法论。这不仅适用于安全工程师对于任何需要维护Linux服务器稳定的运维人员都是一项必须掌握的“生存技能”。2. 日志源解析与核心字段拆解在开始分析之前我们必须像熟悉自己的工具一样理解日志的生成机制和每一行记录所承载的信息。不同的Linux发行版和认证服务如SSH的sshd、系统登录的login、sudo等会产生略有差异的日志格式但核心字段万变不离其宗。2.1 Secure日志的生成与轮转机制/var/log/secure通常由rsyslog或syslog-ng这类系统日志守护进程生成其配置一般位于/etc/rsyslog.conf或/etc/rsyslog.d/目录下其中会有一行类似authpriv.* /var/log/secure的配置表示将认证相关的日志写入该文件。日志轮转则由logrotate管理配置文件通常是/etc/logrotate.d/syslog它决定了日志文件何时切割、压缩和删除旧文件。理解这一点很重要因为在进行时间跨度较长的攻击行为分析时你可能需要检查secure.1、secure.2.gz等历史归档文件。一个典型的SSH登录失败记录在RHEL 8/CentOS 8及更新版本中看起来是这样的Jun 10 14:25:36 server-hostname sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 55678 ssh2而在一些旧系统或不同服务中格式可能是Jun 10 14:25:36 server-hostname sshd[12345]: pam_unix(sshd:auth): authentication failure; logname uid0 euid0 ttyssh ruser rhost192.168.1.100 userroot2.2 关键字段的深度解读每一段日志都不是随意生成的字符串每个字段都是一个重要的调查线索时间戳 (Timestamp)Jun 10 14:25:36。这是攻击行为的时间线起点。分析攻击频率是持续低速扫描还是短时间内爆发式攻击、攻击发生的时间段是否在业务低峰期或深夜对于判断攻击者意图和来源至关重要。主机名 (Hostname)server-hostname。在多服务器环境中它能帮你快速定位受攻击的具体机器。服务与进程ID (Service PID)sshd[12345]。明确指出是SSH服务sshd的某个进程PID 12345记录了该事件。这能帮你区分攻击是针对SSH、FTP、还是本地控制台登录。核心消息 (Message)这是日志的灵魂。我们需要拆解其中的关键词Failed password最经典的密码错误。但需注意后面跟的是for invalid user还是for root。invalid user攻击者尝试了一个系统中不存在的用户名。这是典型的字典攻击或用户名枚举行为。攻击者往往先用一个巨大的用户名列表进行试探根据系统响应是否提示“无效用户”来缩小有效用户名的范围。from ... port ...源IP地址192.168.1.100和源端口55678。IP是追溯攻击源的直接依据但高明的攻击者会使用代理或僵尸网络。源端口是随机的客户端端口一般分析价值小于IP。user在pam_unix格式中这里指明了尝试登录的用户名例如userroot。针对root用户的暴力破解是最常见的。其他变体消息Connection closed by authenticating user ... [preauth]用户在完成认证前主动断开可能是手动取消也可能是攻击脚本在尝试一定次数后的行为。Did not receive identification string from ...通常意味着连接在发送任何认证数据前就异常中断可能是网络扫描工具的行为。POSSIBLE BREAK-IN ATTEMPT!当SSH检测到同一个IP在短时间内有大量失败登录尝试时可能会在日志中标记此警告取决于sshd配置和版本。注意日志的详细程度受/etc/ssh/sshd_config中LogLevel参数的影响。默认的INFO级别通常足够设为VERBOSE或DEBUG会获得更详细的信息但也会显著增加日志量需权衡利弊。3. 手工分析从单条记录到攻击模式识别在拥有自动化工具之前熟练使用Linux自带文本处理命令进行手工分析是每个运维人员的必修课。这不仅能在工具失效时应急更能帮你建立对数据的“直觉”。3.1 基础信息提取与统计首先我们进入正题看看如何从原始日志中快速获取全局视图。1. 查看实时失败登录# 使用tail和grep实时监控失败的登录尝试 sudo tail -f /var/log/secure | grep -i failed\|invalid这个命令能让你在攻击发生时第一时间感知适合在收到告警或进行主动监控时使用。2. 统计失败登录最多的IP地址这是定位攻击源最直接的方法。sudo grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -20grep Failed password筛选出所有密码失败的记录。awk {print $11}提取第11个字段根据你的日志格式这个位置可能是IP地址请先用一条样例日志sudo grep Failed password /var/log/secure | head -1确认位置。sort | uniq -c排序后统计每个IP出现的次数。sort -nr | head -20按次数倒序排列显示前20名。如果日志格式中IP不在第11位或者包含了“invalid user”等情况一个更健壮的提取IP的命令是使用正则表达式sudo grep -oP from \K[0-9]\.[0-9]\.[0-9]\.[0-9] /var/log/secure | sort | uniq -c | sort -nr | head -20-oP参数让grep使用Perl兼容正则表达式\K表示“丢弃之前匹配的内容”只输出IP地址。3. 统计被暴力破解最多的用户名了解攻击者偏好哪些账户。# 针对“Failed password for root”这类格式 sudo grep Failed password for /var/log/secure | awk {print $9} | sort | uniq -c | sort -nr # 针对“invalid user”格式提取尝试的无效用户名 sudo grep invalid user /var/log/secure | awk {print $8} | sort | uniq -c | sort -nr | head -10 # 更通用的方法结合两种情形提取“for”后面的用户名 sudo grep Failed password for /var/log/secure | sed -n s/.*Failed password for \([^ ]*\).*/\1/p | sort | uniq -c | sort -nr3.2 攻击行为模式深度分析简单的统计只能告诉我们“谁”和“多少次”而结合时间、序列和上下文才能还原出“如何”攻击。1. 时间序列分析攻击是持续不断还是间歇性爆发这有助于判断是自动化脚本还是人工攻击。# 提取失败登录的时间小时级别并统计 sudo grep Failed password /var/log/secure | awk {print $3} | cut -d: -f1 | sort | uniq -c这个命令会统计每个小时发生的失败登录次数。如果你发现凌晨2点到5点次数激增那基本可以确定是自动化脚本在作祟。2. 攻击路径还原尝试还原单个IP的攻击剧本。假设我们锁定一个可疑IP203.0.113.5。sudo grep 203.0.113.5 /var/log/secure | head -30仔细查看这个IP的日志序列它是否先尝试了大量invalid user枚举用户然后针对发现的某个有效用户如www-data,deploy进行密集的Failed password攻击这种从“侦察”到“重点突破”的模式非常典型。3. 成功登录后的异常最危险的不是一直失败的攻击而是失败中夹杂着成功。务必检查失败日志时间点前后是否有来自相同或邻近IP的成功登录记录。# 查找某个IP的成功登录 sudo grep 203.0.113.5 /var/log/secure | grep -i accepted\|session opened如果发现一个在疯狂尝试失败后突然成功的记录那极有可能意味着密码已被破解需要立即进行密码重置、会话踢出和彻底排查。4. 关联sudo与其它日志攻击者登录后下一步往往是提权。检查相同时段内该用户是否有异常的sudo命令执行。sudo grep userroot /var/log/secure | grep -i sudo | tail -20或者结合/var/log/messages、/var/log/audit/audit.log如果开启了auditd进行综合分析看是否有异常进程启动、文件访问等。实操心得手工分析时养成“由面到点再由点及面”的习惯。先通过统计命令如uniq -c看整体态势找到最突出的异常点如某个IP或用户然后针对这个点进行深度日志追踪grep IP最后再将这个点的行为放回整个时间线中审视。避免一开始就陷入单条日志的细节里。4. 自动化分析与告警策略构建手工分析适用于事后调查和深度取证但对于日常防护我们必须依靠自动化工具实现实时或准实时的检测与告警。4.1 使用Logwatch/Logcheck进行每日摘要对于小型或个人服务器Logwatch或Logcheck是不错的起点。它们会定期如每天扫描日志将摘要通过邮件发送给管理员。Logwatch配置通常位于/etc/logwatch/conf/。它会汇总包括secure在内的多种日志在邮件中清晰地列出“Failed login attempts”、“Invalid users”等章节并列出排名前几的IP和用户名。安装和配置非常简单yum install logwatch或apt install logwatch适合需要每日健康报告的场景。Logcheck更侧重于报告“异常”而非“摘要”。它通过规则库区分“正常”和“异常”日志只将异常部分报告给管理员可以减少噪音。4.2 使用Fail2ban实现动态防火墙封锁Fail2ban是应对暴力破解的利器。它实时监控日志如/var/log/secure当某个IP在指定时间窗口内失败次数达到阈值时自动调用防火墙iptables, firewalld等规则将其IP临时或永久封禁。一个针对SSH的典型/etc/fail2ban/jail.local配置如下[sshd] enabled true port ssh filter sshd logpath /var/log/secure maxretry 5 findtime 600 bantime 3600 ignoreip 127.0.0.1/8 192.168.1.0/24maxretry 5最大重试次数。findtime 600在600秒10分钟内达到最大重试次数则触发。bantime 3600封禁3600秒1小时。ignoreip忽略的IP段防止误封本地网络。高级技巧可以为不同的服务如[sshd],[apache-auth]设置不同的监狱jail甚至可以配置banaction iptables-multiport来同时封禁多个端口。务必在配置后使用sudo fail2ban-client status sshd来验证其运行状态和当前被封禁的IP列表。4.3 使用ELK/EFK堆栈进行高级分析与可视化对于服务器集群或需要复杂分析、长期存储和漂亮仪表板的场景Elasticsearch, Logstash, Kibana (ELK)或其变体EFK (Fluentd替代Logstash)是工业级标准。日志收集 (Logstash/Fluentd)在每台服务器上部署beats如filebeat负责读取/var/log/secure文件并将日志实时发送到中心的Logstash或Elasticsearch。Logstash可以配置强大的grok过滤器将一行杂乱的日志解析成结构化的JSON字段例如filter { grok { match { message %{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{DATA:program}\[%{POSINT:pid}\]: %{GREEDYDATA:message} } } if [program] sshd { grok { match { message Failed password for (invalid user )?%{USERNAME:auth_user} from %{IP:source_ip} port %{NUMBER:source_port} } } } }这样source_ip、auth_user等就成了可被检索和聚合的独立字段。存储与搜索 (Elasticsearch)接收并索引结构化后的日志数据提供近乎实时的搜索能力。可视化与告警 (Kibana)仪表板创建仪表板可视化展示“近24小时登录失败TOP IP”、“失败用户名分布”、“失败频率时间线”等。告警规则利用Kibana的告警功能或Elasticsearch的Watcher设置规则。例如“当任意IP在5分钟内对同一用户名失败登录超过10次时触发严重告警并发送邮件/Slack通知”。关联分析可以轻松地将secure日志与其他日志如应用日志、网络流量日志进行关联查询发现更复杂的攻击链。4.4 编写自定义脚本实现定制化监控当现有工具不完全满足需求时一个简单的Shell或Python脚本往往是最灵活的解决方案。例如你可以编写一个每5分钟运行一次的cron job#!/bin/bash # check_ssh_brute.sh LOG_FILE/var/log/secure THRESHOLD10 # 10分钟内失败次数阈值 FIND_TIME600 # 秒 # 提取最近10分钟内失败次数超过阈值的IP SUSPICIOUS_IPS$(awk -v threshold$THRESHOLD -v findtime$FIND_TIME # 这里需要根据你的日志时间格式编写时间匹配逻辑示例为简化版 BEGIN { now systime() } { # 提取日志时间和IP假设IP是第11字段 log_time_str $1 $2 $3; # 将log_time_str转换为时间戳这里需要根据实际格式编写转换函数略 # log_epoch convert_to_epoch(log_time_str) ip $11; if (now - log_epoch findtime) { count[ip]; } } END { for (ip in count) { if (count[ip] threshold) { print ip : count[ip]; } } } $LOG_FILE) if [ -n $SUSPICIOUS_IPS ]; then echo 发现可疑暴力破解IP echo $SUSPICIOUS_IPS # 可以在此处添加调用防火墙命令封禁IP或发送告警邮件的逻辑 # /sbin/iptables -A INPUT -s $ip -j DROP # echo $SUSPICIOUS_IPS | mail -s SSH暴力破解告警 adminexample.com fi这个脚本只是一个思路框架实际编写时需要处理复杂的日志时间解析。更推荐使用Python的datetime和re模块来编写逻辑会更清晰健壮。5. 从攻击日志到安全加固的闭环分析日志的终极目的不是为了分析而分析而是为了指导我们进行有效的安全加固形成“监测 - 分析 - 响应 - 加固”的闭环。5.1 即时响应措施当通过分析确认正在遭受攻击或已存在安全隐患时应立即采取以下措施封禁攻击源使用fail2ban即时封禁或手动通过防火墙封禁IPsudo iptables -A INPUT -s 攻击IP -j DROP或sudo firewall-cmd --permanent --add-rich-rulerule family“ipv4” source address“攻击IP” reject。检查受影响账户立即检查被暴力破解的用户账户尤其是root和任何有sudo权限的账户。强制修改强密码sudo passwd 用户名。检查该用户是否有异常进程、登录会话w,who,ps -u 用户名并立即终止可疑会话sudo pkill -u 用户名需谨慎。检查该用户的~/.ssh/authorized_keys文件看是否被添加了未授权的公钥。留存证据将相关时间段的完整secure日志备份以备后续深度取证或法律需要。5.2 中长期安全加固建议基于日志分析中暴露出的薄弱点进行系统性加固SSH服务加固禁止root直接登录修改/etc/ssh/sshd_config设置PermitRootLogin no。这是最有效、最简单的措施之一。改用密钥认证禁用密码登录设置PasswordAuthentication no和PubkeyAuthentication yes。彻底杜绝暴力破解密码的可能。修改默认端口将Port 22改为一个非标准端口如Port 23456。这能减少90%以上的自动化扫描噪音。使用TCP Wrappers或防火墙限制访问源在/etc/hosts.allow和/etc/hosts.deny中限制只允许特定IP段访问SSH或者在防火墙中设置白名单。启用双因子认证 (2FA)对于特别重要的服务器可以为SSH登录配置Google Authenticator等2FA工具。系统层面加固使用强密码策略通过/etc/security/pwquality.conf或/etc/pam.d/system-auth配置密码复杂度、最小长度和定期更换策略。限制用户登录对于仅用于运行服务的系统账户如nginx,mysql使用usermod -s /sbin/nologin 用户名禁止其登录shell。安装并配置入侵检测系统 (IDS)如AIDE文件完整性检查或OSSEC基于主机的IDS它们能监控文件变更、提权行为等与日志分析互补。定期更新系统sudo yum update或sudo apt update sudo apt upgrade及时修补安全漏洞。日志管理强化确保日志服务持续运行定期检查rsyslog/systemd-journald服务状态。配置远程日志服务器将重要服务器的secure日志实时发送到一台独立的、加固的日志服务器使用rsyslog或syslog-ng的远程转发功能。这样即使攻击者攻陷了业务服务器并清除了本地日志攻击证据依然在远端留存。设置合理的日志轮转策略确保有足够的磁盘空间并保留足够长时间的历史日志如30天或90天以满足审计和调查需求。6. 典型攻击场景与排查案例实录理论结合实践下面通过几个我实际遇到过的场景来看看如何将上述分析方法应用起来。6.1 场景一低频慢速暴力破解现象日常Logwatch邮件中偶尔会看到几个不同的IP每天对root用户尝试3-5次失败登录持续数周。单个IP看频率很低未触发Fail2ban阈值设为10次/10分钟。分析手工统计使用grep Failed password for root /var/log/secure* | awk {print $11} | sort | uniq -c | sort -nr发现确实有几十个IP每个尝试次数在10-50次不等但分散在长达一个月的时间里。模式识别这些IP来自全球各地且用户名固定为root。这是典型的“分布式低频暴力破解”旨在绕过基于单IP频率的防御系统。关联分析检查这些IP是否有成功记录。幸运的是没有。响应与加固批量封禁虽然单个IP频率低但集合起来就是明确的攻击。可以将这些IP列表导出一次性添加到防火墙的DROP规则中。调整防御策略仅靠频率阈值不够。可以在Fail2ban中降低maxretry并延长findtime如maxretry3,findtime86400捕捉24小时内的低频尝试。更有效的是启用Fail2ban的recidive累犯监狱。它封禁那些在多个普通监狱中被多次短暂封禁过的IP专门对付这种“打一枪换一个地方”的攻击者。强化认证方式这是根本解决方案。直接禁用root的SSH密码登录甚至对所有用户禁用密码登录强制使用密钥。6.2 场景二成功入侵后的日志清理痕迹现象收到监控系统告警某台服务器的磁盘使用率在短时间内异常下降。检查发现/var/log/secure文件大小变为0且其修改时间非常新。分析这是高危信号正常的日志轮转会生成secure.1,secure.2.gz等文件而不会清空当前文件。直接清空日志是攻击者在获取权限后掩盖行踪的常见手段。立即检查其他日志查看/var/log/messages,/var/log/audit/audit.log如果开启看是否有在secure被清空前后时间的异常记录如大量sudo命令、未知进程启动、网络连接等。检查用户和进程使用last,lastb命令查看登录历史但攻击者可能也清除了/var/log/wtmp使用ps auxf查看异常进程使用netstat -tunap或ss -tunap查看异常网络连接。求助历史备份如果你配置了远程日志服务器立即去远程服务器上查看该时间点前后的secure日志这是还原攻击过程的关键。响应立即隔离如果可能将服务器从网络中断开。取证对磁盘进行只读备份以便后续深入分析。使用rkhunter,chkrootkit等工具扫描 rootkit。恢复从备份中恢复系统或基于最小化可信镜像重建。切勿直接在被入侵的系统上修补后继续使用因为你无法确定攻击者留下了多少后门。复盘加固分析攻击入口很可能是弱密码或未修复的漏洞并实施前述所有加固措施特别是配置远程日志确保日志的不可篡改性。6.3 场景三利用合法用户名的精准爆破现象日志显示大量Failed password记录但没有invalid user记录。攻击者使用的用户名都是系统中真实存在的低权限用户如apache,nginx,ftp等。分析攻击升级这说明攻击者已经完成了“用户枚举”阶段可能通过其他信息泄露途径如网站错误信息、公开的代码仓库等获得了有效的用户名列表。现在的攻击进入了“精准密码爆破”阶段。风险更高这些服务账户通常密码较弱或者甚至设置了默认密码。一旦破解攻击者就获得了一个合法的系统立足点。检查重点立即检查这些被尝试的用户是否设置了弱密码或空密码。使用sudo grep ^用户名: /etc/shadow查看密码哈希字段如果第二字段为!或*表示密码被锁定或未设置如果是空则极其危险。响应与加固立即锁定或禁用这些服务账户的登录权限sudo usermod -s /sbin/nologin apache。审查所有系统账户使用awk -F: ($3 1000) {print $1} /etc/passwd列出所有系统账户检查它们是否真的需要登录shell。加强密码策略确保即使是不常登录的服务账户也有强密码。考虑使用账户登录失败锁定策略通过PAM模块如pam_tally2配置连续失败多次后锁定账户一段时间即使攻击者知道用户名也会大大增加爆破难度。日志分析不是一项一劳永逸的工作而是一个需要持续进行的安全习惯。将/var/log/secure的日常检查纳入你的运维清单结合自动化工具进行监控并基于分析结果不断迭代安全策略才能让你的Linux系统在充满威胁的网络中保持坚固。记住攻击者总是在寻找最薄弱的一环而你的日志就是照亮这些薄弱环节的探照灯。