Your broker account probably has two factor authentication on it. The machine that places the orders often still has the password it was given on setup day. Attackers do not need to beat your broker’s security if the server holding your terminals is the softer target.
Key Takeaways
- The traffic is automated, not personal. Roughly 165,000 failed logins a day across our fleet, none of them aimed at anyone specific.
- FXVPS runs RDP on port 41011, not 3389. That alone removes you from most bulk scanning.
- The setup password is the weak point. Change it to a long, unique passphrase.
- An account lockout threshold turns an endless guessing attack into a few attempts and a stop.
- Event Viewer tells you what actually happened, rather than what you are worried might have.
1. What Is Actually Out There
There is a persistent idea that a small trading account is not worth attacking. That misreads how this works. Nobody is choosing you.
What runs against every internet-facing server is automated software sweeping address ranges, knocking on well known ports and trying short lists of common usernames and passwords. It is cheap, it never stops, and it does not know or care what the machine is for. A server that has been online for a week has already been probed thousands of times.
The number we measure across our own fleet is around 165,000 failed login attempts in any 24 hour window. That is the ordinary background level for Windows servers on the public internet, not a sign of an incident.
What matters is that a tiny fraction of those attempts succeed somewhere, every day, and it is almost always because of one of three things: the default port, a password that was never changed, or a predictable username.
2. The RDP Port
Remote Desktop listens on port 3389 by default, and that is the first and often only port those bulk scans try.
FXVPS servers use port 41011. You connect by putting the port after the address, like this:
1.2.3.4:41011Two useful consequences. First, the volume of traffic that finds you at all drops sharply, because most scanning never looks past the default. Second, and worth remembering when something looks wrong, a server that does not respond on 3389 is not down. If you are testing whether your VPS is alive, test the port it actually uses.
Moving the port is not encryption and it is not authentication. A determined scan of all ports will still find an open service. It is a filter that removes the overwhelming bulk of automated noise, which is exactly what you want it to do.
3. The Password You Were Given
Every VPS ships with a generated password so you can get in the first time. It was created by a system, sent to you, and now lives in an email inbox and possibly a chat history.
Replace it. This is the highest value item on this page.
Length beats complexity. A passphrase of four or five unrelated words is far harder to attack than eight characters of punctuation, and you can actually remember it. What matters most is that it is unique. A password reused from anywhere else is only as strong as the weakest place you have used it.
While you are there, think about the username. Automated attempts overwhelmingly try administrator, admin, user, test and a handful of others. A username that is not on that list quietly removes you from most of the attempts.
4. Lock the Door After a Few Tries
Windows can stop a guessing attack on its own, and it is off by default.
Open Local Security Policy, then Account Policies, then Account Lockout Policy. Set an Account lockout threshold of five or ten invalid attempts, with a lockout duration of fifteen or thirty minutes.
That changes the arithmetic completely. An attacker who could otherwise try passwords indefinitely now gets a handful of guesses per lockout window. Set the threshold too low and you will lock yourself out after a typo, which is why five to ten with a short duration is the sensible range rather than three.
5. Restrict by Address If You Can
If you connect from a static IP address, you can tell Windows Firewall to accept RDP only from it. Open Windows Defender Firewall with Advanced Security, find the inbound RDP rule, and set a Scope limiting the remote address.
Be careful here, and be honest about your connection. Most home broadband addresses change. If yours does and you lock the rule to it, the next change locks you out of your own server. If you travel, or connect from a phone hotspot, this is not the control for you. When it does apply, it is the strongest item on this list, because it stops the attempt before authentication is ever reached.
6. Check What Has Actually Happened
Rather than wondering, look.
Open Event Viewer, expand Windows Logs, and select Security. Two event IDs matter:
- 4625 is a failed logon. You will see a great many of these. Their presence is not an incident, it is the internet.
- 4624 is a successful logon. This is the one to read carefully. Every entry should correspond to you, from a place and at a time that makes sense.
If you find a successful logon you cannot account for, change the password immediately from a machine you trust, then check for scheduled tasks, new user accounts and anything running that you did not install.
7. What We Handle, and What Is Yours
Worth being clear about the split.
We run the network and the hypervisor, we keep RDP off the default port, and we watch the infrastructure the servers sit on. What happens inside your Windows instance is yours: the password, the accounts, the lockout policy, the firewall scope and the software you install.
That division is normal for any VPS, managed or not. Nobody else can choose your password for you, and a provider that could log into your trading server whenever it liked would be a bigger problem than the one this page is about.
Five minutes of the checks above puts you well past the point where any automated attack is going to get anywhere.