Tesis

TECNOLGICO DE ESTUDIOS SUPERIORES DE
CHALCO

Ingeniera en Sistemas Computacionales

REFERENCIA:

CENTRO ESPECIALIZADO DE ATENCIN PRIMARIA A LA SALUD
ATLAUTLA

MONTAJE DE UN SERVIDOR WEB PARA EL CENTRO
ESPECIALIZADO DE ATENCIN PRIMARIA A LA SALUD
ATLAUTLA (CEAPS ATLAUTLA)

TESIS
QUE PARA OBTENER EL TITULO DE:
Ingeniero en Sistemas Computacionales

P R E S E N T A:

ANTONIO ALVAREZ GALICIA

CHALCO, ESTADO DE MXICO A 20 DE MAYO DE 2014

2

INDICE
NDICE DE FIGURAS .......................................................................................................................... 6
CAPITULO 1. INTRODUCCIN ......................................................................................................... 8
1.1. PLANTEAMIENTO DEL PROBLEMA .................................................................................. 8
1.2. JUSTIFICACIN ....................................................................................................................... 9
1.3. OBJETIVOS ............................................................................................................................. 10
1.3.1. Objetivo General ............................................................................................................ 10
1.3.2. Objetivos Especficos .................................................................................................. 10
1.4. HIPTESIS .............................................................................................................................. 11
1.5. ACTIVIDADES REALIZADAS .............................................................................................. 11
1.5.1. Interaccin con el cliente ............................................................................................ 12
1.5.2. Planificacin ................................................................................................................... 12
1.5.3. Diseo, desarrollo y pruebas ..................................................................................... 13
1.5.4. Cronograma de actividades........................................................................................ 14
CAPITULO 2. MARCO TERICO ................................................................................................... 15
2.1. SERVIDORES .............................................................................................................................. 15
2.1.1. Definicin de Servidor ...................................................................................................... 15
2.1.2. Tipos de Servidores ....................................................................................................... 17
2.2. SISTEMAS OPERATIVOS PARA SERVIDORES ................................................................. 19
2.2.1. Caractersticas de los Sistemas Operativos de Red ................................................ 19
2.3. SERVIDORES WEB ................................................................................................................... 21
2.3.1. Definicin de servidor web .......................................................................................... 21
2.4. ADMINISTRACIN DE LA SEGURIDAD. .............................................................................. 24
2.4.1. Definicin de administracin de la seguridad. ........................................................... 25
2.4.2. Buenas Prcticas en la seguridad de servidores ..................................................... 26
2.5. TECNOLOGAS DE LOS SISTEMAS WEB ........................................................................... 29
2.5.1. HTML 5 .................................................................................................................................. 29
2.5.1.1. Ventajas ......................................................................................................................... 30
2.5.1.2. Desventajas .................................................................................................................. 30
2.5.2. PHP ........................................................................................................................................ 31
2.5.2.1. Ventajas ......................................................................................................................... 32
2.5.2.2. Desventajas .................................................................................................................. 33
2.5.3. DomPDF ................................................................................................................................ 33

3

2.5.3.1. Ventajas ......................................................................................................................... 34
2.5.3.2. Desventajas .................................................................................................................. 34
2.5.4. MySQL .................................................................................................................................. 34
2.5.4.1. Ventajas ......................................................................................................................... 36
2.5.4.2. Desventajas .................................................................................................................. 37
2.5.4.3. Algunos detalles tcnicos de MySQL .................................................................... 37
2.5.5. Apache .................................................................................................................................. 37
2.5.5.1. Ventajas ......................................................................................................................... 39
2.5.5.2. Desventajas .................................................................................................................. 40
2.5.6. AJAX ...................................................................................................................................... 41
2.5.6.1. Tecnologas incluidas en Ajax ................................................................................ 42
2.5.6.2. Problemas e Inconvenientes.................................................................................... 42
2.5.7. JQuery ................................................................................................................................... 43
2.5.7.1. Ventajas ......................................................................................................................... 43
2.5.7.2. Desventajas .................................................................................................................. 44
2.6. VULNERABILIDAD DE LOS SERVICIOS EN LA WEB ...................................................... 44
2.7. DESCRIPCIN DE LAS VULNERABILIDADES CON MAYOR RIESGO PARA LAS
APLICACIONES WEB ....................................................................................................................... 46
2.7.1. Fallos de Inyeccin ............................................................................................................ 46
2.7.2. Secuencia de Comandos en Sitios Cruzados (XSS) ................................................. 46
2.7.3. Perdida de Autenticacin y Gestin de Sesiones ..................................................... 47
2.7.4. Referencia Insegura y Directa a Objetos ..................................................................... 47
2.7.5. Falsificacin de Peticin en Sitios Cruzados (CSRF)............................................... 47
2.7.6. Configuracin defectuosa de seguridad...................................................................... 47
2.7.7. Almacenamiento Criptogrfico Inseguro ..................................................................... 48
2.7.8. Fallos de restriccin de acceso a URL ......................................................................... 48
2.7.9. Comunicaciones Inseguras ............................................................................................. 48
2.7.10. Redirecciones y Reenvos no validados.................................................................... 48
2.8. MEDIDAS DE PREVENCIN CONTRA LAS VULNERABILIDADES .............................. 48
2.9. PROGRAMACIN EXTREMA .................................................................................................. 50
2.9.1. Caractersticas fundamentales ....................................................................................... 54
2.10. DIAGRAMA DE CASO DE USO ............................................................................................ 56
2.10.1. Diagramas de Casos de Uso UML ............................................................................... 56

4

2.11. DIAGRAMA UML ...................................................................................................................... 57
2.12. DIAGRAMA ENTIDAD RELACIN .................................................................................... 58
2.13. CALIDAD .................................................................................................................................... 60
2.13.1. Medida de la calidad de software ................................................................................ 62
2.14. ESTADISTICA INFERENCIAL ............................................................................................... 62
2.14.1. Planteamiento del problema ......................................................................................... 63
2.14.2. Elaboracin de un modelo ............................................................................................. 63
2.14.3. Extraccin de la muestra ............................................................................................... 63
2.14.4. Tratamiento de los datos ............................................................................................... 64
2.14.5. Estimacin de los parmetros ...................................................................................... 64
2.14.6. Contraste de hiptesis ................................................................................................... 64
2.14.7. Conclusiones .................................................................................................................... 64
2.15. SOFTENG AGILE ..................................................................................................................... 64
2.15.1. Estudio estratgico ......................................................................................................... 64
2.15.3. Produccin ........................................................................................................................ 66
2.15.3. Control de calidad ............................................................................................................ 66
2.15.4. Puesta en marcha ............................................................................................................ 66
2.15.5. Gestin del proyecto ....................................................................................................... 67
2.16. VARIABLES DE MEDICION ................................................................................................... 67
Tamao Muestral ........................................................................................................................... 67
2.16.1. Variables Humanas de Medicion ................................................................................. 68
2.16.1.1. Satisfaccin ................................................................................................................ 68
2.16.1.2. Calidad ......................................................................................................................... 70
2.16.2. Variables Tecnolgicas de Medicin .......................................................................... 70
2.16.2.1. Carga ............................................................................................................................ 70
2.16.2.2. Tiempo ......................................................................................................................... 72
2.17. ADMINISTRACIN DEL SERVIDOR EN UBUNTU SERVER 12.04 ............................... 72
2.17.1. Instalacion del sistema operativo Ubuntu Server 12.04 ........................................ 73
2.17.2. Instalacion de servidor DNS en Ubuntu Server 12.04 ............................................ 82
2.17.3. Configuracin de Samba ............................................................................................... 85
2.17.4. Instalacion de un servidor de Correo en Ubuntu Server 12.04 ............................ 93
2.17.5. Instalacion de los Servicios SSH y Telnet en Ubuntu Server 12.04 ................. 107
2.17.6. Conclusiones Sobre Telnet ......................................................................................... 110

5

2.17.7. Manejo e instalacin de SSH ...................................................................................... 110
REFERENCIAS ................................................................................................................................. 114

6

NDICE DE FIGURAS
Figura 1. Imagen de un servidor ....................................................................................................... 15
Figura 2. Esquema del funcionamiento del modelo cliente-servidor ........................................... 16
Figura 3. Operatividad bsica de una peticin cliente-servidor .................................................. 21
Figura 4. Predominancia de servidores con sistema operativo presintalado a la venta en el
mercado ................................................................................................................................................ 22
Figura 5. Distribucion de los sistemas operativos para servidor de las familias UNIX y Linux
en el mercado ...................................................................................................................................... 23
Figura 6. Distribucion de los sistemas operativos Linux en servidores ..................................... 24
Figura 7. Ciclo de la administracin de la seguridad ..................................................................... 25
Figura 8. Monitoreo Bsico del anlisis de seguridad en servidores ......................................... 28
Figura 9. Estructura bsica del documento HTML 5 ..................................................................... 29
Figura 10. Logo de PHP .................................................................................................................... 31
Figura 11. Posicionamiento de los lenguajes de programacin para servidor .......................... 32
Figura 12. Uso de los Sistemas Gestores de Base de Datos mas populares a nivel mundial 36
Figura 13. Posicionamiento de Apache frente a sus competidores ............................................ 38
Figura 14. Funcionamiento bsico de Apache ............................................................................... 39
Figura 15. Analisis Basico del ataque SQL injection ..................................................................... 45
Figura 16. Esquematizacion de los valores de XP ......................................................................... 53
Figura 17. Principios bsicos del trabajo con programacin extrema ........................................ 55
Figura 18. Simbologia bsica de los diagramas de caso de uso ................................................. 56
Figura 19. Ejemplo de un diagrama de caso de uso para un restaurante ................................. 57
Figura 20. Ejemplo del diagrama entidad relacin. .................................................................... 59
Figura 21. Gestion de proyectos segn SOFTENG Agile ............................................................. 65
Figura 22. Eleccion de Lenguaje para Instalacion de Ubuntu Server ......................................... 73
Figura 23. Instalacion de Ubuntu Server ......................................................................................... 74
Figura 24.Eleccion de pas en Ubuntu Server ................................................................................ 75
Figura 25. Configuracin de un teclado para latam para nuestra PC. ........................................ 76
Figura 26. Configuracin del nombre de la mquina, en este caso, naranja. ........................... 77
Figura 27. Configuracin del nombre de nuestro superusuario para usarlo dentro del sistema
operativo. .............................................................................................................................................. 77
Figura 28. creamos nuestro usuario personal y no un superusuario ya que una es la cuenta
individual y la otra la del superusuario. ............................................................................................ 78
Figura 29. Configuracin de la contrasea de la cuenta del usuario. ......................................... 78
Figura 30. Configuracin de la zona horaria del servidor, debemos seleccionar de la lista
completa para conseguir el adecuado. ............................................................................................ 79
Figura 31. Confirmacin de la parte del disco a formatear para instalar nuestro sistema
operativo. .............................................................................................................................................. 80
Figura 32. Confirmacin de escritura en disco de los cambios propuestos. .............................. 80
Figura 33. Servicios con los que cuenta el servidor y que pueden ser instalados desde un
principio usando la barra espaciadora como seleccionador. ........................................................ 81
Figura 34. Pantalla de finalizacin de instalacin de Ubuntu Server 12.04 ............................... 82
Figura 35. Configuracion de Carpetas ............................................................................................. 83
Figura 36. Instalacion de Complementos ........................................................................................ 84

7

Figura 37. Configuracion del archivo smb.conf .............................................................................. 86
Figura 38. Configuracion del archivo smb.conf (parte2) ............................................................... 87
Figura 39. Configuracion de la carpeta ............................................................................................ 88
Figura 40. Configuracion de usuarios en samba ............................................................................ 89
Figura 41.Configuracion de usuarios en samba ............................................................................. 90
Figura 42. Entrada al dominio desde un cliente ............................................................................. 91
Figura 43. Windows XP en el dominio ............................................................................................. 92
Figura 44. Alternativa de Acceso al dominio ................................................................................... 92
Figura 45. Servicios Previos ante instalacin de un servidor de Correo .................................... 93
Figura 46. Configuracion de La red estatica ................................................................................... 94
Figura 47Confguracion del servidor Web Apache.......................................................................... 95
Figura 48. Instalacion de los servicios de Correo .......................................................................... 96
Figura 49. Instalacion de otros servicios ......................................................................................... 97
Figura 50. Configuracion de Postfix ................................................................................................. 98
Figura 51. Configuacion de Squirrelmail .......................................................................................... 99
Figura 52. Configuracion de Squirrelmail (parte2) ....................................................................... 100
Figura 56. Creacion de un enlace simbolico ................................................................................. 104
Figura 57. Primer acceso a SquirrelMail ........................................................................................ 105
Figura 58. Interfaz Cliente Servidor de correo. ............................................................................. 105
Figura 59. Primer Correo en el cliente ........................................................................................... 106
Figura 60.Detalle de la pantalla de correo enviado. .................................................................... 107
Figura 61. Instalacion de los servicios ........................................................................................... 108
Figura 62. Acceso a Telnet .............................................................................................................. 109
Figura 63. Finalizacion del Servicio telnet ..................................................................................... 110
Figura 64. Instalacion del servicio SSH ......................................................................................... 111
Figura 65. Uso de Putty .................................................................................................................... 112
Figura 66. Uso de Putty (parte2) ..................................................................................................... 112
Figura 67. Configuracion de Putty .................................................................................................. 113
Figura 68. Incio de Putty .................................................................................................................. 113

8

CAPITULO 1. INTRODUCCIN
1.1. PLANTEAMIENTO DEL PROBLEMA

El CEAPS Atlautla es una institucin regional que cuenta con un sistema web
de administracin web, sin embargo, dicho sistema no cuenta con una generacin
dinmica de formatos para evitar datos redundantes que apoyen a los mdicos en
sus informes para evitar la sobrecarga de trabajo, esto disminuye la atencin que se
le da a los pacientes evitando un servicio ptimo, adems de que el sistema est en
internet y muchas veces se traba
1
.

Implementar un servidor web Linux en centros regionales con estas
caractersticas y, en particular, para los CEAPS que tienen la misma problemtica
abre las puertas a la implementacin intranet de sistemas ms eficientes y de bases
de datos ms rpidas trabajando con recursos mnimos. Otra caracterstica valuada
en dicho centro es el impacto que tiene en la sociedad, directamente afecta a 3
agentes, los cuales son en orden de importancia, los derechohabientes, los mdicos
de rea externa y la administracin del rea de estadstica.

Por un lado los derechohabientes deben esperar largas filas en los
consultorios ya que con cada cita que atienden los mdicos estos ltimos deben
llenar alrededor de 22 formatos para llevar un correcto control de informacin, ya que
por da deben entregar un informe de actividades traducido en ficha del da lo que
ocasiona que el tiempo de respuesta para la siguiente consulta sea muy tardado y el
tiempo en consulta sea mnimo, ello se traduce en una atencin muy rpida y poco
profunda para el paciente.

Por otro lado el rea de estadstica se enfrenta al problema de entregar
informes mensuales a sus autoridades y muchas veces los datos que entregan los
mdicos no son correctos por la enorme carga que tiene de trabajo a la hora de

1
(Pea, 2014)

9

hacer sus registros ocasionando datos redundantes, falsos, y regreso de documentos
para su realizacin una y otra vez.

Un servidor con sistema libre que pueda almacenar una base de datos y
respaldarla en servidores ajenos (usando trabajos en CRON) para evitar prdidas y
siempre tener un respaldo
2
, resulta costeable y de alto impacto a los
derechohabientes, los mdicos externos y el flujo de informacin estadstico
formando un canal que abre las posibilidades del centro a mejorar an ms los
servicios proporcionados.

1.2. JUSTIFICACIN

En la actualidad, y con el incremento de la poblacin, uno de los problemas
ms comunes en las clnicas regionales es el flujo de informacin para llevar un
correcto control de las operaciones realizadas acertadamente en el rea de consulta
externa.

Tal es el caso del Centro Especializado de Atencin Primaria a la Salud
seccin Atlautla (CEAPS Atlautla) donde el rea de consulta externa carece de un
sistema que apoye a los mdicos para generar sus informes mensuales que cuentan
con datos como el nmero de pacientes atendidos, el tipo de programa al que
pertenecen (Seguro Popular, por ejemplo), su diagnstico entre otros datos, ello
provoca que al final de cada mes se vean muy presionados para poder entregar
dicha documentacin al rea de estadstica provocando un descontrol en el flujo de
informacin, un desorden de datos y, en algunas ocasiones, datos que no coinciden
por lo apresurado de registrarlos
3
.

2
(W3Techs, Linux.org, 2014)
3
(Pea, 2014)

10

Implementar un servidor web con tecnologas libres en una de las maquinas
con las que cuenta el centro para la instalacin de un sistema a medida que ayude a
la administracin de formatos del rea de consulta externa ayudara a que los datos
generados por consulta en cada da y multiplicada por mes y por 24 horas generando
dichos formatos de manera dinmica ayudara a que los mdicos del centro tengan
menos trabajo para brindar un mejor servicio y mayor tiempo de atencin a los
derechohabientes evitando que los datos no coincidan cuando pasen al rea de
estadstica ya que estos ya fueron llenados apoyados desde el servidor web que se
encontrara en intranet.

Hacer uso de tecnologas libres e indagar sobre ellas creara un nuevo
panorama de accin para cualquier estancia de gobierno y no solo limitndose a un
rea de clnica, ya que este tipo de administracin de servidores Linux evitara
problemas sobre licencias, creara una conciencia de legalidad en las instituciones y
aumentara gravemente la seguridad, fiabilidad y flujo de informacin para esta y
otras instituciones.

1.3. OBJETIVOS
1.3.1. Objetivo General

Montar un servidor web con sistema operativo Linux, para instalar el sistema
de administracin de consulta externa en una clnica regional, acelerando su
atencin a derechohabientes.

1.3.2. Objetivos Especficos

Convertir una PC del Centro Especializado de Atencin Primaria a la Salud de
Atlautla (CEAPS Atlautla) en un servidor web Linux con sistema operativo
Ubuntu Server en apache para la instalacin de un sistema de administracin
de consulta externa programado en PHP, HTML 5, JQuery, AJAX, JavaScript,
JQuery UI en una plataforma de navegacin Google Chrome.

11

Generar automticamente los informes diarios y mensuales de cada mdico,
extrayendo dicha informacin de los registros de cada da de la base de datos
en MySQL en el servidor usando la librera DomPDF para reducir el trabajo en
el rea de consulta externa proporcionando ms atencin a los
derechohabientes.
Instalar el protocolo SSH para la comunicacin remota al servidor por parte de
administrador, facilitando su mantenimiento y evitando estar presente para
crear nuevas funcionalidades o corregir errores posibles que se presenten
ante en el centro.
Instalar el protocolo FTP mediante los repositorios de Ubuntu para la gestin
de archivos remotamente en caso de requerirse una actualizacin en el
servidor o en el propio sistema de administracin, reduciendo el tiempo de
mantenimiento generando mayor satisfaccin en los usuarios.

1.4. HIPTESIS

El montaje de un servidor web para instalar un sistema de administracin

de los pacientes aumentara la calidad del servicio proporcionado a los
derechohabientes y la satisfaccin del servicio.

Un servidor web dedicado a un sistema de administracin de pacientes

reduce el tiempo invertido en trabajo de los mdicos de consulta externa al generar
sus reportes de manera automtica.

1.5. ACTIVIDADES REALIZADAS

El montaje del servidor web y la programacin del sistema administrador de
pacientes para consulta externa fueron elaborados bajo la filosofa de la
programacin extrema debido a la necesidad de implementar lo ms rpido posible
este sistema informtico.

12

1.5.1. Interaccin con el cliente

Se plantea la realizacin de 5 entrevistas con respectivos 5 avances para
generar el software destinado a los mdicos bajo la supervisin del jefe de
estadstica, Lic. Orlando Valdez Pea del Centro Especializado de Atencin Primaria
a la Salud en el municipio de Atlautla. En primera instancia se puntualiz en la
necesidad que tienen los mdicos de entregar informes mensuales y diarios dados
los datos de los pacientes ya que estos consumen tiempo que ya no dedican a los
pacientes sino a generar documentacin de su trabajo. Estos informes muchas veces
no coinciden con los datos que se tienen en el rea de archivo, generando fallas e
inconsistencias que ms tarde repercuten en rehacer todos los informes desde cero.
Adicionalmente, el centro cuenta con un sistema de administracin, sin
embargo es ineficiente y carece de funcionalidades ya que es necesaria una
conexin a internet mejor que la tpica con la que se cuenta y por ello el sistema no
es utilizado.
Momentneamente el centro cuenta con un rea de consulta externa la cual
llena formatos iguales para todos los mdicos una clase de formatos denominados
SIS, los cuales evocan a datos particulares de los pacientes como su edad, genero,
programa de apoyo de adscripcin, diagnostico que presenta, si viene o no de otra
clnica, si pertenece a otro seguro, si es indgena, migrante, extranjero, etc. Todo
esto con un marcado riesgo de error ya que al registrar la consulta tambin debera
registrarse el informe mensual pero a su vez ocasionara inconsistencia o riesgo a
perdida de datos ya que cada paciente se maneja por una clave y lo mismo ocasiona
para el diagnstico.

1.5.2. Planificacin

Una vez obtenido el objetivo del proyecto se plantea el montaje de un servidor
web en el centro donde se instale un sistema de administracin para el rea de
consulta externa, registrando los pacientes para cada consulta, esto con el fin de

13

compartir la conexin a internet en una red intranet y que cada mdico pueda
acceder desde su consultorio al sistema en cuestin, por supuesto, para evitar el
problema de la conexin tambin es necesario este servidor, ya que, al encontrarse
en el centro mismo no requerir de un gran ancho de banda para generar resultados
ptimos.
Dada la necesidad los mdicos solo tendran que dar consulta ordinaria para
generar los informes correspondientes a los das y meses del ao, ya que en una
consulta se pueden recuperar los datos necesarios para este fin evitando la
redundancia de datos cumpliendo con el objetivo general.

1.5.3. Diseo, desarrollo y pruebas

Bajo la filosofa de la programacin extrema se han realizado varias pruebas
conforme avances se realizan acordes a las especificaciones e ideas generadas en
las entrevistas como se marca en el cronograma de actividades siguiente.

Lo que se pretende es continuar hasta la finalizacin del prototipo con las
entrevistas y la retroalimentacin de los involucrados en el proyecto para
enriquecerlo y extenderlo, adicionalmente este sistema apoyara en la generacin
ms rpida de los informes diarios y mensuales de cada mdicos para despus
adaptarlo a otros centro y a otras reas subsecuente a la finalizacin del software
como se indica en el cronograma.

14

1.5.4. Cronograma de actividades

TIEMPO ESTABLECIDO MARZO ABRIL MAYO JUNIO JULIO
NP ACTIVIDADES 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2
1 ELECCIN DEL TEMA
2 IDENTIFICACIN DEL PROBLEMA
3 ELABORACIN DE LA PROPUESTA DEL PROYECTO
4 PRIMERA ENTREVISTA CEAPS ATLAUTLA
5 ELABORACIN DE OBJETIVOS
6 DESARROLLO DEL PROTOTIPO FASE 1
7
ELABORACIN DE LA JUSTIFICACIN Y PLANTEAMIENTO DEL
PROBLEMA
8 SEGUNDA ENTREVISTA CEAPS ATLAUTLA
10 TERCERA ENTREVISTA CEAPS ATLAUTLA
11 ELABORACIN DE LA HIPTESIS Y CARATULA
13 MARCO TERICO
14 CUARTA ENTREVISTA CEAPS ATLAUTLA
16 QUINTA ENTREVISTA CEAPS ATLAUTLA
17 PRUEBAS E IMPLEMENTACIN EN SERVIDOR
18 ANLISIS DE RESULTADOS
19 CONCLUSIONES Y RECOMENDACIONES
20
ELABORACIN DE ESQUEMAS FINALES DEL TRABAJO
ESCRITO

15

CAPITULO 2. MARCO TERICO

2.1. SERVIDORES

2.1.1. Definicin de Servidor
Un servidor, es un ordenador o mquina informtica que est al servicio de
otras mquinas, ordenadores o personas llamadas clientes y que le suministran a
estos, todo tipo de informacin
4
.

Figura 1. Imagen de un servidor
Un servidor en informtica es un ordenador u otro tipo de dispositivo que
suministra una informacin requerida por unos clientes (que pueden ser personas, o
tambin pueden ser otros dispositivos como ordenadores, mviles, impresoras, etc.).
Por tanto, el siguiente esquema general, en el denominado esquema cliente-
servidor que es uno de los ms usados ya que en l se basa gran parte de internet.

4
(Augusto, 2011)

16

Figura 2. Esquema del funcionamiento del modelo cliente-servidor
Como se aprecia, tenemos una mquina servidora que se comunica con
variados clientes, todos demandando algn tipo de informacin. Esta informacin
puede ser desde archivos de texto, video, audio, imgenes, emails, aplicaciones,
programas, consultas a base de datos, etc.
Por regla general, las mquinas servidoras suelen ser algo ms potentes que
un ordenador normal
5
. Sobre todo suelen tener ms capacidad tanto de
almacenamiento de informacin como de memoria principal, ya que tienen que dar
servicio a muchos clientes. Pero como todo, tambin depende de las necesidades,
ya que podemos tener un servidor de menores prestaciones si vamos a tener pocos
clientes conectados, o si los servicios que queramos en el servidor no requieren una
gran capacidad servidora. Por general, los servidores suelen estar situados en
centros de datos de empresas (edificios con grandes salas dedicadas a alojar a los
servidores).

5
(Dueas, 2008)

17

2.1.2. Tipos de Servidores

Servidores de Aplicaciones (Application Servers)

Designados a veces como un tipo de middleware (software que conecta dos
aplicaciones), los servidores de aplicaciones ocupan una gran parte del territorio
entre los servidores de bases de datos y el usuario, y a menudo los conectan.

Servidores de Audio/Video (Audio/Video Servers)

Los servidores de Audio/Video aaden capacidades multimedia a los sitios
web permitindoles mostrar contenido multimedia en forma de flujo continuo
(streaming) desde el servidor.

Servidores de Chat (Chat Servers)

Los servidores de chat permiten intercambiar informacin a una gran cantidad
de usuarios ofreciendo la posibilidad de llevar a cabo discusiones en tiempo real.

Servidores de Fax (Fax Servers)

Un servidor de fax es una solucin ideal para organizaciones que tratan de
reducir el uso del telfono pero necesitan enviar documentos por fax.

Servidores FTP (FTP Servers)

Uno de los servicios ms antiguos de Internet, File Transfer Protocol permite
mover uno o ms archivos.

18

Servidores Groupware (Groupware Servers)

Un servidor groupware es un software diseado para permitir colaborar a los
usuarios, sin importar la localizacin, va Internet o va Intranet corporativo y trabajar
juntos en una atmsfera virtual.

Servidores IRC (IRC Servers)

Otra opcin para usuarios que buscan la discusin en tiempo real, Internet
Relay Chat consiste en varias redes de servidores separadas que permiten que los
usuarios conecten el uno al otro va una red IRC.

Servidores de Listas (List Servers)

Los servidores de listas ofrecen una manera mejor de manejar listas de correo
electrnico, bien sean discusiones interactivas abiertas al pblico o listas
unidireccionales de anuncios, boletines de noticias o publicidad.

Servidores de Correo (Mail Servers)

Casi tan ubicuos y cruciales como los servidores web, los servidores de correo
mueven y almacenan el correo electrnico a travs de las redes corporativas (va
LANs y WANs) y a travs de Internet.

Servidores Proxy (Proxy Servers)

Los servidores proxy se sitan entre un programa del cliente (tpicamente
un navegador) y un servidor externo (tpicamente otro servidor web) para filtrar
peticiones, mejorar el funcionamiento y compartir conexiones.

19

Servidores Web (Web Servers)

Bsicamente, un servidor web sirve contenido esttico a un navegador, carga
un archivo y lo sirve a travs de la red al navegador de un usuario. Este intercambio
es mediado por el navegador y el servidor que hablan el uno con el otro mediante
HTTP.
Se pueden utilizar varias tecnologas en el servidor para aumentar su potencia
ms all de su capacidad de entregar pginas HTML; stas incluyen scripts CGI,
seguridad SSL y pginas activas del servidor (ASP).
2.2. SISTEMAS OPERATIVOS PARA SERVIDORES

Un sistema operativo de red (Network Operating System) es un componente
software de una computadora que tiene como objetivo coordinar y manejar las
actividades de los recursos del ordenador en una red de equipos. Consiste en un
software que posibilita la comunicacin de un sistema informtico con otros equipos
en el mbito de una red. Dependiendo del fabricante del sistema operativo de red, el
software de red para un equipo personal se puede aadir al propio sistema operativo
del equipo o integrarse con l. Netware de Novell es el ejemplo ms familiar y
famoso de sistema operativo de red donde el software de red del equipo cliente se
incorpora en el sistema operativo del equipo. El equipo personal necesita ambos
sistema operativos para gestionar conjuntamente las funciones de red y las funciones
individuales.

2.2.1. Caractersticas de los Sistemas Operativos de Red

En general, se puede decir que un Sistema Operativo tiene las siguientes
caractersticas:
- Conveniencia. Un Sistema Operativo hace ms conveniente el uso de una
computadora.

20

- Eficiencia. Un Sistema Operativo permite que los recursos de la
computadora se usen de la manera ms eficiente posible.
- Habilidad para evolucionar. Un Sistema Operativo deber construirse de
manera que permita el desarrollo, prueba o introduccin efectiva de nuevas
funciones del sistema sin interferir con el servicio.
- Encargado de administrar el hardware. El Sistema Operativo se encarga
de manejar de una mejor manera los recursos de la computadora en
cuanto a hardware se refiere, esto es, asignar a cada proceso una parte
del procesador para poder compartir los recursos.
- Relacionar dispositivos (gestionar a travs del kernel). El Sistema
Operativo se debe encargar de comunicar a los dispositivos perifricos,
cuando el usuario as lo requiera.
- Organizar datos para acceso rpido y seguro.
- Manejar las comunicaciones en red. El Sistema Operativo permite al
usuario manejar con alta facilidad todo lo referente a la instalacin y uso de
las redes de computadoras.
- Procesamiento por bytes de flujo a travs del bus de datos.
- Facilitar las entradas y salidas. Un Sistema Operativo debe hacerle fcil al
usuario el acceso y manejo de los dispositivos de Entrada/Salida de la
computadora.
- Tcnicas de recuperacin de errores.
- Evita que otros usuarios interfieran. El Sistema Operativo evita que los
usuarios se bloqueen entre ellos, informndoles si esa aplicacin est
siendo ocupada por otro usuario.
- Generacin de estadsticas.
- Permite que se puedan compartir el hardware y los datos entre los
usuarios.

21

Figura 3. Operatividad bsica de una peticin cliente-servidor

2.3. SERVIDORES WEB

2.3.1. Definicin de servidor web
Los servidores web son los que hacen posible el Web hosting, es decir, la
posibilidad de alquilar un espacio en un servidor para alojar nuestro sitio.
La principal funcin de un servidor Web es almacenar los archivos de un sitio y
emitirlos por Internet para poder ser visitado por los usuarios. Bsicamente, un
servidor Web es una gran computadora que guarda y transmite datos va Internet.
Cuando un usuario entra en una pgina de Internet su navegador se comunica con
el servidor enviando y recibiendo datos que determinan qu es lo que ve en la
pantalla.
Cada servidor Web y cada computadora conectada a Internet tienen
asignado una direccin de IP irrepetible que lo identifica en la red. La direccin de
IP vendra a ser como los datos del remitente en una carta postal. Cuando se entra
a un sitio Web, se enva un pedido desde la direccin de IP hacia la direccin IP del
servidor. El servidor Web responde mandando datos a la direccin IP que los pide.

22

La capacidad de un servidor depende del tipo de servidor que sea y de los
componentes que lo conforman.
Por supuesto, la gran diferencia en velocidad, seguridad, viabilidad,
usabilidad y administracin de un servidor web depende mucho del sistema
operativo como punto de montaje. En la actualidad, los servidores vienen con
sistemas operativos instalados por defecto (Vease figura 4) que pueden o no
cumplir con las normas y/o policas empresariales.

Figura 4. Predominancia de servidores con sistema operativo presintalado a la venta en el mercado
extraida de W3Techs Web Technology Surveys: http://w3techs.com/technologies/details/os-
linux/all/all

Observamos una clara predominancia de los sistemas operatrivos de la
familia Microsoft, sin embargo, ello no implica que los mas usados sean estos
precisamente, sino que la figura muetra aquellos servidores cuyo sistema por
defecto es Windows, en este aspecto, es necesario destacar que cuando la
73.90%
21.10%
Sistemas Operativos de
Servidor
Windows Server Linux

23

empresa lo requiere los sistemas operativos por defecto son sustituidos
primordialmente por productos de la familia Linux
6
.
Adjunto a las polticas y predominancia de los sistemas operativos de
servidor y la actualizacin a familia Linux ello implica un anlisis detallado de la
concurrencia de esta familia en el mercado de los servidores en contraste a la
familia Windows (Vease Figura 5).

Figura 5. Distribucion de los sistemas operativos para servidor de las familias UNIX y Linux en el
mercado
linux/all/all

Quizs la predominancia de la familia Linux se deba a la facilidad de uso
para usuarios promedio adjuntos a las nuevas tecnologas, ello implica un anlisis
de la predominancia de esta familia de sistemas operativos en el mercado para
destacar la viabilidad en contraste a la conveniencia del fin ultimo (Vase Figura 6).

6
(Gelbmann, 2013)
67.50%
38.90%
UNIX y Linux en
Servidores
Linux UNIX

24

Figura 6. Distribucion de los sistemas operativos Linux en servidores
linux/all/all
.

2.4. ADMINISTRACIN DE LA SEGURIDAD.

Para que un esquema de seguridad quede completo, es necesario que se
lleve a cabo la administracin de la seguridad.

29%
22.80%
19.80%
6.70%
2.00%
1.90%
1.20%
16.60%
Linux en Servidores
Debian Ubuntu CentOS RedHat
Gentoo Fedora SuSE Otros

25

Figura 7. Ciclo de la administracin de la seguridad
imagen de Claudia Yvette Castro Jaime, T. H. (2010). Polticas y Buenas Prcticas de seguridad en
Servidores Web del CDMIT. Distrito Federal: Ciudad Universitaria.
.

2.4.1. Definicin de administracin de la seguridad.

La administracin de la seguridad se refiere a gestionar y dirigir todas las
acciones que se lleven a cabo con el fin de proteger la informacin, hacer uso lcito
de sta, as como de los recursos con los que cuenta la organizacin
7
.

La administracin consta de cuatro etapas
que son:

Etapa 1: Planeacin. Se debe llevar a cabo una revisin peridica de las polticas
de seguridad, por lo que hay que revisar el esquema de seguridad
desarrollado para identificar si se requiere actualizar, remover y modificar las que
ya existen.

Etapa 2: Proteccin. Despus de revisar y actualizar las polticas de seguridad
del entorno, se debe de reforzar la seguridad con base en stas y hacer uso de

7
(Claudia Yvette Castro Jaime, 2010)

26

nuevas tecnologas, ya que estas nuevas formas de proteccin elevan el nivel de
seguridad del entorno en cuestin.
Etapa 3: Deteccin. Es necesario contar con sistemas que permitan realizar
actividades de monitoreo de forma continua y permanente en toda informacin,
reas y sistemas que sean considerados dentro de las polticas como de
relevancia; y as mismo, generar reportes que permitan detectar alguna anomala
para tomar las medidas pertinentes, es decir, reaccionar a la anomala.
Etapa 4: Reaccin ante el incidente. En sta etapa se toman las decisiones que
dictan las acciones orientadas a salvaguardar los bienes informticos de
la empresa u organizacin, esto con base en la informacin obtenida de la etapa
anterior, se realiza de manera continua un anlisis de sta para tomar una decisin
de cambio de polticas o mecanismos. Estos cambios pueden ser desde actualizar
la tecnologa para llevar a cabo la proteccin de los bienes, modificar esquemas
de seguridad o llevar a cabo una revisin extraordinaria de las polticas, entre
otros.

2.4.2. Buenas Prcticas en la seguridad de servidores

Aunque nadie puede garantizar la seguridad al 100% de los algoritmos y la
estabilidad de un servidor, si que es posible generar un grado alto de calidad en el
montaje y administracin de los mismos para obtener resultados optimos, la
deteccin de las fallas es posible mediante el anlisis de las vulnerabilidades que
mas afectan en la actualidad a esta clase de dispositivos (vase Figura) por lo que es
importante seguir algunos patrones de conducta cuando se habla de instalar un
servidor:
1. No instalar servicios que no son necesarios. En general, en una operacin
tpica de instalacin, por defecto, del sistema no es seguro, ya que muchos
servicios de red que se descargan no son realmente necesarios por el usuario.
Esto se convierte en ms peligroso porque los servicios estn abiertos en el
servidor, es decir, ms puertos potenciales para los hackers puedan introducirse

27

en el mismo. Al eliminar estos servicios innecesarios de su servidor de red o
nunca descargarlos en primer lugar, estaras tomando importantes medidas
preventivas para prevenir una brecha en la seguridad del servidor.

2. Accesibilidad de inicio de sesin remoto. En el pasado, muchos servidores
slo eran accesibles a travs de un Login de forma local. Sin embargo, esto no es
propicio para el entorno empresarial actual. Existe una mayor posibilidad de un
fallo de seguridad en el servidor cuando el acceso remoto est disponible, pero
se pueden tomar medidas para asegurar una conexin remota. Tneles y cifrado
junto con software de seguridad y otros equipos son una buena manera de
garantizar la mayor proteccin posible si se utiliza el acceso remoto a un servidor.

3. Seguimiento, Monitoreo, y auditora del servidor. A menudo, las brechas de
seguridad se producen porque el departamento de TI no es consciente de lo que
est pasando. Todos los registros en los servidores web deben ser almacenados
en un rea inaccesible por separado. Estos registros, incluyendo registros de
acceso del sitio web, registros de servicios de red, los registros del sistema y los
registros de la base de datos del servidor se les debe realizar un seguimiento de
por lo menos una vez por semana, si no todos los das. Ser consciente de una
posible infraccin, ya que si se produce puede ser la mejor manera de minimizar
los daos, se puede resolver o incluso se puede detectar que se est
produciendo.

4. Desarrollo y prueba de aplicaciones Web. Debido a que es ms fcil y ms
rpido probar nuevas aplicaciones web en el servidor en s, muchos
desarrolladores lo hacen. Sin embargo, esto es muy peligroso porque estas
aplicaciones web por lo general en sus primeras fases de desarrollo y no tienen

28

ningn tipo de restricciones de seguridad desarrollada. Debido a estos peligros,
las nuevas aplicaciones web ya sea en desarrollo o prueba siempre deben
llevarse a cabo en distintos servidores de Internet, y an ms importante, nunca
se debe conectar a los datos importantes o bases de datos.

5. Privilegios y acceso al servidor. Cuando un servidor web se ve comprometido
por medio de una violacin del mismo, a menudo el hacker puede utilizar la
cuenta que est corriendo en el servidor para ejecutar tareas maliciosas. Es por
esto que es tan importante que para conceder determinados permisos slo a
ciertos individuos, por lo general una violacin no da lugar a que el hacker tenga
acceso a toda la informacin. Como regla general, slo se debe permitir que los
privilegios mnimos para el usuario annimo, estos privilegios usualmente slo
permiten el acceso a la pgina web, archivos de aplicaciones web, datos
generales y bases de datos.

Figura 8. Monitoreo Bsico del anlisis de seguridad en servidores

29

.

2.5. TECNOLOGAS DE LOS SISTEMAS WEB

2.5.1. HTML 5
HTML 5 es una coleccin de estndares para el diseo y desarrollo de pginas web.
Esta coleccin representa la manera en que se presenta la informacin en el
explorador de internet y la manera de interactuar con ella.
HTML 5 est siendo desarrollado por Ian Hickson de Google Inc. y David Hyatt de
Apple Inc. junto con todas las personas que participan en Web Hypertext Application
Technology Working Group.
HTML 5 nos permite una mayor interaccin entre nuestras pginas web y contenido
media (video, audio, entre otros) as como una mayor facilidad a la hora de codificar
nuestro diseo bsico
8
.

Figura 9. Estructura bsica del documento HTML 5

Esta nueva versin se bas en el diseo ms comn de las pginas web

8
(Gauchat, 2012)

30

alrededor del mundo para llegar a un estndar de etiquetas que realicen las mismas
tareas de manera ms rpida y eficiente
2.5.1.1. Ventajas

Las principales ventajas que presenta HTML5, tenemos las siguientes:
Nueva estructura de etiquetas mejorada, esta nueva estructura permite
definir por separado el encabezado, la barra de navegacin, las secciones de la
pgina web, los textos del sitio, los dilogos y el pi de pgina de los sitios web. Esta
nueva estructura, incluso permite desarrollar blogs con gran facilidad.
Inclusin de las etiquetas video y audio, dicha etiqueta soporta de manera
eficiente y estable cualquier opcin de ejecucin de video y audio, sin generar
errores o incluir cdigo flash en nuestro sitio web.
Capacidad de realizar ejecuciones offline de las pginas web creadas con
cdigo HTML5, lo que permite realizar aplicaciones de escritorio con este cdigo tan
verstil.
Incluye una nueva etiqueta de dibujo sobre la pgina web, llamada canvas,
que vuelve el proceso de crear dibujos en el sitio web tan fcil como dibujar con
aplicaciones como Paint.
2.5.1.2. Desventajas

No se preveen buenos filtros a los campos de texto insertados
En algunas ocasiones el PHp emebebido ocasiona conflictos con las nuevas
etiquetas
No todos los navegadores detectan aun esta nueva tendencia
Aun no se prevee la inclusin del CSS3 en todos los navegadores
Algunos dispositivos mviles no reconocen la snuevas etiquetas.

31

2.5.2. PHP
PHP es un lenguaje de cdigo abierto muy popular, adecuado para desarrollo
web y que puede ser incrustado en HTML. PHP (acronimo de "PHP: Hypertext
Preprocessor") es un lenguaje interpretado de alto nivel embebido enpginas HTML y
ejecutado en el servidor
9
.

Figura 10. Logo de PHP
PHP se utiliza para generar pginas web dinmicas. Se llama pgina esttica
a aquella cuyos contenidos permanecen siempre igual, mientras que se llama pgina
dinmica a aquella cuyo contenido no es el mismo siempre. Por ejemplo, los
contenidos pueden cambiar en base a los cambios que haya en una base de datos,
de bsquedas o aportaciones de los usuarios, etc.
Estas caractersticas convierten a PHp en una de las herramientas mas tiles
en la programacin e intalacion de sistemas web y ha generado gran expectativa por
su constante actualizacin frente a sus competidores (vase figura 11)

9
(Martnez, 2002) (Jimmy Wales, 2011)

32

Figura 11. Posicionamiento de los lenguajes de programacin para servidor
linux/all/all

2.5.2.1. Ventajas
- Es un lenguaje multiplataforma.
- Completamente orientado al desarrollo de aplicaciones web dinmicas con
acceso a informacin almacenada en una Base de Datos.
- El cdigo fuente escrito en PHP es invisible al navegador y al cliente ya que
es el servidor el que se encarga de ejecutar el cdigo y enviar su resultado HTML al
navegador. Esto hace que la programacin en PHP sea segura y confiable.
- Capacidad de conexin con la mayora de los motores de base de datos que
se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL.
- Capacidad de expandir su potencial utilizando la enorme cantidad de
mdulos (llamados ext's o extensiones).
81.80%
17.90%
2.70%
0.80%
0.60% 0.50%
0.20% 0.10%
Lenguajes para Servidores
PHP ASP .NET Java ColdFusion
Perl Ruby Python JavaScript

33

Como es un lenguaje que se interpreta en ejecucin para ciertos usos puede
resultar un inconveniente que el cdigo fuente no pueda ser ocultado. La ofuscacin
es una tcnica que puede dificultar la lectura del cdigo pero no la impide y, en
ciertos casos, representa un costo en tiempos de ejecucin
2.5.3. DomPDF
En ocasiones surge la necesidad de devolver va web un fichero con
formato PDF. La utilizacin de herramientas para la elaboracin de informes suelen
dar resultados muy profesionales permitiendo personalizar la parte visual poniendo
nmero de pgina, cabecera, etc. Sin embargo, cuando esta informacin se est
mostrando por pantalla en un HTML y se desea que sea descargable en un
documento nos obliga a tener que realizar la misma tarea dos veces, una
para HTML y otra para PDF.
DomPDF es una herramienta que permite leer un documento HTML y
convertirlo a PDF. El objetivo de esta herramienta no es crear un documento
estticamente profesional y personalizado, sino permitir con el mismo
documento HTML generar un documento PDF para que el usuario lo pueda
descargar ms fcilmente. Cuando la parte esttica no es tan importante, a veces
viene bien simplificar el trabajo realizando una sola vez la programacin.
Este proyecto es muy reciente, an por la versin Dompdf v0.5, por lo que en
la actualidad es una herramienta para considerarla con mucha prudencia.
Actualmente, la mayor parte de la funcionalidad soporta la mayor parte de CSS2. El
mayor reto que se pueden encontrar est en el desarrollo del soporte de los ltimos
estndares HTML 5 y CSS3.
Aunque tambin tiene limitaciones importantes. No siempre se puede plasmar
lo que puede ver el usuario en el caso de utilizar AJAX o contiene JavaScript. Por
otra parte, para poder utilizar esta librera es necesario que el HTML est en una
cadena por lo que el consumo de memoria puede ser considerable si el informe que

34

se desea imprimir es muy grande. Adems obligara a poner el CSS dentro del
fichero HTML.
Como punto positivo adicional, no es preciso incorporar mdulos o libreras
externas (en la configuracin del apache) ya que utiliza la clase R&OS escrita
en PHP que genera el PDF. Esta librera soporta PHP5 o superior y la licencia
es LGPL.
2.5.3.1. Ventajas

- Es posible convertir el cdigo HTML visualizado en una web en un
documento PDF
- Detecta CSS3 en las etiquetas de HTML
- Los diseos son fieles a la visualizacin en PDF despus de renderizar.
- Es agil con el servidor apache


- Existen varios problemas en cuanto a coordenadas en la inclusin de
etiquetas HTML
- No es posible atrapar aun todas las excepciones
- Es un proyecto de origen nuevo y por ello no cuenta con gran
documentacin
- La mayora de las funcionalidades nuevas se basan en la experiencia de
otros usuarios.

2.5.4. MySQL

MySQL es el servidor de bases de datos relacionales ms popular,
desarrollado y proporcionado por MySQL AB. MySQL AB es una empresa cuyo

35

negocio consiste en proporcionar servicios en torno al servidor de bases de datos
MySQL
10
.
Una base de datos es una coleccin estructurada de datos. La informacin
que puede almacenar una base de datos puede ser tan simple como la de una
agenda, un contador, o un libro de visitas, o tan vasta como la de una tienda en lnea,
un sistema de noticias, un portal, o la informacin generada en una red corporativa.
Para agregar, accesar, y procesar los datos almacenados en una base de datos, se
necesita un sistema de administracin de bases de datos, tal como MySQL.
Una base de datos relacional almacena los datos en tablas separadas en lugar
de poner todos los datos en un solo lugar. Esto agrega velocidad y flexibilidad. Las
tablas son enlazadas al definir relaciones que hacen posible combinar datos de
varias tablas cuando se necesitan consultar datos. La parte SQL de "MySQL"
significa "Lenguaje Estructurado de Consulta", y es el lenguaje ms usado y
estandarizado para accesar a bases de datos relacionales.
El servidor MySQL fue desarrollado originalmente para manejar grandes
bases de datos mucho ms rpido que las soluciones existentes y ha estado siendo
usado exitosamente en ambientes de produccin sumamente exigentes por varios
aos. Aunque se encuentra en desarrollo constante, el servidor MySQL ofrece hoy
un conjunto rico y til de funciones. Su conectividad, velocidad, y seguridad hacen de
MySQL un servidor bastante apropiado para accesar a bases de datos en Internet.

10
(Jimmy Wales, 2011)

36

Figura 12. Uso de los Sistemas Gestores de Base de Datos mas populares a nivel mundial
extraida de W3Techs Web Technology Surveys: http://w3techs.com/technologies/details/os-linux/all/all

2.5.4.1. Ventajas

1. MySQL software es Open Source
2. Velocidad al realizar las operaciones, lo que le hace uno de los gestores con
mejor rendimiento.
3. Bajo costo en requerimientos para la elaboracin de bases de datos, ya
que debido a su bajo consumo puede ser ejecutado en una mquina con
escasos recursos sin ningn problema.
4. Facilidad de configuracin e instalacin.
Soporta gran variedad de Sistemas Operativos
5. Baja probabilidad de corromper datos, incluso si los errores no se producen
en el propio gestor, sino en el sistema en el que est.
6. Su conectividad, velocidad, y seguridad hacen de MySQL Server
altamente apropiado para acceder bases de datos en Internet
MongoDB,
12%
CouchDB,
0%
MySQL,
58%
PostgreSQ
L, 10%
MariaDB,
20%
USO DE SGBD

37

7. El software MySQL usa la licencia GPL


1. Un gran porcentaje de las utilidades de MySQL no estn documentadas.
2. No es intuitivo, como otros programas (ACCESS).

2.5.4.3. Algunos detalles tcnicos de MySQL

El software de bases de datos MySQL consiste de un sistema cliente/servidor
que se compone de un servidor SQL multihilo, varios programas clientes y
bibliotecas, herramientas administrativas, y una gran variedad de interfaces de
programacin (APIs). Se puede obtener tambin como una biblioteca multihilo que se
puede enlazar dentro de otras aplicaciones para obtener un producto ms pequeo,
ms rpido, y ms fcil de manejar.
2.5.5. Apache

Apache es el Servidor Web ms utilizado, lder con el mayor nmero de
instalaciones a nivel mundial muy por delante de otras soluciones como el IIS
(Internet Information Server) de Microsoft. Apache es un proyecto de cdigo abierto y
uso gratuito, multiplataforma (hay versiones para todos los sistemas operativos ms
importantes), muy robusto y que destaca por su seguridad y rendimiento (vase
figura).

38

Figura 13. Posicionamiento de Apache frente a sus competidores
extraida de W3Techs Web Technology Surveys: http://w3techs.com/technologies/details/os-linux/all/all

Su misin es crtica, ya que es el encargado de aceptar las peticiones de
pginas (o recursos en general) que provienen de los visitantes que acceden a
nuestro sitio web y gestionar su entrega o denegacin, de acuerdo a las polticas de
seguridad establecidas. Esto, que puede parecer simple, implica muchas facetas y
funcionalidades que debe cubrir, como pueden ser:
Atender de manera eficiente, ya que puede recibir un gran nmero de peticiones
HTTP, incluyendo una ejecucin multitarea ya que pueden darse peticiones
simultneas. Cualquier peticin compleja (por ejemplo con acceso a base de datos)
dejara colapsado el servicio.
Restricciones de acceso a los ficheros que no se quieran exponer, gestin de
autentificaciones de usuarios o filtrado de peticiones segn el origen de stas.
Manejar los errores por pginas no encontradas, informando al visitante y/o
redirigiendo a pginas predeterminadas.
Gestin de la informacin a transmitir en funcin de su formato e informar
adecuadamente al navegador que est solicitando dicho recurso.
64.92%
14.39%
9.89%
3.16%
Uso de Servidores
(2012)
Apache Microsoft Nginx Google

39

Gestin de logs, es decir almacenar las peticiones recibidas, errores que se han
producido y en general toda aquella informacin que puede ser registrada y
analizada posteriormente para obtener las estadsticas de acceso al sitio web.

Figura 14. Funcionamiento bsico de Apache

2.5.5.1. Ventajas

El paquete del servidor es ms flexible en tiempo de ejecucin porque el
proceso actual del servidor puede ser ensamblado en tiempo de ejecucin por
medio de LoadModule en httpd.conf en lugar de hacerlo por medio de la
configuration en tiempo de compilacin. De este modo se pueden arrancar
diferentes instancias del servidor (estndar, versin SSL, mnima, versin
potenciada [PHP, etc. ], etc.) con una nica instalacin de Apache.
El paquete del servidor puede ser fcilmente ampliado con mdulos de
terceros incluso despus de la instalacin. Esto representa un gran beneficio
para los que mantienen paquetes, ya que les permite crear el paquete del
ncleo de Apache y adicionalmente paquetes que contengan extensiones
como PHP, mod_perl, mod_fastcgi, ...

40

Mayor facilidad en los prototipos de mdulos Apache porque con DSO y apxs
se puede trabajar fuera del rbol fuente de Apache y necesitar un nico
comando apxs -i seguido de un apachectl restart para cargar una nueva
versin del mdulo desarrollado en el servidor Apache que est funcionando
actualmente.

El mecanismo DSO no puede ser usado en todas las plataformas porque no
todos los sistemas operativos soportan carga dinmica del cdigo en el
espacio de direcciones de un programa.
El servidor es aproximadamente un 20% ms lento en su arranque debido a la
sobrecarga que la resolucin representa para el cargador (loader).
El servidor es aproximadamente un 5% ms lento en su ejecucin bajo
algunas plataformas porque el PIC (Position Independent Code, posicin de
cdigo independiente) necesita maniobras complicadas para direccionamiento
dinmico, que no es necesariamente tan rpido como el direccionamiento
absoluto.
No se puede usar DSO para todo tipo de mdulos, debido a que los mdulos
DSO no pueden ser enlazados con otras bibliotecas basadas en DSO (ld -lfoo)
en todas las plataformas
B.4
. En otras palabras, los mdulos compilados como
ficheros DSO estn restringidos a utilizar slo smbolos del ncleo de Apache,
de las biblioteca C (libc ) y todas las dems bibliotecas dinmicas o simblicas
usadas por el ncleo de Apache o desde archivos de bibliotecas estticas
(libfoo.a ) que contengan PIC. La nica ocasin de usar otro cdigo es, o bien
asegurarse de que el ncleo de Apache ya contenga una referencia a l,
cargando uno mismo el cdigo por medio de dlopen() , o bien habilitando la
regla SHARED_CHAIN cuando se compila Apache y la plataforma soporta el
enlace de ficheros DSO contra bibliotecas DSO.
Bajo algunas plataformas (varios sistemas SVR4) no hay forma de forzar al
enlazador para que exporte todos los smbolos globales cuando se enlaza el

41

programa ejecutable httpd. Pero sin la visibilidad de los smbolos del ncleo de
Apache, ningn mdulo estndar de Apache podra ser usado como DSO. La
nica posible solucin es compilar el sistema con la opcin SHARED_CORE
porque de este modo los smbolos globales se fuerzan a ser exportados.

2.5.6. AJAX

Ajax, acrnimo de Asynchronous J avaScript And XML (JavaScript asncrono
y XML), es una tcnica de desarrollo web para crear aplicaciones interactivas o RIA
(Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en
el navegador de los usuarios mientras se mantiene la comunicacin asncrona con el
servidor en segundo plano. De esta forma es posible realizar cambios sobre las
pginas sin necesidad de recargarlas, lo que significa aumentar la interactividad,
velocidad y usabilidad en las aplicaciones
11
.
Ajax es una tecnologa asncrona, en el sentido de que los datos adicionales
se solicitan al servidor y se cargan en segundo plano sin interferir con la visualizacin
ni el comportamiento de la pgina. JavaScript es el lenguaje interpretado (scripting
language) en el que normalmente se efectan las funciones de llamada de Ajax
mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto
disponible en los navegadores actuales. En cualquier caso, no es necesario que el
contenido asncrono est formateado en XML.
Ajax es una tcnica vlida para mltiples plataformas y utilizable en muchos
sistemas operativos y navegadores dado que est basado en estndares abiertos
como JavaScript y Document Object Model (DOM).

11
(Jimmy Wales, 2011)

42

2.5.6.1. Tecnologas incluidas en Ajax
Ajax es una combinacin de cuatro tecnologas ya existentes:
XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseo que
acompaa a la informacin.
Document Object Model (DOM) accedido con un lenguaje de scripting por
parte del usuario, especialmente implementaciones ECMAScript como
JavaScript y JScript, para mostrar e interactuar dinmicamente con la
informacin presentada.
El objeto XMLHttpRequest para intercambiar datos de forma asncrona con el
servidor web. En algunos frameworks y en algunas situaciones concretas, se
usa un objeto iframe en lugar del XMLHttpRequest para realizar dichos
intercambios.
XML es el formato usado generalmente para la transferencia de datos
solicitados al servidor, aunque cualquier formato puede funcionar, incluyendo
HTML preformateado, texto plano, JSON y hasta EBML.
Como el DHTML, LAMP o SPA, Ajax no constituye una tecnologa en s, sino que
es un trmino que engloba a un grupo de stas que trabajan conjuntamente.
2.5.6.2. Problemas e Inconvenientes
Las pginas con AJAX son ms difciles de desarrollar que las pginas
estticas.
Las pginas creadas dinmicamente mediante peticiones sucesivas AJAX, no
son registradas de forma automtica en el historial del navegador, as que
haciendo clic en el botn de "volver" del navegador, el usuario no ser
devuelto a un estado anterior de la pgina, en cambio puede volver a la ltima
pgina que visit. Soluciones incluyen el uso de IFrames invisible para
desencadenar cambios en el historial del navegador y el cambio de la porcin
de anclaje de la direccin.

43

Los motores de bsquedas no entienden JavaScript. La informacin en la
pgina dinmica no se almacena en los registros del buscador.
Hay problemas usando Ajax entre nombres de dominios. Eso es una funcin
de seguridad.
El sitio con Ajax usa ms recursos en el servidor. Recomendacin: slo usar
las peticiones necesarias en Ajax, no desarrollar todo el sitio en AJAX. Con
esto garantizamos menos recursos del servidor.
Es posible que pginas con Ajax no puedan funcionar en telfonos mviles,
PDA u otros aparatos. Ajax no es compatible con todo el software para ciegos
u otras discapacidades.
2.5.7. JQuery
JQuery es una biblioteca de JavaScript, creada inicialmente por John Resig,
que permite simplificar la manera de interactuar con los documentos HTML,
manipular el rbol DOM, manejar eventos, desarrollar animaciones y agregar
interaccin con la tcnica AJAX a pginas web. Fue presentada el 14 de enero de
2006 en el BarCamp NYC
12
.
JQuery es software libre y de cdigo abierto, posee un doble licenciamiento
bajo la Licencia MIT y la Licencia Pblica General de GNU v2, permitiendo su uso en
proyectos libres y privativos. jQuery, al igual que otras bibliotecas, ofrece una serie
de funcionalidades basadas en JavaScript que de otra manera requeriran de mucho
ms cdigo, es decir, con las funciones propias de esta biblioteca se logran grandes
resultados en menos tiempo y espacio.
2.5.7.1. Ventajas
La ventaja principal de jQuery es que es mucho ms fcil que sus
competidores. Usted puede agregar plugins fcilmente, traducindose esto en un

12
(Jimmy Wales, 2011)

44

ahorro substancial de tiempo y esfuerzo. De hecho, una de las principales razones
por la cual Resig y su equipo crearon jQuery fue para ganar tiempo (en el mundo de
desarrollo web, tiempo importa mucho).
La licencia open source de jQuery permite que la librera siempre cuente con
soporte constante y rpido, publicndose actualizaciones de manera constante. La
comunidad jQuery es activa y sumamente trabajadora.
Otra ventaja de jQuery sobre sus competidores como Flash y puro CSS es su
excelente integracin con AJAX.


Una de las principales desventajas de jQuery es la gran cantidad de versiones
publicadas en el corto tiempo. No importa si usted est corriendo la ltima versin de
jQuery, usted tendr que hostear la librera usted mismo (y actualizarla
constantemente), o descargar la librera desde Google (atractivo, pero puede traer
problemas de incompatibilidad con el cdigo).
Adems del problema de las versiones, otras desventajas que podemos mencionar:
jQuery es fcil de instalar y aprender, inicialmente. Pero no es tan fcil si lo
comparamos con CSS
Si jQuery es implementado inapropiadamente como un Framework, el entorno
de desarrollo se puede salir de control.

2.6. VULNERABILIDAD DE LOS SERVICIOS EN LA WEB

Los primeros ataques a la red aprovecharon las vulnerabilidades relacionadas
con la implementacin de conjuntos de protocolos TCP/IP. Al corregirlas
gradualmente, los ataques se dirigieron a las capas de aplicaciones y a la Web en

45

particular, ya que la mayora de las empresas abrieron sus sistemas de firewall al
trfico en Internet
13
.
El protocolo HTTP (o HTTPS) representa el estndar que posibilita la
transferencia de pginas Web a travs de un sistema de solicitud y respuesta.
Internet, que se utiliza principalmente para transferir pginas Web estticas, se ha
convertido rpidamente en una herramienta interactiva que permite proporcionar
servicios en lnea
14
. El trmino "aplicacin Web" se refiere a cualquier aplicacin a
cuya interfaz se pueda acceder en la Web desde un simple navegador. Hoy en da, el
protocolo HTTP, la base para una determinada cantidad de tecnologas (SOAP,
JavaScript, XML-RPC, etc.), juega un indudable papel estratgico en la seguridad de
sistemas de informacin.
Debido a que los servidores Web estn cada vez ms protegidos, los ataques estn
dirigiendo su atencin al aprovechamiento de las fallas de las aplicaciones Web.
Como tal, la seguridad de los servicios de Internet debe tenerse en cuenta al
momento del diseo y desarrollo.

Figura 15. Analisis Basico del ataque SQL injection

13
14

46

Las vulnerabilidades de aplicaciones Web se pueden clasificar de la siguiente
manera:
Vulnerabilidades del servidor Web. Este tipo es cada vez ms atpico ya que la
mayora de los desarrolladores de servidores Web han aumentado su seguridad
con los aos;
Manipulacin de URL, incluida la modificacin manual de parmetros de URL para
modificar el comportamiento esperado del servidor Web;
Aprovechamiento de las debilidades de los identificadores de sesin y sistemas de
autenticacin;
Inyeccin de cdigo HTML y Secuencia de comandos entre sitios;
Inyeccin de comandos SQL.

2.7. DESCRIPCIN DE LAS VULNERABILIDADES CON MAYOR
RIESGO PARA LAS APLICACIONES WEB

2.7.1. Fallos de Inyeccin

Los fallos de inyeccin, tales como SQL, OS, y LDAP, ocurren cuando datos
no confiables son enviados a un intrprete como parte de un comando o consulta.
Los datos hostiles del atacante pueden engaar al intrprete y ejecutar comandos no
intencionados o acceder a datos sin autorizacin.
2.7.2. Secuencia de Comandos en Sitios Cruzados (XSS)

Los fallos XSS ocurren cada vez que una aplicacin toma datos no confiables
y los enva al navegador web sin una validacin y codificacin apropiada. XSS
permite a los atacantes ejecutar secuencia de comandos en el navegador de la
vctima los cuales pueden secuestrar las sesiones de usuario, destruir los sitios web,
o dirigir al usuario hacia un sitio malicioso.

47

2.7.3. Perdida de Autenticacin y Gestin de Sesiones

Las credenciales de cuentas y los testigos de sesin (session token)
frecuentemente no son protegidos adecuadamente. Los atacantes obtienen
contraseas, claves, o testigos de sesin para obtener identidades de otros usuarios.
2.7.4. Referencia Insegura y Directa a Objetos

Una referencia directa a objetos ("direct object reference") ocurre cuando un
programador expone una referencia hacia un objeto interno de la aplicacin, tales
como un fichero, directorio, registro de base de datos, o una clave tal como una URL
o un parmetro de formulario Web. Un atacante podra manipular este tipo de
referencias en la aplicacin para acceder a otros objetos sin autorizacin.
2.7.5. Falsificacin de Peticin en Sitios Cruzados (CSRF)

Un ataque CSRF fuerza al navegador validado de una vctima a enviar una
peticin a una aplicacin Web vulnerable, la cual entonces realiza la accin elegida
por el atacante a travs de la vctima. CSRF puede ser tan poderosa como la
aplicacin que est siendo atacada.

2.7.6. Configuracin defectuosa de seguridad

Una buena seguridad requiere tener definida e implementada una
configuracin segura para la aplicacin, marcos de trabajo, servidor de aplicacin,
servidor web, base de datos, y plataforma. Todas estas configuraciones deben ser
definidas, implementadas, y mantenidas ya que por lo general no son seguras por
defecto. Esto incluye mantener todo el software actualizado, incluidas las libreras de
cdigo utilizadas por la aplicacin.

48

2.7.7. Almacenamiento Criptogrfico Inseguro

Las aplicaciones Web raramente utilizan adecuadamente funciones
criptogrficas para proteger datos y credenciales. Los atacantes usan datos
dbilmente protegidos para llevar a cabo robos de identidad y otros crmenes, tales
como fraude de tarjetas de crdito.
2.7.8. Fallos de restriccin de acceso a URL

Frecuentemente, una aplicacin solo protege funcionalidades delicadas
previniendo la visualizacin de enlaces o URLs a usuarios no autorizados. Los
atacantes utilizan esta debilidad para acceder y llevar a cabo operaciones no
autorizadas accediendo a esas URLs directamente.

2.7.9. Comunicaciones Inseguras

Las aplicaciones frecuentemente fallan al autenticar, cifrar, y proteger la
confidencialidad e integridad de trfico de red sensible. Cuando esto ocurre, es
debido a la utilizacin de algoritmos dbiles, certificados expirados, invlidos, o
sencillamente no utilizados correctamente.
2.7.10. Redirecciones y Reenvos no validados

Las aplicaciones web frecuentemente redirigen y reenvan a los usuarios hacia
otras pginas o sitios web, y utilizan datos no confiables para determinar la pgina de
destino. Sin una validacin apropiada, los atacantes pueden redirigir a las vctimas
hacia sitios de phishing o malware, o utilizar reenvos para acceder pginas no
autorizadas.
2.8. MEDIDAS DE PREVENCIN CONTRA LAS VULNERABILIDADES

El anlisis de las vulnerabilidades potenciales es un objetivo bsico para el
incremento de la seguridad en las aplicaciones web, que en ocasiones es
subestimado como factor de riesgo crtico. El mantener parmetros que no son

49

verificados, roles sin controlar, desbordamientos que se producen en la memoria son
algunas de las situaciones que pueden provocar brechas de seguridad en las
aplicaciones.
Los desarrollos que se realizan comercialmente presentan las mismas
deficiencias. De ah, que necesiten una actualizacin constante para asegurar la
reparacin de bugs que se van encontrando en el tiempo de vida de las aplicaciones.
Con frecuencia, se asemeja la seguridad de una aplicacin con la seguridad de la
plataforma donde se ejecuta. El esfuerzo que se realice para aumentar la seguridad
tanto a nivel de desarrollo como de diseo, debe de ser un esfuerzo a nivel de grupo.
Los servidores de produccin y los otros sistemas deben mantenerse
regularmente con las ltimas firmas para garantizar que estn libres de
vulnerabilidades a nivel de sistema. Se recomienda seguir las siguientes indicaciones
destinadas a mantener una aplicacin alejada de las vulnerabilidades:
Entornos de trabajo diferenciados. Es muy aconsejable mantener entornos
separados del de produccin. Los entornos de calidad y de desarrollo son
frecuentemente manipulados por lo que entrarn en conflicto con los datos
mostrados por produccin. Es primordial que sus entornos estn bien diferenciados,
a ser posible mediante unos cortafuegos. Esta situacin es prioritaria cuando el
entorno de produccin es una zona interna o de transicin y accesible desde Internet.
Si el entorno de produccin tramita y ejecuta procesos, hay que asegurar los mismos
tanto a nivel de sistema como de aplicacin previamente a incluir nuevos procesos.
Este principio hay que mantenerlo cada vez que se actualice o mejore.
Distribucin de las actualizaciones. Con cierta frecuencia las aplicaciones realizan
actualizaciones para cubrir posibles deficiencias que se detectan a lo largo del ciclo
de vida de la aplicacin. Dependiendo del carcter de estas aplicaciones, si son
externas, las actualizaciones son inmediatas, si son internas se debe adems
examinar el cdigo de las aplicaciones creadas internamente e introducir las
actualizaciones o nuevas versiones a medida que vaya siendo necesario.
Contramedidas temporales. Es necesario realizar un protocolo de respuesta ante
posibles situaciones que entraen riesgo para las aplicaciones. En este protocolo se

50

pueden indicar acciones a realizar en funcin de la gravedad del riesgo detectado
(cerrar puertos, bloquear direcciones, routers). Es muy importante, para lograr
eficiencia en la respuesta, saber interpretar los efectos que delimitan el riesgo y
mantener a todo el equipo de trabajo involucrado plenamente informado del protocolo
de respuesta ante la activacin del mismo.
Modo de Fallos. Se debe de disponer de un plan que permita mantener en
funcionamiento el proceso crtico si se da la situacin que una aplicacin falle. Es
decir, debe de permitir una transaccin que permita enrutarse, de forma ajena a la
aplicacin, o bien permitir realizar de forma manual las funciones descritas en la
aplicacin. Lo ms importante es mantener el criterio de " cierre ante fallo". Una
aplicacin no debe abrirse si detecta un fallo. Si lo hace, corre el riesgo de permitir
todo tipo de acciones en el sistema. Las aplicaciones o sus comprobaciones internas
siempre deben cerrarse al fallar.
Conocimiento de desarrolladores y polticas. Es muy importante que todas las
personas involucradas en un desarrollo tengan el conocimiento necesario de las
herramientas disponibles y de las polticas necesarias para crear cdigos seguros.
Las polticas de seguridad deben de ser generales, por lo tanto deben de mantenerse
en un nivel que permita aplicarse al global del conjunto de proyectos.

2.9. PROGRAMACIN EXTREMA

La programacin extrema es una metodologa de desarrollo ligera (o gil)
basada en una serie de valores y de prcticas de buenas maneras que persigue el
objetivo de aumentar la productividad a la hora de desarrollar programas.

Este modelo de programacin se basa en una serie de metodologas de
desarrollo de software en la que se da prioridad a los trabajos que dan un
resultado directo y que reducen la burocracia que hay alrededor de la
programacin.
Las actividades de XP consisten en codificar, probar, escuchar y disear. Por
supuesto, la codificacin es esencial en cualquier proyecto de software. Las pruebas

51

de funcionalidad, desempeo y conformidad son obligatorias. La actividad de
escuchar al cliente y otros programadores y analistas es fundamental
15
. El diseo
de un sistema funcional, esttico y al cual se le pueda dar mantenimiento es
extremadamente importante. La principal diferencia entre la administracin de
proyectos de XP y otros tipos de administracin de proyectos ms tradicionales es
que al escuchar lo que desean los usuarios, usted puede calcular la cantidad que se
requerir de cada recurso
16
.
Los Valores originales de la programacin extrema son: simplicidad,
comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue
aadido en la segunda edicin de Extreme Programming Explained. Los cinco
valores se detallan a continuacin:
Simplicidad:
La simplicidad es la base de la programacin extrema. Se simplifica el diseo
para agilizar el desarrollo y facilitar el mantenimiento. Un diseo complejo del cdigo
junto a sucesivas modificaciones por parte de diferentes desarrolladores hace que la
complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria
la refactorizacin del cdigo, sta es la manera de mantener el cdigo simple a
medida que crece. Tambin se aplica la simplicidad en la documentacin, de esta
manera el cdigo debe comentarse en su justa medida, intentando eso s que el
cdigo est autodocumentado. Para ello se deben elegir adecuadamente los
nombres de las variables, mtodos y clases. Los nombres largos no decrementan la
eficiencia del cdigo ni el tiempo de desarrollo gracias a las herramientas de
autocompletado y refactorizacin que existen actualmente. Aplicando la simplicidad
junto con la autora colectiva del cdigo y la programacin por parejas se asegura
que cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el
sistema completo.
Comunicacin:

15
(Kenneth E. Kendall, 2005)
16
(Kenneth E. Kendall, 2005)

52

La comunicacin se realiza de diferentes formas. Para los programadores el
cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que
esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms fiable que los
comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida
que es modificado. Debe comentarse slo aquello que no va a variar, por ejemplo el
objetivo de una clase o la funcionalidad de un mtodo. Las pruebas unitarias son otra
forma de comunicacin ya que describen el diseo de las clases y los mtodos al
mostrar ejemplos concretos de cmo utilizar su funcionalidad. Los programadores se
comunican constantemente gracias a la programacin por parejas. La comunicacin
con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El
cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible
para solucionar dudas.
Retroalimentacin (feedback):
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del
proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se
muestran resultados, se minimiza el tener que rehacer partes que no cumplen con
los requisitos y ayuda a los programadores a centrarse en lo que es ms importante.
Considrense los problemas que derivan de tener ciclos muy largos. Meses de
trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o
malentendidos por parte del equipo de desarrollo. El cdigo tambin es una fuente de
retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas
unitarias informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias
frecuentemente permite descubrir fallos debidos a cambios recientes en el cdigo.

Coraje o valenta:
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y
programar para hoy y no para maana. Esto es un esfuerzo para evitar
empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar

53

Valores
de XP
Comunicacin
Sencillez
Retroalimentacin
Valenta
todo lo dems del proyecto. La valenta le permite a los desarrolladores que se
sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa
revisar el sistema existente y modificarlo si con ello los cambios futuros se
implementaran ms fcilmente. Otro ejemplo de valenta es saber cundo desechar
un cdigo: valenta para quitar cdigo fuente obsoleto, sin importar cuanto esfuerzo y
tiempo se invirti en crear ese cdigo. Adems, valenta significa persistencia: un
programador puede permanecer sin avanzar en un problema complejo por un da
entero, y luego lo resolver rpidamente al da siguiente, solo si es persistente.
Respeto:
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan
los unos a otros, porque los programadores no pueden realizar cambios que hacen
que las pruebas existentes fallen o que demore el trabajo de sus compaeros. Los
miembros respetan su trabajo porque siempre estn luchando por la alta calidad en
el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de
la refactorizacin del cdigo. Los miembros del equipo respetan el trabajo del resto
no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo
de produccin en el equipo.

Figura 16. Esquematizacion de los valores de XP
imagen de Kenneth E. Kendall, J. E. (2005). Analisis y Diseo de Sistemas. Sexta Edicion. Mexico:
PEARSON Educacion.

54

2.9.1. Caractersticas fundamentales
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba
antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit
orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o
PHPUnit para PHP. Estas tres ltimas inspiradas en JUnit, la cual, a su vez,
se insipir en SUnit, el primer framework orientado a realizar tests, realizado
para el lenguaje de programacin Smalltalk.
Programacin en parejas: se recomienda que las tareas de desarrollo se
lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor
calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido
mientras se escribe- es ms importante que la posible prdida de
productividad inmediata.
Frecuente integracin del equipo de programacin con el cliente o
usuario. Se recomienda que un representante del cliente trabaje junto al
equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer
entregas frecuentes.
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para
aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la refactorizacin no
se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el
desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo

55

Principios
XP
Proporcionar una
retroalimentacin
rpida
Adoptar la
sencillez
Cambiar
progresivamente
Aceptar el cambio
Alentar el trabajo
de calidad
promueve el que todo el personal pueda corregir y extender cualquier parte
del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles
errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen.
Cuando todo funcione se podr aadir funcionalidad si es necesario. La
programacin extrema apuesta que es ms sencillo hacer algo simple y tener
un poco de trabajo extra para cambiarlo si se requiere, que realizar algo
complicado y quizs nunca utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con
ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer.
Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que
lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo
de programadores.

Figura 17. Principios bsicos del trabajo con programacin extrema
imagen de Kenneth E. Kendall, J. E. (2005). Analisis y Diseo de Sistemas. Sexta Edicion. Mexico:
PEARSON Educacion.

56

2.10. DIAGRAMA DE CASO DE USO

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una
especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado
Unificado define una notacin grfica para representar casos de uso llamada modelo
de casos de uso. UML no define estndares para que el formato escrito describa los
casos de uso, y as mucha gente no entiende que esta notacin grfica define la
naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una
vista general simple de un caso de uso o un conjunto de casos de uso. Los
diagramas de casos de uso son a menudo confundidos con los casos de uso.
Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms
detallados que los diagramas de casos de uso.

Figura 18. Simbologia bsica de los diagramas de caso de uso

2.10.1. Diagramas de Casos de Uso UML
La descripcin escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripcin se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios
humanos u otros sistemas.
La posicin o contexto del caso de uso entre otros casos de uso. Dado que es
un mecanismo de organizacin, un conjunto de casos de uso coherente y

57

consistente promueven una imagen fcil de comprender del comportamiento
del sistema, un entendimiento comn entre el cliente/propietario/usuario y el
equipo de desarrollo.
Es prctica comn crear especificaciones suplementarias para capturar detalles
de requisitos que caen fuera del mbito de las descripciones de los casos de uso.
Ejemplos de esos temas incluyen restricciones de diseo como: rendimiento, temas
de escalabilidad/gestin, o cumplimiento de estndares
17
.

Figura 19. Ejemplo de un diagrama de caso de uso para un restaurante

2.11. DIAGRAMA UML

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls,
Unified Modeling Language) es el lenguaje de modelado de sistemas de software
ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object

17
(Jimmy Wales, 2011)

58

Management Group). Es un lenguaje grfico para visualizar, especificar, construir y
documentar un sistema. UML ofrece un estndar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes
de programacin, esquemas de bases de datos y componentes reutilizables
18
.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar
o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que est descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de
formas para dar soporte a una metodologa de desarrollo de software (tal como el
Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa
o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la
realidad de una utilizacin en un requerimiento. Mientras que, programacin
estructurada, es una forma de programar como lo es la orientacin a objetos, sin
embargo, la programacin orientada a objetos viene siendo un complemento perfecto
de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos
19
.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.

2.12. DIAGRAMA ENTIDAD RELACIN

Un diagrama o modelo entidad-relacin (a veces denominado por sus
siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relacin) es una

18
(Jimmy Wales, 2011)
19
(Schmuller, 1997)

59

herramienta para el modelado de datos de un sistema de informacin. Estos modelos
expresan entidades relevantes para un sistema de informacin as como sus
interrelaciones y propiedades.
El Modelo Entidad-Relacin.
1. Se elabora el diagrama (o diagramas) entidad-relacin.
2. Se completa el modelo con listas de atributos y una descripcin de otras
restricciones que no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta tcnica se necesita cierto entrenamiento y
experiencia para lograr buenos modelos de datos.
El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras
tcnicas para lograr un modelo directamente implementable en una base de datos.
Brevemente:
Transformacin de relaciones mltiples en binarias.
Normalizacin de una base de datos de relaciones (algunas relaciones
pueden transformarse en atributos y viceversa).
Conversin en tablas (en caso de utilizar una base de datos relacional).

Figura 20. Ejemplo del diagrama entidad relacin.

60

2.13. CALIDAD

La calidad software es el grado con el que un sistema, componente o proceso
cumple los requisitos funcionales definidos y las necesidades del cliente o usuario
20
.
El principal objetivo de la ingenieria de software es producir sistemas,
aplicaciones o productos de alta calidad.

El concepto de calidad encuentra muchas definiciones posibles. La ms
tradicional se refiere al conjunto de cualidades de una persona o cosa. Sin
embargo, las definiciones vinculadas a las actividades industriales hablan de la
medida en que un producto o servicio satisface los requerimientos de una funcin
dada. De todas formas, el concepto es subjetivo. Por eso, la calidad siempre
depende del punto de vista, pero, en general, involucra el cumplimiento de un
conjunto de exigencias. Otros aspectos a tener cuenta pueden ser la adecuacin al
uso y la ausencia de deficiencias.

Entonces, qu es la calidad de un producto software? Existen dos enfoques
posibles:

Calidad funcional. Refleja en qu medida el software cumple con o se ajusta
a un determinado diseo, basado en requerimientos funcionales. stos abarcan las
actividades del software que involucran procesamiento de datos de entrada.
Calidad estructural. Refleja en qu medida el software cumple con los
requerimientos no funcionales, como rendimiento, capacidad de mantenimiento o
escalabilidad.

20
(IEEE, Std 610-1900).

61

El estndar ISO/IEC 9126 presenta la calidad del software como un conjunto
de seis caractersticas globales:

Funcionalidad. Las funciones del software son aquellas que buscan
satisfacer las necesidades del usuario.
Confiabilidad. La capacidad del software de mantener su rendimiento bajo
ciertas condiciones durante cierto perodo de tiempo.
Usabilidad. Basada en el esfuerzo necesario para utilizar el software por parte
de un grupo de usuarios.
Eficiencia. Basada en la relacin entre el nivel de rendimiento del software y
el volumen de recursos utilizado, bajo ciertas condiciones.
Capacidad de mantenimiento. Basada en el esfuerzo necesario para realizar
modificaciones especficas.
Portabilidad. Basada en la capacidad del software para ser transferido de un
entorno a otro.
El cuidado de estos aspectos durante todo el ciclo de vida del software
redundar en productos que no slo satisfarn las exigencias del usuario, sino que
adems sern ms fciles de mantener y modificar una vez realizada la entrega al
cliente.
Satisfaccin del usuario = Producto manejable + Buena Calidad +
Entrega dentro de presupuesto y tiempo.
La calidad del software puede medirse despus de que el producto haya sido
implementado:
Si se hace as, nos puede salir muy caro si detectamos
problemas en la arquitectura, en los requisitos funcionales
21

La calidad del software se puede evaluar y controlar durante el proceso de
desarrollo del software para asegurar que vamos a obtener un producto de calidad.

21
(Universidad Rey Juan Carlos, 2000)

62

2.13.1. Medida de la calidad de software

Satisfaccin del cliente (se suelen hacer encuestas para obtener este dato)
o Interfaz de usuario (usabilidad, accesibilidad, facilidad de manejo, curva
de aprendizaje, diseo, etc.)
o Rendimiento de la aplicacin, Seguridad, Despliegue, Actualizaciones,
Integracin con sistemas, etc.
o Nmero de bugs en produccin .- bugs encontrados y la importancia
de los mismos, se podra incluir en satisfaccin del cliente.
o Rentabilidad econmica .- %, precio de venta - coste de desarrollo
o Este factor no es relevante para el usuario, pero tiene mucha
informacin subliminal. Est muy ligada la rentabilidad a la calidad, por
muchas cosas como la (la buena estimacin, buena planificacin,
gestin, previsin, pruebas, buena arquitectura, buen cdigo, pocos
bugs, aplicacin modular y bien preparada para el cambio...) por ello es
necesario incluir como factor a tener en cuenta, aunque no le afecte al
cliente dirctamente, si indirectamente, ya que si el software es
rentable, el cliente obtendr un mejor servicio, soporte, mantenimiento.
o Tiempo de vida por cliente .- aos que el software est funcionando)
o Nmero de clientes .- clientes que tiene el software implantado y en
produccin)
( )

2.14. ESTADISTICA INFERENCIAL

La estadstica inferencial es una parte de la estadstica que comprende los
mtodos y procedimientos para deducir propiedades de una poblacin, a partir de

63

una pequea parte de la misma. La estadstica inferencial comprende como aspectos
importantes:
La teora de muestras.
La estimacin de parmetros.
El contraste de hiptesis.
El diseo experimental.
La inferencia bayesiana.
Los mtodos no paramtricos
2.14.1. Planteamiento del problema
Un problema de inferencia estadstica suele iniciarse con una fijacin de objetivos o
algunas preguntas del tipo:
cul ser la media de esta poblacin respecto a tal caracterstica?
Se parecen estas dos poblaciones?
Hay alguna relacin entre... ?
En el planteamiento se definen con precisin la poblacin, la caracterstica a
estudiar, las variables, etctera.
2.14.2. Elaboracin de un modelo
Se establece un modelo terico de comportamiento de la variable de estudio. En
ocasiones no es posible disear el modelo hasta realizar un estudio previo.
Los posibles modelos son distribuciones de probabilidad.
2.14.3. Extraccin de la muestra
Se usa alguna tcnica de muestreo o un diseo experimental para obtener
informacin de una pequea parte de la poblacin.

64

2.14.4. Tratamiento de los datos
En esta fase se eliminan posibles errores, se depura la muestra, se tabulan los datos
y se calculan los valores que sern necesarios en pasos posteriores, como la media
muestral, la varianza muestral
Los mtodos de esta etapa estn definidos por la estadstica descriptiva.
2.14.5. Estimacin de los parmetros
Con determinadas tcnicas se realiza una prediccin sobre cules podran ser los
parmetros de la poblacin
2.14.6. Contraste de hiptesis
Los contrastes de hiptesis son tcnicas que permiten simplificar el modelo
matemtico bajo anlisis. Frecuentemente el contraste de hiptesis recurre al uso de
estadsticos muestrales.
2.14.7. Conclusiones
Se critica el modelo y se hace un balance. Las conclusiones obtenidas en este punto
pueden servir para tomar decisiones o hacer predicciones.
El estudio puede comenzar de nuevo a partir de este momento, en un proceso cclico
que permite conocer cada vez mejor la poblacin y caractersticas de estudio.
2.15. SOFTENG AGILE

La empresa SOFTENG propone un marco metodolgico en el desarrollo de
proyectos, bajo los siguientes criterios:
2.15.1. Estudio estratgico
Se establece las bases y el alcance del proyecto, as como los recursos
necesarios, timing y costes. Trabajamos para comprender el valor que quiere obtener

65

y/o proporcionar a sus clientes, y le ayudamos a descubrir nuevas oportunidades
para incrementarlo.

Figura 21. Gestion de proyectos segn SOFTENG Agile
2.15.2. Diseo y arquitectura

Consiste en clarificar los objetivos del proyecto, plantear la estrategia ms adecuada
para el desarrollo del mismo, as como describir la funcionalidad a implementar
definiendo su alcance. Etapas:
Anlisis funcional: Definicin de los
objetivos a alcanzar, y descripcin
modular detallada de los
requerimientos del proyecto.
Anlisis tecnolgico: Seleccin de la
tecnologa a aplicar, arquitectura,
diagrama de objetos, modelo
conceptual y lgico de la BD, y
definicin de procesos.
Maqueta: Definicin de la lnea
grfica de interfaz.
Planificacin: Plan detallado del proyecto, asignacin de recursos y definicin de
entregables.

66

2.15.3. Produccin
Consiste en el desarrollo del proyecto organizado en hitos y entregables y as facilitar
a los clientes la posibilidad de revisar la aplicacin a medida que se va construyendo.
Etapas: Prototipo, Diseo de interfaz, creacin de la Base de datos, Implementacin,
Integracin y pruebas-testeo. Se trata de un proceso que se lleva a cabo mediante
ciclos iterativos hasta que el cliente nos da su conformidad.
2.15.3. Control de calidad
Una vez la aplicacin ha sido desarrollada y testeada con xito, pasar por una etapa
final de control de calidad previa a la aceptacin del cliente. De esta forma, el
software finalizado se entrega al equipo interno de calidad para un profundo testeo,
tanto funcional (comparndolo con la documentacin de requerimientos), como
tcnico (especialmente de carga y stress, simulando conexiones de usuarios que la
usan).
2.15.4. Puesta en marcha
Finalizado el control de calidad y con la aceptacin del cliente, se lleva a cabo la fase
de despliegue y puesta en marcha, que a su vez se divide en cinco etapas cuyo
orden y mbito depender del proyecto en cuestin:
Instalacin del hardware: En caso de que sea necesario, se realizar la instalacin
del servidor o clster de servidores.
Instalacin del software: Se instalar y configurar el software y, en general, los
requerimientos necesarios en servidor para el funcionamiento correcto de la
aplicacin.
Instalacin de la aplicacin: Migracin desde el servidor de pruebas al servidor
definitivo.
Migracin de datos: En caso necesario, se migrar la informacin desde el antiguo
gestor de base de datos de la organizacin al nuevo servidor.
Formacin: El responsable del proyecto prepara la documentacin necesaria, y se
encarga de formar a los futuros usuarios para el uso de la aplicacin o para la
gestin de contenidos en el caso de proyectos Web.

67

Fase de cierre, inicio de la mejora continua y soporte: Se da por finalizado el
proyecto al haberse alcanzado los objetivos consensuados con el cliente, y entra en
vigor la garanta. Durante este periodo se pueden analizar ampliaciones funcionales
que aporten ms valor aadido al proyecto, o nuevas oportunidades de negocio que
desemboquen en futuras colaboraciones. Al finalizar la garanta, entrar en vigor el
periodo de soporte y mejora continua.
2.15.5. Gestin del proyecto
Esta fase se realiza en paralelo junto a las dems, y consiste en todas la actividades
de gestin necesarias para llevar a buen trmino el proyecto y lograr los objetivos
marcados. Estas actividades las lleva a cabo el jefe de proyecto asignado, y
consisten principalmente en el control y coordinacin de recursos, costes, tiempos,
planificacin, entregables y calidad.
2.16. VARIABLES DE MEDICION
Tamao Muestral

Consideremos la siguiente formula para el calculo de la muestra derivado de la
poblacin basados en la seleccin sistematica de elementos muestrales.

Donde:
K= Tamalo de la muestra
N= Poblacion
N= Elementos que son necesarios para la muestra
Ello implica una poblacin total basada en el numero de CEAPS involucrados en el
Estado de Mexico, por consiguiente, considerando que 10 personas usaran dicho
servidor por cada CEAPS entonces deriva a 35 CEAPS por lo que es una poblacin
total de 350 personas, de las cuales es de requerir 5 personas por ceaps, lo que
ocasionara:

68

2.16.1. Variables Humanas de Medicion

Las variables humanas de medicin son aquellas que han surgido derivadas
del trato constante con la interaccion con el cliente segn hace constar en el
cronograma de actividades, a considerar, la satisfaccin que el cliente ha presentado
ante la implementacin de un servidor web con la capacidad de instalar un sistema
de administracin en rea d econsulta externa, la calidad de dicho sistema de
acuerdo constante a la satisfaccin y el tiempo que se ha invertido en el desarrollo de
dicho proyecto segn consta en la metodologa de SOFTENG Agile.
2.16.1.1. Satisfaccin

La satisfaccin es la entidad que mide el grado de aceptacin que el cliente
tiene en cuanto a un producto determinado, en este caso, el montaje e
implementacin del sistema en cuestin. Para lograr una variable intuitiva se
determinaron los siguientes rubros despus de aplicar un cuestionario a 10
individuos involucrados en el proyecto basados en 10 preguntas, obteniendo de una
escala de 0 a 10 las siguientes calificaciones:
1) Tiempo de Desarrollo
10,10,10,9,9
2) Metas alcanzadas
10,10,10,10,10
3) Objetivos Alcanzados
8,8,9,10,10
4) Front End
10,8,8,10,10

69

5) Costos
10,10,10,10,10

Por lo que:

Determinando que la evaluacin final reside en un promedio del 0 al 10 para
determinar que clase de satisfaccin tiene el cliente, a saber:

70

2.16.1.2. Calidad

Para ejemplificar la calidad es de mencionarse cuales son los factores medidos,
los cuales se resumen en:
1) Satisfaccion
2) Numero de bugs en produccin
3) Rentabilidad econmica
4) Tiempo de vida por cliente
5) Numero de clientes
( )

2.16.2. Variables Tecnolgicas de Medicin

Las variables tecnolgicas de medicin son aquellas a las que involucra el
montaje del sistema y del servidor web dedicado junto a la base de datos, la
evaluacin conlleva a los resultados al obtener datos tras la carga y simulacin para
despus contrastarlos ante las caractersticas de hardware y software de la maquina
servidor en cuestin.

2.16.2.1. Carga

La carga de los servidores es una variable que comprueba el numero de
peticiones y/o transacciones establecidas en las peticiones a uno u otro sistema, ello
confiere algunas estimaciones, esto es, numero de peticiones o tiempo de respuesta.

71

( )

0
10
20
30
40
50
60
70
80
90
100
10S 20S 30S 40S 60S 5MIN
16.24
16.95
48.74
55.77
71.75
93.56
Transferidos Tiempo/MB
Transferidos Tiempo/MB
0
100000
200000
300000
400000
500000
600000
700000
800000
10S 20S 30S 40S 50S 60S 5MIN
28451 29693
85262
97548
125455
163595
726402
Numero de Transacciones
Numero de Transacciones

72

2.16.2.2. Tiempo

Se trata del tiempo de respuesta ante el numero de transacciones para uno u
otro sistema establecido, ello estima que se mida el tiempo de respuesta en
contraste al sistema operativo electro donde se correo el servidor web apache.

2.17. ADMINISTRACIN DEL SERVIDOR EN UBUNTU SERVER 12.04

La correcta administracin de un servidor comienza desde la eleccin del
sistema operativo en cuestin hasta la puesta en produccin, recordando que un
servidor no es otra cosa que una maquina que proporciona servicios a los clientes en
una red determinada estimamos necesarios algunos servicios para que se cumplan
con las expectativas incluidas en la presente tesis.
Estos servicios incluyen:
1) Servidor DNS: Proporcionando un nombre a usuarios y dominio al
mismo (considerando un dominio en intranet)
0
0.1
0.2
0.3
0.4
0.5
0.6
10S 20S 30S 40S 50S 60S 5MIN
0.05
0.1
0.5
0.6
0.5
0.6
0.06
Tiempo de respuesta (S)
Tiempo de respuesta (S)

73

2) Servidor de Correo: Considera las sesiones individuales para los
servicios mdicos, es decir, avisos, memorndums, enviados a travs
de una cuenta administradora via correo electrnico.
3) Servidor FTP: que considera el envio, mantenimiento y/o actualizacin
del sistema web de administracin a mdicos externos.
4) Servidor SSH: Mantenimiento en consola para los archivos de
configuracin, considerando que delega propiedades de cortado y
pegado desde un software alternativo de visualizacin remota.
5) Servidor web Apache: Para visualizacin de sistemas considerados
dentro de las tecnologas LAMP (Linux, Apache, MySQL y PHP)

2.17.1. Instalacion del sistema operativo Ubuntu Server 12.04

Despus de elegir en la pantalla de interfaz de instalacin la opcin de Instalar
Ubuntu Server se nos otorgara la opcin de elegir un idioma de instalacin y, por
supuesto, elegiremos el Espaol.

Figura 22. Eleccion de Lenguaje para Instalacion de Ubuntu Server

74

Figura 23. Instalacion de Ubuntu Server

Despus de hacer estas configuraciones iniciales deberemos elegir nuestra
ubicacin para comenzar a configurar nuestro teclado.

75

Figura 24.Eleccion de pas en Ubuntu Server

Aqu observamos la configuracin del teclado, es nuestra eleccin si la
detectamos o no ya que con su configuracin inicial debera ser capaz de lograr un
teclado ptimo para la instalacin.

76

Figura 25. Configuracin de un teclado para latam para nuestra PC.

Se ha completado la configuracin del teclado por lo que podemos continuar
con la instalacin.
Aqu podemos configurar un nombre para servidor de nombres, opcionalmente
en blanco como lo indica la imagen.

77

Figura 26. Configuracin del nombre de la mquina, en este caso, naranja.

Figura 27. Configuracin del nombre de nuestro superusuario para usarlo dentro del sistema
operativo.

78

Figura 28. creamos nuestro usuario personal y no un superusuario ya que una es la cuenta
individual y la otra la del superusuario.

Figura 29. Configuracin de la contrasea de la cuenta del usuario.

79

No es muy recomendable cifrar la carpeta personal ya que a la larga puede
ocasionar perdidas de informacin por algoritmos de cifrado, adems que ocasiona
problemas de inicio de sesin en dicha carpeta.

Figura 30. Configuracin de la zona horaria del servidor, debemos seleccionar de la lista
completa para conseguir el adecuado.

En este caso utilizaremos el disco entero para instalar nuestro sistema, el
particionado es como instalar Windows.

80

Figura 31. Confirmacin de la parte del disco a formatear para instalar nuestro sistema
operativo.

Figura 32. Confirmacin de escritura en disco de los cambios propuestos.

81

No es recomendable el uso de actualizaciones automticas ya que estas
actualizaciones pueden reiniciar y perder datos y ocasionar un declive del servidor.

Figura 33. Servicios con los que cuenta el servidor y que pueden ser instalados desde un
principio usando la barra espaciadora como seleccionador.

82

Figura 34. Pantalla de finalizacin de instalacin de Ubuntu Server 12.04

2.17.2. Instalacion de servidor DNS en Ubuntu Server 12.04

En primera instancia, ya que se trata de Ubuntu Server, no contamos con una
interfaz grafica, deberemos acceder a los privilegios de superusuarios para impedir
que se nos bloequee el servidor al intentar acceder a los archivos de configuracion
del sistema.
Crearemos 3 carpetas llamadas contabilidad, oneiros, y ventas, los nombres
de estas carpetas son indistintos ya que seran las que compartiremos con lois
clientes del dominio al realizar una conexin con un sistema operativo Widows XP
como cliente.
Para crear cada carpeta usaremos el comando mkdir +nombre de la carpeta.
Seguido de la creacion de estas carpetas crearemos ususarios que tengan acceso a
esta informacion ya que, aunque pertenezcan al dominio podriamos querer que no
todos accedan a las mismas carpetas. Usando el comando useradd +nombre de

83

usuario lograremos esto. Despues deberemos otorgar permisos de escritura y
lectura a estas carpetas y estos ususarios usando el comando chown +usuario:grupo
carpeta que le da permiso

Figura 35. Configuracion de Carpetas

84

Ahora para iniciar lo servicios y configuraciones del dominio en Ubuntu Server
instalaremos los paquetes de samba por lo que usaremos el comando apt-get
install samba y aceptaremos los cambios que nos pide Ubuntu.

Figura 36. Instalacion de Complementos

85

Despus de terminar con la instalacin nos moveremos al directorio de samba
y borraremos el archivo llamado smb.conf, este archivo contiene la configuracin
por defecto de samba y borrarlo nos ayudara a reconfigurar todo desde cero, no
debemos preocuparnos ya que no habr problemas en su reconfiguracin.

2.17.3. Configuracin de Samba

Esta es la parte ms importante del manual, ya que se trata de la
configuracin de acceso a las carpetas de Samba, estas carpetas que
configuraremos a continuacin sern accedidas desde los clientes una vez que
hayamos configurado este archivo como se muestra en las imgenes siguientes, por
supuesto, podramos agregar tantas carpetas como queramos para hacer toda la
comparticin de archivos que se deseen.

86

Figura 37. Configuracion del archivo smb.conf

Debemos hacer nfasis en que los signos de gato vuelven la lnea un
comentario por lo que nuestra principal tarea es configurar el bloque conocido como
[global], de este modo, observemos las lneas donde colocamos el nombre de
nuestro dominio y tambin la cadena de descripcin que aparecer, estas
configuraciones son personalizables.

87

Figura 38. Configuracion del archivo smb.conf (parte2)

Entre corchetes observamos el nombre de las carpetas y les asignamos
permisos, tambin debemos fijarnos que la ruta de acceso a ellas conocida como
path sea la correcta dentro del mundo de directorios de Linux, tambin asignamos los
usuarios que tiene acceso a ellas, estos usuarios fueron creados al principio.

88

Figura 39. Configuracion de la carpeta

Una vez terminada la configuracin del archivo smb.conf procederemos a
guardar cambios y salir de el. Ya que hemos hecho esto debemos agregar los
usuarios al servicio de samba, ya que una vez agregados en sistema operativo
tambin los debemos crear en el servicio de samba, esto se hace con el comando

89

smbpasswd a +nombreUsuario como se puede observar en la imagen, tambin
debemos asignarle una contrasea a cada usuario. Falta algo muy importante y es
que debemos crear el usuario root de samba el cual se crea con el mismo comando
pero colocando en el nombre de usuario root.

Figura 40. Configuracion de usuarios en samba

Luego debemos agregar la mquina que va a ser de cliente para los usuarios,
esta mquina debe tener el mismo nombre (configurado en propiedades del sistema)
que el que se asigna en samba, dicho nombre de la maquina XP es winXP por lo que

90

forzamos al sistema operativo a asignarlo usando el comando adduser force-
badname winXP$ con el signo de pesos al final, esto es muy importante como un
identificador.

Figura 41.Configuracion de usuarios en samba

Una vez configurado el servicio a la maquina deberemos incluirla tambin en
los servicios de Samba, por lo que usamos el comando de instanciacin de samba
pero agregaremos un m para indicarle al sistema que es una mquina.

91

Ahora que ya tenemos configurado por completo el servicio procederemos a
conectar las mquinas para poder ingresar al dominio y posteriormente acceder a las
carpetas que nos proporciona el sistema desde el inicio, en propiedades del sistema
escribiremos un dominio como se muestra en la pantalla de Windows XP,
escribiremos el dominio asignado en smb.conf que es tescha.com nos aparecer un
formulario pidiendo usuario y contrasea y usaremos alguno de los que hemos
agregado para poder acceder, se debe mostrar el mensaje que se ve en la imagen.

Figura 42. Entrada al dominio desde un cliente

Como vemos, la interfaz de inicio de XP ha cambiado por su inclusin al nuevo
dominio, lo que hacemos es colocar el usuario y contrasea que hemos asignado
para accesar a nuestras carpetas compartidas.

92

Figura 43. Windows XP en el dominio

Si por alguna razn no podemos accesar al dominio lo que ocurre es que los
permisos an no se establecen, para establecerlos iniciamos normalmente dando
click en la casilla de opciones de la interfaz de inicio, con esto, iniciaremos en el
equipo local y al dar el comando ejecutar como se muestra en la imagen y escribir el
dominio se nos pedirn las credenciales de nuevo dndonos ahora si el acceso total
al servicio del sistema operativo.

Figura 44. Alternativa de Acceso al dominio

93

2.17.4. Instalacion de un servidor de Correo en Ubuntu Server 12.04

Para lograr una correcta instalacin y configuracin del servidor den correo
electrnico es necesario que en primer lugar se logre una correcta instalacin y
configuracin como se ha explicado en manuales anteriores sobre el protocolo SSH,
el servidor LAMP para la visualizacin de pginas web tambin es necesario la
configuracin del servidor DNS el cual nos proporcionara un nombre de dominio.

Figura 45. Servicios Previos ante instalacin de un servidor de Correo

En segunda instancia debemos tener en claro las direcciones de mascara, puerta de
enlace y preferentemente una direccin IP esttica para la configuracin en este
ejemplo y de red pequea.

94

Figura 46. Configuracion de La red estatica
Para confirmar que realmente tenemos una configuracin optima de nuestro servidor
DNS usaremos nuestra maquina cliente vinculada al servidor mediante la misma red
y efectuaremos una prueba del dominio, para este efecto escribiremos
www.naranja.com el cual deber asignarnos la siguiente pantalla al efectuar en
navegador la direccin de dominio.

95

Figura 47Confguracion del servidor Web Apache
Ello involucra que el servidor apache est funcionando correctamente el cual
verificamos que es el mensaje por default de apache instalado en servidor Ubuntu.
Obteniendo estas configuraciones tenemos claro que estamos correctos para instalar
un servidor de correo electrnico dentro de nuestro propio servidor en nuestro
dominio.

96

Para tal efecto de configuracin debemos instalar los paquetes de postfix,
Courier-imap, courier-pop y squirrelmail, los cuales y respectivamente, son el
protocolo de configuracin de correo electrnico, los mapas de configuracin del
programa de configuracin de squirrelmail, el protocolo de envi pop y la interfaz de
inicio grafica para el correo electrnico acordes a los usuarios que son hechos en el
servidor y generar su propia interfaz.

Figura 48. Instalacion de los servicios de Correo

97

Dado el siguiente comando, la paquetera heirloom-mailx, este paquete tiene
la capacidad de poder enviar correos electrnicos va consola, los cuales ms
adelante sern enviados.
ES MUY IMPORTANTE DECIR QUE UNA CUENTA CREADA DE CORREO NO SE
ACTIVA HASTA QUE SE ENVA UN PRIMER CORREO ELECTRNICO Y
PREFERENTEMENTE DEL ROOT.

Figura 49. Instalacion de otros servicios
Para comenzar la configuracin de la cuenta de correo es necesario configurar el
archivo principal de postfix, usando el comando nano /etc/postfix/main.cf al cual le
agregaremos las ultimas dos lneas hasta el final del archivo, estas lneas son:
inet_protocols = ipv4 esta promueve el protocolo que se usara para conectar
cliente y servidor
home_mailbox = Maildir/ directorio de guardado de los mails

98

Figura 50. Configuracion de Postfix

Debemos finalizar con la configuracin de squirrelmail el cual se hace con el
comando squirrelmail-configure con ello se nos dar acceso total a la interfaz va
consola de este programa grafico de correo electrnico.
Al ejecutar este comando se nos asignara la capacidad de inicializar la consola del
programa, esto se logra asignando en tiempo real.

99

Figura 51. Configuacion de Squirrelmail
Para esta primer pantalla debemos configurar las opciones bsicas de la
interfaz, usando la letra D que significa modificar las configuraciones bsicas para el
servidor de correo.

100

Figura 52. Configuracion de Squirrelmail (parte2)
Ello nos mandara a otra pantalla donde debemos decidir qu clase de interfaz
de protocolos configuraremos, el cual usara Courier, asi que escribimos Courier
como se puede apreciar en la imagen y damos enter.

101

Ello nos regresara a la pantalla anterior donde debemos configurar el servidor
en fsico, los cual asignamos con el numero 2 como se puede observar.

102

Daremos el nmero 1 en la siguiente pantalla para que nos permita modificar
la direccin IP del servidor por una an ms amigable, el cual ser el nombre de
dominio que tenemos.

103

Esto nos enviara a asignar el nombre de dominio y colocaremos el asignado
correspondiente el cual ser naranja.com
Despus de esto se nos enviara a la pantalla de configuracin inicial donde
colocaremos la letra q para retirarnos del sistema de configuracin, guardando la
informacin como se puede apreciar en la imagen.

Despus de todas estas configuraciones deberemos reiniciar los servidores de DNS
con el comando sudo /etc/init.d/bind9 restart

Ahora comenzamos la prueba de correo asignando usuarios, asignamos el usuario
Antonio al cual le daremos una contrasea correcta y daremos datos si es que fuese

104

el caso, debemos recordar que esta contrasea y el nombre de usuario sern
los que usaremos para accesar con el cliente de correo electrnico.

Despus en la ruta /etc/hostname sustituimos lo que tenga por el nombre de
dominio.

Figura 56. Creacion de un enlace simbolico
A continuacin debemos crear un enlace simblico en la carpeta www que se genera
al ser instalado el servidor LAMP que sirve para publicacin y lectura de pginas
web, este enlace con el propsito de crear un vnculo entre la aplicacin de correo
electrnico y la aplicacin de navegacin de cliente. Le podemos asignar el nombre
que mas nos parezca, en este caso se uso el nombre correo.

105

Figura 57. Primer acceso a SquirrelMail

Del lado del cliente debemos colocar la direccin de dominio ms diagonal
mas nombre del enlace simblico creado con anterioridad, es decir
www.naranja.com/correo lo que nos mandara directo a la aplicacin de correo
electrnico vinculado desde el servidor DNS para conexin al servidor LAMP.

Figura 58. Interfaz Cliente Servidor de correo.
Ahora del lado del servidor debemos enviar un correo a una cuenta ya creada,
dentro de esta cuenta ya existe un usuario creado llamado oneiros el cual tiene una
contrasea asiganada, dicho usuario aunque se loguee en el correo ser rechazado
pues nunca ha sido enviado un correo para activar la cuenta, del lado del servidor
enviaremos un correo a oneiros usando la siguiente estructura.

106

mail oneiros
(Subject) Poner el asunto de este correo y dar ENTER
PONER EL CONTENIDO DEL CORREO CON TODA LIBERTAD Y DAR ENTER
PONER UN PUNTO (.) Y DAR ENTER PARA FINALIZAR.

Figura 59. Primer Correo en el cliente
Despus podemos loguearnos con toda libertad y ya tendremos una cuenta activa
con el correo enviado a nuestra cuenta personal.

107

Figura 60.Detalle de la pantalla de correo enviado.

2.17.5. Instalacion de los Servicios SSH y Telnet en Ubuntu Server 12.04

Telnet es un servicio de comunicacin remota que nos puede ser de gran
utilidad cuando necesitamos dar mantenimiento a un sistema de servidor, para poder
lograr la conexin de un cliente a un servidor dicho servidor debe tener instalado el
servicio Telnet, en este caso de Ubuntu Server el comando es:
sudo apt-get install telnetd
Y despus para lograr su expansin se usa el comando:

108

Figura 61. Instalacion de los servicios

sudo apt-get install xinetd telnetd
Con esto ya podremos iniciar las conexiones remotas desde un Sistema
operativo Windows XP que sirva como servicio telnet y se pueda administrar desde el
cliente el servidor.

Una vez que se han completado estas configuraciones lo primordial es iniciar
ambas mquinas virtuales para simular una pequea red que podamos administrar
como cliente-servidor, las mquinas virtuales deben tener una IP valida y puertas de
enlace iguales por lo que debemos verificar dichas configuraciones antes de intentar
iniciar los servicios de Telnet.

109

Una vez iniciadas ambas mquinas virtuales observamos en el sistema de
servidor la IP asignada estticamente, la cual es para este caso 10.0.0.2 y es la que
se usara en el servicio telnet del sistema operativo cliente de Windows XP.

Figura 62. Acceso a Telnet
Cuando ya tengamos la direccin IP clara del servidor usaremos en el lado del
cliente el comando telnet 10.0.0.2 de este modo abriremos una terminal capaz de
administrar va consola el servidor de sistema operativo Ubuntu Server pero desde el
lado del cliente como se puede observar.

Despus de hacer las gestiones que correspondan en el servidor podemos
salir con los mismos comandos que usaramos en el sistema Linux ya que se trata de
una terminal con todos los privilegios del servidor, es una gran ventaja pero una gran
desventaja ya que no podremos cifrar los mensajes enviados, desventajas de Telnet.

110

Figura 63. Finalizacion del Servicio telnet

2.17.6. Conclusiones Sobre Telnet

Telnet es una buena herramienta de control remoto para el administracin de
un servidor, sin embargo, presenta la desventaja de que no es posible cifrar los
mensajes que se envan a travs de l, por lo que un intruso que filtre dicha
informacin la encontrara como texto plano y podr verla sin preocupaciones, lo cual
es un grave riesgo de seguridad, telnet tambin tiene mucha relacin con Windows y
sobre este funciona muy bien, aunque para sistemas operativos Linux lo preferente
es su contraparte o el protocolo SSH, el cual si que cifra los mensajes y elimina esta
desventaja marcada de Telnet.

2.17.7. Manejo e instalacin de SSH
El protocolo SSH presentado es una gran ventaja frente al servicio Telnet, el
cual podra definirse como la contraparte de Telnet aunque su uso vari en muchos
contextos. Para instalar el servicio en sistemas Linux basta con el comando: sudo
apt-get install openssh-server.

111

Figura 64. Instalacion del servicio SSH

Para instanciar este protocolo nos valdremos de un software llamado putty, el
cual no es ms que un interfaz de conexin en terminal para acceso y control remoto
de un servidor, este software nos pide 2 datos fundamentales, los cuales son la
direccin IP y el puerto, como el protocolo SSH usa el puerto 22 ese asignaremos y
tambin la direccin IP del servidor (pantalla derecha de Ubuntu Server).

112

Figura 65. Uso de Putty
Para verificar los servicios en el servidor usaremos el comando netstat ltpn
y observaremos los servicios y puertos de escucha de los mismos.

Figura 66. Uso de Putty (parte2)
Ahora para la conexin usando putty asignaremos la IP del servidor e
iniciaremos el software aceptando los cambios.

113

Figura 67. Configuracion de Putty
Iniciaremos el servicio aceptando todas las redes e iniciaremos el software
para la conexin remota.

Figura 68. Incio de Putty

Finalmente observamos que este software putty es capaz de generar una
terminal con todos los privilegios del servidor como si nos encontrramos frente al
mismo servidor pero controlndolo de manera remota, tambin tiene la ventaja de

114

poder copiar y pegar dicho contenido que no podramos realizar tan fcil en servidor
con la terminal del sistema operativo.

REFERENCIAS
1) 4R BLOG. (19 de 05 de 2014). http://www.4rsoluciones.com/. Obtenido de
http://www.4rsoluciones.com/: http://www.4rsoluciones.com/como-medir-la-calidad-en-
software/
2) Augusto, M. E. (2011). Administrador de Servidores. Herramientas, Consejos y procedimientos
de la actividad diaria. Buenos Aires: Manuales USERS.
3) Bakken, S. S. (2002). Manual de PHP. Madrid: GNU.
4) Claudia Yvette Castro Jaime, T. H. (2010). Polticas y Buenas Prcticas de seguridad en
5) Dueas, J. B. (2008). Implementacion De Servidores Con GNU/Linux. Mexico: alcancelibre.
6) Gauchat, J. D. (2012). El gran libro de HTML5, CSS3 y Javascript. Barcelona: MARCOMBO.
7) Gelbmann, M. (21 de Octubre de 2013). W3Techs Web Technology Surveys. Obtenido de
W3Techs Web Technology Surveys:
http://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_
server_market_at_the_expense_of_red_hat_centos
8) Gretter, G. (31 de Marzo de 2014). InnovaAge. Obtenido de InnovaAge:
http://www.innovaportal.com/innovaportal/v/75/1/innova.front/que_es_una_intranet
9) http://geeks.ms. (20 de Mayo de 2014). http://geeks.ms. Obtenido de http://geeks.ms:
http://geeks.ms/blogs/msierra/archive/2008/08/25/_BF00_C_F300_mo-se-mide-la-calidad-
en-el-software_3F00_.aspx
10) Jimmy Wales, L. S. (21 de Enero de 2011). Wikipedia. Obtenido de Wikipedia:
http://www.wikipedia.org
11) Johnson Robert, K. p. (2004). Estadistica elemental, Lo esencial. Mexico: MATH LEARNING.
12) Kenneth E. Kendall, J. E. (2005). Analisis y Diseo de Sistemas. Sexta Edicion. Mexico:
PEARSON Educacion.

115

13) Labrador, R. M. (2010). Administracion de Servidores Linux (Ubuntu/Fedora). Sevilla:
Universidad de Sevilla.
14) Martnez, R. (2002). Manual de PHP. Madrid: GNU.
15) Pea, L. O. (19 de Marzo de 2014). Estadista del CEAPS Atlautla. (A. A. Galicia, Entrevistador)
16) Rivas, J. (31 de Marzo de 2014). Tecnologia Pyme. Obtenido de Tecnologia Pyme:
http://www.tecnologiapyme.com/software/necesita-la-pyme-un-servidor
http://www.tecnologiapyme.com/hardware/como-elegir-un-servidor-para-nuestra-empresa-
i-el-hardware
http://www.tecnologiapyme.com/hardware/como-elegir-un-servidor-para-nuestra-empresa-
iii-sistemas-de-copia-de-seguridad
http://www.tecnologiapyme.com/software/como-elegir-un-servidor-para-nuestra-empresa-
ii-el-sistema-operativo
20) Schmuller, J. (1997). Aprendiendo UML en 24 Horas. Naucalpan de Juarez: PEARSON.
21) Universidad Rey Juan Carlos. (2000). Calidad Software. Madrid: Kybele.
22) W3Techs, Linux.org. (23 de 03 de 2014). W3Techs Web Technology Surveys. Obtenido de
W3Techs Web Technology Surveys: http://w3techs.com/technologies/details/os-linux/all/all
23) W3Techs, Web Technology Survey. (7 de Abril de 2014). W3Techs. Obtenido de W3Techs:
http://w3techs.com/

Tesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis

Uploaded by

Copyright:

Available Formats

TECNOLGICO DE ESTUDIOS SUPERIORES DE

El montaje de un servidor web para instalar un sistema de administracin

Un servidor web dedicado a un sistema de administracin de pacientes

You might also like