1. 项目概述为什么我们需要关注RustDesk的会话记录如果你正在使用RustDesk进行远程支持或团队协作那么“谁在什么时候连接了哪台设备做了什么操作”这个问题迟早会摆在你面前。这不仅仅是技术问题更是安全合规和团队管理的核心需求。RustDesk作为一款开源的远程桌面软件其轻量、高性能和自托管的特性吸引了大量用户但默认配置下它更像一个“用完即走”的工具缺乏对操作行为的追溯能力。想象一下这样的场景作为IT管理员你为同事临时解决了一个紧急问题几天后系统出现异常需要回溯当时的操作或者在一个需要严格审计的行业每一次远程访问都必须有据可查。这时仅靠记忆或聊天记录是远远不够的。RustDesk本身提供了基础的连接日志但远未达到“操作记录与审计日志”的深度。所谓“会话记录”不仅仅是记录连接和断开的时间戳更应包含连接过程中的关键操作事件例如文件传输记录、远程命令执行、剪贴板同步内容脱敏后、甚至会话过程中的屏幕快照需谨慎合规。而“审计日志”则是在此基础上为这些记录赋予可查询、可分析、可告警的能力满足安全审计与事件调查的需求。近期关于RustDesk安全性的讨论也在增多例如网络热词中出现的“rustdesk禁止安装”、“rustdesk里的key不匹配”等都反映出用户对可控性和透明度的迫切需求。搭建自托管服务器只是第一步建立完善的审计体系才是实现真正“可控”的关键。因此为RustDesk构建一套会话记录与审计日志系统并非锦上添花而是许多严肃使用场景下的必需品。本文将从一个实践者的角度深度拆解如何基于RustDesk Server从零构建一套贴合实际需求的操作审计方案涵盖设计思路、核心实现、问题排查以及那些官方文档里不会写的实操细节。2. 核心需求与方案设计解析在动手之前我们必须明确要解决什么问题以及不同方案的优劣。盲目开始只会制造出一堆无用的日志文件。2.1 审计日志的核心要素拆解一个合格的审计日志系统至少需要满足以下几个核心要素完整性记录的事件必须包含足够的信息来还原操作现场。对于一次RustDesk会话基础信息应包括会话元数据唯一会话ID、发起端ID你的客户端、目标端ID被控端、连接开始/结束时间、连接使用的中继服务器或直连IP。身份信息操作者账号如果启用了RustDesk Server的用户系统、客户端设备名、IP地址。操作事件这是核心。需要定义哪些操作值得记录。通常包括会话建立、会话断开、文件传输上传/下载含文件名、路径、大小、远程命令行执行命令内容、剪贴板文本同步需脱敏如仅记录“剪贴板同步事件”而非内容、权限变更如请求/授予远程控制、文件传输、录音等权限。不可篡改性审计日志一旦生成应防止被轻易修改或删除。这通常通过将日志写入受保护的目录、使用只追加Append-Only的文件格式、或实时发送到远程日志服务器如Syslog、ELK来实现。可检索性海量日志如果没有高效的查询方式等于没有。需要支持按时间范围、操作者、目标设备、操作类型等维度进行快速过滤和搜索。性能影响最小化日志记录不应显著影响远程桌面的流畅度和响应速度。这意味着日志记录操作必须是异步的、非阻塞的并且要谨慎选择记录频率和内容粒度例如记录每个鼠标点击是不现实的。2.2 方案选型客户端埋点 vs. 服务器端拦截实现上述目标主要有两条技术路径方案一修改RustDesk客户端源码进行埋点记录。这是最直接、信息最全的方式。你可以直接在RustDesk的Rust源码中在关键函数调用处如文件传输、命令行调用插入日志记录代码。优点是能获取第一手、最精确的操作数据。但缺点极其明显维护成本高你需要维护一个RustDesk源码的分支每次官方更新都要考虑合并和冲突解决。部署困难你需要说服所有用户安装你自定义编译的客户端这在企业环境中是一个巨大的管理负担。技术门槛高需要深入理解RustDesk的代码结构和Rust语言。方案二在自托管的RustDesk Server中继/信令服务器端进行流量分析与日志增强。这是更推荐、更可行的方案。RustDesk客户端与服务器之间通过TCP/WebSocket等进行通信。服务器可以看到所有信令交互和经过中继的数据如果使用中继模式。通过解析这些流量我们可以间接推断出许多操作。优点无侵入性无需修改任何客户端所有标准客户端均可使用。集中管控日志在服务器端统一生成和管理易于收集和分析。与客户端解耦服务器升级不影响客户端。缺点信息可能不全对于端到端加密的直连会话服务器无法看到具体操作内容只能记录“建立了直连会话”这一事件。但对于经过中继的流量如文件传输、某些情况下的远程Shell可以解析出更多信息。需要解析协议需要深入研究RustDesk的私有通信协议有一定技术挑战。实操心得对于绝大多数追求平衡与可行的团队方案二服务器端增强是起点。我们可以先实现服务器端的完整会话元数据记录和部分操作事件推断这对于安全审计记录“谁连接了谁”和大部分问题排查已经足够。如果确有记录详细操作内容如命令行的强需求可以再考虑在受控环境如IT管理员专用客户端中有限度地采用方案一。基于方案二我们的技术栈可以这样选择日志采集修改或增强hbbs信令服务器和hbbr中继服务器的源码在关键网络事件处理函数中写入结构化日志如JSON格式。日志传输使用rsyslog或vector等工具将本地日志文件实时转发到中央日志服务器。日志存储与展示采用经典的 ELK StackElasticsearch, Logstash, Kibana或更轻量的 Grafana Loki Promtail Grafana 组合。ELK功能强大但资源消耗大Loki轻量擅长日志索引和查询与Grafana集成好。协议分析对于需要深度解析中继流量的部分可能需要使用Rust或Go编写一个旁路解析程序监听或镜像中继服务器的流量。3. 服务器端日志增强实战这里我们聚焦于最核心的部分修改RustDesk Server源码输出增强的审计日志。我们假设你已经搭建好了自托管的RustDesk服务器hbbs和hbbr。3.1 环境准备与源码定位首先你需要准备好Rust开发环境并获取RustDesk Server的源码。# 1. 安装Rust (如果尚未安装) curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env # 2. 克隆RustDesk Server 源码 (请使用官方仓库或稳定版本分支) git clone https://github.com/rustdesk/rustdesk-server.git cd rustdesk-server # 3. 查看主要项目结构 # hbbs/ - 信令服务器 # hbbr/ - 中继服务器 # libs/ - 共享库审计日志的关键注入点主要在hbbs中因为它处理所有连接、登录、配对等信令。hbbr主要处理实际的数据流中继是记录文件传输等操作的关键。3.2 信令服务器(hbbs)日志注入我们需要在hbbs/src目录下找到处理客户端请求的函数。以记录“连接请求”为例通常会在处理Peer连接或Login消息的地方。步骤1确定日志注入点查看hbbs/src/main.rs或相关的处理器文件。通常连接建立和认证逻辑在server.rs或类似命名的文件中。找到类似handle_client或on_login的函数。步骤2设计日志结构在开始修改前定义好要输出的JSON日志格式。例如一个连接事件日志{ timestamp: 2023-10-27T10:00:00.000Z, level: INFO, event_type: session_start, session_id: uuid-v4-generated, source_client_id: client-id-of-operator, target_client_id: client-id-of-target, source_ip: 192.168.1.100, auth_method: password_or_paired, relay_mode: direct_or_relay, server_host: your-hbbs-hostname }步骤3修改源码添加日志假设我们在hbbs/src/server.rs的handle_login函数中找到位置。我们需要引入Rust的日志库如log和env_logger但项目可能已集成tracing。这里我们使用项目已有的tracing框架进行结构化日志输出。首先在函数内部生成一个唯一的会话ID并在连接建立时记录// 在 handle_login 或类似函数中认证成功后 use uuid::Uuid; let session_id Uuid::new_v4().to_string(); let source_ip socket.peer_addr().unwrap().ip().to_string(); // 使用 tracing 的 event! 宏记录结构化字段 tracing::info!( event_type session_authenticated, session_id %session_id, source_client_id %login_info.client_id, // 假设 login_info 包含客户端ID source_ip %source_ip, auth_method %auth_method, User authenticated for remote session );步骤4记录会话结束同样需要在连接断开的地方如drop实现或连接错误处理中记录结束事件。tracing::info!( event_type session_ended, session_id %session_id, duration_secs %duration.as_secs(), bytes_sent %bytes_sent, bytes_received %bytes_received, Remote session ended );3.3 中继服务器(hbbr)日志注入用于文件传输等操作hbbr处理实际的数据流。文件传输、可能的远程Shell数据都会经过它如果走中继模式。这是记录具体操作的关键。步骤1定位数据包处理逻辑在hbbr/src下找到处理数据转发的函数。需要解析RustDesk的数据包格式。RustDesk使用自定义的二进制协议包结构通常包含类型、长度、负载等。步骤2解析关键操作码你需要查阅源码或通过抓包分析确定不同操作对应的包类型码。例如文件传输开始/数据块/结束远程命令行数据剪贴板同步这是一个简化的示例展示如何识别文件传输// 假设在数据转发循环中 match packet_type { FILE_TRANSFER_START { // 解析出文件名、大小等信息 let file_name parse_file_name(payload); let file_size parse_file_size(payload); tracing::info!( event_type file_transfer_start, session_id %current_session_id, // 需要将会话ID从信令层传递过来 direction upload_or_download, // 需根据上下文判断 file_name %file_name, file_size %file_size, File transfer initiated ); } FILE_TRANSFER_CHUNK { // 通常不需要记录每个数据块太冗余。可以定期汇总。 } FILE_TRANSFER_END { tracing::info!( event_type file_transfer_end, session_id %current_session_id, status success_or_failed, File transfer completed ); } _ { // 其他包类型... } }重要注意事项性能考量在hbbr的数据路径上记录日志必须极其小心。每个数据包都进行详细的解析和日志记录会带来巨大开销。务必采用抽样或仅记录元数据如开始/结束事件的方式。对于命令行可以记录“启动了远程Shell”和“Shell会话结束”而非每个击键。隐私与合规绝对不要记录文件内容、命令行中的敏感信息如密码、剪贴板中的明文数据。只记录事件和脱敏后的元数据如文件名、命令名称ls但不记录rm -rf /的具体参数。这是法律和伦理的红线。会话关联hbbr收到的数据流需要与hbbs建立的会话关联起来。这通常需要通过连接标识或内部会话ID来实现可能需要修改协议或在连接建立时传递上下文信息这是实现中最复杂的部分之一。3.4 编译与部署自定义服务器修改完成后在项目根目录编译cargo build --release --bin hbbs cargo build --release --bin hbbr编译产物位于target/release/目录下。用它们替换你原有服务器上的二进制文件并重启服务。确保你的日志配置如tracing的输出目标已设置为写入文件或标准输出以便被后续的日志收集器抓取。4. 构建中央审计日志系统服务器输出结构化日志如JSON Lines格式只是第一步。我们需要一个系统来集中收集、存储、索引和展示这些日志。4.1 日志收集与转发配置我们使用vector作为日志收集和转发器它性能好、配置灵活。假设我们将RustDesk服务器的日志输出到/var/log/rustdesk/audit.json。Vector 配置文件 (/etc/vector/vector.toml)[sources.rustdesk_audit] type file include [/var/log/rustdesk/audit.json] read_from beginning max_line_bytes 102400 # 处理较长的JSON行 # 解析JSON格式的日志 [transforms.rustdesk_parser] type remap inputs [rustdesk_audit] source . parse_json!(.message) // 如果日志行本身是JSON // 或者如果整个文件内容是JSONL则直接使用 . 即可 .timestamp to_timestamp!(.timestamp, format: %Y-%m-%dT%H:%M:%S%.fZ) # 可选添加一些通用标签 [transforms.add_tags] type remap inputs [rustdesk_parser] source .host get_hostname!() .source rustdesk_server # 输出到Elasticsearch [sinks.rustdesk_to_es] type elasticsearch inputs [add_tags] endpoint http://your-elasticsearch-host:9200 index rustdesk-audit-%Y.%m.%d # 按日创建索引 auth.strategy basic auth.user your_es_user auth.password ${ES_PASSWORD} # 从环境变量读取密码4.2 使用Grafana Loki实现轻量级存储与查询如果你觉得ELK太重Grafana Loki是绝佳的替代品。它只索引日志的元数据标签日志内容本身被压缩存储非常节省资源。架构Promtail安装在RustDesk服务器上负责读取日志文件并发送给Loki。Loki中央日志存储服务器。Grafana用于查询和展示日志。Promtail 配置文件 (/etc/promtail/config.yaml)server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients: - url: http://your-loki-host:3100/loki/api/v1/push scrape_configs: - job_name: rustdesk_audit static_configs: - targets: - localhost labels: job: rustdesk app: rustdesk-audit host: __host__ # 自动填充主机名 __path__: /var/log/rustdesk/audit.json pipeline_stages: - json: expressions: timestamp: timestamp event_type: event_type session_id: session_id source_client_id: source_client_id target_client_id: target_client_id - timestamp: source: timestamp format: RFC3339 - labels: event_type: session_id: source_client_id: target_client_id: - output: source: message这个配置会从JSON日志中提取关键字段作为标签Label在Loki中可以通过这些标签进行高效过滤。例如查询特定会话的所有事件{apprustdesk-audit, session_idyour-session-uuid}。4.3 在Grafana中创建审计仪表盘在Grafana中连接到你的Loki数据源后可以创建丰富的仪表盘。常用面板建议实时会话监控使用Logs面板查询{apprustdesk-audit, event_type~session_.*} | json按时间倒序排列实时滚动显示所有会话的建立和断开。每日活动统计使用Stat或Time series面板查询count_over_time({apprustdesk-audit, event_typesession_authenticated}[1d])显示每日连接数。高频操作者/设备使用Table面板查询topk(10, sum by (source_client_id) (count_over_time({apprustdesk-audit}[1d])))列出最活跃的客户端。文件传输审计使用Logs面板查询{apprustdesk-audit, event_typefile_transfer_start} | json展示所有文件传输事件的详情。异常行为告警在Grafana中设置告警规则。例如同一源客户端在1分钟内发起超过10次连接尝试可能意味着暴力破解或异常行为。告警规则可以基于Loki查询sum by (source_client_id) (count_over_time({apprustdesk-audit, event_typesession_authenticated}[1m])) 10。5. 常见问题、排查技巧与进阶思考在实际部署和运行过程中你会遇到各种预期之外的问题。以下是一些典型问题及其解决思路。5.1 日志丢失或不完整问题审计日志中某些事件缺失尤其是快速连续的短会话。排查检查日志缓冲tracing或其它日志库可能使用了异步缓冲。确保在进程正常退出或连接断开前日志被刷新flush到文件。可以在记录关键事件后手动调用 flush或配置日志库使用行缓冲模式。检查Vector/Promtail采集延迟检查采集器的read_from配置是否为beginning或end。对于审计日志建议设为beginning并确保有监控防止文件被轮转logrotate时丢失。配置logrotate时使用copytruncate或让采集器支持文件重打开。服务器性能瓶颈在高并发下如果日志记录是同步的可能会被丢弃。务必确保所有审计日志记录操作是异步的。可以使用tracing的异步Appender或将日志事件发送到一个无阻塞的通道channel由后台线程写入。5.2 无法关联hbbs和hbbr的日志问题hbbr中记录的文件传输事件无法与hbbs中记录的会话发起者关联。解决思路方案A传递会话ID修改协议。在客户端通过hbbs协商中继连接时将hbbs生成的session_id传递给hbbr。这需要修改客户端和服务器端的信令交互工作量较大。方案B基于连接五元组推断在hbbr端记录客户端的连接IP和端口。在hbbs端也记录客户端连接hbbs的IP和端口以及为其分配的session_id。在中央日志系统如Elasticsearch中通过时间窗口和IP/端口信息进行关联查询。这种方法不精确特别是在NAT后多个客户端IP相同的情况下但实现简单。方案C客户端注入标识在客户端发起特定操作如文件传输的请求包中携带一个由hbbs下发的临时令牌tokenhbbr解析出这个令牌并记录。这比方案A的修改范围小一些。实操心得从简到繁。首先实现方案B它能解决大部分“何时、何IP连接”的审计需求。对于需要精确操作溯源的情况再评估实施方案C的必要性和成本。方案A通常过于重型。5.3 隐私与安全合规的边界这是审计系统设计的重中之重。敏感信息脱敏在日志记录代码中必须加入过滤逻辑。例如对于命令行日志可以定义一个敏感命令或参数列表如包含password、secret、key等字段将其替换为[REDACTED]。或者只记录命令名称ssh、scp不记录参数。日志访问控制存储审计日志的服务器Elasticsearch/Loki和展示平台Grafana/Kibana必须设置严格的访问控制RBAC确保只有授权的安全审计人员才能访问。日志加密与完整性保护考虑对存储在磁盘上的日志文件进行加密如使用LUKS或ecryptfs或者确保传输通道Vector到ES使用TLS。可以使用日志签名技术如HMAC来检测日志是否被篡改但这会增加系统复杂性。5.4 性能优化与规模化当会话量很大时例如每天数万次连接审计日志系统本身不能成为瓶颈。日志分级并非所有事件都需要记录为“INFO”。将会话开始/结束、文件传输定义为INFO将心跳包、常规数据包转发定义为DEBUG级别并在生产环境中关闭DEBUG日志。抽样记录对于极其高频的事件如果未来记录了鼠标移动当然这没必要可以采用抽样记录比如每100次记录1次。使用高效的序列化格式日志输出使用二进制格式如Protocol Buffers比JSON文本更节省空间和CPU但会牺牲可读性。需要在性能和可调试性间权衡。初期用JSON更简单。日志聚合与降精度在存储前可以使用流处理框架如Flink, Spark Streaming对日志进行实时聚合。例如将“每秒心跳数”聚合成“每分钟心跳数”再存储大幅减少数据量。为RustDesk构建会话记录与审计日志系统是一个从无到有、逐步深化的过程。它始于一个简单的需求——想知道“谁连了谁”最终可以演变为一个集安全监控、合规审计、故障排查于一体的综合运维平台。关键在于起步要稳先从服务器端无侵入的元数据收集开始搭建起可靠的日志管道和查询界面。当这个基础稳固后再根据实际遇到的具体安全或运营问题决定是否需要进行更深度的客户端埋点或协议解析。记住审计系统的价值不在于记录了多少数据而在于当需要回答关键问题时你能多快、多准地找到答案。