Constant login failures in event viewer with changing ports
Solution 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.
Solution 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.