racknerd, why do you always permit 107.173.42.94 to abuse again and again

apollo15 · August 7

Whats your badge number?

inoricat · August 7

It seems iptables -J DROP is a lost art nowadays. You should try it OP

markrao888 · August 7

Yes, I enhance my vps security after that. But it doesn't stop this compromised machine from brute-forcing other oblivious users across the internet.

If 'just dropping the IP' is the only lost art we need, then why do providers even bother having an Abuse department or AUP (Acceptable Use Policy)? An ISP that relies entirely on external victims to act as its free intrusion detection system is fundamentally broken.

Mainfrezzer · August 7

@markrao888 said:
Yes, I enhance my vps security after that. But it doesn't stop this compromised machine from brute-forcing other oblivious users across the internet.

If 'just dropping the IP' is the only lost art we need, then why do providers even bother having an Abuse department or AUP (Acceptable Use Policy)? An ISP that relies entirely on external victims to act as its free intrusion detection system is fundamentally broken.

You haven't managed to provide anything that even resembles abuse. The only logs were the IP using post on some API. That's not abuse. If you have some proper logs, come again.

markrao888 · August 7

@Mainfrezzer said:

@markrao888 said:
Yes, I enhance my vps security after that. But it doesn't stop this compromised machine from brute-forcing other oblivious users across the internet.

If 'just dropping the IP' is the only lost art we need, then why do providers even bother having an Abuse department or AUP (Acceptable Use Policy)? An ISP that relies entirely on external victims to act as its free intrusion detection system is fundamentally broken.

You haven't managed to provide anything that even resembles abuse. The only logs were the IP using post on some API. That's not abuse. If you have some proper logs, come again.

This is like the log that somebody logged in your vps, what do you want more? give you the whole log?

markrao888 · August 7

I alreay enchance my vps, but there are still many victims
https://linux.do/t/topic/2662508
https://linux.do/t/topic/2426372

It seemed many people support racknerd to do nothing, that surpirsed me!!!

Mainfrezzer · August 7

@markrao888 said:

@Mainfrezzer said:

@markrao888 said:
Yes, I enhance my vps security after that. But it doesn't stop this compromised machine from brute-forcing other oblivious users across the internet.

If 'just dropping the IP' is the only lost art we need, then why do providers even bother having an Abuse department or AUP (Acceptable Use Policy)? An ISP that relies entirely on external victims to act as its free intrusion detection system is fundamentally broken.

You haven't managed to provide anything that even resembles abuse. The only logs were the IP using post on some API. That's not abuse. If you have some proper logs, come again.

This is like the log that somebody logged in your vps, what do you want more? give you the whole log?

Listen, you cant be a muppet and then punish someone else for it.

Here is an example of a proper abuse log

i cant post it as text as cloudflare REALLY dislikes it

markrao888 · August 7

@Mainfrezzer said:

@markrao888 said:

@Mainfrezzer said:

@markrao888 said:
Yes, I enhance my vps security after that. But it doesn't stop this compromised machine from brute-forcing other oblivious users across the internet.

If 'just dropping the IP' is the only lost art we need, then why do providers even bother having an Abuse department or AUP (Acceptable Use Policy)? An ISP that relies entirely on external victims to act as its free intrusion detection system is fundamentally broken.

You haven't managed to provide anything that even resembles abuse. The only logs were the IP using post on some API. That's not abuse. If you have some proper logs, come again.

This is like the log that somebody logged in your vps, what do you want more? give you the whole log?

Listen, you cant be a muppet and then punish someone else for it.

Here is an example of a proper abuse log

i cant post it as text as cloudflare REALLY dislikes it

Do you know CPA and CPA how to log? Yes, you cant be a muppet and then punish someone else for it.

Mainfrezzer · August 7

@markrao888 said:

@Mainfrezzer said:

@markrao888 said:

@Mainfrezzer said:

@markrao888 said:
Yes, I enhance my vps security after that. But it doesn't stop this compromised machine from brute-forcing other oblivious users across the internet.

If 'just dropping the IP' is the only lost art we need, then why do providers even bother having an Abuse department or AUP (Acceptable Use Policy)? An ISP that relies entirely on external victims to act as its free intrusion detection system is fundamentally broken.

You haven't managed to provide anything that even resembles abuse. The only logs were the IP using post on some API. That's not abuse. If you have some proper logs, come again.

This is like the log that somebody logged in your vps, what do you want more? give you the whole log?

Listen, you cant be a muppet and then punish someone else for it.

Here is an example of a proper abuse log

i cant post it as text as cloudflare REALLY dislikes it

Do you know CPA and CPA how to log? Yes, you cant be a muppet and then punish someone else for it.

You not knowing how to setup proper logging doesnt make it magically possible to enforce "trust me bro". Thats a you problem.

I could just say you abused me. You used POST on my contact form. They should drop you asap!

CheepCluck · August 7

The only action here is to obviously call the FBI.

forest · August 7

@CheepCluck said:
The only action here is to obviously call the FBI.

They're busy oppressing people, but I've got the next best thing: Andrew from legal.

AlteredParadox · August 7

@forest said:

@CheepCluck said:
The only action here is to obviously call the FBI.

They're busy oppressing people, but I've got the next best thing: Andrew from legal.

ralf · August 8

@markrao888 said:
https://linux.do/t/topic/2662508/20
https://linux.do/t/topic/2426372

Racknerd, why do you alwasy permit 107.173.42.94 to abuse again and again? There are already many victims reported this CPA abuse.

Still not sure what CPA even after reading this thread and the linked one, but just set up an iptables rule to drop all traffic from that IP if they keep bothering you. Solved.

markrao888 · August 8

@dustinc anything to update?

LEmeINalr · August 8

Dustinc runs a business, they provided the proper route for you to contact them.
No provider in their right mind would keep scrolling this forum to look for every mention of theirs to reply to when they could do it by the ticket they asked you to make.

PuDLeZ · August 9

Bro, Dustin replied on what to do like 35-ish minutes after this thread was created and mentioned the proper steps, even said you can reach out to him directly. You said you created a ticket, what was/has been the update(s) on it? You say this stealing is happening because of improper configs/weak password, has this been fixed or are you expecting not to do anything regarding it? I'm guessing nothing since you said you got this suspended before for this and the same thing is happening again... If you did nothing to fix the config/password, maybe the owner of the VPS/ip is just like you, they have a bad config/weak password and don't do anything about it to prevent others from abusing it after the previous suspension.

It is really mind blowing how you take the community giving you a simple solution to ignore this IP as them saying they agree with the abuse and not to report it. The solution is to immediately stop the IP from using your improperly config/weak password app while you work through the proper channels to report it... Though, if reporting is your method to prevent abuse, I feel sorry for you going through your logs and reporting all the skids port scanning, trying default/common creds, standard urls (like for word press), and so on... Because there's no way just this one ip is the only thing trying something...

markrao888 · August 9

My complain is that Racknerd that I reported, then suspended, then I reported agian, then suspend again, But now the IP do abuse again...

Bro, I already enhance my own vps after first attack, and I do not experience stealing after first attck. But many people still reportt the IP is stealing other people's gpt tokens. You may check linux.do forum for many reports there.

What I compalin here is that Racknerd do not terminate the IP even there are so many reports in linux.do

I complain here not for me myself, but for many victimes.

rpqu · August 9

@markrao888 said:.

What I compalin here is that Racknerd do not terminate the IP even there are so many reports in linux.do

If he's banned, he will just purchase another vps from nodeseek reseller. So, why bother when the solution is rather simple: drop packets from that IP.

forest · August 9

@markrao888 said: Bro, I already enhance my own vps after first attack, and I do not experience stealing after first attck. But many people still reportt the IP is stealing other people's gpt tokens.

If they are exposing a public service, it's entirely their fault that other people are using it.

Set a damn password or IP whitelist.

bozolover99 · August 9

CPA certified public account?

markrao888 · August 9

Yes, the CPA user should take actions, but not every CPA user are expert.
What I complain here is what Racknerd should do?

rpqu · August 9

@markrao888 said:
Yes, the CPA user should take actions, but not every CPA user are expert.
What I complain here is what Racknerd should do?

Just make a script. Heck, where's the CPA repo?

forest · August 9

@markrao888 said: What I complain here is what Racknerd should do?

Nothing? Because no one is abusing anything? The IP is just using a public service.

rpqu · August 9

LOL
https://github.com/router-for-me/CLIProxyAPI
https://github.com/Git-creat7/grokRegister-cpa
https://github.com/Maoleio/CPA-Codex-Manager
https://github.com/Willxup/cpa-usage-keeper
https://github.com/seakee/CPA-Manager-Plus
https://github.com/basketikun/chatgpt2api
https://github.com/QLHazyCoder/FlowPilot

OpaqueRegistrant · August 9

Who cares if someone is scanning for default passwords if you don't have a default password?

AI proxy services are "abuse" for OpenAI/Anthropic. Would you also think they should terminate your VPS for abuse?

Just set a password.

rpqu · August 9

@markrao888 @forest

https://github.com/router-for-me/CLIProxyAPI/issues/4733
Describe the bug

The management-API brute-force protection in internal/api/handlers/management/handler.go
tracks failed attempts and bans keyed on c.ClientIP() (Gin's helper), but the engine
is never configured with SetTrustedProxies() anywhere in the codebase
(internal/api/server.go just calls gin.New()).

Gin v1.10.1's gin.New() defaults to:

trustedProxies:  []string{"0.0.0.0/0", "::/0"}
RemoteIPHeaders: []string{"X-Forwarded-For", "X-Real-IP"}
ForwardedByClientIP: true

Context.ClientIP() treats any direct TCP peer as a "trusted proxy" (since the
trusted CIDR list is 0.0.0.0/0), and then blindly returns whatever value is in the
X-Forwarded-For (or X-Real-IP) header — with no validation that the request actually
passed through a real reverse proxy.

Impact

Anyone who can reach the CLIProxyAPI listening port directly (e.g. from inside the same
Docker network, bypassing an intended reverse proxy like Caddy/Nginx) can set an
arbitrary X-Forwarded-For: <any IP> header. Combined with the 5-failed-attempts /
30-minute ban in AuthenticateManagementKey, this allows:

Framing an arbitrary third-party IP: repeatedly send failed management-key auth
requests with X-Forwarded-For set to a victim's real IP, causing that IP to be
banned indefinitely (each forged failure re-arms the 30-minute countdown before it
ever reaches zero) — a denial-of-service against an unrelated, innocent IP.
Evading a ban on the attacker's own real source by simply rotating the forged header
value on every attempt.

In our deployment (Docker + Caddy, CLIProxyAPI's port is not published to the host,
only reachable via the reverse proxy or from other containers on the same bridge
network), we observed exactly this: unauthenticated requests hitting
/v0/management/api-keys directly on the container's internal port, bypassing Caddy
entirely, roughly every ~70s, receiving fast-path 403 "IP banned" responses — consistent
with a forged/arbitrary IP identity being continuously re-banned rather than a real
client's own repeated failures.

To Reproduce

Connect directly to the container's management port (bypassing any reverse proxy).
Send 5 requests with an invalid management key, each with
X-Forwarded-For: 203.0.113.1 (or any arbitrary IP).
Observe that AuthenticateManagementKey bans 203.0.113.1 — an IP that never
actually made a TCP connection to the service.

Expected behavior

The ban should be keyed on the real TCP peer address unless the connection genuinely
came through an explicitly configured, trusted reverse proxy. X-Forwarded-For /
X-Real-IP should not be trusted from arbitrary direct connections.

Suggested fix

Call engine.SetTrustedProxies([...]) in internal/api/server.go with the actual
trusted reverse-proxy address(es)/CIDR (e.g. the reverse-proxy container's IP or the
Docker bridge subnet), instead of relying on Gin's insecure "trust everyone" default.
Alternatively, document clearly that operators MUST set this (or disable
ForwardedByClientIP) whenever the management port is reachable from anything other
than the trusted reverse proxy — otherwise the IP-ban mechanism can be trivially
bypassed and turned into a griefing tool against arbitrary IPs.

Environment

CLIProxyAPI: latest (main, as of 2026-08)
Gin: v1.10.1 (per go.mod)
Deployment: Caddy reverse proxy + Docker bridge network; CLIProxyAPI container does
not publish its port to the host.

!

Thank you for the detailed report. The risk of automated scanning and brute-force traffic against an exposed service is indeed difficult to address. However, users deploy CLIProxyAPI in substantially different environments: directly on the public Internet, on private networks, behind a CDN, behind Nginx/Caddy, through Cloudflare Tunnel, or behind LVS load balancers. These topologies have different trusted-proxy and client-IP semantics, so there is currently no good, universally safe way for the application to handle this consistently.

For now, our recommendation is to deploy the service in an environment fully isolated from the public Internet and configure a sufficiently strong management key. We are closing this issue as not planned because we do not currently have a one-size-fits-all application-level solution that would be safe across these deployment models.

Is it that hard to make a fork and automated pull from upstream, then rebase and commit in different branch?

Howdy, Stranger!

Categories

In this Discussion

racknerd, why do you always permit 107.173.42.94 to abuse again and again

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

racknerd, why do you always permit 107.173.42.94 to abuse again and again

Comments