PDF de programación - Protección del servidor Apache

seguridad
Protección de servidor

Protección del
servidor Apache

Jose Ignacio Ruiz de Alegría
Cuando 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.

l

.

p
m
o
c
.
e
r
a
w

t
f

o
s
@
x
u
n

i
l

E l 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*

40

Linux+ 1/2007

seguridad
Protección de servidor

Figura 1. mod_security

Activamos el filtro:

Rango de Bytes:

SecFilterEngine On

SecFilterForceByteRange 0 255

Activamos el chequeo del url, Post:

SecFilterCheckURLEncoding On

Para evitar que interfiera con las aplicaciones
web:

SecFilterCheckUnicodeEncoding Off

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>.

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>

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

www.lpmagazine.org

41

seguridad
Protección de servidor

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

por un tiempo prudencial de unos 10 segun-
dos, dicha cantidad es configurable, y compa-
rar si dichas IPs se encuentran en la lista negra
o 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 en
la 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:

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.

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).

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

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

SecFilterDefaultAction
Esta 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.

SecFilterForceByteRange
Esta 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.

SecAuditLog
Suma 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].

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.

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

El significado es el de encadenar dos ins-

trucciones, véase el ejemplo de arriba.

tar –xzf mod_evasive

Reiniciamos el Apache
Una 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