* Robert Casties wrote on Thu, Sep 21, 2000 at 14:57 +0200:
Sorry I did anything like this in practice. You could of course setup a real VPN (there was a thread about using freeSWAN on this list) but maybe that's overkill and port forwarding by SSH can do it.
It's not for the asked question but for other connects:
If you have a local X-Session and you make a ssh connect, ssh
forwards the X data automatically. To make this possible, ssh
sets DISPLAY to localhost:
Try searching the net on more specific info or just start experimenting by forwarding the X ports 6000, 7100 (any other?) and xdmcp 177 from your "VPN-router" to your server and point the terminals to the "VPN-router".
Still there must be no access to the X terminals network segment or the whole exercise will be futile since the traffice goes unencrypted between the terminal and the "VPN-router".
If IpSec-based VPN should be used, I suggest to block anything except proto-50 (and maybe proto-51?) and port 500 UDP to avoid accidently unencrypted data.
AFAIK all traffic on the wire goes unencrypted, cookie or not. So if anyone can sniff the network traffic you can't help it.
Yep, and all other attack methods should work too, like TCP hijacking.
Is there a way of anhancing the security of the whole XDMCP-Authentication-Thingy?
I don't know any way.
You could check if it's possible to use some one-time-passwords, then it's useless to sniff them, but usually it's hard to work with such things... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.