Diseno e implementacion del sistema de

gestion de redes wireless con portal cautivo.

Autor: Avila Correas, Javier
Director: Roma i Frigole, Francesc
Ponente: Serral Gracia, Rene
Departamento: TI

Fecha de defensa: 30/06/2014

1
Indice

1 Introduccion 5
1.1 Motivaciones del proyecto . . . . . . . . . . . . . . . . . . . . 6
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Estructura . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Vision general 9
2.1 El producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 El sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 El proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Estudio de la situacion inicial 14

3.1 Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Repositorios y developers . . . . . . . . . . . . . . . . . . . . . 19
3.4 Esquema con repositorios . . . . . . . . . . . . . . . . . . . . . 20
3.5 Conclusiones sobre la situacion inicial . . . . . . . . . . . . . . 21

4 Tecnologas 23

5 Objetivos de la reestructuracion y ampliacion 26

5.1 Consistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Escalabilidad y flexibilidad . . . . . . . . . . . . . . . . . . . . 26
5.3 Estabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4 Fiabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.5 Amortizacion de costes . . . . . . . . . . . . . . . . . . . . . . 27
5.6 Recuperacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.7 Portabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Implementacion 28
6.1 Analisis de las plataformas existentes. . . . . . . . . . . . . . . 28
6.1.1 Servers fsicos . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.2 Amazon Web Services . . . . . . . . . . . . . . . . . . 29

2
 6.1.3 Telefonica Cloud Computing . . . . . . . . . . . . . . . 30
6.2 Eleccion de la plataforma . . . . . . . . . . . . . . . . . . . . . 31
6.3 Servidores Amazon Controler Unifi . . . . . . . . . . . . . . . 31
6.3.1 Introduccion al servidor Unifi . . . . . . . . . . . . . . 31
6.3.2 Objetivos y soluciones . . . . . . . . . . . . . . . . . . 32
6.3.3 Implementacion . . . . . . . . . . . . . . . . . . . . . . 33
6.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4 Server Develop . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4.2 Objetivos y soluciones . . . . . . . . . . . . . . . . . . 34
6.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.5 Ampliacion develop . . . . . . . . . . . . . . . . . . . . . . . . 35
6.5.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . 35
6.6 Previo migracion del servidor de produccion . . . . . . . . . . 36
6.6.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . 36
6.6.2 Migracion de base de datos . . . . . . . . . . . . . . . 37
6.6.3 Migracion de codigo . . . . . . . . . . . . . . . . . . . 39
6.6.4 Migracion de radiator . . . . . . . . . . . . . . . . . . . 39
6.6.5 Migracion de los servidores . . . . . . . . . . . . . . . . 40
6.7 Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.1 Analisis . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.2 Implementacion . . . . . . . . . . . . . . . . . . . . . . 41
6.7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.8 Replicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.9 HTTPS, SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . 43
6.10 Administracion de los dispositivos . . . . . . . . . . . . . . . . 45
6.10.1 Eleccion del tunel . . . . . . . . . . . . . . . . . . . . . 47
6.10.2 Implementacion . . . . . . . . . . . . . . . . . . . . . . 50
6.11 Monitorizacion de servidores . . . . . . . . . . . . . . . . . . . 51
6.12 Servicio generador de graficas . . . . . . . . . . . . . . . . . . 52
6.13 Automatizacion de servidores . . . . . . . . . . . . . . . . . . 54
6.13.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . 54
6.13.2 Chef . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3
 6.13.3 Recipes . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.14 AutoProvisionamiento . . . . . . . . . . . . . . . . . . . . . . 59
6.15 DenyHosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Estudio economico 63
7.1 Calculo de rentabilidad . . . . . . . . . . . . . . . . . . . . . . 63

8 Conclusiones 65

9 Bibliografa 67

10 Glosario 68

11 Anexo y futuras implementaciones 69

11.1 Hearthbleed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.2 Migracion de dispositivos . . . . . . . . . . . . . . . . . . . . . 71
11.3 Instalaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.4 Balanceo de carga . . . . . . . . . . . . . . . . . . . . . . . . . 73

4
1 Introduccion
EL proyecto Diseno e implementacion del sistema de gestion de redes wire-
less con portal cautivo se ha desarrollado con la Start-up SocialAndBeyond.
Dicha empresa posee un producto en fase prototipo que se basa en un portal
cautivo, con el agregado de publicar campanas de marketing en las redes
sociales como contraprestacion a la conexion obtenida por el usuario.

El producto de la empresa se basa en configuracion de un harware concreto,

normalmente routers o routers-Wi-Fi, para que creen un portal cautivo (un
portal cautivo es aquella red Wi-Fi aparentemente abierta que al conectar
te redirige a una pagina web concreta donde usualmente te pide algun tipo
de autentificacion o de pago para poder usar la conexion), sin embargo como
valor anadido en vez de otros portales cautivos el sistema de autentificacion
se realiza a traves de la cuenta de red social del usuario, permitiendo que el
que dispone de la conexion pueda publicitarse en el muro del usuario o pedir
que le de un megusta a su pagina en la red social.

Tecnicamente esta solucion necesita cierto soporte dentro de las tecnologas

de la informacion (TI), ya que la configuracion de los dispositivos requiere
configurar firewalls, redes virtuales privadas (VPN) para la gestion de dis-
tintos dispositivos, servicio de upgrade para nuevos cambios, etc. Ademas
de todo el soporte necesario para mostrar los portales en el momento de
conexion, y el soporte para el mission control (plataforma web para ges-
tionar entre otras cosas los disipositivos, portales, datos, etc).

En este proyecto se explicara todo el desarollo realizado en tecnologas TI

que se ha llevado a cabo. La finalidad del mismo se estriba en proveer a la
empresa de una base solida y estable, con la que seguira desarrollando su
producto de la mejor forma posible.

5
1.1 Motivaciones del proyecto
En la actualidad, muchas empresas recientes tienen problemas de finan-
ciacion, donde la busqueda de capital se canaliza va el ahorro en tecnologas
mas asequibles para el desarrollo del producto. Ademas, cabe destacar que
es un hecho reiterado que una vez establecida la empresa, esta decida que los
costes de los servicios TI les resultan demasiado caros y difciles de mantener.

Para poder permitir a una empresa financiarse de forma mas eficiente este
proyecto intenta buscar soluciones TI mas eficientes, que permita un uso mas
adaptado a las necesidades de la empresa.

Por ello, la motivacion de este proyecto es intentar buscar soluciones TI

adaptables para start-ups. Aquellas quienes en su fase de crecimiento busquen
en primer lugar, una estabilidad inicial y en segundo instancia, ser flexibles
y escalables con respecto a los servicios TI y as poder ajustarse a las necesi-
dades cambiantes de la empresa.

1.2 Objetivos
Seis son los objetivos que nos hemos marcado para este proyecto: la seleccion
y coordinacion de recursos, la estabilidad, la flexibilidad, la seguridad, la
gestion de usuarios y entornos de trabajo, la disponiblidad y finalmente la
automatizacion de tareas.

Optimizacion y gestion de recursos: Por una parte, nos cen-

traremos en la reduccion de costes mediante la eliminacion de recursos
no necesarios. Por otro lado, adaptaremos la necesidad de recursos y
los disponibles a las necesidades actuales de la empresa.

Estabilidad: En este sistema el codigo se estructura en un sistema

de repositorios GIT. Existen dos ramas en el repositorio importantes:
DEVELOP y MASTER. En la primera, se desarrollan y prueban los
nuevos cambios y funcionalidades. Una vez comprobados, dichos cam-
bios se introducen en el repositorio MASTER. Para lograr una mayor

6
 estabilidad, es importante que la plataforma donde se desarrolla la rama
DEVELOP sea lo mas similar posible a la plataforma donde se ubicara
el repositorio MASTER.

Flexibilidad: Es de vital importancia puesto que estas herramientas

TI se tienen que adaptar a las necesidades de la empresa. A variaciones
en la produccion, vease si es necesario mas capacidad, se busca que
puedan anadirse de forma rapida y sencilla.

Seguridad: Focalizandose en evitar intrusos en el sistema, as como en

evitar ataques fortuitos masivos que puedan perjudicar al rendimiento.

Gestion de usuarios y entornos de trabajo: Es de vital impor-

tancia gestionar los usuarios de los sistemas y sus entornos de forma
correcta y sencilla, para un mejor desarrollo del producto y demostrar
cual es nuestro valor anadido.

Disponibilidad: Es importante evitar cualquier fallo de sistema. Para

cualquier imprevisto hay que desarrollar un metodo con el cual el sis-
tema siga funcionando aunque haya habido un fallo y alguna maquina
no este funcionando.

Como objetivo final, se han impulsado distintos servicios para poder re-
alizar ciertas tareas de forma automatica sin necesidad de intervencion.

Para cumplir estos objetivos se han usado distintas tecnologas, por ejemplo
highcharts and highstocks (para generar graficas), extjs, nodejs, JasonP, Git
y dos tipos de protocolos de tuneleado OpenVPN, PPTP, radiator (servicio
de autentificacion), chef (provisionamiento automatico de servidores).

1.2.1 Estructura

La estructura del proyecto constara de las siguientes partes:

Vision general: Se define la finalidad del proyecto y las condiciones

en las cuales se ha desarrollado como el producto que desarrolla la
empresa y el sistema necesario para el producto.

7
 Estudio de la situacion inicial: Se plantea la situacion inicial de los
sistemas, ahondando en su funcionamiento y exponiendo sus carencias
y errores funcionales.

Tecnologas: Se detallan las diferentes tecnologas y herramientas que

se han utilizado durante el proyecto, tanto las que componen el pro-
ducto como las utilizadas para su desarrollo.

Objetivos de la reestructuracion y ampliacion: Se planteara los

objetivos generales de los cambios a realizar, para las lneas de accion
de la reestructuracion y la ampliacion.

Implementacion: Estudio del trabajo realizado para conseguir cumplir

con los objetivos propuestos.

Estudio Economico: Balance economico resultado de la realizacion

de este proyecto para la empresa.

Conclusiones: Se explicaran la resolucion que se ha tomado sobre el

proyecto a que se ha llegado tras su realizacion.

Bibliografa: Referencia a las paginas web y libros donde se han

obtenido datos para la realizacion del proyecto.

Glosario: En el, se incluyen todos aquellos terminos de difcil in-

terpretacion. Cada uno de estos terminos viene acompanado de su
respectiva definicion o explicacion.

8
2 Vision general
La finalidad de este proyecto es configurar, mantener y administrar los recur-
sos TI de una start-up tecnologica, que pueda ser extrapolable a cualquier
otro tipo de empresa que necesite este tipo de servicios. Para ello, es necesario
reestructurar toda la instalacion ya existente e ir anadiendo mas funcionali-
dades imprescindibles, segun las necesidades de la empresa.

La Start-up donde se ha realizado este proyecto ha sido aceptada en la

academia Wayra de Movistar-Telefonica. Gracias a esta inclusion se ha po-
dido obtener mas recursos a disponer y a un coste mas competitivo o nulo,
como puede ser: soporte, servers virtuales, descuentos, etc. Sin embargo,
tambien se han incluido ciertos cargos por concepto del uso este tipo de re-
cursos aunque pudiera no ser la mejor opcion.

Al ser una start-up tecnologica con un modelo de negocio en expansion, se

presuponen de base futuros y diversos cambios en las tareas y en sus priori-
dades. El tener un negocio cambiante ha influido tambien en las necesidades
en los recursos TI. Por lo tanto, conseguir una base solida y funcional ha sido
prioritario ya que facilita la adaptacion de los nuevos servicios necesitados,
a la vez que implementan dichos cambios. Estos hechos han condicionado
los elementos del proyecto, desde la metodologa, el desarrollo y la imple-
mentacion.

2.1 El producto
El producto que ofrece la empresa esta basado en el provecho de la necesi-
dad creciente de servicio Wi-Fi para dispositivos moviles, dotandolo de valor
comercial para comercios, locales, etc. Es decir, los clientes de la start-up
obtienen un beneficio potencial por disponer de Wi-Fi para sus clientes, este
beneficio es obtenido mediante la propaganda a traves de las redes sociales
del usuario final.

9
Se provee al cliente de los dispositivos networking necesarios para poder
disponer del servicio de portal cautivo, normalmente un router (appliance)
que se encarga de gestionar el portal cautivo. El cliente se conecta a la red
Wi-Fi, que le redirigira a un portal donde se logueara a traves de su red so-
cial, aceptara los permisos de la aplicacion para que se pueda publicar con su
nombre, dara Like a la pagina, etc, y posteriormente dispondra de Internet
libremente.

El producto beneficia tanto al usuario como al cliente ya que:

Usuario: Dispone de un servicio Wi-Fi para poder conectarse.

Cliente: Da un valor anadido a un servicio que no lo tena, otorgandole

de la posiblidad de hacerse publicidad a traves de las redes sociales
mediante los usuarios, consiguiendo likes o dando promociones para
atraer mas publico.

2.2 El sistema
Para llevar a funcionamiento este sistema son necesarios Access-Point, no
importa demasiado el modelo sino que este configurado en modo bridge, el
router con portal cautivo (encargado de redireccionar al portal y filtar las
conexiones hasta que sean aceptados en el sistema), y salida a internet.

Desde la vision TI el sistema necesita:

Servicio Portal: Servicio Web donde son redireccionados todos los

usuarios, es aqu donde salen los portales de promocion, redirects a
la red social para dar permisos, etc.

Servicio Radius: Servicio protocolo radius, donde autentifica a los

usuarios en la base de datos y le dice al router que ya tienen acceso a
internet.

Appliance: Router instalado en el cliente que actua con Radius y el

portal.

10
 Base de datos: Para poder guardar todos los datos necesarios de los
usuarios y sus conexiones.

Mision control: Portal web donde se puede gestionar los dispositivos,

la base de datos, recoger estadsticas, etc.

El esquema base se puede describir como:

Figure 1: Esquema base del funcionamiento

2.3 El proyecto
El proyecto se compone de las siguientes fases:

Reestructuracion: Analisis de la situacion actual de los recursos TI.

El sistema incial contiene diversos errores de configuracion y falta de
estabilidad, que dificultan el correcto desarrollo de la aplicacion. Por lo
tanto, una parte del proyecto se centrara en reparar y configurar este
sistema para facilitar el desarrollo.

Recuperacion de los sistemas: Facilitar un metodo fiable y seguro

para recuperar los sistemas TI en caso de desastre, adaptado (o facil
de adaptar) a cualquier plataforma usada. Una parte del proyecto

11
 se centrara en el metodo usado para recuparar sistemas, en caso de
necesitarlo.

Recuperacion de datos: No solo se tendra que recuperar los sis-

temas, sino tambien los datos. Con este fin, es necesario un sistema
y una planificacion robusta para realizar backups a todos los datos
interesantes.

Ampliacion: Dada la situacion de la empresa, hay una necesidad

contnua de expandirse horizontalmente, en numero de negocios. Hecho
que repercute en una cantidad mas grande de recursos TI, as pues es
necesario desarrollar una ampliacion constante de estos recursos, de
forma que se pueda adaptar facilmentemente a lo que ya exista.

Ampliacion de servicios: Debido a la necesidad de expandirse, sera

vital tambien desarrollar nuevos servicios para ir completando los pro-
ductos disponibles para la empresa.

Mantenimiento y monitorizacion: Los dispositivos networking la

mayora de veces estan detras de un router que realiza NAT, que hace
imposible realizar un port forwarding para poder acceder a ellos de
forma convencional. Para superar esta casustica, es necesario realizar
y mantener un tunel hacia los dispositivos para poderlos manejar de
forma remota.

Aprovisionamiento: Una parte del producto de la empresa es la con-

figuracion de dispositivos networking para usar nuestros sistemas. Al
crecer y necesitar configurar cada vez mas dispositivos, se hace inviable
realizar una configuracion manual; por ello es necesario un sistema para
provisionar los dispositivos automaticamente.

Las tres primeras fases estan relacionadas entre ellas, pertenecen mas a la
configuracion de los recursos y su mantenimiento. En muchas ocasiones se
han tenido que desarrollar en paralelo, mientras que las tres siguientes fases
son componentes adicionales anadidas.

12
La ultima fase hace referencia a un sistema no previsto que se tuvo que
realizar debido al crecimiento de la empresa. Consiste en un conjunto de
software en distintas plataformas, para poder configurar cualquier tipo de
dispositivo en cualquier lugar. Sin tener que ser enviado a nuestras oficinas
y de nuestras oficinas configurarlo manualmente y enviarlo a cliente final, se
ahorra tal y como se explicara a posteriori bastantes recursos a la empresa.

13
3 Estudio de la situacion inicial
Dado que no se implementa un conjunto de sistemas TI desde cero, sino que
se empieza con algo implantado, es necesario realizar un estudio del sistema
existente, analizando sus puntos fuertes y debiles para saber que se puede
aprovechar y que no.

La trayectoria de la empresa ha ocasionado varios cambios tanto en las her-

ramientas usadas como en los recursos necesitados.

Dado la situacion de la empresa y los cambios de necesidades, se han ido

analizando a medida que se han ido encarando. Debido a estos cambios, al-
gunas veces se ha tenido que implementar, segun se iba necesitando, servicios
nuevos o cambios en los que ya existan.

3.1 Producto
Para un mejor entendimiento de la situacion inicial, se explicara brevemente
el producto del que se parte:

Portal: Son los conjuntos de pantallas que el usuario tiene que visu-
alizar para tener conexion a internet. Es en donde se aprovecha para
hacer publicidad de la empresa que contrata el servicio. Un ejemplo de
las pantallas que se mostrara a un usuario al conectarse por ejemplo
en la red Wi-Fi desigual:

14
Figure 2: Ejemplo de Portal login realizado para desigual.

Figure 3: Portal conectando realizado para desigual.

15
 Figure 4: Portal ya conectado realizado para desigual.

Mision Control: Plataforma web que permite administrar la in-

formacion de los portales, modificar la base de datos, gestionar las
propiedades de los dispositivos, visualizar estadsticas, etc.

16
 Figure 5: Visualizacion y gestion de datos.

Figure 6: Visualizacion de estadsticas

Radius: Servicio/protocolo para autentificar a los usuarios en los dis-

positivos y guardar los datos de conexion.

17
 Administracion Wi-Fi: Para ciertos clientes se alquila y administra
las antenas Wi-Fi, que son controladas de forma centralizada.

3.2 Esquema
El servicio para el mision control esta situado en un server fsico de renting
ubicado en Alemania con un sistema operativo (SO) centos, respondiendo al
nombre de SocialAndBeyond.
El servicio para los portales y el servicio de Radius esta ubicado en Alemania,
en un server fsico de renting. Como en el caso anterior, tambien con centros
respondiendo el nombre de iLikeFreewifi.
El servicio de gestion de las antenas Wi-Fi esta ubicado en varios servers de
AmazonWebService (virtuales).

El esquema grafico corresponde a:

18
 Figure 7: Diagrama basico del caso incial

3.3 Repositorios y developers

El codigo esta construido en un repositorio GIT, separando codigo Master
de codigo Develop, segun si esta probado y testeado o esta en desarollo.
Este tipo de implementaciones muy usadas permite realizar cambios para pro-
bar el buen funcionamiento antes de lanzarlos al producto final, ahorrandose
problemas y errores que se puedan introducir. Con este fin, es bastante re-
comendable que el sistema que alberga y se prueban los cambios sea lo mas

19
parecido posible al final.

3.4 Esquema con repositorios

El sistema para el desarollo se esta implementando mediante dos servidores
adicionales ubicados en el CloudComputing de Telefonica. El sistema para
el desarrollo funciona mediante repositorios instalados en las workstation de
cada developer. Usando Dropbox se sincroniza a un servidor NFS, el cual
sincroniza este contenido a otro server, este tiene un servicio web y una base
de datos sqlite para imitar el funcionamiento de los servidores Master.

Estos servidores web responden a los nombres develop.ilikefreewifi.com/(develop

name) y develop.socialandbeyond.com/(develop name).

20
 Figure 8: Diagrama basico del caso incial con develop

3.5 Conclusiones sobre la situacion inicial

Posiblemente, el punto mas negativo de la situacion inicial es la sobredi-
mension existente en los sistemas. En total existen cuatro servidores para
wireless, mas otro cuatro para develop y master y ninguno de ellos pasaba
en aquel momento del 1% de uso.

El siguiente punto negativo es la diversidad de plataformas usadas para

hostear los servicios: se estaba usando amazonwebservices, servidores fsicos
y cloud de Telefonica. Este problema es mas grave, teniendo en cuenta que
tanto develop como master estaban en distintas plataformas con distintos

21
sistemas operativos, cuando obviamente lo mas recomendable es que fuesen
lo mas similar posible entre ellos. Ademas, no era un sistema flexible que
pudiese afrontar nuevas necesidades de computacion en un futuro.

Junto a los otros dos puntos, existen otros dos problemas: en develop se
usa una base de datos SQLite; mientras que en produccion, una Oracle.
Ello obligaba a mantener muchos codigos diferentes entre develop y master
ademas, es un motivo por el cual se pueden producir errores.
Otro problema eran los errores de configuracion, sobretodo en la maquina
NFS y la Develop, con los permisos de los usuarios.

22
4 Tecnologas
El producto consta de tres distintos grupos de usuarios: la persona que esta
usando el acceso Wi-Fi con portal, el cliente que contrata este servicio y los
developers que desarrollan para este. Es decir, el sistema tiene que agrupar
distintas tecnologas para cada grupO.

Highcharts and highstocks: Highcharts y Highstock son dos apis

proporcionadas por la misma empresa, Highsoft Solutions. Son dos li-
breras para crear distintos tipos de graficos, intuitivos e interactivos,
mediante JavaScript. Highstock permite eorar graficos con lnea de
tiempo, permitiendo localizar facilmente el periodo que se quiere obser-
var, Highstock es adecuado tambien para cualquier otro tipo de grafico.
Estas graficas permiten tanto al cliente, como al developer, consultar
las graficas sobre los datos de acceso, likes, etc.

Extjs: Es una librera de JavaScript para el desarrollo de aplicaciones

web interactivas. Es desarrollada por la empresa Sencha.
Es una aplicacion orientada para la creacion de una aplicacion para
escritorio es decir, no optimizada para movil y teniendo el uso de
ventanas como uno de los elementos basicos. Destaca en la compatibil-
idad con multiples navegadores, la estructuracion de los componentes
visuales y la optimizacion para tables con grandes cantidades de datos.
El mision control esta construido mediante esta herramienta.

Node.js es un entorno de programacion en la capa del servidor basado

en Javascript. Fue creado bajo el enfoque de ser util en la creacion de
programas de red altamente escalables. Al contrario que en la mayora
del codigo JavaScript, no se ejecuta en un navegador. Ello permite
servicios altamente escalables como big data.
Ademas, con el plugin de highcharts se generan graficas consistentes
con las graficas de visualizacion del mision control.

23
 JasonP: JSONP o JSON con padding es una tecnica de comuni-
cacion utilizada en los programas JavaScript para realizar llamadas
asncronas a dominios diferentes. JsonP suple la limitacion de AJAX,
que unicamente permite realizar peticiones a paginas, quienes se en-
cuentran bajo el mismo dominio y puerto por razones de seguridad.
Esta herramienta se utiliza sobretodo en el proceso del portal cau-
tivo y permite cambiar de dominio entre ilikefreewifi.com, socialandbe-
yond.com y el router.

Git-Bitbucket: Git es un software de control de versiones distribuido,

pensando en la eficiencia y la confianza en el mantenimiento de ver-
siones de proyectos, cuando estas tienen un gran numero de archivos
de codigo fuente.
Entre las propiedades mas distintivas de Git destacan: la facilidad para
crear ramas de desarrollo locales, para guardar y desaplicar los cambios
hechos desde la ultima version (pudiendose recuperar posteriormente)
muy util ante cambios espontaneos del flujo de trabajo, y para ges-
tionar paralelamente multiples flujos de trabajo.
En este entorno se usa Bitbucket como alojamiento web y SourceTree
como interfaz grafica para facilitar el uso de Git.

Tunneling protocols: Para poder administrar y mantener los diver-

sos dispositivos networking, es necesario un conjunto de herramientas
capaces de conectar con estos dispositivos, aunque no tengan una IP
publica y no sea posible hacer un port forwarding.

Radiator: Protocolo usado para la autentificacion, autorizacion y con-

tabilizacion de accesos al portal cautivo. Usado en todos los disposi-
tivos, proveen del mecanismo para acceder a internet.

Chef: Mecanismo para poder replicar el software necesario entre distin-

tos servidores, mecanismo multiplataforma basado en recetas quienes
implementan los cambios necesarios de forma distinta, dependiendo de
la plataforma destino.

24
 Cron: Sistema unix/linux para realizar tareas programadas en los
servidores, de gran utilidad para realizar backups o tareas de manten-
imiento, como tambien servicios de envo de estadsticas a los clientes.

25
5 Objetivos de la reestructuracion y ampliacion
A partir de la situacion inicial, es importante definir ciertos objetivos nece-
sarios para el correcto desarrollo de la reestructuracion y ampliacion. Estos
objetivos se toman valorando: la estabilidad, la flexibilidad, el rendimiento
necesario y los costes derivados. Teniendo en cuenta todo ello se han definido
como:

5.1 Consistencia
La consistencia se puede definir como una garanta de para un conjunto de
instrucciones, obtener el mismo resultado.
En este entorno se busca una consistencia en el codigo generado por los
developers en la rama devel; si este codigo funciona correctamente en esta
rama, funcionara igualmente en la rama produccion. Para acercarse lo mas
posible a este resultado, es necesario eliminar todo aquel sistema que pueda
interferir en el funcionamiento del codigo. No resulta logico que, por ejemplo,
el uso de herramientas y la plataforma usada en una entorno sea totalmente
distinta que en el otro entorno, puesto que eso puede inlfuir en el resultado.

5.2 Escalabilidad y flexibilidad

En el futuro es posible que los requisitos respectos a los sistemas sean mucho
mas amplios en envergadura de lo que eran. Por lo tanto, se requiere que sean
facilmente adaptables a las necesidades del momento. Asi pues, es necesario
que los sistemas puedan crecer de forma facil y sencilla, si fuese necesario.

5.3 Estabilidad
Uno de los puntos importantes en cualquier sistema es que este sea estable. Es
decir, que las herramientas proporcionadas no cambien su forma de trabajar,
teniendo que adaptar el desarrollo a cada cambio. Ademas, si se tienen que
hacer cambios, que estos sean de larga solucion y a largo plazo. Buscando
que se puedan ampliar estos mismos, sin repercutir en nuevos cambios.

26
5.4 Fiabilidad
Hay que evitar que las herramientas necesarias para el desarrollo y ex-
plotacion del producto fallen. Para ello, hay que desarrollar un conjunto
de herramientas para evitar fallos innecesarios. Como por ejemplo: her-
ramientas de proteccion sobre fallos de red, fallos de servicios, etc.

5.5 Amortizacion de costes

Debido a la situacion actual: la falta de financiacion empresarial, se deben
paliar las posibles restricciones presupuestarias mediante una mejor amorti-
zacion de la infraestructura. Ello se puede conseguir mediante plataformas
virtuales, donde se paga por el uso dado a un servidor, (si en ese momento
no es necesario se puede parar o reducir sus caractersticas). No es lo mismo
para una empresa una dotacion de inmovilizado por infraestructuras en TI,
cuyo valor dependera de factores como: la amortizacion del mismo, el ben-
eficio o la perdida por la venta del mismo, etc. En cambio, la posibilidad de
pagar unicamente por el uso dado de un servidor ofrece ajustar la estructura
economica a la estructura productiva de una empresa y viceversa.

5.6 Recuperacion
Aun y con el desarrollo mas exhaustivo realizado para que un sistema no
falle, este puede fallar. Razon por la cual, se debe desarrollar un sistema
para poder recuperar lo antes posible este sistema. Como por ejemplo va:
backups, replicacion de servidores, etc.

5.7 Portabilidad
Existen muchas soluciones viables de hosting para los servidores y es posible
que en un futuro se cambie. Por ese mismo motivo, resulta necesario que
todo tipo de configuracion sea rapidamente portable a otro tipo de sistema
similar.

27
6 Implementacion
Antes de empezar cualquier implementacion, se decidio que tipo de plataforma
se iba usar. Debido a que el mantenimiento y la escalabilidad de un sistema
implementado en multiples tipos de plataformas es bastante pobre; para de-
cidir cual sera el tipo de plataforma a usar, hay que analizar los beneficios y
problemas de cada una de las posiblidades.

6.1 Analisis de las plataformas existentes.

Se barajaron 3 tipos de plataformas: continuar mediante servidores fsicos
(intentando reaprovechar los que estaban contratados), seguir usando amazon
web services o usar el cloud computing de Telefonica. A continuacion se
explicaran las ventajas e inconvenientes de cada uno de ellos.

6.1.1 Servers fsicos

Como ventajas este tipo de plataformas ofrecen:

Rendimiento: Teniendo un precio similar a las otras soluciones, su

hardware era superior, ya que dispone de un mejor procesador y algo
mas de memoria RAM.

Ancho de banda: Dispone de una conexion 100MB exclusivos para

el servidor.

Y como desventajas se pueden destacar:

Sistema Operativo: Suele disponer de pocos sistemas operativos.

Generalmente solo tienen un tipo.

Escalabilidad: No dispona de algun tipo de sistema para conseguir

mayor capacidad de conmutacion.

Latencia: El servidor estaba en Alemania cuando la mayora de clientes

estan en Espana, pudiendo causar un extra de latencia que de otras
soluciones puede no derivarse.

28
6.1.2 Amazon Web Services

Amazon web services es la plataforma mas conocida de cloud computing.

Basada en un modelo de prestacion de servicios de negocio y tecnologa, con
un catalogo de servicios estandarizados flexibles y capaz de adaptarse a las
necesidades de la empresa.
Como ventajas cabe destacar:

Escalabilidad: Permite aumentar o disminuir las funcionalidades segun

la demanda.

Pago por uso: El coste esta directamente relacionado en funcion de

las necesidades.

Provisionamiento automatico: No es necesario recurrir al provee-

dor para provisionar nuevos servicios.

Catalogo: Dispone de un gran numero de herramientas para distintos

usos.

Sistemas Operativos: Dispone de bastantes opciones al escoger el

sistema operativo.

Como desventajas comprende:

Disponibilidad: Para acceder a los servicios se depende de si se tiene

acceso a internet.

Dependencia: El uso de ciertas tecnologas exclusivas de AWS causara

dependencia de sus servicios, hecho que dificultara una posible futura
migracion a otra plataforma.

Latencia: El nodo de AWS Europeo esta en Irlanda, al igual que en

el caso anterior, eso puede producir un exceso de latencia debido a un
mayor numero de nodos que hay que recorrer, aproximadamente unos
200ms.

29
6.1.3 Telefonica Cloud Computing

Una alternativa que se planteo fue usar el nuevo cloud computing de Telefonica,
un nuevo servicio disponible en fase de salida al mercado.
Debido a que Telefonica es un socio, esto nos aportaba bastantes ventajas
como:

Herramientas: a pesar de no disponer de demasiados sistemas opera-

tivos, unicamente SmartOS y Ubuntu, de estos disponan de diferentes
versiones con herramientas ya incluidas y funcionales, como podra ser
mongoDB, apache, nodejs.

Provisionamiento automatico: No es necesario recurrir al provee-

dor para provisionar nuevos servicios.

Soporte: Al ser un producto todava en fase experimental y ser Telefonica

un socio, se nos ofreca un canal de soporte directo con los responsables
del cloud. As pues, para que cualquier problema o duda que nos en-
contrasemos, se podra reportar inmediatamente.

Latencia: Al tener el nodo en Madrid, la latencia existente era sin

duda la mas baja de todas, con apenas 23ms.

Sin embargo existan ciertas desventajas expuestas a continuacion:

Pago por uso: El coste era por maquina, y no por uso, haciendo que
otras soluciones a la larga pudiesen ser mas economicas.

Sistemas operativos: Disponibles unicamente dos, (smartOS y Ubuntu).

Catalogo: Solo dispone de sistemas operativos, difiriendo mucho de

otras soluciones que aportan muchas mas herramientas para todo tipo
de soluciones.

Disponibilidad: Al igual que amazon, para acceder a los recursos es

estrictamente necesario tener conexion a internet.

30
6.2 Eleccion de la plataforma
Una vez analizadas las mejores opciones disponibles, inmediatamente se descarto
la opcion actual, sevidores fsicos de renting; debido a que sin duda era la
peor opcion de todas por su poca flexibilidad.
Como eleccion final, se decidio por el cloud computing de Telefonica, (a pesar
de la opcion de que Amazon posiblemente fuese la mejor por las herramientas
extras como: balanceadores servicios de forwarding de email, dns, etc, o por
su precio por horas y la posiblidad de aumentar los recursos de la maquina
bajo demanda) la razon fue motivada la situacion de que telefonica es un
socio estrategico, disponiendo de un soporte mas rapido, ademas de tener la
menor latencia de todas las opciones nos hizo decantar por esa opcion.

Sin embargo esta eleccion tenia algun incoveniente extra, una parte de la
instalacion estaba en servidores amazon y otra en servidores fsicos, debido
al uso de tecnologas distintas se anada un nivel de complejidad en la mi-
gracion.

6.3 Servidores Amazon Controler Unifi

6.3.1 Introduccion al servidor Unifi

El cloud Unifi consta de dos partes: la primera, el servicio inform por el

puerto 8080, donde la controladora y antenas se comunican todos los datos
para su correcto funcionamiento. El otro punto es el controlador, que fun-
ciona por el puerto 8443, donde se puede configurar y cambiar la configu-
racion de las antenas.

31
 Figure 9: Controladora Beta Unifi

6.3.2 Objetivos y soluciones

Uno de los primeros objetivos era reducir el coste y las infraestructuras desti-
nadas para la gestion de las antenas unifi. Recordemos que se estaban usando
4 servidores unifi 24 horas, que jamas usaban mas del 1% de cpu.

El motivo de necesitar tantas maquinas vena por el hecho de que por cada
site se necesitaba una maquina, es decir, por cada sitio fsico donde hubiese
antenas se necesitaba un controlador aparte. Este tipo de infraestructura no
se considero viable ya que se tena planeado ampliar el numero de antenas,
por lo que no era suficientemente escalable si por cada sitio diferente se nece-
sitaba otro servidor.

Como solucion se planteo buscar una alternativa viable en la que, con solo
un servidor, que pudiese gestionar las antenas o cambiar de fabricante asum-
iendo todo el coste de cambiar las antenas, en los distintos sitios que estaban
ya instaladas. La solucion que se escogio fue la primera, ocurrio que al mismo
tiempo que se planteaban las posibles soluciones, la compana unifi saco una

32
controladora beta que permita la creacion de multiples sitios.

6.3.3 Implementacion

A la hora de implementar la solucion, se escogio como plataforma a Ubuntu,

ya que era la plataforma en la que Unifi daba soporte. Ademas, propor-
cionaba un repositorio para poder instalar el software; como se haba podido
observar, la carga de la controladora tanto de cpu como memoria era muy
baja y se utilizo una maquina ya funcional (la que estaba haciendo de NFS
en ese momento).

Una vez instalado, se decidio crear una entrada en el DNS para este ser-
vicio; as pues, si se cambiaba en el futuro de plataforma y se necesitaba
migrar la controladora, sera suficiente cambiar la traduccion DNS.
Sin embargo, las antenas ya conocan a su controladora va IP, el cam-
bio obligaba a cambiar localmente la IP antigua de amazon por el nombre
unifi.socialandbeyond.com en todas las antenas, que ya estaban configuradas.

6.3.4 Conclusion

Es importante estar informado de las novedades del software que se esta

utilizando, ya que se pueden ahorrar bastantes recursos. En este caso se
ahorro 3 servidores, sin embargo podran haber sido bastantes mas.

6.4 Server Develop

6.4.1 Introduccion

Esta implementacion esta ideada para el desarrollo de nuevas features de los

developers. Consta de un server Ubuntu que tiene instalado un server Drop-
box para cada developer mas un servidor NFS, compartiendo las carpetas
del Dropbox a un servidor web SmartOS.

Al acabar los cambios, los developers comitean el cambio mediante un repos-

itorio Bitbucket (git), en la rama devel, para su posterior comprobacion e

33
implementacion en produccion (rama final).

6.4.2 Objetivos y soluciones

El primero objetivo, dada la estructura inicial, es que funcionase correc-

tamente. Debido a errores de configuracion en el servidor NFS, no se ex-
portaban correctamente los permisos. Puesto que NFS ,a diferencia de otros
sistemas de ficheros en red, exporta los permisos mediante el identificador de
usuario y no mediante el nombre del usuario. Es decir, aunque tanto en el
cliente como en el servidor exista el mismo nombre de usuario, si no com-
parten el mismo UID, no se considera el mismo usuario.
Este problema causaba primero un problema de seguridad, ya que no se ma-
peaba correctamente los ficheros al usuario que se pretenda. Ademas, al no
coincidir los permisos con ningun usuario existente, se gestionaban ficheros
importantes para el funcionamiento del programa mediante links en /tmp/ ,
para que los developers pudieran acceder.
La solucion de este problema se realizo mediante el cambio de UID de los
usuarios, para que coincidiese tanto en usuario y cliente. Posteriormente,
se deshizo el uso del directorio /tmp y se creo una estructura de carpetas
separada para cada developer, siguiendo el patron.
/home/www/(nombredeveloper)/db-portals-uploads/

El siguiente objetivo es que el sistema no se consideraba facil de usar para los

developers, por tanto se busco formas para conseguir facilitar su uso. Para
ello se realizaron ciertos cambios como el desarrollo de que el servidor web
no solo respondiese al nombre de develop.socialandbeyond.com/ sino que re-
spondiendese a un nombre distinto por cada develop.
ej: http://marc.develop.socialandbeyond.com
Con este cambio, primero se consigue aislar el espacio de trabajo de cada
developer, haciendolo independiente de unos y los otros. Aislandolo de esta
forma, se evita conflictos en el desarrollo, tambien se consigue un mejor man-
tenimiento y debugeo, ya que con distintos hosts virtuales permite distintos
logs. Es decir, cada espacio de trabajo de develop tiene su access.log y er-

34
ror.log independiente.

6.4.3 Conclusion

No solo se busca que funcione correctamente, sino que se adapte a las necesi-
dades de la empresa. Proveerlo de ciertos extras como logs independientes
ha ayudado a la empresa a crecer mas deprisa, antes cada develop tena
que filtrar su parte del log de los demas. Sumando, la instanciacion e im-
plementacion de virtualhosts permitira una facil ampliacion de los servicios
web.

6.5 Ampliacion develop

6.5.1 Introduccion

Una vez solucionado los problemas en el sistema develop, se pensaron nuevas

formas de complementarlo. Una de las soluciones mas tpicas es la imple-
mentacion de un sistema beta, es decir, un sistema que contenga la version
mas reciente de la rama develop del repositorio. Con ello y un sistema web,
se permite un entorno de prueba de ultimos cambios en el repositorio.

35
 Figure 10: Diagrama del funcionamiento del servicio beta.

6.6 Previo migracion del servidor de produccion

6.6.1 Introduccion

En el estado en el que se encontraba, en aquel momento el sistema era

propenso a errores de desarrollo, debido a un entorno develop mal configu-
rado y un entorno produccion bastante distinto al entorno de develop. Entre
las multiples diferencias, (principalmente la mas notoria era que cada en-
torno estaba usando una base de datos totalmente distinta), provocaba que
existiese una gran parte de codigo, solo para diferenciar el tipo de base de
datos y los cambios necesarios en cada una.

36
Sin embargo, no era la unica diferencia, el sistema operativo no era el mismo,
uno era una Linux y la otra una Unix. A parte del servicio de Radius in-
stalado en produccion, estaba configurado para usar la base de datos Oracle.
Por tanto, se tuvo que realizar una migracion por partes divida en:

Migracion de base de datos

Migracion de codigo

Migracion de radius

Migracion del servidor

6.6.2 Migracion de base de datos

En este momento, exista una base de datos Oracle en produccion y una

base de datos SQLite en develop. Tanto una como la otra tenan distintas
estructuras, haciendo que se necesitase codigo especfico para cada una de
ellas. As pues, se deba migrar a alguna de ellas. Para ello, se realizo un
estudio sobre que base de datos se adaptaba mejor en ese mismo momento.
Las opciones que se barajaron fueron:
Mantener Oracle como ventajas:

Alto rendimiento.

Base de bastos High-availibity, posibilidad de replicacion.

Y como desventajas:

La base de datos estaba mal hecha, no existan primary keys, se uti-

lizaba triggers para simularlas, tablas que sobraban, nombres incoher-
entes, etc.

Uso mas complejo.

Licencia propietaria y necesario pagar para tenerla.

SQLite3 como ventajas tiene:

37
 Basada en un fichero que es bastante facil de usar.

Los developers estaban ya acostumbrados a usar este tipo de base de

datos.

La estructura de la base de datos estaba bien implementada a diferencia

de la Oracle.

Licencia libre

Como desventajas podemos recalcar:

Rendimiento bastante pobre. Ranking 8 segun db-engines, a diferencia

de Oracle que esta la primera.

Disponibilidad: No proporciona ningun mecanismo de replicacion.

Otras opciones que tambien se plantearon fueron: PostgreSQL o MySQL.

Ventajas:

Licencia libre (MySQL depende de si se quiere alguna version con mas

caractersticas, entonces deja de ser libre).

Mayor rendimiento que SQLite.

Disponibilidad: Tiene mecanismos para replicarse.

Desventajas:

Migracion de develop y produccion.

Codigo no adaptado para estas bases de datos.

En el contexto actual de la empresa, el rendimiento no era un problema ya

que no se hacan suficentes accesos a la base de datos. Es decir, el rendimiento
de una base de datos Oracle no era un punto prioritario; es mas, al no ser
libre, tener un coste y estar ya mal configurada desde un inicio (hecho que
nos impona que en algun momento se tuviese que arreglar la base de datos
entera), nos hizo descartarla.

38
Entre las otras dos opciones, la que podra tener una mejor adaptacion sera
la postgreSQL. Sin embargo, al no tener el codigo totalmente encapsulado,
para anadir una nueva base de datos y el hecho de tener que migrar tanto
produccion como develop, provoco que se decidiese usar SQLite por el mo-
mento como base de datos en produccion. Se espero a mas adelante para
cambiar a alguna base de datos algo mas sofisticada.

Para la migracion de la base de datos, se probo antes usando dumps de la

base de datos, que se parseaban mediante un script en bash, el cual tambien
llamaba a otro script que ya exista para traducir ciertos datos al sistema
SQLite.

6.6.3 Migracion de codigo

Algunas funcionalidades de produccion como el servicio de Mailers (servicio

que se encargaba de enviar mails con los distintos datos de seguimiento del
producto, tanto a los developers como a los clientes) y el servicio de workers,
que realizaba distintas tareas en la base de datos en momentos determinados
(mediante tareas programadas) estaban unicamente adaptadas a Oracle. A
parte de existir codigo especifico por tener dos servidores distintos, codigo
especfico (como al subir imagenes de los portales en el mision control), se
tenan que subir tambien al servidor de gestion de portales.
Con este fin, se creo una nueva rama en el repositorio y se provisiono una
nueva maquina SmartOS para probar el buen funcionamiento de los cambios.
Ademas, se encapsulo todo el codigo suelto que acceda a la base de datos.

6.6.4 Migracion de radiator

Para la migracion del servidor Radius, se tuvieron que realizar varios cambios
para el uso de la base de datos SQLite. Ademas, se realizaba una profunda
reestructuracion de las querys, ya que bastante de ellas no estaban correcta-
mente programadas. Algunas de ellas usaban subquerys dentro del apartado
de SELECT, as que se aprovecho la migracion para fixear errores.

39
6.6.5 Migracion de los servidores

Una vez que todos los puntos anteriores estaban solucionados y estaban per-
fectamente funcionales, se empezo con la migracion entera de los dos servi-
dores. Lo primero que se decidio fue en que servidor se usara para hostear
todo produccion, ya que en el servidor develop dispona de dos cores y de
4GB de ram. Estos apenas eran usados, un 2% por el entorno develop, se
decidio usar la misma maquina tanto para develop como para produccion.

Para la migracion, el primer paso fue agregar en el servidor apache los dos
hosts, a los que la maquina tendra que responder: ilikefreewifi.com y socia-
landbeyond.com. Al igual que como se hizo con el entorno develop, dispone
de cada hosts de sus propios logs independientes. Sin embargo, a diferencia
de develop no se uso un entorno NFS y Dropbox para sincronizar el reposi-
torio, sino que el repositorio estaba en un directorio concreto. De ah, cada
vez que se realizaba un cambio en produccion se sincronizaba el contenido
local con el directorio web.

6.7 Backups
Las Copias de Seguridad son replicas de datos que nos permiten recuperar
la informacion original, en caso de ser necesario.
Sin embargo, para realizar copias de seguridad se necesita espacio de alma-
cenamiento de datos adicional. As pues, es necesario realizar un analisis
sobre que datos son necesarios para realizar copias de seguridad, de que tipo
y donde se guardaran.

6.7.1 Analisis

Lo primero que se decicidio analizar, era donde guardar estas copias de seguri-
dad. Exista la posiblidad de poder guardarlas localmente mediante unidades
de almacenamiento de datos. Esta solucion, existente en la gran mayoria de

40
Centro de procesamiento de datos (CPDS), no era una opcion realmente vi-
able, ya que era necesario hardware adicional y una infraestructura local de
la que no se dispona.
Debido a que toda la infraestructrura estaba en nodos virtuales en el cloud,
se decidio usar alguna de las herramientas adicionales que el cloud propor-
cionaba. La opcion mas adecuada era una adaptacion del S3 de Amazon Web
Services, que funcionaba de forma muy similar (algunas opciones avanzadas
no estaban habilitadas). Este tipo de servicio proporciona un nodo virtual
para almacenar datos mediante la API dada. Ademas, el coste de este servi-
cio esta basado en datos almacenados a un precio muy reducido.
(Este sistema S3 se basa en buckets, son una especie de directorios virtuales
donde se guardan los datos.)

6.7.2 Implementacion

El primer punto de la implementacion fue la realizacion de los scripts nece-

sarios para usar este sistema de copias de seguridad. Se desarrollaron dos, un
manager por terminal el cual permite ciertas funcionales rapidas como crear
bucket, borrar, listar ficheros de un bucket, guardar un fichero en un bucket,
etc.
El segundo script no era interactivo, funciona pasando un fichero como
parametro y este automaticamente lo almacena en un bucket. La idea de
estos dos scripts es que, mientras uno daba ciertas operaciones para obtener
o listar las copias de seguridad de forma rapida, el otro permita automatizar
los backups sin necesidad de interactuacion externa.

Se decidio realizar backups de los siguientes componentes:

Logs: Ficheros donde se guardan todo tipo de accesos, errores e infor-

macion de los servicios del sistema. Entre todos los que se decidieron
para realizar backup debido a su importancia, fueron los del servicio
web de produccion y sobretodo el log del servicio radius de produccion.
Segun la regulacion de la comision del mercado de las Telecomunica-
ciones, al ofrecer un servicio abierto de conexion a internet debemos

41
 de tener guardados todos los accesos realizados, durante al menos tres
meses.
Al ser un fichero en texto plano, que ocupa muy poco, se configuro
para realizar copias de seguridad diarias y completas sobre el log del
da anterior y ademas comprimido.

Base de datos: todos los datos de los clientes, como las estadsticas
estan almacenados aqu. Resulta de vital importancia realizar copias
de seguridad por si se pierden. Como la base de datos esta en SQLite,
se basa en un fichero de pocos MB. SQLite no proporciona ninguna
herramienta para poder realizar dumps de los datos, por lo que se
decididio realizar backups completos y diarios.

Imagenes de los portales: los clientes suben o cambian los portales,

en caso de perdida es importante poder tener copias de seguridad de el-
los. El tamano de las imagenes esta en total por encima de los 200MB,
utilizar una estrategia de backups completos no era lo mas idoneo de-
bido al gran volumen y el coste producido por ello. As pues, se decidio
realizar un backup completo semanal y luego realizar backups incre-
mentales (guardar los cambios respecto al ultimo backup semanal) cada
da.

6.7.3 Conclusion

Herramientas como S3 u otros complementos como glaciel, que permite

almacenar GB de datos por apenas diez centimos al mes, es una alterna-
tiva muy interesante enfrente a otros sistemas clasicos. Comparado con
otras soluciones clasicas, como el uso de cintas, dispositivos opticos o
discos, no pueden proporcionar esta relacion de tamano/precio, (sin
contar el coste adicional energetico y/o infraestructuras adicionales
necesarias para una implementacion fsica).

42
6.8 Replicacion
Uno de los objetivos de los que se hablo previamente, era conseguir que el
sistema estuviese siempre disponible, aunque fallase alguna maquina. Al
concentrar bastantes servicios en pocas maquinas, se corre el riesgo de que
un fallo pueda colapsar todos los servicios.
Para evitarlo, se necesita replicar el servicio, mediante una maquina identica
a la principal que, si la primera falla, esta coge el control y la sustituye.
Para conseguirlo, es necesario una base de datos que se pudiese replicar. Es
decir, que existiese en ambos servidores y en la que cualquier cambio que se
realizase, se propagase en ambas maquinas. Al no ser posible con la base
de datos SQLite, se decidio aplicar un sistema manual que cuando detectase
cambios en la base de datos del servidor principal, realizase una copia en la
maquina secundaria.
Como sistema de sustitucion, se planeo usar una tecnologa disponible en
muchos sistemas cloud: una tercera maquina que redirigiese el trafico a uno
de los dos servidores dependiendo de su estado.

6.9 HTTPS, SSL/TLS

SSL significa Secure Socket Layer y es un protocolo con dos funciones:

Cifrado:
Cifra los datos, lo que significa que cualquier nodo intermediario no se
debera poder ver lo que el navegador enva al servidor, ni lo que el
servidor enva al navegador.

Autentificacion:
Autentifica el sitio web, lo que significa que le dice al navegador, que
ese sitio es quien realmente dice ser.

El funcionamiento de TLS esta descrito mediante los siguientes pasos:

El cliente enva al server la version de SSL disponible, parametros del

cifrado, datos especficos de sesion y alguna informacion mas, necesaria
para establecer la conexion con el servidor.

43
 El server manda al cliente la version de SSL soportada, configuraciones
de cifrado, datos especficos de sesion y ademas manda su propio cer-
tificado.

EL siguiente paso es que el cliente usa la informacion enviada por el

servidor para autentificar el servidor. Es decir, comprobar que el certi-
ficado del servidor coincide realmente con el que dice ser. Para ello se
usa una entidad certificadora, quien ha tenido que autenficar este cer-
tificado. Si no ha sido as o el navegador no tiene incluido esta entidad
como fiable, en la lista saldra una advertencia.

Con los datos generados y compartidos el cliente, con la cooperacion

del server dependiendo del tipo de cifrado, crea una clave pre-master
secreta para la sesion. Con la que se encripta mediante la llave publica
del servidor, obtenida del certificado en el paso 2, entonces enva la
llave encriptada al servidor.

Tanto el cliente como el servidor usan la clave secreta para generar las
llaves de la sesion, que son simetricas.

Sin embargo, al usar HTTPS, el handshake descrito hace un momento ocurre

antes de que el servidor vea algun header http. Por tanto, en un sistema con
multiples dominios en un servidor como el nuestro, el servidor al no poder
saber que certificado usar, no podra establecer la comunicacion con el cliente.
Parte de este problema se podra solucionar con certificados Wildcard.
Este tipo de certificados pueden responder a multiples subdominios de un
dominio, esto podra ser util para algunos de los subdominios utilizados, sin
embargo al tener dos dominios distintos no servira. Ademas, como contra-
parte, este tipo de certificados son mucho mas caros que los normales.

La solucion escogida fue utilizar una extension de TLS llamada SNI (ser-
vice name indication) el qual habilitaba el paso del nombre del dominio en el
handshaking, permitiendo al servidor utilizar el certificado correcto. Como
contraparte, en ciertos navegadores con ciertos sistemas operativos no fun-
ciona este correctamente, lanzando una advertencia de certificado no seguro.

44
No obstante, las plataformas afectadas eran muy reducidas. Las platafor-
mas afectadas son Internet explorer anterior a la version 6 o cualquier IE en
windowsXP y algunos android 2.x con el navegador por defecto.

6.10 Administracion de los dispositivos

Una parte importante de vender dispositivos configurados con el software
necesario para realizar el portal cautivo, es disponer de algua forma para
poder acceder a ellos. Ya sea para cambiar algun tipo de configuracion in-
terna, como resolucion de problemas o simplemente por rutinas de compro-
bacion del correcto funcionamiento del dispositivo.

Segun el tipo de de red en la que este nuestro dispositivo, existen varios

casos para poder acceder, estos son:

Figure 11: Appliance dispone de una IP publica.

45
 Figure 12: Router realiza port forwarding.

Figure 13: Configurando una red virtual.

En el primer caso, se adjudica una IP publica al appliance, al ser una

IP publica conocida se puede administrar directamente ,sin necesidad de
ninguna configuracion adicional. Sin embargo, las IPs publicas son caras
y en la mayora de instalaciones no tienen IPs publicas para darlas a sus

46
dispositivos internos.
En el segundo caso, al tener el router una IP privada, (que es lo mas comun),
no se puede conectar directamente. En este caso, la conexion se establece
hacia el router de salida a traves de su IP de salida y un puerto. Es este el
encargado de redirigir la conexion hacia el puerto deseado del appliance.
El metodo de la tercera figura se basa en crear una red local virtual, se
consigue encapsulando un paquete IP sobre otro. As, cuando llega a su
destino al quitar la cabezera IP de internet, queda la cabecera de la red
local.
Para mantener un modo de acceso generico viable para todos los dispositivos,
la primera y segunda forma quedan automaticamente descartada. En el
primer caso, no es muy comun que la empresa tenga IP publicas para repartir.
En el segundo caso, es necesario realizar distintas configuraciones en el router
y no sera posible siempre que fuese ni el mismo puerto, ni que se permitiese
hacerlo.

6.10.1 Eleccion del tunel

Una vez decicido que era necesario crear una red virtual para poder admin-
istrar los dispositivos, solo quedaba escoger cual era el mejor metodo para
hacerlo. Para ello, se estudio distintos protocolos para ver cual encajaba
mejor para este caso:

PPTP:
Es un protocolo basico de tunneling publicado en 1999 por un consorcio
de empresas, en las que se incluye Microsoft, Alcatel, 3COM y otros.
La especificacion de pptp no describe un metodo de autentificacion y
encriptacion, sino que deja a las comunicaciones que viajen en la red
que se encargen de la seguridad. Algunas de las versiones mas moder-
nas pueden llegar a usar una encriptacion RSA de 128 bits.

En tema de seguridad, este protocolo se considera bastante inseguro

y se han detectado bastantes vulnerabilidades, en varias de sus ver-
siones. Ahora mismo, Microsoft recomienda que se use otros metodos

47
 de tuneling.
Debido a su encriptacion, el overhead que implica es el menor de todos,
convirtendolo en el mas rapido.
PPTP usa el puerto TCP 1723 y el protocolo GRE (protocolo 47).

L2TP/IPSEC
Es un conjunto de herramientas avanzadas, ahora mismo se aconseja
por Microsoft como sustituto de PPTP, para todas aquellas comunica-
ciones que tengan que ir encriptadas.
El payload de L2TP es encriptado usando el standar IPSec protocol.
El algoritmo mas seguro que acepta estas herramientas, es AES 256 bit
keys.
En vulnerabilidades de seguridad, IPSec no tiene ninguna vulnerabili-
dad mayor y se considera extremadamente seguro, cuando es usado con
un algoritmo de encriptacion muy seguro como es el AES.
En tema de rendimiento L2TP/IPSec tiene un overhead mayor, debido
a su doble encapsulacion, muy similar al OpenVPN.
En temas de configuracion de red, L2TP/IPSEC usa el puerto UDP
500 para el primer intercambio de llaves, el protocolo 50 para el envo
de datos encriptados, el puerto UDP 1701 para la configuracion inicial
del tunel y el puerto UDP 4500 para realizar el NAT traversal.
Sobre compatibildad, este tipo de tunel es bastante mas difcil de con-
figurar que las otras opciones. Ademas, el cliente tiene que soportar
NAT traversal.

OpenVPN
Considerado como el estandar, dentro del conjunto de protocolos de
tuneleado (dentro de opensource).
En temas de encriptado, se usa el mas que probado protocolo de en-
criptacion SSL/TLS, mediante la herramienta OpenSSL. Soporta bas-
tantes tipos de encriptacion como: 3DES, AES, RC5, Blowfish. Ademas,
la posiblidad de usar el extremadamente seguro AES-256bits.
En temas de seguridad, no se conoce ningun tipo de vulnerabilidad
hasta el reciente descubrimiento del bug de seguridad en la libraria SS-

48
 L/TLS, conocido como HeartBleed.
Funciona a traves de un puerto TCP o UDP, pudiendolo configurar en
cualquier tipo de puerto.
Aunque no esta incluido en ningun sistema operativo de forma nativa,
s que esta instalado en la mayora de dispositivos networking utiliza-
dos.
Se considera el mas rapido y estable, sobretodo en dispositivos moviles.
Como se ha explicado previamente, el objetivo de tener un tunel es poder
conectarse a cualquiera de nuestros dispositivos independientemente de la
infraestructura de red en la que este. Intentando as evitar cualquier firewall
existente entremedio.
Como solucion: usar un tunel PPTP tena ciertas ventajas, es extremada-
mente facil, funciona con un usuario contrasena para poder entrar. Aunque
fuese muy inseguro, al crear una red virtual que solo serva para poder co-
municarse entre servidor y dispositivo, (no para enrutar cualquier tipo de
trafico), se poda relegar el tema de seguridad al protocolo SSH (secure shell).
Incialmente, el unico que se iba a permitir; sin embargo, exista un inconve-
niente bastante importante, como era no ser posible de configurar el puerto.
Por ello se usaba el protocolo GRE, que podra ser filtrado por algun firewall
existente.

IPSec en cambio, es bastante mas seguro que el PPTP. Aunque tena ciertos
problemas de compatibildad con algun dispositivo usado para nuestro servi-
cio. Ademas el no poder adaptar el puerto TCP/UDP usado y tener otro
protocolo distinto, haca que no fuese una opcion aplicable.

OpenVPN aportaba, como el IPSec, seguridad tambien y se puede config-

urar el puerto TCP/UDP que se desee, sin utilizar ningun otro protocolo
extra para la comunicacion. Ello aportaba la flexibilidad y la adaptabili-
dad deseada para este parte. Configurando el puerto del server al 443 TCP
(comunmente usado para HTTPS) , posiblemente el puerto menos cerrado
por cualquier tipo de firewall existente, se evitaba gran parte de los problemas
de la existencia de firewalls. Como extra, al usar certificados de SSL/TLS

49
donde se puede configurar el CN del certificado/llave usada por el cliente,
permita poder distinguir facilmente la relacion entre dispositivo e IP de la
VPN. Por tanto, fue la opcion escogida.

Figure 14: Visualizacion MAC-IP de OpenVPN.

6.10.2 Implementacion

Se decidio provisionar una nueva maquina Linux para usarla como servidor
del tunel. Usando TCP y puerto 443 para evitar firewalls, encriptacion AES-
256 por ser la mas segura, ademas se cambio la ejecucion del servicio una vez
inicializado al usuario del sistema nouser y al grupo nogroup. Se reducan
as los privilegios del servicio, una vez arrancado.

50
6.11 Monitorizacion de servidores
Telefonica cloud computing dispone de varias formas de monitorizacion de
las maquinas en forma de graficas y estadsticas de gran utilidad.

Figure 15: Grafica de consumo de red.

Para complementar este tipo de monitorizacion, (que solo se poda con-

sultar por el portal de Telefonica Cloud Computing), se desarrollaron dos
servicios mas. Estos comprobaban el funcionamiento del servidor Web de
produccion y el funcionamiento del servidor Radius de produccion. Si este
fallase, recibiramos un mail de alerta avisandonos de este problema.

Figure 16: Email ejemplo de fallo de servidor.

51
 Gracias a este servicio, en caso de fallo de estos servicios, nos permitira
conocerlo aunque no hubiese nadie en la oficina.

6.12 Servicio generador de graficas

El mision control ofrece ciertas opciones de visualizaciones de datos para los
clientes mediante highcharts y highstock, un plugin de javascript. Esta fun-
cionalidad aunque muy completa, tena una carencia importante: la necesi-
dad obligada del cliente a acceder al mission control, para poder ver es-
tadsticas sobre los datos mas importantes.

Para solucionar esta problematica, basandose en el objetivo de la automati-

zacion, se decidio desarrollar un sistema que pudiese enviar ciertas graficas
al cliente. Este sistema tena que ser de estetica similar a las graficas desar-
rolladas en el mission control.
Para ello, se decidio desarrollar un script en Nodejs, con el plugin de high-
charts. Este script crea un servicio http que escucha cualquier peticion que
recibe, recoge los datos va get, genera la imagen, y devuelve ciertos datos
en formato json, (entre ellos la url donde se puede obtener la imagen).
Desde un cron, se llama un script php que accede a la base de datos, recoge
los datos en cuestion enva la peticion a nodejs y luego obtiene la imagen
para poder enviar mails informativos sobre los datos de cada cliente.

52
Figure 17: Ejemplo de grafica generada con nodejs.

Figure 18: Ejemplo de grafica generada con nodejs.

53
6.13 Automatizacion de servidores
6.13.1 Introduccion

Es bastante tpica la posiblidad de crear una instantanea de un Servidor vir-

tual. Esta instantanea permite crear una imagen clon del servidor, pudiendolo
restaurar cuando se necesite. A diferencia del backup, no hace una copia a
los datos, sino a todo el sistema operativo.
Sin embargo, la plataforma de Telefonica no dispona de esta opcion. Lo
mas similar que tenan, implicaba que la maquina a la que se quiesiese hacer
tendra que estar varios das apagadas. Por lo tanto, se descarto y se busco
otro metodo.

Como la informacion importante estaba en backups, se penso en otro metodo

para llegar a la misma solucion que una instantanea. Este metodo tena que
recrear todo el servidor, configuraciones de programas, crear usuarios, gru-
pos, configurar permisos, es decir recrear todo el servidor.

6.13.2 Chef

Chef es una infraestructura de automatizacion de plataformas que permite

crear codigo para configurar diferente tipos de plataformas. Es decir, te
permite crear codigo para configurar servidores de los cuales es independen-
diente. Chef ha sido elegido por empresas como Facebook y Amazon.

El usuario escribe recetas que describen como Chef gestiona las apli-
caciones de servidor (como Apache, MySQL, o Hadoop) y como se debe
configurar. En estas recetas se describen una serie de recursos que deben
estar en un estado determinado: que se instalen paquetes, el estado de eje-
cucion de los servicio, o los archivos que deben ser escritos. Chef asegura que
cada recurso esta configurado y corrige los archivos de recursos que no estan
en el estado deseado.

54
 El entorno tpico chef se compone de 3 partes: el servidor Chef , la estacion
de trabajo y nodos.

Figure 19: Esquema de un entorno chef.

El servidor Chef es como el cerebro de la operacion. Almacena la infor-

macion sobre la infraestructura, as como las recipes (codigo para programar
los servidores).
La estacion de trabajo es el lugar donde se crean las recipes para que poste-
riormente se suban al servidor, es el lugar donde se realiza el desarrollo.
La estacion de trabajo es el lugar donde pasara la mayor parte de su tiempo
de trabajo con el Chef . Es el mismo lugar en el que hace su desarrollo o de
administrador de sistemas.

55
 El nodo es un servidor de la infraestructura. Los nodos son los equipos
donde se va a aplicar la recipe, ya sea un equipo fsico, virtual o este en la
nube.

6.13.3 Recipes

Por el momento se ha desarrollado las siguientes recetas:

Apache: Receta que se encarga de instalar y arrancar el servicio de

apache. Funciona en cualquier entorno Unix/Linux.

Prepare-apache: Receta que configura todos los directorios, configura

el apache con nuestro sevicio, certificados de seguridad, ademas de
preparar el entorno beta, develop y master. Probado en debian/ubuntu
y smartos.

Nfs-Client: Instala, configura y monta el directorio compartido por

NFS de forma automatica, probado en debian/ubuntu/smartos.

Nfs-Server: Configura y arranca el servicio de nfs-server. Probado en

Ubuntu.

Nodejs: Instala nodejs, el plugin highcharts, el programa que genera

graficas, ademas de configurar el iptables para redirigir el puerto, ar-
ranca el programa.

Users: Crea, configura los usuarios y los grupos, ademas de preparar el

entorno. Probado en Unix/Linux.

Dropbox: Instala y configura el servicio de dropbox por cada develop.

Probado en Ubuntu.

Backups3: Instala todos los paquetes necesarios para poder ejecutar el

script que permite realizar backups, aparte de configurar los crons para
realizar los backups.

56
 Openvpn: Instala, configura y arranca el servicio de openvpn para
gestionar los dispositivos networking.

Pptp: Instala, configura y arranca el servicio de pptp para gestionar

los dispositivos networking.

Radiator: Instala, configura y arranca el servicio de radiator.

Sudoers: Configura el archivo sudoers, probado en linux/unix.

i f node [ p l a t f o r m ] == s m a r t o s

package py27e x p a t

package s c m g i t b a s e

end

i f node [ p l a t f o r m ] == ubuntu

package g i t

end

git /tmp/ boto do

repository h t t p s : / / g i t h u b . com/ boto / boto . g i t

action : sync

end

execute i n s t a l l boto do

command cd /tmp/ boto && python /tmp/ boto / s e t u p . py i n s t a l l

end

cookbook_file / u s r / l o c a l / b i n / backupprod . py do

source backupprod . py

mode 0744

57
 owner r o o t

group r o o t

end

cron backup l o g s i l i k e f r e e w i f i do

minute 0

hour 5

day

month

command python / u s r / l o c a l / b i n / backupprod . py

/home/ i l i k e f r e e w i f i . com/ l o g s / a c c e s s l o g . 0
/home/ i l i k e f r e e w i f i . com/ l o g s / e r r o r l o g . 0

action : create

end

cron backup s o c i a l a n d b e y o n d do

minute 3

hour 5

day

month

command python / u s r / l o c a l / b i n / backupprod . py

/home/ s o c i a l a n d b e y o n d . com/ l o g s / a c c e s s l o g . 0
/home/ s o c i a l a n d b e y o n d . com/ l o g s / e r r o r l o g . 0

action : create

end

cron backup r a d i a t o r do

minute 5

hour 5

58
 day

month

command python / u s r / l o c a l / b i n / backupprod . py

/ v a r / l o g / r a d i a t o r / prod / a u t h l o g i l f w p r o d r a d i u s . 0
/ v a r / l o g / r a d i a t o r / prod / l o g f i l e i l f w p r o d r a d i u s . 0

action : create

end

cron backup d a t a b a s e do

minute 7

hour 5

day

6.14 AutoProvisionamiento
La razon de este sistema es proporcionar una plataforma confiable y estable,
para cualquier empresa que quiera vender nuestro producto. Este sistema
esta preparado para poder configurar cualquier tipo de Mikrotik con solo 1
archivo ( supplier.auto.rsc ). Este archivo se genera y forman las ubicaciones
de las ventanas Control de Mision.

Uno de los requisitos del sistema es, para hacer mas facil tal y como sea
posible para el usuario no tecnico, llevar a cabo el proceso . Por lo tanto,
se ha disenado para que solo se requiera subir un unico archivo para que el
usuario incie el proceso.

Sin embargo, en ese script no esta toda la configuracion. Sino que solo
se conecta a un servidor pptp, ya que es el tipo de tunel que no necesita
mas archivos. Una vez ah, existe un proceso que comprueba si hay algun
dispositivo conectado para continuar con el proceso.

59
Segun las fases:
El primer archivo configura el mikrotik dandole acceso a internet (eth0
con dhcpclient), drop de cualquier regla de firewall por defecto que evitase
tener conexion, ademas de configurar el tunel PPTP.

El primer tunel se realiza mediante pptp, porque es mas facil de configu-

rar y no necesita archivos adicionales como los certificados.

El servidor comprueba entonces la version del firmware, para ver si es nece-

sario actualizarla o no, siendo la ultima que conocemos la que funciona cor-
rectamente para nuestro servicio.

A continuacion, es el encargado de subir los archivos necesarios para el servi-

cio, como pueden ser los distintos certificados necesarios tanto para el servicio
como para el openvpn.

A continuacion, cambia el password del dispositivo a uno generado de forma

aleatoria y almacenado en la base de datos.

El ultimo archivo que se sube es un script autoejecutable, que actua como

una rutina de carga suficiente para configurar los ajustes del router, para
poder llevar a cabo una updateappliance.

Cuando se carga de esta configuracion, se realiza updateappliance - descarga

la ultima configuracion desde el servidor para establecer los parametros para
cada router en particular ( estatico o dinamico Wan IP , IP local, SSID ....).
Despues de esta configuracion, para demostrar que ha acabado, el aparato
encendera los leds de cierta forma y si es compatible, sonara una cancion.

60
 Figure 20: Diagrama del proceso de provisionamiento.

6.15 DenyHosts
Al revisar los logs de los servidores, se encuentran muchos tipo de ataques:
ordenadores que intentan entrar en la maquina, es tpico que intenten entrar
a traves del servicio de SSH, ya que suele estar abierto.
Evitarlo es bastante sencillo, solo hace falta cambiar en la configuracion de
SSH el acceso a la maquina con password. Es decir, solo se permite acceder
a la maquina que tenga la llave privada a juego con las llaves publicas, que
se permite acceder a ese usuario en concreto.

Aun as, los ataques son bastante molestos apareciendo sin parar en los logs

61
del sistema. Por lo tanto, se decidio primero bloquear a las IPs de los at-
acantes a traves de denyhosts, este programa comprueba en el log intentos
de acceso fallidos. Guarda la informacion de la IP original de los accesos,
el numero de intentos y comprueba si supera el lmite permitido. Si es as,
asume un intento de fuerza bruta y bloquea el acceso de esta IP. Ademas,
las ultimas versiones de DenyHosts sincronizan y centralizan la informacion
de los atacantes, estando disponible para cualquiera.

Finalmente, se creo un script que, con la informacion obtenida del intento

de atacar, obtiene informacion de a que sistema autonomo pertenece la IP
(tpicamente pertenecera a un ISP). Recogiendo todos los emails que estan
disponibles (priorizando abuse-email si existen) e escriben un mail infor-
mando del ataque y aportando las pruebas obtenidas del log.

Figure 21: Email informando un ataque SSH

62
7 Estudio economico
Al haber realizado el proyecto en una empresa, este ha tenido un coste cal-
culable para ella, teniendo en cuenta que:

El contrato es un convenio de cooperacion educativa, con un numero

estipulado de horas laborables y un coste fijo por hora.

El director ha proporcionado parte de su horario laboral para asistir a

la elaboracion del proyecto.

Se ha proporcionado parte del material para poder desarrollar el proyecto,

como tambien el acceso a las plataformas necesarias.

Desglosando los anteriores puntos, el coste estimado es:

Salario:
Coste por hora: 8 e.
Horas: 680h
Coste: 5.440 e.

Dispositivos: Los costes debidos a la adquisicion de distintos disposi-

tivos para testing, se estiman en 350 e.

Agregando los costes, tenemos un coste final de 5.790 e.

7.1 Calculo de rentabilidad

Se ha realizado una estimacion del tiempo necesario que tardara la empresa
en recuperar el dinero invertido para la realizacion del proyecto.

Ahorro por el servicio de control de antenas wireless, al conseguir el mismo

servicio utilizando 3 maquinas menos, se ha conseguido un ahorro estimado
de 240 e.

63
al mes.
Los cambios realizados en el entorno de develop han conseguido aumentar la
produccion de los developers. Se ha estimado que gracias a la simplifacion
y el aislado de los entornos entre s, se ha conseguido al menos un aumento
de un 10%. Al ser 3 developers (dos front-end y 1 back-end), este aumento
implicara al menos un ahorro de unos 350 e.
al mes. (Es un calculo estimado ya que se desconoce el sueldo exacto de los
developers).

En el sistema de automatizacion de dispositivos realizada para las divisiones

de Canada y Russia, ademas de los partners como Telefonica, estan provisio-
nando 220 dispositivos de media al mes. Sin este sistema, el tiempo necesario
para provisionarlos de forma manual estara rondando las 12 horas, teniendo
un coste estimado de 96 e.
(No se contabiliza el tiempo perdido en mensajera y derivados, al no disponer
de esos datos)

Consiguiendo un ahorro total de 686 e al mes, en menos de 8 meses se

conseguira amortizar el coste total del proyecto.

64
8 Conclusiones
En este proyecto en donde se ha usado tecnologas tan diversas como nodejs
(plataforma de lado servidor para javascript), extjs, highcharts y highstocks
(para realizar graficas consistentes con el modelo de grafica presente en el mi-
sion control), sistemas operativos Unix, Linux, iptables (redireccionamiento
de puertos), chef (provisionamiento de servidores automatizado), git-bitbucket
(para control de versiones), protocolos de tuneleado (para administracion re-
mota de dispositivos), radiator (autentificacion de usuarios en la red), cron
(para automatizacion de tareas en el servidor), ademas de una extensa plan-
ificacion para un uso adecuado y rentable de los recursos TI, dando como
resultado un producto escalable, fiable, estable y flexible a las necesidades de
la empresa.

Como conclusiones personales estoy bastante satisfecho con los resultados

conseguidos. Considero que se han cumplido la gran mayora de los obje-
tivos establecidos al principio del proyecto.

Al partir de una estructura bastante mal disenada y tener que reestructurar

gran cantidad de esta, (ademas de que algunos pasos se tuvieron que realizar
sin tener una idea de como tendra que ser el resultado final), ha hecho que
tuviera que aplicar mucho de lo aprendido durante la especializacion de la
carrera. Conocimientos adquiridos en asignaturas como: redes de computa-
dores, protocolos de internet, administracion de sistemas operativos, teora
de redes de computacion y sistemas distribuidos, que han sido indispensables
para la realizacion del proyecto.

Este proyecto me ha permitido aprender, comprobar y reconcer los sistemas

virtuales al transformar un sistema fsico a uno virtual.

Tambien estoy agradecido el haber sido capaz de colaborar en un equipo joven

y dinamico, para poder cumplir todas las metas de la empresa. Destacar
sobretodo el poder haber sido capaz de responder y cumplir todas las re-

65
sponsabilidades crticas, que los responsables me han ido asignando. Ya sea
la configuracion y migracion de todo el servidor de produccion, como disenar
y gestionar el sistema de copias de seguridad o como desarrollar las platafor-
mas de provisionamiento automatizado. Sin embargo, cabe lamentar que no
haya podido acabar ciertas funcionales que queria aportar: como un sistema
totalmente replicado con ciertos anadidos extras, sea un balanceo de carga.

En conclusion, he disfrutado desarrollando este proyecto y de la estimable

compana de mis companeros de trabajo. Sobretodo de mi responsable,
Francesc Roma.

66
9 Bibliografa
Pagina wiki de SmartOS
http://wiki.smartos.org/display/DOC/Home

Paginas informativa sobre bases de datos:

http://db-engines.com/en/ranking

Pagina informativa sobre https y certificados

https://www.digitalocean.com/community/articles/how-to-set-up-multiple-ssl-
https://devcenter.heroku.com/articles/ssl-certificate-self

Paginas sobre protocolos de tuneling

http://www.giganews.com/vyprvpn/compare-vpn-protocols.html
https://www.ivpn.net/pptp-vs-l2tp-vs-openvpn

Pagina sobre chef:

http://www.getchef.com/chef/

Pagina sobre amazon web services:

https://aws.amazon.com/documentation/

Pagina sobre el plugin de S3 para la realizacion de backups.

http://boto.readthedocs.org/en/latest/ref/s3.html

Pagina sobre el bug de heerthbleed:

http://heartbleed.com/

Pagina sobre bash:

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html

Pagina sobre nodejs

http://nodejs.org/
https://www.npmjs.org/package/node-highcharts

Pagina sobre dispositivos mikrotik

http://wiki.mikrotik.com/wiki/Main_Page

67
10 Glosario
TI=Tecnlogas de la informacion.

VPN=Virtual private network (Red privada creada sobre internet, per-

mite conectar nodos remotos como si fuese una red privada.

GIT=Git es un software de control de versiones, pensando en la eficien-

cia y la confiabilidad del mantenimiento de versiones de aplicaciones
cuando estas tienen un gran numero de archivos de codigo fuente.

PPTP=Point to Point Tunneling Protocol, es un protocolo de tune-

leado.

NAT=Network Address Translation - Traduccion de Direccion de Red)

es un mecanismo utilizado por routers IP para intercambiar paque-
tes entre dos redes que asignan mutuamente direcciones incompatibles.
Consiste en convertir, en tiempo real, las direcciones utilizadas en los
paquetes transportados, entre otras cosas permite dispositivos de red
con direcciones privadas puedan acceder a Internet mediante la IP pub-
lica de otro dispositivo.

NFS=Network File System (Sistema de archivos de red), o NFS, es un

protocolo de nivel de aplicacion, segun el Modelo OSI. Es utilizado para
sistemas de archivos distribuido en un entorno de red de computadoras
de area local.

ISP=Internet service provider, compania encargada de darte acceso a

internet.

68
11 Anexo y futuras implementaciones

11.1 Hearthbleed
Considero que es importante hablar sobre el fallo de seguridad dentro de
OpenSSL llamado hearthbleed, por la gran importancia que ha tenido den-
tro de cualquier tipo de infraestructuras de sistemas.

Proclamado como el mayor fallo den la seguridad de Internet, provocado

por una vulnerabilidad de OpenSSL, librera de cifrado utilizada por la gran
mayora.
El bug exista en una funcion que gestiona los mensajes HeartBeat (de ah
el juego de palabras). La funcion de estos mensajes era avisar al servidor de
que la conexion aun exista, que aun se estaba conectado, para que no cerrase
la conexion despues del tiempo estipulado (time-out). Lo cual constitua un
mensaje muy normal para evitar sobrecargas, debido a tener que mantener
muchas sesiones.

Al enviar este mensaje, se devolva uno de igual longitud, el problema es

que no comprobaba la longitud del paquete enviado. Es decir, si se envi-
aba un mensaje de 1 byte pero indicando que ocupaba 1000bytes, la librera
devolva no solo el byte, sino que tambien devolva los 999 siguientes que hu-
biese en la memoria, una vez que se guardo el dato. Haciendo que se pudiera
obtener datos de todo tipo.

69
Figure 22: Vineta ilustrando el fallo de seguridad.

70
 Este bug es extremadamente grave, no nos llego a afectar, debido a que las
maquinas Unix usaban una version anterior a la primera afectada. As como
que la instalacion y configuracion de OpenVPN al configurar que librera de
OpenSSL iba a usar, se decidio utilizar la misma version que en el servidor
SmartOS, haciendo que tampoco fuese vulnerable al bug.

11.2 Migracion de dispositivos

Durante la realizacion del proyecto, se utilizaban ciertos dispositivos para
proveer el portal cautivo, existan dos tipos de productos:

Router Soekris6501: Router con Ubuntu server instalado y 4 puertos

gigabit, tena graves bugs de hardware, as como que los puertos giga-
bit no funcionaban correctamente. Obligandolo a instalar una tarjeta
adicional a la placa del router, ademas no era demasiado estable y que
su precio oscilaba los 300 euros.

Router-Wi-Fi picostation: Router-Wi-Fi, flasheado con el sistema op-

erativo OpenWRT, un tipo de antena ideal para locales pequenos donde
solo era necesario conectar la antena al router de salida para que fun-
cionas. El problema existente con esta antena es que ya no se poda
hacer cambios en el firmware por estar protegido con una contrasena
que estaba perdida, su precio ademas oscila los 60 euros.

Se estudiaron distintas soluciones en el mercado hasta encontrar dispositivos

Mikrotik, que funcionan con el sistema operativo RouterOS y son capaces de
crear un portal cautivo de forma nativa, compatible con bastantes tipos de
tunel.
Dispona de una gran gama de productos, desde routers Wi-Fi a partir de
40 euros, como routers con 16cores por aproximadamente 300 euros. Permi-
tiendo primero poder desplegar a cualquier tipo de negocio nuestra solucion
con una unica plataforma, ademas de conseguir una solucion mas asequible.

71
11.3 Instalaciones
Durante la realizacion del proyecto se tuvieron que asistir y configurar distin-
tas instalaciones en varios de nuestros clientes, usando distintas tecnologas,
como antenas controladas con controladora central, remota, tuneles a distin-
tas sedes, vlans, etc.

Algunos ejemplos:

Figure 23: Instalacion para el ayuntamiento de Girona con tecnologa punto

a punto.

72
Figure 24: Instalacion para el ayuntamiento de Girona con tecnologa punto
a punto.

11.4 Balanceo de carga

El sistema de replica, dispone de una maquina adicional para unicamente
dar acceso si la principal se cae. Balancear la carga es un sistema que divide
el trafico que va al servidor principal entre todas las replicass, permitiendo
tener un sistema altamente escalable ademas de fiable.

73
 Figure 25: Diagrama ilustrativo de un sistema de balanceo de carga.

Hay distintas formas de conseguir este efecto, ya sea por DNS, es decir
el DNS va contestando las distinas IPs de los servidores, como un nodo
intermedio (igualmente necesario para replica) que divide el trafico entrante
hacia los dos servidores. Ya sea de forma sencilla como IP origen par/impar,
como formas mas complejas teniendo el cuenta el trafico ya existente para
una mejor optimizacion.

74