Ver código fuente

== La red en sistemas GNU/Linux ==

Vease también la  [https://help.ubuntu.com/10.04/serverguide/C/network-configuration.html 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.

<code><pre>
# 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)
</pre></code>

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.

<code><pre>

# 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)
</pre></code>

Normalmente, existen tres tipos de interfaces en linux (dispositivos):
# Las interfaces (dispositivos) ethernet: estos dispositivos se configuran y manejan usando exclusivamente ifconfig. 
# 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.
# 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):

<code><pre>
# ifconfig eth0 down

# ifconfig eth0 up
</pre></code>

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.

<code><pre>
# ifconfig eth0 192.168.1.1 netmask 255.255.255.0
</pre></code>

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

<code><pre>
# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
</pre></code>

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''

<code><pre>
# 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
</pre></code>

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:

<code><pre>
# 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
</pre></code>

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.

<code><pre>
# route add default gw 193.147.87.1 eth0
</pre></code>

Finalmente, dado que es necesario configurar el uso del servicio [http://es.wikipedia.org/wiki/Domain_Name_System 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:

<code><pre>
# 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
</pre></code>

Cuando se desean configurar interfaces (dispositivos) de red mediante el uso de servidores [http://es.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol 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. 

<code><pre>
# dhclient eth0
</pre></code>

=== 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 ([[#Configuración no persistente de interfaces 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) [http://www.aircrack-ng.org/doku.php?id=r8187 características del driver r8187].

La configuración de conexiones de dispositivos de red inalámbricos a redes abiertas o de tipo [http://es.wikipedia.org/wiki/Wired_Equivalent_Privacy 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:

<code><pre>
# 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
</pre></code>

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. 

<code><pre>
sudo iwconfig wlan0 essid prueba
</pre></code>

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

<code><pre>
sudo iwconfig wlan0 key clave
</pre></code>

En el caso de redes [http://es.wikipedia.org/wiki/Wi-Fi_Protected_Access 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'):

<code><pre>
# wpa_passphrase prueba claveclave > /root/wpa.conf
</pre></code>

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

<code><pre>
network={
	ssid="prueba"
	#psk="claveclave"
	psk=fd5b6196092b2860a1c0e45e3b28b235f96aa8b57dd55bf5c3f16ca77f9d0ea9
}
</pre></code>

Finalmente, asumiendo el driver de conexion WPA wext (comprobar el soporte de dispositivos y drivers en la [http://hostap.epitest.fi/wpa_supplicant/ 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:

<code><pre>
# wpa_supplicant -Dwext -iwlan0 -c/root/wpa.conf
</pre></code>

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:

<code><pre>
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

</pre></code>

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:

<code><pre>
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
</pre></code>

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 [http://es.wikipedia.org/wiki/Familia_de_protocolos_de_Internet 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:

<code><pre>
# 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
</pre></code>

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

<code><pre>
# echo 1 > /proc/sys/net/ipv4/ip_forward
</pre></code>

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:

<code><pre>
# echo 1 > /proc/sys/net/ipv4/ip_forward
</pre></code>

=== 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:

<code><pre>
# iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -j MASQUERADE
</pre></code> 

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 [http://es.wikipedia.org/wiki/Iproute2 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 [http://lartc.org/howto/ 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 [http://www.gulic.org/almacen/lartc/lartc.pdf 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 [http://rodria1.blogspot.com/2008/01/dhcp-server-debian.html 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.

<code><pre>
$ 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
</pre></code>

=== 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.

[[Archivo:etherape.png|center|thumb|400px|]]

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 [http://es.wikipedia.org/wiki/Ping 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 [http://es.wikipedia.org/wiki/Traceroute 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 [http://es.wikipedia.org/wiki/Address_Resolution_Protocol 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 [http://es.wikipedia.org/wiki/Tcpdump 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 [http://www.wireshark.org/docs/man-pages/tshark.html tshark] es el reemplazo de wireshark para consola.

La herramienta [http://es.wikipedia.org/wiki/IPTraf iptraf] permite ver en tiempo real el tráfico manejado por las interfaces de red. 

La herramienta [http://nmap.org/ 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 [http://crysol.org/node/28 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:

<code><pre>
#en un equipo
$ nc -l -p 8080

#desde otro equipo
$ nc primerequipo 8080

#ahora se esctibe lo que se quiera en cualquier equipo 
</pre></code>

A continuación un ejemplo de servidor de audio

<code><pre>
#servodor de audio
$ cat *.mp3 | nc -l -p 2000

#cliente de audio
nc server.example.org 2000 | madplay –
</pre></code>

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 [http://www.dest-unreach.org/socat/ socat]. Socat permite incluso el establecimiento de redes privadas virtuales. Es realmente útil.

La herramienta [http://ettercap.sourceforge.net/ 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. [http://www.hackcommunity.com/Thread-Ettercap-Man-In-The-MIddle-Attack-SSL-Strip 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 [http://es.wikipedia.org/wiki/Netfilter/iptables 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:

<code><pre>
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP
</pre></code>

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 [http://www.iana.org/assignments/icmp-parameters 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 [http://es.wikipedia.org/wiki/Transmission_Control_Protocol 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.

<code><pre>
#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

</pre></code>

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):

<code><pre>
iptables -n -t nat -L
</pre></code>

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.

<code><pre>
#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 RELATED,ESTABLISHED -j ACCEPT 
iptables -t filter -A INPUT -m state --state RELATED,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
</pre></code>

Si a esto le añadimos un servidor FTP, sería tan sencillo como añadir los siguientes comandos:
<code><pre>
iptables -t filter -I INPUT --protocol tcp --destination-port 21 -j ACCEPT
modprobe nf_conntrack_ftp
</pre></code>

=== 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:

<code><pre>
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
....
</pre></code>

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 [http://objektblog.wordpress.com/2007/11/21/hacer-un-switchbridge-lan-por-software-con-gnulinux/ este documento] que explica cómo construir un switch con Linux y [http://linux-networks.net/Prentice.Hall.PTR-Troubleshooting.Linux.Firewalls/0321227239/ch11lev1sec3.html 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 [http://es.wikipedia.org/wiki/OpenSSH].

=== 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: 

<code><pre>
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
</pre></code>

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 

<code><pre>
$ ssh moncho@os.atopa.me echo 1 
moncho@os.atopa.me's password: 
1
$
</pre></code>

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:

<code><pre>
$ ssh -f moncho@os.atopa.me echo 1 ; echo 2
moncho@os.atopa.me's password: 
2
$ 1
$
</pre></code>

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:

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

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:

<code><pre>
$ 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
</pre></code>

ó también (e incluso mejor):

<code><pre>
$ 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
</pre></code>

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:
<code><pre>
$ 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
</pre></code>

=== 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:

<code><pre>
ssh -f -X moncho@osas.atopa.me xeyes
</pre></code>

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

<code><pre>
ssh -X moncho@osas.atopa.me xeyes
#una vez conectado ejecutar comandos X
</pre></code>

=== SSH Agent ===

[http://es.wikipedia.org/wiki/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:

<code><pre>
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/moncho/.ssh/id_dsa): (enter)
Enter passphrase (empty for no passphrase): miclave
Enter same passphrase again: miclave
</pre></code>

Se pueden generar claves de tipo (''-t'') ''dsa'' o ''rsa'' aunque es recomendable usar ''dsa''. Se puede establecer la longitud en bits de la clave con el argumento -b (por defecto 2048 en el caso de rsa). La clave privada se guarda, por defecto en ''~/.ssh/id_dsa' o '~/.ssh/id_rsa' (según el tipo)'. Este fichero indica a ssh-agent la identidad del usuario. La clave pública se guarda en el fichero ''~/.ssh/id_dsa.pub' o '~/.ssh/id_rsa.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:

<code><pre>
#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"
</pre></code>

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://www.ietf.org/rfc/rfc2616.txt HTTP 1.1] es una evolución del antiguo [http://www.ietf.org/rfc/rfc1945.txt 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://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP en Wikipedia] y [http://www8.org/w8-papers/5c-protocols/key/key.html 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: [http://www.cherokee-project.com/ Cherokee] y [http://httpd.apache.org/ 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.

<youtube>bIxFzOv3U1A</youtube>

=== Apache 2 ===

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

<youtube>Ny_B6P00Ehc</youtube>

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 [http://es.wikipedia.org/wiki/Domain_Name_System 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 [http://www.ietf.org/rfc/rfc1034.txt RFC 1034] y el [http://www.ietf.org/rfc/rfc1035.txt 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 [http://es.wikipedia.org/wiki/Domain_Name_System 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 [http://www.iana.org/ 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 [http://domain.me/ ''domain.ME''] o el dominio ''es'' está delegado en [http://www.nic.es/index.action 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 [http://www.nic.es/listado-agentes/agenteRegistrador/1447 ''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 [http://www.dinahosting.com 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 [http://es.wikipedia.org/wiki/Domain_Name_System ''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:

<youtube>EQTkU-ZXgVk</youtube>

A mayores en [http://www.liberaliatempus.com/dns-bind.html 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:

<code><pre>
#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
</pre></code>

=== 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 [http://www.spamhaus.org/ 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

<code><pre>
$ dig A 120.32.146.193.zen.spamhaus.org +short
$ dig A 120.32.146.193.list.dnswl.org +short
</pre></code>

He aquí una [http://www.moensted.dk/spam/ Lista de RBLs]. 

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

=== SPF ===

[http://es.wikipedia.org/wiki/Sender_Policy_Framework 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:

<code><pre>
$ 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"
</pre></code>

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.

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

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 [http://www.servitux.org/view.php/page/postfix 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)
<code><pre>
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
</pre></code>

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

<code><pre>
apt-get install postfix postfix-doc postfix-pcre
</pre></code>

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

<code><pre>
 relayhost =
</pre></code> 

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

<code><pre>
 relayhost = smtp.mi-red-local.com
</pre></code>

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.

<code><pre>
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
</pre></code>

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:

<code><pre>
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
</pre></code>

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

<code><pre>
usuario@dominio.com     OK
usuario2@dominio.com    OK
usuario3@dominio2.com   OK
</pre></code>

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

<code><pre>
 cd /etc/postfix && postmap usuarios && postfix reload
</pre></code>

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

<code><pre>
smtpd_sender_restrictions =
        hash:/etc/postfix/access
        reject_unknown_sender_domain
        permit_mynetworks
</pre></code>

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

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

Como vemos se pueden denegar direcciones e-mail concretas (bob645@yahoo.com), o dominios enteros (techemail.com). Cada vez que se modifique este fichero debemos ejecutar

<code><pre>
 cd /etc/postfix && postmap access && postfix reload
</pre></code>

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

<code><pre>
apt-get install pop-before-smtp
</pre></code>

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

<code><pre>
 /etc/init.d/pop-before-smtp restart
</pre></code>

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:

<code><pre>
#!/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;
}
</pre></code>

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:

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

y se reinicia postfix

<code><pre>
/etc/init.d/postfix restart
</pre></code>

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 [http://www.nervous.it/txt/Postfix-SMTP-AUTH-4-DUMMIES.html 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:

<code><pre>
##NAME: MAILDIRPATH:0
#
# MAILDIRPATH - directory name of the maildir directory.
#
MAILDIRPATH=Maildir
</pre></code>

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

<code><pre>
# 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/
</pre></code>
=== 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.