Problema HAckeo de Web

    Buenos días,


    Estoy un poco cansado ya con el tema de un alojamiento que tiene una web vulnerable. Se la han hackeado ya unas cuantas veces (y de distintas formas) y siempre me toca borrar y restaurar ficheros porque se dedican a tocar ficheros para enviar SPAM.


    Existe la posibilidad de bloquear para un dominio completo el sendmail de php (solo para un alojamiento)? Y congelar un directorio para que no se pueda modificar nada?


    La web se la hicieron y debe de tener varios agujeros de segurirad, y la verdad es que no estoy demasiado ducho como para dedicarme a revisar 1500 ficheros de otro programador para ver en donde NO ha metido la pata.


    Gracias por adelantado.

    Bueno, he avanzado algo, he modificado estos dos archivos:


    nano /etc/php5/fpm/pool.d/dominio.com.conf
    nano /etc/imscp/php-fpm/working/dominio.com.conf


    Y he añadido la función mail a funciones deshabilitadas:
    php_admin_value[disable_functions] = show_source,system,shell_exec,passthru,exec,phpinfo,symlink, mail


    He reiniciado el server, y con eso parece que se ha parado el envio de mails, pero no me termina de convencer como solución.

    Tio echalo a la calle o bien pon lo archivos fuera de propiedad de forma no puedan escribir en la carpeta, el que hayas parado los email no quiere decir que no usen el server para mil guarrerias mas, el correo es tan solo una de las muchas.


    No tardaras mucho en recibi correos de pishing, de scaneos, ataques de diccionario a otras webs y un largo etc mas....

    Lo sé, pero no puedo largarlo... :'(


    Necesito que los ficheros se ejecuten, pero que no se puedan modificar. Con cambiar de propietario a root valdría, no? pero....Si se ejecutan y se hace un chmod desde el php estaré en las mismas.....o no?


    Joer....tengo demasiado oxidados mis conocimientos de linux. Tocará modificar y ver que pasa...Y a unas malas, me cargo la web y ya lloraré después. (Vivan los backups!!!).

    Eso no se puede amigo una vez cambien de propietario ya no son de vu2???, que quieres root pues root que no otro usuario


    chown -R root:root htdocs/*


    Yo es un formula que hago, con los wordpress sobre todo,
    les aviso del problema,
    si reinciden los invito a irse,
    que no quieren les cambio el propietario

    Sorry for answering in english:


    Some of those spam scripts do not use the local mail server and therefore blocking the sendmail / mail command does not help at all. Those scripts make direct connections to other SMTP servers on port 25.


    I use the following iptables to block such outgoing traffic and allow only root and postfix users to send something out on port 25.


    Code
    1. # Allow internal mail delivery
    2. iptables -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 25 -j ACCEPT
    3. # Allow external mail delivery from root
    4. iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner root -j ACCEPT
    5. # Allow external mail delivery from postfix
    6. iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner postfix -j ACCEPT
    7. # Reject all other mail packets
    8. iptables -A OUTPUT -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachable

    Directorio congelado. Y cuando me llame mi amigo ya veré que hago.


    Al reiniciar el server se quitó la función mail de php_admin_value[disable_functions] y empezó otra vez a enviar mails.


    Analice los mails enviados con postcat y vi el fichero culpable. Borré el fichero, y después chmod. Y desde esta noche parece todo despejado.


    Veremos a ver lo que tardo en recuperar reputación, que ahora mismo tengo reputación poor.


    Muchísimas gracias kurgans y MuhKuh

    Al final, mirando conexiones con netstat -putona (ME ENCANTA METER LAS OPCIONES ASI), he visto que tenia muchísimas conexiones a puertos 25 de otros servidores.


    He mirado el proceso que estaba lanzando esas conexiones, y resulta que es del mismo propietario que la web hackeada.


    vu2014 22941 1 4 Oct06 ? 14:19:42 /sbin/mingetty


    mingetty?? No tengo ni idea de que es eso, ni como se puede bloquear para que no lo lancen de nuevo. Pero desde luego ha sido matar el proceso con kill y las conexiones a puertos 25 han caído.


    He probado a meter las reglas de iptables que puso MuhKuh, pero al meter:


    iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner root -j ACCEPT


    me aparece:


    iptables: No chain/target/match by that name.


    ¿Hay alguna otra forma para poder evitarlo? Voy a documentarme y leer (que lo necesito mucho) a ver por donde pueden venir los tiros del mingetty.


    It looks like your iptables does not support owner matching. Can you post the output of:

    Code
    1. cat /proc/net/ip_tables_matches

    root@www:~# cat /proc/net/ip_tables_matches
    state
    conntrack
    conntrack
    conntrack
    rpfilter
    ah
    icmp
    policy
    ttl
    ecn
    udplite
    udp
    tcp



    Creo que voy borrar el alojamiento, otra vez conexiones a puerto 25. Ahora desde udevd:


    root@www:~# ps -ef |grep "vu2014"
    vu2014 14016 1 3 Oct08 ? 00:23:31 /sbin/udevd
    vu2014 14017 1 3 Oct08 ? 00:23:56 /sbin/udevd
    root 20268 9940 0 10:32 pts/2 00:00:00 grep vu2014


    QUE HIJOS DE....


    Voy a asegurarme que el alojamiento tenga todas las funciones deshabilitadas y voy a mirar logs a ver si encuentro el agujero.... :S


    Muchas gracias MuhKuh