Stop me if you've heard this one before, X11Forwarding is bad, because the ISM doesn't tell us so.

Let me start by giving some context around this problem; You have a Piece Of Software that you need to run on your Linux Server somewhere in your environment, that's cool. However this 'PoS' requires a GUI for it to be used/managed and you need to be able to administer this machine remotely, that's bad if you intend do do this via X11 Forwarding over SSH; and I'll explain why.

Compliance

Before I dive into the nitty-gritty, lets relate it to some relevant guidance.

The ISM Control that tells us that X11 is bad is Control 0484, or does it? We don't actually cover the reasons for why we must ensure 'X11Forwarding no' is set within our SSH configuration, citing "could result in an intruder being able to gain control of the computer displays as well as keyboard and mouse control functions" This doesn't specifically outline what impact that actually has (we could assume keylogger and/or viewing the remote display); nor does it provide us with the intention of the control's recommendation so that if you were to consider alternative solutions, you don't introduce the same problem.

The Center for Internet Security has very well documented configuration benchmarks for people looking to harden their environment. Unfortunately in this case CIS don't provide a full picture either as to why you don't want X11 forwarding; for example lets look at RHEL5/6 guidance 6.2.4 states: "There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server". Great; we are getting somewhere, however it's still unclear as to what specifically we are protecting our systems from, by disabling X11Forwarding.

X11Forwarding no?

OK so I did some brief scrapping about on the net and after a very brief refresher and some light reading on how X sessions work, I have a clear-as-mud idea on this problem. Basically X11 is not built with security in mind at all, so in order to 'secure' the X11 session communication between client and server, we wrap it up in a SSH tunnel. Now we can use the -x switch when establishing this connection which treats the server you are connecting to as 'untrusted', which is meant to stop you from executing commands that violate the security of the remote machine (using a whole bunch of complicated protocol guff).

So we are protecting our communication on the wire with SSH; the client issues commands which are executed on the server, and sending the X11 display output back to be client to be displayed by the client X Server display. Now the fun part here is your local X Server runs as root and your remote session runs as your context on the server which can be easily compromised and BOOM a malicious user on the compromised Server you connected to, now has root on your desktop (or whatever).

Note: I'm not going to touch using an X11 client on a Windows box as it is a different kettle of fish; mainly clients usually run in the context of the logged in user.

Either way, we wish to lessen our attack surface by disabling X11Forwarding on the Server side.

Connecting to GUI Apps

So what else do we have to provide the GUI functionality required, remotely?

Well we can use xRDP, which uses either a VNC Server or a RDP Server to handle the X Session, you can read about it here.

If you're looking to provide that seamless thin-application (and full desktop) experience; perhaps XPRA can suit your needs?

Both use an AACA which ticks a box on the warm and fuzzy.