AP4-AA4-Ev1-Mecanismos de control y seguridad

INFORME ESCRITO

POR:

EDWARD LEANDRO HURTADO MINA

DIANA MARCELA TILANO ZAPATA
DILMA ROCIO MEDINA PUERTO

INSTRUCTOR RESPONSABLE:
Anglica Rodrguez
Instructora lder

REGIONAL DISTRITO CAPITAL

Centro de Servicios Financieros

2016

"EL CENTRO CLNICO Y DE REHABILITACIN" Se tendr en cuenta los

siguientes factores para lograr un mejor avance en cada una de las dependencias
que se tendrn y el usuario logre acceder fcilmente a nuestros servicios.

1. SEGMENTACIN DE PROCESOS, PERFILES Y ROLES:

Hoy en da la interconexin entre redes es ms comn de lo que parece, desde
una simple conexin a internet, ya estamos sumergidos en un sin fin de
conexiones, de las que muchas veces como usuarios ni nos damos cuenta de todo
lo que acontece detrs de un simple cable de red.

Precisamente para mantener un orden detrs de ese cable existe algo que permite
la comunicacin entre redes, que permite una mejor distribucin de todos los datos
que por all viajan, permite un mejor manejo del ancho de banda utilizado por cada
usuario en la red, a esa distribucin la llamamos Segmentacin de Redes.

Hay dos motivos fundamentales para dividir una red en segmentos. La primera es
aislar el trfico entre segmentos. La segunda razn es lograr ms ancho de banda
por usuario mediante la creacin de dominios de colisin ms pequeos.
Sin la segmentacin, las redes ms grandes que un pequeo grupo de trabajo
podra atascarse rpidamente con el trfico y las colisiones.
Cabe destacar que el tipo de red comn hoy en da es la red basada en IPV4, es
la versin 4 del protocolo IP, debido a su implementacin a gran escala, su
crecimiento se desbordo al que inicialmente se esperaba en su diseo, cuyo lmite
en el nmero de direcciones de red admisibles est empezando a restringir el
crecimiento de Internet y su uso, debido a este auge y dado que el requerimiento
de grandes velocidades en internet en mayor dado el contenido que se maneja
actualmente (multimedia, vos sobre ip, video sobre ip, telefona por ip etc ), es que
hoy en da le est dando paso a una versin mejorada que distribuye y maneja
mejor el nmero de direcciones para el mejor uso de la Internet, el llamado IPV6,
que no es ms el reemplazo mejorado de su antecesor IPV4.
Volviendo a IPV4 que es la usada actualmente en la mayora de las redes
mundiales, especialmente en redes LAN, esto hace que se requiera un buen

diseo estructural de las redes, que permitan definir grupos, accesso y por ende
controlar el ancho de banda para cada nodo de la red, esto se hace por medio de
la segmentacin, la cual como hemos mencionado hace que esto sea posible

2. MECANISMO DE AUTENTICACIN A IMPLEMENTAR EN EL SISTEMA:

En nuestro centro se tendrn en cuenta los siguientes:

Autenticacin clsica

En un sistema Unix habitual cada usuario posee un nombre de entrada al sistema

o login y una clave o password; ambos datos se almacenan generalmente en el
fichero /etc/passwd. Este archivo contiene una lnea por usuario donde se indica la
informacin necesaria para que los usuarios puedan conectar al sistema y trabajar
en l, separando los diferentes campos mediante
Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus
usuarios por su nombre de entrada al sistema. Para el sistema operativo lo que
realmente distingue a una persona de otra (o al menos a un usuario de otro) es el
UID del usuario en cuestin; el login es algo que se utiliza principalmente para
comodidad de las personas (obviamente es ms fcil acordarse de un nombre de
entrada como toni que de un UID como 2643, sobre todo si se tienen cuentas en
varias mquinas, cada una con un UID diferente).
Para cifrar las claves de acceso de sus usuarios, el sistema operativo Unix emplea
un criptosistema irreversible que utiliza la funcin estndar de C crypt, basada en
el algoritmo DES. Para una descripcin exhaustiva del funcionamiento de crypt.
Esta funcin toma como clave los ocho primeros caracteres de la contrasea
elegida por el usuario (si la longitud de sta es menor, se completa con ceros)
para cifrar un bloque de texto en claro de 64 bits puestos a cero; para evitar que
dos passwords iguales resulten en un mismo texto cifrado, se realiza una
permutacin durante el proceso de cifrado elegida de forma automtica y aleatoria
para cada usuario, basada en un campo formado por un nmero de 12 bits (con lo
que conseguimos 4096 permutaciones diferentes) llamado salt. El cifrado
resultante se vuelve a cifrar utilizando la contrasea del usuario de nuevo como
clave, y permutando con el mismo salt, repitindose el proceso 25 veces. El
bloque cifrado final, de 64 bits, se concatena con dos bits cero, obteniendo 66 bits
que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto con
el salt, pasan a constituir el campo password del fichero de contraseas,
usualmente /etc/passwd. As, los dos primeros caracteres de este campo estarn
constituidos por el salt y los 11 restantes por la contrasea cifrada.
Otro mtodo cada da ms utilizado para proteger las contraseas de los usuarios el
denominado Shadow Password u oscurecimiento de contraseas. La idea bsica de este

mecanismo es impedir que los usuarios sin privilegios puedan leer el fichero donde
se almacenan las claves cifradas.

Envejecimiento de contraseas

En casi todas las implementaciones de Shadow Password actuales se suele incluir

la implementacin para otro mecanismo de proteccin de las claves denominado
envejecimiento de contraseas (Password Aging). La idea bsica de este
mecanismo es proteger los passwords de los usuarios dndoles un determinado
periodo de vida: una contrasea slo va a ser vlida durante un cierto tiempo,
pasado el cual expirar y el usuario deber cambiarla.
Realmente, el envejecimiento previene ms que problemas con las claves
problemas con la transmisin de stas por la red: cuando conectamos mediante
mecanismos como telnet, ftp o rlogin a un sistema Unix, cualquier equipo entre el
nuestro y el servidor puede leer los paquetes que enviamos por la red, incluyendo
aquellos que contienen nuestro nombre de usuario y nuestra contrasea.

Sintaxis del archivo de configuracin

El archivo (/etc/pam.conf) est formado por una lista de reglas (tpicamente una
por lnea). Cada regla es un conjunto de campos separados por espacios (los tres
primeros son case-sensitives):
Service type control module-path module-arguments
La sintaxis de los archivos bajo /etc/pam.d/ es igual salvo que no existe el campo
"service". En este caso "service" es el nombre del archivo en el directorio
/etc/pam.d/ (el nombre del archivo debe estar en minsculas)
Usualmente service es el nombre del servicio o aplicacin comnmente usado,
ejemplo de esto son login, su y ssh.
type especifica a que grupo de administracin est asociada la regla. Las entradas
vlidas son:

account: este mdulo maneja la cuenta sin basarse en autenticacin.

Tpicamente se usa para restringir/permitir el acceso a un servicio
basado en la hora o quizs desde donde se loguea el usuario (ej.: root
solo se puede loguear desde consola

auth: provee mecanismo de autenticacin (el usuario es quien dice ser).

password: este mdulo es requerido para modificar la password del

usuario.

session: este mdulo est asociado con hacer tareas previas y/o
posteriores al inicio del servicio mismo (pueden ser cosas como montar
un directorio, activar logueos, etc).

El tercer campo control especifica que hacer si falla el control

aplicado. Existen dos sintaxis para este campo, una sencilla de un
campo y otra que especifica ms de un campo dentro de corchetes
rectos [] Para la bsica, las opciones son:

required: indica que esta regla debe ser exitosa, de lo contrario el

usuario no es autorizado a correr el servicio. Si falla se devuelve el
control al programa, pero antes se ejecutan todos los mdulos.

requisite: es como el required, pero devuelve el control al programa

enseguida de fallar.

sufficient: Si este mdulo se verifica, entonces (se devuelve) se le da el

ok al programa y no se sigue verificando los otros mdulos.

optional: la falla o no de este mdulo es solo importante si es el nico

existente.
El cuarto campo module-path especfica el path al mdulo PAM
asociado con la regla. Los mdulos se encuentran en /lib/security.
El quinto campo module-arguments es un conjunto de cero o ms
argumentos pasados al mdulo durante su invocacin. Los argumentos
varan segn el mdulo.
La configuracin de los archivos de configuracin bajo /etc/pam.d/
resulta ser ms flexible (se evita tener una archivo nico enorme). Bajo
este directorio se puede encontrar el archivo de confiuracin personal
de un servicio particular como ser ssh. La nica diferencia entre la
sintaxis del archivo /etc/pam.conf es que no existe el campo service.

3. CIFRADO DE DATOS: TIPO DE ALGORITMOS A IMPLEMENTAR.

Un algoritmo de cifrado simtrico es una frmula matemtica que convierte el texto
plano en un forma ininteligible, cifrada, y conocida como texto cifrado. La variable,
o clave de cifrado, que se utiliza para conducir un algoritmo de cifrado simtrico es
derivado de la contrasea dada cuando los datos estn cifrados, y una clave nica
compartida es utilizada para cifrar y descifrar los datos. Existen varios tipos
diferentes de algoritmos de cifrado simtricos y su fuerza depende, en gran parte,
de la longitud, en bits (0 y 1), de su clave de cifrado.
3DES
Triple DES (3DES) es una mejora del simple DES que aplica el mtodo de cifrado
DES a los mismos datos tres veces para aumentar el nivel de cifrado. Triple DES
aumenta la longitud de la clave de cifrado de 192 bits, pero es ms lento que otros

mtodos de cifrado. Sin embargo, 3DES reemplaz a DES como el algoritmo de

cifrado simtrico en el ao 1999, de acuerdo con Federal Information Processing
Standards (FIPS).
AES
Advanced Encryption Standard (AES), que en realidad es una implementacin de
un algoritmo de cifrado simtrico conocida como Rjindael, es el ltimo estndar
recomendado por el NIST. AES utiliza una clave de cifrado que vara en longitud
de 128 bits a 256 bits y cifra los datos en bloques de 128 bits. El algoritmo AES es
aplicado a los datos 10, 12, o 14 veces, conocido como "rondas", lo que es muy
seguro. De hecho, slo un ataque de fuerza bruta, en el que el atacante prueba
todas las combinaciones posibles de la clave de cifrado, ha demostrado ser eficaz
contra AES. Sin embargo, AES es rpido, flexible y puede ser implementado en
una variedad de diferentes plataformas.

4. PROCEDIMIENTOS ADICIONALES DE SEGURIDAD A IMPLEMENTAR

El tema de la creacin de una aplicacin Web segura es muy amplio ya que
requiere realizar un estudio para comprender los puntos vulnerables de la
seguridad.
Protegerse contra entradas malintencionadas
Como regla general, nunca se debe dar por sentado que la entrada proveniente de
los usuarios es segura. A los usuarios malintencionados les resulta fcil enviar
informacin potencialmente peligrosa desde el cliente a la aplicacin. Para
protegerse contra las entradas malintencionadas, siga estas instrucciones:
En las pginas Web ASP.NET, filtre la entrada de los usuarios para
comprobar si existen etiquetas HTML, que pueden contener un script. Para
obtener informacin detallada, vea Cmo: Proteger una aplicacin Web
frente a ataques mediante secuencias de comandos aplicando codificacin
HTML a las cadenas.
Nunca repita (muestre) entrada de los usuarios sin filtrar. Antes de mostrar
informacin que no sea de confianza, codifique los elementos HTML para
convertir cualquier script potencialmente peligroso en cadenas visibles, pero
no ejecutables.
No almacene nunca informacin proporcionada por el usuario sin filtrar en
una base de datos.
Si desea aceptar algn elemento de cdigo HTML de un usuario, fltrelo
manualmente. En el filtro, defina explcitamente lo que aceptar. No cree un
filtro que intente eliminar cualquier entrada malintencionada, ya que es muy
difcil anticipar todas las posibilidades.

No d por sentado que la informacin obtenida del encabezado de solicitud

HTTP (en el objeto HttpRequest) es segura. Proteja las cadenas de
consulta, cookies, etc. Tenga en cuenta que la informacin que el
explorador enva al servidor (informacin del agente de usuario) puede ser
suplantada, en caso de que resulte importante para la aplicacin en
cuestin.
Si es posible, no almacene informacin confidencial en un lugar accesible
desde el explorador, como campos ocultos o cookies. Por ejemplo, no
almacene una contrasea en una cookie.
Tener acceso seguro a bases de datos
Normalmente, las bases de datos tienen sus propios sistemas de seguridad. Un
aspecto importante de una aplicacin Web protegida es disear un modo de que
sta pueda tener acceso a la base de datos de forma segura. Siga estas
instrucciones:
Use el sistema de seguridad inherente de la base de datos para limitar
quin puede tener acceso a los recursos de dicha base. La estrategia
exacta depender de la base de datos y de la aplicacin:
Si resulta viable en la aplicacin, use la seguridad integrada de forma que
slo los usuarios autenticados mediante Windows puedan tener acceso a la
base de datos. La seguridad integrada es ms segura que pasar las
credenciales explcitas a la base de datos.
Si la aplicacin utiliza el acceso annimo, cree un nico usuario con
permisos muy limitados, y haga que las consultas se ejecuten
conectndose como dicho usuario.
No cree instrucciones SQL concatenando cadenas que contengan
informacin aportada por los usuarios. En su lugar, cree una consulta
parame rizada y use la entrada del usuario para establecer los valores de
los parmetros.
Si debe almacenar un nombre de usuario y su contrasea en algn lugar
para utilizarlos como las credenciales de inicio de sesin de la base de
datos, almacnelos en el archivo Web.config y asegure el archivo con
configuracin protegida. Para obtener informacin detallada, vea Cifrar
informacin de configuracin mediante una configuracin protegida.
Crear mensajes de error seguros
Si no se es cuidadoso, un usuario malintencionado puede deducir informacin
importante sobre la aplicacin a partir de los mensajes de error que sta muestra.
Siga estas instrucciones:
No escriba mensajes de error que presenten informacin que pudiera
resultar til a los usuarios malintencionados, como un nombre de usuario.
Configure la aplicacin para que no muestre errores detallados a los
usuarios. Si desea mostrar mensajes de error detallados para la
depuracin, determine primero si quien los recibir es un usuario local con

respecto al servidor Web. Para obtener informacin detallada, vea Cmo:

Mostrar mensajes de error seguros.
Utilice el elemento de configuracin customErrors para controlar quin ve
las excepciones desde el servidor.
Cree un sistema de administracin de errores personalizado para las
situaciones que sean propensas a los errores, como el acceso a las bases
de datos. Para obtener ms informacin, vea Control de errores en
aplicaciones y pginas ASP.NET.
Mantener segura la informacin confidencial
Informacin confidencial es toda aquella informacin que se desea conservar
privada. Un ejemplo de informacin confidencial es una contrasea o una clave
cifrada. Si un usuario malintencionado consigue llegar a la informacin
confidencial, los datos protegidos se vern expuestos. Siga estas instrucciones:
Si la aplicacin transmite informacin confidencial entre el explorador y el
servidor, plantese utilizar el protocolo SSL (Secure Sockets Layer). Para
obtener detalles sobre cmo asegurar un sitio con SSL, vea el artculo
Q307267 en ingls, "HOW TO: Secure XML Web Services with Secure
Socket Layer in Windows 2000" en Microsoft Knowledge Base en el sitio
http://support.microsoft.com.
Utilice configuracin protegida para proteger la informacin confidencial en
archivos de configuracin como los archivos Web.config o Machine.config.
Para obtener ms informacin, vea Cifrar informacin de configuracin
mediante una configuracin protegida.
Si debe almacenar informacin confidencial, no lo haga en una pgina Web,
ni siquiera en un formato que piense que la gente no podr verlo (por
ejemplo, cdigo del servidor).
Utilice los algoritmos de cifrado de alta seguridad proporcionados en el
espacio de nombres System.Security.Cryptography.