★ FEATURED ARTICLE 简介这份资源围绕 ip-guard 网络监控与管理工具展开面向企业 IT 运维、网络管理员以及需要部署终端行为审计与上网行为管理的技术人员帮助解决内网监控、权限管控与员工上网行为记录等实际问题。压缩包为 rar 格式整体约 33.39MB包内文件数量与具体类型上游未提供明细故不展开说明。资源标题标注为 406 用户版本作者自述已使用一年说明其在真实环境中经过一定周期验证对想了解该工具部署与使用思路的读者具备参考意义。目前已有 1407 人浏览学习属于同类工具资源中关注度较高的内容。读者可借助该资源了解 ip-guard 在终端监控、网络行为管理方面的功能定位与配置方向结合自身企业网络规模评估适用性并作为搭建内网监控体系的入门参考适合具备一定网络基础、希望快速上手管理利器的运维人员查阅。1. 从一次内网排查说起为什么我又把 ip-guard 翻了出来去年帮一个朋友处理他们内部网络的异常外联问题当时手头没有现成的流量审计工具临时装了一套开源方案结果在终端行为采集这一层卡了整整两天——进程链抓不全、屏幕操作录不到、U盘拷贝记录缺失。后来一个做企业IT运维的老哥丢给我一份 ip-guard 的部署包说你先拿这个把底摸清楚。装完跑了一周终端侧的行为日志颗粒度确实比我之前那套拼凑方案细得多尤其是文档操作和即时通讯内容的留存基本能做到事后可回溯。这次经历让我意识到ip-guard 这类网络监控与管理工具在中小规模内网里依然有它不可替代的位置。但网上关于它的资料要么是厂商白皮书式的功能罗列要么是零散的破解讨论真正从部署、配置到日常运维的完整记录很少。这篇内容不聊破解只聊我在实际环境里怎么把它跑起来、哪些参数值得调、哪些坑我踩过。如果你正在做内网行为管理选型或者手头已经有一套 ip-guard 但只用到了皮毛下面这些记录应该能帮你省掉不少试错时间。2. 部署前想清楚ip-guard 到底管什么、不管什么2.1 它的能力边界在哪里很多人第一次接触 ip-guard会把它当成一个单纯的“监控软件”这个理解太窄了。从我这几次部署的经验看它实际覆盖的是终端行为管理 网络准入 文档加密三条线。终端行为管理包括进程记录、窗口标题采集、屏幕快照、文件操作审计、打印记录、即时通讯内容留存网络准入控制的是终端能不能连内网、能不能访问外网、能访问哪些网段文档加密则是对指定后缀的文件做透明加解密离开授权环境就打不开。但它的短板也很明显。第一对加密流量的解析能力有限如果内网大量使用 HTTPS 且没有做证书中间人内容层面的审计会打折扣。第二服务端性能对数据库依赖很重SQL Server 的版本和索引优化直接影响控制台响应速度。第三客户端对操作系统的兼容性在不同版本间有差异老版本 Windows 和最新版 Windows 11 的驱动签名策略经常打架。我一般会这么判断如果你需要的是“谁在什么时候动了什么文件、发了什么消息、插了什么U盘”ip-guard 能覆盖如果你要的是“深度包检测 应用层协议识别”那它不如专业的 NDR 或全流量审计设备。2.2 部署架构的三种常见形态实际落地时ip-guard 的部署架构大致分三种。第一种是单服务器全量部署服务端、数据库、控制台全在一台机器上适合 200 终端以内的场景。第二种是服务端与数据库分离数据库单独一台服务端只跑应用适合 500 终端左右。第三种是多级级联总部一套主服务端分支机构各跑一套从服务端数据定时回传适合跨地域的中大型内网。我这次跑的是第二种服务端 Windows Server 2019数据库 SQL Server 2017终端数峰值 380 左右。选这个架构的原因很简单控制台查询日志时数据库 IO 是瓶颈分离之后查询响应从平均 4 秒降到了 1 秒以内。2.3 授权与用户数的关系标题里提到的“406用户”这个数字我理解是指授权终端数。ip-guard 的授权模式是按终端点数算的服务端不限制管理账号数量但每个被管理的终端都要占一个授权。实际部署时要注意授权文件导入后控制台显示的“已授权点数”和“已注册终端数”是两个概念。已注册终端数可以超过授权点数但超出的终端会进入“未授权”状态策略不生效。我遇到过一种情况测试阶段反复重装客户端导致服务端里残留了大量重复的终端记录占用了授权点数。解决办法是在控制台里先删除无效终端记录再重新注册。这个操作在“终端管理”里做删除时勾选“同时删除该终端的日志”否则数据库会越跑越大。3. 服务端与数据库配置几个影响性能的关键参数3.1 数据库连接池与超时设置ip-guard 服务端和 SQL Server 之间的连接池配置直接决定了高并发时控制台会不会卡死。默认安装后连接池最大连接数通常是 100超时 30 秒。在 300 终端以上的环境里这个值偏小。我一般会调到 300 连接、超时 60 秒。调整位置在服务端安装目录下的ServerConfig.xml找到Database节点Database MaxPoolSize300/MaxPoolSize ConnectionTimeout60/ConnectionTimeout CommandTimeout120/CommandTimeout /DatabaseMaxPoolSize控制同时打开的数据库连接上限ConnectionTimeout是建立连接的超时秒数CommandTimeout是单条 SQL 执行的超时。改完重启服务端服务生效。注意不要盲目调太大SQL Server 的max worker threads默认是 0自动如果连接数超过 CPU 核心数的几十倍反而会因上下文切换导致性能下降。3.2 日志分区与清理策略ip-guard 的日志表增长非常快。一个 300 终端的环境如果开启了屏幕快照和即时通讯内容留存数据库每天增量在 2GB 到 5GB 之间。如果不做分区和清理三个月后查询就会明显变慢。我的做法是两步。第一步在 SQL Server 里对日志主表按周做分区分区函数按LogTime字段切分。第二步在 ip-guard 控制台的“系统设置”里开启自动清理保留周期设为 90 天。注意自动清理任务默认是每天凌晨 2 点执行如果数据库压力大可以改成每周一次但保留周期要相应缩短。-- 查看当前日志表大小和行数 SELECT t.name AS TableName, p.rows AS RowCounts, SUM(a.total_pages) * 8 / 1024 AS TotalSpaceMB FROM sys.tables t INNER JOIN sys.indexes i ON t.object_id i.object_id INNER JOIN sys.partitions p ON i.object_id p.object_id AND i.index_id p.index_id INNER JOIN sys.allocation_units a ON p.partition_id a.container_id WHERE t.name LIKE %Log% GROUP BY t.name, p.rows ORDER BY TotalSpaceMB DESC;这段 SQL 用来定位哪些日志表占用空间最大。通常AgentLog、ScreenLog、IMLog这三张表是增长主力。如果ScreenLog过大可以考虑降低屏幕快照的采集频率从默认的 5 分钟一次改成 15 分钟一次。3.3 控制台访问的权限模型ip-guard 控制台的权限分三级超级管理员、策略管理员、审计员。超级管理员什么都能改策略管理员只能改策略不能看日志审计员只能看日志不能改策略。实际使用时建议给日常运维人员只开审计员权限策略变更走审批流程。我见过一个翻车案例某公司把超级管理员账号给了三个运维结果其中一个人误删了一条全局策略导致所有终端的U盘管控失效第二天才发现。后来他们改成策略管理员只能提交变更申请超级管理员审批后才生效。这个流程在控制台的“权限管理”里配置支持对接 LDAP 做统一认证。4. 客户端策略配置从进程审计到文档加密的实操4.1 进程与窗口标题采集的粒度控制客户端策略里最常用的是进程审计。ip-guard 默认会记录所有进程的启动和退出但窗口标题采集默认是关闭的。开启后每个进程的窗口标题变化都会产生一条日志数据量会翻倍。我的建议是只对敏感进程开启窗口标题采集。比如财务软件、代码编辑器、即时通讯工具其他如浏览器、系统进程只记录进程名和路径即可。配置路径在“策略模板” - “进程审计” - “高级设置”里可以按进程名做白名单。; 进程审计白名单示例只采集以下进程的窗口标题 [WindowTitleCapture] ProcessListfinapp.exe,code.exe,wechat.exe,dingtalk.exe CaptureInterval30CaptureInterval是窗口标题的采集间隔秒数默认 10 秒调到 30 秒可以降低日志量。注意这个配置是客户端本地的服务端下发策略后会覆盖所以要在服务端策略里改。4.2 文档透明加密的密钥管理文档加密是 ip-guard 里最敏感的功能。开启后指定后缀的文件在授权进程里打开是明文在非授权进程里打开是密文。密钥存在服务端的数据库里客户端启动时从服务端拉取。这里有一个血泪经验密钥备份一定要做而且要在开启加密之前做。我遇到过服务端数据库损坏导致密钥丢失的情况结果所有加密文档都打不开了。后来每次部署我都会在开启加密前先导出一份密钥文件存在离线介质里。导出方式在控制台的“文档加密” - “密钥管理” - “导出密钥”导出的文件是加密的需要设置一个保护密码。这个密码和密钥文件要分开存放否则一起丢了就真没后悔药了。4.3 网络准入与例外名单网络准入控制的是终端能不能上网、能访问哪些IP。默认策略是“禁止所有外网访问只允许内网指定网段”。实际配置时例外名单比黑名单更常用。比如研发部门需要访问代码托管平台但不想让他们访问视频网站。做法是先建一个“研发例外”策略组在“网络控制”里添加允许访问的域名和IP段其他一律禁止。注意 ip-guard 的域名过滤是基于 DNS 解析结果的如果终端直接填 IP 访问域名策略不生效所以还要配合 IP 段过滤。# 查看客户端当前生效的网络策略在客户端安装目录下执行 AgentCLI.exe /querypolicy network # 输出示例 # PolicyName: RD_Exception # AllowDomains: git.internal.com, repo.internal.com # AllowIPs: 10.10.0.0/16, 172.16.1.0/24 # DefaultAction: Block这个命令在客户端本地执行用来确认策略是否下发成功。如果输出为空说明客户端没有连上服务端需要检查客户端的“服务端地址”配置和网络连通性。5. 避坑记录这五个问题我踩过你不用再踩5.1 客户端安装后蓝屏或反复重启现象在部分 Windows 10 机器上安装客户端后系统蓝屏错误码DRIVER_IRQL_NOT_LESS_OR_EQUAL重启后进入恢复模式。原因客户端的文件过滤驱动和某些安全软件如某杀毒软件的主动防御模块冲突或者和 Windows 自带的Filter Manager版本不匹配。解决先在安全模式下卸载冲突的安全软件再安装 ip-guard 客户端。如果已经蓝屏用 Windows 安装U盘启动进入修复模式删除C:\Windows\System32\drivers\下 ip-guard 的驱动文件通常以ipg开头然后正常启动后重新安装。安装前建议先打上最新的 Windows 累积更新驱动签名兼容性会好很多。5.2 控制台登录提示“数据库连接失败”现象服务端服务启动正常但控制台登录时提示数据库连接失败日志里报Login failed for user ipguard。原因SQL Server 的认证模式是“仅 Windows 认证”而 ip-guard 用的是 SQL 账号认证。或者 SQL Server 的 TCP/IP 协议没启用。解决在 SQL Server 配置管理器里把协议中的 TCP/IP 启用端口保持 1433。然后在 SSMS 里把服务器认证模式改成“SQL Server 和 Windows 身份验证模式”重启 SQL Server 服务。最后确认 ip-guard 使用的数据库账号有db_owner权限。5.3 屏幕快照日志占满磁盘现象服务端磁盘空间告警检查发现ScreenLog表所在的数据文件已经 200GB。原因屏幕快照默认每 5 分钟一次且默认保留 180 天。300 终端的环境下一天就能产生几万张图片。解决两步走。第一步在控制台把屏幕快照频率改成 15 分钟保留周期改成 30 天。第二步在 SQL Server 里对ScreenLog表做分区把历史分区切到单独的磁盘。如果已经占满先手动清理 90 天前的记录再收缩数据库文件。-- 清理 90 天前的屏幕快照记录分批执行避免锁表 WHILE 1 1 BEGIN DELETE TOP (10000) FROM ScreenLog WHERE LogTime DATEADD(DAY, -90, GETDATE()); IF ROWCOUNT 10000 BREAK; WAITFOR DELAY 00:00:01; END分批删除是为了避免一次性删除大量数据导致事务日志暴涨和锁表。WAITFOR DELAY让每批之间停 1 秒给其他查询留出资源。5.4 客户端离线后策略不生效现象笔记本带出公司后U盘管控策略失效可以随意拷贝文件。原因ip-guard 的默认策略是“在线生效”客户端连不上服务端时策略回退到“全部允许”。解决在策略模板里开启“离线策略”设置离线有效期比如 7 天。离线期间客户端使用本地缓存的策略U盘管控和文档加密继续生效。超过有效期后客户端锁定需要连回服务端才能解锁。这个配置在“策略模板” - “高级设置” - “离线策略”里。5.5 数据库备份恢复后日志丢失现象服务端数据库崩溃后从备份恢复发现恢复点之后的所有日志都没了。原因SQL Server 的恢复模式是“简单”只支持完整备份不支持事务日志备份。ip-guard 的日志写入是实时的简单模式下备份间隔内的数据会丢失。解决把数据库恢复模式改成“完整”然后配置每日完整备份 每 15 分钟事务日志备份。这样最多丢 15 分钟的数据。注意事务日志文件会持续增长需要定期做日志截断。-- 查看当前恢复模式 SELECT name, recovery_model_desc FROM sys.databases WHERE name ipguard; -- 改成完整恢复模式 ALTER DATABASE ipguard SET RECOVERY FULL; -- 做一次完整备份路径按实际改 BACKUP DATABASE ipguard TO DISK D:\Backup\ipguard_full.bak WITH INIT; -- 做一次事务日志备份 BACKUP LOG ipguard TO DISK D:\Backup\ipguard_log.trn WITH INIT;改完恢复模式后必须做一次完整备份否则事务日志备份会失败。之后用 SQL Server 代理作业定时执行这两条命令即可。6. 回到那个 406 用户的场景我的最终配置清单和一条硬习惯那个 380 终端的环境跑稳之后我把整套配置整理成了一份清单。服务端 Windows Server 2019SQL Server 2017 分离部署连接池 300、超时 60 秒日志保留 90 天、屏幕快照 15 分钟一次文档加密密钥离线备份两份网络准入按部门分策略组。客户端统一用静默安装包推送安装前先卸载冲突安全软件安装后重启一次再注册。这套配置跑了一年多控制台查询响应稳定在 1 秒左右数据库月增量控制在 60GB 以内没有出现过蓝屏或策略失效的批量故障。中间有一次服务端磁盘告警靠分区切换和分批清理扛过去了没有影响终端使用。回过头看ip-guard 这类工具的价值不在于功能有多花哨而在于策略能不能稳定执行、日志能不能可靠回溯。我现在的习惯是每次开启一个新策略之前先在一台测试终端上跑 48 小时确认没有兼容性问题再批量下发。这个习惯帮我避开了至少三次可能的批量故障。另外密钥备份和数据库完整备份这两件事我强制自己在上线前必须做完不做完不开加密功能。希望这些记录能帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
