cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1827
Views
10
Helpful
3
Replies

RDP Account brute force attempts

cshackel77
Level 1
Level 1

We have a customer experiencing brute force attempts to their RDP servers form randomizing source IPs.  The have ASA with FP IPS in place.  Looking for options to block this.  I've suggested restricting access to the RDP farm to VPN, or moving the listening port from 3389 to something else and then configuring the ASA to shun IP port scanning from the internet, but neither is convenient from a business prspective for them.

Thoughts? Thank in advance!

3 Replies 3

keglass
Level 7
Level 7

Hi, Cody,

I recommend you also post this to the Cisco Support Community for more feedback and information.

https://supportforums.cisco.com/

I hope this helps.

Kelli Glass

Moderator for Cisco Customer Communities

leciscokid
Level 1
Level 1

Use a signed certificate that only trusted clients trust, in their root store, for Server Auth. (aka set the servers to require TLS)

Client's attempting to brute force will get a NAG due to untrusted cert. So for instance, even if they wanted to self-sign a cert, for use on their Farm, all they need to do is push the CA down to their clients via RDP, or provide a download location for that CA cert.

This isn't a hardening maneuver, rather, more of a nuisance to the script kiddie, and the random passerby who just so happens to scan TCP DST3389 and see listeners.

The other thing is somehow they're (attacker) arriving at the conclusion you have some TermServers back behind that perimeter. They did this via some previous reconnaissance. Since they're probably using the same anonymizer to run the port scan as they are to perpetrate the DOS or BF attack, you can probably go back through your connection logs, and see where they did the initial scan of the perimeter.

Adjust the timers on half open connections (embryonic) to extremely aggressive. (such that if a simple NMAP hits a TCP 3389 socket, and doesn't present a valid RDP handshake, within 1-2 seconds you can slam the connection shut, either silent drop it, or send a hard RST to the sender)

these are just a couple techniques that come to mind, but all in all, a poor design, or a "publicly available" RDP front-end leaves much to be desired.

In lieu of some very "static" type Snort Rules customized to their environment, and depending on the size of the farm, my recommendation would be to put these behind an F5 Box, with an RDP WebTop, and run Auth to an external Radius, AD box, or whatever, and do multi-factor to prevent this sort of thing.

There's a write up somewhere on doing NLA with MS Term Services. Just lookup Network Layer Auth for Ms Term Services.

Thank you.  we did shun scanning from outside and locked the regional source of the initial scan (Ukraine) as well as updated snort rules.  Seems to have done the trick, but i will mention the TCP timer idea.  I doubt F5 is a feasible budget solution, but i may reach out to A10 and see what their products can do for this.

Thank you again!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: