Setting up Remote Desktop Securely

I don’t have an ideal home office set up yet. I jacked up my shoulder pretty bad for a few weeks by working too long at my very un-ergonomic desk. To avoid any more of that, I wanted to work on my beefy desktop from the comfort of my living room. It runs Windows 10, so I set up Remote Desktop so I could connect to it from my laptop. I was concerned about security because my whole life is on that thing, so I also looked up some hardening suggestions.

To enable Remote Desktop on the host machine:

  • Settings > System > Remote Desktop
    • Enable Remote Desktop
    • Advanced Settings > Require computers to use Network Level Authentication to connect (recommended)

Administrators all allowed by default, even Local Admin. Local Admin will not be properly logged or identified. Override local security policy with a Group Policy Setting.

  • Local Security Policy > Local Policies > User Rights Assignment > Allow log on through Remote Desktop Services
  • Remove defaults (Administrators, Remote Desktop Users) and whitelist specific users instead
    • Add User or Group > Advanced > Find Now to list Users
    • Double click desired User
    • OK
    • Repeat if needed for additional Users
    • OK

Set an account lockout policy:

  • Local Security Policy > Account Policies > Account Lockout Policies
    • Set Account lockout threshold to 3
    • Other values will be set to 30 min by default. Adjust as desired.

Enable RDP security settings:

  • Local Group Policy Editor > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
    • Set client connection encryption level: High Level
    • Require secure RPC communication: Enabled
    • Require use of specific security layer for remote (RDP) connections: SSL (TLS 1.0)
    • Require user authentication for remote connections by using Network Level Authentication: Enabled

You can also change the Remote Desktop listening port (default 3389) to dodge any default scans, but remember: security by obscurity is not security.

  • Registry Editor > HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > RDP-Tcp
  • Change PortNumber (select Decimal)
  • Remember to update any firewall rules.

You can now use a Remote Desktop client (official version available free in Windows Store, Google Play, and iOS App Store) to connect securely, but only from the local network.

Some oft-recommended open source Linux RDP clients include Remmina, KRDC from KDE, TigerVNC, and Vinagre from GNOME, but there are many others.

To connect over the internet from anywhere, set up a Remote Desktop Gateway or an IPSec or SSH tunnel. I had an SSH tunnel set up on my router at my old place, but not here yet. However, I don’t anticipate being able to leave the house anytime soon (thanks, coronavirus) so that project will have to wait for another day.

Adventures in Django Deployment: What is a Web Server Anyway?

I recently had some hair-raising adventures in the land of website deployment. I’ve been completely rebuilding my website with a Django backend because I love Python. (This blog will eventually be hosted there, although WordPress does excel at the blog thing, so I might just get crazy and integrate Django AND WordPress. But I digress.) I had everything working all fine and dandy on my local computer and was ready to deploy my almost-identical-but-now-Django-backed placeholder site. I’ve long had Apache serving a few VirtualHosts and handling the SSL certificates on my personal DigitalOcean droplet, so my choice of web server was made for me. At least all that domain config stuff was done, so it would be a cinch to get Django up and running in place of my static site, I thought.

I thought wrong.

It started off so well. I installed python and PostgreSQL on my server and configured my production settings file to match (and to pull in the passwords from a separate ini file on the server and out of the git tracking). I set up a bare repo and some git hooks to make pushing to production easy. (I know I should also set up a separate staging subdomain for testing, but I’ve been in a hurry to get something real up there since I’m starting the ol’ job hunt.) Everything seemed to be ready to push so I turned to the Apache config.

This is where my troubles began. I had been running Django’s testing server locally, but the docs were very clear that this testing server should not be used in production. They did not go into details as to why other than “security and scaling,” but I took their word for it. That’s okay, I thought; I have Apache set up already anyway. The docs also kept talking about this “WSGI” thing, but when I had tried to figure out how to configure that, it had mostly just confused me, and well, it was working on my machine.

Continue reading “Adventures in Django Deployment: What is a Web Server Anyway?”

If you wanna resize a partition with gparted…

…you gotta manually compile the latest version of e2fsck.

WHY IS EVERYTHING SO DIFFICULT?!

OK, it’s not that difficult, but you would think the error messages for such a common operation would have been more helpful. I’m just trying to extend the Raspberry Pi image I just flashed so it takes up the whole SD card.

Here’s how to do the thing.

For the record, e2fsck is the ext-filesystem-specific component of the fsck filesystem utility. I have just this week been using it to check ext filesystems for errors like so:

e2fsck /dev/sdb5 (or whatever)

Make sure the drive is unmounted first:
umount /dev/sdb

Be careful; that’s umount, not unmount. I can’t tell you how many times that used to throw me off!

Update:

Additional issues! For some reason I could mount the filesystem once, but not again after that. Apparently I should have just resized the filesystem manually instead of using gparted to begin with. I resolved the issue thanks to the info found in this thread and the following commands:

(make sure partition is unmounted)
e2fsck -f /dev/sdX
resize2fs /dev/sdX

Changing the Default OS in GRUB—the Easy Way!

A grub larva

Like many folks, I have my laptop set to dual boot Windows and Linux. This isn’t the sort of thing that’s too terribly difficult to set up, but GRUB always boots up Linux by default, and sometimes that’s not ideal, such when I’m trying to install Windows updates that require a restart or two. I’m a distractible beast, and I always seem to look away from my computer at just the wrong time.

When I searched for an easy way to switch which OS was set to boot by default, I found a lot of dead ends, either outdated information or complicated methods that just seemed like a lot more trouble than they were worth for what is, at the end of the day, a minor annoyance. Well I took another crack at it the other day and I finally found an easy solution! Better yet, I found out that it’s also easy to set GRUB to save whichever OS was booted last as use that as the default! That’s not even what I was initially trying to figure out how to do, but that’s exactly the behavior I wanted, I realized.

Now, this should work for any version of GRUB2, though I can’t personally vouch for other setups; I have GRUB version 2.02 from Linux Mint. But the solution is to simply edit the /etc/default/grub file, which is used to generate the actual grub.conf file (which should not be edited by hand).

There is a line which reads:

GRUB_DEFAULT=0

The value is an index number for the menu items displayed by the GRUB menu at boot, starting at zero for the first item. You can switch this number to set any other item on the list as the default, so 1 for the 2nd menu item, 2 for the 3rd menu item, etc.

OR! You can change this value to saved and add one more option as follows:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

As you might suppose, this tells GRUB to start saving a reference to whichever OS was last booted and sets that reference as the new default. After saving these changes, the GRUB boot menu will still display as before, so you are free to manually select whichever OS you need, but left unattended, whichever menu option was chosen last will be booted automatically when the countdown timer runs out.

For good measure, now that I was more confident about my default boot selection, I went ahead and shortened that boot countdown to 30 seconds:

GRUB_TIMEOUT=30

As the file reminds you in the comments, once you are done saving your changes, be sure to run sudo update-grub to put them into effect.

For more details and to learn about some of the other GRUB options, check out this post from How To Geek.