Cambio de DNS primario y secundarios en panel de nombres de dominios internacionales.
Tutorial paso a paso
Vamos a cambiar DNS primario y secundario de un nombre de dominio internacional en el panel de administración de su nombre de dominio provisto por SectorHosting.
1.- Ingrese a su panel de administración de su nombre de dominio.

Ingreso a su panel de nombre de dominio

2.- Ha ingresado a su pantalla principal.
En las opciones de “My Products”, ingrese en Domain Manager.

Pantalla principal de su panel

3.- Aparece el listado con sus dominios – Click sobre el nombre de dominio en cuestión.

Lista de sus nombres de dominios

4.- Aparecen las propiedades del dominio.
En el apartado Name Servers, click sobre el “Manage”.
En este caso aparecen los nameservers asignados: NS11.SECTORHOSTING.COM y NS12.SECTORHOSTING.COM

Propiedades del nombre de dominio elegido

5.- Click sobre “I host my domains whit another provider”. Los nombre de DNS aparecerán en campos de texto editables.

Campos de texto editables para el cambio de DNS's

6.- En el ejemplo hemos cambiado los NS11 y 12 por NS15.SECTORHOSTING.COM y NS16.SECTORHOSTING.COM.
Luego click sobre el botón “Ok”.

Cambios efectuados correctamente

7.- Tarea terminada. Ahora el nombre de dominio tiene asignados como nameservers: NS15.SECTORHOSTING.COM y NS16.SECTORHOSTING.COM. El nombre de dominio tardará en responder desde los nuevos nameservers en Internet, desde unos pocos minutos, hasta algunas horas. Recibirá un email en su dirección registrada informando del cambio.

Visualización de los cambios realizados

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

Los aspectos de seguridad tienen una importante componente técnica que no podemos ovbiar. Lo que sigue intenta brindar algunas pistas.

Con la sencillez que ofrecen hoy día los instaladores de los sitios Web de administración de contenido (CMS como Joomla, Moodle, WordPress, etc.) es muy común que, una vez que ha finalizado la instalación, el interesado sólo se dedique a cargar su propia información y configurar las opciones (más que abundantes) con lo que, en realmente poco tiempo, se puede tener un importante y profesional sitio Web.

Sin dudas, el uso de estas aplicaciones es tentador por su facilidad de instalación, potencia, variedad de opciones e importantes herramientas que brindan a administradores y usuarios un sinnúmero de ventajas. La eficiencia del lado del usuario, y aún del administrador-Webmaster, es comprobada.

Sin embargo, la contraparte no es tan alegre ya que, normalmente, para poder iniciar o completar la instalación, el mismo proceso indica que ciertos directorios deben tener acceso total (0777) al igual que algún que otro archivo de configuración, lo que debe ser llevado a cabo si se quiere instalar el sistema, desde ya. Una vez finalizada la instalación y, al ingresar por vez primera al sistema desde la Web, en algunos casos (¡los menos!) se previene sobre la situación de modo que la persona pueda asignar relativa seguridad a su sitio Web y al resto de los usuarios que comparten un mismo servidor o unidad.

¿Por qué es tan riesgosa la situación?

Un directorio con acceso total (0777) significa TRES cosas desde el lado de un visitante anónimo por medio de la Web:

1) Puede LEER el contenido de un directorio

2) Puede ESCRIBIR en el directorio (se puede no sólo subir nuevos archivos sino romper o sobrescribir los actuales con el consiguiente daño que ello pueda generar a la funcionalidad de su sitio Web)

3) Puede EJECUTAR lo que se haya subido o modificado.

El punto esencialmente peligroso, como se dará cuenta, es el último.

Es importante notar que la gran mayoría de la gente que sube imágenes hace sólo eso: sube una foto. No intenta romper ni hackear un sitio Web.

El problema se suscita cuando alguien o, mejor dicho, un sistema de monitoreo de determinados CMS o tipos de instalaciones, encuentra un directorio con acceso total: sube lo que necesite para sus propósitos y ¡voila! lo ejecuta. Puede ejecutar un script o sistema para mandar spam desde su dominio; puede intentar propagar troyanos; puede poner en marcha un sistema de PHISHING (conocidos como sistemas para el robo de identidad personal sensible y confidencial) o puede sólo querer dejar su “huella” sobre su pseudo-capacidad (que no habría sido posible sin un acceso global que muy sencillamente se lo ha permitido).

Ahora bien. Si un sitio necesita que los visitantes suban imágenes y de un script que trabaje sobre ellas (creación de miniaturas, resampleos, etc.) necesitará de permisos 0777.

La pregunta que debemos hacernos salta a la vista:

¿Cómo mantener la funcionalidad y no descuidar la seguridad del sitio Web?

Intentaré brindar posibles respuestas.

Algunas sugerencias para mitigar el conflicto

Existen muchas opciones a la hora de asegurar un sitio Web.

Algunas son llevadas a cabo a un nivel interno por parte de nuestra empresa por lo que podemos hacer frente a los miles de intentos a los que un servidor en Internet es afectado cada día… sí, ¡miles al día!

Para comprobarlo y a simple modo ilustrativo, busque “joomla hacking” (recuerde: Joomla es el nombre de un administrador de contenido muy conocid, puede buscar por otro si lo desea) en GOOGLE y verá importante cantidad de enlaces que evidencian la situación.

Veamos las opciones:

Primer caso: acceso global FUERA de public_html

En lo personal, cada vez que necesito un directorio con permisos global (0777), lo pongo al MISMO NIVEL que public_html y no DENTRO de public_html. IMPORTANTE: Nunca asigne permiso 0777 al directorio public_html

Cuando un visitante ingresa a su sitio Web de la forma www.ejemplo.com, está ingresando al servidor que aloja su cuenta y a una estructura que es algo así cómo: /home/ejemplo/public_html. Es particular accede a un archivo del tipo index.html o index.php quedando así el acceso real: /home/ejemplo/public_html/index.html o /home/ejemplo/public_html/index.php

En nuestro ejemplo, y desde la Web, NO se tiene acceso a /home/ejemplo ya que el mismo servidor Web se encarga de “rutear” TODOS los accesos al directorio antes mostrado: /home/ejemplo/public_html

Si se pone una carpeta con acceso global en /home/ejemplo/fotos es inaccesible desde la Web debido a que NO SE PUEDE ir hacía atrás desde la ubicación BASE que es: /home/ejemplo/public_html. No hay manera.

En éste escenario, el directorio fotos está protegido a pesar de tener acceso global debido a la naturaleza misma del servidor Web y no a un principio de seguridad que puede implementarse.

La ventaja queda clara aunque tiene una complejidad que no resulta muy cómoda de implementar: es necesario un script que sepa subir archivos fuera de la estructura accesible desde la Web. Si bien es para nada complejo, implementarlo puede resultarle en un cierto dolor de cabeza. Si le interesa, puedo brindarle algún script a modo de ejemplo. Su uso es libre (GNU).

Segundo Caso: DENEGAR ejecución de todo tipo de archivo MENOS de imágenes

En éste escenario UD. tiene un directorio como el que sigue (a modo de ejemplo siempre): /home/ejemplo/public_html/images

Para que sólo se vean los archivos de imágenes del tipo que desee (jpeg, jpg, gif, etc.), deberá crear un archivo que llamará así: “.htaccess” (el punto inicial es importante) y lo subirá al directorio que tiene las imágenes (/home/ejemplo/public_html/images en nuestro ejemplo)

El contenido del archivo es el que sigue:

# ————————————————————–
# DIRECTIVAS GENERALES
# ————————————————————–
# Evitar acceso por el navegador a una carpeta sin “index”:
Options All -Indexes

# Evitar el listado de directorios:
IndexIgnore *

# Evitar EXEC de scripts
RemoveHandler cgi-script .pl .py .cgi

# ————————————————————–
# No permitir ningún tipo de archivo
# ————————————————————–
<Files *>

# Primero controlaremos las directivas ALLOW y luego DENY
# Significa que debemos especificar TODO lo que permitiremos explicitamente.
Order allow,deny

# Si una directiva ALLOW se cumple, el acceso es concedido (en el presente bloque).

# Si ninguna directiva ALLOW se cumple, se examinan las directivas DENY

# Al ser DENY la directiva que se examina al final, debemos poner todo lo que
# deseemos denegar o nada para que se tome el default de
# la directiva que es: FROM ALL (denegar a todos los orígenes)

# Al NO permitir el acceso desde ningún host o IP al contenido del directorio actual
# (y todos los que se encuentran dentro de éste), no es necesario especificar la
# directiva DENY ya que se toma el default: a todos (FROM ALL)
# Deny from all

</Files>

# ————————————————————–
# Sólo permitir estos tipos de archivos
# ————————————————————–
<FilesMatch “\.(jpeg|jpg|swf|png|xml|gif|ico|html)$”>

# Si se ingresó a este bloque, es que se trata de un tipo de archivo (extension o
# parte final del mismo) permitido (por el FilesMatch)

# Primero controlaremos las directivas ALLOW y luego DENY
# Significa que debemos especificar TODO lo que permitiremos explicitamente.
order allow,deny

# Como se trata de un Order que tiene por default a denied, debemos indicar una
# directiva del tipo ALLOW.  Si se quita la linea que sigue, es denied por default
# (tal lo que se acaba de explicar)
allow from all

</FilesMatch>

# ————————————————————–
# Lo que sigue es a los solos efectos demostrativos y es totalmente equivalente a la
# sección anterior salvo por el esquema de control de las directivas Allow y Deny
# que es el inverso.
# SOLO PERMITIR ESTOS TIPOS DE ARCHIVOS
# ————————————————————–
<FilesMatch “\.(jpeg|jpg|swf|png|xml|gif|ico|html)$”>

# Primero se controlan las directivas DENY y luego ALLOW
# Significa que debemos TODO lo que NO se permite y, sino, es concedido el
# acceso por default
order deny,allow

# Como se trata de un Order que tiene por default el permitir el acceso, NO es necesario
# dar mayores detalles por lo que no es necesaria una directiva ALLOW: allow from all

</FilesMatch>

Sólo es necesario que lo agregue en el directorio protegido. Si, por ejemplo, dentro del directorio con acceso global de nuestro ejemplo (/home/ejemplo/public_html/images) tiene otro directorio también con acceso global (digamos: /home/ejemplo/public_html/images/files) NO necesita ponerlo dentro del directorio “files” ya que se toma la configuración del anterior. De todos modos, si lo copia en todos y cada uno de los directorios con acceso global (0777) no hay problema. Funciona igual.

Con éste archivo NO se impide que se suba NINGÚN tipo de archivo al directorio comprometido, sólo se impide que se EJECUTEN otros archivos que no sean los tipos de imágenes especificados (pueden ser los tipos de archivos que desee).

No es una solución realmente segura en su totalidad debido a que varias vulnerabilidades han sido explotadas por medio de imágenes especialmente preparadas. La ventaja es que no son muy frecuentes los ataques desde imágenes ya que los sistemas de búsqueda prefieren no complicarse y van detrás de sitios sin protección alguna. Piense que son sistemas que corren en modo automático las 24 horas y que avisan al “dueño” si se pudo entrar. Si se encuentran con una traba como la descrita cambian de dominio (casi siempre) salvo que alguien quiera dañarle puntualmente.

Una consideración final

La seguridad de un sitio Web debe ser mantenida entre ambas partes: prestador del servicio y cliente.

El proveedor de hosting debe contemplar las correspondientes actualizaciones de seguridad, upgrades de servicios y demás aspectos ligados a la seguridad de servidores que utilice (ej: modsecurity en Apache)

La parte del cliente puede resultar compleja o no, dependiendo de sus conocimientos, pero independientemente de ello, es necesario invertir tiempo en el tema seguridad de un sitio Web. El medio lo requiere. Internet no está libre de personas mal intencionadas que intentarán utilizarla para fines personales y, muy a menudo, con delictivos propósitos.

Reciban un cordial saludo,

Julio Alfredo Botto
www.sectorhosting.com

Adenda (por la implementación de Suexec):

Si se ha activado el módulo suExec y PHPsuExec, deberá asignar el permiso 775 en lugar de 777 cuando requiera accesibilidad global. De no hacerlo, se recibirán errores 500 (Internal Web Server Error) que indican la asignación inválida de un permiso en un script CGI o PHP.

© 2010 SectorHosting BLOG Suffusion WordPress theme by Sayontan Sinha