简介：本资源是深信服终端安全管理系统EDR（Endpoint Detection and Response）的官方用户手册PDF文档，面向企业安全运维人员、终端安全管理员及等保合规实施工程师，用于系统部署、日常管理与威胁响应能力建设。手册内容覆盖产品概述、核心功能（实时监控、威胁检测、事件响应、终端资产管理）、首次上线全流程（含管理端/客户端环境准备、网络连通性要求、白名单收集、部署激活）及详细操作指南，并附有危险/警告/注意等安全操作标识说明和规范符号图例，便于快速定位关键配置与风险规避要点。资源为单文件PDF格式，体积98.99MB，结构完整，含目录、版本声明、版权声明及官方技术支持渠道信息。目前已有776人学习下载，是掌握深信服EDR系统从零部署到实战响应的权威参考依据。

1. 别急着点“安装”，先看清这版EDR手册的隐藏门槛：3.7.2不是万能钥匙，装错环境直接卡在激活页

你是不是也经历过——下载了《深信服终端安全管理系统EDR用户手册-398》，兴冲冲打开“2.2 管理端部署”章节，照着步骤解压ISO、运行setup.sh，结果卡在“License校验失败”或“数据库连接超时”？我帮某高校实验室部署EDR时就栽过这个坑：他们用CentOS 7.9最小化安装+MySQL 8.0.33，管理端界面能起来，但所有策略下发全失败，日志里反复报[ERROR] failed to init policy engine: invalid db schema version。翻遍手册第3.2.1节才发现，3.7.2版本管理端明确要求MySQL 5.7.x（仅支持5.7.16–5.7.39），且必须关闭strict mode——而新版MySQL默认开启。这不是玄学，是手册里白纸黑字写在“3.1.1 管理端安装环境”表格底部的一行小字：“数据库兼容性以实际测试为准，推荐使用随包提供的MySQL 5.7.28镜像”。这份手册不是操作指南，它是一份带版本锁链的部署契约：从硬件配置、内核参数、SELinux状态到Java Runtime版本，漏掉任意一环，后续所有“威胁狩猎”“微隔离”功能都会变成黑匣子。适合谁？适合正在为等保2.0三级系统做终端安全加固的运维工程师、需要批量部署EDR Agent的IT管理员，以及接手遗留EDR集群做升级迁移的二线支持人员——如果你只是想看看“勒索防护怎么配”，建议直接跳到4.3.4节；但如果你想让整套系统真正跑起来，这篇笔记就是你该先读的“防翻车说明书”。

2. 环境准备：不是列个清单就完事，得把每个依赖项拧到手册要求的扭矩值

2.1 管理端硬件与系统环境：别被“支持国产化”误导，x86和ARM要分两套逻辑

手册第3.1.1节表格看似简单，但藏着三个关键陷阱。第一，“CPU ≥ 8核”不等于“随便8核就行”——实测发现，当使用Intel Xeon E5-2620 v3（12核24线程）时，若未在BIOS中启用Intel VT-x和Intel EPT，管理端Web服务会间歇性502；第二，“内存 ≥ 32GB”是硬门槛，但手册没明说JVM堆内存必须手动调至16G以上，否则启动后30分钟内必然OOM；第三，“国产化终端部署”在手册里单列一节（3.4.4），但管理端对国产OS的支持其实是单向适配：你可以在麒麟V10 SP1上部署管理端（需额外安装openjdk-11-jre-headless），但该管理端无法向统信UOS V20 2103之后的终端下发Agent，因为签名机制不兼容。

提示：手册中“管理端安装环境”表格第4行“操作系统”列写的“CentOS 7.6/7.9、Ubuntu 18.04/20.04、麒麟V10 SP1”是最低兼容列表，不是推荐列表。我们团队实测下来，最稳组合是CentOS 7.9（内核3.10.0-1160.118.1.el7.x86_64）+ MySQL 5.7.28 + OpenJDK 1.8.0_362-b09。Ubuntu系因systemd服务管理差异，常出现edr-mgr.service状态为activating (start)却无进程。

验证命令：

# 检查CPU虚拟化是否启用（必须返回非空） grep -E "(vmx|svm)" /proc/cpuinfo # 检查内核参数（手册3.1.1要求net.core.somaxconn=65535） sysctl net.core.somaxconn # 检查SELinux状态（手册明确要求disabled，不是permissive） getenforce # 检查Java版本（必须是OpenJDK 1.8，Oracle JDK 1.8会触发证书链异常） java -version | grep "openjdk version"

2.2 客户端部署环境：Windows组策略和Linux内核模块才是真战场

手册2.6.1节讲Windows部署，但没告诉你域环境下GPO推送Agent.msi时，必须禁用“始终以提升的权限安装”策略，否则普通域用户登录后Agent服务无法自启（现象：服务存在但状态为“已暂停”）。Linux部分更隐蔽：手册3.4.2节说“支持CentOS 7/8、Ubuntu 16.04/18.04/20.04”，但实际测试发现，Ubuntu 20.04内核5.4.0-150-generic下，EDR Agent的kprobe模块加载失败，报错insmod: ERROR: could not insert module /opt/sangfor/edr/agent/kernel/edr_kprobe.ko: Invalid module format——原因是内核头文件版本不匹配。解决方案不是重装内核，而是在安装Agent前执行apt install linux-headers-$(uname -r)并重启。

国产化终端部署（3.4.4节）有个致命细节：手册说“支持统信UOS V20、麒麟V10”，但仅指x86_64架构。我们在飞腾D2000平台（ARM64）上部署时，Agent安装脚本install.sh直接退出，日志显示unsupported architecture: aarch64。翻源码发现，3.7.2版Agent的install.sh里硬编码了ARCH=x86_64判断，ARM64支持实际要等到3.8.0+版本。

2.3 网络连通性：不是“能ping通就行”，得按手册画出三张流量图

手册2.1.3节的网络要求看着简单，但实操中90%的部署失败源于这里。它要求管理端与终端间开放TCP 443/54321/54322端口，但没说明54321是Agent主动回连端口，54322是管理端下发指令端口。这意味着：如果终端在NAT后，必须在防火墙上做DNAT将54321映射到管理端；如果管理端在云上，安全组必须放行54322入方向。更关键的是时间同步——手册只在4.8.3节“系统设置”里提了一句“确保NTP服务正常”，但没强调：终端与管理端时间差超过3分钟，Agent认证直接失败，现象是终端列表里显示“离线”，但ping和telnet 54321都通。

我们画了三张必验流量图：

• 管理端出向：必须能访问https://update.sangfor.com.cn（固件升级）、https://license.sangfor.com.cn（授权校验），DNS解析需指向公网IP（不能走内网DNS缓存）
• 终端入向：终端防火墙必须放行UDP 123（NTP）、TCP 443（HTTPS控制通道）、TCP 54321（心跳回连）
• 级联场景：上级管理端访问下级管理端的https://<ip>:443/api/v1/sync，且下级管理端的/etc/hosts里必须有上级管理端域名解析（手册3.2.3节埋的雷）

验证命令：

# 终端侧检查时间偏差（必须≤180秒） ntpdate -q update.sangfor.com.cn | awk '{print $NF}' | sed 's/[^0-9.-]//g' # 管理端侧检查对外连通性（手册要求的两个关键域名） curl -I --connect-timeout 5 https://update.sangfor.com.cn 2>/dev/null | head -1 curl -I --connect-timeout 5 https://license.sangfor.com.cn 2>/dev/null | head -1 # 终端侧检查54321端口是否可被管理端访问（反向验证） telnet <mgr_ip> 54321 # 应返回Connected

3. 管理端部署：从ISO解压到服务启动，每一步都有手册没写的“后悔药”

3.1 软件管理端安装：别跳过precheck.sh，它比setup.sh更关键

手册3.2.1节说“运行setup.sh即可”，但setup.sh只是个外壳。真正决定成败的是同目录下的precheck.sh——它检查17项环境指标，其中3项不通过会直接终止安装：/opt/sangfor分区剩余空间≥50GB、/var/log挂载点inode使用率＜85%、ulimit -n≥65535。我们曾遇到一次失败：precheck.sh报[WARN] /opt/sangfor space usage: 92%，但df -h显示只有68%，后来发现是/opt/sangfor挂载在LVM逻辑卷上，precheck.sh用的是df -i查inode而非df -h查空间。解决方法：lvextend -l +100%FREE /dev/mapper/vg01-lv_opt && resize2fs /dev/mapper/vg01-lv_opt。

安装命令必须带参数，手册没写但实测必需：

# 必须指定数据库类型和路径，否则默认用嵌入式H2（仅限测试） ./setup.sh --db-type mysql --db-host 127.0.0.1 --db-port 3306 \ --db-name edr_mgr --db-user root --db-pass 'YourPass123!' \ --java-home /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-1.el7_9.x86_64 # 关键参数说明： # --db-type mysql：强制使用外部MySQL，避免H2在生产环境崩溃 # --java-home：必须指向OpenJDK 1.8路径，否则启动报NoClassDefFoundError # --db-pass：密码必须含特殊字符且长度≥8，否则MySQL连接失败

3.2 硬件管理端部署：物理设备不是插电就行，得改固件里的“信任根”

手册3.2.2节描述硬件设备开箱即用，但实际交付的硬件管理端（如SFA-2200型号）出厂固件是3.6.0，必须先升级到3.7.2才能激活销售授权。升级过程有两个坑：第一，升级包.bin文件必须放在U盘根目录，且U盘格式必须是FAT32（NTFS会被忽略）；第二，升级中设备会重启两次，第二次重启后需等待至少8分钟才能访问Web界面，因为后台在初始化Elasticsearch索引（手册没提，但日志/var/log/elasticsearch/edr-es.log会持续写入initializing index...）。

注意：硬件管理端的“产品激活”（3.3节）和软件管理端不同——它需要扫描设备背面的SN码二维码，然后在https://license.sangfor.com.cn手动绑定。如果扫完码提示“SN码无效”，大概率是设备固件版本低于3.7.2，必须先升级固件再激活。

3.3 级联部署：不是配个IP就联动，得在证书链里埋“信任锚”

手册3.2.3节的级联配置看似简单，但核心在证书。上级管理端导出的ca.crt必须手动导入下级管理端的Java信任库，否则/opt/sangfor/edr/mgr/conf/ssl/truststore.jks会拒绝建立TLS连接。命令如下：

# 在下级管理端执行（假设上级CA证书已上传到/tmp/ca.crt） keytool -import -trustcacerts -file /tmp/ca.crt -alias sangfor-ca \ -keystore /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-1.el7_9.x86_64/jre/lib/security/cacerts \ -storepass changeit -noprompt # 验证是否导入成功 keytool -list -v -keystore /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-1.el7_9.x86_64/jre/lib/security/cacerts \ -storepass changeit | grep "sangfor-ca"

级联后常见问题：下级终端在上级管理端显示“离线”。排查顺序必须是：1）检查下级管理端/opt/sangfor/edr/mgr/logs/mgr.log是否有Failed to sync terminal list；2）在上级管理端执行curl -k https://<lower_mgr_ip>:443/api/v1/sync/status看返回；3）确认下级管理端的/opt/sangfor/edr/mgr/conf/cluster.conf中upstream_url末尾不能带斜杠（手册示例有误，写成https://192.168.1.100/会导致404）。

4. 授权激活与策略配置：销售授权不是“输入密钥”，而是重建信任链

4.1 销售授权激活：密钥只是“入场券”，真正的授权在数据库里

手册3.3.1节说“输入授权码完成激活”，但实际流程是：输入密钥 → 后台调用https://license.sangfor.com.cn/api/v1/activate→ 返回license_token→ 写入MySQLedr_mgr.license_info表 → 重启edr-mgr服务。如果卡在“激活中”，90%是网络问题。但我们遇到过一次诡异情况：curl -X POST https://license.sangfor.com.cn/api/v1/activate返回{"code":200,"msg":"success"}，但数据库里license_info表仍是空的。查日志发现mgr.log有[ERROR] failed to save license token: duplicate key——原来之前试用授权没清理干净，license_info表里残留了status=0的旧记录。解决方案是手动清库：

-- 连接MySQL执行（谨慎！） USE edr_mgr; DELETE FROM license_info WHERE status = 0 OR create_time < DATE_SUB(NOW(), INTERVAL 7 DAY); -- 然后重启服务 systemctl restart edr-mgr

4.2 白名单策略配置：不是加个路径就信任，得理解“进程树签名链”

手册2.5.1节的白名单配置，新手常犯的错是只填C:\Program Files\WeChat\WeChat.exe，结果微信更新后仍被拦截。因为EDR的白名单是基于代码签名验证，不是路径匹配。正确做法是：在“信任名单”→“进程白名单”里，点击“添加”→选择“签名哈希”→上传微信安装包里的WeChat.exe，系统自动提取SHA256哈希值。更稳妥的是用“签名颁发者”模式，填Tencent Technology (Shenzhen) Company Limited——这样微信所有子进程（如WeChatAppEx.exe）都受信任。

提示：国产化终端白名单必须用“绝对路径+签名哈希”，因为国产OS的签名机制（如麒麟的KMS）和Windows不同，用“颁发者”模式会失效。

4.3 安全策略配置：实时防护的“开关”藏在三个地方

手册2.5.2节的安全策略，表面看是勾选框，实则有三层控制：

• 全局开关：系统设置→安全通用配置→启用实时防护（必须开启，否则所有子策略无效）
• 进程级开关：病毒查杀→实时防护→监控进程行为（控制进程注入、内存马检测）
• 网络级开关：微隔离→网络防护→启用网络连接监控（控制横向移动检测）

我们曾遇到客户反馈“勒索防护不生效”，查到最后发现是第三层开关没开——因为微隔离模块默认关闭，而勒索防护依赖其网络连接分析能力。手册4.3.4节没明说这个依赖关系，属于隐性耦合。

5. 常见问题排查：血泪经验总结的5条“踩坑实录”，每条都救过火

5.1 现象：管理端Web界面能打开，但所有菜单点击后空白，F12看Network全是404

原因：/opt/sangfor/edr/mgr/webapps/ROOT目录权限错误。手册没提，但3.7.2版要求该目录属主为root:edr，且webapps目录权限必须是755，ROOT目录下js/和css/子目录必须是644。若用chmod -R 777粗暴赋权，Tomcat会拒绝加载静态资源。
解决：

chown -R root:edr /opt/sangfor/edr/mgr/webapps/ROOT chmod 755 /opt/sangfor/edr/mgr/webapps chmod 644 /opt/sangfor/edr/mgr/webapps/ROOT/js/* /opt/sangfor/edr/mgr/webapps/ROOT/css/* systemctl restart edr-mgr

5.2 现象：终端Agent安装成功，但在管理端显示“离线”，且/opt/sangfor/edr/agent/logs/agent.log里有[ERROR] connect to manager failed: Connection refused

原因：管理端的edr-mgr服务虽运行，但nginx反向代理未启动。手册3.2.1节没提nginx是独立服务，实际/opt/sangfor/edr/mgr/nginx/sbin/nginx必须手动启动，且/opt/sangfor/edr/mgr/nginx/conf/nginx.conf里proxy_pass必须指向http://127.0.0.1:8080（Tomcat端口）。
解决：

/opt/sangfor/edr/mgr/nginx/sbin/nginx -c /opt/sangfor/edr/mgr/nginx/conf/nginx.conf # 验证nginx是否监听443 netstat -tlnp | grep :443

5.3 现象：Linux终端部署Agent后，systemctl status edr-agent显示active，但ps aux | grep edr看不到进程

原因：Agent的edr_agent二进制文件被SELinux阻止执行。手册3.1.2节要求“关闭SELinux”，但很多生产环境设为permissive，此时Agent能启动但立即被setroubleshoot杀死。
解决：

# 查看SELinux拒绝日志 ausearch -m avc -ts recent | grep edr # 临时放行（生产环境应生成策略） setsebool -P antivirus_can_scan_system 1 # 或永久关闭（手册要求） sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config reboot

5.4 现象：Windows终端Agent安装后，任务管理器里edr_agent.exe进程CPU占用100%，事件查看器报Application Error: edr_agent.exe

原因：Windows Defender实时防护与EDR Agent冲突。手册2.6.1节没提，但实测Win10 21H2+版本中，Defender的Antimalware Service Executable会劫持EDR的API Hook。
解决：

# 以管理员身份运行PowerShell Add-MpPreference -ExclusionProcess "C:\Program Files\Sangfor\EDR\agent\edr_agent.exe" Restart-Service WinDefend

5.5 现象：国产化终端（麒麟V10 SP1）部署Agent后，journalctl -u edr-agent显示[ERROR] failed to load kernel module: Operation not permitted

原因：麒麟OS的secure boot启用状态下，EDR的edr_kprobe.ko内核模块未签名，被内核拒绝加载。手册3.4.4节完全没提Secure Boot。
解决：

# 临时禁用（重启后恢复） mokutil --disable-validation # 或永久禁用（需重启进MOK管理界面确认） echo "options efivar_ssdt disable=1" > /etc/modprobe.d/efivar.conf update-initramfs -u reboot

6. 验证部署是否真正跑通：用三组命令+一个真实场景，拒绝“页面能开就等于成功”

6.1 基础服务连通性验证：不只是端口通，要看服务心跳

管理端部署完成后，不能只满足于浏览器打开https://<mgr_ip>。必须执行这组命令，每一条都对应手册里一个关键模块：

# 1. 验证数据库连接（手册3.2.1核心依赖） mysql -uedr -p'YourPass123!' -h127.0.0.1 -P3306 -e "SELECT COUNT(*) FROM edr_mgr.terminal_info;" # 2. 验证Elasticsearch健康（手册4.7.1日志存储基础） curl -k -u admin:admin https://127.0.0.1:9200/_cluster/health?pretty | grep '"status"' | grep -E '"green"|\"yellow"' # 3. 验证Nginx反向代理（手册3.2.1隐藏依赖） curl -k -I https://127.0.0.1 | grep "HTTP/2 200" # 4. 验证Agent通信通道（手册2.6.1核心链路） curl -k https://127.0.0.1:443/api/v1/heartbeat -X POST -H "Content-Type: application/json" \ -d '{"terminal_id":"test-001","status":"online"}' | jq '.code' # 应返回{"code":200,"msg":"success"}

注意：第4条命令是模拟Agent心跳，如果返回{"code":500,"msg":"invalid request"}，说明nginx.conf里location /api/的proxy_pass没指向Tomcat，而是指向了错误端口。

6.2 终端Agent在线验证：不止看“在线”状态，要看进程树和网络连接

在已部署Agent的Windows终端上，执行以下PowerShell命令（需管理员权限）：

# 1. 检查EDR进程是否存在且未被杀毒软件拦截 Get-Process edr_agent -ErrorAction SilentlyContinue | Select-Object Id, ProcessName, Path # 2. 检查EDR服务状态（手册4.9.1要求） Get-Service SangforEDRAgent | Select-Object Status, Name, StartType # 3. 检查EDR网络连接（必须连管理端54321端口） Get-NetTCPConnection -LocalPort 54321 -State Established | Select-Object LocalAddress, RemoteAddress, State, AppliedSetting # 4. 检查EDR驱动加载（关键！手册4.9.1没提但决定防护能力） Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceName -like "*Sangfor*"} | Select-Object DeviceName, DriverDate, DriverVersion, Signed

在Linux终端上，对应命令是：

# 1. 检查Agent进程和父进程（必须是systemd） ps auxf | grep edr_agent | grep -v grep # 2. 检查内核模块（手册3.4.2核心） lsmod | grep edr_kprobe # 3. 检查网络连接（必须ESTABLISHED） ss -tnp | grep :54321 | grep ESTAB # 4. 检查SELinux上下文（手册3.1.2隐性要求） ls -Z /opt/sangfor/edr/agent/bin/edr_agent # 应返回 system_u:object_r:bin_t:s0

6.3 真实场景压力验证：用“勒索防护”功能反向证明整套系统可用

手册4.3.4节的勒索防护配置，是检验部署质量的终极考题。我们设计了一个5分钟压力测试：

步骤1：在管理端创建勒索防护策略

• 进入策略配置→勒索防护→新建策略
• 名称填Test-Ransom-Protect，作用范围选全部终端
• 防护模式选严格模式，例外进程留空
• 文件保护目录添加C:\TestRansom\（Windows）或/home/test/ransom/（Linux）

步骤2：在终端创建测试目录并放文件

# Windows（管理员PowerShell） mkdir C:\TestRansom echo "safe file" > C:\TestRansom\safe.txt # Linux mkdir -p /home/test/ransom echo "safe file" > /home/test/ransom/safe.txt

步骤3：模拟勒索软件行为（手册没教但必须测）

# Windows：用PowerShell模拟加密（不会真加密，只触发EDR拦截） $files = Get-ChildItem C:\TestRansom\*.txt foreach($f in $files) { $content = Get-Content $f.FullName Set-Content "$f.FullName.locked" $content Remove-Item $f.FullName } # Linux：用shell模拟（同理） for f in /home/test/ransom/*.txt; do cp "$f" "${f}.locked" && rm "$f" done

步骤4：验证结果

• 管理端响应中心→威胁响应里应立即出现勒索软件攻击告警（5秒内）
• 终端上，被修改的文件应自动还原（safe.txt恢复，safe.txt.locked被删除）
• 终端管理→终端清点里，该终端状态应显示受保护（绿色图标）

如果告警延迟＞30秒，或文件未还原，说明：

• edr-mgr的threat-engine服务未启动（systemctl status edr-threat-engine）
• 或终端Agent的realtime_protection模块未加载（/opt/sangfor/edr/agent/logs/agent.log查load realtime module）

从那以后我每次部署EDR，都强制走一遍这个勒索防护压力测试——它比任何systemctl status都诚实。因为EDR不是静态软件，它是动态的防护引擎，只有在真实对抗中才能证明它活着、呼吸着、真正工作着。希望帮到你。

本文还有配套的精品资源，点击获取