1. ¡OFERTA! con cupón "DIRVPS": hosting por $0,01 y también VPS Linux y Windows por $0,01 el primer mes por Interserver ← publi
    Descartar aviso
Descartar aviso
Al usar este sitio web, aceptas que nosotros y nuestros socios podamos establecer cookies para fines tales como personalizar el contenido y la publicidad. Más información.

Problema phishing

Tema en 'Manejando una empresa de hosting' iniciado por malagueta, 12 Ago 2014.

  1. malagueta

    malagueta Nuevo usuario

    Buenas;
    Tengo un servidor privado administrado por una empresa y tengo constantes inyecciones de códigos para intentar vulnerar la identidad de Google Docs, inyectando normalmente un archivo .rar que es descomprimido en varias carpetas de mis distintos dominios dentro del mismo servidor. Tengo casi todas las webs con Joomla, diferentes versiones, actualizadas o no (por lo que descarto vulnerabilidad del CMS) y el servicio de administración solo me sabe decir que es vulnerabilidad de los CMS.

    ¿Alguna idea o posible solución? Gracias.
     
  2.  
  3. Yo probaría primero a actualizar todos los cms a la última versión por que la 1.5 de joomla tiene muchos bugs y si aun así pasa diles que te instalen CXS de configserverfirewall si usas cpanel.

    Salu2,
     
  4. AMateos

    AMateos Súper Moderador Miembro del Staff Moderador CH

    Como consejo adicional, puedes intentar detener la entrada de ese fichero con ModSecurity. Tienes un VPS administrado, por lo que tu proveedor debe poder ayudarte con él. Desconozco si pagando un plus.

    Si los sitios ya fueron vulnerados una vez, es posible que la vulnerabilidad ya esté integrada al código y ficheros, independientemente de la versión. Aún así, utilizar versiones antiguas es la mejor forma de decirle al atacante que puede seguir haciéndolo, por lo que independientemente de que solucione el problema o no, actualizaría los sitios. Y, si puedes permitirte eliminar sus archivos, y sólo colocar los originales de Joomla, mucho mejor.

    Un saludo,
     
  5. egrueda

    egrueda Usuario activo

  6. malagueta

    malagueta Nuevo usuario

    Gracias a ambos ¿habría alguna manera de no permitir la subida de esos archivos por htaccess? siempre tienen el mismo nombre. De todas formas empezaré a migrar y actualizar todos los CMS.
     
  7. egrueda

    egrueda Usuario activo

    Con mod_security puedes filtrar lo que se sube al servidor via HTTP (e incluso via FTP) sea cual sea el nombre. De esa forma te proteges de todas las amenazas, y no sólo de las que conoces.
     
  8. Datacenter1

    Datacenter1 Usuario activo

    mod_security solo habla http, no entiende ftp, puede ser configurado para que escanee archivos subidos mediante http, pero no vía FTP

    @malagueta mantener los CMS actualizados, utilizar solo plugins seguros y actualizados, eliminará en gran parte las inyecciones de código, no importa cuánta seguridad tenga el servidor si el código permite subir archivos ya sea por diseño o por bug de programación
     
  9. egrueda

    egrueda Usuario activo

    Me refería a que puedes explorar todo lo que subes por http y por ftp, ya sé que no con modsec (me he expresado mal), pero sí con cxs, que se integra en modsec y en el servidor ftp.
    Es imposible que todos tus clientes tengan actualizados los cms y todos los plugins de cada uno de ellos. Tenerlo todo actualizado, incluso lo que no sabes que tienes, es utópico.

    Y sí, por supuesto que SI IMPORTA la seguridad del servidor, porque puede protegerlo de subidas de archivos, de inyecciones y de mil cosas gracias al maravilloso modsec y unas reglas en condiciones.
    El código permitirá que se suba el archivo, pero modsec lo detendrá o csx lo filtrará.
    Sería una irresponsabilidad recomendar a alguien que se fíe de tener todos los cms actualizados, en lugar de usar un filtrado web (waf) para detener ataques conocidos y desconocidos.
     
    A justice13 le gusta esto.
  10. Datacenter1

    Datacenter1 Usuario activo

    no busco entrar en polémicas, pero puedo decirte que uno de nuestros clientes, está detrás de un firewall, de hardware, un IDS (suricata) con reglas de pago emergingthreats, mod_security con reglas COMODO y recibe inyecciones frecuentes, la razón: un montón de jommlas 1.x con dos +2 años sin actualizar

    Si el software es vulnerable por diseño, es extremadamente difícil que del lado del servidor se puedan parar todos los ataques, si el software es seguro por diseño, tendrá mucho mejor chance de no ser vulnerado aún en un servidor pobre en seguridad
     
    A Aldeahost, justice13 y nonamef191118 les gusta esto.
  11. egrueda

    egrueda Usuario activo

    Me encanta la polémica :)

    modsec con unas buenas reglas (yo uso las de atomic) pueden detener más del 99% de ataques a un joomla 1.x
    De hecho es muy improbable que hoy en día alguien pueda subir un rootkit o similar a un joomla 1.x con un modsec bien armado. Recibirán cientos o miles de inyecciones, eso no lo vas a evitar, pero modsec los detectará casi todos, incluso aquellos ataques que consigan subir archivos, no podrán ser ejecutados porque modsed detiene la llamada que haces al archivo después de subirlo. Y ya si usas cxs, el archivo directamente se pondrá en cuarentena.

    Tengo servidores con joomlas 1.x y hasta con mambos, dotnukes y oscommerces y no puedo obligar a mis clientes a migrar a otra versión ni puedo/quiero echarles. Sin embargo estoy tranquilo y seguro con modsec+cxs (y en breve, cloudlinux).

    Hay otros clientes que instalan el software que quieren en sus hospedajes, y aunque cxs nos avisa de versiones obsoletas de los scripts más conocidos, lo cierto es que no podemos estar al día de todos los scripts que se suben (conocidos o desconocidos), de las versiones, de los plugins/módulos y de cientos de miles de variables.
    Por eso es impensable que podamos llegar a tener todas las versiones de todos los scripts actualizados.

    Es más, modsec nos ha ayudado incluso en casos de riesgo zero-day, porque aunque todos los clientes actualizasen todos los scrips y todos los plugins, siempre existe un espacio de tiempo entre que sale la vulnerabilidad y que el cliente actualiza, y en ese espacio de tiempo, lo único que te protege es un WAF.

    Confío en mi waf, y sé que no es 100% infalible porque nada lo es, y no concibo que nadie que entienda el funcionamiento de modsec pueda negar la evidencia de fiabilidad y seguridad que ofrece, más allá de scripts actualizados.

    modsec me ofrece una seguridad tangible y permanente, ya sea que los scripts están actualizados o no, y sinceramente pienso que todo proveedor de hosting debería ofrecer esa seguridad, tanto por su propia seguridad como por la de sus clientes.

    Creo que esa premisa es incorrecta. Si el software es vulnerable por diseño (y recuerda que siempre lo será) no hay excusa para no utilizar un WAF. O dicho de otra forma, precisamente porque el software es vulnerable, debes usar un WAF.

    Entonces, mientras que el 100% del software no sea 100% seguro en el 100% del tiempo, el proveedor debe ofrecer una capa de seguridad como la que en mi caso conseguimos con modsec+cxs, entre otros.
    Tengas o no tengas los scripts de tus clientes actualizados, creo que un WAF es obligatorio, y el hecho de no utilizarlo no es una opción.
     
    A justice13 le gusta esto.
  12. Por eso dije yo de entrada que actualizar actualizar actualizar y para detectar y limpiar CXS. Totalmente de acuerdo @Datacenter1
     
    A Aldeahost le gusta esto.
  13. hostigal

    hostigal Usuario activo

    NO estoy de todo deacuerdo, está claro lo teneis razón en parte en lo del ModSecurity
    Pero por mucha seguridad que cumpla el server, si existen sitios muy vulnerables siempre queda abierto una posibilidad a tener problemas...

    saludos.
     
    A nonamef191118 le gusta esto.
  14. egrueda

    egrueda Usuario activo

    Por supuesto, eso es cierto y en ningún momento lo niego, así como tampoco afirmo que modsec pueda ser 100% seguro.
    Pero partiendo de que siempre va a haber sitios web vulnerables, el mínimo de seguridad obliga a usar, como poco, un WAF

    No digo que no sea necesario actualizar todos los scrips y todos sus plugins, digo que sencillamente es imposible controlar cada versión de cada plugin y obligar a cada usaurio a actualizar o migrar, y que por tanto se hace necesario un nivel de protección por encima de eso.
     
    A justice13 le gusta esto.
  15. hostigal

    hostigal Usuario activo

    Pues yo pienso que en todo momento cualquier persona debería tener actualizado, y sino no utilizar un cms. Tambíen te doy la razón en parte...pero el que utiliza un cms debería saber a que se atiene...y debería ser responsable. saludos.
     
    A nonamef191118 le gusta esto.
  16. justice13

    justice13 Usuario activo

    Yo estoy con @egrueda, y claramente todos sabemos aquí cuál sería la situación de ensueño, pero como la realidad dista mucho de la ficción, habrá que dar algunos pasos para quedarnos más cerca de esa situación casi perfecta, y pasa por lo comentado por egrueda: plugins como CXS o Pyxsoft (funciona bastante bien, yo es el que tengo implementado), y por supuesto un firewall, entre otras cosas.
     
  17. Y lo peor de todo es que los cms los instalan los diseñadores y dejan la variable por defecto en la base de datos que eso es un vector de sql injection si te quieren atacar y los privilegios de ña base de datos marcan todos los privilegios. Yo creo que también se debería educar al cliente aplicar mucha seguridad sin educar al cliente no sirve de nada. Si no actualizas windows por más firewall que tengas con el del norton te la cuelan igual es un ejemplo.
     


Alojamiento web, Hosting Reseller, Servidores Dedicados - All in Hosting


    
    
    
    
Blog · Sitios amigos: GuiaHosting · Unidominios · Interalta ·