FireWall-Router Linux-Ubuntu

Tema 10: Administracin de la red (Linux III)
Sistemas Informticos 1 DAM
Administracin de la red (Linux III)

Pginas
Contenidos
Introduccin.
10.0
Configuracin de las mquinas virtuales.
4-7
10.1
Configuracin del Servidor (servidor con dos ifaces de red SUBU14 ).
8-10
10.2
Configuracin de los host de la red interna (mquinas virtuales en MiRedDam ).
11-19
10.3
Configuracin del FireWall (iptables) (dar acceso a Internet a la red interna UBU14, WIN7 ).
20-23
24-30
10.3.1 Configuracin de Samba.

10.4
31-34
35-44
Instalacin de Apache2 (servidor Web).

10.4.1 Configuracin de DHCP.
10.5
Acceso remoto al servidor . . .
35-39
10.5.1 . . . por VNC.
40-44
10.5.2 . . . por SSH.
1/44
Introduccin:
En esta tarea se tratar de montar un router-firewall haciendo uso de un servidor sobre el que corre un Linux Ubuntu 14.04. La idea es montar un sistema de red
cuyo esquema lgico es como el que se aprecia en la imagen. Donde el servidor tiene acceso directo a Internet a travs de la interface de red eth0 y se conecta a la red
interna a travs de la eth1.
eth0
Router
eth1
INTRANET
INTERNET
Switch
Firewall
Servidor Linux
Ubuntu 14.04
Teniendo en cuenta que tan slo dispongo de una mquina conectada a internet, hago uso de la virtualizacin para montar el sistema. Para ello creo una mquina
virtual con Ubuntu 14.04 con dos interfaces de red, que actuar como servidor y otras dos mquinas virtuales con Ubuntu 14.04 y Windows 7 Profesional con una
interface de red cada una de ellas. El esquema real de la red que he montado queda as:
Sistema Virtual en Virtual Box sobre mquina anfitrin Linux Open Suse 13.01
eth1
IP Privada
192.168.1.1/24
eth0
IP Pblica
INTERNET
Router-Firewall
ADSL
Eth0
adaptador puente
IP Privada
192.168.1.40/24
Host Vitual Linux Ubuntu 14.04

Eth0
IP Privada 10.0.0.100/24
eth1
IP Privada
10.0.0.1/24
Switch Virtual
Virtual Box
eth0
mquina real
IP Privada
192.168.1.37/24
MiRedDAM Virtual
10.0.0.0/24
Host Vitual W7 Profesional
Eth0
IP Privada 10.0.0.110/24
Servidor Virtual
Linux Ubuntu 14.04
2/44
10.0 Configuracin de las mquinas virtuales.

Como podemos observar en la imagen anterior, realmente tenemos un router ADSL que proporciona conexin a Internet a la mquina real o anfitrin sobre la que
corre un Linux OpenSuse 13.01 como SO anfitrin, en la cual est instalado el gestor de MV, Virtual Box.
Sobre VB he creado una mquina virtual con dos interfaces de red, la eth0 que est configurada como adaptador puente y la eth1 que est configurada como red
interna.
La eth0 accede al router ADSL ,a travs de la eth0 de la mquina anfitrin que funciona como puente, el cual le
proporciona una IP privada mediante su servicio DHCP, en concreto la 192.168.1.40/24, adems de pasarle como puerta de
enlace predeterminada la 192.168.1.1/24, mscara de red y DNS's entre otros.
La eht1 accede a una red interna virtual que he llamado MiRedDam en VB (10.0.0.0/24), en la cual hay otros dos host
virtuales conectados. Por tratarse del equipo que funciona como router-firewall, que dar acceso a internet a la los hosts de
la red interna, esta interface debe ser la 10.0.0.1/24, es decir, la reservada al router.
En las cuatro imgenes de arriba vemos como clono de forma completa la mquina virtual de la tarea 8, lo cual es mucho ms rpido que instalar una nueva
mquina. En la mquina clonada configuro dos interfaces de red como ya he comentado y se aprecia en las capturas arriba.
3/44
10.1 Configuracin del Servidor.

Para hacer que el equipo con dos interfaces de red y Linux Ubuntu 14.04 (mquina virtual UBU-14-Tarea10) pueda actuar como un servidor que proporcione
servicios a la red interna (virtual MiRedDam) donde tengo dos mquinas virtuales (UBU-14-Tarea8 y Win7-Pro-Tarea5) debemos configurarlo para tal fin.
El primer paso a tener en cuenta es que se trata de una mquina que hemos clonado y por el SO es exactamente igual a su mquina padre. Esto quiere decir que
en ambas mquinas existen los mismos usuarios y grupos, lo que en principio no es un problema para conectarlas en red. Adems ambas tienen el mismo nombre de host
como se ve cuando muestro por pantalla la variable global del sistema HOSTNAME y los hosts de la red donde el loopback es tambin UBU14.
Para solucionarlo accedo al archivo 'etc/hostname' y cambiamos la variable global que ahora es UBU14 y la nombro
como SUBU14 (servidor Ubuntu 14) y de la misma forma cambio el nombre para la direccin de loopback.
Tras reiniciar la MV exploro la variable global y vemos como en efecto ha cambiado y ahora es SUBU14.
Otro paso importante es observar si el SO ha detectado las dos interfaces de red que hemos puesto a la MV.
Para ello utilizo el comando 'ifconfig' y vemos como la eth0 (que accede al router ADSL a travs del puente con la mquina anfitrin) recibe del servidor DHCP
del router ADSL la direccin 192.168.1.40/24.
4/44
Y explorando las rutas en la tabla de enrutamiento de la MV con el comando 'route' opcin '-F'(datos de enrutamiento en FIB = Forwarding Information Base)
vemos como el servidor DHCP del router ADSL ha asignado como pasarela, puerta de enlace o gateway por defecto a la ip privada del router ADSL (se ve en la
Indic=U(utilizable) G(gateway) y en Destino=default es decir, todos los paquetes que no van a la 192.168.1.0/24 son por defecto encaminados a la 192.168.1.1 a
travs de Interface=eth0 para su reenvo).
Por otro lado, se observa como en la eth1 no han sido
configurados los parmetros del IPv4. Esto es debido a que la eth1 no
est presente en la configuracin de las interfaces en el archivo
'/etc/network/interfaces', tal y como vemos en la imagen. Y tampoco hay
ningn servidor DHCP en la red 10.0.0.0/24 que le proporcione direccionamiento.
El siguiente paso para preparar nuestro servidor ser modificar dicho archivo
aadiendo la configuracin para eth0, eth1 y loopback.
5/44
En las imgenes arriba se puede observar como ha quedado el fichero tras retocarlo. Y como al reiniciar la MV los cambios surgen efecto (imgenes derecha).
Ojo, los DNS slo se configuran en una de las dos ifaces de la mquina.
A este punto y a tenor de lo que se observa en las imgenes de la derecha, la eth0 de la MV ya no recibir direccionamiento DHCP del router ADSL, puesto que
est en esttico a la direccin 192.168.1.2/24. La eth1 ahora si tiene parmetros para ipv4 estticamente a 10.0.0.1/24. Y la tabla de enrutamiento de la MV ha quedado
como:
1) todos los paquetes que no van a localhost, 10.0.0.0/24 o 192.168.1.0/24 sern encaminados a 192.168.1.1 a travs de la eth0 de la MV, para ser reenviados.
2) todos los paquetes que van hacia la red 10.0.0.0/24 son enviados a la misma a travs de la eth1 de la MV.
3) todos los paquetes que van hacia la mquina local se los queda la mquina local (metric=1000).
4) todos los paquetes que van hacia la red 192.168.1.0 son enviados a la misma a travs de la eth0 de la MV.
Debemos saber que un SO Linux puede actuar como host-terminal (variable global ip_forward = false) o como enrutador o router (variable global ip_forward =
true), en cuyo caso har uso de la tabla de enrutamiento del ncleo que he descrito en el prrafo de arriba.
Para modificar el valor de la variable 'ip_forward' de forma circunstancial lo hacemos poniendo el
valor 1 en el fichero '/proc/sys/net/ipv4/ip_forward'.
Sin embargo como he dicho se trata de un cambio no permanente y al reiniciar la mquina se pierde.
Ya que el sistema lo carga desde el fichero '/etc/sysctrl.conf' , donde realmente hay que hacer el cambio
para que sea permanente.
Esto es tan simple como editar el fichero y des-comentar la lnea con el

contenido net.ipv4.ip_forward=1.
Ahora al reiniciar la MV actuar como ip_forward, es decir como router, y aplicar
las reglas reflejadas en FIB= Forwarding Information Base.
6/44
Por ltimo controlamos o establecemos la forma en la que el servidor va a resolver los nombres de
dominios. Lo cual se puede hacer de forma manual aadiendo cada nombre de dominio.host y su ip al archivo
'/etc/hosts' o le podemos indicar a travs del fichero '/etc/resolv.conf' las ip's de DNS's, como se ve en la
imagen.
Es preciso aclarar que esto duplica la indicacin de los DNS en el fichero '/etc/network/ifaces'. Se hace
a ttulo ilustrativo.
Una vez establecidos los DNS del servidor, lo reinicio y compruebo que los cambios tienen efecto. Para ello hago 'ping' a la puerta de enlace o gateway, hago
'ping' a un DNS de Google, y por ltimo accedo a la Web y hago una bsqueda de algo.
Todas las pruebas son satisfactorias, lo que indica que nuestro servidor est bien configurado para tener acceso a Internet.
7/44
10.2 Configuracin de los hosts en la red interna.

La mquina de la tarea 8 me servir como uno de los host de la red interna sin ms que cambiar el tipo de conexin de su interface de red a Red interna. De la
misma forma hago uso de la mquina virtual de la tarea 5, con W7 Profesional, la cual paso tambin a la red interna. Contamos ahora con dos host en la red interna los
cuales he direccionado de forma esttica, ya que no hay un servidor DHCP an instalado en el servidor virtual. En concreto para la MV con Ubuntu 14.04 le asign la ip
10.0.0.100/24 y los DNS de Google 8.8.8.8 y 8.8.4.4 . Igualmente a la MV con W7 Profesional le asigne la ip 10.0.0.110/24 y los mismos DNSs.
Mquina UBU-14-Tarea8:
Para ello sigo los mismo pasos que para la configuracin de las interfaces del servidor. Exploro las interfaces y veo que la reconoce pero no asigna ip.
Configuro la eth0 en 10.0.0.100/24 y al reiniciar compruebo los cambios. Los DNS ya los indico en este mismo fichero, por tanto no necesito tocar
'/etc/resolv.conf'.
8/44
Mquina Win7-Pro-Tarea5:
Para la mquina con Windows-7-Professional, tras arrancar el SO accedo a Panel de control Redes e Internet Centro de redes y recursos compartidos, y
configuro la iface de la MV, en concreto para el protocolo ipv4, con los valores que vemos arriba a la izquierda.
Tras reiniciar ambas mquinas compruebo que estas se ven en la red interna entre s y con el servidor (las tres MV corriendo a la vez sobre OpenSuse 13.01).
SUBU14 ve a UBU14
UBU14 ve a SUBU14
9/44
SUBU ve a WIN7PRO
UBU14 ve a WIN7PRO
WIN7PRO ve a SUBU
WIN7PRO ve a UBU14
Sin embargo falta algo para que nuestro servidor funcione correctamente, como vemos en las imgenes, los equipos de la red no tienen acceso al router ADSL y
por tanto tampoco a Internet a travs del servidor. Para solucionarlo es necesario configurar el FireWall del servidor.
10/44
10.3 Configuracin del FireWall (iptables).

Antes de empezar con la configuracin del FireWall voy a introducir un poco de teora que nos ayudar a comprender mejor los pasos que vamos a dar.
Como ya coment anteriormente, Linux puede funcionar como host-terminal o como router sin mas que cambiar el switch 'ip_forward' a 'true'. En ese caso los
paquetes que lleguen al servidor por cualquiera de sus interfaces de red: se las quedar el SO del servidor si van dirigidas a stas (10.0.0.1/24 o 192.168.1.2 en nuestro
caso), las encaminar por las rutas definidas en la FIB si su destino coincide con alguna, o por ltimo las desechar si no se da ninguna de las dos condiciones anteriores.
Pero, para que esto suceda, adems los paquetes deben de satisfacer las reglas establecidas en las diferentes tablas del FireWall, las llamadas iptables.
En concreto son cuatro por lo general: filter (filtros), nat(networks address translation), mangle y raw. En nuestro caso debemos conocer bien el funcionamiento
de filter y nat.
La tabla filter se estructura en tres cadenas chains de reglas:
La cadena de reglas INPUT que son las que se aplicarn sobre todos los paquetes que entran en la mquina
por cualquiera de las interfaces y tienen como destino la mquina local. En nuestro caso todo lo que
vaya a 10.0.0.1/24 o 192.168.1.2.
La cadena de reglas OUTPUT que son las que se aplican sobre todos los paquetes generados en la mquina
y que salen por cualquiera de sus interfaces.
La cadena de reglas FORWARD que son las que se aplican sobre todos los paquetes que no tienen ni como
origen ni como destino la mquina local, es decir, estn de paso.
La tabla nat se articula con el fin de traducir, por la tcnica del enmascarado MASQUERADE, los paquetes que viajan entre distintos tipos de redes. Con el fin
de que de forma transparente un paquete que tiene un tipo de direccionamiento en su red de origen pueda llegar a un destino con otro tipo de direccionamiento. Es decir
nat traduce la direccin en la red tipo 1 a una direccin en la red tipo 2 aadiendo una mscara (envoltorio) a los paquetes o datagramas.
En nuestro caso en concreto no estamos moviendo paquetes entre dos redes de diferente tipo, sin embargo vemos como desde los hosts de la red interna no
podemos acceder a Internet. Esto se produce porque una direccin de red privada no es lcita en Internet y por tanto nuestros paquetes deben ser enmascarados con una ip
pblica.
Nat toma la ip pblica del router ADSL, al cual accede a travs de la puerta de enlace (192.168.0.1/24) y con sta enmascara los paquetes para que puedan salir a
internet. Esto lo hace el nat del propio router ADSL cuando accedemos a Internet y en nuestro caso tambin el nat del servidor.
Para ello la tablas nat cuentan con tres cadenas de reglas:
La cadena de reglas OUTPUT que son aplicadas a los paquetes generados localmente que deben ser enmascarados para ser enrutados.
La cadena de reglas PREROUTING que son aplicadas a los paquetes que deben ser enmascarados antes de ser enrutados.
La cadena de reglas POSTROUTING que son aplicadas a los paquetes que deber ser enmascarados despus de ser enrutados.
As los paquetes que entran en una cadena de reglas van siendo filtrados segn la regla con la que coincidan y enmascarados siguiendo el mismo criterio.
11/44
La estructura de cada eslabn o regla de una cadena es:
En este caso estamos viendo la tabla filter de la mquina anfitrin (OpenSuse 13.1). La idea es que los paquetes segn su origen y destino van a entrar en una
cadena de reglas (cadena INPUT, cadena OUTPUT, cadena FORWARD, cadenas definidas por nosotros como input_ext o reject_func) y segn su protocolo, origen y
destino sern lanzados hacia el objetivo (target) del eslabn de la cadena de reglas con la que coincidan. Si no coinciden con ninguna regla de su cadena entonces se
lanzan por lo que se llama poltica de la cadena (policy) que por defecto siempre es ACCEPT.
As los posibles objetivos a los que se puede lanzar un paquete es a otra cadena (por ejemplo de INPUT a input_ext que es una extensin creada por el usuario) o
a los objetivos especiales ACCEPT=aceptar paso del paquete, DROP=desechar el paquete, QUEUE, RETURN, LOG, REJECT=rechazar el paquete,
MASQUERADE=enmascarar el paquete.
12/44

En la imagen a la izquierda podemos ver la estructura de la tabla nat de la
mquina anfitrin, que por poltica lo acepta todo, como corresponde a una
mquina que no es router sino host terminal.
Ahora que entendemos
como funciona el FireWall tendremos que
configurarlo correctamente en nuestro servidor virtual para que los paquetes de
la red interna 10.0.0.0/24 puedan salir a Internet pasando por el servidor.
Para ello en principio exploro el contenido de las tablas filter y nat con ayuda del comando 'iptables'.
La opcin '-t' me permite seleccionar la tabla a ver, en este caso 'filter' y 'nat'. La opcin '-L' indica que
muestre la tabla en formato lista y la opcin '-S' que la muestre en formato tal y como est almacenada en el
archivo.
Podemos observar como solo estn establecidas las polticas por defecto de cada cadena de 'filter' y
'nat', todas en 'ACCEPT'.
Por esta razn nuestro paquetes no llegan al router ADSL, puesto que no hay ninguna regla en nat que
los enmascare. Debemos entonces aadir una regla de enmascarado a nat para que los paquetes puedan salir
a Internet. Para ello hago uso del comando 'iptables' como vemos en la imagen a continuacin.
Con la opcin '-t' selecciono la tabla 'nat', con la opcin

'-A' indico aadir (append) una nueva regla al final de una cadena
de reglas. En este caso indico la cadena 'POSTROUTING',
afectar por tanto a paquetes ya enrutados. Con la opcin '-S'
incido el origen (source) de los paquetes a enmascarar, que en nuestro caso son los que vienen de la red interna 10.0.0.0./24. Con la regla '-d' indico el destino
(destination) de los paquetes a enmascarar, que en nuestro caso son los que van a Internet y por tanto no sabemos su destino a priori, es decir, todos 0/0. Puesto que los
que vayan al servidor se los quedar l. Y por ltimo con la regla '-j' indico el objetivo (target) al cual deben saltar (jump) los paquetes, que en nuestro caso es al objetivo
Masquerade.
13/44
Tras aplicar el comando vuelvo a explorar la nat y en efecto los cambios se ven reflejados (ojo, a nivel de cach, al reiniciar se pierden).
Los cambios adems de reflejarse en las tablas deben surtir su efecto, para comprobarlo hago 'ping' desde la mquina UBU14, host de la red interna, al router
ADSL y a un DNS de Google. Y en efecto el nat ahora si est haciendo su trabajo y enmascarando los paquetes correctamente.
14/44
Si esto es as, entonces debemos poder acceder desde un host de la red interna a explorar la Web.
Para ello realizo una bsqueda y en efecto, parece que funciona.

Pero como ya he comentado estos cambios solo estn en cach y al apagar la mquina los
perderamos. Es necesario guardarlos en un archivo que llamaremos iptables.rules y en el que
haremos un volcado del cach con 'iptables-save', tal y como se aprecia en la imagen.
El contenido del archivo una vez volcado lo apreciamos en la imagen de la izquierda.
15/44
Ya tenemos la nueva regla del nat volcada en el fichero '/etc/iptables.rules'.

Necesitamos ahora que al reiniciar la mquina todo su contenido se cargue en
cach del ncleo del SO para que el FireWall haga uso de las reglas.
Para este fin modificamos el fichero '/etc/network/interfaces' e indicamos que
queremos pre-cargar (pre-up) el contenido de '/etc/iptables.rules' en cach, con el
comando 'pre-up' y 'iptables-restore'.
Tras guardar los cambios en '/etc/network/interfaces' reinicio el servidor y compruebo que en el

arranque se cargan los datos de configuracin en '/etc/iptables.rules'.
Y como se puede apreciar en la imagen de la izquierda se han cargado tal y como se configur.
Recordemos que nuestro servidor va a funcionar como router, para ello ya hemos configurado el enrutador y el nat, pero una de las partes mas importantes es la
seguridad y esto hasta el momento no se ha controlado. Para hacer que nuestro servidor sea seguro debemos aadir reglas de seguridad al cortafuegos, en concreto a la
tabla 'filter'. Esto lo hacemos nuevamente trabajando con el comando 'iptables'.
En concreto nos interesa controlar el trfico de red entrante (cadena INPUT) y el trfico de red pasante (cadena FORWARD), que como se observa en la imagen
anterior la poltica por defecto es la de aceptar todo.
Hay muchas formas de controlar y establecer reglas para el FireWall, en mi caso he optado por la opcin mas conservadora. Es decir, cambiar la poltica por
defecto del trfico pasante a desechar todo por defecto y luego aadir reglas o abrir los puertos de todo aquello que nos interese.
16/44
El trfico pasante por defecto se va a desechar. Es decir,

'-P' = policy va a 'DROP'.
Ahora mismo no podr pasar ningn paquete de informacin desde fuera del servidor hacia la red interna 'FORWARD'.
Para solucionarlo indicamos de forma precisa que paquetes podrn pasar segn su origen, destino, protocolo, puerto, etc.
En la imagen arriba se puede observar como he abierto los puertos para los protocolos necesarios para que funciona: http, https, ftp, sftp, ssh, pop3, spop3, imap,
imaps, etc.
Una vez modificada la estructura de filter la guardamos en '/etc/iptables.rules' para que en el reinicio del sistema se vuelva a cargar la configuracin del
FireWall.
17/44
Tras establecer la configuracin del FireWall exploro la tabla filter para ver como ha quedado (imagen arriba a la izquierda) y hago 'ping' desde un host de la
red interna a un DNS de Google y a la red 192.168.1.0/24, en concreto al router ADSL. Para mi sorpresa me encuentro con que el FireWall tal y como lo he configurado
me permite hacer ping a 8.8.8.8 y sin embargo no a 192.168.1.1.
Tras consultar algunos manuales, la conclusin es que el comando 'ping' funciona bajo el protocolo ICMP que no hemos habilitado. Por esto los 'ping' a la red
192.168.1.0/24 no funcionarn a menos que habilite el protocolo, si lo harn los que salen al exterior 8.8.8.8, ya que estos pasan a travs de nat.
Permito el trfico pasante desde ('-s') la red interna (10.0.0.0/24) del protocolo ('-p') ICMP, el cual se usa para hacer un ping.
18/44
Una vez hecho esto guardo la configuracin actual, en cach, de filter y nat con 'iptables-save al archivo '/etc/iptables.rules'. Y como siempre hago pruebas
para ver que todo funciona correctamente. En este caso uso el host de la red interna con Windows 7.
Hago 'ping' al router ADSL y todo funciona.

Salgo a la Web y buco algo y tambin funciona.
Llegados a este punto podemos asegurar que nuestro servidor est configurado como router-firewall, dando acceso a Internet a nuestra red interna MiRedDam.
Por tanto el esquema actual de la red es el siguiente:
Vemos como la ip en la eht0 ahora es la 192.168.1.2/24 y el servidor est representado como router y firewall.
19/44
10.3.1 Configuracin de Samba.

Aunque en la tarea no se pide especficamente configurar Samba, si se podra decir que de forma implcita. Ya que para mover ficheros entre la red interna y el
servidor o entre el los hosts de la red interna necesitamos que Windows y Linux se entiendan.
Instalo Samba en el servidor.
Aado el usuario juan a Samba, ya que tambin esttica

como usuario en el sistema. Tras aadirlo exploro la BBDD
de Samba para ver que se ha aadido.
Con 'chkconfig' vemos que no se cargar

el servicio en el arranque.
Ejecuto 'chkconfig para que se cargue

el servicio al arrancar el SO.
Creo en el servidor la carpeta '/compartida' que ser compartida con la red

interna.
Cambio de propietario y de grupo la carpeta '/compartida' y juan, ya que este usuario tiene cuenta en los hosts de la red interna y as podr tener derechos
lectura, escritura y exploracin de la carpeta.
20/44
Para poder compartirla en la red, debemos indicar al SO que la comparta, esto se puede hacer desde la terminal de comandos, o desde el entorno grfico. En este
caso lo he hecho desde el entorno grfico aunque se podra con cnf shared desde la consola de comandos.
Desde el entorno grfico tenemos la posibilidad de hacer click con el botn derecho del ratn sobre la carpeta y se despliega el men contextual de la imagen
arriba a la izquierda. O desde la aplicacin Comparticin de carpetas. Ambas dan el mismo resultado.
En la imagen arriba a la izquierda vemos como aparece la carpeta ya como compartida. Por otra parte adems de compartirla en el SO lo que har que se pueda
ver y utilizar desde el host de la red interna con Ubuntu 14.04 (como el servidor, se vern por NFS), tambin lo debemos indicar en Samba en su archivo de
configuracin '/etc/samba/smb.conf' para que sea accesible desde el host con Windows 7. En este caso he editado el archivo con nano, un pequeo editor de consola de
comandos. En la imagen arriba a la derecha vemos el contenido del archivo y la carpeta compartida que he aadido indicando su ruta, comentario, usuarios autorizados y
derechos de los mismos sobre la carpeta.
21/44
No as para el host con Ubuntu, pero si para el host con Windows 7, es necesario estar en el mismo dominio o grupo de trabajo en nuestro caso. Para ello en el
host Windows establezco el grupo de trabajo con el nombre ARAA y en Samba edito el fichero '/etc/samba/smb.conf' y tambin lo aado al mismo grupo de trabajo.
Realizados y guardados los cambios reinicio el servicio samba para que los cambios surtan efecto.
Una vez mas compruebo que todo ha ido bien, para ello exploro la red desde el host con Windows 7 y en la imagen arriba a la izquierda vemos como se ve el
servidor SUBU14 y como explorando el servidor, en la imagen de la derecha, se ve la carpeta compartida.
22/44
Por ltimo intento acceder a la carpeta haciendo doble click y se despliega el logging de la imagen arriba a la izquierda. Introduzco los datos y la contrasea
configurados para el usuario juan en Samba y vemos el contenido de la carpeta compartida. Para comprobar que funciona todo creo una carpeta en el servidor y un
archivo en el host con Windows 7 y ambas se ven desde los dos SO.
23/44
10.4 Configuracin de Apache:

Una vez que nuestro servidor est bien configurado, da salida a Internet a los hosts de la red interna enrutando el trfico correctamente y haciendo de FireWall.
Podemos entonces configurarlo para que preste servicios a los hosts de la red interna. En este caso en concreto queremos que sirva pginas Web, para ello instalaremos el
servidor Web Apache2.
Instalo Apache2 con 'apt'.
Con 'chkconfig' hacemos que el servicio se inicia en el arranque. Vemos como el servicio 'apache2' ha quedado configurado para arrancar cuando arranque el SO.
Reinicio el equipo y a partir de este momento el servidor Web Apache2 est a la escucha en el puerto lgico 80 de cualquier peticin web que entre por cualquiera
de las dos Interfaces de red eth0, eth1 o desde dentro del propio servidor.
Para comprobar que esto es as podemos hacer una exploracin con un navegador web, bien desde el mismo servidor, desde la red interna (10.0.0.0/24), desde la
red perimetral (192.168.1.0/24) o desde el exterior.
Para intentarlo desde el exterior deberamos atacar la ip pblica del router ADSL (80.0.254.190:80) por el puerto 80. No habra que hacer nada en mi mquina
anfitrin porque la iface externa del servidor virtual utiliza la iface de la mquina anfitrin como puente (adaptador-puente) para llegar al router ADSL.
Abrir el puerto 80 en el router ADSL y redirigir el trfico de dichos paquetes a la ip externa del servidor virtual(192.168.0.2/24).
Para intentarlo desde la red perimetral podramos hacerlo con cualquier equipo conectado al router ADSL atacando la ip externa del servidor
virtual(192.168.1.2:80) por el puerto 80. Y reitero, no habra que hacer nada en mi mquina anfitrin porque la iface externa del servidor virtual utiliza la iface de la
mquina anfitrin como puente (adaptador-puente) para llegar al router ADSL.
Para intentarlo desde la red interna atacaramos la ip interna(10.0.0.1:80) del servidor virtual por el puerto 80 desde cualquier mquina de la red interna
MiRedDam.
Por ltimo, para intentarlo desde el propio servidor virtual atacaramos la mquina local (localhost:80) por el puerto 80.
24/44
Muestro capturas de lo comentado anteriormente:
En la imagen arriba a la izquierda accedemos desde una mquina en la red

perimetral, en concreto la (192.168.1.37/24) con OpenSuse 13.01. Se trata de la
mquina anfitrin.
En la imagen de arriba a la derecha accedemos desde el host UBU14 en la
red interna con ip (10.0.0.100/24) y con Ubuntu 14.04.
En la imagen a la derecha accedemos desde el otro host de la red interna
WIN7 en (10.0.0.110/24) con Windows 7.
25/44
Con el servidor Apache configurado y funcionando correctamente, hago una sencilla pgina web con el siguiente cdigo.
En la imagen arriba a la izquierda podemos ver el cdigo de la pgina

web que guardamos en '/var/www/html/pweb.html' junto con la imagen que se
muestra.
En la imagen arriba a la derecha accedemos desde un host de la red
perimetral con Ubuntu-Gnome 12.02 en (192.168.1.34), se trata del equipo de
mi mujer.
En la imagen a la derecha accedemos desde una mquina en la red
perimetral, en concreto la (192.168.1.37/24) con OpenSuse 13.01. Se trata de
la mquina anfitrin.
26/44
Accedo desde el propio servidor a explorar pweb.html
Accedo desde el host de la red interna UBU14 (10.0.0.100/24) con Ubuntu 14.04
Desde el editor nano modifico el cdigo de la pgina y accedo a ella desde el otros host de la red interna, el WIN7 en (10.0.0.110/24) con Windows 7.
27/44
Como se puede observar se puede acceder correctamente desde diferentes redes al servidor Web.
Sin embargo, he querido extender un poco este punto de la tarea para ilustrar como quedara el servidor web protegido detrs del FireWall en la red perimetral.
Para ello suspendo el servicio web Apache2 en el servidor virtual e instalo el servidor web Apache2 en el host de la red interna (10.0.0.100/24).
Con 'apt' descargo e instalo el servidor Apache2 y lo configuro par que se inicie al
arrancar la mquina.
Adems exploro la carpeta donde alojaremos la pgina web y vemos que al
instalarse tan solo est index.html, que es la que se muestra por defecto.
Para comprobar que los cambios funcionan podemos hacer una exploracin con un navegador web, bien desde el mismo servidor web, desde la red interna
(10.0.0.0/24), desde la red perimetral (192.168.1.0/24) o desde el exterior.
Para intentarlo desde el exterior deberamos atacar la ip pblica del router ADSL (80.0.254.190:80) por el puerto 80. No habra que hacer nada en mi mquina
anfitrin porque la iface externa del servidor virtual utiliza la iface de la mquina anfitrin como puente (adaptador-puente) para llegar al router ADSL.
Abrir el puerto 80 en el router ADSL y redirigir el trfico de dichos paquetes a la ip externa del servidor virtual(192.168.0.2/24).
Ahora debemos tener en cuenta que el servidor Apache2 no est en el servidor virtual SUBU14, con lo cual cuando SUBU14 reciba paquetes con destino al
puerto 80 debemos indicarle como y a donde debe enviarlos para que no los deseche y lleguen al servidor Apache2 montado en la red interna.
Para ello hacemos uso del objetivo Destination Network Address Translation DNAT, que tomar los paquetes entrantes en la eth0 del servidor virtual que vayan
por el protocolo 'tcp' y como puerto de destino tengan el 80 y los reenviar a (10.0.0.100:80), cambindole la ip de destino a (10.0.0.100/24). Es lo que se llama hacer
NAT en el destino o DNAT.
Es interesante saber que esto ya lo ha hecho previamente el router ADSL cuando recibe la peticin http://80.0.254.190:80/pweb.html. Como acabo de comentar
he abierto el puerto 80 en el router ADSL y lo he configurado para que reenve a (192.168.1.2:80) a travs de su ip interna (192.168.1.1/24).
28/44
En definitiva el router ADSL ha hecho DNAT a (192.168.1.2:80) y el servidor virtual que funciona como router-firewall har otro DNAT a (10.0.0.100:80) de los
paquetes que entran por la eth0 con puerto de destino 80 envindolos por la eth1 a (10.0.0.100/24).
La forma en la que vamos a indicar al servidor virtual que haga DNAT es haciendo uso del comando 'iptables' como se puede apreciar en la siguiente imagen.
Le indicamos que antes de ser enrutados, los paquetes provenientes de la eth0 que tienen destino el puerto 80 (destination port= dport) con en protocolo tcp los
lance al objetivo DNAT que les cambiar el destino a la (10.0.0.100:80). Tras salir de DNAT los paquetes sern enrutados por el router del SO a dicha ip a travs de la
eth1 del servidor virtual(puesto que as est configurado con 'route').
Para intentarlo desde la red perimetral podramos hacerlo con cualquier equipo conectado al router ADSL atacando la ip externa del servidor
virtual(192.168.1.2:80) por el puerto 80. Y reitero, no habra que hacer nada en mi mquina anfitrin porque la iface externa del servidor virtual utiliza la iface de la
mquina anfitrin como puente (adaptador-puente) para llegar al router ADSL. En este caso DNAT y el router del servidor virtual harn su trabajo y lo mandarn todo
por la eth1 del servidor virtual con destino a (10.0.0.100:80).
Para intentarlo desde la red interna atacaramos la ip interna(10.0.0.100/24) del servidor web por el puerto 80 desde cualquier mquina de la red interna
MiRedDam.
Por ltimo, para intentarlo desde el propio servidor web atacaramos la mquina local (localhost:80) por el puerto 80.
En las imgenes a continuacin podemos ver como tras haber instalado Apache2 en el host (10.0.0.100/24) de la red interna a la escucha en el puerto 80 y tras
haber reconfigurado el FireWall del servidor virtual para que reenve las peticiones del puerto 80 a este host, todo parece funcionar correctamente.
29/44
Accediendo desde la red perimetral, en este caso el propio servidor virtual SUBU14.
En la imagen de arriba se puede observar el servidor virtual SUBU14, a la izquierda, accediendo a (10.0.0.100:80). Y en la mquina de la derecha vemos el host
virtual de la red interna UBU14 accediendo al servidor web en la mquina local.
30/44
10.4.1 Servidor DHCP:

Al igual que la segunda parte del anterior punto he decidido instalar el servidor DHCP con el fin de ilustrar su configuracin y uso.
Ojo (el servidor Apache2 en el servidor virtual ha sido restituido y he desactivado el que instal en el host UBU14 de la red interna).
Exploro el sistema con el fin de ver si hay algn servicio DHCP ya instalado, para ello simplemente escribo el comando 'dhcp' o 'dhcpd' y observo en la imagen
arriba a la izquierda como no est instalado. Adems es habitual que Linux sugiera una serie de paquetes a descargar en los que se encuentra la herramienta deseada, es
este caso DHCP.
Siguiendo las sugerencias instalo el servidor DHCP como se muestra e la imagen arriba a la derecha.
Una vez instalado compruebo que el sistema de inicio en el arranque lo reconoce y adems est configurado a off en el nivel 5 de ejecucin que es en el que
corre el sistema por defecto. Por otro lado exploro la carpeta de configuraciones y veo que al instalarse se ha creado una creado una carpeta para DHCP.
31/44
En su interior encuentro el archivo dhcpd.conf en el cual se establecen los

parmetros por los que se regir el servidor para asignar de forma automtica las
direcciones, dominios, DNS's, tiempo de uso de una determinada ip y establecer
rangos de direcciones. Todo esto se puede apreciar en la imagen a la derecha.
Donde he establecido el dominio grupo de trabajo en nuestro caso como
ARAA, los DNS's de Google, 86.400 segundos (dos das) como tiempo de uso
o caducidad de un misma ip, creo la sub red (10.0.0.0/24) y defino el rango de
direcciones desde la (10.0.0.15/24-10.0.0.254/24) con los DNS's de Google y grupo
de trabajo ARAA, dos das de caducidad para las ip y la puerta de enlace o
gateway en (10.0.0.1/24).
Una vez almacenados los cambios en la configuracin intento lanzar el servicio y lo

lanzo con el demonio 'dhcpd'. Donde se puede apreciar (imagen a la izquierda) que algo
no est bien configurado. Tras releer el archivo de configuracin y consultar alguna web
doy con el error.
32/44
El problema est en que no puedo iniciar el servicio directamente a travs de el

demonio 'dhcpd'. Hay que hacer uso del script que se crea en '/etc/default/isc-dhcpserver'.
El cual debo configurar previamente para apuntar la variable DHCP_CONF a
'/etc/dhcp/dhcpd.conf' y la variable INTERFACES sobre las que va a servir
direcciones en 'eth1'.
Guardo los cambios y paro y reinicio el servicio para que tome la nueva
configuracin y ahora parece que todo ha ido bien.
Una vez mas vemos que el servicio hace su trabajo correctamente. Para ello reconfiguro ipv4 en el host de la red interna con Windows7 y lo pongo todo en
dinmico, como se aprecia en las imgenes a continuacin.
Paso la conf. esttica a dinmica y vemos como el servidor DHCP ha hecho su trabajo, puesto que hay red y conexin a Internet.
33/44
Desde la consola de comandos de Windows con el comando 'ipconfig'

despliego la configuracin y en efecto el servidor DHCP ha asignado la ip
(10.0.0.15/24) y la puerta de enlace o gateway (10.0.0.1/24) tal y como estaba
figurado y previsto.
Compruebo adems que tengo acceso a Internet explorando la Web y
accediendo adems a la pgina web creada en el servidor virtual y que sirve Apache2.
Comentar por ltimo que en el caso de querer tomar direccionamiento dinmico en el host UBU14, no tendramos mas que acceder a '/etc/network/interfaces' y
comentar la configuracin actual de la eth0 salvo auto eth0 y aadir la lnea iface eth0 inet dhcp. De esta forma ya tomar una ip servida por el serv. DHCP.
34/44
10.5.1 Acceso remoto al servidor por VNC.

Otro servicio muy importante en el mundo de los servidores Linux es el de el acceso remoto, el cual nos permite controlar el servidor de forma remota tanto en
modo consola-terminal como en modo grfico. En este caso vamos a ver la instalacin del servidor VINO y del cliente VINAGRE que funcionan por VNC.
Descargo e instalo el servicio VINO con tightvncserver

en el servidor SUBU14.
Configuro el password que se solicitar a los clientes al intentar
conectar al servidor.
Instalo el cliente VINAGRE en el host UBU14 de la red
interna.
Arranco el servidor 'vncserver'.
Ejecuto el Visor de escritorio remoto desde UBU14.
Haciendo click en conectar indico la ip del servidor VINO y el puerto

por el que se mantiene a la escucha el 5900.
35/44

Hago click en el botn conectar de la ventana arriba a la derecha y se nos
muestra la imagen a la izquierda. Donde se nos solicita la clave de acceso al servidor
VNC. Introduzco la clave y hago click en el botn Autentificar y la pantalla que est
en negro que debera mostrar el escritorio remoto, se muestra de color gris.
A la vista de los resultados indago en la Web y encuentro una posible solucin que me
indica que vaya a Comparticin de escritorio en el servidor SUBU14 y permita a otros
usuarios ver el escritorio. Adems hago que el usuario tenga que poner una clave para ver el
escritorio.
Realmente este proceso es el mismo que se hace con vncpasswd y algn otro paso
que no he controlado para poder indicar desde consola de comandos el compartir escritorio.
Adems de esto el tutorial consultado me indica que ser necesario activar el acceso remoto de la aplicacin de escritorio. Lo cual se puede hacer desde el entorno
de escritorio con la herramienta dconf-tools, que simula una especie de lo que sera el gestor del registro en Windows (regedit).
Descargo e instalo dconf-tools con 'apt', la
Ejecuto deconf.
36/44
En la imagen de la izquierda podemos ver como al

ejecutar dconf se muestra un rbol con las aplicaciones
instaladas en el sistema. Debemos expandir el nodo de
aplicaciones del escritorio y en su interior tenemos la
clave llamada remote-access y su contenido se muestra
en la parte derecha de la ventana. El acceso remoto al
escritorio se encuentra deshabilitado, es decir, enabled a
false. Lo chequeo a truey cierro la aplicacin.
Sin duda alguna debe haber algn fichero en '/etc/' donde
se pueda modificar todos estos parmetros de forma directa a
travs de la consola de comandos. Pero lo cierto es que
actualmente desconozco de que fichero se trata.
Cierro la terminal :1 con el comando 'vncserver -kill :1' y vuelvo a lanzar una nueva terminal.
Se lanza nuevamente la :1 porque est libre. Recordemos que el servidor lanzar una nueva terminal
remota en cada llamado con 'vncserver'. Despus de la :1 lanzar la :2 y as sucesivamente.
Podremos por tanto conectarnos con varios terminales de forma remota al mismo servidor.
En el host de la red interna UBU14 vuelvo

a ejecutar la aplicacin de visor de
escritorio remoto.
37/44

Al igual que antes con el botn conectar se despliega el dilogo que nos pide elegir un
servidor VNC. Pongo el 10.0.0.1:5900 servidor SUBU14 en el puerto 5900, que es el
puerto de la terminal :1.
Hago click en conectar y como se puede observar en la imagen de abajo se pone la
pantalla en color negro y en el escritorio de SUBU14 se solicita permiso para que un cliente
VNC pueda acceder.
Hago click en permitir y se muestra la imagen que podemos ver a continuacin.

38/44
En la ventana de Vinagre vemos el fondo de escritorio de SUBU14. Cuando muevo el ratn por la ventana del escritorio remoto (UBU14) se observa como se
mueve en el escritorio de SUBU14. Sin embargo no puedo ver la barra vertical Dash de aplicaciones. Aunque si me acerco al borde izquierdo y hago click se ejecuta la
correspondiente aplicacin en SUBU14.
He intentado diferentes configuraciones de comparticin sin xito. Y ojeando la Web he visto en algn foro que el problema podra estar en VirtualBox. Es
decir, sera un problema causado por la configuracin o drivers de VB.
39/44
10.5.2 Acceso remoto al servidor por SSH.

Como ya coment en el punto anterior, se trata del modo de gestin remota habitual en servidores Linux. Secure Shell o Herramienta Segura es una herramienta
para la gestin remota de forma segura, ya que los datos viajan encriptados.
Tras instalar la herramienta, reinicio el SO y ejecuto el script

'/etc/init.d/ssh start' para iniciar el servicio de SSH.
Descargo e instalo la herramienta con el comando 'apt'. En este caso
tras probar con las herramientas recomendadas en los apuntes y ver que hay
un problema de compatibilidad (puesto que esta versin de Ubuntu es posterior),
consulto la Web, donde se indica openssh como la herramienta adecuada.
En esta ocasin decido acceder de forma
remota al servidor SUBU14 desde la red perimetral
(192.168.1.0/24) donde se encuentra el router ADSL,
el propio servidor SUBU14, el equipo de mi mujer y
ste mismo equipo, es decir, la mquina anfitrin que
desde el punto de vista lgico es un host mas en la red
perimetral. Por tanto accedo desde la mquina
linux-u2wz que es la mquina anfitrin y desde la
terminal de comandos del entorno grfico me conecto
a SUBU14 con el cliente SSH escribiendo el
comando 'ssh juan@192.168.1.2' . Es decir, le indico
el usuario y la ip del servicio SSH. Tal y como se ve
en la imagen a la derecha el servidor solicita la clave
del usuario juan que ya existe en el sistema del
servidor.
40/44
Tras indicar la clave el servidor nos muestra, en el terminal remoto, un mensaje de bienvenida y nos informa de la ltima conexin, que fue una prueba previa
desde esta misma mquina (192.168.1.37 = servido por el dhcp del router ADSL = mquina anfitrin). Esto lo podemos observar en la captura arriba a la izquierda.
En la captura a la derecha se ve como exploro el HOME del usuario juan en SUBU14.
Como siempre, hago algunas pruebas para comprobar el correcto funcionamiento de la herramienta. Como se aprecia en la imagen arriba entro en el directorio
Escritorio y exploro su contenido. Donde se ve claramente, en la imagen arriba, que su contenido corresponde a lo que se refleja en el escritorio de SUBU14.
41/44
Ahora con 'mkdir' creo una carpeta, la cual de forma inmediata se muestra en el escritorio remoto (SUBU14). Se trata de la carpeta Carpeta_desde_anfitrin
como se aprecia en la imagen de arriba.
De la misma forma con el comando 'rmdir', elimino la carpeta y de forma inmediata desaparece del escritorio de SUBU14 y del directorio Escritorio.
42/44
Para ir un poco mas all, me logueo como super usuario (imagen arriba a la izquierda) y no se presenta ningn problema. En la imagen arriba a la derecha se ve
como monitorizo la configuracin de los servicios en el arranque del SO. En concreto busco que se cargue en el arranque Apache2 a modo de ilustracin de lo que
puede ser una tarea de gestin remota des servidor.
En la imagen arriba vemos como ejecuto el editor de textos por consola de comandos nano y escribo un texto. Se trata de otra de las tareas habituales de los
administradores de sistemas, es decir, escribir scripts que se ejecutarn al reiniciar el servidor y que puede servir por ejemplo para automatizar una tarea determinada.
43/44
Como se observa en la imagen a la derecha al hacer

Ctrl+O en nano para guardar el documento, indico la ruta
'/home/juan/Escritorio/doc-desde-anfitrion' y de forma
inmediata al hacer enter vemos el icono del archivo en el
escritorio de SUBU14.
Para terminar de comprobar que todo funciona correctamente compruebo que la

desconexin funciona. Para ello uso el comando 'exit'. Podemos observar como la consola
retoma la terminal de la mquina anfitrin.
44/44

FireWall-Router Linux-Ubuntu

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FireWall-Router Linux-Ubuntu

Uploaded by

Copyright:

Available Formats

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Administracin de la red (Linux III)

Configuracin de las mquinas virtuales.

Configuracin del Servidor (servidor con dos ifaces de red SUBU14 ).

Configuracin de los host de la red interna (mquinas virtuales en MiRedDam ).

10.3.1 Configuracin de Samba.

Instalacin de Apache2 (servidor Web).

Acceso remoto al servidor . . .

10.5.1 . . . por VNC.

10.5.2 . . . por SSH.

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Host Vitual Linux Ubuntu 14.04

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

10.0 Configuracin de las mquinas virtuales.

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

10.1 Configuracin del Servidor.

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Esto es tan simple como editar el fichero y des-comentar la lnea con el

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

10.2 Configuracin de los hosts en la red interna.

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

10.3 Configuracin del FireWall (iptables).

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

La estructura de cada eslabn o regla de una cadena es:

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Con la opcin '-t' selecciono la tabla 'nat', con la opcin

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Para ello realizo una bsqueda y en efecto, parece que funciona.

El contenido del archivo una vez volcado lo apreciamos en la imagen de la izquierda.

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Ya tenemos la nueva regla del nat volcada en el fichero '/etc/iptables.rules'.

Tras guardar los cambios en '/etc/network/interfaces' reinicio el servidor y compruebo que en el

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

El trfico pasante por defecto se va a desechar. Es decir,

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

Hago 'ping' al router ADSL y todo funciona.

Tema 10: Administracin de la red (Linux III)

Sistemas Informticos 1 DAM

10.3.1 Configuracin de Samba.