They do not appear to be ramping up on any of my VPS nodes. I see the same averages to my tarpit ports on all my nodes.

    # VPS They all look similar to this
    iptables -L INPUT -n -v | grep TAR | sort -r | awk '{print $1"\t" $3"\t" $11}'
    2680        TARPIT dpt:23
    2657        TARPIT dpt:6379
    170K        TARPIT dpt:445
    1186        TARPIT dpt:80
    882         TARPIT dpt:22
    757         TARPIT dpt:443
    591         TARPIT dpt:5900
    311         TARPIT dpt:21
    296         TARPIT dpt:3389
    119         TARPIT dpt:873

    # Home
    iptables -L INPUT -n -v | grep TAR | sort -r | awk '{print $1"\t" $3"\t" $11}'
    9013        TARPIT dpt:5900
    1628        TARPIT dpt:22
    1274        TARPIT dpt:23
    1092        TARPIT dpt:445
    119         TARPIT dpt:3389
    40          TARPIT dpt:21

    # Second Home connection
    iptables -L INPUT -n -v | grep TAR | sort -r | awk '{print $1"\t" $3"\t" $11}'
    50532    TARPIT dpt:22
    44301    TARPIT dpt:445
    33520    TARPIT dpt:23
    6718     TARPIT dpt:80
    6439     TARPIT dpt:3389
    184K     TARPIT dpt:5900
    1091     TARPIT dpt:21
    271      TARPIT dpt:1900

Why don't more people use Fail2Ban?

https://www.fail2ban.org/wiki/index.php/Main_Page

I avoided running servers since people are jerks but if I did that would be on my checklist of things to set up if I intended one to stick around long term.

People seem to reinvent concepts from long ago for reasons I do not understand.

As someone who supports a lot of Windows environments - yes, it's incredible the rate at which this occurs. I'd strongly point people at the RD Gateway MFA plugin as a requisite for publishing RDS these days:

https://docs.microsoft.com/en-us/azure/active-directory/auth...

It's also supported to publish behind the Azure App Proxy, avoiding the need for any port forwards at all:

https://docs.microsoft.com/en-us/azure/active-directory/app-...

https://github.com/devnulli/EvlWatcher

README…

It's basically a fail2ban for windows. Its goals are also mainly what we love about fail2ban:

pre-configured no-initial-ducking-around-with-scripts-or-config-files install-and-forget You can download it here ( v2.1.5 - April 2022 ) .

Also, we love issues!

If anyone needs something or has questions about something, please feel free to open an issue. We are especially happy to get issues about log-entry samples we don't react on, or ideas of how we can support more protocols.

A bit more detailed description of what EvlWatcher does.

Scenario: there are those bad people out there, hammering your service (RDP and whatnot) with brute force attempts.

You can see them and their IPs clearly in the Windows Event-Log.

You have searched the web and yea, there are plenty of tools, scripts, and all that, to read the event-log and automatically ban the attackers IP.

You however, are lazy. You need something like fail2ban, with a preconfigured set of rules to just RUN right away and it works.

But then, it still needs enough flexibility for you to completely configure it, should you wish to do so. EvlWatcher does that. It scans the Windows-Event-Log, and reacts.

It works by installing a service that scans the event log for unsuccessful login attempts. When one of its rules are violated (e.g. trying to log in without correct credentials, more than 5 times in 2 minutes), it will place that poor bastard into a generic firewall rule, and thereby ban the attacker for 2 hours.

Also, when someone is repeatedly trying, there is a permanent ban list for that, where people defaultly land on when they've had three strikes.

You can, of course, adjust the rules to your liking. They are basically a consisting of an event source, and a Regex to extract an IP, its pretty simple.

Well I never ever expose RDP to the internet directly. Allow only office IP or setup some VPN/jumphost via ssh whatever.

I trust SSH much more than RDP to not have RCE/auth bypass bugs. SSH is also much easier to setup key auth or 2FA than in RDP if one like they mentioned in post are more used to setting up Linux boxes.

After reading this blog post - I would not send any logs to their servers.

Yep, I have a single Windows Server machine with an RDP port(non default) exposed to the world and it gets tens of thousands of failed logins every day. It has been for the past few years. I have no idea who is wasting their time on this or why, but as far as I can tell it's costing me nothing, so other than setting up an alert for a successful login I decided to simply ignore it.

The difference between type 3 and type 10 is probably the difference between providing the username and password when connecting to RDP or after already connecting. In the latter case it's “interactive”: you enter the password via the GUI of the server you connected to.

I had to ban Flyservers on many occasions too.

Given the frequency with which these incidents happen, I am more inclined to think they are a bulletproof hoster of some kind ...

At a certain point it becomes difficult to attribute things to “incompetence” rather than malicious intent

There’s a pretty cheap program that will do auto blocking, it’s easily googleable. Also changing the default port will cut down the numbers. I’ve had one hacked over RD gateway so that alone isn’t the answer. On our cloud windows servers we use a remote management agent to access, this obvs has its own trust issues but overall works well.

Windows do not log the passwords they tried, so we can't know which ones were used

Would be interesting to create a server daemon that listens on TCP port 3389 and implements the login portion of the RDP protocol to 1) Be able to gather information about the passwords used and 2) Experiment with ways to lock up or stall the scanners.

You absolutely should blame Flyserver. They allow bots to run, and they don't do anything about it. There are too many network operators like this.

Imagine if any networks where constant and ongoing illegal activity happens, and the network operators do nothing, eventually result in those networks being taken away. Things would change drastically.