1. 项目概述为什么/var/log/secure是你的安全前哨如果你在管理一台暴露在公网的Linux服务器那么每天最让你提心吊胆的恐怕就是那些来自全球各地、永不停歇的SSH登录尝试。它们像潮水一样涌来试图用弱密码、默认账户或者已知漏洞敲开你的大门。作为一线运维我处理过无数次安全告警也复盘过几次真实的入侵事件。一个深刻的体会是绝大多数成功的攻击在初期都会在系统日志中留下蛛丝马迹而/var/log/secure在基于RHEL/CentOS/Fedora的系统上或/var/log/auth.log在Debian/Ubuntu系统上就是这场攻防战最核心的“黑匣子”。这个日志文件专门记录了所有与系统认证和授权相关的事件尤其是SSH登录、sudo提权、su切换用户等关键操作。它不像/var/log/messages那样包罗万象也不像/var/log/syslog那样需要过滤它的内容高度聚焦于“谁在什么时候从哪里用什么方式尝试登录了哪个账户结果是成功还是失败”。对于安全分析来说这种聚焦性就是最大的价值。通过实时监控和定期审计这个文件你可以在攻击者真正得手之前就发现异常模式比如来自陌生地理位置的登录、短时间内高频的失败尝试、非工作时间的登录活动或者针对特定高权限账户的暴力破解。很多新手管理员可能会依赖一些现成的入侵检测系统IDS或安全信息与事件管理SIEM工具这当然很好。但工具可能会误报、漏报或者因为配置不当而失效。掌握手动分析/var/log/secure的技能就像是拥有了一个永不失效的“最后一道防线”。你能理解每一条日志背后的故事能快速判断一个登录尝试是同事的误操作还是攻击者的探测这种基于第一手日志的直觉和判断力是任何自动化工具都无法完全替代的。接下来我就带你深入这个文件看看如何像侦探一样从中快速定位异常并理解那些常见的错误信息到底在告诉你什么。2. 核心日志结构解析读懂每一行警报在开始搜索异常之前我们必须先成为日志的“母语者”。/var/log/secure中的每一行都不是乱码而是一个结构清晰的句子由时间戳、主机名、服务进程、日志级别和具体消息构成。理解这个结构是你进行高效筛选和分析的基础。2.1 一条标准登录日志的解剖我们来看一条最常见的SSH登录成功日志May 15 10:23:17 server-01 sshd[12345]: Accepted password for user01 from 192.168.1.100 port 54322 ssh2让我们拆解它May 15 10:23:17: 事件发生的本地系统时间。这是所有时间相关分析如非工作时间登录的起点。server-01: 产生这条日志的主机名。在集中式日志分析中这个字段至关重要。sshd[12345]: 产生日志的进程名sshd即SSH守护进程及其进程IDPID。PID可以帮助你追踪单次会话的完整生命周期比如从连接到断开。Accepted password: 这是日志的关键动作和状态。Accepted表示登录尝试被接受成功。password表示使用的认证方式是密码。这里还可能看到publickey密钥认证。for user01: 被登录的目标用户名。这是你关注的核心实体之一。你需要清楚服务器上哪些是有效用户哪些是默认的、应被禁用的用户如root,admin,test。from 192.168.1.100 port 54322:源IP地址和源端口。这是定位攻击源的黄金信息。IP地址可以用于地理定位、查询威胁情报是否是已知的恶意IP。源端口是客户端随机打开的通常分析价值小于IP。ssh2: 使用的SSH协议版本。再看一条失败日志May 15 10:23:18 server-01 sshd[12346]: Failed password for invalid user admin from 203.0.113.5 port 37344 ssh2这条信息量更大Failed password: 动作状态是Failed认证方式是password。这直接表明了一次失败的密码尝试。for invalid user admin: 关键短语invalid user说明系统上根本不存在名为“admin”的用户。攻击者常常用常见用户名root, admin, test, oracle, ftp等进行撞库。看到大量针对无效用户的失败尝试通常是自动化扫描工具的特征。2.2 关键字段的提取与过滤思路基于以上结构我们的分析思路就清晰了。我们不会漫无目的地通读日志而是用grep,awk,cut等文本处理工具像数据库查询一样按字段进行过滤和统计。按状态过滤这是最粗粒度的筛选。# 查看所有失败的登录尝试 grep \Failed password\ /var/log/secure # 查看所有成功的登录需特别关注 grep \Accepted\ /var/log/secure # 查看针对不存在用户的尝试恶意扫描强信号 grep \invalid user\ /var/log/secure按IP地址聚合找出“最活跃”的IP无论是攻击者还是正常用户。# 统计所有失败日志中每个源IP出现的次数并按次数降序排列 grep \Failed password\ /var/log/secure | awk \{print $11}\ | sort | uniq -c | sort -nr # 解释$11是默认情况下IP地址所在的字段位置。使用awk更精确的方法是匹配“from”后面的IP。 # 更稳健的写法 grep \Failed password\ /var/log/secure | grep -oE \from [0-9]{1,3}(\\.[0-9]{1,3}){3}\ | awk \{print $2}\ | sort | uniq -c | sort -nr输出结果类似1245 203.0.113.5 32 198.51.100.20 1 192.168.1.100一眼就能看出203.0.113.5在疯狂尝试。按用户名聚合找出被“重点照顾”的用户账户。# 统计哪些用户名被尝试失败最多 grep \Failed password\ /var/log/secure | awk \{print $9}\ | sort | uniq -c | sort -nr # 注意字段位置可能因日志格式微调而变化上述命令是常见情况。按时间范围查询调查特定时间段的活动。# 查看今天5月15日的日志 grep \May 15\ /var/log/secure # 使用journalctlSystemd系统更灵活 journalctl _SYSTEMD_UNITsshd.service --since \2024-05-15 00:00:00\ --until \2024-05-15 23:59:59\注意日志字段的位置如$9,$11可能因发行版、SSH版本或/etc/ssh/sshd_config中LogLevel的设置而略有不同。最可靠的方法是先看几行样本确定IP和用户名的位置。使用grep -oE配合正则表达式提取关键信息比依赖固定列数更健壮。3. 实战四步定位法揪出异常登录理论说再多不如一次实战。下面我分享一个我日常使用的、层层递进的四步分析法可以系统性地从海量日志中筛选出真正的威胁。3.1 第一步快速态势感知——谁在狂轰滥炸首先我们需要一个全局视图。登录服务器后我会立即执行以下命令对最近的失败登录进行聚合分析比如查看过去24小时# 组合命令提取过去24小时secure日志筛选失败密码统计IP频次 sudo grep \$(date -d \24 hours ago\ \%b %_d\)\ /var/log/secure | grep \Failed password\ | awk \{print $11}\ | sort | uniq -c | sort -nr | head -20这个命令做了几件事date -d \24 hours ago\ \%b %_d\生成24小时前的月份和日期如May 14用于过滤时间。grep先按时间过滤再筛选“Failed password”行。awk \{print $11}\提取IP地址字段请根据你的日志格式调整。sort | uniq -c统计每个IP的出现次数。sort -nr按次数倒序排列。head -20显示最活跃的前20个IP。结果解读如果发现某个IP在短时间内如一小时有数百甚至上千次失败尝试这基本可以判定为暴力破解攻击。这是最普遍、最低级的威胁。如果这个IP来自一个你业务毫不相关的国家或地区可以通过whois或在线IP地理定位工具查询那么恶意可能性极高。实操心得不要一看到高次数IP就立刻封禁。先确认它是否还在持续活动用tail -f /var/log/secure | grep IP实时观察。有时可能是某位同事或自动化脚本配错了密码。如果确认是攻击再采取行动。3.2 第二步深度关联分析——攻击者盯上了谁知道了攻击IP下一步就要看它的攻击目标。我们针对上一步找出的可疑IP例如203.0.113.5进行深度挖掘# 查看该IP所有的登录尝试记录成功和失败 sudo grep \203\\.0\\.113\\.5\ /var/log/secure # 或者更清晰地按时间排序查看 sudo grep \203\\.0\\.113\\.5\ /var/log/secure | sort -k1,2M -k2,3n这条命令会列出该IP的所有相关日志。你需要重点关注攻击目标用户列表它尝试了哪些用户名是常见的root、admin还是你系统上特有的用户名如果出现了你系统的真实用户名尤其是非公开的就需要高度警惕说明攻击者可能通过信息泄露获得了一些情报。攻击时间模式尝试是集中在几分钟内还是持续了数小时甚至数天持续的低频尝试可能更隐蔽。有无成功记录这是最关键的仔细检查输出中是否有Accepted字样。务必逐条确认。攻击者可能已经攻破了一个弱密码账户。常见场景与应对场景AIP只尝试了root、admin、test等无效或已禁用用户且无成功记录。判断这是无目标的自动化扫描威胁等级较低但占用了日志和带宽。行动可以考虑使用fail2ban或iptables/firewalld将该IP拉黑一段时间。场景BIP尝试了多个你系统的真实有效用户名如zhangsan、deploy但密码均失败。判断这是有部分情报的、更具针对性的攻击威胁等级中。行动立即检查这些被尝试的用户账户是否使用了弱密码。强制这些用户修改密码并考虑启用密钥认证禁用密码认证。场景C日志中出现了该IP对某个用户的Accepted成功登录记录判断安全事件可能已经失陷。行动紧急响应流程启动立即禁用该用户账户sudo usermod -L 用户名或sudo passwd -l 用户名。检查该用户的历史命令sudo su - 用户名 -c \history\或查看其家目录下的.bash_history文件。检查该用户最近运行的进程、打开的连接netstat -antp | grep 用户名。审查该用户的crontab、authorized_keys文件是否被篡改。通知所有相关人员并考虑进行更全面的系统安全检查。3.3 第三步成功登录审计——每一个“允许”都需警惕失败日志固然重要但成功的登录记录才是攻击的最终目标也可能是内部人员违规操作的痕迹。定期审计成功登录日志是深度防御的关键。# 统计所有成功登录的记录按用户分组 sudo grep \Accepted\ /var/log/secure | awk \{print $9}\ | sort | uniq -c | sort -nr # 查看root用户的成功登录记录应格外关注 sudo grep \Accepted.*for root\ /var/log/secure # 查看来自非内网IP的成功登录假设内网网段是192.168.0.0/16 sudo grep \Accepted\ /var/log/secure | grep -v \192\\.168\\.[0-9]*\\.[0-9]*\审计要点root登录在规范的运维中应禁止直接以root身份通过SSH登录。所有Accepted password for root或Accepted publickey for root的记录都需要被调查和解释。异常时间登录检查在深夜、周末或节假日发生的成功登录。这可能是攻击者在利用无人值守的时间段活动也可能是内部人员的异常操作。异常地理位置登录如果运维团队都在国内但出现了来自海外IP的成功登录这绝对是红色警报。认证方式关注是password还是publickey。如果某个通常使用密钥登录的用户突然用密码登录成功需要核实是否为本人操作。3.4 第四步线索串联与威胁狩猎单点日志的分析有时会有局限。高级攻击者会使用低频率、慢速扫描或者使用代理、Tor网络来隐藏真实IP。这时我们需要将多个线索串联起来进行“威胁狩猎”。用户行为基线偏离为关键用户如deploy、admin建立行为基线。例如用户deploy通常只在工作时间内从固定的跳板机IP如10.10.10.10登录。如果某天发现deploy在凌晨3点从另一个IP登录即使密码正确、密钥认证成功这也构成了一个异常事件需要人工核实。失败-成功模式寻找“短时间内针对同一用户的大量失败登录紧随其后的一次成功登录”。这种模式极有可能是暴力破解成功的标志。可以用awk或编写Python脚本对日志进行时间序列分析来发现这种模式。关联其他日志/var/log/secure不是孤岛。攻击者登录后其行为会记录在其他日志中。命令历史/home/用户名/.bash_historysudo日志/var/log/secure中同样有sudo:开头的记录记录了谁在什么时候以谁的身份执行了什么命令。系统调用审计如果开启了auditdLinux审计守护进程可以在/var/log/audit/audit.log中看到更细粒度的文件访问、命令执行等记录。Web日志如果服务器是Web服务器攻击者可能利用Web漏洞获取了shell其访问痕迹在/var/log/nginx/access.log或/var/log/apache2/access.log中。核心技巧将上述四步分析过程脚本化。你可以编写一个Shell脚本或Python脚本定期如每天运行自动生成一份安全日志摘要报告内容包括TOP 10攻击IP、被尝试最多的用户、异常的成功登录事件等。通过邮件或即时通讯工具发送给管理员实现主动预警。4. 常见错误日志深度解析与应对策略/var/log/secure里的错误信息五花八门但常见的就那么几类。理解它们背后的原因能帮你快速排除故障或确认攻击。4.1 认证失败类错误这是日志中最常见的部分但细分之下含义不同。Failed password for invalid user username from IP含义最典型的扫描特征。攻击者尝试了一个系统中不存在的用户名。原因自动化工具在撞常见用户名字典。应对威胁性较低但需监控此类日志的量。如果量巨大可以考虑用fail2ban设置针对“invalid user”的规则进行封禁。Failed password for valid_username from IP含义针对有效用户的密码尝试失败。原因攻击暴力破解或密码喷洒攻击。误操作用户自己输错了密码。应对这是需要重点关注的日志。如果同一用户短时间内连续失败如5分钟内5次应立即告警。应强制该用户使用强密码并建议启用双因素认证或切换到密钥登录。Connection closed by authenticating user username IP [preauth]含义客户端在认证完成前主动断开了连接。[preauth]表示在预认证阶段。原因攻击者在扫描时可能发送了畸形的数据包或主动取消。客户端网络不稳定。服务器负载过高响应慢。应对单独出现无需紧张。但如果来自同一IP的大量此类日志伴随Failed password出现则是扫描工具的特征。4.2 连接与配置类错误这类错误通常指向服务器配置或网络问题。Did not receive identification string from IP含义客户端连接到SSH端口通常是22但没有发送正确的SSH协议标识字符串就断开了。原因非常常见的互联网背景噪音。可能是端口扫描工具如nmap、僵尸网络探测甚至是其他误配置的服务尝试连接。应对通常无害。可以通过修改SSH端口为非标准端口如2222来大幅减少此类干扰。Invalid user username from IP注意这条日志可能不伴随Failed password。这意味着客户端尝试用了一个无效用户名但连接在密码提示前就因其他原因如连接断开结束了。其安全含义与Failed password for invalid user类似。User username not allowed because shell shell_path does not exist含义用户存在但其在/etc/passwd中指定的登录shell不存在。原因管理员可能为了禁止某个用户登录将其shell修改为/bin/false或/usr/sbin/nologin但如果这些shell路径写错或对应的程序被误删就会产生此错误。也可能是在创建用户时指定了错误的shell。应对这是一个配置错误需要管理员修复。使用usermod -s /bin/bash username或usermod -s /sbin/nologin username来修正。Authentication refused: bad ownership or modes for directory path含义SSH密钥认证失败因为用户家目录或~/.ssh目录的权限设置过于开放不安全。原因SSH对密钥文件及其父目录的权限有严格规定如~/.ssh目录应为700authorized_keys文件应为600。权限过宽如组或其他用户有写权限会导致SSH出于安全考虑拒绝认证。应对登录服务器修正权限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod go-w ~ /home/username # 确保家目录其他用户无写权限4.3 密钥认证相关错误在禁用密码、只允许密钥登录的环境中这类错误很关键。Failed publickey for username from IP含义公钥认证失败。原因客户端提供的私钥与服务器上authorized_keys中存储的公钥不匹配。authorized_keys文件格式错误或权限问题见上一条。服务器上该用户的.ssh目录权限问题。应对检查客户端使用的私钥是否正确检查服务器上对应用户的.ssh目录和authorized_keys文件的权限与内容。Connection closed by IP [preauth](在密钥交换后)含义可能在密钥交换完成后客户端因没有合适的密钥或认证方法而主动断开。原因服务器配置为只接受密钥认证PasswordAuthentication no但客户端没有提供有效的密钥或尝试使用密码。应对对于合法用户指导其正确配置密钥。对于未知IP这通常是无密钥扫描器的行为。5. 自动化监控与防御加固实战手动分析是基础但无法7x24小时持续。将分析工作自动化并基于分析结果进行防御加固才是构建安全运维体系的关键。5.1 使用Fail2ban实现自动封禁Fail2ban是一个经典的日志分析工具它监控日志文件如/var/log/secure当发现符合恶意行为模式如短时间内多次密码失败的IP时会自动调用防火墙规则如iptables或firewalld将其封禁一段时间。安装与基础配置# 在RHEL/CentOS上 sudo yum install epel-release -y sudo yum install fail2ban -y # 在Debian/Ubuntu上 sudo apt update sudo apt install fail2ban -y # 启动并设置开机自启 sudo systemctl enable --now fail2ban关键配置Fail2ban的配置位于/etc/fail2ban/。通常我们不直接修改jail.conf而是创建覆写文件jail.local。sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo vi /etc/fail2ban/jail.local找到[sshd]段落或类似段落进行如下关键设置[sshd] enabled true port ssh # 关键指定你的日志文件路径Ubuntu/Debian是auth.log logpath /var/log/secure # 触发封禁的阈值在10分钟内最多5次失败尝试 maxretry 5 findtime 600 # 封禁时间1小时 bantime 3600 # 使用的封禁动作一般用firewalld或iptables banaction firewallcmd-ipset保存后重启服务sudo systemctl restart fail2ban。检查状态# 查看所有被监控的服务的状态 sudo fail2ban-client status # 查看sshd监狱的详细状态包括当前被禁IP列表 sudo fail2ban-client status sshd实操心得maxretry和bantime需要根据你的环境调整。对于面向公网的服务可以设置得严格一些如maxretry3, bantime86400封禁一天。对于内网环境可以宽松一些避免误封同事。务必先在一个非关键环境测试规则确保不会把自己锁在外面。5.2 进阶使用Logwatch或自定义脚本进行日报Logwatch是一个日志分析和报告生成工具可以定期如每天将系统日志的摘要发送到管理员邮箱。安装与配置sudo yum install logwatch -y # RHEL/CentOS sudo apt install logwatch -y # Debian/Ubuntu默认配置通常已足够。你可以通过/usr/share/logwatch/default.conf/logwatch.conf或/etc/logwatch/conf/下的文件进行定制比如设置报告详细级别和收件人。更灵活的方式是编写自己的Shell脚本。下面是一个简单的示例用于生成每日安全日志摘要#!/bin/bash # daily_ssh_report.sh REPORT_FILE/tmp/ssh_report_$(date %Y%m%d).txt LOG_FILE/var/log/secure YESTERDAY$(date -d \yesterday\ %b %_d) echo \ 每日SSH安全报告 $(date) \ $REPORT_FILE echo \\ $REPORT_FILE echo \【1】昨日TOP 10攻击源IP失败登录:\ $REPORT_FILE grep \$YESTERDAY\ $LOG_FILE | grep \Failed password\ | grep -oE from [0-9]{1,3}(\\.[0-9]{1,3}){3} | awk {print $2} | sort | uniq -c | sort -nr | head -10 $REPORT_FILE echo \\ $REPORT_FILE echo \【2】昨日被尝试最多的用户名:\ $REPORT_FILE grep \$YESTERDAY\ $LOG_FILE | grep \Failed password\ | awk {print $9} | sort | uniq -c | sort -nr | head -10 $REPORT_FILE echo \\ $REPORT_FILE echo \【3】昨日所有成功登录记录:\ $REPORT_FILE grep \$YESTERDAY\ $LOG_FILE | grep \Accepted\ $REPORT_FILE echo \\ $REPORT_FILE echo \【4】昨日异常事件无效用户登录:\ $REPORT_FILE grep \$YESTERDAY\ $LOG_FILE | grep \invalid user\ | tail -20 $REPORT_FILE # 可以通过mail命令发送报告例如 # mail -s \Daily SSH Security Report for $(hostname)\ adminyourdomain.com $REPORT_FILE # 或者使用sendmail等 cat $REPORT_FILE # 本地输出将这个脚本加入crontab每天定时运行一次你就能获得一份自动化的安全简报。5.3 系统级安全加固建议日志分析是“检测”而加固是“预防”。结合日志分析中发现的问题你应该实施以下加固措施修改SSH默认端口将/etc/ssh/sshd_config中的Port 22改为一个非标准的高位端口如Port 23456。这能过滤掉90%以上的自动化扫描。改完后重启sshd服务并务必确保新端口在防火墙中已放行。禁止root直接登录在/etc/ssh/sshd_config中设置PermitRootLogin no。管理员应通过普通用户登录再用sudo提权。使用密钥认证禁用密码认证这是最有效的防暴力破解方法。为每个用户配置SSH密钥对然后在sshd_config中设置PasswordAuthentication no和PubkeyAuthentication yes。使用强密码策略如果必须使用密码确保启用强密码策略pam_pwquality模块设置最小长度、复杂度要求。限制用户和IP使用AllowUsers或AllowGroups限制允许登录的用户。更进一步可以使用TCP Wrappers/etc/hosts.allow和/etc/hosts.deny或防火墙规则只允许特定的管理IP段访问SSH端口。保持系统和软件更新定期运行yum update或apt upgrade及时修补SSH服务及其依赖库的漏洞。启用PAM模块失败延迟编辑/etc/pam.d/sshd或/etc/pam.d/system-auth在auth部分添加auth required pam_faildelay.so delay4000000延迟4秒可以显著增加暴力破解的时间成本。日志分析不是一次性的任务而是一个持续的过程。将手动分析的洞察力与自动化工具的效率结合起来不断根据新的威胁调整你的监控规则和防御策略才能为你的Linux服务器构建起一道动态、有效的安全防线。从今天起养成每天花5分钟看一眼/var/log/secure的习惯它可能会在关键时刻给你最宝贵的预警。
