mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #3637] [Feature Request] Add FRP antivirus note to documentation/README, maybe make FRP more visible on windows. #2903
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#2903
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ZeroVocabulary on GitHub (Oct 1, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3637
Describe the feature request
FRP is a reverse proxy, which has good uses, but is also useful for getting past firewalls and security.
There are reports of malware using FRP to communicate so that they are not as easily identified:
On a VirusTotal scan, you can see from the naming that some antiviruses are simply detecting it because of the utility for malware even though the antivirus vendors know it is not malware.
etc.
Because of this, I doubt that it will stop being detected, and the likely best outcome is FRP still getting detected but marked as Not-a-virus, HackTool, Riskware, etc. so that users are not scared.
The documentation/readme should mention this in order to avoid confusion, particularly for windows users.
Maybe visibility on windows could also be increased, but it might make it uglier/be a distraction. For example, an icon could appear in the system tray or taskbar when FRPC is running, which would make malware authors more likely to avoid using it.
Describe alternatives you've considered
No response
Affected area
@fatedier commented on GitHub (Oct 9, 2023):
Can you commit a PR to update the README?
@nirui commented on GitHub (Oct 9, 2023):
Hi, @fatedier, can you give the reports a closer look?
Apparently some features offered by FRP also made it a good tool for by hackers to facilitate actual attacks.
While changing the README is necessary to make users aware of the anti-virus situation before download/deploy, fundamentally something has to be changed in order to make this software less useful for attackers.
Showing an icon in the Windows system tray could be useful, but I'm afraid not to the degree that we might have hoped, since the analysis hosted on IBM X-Force Exchange suggested that the attacker might deploy their own fork of FRP with it's source code modified to help with their attacks. This in turn suggests that the attacker might also just remove whatever stinker code you put into FRP.
Maybe you can ship two versions? One open sourced one with limited forwarding capabilities (can only proxy specific protocols such as HTTP/HTTPS/FTP etc), and a close-sourced one with capability of relaying arbitrary TCP/UDP connections under numbers of hard restrictions (for example, hardcoded destination/port allowlist/blocklist).
Maybe you can also sell the close-sourced one for a profit too, which might help improve the personal situation that you've mentioned in the README file.
@ZeroVocabulary commented on GitHub (Oct 9, 2023):
The reason for detections is that reverse proxies are used to bypass firewalls/port restrictions (whether that be for legitimate or malicious reasons). Reverse proxies are the core feature of frp, so I don't think it is possible/realistic to reduce the usefulness to malware by removing features. I don't think the protocols matter; malware can easily switch and its a huge restriction for users.
With regards to forking/modifications, forcing malware authors to modify the program allows antivirus to flag the modification rather than the whole program. Beyond that, code signing/certification could be used to stop the files from being modified.
I'm not sure it is worth trying too hard to remove detection/appease AV via modifications, as AV vendors probably will not care. If I were managing a company's computers/network, I would prefer that these tools be flagged and require approval from admin/IT for use, which is probably the mindset the AV vendors have here. The fact that some AVs already mark it as not-a-virus shows that they know it is not malware but still wish to restrict it anyway due to its capabilities.
For the English readme update, I added a small addition to the examples (installation) section informing users about the problem. I linked this issue if people want further information.
I guess the issue can remain open after the readme change if the maintainers think more discussions/improvements can be done. Two improvements I like are:
I might try to do # 2 (will make a new issue if I do).
@nirui commented on GitHub (Oct 9, 2023):
I understand the thinking, but I couldn't agree with the conclusion, since there are other reverse proxies out there, and antivirus software is giving them a complete different treatment.
For example,
cloudflaredcan too facilitate reverse proxying while not been marked as any risk according to this VirusTotal report, the same is true forInlets Proandngrok.exetoo.All of those are reverse proxies, Inlets Pro even allows you to self-host, just like FRP. So what is the different that made FRP (and NPS actually) a target? Or, to put it into other words, why hackers used FRP, not Inlets or
cloudflaredorngrokor even just good oldsocat?@Wyk72 commented on GitHub (Oct 21, 2023):
Or, to put it into other words, why hackers used FRP, not Inlets or cloudflared or ngrok or even just good old socat?
Well, because frp is smaller, faster and easier to deploy. And it's basically freeware, ngrok is commercial and they will file lawsuits if they mark it as malicious, because it will END the company in one day. It's all about corporate mentality.
Anyway this AV issue will never go away.
The only solution/workaround I found for this is by using a (rather convolute) WSL2 approach i.e. run frpc/frps into this Linux layer they built into Windows.
100% legit.
P.S.
Anti-viruses and "security softwares" are the NEW SOFTWARE MAFIA/MOB.
@Andrewlilei commented on GitHub (Jan 17, 2024):
@Wyk72 , I tried to run frpc in WSL2 using latest 0.53.2_linux_amd64, but when I run frpc, it tells me :
-bash: ./frpc: cannot execute binary file: Exec format error.
Do you encountered this and how to solve it? Thanks
@Misiu commented on GitHub (Oct 10, 2025):
Is there a way to make FRPC not detectable by antivirus?
I can recompile FRPC and sign the exe file (I need it for Windows) with EV Code Signing, but I'm not sure if this will help, especially since the cert is expensive.
@nirui commented on GitHub (Oct 10, 2025):
I stopped replying after @fatedier closed this issue as completed. The problem about WSL approach is that, some anti-virius software is also targeting FRP's Linux binaries.
But... it looked like people are still finding this problem interesting, so I got one idea.
Since the hackers often used modified versions of FRP, maybe this problem can be resolved by:
Making it so FRP binaries can only be deployed by admin, and can only be run by admin or admin-delegated users.
This can be done through restricting the location of the FRP binaries, and enforcing an user group check run before serving. For example, refuse to run unless the application is deployed under
/user/bin/frpand the user trying to run it belongs to thefrpuser group.Normally hackers can't neither write files to
/user/bin/or creating user group, so even if they got the shell, they still can't run officially distributed FRP.If hacker got the root privilege to deploy FRP correctly on the server, then it's an admin/user negligent, not a fault on the FRP side at all.
After Point 1 is achieved, code-signing all officially disturbed FRP binaries with a publicly valid certificate. This ensures that the binary cannot be tampered by hackers, and thus the protections put in place in Point 1 cannot be bypassed.
Doing this might be expensive, but under the circumstance maybe wroth a try.
Doing so demonstrates FRP's willingness to prevent malicious usages, and also allow anti-virus software to better target actual bad-acting FRP binaries.
This should already clear FRP's name, if not, it could also gave FRP some leverage if a law sue is warranted.
All and all, justice is not a given, when injustice falls upon you, don't just sit there and cry, pick up everything you can and fight.