RustDesk自托管API服务器安全加固实践

RustDesk自托管API服务器安全加固实践

发布时间：2026/10/21 6:48:21
RustDesk自托管API服务器安全加固实践 1. 项目背景为什么RustDesk API服务器会成为安全短板1.1 RustDesk自托管部署的组件拓扑先说清楚一件事RustDesk本身是一个开源远程桌面工具自托管部署时通常包含hbbsID/中继服务端、hbbr中继服务器、以及一个API服务器也叫web api / rustdesk-api-server一般用Go或Node写的。很多人第一次部署的时候只关注了hbbs/hbbr能不能连通端口通不通却把API服务器当成一个“附属品”随便扔在公网里。但恰恰是这个API服务器承载着设备列表、用户登录、token签发、设备分组、日志下发等一系列重要功能。更关键的是在RustDesk的官方客户端配合自定义API服务器时客户端的登录验证、设备注册、甚至远程会话的授权逻辑都会经过这个API。也就是说API服务器是整条链路里的闸门。如果这个闸门本身不设防那远端设备等于把凭据和入口都暴露给了攻击者。我见过不少团队部署了RustDesk后所有东西都能连通但API服务器直接裸奔——HTTP明文、无认证头校验、数据库口令硬编码在配置里。这种问题一旦被扫描到整个远程控制体系就形同虚设。1.2 API服务器面临的主要攻击面把API服务器暴露在公网等于给所有人递了一张访问卡。常见的攻击路径有这么几条未授权接口探测很多rustdesk-api项目默认提供/api/login、/api/users这类接口如果没有做访问控制攻击者可以直接调用接口遍历用户列表。弱口令撞库API服务器如果使用数据库存储用户令牌或密码哈希弱口令一旦存在配合批量扫描工具很快就会被撞开。中间人窃听不使用HTTPS时客户端和API之间传输的凭据、token在公共网络里如同裸奔。资源耗尽攻击API服务器默认没有限流时攻击者可以用脚本并发打接口直接把服务器拖垮影响正常远程会话。日志泄露很多默认配置会把请求体、token甚至密码明文打到日志里日志一旦被拿到等于直接交出控制权。这些攻击面如果不处理RustDesk再安全也无济于事。所以这篇博文我打算从部署前置、访问链路、API自身、数据存储、运维监控几个层面把一套完整的加固方案拆开讲清楚。2. 部署前置基础环境与访问链路的安全准备2.1 服务器选型与系统级加固在配置RustDesk API之前服务器底子先要干净。我建议从一开始就不要使用官方一键脚本直接跑在root用户下而是创建一个单独的系统账号。以Linux环境为例sudo useradd -r -s /usr/sbin/nologin rustdesk sudo mkdir -p /opt/rustdesk-api sudo chown -R rustdesk:rustdesk /opt/rustdesk-apinologin可以保证这个账号无法直接登录shell即使API服务器被利用getshell也无法轻易切换交互环境。系统层面还要做几件事关掉不需要的服务端口至少保证本机只监听需要的端口不要开着SSH后还把API绑定在0.0.0.0:80上。开启防火墙只放行必要端口。默认情况下API服务器监听21148这类自定义端口配合反向代理时只需要放行80/443。配置fail2ban或者类似工具针对SSH入口做暴力破解防护不要把服务器的安全都寄托在密码强度上。定期升级系统补丁尤其Linux内核版本过旧、存在已知提权漏洞时一定要及时更新。我个人的习惯是部署之前先做一次基础镜像用最小的发行版比如Debian精简安装能不装的软件一律不装。API服务器只依赖运行时和必要库其他的一概不要。攻击面小了排查问题时也简单。2.2 域名、DNS与TLS证书规划HTTPS不是可选项是这个方案里第一优先级。不要用自签证书或者HTTP裸连否则token和密码分分钟被截获。域名规划上我建议单独用一个子域比如rd-api.example.com不要和其他业务混在一起。证书申请方面用Lets Encrypt的免费证书完全够用配合certbot自动续期省心不费钱sudo apt install certbot python3-certbot-nginx -y sudo certbot --nginx -d rd-api.example.com申请完之后注意一点TLS配置不要用默认值至少启用TLS 1.2以上禁用旧协议。Nginx里可以这么配置ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_session_timeout 1d; ssl_session_cache shared:SSL:10m; ssl_prefer_server_ciphers on;这样配置之后即使客户端比较老也能保证加密强度不至于被一把梭。另外不要把证书私钥的权限放开给普通用户Nginx运行用户只要能读取公钥和私钥文件即可不要用644权限直接暴露给所有人。2.3 反向代理层的基础防护RustDesk API服务器一般不建议直接对外监听最好在API前面挂Nginx或者Caddy。反向代理的作用不只是转发请求它可以做以下几层防护HTTP头过滤只允许特定的HTTP方法GET、POST、PUT、DELETE禁止其他方法。请求体大小限制防止上传超大payload拖垮API。超时控制避免慢连接占用连接池。访问日志脱敏不让token和密码出现在日志里。Nginx关键配置参考server { listen 443 ssl http2; server_name rd-api.example.com; client_max_body_size 10m; proxy_connect_timeout 5s; proxy_read_timeout 30s; # 阻止非预期方法 if ($request_method !~ ^(GET|POST|PUT|DELETE)$) { return 405; } location / { proxy_pass http://127.0.0.1:21148; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 去掉不必要的header proxy_hide_header X-Powered-By; } }这只是基础更细的访问控制放到API层去做nginx负责网络边界API负责业务鉴权两者配合才不会出现单点失效。3. API服务自身的权限模型与认证强化3.1 API请求链路中的身份鉴别很多开源版RustDesk API设计得比较简单用户登录成功后签一个token后续请求在请求头里带上Authorization: Bearer token。这个模型本身没问题问题在于很多部署没有检查token的有效性、过期时间、以及token绑定的客户端信息。我在实际加固时给API加了一层中间件所有需要鉴权的接口统一走中间件逻辑解析请求头里的Bearer token验证token签名用HMAC-SHA256或者RSA校验token的过期时间以及是否被服务端主动吊销检查token关联的客户端ID与当前请求的客户端ID是否一致将解析出的用户信息注入到请求上下文这样一来即使某个token被泄露也无法在过期后继续使用也无法关联到其他客户端设备。在实现层面如果开始就用的是成熟的Go或者Node框架加中间件不难。关键是别把token校验逻辑散落在每个接口里那样很容易漏判。统一入口处理后续再添加新的鉴权规则也很方便。3.2 令牌生命周期管理与密钥轮换token不能永久有效。我见过有人配置完之后token有效期设成一年甚至不设置过期时间。这在远程控制场景里非常危险因为一旦设备丢失或者员工离职token如果还活着就等于把内部系统的钥匙留在了外面。建议至少做到短期令牌如2小时用于客户端会话到期自动刷新长期令牌如7天用于设备注册不可手动刷新服务器端保存一份token黑名单吊销时直接加入黑名单轮换HMAC密钥也不能偷懒。如果API服务器的签名密钥写死在配置文件里且多年不变一旦泄露所有历史token都能被伪造。我一般把密钥放在环境变量或者独立的密钥文件中并且用脚本定期轮换当前密钥、旧密钥同时支持一段时间避免所有客户端强制重新登录。你可以参考这个伪代码逻辑def generate_token(user_id, expires_in): payload { user_id: user_id, exp: int(time.time()) expires_in, iat: int(time.time()), jti: uuid.uuid4().hex } token jwt.encode(payload, current_secret, algorithmHS256) return token def verify_token(token): try: payload jwt.decode(token, current_secret, algorithms[HS256]) if payload.get(jti) in revoked_tokens: raise InvalidToken return payload except jwt.ExpiredSignatureError: # 可使用旧密钥尝试解析如仍未过期的token可放行 payload jwt.decode(token, previous_secret, algorithms[HS256]) return payload注意jti字段要生成并记录便于吊销单个token而不用全部失效。3.3 基于IP的访问控制与内部信任边界如果你的RustDesk API并不是必须要提供给外网设备访问那最稳的方案就是直接把API服务器放在内网只允许公司办公网段或者专线网段访问。这比任何应用层防火墙都好使。比如在Nginx层加白名单location / { allow 192.168.10.0/24; allow 100.64.0.0/10; deny all; proxy_pass http://127.0.0.1:21148; }如果确实有外网访问需求比如在外出差的员工需要远程内网电脑那就不能只按来源IP锁死得通过只能使用HTTPStoken。对于这类场景可以在API前面再加一层防火墙策略限制来源地域、ASN范围甚至只允许公司出口公网IP。实际操作时我倾向于“多重叠加”对管理接口比如用户增删改、密钥轮换、票据查询一律内网白名单访问对客户端调用接口正常走公网HTTPStoken但也要在反向代理层记录来源IP一旦发现异常来源立刻封禁。3.4 接口动作级权限拆分这里要说一个很多人都忽略的点RustDesk API一般不止一种角色比如管理员和普通用户。如果所有角色都能调用管理接口权限设计形同虚设。我建议至少在数据库用户表加一个role字段在中间件里做角色校验管理员可以管理用户、查看全局设备、轮换密钥 普通用户只能查看自己的设备列表、生成自己的会话凭证 访客/受限用户只能被远程不能主动发起会话接口级别做权限控制后还要保证前端拿到的功能列表也是按角色动态返回的。不要只靠“隐藏按钮”来限制接口本身必须响应403。后端模型和前端展示是两码事。4. 数据存储与后台日志安全加固4.1 数据库访问隔离与加密存储API服务器在这个方案里最常见的存储关联是SQLite或者PostgreSQL。如果是SQLite尽量让它只绑定在本地回环地址不要让数据库监听公网端口。如果是PostgreSQL则通过密码认证、SSL连接、独立账号三管齐下。无论哪种数据库都必须做到以下几点数据库账号和API服务器账号分开不要用postgres超级用户数据库连接串中的密码不要明文写在配置文件里使用环境变量或者密钥管理服务敏感字段加密存储尤其是用户密码哈希、令牌签名密钥、设备序号在代码层面密码哈希不要用MD5/SHA1至少用bcrypt或者argon2from passlib.hash import bcrypt def hash_password(pwd): return bcrypt.hash(pwd) def verify_password(pwd, stored_hash): return bcrypt.verify(pwd, stored_hash)注意bcrypt有72字节的密码长度上限如果密码过长会被截断。实际选择中可以用argon2更安全一些但计算开销稍微高一点。对于小规模部署bcrypt足够了。数据库传输层也要加密。PostgreSQL的pg_hba.conf里配置hostssl只允许SSL连接防止在局域网内被嗅探。4.2 配置信息脱敏与环境变量管理配置文件往往是泄露的源头。很多人把API连接串、数据库密码、JWT密钥、甚至管理后台账号密码一起写在config.toml或.env文件里然后整个仓库提交到Git仓库。这个习惯一定要改。建议的方案是配置文件里只保留环境变量引用比如${DB_PASSWORD}启动API服务时通过 systemd 的环境文件加载或者通过 Docker Secret 注入敏感信息由专人管理权限设置为600仅属主可读写禁止把配置文件提交到Git仓库使用.gitignore排除systemd 服务示例[Service] EnvironmentFile/etc/rustdesk/api.env ExecStart/usr/bin/rustdesk-api Userrustdesk Grouprustdesk Restartalways RestartSec10 NoNewPrivilegestrue ProtectSystemstrict ProtectHometrue ReadOnlyPaths/其中ProtectSystemstrict和ProtectHometrue可以防止API服务器进程随意修改系统文件主目录也访问不到。NoNewPrivilegestrue则避免进程获得额外的特权。这些systemd的隔离参数虽然不能完全阻止攻击但能显著提高被利用后的提权难度。4.3 审计日志与告警配置日志是做安全分析的关键。API服务器的访问日志至少需要记录以下字段时间戳精确到毫秒请求方法、路径、状态码来源IP和User-Agent用户ID如果已鉴权请求耗时但是要注意不要把路径中的query参数、header里的Authorization信息直接打印出来。Nginx默认的访问日志会记录完整请求头需要设置过滤或自定义日志格式。我采用过一种做法在Nginx层记通用访问日志在API层记录业务日志业务日志里面对token做截断只显示前几位后几位。配置日志轮转也很重要避免日志文件无限膨胀。用logrotate按天轮转保留30天即可。告警方面最简单的做法是监控API的非200状态码比例特别是401、403、500突然增多时用shell脚本或者Prometheus报警。一通电话提醒比事后翻日志强十倍。5. 运维实践中的避坑记录与排查建议5.1 常见安全误配置我接触过不少RustDesk部署很多团队栽在同一个地方只开了443端口却把API绑定在公网IP上以为有HTTPS就安全。实际上HTTP头里带着客户端的真实IP、token一旦客户端的反代没有处理好还是会有泄露风险。整理一份常见误配置清单可以对照自检配置项错误示例正确操作API监听地址0.0.0.0:21148127.0.0.1:21148TLS协议TLSv1 TLSv1.1TLSv1.2 TLSv1.3用户密码明文存储 / MD5bcrypt/argon2Token过期永久 / 一年2-24小时数据库端口监听公网可达仅本机/内网日志敏感字段记录token截断脱敏有一次我给某公司排查问题发现他们API都跑了一年了数据库里用户密码还是明文。我问他们怎么做的登录认证说直接比对数据库字符串。这种操作只能说运气好还没被攻破但防线完全经不起考验。5.2 高并发场景下的安全性能平衡加安全措施肯定会带来性能损耗比如HTTPS握手、token校验、bcrypt密码哈希。但损耗不至于让服务崩溃关键在于合理设计。我在压测时发现如果每个请求都做一次数据库查询验证tokenQPS上到500左右PostgreSQL的CPU就飙高了。优化方法是token的校验结果用内存缓存1分钟过期降低数据库压力密码哈希计算只在登录接口做其他接口不重复计算Nginx和API之间开启HTTP keep-alive减少握手开销如果并发量更大可以在API前面加一层Redis缓存做短期令牌的校验记录防止同一token频繁跑数据库。但这会增加部署复杂度小规模场景没必要。安全与性能之间有一条底线不能妥协认证环节不能跳过。缓存的只能是“校验结果”不能直接缓存“用户已认证”的结论因为token可以被吊销。5.3 应急响应与吊销机制不管配置多完善一旦发现token泄露或者API服务器被扫描到异常登录必须有应急响应流程。我建议提前准备一套脚本一键吊销指定用户的所有token一键封禁来源IP地址火烧眉毛时直接iptables一键切换JWT签名密钥让所有历史token失效强制所有用户重新登录举个例子吊销脚本可以简化为#!/bin/bash USER_ID$1 curl -X POST https://rd-api.example.com/admin/revoke_user_tokens \ -H Authorization: Bearer $ADMIN_TOKEN \ -d user_id$USER_ID配合管理后台的页面运维人员可以在手机上一分钟内完成应急处理。千万别等到攻击发生后才开始现写shell脚本那样太迟了。5.4 我踩过的几个坑与心得最后分享几个实际运维中踩过的坑希望后面的朋友不要重蹈覆辙第一个坑非root用户跑不起来。有些API版本会写日志到当前目录如果目录属于root且权限为755非root用户启动时就报Permission denied。解决办法是提前创建好/var/log/rustdesk-api目录属主设为rustdesk用户或者直接用systemd的LogsDirectoryrustdesk-api自动管理。第二个坑反向代理后客户端获取到的IP都是127.0.0.1。如果你在API代码里用r.RemoteAddr做IP限制会发现所有IP都变成了localhost。为了让API能拿到真实IPNginx里必须设置X-Real-IP和X-Forwarded-ForAPI里也要选择正确的方式获取客户端IP。建议在API代码里统一封装一个获取真实IP的工具函数优先检查X-Real-IP头部。第三个坑token过期时间设置太短导致用户频繁掉线。我在测试的时候把token设成了15分钟结果远程会话超过15分钟就断开了体验极差。最后把短期token设成4小时同时允许刷新机制既保证安全又不影响正常使用。所以过期时间要结合业务场景权衡不是越短越好。第四个坑证书自动续期失败导致服务突然中断。Lets Encrypt的证书三个月有效如果certbot定时任务没有配置好过期之后HTTPS握手直接失败RustDesk客户端就会报连接异常。要定时检查certbot的续期日志并监控证书到期时间不要等到报警了才处理。根据我的经验RustDesk API服务器的安全配置并不需要非常复杂的商业安全产品更多是基本功是否扎实。把上文提到的几个层面逐一落实普通规模的团队用起来已经很放心了。后续如果业务规模变大、设备数超过几百台还可以考虑把API服务器拆成独立集群配合更细粒度的审计平台但那是后话了。