SSH X11 server

Question

Hello
We just received a audit finding on the solaris machine that states- the remote x11 server accepts connections from anywhere because various ports 6001, - 6009 were open. The suggested solution is to restrict access to this port by using the xhost command.
We on the other hand have ssh configured by using X forwarding. Since the traffic is secure can we depend on ssh to secure traffic without restricting access to the local host ports?

Answer 1

The xhost command will not close ports 6000-6009. It will however update the IP based access control to the X server that is already listening there. The Xserver would still be vulnerable to remote brute force attacks even if the source IP is not on the access control list. Even if you are exclusively connecting via ssh tunelling, those ports are still flapping in the breeze.
Worse yet, if anyone uses the ports directly ("export DISPLAY=remotehost:0") the traffic is not encrypted meaning eavsdropping is relatively easily with snoop/tcpdump if a system along the routing path were compromised (or your switch, set to echo point to point packets to a capture port). Within seconds, that conversation would tell would-be attackers which IP addresses are on the access control list, allowing them to spoof the X11 client (man-in-the-middle), and even hijack control of the conversation entirely.
A quick example:
$ export DISPLAY=remoteserver:0 (use netstat -tn to find out what display the "victim" is using. subtract 6000 for the display number.)
$ export XAUTHORITY=/home/victim_account_name/.Xauthority
$ xwd -display remoteserver:0 -out /var/tmp/victim_screenshot -root -silent
$ xwud -in /var/tmp/victim_screenshot -scale &
$ xmessage -nearmouse 'Here is a screenshot of your system' &
Two suggestions here (recommend both):
1. Use the following SMF property settings to disable tcp_listen altogether:
root# svccfg -s svc:/application/x11/x11-server listprop options/\*
options/tcp_listen boolean true
root# svccfg -s svc:/application/x11/x11-server setprop options/tcp_listen false
root# svccfg -s svc:/application/x11/x11-server listprop options/\*
options/tcp_listen boolean false
which will then pass the "-nolisten tcp" argument to the Xorg daemon which is managed by the above SMF entry. Restart the service to implement and confirm the change with:
root# ps -ef|grep -i xorg
root# svcadm restart svc:/application/x11/x11-server
root# ps -ef|grep -i xorg
This will prevent anything except local unix socket access to X11.
2. Also use ipfilter to explicitly block ports 6000-6063, out of paranoia, just in case the above property gets enabled again inadvertently:
block in log quick on eri0 proto tcp from any to eri0/32 any port 5999 >< 6064 keep state
Then use "ssh -X" to forward your X display over ssh. Note that if your client end of the communications is compromised, the above display hijacking routine would still work (substitute :10 instead of :0, and you would have to know the XAUTHORITY in use by the client shell), but ssh makes figuring out display offset nearly mpossible without having local access to the client machine. Using unencrypted X11 access, you simply observe which 6000+ port has activity (say :6001), subtract 6000, and that's your display number. With tunnelling, all the traffic between client and server goes over port 22 encrypted. Once the traffic gets to the server end, the ssh daemon forwards the X11 traffic to the :0 local domain socket relatively securely.
Hope this helps!
Bryan Wood