近日，国内网络安全公司微步在线发布了名为Flocks的智能安全数字员工产品，成为国内网络安全行业内首个完全免费、开源、本地化部署的智能数字安全员工。看到此新闻后，笔者也马上尝鲜，部署了一个进行体验。

其定位是网络安全数字员工，笔者个人认为首先需要解决的是网络安全日志的接入问题。

关于网络安全建设，笔者认为常见的企业落地场景如下

1、对于网络安全运营建设比较完全的企业，操作系统日志、edr日志、各位网络安全设备如IPS、WAF、探针等日志通过各类转发协议将日志转发到了网络安全分析运营类平台如XDR等，部分安全厂商可能会部署siem类日志审计组件或其他大数据平台收集日志，此类组件再对接安全运营平台。

这类场景下，安全运营平台统一提供API接口，供ai agent查询分析。

但这种情况下有可能会有如下几种情况

1、小型企业或个人开发者几乎未部署网络安全设备，或部署了开源或单一的网络安全设备，所用产品几乎不能提供API接口查询能力。

此类用户如果能实现flocks能读取操作系统日志、中间件日志、现有网络安全日志，让flocks进行统一分析，实现自动化告警或处置的话，意义还是相对较大的。

2、部分中小型企业网络安全建设并不很完善，仅部署了常规的网络安全设备如态势感知、探针、EDR、防火墙、零信任\VPN、日志审计 等，网络安全设备与现有的态势感知在未进行定制开发情况下进行了简单接入，并没有完善网络安全运营流程。

此场景下一般会遇到如下问题

（1）此类用户大概率没有预算投入网络安全ai的建设预算，也没有预算去定制开发态势感知系统（能每年续保都不错了），让其提供完善API接口。但如果实现ai agent获取到全部的原始安全日志情况下，也是可以很大的提供企业信息管理人员排障、统计、分析、处置的效率。

（2）但是可能存在如下情况，网络安全设备将日志发送给了日志审计或SIEM或态势感知，态势感知类平台提供的api接口能力欠缺，仅为聚合分析后的安全事件，甚至可能安全告警也没有，更何况安全日志。甚至部分安全设备仅支持配置一个syslog，配置后就无法发送到其他地方导致无法接入ai agent。

3、对于网络安全运营建设比较完全的企业，操作系统日志、edr日志、各位网络安全设备如IPS、WAF、探针等日志通过各类转发协议将日志转发到了网络安全分析运营类平台如XDR等（部分安全厂商平台可能需要部署siem类日志审计组件或其他大数据平台收集日志，此类组件再对接安全运营平台）。这种用户一般预算相对充足，会直接购买商用的AI 检测、分析、运营平台，找专业厂商定制开发ai agent等，API接口数据全不全的问题肯定在预算充足情况下完全不存在。

综上，中小型企业用户可能存在当前所用网络安全产品无法提供API接口让AI agent获取原始日志，导致 ai agent可分析内容有限，难以产生价值。

笔者认为获取网络安全日志接口通常分为2类，第一类是api接口，flocks适配主流网络安全设备的api接口，通过api接口去查询网络安全日志或告警相关事件，这也是最主流的方向。第二类是发送类接口如syslog、kafka等，网络安全设备、操作系统将网络安全日志发送到存储服务器，ai agent去读取存储服务器。既然第一条路有时难以走通，笔者就想如何利用第二条路让ai agent获取到原始日志。

废话不再多说，回归正题，分享一下syslog日志接入的常见思路。

思路一：使用linux系统自带的rsyslog实现接收syslog并转存到文件。ai工具读取文件实现日志接入。

可以接收syslog的开源产品有很多，但是笔者相对较懒，能用系统自带功能实现的绝不部署其他产品。修改/etc/rsyslog.conf配置文件，系统防火墙开放UDP514端口，即可接入syslog日志并存储。

笔者的配置文件参考如下

$CreateDirs on
module(load="imudp")
input(type="imudp" port="514")
# 模板定义
$template DeviceLog71,"/home/remote/device-10.10.33.71/%$YEAR%-%$MONTH%-%$DAY%.log"
$template DeviceLog101,"/home/remote/device-10.10.33.101/%$YEAR%-%$MONTH%-%$DAY%.log"
$template DeviceLog192,"/home/remote/device-10.10.33.192/%$YEAR%-%$MONTH%-%$DAY%.log"
$template RemoteLogs,"/home/remote/%fromhost-ip%/%$YEAR%-%$MONTH%-%$DAY%.log"
# 匹配 71
if $msg contains ',"device":"10.10.33.71"' then ?DeviceLog71
& stop
if $msg contains ',"device":"10.10.33.192"' then ?DeviceLog192
& stop
# 匹配 101
if $msg contains ',"device":"10.10.33.101"' then ?DeviceLog101
& stop

笔者接入syslog遇到两种情况

1、各类设备直接配置syslog到此台linux服务器，此类场景通过上面这条配置文件，即可实现自动创建以设备源IP命名的文件夹，文件名称是时间，

$template RemoteLogs,"/home/remote/%fromhost-ip%/%$YEAR%-%$MONTH%-%$DAY%.log"

2、我目前的环境存在两种特殊情况，一种是某些设备只支持配置一个syslog服务器，为应对等保要求，已经将日志发送到了日志审计设备。此时我通过日志审计设备的日志转发功能，转发到了此台linux服务器，但是多种不同设备通过日志审计转发时，来源IP都是日志审计设备的，此时通过

if $msg contains ',"device":"10.10.33.71"' then ?DeviceLog71

匹配关键字的实现将不同设备的日志存到不同文件夹。（我在用的日志审计设备转发日志时，可以添加device自带标记真实源IP），第二种情况是某台服务器上可能部署了nginx等中间件日志，同时其操作系统日志也需要发给日志接收服务器，在日志中找出可以区分出的关键字后，也可以通过contains区分，实现同一服务器IP发出的nginx日志到nginx目录，服务器底层日志到其他指定目录，便于AI的分析。

对于没有日志审计设备的用户，利用此方式也变相的相当于有了日志审计设备，如果担心存储容量问题，也可以在系统写脚本，定时删除多长时间之前的日志文件。

对于flocks如何读到日志文件，笔者比较懒，直接将flocks装到了此台日志接收服务器上，与其对话或在做工作流时，直接告诉flocks哪个目录的哪个文件，是什么类型的设备即可，相对比较方便。如果flocks与日志服务器是独立部署的，日志服务器只需要提供一个接口给flocks即可，比如提供nas接口，flocks直接挂载日志服务器的日志文件目录到本地，或者告诉flocks日志服务器的ssh密码，让flocks通过sftp去读取日志等。

综上，通过linux系统自带的rsyslog服务，实现syslog日志接入与分类，让flocks更便捷的拿到日志原文去分析。

思路二：使用flocks自带的syslog接入功能

笔者在刚接触flocks时，flocks并没有支持syslog接入，因此笔者才使用了上述思路解决日志接入问题，但是26年5月19日，flocks正式支持了syslog接入，为开发者快速迭代与积极聆听用户需求点赞。笔者没有深度使用此功能，初步的了解是syslog需要在工作流接入，默认情况下数据并不落地，当然也可以存储在持久化存储中，需要明确告知flocks去处理，同时其写入持久化存储更为强大，除了写入到文件中，也支持写入到数据库中。

常见系统采集方式

linux系统采集，可以使用自带的rsyslog将系统日志或指定路径的日志发送给日志服务器，或者也可以使用nxlog等工具采集。

windows系统采集，windows系统默认不支持syslog的转发，一般依赖第三方工具实现，常见工具用nxlog、winlogbeat等，据说目前出了一个新工具叫winlogagent，非常好用，guihub目录是youxia029/WinLogAgent，大家可自行测试。

中间件与数据库日志。主流中间件与数据库是支持syslog外发的，如果嫌配置麻烦，也可以使用上述linux/windows的采集工具，直接将中间件或数据库的日志目录转发到日志服务器。

各类商业安全设备基本都支持syslog。

日志接入后常见分析效果

日志接入后的常见效果，在实现各类日志接入到flocks后，能实现哪些效果呢，我个人目前在用的有如下几种。

1、操作系统类。linux与windows系统日志接入到flocks后，可以快速定位账号爆破类安全事件，同时可以快速溯源。例如笔者的工作环境是有AD域控环境的，经常遇到用户锁定问题，需要查原因。在接入flocks后，排查效率大幅提升。同时，在智能体分析日志时，可以配合自动告警的skill，实现用户锁定时自动化告警到企业微信、钉钉、邮箱等，快速发现问题。

2、网络安全设备类。对于此类网络日志，常规做法就是降噪分析，挖掘需要关注的重点安全事件，对现有的告警分析是误报还是真实攻击，如果是真实攻击自动化联动API处置同时自动化告警等，对比传统的SORA流程，主要是多了AI研判吧。

3、蜜罐钓鱼。笔者在不同区域部署了蜜罐服务器，比如用linux内置的python直接监听一个http服务，通过把access日志发送给flocks，一旦发现access日志有任何访问，直接自动化告警并触发联动封锁，调用防火墙API去封锁源IP。

4、中间件日志类。正常来说，到达业务中间件的请求，都是经过了IPS、WAF过滤后的，理论上攻击记录相对较少。利用一些插件，记录下http原始的请求与相应报文，让flocks去补充分析有无恶意请求，相当于在常规的网络安全设备拦截后，再对每一次请求再进行分析，是否有漏报，对于明确恶意的访问者，联动防火墙自动化封禁IP。一般WEB中间件的access.log只记录URL + 状态码 + 头信息等，并不会记录请求体，需要记录的话往往要特殊配置，flocks拿到的越多，能够分析的也就越多。

注：此方案仅适用于中小型场景下的特殊操作，不一定适用于常规场景，仅供参考。