Getting XRDP to Work on Linux
14 January 2016
My fellow programmers and I use XRDP, an open source Remote Desktop Protocol application, for remotely connecting to our workstations. Routinely during upgrades XRDP would stop working. Some time later, during a routine security scan, my workstation was assessed to have the CVE-2005-1794 vulnerability. CVE-2005-1794 is about a man in the middle attack being able to spoof public keys. This vulnerability exists on both Linux and Windows. The workstation I am working with is XFCE Fedora Core 23.
Having to redo the configurations a number of times, for myself and others, it seemed prudent to document the procedures. First let us look into getting XRDP to play nice with SELinux. SELinux uses extended file attributes to label files with a “Security Context”. For XRDP to work with SELinux we need to change the context of files xrdp and xrdp-sesman as shown below.Change files security context
sudo chcon --type=bin_t /usr/sbin/xrdp sudo chcon --type=bin_t /usr/sbin/xrdp-sesman sudo systemctl reenable xrdp.service sudo systemctl start xrdp.service
What happened is we used the change context command to change the type of the files. SELinux then allowing the files to be run. Unfortunately the changes above will likely not last if you reinstall or upgrade XRDP. To make the changes more permanent you would want to modify SELinux configuration to remember the changes.Add file context configuration to SELinux configuration
sudo semanage fcontext -a -t bin_t "/usr/sbin/xrdp" sudo semanage fcontext -a -t bin_t "/usr/sbin/xrdp-sesman" sudo systemctl reenable xrdp.service sudo systemctl start xrdp.service
Now that SELinux is out of the way, you will want to make sure port 3389 is open in your firewall. On my system I have Firewall and I added port 3389 under “Public” for both the “Runtime” and “Permanent” configurations.
Now lets look into securing XRDP from public key spoofing. We chose to create a self-signed certificate. For our purposes this will be perfectly adequate as only our team will be connecting to the workstations and we know they are trustworthy. First lets get our certificate. You will be prompted to answer a series of questions about the location and name of the server for which it is being created.Generate a certificate
bash-4.3$ cd /etc/xrdp bash-4.3$ openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 3650 Generating a 2048 bit RSA private key ..........+++ .......+++ writing new private key to 'key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) :Kentucky Locality Name (eg, city) [Default City]:Louisville Organization Name (eg, company) [Default Company Ltd]:Open Source Organizational Unit Name (eg, section) :Blog Common Name (eg, your name or your server's hostname) :Workstation Email Address :firstname.lastname@example.org
Once that is accomplished change the permissions of of the keys to protect them.Generate a certificate
bash-4.3$ chmod 400 key.pem bash-4.3$ chmod 444 cert.pem
Next we modify the /etc/xrdp/xrdp.ini file to enable tls by changing “security_layer=rdp” to “security_layer=tls”. Finally we restart the XRDP service in order for the changes to take effect.Restart XRDP
bash-4.3$ systemctl restart xrdp
Due to a security scan hit on XRDP for not activating Network Level Authentication I had to forgo its use in favor of Tiger VNC. XRDP is aware of the issue but at this time we don’t know when a fix will be available.