别让日志躺在服务器里吃灰
每天成千上万条网络日志自动生成，很多人觉得“留着总没错”，但真到出事了才翻记录，往往已经晚了。就像家里装了监控，却从来不看回放，等丢了东西才去查，线索早没了。真正有用的做法，是把日志当成日常巡检的一部分，而不是事后诸葛亮。
明确你要看什么
不是所有日志都值得盯着。Web 服务器的访问日志、防火墙的拦截记录、IDS/IPS 的告警、登录认证日志，每种都有不同价值。比如，突然出现大量 404 请求，可能是爬虫在探测漏洞；凌晨三点从国外 IP 登录管理员账户，大概率有问题。先想清楚你防的是什么——是暴力破解？数据泄露？还是内部滥用？目标定了，筛选条件才能跟上。
集中收集，统一格式
日志散落在不同设备上，排查起来效率极低。用 ELK（Elasticsearch + Logstash + Kibana）或者 Graylog 把所有日志集中起来，统一时间戳和字段格式，查起来才方便。下面是个简单的 Logstash 过滤配置示例：
<filter>
<source>
type => "syslog"
</source>
<grok>
match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:syslog_message}" }
</grok>
<date>
match => [ "syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ]
</date>
</filter>这样处理后，不同来源的日志就能按时间对齐，搜索时一目了然。
设置合理的告警规则
不是所有异常都要报警。比如单次登录失败很正常，但同一 IP 在一分钟内失败 10 次，就得警惕了。可以用 SIEM 工具设置阈值触发告警：
- 5 分钟内超过 20 次 404 响应
- 非工作时间出现特权账户登录
- 某个用户短时间内访问大量敏感文件路径
这些规则要结合业务实际调整，太敏感会误报太多，太宽松又可能漏掉真实攻击。
定期做日志抽样审查
即使没有告警，也建议每周抽几条典型日志看看。比如随机翻翻昨天下午的访问记录，有没有奇怪的 User-Agent？有没有异常长的请求参数？这种“散步式”检查能发现自动化规则捕捉不到的问题。曾有个案例，攻击者用合法账号上传木马，行为隐蔽，没触发任何规则，就是靠人工抽查才发现请求体里藏着 base64 编码的恶意脚本。
保留策略要合理
日志不是存得越久越好。合规要求通常规定至少保存 90 天，金融行业可能要半年以上。但硬盘空间有限，老日志可以压缩归档或转存到低成本存储。重点是保证关键时期的数据可查，比如系统升级前后、重大活动期间，这些时段的日志要重点保留。
实战中常用查询技巧
在 Kibana 里查日志，别只会搜 IP。组合条件更有效：
status:404 AND response_size:>1000
user_agent:"curl/*" AND method:POST
src_ip:192.168.1.100 AND uri:/wp-admin*这些查询能快速定位可疑行为，比如用脚本工具发起的批量请求，或者针对 CMS 后台的试探性攻击。