Ahora 200 conexiones desde aquí:
root@www:~# ps -ef |grep "vu2014"
vu2014 3707 1 3 00:45 ? 00:27:04 /usr/sbin/httpd
vu2014 3708 1 3 00:45 ? 00:25:41 /usr/sbin/httpd
Revisión del log otra vez...y nuevos ficheros infectados.
Creo que les voy a cerrar el sitio directamente.
La madre que me parió....no se si yo estoy tonto, o no.
https://dominio.com/client/phpini.php
Verde es igual a función deshabilitada.
Rojo es igual a función habilitada.
Joer, lo había entendido al revés y tenía todo habilitado.
Perdón por el forochat.
Sabiendo la hora en la que se ejecutó el proceso. Mucho mas facil encontrar uno de los agujeros.
Tapando....
Estaré atento a la evolución.
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.... 
Muchas gracias 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.
Increíble. Me respondieron, tarde, pero me respondieron.... y me dieron en todos los morros. Se puede cambiar la rDns desde el panel de control. Y además no está muy escondido.
Ahora ya está cambiado y replicado...pero sigo con reputación baja en SenderScore.org y no hay manera de que suba.
Revisando logs, no se envían mas mails que los permitidos, pero después de una semana de tranquilidad (en cuanto envío de mails) me extraña que no haya recuperado la puntuación. Tengo un triste 3.
El spf es el menor de los problemas (aun asi, muchas gracias)...el XXXX rdns es el que me está volviendo loco...y por supuesto, soporte 1and1 desde ayer enviado el mail y sin respuesta.
¿Reconfiguro el servidor poniéndole que el nombre de la maquina es el que me dan los de 1and1?
No me creo que tenga que hacer esto.....en fin...daré de tiempo hasta el lunes, y si no....
/var/www/imscp/engine/setup/imscp-setup -r
Y reinstalar.... 
Buenas,
Desde que usaron el servidor para enviar SPAM no levanta cabeza y sigo sin poder enviar correos a yahoo y hotmail por mala reputación. Estoy revisando logs y llevo sin enviar mierda una semana, pero aun asi, como se siguen enviando correos legitimos (pocos), no se ha limpiado la reputación y sigue estando en estado pobre.
He querido seguir ajustándome a buenas practicas para intentar mejorar la situación, como por ejemplo, instalar openDkim (mediante el plugin). Lo tengo habilitado en los dominios, pero aun así, sigo en las mismas.
Me faltaría (por lo que me dicen los analizadores automáticos) que los registros SPF no fuesen tan genéricos (indicando la ip del server en lugar de como está, que parece que está permitido para todas las ips), y me faltaria la rDns. Al ser un servidor de 1and1, me lo dieron con mi dominio, pero realmente resuelve a su nombre interno. No sé si ponerme en contacto con 1and1 para que cambien eso o reconfigurar postfix para que conteste como el supuesto dominio que tiene la ip. Lo mas fácil seria 1and1, pero con el servicio técnico que tienen me van a mandar a freír monas. ¿Se puede reconfigurar solo el postfix? ¿Como debería de hacerlo?
En la pagina mail-tester.com saco un 10 de 10. Pero me muestra esta advertencia:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Tu dirección IP 87.106.xxx.xxx está asociada con el dominio s1734xxxx.onlinehome-server.info.
Sin embargo, tu correo parece haber sido enviado desde www.dominio.com.
Puede que quieras cambiar tu entrada DNS puntero (tipo PTR) y el nombre de host de tu servidor al mismo valor.
Aquí están los valores testeados para esta prueba:
IP: 87.106.xxx.xxx
HELO: www.dominio.com
rDNS: s1734xxxx.onlinehome-server.info
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Un saludo y muchas gracias por adelantado.
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
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!!!).
