guebmaster.com

Todo sitio web necesita de algún fichero o scripts donde se guardan datos sensibles que el servidor necesita para restringir el acceso a usuarios no autentificados, conectarse a una base de datos, etc.

Existen multitud de situaciones donde uno se pregunta (o al menos debería) cual será el sitio más seguro para guardar ese script o archivo de configuración necesario para que nuestro sitio web o software funcione correctamente.

Estos archivos de configuración suelen contener los datos necesarios para que un programa se pueda conectar a una base de datos, restringir el acceso a un directorio protegido por htaccess, verificar la autenticidad de un usuario que pretenda acceder a sistema de administración de un sitio web, etc. Por lo tanto, los archivos de configuración son necesarios y en alguna parte debemos colocarlos.

La mejor opción es situar esos archivos en un directorio al cual no se pueda tener acceso desde internet, por lo que solo se puede tener acceso a ellos desde un script situado en el mismo servidor. Supongamos que la estructura de directorios de tu sitio web es el siguiente:

/home/tudominio
/home/tudominio/mail
/home/tudominio/stats
/home/tudominio/www

El directorio “/home/tudominio” es tu directorio personal, mientras que “home/tudominio/www” es el directorio público, al cual se puede acceder desde internet. Tus archivos de configuración deberían estar fuera de este directorio público, por lo tanto, podrías crear “/home/tudominio/config” y guardar allí todos tus ficheros de configuración.

Estos archivos de configuración solo serán accesibles desde scripts situado en tu servidor ya que al estar fuera del directorio público, la única forma de incluirlos en un script es usando la estructura de directorios.

<?php
include('/home/tudominio/config/conexion.conf');
?>

Manteniendo, los archivos de configuración fuera del directorio público, nadie puede usarlos en un script situado en un ordenador remoto. Supongamos, que tu archivo de configuración estuviera en el directorio “/home/tudominio/www/conexion.conf”, cualquiera podría acceder a sus datos de la siguiente forma:

<?php
include('http://tudominio.com/conexion.conf');
?>

¿Que pasa con los usuarios locales?

Reubicando estos archivos en el directorio “/home/tudominio/config” evitamos que se pueda acceder a ellos desde Internet, pero el resto de usuarios que posiblemente compartan tu mismo servidor si que pueden acceder a ellos.

Para evitarlo debes asegurarte de configurar correctamente los permisos de estos archivos y del directorio “/home/tudominio/config”. La forma correcta de hacerlo varia de servidor a servidor, pero en general, la siguiente configuración resultará correcta:

$ chmod 751 /home/tudominio/config
$ chmod 644 /home/tudominio/config/*

En realidad, con los permisos sugeridos no impedimos que los usuarios locales accedan a tus archivos, pero se lo ponemos un poco más difícil. Y obviamente existen métodos muchos más seguros y efectivos pero su explicación no es objeto de este artículo.

Lo mismas medidas preventivas son aplicables a los archivos .htpasswd, las imagenes (puedes evitar el Hotlink), etc. Siempre es preferible colocar los archivos sensibles fuera del directorio público.

Los Server Side Includes, o simplemente SSI, nos proporcionan una sencilla forma de automatizar ciertos aspectos de la creación y posterior mantenimiento de nuestro sitio web, y sin necesidad de saber programar en Perl o PHP.

Los SSI (Server Side Includes) son directivas insertadas en páginas HTML que nos permiten inserción de contenido generado dinámicamente en nuestras páginas web. Como PHP pero mucho más fácil.

Para que los SSI funcionen, las páginas HTML que las incluyen deben ser evaluadas por Apache antes de mostrar su contenido al navegador cliente. Por este motivo, servir páginas que hacen uso de SSI consume más recursos del sistema que el servir páginas HTML normales.

El uso de SSI consume más recursos del sistema su utilización supone una carga adicional del servidor. Aunque esto es inevitable y lo mismo ocurre con los scripts en PHP o CGI, es una cuestión de comodidad contra eficiencia. Obviamente, no debemos hacer que Apache evalúe todas las páginas HTML antes de devolverlas al cliente, ya que seguramente en muchas de ellas no habrá directivas SSI y estaremos sobrecargando el sistema inútilmente. Por lo tanto, debemos diferenciar las páginas HTML y las que incluyen instrucciones SSI, para ello nada mejor que la solución estándar, la de usar la extensión "shtml" con las páginas que deben ser evaluadas.

Configurar Apache para que permita SSI

Para permitir el uso de SSI en todo tu servidor o en un directorio concreto debes tener la directiva "Options All" o "Options +Includes" en el fichero de configuración de Apache, httpd.conf, o en un archivo htaccess. Debes tener algo así:

<directory "c:/home">
Options +Includes
Order allow,deny
Allow from all
</directory>

Además, como queremos que Apache únicamente evalúe los archivos que tengan extensión "shtml", esto también tendremos que indicarlo en httpd.conf o en el archivo htaccess que usemos. Para ello, en caso de usar la versión 2.0 de Apache, debes incluir las siguientes líneas:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

En cambio, si utilizas la versión 1.3 de Apache, la configuración se hace con esto:

AddType text/html .shtml
AddHandler server-parsed .shtml

Pero que ocurre cuando queremos usar SSI en una página web, pagina.html, que previamente no las usaba y que por lo tanto su extensión no es "shtml"? Tenemos dos opciones:

• Renombrar pagina.html por pagina.shtml y cambiar todos lo enlaces a pagina.html por pagina.shtml.
• Usar la directiva XBitHack de Apache. Esta directiva nos proporciona una forma de indicarle a Apache de uno en uno las páginas sin extensión "shtml" que queramos que evalúe. Para activar XBitHack incluye la siguiente línea en la configuración:

  XBitHack on

  Para indicar a Apache que evalúe una página concreta, simplemente tenemos que dar permisos de ejecución a este fichero:

  $ chmod +x pagina.html

Uso de SSI

echo permite imprimir ciertos datos como por ejemplo la fecha local, fecha GMT, fecha de la ultima modificación del fichero, variables definidas previamente, variables de entorno como DOCUMENT_URI, REMOTE_ADDR, SERVER_NAME, SERVER_PORT, etc.

La siguiente directiva imprime la fecha y hora GMT:

< !###echo var="DATE_GMT"##>

La siguiente directiva muestra la fecha y hora local:

< !###echo var="DATE_LOCAL"##>

La siguiente directiva muestra la fecha y hora de la última actualización del fichero:

< !###echo var="LAST_MODIFIED" ##>

La siguiente directiva muestra el valor de la variable NOMBRE, la cual como se puede observar ha sido definida previamente:

< !###set var="NOMBRE" value="Juan García" ##>
< !###echo var="NOMBRE" ##>

La siguiente directiva muestra el número IP del cliente:

< !###echo var="REMOTE_ADDR" ##>

include permite la inserción del contenido de otro fichero en el fichero actual. Resulta muy práctico para incluir una cabecera común en todos nuestros documentos:

< !###include virtual="cabecera.html" ##>

exec permite la ejecución de un programa externo desde el documento actual. Podemos ejecutar un programa ejecutable pasándole comandos de la siguiente forma:
< !###exec cmd="mkdir -m 0755 /home/tudominio/directorio_nuevo" ##>

Aunque también podemos ejecutar un script CGI:
< !###exec cgi="script.cgi" ##>

Debemos comentar que esta última directiva, exec, suele estar deshabilitada en la mayoría de los entornos de hosting virtual, por lo que sino funciona… posiblemente esta sea la causa.

config permite configurar la forma en la que se muestran ciertos tipos de datos.

La siguiente directiva configura el mensaje de error por defecto:

< !###config errmsg="Ha ocurrido un error" ##>

La siguiente directiva configura el formato en el que se muestras las fechas:

< !###config timefmt="%A %B %d, %Y" ##>
Hoy es < !###echo var="DATE_LOCAL" ##>

En ciertas ocasiones nos puede interesar impedir que los robots de los buscadores indexen ciertos directorios o documentos de nuestro web, para ello se usan los archivos "robots.txt".

En ciertas ocasiones nos puede interesar impedir que los robots de los buscadores indexen ciertos directorios o documentos de nuestro web, para ello se usan los archivos "robots.txt".

El archivo robots.txt no es más que archivo de texto que contiene una lista de instrucciones escritas en un formato estandarizado y que están dirigidas a todos o a ciertos robots en concreto. La función de estas instrucciones es la de prohibir que ciertos documentos o directorios que no queramos compartir sean indexados por los spiders.

El fichero robots.txt es lo primero que los crawlers buscan cuando acceden a un sitio web, posteriormente pasan a indexar el resto de nuestra web. El fichero robots.txt debe esta situado en el directorio raíz de nuestro sitio web, es decir, deberíamos poder acceder a el desde la dirección tudominio.com/robots.txt.

El motivo por el cual robots.txt debe esta colocado en nuestro directorio raíz es por es simple hecho de que los spiders solo lo buscan allí. Si lo encuentran, lo leerán y supuestamente acataran las instrucciones allí indicadas. Pero si no lo encuentran, darán por hecho que pueden indexar todos los documentos que estimen oportuno.

Puede ocurrir que un spider encuentre nuestro fichero robots.txt y que aunque supuestamente debería de acatar las ordenes que allí se le indican, este haga caso omiso de los mismo y termine indexando los documentos que queríamos prohibirle. Pero esto es algo que no tiene solución clara, al fin y al cabo quien va a obligar a los desarrolladores del spider a que este acate las ordenes de los archivos robots.txt?

La estructura de un archivo robots.txt es realmente simple, todas sus instrucciones son de tipo

<Campo> : <Valor>

donde <Campo> únicamente puede ser "User-agent" o "Disallow", mientras que <Value> solo puede ser el nombre de un robot o el path relativo al directorio o documento cuya indexación queremos prohibir.

Con un ejemplo todo se ve más claro:

User-agent: *
Disallow: /docs_privados/fotos/
Disallow: /docs_privados/textos/
Disallow: /docs_privados/doc_secreto.txt
User-agent: Googlebot/2.1
User-agent: InfoNaviRobot(F107)
User-agent: TV33_Mercator_1-1.0
User-agent: AVSearch-3.0
User-agent: Scooter/2.0
User-agent: Slurp/2.0
User-agent: SearchengineLicenceSheep_v1.0
User-agent: shadow/2.0
User-agent: MultiText/0.1
User-agent: FAST-WebCrawler/2.2.5
User-agent: Atomz/1.0
User-agent: htdig/ (searchit@netmind.com)
User-agent: spider00.logika.net.
Disallow: /documento.html

Como puedes observar el ejemplo esta dividido en dos partes. La primera esta dirigida a todos los robots, así lo indica la primera instrucción User-agent: *, donde el carácter "*" equivale a "cualquier" o "todos" los spiders. La segunda parte, esta dirigida a unos robots concretos definios mediante múltiples instrucciones que asignan un robot concreto a "User-agent".

En ambas partes, tras indicar los robots a los cuales esta dirigido, se especifica mediante "Disallow" los directorios y documentos que no deberían ser indexados por los robots. Hay que tener en cuenta que para prohibir la indexación de todos los documentos de un directorio, el path que se asigna a "Disallow" debe incluir el carácter "/" al final del nombre del directorio. Es decir, debe tener el formato Disallow: /directorio/ en vez de Disallow: /directorio.

El archivo robots.txt solo sirve para intentar prohibir la indexación de ciertos documentos y directorios, no es valido para configurar otros aspectos del funcionamiento de los spiders. Pero para esto existen los meta-tags de tipo "Robot", los cuales incluidos en un documento HTML sirven para comunicar al robot la asiduidad con la que debiera indexar el documento. Pero esto es ya otra historia…