日志审计系统这个东西说难不难说简单也不简单。难的是很多运维同学第一反应是不就是把日志收集过来嘛有什么好折腾的真正上手之后才发现光是让Windows、Linux、Web服务器三拨日志稳定地进到系统里就能折腾掉一两天。我也踩过不少坑这次把我最近在一套绿盟LAS日志审计系统上做采集的完整过程整理出来给准备做等保整改或者正在折腾日志平台的兄弟做个参考。先说清楚这套东西是干嘛的。绿盟LAS日志审计系统是一套软硬一体的日志收集、存储、审计分析平台常见部署场景是企业内网核心交换区旁路挂一台然后让所有服务器的日志通过网络送过来统一做留存和分析。等保2.0要求日志留存不少于六个月各种安全设备、服务器、数据库的日志都要可追溯光靠登录每台机器去看根本不可能这时候日志审计系统就是刚需。这篇文章适合谁看刚接手日志采集的新人、正在做等保整改的运维工程师、还有那些被领导一句“把日志都接到审计系统里”安排得明明白白的朋友。我不会跟你扯太深的理论按步骤操作就行涉及的原理我会用大白话解释清楚。1. 项目概述日志采集到底在采什么1.1 核心需求解析我最近在协助某公司做内网日志改造环境不算复杂两台Windows Server、三台Linux服务器外加一套Web应用跑在Nginx后面。领导的要求很简单——所有服务器日志都要进绿盟LAS审计员随时能查到谁登录过、谁访问过什么、系统有没有异常报错。听起来简单实际上要采集的内容分三类系统日志操作系统自己产生的事件记录比如用户登录、服务启动停止、系统报错。Windows叫事件日志Linux分散在/var/log下的各种文件里。应用日志Web服务器的访问记录、错误记录数据库的操作记录等。这类日志格式最杂不同中间件格式完全不一样。安全日志登录成功/失败记录、权限变更记录、防火墙阻断记录。等保检查主要盯这一类。1.2 部署架构与采集链路设计LAS在架构上通常分采集器和审计中心两部分小规模部署一台设备全搞定。采集链路就是服务器产生日志 → 通过网络传给LAS → LAS解析、归一化、存储 → 审计员在Web界面查询和配置告警。我在这个项目里选择了旁路部署核心交换机上给LAS划了一个独立VLAN服务器通过内网把日志送过来。所有服务器和LAS之间不经过公网链路本身是可信的。画一下我实际用的拓扑思路LAS管理口接运维网段管理员通过浏览器登录管理界面。日志接收口接业务网段服务器通过这个口把日志送过来监听514/UDPsyslog和Agent专用端口。两台Windows Server装采集Agent主动把事件日志推给LAS。三台Linux配置rsyslog转发把/var/log/messages、/var/log/secure等文件内容发给LAS。一台Nginx服务器通过rsyslog把访问日志和错误日志转发过去因为这台是Linux系统不用额外装Agent。1.3 采集前的准备工作清单别急着动手改配置先花半小时把信息收集齐。我是吃过亏的——第一次做的时候没规划好弄到一半才发现Windows服务器防火墙没开端口Linux服务器时区不对导致日志时间差八个小时来回折腾。建议先做这样一张表服务器操作系统IP地址需要采集的日志日志路径采集方式Web01Linux192.168.1.11Nginx访问日志、错误日志、系统日志/var/log/nginx/*.log、/var/log/messagesrsyslog转发App01Windows192.168.1.21系统事件日志安全、系统、应用事件查看器AgentDB01Linux192.168.1.31系统日志、MySQL慢查询日志/var/log/messages、/var/log/mysql/slow.logrsyslog转发顺便确认几个关键信息LAS管理界面的IP和账号密码、日志接收端口是否可达、服务器和LAS之间的时间是否同步。时钟同步这一步很多人忽略审计日志时间对不上的话后面排查问题会想死。2. 采集协议与方式选型为什么这样选2.1 三种常见采集方式的工作机制接触过日志审计的朋友应该知道设备接入LAS无外乎三种方式SYSLOG转发服务器上装个syslog客户端Linux自带rsyslogWindows可以装第三方工具把日志按标准格式发到LAS的514端口。优点是对系统资源占用极小缺点是没有加密且发送方只管发不确认接收方有没有收到。Agent采集在服务器上装一个厂商提供的采集程序由Agent主动连接LAS把日志推送过去。好处是支持Windows事件日志这种特殊格式还能做本地缓存防丢包坏处是每台机器都要装规模化部署时工作量不小。SNMP Trap主要用于网络设备比如交换机、路由器、防火墙主动上报告警。服务器日志一般不采用这种方式但如果你要把网络设备的日志也接进来需要了解。2.2 三种方式的优缺点对比采集方式优点缺点适用场景SYSLOG转发配置简单、零依赖、兼容性好无加密、UDP模式下可能丢包Linux服务器、网络设备Agent采集支持复杂日志格式、本地缓存、可靠传输需要逐台安装、有系统兼容性要求Windows服务器、数据库SNMP Trap网络设备原生支持不支持完整日志内容只传告警交换机、防火墙2.3 选型建议我的经验是分场景来Windows服务器优先装Agent原因是Windows事件日志格式复杂有Event ID、Level、Provider等结构化字段用syslog转发需要做一层转换搞不好字段就丢了。Agent能把这些结构化信息原样传给LAS审计的时候按事件ID查起来非常方便。Linux服务器直接用自带的rsyslog就能搞定不用装任何额外组件。系统默认就装了rsyslog改个配置文件重启一下服务就行。除非日志量巨大且要求可靠传输这时候可以考虑用TCP而非UDP。Web服务器看情况如果是LinuxNginx/Apache跟着系统日志一起用rsyslog转发即可。如果是WindowsIIS那就走Agent方案。3. Linux服务器日志采集实操rsyslog也能玩出花3.1 rsyslog转发配置的完整步骤Linux采集我用的方式是修改rsyslog配置把系统日志实时转发给LAS。先找到配置文件通常在/etc/rsyslog.conf或者/etc/rsyslog.d/目录下。我用的是/etc/rsyslog.d/60-las-forward.conf这个新文件不动主配置方便后期维护。# /etc/rsyslog.d/60-las-forward.conf # 转发所有日志到LAS服务器使用TCP协议端口514 *.* 192.168.1.10:514这里有一个关键点和的区别。单个表示使用UDP协议发送两个表示使用TCP协议。UDP快但不可靠TCP慢一点但能确认收到。在日志审计场景里我强烈建议用TCP特别是等保检查要求日志完整留存的情况下UDP丢包就是给自己埋雷。如果你只想转发核心日志不想要太吵的杂讯可以按类型过滤# 只转发认证日志和系统日志 authpriv.* 192.168.1.10:514 cron.* 192.168.1.10:514 kern.* 192.168.1.10:514 *.info;mail.none;authpriv.none;cron.none 192.168.1.10:514这里*.info代表所有级别为info及以上的日志mail.none表示排除邮件日志authpriv.none表示排除认证日志因为上面已经单独转了避免重复发送。改完之后重启服务systemctl restart rsyslog systemctl status rsyslog3.2 分类转发与日志格式定制如果服务器上跑着Web服务或数据库一般还需要把应用自己的日志文件也送过来。以Nginx为例访问日志写在/var/log/nginx/access.log里rsyslog默认不读这个文件需要加一个模块# /etc/rsyslog.d/60-las-forward.conf 追加 # 加载imfile模块用于读取文本文件 module(loadimfile) # Nginx访问日志 input(typeimfile File/var/log/nginx/access.log Tagnginx_access Severityinfo Facilitylocal1) # Nginx错误日志 input(typeimfile File/var/log/nginx/error.log Tagnginx_error Severityerror Facilitylocal1)imfile模块的作用是让rsyslog像读系统日志一样把指定文件的内容一条条读出来并转发。配置好以后nginx的访问日志和系统日志会一起送到LAS。Apache的话同理把File路径换成/var/log/apache2/access.log或者/var/log/httpd/access_log就行。注意imfile模块读取文件时是按行读取的每条日志结尾必须换行否则最后一条日志可能不触发读取。Nginx和Apache默认格式都带换行问题不大。3.3 验证Linux日志是否成功到达LAS配置完别急着收工先验证一下。在服务器上执行logger LAS connectivity test from Web01这条命令会往系统日志里写一条测试信息并触发rsyslog转发。如果配置正确几分钟之内在LAS的日志检索界面搜索关键字“LAS connectivity test”就能看到这条记录。如果想在服务器侧确认是否真的发出去了可以抓包tcpdump -i eth0 port 514 -c 10看到有数据包发往LAS的IP就说明链路通了。如果抓包有数据但LAS那边收不到基本可以断定是防火墙或者LAS侧的接收配置问题。4. Windows服务器日志采集实操事件日志接入的那些坑4.1 基于Agent的事件日志采集Windows的日志采集我最后选了Agent方案。说实话Windows原生的事件日志转发功能WEC配置相当繁琐需要在收集器上跑WinRM服务、配置转发订阅、还要改组策略一套搞下来半天没了。对于只想把日志弄到LAS里的场景Agent是性价比最高的选择。在LAS管理界面找到Agent安装包传到Windows服务器上双击安装。按提示填写LAS的IP和通信端口默认会用TCP协议连接LAS的Agent服务端口。Agent装好后在LAS管理端能看到这台主机自动上报接下来就是勾选要采集的日志类型。Windows事件日志分三类Application应用程序产生的日志比如某个服务崩溃、某个软件报错。Security安全日志包括登录成功、登录失败、特权操作等。这是等保检查的重点。System系统组件产生的日志比如服务启动停止、驱动加载失败、系统关机重启。在Agent配置里把这三类都勾上按级别可以选择性过滤。我建议全部采集然后到LAS侧做过滤因为审计要求“先留存后分析”别在采集端就把日志丢了。4.2 Windows系统日志权限与关键事件理解有件事容易被带沟里Security日志默认只有管理员组能读。Agent通常以管理员权限运行读取没问题但如果你用普通运维账号去Windows上直接看事件查看器可能看不到安全日志的详细内容。另外Windows日志里噪音很大特别是System日志动不动就刷Service Control Manager的事件ID 7040、7036。这些日志本身没坏处但如果不做过滤会在LAS里占据大量存储空间还会让审计员挑重点的时候想骂人。我的做法是在Agent配置里关闭一些已知的噪音事件或者在LAS端配置过滤规则排除事件ID 7036服务状态变更通知排除事件ID 7040服务启动类型变更通知保留登录相关的4624登录成功、4625登录失败、4740账号被锁定这里要留意4624是登录成功每次用户输密码进去就会产生一条。攻击者在爆破的时候会产生海量4625登录失败配合上锁定策略这条告警在等保检查里经常被抽查到。4.3 Windows时间同步与防火墙放行Windows服务器如果时间不准日志时间戳就是乱的。等保审计的时候时间对不上会直接被判定不合规。我的习惯是所有服务器统一用NTP服务器同步时间。设置NTPw32tm /config /manualpeerlist:ntp.aliyun.com /syncfromflags:manual /reliable:yes /update w32tm /resync另外Agent安装完以后Windows防火墙可能弹出提示需要允许Agent程序通过防火墙。有些安全软件也会拦截Agent的通信行为加入白名单比较好。我碰到过一台服务器Agent装完怎么也连不上LAS最后发现是服务器上的主机安全软件把Agent的网络通信给拦了加白名单后立刻恢复。5. Web服务器日志采集实操Nginx、Apache、IIS全覆盖5.1 Nginx访问日志与错误日志的采集配置Nginx的日志采集在上面Linux部分已经提过用rsyslog的imfile模块就能搞定。这里展开讲一下格式问题。Nginx默认的日志格式是combined格式长这样192.168.1.21 - - [23/Mar/2025:14:23:45 0800] GET /index.php HTTP/1.1 200 5120 - Mozilla/5.0 (Windows NT 10.0; Win64; x64)这个格式里包含客户端IP、时间、请求方法、URI、协议版本、状态码、响应大小、User-Agent。LAS认识这种格式有现成的解析模板可以直接套用。如果你自定义过Nginx日志格式比如添加了请求耗时、上游服务器地址等字段LAS的默认模板就不认识了。这时候有两个选择一是改Nginx配置把它切回默认格式二是在LAS端自定义解析规则。我的建议是如果自定义字段对业务审计有用就保留自定义格式然后在LAS里新建一个解析模板用正则把字段拆出来。这个稍后在LAS配置部分细说。5.2 Apache与IIS日志采集的差异点Apache的访问日志和Nginx类似默认是Common Log Format或者Combined Log Format路径通常在/var/log/apache2/access.log或/var/log/httpd/access_log。采集方式同样是rsyslog imfile转发。IIS则完全是另一个物种。IIS日志默认路径是C:\inetpub\logs\LogFiles\文件名像W3SVC1\u_ex250323.log这样的格式。内容也是W3C扩展格式用逗号或空格分隔字段和Apache/Nginx差异很大。Windows上的IIS日志采集我建议用Agent方式因为Agent对Windows文件系统集成度更好能监控日志目录的增量变化。另外一个原因IIS日志文件的字段默认就不完整需要在IIS管理器的“日志”功能里勾选字段把所有需要的字段都选上Agent才能抓到完整数据。5.3 Web日志格式与LAS解析模板的匹配技巧无论哪种Web服务器日志格式都是文本LAS要从中提取结构化字段靠的是解析模板。模板的核心是正则表达式。我的经验是在配置LAS数据源时先确认日志的真实格式再选模板。怎么确认直接在服务器上执行tail -5 /var/log/nginx/access.log看几行真实日志心里有数。然后到LAS的日志源管理里选“Nginx访问日志”这个模板先点“测试解析”把日志样本贴进去看能否正确提取出IP、时间、状态码字段。如果测试解析失败多半是日志格式和模板不匹配。常见的坑有时间格式不同标准是[23/Mar/2025:14:23:45 0800]有些配置是2025-03-23T14:23:4508:00模板就不认。引号处理字段值带引号时正则里的转义容易出错。新增字段某天升级了日志格式多了一列字段老模板就不匹配了。6. LAS端配置日志源接入、解析规则与审计策略6.1 新增日志源与采集器注册服务器端的配置做完回到LAS管理界面把每一台服务器作为日志源加进来。一般路径是资产管理 → 新增资产 → 填写主机名、IP、操作系统类型 → 选择采集方式syslog/Agent→ 配置协议和端口 → 保存。我的习惯是给每个日志源起一个明确命名的名字比如“Web01-Nginx-Access”、“App01-Windows-Security”这样在LAS检索界面看日志列表时一眼就能看出是哪台机器哪类日志不用费力去猜IP。这里特别提醒创建日志源时填写的IP地址必须和服务器实际发送日志的源IP一致。如果服务器有多块网卡syslog转发时可能走了另一块网卡的IPLAS会把这条日志识别为“未知来源”而拒收。我在配置Linux服务器时遇到过这个坑服务器管理口和业务口IP不同rsyslog默认走管理口发送和LAS里配的数据源IP对不上日志被丢了好久才发现。6.2 LAS日志解析与归一化设置日志源接入后LAS会把原始日志存下来同时按照解析模板做字段提取把IP、时间、用户名、操作类型等关键字段放到统一的字段表里这个流程叫归一化。归一化后的字段在查询时可以直接用SQL-like语法搜索src_ip 192.168.1.21 AND event_type login_failureLAS内置了常见设备的解析模板Linux系统日志、Windows事件日志、Nginx、Apache、IIS都有现成的。对自定义格式的日志需要在“自定义解析规则”里写正则。举个例子Nginx自定义日志格式为$remote_addr|$time_local|$request_method|$request_uri|$status|$request_time对应日志行192.168.1.21|23/Mar/2025:14:23:45 0800|GET|/index.php|200|0.128解析正则可以写成^(?Psrc_ip\S)\|(?Ptime[^|])\|(?Pmethod\S)\|(?Puri\S)\|(?Pstatus\d)\|(?Pstart_time[\d.])然后用这个模板做解析测试确认每个字段都能映射上就行了。这里用到的命名捕获组语法LAS的解析引擎是支持的具体不同版本略有差异以你手里的版本为准。6.3 审计策略与告警通知配置日志采集只是第一步LAS的价值在审计策略。我的习惯是至少配置以下几类策略策略名称触发条件严重级别暴力破解检测同一来源IP在5分钟内登录失败超过5次高非法登录尝试非工作时间22:00-8:00登录成功中Web攻击检测访问URL中包含SQL注入、XSS特征高账号锁定告警日志中出现账号被锁定事件高后门/异常账号新增管理员组成员高配置路径一般是审计策略 → 新增策略 → 选择关联日志源 → 设置触发条件 → 选择动作邮件告警/短信告警/SYSLOG转发。告警通知一定要配否则审计系统只会闷头存日志出了事没人知道。邮件告警最简单的配置方式是设置一个告警邮箱LAS检测到触发条件后自动发邮件。内部测试观察到从日志到达LAS到告警邮件发出大约有1-2分钟延迟这在可接受范围内。7. 常见问题与排查技巧实录7.1 日志收不到从三个层面快速定位日志收不到是最常见的问题别慌按这个顺序排查首先看服务器端服务是否在跑systemctl status rsyslog然后看网络层防火墙是否放行了514端口firewall-cmd --list-all或者直接抓包确认有没有数据包发出去tcpdump -i eth0 host 192.168.1.10 and port 514 -c 20最后看LAS端日志源是否在线数据源配置里的IP是否匹配如果服务器端抓包有数据LAS侧显示日志源离线九成是IP不匹配或端口没监听。7.2 日志乱码或中文显示异常Linux服务器默认UTF-8编码Windows服务器默认GBK编码。日志到LAS里显示乱码一般是编码不匹配导致的。解决方法就一个思路让所有环节使用同一编码。Windows上装Agent时确认Agent的字符集设置是UTF-8Linux那边一般不用动保持默认UTF-8就行。如果Windows日志已经入库乱码了可以在LAS的解析规则里配置编码转换从GBK转UTF-8但这样会占用一些处理资源能治本还是让源头统一最好。7.3 日志时间与真实时间不一致遇到这个先查时区timedatectl如果显示UTC而不是CST北京时间说明系统时区没设对。时间差8小时基本就是这个原因。再用NTP同步yum install ntpdate -y ntpdate ntp.aliyun.comLAS端本身也要保证时间准确不然所有日志的时间戳都会错位。等保检查对时间源有明确要求建议LAS也同步到同一台NTP服务器。7.4 日志量太大导致丢包或性能瓶颈日志量大是大规模环境里必然遇到的问题。UDP转发模式下系统日志和Web访问日志如果量大很容易在高峰期出现丢包。我的解决方案是两步走第一步把rsyslog转发协议从UDP改为TCP*.* 192.168.1.10:514第二步给rsyslog增加队列配置防止日志高峰时进程阻塞$WorkDirectory /var/spool/rsyslog $ActionQueueFileName fwdQueue $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1这些配置的意思是转发失败时日志先缓存到磁盘网络恢复后继续发送不会因为网络抖动丢日志。这是我踩过坑后才学乖的——第一版配置只用了UDP大促活动期间日志井喷LAS里缺了整整两小时的日志审计的时候才发现。7.5 排查问题时的经验速查表现象可能原因排查命令/动作rsyslog改了配置没生效忘记重启服务systemctl restart rsyslogLAS收不到Linux日志防火墙挡514端口firewall-cmd --list-allWindows Agent连不上LAS安全软件拦截检查安全软件白名单日志乱码编码不一致统一为UTF-8日志时间差8小时时区没设置timedatectl set-timezone Asia/Shanghai日志解析字段为空格式模板不匹配使用“测试解析”功能日志量巨大导致丢包使用UDP传输改TCP并启用rsyslog队列最后再说几句实在话这套配置流程走下来Linux系统日志、Windows事件日志、Web访问日志三类都能进绿盟LAS了审计策略也配了告警邮件也通了等保检查要的“日志留存六个月、可追溯、可审计”基本就落地了。我个人在实际操作中的体会是日志采集这种活看着基础但一旦配上审计策略、告警规则就成了一座安全分析的金矿。我现在的习惯是每次做完采集配置都会随手写一份记录这台服务器用的什么协议、送的哪个端口、日志格式是什么模板、有没有字段被过滤。三个月后再排查的时候这份记录比任何文档都有用。另外LAS这类设备日常维护其实很简单磁盘满了清一下归档、定期导出报表、偶尔看看日志源在线状态就够了。真正需要用人的地方反而是前期把这些采集规则搞规矩后面全自动跑着就行。祝各位一次配置成功日志不漏一条。 
长河君 · 2026/10/21 17:36:05 · 阅读 1.2k 日志审计系统采集实战：从rsyslog到Agent的绿盟LAS接入全指南
日志审计系统这个东西说难不难说简单也不简单。难的是很多运维同学第一反应是不就是把日志收集过来嘛有什么好折腾的真正上手之后才发现光是让Windows、Linux、Web服务器三拨日志稳定地进到系统里就能折腾掉一两天。我也踩过不少坑这次把我最近在一套绿盟LAS日志审计系统上做采集的完整过程整理出来给准备做等保整改或者正在折腾日志平台的兄弟做个参考。先说清楚这套东西是干嘛的。绿盟LAS日志审计系统是一套软硬一体的日志收集、存储、审计分析平台常见部署场景是企业内网核心交换区旁路挂一台然后让所有服务器的日志通过网络送过来统一做留存和分析。等保2.0要求日志留存不少于六个月各种安全设备、服务器、数据库的日志都要可追溯光靠登录每台机器去看根本不可能这时候日志审计系统就是刚需。这篇文章适合谁看刚接手日志采集的新人、正在做等保整改的运维工程师、还有那些被领导一句“把日志都接到审计系统里”安排得明明白白的朋友。我不会跟你扯太深的理论按步骤操作就行涉及的原理我会用大白话解释清楚。1. 项目概述日志采集到底在采什么1.1 核心需求解析我最近在协助某公司做内网日志改造环境不算复杂两台Windows Server、三台Linux服务器外加一套Web应用跑在Nginx后面。领导的要求很简单——所有服务器日志都要进绿盟LAS审计员随时能查到谁登录过、谁访问过什么、系统有没有异常报错。听起来简单实际上要采集的内容分三类系统日志操作系统自己产生的事件记录比如用户登录、服务启动停止、系统报错。Windows叫事件日志Linux分散在/var/log下的各种文件里。应用日志Web服务器的访问记录、错误记录数据库的操作记录等。这类日志格式最杂不同中间件格式完全不一样。安全日志登录成功/失败记录、权限变更记录、防火墙阻断记录。等保检查主要盯这一类。1.2 部署架构与采集链路设计LAS在架构上通常分采集器和审计中心两部分小规模部署一台设备全搞定。采集链路就是服务器产生日志 → 通过网络传给LAS → LAS解析、归一化、存储 → 审计员在Web界面查询和配置告警。我在这个项目里选择了旁路部署核心交换机上给LAS划了一个独立VLAN服务器通过内网把日志送过来。所有服务器和LAS之间不经过公网链路本身是可信的。画一下我实际用的拓扑思路LAS管理口接运维网段管理员通过浏览器登录管理界面。日志接收口接业务网段服务器通过这个口把日志送过来监听514/UDPsyslog和Agent专用端口。两台Windows Server装采集Agent主动把事件日志推给LAS。三台Linux配置rsyslog转发把/var/log/messages、/var/log/secure等文件内容发给LAS。一台Nginx服务器通过rsyslog把访问日志和错误日志转发过去因为这台是Linux系统不用额外装Agent。1.3 采集前的准备工作清单别急着动手改配置先花半小时把信息收集齐。我是吃过亏的——第一次做的时候没规划好弄到一半才发现Windows服务器防火墙没开端口Linux服务器时区不对导致日志时间差八个小时来回折腾。建议先做这样一张表服务器操作系统IP地址需要采集的日志日志路径采集方式Web01Linux192.168.1.11Nginx访问日志、错误日志、系统日志/var/log/nginx/*.log、/var/log/messagesrsyslog转发App01Windows192.168.1.21系统事件日志安全、系统、应用事件查看器AgentDB01Linux192.168.1.31系统日志、MySQL慢查询日志/var/log/messages、/var/log/mysql/slow.logrsyslog转发顺便确认几个关键信息LAS管理界面的IP和账号密码、日志接收端口是否可达、服务器和LAS之间的时间是否同步。时钟同步这一步很多人忽略审计日志时间对不上的话后面排查问题会想死。2. 采集协议与方式选型为什么这样选2.1 三种常见采集方式的工作机制接触过日志审计的朋友应该知道设备接入LAS无外乎三种方式SYSLOG转发服务器上装个syslog客户端Linux自带rsyslogWindows可以装第三方工具把日志按标准格式发到LAS的514端口。优点是对系统资源占用极小缺点是没有加密且发送方只管发不确认接收方有没有收到。Agent采集在服务器上装一个厂商提供的采集程序由Agent主动连接LAS把日志推送过去。好处是支持Windows事件日志这种特殊格式还能做本地缓存防丢包坏处是每台机器都要装规模化部署时工作量不小。SNMP Trap主要用于网络设备比如交换机、路由器、防火墙主动上报告警。服务器日志一般不采用这种方式但如果你要把网络设备的日志也接进来需要了解。2.2 三种方式的优缺点对比采集方式优点缺点适用场景SYSLOG转发配置简单、零依赖、兼容性好无加密、UDP模式下可能丢包Linux服务器、网络设备Agent采集支持复杂日志格式、本地缓存、可靠传输需要逐台安装、有系统兼容性要求Windows服务器、数据库SNMP Trap网络设备原生支持不支持完整日志内容只传告警交换机、防火墙2.3 选型建议我的经验是分场景来Windows服务器优先装Agent原因是Windows事件日志格式复杂有Event ID、Level、Provider等结构化字段用syslog转发需要做一层转换搞不好字段就丢了。Agent能把这些结构化信息原样传给LAS审计的时候按事件ID查起来非常方便。Linux服务器直接用自带的rsyslog就能搞定不用装任何额外组件。系统默认就装了rsyslog改个配置文件重启一下服务就行。除非日志量巨大且要求可靠传输这时候可以考虑用TCP而非UDP。Web服务器看情况如果是LinuxNginx/Apache跟着系统日志一起用rsyslog转发即可。如果是WindowsIIS那就走Agent方案。3. Linux服务器日志采集实操rsyslog也能玩出花3.1 rsyslog转发配置的完整步骤Linux采集我用的方式是修改rsyslog配置把系统日志实时转发给LAS。先找到配置文件通常在/etc/rsyslog.conf或者/etc/rsyslog.d/目录下。我用的是/etc/rsyslog.d/60-las-forward.conf这个新文件不动主配置方便后期维护。# /etc/rsyslog.d/60-las-forward.conf # 转发所有日志到LAS服务器使用TCP协议端口514 *.* 192.168.1.10:514这里有一个关键点和的区别。单个表示使用UDP协议发送两个表示使用TCP协议。UDP快但不可靠TCP慢一点但能确认收到。在日志审计场景里我强烈建议用TCP特别是等保检查要求日志完整留存的情况下UDP丢包就是给自己埋雷。如果你只想转发核心日志不想要太吵的杂讯可以按类型过滤# 只转发认证日志和系统日志 authpriv.* 192.168.1.10:514 cron.* 192.168.1.10:514 kern.* 192.168.1.10:514 *.info;mail.none;authpriv.none;cron.none 192.168.1.10:514这里*.info代表所有级别为info及以上的日志mail.none表示排除邮件日志authpriv.none表示排除认证日志因为上面已经单独转了避免重复发送。改完之后重启服务systemctl restart rsyslog systemctl status rsyslog3.2 分类转发与日志格式定制如果服务器上跑着Web服务或数据库一般还需要把应用自己的日志文件也送过来。以Nginx为例访问日志写在/var/log/nginx/access.log里rsyslog默认不读这个文件需要加一个模块# /etc/rsyslog.d/60-las-forward.conf 追加 # 加载imfile模块用于读取文本文件 module(loadimfile) # Nginx访问日志 input(typeimfile File/var/log/nginx/access.log Tagnginx_access Severityinfo Facilitylocal1) # Nginx错误日志 input(typeimfile File/var/log/nginx/error.log Tagnginx_error Severityerror Facilitylocal1)imfile模块的作用是让rsyslog像读系统日志一样把指定文件的内容一条条读出来并转发。配置好以后nginx的访问日志和系统日志会一起送到LAS。Apache的话同理把File路径换成/var/log/apache2/access.log或者/var/log/httpd/access_log就行。注意imfile模块读取文件时是按行读取的每条日志结尾必须换行否则最后一条日志可能不触发读取。Nginx和Apache默认格式都带换行问题不大。3.3 验证Linux日志是否成功到达LAS配置完别急着收工先验证一下。在服务器上执行logger LAS connectivity test from Web01这条命令会往系统日志里写一条测试信息并触发rsyslog转发。如果配置正确几分钟之内在LAS的日志检索界面搜索关键字“LAS connectivity test”就能看到这条记录。如果想在服务器侧确认是否真的发出去了可以抓包tcpdump -i eth0 port 514 -c 10看到有数据包发往LAS的IP就说明链路通了。如果抓包有数据但LAS那边收不到基本可以断定是防火墙或者LAS侧的接收配置问题。4. Windows服务器日志采集实操事件日志接入的那些坑4.1 基于Agent的事件日志采集Windows的日志采集我最后选了Agent方案。说实话Windows原生的事件日志转发功能WEC配置相当繁琐需要在收集器上跑WinRM服务、配置转发订阅、还要改组策略一套搞下来半天没了。对于只想把日志弄到LAS里的场景Agent是性价比最高的选择。在LAS管理界面找到Agent安装包传到Windows服务器上双击安装。按提示填写LAS的IP和通信端口默认会用TCP协议连接LAS的Agent服务端口。Agent装好后在LAS管理端能看到这台主机自动上报接下来就是勾选要采集的日志类型。Windows事件日志分三类Application应用程序产生的日志比如某个服务崩溃、某个软件报错。Security安全日志包括登录成功、登录失败、特权操作等。这是等保检查的重点。System系统组件产生的日志比如服务启动停止、驱动加载失败、系统关机重启。在Agent配置里把这三类都勾上按级别可以选择性过滤。我建议全部采集然后到LAS侧做过滤因为审计要求“先留存后分析”别在采集端就把日志丢了。4.2 Windows系统日志权限与关键事件理解有件事容易被带沟里Security日志默认只有管理员组能读。Agent通常以管理员权限运行读取没问题但如果你用普通运维账号去Windows上直接看事件查看器可能看不到安全日志的详细内容。另外Windows日志里噪音很大特别是System日志动不动就刷Service Control Manager的事件ID 7040、7036。这些日志本身没坏处但如果不做过滤会在LAS里占据大量存储空间还会让审计员挑重点的时候想骂人。我的做法是在Agent配置里关闭一些已知的噪音事件或者在LAS端配置过滤规则排除事件ID 7036服务状态变更通知排除事件ID 7040服务启动类型变更通知保留登录相关的4624登录成功、4625登录失败、4740账号被锁定这里要留意4624是登录成功每次用户输密码进去就会产生一条。攻击者在爆破的时候会产生海量4625登录失败配合上锁定策略这条告警在等保检查里经常被抽查到。4.3 Windows时间同步与防火墙放行Windows服务器如果时间不准日志时间戳就是乱的。等保审计的时候时间对不上会直接被判定不合规。我的习惯是所有服务器统一用NTP服务器同步时间。设置NTPw32tm /config /manualpeerlist:ntp.aliyun.com /syncfromflags:manual /reliable:yes /update w32tm /resync另外Agent安装完以后Windows防火墙可能弹出提示需要允许Agent程序通过防火墙。有些安全软件也会拦截Agent的通信行为加入白名单比较好。我碰到过一台服务器Agent装完怎么也连不上LAS最后发现是服务器上的主机安全软件把Agent的网络通信给拦了加白名单后立刻恢复。5. Web服务器日志采集实操Nginx、Apache、IIS全覆盖5.1 Nginx访问日志与错误日志的采集配置Nginx的日志采集在上面Linux部分已经提过用rsyslog的imfile模块就能搞定。这里展开讲一下格式问题。Nginx默认的日志格式是combined格式长这样192.168.1.21 - - [23/Mar/2025:14:23:45 0800] GET /index.php HTTP/1.1 200 5120 - Mozilla/5.0 (Windows NT 10.0; Win64; x64)这个格式里包含客户端IP、时间、请求方法、URI、协议版本、状态码、响应大小、User-Agent。LAS认识这种格式有现成的解析模板可以直接套用。如果你自定义过Nginx日志格式比如添加了请求耗时、上游服务器地址等字段LAS的默认模板就不认识了。这时候有两个选择一是改Nginx配置把它切回默认格式二是在LAS端自定义解析规则。我的建议是如果自定义字段对业务审计有用就保留自定义格式然后在LAS里新建一个解析模板用正则把字段拆出来。这个稍后在LAS配置部分细说。5.2 Apache与IIS日志采集的差异点Apache的访问日志和Nginx类似默认是Common Log Format或者Combined Log Format路径通常在/var/log/apache2/access.log或/var/log/httpd/access_log。采集方式同样是rsyslog imfile转发。IIS则完全是另一个物种。IIS日志默认路径是C:\inetpub\logs\LogFiles\文件名像W3SVC1\u_ex250323.log这样的格式。内容也是W3C扩展格式用逗号或空格分隔字段和Apache/Nginx差异很大。Windows上的IIS日志采集我建议用Agent方式因为Agent对Windows文件系统集成度更好能监控日志目录的增量变化。另外一个原因IIS日志文件的字段默认就不完整需要在IIS管理器的“日志”功能里勾选字段把所有需要的字段都选上Agent才能抓到完整数据。5.3 Web日志格式与LAS解析模板的匹配技巧无论哪种Web服务器日志格式都是文本LAS要从中提取结构化字段靠的是解析模板。模板的核心是正则表达式。我的经验是在配置LAS数据源时先确认日志的真实格式再选模板。怎么确认直接在服务器上执行tail -5 /var/log/nginx/access.log看几行真实日志心里有数。然后到LAS的日志源管理里选“Nginx访问日志”这个模板先点“测试解析”把日志样本贴进去看能否正确提取出IP、时间、状态码字段。如果测试解析失败多半是日志格式和模板不匹配。常见的坑有时间格式不同标准是[23/Mar/2025:14:23:45 0800]有些配置是2025-03-23T14:23:4508:00模板就不认。引号处理字段值带引号时正则里的转义容易出错。新增字段某天升级了日志格式多了一列字段老模板就不匹配了。6. LAS端配置日志源接入、解析规则与审计策略6.1 新增日志源与采集器注册服务器端的配置做完回到LAS管理界面把每一台服务器作为日志源加进来。一般路径是资产管理 → 新增资产 → 填写主机名、IP、操作系统类型 → 选择采集方式syslog/Agent→ 配置协议和端口 → 保存。我的习惯是给每个日志源起一个明确命名的名字比如“Web01-Nginx-Access”、“App01-Windows-Security”这样在LAS检索界面看日志列表时一眼就能看出是哪台机器哪类日志不用费力去猜IP。这里特别提醒创建日志源时填写的IP地址必须和服务器实际发送日志的源IP一致。如果服务器有多块网卡syslog转发时可能走了另一块网卡的IPLAS会把这条日志识别为“未知来源”而拒收。我在配置Linux服务器时遇到过这个坑服务器管理口和业务口IP不同rsyslog默认走管理口发送和LAS里配的数据源IP对不上日志被丢了好久才发现。6.2 LAS日志解析与归一化设置日志源接入后LAS会把原始日志存下来同时按照解析模板做字段提取把IP、时间、用户名、操作类型等关键字段放到统一的字段表里这个流程叫归一化。归一化后的字段在查询时可以直接用SQL-like语法搜索src_ip 192.168.1.21 AND event_type login_failureLAS内置了常见设备的解析模板Linux系统日志、Windows事件日志、Nginx、Apache、IIS都有现成的。对自定义格式的日志需要在“自定义解析规则”里写正则。举个例子Nginx自定义日志格式为$remote_addr|$time_local|$request_method|$request_uri|$status|$request_time对应日志行192.168.1.21|23/Mar/2025:14:23:45 0800|GET|/index.php|200|0.128解析正则可以写成^(?Psrc_ip\S)\|(?Ptime[^|])\|(?Pmethod\S)\|(?Puri\S)\|(?Pstatus\d)\|(?Pstart_time[\d.])然后用这个模板做解析测试确认每个字段都能映射上就行了。这里用到的命名捕获组语法LAS的解析引擎是支持的具体不同版本略有差异以你手里的版本为准。6.3 审计策略与告警通知配置日志采集只是第一步LAS的价值在审计策略。我的习惯是至少配置以下几类策略策略名称触发条件严重级别暴力破解检测同一来源IP在5分钟内登录失败超过5次高非法登录尝试非工作时间22:00-8:00登录成功中Web攻击检测访问URL中包含SQL注入、XSS特征高账号锁定告警日志中出现账号被锁定事件高后门/异常账号新增管理员组成员高配置路径一般是审计策略 → 新增策略 → 选择关联日志源 → 设置触发条件 → 选择动作邮件告警/短信告警/SYSLOG转发。告警通知一定要配否则审计系统只会闷头存日志出了事没人知道。邮件告警最简单的配置方式是设置一个告警邮箱LAS检测到触发条件后自动发邮件。内部测试观察到从日志到达LAS到告警邮件发出大约有1-2分钟延迟这在可接受范围内。7. 常见问题与排查技巧实录7.1 日志收不到从三个层面快速定位日志收不到是最常见的问题别慌按这个顺序排查首先看服务器端服务是否在跑systemctl status rsyslog然后看网络层防火墙是否放行了514端口firewall-cmd --list-all或者直接抓包确认有没有数据包发出去tcpdump -i eth0 host 192.168.1.10 and port 514 -c 20最后看LAS端日志源是否在线数据源配置里的IP是否匹配如果服务器端抓包有数据LAS侧显示日志源离线九成是IP不匹配或端口没监听。7.2 日志乱码或中文显示异常Linux服务器默认UTF-8编码Windows服务器默认GBK编码。日志到LAS里显示乱码一般是编码不匹配导致的。解决方法就一个思路让所有环节使用同一编码。Windows上装Agent时确认Agent的字符集设置是UTF-8Linux那边一般不用动保持默认UTF-8就行。如果Windows日志已经入库乱码了可以在LAS的解析规则里配置编码转换从GBK转UTF-8但这样会占用一些处理资源能治本还是让源头统一最好。7.3 日志时间与真实时间不一致遇到这个先查时区timedatectl如果显示UTC而不是CST北京时间说明系统时区没设对。时间差8小时基本就是这个原因。再用NTP同步yum install ntpdate -y ntpdate ntp.aliyun.comLAS端本身也要保证时间准确不然所有日志的时间戳都会错位。等保检查对时间源有明确要求建议LAS也同步到同一台NTP服务器。7.4 日志量太大导致丢包或性能瓶颈日志量大是大规模环境里必然遇到的问题。UDP转发模式下系统日志和Web访问日志如果量大很容易在高峰期出现丢包。我的解决方案是两步走第一步把rsyslog转发协议从UDP改为TCP*.* 192.168.1.10:514第二步给rsyslog增加队列配置防止日志高峰时进程阻塞$WorkDirectory /var/spool/rsyslog $ActionQueueFileName fwdQueue $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1这些配置的意思是转发失败时日志先缓存到磁盘网络恢复后继续发送不会因为网络抖动丢日志。这是我踩过坑后才学乖的——第一版配置只用了UDP大促活动期间日志井喷LAS里缺了整整两小时的日志审计的时候才发现。7.5 排查问题时的经验速查表现象可能原因排查命令/动作rsyslog改了配置没生效忘记重启服务systemctl restart rsyslogLAS收不到Linux日志防火墙挡514端口firewall-cmd --list-allWindows Agent连不上LAS安全软件拦截检查安全软件白名单日志乱码编码不一致统一为UTF-8日志时间差8小时时区没设置timedatectl set-timezone Asia/Shanghai日志解析字段为空格式模板不匹配使用“测试解析”功能日志量巨大导致丢包使用UDP传输改TCP并启用rsyslog队列最后再说几句实在话这套配置流程走下来Linux系统日志、Windows事件日志、Web访问日志三类都能进绿盟LAS了审计策略也配了告警邮件也通了等保检查要的“日志留存六个月、可追溯、可审计”基本就落地了。我个人在实际操作中的体会是日志采集这种活看着基础但一旦配上审计策略、告警规则就成了一座安全分析的金矿。我现在的习惯是每次做完采集配置都会随手写一份记录这台服务器用的什么协议、送的哪个端口、日志格式是什么模板、有没有字段被过滤。三个月后再排查的时候这份记录比任何文档都有用。另外LAS这类设备日常维护其实很简单磁盘满了清一下归档、定期导出报表、偶尔看看日志源在线状态就够了。真正需要用人的地方反而是前期把这些采集规则搞规矩后面全自动跑着就行。祝各位一次配置成功日志不漏一条。