Bacchuss WIPS

Bacchuss WIPS
Análisis de prestaciones y su impacto en escenarios de producción
......................................................................................................................................................................................................................................................
1. Introducción
Bacchuss WIPS es un firewall de aplicaciones Web (WAF) que
cumple con todos los requerimientos impuestos por las prácticas
de la industria para protección de aplicaciones y servicios Web
(OWASP, WASC) y por estándares y regulaciones en el ámbito de
seguridad de la información (ISO/IEC 27002, PCI-DSS, SOX, BCRA,
etc.). WIPS está soportado por procesos de desarrollo y
tecnologías de última generación, involucra conocimiento de una
gran comunidad de carácter internacional dedicada
específicamente a la protección de recursos Web, y está soportada
localmente por un grupo de especialistas en seguridad Web que
respalda su operación y permite avanzar en la respuesta a nuevos
requerimientos impuestos por el mercado.
Una de las cuestiones fundamentales a la hora de considerar la
adquisición de un WAF es el impacto que este puede tener en el
modelo de negocios objetivo en términos de métricas de
eficiencia como tiempos de respuesta, tasa de solicitudes por
segundo, entre otros. En este sentido, el dimensionamiento del
dispositivo estará estrechamente vinculado con las prestaciones
que se deseen obtener considerando los siguientes aspectos
fundamentales:
• Cantidad de aplicaciones a soportar
• Calidad de las aplicaciones (estáticas vs dinámicas)
• Modelos de protección (negativo/positivo/mixto)
• Cantidad y calidad de reglas de detección
Desde la perspectiva del usuario, las acciones llevadas adelante
(por el navegador) desde el momento en que se genera una
solicitud sobre un recurso web hasta la fase final de recepción del
mismo son:
1. Conexión al servidor web
2. Solicitud del recurso deseado
3. Latencia de servicio por parte del servidor (desde la
interpretación, hasta el procesamiento y enlazado, hasta el
rendering y el inicio de la presentación)
4. Descarga del archivo
El impacto de WIPS sobre los tr estará enfocado en la fase 3
identificada arriba, e involucra a todos los procesos necesarios
para generar el HTML de respuesta.
Un aspecto importante que deberá ser atendido es, como se verá
mas adelante, la utilización de memoria RAM por parte del
servidor web Apache, componente fundamental de Bacchuss
WIPS. En su configuración más típica de funcionamiento conocida
como "prefork", Apache inicia un nuevo proceso hijo por cada
conexión activa contra el servicio. La consecuencia directa de este
modo de funcionamiento es que el número de instancias de
Apache crece o decrece linealmente con el número de clientes
conectados, y como el consumo total de memoria de Apache
depende del número de hijos y de la cantidad de memoria que
cada uno de ellos consume, entonces deberá tenerse una idea
clara de como WIPS afecta el consumo de memoria en Apache.
• Configuración de los componentes núcleo (Apache, etc.)
Como en todas las cuestiones técnicas vinculadas a la
determinación de parámetros de prestación de un dispositivo, se
deben asumir algunas cuestiones que permitan simplificar el
problema y a la vez extraer conclusiones relevantes.
3. Escenarios de evaluación
2. Una petición HTTP típica
Para la evaluación se utilizarán tres escenarios:
Para entender el impacto de WIPS en los tiempos de respuesta (tr)
de una aplicación web resulta conveniente comprender la
estructura de una petición típica HTTP de tal modo de establecer
un escenario base sobre el cuál realizar el análisis y generar
hipótesis.
Para poder obtener resultados concretos se utilizarán mediciones
en un entorno de pruebas con un servidor Apache 2.2.8 el cuál
corre sobre un Fedora Linux server (kernel 2.6.25). El hardware es
un Intel Xeon 2.33 GHz dual-core processor con 2 GB de RAM.
• Ejecución de Apache solo
• Ejecución con WIPS, pero sin reglas de detección
• Ejecución con WIPS y un conjunto de reglas
www.bacchuss.com.ar
La reglas de detección de WIPS - The core ruleset (CRS)
--num-conn 1000 (inicio de 1000 conexiones en total)
El conjunto de reglas de WIPS (OWASP CRS) posee alrededor de
120 reglas por defecto que proveen protección por defecto contra
un conjunto de ataques que representan el mayor nivel de riesgo
para las aplicaciones web. Algunas de las cuestiones cubiertas por
WIPS en sus reglas son:
--rate (control de la cantidad de solicitudes por segundo)
Respecto a la última opción, 'rate', esta se irá variando para
ver las respuestas a las diferentes cargas.
A continuación se presenta una salida típica de httperf:
• Solicitudes HTTP sospechosas (ejemplo: valores de
User-Agent o Accept headers inexistentes)
$ ./httperf --hog --server=bytelayer.com --uri
• Inyección SQL
Total: connections 1000 requests 1000 replies 1000
• Cross-Site Scripting (XSS)
/index.html --num-conn 1000 --rate 50
test-duration 20.386 s
Connection rate: 49.1 conn/s (20.4 ms/conn, <=30
• Remote code injection
concurrent connections)
• File disclosure, entre otros.
median 404.5 stddev 16.9
La forma de activar o desactivar las reglas será por medio de su
inclusión no en el archivo de configuración de Apache (Include
camino/a/modsecurity/*.conf).
Connection time [ms]: min 404.1 avg 408.2 max 591.3
Connection time [ms]: connect 102.3
Connection length [replies/conn]: 1.000
Request rate: 49.1 req/s (20.4 ms/req)
Request size [B]: 95.0
Reply rate [replies/s]: min 46.0 avg 49.0 max 50.0
stddev 2.0 (4 samples)
4. Sobre el método y las herramientas de evaluación
El interrogante fundamental en este trabajo es:
Reply time [ms]: response 103.1 transfer 202.9
Reply size [B]: header 244.0 content 19531.0 footer 0.0
(total 19775.0)
¿Que efecto tiene WIPS sobre los tiempos de respuesta de
aplicaciones web?
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0
para lo que deberán plantearse los siguientes interrogantes:
Net I/O: 951.9 KB/s (7.8*10^6 bps)
• ¿Que efecto tiene WIPS sobre los tiempos de respuesta de
Apache?
• ¿Como puede medirse este efecto?
CPU time [s]: user 2.37 system 17.14 (user 11.6% system
84.1% total 95.7%)
Errors: total 0 client-timo 0 socket-timo 0 connrefused
0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other
0
• ¿Como se debería dimensionar el hardware para WIPS?
La manera de medir la diferencia entre los tiempos de respuesta
deberá contemplar validez estadística por lo que se realizarán
múltiples ensayos y se trabajará finalmente sobre los valores
promedio. Esto aísla a los ensayos de posibles desviaciones por
procesos propios del sistema operativo como procesamiento
intensivo por scheduling, atención de interrupciones, etc.
Con el fin de estimular a Bacchuss WIPS se recurrirá a
'httperf' [2], herramienta de benchmarking para servidores
HTTP. Httperf permite simular grandes cargas contra servidores y
obtener resultados estadísticos sobre el comportamiento de los
mismos.
Opciones de httperf a utilizar:
--hog (utilizar tantos puertos TCP como sea necesario)
--uri/index.html (solicitud de recurso)
Como puede verse, la salida muestra:
• Número de conexiones iniciadas por segundo ("Connection
rate").
• Tasa a la cuál se generaron requerimientos sobre el archivo
web ("Request rate").
• Tasa de respuesta del servidor en base a su capacidad ("Reply
rate").
Además se obtiene información valiosa como:
• Tiempo requerido entre el envío del primer byte al servidor y
la llegada del primer byte de respuesta ("reply time –
response", en este caso 103.1), y
• Tiempo total para recibir la respuesta completa desde el
servidor ("transfer time", en este caso 202,9).
www.bacchuss.com.ar
La página estática que se estará utilizando para los ensayos
(índex.html) es de tamaño promedio, de 20 KB. Httperf
descargará el archivo una única vez por conexión, sin seguir
ningún enlace que pueda estar contemplado en el mismo.
y sin procesos de uso intensivo de memoria, es posible llegar a
situaciones en la que 'top' muestre solo 50 MB. Además, debe
considerarse que el consumo de Apache resulta de la sumatoria de
los consumos de todos sus hijos aspecto que será profundizado
mas adelante en este trabajo.
La arquitectura de red utilizada para el ensayo es la de la Figura 1,
donde WIPS actúa como punto de choque para todos los
requerimientos realizados al servidor web (en este caso una
granja de 2 servidores).
El siguiente script realizará el trabajo:
#!/bin/sh
# apache_mem.sh
# Calculate the Apache memory usage
ps -ef | grep apache2 | awk '{ print $2 }' |
xargs pmap -x | grep 'total kB' |
awk '{ print $3 }' |
awk '{ sum += $1 } END { print sum/1024 MB}'
Figura 1: Bacchuss WIPS en escenario de pruebas.
Se ejecuta un 'ps' para encontrar todos los hijos de Apache, y se
envía el PID de cada uno a 'pmap' para determinar el consumo
de memoria. Sobre el resultado se aplica 'awk' para extraer el
valor (en MB) para la suma.
A continuación se muestra el consumo base de memoria:
5. Mediciones
5.1 Medición base, respuesta de Apache (sin WIPS)
Tiempos de respuesta:
El servidor entrega el recurso en tiempos promedio de 300 ms
hasta que se alcanzan las 75 solicitudes por segundo (sps).
A partir de este valor el tiempo se incrementa hasta llegar a 1 s
para 500 sps.
Uso de memoria:
Para la medición de la memoria no puede utilizarse el comando
'top' debido a las características de funcionemainto del sistema
operativo que hacen que este consuma de manera permanente
todo la memoria libre. Así, para un servidor con varios GB de RAM
Apache comienza consumiendo 300 MB de memoria RAM, valor
que mantiene estable hasta aproximadamente 150 consultas por
segundo. A partir de este punto el crecimiento es muy acentuado,
hasta alcanzar un consumo de 2.4 GB para 500 sps, valor que
excede a la cantidad de memoria física del servidor cosa que es
posible gracias a la arquitectura de memoria virtual de Linux. A
partir de los 2GB, el uso de la memoria virtual, que no es otra cosa
que el swapping de páginas de memoria al disco rígido, comienza
a agravar los retardos debido a los tiempos de acceso a disco.
Uso de CPU:
En todas las simulaciones, la carga de CPU rondó entre el 1% y el
2%, sin importar la tasa de solicitudes. En este experimento, y en
muchos otros relacionados con Apache, se ve que el CPU no es un
facto determinante de performance.
www.bacchuss.com.ar
5.2 Medición con WIPS, pero sin reglas de detección
5.3 Medición con WIPS y reglas de detección estándar
Tiempos de respuesta:
En este punto se analizará el tr y el comportamiento de Apache
junto a WIPS, pero con carga de reglas de detección basadas en el
conjunto estándar de la distribución "core-ruleset" (CRS).
En WIPS se han activado las opciones:
• SecRequestBodyAccess, y
• SecResponseBodyAccess
Tiempos de respuesta:
En la siguiente imagen se presenta el tiempo de respuesta:
directivas que generan una copia temporal intermedia (buffer) de
los contenidos de solicitud y respuesta, antes de ser direccionados
a destino para su análisis. Si se experimentan retardos en este
escenario, será por el almacenamiento temporal intermedio de
datos (buffering).
La siguiente imagen muestra el tr:
Uso de memoria:
Puede verse de la gráfica siguiente que el valor de quiebre pasó
ahora de 75 a 50 sps. Esto genera una reducción del 33% de la
cantidad de sps que WIPS puede manejar.
La curva es similar a la del escenario base, hasta 75 sps el tiempo
de respuesta es estable mientras que para valores de entre 75 y
350 sps las cosas comienzan a cambiar evidenciándose un
crecimiento aceptable. A partir de 350, el crecimiento se proyecta
dramáticamente en crecimiento.
Uso de memoria:
Respecto a la utilización de memoria, el comportamiento también
es muy similar al caso base.
¿Que factores pueden estar generando el incremento en los tiempos
de respuesta?
Puede verse en la última gráfica que a las 50 sps la memoria
consumida por Apache comienza a incrementarse
dramáticamente hasta alcanzar un valor de 2 GB, valor a partir del
cuál se comienza a generar almacenamiento temporal
intermedio, hecho que sustentaría la hipótesis del impacto de
memoria.
Lo que se evidencia es un incremento de 1,3 MB en la cantidad de
memoria RAM que utiliza cada hijo de Apache, generándose
finalmente una carga de 26 MB extra para el escenario dado (10%
del total para el servidor Apache cuando está desocupado).
www.bacchuss.com.ar
La siguiente gráfica muestra los tiempos de respuesta de WIPS
solo, y WIPS con reglas de detección:
¿podría deberse a las directivas RequestBodyAccess y
ResponseBodyAccess que generan almacenamiento temporal
intermedio (buffering)?
6.1 Comportamiento de tiempos
La siguiente gráfica muestra el tiempo de respuesta de WIPS con y
sin las opciones RequestBodyAccess y ResponseBodyAccess
activas:
La siguiente gráfica muestra los consumos de memoria de WIPS
solo, y WIPS con reglas de detección:
Como puede verse, la eliminación del almacenamiento temporal
intermedio mejora las condiciones desplazando de 50 a 75 las
solicitudes que WIPS puede manejar antes del problema.
Nota: debe tenerse en cuenta que al ser activadas, tanto
RequestBodyAccess como ResponseBodyAccess
generan la reserva (consumo) de memoria extra.
Algunas ideas...
Al momento que el servidor alcanza una determinada tasa de sps,
el consumo de memoria explota y se incurre en almacenamiento
temporal de información (buffering). Alcanzada esta situación, las
cosas empeoran aún mas sin control.
En un valor de 50 sps, la respuesta de WIPS con reglas es muy
similar a la del escenario base por lo que puede establecerse que
la inclusión de las reglas no generan un impacto significativo en
las prestaciones de Apache ya que hasta ese punto hay
disponibilidad de memoria RAM. Este punto es fundamental ya
que parece destacar el impacto de la cantidad de memoria RAM
como factor limitante de las prestaciones. El efecto de WIPS
parecería tener impacto en el desplazamiento del valor en el que
se comienza a experimentar la limitación (desde 75 sps a 50 sps,
un 33% menos).
En base a lo recién expuesto puede concluirse que desactivando
RequestBodyAccess
y ResponseBodyAccess
mejoraría el comportamiento de WIPS, siempre que esto sea
viable en base a los requerimientos de protección establecidos.
6.2 Comportamiento de la memoria
La siguiente gráfica muestra el consumo de memoria RAM de
WIPS con y sin las opciones RequestBodyAccess y
ResponseBodyAccess activas:
6. En busca de la causa del cuello de botella
La porción de responsabilidad de WIPS en el problema:
www.bacchuss.com.ar
Tal como era de esperar, se ve que el incremento de memoria con
almacenamiento temporal comienza a las 75 solicitudes por
segundo.
6.3 Consideraciones sobre las reglas de WIPS
Como ha podido verse, la inclusión de las reglas de WIPS generan
una alteración en el comportamiento de los tr de Apache debido a
la utilización de memoria RAM para el almacenamiento de
información temporal intermedia.
Existen dos factores sobre los cuales puede trabajarse para
mejorar el comportamiento de Apache:
• Reducir la cantidad de memoria RAM utilizada por cada
proceso de WIPS, y
• Incrementar la cantidad de memoria RAM del servidor físico
A continuación se avanzará en cuestiones relacionadas con la
optimización del uso de memoria de Apache, y de las reglas de
WIPS.
7. Optimización de Bacchuss WIPS
El estudio anterior muestra que WIPS no genera impacto en el uso
de aplicaciones web a menos que incurra en el uso excesivo de
memoria RAM, factor directamente vinculado a la tasa de sps, o
que se tengan demasiadas reglas de detección en equipos
obsoletos.
7.1 Consumo de memoria
Reducir el número de reglas de detección tiene impacto positivo
directo ya que a mayor número de reglas, mayor consumo de
memoria por cada proceso de Apache. De igual modo, cuanto mas
reglas hay mayor será el tiempo de ejecución por lo que la
ganancia en este punto es doble.
7.2 Sobre las reglas de detección
A continuación se presentan algunas cuestiones sobre la
configuración y el desarrollo de reglas que pueden tener impacto
en WIPS.
Evitar la inspección de contenido estático: si se evita la inspección
se pueden lograr ganancias importantes, sobre todo para
determinadas aplicaciones web que manejan mucho contenido
estático como imágenes, binarios, etc. Abajo se muestra un
ejemplo de una regla que permite implementar esta excepción:
SecRule REQUEST_FILENAME |
".(?:jpe?g|gif|png|js|exe)$" |
"phase:1,allow"
7.3 Utilización de @pm y @pmFromFile
La utilización de @pm y @pmFromFile puede ofrecer mejoras de
tiempo respecto a la rutina estándar de detección de patrones
regex en los casos en los que se deba hacer inspección de grandes
listas de frases (ej: listas blancas).
7.4 Registro (logging)
Al activar las funciones de auditoría y depuración se incurre
inexorablemente en un costo por escritura en disco. Respecto al
registro de depuración, este es especialmente costoso
(especialmente en nivel 9) por lo que solo deberá ser activado en
escarnios de prueba o depuración.
7.5 Buen habito de escritura de reglas
Hay ciertas cuestiones que garantizan buena prestación al
momento de escribir reglas con expresiones regulares (regex).
Utilizar paréntesis (non-capturing) siempre que sea posible: es
una construcción del tipo "(?: )" que cumple el mismo rol que los
paréntesis normales, salvo que usado en el contexto de regexp
evita la utilización de referencias hacia atrás (backreferences) y
por consiguiente la utilización de memoria extra También salva
procesamiento extra.
Utilizar una única expresión regular siempre que sea posible: es
mejor usar una única regexp que varias mas chicas. Por ejemplo,
la regla:
SecRule REQUEST_FILENAME |
".(?:exe|bat|pif)" deny
será mas eficiente que la definición de una única reglas por
formato.
8. Análisis de prestaciones del servidor web Apache
A continuación se analizará una serie de aspectos que pueden
afectar de manera significativa las prestaciones del servidor web
Apache, y se avanzará en soluciones que pueden ser
implementadas para mejorar los tr. Hay dos lineas generales
sobre las cuales avanzar:
• Cuestiones vinculadas con el hardware
• Cuestiones de configuración y ejecución
• Cuestiones vinculadas a la compilación
www.bacchuss.com.ar
8.1 Cuestiones vinculadas al hardware
La principal característica de hardware que puede impactar en la
prestaciones de Apache es la cantidad de memoria RAM del
servidor físico sobre el que se ejecuta [3]. Apache no deberá, bajo
ninguna circunstancia, utilizar memoria swap (almacenamiento
de memoria temporal intermedia en disco) ya que se
incrementará el tr hasta valores que pueden comenzar a resultar
inaceptables para los usuarios.
Mas RAM tengamos disponible en hardware, mejor!
Para optimizar el uso de la memoria RAM se deberá hacer uso de
la directiva 'MaxClients' que para el caso de servidores de
tipo "non-threaded" (ej: prefork) permite limitar el número de
procesos hijos creados para atender a las peticiones (valor por
defecto 256) [4]. En este sentido, el número máximo de hijos
deberá ser fijado de tal modo que se consuma toda la memoria
RAM física disponible en el servidor, no más.
La fórmula para determinar el valor de 'MaxClients' es:
MaxClients = (RAM total − RAM para OS − RAM para
otros procesos) / RAM por proceso httpd/apache2
Los valores de consumos pueden ser determinados por medio de
la utilización de los comandos:
• 'ps -ylC httpd --sort:rss': determinación del
tamaño del proceso, se debe dividir por 1024 para obtener el
resultado en MB. También se pude probar 'top'.
• 'free -m': para obtener una vista general. La clave es
observar el valor de buffers/cache utilizado.
• 'vmstat 2 5': muestra el número de procesos en estado
"runnable", "blocked", y "waiting"; y los valores de "swap in"
y "swap out".
Mas allá de la memoria están las cuestiones asociadas al resto de
los componentes, que cuanto más rápidos, mejor! (CPU, Disco,
Red).
8.2 Cuestiones de configuración y ejecución
Resolución de nombres (DNS)
Apache cuenta con una directiva que permite utilizar ACLs de tipo:
Para su funcionamiento, el servidor realiza una consulta DNS por
cada solicitud que llega incurriendo en costo extra. De no ser
utilizada, esta opción deberá ser desactivada [5].
Creación de procesos
En su funcionamiento original hasta la versión 1.3, Apache
requería de un tiempo considerable para responder al incremento
de sps ya que solo se generaba un nuevo hijo por segundo para
preservar la estabilidad del sistema. En este escenario, si el valor
de la directiva 'StartServers' [6] era definida con un valor
5, entonces se requerirían 95 segundos para alcanzar la cantidad
de hijos necesaria para responder a la carga. Este modo de
funcionamiento tuvo tal efecto en la prestación percibida por las
herramientas de benchmarking que debió ser cambiado.
A partir de la versión 1.3, Apache genera un hijo al inicio, de ser
necesario genera 2 mas y espera 1 segundo, luego crea 4 mas y
espera otro segundo, luego 8, y así sucesivamente en base
exponencial para responder a la carga hasta alcanzar un valor
máximo de 32 hijos creados por segundo. En este nuevo modo, la
creación de hijos se detiene en el momento que se alcanza el valor
definido por 'MinSpareServers'. Este valor debe ser
considerado en servidores realmente demandados ya que tiene
implicancias que pueden afectar la estabilidad. En los casos en
que mas de 4 hijos sean generados por segundo se genera un
aviso en el 'ErrorLog' [8].
Igual de importante que el proceso de creación es el de muerte de
los hijos de Apache, aspecto manejado por la directiva
'MaxRequestsPerChild' [9]. Esta directiva define el
número de solicitudes que manejará un hijo durante su tiempo de
vida (el valor 0 implica que el hijo jamás expirará, en algunas
configuraciones por defecto el valor puede ser 10000). Esta
directiva permite proteger al sistema contra consumo excesivo de
memoria RAM por causa de goteos (leak). Lo recomendado es
probar con valores altos e ir ajustando hacia abajo.
Un tercer aspecto importante en el contexto de hijos de Apache es
la utilización de 'Keep-Alives" que hacen que estos queden a la
espera de mas solicitudes sobre conexiones establecidas con la
correspondiente pérdida de recursos. Este factor es manejado por
medio de la directiva 'KeepAliveTimeout' [10] que
permite establecer el tiempo que un hijo esperará por solicitudes
en una conexión persistente. En su valor por defecto de 5 s intenta
minimizar este efecto de espera.
• Allow from domain, o
• Deny from domain
www.bacchuss.com.ar
Ejemplo:
utilizado en escenarios de gran demanda ya que utiliza menor
cantidad de memoria que la alternativa.
Sistema: CentOS 4.4, con 128MB RAM
Apache: v2.0, mpm_prefork, mod_php, mod_rewrite, mod_ssl,
y otros modulos
Otros Servicios:
MySQL, Bind
Memoria del sistema reportada:
120MB
Tamaño del proceso httpd:
7-13MB
Memoria disponible para Apache:
90MB
• "MPM prefork": modelo que hace uso de múltiples hijos cada
uno de los cuales posee un único hilo de ejecución. Cada hijo
maneja una conexión por vez, y en general aunque es
comparable en velocidad al modelo worker, utiliza mayor
cantidad de memoria RAM. Es de especial interés para
escenarios donde se requiere gran estabiliu]dad o
funcionalidad de depuración avanzada debido a la existencia
de un único hilo de ejecución por conexión.
Abajo se presentan algunas configuraciones por defecto:
En base a los valores reportados, la configuración podría ser:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 15
MaxClients 15
MaxRequestsPerChild 2000
Separación de contenidos estáticos vs dinámicos
Debe desalentarse la mezcla de contenido dinámico y estático
para un mismo servidor web. Un proceso Apache sirviendo
contenido dinámico puede utilizar entre 3 y 20 MB de memoria
RAM, tamaño que se irá ajustando en relación al contenido
servido. El problema es que una vez finalizado el servicio de un
determinado contenido, el tamaño del proceso nunca se reduce,
hasta el momento en el que este muere finalmente. Un ejemplo
de esto lo constituye el caso en el que un proceso utiliza 20 MB
para servir un contenido PHP, y luego en mismo proceso recibe
una solicitud por ua imágen, recurso que podría ser servido con un
consumo asociado de memoria de 1 MB.
En este sentido, WIPS funciona como un servidor-pequeño que
contiene compilados de manera estática los procesos
indispensables sirviendo de front-end a las aplicaciones donde se
encuentra el contenido activo.
8.3 Cuestiones vinculadas a la compilación
Módulos para modelos de concurrencia (MPM) [11]
Apache soporta diferentes módulos para modelos de concurrencia
("Multi-Processing Modules" o MPMs) cuya selección tendrá
impacto en la velocidad y escalablidad del servidor.
• "MPM worker": modelo que utiliza múltiples hijos, con
múltiples hilos de ejecución en cada uno de ellos. Cada hilo se
encarga de manejar una conexión por vez. Este modelo es
<IfModule prefork.c>
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
</IfModule>
8
5
20
150
1000
<IfModule worker.c>
StartServers
MaxClients
MinSpareThreads
MaxSpareThreads
ThreadsPerChild
MaxRequestsPerChild
</IfModule>
2
150
25
75
25
0
Módulos
Debido a que el consumo de memoria es el factor clave para lograr
buenas prestaciones, es fundamental eliminar todo módulo que
no sea necesario para el funcionemiento del sistema. Si los
módulos se encuentran cargados como "Dynamic Shared Object"
(DSO), entonces su eliminación resulta muy simple por medio de
la utilización de la directiva 'LoadModule'. Si por otro lado,
existen módulos compilados de manera estática en el demonio
httpd, entonces deberá procederse a su recompilación. Una lista
mínima de módulos requeridos es:
• mod_mime
• mod_dir
Operaciones atómicas
Algunos módulos como mod_cache y algunas versiones de
desarrollo de MPM worker utilizan la API APR, utilizada para
optimizar las operaciones de sincronización de hilos (threats). APR
implementa esto en base a los mecanismos implementados en la
www.bacchuss.com.ar
CPU como por ejemplo "compare-and-swap"
implememntado directamente en hardware.
(CAS)
mod_status y ExtendedStatus On
Si se utiliza el módulo 'mod_status' y se configura
'ExtendedStatus On' entonces por cada solicitud Apache
realizará dos llamadas a 'gettimeofday(2)', y varias
llamadas mas a 'time(2)'. Para configuraciones de altas
prestaciones
se
debe
configurar
la
directiva
'ExtendedStatus off'.
9. Conclusiones
El estudio mostró que la principal variable de afectación de los
tiempos de respuesta (tr) de WIPS la constituye la cantidad de
memoria RAM presente en el hardware, y el consumo de la misma
por parte de los diferentes componentes de la solución,
principalmente Apache. Se ha podido mostrar que el tr comienza
a evidenciar deterioros cuando la cantidad de hijos de Apache
alcanzan un número suficiente como para consumir el total de
memoria RAM disponible. Sumado al consumo natural de
memoria RAM de los hijos de apache involucrados en el servicio
de solicitudes se destaca el consumo vinculado a las rutinas de
detección de WIPS que generan almacensmiento temporal
intermedio (buffering) para dar soporte a sus modelos de
protección. Un tercer aspecto que debe ser tenido en cuenta es la
correcta configuración y compilación de los binarios de los
componentes centrales ya que tienen también un gran impacto
en la solución final.
En base a lo expuesto, será de gran importancia la determinación
de la cantidad de memoria correcta que deberá poseer el
hardware, así como la correcta compilación y configuración de los
diversos componentes de WIPS.
Con respecto a la influencia de la capacidad de procesamiento
(CPU), este comienza a ser relevante a partir del momento en el
que se consideren rutinas de detacción intensivas en WIPS, sobre
todo mediante el desarrollo de modelos positivos de seguridad en
el que se hace gran uso de acceso a variables y a rutinas de
detección por medio de expresiones regulares (regexp), detección
de patrones (pm), etc.
Finalmente, y por la experiencia ganada en proyectos de
producción sobre este tipo de soluciones, se deberá contar con
interfaces de red que permitan alcanzar el máximo potencial sin
que estas se conviertan en el cuello de botella. Además será un
factor determinante la cantidad de aplicaciones que se deberán
soportar a soportar, y la calidad de estas con respecto al tipo de
contenidos (estáticas vs dinámicas).
www.bacchuss.com.ar
Referencias:
[1] "Ways to improve performance of your server in ModSecurity
2.5"
http://www.packtpub.com/article/ways-improve-performance-s
erver-in-modsecurity2.5
[2] httperf
http://www.hpl.hp.com/research/linux/httperf/
[3] Apache 2.2 Performance Tuning
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
[4] Apache 2.2 MaxClients Directive
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ma
xclients
[5] Apache 2.2 HostnameLookups Directive
http://httpd.apache.org/docs/2.2/mod/core.html#hostnamelook
ups
[6] Apache 2.2 StartServers Directive
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#sta
rtservers
[7] Apache 2.2 MinSpareServers Directive
http://httpd.apache.org/docs/2.2/mod/prefork.html#minsparese
rvers
[8] Apache 2.2 ErrorLog Directive
http://httpd.apache.org/docs/2.2/mod/core.html#errorlog
[9] Apache 2.2 MaxRequestsPerChild Directive
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ma
xrequestsperchild
[10] Apache 2.2 KeepAliveTimeout Directive
http://httpd.apache.org/docs/2.2/mod/core.html#keepalivetime
out
[11] Apache 2.2 Compile-Time Configuration Issues
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html#compil
etime
www.bacchuss.com.ar
Bacchuss
Contactos
......................................................................................................................................................................................................................................................
HQ-SI
Sarmiento 537 PB B
HQ-TI
Sarmiento 537 PB
Rosario - Santa Fe - Argentina
+54 341 5271213
Rosario - Santa Fe - Argentina
+54 341 5271214
http://www.bacchuss.com.ar
[email protected]
http://www.bacchuss.com.ar/TI
[email protected]
Sobre BACCHUSS ®
Fundada en el año 2001, BACCHUSS ® se ha convertido en una empresa líder en Servicios de Consultoría en Seguridad de la Información en Argentina brindando una serie de productos y servicios
destinados a proteger la infraestructura crítica para corporaciones privadas y para organizaciones gubernamentales y del estado, tomando siempre como base estándares internacionales y prácticas
recomendadas en la materia. Las oficinas de BACCHUSS ® se encuentran en la ciudad de Rosarios, Santa Fe, Argentina; desde donde se desarrollan las soluciones y se opera con todos los clientes.
Todos los derechos reservados. BACCHUSS y el Logo de BACCHUSS son marcas registradas.
Copyright © 2001-2012, BACCHUSS.
www.bacchuss.com.ar