Seguridad en SIstemas Operativos *Nix

Seguridad en Sistemas Operativos
1

2
Introducción 5
Capítulo 1 – Estructura de red 7
1.1 – Nuestro Sitio Web 7
1.2 – Arquitectura de Red 8
1.2.1 – Arquitectura de Red (DEMO) 8
1.2.2 – Arquitectura de Red (SUGERIDO) 9
1.3 – Herramientas de hardware 10
1.3.1 – Máquina virtual del Servidor 10
1.3.2 – Máquina virtual del Firewall 11
1.3.3 – Máquina virtual Windows 11
1.3.4 – Otros elementos de hardware 11
Capítulo 2 – Configuración de Línea Base 13
2.1 – Hardening o endurecimiento de nuestro servidor Apache. 13
2.1.1 – Remover la versión del banner 13
2.1.2 – Deshabilitar el listado de directorios. 14
2.1.3 – Ejecutar apache desde una cuenta sin privilegios. 15
2.1.4 – Protegernos de ataques Clickjacking 16
2.1.5 – Proteger la cookie con Secure cookie 17
2.1.6 – XSS (Cross Site Scripting) 18
2.1.7 – Eliminar el historial de la consola de intérprete 19
2.1.8 – Configuración seguridad de Openssl y suites de protocolos
seguros.
20
2.2 – Configuración del WAF 23
2.2.1 – Instalamos las dependencias con el siguiente comando: 23
2.2.2 – Instalación del mod_Security 24
2.2.3 – Configuración del ModSecurity 25
2.2.4 – Ahora procedemos a activar las reglas en el archivo de
configuración usamos el siguiente comando
26
2.2.5 – Buscamos la línea 26
2.2.6 – Procedemos a reemplazar la línea anterior, por la siguiente línea 27
2.2.7 – Incrementamos la cantidad máxima de solicitud a 16MB 27
2.2.8 – Descargamos el Core Set Rule de OWASP 28
2.2.9 – Instalación de mod evasive 31
2.3 – Instalación de mod qos 34
2.4 – Hardening SSH (fail2ban, configuración del ssh) 36
2.4.1 – Instalación, configuración SSH. 36
2.4.2 – Uso del Protocolo ssh2, verificaremos que en la configuración este 37
Índice

3
habilitado la versión 2 del SSH
2.4.3 – Limitaremos el acceso a los usuarios o grupos con el siguiente
parámetro
38
2.4.4 – Configuraremos el tiempo de inactividad 38
2.4.5 – Verificamos que están los siguientes parámetros 39
2.4.6 – Deshabilitaremos el acceso de root por ssh 39
2.4.7 – Configuración del puerto SSH. 40
2.4.8 – Deshabilitamos la contraseña en blanco. 41
2.4.9 – Habilitaremos el banner de advertencia quitándole el signo 41
2.4.10 – Podemos editar el banner y su información 42
2.5 – Instalación de fail2ban 43
2.5.1 Editamos el archivo de configuración 43
2.5.2 – Si queremos habilitar el envío de informes usamos o instalamos el
SMTP
44
2.6 – Virtual host 46
2.7 – ClamAV 48
2.7.1 – Instalamos nuestro antivirus, (escogimos el ClamAV). 48
Capítulo 3 – Reporte y análisis de seguridad 53
3.1 – Análisis de Vulnerabilidades Nessus 53
3.2 – Enumeración de Puertos y enumeración de servicios Nmap 55
3.3 – Análisis de Firma Digital y Protocolos de cifrado sslscan 56
3.4 – Tabla de Vulnerabilidades para Aplicaciones Web 60
Capítulo 4 – Mitigación y contingencia 65
4.1 – Factores que afectan la seguridad física de los servidores 65
4.2 – Seguridad física de el(los) servidor(es) 67
4.2.1 – Protección física del lugar 67
4.2.2 – Mantenimientos 69
4.2.3 – Medidas de seguridad 70
4.3 – Seguridad pre-arranque del servidor 71
4.3.1 – Copias de seguridad 71
4.3.2 – Soportes no electrónicos 72
4.3.3 – El sistema de arranque en BIOS 72
4.3.4 – Configuración de contraseña 72
4.4 – Riesgo Inyección 73
4.4.1 – Mitigación 73
4.5 – Pérdida de Autenticación y Gestión de Sesiones 74
4.6 – Secuencia de Comandos en Sitios Cruzados (XSS) 75
4.7 – Referencia Directa Insegura a Objetos 75
4.8 – Configuración de Seguridad Incorrecta 76

4
4.9 – Exposición de datos sensibles 76
4.10 – Ausencia de Control de Acceso a Funciones 77
4.11 – Falsificación de Peticiones en Sitios Cruzados (CSRF) 78
4.12 – Utilización de componentes con vulnerabilidades conocidas 78
4.13 – Redirecciones y reenvíos no validados 79
Conclusiones 80
Bibliografía 81

5
Todo equipo que tenga acceso por algún medio a la red global, está expuesto a
ser vulnerado, independientemente del tipo de hardware o el sistema operativo.
Entendiendo esto entonces cada vez que se hagan experimentos o
implementaciones con Software OpenSource, estos deben ser sometidos a
diferentes pruebas de resistencia contra las vulnerabilidades. Esto es el análisis
de riesgos y el plan de mitigación de riesgos, que todo servidor *NIX debe
someterse al momento de hacer implementaciones de servicio a través de estos
sistemas operativos de software libre.
A continuación en el proyecto que se desarrolla en el trabajo presentado veremos
la implementación de un servidor web utilizando solo herramientas OpenSource.
Muchas de las características que queremos resaltar de seguridad las veremos en
los capítulos siguientes de los cuales podemos decir brevemente de que tratan.
Capítulo 1: este el capítulo de estructura de nuestra red y recursos disponibles
para los sistemas operativos que se necesitan poner a funcionar. En este
capítulo también se destacan las características de hardware y software de las
máquinas virtuales que tenemos de uso para nuestro servicio web.
Capítulo 2: aquí veremos las instalaciones y configuraciones que se hicieron
sobre la máquina del servidor web que brinda características muy importantes de
seguridad en diferentes frentes que son blando de vulnerabilidades terribles que
pueden afectar la continuidad del servicio. En el capítulo hay una serie de pasos
cada vez que se instala una herramienta que son buenas referencias para que
aquellos que lean este documento se puedan beneficiar de estas herramientas.
Capítulo 3: aquí veremos los riesgos, amenazas que son productos del resultado
de herramientas que nos ayudan a escanear y analizar vulnerabilidades que tiene
nuestro servicio. En el mismo destacaremos las herramientas utilizadas y
explicaciones de los resultados del escaneo después de utilizarlas sobre el equipo.
Capítulo 4: en esta sección está dedicada a ver las formas en que podemos
mitigar posibles riesgos y vulnerabilidades que se escapan de todas las
protecciones previstas en el hardening del mismo servicio. Vamos a ver
herramientas alternativas para aumentar la protección, equipos y protección del
medio en que se encuentra nuestro servidor.
Introducción

6
Estructura de Red
1

7
La seguridad de la información no solo consiste en aplicar soluciones que venden
en el mercado, que regularmente son enfocadas a solo partes de los aspectos que
se deben tomar en cuenta en el momento de asegurar un equipo informático.
Para ello se debe hacer un análisis de todas las posibles causas que pueden
comprometer el equipo en el esquema de hardware y software donde se
encuentra aloja el equipo.
Esto lo vamos a ver a continuación que presentamos el esquema de la red
estamos utilizando para proteger un servicio web.
1.1 – Nuestro sitio web
Este proyecto consiste en la puesta en marcha de un sitio web que utilice
herramientas OpenSource, quizás es más preciso decir que lo que se desea es la
aplicación de un sistema Linux para que soporte nuestro servicio web.
Sin embargo, esta aplicación hay que protegerla ya que existen diversos ataques
que pueden bloquear o afectar el servicio web, por lo que nos valemos de diversas
herramientas OpenSource de las cuales también hay que tener mucho cuidado
porque utilizarlas de forma incorrecta puede suponer una vulnerabilidad de nuestro
servicio web.
¿Cuál es la función del servicio web?
Este punto es importante para saber qué tan valioso es lo que protegemos, ya que
esto se mide por las ventajas que brinda tal servicio a los usuarios del mismo.
Para mencionarlo de una forma fácil, consiste en un servicio web de Cloud o un
sistema donde puedes alojar diferentes tipos de archivo, compartirlo con otros
usuarios e incluso se pueden crear carpetas y documentos de texto, lo que le
permite a los usuarios configurar su propia navegación dentro del espacio de cloud
reservado para ellos.
La protección básica o sencilla que da este sistema a los usuarios es el inicio de
sesión por usuario y contraseña. De los otros aspectos de seguridad se encargan
todo un conjunto de herramientas dedicadas a la aplicación de la protección del
servicio.
1

8
1.2 – Arquitectura de Red
La arquitectura de red está compuesta por los elementos que nos ayudan a
conectarnos con el servidor para poder accesar a los servicios que este provee.
Sin embargo hay que incluir elementos de protección en tal arquitectura que
garantice que el servicio esté disponible 24/7 mientras no se haya dado algún
anuncio de baja temporal ya sea por nuevas implementaciones, mantenimientos,
etc.
Para nuestro servicio web, que esta virtualizado posee herramientas adheridas al
sistema operativo que ayudan a mantener el servicio activo y con alta defensa
contra amenazas de posibles ataques, sin embargo algunas características
podrían mejorar la protección. A continuación presentamos el diagrama de la
arquitectura de red para nuestro sitio web.
1.2.1 – Arquitectura de Red (DEMO)
Figura #1.1 – Arquitectura de red (DEMO)

9
Como se puede ver en la imagen anterior es la arquitectura simulada en nuestro
conjunto de máquinas virtuales entre las que podríamos clasificar como:
 Máquinas virtuales del servicio: son las maquinas que se encuentran en el
área naranja del diagrama o DMZ (zona desmilitarizada) que cuenta con la
máquina virtual del servicio web montado sobre Debian 8 Jessie. Aparte esta
la máquina virtual del DNS
 Máquina virtual de Firewall: contiene el software pfsense que es un firewall
lógico montado sobre FreeBSD.
 Máquinas virtuales de usuarios: son máquinas que tienen el sistema
operativo Windows con las que se quiere acceder y probar ataques sobre el
servicio web y que se encuentra en la zona de usuarios de la organización
(LAN).
Aunque este esquema es muy prometedor hay elementos que mejoran la
seguridad del servicio web . A continuación en el siguiente esquema veremos las
mejoras del esquema del DEMO.
1.2.2 – Arquitectura de Red (SUGERIDO)
Figura #1.2 – Arquitectura de red sugerida

10
En el diagrama anterior podemos notar que solo se ha agregado un IPS y el
monitor de actividades del IPS. Sin embargo, esto no es lo único que se desea
mostrar.
El otro punto que se quiere mencionar sobre este esquema es que los elementos y
componentes son físicos y no virtuales. Esto es así, ya que estos poseen mayor
protección que una máquina virtual y permite ampliamente realizar operaciones y
configuraciones para todos los componentes que conforman la arquitectura de
red.
Los equipos físicos son más estables que los virtuales además que la contención
de servicios virtuales en una sola maquina física es un riesgo ya que la emulación
de estas se puede ver afectada por algún evento que ocurra en el sistema físico.
1.3 – Herramientas de Hardware (VIRTUAL)
Entre las herramientas de hardware están las propias máquinas virtuales utilizadas
para el proyecto, de las cuales se quiere destacar el consumo de recursos de la
maquina física que se le asignó a cada una de estas.
A continuación mostramos características propias del equipo físico que usa el
simulador Virtual Box para los sistemas que componen el proyecto.
Elementos principales de la máquina Física
Elemento Característica
Procesador 2.4 GHz 4 core
RAM 8 GB
HDD 750 GB
Equipo físico Laptop Acer Aspire
Con la maquina anteriormente descrita se crearon las máquinas virtuales que eran
un total de 3 máquinas, de las cuales nos apoyamos para hacer la simulación de
la manera que vamos a describir a continuación.
1.3.1 – Máquina virtual del Servidor
La máquina virtual del servidor posee las siguientes características de hardware
virtual al momento de haber hecho la instalación del sistema operativo.
Elementos principales de la máquina Servidor
Procesador Máximo utilizable por la maquina

11
física
RAM 2 GB
HDD 20 GB
1.3.2 – Máquina virtual del Firewall
Es la máquina virtual que corre el sistema Operativo FreeBSD de Unix que tiene
incluido el Firewall lógico PFsense y que posee las siguientes características
virtuales de hardware.
Elementos principales de la máquina Firewall
física
RAM 1.5 GB
HDD 15 GB
1.3.3 – Máquina virtual Windows
Las máquinas virtuales de Windows son incluidas dentro de la LAN y son para
testeo con herramientas que ponen a prueba la calidad de la instalación del
servidor y las herramientas de protección que se le agregaron para mantener el
servicio.
Elementos principales de la máquina Windows 7
física
RAM 2 GB
HDD 20 GB
1.3.4 – Otros elementos de hardware
Para agregar valor a la red que presentamos también contamos con un router
inalámbrico el cual provee red al firewall y que este se encarga de distribuir a
través de los diferentes segmentos de red que se crearon y que están dibujados
en el primer esquema de red que vimos en este capítulo.

12
Configuración de
Línea base. 2

13
2.1 Hardening o endurecimiento de nuestro servidor Apache.
Con la aparición de la Web 2.0, el intercambio de información a través de redes
sociales y el crecimiento de los negocios en la adopción de la Web como un medio
para hacer negocios y ofrecer servicios, los sitios web son constantemente
atacados. Los hackers buscan, ya sea comprometer la red de la corporación o a
los usuarios finales, accediendo al sitio web.
Como resultado, la industria está prestando mayor atención a la seguridad de
aplicaciones web, así como a la seguridad de las redes
computacionales y sistemas operativos.
La mayoría de los ataques a aplicaciones web ocurren a través del cross-site
scripting (XSS) e inyección SQL el cual comúnmente resulta de una codificación
deficiente y la falta de desinfección de las entradas y salidas de la aplicación web.
2

14
Figura #2.0 - Gráfico Cenzic muestra el informe de tendencias de la
vulnerabilidad de 2013
2.1.1 – Remover la versión del banner
Abrimos el archivo security.conf
/etc/apache2/conf-availables/security.conf
Habilitamos o agregamos de ser necesario las siguientes líneas:
ServerTokens Prod
ServerSignature Off
Figura #2.1 – Remover versión del banner.
2.1.2 – Deshabilitar el listado de directorios.

15
Para evitar que un atacante pueda ver el listado de archivos y carpetas de nuestro
servidor Web.
Abrimos el siguiente archivo apache2.conf
vi /etc/apache2/apache2.conf
Dentro del directorio agregamos la siguiente línea:
Options –Indexes
Figura #2.2 – Deshabilitar el listado del directorio.
2.1.3 – Ejecutar apache desde una cuenta sin privilegios.

16
En caso de que un atacante logre obtener el usuario y contraseña del apache, es
importante que esta cuenta no posea permisos para iniciar sesión como root y
poder hacer otras cosas en nuestro servidor Web.
Para esto debemos crear un grupo y posteriormente un usuario, con el nombre de
apache.
groupadd apache
useradd –G apache apache
Luego cambiamos el propietario de la carpeta de instalación del Apache, con el
nuevo usuario sin privilegios que acabamos de crear.
chown –R apache:apache /opt/apache
Figura #2.3 – Cambiar propietario del apache.
2.1.4 – Protegernos de ataques Clickjacking
Clickjacking o secuestro de clic, es una técnica maliciosa para engañar a
usuarios de Internet con el fin de que revelen información confidencial o tomar
control de su computadora cuando hacen clic en páginas web aparentemente
inocentes.
En uno de los muchos navegadores o plataformas con alguna vulnerabilidad, un
ataque de clickjacking puede tomar la forma de código embebido o script que se
ejecuta sin el conocimiento del usuario; por ejemplo, aparentando ser un botón
para realizar otra función.

17
Editar el siguiente archivo default-ssl.conf, ubicado en /etc/apache2/sites-
available/
nano /etc/apache2/sites-available/default-ssl.conf
Agregar la siguiente línea:
Header always append X-Frame-Options SAMEORIGIN
Figura #2.4 – Protección contra el Clickjacking.
2.1.5 – Proteger la cookie con Secure cookie
La cookie es una pequeña información enviada por un sitio web y almacenado en
el navegador del usuario, de manera que el sitio web puede consultar la actividad
previa del usuario. Pero dicha información puede ser manipulada por terceros sin
no controlamos esto.
Agregamos la siguiente línea dentro del archivo default-ssl.conf:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

18
Figura #2.5 – Protección contra manipulación de cache.
2.1.6 – XSS (Cross Site Scripting)
Cross-site scripting es un tipo de inseguridad informática o agujero de
seguridad típico de las aplicaciones Web, que permite a una tercera persona
inyectar en páginas web visitadas por el usuario código JavaScript o en otro
lenguaje similar (ej: VBScript), evitando medidas de control como la Política del
mismo origen.
XSS es un vector de ataque que puede ser utilizado para robar información
delicada, secuestrar sesiones de usuario, y comprometer el navegador,
subyugando la integridad del sistema.
Para solucionar esta vulnerabilidad agregamos dentro del archivo default-ssl.conf
la siguiente línea.
Header set X-XSS-Protection: "1; mode=block"

19
Figura #2.6 - Cross site Scripting.
Luego de haber agregado estas tres últimas líneas al archivo default-ssl.conf,
nos debe quedar el IfModule mod_header.c así:
<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
Header set X-XSS-Protection: "1; mode=block"
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
</IfModule>
Reiniciamos apache2
/etc/init.d/apache2 restart
2.1.7 – Eliminar el historial de la consola de intérprete

20
Ejecutamos el siguiente comando:
history -c && history –w
Figura #2.7 – Eliminación del Historial.
2.1.8 - Configuración seguridad de Openssl y suites de protocolos seguros.
Primero vamos a crear un certificado con una cifrado RSA de 4096, y su
respectiva firma.
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -
out localhost.crt
Ahora vamos a generar nuestras llaves
openssl req -out localhost.csr -new -newkey rsa:2048 -nodes -keyout
localhost.key
Agregamos nuestro certificado, copiamos nuestro certificado, y llave dentro del
siguiente archivo: default-ssl.conf.
SSLCertificateFile # Personal Certificate
SSLCertificateKeyFile # Key File

21
SSLCACertificateFile # Signer Cert file
Ahora vamos a configurar el OpenSSL con los protocolos de cifrados seguros,
eliminando protocolos obsoletos como el sslv2 y sslv3, además de la
renegociación de protocolos débiles aprovechados por vulnerabilidades como
Poodle, the beast, heartbleed, entre otras. Procedemos a abrir el archivo ssl.conf
nano /etc/apache2/mods-available/ssl.conf
Figura #2.8 – Configuración del Open SSL - 1.
La siguiente opción permite el uso de suite de cifrados altas y medios, y anula los
cifrados débiles y hash como MD5, MD4, entre otros obsoletos.

22
Figura #2.9 – Configuración del open SSL - 2.
El parámetro SSLHonorCipherOrder On, habilita o permite solamente el uso de
los cifrados Fuertes que mostramos abajo: Curvas elípticas + diffie healman,
curvas elípticas + dsa,, entro otros cifrados en dicho orden.
La siguiente configuración elimina los protocolos obsoletos de SSLv2 y SSLv3
En la siguiente opción comentamos el parámetro que por defecto permite la
renegociación de insegura de cifrados.

23
Habilitamos el uso de HSTS que nos permite el uso de forward secrecy con https
Figura #2.12 – Habilitamos el uso de HSTS.
2.2 – Configuración del WAF
Estará formado por tres mod (mod security, mod evasive, mod qos).
Nota: La dirección IP y nombre de la máquina que veremos a continuación es
diferente, pues es de un informe anterior.
A continuación detallamos los pasos para la instalación y configuración del Mod
Security (nuestro WAF), luego continuamos con el Mod Evasive (nuestro IPS) y
por último el Mod Qos (Nuestra protección contra ataques de denegación de
servicios o Slow Loris).
2.2.1 – Instalamos las dependencias con el siguiente comando:
apt-get install libxml2 libxml2-dev libxml2-utils

24
Figura #2.13 – Instalación de dependencias.
apt-get install libaprutil1 libaprutil1-dev

25
Nos preguntará si deseamos continuar, le decimos que sí, osea presionamos la
letra Y luego la tecla Enter.
Ahora que ya hemos instalado las dependencias necesarias, podemos iniciar la
instalación del Mod Security.
2.2.2 – Instalación del mod_Security:
Mod security cambio a la versión dos por eso utilizamos este comando
apt-get install libapache2-mod-security2 -y

26
Figura #2.15 – Instalación del mod Security.
2.2.3 – Configuración del ModSecurity
Vamos a copiar la configuración recomendada a su correspondiente archivo en la
ubicación
cp /etc/modsecurity/modsecurity.conf-recommended
/etc/modsecurity/modsecurity.conf
Figura #2.16 – Configuración del mod Security.

27
2.2.4 – Ahora procedemos a activar las reglas en el archivo de configuración
usamos el siguiente comando:
nano /etc/modsecurity/modsecurity.conf
Figura #2.17 – Activación de reglas del mod security.
2.2.5 – Buscamos la línea:
SecRuleEngine DetectionOnly
Figura #2.18 – Activación del mod security.

28
2.2.6 – Procedemos a reemplazar la línea anterior, por la siguiente línea:
SecRuleEngine On
Figura #2.19 – Activación del mod security.
2.2.7 – Incrementamos la cantidad máxima de solicitud a 16MB
SecRequestBodyLimit 16384000
SecRequestBodyInMemoryLimit 16384000
Figura #2.20 – Limitación máxima de solicitud.

29
2.2.8 – Descargamos el Core Set Rule de OWASP
Vamos a descargarlo dentro de la carpeta temporal
cd /tmp
Descargamos las reglas
wget -O SpiderLabs-owasp-modsecurity-crs.tar.gz
https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master
Figura #2.21 – Descarga de reglas.
Nota: Prestar atención en que el archivo se descargue satisfactoriamente, pues
sino al realizar el siguiente paso nos enviará un error y no podremos continuar.
Descomprimimos
tar -xzvf SpiderLabs-owasp-modsecurity-crs.tar.gz
Copiamos las reglas al directorio del modsecurity
cp -r SpiderLabs-owasp-modsecurity-crs-c63affc/* /etc/modsecurity/
Copiamos o renombramos las reglas por defecto:

30
cp /etc/modsecurity/modsecurity_crs_10_setup.conf.example
/etc/modsecurity/modsecurity_crs_10_setup.conf
Procedemos a crear los symlinks o enlaces directos de las reglas activas
cd /etc/modsecurity/base_rules
for f in * ; do sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ;
done
cd /etc/modsecurity/optional_rules
for f in * ; do sudo ln -s /etc/modsecurity/optional_rules/$f
/etc/modsecurity/activated_rules/$f ; done
Nota: Cada comando con viñeta lo ejecutamos por separado, y en ese mismo
orden.
Vamos a cargar las reglas en el archivo de configuración del mod secuirty
nano /etc/apache2/mods-available/security2.conf
Añadimos la siguiente línea al archivo de configuración
Include /etc/modsecurity/activated_rules/*.conf
Figura #2.22 – Inclusión de librería de reglas activas.
Recargamos los headers de los módulos y reiniciamos el apache
 a2enmod headers

31
 a2enmod security2
 service apache2 restart
Nota: Cada comando con viñeta lo ejecutamos por separado, y en ese mismo
orden.
Verificamos los errores del modsecurity y procedemos a crear unas reglas
personalizadas
cd /etc/modsecurity
Creamos carpetas donde va nuestras reglas personalizadas
mkdir custom_rules
Para mayores detalles sobre como personalizar nuestras reglas podemos
consultar el siguiente sitio web:
https://digi.ninja/blog/modsecurity_lab.php
Creamos la regla
custom_rules/modsecurity_crs_99_custom.conf
Podemos verificar las reglas activas en el siguiente archivo:
cat /var/log/apache2/modsec_audit.log

32
Figura #2.23 – Definición del reglas.
Por Ejemplo para desactivar las dos reglas que vemos en pantalla, escribimos el
siguiente comando.
SecRuleRemoveById 981401
Además es posible que también halla que desactivar estas reglas:
Creamos el enlace
ln -s /etc/modsecurity/custom_rules/modsecurity_crs_99_custom.conf
/etc/modsecurity/activated_rules/
Reinciamos apache
service apahce2 restart
2.2.9 – Instalación de mod evasive
apt-get install libapache2-mod-evasive

33
Figura #2.24 – Instalación del mod Evasive.
a. Creamos la carpeta o directorio de logs
mkdir /var/log/mod_evasive
b. Cambiamos el dueño de la carpeta
chown www-data:www-data /var/log/mod_evasive/

34
Figura #2.25 – Cambio del propietario de la carpeta.
c. Editamos el archivo de configuración
vi /etc/apache2/mods-available/evasive.conf
d. Habilitamos los siguientes parámetros:
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir /var/log/mod_evasive
DOSEmailNotify EMAIL@DOMAIN.com
DOSWhitelist 127.0.0.1

35
Figura #2.26 – Configuración del mod Evasive.
e. Recargamos el mod evasive
a2enmod evasive
f. Reiniciamos apache
service apache2 restart
Figura #2.27 – Reinicio del servidor apache.
2.3 – Instalación de mod qos

36
apt-get -y install libapache2-mod-qos
Figura #2.28 – Instalación del mod Qos.
a. Configuración del mod qos
Ponemos los siguientes parámetros
cd /etc/apache2/mods-available/
Abrimos el siguiente archivo:
nano qos.load

37
Figura #2.29 – Inclusión del mod Qos.
b. Luego agregamos la siguiente línea y guardamos el archivo.
LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so
c. Luego abrimos el archivo que aparece abajo y procedemos a modificarlo.
nano qos.conf
## QoS Settings
<IfModule mod_qos.c>
# handles connections from up to 100000 different IPs
QS_ClientEntries 4000
# will allow only 50 connections per IP
QS_SrvMaxConnPerIP 50
# maximum number of active TCP connections is limited to 256
MaxClients 256
# disables keep-alive when 70% of the TCP connections are occupied:
QS_SrvMaxConnClose 180
# minimum request/response speed (deny slow clients blocking the server, ie.
slowloris keeping connections open without requesting anything):
#QS_SrvMinDataRate 150 1200
# and limit request header and body (carefull, that limits uploads and post
requests too):

38
# LimitRequestFields 30
# QS_LimitRequestBody 102400
</IfModule>
El archivo qos.conf debe quedar con los parámetros de la imagen de abajo.
Figura #2.30 – Configuración del Mod Security.
d. Reiniciamos apache
service apache2 restart
2.4 - Hardening SSH (fail2ban, configuración del ssh)
Nota: La dirección IP y nombre de la máquina que veremos a continuación es
diferente, pues es de un informe anterior.
2.4.1 – Instalación, configuración SSH.
Vamos a editar algunos parámetros en el archivo
/etc/ssh/sshd_config:

39
Primero escribiremos la siguiente línea para abrir el archivo sshd_config:
nano /etc/ssh/sshd_config
Figura #2.31 – Configuración del SSH
2.4.2 – Uso del Protocolo ssh2, verificaremos que en la configuración este
habilitado la versión 2 del SSH:
Protocol 2
Figura #2.32 – Verificación del uso de la versión 2.

40
2.4.3 – Limitaremos el acceso a los usuarios o grupos con el siguiente
parámetro:
AllowGroups sshaccess
Figura #2.33 – Definición del grupo.
2.4.4 – Configuraremos el tiempo de inactividad
ClientAliveInterval 300
ClientAliveCountMax 0
Figura #2.34 – Definición del intervalo para cerrar la conexión.

41
2.4.5 – Verificamos que están los siguientes parámetros:
IgnoreRhosts yes
HostbasedAuthentication no
Figura #2.35 – Configuración SSH.
2.4.6 – Deshabilitaremos el acceso de root por ssh:
PermitRootLogin no

42
Figura #2.36 – Deshabilitar el acceso Root por SSH.
2.4.7 - Configuración del puerto SSH.
Cambiaremos el puerto ssh por defecto por el puerto que queramos, nosotros
elegimos el puerto 1022:
Port 1022
Figura #2.37 – Configuración del puerto SSH.

43
2.4.8 – Deshabilitamos la contraseña en blanco.
PermitEmptyPasswords no
Figura #2.38 – No permitir contraseña en blanco.
2.4.9 – Habilitaremos el banner de advertencia quitándole el signo de #:
Por defecto #Banner /etc/issue.net
Quitamos el #, nos debe quedar: Banner /etc/issue.net

44
Figura #2.39 – habilitación del banner.
Guardamos las configuraciones del archivo sshd_config, si usamos nano como
nuestro interprete de comandos, entonces presionamos la tecla control + la tecla
O, luego presionamos la tecla Enter y por último presionamos la tecla X, para salir
del archivo.
2.4.10 – Podemos editar el banner y su información en el siguiente archivo:
nano /etc/issue.net
Figura #2.40 – Edición del banner.
Reiniciamos el servicio SSH con el siguiente comando:
/etc/init.d/ssh restart
Ahora que ya tenemos configurado nuestro servicio SSH, vamos a instalar y
configurar nuestra siguiente aplicación, llamada fail2ban.
Fail2ban es una aplicación escrita en Python para la prevención de intrusos en un
sistema, que actúa penalizando o bloqueando las conexiones remotas que
intentan accesos por fuerza bruta. Se distribuye bajo licencia GNU y típicamente
funciona en sistemas POSIX que tengan interfaz con un sistema de control de
paquetes o un firewall local (como iptables o TCP Wrapper).

45
Fail2ban busca en los registros (logs) de los programas que se especifiquen las
reglas que el usuario decida para poder aplicar una penalización. La penalización
puede ser bloquear la aplicación que ha fallado en un determinado puerto,
bloquearla para todos los puertos, etc. Las penalizaciones, así como las reglas,
son definidas por el usuario.
2.5 – Instalación de fail2ban:
apt-get install fail2ban
Figura #2.41 – Instalación del Fail2ban.
2.5.1 Editamos el archivo de configuración con los siguientes parámetros:
nano /etc/fail2ban/jail.conf
[ssh]
enabled = true
port = 1022
filter = sshd
logpath = /var/log/auth.log

46
maxretry = 3
Figura #2.42 – Configuración del Fail2ban.
2.5.2 – Si queremos habilitar el envío de informes usamos o instalamos el
SMTP y editamos los siguientes parámetros:
Reemplazamos el correo por el correo de nosotros:
destemail = root@localhost
Figura #2.43 – Envío de informes al correo.

47
Buscamos la línea action = %(action_)s
Y la reemplazamos por: action = %(action_mwl)s
Figura #2.44 – Configuración del Fail2ban.
Reiniciamos el Fail2ban:
/etc/init.d/fail2ban restart
Algunas alerta realizadas por el Fail2Ban y cómo podemos ver, nos realiza una
notificación en nuestro correo.
Figura #2.45 – Alerta del Fail2ban en el correo.

48
La siguiente aplicación que instalaremos es el Postfix, para poder recibir las
alertas que aplicaciones como el Fail2ban generaran y que necesitamos recibir,
para poder estar alertado de cualquier evento sospechoso.
Postfix es un servidor de correo de software libre / código abierto, un programa
informático para el enrutamiento y envío de correo electrónico, creado con la
intención de que sea una alternativa más rápida, fácil de administrar y segura al
ampliamente utilizado Sendmail.
2.6 – Virtual host
Poner ruta (/var/www/html)
Figura #2.46 – Directorio de instalación del virtual host.
chown -R www-data:www-data /var/www/html
cd /etc/apache2/sites-available

49
Ahora vamos a crear el archivo para configurar nuestro Virtual Host, para ello
ejecutamos el siguiente comando.
cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-
available/seguridad.local.conf
Figura #2.47 – Configuración del virtual host.
Al no contar con un dominio real creamos un dominio virtual llamado
seguridad.local, donde añadimos el puerto 80 y el dominio, también habilitamos
que la raíz de la aplicación web que instalamos sea en la ruta /var/www/html.
Forzamos a que responda únicamente por https, por medio del módulo rewrite
con los comodines mostrados en el segundo recuadro.
Deshabilitamos el sitio por defecto con el siguiente comando:
a2dissite 000-default.conf
Habilitamos que el sitio responda por dominio.
a2ensite seguridad.local.conf
Reiniciamos el servidor apache

50
/etc/init.d/apache2 restart
Cambiamos el archivo hosts
nano /etc/hosts
Figura #2.48 – Configuración del archivo host.
Ya por último en nuestra máquina virtual debemos añadirle el ip del servidor y el
dominio para que no soló responda de manera local sino que dentro de la red
virtual puedan llamar al dominio seguridad.local.
2.7 – ClamAV
Instalar el paquete antivirus ClamAV. Este puede integrarse posteriormente en
sistemas para filtrar e-mails o archivos.
2.7.1 – Instalamos nuestro antivirus, (escogimos el ClamAV).
Ejecutamos el siguiente comando:
aptitude install clamav clamav-docs clamav-daemon clamav-freshclam

51
Figura #2.49 – Instalación del Clamav.
Para que ClamAV también pueda verificar archivos comprimidos, deben instalarse
algunos paquetes para descomprimir archivos:
aptitude install arc arj bzip2 cabextract lzop nomarch p7zip pax tnef unrar-free
unzip zoo

52
Si usted tiene acceso a los repositorios “non-free”, puede instalar otros paquetes
adicionales:
aptitude install lha unrar
Figura #2.51 – Instalación de repositorios.
La actualización de la base de datos de firmas de virus es descargada de Internet
por daemon clamav-freshclam24 veces al día. Esta frecuencia puede modificarse
en el archivo
/etc/clamav/freshclam.conf:
Entramos al archivo de configuración del antivirus:
nano /etc/clamav/freshclam.conf
Verificamos que la siguiente línea este activa.
Checks 24

53
Figura #2.52 – Verificar archivo de configuración del antivirus.
Reiniciar el servicio, para que tenga en cuenta las alteraciones de configuración:
/etc/init.d/clamav-freshclam restart
Figura #2.53 – Reinicio del antivirus.

54
Reporte y análisis
de Seguridad 3

55
El siguiente capítulo veremos los riesgos, amenazas y hallazgos, de nuestro
servidor web, después de efectuar el hardening o línea base.
3.1 – Análisis de Vulnerabilidades Nessus
El siguiente análisis fue efectuado después de realizar los ajustes de línea base,
dando como resultado, 29 incidencias, 2 de nivel medio.
!
NOTA
Dichas vulnerabilidades son advertencias indicando que los certificados
no tiene una firma de una autoridad certificadora. Las otras 27 incidencias
son alertas informativas, comunes de banners e indicativas de
herramientas instaladas en el servidor.
3

56
Figura #3.1 – Resumen Nessus

57
Figura #3.2 – Resumen Nessus
3.2 – Enumeración de puertos y Enumeración de servicios Nmap
Figura #3.3 – Enumeración de Puertos y Servicios

58
Figura #3.4 – Enumeración de Puertos y Servicios
La siguiente tabla resume los hallazgos encontrados durante el Análisis de
vulnerabilidades y sus posibles incidencias:
Resumen de Hallazgos
Puertos Estado Servicios Riesgos
80 Open Apache Bajo
111 Open rpcbind Bajo
443 Open Apache Bajo
1022 Open SSH Medio
!
NOTA
Los hallazgos encontrados fueron mitigados con controles como la
implementación de WAF, Protocolos de cifrados robustos, implementación de
herramientas de seguridad para conexiones remotas (fail2ban). Cambios de
configuraciones básicas para el apache, respuesta únicamente por https, etc.
3.3 – Análisis de Firma Digital y Protocolos de cifrado sslscan

59
Figura #3.4 – Análisis de Cifrado

60
Figura #3.7 – Análisis de Cifrado en aplicación web Externa
!
NOTA
La evaluación efectuada al servidor indica únicamente permite el cifrado o suite
de cifrados fuertes. Se previene el ataque Poodle, The beast, Heartbleed y
soporta HTST.

61

62
3.4 – Tabla de Vulnerabilidades Para aplicaciones Web
La siguiente tabla presenta un resumen del Top 10 2013 de Riesgos de Seguridad en Aplicaciones web, y los factores de
riesgo que hemos asignado a cada uno. Estos factores fueron determinados basándose en las estadísticas disponibles y
en la experiencia del equipo OWASP TOP 10. Para entender estos riesgos para una aplicación u organización particular,
debe considerar sus propios agentes de amenaza e impactos específicos al negocio. Incluso debilidades de software
importantes podrían no representar un riesgo serio si no hay agentes de amenaza en posición de ejecutar el ataque
necesario o el impacto al negocio podría ser insignificante para los activos involucrados. Adicionalmente hemos incluido
una última categoría que puede afectar de manera significativa nuestra aplicación web.
Riesgos Explotabilidadad Prevalencia Detectabilidad Impacto Impacto al Negocio
A1 Inyección Fácil Común Promedio Severo Considere el valor de negocio de los
datos afectados y la plataforma sobre
la que corre el intérprete. Todos los
datos pueden ser robados,
modificados o eliminados.
¿Podría ser dañada su reputación?
Posible impacto: Severo
A2
Autenticación
Promedio Difundida Promedio Severo Considere el valor de negocio de los
datos afectados o las funciones de la
aplicación expuestas.
También considere el impacto en el
negocio la exposición pública de la
vulnerabilidad.
Posible Impacto: Severo
A3
XSS
Promedio Muy
Difundida
Fácil Moderado Considere el valor para el negocio del
sistema afectado y de los datos que
éste procesa.
vulnerabilidad.

63
A4
Ref. Directa
insegura
Fácil Común Fácil Moderado Considere el valor de negocio de los
datos afectados o las funciones de la
aplicación expuestas.
vulnerabilidad.
A5
Configuración
Defectuosa
Fácil Común Fácil Moderado El sistema podría ser completamente
comprometido sin su conocimiento.
Todos sus datos podrían ser robados
o modificados lentamente en el
tiempo.
Los costes de recuperación podrían
ser altos.
A6
Exposición de
Datos
Sensibles
Difícil Poco
Común
Promedio Severo  Considere el valor de negocio
de la pérdida de datos y el
impacto a su reputación. ¿Cuál
su responsabilidad legal si
estos datos son expuestos?
También considere el daño a la
reputación
A7
Ausencia de
Control de
Funciones
Fácil Común Promedio Moderado Considere el valor para su negocio de
las funciones expuestas y los datos
que éstas procesan. Además,
considere el impacto a su reputación
si esta vulnerabilidad se hiciera
pública.

64
A8
Falsificación
de peticiones
en sitios
Cruzados
CSRF
Promedio Común Fácil Moderado Considerar el valor de negocio
asociado a los datos o funciones
afectados. Tener en cuenta lo que
representa no estar seguro si los
usuarios en realidad desean realizar
dichas acciones. Considerar el
impacto que tiene en la reputación de
su negocio.
A9
Componentes
Vulnerables
Promedio Difundida Difícil Moderado Considere qué puede significar cada
vulnerabilidad para el negocio
controlado por la aplicación afectada.
Puede ser trivial o puede significar
compromiso completo.
A10
Redirecciones
no Validas
Promedio Poco
Común
Fácil Moderado  ¿Qué pasaría si sus usuarios
son infectados con código
malicioso?
 ¿Qué ocurriría si los
atacantes pudieran acceder a
funciones que sólo debieran
estar disponibles de forma
interna?
A11
Denegación
de Servicios
Promedio Común Promedio Severo Considera que puede significar para el
negocio no tener una disponibilidad
para sus clientes a su aplicación

65
!
NOTA
El impacto al negocio de cada riesgo es especifico de la aplicación o negocio

66
4
Seguridad Física y
Mitigación de riesgos

67
4.1 – Factores que afectan la seguridad física de los servidores
Acceso físico
Si alguien que desee atacar un sistema tiene acceso físico al mismo todo el resto
de medidas de seguridad implantadas se convierten en inútiles.
De hecho, muchos ataques son entonces triviales, como por ejemplo los de
denegación de servicio o si apagamos una máquina que proporciona un servicio
es evidente que nadie podrá utilizarlo.
Otros ataques se simplifican enormemente, por ejemplo, si deseamos obtener
datos podemos copiar los ficheros o robar directamente los discos que los
contienen.
Incluso dependiendo el grado de vulnerabilidad del sistema es posible tomar el
control total del mismo, por ejemplo reiniciándolo con un disco de recuperación
que nos permita cambiar las claves de los usuarios.
Este último tipo de ataque es un ejemplo claro de que la seguridad de todos los
equipos es importante, generalmente si se controla el PC de un usuario autorizado
de la red es mucho más sencillo atacar otros equipos de la misma.
Desastres naturales
Además de los posibles problemas causados por ataques realizados por
personas, es importante tener en cuenta que también los desastres
naturales pueden tener muy graves consecuencias, sobre todo si no los
contemplamos en nuestra política de seguridad y su implantación.
Algunos desastres naturales a tener en cuenta:
 Terremotos y vibraciones
 Tormentas eléctricas
 Inundaciones y humedad
 Incendios y humos
Los terremotos son el desastre natural menos probable en la mayoría de las
organizaciones, por lo que no se harán grandes inversiones en prevenirlos.
Tormentas eléctricas
Otro desastre natural importante son las tormentas con aparato eléctrico,
especialmente frecuentes en verano, que generan subidas súbitas de tensión muy
superiores a las que pueda generar un problema en la red eléctrica.
4

68
En entornos normales es recomendable que haya un cierto grado de humedad, ya
que en si el ambiente es extremadamente seco hay mucha electricidad estática.
No obstante, tampoco interesa tener un nivel de humedad demasiado elevado, ya
que puede producirse condensación en los circuitos integrados que den origen a
un cortocircuito. En general no es necesario emplear ningún tipo de aparato para
controlar la humedad, pero no está de más disponer de alarmas que nos avisen
cuando haya niveles anómalos.
Inundaciones
Otro tema distinto son las inundaciones, ya que casi cualquier medio (máquinas,
cintas, router, etc) que entre en contacto con el agua queda automáticamente
inutilizado, bien por el propio líquido o bien por los cortocircuitos que genera en los
sistemas electrónicos.
Fuego y humo
Por último mencionaremos el fuego y los humos, que en general provendrán del
incendio de equipos por sobrecarga eléctrica.
Además del fuego, también el humo es perjudicial para los equipos (incluso el del
tabaco), al ser un abrasivo que ataca a todos los componentes, por lo que es
recomendable mantenerlo lo más alejado posible de los equipos.
Alteraciones del entorno
En nuestro entorno de trabajo hay factores que pueden sufrir variaciones que
afecten a nuestros sistemas que tendremos que conocer e intentar controlar.
Deberemos contemplar problemas que pueden afectar el régimen de
funcionamiento habitual de las máquinas como la alimentación eléctrica, el ruido
eléctrico producido por los equipos o los cambios bruscos de temperatura.
Electricidad
Quizás los problemas derivados del entorno de trabajo más frecuentes son los
relacionados con el sistema eléctrico que alimenta nuestros equipos;
cortocircuitos, picos de tensión, cortes de flujo, etc.
Para corregir los problemas con las subidas de tensión podremos instalar tomas
de tierra o filtros reguladores de tensión.
Ruido eléctrico
El ruido eléctrico suele ser generado por motores o por maquinaria pesada, pero
también puede serlo por otros ordenadores o por multitud de aparatos, y se
transmite a través del espacio o de líneas eléctricas cercanas a nuestra
instalación.

69
Temperaturas extremas
Las temperaturas extremas, ya sea un calor excesivo o un frio intenso, perjudican
gravemente a todos los equipos. En general es recomendable que los equipos
operen entre 10 y 32 grados Celsius. Para controlar la temperatura emplearemos
aparatos de aire acondicionado.
4.2 – Seguridad física de el(los) servidor(es)
Cuando hablamos de seguridad física nos referimos a todos aquellos mecanismos
generalmente de prevención y detección, destinados a proteger físicamente
cualquier recurso del sistema; estos recursos son desde un simple teclado hasta el
servicio en si para el que fue designado el servidor.
Dependiendo del entorno y los sistemas a proteger esta seguridad será más o
menos importante y restrictiva, aunque siempre deberemos tenerla en cuenta.
A continuación mencionaremos algunos de los problemas de seguridad física con
los que nos podemos enfrentar y las medidas que podemos tomar para evitarlos o
al menos minimizar su impacto.
4.2.1 – Protección física del lugar
Hay varios elementos o problemas que nos enfrentamos cuando queremos
proteger el lugar donde se alojan los servidores y que en muchas ocasiones tiene
que pasar el desastre para corregir que vuelva a pasar un incidente.
En el lugar donde se alojan los servidores hay muchos elementos a tomar en
cuenta para que el equipo que es regularmente el elemento más caro del lugar y
que queremos que se mantenga en funcionamiento de forma continua.
Vemos a continuación algunos de esos elementos que debemos proteger del lugar
donde se alojan los servidores.
Puerta de seguridad
La puerta de seguridad es muy importantes ya que el acceso a los diferentes
lugares del cuarto de servidores no debe ser accesible desde cualquier parte sino
que se hace uso de este medio para definir quien pasa y quien no de acuerdo al
privilegio que tiene la persona que aspira a entrar al cuarto de servidores.
Seguridad o agente de control de acceso
Es la persona designada para cuidar la puerta de acceso al cuarto de servidores.
Este se encargara de revisar los privilegios de aquellos que están autorizados
para entrar, solicitara credenciales y hará consultas de ser necesario a sus
superiores por visitas insistentes que aspiran a realizar un trabajo en el cuarto de
servidores.

70
Revisa también las citas de mantenimiento teniendo en cuenta la identificación de
las personas que van a entrar, el propósito de la visitas y coordinando la vigilancia
con el agente de TI encargado en el momento de los servidores.
Control de ingreso de personal no autorizado
Aparte de la persona de seguridad también es posible restringir el acceso al cuarto
de servidores con el uso de elementos tecnológicos pioneros en temas de
seguridad entre los cuales se puede mencionar:
 Lector de huellas digitales
 Marcador de código de empleado de la organización con privilegio de acceso al
área de servidores.
 Lector de pupilas.
 Entre muchas otras.
Sistema eléctrico protegido con UPS.
Un elemento importante a tener en cuenta para la continuidad del servicio que se
brinda es que estos siempre dispongan de energía y como se sabe que la
electricidad puede por diversos motivos dejar de llegar a las instalaciones de
servidores. Es importante contar con un sistema de respaldo eléctrico o UPS que
nos brinda electricidad cuando el sistema eléctrico tiene alguna falla, permitiendo
que los servicios sean continuos.
Cables de Energía y de red estandarizados y protegidos por canaletas.
Para un servicio que se pone en producción y que debe ser constante no se deben
utilizar elementos comunes de cableado, sino utilizar los estándares
recomendados para mantener por mayor tiempo el servicio en línea y que los
mantenimientos por cambio de cableado sean menos frecuentes, aumentando así
la disponibilidad del servicio.
Aire acondicionado al menos a 21 °C.
El área de servidores generalmente es un área cerrada que acumula el calor de
los servidores que están en funcionamiento en el momento y el calor es enemigo
de los equipos computacionales ya que se pueden dañar componentes internos
más sensibles al calor.
De este modo el cuarto de servidores debe ser un área refrigerada a temperaturas
óptimas para que los equipos se mantengan trabajando mucho tiempo.
La temperatura óptima para seguridad de los equipos servidores es de 19 °C a 25
°C.
Cámaras de seguridad

71
Las cámaras de seguridad son importantes para mantener vigilados los pasillos
del cuarto de servidores y estas cámaras deben ser monitoreadas en una
habitación exterior del cuarto de servidores.
De esta manera se evita que intrusos tengan acceso al cuarto de servidores ya
que representan una gran amenaza a los servicios que proporcionamos.
Área designada para máquinas de archivos de medios y digitales.
Dentro del cuarto de servidores deben existir un conjunto de máquinas que me
permita crear backups y hacer instalaciones de prueba, por lo que se debe separar
una sección para máquinas de archivos de medios y digitales, y que este conjunto
de máquinas no afecten la continuidad del servicio.
Pared Falsa
La pared falsa nos ayuda a proteger diferentes elementos como lo es el cableado
que no debe estar en el piso, además de que en caso que ocurra inundaciones es
peligrosos que se encuentren por ejemplo en un suelo falso ya que el agua de las
inundaciones correría por ahí, por lo que es más recomendable que sea en las
paredes o techo (falso).
Piso Falso
El piso falso se puede implementar con diferentes objetivos, sin embargo, como se
mencionó en el punto anterior sería un medio de desalojo de agua en caso de
inundaciones y también en el caso de que haya tuberías de agua rota.
Canaletas en el techo
El cableado de la red que se conecta a los servidores descansa sobre estas ya
que el cableado jamás debería ir en el piso. Además de que impone más orden
en el lugar de los servidores y el cableado se encuentra libre de ciertos peligros
como agua, tropezones con el cable, aplastamiento, entre otros.
Sistema de control de incendio
Muchas veces cuando ocurren incendios en las instalaciones de los servidores
estos pueden funcionar mal y de repente se puede crear fuego, por lo que esta
situación debe tener solución rápido. Aquí es donde debe entrar un sistema
avanzado para mitigar el fuego en el área, por lo que es necesario un sistema de
detección que al momento de producirse fuego riegue sobre el equipo un material
que apague el fuego y que pueda ser vertido sobre estos dispositivos eléctricos.
4.2.2 – Mantenimientos

72
Los mantenimientos son medidas de control de correcto funcionamiento del
servidor y que sirve para observar el rendimiento con el que progresa el sistema y
que este no disminuya en cada sesión que se de mantenimiento. La aplicación
del mantenimiento es para verificar que el equipo seguirá trabajando en óptimas
condiciones. Para ello hay que tener controles de seguridad altos que nos ayude
que el servidor siga funcionando bien.
Entre las medidas que podemos mencionar, están las siguientes:
Aseo mensual con supervisión
En este aseo debe haber dos personajes claves para que se pueda dar tal
limpieza del área de los servidores. El oficial de seguridad y la persona de TI
deben coordinar, validar, verificar que el personal de aseo entrante cumpla con los
objetivos de visita. Además que estas personas deben ser vigiladas por las
cámaras de vigilancia mencionadas anteriormente.
Mantenimiento preventivo de equipos
Para evitar que ocurra malfuncionamiento en los equipos hay revisar diferentes
características que hagan que estos puedan tener un desajuste más adelante.
Por lo que debe haber un personal calificado del grupo de TI que verifique la
condición de los servidores. De otro modo si este servicio se da por personal
externo, deben estar presente y sincronizados los 3 elementos mencionados en el
punto 1 (oficial de seguridad, persona encargada de TI y la video-vigilancia).
Verificar que todas las actividades del plan de mantenimiento sean
cumplidas.
La persona de TI en coordinación con una mesa de ayuda que se compone de
vicepresidentes y personas de alto rango en el áreas de tecnología de la
información deben validar cuales son las mejores acciones a tomar en cuenta para
coordinar mantenimientos, revisiones de equipo, test de rendimiento, instalaciones
de actualizaciones o algún nuevo sistema de protección a implementar, entre
muchas otras opciones.
Mantenimiento correctivo se canaliza a través de coordinación de asistencia
técnica.
El encargado de TI en conjunto con el personal que da mantenimiento a los
servidores deben verificar que se cumpla con el plan y verificar que todo el
manteamiento programado haya cumplido con los puntos de forma estricta, para
que ningún elemento se quede por fuera.
4.2.3 – Medidas de seguridad

73
Entre algunas de las medidas de protección y prohibición que podemos destacar
además de los mencionados anteriormente, están las siguientes:
1. No situar equipos en sitios altos para evitar caídas.
2. No colocar elementos móviles sobre los equipos para evitar que caigan sobre
ellos.
3. Separar los equipos de las ventanas para evitar que caigan por ellas o qué
objetos lanzados desde el exterior los dañen.
4. Utilizar fijaciones para elementos críticos.
5. Colocar los equipos sobre plataformas de goma para que esta absorba las
vibraciones.
6. Poseer un botiquín para cualquier accidente que pueda ocurrir en las
instalaciones por alguna actividad que se desarrolle dentro de las
instalaciones.
7. Poseer un extintor por cualquier material inflamable que produzca un conato de
incendio y este no esté cerca de equipos eléctricos o posea una espuma capaz
de ser regada sobre equipo eléctrico sin provocar cortocircuitos.
8. No consumir alimentos dentro de las instalaciones de los servidores ya que
estos atraen hormigas y roedores que son capaces de dañar el equipo
computacional que se encuentra dentro de las instalaciones.
9. No acumular material inflamable que pueda ser productor de incendios grandes
en el cuarto de servidores. No se debe tener cartón, plástico ni papelerías
cerca de los equipos computacionales.
10.No fumar, ya que esto puede activar las alarmas de incendio y provocar falsas
alarmas al equipo encargado del área de servidores.
4.3 - Seguridad pre-arranque del servidor
4.3.1 – Copias de seguridad
Es evidente que es necesario establecer una política adecuada de copias de
seguridad en cualquier organización; al igual que sucede con el resto de equipos y
sistemas, los medios donde residen estas copias tendrán que estar protegidos
físicamente; de hecho quizás deberíamos de emplear medidas más fuertes, ya
que en realidad es fácil que en una sola cinta haya copias de la información
contenida en varios servidores.
Lo primero que debemos pensar es dónde se almacenan los dispositivos donde se
realizan las copias. Un error muy habitual es almacenarlos en lugares muy
cercanos a la sala de operaciones, cuando no en la misma sala; esto, que en
principio puede parecer correcto (y cómodo si necesitamos restaurar unos
archivos) puede convertirse en un problema serio si se produce cualquier tipo de
desastre (como p. ejemplo: un incendio). Hay que pensar que en general
el hardware se puede volver a comprar, pero una pérdida de información puede
ser irreemplazable.

74
Así pues, lo más recomendable es guardar las copias en una zona alejada de la
sala de operaciones; lo que se suele recomendar es disponer de varios niveles de
copia, una que se almacena en una caja de seguridad en un lugar alejado y que
se renueva con una periodicidad alta y otras de uso frecuente que se almacenan
en lugares más próximos (aunque a poder ser lejos de la sala donde se
encuentran los equipos copiados).
Para proteger más aun la información copiada se pueden emplear mecanismos de
cifrado, de modo que la copia que guardamos no sirva de nada si no disponemos
de la clave para recuperar los datos almacenados.
4.3.2 – Soportes no electrónicos
Otro elemento importante en la protección de la información son los elementos no
electrónicos que se emplean para transmitirla, fundamentalmente el papel. Es
importante que en las organizaciones que se maneje información confidencial se
controlen los sistemas que permiten exportarla tanto en formato electrónico como
en no electrónico (impresoras, plotters, faxes, teletipos,etc).
Cualquier dispositivo por el que pueda salir información de nuestro sistema ha de
estar situado en un lugar de acceso restringido; también es conveniente que sea
de acceso restringido el lugar donde los usuarios recogen los documentos que
lanzan a estos dispositivos.
Además de esto es recomendable disponer de trituradoras de papel para destruir
todos los papeles o documentos que se quieran destruir, ya que evitaremos que
un posible atacante pueda obtener información rebuscando en nuestra basura.
4.3.3 – El sistema de arranque en BIOS
Todas las estaciones de trabajo actuales disponen de algún sitema básico de
arranque grabado en una memoria de sólo lectura (generalmente una EPROM,
que permite actualizarla) denominado firmware.
Generalmente el acceso a la BIOS se hace pulsando una o varias teclas cuando
arranca el equipo; una vez pulsado se entra en un entorno de configuración
sencillo, habitualmente en modo texto, que nos permite definir parámetros del
sistema como la fecha y la hora, la geometría y tamaño de los discos, si debemos
habilitar o no determinadas controladoras, etc.
Uno de los parámetros que más nos interesa desde el punto de vista de la
seguridad es la elección de los dispositivos de arranque, ya que generalmente es
la BIOS la que decide el orden en el que se intenta arrancar empleando distintos
soportes (disco duro, CD-ROM, floppy, ...). Si permitimos el arranque de disquete
o CD-ROM es extremadamente fácil para cualquiera que se siente ante el equipo
el arrancarlo con cualquier cosa y modificar nuestros sistemas de ficheros.

75
4.3.4 – Configuración de contraseña
Aunque configuremos correctamente los dispositivos de arranque es necesario
limitar el acceso a la BIOS para que nadie pueda entrar en ella de nuevo y
cambiar los ajustes. Para ello la mayor parte de las BIOS ofrecen la posibilidad de
establecer dos contraseñas independientes; una para impedir el acceso a la
configuración de la BIOS (hay que introducirla despues de pulsar la secuencia de
teclas que carga el programa de configuración de la BIOS) y otra de arranque (si
no se introduce la clave no se inicia el procedimiento de arranque y por tanto no se
puede ejecutar nada).
Por último mencionar que la BIOS tiene un sistema de carga de S. O.
extremadamente simple: en el caso de los discos duros se carga el programa que
hay en unos sectores concretos del disco (el MBR o Master Boot Record) o, en
caso de no haber nada en ese sector, lo que hay en el sector de arranque de la
partición marcada como activa.
Por todo esto, es imposible usar la BIOS para pasarle parámetros a un sistema
operativo o simplemente decidir cuál vamos a arrancar si tenemos más de uno. Si
instalamos linux en el equipo es habitual instalar en el disco algún bootloader que
nos permita arrancar varios sistemas operativos distintos (o incluso el mismo con
parámetros diferentes) como LILO o GRUB.
Riesgos y mitigaciones
4.4 – Riesgo Inyección
Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no
confiables son enviados a un intérprete como parte de un comando o consulta.
Los datos hostiles del atacante pueden engañar al intérprete en ejecutar
comandos no intencionados o acceder datos no autorizados.
4.4.1 – Mitigación
Evitar una inyección requiere mantener los datos no confiables separados de
los comandos y consultas. Para prevenir este tipo de riesgo podemos seguir los
puntos a continuación:
1. La opción preferida es usar una API segura la cual evite el uso de intérpretes
por completo o provea una interface parametrizada. Sea cuidadoso con las
APIs, como los procedimiento almacenados, que son parametrizados, pero
que aún pueden introducir inyecciones en el motor del interprete.
2. Si una API parametrizada no está disponible, debe codificar
cuidadosamente los caracteres especiales, usando la sintaxis de escape

76
específica del intérprete.
3. La validación de entradas positiva o de "lista blanca" también se recomienda,
pero no es una defensa integral dado que muchas aplicaciones requieren
caracteres especiales en sus entradas. Si se requieren caracteres
especiales, solo las soluciones anteriores 1. y 2. harían su uso seguro.
!
NOTA
Muchas aplicaciones web, como los CMS (Joomla, Drupal, Wordpress) entre
otras herramientas como los frameworks de desarrollo, se encuentran con
validaciones para evitar este tipo de riesgo. Sin embargo nosotros
complementamos nuestra aplicación con a herramienta Mod Security (Web
Application Firewall).
4.5 – Pérdida de Autenticación y Gestión de Sesiones
Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones
son frecuentemente implementadas incorrectamente, permitiendo a los atacantes
comprometer contraseñas, claves, token de sesiones, o explotar otras fallas de
implementación para asumir la identidad de otros usuarios. Esta se debe
principalmente a lo siguiente:
1. Falta de políticas de seguridad en las aplicaciones.
2. Perfiles o permisos de acceso a las aplicaciones inadecuados.
La recomendación principal para una organización es facilitar a los
desarrolladores:
1. Un único conjunto de controles de autenticación y gestión de sesiones fuerte.
Dichos controles deberán conseguir:
a. Cumplir con todos los requisitos de autenticación y gestión de sesiones
definidos
b. Tener un interfaz simple para los desarrolladores.
2. Se debe realizar un gran esfuerzo en evitar vulnerabilidades de XSS que
podrían ser utilizadas para robar ID de sesión.
!
NOTA
Para mitigar esté riesgo debemos tomar en cuenta a parte de las
herramientas como los WAF implementados:
 Definir los Procesos, Organización y Relaciones de TI: Segregación
de Funciones y Establecimiento de Roles y Responsabilidades.

77
 Garantizar la seguridad de los sistemas: Administración de Cuentas
del Usuario.
4.6 – Secuencia de Comandos en Sitios Cruzados (XSS)
Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los
envía al navegador web sin una validación y codificación apropiada. XSS permite
a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los
cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al
usuario hacia un sitio malicioso.
Prevenir XSS requiere mantener los datos no confiables separados del contenido
activo del navegador.
1. La opción recomendada es codificar los datos no confiables basados en el
contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL) donde serán
ubicados.
2. También se recomienda la validación de entradas positiva o de “lista blanca”,
considerando que esta técnica no es una defensa completa ya que muchas
aplicaciones requieren aceptar caracteres especiales como parte de las
entradas válidas. Dicha validación debe, en la medida de lo posible, validar el
largo, los caracteres, el formato y reglas de negocio que debe cumplir el dato
antes de aceptarlo como entrada.
4.7 – Referencia Directa Insegura a Objetos
Una referencia directa a objetos ocurre cuando un desarrollador expone una
referencia a un objeto de implementación interno, tal como un fichero, directorio, o
base de datos. Sin un chequeo de control de acceso u otra protección, los
atacantes pueden manipular estas referencias para acceder datos no autorizados.
Requiere seleccionar una forma de proteger los objetos accesibles por cada
usuario (identificadores de objeto, nombres de fichero):
1. Utilizar referencias indirectas por usuario o sesión. Esto evitaría que los
atacantes accedieren directamente a recursos no autorizados. Por
ejemplo, en vez de utilizar la clave del recurso de base de datos, se
podría utilizar una lista de 6 recursos que utilizase los números del 1 al 6
para indicar cuál es el valor elegido por el usuario. La aplicación tendría que

78
realizar la correlación entre la referencia indirecta con la clave de la
base de datos correspondiente en el servidor.
2. Comprobar el acceso. Cada uso de una referencia directa a un objeto de una
fuente que no es de confianza debe incluir una comprobación de control
de acceso para asegurar que el usuario está autorizado a acceder al objeto
solicitado.
!
NOTA
La implementación de scripts y códigos de terceros da como resultado
este tipo de riesgo, donde se efectúa consultas directas a tablas o
registros de base de datos. Cuando se utilizan códigos de terceros es
obligatorio el análisis de todo el código antes de su implementación.
4.8 – Configuración de Seguridad Incorrecta
Una buena seguridad requiere tener definida e implementada una configuración
segura para la aplicación, marcos de trabajo, servidor de aplicación, 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 librerías de
código utilizadas por la aplicación.
Las recomendaciones son las siguientes:
1. Un proceso rápido, fácil y repetible de fortalecimiento para obtener un entorno
apropiadamente asegurado. Los entornos de Desarrollo, QA y Producción
deben ser configurados idénticamente (con diferentes contraseñas usadas en
cada entorno). Este proceso puede ser automático para minimizar el esfuerzo
de configurar un nuevo entorno seguro.
2. Un proceso para mantener y desplegar las nuevas actualizaciones y parches
de software de una manera oportuna para cada entorno. Debe incluir también
todas las librerías de código.
3. Una fuerte arquitectura de aplicación que proporcione una separación segura y
efectiva entre los componentes.
4. Considere ejecutar escaneos y realizar auditorías periódicamente para ayudar
a detectar fallos de configuración o parches omitidos.
4.9 – Exposición de datos sensibles
Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como
números de tarjetas de crédito o credenciales de autenticación. Los atacantes
pueden robar o modificar tales datos para llevar acabo fraudes, robos de identidad

79
u otros delitos. Los datos sensibles requieren de métodos de protección
adicionales tales como el cifrado de datos, así como también de precauciones
especiales en un intercambio de datos con el navegador.
Para la mitigación de riesgos de los datos sensibles, se deben realizar como
mínimo lo siguiente:
1. Considere las amenazas de las cuáles protegerá los datos (ej: atacante
interno, usuario externo), asegúrese de cifrar los datos sensibles almacenados
o en tráfico de manera de defenderse de estas amenazas.
2. No almacene datos sensibles innecesariamente. Descártelos apenas sea
posible. Datos que no se poseen no pueden ser robados.
3. Asegúrese de aplicar algoritmos de cifrado fuertes y estándar así como claves
fuertes y gestiónelas de forma segura. Considere utilizar módulos criptográficos
validados como FIPS 140.
4. Asegúrese que las claves se almacenan con un algoritmo especialmente
diseñado para protegerlas como ser bcrypt, PBKDF2 o scrypt.
5. Deshabilite el autocompletar en los formularios que recolectan datos sensibles.
Deshabilite también el cacheado de páginas que contengan datos sensibles.
!
NOTA
El siguiente riesgo, fue una de las vulnerabilidades encontradas en
nuestro servidor web al realizar el análisis de vulnerabilidades/ Ethical
hacking. Específicamente los puntos 2, 4 y 5. Se Procedió a añadir a la
línea base la eliminación de historial de la consola.
4.10 – Ausencia de Control de Acceso a Funciones
La mayoría de aplicaciones web verifican los derechos de acceso a nivel de
función antes de hacer visible en la misma interfaz de usuario. A pesar de esto,
las aplicaciones necesitan verificar el control de acceso en el servidor cuando se
accede a cada función. Si las solicitudes de acceso no se verifican, los atacantes
podrán realizar peticiones sin la autorización apropiada.
La aplicación debería tener un módulo de autorización consistente y fácil de
analizar, invocado desde todas las funciones de negocio.
Frecuentemente, esa protección es provista por uno o más componentes
externos al código de la aplicación.
1. El proceso para gestión de accesos y permisos debería ser actualizable y
auditable fácilmente. No lo implemente directamente en el código sin utilizar
parametrizaciones.
2. La implementación del mecanismo debería negar todo acceso por defecto,

80
requiriendo el establecimiento explícito de permisos a roles específicos para
acceder a cada funcionalidad.
3. Si la funcionalidad forma parte de un workflow, verifique y asegúrese que las
condiciones del flujo se encuentren en el estado apropiado para permitir el
acceso.
4.11 – Falsificación de Peticiones en Sitios Cruzados (CSRF)
Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una
petición HTTP falsificado, incluyendo la sesión del usuario y cualquier otra
información de autenticación incluida automáticamente, a una aplicación web
vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar
pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes
de la víctima.
La prevención CSRF por lo general requiere la inclusión de un token no
predecible en cada solicitud HTTP. Estos tokens deben ser, como mínimo, únicos
por cada sesión del usuario.
1. La opción recomendada es incluir el token único en un campo oculto. Esto
hace que el valor de dicho campo se envíe en el cuerpo de la solicitud HTTP,
evitando su inclusión en la URL, sujeta a mayor exposición.
2. El token único también puede ser incluido en la propia URL, o un parámetro de
la misma. Sin embargo, esta práctica presenta el riesgo e inconveniente de
que la URL sea expuesta a un atacante, y por lo tanto, pueda comprometer el
token secreto.
3. Requiera que el usuario vuelva a autenticarse, o pruebas que se trata de un
usuario legitimo (por ejemplo mediante el uso de CAPTCHA) pueden también
proteger frente ataques de tipo
CSRF.
4.12 – Utilización de componentes con vulnerabilidades
conocidas
Algunos componentes tales como las librerías, los frameworks y otros módulos de
software casi siempre funcionan con todos los privilegios. Si se ataca un
componente vulnerable esto podría facilitar la intrusión en el servidor o una
perdida seria de datos. Las aplicaciones que utilicen componentes con
vulnerabilidades conocidas debilitan las defensas de la aplicación y permiten
ampliar el rango de posibles ataques e impactos.

81
No usar componentes que no ha codificado. La mayoría de los proyectos de
componentes no crean parches de vulnerabilidades de las versiones más
antiguas. A cambio, la mayoría sencillamente corrige el problema en la versión
siguiente. Por lo tanto, actualizar a esta nueva versión es crítico.
Proyectos de software debieran tener un proceso para:
1. Identificar todos los componentes y la versión que están ocupando, incluyendo
dependencias
2. Revisar la seguridad del componente en bases de datos públicas, lista de
correos del proyecto, y lista de correo de seguridad, y mantenerlos
actualizados.
3. Establecer políticas de seguridad que regulen el uso de componentes, como
requerir ciertas prácticas en el desarrollo de software, pasar test de seguridad,
y licencias aceptables.
4. Sería apropiado, considerar agregar capas de seguridad alrededor del
componente para deshabilitar funcionalidades no utilizadas y/o asegurar
aspectos débiles o vulnerables del componente.
4.13 – Redirecciones y reenvios no validados
Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia
otras páginas o sitios web, y utilizan datos no confiables para determinar la página
de destino. Sin una validación apropiada, los atacantes pueden redirigir a las
víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder
páginas no autorizadas.
El uso seguro de reenvíos y redirecciones puede realizarse de varias maneras:
1. Simplemente evitando el uso de redirecciones y reenvíos.
2. Si se utiliza, no involucrar parámetros manipulables por el usuario para definir
el destino. Generalmente, esto puede realizarse.
Si los parámetros de destino no pueden ser evitados, asegúrese que el valor
suministrado sea válido y autorizado para el usuario. Se recomienda que el valor
de cualquier parámetro de destino sea un valor de mapeo, el lugar de la dirección
URL real o una porción de esta y en el código del servidor traducir dicho valor a la
dirección URL de destino.

82
El siguiente trabajo hemos verificado la importancia de cumplir con todos los
niveles la seguridad de los sistemas, principalmente en el nivel físico, quedó
comprobado como al descuidar un aspecto tan importante como esté nos afectó a
la hora de realizar un análisis de vulnerabilidades por parte de los compañeros
Análisis de vulnerabilidades/Ethical Hacking. Independientemente del escenario
planteado por nosotros, donde explicamos nuevamente que debido a la limitantes
de la tecnología utilizada en este caso software libre para fines educativos como
lo es virtualbox no permitía el añadir la contraseña de bios, evidentemente
aquellas personas malintencionadas no tendrán escrúpulos a la hora de realizar
actividades ilegales y a la hora de extraer información confidencial en nuestras
empresas.
En cuanto a las herramientas utilizadas comprobamos la efectividad de las
mismas, principalmente del WAF, disminuyendo los riesgos de ataques como
DDOS, XSS, sql injection, entre otros del top 10 de OWASP. Sin embargo esto
solo no es suficiente y debemos complementar estás herramientas con la
eliminación de las configuraciones básicas y ajustes predeterminados en los
servidores web.
Conclusión

83
1. Clickjacking
Consultado el 30 de noviembre de 2015. Disponible en:
https://es.wikipedia.org/wiki/Clickjacking
2. Cookie (informática)
https://es.wikipedia.org/wiki/Cookie_(inform%C3%A1tica)
3. Cross-site scripting
https://es.wikipedia.org/wiki/Cross-site_scripting
4. Setup Apache Virtual Hosts On Ubuntu 15.10
http://www.unixmen.com/setup-apache-virtual-hosts-on-ubuntu-15-10/
5. Como habilitar perfect forward secrecy
Consultado el 29 de noviembre 2015. Disponible en:
http://stackoverflow.com/questions/17308690/how-do-i-enable-perfect-forward-
secrecy-by-default-on-apache
6. Como parchar, Poodle vulnerabilidad SSLv3
Consultado el 29 noviembre 2015. Disponible en:
http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-
poodle-vulnerability-cve-2014-3566
Bibliografía

84
7. Habilitar HTTPS en Onwlcloud
http://www.slsmk.com/enabling-https-access-to-owncloud/
8. 13 Apache Web Server Security and Hardening Tips
http://www.tecmint.com/apache-security-tips/
9. Security Hardening en Ubuntu
http://blog.mattbrock.co.uk/hardening-the-security-on-ubuntu-server-14-04/
10.Quit Bash Shell without Saving Bash History
Consultado el 27 de noviembre de 2015. Disponible en: http://www.if-not-true-
then-false.com/2010/quit-bash-shell-without-saving-bash-history/

Seguridad en SIstemas Operativos *Nix

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Seguridad en SIstemas Operativos *Nix

Similaire à Seguridad en SIstemas Operativos *Nix (20)

Plus de José Moreno

Plus de José Moreno (15)

Dernier

Dernier (20)

Seguridad en SIstemas Operativos *Nix