这是一个创建于 1286 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在用 frp 穿透一些服务到外网，大致是这样的，我有一台公网 VPS，有公网 IP，机器性能不行，所以在内网搭建了一些服务，gitlab，minio 这些的，然后将这些 web 服务通过 frp 映射到公网去，通过域名访问的。
这个使用下来，留意到 frp 一直有的安全问题，但是搜了一圈，貌似安全问题都是体现在 frp 穿透了 ssh 服务出去才引起的，像我这种只穿透 http web 服务出去会有影响吗？
我的理解是只穿透 http 服务出去，不会出现安全问题，最坏的情况是，VPS 被攻破，然后他只能访问有限的几个内网 web 服务。
不知道大家怎么看？
 |
1
bruce00 2021-05-08 14:42:01 +08:00
frp 只管转发，内网的安全取决于穿透的服务本身的安全性
|
 |
2
v2tudnew 2021-05-08 14:44:46 +08:00 via iPhone
你这个题就不对，安全性在于你要暴露的服务上面做，穿透就像个端口开放。
|
 |
3
psirnull 2021-05-08 14:47:24 +08:00
你本地的 web 服务是否安全是短板
|
 |
4
love 2021-05-08 14:51:45 +08:00
gitlab/minio 这种本身有漏洞了呢？
ssh 我觉得有漏洞的可能性不大（至少这种大杀器不会用在你身上）但别的乱七八糟的 http 服务就不一定了，比如 wordpress 之类 |
 |
6
LeeReamond 2021-05-08 15:30:34 +08:00
有点意思的问题，读下来似乎楼主是认为 stcp （还是叫 xtcp ）的那个 api 在 client 被爆破后可能用来向 server 上传不安全代码，所以用 http 转发就比较安全了？一个疑问是他那个 http 转发支不支持 tls，不支持的话不是裸奔传输，本末倒置。
|
 |
8
no1xsyzy 2021-05-08 15:32:55 +08:00
frp 只管转发，所谓的安全问题无外乎：1. 在公网上这件事本身就是个安全问题； 2. 你的 TLS 放在 frps 上； 3. 你的 frps 服务器被攻破，从而中间人。
针对 1，你只能减少暴露使其不可能被直接访问，比如 knocking，比如只暴露一个 wg/ov 的口。 针对 2，不要这么做，如果真有必要单端口多服务，也请转到内网再进行分离，或者 wg/ov 。 针对 3，请结合 1 2 实施，更进一步地，定期完全清理并重装 frps，可以做个自动配置脚本，但需要想办法处理日志。 ssh 的大漏洞，除非哪个无知愣头青撞上了漏洞或者意外地从其他人那里拿到了漏洞资料，否则不太可能拿去全网扫描，直接被蜜罐发现。 |
 |
9
brader 2021-05-08 15:34:45 +08:00
这么和你说吧，如果有漏洞，你是自己服务器的话，也就是你自己的服务器被盗，损失是你自己的，但是你公司局域网不同，如果你的电脑和内网其他机器互通，那么其他机器也面临威胁。
最最最重要一点，是法律风险，你将内网映射到公网，得到公司授权了吗？ 你不出事的时候，公司不会找你麻烦，出事你就知道了，所以我劝你，谨慎看待你这个行为。 看过很多新闻吗？某某某公司员工，私自将内网映射到公网，被公司起诉，要求赔偿 xx 钱。 |
|
10
brader 2021-05-08 15:39:32 +08:00
再面对上面一些老兄说的，对其他机器无威胁的，其实有些方面是他们没想到，现在家庭电脑，很多不安装杀毒软件、不及时安装补丁程序，防护是非常薄弱的，那么为什么比较少人中招呢？这得益于网络的 nat 映射技术，内网和外网隔离了，除了你主动去下载了带病毒的一些东西，一般外网无法直接攻击用户计算机。
但是你把你自己内网映射出去就不同了，外网有了突破口来入侵内网，如果你某个 web 项目，存在严重漏洞，别人有办法把蠕虫病毒注入进来，那么蠕虫借助你的计算机和内网其他机器的连通性，可以快速扩散，对其他计算机造成威胁。 |
 |
11
joyhub2140 2021-05-08 15:50:52 +08:00
我用 autossh 内网穿透的，和 frp 一样，基于 ssh 协议的，ssh 采取非常规端口+只允许密钥登录一般没有太大问题的，而且还是加密通信，但要注意 frp 转发出去的服务端口，这个端口是有可能成为突破口的，特别是那个 gitlab，软件本身很复杂，且更新不及时，爆出严重漏洞的时候，是很容易被攻击者突破到公司内网环境的。
|
|
12
joyhub2140 2021-05-08 15:53:45 +08:00
与其担心 frp 的安全性问题，不如勤更新转发的服务的软件版本。
|
|
13
brader 2021-05-08 15:58:54 +08:00
@joyhub2140 其实更安全的模式，应该采用，让远程机器通过 frp 加入内网这样一种模式，才是最安全的。目前 frp 软件已经支持该功能了。
好处如下： 1. 只需要暴露 ssh 的 22 端口，而且 ssh 算比较成熟了，目前漏洞已经很少了。 2. 远程机器加入内网后，可随意访问内网任意端口（就好像你处于内网环境中一样），而不需要逐个将内网的端口映射到公网去，灵活。 |
 |
14
q1angch0u 2021-05-08 20:25:01 +08:00 via iPhone
frp 的安全问题在我看来是不加 token 导致 frp 服务被滥用的问题
|
 |
16
littlewing 2021-05-08 23:14:55 +08:00
@brader 感觉这种模式类似于 VPN ？
|
 |
17
Huelse 2021-05-09 11:44:29 +08:00
wireguard 你值得一试
|
 |
18
ntgeralt 2021-05-09 17:41:08 +08:00
首先 FRP 只是转发，也就是隧道问题。如果你 ssh 端口 22 密码 123456 这就是安全问题。如果你转发后，依然在新的 IP 用 22 端口，那一样是非常低级的问题。
你的担心源于没用过 frp 几天。另外 ssh 问题装个 fail2ban+8 位标点密码，根本就不是问题了 |
 |
19
mostkia 2021-05-09 21:27:47 +08:00
frp 在我看来，主要的问题是很多程序都无法定位访问者的 ip，从而做到针对性的 block，除此之外基本都是被穿透服务本身的问题了。ssh 可以不用 22 端口，或者使用复杂度高的密码就行了。我是直接吧 ssh 停用转为 webssh 了，尽量减少不必要端口的映射开放。
|
 |
20
amrom OP |
 |
21
killva4624 2021-05-10 20:07:39 +08:00
暴露 HTTP 服务，如果服务存在 CVE 漏洞的话，很容易被人入侵（比如 shell 反弹），轻则泄漏资料，重则在把被入侵的服务器当跳板，横向入侵内网其他服务器。
不管是小公司还是大公司，都不要把内网的服务轻易暴露到公网，我觉得这是首要安全共识。 如果非要暴露出去的话，一个是 HTTP 或者其他服务不要用 root 身份运行，另外一个如楼上所说，加 fail2ban 来减少恶意端口扫描，另外如果能限制访问源 IP 就更好了。 |
Select Language