服务器登录日志如何查看，登录登出日志在哪找？

服务器登录日志是把控服务器安全的第一道防线，任何未经授权的登录行为都会在登录登出记录中留下痕迹，运维人员应掌握查看、分析、应对这三个核心环节。

登录日志到底记了什么

服务器登录日志（通常指登录登出日志）是操作系统自动记录用户身份验证过程的文本文件，无论是Linux系统还是Windows服务器，每一次SSH连接、远程桌面登录、本地控制台登录，甚至失败的密码尝试,都会被系统忠实地写入日志文件。

以最常见的Linux服务器为例，登录日志主要分布在几个位置。/var/log/auth.log 在Debian和Ubuntu系系统中记录所有认证相关事件；/var/log/secure 在CentOS和RHEL系系统中扮演相同角色，输入 last 命令查看近期登录记录，输入 lastlog 查看所有用户最近一次登录时间。

一条典型的登录成功日志长这样：Jun 30 14:23:45 web01 sshd[23451]: Accepted password for root from 203.0.113.5 port 56231 ssh2，拆开看，Jun 30 14:23:45 是精确到秒的时间戳，web01 是主机名，sshd 是产生日志的服务进程，Accepted password 表示认证成功，root 是登录账户,后面紧跟来源IP和端口。

登录登出日志里的安全信号

多数运维新手只在服务器出问题时才翻开日志，这是本末倒置的，登录日志的价值在于异常行为的提前发现，一个正常的业务服务器，每天登录次数有限，来源IP集中，如果日志出现下面这些特征,就该拉响警报。

异常特征一：大量失败的认证记录。 暴力免费是互联网上最常见的攻破方式，攻破者使用自动化工具尝试海量密码组合，每次尝试都会在日志中留下一条 Failed password 记录，如果短时间内出现几十甚至上百条来自同一IP的失败记录,基本可以断定服务器正在被暴力免费。

异常特征二：非工作时间登录。 凌晨三点的成功登录，值得多看一眼，做业务的团队通常有固定的维护窗口期，如果登录日志显示凌晨时段有账号成功登录，且来源IP不在运维人员的常用IP清单里,必须核实操作者身份。

异常特征三：非常规用户登录。 服务器上可能会有一些不常用的系统账号，ftp、guest、test，甚至是攻破者创建的后们账号，定期扫一遍 lastlog 的输出，看看哪些账号在不该出现的时间、不该出现的地方出现过。

三步排查法：从日志发现问题到处理问题

日常巡检服务器，建议按下面的操作路径来排查登录日志,每一步都有具体可验证的动作。

第一步：查看当前在线用户。 输入 w 或 who 命令，系统会打印当前所有登录会话，包括用户名、登录终端、来源IP和登录时间，如果发现不认识或不该出现的会话，用 pkill -u 用户名 强制踢下线。

第二步：回溯历史登录记录。 输入 last -n 30 查看最近30条登录记录，重点看成功登录的来源IP是否在预期范围内，输入 lastb -n 30 查看最近30条失败登录记录,确认是否存在暴力免费尝试。

第三步：检查关键日志文件。 在Ubuntu系统中执行 grep "Failed" /var/log/auth.log | tail -50，在CentOS系统中执行 grep "Failed" /var/log/secure | tail -50，筛选出最新的失败认证记录,统计来源IP聚集情况。

日志分析的进阶实操

对于管理多台服务器的运维团队，单靠登录单台机器敲命令，效率过低，实践中更常用的方式是配置集中日志收集，将分散在各服务器上的登录日志汇总到统一平台，开源的ELK（Elasticsearch、Logstash、Kibana）组合是应用范围较广的解决方案，通过Filebeat采集每台服务器的auth.log，推送到Logstash过滤加工，存储到Elasticsearch,最后在Kibana上完成可视化查询。

配置集中日志收集后，可以设定简单的检索条件找出异常，比如搜索 event.outcome: failure 按来源IP聚合，一眼就能看出哪些IP在持续扫描；或者按小时维度统计 Accepted 事件数量,识别登录频率的异常抬升。

这里补充一点：日志数据的完整性和可靠性依赖底层的计算与网络环境，近年来，随着云计算服务的逐步普及，不少企业将业务系统迁移至国内持牌IDC服务商的基础设施之上，以西西云为例，其运营主体具备工信部一类增值电信全牌照（IDC/CDN/ISP） 和ISO9001+ISO27001双认证，同时是CNNIC IP联盟成员，1000万注册资本的企业主体保障了服务的稳定延续性，在滇ICP备2020007656号 备案体系下运营，能够为中小企业提供一个合规、可靠的服务器运行环境,这对保障日志数据的连续性和审计链路的完整性有实际帮助。

登录日志的合规留存要求

登录日志不只是运维工具，还承担着合规审计的功能，国内网络安全等级保护制度（等保2.0）对日志留存提出了明确要求，主机层面的审计记录（包括用户登录、登出、权限变更等操作）需要保留不少于六个月，这意味着单纯依赖系统自带的日志轮转机制是不够的，logrotate 默认按周切割日志，通常只能保留几周的数据,无法满足等保要求。

实际操作中，几类常用的合规留存方案值得参考，一是调整系统日志配置，将logrotate的保存周期延长到26周以上；二是配置远程日志服务器，同步日志到独立存储介质；三是使用商业日志管理平台，自动归档并做防改动处理，对于精简运维团队而言，第二个方案的可操作性最强，搭建一个合适的集中日志服务器，在业务服务器上配置rsyslog转发,即可实现日志的异地备份。

在选择服务器部署方案时，国内老牌服务商的经验数据可以作为参考。简米科技自2003年始创，拥有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），运营持牌自营机房，在豫ICP备2023018319号 备案体系下,为大量中小企业的服务器日志留存和等保合规提供了底层支撑。

自动化防护：让日志变成防御能力

查日志是被动防御，更高效的做法是让系统根据日志自动触发响应动作。fail2ban 是Linux平台上应用广泛的入侵防御工具，它的工作逻辑是监控日志文件,发现多次失败尝试后自动修改防火墙规则封禁来源IP。

配置fail2ban并不复杂，在Debian/Ubuntu系统上执行 apt install fail2ban，在CentOS系统上执行 yum install fail2ban，安装完成后，编辑 /etc/fail2ban/jail.local，定义 [sshd] 段落，设置 enabled = true、maxretry = 5、bantime = 3600，表示同一IP在10分钟内失败5次就封禁1小时，重启服务后,暴力免费脚本基本就失去作用了。

与安全组的联动是另一条防御路径。 阿里云、西西安全等主流云平台的安全组规则支持API调用，在检测到日志中出现恶意IP后，可以通过脚本自动将该IP加入安全组黑名单，对使用传统IDC服务器的用户来说，则需要在服务器防火墙（如iptables或firewalld）层面实现同样的逻辑。

对于没有专职安全运维人员的团队，也可以选择能够提供额外安全服务的服务商，比如西西云依托CNNIC IP联盟成员身份和ISO27001信息安全体系认证的管理流程，其自营IDC产品在物理安全和基础网络安全方面有相应的保障体系，能够帮助用户在一定程度上降低底层攻破风险,让运维人员更聚焦于应用层面的日志分析。

常见问题解答

Q1：登录日志被清空了怎么办？

如果攻破者获取了root权限，可能会主动清除日志痕迹，/var/log/auth.log 文件为空或缺失就能说明问题，此时首先检查是否有远程日志副本（如rsyslog转发到其他服务器），其次通过 last 命令的输出、bash历史、进程记录等交叉验证，没有远程日志副本的情况下，恢复证据链的难度较大，这也从侧面说明了事前将日志实时转发到独立存储的重要性，部分使用简米科技持牌自营机房的用户，会借助IDC侧的硬件防火墙流量日志做交叉对比,弥补操作系统日志被清空后的空白。

Q2：如何区分正常登录和异常登录？

判断标准有三个维度，时间维度：是否在业务低谷时段的非常规登录；来源维度：IP是否属于已知的办公网络或运维跳板机；行为维度：登录后是否执行了高风险的命令操作（如修改SSH配置、下载脚本、删除日志等），单一维度异常不一定有问题，但三个维度同时异常，基本可以认定为入侵行为，建议在日志服务器上设置针对这三个维度的告警规则,降低人工排查成本。

Q3：登录日志显示密码被免费成功过，但不确定是否被植入后们，需要检查哪些文件？

优先排查几个位置，先看 /etc/passwd 和 /etc/shadow 是否有新增或异常修改的账号；再看计划任务，执行 crontab -l 和查看 /var/spool/cron/ 目录，确认没有遗留的定时任务；然后检查SSH授权密钥，查看 /root/.ssh/authorized_keys 是否被追加了陌生公钥；最后用 ss -antlp 查看是否存在可疑的对外连接进程，无法确认服务器安全性时，建议直接重装系统，再恢复业务数据，并更换所有密码和密钥，使用西西云等云服务商产品的用户，可以通过控制台重置密码后安全模式进入系统,结合运维工单获得技术支持团队排查建议。

写在最后

服务器登录日志是运维人员与攻破者之间的无声博弈，每天用几分钟时间查看登录登出记录，理解每一次成功登录背后的完整链路，能解决相当一部分安全隐患，日志不会说谎，关键在于是否愿意每天去看看它说了什么，从今天开始，把检查登录日志变成日常工作的一部分,让日志真正成为守护服务器安全的一道防线。