I have question regarding RDP on Windows Server 2022, however, I do need to first clarify and advise on the following:
I CANNOT require the users involved to use RDP over VPN, because reasons. Please do not make comments about this.
So, with that said, I have the above Server for a client which is their Pastel server and users sometimes access remotely to do work.
I have set up a port redirect from a random port to port 3389, which is working 100%. However, in the Windows Security Event Viewer, I saw a LOT of attempts to log in via RDP that obviously fail. These are most likely bots or some automated hacker script trying to crack the Administrator password. ( I have renamed the Administrator name, so that is somewhat secure).
I subsequently installed Cyberarms IDDS on the server, which immediately stopped those attempts. I am not going to go into the details of Cyberarms IDDS, except to say it works a treat.
I would like to stop these attack attempts at my IPFire Firewall, however. Is there a way to do this, please?
@hvacguy Thank you for your reply and apologies, I forgot to mention that, in South Africa, very few home fibre users are allocated Static IP addresses, unless it is requested from the ISP and paid for, so that is not an option, regrettably.
If RDP over VPN is not able to be used then port forwarding is your only option. That means the same as when you port forward your webserver. Anyone and their uncle can access it and try to get into any password protected areas.
Searching and reading up about the best way to secure RDP access via the internet the following were the recommendations I found.
Get your users to use strong passwords. Preferably 64 character passwords and use a password manager to provide the user name and password into the login window.
Make sure all your Windows systems are patched as quickly as possible when new updates are issued to prevent any RDP vulnerabilities being exposed for too long.
Make sure all users logging in via the internet are doing so with non-privileged accounts.
Set the client connection encryption level to High and set the security layer to TLS, preferably minimum of 1.2
Enable Network Level Authentication (NLA) to ensure user authentication.
Implement 2 factor authentication.
Limit access to only those user accounts that should be accessing RDP via the internet.
Set Account lockout policy to block accounts after a certain number of wrong password attempts.
Make sure none of the users accessing via RDP have admin access to the settings on their Windows systems.
I have no idea how easy or difficult any of the above is to set up on the client machines as I haven’t used Windows for around 20 years, other than as a user when I was working. Retired now for 8.5 years so no Windows access at all in that time.
No you cannot stop these attack attempts, in the same way that you cannot stop bad actors accessing your website that you have opened for http/https. Once opened all your website users but also all the bad actors, bots, script kiddies etc are also forwarded to the server.
The only ones that would be stopped would be any IP’s that are listed in the DROP list from spamhaus if you have “block all hostile IP nets” turned on so that would stop the worst of the worst trying to access your rdp server but that still lets a lot of access.
Regarding your first reply, all the items you listed in order to secure RDP on Windows Serverare already implemented, with the exception of 2FA, so there is no real concern regarding the actual security of the actual access there. All the items you listed are the recommended practices for RDP security and being an I.T. Admin, I naturally ensured that the practices were implemented.
Regarding your second reply, I will check my DROP lists to see if I have that Spamhaus option selected. Thank you.
@bloater99 It seems some trolls just cannot help themselves. Your post is EXACTLY the reason I no longer want to post questions on this forum anymore. It is just too much of a risk that some or other character just HAS to have his/her/it’s say, no matter what.
@dragonslayr Thank you, I will look at location blocking, that MAY be an option, especially if the attempts look like that are coming from the same country/location.
Regarding implementing a time the port is open, I will also look into that, it MAY be an option. Great suggestion, thank you.
First off, I am sorry for the comment. I had a really bad day leading up to reading your post. If you look at all of my posts here, they are mostly attempts to help others or asking questions. I did spend a good chunk of time rewriting the QoS docs and helping a few people who wanted to set it up per my suggestions. I do not think it is warranted to label me as a troll. But like you, I rarely post questions here anymore. The last couple were never even answered by a single person. Good luck with finding a solution.
I’ve also had this type of problem in the past, since in Spain, if you want a fixed IP, you have to pay for it.
With dynamic IPs and IPFire’s Dynamic DNS, it’s solved, but the problem is that IPFire doesn’t resolve Dynamic DNS addresses.
I’m almost ready to upload it to the forum (it’s almost finished, all that’s missing now is to integrate it with the IPFire “host” file so it appears in the Firewall).
In theory, you can use DDNS on your clients. The firewall, iptables, at the command line, will accept FQDNs. The problem with this approach is that iptables automatically converts FQDNs to IP addresses at the time the rules are applied and then not re-evaluated until the firewall is reloaded.
It is possible to add firewall rules with comments (-m comment). If you include the FQDN in the comment, you could then script something to continually monitor the FQDN against the resolved IP address and, if it changes, update the rule. Even easier would be to script deleting all your rules with comments and re-adding them whether they had changed or not.. It could even be done, say, every 5 minutes as the contracking would not cut existing connections so would not interrupt existing RDP sessions.
I am very sorry to give you not the answer that you would like to hear, but it has to be said: You will not be able to protect a RDP session over the open internet. It is a target for many bad people, it is a weak protocol that has not been designed to be used like this, and it will go very very wrong for you.
You can mitigate a couple of the attack vectors by using what @bonnietwin has pointed out, but it will not become anything better than a mitigation. VPNs have been invented exactly because of this.
Any other advice, or even entertaining the idea that is will be “somehow okay” on a forum like this where we care about security is just bonkers. Again, this is not what you want to hear, but if you are asking people for their expertise, you will have to accept that sometimes it is not the easy way.
IPFire has some excellent options to connect remote workers. They are indeed easy to deploy. Both OpenVPN and WireGuard are perfect candidates. If you cannot do this, you cannot use RDP over the internet. It is as simple as that. You will be compromised. It is not a question of if, but only when.
You will expose yourself to ransomware attacks, data theft and your systems will potentially be abused to infect other people. This is not what a good citizen on the internet would do.
RDP via WAN without VPN is really a bad decision and this is going completely wrong
and just because the TE doesn’t want to hear it, it is and remains totally unsafe
Much worse: in a few Weeks/Months it will be posted that IPFire is no good because the Network behind it was hacked - but the fact that RDP was the actual Problem is not mentioned any further
@ms I appreciate your candor and honest advice. There are, unfortunately, things at play that I cannot discuss that prevent me from using a VPN at least at this stage. So while I do understand that a VPN is the only way to protect RDP, please also understand that my hands are currently tied.
@luxskywalker I am not sure what a TE is, however, I will NEVER EVER post that “IPFire is no good because the network behind it was hacked”. That is NOT how I work. I understand my limitations as well as the risk of not using a VPN and not using a VPN is certainly not the fault of IPfire but of my company’s ignorance.
So please do not assume to know what I MIGHT or MIGHT not post. It is irresponsible, reckless and frankly, insulting
I understand. I am mostly speaking for the general case because I don’t know all the details about your individual case. But very often management makes technical decisions and I hope that maybe this advice helps you to go back to them and tell them that not only you are thinking that this is a bad idea, but instead you have gone to a place where independent people give advice and they have strongly warned you about the consequences.
I don’t think he meant you in particular, but generally speaking again, IPFire is only a firewall. It cannot do magic. Setting up something bad behind it and telling the firewall to forward (port forward - the clue is in the name) all the traffic is what it will do for you. The IPS can help to mitigate, but only so far. In the end there will be a search for a culprit and something will be found. So this would not be the first time where the firewall or a virus scanner was blamed, because people expect it to do magic when it only does what it has been configured to do.
You are taking too many things that people tell you too personally. This is security. We are dealing with the hard truth and often that is not the easy answer. We don’t know your situation. We are only giving advice on the basis of what you told us and what we have learned from other cases.