Block Brute Force RDP attempts

[Sjoerd]

I have a Palo Alto 820 up and running, and one of its roles is to publish an terminal server (on its default port3389, the Terminal Server have an 2 factor authentication mechanism.)

I see lots of connections, and i would like to block this brute force attempts, so I configured a Vulnerability Protection Profile which blocks threats with host type = server, and severity = high.

I changed the default time attributes of Threat 40021 (MS-RDP Brute Force Attempt) from 8 hits per 100 seconds to 10 hits per 300 seconds (since I see approximately 3 attempts per minute from the same IP for a long amount of time). I left the aggregation criteria to its default (source-and-destination)

However, I’m not able to trigger this threat. I did 20 failed logon attempts within a minute or 2, and after this I was able to connect successfully.

So: How can I stop these brute force attacks?

Further more: What happens if this would have worked? I guess the IP address of the attacker gets blocked for a specific amount of time. Where can I see these blocked IP’s? And is it possible to (manually) unblock this IPs?

[Sjoerd]

OK, a short update on this issue:

I added a rule on top of my vulnerability protection profile to block ip’s on all threats of the category brute-force as descripted in this article.

However: I used the same profile on my outbound rules which resulted in several users getting blocked cause of threat ID 34556 (HTTP Unauthorized Error). So, I created a separate profile for the outbound rule.

I had to remove the addresses from the block list, and this answered one of my questions (how to see / manage this blocked IPs) by this article. I think this can't be done through the GUI?

However: I’m still able to do a brute force from the outside, and the IP from where I try the attempts doesn’t get blocked. How to fix this?

Now I understand I should set the action to block-ip, but this raised another question: what does a drop do with a threat of the category brute-force? If I set it to 10 hits it will drop the 11th? But what does it do with the 12th?

[BPry]

@Sjoerd,

I think you are going about this a little wrong. A few things that I can think of off hand. 

1) Why are you publishing a terminal server on 3389 open to the public? Of course this is getting scanned, while you can mitigate this you'll always run into an issue with scanning and brute force attempts simply because you are using the default port. I would change this to a non-standard port, otherwise you'll continue to have the same problem. This just isn't the best idea in general. 

2) If you are going to publish a terminal server like this I wouldn't even think of vulnerability profile protections being good enough to secure this server. You need to look at DoS Protections and baselining this traffic. This is a really good use case of classified profiles with Session limits imposed. 

3) The proper 'secure' way of publishing a terminal server is through a VPN client such as GlobalProtect so that you don't have to leave access to a machine open to the outside world. If that isn't possible then you should limit the ability to access this server to set source addresses. If that isn't ideal you limit to certain source ranges, if you can't do that you move to source countries. 

The Drop action in a vulnerability profile is going to drop all traffic for the session. So as soon as that session expires and moves off the session table that same source can start attacking your server again. If the server continues to hammer your terminal server and the session never expires and gets removed from the session table the drop action will continue to function. 

[Sjoerd]

Thnx for youre response BPry!

1) Unfortunately my experience is that the hackers will also find the non-standard port. Nevertheless: you’re right, I will change this default port.

2) I will have a further look at DoS Protection.

3) Unfortunately this is not an option for the customer.

I think your explanation about the drop action makes it a little bit more clear to me.

I’m gonna grab a beer and dive in to it on Monday.

[jvalentine]

It's been a while since I last looked at the Brute-Force RDP signature, so take this with a grain of salt.  

The MS-RDP Brute Force Attempt signature, by default, triggers when Vulnerability Protection signature ID 33020 (Microsoft remote desktop connect initial attempt) fires 8 times within 100 seconds.  Signature ID 33020 is informational severity with default action = allow.  You won't see this fire in your threat logs unless you change the action for this signature to "alert"

 

(Also note that there are 2 different MS-RDP Brute Force signatures that you'll want to change action to Block-IP: 40021 and 40026.  See pic above.)

When I tested this, the signature 33020 fires each time a TCP connection is made to the RDP server.  Keep in mind that this one TCP connection will allow you to try ~3 passwords before it disconnects.  If you connect, try 3 wrong passwords, and get disconnected - that will be logged as 1 occurance of 33020.  It's not per-password, it's per-session/connection.  

So, with default timings, you may have to try 3 (passwords per session) * 8 (tcp sessions) = 24 password attempts, all within 100 seconds, in order to trigger this brute force signature.  

In order to troubleshoot the behavior, I would do the following:

 - Change signature 33020 behavior to "alert"

 - Change signature 40021 and 40026 timing to Number of Hits = 3 within 100 seconds

When configured appropriately, it can be a very powerful signature.  I assisted in the deployment of a Palo Alto Networks firewall at the border of a University.  They first deployed with Threat Prevention signatures in "alert" only mode.  We logged 130k ms-rdp brute force attempts in a single day.  8 TCP sessions per attempt * 130k occurances = 1Mil connections.  1Mil connections * 3 passwords per connection = 3Million passwords/day.  

At the end of that day, we changed the action to block-ip for 300 seconds (5 minutes).  The very next day the # of rdp brute force occurances was less than 2k (down from 130k!).  I encouraged them to move the block-ip duration to 3600 seconds (1 hour) once they were comfortable with how the brute force signatures worked.  I'm sure that would have dropped the daily 2k occurances into the low hundreds.  

When used properly, it can be a powerful tool.  You just want to make sure you "tune it" so that you're not tagging legitimate traffic/users - and have a well-known process in place to unblock a legitimate user. 

Good luck!

[Sjoerd]

Thanks for you’re detailed explanation jvalentine!

All sounds pretty logical, but I’m still not able to get this to work.

As you suggested we set signature ID 33020 to alert on the Vulnerability Protection Profile attached to the RDP publish Security rule. Both signature ID 40021 & 40026 are set to 3 hits per 100 seconds in this profile and the action is block.

We tested a brute force attack: 5 attempts per seconds using a user name / password file including a correct one, which successfully found the correct username. Nothing shows up in the threat log. The traffic log however was filled up with this attempts (action allow).

Since we suspected this would possibly had something to do with the NLA on our 2012 server, so we also tested this to an older server with NLA disabled. No difference.

What I also noticed is when I committed my changes it gave me an error:

Profile compiler : can not find tid 40026 in threat database

When I lookup the threat ID in the online Threat Vault, it also give’s me a different description (SSL Renegotiation Denial of Service Brute Force).

For now I only allowed connections from my own country.

Is there anyone out there who can help me out on this?

[TerjeLundbo]

We used to have loads of brute force attempts on our firewall (not RDP but SSH). After we started using EDL and blocked all traffic from these addresses the problem is much reduced. This might be able to help you combined with finetuning the threat signatures.

http://panwdbl.appspot.com

[DMartinek]

Were you able to make the firewall trigger the 33020 signature and therefore trigger the 40021 to block the MS-RDP brute-force?

I have a similar setup at one of my customers site - configured a top-level rule to allow RDP to a specific terminal server, assigned vulnerability profile to block-IP anything in category brute-force, created exceptions for 33020 (changed action to alert) and 40021 (lowered the default value of 40021 from 8 req per 100 sec to 5 req per 100 sec).

I am seeing the ms-rdp requests in Traffic log with action allowed but there is nothing in the Threat log. This is overloading the terminal server making the valid users unable to connect.

Thanks.