V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
az22c
V2EX  ›  宽带症候群

小白是否不适合搞外网远程桌面?

  •  
  •   az22c · 2023-05-05 11:16:55 +08:00 · 6409 次点击
    这是一个创建于 601 天前的主题,其中的信息可能已经有所发展或是发生改变。

    想从公司,远程桌面到家里的 主力机(代号为 C 机),看看笔记啥的,一般不需要提交什么资料。

    一般方案就是:控制端机 A,远程桌面到,家里 主力机 C。(家里还有一台 闲置机 B,看看能不能帮助提高安全性。)


    如果实施远程桌面方案:

    研究了一下站里,我做一个肤浅的解读:

    • 基本上我把外网远程桌面和内网穿透视为是外网裸奔了,是并非绝对安全的
      • 一般认为套 vpn 或者用 ssh 是安全的。
      • 其他的向日葵、teamviewer 、rdp 、frp 有翻车中毒的案例。
      • tailscale ,zerotier 等虽说是 vpn ,但是不知道会不会未来翻车中毒。

    所以,

    • 所以想中间加一台 闲置机 B 做轻度的隔离,好像能挡挡常见勒索病毒。
      • (万一中勒索毒了,重装 机 B 没事)
      • 控制端机 A,远程桌面到 闲置机 B
      • 闲置机 B,再通过待定什么服务访问 主力机 C 里面的笔记、局域网图床、局域网网盘。

    但是看到很多案例,病毒木马感染能打穿局域网。想试问 机 B 访问 机 C 的笔记和图床有什么安全的服务? ==》就是一个局域网里面搞安全隔离的问题。


    如果不实施远程桌面方案:

    任意一台局域网内机器,将笔记部署为一个网页服务,只暴露这个端口和网页。外网的机器怎么访问这个内网网页,同时安全性比较高呢?

    52 条回复    2023-10-27 14:40:57 +08:00
    mohumohu
        1
    mohumohu  
       2023-05-05 11:21:32 +08:00
    zerotier 开源可以自建,也不暴露端口。想安全暴露可以套个 cloudflare tunnel 。
    az22c
        2
    az22c  
    OP
       2023-05-05 11:25:17 +08:00
    @mohumohu zerotier 开源。个人粗浅理解,如果某人发现该程序后门,选择公不公开是个玄学问题
    az22c
        3
    az22c  
    OP
       2023-05-05 11:27:47 +08:00
    @mohumohu 不论开源还是闭源,个人对内网穿透和远程桌面不太信任,主要是因为这些给予的计算机权限太大了,把风险拔得太高。
    iyiluo
        4
    iyiluo  
       2023-05-05 11:27:48 +08:00   ❤️ 1
    开防火墙,只放行固定 ip 访问,如果是公司出口没有固定 ip ,可以放行网段,加上远程登录密码,足够安全了
    weiweiwitch
        5
    weiweiwitch  
       2023-05-05 11:32:17 +08:00   ❤️ 3
    没有绝对安全的系统。防的在好,某些安全技术在未来也有可能有致命漏洞。
    所以说,所有方案都是在投入的时间精力(成本)和安全性之间做平衡。
    把重要资料做离线备份,然后在自己有限精力范围内选择一个可行方案就行了。
    太注重安全,这日子就没法过了(整天都处于焦虑中)。
    mohumohu
        6
    mohumohu  
       2023-05-05 11:35:28 +08:00
    @az22c 你这么说的话所有程序和方案都可能是不安全和有后门的,更别说闭源的程序了。远程权限并不是内网穿透给与的,而是你自己给的,你可以用标准用户远程连接,符合 UAC 的用法。
    leaflxh
        7
    leaflxh  
       2023-05-05 11:38:39 +08:00   ❤️ 1
    内网单独开一个 linux 虚拟机

    用 iptables 禁止到内网的流量,只允许特定的端口
    ---
    #新建一个隔离用的链
    iptables -N ISOLATION

    #允许内网机器 192.168.1.10 连接该虚拟机的 ssh 服务和 https 服务
    iptables -A ISOLATION -d 192.168.1.10 -p tcp -m multiport --sport 22,443 -j ACCEPT
    #拒绝所有的其他流量
    iptables -A ISOLATION -d 192.168.1.0/24 -j DROP
    iptables -A ISOLATION -p all -j RETURN

    #以上规则应用到出站
    iptables -I OUTPUT -p all -j ISOLATION
    iptables -I DOCKER-USER -p all -j ISOLATION
    ---
    xuelu520
        8
    xuelu520  
       2023-05-05 11:39:26 +08:00
    你这个需求不需要远程呀,oneDrive 等等同步盘就行了
    leaflxh
        9
    leaflxh  
       2023-05-05 11:41:36 +08:00
    这样黑不到内网的机器,除非拿到 root 权限把防火墙清了,或者知道了这个规则,特地把发包的源端口设定为 22 或 443
    az22c
        10
    az22c  
    OP
       2023-05-05 12:00:39 +08:00
    @leaflxh > 允许内网机器 192.168.1.10 连接该虚拟机的 ssh 服务和 https 服务

    那我外网连到该 隔离机,随便选个相对靠谱的远程桌面方案就可以了吗?

    我笔记仓库应该是放在主力机呀,那这个 隔离机 可以通过 git ssh 连接笔记吗?还是用的 u 盘传输笔记?
    az22c
        11
    az22c  
    OP
       2023-05-05 12:02:19 +08:00
    @mohumohu #6 不太看得懂。意思是 标准用户远程连接或者说 UAC 是相对更安全一点嘛?
    az22c
        12
    az22c  
    OP
       2023-05-05 12:06:23 +08:00
    @xuelu520 #8 对呀。光是看笔记,靠笔记厂商的云服务或者云盘就可以了。这是绝大多数人已知的方案。我想问一下上述我这些不了解的方案,拿来实施一下。然后对比一下效果。

    笔记云服务也不是十全十美的啊,主要在于要支付云服务费;然后大体积笔记仓库想弄到云上面,还是比较麻烦的呀
    leaflxh
        13
    leaflxh  
       2023-05-05 12:16:21 +08:00
    服务暴露在公网上肯定要开防火墙的。

    如果不想学防火墙的话也可以试试端口敲门,就是只开一个端口,然后你连接过去,鉴权通过后它修改防火墙规则,把服务暴露出来。不过没怎么用过只看到过这个概念

    https://www.freebuf.com/articles/network/281639.html
    https://lingwu111.github.io/%E7%AB%AF%E5%8F%A3%E6%95%B2%E9%97%A8%E6%8A%80%E6%9C%AF.html
    https://en.wikipedia.org/wiki/Port_knocking
    leaflxh
        14
    leaflxh  
       2023-05-05 12:18:10 +08:00
    再就是把服务绑在 ipv6 上,目前“看起来”挺安全的,没什么人扫
    brader
        15
    brader  
       2023-05-05 12:23:16 +08:00
    如果你有自己的服务器,懂用 frp 的话,我推荐你用这个,吊打其他远程软件,配置好后,无论是操作便利性还是连接质量,非常完美,我使用这个模式 3 年了,没出什么问题,也没中毒。
    我使用的是 stcp 模式。
    az22c
        16
    az22c  
    OP
       2023-05-05 12:28:38 +08:00
    @leaflxh 我笔记仓库应该是放在主力机呀,那这个 隔离机 可以通过 git ssh 连接笔记吗?还是用的 u 盘传输笔记?还是彻底物理隔离 wifi 隔离?
    hack
        17
    hack  
       2023-05-05 14:08:58 +08:00
    mstsc 加个双因素认证
    VirgilChen97
        18
    VirgilChen97  
       2023-05-05 14:14:30 +08:00 via Android
    是不是直接用 VPN 就好了,我在公司就是直接 wireguard 回家然后直接内网地址远程桌面
    az22c
        19
    az22c  
    OP
       2023-05-05 15:01:14 +08:00
    @hack 双因素认证 有啥成功部署案例吗?企业级的好难呀。手持设备查看动态密码或者接收短信,应该都是需要服务的
    Jhma
        20
    Jhma  
       2023-05-05 15:20:21 +08:00   ❤️ 2
    openvpn 方案,用 opnsense 开源防火墙搭建,可附加一个 OTP 二次验证,手机 APP 装谷歌验证器等,实现了用户+密码+证书+动态码高安全连接!
    c5QzzesMys8FudxI
        21
    c5QzzesMys8FudxI  
       2023-05-05 15:31:13 +08:00
    我是在家里软路由上开了个 Ss 节点,手机和 mac 用 QX ,在外面访问家庭网段 QX 默认走软路由的 Ss 节点。
    registerrr
        22
    registerrr  
       2023-05-05 15:37:49 +08:00
    frp+远程桌面 最不用折腾, 最合适. 就是得有台公网服务器
    密钥设长一点复杂一点, 安全的很.
    LnTrx
        23
    LnTrx  
       2023-05-05 15:44:43 +08:00
    远程桌面的话虚拟机就行了吧,独立物理机的必要性没那么明显。虚拟机可以通过虚拟化软件的共享文件夹功能访问特定宿主机文件。

    非远程桌面方案,部署网页服务的笔记放在虚拟化环境,然后 https 向外网公开不就行了。不放心的话在 nginx 反代再加一层密码验证。
    az22c
        24
    az22c  
    OP
       2023-05-05 15:54:25 +08:00
    @LnTrx 虚拟机有虚拟机逃逸;独立物理机可以通过 wifi 进入局域网。好像虚拟机靠谱一点点
    LnTrx
        25
    LnTrx  
       2023-05-05 16:43:57 +08:00   ❤️ 1
    @az22c 如果这都要考虑,那 A 上应用更可能有漏洞,导致 B 也可以攻击到 A 。
    对比一下:

    1. C 直接部署笔记服务,https 暴露外网
    如果笔记服务有重大漏洞(比如登录界面可以访问到主机文件),会威胁整台机器

    2. C 直接部署笔记服务,https 暴露外网,nginx 额外加一层密码
    即使有重大漏洞,外界绕不过外层密码也难办(但有些 App 可能会不兼容额外的访问控制)

    3. C 使用虚拟化部署笔记服务,https 暴露外网
    如果笔记服务被攻破,虚拟环境可访问的信息会沦陷。
    宿主的风险取决于虚拟化技术。对于虚拟机,逃逸是价值很高的漏洞,对于民用场景不太会遇到。Docker 可能需要加固。

    4. C 直接部署远程桌面访问仅限本机的笔记服务,远程桌面暴露外网
    如果远程桌面有重大漏洞,那会威胁整台机器。如果套一层隧道,那进一步取决于隧道协议和虚拟局域网的安全性。

    5. B 部署远程桌面访问 C 仅限局域网的笔记服务,远程桌面暴露外网
    首先取决于远程桌面的安全性。如果被攻陷,且局域网内有不设防 /高危漏洞的服务,可能会让运行该服务的机器进一步沦陷(除非额外限制)。B 本身的使用痕迹也可能成为跳板(比如保存了密码)。另外,局域网内其它设备也可能威胁笔记服务(除非额外限制)。

    6. C 部署虚拟机运行远程桌面通过共享访问笔记,远程桌面暴露外网
    如果远程桌面被攻破,虚拟环境可访问的信息会沦陷。是否能访问局域网其他设备取决于虚拟机网络的配置。
    如果虚拟机存在逃逸等漏洞,会威胁到宿主机。

    综合看下来,其实就是估计笔记服务出漏洞、远程桌面被攻破、虚拟机发生逃逸、隧道被攻破的可能性(同时考虑 ABC 自身以及虚拟局域网中其他设备等风险),组合出安全系数满足需求、同时不至于太麻烦的方案。个人认为民用场景下,虚拟机的隔离已经够安全了,实在不行加一层密码 /隧道。过于复杂的方案比较难以坚持,而且可能会增加新的风险点。
    LnTrx
        26
    LnTrx  
       2023-05-05 16:45:57 +08:00
    @LnTrx 如果这都要考虑,那 A 上应用更可能有漏洞,导致 B 也可以攻击到 A 。
    修正> 如果虚拟机逃逸都要考虑,那 C 暴露在局域网的服务出漏洞更要考虑。这样的话,B 自然也可以攻击到 C 。
    az22c
        27
    az22c  
    OP
       2023-05-05 16:54:18 +08:00
    @LnTrx 感谢大佬。还是觉得虚拟机比较易用,以前已经装过虚拟机。笔记服务、局域网服务本人根本不懂如何设防。
    LnTrx
        28
    LnTrx  
       2023-05-05 17:02:19 +08:00
    @az22c 我考虑得可能还不够周全。
    另外想问下,你增加一个跳板,目的是为了保护笔记,还是宿主机。如果只是保护宿主机,那直接在 B 部署笔记不就完了。如果远程桌面方案想额外保护笔记,那还需要好的使用习惯。比如在 B 的浏览器里保存了密码,或者登陆了没退出,此时远程桌面被攻破,不也一样白搭。相比其它远程桌面方案,物理隔离对笔记的保护没有增加多少。
    az22c
        29
    az22c  
    OP
       2023-05-05 17:05:48 +08:00
    @LnTrx #28 增加一个跳板,目的是为了保护宿主机。而笔记内容可以脱敏脱密再使用,笔记外泄倒是不怕。
    az22c
        30
    az22c  
    OP
       2023-05-05 17:09:33 +08:00
    @LnTrx #28 如果用 备用机物理机 来实现 B 。打算把笔记仍到 git 私人仓库。然后 B 用 git ssh 连接笔记仓库,同时搞那种每次连接输密码的。

    再深一层局域网防护已经不会了。
    LnTrx
        31
    LnTrx  
       2023-05-05 17:27:18 +08:00
    @az22c 如果服务直接部署在 B ,就没必要再研究 B 、C 的互访,同时避免 C 局域网暴露造成的额外风险。担心 B 沦陷连累局域网的话可以在网关做额外限制,更重要的是加固其他设备的局域网暴露端口。(既然考虑 B 沦陷,那 B 自身防火墙禁止访问内网似乎意义有限)
    另外的方案就是直接在 C 上运行虚拟机。比上述方案增加了逃逸的风险,当然民用很难碰到 0day 的逃逸攻击。但方便的点在于不用维护一台额外的设备,可以通过共享文件访问特定目录,同时控制虚拟机网络比较方便。可以在虚拟网络与宿主机通信(配完可以验证一下哪些宿主端口可访问),避免宿主机向真实的局域网暴露端口。
    当然以上都是基于远程桌面的方案,如果是我自己还是更倾向于转发 https 。

    写了半天注意到你怕的好像是勒索病毒,那把重要资料定期异机备份可能是更需要的保护。
    thereone
        32
    thereone  
       2023-05-05 18:03:59 +08:00
    搞的麻烦,哪有那么多翻车的。最简单就是部署一个 VPN 。你要有公网 IP 那就直接 VPN 回去就行,自行搭建 VPN 总不会被人攻破啊。不行就用内网穿透的 zerotier 这种,觉得不安全那就自建一个 moon 或者 leaf 节点。然后 B 和 C 之间要安全就上一个软防火墙如 pfsense opnsense 这类的或者用 esxi 导入山石网科的防火墙,虽然只有 30 天试用但是到差不多时间就快照一键还原就行。b 访问 c 就只在防火墙里面开启某些端口就行做到访问隔离。
    az22c
        33
    az22c  
    OP
       2023-05-05 18:05:26 +08:00
    @thereone 原来如此,就喜欢后半段这么简单粗暴的 感谢
    sofukwird
        34
    sofukwird  
       2023-05-05 18:14:13 +08:00 via Android   ❤️ 1
    不适合,微软远程桌面出过 0day 漏洞,不需要密码,只要你开了远程桌面端口就可以被黑客控制
    如果你觉得自己很牛逼,能防所有 0day 漏洞,那你可以不用 VPN
    sofukwird
        35
    sofukwird  
       2023-05-05 18:15:56 +08:00 via Android
    tailscale 客户端是开源的,你可以认为它没有明显的漏洞
    bluehr
        36
    bluehr  
       2023-05-05 18:18:05 +08:00   ❤️ 1
    企业版 win10 mstsc + duo mobile 双因子认证 ,已经暴露 3389 端口多年,没被攻击过
    AaIT
        37
    AaIT  
       2023-05-05 18:25:01 +08:00   ❤️ 2
    tailscale 组个内网不就行了,我们商用内部管理都用 tailscale 后台配置权限打上 TAG 想怎么控制怎么控制,tailscale 的域名可以申请免费的证书做个内网网站就行了,HTTPS 都齐全的,很完整的方案了
    dann73580
        38
    dann73580  
       2023-05-06 00:44:13 +08:00
    Tailscale 基于 wg ,目前看 wg 的安全性还是挺有保障的。如果一定要信赖,那我选这个。家里电脑可以设置密钥过期时间,要安全就设置低一点好了。
    lentrody
        39
    lentrody  
       2023-05-06 01:33:25 +08:00
    @sofukwird 难道 VPN 就不会有 0day 漏洞了?
    部署安全性低的服务才需要 VPN ,微软远程桌面被无数人盯着,安全性不会比 VPN 差。
    sofukwird
        40
    sofukwird  
       2023-05-06 08:00:36 +08:00 via Android
    @lentrody 你能盯着黑盒你牛逼,微软远程桌面是闭源的
    wireguard 的安全性是经过安全公司检验过的,目前来说没有发现明显的漏洞
    hack
        41
    hack  
       2023-05-06 09:23:46 +08:00   ❤️ 1
    @az22c multiOTP 够个人用的。改一改有案例可以在 windows 域环境使用。
    aukus
        42
    aukus  
       2023-05-06 09:54:21 +08:00
    说了这么多,都说 MS 不安全,有大佬科普下 RDP 被攻破的案例吗?
    sheayone
        43
    sheayone  
       2023-05-06 11:02:30 +08:00
    我的经验,RDP 端口直接对公网开放,不管你改不改端口号码,都立马会引来一堆肉鸡来试密码,这个才是最大的安全风险;其次才是协议漏洞,这个需要勤打补丁。
    增强 RDP 安全性的途径:
    1. 增加一台 RDP Gateways ,相当于堡垒机;
    2. 通过 over 其他安全通道,比如 VPN 或者 SSH Tunnel ,其中 SSH 仅允许密钥 /证书登录,安全性也可以得到提升。
    互联网没有绝对的安全的说法,都是道高一尺,魔高一丈,保持警惕,安全防护实时跟进就是了。
    wslzy007
        44
    wslzy007  
       2023-05-06 11:30:37 +08:00
    @az22c
    自己使用的话不要发不到外网。具体做法:
    1 、使用工具建立 A to C 的 P2P 连接
    2 、C 上无需监听端口
    3 、只有从 A 可以访问 C
    如上就非常安全了,至于工具如果只是远程端口映射,无需 vpn ,推荐使用 SG:github.com/lazy-luo/smarGate
    hamsterbase
        45
    hamsterbase  
       2023-05-06 12:12:40 +08:00 via iPhone
    电脑 a 安装 tailscale
    电脑 b 安装 tailscale

    问题就解决了
    huihuilang
        46
    huihuilang  
       2023-05-06 14:15:06 +08:00 via Android
    我用 vpn+内网远程桌面解决,技术不行公网开端口怕怕的
    xPKK1qofAr6RR09O
        47
    xPKK1qofAr6RR09O  
       2023-05-08 14:54:37 +08:00
    不适合,你猜 CIA 手里有没有一堆 0day 漏洞
    mm2x
        48
    mm2x  
       2023-05-09 19:34:36 +08:00
    我一般是 ACL 做策略 只允许白名单 IP 通过。或者你有环境的话使用 IPv6
    cdh1075
        49
    cdh1075  
       2023-05-09 22:31:38 +08:00
    有一个 vps 上的 windows 11 ,全关系统防火墙,全关 vps 商的硬件防火墙,3389 暴露公网,两年前发现基本每天有好几百的链接请求,那个主机也不重要,所以我就故意一直这么放着做个实验,除了及时更新补丁,啥格外的安全措施不加,两年过去了,没被打穿。
    3389 的安全风险和 ssh 是一样的,一是弱密码,二是安全 bug 。
    弱密码可以通过加证书解决,安全 bug 遇到的几率和中彩票差不多。
    a578800641
        50
    a578800641  
       2023-05-17 10:19:23 +08:00
    @huihuilang 跟你一样,我也是这样处理的,,
    yijiangchengming
        51
    yijiangchengming  
       2023-05-31 19:02:32 +08:00
    都上 VPN 了,为什么不试试 WireGuard 呢?
    rnv
        52
    rnv  
       2023-10-27 14:40:57 +08:00
    有公网 IP
    弱密码
    开放远程桌面
    是不安全的

    我已经试过了。前几天在 ikuai 后台看到一个可疑 IP 通过远程桌面跟我 PC 建立了很多连接
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   999 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 21:22 · PVG 05:22 · LAX 13:22 · JFK 16:22
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.