Esta es la segunda parte de mi sitio web seguro. La primera parte fue más bien para principiantes, ya que es más básica y específica. Esta parte está más avanzada, con detalles y explicaciones.

Servidores

La mayoría de los servidores web en el mundo se ejecutan en el sistema operativo Linux. La razón es que este sistema es seguro y fácil de mantener para los administradores de IT. La mayor parte de los exploits que he encontrado no es en Linux, sino en las capas superiores de la plataforma del servidor. Si su proveedor de alojamiento cuida y mantiene todas las capas del servidor - Apache, MySQL y PHP (ver la imagen de demostración), y las actualiza según sea necesario, la mayoría de los riesgos de seguridad que puedan ocurrir, van a pertenecer a la capa de aplicación, Joomla en este caso, por lo que aquí es donde se tendrá que ser más cuidadoso.

Los permisos de archivos

Una de las primeras cosas que debes buscar, si se va de un entorno de desarrollo a uno de producción, son los permisos de archivos. En una instalación de Joomla no necesitará hacer esto. Para cada archivo y directorio en Linux hay tres banderas - lectura (r), escritura (w) y ejecución (x). Además, hay tres grupos afines - usuario (U), grupo (g) y otros (s). Cada grupo contiene las 3 banderas. Cada archivo tiene permisos que se pueden convertir en números, pero no voy a entrar en detalles sobre las banderas, los grupos y números. Estoy seguro de que googleando, encontrará una documentación más detallada. Lo que es importante en esas banderas es la de "escritura" de otro grupo, que permiten a los usuarios agregar archivos al sistema de archivos. Un ejemplo de cómo agregar archivos al sistema de archivos es la adición de imágenes y otros archivos al contenido. Joomla tiene unos cuantos directorios que necesitan permisos de escritura para los archivos, incluyendo el directorio de caché (se utiliza para almacenar en caché páginas), y el directorio tmp (utilizado para los archivos temporales asignados durante la instalación de extensión, por ejemplo). Por lo tanto, debemos permitir que esos directorios se puedan escribir, pero sólo aquellos directorios. Todos los directorios y archivos no deben tener permisos de escritura.

El permiso para los Archivos se debe establecer en 644 (es decir, sólo el grupo "usuario" tiene permiso de escritura y no el "grupo", ni los "otros"):

find /home/xxx/domains/xxxxxxx.com/public -type f -exec chmod 644 {} \; 

Los Directorios requieren un permiso de 755 (es decir, sólo el grupo "usuario" hará escritura y ejecución, no el "grupo" o los "otros"):

find /home/xxx/domains/xxxxxxx.com/public -type d -exec chmod 755 {} \;

Algunas notas adicionales:

• Si tienes curiosidad sobre cómo utilizar números, en vez de los distintos tipos de niveles (Permisos, Acceso...), entonces te recomiendo leer esta guía.
• El comando se puede ejecutar a través de ftp, ssh o una interfaz de cPanel.
• Tenga en cuenta que el directorio /home/xxx/domains/xxxxxxx.com/public se reemplaza con la ruta de la instalación de Joomla en su servidor.

Hacer los directorios escribibles

Como he mencionado antes, a veces necesitamos que algunos directorios tengan permisos de escritura. Los directorios que recomiendo que tengan permisos de lectura y escritura son: cache, tmp, imágenes y sus subdirectorios. Puede hacerlo con el siguiente comando:

cd /home/xxxxxx/domains/xxxxxxx.com/public_html && chmod -R o+w images cache tmp

Ahora, ¿qué pasa si alguien se apropia de su sitio Joomla y carga un archivo de script? Se puede instalar un script que puede hacer cualquier cosa en el servidor incluso destruir nuestro sitio web. Por supuesto, Joomla, por defecto, bloquea los scripts, pero ¿y si alguna extensión no los bloquea?

La respuesta se divide en dos opciones. En primer lugar, si no tienes que cargar las imágenes de los contenidos, no utilizas la caché o no instalas alguna extensión (no hacer ningún directorio escribible).

En caso de que tenga algunas de las características que he mencionado, o cualquier otra característica que requiere tener directorios escribibles, debe desactivar la capacidad de ejecutar scripts para estos directorios. Para ello, es necesario utilizar el siguiente truco - añadir un .htaccess (empezar con el punto) para cada directorio, y debe contener las siguientes líneas:

# secure directory by disabling script execution
Options -ExecCGI
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi

Una directiva htaccess precede a cualquier actividad Joomla porque el archivo se deriva de Apache, llamando a htaccess antes de PHP.

Base de Datos MySQL

La recomendación es evitar el uso del prefijo por defecto jos_ para tablas MySQL. En la versión 2.5 el prefijo es aleatorio . Si ya ha instalado Joomla con este prefijo, sólo tiene que utilizar algún script o una guía para convertir el prefijo de las tablas a otro, y no se olvide de actualizar su configuración inmediatamente.

Además, es recomendable que el usuario que ejecuta el servicio MySQL sólo utilice los siguientes permisos específicos (SELECT, UPDATE, DELETE, INSERT, CREATE). En cualquier caso - NO USE el usuario root de MySQL. Esto es muy peligroso.

Avanzado: PHP

Las siguientes opciones son para usuarios avanzados con acceso al archivo de configuración de PHP llamado php.ini. Si no está familiarizado con esto, déjeselo a su proveedor de alojamiento.

El bloqueo de la función de riesgo

PHP es el lenguaje de programación más común para aplicaciones basadas en web. Es fácil empezar a desarrollar con PHP, que es una de sus grandes ventajas, pero puede ser arriesgado. Hay algunas funciones que pueden dar acceso a lugares que no son convenientes. Puedes bloquear las funciones peligrosas con el argumento disable_functions:

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, eval

Estas funciones permiten a los usuarios ejecutar funciones en el servidor como el envío de datos, ejecutar comandos desde el servidor, recibiendo información sobre el servidor, etc, pero ten cuidado. Son útiles en un entorno de desarrollo, pero en producción no se recomiendan en absoluto.

Directivas de acceso PHP

PHP puede acceder a cualquier lugar en el servidor web, a menos que se configure de otra forma. Esto es peligroso, porque si un hacker obtiene acceso al servidor puede obtener acceso a cualquier lugar. Para reducir este riesgo, vamos a definir en lo que PHP puede acceder:

open_basedir =/home/xxxxxx/domains/xxxxxxx.com/:/tmp

El directorio tmp debe ser accesible (esto no es el directorio tmp Joomla), ya que los archivos PHP se realizan en primer lugar en este directorio, antes de pasar a Joomla.

Avanzado: htaccess

Como se mencionó antes, el archivo htaccess puede filtrar los datos antes de entrar en la aplicación Joomla, y salva el uso del servidor. Todo esto es bueno, y a lo mejor te preguntas por qué esta sección es para usuarios avanzados, si se trata de configurar y olvidar. La respuesta es que htaccess puede filtrar información requerida de los requerimientos necesarios y, en ocasiones, principiantes con poca experiencia jugando con el archivo rompe la configuración. En el peor de los casos puede eliminar directivas de reescritura en Joomla, y luego el htaccess estará corrupto y las operaciones básicas de Joomla dejarán de funcionar (como enlaces SEF).

Mi recomendación es añadir una sección específica en el archivo htaccess para cada nueva directiva, y realizar un seguimiento de las directrices que ha añadido. Guarde el original como un archivo htaccess.txt para que puedas volver a una versión de trabajo en caso de que le resulte algo mal.

Puedes encontrar archivos detallados htaccess en la wiki de Joomla y utilizar las secciones específicas de allí.

El bloqueo de acceso directo al core de Joomla

Todas las solicitudes de aplicación de Joomla pasan por un lugar - index.php . Cualquier otro acceso directo puede considerarse como un intento de piratería. Ninguna extensión (la mayoría) utilizan el acceso directo a cualquier archivo, excepto al index.php, pasando por la plataforma Joomla que pasa a través de esta puerta. Por lo tanto, se puede bloquear el acceso directo a la mayoría de los archivos (INI, XML y PHP), añadiendo la siguiente sección en el archivo htaccess:

#### @RS
# Deny access to php, xml and ini files
# within components and plugins directories
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_URI} \.php|\.ini|\.xml [NC]
RewriteCond %{REQUEST_URI} \/components\/ [OR]
RewriteCond %{REQUEST_URI} ^\/includes\/|^\/administrator\/includes\/ [OR]
RewriteCond %{REQUEST_URI} \/language\/ [OR]
RewriteCond %{REQUEST_URI} \/libraries\/ [OR]
RewriteCond %{REQUEST_URI} \/modules\/ [OR]
RewriteCond %{REQUEST_URI} \/plugins\/ [OR]
RewriteCond %{REQUEST_URI} \/templates\/ [OR]
RewriteCond %{REQUEST_URI} \/xmlrpc\/
RewriteRule ^(.*)$ index.php [R=404,L]
#### @RS

El @RS marca el comienzo y el final de la sección.

El bloqueo de inyección SQL

Una inyección SQL no funciona en Joomla porque la mayoría de los desarrolladores de Joomla utilizar las funciones básicas de SQL. Pero, de nuevo, hay pocos desarrolladores de extensiones perezosos que no lo hacen. Por lo tanto, puede bloquear los intentos con la siguiente sección:

#### @RS
# Prevent most common SQL-Injections
RewriteCond %{query_string} concat.*\( [NC,OR]
RewriteCond %{query_string} union.*select.*\( [NC,OR]
RewriteCond %{query_string} union.*all.*select [NC]
RewriteRule ^(.*)$ index.php [F,L]
#### @RS

Bloqueo de herramientas hijack

Cualquier persona que visita su sitio web se llama un agente de usuario. Para los visitantes regulares, incluye la identificación de su navegador (Firefox, Explorer, Chrome). Para los robots de los buscadores hay una identificación especial, y para las herramientas hijack hay identificaciones únicas. Por lo tanto, se pueden bloquear también:

#### @RS
# Block most common hacking tools
SetEnvIf user-agent "Indy Library" stayout=1
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Wget" stayout=1
deny from env=stayout
#### @RS

Avanzado: Cambiar de lugar el archivo configuration.php

Desde la versión 1.6, puede cambiar la ubicación del archivo de configuración principal: configuration.php. Hay varias razones para realizar este cambio. En primer lugar, muchos de los hackers saben que se está ejecutando Joomla y tratan de hackear este archivo conocido. Además, el archivo reside en el mismo lugar (es estático), y se puede acceder desde la web porque está en la carpeta pública. El riesgo fue creado por la gente que hace que pueda escribir el archivo con el fin de ser capaz de actualizar la configuración global en el panel de administración.

La pregunta que debe plantearse es ¿cómo podemos cambiar la ubicación del archivo, de preferencia fuera de la carpeta pública, y aún así dejar Joomla continuar trabajando correctamente?

Puedes anular la ubicación por defecto del archivo de configuración, pero no sólo la ruta de configuración, puedes cambiar las múltiples rutas. En esta guía vamos a cambiar sólo la configuración (primero: copia de seguridad):

1. Copie el archivo public_html/includes/defines.php a public_html y public_html/administrator/includes/defines.php a public_html/administrator/defines.php.
2. En cada defines.php nuevo, en public_html y public_html/administrator le añadimos las siguientes dos líneas:

define('_JDEFINES', 1);
define('JPATH_BASE', dirname(__FILE__));

Debajo de:

defined('_JEXEC') or die;

3. El siguiente paso sería la actualización de la ubicación predeterminada de la configuración en los archivos nuevos. Por ejemplo vamos a poner la configuración fuera del alcance public_html (un nivel por encima de ella). Para ello vamos a cambiar la siguiente línea en:

define('JPATH_CONFIGURATION', JPATH_ROOT);

a

define('JPATH_CONFIGURATION', JPATH_ROOT .DS.'..');

4. Una vez más, realizar este cambio en ambos archivos defines.php.
5. No te olvides de mover el archivo configuration.php a la nueva ubicación.

Conclusiones

Espero que hayas aprendido más sobre la seguridad en esta segunda guía, que estaba destinada a ser más avanzada.

Tenga en cuenta que la seguridad es un proceso continuo y siempre hay que tener cuidado de mantenerla tan seguro como si fuera su hogar o negocio.

Artículo Original: Simple Security Guide, Part 2 por Ofer Cohen
Traducido por: Carlos Rodríguez
Miembro del: Equipo de Marketing y Difusión de Joomla! en Español