Limpiar greylist blackdomains de plesk

Por defecto Plesk instala un servicio de greylisting con algunas reglas que pueden ser muy restristivas.
Para ver el estado de la lista gris :

~# /usr/local/psa/bin/grey_listing --info-server
Grey listing configuration.

Grey listing checking  enabled
Grey interval          5 minutes
Expire interval        51840 minutes
Penalty interval       2 minutes
Penalty                disabled
Personal grey listing
configuration          allowed

Server-wide black list:

Server-wide white list:

White domains patterns list:
*google.com
*mail.ru
*parallels.com
*rambler.ru
*yahoo.com
*yandex.ru

Black domains patterns list:
*[0-9][0-9]-[0-9][0-9]-[0-9][0-9]*
*[0-9][0-9].[0-9][0-9].[0-9][0-9]*
*[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]*
*[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9[0-9]][0-9]*

SUCCESS: Gathering of server wide information complete.

Para eliminarlas puedes copiar y pegar estas lineas:

/usr/local/psa/bin/grey_listing --update-server -domains-blacklist del:'dsl|pool|broadband|hsd'
/usr/local/psa/bin/grey_listing --update-server -domains-blacklist del:'dynamic|static|ppp|dyn-ip|dial-up'
/usr/local/psa/bin/grey_listing --update-server -domains-blacklist del:'*[0-9][0-9]-[0-9][0-9]-[0-9][0-9]*'
/usr/local/psa/bin/grey_listing --update-server -domains-blacklist del:'*[0-9][0-9].[0-9][0-9].[0-9][0-9]*'
/usr/local/psa/bin/grey_listing --update-server -domains-blacklist del:'*[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]*'
/usr/local/psa/bin/grey_listing --update-server -domains-blacklist del:'*[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9[0-9]][0-9]*'

Fallo grave de seguridad en Plesk mod_php

Nos llega información acerda de una fallo de seguridad en Plesk:

«SECURITY ADVISORY:
Parallels Plesk Panel 9.x, 10.x, 11.x – Privilege Escalation Vulnerability

Parallels Customer,

Please read this message in its entirety and take the recommended actions.

Situation

Parallels Plesk Panel privilege escalation vulnerabilities have been
discovered and are described in VU#310500 and CVE-2013-0132,
CVE-2013-0133 (CVSS score 4.4 –
http://www.kb.cert.org/vuls/id/310500).

Impact

This impacts Parallels Plesk Panel for Linux versions 9.x, 10.x, 11.x.

You are at risk if you have Apache web server running mod_php,
mod_perl, mod_python, etc.

You are NOT at risk if you have Apache web server running Fast CGI
(PHP, perl, python, etc.) or CGI (PHP, perl, python, etc.).

Solution

Parallels has issued security updates for Parallels Plesk Panel
versions 9.x-11.x. The security updates for Parallels Plesk Panel 11.x
and Parallels Plesk Panel 10.4.4 will automatically appear inside your
Parallels Plesk Panel control panel – please apply them as soon as
possible.

The security hotfix for Parallels Plesk 9.x is available for download
here: http://kb.parallels.com/115942.

Workaround

Parallels understands that it’s not always practical for immediate
upgrades, so we have provided a solution to fix this vulnerability.
For the immediate solution, customers should read this knowledge base
article for instructions: http://kb.parallels.com/115942.»

Recordamos que para instalar los microupdates de plesk se pueden ejecutar estos comandos :

/usr/local/psa/admin/sbin/autoinstaller --select-release-current --install-component base
/usr/local/psa/admin/sbin/autoinstaller --select-release-current --upgrade-installed-components

Quitar notificaciones de updates de drweb

En el fichero /etc/cron.daily/drweb-update
se ejecuta /opt/drweb/update.pl

y nos llega un mail diario con este log

/etc/cron.daily/drweb-update:
Dr.Web (R) update details:
Update server: http://update.msk6.drweb.com/unix/500
Update has begun at Fri Mar 22 10:22:49 2013
Update has finished at Fri Mar 22 10:24:12 2013

Following files has been updated:
        /var/drweb/bases/drwdaily.vdb
        /var/drweb/bases/drwtoday.vdb
        /var/drweb/bases/dwntoday.vdb
        /var/drweb/bases/dwrtoday.vdb
        /var/drweb/updates/timestamp

Para evitar que nos llegue, editamos el fichero /etc/drweb/drweb32.ini y cambiamos el CronSummary que por defecto está a yes por no

CronSummary = no

VPS Plesk no ejecuta cron.daily

En un par de máquinas VPS Plesk 10.4.4 que tenemos con Axarnet no funciona cron correctamente. El caso es que todo parece estar correcto, los ficheros del cron, permsisos, los logs no reflejan nada…

Nos pusimos a revisar ficheros y llegamos a este punto /etc/crontab. En crontab se definen las horas a las que se ejecutan los cron de hourly, daily, weekly y monthly.

En debian/ubuntu la forma de ejecutar estos cron es esta :

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Con lo que si queremos testear la ejecución directamente vemos que si /usr/bin/anacron se puede ejecutar no se hace nada. Si vemos los permisos, comprobamos que sí es ejecutable :

 stat /usr/sbin/anacron
  File: `/usr/sbin/anacron'
  Size: 29632     	Blocks: 64         IO Block: 4096   regular file
Device: 92adh/37549d	Inode: 30526104    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-01-11 12:59:10.000000000 +0100
Modify: 2009-11-02 04:48:41.000000000 +0100
Change: 2013-01-11 12:59:11.000000000 +0100

Esto huele a problema con la plantilla … y googleando un poco hemos encontrado algunas referencias y en concreto esta: http://forum.parallels.com/showthread.php?t=258358

La solución rápida es desinstalar y reinstalar el paquete anacron o crear los ficheros /etc/cron.{hourly,daily,weekly,monthly}/0anacron Que son los que faltan.

apt-get remove --purge anacron
apt-get install anacron

El contenido del fichero 0anacron:

/etc/cron.daily/0anacron 
#!/bin/sh
#
# anacron's cron script
#
# This script updates anacron time stamps. It is called through run-parts
# either by anacron itself or by cron.
#
# The script is called "0anacron" to assure that it will be executed
# _before_ all other scripts.

test -x /usr/sbin/anacron || exit 0
anacron -u cron.daily

Error migration Plesk 11 : Failed to execute scout.

Parallels Plesk Panel 11 migration error

Esta mañana migrando unos dominios a un servidor con Plesk 11 ( de Axarnet estamos probando este proveedor ) nos ha saltado un TOTAL FAIL ! migrando los dominios. El error es este :

 

 

 

 

= STDERR ====================
Failed to execute scout.
The return code is 9
The output on STDERR is
Unable to determine block size in df output. First line looks like ‘S.ficheros Bloques de 512 Usado Libre Ocupado Montado en
‘ at – line 560.

Nos parece tristísimo que a estas alturas, un software con la trayectoria de Plesk cometa estos fallos de principiante. ¿ De que hablamos ? De que la máquina de origen tiene el idioma por defecto como es_ES.UTF-8. Por eso cuando laza un df -h para ver si hay espacio salta el error en castellano…

Como somos perros viejos y no nos las sabemos todas, pero sí algunas, hemos ido directamente a cambiar el idioma en el servidor de origen a ver si cuela. Es una ubuntu así que lo hemos así :

vps:~# update-locale LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=POSIX
vps:~# locale-gen
Generating locales...
  en_US.UTF-8... up-to-date
  es_ES.UTF-8... up-to-date
Generation complete.

y ha funcionado perfectamente. A título personal, no está de más que en los scripts que lanza el agente migrador de plesk incluyan algo como:

export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

Como siempre Plesk, sigue decepcionando… en estos pequeños detalles. Esperemos que no aparezcan SQLi’s que nos dejen en bastante mala posición a los usuarios.

Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden

Otro error recurrente que aparece mucho en instalaciones con wordpress

[Mon Jun 11 08:17:25 2012] [error] [client 127.0.0.1] Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /var/www/vhosts/hostingaldescubierto.org/httpdocs/index.pl

En instalaciones Debian se corrige editando el fichero /etc/apache2/mods-available/dir.conf
La linea original es esta:

          DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm

y vamos a dejar una reducida

          DirectoryIndex index.html index.php

De forma que sólo se ejecuten estos ficheros como índices del directorio.

Usando Horde con safe_mode para enviar por smtp y no usar sendmail

Seguramente esté muy documentado ya por ahí pero es muy recomendable dejar de usar horde bajo sendmail con el fin de securizar la máquina. Con el cambio que comentamos a continuación, evitamos tener que ejecutar comandos en la máquina local, ya que el correo lo enviamos vía smtp al servidor local o a cualquier otro servidor que configuremos.

Resumen rápido:

Deshabilitamos la mayor parte de funciones potencialmente peligrosas para el sistema.
Esto implica que fallen algunas aplicaciones, como Horde

 
# /etc/php5/apache2/php.ini) 
disable_functions = system,passthru,readfile,escapeshellarg,proc_close,proc_open,ini_alter,dl,show_source,curl_exec

La alternativa elegante sería activar safe_mode y dejar de usar sendmail, como vemos en el fragmento de la configuración de Horde:

# fragmento de la configuracion de horde 
# /etc/psa-webmail/horde/horde/conf.p
if (ini_get("safe_mode") == "1") { // Safe mode in action
$conf['mailer']['params']['host'] = '127.0.0.1';
$conf['mailer']['params']['port'] = 25;
$conf['mailer']['params']['auth'] = false;
$conf['mailer']['type'] = 'smtp';
} else {
$conf['mailer']['params']['sendmail_path'] = '/usr/sbin/sendmail';
$conf['mailer']['params']['sendmail_args'] = '-oi';
$conf['mailer']['type'] = 'sendmail';
}

En Plesk10 se han definido plantillas para los servicios de forma que aunque cambiasemos los ficheros de configuarción de apache estos cambios se terminarían machacando y volveríamos al estado por defecto.

Para ello, Plesk ha provisto un repositorio de plantillas para configurar los servicios en /usr/local/psa/admin/conf/templates/

Para reconfigurar la plantilla tenemos aqui un copy&paste muy cómodo, como siempre nos gusta:

# reemplazar safe_mode en la plantilla
sed -i 's/safe_mode off/safe_mode on/g' /usr/local/psa/admin/conf/templates/default/horde.php
# reconfigurar las plantillas
/usr/local/psa/admin/bin/httpdmng --reconfigure-server
# recargar el servicio
apache2ctl graceful

Para probarlo es necesario cerrar la sesión de Horde y volver a autenticarse.

Vulnerabilidad CRÍTICA en la API de Plesk

Hace unas semanas se notificó por parte de Parallels un fallo crítico en el su software de panel de control de hosting: Plesk. Hicimos referencia a la nota en nuestro blog http://hostingaldescubierto.com/wordpress/2012/02/10/plesk-fallo-critico-de-seguridad-sql-injection/

Reciemiente hemos tenido accesos a una máquina usando este fallo de seguridad y vamos a compartir con vosotros algunas observaciones de estos accesos:

En el sistema se observan procesos perl no habituales, con lo que procedemos a buscar el origen del mismo con lsof y el resultado es que el origen del proceso pertenece a «/tmp/…» y se se ha eliminado. Ya esto nos da una idea de que el proceso no es para nada un proceso autorizado.

Verificamos /tmp y /var/tmp donde encontramos algunos ficheros ajenos al sistema pero sin contenido.

Si nos enganchamos al proceso , podemos ver que constantemente se está descargando ficheros de diversas urls con wget:

https://eycgkhkxfs.tmdnzapomk.info:1905//b/index.php?id=...
https://94.23.208.20:1905//b/index.php?id
https://rqckfdgumv.sxobnmbjzb.info:1905//b/index.php?...

Después de consultar algunas fuentes ( gracias Logan ) vemos que en los ficheros de logs de panel de control de plesk en /usr/local/psa/admin/logs/httpsd_access_log tenemos llamadas al fichero agent.php de la api de Plesk y posteriormente accesos al panel de control donde se suben ficheros a diversos dominios.

httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:00:33:05 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:03:04:52 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:03:37:21 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:37 +0100] "POST /login_up.php3 HTTP/1.1" 200 966 "https://x.x.x.x:8443/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:42 +0100] "GET /plesk/client@3/domain@/?context=domains HTTP/1.1" 200 29327 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:50 +0100] "GET /plesk/client@3/domain@222/hosting/file-manager/?cmd=chdir&file=%2Fcgi-bin%2F HTTP/1.1" 200 39293 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:13:06 +0100] "POST /plesk/client@3/domain@222/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"

y dentro del dominio en la carpeta /cgi-bin/ vemos ficheros .cgi con el contenido de los scripts que el atacante ha subido.

Un fragmento de uno de los scripts nos indica que los procesos ejecutados en el sistema provienen de esos ficheros

open(OLD_UNIX, ">", "/tmp/.X11-unix");
print OLD_UNIX decode_base64("....L....");
close(OLD_UNIX);
system("echo '* * * * * perl /tmp/.X11-unix >/dev/null 2>&1' >
/tmp/cron.d ; crontab /tmp/cron.d ; rm /tmp/cron.d");
system("perl /tmp/.X11-unix");
print "exdonen";

Como medidas para prevenir este fallo de seguridad hay que actualizar Plesk aplicando los microupdates.
Reviar /var/spool/cron aunque en nuestro caso no se han encontrado crontabs ajenos.
Es recomendable también ajustar los permisos para wget, curl y get

http://kb.parallels.com/en/113321

En breve daremos más detalles de las evidencias obtenidas.

Plesk Fallo crítico de seguridad: SQL Injection

Se ha notificado desde Parallels a todos los clientes de que existe un fallo grave de seguridad que permitie la inyección de código SQL que afecta a algunas versiones antiguas de Plesk . Las versiones afectadas son :

  • Linux – Plesk 10.3.1
  • Linux – Plesk 9.5.4
  • Linux – Plesk 8.6.0
  • Windows 10.3.1
  • Windows Plesk 9
  • Windows Plesk 8

Se han publicado parches para solucionar estos problemas. Instalando los microupdates se corrije el problema, excepto en las versiones para Windows Plesk 9 y Windows Plesk 8 que se han publicado parches específicos en este enlace :

How to fix vulnerability in Plesk 8.6, 9.3, and 9.5 for Windows

Para las versiones linux se puede ejecutar este comando para actuailzar la distribución:

/usr/local/psa/admin/sbin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base

Y por último si queremos verificar la versión de nuestra instalación lo podemos comprobar así:

cat /usr/local/psa/version

No hace falta decir que es crítico actualizar el sistema.