Sunteți pe pagina 1din 162

TECNOLGICO DE ESTUDIOS

SUPERIORES DE COACALCO

Laboratorio de prcticas,
modelado en tecnologas libres

I. Tesis Profesional
PARA OBTENER EL TTULO DE
INGENIERO
PRESENTA

Daniel Campos Ojeda


Erick Johans Zamorategui Nava

COACALCO DE BERRIOZABAL, MX. ABRIL, 2012

Tabla de contenido

NDICE DE IMGENES...................................................................................................................VII

NDICE DE TABLAS ........................................................................................................................ XI

INTRODUCCIN ............................................................................................................................. 1

IDENTIFICACIN Y PLANTEAMIENTO DEL PROBLEMA ............................................................. 3

1.1

Justificacin....................................................................................................................... 5

1.2

Objetivos........................................................................................................................... 6

1.2.1

General.................................................................................................................................... 6

1.2.2

Especficos............................................................................................................................... 6

1.3

Alcances y Limitaciones ..................................................................................................... 7

FUNDAMENTOS TERICOS................................................................................................... 10

2.1

Cloud Computing ............................................................................................................. 11

2.1.1

Caractersticas del Cloud Computing .................................................................................... 11

2.1.2

Tipos de servicios .................................................................................................................. 13

2.2
2.2.1

Linux ............................................................................................................................... 15
Caractersticas de Linux ........................................................................................................ 15

2.3

Virtualizacin .................................................................................................................. 17

2.3.1

Hypervisor ............................................................................................................................. 17

2.3.2

Tipos de virtualizacin .......................................................................................................... 18

2.3.3

TFTP....................................................................................................................................... 22

2.3.4

Cliente ligero ......................................................................................................................... 22

2.3.5

PXE ........................................................................................................................................ 22

2.4

Seguridad Informtica ..................................................................................................... 23

2.4.1

Qu es encriptar y desencriptar? ........................................................................................ 24

2.4.2

Filtrado de contenido web .................................................................................................... 25

2.4.3

Monitorizacin ...................................................................................................................... 26

2.4.4

Ataque de denegacin de servicio (DDOS) ........................................................................... 28

2.4.5

Por qu proteger un servidor Linux de ataques por fuerza bruta? .................................... 30

EVALUACIN Y SELECCIN DE HERRAMIENTAS .................................................................... 31

3.1

Proyectos de Virtualizacin: Hypervisors .......................................................................... 32

3.1.1

XEN ........................................................................................................................................ 32

3.1.2

KVM....................................................................................................................................... 32

3.1.3

OpenVZ ................................................................................................................................. 33

3.1.4

VirtualBox ............................................................................................................................. 33

3.1.5

VmWare ................................................................................................................................ 33

3.1.6

Resultados de la evaluacin de hypervisors ......................................................................... 34

3.2

Gestin de Mquinas Virtuales: Plataformas de Virtualizacin .......................................... 35

3.2.1

VmWare: Server, Player, ESXi ............................................................................................... 36

3.2.2

Oracle Linux, Oracle Solaris .................................................................................................. 37

3.2.3

Proxmox ................................................................................................................................ 38

3.2.4

XenServer .............................................................................................................................. 38

3.2.5

Resultados del anlisis de los gestores de mquinas virtuales: ........................................... 38

3.3

Software Para Montar Un Servidor de Clientes ligeros ...................................................... 40

3.3.1

TCOS ...................................................................................................................................... 40

3.3.2

LTSP ....................................................................................................................................... 41

3.3.3

OpenThinClient OS ................................................................................................................ 42

3.3.4

Resultado de la evaluacin de herramientas para montar servidores de clientes ligeros ... 43

3.4

Seguridad ........................................................................................................................ 44

3.4.1

Encripcin AES ...................................................................................................................... 44

3.4.2

OpenDNS............................................................................................................................... 46

3.4.3

Monitorizacin ...................................................................................................................... 47

3.4.4

Solucin en Ubuntu para Bomba Fork .................................................................................. 49

3.4.5

Proteccin de ataques por fuerza bruta con Fail2ban.......................................................... 51

PROPUESTA DEL MODELO DE RED ........................................................................................ 53

4.1

Descripcin del Modelo ................................................................................................... 54

4.2

Computadoras Cliente ..................................................................................................... 55

4.2.1

Computadoras obsoletas ...................................................................................................... 55

4.2.2

Clientes ligeros dedicados .................................................................................................... 58

4.3

Servidor virtual de clientes ligeros.................................................................................... 58

4.3.1

Memoria ............................................................................................................................... 58

4.3.2

Procesador ............................................................................................................................ 59

4.3.3

Disco duro ............................................................................................................................. 59

4.4

Servidor de mquinas virtuales ........................................................................................ 60

4.5

Red ................................................................................................................................. 62

4.5.1

Red cableada......................................................................................................................... 62

4.5.2

Red inalmbrica .................................................................................................................... 63

4.5.3

Resumen ............................................................................................................................... 64

PRUEBA VIRTUAL DEL MODELO DE RED................................................................................ 66

5.1

Elementos Utilizados en la Prueba ................................................................................... 67

5.1.1

Servidor ................................................................................................................................. 67

5.1.2

Hypervisor ............................................................................................................................. 67

5.1.3

Servidor virtual de clientes ligeros........................................................................................ 68

5.1.4

DHCP ..................................................................................................................................... 68

5.2

Iniciando la Prueba .......................................................................................................... 70

5.3

Resultado de la Prueba .................................................................................................... 74

CONSIDERACIONES, CONCLUSIONES Y TRABAJOS FUTUROS ................................................. 76

6.1

Aspecto Econmico ......................................................................................................... 77

6.2

Aspecto Ambiental .......................................................................................................... 78

6.3

Aspecto Tecnolgico ........................................................................................................ 79

6.4

Aspecto Educativo ........................................................................................................... 79

6.5

En Resumen .................................................................................................................... 81

6.6

Conclusiones ................................................................................................................... 82

6.7

Trabajos Futuros .............................................................................................................. 87

REFERENCIAS ............................................................................................................................... 89

ANEXOS ..................................................................................................................................... 93

ANEXO A: ESCENARIO DEL SOFTWARE LIBRE EN AMBIENTE PROFESIONAL .................................... 94

ANEXO B: LICENCIAS DE SOFTWARE ............................................................................................. 96

ANEXO C: TIPOS DE RED EN AMBIENTES VIRTUALES ..................................................................... 98

ANEXO D: RECOMENDACIONES PARA REGLAMENTO, SEGURIDAD FSICA Y CONTRA INCENDIOS,


SEGURIDAD EN CONTRASEAS .................................................................................................... 99

ANEXO E: HERRAMIENTAS DE SOFTWARE LIBRE ......................................................................... 103

ANEXO F: HOW TO: INSTALACIN DE PROXMOX ........................................................................ 105

ANEXO G: HOW TO: INSTALACIN DE LTSP EN UBUNTU 11.04 .................................................... 108

ANEXO H: COMO ENCRIPTAR SISTEMA OPERATIVO .................................................................... 112

ANEXO I: HOW TO: INSTALAR MUNIN ........................................................................................ 122

ANEXO J: HOW TO: INSTALAR CONKY ......................................................................................... 128

ANEXO K: EJEMPLO DE UNA BOMBA FORK ................................................................................. 138

ANEXO L: HOW TO: INSTALAR FAIL2BAN .................................................................................... 140

GLOSARIO DE TRMINOS TCNICOS ........................................................................................... 145

ndice de Imgenes
Figura 1: Internet como Red de Dispositivos ......................................................................................... 11
Figura 2: Estructura de Cloud Computing .............................................................................................. 13
Figura 3: Representacin de un hypervisor con tres maquinas virtuales .............................................. 18
Figura 4:Emulacin por hardware .......................................................................................................... 18
Figura 5: El hypervisor media entre el hardware y la mquina virtual .................................................. 19
Figura 6: En la paravirtualizacin se comparte el proceso con el SO invitado....................................... 20
Figura 7: Aislamiento de servidores ....................................................................................................... 21
Figura 8: Proceso de encripcin ............................................................................................................. 24
Figura 9: Ataque de denegacin de servicio distribuido ........................................................................ 28
Figura 10: Funcin de procesos Fork...................................................................................................... 29
Figura 11: Diagrama VmWare ESXi ........................................................................................................ 36
Figura 12: Virtualizacin con Solaris ...................................................................................................... 37
Figura 13: Diagrama de red TCOS .......................................................................................................... 41
Figura 14: Diagrama del proyecto LTSP.................................................................................................. 41
Figura 15: Esquema de openThinClient OS ............................................................................................ 42
Figura 16: Verificar si ha quedado de manera correcta el nmero de procesos mximos ................... 50

Figura 17: Como hacer una Bomba Fork desde consola ........................................................................ 50
Figura 18: Solucin de Bomba Fork correcta ......................................................................................... 50
Figura 19: Modelo de infraestructura Cloud.ia ...................................................................................... 54
Figura 20: Diagrama del servidor de mquinas virtuales ....................................................................... 61
Figura 21: Diagrama de red completo.................................................................................................... 65
Figura 22: Appliance de openThinClient OS ........................................................................................... 68
Figura 23: Men de opciones VirtualBox ............................................................................................... 69
Figura 24: Diagrama de red virtual......................................................................................................... 70
Figura 25: Estado inicial de la red........................................................................................................... 71
Figura 26: Diagrama de red final de la prueba ....................................................................................... 73
Figura 27: openThinClient sin clientes conectados ................................................................................ 73
Figura 28: openThinClient con un cliente conectado ............................................................................ 73
Figura 29: openThinClient con diez clientes conectados ....................................................................... 74
Figura 30: openThinClient un cliente conectado y firefox ..................................................................... 74
Figura 31: Consumo de recursos del servidor con 10 maquinas virtuales simultneas ........................ 75
Figura 32: Cuota de mercado de Sistemas operativos de escritorio ..................................................... 94
Figura 33: Cuota de mercado de sistemas operativos desde el punto de vista del desarrollador ........ 95
Figura 34: Inicio de Proxmox ................................................................................................................ 105

Figura 35: Configuracin de pas y teclado de Proxmox ...................................................................... 105


Figura 36: Contrasea y correo de administrador ............................................................................... 106
Figura 37: Datos de la red .................................................................................................................... 106
Figura 38: Ingreso de la IP del servidor ................................................................................................ 106
Figura 39: Login de Proxmox ................................................................................................................ 107
Figura 40: Datos del servidor ............................................................................................................... 107
Figura 41: Configuracin de red eth1................................................................................................... 108
Figura 42: Vista sin modificaciones del archivo isc-dhcp-server .......................................................... 109
Figura 43: Vista por default del archivo dhcpd.conf ............................................................................ 110
Figura 44: Fin de la creacin de la imagen del cliente ......................................................................... 111
Figura 45: Muestra del programa Thin Client Manager funcionando ................................................. 111
Figura 46: Ubicar disco duro con espacio libre .................................................................................... 113
Figura 47: Seleccionar configuracin de volumenes cifrados .............................................................. 114
Figura 48: Seleccionar particin con espacio libre ............................................................................... 114
Figura 49: Seleccionar la configuracin de gestor de volmenes (LVM) ............................................. 115
Figura 50: Cmo crear un grupo de volmenes ................................................................................... 116
Figura 51: Cmo seleccionar la particin boot..................................................................................... 116
Figura 52: Fin de tabla de particiones .................................................................................................. 117

Figura 53: Muestra de particiones creadas .......................................................................................... 117


Figura 54: Muestra de particiones finalizadas ..................................................................................... 118
Figura 55: Muestra de particiones creadas y cifradas.......................................................................... 119
Figura 56: Pantalla de inicio del sistema operativo para montar el cifrado ........................................ 120
Figura 57: Login de Ubuntu .................................................................................................................. 120
Figura 58: Escritorio de Ubuntu ........................................................................................................... 121
Figura 59: Ubicacin de las aplicaciones al inicio ................................................................................. 134
Figura 60: Ejemplo de cmo agregar Conky a las aplicaciones de inicio ............................................. 135
Figura 61: Termino de adicin de Conky a programas de inicio .......................................................... 135
Figura 62: Conky en escritorio.............................................................................................................. 137

ndice de Tablas
Tabla 1: Hypervisors evaluados .............................................................................................................. 34
Tabla 2: Plataformas de virtualizacin evaluadas .................................................................................. 39
Tabla 3: Resultado de Software para montar un servidor de Clientes Ligeros ...................................... 43
Tabla 4: Requisitos obligatorios para un cliente ligero .......................................................................... 56
Tabla 5: Requisitos para booteo de red para un cliente ligero .............................................................. 57
Tabla 6: Requisitos opcionales para un cliente ligero ............................................................................ 57
Tabla 7: Configuracin del servidor DHCP ............................................................................................. 69
Tabla 8: Mquinas Virtuales de la red virtual ........................................................................................ 71
Tabla 9: Consumo de memoria de los clientes ligeros ........................................................................... 74
Tabla 10: Tipos de Licencias de Software............................................................................................... 97
Tabla 11: Tipos de red ............................................................................................................................ 98
Tabla 12: Listado de Software .............................................................................................................. 104
Tabla 13: Significado de los comandos de una Bomba Fork ................................................................ 139

Introduccin
La virtualizacin y los clientes ligeros son tecnologas que datan de los aos 60's. En aquella poca
eran utilizadas principalmente para aumentar la productividad y optimizar los recursos informticos.
En la actualidad se han renovado, en el caso de la virtualizacin, como base de los servicios de
cmputo en la nube.
Este documento presenta una propuesta para montar una infraestructura de red que combine la
tecnologa de virtualizacin y el modelo de clientes ligeros. La principal motivacin para desarrollar
este proyecto fue poder trabajar con tecnologa que no se utiliza o se utiliza poco en el ambiente
escolar actual y por los laboratorios de cmputo deficientes en el pas.
Con este modelo se pretende reducir costos de renovacin de infraestructura y centralizar los datos
aprovechando las caractersticas que tienen la virtualizacin y el uso de clientes ligeros.
ste documento est compuesto por los siguientes captulos: captulo uno: Identificacin y
planteamiento del problema, captulo dos: Fundamentos tericos, captulo tres: Evaluacin y
seleccin de herramientas, captulo cuatro: Propuesta del modelo de red, captulo cinco: Prueba
virtual del modelo de red y captulo seis: Consideraciones, conclusiones y trabajos futuros.
En el captulo uno, correspondiente a identificacin y planteamiento del problema, se plantea el
problema que da origen a la investigacin plasmada en ste documento as como los objetivos
derivados de esta problemtica.
En el captulo dos, correspondiente a fundamentos tericos, se incluyen conceptos que refuerzan los
conocimientos necesarios para el desarrollo de este proyecto, principalmente conceptos de
virtualizacin y de clientes ligeros.

En el captulo cuatro, referente a evaluacin y seleccin de herramientas, se incluyen comparativas


respecto a distintas herramientas evaluadas a fin de seleccionar las que integren mejor el proyecto.
En el captulo cuatro, llamado: Propuesta de modelo de red, se describe como tal, el procedimiento
tcnico para montar un laboratorio como el propuesto en ste documento, tomando en cuenta
ciertas consideraciones del lado del servidor, de los clientes y de la red.
En el captulo cinco correspondiente a prueba virtual del modelo de red, se describe la prueba
realizada del modelo propuesto as como el procedimiento, realizada totalmente en un ambiente
virtual.
En el captulo seis, llamado: Consideraciones, conclusiones y trabajos futuros, se mencionan algunos
aspectos a tener en cuenta, no necesariamente tcnicos, seguido de las conclusiones de este
documento y algunas sugerencias para trabajos futuros del mismo.
En los anexos se incluyen temas de apoyo que refuerzan algunos conceptos tratados en este
documento.

Laboratorio de prcticas, modelado en software libre by Daniel Campos Ojeda and Erick Johans
Zamorategui Nava is licensed under a Creative Commons Attribution 3.0 Unported License.

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Captulo 1
1 Identificacin y planteamiento del problema
"Si no est roto, no lo arregles"
Frase popular

Un problema comn en muchos centros de cmputo (escuelas, oficinas, hospitales, caf internet,
etc.) es la rapidez con la que sus equipos informticos caen en la obsolescencia, los avances
tecnolgicos obedecen a la ley de Moore, la cual dice que: aproximadamente cada 18 meses el
nmero de transistores dentro de los circuitos integrados se duplica, lo que tiene como consecuencia
que los equipos de cmputo queden obsoletos en poco tiempo y la crisis econmica que afecta al
mundo no es de ayuda cuando un centro de cmputo "necesita" renovar sus equipos.
En consecuencia, estos centros de cmputo funcionan con computadoras obsoletas y muchas veces
no permiten desarrollar ptimamente las tareas para las cuales fueron designadas esas
computadoras.

Captulo 1: Identificacin y planteamiento del problema

Para alargar el tiempo de uso de esos equipos de cmputo se puede recurrir a modelos de red de tipo
Terminal Server - Thin Client, en donde un cliente ligero (Thin Client) depende de un servidor para el
procesamiento de informacin. Este proyecto se apoya de la tecnologa de clientes ligeros y de
virtualizacin para crear una arquitectura de red distinta a la tradicional.
En un modelo de red tradicional, en donde todas las computadoras conectadas a la red son
responsables de sus propios recursos y cuentan con su propio sistema operativo, regularmente estn
diseadas para operar de manera ptima con su configuracin de fbrica. Cuando un laboratorio de
cmputo sufre del problema de obsolescencia en sus equipos y la escalabilidad de las computadoras
llega a su lmite, es posible implementar otro modelo de red que ayude a alargar la vida til de estas
computadoras.
Con la implementacin de ste modelo de red en un centro de cmputo, se reduce el problema de los
virus informticos, ya que al utilizar Linux como sistema operativo, el riesgo a la exposicin de virus es
menor en comparacin de Windows.
Al centralizar los documentos se reduce el costo de administracin del sistema, el sysadmin
nicamente trabaja fsicamente sobre una computadora, desde esa computadora tiene acceso a
todas las cuentas de usuario del sistema.
Socialmente, se busca impulsar el trabajo colaborativo desde la construccin de este modelo hasta la
implementacin y el uso del mismo, todo esto con software libre a travs de herramientas
colaborativas que promuevan el trabajo en equipo y que en un futuro impulsen el desarrollo de
tecnologa propia.

Captulo 1: Identificacin y planteamiento del problema

1.1 Justificacin

Con la implementacin de ste modelo de red en un centro de cmputo, se pretende aumentar el


tiempo de uso de las computadoras con la introduccin de un servidor y distintas configuraciones,
todo desarrollado con software libre.
El uso de tecnologas libres se puede traducir en reduccin de costos para los centros de cmputo y
en la independencia tecnolgica, adems puede ser un caso de estudio para requerimientos similares
en cuanto a diseo y solucin.
Adems, este modelo es adaptable a distintos escenarios en donde se necesita un modelo de red
econmico, de bajo a mediano rendimiento y que sea agradable con el medio ambiente.

Captulo 1: Identificacin y planteamiento del problema

1.2 Objetivos

1.2.1 General

Crear y proponer un modelo de red el cual integrar la tecnologa de virtualizacin con el modelo de
red cliente-servidor utilizando como Sistema Operativo Linux y herramientas de software libre para
otorgar el sistema operativo a computadoras que fungirn como clientes ligeros.

1.2.2 Especficos

Evaluar plataformas de virtualizacin

Evaluar herramientas para implementar clientes ligeros

Replicar modelos existentes de clientes ligeros y de virtualizacin

Crear y proponer modelo de red

Implementar seguridad

Probar virtualmente el modelo

Captulo 1: Identificacin y planteamiento del problema

1.3 Alcances y Limitaciones

Este modelo puede ser utilizado en centros de cmputo de baja demanda como: escuelas, pequeas
empresas, caf internet, pequeos laboratorios de cmputo, etc.
Se implementar un servidor de mquinas virtuales, una mquina virtual por cada interfaz de red
para dar servicio a distintos centros de cmputo.
Las computadoras cliente iniciarn el sistema por red, aprovechando las caractersticas naturales de
Linux, los clientes contarn con una cuenta de usuario personal y un espacio propio dentro del
servidor para almacenar datos.
Este modelo por limitaciones tecnolgicas, no est preparado para centros de cmputo de alta
demanda como: entornos de desarrollo, diseo, edicin de video, etc.
Con este modelo es posible virtualizar cualquier sistema operativo, incluso de Microsoft, pero por
limitaciones legales (licencia), los sistemas operativos de Microsoft no deben ser virtualizados.
Este proyecto es un modelo, las pruebas fsicas del modelo quedan a consideracin del interesado.

Captulo 1: Identificacin y planteamiento del problema

Metodologa de Investigacin y Desarrollo


Actividad

Tcnicas

Herramientas

1. Comprender e
identificar el
problema

Observacin
Investigacin
Bsqueda de
nuevos temas

Internet
Libros

2. Idealizar y
modelar
propuesta de
solucin.

Investigacin
Modelado

3. Investigar las
alternativas
tecnolgicas
para la
resolucin del
proyecto
4. laborar
pruebas de los
modelos
existentes en
las
herramientas
tecnolgicas de
Virtualizacin
y Clientes
Ligeros.

Investigacin

Procesador de
textos
Internet
Libros
Pizarrn
Internet
Libros
Conferencias

5. Integrar el
diagrama de
modelado con
herramientas
tecnolgicas
seleccionadas

Investigacin de
manuales
Descarga y
prueba de
Sistemas
Operativos,
Herramientas
de virtualizacin
y herramientas
para servidores
de clientes
ligeros.
Adaptacin e
investigacin del
uso de las
herramientas.

Documentacin
de la instalacin
real con las
versiones
correctas.

METAS
Observacin e indagacin de
soluciones
existentes
o
alternativas e Identificacin del
problema

rea
de
oportunidad.
Diseo conceptual del proyecto,
alcances y limitaciones

Identificacin
de
diversas
alternativas y definicin de las
herramientas tecnolgicas que
sirvan para resolucin del
problema.

Internet
Equipo de
cmputo con
caractersticas
de servidor
Cableado
estructurado
Switch

Determinar el uso de las


herramientas que se poda
utilizar para poder aplicar el
modelo

Internet
Equipo de
cmputo con
caractersticas
de servidor
Cableado
estructurado
Switch

Diseo fsico del proyecto, con


pruebas de ensayo y error

Captulo 1: Identificacin y planteamiento del problema

6. Testear y
realizar
pruebas
virtuales

Generacin de
maquinar
virtuales con el
uso de
aplicaciones.

7. Identificar y
lineamientos
de seguridad y
monitoreo

8. Redactar y
Documentar el
proyecto de
investigacin

Investigacin de
vulnerabilidades
acerca de
servidores y
Linux.
Tcnicas de
redaccin
Asesoras.

Internet
Equipo de
cmputo con
caractersticas
de servidor
Cableado
estructurado
Switch
Procesador de
textos
Computadora
Internet

Comprobacin
del
funcionamiento del modelo
lgico y la integracin de las
herramientas tecnolgicas para
producir un servicio de un
servidor que administre clientes
ligeros y soporte la carga de
aplicaciones.

Procesador de
texto
Computadora
Manuales
Referencias de
Internet

Documento de Tesis

Generacin y propuesta de
lineamientos para proteger el
servidor y mquinas virtuales.

Los aspectos pertinentes a la creacin y montaje del modelo corren a cargo de Daniel Campos Ojeda
de la especialidad: Ingeniera de Software.
Los aspectos relacionados con la seguridad del modelo son desarrollados por Erick Johans
Zamorategui Nava de la especialidad: Auditora y Seguridad.

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Captulo 2
2 Fundamentos tericos
"Cuanto ms sabes, ms te das cuenta de que no sabes nada"
Scrates
"Obtener informacin de internet es como intentar beber agua de una manguera de incendios"
Mitchell Kapor

En el siguiente captulo se recopilan algunos conceptos que el lector necesita saber para comprender
el proyecto, si el lector est familiarizado con la virtualizacin y los clientes ligeros, puede hacer caso
omiso a este captulo, no obstante para entrar en contexto es conveniente leerlo.

Captulo 2: Fundamentos tericos

2.1 Cloud Computing

Figura 1: Internet como Red de Dispositivos


Fuente: http://www.maestrosdelweb.com/editorial/cloud-computing-nueva-era-de-desarrollo/

Se define como una tecnologa que ofrece servicios a travs de la plataforma de internet. Los usuarios
de este servicio tienen acceso de forma gratuita o de pago, todo depende del servicio que se necesite
usar [2].
La computacin en la nube, consiste en la gestin y suministro de aplicaciones, informacin y datos
como un servicio. Estos servicios se proporcionan a travs de la nube, a menudo basado en un
modelo basado en el consumo [13].

2.1.1 Caractersticas del Cloud Computing

Auto Reparable: En caso de fallo, el ltimo Backup de la aplicacin pasa a ser automticamente la
copia primaria y se genera uno nuevo.

11

Captulo 2: Fundamentos tericos

Escalable: Todo el sistema/arquitectura es predecible y eficiente. Si un servidor maneja 1000


transacciones, 2 servidores manejaran 2000 transacciones.
SLA: Regidos por un Acuerdo de Nivel de Servicio (SLA) que define varias polticas como cuales son los
tiempos esperados de rendimiento y en caso de pico, debe crear ms instancias.
Virtualizado: las aplicaciones son independientes del hardware en el que corran, incluso varias
aplicaciones pueden corren en una misma mquina o una aplicacin puede usar varias maquinas a la
vez.
Multipropsito: El sistema est creado de tal forma que permite a diferentes clientes compartir la
infraestructura sin preocuparse de ello y sin comprometer su seguridad y privacidad [2].
An incluyendo los conceptos de Cloud Computing en el marco terico, se recomienda tomar dichos
conceptos como lo que son, simples conceptos; durante las presentaciones que ha tenido este
proyecto se han detectado diversas confusiones respecto al uso de estos trminos. Estos "nuevos"
conceptos son utilizados en el proyecto con el fin de describir antiguos procesos que estn siendo
utilizados actualmente. En lo que respecta a este proyecto se concluye que: para poder hablar de
Cloud Computing como "nuevo" modelo de negocios, se deben cubrir varios aspectos: cmo medirlo,
cmo cobrarlo y cmo mantener alta disponibilidad, aspectos los cuales no son objetivos de este
documento.

El prrafo anterior es un comentario de los autores de ste documento


12

Captulo 2: Fundamentos tericos

2.1.2 Tipos de servicios

La computacin en nube ha evolucionado en una variedad de servicios que incluyen recursos


compartidos, software y plataformas a demanda. Se dar a conocer una breve introduccin a cada
uno de estos tipos: SaaS (Software as a Service), PaaS (Plataform as a Service), IaaS (Infrastructure as
a Service) [4].

Figura 2: Estructura de Cloud Computing


Fuente:http://www.denoe.es/test/wp-content/uploads/estructura-cloud-computing.png

2.1.2.1 Software as a Service (SaaS)

Software as a Service (Software como servicio) es un trmino utilizado para describir el software
desplegado en Internet y se caracteriza por que el proveedor licencia la aplicacin al suscriptor en un
modelo de "servicio por demanda". Los principales segmentos de mercado del modelo SaaS se
encuentran en tpicos como: administracin de contenido, colaboracin y Customer Relationship
Management (CRM) [4].

13

Captulo 2: Fundamentos tericos

2.1.2.2 Platform as a Service (PaaS)

Platform as a Service (Plataforma como Servicio) se refiere a un modelo que no slo ofrece la
plataforma de despliegue y adicionalmente una plataforma de desarrollo de aplicaciones completa.
Mientras que en el modelo SaaS se ofrecen aplicaciones listas para utilizarse, el modelo PaaS brinda la
opcin de construir una aplicacin personalizada utilizando la plataforma de desarrollo ofrecida. Los
proveedores PaaS ofrecen por medio de sus plataformas soporte para los lenguajes de programacin
ms comunes como Java o .NET reduciendo la dependencia de plataformas SaaS, que usualmente
casan los usuarios y organizaciones con su plataforma [4].

2.1.2.3 Infrastructure as a Service (IaaS)

Infrastructure as a Service (Infraestructura como servicio) es el tercer modelo de implementacin de


Cloud Computing y hace referencia a plataformas que ofrecen infraestructura de cmputo y
usualmente se encuentran desplegadas sobre un entorno de virtualizacin. La plataforma brinda la
alternativa de escalar la infraestructura de manera vertical (subir y bajar los recursos de cmputo) a
demanda y se paga por los recursos consumidos. Este modelo ofrece el ms alto grado de flexibilidad,
as como el menor grado de dependencia con la plataforma permitiendo a los usuarios migrar las
aplicaciones de un proveedor a otro. Por otro lado una implementacin sobre IaaS requiere
instalacin, configuracin y mantenimiento adicionales [4].

14

Captulo 2: Fundamentos tericos

2.2 Linux

Linux es un sistema operativo tipo Unix. Es libre, esto significa que no se debe pagar ningn tipo de
licencia a ninguna casa desarrolladora de software por el uso del mismo.
El sistema lo forman el ncleo del sistema (Kernel) ms un gran nmero de programas / bibliotecas
que hacen posible su utilizacin.
El sistema ha sido diseado y programado por multitud de programadores alrededor del mundo. El
ncleo del sistema sigue en continuo desarrollo bajo la coordinacin de Linus Torvalds, la persona
de la que parti la idea de este proyecto, a principios de la dcada de los noventa. Hoy en da,
grandes compaas, como IBM, SUN, HP, Novell y RedHat, entre otras muchas, aportan a Linux
grandes ayudas tanto econmicas como de cdigo [16].

2.2.1 Caractersticas de Linux

Linux al igual que Unix, es un sistema operativo diseado para operar en modo multiusuario y
multisesin, de tal modo que est optimizado para proporcionar servicio a varios usuarios a la vez,
adems de esto, Linux cuenta con las siguientes caractersticas:

Altamente personalizable.

Un sistema operativo econmico o incluso gratuito.

Todas las aplicaciones necesarias son econmicas o gratuitas.

Redes incorporadas al ncleo del sistema operativo.

15

Captulo 2: Fundamentos tericos

Lo suficientemente pequeo como para entrar en dispositivos pequeos.

Lo suficientemente flexible y poderoso como para que se puedan usar computadoras porttiles
completas.

Lo suficientemente ahorrativo como para conservar la batera durante el mayor tiempo posible
[21].

Por las caractersticas mencionadas en el punto anterior, Linux es el sistema operativo ideal para el
proyecto por ser moldeable y adaptable tanto para el sistema base del servidor como para los
servidores de clientes ligeros. Adems la idea es que este proyecto sea lo ms libre posible, que
cualquiera pueda modificar cualquier aspecto que se involucre en la creacin o en la puesta en
marcha de ste modelo, de haber elegido un sistema operativo distinto, todo esto no sera posible.

El prrafo anterior es un comentario de los autores de ste documento


16

Captulo 2: Fundamentos tericos

2.3 Virtualizacin

La virtualizacin consiste en la capacidad de separar el software del hardware en el que estn


instalados. Esta caracterstica aplicada al Cloud Computing se materializa en que el usuario no tiene
que preocuparse por la implementacin concreta de los servicios de la nube ni tener en cuenta el
hardware asociado a ellos [13].
La virtualizacin posibilita una optimizacin respecto al aprovechamiento de los recursos comunes, ya
que permite que las aplicaciones sean independientes del hardware en el que se ejecutan.

2.3.1 Hypervisor

Un hypervisor es el software encargado de mediar el hardware fsico con el hardware de las mquinas
virtuales. Existen hypervisores de 2 tipos, tipo 1 o bar-metal y tipo 2 o hosted.
El hypervisor bare-metal no funciona bajo un sistema operativo instalado sino que tiene acceso
directo sobre los recursos hardware, en este tipo de tecnologa de virtualizacin el hardware
soportado es ms limitado ya que normalmente es construido con un conjunto limitado de drivers.
Un hypervisor hosted requiere que instales primero un sistema operativo sobre el cual se instalar el
software de virtualizacin, de igual modo a como se instala cualquier aplicacin. Esta tecnologa
presenta una compatibilidad mayor con el hardware que la bare-metal, debido a que es el propio
sistema operativo el que se encarga de gestionar los drivers [18].

17

Captulo 2: Fundamentos tericos

Figura 3: Representacin de un hypervisor con tres maquinas virtuales


Fuente: http://blog.virtualizamos.es/2011/09/21/%C2%BFque-tecnologia-de-hypervisor-de-virtualizacion-elegir/

2.3.2 Tipos de virtualizacin

2.3.2.1 Emulacin de Hardware

Esta es el tipo de emulacin ms compleja, con esta tcnica en el sistema anfitrin se utiliza una
mquina virtual que emula el hardware, como se muestra en la figura 4.

Figura 4:Emulacin por hardware


Fuente: http://www.ibm.com/developerworks/linux/library/l-linuxvirt/

18

Captulo 2: Fundamentos tericos

El principal problema con la emulacin de hardware es que puede resultar lenta ya que cada
instruccin debe ser simulada por el hardware base.
Tiene como ventaja la posibilidad de ejecutar un sistema operativo sin modificar, incluso se pueden
ejecutar varias maquinas virtuales simulando procesadores diferentes.

2.3.2.2 Virtualizacin completa

Tambin llamada Virtualizacin nativa, utiliza un monitor de maquina virtual que media entre el
sistema operativo invitado y el hardware nativo. Algunas instrucciones protegidas deben capturarse y
manejarse dentro del hypervisor. El hardware no es propiedad del sistema operativo invitado sino
que es compartido a travs del hypervisor [7].

Figura 5: El hypervisor media entre el hardware y la mquina virtual


Fuente: http://www.ibm.com/developerworks/linux/library/l-linuxvirt/

19

Captulo 2: Fundamentos tericos

La virtualizacin completa es ms rpida que la emulacin de hardware, pero el rendimiento es


menor que cuando se utiliza hardware y el sistema operativo nativo debido a la mediacin del
hypervisor.
La ventaja de utilizar virtualizacin completa es que un sistema operativo puede ser ejecutado sin
modificaciones, la nica restriccin es que el sistema operativo invitado debe soportar el hardware
anfitrin.

2.3.2.3 Paravirtualizacin

Este mtodo utiliza un hypervisor para compartir el acceso al hardware anfitrin pero integra cdigo
que est al tanto de la virtualizacin en el propio sistema operativo, esto evita la necesidad de
recompilar y capturar ya que los sistemas operativos virtualizados cooperan en el proceso de
virtualizacion [7].

Figura 6: En la paravirtualizacin se comparte el proceso con el SO invitado


Fuente: http://www.ibm.com/developerworks/linux/library/l-linuxvirt/

20

Captulo 2: Fundamentos tericos

La paravirtualizacin ofrece un rendimiento prximo al de un sistema no virtualizado, es posible


soportar varios sistemas operativos diferentes de manera concurrente.

2.3.2.4 Virtualizacin en el nivel del Sistema Operativo

Esta tcnica virtualiza los servidores encima del propio sistema operativo. Slo soporta un solo
sistema operativo y simplemente asla a los servidores de manera independiente [7].

Figura 7: Aislamiento de servidores


Fuente: http://www.ibm.com/developerworks/linux/library/l-linuxvirt/

El papel de la virtualizacin dentro del proyecto ser virtualizar servidores de clientes ligeros para
aprovechar al mximo los tiempos muertos del procesador y sacar el mximo provecho del hardware
que sea utilizado como servidor, como beneficio se ahorran costos en la implementacin de
servidores y se facilita la administracin de los servicios. Para esto se ha elegido la virtualizacin
completa y la paravirtualizacin ya que se estarn virtualizando sistemas operativos completos.
El prrafo anterior es un comentario de los autores de ste documento
21

Captulo 2: Fundamentos tericos

2.3.3 TFTP

Son las siglas en ingls de: Protocolo de Transferencia de Archivos Trivial, es una forma de transferir
archivos muy simples, como una versin bsica de FTP. Uno de los usos ms comunes es la
transferencia de pequeos archivos entre computadoras de una red. Es ms rpido que FTP ya que
utiliza un protocolo de transporte UDP, por lo cual no lleva control de errores en la transmisin [17].

2.3.4 Cliente ligero

Un cliente ligero (thin-client) es una computadora cliente en una arquitectura de red cliente-servidor
que depende del servidor central para tareas de procesamiento, principalmente se encarga de
transportar la entrada y la salida entre el usuario y el servidor remoto [1].

2.3.5 PXE

Es un protocolo que consiste en la combinacin de los protocolos DHCP y TFTP. DHCP es utilizado
para localizar el servidor de arranque apropiado, con TFTP se descarga el programa inicial de
bootstrap y archivos adicionales.
Tanto TFTP como PXE son protocolos utilizados para el booteo por red. Para este proyecto son
indispensables estos protocolos pues las computadoras cliente solo tendrn la opcin de conectarse
al servidor por medio del booteo por red.

El prrafo anterior es un comentario de los autores de ste documento

22

Captulo 2: Fundamentos tericos

2.4 Seguridad Informtica

La seguridad no era realmente vital, pero debido a la ayuda que proporciona a las necesidades
primarias antes, durante y despus de la vida de cualquier cosa (ya sea vida, proyecto, proceso, etc),
es considerada como fundamental o algunas veces como una necesidad primaria debido a su
importancia y por la necesidad que llega a existir por establecer un nivel de tranquilidad y confort.
La seguridad es la proteccin de amenazas o riesgos para estar exentos de peligros o daos,
ejerciendo confianza sobre algo o alguien que represente una menor ausencia de tener
vulnerabilidades, aunque esto no asegurar estar libre completamente de no tener ningn tipo de
percance, solo acerca a un nivel razonable de estar protegidos.
La seguridad informtica son las tcnicas, mtodos, documentos, programas o dispositivos que
protegen una computadora, sus datos, procesos y lo que conlleve a ella logrando su disponibilidad,
integridad y privacidad, procurando tener las menores vulnerabilidades posibles.
En todos los laboratorios de cmputo se debe tener un reglamento el cual debe ser acatado para
tener un ptimo funcionamiento del equipo de cmputo, tambin se debe contar con seguridad fsica
y seguridad contra incendios para proteger el servidor. Otro punto importante es tener contraseas
seguras, esto puede ser realizado mediante medidas de seguridad para contraseas.
Debido a que el modelo del proyecto no es fijo y est abierto a cualquier posibilidad de
implementacin, dentro del Anexo D tal se muestran ejemplos bsicos para la seguridad de cualquier
laboratorio de cmputo tales como:

23

Captulo 2: Fundamentos tericos

Reglamento de centro de cmputo

Seguridad fsica y contra incendios

Seguridad en contraseas

Los ejemplos que se muestran en el anexo son nicamente como un nivel bsico para cualquier tipo
de laboratorio y servirn solo como un perfil bajo para un laboratorio de cmputo.

2.4.1 Qu es encriptar y desencriptar?

La seguridad de la informacin privada o corporativa siempre es importante y una manera de poder


hacerla segura es encriptando la informacin.

Figura 8: Proceso de encripcin


Fuente: http://3.bp.blogspot.com/-WZV-ZbqCz9g/TgQhmrlrgVI/AAAAAAAAAJ0/nhqOJCxtWKA/s1600/criptografia.jpg

La informacin que puede ser leda y entendida sin aplicarle ninguna transformacin se llama texto
plano. El mtodo que transforma el texto plano de tal manera que oculta su valor til es llamado

24

Captulo 2: Fundamentos tericos

encripcin o cifrado protegindolo con una contrasea. Cifrar el texto plano da como resultado un
documento ilegible y sin sentido que se denomina texto cifrado. El cifrado se usa para asegurarse de
que la informacin va a permanecer oculta a los ojos de aquellos a quienes no est destinada, incluso
aquellos que pueden ver el texto cifrado. El proceso de revertir el texto cifrado a su estado original
(texto plano) es llamado desencriptado o descifrado [24].

2.4.2 Filtrado de contenido web

Permite bloquear el contenido no deseado de pginas Web, restringe el acceso a pginas de


entretenimiento, compras, y pginas de chat, o la que deseemos, la mayora con contenido
pornogrfico, programas pirata un alto contenido de virus [19].
El filtrado de contenido Web, o la habilidad para tener el control de acceso a Internet, es una
actividad crtica para minimizar los riesgos de que los usuarios tengan acceso a Internet, dependiendo
el lugar en donde este implementado.

2.4.2.1 DNS

Los DNS (Domain Name System) traducen la direccin URL de una pgina de Internet (ej.
www.google.com.mx) a la IP que le corresponde (ej: http://74.125.227.100/). Aunque generalmente
no se conoce este proceso, se hace notar cuando no funciona correctamente.

25

Captulo 2: Fundamentos tericos

Este servicio tiene diferentes propsitos, pero su nico fin es mejorar la manera en la que se navega
por Internet. Esto lo logra haciendo la navegacin ms segura y rpida. El problema principal con los
DNS es que la mayora de las personas utilizan el DNS que viene de manera predefinida con el
proveedor del servicio y generalmente, son lentos estn llenos de agujeros que presentan una
amenaza para el usuario.

2.4.3 Monitorizacin

A medida que un servidor es usado, crece el tamao de los datos, se agregan nuevos enlaces y
equipos, hasta el punto en que es muy difcil para los administradores estar al tanto del estado de la
red.
Es deseable disponer de informacin estadstica para conocer exactamente el consumo de las CPUs o
de ancho de banda. Una buena forma de justificar un pedido para mayor ancho de banda es,
precisamente, utilizando datos sobre su utilizacin que muestren que los enlaces estn saturados [14].
La monitorizacin del hardware y software del servidor sirve para poder ver que tanto es usado, es
benfica para conocer en todo momento el estado del equipo (tanto del pasado, como al instante),
los horarios en que son usados, si un intruso realiza tareas que no debe hacer el servidor (bot, botnet)
y poder anticiparse a los problemas que surjan, se encontraron dos buenas alternativas, Munin y
Conky.

El prrafo anterior es un comentario de los autores de ste documento

26

Captulo 2: Fundamentos tericos

2.4.3.1 Porque monitorizar un servidor Linux guardando un historial

Monitorizar una computadora almacenando un historial es benfico debido a que de esta manera se
sabr que procesos son los ms usados, en qu momento es que una computadora colapsa, cuanto
ancho de banda usa la computadora (y las que se conecten a Internet directamente al servidor), si la
computadora realiza procesos indebidos, dentro de muchas otras cosas, y as poder determinar
fcilmente que problema pudo marcar una falla en el servidor por medio del registro guardado (logs).
Munin se usar como parte de la monitorizacin guardando un historial para poder verificar el uso a
mediano y largo plazo del servidor. Este programa puede agregar cualquier hardware o software para
que pueda ser mostrado en las grficas.

2.4.3.2 Por qu monitorizar un servidor Linux mostrando uso al momento?

La monitorizacin instantnea permite saber el estado de los componentes mientras son usados, de
esta manera si un componente est a punto de fallar o saturarse, se realiza mantenimiento
preventivo para arreglarlo o corregirlo.
El software que se usar es Conky, este software es personalizable para poder agregar cualquier
hardware o software que se requiera monitorear, se puede tener Conky siempre abierto sobre el
escritorio mostrando toda esa informacin sin que repercuta en el rendimiento general del equipo ya
que apenas consume recursos.

27

Captulo 2: Fundamentos tericos

2.4.4 Ataque de denegacin de servicio (DDOS)

Este tipo de ataques consiguen hacer miles o millones de peticiones a la vez a un servidor o de
manera web, consiguiendo as que no pueda responder a todas y se caiga o desmorone, consumiendo
sus recursos la reserva de conexiones hasta que la comunicacin se complete satisfactoriamente
se acabe el tiempo de espera para el establecimiento de conexiones. Estas acciones desembocan
lgicamente en la consiguiente saturacin del servidor afectado.
Generalmente estos ataques se producen por medio de los llamados zombies y bots,
y suelen ir asociados al IRC donde consiguen hacer que millones de IPS hagan esas millones de
peticiones al servidor o web, provocando su cada.

Figura 9: Ataque de denegacin de servicio distribuido


Fuente: http://www.windowstecnico.com/archive/2011/09/05/dos-ataques-de-denegaci-243-n-de-servicio-i.aspx

28

Captulo 2: Fundamentos tericos

Un ataque DDOS tambin se le puede aplicar a un mvil o celular el cul contenga alguna falla o algn
bug. No siempre tiene que ser mediante un IRC o algo parecido. Este tipo de ataque como ya el
nombre indica, deniega el servicio mediante alguna tcnica, pero la tcnica no siempre tiene que ser
la misma [26].

2.4.4.1 Bomba Fork

La bomba fork es una forma de ataque del tipo denegacin (Dos) de servicio sobre una computadora
que implementa la operacin fork, su efecto se basa en la suposicin de que el nmero de programas
y procesos que se ejecutan rpidamente con el objetivo de saturar el espacio disponible en la lista de
procesos en una computadora [32].

Figura 10: Funcin de procesos Fork


Fuente: http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Fork_bomb.svg/800px-Fork_bomb.svg.png

29

Captulo 2: Fundamentos tericos

Si la tabla de procesos se llega a saturar, entonces no se pueden iniciar nuevos programas hasta que
no se cierre alguno. En el caso que esto suceda, es muy poco probable que se pueda iniciar un
programa til ya que los procesos de la bomba estarn esperando para poder crear nuevos procesos
a la primera oportunidad que se les conceda. No slo ocupan espacio dentro de la lista de procesos,
tambin consumen tiempo de proceso y memoria de la mquina donde se ejecutan. Como resultado
de esto, las computadoras se vuelven lentas e incluso se pueden volver inutilizables dada la falta de
memoria y la imposibilidad de aprovechar el procesador.

2.4.5 Por qu proteger un servidor Linux de ataques por fuerza bruta?

Un ataque de diccionario (o tambin conocido como ataque por fuerza bruta) es un mtodo mediante
el cual alguien desde el exterior trata de acceder a la mquina utilizando una larga lista de usuarioscontraseas (denominadas como diccionarios) que se sabe son muy utilizadas por los usuarios y los
prueba en repetidas ocasiones buscando dar con la combinacin acertada.
Una correcta configuracin de la computadora y el uso de contraseas correctas, reducen
considerablemente el riesgo pero no evita que la computadora pierda tiempo y recursos en denegar
un servicio [28].

30

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Captulo 3
3 Evaluacin y seleccin de herramientas
"La diferencia entre la teora y la prctica es que, en teora, no hay diferencia entre la teora y la
prctica"
Richard Moore

En este captulo se realiza la propuesta del modelo de red.


Antes de proponer el modelo de red, es necesario evaluar herramientas referentes a la virtualizacin
y a los clientes ligeros, con el fin de conocer sus caractersticas y tener certeza de que pueden ser
integradas entre s para poner en funcionamiento el modelo de red, pues, se necesita de hardware y
software para que el modelo de red funcione.
A nivel software, para este modelo se necesitan tres tipos de herramientas las cuales fueron
clasificadas en tres grupos: hypervisors, gestores de mquinas virtuales y servidores de clientes
ligeros.

Captulo 3: Evaluacin y seleccin de herramientas

3.1 Proyectos de Virtualizacin: Hypervisors

Se evaluaron distintos hypervisors con el fin de seleccionar l o los que cubrieran las necesidades del
proyecto, se busca que estas herramientas permitan virtualizar sistemas operativos completos e
independientes del sistema base y que preferentemente sean software libre.
A continuacin, se mencionan algunos hypervisores que fueron evaluados para este proyecto.

3.1.1 XEN

Xen es una solucin de paravirtualizacin que implementa un hypervisor que se encarga de la


planificacin de tareas y de la gestin de memoria, delegando la gestin de la entrada/salida en un
invitado privilegiado (llamado domain 0 o dom0 en XEN).

3.1.2 KVM

KVM es una solucin de virtualizacin completa en la que se utiliza el ncleo de Linux como
hypervisor, de este modo tanto el control de los dispositivos reales, como la planificacin de tareas y
la gestin de memoria del sistema anfitrin las hace el ncleo de Linux.
Las mquinas virtuales son procesos normales del sistema, por esta razn la gestin de memoria y la
planificacin de procesos son las estndar del sistema.

32

Captulo 3: Evaluacin y seleccin de herramientas

3.1.3 OpenVZ

OpenVZ es un sistema de virtualizacin a nivel sistema operativo que se implementa como una serie
de parches sobre el ncleo Linux.
Lo que realiza esta herramienta de virtualizacin es incluir apoyo en el ncleo para crear y mantener
mltiples entornos de usuarios independientes (conocidos como VPS o Virtual Private Servers) sin
que exista una interferencia entre ellos.

3.1.4 VirtualBox

VirtualBox es desarrollado por Oracle. Se distribuye bajo distintas licencias: existe la versin privativa,
que es gratuita nicamente bajo uso personal o de evaluacin y est sujeta a la licencia de "Uso
Personal y de Evaluacin VirtualBox" (VirtualBox Personal Use and Evaluation License o PUEL) y la
versin Open Source, sujeta a la licencia GPL.
La licencia PUEL permite el uso acadmico de VirtualBox, por lo que es legal utilizarlo en los
laboratorios escolares de manera gratuita.

3.1.5 VmWare

VmWare es la solucin ms conocida y con ms presencia comercial, ofrece muchas prestaciones


para asegurar la alta disponibilidad, control y eficiencia de sistemas crticos, no obstante es el

33

Captulo 3: Evaluacin y seleccin de herramientas

producto ms cerrado de los evaluados y a pesar de contar con versiones gratuitas de sus productos,
estos cuentan con diversas limitaciones que no se pueden evitar si no se paga por su licencia
correspondiente.

3.1.6 Resultados de la evaluacin de hypervisors

La siguiente tabla es un fragmento de kernelnewbies.org, pgina de una comunidad de usuarios de


Linux que se dedica a ayudar a otros usuarios a conocer el funcionamiento del Kernel de Linux. Esta
tabla se toma como apoyo para la evaluacin y bsqueda del hypervisor adecuado para este
proyecto.
Virtualizacin
completa

Licencia

Performance

Xen

GPL

KVM

GPL

OpenVZ
VirtualBox

GPL
GPL/
proprietaria
proprietaria
proprietaria

paravirt muy
rpido,
virtualizacin
completa
velocidad
media
Paravirt rpido,
virtualizacin
completa
velocidad
media
nativa
rpida/muy
rpida
media/rpida
media/rpida

VMware Server
VMware
Workstation/Player
VMware ESX

Paravirt

Contenedo
res
(OS
virt)

proprietaria

Sistema
dedicado

rpida/muy
rpida

Tabla 1: Hypervisors evaluados


Fuente: http://virt.kernelnewbies.org/TechComparison

34

Captulo 3: Evaluacin y seleccin de herramientas

Como primera opcin se recomienda utilizar los hypervisors KVM y XEN pues ambos ofrecen
virtualizacin completa, como segunda opcin se recomienda VirtualBox por ser una solucin sencilla
y cumplir con los requerimientos de virtualizacin del proyecto (virtualizacin completa); la licencia
bajo la cual se distribuye VirtualBox permite utilizar este hypervisor sin necesidad de pagar una
licencia.

3.2 Gestin de Mquinas Virtuales: Plataformas de Virtualizacin

Adems de un Hypervisor, es conveniente que un proyecto de virtualizacin utilice un gestor de


mquinas virtuales para hacer sencilla la administracin del servidor de mquinas virtuales, para el
proyecto se evalan distintas plataformas de virtualizacin buscando un equilibrio entre rendimiento,
facilidad de instalacin, facilidad de uso y escalabilidad.
Se da preferencia a plataformas de virtualizacin que hagan uso de KVM y/o XEN, en el caso de estos
dos hypervisors, pueden ser administrados va consola por medio de comandos. En el caso de
VirtualBox, la interfaz de administracin est integrada con el hypervisor, no teniendo otra forma de
administrar ms que el propio VirtualBox.
A continuacin, se mencionan algunos gestores de mquinas virtuales evaluados para el proyecto:

35

Captulo 3: Evaluacin y seleccin de herramientas

3.2.1 VmWare: Server, Player, ESXi

VmWare cuenta con varios productos para la gestin de mquinas virtuales. En el caso de VmWare
Player, puede ser comparado directamente con VirtualBox, es una aplicacin que se ejecuta en el
escritorio, est orientada para uso personal, por lo que no cuenta con una alternativa para
administrar las mquinas virtuales desde web. El caso es similar con VmWare Workstation el cual
agrega algunas funciones ms a VmWare Player pero no deja de ser una herramienta para
virtualizacin personal.
VmWare Server es una opcin funcional para el proyecto ya que cuenta con un administrador va
web, no obstante VmWare ha dejado de dar soporte a este producto desde Junio de 2011. La
alternativa a la versin Server es VmWare ESXi, la principal diferencia es que este producto es un
hypervisor de nivel 1, es decir se instala directamente sobre el hardware del servidor, sin ningn
sistema operativo de por medio, como muestra la figura 11:

Figura 11: diagrama VmWare ESXi


Fuente: http://www.vmware.com/files_inline/images/products_esx_esxi_diagram.jpg

36

Captulo 3: Evaluacin y seleccin de herramientas

3.2.2 Oracle Linux, Oracle Solaris

Solaris utiliza contenedores similares a OpenVz, es decir, es una solucin de Virtualizacin a nivel de
Sistema Operativo. Como alternativa existe un ejecutable de VirtualBox para Solaris para cubrir
necesidades de virtualizacin completa, as utilizando las opciones que proporciona Oracle, se pueden
cubrir todas las necesidades de virtualizacin. La figura 11 muestra las distintas posibilidades de
virtualizacin que ofrece Solaris.

Figura 12: Virtualizacin con Solaris


Fuente: http://www.spi.es/solucion_virtualizacion.html

37

Captulo 3: Evaluacin y seleccin de herramientas

3.2.3 Proxmox

Proxmox Virtual Environment es un gestor de mquinas virtuales que integra los hypervisors de KVM,
y OpenVz, es un producto preparado para virtualizar a nivel Sistema Operativo y Virtualizar
completamente un sistema, posee una interfaz web lo que permite administrar el servidor
remotamente, adems est preparado para escalabilidad pues tiene instaladas herramientas de
cluster y alta disponibilidad. Es una distribucin bare-metal (hypervisor tipo 1), basada en Debian con
servicios bsicos para obtener un mejor rendimiento.

3.2.4 XenServer

XenServer es la plataforma de virtualizacin de Citrix, utiliza Xen como hypervisor, para su


administracin requiere de una aplicacin cliente solo disponible para Windows. Existe una versin
gratuita pero tiene muchas limitaciones que no permitiran la escalabilidad del sistema a menos que
se pagara por la licencia de una versin ms avanzada.

3.2.5 Resultados del anlisis de los gestores de mquinas virtuales:

La siguiente tabla muestra los distintos gestores de mquinas virtuales evaluados para el proyecto, as
como las caractersticas que se tomaron en cuenta al momento de la evaluacin.

38

Captulo 3: Evaluacin y seleccin de herramientas

Virtualizacin
completa

paravirt

containers
(OS virt)

VmWare

licencia

Gestin

Limitaciones
entre
versiones

propietaria Local, remota


por cliente
Libre,
Remota por
propietaria cliente
GPL
Remota por
web
propietaria media/rpida

Oracle
Solaris/Linux
Proxmox
XenServer

Tabla 2: Plataformas de virtualizacin evaluadas

El gestor elegido para administrar las mquinas virtuales es Proxmox Virtual Environment, es un
producto completo y sencillo de usar, adems de ser completamente libre, se distribuye bajo la
licencia GPL, por lo que ste fue el elegido para el modelo que aqu se plantea, adems la instalacin
es muy sencilla, se incluye un manual sobre cmo instalarlo en la seccin de anexos.
Proxmox rene las siguientes caractersticas:

Soporta Virtualizacin y Paravirtualizacin.

Gestin Web centralizada.

Configuracin en Cluster.

Live Migration (VMotion en VMware)

Storage ISCSI, FC , NFS

Migracin de archivos VDMK.

Hot Backup. [22]

39

Captulo 3: Evaluacin y seleccin de herramientas

3.3 Software Para Montar Un Servidor de Clientes ligeros

Para que las computadoras cliente puedan obtener el sistema operativo por medio de la red, dentro
de la red debe existir un servidor de clientes ligeros, que en este proyecto es virtual.
Para montar un servidor de clientes ligeros se necesita de software que permita que el sistema
operativo pueda trabajar como servidor de clientes ligeros. Se consideraron las siguientes
aplicaciones las cuales integran un conjunto de herramientas para montar servidores de clientes
ligeros en Linux: LTSP, TCOS y openThinClient.
La descripcin para los tres proyectos es prcticamente la misma: Es un conjunto de herramientas
que permiten implementar un servidor de clientes ligeros para bootear computadoras a travs de la
red. A continuacin, se hace una breve descripcin de los mismos:

3.3.1 TCOS

TCOS son las siglas de Thin Client Operating System, es un conjunto de herramientas para el arranque
de terminales ligeros y para su control, se distribuye bajo la licencia GPL2. La siguiente figura es un
diagrama representativo de una red montada con TCOS, en la cual se puede observar que es
necesario contar mnimo con dos interfaces de red para poder utilizarlo.

40

Captulo 3: Evaluacin y seleccin de herramientas

Figura 13: diagrama de red TCOS


Fuente: http://wiki.tcosproject.org/File:Rede-tcos.png

3.3.2 LTSP

Son las siglas en ingls de: Proyecto Servidor de Terminales Linux, es un conjunto de aplicaciones que
le dan a un servidor basado en Linux la posibilidad de utilizar otras computadoras como clientes
ligeros. LTSP requiere de dos interfaces de red para funcionar, tal como lo muestra el diagrama de la
figura siguiente:

Figura 14: Diagrama del proyecto LTSP


Fuente: http://www.linuxjournal.com/article/9097

41

Captulo 3: Evaluacin y seleccin de herramientas

3.3.3 OpenThinClient OS

OpenThinClient OS es un proyecto basado en TCOS el cual incluye como mejoras un gestor


desarrollado en Java y es compatible con Windows y Linux, la gestin de usuarios en Windows la
realiza mediante Active Directory y la gestin de usuarios en Linux la realiza mediante LDAP, siendo
posible implementar un servidor de clientes ligeros en cualquiera de estas dos plataformas. La
siguiente figura es un diagrama representativo de una red montada con openThinClient OS en la cual
se puede observar que: a diferencia de los otros dos servidores de clientes ligeros antes
mencionados, openThinClient OS slo necesita de una interfaz de red para funcionar.

Figura 15: Esquema de openThinClient OS


Fuente: http://openthinclient.org/function

42

Captulo 3: Evaluacin y seleccin de herramientas

3.3.4 Resultado de la evaluacin de herramientas para montar servidores

de clientes ligeros

Memoria RAM mnima para clientes


NFS
Suficiente documentacin
DHCP interno
Tiene licencia GPL
Fcil instalacin
Fcil uso
Monitoreo
Interfaz de administracin

LTSP
16MB

TCOS
32MB

openThinClient OS
64MB

Escritorio

Escritorio

Escritorio

Tabla 3: Resultado de Software para montar un servidor de Clientes Ligeros

Cualquier solucin para clientes ligeros es ptima para este proyecto, LTSP es un proyecto extendido
pero con un circulo de desarrollo cerrado, TCOS es un proyecto mantenido slo por dos personas, lo
que hace pensar que el proyecto tiene un futuro incierto, sin embargo, el desarrollador del proyecto
tiene su propia empresa dedicada a instalar clientes ligeros (http://thinetic.es/), as que el mismo
depende de su desarrollo para continuar con su negocio. OpenThinClient OS es un proyecto con poca
documentacin, es completamente abierto y tiene como caracterstica a destacar de las otras dos
opciones mencionadas, el poder funcionar con una sola interfaz de red, adems de realizar la
administracin de usuarios con LDAP.
La eleccin de una u otra opcin queda a consideracin de cada persona interesada en el proyecto, la
decisin depender de las necesidades de la red que se est montando.

43

Captulo 3: Evaluacin y seleccin de herramientas

Otros proyectos de Servidores de Clientes Ligeros en Linux no se ven reflejados en este trabajo pues
fueron descartados por ser proyectos poco estables y/o abandonados o por no ser Software Libre.

3.4 Seguridad

En esta seccin se mostrarn las principales caractersticas, configuraciones, archivos importantes e


informacin relevante sobre los puntos dentro de la seccin 2.4 Seguridad Informtica del captulo
anterior de este mismo documento, demostrando porque es necesario tomar en cuenta los puntos
mencionados del captulo dos para este proyecto.

3.4.1 Encripcin AES

Haciendo referencia a la parte 2.4.1 Qu es encriptar y desencriptar? de este documento, se


demuestra porque se usa el cifrado AES en el proyecto.
El algoritmo AES utiliza una de las tres fortalezas de clave de cifrado: una clave de encriptacin
(contrasea) de 128-, 192-, o 256- bits. Cada tamao de la clave de cifrado hace que el algoritmo se
comporte ligeramente diferente, por lo que el aumento de tamao de clave no slo ofrece un mayor
nmero de bits con el que se pueden cifrar los datos, sino tambin aumentar la complejidad del
algoritmo de cifrado [3].

44

Captulo 3: Evaluacin y seleccin de herramientas

Para poder realizar una encripcin con AES-256 del Sistema Operativo Ubuntu desde su instalacin ,
revisar el ANEXO H al final de este documento.

3.4.1.1 Ventajas Encripcin del Sistema Operativo

La proteccin de la informacin en caso de robo fsico es poco contemplada, pero realmente es de


suma importancia debido a que si alguien roba un servidor de manera fsica, es preferible que no
tenga acceso a la informacin que se encuentre dentro de l o de ser posible que la vea pero no sea
entendible para que no pueda extraer los datos del disco duro.
Para poder brindar seguridad a este problema se implementa la encripcin del sistema operativo
completo y con una proteccin de una clave comn (contrasea), as en caso de robo no podr tener
acceso a la informacin o programas sin la clave comn con la cual se puede desencriptar el
contenido y tampoco ver la informacin conectando el disco duro en otra computadora puesto que
la informacin se encuentra encriptada por lo que no entender nada de su contenido.

3.4.1.2 Desventajas Encripcin del Sistema Operativo

La principal desventaja que se tiene cifrando el contenido y sobre todo con el cifrado AES es que la
tcnica de cifrado es realmente fuerte y en caso de no recordar la Clave comn, jams se podr
acceder a la informacin almacenada ni al sistema operativo, por lo que es necesario reinstalar todo

45

Captulo 3: Evaluacin y seleccin de herramientas

el sistema operativo que ha sido encriptado previamente y se perder la informacin que haya sido
guardada en el medio de almacenamiento administrado por dicho sistema operativo.

3.4.2 OpenDNS

Retomando el punto 2.4.2 Filtrado de contenido web usaremos OpenDNS para el filtrado web del
proyecto.
OpenDNS es un servicio totalmente gratuito que promete mejorar todos los aspectos negativos del
servicio de DNS de los proveedores de Internet. Este servicio tiene diferentes propsitos, pero un solo
fin que es el de mejorar la manera en la que se navega por Internet. Esto lo logra haciendo la
navegacin ms segura y rpida [9].
OpenDNS permite utilizar sus servidores DNS en lugar de usar lo que el proveedor de acceso a
Internet otorga por default.
OpenDNS es rpido y posee funciones de proteccin (anti-phishing y otros).
Caractersticas:

Generalmente ms rpido que el proveedor de acceso a Internet (estos poseen enormes


servidores, con un cach DNS importante)

Ms fiable (OpenDNS es muy fiable y sus servidores tienen una disponibilidad del 100%)

Autocorreccin de pequeos errores al teclear (google.cmo o gogle.com)

Proposicin automtica (Motor de bsqueda) si el dominio no existe.

46

Captulo 3: Evaluacin y seleccin de herramientas

Proteccin anti-phishing (OpenDNS est conectado directamente a PhishTank.com)

El servicio es gratuito

No hay necesidad de instalar ningn programa (slo la direccin del DNS por configurar)

Cuando sea es posible dejar de utilizar OpenDNS.

La mayora de usuarios de OpenDNS han constatado una mejora del rendimiento, en particular el de
los navegadores.

3.4.3 Monitorizacin

Tomando en cuenta el punto 2.4.3 Monitorizacin se demuestra porque se han usados dos
herramientas (una para la monitorizacin en tiempo real y otro que genere un historial) para el
control de recursos del servidor.
Cuando se tienen servidores, se vuelve una necesidad que sean monitorizados para estar alertas a
cadas o fallos en los servicios, puertos, y poder tomar las acciones correspondientes. Saber y
mantenerse enterados de que servicios estn corriendo, el uso del servidor, cadas del sistema entre
muchas otras cosas.
A continuacin se explican brevemente las 2 aplicaciones que se usaron para el monitoreo en este
proyecto.

47

Captulo 3: Evaluacin y seleccin de herramientas

3.4.3.1 Munin

Munin es un software de monitorizacin para equipos Linux bajo licencia GNU GPL, que permite
monitorizar muchos parmetros y visualizarlos en cmodas grficas diarias, semanales, mensuales y
anuales. Puede usarse para comprobar el estado de salud y carga de las mquinas, anticipar
problemas de rendimiento o capacidad y en caso de problemas ofrece valiosa informacin sobre los
momentos anteriores al problema para verificar cual fue la falla exacta.
Su funcionamiento se basa en un modelo cliente-servidor. En los clientes, llamados nodos, se
ejecutan los diversos plugins que conforman cada monitor que se desea controlar, y el servidor
central se comunica con cada nodo para recopilar peridicamente los datos que generan de forma
local los plugins.
Los logs se guardan en /var/log/munin
Para instalar este programa, configurarlo y ejecute sus funciones, se muestra el procedimiento en
ANEXO I.

3.4.3.2 Conky

Conky es una herramienta para monitorizar el sistema, es muy liviano y se encuentra disponible para
Linux, FreeBSD, y OpenBSD, es muy potente pero tambin es altamente configurable, y ha obtenido
varios premios por Linux, como uno de los programas "ms tiles y mejor mantenidos". Es una
aplicacin que dibuja informacin de texto en el escritorio para verificar el comportamiento del
sistema operativo y el hardware en que este instalado [12].

48

Captulo 3: Evaluacin y seleccin de herramientas

Puede monitorear muchas variables del sistema incluido el estatus del CPU, memoria, espacio del
swap, disco duro, temperaturas, procesos, interfaces de red, batera, sistema de mensajes, correos,
actualizaciones de Arch Linux, los ms populares reproductores de msica (MPD, XMMS2, BMPx,
Audacious), y mucho ms.
Para instalar, ejecutar al inicio del sistema y la ubicacin de los archivos de configuracin de Conky, se
muestra en el ANEXO J.

3.4.4 Solucin en Ubuntu para Bomba Fork

Para evitar ser vctima de los Ataques de Denegacin de Servicio explicada en el tema 2.4.4 Ataque de
Denegacin de Servicio (DDOS), se muestra la solucin en Ubuntu para evitarlo. Esto se realiza
editando un archivo de configuraciny se hace la prueba correspondiente para verificar los
resultados.
Para editar el archivo de configuracin escribir lo siguiente en la consola:
sudo /etc/security/limits.conf

En ste archivo se debe agregar la siguiente lnea:


* hard nproc 1000

Cabe aclarar que cada distribucin viene configurada con un nmero de procesos mximos, aunque
varias distribuciones (dependiendo de la versin) tienen un nmero ilimitado de procesos a ejecutar.

49

Captulo 3: Evaluacin y seleccin de herramientas

Para saber cul es el nmero mximo de procesos que pueden ser ejecutados por un usuario, se
escribe en consola el siguiente comando:
ulimit -u
Para hacerlo desde la consola de comandos, escribir ulimit u 1000 para establecer como 1000 el
nmero de procesos mximos o el que se desee poner:

Figura 16: Verificar si ha quedado de manera correcta el nmero de procesos mximos

El nmero que se muestra cuando tecleamos el comando ulimit -u representa la cantidad de


procesos que puede se pueden ejecutar en la sesin activa, por lo cual si llega a poner un lmite, no
podr congelar la sesin o servidor.
Para comprobar que no se congela el servidor se escribe en la consola de comandos la bomba fork
como se muestra en la Figura 17.

Figura 17: Como hacer una Bomba Fork desde consola

Se puede observar que el sistema ya no se congela, de hecho posiblemente aparezca algo como:

Figura 18: Solucin de Bomba Fork correcta

50

Captulo 3: Evaluacin y seleccin de herramientas

Para poder quitar esta lnea de la consola y tenerla en estado normal, presionar Ctrl + C, as se
cancelar el proceso, de esta manera se pueden poner otros comandos y seguir con el uso de la
consola [31].
Para ver diferentes ejemplos de cmo hacer una Bomba Fork, revisar el ANEXO K.

3.4.5 Proteccin de ataques por fuerza bruta con Fail2ban

Tomando en cuenta el punto 2.4.5 Por qu proteger un servidor Linux de ataques por fuerza bruta?
de este documento, se considera que para evitar la vulnerabilidad de fuerza bruta por medio de
intentos fallidos o de diccionario, es necesario implementar la herramienta Fail2ban para banear a
quienes intenten realizar este tipo de acciones.
Fail2ban es un script en Python el cual permite monitorizar los archivos de registro o logs para
analizar si se es objeto de un ataque de tipo fuerza bruta y as realizar diferentes acciones como:

Bloquea las direcciones Internet de donde se hayan originado varias tentativas fallidas de acceso
con contrasea invlida.

Bloquear mediante IPtables.

Hacer deny a la IP del atacante en el archivo hosts.

Realizar un whois.

Notificar al administrador de red sobre la accin.

Entre otras acciones que se pueden ir agregando a la configuracin.

51

Captulo 3: Evaluacin y seleccin de herramientas

Fail2Ban es extremadamente eficaz en la prevencin de ataques de fuerza bruta y ataques de


negacin de servicio (Dos) [25].
Para poder realizar una eficaz proteccin con Fail2Ban revisar el ANEXO L donde se explica cmo se
instala y configura el programa.

52

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Captulo 4
4 Propuesta del modelo de red
"Innovar es encontrar nuevos o mejorados usos a los recursos de los que ya disponemos"
Peter Drucker

En el captulo anterior se evalu el software que pondr a funcionar el modelo de red. En este
captulo se propone la infraestructura del modelo de red. Este modelo de red es creado basndose en
la infraestructura de la virtualizacin y los clientes ligeros, uniendo estas dos tecnologas para obtener
un modelo de red que permita montar un centro de cmputo de baja demanda, reutilizando equipo
de cmputo obsoleto.

Captulo 4: Propuesta del modelo de red

4.1 Descripcin del Modelo

El modelo consiste en montar un servidor de mquinas virtuales que alojar como sistema invitado
un servidor de clientes ligeros, de este modo se tienen en funcionamiento laboratorios de cmputo
independientes entre s pero centralizados en un mismo servidor. El diagrama de red que resulta de la
combinacin de estas dos tecnologas es el que se muestra en la figura siguiente.

Figura 19: Modelo de infraestructura Cloud.ia

Dentro del modelo se pueden identificar tres elementos importantes, los clientes, el servidor virtual
de clientes ligeros y el servidor de mquinas virtuales, en las siguientes secciones se profundizar en
estos tres aspectos.

54

Captulo 4: Propuesta del modelo de red

4.2 Computadoras Cliente

Las computadoras cliente actuarn como terminales en este modelo, por las caractersticas tcnicas
que deben tener estas computadoras, se permite que para este modelo se puedan utilizar:
a) computadoras obsoletas
b) clientes ligeros dedicados

4.2.1 Computadoras obsoletas

CPU
Los proyectos para montar clientes ligeros recomiendan que las computadoras que se vaya a utilizar
como clientes ligeros tengan un procesador de aproximadamente 500MHz.
Red
Un cliente ligero bootea a travs de la red por distintos medios, en caso de ste modelo se propone
utilizar distintos boot loaders a fin de lograr el booteo por red, estos bootloders son:

PXE: Este es el ms comn y muchas tarjetas de red traen este boot loader incluido.

Etherboot/gPXE: Es un boot loader de software libre que puede ser utilizado en aquellas
computadoras cuya tarjeta de red no soporte PXE, puede utilizarse desde un disquete, CD o
quemarse en una eeprom si la tarjeta de red tiene un slot para ello.

55

Captulo 4: Propuesta del modelo de red

Memoria RAM
El mnimo de memoria RAM que debe tener un cliente ligero son 48MB, pero se recomienda instalar
al menos 128MB, lo ptimo sera tener 256MB, con esto mejora la velocidad de los clientes ligeros.
Tarjeta de video
Cualquier tarjeta de video con 16MB de memoria o ms debe funcionar bien para cualquier cliente
ligero.
Saber si una computadora funciona como cliente ligero
Existen computadoras con caractersticas inferiores que pueden ser utilizadas como clientes ligeros,
pero no todas cumplen con los requisitos mnimos, es por eso que se propone un formato para saber
si una computadora puede ser utilizada como cliente ligero.
La tabla 4 muestra los requisitos obligatorios para determinar si la computadora en cuestin puede
servir como cliente ligero.
REQUISISTOS OBLIGATORIOS

SI

NO

Procesador mnimo de 200 Mhz


Memoria RAM mnimo de 64 MB
Fuente de poder funcional
Puerto VGA para monitor
Puertos USB mnimo 2
Puerto Ethernet
Botn de encendido funcional
Tabla 4: Requisitos obligatorios para un cliente ligero

56

Captulo 4: Propuesta del modelo de red

La tabla 5 muestra las opciones para el booteo de red del cliente ligero configurando desde el BIOS,
tambin es de manera obligatoria cumplir con al menos una de las opciones mostradas.
REQUISITOS PARA EL BOOTEO DE RED

SI

NO

Booteo PXE en configuracin de BIOS


Floppy
Booteo por puerto USB en configuracin de BIOS
Unidad de CD, CD-RW, DVD, DVD-RW, BR, BR-RW
Tabla 5: Requisitos para booteo de red para un cliente ligero

En caso de no cumplir todos los requisitos mnimos de la Tabla 4 y al menos una de la Tabla 5, la
computadora no podr ser parte de la red, debido a que para efectuar las tareas que realiza el cliente
ligero es necesario tener esas caractersticas bsicas.
Si ha cumplido con las Tablas anteriores, llenar la Tabla 6 para terminar el formato, de lo contrario
regresar el formato al administrador de red.
Los requisitos de la Tabla 5 son opcionales, el propsito de la tabla es saber que opciones de conexin
puede tener el cliente ligero.
REQUISITOS OPCIONALES

SI

NO

Puertos PS-2 (de 1 a 2)


Entrada de micrfono
Salida de audio
Tabla 6: Requisitos opcionales para un cliente ligero

57

Captulo 4: Propuesta del modelo de red

4.2.2 Clientes ligeros dedicados

Los clientes ligeros dedicados no requieren de mucha atencin en cuanto a especificaciones, el cliente
ligero menos potente en el mercado tiene caractersticas similares a las de una computadora
obsoleta, con la ventaja de reducir el consumo elctrico.

4.3 Servidor virtual de clientes ligeros

Los requerimientos de un servidor de clientes ligeros son muy relativos al tamao de la red y a las
expectativas de sta. Los requerimientos varan mucho en una red en la cual solo se har navegacin
web sin java ni flash en comparacin con una red la cual har uso intensivo de grficos, juegos y
animaciones.
Aun as se pueden seguir algnas recomendaciones de casos de xito y ajustarlos a las necesidades de
la red que se est montando, las recomendaciones que hace el proyecto LTSP son las siguientes:

4.3.1 Memoria

Una distribucin Linux hace uso eficiente de la memoria. La primera sesin de usuario que cargue
consumir aproximadamente entre 250 y 300 MB de RAM. Cada sesin siguiente usar entre 50 MB y
80 MB adicionales. Esto puede ayudar a calcular la cantidad de RAM necesaria para el servidor.
Siempre tomando en cuenta que ser variable dependiendo de qu programas carguen los usuarios.

58

Captulo 4: Propuesta del modelo de red

La frmula que se utiliza para calcular la cantidad de memoria respecto a cada cliente ligero es:
256 + (192 * usuarios) MB
Entonces, para tener veinte clientes ligeros funcionando, la formula seria:
256 + (192 * 20) = 256 + 3840 = 4096 MB

4.3.2 Procesador

El procesador tambin depender de las tareas a realizar en la red de clientes ligeros. Una red con
pequeas necesidades funcionaria bien con un procesador de 2GHz. Para redes ms grandes o con
ms carga de trabajo se pueden aprovechar los procesadores multi ncleo.

4.3.3 Disco duro

Es recomendable utilizar arreglos de disco en el servidor, con una configuracin RAID 1 en la cual se
conectan discos duros en paralelo para mejorar la velocidad, con dos discos duros es suficiente. Para
una red ms grande, una configuracin RAID 10 en la cual se asegura velocidad y disponibilidad de
datos, es ms que suficiente.

59

Captulo 4: Propuesta del modelo de red

4.4 Servidor de mquinas virtuales

Para poder realizar tareas de virtualizacin, el servidor requiere de un hypervisor, se recomienda en


la medida de lo posible instalar un hypervisor nivel 1 (bare-metal, a nivel hardware), si se va a instalar
un hypervisor de tipo 2 (sobre un sistema operativo base), se recomienda instalar un sistema
operativo tipo UNIX, ya que gestionan mejor los recursos del servidor.
Para dar salida a las interfaces de red virtuales (VNICs) de las mquinas virtuales a travs de una
interfaz de red (NIC), cada VNIC debe ser conectada a una NIC en modo BRIDGED, de este modo se
podrn intercambiar datos entre el ambiente virtual y el fsico.
Dentro del servidor, el hypervisor debe tener configurada una interfaz de red de algn modo que
permita proveer a las mquinas virtuales de Internet, como ejemplo en la figura 20, la interfaz de red
est configurada en modo Traduccin de Direcciones de Internet (NAT), de esta manera todas las
mquinas virtuales conectadas a sta interfaz tendrn acceso a Internet.

60

Captulo 4: Propuesta del modelo de red

Figura 20: Diagrama del servidor de mquinas virtuales

Se recomienda que la administracin del servidor se realice remotamente, con esto se evita utilizar el
servidor como otra mquina ms y as se previene que el rendimiento del servidor no sea
desperdiciado en tareas superfluas o que no tienen que ver con el desempeo de las mquinas
virtuales.

61

Captulo 4: Propuesta del modelo de red

4.5 Red

Para reducir la demanda de las interfaces de red, cada interfaz de red del servidor estar vinculada a
una maquina virtual, por lo tanto, se tendrn tantas maquinas virtuales de como interfaces de red
tenga el servidor -1, esto para reducir la demanda de ancho de banda que puede otorgar un cable de
red UTP.
Un factor importante a recordar es que la red funciona tan rpido como la parte ms lenta de la red.
Se debe asegurar que la configuracin de red se adece a las necesidades de la red montada.

4.5.1 Red cableada

Las redes cableadas pueden transferir paquetes en estas distintas velocidades: 10 Mbit/seg, 100
Mbit/seg, 1000 Mbit/seg (Gigabit). Se recomienda utilizar una conexin de 1000 Mbit/seg entre la
interfaz de red del servidor y el switch ya que esta interfaz estar conectada a varias computadoras
cliente y ser por donde pasen todas las peticiones de los clientes. Para conectar cada computadora
cliente al switch, es suficiente una conexin de red de 100 Mbits/seg.
Una red solo es til si pueden ser conectadas varias computadoras, existe hardware para conectar
varias computadoras en red, son parecidos pero su funcin es diferente y la velocidad a la que operan
tambin.

62

Captulo 4: Propuesta del modelo de red

Hub
Es la manera ms simple de conectar varias computadoras. Un hub recibe mensajes en un puerto y
los reenva a todos los puertos. En un hub solo un puerto puede hablar a la vez.
Switch
Un switch es muy parecido a un hub, con la excepcin que un switch solo hace conexin entre os
puertos que lo necesitan. Un switch puede mantener varias conexiones a la vez, por lo que un switch
resulta ms rpido que un hub.
Router
Un router se utiliza para hacer una conexin entre dos redes. Los routers comnmente son utilizados
para conectar una LAN a Internet.

4.5.2 Red inalmbrica

Este modelo no est preparado para utilizar una conexin inalmbrica por las siguientes razones.
Una red inalmbrica normalmente tiene ms latencia que una red cableada, esto hace que los
programas se sientan lentos y/o que no responden.
Un adaptador de red inalmbrica no puede ejecutar directamente el booteo mediante PXE, adems
de necesitar la configuracin de la red como la ESSID, KEY, etc. Y no existen estas caractersticas en
una tarjeta con PXE.

63

Captulo 4: Propuesta del modelo de red

Existen herramientas que otorgan la capacidad de bootear por wifi a las mquinas, pero se requiere
ms hardware para realizar esto y aun as no se puede reducir la latencia de la red, la experiencia de
uso no sera satisfactoria debido a la lentitud del sistema.

4.5.3 Resumen

Para montar la red:


La red en cada laboratorio se conecta en forma de estrella, las computadoras estn conectadas a un
switch el cual est conectado al servidor. Esto se hace en cada laboratorio que se quiera montar, cada
switch va conectado a una interfaz de red del servidor y cada interfaz se configura en puente con una
mquina virtual.
Para montar el servidor de mquinas virtuales:
Se procede a instalar el hypervisor elegido. El servidor debe contar con varias interfaces de red, una
est conectada a Internet, las otras son para los laboratorios y se conectan en puente con la interfaz
de red virtual de cada mquina virtual.
Para montar el servidor de clientes ligeros:
Se realiza la instalacin de Linux sobre una mquina virtual, configurando dos interfaces virtuales de
red, una conectada a la interfaz que provee el internet, la otra conectada en modo puente con una
interfaz del servidor. Recordar que esta interfaz ser conectada a un switch.

64

Captulo 4: Propuesta del modelo de red

La figura 21 es un diagrama que muestra lo descrito en el resumen del captulo:

Figura 21: Diagrama de red completo

65

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Captulo 5
5 Prueba virtual del modelo de red
"La mejor forma de predecir el futuro es implementarlo"
David Heinemeier Hansson

Con el fin de validar el funcionamiento de este modelo de red, se realiz una prueba virtual de dicho
modelo, como se describi al principio del captulo anterior, este modelo precisa de 3 elementos
indispensables: el servidor de mquinas virtuales, el servidor virtual de clientes ligeros y los clientes
ligeros.
Al ser una prueba virtual, el rendimiento y la extensin de la prueba dependen del rendimiento del
servidor, como los clientes conectados a esta red tambin sern virtuales, el rendimiento del servidor
es reducido por el consumo de los clientes virtuales.
Esta prueba virtual se limita a validar la posibilidad de obtener el sistema operativo desde un
ambiente virtual.

Captulo 5: Prueba virtual del modelo de red

5.1 Elementos Utilizados en la Prueba

5.1.1 Servidor

La computadora que se utiliz como servidor de mquinas virtuales tiene las siguientes
caractersticas:

Procesador: Intel i5-560m

Memoria: 8 GB DDR3

Video GeForce 310M 512MB

Sistema Operativo: Windows 7 Pro (64 bits)

5.1.2 Hypervisor

Al no contar con la libertad de cambiar el sistema operativo del servidor, el hypervisor elegido fue
VirtualBox. Aunque VirtualBox da la impresin de ser poco profesional, en realidad es una opcin muy
extendida y utilizada para virtualizacin a nivel personal y para esta prueba resulta suficiente.
NOTA: VirtualBox debe tener instalado el Pack de extensiones para habilitar la opcin de booteo por
red.

67

Captulo 5: Prueba virtual del modelo de red

5.1.3 Servidor virtual de clientes ligeros

Para montar un servicio virtualizado existen dos alternativas con las cuales se puede desplegar la
mquina virtual en el servidor: una de ellas consiste en instalar el sistema operativo y las aplicaciones
requeridas siguiendo el mismo procedimiento como si se tratara de la instalacin sobre hardware
fsico, la segunda opcin es utilizar una mquina virtual previamente configurada por la misma
persona o por terceros.
A esta segunda opcin, de utilizar una mquina virtual previamente configurada se le llama appliance.
Como servidor virtual de clientes ligeros se utiliz un appliance de openthinclient OS el cual viene pre
configurado con las caractersticas que muestra la figura 22:

Figura 22: Appliance de openThinClient OS

5.1.4 DHCP

OpenThinClient OS requiere de un servidor DHCP en la misma red pero no en la misma mquina, para

68

Captulo 5: Prueba virtual del modelo de red

montar este servidor DHCP se utiliza Debian 6 como sistema operativo, el servidor DHCP tiene la
siguiente configuracin:
Red

192.168.1.0

Rango

192.168.1.50 - 192.168.1.60

IP del servidor

192.168.1.1

Nombre del servidor

thin.tesco.mx

Broadcast

192.168.1.255

Gateway

192.168.1.1
Tabla 7: Configuracin del servidor DHCP

Despus de montar el servidor DHCP, se exporta como appliance (servicio virtualizado), si en algn
momento se necesita utilizar de nuevo, basta con importarlo como servicio virtualizado dentro del
men de opciones de VirtualBox.

Figura 23: Men de opciones VirtualBox

El diagrama de la red virtual queda de la siguiente manera: con un servidor de clientes ligeros, un
servidor DHCP y tres clientes conectados a travs de un switch, tal como lo muestra la figura 24:

69

Captulo 5: Prueba virtual del modelo de red

Figura 24: Diagrama de red virtual

5.2 Iniciando la Prueba

El propsito de esta prueba es comprobar que efectivamente puede funcionar un servidor de clientes
ligeros virtualizado dentro de un servidor fsico dedicado a gestionar mquinas virtuales, esto
simulando el modelo de red propuesto en captulos anteriores y verificando que los clientes ligeros
pueden obtener el sistema operativo a travs de un servidor virtualizado.
Al ser una prueba virtual, es complicado mostrar grficamente cmo funciona el modelo en conjunto,
sin embargo se puede describir el proceso que siguen los elementos involucrados en el modelo
dentro de la red.

70

Captulo 5: Prueba virtual del modelo de red

Para realizar esta prueba, se simulan dos laboratorios los cuales son formados por los siguientes
elementos para cada laboratorio: un servidor de clientes ligeros, un servidor DHCP y tres clientes
conectados.
Mquina Virtual
Debian 6
Ubuntu 10.04
Sin Sistema Operativo

Rol
Servidor DHCP
Servidor de Clientes Ligeros
Cliente Ligero

Tabla 8: Mquinas Virtuales de la red virtual

El estado inicial de la red est dado por tres computadoras conectadas a un switch, tanto del
laboratorio A como en el B, los cuales estn representados en la figura 25:

Figura 25: Estado inicial de la red

Para agregar el servidor de clientes ligeros se procede conforme los pasos descritos a continuacin:
Se configura la red virtual en modo red interna, los nombres dados a la red son laboratorioA y
laboratorioB para el primer y segundo laboratorio respectivamente.

71

Captulo 5: Prueba virtual del modelo de red

Se importan las appliances del servidor DHCP y del servidor de clientes ligeros.
Se clona cada appliance para poder ser utilizadas por el segundo laboratorio.
Se configura la interfaz de red de cada appliance para que correspondan a un laboratorio, ya sea A o
B.
Asegurarse que las MAC de las appliances sean diferentes, pues al ser clonadas se copia
completamente la configuracin.
Se inicia el servidor DHCP de ambos laboratorios y se espera a que termine de cargar, en este
momento las siguientes computadoras que se inicien dentro de la red sern provistas de una
direccin ip.
Se inicia el servidor openThinClient OS de ambos laboratorios, con una ip provista por el servidor
DHCP.
A partir de este momento estn montados los servicios virtuales, preparados para proveer el sistema
operativo a las computadoras cliente.
A continuacin se da inicio uno a uno a los clientes conectados en cada laboratorio, para este
momento la red de cada laboratorio cuenta con un servidor virtual de clientes ligeros (TCVS), un
servidor DHCP, en este caso tambin virtualizado, tal como muestra la figura 26:

72

Captulo 5: Prueba virtual del modelo de red

Figura 26: Diagrama de red final de la prueba

Para obtener algn dato relevante, se opt por medir el consumo de RAM. En la figura 27 se muestra
el consumo de recursos del servidor virtual de clientes ligeros, sin ningn cliente conectado.

Figura 27: openThinClient sin clientes conectados

En las figuras 28 a 30 se muestra el consumo de RAM por parte de los clientes conectados al servidor.

Figura 28: openThinClient con un cliente conectado

73

Captulo 5: Prueba virtual del modelo de red

Figura 29: openThinClient con 10 clientes conectados

Figura 30: openThinClient un cliente conectado y Firefox

5.3 Resultado de la Prueba

En la tabla 9 se muestra un resumen del consumo de memoria que tienen los clientes respecto al
servidor.
No.
De
clientes
conectados
1
2
3

10

Consumo
memoria (MB)
297
298
299
...
303

de Consumo de memoria con


Firefox corriendo (MB)
324
324
324

324

Tabla 9: Consumo de memoria de los clientes ligeros

En la tabla anterior se puede apreciar que el consumo de memoria a partir del segundo cliente
conectado es menor que el consumo del primer cliente conectado, de la misma manera, el consumo
de los clientes al iniciar Firefox es prcticamente el mismo si la aplicacin es iniciada por uno o por
varios clientes, este comportamiento se da por que en Linux todas las aplicaciones comparten

74

Captulo 5: Prueba virtual del modelo de red

libreras del sistema y/o de terceros y al iniciar varias copias de la misma aplicacin, en lugar de iniciar
varias copias de las libreras, stas son compartidas por la primer instancia de la aplicacin, es por
esto que el consumo de memoria es menor, recordando la frmula para calcular la cantidad de RAM
necesaria por nmero de clientes:
256 + (192 * usuarios) MB
* Nota: Recordando que en esta prueba, los clientes ligeros tambin son virtuales y no fsicos, el
rendimiento de la computadora en la cual se realizaron las pruebas se vio afectado tras iniciar dos
servidores DHCP, dos servidores virtuales de clientes ligeros y seis clientes juntos, por lo cual no se
pueden realizar pruebas exhaustivas del modelo de red, la siguiente figura muestra el estrs al que
fue sometido el procesador de la computadora utilizada como servidor, haciendo necesario detener
la prueba.

Figura 31: Consumo de recursos del servidor con 10 maquinas virtuales simultneas

Con todo y las limitaciones respecto al hardware utilizado para las pruebas, la finalidad de esta
prueba se cumple, comprobando la funcionalidad del modelo, confirmando que: un servidor de
clientes ligeros puede funcionar a travs de un ambiente virtualizado.

75

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Captulo 6
6 Consideraciones, conclusiones y trabajos
futuros
" La mejor razn para crear una empresa es para tener un impacto: crear un producto o servicio que
haga del mundo un lugar mejor"
Guy Kawasaki

En este captulo se hace nfasis a hechos que fueron tomados en cuenta para realizar este proyecto.
Son aspectos que sirvieron como motivacin y muestran puntos de vista no necesariamente tcnicos;
pueden ser considerados como conclusiones del proyecto, mas no del documento. Las conclusiones
del documento estn enseguida de estos puntos de vista. Para finalizar, despus de las conclusiones
hay un breve espacio dedicado a posibles trabajos futuros que podran derivar de este documento.

Captulo 6: Consideraciones, conclusiones y trabajos futuros

6.1

Aspecto Econmico

En los ltimos aos hubo principalmente dos eventos que impulsaron ligeramente la popularidad del
sistema operativo Linux; uno fue la salida al mercado de Windows Vista y su posterior fracaso, el otro
la crisis econmica que afect a todo el mundo. Un argumento y razn de peso fue la cantidad de
recursos de hardware que exiga Windows Vista al momento de salir al mercado y la falta de
compatibilidad con antiguas aplicaciones, por lo que muchos usuarios buscaron alternativas al no
poder escalar sus equipos de cmputo en ese momento.
En varios pases de habla Hispana (y del resto del mundo) se realizaron implementaciones de
software libre en instituciones de gobierno; pases de Europa, de Centro y Sud Amrica comenzaron
con la migracin de sus sistemas informticos.
En esos pases los modelos basados en software libre han tenido gran aceptacin por parte de los
usuarios, los gobiernos han reconocido que en verdad existe un ahorro econmico y una
independencia tecnolgica que resulta importante a futuro.
En Mxico, en su momento se firm un convenio con Microsoft para que fuera proveedor exclusivo
de la plataforma tecnolgica del gobierno

[20],

dejando fuera completamente a cualquier otra

alternativa que se presentara. Afortunadamente este ao termina ese convenio y por fin el gobierno
considera al software libre como proveedor de servicios tecnolgicos

[29],

por lo que se pronostican

grandes oportunidades para industria mexicana de software ya que habr desarrollo de tecnologa
propia.

77

Captulo 6: Consideraciones, conclusiones y trabajos futuros

6.2 Aspecto Ambiental

Por basura tecnolgica se refiere a los desechos electrnicos de la industria de cmputo. La basura
tecnolgica es un problema que afecta principalmente a habitantes de pases en vas de desarrollo;
especficamente los pases de frica que son utilizados como vertederos de este tipo de desechos.
En Mxico no existe cultura de reciclaje ni de tratamiento de desechos, independientemente de los
programas del gobierno para el reciclaje de basura tecnolgica, en este breve texto no interesa tanto
el recorrido de estos desechos, es de mayor inters su destino. Para agravar este problema, los
avances y mejoras tecnolgicas ocurren en cortos espacios de tiempo, induciendo la obsolescencia de
los dispositivos actuales y su reemplazo, provocando as la acumulacin de ms basura tecnolgica
[27].

La rpida obsolescencia de los equipos de cmputo hace complicado el tratar con la basura
tecnolgica. Las compaas de hardware han optado por recolectar las computadoras viejas y
disponer de ellas de alguna manera, por ejemplo suelen donar estas computadoras a organizaciones
no lucrativas de manera tal que estas organizaciones pueden obtener computadoras que si no son
muy modernas, al menos son suficientemente competitivas para sus propsitos. De este modo se
extiende la vida de las computadoras y tambin se cuida del medio ambiente pues estas
computadoras no terminan como basura tecnolgica.

78

Captulo 6: Consideraciones, conclusiones y trabajos futuros

6.3 Aspecto Tecnolgico

En el contexto del inicio de este proyecto, la tecnologa de infraestructura tecnolgica que est dando
de qu hablar es el Cloud Computing y la virtualizacin. Los costos en componentes de las
computadoras se han reducido bastante; en la actualidad se pueden tener computadoras con alto
poder de procesamiento y almacenamiento por un costo relativamente bajo.
Esto tiene como consecuencia que el Cloud Computing y la virtualizacin est cada vez ms al alcance
de casi cualquier empresa, pues, al reducirse los costos, aparece como una opcin viable
econmicamente y deja de ser tecnologa que slo poda proveer las compaas poseedoras de gran
infraestructura.
El poder utilizar casi cualquier computadora como un servidor permite que montar un modelo de red
como lo propone este documento sea viable econmicamente y moderno. La comunidad de Linux
siempre est resolviendo errores y manteniendo las herramientas al da, por lo que siempre se estar
utilizando el software ms moderno, adems se explotar al mximo el servidor por medio de la
virtualizacin y estar preparado para dar el salto al Cloud Computing.

6.4 Aspecto Educativo

El crecimiento natural de la sociedad en cuanto a ciencia y tecnologa se ha dado a travs de


compartir avances con la comunidad cientfica, siendo estos conocimientos base para que otras
personas pueden crear e innovar con nuevas propuestas.

79

Captulo 6: Consideraciones, conclusiones y trabajos futuros

Pocas instituciones como la Universidad Autnoma de Chihuahua que es la primera universidad en


Mxico en ofrecer una maestra en software libre, han integrado el uso y enseanza del software libre
en sus aulas dando paso a que las Universidades en Mxico poco a poco integren en su retcula
materias enfocadas a la enseanza de estas tecnologas.
La escuela no est obligada a ensear cierta tecnologa o algn lenguaje de programacin en
especfico. El alumno es responsable de mantenerse al da respecto a las herramientas que se utilizan
en lo referente a Sistemas. Actualmente existen muchas alternativas para obtener un acercamiento a
las herramientas que se utilizan en el mbito profesional, Microsoft tiene el programa Dreamspark
(www.dreamspark.com) el cual proporciona a maestros y alumnos herramientas de desarrollo de la
propia compaa sin costo alguno.
sta es una alternativa vlida para acercar a los alumnos a tecnologa utilizada profesionalmente, no
obstante, existe otra alternativa, sin descalificar ni menospreciar ste programa de Microsoft, que
bien puede ser combinado con herramientas libres.
Por el lado del software libre y/o de cdigo abierto tambin estn accesibles muchas herramientas
que si bien su consumo por usuarios finales no es tan extendido, s se encuentran en los grandes
sistemas que al da de hoy soportan la infraestructura de las grandes redes, entre ellas Internet.
Compartiendo la opinin de Pedro Galvn, Director General de la revista Software Gur, los
lenguajes de programacin que conviene aprender y que permanecern en el futuro son aquellos que
sean multiplataforma, hbridos, escalables y orientados a sistemas concurrentes [15]. Por ello es mejor
para un alumno aprender con lenguajes de programacin independientes de la plataforma.

80

Captulo 6: Consideraciones, conclusiones y trabajos futuros

6.5 En Resumen

El modelo de red que se define en este documento hace uso de tecnologas libres, este tipo de
herramientas han estado ganando terreno frente a las opciones tradicionales/privadas. Si se
implementa un modelo de red como el expuesto en este documento, al estar basado en software
libre, entre los beneficios que traera estn:
Fomenta la capacitacin del personal y desarrollo de habilidades ya que la gente trabaja en el
proyecto en lugar de contratar a externos que lo implementen.
El conocimiento se queda dentro de la institucin, siendo el mismo caso del punto anterior, quien
desarrolla es la misma gente dentro de la institucin y no alguien externo.
Permite extender el tiempo de uso de equipos de cmputo obsoletos, reduciendo la cantidad de
recursos econmicos que se debe invertir en infraestructura que remplace los equipos de cmputo
actuales.
Como se ha mencionado a lo largo de este documento, este modelo es flexible y se puede adaptar e
implementar en cualquier centro de cmputo que requiera bajo poder de procesamiento, como
pudiera ser el sector educativo, el sector salud, gobierno, caf internet, oficina, etc. Todo esto siendo
amigables con el medio ambiente, reutilizando equipos de cmputo obsoletos y evitando que se
conviertan en desechos tecnolgicos.
Por lo tanto, implementar un laboratorio de cmputo con software libre donde se puedan combinar
tecnologas de Cloud Computing privado y pblico y con las caractersticas que se propone en este

81

Captulo 6: Consideraciones, conclusiones y trabajos futuros

documento, puede resultar una solucin viable para algunos problemas como la rpida obsolescencia
de computadoras, el poco poder adquisitivo y diversas dificultades para la renovacin de centros de
cmputo.
Para abrir las puertas a la innovacin, este modelo estar abierto a sugerencias y modificaciones ya
sea en aspectos visuales, tcnicos o de negocio, para que, una vez replicado, sea adaptado a
necesidades particulares y a partir de ah desarrollar tecnologa propia y libre.

6.6 Conclusiones

El modelo hace uso de tecnologa de virtualizacin y de clientes ligeros, estas dos tecnologas que
datan de los aos 60's se han renovado en la actualidad, en el caso de la virtualizacin, como base de
los servicios de cmputo en la nube.
El desarrollo de este modelo de red dio la oportunidad de conocer distintas distribuciones Linux,
adems de diversas herramientas de software libre con distintos fines como: KVM, Xen, Proxmox,
VirtualBox, VmWare en el caso de virtualizacin; openThinClient OS, LTSP, TCOS en el caso del
servidor de clientes ligeros; Fail2ban para banear cuando existe un nmero especificado de fallos en
el login; Munin y Conky en caso de monitorizacin, AES-256 para cifrar el disco duro y configuraciones
de sistema para evitar los DDOS.
Todo el software empleado para este proyecto es software libre/gratuito por lo cual el gasto por
licencias de software es nulo teniendo como consecuencia una inversin inicial reducida si se toma en

82

Captulo 6: Consideraciones, conclusiones y trabajos futuros

cuenta el costo de las licencias de software de otras herramientas.


La idea original del proyecto, la cual consista en realizar una implementacin en la universidad, no
vari mucho: durante el desarrollo del proyecto se observ que la implementacin del modelo de red
propuesto puede llevarse a cabo en distintos escenarios que tengan caractersticas y/o necesidades
similares a las descritas a continuacin:

Implementar una red nueva o reutilizar una existente (tanto equipo de cmputo como
infraestructura de red).

Tener computadoras obsoletas y querer reutilizarlas.

No invertir en nuevas computadoras (usando las obsoletas).

Realizar una baja inversin para renovar un laboratorio de cmputo (con el servidor).

Tener un control sobre los registros, datos y programas de manera centralizada (por medio de un
servidor).

No depender de programas privativos y evitar el pago de licencias (haciendo uso de software


libre/gratuito).

Todas estas necesidades/caractersticas pueden ser cubiertas por el modelo de red de sta
investigacin. Recordando que es recomendable implementar el modelo de red en un ambiente que
requiera de bajo a medio poder de procesamiento, stos son algunos de los escenarios en los que
puede ser implementado:

Cibercafs

Laboratorios de cmputo

83

Captulo 6: Consideraciones, conclusiones y trabajos futuros

Hogares

Pymes

Redes escolares

De tantas opciones que existen para virtualizar en la plataforma X86 se eligi la plataforma Proxmox
VE por cumplir con los requerimientos tcnicos, el principal: que permita virtualizacin completa. Est
preparado tambin para darle escalabilidad al modelo permitiendo montar cluster de servidores en
caso de ser necesario. Adems de caracterizarse de una interfaz de usuario amigable lo que permite
una gestin sencilla de las mquinas virtuales.
Como plataforma para el servidor de clientes ligeros se utiliz openThinclientOS, entre las caractersticas que destacan se encuentra la gestin de cuentas de usuario que se realiza mediante LDAP en
sustituto del sistema de usuarios y permisos que tiene Linux por default, lo que permite un mejor
rendimiento del servidor cuando se manejan gran cantidad de usuarios en el sistema.
La integracin de estas herramientas fue un xito y su funcionamiento fue demostrado en una prueba
virtual en la cual se puede observar la capacidad de una computadora de bajas prestaciones para
obtener el sistema operativo por medio de la red y adems ste sistema est siendo virtualizado por
un servidor.
El software sugerido para el montaje de este modelo puede ser elegido a conveniencia, recordando
que este modelo de red es muy flexible y adaptable casi a cualquier necesidad de implementacin.
Puede utilizarse software libre o privativo, El Hypervisor y el servidor de clientes ligeros puede ser de
distinto proveedor, los ajustes pertinentes deben realizarse por el interesado para adaptarlo al

84

Captulo 6: Consideraciones, conclusiones y trabajos futuros

escenario deseado.
El proyecto puede funcionar sin necesidad de implementar medidas de seguridad como las sugeridas
en ste documento, no obstante es recomendable reforzar el ambiente informtico para prevenir
posibles fallos en el mismo.
Para proteger el modelo de red de usuarios ociosos y con el fin de mejorar la integridad de la red, se
implementaron medidas de seguridad a nivel Software.
Para la proteccin de la informacin por un robo fsico se aseguraron los datos con la encripcin del
sistema operativo completo, esto no evita que sea robado el servidor, pero si asegura que cuando se
intente ver la informacin, no lo har de manera explcita.
La proteccin en las pginas de Internet ante el phishing, robo de identidad y malware malicioso es
resuelto con la inclusin de OpenDNS que nos advierte de estos tipos de contenidos y realiza el
filtrado de manera muy efectiva, aparte de incorporar ms cosas favorables al proyecto como son la
correccin de ortografa en las pginas web y ofrece control parental en caso de ser necesario.
Para tener un control de los componentes de Hardware que se tienen en los servidores virtualizados
o el servidor base es necesario que sean monitorizados y lo ideal es tenerlos monitorizados durante el
pasado (historial), el presente (tiempo real) y el futuro (como servicio), para lograrlo se usan las
herramientas Conky para el presente y Munin para el pasado/futuro. Ambos al consumir bajos
recursos no es un problema con respecto al uso de memoria o procesador del servidor virutalizado.
Debido al creciente uso del ataque de denegacin de servicios, se decidi dar dos opciones de
solucin para casos distintos, que son el ataque mediante procesos (Bombas Fork) y el ataque

85

Captulo 6: Consideraciones, conclusiones y trabajos futuros

mediante peticiones de logeo. El primero es para que no se realice la denegacin de servicio


mediante la saturacin de procesos en el sistema operativo llevndolo al freezeo al servidor
virtualizado, es solucionado limitando el nmero de procesos que puede ejecutar el cliente al mismo
tiempo. El segundo es un ataque de fuerza bruta solucionado haciendo un baneo a un nmero
asignado de intentos fallidos y evitar la agresin.

86

Captulo 6: Consideraciones, conclusiones y trabajos futuros

6.7 Trabajos Futuros

Siguiendo de cerca la tendencia de la industria de software mientras se desarrollaba este proyecto, la


cual se est orientando a servicios en la nube, en esta seccin quedan plasmados algunos caminos
que puede tomar este proyecto.
El proyecto est validado solo con pruebas virtuales, no est implementado en un ambiente fsico,
para una futura revisin del proyecto se podra llevar a cabo una implementacin con computadoras
obsoletas y/o clientes ligeros y realizar pruebas exhaustivas para determinar el funcionamiento
ptimo del modelo de red. La siguiente lista es una sugerencia de los insumos necesarios para realizar
una prueba fsica del modelo de red:

Servidor: Workstation SUN ULTRA 27

Hypervisor: Proxmox VE con XEN, KVM y OpenVZ

(2) Servidor Virtualde Clientes Ligeros: Debian con TCOS

(4) Clientes ligeros: Encore Thin Client ENTC-1000

Switch 10/100 Mbps

El proyecto est preparado para dar servicio en intranet, para poder proveer este servicio por
Internet habra que realizar una investigacin respecto al booteo por red a travs de HTTP y hacer
las adecuaciones pertinentes al modelo. Una vez realizados estos pasos se podra orientar el proyecto
hacia un modelo de servicio compatible con el Cloud Computing.
Hablando especficamente de las universidades y retomando el ttulo de este proyecto, se puede
crear en las universidades un laboratorio de prcticas en donde se utilice software libre y dentro de

87

Captulo 6: Consideraciones, conclusiones y trabajos futuros

ste implementar un modelo como el propuesto en ste documento para pulir el modelo de red
mientras los alumnos utilizan el laboratorio. Un laboratorio como estos puede servir para desarrollar
las habilidades de los alumnos no solo en programacin, tambin en redes, en seguridad,
administracin, diseo de interfaces, etc. y descubrir su perfil de entre todos los roles que intervienen
en la Ingeniera en Sistemas.

88

Captulo 6: Consideraciones, conclusiones y trabajos futuros

Referencias
[1]

Alvarenga, S. (07 de 09 de 2009). JeuAzarru.com. Recuperado el 11 de 2011, de

http://www.jeuazarru.com/docs/Thin_clients.pdf

[2]

Aroche, S. F. (s.f.). Maestros del web. Recuperado el 8 de abril de 2011, de

http://www.maestrosdelweb.com/editorial/cloud-computing-nueva-era-de-desarrollo/

[3]

Bitzipper. (2008 de 04 de 2008). Bitzipper.com. Recuperado el 12 de 10 de 2011, de

http://www.bitzipper.com/es/aes-encryption.html

[4]

Cloudcomputingla. (10 de 08 de 2010). Cloudcomputingla.com/. Recuperado el 10 de 02 de

2011, de http://www.cloudcomputingla.com/

[5]

Cristina. (07 de 11 de 2009). Travesuras.wordpress.com. Recuperado el 19 de 10 de 2011, de

http://travesuras.wordpress.com/2009/11/07/20091107-1/

[6]

desarrolloweb.com.

(10

de

02

de

2011).

Recuperado

el

10

de

2011,

de

http://www.desarrolloweb.com/de_interes/ranking-sistemas-operativos-enero-2011-4783.html

[7]

Fernandez, M. (18 de 07 de 2009). El Blog de Marcelo! Recuperado el 10 de 2011, de

http://blog.marcelofernandez.info

[8]

Fortuna, J. (26 de 09 de 2011). juanfortuna.blogspot.com. Recuperado el 15 de 12 de 2012, de

http://juanfortuna.blogspot.com/p/ubuntu-con-encriptacion-de-disco-duro.html

[9]

Garca, T. (19 de 09 de 2008). Neoteo.com. Recuperado el 14 de 11 de 2011, de

http://www.neoteo.com/opendns-nunca-mas-un-error-de-dns-5690

89

Captulo 6: Consideraciones, conclusiones y trabajos futuros

[10]

Gutierrez, M. A. (08 de Julio de 2009). marcomancilla.com.ar. Recuperado el 12 de 2011, de

http://www.slideshare.net/mrsuperstar/licencias-de-software-1550985

[11]

JNechuz. (28 de 03 de 2008). Taringa.net. Recuperado el 20 de 12 de 2012, de

http://www.taringa.net/posts/linux/10574959/Fail2Ban---Proteger-nuestro-server--de-peluchin.html

[12]

Juanetebitel. (19 de 09 de 2010). Ubuntu-guia.com. Recuperado el 17 de 10 de 2011, de

http://www.ubuntu-guia.com/2010/08/instalar-conky-colors-ubuntu.html

[13]

Junta de castilla y Len. (2010). Observatorio Regional de la Sociedad de la Informacin.

Recuperado

el

03

de

11

de

2011,

de

La

tecnologa

como

servicio:

http://issuu.com/orsicyl/docs/cloud_computing?mode=a_p

[14]

Keys, 3.-I. I. (06 de 05 de 2011). 3-ik.com.ar. Recuperado el 8 de 12 de 2011, de

http://www.3-ik.com.ar/blog/tag/herramientas-de-monitoreo-opensource/

[15]

Kondo, P. G. (13 de 08 de 2010). Youtube. Recuperado el 08 de 2011, de

http://www.youtube.com/watch?v=dvmN3dvMnjY

[16]

Martinez, R. (1998). El rincn de Linux. Recuperado el 10 de abril de 2011, de El rincn de

Linux para hispanohablantes: http://www.linux-es.org/sobre_linux

[17]

Naranjo, M. F. (s.f.). Clusterizacin de Servidor de Terminales con TCOS.

[18]

Nerion.

(2012).

El

blog

de

Virtualizamos.

Recuperado

el

02

de

2012,

de

http://blog.virtualizamos.es/2011/09/21/%C2%BFque-tecnologia-de-hypervisor-de-virtualizacionelegir/

90

Captulo 6: Consideraciones, conclusiones y trabajos futuros

[19]

Networks, F. d. (09 de 05 de 2010). Rie.d. Recuperado el 09 de 11 de 2011, de

http://www.salixnetworks.com/filtrado_web.html

[20]

de

Octavio Islas, F. G. (19 de 03 de 2012). Mxico: De Los Amigos de Vicente Fox a Los amigos
Microsoft.

Recuperado

el

03

de

2012,

de

Radio

Informaremos:

http://radioinformaremosmexico.wordpress.com/2012/03/25/mexico-de-los-amigos-de-vicente-foxa-los-amigos-de-microsoft/

[21]

Osier-Mixon, J. M. (02 de septiembre de 2009). IBM. Recuperado el 08 de abril de 2011, de

developer works: http://www.ibm.com/developerworks/ssa/library/l-thin-client-cloud/index.html

[22]

RedMallorca Lab. (s.f.). Recuperado el 11 de 2011, de Las noticias mas interesantes de la red:

http://lab.redmallorca.com/distribucion-completa-para-virtualizacion-free-proxmox-ve-kvm-nivmware-esxi-ni-xenserver/

[23]

Remesal, A. (20 de 04 de 2011). Alvaroremesal.net. Recuperado el 28 de 11 de 2011, de

http://www.alvaroremesal.net/blog-alvaroremesal/monitorizando-equipos-con-munin

[24]

Ruiz, A. M. (2003). mauricio.tic.udc.es. Recuperado el 12 de 10 de 2011, de

http://webcache.googleusercontent.com/search?q=cache:xd3DCAbzop8J:mauricio.tic.udc.es/trabajo
s/seguridad/PGP/2003/pgpdoc.doc+pgpdoc.doc&hl=es&gl=mx

[25]

Servidordebian. (07 de 02 de 2011). servidordebian.wikidot.com. Recuperado el 21 de 11 de

2011, de http://servidordebian.wikidot.com/squeeze-es:security-bruteforceattack-fail2ban

[26]

Significadode.info. (16 de 05 de 2011). Significadode.info. Recuperado el 09 de 01 de 2012, de

91

Captulo 6: Consideraciones, conclusiones y trabajos futuros

http://www.significadode.info/palabras-de-internet/ddos/

[27]

Solis, M. N. (13 de 05 de 2010). Semarnat.gob.mx. Recuperado el 16 de 01 de 2012, de

http://www.semarnat.gob.mx/eventos/anteriores/experienciasresiduos/Documents/ProgramadeRec
olecci%C3%B3nyReciclado.pdf

[28]

Trebol-a. (27 de 10 de 2007). Trebol-a.com. Recuperado el 03 de 11 de 2011, de

http://www.trebol-a.com/2007/10/27/detener-ataques-con-fail2ban/

[29]

Velasco, E. (14 de 03 de 2012). Proveer Linux los servicios tecnolgicos al gobierno federal.

La Jornada , pg. 23.

[30]

wgarcia. (24 de 12 de 2010). puna.upf.edu. Recuperado el 10 de 12 de 2011, de

http://puna.upf.edu/es/node/62

[31]

windoctor. (27 de 12 de 2007). Mundobyte. Recuperado el 20 de 12 de 2011, de

http://mundobyte.wordpress.com/2007/12/27/cuidado-%C2%BFbombas-fork-%C2%BFque-son/

[32]

ZroBot. (05 de 04 de 2007). Wikipedia.es. Recuperado el 06 de 12 de 2011, de

http://es.wikipedia.org/wiki/Bomba_fork

92

LABORATORIO DE PRCTICAS, MODELADO EN TECNOLOGAS LIBRES

Anexos

Anexo A: Escenario del software libre en ambiente profesional


Actualmente, el uso de Linux en el hogar es un poco ms del 1%

[6],

es una cifra que carece de

impacto considerando el mercado que abarcan los otros sistemas operativos.

Figura 32: Cuota de mercado de Sistemas operativos de escritorio


Fuente: http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8&qpcustomd=0

Si se observan estos datos desde el punto de vista del desarrollador la cifra cambia, siendo un poco
ms del 50% de usuarios de Linux en este caso.

Figura 33: Cuota de mercado de sistemas operativos desde el punto de vista del desarrollador
Fuente: http://www.muylinux.com/wp-content/uploads/2011/08/MuyLinux-julio2011.jpg

Con esto se observa que en un ambiente orientado al desarrollo en sistemas, el nmero de usuarios
es una cifra importante, en la actualidad ya no es un plus saber utilizar herramientas de software
libre, si una persona dedicada a la tecnologa quiere ser competitiva, DEBE saber utilizar software
libre.

Anexo B: Licencias de software


Por qu debe importar [10]:

Ayuda a seleccionar herramientas de trabajo

Influye en el costo final del trabajo

Posibilita otorgar o quitar permisos sobre el trabajo final

Cdigo

Licencia

Clausulas

Sin licencia

Abierto

Ninguna

Si no se especifica ninguna licencia, el cdigo


tiene derechos de copia por defecto. La gente
puede leer el cdigo, pero no tienen derecho a
utilizarlo. Para utilizar el cdigo, debes
contactar con el autor directamente y pedir su
permiso.

Dominio
pblico

Abierto

Permisiva

Si tu cdigo est en el dominio pblico,


cualquiera puede utilizarlo para cualquier
propsito. El cdigo no est en el dominio
pblico por defecto; tienes que indicarlo
explcitamente si quieres que as sea. De otra
forma, el autor debe llevar bastante tiempo
muerto para que su trabajo pase a ser de
dominio pblico.

Licencia GPL

Abierto

Copyleft

12

La arquetpica licencia de software libre con


barbas y sandalias. Tu cdigo no podr ser
utilizado en ningn programa propietario,
nunca! Toma esa, capitalismo!

Licencia LGPL

Abierto

En
su 16
mayor
parte
copyleft

GPL
con
una
vlvula
de
presin
inteligentemente construida. Tu software libre
puede enlazarse de forma binaria a programas
propietarios bajo ciertas condiciones muy
especficas.

Licencia
MIT/X11

Abierto

Permisiva

Corta y dulce.
Incluye una clusula de
responsabilidad genrica.

Licencia BSD

Abierto

Permisiva

Corta y dulce.

descargo

de

Incluye una clusula de descargo de


responsabilidad nombrando explcitamente a la
organizacin.
Licencia
Apache

Abierto

Permisiva

Se requiere a las obras derivadas que


notifiquen de cualquier cdigo licenciado o
propietario en una localizacin comn.

Abierto

Permisiva

Amigable con los negocios. Permite que las


obras derivadas elijan su propia licencia para
sus contribuciones.

Abierto

Copyleft
dbil

13

Permite una mezcla libre con software


propietario.

Licencia
Abierto
Permisiva de
MS

Permisiva

Parecida a las licencias MIT y BSD. No est


aceptada formalmente por la OSI, y tambin se
ofrece en una variante slo-Windows
llamada LPL.

Licencia
Comunitaria
de MS

Copyleft

Parecida a la licencia GPL. Requiere que todo el


cdigo con el que se contribuya se devuelva a
la comunidad. No est aceptada formalmente
por la OSI, y tambin se ofrece en una versin
slo-Windows llamada LCL.

Puedes revisar el cdigo, o hacer copias de l,


pero no puedes utilizarlo o cambiarlo de
ninguna forma. Ofrece una ventana a cdigo
que anteriormente era completamente
proprietario y secreto.

Licencia
Pblica
Eclipse

de

Licencia
Pblica
Mozilla

de

Abierto

Licencia de Proprietario Slo


Referencia de
lectura
MS

Tabla 10: Tipos de Licencias de Software


Fuente: http://mundogeek.net/archivos/2007/04/09/licencias-de-software/

Anexo C: Tipos de red en ambientes virtuales


Comparacin de tipos de red
Comparison of the network types
NAT
(Network Address
Host-only
Translation)
The VM hides behind
The VM appears as the IP address of the
The VM can only access
if it was
VMware host. Other
the VMware host and
Description
a physical host on VMs in the same NAT other VMs in the same
the network.
network can access it
host-only network
directly.
The VM requires it's
own IP address from
The VM can have any private IP configured on the
the network it is
IP address
VMware host.
supposed to belong
to.
Not accessible from
Hides behind NAT, so
external network unless
Accessibility Same as a physical port forwarding on the routed via another VM
VMware host required if with access to both
from network host
external access required external network and the
same host-only network
VMs intended for
An always-on
VMs intended for
testing with no need to
server hosted on
testing, or cases when
access the network, or
VMware, or a
the amount of IP
Use cases
VMs which will be
virtual router or
addresses in the external
protected by a firewall
firewall
network is limited.
in another VM.
Known to have
NAT is really a hostproblems with some
only network with a
wireless chipsets
default gateway (on the
Other
especially with
VMware host) that
Linux, also with
routes and NATs.
Windows Vista.
Type

Bridged

Tabla 11: Tipos de red


Fuente: http://vmfaq.com/entry/34/

ANEXO D: Recomendaciones para reglamento, seguridad fsica


y contra incendios, seguridad en contraseas
Reglamento
Queda prohibido a todos los usuarios:

Introducir alimentos y/o bebidas y fumar dentro del rea de servicio.

Meter o consumir bebidas alcohlicas, estupefacientes o cualquier tipo de droga

Utilizar grabadoras, radios o equipos de sonido y audfonos.

Mover, desconectar y/o conectar equipo de cmputo sin autorizacin.

Modificar o intentar modificar la configuracin del servidor o equipos.

Alterar software instalado en los equipos.

Alterar o daar las etiquetas de identificacin del equipo de cmputo.

Crear directorios y copiar archivos fuera de las carpetas personales de cada usuario.

Utilizar el equipo de computo como maquinas de juegos; esto incluye utilizar software de juegos
o acceder a servicios de cualquier tipo que impliquen el uso de juegos interactivos no
acadmicos.

Utilizar el equipo para desarrollar programas o proyectos ajenos al inters acadmico de la


Universidad.

Extraer manuales y/o libros.

Extraer materiales de consumo del equipo de cmputo.

Copiar software cuya licencia de uso lo prohba.

Enviar mensajes a otros usuarios de manera annima.

Abuso y/o mal uso del equipo.

Acceder a pginas con contenido no apto a la moral pblica de los usuarios del centro de
cmputo.

Acceder a programas de Chat o mensajera o instalarlos en las maquinas.

Cualquier actitud agresiva o de mala educacin.

Se recomienda manejar mnimo 2 perfiles para el laboratorio:

Administrador (profesor)

Cliente (alumno)

De preferencia manejar 3 perfiles:

Administrador (especialista)

Encargado (profesor)

Cliente (alumno)

Seguridad fsica y contra incendios de los equipos.


La seguridad de contra incendios es un aspecto de suma importancia en un centro de cmputo. Las
siguientes recomendaciones pueden prolongar la vida de los equipos:

Ubicar el equipo en un lugar donde no exista mucho movimiento de personal o de equipo de


cmputo.

No traslade la computadora sin la autorizacin del asesor del Laboratorio de Computo.

Instale la computadora sobre escritorios o muebles estables o especialmente diseados para ello.

Ubique el servidor lejos de la luz del sol y de ventanas abiertas.

La energa elctrica debe ser regulada a 110 voltios y con polo a tierra. Asesrese debidamente
para garantizar una buena toma elctrica.

El equipo de la red debe estar lejos de la luz del sol y de ventanas abiertas.

No conecte otros aparatos (Radios, Computadoras porttiles, calculadoras, celulares, etc.) en la


misma toma de la computadora, ubique el equipo en un lugar donde no exista mucho
movimiento de personal.

No traslade la computadora sin la autorizacin del asesor del Centro de Cmputo.

Instale la computadora sobre escritorios o muebles estables o especialmente diseados para ello.

Debe haber dos enchufes nicamente por cada computadora.

Cada usuario, al momento de terminar las labores diarias, deber apagar su equipo asignado.

El encargado del laboratorio de cmputo deber apagar los dispositivos que se hayan ocupado
aparte de las computadoras (Impresoras, Escner, etc).

Evite colocar encima o cerca de la computadora ganchos, clips, bebidas y comida que se pueden
caer accidentalmente dentro del equipo.

No fume dentro del laboratorio, ni cerca del equipo, el alquitrn se adhiere a las piezas y circuitos
internos del equipo.

Mantenga libre de polvo las partes externas de la computadora y de las impresoras. Utilice un
pao suave y seco. Jams use agua y jabn.

Utilice en la impresora el ancho del papel adecuado.

Est prohibido destapar y tratar de arreglar los equipos por cuenta propia. En todos los casos el
encargado del Laboratorio de Cmputo es el encargado de esta operacin.

No preste los equipos o asegrese que la persona que lo utilizar conoce su correcta operacin.

Seguridad en contraseas
Recomendaciones para tener contraseas ms seguras para el Laboratorio de cmputo:

Exigir el cambio de las claves con frecuencia.

No permitir el uso de palabras comunes, o que estn en un diccionario comn.

Exigir un mnimo de caracteres para la clave (10 o ms).

Exigir la combinacin de letras, nmeros y smbolos en las claves (sin que se puedan repetir como
mximo dos veces en el caso de los nmeros y smbolos).

Nunca almacenar las claves en texto plano, o con algoritmos dbiles de criptografa.

No contiene el nombre de usuario, el nombre real o el nombre de la empresa.

No almacenar slo el hash de la clave, usar un mecanismo que genere algo de entropa en la clave
almacenada (salt, o algo similar).

Abrevie una frase que recuerde fcilmente. Puede estar formada por nmeros, signos o palabras
que puede cambiar por nmeros o signos.

No escriba nunca su contrasea ni enve nunca su contrasea en un mensaje de correo


electrnico

No revele nunca su contrasea en una conversacin de mensajes instantneos ni la comparta con


nadie.

Anexo E: Herramientas de Software Libre


En el siguiente apartado se muestra un listado de herramientas de software libre que ha sido
seleccionado para su uso en un laboratorio de cmputo universitario.
Este listado de aplicaciones es solo una referencia de las posibles aplicaciones que se pueden utilizar
en un entorno como es el modelo de red al que este anexo hace referencia, es una pequea
exploracin de la vasta cantidad de alternativas que se ofrecen dentro del software libre para cubrir
las diferentes necesidades que surjan a los distintos tipos de probables usuarios del sistema.
Esta lista sugiere aplicaciones que se pueden utilizar en un entorno de desarrollo de sistemas a nivel
universitario, el lector es libre de modificar esta lista y de agregar el software que se adapte a sus
necesidades.
Lo que proponemos con este catlogo es utilizar herramientas universales, utilizar lenguajes de
programacin multiplataforma como C, C++, JAVA permite al alumno una versatilidad que no
obtendra si se especializara en una sola plataforma. Los lenguajes que sobrevivirn son aquellos que
proporcionen soluciones multiplataforma, lenguajes hbridos, que incorporen distintos paradigmas,
escalables y concurrentes.
Por ltimo se le recuerda al lector que la manera de instalar software en este sistema se hace con el
comando "sudo apt-get install" seguido del nombre del programa instalar.

Listado de software

Aplicacin
Eclipse
Netbeans
Kdevelop
Anjuta
Code::Blocks
MonoDevelop
Protege
Hugs 98
Pselnt
gnat gps
swi prolog
python
pythonG
Gambas
Bluefish
Kompozer
Alleyoop
Data
Display
Debugger
Doxygen Wizard
Meld
Nemiver
eSvn

Descripcin
Entorno de desarrollo integrado
Entorno de desarrollo integrado para java
Entorno de desarrollo integrado para C/C++
Entorno de desarrollo integrado para C/C++
Entorno de desarrollo integrado para C/C++
Entorno de desarrollo integrado para .NET
Editor de ontologas y framework para bases de
conocimiento
Interprete para el lenguaje de programacin funcional
Haskell
Aprendizaje de logica de programacin
Entorno de programacin para ADA
Implementacin del lenguaje de programacin Prolog
Lenguaje de scripting de propsito general
Entorno de programacin para una versin extendida de
Python
Entorno de desarrollo integrado parecido a Visual Basic
Entorno de edicin HTML
Entorno de edicin HTML
Entorno grafico para Valgrind
Interfaz grafica para GDB y otros debuggers de UNIX
Generador de documentacin con soporte multilenguaje
Herramienta para comparar archivos y directorios
Interfaz para depurador GDB
Entorno grafico para Subversion
Tabla 12: Listado de Software

De la tabla anterior se destacan las herramientas Eclipse y Netbeans las cuales funcionan en sistemas
operativos Windows, Linux y Mac OS X. Estos dos IDE han integrado otros lenguajes de programacin,
no solo JAVA, adems Eclipse fue un proyecto iniciado por IBM, tiene la calidad suficiente que puede
aportar una gran empresa. Estos IDE, pudindose ejecutar en cualquier plataforma permiten la
portabilidad de las aplicaciones desarrolladas.

Anexo F: How to: Instalacin de Proxmox


Para instalar Proxmox Virtual Environment se deben seguir los pasos siguientes:

Bootear el servidor con el CD de proxmox dentro

Configurar el pas y el teclado

Figura 34: Inicio de Proxmox

Figura 35: Configuracin de pas y teclado de Proxmox

Escribir la contrasea de root y el correo del administrador.

Figura 36: Contrasea y correo de administrador

Ingresar los datos correspondientes a la configuracin de la red.

Figura 37: Datos de la red

Esperar a que termine la instalacin y reiniciar el servidor.

Desde cualquier otra computadora conectada a la red se debe ingresar a la direccin IP del
servidor a travs de un explorador.

Figura 38: Ingreso de la IP del servidor

En la pgina que mostrar en pantalla se debe ingresar el usuario root y su correspondiente


contrasea.

Figura 39: Login de Proxmox

Si todo ha salido bien, se mostrar en pantalla una tabla con datos acerca del servidor

Figura 40: Datos del servidor

Anexo G: How to: Instalacin de LTSP en Ubuntu 11.04


sta configuracin de LTSP se realizar con dos interfaces de red, en la cual una interfaz (eth0) estar
conectada a internet y la segunda interfaz (eth1) estar conectada a la red interna en donde estarn
conectados los clientes. Para instalar LTSP debe seguirse el siguiente procedimiento.

Dentro de Ubuntu 11.10 ejecutar las siguientes lneas en terminal.


sudo apt-get update

sudo apt-get install ltsp-server-standalone openssh-server

Se configuran las interfaces de red, como ejemplo se configura eth0 por DHCP y eth1 con IP
192.168.0.1 MASK 255.255.255.0.

Figura 41: Configuracin de red eth1

Para configurar la segunda interfaz como DHCP se debe editar un siguiente archivo de la siguiente
manera:

sudo nano /etc/default/isc-dhcp-server


Y en la lnea donde dice INTERFACES agregar entre comillas eth1

Figura 42: Vista sin modificaciones del archivo isc-dhcp-server

Ahora hay que especificar la configuracin de la red (direcciones IP y mascaras), para esto se edita
el siguiente archivo:
sudo nano /etc/ltsp/dhcpd.conf

Figura 43: Vista por default del archivo dhcpd.conf

Reiniciar servicios:
sudo /etc/init.d/networking restart

sudo /etc/init.d/isc-dhcp-server restart

sudo /etc/init.d/openbsd-inetd restart


Crear Imagen de Cliente
Los clientes conectados a un servidor LTSP obtienen el sistema operativo de una imagen generada
dentro del servidor.

Para

construir

la

imagen

sudo ltsp-build-client --arch i386

del

cliente

hay

que

ejecutar

el

siguiente

comando:

Figura 44: Fin de la creacin de la imagen del cliente

Para instalar el administrador-monitor de LTSP se debe ejecutar el siguiente comando:


sudo apt-get install thin-client-manager-gnomesudo

Figura 45: Muestra del programa Thin Client Manager funcionando

ANEXO H: Como encriptar sistema operativo


Se muestran los pasos a seguir para instalar Ubuntu 11.04 encriptando el sistema operativo usando la
versin de 64 bits ubuntu-11.04-alternate-amd64.iso (funciona en 32 y 64 bits de la misma manera
para cualquier versin de Ubuntu altarnate que pueden ser descargadas de la pgina:
http://releases.ubuntu.com/).
Se deben seguir los siguientes pasos para realizar la encripcin completa del disco duro [8]:

Seleccionar Idioma: Espaol.

En las opciones escogeremos: Instalar Ubuntu.

Escoger el pas: Mxico.

Seleccionar No en detectar la disposicin del teclado.

Seleccionar el teclado disponible, en este caso es Latino Amrica.

Elegir el keyboard layout del teclado que est disponible, en este caso es Latinoamrica.

Introducimos el nombre de la maquina: aqu ser serverubuntu.

Escoger S en configurar el reloj.

Realizaremos el Particionado manual de los discos.

Elegir el disco duro en donde se instalar el sistema operativo encriptado.

Dar S en caso de preguntar si queremos crear una nueva tabla de particiones vaca en el
dispositivo seleccionado anteriormente.

Asignar el Disco duro que muestre las palabras ESPACIO LIBRE

Figura 46: Ubicar disco duro con espacio libre

Crear una nueva particin para el /boot.

Se asigna un espacio de 250MB ya que es solo para las opciones de booteo de los sistemas
operativos.

Seleccionar Primaria y al principio del espacio disponible.

Seleccionar un punto de montaje y escoger /boot.

Y terminar de definir la particin.

Ir a Configurar los volmenes cifrados.

Figura 47: Seleccionar configuracin de volumenes cifrados

Seleccionar S para guardar los cambios a los discos duros y configurar los volmenes cifrados.

Crear el nuevo volumen cifrado.

Aqu asignar la particin que tenga ESPACIO LIBRE ya que la otra es la que ya se ha realizado de
/boot.

Figura 48: Seleccionar particin con espacio libre

Seleccionar; Se ha terminado de definir la particin, y guardar los cambios de los discos y


volumen de cifrado seguido de la opcin de Terminar.

Escribiremos la frase de contrasea (mientras ms robusta y compleja, es mejor para la


proteccin).

La repetimos y seguido escoger Configurar el Gestor de Volmenes Lgicos (LVM).

Figura 49: Seleccionar la configuracin de gestor de volmenes (LVM)

Dar S a Guardar los cambios a los discos.

Crear un grupo de volmenes.

Figura 50: Cmo crear un grupo de volmenes

Teclear un nombre a los volmenes cifrados en este caso es volmenes.

Seleccionar la particin de mayor tamao, la otra de 248 MB es la que se hizo de /boot.

Figura 51: Cmo seleccionar la particin boot

Dar que S se desea mantener la distribucin de particiones existente y configurar LVM.

Ir a Crear un volumen lgico.

Escribir el nombre del volumen cifrado que se creo, fue volmenes.

Asignar el nombre al primero volumen lgico, SWAP y asignar el tamao que sea necesario para
la rea de intercambio, dependiendo la memoria RAM que se tenga en la computadora o
mquina virtual (tampoco es necesario poner toda la memoria RAM fsica para SWAP, si se tiene
4 GB se podran poner solo 3GB).

Crear un volumen lgico de nuevo pero ahora con el nombre de raz y el tamao del 30%
aproximadamente del disco duro que tengan en los volmenes cifrados.

Establecer un volumen lgico de nuevo pero ahora con el nombre de home y el tamao restante
del disco duro que se tengan en los volmenes cifrados.

Ahora elegimos la opcin de Terminar.

Figura 52: Fin de tabla de particiones

Entonces la tabla de particiones deber quedar de la siguiente manera:

Figura 53: Muestra de particiones creadas

Ir a la seccin de home en donde se encuentra el tamao asignado, seguido de la opcin no


utilizar para especificar el tipo de particin ext4.

Optar por el punto de montaje /home y terminar de definir la particin.

Ir a la seccin de raz en donde se encuentra el tamao asignado, seguido de la opcin no utilizar


para especificar el tipo de particin ext4.

Elegit el punto de montaje / (raz) y terminar de definir la particin.

Llegar a la seccin de raz en donde se encuentra el tamao asignado, seguido de la opcin no


utilizar para especificar el tipo de particin rea de intercambio y terminar de definir la particin.

Finalizar el particionado y escribir los cambios en el disco.

Figura 54: Muestra de particiones finalizadas

Muestra todos los cambios que se han realizado en las 3 nuevas particiones, si estas se encuentran de
manera correcta seleccionar S, de lo contrario se tiene que borrar las particiones y realizar de nuevo
el procedimiento para realizar los volmenes.

Figura 55: Muestra de particiones creadas y cifradas

Esperar a que cargue la instalacin del sistema base y despus poner el nombre del usuario.

Asignar despus el nombre de usuario para la cuenta y agregar la contrasea, de nuevo ponemos
la contrasea.

Seleccionar No para cifrar la carpeta personal (/home) ya que ha sido encriptada posteriormente,
se puede seleccionar que s en caso de ser muy paranoico.

Si no tenemos que configurar un gestor de paquetes por proxy HTTP lo dejar vaco.

Esperar a que se instale el sistema y seguido a ello daremos s para cargar el GRUB.

De nuevo S para la opcin del reloj y continuar para terminar con la instalacin del sistema.

La computadora se reiniciar y antes de entrar a login de Ubuntu pedir la frase para montar la
particin encriptada.

Figura 56: Pantalla de inicio del sistema operativo para montar el cifrado

Teclear la contrasea de cifrado y mandar al login de Ubuntu, poner la contrasea del usuario con el
que se entrar y se abrir el Sistema operativo corriendo de manera normal pero con la diferencia
que esta encriptado.

Figura 57: Login de Ubuntu

Figura 58: Escritorio de Ubuntu

ANEXO I: How to: Instalar Munin


Para poder instalar y configurar el servicio de servidor Munin es necesario abrir una consola como
root (#) ir a la carpeta /Munin y ejecutar el archivo configurarmunin esto se realiza escribiendo en
consola lo siguiente [23]:
sh intstallmunin

Para desinstalar el servidor Munin se debe ejecutar el archivo desinstalarmunin esto se realiza
escribiendo en consola lo siguiente:
sh uninstallmunin
Al terminar la instalacin de Munin abriremos un explorador y escribiremos la siguiente URL:
http://localhost/munin

En caso de que muestre un mensaje de error que diga algo como:


Forbidden
You don't have permission to access /munin/ on this server

El baneo a esperar es aproximadamente 5 minutos para que se ejecute el archivo cron (5 minutos es
el tiempo por default que establece cron en la instalacin de Munin) y comience a actualizar las
grficas en la ubicacin que necesite el programa. En caso de que no muestre este error, abrir una
pgina con el logo de Munin y ah escoger las opciones de que grficas se estn usando.
Como agregar un nodo cliente

Para poder agregar un nodo cliente es necesario editar un archivo ubicado en la extensin:
/etc/munin/munin.conf
En donde muestra algo como esto:
[nombreserver.localdomain]
address 127.0.0.1
use_node_name yes
Esta informacin es del servidor para que sea auto monitoreado, para agregar a los clientes es
necesario agregar:
[nombreserver.localdomain]
address ipserver
use_node_name yes
[nombrecliente.localdomain]
address ipcliente
use_node_name yes

Se debe modificar ipcliente por la IP del cliente que se dese monitorear y el nombrecliente por el
nombre que deseemos aparezca en la raz de sus grficas.
Es opcional modificar ipserver por la IP del servidor o dejarlo como 127.0.0.1 y el nombreserver por el
nombre que deseemos aparezca en la raz las grficas del servidor.
En localdomain se escribe el nombre de la empresa, red o cualquier otro nombre.

Se pueden agregar por debajo todos los clientes que se quieran.


Eliminar grficas de Munin
Para poder eliminar las grficas de la pgina web de Munin, es necesario quitar los enlaces simblicos
ubicados en la extensin /etc/munin/plugins en donde solo es necesario borrar el acceso directo la(s)
grfica(s) que se desee(n) quitar, o tambin modificar el archivo de eliminargraficas, el archivo
contiene todas las grficas que tiene por default Munin, todas inician con el smbolo de #, es
necesario quitar el smbolo de # en los renglones que tengan la palabra sudo ejemplo de eliminar la
grfica de usuario:
# usuario
# sudo rm /etc/munin/plugins/users

El archivo debe quedar de la siguiente manera:


# usuario
sudo rm /etc/munin/plugins/users

Guardar el archivo, ahora abriremos una terminal y ejecutaremos el archivo como root (#) de la
siguiente manera:
sh deletegraph

De esta manera cuando se vuelva a ejecutar el cron no mostrar la grfica correspondiente a


usuarios.
Agregar grficas que fueron borradas

Para poder aadir las grficas de la pgina web de Munin, es necesario crear los enlaces simblicos
desde /usr/share/munin/plugins/ a /etc/munin/plugins/ en donde solo es necesario agregar el acceso
directo de la(s) grfica(s) que se desee(n) agregar, o tambin modificar el archivo de agregargraficas,
el archivo contiene todas las grficas que tiene por default Munin, todas inician con el smbolo de #,
es necesario quitar el smbolo de # en los renglones que tengan la palabra sudo ejemplo de crear el
enlace simblico de usuario:
# usuario
#sudo ln -s /usr/share/munin/plugins/users /etc/munin/plugins/users

El archivo debe quedar de la siguiente manera:

# usuario
sudo ln -s /usr/share/munin/plugins/users /etc/munin/plugins/users

Guardar el archivo, ahora abriremos una terminal y ejecutaremos el archivo como root (#) de la
siguiente manera:
sh agregargraficas

Agregar nuevas grficas


Para agregar nuevas grficas y monitorear hardware o software, se debe realizar un Shell Script
programado en Perl y al parecer nuevas versiones soportan bash y phyton tambin, los cuales
debern ser copiados en la extensin /usr/share/munin/plugins/users y despus crear su enlace

simblico de /usr/share/munin/plugins/nombrescript a /etc/munin/plugins/nombrescript solo resta


esperar a que cron se ejecute para que aparezca la nueva grfica.
Escribiremos desde consola el comando
munin-node-configure --suggest

Se mostrar todos las grficas estn funcionando y cuales an no lo hacen, dar informacin de que
plugins necesitan parmetros o pueden ser ocupados en la computadora y para agregar alguno es
necesario solo crear el enlace simblico. En la siguiente pgina existen varios plugins listos para
comenzar a monitorear:
http://exchange.munin-monitoring.org/
Si algunos de los plugins no se muestran se debe instalar la siguiente librera escribiendo en consola:

sudo apt-get install libcache-cache-perl

Cron
Permite ejecutar otros programas o scripts en un lapso de tiempo y una periodicidad especificada por
el usuario. Su comportamiento est regulado por su archivo de configuracin, que se llama crontab.
Cada usuario del sistema posee un archivo crontab personalizado y slo el usuario root puede
modificar el archivo crontab de otro usuario.
Para hacer que Munin se actualice por un tiempo especfico es necesario ir a su archivo cron ubicado
para modificarlo en la extensin:
/etc/con.d/munin

El archivo tiene por default que el programa se actualice cada 5 minutos, es posible modificarlo de la
siguiente manera:

Un asterisco (*) para indicar todos los posibles valores.

Un valor fijo para indicar un minuto, hora, da o mes.

Un rango de valores, dos nmeros separados por guiones. Un rango puede terminar en
/numero para indicar el incremento.

Una lista de valores separados por comas.

Un valor */numero para indicar todos los valores con incremento de "nmero".

Ejecutarlo de lunes a viernes a la hora en punto


Minutos (0-59)
|

Horas (0-23)

Da del mes (1-31)

Mes (1-12)

Da de la semana (0-6 donde 0=Domingo)

Comandos

1-5

/etc/cron.d/munin

Ejecutarlo a las 12 de la noche cada da


0 0 * * * /etc/cron.d/munin
Ejecutarlo a las 12:15 de la noche cada da
15 0 * * * /etc/cron.d/munin

ANEXO J: How to: Instalar Conky


Primero se agrega el repositorio para tener la versin ms reciente de Conky [30]:

sudo add-apt-repository ppa:norsetto/ppa


Actualizar el apt-get:
sudo apt-get update

Para poder instalar y configurar el servicio de Conky es necesario abrir una consola y ejecutar el
siguiente comando:
sudo apt-get install conky-all
Copiar el archivo de configuracin de Conky y le dejaremos otro valor para tener el original como
respaldo:
mv ~/.conkyrc ~/.conkyrcOLD

Se debe crear el archivo "~/.conkyrc" y editarlo con los valores que deseemos que sean
monitorizados:
gksudo gedit ~/.conkyrc

Se muestra el cdigo de un ejemplo para Conky usado para el proyecto:


use_xft yes
xftfont DroidSans:size=8.75
xftalpha 0.1
text_buffer_size 2048
####
## Force UTF8? Requires XFT

## Displays degree symbol, instead of , etc.


#
override_utf8_locale yes
####
## Daemonize Conky, aka "fork to background".
#
background yes
####
# Update interval in seconds.
#
update_interval 1.5
####
## This is the number of times Conky will update before quitting.
## Set to zero to run forever.
#
total_run_times 0
####
## Create own window instead of using desktop (required in nautilus)?
#
own_window yes
own_window_type override
own_window_transparent yes
####
## Force images to redraw when they change.
#
imlib_cache_size 0
####
## Use double buffering? Reduces flicker.
#
double_buffer yes
####
## Draw shades?
#
draw_shades no
####
## Draw outlines?
#
draw_outline no
####
## Draw borders around text?
#
draw_borders no
####
## Draw borders around graphs?
#

draw_graph_borders no
####
## Print text to stdout?
## Print text in console?
#
out_to_ncurses no
out_to_console no
####
## Text alignment.
#
alignment top_right
####
## Minimum size of text area.
#
minimum_size 240 0
####
## Gap between text and screen borders.
#
gap_x 8
gap_y 33
####
## Shorten MiB/GiB to M/G in stats.
#
short_units yes
####
## Pad % symbol spacing after numbers.
#
pad_percents 0
####
## Pad spacing between text and borders.
#
border_inner_margin 4
####
## Limit the length of names in "Top Processes".
#
top_name_width 10
####
## Subtract file system -/+buffers/cache from used memory?
## Set to yes, to produce meaningful physical memory stats.
#
no_buffers yes
####
## Set to yes, if you want all text to be in UPPERCASE.
#
uppercase no

####
## Number of cpu samples to average.
## Set to 1 to disable averaging.
#
cpu_avg_samples 2
####
## Number of net samples to average.
## Set to 1 to disable averaging.
#
net_avg_samples 2
####
## Add spaces to keep things from moving around?
## Only affects certain objects.
#
use_spacer right
####
## My colors (suit yourself).
color1 Ivory
color2 Ivory2
color6 Gray
color8 DarkSlateGray
#
## Installed fonts (required).
## OpenLogos (Icoma)
## StyleBats (Vinterstille)
## Ubuntu Title Bold (Paulo Silva)
TEXT
##################################
## DATOS ##
##################################
${voffset -33}${font OpenLogos:size=103}${color2}${font}${voffset -76}${goto 178}${font
UbuntuTitleBold:size=19.6}${color #cb2033}${pre_exec lsb_release -r -s}${font}
${font DroidSans:bold:size=9.25}${color #cb2033}${exec whoami} ${font}${color8}${voffset 2}${hr 2}${font}
##################################
## SISTEMA ##
##################################
${voffset
7}${font
DroidSans:bold:size=8}${color
#cb2033}SISTEMA${offset
8}${color8}${voffset -2}${hr 2}${font}
${voffset 4}${font OpenLogos:size=8.3}${color2}${voffset -4}${font StyleBats:size=8.3}${color
#828282}${offset
5}${sysname}${offset
5}${kernel}${alignr}${font
StyleBats:size=8.3P5}${machine}${font}
${voffset 2}${font StyleBats:size=8.3}${color2}${voffset -1}${font StyleBats:size=8.3}${color
#828282}${offset 5}Velocidad${offset 3}Del${offset 3}Procesador${offset 3}${alignr}${font
StyleBats:size=8.3}${freq_g cpu0}${offset 1}GHz${font}

${voffset 2}${font StyleBats:size=8.3}${color2}${voffset -1}${font StyleBats:size=8.3}${color


#828282}${offset
5}Tiempo
del
${offset
3}Sistema
Encendido${alignr}${font
StyleBats:size=8.3}${uptime_short}${font}
${voffset 2}${font StyleBats:size=8.3}${color2}${voffset -1}${font StyleBats:size=8.3}${color
#828282}${offset
5}Sistema
de${offset
3}Archivos${alignr}${font
StyleBats:size=8.3}${fs_type}${font}
${voffset 2}${font StyleBats:size=8.3}${color2}${voffset -1}${font StyleBats:size=8.3}${color
#828282}${offset 5}Actualizaciones del Sistema ${alignr}${execi 3600 aptitude search "~U" |
wc -l | tail} Paquetes
##################################
## PROCESADOR ##
##################################
${font DroidSans:bold:size=8}${color #cb2033}PROCESADOR${offset 8}${color8}${voffset 2}${hr 2}${font}
${voffset 4}${font StyleBats:size=8.3}${color2}${voffset -2}${font StyleBats:size=8.3}${color
#828282}${offset 2}CPU:${offset 5}${font StyleBats:size=8.3}${cpu cpu1}%
${color #1d89ca}$cpubar
##################################
## MEMORIA ##
##################################
${font DroidSans:bold:size=8}${color #cb2033}MEMORIA${offset 8}${color8}${voffset -2}${hr
2}${font}
${voffset 4}${font StyleBats:size=8.3}${color2}${voffset -2}${font StyleBats:size=8.3}${color
#828282}${offset 1}RAM${goto 97}${font StyleBats:size=8.3}${mem}${goto 133}/${offset
1}${memmax}${alignr}${memperc}%${font}
${color #1d89ca}${membar 6}
##################################
## HDD ##
##################################
${font DroidSans:bold:size=8}${color #5abb47}HDD${offset 8}${color8}${voffset -2}${hr
2}${font}
${voffset
5}${font
StyleBats:size=9.9}${color
#1d89ca}${voffset
-2}${font
StyleBats:size=8.3}${color
#828282}${offset
4}ROOT${goto
95}${font
StyleBats:size=8.3}${fs_used /}${goto 133}/${offset 5}${fs_size /}${alignr}${fs_free_perc
/}%${font}
${color #1d89ca}${fs_bar 8 /}
${voffset
5}${font
StyleBats:size=9.9}${color
#1d89ca}${voffset
-2}${font
StyleBats:size=8.3}${color
#828282}${offset
4}HOME${goto
95}${font
StyleBats:size=8.3}${fs_used
/home}${goto
133}/${offset
5}${fs_size
/home}${alignr}${fs_free_perc /home}%${font}
${color #1d89ca}${fs_bar 8 /home}
${voffset
5}${font
StyleBats:size=9.9}${color
#1d89ca}${voffset
-2}${font
StyleBats:size=8.3}${color
#828282}${offset
4}SWAP${goto
95}${font
StyleBats:size=8.3}${swap}${goto 133}/${offset 5}${swapmax}${alignr}${swapperc}%${font}
${color #1d89ca}${swapbar 8}

#####################
# PROCESOS PESADOS ##
#####################
${font
DroidSans:bold:size=8}${color
#5abb47}PROCESOS
PESADOS${offset
8}${color8}${voffset -2}${hr 2}${font}
${voffset 4}${font StyleBats:size=8.3}${color1}${voffset -3}${font StyleBats:size=8.3}${color
#828282}${offset 5}${top_mem name 1}${goto 120}${font StyleBats:size=8.3}${top_mem
mem_res 1}${alignr}${top_mem mem 1}%${font}
${voffset 2}${font StyleBats:size=8.3}${color1}${voffset -3}${font StyleBats:size=8.3}${color
#828282}${offset 5}${top_mem name 2}${goto 120}${font StyleBats:size=8.3}${top_mem
mem_res 2}${alignr}${top_mem mem 2}%${font}
${voffset 2}${font StyleBats:size=8.3}${color1}${voffset -3}${font StyleBats:size=8.3}${color
#828282}${offset 5}${top_mem name 3}${goto 120}${font StyleBats:size=8.3}${top_mem
mem_res 3}${alignr}${top_mem mem 3}%${font}
${voffset
2}${if_running
rhythmbox}${voffset
-16}${else}${font
StyleBats:size=8.3}${color1}${voffset -3}${font StyleBats:size=8.3}${color #828282}${offset
5}${top_mem name 4}${goto 120}${font StyleBats:size=8.3}${top_mem mem_res
4}${alignr}${top_mem mem 4}%${font}
${voffset 2}${font StyleBats:size=8.3}${color1}${voffset -3}${font StyleBats:size=8.3}${color
#828282}${offset 5}${top_mem name 5}${goto 120}${font StyleBats:size=8.3}${top_mem
mem_res 5}${alignr}${top_mem mem 5}%${font}
${voffset 2}${font StyleBats:size=8.3}${color1}${voffset -3}${font StyleBats:size=8.3}${color
#828282}${offset 5}${top_mem name 6}${goto 120}${font StyleBats:size=8.3}${top_mem
mem_res 6}${alignr}${top_mem mem 6}%${font}${endif}
##################
## RED ##
##################
${font DroidSans:bold:size=8}${color #5abb47}RED${offset 8}${color8}${voffset -2}${hr
2}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}eth0${offset 5}IP${alignr}${font StyleBats:size=8.3}${addr eth0}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}eth1${offset 5}IP${alignr}${font StyleBats:size=8.3}${addr eth1}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}IP${offset 7}Pblica${alignr}${font StyleBats:size=8.3}${texeci 1800 wget -q -O checkip.dyndns.org | sed -e s/[^[:digit:]\|.]//g}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}Velocidad de Descarga${alignr}${font StyleBats:size=8.3}${downspeed eth0}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}Velocidad de Subida${alignr}${font StyleBats:size=8.3}${upspeed eth0}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}Descarga${alignr}${font StyleBats:size=8.3}${totaldown eth0}${font}
${font StyleBats:size=8.3}${color6}${font StyleBats:size=8.3}${color #828282}${offset
5}Subida${alignr}${font StyleBats:size=8.3}${totalup eth1]0}${font}

Al final de este Anexo se muestra el resultado del cdigo para este Conky
Despus crear un script para evitar conflictos entre Nautilus y Conky en el arranque del sistema

y de esta forma solucionar la superposicin de Conky en las ventanas, se puede demorar la


carga de Conky con un script:
gksudo gedit /usr/bin/inicio-conky.sh

Teclear lo siguiente:
#!/bin/bash
sleep 30 && conky;

Dar permisos para que todos puedan ejecutar el archivo:


sudo chmod a+x /usr/bin/inicio-conky.sh

Ahora Conky se ejecuta desde que inicia la computadora, esto se puede realizar de 2 maneras, de
forma grfica y desde terminal creando un archivo, se explicarn las 2 y usar la manera que ms se
facilite.
De manera grfica
Ir al men en Sistema>Preferencias>Aplicaciones al Inicio

Figura 59: Ubicacin de las aplicaciones al inicio

Ahora dar clic en el botn de Aadir y configurar de la siguiente manera:

Figura 60: Ejemplo de cmo agregar Conky a las aplicaciones de inicio

Nombre: como se llama la aplicacin que queremos iniciar.

Comando: /usr/bin/inicio-conky.sh, es el archivo que se cre.

Comentario: Es posible escribir cualquier descripcin.

Dar clic en Guardar y verificar que se registre en los programas de inicio:

Figura 61: Termino de adicin de Conky a programas de inicio

Por terminal

Agregar un archivo oculto en ~/.config/autostart/.conkystart.desktop


gksudo gedit ~/.config/autostart/.conkystart.desktop

Y agregar el siguiente contenido, basado en los archivos que se crearon anteriormente.

[Desktop Entry]
Type=Application
Exec=/usr/bin/inicio-conky.sh
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[es_ES]=conky
Name=conky
Comment[es_ES]=inicioconky
Comment=inicioconky
NOTA: Si alguna de las carpetas como ~/.config ~/.config/autostart no existen, crearlas con el
siguiente comando:
mkdir ~/.config

mkdir ~/.config/autostart

Ahora cuando se reinicie la computadora cargar Conky automticamente.

Figura 62: Conky en escritorio

ANEXO K: Ejemplo de una bomba fork


Cdigo fuente de una bomba fork programada en Batch funcional (escribir dentro de la terminal de
Windows) [32]:

%0|%0
Cdigo fuente de una bomba fork programada en UNIX C o C++ (creando un archivo en C o C++):
#include <unistd.h>
void main()
{
while(1)
fork();
}

Bomba Fork para Bash de Linux (escribindolo en consola Bash):


:(){ :|:& };:

Se explica para que se usa cada uno de los smbolos de esta Bomba Fork en la siguiente Tabla
Smbolo

Significado

Es el nombre de la funcin

()

Contienen los parmetros. Como estn vacan carece de ellos.

Abre el cuerpo de la funcin


Separador de comandos

:|:

Estas llaman una y otra vez la funcin gracias a la tubera.

&

Hace que la funcin se ejecute en el background


Separador de comandos

Cierra el cuerpo de la funcin

Fin de la instruccin

Una vez finalizada la instruccin, volvemos a llamar a la funcin


Tabla 13: Significado de los comandos de una Bomba Fork

O tambin en un archivo bash o sh (crear un archivo con extensin sh):

#!/bin/bash
$0 &
$0 &

En Perl (crear un archivo en Perl):


fork while fork

En Phyton (crear un archivo en Phyton):


import os
while True:
os.fork()

En Ruby (Crear un archivo en Ruby):


fork while fork

ANEXO L: How to: Instalar Fail2Ban


Fail2Ban se instala de la siguiente manera desde consola [11]:
sudo apt-get install fail2ban

Parar el servicio que se inicia de forma automtica despus de la instalacin:


fail2ban-client stop

Hacemos una copia del archivo de configuracin, este archivo tiene la configuracin de Fail2Ban:
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.confOLD

Descripcin de los comandos del archivo de configuracin

ignoreip: IPs del rea local que no queremos que sean baneadas.

bantime: Tiempo que el usuario que fall el login se quedara sin poder acceder al servicio
especificado en segundos.

maxretry: Nmero de intentos de login.

backend: Permite de un modo u otro la escritura de los archivos log.

destemail: Direccin de correo donde enviar las alertas.

action: Forma en que Iptables aplica sus reglas.

mail-whois-lines: Se especifica que queremos que se envi al correo en caso de intrusin.

[ssh]: Tomare ssh como ejemplo pero esta es una lnea que da igual lo que se ponga, ya que no
afecta a la configuracin.

enable: Se puede introducir true para activarlo y false para desactivarlo.

port: Nombre del servicio relacionado con el puerto.

filter: Nombre del archivo .conf ubicado en el subdirectorio /etc/fail2ban/filter.d, este va


relacionado con algn filtro ya creado.

logpath: Ruta donde se ubica el archivo log donde se almacena toda la informacin del servicio en
cuestin.

maxretry: Nmero de intentos fallidos, aqu hay que especificar un carcter diferente para cada
celda que creemos.

findtime: Si alguien prueba x intentos en este periodo de tiempo especificado en segundos se le


considera ataque.

Se da un ejemplo de una configuracin de baneo de Fail2Ban que se uso para el proyecto, este cdigo
va en el archivo /etc/fail2ban/jail.conf:
[DEFAULT]
ignoreip = 127.0.0.1
bantime = 40
maxretry = 3
backend = polling
destemail = $mail
action = iptables[name=%(__name__)s, port=%(port)s]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
[SSH]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 4
findtime = 600
[APACHE]
enabled = true
port = http
filter = apache-auth
logpath = /var/log/apache/access.log
maxretry = 4
findtime = 600
[APACHE-NOSCRIPT]

enabled = true
port = http
filter = apache-noscript
logpath = /var/log/apache/error.log
maxretry = 4
findtime = 600
[POSTFIX]
enabled = true
port = smtp
filter = postfix
logpath = /var/log/mail.log
maxretry = 5
findtime = 600
[COURIERPOP3]
enabled = true
port = pop3
filter = courierlogin
failregex = courierpop3login: LOGIN FAILED.*ip=\[.*:<HOST>\]
logpath = /var/log/mail.log
maxretry = 5
findtime = 600
[COURIERIMAP]
enabled = true
port = imap2
filter = courierlogin
failregex = imapd: LOGIN FAILED.*ip=\[.*:<HOST>\]
logpath = /var/log/mail.log
maxretry = 5
findtime = 600
[VSFTPD]
enabled = false
port = ftp
filter = vsftpd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
[PROFTPD]
enabled = true
port = ftp
filter = proftpd
logpath = /var/log/proftpd/proftpd.log
maxretry = 4
findtime = 600
[WUFTPD]
enabled = false

port = ftp
filter = wuftpd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
[SASL]
enabled = true
port = smtp
filter = sasl
failregex = warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5)
authentication failed
logpath = /var/log/mail.log
maxretry = 5
findtime = 600

Este archivo banear por 300 segundos la IP que haga 3 intentos fallidos de login, y se guardar el
registro en el /var/log/apache*/*error.log
Activar el servicio con la nueva configuracin de la siguiente manera:
fail2ban-client start
2011-08-08

22:05:20,246

fail2ban.server

INFO

Starting

Fail2ban

v0.X.X-SVN

2011-08-08 22:05:20,247 fail2ban.server : INFO Starting in daemon mode


Tambin est la posibilidad de checar los logs de Fail2Ban en general de la siguiente manera:
tail -f /var/log/fail2ban.log

La consola puede regresar un mensaje parecido a este:


2011-08-08

21:26:52,734

fail2ban.actions:

WARNING

[apache]

Ban

2011-08-08 21:31:53,129 fail2ban.actions: WARNING [apache] Unban 88.9.95.68

IP 88.9.95.68 bloqueada.

88.9.95.68

NOTA: Al arrancar puede dar unos avisos WARNING si es as es porque tenemos algn filtro sin
definir el findtime hay que definirlo, aqu un ejemplo de aviso:
WARNING 'findtime' not defined in 'ssh'. Using default value

Ahora solo queda que el servidor haga el resto y verificar el correo de forma peridica.

Glosario de trminos tcnicos


Aplicacin: Es un tipo de programa informtico diseado como herramienta para permitir a un
usuario realizar uno o diversos tipos de trabajo.
Appliance: Es una mquina virtual pre configurada la cual puede ser importada dentro del gestor de
mquinas virtuales
Argumento: Es una variable que puede ser recibida por un programa.
Background: Todos aquellos procesos o rutinas de ejecucin que se realizan en segundo plano.
Boot: Arranque, iniciar el funcionamiento de la pc. Hacer que la computadora inicie la ejecucin de
instrucciones.
CLI: Interfaz/Intrprete de Lnea de Comandos.
Cliente o terminal: Es una aplicacin informtica o una PC que accede a un servicio remoto en otra
PC, conocido como servidor, normalmente a travs de una red de telecomunicaciones.
Cliente: Computadora o programa que accede a un servicio dado por el Servidor.
Cloud Computing: Tendencia de basar las aplicaciones en servicios alojados de forma externa, en la
propia web.
Consola: Interfaz de lnea de texto
Core utils: paquete de software con herramientas bsicas para la administracin de sistemas UNIX.

Cracker cracking: Es la ciencia que estudia la seguridad de sistemas de proteccin tanto de software
como de hardware con el objetivo de violarlos para aprender de ellos y obtener un beneficio personal
sin fines de lucro.
Daemon: Proceso que se ejecuta en segundo plano sin la intervencin ni control por parte del
usuario.
DHCP: Es un protocolo de red que permite a los clientes de una red IP obtener sus parmetros de
configuracin automticamente.
Direccin IP: Es una etiqueta numrica que identifica, de manera lgica y jerrquica, a un interfaz
(elemento de comunicacin/conexin) de un dispositivo (habitualmente una computadora) dentro de
una red que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red del protocolo
TCP/IP.
Disponibilidad Informtica: La informacin debe estar en el momento que el usuario requiera de ella.
Distribucin: Es el ncleo de Linux ms software destinado a satisfacer las necesidades de un grupo
de usuarios.
DNS: Es un sistema de nomenclatura jerrquica para computadoras, servicios o cualquier recurso
conectado a Internet o a una red privada.
Entorno de escritorio: Conjunto de programas para ofrecer al usuario una interaccin agradable con
el sistema.
Gateway: Es un dispositivo, con frecuencia una computadora, que permite interconectar redes con
protocolos y arquitecturas diferentes a todos los niveles de comunicacin por medio de una IP.

Gnome: Entorno de escritorio para sistemas operativos UNIX.


GPL: General Public License, licencia que protege la libre distribucin, modificacin y uso del software
libre.
GUI: Interfaz de usuario representada con imgenes y objetos grficos para presentar informacin al
usuario.
Hacker Hacking: Es una persona que slo desea conocer el funcionamiento interno de los sistemas
informticos, ayudando a mejorarlos en el caso de que detecte fallos en su seguridad.
Hardware: Son las partes tangibles de una computadora.
Hypervisor: Tambin conocido como Virtual Machine Monitor, permite que distintos sistemas
operativos, tareas y configuraciones de software coexistan en una misma mquina fsica. Abstrae y
aisla los recursos fsicos de la computadora para asignarle recursos a las mquinas virtuales.
Integridad Informtica: La informacin debe ser consistente, fiable y no propensa a alteraciones no
deseadas.
Interfaz: Medio por el cual una persona puede interactuar con una computadora.
IPTables: Herramienta de cortafuegos que permite no solamente filtrar paquetes, sino tambin
realizar traduccin de direcciones de red (NAT) para IPv4 o mantener registros de log, tambin puede
ser usada para realizar funciones de un Router.

NAT (Network Address Translation - Traduccin de Direccin de Red): Es un mecanismo utilizado por
enrutadores IP para intercambiar paquetes entre dos redes que se asignan mutuamente direcciones
incompatibles, tambin es conocido como traduccin de direccin de Red.
KDE: Entorno de escritorio para sistemas operativos UNIX.
Kernel/ncleo: Software responsable de proporcionar acceso al hardware administrando sus
recursos.
Librera/Biblioteca: Es un conjunto de subprogramas utilizados para desarrollar software.
Llamada al sistema: Es el mecanismo usado por una aplicacin para solicitar un servicio al sistema
operativo.
LDAP: Son las siglas de Lightweight Directory Access Protocol (en espaol Protocolo Ligero de Acceso
a Directorios) que hacen referencia a un protocolo a nivel de aplicacin el cual permite el acceso a un
servicio de directorio ordenado y distribuido para buscar diversa informacin en un entorno de red.
LDAP tambin es considerado una base de datos (aunque su sistema de almacenamiento puede ser
diferente) a la que pueden realizarse consultas.
Mdulo: Parte de un programa que resuelve un problema especfico.
Pginas man: Es la documentacin que acompaa a las herramientas de un sistema UNIX.
Ping: Es una utilidad diagnstica en redes de computadoras que comprueba el estado de la conexin
del host local con uno o varios equipos remotos por medio del envo de paquetes ICMP de solicitud y
de respuesta.

Pool DHCP: Rango de IP que el DHCP puede asignar a los clientes o terminales.
Privacidad Informtica: La informacin debe ser vista y manipulada principalmente por quienes
tienen el derecho o la autoridad de hacerlo.
Prototipo: Es el diseo no funcional de un programa.
Repositorio: Servidor web que sirve de depsito para el software que se puede instalar en Linux.
Router: Es un dispositivo de hardware para interconexin de red de computadoras que opera en la
capa tres (nivel de red) del modelo OSI.
SaaS: Software as a Service, es un modelo de negocio en el cual la compaa que provee el software
tambin se encarga de operarlo y darle mantenimiento.
Script: Archivo de rdenes interpretados por la computadora.
Servidor: Es una computadora que provee servicios a otras computadoras.
Sistema Operativo: Es el programa o conjunto de programas que efectan la gestin de los procesos
bsicos de un sistema informtico, y permite la normal ejecucin del resto de las operaciones.
Software Libre: Software que respeta y garantiza la libertad que tiene una persona de usar, copiar,
estudiar, modificar y distribuir libremente el software.
Software: Componente lgico que posibilita la realizacin de tareas de una computadora. Sinnimo
de Aplicacin, Programa, Herramienta.
SWAP espacio de intercambio: Es una zona del disco (particin) que se usa para guardar las
imgenes de los procesos que no han de mantenerse en memoria fsica.

Transparencia: Ocultar informacin al usuario para que el sistema sea percibido como un todo en
lugar de una coleccin de componentes.
Ubuntu: Es una distribucin Linux basada en Debian que proporciona un sistema operativo para el
usuario medio, con un fuerte enfoque en la facilidad de uso e instalacin del sistema.

S-ar putea să vă placă și