Blog de Javi

El popular servidor web que desde sus inicios adoptó la filosofía Open Source llevaba años sin ser modificado en gran medida, pero ahora se han dado los primeros pasos para llegar a una futura versión Apache 2.4. Los desarrolladores del proyecto Apache han publicado la versión Apache 2.3.11, que es el primer paso de lo que será Apache 2.4, y que llega con mejoras interesantes, sobre todo en el área de la gestión de varias peticiones de forma simultánea.

Seis años después de lanzarse la versión 2.2 del servidor web Apache, los responsables del proyecto han publicado Apache 2.3.11, que se supone es el primer paso hacia una futura versión Apache 2.4.

Las nuevas características de esta versión preliminar afectan por ejemplo a la arquitectura MPM (Multi-Processing Module) que permite múltiples peticiones para ser procesadas de forma casi simultánea. Por primera vez los usuarios no necesitan elegir un MPM cuando compilan el servidor.

Como cualquier otro componente software, los MPM se generan como módulos dinámicos que pueden ser seleccionados al iniciar el servidor. Como indican en The H Open, mientras que antes estos componentes estaban clasificados como “experimentales”, ahora se han unido a la lista de módulos plenamente funcionales.

También nos hablan de la directiva LogLevel, que ahora se puede configurar para mantener distintos tipos de directorios y de módulos. Otro nuevo módulo integra el lenjuaje de scripting Lua para permitir a los desarrolladores implementar los llamados “request habdlers” en este lenguaje.

Además mod_ssl permite que se usen certificados para ser verificados online a través de OCSP. Como suele suceder con este tipo de versiones preliminares, los desarrolladores recomienzan su uso siempre fuera de entornos de producción.

Podéis encontrar más detalles sobre este lanzamiento en el anuncio oficial y en el registro de cambios, y además podéis descargar Apache 2.3.11 desde la página oficial.

De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Fuente: Bosque Viejo

Resumiendo mucho el funcionamiento de los VirtualHost en Apache, se puede decir que el cliente (nuestro navegador) envía al servidor el nombre del dominio al que deseamos acceder y Apache lo busca en sus configuraciones para entregarte la web. De esta forma en un solo servidor podemos tener alojados múltiples páginas web, cada una con su VirtualHost.

GET /blog/ HTTP/1.1
Host: javirodriguez.com.es
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.6) Gecko/2009020911 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Pero la cosa cambia si las webs deben ser transmitidas mediante HTTPS, esto es, estableciendo una conexión SSL. Gracias a esta tecnología es posible que todo el tráfico entre el servidor y nuestro navegador vaya cifrado y esta es la raíz del problema. Al tener todos los datos cifrados, el servidor no puede saber que dominio está pidiendo el navegador, por lo que los VirtualHost en base a nombres (dominios) pierden utilidad. Para paliar este problema, se ponían múltiples IPs en el servidor y se asignaba cada IP a un VirtualHost. De esta forma, cada web HTTPS tenia como destino una IP distinta y así el servidor era capaz de darte la web que estabas buscando. Esto es, se pasaba de tener VirtualHost por nombre a tenerlos por IP. Si tenías dos páginas web esto no era problema, pero si tenías 200… acelerarías la implantación de IPV6 y eso no es bueno 😉

Para solucionar este problema se publicó en 2006 el RFC 4366. En resumen, TLS pasaba a tener extensiones a nivel cliente y servidor. Una de las cuales permite que el cliente en el establecimiento de la conexión (antes de comenzar el cifrado) pueda indicar el dominio al que desea acceder. La que nos hace la magia es SNI. Para que esto funcione es necesario cumplir una serie de requisitos:

• OpenSSL 0.9.8f o posterior con extensiones TLS (enable-tlsext)
• Apache compilado con dicho OpenSSL
• Navegadores Mozilla Firefox 2.0, Opera 8.0 Internet Explorer 7.0, Google Chome, Safari 3.2.1

Para activar esta extensión añadimos la siguiente línea a httpd.conf:

SSLStrictSNIVHostCheck on

Una vez hecho configuraríamos nuestros VirtualHost SSL como si fuesen los de toda la vida (sin SSL).

Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
        ServerName test1.javirodriguez.com.es
        ServerAlias test1.javirodriguez.com.es
        DocumentRoot /var/www/test1
        Options FollowSymLinks
        <Directory /var/www/test1>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test1error.log
        CustomLog /var/log/apache2/test1access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>
<VirtualHost *:443>
        ServerName test2.javirodriguez.com.es
        ServerAlias test2.javirodriguez.com.es
        DocumentRoot /var/www/test2
        Options FollowSymLinks
        <Directory /var/www/test2>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test2error.log
        CustomLog /var/log/apache2/test2access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>

Si vemos el siguiente error en los logs de Apache es que nuestro navegador no es compatible:

[error] No hostname was provided via SNI for a name based virtual host

Y listo, ya puedes tener múltiples VirtualHost con SSL en una única IP 🙂

Fuente: Miguel Angel Nieto

En esta guia voy a explicar el proceso de instalar el soporte WebDAV para Apache 2.2.x en Gentoo.

Si ya tenemos Apache instalado, deberemos asegurarnos que tiene soporte para los modulos que necesitamos. Estos modulos son:

• dav
• dav_fs
• auth_digest
• authn_file
• setenvif

Si no estamos seguro si estan instalados o no, ejecutaremos el siguiente comando.

APACHE2_MODULES="dav dav_fs auth_digest authn_file setenvif" emerge -av apache

De esta manera compilaremos e instalaremos apache con soporte para WebDAV. Si quieres que en posteriores actualizaciones de Apache siempre se tenga el soporte, añade la siguiente linea en /etc/make.conf

APACHE2_MODULES="dav dav_fs auth_digest authn_file setenvif"

Una vez instalado Apache, deberemos decirle que cargue ciertos modulos. Para ello editamos el archivo /etc/conf.d/apache2 y en la linea de opciones de Apache (APACHE2_OPTS) añadimos los modulos quedando un estilo a lo siguiente:

APACHE2_OPTS="-D DEFAULT_VHOST -D DAV -D AUTH_DIGEST"

Una vez hecho esto, nos vamos a editar el archivo /etc/apache2/modules.d/45_mod_dav.conf para que quede un estilo a lo siguiente:

<IfDefine DAV>
<IfModule dav_module>
<IfModule dav_fs_module>
DavLockDB "/var/lib/dav/lockdb"

# The following example gives DAV write access to a directory called
# "uploads" under the ServerRoot directory.
<IfModule auth_digest_module>
<IfModule authn_file_module>

<Directory /var/www/localhost/htdocs/dav>
Dav On
Options none
AllowOverride None
Order allow,deny
Allow from all
<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
AuthType Digest
AuthName "DAV-upload"
AuthUserFile "/var/www/localhost/htdocs/dav/.htpasswd-dav"
Require valid-user
</Limit>
</Directory>

</IfModule>
</IfModule>

</IfModule>
</IfModule>

# The following directives disable redirects on non-GET requests for
# a directory that does not include the trailing slash.  This fixes a
# problem with several clients that do not appropriately handle
# redirects for folders with DAV methods.
<IfModule setenvif_module>
BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "MS FrontPage" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
BrowserMatch "^WebDAVFS/1.[012345678]" redirect-carefully
BrowserMatch "^gnome-vfs/1.0" redirect-carefully
BrowserMatch "^XML Spy" redirect-carefully
BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully
</IfModule>

</IfDefine>

Y por ultimo crear el archivo con usuarios y password utilizando htdigest2.

htdigest2 -c /var/www/localhost/htdocs/dav/.htpasswd-dav DAV-upload [user]

El -c se pone para crear el archivo, para añadir posteriormente mas usuarios no hay que ponerlo.

Cuando ya esta todo hecho, reiniciamos Apache y a funcionar.

Todos hemos tenido la preocupación de que nuestra web no sea segura y necesitamos una manera de comprobarlo. Todo lo que tenemos que hacer es editar nuestro archivo .htaccess e incluir estas lineas:

## Seguridad extra para PHP
php_flag safe_mode on
php_flag expose_php off
php_flag display_errors off

## Manejo de errores de Apache. Cuando se produzca uno de estos errores, redirigimos a una pagina especial desarrollada por nosotros.
ErrorDocument 401 /error401.html
ErrorDocument 403 /error403.html
ErrorDocument 404 /error404.html

RewriteEngine On

Options +FollowSymLinks
# Evitar escaneos y cualquier intento de manipulación malintencionada
# de la URL. Con esta regla es imposible lanzar ataques de inyección (SQL, XSS, etc)
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(-|\.|') [OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)(<|>|%3C|%3E)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)(libwww-perl|libwwwperl|snoopy|curl|wget|winhttp|python |nikto|scan|clshttp|archiver|loader|email|harvest|fetch|extract|grab|miner|suck|reaper|leach)(.*) [NC,OR]

RewriteCond %{REQUEST_URI} ^(/,|/;|/<|/>|/'|/`|/%2C|/%3C|/%3E|/%27|/////) [NC,OR]
RewriteCond %{HTTP_REFERER} ^(.*)(%00|%08|%09|%0A|%0B|%0C|%0D|%0E|%0F|%2C|<|>|'|%3C|%3E|%26%23 |%27|%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%00|%08|%09|%0A|%0B|%0C|%0D|%0E|%0F|%2C|%3C|%3E|%27|%26%23 |%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)('|-|<|>|,|/|\\|\.a|\.c|\.t|\.d|\.p|\.i|\.e|\.j)(.*) [NC,OR]
RewriteCond %{HTTP_COOKIE} ^(.*)(<|>|'|%3C|%3E|%27)(.*) [NC]

RewriteRule ^(.*)$ error.php [NC]
## No permitir acceso al .htaccess
order allow,deny
deny from all

## Evitar que se liste el contenido de los directorios
Options All -Indexes

## Lo mismo que lo anterior
IndexIgnore *

## Denegar el acceso a robots dañinos, browsers offline, etc
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^Anarchie [OR]
RewriteCond %{HTTP_USER_AGENT} ^ASPSeek [OR]
RewriteCond %{HTTP_USER_AGENT} ^attach [OR]
RewriteCond %{HTTP_USER_AGENT} ^autoemailspider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xenu [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus.*Webster [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
##redireccionar a los robots a otra web
RewriteRule ^.*$ http://www.otraweb.com [R,L]

# Protegerse contra los ataques DOS limitando el tamaño de subida de archivos
LimitRequestBody 10240000

Espero que les sirva de ayuda en sus proyectos. Saludos.

NOTA: Si os da problemas el copiar y pegar estas lineas del Blog, descarga el siguiente archivo: htaccess-antiddos.txt y renombralo despues en tu servidor a .htaccess