In DWScript WebServer in the metered cloud, I mentioned setting up a light weight Windows 2008 r2 Virtual Private Server to serve as web server host.
A parallel series of articles deals with the DWScript Web Server itself, and this is a mini-series about setting up Windows 2008 with minimal memory, CPU, storage and vulnerability surface.
This article assumes that you’re intending to setup a server for usage with mostly Delphi-made native services, ie. without .Net, IIS, Apache, but with DWS Web Server, mORMot, and maybe an SQLite, FireBird or PostgreSQL database. That server will be connected to the world via TCP sockets, https, REST and other light-weight protocols (ie. no DCOM or other Windows protocols).
It also goes under the assumption that you want RDP (Remote Desktop) administration, ie. a comfortable GUI and not just command-line.
Finally, the targeted OS is Windows 2008 R2 sp1, Standard Edition, which can currently be had in metered cloud/VPS hosters like Ikoula’s 1€/month VM. At the moment Windows 2008 is IME the best option for a light-weight Windows server, Windows 2012 baseline memory and CPU usage being higher.
Note about Ikoula: if you go for Windows 2012, the 1€/month VM will quickly exceed the 512 MB RAM in the franchise, so if you want to run it 24/7, you’ll be better off using one of the packaged servers options. If it’s only for testing and you shut down the VM between the tests, you shouldn’t have trouble staying within the franchise. Just be careful.
Part 1 – Basic Security
So your new virtual machine just got delivered! Let’s get started!
During the first few minutes, it’ll likely be running scripts and finishing deployment, but once that’s done and you can connect to it. The first thing you should do is tighten its security and reduce its attack surface. You can always open up later on if need arises.
Reducing the attack surface essentially means turning off or closing services you wont use, this ensures that security vulnerabilities these services may have won’t affect your server. As a bonus it means you’ll use less CPU and memory.
Tighten the Firewall
First once connected by remote desktop (mstsc.exe), close a few things in the Firewall.
Navigate “Start Menu”, “Administrative Tools”, “Windows Firewall with Advanced Security”.
Then select “Inbound Rules”, and clarify it by then choosing “Filter By State” / “Filter by Enabled” to the right.
Start by disabling rules:
- DFS: disable all rules, you don’t need the Distributed File System in a simple web server.
- File and Printer Sharing: you won’t need those either.
- SNMP: disable all rules, unless you have an administrator that asked you for SNMP specifically.
- Windows Communication Foundation: if you won’t use WCF, disable it.
That should leave you with only “Core Networking” rules (mostly about IPv6) and one “Remote Desktop” rule (which you’re using for administration). If you’re fluent with IPv6, you can to clamp down on these depending on your needs. If you’re not, just leave them alone.
Strengthen the administrator account
Next you need to strengthen the administrator account, so it is more likely to resist dictionary attacks. One simple way to deflect many dictionary attacks is to rename the administrator account.
Navigate “Start Menu”, “Administrative Tools”, “Local Security Policy”.
Then in “Local Policies”, “Security Options”, go to “Account: Rename administrator account”, and pick a new name. Feel free to go wild, if you want something simple to remember, choose one there, if you want something hard-core, go there.
Now you should change your password. The VPS hoster will hopefully have provided a strong one, but it’ll have likely been sent in an un-encrypted email that NSA+dog could have sniffed in a myriad ways. So choose a pass-phrase instead. Yes, a phrase, at least a handful of words, just avoid famous quotes.
2 thoughts on “Setting up a Windows 2008 for the metered cloud – part 1”
Instead of moving the port for RDP it’s lots better to use certificates to establish the communication.
And startssl will give you a good one for free….
Leaving the standard port open just attracts bots IME, which will eat your incoming bandwidth through their brute-force attempts, along with a bit of CPU power (in the kernel & firewall to accept the TCP connections, check and reject the request).
Using a certificate will strengthen your connection, but will not deter brute-force connections attempts, and you’re even likely to lose a bit more, as failed secure negotiations are slightly more expensive bandwidth & CPU-wise.
So regardless of certificates, my advice is to always move the port if you don’t have filtering by static IP (which would make the port look closed to bots). Certificates address security, moving the port helps minimize the bandwidth & CPU wasted by the mindless bot hordes.
Comments are closed.