服务器登录日志全解析：从默认记录到异常排查与安全加固

服务器登录日志全解析：从默认记录到异常排查与安全加固

发布时间：2026/10/5 2:55:16
服务器登录日志全解析：从默认记录到异常排查与安全加固 1. 先给结论服务器不止会记而且记录得比你想象的细先说个真实经历。上周帮一位朋友排查一台CentOS云服务器他说收到一条“登录失败”的短信通知问我要不要紧。我让他把/var/log/secure里那一段拉出来看结果他愣住了不光是那一条失败记录前后还躺着几十条相同来源IP的尝试连时间精确到秒、尝试过的用户名、来源端口、SSH客户端版本号都在。他问“这些东西是谁写进去的我明明没有装任何监控软件啊。”这就是大多数人第一次面对登录日志时的真实反应以为“没装监控 没记录”但实际上操作系统从安装好的第一天起就在默默记录登录行为。这个问题的答案是服务器不仅会记而且默认就会记。你不需要装任何额外软件登录日志一直都在只是你平时没去看而已。1.1 登录日志到底记了什么一次登录事件无论是成功还是失败系统至少会留下这些信息发生登录的时间精确到秒尝试登录的用户名就算这个用户根本不存在也会记来源IP和源端口认证方式密码、公钥、键盘交互等结果是成功还是失败如果成功还会记录建立会话的终端类型、会话开始和结束时间这些信息分散在几种不同的日志里各管一段认证过程日志记录密码校验、公钥比对、PAM模块执行结果比如“Failed password for root from 1.2.3.4 port 22 ssh2”登录状态日志记录一次会话的开始、结束、持续时长对应last和who命令看到的内容审计日志如果配置了auditd可以进一步记录登录后执行了哪些命令、打开了哪些文件这是更细一层的追溯很多新人以为“异常登录”和“日志”是两件事其实是同一件事的两面。所谓异常登录本质上就是日志里出现了你不认识的记录。先把日志这个东西搞清楚后面的判断才有依据。1.2 默认开启吗会不会被管理员偷偷关掉有人会担心是不是有些服务器默认不记录或者被安全策略关掉了以 Linux 为例SSH 服务从编译时就默认接入了 syslog 体系登录信息走的是auth或authpriv设备通道。只要系统里 syslogrsyslog 或 systemd-journald还在运行记录就不会断。CentOS 系的/var/log/secure、Debian/Ubuntu 系的/var/log/auth.log都是这个通道的默认落盘位置。Windows 更直接。安全审计是 Windows 系统的基础组件之一登录成功对应事件ID 4624登录失败对应事件ID 4625。只要你没通过组策略手动关掉相应审计项这些事件默认就会写进安全事件日志。我见过一些 Windows 管理员为了让系统“少写日志”而清掉安全审计策略这种做法相当危险真出事的时候所有证据都没了。所以结论很明确只要系统是正常安装、正常运行的登录日志就是默认存在的。你找不到记录绝大多数情况不是“没有记录”而是不知道去哪看或者时间对不上没搜对地方。2. 日志文件到底藏在哪里Linux、Windows、云平台各自的查法不同系统的日志存放路径天差地别但核心逻辑是一致的都分“认证日志”和“会话日志”两层。下面把三种常见场景分别过一遍。2.1 Linux 上最常用的三件套Linux 上排查登录日志我平时基本只用三组命令# 查看成功登录的历史会话 last # 查看失败登录尝试lastb 需要 root 权限读取 /var/log/btmp lastb # 查看实时的登录会话 who wlast读完的是/var/log/wtmp里面记录的是“哪些用户从哪个IP登录过、登录时长、何时退出”。lastb读取的是/var/log/btmp专门记录失败尝试。注意一点btmp文件不是所有系统默认都预分配的如果文件不存在lastb会报错“No such file or directory”。这个文件的分配通常由 syslog 或 systemd 的 tmpfiles 机制在启动时创建某些精简安装的容器镜像可能没有需要手动touch /var/log/btmp并确认权限。想看更详细的认证过程就得去翻认证日志# Debian/Ubuntu tail -n 200 /var/log/auth.log # CentOS/RHEL tail -n 200 /var/log/secure # 使用 systemd 日志的系统也可以这样查 journalctl -u sshd --since yesterday典型的记录长这样Jan 15 03:12:47 web-server sshd[23854]: Failed password for root from 203.0.113.10 port 51234 ssh2 Jan 15 03:12:48 web-server sshd[23856]: Received disconnect from 203.0.113.10 port 51234:2: too many authentication failures Jan 15 03:12:49 web-server sshd[23858]: Invalid user admin from 203.0.113.10 port 51235这里面每一行字段的含义都很直接时间、主机名、进程名、事件内容。看到Failed password for root说明有人用root账号试密码失败了看到Invalid user admin说明这个叫 admin 的用户根本不存在扫描器在猜用户名。2.2 Windows 服务器看事件IDWindows 的登录日志不在普通文件里而是存放在“安全事件日志”中文件位置是C:\Windows\System32\winevt\Logs\Security.evtx。日常排查不需要直接读文件用事件查看器或者 PowerShell 就够了。需要重点记住的事件ID有这些事件ID含义排查价值4624登录成功记录谁在何时成功登录4625登录失败记录暴力破解或错误密码尝试4648使用显式凭据尝试登录可能涉及提权操作4634 / 4647登出配合4624计算会话时长4776凭据验证成功/失败域控环境下的认证记录用 PowerShell 查也很方便Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625} -MaxEvents 20 | Select-Object TimeCreated, Message | Format-List想只看某个时间段的失败登录可以加StartTime和EndTime参数$start Get-Date 2026-01-01 00:00:00 $end Get-Date 2026-01-01 23:59:59 Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625; StartTime$start; EndTime$end} | Select-Object TimeCreated, MessageWindows 日志里的 4625 事件会带上登录类型2表示本地键盘登录3表示网络登录10表示远程交互登录、源IP、进程名信息量不比 Linux 少。2.3 云平台上的登录记录要分开看如果你用的是云服务器那么除了操作系统日志还要看云平台侧的控制台登录日志和操作审计。这类日志一般记录“谁通过网页控制台登录了这台服务器”“谁重启过实例”“谁修改过安全组规则”。云平台日志和系统日志是互补的而不是互相替代系统日志记录的是操作系统内部的认证行为包括SSH、远程桌面云平台日志记录的是控制台层面的管理操作比如通过网页VNC登录、重置密码、调整配置我见过一个案例有人在云控制台的“远程登录”里输错了密码系统日志没记录但云平台的操作记录里有。反过来SSH暴力破解在系统日志里刷屏云平台侧却可能毫无动静。所以排查的时候两部分都要看只看任何一边都可能漏掉关键信息。另外服务器一旦上了公网被扫描是常态并不等于被入侵。云平台上看到一条失败登录告警先冷静接着去系统日志里核对细节而不是立刻紧张。3. 一眼识别“异常”登录攻击指纹、正常误报、高危信号日志文件摆在那里几千行记录怎么判断哪些才是真正值得关注的“异常”这里分享我自己的工作方法不用什么高大上的工具纯手工也能看出门道。3.1 暴力破解和扫描器的典型指纹凡是互联网上暴露过默认SSH端口22的服务器几乎每天都有人来试密码。这些扫描行为有非常典型的特征基本一眼就能认出来同一IP短时间内大量失败尝试尝试的用户名明显是字典枚举root、admin、test、guest、ubuntu、oracle 等等用户名五花八门包含一堆不存在的用户backup、deploy、mysql、tomcat、minecraft每次连接间隔极短几秒钟就试好几组密码来源IP常常是海外动态宽带IP或IDC机房的IP举个最常见的例子很多扫描机器人专门盯着互联网上的 Minecraft 服务器相关端口或者是拿一批常见用户名去批量试探。你会在日志里看到类似这样的组合Jan 15 04:02:11 web sshd[24001]: Invalid user minecraft from 198.51.100.23 port 60001 Jan 15 04:02:12 web sshd[24002]: Failed password for invalid user mcserver from 198.51.100.23这种就属于典型的自动扫描不代表有人盯上你而是全网无差别攻击的一部分。看到之后不用慌但也不能放任不管后面会讲怎么配置自动封禁。3.2 容易被误判成“异常”的正常登录反过来有些记录看起来像是异常其实完全正常误判了可能把自己吓一跳。最典型的几个场景家里宽带是动态IP今天登录来源是 100.64.x.x明天变成 100.66.x.x这不代表异地登录只是运营商给你换了出口IP。经过跳板机或堡垒机登录团队里多个人通过同一台跳板机连服务器日志里看到的永远是跳板机的IP而不是每个人的真实IP。如果你不记得自己有从那个IP登录过别急着下结论先想想是不是同事或者CI系统在用。UTC时区导致的“半夜登录”很多服务器默认时区是UTC中国时间凌晨3点日志里往往显示的是前一天晚上7点。你看到一条“凌晨登录成功”的记录换算回北京时间可能只是晚上正常操作。自动部署工具和监控探针ansible、salt、consul这类工具会定时连服务器它们在日志里会显示成各种登录成功记录。如果这些账号用的人不多偶尔看一眼觉得陌生其实每天都在规律运行。我自己的经验是判断一条登录是否异常永远要把时区换算、登录方式、业务场景三者放在一起看。单独看“来源IP陌生”很容易误判关键是结合时间段和行为是否规律。3.3 真正需要警惕的高危信号如果出现下面这些情况优先级就要提高了原本从未用公钥登录过的账号突然出现一条公钥登录成功记录同一个账号在极短时间内从两个相距很远的地区登录排除跳板机后基本可以认定凭据泄露日志里出现了你完全不知道的新用户名并且登录成功登录成功之后紧接着有审计日志显示执行了下载、打包、权限切换等敏感命令系统里多了新的 authorized_keys 公钥内容或者 /etc/cron.d/ 下面多了新文件有过一次这样的场景我接到告警后去查last发现一个刚创建不久的系统账号在凌晨成功登录过而这个账号只有当初创建数据库任务时用过。后来查了审计日志发现登录后立刻执行了curl下载脚本基本可以确认被入侵。这种情况就不能再当扫描误报处理了要按应急响应流程走。4. 日志是怎么被写进文件的auth.log 背后的生产流水线很多人看过日志但不知道日志是怎么来的。了解这个机制特别有用因为你会懂得为什么同一个事件会出现两行内容、为什么有些内容查不到、为什么时间戳可能不可信。4.1 sshd、PAM、syslog 三者怎么配合以 Linux 下最常见的情况为例一次 SSH 密码登录大概走这么几步客户端连上服务器的22端口sshd 收到连接请求sshd 调用 PAM可插拔认证模块完成用户名密码校验PAM 把校验结果交给 pam_unix 模块记录到 syslogsshd 自己也会针对登录事件再过一遍日志输出各种日志信息经过 syslogrsyslog 或 systemd-journald分类认证类信息写入auth.log或secure登录成功建立会话后sshd 还会通过系统调用把会话信息写进 wtmp 文件所以你在日志里经常会看到同一个事件的两条记录比如Jan 15 03:12:47 web sshd[23854]: Failed password for root from 203.0.113.10 port 51234 ssh2 Jan 15 03:12:47 web sshd[23854]: pam_unix(sshd:auth): authentication failure; logname uid0 euid0 ttyssh ruser rhost203.0.113.10 userroot这两条都在说同一件事root用户密码验证失败。一条是 sshd 自己输出的一条是 PAM 记录下来的。看到重复内容不用奇怪不是出了两条独立登录事件。4.2 哪些信息会被记录哪些永远不会被记录这是很多人最关心的部分。直接说结论会记录的信息用户名、来源IP、源端口、认证类型、连接时间、断开时间、会话时长、sshd版本和客户端版本、尝试次数。不会记录的信息登录密码本身。密码在校验时要么转成哈希比对要么直接丢弃日志里只保存“校验失败/成功”这个结果不会把明文密码写进文件。如果哪个系统在日志里明文记录密码那是相当严重的安全事故。另外默认情况下登录之后的命令输入也不会被记录。也就是说攻击者成功登录后执行了什么命令光靠 auth.log 是看不出来的必须靠 shell 的历史记录或者auditd审计日志。这就是为什么我经常建议重要的服务器开启 auditd它能记录一条命令是谁在什么时候、从哪个终端、以什么权限执行的。4.3 为什么有些记录会平白无故“消失”有几次排查异常登录时我发现记录对不上窗口期内应该有的记录就是找不到。原因往往是下面几个服务器时间漂移NTP 没配置好服务器时间比真实时间慢了十几个小时按错误时间去搜当然搜不到日志被 logrotate 轮转日志文件被切过了你要找的时间段可能在昨天的压缩包里容器环境日志直接打到 stdout容器一销毁日志跟着丢失连渣都不剩syslog 服务异常rsyslog 进程崩了或者磁盘满了新日志写不进去系统发生过快照回滚虚拟化平台上如果从旧快照恢复恢复之后的所有日志都会被抹掉时间线上的日志会突然断层还有一类比较容易踩坑CentOS 7 这类带 systemd 的系统journald 默认会把日志放内存如果意外断电未落盘的日志直接丢失。所以特别重要的服务器我会在/etc/systemd/journald.conf里把Storage设成persistent并且在 rsyslog 里保证核心日志有落盘。4.4 时间戳怎么才算可信NTP 和时区问题排查登录日志时“时间对不上”是最常见的坑。很多服务器出厂默认是 UTC 时间而业务同事习惯用北京时间。日志里显示凌晨3点其实北京时间是上午11点正常人都会以为“有人半夜登录了”而吓一跳。我的建议是把三件事一次做对# 查看当前时区和时间状态 timedatectl status # 改成中国标准时间 timedatectl set-timezone Asia/Shanghai # 开启并配置 NTP 时间同步 timedatectl set-ntp true如果你想手动指定时间同步源就在/etc/chrony.confCentOS/RHEL 8或者/etc/systemd/timesyncd.confUbuntu里配置上游 NTP 服务器然后重新启动计时服务。时间同步能消除“日志时间和现实对不上”的问题也能避免因为时钟漂移导致的关键日志排错困难。我习惯把所有服务器的时区统一设置成Asia/Shanghai这样不管谁去看日志都不用再做心理换算了。5. 一次异常登录的完整排查链路从收到告警到得出结论看再多理论不如完整走一次排查。下面用我实际排查过一次“凌晨异常登录”的经历来演示具体步骤可以直接迁移到其他服务器上。5.1 第一步先定位可疑记录假设你收到一条告警短信服务器在凌晨2点有过失败登录。第一件事不是立刻断网而是先看日志确认到底发生了什么。# 看最近失败的登录记录 lastb | head -n 50 # 看认证日志里最近的变化 grep Failed password /var/log/auth.log | tail -n 50如果发现大量来自同一个IP的失败尝试先把该IP的所有行为提取出来看grep 203.0.113.10 /var/log/auth.log | tail -n 100上面的操作会把所有包含该IP的日志行全部拉出来包括它尝试过的用户名、成功与否、用了什么认证方式。如果全是Failed那基本就是扫描还没成功不需要过度恐慌。5.2 第二步从“异常时间点”反向找回完整上下文如果告警说的是“某天某时有一笔成功登录”你不能只看那个瞬间得把那个时间点前后一段时间的日志全部捞出来。比如用 journald 指定时间窗口journalctl -u sshd --since 2026-01-15 02:00:00 --until 2026-01-15 02:30:00也可以直接对 auth.log 做筛选awk /2026-01-15 02:/ /var/log/auth.log拿到这段时间窗口的记录后去做三件事确认这个时间点有没有人成功登录了系统看来源IP是什么、用户名是什么查一下这个来源IP是谁家的可以用whois命令查归属也可以直接去IP查询站点确认是住宅网络还是机房地址5.3 第三步检查登录之后有没有“后续动作”如果确认了一次成功登录来自陌生IP那就要关心这个账号登录之后干了什么。这部分的排查重点# 当前在线会话 who # 检查所有用户 awk -F: $31000 {print $1, $3, $7} /etc/passwd # 检查所有用户主目录下的 authorized_keys find /home -name authorized_keys -exec cat {} \; 2/dev/null # 检查新增的定时任务 ls -la /etc/cron.d/ /var/spool/cron/ 2/dev/null # 检查登录成功之后的命令历史前提是 shell 有记录 find /home -name .bash_history -exec tail -n 50 {} \; 2/dev/null重点看三处authorized_keys里有没有不认识的公钥、cron 目录下有没有新增的任务文件、用户列表里有没有不应存在的系统账号。如果这三样里出现不正常的东西那就不再是“登录异常”这么简单而是很可能已经入侵成功。5.4 第四步确认被入侵后先做什么如果判断基本确认被入侵不要急着去“清除后门”优先顺序应该是切断对外服务云服务器先在安全组里关闭相关公网入口防止攻击者继续连进来保留现场在云平台上给实例打快照把 auth 日志、最近的命令历史、进程列表先拷一份出来备用修改凭据重置所有可疑账号的密码删掉不认识的 SSH 公钥重装或恢复对于没有把握彻底清理后门的系统直接重装系统或者用干净快照恢复之后再逐个恢复业务很多人一发现问题就先删日志或者重启服务器反而把证据毁了这个顺序要注意。6. 与其每次吓一跳不如让登录日志变得可管理可报警日志本身只是“记录”真正让日志有价值的是把它们变成主动告警和自动防护。下面是我认为每个服务器都应该做的几项最小配置全部做完也不会超过半小时。6.1 SSH 服务本身的最小加固不管日志怎么记先把 SSH 本身的可攻击面缩小后面告警量会大幅下降。推荐配置在/etc/ssh/sshd_config里PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no MaxAuthTries 3 LoginGraceTime 30这几项的意思依次是禁止root直接密码登录、开启公钥认证、关闭密码认证、限制单次连接最多试3次、超过30秒未完成登录就断开。有人犹豫要不要禁 root 登录我的建议是一定要禁。日常运维用普通用户登录后su -提权攻击者想摸到 root 还要多绕一层日志里也能留下更清晰的痕迹。改完配置后记着sshd -t检查语法再systemctl reload sshd热加载避免把远程连接搞断。这个坑我踩过一次——语法没验证直接重启结果 SSH 全断了还要去控制台走 VNC 救回来。6.2 用 fail2ban 挡住重复攻击日志已经在记录攻击了接下来就让它自动干活。fail2ban会去扫描认证日志发现某个IP在一段时间内失败次数超限就自动在防火墙层封禁它。一个实用配置片段# /etc/fail2ban/jail.local [sshd] enabled true port ssh filter sshd logpath /var/log/auth.log maxretry 5 bantime 3600 findtime 600含义10分钟内同一个IP失败超过5次封禁1小时。CentOS 系统把logpath改成/var/log/secure即可。如果服务器用了非默认端口port需要改成实际端口避免封禁策略没绑定到正确的服务上。安装和启动方式不同发行版略有差异但基本上systemctl enable --now fail2ban就能跑起来。跑起来之后配合日志观察你会发现刷屏的攻击记录迅速变少因为来源IP大量被封了。6.3 日志保留和集中化本地日志最大的问题是服务器一旦被攻破攻击者可以顺手清掉日志。所以更稳妥的方式是把日志同步到另一台服务器或者对象存储上。最简单的方案是给 rsyslog 加一条转发规则例如把认证日志发到远程日志服务器# /etc/rsyslog.d/remote.conf authpriv.* 192.0.2.100:514远程日志服务器需要开放对应的 UDP/TCP 514 端口。如果不想自建日志服务器也可以靠 logrotate 把本机日志保留更久再配合云平台的对象存储定期打包上传。日志文件的保留周期我一般设半年以上毕竟很多安全事件的追溯周期比想象中长。6.4 最小可行的告警脚本不一定非得上一套复杂的 SIEM一个简单的 cron 脚本就够了。比如每天晚上执行一次统计把失败次数超过阈值的IP列出来然后通过 webhook 推到群机器人。一个很粗但能用的思路#!/usr/bin/env bash # /usr/local/bin/check_ssh_failed.sh THRESHOLD30 REPORT$(grep Failed password /var/log/auth.log | grep -oP from \K[0-9.] | sort | uniq -c | sort -nr | awk -v t$THRESHOLD $1 t) if [ -n $REPORT ]; then echo $REPORT | while read count ip; do curl -s -X POST $WEBHOOK_URL \ -H Content-Type: application/json \ -d {\text\:\SSH爆破告警IP ${ip} 登录失败 ${count} 次\} done fi写完之后加到 crontab 里每天凌晨跑一次0 1 * * * /usr/local/bin/check_ssh_failed.sh这套方案简单、透明、不依赖任何商业产品而且每次执行都是在读日志不会给系统带来太多额外负担。等它跑顺了再考虑引入更完整的日志平台。7. 排查登录日志的这三年我踩过的一些坑方法论讲得再多都不如实际踩坑记忆深刻。最后分享几个我很常见的低级错误希望你看完能避开。7.1 日志文件明明存在却怎么也搜不到记录有一次我在一台 Ubuntu 服务器上排查登录日志tail /var/log/auth.log有内容但grep某个IP却一条都搜不到。后来才发现那台服务器的 rsyslog 配置里把auth设备单独重定向到了另一个文件不在默认的 auth.log 里。具体可以这样查grep ^auth /etc/rsyslog.conf /etc/rsyslog.d/*.conf 2/dev/null看到的是真实的落盘路径比猜靠谱得多。类似的还有 systemd 机器上的journalctl和 rsyslog 各写一份内容不一定完全一致别把两边当成同一个文件看待。7.2 lastb 显示“No such file or directory”不代表没有失败记录lastb依赖/var/log/btmp。很多新装的系统根本不会自动创建这个文件导致lastb直接报错。这不意味着没有失败记录只是没有 btmp 文件而已auth.log里照样满满当当。解决办法很简单touch /var/log/btmp chown root:utmp /var/log/btmp chmod 660 /var/log/btmp只要别用last和lastb同时把 btmp 和 wtmp 搞混后面排查会顺畅很多。7.3 别把“端口探测”当成“SSH暴力破解”有时你会看到日志里出现连接记录然后几秒内又断开没有任何认证过程。这往往是别人在扫描端口而不是在猜密码。判断标准很简单一条连认证都没开始的连接谈不上“登录异常”只能算“端口被扫了”。收集这类信息不是没用但别把它们混进登录失败的告警里否则告警噪音会大到让你忽略真正的风险。7.4 云平台的管控入口也要盯有一次我在一台云服务器上查不到任何异常登录但用户命令历史里出现了一条不该存在的操作。最后排查发现攻击者是通过云平台的控制台 VNC 登录进去的根本不走 SSH所以系统认证日志里没记录。也就是说排查“异常登录”不能只看系统日志还要看云平台的管理操作记录。尤其是重装系统、重置密码、VNC登录、挂载云盘这些关键动作都要纳入你的审查范围。我自己现在的习惯是重要服务器每周末打包一次认证日志存到对象存储日常的失败登录用 cron 脚本统计真正的“成功登录且行为异常”事件人工复核。这套流程坚持下来再碰到“一图看懂一次异常登录服务器有没有记录”的问题就不会再慌因为你已经知道记录在哪里、怎么查、怎么让记录真正保护自己。