[kwlug disc.] Understanding the X Window System

Thu Feb 8 21:00:10 EST 2007

I've edited your post a bit to make it easier to follow my responses. -
Oksana

On 2/6/07, Unsolicited <unsolicited at gto.net> wrote:
>
>
>
> > I had heard that VNC wasn't as secure as ssh
>
> Divide up remote access / viewing and remote access / 'network
> inter-connection'

Yes, I guess I didn't make that clear.  I was really thinking inside a
network in a place of business.  I do understand that you can use ssh across
the internet quite effectively.

First, deal with remote access / 'network connection'. (1) Everyone
> has, or should, have a firewall - if your firewall doesn't let those
> ports in, it's a non-issue. Most don't have the ports open, but it
> gets more risky when you (typically) open a range or ports, usually
> 'high' up, for things like Torrent. (2) Not usually an issue for home
> users, but the network of computers behind the firewall are at risk
> from each other. Typically the I.T. Administrators implement a
> consistent authentication behaviour and each remote viewing mechanism
> follows it or has their own (such as VNC). One doesn't usually have to
> worry about their co-workers, and I.T. Admins. normally require you to
> make your machine available (for good reason).

As an admin, in a place of business, I still worry about co-workers or those
that have too much access and are just poking around.   I've heard it said
that as much as 80% of all attacks come from within networks rather than
outside.  We've traditionally been a NetWare shop and of couse, have a lot
of Windows servers and the concept of firewalls on corporate machines for
inside the network is something not everyone is doing yet.  Of course we
have firewalls and the like in place for protection from the internet.  I
guess I'm struggling with how to best protect linux systems - which method
of remote access from within (from your desk) and not in the freezer [aka
the server room].  Along this same vein is how to have people run things
with root privileges [admin team] but still know who made the changes and at
what time and from where... and of course, not have everyone [co-workers,
sysops etc.] have root access.

        UDP and TCP are equally 'secure' - TCP has more overhead, but is
> more
> deterministic. TCP doesn't typically open a wide range of higher
> ports, for things like Torrent. Torrent is fairly unusual, and cool,
> for having its own mechanism for making sure each packet was correctly
> received, and for reordering them as necessary.

Yes, I understand TCP is connection-oriented whereas UDP is not.  I was just
inquiring about the underlying architecture... which protocols does ssh or
VNC rely upon.  I was thinking that having an understanding of these things
can lead to a better and more secure implementation of any remote access
solution.

        So, if a VNC port isn't open on the firewall, but ssh is, you can
> limit the things you need to worry about. And so on.
>
>         SSH is a wonderful thing in several ways. Because you can tunnel
> through it, you can, for example, leave only one port open on the
> firewall, then tunnel VNC through it.

I hadn't really thought of tunnelling VNC through ssh.  I just assumed one
would use one or the other - ssh with X or VNC or simply ssh.

        Moreover, at its most secure form, SSH can be used with certificates
> (only, or as well). A file, usually generated on the ssh server by the
> ssh administrator must be present on the calling computer - if the
> server requires it, and you don't have it, goodbye. This avoids the
> whole snooping, cracking passwords, and everything else, problem. If
> you lose the key (a) you don't get in, (b) a simple deletion operation
> on the server renders the certificate useless, should your laptop get
> stolen or something. You can give the same certificate to multiple
> things - which allows all of them to talk to ssh - usually then there
> are additional userids/passwords used to direct the individual to
> their specifics. [Access separated from individual authentication /
> permission.]

What I would like to do is limit who can ssh into the [Linux or NetWare]
server - even inside our network.  Hostname is not enough, that's easy
enough to get around.

>        Second, remote viewing. There are more VNC clients out there than
> you
> can shake a stick at. None to my knowledge encrypt the viewing, which
> should not matter anyways - you have to have allowed the remote viewer
> in, they have to be watching you at the time, and you have to be doing
> something worth watching at the time. I believe there are now
> utilities to record VNC sessions, but as a snooping tools I don't
> believe it to be practical - storage and bandwidth requirements would
> consume quite a bit, in the hope something useful will be gleaned.

This example is more specific to Windows ~
I'm not thinking so much of a remote session to a machine I'm sitting in
front of, more of a machine in the server room running an app that can't or
won't run as a service [on Windows] and you need to be on the console to
troubleshoot it or whatever.  How do you make VNC more secure there?  And
how do you know who connected?

        One, tight VNC, combines ssh and VNC to give you absolutely secure
> access, so no worries about snooping. It is well regarded.
>
>         But, you're right, in the end, VNC via ssh is more secure. And
> having
> gone through the pain of setting up ssh, everything else comes along
> for the ride.
>
>
>
          Having said all this ... setting up an ssh server is irritating
> enough, I wouldn't want to have to implement it on every computer.
> VNC, though, brings so much usefulness that it is worth setting on
> every computer (with no user acceptance required) - everyone has to
> decide on their own risk acceptance levels, but for an internal
> network, in my opinion, setting up ssh on every computer isn't worth
> the aggravation.

We use ZENworks to connect to user workstations within our environment.
Servers  - we use a utility designed for NetWare and for Windows we use RDP,
Linux we're just starting with and I want to set it all up correctly from
the beginning [or as correctly as is possible !!].

       In my own experience, you use ssh, VNC, remote x, whatever, because
> of the particular requirements of what you are trying to do. Although
> one reasonably usually thinks bandwidth should be important, the
> requirements of what you are trying to do usually forces you into a
> particular mode where you consume whatever bandwidth you need to
> consume to satisfy the requirement. Only then do things like freeNX
> become an issue.

I was thinking if bandwidth was a big issue one would just use ssh and the
cli.  :)

As you have noted, it is not atypical for RDP (aka MS Windows Terminal
> Server) and VNC have been combining clients, and most every distro has
> a VNC client easily available. RDP is another option, just as secure
> as https.
>
>         So, RDP is yet another option, in the typical plethora of choices
> GNU/Linux offers.

So, when I'm using KDE and I configure VNC - is it not using RDP?  That's
what it seemed to be saying when I looked into it.  VNC server if you want
to serve up your machine and a RDP client to connect to VNC servers.  I have
used the Linux RDP client to talk to our Windows servers and it does that
quite nicely.

          FWIW, the presence of any of the above does not mean that gnuPG,
> etc., aren't still needed or useful. These, in the end, as they are
> typically used today, have more to do with end to end / client to
> client / individual to individual secure communications, whereas the
> above has to do with inter-network communication and access, and
> inter-computer access. [vs. person to person access such as via e-mail.]

I was only thinking of GnuPG in terms of understanding how the security in
ssh works, not as a comparison of features between ssh and GnuPG.

ssh CAN use userids, passwords, certificates, or one or all.
> Certificates are similar beasties to what gnuPG and https use. Usually
> all placed in different places. [This is why things like PAM, and
> non-VNC authentication mechanisms that use it, can reduce the
> complexity in your life.] X's magic cookies are equivalent to SSH's
> certificates. Otherwise, one has zero to do with the other.
>
>         With two way encryption (?) having one key allows you to decrypt
> something encrypted with the other key. Sessions go something like two
> magic/random numbers are generated. Each side then agrees to use these
> numbers for further (negotiation) communications. Assuming each side
> has the other's public key, one encrypts 'I am me' with their private
> key, then encrypts with the agreed key. The other decrypts on the
> agreed key, then decrypts on the other side's public key, and things
> proceed. Ultimately the negotiated stuff times out, and a new
> negotiation occurs, but the public/private key stuff still plays a
> role. Essentially: I encrypt with my private key so you can decrypt
> with my public key. You encrypt with my public key so only I can
> decrypt with my private key. [And access to the private key is also
> typically password protected.]
>
>         That is snooping security (encryption) and authentication (it
> really
> came from you, and only you can read it).
>
>         Before you complete the process, you will have had to go through a
> permissions validation as well. Just because public keys have been
> exchanged, doesn't mean you're allowed to talk. The server still has
> to allow you to talk. Authorizing you may or may not involve
> certificates, userids, and passwords, or all of the above.

Right.  Thanks.  That helped to clarify some things in my mind.  Even if you
get on the box, there still is authentication and what you can do is limited
by who you are (username).

> I'm assuming that if your home directory mounted as a fileshare then
> > possibly your hidden directory for .gnupg could be also more or less
>
>
> Mounting as a file share doesn't necessarily mean you have access.
> George may be able to see it can be mounted, but that doesn't
> necessarily mean he has the password in order to see the files within
> it.

True.  I was thinking more of other admin's or person's with elevated
access.  And yes, don't put private keys on the network - kind of defeats
the purpose, no?  :)

> available.  When I looked at the file on my machine it's a binary
> > file - so would that make it more protected?
>
> Typically a password is required to decrypt, so even if you get the
> file / have access to it, the binary data needs the additional
> password to make use of it. (The contents make no sense without it.)

Okay.  Thanks for that explanation and all your time on this.  :)

Oksana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.ccjclearline.com/pipermail/kwlug-disc/attachments/20070208/91add43f/attachment.htm