0

We've just finished setting up a brand new instance of Windows Server 2016. It's a dedicated server at a local hosting provider. They left our old server up to give us time to migrate things over.

Everything is migrated now, and I decided to test something on the old server that I want to implement on the new server - I changed the RDP listening port. Now, I facepalmedly didn't take note of the 'note' about configuring the firewall to allow the new port. So essentially I'm now locked out of the old server. Which is not a problem - I was just about to give the provider instructions to nuke it anyway.

The problem is, I'm now too scared to configure the new server's RDP listening port. Would someone be kind enough to offer some advice so that I can avoid a calamity.

I need to a) ensure my config steps are correct and proofread, and b) have a contingency plan.

Regarding a), is this correct:

  1. (Ask provider to allow the specified port. Old server wasn't behind an external firewall so I didn't need this step.)
  2. Change RDP listening port as described above.
  3. Create a 'New Rule' in Windows Firewall's 'Inbound Rules' to allow the TCP port that I specify above.
  4. Restart server and pray.

Regarding b), what are some things I can do to avoid being locked out? I'm thinking:

  1. Enable something like LogMeIn beforehand, and disable it once I've made the change successfully.
  2. Add an RDP listening port instead of changing it, and remove the original listening port once I've made the change successfully.
  3. Ask the hosting provider to take some sort of image of the disk in case I need to restore it (I really don't want to do this).

edit: We have web apps successfully set up and using ort 443, so my LogMeIn plan should theoretically be a good fail-safe, right?

cpengin
  • 21
  • 2
  • 1
    This contingency plan for plan b) should really include some out-of-band access method like remote KVM for a physical server that you can access even if your OS is broken/unreachable. In case of a Linux system, a dedicated rescue system that you can boot into *might* be an alternative. In 2017, a new physical server should be equipped with this, but at the very least the provider *must* offer some pluggable remote console for this case - if they don't, run. – Sven Apr 17 '17 at 11:40
  • AFAIK it's a virtual machine. I just said 'dedicated' to differentiate from any shared kind of service. We're actually planning on changing providers anyway for unrelated reasons. They're quite bad. – cpengin Apr 17 '17 at 11:44
  • Then you already should have this kind of out-of-band access to a remote console, which makes this kind of change easy and a lot less dangerous- if you do something wrong, just log into the VM console and fix it. – Sven Apr 17 '17 at 11:51
  • Why are you doing this in the first place? – joeqwerty Apr 17 '17 at 15:23
  • @joeqwerty, precisely because of [this](https://serverfault.com/questions/314850/ban-slowdown-or-stop-massive-login-attempts-to-rdp). Had that same problem on our old server. It's not critical that I do it, I'd just like to. – cpengin Apr 17 '17 at 15:42
  • 1
    I've got to think that changing the RDP listening port is merely moving the target, not removing the target. Any type of scanner is going to find the new RDP port. – joeqwerty Apr 17 '17 at 17:52
  • Yeah. I've been reading that too. (I'm not a system administrator by profession). Consensus is that it's better than nothing but still not ideal. Also re. my original post, it looks like my method will in fact work to change the port successfully. I just got spooked from botching the old server's config. I'm gonna keep investigating things and I'll post a better formulated question here once I have one. Thanks for the info anyhow, much appreciated. edit: changing the port is not meant to be the silver bullet for security - it's just to mitigate botnet attacks which the old server was prone to. – cpengin Apr 17 '17 at 17:55

0 Answers0