CONSULTA DEL USUARIO:

Amigos de SH:

Ya borre el archivo data_.php, el mismo fue añadido el dia 23/06/2008. Yo no realice ninguna tarea en el sitio desde el dia 20/06 por lo tanto, el archivo fue subido al servidor por otro medio.

Sinceramente no se adonde puede estar el error, por el momento, voy a optar por realizar un cambio en la contraseña. Solicito el alta del dominio nuevamente.

Si pueden aconsejarme en algo acerca de la seguridad de mis dominios, estaria muy agradecido.

Atte
Santiago

RESPUESTA DEL STAFF:

Estimado Santiago:

Antes de reactivar acceso, debe confirmar que la versión del sistema instalado sea la última puesta a disposición por el desarrollador y que todas las eventuales actualizaciones de seguridad estén debidamente aplicadas.

La seguridad es algo que depende de varios aspectos y debe ser contemplada por UD. y por nosotros de forma tal que las vulnerabilidades que aparezcan sean corregidas a tiempo, máxime cuando ha sido víctima de un ataque previo: su cuenta puede estar a la “lista” de algún delincuente “de pacotilla” (mal conocidos como “hackers“… ¡distan mucho de serlo!).

Algunas consideraciones generales a tener en cuenta:

1) Cuide sus credenciales de acceso para evitar que sean utilizados para el ingreso a la cuenta (ej: no las utilice desde una conexión pública como un cibercafé).

2) Genere contraseñas seguras no menores a 8 caracteres y mezcle letras minúsculas y mayúsculas, con números y símbolos (ej: aRm84*5!y7)… y mejore su ingesta diaria de fósforo (¡su cerebro lo necesitará para tales claves!)

3) Si utiliza un sistema de terceros (ej: Joomla, Moodle, Xoops, etc), tenga el hábito de controlar que su versión sea la más reciente. Regístrese para recibir novedades o actualizaciones por parte del fabricante y atiéndalos tan pronto le resulte posible.

4) Regístrese en algún sitio de publicación de vulnerabilidades de modo que reciba novedades sobre los sistemas que utilice y pueda reaccionar a tiempo. Puede consultar: http://secunia.com

5) Si necesita directorios con permisos de acceso global, ubíquelos fuera del directorio public_html o protéjalos debidamente (ver: http://blog.sectorhosting.com/2007/06/18/proteger-una-estructura-web-parte-i/)

6) Sus scripts PHP deben tener permiso 0644 para minimizar problemas. En nuestros nuevos servidores no es posible que los scripts PHP tengan otro valor ya que se produce un error. Se detiene la carga. En breve, todos nuestros servidores contarán con el mismo control.

7) Si coloca imágenes que “apuntan” a un script PHP tenga cuidado ya que puede descargarse el archivo PHP sin problemas y desde cualquier navegador. Si su imagen apunta a un archivo index.php, por ejemplo, podría descargarlo y verlo sin problemas. Si tal script tiene datos de acceso a una base de datos, por ejemplo, imagínese en manos no deseadas lo que puede pasar. Por lo tanto, las referencias del tipo HREF complételas así http://www.example.com y no así http://www.example.com/index.php

8 ) Controle que NO estén habilitadas las definiciones de variables globales desde la URL, es decir, que el flag register_globals de PHP esté desactivado (OFF). Si no es así y aún está en un servidor que no ha activado dicho valor (muchas cuentas están siendo actualizadas para el cambio) agregue la siguiente entrada al archivo .htaccess que se encuentra en su directorio public_html (y en todos los que tenga dentro de esa estructura y que contengan scripts PHP): php_value register_globals off (NOTA: si agrega dicha entrada en un servidor que implementa suExec para PHP recibirá un error. En tal caso, quítelo ya que su servidor ya está configurado con la opción desactivada)

9) Si cuenta con formularios de contacto, agregue un código de validación humano o CAPTCHA para evitar que sea utilizado por sistemas automatizados con diversos propósitos (Ej.: envío de correo basura o spam).

10) Para tales formularios de contacto, controle cada uno de los campos para evitar sean utilizados para spam por medio de reescritura de headers. Es decir, anule caracteres de retorno de carro y nueva línea y cadenas del tipo “Cc:”, “Bcc”, etc.

Si bien la lista puede ser mayor, si se contemplan tales aspectos podría casi asegurarle que el usuario malintencionado cambiará muy rápido de destino ya que, en realidad, la gran mayoría de las cuentas de hosting no están actualizadas ni protegidas para la mitad de los puntos indicados arriba de modo que, ¿para qué complicarse con tanta “oferta”?

Soporte Técnico
www.sectorhosting.com