# rm-rf.es | Administración de sistemas

Blog de un SysAdmin Unix, Gnu/Linux, Windows y lo que haga falta.

Generar un certificado SSL con genkey (Red Hat Keypair Generation)

Hoy vamos a ver una alternativa a la generación de certificados SSL con OpenSSL. Genkey (Red Hat Keypair Generation) es un comando disponible como parte del paquete crypto-utils:

# yum whatprovides */genkey
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
....
....

crypto-utils-2.4.1-24.2.el6.i686 : SSL certificate and key management utilities
Repo        : base
Matched from:
Filename    : /usr/bin/genkey

Aprovechamos entonces para instalarlo:

# yum install crypto-utils

Echando un vistazo a la ayuda podemos ver las opciones del comando:

# genkey 
Usage: genkey [options] servername
    --test   Test mode, faster seeding, overwrite existing key
    --genreq Generate a Certificate Signing Request (CSR)
    --makeca Generate a self-signed certificate for a CA
    --days   Days until expiry of self-signed certificate (default 30)
    --renew  CSR is for cert renewal, reusing existing key pair, openssl certs only
    --cacert Renewal is for a CA certificate, needed for openssl certs only
    --nss    Use the nss database for keys and certificates
    --gdb    For package maintainers, to trace into the nss utilities

¡Qué motivo podríamos tener para utilizar genkey en lugar de openssl? Corregidme si hay algún otro más, pero en principio lo que yo veo es que no tenemos que acordarnos de los comandos de openssl ya que genkey es un asistente en modo text/gráfico desde línea de comandos que nos guía con todos los pasos.

Si quisieramos generar un certificado self-signed para ssl.rm-rf.es seguiríamos estos pasos:

# genkey ssl.rm-rf.es

Comienza el asistente, que ya nos indica donde van a guardarse los ficheros resultantes (llaves privadas, certificados, certificate requests, CA requests, etc.)

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 1

Indicamos el tamaño de la llave, a mayor tamaño en bits, mayor seguridad, también costará más tiempo generarla:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 2

Esperamos a la generación de los bits aleatorios:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 3

Y la generación de datos aleatorios. Se recomienda mover el ratón o escribir en la consola del servidor/máquina para acelerar el proceso:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 4

Si quisiéramos enviar una petición de CSR a una entidad certificadora autoritativa (CA) este sería el momento:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 5

Para mayor seguridad podemos encriptar la llave privada del certificado. La frase de paso (passphrase) que indiquemos tendrá que ser introducida cada vez que arranquemos el servicio web seguro.

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 6

Por último introducimos los datos de nuestro certificado:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 7

Una vez aceptado podremos ver en la línea de comandos la ejecución del proceso por genkey:

/usr/bin/keyutil -c makecert -g 1024 -s "CN=ssl.rm-rf.es, OU=IT, O=Rm-RF, L=Zaragoza, ST=Zaragoza, C=ES" -v 1 -a -z /etc/pki/tls/.rand.2492 -o /etc/pki/tls/certs/ssl.rm-rf.es.crt -k /etc/pki/tls/private/ssl.rm-rf.es.key
cmdstr: makecert

cmd_CreateNewCert
command:  makecert
keysize = 1024 bits
subject = CN=ssl.rm-rf.es, OU=IT, O=Rm-RF, L=Zaragoza, ST=Zaragoza, C=ES
valid for 1 months
random seed from /etc/pki/tls/.rand.2492
output will be written to /etc/pki/tls/certs/ssl.rm-rf.es.crt
output key written to /etc/pki/tls/private/ssl.rm-rf.es.key

Generating key. This may take a few moments...

Made a key
Opened tmprequest for writing
(null) Copying the cert pointer
Created a certificate
Wrote 882 bytes of encoded data to /etc/pki/tls/private/ssl.rm-rf.es.key 
Wrote the key to:
/etc/pki/tls/private/ssl.rm-rf.es.key

Y nuestra private key y certificado ya están disponibles para su uso.

Comprobar la integridad de las descargas de archivos con md5sum, sha256sum…

Cuando descargamos archivos a través de Internet, por ejemplo ISOs de sistemas operativos, o paquetes RPM, DEB, etc, vienen acompañados de un “código” (hash MD5 del archivo) que sirve para verificar, una vez descargado el archivo, que no ha sido alterado por terceras partes y que podemos confiar en que es lo que realmente buscamos.

Por ejemplo, si accedemos a uno de los mirrors de CentOS vermos que además de las ISOs podemos descargar sus correspondientes checksum MD5, PGP, SHA…(*.asc y *.txt):

0_README.txt 06-Jul-2012 06:01 2.0K
CentOS-6.3-x86_64-LiveCD.iso 07-Jul-2012 13:26 692M
CentOS-6.3-x86_64-LiveCD.torrent 09-Jul-2012 14:03 217K
CentOS-6.3-x86_64-LiveDVD.iso 06-Jul-2012 09:07 1.6G
CentOS-6.3-x86_64-LiveDVD.torrent 09-Jul-2012 13:50 263K
CentOS-6.3-x86_64-bin-DVD1.iso 06-Jul-2012 06:20 4.0G
CentOS-6.3-x86_64-bin-DVD1to2.torrent 09-Jul-2012 14:15 217K
CentOS-6.3-x86_64-bin-DVD2.iso 06-Jul-2012 06:20 1.4G
CentOS-6.3-x86_64-minimal-EFI.iso 21-Aug-2012 14:30 364M
CentOS-6.3-x86_64-minimal.iso 06-Jul-2012 06:23 330M
CentOS-6.3-x86_64-netinstall-EFI.iso 18-Sep-2012 05:39 234M
CentOS-6.3-x86_64-netinstall.iso 06-Jul-2012 06:14 200M
README.txt 06-Jul-2012 06:01 2.0K
md5sum.txt 18-Sep-2012 17:31 734 md5sum.txt.asc 18-Sep-2012 17:31 1.6K
sha1sum.txt 18-Sep-2012 17:31 822
sha1sum.txt.asc 18-Sep-2012 17:31 1.7K
sha256sum.txt 18-Sep-2012 17:31 1.1K
sha256sum.txt.asc 18-Sep-2012 17:31 1.9K

En el caso de los checksum MD5 el fichero tiene el siguiente contenido:

a991defc0a602d04f064c43290df0131  CentOS-6.3-x86_64-bin-DVD1.iso
410c1c5188e6076d62d6107153738a15  CentOS-6.3-x86_64-bin-DVD2.iso
087713752fa88c03a5e8471c661ad1a2  CentOS-6.3-x86_64-minimal.iso
690138908de516b6e5d7d180d085c3f3  CentOS-6.3-x86_64-netinstall.iso
9953ff1cc2ef31da89a0e1f993ee6335  CentOS-6.3-x86_64-LiveCD.iso
0d28b5f9c9f562bd3a17c68ef05b3998  CentOS-6.3-x86_64-LiveDVD.iso
21157a19ec6a32b4fd71f0e45b9aa951  CentOS-6.3-x86_64-bin-DVD1to2.torrent
9015d02b4e22efd547a6bd8b19bce0ec  CentOS-6.3-x86_64-LiveCD.torrent
3b9c1c463cfe8983c0835f46f2db39db  CentOS-6.3-x86_64-LiveDVD.torrent
4dd1ff9a521823e033dde6b152196de7  CentOS-6.3-x86_64-minimal-EFI.iso
c750ba06d83a38494dbf100bf33014d4  CentOS-6.3-x86_64-netinstall-EFI.iso

Cada línea hace referencia al checksum de cada descarga. Una vez descargado, en GNU/Linux debemos comparar ese hash con el del fichero que hemos descargado. Para ello utilizamos el comando “md5sum“:

~$ md5sum CentOS-6.3-x86_64-netinstall.iso
690138908de516b6e5d7d180d085c3f3  CentOS-6.3-x86_64-netinstall.iso

En este caso hemos visto que efectivamente coincide, por lo que es fiable hacer uso del archivo. En el caso de que el hash fuera distinto detectaríamos que el archivo ha sido comprometido y no es fiable su descarga o utilización:

~$ md5sum CentOS-6.3-x86_64-netinstall.iso
d41d8cd98f00b204e9800998ecf8427e  CentOS-6.3-x86_64-netinstall.iso

Podéis hacer lo mismo con los hash sha y los comandos sha1sum, sha256dum, etc:

~$ sha[TAB]
sha1pass sha224sum sha384sum shasum
sha1sum sha256sum sha512sum

! bad user (foo) en los cron jobs de Solaris

Suponiendo que tenemos un usuario en Solaris que debería estar ejecutando los cron jobs establecidos en su crontab pero no está siendo así, lo primero que debemos hacer es revisar los logs de cron para encontrar el origen del problema. Podemos consultarlos en /var/cron/log.

Si lo que vemos es entradas similares a la siguiente en el log…

! bad user (foo) Tue Sep 12 15:30:10 2012

… puede significar que el usuario foo no tiene privilegios para la ejecución de crontabs, habiendo sido denegado a través del fichero /etc/cron.deny (ver “Cron linux: autorizar o denegar su uso a usuarios“):

foo:~$ crontab -l foo
You (foo) are not allowed to use this program (crontab)
See crontab(1) for more information

Pero también es muy probable que el usuario se encuentre bloqueado a nivel de sistema operativo, ya sea porque su password ha expirado, bloqueo de cuenta por excesivos logins incorrectos, etc. Puede haber muchas causas. En este caso veremos que la cuenta está marcada como el prefijo \*LK\* en el password (locked) de su entrada en el fichero /etc/shadow:

foo:\*LK\*asd73jasd80kj:::::::

También podríamos averiguarlo sin mirar el fichero shadow, con el comando passwd -s:

# passwd -s foo
foo    LK

Para desbloquearla utilizamos el parámetro -u (unlock) de passwd:

# passwd -u foo
passwd: password information changed for foo
# passwd -s foo
foo       PS

Y ya podemos ejecutar crons. El prefijo LK ha desaparecido del fichero /etc/shadow:

foo:asd73jasd80kj:::::::

AIDE (Advanced Intrusion Detection Environment)

AIDE (Advanced Intrusion Detection Environment) es, como su nombre indica un sistema avanzado de detección de intrusiones a nivel de sistema operativo. Es muy sencillo de instalar y con una configuración estándar puede funcionar realmente bien.

El funcionamiento consiste en que se crea una base de datos basada en la configuración especificada en el fichero de configuración, una vez inicializada permite ser utilizada para verificar la integridad de los ficheros del sistema y muchas otras cosas como atributos de ficheros (tipo de fichero, permisos, nº de inodo, uid, gid, tamaño, bloques, mtime, ctime, atime…), Posix ACL, SELinux, XAttrs

AIDE se ofrece precompilado en paquete para la mayoría de distribuciones por lo que la instalación es sencilla:

Debian, Ubuntu, etc:

# apt-get install aide
# aptitude install aide

FreeBSD:

# pkg_add -r aide

Red Hat, CentOS, Fedora, Scientific Linux:

#  yum install aide

Una vez instalado debemos familiarizarnos con el fichero de configuración, en el caso de Red Hat se encuentra en /etc/aide.conf, probablemente será igual en el resto de distribuciones. También podemos revisar la página man (man /etc/aide.conf) para tener más idea de todas las posibilidades y personalización.

Como os decía, la instalación base nos permite funcionar sin problemas, lo primer que hay que hacer es generar una nueva base de datos, por defecto es un fichero comprimido pero veréis en el fichero de configuración que hay más opciones:

# /usr/sbin/aide --init

Una vez terminado tendremos la nueva base de datos en /var/lib/aide/aide.db.new.gz, para evitar sobreescribir la de producción se almacena ahí, luego la copiamos o movemos a la definitiva:

# cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

En la configuración se define así:

# The location of the database to be read.
database=file:@@{DBDIR}/aide.db.gz

# The location of the database to be written.
database_out=file:@@{DBDIR}/aide.db.new.gz

Una vez generada la base de datos ya podemos ejecutar un chequeo del sistema, no debería haber ningún problema ya que acabamos de generar la base de datos y es muy difícil tener algo distinto en pocos segundos:

# /usr/sbin/aide --check

El resultado que todos esperamos es el siguiente, todo correcto:

AIDE, version 0.14

### All files match AIDE database. Looks okay!

Este mismo chequeo es el que podríamos configurar periódicamente vía cron:

# crontab -e -u root
0 5 * * * /usr/sbin/aide --check

En el momento que se generara un problema veríamos en el informe algo así (también se guarda en /var/log/aide/aide.log). Por ejemplo he modificado el fichero /etc/passwd para que saltara en el escaneo:

AIDE found differences between database and filesystem!!
Start timestamp: 2012-08-10 09:58:03

Summary:
  Total number of files:	31858
  Added files:			0
  Removed files:		0
  Changed files:		1

---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /etc/passwd

--------------------------------------------------
Detailed information about changes:
---------------------------------------------------

File: /etc/passwd
  Mtime    : 2012-08-06 12:11:53              , 2012-08-10 09:58:01
  Ctime    : 2012-08-06 12:11:53              , 2012-08-10 09:58:01
  Inode    : 22457                            , 22487

Hay que tener en cuenta que cuando tenemos un problema como este, mientras no actualicemos la base de datos de aide seguirá “cantando“. Una vez solucionado o revisado hay que generar un nuevo “snapshot” del estado del sistema para empezar de 0:

# /usr/sbin/aide --update

Os recomiendo revisar el manual si os resulta interesante para estar al tanto de todo lo que pasa en vuestros sistemas.

Nmap Online para tu IP o Clase C

Nmap Online nos permite utilizar Nmap directamente desde el navegador para poder analizar los puertos abiertos de nuestro equipo y toda la información que sabéis que puede ofrecer Nmap. Eso sí, la limitación es que podemos lanzarlo únicamente contra nuestra IP pública de salida y toda su clase C (/24) correspondiente.

Básicamente, la idea es utilizarlo como herramienta durante la securización de nuestro sistema cuando no tenemos la posibilidad de utilizar una máquina remota para lanzar pruebas de seguridad de red y escaneos de puertos, algo necesario cuando estamos realizando configuraciones en nuestro firewall. No voy a entrar en posibles usos maliciosos que se le puedan dar a la herramienta. Es recomendable leer los TOS para tener claro que y que no se puede hacer, lo que se guardan en los registros de ese servidor, el tiempo que permanecen ahí esos datos, si son públicos, etc.

Como veis en la imagen, podemos realizar un escaneo rápido, completo o personalizado, especificando los parámetros de Nmap igual que lo haríamos en la línea de comandos.

Nmap Online

Vulnerabilidad crítica en instalaciones de PHP basadas en CGI

Todas las instalaciones de PHP en modo CGI están afectadas, al parecer se trata de una vulnerabilidad de la cual nadie se había dado cuenta en nada menos que ocho años.

Básicamente, la vulnerabilidad consiste en que en este tipo de instalaciones (sólo CGI, FastCGI o DSO no se ven afectadas), si la petición/request contiene ?-s permite volcar por pantalla el código fuente PHP en lugar de interpretarlo.

Para verificar si la vulnerabilidad nos afecta, sólo es necesario añadir ?-s a la URL y ver si descargamos el código fuente, ejemplo:

dominio.com/test.php?-s

Por suerte, ya podemos descargar las versiones parcheadas desde el sitio web de PHP, concretamente la PHP 5.3.12 o PHP 5.4.2. Si no queremos o podemos actualizar tan sencillamente, podemos aplicar un workaround mediante el cual configuramos unos rewrite, ya sea en el virtualhost o a nivel de .htaccess para bloquear este tipo de peticiones. Para Apache con mod_rewrite:

         RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
         RewriteRule ^(.*) $1? [L]

Más información en www.php.net

Consultar y exportar certificados SSL en Sun Web Server (certutil y pkcs12)

Sun Web Server (en este artículo trabajamos sobre la versión 6.1) almacena los certificados y llaves privadas en ficheros .db (cert8.db y key3.db). Vamos a hacer uso de los comandos certutil y pkcs12 para poder hacer operaciones de listado y exportación de certificados (con o sin private key).

Para listar los certificados que tiene instalados el servidor web debemos usar el comando certutil, que se encuentra en la ruta /bin/https/admin/bin/. Los ficheros .db que comentaba antes se encuentran en la carpeta “alias” por defecto. Podéis copiarlos a una ruta temporal para trabajar con ellos en lugar de directamente en la ruta de producción. Una vez realizado, nos colocamos en esa carpeta y ejecutamos el siguiente comando:

$ certutil -L -d .

    CERTIFICADO-WEB                                                CTu,u,u

Como podéis comprobar, en este servidor web tenemos instalado el certificado CERTIFICADO-WEB. Si queremos exportarlo en formato ASCII sin su private key podemos usar el mismo comando pero especificado el certificado y el parámetro -a (ASCII). En formato binario usamos el parámetro -d (DER):

$ certutil -L -d . -n "CERTIFICADO-WEB" -a
    -----BEGIN CERTIFICATE-----
    MIICTjCCAbAxasdhljkads8akjasdolasdYjEfMB0GA1UEChMWU3Vu
    ...
    ...
    asd3asd23sadasdadsasdasd
    -----END CERTIFICATE-----
$ certutil -L -d . -n "CERTIFICADO-WEB" -d

Finalmente, si lo queremos exportar en formato legible:

$ certutil -L -d . -n "CERTIFICADO-WEB"
     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number: ...
             Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
             Issuer:
...
...

En caso de necesitar exportar también la private key del certificado, hacemos uso del comando pkcs12. En este caso necesitaremos la password del “NSS Certificate DB” para poder acceder a los certificados del servidor así como especificar una nueva para el fichero resultante PKCS12. Seguimos ubicados en la carpeta donde están los ficheros *.db. Especificamos el fichero de salida (certificado.p12, y el nombre del certificado.

$ pk12util -o certificado.p12 -n 'CERTIFICADO-WEB' -d .
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
Re-enter password:
pk12util: PKCS12 EXPORT SUCCESSFUL

Cómo limitar el acceso root de forma local y por tty

Pueden existir circunstancias en las que queramos, además de lo típico que es desactivar el acceso root por ssh, desactivar el acceso local para el usuario root.

Para ello tenemos el fichero /etc/securetty, en el cual aparece un listado de las consolas virtuales disponibles en el sistema (tty). Aparecerán todas las que puedan ser utilizadas, pero no tienen porque estar activas. En sistemas RedHat y derivados se especifican en /etc/init/start-ttys.conf.

Bien, para desactivar entonces el acceso root a cualquiera de esas tty, o a todas, únicamente hay que eliminarla o comentarla en ese fichero. A partir del momento que guardemos los cambios “root” ya no podrá acceder por los accesos locales/ttys desactivadas:

# cat /etc/securetty 
console
vc/1
vc/2
vc/3
...
vc/9
vc/10
vc/11
#tty1
#tty2
#tty3
#tty4
#tty5
#tty6
#tty7
#tty8
#tty9
#tty10
#tty11

Si necesitamos mayor detalle en las restricciones, o hacer lo mismo con otros usuarios, debemos revisar el fichero /etc/security/access.conf. Veréis que está perfectamente documentado y que podemos realizar configuraciones como las siguientes:

# Disallow non-root logins on tty1
#
#-:ALL EXCEPT root:tty1
#
# Disallow console logins to all but a few accounts.
#
#-:ALL EXCEPT wheel shutdown sync:LOCAL
#
# Same, but make sure that really the group wheel and not the user
# wheel is used (use nodefgroup argument, too):
#
#-:ALL EXCEPT (wheel) shutdown sync:LOCAL
#
# Disallow non-local logins to privileged accounts (group wheel).
#
#-:wheel:ALL EXCEPT LOCAL .win.tue.nl
#
# Some accounts are not allowed to login from anywhere:
#
#-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL
#
# All other accounts are allowed to login from anywhere.
...
...
...

Verificar la integridad y seguridad de ficheros con RPM

rpmRPM nos ofrece una utilidad muy valiosa que nos permite verificar la integridad y seguridad de todos los paquetes y aplicaciones instaladas en el sistema (con yum o rpm). Básicamente, lo que vamos a hacer es verificar todos los ficheros de todos los paquetes instalados en el sistema. La verificación consiste en comprobar la información de estos ficheros con la que hay almacenada en la base de datos rpm. Vamos a verificar el MD5 checksum, los permisos, el propietario y grupo, tamaño del fichero, etc. Para ello utilizaremos los parámetros –verify o -V.

De primeras podemos descartar los ficheros de configuración, ya que lo más normal es que su contenido cambie, aunque todavía podríamos revisar su configuración de permisos, propietario, etc.

Si queremos hacer una revisión de todos los ficheros del sistema, algo que lógicamente puede tardar bastante tiempo, utilizaremos el siguiente comando. Hay que tener en cuenta que en caso de no haber salida todo es correcto:

# rpm -Va

Si queremos hacer la revisión de un único paquete lo indicamos y quitamos el parámetro “a”:

# rpm -V telnet

Y si quisiéramos revisar un único fichero:

# rpm --verify --file /usr/bin/chcon

¿Y qué sucede si se detecta algún problema? Vamos a verlo. Voy a hacer un backup del binario /usr/sbin/apachectl y a reescribirlo:

# mv /usr/sbin/apachectl /usr/sbin/apachectl.BAK
# touch /usr/sbin/apachectl
# rpm -V --file /usr/sbin/apachectl
S.5....T.  c /etc/httpd/conf/httpd.conf
S.5....T.    /etc/rc.d/init.d/httpd
S.5....T.  c /etc/sysconfig/httpd
SM5....T.    /usr/sbin/apachectl

Como véis ahora sí que hay salida. Tenemos 8 puntos que se pueden convertir en otros caracteres cuando hay algo que no cuadra:

  • 5: fallo en el checksum MD5
  • S: discrepancia en el tamaño del fichero
  • T: fecha de modificación distinta al original
  • L: enlace simbólico
  • D: dispositivo
  • U: usuario
  • G: grupo
  • M: permisos

Así pues, en el ejemplo anterior vemos como el binario apachectl tiene un checksum MD5 distinto, distinto tamaño, fecha de modificación y de permisos. La “c” es de fichero de configuración.

Si queremos comprobar de una tacada la integridad de todos los binarios de /usr/sbin, es tan sencillo como:

# rpm -Va | grep "/usr/sbin"
S.5....T.    /usr/sbin/apachectl

Podemos añadir un mayor nivel de debug con el parámetro “v”, “vv” más debug aún:

# rpm -Vv --file /usr/sbin/apachectl
# rpm -Vvv --file /usr/sbin/apachectl

Como veis, esta es una buena y sencilla forma de asegurarnos que los binarios del sistema no han sido alterados y también de tener un control del estado de los ficheros de configuración, etc.

Instalar y configurar TigerVNC server y utilizarlo con un túnel SSH

Instalar y configurar el servidor VNC TigerVNC es realmente sencillo. Lo que muchas veces no nos paramos a pensar es que el protocolo en sí no es seguro por lo que el tráfico no está cifrado al conectar al escritorio remoto. Vamos a ver como solucionarlo.

Lo primero es instalar TigerVNC con yum (RHEL, CentOS, Scifi linux, etc). En este caso instalo también el cliente para hacer las pruebas en local:

# yum install tigervnc-server tigervnc

Una vez instalado debemos saber que la configuración se realiza en el fichero /etc/sysconfig/vncservers. Los comentarios del fichero nos indican claramente como configurarlo, también hice un artículo hace un tiempo, echadle un vistazo: Instalar y configurar vnc-server en CentOS/RHEL/Fedora

He creado un usuario “alex” al que únicamente se le permite el acceso local por seguridad:

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.  
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see this URL:
# http://kbase.redhat.com/faq/docs/DOC-7028

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"
VNCSERVERS="2:ale
VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"

Creamos el password VNC para el usuario del siguiente modo:

# su alex -c "vncpasswd"
Password: XXXX
Verify: XXXX

Arrancamos el servidor VNC para el usuario alex:

[alex@localhost /]$ vncserver
xauth:  creating new authority file /home/alex/.Xauthority

New 'rhcsa:1 (alex)' desktop is rhcsa:1

Starting applications specified in /home/alex/.vnc/xstartup
Log file is /home/alex/.vnc/rhcsa:1.log

Llegados a este punto podemos acceder sin problemas en local al escritorio remoto con el comando vncviewer:

$ vncviewer localhost:1

Desde fuera no, por motivos de seguridad. Para ello vamos a crear un tunel SSH de modo que las conexiones VNC con el exterior sí que estén cifradas. Vamos a usar por ejemplo el puerto 6922 para el tunel. El servidor VNC se encuentra en la IP 10.0.0.100, desde el equipo remoto con el que queremos conectar al servidor creamos el tunel:

$ ssh alex@10.0.0.100 -L 6922:10.0.0.100:5901 -N

Y ya está, podemos acceder remotamente al servidor VNC de forma segura con el nuevo puerto:

$ vncviewer localhost:6922

Si queréis usar el estandar podéis mantener los puertos de VNC:

$ ssh alex@10.0.0.100 -L 5901:10.0.0.100:5901 -N
$ vncviewer localhost:1