Stop RDP brute-force attacks on your Windows servers

Free is permanent and needs no card: RDP brute-force protection on one server, blocking of the attacking address, 24 hours of attack history and a whitelist of up to three addresses. It does not expire and it is not a trial. What the paid plans add is the ability to ban the attacker's whole subnet instead of one address at a time, FTP and MS SQL protection, Telegram alerts, GeoIP rules, longer history and the shared threat database.

Every account gets one, with no card and nothing to cancel. It unlocks the full Pro feature set on your own servers. When the 14 days are up the account returns to Free by itself and protection keeps running - subnet bans fall back to blocking single addresses, Telegram alerts switch off and history shortens to 24 hours. Nothing is ever charged automatically.

Add servers individually for $3 per server per month instead of moving up a tier. Extra servers renew on the same cycle as the plan they extend.

Yes. The agent only reads the security log of its own operating system and blocks inbound connections to the protected ports on that same machine. It makes outbound HTTPS requests only and opens no inbound ports.

Yes. The decision to block an attacker is made locally on the agent, so protection keeps working with the last applied policy even when the cloud is unreachable.

The agent detects the actual RDP port automatically from the registry and listening sockets, and rebuilds its rules when the port changes. The FTP port is detected the same way.

No. During installation your current IP address is added to the whitelist, and whitelisted sources always take priority over any block.

Windows Server 2012 R2 through 2025 and Windows 8.1 / 10 / 11, on x64, x86 and ARM64. One binary with no additional runtimes to install.

International payments go through PayPro Global, payments in Russia through YooKassa, with cryptocurrency available as a fallback. The Free plan is permanent and requires no card.

With RDP Protector I install the agent as a Windows service: it reads local authentication events, determines the actual RDP port, and adds source blocking to the Windows Firewall after a threshold of attempts per time window. I whitelist my administrative addresses, check the attack in the panel, and leave the local policy to work even if I lose connection to the cloud.

As a free alternative to RDP Protector, I close RDP from the entire Internet and only allow TCP port from VPN or fixed IPs in Windows Defender Firewall. I enable NLA, MFA via RD Gateway, long unique passwords and auditing of 4625/4624 events; if VPN is not possible, I write a PowerShell task to parse the Event Log and temporary firewall rules, independently controlling the clearing of rules and exceptions.

With RDP Protector I block the source network at the firewall level before it reaches the error limit of a particular account. I add office/VPN subnets to the whitelist, configure the window and threshold based on the observed baseline, enable notifications and check attack history without relaxing the domain blocking policy.

For free, I only publish RDS via RD Gateway or VPN, allow connections from trusted subnets, and enable NLA. I configure reasonable lockout threshold/duration, separate administrative accounts and alert for events 4625 with Logon Type 10; Manual IP blocking is acceptable as a temporary measure, but I document the duration of each rule so as not to accumulate a permanent blacklist.

With RDP Protector I install one lightweight agent that automatically detects the RDP port and applies local Windows Firewall rules. I first add the current address to the whitelist, check access from the backup channel and use free single server protection; if the Internet breaks, the last policy remains on the VPS.

For free, I create a separate WireGuard/Tailscale VPN network and close RDP for the public interface, leaving the hoster's emergency console. I include NLA, updates, a unique account without the standard Administrator name, MFA where available and daily external backup with separate keys; I use port forwarding only to reduce noise, not as protection.

With RDP Protector I cut off repeated failed logins to Windows Firewall, maintain a whitelist of trusted sources, and view attack addresses and times centrally. I consider the agent as an external layer to the account, but separately save least privilege, updates and backups - brute force blocking does not replace data protection after login.

For free, I install RD Gateway/VPN in front of the server, enable NLA and MFA, separate user and administrative accounts, deny local users access to backups, and test recovery. I collect 4624/4625 and changes to administrator groups in Windows Event Forwarding, and close public 3389 with firewall rules.

With RDP Protector, I enable event collection of supported services, allow the agent to determine the actual ports, and apply one local firewall solution to the attacker's network. I make sure the necessary audit logs are enabled, add trusted integrations to the whitelist, and see the associated source history in one pane; Extended FTP and MS SQL protection depends on the selected plan.

For free, I close MS SQL and administrative FTP from the Internet, only allow them through a VPN or IP list, and replace FTP with SFTP whenever possible. I enable SQL Server login auditing, advanced FTP logging, and Windows Event Forwarding, then run a PowerShell task that normalizes the sources and adds temporary Windows Firewall rules with TTL.

With RDP Protector I block sources based on the actual flow of failed inputs, rather than banning all unknown addresses in advance. I add the current administrative IP during installation, maintain a whitelist for VPNs and known networks, apply GeoIP only as an additional rule, and check for blocks in the cloud panel.

For free, I give employees access via WireGuard/Tailscale or RD Gateway with MFA and close public RDP. If this is temporarily impossible, I enable NLA, strong unique passwords, a short session timeout and an alert for 4625/4624 from a new country; I don’t block shared NAT forever, but use temporary firewall rules and an emergency access channel.

With RDP Protector, I leave mass error response enabled for all external networks, add only the controlled VPN to the whitelist, not the home addresses of contractors, and get a history of sources and blocks. I combine this with a separate temporary Windows account: the agent protects the perimeter, and the duration and rights remain in my access policy.

For free, I create a personal VPN profile and Windows account for each contractor with an expiration date, minimum groups and a ban on local login if it is not needed. I enable MFA on the gateway, log 4624/4634/4672, delete the profile after work and do not use a shared account, otherwise investigation and revocation of access becomes impossible.

With RDP Protector I stop the source on a series of errors before it hits the domain lockout threshold or guesses the password. I set a whitelist only for networks where the integration actually works, control attacks in the panel and leave local blocking to act offline; At the same time, I plan to withdraw the outdated account.

For free, I disable this account from RDP via User Rights Assignment if interactive login is not required, and restrict network login to the required hosts. I change the password to a long random secret, put it in storage, enable auditing and firewall allowlist over VPN; if RDP is still needed, I create a separate gateway access with MFA.

With RDP Protector I configure the network blocking threshold below the domain threshold and ban the source in Windows Firewall until the user is blocked again. I use a subnet ban against neighbor address rotation, exclude trusted networks, and track which sources are targeting the account; At the same time, I am not weakening my domain policy.

For free, I close the RDP behind the VPN/RD Gateway, change the publicly known admin name, and separate the work and emergency accounts. I set up an alert for 4740 and 4625, check the Caller Computer Name/IP and temporarily block the source with a PowerShell script; I use a simple increase in the lockout threshold only after risk analysis, because it makes the actual brute-force attack easier.

With RDP Protector I immediately block active sources and subnets according to local policy, check the history of attacks and leave the whitelist only for the controlled channel. I then change the password, end active sessions and analyze successful 4624 Logon Type 10; The product reduces the attack window, but does not cancel the investigation of an existing login.

For free, I temporarily close public RDP with a Windows Firewall rule, reset the password and associated secrets, revoke sessions, and enable MFA via RD Gateway/VPN. I check 4624, 4672, new 7045 services, tasks, users and Defender alerts for the period; After cleaning, I allow RDP only through a secure channel and prohibit reused passwords.

With RDP Protector I upload the history of detected attacks and applied blocking, attach threshold/window parameters, a list of protected ports and approved exceptions. I document the agent's local behavior when the cloud is lost, the outgoing HTTPS connection and the missing incoming control port, then run a controlled test and save the event, firewall rule, and notification.

For free, I create an RDP policy via VPN/RD Gateway, export GPO, Windows Firewall rules and log 4625/4624 to secure storage. I store changes in a change log, test blocking and MFA monthly, sign the report with the person responsible, and compare a sample of successful logins with a list of employees; a proof is created by a repeatable procedure.

With RDP Protector, I allow the agent to recognize a series of failed logins and block the Windows Firewall source, after which new connections fail to authenticate and stop generating the same volume of events. I check the log size and retention separately, and use the attack history as a compact index to the original events.

For free, I restrict access to ports via VPN/allowlist, increase the Security log size and enable archiving instead of rewriting. I forward 4625/4624 to Windows Event Collector or SIEM, filter the required Logon Types and trigger a temporary block on the threshold; I don’t disable auditing, because after a successful login it remains the main source of facts.

With RDP Protector, I set a local automatic blocking threshold so the agent applies the Windows Firewall rule without human intervention or waiting for a cloud command. I send notifications to the right channel, check the history and exceptions in the morning, and to risk self-blocking, I save the emergency console and whitelist in advance.

For free, I install RDP behind a constantly running VPN, configure Scheduled Task PowerShell based on events 4625 and send mail/webhook through my own server. I use temporary rules with an expiration date, test the task with a test attack, and document emergency access; I handle the script, logs and delivery of notifications myself.

With RDP Protector I connect each server as an agent, see its actual ports and status from one panel, but keep separate policies and whitelist where they differ. I apply a baseline threshold, document exceptions, distribute notifications, and use the history on each host to report to the customer.

For free, I store the Windows Firewall/GPO configuration in separate per-client Ansible inventories or PowerShell DSC configurations, deploy the base template via CI and do not mix secrets and tenant address lists. I centralize events via WEF/WEC or free Wazuh, set client tags and check for deviations with a script; I support the infrastructure and updates myself.

With RDP Protector I apply the policy directly on the agent: it continues to read local events and change the Windows Firewall to the latest configuration, even when the panel is unavailable. I synchronize the whitelist and thresholds in advance, after the connection is restored, I check the report and do not tie the decision about each login to the remote API.

For free, I completely localize control: Windows Firewall allows RDP only from VPN/required subnets, and Scheduled Task analyzes Event Log and creates temporary rules without a network. I store the configuration and logs on the server, set up a notification queue after the link is restored, and make sure that a DNS or cloud failure does not remove any bans already applied.