seguridadProtección de servidor

40 Linux+ 1/2007

seguridadProtección de servidor

41www.lpmagazine.org

linux

@so

ftwar

e.co

m.p

lProtección del servidor ApacheCuando hablamos de Internet debemos hablar del servidor Apache, ya que es gracias a este servidor web por el que podemos publicar en Internet, así como podemos recibir la opinión de los internautas que han visitado nuestro sitio web, podemos colgar gráficos, fotos, banners con efectos flash, música, video, etc.

Jose Ignacio Ruiz de Alegría

El servidor Apache, tanto la versión 1.3.x como la versión 2, se ha convertido en un servidor web de referencia para todo diseñador de páginas web, webmaster, etc. Aunque es uno

de los más estables que hay actualmente en el mercado, debemos de recordar también que dicho servidor se en-cuentra constantemente sometido a ataques a través de Internet o de la web, los dos más comunes son el ataque a través de la instrucción POST. Dicha instrucción es ampliamente utilizada en Internet porque va unida al envio de información a través de Internet, por el cual un cracker intenta enviar información maliciosa a tra-vés de la red con la intención de perjudicar al servidor o provocar una negación de servicios. Como veremos más adelante hay una forma de evitar o de filtrar la in-formación que se envía vía POST entre el servidor web y el cliente. Otro de los ataques más comunes que se producen a través del servidor Apache son los llamados Ddos Attack o Negación de servicios y como el mismo nombre lo indica, la finalidad de estos ataques es hacer que el servidor Apache se bloquee, lo que traerá como consecuencia la pérdida de servicio. Quién no ha escu-

chado decir que el servidor está caído y que por ese mo-tivo sus paginas web no son accesibles a través de Inter-net.

Para evitar o mitigar en lo más posible esta clase de ataques, existen en el mercado dos módulos, ambos gra-tuitos, que permiten solucionar este tipo de problemas. Sus nombres son: mod_security y mod_evasive. Debido a que el 70 por ciento de los ataques son llevados a través de las aplicaciones web, debemos considerar aplicar un cortafuegos, firewall o filtro, que bloquee las solicitudes que proceden de los clientes hacia el servidor. Esa es la función principal del mod_security. Lo primero que tenemos que hacer es descargarnos el mod_security: des-cargamos el mod_security desde http://www.modsecurity.org/.Descomprimimos el fichero:

tar –xzf modsecurity-Apache-1.9.2.tar.gz

Accedemos al directorio:

cd modsecurity*

seguridadProtección de servidor

40 Linux+ 1/2007

seguridadProtección de servidor

41www.lpmagazine.org

Aquí necesitamos saber para qué versión de Apache lo vamos a instalar, pudiendo ser la versión 2.* o la 1.3.*. Si utilizamos la versión de Apache 1.3.* debemos de hacer:

cd Apache1

Antes de instalar el módulo es conveniente hacer una copia de seguridad del archivo de configuración del servidor, por lo tanto hare-mos lo siguiente:

cp /usr/local/Apache/conf/httpd.conf

/usr/local/Apache/conf/httpd.conf.back

Instalamos el mod_security:

/usr/local/Apache/bin/apxs –cia

mod_security.c

Aquí debemos editar el fichero de configura-ción del Apache (httpd.conf), en dicho fichero debemos poder ver las siguientes instruccio-nes, indicadas abajo:

LoadModule security_module

libexec/mod_security.so

AddModule mod_security.c

Señal inequívoca que el módulo se ha instala-do correctamente, es ahora cuando podemos empezar a añadir las directivas de nuestro filtro o firewall.

Para empezar a escribir las directivas den-tro del fichero de configuración del Apache de-bemos hacer lo siguiente: editamos el httpd.conf, podemos elegir el editor que más nos guste en nuestro caso nano –f httpd.conf

la definición de la directiva del modse-curity será, la siguiente <IfModules mod_se-curity.c>.

Activamos el filtro:

SecFilterEngine On

Activamos el chequeo del url, Post:

SecFilterCheckURLEncoding On

Para evitar que interfiera con las aplicaciones web:

SecFilterCheckUnicodeEncoding Off

Rango de Bytes:

SecFilterForceByteRange 0 255

No permitir guardar un fichero en el direc-torio /tmp:

SecUploadDir /tmp

SecUploadLeepFiles Off

Sólo audita los intentos de violación del ser-vidor, con dicha opción activada, nos dejará en el fichero audit._log, del directorio /usr/local/Apache/logs. Dicho fichero es muy útil para buscar desde qué dominio nos han intentado atacar:

SecAuditEngine RelevantOnly

SecAuditLog logs/audit._log

Definición de los ficheros LOGS, el nivel cero (Level 0) es entorno de producción:

SecFilterDebugLog logs/modesec_

debug_log

SecFilterDebugLevel 0

Escaneo de las solicitudes POST:

SecFilterSacnPost On

Listado 1. Comienzo de las reglas de filtrado

SecFilterSelective THE-REQUEST “wget”

SecFilterSelective THE-REQUEST “lynx”

SecFilterSelective THE-REQUEST “telnet”

SecFilterSelective THE-REQUEST “ssh”

SecFilterSelective THE_REQUEST "scp "

SecFilterSelective THE_REQUEST "rcp "

SecFilterSelective THE_REQUEST "curl "

SecFilterSelective THE-REQUEST “cd /tmp”

SecFilterSelective THE-REQUEST “cd /var/tmp”

SecFilterSelective THE-REQUEST “cd /dev/shm”

SecFilterSelective THE_REQUEST "/../../ "

SecFilterSelective POST_PAYLOAD “Subject\:” chain

SecFilterSelective ARG_Bcc ”.\@”

</ifModule>

Figura 1. mod_security

42

seguridadProtección de servidor

Linux+ 1/2007 43

seguridadProtección de servidor

www.lpmagazine.org

Acción por defecto en caso de filtrado, niega, escribe en el log, muestra status:403:

SecFilterDefaultAction “deny, log,

status:403”

Comienzo de las reglas de filtrado (ver Lis-tado 1).

SecFilterEngineEsta directiva nos da la posibilidad de activar y desactivar el filtro on/off.

SecFilterSacnPost OnCon esta directiva podemos chequear las soli-citudes POST, viene desactivado por defecto, por consiguiente la activamos.

SecFilterDefaultActionEsta directiva sirve para definir qué acción queremos que se ejecute una vez que el filtro que hemos definido detecta que ha llegado una solicitud que lo cumple.

Deny : Interrumpe todos los procesos, de las solicitudes que cumple con nuestro filtro.

Log : Suma una entrada en el error_log.Status:403 : Muestra la pagina 403.

SecFilterForceByteRangeEsta directriz consiste en limitar el rango de Bytes de las solicitudes que se hacen a través del servidor Apache. La intención de esta limi-tación consiste en limitar los ataques overflow attacks, por defecto todo los rangos de bytes son permitidos.

SecAuditEngine RelevantOnly La directiva SecAuditEngine junto con relevant-Only significa que incluye sólo las solicitudes que cumplen con las condiciones de nuestro filtro.

SecAuditLogSuma una entrada en el fichero logs/ audit._log cuando se cumpla una de las condiciones del filtro, dicha acción es muy útil para poder analizar a través de quien nos ha venido el ataque.

Con la directiva SecFilterSelective Location Keywords [Action].

Le permitirá elegir exactamente dónde se utilizará o aplicará el filtro, aquí nosotros podremos elegir entre todas las variables de los CGI, como se puede ver en nuestro caso cualquier petición que contenga las palabras wget, lynx, telnet, etc será automáticamente filtrada. Ver abajo el juego completo de ins-trucciones.

Cabe especial mención a la instrucción de POST_PAYLOAD.

El significado es la de aplicar el filtro en la localización del cuerpo de los peticiones POST. con respecto a la instrucción Chain.

El significado es el de encadenar dos ins-trucciones, véase el ejemplo de arriba.

Reiniciamos el ApacheUna vez que hemos reiniciado el Apache ya tenemos en funcionamiento nuestro filtro, dicho filtro nos protegerá de ciertos ataques y nos permitirá saber a través de cual usua-rio se está cometiendo el ataque. Pero como hemos dicho al principio, otro de los ataque más comunes que afectan al servidor Apa-che es el Ddos attack o negación de servi-cios, quien no ha oído hablar de que el servi-dor Apache está caído y que esa es la causa de que no se vean las páginas web. El Ddos attack se produce de la siguiente manera: cuando alguien introduce el nombre de su sitio web en Mozilla Firefox o en Internet Explorer y comienza a ver su página web, el servidor Apache debe abrir un proceso para atender a esa demanda, dicho proceso lleva por consiguiente un uso de la CPU y de memoria del sistema. El ataque consiste en hacer muchas peticiones sobre la misma página durante un tiempo muy corto, lo que obligará al servidor Apache a abrir innume-rables procesos con la intención de atender a la demanda de peticiones que ha recibido dicho proceso lo que conllevará un mayor consumo de CPU y de memoria del sistema, llegando a colapsar el servidor, una vez lle-gado a este punto, la finalidad de este ataque se ha completado, ya que se ha producidouna carencia del servicio.

La manera de defenderse de esa clase de ataques sería la de crear una lista negra (“blacklist”) o tabla en la cual se guardará

por un tiempo prudencial de unos 10 segun-dos, dicha cantidad es configurable, y compa-rar si dichas IPs se encuentran en la lista negrao blacklist con las IPs de acceso. Si una vez comparadas las IPs resulta que ya se encuentra en su Blacklist le deberá de negar el acceso al servidor Apache o si alguien intenta abrir in-numerables procesos haciendo muchas soli-citudes a la vez en un tiempo, pongamos de 1 segundo, el sistema lo debería de incluir en su blacklist y negarle el acceso también. Debe-mos mencionar otra forma de ser incluido enla blacklist, que es hacer más de 50 peticio-nes en el mismo proceso por segundo.

Pues bien esta herramienta ya existe, el módulo que lo hace posible es mod_evasive. Esta herramienta es muy útil y frena los in-tentos de ataque al servidor mediante el Ddos attack. Los pasos son los siguientes:

Descargamos el mod_evasive desde http://www.zdziarski.com/projects/mod_evasive/ y des-comprimimos el fichero:

tar –xzf mod_evasive

Antes de instalar el módulo es conveniente hacer una copia de seguridad del archivo de configuración del servidor, por consiguiente haremos lo siguiente:

cp /usr/local/Apache/conf/httpd.conf

.../usr/local/Apache/conf/

httpd.conf.back

Accedemos al directorio:

cd mod_evasive*

Instalamos el mod_evasive:

/usr/local/Apache/bin/apxs –cia

mod_evasive.c

Aquí debemos de editar el fichero de confi-guración del Apache (httpd.conf), en dicho fichero debemos de poder ver las siguientes instrucciones, ver abajo:

Listado 2. Juego completo de instrucciones

REMOTE_ADDR, REMOTE_HOST, REMOTE_USER, REMOTE_IDENT, REQUEST_METHOD,

SCRIPT_FILENAME, PATH_INFO, QUERY_STRING, AUTH_TYPE, DOCUMENT_ROOT,

SERVER_ADMIN, SERVER_NAME, SERVER_ADDR, SERVER_PORT, SERVER_PROTOCOL,

SERVER_SOFTWARE, TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN,

TIME_SEC, TIME_WDAY, TIME, API_VERSION, THE_REQUEST, REQUEST_URI, REQUEST_

FILENAME, REQUEST_BASENAME, IS_SUBREQ

Figura 2. mod_evasive

42

seguridadProtección de servidor

Linux+ 1/2007 43

seguridadProtección de servidor

www.lpmagazine.org

LoadModule evasive_module

libexec/mod_evasive.so

AddModule mod_evasive.c

Señal inequívoca de que el módulo se ha instalado correctamente, es ahora cuando podemos empezar a añadir las directivas de configuración del módulo dos_evasive

Para empezar a escribir las directivas dentro del fichero de configuración del Apa-che debemos de hacer lo siguiente: edita-mos el httpd.conf, podemos elegir el editor que más nos guste en nuestro caso nano –f httpd.conf

La definición de la directiva del mod_evasive será la siguiente:

<IfModule mod_evasive.c>

DOSHashTableSize 3097

DOSPageCount 10

DOSSiteCount 50

DOSPageInterval 1

DOSSiteInterval 1

DOSBlockingPeriod 10

</IfModule>

DOSHashTableSizeEsta tabla define el máximo número de nodos a almacenar por proceso. Si incrementamos el número aumentará la velocidad de ejecución del proceso ya que reducirá el número de Iteraciones por registro, pero traerá como consecuencia un incremento de los recursos del servidor, lo que implica que consumirá más memoria del sistema. En el supuesto que tengamos un servidor Apache que tenga que atender mucho trafico es aconsejable incre-mentar dicha cantidad.

DOSPageCountEste valor es el número de solicitudes sobre la misma página o URI por intervalo, si di-chas solicitudes exceden al valor previamente definido, que para nuestro caso es de 10, la IP del cliente será sumada en nuestra Black-list.

DOSSiteCountEste valor es el número máximo de solicitu-des hechas sobre el mismo proceso por el mismo cliente, si dicho valor excede el valor previamente definido, que para nuestro caso es de 50, la IP del cliente será sumada en nuestra Blacklist.

DOSPageIntervalCon este valor definimos el intervalo de tiem-po por el cual el DOSPageCount debe de con-tar el número máximo de solicitudes sob-

re la misma página, por defecto ponemos 1 segundo.

DOSSiteIntervalCon este valor definimos el intervalo de tiem-po por el cual el DOSPageInterval debe de contar el máximo de solicitud hechas sobre el mismo proceso, por defecto ponemos 1 se-gundo.

DOSBlockingPeriodComo ya hemos mencionado anteriormente una vez que la IP de cualquiera de nuestros clientes cumple con las condiciones arriba in-dicadas, dicha IP se suma a nuestra Blacklist, trayendo como resultado una página de error y se le niega el acceso al servidor Apache, esa situación de permanencia en nuestra Blacklist no es definitiva y nosotros podemos definir durante cuanto tiempo dicha IP estará en nuestra Blacklist, en nuestro caso dicha situa-ción de negación de acceso será durante 10 segundos, una vez cumplido dicho período de tiempo la IP dejará de estar en nuestra Blacklist

Debemos recordar que el mod_evasise, es-cribe en el syslog cualquier incidencia o Ddosattack que ha tenido, en dicho fichero apare-cerá de la siguiente forma, ver abajo:

Active System Attack AlertsOct 24 11:07:35 host mod_evasive[15587]: Blacklisting address xx.xx.xx.xx: possible attack.

Reiniciamos el ApachePor último debemos hacer una mención del fichero de configuración del Apache, he aquí unos consejos que servirán para poder me-jorar el funcionamiento del servidor Apache y lo reforzarán contra ataques maliciosos a través de Internet.

HostNameLookups offNo activaremos la directriz, de esa forma elApache registrará la IP de acceso de cada cliente que acceda al servidor, si la activa-mos traerá como consecuencia un menor rendimiento del servidor.

MinSpareServers/MaxSpareSarvers Ambas directrices sirven para regular la can-tidad de procesos, es decir tratan de mantener el suficiente número de procesos de carga, pa-ra ello comprueban la cantidad de veces que un proceso se queda esperando una petición, si son menos que el valor especificado por la instrucción MinSpareServer crea una reserva, si es superior a MaxSpareServer eliminará los

procesos sobrantes, los valores que vienen por defecto son válidos y no conviene alterarlos.

KeepAliveTimeOut 15Este es el tiempo por el cual el servidor Apa-che esperará en atender la recepción de la si-guiente petición, una vez pasado este tiempo el proceso desaparece, si el servidor Apache recibe muchas peticiones es aconsejable redu-cir dicha cantidad.

AllowOverride NoneNo permitiremos que un usuario del sistema pueda cambiar o sobrescribir mediante los ficheros .htaccess con el propósito de alterar el funcionamiento del Apache.

Una vez llegado al final del articulo, hemos visto las formas de ataques que se producen a través de la red, o mejor dicho, a través de Internet, que van explícitamente a intentar atacar al servidor mediante solici-tudes POST, para el cual hemos dispuesto la instalación del modulo mod_security con la intención de poner un filtro a dichas solicitu-des y evitar en lo posible ataques a través de aplicaciones web que pueden producir un fa-llo de seguridad en el sistema, también dicho módulo nos da una idea de cual puede ser el usuario del sistema utilizado para producir el ataque. Junto con el módulo dos evasive que nos protege de los ataques de negación de servicio, también conocido como Ddos atacks, evitando que mediante un montón de solicitudes reiterativas sobre el servidor Apache atacado provoque la caída de éste. También hemos comentado la manera de mejorar los parámetros de configuración del Apache accediendo al fichero de configura-ción del mismo.

Después de este curso podríamos caer en la tentación de empezar a instalar cual-quier módulo para el servidor Apache que pueda hacer el mismo trabajo de protección, pero debemos de advertir que cuantos másmódulos sean instalados, menor será el redi-miendo del servidor, también puede abrir un fallo en la seguridad de su servidor dejando un hueco de seguridad el cual un cracker puede aprovechar y tener acceso al sistema. Lo que es más importante, y como de open source estamos hablando, es importante que dicho módulo tenga una comunidad que lo mantenga de tal forma que se actualice rápidamente en caso que aparezca un fallo de seguridad. Si dicha comunidad no existe no conviene pensar en instalarlo en nuestro servidor, porque podría resultar un peligro para nuestro sistema, sobre todo en un en-torno de producción.