Módulo 3

Tema 3.1: Configurar servidor FTP

3.1.1 Realización de la instalación de dominio VSFTPD

FTP (File Transfer Protocol) es un protocolo de transferencia de archivos, por lo general

usa el puerto 20 y 21 exclusivamente sobre TCP. El puerto 20 es utilizado para el flujo de
datos entre cliente y servidor. El puerto 21 es utilizando para el envío de órdenes del cliente
hacia el servidor. Prácticamente todos los sistemas operativos y plataformas incluyen
soporte para FTP, lo que permite que cualquier computadora conectada a una red basada
sobre TCP/IP pueda hacer uso de este servicio a través de un cliente FTP.
Existen dos métodos, el modo activo y el modo pasivo.

Modo activo de FTP.

En este modo, el cliente crea una conexión de datos a través del puerto 20 del servidor,
mientras que en el cliente asocia esta conexión desde un puerto aleatorio entre 1024 y
65535, enviando PORT para indicar al servidor el puerto a utilizar para la transferencia de
datos. Tiene como desventaja que el cliente FTP debe estar dispuesto a aceptar cualquier
conexión de entrada asociada a puertos entre 1024 y 65535, lo que significa que el cliente
tendría que estar detrás de un muro cortafuegos que acepte establecer conexiones
entrantes en este rango de puertos o bien acceder hacia Internet sin un muro cortafuegos
de por medio, lo que evidentemente implica un enorme riesgo de seguridad. El modo activo
sólo es conveniente en la ausencia de un muro cortafuegos entre el servidor y el cliente,
como ocurre en los escenarios de una red de área local.

Modo pasivo de FTP.

Fue creado como una alternativa al problema que representa el modo activo. A diferencia
de éste último, el modo pasivo envía PASV en lugar PORT a través del puerto de control
del servidor. Éste devuelve como respuesta el número de puerto a través del cual debe
conectarse el cliente para hacer la transferencia de datos. El servidor puede elegir al azar
cualquier puerto entre 1024 y 65535 o bien el rango de puertos determinado por el
administrador del sistema. En el caso de vsftpd, se puede definir un rango arbitrario de
puertos para conexiones pasivas utilizando las opciones pasv_min_port y pasv_max_port.
Éste es el método recomendado para servidores de acceso público.

Primeramente instalaremos el servidor VSFTPD que utiliza en cualquier distribución de

linux, en nuestro caso CENTOS y empezamos a instalar mediante el gestor yum.

Una vez instalada tenemos que configurar el archivo /etc/vsftpd/vsftpd.conf y empezamos

a configurar.

Configuración de parámetros de conexión

Primeramente editamos con vi el archivo vsftpd.conf y buscamos la siguiente línea y

cambiamos los valores
Esta opción permite ingresar sin necesidad de tener un usuario configurado, nuestra
recomendación es dejarla en NO si no queremos que esto suceda.

Permite escribir en los directorios y archivos sobre los que tengamos acceso.

Esta opción permite que los usuarios anónimos (recordemos la opción anonymous_enable)
escriban en los directorios y archivos. Podemos dejarla tal cual está, en NO, nuestra
recomendación.

Dicha variable permite que los usuarios anónimos puedan crear directorios nuevos en el
servidor, viene en NO por defecto.

Esta opción viene incluida en la configuración predeterminada. Sirve para establecer el

banderín de bienvenida que será mostrado cada vez que un usuario acceda al servidor.
Puede establecerse cualquier frase breve que considere conveniente, pero sin signos de
puntuación.

Unas ves cambiadas estos parámetros procedemos a guardar y levantar el servidor

VSFTPD de la siguiente manera:
Y realizamos la prueba primeramente creándonos un usuario en linux con grupo de ftp. Por
ejemplo:

Obviamente con un Password asignado al usuario_1. Luego pasamos a comprobar la

conexión con el servidor VSFTPD desde un cliente ftp para nuestro caso será la consola de
DOS de Windows.

Cuando ingresamos por FTP al servidor linux la conexión siempre nos lleva a su carpeta
creada del usuario en la dirección /home/usuario_1

Pero la desventaja que tiene esta configuración es que podemos subir un nivel mas arriba
para ver los archivos.
En el recuadro se ve que el usuario_1 pudo acceder hasta la raíz, pero no copiaría archivos
ni escribiría si no tiene asignado propiedades de chmod en los archivos para que puedan
escribir y modificarles pero igual sería una vulnerabilidad. Pero existe una solución a este
problema y es la de enjaular al usuario lo cual debemos agregar los siguientes líneas de
códigos en el /etc/vsftpd/vsftpd.conf.

Con lo anterior cada vez que un usuario local se autentique en el servidor FTP, sólo tendrá
acceso a su propio directorio personal y lo que éste contenga. Por favor recuerde crear el
archivo /etc/vsftpd/chroot_list debido a que de otro modo será imposible que funcione
correctamente el servicio vsftpd, volvemos a resetear el servicio ara hacer las pruebas.

Y nos volvemos a conectar al servidor FTP.

También llega los casos en que tenemos que administrar un poco el ancho de banda con
el motivo de mejorar la transmisión y no volverlo lenta. Póngase el caso que si estamos
descargando un archivo de 1GB el cliente estaría ocupando todo el ancho de banda del
servidor para poder descargar lo cual hace bajar la QoS del servidor, lo bueno de VSFTPD
se puede administrar el ancho de banda agregando o modificando la siguiente línea en el
archivo /etc/vsftpd/vsftpd.conf

Esto hace que la tasa de transferencia sea de 1MB. Ojo que este valor está en byte.
También se puede limitar el número de conexiones que puede tener el servidor lo cual
agregamos al archivo vsftpd.conf

Y todo cambio realizado en el archivo vsftpd.conf se tiene que volver a reiniciar el servicio
vsftpd. Veamos el ejemplo de las conexiones:
También podemos limitar la cantidad de conexiones por ip agreando al vsftpd.conf la
siguiente línea:

Y realice la prueba para comprobar si resulta la línea configurada.

Seguridad en servidor FTP

Podemos apreciar en el grafico siguiente que el trafico FTP no está encriptado y se ve
claramente datos relevantes y de suma importancia para el atacante si quiere atacar el
servidor VSFTPD.

Si ven en el protocolo FTP se ve el usuario y la contraseña del usuario que se conecta al

servidor FTP y además la lista de archivos que tiene, para solucionar este problema
VSFTPD viene para configuración segura con certificados SSL de seguridad, estos
certificados permite a que todo el tráfico FTP sea encriptado y no se pueda ver el contenido.
Aclarar que el FTP en si es solo el paso de comandos (USER, PASS, NLST).

Para configurar con certificado SSL primeramente tenemos que verificar si tenemos
instalado OpenSSL, RSA y x.509, lo cual verificamos con el comando yum.

Luego nos dirigimos al directorio /etc/pki/tls y en ese archivo generaremos el certificado

conjuntamente la llave.
Ejecutamos el comando y primeramente generara la llave RSA y después nos pedirá los
siguientes datos para llenar.

Una vez llenado, en el archivo cert se encuentra vsftpd_linux.crt y la firma digital

llave_vsftp.key les damos propiedad de lectura y escritura solo para el usuario root.

Editamos el archivo /etc/vsftpd/vsftpd.conf y agregamos las siguientes líneas:

Grabamos y reiniciamos el servidor VSFTPD, para hacer pruebas se necesita un cliente ftp
que soporte certificado ssl para conexiones en ftp. Para verificar utilizaremos el programa
winscp.
Y conectamos.
Si analizamos el tráfico de red veremos que se está encriptando la información.

Instalación de ssh – ftp (SFTP)

SSH File Transfer Protocol (también conocido como SFTP o Secure File Transfer Protocol)
es un protocolo del nivel de aplicación que proporciona la funcionalidad necesaria para la
transferencia y manipulación de archivos sobre un flujo de datos fiable. Se utiliza
comúnmente con SSH para proporcionar la seguridad a los datos, aunque permite ser
usado con otros protocolos de seguridad. Por lo tanto, la seguridad no la provee
directamente el protocolo SFTP, sino SSH o el protocolo que sea utilizado en su caso para
este cometido.

Creamos los directorios y asignamos los permisos donde van acceder los usuarios los
cuales tengan permiso.

Creamos el grupo (sftp) y usuario (alumno_1)

Configurar Enjaulado SFTP.

Accedemos al archivo de configuración /etc/ssh/sshd_config

Buscamos la siguiente línea y la comentamos (Ponemos delante #), de la siguiente forma:

Nos damos al final del documento (Para ir al final con vi :$ ) y añadimos lo siguiente:
Guardamos la configuración y reiniciamos el servicio sshd

Y por último cambiamos el nombre de usuario y el grupo del usuario alumno_1

Hacemos la prueba con el usuario creado con el programa scp para la conexión sftp
Y hacemos la prueba de transferencia de archivos, pero existe un peligro de seguridad que
igual topamos con ftp, que es enjaular al usuario que solo use su carpeta o vea solo su
carpeta. Para poder realizar esto se debe aumentar en el archivo /etc/ssh/sshd_config.

Para enjaular a los usuarios disponemos de 2 opciones. Enjaular usuario por usuario, o
enjaular a un grupo entero de usuarios. Únicamente podemos seleccionar una de las 2
opciones.

Opción 1: Enjaular a un grupo de usuarios

Para enjaular a un grupo de usuarios hay que modificar la configuración del fichero
sshd_config. Antes de realizar cualquier modificación en la configuración de este fichero,
realizaremos una copia del fichero ejecutando el siguiente comando en la terminal:

Una vez realizada la copia de seguridad ya se puede editar el fichero de configuración

introduciendo el siguiente comando en la terminal:

Para enjaular al grupo de usuarios del servidor, tenemos que ir al final del fichero de
configuración e introducir los siguientes parámetros:

Reiniciamos el servicio

Opción 2: Enjaular usuario por usuario

Para enjaular a un usuario hay que modificar la configuración del fichero sshd_config, y
modificar lo siguiente:
Reiniciamos el servicio de sshd

Saque sus conclusiones por usted mismo para ver la configuración que se hizo.

Tema 3.2: Configurador de Servidor Apache

3.2.1 Montar Servidor Apache en Linux

Podemos hacerlo editando el fichero “/etc/hosts”. Al final de la línea que empiece por
127.0.0.1 añadimos el nombre que queramos, quedando de la siguiente manera:

También habrá que hacerlo en el fichero “/etc/sysconfig/network”, cambiando el valor de la

variable “HOSTNAME”. En este caso el fichero queda de la siguiente manera:

Y luego pasamos a actualizar el sistema de Centos.

Instalamos las herramientas que necesitamos, herramientas de desarrollo como

compiladores GCC, MAKE, fuentes del kernel y perl.

Esto instala los mínimos paquetes para desarrollo. Si queremos instalar todos ellos,
podremos hacerlo ejecutando el siguiente comando:
Instalamos PHP, para el desarrollo de páginas dinámicas

Puede que nos falte alguna cosa, así que podemos correr la siguiente línea para completar
la instalación de PHP:

Seguidamente, podemos configurar la zona horaria predeterminada usada por las funciones
"date" y "time", para ello en el fichero "/ etc/php.ini" añadimos la siguiente línea:

Instalamos el servidor apache

Podemos completar la instalación del servidor Apache instalando las librerías de desarrollo:

Para ver la versión de Apache instalada, ejecutamos:

Configuración general de Apache

Ahora pasamos a configurar el servidor web apache, en este caso Centos a apache lo
define como servidor httpd lo cual iniciamos el servicio.

El fichero principal de configuración se encuentra en "/etc/ httpd/conf/httpd.conf", y el resto

de ficheros de configuración en "/etc/httpd/conf.d".

Ahora empezaremos a configurar el archivo httpd.conf. Ahora daremos un nombre al

servidor. Aunque no es necesario hacer esto, sí es recomendable para que no aparezcan
problemas en los arranques. Para esto nos aseguramos de que en el fichero de
configuración httpd.conf tengamos la siguiente línea:

Y volvemos a recargar el servidor httpd de la siguiente manera:

Veamos ahora si está funcionando bien nuestro servidor web, abrimos un explorador
cualquiera e introducimos la IP del equipo en la barra de direcciones y tendría que salir la
siguiente imagen:

Por seguridad es recomendable eliminar la página de pruebas del servidor lo cual editamos
el siguiente archivo /etc/httpd/ conf.d/welcome.conf y comentamos lo siguiente.

Y luego reiniciamos el servicio web para ver que no saldrá la página de inicio.
Nuestro servidor está funcionando con http por el puerto 80 lo cual es considerado como
inseguro, y es necesario ponerlo a puerto seguro al protocolo https por el puerto 443, para
lo cual configuraremos de la siguiente manera.
Primera mente debemos instalar el openssl, porque https para que sea segura tiene que
ser con un certificado ssl, instalamos de la siguiente manera:

Una vez instalada realizamos la generación de la misma.

Los siguientes comandos se pueden utilizar para generar un certificado auto-firmado. En
primer lugar, generar una clave privada con cifrado de 2048 bits.

Luego genere solicitud de firma de certificado (CSR).

Por último, generar un certificado auto-firmado de tipo X 509, que tiene una validez de 365
días, pero podemos hacerlo para más días.

Una vez creado el certificado, copia los archivos en los directorios necesarios.

Ahora editamos el archivo /etc/httpd/conf.d/ssl.conf para configurar y agregar los

certificados ssl. Y modificamos las siguientes líneas:
A continuación, reinicie el servicio httpd para que los cambios surtan efecto. El servidor web
ya está listo para usar HTTPS.
Ahora hacemos un ajuste a httpd.conf para poder siempre entrar con https con puerto 443,
para ello editamos /etc/httpd/conf/httpd.conf y modificamos lo siguiente:

Y luego reiniciamos el servidor httpd. Y al ingresar ingrese poniendo https://[numero de ip ]

Instalación de módulos
Para instalar los módulos complementarios de apache se instalan fácilmente desde los
repositorios de centos, ya que es más difícil instalar desde la compilación de código fuente
o rpm. Existen muchos módulos complementarios para que funcione apache pero solo
veremos los más importantes.
Si queremos ver los modulos que soporta apache ejecutamos el siguiente comando para
ver:
PHP
Php es un lenguaje de programación para realizar paginas dimanicas, lo cual nos ayuda a
realizar conexiones con base de datos. Para verificar si está instalado este módulo tiene
que ejecutar el siguiente comando:
Si está instalado le aparecerá el mensaje en caso contrario le mostrara que no encuentra
el comando de orden, en ese caso tendrá que instalar por yum.

Si deseamos ver que módulos más se pueden instalar en php ejecutamos el siguiente
comando:

PERL
Perl es un lenguaje de programación que también se acopla a httpd, primeramente nos
fijamos si está habilitado el siguiente módulo de Perl en la ruta del archivo
/etc/httpd/conf/httpd.conf y buscamos la sección de módulos:
Al verificar se ve que no se tiene configurado modulo perl lo cual procedemos a la
configuración:

Y procedemos a la instalación.
La mayor parte de las instalaciones de módulos son complementos de programación
dependiendo del lenguaje que se utilice.
Tema 3.3: Configurador de Servidor Mysql
3.2.1 Instalación de Mysql

Mysql es un gestor de base de datos relacional, desarrollado bajo licencia dual

GPL/Licencia comercial por Oracle Corporation y está considerada como la base datos
open source más popular del mundo.
En este tema instalaremos desde 0 lo que es servidor de Mysql, hay dos tipos de
distribución en linux de mysql:
- El mysql cliente o estándar, es el que no está configurado como servidor especifico.
- El mysql server o mysqld que es especialmente servidor.
Para instalar podemos realizarlo con la compilación de código fuente lo cual haremos
compilándolo ya que por el repositorio es muy sencillo de instalar. Primeramente debemos
descargarnos el código fuente de mysql de la página web en la siguiente dirección:
http://dev.mysql.com/get/Downloads/
O podemos descargarlo por modo consola de la siguiente forma, pero antes debemos
posesionarnos en la carpeta /usr/src.

Y empezamos a descargar el archivo del compilado de mysql.

Luego empezamos a descomprimir el archivo.

Luego ingresamos a la carpeta mysql-5.6.19 y veemos los archivos que comprende mysql.
El archivo INSTALL-SOURCE posee las instrucciones de instalación (en inglés). Es un
documento demasiado extenso que posee instrucciones generales y específicas para cada
plataforma. Dirigirse directamente a la sección "2.9 Installing MySQL from Source", El
archivo BUILD-CMAKE posee información específica acerca de cmake.
Antes de comenzar es necesario instalar ciertas herramientas necesarias para compilar
(cmake, bison y flex). En CentOS ejecutar yum install cmake bison flex, en Debian y
derivados apt-get install cmake bison flex, también instalar todas las librerías de ncurses y
por ultimo zlib zlib-devel openssl openssl-devel valgrind valgrind-devel cmake gcc cpp
ncurses ncurses-devel bison gcc-c++
El demonio MySQL requiere un usuario y grupo para su ejecución y configuración de
permisos en las instancias:

Las versiones recientes de MySQL utilizan CMake para generar la configuración del código
fuente antes de compilar. Es posible listar todos los parámetros de configuración junto con
una breve ayuda, ejecutando:

A modo de ejemplo, configurar MySQL con readline, SSL, y utilizando el directorio de

instalación /usr/local/mysql-5.6.19:

Compilar e instalar.
Utilizo el directorio /usr/src/local/mysql56 en vez de simplemente /usr/src/local/mysql, por si
en el futuro es necesario actualizar a una nueva versión. De esta forma,
/usr/src/local/mysql56 es un link simbólico al directorio de instalación:

Ajustar los permisos en el directorio de instalación para que el dueño y grupo sea "mysql", y
denegar la ejecución para el resto de los usuarios:

A continuación, es necesario crear el archivo de configuración del servidor MySQL. Para

ello, crear el directorio "etc" dentro del directorio de instalación:

Junto con el código fuente, se incluyen diferentes plantillas de archivos de configuración de

MySQL, para diferentes tipos y tamaño de sistemas. Estos archivos de configuración de
ejemplo se encuentran dentro del directorio "support-files".
Copiar el archivo de configuración my-default.cnf al directorio "etc" creado en el paso
anterior, con el nombre "my.cnf":
Ajustar los permisos adecuadamente, tanto para el directorio "etc", como para el archivo de
configuración:

Configuración del servidor MySQL:

La configuración del demonio dependerá de cada instalación en particular. Si se requiere

utilizar una partición grande para almacenar las instancias, se debe modificar el directorio
de datos que utiliza MySQL por defecto (/usr/local/mysql/data/). Configurar el directorio de
datos para las instancias de bases de datos utilizando la variable "datadir" (en este ejemplo
/data/inst1).
3.2.2 Configuración de MySQLD
La sección principal de configuración del demonio mysqld es similar a la siguiente:
Revisar cuidadosamente los límites de tamaño para paquetes y buffers.
Si se utilizan tablas InnoDB, es necesario configurar las siguientes variables:
En este ejemplo se ha configurado el motor de almacenamiento InnoDB para reservar
porciones de espacio en disco en incrementos de 512 Mb.
Si el directorio que se ha definido para las instancias no existe, es necesario crearlo:

Habiendo configurado MySQL correctamente, es posible crear las bases de datos de

sistema. Para ello ejecutar:

Luego, establecer la contraseña del usuario "root" de MySQL (administrador). Se debe

especificar el nombre de host (en el ejemplo, "localhost") y la contraseña (en el ejemplo,
"123456"):

Finalmente, instalar el script de control del servicio, iniciar el demonio mysqld ejecutando:
3.2.3 Seguridad en MySQL
Lo que conlleva referente a seguridad en mysql se puede ver este aspecto desde 2 puntos
de vista a nivel usuario con privilegios y a nivel de conexión. Primeramente veremos a nivel
usuario con privilegios.
Cuando realizamos la instalación de mysql por compilación el usuario root está sin
contraseña lo cual es una parte insegura de la conexión a la base de datos. Para lo cual
podemos realizar mediante consola con el siguiente comando:

Una vez realizado reiniciamos el servidor mysql y listo.

Para poder crear usuario se debe ejecutar el siguiente comando y asignamos privilegios.
Cómo otorgar permisos de usuario diferentes
Aquí está una pequeña lista del resto de los posibles permisos que los usuarios pueden
gozar.
ALL PRIVILEGES: como mencionamos previamente esto permite a un usuario de MySQL
acceder a todas las bases de datos asignadas en el sistema.
CREATE: permite crear nuevas tablas o bases de datos.
DROP: permite eliminar tablas o bases de datos.
DELETE: permite eliminar registros de tablas.
INSERT: permite insertar registros en tablas.
SELECT: permite leer registros en las tablas.
UPDATE: permite actualizar registros seleccionados en tablas.
GRANT OPTION: permite remover privilegios de usuarios.
Para proporcionar un permiso a usuario específico, puedes utilizar ésta estructura:

GRANT [permiso] ON [nombre de bases de datos].[nombre de tabla] TO ‘[nombre de

usuario]’@'localhost’;
Si deseas darles acceso a cualquier base de datos o tabla, asegurate de insertar un
asterisco (8) en lugar del nombre de la base de datos o tabla.

Cada vez que tu actualizas o cambias permisos, asegúrate de refrescar los privilegios
mediante FLUSH PRIVILEGES;.

Si necesitas remover un permiso, la estructura es casi idéntica a la que los asigna:

REVOKE [permiso] ON [nombre de base de datos].[nombre de tabla] FROM ‘[nombre de

usuario]’@‘localhost’;
Así como puedes borrar bases de datos con DROP, también puedes usar el comando
DROP para borrar usuarios:

DROP USER ‘usuario_prueba’@‘localhost’;

Para probar el nuevo usaurio, debes cerrar sesión escribiendo quit y volviendo a iniciar
sesión con éste comando en la consola:

mysql -u [nombre de usuario]-p

Tema 3.3: Configuración del Servidor SAMBA

3.3.1 Montar Servidor SAMBA en Linux
Acerca del protocolo SMB

SMB (acrónimo de Server Message Block) es un protocolo, del Nivel de Presentación del
modelo OSI de TCP/IP, creado en 1985 por IBM. Algunas veces es referido también como
CIFS tras ser renombrado por Microsoft en 1998. Entre otras cosas, Microsoft añadió al
protocolo soporte para enlaces simbólicos y duros así como también soporte para archivos
de gran tamaño. Por mera coincidencia, esto ocurrió por la misma época en que Sun
Microsystems hizo el lanzamiento de WebNFS.

SMB fue originalmente diseñado para trabajar a través del protocolo NetBIOS, el cual a su
vez trabaja sobre NetBEUI , IPX/SPX (acrónimo de Internet Packet Exchange/Sequenced
Packet Exchange, que se traduce como Intercambio de paquetes inter-red/Intercambio de
paquetes secuenciales) o NBT, aunque también puede trabajar directamente sobre TCP/IP.

Necesitamos tener instalados los siguientes paquetes:

- samba: Servidor SMB.

- samba-client: Diversos clientes para el protocolo SMB.
- samba-common: Archivos necesarios para cliente y servidor.

Procedemos a la instalación.

Luego de instalar quitamos selinux y el firewall.

Editamos y ponemos selinux en disabled y reiniciamos el servidor.

Una vez reiniciado el servidor desactivamos el firewall.

Unas ves realizadas estas operaciones pasamos a configurar el SAMBA.

3.3.2 Configuración General de SAMBA

SAMBA está formado por tres demonios principales:

- nmbd. Este demonio es el encargado del registro y la resolución de peticiones de

los clientes.
- smbd. Este demonio samba propiamente dicho, es el encargado de todos los
servicios de conexión entre los sistemas en las operaciones con archivos e
impresoras.
- Winbind. Este demonio solo debería ser iniciado cuando SAMBA sea miembro de
un dominio NT o un ACTIVE DIRECTORY.

Antes de empezar a ponernos a configurar es interesante conocer algunos comandos

básicos para administrar SAMBA y para saber conectarnos y/o visualizar archivos e
impresoras compartidas en nuestra red.

Algunos comandos útiles desde línea de comandos:

- smbtree. Este comando realizara una búsqueda en todos los dominios y grupos de
trabajo que encuentre y mostrara todos los recursos compartidos de cada uno.
- smbclient. Este comando es el cliente de samba que permite mostrar los recursos
compartidos de las maquinas que se le indiquen como parámetro y permite
conectarse a ellas emulando un servicio FTP.
- smbmount. Permite mostrar ficheros compartidos en máquinas remotas en tu
maquina local como si fuera un archivo más de tu sistema de ficheros.
- smbpassword. Este es el comando de administración de contraseñas de samba.

Accedemos al archivo de configuración.

Y en el parámetro de workgroup identificamos el grupo en Windows al que vamos a
pertenecer.

Creamos los usuarios, los usuarios en Linux deben ser iguales a los usuarios en SAMBA.

Ahora habilitamos al usuario cursolinux en SAMBA.

Ahora procederemos a compartir archivos de Linux en la red de Windows. Para esto
volvemos a acceder a /etc/samba/smb.conf y agregamos la siguiente línea:

Lo guardamos y activamos SAMBA.

3.3.3 Compartir recursos en Windows en Linux

Para poder compartir recursos en Windows y podamos accederlo solo debemos compartir
normalmente los recursos, primeramente compartiremos una carpeta en Windows para
poder acceder en linux.

Hacemos click derecho en el archivo que queremos compartir.

Hacemos click en propiedades y nos aparecerá la siguiente ventana.
Luego hacemos click en Uso compartido avanzado…… y aparecerá lo siguiente.

Hacemos click en el botón Permisos y tickeamos todas las opciones.

Aplicar y luego aceptar. Luego en el servidor Linux hacemos lo siguiente.

Con el comando smbclient –L nos muestra solo los recursos compartidos que tiene la
maquina Windows, en este caso solo tiene el disco C compartido. También podemos hacer
el siguiente comando:
Si queremos acceder a ver los archivos y manipularlos debemos entrar desde el entorno
grafico de Linux de la siguiente manera.
Para ver de Windows a Linux debemos abrir una ventana de Windows, y en la barra de
dirección poner la ip del servidor Linux.

Se coloca el usuario y contraseña que se creó en Linux con samba.

Son los archivos configurados en el archivo smb.conf también se puede configurar el
servidor samba de forma web gracias a samba swat y se instala de la siguiente manera:

Una vez instalado procedemos a configurar el archivo /etc/xinetd.d/swat

E iniciamos el servidor xinetd para ingresar

Tema 3.5 Seguridad
3.5.1 Realizar tareas de administración de la seguridad

Administrar la seguridad de la red

Los sistemas Linux se conectan a internet de una manera más o menos directa, por lo que
la seguridad de la red es particularmente importante debido a que los servidores
incorrectamente configurados pueden suponer una vía de entrada de intrusos. Existen
varios métodos para proteger los ordenadores de la red, algunos de ellos implican apagar
o restringir el acceso a los servidores controlando los puertos de red que utilizan. Podemos
comprobar las conexiones de red existentes, revisar los puertos abiertos, utilizar un súper
servidor para limitar el acceso y desactivar los servidores que no utilicemos.
Utilizar las restricciones de un súper servidor

Muchos servidores abren los puertos de red y escuchan en busca de conexiones

directamente, sin embargo, algunos operan a través de un intermediario: un súper servidor
es un programa que escucha las conexiones de red para otro programa, cuando se inicia
una conexión, le pasa el control de esta al servidor adecuado. Esto puede parecer una
complicación sinsentido, pero posee ventajas frente a una conexión más directa. Por
ejemplo, puede reducir la carga de la memoria si controla muchos servidores pequeños que
rara vez se utilizan, ya que la mayor parte del tiempo estará sólo cargado el súper servidor.
Otra ventaja es la seguridad: podemos utilizar comprobaciones de seguridad en el súper
servidor para proteger todos los servidores que este controla. inetd y xinetd son los
principales súper servidores de Linux, en inetd la seguridad la gestiona un paquete llamado
TCP Wrappers, por el contrario, las características de seguridad de xinetd están montadas
sobre el propio xinetd.

Siempre que sea posible, aplicaremos controles de acceso redundantes. Por ejemplo,
utilizar las funciones de seguridad del propio servidor como los TCP Wrappers o xinetd para
bloquear los accesos no deseados. Esto nos ayudará a protegernos de bugs y
configuraciones defectuosas si surge un problema en la configuración del súper servidor,
probablemente el bloqueo secundario que tendrá el intruso. Si configuramos el sistema
meticulosamente, los accesos de este tipo dejarán un mensaje en el fichero de registro que
alertará de que el súper servidor no hizo su trabajo.

Configurar inetd

inetd fue el súper servidor estándar de Linux y se sigue utilizando en algunas distribuciones.
Durante la última década xinetd ha ido ganando terreno. Para averiguar que súper servidor
utiliza nuestro sistema escribiremos ps ax | grep inetd, la salida debería mostrar una línea
con los comandos inetd o xinetd. También hay sistemas que no ejecutan ningún súper
servidor.

Detalles de configuración de inetd

Los servidores iniciados a través de inetd se controlan con el fichero /etc/inetd.conf o los
ficheros de /etc/inetd.d/ el fichero inetd.conf lo componen una serie de líneas, una para
cada servidor. Una línea típica presenta el siguiente aspecto:

ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd -l

Este ejemplo hace referencia a in.ftpd, un servidor FTP que fue bastante popular, pero que
hoy en día ha sido sustituido por otros servidores FTP. Algunos no se pueden ejecutar
desde un súper servidor.

Las versiones recientes de inetd no utilizan un único fichero de configuración, sino que
permiten dividirlo en varios ficheros del directorio /etc/inetd.d/. Esto permite añadir o eliminar
fácilmente configuraciones del servidor añadiendo o eliminando sus ficheros de
configuración. Las siguientes descripciones hacen referencia a /etc/inetd.conf, pero
también se aplican a los ficheros de /etc/inetd.d/.

Cada línea consta de varios campos separados por uno o más espacios, sus significados
son los siguientes:
Nombre del servidor: el primer campo (ftp en el ejemplo) es el nombre del servicio tal como
aparece en el fichero /etc/services.
Tipo de socket: el tipo de socket le indica al sistema qué tipo de conexión debe esperar:
una conexión fiable de dos sentidos (stream), una conexión menos fiable con menos
sobrecarga (dgram), una conexión de bajo nivel de red (raw) o alguna otra. Las diferencias
entre ellas son muy técnicas, nuestra principal preocupación debe ser escribir
correctamente el valor especificado por la documentación del servidor.
Protocolo: este es el protocolo de la capa de transporte TCP/IP utilizado, que suele ser tcp
o udp.
Wait/nowait: en los sockets de tipo dgram esta opción indica si el servidor se conecta al
cliente y liberará el socket (nowait) o si procesara todos los paquetes y después se
desconectará pasado un tiempo determinado (wait). Los servidores que utilizan otro tipo de
socket deberían especificar nowait en este campo.
Usuario: es el nombre de usuario que ejecuta el servidor, las opciones más comunes son
root y nobody, aunque existen otras posibilidades. Por regla general, deberíamos ejecutar
los servidores con un usuario con pocos privilegios, sin embargo, algunos servidores
tendrán que ejecutarse como root. Los detalles se mencionan en la documentación del
servidor.
Nombre del servidor: es el nombre de fichero del servidor. En este ejemplo se especifica
/usr/sbin/tcpd, que es el binario de TCP Wrappers. Este programa es una importante
herramienta de seguridad que deberíamos incluir habitualmente como medio para iniciar
programas a través de inetd.
Parámetros: todo lo que sigue al nombre del servidor son parámetros que se le pasan a
éste. Si utilizamos TCP Wrappers le pasaremos el nombre del servidor de destino, por
ejemplo, /usr/sbin/in.ftpd junto con sus parámetros en este ejemplo.
En inetd.conf la almohadilla (#) indica un comentario, por lo que si queremos desactivar un
servidor que se ejecuta a través de inetd, sólo tendremos que colocar una almohadilla al
inicio de su línea. Si queremos agregar un servidor a inetd.conf tendremos que crear una
entrada, la mayoría de estos servidores incluyen entradas de ejemplo en su documentación.
Hay distribuciones que incluyen ejemplos para las entradas de los servidores más
habituales en el fichero /etc/inetd.conf, normalmente como ejemplos, sólo tendremos que
eliminar la almohadilla del comienzo del la línea para activar el servidor.

Tras modificar inetd.conf tendremos que reiniciar el súper servidor inetd, que se suele
ejecutar como un servidor SysV estándar, por lo que podemos reiniciarlo escribiendo:

# /etc/rc.d/init.d/inetd restart
Otra alternativa es recargar la configuración de inetd pasándole al script de inicio el
parámetro reload, ya que restart apaga el servidor y después lo enciende. Con reload el
servidor nunca deja de funcionar, simplemente vuelve a leer el fichero de configuración e
implementa los cambios. Si utilizamos restart es más probable que los cambios se apliquen
correctamente, pero también es más probable que se interrumpan las conexiones
existentes. En lugar de utilizar el script SysV podemos utilizar kill o killall para pasarle la
señas SIGHUP a inetd. Esta señal hace que inetd recargue su configuración. Por ejemplo,
podemos escribir kill -HUP PID si conocemos el PID de inetd o killall -HUP inetd para hacer
que todas las instancias de inetd recarguen sus ficheros de configuración. Esto debería
funcionar de un modo similar a reload del script de inicio SysV de hecho, estos scripts
suelen utilizar esta técnica para implementar esta opción. Suele ser preferible desactivar
todos los servidores posibles en inetd.conf lo que mejorará la seguridad del sistema
eliminando servidores potencialmente peligrosos.
Controlar el acceso mediante TCP Wrappers

El paquete TCP Wrappers proporciona un programa conocido como tcpd. En lugar de hacer
que inetd llame directamente a un servidor, inetd llamará a tcpd para verificar si un cliente
está autorizado para acceder al servicio; si el cliente está autorizado, tcpd llama al programa
servidor.

TCP Wrappers se configura a través de los ficheros /etc/hosts.allow y /etc/hosts.deny. El

primero especifica los ordenadores a los que se les permite el acceso de una manera en
particular, por lo que los sistemas no listados no tienen permitido el acceso. El segundo lista
los ordenadores que no tienen permitido el acceso, todos los demás podrán acceder. Si un
ordenador aparece en ambos ficheros hosts.allow tendrá prioridad. Los dos ficheros tienen
el mismo formato y se componen de líneas con la siguiente forma:

lista-demonios : lista-clientes
lista-demonios es una lista de servidores que utilizan los nombres de /etc/services. Se
pueden utilizar comodines además de ALL para denotar todos los servidores. lista-clientes
es una lista de ordenadores a los que se les concede o deniega el acceso a los demonios
especificados. Se pueden especificar por nombre, IP y podemos especificar una red
utilizando un punto inicial o final al identificar redes por su nombre o su bloque de
direcciones IP, por ejemplo, .luna.edu para todos los ordenadores del dominio luna.eduy
192.168.7. para todos los ordenadores de la red 192.168.7.0/24. También podemos utilizar
comodines como ALL para todos los ordenadores y EXCEPT ,que genera una excepción,
por ejemplo, 192.168.7. EXCEPT 192.168.7.105 se refiere a todos los ordenadores de la
red 192.168.7.0/24 excepto a 192.168.7.105.

Las páginas MAN de hosts.allow y hosts.deny proporcionan información sobre

funcionalidades más avanzadas, deberíamos consultarlas cuando creemos reglas para
TCP Wrappers. Debemos recordar que no todos los servidores están protegidos por TCP
Wrappers, sino que sólo aquellos servidores que inetd ejecute a través de tcpd estarán
protegidos de este modo. Esto suele incluir servidores telnet, ftp, tftp, rlogin, finger, POP e
IMAP, aunque existen más. No obstante, hay servidores que pueden analizar
independientemente los ficheros de configuración de TCP Wrappers.

Configurar xinetd
xinetd es un súper servidor ampliado. Proporciona lo funcionalidad de inetd y opciones de
seguridad similares a las de TCP Wrappers. Muchas distribuciones utilizan xinetd por
defecto, sino podemos reemplazar inetd por xinetd en cualquier distribución.
Detalles de configuración de xinetd
El fichero /etc/xinetd.conf controla xinetd. Las distribuciones que utilizan por defecto xinetd
sólo contienen por defecto opciones globales y una directiva para incluir los ficheros de
/etc/xinetd.d/ en el fichero xinetd.conf. Cada servidor que ejecute xinetd instalará un fichero
en /etc/xinetd.d con sus propias opciones de configuración.
Independientemente de que el servidor se incluya en cualquiera de las dos ubicaciones, la
información guardada es similar a la del fichero inetd.conf. Sin embargo, el fichero de
configuración de xinetd abarca varias líneas con un etiquetado más explícito. A continuación
se muestra un ejemplo equivalente a la entrada de inetd.conf que vimos anteriormente. En
la entrada hay exactamente la misma información que en inetd.conf, excepto porque no se
incluye una referencia a /usr/bin/tcpd (TCP Wrappers), ya que xinetd incluye una función
similar a tcpd.
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
}
Si incluimos la línea disable = yes en una definición de servicio, xinetd ignorará la entrada.
Hay servidores que instalan ficheros de inicio en /etc/xinetd.d/, que tiene desactivada esta
opción por defecto, por lo que deberemos indicarle disable = no para activar el servidor.
Podemos desactivar un conjunto de servidores listando sus nombres en la sección defaults
de xinetd.conf con una línea llamada disabled, como en disabled = ftp shell.
Tras realizar los cambios en la configuración, deberemos reiniciar el súper servidor xinetd
de manera similar a como reiniciamos inetd. Podemos emplear reload o restart:
# /etc/rc.d/init.d/xinetd restart
También podemos pasarle la señal SIGHUP a través de los comandos kill o killall para hacer
que xinetd recargue su fichero de configuración, suele ser el método más adecuado para
distribuciones como slackware que no emplea el script de inicio SysV convencional para
iniciar xinetd.
Controlar el acceso mediante xinetd
La seguridad se controla a nivel de servidor utilizando los parámetros de configuración de
/etc/xinetd.conf o los ficheros de configuración específicos de cada servidor. Algunas de
estas opciones son similares a la función de hosts.allow y hosts.deny:
Interfaz de red: la opción bind le indica a xinetd que sólo debe escuchar en busca del
servicio en una interfaz de red. Por ejemplo, bind = 192.168.23.7 hace que sólo se escuche
en la tarjeta de red asociada con dicha dirección. Esta característica es extremadamente
útil para los routers, así como para asociar un servidor sólo a la interfaz de circuito cerrado
127.0.0.1 si algún servidor sólo está disponible localmente. Podemos hacer esto con una
herramienta de configuración como la herramienta de administración web de SAMBA, swat.
Esta opción posee un sinónimo: interface.
Direcciones IP o de red permitidas: la opción only_from permite especificar direcciones IP,
redes o nombres de ordenador separados por espacios. xinetd sólo aceptará conexiones
de estas direcciones, es similar a las entradas hosts.allow de TCP Wrappers.
Direcciones IP o de red no permitidas: la opción no_access permite indicar los ordenadores
o redes que deseemos incluir en nuestra lista negra. Es similar a hosts.deny de TCP
Wrappers.
Tiempos de acceso: la opción access_times define las horas durante las que los usuarios
pueden acceder al servidor. El formato es hora:min-hora:min, utilizando un reloj de 24
horas. Esta opción sólo afecta a las horas durante las que el servidor responderá. Por
ejemplo, si access_tiemes está definido como 8:00-17:00 y alguien accede a las 16:59,
dicho usuario podrá seguir utilizando el sistema más allá de las 17:00, la hora de corte.
Estas opciones se deben incluir en los ficheros de /etc/xinetd.d, que correspondan a los
servidores que queramos proteger. Colocaremos las líneas entre el corchete de apertura y
cierre ( { } ) del servicio. Si queremos restringir todos los servidores controlados por xinetd
colocaremos las entradas en la sección defaults de /etc/xinetd.conf. Algunos servidores
proporcionan mecanismos de control de acceso similares a TCP Wrappers o xinetd. Por
ejemplo, pueden proporcionar opciones hosts allow y hosts deny que funcionan de manera
similar a las entradas de TCP Wrappers, suelen ser las opciones más comunes en los
servidores delicados o imposibles de ejecutar a través de inetd o xinetd.
Configurar un cortafuego
Un cortafuego restringe el acceso a otros ordenadores o programas que se ejecutan en un
ordenador y protegen sólo a éste. Existen dos tipos de cortafuegos: cortafuegos de filtrado
de paquetes, que bloquean o permiten el acceso en base al información de los paquetes
de datos individuales, y los filtros proxy, que procesan parcialmente una transacción y
bloquean o permiten el acceso en base a las características de alto nivel de esta
transacción.
En Linux, el kernel incluye un cortafuegos de filtrado de paquetes que se puede programar
a través del programa iptables, escribiendo iptables seguido de varias opciones que definen
restricciones específicas. Para crear un cortafuegos eficaz debemos conocer iptables en
detalle y escribir un script que llame repetidamente a este programa para definir las reglas.
Hay distribuciones que ponen las cosas más fáciles proporcionando un script genérico que
podemos configurar utilizando una herramienta GUI, se suele diseñar para proteger a un
único ordenador de accesos externos no deseados. Linux también puede comportarse
como un cortafuego para una red entera, no obstante, este tipo de configuración requiere
un conocimiento a fondo de iptables, además de saber cómo configurar Linux como un
router.
Desactivar los servidores no utilizados
La mayoría de distribuciones vienen con un gran número de servidores que pueden ser una
ventaja, ya que nos evitará tener que buscar los servidores que queramos ejecutar. Por otra
parte, es un inconveniente, ya que, si no tenemos cuidado, podemos acabar ejecutando un
servidor sin tan siquiera darnos cuenta de que está instalado. Deberíamos buscar
periódicamente los servidores y apagar los que no son realmente necesarios. Para ello
podemos ejecutar herramientas como netstat, lsof y escáneres de red remotos. También
podemos buscar pistas sobre lo que se está ejecutando. Podemos desactivar los servidores
desinstalando el paquete o reconfigurando el servidor.
Utilizar netstat
netstat permite diagnosticar la seguridad de la red buscando actividad en los puertos
abiertos de un ordenador. Es la navaja suiza de las herramientas de estado, proporciona
muchas opciones y formatos de salida para distribuir la información sobre tablas de
enrutamiento, estadísticas de la interfaz, etc. Para localizar los servidores innecesarios
utilizaremos netstat con las opciones -a y -p:
# netstat -ap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID / Program Name
tcp 0 0 *:ftp *:*
LISTEN 690 inetd
tcp 0 0 teela.rodsbooks.com:ssh nessus.rodsbooks.:39361
ESTABLISHED 787/sshd
El comando netstat muestra conexiones de red activas que pueden revelar la presencia de
servidores que se ejecutan en el ordenador. Las columnas Local Address y Foreing Address
especifican las direcciones local y remota incluyendo el nombre de host o dirección IP y el
número de puerto o nombre asociado de /etc/services. En este ejemplo, la línea que
muestra la conexión FTP no está conectada activamente, por lo que la dirección Local, la
dirección Remota y el número de puerto se muestran mediante asteriscos. No obstante,
esta línea indica que se está ejecutando un servidor FTP a través del protocolo tcp. La
columna State especifica que el servidor está escuchando conexiones. La columna final
PID/Program name indica que el proceso con ID (PID) 690 está utilizando el puerto, en este
caso es inetd. Este servidor se está ejecutando y escuchando conexiones, pero nadie esta
realmente conectado a el.
La segunda línea indica una conexión entre teela.rodsbooks.com y nessus.rodsbooks.com.
El sistema local (teela) utiliza el puerto ssh y el cliente (nessus) utiliza el puerto 39361
ambos con el protocolo tcp. El proceso que controla la conexión es sshd, que se ejecuta
con la PID 787.
El análisis detallado de la salida de netstat puede llevar algún tiempo, pero nos
proporcionará un mejor conocimiento de las conexiones de red de nuestro sistema. Si
localizamos servidores que escuchan conexiones que no sabíamos que estaban activas,
deberíamos investigar sobre ello; algunos pueden ser inofensivos o incluso necesarios,
pero otros pueden ser riesgos potenciales para la seguridad. Cuando utilicemos la opción -
p para obtener el nombre y la PID del proceso, la salida de netstat superará la anchura de
80 columnas, por lo que resulta útil abrir una ventana xterm de anchura especial para
visualizar la salida o bien redireccionarla a un fichero que analizaremos posteriormente en
un editor de texto capaz de mostrar más de 80 columnas. Para localizar rápidamente
servidores que escuchan conexiones utilizaremos netstat -lp en lugar de netstat -ap. El
resultado mostrará todos los servidores que escuchan conexiones, omitiendo conexiones
cliente e instancias de servidor específicas que ya estén conectadas a clientes.
Utilizar lsof
lsof lista los nombres de los ficheros abiertos. Con él podemos identificar qué ficheros están
abiertos en un directorio, quién accede a ellos, etc. La definición de fichero de lsof incluye
las conexiones de red. Por lo tanto, podemos utilizar lsof en lugar de netstat para algunas
tareas como localizar los servidores que están en uso, la forma más básica de obtener
información acerca de la red es pasandole el parámetro -i:
# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE
NAME
ssh 2498 rodsmith 3u IPv4 3292662 TCP
nessus.rodsbooks.com:53106->seeker.rodsbooks.com:ssh (ESTABLISHED)
exim4 4827 Debian-exim 5u IPv4 3369596 TCP *:smtp
(LISTEN)
sshd 4997 root 3u IPv4 13273 TCP
*:ssh (LISTEN)
Esta salida está truncada para que sea más manejable, en ella se muestran dos tipos de
conexiones: la primera, que comienza con ssh, muestra una conexión saliente de
nessus.rodsbooks.com hacia el puerto ssh de seeker.rodsbooks.com. Este tipo de
cvonexiones se identifican por la existencia de dos nombres de host en la columna NAME
y por la palabra clave ESTABLISHED de la misma columna. Las siguientes dos líneas
muestran dos servidores que escuchan conexiones en los puertos SMTP y SSH (exim4 y
sshd). Estas líneas se identifican por el hecho de que la columna NAME adopta la forma
*:servicio (LISTEN), donde servicio es el nombre del servicio o el número de puerto, otras
columnas de la salida muestran información como la PID y el nombre de usuario asociado
con el acceso al puerto.
Si escribimos lsof -i como un usuario normal, sólo veremos nuestras propias conexiones de
red, por lo que si queremos que el comando nos sea útil, debemos ejecutarlo como root.
Para restringir la salida podemos incluir una dirección tras la opción -i. La dirección tomará
la siguiente forma:
[46] [protocolo] [@nombrehost | dirhost] [:servicio | puerto]
4 o 6 representa una conexión IPv4 o IPv6, protocolo es el tipo de protocolo (tcp o udp),
nombrehost o dirhost es el nombre o la dirección IP del sistema remoto, servicio es el
nombre del servicio de /etc/services y el puerto es el número de puerto. Por ejemplo, si
queremos verificar que no se está ejecutando ningún servidor FTP, buscaremos las
conexiones asociadas con el:
# lsof -i :ftp
También podemos sustituir FTP por 21, ya que es el puerto asociado con el servicio FTP.
El comando devuelve una lista de todos los procesos asociados con las conexiones FTP,
tanto entrante como saliente. Si no hay conexiones, el comando no genera ninguna salida.
Tendremos que notar que líneas de salida están asociadas con servidores y cuáles son
procesos cliente. Si los usuarios del ordenador utilizan clientes FTP, el comando producirá
decenas de líneas de salida aunque no ejecutemos ningún servidor FTP.
Para realizar una auditoría general de las conexiones de red del sistema, escribiremos lsof
-i sin restringir la salida. Es aconsejable canalizar la salida mediante less o utilizar un buffer
desplazable de xterm, grep puede resultar un atajo para localizar los servidores activos
filtrando mediante la cadena LISTEN:
# lsof -i | grep LISTEN
Si consultamos la salida sin utilizar grep, obtendremos una idea más clara del uso global
de la red del sistema. Si localizamos algo sospechoso como una conexión de red saliente
que no debería estar, esto puede indicar un intento de ataque de un usuario, el acceso de
un intruso o la actividad de un gusano o troyano. Si identificamos programas que no se
deberían estar ejecutando, como servidores innecesarios, podemos utilizar el nombre del
comando, su PID u otra información para intentar apagarlo.
Utilizar escáneres de red remotos
Los escáneres de red pueden buscar puertos abiertos en el ordenador local o en otros
ordenadores, los más sofisticados también buscan vulnerabilidades conocidas, lo que nos
indica si un servidor puede estar en riesgo en caso de que lo dejemos funcionando. Los
crackers utilizan estos escáneres para localizar posibles sistemas objetivo. Muchas
empresas tienen políticas que prohíben el uso de estas herramientas excepto bajo
condiciones específicas. Si queremos usarlas en nuestra empresa, deberíamos consultar
las políticas y obtener un permiso explícito, por escrito y firmado, de lo contrario podríamos
perder el empleo o incluso podrían acusarnos de un delito.
nmap es capaz de realizar una comprobación básica de los puertos abiertos. Le pasaremos
el parámetro -sT y el nombre del sistema objetivo tal y como se indica a continuación:
$ nmap -sT seeker.rodsbooks.com
Starting Nmap 4.53 ( http://insecure.org ) at 2008-09-04 15:38 EDT
Interesting ports on seeker.rodsbooks.com ( 192.168.1.6 ):
Not shown: 1704 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
2049/tcp open nfs
3306/tcp open mysql
Nmap done: 1 IP address ( 1 host up ) scanned in 0.100 seconds
La salida muestra cuatro puertos abiertos: 22, 80, 2049 y 3306, utilizados por ssh, http, nfs
y mysql. Si no somos conscientes de que estos puertos estaban abiertos, deberíamos
acceder al sistema escaneado e investigar un poco utilizando netstat, lsof o ps, para
localizar los programas que utilizan estos puertos. -sT especifica un analisis de puertos tcp,
pero también hay servidores que se ejecutan sobre puertos udp, por lo que tendremos que
utilizar -sU para analizar los servidores de los puertos udp. nmap puede realizar escaneos
más sofisticados, incluyendo escaneos que no detectan la mayoría de los cortafuegos y
escaneos mediante ping para detectar que host están activos.
nessus está montado sobre nmap, proporciona GUI y medios para realizar pruebas
automatizadas y aún más sofisticadas. Viene como cliente y componentes de servidor
independientes, el cliente permite controlar el servidor que hace el trabajo real.
Cuando utilizamos un escáner de red debemos tener en cuenta que los puertos que vemos
desde nuestro sistema de prueba pueden no ser los mismos que serían visibles para un
atacante. Esto es importante si estamos probando un sistema que está detrás de unos
cortafuegos desde otro sistema que está detrás de los mismos cortafuegos. El sistema de
prueba revelará puertos accesibles que no lo estarán desde el mundo exterior. Por otra
parte un cracker que esté en nuestra red local tendrá acceso a estos puertos, por lo que no
debemos darnos por satisfechos con utilizar unos cortafuegos, aunque los cortafuegos son
herramientas importantes para ocultar servidores sin tener que apagarlos.
Examinar los ficheros de configuración
La mayoría de servidores de Linux incluyen ficheros de configuración, por lo que podemos
localizar servidores instalados buscando sus ficheros de configuración. La mayoría de
sistemas incluyen dos tipos de ficheros importantes: los que controlan scripts de inicio SysV
y los que controlan nuestro súper servidor.slackwareno utiliza scripts de inicio SysV, sino
un script de inicio por cada modo de ejecución, por lo que en este sistema tendremos que
localizar el script de inicio del modo de ejecución relevante buscando llamadas
sospechosas.
Generalmente, tendremos que buscar en /etc/rc?.d, /etc/init.d/rc?.d o /etc/rc.d/rc?.d, donde
? es el número del modo de ejecución, para aquellos scripts cuyos nombres adoptan la
forma S##servidor, donde ## es un número y servidor es el nombre del servidor. Si
localizamos un script para un servidor que no queremos ejecutar, deberíamos desactivarlo
mediante los scripts de inicio SysV. No debemos desactivarlo automáticamente, ya que
puede que sea necesario aunque no nos suene el nombre, antes debemos investigar más
sobre el tema.
La otra clase de ficheros de configuración principal son los de configuración del súper
servidor. Deberíamos revisar los ficheros de inetd o xinetd en busca de ficheros o servidores
no deseados; los súper servidores sólo inician servidores de red, por lo que deberíamos
utilizar un método más agresivo para desactivar las entradas que no reconozcamos de la
configuración de nuestro súper servidor.
En los sistemas antiguos vale la pena examinar /etc/inittab. Este fichero controla algunas
de las primeras etapas del proceso de inicio, por lo que es de especial interés el hecho de
que las instalaciones de /etc/inittab más antiguas iniciaban los procesos que se empleaban
para aceptar accesos de tipo texto, accesos a través de MODEM y puertos rs-232. Estos
procesos suelen recibir el nombre de getty o alguna de sus variantes como mingetty.
Normalmente, una máquina Linux tiene uno de estos procesos en ejecución y se controla
mediante una entrada de /etc/inittab:
1:2345:respawn:/sbin/mingetty –noclear tty1
El primer carácter (1) especifica la terminal virtual (VT) que controla. La mayoría de
distribuciones incluyen líneas similares para las primeras 6 VT, normalmente, no hay
necesidad de ajustar estas líneas. Las líneas que empiezan por S#, donde # es un número,
controlan el acceso por puerto serie rs-232 y MODEM:
S0:2345:respawn:/usr/sbin/mgetty -F -s 57600 /dev/ttyS0
Si queremos utilizar un MODEM y no queremos activar accesos remotos a través del
MODEM, debemos asegurarnos de que /etc/inittab no posee líneas de este tipo.
Los sistemas modernos que carecen de inittab o tienen ficheros básicos inittab, suelen
pasar estas funciones a otros ficheros, como los scripts de inicio SysV o ficheros de
/etc/event.d. No suele ser necesario modificar estas configuraciones, pero debemos
asegurarnos de que nuestro sistema no escucha innecesariamente conexiones por
MODEM de marcado. Los ficheros con nombre /etc/event.d/tty# controlan los accesos
locales mientras que los ficheros /etc/event.d/ttyS# controlan los accesos por puertos serie
rs-232 o MODEM.
Desinstalar o reconfigurar servidores
Cuando identifiquemos un servidor innecesario, la siguiente tarea es apagarlo. Para ello
existen dos opciones:
Podemos desactivar el servidor cambiando la configuración SysV o desactivándolo en el
súper servidor.Desactivar el servidor de esta manera tiene la ventaja de que podemos
volver a activarlo fácilmente si deseamos volver a utilizarlo. Tiene el inconveniente de que
los ficheros del servidor seguirán consumiendo espacio, además el servidor podría
activarse accidentalmente.
Podemos desinstalar completamente el servidor utilizando la herramienta de administración
de paquetes o borrando de algún otro modo sus ficheros. Este método tiene la ventaja de
reducir el riesgo de reactivación accidental, pero el inconveniente es que no podremos
reactivar fácilmente el servidor.
En general, suele ser preferible eliminar el servidor a menos que deseemos desactivarlo
temporalmente. Si decidimos volver a activarlo en el futuro siempre podremos reinstalarlo.
3.5.2 Administrar la seguridad local
La seguridad local abarca muchos más aspectos que las amenazas de los intrusos remotos.
Por tanto, debemos prestar atención a ciertas cuestiones como proteger las contraseñas,
limitar el acceso a root, definir los límites de los usuarios y seguir la pista de los ficheros
SUID/SGID.
Proteger las contraseñas
La configuración por defecto de Linux depende demasiado de las contraseñas, que son las
llaves del sistema de los usuarios, por lo que, si estos son descuidados, pueden aparecer
fisuras en la seguridad. Para poder mantener la seguridad del sistema es necesaria la ayuda
de los usuarios, ya que son los únicos que están en posesión de las contraseñas. Debemos
conocer también algunas de las herramientas que proporciona Linux para ayudar a
mantener la seguridad de las contraseñas.
Los riesgos de las contraseñas
Para evitar que las contraseñas acaben en manos ajenas, debemos seguir ciertas pautas,
entre las que se encuentran:
Utilizar contraseñas seguras: se deben utilizar buenas contraseñas, aunque esta práctica
no elimina todo el riesgo.
Cambiar las contraseñas con frecuencia: esto minimiza el daño por una contraseña
comprometida. Hay herramientas que ayudan a implementar estos cambios.
Utilizar contraseñas ocultas: si un individuo accede al sistema como un usuario normal,
podrá leer el fichero de contraseñas y utilizar uno de los muchos programas para obtenerlas.
Es aconsejable utilizar las contraseñas ocultas almacenadas en /etc/shadow siempre que
sea posible. La mayoría de distribuciones utilizan contraseñas ocultas por defecto.
Mantener las contraseñas en secreto: hay que recordarle a los usuarios que no se pueden
revelar las contraseñas. No se debe anotar la contraseña, guardarla en formato electrónico
o enviarla por correo u otros medios electrónicos. Los usuarios no deben ni enviar ni
guardar contraseñas y, sobre todo, jamás se deben anotar.
Utilizar protocolos seguros de acceso remoto: determinados protocolos de acceso remoto
son intrínsecamente inseguros: todos los datos atraviesan la red sin cifrar. Los ordenadores
que se encuentran entre ambos extremos de la conexión pueden atrapar las contraseñas
de estas sesiones. Es preferible desactivar telnet, ftp y otros protocolos que emplean
contraseñas en texto plano en favor de protocolos que encriptan las contraseñas, como ssh.
Evitar los fisgones: si los usuarios acceden desde terminales públicos, como campus
universitarios, cibercafes y similares, es posible que haya personas observando mientras
introducen las contraseñas. Los usuarios deben ser conscientes de esta posibilidad para
minimizar en lo posible este tipo de accesos.
Utilizar cada contraseña sólo para un sistema: si se compromete la base de datos de
contraseñas de un ordenador y los usuarios de dicho sistema reutilizan las contraseñas en
otros, se pondrán en riesgo también estos otros sistemas. Es aconsejable utilizar cada
contraseña una sola vez. Hoy en día, esto puede ser casi imposible, ya que hay un gran
número de sitios web cuyo acceso requiere una contraseña. Una solución razonables es
utilizar una contraseña para los sitios menos sensibles y contraseñas únicas para los sitios
webs más sensibles y cuentas de acceso.
Tener cuidado con la ingeniería social: esta práctica implica engañar a personas fingiendo
ser un administrador del sistema o confundiéndolas de algún otro modo, para que les
entreguen sus contraseñas, es muy alto el porcentaje de usuarios que cae en el engaño.
Una práctica relacionada con ésta es el phishing, en el que un atacante crea un sitio web
falso o envía un correo electrónico fingiendo ser alguna otra persona, de manera que la
víctima se lo crea y le revele algún dato sensible, como su número de tarjeta de crédito.
Algunos de estos pasos son cosas que se pueden hacer, como sustituir los protocolos
inseguros por otros cifrados. Otras cosas las tienen que hacer los usuarios, lo que pone
revela la importancia de la educación del usuario, en particular en los sistemas con muchos
usuarios.
La gente tiende a volverse perezosa en los asuntos de la seguridad. Llevado a la
informática, esto se traduce en que los usuarios tienden a escoger contraseñas fáciles de
adivinar y que cambian con poca frecuencia. Linux incluye herramientas para ayudar a los
usuarios a escoger buenas contraseñas y cambiarlas regularmente.
Las contraseñas comunes suelen basarse en nombres de familiares, amigos y mascotas,
libros, películas, programas de TV, números de teléfono, direcciones postales, números de
la seguridad social y otros datos personales con significado. Cualquier palabra que se
pueda encontrar en un diccionario es una mala elección para una contraseña. Las mejores
contraseñas se basan en conjuntos aleatorios de letras, dígitos y signos de puntuación.
Lamentablemente estas contraseñas son difíciles de recordar. Una solución aceptable sería
crear la contraseña en dos pasos: primero, escoger una base que sea fácil de recordar pero
difícil de adivinar. Seguidamente, la modificaremos para que resulte más difícil de adivinar.
Un método para crear una base es utilizar dos palabras sin relación entre sí. Otro sistema,
incluso razonablemente mejor que el primero, es utilizar las primeras letras de una frase
que tenga significado. Como norma general, cuanto más larga sea la contraseña, mejor.
Las versiones antiguas de Linux tenían un límite de ocho caracteres para la contraseña;
hoy en día, gracias al uso de un hash md5, se ha elevado este límite. Hay sistemas que
exigen que la contraseña tenga cuatro o seis caracteres de longitud. La utilidad passwd no
acepta nada de longitud inferior al mínimo de la distribución.
El usuario debe aplicar al menos un par de estas posibles modificaciones:
- Añadir números o puntuación: es la modificación más importante. Como norma general,
añadiremos al menos dos símbolos o números.
- Mezclar mayúsculas y minúsculas: Linux distingue mayúsculas y minúsculas, por lo que
mezclarlas puede mejorar la seguridad.
- Invertir el orden: un cambio muy leve en sí, pero que puede mejorar algo la seguridad si
se utiliza conjuntamente a los anteriores. Podemos aplicar esto a una sola palabra o a toda
la base.
La mejor herramienta para hacer que los usuarios escojan buenas contraseñas es
educarlos. Debemos indicarles cuáles son las contraseñas fáciles de adivinar, tanto por
personas mal intencionadas como por aquellas que les escojan al azar. Además, debemos
indicarles que Linux cifra internamente las contraseñas y que existen programas que utilizan
diccionarios que pasan por algoritmos de cifrado para comparar el resultado con las
contraseñas cifradas. Emplear una contraseña que no se encuentre en un diccionario ni
sea una variante sencilla de una palabra, mejora substancialmente la seguridad. Hay que
advertir a los usuarios que sus cuentas se pueden utilizar como primer paso para acceder
a todo el ordenador o como punto de partida para atacar a otros ordenadores; advertiremos
a los usuarios de que jamás deben revelar sus contraseñas, incluso a personas que afirmen
ser administradores del sistema. También deben saber que no deben utilizar la misma
contraseña en varios sistemas. Todo esto ayuda a los usuarios a entender las razones de
nuestra preocupación y, quizá, algunos de ellos se animen a escoger buenas contraseñas.
Si los usuarios no muestran preocupación por estos asuntos, tendremos que hacer uso de
las comprobaciones de passwd. La mayoría de las implementaciones de esta utilidad
exigen que la contraseña tenga una longitud mínima y suelen comprobar la calidad de la
contraseña empleando un diccionario para eliminar las peores elecciones. Otras requieren
que una contraseña contenga como mínimo uno o dos dígitos o signos de puntuación.
Podríamos considerar la posibilidad de aplicar programas que averigüen contraseñas sobre
nuestra base de datos de contraseñas cifradas para localizar las contraseñas pobres. Esto
puede suponer el despido en muchas empresas e incluso una acusación de delito, al menos
si lo hacemos sin autorización. Debemos consultar el asunto con nuestros superiores y
obtener un permiso por escrito de una persona con la autoridad suficiente. Debemos
extremar el cuidado con los ficheros implicados, es preferible extraer las contraseñas en un
ordenador que no tenga conexiones de red.
Otro aspecto son los cambios de contraseña: si se hacen con frecuencia, minimiza el rango
de oportunidades para hacer daño, ya que, si alguien obtiene una contraseña pero ésta
cambia antes de que pueda utilizarla, el cambio de contraseñas habrá evitado el peligro.
Podemos configurar las cuentas para que requieran un cambio de contraseña periódico; si
utilizamos esta configuración, una cuenta dejará de aceptar accesos tras un periodo en
caso de que la contraseña no se cambie cada cierto tiempo (podemos configurar avisos a
los usuarios cuando se acerque este momento). Es una opción apropiada para sistemas
sensibles o con muchos usuarios, pero no debemos configurar un tiempo de expiración
demasiado corto, pues si los usuarios tienen que cambiar la contraseña con demasiada
frecuencia, es probable que alternen entre un par de contraseñas o escojan contraseñas
pobres. En la mayoría de sistemas, un periodo para el cambio de entre uno y seis meses
resulta razonable, pero en otros puede ser más largo o más corto.
Herramientas para administrar contraseñas
La mayoría de distribuciones utilizan contraseñas ocultas por defecto. Además de
proporcionar seguridad cifrando las contraseñas en el fichero /etc/shadow, las contraseñas
ocultas incorporan información adicional sobre la cuenta. Una de las ventajas de estas
contraseñas es que incluyen funcionalidades de vigencia de contraseñas y expiración de
cuenta, lo que permite implementar cambios de contraseña en intervalos regulares o
desactivar automáticamente una cuenta tras un periodo de tiempo especificado. Podemos
activar estas funcionalidades y definir los tiempos utilizando el comando chage.
La utilidad usermod se puede utilizar para ajustar algunas características de las
contraseñas ocultas, como la fecha de expiración de la cuenta. El comando chage es más
completo en lo referente a la seguridad de las cuentas, pero usermod puede ajustar más
características de otro tipo.
Limitar el acceso a root
Como root puede hacer cualquier cosa en el ordenador, debemos limitar el acceso a esta
cuenta. En un sistema con un único administrador, esto se hace definiendo una contraseña
para root que sólo conozca el administrador. Después, podremos acceder directamente
como root o utilizar su. El nombre de este comando viene de switch user y se utiliza para
cambiar la identidad aparente de un usuario. Si sólo escribimos su, se nos preguntará la
contraseña de root, si la escribimos correctamente, la sesión se convertirá en una sesión
de root. Podemos escribir un nombre de usuario detrás de su para obtener los privilegios
de dicho usuario. Si esto lo hace root, no se le exige contraseña. La opción -c nos permite
ejecutar un único programa con privilegios de root, por ejemplo, su -c “lsof -i” para ejecutar
lsof -i como root.
Acceder directamente como root está normalmente desaconsejado por varios motivos: no
deja ningún rastro en los ficheros de registro acerca de quien escribió la contraseña, que
se puede interceptar de varias maneras; si el usuario abandona la terminal, cualquiera
podría hacerse con el ordenador. Utilizar su es algo mejor que acceder directamente, ya
que su uso suele dejar una indicación en el registro del sistema sobre quién se convirtió en
root.
Un método algo más seguro que el acceso directo o su para obtener acceso como root es
el programa sudo, que ejecuta un único comando como root, por ejemplo, para ejecutar lsof
-i como root, escribiremos:
$ sudo lsof -i
[sudo] password for nombre_usuario:
El ordenador pregunta por la contraseña del usuario, no por la de root. La idea de sudo es
que primero se configure el ordenador para aceptar a determinados usuarios como usuarios
de sudo, para después poder utilizar sus propias contraseñas para realizar tareas de súper
usuario, aunque no conozcan la contraseña de root. También podemos especificar qué
tareas pueden realizar los usuarios a través del fichero de configuración /etc/sudoers.
visudo, que es una variante de vi que permite editar este fichero de una forma segura. Para
más información podemos recurrir al manual del programa con MAN visudo.
/etc/sudoers consta de dos tipos de entradas: alias y especificaciones del usuario. Los alias
son variables y pueden utilizarse para definir grupos de comandos, grupos de usuarios, etc.
Las especificaciones de usuarios vinculan usuarios con máquinas y comandos,
posiblemente utilizando alias para algunas o todas las opciones. Por tanto, podemos
configurar sudoers de manera que nombre_usuario pueda ejecutar programas de red con
privilegios de root,pero no las herramientas de mantenimiento de cuentas, mientras que
otro usuario podrá ejecutar herramientas de mantenimiento de cuentas pero no programas
de red. Probablemente /etc/sudoers incluya varios ejemplos.
Consideremos las siguientes líneas
## Storage
Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount,
/bin/umount
## Processes
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall
%sys ALL = STORAGE, PROCESSES
%disk ALL = STORAGE
%wheel ALL=(ALL) ALL
Este ejemplo define dos alias de comandos, STORAGE y PROCESSES. Los usuarios que
sean miembros del grupo sys pueden utilizar ambos, los usuarios miembros del grupo disk
podrán utilizar los comandos STORAGE pero no los PROCESSES, los miembros del grupo
wheel pueden utilizar todos los comandos del sistema.
Hay distribuciones como Ubuntu que hacen un uso intensivo de sudo, son distribuciones
pensadas para administrarlas exclusivamente con sudo y la configuración del fichero
/etc/sudoers, que proporciona al menos un usuario con fácil acceso a todas las utilidades
del sistema. Otras distribuciones que no se basan en sudo permiten alterar su configuración
para activar la administración empleándolo.
Definir los límites de acceso, procesos y memoria
A veces es deseable imponer límites al número de veces que los usuarios pueden acceder,
cuánto tiempo de CPU pueden consumir, cuánta memoria pueden utilizar, etc. Es preferible
realizar estas restricciones mediante un módulo PAM (módulo de autenticación conectable)
llamado pam_limits. La mayoría de distribuciones utilizan este módulo como parte de su
configuración PAM estándar, por lo que es posible que no necesitemos instalarlo; sin
embargo, tendremos que configurar pam_limits mediante el fichero /etc/security/limits.conf,
que contiene comentarios y líneas de límites que constan de cuatro campos:
Dominio tipo elemento valor
Cada uno de estos campos especifica un tipo particular de información:
- El dominio: describe la entidad a la que se aplica el límite, puede ser un nombre de
usuario, un nombre de grupo (que tendría la forma @nombregrupo) o un asterisco (*),
que coincide con todo el mundo.
- Límites estrictos o flexibles: tipo especifica el límite como hard (estricto) o soft (flexible).
El límite estricto lo impone el administrador del sistema y no se puede rebasar bajo
ninguna circunstancia; el límite flexible puede ser excedido temporalmente por un
usuario. Un guión (-) indica que un límite es tanto estricto como flexible.
- El elemento limitado: elemento especifica qué tipo de elemento se limita, entre ellos
están core (tamaño de los ficheros del núcleo), data (tamaño del área de datos de un
programa), fsize (tamaño de los ficheros creados por el usuario), nofile (número de
ficheros de datos abiertos), rss (tamaño de proceso residente), stack (tamaño de la
pila), cpu (tiempo de CPU de un único proceso en minutos), nproc (número de procesos
concurrentes), maxlogins (número de accesos simultaneos) y priority (prioridad de
acceso). Los elementos data, rss y stack están todos relacionados con la memoria
consumida por un programa. Estas y otras medidas de capacidad de datos se miden
en KB.
- El valor: el campo final especifica el valor que se aplica al límite.
Como ejemplo, consideremos un sistema en el que determinados usuarios deberían poder
acceder y realizar un número limitado de acciones, pero no permanecer indefinidamente y
consumir grandes cantidades de tiempo de CPU. Podríamos utilizar una configuración
como la siguiente:
@limited hard cpu 2
Con esta configuración aplicamos un límite de CPU de dos minutos al grupo limited, sus
miembros podrán acceder y ejecutar programas, pero si uno de estos programas consume
más de dos minutos de tiempo de CPU, se cerrará.
El tiempo de CPU y el tiempo total de acceso al sistema son dos cosas completamente
diferentes. El tiempo de CPU se calcula en función a la cantidad de tiempo que la CPU está
procesando activamente los datos del usuario. El tiempo de inactividad (por ejemplo,
cuando la consola del usuario está activa pero no hay en ejecución tareas que hagan uso
intenso de la CPU) no cuenta. En consecuencia, un usuario puede acceder y permanecer
en el sistema durante horas con un límite estricto de tiempo de CPU muy bajo. Este límite
está pensado para evitar problemas causados por los usuarios que ejecutan programas que
hacen uso constante de la CPU en sistemas que no se deberían utilizar para tales fines.
Otra manera de definir los límites es a través del comando ulimit, que es nativo de bash,
por lo que sólo afectará a bash y a los programas iniciados desde éste. Su sintaxis es la
siguiente:
ulimit [opciones [limite]]
Las opciones definen lo que se está limitando:
Límites de los ficheros del núcleo: -c limita el tamaño de los volcados del núcleo, que son
ficheros creados cuando se depuran determinados tipos de fallo de programa.
Límites de fichero: -f limita el tamaño de los ficheros que puede crear la consola y -n limita
el número de los descriptores de fichero abiertos (la mayoría de sistemas no respetan los
límites de -n).
Límites de proceso: -u limita el número de procesos que puede ejecutar un usuario y -t limita
el tiempo total de CPU en segundos.
Límites de memoria: -v define la cantidad total de memoria virtual disponible para la consola,
-s define el tamaño máximo de la pila, -n define el tamaño máximo del conjunto residente,
-d limita el tamaño del conjunto de datos de los programas y -l define el tamaño máximo
que se puede bloquear en la memoria.
Límites estrictos y flexibles: -H y -S modifican las opciones haciendo que se definan como
límites estrictos o flexibles. Los límites estrictos no se pueden incrementar, pero los flexibles
sí. Si no indicamos ninguna opción, ulimit define ambos límites con el valor especificado.
Parámetros actuales: -a hace que ulimit informe sobre sus parámetros actuales.
El límite suele ser un valor numérico asociado al límite. ulimit suele aparecer en los scripts
de inicio de usuario de bash o en los del sistema, generalmente como ulimit -c 0, para evitar
la creación de ficheros del núcleo que pueden crear desorden en el sistema de ficheros. Si
los usuarios desarrollan software, es aconsejable no definir este límite, o, al menos, hacerlo
como límite flexible (como ulimit -Sc 0) para que los usuarios puedan invalidarlo cuando sea
necesario. Como ulimit es un comando nativo de bash, su utilidad como herramienta de
seguridad del sistema es limitada: los usuarios tienen acceso a herramientas GUI de
acceso o pueden acceder al sistema saltándose bash de algún modo (por ejemplo,
mediante ssh). Por consiguiente, deberíamos considerar a ulimit como un medio para
prevenir problemas debidos a un abuso accidental, más que intencionado, del sistema.
El fichero /etc/nologin aplica un concepto de seguridad particularmente radical. Si se
encuentra presente, sólo root puede acceder al ordenador. En muchos aspectos, esto
equivale a definir un valor cero para los límites críticos del sistema para todos los usuarios.
Este fichero, probablemente, sea más útil en sistemas de servidores dedicados que no
poseen usuarios de consola locales o remotos.
Localizar ficheros SUID/SGID
Los bits SUID y SGID son indicadores especiales que se pueden aplicar a los ficheros de
programa ejecutables, haciendo que Linux trate el programa como si lo ejecutara el
propietario del fichero (SUID) o el grupo del fichero (SGID) en lugar de la persona que
realmente lo ejecuta. Por ejemplo, si el bit SUID se define en un programa y su propietario
es bruce, cuando cualquiera ejecute este programa, esa persona podrá acceder a todos los
ficheros cuyo propietario sea bruce.
Los bits SUID y SGID se asocian frecuentemente con la cuenta root para permitir realizar
tareas que requieran un privilegio especial. Por ejemplo, el programa passwd tiene SUID
de root, ya que sólo este usuario puede modificar la base de datos de contraseñas de Linux.
Si un usuario normal quiere cambiar una contraseña, debe existir un mecanismo para
ejecutar un proceso como root; este mecanismo, en el caso de passwd, es el bit SUID.
El problema de todo esto es que estos bits pueden suponer un riesgo para la seguridad.
Por ejemplo, supongamos que tengamos definido el bit SUID del programa rm. El
propietario suele ser root, por lo que definir el bit SUID en rm implica que cualquier usuario
podría borrar cualquier fichero del sistema. Ninguna distribución define este bit para rm por
defecto, debemos tener cuidado para no definirlo de manera inadecuada, algo que puede
ocurrir por accidente, por malicia o debido a algún ligero error de configuración del
mantenedor de la distribución. Incluso en el caso de que los bits de SUID y de SGID se
definan correctamente, un bug del programa puede volverse más serio debido a que el bug
se ejecute como root, si permite a los usuarios escribir ficheros, por ejemplo, cualquiera
podría aprovecharse de ello para sobreescribir ficheros críticos del sistema.
Deberíamos revisar periódicamente el sistema para localizar todos los programas SUID o
SGID y, si fuera preciso,cambiar su configuración. Para ello utilizaremos el comando find
junto con la opción -perm modo, que busca ficheros que tengan el modo de permiso
especificado. Para buscar ficheros SUID y SGID deberíamos pasarle el modo +6000. La
representación simbólica de los bits SUID y SGID es 6000 y el signo de la suma (+) le dice
a find que localice cualquier fichero que tenga definido cualquiera de los bits especificados
(podríamos buscar sólo los ficheros SUID pasándole +4000 o sólo por SGID pasándole
+2000). Puede que también necesitemos pasarle -type f, que restringe la búsqueda a los
ficheros normales, ya que los directorios utilizan los bits SUID y SGID de manera diferente.
Por tanto, para buscar en todo el ordenador programas SUID y SGID escribiremos lo
siguiente:
# find / -perm +6000 -type f
El resultado es una lista de ficheros, uno por línea, que tienen definidos los bits SUID o
SGID. Probablemente, en esta lista aparecerán los programas su, ping, mount, passwd,
umount y sudo, todos ellos necesitan estar configurados de esta manera. La mayoría de
sistemas poseen programas SUID y SGID adicionales. Si tenemos dudas de si un programa
realmente necesita este status, deberíamos investigarlo verificando la integridad del
paquete o buscando en internet el nombre del programa y SUID o SGID. También podemos
probar a cambiar el estado SUID del programa utilizando chmod y ver si éste continúa
funcionando correctamente cuando lo ejecuta un usuario normal.
Los programas que tienen el SUID o SGID de root pero no deberían tenerlo, pueden ser
una señal de que el sistema está comprometido. Por consiguiente, si localizamos tales
programas, deberíamos investigar la integridad global del sistema. Por otra parte, si el
mantenedor de la distribución define incesantemente el bit SUID o SGID, esto no debe ser
motivo de preocupación, aunque es recomendable corregir este detalle. Si realizamos
accidentalmente una configuración errónea, no causará un trastorno masivo en el sistema,
pero tendremos que investigar para aclarar si tal cambio es accidental o es síntoma de un
problema más grave. Configurar la seguridad del equipo
3.5.3 Asegurar los datos mediante encriptación
Configurar ssh
Antiguamente, telnet era el sistema de acceso remoto preferido en modo texto de sistemas
GNU/Linux y UNIX, pero presentaba serias carencias de seguridad, por lo que, durante los
siguientes años, fue cediendo terreno a ssh, que es la herramienta preferida actualmente
para el acceso remoto, pues, además, gestiona tareas de transferencia similares a las de
ftp. Saber cómo configurar ssh es muy útil, sobre todo en lo que se refiere a sus
fundamentos y su fichero de configuración de en GNU/Linux. ssh es lo suficientemente
complejo como para no poder abarcar más que los puntos básicos en este capítulo.
Podemos obtener más detalles en la documentación de openssh o en algún libro sobre la
materia.
Fundamentos de ssh
Linux permite el acceso remoto a través de varios servidores como telnet, VNC e incluso X.
Lamentablemente la mayoría de estos métodos transfieren los datos sin cifrar, lo que
implica que cualquiera puede monitorizar el tráfico de red y rastrear datos sensibles o,
incluso, contraseñas. VNC y otros protocolos cifran las contraseñas, pero no el resto de los
datos. Esta limitación supone un serio riesgo en la utilización de estas herramientas, al fin
y al cabo, si utilizar un protocolo de acceso remoto implica entregar datos sensibles o
comprometer todo el equipo, la utilidad del protocolo queda en entredicho.
Las herramientas de acceso remoto no cifrado son muy peligrosas cuando se trabaja como
root, se accede directamente como root o a través de un usuario normal que emplea su,
sudo u otra herramienta para obtener privilegios de root.
ssh fue diseñado para cerrar esta brecha de seguridad empleando técnicas de cifrado fuerte
en todas las partes de la conexión de red, ssh cifra el intercambio de contraseñas y todas
las transferencias de datos subsiguientes, lo que lo convierte en un protocolo para acceso
remoto mucho más seguro. Además del cifrado, proporciona funcionalidades para transferir
ficheros y la posibilidad de hacer de túnel para otros protocolos de red y permitir, así, que
protocolos de red no cifrados transporten sus datos aprovechando las ventajas de cifrado
de ssh. Esta característica se suele emplear junto a X, posibilitando un acceso por GUI
remoto y cifrado.
Las ventajas de ssh tienen algunas desventajas, la principal es que el cifrado y descifrado
consume tiempo de CPU, lo que ralentiza las conexiones y puede degradar el rendimiento
global del sistema. No obstante, se trata de un efecto modesto, sobre todo en las
conexiones en modo “texto plano”. Si lo utilizamos como túnel para un protocolo que
transfiere muchos datos, puede que observemos una gran repercusión en el rendimiento.
Incluso en este caso, vale la pena esta reducción de velocidad si se tiene en cuenta la
mejora de la seguridad.
Hay muchos servidores ssh disponibles, aunque el más popular es openssh
(www.openssh.org). Fue una de las primeras implementaciones de código libre del
protocolo ssh, desarrollado comercialmente por la SSH Comunications Security
(http://www.ssh.com), cuyo servidor se vende ahora bajo el nombre de SSH Tectia. Estos
y otros productos ssh pueden operar entre sí, asumiendo que todos ellos estén
configurados para admitir, al menos, un nivel de protocolo ssh, pueden ser 1.3, 1.5 y 2.0,
siendo 2.0 el preferido a causa de las vulnerabilidades que se conocen de las versiones
anteriores.
openssh está estrechamente relacionado con el SO OpenBSD, por lo que su sitio web tiene
cierta predilección por OpenBSD. Si visitamos el sitio, haremos click en el enlace Linux para
encontrar el código fuente y binarios compatibles con Linux de openssh. Hoy en día, la
mayoría de las distribuciones lo incluyen de serie.
openssh se puede iniciar a través de un súper servidor (inetd o xinetd) o un script de inicio
SysV. Este último método es el preferido, ya que el servidor suele realizar tareas que utilizan
mucho la CPU al iniciarse. Si lo iniciamos desde un súper servidor, openssh puede
ralentizar las respuestas a las peticiones de conexión, sobre todo en sistemas con CPUs
pobres. Las distribuciones actuales suelen incluir scripts de inicio SysV en sus paquetes
ssh.
Si hacemos cambios en la configuración de ssh, puede que necesitemos pasarle las
opciones reload o restart al script de inicio, como por ejemplo /etc/init.d/sshd reload.
Independientemente de cómo se inicie, el nombre del servidor binario openssh es sshd que
es el mismo que el nombre binario de SSH Tectia.
Definir las opciones de SSH de nuestro sistema
ssh funciona razonablemente bien nada mñas instalarlo, por lo que seguramente no
necesitemos hacer cambios en su configuración. Si necesitamos hacer cambios, se
gestionan en su mayor parte a través del fichero de configuración de ssh que está en
/etc/ssh/sshd_config. También podemos editar algunos ficheros adicionales para limitar el
acceso o cambiar el modo en que ssh gestiona el proceso de acceso.
Configurar las funcionalidades básicas de ssh
El fichero /etc/ssh/sshd_config se compone principalmente de líneas de opción que
adoptan la siguiente forma:
Opción valor
Advertencia:
No debemos confundir el fichero sshd_config con el fichero ssh_config. El primero
controla el servidor openssh mientras que el segundo controla el programa cliente
de ssh.
Además de las líneas de configuración, el fichero contiene comentarios con almohadillas.
La mayoría de ficheros de configuración de ejemplo incluyen un gran número de opciones
que vienen comentadas y que especifican valores por defecto, por lo que, si las des
comentamos sin cambiar los valores, el efecto será nulo. Para cambiar una opción
eliminaremos la marca de comentario (#) y cambiaremos el valor. Los valores por defecto
suelen ser apropiados para la mayoría de los sistemas. La siguiente lista muestra algunas
opciones que recomendamos revisar y que podemos cambiar:
- Protocol: en esta opción indicamos los niveles de protocolo de ssh. Los valores son 1
y 2. Podemos configurar openssh para que admita ambos protocolos separándolos por
una coma. El nivel de protocolo 1 ha sido comprometido, por lo que la configuración
más segura es definir protocol 2, aunque esto limita la capacidad del servidor para
comunicarse con los clientes.
- PermitRootLogin: esta opción se define como yes por defecto, lo que permite que
openssh acepte accesos como root. Es más seguro que una configuración similar bajo
telnet. Si queremos aumentar la seguridad, definiremos este valor como no, lo que hará
que cualquiera que desee trabajar en remoto como root, tendrá que acceder primero
como un usuario normal; esto significa que si un intruso ha conseguido la contraseña
de root, también necesitará un usuario y su contraseña.
- X11Forwarding: esta opción especifica si están activas las funcionalidades de túnel
para X. Si definimos esta opción como yes, los usuarios remotos podrán ejecutar
programas X a través de ssh, lo que degrada ligeramente la seguridad de X en el
cliente, dependiendo de algunas otras opciones, de ahí que el valor por defecto sea no.
Podemos encontrar información sobre las opciones en la página MAN de sshd_config. Una
vez realizados los cambios en la configuración de ssh no debemos olvidarnos de reiniciarlo
utilizando el script de inicio SysV.
Claves de ssh
Parte de la seguridad de ssh depende de las claves de cifrado. Cada sistema servidor y
cada usuario tiene un número (o clave) único a efectos de identificación. ssh utiliza un
sistema de seguridad que emplea dos claves: una pública y otra privada, las dos están
vinculas matemáticamente de manera que los datos cifrados con una clave pública concreta
sólo se puedan descifrar con la clave privada coincidente. Cuando se establece una
conexión, cada lado envía su clave pública al otro, después, cada lado cifra la información
con la clave pública del otro lado. Esto asegura que tan sólo el destinatario deseado pueda
descifrar los datos; es el primer paso del proceso aunque es fundamental. Los clientes ssh
suelen conservar las claves públicas de los servidores con los que contactan, lo que permite
detectar cambios en las claves públicas que puedan significar una señal de falsificación.
La mayoría de scripts de inicio SysV del servidor openssh suelen buscar las claves públicas
y privadas almacenadas; si no las encuentran, las generan. En total, hacen falta de 4 a 6
claves: las claves pública y privada para las dos o tres herramientas de cifrado que admite
ssh. Las claves se suelen almacenar en /etc/ssh y se llaman ssh_host_rsa_key y
ssh_host_dsa_key en el caso de las privadas, añadiendo la extensión .pub al nombre del
fichero en el caso de las públicas. Si nuestro sistema no dispone de estas claves y no
podemos poner en funcionamiento el servidor ssh, podemos generarlas con el comando
ssh-keygen:

# ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C ” -N “

# ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C ” -N “
# ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C ” -N “
Cada uno de estos comandos genera una clave privada (el parámetro -f le da nombre) y
una clave pública (con el mismo nombre pero añadiendole .pub).
No debemos ejecutar estos comandos ssh-keygen si ya existen los ficheros clave ssh, ya
que la sustitución de ficheros en uso hará que los clientes ya conectados al servidor,
posiblemente, rechacen la conexión.
Advertencia:
Debemos asegurarnos de que las claves privadas están adecuadamente protegidas,
ya que si las obtiene un intruso, puede suplantar a nuestro sistema. Estos ficheros
deberían tener permisos 0600 (-rw——-) y a root como propietario. Los ficheros de
clave pública (con extensiones .pub) deberían poder ser leídos por todos los
usuarios.
Cuando configuremos un sistema cliente es recomendable considerar la creación de una
caché global de claves de host, ya que el programa ssh registra las claves de host para
cada usuario individual (~/.ssh/known_hosts). Cuando configuremos el cliente podemos
rellenar el fichero ssh_known_hosts global, que se suele guardar en /etc o /etc/ssh. De esta
manera nos aseguramos de que la lista de claves públicas sea tan precisa como las fuentes
que empleemos para rellenar el fichero global. Eliminaremos los mensajes de confirmación
cuando los usuarios se conecten a los hosts cuyas claves hemos seleccionado para incluir
en el fichero global.
¿Cómo se crea este fichero? Una manera sencilla es copiando el fichero desde una cuenta
de usuario que se haya utilizado para conectarse a los servidores que queremos incluir. Por
ejemplo, cp /home/ecernan/.ssh/known_hostst /etc/ssh/ssh_known_hosts debe ser
revisado antes de copiarlo. Consta de una línea por cada host. Cada línea empieza por un
nombre de host, una IP o ambos y continúa con el tipo de clave y la clave. Se puede ignorar
la mayor parte de esta información, pero debemos prestar atención a los nombres de host
y las direcciones IP. Debemos asegurarnos de que la lista incluya a todos los servidores
ssh que queramos utilizar y de que excluya a servidores inapropiados o innecesarios. Para
añadir entradas, utilizaremos la cuenta cuyo fichero estamos copiando y nos conectaremos
al sistema que queremos añadir, ssh mostrará un aviso de que nos estamos conectando a
un sistema desconocido, lo confirmaremos y recargaremos el fichero para comprobar la
nueva entrada.
openssh 4.0 y posteriores realizan un hash de los nombres de host del fichero known_hosts.
Cuando esta funcionalidad está activa se aplica un hash al nombre del host y se guarda en
este formato, la idea es que pueda seguir autenticando los servidores ssh a los que se
conectan, puesto que el hash del nombre del host coincide con el hash del nombre de host
almacenado, pero si un intruso roba el fichero known_hosts, no podrá determinar las
identidades de los ordenadores a los que nos hemos conectado.
Controlar el acceso por ssh
Podemos limitar el acceso a nuestro servidor ssh de varias maneras. El método más obvio
y básico es a través de contraseñas. El método de autenticación más usual en ssh es
emplear un nombre de usuario y una contraseña. El cliente ssh envía el nombre de usuario
local automáticamente como parte de la línea de comandos, por lo que no se nos pedirá el
nombre de usuario cuando accedamos a través de ssh. En caso de que el nombre del
usuario en la máquina remota no sea el mismo que el usuario en la máquina local,
deberemos especificar el usuario al hacer la conexión por ssh.
A parte de la autenticación de la contraseña. ssh incluye otros tipos de limitaciones:
- TCP Wrappers: si ejecutamos ssh desde un súper servidor o si el servidor se compiló
con soporte para TCPWrappers, podemos utilizar los ficheros /etc/hosts.allow y
/etc/hosts.denypara limitar el acceso por dirección IP. Debemos tener en cuenta que si
iniciamos ssh a través de un script de inicio SysV, sólo funcionará si el servidor se
compiló con dicho soporte, que puede estar o no presente en el paquete ssh de nuestra
distribución.
- Cortafuegos: ssh utiliza el puerto tcp 22. Técnicamente, esta no es una característica
de ssh, pero resulta verdaderamente útil para proteger el servidor.
- /etc/nologin: cuando existe el fichero, ssh lo tiene en cuenta. La presencia de este
fichero implica que sólo root puede acceder. El contenido del fichero se suele mostrar
como un mensaje de error, sin embargo, ssh no hace esto.
Copiar ficheros a través de ssh
La mayoría de usuarios utilizan el cliente ssh, que proporciona un acceso remoto, por
ejemplo, ssh otrosistema nos permite acceder a otrosistema utilizando el nombre de usuario
que emplea el sistema cliente o podemos añadir un nombre de usuario, como en ssh
usuario@otrosistema para acceder como usuario.
ssh incluye un comando para copiar ficheros: scp, que funciona de un modo similar al
comando cp que copia comandos locales, debemos especificar el ordenador de destino y
opcionalmente, el nombre de usuario justo antes del nombre del fichero de destino. Por
ejemplo, para copiar el fichero masterpiece.c en la cuenta lisa de leonardo.example.com,
escribiremos:
$ scp masterpiece.c lisa@leonardo.example.com:
Los dos puntos finales ( : ) son extremadamente importantes, ya que si se omiten scp
funcionara como cp y acabaremos con un fichero llamado lisa@leonardo.example.com. Si
queremos renombrar el fichero, podemos hacerlo incluyendo el nuevo nombre a
continuación de los dos puntos (:).
Configurar accesos sin contraseña
Si utilizamos ssh o herramientas automatizadas frecuentemente, probablemente estemos
cansados de escribir las contraseñas en cada conexión. Hay un medio para evitar este
requisito: podemos configurar el cliente ssh con unas claves y darle la clave pública al
ordenador servidor. Gracias a esto el cliente ssh podrá identificarse a sí mismo, obviando
la necesidad de escribir una contraseña.
Advertencia:
Configurar ssh para trabajar sin contraseñas es cómodo, pero debilita la seguridad
del sistema. Si alguien que no es de confianza consigue acceder a nuestra cuenta
en el sistema cliente ssh, esta persona podrá acceder al servidor ssh. Por tanto,
sólo deberíamos crear accesos sin contraseña desde clientes muy bien protegidos.
Configurar el acceso de la cuenta root de esta manera es particularmente
arriesgado.
Para configurar ssh de manera que no solicite una contraseña, seguiremos los siguientes
pasos:
Accederemos al cliente ssh como el usuario que accederá remotamente.
Gereraremos una clave sshversión 2 de la siguiente manera:
$ ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -c ” -N “
El paso 2 genera dos ficheros: id_rsa e id_rsa.pub. Transferiremos el segundo fichero al
servidor ssh. Copiaremos el fichero con un nombre temporal, como temp.rsa.
Seguidamente accederemos al servidor ssh, si lo hacemos mediante ssh, tendremos que
escribir la clave.
Añadiremos el contenido del fichero que acabamos de transferir al final del fichero
~/.ssh/authorized_keys (este fichero puede tener otros nombres, por lo que tendremos que
comprobar que está presente). Para añadir el contenido escribiremos cat ~/temp.rsa >>
~/.ssh/authorized_keys, en caso de que guardemos el fichero original como ~/temp.rsa.
Si salimos del servidor e intentamos acceder de nuevo mediante ssh, no se nos solicitará
contraseña, ya que los dos ordenadores gestionan automáticamente la autenticación. Si
esto no funciona, es probable que el fichero ~/.ssh/autorized_keys necesite otro nombre.
También es aconsejable comprobar que el fichero incluya una línea que coincida con el
contenido del fichero original de clave pública del cliente. Algunos clientes pueden requerir
la especificación de utilización de la versión 2 del protocolo ssh de la siguiente manera:
$ ssh -2 servidor
Utilizar ssh-agent
ssh-agent es otra opción para la autenticación ssh. Este programa solicita una contraseña
para iniciar las conexiones, por lo que resulta más seguro que configurar accesos sin
contraseñas; sin embargo, ssh-agent recuerda las contraseñas, por lo que sólo
necesitaremos escribirla una vez por cada sesión local. Para utilizar ssh-agent, seguiremos
estos pasos:
Seguiremos el procedimiento para activar los accesos sin contraseña que describimos
anteriormente, pero con un cambio: omitiendo la opción -N del comando ssh-agent. En este
paso se le solicitará una frase de contraseña, que será nuestra clave para todos los accesos
ssh gestionados por ssh-agent.
En el cliente ssh, escribiremos ssh-agent /bin/bash. Esto iniciará ssh-agent que, a su vez,
iniciará bash. Utilizaremos esta sesión de bash para los accesos ssh subsiguientes.
En la nueva consola, escribiremos ssh-add ~/.ssh/id_rsa, lo que añadirá la clave rsa al
conjunto gestionado por ssh-agent. En este momento, se nos pedirá que escribamos
nuestra frase de contraseña.
A partir de este punto, cuando utilicemos ssh para conectarnos a un sistema remoto al que
hayamos dado nuestra clave pública, no tendremos que escribir nuestra contraseña. No
obstante, tendremos que repetir los pasos dos y tres cada vez que salgamos, ya que esto
sólo se aplica a la consola iniciada en el paso 2 o a las consolas que iniciemos desde ésta.
Si utlizamos este recurso con frecuencia, podemos insertar ssh-agent en nuestro
procedimiento de acceso normal. Por ejemplo, podemos editar /etc/passwd para utilizar
ssh-agent /bin/bash como consola por defecto. En un acceso GUI podemos renombrar el
script de acceso GUI normal (por ejemplo, cambiar ~/.xsession por ~/.xsession-nossh) y
crear un nuevo script de acceso GUI que llame a ssh-agent con el script renombrado como
eparámetro. Cada acción insertará ssh-agen en la raíz de nuestro árbol de procesos de
usuario para que todas las llamadas a ssh utilicen ssh-agent.
Utilizar scripts de acceso ssh
La sesiones de acceso ssh en modo texto suelen ejecutar la consola configurada para el
usuario, que ejecuta los scripts de acceso definidos para la consola. El servidor openssh
también incluye su propio script de acceso, sshrc, que suele guardarse en /etc o /etc/bash.
openssh ejecuta este script utilizando /bin/sh que, normalmente, es un enlace simbólico a
bash, por lo que se puede tratar como un script de bash ordinario.
Configurar túneles para puertos ssh
ssh tiene la capacidad de extender sus capacidades de cifrado a otros protocolos, lo que
requiere una configuración adicional, esto es lo que se denomina tunneling. Anteriormente
describimos un tipo especial de túnel ssh vinculado a X.
La siguiente figura ilustra el concepto de túnel ssh. El ordenador servidor ejecuta dos
programas de servidor: un servidor para el protocolo que utiliza el túnel (imap en este
ejemplo) y un servidor ssh. El ordenador cliente ejecuta dos clientes: uno para el protocolo
que utiliza el túnel y otro para ssh. El cliente ssh también escucha las conexiones del
protocolo del túnel, por lo que hace tanto de cliente como de servidor. Cuando el cliente ssh
recibe una conexión del cliente del protocolo del túnel, el resultado es que ésta se cifra
utilizando ssh, se lleva por el túnel hasta el servidor ssh y se dirige al servidor de destino.
En consecuencia, los datos pasan por la red en forma cifrada, aunque el protocolo objetivo
no incluya cifrado.
Por defecto el servidor ssh permite crear túneles, pero, para asegurarnos, comprobaremos
el fichero /etc/ssh/sshd_config y comprobaremos que la siguiente opción está
descomentada:
AllowTcpForwarding no
Tendremos que cambiar no por yes; si ya está definida como yes, no deberemos cambiar
nada en la configuración de ssh. En el lado del cliente estableceremos una conexión ssh
especial, utilizando un cliente ssh normal con varios parametros:
# ssh -N -f -L 142:mail.luna.edu:143 benf@mail.luna.edu
Las opciones -N y -f le indican a ssh que no ejecute un comando remoto y que se ejecute
en segundo plano tras solicitar una contraseña, son opciones necesarias para crear el túnel.
-L especifica el puerto local en el que escuchar, el ordenador remoto al que conectarse y el
puerto de dicho ordenador al que conectarse. En este ejemplo se escucha en el puerto local
142 y se conecta al puerto 143 de mail.luna.edu. El parámetro final (benf@mail.luna.edu)
indica el nombre de usuario remoto y el ordenador hacia el que se dirige el túnel. Hay que
tener en cuenta que este ordenador no tiene por qué ser el mismo que el sistema
especificado a través de -L.
Nota: si queremos que ssh escuche en un puerto inferior a 1024 (puerto con
privilegios) tendremos que ejecutar el programa como root. Si permitimos la escucha
en un puerto no privilegiado podremos ejecutar ssh como usuario normal.
Una vez establecido el túnel, utilizaremos el programa cliente (en este caso imap) para
conectarnos al puerto local especificado por el parámetro -L (142 en este ejemplo). Por
ejemplo, para redirigir el tráfico de imap debemos configurar un cliente de correo en el
cliente para obtener el correo imap del puerto 142 para localhost. Cuando el cliente de
correo haga esto, ssh entrará en acción y reenviará el trafico al servidor ssh, que pasará la
información por el puerto 143 local y ejecutará el servidor imap real. Todo esto queda oculto
para el programa lector de correo, para el el correo se obtiene de un servidor imap local.
Aspectos de la seguridad ssh
ssh está pensado para resolver problemas de seguridad en vez de crearlos, su uso supera
al de telnet para los accesos remotos y puede asumir funciones de tipo ftp y hacer de túnel
para otros protocolos. Por tanto, ssh es un extra para la seguridad. Sin embargo, como
todos los servidores, puede suponer una responsabilidad en lo referente a seguridad al
ejecutarlo de manera innecesaria o inadecuada. Lo ideal es configurar ssh para que sólo
acepte conexiones del nivel 2 del protocolo y rechace accesos directos como root; también
desactivaremos el redireccionamiento de X sino lo necesitamos. En la medida de lo posible,
utilizaremos TCPWrappers o un cortafuegos para limitar las máquinas que pueden conectar
con el servidor ssh. Debemos mantenerlo actualizado, ya que los bug pueden causar
problemas.
Debemos considerar si necesitamos un servidor de acceso remoto en modo texto; resulta
muy cómodo, lo suficiente como para justificar el modesto riesgo que implica. No obstante,
en sistemas de muy alta seguridad, la seguridad puede mejorarse si utilizamos el ordenador
exclusivamente desde la consola.
Un problema de seguridad de ssh poco habitual son sus claves, ya que los ficheros de clave
privada son extremadamente sensibles y se deben proteger de los curiosos, ademas de las
copias de seguridad de estos ficheros. No debemos dejar una cinta de copia del sistema en
un sitio en el que se pueda robar con facilidad.
Utilizar GPG
ssh está diseñado para cifrar sesiones de acceso interactivo y transferencia de archivos. A
veces necesitamos otro tipo de cifrado que proteja los mensajes de correo enviados a otra
persona utilizando otros medios. Los correos no son una herramienta segura para transferir
información, ya que la mayoría de los mensajes pasan a través de varios servidores de
correo y routers. Si cualquiera de estos puntos está comprometido, se podría rastrear el
tráfico del correo y extraer información sensible. Cifrando el correo mantendremos la
privacidad de estos detalles.
La herramienta habitual para cifrar correos es gnu privacy guard (gpg,
http://www.gnupg.org). Este paquete es una reinplementación bajo código libre de la
herramienta propietaria pgp. Además de cifrar mensajes completos, gpg permite firmar
digitalmente los mensajes. De esta manera los destinatarios que carecen del software gpg
o las claves apropiadas podrán leer los mensajes, pero no verificar que su contenido no ha
sido alterado.
Generar e importar claves
Lo primero que debemos hacer es instalar el software; probablemente, la distribución ya lo
incluya como un paquete estándar, por lo que podremos instalarlo con nuestro gestor de
paquetes. Después, debemos generar las claves, que son similares en concepto a las
claves ssh: necesitaremos una clave privada (clave secreta) y una pública. La clave privada
se mantiene en privado y la pública está disponible públicamente.
La clave privada se utiliza para firmar los mensajes y la pública la utilizan los lectores para
realizar las verificaciones. Otra opción es cifrar un mensaje con la clave pública de otro
usuario, con lo que sólo se podrá descifrar con la clave privada de dicho usuario.
Para poder generar las claves, se utiliza el programa gpg y su opción –gen-key:
$ gpg –gen-key
El programa hará una serie de preguntas, la mayoría de ellas se pueden responder con los
valores por defecto, tendremos que escribir nuestro nombre completo y la dirección de
correo. Las claves se guardan en ~/.gnupg, una vez generadas, podremos exportar la clave
pública:
$ gpg –export nombre > gpg.pub
Este comando guarda la clave pública asociada con nombre en el fichero gpg.pub; podemos
usar nuestra dirección de correo como nombre y, si creamos claves públicas adicionales o
añadimos claves públicas de otros, podemos especificar su nombre al exportarlas. También
podemos hacer que nuestra clave esté disponible para otras personas para que puedan
cifrar los mensajes de correo que nos mandan o verificar los que nosotros firmamos. Si
añadimos la opción –armor se genera una salida ASCII, que es preferible si tenemos
pensado mandar por correo la clave pública. Podemos colgar el fichero en nuestro sitio
web, transferirlo como un adjunto de un correo o distribuirlo de varias maneras.
Para cifrar el correo que enviemos debemos obtener las claves públicas de los
destinatarios. Cuando lo hayamos hecho podremos añadir nuestras claves al deposito de
claves o keyring, que es el conjunto de claves que mantiene gpg:
$ gpg –import filename
Este comando añade filename a nuestro conjunto de claves públicas que pertenecen a otras
personas.
Nota: aunque las claves públicas son por definición públicas, al utilizarlas hay que tener en
cuenta algunos detalles relacionados con la seguridad. En concreto, debemos asegurarnos
de que utilizamos una clave pública legítima. En teoría, alguien mal intencionado podría
publicar una clave pública falsa para obtener información sensible o falsificar un correo. Por
tanto, debemos utilizar el método de comunicación más seguro para distribuir nuestra clave
pública y para recibir claves públicas de otros.
Cuando hayamos creado nuestra propia clave e importado claves de otros, podremos ver
qué claves hay disponibles de la siguiente manera:
$ gpg –list-keys
/home/gjones/.gnupg/pubring.gpg
———————————————-
pub 1024D/190EDB2E 2008-09-05
uid George A. Jones <gjones@example.com>
sub 2048g/0D657AC8 2008-09-05

pub 1024D/A8B2061A 2008-09-05

uid Jennie Martin <jennie@luna.edu>
sub 2048g/4F33EF6B 2008-09-05
Las líneas uid contienen identificadores que se utilizan cuando se cifran o descifran los
datos, por lo que debemos prestar una especial atención a esta información.
Cifrar y descifrar datos
Para cifrar datos utilizaremos gpg con –out y –encrypt y opcionalmente –recipient y –armor:
$ gpg –out fichero-cifrado –recipient uid –armor –encrypt fichero-original
Podemos utilizar la uid de una salida gpg –list-keys, sólo la parte de la dirección del correo
como uid en este comando. El resultado será un nuevo archivo fichero-cifrado, que contiene
una versión cifrada del archivo fichero-original. Si omitimos la opción –armor, el archivo
resultante será un fichero binario; si queremos enviarlo en un correo, tendremos que hacerlo
como adjunto o codificarlo de algún otro modo para enviarlo por el sistema de correo de
tipo texto. –armor produce una salida en ASCII, con lo que podremos cortar y pegar el
mensaje cifrado en un correo o enviarlo como adjunto.
Si recibimos un mensaje o fichero cifrado con nuestra clave pública podemos revertir el
cifrado utilizando la opción –decrypt:
$ gpg –out fichero-descifrado –decrypt fichero-cifrado
Se nos pedirá que introduzcamos nuestra frase de contraseña y obtendremos una versión
descifrada del fichero original.
En la práctica, gpg puede ser incluso más fácil de utilizar de lo que se puede pensar a raíz
de esta descripción. Se utiliza principalmente para proteger y verificar correos electrónicos,
por lo que la mayoría de clientes de correo de GNU/Linux, proporcionan interfaces gpg.
Estas opciones llaman a gpg con las opciones apropiadas para cifrar, firmar o descifrar
mensajes. Los detalles varían de un cliente de correo a otro.
Firmar mensajes y verificar firmas
gpg se utiliza para firmar mensajes de modo que los destinatarios sepan de quien proceden.
Para ello se utilizan las opciones –sing o –clearsing:
$ gpg –clearsing fichero-original
La opción –sing crea un nuevo fichero con el mismo nombre que el original, pero añadiendo
la extensión -gpg. Este fichero se cifra utilizando nuestra clave privada, por lo que sólo se
podrá descifrar con nuestra clave pública, lo que significa que cualquiera que conozca
nuestra clave pública podrá leer el mensaje y todos sabrán que de dónde procede. La
opción –clearsing funciona de manera similar, pero deja el mensaje de texto sin cifrar y sólo
añade una firma cifrada que se puede verificar utilizando nuestra clave pública. –clearsing
crea un fichero con un nombre que acaba en .asc. Si recibimos un mensaje firmado,
podemos verificar la firma utilizando la opción –verify:
$ gpg –verify fichero-recibido
Si cualquiera de la claves de nuestro depósito de claves puede decodificar o verificar la
firma, gpg mostrará un mensaje Good Signature (firma correcta). Para leer un mensaje
cifrado mediante la opción –sing, debemos descifrarlo mediante la opción –decrypt que
vimos anteriormente.