Blog

Archive for Seguridad

Cómo cambiar globalmente la contraseña para una cuenta en todos tus wordpress con Core-Admin

En caso de que necesite cambiar la contraseña para la misma cuenta en todos los sitios WordPress de una máquina, puede hacerlo con la siguiente opción de Core-Admin.
El siguiente artículo explica cómo cambiar la contraseña para la misma cuenta en todas las instalaciones WordPress que se encuentren en una máquina con Core-Admin.

https://support.asplhosting.com/t/como-cambiar-la-contrasena-al-mismo-usuario-en-todos-los-wordpress-de-tu-maquina-con-core-admin/216

Posted in: Seguridad, Wordpress, Wordpress Manager

Leave a Comment (0) →

Cómo usar ipset para bloquear conjuntos de IPs grandes con #Core-Admin e #IpBlocker

[extoc]

Introducción a ipset con Core-Admin

En el caso de que quiera bloquear un conjunto grande de IPs (más de 500 ips/redes), entonces puede que haya notado que el modo por defecto block-by-iptables no es lo suficientemente rápido, además tiende a crear un conjunto de reglas iptables demasiado grande, que no ofrece un buen rendimiento.

Selección_334

Si ese es su caso, aquí puede ver cómo configurar su #IpBlocker para usar ipset del kernel de linux.

Prerequisitos para usar ipset con Core-Admin

Esta opción no está disponible para Debian Lenny, Debian Squeeze y Centos 6 debido a soporte limitado o inexistente de ipset.

Cómo activarlo ipset con Core-Admin

#IpBlocker está preparado para cambiar deblock-by-ipset a block-by-iptables y viceversa en cualquier momento que lo necesite. Esto incluye casos donde el firewall ya está funcionando y con un conjunto de reglas de bloqueo.

Para habiltiarlo, simplemente sigua los siguientes pasos. Abra el #IpBlocker como se muestra (se necesita permisos de administrador):

Selección_336

Luego abra la configuración:

Selección_337

A continuación, seleccione block-by-ipset en el modo de bloqueo y dele a guardar. Si no está disponible, por favor, actualice su core-admin. Dependiendo del número de reglas que tenga su máquina, puede que lleve algunos minutos hacer el cambio.

Selección_338

Operación activada

Si todo fue correcto, podrá usar su #IpBlocker como de costumbre (y el resto del sistema también). No se necesitan pasos adicionales debido a que una vez está hecho, es transparente para el usuario y para el sistema.

Algunos detalles internos de cómo ipset es usado con Core-Admin

Bajo el modo ipset, core-admin instalará solo unas pocas reglas dentro de la cadena iptables e ip6tables para enlazar el conjunto ipset creado.

>> iptables -S | grep set
-A INPUT -m set --match-set core_admin_blacklist_ipv4_net src -j DROP
-A INPUT -m set --match-set core_admin_blacklist_ipv4 src -j DROP
-A FORWARD -m set --match-set core_admin_blacklist_ipv4_net src -j DROP
-A FORWARD -m set --match-set core_admin_blacklist_ipv4 src -j DROP
-A OUTPUT -m set --match-set core_admin_blacklist_ipv4_net src -j DROP
-A OUTPUT -m set --match-set core_admin_blacklist_ipv4 src -j DROP

Estos conjuntos (“sets”) son accesibles ejecutando comandos habituales de “ipset” (no manipule directamente, use la aplicación #IpBlocker o la herramienta de comandos crad-ip-blocker.pyc):

>> ipset list

Posted in: Blacklist, Seguridad

Leave a Comment (0) →

Integración con Crad-Log-Watcher para bloquear IPs por fallos de login para aplicaciones web/servidor

[extoc]

Para integrar los fallos de login con crad-log-watcher y hacer que la IP remota sea bloqueada automáticamente cuando el número de fallos de login sean alcanzados, entonces siga la siguiente guía.

Los siguientes pasos le ayudarán a crear un handler para gestionar fallos de login que serán trazados y marcados para cualquier aplicación, de manera que la IP de origen sea bloqueada cuando un humbral configurable sea alcanzado.

  1. Primero, haga que su aplicación web o servidora genere una indicación de log con la IP que debería ser bloqueada (o controlada).

    Recomendamos enviar este log a syslog debido a que este log es accesible a todos los usuarios del sistema y no requiren un usuario ni permisos especiales. Esto simplificará los siguientes pasos. Si decide enviar esta información a otro log, simplemente adapte los siguientes pasos como corresponda.

    Con PHP, generar dichos logs, sería:

    // en caso de logins fallidos ::
            $remoteAddr = $_SERVER['REMOTE_ADDR'];
            $currentWeb   = $_SERVER['SERVER_NAME'];
            $loginAttempted = // apunte esta variable al login que ha sido intentado y ha fallado
            syslog (LOG_INFO, "Login failure from [$remoteAddr] access denied to [$currentWeb] with user [$loginAttempted]");
            

    Esto hará que se registre un log en el syslog cada vez que haya un fallo de login.
    Esto será necesario para cada aplicación web o servicio que sea necesario proteger.

  2. Ahora, cree un handler personalizado para crad-log-watcher que lea estos logs, lleve una traza de los logins fallidos y bloquee las IPs alcanzado los umbrales:

    Para eso, cree un fichero llamado login_failure_handler.py con el siguiente contenido (adapte a sus necesidades):

    #!/usr/bin/python
    
    from core_admin_common import support
    from core_admin_agent  import checker, watcher
    
    # database for tracking login failures
    database_path = "/etc/core-admin/client/my.watcher.sql"
    
    def init ():
    
        # notify this is child for checker notification
        checker.is_child = True
    
        # track and lock login failures
        (status, info) = watcher.create_track_login_failure_tables (database_path)
        if not status:
            return (False, "Unable to create ip_registry table, error was: %s" % info)
    
        return (True, None) # return ok init
    
    def handle_line (line, source_log):
    
        # only process log failures to block
        if "login failure from [" in line.lower () and "access denied to [" in line.lower ():
            
            # assuming log error format:
            # Jul  7 16:15:29 node04-grupodw python: Login failure from [88.99.109.209] access denied to [http://foobar.com] with user [userAccess1]
        
            source_ip_to_block    = line.lower ().split ("login failure from [")[1].split ("]")[0]
            login_failure_because = line.lower ().split ("access denied to [")[1].split ("]")[0]
            user_login            = line.lower ().split ("with user [")[1].split ("]")[0]
    
            # configure notification
            reason                   = "Access failure to %s" % login_failure_because
            fail_logins_before_block = 10
            
            # call to track user and ip
            watcher.track_and_report_login_failure (user_login, source_ip_to_block, reason, database_path, fail_logins_before_block, source_log)
    
        # end if
        
        return
    
  3. Ahora, ajuste este fichero dentro de /var/beep/core-admin/client-agent/log-handlers (cópielo dentro de este directorio)

  4. Ahora, dentro de /etc/core-admin/client/log-watcher.d, cree un fichero que vincule su /var/log/syslog con el handler que acaba de crear. Por ejemplo, haga que el fichero tenga la siguiente ruta: /etc/core-admin/client/log-watcher.d/custom-login-failures-blocker

    <log src="/var/log/syslog" handler="login_failure_handler" />
  5. Después de eso, simplemente reinicie crad-log-watcher para hacer que lea su handler y la configuración creada con:

    /etc/init.d/crad-log-watcher restart
  6. Supervise la ejecución de crad-log-watcher para asegurar que todo está funcionando con:
    # tail -f /var/log/syslog | grep crad-log-watcher
  7. Ahora, pruebe el desarrollo causando login fallidos al sistema protegido. Debería ver logs creados en /var/log/syslog.

    Si no ve ningún fallo de login, entonces el sistema no funcionará. Revise su código para asegurar que estos logs son creados.

  8. Si los logs de fallo de login son creados, entonces use el siguiente comando para mostrar si el trazado de login fallidos está ocurriendo:

    # sqlite3 -column -header /etc/core-admin/client/syslog.watcher.sql "select * from login_failure"

¿Alguna cuestión? Contacte con nosotros en support@core-admin.com (https://www.core-admin.com/portal/about-us/contact).

Posted in: Blacklist, Firewall, Seguridad

Leave a Comment (0) →

Controlando el “content filter” Amavis con Valvula (protocolo “access policy delegation”)

Índice de claves

Resumen

Controlando los correos comprobados o producidos por el servidor de “Content filter” (Amavis) con el servidor de delegación de políticas de acceso (Valvula)configurado en Postfix.

Introdución

Debido al modo en que funciona Postfix cuando configuras el parámetro “content filter =”, donde configuras Amavis o cualquier otro servidor de “Content Filter”, esto hace que todos los correos que entran en la cola de Postfix sean envaidos a Amavis (o el servidor de “Content filter” que tenga configurado) de manera que el correo sea procesado y a su vez, si todo está correcto, ese correo regresará a Postfix a través de un puerto interno diferente (típicamente 10025/tcp).

Desde aquí, asumiremos que el servidor de “Content Filter” es Amavis y Valvula como servidor de delegación de política. Si este no es el caso, este artículo sigue siendo relevante para su configuración.

Una vez que Amavis ha decidido que todo está correcto, ese correo es enviado de nuevo a Postfix en un puerto dedicado, usualmente declarado como sigue en  /etc/postfix/master.cf:

# amavis connection, messages received from amavis 
127.0.0.1:10025 inet n - y - - smtpd
 -o content_filter=
 -o local_recipient_maps=
 -o relay_recipient_maps=
 -o smtpd_restriction_classes=
 -o smtpd_client_restrictions=
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject 
 -o mynetworks=127.0.0.0/8
 -o strict_rfc821_envelopes=yes
 -o receive_override_options=no_address_mappings

Como puede ver, cualquier correo será aceptado en el puerto (10025/tcp) mientras que venga de localhost (confianza total).

Sin embargo, el problema que queremos resolver es como enfrentarnos a correos originados desde el servidor internamente (enviados por el comando mail/maildrop) o porque sean enviados por mailman (o alguna configuración del propio servidor de “Content Filter” que también puede producir correos por si mismo) y que estos sean controlados/supervisados por Valvula (access policy server).

En este caso, con la configuración anterior no hará que los correos producidos por Amavis sean controlados por Valvula.

Qué hay que cambiar para que el servidor de políticas sea llamado

Con esta información identificada, en el caso de que sea necesario filtrar los correos enviados de regreso a Postfix por el servicio de “Content Filter”, puede actualizar el siguiente parámetro:

        -o smtpd_recipient_restrictions=permit_mynetworks,reject

..para que sea lo siguiente:

        -o smtpd_recipient_restrictions=check_policy_service,inet:127.0.0.1:3579,permit_mynetworks,reject

Esta esta la configuración recomendada para Core-Admin, donde la parte relevante es “127.0.0.1:3579″ y que tiene que ser actualizada con su configuración local.

De esta manera, cuando Amavis termine, ese correo tendrá que ir también através de Valvula cuando vuelva a Postfix.

Interacciones que puede causar esta configuración

Este cambio hará que Valvula (o el servidor de políticas que tenga configurado) que sea llamado 2 veces por cada correo recibido. Primero cuando el correo es recibido y segundo, cuando es recibido después que Amavis termina de procesar el correo.

Porqué no configurar esto por defecto

Esta configuración aquí descrita puede ser interesante en algunos escenarios.

Para el caso de un servidor de correo dedicado, esta configuración no es útil/necesaria. Nos referimos “servidores de correo dedicados” aquellos que no tienen un software de gestión de listas, páginas webs o cualquier otro software que pueda proucir correos internamente y que sea necesario limitarlos, bloquearlos o descartarlos.

Por otro lado, esta información puede no ser interesante en todos aquellos casos conde esta limitación pueda ser en origen (actualizando la configuración del servicio produciendo estos correos a limitar) o incluso la configuración de Postfix authorized_submit_users.

Resumiendo, esta no es la única configuración disponible para limitar/controlar correos desde dentro del servidor usando el servicio de delegación de política de acceso (http://www.postfix.org/SMTPD_POLICY_README.html).

Posted in: Administrador de Correo, Amavis, Postfix, Seguridad, Valvula

Leave a Comment (0) →

Let’s Encrypt: la revolución silenciosa

Let’s encrypt: la revolución silenciosa de los certificados SSL

Let's encrypt logoSi ha tenido que comprar un certificado digital SSL —terminología antigua, ya que en realidad ahora todo es TLS [2] — sabrá que tienen un coste y que ese coste lo pagamos debido a que una entidad “confiable” pone su “firma digital” en nuestro certificado para que los navegadores, a su vez, y por esta cadena de “confianza”, acepte nuestro certificado.

Y de eso va la tecnología SSL/TLS: de confianza.

Criptografía asimétrica: el resumen más corto de la historia

Para poder entender porqué SSL/TLS es tan importante para la seguridad del Internet de hoy en día y ese “verde” característico que aparece cuando escribimos https:// en nuestro sitio favorito, tenemos que entender qué es la Critografía Asimétrica [1] y qué relación guarda con eso que hemos dicho antes: “la confianza”.

Brevemente, la critografía asimétrica permite generar una llave pública y una privada de tal modo que todo lo que sea cifrado con el certificado público, sólo podrá ser descifrado por la llave privada (que es la que queda instalada en el servidor y que nunca saldrá de allí: salvo fallo de seguridad).

Sobre este pilar de criptografía matemática se fundamenta todo el protocolo TLS [2] (versión evolucionada del SSL), el cual proporciona una serie de intercambios para que el cliente que conecta con el servidor, pueda recibir y aceptar una serie de indicaciones que permite intercambiar mensajes de manera segura.

Sin embargo, aquí hay un “pero” y radica en esa parte “de intercambiar de manera segura” información.

La pata que le falta para completar SSL/TLS: la confianza

Lo único que asegura SSL/TLS es que el emisor y el receptor, una vez completada la negociación, podrán intercambiar mensajes con la seguridad de que sólo el emisor y el receptor son partícipes de la conversación: nadie podrá espiar mientras los mensajes están en tránsito.

Sin embargo, el gran problema a solucionar es el siguiente: ¿cómo asegurar que estamos hablando con el servidor que queremos y no otro que está interceptando la comunicación?

Ahí es donde entra la cadena de confianza y las certificadoras digitales que todos conocemos, como, por nombrar algunas: GeoTrust, Thawte, Verisign, Comodo…

¿Qué milla extra venían aportando las certificadoras?

Con todas las piezas técnicas sobre el tablero, la pieza que nos falta para completar el puzle son las compañias que tienen reputación, que
son conocidas previamente, y que debido a acuerdos previos, han consegido que sus certificados de firma –simplificando algo el proceso– estén reconocidos por la mayoría de navegadores.

Debido a que los navegadores aceptan y confian en estos certificados, todo lo que sea firmado por ellos, será también reconocido y aceptado
sin error.

¿Qué aporta Let’s encrypt?

La base fundacional del proyecto es: certificados gratis para todos. ¿Y sin tener que pagar a las autoridades de certificación legacy?

Sí. Entonces ¿cuál es el truco? No hay truco.

Sin embargo, hay que entender su origen para saber cuál es su objetivo.

Let’s encrypt es una iniciativa apoyada por grandes de la industria y que necesitan que sus dispositivos, intranets y portales de gestión, etc, puedan tener un certificado reconocido por todos los navegadores.

Después de todo, ¿qué impide a estas compañías llegar a los mismos acuerdos con los navegadores para que sus certificados sean reconocidos?

Combinando esta inclusión con un protocolo de validación y despliegue, let’s encrypt no sólo proporciona certificados que son totalmente reconocidos y sin costes: sino que automatiza la solicitud y configuración del certificado quitando al administrador la molesta tarea de solicitar y configurar un certificado.

Entonces, ¿desaparecerán las entidades de certificación?

En nuestra opinión, no. Se tendrán que especializar en emitir certificados que requieran una nueva milla adicional. También seguirán conservando la certificación de certificados para empresas y organismos. Ahí es donde let’s encrypt “no quiere llegar” (aunque podría).

[1] https://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica
[2] https://es.wikipedia.org/wiki/Transport_Layer_Security

Posted in: Let's Encrypt, Seguridad, SSL/TLS

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 &amp; 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 &amp; 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) →

Actualización — KB: 24032014-001: Gestionando problemas con time wait (no más conexiones TCP)

El artículo de base de conocimiento http://www.core-admin.com/portal/es/kb-24032014-001-dealing-with-time-wait-exhaustion-no-more-tcp-connections sobre cómo gestionar problemas de configuración reportados por el comprobador de time wait, ha sido actualizado para permitir configurar la opción TCP TIME WAIT recycle  (/proc/sys/net/ipv4/tcp_tw_recycle). El artículo también incluye información de cómo la opción se relaciona (y puede causar problemas) con dispositivos detrás de un firewall NAT cuando el servidor que ejecuta esta opción es accedido desde los anteriores.

El artículo también incluye referencias al artículo d Troy Davis http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/  (en inglés) que explica con mayor detalle porqué ocurre este problema del NAT.

Posted in: Administration, Firewall, KB, Seguridad

Leave a Comment (0) →

Let’s encrypt: certificados SSL/TLS confiables para todo el mundo

letsencrypt-128x128Let’s encrypt (http://letsencrypt.org) ahora está haciendo posible para todo el mundo tener acceso a certificados confiables de manera gratuita. Lo hace através de un cliente que implementa el protocolo ACME  (https://github.com/ietf-wg-acme/acme/), el cual permite tener acceso a la infraestructura Let’s Encrypt para solicitar y emitir un certificado para sus dominios.

Este es un paso muy importante para asegurar incluso la internet haciendo posible, como mínimo, asegurar todos los paneles de administración con Let’s encrypt. Estamos hablando de “al menos los paneles de administración” porque es posible que esté todavía interesado en los certificados SSL/TLS antiguos donde se puede incluir información de contacto o que por motivos legales o técnicos, necesite un certificado de un proveedor en particular.

En cualquier caso, esta nueva tecnología, promovida por importantes fabricantes involucrados en promocionar la web, proporcionará certificados confiables y seguros para muchos de nuestros dispositivos (routers, cosas IoT (“things”), “appliances”), para tenerlos protegidos con un certificado SSL/TLS para acceder a sus páginas de administración https:// ….y de manera gratuita!

Así que, ya no hay excusas para proteger sus páginas web sensibles, especialmente aquellas ejecutando servicios críticos con paneles de administración http://

Core-Admin y la aplicación de gestión Let’s encrypt

Core-Admin ahora soporta Let’s encrypt integrándolo completamente con una aplicación gráfica fácil de usar y que permite localizar fácilmente las webs ejecutando en sus servidores y solicitar un certificado para las mismas.

Esta es una nueva aplicación disponible para Core-Admin desde la revisión 4615.

Consule el siguiente  manual de Let’s encrypt para Core-Admin  para saber más detalles sobre la misma : http://www.core-admin.com/portal/es/applications/lets-encry

Posted in: Administration, Certificados, Seguridad

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