High CPU/Network Usage in frps about frp HOT 7 CLOSED

Still, would you be willing to accept a PR to include the IP of failed connections in the log output? I feel this could help elsewhere as well, debugging other issues...
EDIT: Looking at the code, might be too hard for me actually, to get this right ;)

Yes, we have similar plans in the refactoring of the v2 major version. This is a relatively long-term and complex plan, which is also related to other aspects of refactoring. I will write this part of the code myself.

At this stage, the main focus is on gathering requirements. Your feedback will be helpful for how we will refactor in the future.

from frp.

Short update: I've noticed the issue goes away when changing vhostHTTPSPort to something different than 443, e.g.

vhostHTTPSPort = 444

or

vhostHTTPSPort = 44344

then CPU goes down to 0%.

BTW: In any case - even when CPU usage is high – I can connect with frpc just fine and everything works.

from frp.

Exposure of services on the public network being accessed or scanned is very normal, you can troubleshoot traffic on port 443 by capturing packets.

from frp.

You are right, didn't think about that.

There are ~5 incoming TCP connections per second on port 443. Each connection attempt has about 8-9 packets exchanged with about 500 bytes of data total.

frps with loglevel of debug or trace, shows tons of messages like this:

2024/03/11 11:20:51 [D] [vhost.go:206] get hostname from http/https request error: tls: first record does not look like a TLS handshake

So I am thinking:

• Is there any way the server can limit the amount of processing required for these invalid connections? (I guess this is unlikely, given the amount of packets seems already very small.)
• Could you add more comprehensive logging for failed connection or authentication attempts, that include IP (and port)? Then a tool such as fail2ban could be used to ban hosts with repeated failed connections attempts, based on the log file.

from frp.

Perhaps there are more professional tools/proxies available that can be used to identify/configure some simple protection rules.

Currently, frp will not make too many changes in this regard; this is more like a capability of a WAF gateway.

from frp.

Right, this kind of protection is not the responsibility of frp. This is a small/hobby project so I can't invest in extra services – but I've managed to get the CPU down to idle levels by simply rate limiting incoming connections to the frp server.

Still, would you be willing to accept a PR to include the IP of failed connections in the log output? I feel this could help elsewhere as well, debugging other issues...
EDIT: Looking at the code, might be too hard for me actually, to get this right ;)

from frp.

Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

from frp.