PDF de programación - Configuracion de Servicios de Red en GNU/Linux

Configuración de Servicios de Red en

GNU/Linux

Margarita Manterola y Maximiliano Curia

Versión Beta - Octubre 2003

Índice

1. X

1.1. Ejecutando aplicaciones en otras computadoras
. . . . . . . .
1.2. Utilizando más entornos, con Xdmcp . . . . . . . . . . . . . .

2. Servidor de SSH

2.1. Cliente de SSH - Utilización de claves . . . . . . . . . . . . . .

3
3
4

4
6

3. inetd

3.1. Ejemplo: agregando servicios con inetd . . . . . . . . . . . . .
3.2. tcp-wrappers
. . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Ejemplo: agregando control de acceso . . . . . . . . . . . . . .
3.4. Servicios Adicionales . . . . . . . . . . . . . . . . . . . . . . .
talk . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
8
8
9
9
3.4.1.
9
3.4.2. finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
telnetd . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.3.
tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.4.
3.4.5.
ident . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Apache

11
4.1. Configuración básica . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Directorios public html . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Algunas configuraciones generales . . . . . . . . . . . . . . . . 12
4.4. Dominios virtuales
. . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Tipos mime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Restricción de acceso . . . . . . . . . . . . . . . . . . . . . . . 16
4.7. Cambios dentro de los directorios . . . . . . . . . . . . . . . . 16

1

5. DHCPD

6. BIND

7. NFS

18

20

23

8. NIS

23
8.1. Configuraciones generales . . . . . . . . . . . . . . . . . . . . . 23

9. SAMBA

24
9.1.
Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Conceptos Generales . . . . . . . . . . . . . . . . . . . . . . . 25
9.3. Montar un sistema de archivos con smbfs . . . . . . . . . . . . 26
9.3.1. Configuración en el fstab . . . . . . . . . . . . . . . . . 26
9.4. Configuración del servidor . . . . . . . . . . . . . . . . . . . . 26
9.4.1. Configuración básica . . . . . . . . . . . . . . . . . . . 26
9.4.2. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.4.3. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . 27
. . . . . . . . . . . . . . . . . . 29
9.4.4. Compartir Impresoras
9.5. Herramientas para examinar la red . . . . . . . . . . . . . . . 30

10.SMTP

30

11.Seguridad

11.1. Firewall

33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2

1. X

Para empezar, veremos un servicio que utilizamos todos los días dentro
del entorno GNU/Linux: el servidor X. El servidor X es un servicio muy
poderoso, que nos permite utilizar terminales gráficas remotamente, ejecu-
tar aplicaciones en una máquina y que se muestren en otra y varias cosas más.

Muchas veces, cuando se instala una distibución, el servicio de X está con-
figurado para que no se puedan utilizar conexiones TCP (es decir que sola-
mente están permitidas las conexiones de tipo UNIX).

Las conexiones de tipo UNIX se utilizan entre los diversos procesos que
se están ejecutando en un mismo servidor. Al ejecutar netstat -nl, las
conexiones de tipo UNIX son las últimas en aparecer; en la última columna
se listan los archivos utilizados por la conexión. Estos archivos no son archivos
comunes, sino que son de tipo socket. A través de esos archivos se comunican
los procesos cuando utilizan estas conexiones de tipo UNIX.

1.1. Ejecutando aplicaciones en otras computadoras

Para permitir que otras computadoras puedan utilizar el servicio X de
un servidor es necesario verificar que el servicio no se esté iniciando con la
opción -nolisten tcp.

Si se está utilizando el kdm, gdm o xdm, será necesario modificar el ar-
chivo de configuración correspondiente para indicar que el servicio de X se
inicie sin esa opción.

Una vez que el X se ha iniciado correctamente, desde una consola gráfica
se puede utilizar el comando xhost para agregar o quitar permisos a deter-
minada maquina para que pueda o no utilizar nuestra pantalla. Esto se hace
con la siguiente sintaxis.

xhost +host
xhost -host

Por otro lado, en la máquina remota donde se quiera ejecutar la aplicación,

será necesario configurar la variable de entorno $DISPLAY.

export DISPLAY=157.92.49.211:0
xmessage Hola!!

Luego de ejecutar estas líneas, en la computadora quet tenga la dirección
IP 157.92.49.211 se verá un mensaje provisto por la aplicación xmessage
en la pantalla 0.

3

Se pueden hacer pruebas con otras aplicaciones, como xclock, que muestra
un reloj en modo gráfico, xpenguin que muestra un ping¨uino, o xpenguins que
muestra una familia de ping¨uinos que caminan por la pantalla.

Es necesario indicar que es la pantalla 0, porque puede haber más de una

pantalla en una misma máquina, como se explica a continuación.

1.2. Utilizando más entornos, con Xdmcp

De una manera similar, en lugar de ejecutar solamente las aplicaciones

en forma remotamente, es posible obtener una pantalla de inicio de sesión.

Es decir, al servidor X que se está ejecutando en una máquina, se le puede
indicar que reciba todas las aplicaciones a partir de otro servidor. De maneras
que el procesamiento se realiza en el servidor y la otra máquina pasa a ser
una terminal que simplemente muestra la pantalla y recibe la entrada de
mouse y teclado.

Sobre estos principios se basa el desarrollo de Thin Clients, es decir, Clien-
tes Delgados, que son computadoras sin disco rígido, que utilizan un servidor
X para interactuar con el usuario y todo el procesamiento se hace en el ser-
vidor.

Para todo esto se utiliza el protocolo xdmcp: X Display Manager Control

Protocol.

En el servidor que va a realizar el procesamiento, tiene que estar habilita-
do el servicio de xdmcp. Para esto, al igual que antes, es necesario modificar
la configuración del programa de inicio de sesión que se esté utilizando. Ya
sea el xdm, el gdm o el kdm.

Para poder iniciar el X, desde la máquina en la que solamente se va a mos-
trar la pantalla, es necesario utilizar el comando X con algunos parámetros
especiales, para que realice consultas xdmcp a la red, como -broadcast que
pregunta a toda la red quiénes responden el servicio xdmcp o -query host
que trata de conectarse al xdmcp que este en ese ip.

Por ejemplo, si el servidor que va a atender las consultas tiene la dirección
IP 157.92.49.102, el siguiente comando abriría una nueva sesión de X, pero
que se estaría ejecutando en ése servidor.

X :1 -query 157.92.49.102

2. Servidor de SSH

El servicio de ssh es prestado por el sshd, es decir el daemon de ssh.

4

El archivo de configuración, normalmente es /etc/ssh/sshd_config. En
general, la configuración predeterminada cumple con los requerimientos que
se pueden llegar a tener de este servicio.

Se puede seleccionar qué usuarios pueden ingresar y qué usuarios no pue-
den ingresar al sistema mediante este servicio, utilizando las siguientes op-
ciones.

AllowUsers usuario1 usuario2
PermitRootLogin no

La opción AllowUsers lista de usuarios especifica qué usuarios tie-
nen permiso para ingresar al sistema a través de ssh, cualquier otro usuario
del sistema no va a poder acceder utilizando este servicio. Esto puede ser
útil si se tienen varios usuarios con contraseñas nulas, o muy tontas y que no
les interesa utilizar ssh o cuando el administrador quiere poder acceder de
manera remota a la máquina, pero no quiere que los demás puedan ingresar.
También existen: DenyUsers, AllowGroups, DenyGroups, AllowHosts,

DenyHosts.

La opción PermitRootLogin no es fundamental en cualquier ambiente,
para que el usuario root no pueda ingresar directamente en forma remota. No
es una buena idea ingresar directamente como administrador, ya que como
política de seguridad siempre hay que tratar de utilizar el admiinistrador lo
menos posible. Por otro lado, como el usuario root existe en todos los sis-
temas UNIX, a un posible atacante le alcanza con encontrar la contraseña
del administrador para poder entrar a la computadora, si esta opción no
está activada; en cambio de esta manera, debe además conocer un usuario
del sistema y su contraseña para entrar y conseguir de alguna manera la
contraseña del administrador.

Otra opción útil, es la que permite utilizar el protocolo X a través de ssh:

X11Forwarding yes

Cuando esta opción está habilitada, un cliente que se conecte utilizando
la opción -x del cliente de ssh, generará un DISPLAY virtual en el servidor,
creando un túnel entre ambas máquinas. Es decir que se pueden ejecutar
aplicaciones gráficas en el servidor, que se muestran en el cliente, pero la
información se transmite en forma segura, a través del ssh.

Por ejemplo, si el servidor serrucho se ha configurado para que acepte

conexiones gráficas, se podría realizar la siguiente prueba.

5

user@boxitracio:~$ ssh -X serrucho
(...)
user@amadeus:~$ echo $DISPLAY
localhost:200.0
user@amadeus:~$ xclock

En este caso, el reloj gráfico se vería en la máquina original (boxitracio),
aunque se estaría ejecutando en serrucho y los datos se estarían transmitien-
do en forma segura a través del protocolo ssh.

Otra opción, utilizada para habilitar el servicio de sftp.

Subsystem sftp /usr/lib/sftp-server

2.1. Cliente de SSH - Utilización de claves

Cuando uno ingresa a un sistema en forma remota, muchas veces tiene
que escribir su contraseña, y esto no es muy seguro. Uno puede equivocarse y
escribirla en otra ventana o alguien puede estar mirando mientras la está es-
cribiendo. Además es difícil utilizar una clave realmente complicada, ya que
de alguna manera hay que recordarla, y no es una buena idea escribirla en
un papel.

El cliente de ssh posee una característica especial que permite utilizar un
método de autenticación alternativo. Este método consiste en utilizar una
clave pública y una clave privada. Estas claves suelen tener un