I'm trying to put into place blocking of brute force RDP attempts, but it seems like the src-address-list value is being ignored - every connecting IP is added to every address list immediately, including the blacklist. The timeouts are low because I've been experimenting trying to see if it was a problem of multiple packets being exchanged, etc.

This is on a 450G with 6.32.3 though I just looked and the firmware is 3.18 not 3.24. I rearranged so they're at the top of the rule processing based on someone else's comments (have moved the "accept" rule below the add-src-to-address-list rules already).

Am I missing something? Is this a firmware issue I need to be updating for? Always a little wary of remote firmware updates, since I'm ~35 miles from the unit and would really prefer not to travel if something goes awry.

Code: Select all

0    chain=forward action=accept protocol=tcp src-address=10.0.0.0/8 dst-port=3389 log=no log-prefix="" 

 1    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp address-list=rdpstage1 address-list-timeout=2m dst-port=3389 log=no log-prefix="FirstStage" 

 2    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdpstage1 address-list=rdpstage2 address-list-timeout=2m dst-port=3389 
      log=no log-prefix="SecondStage" 

 3    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdpstage2 address-list=rdpstage3 address-list-timeout=2m dst-port=3389 
      log=no log-prefix="ThirdStage" 

 4    chain=forward action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=rdpstage3 address-list=rdpblacklist address-list-timeout=3m dst-port=3389 
      log=no log-prefix="" 

What are you exactly experiencing?
From those rules I can see that network 10.0.0.0/8 will always connect, you are accepting connections from that network. That means IPs form 10.0.0.1 to 10.254.254.254 can connect.
The timeout of the blacklist is only 3 minutes, so after three minutes every IP on that list can retry to connect.

The add-to-[xxx]-address-list actions do not stop traffic from being analyzed by the next rule when a packet matches. So you need to reverse the order or the rules for this to work. So this is a logical issue rather then a software (or firmware) issue.

The add-to-[xxx]-address-list actions do not stop traffic from being analyzed by the next rule when a packet matches. So you need to reverse the order or the rules for this to work. So this is a logical issue rather then a software (or firmware) issue.

Ah, OK, so I'm adding the address to the list, then immediately checking in the next rule and finding that it's in the list (surprise surprise) which lets that rule work. I'll reorder things and give that a shot, thanks!

As for the timeouts, yeah, they're currently very short and I didn't include the "drop" rule - I was just watching list entries to be sure things were behaving before I actually started dropping any traffic. That's also the reason for the 3-minute timeout, I'm still debating between a 1-day timeout with a low number of tries or a 10-30 day timeout with a higher number to trigger it. I don't want to have to deal with end users who typo their passwords a few times and lock themselves out.

I'm not sure what your userbase is like so it might not be an option but you could setup port knocking to allow users to give themselves access if they lock themselves out. You could use the port knocking as a trigger to add the IP to a specific 'allowed' list for a limited time (1 day for instance) and allow users to connect this way while their IP is blacklisted.

I may set up port knocking if it becomes an issue, right now I just dropped it down to 5 attempts with gradually increasing timeouts. Looking at the logs, the bulk of the attempts I see are separated by only 2 seconds, but I've got it set now at 2 min, 3 min, 5 min, 10 min, 20 min, 10d for the timeouts (the last being the block). Once I've let that run for a few days I'll check to see what the failed logins logging looks like.

It is interesting to see that there are a bunch of things trying various eClinicalWorks related logins (ecwrep, ecwreports, ecwsupport, eclinicalworks, etc.).

I don't understand what you're trying to accomplish with the difference in timeout. Timeout only affects the amount of time an IP address is present in a list. This could create the rather unexpected situation that someone ends up in the 20 minutes timeout list due to problems logging in. If they log out within that 20 minute time-frame and try to login again, they will be added to the block list. I doubt that it will do anything to deter brute force attacks though.

It's amazing how many companies use very obvious naming conventions like that. There's always some application that needs to run some batch job that ends up with a generic account that never gets locked down. Usually the password is something in a dictionary cos the tech that created it didn't know it wasn't supposed to be used by a user.

Yeah, thinking about it the timeout increase isn't going to be helpful. I was thinking in terms of catching slower brute force attempts, but the way I'm doing it wouldn't actually work.

Your thinking isn't off to be honest. The increased timeout will make it harder for brute force attacks with increased timeouts between login attempts to succeed. The question I'd ask myself is whether this type of attack is a bigger problem then the potential that users lock themselves out as described in my previous post. It is entirely possible that none of your users attempt a second login within the 20 minute timeframe once they've successfully authenticated themselves. I just wanted to point out that this technique relies on detecting new connections. As such, a user can lock him-/herself out by starting up 5 sessions. This, for me at least, is the main reason to keep the timeout at 1 minute.