You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I changed the Windows 3389 port through the router to a high value port and exposed it to the public network. I was attacked by brute force password cracking attacks every time. This software really helped. As can be seen from the RDSH 140 incident, password guessing occurred after using RDPBloker stopped, but as can be seen from the RDSH 131 event and Wireshark packet capture, the TCP connection is still established, and the entry that RDPBlocker should have created cannot be found in the Windows Advanced Firewall panel. Fail2ban feature seems not working. It is recommended that these attack sources be added to the firewall blacklist and TCP connections should not be established.
before-rdpblocker
after-rdpblocker-running
The text was updated successfully, but these errors were encountered:
In the current version, any failed login attempts via RDP are logged in the "Security" event, so currently only the "Security" event is subscribed to.
From your screenshot, it appears that the IP you are trying to block is just trying to establish a TCP session where the client tries to log in, but the system rejects the request because it doesn't meet the system's security requirements.
The fact that the system rejects the session request and the client fails to attempt to enter a username and password has no impact on system security.
If it's just establishing a connection, I don't think the firewall needs to do anything. For the most part we should assume that any IP can try to establish a connection to the server and the firewall should not block them without a clear reason.
I changed the Windows 3389 port through the router to a high value port and exposed it to the public network. I was attacked by brute force password cracking attacks every time. This software really helped. As can be seen from the RDSH 140 incident, password guessing occurred after using RDPBloker stopped, but as can be seen from the RDSH 131 event and Wireshark packet capture, the TCP connection is still established, and the entry that RDPBlocker should have created cannot be found in the Windows Advanced Firewall panel. Fail2ban feature seems not working. It is recommended that these attack sources be added to the firewall blacklist and TCP connections should not be established.
before-rdpblocker
after-rdpblocker-running
The text was updated successfully, but these errors were encountered: