proceso de hardening de servidor web - ua

PROCESO DE HARDENING DE SERVIDOR WEB

ERICK GIOVANNI VARELA GUZMÁN UNIVERSIDAD DE ALICANTE

SEGURIDAD Y PRIVACIDAD 2020

2

Contenido

1. Introducción. ......................................................................................................................... 3

1.1. Definición del problema. .................................................................................................. 3

1.2. Propuesta de trabajo. ....................................................................................................... 3

1.3. Configuraciones iniciales de los servidores. ..................................................................... 5

1.3.1. Servidor Apache. .............................................................................................................. 5

1.3.2. Servidor Nginx. ................................................................................................................. 5

1.4. Objetivos. ......................................................................................................................... 6

1.5. Justificación. ..................................................................................................................... 6

1.6. Metodología utilizada. ...................................................................................................... 6

2. Servidor web Apache. ........................................................................................................... 7

2.1. Editando configuración por defecto de Apache. .............................................................. 7

2.2. Verificando el usuario encargado de ejecutar apache. .................................................. 10

2.3. Configurando Headers de respuesta .............................................................................. 10

2.4. TLS. ................................................................................................................................. 11

2.4.1. Configurando TLS............................................................................................................ 11

2.5. Instalando y configurando modSecurity. ....................................................................... 14

2.5.1. Configurando mod_security. .......................................................................................... 14

3. Servidor web Nginx. ............................................................................................................ 15

3.1. Editando configuración por defecto de Nginx................................................................ 15

3.2. Configurando Headers de respuesta .............................................................................. 16

3.3. TLS. ................................................................................................................................. 16

3.4. Instalando y configurando mod_security. ...................................................................... 18

3.4.1. Obteniendo y compilando el conector para Nginx. ....................................................... 18

3.4.2. Configurando mod_security. .......................................................................................... 18

3.4.3. Implementando mod_security en la configuración de Nginx. ....................................... 19

4. Pruebas de seguridad. ......................................................................................................... 20

4.1. Pruebas de seguridad utilizando Arachni. ...................................................................... 20

4.1.1. Resultado de pruebas servidor inicial Apache. .............................................................. 20

4.1.2. Resultado de pruebas servidor seguro Apache. ............................................................. 21

4.1.3. Resultado de pruebas servidor inicial Nginx. ................................................................. 21

4.1.4. Resultado de pruebas servidor seguro Nginx. ................................................................ 22

4.2. Pruebas de seguridad utilizando Nikto........................................................................... 22

4.2.1. Resultado de pruebas servidor inicial Apache. .............................................................. 23

4.2.2. Resultado de pruebas servidor seguro Apache. ............................................................. 23

4.2.3. Resultado de pruebas servidor inicial Nginx. ................................................................. 23

4.2.4. Resultado de pruebas servidor seguro Nginx. ................................................................ 24

4.3. Análisis de resultados. .................................................................................................... 24

5. Conclusiones........................................................................................................................ 25

6. Bibliografía. ......................................................................................................................... 26

3

1. Introducción.

1.1. Definición del problema.

El servidor web es uno de los elementos cruciales en toda aplicación basada en web,

convirtiendo a este servicio en uno de los objetivos principales para atacar. Es un grave error

pensar que la configuración por defecto es la configuración óptima para defenderse de posibles

ataques, al contrario, permite a un atacante prepararse en mejor medida para realizar una

acción que puede provocar serios daños o perdidas.

Según el reporte Web application vulnerabilities: statistics for 2018 [1], de la entidad Positive

Technologies, proveedor de soluciones de seguridad corporativa, revela que, del 100% de sitios

web escaneados a lo largo del año 2018, el 67% de ellos, presentaron problemas de seguridad

que hacían del sitio web altamente vulnerable. (Ilustración 1-1).

Ilustración 1-1. Sitios web clasificados por gravedad de vulnerabilidad, gráfico tomado de Web application vulnerabilities: statistics for 2018. Fuente: Positive Technologies. [1]

Por otro lado, The Open Web Application Security Project (OWASP, por sus siglas en inglés), en

su reporte The Ten Most Critical Web Application Security Risks [2], realiza un análisis sobre las

vulnerabilidades más comunes encontradas en servicios web:

1. Inyección.

2. Implementación incorrecta de sesiones y autenticación en sitios web.

3. Exposición de datos sensibles.

4. Mala gestión de entidades externas XML (XXE).

5. Problemas de control de acceso.

6. Mala gestión configuración de seguridad.

7. Cross-Site Scripting XSS.

8. Deserialización insegura.

9. Uso de componentes con vulnerabilidades conocidas.

10. Insuficiente registro y monitoreo.

1.2. Propuesta de trabajo.

Ante esta problemática, se plantea un proceso de investigación de las prácticas de seguridad

recomendadas e implementarlas sobre un servidor web en un escenario de trabajo controlado

utilizando máquinas virtuales. Esta investigación se enfoca en el punto 6, “mala gestión de

configuración se seguridad” de la lista de vulnerabilidades comunes de OWASP [2], y que, en

alguna medida, está relacionado con el resto de las vulnerabilidades listadas.

4

Los servidores web a implementar serán Apache [3 y Nginx [4], debido a su gran popularidad.

Según los reportes generados por la entidad w3techs [5], Solo estas dos plataformas abarcan el

71,8% de servidores web implementados a nivel mundial, tal como lo muestra la gráfica de la

ilustración 1-2.

Ilustración 1-2. Top servidores web, fuente: w3techs.com [3]

Para poder realizar todas las pruebas y configuraciones, se ha implementado una arquitectura

de red utilizado el software de simulación de redes GNS3 [6] en su versión 2.2.5. Se ha creado la

siguiente topología de red:

Ilustración 1-3. Topología de red utilizada en las pruebas

La topología de red es simple, pero cumple con el objetivo de establecer un escenario controlado

y realista de pruebas, donde los clientes acceden a un servidor web desde redes externas y fuera

del dominio de broadcast del servidor. La información de las redes utilizadas es la siguiente:

Tabla 1-1. Información de red utilizada en la simulación.

Red ID Máscara de red Gateway

Red servidor 100.30.34.0 255.255.255.0 100.30.34.1

Red cliente 200.100.40.0 255.255.255.0 200.100.40.1

La simulación se complementa con tres máquinas virtuales (VM) basadas en VirtualBox [7]. GNS3

cuenta con la funcionalidad de poder integrar VMs a su entorno, como nodos capaces de

interactuar entre ellos según las condiciones establecidas en la red creada en GNS3 [6]. La

información de las máquinas virtuales se muestra en la siguiente tabla:

5

Tabla 1-2. Características de las máquinas virtuales utilizadas en la simulación.

Característica Servidor Apache Servidor Nginx Cliente

Nombre: www.sp.server.net www.sp2.server.net Cliente

Sistema operativo:

Ubuntu Server 18.04 x64

Ubuntu Server 20.04 x64

Ubuntu desktop 18.04 x64

RAM, HD: 1GB, 10GB 1GB, 10GB 2GB, 10GB

Configuración de red:

IP: 100.30.34.2/24 Gateway: 100.30.34.1

IP: 100.30.34.3/24 Gateway: 100.30.34.1

IP: 200.100.40.2/24 Gateway: 200.100.40.1

1.3. Configuraciones iniciales de los servidores.

1.3.1. Servidor Apache.

Se ha implementado una pila LAMP (Linux, Apache, MySQL, PHP). Los servicios instalados son:

▪ Servidor web: Apache/2.4.29 (Ubuntu) [3]

▪ Gestor de base de datos: MySQL 5.7.29-0Ubuntu0.18.04.1 [8]

▪ Contenido dinámico: PHP 7.2.24-0ubuntu0.18.04.3 [9]

▪ Servidor DNS: BIND 9.11.3-1ubuntu1.11-Ubuntu [10]

En el servicio DNS, se ha configurado el nombre de dominio “server.net” y las direcciones

“www.sp” que apunta al servidor apache y “www.sp2” que apunta al servidor Nginx, de esta

manera, será posible acceder desde el cliente a través de las direcciones “www.sp.server.net” y

“www.sp2.server.net” respectivamente.

Este servidor implementa, además, Apache2 como servicio web complementado con PHP7.2

como gestor de contenido dinámico y MySql 5.7 como gestor de base de datos. Se ha creado

una página web sencilla ubicada en el directorio /var/www/ que contiene un formulario para

introducir datos que serán guardados en una tabla en MySql.

1.3.2. Servidor Nginx.

Se ha implementado una pila LEMP (Linux, Nginx, MySQL, PHP). Los servicios instalados son:

▪ Servidor web: nginx/1.17.10 (Ubuntu) [4]

▪ Gestor de base de datos: MySQL 8.0.20-0Ubuntu0.20.04.1 [8]

▪ Contenido dinámico: PHP 7.4.3 [9]

Este servidor implementa Nginx como servicio web complementado con PHP7.4 como gestor de

contenido dinámico y MySql como gestor de base de datos. Se ha creado una página web sencilla

ubicada en el directorio /var/www/ que contiene un formulario para introducir datos que serán

guardados en una tabla en MySql.

Ilustración 1-4. Páginas web disponibles en Apache y Nginx respectivamente.

6

1.4. Objetivos.

▪ Realizar un estudio de la situación actual con respecto a problemas de vulnerabilidad y

buenas prácticas se seguridad para servidores web y poder realizar la implementación

de estas medidas en un servidor Apache web.

Objetivos específicos.

▪ Estudiar herramientas y métodos de hardening para implementar en servidores web

basados en ambientes Linux.

▪ Identificar riesgos, vulnerabilidades o fallas de seguridad que implica la configuración

por defecto en servidores que ofrecen servicios web.

▪ Implementar medidas de hardening y buenas prácticas de seguridad en un servidor web

ejecutándose sobre sistema operativo Linux.

▪ Documentar en una memoria el proceso de investigación e implementación de

seguridad en un servidor web.

1.5. Justificación.

Con la implementación de tecnologías de la información y la comunicación (TIC) toda

organización obtiene una serie de herramientas imprescindibles para su crecimiento, logrando

reducir costos y agilizar procesos administrativos, pero al mismo tiempo e inevitablemente estas

acarrean una serie de nuevos retos con respecto a la seguridad de los datos de la organización.

Algo tan simple como no considerar modificar la configuración por defecto de una serie de

servicios TIC, "porque parece que así funcionan bien", hace de la organización una víctima

potencial para un atacante, que, con la suficiente experiencia, puede aprovechar cada hueco de

seguridad que implican las configuraciones por defecto de elementos TIC, comprometiendo la

disponibilidad, confidencialidad e integridad de los datos de la organización y servicios que esta

ofrece.

Consciente de esta situación, esta investigación nace como acercamiento introductorio e inicial

para el aseguramiento un sistema TIC de una organización. Debido a la amplitud del área técnica,

el desarrollo de este proyecto está enfocado en la implementación de políticas y buenas

prácticas de seguridad sobre un servidor web instalado en un Sistema Operativo basado en Unix.

poniendo en conocimiento las diferentes herramientas y técnicas disponibles para el

aseguramiento y detección oportuna de vulnerabilidades que son encontradas en la

configuración por defecto de un servidor web.

1.6. Metodología utilizada.

La metodología empleada en el desarrollo de este trabajo obedece a un esquema de cuatro

fases [11]:

1. Contextualización. Se hace un análisis de las investigaciones realizadas por entidades que

se encargan de documentar el estado actual en materia de seguridad web, detectando

cuales son las vulnerabilidades más comunes de encontrar en este contexto. Además, se

realiza una búsqueda de los servidores web más utilizados, con el objetivo de seleccionar

uno y poder realizar pruebas de configuración y aplicar buenas prácticas de seguridad.

7

2. Investigación de buenas prácticas. Se realiza una investigación sobre técnicas,

recomendaciones y buenas prácticas de seguridad, con el fin de minimizar el posible impacto

de un ataque al servidor web, debido a la reducción de la cantidad de puntos vulnerables

causados por una configuración por defecto.

3. Aplicación: Se implementa un laboratorio virtual como ambiente de trabajo controlado

utilizando software de virtualización de Sistemas Operativos y redes de computadoras, el

objetivo de esta fase es aplicar las buenas prácticas encontradas en la fase anterior.

4. Pruebas. En esta fase, se realizan pruebas funcionales para encontrar vulnerabilidades en

los sistemas configurados, existen diversas herramientas para poder realizar este tipo de

pruebas, en este trabajo se hace una investigación sobre cómo utilizar las herramientas

Nikto [12] y Arachni [13], herramientas de código abierto que se enfocan en el análisis de

vulnerabilidades en servidores web.

Es recomendable realizar este proceso de manera iterativa, partiendo de los resultados del

análisis de la fase cuatro para poder tomar las respectivas medidas de seguridad, logrando en

cada iteración un sistema con menos vulnerabilidades.

2. Servidor web Apache.

El centro de media de Panda Security recomienda que la primera regla de seguridad a

implementar cuando se hace uso de un nuevo servicio ya sea a nivel de hardware o software, es

nunca mantener la configuración por defecto [14]. En el caso de Apache HTTP, este cuenta con

un buen historial con respecto a tomar en cuenta el aspecto de la seguridad y, además, dispone

de una gran comunidad de desarrolladores altamente preocupados por los problemas de

seguridad [15]. A pesar de esto, es recomendable no mantener la configuración por defecto.

Como primer ejercicio, se realiza una investigación para implementar una serie de

configuraciones adicionales a la que se instala por defecto.

2.1. Editando configuración por defecto de Apache.

Sobre sistemas operativos Linux Debian/Ubuntu, el fichero de configuración de apache se llama

“apache2.conf”. Este fichero está ubicado en el directorio /etc/apache2/. El proceso de

hardening inicia con la modificación y adición de algunos sencillos parámetros de configuración

en este fichero, el resultado se puede observar en la ilustración 2-1, por cuestión de espacio se

han eliminado la mayoría de los bloques de comentarios.

L Configuración /etc/apache2/apache2.conf 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

# This is the main Apache server configuration file.

# The directory where shm and other runtime files will be stored.

DefaultRuntimeDir ${APACHE_RUN_DIR}

# PidFile: The file in which the server should record its process

PidFile ${APACHE_PID_FILE}

#SP-Server Configuration

Timeout 30

# KeepAlive: Whether or not to allow persistent

KeepAlive On

# MaxKeepAliveRequests: The maximum number of requests to allow

during a persistent connection

MaxKeepAliveRequests 100


KeepAliveTimeout 3

# These need to be set in /etc/apache2/envvars

User ${APACHE_RUN_USER}

Group ${APACHE_RUN_GROUP}

8

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

# HostnameLookups: Log the names of clients or just their IP addresses

HostnameLookups Off

# ErrorLog: The location of the error log file.

ErrorLog ${APACHE_LOG_DIR}/error.log

# LogLevel: Control the severity of messages logged to the error_log.

LogLevel warn

# Include module configuration:

IncludeOptional mods-enabled/*.load

IncludeOptional mods-enabled/*.conf

# Include list of ports to listen on

Include ports.conf

# Sets the default security model of the Apache2 HTTPD server.

<Directory /var/www/www.sp/>

Options None

AllowOverride None

Require all granted

<LimitExcept POST GET HEAD >

Deny from all

</LimitExcept>

</Directory>

# AccessFileName.

AccessFileName .htaccess

<FilesMatch "^\.ht">

Require all denied

</FilesMatch>

# Include generic snippets of statements

IncludeOptional conf-enabled/*.conf

# Include the virtual host configurations:

IncludeOptional sites-enabled/*.conf


ServerTokens Prod

#SP: Evitando que el servidor exponga información

ServerSignature Off

Ilustración 2-1. fichero de configuración /etc/apache2/apache2.conf

Para que las modificaciones se ejecuten, es necesario reiniciar el servicio de apache con la

instrucción systemctl restart apache2. Las modificaciones realizadas son:

▪ Parámetro Timeout: El tiempo de espera del servidor apache para cerrar una conexión, ha

sido disminuido a 30 segundos (Ilustración 2-1, línea 7). El tiempo por defecto es de 300

segundos, al reducir el tiempo de este parámetro es posible minimizar ataques de

denegación de servicio (DOS) y ataques de slowloris1. Es necesario tener en cuenta que

configurar con un valor de tiempo muy pequeño puede comprometer el rendimiento del

servidor.

▪ Parámetro KeepAliveTimeout: El tiempo de espera de solicitudes del mismo cliente en una

misma conexión ha sido reducido a 3 segundos. (Ilustración 2-1, Línea 14). El tiempo por

defecto es de 5 segundos, al reducir el tiempo de este parámetro es posible minimizar

ataques de denegación de servicio y ataques de slowloris. Es necesario tener en cuenta que

configurar con un valor de tiempo muy pequeño puede comprometer el rendimiento del

servidor.

▪ Estructura Directory: Estructura creada para configurar parámetros relacionados con el sitio

web que ofrece el servidor (Ilustración 2-1, Línea 30-37).

▪ Parámetro Options: Se ha configurado con valor de none. Esto previene el uso de varias

opciones que por defecto podrían causar problemas (Ilustración 2-1, Línea 31):

1 Slowloris es un ataque DOS donde un atacante sobrecarga un servidor abriendo y manteniendo muchas conexiones HTTP simultáneas. [16]

9

- Previene listar los directorios. Si un directorio dentro del sitio web no tiene un archivo

index (por ejemplo, index.html), mod_autoindex, retorna un listado con formato de

directorio, permitiendo al atacante saber que archivos contiene:

Ilustración 2-2. Parámetro "options" configurado con la opción "indexes".

Con el parámetro configurado con la opción none, la vista que se presenta es la

siguiente:

Ilustración 2-3, Parámetro "options" configurado con la opción "none".

- Previene la capacidad de ejecutar scripts maliciosos desde páginas SSI. Los riesgos

potenciales de permitir Server Side Includes (SSI), es que un atacante puede incrementar

la carga del servidor, además, ejecutar SSI con scripts maliciosos con los permisos de

usuario y grupo con los que se ejecuta Apache [15].

▪ Parámetro AllowOverride: Configurado con el valor de none, impide que los usuarios

configuren ficheros .htaccess que pueden invalidar características de seguridad que se

hayan configurado (Ilustración 2-1, Línea 32) [15].

▪ Estructura LimitExcept: Limita las respuestas únicamente a los métodos de solicitud

(Ilustración 2-1, Línea 34-36). Por defecto el protocolo HTTP soporta una gran cantidad de

métodos de solicitud, es un riesgo potencial no tener control sobre que métodos es posible

utilizar en una página web. Para una página web convencional, basta con los métodos POST,

GET, HEAD. El método OPTIONS fue utilizado para realizar la prueba de la ilustración 2-4t,

luego se removió. Con el comando curl, es posible verificar los métodos permitidos por el

servidor:

Ilustración 2-4. Métodos HTTP permitidos por el servidor web.

▪ Parámetro ServerTokens: Agregado con el valor Prod, que es el que menos información

ofrece del servidor (Ilustración 2-1, Línea 48). Con esto, se evita dar información importante

a un potencial atacante, como la versión del servidor, con esto, un atacante podría saber si

el servicio esta actualizado o no, o que vulnerabilidades podría explotar en base a los

problemas de seguridad encontrados en cada versión.

10

▪ Parámetro ServerSignature: Agregado con el valor off, evitando que el servidor de

información como servername, virtualhost e email de administrador (Ilustración 2-1, Línea

50).

2.2. Verificando el usuario encargado de ejecutar apache.

Apache server usualmente se ejecuta con el usuario apache, que es un usuario no privilegiado,

es decir no es capaz de ejecutar comandos de sistema y únicamente tiene acceso al directorio

relacionado con el servicio. Es una buena práctica verificar con que usuario se está ejecutando

el proceso de apache, en caso de encontrarse con un usuario con privilegios, es altamente

recomendable cambiarlo, esto es por razones de seguridad, ya que un script malicioso podría

causar mucho daño al sistema. La ilustración 2-5 muestra el resultado de ejecutar el comando

"apachectl -S" para verificar cual es el usuario responsable del proceso, además de más

información que se ha resumido al no ser relevante para esta memoria.

VirtualHost configuration: … ServerRoot: "/etc/apache2" Main DocumentRoot: "/var/www/html" Main ErrorLog: "/var/log/apache2/error.log" … PidFile: "/var/run/apache2/apache2.pid" … User: name="apache" id=1001 Group: name="apache" id=1001

Ilustración 2-5. Verificando usuario responsable del proceso apache

2.3. Configurando Headers de respuesta

Con las cabeceras HTTP (Headers) es posible para los usuarios y el servidor, enviar información

adicional junto a una petición o respuesta. Con respecto a la configuración de Headers, el

objetivo es ocultar información sensible o prevenir ciertas configuraciones que un atacante

puede explotar para lograr un fin malicioso [17].

Para configurar los headers es necesario editar el contenido del fichero /etc/apache2/conf-

available/security.conf, el resultado de la configuración se observa en la ilustración 2-6. Por

cuestión de espacio, se han removido la mayoría de los comentarios de este fichero.

L /etc/apache2/conf-available/security.conf 1

2

3

4

5

6

# Requires mod_headers to be enabled.

Header always append X-Content-Type-Options: NOSNIFF

#

Header always append X-Frame-Options: SAMEORIGIN

#

Header always append X-XSS-Protection "1; mode=block"

Ilustración 2-6. Fichero de configuración de apache /etc/apache2/conf-available/security.conf

Las modificaciones en este fichero son:

▪ Header X-Content-Type-Options: Previene ataques MIME sniffing. Los navegadores utilizan

una técnica llamada sniffing para determinar el tipo de archivo o formato de un elemento

web. Pero con esto, se crea una vulnerabilidad. El encabezado X-Content-Type-Options es

un marcador utilizado para indicar que los tipos MIME2 definidos en los encabezados no

deben cambiar ni ser rastreados [17].

2 MIME (Multipurpose Internet Mail Extensions), es un estándar que indica la naturaleza y el formato de un documento. Está definido y estandarizado en el RFC 6838 de IETF. [17]

11

▪ Header X-Frame-Options: Al configurar esta cabecera con el valor “SAMEORIGIN”, se define

que un elemento puede ser mostrado en un frame/iframe3 solo si posee el mismo origen.

Con esto se minimiza el riesgo de ataques de clickjacking. Este tipo de ataque busca que el

usuario acceda a un elemento (usualmente invisible o transparente) creyendo que lo hace

en otro (visible). Para conseguirlo, se fundamenta en una estructura de iframes [17].

▪ Header X-XSS-Protection: Configurar esta cabecera con el valor de “1; mode=block”,

permite activar en el navegador del cliente la protección XSS, y que bloquee la respuesta si

detecta un ataque. X-XSS-Protection es una característica a nivel de navegador, que impide

la carga de una página cuando se detecta un ataque de tipo Cross-Site Scripting [17]. Este

ataque busca inyectar código malicioso en páginas web confiables, permitiendo al atacante

robar información delicada, secuestrar sesiones de usuario y comprometer al navegador.

Para que el servidor se ejecute correctamente al aplicar esta configuración, es necesario

habilitar el módulo de cabeceras, luego reiniciar el servicio de Apache. La ilustración 2-7 muestra

este proceso:

# a2enmod headers # systemctl reload apache2 Ilustración 2-7. Habilitando módulo de cabeceras.

2.4. TLS.

Secure Sockets Layer (TLS), es la versión actualizada y más segura de SSL. Actualmente, TLS es la

tecnología aceptada para crear un canal seguro de comunicación entre un servidor web y un

cliente, impidiendo que un atacante lea y modifique cualquier dato que se transfiera. Cuando la

comunicación está protegida por medio de TLS, se hace uso de protocolo HTTPS en lugar de

HTTP [19].

El fundamento de TLS se basa en la combinación de dos elementos: una clave privada y un

certificado público. La clave privada es propia del servidor, y se mantiene en secreto, es utilizada

para cifrar el contenido, el certificado público se comparte con los clientes y se utiliza para poder

descifrar el contenido procedente del servidor [20].

A pesar de que existe una gran cantidad de bibliografía que vale la pena estudiar sobre TLS, esta

memoria se enfocará en su configuración.

2.4.1. Configurando TLS.

Creando la clave privada y el certificado público.

El primer paso para configurar TLS es crear la clave privada y el certificado público, se hará uso

de openssl para hacer esta configuración. La instrucción utilizada para este procedimiento es:

# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/sp-server.key -out /etc/ssl/certs/sp-server.crt

Ilustración 2-8. Creando clave privada y certificado publico auto firmados.

Durante la ejecución, Openssl solicitará información relativa al servidor. Para esta prueba la

información utilizada se muestra en la ilustración 2-9.

Country Name (2 letter cod) [AU]: ES

State or Province Name (full name) [Some-State]: Alicante

Locality Name (eg, city) []:San Vicente de Raspeig

3 Frame/Iframe: forma de organización de un documento HTML basada en marcos. [18]

12

Organization Name (eg, company) []:Universidad de Alicante

Organizational Unit Name (eg, section) []:Seguridad y privacidad

Common Name (eg, server FQDN or YOUR name) []: 100.30.34.2

Email Address []:[email protected]

Ilustración 2-9. Información ingresada durante la creación de la clave privada y certificado público.

Configurando Apache.

A continuación, se crea el fichero /etc/apache2/conf-available/ssl-params.conf, que contiene

información de configuración que se cargará en Apache. El fichero incluye información de

configuración de SSL e implementa los headers que se han configurado en la sección 2.3. Para

que sea usadas en las peticiones HTTPS. La ilustración 2-10 muestra el contenido de este fichero.

/etc/apache2/conf-available/ssl-params.conf 1

2

3

4

5

6

7

8

9

10

11

12

13

14

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

SSLHonorCipherOrder On

Header always set Strict-Transport-Security "max-age=31536000;

includeSubDomains; preload"

Header always append X-Frame-Options: SAMEORIGIN

Header always append X-Content-Type-Options: NOSNIFF

Header always append X-XSS-Protection "1; mode=block"

# Requires Apache >= 2.4

SSLCompression off

SSLUseStapling on

SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

# Requires Apache >= 2.4.11

SSLSessionTickets Off

Ilustración 2-10. Fichero de configuración SSL para Apache2.

En este fichero se implementa un nuevo encabezado cuya utilidad es específica para cuando se

han implementado las conexiones seguras utilizando SSL. El encabezado agregado es:

▪ Header Strict-Transport-Security: Este header está definido por IETF especificado en RFC

6797 y establece un mecanismo automático para redireccionar cualquier intento de un

usuario al utilizar un canal inseguro (HTTP) hacia un canal seguro (HTTPS) [17]. Los

parámetros configuradores en la cabecera son:

o max-age: el tiempo en segundos que el navegador del cliente debe recordar

hacer las conexiones por un canal seguro.

o includeSubDomains: Define que esta configuración aplica también para todos

los subdominios.

o Preload: directiva que ayuda a precargar la configuración, evita el problema del

retardo causado debido a la primera visita del sitio web.

Configurar archivo de virtual host.

Se crea el fichero /etc/apache2/sites-available/ssl.spserver.conf. En este fichero básicamente se

configura la información de un fichero virtual host típico: el ServerName, el email del

administrador y el document root del sitio web y se definen las directivas que apuntan a la clave

privada y certificado publico creados anteriormente. El fichero configurado se muestra en la

ilustración 2-11.

/etc/apache2/sites-available/ssl.spserver.conf 1

2

3

4

5

<IfModule mod_ssl.c>

<VirtualHost _default_:443>

ServerAdmin [email protected]

ServerName www.sp.server.net

DocumentRoot /var/www/www.sp

13

6

7

8

9

10

11

12

13

14

15

16

17

18


CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on

SSLCertificateFile /etc/ssl/certs/sp-server.crt

SSLCertificateKeyFile /etc/ssl/private/sp-server.key

<FilesMatch "\.(cgi|shtml|phtml|php)$">

SSLOptions +StdEnvVars

</FilesMatch>

<Directory /usr/lib/cgi-bin>

SSLOptions +StdEnvVars

</Directory>

</VirtualHost>

</IfModule>

Ilustración 2-11. Fichero de configuración de virtual host HTTPS.

Redireccionando HTTP hacia HTTPS.

Por defecto, Apache proporcionará tanto tráfico no cifrado vía HTTP como cifrado por medio de

HTTPS. Es una buena práctica configurar el archivo de virtual host HTTP para poder redireccionar

de manera automática hacia HTTPS. La ilustración 2-12 muestra la configuración realizada en el

fichero /etc/apache2/sites-available/www.sp.server.net.conf.

/etc/apache2/sites-available/www.sp.server.net.conf 1

2

3

4

5

6

7

8

<VirtualHost 100.30.34.2:80>

ServerName www.sp.server.net

ServerAdmin [email protected]

DocumentRoot /var/www/www.sp


CustomLog ${APACHE_LOG_DIR}/access.log combined

Redirect "/" "https://www.sp.server.net/"

</VirtualHost>

Ilustración 2-12. Configurando virtual host HTTP para redirección hacia HTTPS.

Aplicar configuración.

Para aplicar la configuración SSL realizada, es necesario habilitar los módulos ssl, ssl-params.conf

y el virtual host ssl.spserver.conf. Esto se realiza con las siguientes instrucciones:

# a2enmod ssl # a2enconf ssl-params # a2ensite ssl.spserver.conf

# systemctl reload apache2 Ilustración 2-13. Cargando modulo SSL, configuración SSL y Host virtual.

Verificando configuración.

Ya que el proceso de configuración SSL realizado utiliza certificados auto firmados, cuando se

intenta acceder por primera vez al sitio web desde el cliente utilizando HTTPS, el navegador

muestra una advertencia bastante intimidante de seguridad (Ilustración 2-14).

14

Ilustración 2-14. Navegador detectando certificado auto firmado.

Esto sucede porque el proceso correcto requiere de la firma de una autoridad que indique que

el sitio web es genuino y confiable [21]. Para los propósitos de esta memoria, se omitirá este

paso ya que el objetivo es la configuración y correcta implementación de SSL. Para omitir este

mensaje el cliente debe configurar de manera manual al sitio como sitio web confiable, esto solo

se realiza la primera vez que se accede a este.

La ilustración 2-15 compara la cabecera de respuesta del servidor con configuración por defecto

y con la configuración implementada en las secciones 2.1 a 2.4.

Configuración por defecto. Configuración implementada.

Ilustración 2-15. Comparación de cabeceras de respuestas de servidor inicial vs. configurado.

2.5. Instalando y configurando modSecurity.

El módulo de seguridad modSecurity es un firewall open source orientado específicamente a

aplicaciones web. Este firewall examina todas las peticiones hacia un servidor web y sus

respuestas, para ello hace uso de un set de reglas predefinidas [22][23]. Para poder instalar

mod_security y algunas dependencias necesarias, se hace uso de la siguiente instrucción.

# apt install libapache2-mod-security2 Ilustración 2-16. Instalando mod_security.

2.5.1. Configurando mod_security.

Por defecto, mod_security no funciona como se espera, porque necesita reglas para poder

trabajar correctamente. mod_security incluye una plantilla de configuración para poder

15

implementar. Por lo que el fichero de configuración /etc/modsecurity/modsecurity.conf. se

creará tomando como fichero fuente la plantilla: /etc/modsecurity/modsecurity.conf-

recommended. En este fichero el único parámetro a modificar será SecRuleEngine y se asignará

el valor On. Por defecto posee el valor DetectionOnly, es decir, registra eventos de acuerdo con

las reglas establecidas, pero no bloquea acciones consideradas peligrosas.

mod-security es instalado con un set de reglas por defecto, estas reglas están ubicadas en el

directorio /usr/share/modsecurity-crs/. Pero para esta implementación se hará uso del Core

Rule Set (CRS) recomendadas por OWASP [24]. Se trata de un conjunto de reglas generales

compatibles con mod_security, que tienen como objetivo proteger aplicaciones web de una

amplia gama ataques. Este CRS tiene en cuenta proteger de las 10 vulnerabilidades más

comunes encontradas en servicios web. Ver sección 1.1. Para poder obtener el CRS de OWASP,

se ejecutan las siguientes instrucciones:

# rm -rf /usr/share/modsecurity-crs # git clone https://github.com/SpiderLabs/owasp-modsecurity-crs /usr/share/modsecurity-crs # cd /usr/share/modsecurity-crs # mv crs-setup.conf.example crs-setup.conf

Ilustración 2-17. Descargando OWASP modsecurity CRS.

Ahora es necesario habilitar estas reglas para que trabajen con Apache, esta configuración se

realiza en el fichero /etc/apache2/mods-enabled/security2.conf. ver ilustración 2-18.

/etc/apache2/mods-enabled/security2.conf 1

2

3

4

5

6

<IfModule security2_module>

SecDataDir /var/cache/modsecurity

IncludeOptional /etc/modsecurity/*.conf

IncludeOptional "/usr/share/modsecurity-crs/*.conf

IncludeOptional "/usr/share/modsecurity-crs/rules/*.conf

</IfModule>

Ilustración 2-18. Configurando OWASP modsecurity CRS.

Para que los cambios en la configuración cobren efecto, es necesario reiniciar el servicio de

Apache. Esto se logra con la instrucción:

# systemctl reload apache2 Ilustración 2-19. Recargando el servicio de Apache.

3. Servidor web Nginx.

NGINX, es una plataforma de código abierto, que funciona como servidor web, también puede

funcionar como proxy inverso, proxy de correo electrónico y balanceador de carga web. Fue

desarrollado con el objetivo de solventar los problemas que tenían los servidores web existentes

en su momento cuando se trata de gestionar grandes volúmenes de conexiones simultaneas,

esta filosofía ha hecho de Nginx una de las plataformas para servicios web más confiables con

respecto al rendimiento y la escalabilidad [4].

Esta sección es un complemento a las secciones anteriores, por lo que se busca implementar

algunas de las buenas prácticas documentadas anteriormente.

3.1. Editando configuración por defecto de Nginx.

En distros basadas en Debian, el fichero de configuración de Nginx es /etc/nginx/Nginx.conf. El

proceso de hardening inicia con la modificación y adición de algunos sencillos parámetros de

16

configuración en este fichero. Se ha intentado implementar las mismas prácticas de seguridad

(cuando aplica) que se han aplicado en Apache2 en la sección anterior, el resultado se puede

observar en las siguientes ilustraciones, que muestra solo la información relevante para esta

investigación.

L Configuración /etc/nginx/nginx.conf 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

user www-data;

worker_processes auto;

pid /run/nginx.pid;

include /etc/nginx/modules-enabled/*.conf;

#...

http {

#...

# Logging Settings

access_log /var/log/nginx/access.log;

error_log /var/log/nginx/error.log;

include /etc/nginx/conf.d/*.conf;

include /etc/nginx/sites-enabled/*;

#headers

add_header X-Content-Type-Options 'nosniff';

add_header X-Xss-Protection "1; mode=block";

add_header Strict-Transport-Security 'max-

age=31536000; includeSubDomains; preload;';

add_header X-Frame-Options "DENY";

#signatures

server_tokens off;

more_set_headers "Server: SP2020";

}

Ilustración 3-1. Cambiando configuración por defecto de Nginx.

Las modificaciones realizadas son:

▪ Parámetro ServerTokens. (más información de este parámetro en la sección 2.1).

▪ Parámetro more_set_headers: Parámetro equivalente al parámetro serverSignature de

Apache, permite ocultar información sobre el servidor web. (más información de este

parámetro en la sección 2.1).

3.2. Configurando Headers de respuesta

En el fichero mostrado en la ilustración 3-1, se implementan, además, como una buena práctica

de seguridad una serie de cabeceras que serán incluidas en las respuestas que el servidor de a

las peticiones que realizan los clientes, las cabeceras configuradas son:

▪ Header X-Content-Type-Options: Previene ataques MIME sniffing. (ver sección 2.3).

▪ Header X-Frame-Options: Minimiza el riesgo de ataques de clickjacking. (ver sección 2.3).

▪ Header X-XSS-Protection: Impide la carga de una página cuando se detecta un ataque de

tipo Cross-Site Scripting. (ver sección 2.3).

▪ Header Strict-Transport-Security: Establece un mecanismo automático para redireccionar

cualquier intento de utilizar un canal inseguro por parte de un usuario. (ver sección 2.4.1).

3.3. TLS.

Creando la clave privada y el certificado público.

El primer paso para configurar TLS es crear la clave privada y el certificado público, la instrucción

utilizada para este procedimiento es:

# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/sp2.server.key -out /etc/ssl/certs/sp2.server.crt

Ilustración 3-2. Creando clave privada y certificado publico auto firmados.

17

Durante la ejecución, Openssl solicitará información relativa al servidor (ver ilustración 2-9).

Configurando Nginx.

A continuación, en el directorio, se crea el siguiente fichero que define la ruta de la llave privada

y el certificado público:

/etc/nginx/snippets/sp2.server.conf 1

2

ssl_certificate /etc/ssl/certs/sp2.server.crt; ssl_certificate_key /etc/ssl/private/sp2.server.key;

Ilustración 3-3. fichero /etc/nginx/snippets/sp2.server.conf.

Además, se crea el fichero /etc/nginx/snippets/ssl-params.conf, que contiene información de

configuración que se cargará en Nginx. La ilustración 3-4 muestra el contenido de este fichero.

/etc/nginx/snippets/ssl-params.conf 1 2 3 4 5 6 7 8 9

# from https://cipherli.st/ ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"; ssl_ecdh_curve secp384r1; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on;

Ilustración 3-4. Fichero de configuración SSL para Nginx.

Configurar Nginx para usar SSL.

Para implementar SSL en Nginx, se edita el fichero encargado de registrar la configuración del

sitio web servido, en este caso, se ha utilizado el fichero /etc/nginx/sites-available/default,

donde se define el puerto a utilizar para escuchar peticiones HTTPS, además, se incluyen los

ficheros de configuración creados en el directorio /etc/nginx/snippets/. Cómo medida de

seguridad adicional, se crear un dominio encargado de gestionar las peticiones HTTP, cuya tarea

será la de redireccionar este tráfico a un canal seguro. La ilustración 3-5 muestra la información

relevante de este fichero.

/etc/nginx/sites-available/default 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

server { listen 443 ssl; include /etc/nginx/snippets/sp2.server.conf; include /etc/nginx/snippets/ssl-params.conf; root /var/www/html; #... } server { listen 80 default_server; server_name www.sp2.server.net; #redireccionando HTTP a HTTPS return 301 https://$server_name$request_uri; }

Ilustración 3-5. Fichero de configuración de sitio web.

Para aplicar la configuración SSL realizada, se debe reiniciar el servicio Nginx. Al verificar si SSL

se ha implementado correctamente, cuando se intenta acceder por primera vez al sitio web

desde el cliente utilizando HTTPS, el navegador advierte sobre el uso de certificados poco

confiables, esto sucede porque el proceso correcto requiere de la firma de una autoridad que

18

indique que el sitio web es genuino y confiable [21]. Para los propósitos de esta memoria, se

omitirá este paso ya que el objetivo es la configuración y correcta implementación de SSL.

3.4. Instalando y configurando mod_security.

A diferencia de Apache donde es opcional, para poder instalar mod_security [22] y que sea

compatible con Nginx, es requerido descargar el código fuente y compilarlo, esto es posible con

las siguientes instrucciones:

# cd /opt/ # git clone # https://github.com/SpiderLabs/ModSecurity # sh build.sh #./configure # make # make install

Ilustración 3-6. Instalando mod_security.

3.4.1. Obteniendo y compilando el conector para Nginx.

Nginx proporciona repositorios para las versiones estables actuales de Red Hat/CentOS, Debian

y Ubuntu [4]. Para hacer uso de estos repositorios es necesario descargar uno adecuado a la

versión instalada de Nginx en el paso anterior, al momento de realizar este trabajo, se instaló la

versión 1.17.10. Es necesario obtener desde el repositorio oficial de Mod_security el módulo

compatible para Nginx. Una vez finalizado este procedimiento, se realiza una copia del fichero

/opt/nginx-1.17.10/objs/ngx_http_modsecurity_module.so en el directorio

/etx/nginx/modules-available/ de Nginx. La ilustración 3-7 resume este proceso.

# git clone https://github.com/SpiderLabs/ModSecurity-nginx.git # wget http://nginx.org/download/nginx-1.17.10.tar.gz # tar zxvf nginx-1.17.10.tar.gz # cd nginx-1.17.10 # ./configure --with-compat --add-dynamic-module=../ModSecurity-nginx # make modules # cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules-available/

Ilustración 3-7. Compilando conector de mod_security para Nginx.

3.4.2. Configurando mod_security.

Ahora que se ha compilado el conector nginx y se ha copiado en la ubicación correcta, se debe

configurar nginx para usarlo y se deben implementar las reglas que Mod_security utilizará, para

este caso, se hará uso del Core Rule Set (CRS) recomendadas por OWASP [24]. La ilustración 3-

8, resume este proceso.

# mkdir /etc/nginx/modsec # cd /etc/nginx/modsec # git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git # mv owasp-modsecurity-crs/crs-setup.conf.example /owasp-modsecurity- crs/crs-setup.conf # cp /opt/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Ilustración 3-8. Descargando CRS de OWASP para Mod_security.

Finalmente, se ha creado un nuevo fichero de configuración llamado

/etc/nginx/modsec/main.conf, que cargará los archivos de configuración disponibles en

/etc/nginx/modsec/, además del CRS. El contenido del fichero main.conf se muestra en la

ilustración 3-9.

19

L Configuración /etc/nginx/modsec/main.conf 1

2

3

Include /etc/nginx/modsec/modsecurity.conf

Include /etc/nginx/modsec/owasp-modsecurity-crs/crs-setup.conf

Include /etc/nginx/modsec/owasp-modsecurity-crs/rules/*.conf

Ilustración 3-9. Creando fichero para incluir en la configuración de Nginx.

3.4.3. Implementando mod_security en la configuración de Nginx.

Para incluir a mod_security dentro de la configuración de Nginx, como primer paso se debe

cargar el módulo /etc/nginx/modules-available/ngx_http_modsecurity_module.so, que

anteriormente se había generado en la compilación de conector de mod_security para Nginx, la

ilustración 3-10 muestra cómo se incluye el módulo dentro de la configuración de Nginx.

L Configuración /etc/nginx/nginx.conf 1

2

3

4

5

user www-data;

worker_processes auto;

pid /run/nginx.pid;

include /etc/nginx/modules-enabled/*.conf;

load_module /etc/nginx/modules-available/ngx_http_modsecurity_module.so;

Ilustración 3-10. Cargando módulo de mod_security en Nginx.

Como último paso, se edita el fichero encargado de registrar la configuración del sitio web

servido, en este caso, se trata del fichero /etc/nginx/sites-available/default, la configuración que

se debe incluir se muestra en la ilustración 3-11.

/etc/nginx/sites-available/default 1 2 3 4 5 6 7 8

server { listen 443 ssl; listen [::]:443 ssl; #modsecurity modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf; }

Ilustración 3-11. Implementando mod_security en el sitio web.

Mod_security es instalado con un set de reglas por defecto, estas reglas están ubicadas en el

directorio /usr/share/modsecurity-crs/. Pero para esta implementación se hará uso del Core

Rule Set (CRS) recomendadas por OWASP [22]. Se trata de un conjunto de reglas generales

compatibles con mod_security, que tienen como objetivo proteger aplicaciones web de una

amplia gama ataques. Este CRS tiene en cuenta proteger de las 10 vulnerabilidades más

comunes encontradas en servicios web. Ver sección 1.1. Para poder obtener el CRS de OWASP,

se ejecutan las siguientes instrucciones:

# rm -rf /usr/share/modsecurity-crs # git clone https://github.com/SpiderLabs/owasp-modsecurity-crs /usr/share/modsecurity-crs # cd /usr/share/modsecurity-crs # mv crs-setup.conf.example crs-setup.conf

Ilustración 3-12. Descargando OWASP modsecurity CRS.

Ahora es necesario habilitar estas reglas para que trabajen con Nginx, esta configuración se

realiza en el fichero /etc/nginx/sites-available/default. ver ilustración 3-13.

/etc/nginx/sites-available/default 1

2

3

4

5

6

server { listen 443 ssl; listen [::]:443 ssl; #modsecurity modsecurity on;

20

7 modsecurity_rules_file /etc/nginx/modsec/main.conf; }

Ilustración 3-13. Habilitando Mod_security en el sitio web.

Con la configuración de este fichero finaliza el proceso de hardening de servidor Nginx. Para

implementar los cambios es necesario reiniciar el servicio con el comando service nginx restart.

La siguiente sección describe las pruebas realizadas.

4. Pruebas de seguridad.

En esta sección se busca realizar una evaluación de las medidas de seguridad implementadas en

los servidores www.sp.server.net y www.sp2.server.net. Para ello se utilizarán dos herramientas

de código libre: Nikto [12] y Arachni [13]. Para tener un punto de comparación, las evaluaciones

se realizarán sobre dos versiones de cada servidor que básicamente ofrecen la misma

funcionalidad, pero con la diferencia de que la primera versión tendrá la configuración por

defecto y la segunda, tendrá implementadas todas las medidas de seguridad que han sido

descritas en esta memoria. Para facilitar la referencia, se llamarán “servidor inicial” y “servidor

seguro”.

Como complemento a las pruebas, cada servidor tendrá instalada una sencilla aplicación web.

El árbol de ficheros y directorios es el siguiente:

home/ ├── index.html ├── registrarusuario.php ├── insert.php └── directorio/ ├── directorios_sin_index.txt └── fichero_importante.txt

Ilustración 4-1. Mapa del sitio web de prueba.

La principal diferencia en la aplicación web será que en el servidor seguro las consultas realizadas

a una base de datos estarán parametrizadas, como lo indican las buenas prácticas de desarrollo

web.

4.1. Pruebas de seguridad utilizando Arachni.

Arachni es un framework de código abierto, desarrollado para el escaneo de aplicaciones web.

Ofrece una interfaz gráfica web muy sencilla de usar con la que es posible realizar escaneos y

generar reportes en varios formatos [13]. Para poder realizar las pruebas, se ha utilizado la

plataforma web que ofrece la herramienta, los problemas encontrados se han clasificado según

el daño potencial que pueden causar en un sistema web: Riesgo alto, bajo, informativo. Los

resultados se muestran a continuación.

4.1.1. Resultado de pruebas servidor inicial Apache.

Tabla 4-1. Resultado de pruebas servidor inicial basado en Apache utilizando Arachni.

Nivel de Riesgo

Vulnerabilidad encontrada Descripción

Informativo Server using OPTIONS Proof GET,POST,OPTIONS,HEAD

Detectado método HTTP OPTIONS. Los atacantes utilizan este método porque ofrece información sobre las peticiones aceptadas por el servidor.

Informativo

In server using POST at http://www.sp.server.net/insert.php Proof HTTP/1.1 302 Found

El servidor respondió con un código de estado que no es 200 ni 404. Esto no es un problema, sin embargo, los códigos HTTP ofrecen información sobre el comportamiento de la aplicación web.

21

Informativo

In server using GET at http://www.sp.server.net/directorio Proof HTTP/1.1 301 Moved Permanently


Informativo

In server using PUT at http://www.sp.server.net/Arachni-1b0e2cf5797f40253ddb473796224533 Proof HTTP/1.1 100 Continue


Informativo

In server using TRACE at http://www.sp.server.net/ HTTP/1.1 405 Method Not Allowed


Bajo Missing 'X-Frame-Options' header El servidor no devolvió un encabezado X-Frame-

Options, lo que significa que este sitio web podría estar en riesgo de un ataque de clickjacking.

Alto Blind SQL Injection (timing attack) Timing attack Injected seed: '=sleep(16)='

Esta inyección se detectó porque Arachni pudo inyectar consultas SQL

4.1.2. Resultado de pruebas servidor seguro Apache.

Tabla 4-2. Resultado de pruebas servidor seguro basado en Apache utilizando Arachni.

Nivel de Riesgo


Informativo

In server using POST at http://www.sp.server.net/insert.php Proof HTTP/1.1 302 Found


Informativo

In server using GET at http://www.sp.server.net/directorio Proof HTTP/1.1 301 Moved Permanently


Informativo

In server using TRACE at http://www.sp.server.net/ HTTP/1.1 405 Method Not Allowed


Informativo

In server using PUT at https://www.sp.server.net/Arachni-6122f78bc60b31f9cd4496c197de8d37 HTTP/1.1 403 Forbidden


4.1.3. Resultado de pruebas servidor inicial Nginx.

Tabla 4-3. Resultado de pruebas servidor inicial basado en Nginx utilizando Arachni.

Nivel de Riesgo


Informativo

In server using GET at http://www.sp2.server.net/directorio/? %3Cmy_tag_23d6785bdcd7fdc6d387b5f 0c4733edc/%3E= pointing to http://www.sp2.server.net/directorio/ ?%3Cmy_tag_23d6785bdcd7fdc6d387b 5f0c4733edc/%3E= Proof HTTP/1.1 403 Forbidden


Informativo In server using POST at http://www.sp2.server.net/insert.php

El servidor respondió con un código de estado que no es 200 ni 404. Esto no es un problema, sin

22

pointing to http://www.sp2.server.net/insert.php . Proof HTTP/1.1 302 Found

embargo, los códigos HTTP ofrecen información sobre el comportamiento de la aplicación web.

Informativo

In server using GET at http://www.sp2.server.net/directorio pointing to http://www.sp2.server.net/directorio . Proof HTTP/1.1 301 Moved Permanently


Informativo

In server using OPTIONS at http://www.sp2.server.net/ pointing to http://www.sp2.server.net/ . Proof HTTP/1.1 405 Not Allowed


Bajo Missing 'X-Frame-Options' header El servidor no devolvió un encabezado X-Frame-

Options, lo que significa que este sitio web podría estar en riesgo de un ataque de clickjacking.

Alto Blind SQL Injection (timing attack) Timing attack Injected seed: '=sleep(16)='

Esta inyección se detectó porque Arachni pudo inyectar consultas SQL

4.1.4. Resultado de pruebas servidor seguro Nginx.

Tabla 4-4. Resultado de pruebas servidor seguro basado en Nginx utilizando Arachni.

Nivel de Riesgo


Informativo

In server using POST at https://www.sp2.server.net/insert.php pointing to https://www.sp2.server.net/insert.php Proof HTTP/1.1 302 Found


Informativo

In server using GET at https://www.sp2.server.net/directorio pointing to https://www.sp2.server.net/directorio Proof HTTP/1.1 301 Moved Permanently


Informativo

In server using OPTIONS at https://www.sp2.server.net/ pointing to https://www.sp2.server.net/ Proof HTTP/1.1 403 Forbidden


4.2. Pruebas de seguridad utilizando Nikto.

Nikto es un escáner de vulnerabilidades web, es una herramienta ligera basada en línea de

comandos, es muy sencillo de utilizar y es capaz de realizar más de 6700 pruebas para detectar

vulnerabilidades en sitios web, también intenta analizar las configuraciones del servidor y

elementos que se encuentren desactualizados [12]. La siguiente instrucción ha sido utilizada

para poder realizar los análisis:

# nikto -h 100.30.34.2 -p 443 -F txt -o reporte_server_seguro.txt Ilustración 4-2. Ejecutando análisis con Nikto.

Donde:

▪ h: Indica la dirección IP del servidor a evaluar.

23

▪ p: Puerto para enviar las peticiones

▪ F: formato del fichero donde se guardarán los resultados.

▪ o: fichero donde se guardarán los resultados.

4.2.1. Resultado de pruebas servidor inicial Apache.

Tabla 4-5. Resultado de pruebas servidor inicial basado en Apache utilizando Nikto.

Nivel de Riesgo


Bajo

GET /: Server leaks inodes via ETags, header found with file /, fields: 0x105 0x5a3c9d731edc7

Podría permitir a un atacante obtener información sensible como el número inode, multipart MIME boundary y el proceso hijo a través de este encabezado.

Informativo GET /: The anti-clickjacking X-Frame-Options header is not present.

El servidor no devolvió un encabezado X-Frame-Options, lo que significa que este sitio web podría estar en riesgo de un ataque de clickjacking.

Informativo OPTIONS /: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD

Detectado método HTTP OPTIONS. Los atacantes utilizan este método porque ofrece información sobre las peticiones aceptadas por el servidor.

Bajo -3233: GET /icons/README: /icons/README: Apache default file found.

Nikto detecto que no existen modificaciones en el fichero de configuración de Apache2.

4.2.2. Resultado de pruebas servidor seguro Apache.

Tabla 4-6. Resultado de pruebas servidor seguro basado en Apache utilizando Nikto.

Nivel de Riesgo


Informativo GET /: Uncommon header 'x-xss-protection' found, with contents: 1; mode=block, 1; mode=block

Esto no es un problema, sin embargo, Nikto considera que estas cabeceras ofrecen información sobre el comportamiento de la aplicación web.

Informativo GET /: Uncommon header 'x-frame-options' found, with contents: SAMEORIGIN, SAMEORIGIN


Informativo GET /: Uncommon header 'x-content-type-options' found, with contents: NOSNIFF, NOSNIFF


Informativo

GET /: Uncommon header 'strict-transport-security' found, with contents: max-age=31536000; includeSubDomains; preload


4.2.3. Resultado de pruebas servidor inicial Nginx.

Tabla 4-7. Resultado de pruebas servidor inicial basado en Nginx utilizando Nikto.

Nivel de Riesgo


Bajo

GET /: Server leaks inodes via ETags, header found with file /, fields: 0x105 0x5a3c9d731edc7

Podría permitir a un atacante obtener información sensible como el número inode, multipart MIME boundary y el proceso hijo a través de este encabezado.

Informativo GET /: The anti-clickjacking X-Frame-Options header is not present.

El servidor no devolvió un encabezado X-Frame-Options, lo que significa que este sitio web podría estar en riesgo de un ataque de clickjacking.

24

4.2.4. Resultado de pruebas servidor seguro Nginx.

Tabla 4-8. Resultado de pruebas servidor seguro basado en Nginx utilizando Nikto.

Nivel de Riesgo


Informativo

No CGI Directories found (use '-C all' to force check all possible dirs)

Los programas CGI se utilizan para realizar tareas que no usualmente son soportadas por el estándar HTML básico, este mensaje tiene un carácter más informativo que de peligro, indica que en el servidor no se ha encontrado ningún directorio /CGI-BIN/

4.3. Análisis de resultados.

Luego de realizar las pruebas, las tablas 4-9 y 4-10, realizan un resumen de los resultados

obtenidos.

Tabla 4-9. Resultados pruebas Arachni

0

1

2

3

4

5

6

Servidor inicialApache

Servidor seguroApache

Servidor inicial Nginx Servidor seguro Nginx

Pruebas de seguridad utilizando Arachni

Riesgo bajo Riesgo medio Riesgo alto

25

Tabla 4-10. Resultados pruebas Nikto.

Las vulnerabilidades de bajo riesgo encontradas en el servidor inicial (Missing 'X-Frame-Options'

header, Etag, Apache default file found) no representan un peligro por sí mismas, pero un

atacante experimentado puede sacar mucho provecho de estas debilidades y provocar acciones

inesperadas en el servidor o inconvenientes a los visitantes de este servidor.

La única vulnerabilidad grave fue encontrada en las versiones de servidor inicial de Apache y

Nginx, se trata de una inyección de SQl donde se logra ingresar a la base de datos un tiempo de

espera (sleep). La gravedad de esta vulnerabilidad radica en que un atacante puede provocar

serios daños al servidor: perdida de base de datos, inyección de código malicioso y robo de datos

confidenciales de los usuarios. Es importante hacer referencia a que la página web del servidor

seguro, realizó sus consultas de manera parametrizada mientras que el servidor inicial no.

Luego del análisis de vulnerabilidades realizado con dos herramientas: Arachni y Nikto, se puede

comprobar como en los resultados de la versión segura de cada servidor, Apache y Nginx, se

encuentran menos vulnerabilidades y advertencias que en los resultados de un servidor con la

configuración por defecto. La prueba también permite observar que un mal diseño en las

aplicaciones web que se instalan en un servidor puede aumentar la cantidad y la gravedad de

las vulnerabilidades que es posible encontrar en un servicio web.

5. Conclusiones.

En esta investigación, se ha logrado establecer una serie de políticas, métodos y buenas prácticas

de seguridad aplicables a la configuración por defecto las aplicaciones de servicios web Apache

y Nginx instalados en un SO basado en UNIX. las pruebas realizadas con diferentes herramientas

sobre un servidor configurado con una serie de medidas de seguridad descritas en esta memoria

ofrecen resultados con menos vulnerabilidades encontradas, en comparación a un servidor que

posee la configuración por defecto.

A pesar de esto, los resultados de las pruebas no dejan mal parado a ninguno de los servidores

analizados, se pudo observar como la configuración por defecto de Nginx presentó de manera

leve menos problemas de seguridad que la configuración por defecto de Apache. Gran parte de

0

1

2

3

4

5

6

Servidor inicialApache

Servidor seguroApache

Servidor inicialNginx

Servidor seguroNginx

Pruebas de seguridad utilizando nginx

Riesgo bajo Riesgo medio Riesgo alto

26

los problemas encontrados en los procesos de escaneo de vulnerabilidades, son consideradas

vulnerabilidades menores. Queda en evidencia que la comunidad encargada del desarrollo de

estas plataformas tiene en consideración los posibles problemas de seguridad e implementan

una buena cantidad de buenas prácticas de seguridad en las configuraciones por defecto.

Existen una serie de herramientas capaces de hacer pruebas de verificación de malas

configuraciones y problemas de seguridad de una manera muy eficiente, muchas de estas

pruebas serían muy difíciles de realizar e interpretar por una persona, en cambio, estas

herramientas son capaces de hacer miles de pruebas diferentes en muy poco tiempo,

convirtiéndolas en grandes aliadas cuando se trata de mejorar la seguridad de un servidor web.

Sin embargo, es recomendable realizar escaneos con diferentes herramientas, ya que como se

pudo observar en las pruebas realizadas, las herramientas utilizadas no documentaron

exactamente las mismas vulnerabilidades.

Es necesario no solo tener en cuenta la seguridad a nivel se servidor. Es prioritario la

implementación de buenas prácticas de seguridad a nivel de desarrollo de servicios web. Esto

quedó en evidencia debido a las vulnerabilidades de alto riesgo encontradas la página web

utilizada como ejemplo.

6. Bibliografía.

[1] Positive technologies, "Web application vulnerabilities: statistics for 2018", Ptsecurity.com, 2019. [Online].

Available: https://www.ptsecurity.com/ww-en/analytics/web-application-vulnerabilities-statistics-2019/. [Accessed: 17- Mar- 2020].

[2] OWASP, "OWASP Top 10 - 2017 The Ten Most Critical Web Application Security Risks", Owasp.org, 2017. [Online]. Available: https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_%28en%29.pdf.pdf. [Accessed: 18- Mar- 2020].

[3] The Apache Software Foundation., "The Apache HTTP Server Project", Httpd.apache.org, 2020. [Online]. Available: https://httpd.apache.org/. [Accessed: 17- Mar- 2020].

[4] F5, Inc., "NGINX | High Performance Load Balancer, Web Server, & Reverse Proxy", NGINX, 2020. [Online]. Available: https://www.nginx.com/. [Accessed: 18- Jun- 2020].

[5] w3techs, "Usage Statistics and Market Share of Web Servers, April 2020", W3techs.com, 2020. [Online]. Available: https://w3techs.com/technologies/overview/web_server. [Accessed: 17- Mar- 2020].

[6] Galaxy Technologies, LLC., "GNS3", Gns3.com, 2020. [Online]. Available: https://gns3.com/. [Accessed: 17- Mar- 2020].

[7] Oracle, "Oracle VM VirtualBox", Virtualbox.org, 2020. [Online]. Available: https://www.virtualbox.org/. [Accessed: 17- Mar- 2020].

[8] Oracle, "MySQL", Mysql.com, 2020. [Online]. Available: https://www.mysql.com/. [Accessed: 22- Apr- 2020]. [9] The PHP Group, "PHP: Hypertext Preprocessor", Php.net, 2020. [Online]. Available: https://www.php.net/.

[Accessed: 22- Apr- 2020].

27

[10] Internet Systems Consortium, Inc., "BIND 9", Isc.org, 2020. [Online]. Available: https://www.isc.org/bind/. [Accessed: 17- Mar- 2020].

[11] C. E. Gómez, C. A. Candela, and L. E. Sepúlveda, “Seguridad en la configuración del Servidor Web Apache,” INGE CUC, vol. 9, no. 2, pp. 31–38, 2013.

[12] CIRT, "Nikto2 | CIRT.net", CIRT, 2020. [Online]. Available: https://cirt.net/Nikto2. [Accessed: 08- Apr- 2020 [13] Sarosys LLC, "Arachni - Web Application Security Scanner Framework", arachni-scanner.com, 2020. [Online].

Available: https://www.arachni-scanner.com/. [Accessed: 21- Apr- 2020]. [14] Panda Security, "Configuración por defecto = Configuración insegura", Panda Security Mediacenter, 2020.

[Online]. Available: https://www.pandasecurity.com/spain/mediacenter/seguridad/configuracion-por-defecto-insegura/. [Accessed: 06- Apr- 2020].

[15] The Apache Software Foundation, "Consejos de Seguridad - Servidor HTTP Apache Versión 2.5", Httpd.apache.org, 2020. [Online]. Available: https://httpd.apache.org/docs/trunk/es/misc/security_tips.html. [Accessed: 06- Apr- 2020].

[16] Cloudflare, Inc, "Slowloris DDoS Attack", cloudflare, 2020. [Online]. Available: https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/. [Accessed: 22- Apr- 2020].

[17] Mozilla, Documentación web de MDN, 2020. [Online]. Available: https://developer.mozilla.org/es/docs/Web/HTTP. [Accessed: 15- Apr- 2020].

[18] w3, "Frames in HTML documents", W3.org, 2020. [Online]. Available: https://www.w3.org/TR/html4/present/frames.html. [Accessed: 22- Apr- 2020].

[19] Y. Ryabova, "Who to trust: Different types of SSL certificates", Kaspersky, 2020. [Online]. Available: https://www.kaspersky.com/blog/certificates-are-different/22147/. [Accessed: 17- Apr- 2020].

[20] Siriwardena P. (2014) Mutual Authentication with TLS. In: Advanced API Security. Apress, Berkeley, CA [21] Internet Security Research Group (ISRG)., "Let's Encrypt - Free SSL/TLS Certificates", Letsencrypt.org, 2020.

[Online]. Available: https://letsencrypt.org/. [Accessed: 22- Apr- 2020]. [22] Trustwave Holdings, Inc., "ModSecurity: Open Source Web Application Firewall", Modsecurity.org, 2020.

[Online]. Available: https://modsecurity.org/. [Accessed: 22- Apr- 2020]. [23] O’Leary M. (2015) Apache and ModSecurity. In: Cyber Operations. Apress, Berkeley, CA

[24] Trustwave Holdings, Inc. owasp-modsecurity-crs. GitHub repository, https://github.com/SpiderLabs/owasp-modsecurity-crs/. Último Acceso 21-abr-2020.

proceso de hardening de servidor web - ua

Documents