Administración y configuración de los servicios en red

De Sistemas Operativos II

La red en sistemas GNU/Linux

Vease también la Guía de configuración de red de Ubuntu como material complementario.

Los sistemas GNU/Linux disponen de un conjunto de comandos que permiten la configuración puntual de parámetros de red. Las configuraciones realizadas puntualmente mediante los comandos no persisten al realizar la reinicialización del sistema operativo. A mayores de estos comandos, existen ciertos ficheros de configuración que permiten la realización de configuraciones que, de forma contraria a los cambios realizados por los comandos, son persistentes.

La configuración de dispositivos de red requiere en primera instancia, disponer de un kernel con el soporte para el dispositivo concreto bien sea en forma de módulo o en el propio kernel. Normalmente, sistemas como Ubuntu ejecutan una autodetección del hardware durante el inicio permitiendo que se detecten los dispositivos de red (y otros) cargando automáticamente aquellos módulos que fuera necesario necesarios.

Tal como se ha visto anteoriormente, para comprobar que se han cargado los módulos que implementan los drivers del hardware de red se pueden emplear los comandos lsmod, lspci y lsusb. Si el hardware se ha detectado correctamente, las tarjetas de red deberían aparecer ejecutando el comando ifconfig -a. El comando ifconfig que se encuentra en el directorio /sbin el cual sólo se incluye en el PATH del usuario root por contener este último aplicaciones específicas para la administración del sistema. Por lo tanto para ejecutar ifconfig empleando un usuario sin privilegios es necesario especificar la ruta completa /sbin/ifconfig/). ifconfig puede ser empleado por usuarios sin privilegios para mostrar la configuración (nunca para modificarla).

Entre los comandos más importantes para la configuración de red se encuentra el comando ifconfig que permite obtener un listado de las interfaces (dispositivos) de red habilitadas y su configuración. La opción -a permite mostrar los dispositivos de red aunque no se encuentren habilitados. A continuación se muestra un ejemplo de configuración de interfaces.

# ifconfig
eth0      Link encap:Ethernet  HWaddr 16:db:60:6a:2e:f9  
          inet addr:193.147.86.249  Bcast:193.147.86.255  Mask:255.255.255.0
          inet6 addr: fe80::14db:60ff:fe6a:2ef9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5792487 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1469383 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:854447384 (814.8 MiB)  TX bytes:598874140 (571.1 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:21514397 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21514397 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4012167286 (3.7 GiB)  TX bytes:4012167286 (3.7 GiB)

El resultado del anterior comando indica que existen dos interfaces de red (eth0 y lo) y sus configuraciones. Por otro lado indica el tráfico transmitido y recibido desde que han sido habilitadas. Sin embargo, la opción -a puede indicar que existen dispositivos que, siendo reconocidos por el sistema operativo, no se encuentran habilitados como el siguiente ejemplo.

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 16:db:60:6a:2e:f9  
          inet addr:193.147.86.249  Bcast:193.147.86.255  Mask:255.255.255.0
          inet6 addr: fe80::14db:60ff:fe6a:2ef9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5795265 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1469707 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:854799918 (815.2 MiB)  TX bytes:599093164 (571.3 MiB)

eth1      Link encap:Ethernet  HWaddr ba:b6:b0:be:43:b5  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:21517205 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21517205 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4013306969 (3.7 GiB)  TX bytes:4013306969 (3.7 GiB)

Normalmente, existen tres tipos de interfaces en linux (dispositivos):

1. Las interfaces (dispositivos) ethernet: estos dispositivos se configuran y manejan usando exclusivamente ifconfig.
2. Las interfaces (dispositivos) inalámbricos: a estos dispositivos el kernel les asigna un nombre wlanX donde X es un número que se asigna consecutivamente a cada dispositivo que haya detectado el sistema. Estos dispositivos se configuran y manejan con las utilidades iwconfig e iwlist.
3. La interfaz de loopback: Siempre está presente en todos los equipos y se reconoce porque su nombre es lo y tiene asignada la dirección IP 127.0.0.1/8. El /8 es una notación comunmente usada en sistemas y redes y hace referencia al número de bits activos de la máscara. Dado que el número de bits activos en la máscara es 8, esta sólo puede ser 255.0.0.0.

Configuración no persistente de interfaces ethernet

Para cualquier operación de configuración y administración de las interfaces de red se empleará el comando ifconfig como administrador (sesión interactiva como administrador con sudo -s o simplemente usando sudo).

Para deshabilitar y/o habilitar una interfaz de red se usaran los siguientes comandos (asumiendo que eth0 es la interfaz):

# ifconfig eth0 down

# ifconfig eth0 up

Para cambiar o definir la configuración para la interfaz de red (eth0 en el ejemplo con la dirección IP 192.168.1.1/24) se empleará una sintaxis similar a la usada en el siguiente ejemplo.

# ifconfig eth0 192.168.1.1 netmask 255.255.255.0

En el mismo comando es posible realizar un cambio de configuración y la habilitación del interfaz de red usando la siguiente sintaxis:

# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up

Estas son las operaciones habituales de configuración de interfaces. Para cualquier otra operación, se consultará el manual de la aplicación ('man ifcnofig').

Una vez establecida la dirección IP y la máscara de subred para una determinada interfaz, será necesario configurar adecuadamente la tabla de enrutamiento para lograr que la configuración de red funcione correctamente. En este sentido, las tablas de enrutamiento permiten especificar la interfaz de red por la cual se puede alcanzar una determinada red y, en el caso de ser necesario, la puerta de enlace con dicha red. Por otra banda se puede especificar la puerta de enlace por defecto para el acceso a redes no previstas en la tabla de enrutamiento. Normalmente, al especificar una configuración de red para un dispositivo de red (por ejemplo al configurar eth0 con la dirección IP 192.168.1.12/24) ya se incluye una ruta de forma automática que permite acceder desde la interfaz configurada a la red (en el ejemplo se crearía la ruta 192.168.1.0/24 mediante el dispositivo eth0). Sin embargo, es necesario establecer la ruta a otras redes de forma manual así como la ruta por defecto que especifica normalmente la pasarela que da acceso a Internet.

Para mostrar y modificar la tabla de rutas se empleará el comando route (/sbin/route) que, en el caso de modificación, deberá ser ejecutado como usuario root (considerar el uso de sudo, su, etc.). Para mostrar la tabla de rutas sólo es necesario introducir el comando route sin argumentos aunque se suele emplear el flag -n para indicar que no se realicen resoluciones de las direcciones IP y, por lo tanto, obtener una salida más rápida y en forma de direcciones ip del comando. Nota: también se puede obtener la tabla de enrutamiento con el comando netstat -nr

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.3.0     192.168.3.2     255.255.255.0   UG    0      0        0 tun0
192.168.2.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
193.147.87.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         193.147.87.1    0.0.0.0         UG    0      0        0 eth0

# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.3.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.3.0     192.168.3.2     255.255.255.0   UG        0 0          0 tun0
192.168.2.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
193.147.87.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         193.147.87.1    0.0.0.0         UG        0 0          0 eth0

Para añadir una ruta a una red (por ejemplo 192.168.2.0/24) a través de un dispositivo de red (por ejemplo eth1) se ejecutará el siguiente comando route add -net 192.168.2.0 netmask 255.255.255.0 eth1. Dado que al establecer la configuración IP para un dispositivo se añade automáticamente una ruta para acceder a esta red, y que, para poder acceder a una red a través de una interfaz de red sin atravesar una puerta de enlace, dicha interfaz de red debe estar configurada con una IP de la misma red, la ejecución del comando especificado anteriormente sólo se realizará si se ha borrado previamente la ruta. Por otro lado, si para acceder a la red 192.168.4.0/24 a través del dispositivo eth1 es necesario usar una puerta de enlace (que debe estar necesariamente en las redes alcanzables por la interfaz eth1) 192.168.2.58, se incluiría la siguiente ruta:

# route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.2.58 eth1
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     192.168.2.58  255.255.255.0   UG    0      0        0 eth1
192.168.3.0     192.168.3.2     255.255.255.0   UG    0      0        0 tun0
192.168.2.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
193.147.87.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         193.147.87.1    0.0.0.0         UG    0      0        0 eth0

Para borrar rutas de la tabla de enrutamiento se usa la misma sintaxis que para añadir sustituyendo add por del. Ejemplo route del -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.2.58 eth1.

Para establecer la ruta por defecto (en la que se configura habitualmente la pasarela que da acceso a Internet) se usa una sintaxis muy similar usando la configuración default. A continuación se muestra un ejemplo de uso.

# route add default gw 193.147.87.1 eth0

Finalmente, dado que es necesario configurar el uso del servicio DNS (Domain Name System) se editará el fichero /etc/resolv.conf para incluir los DNS correspondientes y el dominio de búsqueda por defecto. Así se usarán líneas nameserver para especificar cada uno de los servidores de nombres que se usarán, una línea search para especificar los sufijos de búsqueda anexados automáticamente, y una línea domain para especificar el dominio al que pertenece el equipo. Para competar la información sobre configuración DNS se puede ejecutar man resolv.conf. A continuación se muestra un fichero /etc/resolv.conf de ejemplo:

# cat /etc/resolv.conf
domain uvigo.es
search uvigo.es
nameserver 193.146.32.86 #DNS from UVigo
nameserver 193.146.32.228
nameserver 8.8.8.8 #DNS from google

Cuando se desean configurar interfaces (dispositivos) de red mediante el uso de servidores DHCP (Dynamic Host Configuration Protocol) se usará el comando dhclient especificando como argumento el nombre de la interfaz que se desea configurar mediante DHCP. Es importante tener en cuenta la necesidad de disponer de un servidor DHCP en la red que ofrezca configuraciones válidas para los equipos de red. Normalmente las configuraciones ofrecidas por servidores DHCP incluyen la configuración de DNS y tabla de rutas. En caso de no incluirlo habrá que realizar estas configuraciones a mayores.

# dhclient eth0

Configuración no persistente de interfaces inalámbricas

Para configurar dispositivos inalámbricos se usan los comandos iwconfig, iwlist, iwpriv y los incluídos en el kit wpasupplicant que permiten la definición específica de parámetros de red y la asociación del dispositivo a una determinada red inalámbrica. La configuración de los parámetros IP se realiza de la misma forma que los dispositivos ethernet (Revisar la documentación del correspondiente apartado).

El comando iwpriv permite habilitar o deshabilitar características específicas de los dispositivos habilitadas a nivel de driver (por ejemplo habilitar el soporte de alta potencia en dispositivos con capacidad para emitir microondas con mayor energía) características del driver r8187.

La configuración de conexiones de dispositivos de red inalámbricos a redes abiertas o de tipo WEP (Wired Equivalent Privacy) se puede realizar de forma muy sencilla mediante los comandos iwconfig e iwlist. El comando iwlist permite obtener listas de redes WEP y abiertas disponibles y determinar algunas configuraciones del dispositivo de red como la frecuencia usada, la velocidad de conexión o el canal en el que se encuentra configurado el dispositivo. Normalmente, iwlist se usa únicamente para recopilar las redes wifi disponibles. Para esta tarea se ejecutará el comando:

# iwlist wlan0 scanning 
wlan0     Scan completed :
          Cell 01 - Address: 00:08:AB:A4:DC:5A
                    ESSID:"prueba"
                    Mode:Master
                    Frequency:2.432GHz
                    Quality:0/92  Signal level:-94 dBm  Noise level:-99 dBm
                    Encryption key:on
                    Bit Rate:1Mb/s
                    Bit Rate:2Mb/s
                    Bit Rate:5.5Mb/s
                    Bit Rate:11Mb/s

Una vez detectada una red WEP o abierta a la que se desea conectar, se usará el comando iwconfig para conectar la interfaz inalámbrica a dicha red.

sudo iwconfig wlan0 essid prueba

Además, cuanto Encryption key tenga el valor on habrá que especificar la clave WEP lo cual se hará con el siguiente comando:

sudo iwconfig wlan0 key clave

En el caso de redes WPA (Wifi Protected Access), la configuración resultará más compleja debiendo emplear las herramientas proporcionadas en el paquete wpasupplicant. Por lo tanto, para estos efectos habrá que instalar dicho paquete mediante apt-get install wpasupplicant wireless-tools. Una vez instalado wpasuplicant, se creará un fichero de configuración mediante la herramienta wpa_passphrase especificando el SSID de la red (en el ejemplo prueba) y la clave de acceso (en el ejemplo 'clave'):

# wpa_passphrase prueba claveclave > /root/wpa.conf

Este comando genera un fichero /root/wpa.conf con el ssid y la clave compartida tal como el siguiente:

network={
	ssid="prueba"
	#psk="claveclave"
	psk=fd5b6196092b2860a1c0e45e3b28b235f96aa8b57dd55bf5c3f16ca77f9d0ea9
}

Finalmente, asumiendo el driver de conexion WPA wext (comprobar el soporte de dispositivos y drivers en la página oficial de wpasupplicant), la interfaz de red wlan0 y el fichero de configuración generado, se realizará la conexión con el siguiente comando:

# wpa_supplicant -Dwext -iwlan0 -c/root/wpa.conf

Con estos sencillos pasos la interfaz de red se conecta a la red inalámbrica restando únicamente activar la interfaz y establecer su configuración IP con los comandos que se han introducido anteriormente con los comandos ifconfig y dhclient.

Configuración persistente de interfaces y rutas

Para configurar interfaces de red de forma persistente (y que se cargue la configuración cada vez que se inicia el equipo) se usa el fichero /etc/network/interfaces. El script de inicio /etc/init.d/networking es el encargado de desplegar la configuración de este fichero durante el arranque del ordenador. Este fichero tiene una estructura similar a la siguiente:

auto lo

iface lo inet loopback 

auto eth0
iface eth0 inet static
      address 192.168.2.40
      netmask 255.255.255.0
      network 192.168.2.0
      broadcast 192.168.1.255
      gateway 192.168.2.1

auto eth1
iface eth1 inet dhcp

auto wlan0
iface wlan0 inet static
      wireless-essid prueba
      wireless-key clave
      address 192.168.3.40
      netmask 255.255.255.0
      network 192.168.3.0
      broadcast 192.168.1.255
      gateway 192.168.3.1

auto wlan1
iface wlan1 inet dhcp
      wireless-essid prueba2
      wireless-key clave

En el fichero anterior se indica que se cargarán automáticamente las configuraciones de todos los dispositivos lo, eth0 y eth1... etc. (auto lo, auto eth0, auto eth1'...'). La interfaz lo corresponde con la interfaz de loopback y se configura siendo con una dirección de internet (TCP-IP) de loopback (127.0.0.1). La interfaz eth0 se configura con una dirección estática y una máscara de subred (192.168.2.40/24), que pertenecen a la red (192.168.2.0) que tiene dirección de broadcast 192.168.1.255 y en la tabla de rutas, la puerta de enlace por defecto será la 192.168.2.1. Finalmente, la interfaz de red eth1 se configura mediante el protocolo DHCP de forma automática. En el caso de configuraciones de redes abiertas o WEP, se usarán sintaxis similares a las establecidas para las configuraciones de las interfaces wlan0 y wlan1 de los cuales, el primero se configura con dirección estática y el segundo mediante el protocolo DHCP.

En el caso de redes WPA, se sustituirán las configuraciones de los dispositivos wlan0 y wlan1 por la siguiente:

auto wlan0
iface wlan0 inet static
       wpa-ssid prueba
       wpa-psk fd5b6196092b2860a1c0e45e3b28b235f96aa8b57dd55bf5c3f16ca77f9d0ea9
       address 192.168.3.40
       netmask 255.255.255.0
       network 192.168.3.0
       broadcast 192.168.1.255
       gateway 192.168.3.1

auto wlan0
iface wlan0 inet dhcp
       wpa-ssid prueba2
       wpa-psk fd5b6196092b2860a1c0e45e3b28b235f96aa8b57dd55bf5c3f16ca77f9d0ea9

donde fd5b6196092b2860a1c0e45e3b28b235f96aa8b57dd55bf5c3f16ca77f9d0ea9 es la pre-shared key (psk) generada con el comando wpa_passphrase prueba claveclave.

IP aliasing

Con GNU-Linux es posible disponer de varias direcciones IP (incluso de distintas redes) colocadas en una misma interfaz de red. Así por ejemplo, es posible implementar un enrutador (una puerta de enlace) usando únicamente un único dispositivo de red. Obviamente las dos redes IP que enrutará Linux deben usar el mismo medio físico (cable) poder realizar el enrutamiento con una misma tarjeta de red.

En un mismo medio físico (cable, por ejemplo) podrían convivir dos redes IP (por ejemplo 192.168.1.0/24 y 192.168.2.0/24). Esto no plantea problema físico ni lógico alguno de forma que se podrán conectar al cable equipos que pertenezcan a la primera red y otros que pertenezcan a la segunda sin que haya ninguna interferencia ni problema de transmisión. Obviamente, aunque dos redes IP compartan el mismo medio físico, de forma lógica y acorde con las reglas de TCP-IP, no será posible la comunicación entre un equipo de la primera red y un equipo de la segunda a menos que exista un enrutador entre ambas redes.

Gracias al IP aliasing, para poder implementar un equipo enrutador entre ambas redes, no será necesario disponer de dos dispositivos de red. La primera regla básica de un enrutador es que para poder enrutar tráfico entre dos redes el enrutador debe participar en ambas redes. Para ello, se puede crear un álias de la interfaz de red eth0 llamado eth0:0 de forma que eth0 participa en la primera red y eth0:0 participa en la segunda red. La creación de un alias se realiza con el comando ifconfig y consiste únicamente en definir una configuración IP para él. Ver el siguiente ejemplo:

# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
# ifconfig eth0:0 192.168.2.1 netmask 255.255.255.0 up

Una vez definida la configuración para la interfaz de red y su alias, para implementar un router se activará el reenvío IP.

# echo 1 > /proc/sys/net/ipv4/ip_forward

Finalmente, será necesario configurar en la tabla de rutas de las distintas redes, la puerta de enlace para alcanzar cada una de las redes (a excepción del router que puede alcanzar las dos redes por definición). Así en los equipos pertenecientes a la red 192.168.1.0/24 habrá que indicar que para alcanzar la red 192.168.2.0/24 habrá que usar la pasarela 192.168.1.1 y en los equipos pertenecientes a la red 192.168.2.0/24 habrá que indicar que para alcanzar la red 192.168.1.0/24 habrá que usar la pasarela 192.168.2.1.

Para borrar un alias de red sólo es necesario deshabilitarlo con el comando ifconfig: ifconfig eth0:0 down.

Routing

El routing consiste en la técnica que permite en reenvío de paquetes a través de otras interfaces para realizar comunicaciones entre dos redes IP distintas. Activar el routing es tan sencillo como ejecutar el comando:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Enmascaramiento

El enmascaramiento de paquetes (o también conocido como NAT -Network Address Traslation-) es una técnica que se aplica especialmente para compartir conexiones de Internet entre equipos de una red privada. Supongamos que tenemos un equipo con una conexión a Internet y una conexión a una red local privada 192.168.2.0/24. Los equipos de la red privada no pueden acceder a Internet porque las direcciones de la red son de uso privado y existen millones de redes 192.168.2.0/24 así que es imposible realizar el encamientamiento a esta red. ¿Cómo se puede compartir entonces la conexión? La técnica del enmascaramiento consiste en que el router cede su IP pública en el momento del routing a la petición del equipo de la red interna (haciendo un cambio en la cabecera correspondiente). Cuando se recibe respuesta a la petición IP, el router es capaz de restaurar de nuevo la dirección IP original de la petición y entregar de forma trasparence la respuesta al equipo que origina la petición.

Para realizar esta operación se usa el firewall de linux (iptables, ipchains o ipfwadm dependiendo del kernel). En los kernels 2.6 se usa el comando iptables para modificar el chain POSTROUTING de la tabla nat de Netfilter (el firewall de Linux 2.6). El comando sería el siguiente:

# iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -j MASQUERADE

Este comando significa que habilite el enmascaramiento en todas las peticiones que provengan de la red 192.168.2.0/24. La tabla de firewaling y el chain son conceptos que se enseñarán en la sección sobre firewalling. En el caso del enmascaramiento es necesario usar la tabla nat con el chain POSTROUTING.

Para hacer nat con ciertos protocolos (como FTP, por ejemplo) es necesario usar módulos especiales del kernel. Considera el uso de sudo modprobe nf_nat_ftp o cualquier módulo nf_nat_* (sip, tftp, amanda, h323, irc, ...).

iproute 2

Paulatinamente se están sustituyendo los comandos usados tradicionalmente para configurar la red por la suite iproute2. Esta suite es un conjunto de utilidades que permite la administración de la red de una forma sencilla, práctica y más intuitiva. Esta suite está xa disponible en Ubuntu e será o reemplado das utilidades ifconfig, route, etc. No obstante, es necesario tener en cuenta que existen aún multitud de equipos que no disponen de la suite iproute2. En estos equipos habrá que seguir usando los comandos originales. En la asignatura de redes de computadores, los alumnos usarán fundamentalmente iproute2 constituyendo una magnífica oportunidad para desarrollar sus conocimientos en esta suite sin olvidar las herramientas originales.

En la web se puede encontar el Linux Advanced Routing & Traffic Control HOWTO que pretende ser un manual intensivo de cómo manejar la red en GNU Linux de forma avanzada. Buscando en la red hemos encontrado esta traducción al español.

DHCP Servers

Algún día tocará montar un servidor DHCP. Es extremadamente sencillo y existen multitud de manuales. He Aquí uno de los múltiples que se pueden encontrar. Esto no se verá en clase. El cliente DHCP lo podeis ver en las secciones anteriores.

Otras utilidades

Una herramienta muy interesante a la hora de configurar y elaborar redes es ipcalc. Esta herramienta permite el cálculo sencillo de redes IPv4. Para usarla, simplemente hay que instalar el paquete ipcalc mediante el comando apt-get install ipcalc. A continuación se muestra un ejemplo sencillo de uso.

$ sudo apt-get install ipcalc
[sudo] password for moncho: 
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes NUEVOS:
  ipcalc
0 actualizados, 1 se instalarán, 0 para eliminar y 50 no actualizados.
Necesito descargar 26,4kB de archivos.
Se utilizarán 131kB de espacio de disco adicional después de esta operación.
Des:1 http://ftp.debian.org lenny/main ipcalc 0.41-1 [26,4kB]
Descargados 26,4kB en 0s (77,9kB/s)
Seleccionando el paquete ipcalc previamente no seleccionado.
(Leyendo la base de datos ...  
64501 ficheros y directorios instalados actualmente.)
Desempaquetando ipcalc (de .../archives/ipcalc_0.41-1_all.deb) ...
Procesando disparadores para man-db ...
Configurando ipcalc (0.41-1) ...
$ ipcalc 192.168.1.32/27
Address:   192.168.1.32         11000000.10101000.00000001.001 00000
Netmask:   255.255.255.224 = 27 11111111.11111111.11111111.111 00000
Wildcard:  0.0.0.31             00000000.00000000.00000000.000 11111
=>
Network:   192.168.1.32/27      11000000.10101000.00000001.001 00000
HostMin:   192.168.1.33         11000000.10101000.00000001.001 00001
HostMax:   192.168.1.62         11000000.10101000.00000001.001 11110
Broadcast: 192.168.1.63         11000000.10101000.00000001.001 11111
Hosts/Net: 30                    Class C, Private Internet

Monitorización de la red e identificación básica de problemas

Herramientas gráficas

Etherape es un paquete Ubuntu que incluye la herramienta etherape que permite la visión den tiempo real del tráfico que se está produciendo en una red. Permite, de forma muy intuitiva, detectar problemas en la red relativos a sobretráfico, etc.

WireShark es el antiguo Ethereal capaz de monitorizar el tráfico de red, ver cabeceras, etc. Este sofware es estudiado en la asignatura de Redes para enseñar a los alumnos las estructuras de los paquetes ip.

Herramientas en consola

La herramienta ping es una herramienta fundamental para comprobar si dos ordenadores se pueden comunicar. Hay que tener en cuenta que algunos operadores de Internet cortan mediante firewalls la comunicación del protocolo ICMP impidiendo el uso de esta herramienta.

La herramienta traceroute permite ver la ruta seguida por un paquete para llegar desde un equipo a otro y los retardos que se pueden producir entre estos paquetes.

Le herramienta arp con el argumento -n (para evitar la resolución) sirve para mostrar las tabla de direcciones ARP que maneja el núcleo.

La herramienta tcpdump permite ver el tráfico manejado por un interfaz de red. Es una herramienta muy intersante ya que permite la definición de filtros para eliminar de la salida ciertos paquetes. Se recomienda usar la opción -n (do not resolve) para obtener más rápidamente los paquetes.

La herramienta tshark es el reemplazo de wireshark para consola.

La herramienta iptraf permite ver en tiempo real el tráfico manejado por las interfaces de red.

La herramienta nmap permite buscar en equipos remotos servicios (puertos) que están activos. Además, empleando una técnica de envío de paquetes IP imposibles (con combinaciones de flags que resultan imposibles o no están contempladas en los RFC) y observando la respuesta de los distintos sistemas operativos, es capaz de determinar el sistema operativo remoto.

La herramienta netcat permite enviar datos a un puerto o escuchar datos recibidos en un puerto. Se puede usar para ver si una conexión a un determinado puerto está funcionando correctamente. Ejemplo de un chat:

#en un equipo
$ nc -l -p 8080

#desde otro equipo
$ nc primerequipo 8080

#ahora se esctibe lo que se quiera en cualquier equipo 

A continuación un ejemplo de servidor de audio

#servodor de audio
$ cat *.mp3 | nc -l -p 2000

#cliente de audio
nc server.example.org 2000 | madplay –

Ejercicio: Diseñar una duplicado de disco remoto con netcat

Netcat se ha mejorado y existen a día de hoy muchas opciones como, por ejemplo socat. Socat permite incluso el establecimiento de redes privadas virtuales. Es realmente útil.

La herramienta ettercap permite realizar diversos ataques a nivel de capa 2. Se puede usar también de forma gráfica. Sea como sea es conveniente al usarla ser consciente de lo que se está haciendo para no provocar efectos indeseados en las redes. Ejemplos.

Despliegue básico de firewalls con iptables

Una de las mayores ventajas del uso de GNU/Linux y otros sistemas operativos de código abierto es su facilidad para el despliegue de firewalls. En el caso de GNU Linux ha habido históricamente 3 generaciones de firewalls:

• ipfwadm: proveniente de los kernels 2.0.x
• ipchains: proviende de los kernels 2.2.x
• netfilter: proviene de los kernels 2.4 y se sigue usando en los nuevos kernels 2.6

Para administrar los firewalls actuales se usa el comando iptables. El firewall de netfilter incorpora, con respecto a ipchains, el concepto de tabla (especificado con la opción -t). Las tablas sirven para organizar las operaciones que se realizan con el tráfico. Así, ipchains incorpora 3 tablas:

• Filter: Es la tabla usada para descartar paquetes, responder negativamente a su aceptación (mediante ICMP)y realizar el log de los mismos. Es la tabla por defecto así que no hay que especificar nada para incluir reglas en esta tabla (-t filter).
• Nat: Es la tabla que se usa cuando se desea incluir reglas para modificar la dirección IP o el puerto de origen y destino de los paquetes (-t nat)
• Mangle: Es la tabla que se usa para incluir reglas que permiten modificar datos de los paquetes que no sean los de nat (-t mangle).

Cada una de las tablas se encuentra estructurados en chains (cadenas). Todas las reglas deben situarse en una tabla y un chain. Así por ejemplo existen los siguientes chains:

• Filter:
  • INPUT: Reglas para filtrar paquetes de entrada
  • OUTPUT: Reglas para filtrar paquetes de salida
  • FORWARD: Reglas para filtrar paquetes de routing
• Nat:
  • PREROUTING: Reglas a aplicar antes del routing
  • POSTROUTING: Reglas a aplicar después del roting
• Mangle: Contiene todos los chains incluídos en filter y Nat

Además de los chains (cadenas) y las tablas, otro concepto básico de los filtros de GNU/Linux son las acciones. Una acción consiste en indicar lo que se hace con un paquete. A continuación se muestran las acciones más comunes con un determinado paquete:

• DROP: Elimina el paquete directamente sin informar por ICMP de que el paquete no se pudo entregar.
• REJECT: Elimina el paquete informando por ICMP al emisor de que el paquete no se pudo entregar. Normalmente es mejor usar DROP al cortar los paquetes ya que los DROP generan un lag mucho mayor (porque hay que experar la expiración del timeout) lo cual limita la eficiencia de los escaneos de puertos y demás ataques y reduce el caudal de tráfico manejado por una máquina en estas situaciones.
• ACCEPT: Acepta el paquete para que siga su curso normal.
• LOG: Añade a syslog una entrada. Se puede completar con otras opciones para anotar información adicional (por ejemplo --log-prefix 'INTENTO DE ACCESO A SSH ') o el nivel de log que se desea usar (--log-level 4). Hay que tener en cuenta que LOG no corta el paquete así que normalmente cuando se desee hacer log de un paquete y cortarlo habrá que incluir 2 reglas (la primera que hace log y la siguiente que lo elimina).
• REDIRECT: Permite cambiar el puerto de destino de un paquete y sólo puede ser usado en el chain PREROUTING. Se completa con la opción --to-ports (que debe estar siempre). Por ejemplo REDIRECT --to-ports 8080
• DNAT: Permite cambiar el puerto y la IP de destino de un paquete y sólo se puede usar en el chain PREROUTING. Se completa con la opción --to que siempre debe estar presente. Ejemplo: DNAT --to 192.168.1.4:8080
• SNAT: Permite cambiar la dirección IP y puerto de origen de un paquete y sólo se puede usar en el chain POSTOUTING. Se completa con la opción --to-source. Ejemplo: SNAT --to-source 193.147.87.2. Se pueden añadir rangos de orígenes y que iptables balancee automáticamente --to-source 193.147.87.1-193.147.87.10 e incluso hacer que se les cambie también el puerto a unos concretos --to-source 193.147.87.1-193.147.87.10:128-1024. El firewall cambia automáticamente la respuesta recibida a estos paquetes para que el equipo cliente encuentre esta modificación de los paquetes como trasparente. Este tipo de reglas permite hacer MASQUERADING con IPs estáticas aunque la siguiente acción es específica para este objetivo.
• MASQUERADE Permite realizar enmascaramiento de la IP con la IP que tiene la interfaz de salida del paquete en ese momento. Sólo se puede usar en el chain POSTROUTING. No incluye ningún parámetro adicional.

También es común usar la tabla mangle para cambiar flags de calidad de servicio de los paquetes o establecer marcas.

Cada chain tiene una política por defecto. Es habitual colocar en la política por defecto DROP o REJECT de forma que por defecto se descartan todos los paquetes. A continuación se habilitan peticiones o paquetes específicos. Así, por ejemplo, a continuación se muestra un ejemplo de establecimiento de las políticas por defecto para los chains (cadenas) de INPUT, OUTPUT y FORWARD:

iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP

Una vez establecidas las políticas por defecto en las que se añaden reglas en las que el orden es extremadamente importante. Las reglas de un chain se ejecutan de inicio a fin según el orden en el que se han colocado con los parámetros -I (insertar por el principio) y -A (añadir por el final). Cada regla tiene una serie de condiciones que se codifican en los parámetros de iptables. A continuación se presentan algunos modificadores de iptables para describir el paquete:

• -p o --protocol Puede tener uno de los valores tcp, udp, udplite, icmp, esp o ah. Se trata del campo protocolo que se encuentra en la caberecera IP (capa de red).
• -s o --source permite especificar la dirección de origen del paquete. Se pueden usar redes o rangos de direcciones IP -s 192.168.2.0/24 o -s 192.168.2.3-192.168.2.27
• -d o --destination permite especificar la dirección de destino del paquete. De forma similar a -s permite especificar rangos o redes.
• -i, --in-interface permite especificar la interfaz de entrada del paquete. Solo puede ser usado en los chains de INPUT, FORWARD y PREROUTING. -i eth0, por ejemplo.
• -o, --out-interface sólo puede ser usado en los chains de FORWARD, OUTPUT y POSTROUTING y permite especificar la interfaz de salida del paquete.
• --source-port,--sport permite especificar el puerto o puertos de origen (rangos separados por :). Estas reglas deben necesariamente ir acompañadas de -p y, como es obvio, el protocolo adecuado.
• --destination-port,--dport permite especificar el puerto o puertos de destino (rangos separados por :). Estas reglas deben necesariamente ir acompañadas de -p y, como es obvio, el protocolo adecuado.
• --icmp-type permite especificar el tipo de paquete icmp (cabecera ICMP-TYPE de un paquete IP). Normalmente sólo se especifican reglas con ICMP de tipo 8 y 0. Ver IANA ICMP Parameters. Esta opción debe ir acompañada de -p y del protocolo adecuado.
• --mac-source permite definir la dirección de entrada en capa 2 (ethernet). Sólo puede ser usado en los chains de PREROUTING, FORWARD o INPUT.
• --syn o !--syn permite especificar si el bit SYN está activo en el protocolo de establecimiento de conexión a 3 bandas. Sólo se puede usar con la opción -p y el protocolo adecuado.
• --tcp-flags SYN, RST, ACK, FIN, URG, PSH, ALL y NONE (los dos últimos significan todos y ninguno) permite especificar los flags TCP activos. Hay que usarlo con -p y con el protocolo adecuado. Ejemplo: --tcp-flags ACK,SYN. (Repasar Protocolo TCP).
• --ttl-eq permite indicar un determinado valor en el campo IP TTL

Una vez presentados todos los flags, veamos un ejemplo de filtro que permite todo el tráfico saliente de una red interna y conexiones a un puerto 80.

#by default drop input and output packets
iptables -t filter -P INPUT DROP 
iptables -t filter -P OUTPUT DROP

#masquerade packets from internal network 192.168.1.0/24
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

#accept input packets to port TCP 80 
iptables -t filter -I INPUT --protocol tcp --destination-port 80 -j ACCEPT
#Lógicamente habrá que dejar salir a las respuestas (TCP in el flag SYN que provengan del puerto 80)
iptables -t filter -I OUTPUT --protocol tcp --source-port 80 !--syn -j ACCEPT 

#redirect an input packet received on TCP port 80 to real webserver in the internal network 192.168.1.4 port 8080
iptables -t nat -I PREROUTING --protocol tcp --destination-port 80 -j DNAT --to 192.168.1.4:8080

#accept ICMP traffic
iptables -t filter -I INPUT -p icmp -j ACCEPT
iptables -t filter -I OUTPUT -p icmp -j ACCEPT

#but not ICMP echo requests on eth0
iptables -t filter -I INPUT -p icmp --icmp-type 8 --in-interface eth0 -j DROP

Para ver el listado de reglas de una tabla de un firewall se usa el siguiente comando (cambiar la tabla según lo necesario y -n es para evitar resoluciones inversas):

iptables -n -t nat -L

Para borrar reglas se usa -D en vez de -I o -A. Hay que escribir la regla completamente.

Conection tracking

Esta es una de las principales novedades incluídas en netfilter. El filtrado de conexiones FTP activas resultaba prácticamente imposible con ipchains e ipfwadm. La única forma de indicar que un paquete de respuesta a una petición HTTP era mediante el protocolo de conexión a 3 bandas (iptables -I OUTPUT --protocol TCP --source-port 80 !--syn -j ACCEPT). ¿Pero cómo hacerlo en UDP? ¿Cómo se puede habilitar conexiones de FTP (activo o pasivo)? La repuesta es que es prácticamente imposible.

A partir del kernel 2.4, con netfilter/iptables se introdujo el concepto de connection tracking que hace referencia a que el kernel mantiene en memoria información sobre conexiones con el objetivo de saber si los paquetes tienen algo que ver con ellas.

Para usar connection tracking hay que incluir el modificador -m state (que permite cargar el módulo de connection tracking) y el modificador --state junto con uno o varios estados de los siguientes:

• NEW: El paquete pertenece a una conexión nueva que se está estableciendo
• ESTABLISHED: El paquete pertenece a una conexión que no es nueva pero que se había establecido previamente. En el caso de UDP donde no existe conexión lógica, un paquete UDP con una respuesta de DNS tendría este estado.
• RELATED: El paquete no pertene a una conexión nuevo ni establecida previamente pero es necesario para la comunicación por un determinado protocolo que usa varias conexiones TCP o comunicaciones UDP (por ejemplo FTP o SIP). Para el uso de este tipo de estado es necesario, en muchos casos el uso de módulos que permitan hacer tracking específico de estas conexiones. Considera el uso de modprobe nf_conntrack_sip nf_contrack_ftp nf_conntrack_netbios_ns para SIP, FTP o Netbios-NS.
• INVALID: El paquete no es válido y no se encuentra en ninguna de las situaciones anteriores.
• UNTRACKED: Este es un estado especial que puede forzar el administrador mediante una regla de firewall.

La aparición de netfilter ha permitido facilitar en gran medida el desarrollo de firewalls. Incluso algunas opciones heredadas de ipfwadm e ipchains (como --syn) han pasado de ser imprescindibles a no ser comunmente usadas durante el desarrollo de firewalls. A continuación se coloca el firewall del apartado anterior con connection tracking.

#by default drop input and output packets
iptables -t filter -P INPUT DROP 
iptables -t filter -P OUTPUT DROP

#masquerade packets from internal network 192.168.1.0/24
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

#accept input packets to port TCP 80 
iptables -t filter -I INPUT --protocol tcp --destination-port 80 -j ACCEPT
#Lógicamente habrá que dejar salir a las respuestas (TODAS)
iptables -t filter -A OUTPUT -m state --state RELTED,ESTABLISHED -j ACCEPT 
iptables -t filter -A INPUT -m state --state RELTED,ESTABLISHED -j ACCEPT 

#redirect an input packet received on TCP port 80 to real webserver in the internal network 192.168.1.4 port 8080
iptables -t nat -I PREROUTING --protocol tcp --destination-port 80 -j DNAT --to 192.168.1.4:8080

#accept ICMP traffic
iptables -t filter -I INPUT -p icmp -j ACCEPT
iptables -t filter -I OUTPUT -p icmp -j ACCEPT

#but not ICMP echo requests on eth0
iptables -t filter -I INPUT -p icmp --icmp-type 8 --in-interface eth0 -j DROP

Si a esto le añadimos un servidor FTP, sería tan sencillo como añadir los siguientes comandos:

iptables -t filter -I INPUT --protocol tcp --destination-port 21 -j ACCEPT
modprobe nf_conntrack_ftp

Organizando y Optimizando tus filtros

De cara a organizar los filtros y proceder a su optimización, se pueden crear nuevos chains en cualquiera de las tablas. Por ejemplo:

iptables -t filter -N DEST_192_168_2_0
iptables -t filter -d 192.168.2.0/24 -j DEST_192_168_2_0
iptables -t filter -I DEST_192_168_2_0 -d 192.168.2.1/24 -j DROP
....

Esto permite organizar las reglas pero, además, debido a la forma arbórea eliminar la ejecución de algunas reglas en algunos casos ahorrando algún tiempo.

Se puede guardar las reglas actuales de iptables con el comando iptables-save y guardarlas en un fichero. El comando iptables-restore permite restaurar nuevamente las reglas. Dado que el formato de iptables-save es muy sencillo, se puede observar fácilmente la tabla de reglas, construir un script, etc.

Filtros en capa 2

Ver bridging en Linux (paquetes bridge-utils y ebtables. Os recomiendo este documento que explica cómo construir un switch con Linux y este otro que permite definir filtros que se ejecutan en capa de enlace (sin configuración IP).

OpenSSH

OpenSSH es una potente herramienta para la administración remota de equipos, trasferencia de ficheros y acceso a los sistemas de red. Ver [1].

Instalación

Para instalar SSH (cliente y servidor) simplemente es necesario teclear el comando apt-get install ssh como usuario administrador (por ejemplo usando sudo). La instalación del servidor implica la creación de un par de claves con un algoritmo asimétrico (generalmente DSA) que permitirán posteriormente identificar unívocamente al equipo servidor cuando se realicen conexiones remotas. Si se quiere instalar únicamente el cliente o el servidor se considerará instalar únicamente el paquete openssh-client o openssh-server respectivamente (válido en Ubuntu).

Uso de OpenSSH para sesiones remotas

OpenSSH se puede emplear como reemplazo de ciertos clientes de sesión remota como telnet o rlogin. Estos últimos poseían el defecto de que todas las comunicaciones se realizaban de forma no encriptada. El uso de programas como ettercap permite obtener claves de usuarios que emplean este tipo de protocolos de una forma sencilla. Por este motivo el empleo de ciertos esquemas criptográficos para las comunicaciones por red es recomendable.

Para realizar una conexión con un servidor ssh se emplea el comando ssh. Ejemplo: ssh moncho@so2.atopa.me.

Identificación unívoca del equipo

Para identificar unívocamente al equipo servidor, durante la instalación, el servidor genera un par de claves (clave pública y privada). La primera vez que un cliente se conecta no puede reconocer si el servidor es realmente el servidor al que se quiere conectar. Es por ello que el cliente ssh indica que existe un riesgo potencial de estar conectado a otro equipo distinto. Si se confirma la acción de conexión, el cliente almacena en ~/.ssh/known_hosts la clave pública del servidor remoto. En las siguientes conexiones, el cliente es capaz de verificar que se está conectando al mismo servidor que la primera vez. Para ello ssh implementa un protocolo de desafío por el cual encipta un texto aleatorio con la clave pública del servidor. El servidor será el seleccionado con el cliente si tiene la clave privada que desencripta el desafío del cliente y es capaz de enviar al cliente el texto original aleatorio descifrado.

Cuando un cliente se conecta a un equipo ssh informa de los riesgos indicando el fingerprint (la huella) de la clave pública. Es una buena práctica que una vez que se realice la conexión ejecutar el comando ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub o ssh-keygen -lf /etc/ssh/ssh_host_dsa_key.pub para ver que el fingerprint de la clave pública usada en el servidor coincide con el fingerprint empleado en la conexión del servidor.

Sesiones remotas

La principal utilidad de ssh es el establecimiento de sesiones remotas aunque los usos potenciales son muchos. El ejemplo es autoexplicativo:

ssh moncho@os.atopa.me
moncho@os.atopa.me's password: 
Linux os 2.6.18.8.xs5.5.0.13.442 #1 SMP Fri May 29 10:26:39 UTC 2009 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Apr 13 07:10:42 2011 from 193.147.87.241
moncho@osas:~$ 
#ejecuta todos los comandos que quieras y sal con exit

Si se especifica un comando a ssh sólo se ejecuta dicho comando (no hay una sesión de bash). Así, por ejemplo podría ejecutarse

$ ssh moncho@os.atopa.me echo 1 
moncho@os.atopa.me's password: 
1
$

Ejercicio (piensa): Haz el servidor de audio de netcat sobre un canal seguro usando ssh

También se puede emplear el modificador -f para pasar SSH a segundo plano justo despues de ejecutarlo. En el siguiente comando el comando ejecutado (echo 1) se ejecuta en remoto y la salida se muestra en local:

$ ssh -f moncho@os.atopa.me echo 1 ; echo 2
moncho@os.atopa.me's password: 
2
$ 1
$

En el ejemplo anterior se puede ver como ssh ha pasado a segundo plano y se ha ejecutado antes la instruccion posterior. La opción -f implica -n. -n desconecta la entrada estándar del comando remoto. Si no se especificara -n la entrada estandar del comando remoto es la misma que tenga el comando ssh.

Secure copy

Una de las utilidades más interesantes de SSH es el comando scp que permite realizar copias remotas de forma segura. La sintaxis habitual es similar al comando cp. scp [-r] <origen> <destino> donde sólo 1 de los dos (origen o destino) puede ser remoto. La especificación de una ruta remota se especifica de la siguiente forma: <usuario>@<equipo_remoto>:<ruta remota>. Ejemplos:

$ mkdir copia_spamassassin
$ scp -r moncho@os.atopa.me:/usr/share/spamassassin copia_spamassassin

También se pueden copiar ficheros usando sftp (una implementación del tradicinal cliente de comandos de ftp usando ssh).

Port forwarding

Esta utilidad de SSH permite llevar puertos locales a máquinas remotas o traer puertos de máquinas remotas al equipo local. La opción -R hace lo primero y la opción -L lo segundo. Por ejemplo, traer el servicio web de equipo de un equipo 192.168.2.3 de una red local accesible a través de 193.147.87.241:

$ ssh -L 8080:192.168.2.3:80 moncho@193.147.87.241
moncho@193.147.87.241's password: 
Linux petardo 2.6.18.8.xs5.5.0.13.442 #1 SMP Fri May 29 10:26:39 UTC 2009 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Mar  2 08:31:52 2011 from 193.147.87.241

# En otra consola
$ lynx http://localhost:8080

ó también (e incluso mejor):

$ ssh -L 8080:192.168.2.3:80 -f -N moncho@193.147.87.241
moncho@193.147.87.241's password: 
$ lynx http://localhost:8080

La opción -N hace que ssh no ejecute ningún comando ni tenga salida ni entrada estándar. Se úsa cuando se quiere que SSH sólo haga port forwarding.

Al revés:

$ ssh -R 80:192.168.2.3:8080 moncho@193.147.87.241
moncho@193.147.87.241's password: 
Linux petardo 2.6.18.8.xs5.5.0.13.442 #1 SMP Fri May 29 10:26:39 UTC 2009 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Mar  2 08:31:52 2011 from 193.147.87.241

#Desde la máquina remota ya sería posible acceder
$ nc localhost 8080

X forwarding

Es un caso específico de Port forwarding para ejecutar aplicaciones X remotamente y que la interfaz se presente en el equipo local al mas puro estilo de Terminal server o Citrix Metaframe. Se usa la opción -X. La opción -f puede ser muy interesante porque permite pasar ssh a tarea de segundo plano hasta que se termine la ejecución del comando. Ejemplo:

ssh -f -X moncho@osas.atopa.me xeyes

otra forma (sin que ssh pase a segundo plano):

ssh -X moncho@osas.atopa.me xeyes
#una vez conectado ejecutar comandos X

SSH Agent

SSH Agent es una forma sencilla y segura de usar SSH sin necesidad de teclear claves. La idea básica es establecer relaciones de confianza basadas en criptografía asimétrica. La idea es que un usuario disponga de un par de claves en su computador y exporte su clave pública a todos los equipos donde se desee conectar. Para generar el par de claves se usará el comando ssh-keygen. Ejemplo:

$ ssh-keygent -t dsa -b 4096
Generating public/private dsa key pair.
Enter file in which to save the key (/home/moncho/.ssh/identity): (enter)
Enter passphrase (empty for no passphrase): miclave
Enter same passphrase again: miclave

Se pueden generar claves de tipo (-t) dsa o rsa aunque es recomendable usar dsa (esta es la opción por defecto . Se puede establecer la longitud en bits de la clave con el argumento -b (por defecto 2048). La clave privada se guarda, por defecto en ~/.ssh/identity. Este fichero indica a ssh-agent la identidad del usuario. La clave pública se guarda en el fichero ~/.ssh/identity.pub y esta clave pública se usa para autorizar el uso de la clave privada para acceder al equipo. Para autorizar la conexión a un equipo remoto y un usuario con par de claves generado se copiará la clave pública al final del fichero /home/<usuario>/.ssh/authorized_keys. Ejemplo:

#Deseo que el par de claves me permita la conexión al equipo osas.atopa.me con el usuario moncho
cat ~/.ssh/identity.pub | ssh moncho@osas.atopa.me "cat >> ~/.ssh/authorized.keys"

Ten cuidado de no especificar la opción -n (o -f que implica -n) para no deshabilitar la entrada estandar del comando remoto. Durante la instalación de la clave pública en el equipo remoto se pedirá contraseña. Una vez que se haya instalado la clave nunca más se pedirá la contraseña para acceder (se usará el par de claves) (tampoco con el comando scp). Por defecto ssh usa como clave privada para conesión la almacenada en el fichero ~/.ssh/identity. Si se desea especificar otra clave privada de identidad se usará la opción -i <fichero_que_tiene_la_clave_privada>.

Web servers

HTTP 1.1 y HTTP 1.0

El estándar actual HTTP 1.1 es una evolución del antiguo HTTP 1.0 que permitió, entre otras cosas los host virtuales. Con HTTP 1.0, un website necesitaba una dirección IP y un servidor web. En la actualidad, con HTTP 1.1 puede haber en un sólo servidor web y con una única dirección IP tantos websites como se necesiten. La diferencia que aporta esta funcionalidad es la cabecera Host. Llegó incluso a haber un HTTP 1.2 que no tuvo tanto éxito (ver HTTP en Wikipedia y este artículo donde se explican las diferencias principales).

Ejercicio: Hacer una petición HTTP 1.0 y una petición HTTP 1.1 con netcat Ejercicio 2: Ver las cabeceras HTTP enviadas por Mozilla Firefox con netcat

Existen dos productos de software libre que implementan la funcionalidad de servidor web: Cherokee y Apache Web Server.

Cherokee

Cherokee es paquete estándar en Ubuntu y Debian por lo que su instalación es sencilla. Ver el siguiente video para comprobar la sencillez.

Apache 2

Apache es un poco más difícil de configurar. También es paquete en Debian y Ubuntu. Ver o seguinte video:

Obviamente, el paso 10 se realiza para poder probar que funcionan perfectamente los host virtuales. La forma más correcta sería anotar de un dominio el equipo correspondiente.

DNS

El DNS es una tecnología que permite la traducción de nombres en direcciones IP (y viceversa). Los servidores DNS escuchan en el puerto 53 UDP y resuelven peticiones según el protocolo descrito en el RFC 1034 y el RFC 1035. El funcionamiento del DNS puede entendido como una gran base de datos distribuida, con información que se usa para traducir los nombres de dominio. Dado este diseño, se han diseñado un montón de herramientas y protocolos con distintas finalidades que tienen como base el DNS (por ejemplo Sender Policy Framework o las Relay Black/White Lists.

Leer y entender toda la información sobre DNS que se encuentra en el artículo sobre DNS de Wikipedia.

¿Cómo compro mi propio dominio?

La utilización de los dominios de primer nivel (por ejemplo: es, me, com o org) está regulada por el IANA (Internet Asigned Numbers Authority). Esta entidad puede delegar la administración de los dominios de segundo nivel correspondientes a un dominio de primer nivel en otra entidad. Así, por ejemplo, el dominio de primer nivel me está delegado en domain.ME o el dominio es está delegado en esNIC. Cada una de las entidades que tiene delegado la administración de un dominio de primer nivel mantiene una serie de servidores de nombres de primer nivel que permite el funcionamiento de la base de datos global y autoriza a ciertos proveedores de Internet a comercializar los dominios de segundo nivel. Estos proveedores se conocen con el nombre de agentes registradores (registrars). Así, por ejemplo, para registrar un dominio .es no se acuede al esNIC sinó a uno de los registradores que se pueden ver en la sección de Agentes Registradores/listado Agentes.

Normalmente, un proveedor de servicios de Internet procura obtener el título de registar en varios dominios de primer nivel para ofrecer a sus usuarios un mejor servicio. En Galicia existe un registrar muy conocido que es Dinahosting. Dinahosting permite comprar (alquilar) un dominio de segundo nivel y provee de un panel de control web muy intuitivo para su administración. Dinahosting permite registar dominios de segundo nivel en es, com, info, me, org, net, biz, bz, cat, eu, mobi, name, tel, tv, us, cn, ws y cc.

Dinahosting y el resto de proveedores ofrecen un panel de control donde se puede configurar el servidor DNS (bind) que tiene los nombres de la zona o incluir entradas en el propio servidor de DNS de dinahosting y usar este para servir el dominio (lo cual es una opción normalmente gratuíta y cómoda).

Las entradas del DNS

En un DNS existen distintos tipos de entradas o registros (Ver los tipos de entradas en Tipos de registros DNS en Wikipedia.

En cada dominio es habitual especificar, como mínimo, un intercambiador de correo, un servidor DNS y una entrada a para @ y otra para www.

Instalar BIND y configurar una zona

Ver el siguiente video:

A mayores en este sitio web podeis encontar un buen tutorial de cómo instalar Bind.

Clientes DNS

Existen 3 clientes DNS muy conocidos: dig, host y nslookup. De todos ellos el más cómodo para un administrador de sistemas es dig (apt-get install dig). La sintaxis habitual es: dig <tipo_entrada> <dominio> +short. Ejemplos:

#Intercambiadores de correo de uvigo.es
$ dig MX uvigo.es +short

#Entrada A de www.uvigo.es
$ dig A uvigo.es +short

#Entrada TXT del dominio uvigo.es
$ dig TXT uvigo.es +short

RBL

Debido a la especial arquitectura del servicio de DNS en forma de base de datos distribuída, se ha hecho muy popular el aprovechamiento de esta arquitectura para desplegar listas negras de direcciones IP. Habitualmente estas listas negras se usan para el filtro de mensajes spam. Así, organismos como SPAMHAUS distribuyen sus conocidas listas por este sistema.

La idea detrás de listas negras o blancas a través de DNS es emplear los octetos de la dirección IP invertidos junto con un sufijo para hacer una petición DNS. El resultado de la petición DNS es nulo o una dirección IP dentro de la red 127.0.0.0/8. Los tres últimos octetos del resultado se usan para incrustar códigos que son dependientes de la lista. Así por ejemplo, para saber si la dirección 193.146.32.120 (intercambiador de correo de uvigo.es) está en la lista negra ZEN elaborada por SPAMHAUS o en la lista blanca de DNSWL se emplearían los siguientes comandos

$ dig A 120.32.146.193.zen.spamhaus.org +short
$ dig A 120.32.146.193.list.dnswl.org +short

He aquí una Lista de RBLs.

Ejercicio: Comprobar todos los intercambiadores de correo de las universidades gallegas en 5 listas diferentes.

SPF

Sender Policy Framework es otro servicio que se construyó para la verificación del correo electrónico aprovechando las entradas TXT no empleadas del DNS. En estas entradas se ha contemplado la posibilidad de incluir una relación de servidores que están autorizados a enviar correo de un determinado dominio. Así, los intercambiadores de correo de un dominio, al recibir un correo, pueden comprobar si el servidor que se lo ha entregado estaba autorizado para enviar correos provenientes de ese dominio. En caso de no estar autorizado, la dirección de correo se ha falsificado.

Así para consultar la lista de servidores que pueden enviar correos del dominio uvigo.es basta con ejecutar los siguientes comandos:

$ dig TXT uvigo.es +short
"v=spf1 include:relays._spf.uvigo.es include:externos._spf.uvigo.es include:antispam._spf.uvigo.es -all"
$ dig TXT relays._spf.uvigo.es +short
"v=spf1 ip4:193.146.32.124 ip4:193.146.32.68 ip4:193.146.32.88 ip4:193.146.32.69 ip4:193.146.32.71 ip4:193.146.32.86 -all"
$ dig TXT externos._spf.uvigo.es +short
"v=spf1 ip4:216.9.241.0/24 ip4:216.9.253.0/24 ip4:206.124.117.20 ip4:206.124.117.21 ip4:206.124.117.22 ip4:206.124.117.23 ip4:193.109.81.0/24 -all"
$ dig TXT antispam._spf.uvigo.es +short
"v=spf1 ip4:193.146.32.120 ip4:193.146.32.78 ip4:193.146.32.89 ip4:193.146.32.87 ip4:193.146.32.99 -all"

En el caso del dominio uvigo.es resulta más complicada la interpretación debido a que las entradas TXT sólo admiten, habitualmente, 255 caracteres. Para poder incluír toda la lista de servidores autorizados han tenido que realizar varias entradas TXT en distintos subdominios. Sin embargo, otros dominios como usc.es lo tienen más sencillo.

$ dig TXT usc.es +short
"v=spf1 ip4:193.144.75.0/24 ~all"

Ejercicio: Hallar los servidores autorizados para el envío de un correo electrónico desde el dominio gmail.com Ejercicio2: ¿En que consiste DKIM? ¿Usa el DNS?

Correo Electrónico

El correo electrónico tiene asociados gran cantidad de conceptos incluyendo algunos que pueden rozar otro tipo de problemáticas. Por ejemplo no se podría entender el correo electrónico sin entender lo que representa una entrada MX de DNS. Las entradas MX de los DNS especifican para un determinado dominio el intercambiador de correo (MTA) que será empleado. Un intercambiador de correo en un dominio es el equipo que recibe los correos de ese dominio. Puede haber varios equipos intercambiadores de correo siempre con una prioridad. Las prioridades más bajas indican la selección del correo.

Además del protocolo para el intercambio de correo entre los dominios existen otros protocolos muy importantes en el correo electrónico. Es el caso de los protocolos de la gestión de correo post-entrega. En este caso nos encontramos con el POP (Post Office Protocol) e IMAP (Internet Message Access Protocol) que permiten que el usuario final recoja (acceda) su correo entrante. Junto con los servicios de entrega final también es muy importante (en la actualidad) contar con un sistema webmail como Horde, SquirrelMail, RoundCube, etc. que involucran la utilización del protocolo HTTP y con sistemas Tocho-Mail (para el intercambio de ficheros muy grandes).

Finalmente, los sistemas anti-spam también juegan un papel importante en el servicio del correo electrónico y es necesario ser capaz de conocer, configurar y desplegar servicios anti-spam basados en productos como SpamAssassin.

La correcta configuración de todos estos servicios asegurará la mejora de los sistemas en cuanto a vulnerabilidades o el ataque con correos spam. En este contexto hemos seleccionado una serie de productos interesantes para instalar que son Postfix, Courier y SpamAssassin. Se tratarán los conceptos fundamentales para que resulte sencillo cambiar alguno de los productos finales seleccionados por otro (Por ejemplo, Exim es muy usado en vez de postfix).

Postfix

Texto extraído de este documento de Paco Brufal. Gracias al autor por este magnífico documento que resume perfectamente la administración y muchos d elos conceptos de los MTA.

Postfix es un servidor de correo (MTA) muy potente, programado por Wietse Venema, y cuya página web es http://www.postfix.org/. En este documento voy a explicar cómo instalar el MTA Postfix en una Debian Sid (inestable), pero es totalmente válido para otras versiones de Debian, incluso para otras distribuciones de Linux.

Cada vez que quieras comprobar que tu servidor está funcionando de manera correcta, tanto para enviar como para recibir, puedes enviar un mensaje de correo a la siguiente dirección: echo@rediris.es. Cualquier mensaje que envíes a esta dirección te será devuelto.

Paquetes Debian

Los paquetes de Postfix para Debian que existen en este momento son (apt-cache search postfix)

postfix - A high-performance mail transport agent
postfix-dev - Postfix loadable modules development environment
postfix-doc - Postfix documentation
postfix-ldap - LDAP map support for Postfix
postfix-mysql - MYSQL map support for Postfix
postfix-pcre - PCRE map support for Postfix
postfix-snap - Postfix Mail Transport Agent - snapshot release
postfix-snap-dev - Postfix-snap loadable modules development environment
postfix-snap-doc - Postfix-snap documentation
postfix-snap-ldap - LDAP map support for Postfix-snap
postfix-snap-mysql - MYSQL map support for Postfix-snap
postfix-snap-pcre - PCRE map support for Postfix-snap
postfix-snap-tls - TLS and SASL support for Postfix snapshots
postfix-tls - TLS and SASL support for Postfix

Voy a dar una explicación rápida de qué es cada paquete. Los paquetes necesarios están marcados con un asterisco (*).

• postfix. Este es el paquete principal de Postfix. (*)
• postfix-dev. Entorno de desarrollo.
• postfix-doc. Documentación. (*)
• postfix-ldap. Soporte LDAP.
• postfix-mysql. Soporte MySQL.
• postfix-pcre. Soporte de expresiones regulares. (*)
• postfix-snap-*. Versiones snapshot. Pueden ser inestables.
• postfix-tls. Soporte TLS y SASL (SMTP autentificado).

Instalación

La instalación de los paquetes Debian se puede realizar de manera sencilla con el comando

apt-get install postfix postfix-doc postfix-pcre

Si existen dependencias con otros paquetes, apt-get también las instalará. Después de bajarse los paquetes de Internet, y antes de instalarlos, posiblemente se nos preguntarán una serie de cosas (relativas a la configuración). Respoderemos a esas preguntas, ya que son muy sencillas y nos permitiran crear una configuración base. Luego podemos depurar más la configuración siguiendo esta guia.

El directorio donde se encuentran los ficheros de configuración de Postfix es /etc/postfix/, y el fichero principal de configuración se llama main.cf.

Comandos básicos de Postfix

Existen varios comandos que nos pueden ser útiles mientras usemos Postfix. Una breve lista sería

• postfix stop. Este comando para el servidor.
• postfix start. Este comando arranca el servidor.
• postfix reload. Este comando hace que el servidor relea la configuración sin parar el servicio.
• mailq. Para ver la cola de mensajes.
• postfix flush. Fuerza el envío de mensajes de la cola de espera.
• postmap. Este comando sirve para construir los ficheros auxiliares de Postfix.
• postconf. Muestra toda la configuración de Postfix.
• newaliases. Este comando reconstruye la base de datos de alias.

Modos de ejecución del servidor

Existen 2 modos de ejecución, por así decirlo. El modo internet site y el modo internet site with smarthost

internet site

El modo internet site se caracteriza porque el propio servidor se encarga de repartir los mensajes a sus destinatarios directamente, sin pasar por otro servidor predefinido. Para usar este modo, en el fichero de configuración /etc/postfix/main.cf NO debe estar definida la opción relayhost

 relayhost =

Esta configuración es util para ordenadores individuales que no están en una red local o tienen conexión permanente a Internet (como ADSL, cable, ...).

internet site with smarthost

El modo internet site with smarthost se caracteriza porque el servidor no envía los mensajes directamente a sus destinatarios, sino que los envia a otro servidor de correo, y aquel ya se encargará de enviarlo. Para usar este modo, hay que definir la opción relayhost y ponerle como argumento la dirección IP o el nombre de host del servidor SMTP que queramos

 relayhost = smtp.mi-red-local.com

Esta configuración se suele dar en redes locales que ya tienen un servidor SMTP o en conexiones esporádicas a Internet con módem, por ejemplo (el servidor definido sería el de tu proveedor).

Control de envíos por IP

Relacionado con los relayhost, es posible que los correos electrónicos que llegan a un determinado dominio sólo puedan hacerlo a través de un equipo. Por ejemplo, el dominio sing.ei.uvigo.es recibe a través de los servidores antispam1.uvigo.es y antispam2.uvigo.es de la misma forma que uvigo.es. Ningún equipo se puede conectar desde la red externa al puerto 25 de equipos de la Universidad. Pero el correo se recibe en ann7.ei.uvigo.es (193.147.87.222/24). Es antispam1.uvigo.es y antispam2.uvigo.es quienes reciben el correo y lo reenvían al servidor 193.146.32.71 y este al servidor final. En esta situación sabemos exactamente de dónde proceden los correos electrónicos entrantes (y tal vez los salientes) pudiendo establecer una configuración que limite la conexión desde cualquier otra dirección IP.

smtpd_client_restrictions =
        permit_mynetworks
        reject_maps_rbl
        check_relay_domains

mynetworks = 193.146.32.71/32, 193.147.87.0/24 # Permit also the network of ESEI

Ejercicio: Si soy un sysadmin ¿cómo puedo saber quién me entrega un determinado correo electrónico?

¿Cómo se implementa en postfix la redirección del correo a otro servidor? Ejecuta man transport

Mas cuestiones de seguridad aplicables

Como hemos visto, se pueden filtrar los envíos por redes o hosts. Pero también es posible realizar el filtrado mediante el uso de direcciones de correo:

smtpd_recipient_restrictions =
        permit_mynetworks,
        check_sender_access hash:/etc/postfix/usuarios
        reject_unauth_pipelining,
        reject_non_fqdn_recipient,
        reject_non_fqdn_sender,
        reject_unknown_recipient_domain,
        reject_unknown_sender_domain,
        check_relay_domains

En la directiva check_sender_access vemos que hace referencia a un fichero llamado /etc/postfix/usuarios. Este fichero contiene algo parecido a esto:

usuario@dominio.com     OK
usuario2@dominio.com    OK
usuario3@dominio2.com   OK

Esta lista de e-mails significa que dichas direcciones pueden enviar a través de nuestro servidor, independientemente de la IP que tengan. Como puedes imaginar este método no es muy seguro, ya que si algún spammer averigua una dirección de correo válida de tu servidor, podrá usarla para enviar correo de manera indiscriminada.

Cada vez que se modifique este fichero se debe ejecutar el comando

 cd /etc/postfix && postmap usuarios && postfix reload

También se puede emplear la técnica de ACL. Es similar a esta anterior. Las ACL, o listas de control de acceso, son las direcciones de e-mail que NO pueden enviar correo a nuestro servidor. Si llega un mensaje con alguna de esas direcciones, el servidor lo rechazará. La configuración de las ACL sería

smtpd_sender_restrictions =
        hash:/etc/postfix/access
        reject_unknown_sender_domain
        permit_mynetworks

Y el fichero /etc/postfix/access contendría

bob645@yahoo.com        REJECT
METHOSYSTEM.IT          REJECT
techemail.com           REJECT
trafficmagnet.net       REJECT
email.com               REJECT
seekercenter.net        REJECT
icai.ie                 REJECT
</code>

 cd /etc/postfix && postmap access && postfix reload

Todavía más práctico fué el método pop-before-smtp usado por Yahoo durante años.

Este método consiste en que los clientes, antes de poder enviar correo a través de nuestro servidor, deben recoger primero el correo mediante POP3 o IMAP. Al recoger el correo, un demonio controla los logs de los servidores POP3 o IMAP, e introduce en un fichero las IPs de los clientes. A partir de ese momento, desde esa IP se podrán enviar correos, con cualquier remitente, durante el tiempo especificado, que por defecto son 30 minutos.

En la distribución Debian, existe un paquete llamado pop-before-smtp. Lo instalaremos con el comando

apt-get install pop-before-smtp

Luego editamos el fichero /etc/pop-before-smtp/pop-before-smtp.conf para elegir el patrón (expresión regular) que se ajusta a las lineas de log que genera nuestro servidor POP3 o IMAP. Reiniciamos el demonio con el comando

 /etc/init.d/pop-before-smtp restart

y comprobamos que al recoger el correo, nuestra IP se introduce en el fichero /var/lib/pop-before-smtp/hosts.db con el siguiente script:

#!/usr/bin/perl -w
use strict;
use DB_File;

# Written by Jonas Smedegaard <dr@jones.dk>.
# - but copied more or less verbatim from a mail regarding pop-before-smtp
# by Bennett Todd <bet@rahul.net>.
# If someone recovers the origin of this script please tell me, and I will
# add it to this file.
#
# Freely redistributable, or by same rules as those of pop-before-smtp
# (until the original author eventually shows up and claims differently).

die "syntax: $0 filename.db [...]\n" unless @ARGV;

file: for my $file (@ARGV) {
        my %h;
        dbmopen(%h, $file, 0) || do {
                warn "$0: dbmopen($file): $!\n";
                next file;
        };
        print "$_ -> $h{$_}\n" for keys %h;
}

Pasamos a configurar Postfix. En el fichero /etc/postfix/main.cf modificamos la siguiente linea para que incluya el fichero de IPs que genera el demonio pop-before-smtp:

mynetworks = 127.0.0.0/8, 192.168.1.0/24, hash:/var/lib/pop-before-smtp/hosts

y se reinicia postfix

/etc/init.d/postfix restart

En la actualidad se usa el método SMTP-AUTH derivado de las nuevas extensiones del protocolo SMTP incluídas en el RFC 2821. Consultar esta pagina para su instalación.

Integrando postfix y courier

Courier posee buenas implementaciones para los protocolos de POP3, SPOP, IMAP o IMAPS. Además es fácil de integrar con Postfix. Lo único que hay que hacer para que la configuración funcione correctamente es instalar y configurar el servicio courier correspondiente: p.ej apt-get install courier-pop.

La integración de postfix y courier se hace a través del sitio donde postfix (el MTA) almacena los correos recibidos y donde courier-pop los coge para ofrecerselos al usuario. La opcíon de configuración es MAILDIRPATH en Courier y home_mailbox en Postfix. Así por ejemplo, courier necesitaría la siguiente implementación:

##NAME: MAILDIRPATH:0
#
# MAILDIRPATH - directory name of the maildir directory.
#
MAILDIRPATH=Maildir

y en Postfix habría que hacer la siguiente configuración

# mailbox file relative to a user's home directory. The default
# mailbox file is /var/spool/mail/user or /var/mail/user. Specify
# "Maildir/" for qmail-style delivery (the / is required).
home_mailbox = Maildir/

Otras integraciones

Es habitual integrar los sistemas de correo con LDAP o mysql para crear usuarios virtuales. Es algo que no vamos a hacer en clase ya que existen multitud de sitios donde se expone cómo hacerlo.