In DWScript WebServer in the metered cloud [1], I mentioned setting up a light weight Windows 2008 r2 Virtual Private Server [2] to serve as web server host.
A parallel series of articles [3] 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.
Introduction
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 [4], and maybe an SQLite [5], FireBird [6] or PostgreSQL [7] 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) [8] administration, ie. a comfortable GUI and not just command-line.
Finally, the targeted OS is Windows 2008 R2 [9] sp1, Standard Edition, which can currently be had in metered cloud/VPS hosters like Ikoula’s 1€/month VM [10]. 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 [11] 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 [12] 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 [13], if you want something hard-core, go there [14].
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.
Next: Avoid being a honeypot! [15]
Change your RDP port
The RDP port being the primary (and royal) way to access your machine. If you’ll always connect from known static IPs, restrict access to your RDP port for those IPs in your firewall, if not, you should move it from the default port 3389 to something else, choose one from that list [17].
Security by obscurity? Well, yes, the reason why is that the web is a wild wild web, with millions of bot programs that just hammer the common ports looking for servers vulnerabilities and week passwords (dictionary attacks). If you change your port, you’re making yourself more expensive to hammer (they need to scan your ports first).
Another benefit is that it will slightly lessen the amount of CPU cycles lost (but eventually metered) to authentication negotiation with dictionary bots, and slightly lessen your lost (and eventually metered) incoming bandwidth. This is a slight but not negligible tweak.
As an experiment, I left a VM with the default RDP port open, at the end of the month, it had lost several gigabits of incoming bandwidth to thousandths of bots that where attempting to brute-force access from thousandths of different origin IPs…
So IME, a standard open RDP port acts like a honey pot for dictionary attack bots.
How to change the RDP port
To change the RDP port, go back in the firewall, and follow the following steps (don’t miss any, read once first, if you miss a step, you’ll lose access to your VM)
Open your new RDP port by adding a rule of type Port, TCP, and then enter your specific Port
If you’re going to access your machine from static IPs, tighten further by right-clicking your rule, choose Properties, and in the Scope tab, specify the IP addresses you’ll administer from.
Next start RegEdit and go to the following key
- HKEY_LOCAL_MACHINE
- \System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\
- PortNumber
Then enter your port number. Be wary to click on the decimal mode (it’s hexadecimal by default), it should initially read 3389, replace it with your new port number.
Restart your server, wait a bit and connect to your new RDP port by appending it to the address (ie. if your address was “123.45.67.8”, and your new port is 6666, then the new address to type is “123.45.67.8:6666”.
Once connected, go back in the Firewall and disable the old RDP rule, the one for port 3389.
After having disabled the old RDP rule, try clicking around… Still responding?
Good! If not, time to log into your hypervisor access (if you have one) and/or reset your VM to initial state and start from scratch 🙂
To be continued…
Next part will be about slimming down the OS, in terms of metered costs, ie. storage space, storage I/O, CPU and memory usage.