Constant login failures in event viewer with changing ports

Question

We have a Windows Server 2016 webserver that acts as a hosting server and receives constant login attempts. Fortunately they all fail but it's filling our SIEM with alerts for repeated login attempts. On all our other servers, we locked down the RDP port so that it can only be accessed from a select set of IP addresses. This blocks the automated RDP login attempts and the logs are quiet.

The troublesome server also has the RDP port scoped to limited IP addresses but we still have constant failed login attempts. Each login attempt is using a different port which is why the firewall isn't blocking it. I've installed RDPGuard which is partially successful in blocking the IP addresses but I've also noticed that the IP addresses are rotating for each request so it's not as effective as I'd like.

We don't use Active Directory. The administrator account is disabled. The user account tends to almost always be 'administrator'.

An example of the log entry is below:

An account failed to log on.

Subject: Security ID: NULL SID

Account Name: -

Account Domain: -

Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID

Account Name: administrator

Account Domain:

Failure Information:

Failure Reason: Unknown user name or bad password.

Status: 0xC000006D

Sub Status: 0xC000006A

Process Information:

Caller Process ID: 0x0

Caller Process Name: -

Network Information:

Workstation Name: -

Source Network Address: 180.248.230.58 <--- This keeps changing

Source Port: 65149 <--- This keeps changing

Detailed Authentication Information:

Logon Process: NtLmSsp

Authentication Package: NTLM

Transited Services: -

Package Name (NTLM only): -

Key Length: 0

Which is always paired with the following event:

The computer attempted to validate the credentials for an account.

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Logon Account: administrator

Source Workstation:

Error Code: 0xC000006A

Is there a configuration setting that is allowing these login attempts that needs to be changed?

Could changing the firewall to block all incoming ports (except a whitelist of ports like 443, 80, 21, etc) help?

Answer 1

Welcome to the Internet! Whenever you put a server facing the Internet, you are extremely lucky if you don't get some sort of brute-force attacks within 20 minutes. There are all kind of bots scanning through the whole public IP address space for 1) various vulnerabilities and 2) weak passwords in login forms.

The real solution is to adjust your SIEM not to complain about repeated failed login attempts; it's the successful logins from suspicious locations that should raise alerts, instead.

Logon Process: NtLmSsp

This is the NT LAN Manager (NTLM) Security Support Provider. It's used by e.g. HTTP Negotiate authentication from IIS. If so, these brute-force attacks are probably against your web server. As they are coming through HTTP port 80 or HTTPS port 443, blocking all other ports won't stop this. It's still reasonable to only allow connection to ports that should be accessible from the Internet, but for other reasons.

Each login attempt is using a different port which is why the firewall isn't blocking it.

Source Port: 65149 <--- This keeps changing

These are source ports: it's the TCP port that is used to distinguish the connection on the client side (RFC 793, 3.1). All ports from 49152 to 65535 are dynamic / private / ephemeral ports used for this purpose. For more thorough explanation, see RFC 6335, 6 & RFC 6056, 2.

Answer 2

Logon Type 3 is a network logon attempt (file, print, IIS), but it is not an RDP logon attempt, which is Logon Type 10 (remote interactive logon).

If this is a web server there isn't much you can do. Changing the ports isn't going to help. Any scanner will find the website(s)no matter what port(s) it's running on. The source port changing isn't troublesome. That's how the TCP/IP protocol works.

One thing I would suggest is to disable RDP access to the server entirely or only allow it from internal IP addresses. Locking it down from only specific external ip addresses is a good step, but you're still exposing the server to the public and hoping that the firewall does it's job. RDP access to the server isn't a requirement for the server's intended purpose, it's for your convenience. I'd suggest that eliminating that convenience for a little more security is a worthwhile trade-off.