Servidor web Apache avanzado

Servidor web Apache avanzado

Seguridad
Uso de archivos .htaccess
Ejemplo de archivo .htaccess
Módulo mod_access_compat
Usando mod_authz_host
Acceso por IP
Acceso por Sub Redes
Acceso por usuario
Permisos
Mitigar ataque DDOS
Algunas definiciones
El módulo mod_evasive
El módulo mod_qos
El módulo mod_reqtimeout
El módulo mod_suexec
El módulo mod_security

Seguridad

Uso de archivos .htaccess

Los archivos .htaccess permiten aplicar configuraciones personalizadas por directorios. Es muy
útil para sitios en los cuales no se posee total control del sistema operativo. En estos archivos se
permiten aplicar ciertas directivas controladas a su vez por la directiva AllowOverride .

La siguiente tabla muestra qué parámetro usar de AllowOverride de acuerdo al tipo de

directivas y un ejemplo por tipo.
 Parámetro de Directiva
Directiva
AllowOverride permitida

Autorización AuthConfig Require

Tipos de documentos, metadatos,

reescritura de URLs, manipular y
controlar URLs, cuando las peticiones FileInfo Redirect
llegan al servidor, ejecutar CGI's de
acuerdo a ciertas condiciones.

Indexado de directorios Indexes DirectoryIndex

Control de acceso Limit Allow

Options=
Características del directorio FollowSymLinks
[Opción1,Opción2,OpciónN]

Tratamiento de errores de sintaxis Nonfatal=

(No Aplica)
como no fatales [Override|Unknown |All]

Ejemplo de archivo .htaccess

En el fichero de configuración del vhost example.com se establece la directiva AllowOverride en

All para permitir el uso del fichero .htaccess en ese directorio.

<Directory /var/www/example.com>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>

El fichero .htaccess en el directorio /var/www/example.com con las configuraciones pertinetes

para el acceso con contraseña al contenido del mismo.

Options Indexes FollowSymLinks

AuthType Basic
AuthBasicProvider file
AuthUserFile /etc/httpd/http.passwd
AuthName "Test de auth"
Require valid-user

Módulo mod_access_compat
Las directivas facilitadas por mod_access_compat se usan en las secciones <Directory> ,
<Files> , y <Location> así como en los ficheros .htaccess para controlar el acceso a partes
específicas del servidor. El acceso se puede controlar en base al nombre de host del cliente,
dirección IP u otras características de la petición del cliente, tal y como se capturan en las
variables de entorno. La directivas Allow y Deny se usan para especificar qué clientes tienen
acceso y cuales no al servidor, mientras que la directiva Order configura el estado del acceso por
defecto, y configura cómo las directivas Allow y Deny interactuan la una con la otra.
 Límite Directiva

Esta directiva sirve para permitir el acceso a directorios desde determinadas

Allow
direcciones IP's, hosts o dominios

Esta directiva sirve para denegar el acceso a directorios desde determinadas

Deny
direcciones IP's, hosts o dominios

Establece el orden en que se van a procesar las directivas anteriores y que

Order
ocurre si no hay coincidencia con ninguna regla.

Vista al fichero de configuración example.com.conf :

...
<Directory /var/www/html/private>
...
Order Deny,Allow
  Deny from all
  Allow from 192.168.0.187
  Allow from .example.com
  ...
</Directory>
...

Order Deny, Allow significa que primero se van a procesar todas las directivas Deny y luego
todas las directivas Allow. Si ninguna regla coincide se permite el acceso. El valor
predeterminado es Deny Allow.
A diferencia de las reglas de muchos firewalls, el orden en que se presentan las directivas no
importa. Se procesan todas las directivas sin importar si una coincide antes.
En este caso se estaría negando el acceso a todos, salvo a las direcciones IP 10.0.0.1
(asociada example.com) y 192.168.1.1.

IMPORTANTE: Las directivas facilitadas por mod_access_compat han quedado obsoletas en favor
de mod_authz_host. Mezclar directivas antiguas como Order, Allow o Deny con las nuevas
directivas como Require es técnicamente posible pero no recomendable. Éste módulo se creó
para dar soporte a configuraciones que solo contienen directivas antiguas para facilitar una
actualización a la versión 2.4. Por favor compruebe la guía Actualizando para más información.

Usando mod_authz_host
Los proveedores de autorización implementados por mod_authz_host están registrados
utilizando la directiva Require . La directiva se puede hacer referencia a secciones <Directory> ,
<Files> o <Location> , así como los archivos .htaccess para controlar el acceso a
determinadas partes del servidor. El acceso se puede controlar en función del nombre de host del
cliente o la dirección IP.

En general, las directivas de restricción de acceso se aplican a todos los métodos de acceso ( GET ,
PUT , POST , etc.). Este es el comportamiento deseado en la mayoría de los casos. Sin embargo, es
posible restringir algunos métodos, dejando otros métodos sin restricciones, encerrando las
directivas en una sección <Limit> .
Acceso por IP

Vista al fichero de configuración example.com.conf :

...
<Directory /var/www/html/private>
...
Require ip 192.168.0.187
Require hostname .example.com
...
</Directory>
...

En este caso solamente se permitirá el acceso al directorio /var/www/html/test si la petición el

cliente tiene la ip 192.168.0.187 o el hostname con el dominio .example.com.

Acceso por Sub Redes

Vista al fichero de configuración example.com.conf :

...
<Directory /var/www/html/private>
...
Require ip 192.168.0.0/255.255.255.0
...
</Directory>
...

En este caso solamente se permitirá el acceso al directorio /var/www/html/test si la petición el

cliente tiene la ip dentro de las sub-red 192.168.0.0/24 o el hostname con el dominio
.example.com.

Acceso por usuario

Recordemos que:

Autorización es el proceso en que se decide si a un usuario se le permite o deniega el acceso.

Autenticación es el proceso en que se verifica que el usuario es quien dice ser.

En Apache todo esto está determinado por:

El tipo de autenticación (Directiva AuthType)

El proveedor de la autenticación (Directiva AuthBasicProvider o AuthDigestProvider)
Autorización (Directiva Require)

Vista al fichero de configuración example.com.conf :

 ...
<Directory /var/www/html/private>
...
AuthType Basic
AuthBasicProvider file
AuthUserFile /etc/httpd/http.passwd
AuthName "Test de auth"
Require valid-user
...
</Directory>
...

Por supuesto, con eso no basta, tenemos que crear los usuarios y sus contraseñas, por ejemplo:

# htpasswd -B -c /etc/httpd/http.passwd usuario

New password:
Re-type new password:
Adding password for user usuario
# cat /etc/httpd/http.passwd
usuario: $2y$05$bBHnRbJjQ4EVDydyNK162e3iYhKpwTx827ty3t16/SCY.UI1QKbLa

El comando htpasswd sirve para manejar los usuarios de autenticación básica, la opción -B usa
bcrypt para cifrar la password del usuario usuario y -c crea el archivo
/etc/httpd/http.passwd . Estos usuarios no tiene relación alguna con los del archivo
/etc/passwd. Los subsiguientes usuarios se deben crear sin la opción -c.

Permisos
Es importante que los archivos de configuración y los logs sean propiedad de root y que todos los
archivos del servidor web sean propiedad de root (o www-data). Es decir:

# find /etc/apache2 /var/log/apache2 -type d -ls

  32130     4 drwxr-xr-x   8 root     root         4096 jun 1 15:20
/etc/apache2
  32135     4 drwxr-xr-x   2 root     root         4096 jun 1 15:20
/etc/apache2/sites-available
  32136     4 drwxr-xr-x   2 root     root         4096 jun 1 15:20
/etc/apache2/sites-enabled
  32132     4 drwxr-xr-x   2 root     root         4096 jun 7 16:30
/etc/apache2/conf-enabled
  32131     4 drwxr-xr-x   2 root     root         4096 jun 7 16:27
/etc/apache2/conf-available
  32134     4 drwxr-xr-x   2 root     root         4096 jun 7 18:28
/etc/apache2/mods-enabled
  32133     12 drwxr-xr-x   2 root     root       12288 jun 7 18:28
/etc/apache2/mods-available
  145084     4 drwxr-x---   2 root     adm         4096 jun 8 11:46
/var/log/apache2

En cambio los archivos web deben ser del usuario que corre el servicio, típicamente esto se
consigue con:
 # chown www-data:www-data /var/www/example.com/

Mitigar ataque DDOS

Un ataque de DoS (Denial of Service) agota los recursos de un servidor haciendo que uno o más
servicios dejen de responder. Cuando el ataque proviene de múltiples orígenes se dice que es un
DDOS (Distributed Denial of Service).

Algunas definiciones

XSS: Es un tipo de inyección, en el cual se inyectan scripts malicioso en un sitio web de confianza.
La víctima inadvertidamente puede estar ejecutando código que realiza un ataque de denegación
de servicio.

HTTP(S) GET/POST Flood: Este tipo de ataque sucede cuando se envía un enorme volumen de
solicitudes HTTP GET y/o POST y seproduce en capa de aplicación.

Slow Loris: En este caso el atacante envía una enorme cantidad de peticiones una tras otra, pero
con baja ancho de banda. Esto resulta en tipo de maniobra que requiere pocos recursos, pero
que resulta muy perjudicial para la víctima, ya que puede llevar al agotamiento en la cantidad de
sockets.

LAND: El envío de segmentos TCP SYN falsificados a una máquina con el mismo par IP/puerto
tanto para el origen como para el destino. El equipo víctima puede entrar un bucle infinito y el
consiguiente cuelgue del sistema.

XDOS: Se realiza con mensajes en XML con muchísimas firmas digitales que consume los ciclos
del CPU del sistema atacado provancdo la caída del sitio web.

El módulo mod_evasive sirve para mitigar este tipo de ataques, bloqueando direcciones IP que:

Soliciten la misma página más de una determinada cantidad de veces por segundo.
Hagan más de 50 peticiones por segundo al mismo proceso hijo.
Hagan solicitudes mientras está temporalmente bloqueada.

El módulo mod_evasive

El paquete se puede instalar o bien compilando o instalando con el gestor de paquetes de la

distribución.

Vista al fichero de configuración:

<IfModule mod_evasive24.c>
DOSHashTableSize 3097
DOSPageCount 4
DOSSiteCount 400
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSWhitelist 192.168.40.*
</IfModule>
 Directiva Descripción

El tamaño de la tabla de hash que define el número de nodos de

DOSHashTableSize primer nivel por cada tabla de proceso hijo. Este número incrementa
el rendimiento a expensas de mayor consumo de memoria.

DOSPageCount El límite de peticiones para una misma página.

DOSSiteCount El umbral por sitio.

DOSPageInterval Define el período de tiempo para DOSPageCount.

DOSSiteInterval Define el período de tiempo para DOSSiteCount.

La cantidad de tiempo en segundos en el cual la IP quedará

DOSBlockingPeriod bloqueado. Si la IP bloqueada vuelve a hacer la petición se reinicia el
tiempo de bloqueo,

Direcciones IP que no se bloquearán (se pueden poner caracteres

DOSWhitelist
comodines), y se puede usar más de una vez.

Está herramienta es conveniente combinarla con algún otro tipo de firewall. En el caso de
bloqueo aparecerá una línea como la siguiente en el log:

ene 19 09:54:47 www.example.com mod_evasive[43393]: Blacklisting address

190.0.2.0: possible DoS attack.

El módulo mod_qos

Para prevenir el ataque Slow Loris se usa el módulo mod_qos, el cual tiene los siguientes niveles
de protección:

Ancho de banda: acelera solicitudes y respuestas a ciertas direcciones en el servidor.

Conexión: Limita el número de conexiones al servidor web.
Solicitudes: Aplica diferentes prioridades a diferentes direcciones de un servidor.
Encabezados: Filtra solicitudes y URL’s sospechosas.

La siguiente es una configuración básica:

<IfModule mod_qos.c>
MaxClients 1792
TimeOut 10
KeepAlive on
KeepAliveTimeout 5
MaxKeepAliveRequests 30
QS_SrvMaxConnClose 80%
QS_ClientEntries 100000
QS_SrvMinDataRate 150 1200 500
</IfModule>

 
 Directiva Descripción

MaxClients La cantidad máxima de conexiones TCP

TimeOut El tIempo de inactividad (segundos)

KeepAlive Permite múltiples solicitudes en la misma conexión

Cuanto tiempo va a esperar entre peticiones para una misma

KeepAliveTimeout
conexión TCP (segundos)

MaxKeepAliveRequests Cantidad de peticiones permitidas por conexión persistente

Permite definir una cantidad máxima conexiones persistentes,

QS_SrvMaxConnClose
puede ser un número o un porcentaje de MaxClients

QS_ClientEntries Define la cantidad de clientes que puede manejar QoS

Tiene 3 parámetros:

- La mínima cantidad de bytes por segundo que debe alcanzar el

cliente
QS_SrvMinDataRate - Al llegar a MaxClients debe llegar a este rate
- El número de conexiones activas para aplicar esta restrocción.

Este valor es para todo apache, no se puede aplicar a un único

host virtual.

El siguiente es un ejemplo de mensajes en los logs cuando se pasa algún límite:

[Wed Jan 24 18:43:24.105364 2018] [:error] [pid 11540:tid 140329092634368]

mod_qos(034): access denied, QS_SrvMinDataRate
rule (in): min=2010, this connection=64, c=192.168.121.1
[Wed Jan 24 18:43:24.105372 2018] [:error] [pid 11540:tid 140329092634368]
mod_qos(034): access denied, QS_SrvMinDataRate
rule (in): min=2010, this connection=64, c=192.168.121.1
[Wed Jan 24 18:43:24.105376 2018] [:error] [pid 11540:tid 140329092634368]
mod_qos(034): access denied, QS_SrvMinDataRate
rule (in): min=2010, this connection=64, c=192.168.121.1

El módulo mod_reqtimeout

Este módulo ya viene de manera predeterminada con Apache e impone un tiempo y un cantidad
mínima de datos por cada solicitud que recibe. El valor predeterminado es:

<IfModule reqtimeout_module>
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>

De acuerdo a eta configuración el servidor esperará 20 segundos a que el cliente envíe la solicitud
y los encabezados. Si el cliente envía datos, por cada 500 bytes se incrementará en 1 segundo el
tiempo de espera, pero nunca sobrepasará los 40 segundos. Para el cuerpo del http esperará
hasta 20 segundos. La tasa mínima de transferencia debe ser según este ejemplo de 500 bytes
por segundo.
El módulo mod_suexec

Otra medida de protección es la utilización del modulo mod_suexec. Este módulo permite tener
varios servidores virtuales y que cada uno se ejecute como un usuario distinto al del servicio
apache.

Vista del arhivo de configuración example.com.conf :

<VirtualHost *80>
ServerName juan.example.com
DocumentRoot /var/www/juan
SuexecUserGroup juan juan
</VirtualHost>

<VirtualHost>
ServerName maria.example.com
DocumentRoot /var/www/maria
SuexecUserGroup maria maria
</VirtualHost>

El módulo mod_security
Lo ponemos en un apartado especial ya que se trata de un cortafuegos de aplicaciones web (
WAF) y se lo puede usar como módulo de apache. Este módulo tiene la capacidad de analizar los
cuerpos de las solicitudes HTTP, actuar como un detector de intrusos web tomando algún tipo de
acción.

Puede comportarse de manera “positiva” o “negativa”. En el primer caso deniega todo lo que no
está permitido, en el segundo todo lo que signifique anomalías, comportamientos inusuales,
ataques comunes de aplicaciones. Además, puede realizar un parcheo virtual.

El funcionamiento es:

Análisis de datos
Buffering: Retiene los datos en memoria
Logging: Registra lo analizado
Motor de reglas: Toma alguna acción

Esta es una configuración posible de /etc/apache/conf.d/mod_security.conf .

Vista al fichero de configuración conf-available/security.conf :

#
# Disable access to the entire file system except for the directories that
# are explicitly allowed later.
#
# This currently breaks the configurations that come with some web application
# Debian packages.
#
#<Directory />
#   AllowOverride None
#   Require all denied
#</Directory>
# Changing the following options will not really affect the security of the
# server, but might make attacks slightly more difficult in some cases.

#
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of: Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
#ServerTokens Minimal
ServerTokens OS
#ServerTokens Full

#
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
#ServerSignature Off
ServerSignature On

#
# Allow TRACE method
#
# Set to "extended" to also reflect the request body (only for testing and
# diagnostic purposes).
#
# Set to one of: On | Off | extended
TraceEnable Off
#TraceEnable On

#
# Forbid access to version control directories
#
# If you use version control systems in your document root, you should
# probably deny access to their directories. For example, for subversion:
#
#<DirectoryMatch "/\.svn">
#   Require all denied
#</DirectoryMatch>

#
# Setting this header will prevent MSIE from interpreting files as something
# else than declared by the content type in the HTTP headers.
# Requires mod_headers to be enabled.
#
#Header set X-Content-Type-Options: "nosniff"

#
# Setting this header will prevent other sites from embedding pages from this
# site as frames. This defends against clickjacking attacks.
# Requires mod_headers to be enabled.
#
#Header set X-Frame-Options: "sameorigin"
Las reglas tienen este aspecto:

SecRule Variables Operador Acciones

Las variables es dónde va a mirar, operador es cómo y las acciones es qué va a hacer.

Por ejemplo, tomemos en cuenta la siguiente regla:

SecRule REQUEST_URI "etc/group" "phase:2,deny,log,status:406,id:500005"

Va a mirar en la variable REQUEST_URI si contiene etc/group y denegará la operación

correspondiente al cuerpo de la solicitud del cliente (phase:2), además de loguearla, darle estado
http 406 y asignarle el id 500005.