How to stop generating of MIT-MAGIC-COOKIE-1 in /$HOME/.Xauthority

[BDD]

Hi All

We have lot of hpux 11.31 ,11.23 and 11.11 system . After security audit, they come up with a finding that we have to stop generating of MIT-MAGIC-COOKIE-1 in /$HOME/.Xauthority file .
This files are getting generated when we use CDE login for oracle and SAP installation /up gradation
Is it possible to stop generating of MIT-MAGIC-COOKIE-1 in /$HOME/.Xauthority file ? if yes how we can do this

With Thansk

B.Dathan

[Horia Chirculescu]

Hello from Romania,

I believe only the new versions of X11 server include a new extension that will allow generation of the new cookie in the server on the fly.

Best regards,
Horia.

[Matti_Kurkela · Accepted solution]

I think this is a case of misunderstanding or a poorly phrased requirement.

It might be possible to switch the X11 authority scheme to XDM-AUTHENTICATION-1 instead of MIT-MAGIC-COOKIE-1, but that uses only a 56-bit DES key, which is insufficient by today's standards.

Disabling the .Xauthority file entirely would require one of two things:
- either stop using X11 entirely, which might be too troublesome
- or use "xhost +" which is even worse security than MIT-MAGIC-COOKIE.

You should expand your scope of thinking: what have you done to make your X11 sessions secure?
You say you use CDE login: that implies you are either logging on using a display that's directly attached to the server machine, or using a remote X11 terminal, or a X11 server software running on a workstation.

If you're logging on to the server machine locally, you may have disabled remote X11 access e.g. by network firewalls or by ipfilter running on the server.

If you're using CDE logins from a workstation, you should really be looking into encrypting the X11 traffic. A common solution for this is tunneling the X11 connection over SSH. It does not remove the MIT-MAGIC-COOKIEs, but prevents a network attacker from getting the keys, because all the X11 traffic will be strongly encrypted.

It's possible that you've already solved the security problem of the X11 connections in a way that the auditor's checklist does not expect: in that case, document your solution and present the documentation to the auditor as a justification. Most auditors will recognize that there is more than one way to solve most problems.

MK

[BDD]

Hi MK
Thanks for your replay
Can you please give little more details on how we can tunnel the X11 connection over SSH?

With Thanks
B.Dathan

[Matti_Kurkela]

On the server side, if you're using HP Secure Shell (available for free in software.hp.com), make sure you have the "X11Forwarding" set to "yes" in /opt/ssh/etc/sshd_config. I think it is enabled by default; if it isn't, change it and restart sshd.

On the workstation side, first make sure you have your X server application (ReflectionX, Xming, whatever) running (but not connected; just running in the background) if you're using Windows.

If your workstation is running Linux, the local Linux GUI is already running a local X server for you, so you don't have to do anything special.

Most SSH clients (e.g. PuTTY) will have a simple on/off setting, "Forward X11" or something similar. Enable that setting before logging in with SSH.

When your SSH session connects, sshd on the server-side is notified that the client wants to forward X11 connections and arranges everything automatically. Your SSH session will have a DISPLAY variable set with a seemingly non-sensical value: it will point to the server machine, with a display number of 10.0 or above.

This is exactly as it should be: the sshd has set up an X proxy on the server host that receives the X connections from applications and pipes them through the encrypted SSH connection to your workstation, where the SSH client forwards them to ReflectionX (or whatever) that draws the windows on your workstation screen.

The SSH client at the workstation side and the sshd at the server side will also automatically set up the necessary .Xauthority keys, transferring them securely encrypted over the network.

You can then just start up any X programs in your SSH session and the window will pop up on your workstation's screen. When you're setting this up for the first time, test by running some simple and easily-recognizable X command, like xterm or xclock.

When you're using SSH X11 forwarding, forget everything you've learned about xhost, xauth and setting the DISPLAY variable manually: it is all done automatically, and you should not mess with the DISPLAY variable at all. When you've familiar with it, it's actually much easier than using X11 in "traditional" way.

Of course the encryption/decryption of the X11 traffic will slow down the responsiveness of the remote X applications slightly, but this is usually not a problem unless one of the hosts is overloaded or really old.

If you want a "full" CDE desktop over SSH forwarding, just run this command in the SSH session with X11 forwarding enabled:

/usr/dt/bin/dtsession &

Remember that closing the SSH session will also terminate all X11 access, so don't close it until you're done.

MK

[BDD]

Hi Matti

Thanks for the details !!!

Now i have one more doubt on this topic .

In our environment , we use reflection and we I start reflectionX I will get a list of XDCMP hosts
Can I disable it by commenting line " Dtlogin.requestPort:" in Xconig file . Will it effect working of X11 forwarding via ssh


B.Dathan

[Matti_Kurkela]

X11-over-SSH does not use XDMCP at all, so yes, you can disable it.

I think you have to set Dtlogin.requestPort to 0 instead of only commenting it out to disable XDMCP.

MK