Blog
Para que funcionen correctamente los ejemplos de configuración mostrados en esta sección, debes tener el módulo mod_rewrite instalado y activado en el servidor.
Esta configuración funciona solamente para las URL no seguras que empiezan por http://:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^ejemplo\.com [NC]
RewriteRule ^(.*)$ http://www.ejemplo.com/$1 [L,R=301,NC]
Esta configuración funciona tanto para las URL seguras (https://) como para las URL normales (http://):
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Esta configuración funciona solamente para las URL no seguras que empiezan por http://:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.ejemplo\.com [NC]
RewriteRule ^(.*)$ http://ejemplo.com/$1 [L,R=301]
RewriteEngine on
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{REQUEST_URI} /+[^\.]+$
RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
Redirect 301 /pagina_antigua.html http://www.ejemplo.com/nueva_pagina.html Redirect 301 /pagina_antigua_2.html http://www.ejemplo.com/directorio/
Redirect 301 / http://nuevo_sitio.com/
A pesar de que esta configuración sencilla no lo parezca, en realidad se están redirigiendo todos los enlaces viejos al nuevo sitio, no solo la portada del sitio.
La siguiente configuración impide, sin excepción, todas las conexiones a tu sitio web, por lo que es una forma rápida de "apagarlo" y hacerlo desaparecer de Internet:
Deny from All # en Apache 2.4, utiliza lo siguiente # Require all denied
Order deny, allow Deny from All Allow from xxx.xxx.xxx.xxx # en Apache 2.4, utiliza lo siguiente # Require ip xxx.xxx.xxx.xxx
Sustituye xxx.xxx.xxx.xxx por la dirección IP desde la que quieres permitir el acceso al sitio. Esta configuración también soporta la definición de rangos de direcciones IP.
La siguiente configuración es la contraria de la configuración mostrada anteriormente, ya que permite el acceso desde cualquier dirección IP salvo las indicadas explícitamente:
Order deny, allow Allow from All Deny from xxx.xxx.xxx.xxx Deny from xxx.xxx.xxx.yyy # en Apache 2.4, utiliza lo siguiente # Require not ip xxx.xxx.xxx.xxx # Require not ip xxx.xxx.xxx.yyy
Los archivos y directorios ocultos (es decir, aquellos cuyo nombre empieza con un punto) normalmente no son públicos, por lo que el servidor web no debería servirlos:
RewriteCond %{SCRIPT_FILENAME} -d [OR]
RewriteCond %{SCRIPT_FILENAME} -f
RewriteRule "(^|/)\." - [F]
Entre otros, esta configuración protege archivos como .htaccess y .htpasswd y directorios como .git y .hg.
Si lo prefieres, también puedes devolver un error de tipo 404 (Not Found) para confundir un poco más a los atacantes:
RedirectMatch 404 /\..*$
Las siguientes extensiones corresponden a los archivos que pueden contener información sensible, como por ejemplo: archivos de log con información detallada del servidor (.log), copias de seguridad creadas por editores como Vi/Vim (.swp), comandos de consola (.sh), archivos de configuración (.config, .ini), etc.
Order allow,deny
Deny from all
Satisfy All
Options All -Indexes
La siguiente configuración impide que cualquier sitio web externo pueda enlazar a tus imágenes para "robártelas". Cambia el valor ejemplo.com por tu propio dominio, de manera que solamente tú puedas enlazar a tus imágenes:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ejemplo.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]
Primero debes crear un archivo llamado .htpasswd con el comando htpasswd. Este archivo se debe guardar en cualquier directorio que no sea directamente accesible mediante el servidor web:
$ htpasswd -c /home/usuario/.htpasswd nombre_usuario
Y ahora ya puedes usar este archivo para proteger con contraseña el acceso a cualquier directorio:
AuthType Basic AuthName "Zona Segura" AuthUserFile /home/usuario/.htpasswd Require valid-user
AuthName "Zona Segura" AuthType Basic AuthUserFile /home/usuario/.htpasswd Require valid-user Require valid-user
# Forzar compresión también para las cabeceras malformadas
# http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
# Comprimir los contenidos que sean de cualquiera de estos tipos
AddOutputFilterByType DEFLATE application/atom+xml \
application/javascript \
application/json \
application/rss+xml \
application/vnd.ms-fontobject \
application/x-font-ttf \
application/x-web-app-manifest+json \
application/xhtml+xml \
application/xml \
font/opentype \
image/svg+xml \
image/x-icon \
text/css \
text/html \
text/plain \
text/x-component \
text/xml
La cabecera Expires de HTTP indica al navegador la fecha a partir de la cual un recurso se considera "no válido" y debe volver a solicitarse al servidor en vez de servirse directamente desde la caché.
La recomendación para muchos de los archivos estáticos (CSS, JavaScript, imágenes, etc.) consiste en establecer una fecha de expiración muy lejana (1 año por ejemplo). No obstante, si los nombres de los archivos no incluyen información sobre su versión, entonces es mejor que la expiración no sea tan lejana (1 semana por ejemplo). Utiliza la siguiente configuración para indicar la fecha de expiración de todos los archivos estáticos habituales de las aplicaciones web:
ExpiresActive on
ExpiresDefault "access plus 1 month"
# CSS
ExpiresByType text/css "access plus 1 year"
# Archivos relacionados con AJAX y Web Sockets
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType text/xml "access plus 0 seconds"
# Favicon
ExpiresByType image/x-icon "access plus 1 week"
# Componentes HTML (HTCs)
ExpiresByType text/x-component "access plus 1 month"
# HTML
ExpiresByType text/html "access plus 0 seconds"
# JavaScript
ExpiresByType application/javascript "access plus 1 year"
# Manifest
ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds"
ExpiresByType text/cache-manifest "access plus 0 seconds"
# Fotos, vídeos y audio
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
# Canales RSS y Atom
ExpiresByType application/atom+xml "access plus 1 hour"
ExpiresByType application/rss+xml "access plus 1 hour"
# Fuentes web
ExpiresByType application/font-woff "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
Eliminar la cabecera ETag de HTTP puede ser útil en algunas situaciones, ya que impide a los proxys y a los navegadores cachear los contenidos en función de esta cabecera. En la práctica, esto fuerza a que los proxys y navegadores utilicen en su lugar las cabeceras Cache-Control o Expires:
Header unset ETag
FileETag None
Deje aquí su comentario acerca de este artículo...